Steve,
On Feb 16, 2012, at 6:46 PM, Steven Bellovin wrote:
On Feb 16, 2012, at 8:30 39PM, Masataka Ohta wrote:
Steven Bellovin wrote:
Thus, IPv6 was mortally wounded from the beginning.
The history is vastly more complex than that. However, this particular
decision
was just about the last one the IPng directorate made before reporting back
to
the IETF -- virtually everything else in the basic IPv6 design had already
been agreed-to.
I understand that, unlike 64 bit, 128 bit enables MAC based
SLAAC with full of states, which is as fatal as addresses
with 32 hexadecimal characters.
That decision came later. In fact, the deficiencies of relying on MACs were
discussed quite frequently in the directorate.
And that's why the standard allows for other types of identifiers to be used to
create Interface Identifiers.
I don't think this was "the" wrong decision.
Isn't it obvious that, with a lot more than 1% penetration of the
Internet to the world today, we don't need address length much more
than 32 bits?
No. I did and I do think that 64 bits was inadequate.
Why? Apart from the fact that if this transition is painful, the next
one will be well-nigh impossible, having more bits lets us find creative
ways to use the address space. Stateless autoconfig is one example,
though I realize it's controversial. ID/locator split, which I've been
a proponent of for very many years, works a lot better with more bits,
because it allows topological addressing both within and outside an
organization.
To confirm what your are saying about an ID/locator split in IPv6, that the
other reason why we went with 128-bit address with a 64/64 split as the common
case and defining IIDs that indicate if they have global uniqueness. This
creates a framework that an ID/locator split could be implemented.
Opinions vary if ID/locator split is useful, but we have a framework that would
allow it without having to roll out another version of IP. A win IMHO.
Bob
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf