rfc1888.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

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



Bound, et. al.                Experimental                      [Page 1]

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
   plan.  An 8-byte prefix is recommended for this case and [RFC1884]
   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
   [RFC1971].

   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                      [Page 2]

RFC 1888                   OSI NSAPs and IPv6                August 1996


   Three warnings must be carefully considered in every case:

   1. The ES-IS/IS-IS model employs a routing hierarchy down to the Area
   level, but not all end systems in an Area need to be in the same
   physical subnet (on the same "wire" or "link"). IS routers on
   different links within a given Area exchange information about the
   end systems they can each reach directly.  In contrast, the IPv6
   routing model extends down to the subnet level and all hosts in the
   same subnet are assumed to be on the same link. In mapping a CLNP
   addressing plan into IPv6 format, without changing the physical
   topology, it may be necessary to add an extra level of hierarchy to
   cope with this mismatch. In other words, the Area number cannot
   blindly be mapped as a subnet number, unless the physical network
   topology corresponds to this mapping.

   2. It is highly desirable that subnet addresses can be aggregated for
   wide area routing purposes, to minimise the size of routing tables.
   Thus network implementors should ensure that the address prefix used
   for all their subnets is the same, regardless of whether a particular
   subnet is using a pure IPv6 addressing scheme or one derived from a
   CLNP scheme as above.

   3. Some hosts have more than one physical network interface.  In the
   ES-IS model, an end system may have more than one NSAP address, each
   of which identifies the host as a whole.  Such an end system with
   more than one physical interface may be referenced by any one of the
   NSAPs, and reached via any one of the physical connections.  In the
   IPv6 model, a host may have multiple IPv6 addresses per interface,
   but each of its physical interfaces must have its own unique
   addresses. This restriction must be applied when mapping an NSAP
   addressing plan into an IPv6 addressing plan for such hosts.

   This document does not address the issues associated with migrating
   the routing protocols used with CLNP (ES-IS or IS-IS) and transition
   of their network infrastructure.
















Bound, et. al.                Experimental                      [Page 3]

RFC 1888                   OSI NSAPs and IPv6                August 1996


2. Summary of defined mechanisms

   This document defines four distinct mechanisms.  All of these are
   ELECTIVE mechanisms, i.e. they are not mandatory parts of an IPv6
   implementation, but if such mechanisms are needed they MUST be
   implemented as defined in this document.

      1. Restricted NSAPA mapping into 16-byte IPv6 address
      2. Truncated NSAPA for routing, full NSAPA in IPv6 option
      3. Normal IPv6 address, full NSAPA in IPv6 option
      4. IPv6 address carried as OSI address

   To clarify the relationship between the first three mechanisms, note
   that:

      If the first byte of an IPv6 address is hexadecimal 0x02 (binary
      00000010), then the remaining 15 bytes SHALL contain a restricted
      NSAPA mapped as in Chapter 3 below. The term "restricted" is used
      to indicate that this format is currently restricted to a subset
      of the ICD and DCC formats.

      If the first byte of an IPv6 address is hexadecimal 0x03 (binary
      00000011), then the remaining 15 bytes SHALL contain a truncated
      NSAPA as described in Chapter 4 below. EITHER a destination option
      containing the complete NSAPA of any format, as described in
      Chapter 5 below, OR an encapsulated CLNP packet, SHALL be present.

      With any other format of IPv6 address, a destination option
      containing a complete NSAPA, as defined in Chapter 5 below, MAY be
      present.

3. Restricted NSAPA in a 16-byte IPv6 address for ICD and DCC

   Some organizations may decide for various reasons not to follow the
   above general recommendation to redesign their addressing plan.  They
   may wish to use their existing OSI NSAP addressing plan unchanged for
   IPv6. It should be noted that such a decision has serious
   implications for routing, since it means that routing between such
   organizations and the rest of the Internet is unlikely to be
   optimised. An organization using both native IPv6 addresses and NSAP
   addresses for IPv6 would be likely to have inefficient internal
   routing.  Nevertheless, to cover this eventuality, the present
   document defines a way to map a subset of the NSAP address space into
   the IPv6 address space. The mapping is algorithmic and reversible
   within this subset of the NSAP address space.






Bound, et. al.                Experimental                      [Page 4]

RFC 1888                   OSI NSAPs and IPv6                August 1996


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 0-3  |0 0 0 0 0 0 1 0| AFcode| IDI (last 3 digits)   |Prefix(octet 0)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4-7  |             Prefix (octets 1 through 4)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8-11 | Area (octets 0 and 1)         |  ID (octets 0 and 1)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12-15|             ID (octets 2 through 5)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The AFcode nibble is overloaded, and encoded as follows

       0000-1001      Implied AFI value is 47 (ICD)
       (0-9 decimal)  AFcode is first BCD digit of the ICD
                      IDI is last three BCD digits of the ICD

       1010           Implied AFI value is 39 (DCC)
       (hex. A)       IDI is the three BCD digits of the DCC

       1011-1111      Reserved, not to be used.
       (hex. B-F)

   The NSEL octet is not included. It is of no use for TCP and UDP
   traffic.  In any case where it is needed, the mechanism described in
   the next chapter should be used.

   The longest CLNP routing prefixes known to be in active use today are
   5 octets (subdivided into AA and RD fields in US GOSIP version 2).
   Thus the semantics of existing 20-octet NSAPAs can be fully mapped.
   DECnet/OSI (Registered Trade Mark) address semantics are also fully
   mapped.

   It is expected that hosts using restricted NSAPAs could be configured
   using IPv6 auto-configuration [RFC1971], and that they could use
   normal IPv6 neighbour discovery mechanisms [RFC1970].

   Restricted NSAPAs, assuming that they can be fully routed using IPv6
   routing protocols, may be used in IPv6 routing headers.

3.1 Routing restricted NSAPAs

   As mentioned in Chapter 1, there is a mismatch between the OSI or
   GOSIP routing model and the IPv6 routing model. Restricted NSAPAs can
   be routed hierarchically down to the Area level but must be flat-
   routed within an Area. Normal IPv6 addresses can be routed



Bound, et. al.                Experimental                      [Page 5]

RFC 1888                   OSI NSAPs and IPv6                August 1996


   hierarchically down to physical subnet (link) level and only have to
   be flat-routed on the physical subnet.

   Thus, packets whose destination address is a restricted NSAPA can be
   routed using any normal IPv6 routing protocol only as far as the
   Area. If the Area contains more than one physical subnet reached by
   more than one router, no IPv6 routing protocol can route the packet
   to the correct final router.  There is no solution to this problem
   within the existing IPv6 mechanisms.  Presumably a flooding
   algorithm, or a suitably adapted implementation of ES-IS, could solve
   this problem.

   In the absence of such a routing protocol, either the Area number
   must be hierarchically structured to correspond to physical subnets,