summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7042.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7042.txt')
-rw-r--r--doc/rfc/rfc7042.txt1515
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]
+