This sub-thread continues here: https://elists.isoc.org/pipermail/internet-history/2022-October/008299.html (very interesting answer from Brian.) On Fri, Oct 14, 2022 at 09:28:20AM -0400, Scott Bradner wrote: > > > > On Oct 14, 2022, at 8:47 AM, Masataka Ohta <mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > ... > > there are a number of inaccuracies in the text below - see RFC 1752 for a more detailed description of the > process > > Scott > > > An important point of the thread is why IPv6 address is > > so lengthy. And the history around it recognized by the > > thread with my understanding is that: > > > > 1) There was a L3(?) protocol called XNS, which use L2 > > address as lower part of L3 address, which is layer > > violation, which disappeared and IPv4 won the > > battle at L3. > > > > 2) Though IAB tried to force IETF to accept CLNP > > (developed by OSI) as an alternative for IPv4, it was > > denied by democratic process in IETF and a project to > > develop IPng, which should be different from CLNP, was > > initiated in IETF. > > > > 3) the project resulted to choose SIP, which has 8B > > address, as the primary candidate for IPng though > > some attempt to merge it with other proposals > > (though such mergers usually result in worse results > > than originals). > > > > 4) then, all of a sudden, a closed committed of > > IPng directorates decided that address should be > > 16B long to revive an abandoned, with reasons, > > address structure of XNS, which is not a > > democratic process. > > > > 5) we, including me, was not aware that 16B address > > is so painful to operate, partly because I hoped > > most initial bit can be all zero. But... > > > > That is the recently recognized history of IPv6 and most, if > > not all. of my points in it can be confirmed by the link for > > a mail from Bill Simpson. > > > > It should also be noted that unnecessarily lengthy address > > of IPv6 may be motivated to revive CLNP addressing against > > the democratic process. See rfc1888 for such a proposal. > > > > Masataka Ohta > > -- --- tte@xxxxxxxxx