rfc1888.txt

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

   of Ross Callon, Richard Collella, Steve Deering, Dirk Fieldhouse,
   Joel Halpern, Denise Heagerty, Cyndi Jung, Yakov Rekhter, and members
   of the former TUBA and current IPNG working groups of the IETF. The
   support of Scott Bradner and Allison Mankin of the IESG was
   essential.

   Herb Bertine, Alan Chambers, Dave Marlow, and Jack Wheeler were all
   active in arranging the AFI allocation by ISO/IEC JTC1/SC6.









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


References

   [IS8473] Data communications protocol for providing the
   connectionless-mode network service, ISO/IEC 8473, 1988.

   [IS8348] Annex A, Network Layer Addressing, and Annex B, Rationale
   for the material in Annex A, of ISO/IEC 8348, 1993 (identical to
   CCITT Recommendation X.213, 1992).

   [IS10589] Intermediate system to intermediate system intra-domain-
   routeing routine information exchange protocol for use in
   conjunction with the protocol for providing the connectionless-mode
   Network Service (ISO 8473), ISO 10589, 1992.

   [IS9542] End system to Intermediate system routeing exchange
   protocol for use in conjunction with the Protocol for providing the
   connectionless-mode network service (ISO 8473), ISO 9542, 1988.

   [RFC1629] Colella, R., Callon, R., Gardner, E., and Y. Rekhter,
   "Guidelines for OSI NSAP Allocation in the Internet", RFC 1629, May
   1994.

   [RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered
   Dangerous", RFC 1326, May 1992.

   [RFC1883] Deering, S., and R. Hinden, "Internet Protocol, Version 6
   (IPv6) Specification", RFC 1883, December 1995.

   [RFC1884] Hinden, R., and S. Deering, "IP Version 6 Addressing
   Architecture", RFC 1884, December 1995.

   [RFC1971] Thompson, S., and T. Narten, "IPv6 Stateless Address
   Autoconfiguration", RFC1971, August 1996.

   [RFC1970] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
   Discovery for IP Version 6 (IPv6)", RFC1970, August 1996.

   [RFC1825] Atkinson, R., "Security Architecture for the Internet
   Protocol", RFC 1825, August 1995.












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


Annex A: Summary of NSAP Allocations

            -----IDP------
            -----------------------------------------------------
            | AFI  | IDI  |     DOMAIN SPECIFIC PART            |
            -----------------------------------------------------
            --------------------20 bytes max---------------------

   The Initial Domain Part (IDP) is split into Authority and Format
   Identifier (AFI) followed by the Initial Domain Identifier (IDI).
   This combination is followed by the Domain Specific Part and
   allocation within that part is domain specific.

   The following is a summary of current allocations:

   ISO DCC Scheme

   AFI = decimal 38 or binary 39 = ISO Data Country Code Scheme.  IDI =
   3 decimal or binary digits specifying the country.  ISO allocate the
   country codes.  The DSP is administered by the standards authority
   for each country.  In the UK, the British Standards Institution have
   delegated administration to the Federation of Electronics Industries
   - FEI

   The UK DSP is split into a single digit UK Format Indicator (UKFI)
   which indicates large, medium or small organisation rather like IP
   addressing and a UK Domain Identifier (UKDI).  Using binary coded
   decimal examples only (there are binary equivalents):

   UKFI = 0 is reserved UKFI = 1, UKDI = nnn, UK Domain Specific Part =
   31 digits.  UKFI = 2, UKDI = nnnnn, UKDSP = 29 digits max.  UKFI = 3,
   UKDI = nnnnnnnn, UKDSP = 26 digits max.

   UKFI = 4 to 9 reserved

   The UK Government have been allocated a UKDI in the UKFI = 1 (large
   organisation) format and have specified the breakdown of the
   Government Domain Specific Part with sub domain addresses followed by
   a station ID (which could be a MAC address) and a selector (which
   could be a TSAP selection).

   ITU-T X.121

   AFI = decimal 36 or 52, binary 37 or 53 indicates that the IDI is a
   14 digit max X.121 International Numbering Plan address (prefix, 3
   digit Data Country Code, dial up data network number).  The full
   X.121 address indicates who controls the formatting of the DSP.




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


   ITU-T F.69

   AFI = 40,54 or binary 41,55 indicates that the IDI is a telex number
   up to 8 digits long.

   ITU-T E.163

   AFI = 42,56 or binary 43,57 indicates that the IDI is a normal
   telephone number up to 12 digits long.

   ITU-T E.164

   AFI = 44,58 or binary 45,59 indicates that the IDI is an ISDN number
   up to 15 digits long.

   ISO 6523-ICD

   AFI = 46 or binary 47 indicates that the IDI is an International Code
   Designator allocated according to ISO 6523.  You have to be a global
   organisation to get one of these.  The Organisation to which the ISO
   6523 designator is issued specifies the DSP allocation.

Annex B: Additional Rationale

   This annex is intended to give additional rationale, motivation and
   justification for the support of NSAPAs in an IPv6 network.

   There are several models for OSI-IPv6 convergence, of which address
   mapping is only one. The other models can be identified as

    1. Dual stack coexistence, in which a CLNP network and an IPv6
       network exist side by side indefinitely using multiprotocol
       routers.

    2. CLNP tunnels over IPv6.

    3. OSI transport over IPv6.

    4. OSI transport over UDP.

    5. OSI transport over TCP (compare RFC 1006)

   The present model is more fundamental, as it attempts to unify and
   reconcile the OSI and IPv6 addressing and routing schemes, and
   replace CLNP by IPv6 at the network level. The rationale for this
   choice is to preserve investment in NSAPA allocation schemes, and to
   open the door for peer-to-peer routing models between IPv6 and bearer
   services (such as ATM) using NSAPA addressing. It should be noted



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


   that such peer-to-peer models are contentious at the time of writing,
   but in any case a consistent address mapping is preferable to
   multiple mappings.

   In addition to their use to retain an existing addressing plan,
   certain other uses of restricted NSAPAs could be envisaged.  They
   could be used as an intermediate addressing plan for a network making
   a transition from CLNP to IPv6. They could be used in a header
   translation scheme for dynamic translation between IPv6 and CLNP.
   They could be used to allow CLNP and IPv6 traffic to share the same
   routing architecture within an organization ("Ships in the Day").

   It should be noted that the use of full NSAPA addresses in end
   systems impacts many things. The most obvious are the API and DNS. If
   applications are to work normally, everything that has to be modified
   to cope with IPv6 addresses has to be further modified for full
   NSAPAs.  The mechanisms defined in the present document are only a
   small part of the whole.

   A destination option was chosen to carry full NSAPAs, in preference
   to a dedicated extension header.  In the case of an extension header,
   all IPv6 nodes would have needed to understand its syntax merely in
   order to ignore it. In contrast, intermediate nodes can ignore the
   destination option without any knowledge of its syntax. Thus only
   nodes interested in NSAPAs need to know anything about them.

   Thus we end up with two classes of IPv6 nodes:

   1. Nodes knowing only about 16 byte addresses (including restricted
   NSAPAs, which behave largely like any other IPv6 addresses).

   2. Nodes also knowing about 20 byte NSAPAs, either as an extension of
   the IPv6 address space or as the CLNP address space. In either case,
   regions of the network containing such nodes are connected to each
   other by unicast or anycast tunnels through the 16 byte address
   space. Routing, system configuration, and neighbour discovery in the
   NSAPA regions are outside the scope of the normal IPv6 mechanisms.














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


Authors' Addresses

   Jim Bound
   Member Technical Staff                    Phone: [phone]
   Network Operating Systems                 Fax:   [phone]
   Digital Equipment Corporation             Email: [e-mail]
   110 Spitbrook Road, ZKO3-3/U14
   Nashua, NH 03062

   Brian E. Carpenter
   Group Leader, Communications Systems      Phone:  [phone]
   Computing and Networks Division           Fax:    [phone]
   CERN                                      Telex:  419000 cer ch
   European Laboratory for Particle Physics  Email: [e-mail]
   1211 Geneva 23, Switzerland

   Dan Harrington                            Phone: [phone]
   Digital Equipment Corp.
   550 King Street (LKG2-2/Q9)               Email: [e-mail]
   Littleton, MA  01460

   Jack Houldsworth            Phone- ICL: [phone]
   ICL Network Systems               Home: [phone]
   Cavendish Road              Fax:        [phone]
   Stevenage                   Email: [e-mail]
   Herts
   UK SG1 4BQ

   Alan Lloyd                  Phone:  [phone]
   Datacraft Technologies      Fax:    [phone]
   252 Maroondah Highway       Email:  [e-mail]
   Mooroolbark 3138
   Victoria       Australia

   X.400- G=alan;S=lloyd;O=dcthq;P=datacraft;A=telememo;C=au
















Bound, et. al.                Experimental                     [Page 16]