ietf
[Top] [All Lists]

Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)

2006-03-30 22:12:54
Stephen Sprunk writes:

An IPv4/6 address is both a routing locator and an interface identifier.

And so engineers should stop saying that n bits of addressing provides
2^n addresses, because that is never true if any information is
encoded into the address.  In fact, as soon as any information is
placed into the address itself, the total address space shrinks
exponentially.

Unfortunately, the v6 architects decided not to separate these into
separate address spaces, so an address _must_ contain routing
information until that problem is fixed. It doesn't seem to be
likely we'll do so without having to replace IPv6 and/or BGP4+, and
there's no motion on either front, so we're stuck with the
locator/identifier problem for quite a while.

Then we need to make predictions for the longevity of the scheme based
on the exponentially reduced address space imposed by encoding
information into the address.  In other words, 128 bits does _not_
provide 2^128 addresses; it does not even come close.  Ultimately, it
will barely provide anything more than what IPv4 provides, if current
trends continue.

That's why 85% of the address space is reserved.  The /3 we are using (and
even then only a tiny fraction thereof) will last a long, long time even
with the most pessimistic projections.  If it turns out we're still wrong
about that, we can come up with a different policy for the next /3 we use.
Or we could change the policy for the existing /3(s) to avoid needing to
consume new ones.

Or simply stop trying to define policies for an unknown future, and
thereby avoid all these problems to begin with.

It's been a decade since we started and we're nowhere near using up the
first /3 yet, so it appears we're in no danger at this point.

As soon as you chop off 64 bits for another field, you've lost just
under 100% of it.

Variable-length addresses only work if there is no maximum length.

Ultimately, yes.  But there is no reason why a maximum length must be
imposed.

E.164 has a maximum of 15 digits, meaning there are at most 10^15
numbers. Here in +1 we only use eleven digit numbers, meaning we're
burning them 10^4 times as fast as we could. That's not a great
endorsement.

Telephone engineers make the same mistakes as anyone else; no natural
physical law imposes E.164, however.

Also, telephone numbers have the same locator/identifier problem
that IPv4/6 addresses do. In fact, IPv6's original addressing model
looked strikingly similar to the country codes and area/city codes
(aka TLAs and NLAs) that you're apparently fond of.

Maybe the problem is in trying to make addresses do both.  Nobody
tries to identify General Electric by its street address, and nobody
tries to obtain a street address based on the identifier General
Electric alone.

The difference is that in IPv6, it's merely a convention ...

Conventions cripple society in many cases, so "merely a convention"
may be almost an oxymoron.

The folks who designed IPv4 definitely suffered from that problem.  The
folks who designed IPv6 might also have suffered from it, but at least they
were aware of that chance and did their best to mitigate it.  Could they
have done better?  It's always possible to second-guess someone ten years
later.  There's also plenty of time to fix it if we develop consensus
there's a problem.

Sometimes the most important design criterion is ignorance.  In other
words, the best thing an engineer can say to himself in certain
aspects of design is "I don't know."



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>