idnits 2.17.1 draft-eastlake-ethernet-iana-considerations-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 954. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2008) is 5779 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 informational reference (is this intentional?): RFC 3768 (Obsoleted by RFC 5798) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 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 Eastlake Enterprises 3 Updates: RFC 2153 4 Intended Status: Best Current Practice 5 Expires: December 2008 June 29, 2008 7 IANA Considerations and IETF Protocol Usage 8 for IEEE 802 Parameters 9 11 Status of This Document 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 This document is intended to become a Best Current Practice. 19 Distribution of this document is unlimited. Comments should be sent 20 to the IETF or to the following list. Please include 21 the draft file name in your subject line. 22 IESG , Donald Eastlake 3rd , 23 Dan Romascanu , 24 Mark Townsley 25 Erik Nordmark , 26 Bernard Aboba . 28 This document is an Internet-Draft and is in full conformance with 29 all provisions of Section 10 of RFC 2026. Internet-Drafts are 30 working documents of the Internet Engineering Task Force (IETF), its 31 areas, and its working groups. Note that other groups may also 32 distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Abstract 47 Some IETF protocols make use of Ethernet frame formats and IEEE 802 48 parameters. This document discusses some use of such parameters in 49 IETF protocols and specifies IANA considerations for allocation of 50 code points under the IANA OUI (Organizationally Unique Identifier). 52 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 54 Table of Contents 56 Status of This Document....................................1 57 Abstract...................................................1 59 1. Introduction............................................3 60 1.1 Notations Used in This Document........................3 61 1.2 The IEEE Registration Authority........................3 62 1.2.1 The IANA OUI.........................................4 63 1.3 Acknowledgements.......................................4 65 2. Ethernet Identifier Parameters..........................5 66 2.1 48-bit MAC Identifiers and OUIs........................5 67 2.1.1 EUI-48 Allocations under the IANA OUI................5 68 2.1.2 EUI-48 IANA Allocation Considerations................6 69 2.2 64-bit MAC Identifiers.................................7 70 2.2.1 IPv6 Use of Modified EUI-64 Identifiers..............7 71 2.2.2 EUI-64 IANA Allocation Considerations................8 72 2.3 Other IETF Used MAC-48 Identifiers....................10 73 2.3.1 Identifiers Prefixed 33-33..........................10 74 2.3.2 The 'CF Series'.....................................10 75 2.3.2.1 Changes to RFC 2153...............................11 77 3. Ethernet Protocol Parameters...........................12 78 3.1 Ethernet Protocol Allocation Under the IANA OUI.......13 80 4. Other OUI Based Parameters.............................15 82 5. IANA Considerations....................................16 83 5.1 Expert Review and IESG Ratification...................16 84 5.2 Informational IANA Web Page Material..................17 85 5.3 OUI Exhaustion........................................17 86 6. Security Considerations................................18 88 7. Normative References...................................19 89 8. Informative References.................................19 91 Template Annex............................................21 92 EUI-48/EUI-64 Identifier or Identifier Block Template.....21 93 5-octet Ethernet Protocol Identifier Template.............22 94 Other IANA OUI Based Parameter Template...................22 96 Ethertypes Annex..........................................23 97 Some Ethertypes Specified By The IETF.....................23 98 Some IEEE 802 Ethertypes..................................23 100 Disclaimer................................................24 101 Additional IPR Provisions.................................24 102 Author's Address..........................................25 104 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 106 1. Introduction 108 Some IETF protocols use Ethernet or other [IEEE] 802 related 109 communications frame formats and parameters [IEEE802]. These include 110 MAC identifiers and protocol identifiers. 112 This document specifies IANA considerations for the allocation of 113 code points under the IANA OUI. It also discusses some other IETF use 114 of IEEE 802 code points. 116 [RFC5226] is incorporated herein except where there are contrary 117 provisions in this document. 119 1.1 Notations Used in This Document 121 This document uses Hexadecimal Notation. Each octet (that is, 8-bit 122 byte) is represented by two hexadecimal digits giving the value of 123 the octet as an unsigned integer. Successive octets are separated by 124 a hyphen. This document consistently uses IETF bit ordering although 125 the physical order of bit transmission within an octet on an IEEE 126 [802.3] link is from the lowest order bit to the highest order bit, 127 the reverse. 129 In this document: 131 "IAB" stands for Individual Address Block, not for Internet 132 Architecture Board; 133 "MAC" stands for Media Access Control, not for Message 134 Authentication Code; and 135 "OUI" stands for Organizationally Unique Identifier. 136 "**" indicates exponentiation. For example, 2**24 is two to the 137 twenty-fourth power. 139 1.2 The IEEE Registration Authority 141 Originally the responsibility of Xerox Corporation, the registration 142 authority for Ethernet parameters is now the IEEE Registration 143 Authority, available on the web at: 145 http://standards.ieee.org/regauth/ 147 Anyone may apply to that Authority for parameters. They may impose 148 fees or other requirements but commonly waive fees for applications 149 from standards development organizations. 151 A list of some allocated OUIs and IABs and their holders is 153 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 155 downloadable from the IEEE Registration Authority site. 157 1.2.1 The IANA OUI 159 The OUI 00-00-5E has been allocated to IANA. 161 1.3 Acknowledgements 163 The contributions and support of the following people, listed in 164 alphabetic order, is gratefully acknowledged: 166 Bernard Aboba, Scott O. Bradner, Ian Calder, Michelle Cotton, Lars 167 Eggert, Eric Gray, Alfred Hoenes, Russ Housley, Charlie Kaufman, 168 Erik Nordmark, Dan Romascanu, Mark Townsley, and Geoff Thompson. 170 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 172 2. Ethernet Identifier Parameters 174 Section 2.1 discusses EUI-48 MAC identifiers, their relationship to 175 OUIs and IABs, and allocations under the IANA OUI. Section 2.2 176 extends this to EUI-64 identifiers. Section 2.3 discusses other IETF 177 MAC identifier use not under the IANA OUI. 179 2.1 48-bit MAC Identifiers and OUIs 181 48-bit MAC "addresses" are the most commonly used Ethernet interface 182 identifiers. Those that are globally unique are also called EUI-48 183 (Extended Unique Identifier 48) identifiers. An EUI-48 is structured 184 into an initial 3 octet OUI (Organizationally Unique Identifier) and 185 an additional 3 octets assigned by the OUI holder. For organizations 186 not requiring 3 octets worth of identifiers, the IEEE allocates IABs 187 (Individual Address Blocks) instead, where the first 4 1/2 octets (36 188 bits) are assigned giving the holder of the IAB 1 1/2 octets (12 189 bits) they can control. 191 The IEEE describes its assignment procedures and policies for IEEE 192 802 related identifiers in [802 O&A]. 194 Two bits within the initial 3 octets of an EUI-48 have special 195 significance: the Group bit (01-00-00) and the Local bit (02-00-00). 196 OUIs and IABs are allocated with the Local bit zero and the Group bit 197 unspecified. Multicast identifiers may be constructed by turning on 198 the Group bit and unicast identifiers constructed by leaving the 199 Group bit zero. 201 For globally unique EUI-48 identifiers allocated by an OUI or IAB 202 owner, the Local bit is zero. If the Local bit is a one, the 203 identifier is considered by IEEE 802 to be a local identifier under 204 the control of the local network administrator. If the Local bit is 205 on, the holder of an OUI (or IAB) has no special authority over 206 48-bit MAC identifiers whose first three (or 4 1/2) octets correspond 207 to their OUI (or IAB). 209 2.1.1 EUI-48 Allocations under the IANA OUI 211 The OUI 00-00-5E has been assigned to IANA as stated in Section 1.2.1 212 above. This includes 2**24 EUI-48 multicast identifiers from 213 01-00-5E-00-00-00 to 01-00-5E-FF-FF-FF and 2**24 EUI-48 unicast 214 identifiers from 00-00-5E-00-00-00 to 00-00-5E-FF-FF-FF. 216 Of these EUI-48 identifiers, the following allocations have been made 217 thus far: 219 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 221 o The 2**23 multicast identifiers from 01-00-5E-00-00-00 through 222 01-00-5E-7F-FF-FF have been allocated for IPv4 multicast 223 [RFC1112]. 225 o The 2**20 multicast identifiers from 01-00-5E-80-00-00 through 226 01-00-5E-8F-FF-FF have been allocated for MPLS multicast 227 [RFCxxxx]. 229 o The 2**8 unicast identifiers from 00-00-5E-00-00-00 through 230 00-00-5E-00-00-FF are reserved and require IESG Ratification 231 for allocation (see Section 5.1). 233 o The 2**8 unicast identifiers from 00-00-5E-00-01-00 through 234 00-00-5E-00-01-FF have been allocated for the Virtual Router 235 Redundancy Protocol (VRRP) [RFC3768]. 237 2.1.2 EUI-48 IANA Allocation Considerations 239 EUI-48 allocations under the current or a future IANA OUI (see 240 Section 5.2) must meet the following requirements: 242 o must be for standards purposes (either for an IETF Standard or 243 other standard related to IETF work), 245 o must be for a block of a power of two identifiers starting at a 246 boundary which is an equal or greater power of two, including 247 the allocation of one (2**0) identifier, 249 o are not to be used to evade the requirement for vendors to 250 obtain their own block of identifiers from the IEEE, and 252 o must be documented in an Internet Draft or RFC. 254 In addition, approval must be obtained as follows, following the 255 procedure in Section 5.1: 257 Small to medium allocations of a block of 1, 2, 4, ..., 32768, 258 65536, (2**0, 2**1, 2**2, ..., 2**15, 2**16) EUI-48 identifiers 259 require Expert Review. 261 Large allocations of 131072 (2**17) or more EUI-48 identifiers 262 require IESG Ratification (see Section 5.1). 264 To simplify record keeping, all future allocations of 256 (2**8) or 265 fewer identifiers shall have the Group bit unspecified, that is, 266 shall be allocations of parallel equal size blocks of multicast and 267 unicast identifiers, even if one of these two types is not needed for 268 the proposed use. The only exception is that requests for unicast 270 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 272 only identifier blocks of any size may be allocated out of the 273 remaining identifiers in the large unicast range from 274 00-00-5E-00-02-00 to 00-00-5E-8F-FF-FF. 276 2.2 64-bit MAC Identifiers 278 IEEE also defines a system of 64-bit MAC identifiers including 279 EUI-64s. Uptake of these "MAC-64" identifiers has been limited. They 280 are currently used in constructing some IPv6 Interface Identifiers as 281 described below and by the following IEEE standards: 283 o IEEE 1394 (also known as FireWire and i.Link), 285 o IEEE 802.15.4 (also known as ZigBee). 287 Adding a 5-octet (40-bit) extension to a 3-octet (24-bit) OUI forms 288 an EUI-64 identifiers under that OUI. As with EUI-48 identifiers, 289 the OUI has the same group/unicast and local/global bits. 291 The discussion below is almost entirely in terms of the "Modified" 292 form of EUI-64 identifiers; however, anyone allocated such an 293 identifier also has the unmodified form and may use it as a MAC 294 identifier on any link that uses such 64-bit identifiers for 295 interfaces. 297 2.2.1 IPv6 Use of Modified EUI-64 Identifiers 299 MAC-64 identifiers are used to form the lower 64 bits of some IPv6 300 addresses (Section 2.5.1 and Appendix A of [RFC4291] and Appendix A 301 of [RFC5214]). When so used the MAC-64 is modified by inverting the 302 local/global bit to form an IETF "Modified EUI-64 identifier". Below 303 is an illustration of a Modified EUI-64 identifier under the IANA 304 OUI, where aa-bb-cc-dd-ee is the extension. 306 02-00-5E-aa-bb-cc-dd-ee 308 The first octet is shown as 02 rather than 00 because, in Modified 309 EUI-64 identifiers, the sense of the local/global bit is inverted 310 compared with EUI-48 identifiers. It is the globally unique values 311 (universal scope) that have the 02 bit on in the first octet while 312 those with this bit off are locally assigned and out of scope for 313 global allocation. 315 The local/global bit was inverted to make it easier for network 316 operators to type in local-scope identifiers. Thus such Modified 317 EUI-64 identifiers as 1, 2, etc. (ignoring leading zeros), are 319 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 321 local. Without the modification, they would have to be 322 02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc., to be local. 324 As with MAC-48 identifiers, the 01 bit on in the first octet 325 indicates a group identifier. 327 When the first two octets of the extension of a Modified EUI-64 328 identifier are FF-FE, the remainder of the extension is a 24-bit 329 value as assigned by the OUI owner for an EUI-48. For example: 331 02-00-5E-FF-FE-yy-yy-yy 332 or 333 03-00-5E-FF-FE-yy-yy-yy 335 where yy-yy-yy is the OUI owner (IANA in this case) assigned portion 336 of an EUI-48 global unicast or multicast identifier. Thus any holder 337 of one or more EUI-48 identifiers under the IANA OUI also has an 338 equal number of Modified EUI-64 identifiers that can be formed by 339 inserting FF-FE in the middle of their EUI-48 identifiers and 340 inverting the local/global bit. 342 (Note: [EUI-64] defines FF-FF as the bits to be inserted to create 343 an IEEE EUI-64 identifier from a MAC-48 identifier. That document 344 says the FF-FE value is used when starting with an EUI-48 345 identifier. The IETF uses only FF-FE to create Modified EUI-64 346 identifiers from 48-bit Ethernet station identifiers regardless of 347 whether they are EUI-48 or MAC-48 local identifiers. EUI-48 and 348 local MAC-48 identifiers are syntactically equivalent, and this 349 doesn't cause any problems in practice.) 351 In addition, certain Modified EUI-64 identifiers under the IANA OUI 352 are reserved for holders of IPv4 addresses as follows: 354 02-00-5E-FE-xx-xx-xx-xx 356 where xx-xx-xx-xx is a 32-bit IPv4 address. For Modified EUI-64 357 identifiers based on IPv4 address, the local/global bit should be set 358 to correspond to whether the IPv4 address is local or global. (Keep 359 in mind that the sense of the Modified EUI-64 identifier local/global 360 bit is reversed from that in (unmodified) MAC-64 identifiers.) 362 2.2.2 EUI-64 IANA Allocation Considerations 364 The following table shows which Modified EUI-64 identifiers under the 365 IANA OUI are reserved, used, or available as indicated. 367 02-00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF reserved 369 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 371 02-00-5E-10-00-00-00-00 to 02-00-5E-EF-FF-FF-FF-FF available for 372 allocation 374 02-00-5E-F0-00-00-00-00 to 02-00-5E-FD-FF-FF-FF-FF reserved 376 02-00-5E-FE-00-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF used by IPv4 377 address holders as described above 379 02-00-5E-FF-00-00-00-00 to 02-00-5E-FF-FD-FF-FF-FF reserved 381 02-00-5E-FF-FE-00-00-00 to 02-00-5E-FF-FE-FF-FF-FF used by holders 382 of EUI-48 identifiers under the IANA OUI as described above 384 02-00-5E-FF-FF-00-00-00 to 02-00-5E-FF-FF-FF-FF-FF reserved 386 Reserved identifiers above require IESG Ratification (see Section 387 5.1) for allocation. IANA EUI-64 identifier allocations under the 388 IANA OUI must meet the following requirements: 390 o must be for standards purposes (either for an IETF Standard or 391 other standard related to IETF work), 393 o must be for a block of a power of two identifiers starting at a 394 boundary which is an equal or greater power of two, including 395 the allocation of one (2**0) identifier, 397 o are not to be used to evade the requirement for vendors to 398 obtain their own block of identifiers from the IEEE, and 400 o must be documented in an Internet Draft or RFC. 402 In addition, approval must be obtained as follows, following the 403 procedure in Section 5.1: 405 Small to medium allocations of a block of 1, 2, 4, ..., 134217728, 406 268435456, (2**0, 2**1, 2**2, ..., 2**27, 2**28) EUI-64 407 identifiers require Expert Review. 409 Allocations of any size, including 536870912 (2**29) or more 410 EUI-64 identifiers, may be made with IESG Ratification (see 411 Section 5.1). 413 To simplify record keeping, all allocations of 65536 (2**16) or less 414 EUI-64 identifiers shall have the Group bit unspecified, that is, 415 shall be allocations of parallel equal size blocks of multicast and 416 unicast identifiers, even if one of these two types is not needed for 417 the proposed use. 419 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 421 2.3 Other IETF Used MAC-48 Identifiers 423 There are two other blocks of MAC-48 identifiers that are used by the 424 IETF as described below. 426 2.3.1 Identifiers Prefixed 33-33 428 All MAC-48 multicast identifiers prefixed "33-33", that is the 2**32 429 multicast MAC identifiers in the range from 33-33-00-00-00-00 to 430 33-33-FF-FF-FF-FF, are used by the IETF for global IPv6 multicast 431 [RFC2464]. In all these identifiers, the Group bit (the bottom bit 432 of the first octet) is on as is required to work properly with 433 existing hardware as a multicast identifier. They also have the 434 Local bit on and are used for this purpose in IPv6 networks. 436 (Historical note: It was the custom during IPv6 design to use "3" 437 for unknown or example values and 3333 Coyote Hill Road, Palo 438 Alto, California, is the address of PARC (Palo Alto Research 439 Center, formerly "Xerox PARC"). Ethernet was originally specified 440 by Digital Equipment Corporation, Intel Corporation, and Xerox 441 Corporation. The pre IEEE [802.3] Ethernet protocol has sometimes 442 been known as "DIX" Ethernet from the first letters of the names 443 of these companies.) 445 2.3.2 The 'CF Series' 447 The Informational [RFC2153] declared the 3-octet values from CF-00-00 448 through CF-FF-FF to be OUIs available for allocation by IANA to 449 software vendors for use in PPP [RFC1661] or for other uses where 450 vendors do not otherwise need an IEEE-assigned OUI. It should be 451 noted that, when used as MAC-48 prefixes, these values have the Local 452 and Group bits on, while all IEEE-allocated OUIs have those bits off. 453 The Group bit is meaningless in PPP. To quote [RFC2153]: "The 454 'CF0000' series was arbitrarily chosen to match the PPP NLPID 'CF', 455 as a matter of mnemonic convenience." 457 CF-00-00 is reserved and IANA lists multicast identifier 458 CF-00-00-00-00-00 as used for Ethernet loopback tests. 460 In over a decade of availability, only a handful of values in the 'CF 461 Series' has been allocated. (See http://www.iana.org under both 462 Ethernet Parameters and PPP Parameters.) 464 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 466 2.3.2.1 Changes to RFC 2153 468 The IANA Considerations in [RFC2153] are updated as follows (no 469 technical changes are made): Use of these identifiers based on IANA 470 allocation is deprecated. IANA is directed not to allocate any 471 further values in the 'CF Series'. 473 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 475 3. Ethernet Protocol Parameters 477 Ethernet Protocol parameters provide a means of indicating the 478 contents of a frame, for example that its contents is IPv4 or IPv6. 480 The concept has been extended to labeling by "tags". A tag in this 481 sense is a prefix whose type is identified by an Ethertype and which 482 is then followed by either another tag or by an Ethertype or LSAP 483 protocol indicator for the "main" body of the frame, as described 484 below. Traditionally in the [802 O&A] world, tags are fixed length 485 and do not include any encoding of their own length. Thus anything 486 which is processing a frame can not, in general, safely process 487 anything in the frame past an Ethertype it does not understand. An 488 example is the C-tag (formerly the Q-tag) [802.1Q]. It provides 489 customer VLAN and priority information for a frame. 491 There are two types of protocol identifier parameters that can occur 492 in Ethernet frames after the initial MAC-48 destination and source 493 identifiers: 495 Ethertypes: These are 16-bit identifiers appearing as the initial 496 two octets after the MAC destination and source (or after a 497 tag) which, when considered as an unsigned integer, are equal 498 to or larger than 0x0600. 500 LSAPs: These are 8-bit protocol identifiers that occur in pairs 501 immediately after an initial 16-bit (two octet) remaining frame 502 length which is in turn after the MAC destination and source 503 (or after a tag). Such a length must, when considered as an 504 unsigned integer, be less than 0x5DC or it could be mistaken as 505 an Ethertype. LSAPs (Link-Layer Subnet Access Points) occur in 506 pairs where one is intended to indicate the source protocol 507 handler and one the destination protocol handler; however, use 508 cases where the two are different have been relatively rare. 510 Neither Ethertypes nor LSAPs are allocated by IANA but by the IEEE 511 Registration authority (see Section 1.2 above and the Ethertype Annex 512 below). However, both LSAPs and Ethertypes have extension mechanisms 513 so that they can be used with five octet Ethernet protocol 514 identifiers under an OUI including those allocated by IANA under the 515 IANA OUI. 517 When using the IEEE 802 LLC format (SNAP) [802 O&A] for a frame, an 518 OUI based protocol identifier can be expressed as follows: 520 xx-xx-AA-AA-03-yy-yy-yy-zz-zz 522 where xx-xx is the frame length and, as above, must be small enough 523 not to be confused with an Ethertype, "AA" is the LSAP that indicates 524 this use and is sometimes referred to as the SNAP SAP, "03" is the 526 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 528 LLC control octet indicating datagram service, yy-yy-yy is an OUI, 529 and zz-zz is a protocol number, under that OUI, allocated by the OUI 530 owner. The odd five-octet length for such OUI based protocol 531 identifiers was chosen so that, with the LLC control octet ("03"), 532 the result is 16 bit aligned. 534 When using an Ethertype to indicate the main type for a frame body, 535 the special "OUI Extended Ethertype" 88-B7 is available. Using this 536 Ethertype, a frame body can begin with 538 88-B7-yy-yy-yy-zz-zz 540 where yy-yy-yy and zz-zz have the same meaning as in the SNAP format 541 described above. 543 It is also possible, within the SNAP format, to use an arbitrary 544 Ethertype. Putting the Ethertype as the zz-zz field after an all 545 zeros OUI (00-00-00) does this. It looks like 547 xx-xx-AA-AA-03-00-00-00-zz-zz 549 where zz-zz was the Ethertype. 551 (Note that, at this point, the 802 protocol syntax facilities are 552 sufficiently powerful that they could be chained indefinitely. 553 Whether support for such chaining is generally required is not 554 clear but [802 O&A] requires support for 556 xx-xx-AA-AA-03-00-00-00-88-B7-yy-yy-yy-zz-zz 558 even though this could be more efficiently expressed by simply 559 pinching out the "00-00-00-88-B7" in the middle.) 561 As well as appearing to label frame contents, 802 Protocol types 562 appear within NBMA (Non-Broadcast Multi-Access) Next Hop Resolution 563 Protocol [RFC2332] messages. Such messages have provisions for both 564 two octet Ethertypes and OUI based protocol types. 566 3.1 Ethernet Protocol Allocation Under the IANA OUI 568 Two-octet protocol numbers under the IANA OUI are available, as in 570 xx-xx-AA-AA-03-00-00-5E-zz-zz 572 A number of such allocations have been made out of the 2**16 573 available from 00-00-5E-00-00 to 00-00-5E-FF-FF (see [IANA]). The 574 extreme values of this range, 00-00-5E-00-00 and 00-00-5E-FF-FF are 575 reserved and require IESG Ratification for allocation (see Section 577 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 579 5.1). New allocations of SNAP SAP protocol (zz-zz) numbers under the 580 IANA OUI must meet the following requirements: 582 o the allocation must be for standards use (either for an IETF 583 Standard or other standard related to IETF work), 585 o it must be documented in an Internet Draft or RFC, and 587 o such protocol numbers are not to be allocated for any protocol 588 that has an Ethertype (because that can be expressed by putting 589 an all zeros "OUI" before the Ethertype as described above). 591 In addition, the Expert Review (or IESG Ratification for the two 592 reserved values) must be obtained using the procedure specified in 593 Section 5.1. 595 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 597 4. Other OUI Based Parameters 599 Some IEEE 802 and other protocols provide for parameters based on an 600 OUI beyond those discussed above. Such parameters most commonly 601 consist of an OUI plus one octet of additional value. They are 602 usually called "vendor specific" parameters although "organization 603 specific" might be more accurate. They would look like 605 yy-yy-yy-zz 607 where yy-yy-yy is the OUI and zz is the additional specifier. An 608 example is the Cipher Suite Selector in IEEE 802.11 ([802.11] page 609 125). 611 Values may be allocated under the IANA OUI for such other OUI-based 612 parameter usage by Expert Review except that, for each use, the 613 additional specifier values consisting of all zero bits and all one 614 bits (0x00 and 0xFF for a one octet specifier) are reserved and 615 require IESG Ratification (see Section 5.1) for allocation. The 616 allocations must be for standards use (either for an IETF Standard or 617 other standard related to IETF work) and be documented in an Internet 618 Draft or RFC. The first time a value is allocated for a particular 619 parameter of this type, an IANA registry will be created to contain 620 that allocation and any subsequent allocations of values for that 621 parameter under the IANA OUI. The Expert will specify the name of the 622 registry. 624 (If a different policy from that above is required for such a 625 parameter, a BCP or standards track RFC must be adopted updating this 626 BCP and specifying the new policy and parameter.) 628 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 630 5. IANA Considerations 632 The entirety of this document concerns IANA Considerations for the 633 allocation of Ethernet parameters in connection with the IANA OUI and 634 related matters. 636 Specifically: 638 Section 1.2.1 provides information on the IANA assigned OUI. 640 Section 2.1.1 lists current EUI-48 assignments under this OUI. 642 Section 2.1.2 specifies IANA considerations for EUI-48 643 assignments. 645 Section 2.2.2 specifies IANA considerations for EUI-64 646 assignments. 648 Section 3.1 provides a pointer to current protocol identifier 649 assignments under the IANA OUI, and specifies IANA considerations 650 for protocol identifier assignments. 652 Section 4 briefly provides IANA considerations relating to OUI 653 based miscellaneous allocations. 655 5.1 Expert Review and IESG Ratification 657 This section specifies the procedure for Expert Review and IESG 658 Ratification of MAC, protocol, and other IANA OUI based identifiers. 659 The Expert(s) referred to in this document shall consist of one or 660 more persons appointed by and serving at the pleasure of the IESG. 661 The procedure described for Expert Review allocations in this 662 document is fully consistent with the IANA Expert Review policy 663 described in Section 4.1 in [RFC5226]. 665 While finite, the universe of code points from which Expert judged 666 allocations will be made is felt to be sufficiently large that the 667 requirements given in this document and the Experts' good judgment 668 are sufficient guidance. The idea is for the Expert to provide a 669 light sanity check for small allocations of EUI identifiers with 670 increased scrutiny by the Expert for medium size allocations of EUI 671 identifiers, allocations of protocol identifiers and, other IANA OUI 672 based parameters. However, it can make sense to allocate very large 673 portions of the MAC identifier code point space. (Note that existing 674 allocations include one for 1/2 of the entire multicast code point 675 space and one for 1/16 of the multicast code point space.) In those 676 cases, and in cases of the allocation of "reserved" values, IESG 677 Ratification of an Expert Review approval recommendation is required 679 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 681 as described below. The procedure is as follows: 683 The applicant always completes the appropriate Template from the 684 Template Annex below and sends it to IANA . 686 IANA always sends the Template to an appointed Expert. If the 687 Expert recuses themselves or is non-responsive, IANA may choose 688 an alternative appointed Expert or, if none are available, will 689 contact the IESG. 691 If the allocation is based on Expert Review: 692 If IANA receives a disapproval from an Expert selected to 693 review an application Template, the application will be denied. 694 If IANA receives approval and code points are available, 695 IANA will make the requested allocation. 697 If the allocation is based on IESG Ratification the procedure 698 starts with the first two steps above for Expert Review. If the 699 Expert disapproves the application, they simply inform IANA; 700 however, if the Expert believes the application should be 701 approved or they are uncertain and believes that the 702 circumstances warrant the attention of the IESG, the Expert 703 will forward the application, together with their reasons for 704 approval or uncertainty, to the IESG, which must approve for 705 the allocation to be granted. This can be accomplished by a 706 management item in an IESG telechat. If the IESG decides not to 707 ratify a favorable opinion by the Expert or decides against an 708 application where the Expert is uncertain, the application is 709 denied, otherwise it is granted. The IESG will communicate its 710 decision to the Expert and to IANA. 712 5.2 Informational IANA Web Page Material 714 IANA also maintains an informational listing on its web site 715 concerning Ethertypes, OUIs, and multicast addresses allocated under 716 OUIs other than the IANA OUI. IANA shall update that list when 717 changes are provided by the Expert. 719 5.3 OUI Exhaustion 721 When the available space for either multicast or unicast EUI-48 722 identifiers under OUI 00-00-5E have been 90% or more exhausted, IANA 723 should request an additional OUI from the IEEE Registration Authority 724 (see Section 1.2) for further IANA allocation use. 726 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 728 6. Security Considerations 730 This document is concerned with allocation of parameters under the 731 IANA OUI and closely related matters. It is not directly concerned 732 with security. 734 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 736 7. Normative References 738 [802 O&A] 739 "IEEE Standard for Local and Metropolitan Area Networks: 740 Overview and Architecture", IEEE 802-2001, 8 March 2002. 741 "IEEE Standard for Local and Metropolitan Area Networks: 742 Overview and Architecture / Amendment 1: Ethertypes for 743 Prototype and Vendor-Specific Protocol Development", IEEE 744 802a-2003, 18 September 2003. 746 8. Informative References 748 [802.1Q] "IEEE Standard for Local and metropolitan area networks / 749 Virtual Bridged Local Area Networks", IEEE 802.1Q-2005, 19 May 750 2006. 752 [802.3] "IEEE Standard for Information technology / 753 Telecommunications and information exchange between systems / 754 Local and metropolitan area networks / Specific requirements / 755 Part 3: Carrier sense multiple access with collision detection 756 (CSMA/CD) access method and physical layer specifications", 757 IEEE 802.3-2005, 9 December 2005. 759 [802.11] "IEEE Standard for Information technology / 760 Telecommunications and information exchange between systems / 761 Local and metropolitan area networks / Specific requirements / 762 Part 11: Wireless LAN Medium Access Control (MAC) and Physical 763 Layer (PHY) Specifications", IEEE 802.11-2007, 11 June 2007. 765 [EUI-64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 766 Registration Authority", 767 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, 768 March 1997. 770 [IANA] Internet Assigned Numbers Authority 771 . 773 [IEEE] Institute of Electrical and Electronics Engineers 774 . 776 [IEEE802] IEEE 802 LAN/MAN (Local Area Network / Metropolitan Area 777 Network) Standards Committee . 779 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, 780 RFC 1112, Stanford University, August 1989. 782 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 783 RFC 1661, July 1994. 785 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 787 [RFC2153] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997. 789 [RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. 790 Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 791 2332, April 1998. 793 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 794 Networks", RFC 2464, December 1998. 796 [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 797 RFC 3768, April 2004. 799 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 800 Architecture", RFC 4291, February 2006. 802 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 803 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 804 2008. 806 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 807 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 808 2008. 810 [RFCxxxx] Eckert, T., E. Rosen, A. Rahul, and Y. Rekhter, "MPLS 811 Multicast Encapsulations", RFC xxxx, November 2007 (draft-ietf- 812 mpls-multicast-encaps-10.txt approved and in the RFC Editor 813 Queue). 815 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 817 Template Annex 819 This annex provides the specific templates for IANA allocations of 820 parameters. Explanatory words in parenthesis in the templates below 821 may be deleted in a completed template as submitted to IANA. 823 EUI-48/EUI-64 Identifier or Identifier Block Template 825 Applicant Name: 827 Applicant Email: 829 Applicant Telephone: (starting with country code) 831 Use Name: (brief name of Parameter use such as "Foo Protocol") 833 Document: (ID or RFC specifying use to which the identifier or 834 block of identifiers will be put.) 836 Specify whether this is an application for EUI-48 or EUI-64 837 identifiers: 839 Size of Block requested: (must be a power of two sized block, can 840 be a block of size one (2**0)) 842 Specify multicast, unicast, or both: 844 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 846 5-octet Ethernet Protocol Identifier Template 848 Applicant Name: 850 Applicant Email: 852 Applicant Telephone: (starting with country code) 854 Use Name: (brief name of use of code point such as "Foo Protocol") 856 Document: (ID or RFC specifying use to which the protocol 857 identifier will be put.) 859 Other IANA OUI Based Parameter Template 861 Applicant Name: 863 Applicant Email: 865 Applicant Telephone: (starting with country code) 867 Protocol where the OUI Based Parameter for which a value is being 868 requested appears: (such as: Cipher Suite selection in IEEE 869 802.11) 871 Use Name: (brief name of use of code point to be allocated, such 872 as "Foo Cipher Suite") 874 Document: (ID or RFC specifying use to which the other IANA OUI 875 based parameter value will be put.) 877 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 879 Ethertypes Annex 881 This annex lists some Ethertypes specified for IETF Protocols or by 882 IEEE 802 as known at the time of publication. A more up-to-date list 883 may be available on the IANA web site, currently at [IANA]. See 884 Section 3 above. 886 Some Ethertypes Specified By The IETF 888 0x0800 Internet Protocol Version 4 (IPv4) 889 0x0806 Address Resolution Protocol (ARP) 890 0x0808 Frame Relay ARP 891 0x880B Point-to-Point Tunneling Protocol (PPTP) 892 0x880C General Switch Management Protocol (GSMP) 893 0x8035 Reverse Address Resolution Protocol (RARP) 894 0x86DD Internet Protocol Version 6 (IPv6) 895 0x8847 MPLS unicast 896 0x8848 MPLS multicast 897 0x8861 Multicast Channel Allocation Protocol (MCAP). 898 0x8863 PPP over Ethernet (PPPoE) Discovery Stage 899 0x8864 PPP over Ethernet (PPPoE) Session Stage 901 Some IEEE 802 Ethertypes 903 0x8100 IEEE Std 802.1Q - Customer VLAN Tag Type (C-Tag, formerly 904 called the Q-Tag) 905 0x8808 IEEE Std 802.3 - Ethernet Passive Optical Network (EPON) 906 0x888E IEEE Std 802.1X - Port-based network access control 907 0x88A8 IEEE Std 802.1Q - Service VLAN tag identifier (S-Tag) 908 0x88B5 IEEE Std 802 - Local Experimental Ethertype 909 0x88B6 IEEE Std 802 - Local Experimental Ethertype 910 0x88B7 IEEE Std 802 - OUI Extended Ethertype 911 0x88C7 IEEE Std 802.11i - Pre-Authentication 912 0x88CC IEEE Std 802.1AB - Link Layer Discovery Protocol (LLDP) 913 0x88E5 IEEE Std 802.1AE - Media Access Control Security 914 0x88F5 IEEE Std 802.1ak - Multiple VLAN Registration Protocol 915 (MVRP) 916 0x88F6 IEEE Std 802.1Q - Multiple Multicast Registration 917 Protocol (MMRP) 918 0x890D IEEE 802.11r - Fast Roaming Remote Request 920 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 922 Disclaimer 924 This document and the information contained herein are provided on an 925 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 926 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 927 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 928 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 929 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 930 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 932 Additional IPR Provisions 934 The IETF takes no position regarding the validity or scope of any 935 Intellectual Property Rights or other rights that might be claimed to 936 pertain to the implementation or use of the technology described in 937 this document or the extent to which any license under such rights 938 might or might not be available; nor does it represent that it has 939 made any independent effort to identify any such rights. Information 940 on the procedures with respect to rights in RFC documents can be 941 found in BCP 78 and BCP 79. 943 Copies of IPR disclosures made to the IETF Secretariat and any 944 assurances of licenses to be made available, or the result of an 945 attempt made to obtain a general license or permission for the use of 946 such proprietary rights by implementers or users of this 947 specification can be obtained from the IETF on-line IPR repository at 948 http://www.ietf.org/ipr. 950 The IETF invites any interested party to bring to its attention any 951 copyrights, patents or patent applications, or other proprietary 952 rights that may cover technology that may be required to implement 953 this standard. Please address the information to the IETF at ietf- 954 ipr@ietf.org. 956 Copyright (C) The IETF Trust (2008). 958 This document is subject to the rights, licenses and restrictions 959 contained in BCP 78, and except as set forth therein, the authors 960 retain all their rights. 962 INTERNET-DRAFT IANA Considerations & IETF Use of IEEE 802 Parameters 964 Author's Address 966 Donald E. Eastlake 3rd 967 155 Beaver Street 968 Milford, MA 01757 USA 970 tel: +1-508-634-2066 971 email: d3e3e3@gmail.com 973 Expiration and File Name 975 This draft expires in December 2008. 977 Its file name is draft-eastlake-ethernet-iana-considerations-08.txt.