Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tri

On 30-mrt-2006, at 6:26, Anthony G. Atkielski wrote:

> > We currently have 1/8th of the IPv6 address space set aside for
> > global unicast purposes ...
> Do you know how many addresses that is? One eighth of 128 bits is a
> 125-bit address space, or
> 42,535,295,865,117,307,932,921,825,928,971,026,432
> addresses. That's enough to assign 735 IP addresses to every cubic
> centimetre in the currently observable universe (yes, I calculated
> it). Am I the only person who sees the absurdity of wasting addresses
> this way?
When I first learned about IPv6 I felt strongly that 128 bits was too  
much, especially since all those bits have to be carried in every IP  
packet twice, once as a source address and once as a destination  
address. However, since that time I've learned to appreciate  
stateless autoconfiguration and the potential usefulness of having  
the lower 64 bits of the IPv6 address as a place to carry some  
limited security information (see SEND and shim6 HBA).
> > ... with the idea that ISPs give their customers /48 blocks.
> Thank you for illustrating the classic engineer's mistake.  Stop
> thinking in terms of _bits_, and think in terms of the _actual number
> of addresses_ available.  Of better still, start thinking in terms of
> the _number of addresses you throw away_ each time you set aside
> entire bit spans in the address for any predetermined purpose.
The trouble is that you need to build in space for growth.  
Unfortunately, at the time IPv6 was created variable length addresses  
weren't considered viable. (In theory CLNP has variable length  
addresses, in practice that doesn't really work out.) And for some  
strange reason, apparently only powers of two were considered as  
address lengths. So the choice was either 64 bits, which is a lot,  
but it doesn't allow for any innovation over the 32 bits we have in  
IPv4, or 128 which does cost 16 extra bytes in every packet, but  
gives us stateless autoconfig and SEND. Now you can argue that 64 or  
48 bits and continuing current IPv4 practices would have been better,  
but given the choice for 128 bits, the current way of using the  
address space makes sense for the most part.
The only thing I'm not too happy about is the current one address /  
one subnet / /48 trichotomy. Ignoring the single address for a  
moment, the choice between one subnet and 65536 isn't a great one, as  
many things require a number of subnets that's greater than one, but  
not by much. For instance, the cell phone as a router example I  
talked about earlier. A /64 and a single address, or two /64s which  
would be a /63 would be more useful there. The idea that we'd use up  
too much address space by giving out /48s doesn't seem like a real  
problem to me, but on the other hand most people don't need a /48 so  
some choice thats < /48 and > 64 makes sense. But a /56 as suggested  
by some people is suboptimal: people with growing networks will at  
some point need more than 256 subnets but at that point they already  
have very many subnets so renumbering then is painful. Making the  
choice between /60 and /48 makes much more sense: just give everyone  
a /60 rather than a /64 just in case they need a handful of subnets,  
which is adequate for 99% of all internet users. People who need more  
than a handful of subnets can get a /48 and won't have to renumber at  
an inconvenient point in the growth curve.
Yes, I know this will use up sixteen times the number of addresses  
for people who really only need a single subnet, but it saves a  
factor 4096 for the people who need 2 - 16 subnets and would have  
gotten a /48 or a factor 16 for the people who would have gotten a / 
56. The extra wasted address space from giving people who really only  
need one subnet a /60 is made up for by the people who would have  
gotten a /48 but can now get by with a /60 if the ratio of one-subnet  
to <17-subnet users is 1 : 4000 or less. (Making the choice /64 vs / 
56 saves even more as long as the ratio is lower than 94 : 6 but  
doesn't have the desireable near-onesizefitsall quality.)
> If you want exponential capacity from an address space, you have to
> assign the addresses consecutively and serially out of that address
> space.  You cannot encode information in the address.  You cannot
> divided the address in a linear way based on the bits it contains and
> still claim to have the benefits of the exponential number of
> addresses for which it supposedly provides.
The thing that is good about IPv6 is that once you get yourself a / 
64, you can subdivide it yourself and still have four billion times  
the IPv4 address space. (But you'd be giving up the autoconfiguration  
advantages.)
Also, when the time comes to create the next version of IP, we won't  
have to worry about all of this to a noticeable degree because IPvA  
or IPvF or whatever can have a different addressing structure that  
can still be expressed as an IPv6-like 128 bit number for backward  
compatibility with IPv6, which isn't possible today because IPv6's  
128 bits can't be expressed as an IPv4-like 32 bit number.
> > It's generally accepted that an HD ratio of 80% should be reachable
> > without trouble, which means we get to waste 20% of those bits in
> > aggregation hierarchies.
> No. It's not 20% of the bits, it's 99.9756% of your address space that
> you are wasting.
I'm not a huge fan of the HD ratio either, because it substitues a  
rule of thumb for actual knowledge. But the point is that EVEN if you  
waste 99.9756% in this way we STILL have enough addresses to give  
every person living on the planet when the population hits its peak  
several /48s which are wasteful in their own right.
So while I wouldn't want to take away your right to begrudge the way  
all of this is done in IPv6, I must object to your conclusion that  
we'll run out of IPv6 soon, for any reasonable value of "soon".
> Do engineers really study math?
Just the simple stuff.

> That's another problem of engineers: they think they can predict the
> future, and they are almost always wrong.
I hope good engineers don't think that, but it's certainly true that  
as a rule, the future doesn't match what was predicted earlier.  
Engineers should build stuff that still works reasonably well even if  
they get their predictions wrong.
Unfortunately the people who want non-aggregatable provider  
independent addressing can't seem to understand that.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf