IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters
draft-eastlake-ethernet-iana-considerations-08

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: June 2008                                         December 2007


                      IANA Ethernet Considerations

          <draft-eastlake-ethernet-iana-considerations-05.txt>


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 IETF <ietf@ietf.org> or to the following list:
         Donald.Eastlake@motorola.com,
         Dan Romascanu <dromasca@avaya.com>,
         Erik Nordmark <erik.nordmark@sun.com>,
         Bernard Aboba <aboba@hotmail.com>.

   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/1id-abstracts.html

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


Abstract

   Some IETF protocols make use of Ethernet 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 Ethernet parameters related to IETF
   protocols.




D. Eastlake                                                     [Page 1]


INTERNET-DRAFT                              IANA Ethernet Considerations


Table of Contents

      Status of This Document....................................1
      Abstract...................................................1
      Table of Contents..........................................2

      1. Introduction............................................3
      1.1 Notations Used in This Document........................3
      1.2 The IEEE Registration Authority........................3
      1.2.1 The IANA OUI.........................................4
      1.3 Acknowledgements.......................................4

      2. Ethernet Address Parameters.............................5
      2.1 48-bit MAC Identifiers and OUIs........................5
      2.1.1 EUI-48 Allocations under the IANA OUI................5
      2.1.2 EUI-48 IANA Allocation Considerations................6
      2.2 64-bit MAC Identifiers.................................7
      2.2.1 IPv6 Use of Modified EUI-64 Addresses................7
      2.2.2 EUI-64 IANA Allocation Considerations................8
      2.3 Other IETF Used MAC-48 Addresses.......................9
      2.3.1 Addresses Prefixed 33-33............................10
      2.3.2 The 'CF Series'.....................................10

      3. Ethernet Protocol Parameters...........................11
      3.1 Ethernet Protocol Allocation Under the IANA OUI.......12

      4. Other OUI Based Parameters.............................14

      5. IANA Considerations....................................15
      5.1 The Expert Pool.......................................15
      5.2 OUI Exhaustion........................................15
      6. Security Considerations................................16

      7. Normative References...................................17
      8. Informative References.................................17

      Template Annex............................................19
      EUI-48/EUI-64 Identifier or Identifier Block Template.....19
      5-octet Ethernet Protocol Identifier Template.............20

      Ethertypes Annex..........................................21
      Some Ethertypes Used By The IETF..........................21
      Some IEEE 802 Ethertypes..................................21

      Disclaimer................................................22
      Additional IPR Provisions.................................22
      Author's Address..........................................23
      RFC Editor Note...........................................23
      Expiration and File Name..................................23



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
   identifiers and protocol identifiers.

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



1.1 Notations Used in This Document

   This document uses 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 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" stands for Individual Address Block, not for Internet
           Architecture Board;
      "MAC" stands for Media Access Control, not for Message
           Authentication Code; and
      "OUI" stands for Organizationally Unique Identifier.
      "**" indicates exponentiation. For example, 2**24 is two to the
           twenty-fourth power.



1.2 The IEEE Registration Authority

   Originally the responsibility of Xerox Corporation, the registration
   authority for Ethernet parameters is now the IEEE Registration
   Authority, available on the web at

         http://standards.ieee.org/regauth/

   You may apply to that authority for parameters.  They may impose fees
   or other requirements but they commonly waive fees for applications
   from standards development organizations.

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




D. Eastlake                                                     [Page 3]


INTERNET-DRAFT                              IANA Ethernet Considerations


1.2.1 The IANA OUI

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



1.3 Acknowledgements

   The contributions and support of the following people, listed in
   alphabetic order, is gratefully acknowledged:

      Bernard Aboba, Michelle Cotton, Russ Housley, Erik Nordmark, and
      Dan Romascanu.







































D. Eastlake                                                     [Page 4]


INTERNET-DRAFT                              IANA Ethernet Considerations


2. Ethernet Address Parameters

   Section 2.1 discuses EUI-48 MAC identifiers, their relationship to
   OUIs and IABs, and allocations under the IANA OUI.  Section 2.2
   extends this to EUI-64 identifiers. Section 2.3 discuss other IETF
   MAC identifier use not under the IANA OUI.



2.1 48-bit MAC Identifiers and OUIs

   48-bit MAC "addresses" are the most commonly used Ethernet device
   identifiers and those which are globally unique are also called
   EUI-48 (Extended Unique Identifier 48) identifiers. An EUI-48 is
   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 allocates IABs (Individual Address Blocks)
   where the first 4 1/2 octets (36 bits) are assigned giving the holder
   of the IAB 1 1/2 octets (12 bits) they can control. [802]

   Two bits within the initial 3 octets of an EUI-48 have special
   significance, the Group bit (01-00-00) and the Local bit (02-00-00).
   OUIs and IABs are allocated with the Local bit zero 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
   considered by IEEE 802 to be a local identifier under the control of
   the local network administrator. The holder of an OUI (or IAB) has no
   special authority over 48-bit MAC identifiers whose first three (or 4
   1/2) octets correspond to their OUI (or IAB) if the Local bit on.



2.1.1 EUI-48 Allocations under the IANA OUI

   The OUI 00-00-5E has been assigned to IANA as stated 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 for IPv4 multicast
         [RFC1112].


D. Eastlake                                                     [Page 5]


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
         allocation.

      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.1.2 EUI-48 IANA Allocation Considerations

   Future IANA EUI-48 allocations under the current or a future IANA OUI
   (see Section 5.2) must meet 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
   below:

      Small allocations of a block of 1, 2, 4, 8, or 16 EUI-48
         identifiers require the approval of any one member of the
         Expert Pool using the procedure specified in Section 5.1.

      Medium sized allocations of a block of 32, 64, 128, or 256 EUI-48
         identifiers require the approval of any two members of the
         Expert Pool using the procedure specified in Section 5.1.

      Allocations of any size, including 512 or more EUI-48 identifiers,
         may be made with IESG approval.

   To simplify record keeping, all future allocations of 256 or less
   identifiers 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
   identifier blocks of any size that are available may be allocated out
   of the remaining identifiers in the large unicast range from
   00-00-5E-00-02-00 to 00-00-5E-7F-FF-FF.




D. Eastlake                                                     [Page 6]


INTERNET-DRAFT                              IANA Ethernet Considerations


2.2 64-bit MAC Identifiers

   IEEE also defines a system of 64-MAC identifiers including EUI-64s.
   Uptake of MAC-64 identifiers has been limited. They are currently
   used in constructing certain IPv6 addresses as described below and by
   the following IEEE standards:

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

   o  IEEE 802.15.4 (also known as ZigBee).

   EUI-64 identifiers under an OUI are formed by adding a 5-octet
   (40-bit) extension to a 3-octet (24-bit) OUI.  As with EUI-48
   identifiers, the OUI has the same group/unicast and local/global
   bits.



2.2.1 IPv6 Use of Modified EUI-64 Addresses

   MAC-64 identifiers are also used to form the lower 64 bits of some
   IPv6 addresses ([RFC4291] Section 2.5.1 and Appendix A and
   experimental [RFC4214]).  When so used the MAC-64 is modified by
   inverting the local/global bit to form an IETF "Modified EUI-64".
   Below is an illustration of a Modified EUI-64 under the IANA OUI,
   where aa-bb-cc-dd-ee is the extension.

         02-00-5E-aa-bb-cc-dd-ee

   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) that have the 02 bit on in the first octet while
   those with this bit off are locally assigned and out of scope for
   global allocation.

   The local/global bit was inverted to make it easier for network
   operators to type in local scope identifiers. Thus such Modified
   EUI-64 identifiers as 1, 2, etc.  (ignoring leading zeros), are
   local. Without the modification, they would have to be
   02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc., to be local.

   As with MAC-48 identifiers, the 01 bit on in the first octet
   indicates a group address.

   When the first two octets of the extension of a Modified EUI-64 are
   FF-FE, the remainder of the extension is a 24 bit value as assigned
   by the OUI owner for an EUI-48. For example:

         02-00-5E-FF-FE-yy-yy-yy


D. Eastlake                                                     [Page 7]


INTERNET-DRAFT                              IANA Ethernet Considerations


   or
         03-00-5E-FF-FE-yy-yy-yy

   where yy-yy-yy is the OUI owner (IANA in this case) assigned global
   unicast or multicast address. Thus any holder of one or more EUI-48
   addresses under the IANA OUI also has an equal number of Modified
   EUI-64 addresses which can be formed by inserting FF-FE in the middle
   of their EUI-48 addresses and inverting the local/global bit.

      (Note: [EUI-64] defines FF-FF as the bits to be inserted to create
      an IEEE EUI-64 identifier from a MAC-48 identifier. That document
      says the FF-FE value is used when starting with an EUI-48
      identifier. The IETF uses only FF-FE for the creating of Modified
      EUI-64 identifiers from 48-bit Ethernet station identifiers
      regardless of whether they are EUI-48 or MAC-48 local identifiers.
      EUI-48 and local MAC-48 identifiers are syntactically equivalent,
      and this doesn't cause any problems in practice.)

   In addition, certain Modified EUI-64 identifiers under the IANA OUI
   are reserved for holders of IPv4 addresses as follows:

         02-00-5E-FE-xx-xx-xx-xx

   where xx-xx-xx-xx is a 32-bit IPv4 address. For IPv4 address based
   Modified EUI-64 identifiers, the local/global bit should be set to
   correspond to whether the IPv4 address is local or global. (Keep in
   mind that the sense of the Modified EUI-64 local/global bit is
   reversed from that in (unmodified) MAC-64 identifiers.)



2.2.2 EUI-64 IANA Allocation Considerations

   The following table shows which EUI-64 addresses (in Modified form)
   under the IANA OUI are reserved, used, or available as indicated.

      02-00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF reserved

      02-00-5E-10-00-00-00-00 to 02-00-5E-EF-FF-FF-FF-FF available for
         allocation

      02-00-5E-F0-00-00-00-00 to 02-00-5E-FD-FF-FF-FF-FF reserved

      02-00-5E-FE-00-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF used by IPv4
         address holders as described above

      02-00-5E-FF-00-00-00-00 to 02-00-5E-FF-FD-FF-FF-FF reserved

      02-00-5E-FF-FE-00-00-00 to 02-00-5E-FF-FE-FF-FF-FF used by holders
         of EUI-48 identifiers under the IANA OUI as described above


D. Eastlake                                                     [Page 8]


INTERNET-DRAFT                              IANA Ethernet Considerations


      02-00-5E-FF-FF-00-00-00 to 02-00-5E-FF-FF-FF-FF-FF reserved

   Reserved addresses above require IESG approval for allocation. IANA
   EUI-64 allocations under the IANA OUI for remaining values must meet
   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
   below:

      Small allocations of blocks of 1, 2, 4, 8, 16, 32, 64, 128, or 256
         EUI-64 identifiers require the approval of any one member of
         the Expert Pool using the procedure specified in Section 5.1.

      Medium sized allocations of blocks of 512, 1024, 2048, 4096, 8192,
         16384, 32768, or 65536 EUI-64 identifiers require the approval
         of any two members of the Expert Pool using the procedure
         specified in Section 5.1.

      Allocations of any size, including 131072 or more EUI-64
         identifiers, may be made with IESG approval.

   To simplify record keeping, all allocations of 65536 or less EUI-64
   identifiers 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.



2.3 Other IETF Used MAC-48 Addresses

   There are two other blocks of MAC-48 addresses that are used by the
   IETF as described below.








D. Eastlake                                                     [Page 9]


INTERNET-DRAFT                              IANA Ethernet Considerations


2.3.1 Addresses Prefixed 33-33

   All MAC-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, are used by the IETF for global IPv6 multicast
   [RFC2464].  These addresses all have the Group bit (the bottom bit of
   the first octet) on as is required to work properly with existing
   hardware as a multicast address.  They also have the Local bit on and
   are used for this purpose in IPv6 networks.

      (Historical note: It was the custom during IPv6 design to use "3"
      for unknown or example values and 3333 Coyote Hill Road, Palo
      Alto, California, is the address 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 from
      the first letters of the names of these companies.)



2.3.2 The 'CF Series'

   All "OUIs" prefixed "CF", that is, "OUIs" from CF-00-00 to CF-FF-FF
   were stated in Information RFC [RFC2153] to be available to software
   vendors when allocated by IANA for use in PPP [RFC1661] or for other
   uses where vendors do not otherwise need an IEEE assigned OUI. These
   values 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."

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

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













D. Eastlake                                                    [Page 10]


INTERNET-DRAFT                              IANA Ethernet Considerations


3. Ethernet Protocol Parameters

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

   The concept was extended to labeling by "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 LSAP protocol
   indicator for 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
   C-tag (formerly the Q-tag) [802.1Q]. It provides VLAN and priority
   information for a frame.

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

      Ethertypes: These are 16-bit identifiers appearing as the initial
         two octets after the MAC destination and source 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 an initial 16-bit (two octet) remaining frame
         length which is in turn after the MAC destination and source.
         Such a length must, when considered as an unsigned integer, be
         less than 0x5DC or it could be mistaken as an Ethertype. 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 octet Ethernet protocol
   identifiers under an OUI including those 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:

         xx-xx-AA-AA-03-yy-yy-yy-zz-zz

   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"


D. Eastlake                                                    [Page 11]


INTERNET-DRAFT                              IANA Ethernet Considerations


   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 octet length for such OUI based protocol
   identifiers was chose so that, with the LLC control octet ("03"), the
   result is 16 bit aligned.

   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

         88-B7-yy-yy-yy-zz-zz

   where yy-yy-yy and zz-zz have 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
   after an all zeros OUI (00-00-00). This would look like

         xx-xx-AA-AA-03-00-00-00-zz-zz

   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

         xx-xx-AA-AA-03-00-00-00-88-B7-yy-yy-yy-zz-zz

      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 (Non-Broadcast Multi-Access) Next Hop Resolution
   Protocol [RFC2332] messages.  Such messages have provisions for both
   two octet Ethertypes and OUI based protocol types.



3.1 Ethernet Protocol Allocation Under the IANA OUI

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

         xx-xx-AA-AA-03-00-00-5E-zz-zz

   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).  The extreme values of this range,


D. Eastlake                                                    [Page 12]


INTERNET-DRAFT                              IANA Ethernet Considerations


   00-00-5E-00-00 and 00-00-5E-FF-FF are reserved and require IESG
   approval for allocation.  New allocations of remaining SNAP SAP
   protocol (zz-zz) numbers under the IANA OUI require

   o  documentation in an Internet Draft or RFC and

   o  approval of two Experts Pool members using the procedure specified
      in Section 5.1.

   Such protocol numbers are not to be allocated for any protocol that
   has an Ethertype because that can be expressed by putting an all
   zeros "OUI" before the Ethertype as described above.








































D. Eastlake                                                    [Page 13]


INTERNET-DRAFT                              IANA Ethernet Considerations


4. Other OUI Based Parameters

   Some IEEE 802 and other protocols provide for parameters based on an
   OUI beyond those discussed above.  Such parameters most commonly
   consist of an OUI plus one octet of additional value. They are
   usually called "vendor specific" parameters although "organization
   specific" might be more accurate. They would look like

         yy-yy-yy-zz

   where yy-yy-yy is the OUI and zz is the additional specifier.  An
   example is the Cipher Suite Selector in IEEE 802.11 ([802.11] page
   125).

   Values may be allocated under the IANA OUI for such other-OUI-based-
   parameter usage; however, the first time a value is allocated for a
   particular parameter of this type, the creation of an IANA registry
   is required.  Unless otherwise provided by an IETF Consensus, the
   criteria for the allocation of such values shall be IESG approval.

































D. Eastlake                                                    [Page 14]


INTERNET-DRAFT                              IANA Ethernet Considerations


5. IANA Considerations

   The entirety of this document concerns IANA Considerations for the
   allocation of Ethernet parameters in connection with the IANA OUI and
   related matters.



5.1 The Expert Pool

   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 Expert Pool judged
   allocations will be made is felt to be sufficiently large that the
   requirements given in this document and the Experts' good judgment
   are sufficient guidance.

   The procedure for Expert approval is as follows:

      The applicant completes the appropriate Template from the Template
         Annex below and sends it to IANA <iana@iana.org>.  The Template
         may includes a suggested Expert or Experts (up to three) from
         the pool.

      IANA contacts one or two of the Experts, depending on how many
         approvals are required for the allocation requested, and
         obtains their opinion. If Experts are suggested on the
         Template, IANA will select from those suggestions.

      If, within 28 days, IANA receives approvals from the Expert or
         Experts contacted and code points are available, IANA will make
         the requested allocation. Otherwise, the application will be
         denied.

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



5.2 OUI Exhaustion

   When the available space for either multicast or unicast EUI-48
   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 15]


INTERNET-DRAFT                              IANA Ethernet Considerations


6. Security Considerations

   This document is concerned with allocation of parameters under the
   IANA OUI and closely related matters. It is not directly concerned
   with security.















































D. Eastlake                                                    [Page 16]


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.



8. Informative References

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

   [802.11] "IEEE Standard for Information technology /
         Telecommunications and information exchange between systems /
         Local and metropolitan area networks / Specific requirements /
         Part 11: Wireless LAN Medium Access Control (MAC) and Physical
         Layer (PHY) Specifications", IEEE 802.11-2007, 11 June 2007.

   [EUI-64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
         Registration Authority",
         http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
         March 1997.

   [IEEE] Institute of Electrical and Electronics Engineers
         <http://www.ieee.org>.

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

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

   [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.

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



D. Eastlake                                                    [Page 17]


INTERNET-DRAFT                              IANA Ethernet Considerations


   [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.

   [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 4291, February 2006.











































D. Eastlake                                                    [Page 18]


INTERNET-DRAFT                              IANA Ethernet Considerations


Template Annex

   This annex provides the specific templates for IANA allocations of
   parameters and parameter blocks specified in this document as
   allocated based on Expert Approval. No specific template is used for
   those parameters or parameter blocks that require IESG approval.
   Explanatory words in parenthesis in the templates below may be
   deleted in a completed template as submitted to IANA.





EUI-48/EUI-64 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)


      Specify whether this is an application for EUI-48 or EUI-64
      identifiers:


      Size of Block requested: (must be a power of two sized block,
      can be a block of size one (2**0))


      Specify multicast, unicast, or both:


      Suggested Experts (optional, maximum of three IAB/IESG voting
      members) to approve the allocation if they judge that it meets
      the criterion in RFC <TBD> (section 2) and they support it:







D. Eastlake                                                    [Page 19]


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 (optional, maximum of three IAB/IESG voting
      members) to approve the allocation if they judge that it meets
      the criterion in RFC <TBD> (section 3.1) and they support it:































D. Eastlake                                                    [Page 20]


INTERNET-DRAFT                              IANA Ethernet Considerations


Ethertypes Annex

   This annex lists some Ethertypes used for IETF Protocols or by IEEE
   802 as known to the author at the time of publication. A more up-to-
   date list will generally be available on the IANA web site, currently
   at <http://www.iana.org/assignments/ethernet-numbers>.  See Section 3
   above.



Some Ethertypes Used By The IETF

      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)
      0x88E5  IEEE Std 802.1AE -  Media Access Control Security
      0x88F5  IEEE Std 802.1ak - Multiple VLAN Registtration Protocol
                                 (MVRP)
      0x88F6  IEEE Std 802.1Q - Multiple Multicast Registration
                                Protocol (MMRP)
      0x890D  IEEE 802.11r - Fast Roaming Remote Request












D. Eastlake                                                    [Page 21]


INTERNET-DRAFT                              IANA Ethernet Considerations


Disclaimer

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



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
   http://www.ietf.org/ipr.

   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-
   ipr@ietf.org.

   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 22]


INTERNET-DRAFT                              IANA Ethernet Considerations


Author's Address

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

   tel:  +1-508-786-7554
   email: Donald.Eastlake@motorola.com



RFC Editor Note
   Note that when an RFC number is assigned to this draft, it should
   also replace two occurances of "<TBD>" in the Template Annex above.
   This note should be deleted before publication.



Expiration and File Name

   This draft expires in June 2008.

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




























D. Eastlake                                                    [Page 23]