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
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
IEEE802参数的IANA注意事项和IETF协议及文档使用
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.
一些IETF协议使用以太网帧格式和IEEE 802参数。本文档讨论了IETF协议中此类参数的几种用途，指定了IANA OUI（组织唯一标识符）下分配点的IANA注意事项，并提供了一些用于文档中的值。本文件淘汰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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7042.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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.
一些IETF协议使用以太网或其他与IEEE 802相关的通信帧格式和参数[IEEE802]。这些包括MAC（媒体访问控制）标识符和协议标识符。
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.
本文件规定了IANA OUI下代码点分配的IANA注意事项。它还讨论了IETF对IEEE 802码点的几种其他用途，并提供了一些在文档中使用的值。如[RFC2606]和[RFC5737]中所述，使用为文档和示例保留的指定代码值可减少因重复为某些部署用途指定的代码点而产生冲突和混淆的可能性。
[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].
[RFC5226]并入本文件，除非本文件中有相反规定。在本文件中，在某些情况下使用“IESG批准”，并在第5.1节中规定。这与[RFC5226]中的“IESG批准”不同。
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).
本文档使用十六进制表示法。每个八位字节（即8位字节）由两个十六进制数字表示，该八位字节的值为无符号整数。连续的八位字节用连字符分隔。尽管IEEE[802.3]链路上八位字节内的位传输的物理顺序是从最低阶位到最高阶位（即，IETF的顺序相反），但本文件始终使用IETF位顺序。
In this document:
在本文件中：
"AFN" stands for Address Family Number [RFC4760].
“AFN”代表地址族编号[RFC4760]。
"EUI" stands for Extended Unique Identifier.
“EUI”表示扩展的唯一标识符。
"IAB" stands for Individual Address Block, not for Internet Architecture Board.
“IAB”代表单个地址块，而不是Internet架构板。
"MAC" stands for Media Access Control, not for Message Authentication Code.
“MAC”代表媒体访问控制，而不是消息身份验证代码。
"OUI" stands for Organizationally Unique Identifier.
“OUI”代表组织上唯一的标识符。
"RRTYPE" stands for a DNS Resource Record type [RFC6895].
“RRTYPE”表示DNS资源记录类型[RFC6895]。
"**" indicates exponentiation. For example, 2**24 is two to the twenty-fourth power.
“**”表示幂运算。例如，2**24是2到24次方。
o Added MAC addresses and IANA OUI-based protocol and other values for use in documentation, and added relevant Security Considerations language.
o 添加了MAC地址和基于IANA OUI的协议以及文档中使用的其他值，并添加了相关的安全注意事项。
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 消除了并行单播和多播分配的任何要求，除非有要求。[RFC5342]中包含了这些要求，理论上它们可以使IANA更容易记账，但事实证明它们在实践中存在问题。
o Re-casted informational material about relevant IEEE assignment policies to take into account [RAC-OUI].
o 重新铸造有关IEEE分配政策的信息材料，以考虑[RAC-OUI]。
o Added AFNs and RRTYPEs for 48-bit and 64-bit MACs.
o 为48位和64位Mac添加了AFN和RRN类型。
Originally the responsibility of Xerox Corporation, the registration authority for Ethernet parameters is now the IEEE Registration Authority, available on the web at:
最初由施乐公司负责，以太网参数的注册机构现在是IEEE注册机构，可在以下网址获得：
http://standards.ieee.org/regauth/
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.
一些任务及其持有者的列表可从IEEE注册机构网站下载。
The OUI 00-00-5E has been assigned to IANA.
OUI 00-00-5E已分配给IANA。
There is no OUI value reserved at this time for documentation, but there are documentation code points under the IANA OUI specified below.
目前没有为文档保留OUI值，但在下面指定的IANA OUI下有文档代码点。
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.
第2.1节讨论EUI-48（扩展唯一标识符48）MAC标识符，它们与OUI和其他前缀的关系，以及IANA OUI下的分配。第2.2节将其扩展到EUI-64标识符。第2.3节讨论了IANA OUI之外的其他IETF MAC标识符使用。
[RAC-OUI] indicates that the IEEE Registration Authority Committee is exploring the feasibility of defining a new "EUI-128" identifier.
[RAC-OUI]表明IEEE注册管理委员会正在探索定义新的“EUI-128”标识符的可行性。
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].
48位MAC“地址”是最常用的以太网接口标识符。全局唯一的标识符也称为EUI-48标识符。EUI-48被构造成初始的3个八位OUI（组织唯一标识符）和由OUI持有者分配的额外的3个八位字节，或者被构造成分配给组织的更大的初始前缀和更短的额外比特序列，以便总共加起来48比特。例如，IEEE分配了IAB（单个地址块），其中分配了前4个1/2八位字节（36位），从而使IAB 1 1/2八位字节（12位）的持有者能够控制；然而，IAB将成为历史，并且将提供更大范围的前缀长度[RAC-OUI]。
The IEEE describes its assignment procedures and policies for IEEE 802-related identifiers in [802_O&A], which is being revised.
IEEE在正在修订的[802_O&A]中描述了其IEEE 802相关标识符的分配程序和策略。
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.
EUI-48初始八位字节中的两位在MAC地址中具有特殊意义：组位（01）和本地位（02）。OUI和更长的MAC前缀分配有本地位零和未指定的组位。多播标识符可以通过打开组比特来构造，单播标识符可以通过将组比特保留为零来构造。
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.
由OUI所有者或更长前缀所有者分配的全局唯一EUI-48标识符的本地位为零。如果本地比特是1，则IEEE 802认为该标识符是本地网络管理员控制下的本地标识符；然而，IEEE注册管理局可能会对本地地址空间的管理提出新的建议。如果本地位为on，则OUI的持有者对其前3个八位字节对应于OUI的MAC标识符没有特殊权限。
An AFN and a DNS RRTYPE have been assigned for 48-bit MAC addresses (see Section 5.2).
已为48位MAC地址分配了AFN和DNS RRTYPE（见第5.2节）。
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.
如上文第1.4节所述，OUI 00-00-5E已分配给IANA。这包括从01-00-5E-00-00到01-00-5E-FF-FF-FF的2**24 EUI-48多播标识符和从00-00-5E-00-00-00到00-00-5E-FF-FF的2**24 EUI-48单播标识符。
Of these EUI-48 identifiers, the sub-blocks reserved or thus far assigned by IANA for purposes of documentation are as follows:
在这些EUI-48标识符中，IANA为编制文件而保留或迄今分配的子块如下：
Unicast, all blocks of 2**8 addresses thus far:
单播，迄今为止包含2**8个地址的所有块：
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-00-00至00-00-5E-00-00-FF：保留并要求IESG批准转让（见第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-01-00至00-00-5E-00-01-FF：为虚拟路由器冗余协议（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-02-00至00-00-5E-00-02-FF：为IPv6虚拟路由器冗余协议（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-52-00至00-00-5E-00-52-FF：用于非常小的任务。目前，这256个值中有3个已分配。
00-00-5E-00-53-00 through 00-00-5E-00-53-FF: assigned for use in documentation.
00-00-5E-00-53-00至00-00-5E-00-53-FF：指定用于文件编制。
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-00-00-00至01-00-5E-7F-FF-FF:2**23为IPv4多播分配的地址[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-80-00-00至01-00-5E-8F-FF-FF:2**20为MPLS多播分配的地址[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-00-00至01-00-5E-90-00-FF:2**8个地址用于非常小的分配。目前，这256个值中有4个已分配。
01-00-5E-90-10-00 through 01-00-5E-90-10-FF: 2**8 addresses for use in documentation.
01-00-5E-90-10-00至01-00-5E-90-10-FF:2**8个用于文件编制的地址。
For more detailed and up-to-date information, see the "Ethernet Numbers" registry at http://www.iana.org.
有关更详细和最新的信息，请参阅http://www.iana.org.
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
00-00-5E-00-53-00至00-00-5E-00-53-FF用于单播和
01-00-5E-90-10-00 through 01-00-5E-90-10-FF for multicast.
01-00-5E-90-10-00至01-00-5E-90-10-FF用于多播。
EUI-48 assignments under the current or a future IANA OUI (see Section 5.4) must meet the following requirements:
当前或未来IANA OUI（见第5.4节）下的EUI-48任务必须满足以下要求：
o must be for standards purposes (either for an IETF Standard or other standard related to IETF work),
o 必须用于标准目的（IETF标准或与IETF工作相关的其他标准），
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 必须适用于从等于或大于2次幂的边界开始的两个大小为2次幂的标识符块，包括分配一个（2**0）标识符，
o must not be used to evade the requirement for vendors to obtain their own block of identifiers from the IEEE, and
o 不得用于规避供应商从IEEE获得自己的标识符块的要求，以及
o must be documented in an Internet-Draft or RFC.
o 必须记录在互联网草稿或RFC中。
In addition, approval must be obtained as follows (see the procedure in Section 5.1):
此外，必须获得以下批准（见第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).
1、2、4、…、32768、65536（2**0、2**1、2**2、…、2**15、2**16）EUI-48标识符块的中小型分配需要专家审查（见第5.1节）。
Large assignments of 131072 (2**17) or more EUI-48 identifiers require IESG Ratification (see Section 5.1).
131072（2**17）或更多EUI-48标识符的大型分配需要IESG批准（见第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.)
（[RFC5342]在某些情况下要求并行单播和多播分配，即使其中一种类型未包含在应用程序中。该要求已被证明是不切实际的，并在本文档中被删除。）
IEEE also defines a system of 64-bit MAC identifiers including EUI-64s. EUI-64 identifiers are currently used as follows:
IEEE还定义了包括EUI-64s在内的64位MAC标识符系统。目前使用的EUI-64标识符如下：
o In a modified form to construct some IPv6 interface identifiers as described in Section 2.2.1
o 按照第2.2.1节所述，以修改的形式构造一些IPv6接口标识符
o In IEEE Std 1394 (also known as FireWire and i.Link)
o 在IEEE标准1394中（也称为FireWire和i.Link）
o In IEEE Std 802.15.4 (also known as ZigBee)
o 在IEEE标准802.15.4中（也称为ZigBee）
o In [InfiniBand]
o 在[InfiniBand]中
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.
将5-八位（40位）扩展添加到3-八位（24位）OUI，或将更短的扩展添加到更长的分配前缀[RAC-OUI]以总计64位，将在该OUI或更长的前缀下生成EUI-64标识符。与EUI-48标识符一样，第一个八位组具有相同的组和本地位。
An AFN and a DNS RRTYPE have been assigned for 64-bit MAC addresses (see Section 5.2).
已为64位MAC地址分配了AFN和DNS RRTYPE（见第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.
下面的讨论几乎完全是关于EUI-64标识符的“修改”形式；然而，任何分配了这样一个标识符的人也可以在使用这样的64位标识符作为接口的任何链路上使用未修改的形式作为MAC标识符。
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.
MAC-64标识符用于形成某些IPv6地址的低位64位（第2.5.1节和[RFC4291]的附录A和[RFC5214]的附录A）。当如此使用时，通过反转本地/全局位来修改MAC-64，以形成IETF“修改的EUI-64标识符”。下面是IANA OUI下修改的EUI-64单播标识符的图示，其中aa bb cc dd ee是扩展。
02-00-5E-aa-bb-cc-dd-ee
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.
第一个八位组显示为02而不是00，因为在修改的EUI-64标识符中，与EUI-48标识符相比，本地/全局位的意义是颠倒的。第一个八位字节中的02位为on的是全局唯一值（通用范围），而该位为off的是局部赋值，超出全局赋值的范围。
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.
本地/全局位被反转，以便于网络运营商键入本地范围标识符。因此，诸如1、2等修改的EUI-64标识符（忽略前导零）是本地的。如果没有修改，它们必须是02-00-00-00-00-00-01、02-00-00-00-00-00-00-02等，才能是本地的。
As with MAC-48 identifiers, the 01 bit on in the first octet indicates a group identifier.
与MAC-48标识符一样，第一个八位组中的01位表示组标识符。
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:
当修改后的EUI-64标识符扩展的前两个八位字节为FF-FE时，扩展的其余部分为OUI所有者为EUI-48分配的24位值。例如：
02-00-5E-FF-FE-yy-yy-yy or 03-00-5E-FF-FE-yy-yy-yy
02-00-5E-FF-FE-yy-yy-yy或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.
其中yy yy yy是OUI所有者（在本例中为IANA）分配的（EUI-48全局单播或多播标识符的）部分。因此，在IANA OUI下的一个或多个EU-48标识符的任何持有者也具有相同数目的修改的EU-64标识符，其可以通过在其EU-48标识符的中间插入FF-FE并反转局部/全局比特来形成。
(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.)
（注：[EUI-64]将FF-FF定义为要插入的位，以从MAC-48标识符创建IEEE EUI-64标识符。该文档称，从EUI-48标识符开始时使用FF-FE值。IETF仅使用FF-FE从48位以太网站点标识符创建修改的EUI-64标识符，无论它们是EUI-48还是MAC-48本地identifiers.EUI-48和本地MAC-48标识符在语法上是等价的，这在实践中不会引起任何问题。）
In addition, certain Modified EUI-64 identifiers under the IANA OUI are reserved for holders of IPv4 addresses as follows:
此外，IANA OUI下的某些修改的EUI-64标识符保留给IPv4地址的持有者，如下所示：
02-00-5E-FE-xx-xx-xx-xx
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
其中xx xx xx xx是32位IPv4地址。IPv4地址的所有者同时具有单播和多播派生的EUI-64地址。修改的EUI-64标识符来自
02-00-5E-FE-F0-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF
02-00-5E-FE-F0-00-00-00至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.)
在指定IPv4 E类地址之前有效保留。但是，对于基于IPv4地址的修改的EUI-64标识符，本地/全局位应设置为与IPv4地址是本地还是全局相对应。（请记住，修改后的EUI-64标识符本地/全局位的含义与（未修改的）MAC-64标识符中的含义相反。）
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.
下表显示了IANA OUI下保留、分配或可用的修改过的EUI-64标识符。如上所述，可以通过补充第一个八位组中的02位来确定相应的MAC地址。在所有情况下，通过补充第一个八位字节中的01位而形成的相应多播64位MAC地址与下面列出的修改后的64位单播地址块具有相同的状态。
02-00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF reserved
02-00-5E-00-00-00-00-00至02-00-5E-0F-FF-FF-FF-FF预留
02-00-5E-10-00-00-00-00 to 02-00-5E-10-00-00-00-FF assigned for documentation use
02-00-5E-10-00-00-00-00至02-00-5E-10-00-00-00-FF分配文件使用
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-10-00-00-01-00至02-00-5E-EF-FF-FF-FF-FF，可供分配
02-00-5E-F0-00-00-00-00 to 02-00-5E-FD-FF-FF-FF-FF reserved
02-00-5E-F0-00-00-00-00至02-00-5E-FD-FF-FF-FF保留
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-FE-00-00-00至02-00-5E-FE-FF-FF-FF-FF分配给IPv4地址持有者，如上所述
02-00-5E-FF-00-00-00-00 to 02-00-5E-FF-FD-FF-FF-FF reserved
02-00-5E-FF-00-00-00至02-00-5E-FF-FD-FF-FF保留
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-FE-00-00至02-00-5E-FF-FE-FF-FF-FF分配给IANA OUI下EUI-48标识符持有人，如上所述
02-00-5E-FF-FF-00-00-00 to 02-00-5E-FF-FF-FF-FF-FF reserved
02-00-5E-FF-FF-00-00至02-00-5E-FF-FF-FF-FF-FF保留
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:
上述保留标识符需要IESG批准（见第5.1节）才能进行分配。IANA OUI下的IANA EUI-64标识符分配必须满足以下要求：
o must be for standards purposes (either for an IETF Standard or other standard related to IETF work),
o 必须用于标准目的（IETF标准或与IETF工作相关的其他标准），
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 必须适用于从等于或大于2次幂的边界开始的两个大小为2次幂的标识符块，包括分配一个（2**0）标识符，
o must not be used to evade the requirement for vendors to obtain their own block of identifiers from the IEEE, and
o 不得用于规避供应商从IEEE获得自己的标识符块的要求，以及
o must be documented in an Internet-Draft or RFC.
o 必须记录在互联网草稿或RFC中。
In addition, approval must be obtained as follows (see the procedure in Section 5.1):
此外，必须获得以下批准（见第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).
1、2、4、…、134217728、268435456（2**0、2**1、2**2、…、2**27、2**28）EUI-64标识符区块的中小型分配需要专家审查（见第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).
任何规模的分配，包括536870912（2**29）或更多EUI-64标识符，均可通过IESG批准（见第5.1节）。
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.
以下未修改的64位MAC地址块供文档使用。IPv4派生地址基于IPv4文档地址[RFC5737]，MAC派生地址基于上述EUI-48文档地址。
Unicast:
单播：
00-00-5E-EF-10-00-00-00 to 00-00-5E-EF-10-00-00-FF general
00-00-5E-EF-10-00-00-00至00-00-5E-EF-10-00-00-FF概述
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-FE-C0-00-02-00至00-00-5E-FE-C0-00-02-FF和00-00-5E-FE-C6-33-64-00至00-00-5E-FE-C6-33-64-FF和00-00-5E-FE-CB-00-71-00至00-00-5E-FE-CB-00-71-FF
00-00-5E-FF-FE-00-53-00 to 00-00-5E-FF-FE-00-53-FF EUI-48 derived
00-00-5E-FF-FE-00-53-00至00-00-5E-FF-FE-00-53-FF EUI-48
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]
00-00-5E-FE-EA-C0-00-02和00-00-5E-FE-EA-C6-33-64和00-00-5E-FE-EA-CB-00-71源自IPv4单播的IPv4多播[RFC6034]
Multicast:
多播：
01-00-5E-EF-10-00-00-00 to 01-00-5E-EF-10-00-00-FF general
01-00-5E-EF-10-00-00至01-00-5E-EF-10-00-00-FF概述
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-C0-00-02-00至01-00-5E-FE-C0-00-02-FF和01-00-5E-FE-C6-33-64-00至01-00-5E-FE-C6-33-64-FF和01-00-5E-FE-CB-00-71-00至01-00-5E-FE-CB-00-71-FF
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-FE-EA-C0-00-02和01-00-5E-FE-EA-C6-33-64和01-00-5E-FE-EA-CB-00-71源自IPv4单播的IPv4多播[RFC6034]
01-00-5E-FF-FE-90-10-00 to 01-00-5E-FF-FE-90-10-FF EUI-48 derived
01-00-5E-FF-FE-90-10-00至01-00-5E-FF-FE-90-10-FF EUI-48
There are two other blocks of MAC-48 identifiers that are used by the IETF as described below.
IETF使用的MAC-48标识符还有两块，如下所述。
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
所有前缀为“33-33”的MAC-48多播标识符（即，范围从33-33-00-00-00-00到33-33-FF-FF-FF-FF的2**32多播MAC标识符）均按照[RFC2464]中的规定用于IPv6多播。在所有这些标识符中，组位（底部
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.
第一个八位字节的位）为on，这是将现有硬件作为多播标识符正常工作所必需的。它们还具有本地位，并在IPv6网络中用于此目的。
(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.)
（历史注释：在IPv6设计期间，习惯使用“3”表示未知值或示例值，而加利福尼亚州帕洛阿尔托市Coyote Hill Road 3333号是PARC（帕洛阿尔托研究中心，前身为“施乐PARC”）的地址。以太网最初由数字设备公司、英特尔公司和施乐公司指定。IEEE之前[802.3]以太网协议有时从这些公司名称的首字母起被称为“DIX”以太网。）
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."
信息[RFC2153]声明CF-00-00到CF-FF-FF之间的3个八位组值为OUI，IANA可将其分配给软件供应商，用于PPP[RFC1661]中，或用于供应商不需要IEEE分配OUI的其他用途。应该注意的是，当用作MAC-48前缀时，这些值的本地位和组位为on，而迄今为止所有IEEE分配的OUI的这些位均为off。组位在PPP中没有意义。引用[RFC2153]：“为了便于记忆，随意选择了‘CF0000’系列以匹配PPP NLPID‘CF’。”
CF-00-00 is reserved, and IANA lists multicast identifier CF-00-00-00-00-00 as used for Ethernet loopback tests.
CF-00-00是保留的，IANA列出了用于以太网环回测试的多播标识符CF-00-00-00-00。
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>).
在十多年的可用性中，仅分配了“CF系列”中的少数值。（请参阅“以太网号码”<http://www.iana.org/assignments/ethernet-numbers>和“购买力平价数字”<http://www.iana.org/assignments/ppp-numbers>).
The IANA Considerations in [RFC2153] were updated as follows by the approval of [RFC5342] (no technical changes were made at that time):
[RFC2153]中的IANA考虑事项经[RFC5342]批准更新如下（当时未进行任何技术变更）：
o Use of these identifiers based on IANA assignment was deprecated.
o 不推荐使用基于IANA分配的这些标识符。
o IANA was instructed not to assign any further values in the 'CF Series'.
o IANA被指示不要在“CF系列”中分配任何进一步的值。
Ethernet protocol parameters provide a means of indicating the contents of a frame -- for example, that its contents are IPv4 or IPv6.
以太网协议参数提供了一种指示帧内容的方法，例如，其内容是IPv4或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.
这一概念已扩展到“标签”标签。这种意义上的标签是其类型由以太类型标识的前缀，以太类型之后是帧“主体”的另一标签、以太类型或LSAP（链路层服务接入点）协议指示符，如下所述。传统上，在[802_O&A]世界中，标签是固定长度的，并且不包括其自身长度的任何编码。一般来说，任何正在处理帧的设备都不能安全地处理帧中的任何内容，而不是它不理解的以太类型。例如，C-Tag（以前的Q-Tag）[802.1Q]。它提供客户VLAN和帧的优先级信息。
There are two types of protocol identifier parameters that can occur in Ethernet frames after the initial MAC-48 destination and source identifiers:
在初始MAC-48目标和源标识符之后的以太网帧中可能出现两种类型的协议标识符参数：
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.
Ethertypes：这是16位标识符，显示为MAC目标和源（或标记）后面的初始两个八位字节，当视为无符号整数时，等于或大于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.
LSAP：这是8位协议标识符，成对出现在初始16位（两个八位组）剩余帧长度之后，依次出现在MAC目标和源之后（或标记之后）。当将此长度视为无符号整数时，它必须小于0x5DC，否则可能会被误认为是Ethertype。LSAP成对出现，其中一个用于指示源协议处理程序，另一个用于指示目标协议处理程序；然而，两者不同的用例相对较少。
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.
IANA既不分配Ethertypes也不分配LSAP；它们由IEEE注册机构指定（见上文第1.3节和附录B）。然而，LSAP和Ethertype都有扩展机制，因此它们可以与OUI下的五个八位以太网协议标识符一起使用，包括IANA在IANA OUI下分配的标识符。
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:
当对帧使用IEEE 802逻辑链路控制（LLC）格式（子网访问协议（SNAP））[802_O&A]时，基于OUI的协议标识符可以表示为：
xx-xx-AA-AA-03-yy-yy-yy-zz-zz
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.
其中xx xx是帧长度，如上所述，必须足够小，以免与Ethertype混淆；“AA”是表示此用途的LSAP，有时也称为快照服务访问点（SAP）；“03”是指示数据报服务的LLC控制八位字节；yy yy yy是一个OUI；zz zz是协议编号，在该OUI下，由OUI所有者分配。选择这种基于OUI的协议标识符的奇数五个八位字节长度，以便使用LLC控制八位字节（“03”），结果是16位对齐的。
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
当使用Ethertype指示框架主体的主要类型时，可以使用特殊的“OUI扩展Ethertype”88-B7。使用此Ethertype，框架主体可以从
88-B7-yy-yy-yy-zz-zz
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.
其中yy yy yy和zz zz的含义与上述快照格式中的含义相同。
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
在快照格式中，也可以使用任意Ethertype。将Ethertype作为zz zz字段放在全零OUI（00-00-00）之后可以实现这一点。看起来像
xx-xx-AA-AA-03-00-00-00-zz-zz
xx-xx-AA-AA-03-00-00-00-zz-zz
where zz-zz is the Ethertype.
其中zz-zz是以太类型。
(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
（请注意，此时，802协议语法功能足够强大，可以无限期链接。通常不清楚是否需要支持此类链接，但[802_O&A]需要支持
xx-xx-AA-AA-03-00-00-00-88-B7-yy-yy-yy-zz-zz
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.)
虽然这可以更有效地通过简单地捏出“-00 -00 -88 B7”在中间。
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.
除了标记帧内容外，802协议类型也出现在NBMA（非广播多址）下一跳解析协议[RFC2332]消息中。此类消息具有两种八位以太网类型和基于OUI的协议类型的规定。
Two-octet protocol numbers under the IANA OUI are available, as in
IANA OUI下有两个八位字节协议编号，如中所示
xx-xx-AA-AA-03-00-00-5E-qq-qq
xx-xx-AA-AA-03-00-00-5E-qq-qq
where qq-qq is the protocol number.
其中qq是协议号。
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:
从00-00-5E-00-00到00-00-5E-FF-FF（参见[IANA]）的2**16协议编号中，已经做出了许多此类分配。保留该范围的极值00-00-5E-00-00和00-00-5E-FF-FF，并要求IESG批准分配（见第5.1节）。IANA OUI下SNAP SAP协议（qq）编号的新分配必须满足以下要求：
o the assignment must be for standards use (either for an IETF Standard or other standard related to IETF work),
o 任务必须用于标准使用（IETF标准或与IETF工作相关的其他标准），
o it must be documented in an Internet-Draft or RFC, and
o 必须在互联网草案或RFC中记录，以及
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).
o 此类协议编号不得分配给任何具有Ethertype的协议（因为可以通过在Ethertype之前放置一个全零“OUI”来表示，如上所述）。
In addition, the Expert Review (or IESG Ratification for the two reserved values) must be obtained using the procedure specified in Section 5.1.
此外，必须使用第5.1节规定的程序获得专家评审（或两个保留值的IESG批准）。
0x0042 is a protocol number under the IANA OUI (that is, 00-00-5E-00-42) to be used for documentation purposes.
0x0042是IANA OUI（即00-00-5E-00-42）下用于记录目的的协议编号。
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
一些IEEE 802和其他协议提供了基于OUI的参数，超出了上述讨论的范围。这些参数通常由一个OUI加上一个附加值的八位字节组成。它们通常被称为“特定于供应商”的参数，尽管“特定于组织”可能更准确。他们看起来像
yy-yy-yy-zz
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].
其中yy yy yy是OUI，zz是附加说明符。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
通过专家评审，可在IANA OUI下为此类其他基于OUI的参数使用分配值，但对于每次使用
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.
保留由所有零位和所有一位组成的附加说明符值（0x00（00-00-5E-00）和0xFF（00-00-5E-FF）（对于一个八位组说明符）并要求IESG批准（见第5.1节）进行分配；此外，还指定了附加说明符值0x42（00-00-5E-42），以便在文档中使用。
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.
此类基于IANA OUI的其他参数的分配必须用于标准使用（IETF标准或与IETF工作相关的其他标准），并记录在互联网草案或RFC中。首次为该类型的特定参数分配值时，将创建一个IANA注册表，以包含该分配以及IANA OUI下该参数的任何后续值分配。专家将指定登记处的名称。
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.
如果此类参数需要与上述不同的策略，则必须采用BCP或标准跟踪RFC来更新此BCP并指定新策略和参数。
The entirety of this document concerns IANA considerations for the assignment of Ethernet parameters in connection with the IANA OUI and related matters.
本文件的全部内容涉及IANA在分配与IANA OUI相关的以太网参数和相关事项时的注意事项。
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.
由于本文件取代了[RFC5342]，IANA注册中对[RFC5342]的引用已被本文件的引用所取代。此外，注册处对[DOC-ADDR]的任何引用（已合并到本文件中）已被本文件的引用所取代。
This document does not create any new IANA registries.
本文档不创建任何新的IANA注册表。
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.
本文档为文档分配MAC地址值。这些值以前由[DOC-ADDR]分配；如上所述，注册处对[DOC-ADDR]的任何引用均已被本文件的引用所取代。
The only other assignment that has been made by this document is a protocol number for documentation. See Section 5.6 for details.
本文件所做的唯一其他分配是文件的协议编号。详见第5.6节。
No existing assignment is changed by this document.
此文档不会更改任何现有分配。
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.
本节规定了MAC、协议和其他基于IANA OUI的标识符的专家审查和IESG批准程序。本文件中提及的专家应由IESG任命的一名或多名人员组成，并根据IESG的意愿提供服务。
The procedure described for Expert Review assignments in this document is fully consistent with the IANA Expert Review policy described in [RFC5226].
本文件中描述的专家评审任务程序与[RFC5226]中描述的IANA专家评审政策完全一致。
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:
虽然有限，但专家判断任务所依据的代码点范围足够大，本文件中给出的要求和专家的良好判断足以作为指导。专家的想法是为EUI标识符的小型分配提供轻微的健全性检查，专家对EUI标识符的中型分配以及协议标识符和其他基于IANA OUI的参数的分配进行更多的审查。然而，分配很大一部分MAC标识符代码点空间是有意义的。（注意，现有分配包括一个用于整个多播IANA EUI-48代码点空间的1/2，一个用于该多播代码点空间的1/16。）在这些情况下，以及在分配“保留”值的情况下，需要IESG批准专家评审批准建议，如下所述。程序如下：
The applicant always completes the appropriate template from Appendix A below and sends it to IANA <iana@iana.org>.
申请人始终填写以下附录A中的适当模板，并将其发送给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.
IANA总是将模板发送给指定的专家。如果专家回避或没有回应，IANA可以选择另一位指定专家，如果没有，将联系IESG。
In all cases, if IANA receives a disapproval from an Expert selected to review an application template, the application will be denied.
在所有情况下，如果IANA收到选择审查申请模板的专家的不批准，申请将被拒绝。
If the assignment is based on Expert Review:
如果任务基于专家评审：
If IANA receives approval and code points are available, IANA will make the requested assignment.
如果IANA获得批准且代码点可用，IANA将进行请求的分配。
If the assignment is based on IESG Ratification:
如果转让基于IESG批准：
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
该程序从上述专家评审的第一步开始。如果专家不同意申请，他们只需通知IANA；但是，如果专家认为申请应获得批准，或者不确定，并且认为情况值得IESG注意，专家将通知IANA他们的建议，IANA将把申请连同批准或不确定的原因一起提交给IESG。IESG必须决定是否授予该任务。这可以通过IESG Telecohat中的管理项实现
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.
针对其他类型的请求完成。如果IESG决定不批准专家的有利意见，或在专家不确定的情况下决定反对申请，则申请被拒绝；否则，它将被授予。IESG将向专家和IANA传达其决定。
IANA has assigned Address Family Numbers (AFNs) for MAC addresses as follows:
IANA为MAC地址分配了地址系列号（AFN），如下所示：
AFN Decimal Hex Reference
---------- ------- ------ ---------
48-bit MAC 16389 0x4005 [RFC7042]
64-bit MAC 16390 0x4006 [RFC7042]
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:
IANA已为MAC地址分配DNS RRTYPE[RFC6895]，如下所示：
RRTYPE Code
Data Mnemonic Decimal Hex Reference
---------- -------- ------- ------ -----------
48-bit MAC EUI48 108 0x006C [RFC7043]
64-bit MAC EUI64 109 0x006D [RFC7043]
RRTYPE Code
Data Mnemonic Decimal Hex Reference
---------- -------- ------- ------ -----------
48-bit MAC EUI48 108 0x006C [RFC7043]
64-bit MAC EUI64 109 0x006D [RFC7043]
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.
IANA在其网站上维护一个关于以太网类型、OUI和在除IANA OUI之外的OUI下分配的多播地址的信息列表。此信息注册表的标题为“IEEE 802编号”。IANA已合并到附录B中列出的尚未包含的以太网类型中。当专家提供更改时，IANA将更新该信息注册表。
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.
当OUI 00-00-5E下的多播或单播EUI-48标识符的可用空间已耗尽90%或更多时，IANA应向IEEE注册机构请求额外的OUI，以进一步分配IANA。指定的专家应监测这种情况，并通知IANA。
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.
“IANA单播48位MAC地址”和“IANA多播48位MAC地址”表中未作任何更改，第5节第一部分规定的参考更新除外。
The "SNAP PROTOCOL IDs" table has been renamed the "SNAP Protocol Numbers" table. "PID" has been replaced by "Protocol Number".
“快照协议ID”表已重命名为“快照协议编号”表。“PID”已替换为“协议编号”。
IANA has assigned 0x0042 as the SNAP protocol number under the IANA OUI to be used for documentation purposes.
IANA已将0x0042指定为IANA OUI下的SNAP协议编号，以用于记录目的。
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.
本文件涉及IANA OUI下的参数分配以及密切相关的事项。除以下情况外，它与安全没有直接关系。
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.
在文档中使用MAC地址或其他OUI派生的协议参数可能会导致混淆和冲突。文档中“仅”使用的示例最终可能会被编码和发布，或者由于以后的实际使用以及可能获得此类地址或参数中的知识产权而导致冲突。本文保留MAC地址和参数用于文档目的将最大限度地减少此类混淆和冲突。
See [RFC7043] for security considerations in storing MAC addresses in the DNS.
有关在DNS中存储MAC地址的安全注意事项，请参阅[RFC7043]。
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.
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和Mark Townsley。
[802_O&A] "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE Std 802-2001, 8 March 2002.
[802_O&A]“局域网和城域网的IEEE标准：概述和体系结构”，IEEE标准802-2001，2002年3月8日。
"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.
“IEEE局域网和城域网标准：概述和体系结构/修改件1：原型和供应商特定协议开发的以太网类型”，IEEE Std 802a-2003，2003年9月18日。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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.1Q]“局域网和城域网/媒体访问控制（MAC）网桥和虚拟网桥局域网的IEEE标准”，IEEE标准802.1Q-2011，2011年8月31日。
[802.3] "IEEE Standard for Ethernet", IEEE Std 802.3-2012, 28 December 2012.
[802.3]“以太网IEEE标准”，IEEE标准802.3-2012，2012年12月28日。
[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.
[802.11]“系统/局域网和城域网之间信息技术/电信和信息交换的IEEE标准/特定要求/第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.11-2012，2012年3月29日。
[DOC-ADDR] Abley, J., "EUI-48 and EUI-64 Address Assignments for use in Documentation", Work in Progress, March 2013.
[DOC-ADDR]Abley，J.，“文件中使用的EUI-48和EUI-64地址分配”，在建工程，2013年3月。
[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.
[EUI-64]IEEE注册机构，“64位全局标识符（EUI-64（TM））指南”<http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html>，2012年11月。
[IANA] Internet Assigned Numbers Authority, <http://www.iana.org>.
[IANA]互联网分配号码管理局<http://www.iana.org>.
[IEEE802] IEEE 802 LAN/MAN Standards Committee, <http://www.ieee802.org>.
[IEEE802]IEEE 802局域网/城域网标准委员会<http://www.ieee802.org>.
[InfiniBand] InfiniBand Trade Association, "InfiniBand Architecture Specification Volume 1", November 2007.
[InfiniBand]InfiniBand贸易协会，“InfiniBand体系结构规范第1卷”，2007年11月。
[RAC-OUI] Parsons, G., "OUI Registry Restructuring", Work in Progress, September 2013.
[RAC-OUI]Parsons，G.，“OUI注册表重组”，正在进行的工作，2013年9月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC2153] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
[RFC2153]辛普森，W.，“PPP供应商扩展”，RFC 2153，1997年5月。
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[RFC2332]Luciani，J.，Katz，D.，Piscitello，D.，Cole，B.，和N.Doraswamy，“NBMA下一跳解析协议（NHRP）”，RFC 2332，1998年4月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake 3rd，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology of "Foo"", RFC 3092, April 1 2001.
[RFC3092]伊斯特莱克三世，D.，曼罗斯，C.，和E.雷蒙德，“Foo”的词源学”，RFC3092，2001年4月1日。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332]Eckert，T.，Rosen，E.，Ed.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，2008年8月。
[RFC5342] Eastlake 3rd, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008.
[RFC5342]Eastlake 3rd，D.，“IEEE802参数的IANA考虑因素和IETF协议使用”，BCP 141，RFC 5342，2008年9月。
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010.
[RFC5737]Arkko，J.，Cotton，M.和L.Vegoda，“为文档保留的IPv4地址块”，RFC 5737，2010年1月。
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[RFC5798]Nadas，S.，编辑，“IPv4和IPv6的虚拟路由器冗余协议（VRRP）第3版”，RFC 5798，2010年3月。
[RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast Addresses", RFC 6034, October 2010.
[RFC6034]Thaler，D.，“基于单播前缀的IPv4多播地址”，RFC60342010年10月。
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, April 2013.
[RFC6895]Eastlake 3rd，D.，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 6895，2013年4月。
[RFC7043] Abley, J., "Resource Records for EUI-48 and EUI-64 Addresses in the DNS", RFC 7043, October 2013.
[RFC7043]Abley，J.，“DNS中EUI-48和EUI-64地址的资源记录”，RFC 7043，2013年10月。
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.
本附录提供了IANA参数分配的具体模板。在提交给IANA的完整模板中，可删除以下模板中括号内的解释性词语。
Applicant Name:
申请人姓名：
Applicant Email:
申请人电邮：
Applicant Telephone: (starting with country code)
申请人电话：（以国家代码开头）
Use Name: (brief name of Parameter use such as "Foo Protocol" [RFC3092])
使用名称：（参数使用的简要名称，如“Foo协议”[RFC3092]）
Document: (ID or RFC specifying use to which the identifier or block of identifiers will be put.)
文档：（ID或RFC，指定标识符或标识符块的用途。）
Specify whether this is an application for EUI-48 or EUI-64 identifiers:
指定这是EUI-48还是EUI-64标识符的应用程序：
Size of Block requested: (must be a power-of-two-sized block, can be a block of size one (2**0))
请求的块大小：（必须是两个大小块的幂，可以是一个大小块（2**0））
Specify multicast, unicast, or both:
指定多播、单播或两者：
Applicant Name:
申请人姓名：
Applicant Email:
申请人电邮：
Applicant Telephone: (starting with country code)
申请人电话：（以国家代码开头）
Use Name: (brief name of use of code point such as "Foo Protocol")
使用名称：（代码点使用的简要名称，如“Foo协议”）
Document: (ID or RFC specifying use to which the protocol identifier will be put.)
文档：（ID或RFC，指定协议标识符将放置到的用途。）
Note: (any additional note)
注：（任何附加说明）
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)
出现请求值的基于OUI的参数的协议：（例如：IEEE 802.11中的密码套件选择）
Use Name: (brief name of use of code point to be assigned, such as "Foo Cipher Suite" [RFC3092])
使用名称：（要分配的代码点使用的简要名称，如“Foo密码套件”[RFC3092]）
Document: (ID or RFC specifying use to which the other IANA OUI-based parameter value will be put.)
文档：（ID或RFC，指定其他基于IANA OUI的参数值将用于哪个用途。）
Note: (any additional note)
注：（任何附加说明）
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.
本附录列出了IETF协议或IEEE 802在发布时已知的一些以太网类型。IANA网站上可能有更为最新的列表，目前位于[IANA]。IEEE注册机构页面，共页，http://standards.ieee.org/regauth/ethertype/eth.txt，也可能有用。见上文第3节。
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
0x0800 Internet协议版本4（IPv4）0x0806地址解析协议（ARP）0x0808帧中继ARP 0x22F3 TRILL 0x22F4 L2-IS-IS 0x8035反向地址解析协议（RARP）0x86DD Internet协议版本6（IPv6）0x880B点对点协议（PPP）0x880C通用交换机管理协议（GSMP）0x8847 MPLS 0x8848 MPLS，带上游分配标签0x8861多播信道分配协议（MCAP）0x8863以太网PPP（PPPoE）发现阶段0x8864以太网PPP（PPPoE）会话阶段0x893B TRILL细粒度标签（FGL）0x8946 TRILL RBridge信道
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)
0x8100 IEEE Std 802.1Q-客户VLAN标记类型（C-标记，以前称为Q-标记）（最初为Wellfleet）0x8808 IEEE Std 802.3-以太网无源光网络（EPON）0x888E IEEE Std 802.1X-基于端口的网络访问控制0x88A8 IEEE Std 802.1Q-服务VLAN标记标识符（S-标记）0x88B5 IEEE标准802-本地实验以太网类型0x88B6 IEEE标准802-本地实验以太网类型0x88B7 IEEE标准802-OUI扩展以太网类型0x88C7 IEEE标准802.11-预认证（802.11i）0x88CC IEEE标准802.1AB-链路层发现协议（LLDP）0x88E5 IEEE标准802.1AE-媒体访问控制安全0x88F5 IEEE标准802.1Q-多VLAN注册协议（MVRP）0x88F6 IEEE标准802.1Q-多播注册协议（MMRP）0x890D IEEE标准802.11-快速漫游远程请求（802.11r）0x8917 IEEE标准802.21-媒体独立切换协议0x8929 IEEE标准802.1Qbe-多I-SID注册协议0x8940 IEEE标准802.1Qbg-ECP协议（也用于802.1BR）
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.)
以下是分配用于文档使用的基于IANA OUI的协议编号值所依据的模板。（见第3节和附录A.2。）
Applicant Name: Donald E. Eastlake 3rd
申请人姓名：唐纳德·E·伊斯特莱克3号
Applicant Email: d3e3e3@gmail.com
申请人电邮：d3e3e3@gmail.com
Applicant Telephone: 1-508-333-2270
申请人电话：1-508-333-2270
Use Name: Documentation
使用名称：文档
Document: This document.
文件：这份文件。
Note: Request value 0x0042
注意：请求值0x0042
Authors' Addresses
作者地址
Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
Donald E.Eastlake第三华为技术有限公司美国马萨诸塞州米尔福德海狸街155号01757
Phone: +1-508-634-2066
EMail: d3e3e3@gmail.com
Phone: +1-508-634-2066
EMail: d3e3e3@gmail.com
Joe Abley Dyn, Inc. 470 Moore Street London, ON N6C 2C2 Canada
Joe Abley Dyn，Inc.位于加拿大N6C 2C2的伦敦摩尔街470号
Phone: +1 519 670 9327
EMail: jabley@dyn.com
Phone: +1 519 670 9327
EMail: jabley@dyn.com