summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5342.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5342.txt')
-rw-r--r--doc/rfc/rfc5342.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc5342.txt b/doc/rfc/rfc5342.txt
new file mode 100644
index 0000000..1b76c58
--- /dev/null
+++ b/doc/rfc/rfc5342.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group D. Eastlake 3rd
+Request for Comments: 5342 Eastlake Enterprises
+BCP: 141 September 2008
+Updates: 2153
+Category: Best Current Practice
+
+
+ IANA Considerations and IETF Protocol Usage
+ for IEEE 802 Parameters
+
+Status of This Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Abstract
+
+ Some IETF protocols make use of Ethernet frame formats and IEEE 802
+ parameters. This document discusses some use of such parameters in
+ IETF protocols and specifies IANA considerations for allocation of
+ code points under the IANA OUI (Organizationally Unique Identifier).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 1]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Notations Used in This Document ............................3
+ 1.2. The IEEE Registration Authority ............................3
+ 1.2.1. The IANA OUI ........................................4
+ 1.3. Acknowledgements ...........................................4
+ 2. Ethernet Identifier Parameters ..................................4
+ 2.1. 48-Bit MAC Identifiers and OUIs ............................4
+ 2.1.1. EUI-48 Allocations under the IANA OUI ...............5
+ 2.1.2. EUI-48 IANA Allocation Considerations ...............5
+ 2.2. 64-Bit MAC Identifiers .....................................6
+ 2.2.1. IPv6 Use of Modified EUI-64 Identifiers .............6
+ 2.2.2. EUI-64 IANA Allocation Considerations ...............8
+ 2.3. Other MAC-48 Identifiers Used by IETF ......................9
+ 2.3.1. Identifiers Prefixed 33-33 ..........................9
+ 2.3.2. The 'CF Series' ....................................10
+ 2.3.2.1. Changes to RFC 2153 .......................10
+ 3. Ethernet Protocol Parameters ...................................10
+ 3.1. Ethernet Protocol Allocation under the IANA OUI ...........12
+ 4. Other OUI-Based Parameters .....................................13
+ 5. IANA Considerations ............................................13
+ 5.1. Expert Review and IESG Ratification .......................14
+ 5.2. Informational IANA Web Page Material ......................15
+ 5.3. OUI Exhaustion ............................................15
+ 6. Security Considerations ........................................15
+ 7. Normative References ...........................................15
+ 8. Informative References .........................................16
+ Appendix A. Templates ............................................18
+ A.1. EUI-48/EUI-64 Identifier or Identifier Block Template .....18
+ A.2. 5-Octet Ethernet Protocol Identifier Template .............18
+ A.3. Other IANA OUI-Based Parameter Template ...................19
+ Appendix B. Ethertypes ............................................19
+ B.1. Some Ethertypes Specified by The IETF .....................19
+ B.2. Some IEEE 802 Ethertypes ..................................20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 2]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+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 allocation of
+ code points under the IANA OUI. It also discusses some other IETF
+ use of IEEE 802 code points.
+
+ [RFC5226] is incorporated herein except where there are contrary
+ provisions in this document.
+
+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:
+
+ "IAB" stands for Individual Address Block, not for Internet
+ Architecture Board;
+
+ "MAC" stands for Media Access Control, not for Message Authentication
+ Code; and
+
+ "OUI" stands for Organizationally Unique Identifier.
+
+ "**" indicates exponentiation. For example, 2**24 is two to the
+ twenty-fourth power.
+
+1.2. The IEEE Registration Authority
+
+ Originally the responsibility of Xerox Corporation, the registration
+ authority for Ethernet parameters is now the IEEE Registration
+ Authority, available on the web at:
+
+ http://standards.ieee.org/regauth/
+
+ 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.
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 3]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+ A list of some allocated OUIs and IABs and their holders is
+ downloadable from the IEEE Registration Authority site.
+
+1.2.1. The IANA OUI
+
+ The OUI 00-00-5E has been allocated to IANA.
+
+1.3. Acknowledgements
+
+ The contributions and support of the following people, listed in
+ alphabetic order, is gratefully acknowledged:
+
+ Bernard Aboba, Scott O. Bradner, Ian Calder, Michelle Cotton,
+ Lars Eggert, Eric Gray, Alfred Hoenes, Russ Housley, Charlie
+ Kaufman, Erik Nordmark, Dan Romascanu, Mark Townsley, and Geoff
+ Thompson.
+
+2. Ethernet Identifier Parameters
+
+ Section 2.1 discusses EUI-48 (Extended Unique Identifier 48) MAC
+ identifiers, their relationship to OUIs and IABs, and allocations
+ under the IANA OUI. Section 2.2 extends this to EUI-64 identifiers.
+ Section 2.3 discusses other IETF MAC identifier use not under the
+ IANA OUI.
+
+2.1. 48-Bit MAC Identifiers and OUIs
+
+ 48-bit MAC "addresses" are the most commonly used Ethernet interface
+ identifiers. Those that are globally unique are also called EUI-48
+ identifiers. An EUI-48 is structured into an initial 3-octet OUI
+ (Organizationally Unique Identifier) and an additional 3 octets
+ assigned by the OUI holder. For organizations not requiring 3
+ octets' worth of identifiers, the IEEE allocates IABs (Individual
+ Address Blocks) instead, where the first 4 1/2 octets (36 bits) are
+ assigned, giving the holder of the IAB 1 1/2 octets (12 bits) they
+ can control.
+
+ The IEEE describes its assignment procedures and policies for IEEE
+ 802 related identifiers in [802_O&A].
+
+ Two bits within the initial 3 octets of an EUI-48 have special
+ significance: the Group bit (01-00-00) and the Local bit (02-00-00).
+ OUIs and IABs are allocated with the Local bit zero and the Group bit
+ unspecified. Multicast identifiers may be constructed by turning on
+ the Group bit, and unicast identifiers constructed by leaving the
+ Group bit zero.
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 4]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+ For globally unique EUI-48 identifiers allocated by an OUI or IAB
+ owner, the Local bit is zero. If the Local bit is a one, the
+ identifier is considered by IEEE 802 to be a local identifier under
+ the control of the local network administrator. If the Local bit is
+ on, the holder of an OUI (or IAB) has no special authority over
+ 48-bit MAC identifiers whose first 3 (or 4 1/2) octets correspond to
+ their OUI (or IAB).
+
+2.1.1. EUI-48 Allocations under the IANA OUI
+
+ The OUI 00-00-5E has been assigned to IANA as stated in Section 1.2.1
+ above. This includes 2**24 EUI-48 multicast 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.
+
+ Of these EUI-48 identifiers, the following allocations have been made
+ thus far:
+
+ o The 2**23 multicast identifiers from 01-00-5E-00-00-00 through
+ 01-00-5E-7F-FF-FF have been allocated for IPv4 multicast
+ [RFC1112].
+
+ o The 2**20 multicast identifiers from 01-00-5E-80-00-00 through
+ 01-00-5E-8F-FF-FF have been allocated for MPLS multicast
+ [RFC5332].
+
+ o The 2**8 unicast identifiers from 00-00-5E-00-00-00 through
+ 00-00-5E-00-00-FF are reserved and require IESG Ratification
+ for allocation (see Section 5.1).
+
+ o The 2**8 unicast identifiers from 00-00-5E-00-01-00 through
+ 00-00-5E-00-01-FF have been allocated for the Virtual Router
+ Redundancy Protocol (VRRP) [RFC3768].
+
+2.1.2. EUI-48 IANA Allocation Considerations
+
+ EUI-48 allocations under the current or a future IANA OUI (see
+ Section 5.2) must meet the following requirements:
+
+ o must be for standards purposes (either for an IETF Standard or
+ other standard related to IETF work),
+
+ o must be for a block of a power-of-two identifiers starting at a
+ boundary that is an equal or greater power of two, including
+ the allocation 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
+
+
+
+Eastlake 3rd Best Current Practice [Page 5]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+ 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 allocations of a block of 1, 2, 4, ..., 32768,
+ 65536 (2**0, 2**1, 2**2, ..., 2**15, 2**16) EUI-48 identifiers
+ require Expert Review.
+
+ Large allocations of 131072 (2**17) or more EUI-48 identifiers
+ require IESG Ratification (see Section 5.1).
+
+ To simplify record keeping, all future allocations of 256 (2**8) or
+ fewer identifiers shall have the Group bit unspecified, that is,
+ shall be allocations of parallel equal-size blocks of multicast and
+ unicast identifiers, even if one of these two types is not needed for
+ the proposed use. The only exception is that requests for unicast-
+ only identifier blocks of any size may be allocated out of the
+ remaining identifiers in the large unicast range from
+ 00-00-5E-00-02-00 to 00-00-5E-8F-FF-FF.
+
+2.2. 64-Bit MAC Identifiers
+
+ IEEE also defines a system of 64-bit MAC identifiers including
+ EUI-64s. Uptake of these "MAC-64" identifiers has been limited.
+ They are currently used in constructing some IPv6 Interface
+ Identifiers as described below and by the following IEEE standards:
+
+ o IEEE 1394 (also known as FireWire and i.Link),
+
+ o IEEE 802.15.4 (also known as ZigBee).
+
+ Adding a 5-octet (40-bit) extension to a 3-octet (24-bit) OUI forms
+ an EUI-64 identifier under that OUI. As with EUI-48 identifiers, the
+ OUI has the same Group/unicast and Local/Global bits.
+
+ The discussion below is almost entirely in terms of the "Modified"
+ form of EUI-64 identifiers; however, anyone allocated such an
+ identifier also has the unmodified form and may use it 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
+
+
+
+Eastlake 3rd Best Current Practice [Page 6]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+ is an illustration of a Modified EUI-64 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 allocation.
+
+ The Local/Global bit was inverted to make it easier for network
+ operators to type in local-scope identifiers. Thus, such Modified
+ EUI-64 identifiers as 1, 2, etc. (ignoring leading zeros), are
+ local. Without the modification, they would have to be
+ 02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc., to be local.
+
+ As with MAC-48 identifiers, the 01 bit on in the first octet
+ indicates a group identifier.
+
+ When the first two octets of the extension of a Modified EUI-64
+ identifier are FF-FE, the remainder of the extension is a 24-bit
+ value as assigned by the OUI owner for an EUI-48. For example:
+
+ 02-00-5E-FF-FE-yy-yy-yy
+ or
+ 03-00-5E-FF-FE-yy-yy-yy
+
+ where yy-yy-yy is the portion (of an EUI-48 global unicast or
+ multicast identifier) that is assigned by the OUI owner (IANA in this
+ case). Thus, any holder of one or more EUI-48 identifiers under the
+ 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.)
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 7]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+ In addition, certain Modified EUI-64 identifiers under the IANA OUI
+ are reserved for holders of IPv4 addresses as follows:
+
+ 02-00-5E-FE-xx-xx-xx-xx
+
+ where xx-xx-xx-xx is a 32-bit IPv4 address. For 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 Allocation Considerations
+
+ The following table shows which Modified EUI-64 identifiers under the
+ IANA OUI are reserved, used, or available as indicated.
+
+ 02-00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF reserved
+
+ 02-00-5E-10-00-00-00-00 to 02-00-5E-EF-FF-FF-FF-FF available for
+ allocation
+
+ 02-00-5E-F0-00-00-00-00 to 02-00-5E-FD-FF-FF-FF-FF reserved
+
+ 02-00-5E-FE-00-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF used by IPv4
+ address holders as described above
+
+ 02-00-5E-FF-00-00-00-00 to 02-00-5E-FF-FD-FF-FF-FF reserved
+
+ 02-00-5E-FF-FE-00-00-00 to 02-00-5E-FF-FE-FF-FF-FF used by holders
+ of EUI-48 identifiers under the IANA OUI as described above
+
+ 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 allocation. IANA EUI-64 identifier allocations under the
+ IANA OUI must meet the following requirements:
+
+ o must be for standards purposes (either for an IETF Standard or
+ other standard related to IETF work),
+
+ o must be for a block of a power-of-two identifiers starting at a
+ boundary which is an equal or greater power of two, including
+ the allocation 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
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 8]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+ 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 allocations 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.
+
+ Allocations of any size, including 536870912 (2**29) or more
+ EUI-64 identifiers, may be made with IESG Ratification (see
+ Section 5.1).
+
+ To simplify record keeping, all allocations of 65536 (2**16) or less
+ EUI-64 identifiers shall have the Group bit unspecified, that is,
+ shall be allocations of parallel equal size blocks of multicast and
+ unicast identifiers, even if one of these two types is not needed for
+ the proposed use.
+
+2.3. Other MAC-48 Identifiers Used by IETF
+
+ There are two other blocks of MAC-48 identifiers that are used by the
+ IETF as described below.
+
+2.3.1. Identifiers Prefixed 33-33
+
+ All MAC-48 multicast identifiers prefixed "33-33" (that is, the 2**32
+ multicast MAC identifiers in the range from 33-33-00-00-00-00 to
+ 33-33-FF-FF-FF-FF) are used by the IETF for global IPv6 multicast
+ [RFC2464]. In all these identifiers, the Group bit (the bottom bit
+ of the first octet) is on, as is required to work properly with
+ existing hardware as a multicast identifier. They also have the
+ Local bit on and are used for this purpose in IPv6 networks.
+
+ (Historical note: It was the custom during IPv6 design to use "3"
+ for unknown or example values, and 3333 Coyote Hill Road, Palo
+ Alto, California, is the address of PARC (Palo Alto Research
+ Center, formerly "Xerox PARC"). Ethernet was originally specified
+ by Digital Equipment Corporation, Intel Corporation, and Xerox
+ Corporation. The pre IEEE [802.3] Ethernet protocol has sometimes
+ been known as "DIX" Ethernet from the first letters of the names
+ of these companies.)
+
+
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 9]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+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 allocation 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-allocated OUIs 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 allocated. (See http://www.iana.org under both
+ Ethernet Parameters and PPP Parameters.)
+
+2.3.2.1. Changes to RFC 2153
+
+ The IANA Considerations in [RFC2153] are updated as follows (no
+ technical changes are made): Use of these identifiers based on IANA
+ allocation is deprecated. IANA is directed not to allocate any
+ further values in the 'CF Series'.
+
+3. Ethernet Protocol Parameters
+
+ Ethernet protocol parameters provide a means of indicating the
+ contents of a frame -- for example, that its contents are IPv4 or
+ IPv6.
+
+ The concept has been extended to labeling by "tags". A tag in this
+ sense is a prefix whose type is identified by an Ethertype that is
+ then followed by either another tag, an Ethertype, or an LSAP
+ protocol indicator for the "main" body of the frame, as described
+ below. Traditionally in the [802_O&A] world, tags are fixed length
+ and do not include any encoding of their own length. Thus, anything
+ 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:
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 10]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+ Ethertypes: These are 16-bit identifiers appearing as the initial
+ two octets after the MAC destination and source (or after a
+ tag) which, when considered as an unsigned integer, are equal
+ to or larger than 0x0600.
+
+ LSAPs: These are 8-bit protocol identifiers that occur in pairs
+ immediately after an initial 16-bit (two octet) remaining frame
+ length, which is in turn after the MAC destination and source
+ (or after a tag). Such a length must, when considered as an
+ unsigned integer, be less than 0x5DC or it could be mistaken as
+ an Ethertype. LSAPs (Link-Layer Subnet Access Points) occur in
+ pairs where one is intended to indicate the source protocol
+ handler and one the destination protocol handler; however, use
+ cases where the two are different have been relatively rare.
+
+ Neither Ethertypes nor LSAPs are allocated by IANA; instead, they are
+ allocated by the IEEE Registration Authority (see Section 1.2 above
+ and the Ethertype Annex below). However, both LSAPs and Ethertypes
+ have extension mechanisms so that they can be used with five-octet
+ Ethernet protocol identifiers under an OUI, including those allocated
+ by IANA under the IANA OUI.
+
+ When using the IEEE 802 LLC format (SNAP) [802_O&A] for a frame, an
+ OUI-based protocol identifier can be expressed as follows:
+
+ xx-xx-AA-AA-03-yy-yy-yy-zz-zz
+
+ where xx-xx is the frame length and, as above, must be small enough
+ not to be confused with an Ethertype; "AA" is the LSAP that indicates
+ this use and is sometimes referred to as the SNAP SAP; "03" is the
+ LLC control octet indicating datagram service; yy-yy-yy is an OUI;
+ and zz-zz is a protocol number, under that OUI, allocated by the OUI
+ owner. The odd five-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
+
+
+
+Eastlake 3rd Best Current Practice [Page 11]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+ 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
+
+ even though this could be more efficiently expressed by simply
+ pinching out the "00-00-00-88-B7" in the middle.)
+
+ As well as labeling frame contents, 802 Protocol types appear within
+ NBMA (Non-Broadcast Multi-Access) Next Hop Resolution Protocol
+ [RFC2332] messages. Such messages have provisions for both two octet
+ Ethertypes and OUI based protocol types.
+
+3.1. Ethernet Protocol Allocation under the IANA OUI
+
+ Two-octet protocol numbers under the IANA OUI are available, as in
+
+ xx-xx-AA-AA-03-00-00-5E-zz-zz.
+
+ A number of such allocations have been made out of the 2**16 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 allocation (see
+ Section 5.1). New allocations of SNAP SAP protocol (zz-zz) numbers
+ under the IANA OUI must meet the following requirements:
+
+ o the allocation 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 allocated for any protocol
+ that has an Ethertype (because that can be expressed by putting
+ an all zeros "OUI" before the Ethertype as described above).
+
+ In addition, the Expert Review (or IESG Ratification for the two
+ reserved values) must be obtained using the procedure specified in
+ Section 5.1.
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 12]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+4. Other OUI-Based Parameters
+
+ Some IEEE 802 and other protocols provide for parameters based on an
+ OUI beyond those discussed above. Such parameters most commonly
+ consist of an OUI plus one octet of additional value. They are
+ usually called "vendor specific" parameters, although "organization
+ specific" might be more accurate. They would look like
+
+ yy-yy-yy-zz
+
+ where yy-yy-yy is the OUI and zz is the additional specifier. An
+ example is the Cipher Suite Selector in IEEE 802.11 ([802.11], page
+ 125).
+
+ Values may be allocated under the IANA OUI for such other OUI-based
+ parameter usage by Expert Review except that, for each use, the
+ additional specifier values consisting of all zero bits and all one
+ bits (0x00 and 0xFF for a one-octet specifier) are reserved and
+ require IESG Ratification (see Section 5.1) for allocation. The
+ allocations 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 allocated for a
+ particular parameter of this type, an IANA registry will be created
+ to contain that allocation and any subsequent allocations of values
+ for that parameter under the IANA OUI. The Expert will specify the
+ name of the registry.
+
+ (If a different policy from that above is required for such a
+ parameter, a BCP or Standards Track RFC must be adopted updating this
+ BCP and specifying the new policy and parameter.)
+
+5. IANA Considerations
+
+ The entirety of this document concerns IANA Considerations for the
+ allocation of Ethernet parameters in connection with the IANA OUI and
+ related matters.
+
+ Specifically:
+
+ Section 1.2.1 provides information on the IANA-assigned OUI.
+
+ Section 2.1.1 lists current EUI-48 assignments under this OUI.
+
+ Section 2.1.2 specifies IANA considerations for EUI-48
+ assignments.
+
+ Section 2.2.2 specifies IANA considerations for EUI-64
+ assignments.
+
+
+
+Eastlake 3rd Best Current Practice [Page 13]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+ Section 3.1 provides a pointer to current protocol identifier
+ assignments under the IANA OUI, and specifies IANA considerations
+ for protocol identifier assignments.
+
+ Section 4 briefly provides IANA considerations relating to OUI-
+ based miscellaneous allocations.
+
+5.1. Expert Review and IESG Ratification
+
+ This section specifies the procedure for Expert Review and IESG
+ Ratification of MAC, protocol, and other IANA OUI-based identifiers.
+ The Expert(s) referred to in this document shall consist of one or
+ more persons appointed by and serving at the pleasure of the IESG.
+ The procedure described for Expert Review allocations in this
+ document is fully consistent with the IANA Expert Review policy
+ described in Section 4.1 of [RFC5226].
+
+ While finite, the universe of code points from which Expert judged
+ allocations 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 allocations of EUI identifiers with
+ increased scrutiny by the Expert for medium-sized allocations of EUI
+ identifiers, and allocations of protocol identifiers and other IANA
+ OUI based parameters. However, it can make sense to allocate very
+ large portions of the MAC identifier code point space. (Note that
+ existing allocations include one for 1/2 of the entire multicast code
+ point space and one for 1/16 of the multicast code point space.) In
+ those cases, and in cases of the allocation of "reserved" values,
+ IESG Ratification of an Expert Review approval recommendation is
+ required as described below. The procedure is as follows:
+
+ The applicant always completes the appropriate Template from the
+ Template Annex below and sends it to IANA <iana@iana.org>.
+
+ IANA always sends the Template to an appointed Expert. If the
+ Expert recuses themselves or is non-responsive, IANA may choose
+ an alternative appointed Expert or, if none are available, will
+ contact the IESG.
+
+ If the allocation is based on Expert Review:
+
+ If IANA receives a disapproval from an Expert selected to
+ review an application Template, the application will be
+ denied.
+ If IANA receives approval and code points are available, IANA
+ will make the requested allocation.
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 14]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+ If the allocation is based on IESG Ratification, the procedure
+ starts with the first two 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 allocation will be
+ granted. This can be accomplished by a management item in an
+ IESG telechat as done for other types of requests. If the IESG
+ decides not to ratify a favorable opinion by the Expert or
+ decides against an application where the Expert is uncertain,
+ the application is denied, otherwise it is granted. The IESG
+ will communicate its decision to the Expert and to IANA.
+
+5.2. Informational IANA Web Page Material
+
+ IANA also maintains an informational listing on its web site
+ concerning Ethertypes, OUIs, and multicast addresses allocated under
+ OUIs other than the IANA OUI. IANA shall update that list when
+ changes are provided by the Expert.
+
+5.3. OUI Exhaustion
+
+ When the available space for either multicast or unicast EUI-48
+ identifiers under OUI 00-00-5E have been 90% or more exhausted, IANA
+ should request an additional OUI from the IEEE Registration Authority
+ (see Section 1.2) for further IANA allocation use.
+
+6. Security Considerations
+
+ This document is concerned with allocation of parameters under the
+ IANA OUI and closely related matters. It is not directly concerned
+ with security.
+
+7. Normative References
+
+ [802_O&A] "IEEE Standard for Local and Metropolitan Area Networks:
+ Overview and Architecture", IEEE 802-2001, 8 March 2002.
+
+ "IEEE Standard for Local and Metropolitan Area Networks:
+ Overview and Architecture / Amendment 1: Ethertypes for
+ Prototype and Vendor-Specific Protocol Development", IEEE
+ 802a-2003, 18 September 2003.
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 15]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+8. Informative References
+
+ [802.1Q] "IEEE Standard for Local and metropolitan area networks /
+ Virtual Bridged Local Area Networks", IEEE 802.1Q-2005, 19
+ May 2006.
+
+ [802.3] "IEEE Standard for Information technology /
+ Telecommunications and information exchange between systems
+ / Local and metropolitan area networks / Specific
+ requirements / Part 3: Carrier sense multiple access with
+ collision detection (CSMA/CD) access method and physical
+ layer specifications", IEEE 802.3-2005, 9 December 2005.
+
+ [802.11] "IEEE Standard for Information technology /
+ Telecommunications and information exchange between systems
+ / Local and metropolitan area networks / Specific
+ requirements / Part 11: Wireless LAN Medium Access Control
+ (MAC) and Physical Layer (PHY) Specifications", IEEE
+ 802.11-2007, 11 June 2007.
+
+ [EUI-64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
+ Registration Authority", <http://standards.ieee.org/
+ regauth/oui/tutorials/EUI64.html>, March 1997.
+
+ [IANA] Internet Assigned Numbers Authority, Ethernet Types,
+ <http://www.iana.org>.
+
+ [IEEE] Institute of Electrical and Electronics Engineers,
+ <http://www.ieee.org>.
+
+ [IEEE802] IEEE 802 LAN/MAN (Local Area Network / Metropolitan Area
+ Network) Standards Committee, <http://www.ieee802.org>.
+
+ [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
+ RFC 1112, Stanford University, August 1989.
+
+ [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
+ RFC 1661, July 1994.
+
+ [RFC2153] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
+
+ [RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
+ Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC
+ 2332, April 1998.
+
+ [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
+ Networks", RFC 2464, December 1998.
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 16]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+ [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
+ RFC 3768, April 2004.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+ [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
+ Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
+ March 2008.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
+ 2008.
+
+ [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
+ "MPLS Multicast Encapsulations", RFC 5332, August 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 17]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+Appendix A. Templates
+
+ This annex provides the specific templates for IANA allocations of
+ parameters. Explanatory words in parenthesis in the templates below
+ may be deleted in a completed template as submitted to IANA.
+
+A.1. EUI-48/EUI-64 Identifier or Identifier Block Template
+
+ Applicant Name:
+
+ Applicant Email:
+
+ Applicant Telephone: (starting with country code)
+
+ Use Name: (brief name of Parameter use such as "Foo Protocol")
+
+ 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. 5-Octet Ethernet Protocol Identifier 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.)
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 18]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+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 allocated, such
+ as "Foo Cipher Suite")
+
+ Document: (ID or RFC specifying use to which the other IANA OUI
+ based parameter value will be put.)
+
+Appendix B. Ethertypes
+
+ This annex lists some Ethertypes specified for IETF Protocols or by
+ IEEE 802 as known at the time of publication. A more up-to-date list
+ may be available on the IANA web site, currently at [IANA]. The IEEE
+ Registration Authority page of Ethertypes,
+ http://standards.ieee.org/regauth/ethertype/eth.txt, may also be
+ useful. See Section 3 above.
+
+B.1. Some Ethertypes Specified by the IETF
+
+ 0x0800 Internet Protocol Version 4 (IPv4)
+ 0x0806 Address Resolution Protocol (ARP)
+ 0x0808 Frame Relay ARP
+ 0x880B Point-to-Point Tunneling Protocol (PPTP)
+ 0x880C General Switch Management Protocol (GSMP)
+ 0x8035 Reverse Address Resolution Protocol (RARP)
+ 0x86DD Internet Protocol Version 6 (IPv6)
+ 0x8847 MPLS
+ 0x8848 MPLS with upstream-assigned label
+ 0x8861 Multicast Channel Allocation Protocol (MCAP)
+ 0x8863 PPP over Ethernet (PPPoE) Discovery Stage
+ 0x8864 PPP over Ethernet (PPPoE) Session Stage
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 19]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+B.2. Some IEEE 802 Ethertypes
+
+ 0x8100 IEEE Std 802.1Q - Customer VLAN Tag Type (C-Tag, formerly
+ called the Q-Tag)
+ 0x8808 IEEE Std 802.3 - Ethernet Passive Optical Network (EPON)
+ 0x888E IEEE Std 802.1X - Port-based network access control
+ 0x88A8 IEEE Std 802.1Q - Service VLAN tag identifier (S-Tag)
+ 0x88B5 IEEE Std 802 - Local Experimental Ethertype
+ 0x88B6 IEEE Std 802 - Local Experimental Ethertype
+ 0x88B7 IEEE Std 802 - OUI Extended Ethertype
+ 0x88C7 IEEE Std 802.11i - Pre-Authentication
+ 0x88CC IEEE Std 802.1AB - Link Layer Discovery Protocol (LLDP)
+ 0x88E5 IEEE Std 802.1AE - Media Access Control Security
+ 0x88F5 IEEE Std 802.1ak - Multiple VLAN Registration Protocol
+ (MVRP)
+ 0x88F6 IEEE Std 802.1Q - Multiple Multicast Registration
+ Protocol (MMRP)
+ 0x890D IEEE 802.11r - Fast Roaming Remote Request
+
+Author's Address
+
+ Donald E. Eastlake 3rd
+ 155 Beaver Street
+ Milford, MA 01757 USA
+
+ Phone: +1-508-634-2066
+ EMail: d3e3e3@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 20]
+
+RFC 5342 IANA & IETF Use of IEEE 802 Parameters September 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd Best Current Practice [Page 21]
+