doc: Add RFC documents

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