IPv6 Ignorance

Tue Sep 18 14:01:13 UTC 2012

On Sep 17, 2012, at 23:35 , William Herrin <bill at herrin.us> wrote:

> On Mon, Sep 17, 2012 at 2:16 PM, Owen DeLong <owen at 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