[ih] IPng history [was: Notification to list from IETF Moderators team]

Brian E Carpenter brian.e.carpenter at gmail.com
Thu Oct 20 14:57:35 PDT 2022


Hi,

A rather provocative message over at the IETF has been
bugging me for the last week, and I thought that here
might be a better place to correct the record. Of course,
Scott's comment is correct, and there's a whole book about
it (ISBN 9780201633955).

I naturally don't mind people who have deep objections
to the design of IPv6, but we do need historical accuracy.
On 15-Oct-22 02:28, Scott Bradner wrote:
> 
> 
>> On Oct 14, 2022, at 8:47 AM, Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp> 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.

In fact I believe the direct inspirations for the original form
of IPv6 interface identifier based on MAC addresses were Novell
Netware and DECnet Phase IV**, both of which were very widely and
successfully deployed in 1994. IPv6 generalised the concept by
defining that part of the address as an interface identifier,
with the MAC address model as the first (and now deprecated)
format. See RFC7136 and RFC8064.

This was not a layer violation. Address resolution in IPv6
is a function that dynamically discovers the layer 2 address
corresponding to a given layer 3 address.

** DECnet IV did it backwards - it set the MAC address to match
the DECnet layer 3 address, not the other way round.

>>
>> 	2) Though IAB tried to force IETF to accept CLNP
>> 	(developed by OSI) as an alternative for IPv4, 

True, and that was the end of the old IAB.

>>      it was
>> 	denied by democratic process in IETF 

I'd say it was a meritocratic process and was based on
practical experience of trying and failing to deploy
CLNP.

>>      and a project to
>> 	develop IPng, which should be different from CLNP, was
>> 	initiated in IETF.

No, CLNP (i.e. TUBA) was one of the three main contenders
for adoption as IPng.

>> 	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

There were a whole bunch of proposals and attempts to
combine ideas. A very complex story, which is why there's
a whole book about it as well as RFC1752.

It is correct that SIP started with 64 bit addresses that
did not include an interface identifier. But the latter
was added during the design process.

>> 	(though such mergers usually result in worse results
>> 	than originals).
>>
>> 	4) then, all of a sudden, a closed committed of
>> 	IPng directorates 

Yes, following an inconclusive BOF at IETF 27, the IESG
decided to convene an ad hoc Directorate. But all the drafts
we considered were public, as far as I know, although the
I-D mechanism was clunky in those days and not every draft
has survived. Scott was too modest above to mention his
excellent archive: https://www.sobco.com/ipng/archive/

>>      decided that address should be
>> 	16B long to revive an abandoned, with reasons,
>> 	address structure of XNS, which is not a
>> 	democratic process.

The idea of adding an explicit interface identifier
(originally 48 bits, soon expanded to 64 bits) was not
a clone of XNS, Netware, or DECnet IV. It was actually
an architectural innovation, more so than we realised
at the time. We could perhaps have gone further by
making the locator/identifier split even stronger, but
we didn't.

>>
>> 	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...

I can't interpret that statement. There was certainly no
intention that the high order bits would be "all zero".
We did not design IPv6 as IPv4 with bigger addresses.

>>
>> 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's true that Ohta-san and Bill Simpson were dissenters.
So, in a sense, were the proponents of TUBA and CATNIP.
There could only be one consensus, so some ideas were
inevitably rejected.

>>
>> 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.

That's absurd. I can tell you the exact reason we did RFC1988.
I drafted the guts of it sitting on a park bench on University
Avenue in Toronto shortly after the IPv6 proposal was announced in
plenary at IETF 30. This was 1994, when OSI was still very much
alive politically (although not much in reality) and we needed
to avoid a political row with various government funding agencies.
US GOSIP was still a (theoretical) requirement for many agencies.
As the RFC says:

    This recommendation is addressed to network implementors who have
    already planned or deployed an OSI NSAP addressing plan for the usage
    of OSI CLNP [IS8473] according to the OSI network layer addressing
    plan [IS8348] using ES-IS and IS-IS routing [IS9542, IS10589].  It
    recommends how they should adapt their addressing plan for use with
    IPv6 [RFC1883].

That's all, and it was an Experimental RFC, obsoleted in 2005,
by which time its political purpose had gone away.

Regards,
     Brian

>>
>> 					Masataka Ohta
>>
> 
> .



More information about the Internet-history mailing list