On Sep 17, 2012, at 23:35 , William Herrin <b...@herrin.us> wrote: > On Mon, Sep 17, 2012 at 2:16 PM, Owen DeLong <o...@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
