IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters

Versions: 00 01 02 03 04 05 06 07 08 rfc5342                            
Network Working Group                                Donald Eastlake 3rd
INTERNET-DRAFT                                     Motorola Laboratories
Updates: RFC 2153
Intended Status: Best Current Practice
Expires: February 2008                                       August 2007

                      IANA Ethernet Considerations
                      ---- ------- ---------------

Status of This Document

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   This document is intended to become a Best Current Practice.
   Distribution of this document is unlimited. Comments should be sent
   to the author <Donald.Eastlake@motorola.com> or the IESG

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   Some IETF protocols make use of IEEE 802 frame formats and
   parameters.  This document specifies IANA considerations for code
   points under the IANA OUI (Organizationally Unique Identifier). It
   also lists and discusses other IETF 802 parameters.

D. Eastlake                                                     [Page 1]

INTERNET-DRAFT                              IANA Ethernet Considerations

Table of Contents

      Status of This Document....................................1

      Table of Contents..........................................2

      1. Introduction............................................3
      1.1 Notation in This Document..............................3
      1.2 The IEEE Registration Authority........................3
      1.2.1 The IANA OUI.........................................3

      2. IEEE 802 Address Parameters.............................4
      2.1 EUI-48 MAC Addresses and OUIs..........................4
      2.2. EUI-48 Allocations under the IANA OUI.................4
      2.2.1 EUI-48 IANA Allocation Considerations................5
      2.3 EUI-64 Identifier Allocations..........................6
      2.4 Other IETF Used EUI-48 Addresses.......................7
      2.4.1 Allocation in the 'CF Series'........................7

      3. IEEE 802 Protocol Parameters............................8
      3.1 802 Protocol Allocation Under the IANA OUI.............9
      4. Exhaustion.............................................10

      5. IANA Considerations....................................11
      6. Security Considerations................................11

      7. Normative References...................................12
      8. Informative References.................................12

      Template Annex............................................13
      EUI-48 Identifier or Identifier Block Template............13
      5-octet Ethernet Protocol Identifier Template.............14

      Ethertypes Annex..........................................15
      Some IETF Ethertypes......................................15
      Some IEEE 802 Ethertypes..................................15

      Additional IPR Provisions.................................16

      Author's Address..........................................17
      Expiration and File Name..................................17

D. Eastlake                                                     [Page 2]

INTERNET-DRAFT                              IANA Ethernet Considerations

1. Introduction

   Some IETF protocols make use of Ethernet or other [IEEE] 802 related
   communications frame formats and parameters [IEEE802]. These include
   addresses and protocol identifiers.

   This document specifies IANA considerations for the allocation of
   code points under the IANA OUI. It also lists and discusses other
   IETF use of Ethernet code points not under the IANA OUI.

1.1 Notation in This Document

   This document uses what is called Hexadecimal Notation. Each octet
   (that is, 8-bit byte) is represented by two hexadecimal digits giving
   the value of the octet as an unsigned integer and successive octets
   are separated by a hyphen. This document consistently uses IETF bit
   ordering although, for example, the physical order of bit
   transmission within an octet on an 802.3 link is from the lowest
   order bit to the highest order bit, the reverse.

   In this document:
      "IAB" standards for Individual Address Block, not for Internet
   Architecture Board;
      "MAC" standard for Media Access Control, not for Message
   Authentication Code; and
      "OUI" stands for Organizationally Unique Identifier.

1.2 The IEEE Registration Authority

   Originally the responsibility of Xerox Corporation, the registration
   authority for IEEE 802 parameters is now the IEEE Registration
   Authority, available on the web at
   http://standards.ieee.org/regauth/.  Application may be made to that
   authority for parameters.  Fees and other requirements may apply
   although fees are commonly waived for applications from standards
   development organizations.

   A list of allocated OUIs and IABs and their holders is downloadable
   from the IEEE Registration Authority site.

1.2.1 The IANA OUI

   The OUI 00-00-5E has been allocated to IANA.

D. Eastlake                                                     [Page 3]

INTERNET-DRAFT                              IANA Ethernet Considerations

2. IEEE 802 Address Parameters

   Section 2.1 below discuses EUI-48 MAC addresses, their relationship
   to OUIs, and allocations under the IANA OUI.

2.1 EUI-48 MAC Addresses and OUIs

   IEEE 48-bit MAC "addresses" are the most commonly used Ethernet
   device identifiers and are also called EUI-48 (Extended Unique
   Identifier 48) identifiers. They are structured into an initial 3
   octet OUI (Organizationally Unique Identifier) and an additional 3
   octets of address assigned by the OUI holder. In addition, for
   organizations not requiring 3 octets worth of identifiers, the IEEE
   makes IABs (Individual Address Blocks) where the first 4 1/2 octets
   (36 bits) are allocated giving the holder of the IAB 1 1/2 octets (12
   bits) they can control. [802]

   Two bits within the initial 3 bytes have special significance, the
   Group bit (01-00-00) and the Local bit (02-00-00). OUIs are allocated
   with the Local bit off and the Group bit unspecified.  OUI holders
   may use them to construction multicast addresses by turning on the
   Group bit or unicast addresses by leaving the Group bit zero.

   For globally unique EUI-48 identifiers allocated by an OUI owner, the
   Local bit is zero. If the Local bit is a one, the identifier is
   normally considered a local identifier under the control of the local
   network administrator. The holder of an OUI (or IAB) has no special
   authority over EUI-48 identifiers whose first three (or 4 1/2) octets
   correspond to their OUI (or IAB) if the Local bit on.

2.2. EUI-48 Allocations under the IANA OUI

   The OUI 00-00-5E has been assigned to IANA as described in Section
   1.2.1 above. This includes 2**24 EUI-48 multicast addresses from
   01-00-5E-00-00-00 to 01-00-5E-FF-FF-FF and 2**24 EUI-48 unicast
   addresses from 00-00-5E-00-00-00 to 00-00-5E-FF-FF-FF.

   Of these EUI-48 identifiers, the following allocations have been made
   thus far:

      o  The 2**23 multicast addresses from 01-00-5E-00-00-00 through
         01-00-5E-7F-FF-FF have been allocated form IPv4 multicast

D. Eastlake                                                     [Page 4]

INTERNET-DRAFT                              IANA Ethernet Considerations

      o  The 2**8 unicast addresses from 00-00-5E-00-00-00 through
         00-00-5E-00-00-FF are reserved and require IESG approval for

      o  The 2**8 unicast addresses from 00-00-5E-00-01-00 through
         00-00-5E-00-01-FF have been allocated for the Virtual Router
         Redundancy Protocol (VRRP) [RFC3768].

2.2.1 EUI-48 IANA Allocation Considerations

   IANA EUI-48 allocations under the current or a future IANA OUI (see
   Section 4.) must meeting the following requirements:

      o  must be for standards purposes,

      o  must be for a block of a power of two addresses starting at a
         boundary which is an equal or greater power of two, including
         the allocation of one (2**0) identifier,

      o  are not to be used to evade the requirement for vendors to
         obtain their own block of addresses from the IEEE, and

      o  must be documented in an internet-draft or RFC.

   In addition, Expert or IESG approval must be obtained as listed

      Small allocations of 1, 2, 4, 8, or 16 addresses require the
         approval of any one member of the pool of Experts using the
         procedure specified in Section 5 below.

      Medium sized allocations of 32, 64, 128, or 256 addresses require
         the approval of any two members of the pool of Experts using
         the procedure specified in Section 5 below.

      Allocations of any size, including 512 or more addresses, may be
         made with IESG approval.

   To simplify record keeping, all future allocations of 256 or less
   addresses shall have the Group bit unspecified, that is, shall be
   allocations of parallel equal size blocks of multicast and unicast
   addresses, even if one of these two types is not needed for the
   proposed use. The only exception is that requests for unicast only
   address blocks of any size that are available may be allocated out of
   the remaining addresses in the large unicast range from
   00-00-5E-00-02-00 to 00-00-5E-7F-FF-FF.

D. Eastlake                                                     [Page 5]

INTERNET-DRAFT                              IANA Ethernet Considerations

2.3 EUI-64 Identifier Allocations

   IEEE also defines a system of 64-bit EUIs. Uptake of EUI-64
   identifiers has been limited. They are currently used by the
   following IEEE standards:

   o  IEEE 1394 (also known as FireWire and i.Link),

   o  IEEE 802.15.4 (also known as ZigBee).

   They are also used to form local use some IPv6 addresses ([RFC3513],
   section 2.5.1 and Appendix A).

   Modified EUI-64 identifiers under an OUI are formed by adding a
   5-octet (40-bit) extension as illustrated below for the IANA OUI,
   where aa-bb-cc-dd-ee is the extension.  [RFC4214]


   The first octet is show as 02 rather than 00 because, in Modified
   EUI-64 identifiers, the sense of the local/global bit is inverted
   compared with EUI-48 identifiers.  It is the globally unique values
   (universal scope) under the IANA OUI that have the 02 bit on while
   those with this bit off are locally assigned and out of scope for
   IANA allocation. As with EUI-48 identifiers, the 01 bit on would
   indicate a group address.

   When the first two octets of the extension are FF-FE, the remainder
   of the extension is a 24 bit vendor-supplied ID as follows:


   where yy-yy-yy is the vendor-supplied ID. [[Since "vendor" usually
   means the holder of an OUI, does this mean that a use for which the
   EUI-48 00-00-5E-yy-yy-yy is allocated automatically also has the
   EUI-64 of 02-00-5E-FF-FE-yy-yy-yy?]]

   Certain EUI-64 identifiers under the IANA OUI are reserved for
   holders of IPv4 addresses as follows:


   where xx-xx-xx-xx is a 32-bit IPv4 address.

   [[So, should there be a way for IANA to allocate Modified EUI-64
   addresses of the form 00-00-5E-z1-zz-zz-zz-zz where "z1" is some set
   of octet values less than 0xFE ??]]

D. Eastlake                                                     [Page 6]

INTERNET-DRAFT                              IANA Ethernet Considerations

2.4 Other IETF Used EUI-48 Addresses

   All EUI-48 multicast addresses prefixed "33-33", that is the 2**32
   multicast MAC addresses in the range from 33-33-00-00-00-00 to
   33-33-FF-FF-FF-FF, have been adopted by the IETF for global IPv6
   multicast [RFC2464]. These addresses all have the Group bit (the
   bottom bit of the first byte) on as is required to work properly with
   existing hardware as a multicast address; however, they also have the
   Local bit on; nevertheless, they are used for this global purpose.

   (Historical note: It was the custom during IPv6 design to use "3" for
   example or unknown values and 3333 is the street address number of
   Xerox PARC (Palo Alto Research Center). Ethernet was originally
   designed by Digital Equipment Corporation, Intel Corporation, and
   Xerox Corporation. The early Ethernet protocol has sometimes been
   known as "DIX" Ethernet.)

   All "OUIs" prefixed "CF", that is, "OUIs" from CF-00-00 to CF-FF-FF
   were declared by Information RFC [RFC2153] to be available to
   software vendors when allocated by IANA for use in PPP [RFC1661] or
   for other uses where an IEEE allocation is "inappropriate". These
   "OUIs" have both the Group and Local bits on. The Group bit, or
   "multicast" bit, is meaningless in PPP.  To quote [RFC2153]: "The
   'CF0000' series was arbitrarily chosen to match the PPP NLPID 'CF',
   as a matter of mnemonic convenience."

   "OUI" CF-00-00 is reserved and IANA lists multicast address
   CF-00-00-00-00-00 as used for Ethernet loopback tests.

2.4.1 Allocation in the 'CF Series'

   In over a decade of availability, only a handful of "OUIs" in the 'CF
   Series' has been allocated. (See htto://www.iana.org under both
   Ethernet Parameters and PPP Parameters.) Use of these addresses based
   on IETF allocation is deprecated. IANA is directed not to allocate
   any further "OUIs" in the 'CF Series'.

D. Eastlake                                                     [Page 7]

INTERNET-DRAFT                              IANA Ethernet Considerations

3. IEEE 802 Protocol Parameters

   802 Protocol parameters provide a means of indicating the contents of
   a frame, for example that its contents is IPv4 or IPv6.

   The concept has been extended for the labeling of "tags". A tag in
   this sense is a prefix whose type is identified by an Ethertype and
   which is then followed by another tag or by an Ethertype or LSAPs
   protocol indicator for the the "main" body of the frame, as described
   below. Traditionally in the [802] world, tags are fixed length and do
   not include any encoding of their own length. Thus anything which is
   processing a frame can not, in general, safely process anything in
   the frame past an Ethertype it does not understand. An example is the
   Q-tag [802.1Q] which provides VLAN and priority information for a

   There are two types of protocol identifier parameters that can occur
   in Ethernet frames after the initial EUI-48 destination and source

      Ethertypes: These are 16 bit quantities appearing the an initial
         two octets which, when considered as an unsigned integer, are
         equal to or larger than 0x0600.

      LSAPs: These are 8 bit protocol identifiers which occur in pairs
         immediately after a 16 bit (two octet) remaining frame length
         which, when considered as an unsigned integer, is less than
         0x5DC. LSAPs (Local Subnet Access Points) occur in pairs where
         one is intended to indicate the source protocol and one the
         destination protocol, although thus far no significant use
         where the two are different has been found.

   Neither Ethertypes nor LSAPs are allocated by IANA but by the IEEE
   Registration authority (see Section 1.2 above and the Ethertype Annex
   below). However, both LSAPs and Ethernets have extension mechanisms
   so that they can be used with five byte Ethernet protocol identifiers
   allocated by IANA under the IANA OUI.

   When using the IEEE 802 LLC format (SNAP) [802] for a frame, an OUI
   based protocol identifier can be expressed as follows:
   where xx-xx is the frame length and, as above, must be small enough
   not to be confused with an Ethertype, "AA" is the LSAP which
   indicates this use and is sometimes referred to as the SNAP SAP, "03"
   is the LLC control octet indicating datagram service, yy-yy-yy is an
   OUI, and zz-zz is a protocol number, under that OUI, allocated by the
   OUI owner. The odd five byte length for such OUI based protocol
   identifiers was chose so that, with the LLC control byte ("03"), the
   result is 16 bit aligned.

D. Eastlake                                                     [Page 8]

INTERNET-DRAFT                              IANA Ethernet Considerations

   When using an Ethertype to indicate the main type for a frame body,
   the special "OUI Extended Ethertype" 88-B7 is available. Using this
   Ethertype, a frame body can being with


   where yy-yy-yy, zz-zz, and the five octet combination of y's and z's
   has the same meaning as in the SNAP format described above.

   It is also possible, within the SNAP format, to use an arbitrary
   Ethertype. This is done by putting the Ethertype as the zz-zz field
   about after an all zeros OUI (00-00-00). This would look like


   where zz-zz was the Ethertype.

   (Note that, at this point, the 802 protocol syntax facilities are
   sufficiently powerful that they could be chained indefinitely.
   Whether support for such chaining is generally required is not clear
   but [802] requires support for


   even though this could be more efficiently expressed by simply
   pinching out the "00-00-00-88-B7" in the middle.)

   As well as appearing to label frame contents, 802 Protocol types
   appear within NBMA Next Hop Resolution Protocol [RFC2332] messages
   which has provisions for both two octet Ethertypes and OUI based
   protocol types.

3.1 802 Protocol Allocation Under the IANA OUI

   Two octet protocol numbers under the IANA OUI are available for
   standards use, as in


   A number of such allocations have been made out of the 2**16
   available from 00-00-5E-00-00 to 00-00-5E-FF-FF (see
   http://www.iana.org).  New allocations of a SNAP SAP protocol (zz-zz)
   number under the IANA OUI requires approval of two Experts from the
   pool and using the procedure specified in Section 5 below.

   Such protocol numbers are not to be allocated for any protocol that
   has an Ethertype because that can be expressed in this SNAP SAP
   format by putting an all zeros "OUI" before the Ethertype.

D. Eastlake                                                     [Page 9]

INTERNET-DRAFT                              IANA Ethernet Considerations

4. Exhaustion

   When the available space for either multicast or unicast addresses
   under OUI 00-00-5E have been 90% or more exhausted, IANA should
   request an additional OUI from the IEEE Registration Authority (see
   Section 1.2) for further IANA allocation use.

D. Eastlake                                                    [Page 10]

INTERNET-DRAFT                              IANA Ethernet Considerations

5. IANA Considerations

   The entirety of this document concerns IANA Considerations for the
   allocation of Ethernet parameters.

   The Expert Pool referred to in this document shall consist of all
   voting members of the IAB and IESG.

   While finite, the universe of numbers from which these allocations
   being made is felt to be sufficiently large that the requirements
   given in this document and the Expert's good judgment are considered
   sufficient guidance.

   The procedure for Expert approval is that the applicant completes the
   appropriate Template from the Template Annex below and sends it to
   IANA. The Template includes a suggested Expert or Experts from the
   pool.  IANA contacts one or two of the suggested experts, depending
   on how many approvals are required for the allocation requested, and
   obtains their opinion. If, within 30 days, IANA receives approvals
   from the Expert or Experts and code points are available, IANA will
   make the requested allocation. Otherwise, the application will be

   A wise applicant will have discussed their application in advance
   with the person or persons from the pool that they suggest to IANA as

6. Security Considerations

   This document is concerned with IANA allocation of parameters under
   the IETF OUI and is not directly concerned with security.

D. Eastlake                                                    [Page 11]

INTERNET-DRAFT                              IANA Ethernet Considerations

7. Normative References

   [802] "IEEE Standard for Local and Metropolitan Area Networks:
         Overview and Architecture", IEEE 802-2001, 8 March 2002.
              "IEEE Standard for Local and Metropolitan Area Networks:
         Overview and Architecture / Amendment 1: Ethertypes for
         Prototype and Vendor-Specific Protocol Development", IEEE
         802a-2003, 18 September 2003.

   [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
         RFC 1112, Stanford University, August 1989.

   [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
         Networks", RFC 2464, December 1998.

   [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
         (IPv6) Addressing Architecture", RFC 3513, April 2003.

8. Informative References

   [802.1Q] "IEEE Standard for Local and metropolitan area networks /
         Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006.

   [IEEE] Institute of Electrical and Electronics Engineers

   [IEEE802] IEEE 802 LAN/MAN Standards Committee (Local Area Network /
         Metropolitan Area Network) <http://www.ieee802.org>.

   [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
         RFC 1661, July 1994.

   [RFC2153] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.

   [RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
         Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC
         2332, April 1998.

   [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
         RFC 3768, April 2004.

   [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
         "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC
         4214, October 2005.

D. Eastlake                                                    [Page 12]

INTERNET-DRAFT                              IANA Ethernet Considerations

Template Annex

   This annex provides the specific templates for IANA allocations of
   parameter types specified in this document. Explanatory words in
   parenthesis in the templates below may be deleted in a completed
   template as submitted to IANA.

EUI-48 Identifier or Identifier Block Template

      Applicant Name:

      Applicant Email:

      Applicant Telephone: (starting with country code)

      Use Name: (brief name of Parameter use such as "foo Protocol")

      Document: (ID or RFC specifying use to which the identifier or
      block of identifiers will be put)

      Size of Block requested: (must be a power of two sized block)

      Specify multicast, unicast, or both:

      Suggested Experts (maximum of three) to approve the allocation
      and judge that it meets the criterion in RFC TBD, Section 2.2.1:

D. Eastlake                                                    [Page 13]

INTERNET-DRAFT                              IANA Ethernet Considerations

5-octet Ethernet Protocol Identifier Template

      Applicant Name:

      Applicant Email:

      Applicant Telephone: (starting with country code)

      Use Name: (brief name of Parameter use such as "foo Protocol")

      Document: (ID or RFC specifying use to which the protocol
      identifier will be put)

      Suggested Experts (maximum of three) to approve the allocation
      and judge that it meets the criterion in RFC TBD:

D. Eastlake                                                    [Page 14]

INTERNET-DRAFT                              IANA Ethernet Considerations

Ethertypes Annex

   This annex lists some Ethertypes used for IETF Protocols or by IEEE
   802. See section 3 above.

Some IETF Ethertypes

      0x0800  Internet Protocol Version 4 (IPv4)
      0x0806  Address Resolution Protocol (ARP)
      0x8035  Reverse Address Resolution Protocol (RARP)
      0x86DD  Internet Protocol Version 6 (IPv6)
      0x8847  MPLS unicast
      0x8848  MPLS multicast
      0x8863  PPP over Ethernet (PPPoE) Discovery Stage
      0x8864  PPP over Ethernet (PPPoE) Session Stage

Some IEEE 802 Ethertypes

      0x8100  IEEE Std 802.1Q - Customer VLAN Tag Type (C-Tag,
                                formerly called the Q-Tag)
      0x888e  IEEE Std 802.1X - Port-based network access control
      0x88a8  IEEE Std 802.1Q - Service VLAN tag identifier (S-Tag)
      0x88b5  IEEE Std 802 - Local Experimental Ethertype
      0x88b6  IEEE Std 802 - Local Experimental Ethertype
      0x88b7  IEEE Std 802 - OUI Extended Ethertype
      0x88c7  IEEE Std 802.11i Pre-Authentication
      0x88cc  IEEE Std 802.1AB Link Layer Discovery Protocol (LLDP)
      0x88f6  IEEE Std 802.1Q - Multiple Multicast Registration
                                Protocol (MMRP)

D. Eastlake                                                    [Page 15]

INTERNET-DRAFT                              IANA Ethernet Considerations


   This document and the information contained herein are provided on an

Additional IPR Provisions

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

D. Eastlake                                                    [Page 16]

INTERNET-DRAFT                              IANA Ethernet Considerations

Author's Address

   Donald E. Eastlake 3rd
   Motorola Laboratories
   111 Locke Drive
   Marlborough, MA 01752

   email: Donald.Eastlake@motorola.com

Expiration and File Name

   This draft expires in February 2008.

   Its file name is draft-eastlake-ethernet-iana-considerations-01.txt.

D. Eastlake                                                    [Page 17]