idnits 2.17.00 (12 Aug 2021) /tmp/idnits11020/draft-eastlake-rfc7042bis-06.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 document date (March 7, 2022) is 68 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) -- Looks like a reference, but probably isn't: '1' on line 1374 Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Eastlake 2 INTERNET-DRAFT Futurewei Technologies 3 Obsoletes: 7042 J. Abley 4 Intended Status: Best Current Practice Hopcount 5 Expires: September 6, 2022 March 7, 2022 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 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 https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 40 Shadow Directories can be accessed at 41 https://www.ietf.org/shadow.html. 43 Table of Contents 45 1. Introduction............................................4 46 1.1 Notations Used in This Document........................4 47 1.2 Changes from RFC 7042..................................5 48 1.3 The IEEE Registration Authority........................6 49 1.4 The IANA Organizationally Unique Identifier............6 50 1.5 CFM Code Points........................................6 52 2. Ethernet Identifier Parameters..........................8 53 2.1 48-Bit MAC Identifiers, OUIs, and Other Prefixes.......8 54 2.1.1 Special First Octet Bits.............................9 55 2.1.2 OUIs and CIDs.......................................10 56 2.1.3 EUI-48 Assignments under the IANA OUI...............11 57 2.1.4 EUI-48 Documentation Values.........................12 58 2.1.5 EUI-48 IANA Assignment Considerations...............12 59 2.2 64-Bit MAC Identifiers................................13 60 2.2.1. IPv6 Use of Modified EUI-64 Identifiers............13 61 2.2.2 EUI-64 IANA Assignment Considerations...............15 62 2.2.3 EUI-64 Documentation Values.........................16 63 2.3 Other 48-bit MAC Identifiers Used by the IETF.........17 64 2.3.1 Identifiers Prefixed '33-33'........................17 65 2.3.2 The 'CF Series'.....................................17 66 2.3.2.1 Changes to RFC 2153...............................18 67 2.4 CBOR Tags.............................................18 69 3. Ethernet Protocol Parameters...........................19 70 3.1 Ethernet Protocol Assignment under the IANA OUI.......20 71 3.2 Documentation Protocol Number.........................21 73 4. Other OUI-Based Parameters............................22 74 4.1 LLDP IETF Vendor-Specific TLV Type....................22 76 5. IANA Considerations...................................23 77 5.1 Expert Review and IESG Ratification...................23 78 5.2 IANA Web Page Changes.................................24 79 5.3 MAC Address AFNs and RRTYPEs..........................25 80 5.4 Informational IANA Web Page Material..................25 81 5.5 OUI Exhaustion........................................25 82 5.6 IANA OUI MAC Address Table............................26 83 5.7 IANA LLDP TLV Subtypes................................26 84 5.8 CBOR Tag Assignments..................................26 86 6. Security Considerations................................27 87 7. Acknowledgements.......................................27 89 Normative References......................................28 90 Informative References....................................28 92 Table of Contents (continued) 94 Appendix A. Templates.....................................32 95 A.1 EUI-48/EUI-64 Identifier or Identifier Block Template.32 96 A.2 IANA OUI/CID-Based Protocol Number Template...........32 97 A.3 Other IANA OUI/CID-Based Parameter Template...........33 99 Appendix B. Ethertypes...................................34 100 B.1 IESG Statement on Ethertypes..........................34 102 Authors' Addresses........................................35 104 1. Introduction 106 Some IETF protocols use Ethernet or other IEEE 802-related 107 communication frame formats and parameters [IEEE802]. These include 108 MAC (Media Access Control) addresses and protocol identifiers. 110 This document specifies IANA considerations for the assignment of 111 code points under the IANA OUI, including MAC addresses and protocol 112 identifiers, and provides some values for use in documentation. As 113 noted in [RFC2606] and [RFC5737], the use of designated code values 114 reserved for documentation and examples reduces the likelihood of 115 conflicts and confusion arising from their duplication of code points 116 assigned for some deployed use. This document also discusses several 117 other uses by the IETF of IEEE 802 code points, including IEEE 802 118 Connectivity Fault Management (CFM) code points [RFC7319] and IEEE 119 802 Link Local Discovery Protocol (LLDP [802.1AB]) Vaendor-Specific 120 TLV Sub-Types [RFC8520]. It also specifies CBOR tags for MAC 121 addresses and OUI/CIDs. 123 [RFC8126] is incorporated herein except where there are contrary 124 provisions in this document. In this document, "IESG Ratification" 125 is used in some cases. IESG Ratification is specified in Section 5.1. 126 It is not the same as "IESG Approval" in [RFC8126]. 128 1.1 Notations Used in This Document 130 This document uses hexadecimal notation. Each octet (that is, 8-bit 131 byte) is represented by two hexadecimal digits giving the value of 132 the octet as an unsigned integer. Successive octets are separated by 133 a hyphen. This document consistently uses IETF ("network") bit 134 ordering although the physical order of bit transmission within an 135 octet on an IEEE [802.3] link is from the lowest order bit to the 136 highest order bit (i.e., the reverse of the IETF's ordering). 138 In this document: 140 "AFN" Address Family Number [RFC4760]. 142 "CBOR" Conscise Binary Object Representation [RFC8949]. 144 "CFM" Connectivity Fault Management [RFC7319]. 146 "CID" Company Identifier. 148 "EUI" Extended Unique Identifier. 150 "IAB" Individual Address Block, not Internet Architecture Board. 152 "IEEE" Institute for Electrical and Electronics Engineers 153 (www.ieee.org). 155 "IEEE-SA" IEEE Standards Association (standards.ieee.org). 157 "MA-L" MAC Address Block Large, commonly referred to as an OUI. 159 "MA-M" MAC Address Block Medium. 161 "MA-S" MAC Address Block Small. 163 "MAC" Media Access Control, not Message Authentication Code. 165 "MAC-48" A 48-bit MAC address. This term is obsolete. If globally 166 unique, use EUI-48. 168 "OUI" Organizationally Unique Identifier. An OUI is now officially 169 called an "MA-L" by the IEEE. 171 "RRTYPE" A DNS Resource Record type [RFC6895]. 173 "SLAP" IEEE 802 Structured Local Address Plan [802_O&A]. 175 "tag" "Tag" is used in two contexts in this document. For 176 "Ethernet tag", see Section 3. For "CBOR tag", see Section 177 2.4. 179 "TLV" Type, Length, Value. 181 "**" The double asterisk symbol indicates exponentiation. For 182 example, 2**24 is two to the twenty-fourth power. 184 1.2 Changes from RFC 7042 186 This document obsoletes [RFC7042] and makes the changes listed below. 187 However, the completed application template based upon which an IANA 188 OUI-based protocol number value was assigned for document use remains 189 that in Appendix C of RFC 7042. 191 o Adds information on MA-M (28-bit) and MA-S (36-bit) EUI prefixes 192 that the IEEE Registration Authority assigns. 194 o Adds information on the restructuring of the "local" MAC address 195 space into four quadrants under the Structured Local Address Plan 196 (SLAP [802_O&A]). 198 o Includes the IESG Statement on Ethertypes (See Appendix B.1). 200 o Mentions that IEEE 802 CFM Codepoints that have been allocated to 201 the IETF (see Section 1.5). 203 o Mentions the vendor specific LLDP data element that has been 204 assigned under the IANA OUI (see Section 4.1). 206 o Clarifies minor details in Section 5.1 on Expert Review and IESG 207 Ratification. 209 o Specified CBOR tags for MAC addresses and OUI/CIDs (see Section 210 2.4). 212 1.3 The IEEE Registration Authority 214 Originally the responsibility of Xerox Corporation, the registration 215 authority for Ethernet parameters is now the IEEE Registration 216 Authority, available on the web at: 218 http://standards.ieee.org/regauth/ 220 The IEEE Registration Authority operates under the direction of the 221 IEEE-SA Board of Governors. Anyone may apply to that Authority for 222 parameter assignments. The IEEE Registration Authority may impose 223 fees or other requirements but commonly waives fees for applications 224 from standards development organizations. 226 Lists of assignments and their holders are downloadable from the IEEE 227 Registration Authority site. 229 1.4 The IANA Organizationally Unique Identifier 231 The Organizationally Unique Identifier (OUI) 00-00-5E has been 232 assigned to IANA by the IEEE Registration Authority. 234 There is no OUI value reserved at this time for documentation, but 235 there are documentation code points under the IANA OUI specified 236 below. 238 1.5 CFM Code Points 240 The IEEE has allocated two blocks of 802 Connectivity Fault 241 Management (CFM) code points to the IETF, one for CFM OpCodes and one 242 for CFM TLV Types. For further information see [RFC7319]. The IANA 243 "Connectivity Fault Management (CFM) OAM IETF Parameters" Registry 244 has subregistries for these code points. This document does not 245 further discuss these blocks of code points. 247 2. Ethernet Identifier Parameters 249 Section 2.1 discusses 48-bit MAC identifiers, their relationship to 250 OUIs and other prefixes, and assignment under the IANA OUI. Section 251 2.2 extends this to 64-bit identifiers. Section 2.3 discusses other 252 IETF MAC identifier use not under the IANA OUI. Section 2.4 specifies 253 CBOR tags for MAC addresses and OUI/CIDs. 255 ([RAC_OUI] indicates that the IEEE Registration Authority Committee 256 was at one time exploring the feasibility of defining 128-bit 257 identifiers. [RAC_OUI] is an expired draft that also provides 258 additional historic information on [IEEE802] registries.) 260 2.1 48-Bit MAC Identifiers, OUIs, and Other Prefixes 262 48-bit MAC "addresses" are the most commonly used Ethernet interface 263 identifiers. Those that are globally unique are also called EUI-48 264 identifiers (Extended Unique Identifier 48). An EUI-48 is structured 265 into an initial prefix assigned by the IEEE Registration Authority 266 and additional bits assigned by the prefix owner. Currently there 267 are three lengths of prefixes assigned as shown in the table below; 268 however, some prefix bits have special meaning as shown in Figure 1. 270 Prefix Length Owner Supplied Bits 271 in bits Name for EUI-48 272 ------------- ------ -------------------- 273 24 MAC-L (OUI) 24 274 28 MAC-M 20 275 36 MAC-S 12 277 The bottom four bits, as shown in Figure 1, of the first octet of the 278 3-octet 48-bit MAC have special meaning and are referred to below as 279 the M, X, Y, and Z bits. 281 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 282 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 283 | . . . . Z Y X M| . . . . . . . .| octets 0&1 284 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 285 | . . . . . . . .| . . . . . . . .| octets 2&3 286 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 287 | . . . . . . . .| . . . . . . . .| octets 4&5 288 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 290 Figure 1. 48-bit MAC Address Structure 292 Except for cetain combinations of the Z, Y, and X bits as discussed 293 in Section 2.1.1, a MAC address begins with 3 octets or a larger 294 initial prefix indicating the asignee of the block of MAC addresses 295 followed by a sequence of additional octets so as to add up to the 296 total MAC address length, usually 48 bits. For example, the IEEE has 297 assigned IABs (Individual Address Blocks), where the first 4 1/2 298 octets (36 bits) are assigned, giving the holder of the IAB 1 1/2 299 octets (12 bits) they can control in constructing 48-bit MAC 300 addresses; however, IABs have become historic, and a wider range of 301 prefix lengths are available [RAC_OUI]. 303 The IEEE describes its assignment procedures and policies for IEEE 304 802-related identifiers in [802_O&A]. An IEEE tutorial on EUIs, OUIs, 305 and CIDs is available at [IEEEtutorial]. 307 2.1.1 Special First Octet Bits 309 Four bits within the initial octet of an IEEE MAC interface 310 identifier, such as an EUI-48, have special significance [802_O&A] as 311 follows: 313 M bit --- This bit always indicates a group address and is 314 frequently referred to as the group bit. If it is zero, 315 the MAC address is unicast. If it is a one, the address is 316 groupcast (multicast or broadcast). This meaning is 317 independent of the values of the X, Y, and Z bits. 319 X bit --- This bit was previously called the "local" bit. If it is 320 zero, the MAC address is a global address under the 321 control of the owner of the IEEE assigned prefix. 322 Previously, if it was a one, the MAC address was 323 considered "local" and under the assignment and control of 324 the local network operator (but see Section 2.3). Now, if 325 it is a one, the nature of the MAC address is optionally 326 determined by the Y and Z bits under the IEEE 802 327 Structured Local Address Plan (SLAP) as described below. 329 Y&Z bits - These two bits have no special meaning if the X bit is 330 zero. If the X bit is one, these two bits divide the 331 formerly uniform "local" MAC address space into four 332 quadrants, as follows. These quadrants are further 333 described below. 335 Y bit Z bit Quadrant 336 ----- ----- ----------- 337 0 0 Administratively Assigned 338 0 1 Extended Local 339 1 0 Reserved 340 1 1 Standard Assigned 342 While a local network administrator can assign any addresses with the 343 X bit a one, the optional SLAP characterizes the four quadrants of 344 the "local" address space using the Y and Z bits as follows: 346 Administratively Assigned - MAC addresses in this quadrant are 347 called Administratively Assigned Identifiers. This is 348 intended for arbitrary local assignment, such as random 349 assignment; however, see Section 2.3.1. 351 Extended Local - MAC addresses in this quadrant are called Extended 352 Local Identifiers. These addresses are not actually 353 "local" under SLAP. They are available to the 354 organization that has been assigned the CID (see Section 355 2.1.2) specifying the other 20 bits of the 24-bit prefix 356 with X, Y, and Z bits having the values 1, 0, and 1 357 respectively. 359 Reserved - MAC addresses in this quadrant are reserved for future 360 use under the SLAP. Until such future use, they could be 361 locally assigned as Administratively Assigned Identifiers 362 are assigned but there is a danger that future SLAP use 363 would conflict with such local assignments. 365 Standard Assigned - MAC addresses in this quadrant are known as 366 Standard Assigned Identifiers. It is intended that such 367 addresses be assigned and possibly revoked through a 368 local protocol. There is work in the IEEE [802.1CQ] and 369 the IETF [RFC8947] [RFC8948] related to such protocols. 371 2.1.2 OUIs and CIDs 373 OUI, MAC-M, and MAC-S MAC prefixes are assigned with the Local bit 374 zero and the Group bit unspecified. Multicast identifiers may be 375 constructed by turning on the Group bit, and unicast identifiers may 376 be constructed by leaving the Group bit zero. 378 The Local bit is zero for globally unique EUI-48 identifiers assigned 379 by the owner of an OUI or owner of a longer prefix. If the Local bit 380 is a one, the identifier has historically been a local identifier 381 under the control of the local network administrator; however, there 382 are now recommendations on optional management of the local address 383 space as discussed in Section 2.1.1. If the Local bit is on, the 384 holder of an OUI has no special authority over MAC identifiers whose 385 first 3 octets correspond to their OUI or the beginning of their 386 longer prefix. 388 A CID is a 24-bit Company Identifier. It is assigned for 389 organizations that need such an identifier, that can be used in place 390 of an OUI, but do not need to assign subsidiary MAC addresses. A CID 391 can be recognized by its X and Z bits having the value 1 and its Y 392 bit having the value 0 (see Figure 1). 394 An AFN and a DNS RRTYPE have been assigned for 48-bit MAC addresses 395 as discussed in Section 5.2. 397 2.1.3 EUI-48 Assignments under the IANA OUI 399 The OUI 00-00-5E has been assigned to IANA as stated in Section 1.4 400 above. This includes 2**24 EUI-48 multicast identifiers from 401 01-00-5E-00-00-00 to 01-00-5E-FF-FF-FF and 2**24 EUI-48 unicast 402 identifiers from 00-00-5E-00-00-00 to 00-00-5E-FF-FF-FF. 404 Of these EUI-48 identifiers, the sub-blocks reserved or thus far 405 assigned by IANA for purposes of documentation are as follows: 407 Unicast, all blocks of 2**8 addresses thus far: 409 00-00-5E-00-00-00 through 00-00-5E-00-00-FF: reserved and require 410 IESG Ratification for assignment (see Section 5.1). 412 00-00-5E-00-01-00 through 00-00-5E-00-01-FF: assigned for the 413 Virtual Router Redundancy Protocol (VRRP) [RFC5798]. 415 00-00-5E-00-02-00 through 00-00-5E-00-02-FF: assigned for the IPv6 416 Virtual Router Redundancy Protocol (IPv6 VRRP) [RFC5798]. 418 00-00-5E-00-52-00 through 00-00-5E-00-52-FF: used for very small 419 assignments. Currently, 4 out of these 256 values have been 420 assigned. 422 00-00-5E-00-53-00 through 00-00-5E-00-53-FF: assigned for use in 423 documentation. 425 00-00-5E-90-01-00 through 00-00-5E-90-01-FF: used for very small 426 assignments that need parallel unicast and multicast MAC 427 addresses. Currently 1 out of these 256 values has been 428 assigned. 430 Multicast: 432 01-00-5E-00-00-00 through 01-00-5E-7F-FF-FF: 2**23 addresses 433 assigned for IPv4 multicast [RFC1112]. 435 01-00-5E-80-00-00 through 01-00-5E-8F-FF-FF: 2**20 addresses 436 assigned for MPLS multicast [RFC5332]. 438 01-00-5E-90-00-00 through 01-00-5E-90-00-FF: 2**8 addresses being 439 used for very small assignments. Currently, 4 out of these 256 440 values have been assigned. 442 01-00-5E-90-01-00 through 01-00-5E-90-01-FF: used for very small 443 assignments that need parallel unicast and multicast MAC 444 addresses. Currently 1 out of these 256 values has been 445 assigned. 447 01-00-5E-90-10-00 through 01-00-5E-90-10-FF: 2**8 addresses for 448 use in documentation. 450 For more detailed and up-to-date information, see the "Ethernet 451 Numbers" registry at http://www.iana.org. 453 2.1.4 EUI-48 Documentation Values 455 The following values have been assigned for use in documentation: 457 00-00-5E-00-53-00 through 00-00-5E-00-53-FF for unicast and 459 01-00-5E-90-10-00 through 01-00-5E-90-10-FF for multicast. 461 2.1.5 EUI-48 IANA Assignment Considerations 463 EUI-48 assignments under the current or a future IANA OUI (see 464 Section 5.4) must meet the following requirements: 466 o must be for standards purposes (either for an IETF Standard or 467 other standard related to IETF work), 469 o must be for a power-of-two size block of identifiers starting 470 at a boundary that is an equal or greater power of two, 471 including the assignment of one (2**0) identifier, 473 o must not be used to evade the requirement for vendors to obtain 474 their own block of identifiers from the IEEE, and 476 o must be documented in an Internet-Draft or RFC. 478 In addition, approval must be obtained as follows (see the procedure 479 in Section 5.1): 481 Small to medium assignments of a block of 1, 2, 4, ..., 32768, 482 65536 (2**0, 2**1, 2**2, ..., 2**15, 2**16) EUI-48 identifiers 483 require Expert Review (see Section 5.1). 485 Large assignments of 131072 (2**17) or more EUI-48 identifiers 486 require IESG Ratification (see Section 5.1). 488 2.2 64-Bit MAC Identifiers 490 IEEE also defines a system of 64-bit MAC identifiers including 491 EUI-64s. EUI-64 identifiers are currently used as follows: 493 o In a modified form to construct some IPv6 interface identifiers 494 as described in Section 2.2.1 496 o In IEEE Std 1394 (also known as FireWire and i.Link) 498 o In IEEE Std 802.15.4 (also known as ZigBee) 500 o In [InfiniBand] 502 Adding a 5-octet (40-bit) extension to a 3-octet (24-bit) OUI, or a 503 shorter extension to longer assigned prefixes [RAC_OUI] so as to 504 total 64 bits, produces an EUI-64 identifier under that OUI or longer 505 prefix. As with EUI-48 identifiers, the first octet has the same 506 Group and Local bits. 508 An AFN and a DNS RRTYPE have been assigned for 64-bit MAC addresses 509 as discussed in Section 5.2. 511 The discussion below is almost entirely in terms of the "Modified" 512 form of EUI-64 identifiers; however, anyone assigned such an 513 identifier can also use the unmodified form as a MAC identifier on 514 any link that uses such 64-bit identifiers for interfaces. 516 2.2.1. IPv6 Use of Modified EUI-64 Identifiers 518 MAC-64 identifiers are used to form the lower 64 bits of some IPv6 519 addresses (Section 2.5.1 and Appendix A of [RFC4291] and Appendix A 520 of [RFC5214]). When so used, the MAC-64 is modified by inverting the 521 Local/Global bit to form an IETF "Modified EUI-64 identifier". Below 522 is an illustration of a Modified EUI-64 unicast identifier under the 523 IANA OUI, where aa-bb-cc-dd-ee is the extension. 525 02-00-5E-aa-bb-cc-dd-ee 527 The first octet is shown as 02 rather than 00 because, in Modified 528 EUI-64 identifiers, the sense of the Local/Global bit is inverted 529 compared with EUI-48 identifiers. It is the globally unique values 530 (universal scope) that have the 02 bit on in the first octet, while 531 those with this bit off are locally assigned and out of scope for 532 global assignment. 534 The Local/Global bit was inverted to make it easier for network 535 operators to type in local-scope identifiers. Thus, such Modified 536 EUI-64 identifiers as 1, 2, etc. (ignoring leading zeros) are local. 537 Without the modification, they would have to be 538 02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc. to be local. 540 As with 48-bit MAC identifiers, the 01 bit on in the first octet 541 indicates a group identifier. 543 When the first two octets of the extension of a Modified EUI-64 544 identifier are FF-FE, the remainder of the extension is a 24-bit 545 value as assigned by the OUI owner for an EUI-48. For example: 547 02-00-5E-FF-FE-yy-yy-yy 548 or 549 03-00-5E-FF-FE-yy-yy-yy 551 where yy-yy-yy is the portion (of an EUI-48 global unicast or 552 multicast identifier) that is assigned by the OUI owner (IANA in this 553 case). Thus, any holder of one or more EUI-48 identifiers under the 554 IANA OUI also has an equal number of Modified EUI-64 identifiers that 555 can be formed by inserting FF-FE in the middle of their EUI-48 556 identifiers and inverting the Local/Global bit. 558 (Note: [EUI-64] defines FF-FF as the bits to be inserted to create 559 an IEEE EUI-64 identifier from a EUI-48 identifier. That document 560 says the FF-FE value is used when starting with an EUI-48 561 identifier. The IETF uses only FF-FE to create Modified EUI-64 562 identifiers from 48-bit Ethernet station identifiers regardless of 563 whether they are EUI-48 or 48-bit local MAC identifiers. EUI-48 564 and local 48-bit MAC identifiers are syntactically equivalent, and 565 this doesn't cause any problems in practice.) 567 In addition, certain Modified EUI-64 identifiers under the IANA OUI 568 are reserved for holders of IPv4 addresses as follows: 570 02-00-5E-FE-xx-xx-xx-xx 572 where xx-xx-xx-xx is a 32-bit IPv4 address. The owner of an IPv4 573 address has both a unicast- and multicast-derived EUI-64 address. 574 Modified EUI-64 identifiers from 576 02-00-5E-FE-F0-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF 578 are effectively reserved pending the specification of IPv4 Class E 579 addresses. However, for Modified EUI-64 identifiers based on an IPv4 580 address, the Local/Global bit should be set to correspond to whether 581 the IPv4 address is local or global. (Keep in mind that the sense of 582 the Modified EUI-64 identifier Local/Global bit is reversed from that 583 in (unmodified) MAC-64 identifiers.) 585 2.2.2 EUI-64 IANA Assignment Considerations 587 The following table shows which Modified EUI-64 identifiers under the 588 IANA OUI are reserved, assigned, or available as indicated. As noted 589 above, the corresponding MAC addresses can be determined by 590 complementing the 02 bit in the first octet. In all cases, the 591 corresponding multicast 64-bit MAC addresses formed by complementing 592 the 01 bit in the first octet have the same status as the modified 593 64-bit unicast address blocks listed below. 595 02-00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF reserved 597 02-00-5E-10-00-00-00-00 to 02-00-5E-10-00-00-00-FF assigned for 598 documentation use 600 02-00-5E-10-00-00-01-00 to 02-00-5E-EF-FF-FF-FF-FF available for 601 assignment 603 02-00-5E-F0-00-00-00-00 to 02-00-5E-FD-FF-FF-FF-FF reserved 605 02-00-5E-FE-00-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF assigned to 606 IPv4 address holders as described above 608 02-00-5E-FF-00-00-00-00 to 02-00-5E-FF-FD-FF-FF-FF reserved 610 02-00-5E-FF-FE-00-00-00 to 02-00-5E-FF-FE-FF-FF-FF assigned for 611 holders of EUI-48 identifiers under the IANA OUI as described 612 above 614 02-00-5E-FF-FF-00-00-00 to 02-00-5E-FF-FF-FF-FF-FF reserved 616 The reserved identifiers above require IESG Ratification (see Section 617 5.1) for assignment. IANA EUI-64 identifier assignments under the 618 IANA OUI must meet the following requirements: 620 o must be for standards purposes (either for an IETF Standard or 621 other standard related to IETF work), 623 o must be for a power-of-two size block of identifiers starting 624 at a boundary that is an equal or greater power of two, 625 including the assignment of one (2**0) identifier, 627 o must not be used to evade the requirement for vendors to obtain 628 their own block of identifiers from the IEEE, and 630 o must be documented in an Internet-Draft or RFC. 632 In addition, approval must be obtained as follows (see the procedure 633 in Section 5.1): 635 Small to medium assignments of a block of 1, 2, 4, ..., 134217728, 636 268435456 (2**0, 2**1, 2**2, ..., 2**27, 2**28) EUI-64 637 identifiers require Expert Review (see Section 5.1). 639 Assignments of any size, including 536870912 (2**29) or more 640 EUI-64 identifiers, may be made with IESG Ratification (see 641 Section 5.1). 643 2.2.3 EUI-64 Documentation Values 645 The following blocks of unmodified 64-bit MAC addresses are for 646 documentation use. The IPv4-derived addresses are based on the IPv4 647 documentation addresses [RFC5737], and the MAC-derived addresses are 648 based on the EUI-48 documentation addresses above. 650 Unicast Values for Documentation Use: 652 00-00-5E-EF-10-00-00-00 to 00-00-5E-EF-10-00-00-FF general 654 00-00-5E-FE-C0-00-02-00 to 00-00-5E-FE-C0-00-02-FF and 655 00-00-5E-FE-C6-33-64-00 to 00-00-5E-FE-C6-33-64-FF and 656 00-00-5E-FE-CB-00-71-00 to 00-00-5E-FE-CB-00-71-FF IPv4 derived 658 00-00-5E-FF-FE-00-53-00 to 00-00-5E-FF-FE-00-53-FF EUI-48 derived 660 00-00-5E-FE-EA-C0-00-02 and 661 00-00-5E-FE-EA-C6-33-64 and 662 00-00-5E-FE-EA-CB-00-71 IPv4 multicast derived from IPv4 unicast 663 [RFC6034] 665 Multicast Values for Documentation Use: 667 01-00-5E-EF-10-00-00-00 to 01-00-5E-EF-10-00-00-FF general 669 01-00-5E-FE-C0-00-02-00 to 01-00-5E-FE-C0-00-02-FF and 670 01-00-5E-FE-C6-33-64-00 to 01-00-5E-FE-C6-33-64-FF and 671 01-00-5E-FE-CB-00-71-00 to 01-00-5E-FE-CB-00-71-FF IPv4 derived 673 01-00-5E-FE-EA-C0-00-02 and 674 01-00-5E-FE-EA-C6-33-64 and 675 01-00-5E-FE-EA-CB-00-71 IPv4 multicast derived from IPv4 unicast 676 [RFC6034] 678 01-00-5E-FF-FE-90-10-00 to 01-00-5E-FF-FE-90-10-FF EUI-48 derived 680 2.3 Other 48-bit MAC Identifiers Used by the IETF 682 There are two other blocks of 48-bit MAC identifiers that are used by 683 the IETF as described below. 685 2.3.1 Identifiers Prefixed '33-33' 687 All 48-bit multicast MAC identifiers prefixed "33-33" (that is, the 688 2**32 multicast MAC identifiers in the range from 33-33-00-00-00-00 689 to 33-33-FF-FF-FF-FF) are used as specified in [RFC2464] for IPv6 690 multicast. In all of these identifiers, the Group bit (the bottom 691 bit of the first octet) is on, as is required to work properly with 692 existing hardware as a multicast identifier. They also have the 693 Local bit on but any ethernet using standard IPv6 multicast should 694 note that these addresses will be used for that purpose. These 695 multicast MAC addresses fall into the administratively assigned SLAP 696 quadrant (see Section 2.1.1). 698 (Historical notes: It was the custom during IPv6 design to use "3" 699 for unknown or example values and 3333 Coyote Hill Road, Palo 700 Alto, California, is the address of PARC (Palo Alto Research 701 Center, formerly "Xerox PARC"). Ethernet was originally specified 702 by the Digital Equipment Corporation, Intel Corporation, and Xerox 703 Corporation. The pre-IEEE [802.3] Ethernet protocol has sometimes 704 been known as "DIX" Ethernet from the first letters of the names 705 of these companies.) 707 2.3.2 The 'CF Series' 709 The Informational [RFC2153] declared the 3-octet values from CF-00-00 710 through CF-FF-FF to be OUIs available for assignment by IANA to 711 software vendors for use in PPP [RFC1661] or for other uses where 712 vendors do not otherwise need an IEEE-assigned OUI. It should be 713 noted that, when used as 48-bit MAC prefixes, these values have all 714 of the Z, Y, X (Local), and M (Group) special bits at the bottom of 715 the first octet equal to one, while all IEEE-assigned OUIs thus far 716 have the X and M bits zero. Multicast MAC addresses constructed with 717 a "CF" series OUI would fall into the standard assigned SLAP quadrant 718 (see Section 2.1.1). The Group bit is meaningless in PPP. To quote 719 [RFC2153]: "The 'CF0000' series was arbitrarily chosen to match the 720 PPP NLPID 'CF', as a matter of mnemonic convenience." (For further 721 information on NLPIDs, see [RFC6328].) 722 CF-00-00 is reserved, and IANA lists multicast identifier 723 CF-00-00-00-00-00 as used for Ethernet loopback tests. 725 In over a decade of availability, only a handful of values in the CF 726 Series have been assigned. (See "Ethernet Numbers" 727 and "PPP Numbers" 728 ). 730 2.3.2.1 Changes to RFC 2153 732 The IANA Considerations in [RFC2153] were updated as follows by the 733 approval of RFC 5342 and remain so updated (no technical changes have 734 been made): 736 o Use of these 'CF Series' identifiers based on IANA assignment 737 was deprecated. 739 o IANA was instructed not to assign any further values in the 'CF 740 Series'. 742 2.4 CBOR Tags 744 The Concise Binary Object Representation (CBOR [RFC8949]) is a data 745 format whose design goals include the possibility of very small code 746 size, fairly small message size, and extensibility. In CBOR, a data 747 item can be enclosed by a CBOR tag to give it some additional 748 semantics identified by that tag. 750 IANA has assigned TBD1 as the CBOR tag to indicate a MAC address. The 751 enclosed data item is a byte string. The length of the byte string 752 indicates whether a 48-bit (6 byte) or 64-bit (8 byte) MAC address is 753 encoded. Should some other multiple of 8 bits length MAC addresses be 754 used in the future, such as a 128-bit (16 byte) MAC address, the TBD1 755 tag will be used. 757 IANA has assigned TDB2 as the CBOR tag to indicate an OUI/CID. The 758 enclosed data item is a byte string of length 4 to hold the 32-bit 759 OUI or CID (see Section 2.1.2). 761 3. Ethernet Protocol Parameters 763 Ethernet protocol parameters provide a means of indicating the 764 contents of a frame -- for example, that its contents are IPv4 or 765 IPv6. 767 The concept has been extended to labeling by Etherent "tags". An 768 Ethernet tag in this sense is a prefix whose type is identified by an 769 Ethertype that is then followed by either another tag, an Ethertype, 770 or an LSAP (Link-Layer Service Access Point) protocol indicator for 771 the "main" body of the frame, as described below. Traditionally, in 772 the [802_O&A] world, tags are a fixed length and do not include any 773 encoding of their own length. Any device that is processing a frame 774 cannot, in general, safely process anything in the frame past an 775 Ethertype it does not understand. An example is the C-Tag (formerly 776 the Q-Tag) [802.1Q]. It provides customer VLAN and priority 777 information for a frame. 779 There are two types of protocol identifier parameters that can occur 780 in Ethernet frames after the initial MAC-48 destination and source 781 identifiers: 783 Ethertypes: These are 16-bit identifiers appearing as the initial 784 two octets after the MAC destination and source (or after a 785 tag), which, when considered as an unsigned integer, are equal 786 to or larger than 0x0600. 788 LSAPs: These are 8-bit protocol identifiers that occur in pairs 789 immediately after an initial 16-bit (two-octet) remaining frame 790 length, which is in turn after the MAC destination and source 791 (or after a tag). Such a length must, when considered as an 792 unsigned integer, be less than 0x5DC, or it could be mistaken 793 as an Ethertype. LSAPs occur in pairs where one is intended to 794 indicate the source protocol handler and one the destination 795 protocol handler; however, use cases where the two are 796 different have been relatively rare. 798 Neither Ethertypes nor LSAPs are assigned by IANA; they are assigned 799 by the IEEE Registration Authority (see Section 1.3 above and 800 Appendix B). However, both LSAPs and Ethertypes have extension 801 mechanisms so that they can be used with five-octet Ethernet protocol 802 identifiers under an OUI, including those assigned by IANA under the 803 IANA OUI. 805 When using the IEEE 802 Logical Link Control (LLC) format (Subnetwork 806 Access Protocol (SNAP)) [802_O&A] for a frame, an OUI-based protocol 807 identifier can be expressed as follows: 809 xx-xx-AA-AA-03-yy-yy-yy-zz-zz 811 where xx-xx is the frame length and, as above, must be small enough 812 not to be confused with an Ethertype; "AA" is the LSAP that indicates 813 this use and is sometimes referred to as the SNAP Service Access 814 Point (SAP); "03" is the LLC control octet indicating datagram 815 service; yy-yy-yy is an OUI; and zz-zz is a protocol number, under 816 that OUI, assigned by the OUI owner. The five-octet length for such 817 OUI-based protocol identifiers was chosen so that, with the LLC 818 control octet ("03"), the result is 16-bit aligned. 820 When using an Ethertype to indicate the main type for a frame body, 821 the special "OUI Extended Ethertype" 88-B7 is available. Using this 822 Ethertype, a frame body can begin with 824 88-B7-yy-yy-yy-zz-zz 826 where yy-yy-yy and zz-zz have the same meaning as in the SNAP format 827 described above. 829 It is also possible, within the SNAP format, to use an arbitrary 830 Ethertype. Putting the Ethertype as the zz-zz field after an all- 831 zeros OUI (00-00-00) does this. It looks like 833 xx-xx-AA-AA-03-00-00-00-zz-zz 835 where zz-zz is the Ethertype. 837 (Note that, at this point, the 802 protocol syntax facilities are 838 sufficiently powerful that they could be chained indefinitely. 839 Whether support for such chaining is generally required is not 840 clear, but [802_O&A] requires support for 842 xx-xx-AA-AA-03-00-00-00-88-B7-yy-yy-yy-zz-zz 844 although this could be more efficiently expressed by simply 845 pinching out the "00-00-00-88-B7" in the middle.) 847 As well as labeling frame contents, 802 protocol types appear within 848 NBMA (Non-Broadcast Multi-Access) Next Hop Resolution Protocol 849 [RFC2332] messages. Such messages have provisions for both two-octet 850 Ethertypes and OUI-based protocol types. 16-bit Ethertypes also occur 851 in the Generic Router Encapsulation (GRE [RFC2784]) header. 853 3.1 Ethernet Protocol Assignment under the IANA OUI 855 Two-octet protocol numbers under the IANA OUI are available, as in 857 xx-xx-AA-AA-03-00-00-5E-qq-qq 859 where qq-qq is the protocol number. 861 A number of such assignments have been made out of the 2**16 protocol 862 numbers available from 00-00-5E-00-00 to 00-00-5E-FF-FF (see [IANA]). 863 The extreme values of this range, 00-00-5E-00-00 and 00-00-5E-FF-FF, 864 are reserved and require IESG Ratification for assignment (see 865 Section 5.1). New assignments of SNAP SAP protocol (qq-qq) numbers 866 under the IANA OUI must meet the following requirements: 868 o the assignment must be for standards use (either for an IETF 869 Standard or other standard related to IETF work), 871 o it must be documented in an Internet-Draft or RFC, and 873 o such protocol numbers are not to be assigned for any protocol 874 that has an Ethertype (because that can be expressed by putting 875 an all-zeros "OUI" before the Ethertype as described above). 877 In addition, the Expert Review (or IESG Ratification for the two 878 reserved values) must be obtained using the procedure specified in 879 Section 5.1. 881 3.2 Documentation Protocol Number 883 0x0042 is a protocol number under the IANA OUI (that is, 884 00-00-5E-00-42) to be used as an example for documentation purposes. 886 4. Other OUI-Based Parameters 888 Some IEEE 802 and other protocols provide for parameters based on an 889 OUI beyond those discussed above. Such parameters most commonly 890 consist of an OUI plus one octet of additional value. They are 891 usually called "vendor specific" parameters, although "organization 892 specific" might be more accurate. They would look like 894 yy-yy-yy-zz 896 where yy-yy-yy is the OUI and zz is the additional specifier. An 897 example is the Cipher Suite Selector in IEEE [802.11]. 899 Values may be assigned under the IANA OUI for such other OUI-based 900 parameter usage by Expert Review except that, for each use, the 901 additional specifier values consisting of all zero bits and all one 902 bits (0x00 (00-00-5E-00) and 0xFF (00-00-5E-FF) for a one-octet 903 specifier) are reserved and require IESG Ratification (see Section 904 5.1) for assignment; also, the additional specifier value 0x42 905 (00-00-5E-42) is assigned for use as an example in documentation. 907 Assignments of such other IANA OUI-based parameters must be for 908 standards use (either for an IETF Standard or other standard related 909 to IETF work) and be documented in an Internet-Draft or RFC. The 910 first time a value is assigned for a particular parameter of this 911 type, an IANA registry will be created to contain that assignment and 912 any subsequent assignments of values for that parameter under the 913 IANA OUI. The Expert will specify the name of the registry. 915 If different policies from those above are required for such a 916 parameter, a BCP or Standards Track RFC must be adopted to update 917 this BCP and specify the new policy and parameter. 919 4.1 LLDP IETF Vendor-Specific TLV Type 921 An example of such an "other IANA OUI based parameter" is specified 922 in [RFC8520]. This provides for a "vendor based" TLV type for 923 announcing a Manufacturer Usage Description (MUD) Uniform Resource 924 Locator (URL) in the IEEE Link Local Discover Protocol (LLDP 925 [802.1AB]). (See also Section 5.7.) 927 5. IANA Considerations 929 This document concerns IANA considerations for the assignment of 930 Ethernet parameters in connection with the IANA OUI and related 931 matters. 933 NOTE: The "IETF OUI Ethernet Numbers" IANA web page is for 934 registries of numbers assigned under the IETF OUI while the "IEEE 935 802 Numbers" IANA web page has Informational lists of numbers 936 assigned by the IEEE Registration Authority. 938 This document does not create any new IANA registries. 940 The MAC address values assigned for documentation and the protocol 941 number for documentation were both assigned by [RFC7042]. 943 No existing assignment is changed by this document. 945 5.1 Expert Review and IESG Ratification 947 This section specifies the procedure for Expert Review and IESG 948 Ratification of MAC, protocol, and other IANA OUI-based identifiers. 949 The Expert(s) referred to in this document shall consist of one or 950 more persons appointed by and serving at the pleasure of the IESG. 952 The procedure described for Expert Review assignments in this 953 document is fully consistent with the IANA Expert Review policy 954 described in [RFC8126]. 956 While finite, the universe of code points from which Expert-judged 957 assignments will be made is felt to be large enough that the 958 requirements given in this document and the Experts' good judgment 959 are sufficient guidance. The idea is for the Expert to provide a 960 light sanity check for small assignments of EUI identifiers, with 961 increased scrutiny by the Expert for medium-sized assignments of EUI 962 identifiers and assignments of protocol identifiers and other IANA 963 OUI-based parameters. However, it can make sense to assign very 964 large portions of the MAC identifier code point space. (Note that 965 existing assignments include one for 1/2 of the entire multicast IANA 966 EUI-48 code point space and one for 1/16 of that multicast code point 967 space.) In those cases, and in cases of the assignment of "reserved" 968 values, IESG Ratification of an Expert Review approval recommendation 969 is required as described below. The procedure is as follows: 971 The applicant always completes the appropriate template from 972 Appendix A below and sends it to IANA . 974 IANA always sends the template to an appointed Expert. If the 975 Expert recuses themselves or is non-responsive, IANA may choose 976 an alternative appointed Expert or, if none is available, will 977 contact the IESG. 979 In all cases, if IANA receives a disapproval from an Expert 980 selected to review an application template, the application 981 will be denied. The Expert should provide a reason for refusal 982 which IANA will communicate back to the applicant. 984 If the assignment is based on Expert Review: 986 If IANA receives approval and code points are available, 987 IANA will make the requested assignment. 989 If the assignment is based on IESG Ratification: 991 The procedure starts with the first steps above for Expert 992 Review. If the Expert disapproves the application, they 993 simply inform IANA; however, if the Expert believes the 994 application should be approved, or is uncertain and believes 995 that the circumstances warrant the attention of the IESG, 996 the Expert will inform IANA about their advice, and IANA 997 will forward the application, together with the reasons 998 provided by the Expert for approval or uncertainty, to the 999 IESG. The IESG must decide whether the assignment will be 1000 granted. This can be accomplished by a management item in 1001 an IESG telechat as is done for other types of requests. If 1002 the IESG decides not to ratify a favorable opinion by the 1003 Expert or decides against an application where the Expert is 1004 uncertain, the application is denied; otherwise, it is 1005 granted. The IESG will communicate its decision to the 1006 Expert and to IANA. In case of refusal, the IESG should 1007 provide a reason which IANA will communicate to the 1008 applicant. 1010 5.2 IANA Web Page Changes 1012 As this document replaces [RFC7042], references to [RFC7042] in IANA 1013 registries on both the IANA IEEE 802 Numbers web page and the IANA 1014 IETF OUI Ethernet Numbers web pages will be replaced by references to 1015 [this document]. Other IANA web page references to [RFC7042] are not 1016 changed. 1018 For clarity and parallelism with the IANA "IEEE 802 Numbers" web 1019 page, the IANA "Ethernet Numbers" web page is re-named the "IETF OUI 1020 Ethernet Numbers" web page. 1022 5.3 MAC Address AFNs and RRTYPEs 1024 IANA has assigned Address Family Numbers (AFNs) for MAC addresses as 1025 follows: 1027 AFN Decimal Hex Reference 1028 ---------- ------- ------ --------- 1029 48-bit MAC 16389 0x4005 [RFC7042] 1030 64-bit MAC 16390 0x4006 [RFC7042] 1031 24-bit OUI 16391 0x4007 [RFC7961] 1033 MAC/24 16392 0x4008 [RFC7961] 1034 Lower 24 bits of a 48-bit MAC address 1036 MAC/40 16393 0x4009 [RFC7961] 1037 Lower 40 bits of a 64-bit MAC address 1039 IANA has assigned DNS RRTYPEs [RFC6895] for MAC addresses as follows: 1041 RRTYPE Code 1042 Data Mnemonic Decimal Hex Reference 1043 ---------- -------- ------- ------ ----------- 1044 48-bit MAC EUI48 108 0x006C [RFC7043] 1045 64-bit MAC EUI64 109 0x006D [RFC7043] 1047 5.4 Informational IANA Web Page Material 1049 IANA maintains an informational listing on its web site concerning 1050 Ethertypes, OUIs, and multicast addresses assigned under OUIs other 1051 than the IANA OUI. The title of this informational registry is "IEEE 1052 802 Numbers". IANA will update that informational registry when 1053 changes are provided or approved by the Expert(s). 1055 5.5 OUI Exhaustion 1057 When the available space for either multicast or unicast EUI-48 1058 identifiers under OUI 00-00-5E has been 90% or more exhausted, IANA 1059 should request an additional OUI from the IEEE Registration Authority 1060 for further IANA assignment. The appointed Expert(s) should monitor 1061 for this condition and notify IANA. 1063 5.6 IANA OUI MAC Address Table 1065 No changes have been made in the "IANA Unicast 48-bit MAC Addresses" 1066 and "IANA Multicast 48-bit MAC Addresses" tables except for the 1067 updates to references as specified in Section 5.2. 1069 5.7 IANA LLDP TLV Subtypes 1071 The IANA Link Layer Discovery Protpcol (LLDP) TLV Subtypes" Registry 1072 is moved from the IANA 802 Numbers web page to the IANA Ethernet 1073 Numbers web page. Three entries in the Registry are updated as 1074 follows: 1076 Value Description Reference 1077 ----- --------------------------------- --------------- 1078 0 Reserved [this document] 1079 42 Example for use in documentation [this document] 1080 255 Reserved [this document] 1082 The entries for 1 (MUD), 2-41 (unassigned), and 43-254 (unassigned) 1083 are unchanged. 1085 5.8 CBOR Tag Assignments 1087 IANA is requested to assign two CBOR Tags as shown below:. [The 1088 values of 48 and 49 are requested for TBD1 and TBD2 respectively.] 1090 Tag Data Item Semantics Reference 1091 ---- ----------- ---------------- --------------- 1092 TBD1 byte string IEEE MAC Address [this document] 1093 TBD2 byte string IEEE OUI/CID [this document] 1095 6. Security Considerations 1097 This document is concerned with assignment of parameters under the 1098 IANA OUI and closely related matters. It is not directly concerned 1099 with security except as follows: 1101 Confusion and conflict can be caused by the use of MAC addresses 1102 or other OUI-derived protocol parameters as examples in 1103 documentation. Examples that are "only" to be used in 1104 documentation can end up being coded and released or cause 1105 conflicts due to later real use and the possible acquisition of 1106 intellectual property rights in such addresses or parameters. The 1107 reservation herein of MAC addresses and parameters for 1108 documentation purposes will minimize such confusion and conflict. 1110 See [RFC7043] for security considerations in storing MAC addresses in 1111 the DNS. 1113 7. Acknowledgements 1115 The comments and suggestions of the following people, listed in 1116 alphabetic order, are gratefully acknowledged: 1118 Comments and suggestions leading to this Document: 1119 TBD 1121 Comments and suggestions leading to RFC 7042 (which is obsoleted 1122 by this document): 1123 David Black, Adrian Farrel, Bob Grow, Joel Jaeggli, Pearl 1124 Liang, Glenn Parsons, Pete Resnick, and Dan Romascanu. 1126 Normative References 1128 [802_O&A] - "IEEE Standard for Local and Metropolitan Area Networks: 1129 Overview and Architecture", IEEE Std 802-2014, 12 June 2014. 1131 "Standard for Local and Metropolitan Area Networks: Overview 1132 and Architecture - Draft Amendment: Local Medium Access Control 1133 (MAC) Address Usage", IEEE 802c, Draft 2.2, April 2017. 1135 [RFC8126] - Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1136 Writing an IANA Considerations Section in RFCs", BCP 26, RFC 1137 8126, DOI 10.17487/RFC8126, June 2017, . 1140 Informative References 1142 [802.1CQ] - IEEE 802, "Standard for Local and Metropolitan Area 1143 Networks: Multicast and Local Address Assignment", work in 1144 progress. 1146 [802.1Q] - "IEEE Standard for Local and metropolitan area networks / 1147 Media Access Control (MAC) Bridges and Virtual Bridge Local 1148 Area Networks", IEEE Std 802.1Q-2011, 31 August 2011. 1150 [802.3] - "IEEE Standard for Ethernet", IEEE Std 802.3-2012, 28 1151 December 2012. 1153 [802.11] - "IEEE Standard for Information technology / 1154 Telecommunications and information exchange between systems / 1155 Local and metropolitan area networks / Specific requirements / 1156 Part 11: Wireless LAN Medium Access Control (MAC) and Physical 1157 Layer (PHY) Specifications", IEEE Std 802.11-2012, 29 March 1158 2012. 1160 [EUI-64] - IEEE Registration Authority, "Guidelines for 64-bit Global 1161 Identifier (EUI-64(TM))", , November 2012. 1164 [IANA] - Internet Assigned Numbers Authority, . 1166 [IEEE802] - IEEE 802 LAN/MAN Standards Committee, 1167 . 1169 [IEEEtutorial] - IEEE, "Guidelines for Use of Extended Unique 1170 Identifier (EUI), Organizationally Unique Identifier (OUI), and 1171 Company ID (CID)", 1172 , 3 August 1174 2017. 1176 [InfiniBand] - InfiniBand Trade Association, "InfiniBand Architecture 1177 Specification Volume 1", November 2007. 1179 [RAC_OUI] - Parsons, G., "OUI Registry Restructuring", 1180 draft-ieee-rac-oui-restructuring-01.txt, work in Progress, 1181 September 2013. 1183 [RFC1112] - Deering, S., "Host extensions for IP multicasting", STD 1184 5, RFC 1112, August 1989. 1186 [RFC1661] - Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 1187 STD 51, RFC 1661, July 1994. 1189 [RFC2153] - Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997. 1191 [RFC2332] - Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. 1192 Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 1193 2332, April 1998. 1195 [RFC2464] - Crawford, M., "Transmission of IPv6 Packets over Ethernet 1196 Networks", RFC 2464, December 1998. 1198 [RFC2606] - Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 1199 Names", BCP 32, RFC 2606, June 1999. 1201 [RFC2784] - Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1202 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 1203 10.17487/RFC2784, March 2000, . 1206 [RFC3092] - Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology 1207 of "Foo"", RFC 3092, April 1 2001. 1209 [RFC4291] - Hinden, R. and S. Deering, "IP Version 6 Addressing 1210 Architecture", RFC 4291, February 2006. 1212 [RFC4760] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1213 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 1215 [RFC5214] - Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1216 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 1217 2008. 1219 [RFC5332] - Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, 1220 "MPLS Multicast Encapsulations", RFC 5332, August 2008. 1222 [RFC5737] - Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address 1223 Blocks Reserved for Documentation", RFC 5737, January 2010. 1225 [RFC5798] - Nadas, S., Ed., "Virtual Router Redundancy Protocol 1226 (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 1228 [RFC6034] - Thaler, D., "Unicast-Prefix-Based IPv4 Multicast 1229 Addresses", RFC 6034, October 2010. 1231 [RFC6328] - Eastlake 3rd, D., "IANA Considerations for Network Layer 1232 Protocol Identifiers", BCP 164, RFC 6328, DOI 10.17487/RFC6328, 1233 July 2011, 1235 [RFC6895] - Eastlake 3rd, D., "Domain Name System (DNS) IANA 1236 Considerations", BCP 42, RFC 6895, April 2013. 1238 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1239 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 1240 BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, 1241 . 1243 [RFC7043] - Abley, J., "Resource Records for EUI-48 and EUI-64 1244 Addresses in the DNS", RFC 7043, October 2013. 1246 [RFC7319] - Eastlake 3rd, D., "IANA Considerations for Connectivity 1247 Fault Management (CFM) Code Points", BCP 191, RFC 7319, DOI 1248 10.17487/RFC7319, July 2014, . 1251 [RFC7961] - Eastlake 3rd, D. and L. Yizhou, "Transparent 1252 Interconnection of Lots of Links (TRILL): Interface Addresses 1253 APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961, August 2016, 1254 . 1256 [RFC8520] - Lear, E., Droms, R., and D. Romascanu, "Manufacturer 1257 Usage Description Specification", RFC 8520, DOI 1258 10.17487/RFC8520, March 2019, . 1261 [RFC8947] - Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer 1262 Address Assignment Mechanism for DHCPv6", RFC 8947, DOI 1263 10.17487/RFC8947, December 2020, . 1266 [RFC8948] - Bernardos, CJ. and A. Mourad, "Structured Local Address 1267 Plan (SLAP) Quadrant Selection Option for DHCPv6", RFC 8948, 1268 DOI 10.17487/RFC8948, December 2020, . 1271 [RFC8949] - | Bormann, C. and P. Hoffman, "Concise Binary Object 1272 Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, 1273 December 2020, . 1275 Appendix A. Templates 1277 This appendix provides the specific templates for IANA assignments of 1278 parameters. Explanatory words in parentheses in the templates below 1279 may be deleted in a completed template as submitted to IANA. 1281 A.1 EUI-48/EUI-64 Identifier or Identifier Block Template 1283 Applicant Name: 1285 Applicant Email: 1287 Applicant Telephone: (starting with country code) 1289 Use Name: (brief name of Parameter use such as "Foo Protocol" 1290 [RFC3092]) 1292 Document: (ID or RFC specifying use to which the identifier or block 1293 of identifiers will be put.) 1295 Specify whether this is an application for EUI-48 or EUI-64 1296 identifiers: 1298 Size of Block requested: (must be a power-of-two-sized block, can be 1299 a block of size one (2**0)) 1301 Specify multicast, unicast, or both: 1303 A.2 IANA OUI/CID-Based Protocol Number Template 1305 Applicant Name: 1307 Applicant Email: 1309 Applicant Telephone: (starting with country code) 1311 Use Name: (brief name of use of code point such as "Foo Protocol") 1313 Document: (ID or RFC specifying use to which the protocol identifier 1314 will be put.) 1316 Note: (any additional note) 1318 A.3 Other IANA OUI/CID-Based Parameter Template 1320 Applicant Name: 1322 Applicant Email: 1324 Applicant Telephone: (starting with country code) 1326 Protocol where the OUI/CID-Based Parameter for which a value is being 1327 requested appears: (such as: Cipher Suite selection in IEEE 802.11) 1329 Use Name: (brief name of use of code point to be assigned, such as 1330 "Foo Cipher Suite" [RFC3092]) 1332 Document: (ID or RFC specifying use to which the other IANA OUI-based 1333 parameter value will be put.) 1335 Note: (any additional note) 1337 Appendix B. Ethertypes 1339 This appendix provides a copy of the IESG Statement issued in October 1340 2012 on obtaining new IETF Ethertypes in Section B.1. Note that there 1341 is an informational list on the IANA web site of some important 1342 Ethertypes specified for IETF protocols or by IEEE 802 available, 1343 currently at [IANA]. The IEEE Registration Authority page of 1344 Ethertypes, http://standards.ieee.org/regauth/ethertype/eth.txt, may 1345 also be useful. See Section 3 above. 1347 B.1 IESG Statement on Ethertypes 1349 From: IESG Date: 25 October 2012 1351 The IEEE Registration Authority (IEEE RA) assigns Ethertypes with 1352 oversight from the IEEE Registration Authority Committee (IEEE RAC). 1354 (See http://standards.ieee.org/develop/regauth/ethertype/.) Some IETF 1355 protocol specifications make use of Ethertypes. All Ethertype 1356 requests are subject to review by a consultant to the IEEE RA 1357 followed by IEEE RAC confirmation. 1359 Since Ethertypes are a fairly scarce resource, the IEEE RAC has let 1360 us know that they will not assign a new Ethertype to a new IETF 1361 protocol specification until the IESG has approved the protocol 1362 specification for publication as an RFC. In exceptional cases, the 1363 IEEE RA is willing to consider "early allocation" of an Ethertype for 1364 an IETF protocol that is still under development as long as the 1365 request comes from and has been vetted by the IESG. 1367 To let the IEEE RAC know that the IESG has approved the request for 1368 an Ethernet assignment for an IETF protocol, all future requests for 1369 assignment of Ethertypes for IETF protocols will be made by the IESG. 1371 Note that playpen Ethertypes have been assigned in IEEE 802 [1] for 1372 use during protocol development and experimentation. 1374 [1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001). IEEE 1375 standard for Local and Metropolitan Area Networks: Overview and 1376 Architecture -- Amendment 1: Ethertypes for Prototype and Vendor- 1377 Specific Protocol Development. 1379 Authors' Addresses 1381 Donald E. Eastlake 3rd 1382 Futurewei Technologies 1383 2386 Panoramic Circle 1384 Apopka, FL 32703 1385 USA 1387 Phone: +1-508-634-2066 1388 EMail: d3e3e3@gmail.com 1390 Joe Abley 1391 Hopcount Limited 1392 186 Albert Street, Suite 103 1393 London, ON N6A 1M1 1394 Canada 1396 Phone: +1 519 670 9327 1397 EMail: jabley@hopcount.ca 1399 Copyright, Disclaimer, and Additional IPR Provisions 1401 Copyright (c) 2022 IETF Trust and the persons identified as the 1402 document authors. All rights reserved. 1404 This document is subject to BCP 78 and the IETF Trust's Legal 1405 Provisions Relating to IETF Documents 1406 (http://trustee.ietf.org/license-info) in effect on the date of 1407 publication of this document. Please review these documents 1408 carefully, as they describe your rights and restrictions with respect 1409 to this document. Code Components extracted from this document must 1410 include Revised BSD License text as described in Section 4.e of the 1411 Trust Legal Provisions and are provided without warranty as described 1412 in the Revised BSD License. This Internet-Draft is submitted in full 1413 conformance with the provisions of BCP 78 and BCP 79.