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.
Ben Speakman commented
Please this is a must and so easy to implement. There is no reason not to give out /64
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
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, 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.
Oh well, guess I'll be checking out AWS' recently announced support for ipv6 in certain regions of EC2... :(
Jeremy Tribby commented
Unbelievable. /64 is RFC. This isn't a political decision. DigitalOcean is intentionally going against spec for no reason.
Craig McQueen commented
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!
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.
Holger Schinzel commented
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!)  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. 
 "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:"
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
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.
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....
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.
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).
We need a IPv6/48 block. Happily if I find better. I'll switch...
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.