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

[Brian E Carpenter]

On 21-Oct-22 14:41, John Day wrote:
> 
> 
>> On Oct 20, 2022, at 17:57, Brian E Carpenter via Internet-history <internet-history at elists.isoc.org> wrote:
>>
>> 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.
> 
> They were all wrong.  It was well-known in the 70s that network addresses should be location-dependent (relative to the graph of the layer) and route-independent. It was realized in the early 80s, that concatenating the lower layer address with the upper layer address made the address route-dependent. It determines the path. Addresses must be path independent. I know it seems like a natural thing to do. It is what we do for filenames and it works quite well. But remember what Multics called a filename:  a pathname. And the separator was quite correctly “>” rather than “/“.  Address spaces in different layers should be independent.

Yes, and that's exactly the case for IPv6. The interface identifier is an opaque bit string whose only job is to be unique on the link. Unlike XNS, Netware and DECnet IV, it does not map by construction to a MAC address *even it it was formed from a MAC address*. There has always been an address resolution stage in IPv6 (it just isn't called ARP).

> 
> There is a way to do what this trying to do that maintains the route-independence while create the location-dependence.
> 
> The important thing for the IPng to have done was to route to where all of the points of attachment come together, i.e., the node. This had been realized as early as 1972 by multiple different groups.

Well, the decision was to route to a specific interface rather the node as a whole, and to allow a node to have as many addresses as it cares to. But that's only a small alteration to the IPv4 model.

For clarity, I should add that IPv6 routing is CIDR all the way down; up to /128 if need be (BCP198/RFC7608). The 64-bit interface identifier is not carved in stone (only soft clay); it only applies on links that *need* an interface identifier.

> 
>>
>>>>
>>>> 	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
>>
> 
> And is the basis of why the US has had a representative democracy, rather than a democracy.  Just to avoid bad decisions like that. From what I saw, it was more mob rule. A sustained flaming that was generating 70 very nasty emails an hour for days if not weeks.
> 
>> I'd say it was a meritocratic process and was based on
>> practical experience of trying and failing to deploy
>> CLNP.
> 
> I have been told by reputable sources that there was more CLNP deployed and operational in 1992 than IPv6 in 2014.

The airline industry among others built a very large private network using CLNP. I don't know the dates for that. But in 1992, we were nowhere near getting the HEP/SPAN DECnets converted to DECnet Phase V/CLNP, because the software wasn't viable. In fact, by the time that was physically possible (1996 or thereabouts), the physicists and space scientists had all switched to TCP/IP. More importantly, there was never a significant public CLNP network.

At the end of 2014, about 5% of Google users were connecting via IPv6. Are you saying that in 1992, there were that many active CLNP users? I'd like to see the raw data.

> 
>>
>>>>      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.
> 
> And a good thing too. The so-called locator/identifier distinction is a false distinction. See Saltzer’s definition of ‘resolve’ a name in his 1977 paper, i.e., to locate an object in a given context given its name. You can’t do one without the other.

Well, you'd better have that argument with the LISP people. RFC9299 through 9306 just came out a few hours ago.

    Brian

> 
> Generally, the graphs of our networks don’t follow a nice regular pattern like Midwest cities (a grid), but they do exhibit levels of clustering down to some granularity. Interpretation of the address is much like interpreting an address on a letter.  World subset to Country subset to State/Province subset to City, then it shifts to linear search for street and linear search for number. For networks, it is similar:  Subsetting works up to a point (CIDR), then it shifts to exhaustive search ‘locally’. In some cases for large networks, subsetting may continue ‘locally.’
> 
> There are basically 4 kinds of semantics for these identifiers:
> 1) local identifier if it is simply point-to-point
> 2) recognition, if it is a multi-access media, e.g. wireless or original Ethernet.
> 3) forwarding-id,* which may be flat for networks small enough that the tables are tractable, and
> 4) true addresses, which are assigned to be location-dependent and route-independent. IOW, inspection of two addresses can determine if they are ’near’ each other for some definition of ’near.’
> 
> * the traditional routing algorithms, e.g., link-state, distance vector, etc, do not use true addresses. Forwarding-ids are merely used to keep track of what nodes in the graph are being referred to in the creating the solution. Encoding a ’nearness’ property in the forwarding-id is not used. (which is why they are forwarding-ids and not true addresses).
> 
>>
>>>>
>>>> 	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 with4
> 
> Sort of. IS8348 is the Network Layer Service Definition. It specifies guidelines for addresses and how different addressing plans are to be accommodated, but it is hardly an addressing plan itself. It does deftly cover up the error in the OSI Model forced on it by the ITU of exposing the address at the layer boundary, e.g., that an NSAP address and a Network-Entity-Title may be identified by the same string.  Some detailed addressing plans were created for it. However, for the most part it was not yet recognized that the rules noted above, i.e., location-dependence (relative to the graph of the layer) and route-independence were not properties of some of these proposals. The addressing plan needs to be an abstraction of the graph of the layer. As we noted above, the upper levels of the hierarchy can be defined overall, but at some point subsequent levels become a regional or local matter.
> 
> OSI did have the advantage, documented in IS8648, of what was essentially the network layer address (called Subnet Access, technology-specific) and an internet address (called Subnet Independent Convergence, which technology-independent and was what CLNP carried.)* It is interesting to note that this was the structure that INWG had adopted in 1975 and was independently arrived at by the group working out IS8648, almost 10 years later. IOW, that an internet model is a common overlay over the specific network technologies, rather than protocol conversion at the boundaries. Unfortunately, the Internet had lost the Internet Layer by the early 80s.
> 
> * In the Saltzer paper of 1982, these are called point of attachment addresses and node addresses.
> 
> As for IPv6, its current state of confusion speaks for itself.  But that's okay, even if they had done it right, it still wouldn’t be enough.
> 
> Take care,
> John Day
> 
>>
>> 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
>>>>
>>> .
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>