RFC 1888 (rfc1888) - Page 2 of 16

OSI NSAPs and IPv6

RFC 1888                   OSI NSAPs and IPv6                August 1996


1. General recommendation on NSAP addressing plans

   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 [RFC 1883].

   The majority of known CLNP addressing plans use either the Digital
   Country Code (DCC) or the International Code Designator (ICD) formats
   defined in [IS8348]. A particular example of this is the US
   Government OSI Profile Version 2 (GOSIP) addressing plan [RFC 1629].
   The basic NSAP addressing scheme and current implementations are
   summarised in Annex A.

   [IS8348] specifies a maximum NSAPA (NSAP address) size of 20 bytes
   and some network implementors have designed address allocation
   schemes which make use of this 20 byte address space.

   Other NSAP addressing plans have been specified by the ITU-T for
   public data services, such as X.25 and ISDN, and these can also have
   addresses up to 20 bytes in length.

   The general recommendation is that implementors SHOULD design native
   IPv6 addressing plans according to [RFC 1884], but doing so as a
   natural re-mapping of their CLNP addressing plans. While it is
   impossible to give a general recipe for this, CLNP addresses in DCC
   or ICD format can normally be split into two parts: the high order
   part relating to the network service provider and the low order part
   relating to the user network topology and host computers.

   For example, in some applications of US GOSIP the high order part is
   the AFI, ICD, DFI, AA and RD fields, together occupying 9 bytes. The
   low order part is the Area and ID fields, together occupying 8 bytes.
   (The selector byte and the two reserved bytes are not part of the
   addressing plan.) Thus, in such a case, the high-order part could be
   replaced by the provider part of an IPv6 provider-based addressing
   plan.  An 8-byte prefix is recommended for this case and [RFC 1884]
   MUST be followed in planning such a replacement. The low order part
   would then be mapped directly in the low-order half of the IPv6
   address space, and user site address plans are unchanged.  A 6-byte
   ID field, exactly as used in US GOSIP and other CLNP addressing
   plans, will be acceptable as the token for IPv6 autoconfiguration
   [RFC 1971].

   Analogous rules would be applied for other CLNP addressing plans
   similar to US GOSIP, which is used only as a well known example.



Bound, et. al.                Experimental