[ppml] IPv6>>32

Tony Hain alh-ietf at tndh.net
Mon May 9 17:26:09 EDT 2005

Geoff Huston wrote:
> >Burning through a /4 in 50 years is consistent with original assumptions,
> as
> >is the point that we have 3/4 of the space set aside for different
> >allocation approaches if the first proved wrong. It is not that people
> >didn't learn anything from the first time around, it is just that some
> want
> >to be more conservative than others.
> The IPv6 roundtable presentation at ARIN XV explicitly placed quite a high
> level of uncertainly on that number of cumulative consumption Tony, and
> the
> presentation explicitly noted that the outcome was somewhere between a /1
> and a /4. Not, that's not a /4, that's somewhere between a /1 and a /4.

Yes there is uncertainty, as there has been all along. That was part of the
point of starting with 1/8th and allowing for different approaches if time
proved the first attempt to be wrong. The current discussions seem to be
more focused on 'we have to get this right the first time to last for 100
years' than they are on the reality that we don't and can't know what it
will take to deal with the network of 100 years from now. 

> Also, just to be mathematically on the right track here a /4 is 1/16 of
> the
> number space, while a /2 is one quarter of the address space. So, to
> rephrase your comment, if the cumulative consumption is a /4 then there is
> 15/16ths of the space that could, in theory, be used for different
> allocation approaches.

I was not trying to nail down every last block because we have already
defined parts of 0/4, and f/4 so in the big picture there is essentially
only 6/8's worth of space without any issues. 

> However, its sensible to also note that if we think that "installed base"
> is an argument today in terms of the pain associated with changing the 64
> bit length for the device identifier, just wait until the installed base
> of
> end sites gets to the 30 billion mark that is commensurate with a /4
> consumption under current policies. Now 30 billion end sites  is _really_
> an installed base, and its inertial impetus would say to me that at that
> stage your wriggle room for the remaining space is pretty much a lost
> opportunity. So if we are having trouble now in looking at the global
> identifier on the basis of the inertial mass of already deployed systems
> and services, then you cannot also put forward the proposition that we can
> change things once we've deployed 30 billion end site instances of the
> same.

I am not suggesting we change 2000::/3 ever. On the other hand we would not
have to change protocol versions to adjust the allocation policies for other
/3 prefixes.

> So I'm afraid that "we've still got future wriggle room in the future so
> don't worry about it now" is not an approach that I can accept easily - if
> at all. At that point the late comers will be complaining that they are
> exposed to tougher and more constrained policies that are deployed at a
> higher cost than that of the early adopters - and if all this sounds
> hauntingly familiar in reference to the current debates about national
> interests and highly populous economies and various address policy
> frameworks, then it should. I'm afraid that there's an increasing cynicism
> out there about the refrain of "don't worry we'll fix it once its visibly
> broken" with respect to address policies. We should at this point be
> striving to instill some broad confidence in the proposition that we can
> provide a stable and enduring platform for the world's communications
> needs.

By your own numbers changing the H-D policy would get us to centuries in the
current /3, then folding in the non-technical business desires to
differentiate based on prefix length we are talking about multiple millennia
still using the 64/64 split. At what point do you think people will want a
new protocol for non-address consumption reasons? IPv6 is a good protocol
but it will not be in use in 1000 years because there will be plenty of
reasons to change it (including that engineers just can't resist their need
to tinker). Manage the space, but conservation that stifles innovation is
both unnecessary and fundamentally wrong. 


More information about the ARIN-PPML mailing list