DO Ideas 2

Give users IPv6 /64 blocks when you roll out IPv6

As you guys are testing IPv6 in the Singapore region, I highly recommend you give users a /64 each when IPv6 rolls out. This is proper practice, and gives users more flexibility in terms of address selection.

  • D. Strout
  • Sep 11 2018
  • Attach files
  • Craig McQueen commented
    September 11, 2018 17:31

    I left DigitalOcean due to it not providing a /64 block. I occasionally check back here to see if there's been any progress. I'm amazed that there's been no improvement for 4 years.

  • Thomas commented
    September 11, 2018 17:31

    Is there any update here?

  • Pete commented
    September 11, 2018 17:31

    I should add that of course at present public SMTP servers need to be IPv4-capable. The server I want to send to is a private one in my organisation, and the only routable address it has is IPv6. That wasn't supposed to be a problem because all the machines within the organisation have IPv6.

  • Pete commented
    September 11, 2018 17:31

    I don't really need a whole /64 but I do need to be able to send email over IPv6, and as discussed elsewhere it creates reputation issues if everyone is jammed together in a single block.

  • navossoc commented
    September 11, 2018 17:31

    I'm looking for a /64 block too...

  • Anonymous commented
    September 11, 2018 17:31

    Ramnode has been assigning a /64 subnet to each VPS by default since 2014, and Linode offers a /56 subnet on request. In my mind, DigitalOcean is a unique cloud computing company with its commitment to simplicity, technologies and developers. You can do much better than providing 16 IPv6 addresses only.

  • RobM commented
    September 11, 2018 17:31

    Still waiting..... looks like DO are going to lose out very soon as other companies provide more

  • Sam commented
    September 11, 2018 17:31

    It's been three years. Why hasn't DigitalOcean done anything about this yet? I'm a new customer and I can't believe what I got myself into by choosing DO.

    I'm off to make sure my mail server doesn't try to send mail over IPv6....

  • Fashion Net commented
    September 11, 2018 17:31

    Please offer your clients a full /64 IPv6 block like Linode does.

    The reason this is important is that an Open VPN server not set up with IPv6 will leak the IPv6 location of the internet provider, thus defeating one of the reasons for using a VPN in the first place.

  • Luis Muñoz commented
    September 11, 2018 17:31

    Assigning less than a /64 to each host (Droplet from my perspective) introduces additional difficulty for a number of tasks and in my case, blocks most use cases involving SMTP email.

    Lack of IPv6-capable SMTP driven my use case back to Amazon EC2. I hope you can consider allowing at least /64 allocations and unblocking SMTP over IPv6.

  • Ryan Kaiser commented
    September 11, 2018 17:31

    Increase the size of routed IPv6 prefix to /64. If that is too big on a per-droplet basis, consider doing it on a per-account basis; or limit to one routed /64 block per data center. The current /124 block is essentially useless to me.

  • Ryan Kaiser commented
    September 11, 2018 17:31

    Increase the size of routed IPv6 prefixes to /64. If that is too big on a per-droplet basis, consider doing it on a per-account basis; or limit to one routed /64 block per data center. The current /124 block is essentially useless to me.

  • Thomas commented
    September 11, 2018 17:31

    Any news here?

  • Thomas Habets commented
    September 11, 2018 17:31

    /64? What? No, /48 to /56 is the standard. Just check wikipedia for one, and check every ISP.

    I get many /64 subnets for my stupid BT home broadband.

  • Paul Williams commented
    September 11, 2018 17:31

    Echoing the other comments.../64 per droplet and /48 or /56 per account please. The current setup breaks the spec and makes it difficult to utilize IPv6 on DO for a number of scenarios (Docker, OpenVPN, etc.).

  • Thomas commented
    September 11, 2018 17:31

    Also I would love to just get a /48 per account, it makes Firewall and IPsec rules so much simpler than having ~100 firewall rules for each droplet, which would bring it down to one firewall rule.

  • Thomas commented
    September 11, 2018 17:31

    Right now it's pretty hard to run Docker in IPv6 mode on DigitalOcean, since their Architecture wants a /64 per host so it can get give every container it's own IPv6 address.

    https://docs.docker.com/engine/userguide/networking/default_network/ipv6/

  • Troy Kelly commented
    September 11, 2018 17:31

    After many, many years as a Digital Ocean customer - we too are closing our account.
    Ignoring RFC and best practice because you (Moisey) have unilaterally decided that you know best is embarrassing.

  • Ben Speakman commented
    September 11, 2018 17:31

    Please this is a must and so easy to implement. There is no reason not to give out /64

  • Christian Kratzer commented
    September 11, 2018 17:31

    As there as been no response on this for over 6 months I am cancelling all my DO accounts today. Port blocks and no dedicated /64 are a show stopper for me.

  • Chris Weyl commented
    September 11, 2018 17:31

    Being so restrictive with ipv6 addresses doesn't make sense to me. For one, it's so unusual that I'm sure there's a ton of work going on behind the scenes to enforce this -- labor that wouldn't be necessary if DO just gave out /64's properly.

    Also, according to ARIN[1], it's likely the *minimum* allocation they'd give DO is a /32. That means DO would have 2^32 /64's to assign -- that is:

    DO has, at a minimum, over 4 billion /64 networks.

    ...and could easily get more, if, you know, about 75% (still over 3 billion) were allocated.

    If each droplet were given their own /64, that's still a *heck* of a lot of droplets.

    If each customer were given a /56 and allowed to carve it up as they chose, DO would have almost 17 million /56's to hand out.

    IPv6 addresses are *not* constrained by any measure.

    ...except artificially.

    Oh well, guess I'll be checking out AWS' recently announced support for ipv6 in certain regions of EC2... :(

    [1] https://www.arin.net/resources/request.html

  • Jeremy Tribby commented
    September 11, 2018 17:31

    Unbelievable. /64 is RFC. This isn't a political decision. DigitalOcean is intentionally going against spec for no reason.

  • Craig McQueen commented
    September 11, 2018 17:31

    I'm surprised this is still in the "gathering feedback" state. It seems the common consensus is:

    * Droplets should be allocated at minimum a /64, since that is the intent of IPv6 design.
    * Some want an account allocated a /56, which can have /64 allocated per droplet.
    * Some want to be able to pay for additional blocks to be routed to droplets (such as myself, for OpenVPN for example).

    It seems crazy for IPv6 to be so limited for a VPS, when my home ISP is allocating a static /56 per residential DSL customer!

  • Zachary DuBois commented
    September 11, 2018 17:31

    Hey guys, we have a thread raising many issues with DO that should be fixed before they continue to release new things (Snapshots, IPv6 implementation, etc). I'd throw some votes at is so we can influence their decision a bit.

    https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/16058596-fix-your-issues-and-listen-to-your-customers-more

  • Holger Schinzel commented
    September 11, 2018 17:31

    Same story here: Found out today that SMTP traffic via IPv6 is blocked due to users sharing the same /64 block. It was suggested to me that i should disable IPv6 lookups via /etc/gai.conf-file - which is basically like saying "Please disable IPv6".

    I suggested that assigning /128 or /80 subnets to droplets is against IPv6 design best practice and was referred to the developer forum (here!) [1] just to find out that this request is pending since > 2 years without ANY feedback from DO on timeline and priorities.

    Sorry DO, your IPv6 support is a shill. Get yourself sorted out and finally do it right. [2]

    [1] "As we're experiencing extreme growth, our engineering team is working as quickly as possible on a variety of known issues as well as feature requests. We are excited to hear feedback from you on how we can improve our service. To submit feature requests and suggestions, please visit our developer's forum where you can add, discuss, and vote on features:"

    [2] http://etherealmind.com/allocating-64-wasteful-ipv6-not

  • Avi commented
    September 11, 2018 17:31

    I'll quote Justin's comment: "It is against the IPv6 standard to allocate anything smaller than a /64 per subnet. Doing so breaks a lot of the fundamental assumptions that IPv6 relies on to operate properly."

    You got this so wrong DO. See http://etherealmind.com/allocating-64-wasteful-ipv6-not
    It's a brain dead idea to offer 16 hosts, and frankly the first time I've questioned the quality of your service.

  • Adrien Jarthon commented
    September 11, 2018 17:31

    I just hit the IPv6 filtering recently and was pretty surprised. In my case (updown.io) I don't even send email over IPv6, but I monitor other's servers, and if someones configure a simple TCP check on port 25 (to check if his SMTP server is up) I can't do this from DO. I never realized this before but this is pretty bad for me as this means I can't provide a good IPv6 support if it only works on some ports.

    I'm wiling to pay 1€ / month for a /64 IPv6 range if availability is an issue for you and you don't want to give /64s to everyone.

    Of course it would need to be unfiltered then.

  • Christian Kratzer commented
    September 11, 2018 17:31

    Yes please implement at least a routed per Droplet /64 network.

    The current setup is useless for me.

    I do not want to run anything in a shared /64 network. Google is already blocking connects from the respective networks and you are blocking mail related ports....

  • Christian Kratzer commented
    September 11, 2018 17:31

    The current ipv6 networking setup with a /124 network per droplet is rather crippled and forces lots of customers into a shared /64.

    Please implement at least an optional /64 IPv6 per droplet.

    Having per customer ipv6 addresse space for free use between Droplets would be even greater but dedicated /64 per Droplets would help a lot.

    This would also permit you to lift your mail related port blocks for the dedicated /64.

    The current shared /64 with /124 setup and the associted filters are a show stopper for my current project of moving my company's mail infrastructure from dedicated KVM hosts on our own hardware to DO.

  • Zachary DuBois commented
    September 11, 2018 17:31

    It seems like it would be fairly easy for DO to implement this. All it would take is a migration for users with the current setup and then a simple script to update the network interfaces (just like the one they did for old droplets with no floating IPs).

  • HLFH commented
    September 11, 2018 17:31

    We need a IPv6/48 block. Happily if I find better. I'll switch...

  • Zachary DuBois commented
    September 11, 2018 17:31

    I mean, I was sent here when I was asking why SMTP ports a filtered. Initially, a /64 should be given out because it is true most blacklists block /64's. I am out of votes but I would throw as many as I could here because these are the reasons IPv6 is having such a slow adoption. You have to pay attention to what every one is doing so you can implement it in a non-restriction way.

  • Anonymous commented
    September 11, 2018 17:31

    Hello,

    I suggest one /64 per droplet aggregated to one /56 per account and DC.

    Best regards,
    Frank

  • Anonymous commented
    September 11, 2018 17:31

    The rollout of IPv6 seems to show a rather high level of technical misunderstanding and possibly incompetence at many levels of DO's engineering team. Thinking you clearly know better than the IETF and authors of IPv6 specs is kind of hilarious.

  • Martin Komon commented
    September 11, 2018 17:31

    Upvoting this suggestion. A /64 per droplet is absolute minimum, a /56 to /48 per customer per DC is a reasonable option allowing enough space and flexibility.

  • Melissa Pilgrim commented
    September 11, 2018 17:31

    That needs to be a /64 per droplet. You can allocate a /56 or larger per customer per DC if you like, so customers with more than one droplet at a given location will get adjacent /64's. Keep in mind that ARIN, RIPE, and APNIC all expect you to allocate a /56 or larger per customer, and your upstream allocations were based on that. You paid for the allocation, we cover those fees with our droplets, so you are effectively not giving us something for which we're paying.

    Moisey, to address your concern, yes, those of us who harken back to the bad old days of pre-NAT IPv4 and classful routing remember the wasted addresses. But IPv6 was specifically made so large waste is completely a non-issue. The address space is so large we get statements like "can address half the atoms in the planet". Follow RFC, hand out a /64 per droplet, allocate a /56 per DC per customer. You will not make even the slightest dent in the available address space: as wasteful as that seems, you will still need 16.7 MILLION DC-customer tuples to exhaust a single /32.

  • Justin Cormack commented
    September 11, 2018 17:31

    The current setup is basically unusable, so I have stopped using DO until you give out a /64 per host.

    A /48 per account would be nice, that is what my home ISP does.

  • Phillip Smith commented
    September 11, 2018 17:31

    Assuming each DC has a /32 assigned to it, that's 4,294,967,296 /64 subnets. More than enough, and I'm sure they could get extra assignments even if it's not.

    I don't think assigning a /64 per account would be very smart.

  • Ben commented
    September 11, 2018 17:31

    Perhaps the best option would be to give the *user account* a /64 per Data Center used by the account, rather than a /64 per droplet. This avoids the problem with smaller-than-/64 networks, without the large usage of /64s for users who have lots of droplets.

  • Mickey commented
    September 11, 2018 17:32

    I've been using a ipv6 tunnel service through he.net They offer /48's and /64's with your own dns, its highly flexable, I don't encounter any issues - tunnel servers are a few miliseconds away from DO datacenters, My ipv6 ping over home tunnel is lower even with the extra hops. Moving servers? just point the endpoint to the new ipv4 and there no issue!

  • Anders Bergh commented
    September 11, 2018 17:32

    16 addresses is by far too few addresses... IPv6 allocations are not counted in addresses but subnets. And the smallest IPv6 subnet is a /64. Thinking in terms of number of addresses with IPv6 is wrong.

  • Mike Gabriel commented
    September 11, 2018 17:32

    Having the OPenVPN server-ip <ip>/112 issue, as well.

    Real /64 bit networks is a must IMHO.

  • Kristian Hermansen commented
    September 11, 2018 17:32

    Google is also blocking DigitalOcean customers because we are not assigned a proper /64 range of host bits. This means if a neighbor on the DO network is running a bot, your IPv6 is being flagged as well. As such, users are impacted right now and unable to rely on IPv6 services. DigitalOcean is effectively violating the RFC.

  • Ben commented
    September 11, 2018 17:32

    The big problem with the current practice of giving each droplet a /124 is that it has resulted in DO filtering email ports over Ipv6, on the theory that since email DNSBL blocking is normally done on a /64 basis, if a droplet does something over IPv6 email that draws a block, the block will end up blocking many other droplets. Note that this means that an IPv6-only dropet *cannot do email at all*. This alone, to me, argues for giving each droplet a /64.

  • Ed commented
    September 11, 2018 17:32

    Note that OpenVPN doesn't support server-ipv6 with anything smaller than a /112.

  • Justin Coffman commented
    September 11, 2018 17:32

    There is a lot of misconception here as far as allocated subnet sizes. It is against the IPv6 standard to allocate anything smaller than a /64 per subnet. Doing so breaks a lot of the fundamental assumptions that IPv6 relies on to operate properly. That said, there's no reason that a /64 block can't be allocated rather than just a single address.

  • Matt commented
    September 11, 2018 17:32

    The subnet size should be configurable. Most servers only need 1 address, but 256 addresses would be useful for SSL without SNI (server name indication). Also, multiple subnets should be allowed. You should be able to move those subnets to different hosts within a data center.

    With another VPS company, I setup OpenVPN to tunnel only IPv6 traffic through a IPv4 only ISP to that virtual server. OpenVPN requires two subnets, and they were able to route a second subnet of my requested size (/64) to the existing eth0.

  • Jan commented
    September 11, 2018 17:32

    No doubt that we need more than one address.. But a /64 address (18,446,744,073,709,551,616 IPs) would be a waste.

    I would prefer a /120 address (256 IPs) would be assigned to my account.

  • gp commented
    September 11, 2018 17:32

    I think people here are greatly understating how vast the IPv6 space is.

    From Wikipedia:

    The main advantage of IPv6 over IPv4 is its larger address space. The length of an IPv6 address is 128 bits, compared with 32 bits in IPv4. The address space therefore has 2^128 or approximately 3.4×1038 addresses. This would be about 40,000 addresses for every atom on the surface of the earth and almost four /64s per square centimeter of the planet.
    --------

    Even with DigitalOcean's recent growth, I believe handing out a very large block per customer would not terribly affect the global availability of the IP space.

    The current implementation is rather limiting, even though it is definitely a step in the right direction. Thanks for that by the way.

  • gordev commented
    September 11, 2018 17:32

    +1

  • Anonymous commented
    September 11, 2018 17:32

    @Sergey Shepelev

    Your perception of CIDR notation is completely backwards.

  • Craig McQueen commented
    September 11, 2018 17:32

    I'd like to have a separate /64 subnet routed to the droplet's IPv6 address, so I can use it for OpenVPN. The most straight-forward way to configure OpenVPN to use IPv6 is to have a routable /64 subnet that it can use for clients.

    For details see: https://community.openvpn.net/openvpn/wiki/IPv6

  • Luke commented
    September 11, 2018 17:32

    Please please please give every customer their own /64 subnet routable to all droplets in one DC. That's the only thing that makes sense.

    As for utilisation - build it, and they will come! Waiting for IPv6 utilisation to go up before starting to support IPv6 is the self-defeating silly game that everyone has been playing for 10 years.

  • Sergey Shepelev commented
    September 11, 2018 17:32

    Please, do not do this.

    One address is required.
    Some people could use /10 -- that's about 1000 addresses!
    Anything above that is clearly a reason to negotiate with network provider. And why would they (DO) deny, please, have your /20 -- one million addresses. Can you even imagine how to use 10e6 addresses?

    People demanding /64 before they *need* /6 are befuddled with new possibilities.

  • mrjester commented
    September 11, 2018 17:32

    I think you might be misinformed on the size of the v6 address space. Currently, 2000::/3 is allocated for usage. That means we have of 4,611,686,018,427,387,904 /64s to allocate before we need to allocate from 4000::/3. Or even better, giving out /56s to your users, cause heaven forbid they want to have more than one subnet, 9,007,199,254,740,992 /56s to allocate before we need 4000::/3.

    To look at that number a little differently. The IPv4 internet is 2^32 or 4.3 Billion IPs (a lot less when you take out all of the reserved stuff) There are 2,097,152 complete IPv4 internets work of /56s in the 2000::/3 allocation. We have 5.5 more /3s to go after that.

  • Moisey Uretsky commented
    September 11, 2018 17:32

    Our initial roll-out of IPv6 is with a single IP so that we can asses network utilization. We also wanted to collect feedback from customers on use cases for such large IPv6 allocations, certainly it is the industry standard but it also seems eerily reminiscent of what happened with IPv4 with large initial blocks given out to everyone without any clear indicators of why so many were needed.

    Thanks,
    Moisey