idnits 2.17.1 draft-eastlake-nlpid-iana-considerations-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 7, 2009) is 5247 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO9577' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-16) exists of draft-ietf-trill-rbridge-protocol-14 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Donald Eastlake 3rd 2 Internet-Draft Stellar Switches 3 Intended Status: Best Current Practice 4 Expires: June 6, 2009 December 7, 2009 6 IANA Considerations for Network Layer Protocol Identifiers 8 10 Status of This Document 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This document is intended to become a Best Current Practice. 16 Distribution of this document is unlimited. Comments should be sent 17 to the author. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 Some protocols being developed or extended by the IETF make use of 38 the ISO/IEC (International Organization for Standardization / 39 International Electrotechnical Commission) Network Layer Protocol 40 Identifier (NLPID). This document provides NLPID IANA Considerations. 42 Table of Contents 44 Status of This Document....................................1 45 Abstract...................................................1 47 1. Introduction............................................3 48 1.1 Acknowledgements.......................................3 50 2. NLPIDs..................................................4 51 2.1 Sub-ranges of the NLPID................................4 52 2.2 Code Point 0x80........................................4 53 2.3 NLPIDs Available for IANA Allocation...................5 55 3. IANA Considerations.....................................6 56 4. Security Considerations.................................6 58 5. Normative References....................................7 59 6. Informative References..................................7 61 Appendix A: Initial IANA NLPID Web Page....................9 62 Appendix B: RFC References to NLPID.......................10 64 Copyright and IPR Provisions..............................11 65 Author's Address..........................................12 67 1. Introduction 69 Some protocols being developed or extended by the IETF make use of 70 the ISO/IEC (International Organization for Standardization / 71 International Electrotechnical Commission) Network Layer Protocol 72 Identifier (NLPID). 74 The term "NLPID" is not actually used in [ISO9577], which refers to 75 one-octet IPIs (Initial Protocol Identifiers) and SPIs (Subsequent 76 Protocol Identifiers). While these are two logically separate kinds 77 of one-octet identifiers, most values are usable as both an IPI and 78 an SPI. In the remainder of this document, the term NLPID is used for 79 such values. 81 The registry of NLPID values is maintained by ISO/IEC by updating 82 [ISO9577] . The procedure specified by ISO/IEC in that document is 83 that an NLPID code point can be allocated without approval by 84 ISO/IEC, as long as the code point is not in a range of values 85 categegorized for an organization other than the organization 86 allocating the code point and as long as ISO/IEC JTC1 SC6 is 87 informed. 89 This document provides NLPID IANA Considerations. That is, it 90 specifies the level of IETF approval necessary for a code point to be 91 allocated for IETF use, the procedures to be used and actions to be 92 taken by IANA in connection with NLPIDs, and related guidelines. 94 [RFC5226] is incorporated herein except to the extent that there are 95 contrary provisions in this document. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 1.1 Acknowledgements 103 The contributions and support of the following people, listed in 104 alphabetic order, are gratefully acknowledged: 106 Ayan Banerjee, Gonzalo Camarillo, Dinesh Dutt, Don Fedyk, Alfred 107 Hines, Russ Housley, Radia Perlman, Dan Romascanu, and Peter 108 Ashwood-Smith. 110 2. NLPIDs 112 [ISO9577] defines one-octet network layer protocol identifiers that 113 are commonly called NLPIDs, which is the term used in this document. 115 NLPIDs are used in a number of protocols. For example, in the 116 mar$pro.type field of the multicast address resolution server 117 protocol [RFC2022], the ar$pro.type field of the NBMA (Non-Broadcast 118 Multi-Access) next hop resolution protocol [RFC2332] and in the IS-IS 119 Protocols Supported TLV [RFC1195]. See Appendix B. 121 2.1 Sub-ranges of the NLPID 123 Sub-ranges of the possible NLPID values are categorized by [ISO9577] 124 for organizations as shown below, primarily for the ISO/IEC 125 (International Organization for Standardization / International 126 Electrotechnical Commission) and the ITU-T (International 127 Telecommunication Union - Telecommunication Standardization Sector): 129 Code Point Category 130 ---------- -------- 131 0x00 ISO/IEC 132 0x01-0x0F ITU-T 133 0x10-0x3F ITU-T Rec. X.25 and ISO/IEC 8208 134 0x40-0x43 ISO/IEC 135 0x44 ITU-T 136 0x45-0x4F ISO/IEC 137 0x50-0x6F ITU-T Rec. X.25 and ISO/IEC 8208 138 0x70-0x7F Joint ITU-T and ISO/IEC 139 0x80 ISO/IEC (see Section 2.2) 140 0x81-0x8F ISO/IEC 141 0x90-0xAF ITU-T Rec. X.25 and ISO/IEC 8208 142 0xB0-0xBF ITU-T 143 0xC0-0xCF Potentially available for IANA (see Section 2.3) 144 0xD0-0xEF ITU-T Rec. X.25 and ISO/IEC 8208 145 0xF0-0xFE Joint ITU-T and ISO/IEC 146 0xFF Reserved for an Extension mechanism to be 147 jointly developed by ITU-T and ISO/IEC 149 2.2 Code Point 0x80 151 NLPID 0x80 is known as the IEEE (Institute of Electrical & 152 Electronics Engineers) SNAP (SubNetwork Access Protocol) code point. 153 It is followed by five octets, using the IEEE SNAP SAP (Service 154 Access Point) conventions, to specify the protocol. Those conventions 155 are described in Section 3 of [RFC5342]. In particular, it is valid 156 for such a five-octet sequence to start with the IANA OUI 157 (Organizationally Unique Identifier) followed by two further octets 158 assigned by IANA as provided in [RFC5342]. The same IANA registry is 159 used for such protocol identifiers whether they are planned to be 160 introduced by the 0x80 NLPID or the IEEE SNAP SAP LSAPs (Link-Layer 161 Service Access Points) (0xAAAA). Values allocated by IANA may be used 162 in either context as appropriate. 164 Because of the limited number of NLPID code points available for IANA 165 allocation, use of the IEEE SNAP NLPID is RECOMMENDED rather than 166 allocation of a new one-octet NLPID code point. 168 2.3 NLPIDs Available for IANA Allocation 170 A limited number of code points are available that could be allocated 171 by IANA under [ISO9577]. Because of this, it is desirable, where 172 practical, to use code point 0x80, as discussed in Section 2.2 above, 173 or to get code points allocated from the ranges categorized to other 174 organizations. For example, code point 0x8E was allocated for IPv6 175 [RFC2460], although it is in a range of code points categorized for 176 ISO/IEC. 178 The table below, which includes two new code point allocations made 179 by this document, shows those still available. 181 Code Point Status 182 ---------- -------- 183 0xC0 TRILL [TRILL] 184 0xC1 IEEE 802.1aq [802.1aq] 185 0xC2-0xCB Available 186 0xCC IPv4 [RFC791] 187 0xCD-0xCE Available 188 0xCF PPP [RFC1661] 190 3. IANA Considerations 192 As long as code points are available, IANA will allocate additional 193 values when required by an IETF Standards Action. 195 Whenever it allocates an NLPID, IANA will inform the IETF liaison to 196 ISO/IEC JTC1 SC6 (Joint Technical Committee 1, Study Committee 6) 197 [JTC1SC6], or if IANA is unable to determine that IETF liaison, the 198 IAB. The liaison (or the IAB) will then assure that ISO/IEC JTC1 SC6 199 is informed so that [ISO9577] can be updated since ISO/IEC JTC1 SC6 200 is the body that maintains [ISO9577]. To simplify this process, it is 201 desirable that the IAB maintain an IETF Liaison to ISO/IEC JTC1 SC6. 203 This document allocates the code points 0xC0 and 0xC1 as shown in 204 Section 2.3 and IANA shall request the liaison (or the IAB) to so 205 inform ISO/IEC JTC1 SC6. 207 IANA will maintain a web page showing NLPIDs that have been allocated 208 to a protocol being developed or extended by the IETF or are 209 otherwise of interest. The initial state of the web page shall be as 210 shown in Appendix A. IANA will update this web page for (1) NLPIDs 211 allocated by IANA and (2) other allocations or de-allocations when 212 IANA is requested to make such changes to this web page by the IETF 213 liaison mentioned above. 215 4. Security Considerations 217 This document is concerned with allocation of NLPIDs. It is not 218 directly concerned with security. 220 5. Normative References 222 [ISO9577] Information technology - Protocol identification in the 223 network layer, ISO/IEC TR 957:1999(E)7, 1999-12-15. 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, March 1997. 228 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 229 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 230 2008. 232 [RFC5342] Eastlake 3rd., D., "IANA Considerations and IETF Protocol 233 Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 234 2008. 236 6. Informative References 238 [802.1aq] Standard for Local and Metropolitan Area Networks / Virtual 239 Bridged Local Area Networks / Amendment 9: Shortest Path 240 Bridging, Draft IEEE P802.1aq/D2.1, 21 August 2009. 242 [JTC1SC6] ISO/IEC JTC1 SC6 (International Organization for 243 Standardization / International Electrotechnical Commission, 244 Joint Technical Committee 1, Study Committee 6), 245 http://www.iso.org/iso/iso_technical_committee.html?commid=45072 247 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 248 1981. 250 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 251 dual environments", RFC 1195, December 1990. 253 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 254 51, RFC 1661, July 1994. 256 [RFC1707] McGovern, M. and R. Ullmann, "CATNIP: Common Architecture 257 for the Internet", RFC 1707, October 1994. 259 [RFC2022] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based 260 ATM Networks", RFC 2022, November 1996. 262 [RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. 263 Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, 264 April 1998 266 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 267 (IPv6) Specification", RFC 2460, December 1998. 269 [TRILL] Radia, P., Eastlake, D., Dutt, D., Gai, S., and Ghanwani, A., 270 "RBridges: Base Protocol Specification", draft-ietf-trill- 271 rbridge-protocol-14.txt, Work in Progress, October 2009. 273 Appendix A: Initial IANA NLPID Web Page 275 NLPIDs of Interest 277 Code Point Use 278 ---------- -------- 279 0x00 Null 280 0x80 IEEE SNAP (RFC this document) 281 0x81 ISO CLNP (Connectionless Network Protocol) 282 0x82 ISO ES-IS 283 0x83 IS-IS (RFC 1195) 284 0x8E IPv6 (RFC 2460) 285 0xC0 TRILL (draft-ietf-trill-rbridge-protocol) 286 0xC1 IEEE 802.1aq 287 0xCC IPv4 (RFC 791) 288 0xCF PPP (RFC 1661) 290 Note: According to [RFC1707], NLPID 0x70 was assigned to IPv7. That 291 assignment appears to no longer be in effect as it is not listed in 292 ISO/IEC 9577. IPv7 was itself a temporary code point assignment made 293 while a decision was being made between three candidates for the next 294 generation of IP after IPv4. Those candidates were assigned IPv6, 295 IPv7, and IPv8. IPv6 was selected. 297 RFC Editor Note: In "(RFC this document)" above, "this document" 298 should be replaced with the RFC number assigned to this document and 299 this paragraph deleted before publication. 301 Appendix B: RFC References to NLPID 303 The following RFCs, issued before the end of March 2009, excluding 304 other survey RFCs and obsolete RFCs, reference the NLPID as such: 306 RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual 307 Environments 308 RFC 1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet 309 Mode 310 RFC 1377 The PPP OSI Network Layer Control Protocol (OSINLCP) 311 RFC 1661 The Point-to-Point Protocol (PPP) 312 RFC 1707 CATNIP: Common Architecture for the Internet 313 RFC 1755 ATM Signaling Support for IP over ATM 314 RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks 315 RFC 2332 NBMA Next Hop Resolution Protocol (NHRP) 316 RFC 2337 Intra-LIS IP multicast among routers over ATM using Sparse 317 Mode PIM 318 RFC 2363 PPP Over FUNI 319 RFC 2390 Inverse Address Resolution Protocol 320 RFC 2427 Multiprotocol Interconnect over Frame Relay 321 RFC 2590 Transmission of IPv6 Packets over Frame Relay Networks 322 Specification 323 RFC 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5 324 RFC 2955 Definitions of Managed Objects for Monitoring and 325 Controlling the Frame Relay/ATM PVC Service Interworking 326 Function 327 RFC 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay 328 RFC 5308 Routing IPv6 with IS-IS 330 Copyright and IPR Provisions 332 Copyright (c) 2009 IETF Trust and the persons identified as the 333 document authors. All rights reserved. 335 This document is subject to BCP 78 and the IETF Trust's Legal 336 Provisions Relating to IETF Documents in effect on the date of 337 publication of this document (http://trustee.ietf.org/license-info). 338 Please review these documents carefully, as they describe your rights 339 and restrictions with respect to this document. 341 The definitive version of an IETF Document is that published by, or 342 under the auspices of, the IETF. Versions of IETF Documents that are 343 published by third parties, including those that are translated into 344 other languages, should not be considered to be definitive versions 345 of IETF Documents. The definitive version of these Legal Provisions 346 is that published by, or under the auspices of, the IETF. Versions of 347 these Legal Provisions that are published by third parties, including 348 those that are translated into other languages, should not be 349 considered to be definitive versions of these Legal Provisions. For 350 the avoidance of doubt, each Contributor to the IETF Standards 351 Process licenses each Contribution that he or she makes as part of 352 the IETF Standards Process to the IETF Trust pursuant to the 353 provisions of RFC 5378. No language to the contrary, or terms, 354 conditions or rights that differ from or are inconsistent with the 355 rights and licenses granted under RFC 5378, shall have any effect and 356 shall be null and void, whether published or posted by such 357 Contributor, or included with or in such Contribution. 359 Author's Address 361 Donald E. Eastlake 3rd 362 Stellar Switches, Inc. 363 155 Beaver Street 364 Milford, MA 01757 USA 366 tel: +1-508-634-2066 367 email: d3e3e3@gmail.com