IEEE RAC                                                     G. Parsons
Internet Draft                                                 Ericsson
Intended status:  Informational                       September 6, 2013
Expires: April 2014



                      OUI Registry Restructuring
                draft-ieee-rac-oui-restructuring-01.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be
   modified, and derivative works of it may not be created, and it
   may not be published except as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as "work
   in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 9, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents





Parsons                 Expires April 9, 2014                  [Page 1]


Internet-Draft        OUI Registry Restructuring         September 2013


   carefully, as they describe your rights and restrictions with
   respect to this document.

Abstract

   The IEEE Registration Authority Committee, which has oversight
   for the OUI based registries, is seeking IETF community input as
   it finalizes restructuring the OUI registries.  This document
   provides background on the RAC as well as explaining the proposed
   restructuring and the rationale.

Table of Contents


   1. Introduction...................................................3
      1.1. History of the IEEE RA and RAC............................3
      1.2. Mission Statement of the IEEE RAC.........................4
   2. Existing OUI based registries..................................4
      2.1. OUI.......................................................6
      2.2. OUI-36....................................................7
      2.3. IAB.......................................................7
   3. Common identifiers.............................................8
      3.1. EUI-48....................................................8
      3.2. EUI-64....................................................8
      3.3. Company ID / Protocol identifier..........................8
   4. Preventing exhaustion..........................................9
      4.1. IEEE RAC Prime Directive..................................9
      4.2. New devices..............................................10
      4.3. Assignment efficiencies..................................10
         4.3.1. MAC (EUI48) Addressing..............................10
         4.3.2. Company ID..........................................10
      4.4. Virtualization...........................................10
         4.4.1. Reusing addresses...................................11
         4.4.2. EUI-128 addresses...................................11
   5. Proposed new OUI-based registries.............................12
      5.1. OUI-24: MAC Addresses - Large............................14
      5.2. OUI-28: MAC Addresses - Medium...........................14
      5.3. OUI-36: MAC Addresses - Small............................15
      5.4. CompanyID................................................15
         5.4.1. Application Note....................................16
   6. Protocol Considerations.......................................16
   7. Security Considerations.......................................16
   8. IANA Considerations...........................................16
   9. Conclusions...................................................17
   10. References...................................................17
      10.1. Normative References....................................17



Parsons                 Expires April 9, 2014                  [Page 2]


Internet-Draft        OUI Registry Restructuring         September 2013


      10.2. Informative References..................................17
   11. Acknowledgments..............................................17

1. Introduction

   The IEEE Registration Authority (RA) operates under the direction
   of the IEEE-SA Board of Governors. IEEE is recognized by ISO/IEC
   as the authorized Registration Authority to provide this service
   world-wide. The IEEE Registration Authority Committee (RAC)
   provides technical oversight for the IEEE Registration Authority
   Activities.

   The IEEE RA administers the assignment of 24-bit identifiers,
   formally known as an "Organizationally Unique Identifier" (OUI).
   It can be used alone as an identifier, or used to create MAC
   Addresses, Bluetooth Device Addresses or Ethernet Addresses.

   Given the possibility of consuming all the MAC addresses, the
   IEEE RAC places restrictions on their use.  While the number
   space is large, it is not inexhaustible, and the IEEE-RAC reviews
   trends to determine if a new strategy is required to prevent
   exhaustion.  Current usage trends and new applications have
   convinced the RAC that measures are needed to more efficiently
   use the MAC address space.  This document presents the background
   as well as the proposed changes to the OUI registries.

1.1. History of the IEEE RA and RAC

   The IEEE Registration Authority (RA) was formed by the IEEE
   Standards Board in 1986 at the initiative of the IEEE P802
   (LAN/MAN) standards group in order to register Organizationally
   Unique Identifiers (OUI). Since that time, the activities of the
   Registration Authority have continued to expand.

   The IEEE Registration Authority Committee (IEEE RAC) was formed
   in 1991 as a volunteer oversight of the IEEE staff operated RA.
   In 1998, the IEEE RAC became a committee of the IEEE Standards
   Association Board of Governors, (IEEE SA BoG).

   In 1997, the IEEE Registration Authority assumed responsibility
   for the registration of EtherType Fields, as defined in the
   current edition of IEEE Std 802.3, and in 1998 began
   administering Individual Address Block assignments in an effort
   to preserve the OUI assignments and offer the option of obtaining
   a smaller amount of addresses.




Parsons                 Expires April 9, 2014                  [Page 3]


Internet-Draft        OUI Registry Restructuring         September 2013


   In 2003, it assumed responsibility for administering, allocating
   and managing the Logical Link Control (LLC) and Standard Group
   MAC addresses. IEEE has become the single point of contact with
   respect to all information associated with LAN addresses.

   In 2004, IEEE established three registration authorities
   associated with IEEE 1451.4-2004. They are:

   o  Unique Registration Numbers (URNS)

   o  IEEE Templates and TDL Items

   o  Manufacturer_ID

   On 27 April 2007, three additional registries were launched.
   Unlike the registries launched in 2004, each registry represents
   a different IEEE standard.

   o  OUI-36

   o  IEEE 802.16 Operator ID

   o  Provider Service Identifier (PSID)

   The IEEE Registration Authority formerly had administrative
   responsibility for the IEEE POSIX Certification.

1.2. Mission Statement of the IEEE RAC

   The IEEE Registration Authority Committee (IEEE RAC) is the
   oversight committee for the IEEE Registration Authority.

   The IEEE RAC is international in scope, assisting standard
   developing organizations in their establishment of unambiguous,
   sustainable registration authorities.

   The IEEE RAC considers the long-term interests of the ultimate
   users of these standards, while pragmatically addressing the
   needs of the affected organizations, industries, and the IEEE.



2. Existing OUI based registries

   The OUI ("Organizationally Unique Identifier") is defined in IEEE
   Std 802-2001 [1] and its structure is shown in Figure 1 below



Parsons                 Expires April 9, 2014                  [Page 4]


Internet-Draft        OUI Registry Restructuring         September 2013


   with an example for use as a protocol identifier shown in Figure
   2.

                                            Application dependent:
                                             | e.g., I/G or U/L
                                             | address bit, or
                                             | M or X bit in
                                             | protocol ID
                                             |
                                             +-----+
                                             |     |
             +----+----+----+----+----+----+-+--+--+-+
   Octet 0   |    |    |    |    |    |    |    |    |
             |----+----+----+----+----+----+----+----+
   Octet 1   |    |    |    |    |    |    |    |    |
             |----+----+----+----+----+----+----+----+
   Octet 2   |    |    |    |    |    |    |    |    |
             +----+----+----+----+----+----+----+----+


                      Figure 1 - Structure of an OUI

   Of note is that only 22 bits are actually assigned as there are
   specific uses for the first two bits transmitted (the two least
   significant bits of octet 0).  As a MAC address, the first bit
   transmitted indicates either an individual or group address
   (I/G), and the second bit transmitted indicates universal or
   local administration of the address (U/L).  When used as a
   protocol identifier (Figure 2), these bits are the M and X bits.
   As a result of these uses, all previous OUI assignments have set
   these two bits to 0.


















Parsons                 Expires April 9, 2014                  [Page 5]


Internet-Draft        OUI Registry Restructuring         September 2013


                  Hexadecimal representation: AC-DE-48

   Octet:  0           1          2                        +--X bit
                                                           |+-M bit
       LSB   MSB   LSB   MSB                        +------+++
       |       |   |       |                Octet 0 |10101100|
       |       |   |       |                Octet 1 |11011110|
       0011 0101   0111 1011  0001 0010     Octet 2 |01001000|
       ||                                           +--------+
       |+--X bit
       +---M bit

          Figure 2 - Format of an OUI used as protocol identifier


   While the majority of customers purchase the OUI, there are
   currently three OUI based registries:

   1. OUI

   2. OUI-36

   3. IAB

   The latter two use an IEEE reserved OUI from the first registry
   as their root.

   These registries support the standards of IEEE 802 as well as
   ISO/IEC 8802 and other standards that use unique LAN addresses.
   IEEE has been authorized by the ISO Council to act as the
   exclusive registration authority for the implementation of
   International Standards in the ISO/IEC 8802 series.



2.1. OUI

   An OUI or 'company_id' is a 24-bit globally unique assigned
   number referenced by various standards. The OUI is usually
   concatenated with 24 or 40 bits by an Organization to create a
   48-bit or 64-bit number that is unique to a particular piece of
   hardware. It can be used to create MAC Addresses, Bluetooth
   Device Addresses or Ethernet Addresses.

   There are other uses of the OUI as well, such as its use as a
   company identifier in the SNAP protocol.



Parsons                 Expires April 9, 2014                  [Page 6]


Internet-Draft        OUI Registry Restructuring         September 2013


   The OUI or 'company_id' can be used in conjunction with a number
   of standards. It does not limit your right to use your assignment
   for both OUI and 'company_id' purposes.

   Additional information can be found on the IEEE RA website:
   http://standards.ieee.org/develop/regauth/oui/index.html

2.2. OUI-36

   OUI-36 is a 36-bit identifier that can be used as an Individual
   Address Block (IAB) or as an extended OUI. The OUI-36 may be
   appended with four organization-supplied bits to form a 40-bit
   Context Dependent Identifier (CDI-40), with twelve organization-
   supplied bits to form an EUI-48, or with organization-supplied 28
   bits to form an EUI-64. Applications making use of an OUI-36
   should make no assumptions about the bit pattern that will be
   present in the (24-bit most-significant) OUI portion of the
   assigned OUI-36.

   Additional information can be found on the IEEE RA website:
   http://standards.ieee.org/develop/regauth/oui36/index.html



2.3. IAB

   An IAB is for organizations that need less than 4097 unique 48-
   bit numbers (EUI-48) and thus find it hard to justify buying
   their own OUI. It is a particular OUI concatenated with 12
   additional IEEE-provided bits, leaving only 12 bits for the
   owners to assign to their (up to 4096) individual devices.

   Unlike an OUI, which allows the assignee to assign values in
   various different number spaces (for example, EUI-48, EUI-64, and
   the various CDI number spaces), the IAB can only be used to
   assign EUI-48 identifiers.

   The Individual Address Block (IAB) can be used in conjunction
   with a number of standards. It does not limit your right to use
   your assignment for multiple purposes.

   Additional information can be found on the IEEE RA website:
   http://standards.ieee.org/develop/regauth/iab/index.html






Parsons                 Expires April 9, 2014                  [Page 7]


Internet-Draft        OUI Registry Restructuring         September 2013


3. Common identifiers

   The OUI defined in IEEE Std 802-2001 [1] can be used to generate
   48-bit Universal LAN MAC addresses to uniquely identify Local and
   Metropolitan Area Networks stations, and Protocol Identifiers to
   identify public and private protocols.  A revision [3] of this
   standard is underway (expecting to complete in late 2013) that
   will, among other updates, also describe the 64-bit address.

3.1. EUI-48

   The IEEE defined 48-bit extended unique identifier (EUI-48) is a
   concatenation of either a 24-bit Organizationally Unique
   Identifier (OUI) value administered by the IEEE Registration
   Authority (IEEE-RA) and a 24-bit extension identifier assigned by
   the organization with that OUI assignment, or the concatenation
   of a 36-bit Individual Address Block (IAB) identifier /or 36-bit
   Organizationally Unique Identifier (OUI-36)/ and a 12-bit
   extension identifier assigned by the organization with that IAB
   assignment.

   Additional information can be found on the IEEE RA website:
   http://standards.ieee.org/develop/regauth/tut/eui48.pdf



3.2. EUI-64

   The IEEE-defined 64-bit extended unique identifier (EUI-64) is a
   concatenation of the Organizationally Unique Identifier (OUI)
   value assigned by the IEEE Registration Authority (IEEE RA) and
   the extension identifier assigned by the organization with that
   OUI assignment resulting in a 64-bit unique identifier. The
   extension identifiers shall be 40 bits for the 24-bit OUI-24 and
   28 bits for the 36-bit OUI-36. Other OUI lengths will have
   extension identifiers making up the difference between each
   assigned OUI length and the 64-bit EUI-64.

   Additional information can be found on the IEEE RA website:
   http://standards.ieee.org/develop/regauth/tut/eui48.pdf

3.3. Company ID / Protocol identifier

   IEEE Std 802 provides for the use of Protocol Identifiers in
   conjunction with the SNAP/SAP reserved LLC address. A Protocol
   Identifier is defined as a sequence of five octets. The first



Parsons                 Expires April 9, 2014                  [Page 8]


Internet-Draft        OUI Registry Restructuring         September 2013


   three octets take the values of the three octets of the OUI in
   order; the following two octets are administered by the OUI
   assignee. The hexadecimal representation of the Protocol
   Identifier consists of the hexadecimal values of the five octets
   in order, separated by hyphens, in the order transmitted by the
   network application, left to right.

   Additional information can be found on the IEEE RA website:
   http://standards.ieee.org/develop/regauth/tut/lanman.pdf



4. Preventing exhaustion

   Given the possibility of consuming all the MAC addresses, the
   IEEE RAC places restrictions on their use. For new applications,
   EUI-48 identifiers are restricted to use in low volume
   applications, such as the identification of software interface
   standards or hardware model numbers.

   While the number of EUI-48 identifiers is large, it is not
   inexhaustible, and the IEEE-RAC reviews trends to determine if a
   new strategy is required to prevent exhaustion.  Current usage
   trends and new applications have convinced the RAC that measures
   are needed to more efficiently use the EUI-48 address space.



4.1. IEEE RAC Prime Directive

   A "prime directive" of the IEEE RAC is to not run out of global
   EUI-48 addresses (previously called MAC or MAC-48 addresses) for
   100 years.  The clock started in 1980 when this space was created
   by Xerox (and was called Block ID at the time).

   In about 30 years, less than 20,000 OUIs have been assigned.  So
   if the growth is linear, there is more than 99% of the space
   left, giving the world a 4000 year supply.  However, the growth
   trend from last few years is not linear.  If that trend
   continues, then there is only 26 years left before exhaustion of
   OUIs and global address space they are used to create.  The IEEE
   RAC is studying these trends and has considered several possible
   causes.






Parsons                 Expires April 9, 2014                  [Page 9]


Internet-Draft        OUI Registry Restructuring         September 2013


4.2. New devices

   There has been an increase in new device categories in the last
   several years - including smart phones, tablets and various
   sensors - all that have more than one network interface (e.g.,
   WiFi, Bluetooth, Ethernet) that requires a MAC address.

   In addition, there are a few manufacturers that are volume users.
   That is, they are using more than 32 million MAC (EUI-48)
   addresses per month.

4.3. Assignment efficiencies

   Most manufacturers, however, use far less MAC (EUI-48) addresses
   per month.  They either have a smaller production volume or are
   just starting.  And actually, most OUI customers have only bought
   one OUI.  If they need only MAC addresses, then they could
   benefit from options that would offer them fewer.

   This would reduce the many "lost" or "unused" MAC addresses from
   OUIs that were assigned but the manufacturer did not use the full
   16 million.

4.3.1. MAC (EUI48) Addressing

   ~260 billion EUI-48 (of ~70 trillion possible) addresses have
   been assigned.  While the RAC knows these have not all be used in
   devices, there is no way to confirm this.  The RAC does however,
   require that repeat customers confirm that they have used 95% of
   the addresses before they are assigned another OUI block.

   The RAC requires that only one (or at most a few) global EUI-48
   addresses be assigned to a single hardware device.  This is to
   avoid stockpiling of addresses in devices.  However, this may be
   problematic for some applications like virtualization

4.3.2. Company ID

   In order to get a Protocol identifier or company ID, an OUI must
   be assigned.  If the manufacturer does not intend to use it for
   addressing, then those addresses are lost.

4.4. Virtualization

   Virtualization from the IEEE RAC perspective is essentially the
   usage of global MAC (EUI-48) addresses by software - instead of



Parsons                 Expires April 9, 2014                 [Page 10]


Internet-Draft        OUI Registry Restructuring         September 2013


   by a hardware device (i.e., "burned in") as was originally
   intended.

   Traditionally the RAC limited manufacturers to only a few
   addresses per hardware device to prevent stockpiling addresses in
   devices.  This would invalidate virtualization solutions.  As a
   result, the RAC is now allowing assignment of an OUI (16M EUI-48
   addresses) for virtualization use until a further policy is
   clarified.

   One requirement for virtual machines is that they are mobile and
   can be moved around on a rack, within a data center or even
   across data centers.  Such movement in a multi-vendor environment
   requires a globally unique MAC (EUI48) address to be scalable.

4.4.1. Reusing addresses

   However, another inherent nature of virtualization is the
   creation and destruction of the virtual machine.  Hundreds,
   thousands or millions can be created or destroyed per second in a
   data center.  If kept in a closed environment, this requires a
   local or reusable MAC (EUI48) address.  If a global address is
   used, then they could be used at an alarming rate as they are not
   defined as reusable.

   Unfortunately, there appears to be violation of the IEEE RAC
   policy in the virtualization sector.  That is, some are using
   global MAC (EUI-48) addresses per rack / cluster / data center
   and then reusing them in an adjacent rack / cluster / data
   center.

   Clearly this is not permitted and the RAC has been studying what
   guidance should be given to virtualization vendors such that the
   global MAC address space is not tainted.

   It has been suggested that a DHCP-like mechanism or a standard
   allocation should be developed for reusable MAC addresses such
   that there is some order to assignment in an environment where
   addresses are created and destroyed.

4.4.2. EUI-128 addresses

   Given the potential for using a large number of addresses, the
   RAC is also exploring the feasibility of defining a new "EUI-128"
   identifier (i.e., 128 bits) specifically for future
   virtualization applications.



Parsons                 Expires April 9, 2014                 [Page 11]


Internet-Draft        OUI Registry Restructuring         September 2013




5. Proposed new OUI-based registries

   The IEEE RAC has been studying options to restructure the OUI-
   based registries and products for over a year and is now
   reviewing a final proposal.  This proposal provides a refinement
   of the OUI-based registries improves efficiency of assignment
   allocations and attempts to address virtualization issues.

   While there was some desire for the OUI registries to fully
   separate the semantic of protocol identifier (e.g., the 24 bits
   assigned) and addresses (e.g., a 48-bit address created based on
   the 24 bits assigned), the concern raised was that this was not
   enforceable by definition.

   The IEEE RAC conducted a survey of its customers and it quickly
   became clear that there were first-time customers (and in most
   cases they never made another purchase) and repeat customers
   (many of who were volume users).  It was also very clear that the
   dominant use was to create global MAC (EUI48) addresses.  As a
   result, the assignment decisions could be separated as proposed
   in Figure 3 below.


























Parsons                 Expires April 9, 2014                 [Page 12]


Internet-Draft        OUI Registry Restructuring         September 2013


                    Customer Type            Requirements for IDs
                    '''''''''''''            ''''''''''''''''''''
                                          +------------------------+
                                          |                        |
                                      '''''  Company ID only       |
                                      |   |                        |
                                      |   +------------------------+
                                      |
                                      |   +------------------------+
                                      |   | MAC Addresses and      |
                     +-----------+    |---| other unique IDs only  |
                     |  First-   |    |   |                        |
                     |  time     |____|   +------------------------+
            |''''''''| Customers |    |
            |        |           |    |   +------------------------+
            |        +-----+-----+    |   | Combined Company ID    |
            |                         |...| and MAC Addresses or   |
            |                             | other IDs              |
            |                             +------------------------+
         ,--+--.
       ,'       `.
     ,'           `.
    ;   Customer    :
    |   Decision    |
    :    Tree       ;
     `.           ,'
       `.       ,'
         `-----'                          +------------------------+
            |                             |  MAC Addresses and     |
            |                          |--|  other unique IDs only |
            |        +-----------+     |  |                        |
            |        | Repeat    |     |  +------------------------+
            |        | Customers |     |
            |--------|           ''''''|
                     |           |     |  +------------------------+
                     +-----------+     |  | Combined Company ID    |
                                       |..| and MAC Addresses or   |
                                          | other IDs              |
                                          +------------------------+

   Figure 3: Decision Tree for assignment of Unique IDs/MAC
   addresses

   The proposal that the IEEE RAC is considering is to add an
   additional size option for creating MAC (EUI48) addresses -- 1
   million -- as well as creating a new CompanyID registry.  This is



Parsons                 Expires April 9, 2014                 [Page 13]


Internet-Draft        OUI Registry Restructuring         September 2013


   shown in Table 1 below and described in the following sub-
   sections.

              Table 1: New Proposed OUI-based Product Registries
            +-------------------+------------+-------------------+
            |Manufacturer field |Product     |EUI48(MAC)addresses|
            +-------------------+------------+-------------------+
            | 24-bit identifier |OUI-24/MA-L |16777216           |
            +-------------------+------------+-------------------+
            |-                  |OUI-28/MA-M |1048576            |
            +-------------------+------------+-------------------+
            | 36-bit identifier |OUI-36/MA-S |4096               |
            +-------------------+------------+-------------------+
            | 24-bit identifier |CompanyID   |-                  |
            +-------------------+------------+-------------------+



5.1. OUI-24: MAC Addresses - Large

   The OUI-24 is a 24-bit globally unique assigned number.

   This is the base OUI registry.  It is simply a renaming of the
   existing OUI registry.

   An assignment from this registry includes the ability to create:

   o  24-bit company ID / protocol identifiers

   o  48-bit EUI48 addresses

   o  64-bit EUI64 addresses



5.2. OUI-28: MAC Addresses - Medium

   The OUI-28 is a 28-bit globally unique assigned number.

   This new OUI-28 is created by the IEEE RA by assigning an
   additional 4 bits from an OUI-24 (that would be listed as IEEE
   reserved).

   An assignment from this registry includes the ability to create:

   o  48-bit EUI48 addresses



Parsons                 Expires April 9, 2014                 [Page 14]


Internet-Draft        OUI Registry Restructuring         September 2013


   o  64-bit EUI64 addresses

   Note that the IEEE RAC does not intend to define the usage of a
   28-bit company ID / protocol identifier at this time.

5.3. OUI-36: MAC Addresses - Small

   The OUI-36 is a 36-bit globally unique assigned number.

   The OUI-36 is created by the IEEE RA by assigning an additional
   12 bits from an OUI-24 (that is listed as IEEE reserved).

   This is the existing OUI-36 registry, and it is proposed to merge
   the IAB registry with this as well.

   An assignment from this registry includes the ability to create:

   o  36-bit company ID / protocol identifiers

   o  48-bit EUI48 addresses

   o  64-bit EUI64 addresses

5.4. CompanyID

   The CompanyID is a 24-bit globally unique assigned number.
   However, any MAC addresses created with this Company ID would
   only be locally significant (i.e., the U/L bit is set to 1)

   This new CompanyID is created by the IEEE RA assigning an OUI
   with the X bit set to 1 (this bit becomes the U/L bit when used
   to create a MAC address).  Traditionally, this use has been
   reserved to separate the local and global address spaces but no
   use had been defined for protocol identifiers.  It is proposed
   that only a segment (e.g., the bottom half) of the potential 22-
   bit space be made available for allocation.

   An assignment from this registry includes the ability to create:

   o  24-bit company ID / protocol identifiers

   NOTE:  This requires that legacy uses of the OUI in protocols do
   not try to define the M and X bits for other uses.  The RAC is
   not aware of any standard uses of the M and X bits that would
   prevent defining this new registry.




Parsons                 Expires April 9, 2014                 [Page 15]


Internet-Draft        OUI Registry Restructuring         September 2013


5.4.1. Application Note

   It is further proposed that virtualization manufacturers apply
   for assignments of these CompanyIDs.  These could then be used to
   create MAC (EUI48) addresses in the local space that could be
   reused.  Additionally, it would also provide some order and allow
   for multi-vendor usage of a subset of the local space for the
   virtualization application (or any application that could benefit
   from reusable addresses).



6. Protocol Considerations

   There may be unintended consequences of these additions to the
   OUI-based registries for existing protocols.  A study and review
   of many protocols was conducted and there were no apparent issues
   identified.

   IETF community input is requested, especially as it relates to
   the embedded use or carriage of addresses or protocol identifiers
   in other protocols.  For protocol identifiers, the IEEE RAC would
   be interested if any protocol defines the M and X bits for other
   uses.

7. Security Considerations

   There may be unintended consequences of these additions to the
   OUI-based registries, though none are apparent.

   IETF community input is requested.

8. IANA Considerations

   There may be some affect on the existing IANA registries based on
   the restructuring of the OUI based registries.

   However, this has not yet been studied.

   IETF community input is requested.









Parsons                 Expires April 9, 2014                 [Page 16]


Internet-Draft        OUI Registry Restructuring         September 2013


9. Conclusions

   While the background presented in this document is representative
   of the current situation, the proposals in this document have not
   yet been implemented, and therefore may change.

   The IEEE-SA Board of Governors has made a decision, based on the
   recommendation of the IEEE RAC, on the implementation of the OUI
   registry restructuring.  A summary has been provided in this
   document, but full details are under development by the IEEE RAC.
   It is expected that implementation will start in 2014.

   IETF community input is requested to identify any issues with the
   restructuring proposal, especially as it affects IETF protocols.
   Please provide your comments to the RAC public list with "IETF
   community comment" as the start of the subject field:

   STDS-RAC-PUBLIC@LISTSERV.IEEE.ORG



10. References

10.1.  Normative References

   [1] IEEE Std 802-2001, "IEEE Standard for Local and Metropolitan
   Area Networks: Overview and Architecture"
   https://standards.ieee.org/about/get/802/802.html

10.2. Informative References

   [2] IEEE Registration Authority website
   http://standards.ieee.org/develop/regauth/

   [3] IEEE P802 - Overview & Architecture revision project
   http://www.ieee802.org/1/pages/802-rev.html



11. Acknowledgments

   The IEEE RAC appreciates the cooperation of IETF in publicizing
   these proposals to the IETF community including at its meetings.

   Some of the background material in this document is based on
   information previously available on the IEEE RA website [2].



Parsons                 Expires April 9, 2014                 [Page 17]


Internet-Draft        OUI Registry Restructuring         September 2013




Authors Addresses

   Glenn Parsons
   Ericsson

   Phone: +1-613-963-8141
   Email: glenn.parsons@ericsson.com








































Parsons                 Expires April 9, 2014                 [Page 18]