idnits 2.17.1 draft-carpenter-ip6-nsap-map-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 36 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 66: '...that implementors SHOULD design native...' RFC 2119 keyword, line 78: '... high-order part SHOULD be replaced by...' RFC 2119 keyword, line 80: '... provider prefix is recommended for this case and [Rekhter] MUST be...' RFC 2119 keyword, line 81: '...replacement. The low order part SHOULD...' RFC 2119 keyword, line 87: '... Analogous rules SHOULD be applied to ...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'IS8473' on line 249 looks like a reference -- Missing reference section? 'IS8348' on line 252 looks like a reference -- Missing reference section? 'IP6' on line 256 looks like a reference -- Missing reference section? 'RFC1629' on line 258 looks like a reference -- Missing reference section? 'Rekhter' on line 260 looks like a reference -- Missing reference section? 'Katz' on line 262 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft B. Carpenter 2 August 31, 1994 J. Bound 4 Recommendations for OSI NSAP usage in IP6 6 Abstract 8 draft-carpenter-ip6-nsap-map-00.txt 10 This document recommends that network implementors who have planned or 11 deployed an OSI NSAP addressing plan, and who wish to deploy or transition 12 to IP6, should redesign a native IP6 addressing plan to meet their 13 needs. However, in the event that network implementors prefer to keep 14 their OSI addressing plan intact, this document defines a mapping of 15 OSI NSAP addresses into IP6 addresses. This mapping is restricted by 16 the 16 byte size of IP6 addresses. This document also defines a 17 mapping of IP6 addresses within the OSI address format, should this 18 be required for any reason. 20 Table of Contents: 22 Status of this Memo.............................................3 23 1. General recommendations......................................4 24 2. NSAPA mapping into a 16-byte IP6 address for ICD and DCC.....6 25 3. NSAPA mapping into a 16-byte IP6 address for other formats...7 26 4. Restrictions in the NSAPA mappings...........................8 27 5. Annex: 16-byte IP6 addresses inside a 20-octet NSAPA.........9 28 Acknowledgements...............................................10 29 References.....................................................10 30 Authors' Addresses.............................................10 32 Status of this Memo 34 This document is an Internet-Draft. Internet-Drafts are working 35 documents of the Internet Engineering Task Force (IETF), its areas, 36 and its working groups. Note that other groups may also distribute 37 working documents as Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months. Internet-Drafts may be updated, replaced, or obsoleted by 41 other documents at any time. It is not appropriate to use Internet- 42 Drafts as reference material or to cite them other than as a 43 ``working draft'' or ``work in progress.'' 45 To learn the current status of any Internet-Draft, please check the 46 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 47 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 48 munnari.oz.au. 50 1. General recommendations 52 This document is principally addressed to network implementors who 53 have already planned or deployed an OSI NSAP addressing plan for the 54 usage of OSI CLNP [IS8473] according to the OSI network layer 55 addressing plan [IS8348]. It recommends how they should adapt their 56 addressing plan for use with IP6 [IP6]. 58 The majority of CLNP addressing plans use either the Digital Country 59 Code (DCC) or the International Code Designator (ICD) formats defined 60 in [IS8348]. A particular example of this is the US Government OSI 61 Profile Version 2 (GOSIP) addressing plan [RFC1629]. Most of the 62 present document refers to these address plans, which are essentially 63 binary byte-sequence plans. Brief reference is made to decimal 64 digit-sequence plans as used for ISDN and X.25. 66 The general recommendation is that implementors SHOULD design native 67 IP6 addressing plans according to [Rekhter], but doing so as a 68 natural re-mapping of their CLNP addressing plans. While it is 69 impossible to give a general recipe for this, CLNP addresses in DCC 70 or ICD format can normally be split into two parts: the high order 71 part relating to the network service provider and the low order part 72 relating to the user network topology and host computers. For 73 example, in US GOSIP the high order part is the AFI, ICD, DFI, AA and 74 RD fields, together occupying 9 bytes. The low order part is the Area 75 and ID fields, together occupying 8 bytes. (The selector byte and the 76 two reserved bytes are not part of the addressing plan.) 78 Thus, for US GOSIP, the high-order part SHOULD be replaced by the 79 provider part of an IP6 provider-based addressing plan. An 8-byte 80 provider prefix is recommended for this case and [Rekhter] MUST be 81 followed in planning such a replacement. The low order part SHOULD 82 then be mapped directly in the low-order half of the IP6 address 83 space, and user site address plans are unchanged. A 6-byte ID field 84 mapped from US GOSIP will be acceptable for IP6 autoconfiguration 85 [Katz]. 87 Analogous rules SHOULD be applied to other addressing plans similar 88 to US GOSIP. 90 Some organizations may decide for various reasons not to follow the 91 above recommendation and may wish to use their existing OSI NSAP 92 addressing plan unchanged for IP6. It should be noted that such a 93 decision has serious implications for routing, since it means that 94 routing between such organizations and the rest of the Internet can 95 only occur at inter-domain level using IDRP. An organization using 96 both native IP6 addresses and NSAP addresses for IP6 would be obliged 97 to run two independent routing systems interconnected by IDRP. 98 Nevertheless, to cover this eventuality, the present document defines 99 a way to map a subset of the NSAP address space into the IP6 address 100 space. The mapping is algorithmic and reversible within this subset 101 of the NSAP address space. 103 Certain other uses of this algorithmic mapping could be envisaged. 104 It could be used as an intermediate addressing plan for a network 105 making a transition from CLNP to IP6. It could be used in a header 106 translation scheme for dynamic translation between IP6 and CLNP. It 107 could be used to allow CLNP and IP6 traffic to share the same 108 routing architecture within an organization (Ships in the Day). It 109 could possibly be used in an encapsulation scheme. It could be used 110 to leave the CLNP domain to traverse the Internet IP6 domain and then 111 enter back into another CLNP domain. 113 All these uses are DEPRECATED but if any of them are implemented, or 114 any other use of mapping, then the mapping defined below MUST be 115 used. 117 2. NSAPA mapping into a 16-byte IP6 address for ICD and DCC 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 0-3 |0 0 0 0 0 0 1|G| AFcode| IDI (last 3 digits) |Prefix(octet 0)| 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 4-7 | Prefix (octets 1 through 4) | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 8-11 | Area (octets 0 and 1) | ID (octets 0 and 1) | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 12-15| ID (octets 2 through 5) | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 The G bit is 1 for a group address, 0 for an individual address. Its 132 applicability to support multicast is for further study, and this bit 133 may be withdrawn. 135 The AFcode nibble is encoded as follows 137 0000-1001 AFI value is 47 (ICD) 138 (0-9 decimal) AFcode is first BCD digit of the ICD 139 IDI is last three BCD digits of the ICD 141 1111 AFI value is 39 (DCC) 142 (hex. F) IDI is the three BCD digits of the DCC 144 The longest CLNP routing prefixes known to be in active use today are 145 5 octets (subdivided into AA and RD fields in US GOSIP version 2). 146 Thus the semantics of existing 20-octet NSAPAs can be fully mapped. 147 DECnet/OSI (R) address semantics are also fully mapped. 149 The NSEL octet is not included. It is of no use for TCP and UDP 150 traffic, but would be needed if a future revision of CLNP used the 151 same format. In this case it could be encoded as an end-to-end IP6 152 option [IP6]. 154 A network using such addresses could route using suitably adapted 155 implementations of ES-IS, IS-IS and IDRP. It is expected that hosts 156 using such addresses could be auto-configured using [Katz]. 158 3. NSAPA mapping into a 16-byte IP6 address for other formats 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 0-3 |0 0 0 0 0 0 1|G| AFcode| Start of IDI (N digits) | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 4-7 | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 8-11 | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 12-15| End of DSP (29-N digits) | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 The G bit is reserved and must be set to 0. 174 The AFcode nibble is encoded as follows 176 1010 AFI value is 37 or 53 (X.121 binary) 177 (hex. A) IDI is the 14 BCD digits of X.121 address 178 DSP is up to 15 BCD digits 180 1011 AFI value is 45 or 59 (E.164 binary) 181 (hex. B) IDI is the 15 BCD digits of E.164 address 182 DSP is up to 14 BCD digits 184 1100-1110 Reserved, not to be used. 185 (hex. C, D, E) 187 The padding rules defined in [IS8348] are MODIFIED since only BCD 188 digits are used. All pads to IDI and DSP digit strings consist of 189 trailing ones (hex. F nibbles). 191 4. Restrictions in the NSAPA mappings 193 Restrictions compared to [IS8348] are: 195 1. ICD and DCC format addresses using more bytes than the US GOSIP 196 case cannot be mapped. For the US GOSIP case, the DFI byte (DSP 197 Format Identifier) is not mapped and is deemed to be 80 hexadecimal. 199 2. F.69 (Telex), E.163 (telephone) and Local formats cannot be 200 mapped. It is not widely expected that IP6 will need to run with a 201 Telex or POTS addressing plan. IP6 has a native method of supporting 202 Local addressing plans. 204 3. The DSP lengths for X.121 and E.164 are shorter than allowed in 205 [IS8348], where they are 24 and 23 digits respectively. 207 4. Only the binary encodings of [IS8348] are supported. 209 5. Annex: 16-byte IP6 addresses inside a 20-octet NSAPA 211 If it is required, for whatever reason, to embed an IP6 address 212 inside a 20-octet NSAP address, then the following format MUST be 213 used. 215 Use of this embedding is not specifically recommended, nor is it 216 deprecated. A possible goal would be to allow CLNP packets that 217 encapsulate IP6 packets to be routed in a CLNP network using the IP6 218 address architecture. Several leading bytes of the IP6 address could 219 be used as a CLNP routing prefix. However, in general routing between 220 CLNP end-systems using this address format and those using another 221 format would require use of IDRP. 223 The first three octets are an IDP meaning "this NSAPA embeds a 16 224 byte IP6 address" and the last octet is a dummy selector. It is 225 considered unwise to overload the selector octet. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 0-3 | AFI = 47 | ICD = ISoc (TBD) | IP6 (byte 0) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 4-7 | IP6 (bytes 1-4) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 8-11 | IP6 (bytes 5-8) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 12-15| IP6 (bytes 9-12) | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 16-19| IP6 (bytes 13-15) | NSEL = dummy | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Acknowledgements 243 Richard Collella, Jack Houldsworth, Cyndi Jung, Yakov Rekhter, and 244 many other members of the former TUBA and new IP6 working groups of 245 the IETF. 247 References 249 [IS8473] Data communications protocol for providing the 250 connectionless-mode network service, ISO/IEC 8473, 19??. 252 [IS8348] Annex A, Network Layer Addressing, and Annex B, Rationale 253 for the material in Annex A, of ISO/IEC 8348, 1993 (identical to 254 CCITT Recommendation X.213, 1992). 256 [IP6] The IP6 base documents 258 [RFC1629] The one that explains GOSIPv2 addressing 260 [Rekhter] Forthcoming IP6 address allocation documents. 262 [Katz] Forthcoming IP6 autoconfig document. 264 Authors' Addresses 266 Brian E. Carpenter 267 Group Leader, Communications Systems Phone: +41 22 767-4967 268 Computing and Networks Division Fax: +41 22 767-7155 269 CERN Telex: 419000 cer ch 270 European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 271 1211 Geneva 23, Switzerland 273 Jim Bound 274 Member Technical Staff Phone: (603) 881-0400 275 Network Operating Systems Fax: (603) 881-0120 276 Digital Equipment Corporation Email: bound@zk3.dec.com 277 110 Spitbrook Road, ZKO3-3/U14 278 Nashua, NH 03062