Internet Draft B. Carpenter August 31, 1994 J. Bound Recommendations for OSI NSAP usage in IP6 Abstract draft-carpenter-ip6-nsap-map-00.txt This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IP6, should redesign a native IP6 addressing plan to meet their needs. However, in the event that network implementors prefer to keep their OSI addressing plan intact, this document defines a mapping of OSI NSAP addresses into IP6 addresses. This mapping is restricted by the 16 byte size of IP6 addresses. This document also defines a mapping of IP6 addresses within the OSI address format, should this be required for any reason. Expires February 28, 1995 [Page 1] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 Table of Contents: Status of this Memo.............................................3 1. General recommendations......................................4 2. NSAPA mapping into a 16-byte IP6 address for ICD and DCC.....6 3. NSAPA mapping into a 16-byte IP6 address for other formats...7 4. Restrictions in the NSAPA mappings...........................8 5. Annex: 16-byte IP6 addresses inside a 20-octet NSAPA.........9 Acknowledgements...............................................10 References.....................................................10 Authors' Addresses.............................................10 Expires February 28, 1995 [Page 2] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Expires February 28, 1995 [Page 3] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 1. General recommendations This document is principally 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]. It recommends how they should adapt their addressing plan for use with IP6 [IP6]. The majority of 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]. Most of the present document refers to these address plans, which are essentially binary byte-sequence plans. Brief reference is made to decimal digit-sequence plans as used for ISDN and X.25. The general recommendation is that implementors SHOULD design native IP6 addressing plans according to [Rekhter], 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 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, for US GOSIP, the high-order part SHOULD be replaced by the provider part of an IP6 provider-based addressing plan. An 8-byte provider prefix is recommended for this case and [Rekhter] MUST be followed in planning such a replacement. The low order part SHOULD then be mapped directly in the low-order half of the IP6 address space, and user site address plans are unchanged. A 6-byte ID field mapped from US GOSIP will be acceptable for IP6 autoconfiguration [Katz]. Analogous rules SHOULD be applied to other addressing plans similar to US GOSIP. Some organizations may decide for various reasons not to follow the above recommendation and may wish to use their existing OSI NSAP addressing plan unchanged for IP6. 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 can only occur at inter-domain level using IDRP. An organization using both native IP6 addresses and NSAP addresses for IP6 would be obliged to run two independent routing systems interconnected by IDRP. Nevertheless, to cover this eventuality, the present document defines a way to map a subset of the NSAP address space into the IP6 address space. The mapping is algorithmic and reversible within this subset of the NSAP address space. Certain other uses of this algorithmic mapping could be envisaged. It could be used as an intermediate addressing plan for a network making a transition from CLNP to IP6. It could be used in a header translation scheme for dynamic translation between IP6 and CLNP. It could be used to allow CLNP and IP6 traffic to share the same Expires February 28, 1995 [Page 4] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 routing architecture within an organization (Ships in the Day). It could possibly be used in an encapsulation scheme. It could be used to leave the CLNP domain to traverse the Internet IP6 domain and then enter back into another CLNP domain. All these uses are DEPRECATED but if any of them are implemented, or any other use of mapping, then the mapping defined below MUST be used. Expires February 28, 1995 [Page 5] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 2. NSAPA mapping into a 16-byte IP6 address for ICD and DCC 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|G| 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 G bit is 1 for a group address, 0 for an individual address. Its applicability to support multicast is for further study, and this bit may be withdrawn. The AFcode nibble is encoded as follows 0000-1001 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 1111 AFI value is 39 (DCC) (hex. F) IDI is the three BCD digits of the DCC 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 (R) address semantics are also fully mapped. The NSEL octet is not included. It is of no use for TCP and UDP traffic, but would be needed if a future revision of CLNP used the same format. In this case it could be encoded as an end-to-end IP6 option [IP6]. A network using such addresses could route using suitably adapted implementations of ES-IS, IS-IS and IDRP. It is expected that hosts using such addresses could be auto-configured using [Katz]. Expires February 28, 1995 [Page 6] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 3. NSAPA mapping into a 16-byte IP6 address for other formats 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|G| AFcode| Start of IDI (N digits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| End of DSP (29-N digits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The G bit is reserved and must be set to 0. The AFcode nibble is encoded as follows 1010 AFI value is 37 or 53 (X.121 binary) (hex. A) IDI is the 14 BCD digits of X.121 address DSP is up to 15 BCD digits 1011 AFI value is 45 or 59 (E.164 binary) (hex. B) IDI is the 15 BCD digits of E.164 address DSP is up to 14 BCD digits 1100-1110 Reserved, not to be used. (hex. C, D, E) The padding rules defined in [IS8348] are MODIFIED since only BCD digits are used. All pads to IDI and DSP digit strings consist of trailing ones (hex. F nibbles). Expires February 28, 1995 [Page 7] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 4. Restrictions in the NSAPA mappings Restrictions compared to [IS8348] are: 1. ICD and DCC format addresses using more bytes than the US GOSIP case cannot be mapped. For the US GOSIP case, the DFI byte (DSP Format Identifier) is not mapped and is deemed to be 80 hexadecimal. 2. F.69 (Telex), E.163 (telephone) and Local formats cannot be mapped. It is not widely expected that IP6 will need to run with a Telex or POTS addressing plan. IP6 has a native method of supporting Local addressing plans. 3. The DSP lengths for X.121 and E.164 are shorter than allowed in [IS8348], where they are 24 and 23 digits respectively. 4. Only the binary encodings of [IS8348] are supported. Expires February 28, 1995 [Page 8] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 5. Annex: 16-byte IP6 addresses inside a 20-octet NSAPA If it is required, for whatever reason, to embed an IP6 address inside a 20-octet NSAP address, then the following format MUST be used. Use of this embedding is not specifically recommended, nor is it deprecated. A possible goal would be to allow CLNP packets that encapsulate IP6 packets to be routed in a CLNP network using the IP6 address architecture. Several leading bytes of the IP6 address could be used as a CLNP routing prefix. However, in general routing between CLNP end-systems using this address format and those using another format would require use of IDRP. The first three octets are an IDP meaning "this NSAPA embeds a 16 byte IP6 address" and the last octet is a dummy selector. It is considered unwise to overload the selector octet. 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 = 47 | ICD = ISoc (TBD) | IP6 (byte 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4-7 | IP6 (bytes 1-4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8-11 | IP6 (bytes 5-8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12-15| IP6 (bytes 9-12) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16-19| IP6 (bytes 13-15) | NSEL = dummy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires February 28, 1995 [Page 9] Internet Draft OSI NSAP Usage for IP6 August 31, 1994 Acknowledgements Richard Collella, Jack Houldsworth, Cyndi Jung, Yakov Rekhter, and many other members of the former TUBA and new IP6 working groups of the IETF. References [IS8473] Data communications protocol for providing the connectionless-mode network service, ISO/IEC 8473, 19??. [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). [IP6] The IP6 base documents [RFC1629] The one that explains GOSIPv2 addressing [Rekhter] Forthcoming IP6 address allocation documents. [Katz] Forthcoming IP6 autoconfig document. Authors' Addresses Brian E. Carpenter Group Leader, Communications Systems Phone: +41 22 767-4967 Computing and Networks Division Fax: +41 22 767-7155 CERN Telex: 419000 cer ch European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 1211 Geneva 23, Switzerland Jim Bound Member Technical Staff Phone: (603) 881-0400 Network Operating Systems Fax: (603) 881-0120 Digital Equipment Corporation Email: bound@zk3.dec.com 110 Spitbrook Road, ZKO3-3/U14 Nashua, NH 03062 Expires February 28, 1995 [Page 10]