doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc7042.txt b/doc/rfc/rfc7042.txt
new file mode 100644
index 0000000..3abf680
--- /dev/null
+++ b/doc/rfc/rfc7042.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
+Request for Comments: 7042                                        Huawei
+BCP: 141                                                        J. Abley
+Obsoletes: 5342                                                Dyn, Inc.
+Updates: 2153                                               October 2013
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+     IANA Considerations and IETF Protocol and Documentation Usage
+                        for IEEE 802 Parameters
+
+Abstract
+
+   Some IETF protocols make use of Ethernet frame formats and IEEE 802
+   parameters.  This document discusses several uses of such parameters
+   in IETF protocols, specifies IANA considerations for assignment of
+   points under the IANA OUI (Organizationally Unique Identifier), and
+   provides some values for use in documentation.  This document
+   obsoletes RFC 5342.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7042.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Abley                   BCP                          [Page 1]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Abley                   BCP                          [Page 2]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Notations Used in This Document ............................4
+      1.2. Changes from RFC 5342 ......................................5
+      1.3. The IEEE Registration Authority ............................5
+      1.4. The IANA OUI ...............................................5
+   2. Ethernet Identifier Parameters ..................................5
+      2.1. 48-Bit MAC Identifiers, OUIs, and Other Prefixes ...........6
+           2.1.1. EUI-48 Assignments under the IANA OUI ...............6
+           2.1.2. EUI-48 Documentation Values .........................7
+           2.1.3. EUI-48 IANA Assignment Considerations ...............8
+      2.2. 64-Bit MAC Identifiers .....................................8
+           2.2.1. IPv6 Use of Modified EUI-64 Identifiers .............9
+           2.2.2. EUI-64 IANA Assignment Considerations ..............10
+           2.2.3. EUI-64 Documentation Values ........................12
+      2.3. Other MAC-48 Identifiers Used by the IETF .................12
+           2.3.1. Identifiers Prefixed "33-33" .......................12
+           2.3.2. The 'CF Series' ....................................13
+                  2.3.2.1. Changes to RFC 2153 .......................13
+   3. Ethernet Protocol Parameters ...................................14
+      3.1. Ethernet Protocol Assignment under the IANA OUI ...........16
+      3.2. Documentation Protocol Number .............................16
+   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 ..............................19
+      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 .................20
+   6. Security Considerations ........................................20
+   7. Acknowledgements ...............................................20
+   8. References .....................................................21
+      8.1. Normative References ......................................21
+      8.2. 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 ............................................25
+      B.1. Some Ethertypes Specified by the IETF .....................25
+      B.2. Some IEEE 802 Ethertypes ..................................26
+   Appendix C. Documentation Protocol Number .........................26
+
+
+
+
+
+
+
+Eastlake & Abley                   BCP                          [Page 3]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+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 several other uses
+   by the IETF 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.  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].
+
+   "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.
+
+
+
+
+Eastlake & Abley                   BCP                          [Page 4]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+1.2.  Changes from RFC 5342
+
+   o  Added MAC addresses and IANA OUI-based protocol and other values
+      for use in documentation, and added relevant Security
+      Considerations language.
+
+   o  Eliminated 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 they have proved to be problematic in practice.
+
+   o  Re-casted informational material about relevant IEEE assignment
+      policies to take into account [RAC-OUI].
+
+   o  Added AFNs and RRTYPEs for 48-bit and 64-bit MACs.
+
+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 assignments 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.
+
+2.  Ethernet Identifier Parameters
+
+   Section 2.1 discusses EUI-48 (Extended Unique Identifier 48) MAC
+   identifiers, their relationship to OUIs and other prefixes, 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.
+
+
+
+
+
+Eastlake & Abley                   BCP                          [Page 5]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+   [RAC-OUI] indicates that the IEEE Registration Authority Committee is
+   exploring the feasibility of defining a new "EUI-128" identifier.
+
+2.1.  48-Bit MAC Identifiers, OUIs, and Other Prefixes
+
+   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 or into a larger initial prefix assigned
+   to an organization and a shorter sequence of additional bits so as to
+   add up to 48 bits in total.  For example, the IEEE has assigned 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; however, IABs will become historic, and a wider
+   range of prefix lengths will be made available [RAC-OUI].
+
+   The IEEE describes its assignment procedures and policies for IEEE
+   802-related identifiers in [802_O&A], which is being revised.
+
+   Two bits within the initial octet of an EUI-48 have special
+   significance in MAC addresses: the Group bit (01) and the Local bit
+   (02).  OUIs and longer MAC prefixes 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 may
+   be constructed by leaving the Group bit zero.
+
+   The Local bit is zero for globally unique EUI-48 identifiers assigned
+   by the owner of an OUI or owner of a longer prefix.  If the Local bit
+   is a one, the identifier has been considered by IEEE 802 to be a
+   local identifier under the control of the local network
+   administrator; however, there may be emerging recommendations from
+   the IEEE Registration Authority on management of the local address
+   space.  If the Local bit is on, the holder of an OUI has no special
+   authority over MAC identifiers whose first 3 octets correspond to
+   their OUI.
+
+   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
+   identifiers from 00-00-5E-00-00-00 to 00-00-5E-FF-FF-FF.
+
+
+
+
+
+Eastlake & Abley                   BCP                          [Page 6]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+   Of these EUI-48 identifiers, the sub-blocks reserved or thus far
+   assigned by IANA 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 (IPv6 VRRP) [RFC5798].
+
+      00-00-5E-00-52-00 through 00-00-5E-00-52-FF: 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
+   Numbers" 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.
+
+
+
+
+
+Eastlake & Abley                   BCP                          [Page 7]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+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 power-of-two size block of 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 (see Section 5.1).
+
+      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 one of the types was
+   not included in the application.  That requirement has proved
+   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.  EUI-64 identifiers are currently used as follows:
+
+      o  In a modified form to construct some IPv6 interface identifiers
+         as described in Section 2.2.1
+
+      o  In IEEE Std 1394 (also known as FireWire and i.Link)
+
+      o  In IEEE Std 802.15.4 (also known as ZigBee)
+
+      o  In [InfiniBand]
+
+
+
+
+
+
+Eastlake & Abley                   BCP                          [Page 8]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+   Adding a 5-octet (40-bit) extension to a 3-octet (24-bit) OUI, or a
+   shorter extension to longer assigned prefixes [RAC-OUI] so as to
+   total 64 bits, produces an EUI-64 identifier under that OUI or longer
+   prefix.  As with EUI-48 identifiers, the first octet has the 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
+
+
+
+Eastlake & Abley                   BCP                          [Page 9]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+   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
+   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 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
+
+
+
+Eastlake & Abley                   BCP                         [Page 10]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+      02-00-5E-10-00-00-01-00 to 02-00-5E-EF-FF-FF-FF-FF, which is
+         available for assignment
+
+      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 power-of-two size block of 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 (see Section 5.1).
+
+      Assignments of any size, including 536870912 (2**29) or more
+         EUI-64 identifiers, may be made with IESG Ratification (see
+         Section 5.1).
+
+
+
+
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 11]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+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:
+
+      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 the 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 as specified in [RFC2464] for IPv6
+   multicast.  In all of these identifiers, the Group bit (the bottom
+
+
+
+Eastlake & Abley                   BCP                         [Page 12]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+   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
+      Center, formerly "Xerox PARC").  Ethernet was originally specified
+      by the 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 "Ethernet Numbers"
+   <http://www.iana.org/assignments/ethernet-numbers> and "PPP Numbers"
+   <http://www.iana.org/assignments/ppp-numbers>).
+
+2.3.2.1.  Changes to RFC 2153
+
+   The IANA Considerations in [RFC2153] were updated as follows by the
+   approval of [RFC5342] (no technical changes were made at that time):
+
+      o  Use of these identifiers based on IANA assignment was
+         deprecated.
+
+      o  IANA was instructed not to assign any further values in the
+         'CF Series'.
+
+
+
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 13]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+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 (Link-
+   Layer Service Access Point) protocol indicator for the "main" body of
+   the frame, as described below.  Traditionally, in the [802_O&A]
+   world, tags are a 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 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
+   Appendix B).  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.
+
+
+
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 14]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+   When using the IEEE 802 Logical Link Control (LLC) format (Subnetwork
+   Access Protocol (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
+   this use and is sometimes referred to as the SNAP Service Access
+   Point (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.
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 15]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+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
+   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
+
+   0x0042 is a protocol number under the IANA OUI (that is,
+   00-00-5E-00-42) to be used for documentation purposes.
+
+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
+
+
+
+Eastlake & Abley                   BCP                         [Page 16]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+   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 to update
+   this BCP and specify the new policy and parameter.
+
+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 have been replaced by references to this document.  In
+   addition, any references in the registries to [DOC-ADDR], which has
+   been combined into this document, have been replaced by references to
+   this document.
+
+   This document does not create any new IANA registries.
+
+   This document assigns MAC address values for documentation.  These
+   values had been previously assigned by [DOC-ADDR]; as noted above,
+   any references in the registries to [DOC-ADDR] have been replaced by
+   references to this document.
+
+   The only other assignment that has been made by this document is a
+   protocol number for documentation.  See Section 5.6 for details.
+
+   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.
+
+
+
+Eastlake & Abley                   BCP                         [Page 17]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+   The procedure described for Expert Review assignments in this
+   document is fully consistent with the IANA Expert Review policy
+   described in [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
+         Appendix A below and sends it to IANA <iana@iana.org>.
+
+      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 is available, will
+         contact the IESG.
+
+      In all cases, 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 is
+
+
+
+Eastlake & Abley                   BCP                         [Page 18]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+            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 Address Family Numbers (AFNs) for MAC addresses as
+   follows:
+
+         AFN         Decimal     Hex      Reference
+      ----------     -------    ------    ---------
+      48-bit MAC      16389     0x4005    [RFC7042]
+      64-bit MAC      16390     0x4006    [RFC7042]
+
+   IANA has assigned DNS RRTYPEs [RFC6895] for MAC addresses as follows:
+
+                                RRTYPE Code
+         Data       Mnemonic   Decimal   Hex      Reference
+      ----------    --------   -------  ------   -----------
+      48-bit MAC     EUI48       108    0x006C   [RFC7043]
+      64-bit MAC     EUI64       109    0x006D   [RFC7043]
+
+5.3.  Informational IANA Web Page Material
+
+   IANA 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 informational registry is "IEEE
+   802 Numbers".  IANA has merged in those Ethertypes listed in Appendix
+   B that were not already included.  IANA will update that
+   informational registry 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 has been 90% or more exhausted, IANA
+   should request an additional OUI from the IEEE Registration Authority
+   for further IANA assignment.  The appointed Expert(s) should monitor
+   for this condition and notify IANA.
+
+5.5.  IANA OUI MAC Address Table
+
+   No changes have been made in the "IANA Unicast 48-bit MAC Addresses"
+   and "IANA Multicast 48-bit MAC Addresses" tables except for the
+   updates to references as specified in the first part of Section 5.
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 19]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+5.6.  SNAP Protocol Number Table and Assignment
+
+   The "SNAP PROTOCOL IDs" table has been renamed the "SNAP Protocol
+   Numbers" table.  "PID" has been replaced by "Protocol Number".
+
+   IANA has assigned 0x0042 as the SNAP protocol number under the IANA
+   OUI to be used for documentation purposes.
+
+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 [RFC7043] for security considerations in storing MAC addresses in
+   the DNS.
+
+7.  Acknowledgements
+
+   The comments and suggestions of the following people, listed in
+   alphabetic order, are gratefully acknowledged:
+
+   This document:
+      David Black, Adrian Farrel, Bob Grow, Joel Jaeggli, Pearl Liang,
+      Glenn Parsons, Pete Resnick, 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, Geoff Thompson, and Mark Townsley.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 20]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+8.  References
+
+8.1.  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.
+
+8.2.  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 Ethernet", IEEE Std 802.3-2012, 28
+              December 2012.
+
+   [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.
+
+   [DOC-ADDR] Abley, J., "EUI-48 and EUI-64 Address Assignments for use
+              in Documentation", Work in Progress, March 2013.
+
+   [EUI-64]   IEEE Registration Authority, "Guidelines for 64-bit Global
+              Identifier (EUI-64(TM))", <http://standards.ieee.org/
+              regauth/oui/tutorials/EUI64.html>, November 2012.
+
+   [IANA]     Internet Assigned Numbers Authority,
+              <http://www.iana.org>.
+
+   [IEEE802]  IEEE 802 LAN/MAN Standards Committee,
+              <http://www.ieee802.org>.
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 21]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+   [InfiniBand]
+              InfiniBand Trade Association, "InfiniBand Architecture
+              Specification Volume 1", November 2007.
+
+   [RAC-OUI]  Parsons, G., "OUI Registry Restructuring", Work in
+              Progress, September 2013.
+
+   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
+              RFC 1112, August 1989.
+
+   [RFC1661]  Simpson, W., Ed., "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.
+
+
+
+Eastlake & Abley                   BCP                         [Page 22]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+   [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
+              Addresses", RFC 6034, October 2010.
+
+   [RFC6895]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
+              Considerations", BCP 42, RFC 6895, April 2013.
+
+   [RFC7043]  Abley, J., "Resource Records for EUI-48 and EUI-64
+              Addresses in the DNS", RFC 7043, October 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 23]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+Appendix A.  Templates
+
+   This appendix provides the specific templates for IANA assignments of
+   parameters.  Explanatory words in parentheses 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)
+
+
+
+
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 24]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+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)
+
+Appendix B.  Ethertypes
+
+   This appendix 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
+   0x8035  Reverse Address Resolution Protocol (RARP)
+   0x86DD  Internet Protocol Version 6 (IPv6)
+   0x880B  Point-to-Point Protocol (PPP)
+   0x880C  General Switch Management Protocol (GSMP)
+   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
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 25]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+B.2.  Some IEEE 802 Ethertypes
+
+   0x8100  IEEE Std 802.1Q   - Customer VLAN Tag Type (C-Tag, formerly
+                                called the Q-Tag) (initially Wellfleet)
+   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)
+   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)
+
+Appendix C.  Documentation Protocol Number
+
+   Below is the template based on which an IANA OUI-based protocol
+   number value was assigned 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
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 26]
+
+RFC 7042            IANA/IETF and IEEE 802 Parameters       October 2013
+
+
+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
+   Dyn, Inc.
+   470 Moore Street
+   London, ON  N6C 2C2
+   Canada
+
+   Phone: +1 519 670 9327
+   EMail: jabley@dyn.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Abley                   BCP                         [Page 27]
+