Skip to main content

IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters
draft-eastlake-rfc5342bis-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7042.
Authors Donald E. Eastlake 3rd , Joe Abley
Last updated 2013-06-13 (Latest revision 2013-06-07)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources
Stream WG state (None)
Document shepherd Joel Jaeggli
Shepherd write-up Show Last changed 2013-05-06
IESG IESG state Became RFC 7042 (Best Current Practice)
Consensus boilerplate Yes
Telechat date (None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Responsible AD Joel Jaeggli
Send notices to joe.abley@icann.org, d3e3e3@gmail.com, draft-eastlake-rfc5342bis@tools.ietf.org
IANA IANA review state IANA OK - Actions Needed
draft-eastlake-rfc5342bis-03
Network Working Group                                    Donald Eastlake
INTERNET-DRAFT                                                    Huawei
Intended status: Best Current Practice                         Joe Abley
Obsoletes: 5342                                                    ICANN
Updates: 2153
Expires: December 6, 2013                                   June 7, 2013

     IANA Considerations and IETF Protocol and Documentation Usage
                        for IEEE 802 Parameters
                   <draft-eastlake-rfc5342bis-03.txt>

Abstract

   Some IETF protocols make use of Ethernet frame formats and IEEE 802
   parameters.  This document discusses some use of such parameters in
   IETF protocols, specifies IANA considerations for assignment of
   points under the IANA OUI (Organizationally Unique Identifier),
   provides some values for use in documentation, and obsoletes RFC
   5342.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Distribution of this document is unlimited. Comments should be sent
   to the authors.

   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.

D. Eastlake and J. Abley                                        [Page 1]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

Table of Contents

      1. Introduction............................................3
      1.1 Changes from RFC 5342..................................3
      1.2 Notations Used in This Document........................3
      1.3 The IEEE Registration Authority........................4
      1.4 The IANA OUI...........................................4

      2. Ethernet Identifier Parameters..........................5
      2.1 48-Bit MAC Identifiers, OUIs, and IABs.................5
      2.1.1 EUI-48 Assignments under the IANA OUI................5
      2.1.2 EUI-48 Documentation Values..........................6
      2.1.3 EUI-48 IANA Assignment Considerations................7
      2.2 64-Bit MAC Identifiers.................................7
      2.2.1 IPv6 Use of Modified EUI-64 Identifiers..............8
      2.2.2 EUI-64 IANA Assignment Considerations................9
      2.2.3 EUI-64 Documentation Values.........................10
      2.3 Other MAC-48 Identifiers Used by IETF.................11
      2.3.1 Identifiers Prefixed 33-33..........................11
      2.3.2 The 'CF Series'.....................................12
      2.3.2.1 Changes to RFC 2153...............................12

      3. Ethernet Protocol Parameters...........................13
      3.1 Ethernet Protocol Assignment under the IANA OUI.......14
      3.2 Documentation Protocol Number.........................15

      4. Other OUI-Based Parameters.............................16

      5. IANA Considerations....................................17
      5.1 Expert Review and IESG Ratification...................17
      5.2 MAC Address AFNs and RRTYPEs..........................18
      5.3 Informational IANA Web Page Material..................19
      5.4 OUI Exhaustion........................................19
      5.5 IANA OUI MAC Address Table............................19
      5.6 SNAP Protocol Number Table and Assignment.............19

      6. Security Considerations................................20
      Acknowledgements..........................................20
      Normative References......................................21
      Informative References....................................21

      Appendix A. Templates.....................................24
      A.1 EUI-48/EUI-64 Identifier or Identifier Block Template.24
      A.2 IANA OUI Based Protocol Number Template...............24
      A.3 Other IANA OUI-Based Parameter Template...............25

      Appendix B. Ethertypes....................................26
      B.1 Some Ethertypes Specified by the IETF.................26
      B.2 Some IEEE 802 Ethertypes..............................26

      Appendix C: Documentation Protocol Number.................28

D. Eastlake and J. Abley                                        [Page 2]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

1. Introduction

   Some IETF protocols use Ethernet or other [IEEE] 802 related
   communication frame formats and parameters [IEEE802].  These include
   MAC (Media Access Control) identifiers and protocol identifiers.

   This document specifies IANA considerations for the assignment of
   code points under the IANA OUI.  It also discusses some other IETF
   use of IEEE 802 code points and provides some values for use in
   documentation. As noted in [RFC2606] and [RFC5737], the use of
   designated code values reserved for documentation and examples
   reduces the likelihood of conflicts and confusion arising from their
   duplication of code points assigned for some deployed use.

   [RFC5226] is incorporated herein except where there are contrary
   provisions in this document. In this document "IESG Ratification" is
   used in some cases and it is specified in Section 5.1. This is not
   the same as "IESG Approval" in [RFC5226].

1.1 Changes from RFC 5342

   Add MAC addresses and IANA OUI-based protocol and other values for
   use in documentation and add relevant Security Considerations
   language.

   Eliminate any requirements for parallel unicast and multicast
   assignment unless requested. Such requirements had been included in
   [RFC5342] on the theory they would make bookkeeping easier for IANA
   but have proved to be problematic in practice.

   Add AFNs and RRTYPEs for 48-bit and 64-bit MACs.

1.2 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.  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 IEEE
   [802.3] link is from the lowest order bit to the highest order bit
   (i.e., the reverse of the IETF's ordering).

   In this document:

   "AFN" stands for Address Family Number [RFC4760].

D. Eastlake and J. Abley                                        [Page 3]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

   "EUI" stands for Extended Unique Identifier.

   "IAB" stands for Individual Address Block, not for Internet
         Architecture Board.

   "MAC" stands for Media Access Control, not for Message Authentication
         Code.

   "OUI" stands for Organizationally Unique Identifier.

   "RRTYPE" stands for a DNS Resource Record type [RFC6895].

   "**"  indicates exponentiation.  For example, 2**24 is two to the
         twenty-fourth power.

1.3 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/

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

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

1.4 The IANA OUI

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

   There is no OUI value reserved at this time for documentation but
   there are documentation code points under the IANA OUI specified
   below.

D. Eastlake and J. Abley                                        [Page 4]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

2. Ethernet Identifier Parameters

   Section 2.1 discusses EUI-48 (Extended Unique Identifier 48) MAC
   identifiers, their relationship to OUIs and IABs, and assignments
   under the IANA OUI.  Section 2.2 extends this to EUI-64 identifiers.
   Section 2.3 discusses other IETF MAC identifier use not under the
   IANA OUI.

2.1 48-Bit MAC Identifiers, OUIs, and IABs

   48-bit MAC "addresses" are the most commonly used Ethernet interface
   identifiers.  Those that are globally unique are also called EUI-48
   identifiers.  An EUI-48 is structured into an initial 3-octet OUI
   (Organizationally Unique Identifier) and an additional 3 octets
   assigned by the OUI holder.  For organizations not requiring 3
   octets' worth of identifiers, the IEEE assigns IABs (Individual
   Address Blocks) instead, 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.

   The IEEE describes its assignment procedures and policies for IEEE
   802 related identifiers in [802_O&A].

   Two bits within the initial octet of an EUI-48 have special
   significance: the Group bit (01) and the Local bit (02).  OUIs and
   IABs are assigned with the Local bit zero and the Group bit
   unspecified.  Multicast identifiers may be constructed by turning on
   the Group bit, and unicast identifiers constructed by leaving the
   Group bit zero.

   For globally unique EUI-48 identifiers assigned by an OUI or IAB
   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.  If the Local bit is
   on, the holder of an OUI (or IAB) has no special authority over MAC
   identifiers whose first 3 (or 4 1/2) octets correspond to their OUI
   (or IAB).

   An AFN and a DNS RRTYPE have been assigned for 48-bit MAC addresses
   (see Section 5.2).

2.1.1 EUI-48 Assignments under the IANA OUI

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

D. Eastlake and J. Abley                                        [Page 5]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

   identifiers from 00-00-5E-00-00-00 to 00-00-5E-FF-FF-FF.

   Of these EUI-48 identifiers, the sub-blocks reserved or thus far
   assigned by IANA those for purposes of documentation, are as follows:

   Unicast, all blocks of 2**8 addresses thus far:

      00-00-5E-00-00-00 through 00-00-5E-00-00-FF: reserved and require
            IESG Ratification for assignment (see Section 5.1).

      00-00-5E-00-01-00 through 00-00-5E-00-01-FF: assigned for the
            Virtual Router Redundancy Protocol (VRRP) [RFC5798].

      00-00-5E-00-02-00 through 00-00-5E-00-02-FF: assigned for the IPv6
            Virtual Router Redundancy Protocol (VRRP IPv6) [RFC5798].

      00-00-5E-00-52-00 through 00-00-5E-00-52-FF: being used for very
            small assignments. Currently 3 out of these 256 values have
            been assigned.

      00-00-5E-00-53-00 through 00-00-5E-00-53-FF: assigned for use in
            documentation.

   Multicast:

      01-00-5E-00-00-00 through 01-00-5E-7F-FF-FF: 2**23 addresses
            assigned for IPv4 multicast [RFC1112].

      01-00-5E-80-00-00 through 01-00-5E-8F-FF-FF: 2**20 addresses
            assigned for MPLS multicast [RFC5332].

      01-00-5E-90-00-00 through 01-00-5E-90-00-FF: 2**8 addresses being
            used for very small assignments. Currently 4 out of these
            256 values have been assigned.

      01-00-5E-90-10-00 through 01-00-5E-90-10-FF: 2**8 addresses for
            use in documentation.

   For more detailed and up-to-date information, see the Ethernet Number
   registry at http://www.iana.org.

2.1.2 EUI-48 Documentation Values

   The following values have been assigned for use in documentation:

      00-00-5E-00-53-00 through 00-00-5E-00-53-FF for unicast and

      01-00-5E-90-10-00 through 01-00-5E-90-10-FF for multicast.

D. Eastlake and J. Abley                                        [Page 6]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

2.1.3 EUI-48 IANA Assignment Considerations

   EUI-48 assignments under the current or a future IANA OUI (see
   Section 5.4) must meet the following requirements:

      o  must be for standards purposes (either for an IETF Standard or
         other standard related to IETF work),

      o  must be for a block of a power-of-two identifiers starting at a
         boundary that is an equal or greater power of two, including
         the assignment of one (2**0) identifier,

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

      o  must be documented in an Internet-Draft or RFC.

   In addition, approval must be obtained as follows (see the procedure
   in Section 5.1):

      Small to medium assignments of a block of 1, 2, 4, ..., 32768,
         65536 (2**0, 2**1, 2**2, ..., 2**15, 2**16) EUI-48 identifiers
         require Expert Review.

      Large assignments of 131072 (2**17) or more EUI-48 identifiers
         require IESG Ratification (see Section 5.1).

   ([RFC5342] had a requirement for parallel unicast and multicast
   assignments under some circumstances even when both types were not
   applied for. That requirement has proven impractical and is
   eliminated in this document.)

2.2 64-Bit MAC Identifiers

   IEEE also defines a system of 64-bit MAC identifiers including
   EUI-64s.  Uptake of these "MAC-64" identifiers has been limited.
   They are currently used in a modified form to construct some IPv6
   Interface Identifiers 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).

   Adding a 5-octet (40-bit) extension to a 3-octet (24-bit) OUI or a 3
   1/2 octet (28-bit) extension to a 4 1/2 octet (36-bit) IAB forms an
   EUI-64 identifier under that OUI or IAB. (IABs are discussed in
   Section 2.1.)  As with EUI-48 identifiers, the first octet has the

D. Eastlake and J. Abley                                        [Page 7]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

   same Group and Local bits.

   An AFN and a DNS RRTYPE have been assigned for 64-bit MAC addresses
   (see Section 5.2).

   The discussion below is almost entirely in terms of the "Modified"
   form of EUI-64 identifiers; however, anyone assigned such an
   identifier can also use the unmodified form as a MAC identifier on
   any link that uses such 64-bit identifiers for interfaces.

2.2.1 IPv6 Use of Modified EUI-64 Identifiers

   MAC-64 identifiers are used to form the lower 64 bits of some IPv6
   addresses (Section 2.5.1 and Appendix A of [RFC4291] and Appendix A
   of [RFC5214]).  When so used, the MAC-64 is modified by inverting the
   Local/Global bit to form an IETF "Modified EUI-64 identifier".  Below
   is an illustration of a Modified EUI-64 unicast identifier 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 shown 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 assignment.

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

   When the first two octets of the extension of a Modified EUI-64
   identifier 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
   or
         03-00-5E-FF-FE-yy-yy-yy

   where yy-yy-yy is the portion (of an EUI-48 global unicast or
   multicast identifier) that is assigned by the OUI owner (IANA in this
   case).  Thus, any holder of one or more EUI-48 identifiers under the

D. Eastlake and J. Abley                                        [Page 8]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

   IANA OUI also has an equal number of Modified EUI-64 identifiers that
   can be formed by inserting FF-FE in the middle of their EUI-48
   identifiers 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 to create 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. The owner of an IPv4
   address has both the unicast and multicast derived EUI-64 bit
   address.  Modified EUI-64 identifiers from

         02-00-5E-FE-F0-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF

   are effectively reserved pending the specification of IPv4 Class E
   addresses.  However, for Modified EUI-64 identifiers based on an IPv4
   address, 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 identifier Local/Global bit is reversed from that
   in (unmodified) MAC-64 identifiers.)

2.2.2 EUI-64 IANA Assignment Considerations

   The following table shows which Modified EUI-64 identifiers under the
   IANA OUI are reserved, assigned, or available as indicated. As noted
   above, the corresponding MAC addresses can be determined by
   complementing the 02 bit in the first octet.  In all cases, the
   corresponding multicast 64-bit MAC addresses formed by complementing
   the 01 bit in the first octet have the same status as the modified
   64-bit unicast address blocks listed below.

      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-10-00-00-00-FF assigned for
            documentation use

      02-00-5E-EF-10-00-00-00 to 02-00-5E-EF-FF-FF-FF-FF, which is
            available for assignment

D. Eastlake and J. Abley                                        [Page 9]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

      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 assigned to
            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 assigned for
            holders of EUI-48 identifiers under the IANA OUI as
            described above

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

   The reserved identifiers above require IESG Ratification (see Section
   5.1) for assignment.  IANA EUI-64 identifier assignments under the
   IANA OUI must meet the following requirements:

      o  must be for standards purposes (either for an IETF Standard or
         other standard related to IETF work),

      o  must be for a block of a power-of-two identifiers starting at a
         boundary that is an equal or greater power of two, including
         the assignment of one (2**0) identifier,

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

      o  must be documented in an Internet Draft or RFC.

   In addition, approval must be obtained as follows (see the procedure
   in Section 5.1):

      Small to medium assignments of a block of 1, 2, 4, ..., 134217728,
         268435456 (2**0, 2**1, 2**2, ..., 2**27, 2**28) EUI-64
         identifiers require Expert Review.

      Assignments of any size, including 536870912 (2**29) or more
         EUI-64 identifiers, may be made with IESG Ratification (see
         Section 5.1).

2.2.3 EUI-64 Documentation Values

   The following blocks of unmodified 64-bit MAC addresses are for
   documentation use. The IPv4 derived addresses are based on the IPv4
   documentation addresses [RFC5737] and the MAC derived addresses are
   based on the EUI-48 documentation addresses above.

   Unicast:

D. Eastlake and J. Abley                                       [Page 10]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

      00-00-5E-EF-10-00-00-00 to 00-00-5E-EF-10-00-00-FF general

      00-00-5E-FE-C0-00-02-00 to 00-00-5E-FE-C0-00-02-FF and
      00-00-5E-FE-C6-33-64-00 to 00-00-5E-FE-C6-33-64-FF and
      00-00-5E-FE-CB-00-71-00 to 00-00-5E-FE-CB-00-71-FF IPv4 derived

      00-00-5E-FF-FE-00-53-00 to 00-00-5E-FF-FE-00-53-FF EUI-48 derived

      00-00-5E-FE-EA-C0-00-02 and
      00-00-5E-FE-EA-C6-33-64 and
      00-00-5E-FE-EA-CB-00-71 IPv4 multicast derived from IPv4 unicast
         [RFC6034]

   Multicast:

      01-00-5E-EF-10-00-00-00 to 01-00-5E-EF-10-00-00-FF general

      01-00-5E-FE-C0-00-02-00 to 01-00-5E-FE-C0-00-02-FF and
      01-00-5E-FE-C6-33-64-00 to 01-00-5E-FE-C6-33-64-FF and
      01-00-5E-FE-CB-00-71-00 to 01-00-5E-FE-CB-00-71-FF IPv4 derived

      01-00-5E-FE-EA-C0-00-02 and
      01-00-5E-FE-EA-C6-33-64 and
      01-00-5E-FE-EA-CB-00-71 IPv4 multicast derived from IPv4 unicast
         [RFC6034]

      01-00-5E-FF-FE-90-10-00 to 01-00-5E-FF-FE-90-10-FF EUI-48 derived

2.3 Other MAC-48 Identifiers Used by IETF

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

2.3.1 Identifiers Prefixed 33-33

   All MAC-48 multicast identifiers prefixed "33-33" (that is, the 2**32
   multicast MAC identifiers 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].  In all these identifiers, the Group bit (the bottom bit
   of the first octet) is on, as is required to work properly with
   existing hardware as a multicast identifier.  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 PARC (Palo Alto Research

D. Eastlake and J. Abley                                       [Page 11]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

      Center, formerly "Xerox PARC").  Ethernet was originally specified
      by Digital Equipment Corporation, Intel Corporation, and Xerox
      Corporation.  The pre IEEE [802.3] 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'

   The Informational [RFC2153] declared the 3-octet values from CF-00-00
   through CF-FF-FF to be OUIs available for assignment by IANA to
   software vendors for use in PPP [RFC1661] or for other uses where
   vendors do not otherwise need an IEEE-assigned OUI.  It should be
   noted that, when used as MAC-48 prefixes, these values have the Local
   and Group bits on, while all IEEE-assigned OUIs thus far have those
   bits off.  The Group 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 identifier
         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' have been assigned.  (See http://www.iana.org under both
   Ethernet Parameters and PPP Parameters.)

2.3.2.1 Changes to RFC 2153

   The IANA Considerations in [RFC2153] are updated as follows (no
   technical changes are made): Use of these identifiers based on IANA
   assignment is deprecated.  IANA is directed not to assign any further
   values in the 'CF Series'.

D. Eastlake and J. Abley                                       [Page 12]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

3. Ethernet Protocol Parameters

   Ethernet protocol parameters provide a means of indicating the
   contents of a frame -- for example, that its contents are IPv4 or
   IPv6.

   The concept has been extended to labeling by "tags".  A tag in this
   sense is a prefix whose type is identified by an Ethertype that is
   then followed by either another tag, an Ethertype, or an LSAP
   protocol indicator for the "main" body of the frame, as described
   below.  Traditionally in the [802_O&A] world, tags are fixed length
   and do not include any encoding of their own length.  Any device that
   is processing a frame cannot, 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 customer 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 (or after a
         tag) which, when considered as an unsigned integer, are equal
         to or larger than 0x0600.

      LSAPs: These are 8-bit protocol identifiers that occur in pairs
         immediately after an initial 16-bit (two octet) remaining frame
         length, which is in turn after the MAC destination and source
         (or after a tag).  Such a length must, when considered as an
         unsigned integer, be less than 0x5DC or it could be mistaken as
         an Ethertype.  LSAPs (Link-Layer Subnet Access Points) occur in
         pairs where one is intended to indicate the source protocol
         handler and one the destination protocol handler; however, use
         cases where the two are different have been relatively rare.

   Neither Ethertypes nor LSAPs are assigned by IANA; they are assigned
   by the IEEE Registration Authority (see Section 1.3 above and the
   Ethertype Annex below).  However, both LSAPs and Ethertypes have
   extension mechanisms so that they can be used with five-octet
   Ethernet protocol identifiers under an OUI, including those assigned
   by IANA under the IANA OUI.

   When using the IEEE 802 LLC format (SNAP) [802_O&A] 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 that indicates

D. Eastlake and J. Abley                                       [Page 13]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

   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, assigned by the OUI
   owner.  The odd five-octet length for such OUI-based protocol
   identifiers was chosen 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 begin 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.  Putting the Ethertype as the zz-zz field after an all
   zeros OUI (00-00-00) does this.  It looks like

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

   where zz-zz is 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_O&A] requires support for

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

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

   As well as labeling 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 Assignment under the IANA OUI

   Two-octet protocol numbers under the IANA OUI are available, as in

         xx-xx-AA-AA-03-00-00-5E-qq-qq

   where qq-qq is the protocol number.

   A number of such assignments have been made out of the 2**16 protocol

D. Eastlake and J. Abley                                       [Page 14]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

   numbers available from 00-00-5E-00-00 to 00-00-5E-FF-FF (see [IANA]).
   The extreme values of this range, 00-00-5E-00-00 and 00-00-5E-FF-FF,
   are reserved and require IESG Ratification for assignment (see
   Section 5.1).  New assignments of SNAP SAP protocol (qq-qq) numbers
   under the IANA OUI must meet the following requirements:

      o  the assignment must be for standards use (either for an IETF
         Standard or other standard related to IETF work),

      o  it must be documented in an Internet-Draft or RFC, and

      o  such protocol numbers are not to be assigned for any protocol
         that has an Ethertype (because that can be expressed by putting
         an all zeros "OUI" before the Ethertype as described above).

   In addition, the Expert Review (or IESG Ratification for the two
   reserved values) must be obtained using the procedure specified in
   Section 5.1.

3.2 Documentation Protocol Number

   00-42 is a protocol number under the IANA OUI (that is,
   00-00-0E-00-42) to be used for documentation purposes.

D. Eastlake and J. Abley                                       [Page 15]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

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

   Values may be assigned under the IANA OUI for such other OUI-based
   parameter usage by Expert Review except that, for each use, the
   additional specifier values consisting of all zero bits and all one
   bits (0x00 (00-00-5E-00) and 0xFF (00-00-5E-FF) for a one-octet
   specifier) are reserved and require IESG Ratification (see Section
   5.1) for assignment; also, the additional specifier value 0x42
   (00-00-5E-42) is assigned for use in documentation.

   Assignments of such other IANA OUI-based parameters must be for
   standards use (either for an IETF Standard or other standard related
   to IETF work) and be documented in an Internet-Draft or RFC.  The
   first time a value is assigned for a particular parameter of this
   type, an IANA registry will be created to contain that assignment and
   any subsequent assignments of values for that parameter under the
   IANA OUI.  The Expert will specify the name of the registry.

   If different policies from those above are required for such a
   parameter, a BCP or Standards Track RFC must be adopted updating this
   BCP and specifying the new policy and parameter.

D. Eastlake and J. Abley                                       [Page 16]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

5. IANA Considerations

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

   As this document replaces [RFC5342], references to [RFC5342] in IANA
   registries should be replaced by references to this document. In
   addition, any references in the registries to draft-jabley-
   eui48-eui64-doc-addr, which has been combined into this document,
   should be replaced with references to this document.

   This document does not create any new IANA registries.

   This document assigns MAC address values for documentation but those
   values are already in the appropriate IANA tables due to draft-
   jabley-eui48-eui64-doc-addr. The only other assignment made by this
   document is a protocol number for documentation in Section 5.6.

   No existing assignment is changed by this document.

5.1 Expert Review and IESG Ratification

   This section specifies the procedure for Expert Review and IESG
   Ratification of MAC, protocol, and other IANA OUI-based identifiers.
   The Expert(s) referred to in this document shall consist of one or
   more persons appointed by and serving at the pleasure of the IESG.
   The procedure described for Expert Review assignments in this
   document is fully consistent with the IANA Expert Review policy
   described in Section 4.1 of [RFC5226].

   While finite, the universe of code points from which Expert judged
   assignments will be made is felt to be large enough that the
   requirements given in this document and the Experts' good judgment
   are sufficient guidance.  The idea is for the Expert to provide a
   light sanity check for small assignments of EUI identifiers with
   increased scrutiny by the Expert for medium-sized assignments of EUI
   identifiers, and assignments of protocol identifiers and other IANA
   OUI based parameters.  However, it can make sense to assign very
   large portions of the MAC identifier code point space.  (Note that
   existing assignments include one for 1/2 of the entire multicast IANA
   EUI-48 code point space and one for 1/16 of that multicast code point
   space.)  In those cases, and in cases of the assignment of "reserved"
   values, IESG Ratification of an Expert Review approval recommendation
   is required as described below.  The procedure is as follows:

      The applicant always completes the appropriate Template from the
         Template Annex below and sends it to IANA <iana@iana.org>.

D. Eastlake and J. Abley                                       [Page 17]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

      IANA always sends the Template to an appointed Expert.  If the
         Expert recuses themselves or is non-responsive, IANA may choose
         an alternative appointed Expert or, if none are available, will
         contact the IESG.

      In all case, if IANA receives a disapproval from an Expert
         selected to review an application Template, the application
         will be denied.

      If the assignment is based on Expert Review:

            If IANA receives approval and code points are available,
            IANA will make the requested assignment.

      If the assignment is based on IESG Ratification:

            The procedure starts with the first steps above for Expert
            Review. If the Expert disapproves the application, they
            simply inform IANA; however, if the Expert believes the
            application should be approved, or is uncertain and believes
            that the circumstances warrant the attention of the IESG,
            the Expert will inform IANA about their advice and IANA will
            forward the application, together with the reasons for
            approval or uncertainty, to the IESG.  The IESG must decide
            whether the assignment will be granted.  This can be
            accomplished by a management item in an IESG telechat as
            done for other types of requests.  If the IESG decides not
            to ratify a favorable opinion by the Expert or decides
            against an application where the Expert is uncertain, the
            application is denied, otherwise it is granted.  The IESG
            will communicate its decision to the Expert and to IANA.

5.2 MAC Address AFNs and RRTYPEs

   IANA has assigned AFNs for MAC addresses as follows:

            AFN         Decimal      Hex
         ----------     -------     ------
         48-bit MAC      16389      0x4005
         64-bit MAC      16390      0x4006

   IANA has assigned DNS RRTYPEs [RFC6895] for MAC addresses as follows:

                                   RRTYPE Code
            Data       Menmonic   Decimal   Hex
         ----------    --------   -------  ------
         48-bit MAC     EUI48       108    0x006C
         64-bit MAC     EUI64       109    0x006D

D. Eastlake and J. Abley                                       [Page 18]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

5.3 Informational IANA Web Page Material

   IANA also maintains an informational listing on its web site
   concerning Ethertypes, OUIs, and multicast addresses assigned under
   OUIs other than the IANA OUI.  The title of this information registry
   is "IEEE 802 Numbers". IANA shall update that list when changes are
   provided by the Expert.

5.4 OUI Exhaustion

   When the available space for either multicast or unicast EUI-48
   identifiers under OUI 00-00-5E have been 90% or more exhausted, IANA
   should request an additional OUI from the IEEE Registration Authority
   for further IANA assignment use. The appointed Expert(s) should
   monitor for this condition and notify IANA.

   The preceding paragraph should be included in the IANA Registry as a
   Note.

5.5 IANA OUI MAC Address Table

   No changes are required in the "IANA Unicast 48-bit MAC Addresses"
   and "IANA Multicast 48-bit MAC Addresses" tables except for the
   updates to references specified in the first part of Section 5.

   The Note preceeding the "IANA 64-bit MAC Addresses" table should be
   as follows:

      "These values are prefixed with 00-00-0E to form unicast MAC
      addresses, with 01-00-0E to form multicast MAC addresses, with
      02-00-0E to form unicast modified EUI-64 addresses, and with
      03-00-0E to form multicast modified EUI-64 addresses. See [this
      document] for more details."

5.6 SNAP Protocol Number Table and Assignment

   The "SNAP PROTOCOL IDs" table is renamed the "SNAP Protocol Numbers"
   table. The Note for that table is changed by replacing "PID" with
   "protocol number".

   IANA will assign 00-42 as the SNAP protocol number under the IANA OUI
   to be used for documentation purposes.

D. Eastlake and J. Abley                                       [Page 19]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

6. Security Considerations

   This document is concerned with assignment of parameters under the
   IANA OUI and closely related matters.  It is not directly concerned
   with security except as follows:

   Confusion and conflict can be caused by the use of MAC addresses or
   other OUI derived protocol parameters as examples in documentation.
   Examples used "only" in documentation can end up being coded and
   released or cause conflicts due to later real use and the possible
   acquisition of intellectual property rights in such addresses or
   parameters. The reservation herein of MAC addresses and parameters
   for documentation purposes will minimize such confusion and conflict.

   See [EUIRRTYPE] for security considerations in storing MAC addresses
   in the DNS.

Acknowledgements

   The comments and suggestions of the following people, listed in
   alphabetic order, is gratefully acknowledged:

   This document:
      David Black, Joel Jaeggli, Pearl Liang, Glenn Parsons, and Dan
      Romascanu

   RFC 5342:
      Bernard Aboba, Scott O. Bradner, Ian Calder, Michelle Cotton, Lars
      Eggert, Eric Gray, Alfred Hoenes, Russ Housley, Charlie Kaufman,
      Erik Nordmark, Dan Romascanu, Mark Townsley, and Geoff Thompson.

   The document was prepared in raw nroff. All macros used were defined
   within the source file.

D. Eastlake and J. Abley                                       [Page 20]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

Normative References

   [802_O&A]

       - "IEEE Standard for Local and Metropolitan Area Networks:
         Overview and Architecture", IEEE Std 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 Std
         802a-2003, 18 September 2003.

   [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
         IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
         2008.

Informative References

   [802.1Q] - "IEEE Standard for Local and metropolitan area networks /
         Media Access Control (MAC) Bridges and Virtual Bridge Local
         Area Networks", IEEE Std 802.1Q-2011, 31 August 2011.

   [802.3] - "IEEE Standard for Information technology /
         Telecommunications and information exchange between systems /
         Local and metropolitan area networks / Specific requirements /
         Part 3: Carrier sense multiple access with Collision Detection
         (CSMA/CD) Access Method and Physical Layer Specifications",
         IEEE Std 802.3-2008, 26 December 2008.

   [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 Std 802.11-2012, 29 March
         2012.

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

   [EUIRRTYPE] - J. Abley, "Resource Records for EUI-48 and EUI-64
         Addresses in the DNS", draft-jabley-dnsext-eui48-eui64-rrtypes,
         work in progress.

   [IANA] - Internet Assigned Numbers Authority, <http://www.iana.org>.

   [IEEE] - Institute of Electrical and Electronics Engineers,

D. Eastlake and J. Abley                                       [Page 21]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

         <http://www.ieee.org>.

   [IEEE802] - IEEE 802 LAN/MAN (Local Area Network / Metropolitan Area
         Network) Standards Committee, <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.

   [RFC2606] - Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
         Names", BCP 32, RFC 2606, June 1999.

   [RFC3092] - Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
         of "Foo"", RFC 3092, April 1 2001.

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

   [RFC4760] - Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
         "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.

   [RFC5214] - Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
         Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March
         2008.

   [RFC5332] - Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
         "MPLS Multicast Encapsulations", RFC 5332, August 2008.

   [RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol
         Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September
         2008.

   [RFC5737] - Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address
         Blocks Reserved for Documentation", RFC 5737, January 2010.

   [RFC5798] - Nadas, S., Ed., "Virtual Router Redundancy Protocol
         (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.

   [RFC6034] - Thaler, D., "Unicast-Prefix-Based IPv4 Multicast

D. Eastlake and J. Abley                                       [Page 22]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

         Addresses", RFC 6034, October 2010.

   [RFC6895] - Eastlake 3rd, D., "Domain Name System (DNS) IANA
         Considerations", BCP 42, RFC 6895, April 2013.

D. Eastlake and J. Abley                                       [Page 23]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

Appendix A. Templates

   This annex provides the specific templates for IANA assignments of
   parameters.  Explanatory words in parenthesis in the templates below
   may be deleted in a completed template as submitted to IANA.

A.1 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"
   [RFC3092])

   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:

A.2 IANA OUI Based Protocol Number Template

   Applicant Name:

   Applicant Email:

   Applicant Telephone: (starting with country code)

   Use Name: (brief name of use of code point such as "Foo Protocol")

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

   Note: (any additional note)

D. Eastlake and J. Abley                                       [Page 24]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

A.3 Other IANA OUI-Based Parameter Template

   Applicant Name:

   Applicant Email:

   Applicant Telephone: (starting with country code)

   Protocol where the OUI Based Parameter for which a value is being
   requested appears: (such as: Cipher Suite selection in IEEE 802.11)

   Use Name: (brief name of use of code point to be assigned, such as
   "Foo Cipher Suite" [RFC3092])

   Document: (ID or RFC specifying use to which the other IANA OUI based
   parameter value will be put.)

   Note: (any additional note)

D. Eastlake and J. Abley                                       [Page 25]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

Appendix B. Ethertypes

   This annex lists some Ethertypes specified for IETF Protocols or by
   IEEE 802 as known at the time of publication.  A more up-to-date list
   may be available on the IANA web site, currently at [IANA].  The IEEE
   Registration Authority page of Ethertypes,
   http://standards.ieee.org/regauth/ethertype/eth.txt, may also be
   useful.  See Section 3 above.

B.1 Some Ethertypes Specified by the IETF

      0x0800  Internet Protocol Version 4 (IPv4)
      0x0806  Address Resolution Protocol (ARP)
      0x0808  Frame Relay ARP
      0x22F3  TRILL
      0x22F4  L2-IS-IS
      0x880B  Point-to-Point Tunneling Protocol (PPTP)
      0x880C  General Switch Management Protocol (GSMP)
      0x8035  Reverse Address Resolution Protocol (RARP)
      0x86DD  Internet Protocol Version 6 (IPv6)
      0x8847  MPLS
      0x8848  MPLS with upstream-assigned label
      0x8861  Multicast Channel Allocation Protocol (MCAP)
      0x8863  PPP over Ethernet (PPPoE) Discovery Stage
      0x8864  PPP over Ethernet (PPPoE) Session Stage
      0x893B  TRILL Fine Grained Labeling (FGL)
      0x8946  TRILL RBridge Channel

B.2 Some IEEE 802 Ethertypes

      0x8100  IEEE Std 802.1Q  - Customer VLAN Tag Type (C-Tag, formerly
                                   called the Q-Tag)
      0x8808  IEEE Std 802.3   - Ethernet Passive Optical Network (EPON)
      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.11  - Pre-Authentication (802.11i)
      0x88CC  IEEE Std 802.1AB - Link Layer Discovery Protocol (LLDP)
      0x88E5  IEEE Std 802.1AE - Media Access Control Security
      0x88F5  IEEE Std 802.1Q  - Multiple VLAN Registration Protocol
                                   (MVRP)
      0x88F6  IEEE Std 802.1Q  - Multiple Multicast Registration
                                   Protocol (MMRP)
      0x890D  IEEE Std 802.11  - Fast Roaming Remote Request (802.11r)

D. Eastlake and J. Abley                                       [Page 26]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

      0x8917  IEEE Std 802.21  - Media Independent Handover Protocol
      0x8929  IEEE Std 802.1Qbe - Multiple I-SID Registration Protocol
      0x8940  IEEE Std 802.1Qbg - ECP Protocol (also used in 802.1BR)

D. Eastlake and J. Abley                                       [Page 27]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

Appendix C: Documentation Protocol Number

   Below is the template for assignment of a IANA OUI based protocol
   number value for document use. (See Section 3 and Appendix A.2.)

   Applicant Name: Donald E. Eastlake, 3rd

   Applicant Email: d3e3e3@gmail.com

   Applicant Telephone: 1-508-333-2270

   Use Name: Documentation

   Document: This document.

   Note: Request value 0x0042

D. Eastlake and J. Abley                                       [Page 28]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

Appendix Z: Change History

   RFC Editor Note: Please delete this section before publication.

From -00 to -01

   The -00 version was accidentally labeled with intended status
   "Proposed Standard".  This has been corrected to "Best Current
   Practice".

   Update author information.

   Add acknowledgement.

   Add Change History Appendix.

   Fix various typos.

From -01 to -02

   Move "Changes from RFC 5342" up from former Section 7 to be a part of
   Section 1.

   Add AFN numbers for 48-bit and 64-bit MAC addresses.

   Add Security Considerations language for documentation purpose MAC
   addresses.

   Fix various typos.

From -02 to -03

   Add assignment of 00-42 as the protocol number for documentation use
   to new subsection 5.6 and make editorial changes to the protocol
   number subregistry.

   Add assigned AFN and RRTYPE values for 48 and 64 bit MAC addresses in
   decimal and hex.

   Add note to Section 1 that "IESG Ratification" as specified in
   Section 5.1 is not the same as "IESG Approval" as specified in RFC
   5226.

   Add note to 1.4 that there is no documentation OUI but that

D. Eastlake and J. Abley                                       [Page 29]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

   documentation code points under the IANA OUI are specified herein.

   Replace references to [RFC5342] and draft-jabley-eui48-eui64-doc-addr
   in IANA registries with references to this document.

   Update note for "IANA 64-bit MAC Addresses" table.

   Update "PID" (Protocol ID) in connection with SNAP protocols IANA
   table to "protocol number" for consistency.

   Update Appendix B.

   Minor editorial fixes.

D. Eastlake and J. Abley                                       [Page 30]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

Authors' Addresses

      Donald E. Eastlake 3rd
      Huawei Technologies
      155 Beaver Street
      Milford, MA 01757 USA

      Phone: +1-508-634-2066
      EMail: d3e3e3@gmail.com

      Joe Abley
      ICANN
      12025 Waterfront Drive, Suite 300
      Los Angeles, CA 90094 USA

      Phone: +1 519 670 9327
      Email: joe.abley@icann.org

D. Eastlake and J. Abley                                       [Page 31]
INTERNET-DRAFT                         IANA/IETF and IEEE 802 Parameters

Copyright, Disclaimer, and Additional IPR Provisions

   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
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.  The definitive version of
   an IETF Document is that published by, or under the auspices of, the
   IETF. Versions of IETF Documents that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of IETF Documents. The
   definitive version of these Legal Provisions is that published by, or
   under the auspices of, the IETF. Versions of these Legal Provisions
   that are published by third parties, including those that are
   translated into other languages, should not be considered to be
   definitive versions of these Legal Provisions.  For the avoidance of
   doubt, each Contributor to the IETF Standards Process licenses each
   Contribution that he or she makes as part of the IETF Standards
   Process to the IETF Trust pursuant to the provisions of RFC 5378. No
   language to the contrary, or terms, conditions or rights that differ
   from or are inconsistent with the rights and licenses granted under
   RFC 5378, shall have any effect and shall be null and void, whether
   published or posted by such Contributor, or included with or in such
   Contribution.

D. Eastlake and J. Abley                                       [Page 32]