Credit to Digital Ocean for ipv6 offering

Laszlo Hanyecz laszlo at
Thu Jun 19 18:04:35 UTC 2014

On Jun 19, 2014, at 12:18 PM, "STARNES, CURTIS" <Curtis.Starnes at> wrote:

> At 18,446,744,073,709,551,616 per /64, that is a lot of address.
> Right now I cannot get IPv6 at home so I will take getting "screwed" with a /56 or /60 and be estatic about it.
> Curtis

Would be nice if everyone kept it simple and just stuck to /48s though.

It's complicated enough without everyone deploying different prefix sizes.  Even the /64 net/host split isn't standard enough.  Think of something like DHCP - if there's an understanding that it's 'standard' then you can build software/hardware around this assumption and provide an easy to use system, without forcing the user to make sub-netting decisions.  Making software that works with this necessarily has to involve a complex UI and if certain unusual combinations don't work then people cry that it doesn't support IPv6.

The way that it's standard to receive one IPv4 address by DHCP and you can just plug in a laptop, imagine if in a few years it was standard to receive a /48 IPv6 prefix on the local router and end user devices can request as many /64s as they want.  You could assign a /64 to each app on your cell phone or computer.. and this could happen automatically when possible.  Maybe an app wants many /64s, that's fine too.  We've gotten used to multiplexing everything onto a single overloaded address because it's a scarce resource.  In IPv6 addresses are not scarce and in time this can be leveraged to simplify applications.  Yes, you can overload a single address, we do it all the time in IPv4 with proxies and NATs.  There are even hacks for having multiple SSL websites on one IPv4 address.  These things came about because the addresses are scarce but it's not correct to use the same justifications in IPv6 where the unique addresses are practically unlimited.

If we have to assume that /64s might be scarce and they have to be manually managed, then applications end up having to ask that question and configuration becomes complex.  If we know we can get at least a few hundred of them dynamically anywhere we go, then we only have to bother the user when we run out, and things 'just work'.


More information about the NANOG mailing list