Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 9542 Independent
BCP: 141 J. Abley
Obsoletes: 7042 Cloudflare
Category: Best Current Practice Y. Li
ISSN: 2070-1721 Huawei Technologies
April 2024
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA Organizationally Unique Identifier (OUI), and provides some values for use in documentation. This document obsoletes RFC 7042.
一部のIETFプロトコルは、イーサネットフレーム形式とIEEE 802パラメーターを使用しています。このドキュメントでは、このようなパラメーターのいくつかの側面とIETFプロトコルでの使用について説明し、IANA組織的に一意の識別子（OUI）の下でのポイントの割り当てに関するIANAの考慮事項を指定し、ドキュメントで使用する値を提供します。このドキュメントは、RFC 7042を廃止します。
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 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPSの詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9542.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9542で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Notations Used in This Document
1.2. The IEEE Registration Authority
1.3. The IANA Organizationally Unique Identifier
1.4. CFM Code Points
2. Ethernet Identifier Parameters
2.1. 48-Bit MAC Identifiers, OUIs, and Other Prefixes
2.1.1. Special First Octet Bits
2.1.2. OUIs and CIDs
2.1.3. 48-Bit MAC Assignments under the IANA OUI
2.1.4. 48-Bit MAC Documentation Values
2.1.5. 48-Bit IANA MAC Assignment Considerations
2.2. 64-Bit MAC Identifiers
2.2.1. IPv6 Use of Modified EUI-64 Identifiers
2.2.2. EUI-64 IANA Assignment Considerations
2.2.3. EUI-64 Documentation Values
2.3. Other 48-Bit MAC Identifiers Used by the IETF
2.3.1. Identifiers with a '33-33' Prefix
2.3.2. The CF Series
2.4. CBOR Tags
3. Ethernet Protocol Parameters
3.1. Ethernet Protocol Assignment under the IANA OUI
3.2. Documentation Protocol Number
4. Other OUI/CID-Based Parameters
4.1. LLDP IETF Organizationally Specific TLV Type
5. IANA Considerations
5.1. Expert Review and IESG Ratification
5.1.1. Expert Review Guidance
5.1.2. Expert Review and IESG Ratification Procedure
5.2. IANA Registry Group (Web Page) Name Changes
5.3. MAC Address AFNs and RRTYPEs
5.4. Informational IANA Registry Group Material
5.5. EtherType Assignment Process
5.6. OUI Exhaustion
5.7. IANA OUI MAC Address Table
5.8. IANA LLDP TLV Subtypes
5.9. CBOR Tag Assignments
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Templates
A.1. EUI-48/EUI-64 Identifier or Identifier Block Template
A.2. IANA OUI/CID-Based Protocol Number Template
A.3. Other IANA OUI/CID-Based Parameter Template
Appendix B. EtherTypes
B.1. IESG Statement on EtherTypes
Appendix C. Changes from RFC 7042
Acknowledgements
Authors' Addresses
Some IETF protocols use Ethernet or other communication frame formats and parameters related to IEEE 802 [IEEE802]. These include Media Access Control (MAC) addresses and protocol identifiers. The IEEE Registration Authority [IEEE_RA] manages the assignment of identifiers used in IEEE 802 networks, in some cases assigning blocks of such identifiers whose sub-assignment is managed by the entity to which the block is assigned. The IEEE RA also provides a number of tutorials concerning these parameters [IEEEtutorials].
一部のIETFプロトコルは、IEEE 802 [IEEE802]に関連するイーサネットまたはその他の通信フレーム形式とパラメーターを使用します。これらには、メディアアクセス制御（MAC）アドレスとプロトコル識別子が含まれます。IEEE登録機関[IEEE_RA]は、IEEE 802ネットワークで使用される識別子の割り当てを管理します。IEEE RAは、これらのパラメーターに関する多くのチュートリアルも提供しています[IEETutorials]。
IANA has been assigned an Organizationally Unique Identifier (OUI) by the IEEE RA and an associated set of MAC addresses and other organizationally unique code points based on that OUI. This document specifies IANA considerations for the assignment of code points under that IANA OUI, including MAC addresses and protocol identifiers, 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 such code points conflicting with code points assigned for some deployed use. This document also discusses several other uses by the IETF of IEEE 802 code points, including IEEE 802 Connectivity Fault Management (CFM) code points [RFC7319] and IEEE 802 Link Local Discovery Protocol (LLDP) [IEEE802.1AB] Vendor-Specific TLV Sub-Types [RFC8520]. It also specifies Concise Binary Object Representation (CBOR) tags for MAC addresses and OUIs / Company Identifiers (CIDs).
IANAには、IEEE RAによって組織的に一意の識別子（OUI）が割り当てられ、そのOUIに基づいて関連するMACアドレスおよびその他の組織的に一意のコードポイントが割り当てられています。このドキュメントは、MACアドレスやプロトコル識別子を含むIANA OUIの下にあるコードポイントの割り当てに関するIANAの考慮事項を指定し、ドキュメントで使用するためのいくつかの値を提供します。[RFC2606]および[RFC5737]に記載されているように、ドキュメントと例のために予約された指定されたコード値を使用すると、展開された使用に割り当てられたコードポイントと競合するコードポイントから生じる紛争と混乱の可能性が減少します。このドキュメントでは、IEEE 802コードポイントのIETFによるIETFによる他のいくつかの使用についても説明します。これには、IEEE 802接続障害管理（CFM）コードポイント[RFC7319]およびIEEE 802リンクローカルディスカバリープロトコル（LLDP）[IEEE802.1AB]ベンダー特有のTLVサブサブサブサブサブ-Types [RFC8520]。また、MACアドレスとOUIS /会社識別子（CID）の簡潔なバイナリオブジェクト表現（CBOR）タグも指定します。
Descriptions herein of [IANA] policies and procedures are authoritative, but descriptions of IEEE registration policies, procedures, and standards are only informative; for authoritative IEEE information, consult the IEEE sources.
[IANA]のポリシーと手順のここでの説明は権威あるものですが、IEEE登録ポリシー、手順、および標準の説明は有益です。権威あるIEEE情報については、IEEEソースを参照してください。
[RFC8126] is incorporated herein except where there are contrary provisions in this document. In this document, "IESG Ratification", specified in Section 5.1, refers to a combination of Expert Review and IESG Approval as those are defined in [RFC8126], where IESG Approval is required only if the Expert does not reject the request. It is NOT the same as just "IESG Approval" in [RFC8126].
[RFC8126]は、本書に逆の規定がある場合を除き、本明細書に組み込まれています。このドキュメントでは、セクション5.1で指定されている「IESG批准」は、[RFC8126]で定義されている専門家のレビューとIESGの承認の組み合わせを指します。[RFC8126]の「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 ("network") bit ordering although the physical order of bit transmission within an octet on an IEEE [IEEE.802.3_2012] link is from the lowest order bit to the highest order bit (i.e., the reverse of the IETF's ordering).
このドキュメントでは、16進表記を使用しています。各オクテット（つまり、8ビットバイト）は、2つの16進数桁で表され、オクテットの値を符号なし整数として示します。連続したオクテットはハイフンによって分離されます。このドキュメントでは、IETF（ "Network"）ビットの順序付けを一貫して使用しますが、IEEE [IEEE.802.3_2012]リンクのオクテット内のビット伝送の物理的順序は、最低のビットから最高順序ビット（つまり、IETFの注文）。
In this document:
このドキュメントで：
"AFN"
「afn」
Address Family Number [RFC4760].
住所ファミリ番号[RFC4760]。
"CBOR"
「Cbor」
Concise Binary Object Representation [RFC8949].
簡潔なバイナリオブジェクト表現[RFC8949]。
"CFM"
「CFM」
Connectivity Fault Management [RFC7319].
接続障害管理[RFC7319]。
"CID"
「cid」
Company Identifier. See Section 2.1.2.
会社識別子。セクション2.1.2を参照してください。
"DSAP"
「DSAP」
Destination Service Access Point. See Section 3.
宛先サービスアクセスポイント。セクション3を参照してください。
"EUI"
「eui」
Extended Unique Identifier.
拡張された一意の識別子。
"EUI-48"
「EUI-48」
48-bit EUI
48ビットEUI
"IEEE"
「IEEE」
Institute of Electrical and Electronics Engineers [IEEE].
電気およびエレクトロニクスエンジニア研究所[IEEE]。
"IEEE 802"
「IEEE802」
The LAN/MAN Standards Committee [IEEE802].
LAN/MAN標準委員会[IEEE802]。
"IEEE RA"
「IEEERA」
IEEE Registration Authority [IEEE_RA].
IEEE登録機関[IEEE_RA]。
"IEEE SA"
「IEEESA」
IEEE Standards Association [IEEE_SA].
IEEE標準協会[IEEE_SA]。
"LLC"
「LLC」
Logical Link Control. The type of frame header where the protocol is identified by source and destination LSAP fields. See Section 3.
論理リンク制御。ソースおよび宛先LSAPフィールドによってプロトコルが識別されるフレームヘッダーのタイプ。セクション3を参照してください。
"LSAP"
「LSAP」
Link-Layer Service Access Point. See Section 3.
リンク層サービスアクセスポイント。セクション3を参照してください。
"MA-L"
「Ma-l」
MAC Address Block Large.
Macアドレスブロックは大きくなります。
"MA-M"
「ma-m」
MAC Address Block Medium.
MACアドレスブロックメディア。
"MA-S"
「ma-s」
MAC Address Block Small.
Macアドレスブロックは小さくなります。
"MAC"
"マック"
Media Access Control, not Message Authentication Code.
メッセージ認証コードではなく、メディアアクセス制御。
"MAC-48"
「Mac-48」
A 48-bit MAC address. This term is obsolete. If globally unique, use EUI-48.
48ビットMACアドレス。この用語は時代遅れです。グローバルに一意の場合は、EUI-48を使用してください。
"OUI"
「OUI」
Organizationally Unique Identifier. See Section 2.1.2.
組織的に一意の識別子。セクション2.1.2を参照してください。
"RRTYPE"
「rrtype」
A DNS Resource Record type [RFC6895].
DNSリソースレコードタイプ[RFC6895]。
"SLAP"
"平手打ち"
IEEE 802 Structured Local Address Plan [IEEE802_OandA]. See Section 2.1.1.
IEEE 802構造化されたローカルアドレスプラン[IEEE802_OANDA]。セクション2.1.1を参照してください。
"SNAP"
"スナップ"
Subnetwork Access Protocol. See Section 3.
サブネットワークアクセスプロトコル。セクション3を参照してください。
"SSAP"
「SSAP」
Source Service Access Point. See Section 3.
ソースサービスアクセスポイント。セクション3を参照してください。
"tag"
"鬼ごっこ"
"Tag" is used in two contexts in this document. For "Ethernet tag", see Section 3. For "CBOR tag", see Section 2.4.
「タグ」は、このドキュメントの2つのコンテキストで使用されます。「イーサネットタグ」については、セクション3を参照してください。「cborタグ」については、セクション2.4を参照してください。
"TLV"
「TLV」
Type-Length-Value.
タイプ長価値。
"**"
「**」
The double asterisk symbol indicates exponentiation. For example, 2**24 is two to the twenty-fourth power.
二重アスタリスク記号は、指数を示します。たとえば、2 ** 24は24番目の電力です。
Originally the responsibility of the Xerox Corporation, the registration authority for Ethernet parameters since 1986 has been the IEEE Registration Authority, available on the Web at [IEEE_RA].
もともとは、1986年以来のイーサネットパラメーターの登録機関であるXerox Corporationの責任であり、[IEEE_RA]のWebで入手可能なIEEE登録機関でした。
The IEEE Registration Authority operates under the direction of the IEEE Standards Association (IEEE SA) Board of Governors, with oversight by the IEEE Registration Authority Committee (IEEE RAC). The IEEE RAC is a committee of the Board of Governors.
IEEE登録局は、IEEE標準協会（IEEE SA）理事会の指示の下で運営されており、IEEE登録局委員会（IEEE RAC）による監視があります。IEEE RACは、知事委員会の委員会です。
Anyone may apply to that authority for parameter assignments. The IEEE Registration Authority may impose fees or other requirements but commonly waives fees for applications from standards development organizations. Lists of assignments and their holders are downloadable from the IEEE Registration Authority site.
誰でもパラメーターの割り当てをその権限に申請することができます。IEEE登録機関は、手数料またはその他の要件を課すことができますが、一般に標準開発組織からの申請の料金を放棄します。割り当てのリストとその所有者は、IEEE登録局のサイトからダウンロード可能です。
The Organizationally Unique Identifier (OUI) 00-00-5E has been assigned to IANA by the IEEE Registration Authority.
組織的に一意の識別子（OUI）00-00-5Eは、IEEE登録局によって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の下にドキュメントコードポイントがあります。
IEEE Std 802.1Q [IEEE.802.1Q_2014] allocates two blocks of 802 Connectivity Fault Management (CFM) code points to the IETF, one for CFM OpCodes and one for CFM TLV Types. For further information, see [RFC7319]. The IANA "Connectivity Fault Management (CFM) OAM IETF Parameters" registry has subregistries for these code points. This document does not further discuss these blocks of code points.
IEEE STD 802.1Q [IEEE.802.1Q_2014] 802接続障害管理（CFM）コードの2つのブロックをIETFに割り当てます。詳細については、[RFC7319]を参照してください。IANA「接続障害管理（CFM）OAM IETFパラメーター」レジストリには、これらのコードポイントのサブレジストリがあります。このドキュメントでは、コードポイントのこれらのブロックについてはさらに説明しません。
This section includes information summarized from [IEEE802_OandA] that is being provided for context. The definitive information, which prevails in case of any discrepancy, is in [IEEE802_OandA].
このセクションには、コンテキスト用に提供されている[IEEE802_OANDA]から要約された情報が含まれています。矛盾の場合に勝つ決定的な情報は、[IEEE802_OANDA]にあります。
Section 2.1 discusses 48-bit MAC identifiers, their relationship to OUIs and other prefixes, and assignment under the IANA OUI. Section 2.2 extends this to 64-bit identifiers. Section 2.3 discusses other IETF MAC identifier uses not under the IANA OUI. Section 2.4 specifies CBOR tags for MAC addresses and OUIs/CIDs.
セクション2.1では、48ビットのMAC識別子、OUISおよびその他のプレフィックスとの関係、およびIANA OUIに基づく割り当てについて説明します。セクション2.2では、これを64ビット識別子に拡張します。セクション2.3では、他のIETF MAC識別子がIANA OUIの下ではない使用について説明します。セクション2.4は、MACアドレスとOUIS/CIDのCBORタグを指定します。
Historical Note: [RAC_OUI] is an expired Internet-Draft that provides additional historic information on [IEEE802] registries.
歴史的なメモ：[RAC_OUI]は、[IEEE802]レジストリに関する追加の履歴情報を提供する期限切れのインターネットドラフトです。
48-bit MAC "addresses" are the most commonly used Ethernet interface identifiers. Those that are globally unique are also called EUI-48 identifiers (Extended Unique Identifier 48). An EUI-48 is structured into an initial prefix assigned by the IEEE Registration Authority and additional bits assigned by the prefix owner. As of 2024, there are three lengths of prefixes assigned, as shown in the table below; however, some prefix bits can have special meaning, as shown in Figure 1.
48ビットMAC「アドレス」は、最も一般的に使用されるイーサネットインターフェイス識別子です。グローバルに一意のものは、EUI-48識別子とも呼ばれます（拡張ユニークな識別子48）。EUI-48は、IEEE登録機関によって割り当てられた初期プレフィックスと、プレフィックス所有者によって割り当てられた追加ビットに構造化されます。2024年の時点で、下の表に示すように、3つの長さの接頭辞が割り当てられています。ただし、図1に示すように、一部のプレフィックスビットには特別な意味があります。
+=======================+======+=========================+
| Prefix Length in Bits | Name | Owner Supplied Bits for |
| | | 48-bit MAC Addresses |
+=======================+======+=========================+
| 24 | MA-L | 24 |
+-----------------------+------+-------------------------+
| 28 | MA-M | 20 |
+-----------------------+------+-------------------------+
| 36 | MA-S | 12 |
+-----------------------+------+-------------------------+
Table 1
The bottom (least significant) four bits of the first octet of the 6-octet 48-bit MAC have special meaning, as shown in Figure 1, and are referred to below as the M, X, Y, and Z bits.
図1に示すように、6-OCTET 48ビットMACの最初のオクテットの下（最も重要な）4ビットは特別な意味を持ち、以下にM、x、y、およびzビットと呼ばれます。
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| . . . . Z Y X M| . . . . . . . .| octets 0+1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| . . . . . . . .| . . . . . . . .| octets 2+3
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| . . . . . . . .| . . . . . . . .| octets 4+5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 1: 48-Bit MAC Address Structure
図1：48ビットMACアドレス構造
For global addresses, X = 0 and a MAC address begins with 3 octets or a larger initial prefix indicating the assignee of the block of MAC addresses. This prefix is followed by a sequence of additional octets so as to add up to the total MAC address length. For example, the IEEE assigns MAC Address Block Small (MA-S), where the first four and a half octets (36 bits) are assigned, giving the holder of the MA-S one and a half octets (12 bits) they can control in constructing 48-bit MAC addresses; other prefix lengths are also available [IEEEtutorials].
グローバルアドレスの場合、x = 0とMACアドレスは、MACアドレスのブロックの譲受人を示す3オクテットまたはより大きな初期プレフィックスで始まります。このプレフィックスの後に、合計MACアドレスの長さに合わせて追加のオクテットのシーケンスが続きます。たとえば、IEEEはMACアドレスブロックをsmall（ma-s）に割り当てます。ここでは、最初の4オクテット（36ビット）が割り当てられ、MA-Sのホルダーに1.5オクテット（12ビット）を与えます。48ビットMACアドレスの構築における制御。その他のプレフィックスの長さも利用できます[ieeTutorials]。
An AFN, a DNS RRTYPE, and a CBOR tag have been assigned for 48-bit MAC addresses, as discussed in Sections 2.4, 5.3, and 5.9.
セクション2.4、5.3、および5.9で説明するように、AFN、DNS RRTYPE、およびCBORタグが48ビットMACアドレスに割り当てられています。
IEEE Std 802 describes assignment procedures and policies for identifiers related to IEEE 802 [IEEE802_OandA]. IEEE RA documentation on EUIs, OUIs, and CIDs is available at [IEEEtutorials].
IEEE STD 802は、IEEE 802 [IEEE802_OANDA]に関連する識別子の割り当て手順とポリシーについて説明しています。EUIS、OUIS、およびCIDSに関するIEEE RAドキュメントは、[IEETutorials]で入手できます。
There are bits within the initial octet of an IEEE MAC address that have special significance [IEEE802_OandA], as described as follows:
次のように、特別な重要性[IEEE802_OANDA]を持つIEEE Macアドレスの最初のオクテット内にビットがあります。
M bit -
mビット -
This bit is frequently referred to as the "group" or "multicast" bit. If it is zero, the MAC address is unicast. If it is a one, the address is groupcast (multicast or broadcast). This meaning is independent of the values of the X, Y, and Z bits.
このビットは、頻繁に「グループ」または「マルチキャスト」ビットと呼ばれます。ゼロの場合、MACアドレスはユニキャストです。1つの場合、アドレスはグループキャスト（マルチキャストまたはブロードキャスト）です。この意味は、x、y、zビットの値に依存しません。
X bit -
xビット -
This bit is also called the "universal/local" bit (formerly called the Local/Global bit). If it is zero, the MAC address is a global address under the control of the owner of the IEEE-assigned prefix. Previously, if it was a one, the MAC address was considered "local" and under the assignment and control of the local network operator (but see Section 2.3). If it is a one and if the IEEE 802 Structured Local Address Plan (SLAP) is in effect, the nature of the MAC address is optionally determined by the Y and Z bits, as described below.
このビットは、「ユニバーサル/ローカル」ビット（以前はローカル/グローバルビットと呼ばれていた）とも呼ばれます。ゼロの場合、MACアドレスは、IEEEが割り当てられたプレフィックスの所有者の制御下にあるグローバルアドレスです。以前は、それが1つであった場合、MACアドレスは「ローカル」と見なされ、ローカルネットワークオペレーターの割り当てと制御の下にありました（ただし、セクション2.3を参照）。それが1つであり、IEEE 802構造化されたローカルアドレスプラン（SLAP）が有効な場合、MACアドレスの性質は、以下に説明するように、YおよびZビットによってオプションで決定されます。
Y&Z bits -
Y＆Zビット -
These two bits have no special meaning if the X bit is zero. If the X bit is one and if the IEEE 802 Structured Local Address Plan (SLAP) is in effect, these two bits divide the formerly uniform "local" MAC address space into four quadrants as follows and further described below:
これらの2つのビットには、xビットがゼロの場合、特別な意味はありません。Xビットが1つであり、IEEE 802構造化ローカルアドレスプラン（SLAP）が有効な場合、これらの2つのビットは、以前の均一な「ローカル」MACアドレススペースを次のように4つの象限に分割し、さらに説明します。
+=======+=======+===========================+
| Y bit | Z bit | Quadrant |
+=======+=======+===========================+
| 0 | 0 | Administratively Assigned |
+-------+-------+---------------------------+
| 0 | 1 | Extended Local |
+-------+-------+---------------------------+
| 1 | 0 | Reserved |
+-------+-------+---------------------------+
| 1 | 1 | Standard Assigned |
+-------+-------+---------------------------+
Table 2
While a local network administrator can assign any addresses with the X bit a one, the optional SLAP characterizes the four quadrants of the "local" address space using the Y and Z bits as follows:
ローカルネットワーク管理者は、xビットAのアドレスを1つに割り当てることができますが、オプションのスラップは、次のようにyとzビットを使用して「ローカル」アドレス空間の4つの象限を特徴付けます。
Administratively Assigned -
管理上割り当て -
MAC addresses in this quadrant are called Administratively Assigned Identifiers. This is intended for arbitrary local assignment, such as random assignment; however, see Section 2.3.1.
この象限のMACアドレスは、管理上割り当てられた識別子と呼ばれます。これは、ランダム割り当てなどの任意のローカル割り当てを目的としています。ただし、セクション2.3.1を参照してください。
Extended Local -
拡張ローカル -
MAC addresses in this quadrant are called Extended Local Identifiers. These addresses are not actually "local" under SLAP. They are available to the organization that has been assigned the CID (see Section 2.1.2) specifying the other 20 bits of the 24-bit prefix with X, Y, and Z bits having the values 1, 0, and 1, respectively.
この象限のMACアドレスは、拡張ローカル識別子と呼ばれます。これらのアドレスは、実際にはスラップ下で「ローカル」ではありません。それらは、それぞれ値1、0、および1を持つx、y、およびzビットの24ビットプレフィックスの他の20ビットを指定するCID（セクション2.1.2を参照）をそれぞれ割り当てられた組織で利用できます。
Reserved -
予約済み -
MAC addresses in this quadrant are reserved for future use under the SLAP. Until such future use, they could be locally assigned as Administratively Assigned Identifiers are assigned, but there is a danger that future SLAP use would conflict with such local assignments.
この象限のMACアドレスは、平手打ちの下で将来使用するために予約されています。そのような将来の使用まで、それらは管理上割り当てられた識別子が割り当てられているためにローカルに割り当てることができますが、将来の平手打ちがそのようなローカル割り当てと矛盾する危険があります。
Standard Assigned -
標準割り当て -
MAC addresses in this quadrant are called Standard Assigned Identifiers (SAIs). An SAI is assigned by a protocol specified in an IEEE 802 standard, for example, [IEEE802.1CQ] (but see the first NOTE below).
この象限のMACアドレスは、標準割り当て識別子（SAI）と呼ばれます。SAIは、たとえば[IEEE802.1CQ]など、IEEE 802標準で指定されたプロトコルによって割り当てられます（ただし、以下の最初の注を参照）。
NOTE: While the SLAP has MAC addresses assigned through a local protocol in the SAI quadrant and assigned by a protocol specified in an IEEE 802 standard, the SLAP is optional. Local network administrators may use the IETF protocol provisions in [RFC8947] and [RFC8948], which support assignment of a MAC address in the local MAC address space using DHCPv6 [RFC8415] or other protocol methods.
注：SLAPには、SAI象限のローカルプロトコルを介してMACアドレスが割り当てられ、IEEE 802標準で指定されたプロトコルによって割り当てられていますが、スラップはオプションです。ローカルネットワーク管理者は、[RFC8947]および[RFC8948]のIETFプロトコル規定を使用する場合があります。これは、DHCPV6 [RFC8415]またはその他のプロトコルメソッドを使用して、ローカルMACアドレス空間でMACアドレスの割り当てをサポートします。
NOTE: There isn't any automated way to determine if or to what extent a local network is configured for and/or operating according to SLAP.
注：SLAPに従ってローカルネットワークがどの程度構成および/または動作するかを判断する自動化された方法はありません。
MA-L, MA-M, and MA-S MAC prefixes are assigned with the Local bit zero. The assignee of an OUI is exclusively authorized to assign group MAC addresses by extending a modified version of the assigned OUI in which the M bit (see Figure 1) is set to 1 [IEEEtutorials].
MA-L、MA-M、およびMA-S MACプレフィックスには、ローカルビットゼロが割り当てられています。OUIの譲受人は、Mビット（図1を参照）が1 [IEETutorials]に設定されている割り当てられたOUIの変更されたバージョンを拡張することにより、グループMACアドレスを割り当てることのみが許可されています。
The Local bit is zero for globally unique EUI-48 identifiers assigned by the owner of a MAC-L or owner of a longer prefix. If the Local bit is a one, the identifier has historically been a local identifier under the control of the local network administrator; however, there are now recommendations on optional management of the local address space, as discussed in Section 2.1.1. If the Local bit is a one, the holder of an OUI has no special authority over MAC identifiers whose first 3 octets correspond to their OUI or the beginning of their longer prefix.
ローカルビットは、MAC-Lの所有者または長いプレフィックスの所有者によって割り当てられたグローバルに一意のEUI-48識別子の場合はゼロです。ローカルビットが1つの場合、識別子は歴史的にローカルネットワーク管理者の制御下にあるローカル識別子でした。ただし、セクション2.1.1で説明したように、ローカルアドレススペースのオプション管理に関する推奨事項があります。ローカルビットが1つの場合、OUIの所有者には、最初の3つのオクテットがOUIまたは長いプレフィックスの開始に対応するMac識別子に対する特別な権限はありません。
A CID is a 24-bit Company Identifier. It is assigned for organizations that need such an identifier that can be used in place of an OUI but do not need to assign subsidiary global MAC addresses. A CID has X and Z bits equal to 1 and its Y bit equal to 0 (see Figure 1).
CIDは24ビットの会社識別子です。これは、OUIの代わりに使用できるが、子会社のグローバルMACアドレスを割り当てる必要はないこのような識別子を必要とする組織に割り当てられています。CIDにはxビットとzビットが1に等しく、yビットは0に等しい（図1を参照）。
An AFN and a CBOR tag have been assigned for OUIs/CIDs, as discussed in Sections 2.4, 5.3, and 5.9.
セクション2.4、5.3、および5.9で説明したように、AFNとCBORタグがOUIS/CIDに割り当てられています。
The OUI 00-00-5E has been assigned to IANA, as stated in Section 1.3 above. This includes 2**24 48-bit 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.3に記載されているように、OUI 00-00-5EはIANAに割り当てられています。これには、01-00-5E-00-00-00-00から01-00-5E-FF-FF-FF-24 EUI-48ユニキャスト識別子から01-00-5E-00-00-00から01-00-5E-FF-FF-FF-24の2*48ビットマルチキャスト識別子が含まれます。5e-00-00-00〜00-00-5e-ff-ff-ff。
Of these identifiers, the sub-blocks reserved or thus far assigned are as follows:
これらの識別子のうち、サブブロックは予約されているか、これまでに割り当てられているのは次のとおりです。
Unicast, all blocks of 2**8 addresses thus far:
ユニキャスト、これまでの2 ** 8アドレスのすべてのブロック：
00-00-5E-00-00-00 through 00-00-5E-00-00-FF:
00-00-5E-00-00-00から00-00-5E-00-00-FF：
reserved and require IESG Ratification for assignment (see Section 5.1).
予約され、割り当てのためにIESG批准が必要です（セクション5.1を参照）。
00-00-5E-00-01-00 through 00-00-5E-00-01-FF:
00-00-5E-00-01-00から00-00-5E-00-01-FF：
assigned for the Virtual Router Redundancy Protocol (VRRP) [RFC5798].
仮想ルーター冗長プロトコル（VRRP）[RFC5798]に割り当てられています。
00-00-5E-00-02-00 through 00-00-5E-00-02-FF:
00-00-5E-00-02-00から00-00-5E-00-02-FF：
assigned for the IPv6 Virtual Router Redundancy Protocol (IPv6 VRRP) [RFC5798].
IPv6仮想ルーター冗長プロトコル（IPV6 VRRP）[RFC5798]に割り当てられています。
00-00-5E-00-52-00 through 00-00-5E-00-52-FF:
00-00-5E-00-52-00から00-00-5E-00-52-FF：
used for very small assignments. As of 2024, 4 out of these 256 values have been assigned. See [EthernetNum].
非常に小さな割り当てに使用されます。2024年現在、これら256の値のうち4つが割り当てられています。[ethernetnum]を参照してください。
00-00-5E-00-53-00 through 00-00-5E-00-53-FF:
00-00-5E-00-53-00から00-00-5E-00-53-FF：
assigned for use in documentation by this document.
このドキュメントによるドキュメントで使用するために割り当てられています。
00-00-5E-90-01-00 through 00-00-5E-90-01-FF:
00-00-5E-90-01-00から00-00-5E-90-01-FF：
used for very small assignments that need parallel unicast and multicast MAC addresses. As of 2024, 1 out of these 256 values has been assigned. See [EthernetNum].
並列ユニキャストとマルチキャストMACアドレスを必要とする非常に小さな割り当てに使用されます。2024年の時点で、これら256の値のうち1つが割り当てられています。[ethernetnum]を参照してください。
Multicast:
マルチキャスト：
01-00-5E-00-00-00 through 01-00-5E-7F-FF-FF:
01-00-5E-00-00-00から01-00-5E-7F-FF-FF：
2**23 addresses assigned for IPv4 multicast [RFC1112].
2 ** 23 IPv4マルチキャストに割り当てられたアドレス[RFC1112]。
01-00-5E-80-00-00 through 01-00-5E-8F-FF-FF:
01-00-5E-80-00-00から01-00-5E-8F-FF-FF：
2**20 addresses assigned for MPLS multicast [RFC5332].
2 ** MPLSマルチキャストに割り当てられた20アドレス[RFC5332]。
01-00-5E-90-00-00 through 01-00-5E-90-00-FF:
01-00-5E-90-00-00から01-00-5E-90-00-FF：
2**8 addresses being used for very small assignments. As of 2024, 4 out of these 256 values have been assigned. See [EthernetNum].
2 ** 8アドレスは、非常に小さな割り当てに使用されています。2024年現在、これら256の値のうち4つが割り当てられています。[ethernetnum]を参照してください。
01-00-5E-90-01-00 through 01-00-5E-90-01-FF:
01-00-5E-90-01-00から01-00-5E-90-01-FF：
used for very small assignments that need parallel unicast and multicast MAC addresses. As of 2024, 1 out of these 256 values has been assigned. See [EthernetNum].
並列ユニキャストとマルチキャストMACアドレスを必要とする非常に小さな割り当てに使用されます。2024年の時点で、これら256の値のうち1つが割り当てられています。[ethernetnum]を参照してください。
01-00-5E-90-10-00 through 01-00-5E-90-10-FF:
01-00-5E-90-10-00から01-00-5E-90-10-FF：
2**8 addresses assigned for use in documentation by this document.
2 ** 8このドキュメントによるドキュメントで使用するために割り当てられたアドレス。
For more detailed and up-to-date information, see the "IANA OUI Ethernet Numbers" registry at [EthernetNum].
より詳細かつ最新の情報については、[EthernetNum]の「IANA OUIイーサネット番号」レジストリを参照してください。
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 UNICASTおよび
* 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。
48-bit assignments under the current or a future IANA OUI (see Section 5.6) must meet the following requirements:
現在または将来のIANA OUI（セクション5.6を参照）に基づく48ビットの割り当ては、次の要件を満たす必要があります。
* must be for standards purposes (either for an IETF Standard or other standard related to IETF work),
* 標準目的でなければなりません（IETF標準またはIETF作業に関連するその他の標準のいずれか）、
* must be for a power-of-two-sized block of identifiers starting at a boundary that is an equal or greater power of two, including the assignment of one (2**0) identifier,
* 1つの（2 ** 0）識別子の割り当てを含む、2つの等しいまたはより大きなパワーである境界から始まる2つの2つのサイズの識別子ブロック用でなければなりません。
* must not be used to evade the requirement for network interface vendors to obtain their own block of identifiers from the IEEE, and
* ネットワークインターフェイスベンダーがIEEEから識別子の独自のブロックを取得する要件を回避するために使用してはなりません。
* must be documented in an Internet-Draft or RFC.
* インターネットドラフトまたは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を参照）。
IEEE also defines a system of 64-bit MAC identifiers, including EUI-64s. EUI-64 identifiers are used as follows:
IEEEは、EUI-64を含む64ビットMAC識別子のシステムも定義しています。EUI-64識別子は次のように使用されます。
* In IEEE Std 1394 [IEEE1394] (also known as FireWire and i.Link)
* IEEE STD 1394 [IEEE1394]（FirewireおよびI.Linkとしても知られています）
* In IEEE Std 802.15.4 [IEEE802.15.4] (also known as Zigbee)
* IEEE STD 802.15.4 [IEEE802.15.4]（Zigbeeとしても知られています）
* In [InfiniBand]
* [infiniband]で
* In a modified form to construct some IPv6 Interface Identifiers, as described in Section 2.2.1, although this use is now deprecated
* セクション2.2.1で説明されているように、いくつかのIPv6インターフェイス識別子を構築するための変更された形式で、この使用は現在廃止されましたが
Adding a 5-octet (40-bit) extension to a 3-octet (24-bit) assignment, 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 special low-order bits.
5-OCTET（40ビット）の拡張機能を3オクテット（24ビット）割り当てに追加するか、合計64ビットに関しては、より長い割り当てられたプレフィックス[RAC_OUI]に短い拡張機能を追加すると、そのOUIの下でEUI-64識別子が生成されます。または長いプレフィックス。EUI-48識別子と同様に、最初のオクテットには同じ特別な低次ビットがあります。
An AFN, a DNS RRTYPE, and CBOR tag have been assigned for 64-bit MAC addresses, as discussed in Sections 2.4, 5.3, and 5.9.
セクション2.4、5.3、および5.9で説明するように、AFN、DNS RRTYPE、およびCBORタグが64ビットMACアドレスに割り当てられています。
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識別子として使用することもできます。
The approach described below for constructing IPv6 Interface Identifiers is now deprecated, and the method specified in [RFC8064] is recommended.
IPv6インターフェイス識別子を構築するための以下で説明するアプローチが非推奨になり、[RFC8064]で指定された方法が推奨されます。
EUI-64 identifiers have been 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 EUI-64 is modified by inverting the X (universal/local) 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.
EUI-64の識別子は、一部のIPv6アドレスの64ビットを形成するために使用されています（[RFC4291]のセクション2.5.1および[RFC5214]の付録A）。そのように使用すると、EUI-64はX（ユニバーサル/ローカル）ビットを反転させることにより変更され、IETF「修正されたEUI-64識別子」を形成します。以下は、AA-BB-CC-DD-EEが拡張機能であるIANA OUIの下にある修正されたEUI-64ユニキャスト識別子の図です。
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 X bit is inverted compared with EUI-48 identifiers. It is the globally unique values (universal scope) that have the 0x02 bit (also known as the X or universal/local bit) on in the first octet, while those with this bit off are typically locally assigned and out of scope for global assignment.
修正されたEUI-64識別子では、xビットの感覚がEUI-48識別子と比較して反転されるため、最初のオクテットは00ではなく02として表示されます。最初のオクテットでは0x02ビット（xまたはユニバーサル/ローカルビットとも呼ばれる）があるのは、グローバルに一意の値（ユニバーサルスコープ）であり、このビットのあるものは通常、局所的に割り当てられ、グローバルな割り当てのために範囲外です。
The X (universal/local) 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.
X（Universal/Local）ビットは、ネットワークオペレーターがローカルスコープ識別子を簡単に入力できるようにするために反転しました。したがって、このような変更されたEUI-64識別子は1、2など（主要なゼロを無視する）はローカルです。変更がなければ、彼らは02-00-00-00-00-00-01、02-00-00-00-00-00-00-02などでなければなりません。
As with 48-bit MAC identifiers, the M bit (0x01) on in the first octet indicates a group identifier (multicast or broadcast).
48ビットMACの識別子と同様に、最初のオクテットのMビット（0x01）は、グループ識別子（マルチキャストまたはブロードキャスト）を示します。
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識別子の拡張の最初の2オクテットがFF-FEである場合、EUI-48のOUI所有者によって割り当てられた拡張の残りは24ビット値です。例えば：
02-00-5E-FF-FE-yy-yy-yy
02-00-5e-ff-fe-yyyyy
or
または又はそれとも若しくは乃至或るいは
03-00-5E-FF-FE-yy-yy-yy
03-00-5e-ff-fe-yyyyy
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 universal/local bit.
ここで、yy-yy-yyは（eui-48グローバルユニキャストまたはマルチキャスト識別子の部分の部分です。したがって、IANA OUIの下にある1つまたは複数のEUI-48識別子の保有者は、EUI-48識別子の中央にFF-FEを挿入し、ユニバーサル/を反転させることで形成できる等しい修正EUI-64識別子も持っています。ローカルビット。
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 a 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-FE-FF-FF-FF-FF
are effectively reserved pending the specification of IPv4 "Class E" addresses [RFC1112]. However, for Modified EUI-64 identifiers based on an IPv4 address, the universal/local 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 universal/local bit is reversed from that in (unmodified) EUI-64 identifiers.)
IPv4「クラスE」アドレスの仕様[RFC1112]の仕様が保留されているため、効果的に予約されています。ただし、IPv4アドレスに基づいた修正されたEUI-64識別子の場合、Universal/Local Bitは、IPv4アドレスがローカルかグローバルかに対応するように設定する必要があります。（修正されたEUI-64識別子ユニバーサル/ローカルビットの感覚は、（変更されていない）EUI-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. These values are prefixed with 02-00-5E to form unicast modified EUI-64 addresses.
次の表は、IANA OUIの下でどの修正されたEUI-64識別子が予約、割り当て、または説明されているように利用可能であるかを示しています。上記のように、対応するMACアドレスは、最初のオクテットの02ビットを補完することで決定できます。すべての場合において、最初のオクテットの01ビットを補完することによって形成される対応するマルチキャスト64ビットMACアドレスは、以下にリストされている修正された64ビットユニキャストアドレスブロックと同じステータスを持っています。これらの値には02-00-5Eが付いており、ユニキャスト修正EUI-64アドレスを形成します。
+==================================+===================+===========+
| Addresses | Usage | Reference |
+==================================+===================+===========+
| 00-00-00-00-00 to 0F-FF-FF-FF-FF | Reserved | RFC 9542 |
+----------------------------------+-------------------+-----------+
| 10-00-00-00-00 to 10-00-00-00-FF | Documentation | RFC 9542 |
+----------------------------------+-------------------+-----------+
| 10-00-00-01-00 to EF-FF-FF-FF-FF | Unassigned | |
+----------------------------------+-------------------+-----------+
| FD-00-00-00-00 to FD-FF-FF-FF-FF | Reserved | RFC 9542 |
+----------------------------------+-------------------+-----------+
| FE-00-00-00-00 to FE-FF-FF-FF-FF | IPv4 Addr Holders | RFC 9542 |
+----------------------------------+-------------------+-----------+
| FF-00-00-00-00 to FF-FD-FF-FF-FF | Reserved | RFC 9542 |
+----------------------------------+-------------------+-----------+
| FF-FE-00-00-00 to FF-FE-FF-FF-FF | IANA EUI-48 | RFC 9542 |
| | Holders | |
+----------------------------------+-------------------+-----------+
| FF-FF-00-00-00 to FF-FF-FF-FF-FF | Reserved | RFC 9542 |
+----------------------------------+-------------------+-----------+
Table 3: IANA 64-bit MAC Addresses
表3：IANA 64ビットMACアドレス
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 EUI-64 INA OUIの下での識別子の割り当ては、次の要件を満たす必要があります。
* must be for standards purposes (either for an IETF Standard or other standard related to IETF work),
* 標準目的でなければなりません（IETF標準またはIETF作業に関連するその他の標準のいずれか）、
* must be for a power-of-two-sized block of identifiers starting at a boundary that is an equal or greater power of two, including the assignment of one (2**0) identifier,
* 1つの（2 ** 0）識別子の割り当てを含む、2つの等しいまたはより大きなパワーである境界から始まる2つの2つのサイズの識別子ブロック用でなければなりません。
* must not be used to evade the requirement for network interface vendors to obtain their own block of identifiers from the IEEE, and
* ネットワークインターフェイスベンダーがIEEEから識別子の独自のブロックを取得する要件を回避するために使用してはなりません。
* must be documented in an Internet-Draft or RFC.
* インターネットドラフトまたは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の1、2、4、...、134217728、268435456の小規模な割り当て）EUI-64識別子には、専門家のレビューが必要です（セクション5.1を参照）。
* Large assignments of 536870912 (2**29) or more EUI-64 identifiers require 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 values for documentation use:
ドキュメントの使用のユニキャスト値：
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-FF General
00-00-5E-FE-C0-00-02-00 to 00-00-5E-FE-C0-00-02-FF and 00-00-5E-FE-C6-33-64-00 to 00-00-5E-FE-C6-33-64-FF and 00-00-5E-FE-CB-00-71-00 to 00-00-5E-FE-CB-00-71-FF IPv4 derived
00-00-5E-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 IPv4派生
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-FFEUI-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-FE-FE-FE-C6-33-64および00-00-5E-FE-CB-00-71 IPv4マルチキャスト派生IPv4ユニキャストから[RFC6034]
Multicast values for documentation use:
ドキュメント使用のマルチキャスト値：
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-00〜01-00-5E-EF-10-00-FF General
01-00-5E-FE-C0-00-02-00 to 01-00-5E-FE-C0-00-02-FF and 01-00-5E-FE-C6-33-64-00 to 01-00-5E-FE-C6-33-64-FF and 01-00-5E-FE-CB-00-71-00 to 01-00-5E-FE-CB-00-71-FF IPv4 derived
01-00-5E-FE-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 IPv4派生
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-FE-FE-C6-33-64および01-00-FE-FE-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 48-bit MAC identifiers that are used by the IETF as described below.
以下で説明するように、IETFで使用される48ビットMAC識別子の他の2つのブロックがあります。
All 48-bit multicast MAC identifiers prefixed with "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 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, but any Ethernet using standard IPv6 multicast should note that these addresses will be used for that purpose. These multicast MAC addresses fall into the Administratively Assigned SLAP quadrant (see Section 2.1.1).
「33-33」が付いた48ビットマルチキャストMAC識別子すべて（つまり、33-33-00-00-00-00-00から33-33-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FFFの範囲の2 ** 32マルチキャストMAC識別子です。FF-FF）は、IPv6マルチキャストの[RFC2464]で指定されているように使用されます。これらのすべての識別子では、既存のハードウェアをマルチキャスト識別子として適切に作業するために必要なグループビット（最初のオクテットの下部ビット）がオンになっています。また、ローカルビットがありますが、標準のIPv6マルチキャストを使用するイーサネットは、これらのアドレスがその目的に使用されることに注意する必要があります。これらのマルチキャストMACアドレスは、管理上割り当てられたスラップ象限に分類されます（セクション2.1.1を参照）。
Historical Notes: 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 [IEEE.802.3_2012] Ethernet protocol has sometimes been known as "DIX" Ethernet from the first letters of the names of these companies.
歴史的なメモ：IPv6設計中は、不明または例の値に「3」を使用することが習慣でした。カリフォルニア州パロアルトの3333 Coyote Hill Roadは、以前は「Xerox Parc」であるPARC（Palo Alto Research Center）の住所です。イーサネットはもともと、Digital Equipment Corporation、Intel Corporation、およびXerox Corporationによって指定されていました。Pre-IEEE [IEEE.802.3_2012]イーサネットプロトコルは、これらの企業の名前の最初の文字から「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. When used as 48-bit MAC prefixes, these values have all of the Z, Y, X (Local) and M (Group) special bits at the bottom of the first octet equal to one, while all IEEE-assigned OUIs thus far have the X and M bits as zero and all CIDs have the Y and M bits as zero; thus, there can be no conflict between CF series "OUIs" and IEEE-assigned OUIs/CIDs. Multicast MAC addresses constructed with a CF series OUI would fall into the Standard Assigned SLAP quadrant (see Section 2.1.1). 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." (For further information on Network Layer Protocol Identifiers (NLPIDs), see [RFC6328].)
情報[RFC2153]は、CF-00-00からCF-FF-FFの3オクテット値を、PPPで使用するためのソフトウェアベンダーへのIANAによる割り当て[RFC1661]またはベンダーが使用する他の用途での「OUIS」と宣言したと宣言しました。それ以外の場合は、IEEEが割り当てられたOUIが必要ではありません。48ビットMACプレフィックスとして使用する場合、これらの値は、最初のオクテットの下部にあるz、y、x（ローカル）、およびm（グループ）のすべての特別ビットを1つに等しくしますが、これまでにすべてのIEEEが割り当てたすべてのOUIはゼロとしてのXおよびMビットとすべてのCIDには、YおよびMビットがゼロです。したがって、CFシリーズ「OUIS」とIEEEが割り当てたOUIS/CIDの間に矛盾はありません。CFシリーズOUIで構築されたマルチキャストMACアドレスは、標準の割り当てられたスラップ象限に分類されます（セクション2.1.1を参照）。グループビットはPPPで意味がありません。[RFC2153]を引用するために、「「CF0000」シリーズは、ニーモニックな利便性の問題として、PPP NLPID「CF」と一致するように任意に選択されました。」（ネットワークレイヤープロトコル識別子（NLPIDS）の詳細については、[RFC6328]を参照してください。）
CF-00-00 is reserved. CF-00-00-00-00-00 is a multicast identifier listed by IANA as used for Ethernet loopback tests.
CF-00-00は予約されています。CF-00-00-00-00-00は、イーサネットループバックテストに使用されるIANAによってリストされたマルチキャスト識別子です。
In over a decade of availability, only a handful of values in the CF series have been assigned. (See the "IANA OUI Ethernet Numbers" [EthernetNum] and "Point-to-Point (PPP) Protocol Field Assignments" [PPPNum] registry groups.)
10年以上の可用性で、CFシリーズのほんの一握りの値のみが割り当てられています。（「IANA OUI Ethernet Numbers」[EthernetNum]および「Point-to-Point（PPP）プロトコルフィールド割り当て」[PPPNUM]レジストリグループを参照してください。）
The IANA Considerations in [RFC2153] were updated as follows by the approval of [RFC5342] and remain so updated (no technical changes have been made):
[RFC2153]のIANAの考慮事項は、[RFC5342]の承認により次のように更新され、ままで更新されたままです（技術的な変更は行われていません）。
* Use of these CF series identifiers based on IANA assignment was deprecated.
* IANAの割り当てに基づいたこれらのCFシリーズ識別子の使用は非推奨されました。
* IANA was instructed not to assign any further values in the CF series.
* IANAは、CFシリーズにそれ以上の値を割り当てないように指示されました。
The Concise Binary Object Representation (CBOR) [RFC8949] is a data format whose design goals include the possibility of very small code size, fairly small message size, and extensibility. In CBOR, a data item can be enclosed by a CBOR tag to give it some additional semantics identified by that tag. CBOR-tagged data items (fields) are not used in actual IEEE 802 address fields but may be used in CBOR-encoded parts of protocol messages.
簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]は、デザイン目標に非常に小さなコードサイズ、かなり小さなメッセージサイズ、拡張性の可能性を含むデータ形式です。CBORでは、データ項目をCBORタグで同封して、そのタグによって識別された追加のセマンティクスを提供できます。Cborタグ付きデータ項目（フィールド）は、実際のIEEE 802アドレスフィールドでは使用されませんが、プロトコルメッセージのCborエンコード部分で使用できます。
IANA has assigned 48 as the CBOR tag to indicate a MAC address. The enclosed data item is an octet string. The length of the octet string indicates whether a 48-bit (6 octet) or 64-bit (8 octet) MAC address is encoded. Should some other multiple of 8 bits be used in the future for the length of MAC addresses, such as a 128-bit (16-octet) MAC address, the 48 tag will be used.
IANAは、MACアドレスを示すためにCBORタグとして48を割り当てました。囲まれたデータ項目はオクテット文字列です。Octet文字列の長さは、48ビット（6オクテット）または64ビット（8オクテット）MACアドレスがエンコードされているかどうかを示します。128ビット（16-OCTET）MACアドレスなどのMACアドレスの長さに将来、8ビットの他の倍数が使用された場合、48タグが使用されます。
IANA has assigned 1048 as the CBOR tag to indicate an OUI, CID, or CF series organizational identifier. The enclosed data item is an octet string of length 3 to hold the 24-bit OUI or CID (see Section 2.1.2).
IANAは1048をCBORタグとして割り当てて、OUI、CID、またはCFシリーズの組織識別子を示すことを示しています。囲まれたデータ項目は、24ビットOUIまたはCIDを保持する長さ3のオクテット文字列です（セクション2.1.2を参照）。
Ethernet protocol parameters provide a means of indicating, near the beginning of a frame, the contents of that frame -- for example, that it contains IPv4 or IPv6.
イーサネットプロトコルパラメーターは、フレームの開始近くで、そのフレームの内容を示す手段を提供します。たとえば、IPv4またはIPv6が含まれていることを示しています。
There are two types of protocol identifier parameters (see [EthernetNum]) that can occur in Ethernet frames:
イーサネットフレームで発生する可能性のあるプロトコル識別子パラメーターには2つのタイプがあります（[EthernetNum]を参照）。
EtherTypes:
ETHERTYPES：
These are 16-bit identifiers that, when considered as an unsigned integer, are equal to or larger than 0x0600. Figure 2 shows the simplest case where the EtherType of the protocol data in the frame appears immediately after the destination and source MAC addresses. [IEEE802_OandA] specifies two EtherTypes for local, experimental use: 0x88B5 and 0x88B6.
これらは、署名されていない整数と見なされる場合、0x0600以上である16ビット識別子です。図2は、フレーム内のプロトコルデータのETHERTYPEが宛先とソースMACアドレスの直後に表示される最も単純なケースを示しています。[IEEE802_OANDA]は、局所的な実験的使用のための2つの倫理を指定します：0x88B5および0x88B6。
LSAPs:
lsaps：
These are 8-bit protocol identifiers that occur in pairs after a field that gives the frame length. Such a length must, when considered as an unsigned integer, be less than 0x5DD, or it could be mistaken as an EtherType. However, the LLC encapsulation EtherType 0x8870 [IEEE802.1AC] may also be used in place of such a length as a "length indication" of nonspecific length. LSAPs occur in pairs, where one is intended to indicate the source protocol handler (SSAP) and the other the destination protocol handler (DSAP); however, use cases where the two are different have been relatively rare. See Figure 3 for the simplest case where the length field appears immediately after the destination and source MAC addresses. In that figure, the CTL (control) field value of 3 indicates datagram service. This type of protocol identification is sometimes called "LLC" (Logical Link Control).
これらは、フレームの長さを与えるフィールドの後にペアで発生する8ビットプロトコル識別子です。このような長さは、署名されていない整数と見なされる場合は、0x5DD未満であるか、ethertypeと誤解される可能性があります。ただし、LLCカプセル化EtherType 0x8870 [IEEE802.1AC]は、非特異的長さの「長さの表示」のような長さの代わりに使用することもできます。LSAPはペアで発生し、1つはソースプロトコルハンドラー（SSAP）を示し、もう1つは宛先プロトコルハンドラー（DSAP）を示します。ただし、2つが異なるユースケースは比較的まれです。宛先とソースMACアドレスの直後に長さフィールドが表示される最も単純なケースについては、図3を参照してください。その図では、3のCTL（コントロール）フィールド値はデータグラムサービスを示します。このタイプのプロトコル識別は、「LLC」（論理リンクコントロール）と呼ばれることもあります。
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Destination MAC Address ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Source MAC Address ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EtherType, greater than or equal to 0x0600 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Protocol Data ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2: EtherType Frame Protocol Labeling
図2：EtherTypeフレームプロトコルラベル付け
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Destination MAC Address ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Source MAC Address ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Frame length (or 0x8870) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSAP | SSAP |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CTL = 0x03 | Protocol Data ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: LSAP Frame Protocol Labeling
図3：LSAPフレームプロトコルラベル付け
The concept of EtherType labeling has been extended to labeling by Ethernet "tags". An Ethernet 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 LLC Link-Layer Service Access Point (LSAP) protocol indicator for the "main" body of the frame. Customarily, in the world of [IEEE802_OandA], tags are a fixed length and do not include any encoding of their own length. An example is the C-Tag (formerly the Q-Tag) [IEEE.802.1Q_2014]. It provides customer VLAN and priority information for a frame. Any device that is processing a frame cannot, in general, safely process anything in the frame past an EtherType it does not understand.
EtherTypeラベル付けの概念は、イーサネット「タグ」による標識に拡張されています。この意味でのイーサネットタグは、そのタイプがetherTypeによって識別されるプレフィックスであり、その後、別のタグ、EtherType、またはLLC Link-Layer Service Access Point（LSAP）プロトコルインジケーターのいずれかが続いています。フレーム。慣習的には、[IEEE802_Oanda]の世界では、タグは固定された長さであり、独自の長さのエンコードは含まれません。例は、Cタグ（以前はQ-TAG）[IEEE.802.1Q_2014]です。顧客VLANとフレームの優先情報を提供します。フレームを処理しているデバイスは、一般に、理解できないetertypeを過ぎてフレーム内のものを安全に処理することはできません。
Neither EtherTypes nor LSAPs are assigned by IANA; they are assigned by the IEEE Registration Authority [IEEE_RA] (see Section 1.2 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.
EtherTypesもLSAPもIANAによって割り当てられていません。それらは、IEEE登録機関[IEEE_RA]によって割り当てられています（セクション1.2および付録Bを参照）。ただし、LSAPとEthertypesの両方に拡張メカニズムがあるため、IANA OUIの下でIANAによって割り当てられたものを含む、OUIの下で5オクテットのイーサネットプロトコル識別子で使用できます。
When using the IEEE 802 Logical Link Control (LLC) format (Subnetwork Access Protocol (SNAP)) [IEEE802_OandA] for a frame, an OUI-based protocol identifier can be expressed as follows:
IEEE 802 Logical Link Control（LLC）形式（Subnetwork Access Protocol（SNAP））[IEEE802_Oanda]を使用する場合、FREAGEの場合、OUIベースのプロトコル識別子は次のように表現できます。
xx-xx-AA-AA-03-yy-yy-yy-zz-zz
xx-xx-aa-aa-03-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 (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, assigned by the OUI owner. The five-octet length for such OUI-based protocol identifiers results, with the LLC control octet ("0x03"), in the preservation of 16-bit alignment.
ここで、XX-XXはフレームの長さであり、上記のように、EtherTypeと混同しないように十分に小さくなければなりません。「AA」は、この使用を示すLSAPであり、SNAPサービスアクセスポイント（SNAP SAP）と呼ばれることもあります。「03」は、データグラムサービスを示すLLCコントロールオクテットです。YY-YY-YYはOUIです。ZZ-ZZは、OUI所有者によって割り当てられたそのOUIの下で、プロトコル番号です。このようなOUIベースのプロトコル識別子の5オクテットの長さは、16ビットアライメントの保存におけるLLCコントロールオクテット（ "0x03"）とともに結果をもたらします。
When using an EtherType to indicate the main type for a frame body, the special "OUI Extended EtherType" 0x88B7 is available. Using this EtherType, a frame body can begin with
EtherTypeを使用してフレームボディのメインタイプを示す場合、特別な「OUI拡張エーサタイプ」0x88B7が利用可能です。このETHERTYPEを使用して、フレームボディは始めることができます
88-B7-yy-yy-yy-zz-zz
88-b7-yyyyy-zz-zz
where yy-yy-yy and zz-zz have the same meaning as in the SNAP format described above; however, this format with EtherType 0x88B7 does not preserve 16-bit alignment.
yy-yy-yyとzz-zzは、上記のスナップ形式と同じ意味を持っています。ただし、EtherType 0x88B7を使用したこの形式では、16ビットアラインメントは保持されません。
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をAll-Zeros OUI（00-00-00）の後にZZ-ZZフィールドとして配置します。それはように見えます
xx-xx-AA-AA-03-00-00-00-zz-zz
xx-xx-aa-aa-03-00-00-zz-zz
where zz-zz is the EtherType.
ここで、ZZ-ZZはEtherTypeです。
As well as labeling frame contents, IEEE 802 protocol types appear within Non-Broadcast Multi-Access (NBMA) Next Hop Resolution Protocol [RFC2332] messages. Such messages have provisions for both two-octet EtherTypes and OUI-based protocol types. 16-bit EtherTypes also occur in the Generic Routing Encapsulation (GRE) [RFC2784] header and in the Generic Network Virtualization Encapsulation (Geneve) [RFC8926] encapsulation header.
フレームコンテンツのラベル付けに加えて、IEEE 802プロトコルタイプは、非ブロードキャストマルチアクセス（NBMA）次のホップ解像度プロトコル[RFC2332]メッセージ内に表示されます。このようなメッセージには、2オクテットの倫理とOUIベースのプロトコルタイプの両方に関する規定があります。16ビット倫理は、ジェネリックルーティングカプセル化（GRE）[RFC2784]ヘッダーとジェネリックネットワーク仮想化カプセル化（Geneve）[RFC8926]カプセル化ヘッダーにも発生します。
Two-octet protocol numbers under the IANA OUI are available, as in
IANA OUIの下での2オクテットプロトコル番号は、ように利用可能です
88-B7-00-00-5E-qq-qq
88-B7-00-00-5E-QQ-QQ
or
または又はそれとも若しくは乃至或るいは
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-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 [EthernetNum]). 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 protocol numbers (qq-qq) under the IANA OUI must meet the following requirements:
そのような課題の多くは、00-00-5E-00-00から00-00-5E-FF-FFから利用可能な2 ** 16のプロトコル番号から作成されています（[EthernetNum]を参照）。この範囲の00-00-5E-00-00および00-00-5E-FF-FFの極端な値は予約されており、割り当てのためにIESGの批准が必要です（セクション5.1を参照）。IANA OUIの下でのプロトコル番号（QQ-QQ）の新しい割り当ては、次の要件を満たす必要があります。
* the assignment must be for standards use (either for an IETF Standard or other standard related to IETF work),
* 割り当ては、標準の使用（IETF標準またはIETF作業に関連するその他の標準のいずれか）でなければなりません。
* the protocol must include a version field at a fixed offset or an equivalent marking such that later versions can be indicated in a way recognizable by earlier versions,
* プロトコルには、固定オフセットのバージョンフィールドまたは同等のマーキングを含める必要があります。そのため、以前のバージョンで認識できる方法で後のバージョンを示すことができます。
* the protocol must be documented in an Internet-Draft or RFC, and
* プロトコルは、インターネットドラフトまたはRFCで文書化する必要があり、
* such protocol numbers are not to be assigned for any protocol that has an EtherType. (That EtherType can be used directly, or -- in the LSAPs case -- it can be used with the SNAP SAP by putting an all-zero "OUI" before the EtherType as described above.)
* このようなプロトコル番号は、EtherTypeを持つプロトコルに割り当てられないものではありません。（そのETHERTYPEは直接使用できます。または、LSAPSの場合は、上記のようにETHERTYPEの前にゼロの「OUI」を挿入することで、SNAP SAPで使用できます。）
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で指定された手順を使用して、専門家のレビュー（または2つの予約値のIESG批准）を取得する必要があります。
0x0042 is a protocol number under the IANA OUI (that is, 00-00-5E-00-42) to be used as an example for documentation purposes.
0x0042は、ドキュメントの目的の例として使用されるIANA OUI（つまり、00-00-5E-00-42）の下のプロトコル番号です。
Some IEEE 802 and other protocols provide for parameters based on an OUI or CID beyond those discussed above. Such parameters commonly consist of an OUI or CID plus one octet of additional value. They are called Organizationally Specific parameters (sometimes informally and less accurately referred to as "vendor specific"). They would look like
一部のIEEE 802および他のプロトコルは、上記のOUIまたはCIDに基づいたパラメーターを提供します。このようなパラメーターは、通常、OUIまたはCIDと追加価値の1オクテットで構成されています。それらは、組織的に特定のパラメーターと呼ばれます（時には非公式に、「ベンダー固有」と呼ばれることもありません）。彼らはどのように見えるでしょう
yy-yy-yy-zz
yyyyyy-zz
where yy-yy-yy is the OUI/CID and zz is the additional specifier. An example is the Cipher Suite Selector in [IEEE.802.11_2012].
ここで、yy-yy-yyはoui/cid、zzは追加の仕様です。例は、[IEEE.802.11_2012]の暗号スイートセレクターです。
Values may be assigned under the IANA OUI for 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 (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 for a one octet specifier, right justified and filled with zeros on the left if the specifier is more than one octet) is assigned for use as an example in documentation.
各使用については、すべてのゼロビットと1つのビット（0x00（00-00-5E-00）で構成される追加の仕様値があることを除いて、他のOUIベースのパラメーター使用量のIANA OUIの下で値を割り当てることができます。One-octet仕様の場合は0xff（00-00-5e-ff）が予約されており、割り当てにはIESG批准（セクション5.1を参照）が必要です。また、追加の仕様値0x42（1オクテットの仕様の場合は00-00-5E-42、指定子が複数のオクテットである場合、右に正当化され、左側のゼロで満たされています）は、ドキュメントの例として使用するために割り当てられています。
Assignments of 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 may specify the name of the registry.
他のIANA OUIベースのパラメーターの割り当ては、標準の使用（IETF標準またはIETF作業に関連するその他の標準のいずれか）であり、インターネットドラフトまたはRFCで文書化する必要があります。このタイプの特定のパラメーターに値が最初に割り当てられたとき、IANA OUIの下でその割り当てとそのパラメーターの値のその後の割り当てを含むようにIANAレジストリが作成されます。専門家は、レジストリの名前を指定する場合があります。
If different policies from those above are required for such a parameter, a BCP or Standards Track RFC should be adopted to update this BCP and specify the new policy and parameter.
このようなパラメーターには上記のポリシーとは異なるポリシーが必要な場合は、このBCPを更新し、新しいポリシーとパラメーターを指定するために、BCPまたは標準トラックRFCを採用する必要があります。
An example of an "other IANA OUI-based parameter" is specified in [RFC8520]. This provides for an Organizationally Specific TLV type for announcing a Manufacturer Usage Description (MUD) Uniform Resource Locator (URL) in the IEEE Link Local Discovery Protocol (LLDP) [IEEE802.1AB]. Additional IETF use of code points in this space have been proposed [BGP11dp]. (See also Section 5.8.)
「他のIANA OUIベースのパラメーター」の例は、[RFC8520]で指定されています。これにより、IEEEリンクローカルディスカバリープロトコル（LLDP）[IEEE802.1AB]で、製造業者の使用法の説明（MUD）のユニフォームリソースロケーター（URL）を発表するための組織的に特定のTLVタイプが提供されます。このスペースでのコードポイントの追加のIETF使用が提案されています[BGP11DP]。（セクション5.8も参照してください。）
This document concerns IANA considerations for the assignment of Ethernet parameters in connection with the IANA OUI and related matters.
このドキュメントは、IANA OUIおよび関連事項に関連するイーサネットパラメーターの割り当てに関するIANAの考慮事項に関するものです。
Note: The "IANA OUI Ethernet Numbers" registry group (web page) is for registries of numbers assigned under the IANA OUI, while the "IEEE 802 Numbers" registry group has informational lists of numbers assigned by the IEEE Registration Authority.
注：「IANA OUI Ethernet Numbers」レジストリグループ（Webページ）は、IANA OUIの下で割り当てられた番号の登録用であり、「IEEE 802番号」レジストリグループには、IEEE登録機関によって割り当てられた番号の情報リストがあります。
This document does not create any new IANA registries.
このドキュメントでは、新しいIANAレジストリは作成されません。
The MAC address values assigned for documentation and the protocol number for documentation were both assigned by [RFC7042].
ドキュメントに割り当てられたMACアドレス値とドキュメントのプロトコル番号はどちらも[RFC7042]によって割り当てられました。
No existing assignment is changed by this document.
このドキュメントによって既存の割り当ては変更されていません。
This section specifies the procedures 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の喜びで任命され、奉仕する1人以上の人で構成されます。
The procedure described for Expert Review assignments in this document is consistent with the IANA Expert Review policy described in [RFC8126].
このドキュメントの専門家レビューの割り当てについて説明した手順は、[RFC8126]に記載されているIANAの専門家レビューポリシーと一致しています。
While finite, the universe of MAC code points from which Expert-judged assignments will be made is considered 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 reasonableness check for small assignments of MAC identifiers, with increased scrutiny by the Expert for medium-sized assignments of MAC identifiers and assignments of protocol identifiers and other IANA OUI-based parameters.
有限ですが、専門家が判断された割り当てが行われるMACコードポイントのユニバースは、このドキュメントと専門家の良い判断に与えられた要件が十分なガイダンスであるほど十分に大きいと考えられています。アイデアは、MAC識別子の小さな割り当てに対して軽い合理性チェックを提供することであり、MAC識別子の中規模の割り当てとプロトコル識別子およびその他のIANA OUIベースのパラメーターの割り当ての専門家による精査が増加します。
It can make sense to assign very large portions of the MAC identifier code point space. (Note that existing assignments include one for half of the entire multicast IANA 48-bit code point space and one for a sixteenth 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. This can be viewed as a combination of Expert Review and IESG Approval as defined in [RFC8126]. IESG Approval is required only when the Expert does not reject the request. The procedure is as follows:
Mac Identifierコードポイントスペースの非常に大きな部分を割り当てることは理にかなっています。（既存の割り当てには、マルチキャストIANA 48ビットコードポイントスペース全体の半分と、そのマルチキャストコードポイントスペースの16分の1の1つに含まれることに注意してください。）これらの場合、「予約された」値の割り当ての場合、IESG以下に説明するように、専門家のレビュー承認勧告の批准が必要です。これは、[RFC8126]で定義されているように、専門家のレビューとIESGの承認の組み合わせと見なすことができます。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. The Expert should provide a reason for refusal, which IANA will communicate back to the applicant.
すべての場合において、IANAがアプリケーションテンプレートを確認するために選択された専門家から不承認を受け取った場合、アプリケーションは拒否されます。専門家は拒否の理由を提供する必要があり、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, who in turn informs the applicant that their request is denied; 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 provided by the Expert 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 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. In case of refusal, the IESG should provide a reason, which IANA will communicate to the applicant.
手順は、エキスパートレビューの上記の最初のステップから始まります。専門家が申請を不承認にした場合、彼らは単にIANAに通知します。IANAは、申請者に要求が拒否されていることを知らせます。ただし、専門家が申請を承認する必要があるか、不確実であると信じており、状況がIESGの注意を必要とすると信じている場合、専門家はIANAにアドバイスについて通知し、IANAは専門家が提供する理由とともに申請を転送します承認または不確実性のために、IESGに。IESGは、割り当てが許可されるかどうかを決定する必要があります。これは、他の種類のリクエストに対して行われるように、IESGテレカットの管理アイテムによって実現できます。IESGが専門家による有利な意見を批准しないことを決定した場合、または専門家が不確実なアプリケーションに対して決定する場合、申請は拒否されます。それ以外の場合は、付与されています。IESGは、その決定を専門家とIANAに伝えます。拒否の場合、IESGはIANAが申請者に通信する理由を提供する必要があります。
For clarity and parallelism with the IANA "IEEE 802 Numbers" registry group, the IANA "Ethernet Numbers" registry group has been renamed the "IANA OUI Ethernet Numbers" registry.
IANA「IEEE 802番号」レジストリグループとの明確さと並列性のために、IANA「イーサネット番号」レジストリグループは「IANA OUI Ethernet Numbers」レジストリの名前が変更されました。
As this document replaces [RFC7042], references to [RFC7042] in IANA registries in both the "IEEE 802 Numbers" and the "IANA OUI Ethernet Numbers" registry groups have been replaced by references to this document. Other IANA registry references to [RFC7042] are not changed.
このドキュメントが[RFC7042]に取って代わると、「IEEE 802番号」と「IANA OUIイーサネット番号」レジストリグループの両方のIANAレジストリの[RFC7042]への言及は、このドキュメントへの参照に置き換えられました。[RFC7042]への他の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] |
+------------+---------+--------+-----------+
| OUI | 16391 | 0x4007 | [RFC7961] |
+============+=========+========+===========+
| Lower 24 bits of a 48-bit MAC address: |
+============+=========+========+===========+
| MAC/24 | 16392 | 0x4008 | [RFC7961] |
+============+=========+========+===========+
| Lower 40 bits of a 64-bit MAC address: |
+============+=========+========+===========+
| MAC/40 | 16393 | 0x4009 | [RFC7961] |
+------------+---------+--------+-----------+
Table 4
IANA has assigned DNS RRTYPEs [RFC6895] for MAC addresses as follows:
IANAは、次のようにMACアドレスにDNS RRTypes [RFC6895]を割り当てました。
+============+==========+==================+===========+
| | | RRTYPE Code | |
+============+==========+=========+========+===========+
| Data | Mnemonic | Decimal | Hex | Reference |
+============+==========+=========+========+===========+
| 48-bit MAC | EUI48 | 108 | 0x006C | [RFC7043] |
+------------+----------+---------+--------+-----------+
| 64-bit MAC | EUI64 | 109 | 0x006D | [RFC7043] |
+------------+----------+---------+--------+-----------+
Table 5
IANA maintains an informational registry group, currently implemented as a web page, concerning EtherTypes, OUIs, and multicast addresses assigned under OUIs other than the IANA OUI. The title of this informational registry group is "IEEE 802 Numbers". IANA updates that informational registry group when changes are provided by or approved by the Expert(s).
IANAは、IANA OUI以外のOUIに基づいて割り当てられたethertypes、OUIS、およびマルチキャストアドレスに関して、現在Webページとして実装されている情報レジストリグループを維持しています。この情報レジストリグループのタイトルは「IEEE 802番号」です。IANAは、変更が専門家によって提供される、または専門家によって承認されたときの情報レジストリグループを更新します。
Applying to the IEEE Registration Authority for an EtherType needed by an IETF protocol requires IESG Approval, as stated in Appendix B. To minimize confusion, this process will normally be done by the primary expert for the informational "EtherType" registry within the "IEEE 802 Numbers" registry group, as described below (see also Section 5.4).
IETFプロトコルで必要なETHERTYPEのIEEE登録機関に申請するには、付録Bに記載されているように、IESGの承認が必要です。混乱を最小限に抑えるために、このプロセスは通常、「IEEE 802内の情報「EtherType」レジストリの主要な専門家が行われます。Numbers "レジストリグループ、以下に説明するように（セクション5.4も参照）。
After IESG Approval of the requirement for an EtherType, the IESG should refer the matter to IANA. In any case, IANA will ask the "EtherType" registry expert to execute the IEEE Registration Authority [IEEE_RA] EtherType request process. This path is specified because the IESG usually deals with IANA for assignment actions and because IANA should be aware of which "EtherType" registry expert(s) are available, normally referring the making of the EtherType assignment request to the primary expert.
Ethertypeの要件のIESG承認の後、IESGは問題をIANAに照会する必要があります。いずれにせよ、IANAは「EtherType」レジストリの専門家にIEEE登録機関[IEEE_RA] EtherType要求プロセスを実行するように依頼します。このパスは、IESGが通常IANAを割り当てるためにIANAを扱っており、IANAがどの「EtherType」レジストリエキスパートが利用可能であるかを認識する必要があるため、通常、主要な専門家へのEtherType割り当て要求の作成を参照するためです。
Here is sample text for an Internet-Draft where both IANA and IEEE assignments are required, where "YYY" would be replaced by an explanation of for what/why the EtherType is needed in whatever level of detail is necessary and would normally include a reference or references to other appropriate parts of the Internet-Draft:
IANAとIEEEの両方の割り当てが必要なインターネットドラフトのサンプルテキストは次のとおりです。「YYY」は、必要なレベルの詳細でEtherTypeが必要なもの/理由の説明に置き換えられ、通常は参照が含まれます。または、インターネットドラフトの他の適切な部分への参照：
X. Assignment Considerations
X.割り当ての考慮事項
X.1. IEEE Assignment Considerations
X.1. IEEE割り当ての考慮事項
The IESG is requested to approve applying to the IEEE Registration Authority for an EtherType for YYY. (The IESG should communicate its approval to IANA and to those concerned with this document. IANA will forward the IESG Approval to the registry expert of the "EtherType" registry from the "IEEE 802 Numbers" registry group who will make the application to the IEEE Registration Authority, keeping IANA informed.)
IESGは、YYYのETHERTYPEのIEEE登録機関への申請を承認することを要求されています。（IESGは、IANAおよびこの文書に関係する人々に承認を伝える必要があります。IANAは、IESGの承認を「EtherType」レジストリの登録専門家に「IEEE 802番号」レジストリグループから転送します。IANAを通知し続ける登録機関。）
X.2. IANA Considerations
X.2. 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登録機関にさらなるIANAの割り当てを追加することを要求する必要があります。任命された専門家は、この状態を監視し、IANAに通知する必要があります。
The following changes are made by this document to the Notes for the "IANA Unicast 48-bit MAC Addresses", the "IANA Multicast 48-bit MAC Addresses", and the "IANA 64-bit MAC Addresses" registries. In addition, the references in those registries are updated, as specified in Section 5.2.
このドキュメントでは、「IANA Unicast 48ビットMACアドレス」、「IANAマルチキャスト48ビットMACアドレス」、および「IANA 64ビットMACアドレス」レジストリのメモに次の変更が行われます。さらに、セクション5.2で指定されているように、これらのレジストリの参照が更新されます。
The Notes for the "IANA Unicast 48-bit MAC Addresses" registry and for the "IANA Multicast 48-bit MAC Addresses" registry are changed to the following:
「IANA UNICAST 48ビットMACアドレス」レジストリと「IANAマルチキャスト48ビットMACアドレス」レジストリのメモは、次のように変更されます。
These values are prefixed with 00-00-5E. See Section 2.1.3 of RFC 9542.
これらの値には00-00-5Eが付いています。RFC 9542のセクション2.1.3を参照してください。
The Note for the "IANA 64-bit MAC Addresses" registry is changed to the following:
「IANA 64ビットMACアドレス」レジストリのメモは、次のように変更されます。
These values are prefixed with 00-00-5E to form unicast MAC addresses, with 01-00-5E to form multicast MAC addresses, with 02-00-5E to form unicast modified EUI-64 addresses, and with 03-00-5E to form multicast modified EUI-64 addresses. See RFC 9542, particularly Section 2.2.2, for more details.
これらの値には00-00-5Eが付いており、ユニキャストMACアドレスを形成し、01-00-5EでマルチキャストMACアドレスを形成し、02-00-5Eでユニキャスト修正EUI-64アドレスを形成し、03-00-5Eで形成しますマルチキャスト修正EUI-64アドレスを形成する。詳細については、RFC 9542、特にセクション2.2.2を参照してください。
IANA has moved the "IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes" registry from the "IEEE 802 Numbers" registry group to the "IANA OUI Ethernet Numbers" registry group, since code points within it are assigned by IANA, and has added RFC 9542 as an additional reference for that registry.
IANAは、「IEEE 802番号」レジストリグループから「IANAリンクレイヤーディスカバリープロトコル（LLDP）TLVサブタイプ」レジストリを「IANA OUIイーサネット番号」レジストリグループに移動しました。RFC 9542そのレジストリの追加リファレンスとして。
In addition, IANA has updated three entries in that registry as follows:
さらに、IANAは次のようにそのレジストリの3つのエントリを更新しました。
+=======+==================================+===========+
| Value | Description | Reference |
+=======+==================================+===========+
| 0 | Reserved | RFC 9542 |
+-------+----------------------------------+-----------+
| 42 | Example for use in documentation | RFC 9542 |
+-------+----------------------------------+-----------+
| 255 | Reserved | RFC 9542 |
+-------+----------------------------------+-----------+
Table 6
The entries for 1 (MUD), 2-41 (unassigned), and 43-254 (unassigned) are unchanged.
1（泥）、2-41（割り当てられていない）、および43-254（割り当てなし）のエントリは変更されていません。
IANA has assigned two CBOR Tags as shown below in the "Concise Binary Object Representation (CBOR) Tags" registry.
IANAは、「Scise Binaryオブジェクト表現（CBOR）タグ」レジストリに示すように、2つのCBORタグを割り当てました。
+======+=============+==================+===========+
| Tag | Data Item | Semantics | Reference |
+======+=============+==================+===========+
| 48 | byte string | IEEE MAC Address | RFC 9542 |
+------+-------------+------------------+-----------+
| 1048 | byte string | IEEE OUI/CID | RFC 9542 |
+------+-------------+------------------+-----------+
Table 7
This document is concerned with assignment of IEEE 802 parameters allocated to IANA, particularly those under the IANA OUI, and closely related matters. It is not directly concerned with security except as follows:
このドキュメントは、IEAE 802パラメーター、特に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 that are "only" to be used 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アドレスとドキュメントの目的のためのパラメーターの予約は、そのような混乱と競合を最小限に抑えます。
MAC addresses are identifiers provided by a device to the network. On certain devices, MAC addresses are not static and can be configured. The network should exercise caution when using these addresses to enforce policy because addresses can be spoofed and previously seen devices can return to the network with a new address.
MACアドレスは、ネットワークにデバイスによって提供される識別子です。特定のデバイスでは、Macアドレスは静的ではなく、構成できます。アドレスをスプーフィングし、以前に見たデバイスが新しいアドレスでネットワークに戻ることができるため、これらのアドレスを使用してポリシーを実施する場合は、ネットワークは注意を払う必要があります。
MAC addresses identify a physical or virtual interface and can be used for tracking the device with that interface. Thus, they can be used to track users associated with that device. See [madinas] for related privacy considerations and a discussion of MAC address randomization to partially mitigate this threat. Also, see [RFC7043] for the security and privacy considerations of publishing MAC addresses in DNS.
MACアドレスは、物理的または仮想インターフェイスを識別し、そのインターフェイスでデバイスを追跡するために使用できます。したがって、それらを使用して、そのデバイスに関連するユーザーを追跡できます。関連するプライバシーの考慮事項と、この脅威を部分的に軽減するためのMACアドレスのランダム化についての議論については、[Madinas]を参照してください。また、DNSでMACアドレスを公開するセキュリティとプライバシーの考慮事項については、[RFC7043]を参照してください。
[IEEE.802.1Q_2014]
IEEE, "IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,
DOI 10.1109/ieeestd.2014.6991462, 18 December 2014,
<http://ieeexplore.ieee.org/servlet/
opac?punumber=6991460>.
[IEEE802.1AB]
IEEE, "IEEE Standard for Local and metropolitan area
networks - Station and Media Access Control Connectivity
Discovery", IEEE Std 802.1AB-2016,
DOI 10.1109/IEEESTD.2016.7433915, March 2016,
<https://doi.org/10.1109/IEEESTD.2016.7433915>.
[IEEE802_OandA]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE Std 802-2014,
DOI 10.1109/IEEESTD.2014.6847097, June 2014,
<https://doi.org/10.1109/IEEESTD.2014.6847097>.
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture -- Amendment 2: Local
Medium Access Control (MAC) Address Usage", IEEE Std 802c-
2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017,
<https://doi.org/10.1109/IEEESTD.2017.8016709>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[BGP11dp] Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu,
"BGP Logical Link Discovery Protocol (LLDP) Peer
Discovery", Work in Progress, Internet-Draft, draft-acee-
idr-lldp-peer-discovery-17, 4 January 2024,
<https://datatracker.ietf.org/doc/html/draft-acee-idr-
lldp-peer-discovery-17>.
[EthernetNum]
IANA, "IANA OUI Ethernet Numbers",
<https://www.iana.org/assignments/ethernet-numbers>.
[IANA] IANA, "Internet Assigned Numbers Authority",
<https://www.iana.org>.
[IEEE] IEEE, "Institute of Electrical and Electronics Engineers",
<https://www.ieee.org>.
[IEEE.802.11_2012]
IEEE, "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-2012, DOI 10.1109/ieeestd.2012.6178212, 5
April 2012, <http://ieeexplore.ieee.org/servlet/
opac?punumber=6178209>.
[IEEE.802.3_2012]
IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2012,
DOI 10.1109/ieeestd.2012.6419735, 24 January 2013,
<http://ieeexplore.ieee.org/servlet/
opac?punumber=6419733>.
[IEEE1394] IEEE, "IEEE Standard for a High-Performance Serial Bus",
IEEE Std 1394-2008, DOI 10.1109/IEEESTD.2008.4659233,
October 2008,
<https://doi.org/10.1109/IEEESTD.2008.4659233>.
[IEEE802] IEEE 802, "IEEE 802 LMSC", <https://www.ieee802.org>.
[IEEE802.15.4]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
Std 802.15.4-2020, DOI 10.1109/IEEESTD.2020.9144691, July
2020, <https://doi.org/10.1109/IEEESTD.2020.9144691>.
[IEEE802.1AC]
IEEE 802, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Service
Definition", IEEE Std 802.1AC-2016,
DOI 10.1109/IEEESTD.2017.7875381, March 2017,
<https://doi.org/10.1109/IEEESTD.2017.7875381>.
[IEEE802.1CQ]
IEEE, "Draft Standard for Local and Metropolitan Area
Networks: Multicast and Local Address Assignment", draft
0.8, IEEE Std 802.1CQ/D0.8, July 2022.
[IEEEtutorials]
IEEE, "Guidelines for Use of Extended Unique Identifier
(EUI), Organizationally Unique Identifier (OUI), and
Company ID (CID)", August 2017,
<https://standards.ieee.org/wp-
content/uploads/import/documents/tutorials/eui.pdf>.
[IEEE_RA] IEEE, "Registration Authority",
<https://standards.ieee.org/products-programs/regauth/>.
[IEEE_SA] IEEE, "IEEE Standards Association",
<https://standards.ieee.org>.
[InfiniBand]
InfiniBand Trade Association, "InfiniBand Architecture
Specification Volume 1", November 2007,
<https://www.infinibandta.org/>.
[madinas] Zúñiga, JC., Bernardos, CJ., Ed., and A. Andersdotter,
"Randomized and Changing MAC Address state of affairs",
Work in Progress, Internet-Draft, draft-ietf-madinas-mac-
address-randomization-12, 28 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-madinas-
mac-address-randomization-12>.
[PPPNum] IANA, "Point-to-Point (PPP) Protocol Field Assignments",
<https://www.iana.org/assignments/ppp-numbers>.
[RAC_OUI] Parsons, G., "OUI Registry Restructuring", Work in
Progress, Internet-Draft, draft-ieee-rac-oui-
restructuring-01, 9 September 2013,
<https://datatracker.ietf.org/doc/html/draft-ieee-rac-oui-
restructuring-01>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<https://www.rfc-editor.org/info/rfc1661>.
[RFC2153] Simpson, W., "PPP Vendor Extensions", RFC 2153,
DOI 10.17487/RFC2153, May 1997,
<https://www.rfc-editor.org/info/rfc2153>.
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)",
RFC 2332, DOI 10.17487/RFC2332, April 1998,
<https://www.rfc-editor.org/info/rfc2332>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>.
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
<https://www.rfc-editor.org/info/rfc2606>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>.
[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
of "Foo"", RFC 3092, DOI 10.17487/RFC3092, April 2001,
<https://www.rfc-editor.org/info/rfc3092>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
DOI 10.17487/RFC5214, March 2008,
<https://www.rfc-editor.org/info/rfc5214>.
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
"MPLS Multicast Encapsulations", RFC 5332,
DOI 10.17487/RFC5332, August 2008,
<https://www.rfc-editor.org/info/rfc5332>.
[RFC5342] Eastlake 3rd, D., "IANA Considerations and IETF Protocol
Usage for IEEE 802 Parameters", RFC 5342,
DOI 10.17487/RFC5342, September 2008,
<https://www.rfc-editor.org/info/rfc5342>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/info/rfc5737>.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798,
DOI 10.17487/RFC5798, March 2010,
<https://www.rfc-editor.org/info/rfc5798>.
[RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast
Addresses", RFC 6034, DOI 10.17487/RFC6034, October 2010,
<https://www.rfc-editor.org/info/rfc6034>.
[RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer
Protocol Identifiers", BCP 164, RFC 6328,
DOI 10.17487/RFC6328, July 2011,
<https://www.rfc-editor.org/info/rfc6328>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[RFC7043] Abley, J., "Resource Records for EUI-48 and EUI-64
Addresses in the DNS", RFC 7043, DOI 10.17487/RFC7043,
October 2013, <https://www.rfc-editor.org/info/rfc7043>.
[RFC7319] Eastlake 3rd, D., "IANA Considerations for Connectivity
Fault Management (CFM) Code Points", BCP 191, RFC 7319,
DOI 10.17487/RFC7319, July 2014,
<https://www.rfc-editor.org/info/rfc7319>.
[RFC7961] Eastlake 3rd, D. and L. Yizhou, "Transparent
Interconnection of Lots of Links (TRILL): Interface
Addresses APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961,
August 2016, <https://www.rfc-editor.org/info/rfc7961>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
[RFC8947] Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer
Address Assignment Mechanism for DHCPv6", RFC 8947,
DOI 10.17487/RFC8947, December 2020,
<https://www.rfc-editor.org/info/rfc8947>.
[RFC8948] Bernardos, CJ. and A. Mourad, "Structured Local Address
Plan (SLAP) Quadrant Selection Option for DHCPv6",
RFC 8948, DOI 10.17487/RFC8948, December 2020,
<https://www.rfc-editor.org/info/rfc8948>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
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 the country code)
申請者の電話：（カントリーコードから始まる）
Use Name: (brief name of Parameter use, such as "Foo Protocol" [RFC3092])
使用名：（「Foo Protocol」などのパラメーター使用の簡単な名前[RFC3092]）
Document: (I-D or RFC specifying use to which the identifier or block of identifiers will be put)
ドキュメント：（i-dまたは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つのサイズのブロックのパワーでなければなりません、サイズ1（2 ** 0）のブロックにすることができます）
Specify multicast, unicast, or both:
マルチキャスト、ユニキャスト、またはその両方を指定します。
Applicant Name:
申請者名：
Applicant Email:
申請者のメール：
Applicant Telephone: (starting with the country code)
申請者の電話：（カントリーコードから始まる）
Use Name: (brief name of use of code point, such as "Foo Protocol")
使用名：（「Foo Protocol」などのコードポイントの使用の簡単な名前）
Document: (I-D or RFC specifying use to which the protocol identifier will be put)
ドキュメント：（I-DまたはRFCプロトコル識別子が配置される使用法）
Note: (any additional note)
注：（追加のメモ）
Applicant Name:
申請者名：
Applicant Email:
申請者のメール：
Applicant Telephone: (starting with the country code)
申請者の電話：（カントリーコードから始まる）
Protocol where the OUI/CID-Based Parameter for which a value is being requested appears: (such as Cipher Suite selection in IEEE 802.11)
値がリクエストされているOUI/CIDベースのパラメーターが表示されるプロトコル：（ IEEE 802.11のCipher Suite Selectionなど）
Use Name: (brief name of use of code point to be assigned, such as "Foo Cipher Suite" [RFC3092])
使用名：（「Foo Cipher Suite」などの割り当てられるコードポイントの使用の簡単な名前[RFC3092]）
Document: (I-D or RFC specifying use to which the other IANA OUI-based parameter value will be put)
ドキュメント：（i-dまたはrfc他のIANA OUIベースのパラメーター値が置かれる使用法の指定）
Note: (any additional note)
注：（追加のメモ）
This appendix provides a copy of the IESG Statement issued in May 2023 on obtaining new IETF EtherTypes in Appendix B.1. Note that there is an informational IANA registry of some important EtherTypes specified for IETF protocols or by IEEE 802 available, currently at [IANA]. The IEEE Registration Authority page on EtherTypes <https://standards.ieee.org/regauth/ethertype/eth.txt> may also be useful. See Section 3 above.
この付録は、付録B.1で新しいIETF倫理を取得することについて、2023年5月に発行されたIESGステートメントのコピーを提供します。IETFプロトコルまたはIEEE 802が現在[IANA]に入手可能に指定されたいくつかの重要な倫理の情報登録があることに注意してください。Ethertypes <https://standards.ieee.org/regauth/ethertype/eth.txt>のIEEE登録機関ページも役立つ場合があります。上記のセクション3を参照してください。
From:
から：
IESG
iesg
Date:
日付：
1 May 2023
2023年5月1日
The IEEE Registration Authority (IEEE RA) assigns EtherTypes with oversight from the IEEE Registration Authority Committee (IEEE RAC).
IEEE登録局（IEEE RA）は、IEEE登録局委員会（IEEE RAC）からの監視で倫理を割り当てます。
(See https://standards.ieee.org/products-programs/regauth/ ethertype/.) Some IETF protocol specifications make use of EtherTypes. All EtherType applications are subject to IEEE RA technical review for consistency with policy.
（https://standards.ieee.org/products-programs/regauth/ Ethertype/。）いくつかのIETFプロトコル仕様は、ETHERTYPESを使用しています。すべてのEtherTypeアプリケーションは、ポリシーとの一貫性についてIEEE RA技術レビューの対象となります。
Since EtherTypes are a fairly scarce resource, the IEEE RAC has let us know that they will not assign a new EtherType to a new IETF protocol specification until the IESG has approved the protocol specification for publication as an RFC. In exceptional cases, the IEEE RA is willing to consider "early allocation" of an EtherType for an IETF protocol that is still under development as long as the request comes from and has been vetted by the IESG.
Ethertypesはかなり希少なリソースであるため、IEEE RACは、IESGがRFCとして公開するプロトコル仕様を承認するまで、新しいIETFプロトコル仕様に新しいEtherTypeを割り当てないことを知らせてくれました。例外的な場合、IEEE RAは、要求がIESGから来て審査されている限り、まだ開発中であるIETFプロトコルのEtherTypeの「早期割り当て」を喜んで検討します。
To let the IEEE RAC know that the IESG has approved the request for an Ethernet assignment for an IETF protocol, all future requests for assignment of EtherTypes for IETF protocols will be made by the IESG.
IEEE RACに、IESGがIETFプロトコルのイーサネット割り当ての要求を承認したことを知らせるために、IETFプロトコルのEthertypesの割り当てのすべての将来の要求はIESGによって行われます。
Note that Local Experimental ("playpen") EtherTypes have been assigned in IEEE 802 [1] use during protocol development and experimentation.
局所的な実験（ "playpen"）倫理は、プロトコルの開発と実験中にIEEE 802 [1]の使用で割り当てられていることに注意してください。
[1] IEEE Std 802. IEEE standard for Local and Metropolitan Area Networks: Overview and Architecture.
[1] IEEESTD802。IEEEローカルおよびメトロポリタンエリアネットワークの標準：概要とアーキテクチャ。
This document obsoletes [RFC7042] and makes the changes listed below. However, the completed application template based upon which an IANA OUI-based protocol number value was assigned for document use remains that in Appendix C of [RFC7042].
このドキュメントは廃止され[RFC7042]、以下にリストされている変更を行います。ただし、IANA OUIベースのプロトコル番号値がドキュメントの使用のために割り当てられたことに基づいた完了したアプリケーションテンプレートは、[RFC7042]の付録Cのものです。
* Add information on MA-M (28-bit) and MA-S (36-bit) EUI prefixes that the IEEE Registration Authority assigns.
* IEEE登録機関が割り当てるMA-M（28ビット）およびMA-S（36ビット）EUIプレフィックスに関する情報を追加します。
* Add information on the restructuring of the "local" MAC address space into four quadrants under the Structured Local Address Plan (SLAP) [IEEE802_OandA].
* 構造化されたローカルアドレスプラン（SLAP）[IEEE802_OANDA]の下で、「ローカル」MACアドレススペースの再構築に関する情報を4つの象限に追加します。
* Include the IESG Statement on EtherTypes (see Appendix B.1) and more detailed IETF procedures for applying to the IEEE Registration Authority for an EtherType for use in an IETF protocol (see Section 5.5).
* Ethertypesに関するIESGステートメント（付録B.1を参照）と、IETFプロトコルで使用するEtherTypeのIEEE登録局に申請するためのより詳細なIETF手順を含めます（セクション5.5を参照）。
* Mention that IEEE 802 CFM code points have been allocated to the IETF (see Section 1.4).
* IEEE 802 CFMコードポイントがIETFに割り当てられていることに注意してください（セクション1.4を参照）。
* Mention the Organizationally Specific LLDP data element that has been assigned under the IANA OUI and the registry set up for future such assignments (see Section 4.1).
* IANA OUIおよび将来のそのような割り当てのために設定されたレジストリの下で割り当てられた組織的に特定のLLDPデータ要素に言及します（セクション4.1を参照）。
* Clarify minor details in Section 5.1 on Expert Review and IESG Ratification.
* エキスパートレビューとIESG批准に関するセクション5.1でマイナーな詳細を明確にします。
* Specify CBOR tags for MAC addresses and OUIs/CIDs (see Section 2.4).
* MACアドレスとOUIS/CIDのCBORタグを指定します（セクション2.4を参照）。
* Add a version field requirement for the allocation of protocol numbers under the IANA OUI (see Section 3.1).
* IANA OUIに基づくプロトコル番号の割り当てのバージョンフィールド要件を追加します（セクション3.1を参照）。
* Mention that EtherTypes are used in the Geneve [RFC8926] encapsulation header (see Section 3).
* EthertypesはGeneve [RFC8926]カプセル化ヘッダーで使用されていることに注意してください（セクション3を参照）。
* Add "a combination of Expert Review and IESG Approval" as part of the specification for "IESG Ratification".
* 「IESG批准」の仕様の一部として、「専門家のレビューとIESG承認の組み合わせ」を追加します。
The comments and suggestions of the following persons and organizations are gratefully acknowledged:
次の人と組織のコメントと提案は感謝されています。
Comments and suggestions leading to this document:
このドキュメントにつながるコメントと提案：
Carsten Bormann, Bob Hinden, the IEEE 802.1 Working Group, Éric Vyncke, Dale Worley, and Amanda Baber
Carsten Bormann、Bob Hinden、The IEEE 802.1ワーキンググループ、エリックヴィンケ、デールウォーリー、アマンダバベル
Comments and suggestions leading to [RFC7042] (which is obsoleted by this document):
[RFC7042]につながるコメントと提案（このドキュメントで廃止されています）：
David Black, Adrian Farrel, Bob Grow, Joel Jaeggli, Pearl Liang, Glenn Parsons, Pete Resnick, and Dan Romascanu
デビッド・ブラック、エイドリアン・ファレル、ボブ・グロー、ジョエル・ジェグリ、パール・リアン、グレン・パーソンズ、ピート・レストニック、ダン・ロマスカヌ
Donald E. Eastlake 3rd
Independent
2386 Panoramic Circle
Apopka, Florida 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com, donald.eastlake@futurewei.com
Joe Abley
Cloudflare
Amsterdam
The Netherlands
Phone: +31 45 56 36 34
Email: jabley@strandkip.nl
Yizhou Li
Huawei Technologies
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Phone: +86-13809002299
Email: liyizhou@huawei.com