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.
Zachary DuBois commented
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.
I suggest one /64 per droplet aggregated to one /56 per account and DC.
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
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
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
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
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.
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.
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
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
Having the OPenVPN server-ip <ip>/112 issue, as well.
Real /64 bit networks is a must IMHO.
Kristian Hermansen commented
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.
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.
Note that OpenVPN doesn't support server-ipv6 with anything smaller than a /112.
Justin Coffman commented
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.
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.
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.
I think people here are greatly understating how vast the IPv6 space is.
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.
Your perception of CIDR notation is completely backwards.