Internet DRAFT - draft-carpenter-ip6-nsap-map
draft-carpenter-ip6-nsap-map
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]
