idnits 2.17.1 draft-ieee-rac-oui-restructuring-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document date (September 6, 2013) is 3878 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IEEE RAC G. Parsons 3 Internet Draft Ericsson 4 Intended status: Informational September 6, 2013 5 Expires: April 2014 7 OUI Registry Restructuring 8 draft-ieee-rac-oui-restructuring-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be 14 modified, and derivative works of it may not be created, and it 15 may not be published except as an Internet-Draft. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as "work 26 in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on April 9, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. 48 Abstract 50 The IEEE Registration Authority Committee, which has oversight 51 for the OUI based registries, is seeking IETF community input as 52 it finalizes restructuring the OUI registries. This document 53 provides background on the RAC as well as explaining the proposed 54 restructuring and the rationale. 56 Table of Contents 58 1. Introduction...................................................3 59 1.1. History of the IEEE RA and RAC............................3 60 1.2. Mission Statement of the IEEE RAC.........................4 61 2. Existing OUI based registries..................................4 62 2.1. OUI.......................................................6 63 2.2. OUI-36....................................................7 64 2.3. IAB.......................................................7 65 3. Common identifiers.............................................8 66 3.1. EUI-48....................................................8 67 3.2. EUI-64....................................................8 68 3.3. Company ID / Protocol identifier..........................8 69 4. Preventing exhaustion..........................................9 70 4.1. IEEE RAC Prime Directive..................................9 71 4.2. New devices..............................................10 72 4.3. Assignment efficiencies..................................10 73 4.3.1. MAC (EUI48) Addressing..............................10 74 4.3.2. Company ID..........................................10 75 4.4. Virtualization...........................................10 76 4.4.1. Reusing addresses...................................11 77 4.4.2. EUI-128 addresses...................................11 78 5. Proposed new OUI-based registries.............................12 79 5.1. OUI-24: MAC Addresses - Large............................14 80 5.2. OUI-28: MAC Addresses - Medium...........................14 81 5.3. OUI-36: MAC Addresses - Small............................15 82 5.4. CompanyID................................................15 83 5.4.1. Application Note....................................16 84 6. Protocol Considerations.......................................16 85 7. Security Considerations.......................................16 86 8. IANA Considerations...........................................16 87 9. Conclusions...................................................17 88 10. References...................................................17 89 10.1. Normative References....................................17 90 10.2. Informative References..................................17 91 11. Acknowledgments..............................................17 93 1. Introduction 95 The IEEE Registration Authority (RA) operates under the direction 96 of the IEEE-SA Board of Governors. IEEE is recognized by ISO/IEC 97 as the authorized Registration Authority to provide this service 98 world-wide. The IEEE Registration Authority Committee (RAC) 99 provides technical oversight for the IEEE Registration Authority 100 Activities. 102 The IEEE RA administers the assignment of 24-bit identifiers, 103 formally known as an "Organizationally Unique Identifier" (OUI). 104 It can be used alone as an identifier, or used to create MAC 105 Addresses, Bluetooth Device Addresses or Ethernet Addresses. 107 Given the possibility of consuming all the MAC addresses, the 108 IEEE RAC places restrictions on their use. While the number 109 space is large, it is not inexhaustible, and the IEEE-RAC reviews 110 trends to determine if a new strategy is required to prevent 111 exhaustion. Current usage trends and new applications have 112 convinced the RAC that measures are needed to more efficiently 113 use the MAC address space. This document presents the background 114 as well as the proposed changes to the OUI registries. 116 1.1. History of the IEEE RA and RAC 118 The IEEE Registration Authority (RA) was formed by the IEEE 119 Standards Board in 1986 at the initiative of the IEEE P802 120 (LAN/MAN) standards group in order to register Organizationally 121 Unique Identifiers (OUI). Since that time, the activities of the 122 Registration Authority have continued to expand. 124 The IEEE Registration Authority Committee (IEEE RAC) was formed 125 in 1991 as a volunteer oversight of the IEEE staff operated RA. 126 In 1998, the IEEE RAC became a committee of the IEEE Standards 127 Association Board of Governors, (IEEE SA BoG). 129 In 1997, the IEEE Registration Authority assumed responsibility 130 for the registration of EtherType Fields, as defined in the 131 current edition of IEEE Std 802.3, and in 1998 began 132 administering Individual Address Block assignments in an effort 133 to preserve the OUI assignments and offer the option of obtaining 134 a smaller amount of addresses. 136 In 2003, it assumed responsibility for administering, allocating 137 and managing the Logical Link Control (LLC) and Standard Group 138 MAC addresses. IEEE has become the single point of contact with 139 respect to all information associated with LAN addresses. 141 In 2004, IEEE established three registration authorities 142 associated with IEEE 1451.4-2004. They are: 144 o Unique Registration Numbers (URNS) 146 o IEEE Templates and TDL Items 148 o Manufacturer_ID 150 On 27 April 2007, three additional registries were launched. 151 Unlike the registries launched in 2004, each registry represents 152 a different IEEE standard. 154 o OUI-36 156 o IEEE 802.16 Operator ID 158 o Provider Service Identifier (PSID) 160 The IEEE Registration Authority formerly had administrative 161 responsibility for the IEEE POSIX Certification. 163 1.2. Mission Statement of the IEEE RAC 165 The IEEE Registration Authority Committee (IEEE RAC) is the 166 oversight committee for the IEEE Registration Authority. 168 The IEEE RAC is international in scope, assisting standard 169 developing organizations in their establishment of unambiguous, 170 sustainable registration authorities. 172 The IEEE RAC considers the long-term interests of the ultimate 173 users of these standards, while pragmatically addressing the 174 needs of the affected organizations, industries, and the IEEE. 176 2. Existing OUI based registries 178 The OUI ("Organizationally Unique Identifier") is defined in IEEE 179 Std 802-2001 [1] and its structure is shown in Figure 1 below 180 with an example for use as a protocol identifier shown in Figure 181 2. 183 Application dependent: 184 | e.g., I/G or U/L 185 | address bit, or 186 | M or X bit in 187 | protocol ID 188 | 189 +-----+ 190 | | 191 +----+----+----+----+----+----+-+--+--+-+ 192 Octet 0 | | | | | | | | | 193 |----+----+----+----+----+----+----+----+ 194 Octet 1 | | | | | | | | | 195 |----+----+----+----+----+----+----+----+ 196 Octet 2 | | | | | | | | | 197 +----+----+----+----+----+----+----+----+ 199 Figure 1 - Structure of an OUI 201 Of note is that only 22 bits are actually assigned as there are 202 specific uses for the first two bits transmitted (the two least 203 significant bits of octet 0). As a MAC address, the first bit 204 transmitted indicates either an individual or group address 205 (I/G), and the second bit transmitted indicates universal or 206 local administration of the address (U/L). When used as a 207 protocol identifier (Figure 2), these bits are the M and X bits. 208 As a result of these uses, all previous OUI assignments have set 209 these two bits to 0. 211 Hexadecimal representation: AC-DE-48 213 Octet: 0 1 2 +--X bit 214 |+-M bit 215 LSB MSB LSB MSB +------+++ 216 | | | | Octet 0 |10101100| 217 | | | | Octet 1 |11011110| 218 0011 0101 0111 1011 0001 0010 Octet 2 |01001000| 219 || +--------+ 220 |+--X bit 221 +---M bit 223 Figure 2 - Format of an OUI used as protocol identifier 225 While the majority of customers purchase the OUI, there are 226 currently three OUI based registries: 228 1. OUI 230 2. OUI-36 232 3. IAB 234 The latter two use an IEEE reserved OUI from the first registry 235 as their root. 237 These registries support the standards of IEEE 802 as well as 238 ISO/IEC 8802 and other standards that use unique LAN addresses. 239 IEEE has been authorized by the ISO Council to act as the 240 exclusive registration authority for the implementation of 241 International Standards in the ISO/IEC 8802 series. 243 2.1. OUI 245 An OUI or 'company_id' is a 24-bit globally unique assigned 246 number referenced by various standards. The OUI is usually 247 concatenated with 24 or 40 bits by an Organization to create a 248 48-bit or 64-bit number that is unique to a particular piece of 249 hardware. It can be used to create MAC Addresses, Bluetooth 250 Device Addresses or Ethernet Addresses. 252 There are other uses of the OUI as well, such as its use as a 253 company identifier in the SNAP protocol. 255 The OUI or 'company_id' can be used in conjunction with a number 256 of standards. It does not limit your right to use your assignment 257 for both OUI and 'company_id' purposes. 259 Additional information can be found on the IEEE RA website: 260 http://standards.ieee.org/develop/regauth/oui/index.html 262 2.2. OUI-36 264 OUI-36 is a 36-bit identifier that can be used as an Individual 265 Address Block (IAB) or as an extended OUI. The OUI-36 may be 266 appended with four organization-supplied bits to form a 40-bit 267 Context Dependent Identifier (CDI-40), with twelve organization- 268 supplied bits to form an EUI-48, or with organization-supplied 28 269 bits to form an EUI-64. Applications making use of an OUI-36 270 should make no assumptions about the bit pattern that will be 271 present in the (24-bit most-significant) OUI portion of the 272 assigned OUI-36. 274 Additional information can be found on the IEEE RA website: 275 http://standards.ieee.org/develop/regauth/oui36/index.html 277 2.3. IAB 279 An IAB is for organizations that need less than 4097 unique 48- 280 bit numbers (EUI-48) and thus find it hard to justify buying 281 their own OUI. It is a particular OUI concatenated with 12 282 additional IEEE-provided bits, leaving only 12 bits for the 283 owners to assign to their (up to 4096) individual devices. 285 Unlike an OUI, which allows the assignee to assign values in 286 various different number spaces (for example, EUI-48, EUI-64, and 287 the various CDI number spaces), the IAB can only be used to 288 assign EUI-48 identifiers. 290 The Individual Address Block (IAB) can be used in conjunction 291 with a number of standards. It does not limit your right to use 292 your assignment for multiple purposes. 294 Additional information can be found on the IEEE RA website: 295 http://standards.ieee.org/develop/regauth/iab/index.html 297 3. Common identifiers 299 The OUI defined in IEEE Std 802-2001 [1] can be used to generate 300 48-bit Universal LAN MAC addresses to uniquely identify Local and 301 Metropolitan Area Networks stations, and Protocol Identifiers to 302 identify public and private protocols. A revision [3] of this 303 standard is underway (expecting to complete in late 2013) that 304 will, among other updates, also describe the 64-bit address. 306 3.1. EUI-48 308 The IEEE defined 48-bit extended unique identifier (EUI-48) is a 309 concatenation of either a 24-bit Organizationally Unique 310 Identifier (OUI) value administered by the IEEE Registration 311 Authority (IEEE-RA) and a 24-bit extension identifier assigned by 312 the organization with that OUI assignment, or the concatenation 313 of a 36-bit Individual Address Block (IAB) identifier /or 36-bit 314 Organizationally Unique Identifier (OUI-36)/ and a 12-bit 315 extension identifier assigned by the organization with that IAB 316 assignment. 318 Additional information can be found on the IEEE RA website: 319 http://standards.ieee.org/develop/regauth/tut/eui48.pdf 321 3.2. EUI-64 323 The IEEE-defined 64-bit extended unique identifier (EUI-64) is a 324 concatenation of the Organizationally Unique Identifier (OUI) 325 value assigned by the IEEE Registration Authority (IEEE RA) and 326 the extension identifier assigned by the organization with that 327 OUI assignment resulting in a 64-bit unique identifier. The 328 extension identifiers shall be 40 bits for the 24-bit OUI-24 and 329 28 bits for the 36-bit OUI-36. Other OUI lengths will have 330 extension identifiers making up the difference between each 331 assigned OUI length and the 64-bit EUI-64. 333 Additional information can be found on the IEEE RA website: 334 http://standards.ieee.org/develop/regauth/tut/eui48.pdf 336 3.3. Company ID / Protocol identifier 338 IEEE Std 802 provides for the use of Protocol Identifiers in 339 conjunction with the SNAP/SAP reserved LLC address. A Protocol 340 Identifier is defined as a sequence of five octets. The first 341 three octets take the values of the three octets of the OUI in 342 order; the following two octets are administered by the OUI 343 assignee. The hexadecimal representation of the Protocol 344 Identifier consists of the hexadecimal values of the five octets 345 in order, separated by hyphens, in the order transmitted by the 346 network application, left to right. 348 Additional information can be found on the IEEE RA website: 349 http://standards.ieee.org/develop/regauth/tut/lanman.pdf 351 4. Preventing exhaustion 353 Given the possibility of consuming all the MAC addresses, the 354 IEEE RAC places restrictions on their use. For new applications, 355 EUI-48 identifiers are restricted to use in low volume 356 applications, such as the identification of software interface 357 standards or hardware model numbers. 359 While the number of EUI-48 identifiers is large, it is not 360 inexhaustible, and the IEEE-RAC reviews trends to determine if a 361 new strategy is required to prevent exhaustion. Current usage 362 trends and new applications have convinced the RAC that measures 363 are needed to more efficiently use the EUI-48 address space. 365 4.1. IEEE RAC Prime Directive 367 A "prime directive" of the IEEE RAC is to not run out of global 368 EUI-48 addresses (previously called MAC or MAC-48 addresses) for 369 100 years. The clock started in 1980 when this space was created 370 by Xerox (and was called Block ID at the time). 372 In about 30 years, less than 20,000 OUIs have been assigned. So 373 if the growth is linear, there is more than 99% of the space 374 left, giving the world a 4000 year supply. However, the growth 375 trend from last few years is not linear. If that trend 376 continues, then there is only 26 years left before exhaustion of 377 OUIs and global address space they are used to create. The IEEE 378 RAC is studying these trends and has considered several possible 379 causes. 381 4.2. New devices 383 There has been an increase in new device categories in the last 384 several years - including smart phones, tablets and various 385 sensors - all that have more than one network interface (e.g., 386 WiFi, Bluetooth, Ethernet) that requires a MAC address. 388 In addition, there are a few manufacturers that are volume users. 389 That is, they are using more than 32 million MAC (EUI-48) 390 addresses per month. 392 4.3. Assignment efficiencies 394 Most manufacturers, however, use far less MAC (EUI-48) addresses 395 per month. They either have a smaller production volume or are 396 just starting. And actually, most OUI customers have only bought 397 one OUI. If they need only MAC addresses, then they could 398 benefit from options that would offer them fewer. 400 This would reduce the many "lost" or "unused" MAC addresses from 401 OUIs that were assigned but the manufacturer did not use the full 402 16 million. 404 4.3.1. MAC (EUI48) Addressing 406 ~260 billion EUI-48 (of ~70 trillion possible) addresses have 407 been assigned. While the RAC knows these have not all be used in 408 devices, there is no way to confirm this. The RAC does however, 409 require that repeat customers confirm that they have used 95% of 410 the addresses before they are assigned another OUI block. 412 The RAC requires that only one (or at most a few) global EUI-48 413 addresses be assigned to a single hardware device. This is to 414 avoid stockpiling of addresses in devices. However, this may be 415 problematic for some applications like virtualization 417 4.3.2. Company ID 419 In order to get a Protocol identifier or company ID, an OUI must 420 be assigned. If the manufacturer does not intend to use it for 421 addressing, then those addresses are lost. 423 4.4. Virtualization 425 Virtualization from the IEEE RAC perspective is essentially the 426 usage of global MAC (EUI-48) addresses by software - instead of 427 by a hardware device (i.e., "burned in") as was originally 428 intended. 430 Traditionally the RAC limited manufacturers to only a few 431 addresses per hardware device to prevent stockpiling addresses in 432 devices. This would invalidate virtualization solutions. As a 433 result, the RAC is now allowing assignment of an OUI (16M EUI-48 434 addresses) for virtualization use until a further policy is 435 clarified. 437 One requirement for virtual machines is that they are mobile and 438 can be moved around on a rack, within a data center or even 439 across data centers. Such movement in a multi-vendor environment 440 requires a globally unique MAC (EUI48) address to be scalable. 442 4.4.1. Reusing addresses 444 However, another inherent nature of virtualization is the 445 creation and destruction of the virtual machine. Hundreds, 446 thousands or millions can be created or destroyed per second in a 447 data center. If kept in a closed environment, this requires a 448 local or reusable MAC (EUI48) address. If a global address is 449 used, then they could be used at an alarming rate as they are not 450 defined as reusable. 452 Unfortunately, there appears to be violation of the IEEE RAC 453 policy in the virtualization sector. That is, some are using 454 global MAC (EUI-48) addresses per rack / cluster / data center 455 and then reusing them in an adjacent rack / cluster / data 456 center. 458 Clearly this is not permitted and the RAC has been studying what 459 guidance should be given to virtualization vendors such that the 460 global MAC address space is not tainted. 462 It has been suggested that a DHCP-like mechanism or a standard 463 allocation should be developed for reusable MAC addresses such 464 that there is some order to assignment in an environment where 465 addresses are created and destroyed. 467 4.4.2. EUI-128 addresses 469 Given the potential for using a large number of addresses, the 470 RAC is also exploring the feasibility of defining a new "EUI-128" 471 identifier (i.e., 128 bits) specifically for future 472 virtualization applications. 474 5. Proposed new OUI-based registries 476 The IEEE RAC has been studying options to restructure the OUI- 477 based registries and products for over a year and is now 478 reviewing a final proposal. This proposal provides a refinement 479 of the OUI-based registries improves efficiency of assignment 480 allocations and attempts to address virtualization issues. 482 While there was some desire for the OUI registries to fully 483 separate the semantic of protocol identifier (e.g., the 24 bits 484 assigned) and addresses (e.g., a 48-bit address created based on 485 the 24 bits assigned), the concern raised was that this was not 486 enforceable by definition. 488 The IEEE RAC conducted a survey of its customers and it quickly 489 became clear that there were first-time customers (and in most 490 cases they never made another purchase) and repeat customers 491 (many of who were volume users). It was also very clear that the 492 dominant use was to create global MAC (EUI48) addresses. As a 493 result, the assignment decisions could be separated as proposed 494 in Figure 3 below. 496 Customer Type Requirements for IDs 497 ''''''''''''' '''''''''''''''''''' 498 +------------------------+ 499 | | 500 ''''' Company ID only | 501 | | | 502 | +------------------------+ 503 | 504 | +------------------------+ 505 | | MAC Addresses and | 506 +-----------+ |---| other unique IDs only | 507 | First- | | | | 508 | time |____| +------------------------+ 509 |''''''''| Customers | | 510 | | | | +------------------------+ 511 | +-----+-----+ | | Combined Company ID | 512 | |...| and MAC Addresses or | 513 | | other IDs | 514 | +------------------------+ 515 ,--+--. 516 ,' `. 517 ,' `. 518 ; Customer : 519 | Decision | 520 : Tree ; 521 `. ,' 522 `. ,' 523 `-----' +------------------------+ 524 | | MAC Addresses and | 525 | |--| other unique IDs only | 526 | +-----------+ | | | 527 | | Repeat | | +------------------------+ 528 | | Customers | | 529 |--------| ''''''| 530 | | | +------------------------+ 531 +-----------+ | | Combined Company ID | 532 |..| and MAC Addresses or | 533 | other IDs | 534 +------------------------+ 536 Figure 3: Decision Tree for assignment of Unique IDs/MAC 537 addresses 539 The proposal that the IEEE RAC is considering is to add an 540 additional size option for creating MAC (EUI48) addresses -- 1 541 million -- as well as creating a new CompanyID registry. This is 542 shown in Table 1 below and described in the following sub- 543 sections. 545 Table 1: New Proposed OUI-based Product Registries 546 +-------------------+------------+-------------------+ 547 |Manufacturer field |Product |EUI48(MAC)addresses| 548 +-------------------+------------+-------------------+ 549 | 24-bit identifier |OUI-24/MA-L |16777216 | 550 +-------------------+------------+-------------------+ 551 |- |OUI-28/MA-M |1048576 | 552 +-------------------+------------+-------------------+ 553 | 36-bit identifier |OUI-36/MA-S |4096 | 554 +-------------------+------------+-------------------+ 555 | 24-bit identifier |CompanyID |- | 556 +-------------------+------------+-------------------+ 558 5.1. OUI-24: MAC Addresses - Large 560 The OUI-24 is a 24-bit globally unique assigned number. 562 This is the base OUI registry. It is simply a renaming of the 563 existing OUI registry. 565 An assignment from this registry includes the ability to create: 567 o 24-bit company ID / protocol identifiers 569 o 48-bit EUI48 addresses 571 o 64-bit EUI64 addresses 573 5.2. OUI-28: MAC Addresses - Medium 575 The OUI-28 is a 28-bit globally unique assigned number. 577 This new OUI-28 is created by the IEEE RA by assigning an 578 additional 4 bits from an OUI-24 (that would be listed as IEEE 579 reserved). 581 An assignment from this registry includes the ability to create: 583 o 48-bit EUI48 addresses 584 o 64-bit EUI64 addresses 586 Note that the IEEE RAC does not intend to define the usage of a 587 28-bit company ID / protocol identifier at this time. 589 5.3. OUI-36: MAC Addresses - Small 591 The OUI-36 is a 36-bit globally unique assigned number. 593 The OUI-36 is created by the IEEE RA by assigning an additional 594 12 bits from an OUI-24 (that is listed as IEEE reserved). 596 This is the existing OUI-36 registry, and it is proposed to merge 597 the IAB registry with this as well. 599 An assignment from this registry includes the ability to create: 601 o 36-bit company ID / protocol identifiers 603 o 48-bit EUI48 addresses 605 o 64-bit EUI64 addresses 607 5.4. CompanyID 609 The CompanyID is a 24-bit globally unique assigned number. 610 However, any MAC addresses created with this Company ID would 611 only be locally significant (i.e., the U/L bit is set to 1) 613 This new CompanyID is created by the IEEE RA assigning an OUI 614 with the X bit set to 1 (this bit becomes the U/L bit when used 615 to create a MAC address). Traditionally, this use has been 616 reserved to separate the local and global address spaces but no 617 use had been defined for protocol identifiers. It is proposed 618 that only a segment (e.g., the bottom half) of the potential 22- 619 bit space be made available for allocation. 621 An assignment from this registry includes the ability to create: 623 o 24-bit company ID / protocol identifiers 625 NOTE: This requires that legacy uses of the OUI in protocols do 626 not try to define the M and X bits for other uses. The RAC is 627 not aware of any standard uses of the M and X bits that would 628 prevent defining this new registry. 630 5.4.1. Application Note 632 It is further proposed that virtualization manufacturers apply 633 for assignments of these CompanyIDs. These could then be used to 634 create MAC (EUI48) addresses in the local space that could be 635 reused. Additionally, it would also provide some order and allow 636 for multi-vendor usage of a subset of the local space for the 637 virtualization application (or any application that could benefit 638 from reusable addresses). 640 6. Protocol Considerations 642 There may be unintended consequences of these additions to the 643 OUI-based registries for existing protocols. A study and review 644 of many protocols was conducted and there were no apparent issues 645 identified. 647 IETF community input is requested, especially as it relates to 648 the embedded use or carriage of addresses or protocol identifiers 649 in other protocols. For protocol identifiers, the IEEE RAC would 650 be interested if any protocol defines the M and X bits for other 651 uses. 653 7. Security Considerations 655 There may be unintended consequences of these additions to the 656 OUI-based registries, though none are apparent. 658 IETF community input is requested. 660 8. IANA Considerations 662 There may be some affect on the existing IANA registries based on 663 the restructuring of the OUI based registries. 665 However, this has not yet been studied. 667 IETF community input is requested. 669 9. Conclusions 671 While the background presented in this document is representative 672 of the current situation, the proposals in this document have not 673 yet been implemented, and therefore may change. 675 The IEEE-SA Board of Governors has made a decision, based on the 676 recommendation of the IEEE RAC, on the implementation of the OUI 677 registry restructuring. A summary has been provided in this 678 document, but full details are under development by the IEEE RAC. 679 It is expected that implementation will start in 2014. 681 IETF community input is requested to identify any issues with the 682 restructuring proposal, especially as it affects IETF protocols. 683 Please provide your comments to the RAC public list with "IETF 684 community comment" as the start of the subject field: 686 STDS-RAC-PUBLIC@LISTSERV.IEEE.ORG 688 10. References 690 10.1. Normative References 692 [1] IEEE Std 802-2001, "IEEE Standard for Local and Metropolitan 693 Area Networks: Overview and Architecture" 694 https://standards.ieee.org/about/get/802/802.html 696 10.2. Informative References 698 [2] IEEE Registration Authority website 699 http://standards.ieee.org/develop/regauth/ 701 [3] IEEE P802 - Overview & Architecture revision project 702 http://www.ieee802.org/1/pages/802-rev.html 704 11. Acknowledgments 706 The IEEE RAC appreciates the cooperation of IETF in publicizing 707 these proposals to the IETF community including at its meetings. 709 Some of the background material in this document is based on 710 information previously available on the IEEE RA website [2]. 712 Authors Addresses 714 Glenn Parsons 715 Ericsson 717 Phone: +1-613-963-8141 718 Email: glenn.parsons@ericsson.com