idnits 2.17.1 draft-eastlake-rfc7042bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 12, 2016) is 2685 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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 Huawei 3 Obsoletes: 7042 Joe Abley 4 Intended Status: Best Current Practice Dyn, Inc. 5 Expires: June 11, 2016 December 12, 2016 7 IANA Considerations and IETF Protocol and Documentation Usage 8 for IEEE 802 Parameters 9 11 Abstract 13 Some IETF protocols make use of Ethernet frame formats and IEEE 802 14 parameters. This document discusses several uses of such parameters 15 in IETF protocols, specifies IANA considerations for assignment of 16 points under the IANA OUI (Organizationally Unique Identifier), and 17 provides some values for use in documentation. This document 18 obsoletes RFC 7042. 20 Status of This Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Distribution of this document is unlimited. Comments should be sent 26 to the authors. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 40 Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Table of Contents 45 1. Introduction............................................3 46 1.1 Notations Used in This Document........................3 47 1.2 Changes from RFC 7042..................................4 48 1.3 The IEEE Registration Authority........................4 49 1.4 The IANA OUI...........................................4 51 2. Ethernet Identifier Parameters..........................5 52 2.1 48-Bit MAC Identifiers, OUIs, and Other Prefixes.......5 53 2.1.1 EUI-48 Assignments under the IANA OUI................6 54 2.1.2 EUI-48 Documentation Values..........................7 55 2.1.3 EUI-48 IANA Assignment Considerations................7 56 2.2 64-Bit MAC Identifiers.................................7 57 2.2.1. IPv6 Use of Modified EUI-64 Identifiers.............8 58 2.2.2 EUI-64 IANA Assignment Considerations................9 59 2.2.3 EUI-64 Documentation Values.........................11 60 2.3 Other MAC-48 Identifiers Used by the IETF.............11 61 2.3.1 Identifiers Prefixed '33-33'........................11 62 2.3.2 The 'CF Series'.....................................12 63 2.3.2.1 Changes to RFC 2153...............................12 65 3. Ethernet Protocol Parameters...........................13 66 3.1 Ethernet Protocol Assignment under the IANA OUI.......14 67 3.2 Documentation Protocol Number.........................15 69 4. Other OUI-Based Parameters............................16 71 5. IANA Considerations...................................17 72 5.1 Expert Review and IESG Ratification...................17 73 5.2 MAC Address AFNs and RRTYPEs..........................18 74 5.3 Informational IANA Web Page Material..................19 75 5.4 OUI Exhaustion........................................19 76 5.5 IANA OUI MAC Address Table............................19 77 5.6 SNAP Protocol Number Table and Assignment.............19 79 6. Security Considerations................................20 80 7. Acknowledgements.......................................20 82 8. References.............................................21 83 8.1 Normative References..................................21 84 8.2 Informative References................................21 86 Appendix A. Templates.....................................24 87 A.1 EUI-48/EUI-64 Identifier or Identifier Block Template.24 88 A.2 IANA OUI-Based Protocol Number Template...............24 89 A.3 Other IANA OUI-Based Parameter Template...............25 91 Appendix B. Ethertypes...................................26 92 B.1. Some Ethertypes Specified by the IETF...............26 93 B.2. Some IEEE 802 Ethertypes............................26 95 1. Introduction 97 Some IETF protocols use Ethernet or other IEEE 802-related 98 communication frame formats and parameters [IEEE802]. These include 99 MAC (Media Access Control) identifiers and protocol identifiers. 101 This document specifies IANA considerations for the assignment of 102 code points under the IANA OUI. It also discusses several other uses 103 by the IETF of IEEE 802 code points and provides some values for use 104 in documentation. As noted in [RFC2606] and [RFC5737], the use of 105 designated code values reserved for documentation and examples 106 reduces the likelihood of conflicts and confusion arising from their 107 duplication of code points assigned for some deployed use. 109 [RFC5226] is incorporated herein except where there are contrary 110 provisions in this document. In this document, "IESG Ratification" 111 is used in some cases, and it is specified in Section 5.1. This is 112 not the same as "IESG Approval" in [RFC5226]. 114 1.1 Notations Used in This Document 116 This document uses hexadecimal notation. Each octet (that is, 8-bit 117 byte) is represented by two hexadecimal digits giving the value of 118 the octet as an unsigned integer. Successive octets are separated by 119 a hyphen. This document consistently uses IETF bit ordering although 120 the physical order of bit transmission within an octet on an IEEE 121 [802.3] link is from the lowest order bit to the highest order bit 122 (i.e., the reverse of the IETF's ordering). 124 In this document: 126 "AFN" stands for Address Family Number [RFC4760]. 128 "EUI" stands for Extended Unique Identifier. 130 "IAB" stands for Individual Address Block, not for Internet 131 Architecture Board. 133 "MAC" stands for Media Access Control, not for Message 134 Authentication Code. 136 "OUI" stands for Organizationally Unique Identifier. 138 "RRTYPE" stands for a DNS Resource Record type [RFC6895]. 140 "**" indicates exponentiation. For example, 2**24 is two to the 141 twenty-fourth power. 143 1.2 Changes from RFC 7042 145 This document obsoletes [RFC7042] and makes the changes listed below. 146 However, the template based on which an IANA OUI-based protocol 147 number value was assigned for document use remains that in Appendix C 148 of RFC 7042. 150 o TBD 152 1.3 The IEEE Registration Authority 154 Originally the responsibility of Xerox Corporation, the registration 155 authority for Ethernet parameters is now the IEEE Registration 156 Authority, available on the web at: 158 http://standards.ieee.org/regauth/ 160 Anyone may apply to that Authority for parameters. The IEEE 161 Registration Authority may impose fees or other requirements but 162 commonly waives fees for applications from standards development 163 organizations. 165 A list of some assignments and their holders is downloadable from the 166 IEEE Registration Authority site. 168 1.4 The IANA OUI 170 The OUI 00-00-5E has been assigned to IANA. 172 There is no OUI value reserved at this time for documentation, but 173 there are documentation code points under the IANA OUI specified 174 below. 176 2. Ethernet Identifier Parameters 178 Section 2.1 discusses EUI-48 (Extended Unique Identifier 48) MAC 179 identifiers, their relationship to OUIs and other prefixes, and 180 assignments under the IANA OUI. Section 2.2 extends this to EUI-64 181 identifiers. Section 2.3 discusses other IETF MAC identifier use not 182 under the IANA OUI. 184 [RAC-OUI] indicates that the IEEE Registration Authority Committee is 185 exploring the feasibility of defining a new "EUI-128" identifier. 187 2.1 48-Bit MAC Identifiers, OUIs, and Other Prefixes 189 48-bit MAC "addresses" are the most commonly used Ethernet interface 190 identifiers. Those that are globally unique are also called EUI-48 191 identifiers. An EUI-48 is structured into an initial 3-octet OUI 192 (Organizationally Unique Identifier) and an additional 3 octets 193 assigned by the OUI holder or into a larger initial prefix assigned 194 to an organization and a shorter sequence of additional bits so as to 195 add up to 48 bits in total. For example, the IEEE has assigned IABs 196 (Individual Address Blocks), where the first 4 1/2 octets (36 bits) 197 are assigned, giving the holder of the IAB 1 1/2 octets (12 bits) 198 they can control; however, IABs will become historic, and a wider 199 range of prefix lengths will be made available [RAC-OUI]. 201 The IEEE describes its assignment procedures and policies for IEEE 202 802-related identifiers in [802_O&A], which is being revised. 204 Two bits within the initial octet of an EUI-48 have special 205 significance in MAC addresses: the Group bit (01) and the Local bit 206 (02). OUIs and longer MAC prefixes are assigned with the Local bit 207 zero and the Group bit unspecified. Multicast identifiers may be 208 constructed by turning on the Group bit, and unicast identifiers may 209 be constructed by leaving the Group bit zero. 211 The Local bit is zero for globally unique EUI-48 identifiers assigned 212 by the owner of an OUI or owner of a longer prefix. If the Local bit 213 is a one, the identifier has been considered by IEEE 802 to be a 214 local identifier under the control of the local network 215 administrator; however, there may be emerging recommendations from 216 the IEEE Registration Authority on management of the local address 217 space. If the Local bit is on, the holder of an OUI has no special 218 authority over MAC identifiers whose first 3 octets correspond to 219 their OUI. 221 An AFN and a DNS RRTYPE have been assigned for 48-bit MAC addresses 222 (see Section 5.2). 224 2.1.1 EUI-48 Assignments under the IANA OUI 226 The OUI 00-00-5E has been assigned to IANA as stated in Section 1.4 227 above. This includes 2**24 EUI-48 multicast identifiers from 228 01-00-5E-00-00-00 to 01-00-5E-FF-FF-FF and 2**24 EUI-48 unicast 229 identifiers from 00-00-5E-00-00-00 to 00-00-5E-FF-FF-FF. 231 Of these EUI-48 identifiers, the sub-blocks reserved or thus far 232 assigned by IANA for purposes of documentation are as follows: 234 Unicast, all blocks of 2**8 addresses thus far: 236 00-00-5E-00-00-00 through 00-00-5E-00-00-FF: reserved and require 237 IESG Ratification for assignment (see Section 5.1). 239 00-00-5E-00-01-00 through 00-00-5E-00-01-FF: assigned for the 240 Virtual Router Redundancy Protocol (VRRP) [RFC5798]. 242 00-00-5E-00-02-00 through 00-00-5E-00-02-FF: assigned for the IPv6 243 Virtual Router Redundancy Protocol (IPv6 VRRP) [RFC5798]. 245 00-00-5E-00-52-00 through 00-00-5E-00-52-FF: used for very small 246 assignments. Currently, 3 out of these 256 values have been 247 assigned. 249 00-00-5E-00-53-00 through 00-00-5E-00-53-FF: assigned for use in 250 documentation. 252 Multicast: 254 01-00-5E-00-00-00 through 01-00-5E-7F-FF-FF: 2**23 addresses 255 assigned for IPv4 multicast [RFC1112]. 257 01-00-5E-80-00-00 through 01-00-5E-8F-FF-FF: 2**20 addresses 258 assigned for MPLS multicast [RFC5332]. 260 01-00-5E-90-00-00 through 01-00-5E-90-00-FF: 2**8 addresses being 261 used for very small assignments. Currently, 4 out of these 256 262 values have been assigned. 264 01-00-5E-90-10-00 through 01-00-5E-90-10-FF: 2**8 addresses for 265 use in documentation. 267 For more detailed and up-to-date information, see the "Ethernet 268 Numbers" registry at http://www.iana.org. 270 2.1.2 EUI-48 Documentation Values 272 The following values have been assigned for use in documentation: 274 00-00-5E-00-53-00 through 00-00-5E-00-53-FF for unicast and 276 01-00-5E-90-10-00 through 01-00-5E-90-10-FF for multicast. 278 2.1.3 EUI-48 IANA Assignment Considerations 280 EUI-48 assignments under the current or a future IANA OUI (see 281 Section 5.4) must meet the following requirements: 283 o must be for standards purposes (either for an IETF Standard or 284 other standard related to IETF work), 286 o must be for a power-of-two size block of identifiers starting 287 at a boundary that is an equal or greater power of two, 288 including the assignment of one (2**0) identifier, 290 o must not be used to evade the requirement for vendors to obtain 291 their own block of identifiers from the IEEE, and 293 o must be documented in an Internet-Draft or RFC. 295 In addition, approval must be obtained as follows (see the procedure 296 in Section 5.1): 298 Small to medium assignments of a block of 1, 2, 4, ..., 32768, 299 65536 (2**0, 2**1, 2**2, ..., 2**15, 2**16) EUI-48 identifiers 300 require Expert Review (see Section 5.1). 302 Large assignments of 131072 (2**17) or more EUI-48 identifiers 303 require IESG Ratification (see Section 5.1). 305 2.2 64-Bit MAC Identifiers 307 IEEE also defines a system of 64-bit MAC identifiers including 308 EUI-64s. EUI-64 identifiers are currently used as follows: 310 o In a modified form to construct some IPv6 interface identifiers 311 as described in Section 2.2.1 313 o In IEEE Std 1394 (also known as FireWire and i.Link) 315 o In IEEE Std 802.15.4 (also known as ZigBee) 316 o In [InfiniBand] 318 Adding a 5-octet (40-bit) extension to a 3-octet (24-bit) OUI, or a 319 shorter extension to longer assigned prefixes [RAC-OUI] so as to 320 total 64 bits, produces an EUI-64 identifier under that OUI or longer 321 prefix. As with EUI-48 identifiers, the first octet has the same 322 Group and Local bits. 324 An AFN and a DNS RRTYPE have been assigned for 64-bit MAC addresses 325 (see Section 5.2). 327 The discussion below is almost entirely in terms of the "Modified" 328 form of EUI-64 identifiers; however, anyone assigned such an 329 identifier can also use the unmodified form as a MAC identifier on 330 any link that uses such 64-bit identifiers for interfaces. 332 2.2.1. IPv6 Use of Modified EUI-64 Identifiers 334 MAC-64 identifiers are used to form the lower 64 bits of some IPv6 335 addresses (Section 2.5.1 and Appendix A of [RFC4291] and Appendix A 336 of [RFC5214]). When so used, the MAC-64 is modified by inverting the 337 Local/Global bit to form an IETF "Modified EUI-64 identifier". Below 338 is an illustration of a Modified EUI-64 unicast identifier under the 339 IANA OUI, where aa-bb-cc-dd-ee is the extension. 341 02-00-5E-aa-bb-cc-dd-ee 343 The first octet is shown as 02 rather than 00 because, in Modified 344 EUI-64 identifiers, the sense of the Local/Global bit is inverted 345 compared with EUI-48 identifiers. It is the globally unique values 346 (universal scope) that have the 02 bit on in the first octet, while 347 those with this bit off are locally assigned and out of scope for 348 global assignment. 350 The Local/Global bit was inverted to make it easier for network 351 operators to type in local-scope identifiers. Thus, such Modified 352 EUI-64 identifiers as 1, 2, etc. (ignoring leading zeros) are local. 353 Without the modification, they would have to be 354 02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc. to be local. 356 As with MAC-48 identifiers, the 01 bit on in the first octet 357 indicates a group identifier. 359 When the first two octets of the extension of a Modified EUI-64 360 identifier are FF-FE, the remainder of the extension is a 24-bit 361 value as assigned by the OUI owner for an EUI-48. For example: 363 02-00-5E-FF-FE-yy-yy-yy 365 or 366 03-00-5E-FF-FE-yy-yy-yy 368 where yy-yy-yy is the portion (of an EUI-48 global unicast or 369 multicast identifier) that is assigned by the OUI owner (IANA in this 370 case). Thus, any holder of one or more EUI-48 identifiers under the 371 IANA OUI also has an equal number of Modified EUI-64 identifiers that 372 can be formed by inserting FF-FE in the middle of their EUI-48 373 identifiers and inverting the Local/Global bit. 375 (Note: [EUI-64] defines FF-FF as the bits to be inserted to create 376 an IEEE EUI-64 identifier from a MAC-48 identifier. That document 377 says the FF-FE value is used when starting with an EUI-48 378 identifier. The IETF uses only FF-FE to create Modified EUI-64 379 identifiers from 48-bit Ethernet station identifiers regardless of 380 whether they are EUI-48 or MAC-48 local identifiers. EUI-48 and 381 local MAC-48 identifiers are syntactically equivalent, and this 382 doesn't cause any problems in practice.) 384 In addition, certain Modified EUI-64 identifiers under the IANA OUI 385 are reserved for holders of IPv4 addresses as follows: 387 02-00-5E-FE-xx-xx-xx-xx 389 where xx-xx-xx-xx is a 32-bit IPv4 address. The owner of an IPv4 390 address has both the unicast- and multicast-derived EUI-64 address. 391 Modified EUI-64 identifiers from 393 02-00-5E-FE-F0-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF 395 are effectively reserved pending the specification of IPv4 Class E 396 addresses. However, for Modified EUI-64 identifiers based on an IPv4 397 address, the Local/Global bit should be set to correspond to whether 398 the IPv4 address is local or global. (Keep in mind that the sense of 399 the Modified EUI-64 identifier Local/Global bit is reversed from that 400 in (unmodified) MAC-64 identifiers.) 402 2.2.2 EUI-64 IANA Assignment Considerations 404 The following table shows which Modified EUI-64 identifiers under the 405 IANA OUI are reserved, assigned, or available as indicated. As noted 406 above, the corresponding MAC addresses can be determined by 407 complementing the 02 bit in the first octet. In all cases, the 408 corresponding multicast 64-bit MAC addresses formed by complementing 409 the 01 bit in the first octet have the same status as the modified 410 64-bit unicast address blocks listed below. 412 02-00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF reserved 413 02-00-5E-10-00-00-00-00 to 02-00-5E-10-00-00-00-FF assigned for 414 documentation use 416 02-00-5E-10-00-00-01-00 to 02-00-5E-EF-FF-FF-FF-FF available for 417 assignment 419 02-00-5E-F0-00-00-00-00 to 02-00-5E-FD-FF-FF-FF-FF reserved 421 02-00-5E-FE-00-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF assigned to 422 IPv4 address holders as described above 424 02-00-5E-FF-00-00-00-00 to 02-00-5E-FF-FD-FF-FF-FF reserved 426 02-00-5E-FF-FE-00-00-00 to 02-00-5E-FF-FE-FF-FF-FF assigned for 427 holders of EUI-48 identifiers under the IANA OUI as described 428 above 430 02-00-5E-FF-FF-00-00-00 to 02-00-5E-FF-FF-FF-FF-FF reserved 432 The reserved identifiers above require IESG Ratification (see Section 433 5.1) for assignment. IANA EUI-64 identifier assignments under the 434 IANA OUI must meet the following requirements: 436 o must be for standards purposes (either for an IETF Standard or 437 other standard related to IETF work), 439 o must be for a power-of-two size block of identifiers starting 440 at a boundary that is an equal or greater power of two, 441 including the assignment of one (2**0) identifier, 443 o must not be used to evade the requirement for vendors to obtain 444 their own block of identifiers from the IEEE, and 446 o must be documented in an Internet-Draft or RFC. 448 In addition, approval must be obtained as follows (see the procedure 449 in Section 5.1): 451 Small to medium assignments of a block of 1, 2, 4, ..., 134217728, 452 268435456 (2**0, 2**1, 2**2, ..., 2**27, 2**28) EUI-64 453 identifiers require Expert Review (see Section 5.1). 455 Assignments of any size, including 536870912 (2**29) or more 456 EUI-64 identifiers, may be made with IESG Ratification (see 457 Section 5.1). 459 2.2.3 EUI-64 Documentation Values 461 The following blocks of unmodified 64-bit MAC addresses are for 462 documentation use. The IPv4-derived addresses are based on the IPv4 463 documentation addresses [RFC5737], and the MAC-derived addresses are 464 based on the EUI-48 documentation addresses above. 466 Unicast: 468 00-00-5E-EF-10-00-00-00 to 00-00-5E-EF-10-00-00-FF general 470 00-00-5E-FE-C0-00-02-00 to 00-00-5E-FE-C0-00-02-FF and 471 00-00-5E-FE-C6-33-64-00 to 00-00-5E-FE-C6-33-64-FF and 472 00-00-5E-FE-CB-00-71-00 to 00-00-5E-FE-CB-00-71-FF IPv4 derived 474 00-00-5E-FF-FE-00-53-00 to 00-00-5E-FF-FE-00-53-FF EUI-48 derived 476 00-00-5E-FE-EA-C0-00-02 and 477 00-00-5E-FE-EA-C6-33-64 and 478 00-00-5E-FE-EA-CB-00-71 IPv4 multicast derived from IPv4 unicast 479 [RFC6034] 481 Multicast: 483 01-00-5E-EF-10-00-00-00 to 01-00-5E-EF-10-00-00-FF general 485 01-00-5E-FE-C0-00-02-00 to 01-00-5E-FE-C0-00-02-FF and 486 01-00-5E-FE-C6-33-64-00 to 01-00-5E-FE-C6-33-64-FF and 487 01-00-5E-FE-CB-00-71-00 to 01-00-5E-FE-CB-00-71-FF IPv4 derived 489 01-00-5E-FE-EA-C0-00-02 and 490 01-00-5E-FE-EA-C6-33-64 and 491 01-00-5E-FE-EA-CB-00-71 IPv4 multicast derived from IPv4 unicast 492 [RFC6034] 494 01-00-5E-FF-FE-90-10-00 to 01-00-5E-FF-FE-90-10-FF EUI-48 derived 496 2.3 Other MAC-48 Identifiers Used by the IETF 498 There are two other blocks of MAC-48 identifiers that are used by the 499 IETF as described below. 501 2.3.1 Identifiers Prefixed '33-33' 503 All MAC-48 multicast identifiers prefixed "33-33" (that is, the 2**32 504 multicast MAC identifiers in the range from 33-33-00-00-00-00 to 505 33-33-FF-FF-FF-FF) are used as specified in [RFC2464] for IPv6 506 multicast. In all of these identifiers, the Group bit (the bottom 507 bit of the first octet) is on, as is required to work properly with 508 existing hardware as a multicast identifier. They also have the 509 Local bit on and are used for this purpose in IPv6 networks. 511 (Historical note: It was the custom during IPv6 design to use "3" 512 for unknown or example values, and 3333 Coyote Hill Road, Palo 513 Alto, California, is the address of PARC (Palo Alto Research 514 Center, formerly "Xerox PARC"). Ethernet was originally specified 515 by the Digital Equipment Corporation, Intel Corporation, and Xerox 516 Corporation. The pre-IEEE [802.3] Ethernet protocol has sometimes 517 been known as "DIX" Ethernet from the first letters of the names 518 of these companies.) 520 2.3.2 The 'CF Series' 522 The Informational [RFC2153] declared the 3-octet values from CF-00-00 523 through CF-FF-FF to be OUIs available for assignment by IANA to 524 software vendors for use in PPP [RFC1661] or for other uses where 525 vendors do not otherwise need an IEEE-assigned OUI. It should be 526 noted that, when used as MAC-48 prefixes, these values have the Local 527 and Group bits on, while all IEEE-assigned OUIs thus far have those 528 bits off. The Group bit is meaningless in PPP. To quote [RFC2153]: 529 "The 'CF0000' series was arbitrarily chosen to match the PPP NLPID 530 'CF', as a matter of mnemonic convenience." 532 CF-00-00 is reserved, and IANA lists multicast identifier 533 CF-00-00-00-00-00 as used for Ethernet loopback tests. 535 In over a decade of availability, only a handful of values in the CF 536 Series have been assigned. (See "Ethernet Numbers" 537 and "PPP Numbers" 538 ). 540 2.3.2.1 Changes to RFC 2153 542 The IANA Considerations in [RFC2153] were updated as follows by the 543 approval of RFC 5342 (no technical changes have been made): 545 o Use of these identifiers based on IANA assignment was 546 deprecated. 548 o IANA was instructed not to assign any further values in the 'CF 549 Series'. 551 3. Ethernet Protocol Parameters 553 Ethernet protocol parameters provide a means of indicating the 554 contents of a frame -- for example, that its contents are IPv4 or 555 IPv6. 557 The concept has been extended to labeling by "tags". A tag in this 558 sense is a prefix whose type is identified by an Ethertype that is 559 then followed by either another tag, an Ethertype, or an LSAP (Link- 560 Layer Service Access Point) protocol indicator for the "main" body of 561 the frame, as described below. Traditionally, in the [802_O&A] 562 world, tags are a fixed length and do not include any encoding of 563 their own length. Any device that is processing a frame cannot, in 564 general, safely process anything in the frame past an Ethertype it 565 does not understand. An example is the C-Tag (formerly the Q-Tag) 566 [802.1Q]. It provides customer VLAN and priority information for a 567 frame. 569 There are two types of protocol identifier parameters that can occur 570 in Ethernet frames after the initial MAC-48 destination and source 571 identifiers: 573 Ethertypes: These are 16-bit identifiers appearing as the initial 574 two octets after the MAC destination and source (or after a 575 tag), which, when considered as an unsigned integer, are equal 576 to or larger than 0x0600. 578 LSAPs: These are 8-bit protocol identifiers that occur in pairs 579 immediately after an initial 16-bit (two-octet) remaining frame 580 length, which is in turn after the MAC destination and source 581 (or after a tag). Such a length must, when considered as an 582 unsigned integer, be less than 0x5DC, or it could be mistaken 583 as an Ethertype. LSAPs occur in pairs where one is intended to 584 indicate the source protocol handler and one the destination 585 protocol handler; however, use cases where the two are 586 different have been relatively rare. 588 Neither Ethertypes nor LSAPs are assigned by IANA; they are assigned 589 by the IEEE Registration Authority (see Section 1.3 above and 590 Appendix B). However, both LSAPs and Ethertypes have extension 591 mechanisms so that they can be used with five-octet Ethernet protocol 592 identifiers under an OUI, including those assigned by IANA under the 593 IANA OUI. 595 When using the IEEE 802 Logical Link Control (LLC) format (Subnetwork 596 Access Protocol (SNAP)) [802_O&A] for a frame, an OUI-based protocol 597 identifier can be expressed as follows: 599 xx-xx-AA-AA-03-yy-yy-yy-zz-zz 601 where xx-xx is the frame length and, as above, must be small enough 602 not to be confused with an Ethertype; "AA" is the LSAP that indicates 603 this use and is sometimes referred to as the SNAP Service Access 604 Point (SAP); "03" is the LLC control octet indicating datagram 605 service; yy-yy-yy is an OUI; and zz-zz is a protocol number, under 606 that OUI, assigned by the OUI owner. The odd five-octet length for 607 such OUI-based protocol identifiers was chosen so that, with the LLC 608 control octet ("03"), the result is 16-bit aligned. 610 When using an Ethertype to indicate the main type for a frame body, 611 the special "OUI Extended Ethertype" 88-B7 is available. Using this 612 Ethertype, a frame body can begin with 614 88-B7-yy-yy-yy-zz-zz 616 where yy-yy-yy and zz-zz have the same meaning as in the SNAP format 617 described above. 619 It is also possible, within the SNAP format, to use an arbitrary 620 Ethertype. Putting the Ethertype as the zz-zz field after an all- 621 zeros OUI (00-00-00) does this. It looks like 623 xx-xx-AA-AA-03-00-00-00-zz-zz 625 where zz-zz is the Ethertype. 627 (Note that, at this point, the 802 protocol syntax facilities are 628 sufficiently powerful that they could be chained indefinitely. 629 Whether support for such chaining is generally required is not 630 clear, but [802_O&A] requires support for 632 xx-xx-AA-AA-03-00-00-00-88-B7-yy-yy-yy-zz-zz 634 although this could be more efficiently expressed by simply 635 pinching out the "00-00-00-88-B7" in the middle.) 637 As well as labeling frame contents, 802 protocol types appear within 638 NBMA (Non-Broadcast Multi-Access) Next Hop Resolution Protocol 639 [RFC2332] messages. Such messages have provisions for both two-octet 640 Ethertypes and OUI-based protocol types. 642 3.1 Ethernet Protocol Assignment under the IANA OUI 644 Two-octet protocol numbers under the IANA OUI are available, as in 646 xx-xx-AA-AA-03-00-00-5E-qq-qq 648 where qq-qq is the protocol number. 650 A number of such assignments have been made out of the 2**16 protocol 651 numbers available from 00-00-5E-00-00 to 00-00-5E-FF-FF (see [IANA]). 652 The extreme values of this range, 00-00-5E-00-00 and 00-00-5E-FF-FF, 653 are reserved and require IESG Ratification for assignment (see 654 Section 5.1). New assignments of SNAP SAP protocol (qq-qq) numbers 655 under the IANA OUI must meet the following requirements: 657 o the assignment must be for standards use (either for an IETF 658 Standard or other standard related to IETF work), 660 o it must be documented in an Internet-Draft or RFC, and 662 o such protocol numbers are not to be assigned for any protocol 663 that has an Ethertype (because that can be expressed by putting 664 an all-zeros "OUI" before the Ethertype as described above). 666 In addition, the Expert Review (or IESG Ratification for the two 667 reserved values) must be obtained using the procedure specified in 668 Section 5.1. 670 3.2 Documentation Protocol Number 672 0x0042 is a protocol number under the IANA OUI (that is, 673 00-00-5E-00-42) to be used as an example for documentation purposes. 675 4. Other OUI-Based Parameters 677 Some IEEE 802 and other protocols provide for parameters based on an 678 OUI beyond those discussed above. Such parameters most commonly 679 consist of an OUI plus one octet of additional value. They are 680 usually called "vendor specific" parameters, although "organization 681 specific" might be more accurate. They would look like 683 yy-yy-yy-zz 685 where yy-yy-yy is the OUI and zz is the additional specifier. An 686 example is the Cipher Suite Selector in IEEE [802.11]. 688 Values may be assigned under the IANA OUI for such other OUI-based 689 parameter usage by Expert Review except that, for each use, the 690 additional specifier values consisting of all zero bits and all one 691 bits (0x00 (00-00-5E-00) and 0xFF (00-00-5E-FF) for a one-octet 692 specifier) are reserved and require IESG Ratification (see Section 693 5.1) for assignment; also, the additional specifier value 0x42 694 (00-00-5E-42) is assigned for use as an example in documentation. 696 Assignments of such other IANA OUI-based parameters must be for 697 standards use (either for an IETF Standard or other standard related 698 to IETF work) and be documented in an Internet-Draft or RFC. The 699 first time a value is assigned for a particular parameter of this 700 type, an IANA registry will be created to contain that assignment and 701 any subsequent assignments of values for that parameter under the 702 IANA OUI. The Expert will specify the name of the registry. 704 If different policies from those above are required for such a 705 parameter, a BCP or Standards Track RFC must be adopted to update 706 this BCP and specify the new policy and parameter. 708 5. IANA Considerations 710 The entirety of this document concerns IANA considerations for the 711 assignment of Ethernet parameters in connection with the IANA OUI and 712 related matters. 714 As this document replaces [RFC7042], references to [RFC7042] in IANA 715 registries will be replaced by references to this document. 717 This document does not create any new IANA registries. 719 The MAC address values assigned for documentation and the protocol 720 number for documentation were assigned by [RFC7042]. 722 No existing assignment is changed by this document. 724 5.1 Expert Review and IESG Ratification 726 This section specifies the procedure for Expert Review and IESG 727 Ratification of MAC, protocol, and other IANA OUI-based identifiers. 728 The Expert(s) referred to in this document shall consist of one or 729 more persons appointed by and serving at the pleasure of the IESG. 731 The procedure described for Expert Review assignments in this 732 document is fully consistent with the IANA Expert Review policy 733 described in [RFC5226]. 735 While finite, the universe of code points from which Expert-judged 736 assignments will be made is felt to be large enough that the 737 requirements given in this document and the Experts' good judgment 738 are sufficient guidance. The idea is for the Expert to provide a 739 light sanity check for small assignments of EUI identifiers, with 740 increased scrutiny by the Expert for medium-sized assignments of EUI 741 identifiers and assignments of protocol identifiers and other IANA 742 OUI-based parameters. However, it can make sense to assign very 743 large portions of the MAC identifier code point space. (Note that 744 existing assignments include one for 1/2 of the entire multicast IANA 745 EUI-48 code point space and one for 1/16 of that multicast code point 746 space.) In those cases, and in cases of the assignment of "reserved" 747 values, IESG Ratification of an Expert Review approval recommendation 748 is required as described below. The procedure is as follows: 750 The applicant always completes the appropriate template from 751 Appendix A below and sends it to IANA . 753 IANA always sends the template to an appointed Expert. If the 754 Expert recuses themselves or is non-responsive, IANA may choose 755 an alternative appointed Expert or, if none is available, will 756 contact the IESG. 758 In all cases, if IANA receives a disapproval from an Expert 759 selected to review an application template, the application 760 will be denied. 762 If the assignment is based on Expert Review: 764 If IANA receives approval and code points are available, 765 IANA will make the requested assignment. 767 If the assignment is based on IESG Ratification: 769 The procedure starts with the first steps above for Expert 770 Review. If the Expert disapproves the application, they 771 simply inform IANA; however, if the Expert believes the 772 application should be approved, or is uncertain and believes 773 that the circumstances warrant the attention of the IESG, 774 the Expert will inform IANA about their advice, and IANA 775 will forward the application, together with the reasons for 776 approval or uncertainty, to the IESG. The IESG must decide 777 whether the assignment will be granted. This can be 778 accomplished by a management item in an IESG telechat as is 779 done for other types of requests. If the IESG decides not 780 to ratify a favorable opinion by the Expert or decides 781 against an application where the Expert is uncertain, the 782 application is denied; otherwise, it is granted. The IESG 783 will communicate its decision to the Expert and to IANA. 785 5.2 MAC Address AFNs and RRTYPEs 787 IANA has assigned Address Family Numbers (AFNs) for MAC addresses as 788 follows: 790 AFN Decimal Hex Reference 791 ---------- ------- ------ --------- 792 48-bit MAC 16389 0x4005 [RFC7042] 793 64-bit MAC 16390 0x4006 [RFC7042] 795 IANA has assigned DNS RRTYPEs [RFC6895] for MAC addresses as follows: 797 RRTYPE Code 798 Data Mnemonic Decimal Hex Reference 799 ---------- -------- ------- ------ ----------- 800 48-bit MAC EUI48 108 0x006C [RFC7043] 801 64-bit MAC EUI64 109 0x006D [RFC7043] 803 5.3 Informational IANA Web Page Material 805 IANA maintains an informational listing on its web site concerning 806 Ethertypes, OUIs, and multicast addresses assigned under OUIs other 807 than the IANA OUI. The title of this informational registry is "IEEE 808 802 Numbers". IANA has merged in those Ethertypes listed in Appendix 809 B that were not already included. IANA will update that 810 informational registry when changes are provided by the Expert. 812 5.4 OUI Exhaustion 814 When the available space for either multicast or unicast EUI-48 815 identifiers under OUI 00-00-5E has been 90% or more exhausted, IANA 816 should request an additional OUI from the IEEE Registration Authority 817 for further IANA assignment. The appointed Expert(s) should monitor 818 for this condition and notify IANA. 820 5.5 IANA OUI MAC Address Table 822 No changes have been made in the "IANA Unicast 48-bit MAC Addresses" 823 and "IANA Multicast 48-bit MAC Addresses" tables except for the 824 updates to references as specified in the first part of Section 5. 826 5.6 SNAP Protocol Number Table and Assignment 828 The "SNAP PROTOCOL IDs" table has been renamed the "SNAP Protocol 829 Numbers" table. "PID" has been replaced by "Protocol Number". 831 IANA has assigned 0x0042 as the SNAP protocol number under the IANA 832 OUI to be used for documentation purposes. 834 6. Security Considerations 836 This document is concerned with assignment of parameters under the 837 IANA OUI and closely related matters. It is not directly concerned 838 with security except as follows. 840 Confusion and conflict can be caused by the use of MAC addresses or 841 other OUI-derived protocol parameters as examples in documentation. 842 Examples used "only" in documentation can end up being coded and 843 released or cause conflicts due to later real use and the possible 844 acquisition of intellectual property rights in such addresses or 845 parameters. The reservation herein of MAC addresses and parameters 846 for documentation purposes will minimize such confusion and conflict. 848 See [RFC7043] for security considerations in storing MAC addresses in 849 the DNS. 851 7. Acknowledgements 853 The comments and suggestions of the following people, listed in 854 alphabetic order, are gratefully acknowledged: 856 This Document: 857 TBD 859 RFC 7042 (which was obsoleted by this document): 860 David Black, Adrian Farrel, Bob Grow, Joel Jaeggli, Pearl 861 Liang, Glenn Parsons, Pete Resnick, and Dan Romascanu. 863 The document was prepared in raw nroff. All macros used were defined 864 within the source file. 866 8. References 868 8.1 Normative References 870 [802_O&A] - "IEEE Standard for Local and Metropolitan Area Networks: 871 Overview and Architecture", IEEE Std 802-2001, 8 March 2002. 873 "IEEE Standard for Local and Metropolitan Area Networks: 874 Overview and Architecture / Amendment 1: Ethertypes for 875 Prototype and Vendor-Specific Protocol Development", IEEE Std 876 802a-2003, 18 September 2003. 878 802c 880 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 881 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 882 2008. 884 8.2 Informative References 886 [802.1Q] - "IEEE Standard for Local and metropolitan area networks / 887 Media Access Control (MAC) Bridges and Virtual Bridge Local 888 Area Networks", IEEE Std 802.1Q-2011, 31 August 2011. 890 [802.3] - "IEEE Standard for Ethernet", IEEE Std 802.3-2012, 28 891 December 2012. 893 [802.11] - "IEEE Standard for Information technology / 894 Telecommunications and information exchange between systems / 895 Local and metropolitan area networks / Specific requirements / 896 Part 11: Wireless LAN Medium Access Control (MAC) and Physical 897 Layer (PHY) Specifications", IEEE Std 802.11-2012, 29 March 898 2012. 900 [EUI-64] - IEEE Registration Authority, "Guidelines for 64-bit Global 901 Identifier (EUI-64(TM))", , November 2012. 904 [IANA] - Internet Assigned Numbers Authority, . 906 [IEEE802] - IEEE 802 LAN/MAN Standards Committee, 907 . 909 [InfiniBand] - InfiniBand Trade Association, "InfiniBand Architecture 910 Specification Volume 1", November 2007. 912 [RAC-OUI] - Parsons, G., "OUI Registry Restructuring", Work in 913 Progress, September 2013. 915 [RFC1112] - Deering, S., "Host extensions for IP multicasting", STD 916 5, RFC 1112, August 1989. 918 [RFC1661] - Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 919 STD 51, RFC 1661, July 1994. 921 [RFC2153] - Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997. 923 [RFC2332] - Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. 924 Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 925 2332, April 1998. 927 [RFC2464] - Crawford, M., "Transmission of IPv6 Packets over Ethernet 928 Networks", RFC 2464, December 1998. 930 [RFC2606] - Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 931 Names", BCP 32, RFC 2606, June 1999. 933 [RFC3092] - Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology 934 of "Foo"", RFC 3092, April 1 2001. 936 [RFC4291] - Hinden, R. and S. Deering, "IP Version 6 Addressing 937 Architecture", RFC 4291, February 2006. 939 [RFC4760] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 940 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 942 [RFC5214] - Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 943 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 944 2008. 946 [RFC5332] - Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, 947 "MPLS Multicast Encapsulations", RFC 5332, August 2008. 949 [RFC5737] - Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address 950 Blocks Reserved for Documentation", RFC 5737, January 2010. 952 [RFC5798] - Nadas, S., Ed., "Virtual Router Redundancy Protocol 953 (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 955 [RFC6034] - Thaler, D., "Unicast-Prefix-Based IPv4 Multicast 956 Addresses", RFC 6034, October 2010. 958 [RFC6895] - Eastlake 3rd, D., "Domain Name System (DNS) IANA 959 Considerations", BCP 42, RFC 6895, April 2013. 961 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 962 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 963 BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, 964 . 966 [RFC7043] - Abley, J., "Resource Records for EUI-48 and EUI-64 967 Addresses in the DNS", RFC 7043, October 2013. 969 Appendix A. Templates 971 This appendix provides the specific templates for IANA assignments of 972 parameters. Explanatory words in parentheses in the templates below 973 may be deleted in a completed template as submitted to IANA. 975 A.1 EUI-48/EUI-64 Identifier or Identifier Block Template 977 Applicant Name: 979 Applicant Email: 981 Applicant Telephone: (starting with country code) 983 Use Name: (brief name of Parameter use such as "Foo Protocol" 984 [RFC3092]) 986 Document: (ID or RFC specifying use to which the identifier or block 987 of identifiers will be put.) 989 Specify whether this is an application for EUI-48 or EUI-64 990 identifiers: 992 Size of Block requested: (must be a power-of-two-sized block, can be 993 a block of size one (2**0)) 995 Specify multicast, unicast, or both: 997 A.2 IANA OUI-Based Protocol Number Template 999 Applicant Name: 1001 Applicant Email: 1003 Applicant Telephone: (starting with country code) 1005 Use Name: (brief name of use of code point such as "Foo Protocol") 1007 Document: (ID or RFC specifying use to which the protocol identifier 1008 will be put.) 1010 Note: (any additional note) 1012 A.3 Other IANA OUI-Based Parameter Template 1014 Applicant Name: 1016 Applicant Email: 1018 Applicant Telephone: (starting with country code) 1020 Protocol where the OUI-Based Parameter for which a value is being 1021 requested appears: (such as: Cipher Suite selection in IEEE 802.11) 1023 Use Name: (brief name of use of code point to be assigned, such as 1024 "Foo Cipher Suite" [RFC3092]) 1026 Document: (ID or RFC specifying use to which the other IANA OUI-based 1027 parameter value will be put.) 1029 Note: (any additional note) 1031 Appendix B. Ethertypes 1033 This appendix lists some Ethertypes specified for IETF protocols or 1034 by IEEE 802 as known at the time of publication. A more up-to-date 1035 list may be available on the IANA web site, currently at [IANA]. The 1036 IEEE Registration Authority page of Ethertypes, 1037 http://standards.ieee.org/regauth/ethertype/eth.txt, may also be 1038 useful. See Section 3 above. 1040 B.1. Some Ethertypes Specified by the IETF 1042 0x0800 Internet Protocol Version 4 (IPv4) 1043 0x0806 Address Resolution Protocol (ARP) 1044 0x0808 Frame Relay ARP 1045 0x22F3 TRILL 1046 0x22F4 L2-IS-IS 1047 0x8035 Reverse Address Resolution Protocol (RARP) 1048 0x86DD Internet Protocol Version 6 (IPv6) 1049 0x880B Point-to-Point Protocol (PPP) 1050 0x880C General Switch Management Protocol (GSMP) 1051 0x8847 MPLS 1052 0x8848 MPLS with upstream-assigned label 1053 0x8861 Multicast Channel Allocation Protocol (MCAP) 1054 0x8863 PPP over Ethernet (PPPoE) Discovery Stage 1055 0x8864 PPP over Ethernet (PPPoE) Session Stage 1056 0x893B TRILL Fine Grained Labeling (FGL) 1057 0x8946 TRILL RBridge Channel 1059 B.2. Some IEEE 802 Ethertypes 1061 0x8100 IEEE Std 802.1Q - Customer VLAN Tag Type (C-Tag, formerly 1062 called the Q-Tag) (initially Wellfleet) 1063 0x8808 IEEE Std 802.3 - Ethernet Passive Optical Network (EPON) 1064 0x888E IEEE Std 802.1X - 802.1X Port-based network access control 1065 0x88A8 IEEE Std 802.1Q - Service VLAN tag identifier (S-Tag) 1066 0x88B5 IEEE Std 802 - Local Experimental Ethertype 1067 0x88B6 IEEE Std 802 - Local Experimental Ethertype 1068 0x88B7 IEEE Std 802 - OUI Extended Ethertype 1069 0x88C7 IEEE Std 802.11 - Pre-Authentication (802.11i) 1070 0x88CC IEEE Std 802.1AB - Link Layer Discovery Protocol (LLDP) 1071 0x88E5 IEEE Std 802.1AE - Media Access Control Security 1072 0x88F5 IEEE Std 802.1Q - Multiple VLAN Registration Protocol 1073 (MVRP) 1074 0x88F6 IEEE Std 802.1Q - Multiple Multicast Registration 1075 Protocol (MMRP) 1076 0x890D IEEE Std 802.11 - Used for a variety of 802.11 Protocols: 1078 Fast Roaming Remote Request/Response 1079 Tunnelled Direct Link Setup 1080 Registered Location Query 1081 Fast Sessin Transfer 1082 0x8917 IEEE Std 802.21 - Media Independent Handover Protocol 1083 0x8929 IEEE Std 802.1Qbe - Multiple I-SID Registration Protocol 1084 0x8940 IEEE Std 802.1Qbg - ECP Protocol (also used in 802.1BR) 1086 Authors' Addresses 1088 Donald E. Eastlake 3rd 1089 Huawei Technologies 1090 155 Beaver Street 1091 Milford, MA 01757 1092 USA 1094 Phone: +1-508-634-2066 1095 EMail: d3e3e3@gmail.com 1097 Joe Abley 1098 Dyn, Inc. 1099 470 Moore Street 1100 London, ON N6C 2C2 1101 Canada 1103 Phone: +1 519 670 9327 1104 EMail: jabley@dyn.com 1106 Copyright, Disclaimer, and Additional IPR Provisions 1108 Copyright (c) 2016 IETF Trust and the persons identified as the 1109 document authors. All rights reserved. 1111 This document is subject to BCP 78 and the IETF Trust's Legal 1112 Provisions Relating to IETF Documents 1113 (http://trustee.ietf.org/license-info) in effect on the date of 1114 publication of this document. Please review these documents 1115 carefully, as they describe your rights and restrictions with respect 1116 to this document. Code Components extracted from this document must 1117 include Simplified BSD License text as described in Section 4.e of 1118 the Trust Legal Provisions and are provided without warranty as 1119 described in the Simplified BSD License. This Internet-Draft is 1120 submitted to IETF in full conformance with the provisions of BCP 78 1121 and BCP 79.