Closure?

[Brian E Carpenter]

"J. Scott Marcus" wrote:
...
> As you may recall, I was one of the people who spoke up after Brian's talk
> at our last Public Policy meeting.
> 
> Actually, I support the IAB/IESG recommendation, in general.  There are two
> aspects that trouble me, and I would like to see these made clear to the
> IAB and IESG:
> 
> 1) the recommendation is too glib in a number of its assumptions (see below).

You know, I don't think the frame of mind was glib when we wrote it. Personally,
I thought long and hard about the question of whether we were repeating the
error of the orginal 8+24 layout of IPv4 addresses or the 3 class model
(you could argue that we would be in much less trouble today if addresses
had been classless from the start, but let's not go down that rathole).
But then I ran the numbers and saw that they are really, really big 
numbers. I honestly don't think that is glib.

> 
> 2) the IAB and IESG had jolly well better remember that, if we do this,
> there are few if any additional bits to be given away!

True. 

> 
> As far as assumptions:  The recommendation states that the allocation
> efficiency for the 45 usable high order bits needs to remain above 0.22 in
> order to provide a /48 to everyone expected to be on the planet in 2050,
> and that the telephone system already exceeds this.
> 
> >  - RFC 1715 defines an "H ratio" based on experience in address space
> >    assignment in various networks.  Applied to a 45 bit address space,
> >    and projecting a world population of 10.7 billion by 2050 (see
> >    http://www.popin.org/pop1998/), the required assignment efficiency
> >    is log_10(1.07*10^10) / 45 = 0.22.  This is less than the
> >    efficiencies of telephone numbers and DECnetIV or IPv4 addresses
> >    shown in RFC 1715, i.e., gives no grounds for concern.
> 
> In fact, it probably IS plenty.  But it is important to remember the
> implication:  That addresses within the initial 45 usable bits will be
> assigned fairly densely.  The H ratio for the RIGHTHAND 80 bits of the IPv6
> address is approximately zero -- not a sustainable example for the LEFTHAND
> bits to follow.

Absolutely correct. Sparse assignments would be a mistake. Do you think
this should be stated somehow? Send words...

> 
> Some IPv6 proponents like to claim that the protocol could uniquely address
> every electron in the universe.  It's important to remember that the
> EFFECTIVE capacity of IPv6 reflects only 45 bits of addressability.  The
> other 83 have already been wasted by the current recommendations.

Well, it's not quite that bad - as you observe, some subscribers will actually
get /64s and even they could run a single level of LAN - and some of the
/48's will be used by pretty large corporate networks. But I agree,
the electrons argument is a bit silly.


> 
> Are the remaining 45 bits enough?  Yes, probably.  But we need to be honest
> with ourselves.
> 
> >  - We are highly confident in the validity of this analysis, based on
> >    experience with IPv4 and several other address spaces, and on
> >    extremely ambitious scaling goals for the Internet amounting to an
> >    80 bit address space *per person*.  Even so, being acutely aware of
> >    the history of under-estimating demand, we have reserved more than
> >    85% of the address space (i.e., the bulk of the space not under the
> >    Aggregatable Global Unicast Address (TLA) format prefix).
> >    Therefore, if the analysis does one day turn out to be wrong, our
> >    successors will still have the option of imposing much more
> >    restrictive allocation policies on the remaining 85%.
> 
> If we reach this scenario within our childrens' lifetime, we will have failed.

Agreed. This really isn't what we expect.

> 
> The assumption that this migration entails only the implementation of new
> allocation policies is flawed.  Much of the deployed gear -- perhaps most
> of it -- will break if this happens.

Well, we could argue that point. If people do clean implementations it shouldn't
be the case. But sloppy implementations are another question.

> 
> Again, the recommendation is probably workable.  I am worried about the
> underlying overconfidence.

If there is that tone in the text, it should be trimmed out.

   Brian