On Sep 17, 2012, at 23:35 , William Herrin <bill@herrin.us> wrote:
On Mon, Sep 17, 2012 at 2:16 PM, Owen DeLong <owen@delong.com> wrote:
We thought 32 bits was humongous in the context of a research project that would connect universities, research institutions and some military installations.
In that context, 32 bits would still be humongous.
Our estimation of humongous didn't change, the usage of the network changed dramatically. The experiment escaped from the laboratory and took on a life of its own. Once that happened, the realization that 32 bits wasn't enough was very nearly immediate.
The IPv6 address space offers 61 bits of network numbers each of which holds up to 64 bits worth of hosts. Obviously you never want to fill one of those subnets (nor could you with any available hardware), but it means that you don't have to waste time thinking about rightsizing network assignments.
Hi Owen,
We think 64 bits is humongous on an IPv4 Internet where autoconfiguration is rarely bordering never larger than a single LAN.
But, we want the fridge to get a /64 from the home automation controller for its internal sensor network. Which means the home automation controller will be holding something around a /58 or so in order to accommodate the various smart devices in the house. Which means the the cable router will be holding a /54 or more to accommodate the server lan, the home automation delegation, the PC lan, the VM delegation, the wifi lan, etc. And at a customer boundary we'll only break at a nibble boundary, so that brings us to /52. Which is inconvenient since we often have larger users so we'll just break at /48 for everybody.
Correct.
Then we need 32 bits to overlay the customer's IPv4 address for convenience within our 6RD network. So that leaves us 16 bits. But we don't want the native network to overlay the 6RD network because we want a real simple /16 route into the nearest 6rd encapsulator. And we don't want to advertise multiple BGP prefixes either. So we claim another bit and allocate our native infrastructure from the /16 that doesn't overlap the 6rd setup.
No, you really don't. This absurdity (and the ridiculous design of 6RD) are so problematic in this area that I cannot begin to describe what a terrible idea it is.
3 bits are held in reserve at the top; only 2000::/3 is available for public Internet use. So that drops us from 15 to 12 bits. Now we want to organize the BGP backbone and we've 12 bits left to work with. That's 4 bits less than the number of autonomous systems participating in BGP on Internet today.
Again, if you take the 6RD mess out of the equation and don't saddle IPv6 with this IPv4 baggage, this is a non-issue.
Of course this is in many ways a straw man. And I'm picking on you Owen because in the past you've advocated both /48's for end users and 6rd justifying 32 bits of allocation above that from the registry. But really, with the right (or maybe I mean wrong) hierarchic network auto-configuration technologies it's not hard to imagine how the IPv6 address space could be exhausted in 20 years.
I still advocate /48s and I have never advocated 6RD as a permanent solution, nor have I advocated giving ISPs /16s in support of 6RD. I have supported policy to allow for temporary allocations in support of 6RD giving customers more limited (/56) prefixes due to the constraints of 6RD, however, I have consistently referred to this as a degraded form of IPv6. Owen