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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf