Scalable compute services.
Simple object storage.
Run managed Kubernetes clusters.
Tools & Integrations
Automate your infrastructure.
Deploy pre-built applications.
Connect, share and learn
DevOps and development guides
Questions & Answers
Development and systems Q&A
by Justin Ellingwood
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.
@Sergey Shepelev there us somerhing strange about the way you read CIDR a/ 10 of IPv6 has way more than 1000 addresses it actually has 2^(128-10) addresses, so no one Ssignes a costumer that much space (a rir might assign a large isp thst much tho) and according to the standards ( don’t remember the rfc numeratm) the last 64 bits are used to identifi the host, and chuld therefot not be used for further subneting, ie the longes lrefix anyone shuld ever see is a /64, most RIRs recomend thea theair mrmbers (ISPs, hosting companies, karge corps etc) assign their costumers at least most a /56 but they actually do not have to document any reasoning for allocations longer Than /48 Iirc actually for larger multi sit costumers it is not un common for a RIR to kive oyr significantly shorter prefikses and iirc the recomsndation is to use a /48 per site( if tgst is sufficisntly large for your addresing needs. So ket’s say DO gives evry costumer a /56 per dc they would rhen hav the capacety to host 2^(48-56)=65536 coustumers in a dc ( ok afew kess because ther own router switches etc also need addresses) befor needing to dip in to their larger pool of addresses/reguest new ones from the relevant RIR. That is quite a few coustumers isn’t it?
RIR strongly recommends at the VERY least /56 per customer. See https://www.ripe.net/publications/docs/ripe-690
Still no movement on this?
really anything smaller than a /64 breaks IPv6 rules.
Most importantly mail blocks, so we can’t use servers for mail over IPv6
a /64 per account / location would be fine
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.
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.
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.
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.
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
Your perception of CIDR notation is completely backwards.
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.
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.
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.
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.
Note that OpenVPN doesn't support server-ipv6 with anything smaller than a /112.
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.
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.
Having the OPenVPN server-ip <ip>/112 issue, as well.
Real /64 bit networks is a must IMHO.
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.
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!
You won't be notified about changes to this idea.