Network Working Group                                           J. Bound
Request for Comments: 1888                 Digital Equipment Corporation
Category: Experimental                                      B. Carpenter
                                                                    CERN
                                                           D. Harrington
                                           Digital Equipment Corporation
                                                          J. Houldsworth
                                                     ICL Network Systems
                                                                A. Lloyd
                                                  Datacraft Technologies
                                                             August 1996

                           OSI NSAPs and IPv6

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This document recommends that network implementors who have planned
   or deployed an OSI NSAP addressing plan, and who wish to deploy or
   transition to IPv6, should redesign a native IPv6 addressing plan to
   meet their needs.  However, it also defines a set of mechanisms for
   the support of OSI NSAP addressing in an IPv6 network.  These
   mechanisms are the ones that MUST be used if such support is
   required.  This document also defines a mapping of IPv6 addresses
   within the OSI address format, should this be required.

Table of Contents

      1. General recommendation on NSAP addressing plans..............2
      2. Summary of defined mechanisms................................4
      3. Restricted NSAPA in a 16-byte IPv6 address for ICD and DCC...4
      3.1 Routing restricted NSAPAs...................................5
      4. Truncated NSAPA used as an IPv6 address......................6
      4.1 Routing truncated NSAPAs....................................8
      5. Carriage of full NSAPAs in IPv6 destination option...........9
      6. IPv6 addresses inside an NSAPA..............................10
      7. Security Considerations.....................................11
      Acknowledgements...............................................11
      References.....................................................12
      Annex A: Summary of NSAP Allocations...........................13
      Annex B: Additional Rationale..................................14
      Authors' Addresses.............................................16




 
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 [RFC1883].

   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 [RFC1629].
   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 [RFC1884], 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