Summary

  • RFC 1888 defined four elective ways to carry NSAP and IPv6 address information, but first advised operators to redesign old plans natively for IPv6.
  • Its own warnings showed why reversible encoding was not routing equivalence: an OSI Area might span several links, unlike an IPv6 subnet; mixed prefixes resisted aggregation; and host-wide NSAP identity did not become per-interface IPv6 identity.
  • RFC 4048 later retired the apparently unused NSAP-in-IPv6 mechanisms while isolating two errors in the inverse mapping; RFC 4548 corrected only that narrow IPv6-in-NSAPA namespace.

The envelope was not the architecture

In August 1996, RFC 1888 offered an Experimental set of mappings between OSI NSAP addresses and IPv6. Its status matters: the memo did not specify an Internet Standard. More revealingly, its first practical recommendation was not to preserve the old wire image. Where an organisation had planned or deployed an OSI address scheme, it should design a native IPv6 plan and remap the local topology where possible.

The warning preceded the compatibility machinery because the two address families did not divide the network in the same way. In OSI routing, an Area could cover several physical links. IPv6 treated a subnet as one link. Copying an Area number into an IPv6 subnet field therefore produced a neat numerical correspondence without proving that neighbours shared a link or that the last router knew how to reach the right end system.

Aggregation created a second mismatch. Wide-area routing gains scale when addresses share a prefix that can be advertised as one route. Normal IPv6 addresses and the restricted NSAPA-derived addresses in RFC 1888 did not automatically share such a prefix. A mapping could be lossless one address at a time while multiplying the routes needed to reach the population.

Identity was the third fault line. An OSI end system could hold several NSAPs that identified the host across interfaces. IPv6 assigns addresses to interfaces. Moving a host-wide identifier into an interface-address architecture did not select the interface on which the destination could actually be reached. RFC 1888 also left migration of ES-IS and IS-IS routing infrastructure outside its scope. The address recipe did not bring the control plane with it.

Four mechanisms, four unfinished hand-offs

The first mechanism placed a restricted ICD- or DCC-format NSAPA into a sixteen-byte IPv6 address beginning with 0x02. Within the permitted subset the operation was algorithmic and reversible. Yet the memo warned that routing could be inefficient and that an Area containing several physical subnets needed an additional mechanism. The decoder could recover the old address; a router still lacked the missing topology rule.

The second mechanism began an IPv6 address with 0x03 and carried a truncated NSAPA. The retained hierarchy might route a packet toward the right Area, but the edge still needed the complete destination. RFC 1888 required either a full NSAPA destination option or an encapsulated CLNP packet. At the receiver, local policy and implementation had to forward, decapsulate or discard. Automated final discovery was not defined; static mappings or a future ES-IS-like mechanism were merely possibilities.

That gap affected failure evidence too. Ordinary autoconfiguration and discovery did not work unchanged. Full NSAPAs could not simply be inserted into IPv6 routing headers. An ICMP error addressed to the truncated source could be discarded instead of reaching the actual origin. A path might therefore fail precisely where the diagnostic chain had lost the identity required to explain it.

The third mechanism kept a normal IPv6 address and attached a complete source or destination NSAPA option for the receiver to interpret. Nodes that did not use the feature were not required to implement it. Presence of the option therefore proved that a sender supplied data, not that an intermediate or destination node understood, enabled or acted on it.

The fourth direction reversed the nesting. It put an IPv6 address inside a twenty-octet NSAPA under IANA AFI 35 and an Initial Domain Identifier, or ICP. RFC 1888 assigned ICP zero to IPv6. It also prohibited recursive embedding: repeatedly placing one address family inside the other could create anomalies or loops of the kind discussed in RFC 1326.

Earlier context helps delimit the proposal. RFC 1629 described NSAP use over ATM, while RFC 3513 later specified IPv6 addressing architecture. Neither turns an RFC 1888 mapping into deployment evidence. They define neighbouring structures against which the experiment can be read.

Retirement separated non-use from specification error

Nine years later, RFC 4048 made two different judgments. As far as the IETF knew, it said, the NSAP-inside-IPv6 mappings had never been seriously used and were not supported by IPv6 implementations. That is a carefully attributed institutional assessment, not a census of every private implementation. It justified recommending Historic status and returning the former NSAP IPv6 prefix allocation to Reserved.

The inverse IPv6-inside-NSAPA mechanism was treated separately because it had recently attracted interest, including possible ATM use. Here the problem was not merely apparent non-use. Section 6 of RFC 1888 contained two errors about the external namespace. The ICP field was sixteen bits—two octets—not a single third octet. Its four-decimal-digit IDI was encoded as two octets of binary-coded decimal, not as an unrestricted binary integer.

This distinction prevented an overly broad verdict. RFC 4048 did not say that every mapping equation in RFC 1888 was arithmetically false. It said that one family appeared unused and that the inverse section needed an accurate replacement. IANA held the ICP registry in abeyance while that replacement was prepared.

RFC 4548 supplied it in 2006. Under AFI 35, decimal ICP zero identifies the published IPv6 format and ICP one the IPv4 format; values 2 through 9999 remain available only with a defined, published format and IETF consensus. The present IANA OSI NSAPA Numbers registry records those meanings. Its rows prove namespace assignments, not parsers, enabled features, routes or packets.

RFC 4548 replaced only section 6. It did not revive restricted or truncated NSAPAs inside IPv6. The repair preserved a narrow code-point function after the surrounding experiment became Historic. That is the useful ending: standards maintenance can salvage a legitimate namespace need without pretending that an obsolete architecture returned.

The RFC Editor information pages for RFC 1888, RFC 4048 and RFC 4548 preserve their status and update relationships. Together with the underlying texts, they establish a receipt ladder: a document may define a plan; an algorithm may preserve its bytes; IANA may register a meaning; software may parse it; policy may enable it; routing may deliver it; a receiver may accept it; and observation may establish use. No rung certifies the next.