rfc1888.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   or each Area must be limited to one physical subnet.

   It is necessary in an IPv6 network that routes may be aggregated to
   minimise the size of routing tables. If a subscriber is using both
   normal IPv6 addresses [RFC1884] and restricted NSAPAs, these two
   types of address will certainly not aggregate with each other, since
   they differ from the second most significant bit onwards. This means
   that there may be a significant operational penalty for using both
   types of address with currently known routing technology.

4. Truncated NSAPA used as an IPv6 address

   An NSAP address contains routing information (e.g. Routing Domain and
   area/subnet identifiers) in the form of the Area Address (as defined
   in [IS10589]). The format and length of this routing information are
   typically compatible with a 16 byte IPv6 address, and may be
   represented as such using the following format:

       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 1|  High order octets of full NSAP address       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4-7  |                NSAP address continued                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8-11 |                NSAP address continued                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12-15| NSAP address truncated     ...    zero pads if necessary      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If appropriate, when used as a destination IPv6 address, the
   truncated NSAPA may be interpreted as an IPv6 anycast address.  An
   anycast address may be used to identify either an IPv6 node, or
   potentially even an OSI End System or Intermediate System.  For



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


   example, it might be configured to identify the endpoints of a CLNP
   tunnel, or it might identify a particular OSI capable system in a
   particular subnet.

   If a truncated NSAPA is used as a source address, it must be
   interpreted as a unicast address and must therefore be uniquely
   assigned within the IPv6 address space.

   If a truncated NSAPA is used as either the source or destination IPv6
   address (or both), EITHER an NSAPA destination option OR an
   encapsulated CLNP packet MUST be present. It is the responsibility of
   the destination system to take the appropriate action for each IPv6
   packet received (e.g. forward, decapsulate, discard) and, if
   necessary, return to the originating host an appropriate ICMP error
   message.

   If the truncated NSAPA is used to identify a router, and an NSAPA
   destination option is present, then it is the responsibility of that
   router to forward the complete IPv6 packet to the appropriate host
   based upon the Destination NSAP field in the NSAPA option.  This
   forwarding process may be based upon static routing information (i.e.
   a manual mapping of NSAPs to IPv6 unicast addresses), or it may be
   gathered in an automated fashion analogous to the ES-IS mechanism,
   perhaps using extensions to the Neighbor Discovery protocol
   [RFC1970].  The details of such a mechanism are beyond the scope of
   this document.

   This document does not restrict the formats of NSAP address that may
   be used in truncated NSAPAs, but it is apparent that binary ICD or
   DCC formats will be much easier to accomodate in an IPv6 routing
   infrastructure than the other formats defined in [IS8348].

   It is not expected that IPv6 autoconfiguration [RFC1971] and
   discovery [RFC1970] will work unchanged for truncated NSAPAs.

   Truncated NSAPAs are not meaningful within IPv6 routing headers, and
   there is no way to include full NSAPAs in routing headers.

   If a packet whose source address is a truncated NSAPA causes an ICMP
   message to be returned for whatever reason, this ICMP message may be
   discarded rather than being returned to the true source of the
   packet.









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


4.1 Routing truncated NSAPAs

   This is a grey area. If the truncated NSAPA retains a hierarchical
   structure, it can be routed like a restricted NSAPA, subject to the
   same problem concerning the mismatch between Areas and subnets.  If
   possible, in the case of a GOSIP-like NSAPA, it should be truncated
   immediately after the Area number. In this case the routing
   considerations will be similar to those for restricted NSAPAs, except
   that final delivery of the packet will depend on the last IPv6 router
   being able to interpret the NSAPA destination option (or an
   encapsulated CLNP packet).

   In the general case, nothing can be said since the NSAPA could have
   almost any format and might have very little hierarchical content
   after truncation. There may be many cases in which truncated NSAPAs
   cannot be routed across large regions of the IPv6 network.

   The situation for route aggregation is similar to that described in
   Section 3.1 as long as the truncated NSAPAs have ICD or DCC format.
   However, if arbitrary NSAPAs are used nothing can be predicted about
   route aggregation and we must assume that it will be poor.






























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


5. Carriage of full NSAPAs in IPv6 destination option

   In the case of a truncated NSAPA used as an IPv6 address other than
   for a CLNP tunnel, the full NSAPA must be carried in a destination
   option. Any format defined in [IS8348] is allowed.

   The NSAPA destination option is illustrated below. It has no
   alignment requirement.

   The option type code is 11-0-00011 = 195 decimal.

       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 1 0 0 0 0 1 1|  Opt Data Len |Source NSAP Len| Dest. NSAP Len|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                         Source NSAP                           +
       |                                                               |
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                       Destination NSAP                        +
       |                                                               |
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length fields are each one octet long and are expressed in
   octets.  The destination node should check the consistency of the
   length fields (Option Data Length = Source NSAP Length + Dest. NSAP
   Length +2).  In case of inconsistency the destination node shall
   discard the packet and send an ICMP Parameter Problem, Code 2,
   message to the packet's source address, pointing to the Option Data
   Length field.

   The boundary between the source NSAP and the destination NSAP is
   simply aligned on an octet boundary. With standard 20 octet NSAPs the
   total option length is 44 bytes and the Option Data Length is 42.



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


   The NSAP encodings follow [IS8348] exactly.

   If this option is used, both end systems concerned SHOULD use NSAP
   addresses. In the exceptional case that only one of the end systems
   uses NSAP addresses, the NSAP Length field of the other SHALL be set
   to zero in the NSAP destination option.

   This destination option is used in two cases. Firstly, an IPv6 source
   node using normal IPv6 addresses (unicast address or anycast address)
   MAY supply an NSAP destination option header for interpretation by
   the IPv6 destination node. Secondly, an IPv6 node MAY use a truncated
   NSAP address in place of a normal IPv6 address.

   IPv6 nodes are not required to implement this option, except for
   nodes using truncated NSAPAs other than for CLNP tunnels.

6. IPv6 addresses inside an NSAPA

   If it is required, for whatever reason, to embed an IPv6 address
   inside a 20-octet NSAP address, then the following format MUST be
   used.

   A specific possible use of this embedding is to express an IP address
   within the ATM Forum address format.  Another  possible use would be
   to allow CLNP packets that encapsulate IPv6 packets to be routed in a
   CLNP network using the IPv6 address architecture. Several leading
   bytes of the IPv6 address could be used as a CLNP routing prefix.

   The first three octets are an IDP in binary format, using the AFI
   code in the process of being allocated to the IANA. The AFI value
   provisionally allocated is 35, but this requires a formal
   modification to [IS8348].  The encoding format is as for AFI value 47
   [IS8348]. The third octet of the IDP is known as the ICP (Internet
   Code Point) and its value must be zero. All other values are reserved
   for allocation by the IANA.

   Thus an AFI value of 35 with an ICP value of zero means that "this
   NSAPA embeds a 16 byte IPv6 address".

   The last octet is a selector.  To maintain compatibility with both
   NSAP format and IPv6 addressing, this octet must be present, but it
   has no significance for IPv6. Its default value is zero.









Bound, et. al.                Experimental                     [Page 10]

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  |  AFI = 35     |   ICP = 0000                  | IPv6  (byte 0)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4-7  |             IPv6  (bytes 1-4)                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8-11 |             IPv6  (bytes 5-8)                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 12-15|             IPv6  (bytes 9-12)                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16-19|       IPv6  (bytes 13-15)                     |0 0 0 0 0 0 0 0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Theoretically this format would allow recursive address embedding.

   However, this is considered dangerous since it might lead to routing
   table anomalies or to loops (compare [RFC1326]).  Thus embedded IPv6
   address MUST NOT have the prefixes 0x02 or 0x03, and an NSAPA with
   the IANA AFI code MUST NOT be embedded in an IPv6 header.

   An NSAPA with the IANA AFI code and ICP set to zero is converted to
   an IPv6 address by stripping off the first three and the twentieth
   octets. All other formats of NSAPA are handled according to the
   previous Chapters of this document.

7. Security Considerations

   Security issues are not specifically addressed in this document, but
   it is compatible with the IPv6 security mechanisms [RFC1825].

Acknowledgements

   The authors are pleased to acknowledge the suggestions and comments