[要約] RFC 5342は、IEEE 802パラメータのIANAの考慮事項とIETFプロトコルの使用に関するガイドラインです。このRFCの目的は、IEEE 802パラメータの一貫性と一元管理を確保し、IETFプロトコルの使用に関する指針を提供することです。
Network Working Group D. Eastlake 3rd
Request for Comments: 5342 Eastlake Enterprises
BCP: 141 September 2008
Updates: 2153
Category: Best Current Practice
IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters
IEEE 802パラメーターのIANAの考慮事項とIETFプロトコルの使用
Status of This Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Abstract
概要
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier).
一部のIETFプロトコルは、イーサネットフレーム形式とIEEE 802パラメーターを使用しています。このドキュメントでは、IETFプロトコルでのこのようなパラメーターのいくつかの使用について説明し、IANA OUI（組織的に一意の識別子）に基づくコードポイントの割り当てに関するIANAの考慮事項を指定します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Notations Used in This Document ............................3
1.2. The IEEE Registration Authority ............................3
1.2.1. The IANA OUI ........................................4
1.3. Acknowledgements ...........................................4
2. Ethernet Identifier Parameters ..................................4
2.1. 48-Bit MAC Identifiers and OUIs ............................4
2.1.1. EUI-48 Allocations under the IANA OUI ...............5
2.1.2. EUI-48 IANA Allocation Considerations ...............5
2.2. 64-Bit MAC Identifiers .....................................6
2.2.1. IPv6 Use of Modified EUI-64 Identifiers .............6
2.2.2. EUI-64 IANA Allocation Considerations ...............8
2.3. Other MAC-48 Identifiers Used by IETF ......................9
2.3.1. Identifiers Prefixed 33-33 ..........................9
2.3.2. The 'CF Series' ....................................10
2.3.2.1. Changes to RFC 2153 .......................10
3. Ethernet Protocol Parameters ...................................10
3.1. Ethernet Protocol Allocation under the IANA OUI ...........12
4. Other OUI-Based Parameters .....................................13
5. IANA Considerations ............................................13
5.1. Expert Review and IESG Ratification .......................14
5.2. Informational IANA Web Page Material ......................15
5.3. OUI Exhaustion ............................................15
6. Security Considerations ........................................15
7. Normative References ...........................................15
8. Informative References .........................................16
Appendix A. Templates ............................................18
A.1. EUI-48/EUI-64 Identifier or Identifier Block Template .....18
A.2. 5-Octet Ethernet Protocol Identifier Template .............18
A.3. Other IANA OUI-Based Parameter Template ...................19
Appendix B. Ethertypes ............................................19
B.1. Some Ethertypes Specified by The IETF .....................19
B.2. Some IEEE 802 Ethertypes ..................................20
Some IETF protocols use Ethernet or other [IEEE] 802 related communication frame formats and parameters [IEEE802]. These include MAC (Media Access Control) identifiers and protocol identifiers.
一部のIETFプロトコルは、イーサネットまたはその他の[IEEE] 802関連の通信フレーム形式とパラメーターを使用します[IEEE802]。これらには、Mac（メディアアクセス制御）識別子とプロトコル識別子が含まれます。
This document specifies IANA considerations for the allocation of code points under the IANA OUI. It also discusses some other IETF use of IEEE 802 code points.
このドキュメントは、IANA OUIに基づくコードポイントの割り当てに関するIANAの考慮事項を指定しています。また、IEEE 802コードポイントの他のIETF使用についても説明します。
[RFC5226] is incorporated herein except where there are contrary provisions in this document.
[RFC5226]は、本書に逆の規定がある場合を除き、本明細書に組み込まれています。
This document uses hexadecimal notation. Each octet (that is, 8-bit byte) is represented by two hexadecimal digits giving the value of the octet as an unsigned integer. Successive octets are separated by a hyphen. This document consistently uses IETF bit ordering although the physical order of bit transmission within an octet on an IEEE [802.3] link is from the lowest order bit to the highest order bit (i.e., the reverse of the IETF's ordering).
このドキュメントでは、16進表記を使用しています。各オクテット（つまり、8ビットバイト）は、2つの16進数桁で表され、オクテットの値を符号なし整数として示します。連続したオクテットはハイフンによって分離されます。このドキュメントでは、IETFビットの順序付けを一貫して使用しますが、IEEE [802.3]リンクのオクテット内のビット伝送の物理的順序は、最低のビットから最高順序ビット（つまり、IETFの注文の逆）にあります。
In this document:
このドキュメントで：
"IAB" stands for Individual Address Block, not for Internet Architecture Board;
「IAB」は、インターネットアーキテクチャボードではなく、個々のアドレスブロックの略です。
"MAC" stands for Media Access Control, not for Message Authentication Code; and
「Mac」は、メッセージ認証コードではなく、メディアアクセス制御の略です。と
"OUI" stands for Organizationally Unique Identifier.
「OUI」は、組織的にユニークな識別子の略です。
"**" indicates exponentiation. For example, 2**24 is two to the twenty-fourth power.
「**」は指数を示します。たとえば、2 ** 24は24番目の電力です。
Originally the responsibility of Xerox Corporation, the registration authority for Ethernet parameters is now the IEEE Registration Authority, available on the web at:
もともとXerox Corporationの責任であったイーサネットパラメーターの登録機関は、現在IEEE登録機関であり、Webで入手可能です。
http://standards.ieee.org/regauth/
Anyone may apply to that Authority for parameters. They may impose fees or other requirements but commonly waive fees for applications from standards development organizations.
誰でもその権限にパラメーターを申請することができます。彼らは料金またはその他の要件を課すことができますが、一般的に標準開発組織からの申請の料金を免除します。
A list of some allocated OUIs and IABs and their holders is downloadable from the IEEE Registration Authority site.
割り当てられたOUISおよびIABSおよびその所有者のリストは、IEEE登録局のサイトからダウンロード可能です。
The OUI 00-00-5E has been allocated to IANA.
OUI 00-00-5EはIANAに割り当てられました。
The contributions and support of the following people, listed in alphabetic order, is gratefully acknowledged:
アルファベット順にリストされている次の人々の貢献とサポートは、感謝されています。
Bernard Aboba, Scott O. Bradner, Ian Calder, Michelle Cotton, Lars Eggert, Eric Gray, Alfred Hoenes, Russ Housley, Charlie Kaufman, Erik Nordmark, Dan Romascanu, Mark Townsley, and Geoff Thompson.
バーナード・アボバ、スコット・O・ブラッドナー、イアン・カルダー、ミシェル・コットン、ラース・エガート、エリック・グレイ、アルフレッド・ホーネス、ラス・ヒューズリー、チャーリー・カウフマン、エリック・ノードマーク、ダン・ロマスカヌ、マーク・タウンズリー、ジェフ・トンプソン。
Section 2.1 discusses EUI-48 (Extended Unique Identifier 48) MAC identifiers, their relationship to OUIs and IABs, and allocations under the IANA OUI. Section 2.2 extends this to EUI-64 identifiers. Section 2.3 discusses other IETF MAC identifier use not under the IANA OUI.
セクション2.1では、EUI-48（拡張された一意の識別子48）MAC識別子、OUIとIABとの関係、およびIANA OUIにおける割り当てについて説明します。セクション2.2では、これをEUI-64識別子に拡張します。セクション2.3では、IANA OUIの下ではない他のIETF MAC識別子の使用について説明します。
48-bit MAC "addresses" are the most commonly used Ethernet interface identifiers. Those that are globally unique are also called EUI-48 identifiers. An EUI-48 is structured into an initial 3-octet OUI (Organizationally Unique Identifier) and an additional 3 octets assigned by the OUI holder. For organizations not requiring 3 octets' worth of identifiers, the IEEE allocates IABs (Individual Address Blocks) instead, where the first 4 1/2 octets (36 bits) are assigned, giving the holder of the IAB 1 1/2 octets (12 bits) they can control.
48ビットMAC「アドレス」は、最も一般的に使用されるイーサネットインターフェイス識別子です。グローバルに一意のものは、EUI-48識別子とも呼ばれます。EUI-48は、最初の3オクテットのOUI（組織的に一意の識別子）と、OUIホルダーによって割り当てられた追加の3オクテットに構造化されています。3オクテットの相当識別子を必要としない組織の場合、IEEEは代わりにIABS（個々のアドレスブロック）を割り当てます。最初の4 1/2オクテット（36ビット）が割り当てられ、IAB 1 1/2オクテット（12のホルダー）にビット）彼らは制御できます。
The IEEE describes its assignment procedures and policies for IEEE 802 related identifiers in [802_O&A].
IEEEは、[802_O＆A]のIEEE 802関連識別子の割り当て手順とポリシーについて説明しています。
Two bits within the initial 3 octets of an EUI-48 have special significance: the Group bit (01-00-00) and the Local bit (02-00-00). OUIs and IABs are allocated with the Local bit zero and the Group bit unspecified. Multicast identifiers may be constructed by turning on the Group bit, and unicast identifiers constructed by leaving the Group bit zero.
EUI-48の最初の3オクテット内の2つのビットには、グループビット（01-00-00）とローカルビット（02-00-00）という特別な重要性があります。OUISとIABは、ローカルビットゼロで割り当てられ、グループは不特定のビットです。マルチキャスト識別子は、グループビットをオンにすることで構築でき、グループをビットゼロにすることで構築されたユニキャスト識別子を構築できます。
For globally unique EUI-48 identifiers allocated by an OUI or IAB owner, the Local bit is zero. If the Local bit is a one, the identifier is considered by IEEE 802 to be a local identifier under the control of the local network administrator. If the Local bit is on, the holder of an OUI (or IAB) has no special authority over 48-bit MAC identifiers whose first 3 (or 4 1/2) octets correspond to their OUI (or IAB).
OUIまたはIABの所有者によって割り当てられたグローバルなユニークなEUI-48識別子の場合、ローカルビットはゼロです。ローカルビットが1つの場合、識別子はIEEE 802によって、ローカルネットワーク管理者の制御下のローカル識別子と見なされます。ローカルビットがオンの場合、OUI（またはIAB）の所有者には、最初の3（または4 1/2）のオクテットがOUI（またはIAB）に対応する48ビットMAC識別子を超える特別な権限がありません。
The OUI 00-00-5E has been assigned to IANA as stated in Section 1.2.1 above. This includes 2**24 EUI-48 multicast identifiers from 01-00-5E-00-00-00 to 01-00-5E-FF-FF-FF and 2**24 EUI-48 unicast identifiers from 00-00-5E-00-00-00 to 00-00-5E-FF-FF-FF.
OUI 00-00-5Eは、上記のセクション1.2.1に記載されているように、IANAに割り当てられています。これには、01-00-5E-00-00-00-00から01-00-5E-FF-FF-FF-FF-FF-24 EUI-48ユニキャスト識別子から00-00-の2 ** 24 EUI-48マルチキャスト識別子が含まれます。5e-00-00-00〜00-00-5e-ff-ff-ff。
Of these EUI-48 identifiers, the following allocations have been made thus far:
これらのEUI-48識別子のうち、これまでに以下の割り当てが行われました。
o The 2**23 multicast identifiers from 01-00-5E-00-00-00 through 01-00-5E-7F-FF-FF have been allocated for IPv4 multicast [RFC1112].
o 01-00-5E-00-00-00から01-00-5E-7F-FF-FFから2*23のマルチキャスト識別子がIPv4マルチキャスト[RFC1112]に割り当てられています。
o The 2**20 multicast identifiers from 01-00-5E-80-00-00 through 01-00-5E-8F-FF-FF have been allocated for MPLS multicast [RFC5332].
o 01-00-5E-80-00-00から01-00-5E-8F-FF-FFから2 ** 20マルチキャスト識別子がMPLSマルチキャスト[RFC5332]に割り当てられています。
o The 2**8 unicast identifiers from 00-00-5E-00-00-00 through 00-00-5E-00-00-FF are reserved and require IESG Ratification for allocation (see Section 5.1).
o 00-00-5E-00-00-00-00から00-00-5E-00-00-00-ffの2 ** 8ユニキャスト識別子は予約されており、割り当てにはIESG批准が必要です（セクション5.1を参照）。
o The 2**8 unicast identifiers from 00-00-5E-00-01-00 through 00-00-5E-00-01-FF have been allocated for the Virtual Router Redundancy Protocol (VRRP) [RFC3768].
o 00-00-5E-00-01-00から00-00-5E-00-01-FFの2 ** 8ユニキャスト識別子は、仮想ルーター冗長プロトコル（VRRP）[RFC3768]に割り当てられています。
EUI-48 allocations under the current or a future IANA OUI (see Section 5.2) must meet the following requirements:
現在または将来のIANA OUI（セクション5.2を参照）に基づくEUI-48の割り当ては、次の要件を満たす必要があります。
o must be for standards purposes (either for an IETF Standard or other standard related to IETF work),
o 標準目的でなければなりません（IETF標準またはIETF作業に関連するその他の標準のいずれか）、
o must be for a block of a power-of-two identifiers starting at a boundary that is an equal or greater power of two, including the allocation of one (2**0) identifier,
o 1つの（2 ** 0）識別子の割り当てを含む、2つの等しいまたはより大きなパワーである境界から始まる2つの力の識別子のブロックのために必要です。
o must not be used to evade the requirement for vendors to obtain their own block of identifiers from the IEEE, and
o ベンダーがIEEEから識別子の独自のブロックを取得するための要件を回避するために使用してはなりません。
o must be documented in an Internet-Draft or RFC.
o インターネットドラフトまたはRFCで文書化する必要があります。
In addition, approval must be obtained as follows (see the procedure in Section 5.1):
さらに、承認は次のように取得する必要があります（セクション5.1の手順を参照）。
Small to medium allocations of a block of 1, 2, 4, ..., 32768, 65536 (2**0, 2**1, 2**2, ..., 2**15, 2**16) EUI-48 identifiers require Expert Review.
1、2、4、...、32768、65536（2 ** 0、2 ** 1、2 ** 2、...、2 ** 15、2 ** 16のブロックの小〜中程度の割り当て）EUI-48識別子は専門家のレビューが必要です。
Large allocations of 131072 (2**17) or more EUI-48 identifiers require IESG Ratification (see Section 5.1).
131072（2 ** 17）以上のEUI-48識別子の大規模な割り当てには、IESG批准が必要です（セクション5.1を参照）。
To simplify record keeping, all future allocations of 256 (2**8) or fewer identifiers shall have the Group bit unspecified, that is, shall be allocations of parallel equal-size blocks of multicast and unicast identifiers, even if one of these two types is not needed for the proposed use. The only exception is that requests for unicast-only identifier blocks of any size may be allocated out of the remaining identifiers in the large unicast range from 00-00-5E-00-02-00 to 00-00-5E-8F-FF-FF.
記録保持を簡素化するために、256（2 ** 8）以下のすべての将来の割り当ては、グループを少し特定していないものとする必要があります。つまり、これら2つのいずれかであっても、マルチキャストおよびユニキャスト識別子の並列等サイズブロックの割り当てとなります。提案された使用にはタイプは必要ありません。唯一の例外は、任意のサイズのユニキャストのみの識別子ブロックのリクエストが、00-00-5E-00-02-00から00-00-5E-8F-FIFの大きなユニキャスト範囲の残りの識別子から割り当てることができることです。-ff。
IEEE also defines a system of 64-bit MAC identifiers including EUI-64s. Uptake of these "MAC-64" identifiers has been limited. They are currently used in constructing some IPv6 Interface Identifiers as described below and by the following IEEE standards:
IEEEは、EUI-64を含む64ビットMAC識別子のシステムも定義しています。これらの「MAC-64」識別子の取り込みは限られています。現在、以下に説明するように、以下のIEEE標準でいくつかのIPv6インターフェイス識別子の構築に使用されています。
o IEEE 1394 (also known as FireWire and i.Link),
o IEEE 1394（FirewireおよびI.Linkとも呼ばれます）、
o IEEE 802.15.4 (also known as ZigBee).
o IEEE 802.15.4（Zigbeeとも呼ばれます）。
Adding a 5-octet (40-bit) extension to a 3-octet (24-bit) OUI forms an EUI-64 identifier under that OUI. As with EUI-48 identifiers, the OUI has the same Group/unicast and Local/Global bits.
5-OCTET（40ビット）拡張機能を3オクテット（24ビット）OUIに追加すると、そのOUIの下でEUI-64識別子が形成されます。EUI-48識別子と同様に、OUIは同じグループ/ユニキャストとローカル/グローバルビットを持っています。
The discussion below is almost entirely in terms of the "Modified" form of EUI-64 identifiers; however, anyone allocated such an identifier also has the unmodified form and may use it as a MAC identifier on any link that uses such 64-bit identifiers for interfaces.
以下の議論は、EUI-64識別子の「修正された」形式のほぼ完全にあります。ただし、そのような識別子を割り当てた人は誰でも、変更されていないフォームを持っており、インターフェイスにこのような64ビット識別子を使用するリンクでMAC識別子として使用できます。
MAC-64 identifiers are used to form the lower 64 bits of some IPv6 addresses (Section 2.5.1 and Appendix A of [RFC4291] and Appendix A of [RFC5214]). When so used, the MAC-64 is modified by inverting the Local/Global bit to form an IETF "Modified EUI-64 identifier". Below is an illustration of a Modified EUI-64 identifier under the IANA OUI, where aa-bb-cc-dd-ee is the extension.
MAC-64の識別子は、一部のIPv6アドレスの64ビット（セクション2.5.1および[RFC4291]の付録Aおよび[RFC5214]の付録A）を形成するために使用されます。そのように使用すると、MAC-64はローカル/グローバルビットを反転させることにより変更され、IETF「修正されたEUI-64識別子」を形成します。以下は、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 Local/Global bit is inverted compared with EUI-48 identifiers. It is the globally unique values (universal scope) that have the 02 bit on in the first octet, while those with this bit off are locally assigned and out of scope for global allocation.
修正されたEUI-64識別子では、ローカル/グローバルビットの感覚がEUI-48識別子と比較して反転されるため、最初のオクテットは00ではなく02として表示されます。最初のオクテットで02ビットがオンになっているのは、グローバルに一意の値（ユニバーサルスコープ）であり、このビットのあるものはローカルに割り当てられ、グローバル割り当ての範囲外です。
The Local/Global bit was inverted to make it easier for network operators to type in local-scope identifiers. Thus, such Modified EUI-64 identifiers as 1, 2, etc. (ignoring leading zeros), are local. Without the modification, they would have to be 02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc., to be local.
ローカル/グローバルビットは、ネットワークオペレーターがローカルスコープ識別子を簡単に入力できるようにするために反転しました。したがって、このような修正されたEUI-64識別子は、1、2など（主要なゼロを無視する）がローカルです。変更がなければ、ローカルであるためには、02-00-00-00-00-00-00-01、02-00-00-00-00-00-02などでなければなりません。
As with MAC-48 identifiers, the 01 bit on in the first octet indicates a group identifier.
MAC-48識別子と同様に、最初のオクテットの01ビットオンは、グループ識別子を示します。
When the first two octets of the extension of a Modified EUI-64 identifier are FF-FE, the remainder of the extension is a 24-bit value as assigned by the OUI owner for an EUI-48. For example:
変更されたEUI-64識別子の拡張の最初の2オクテットがFF-FEである場合、拡張の残りはEUI48のOUI所有者によって割り当てられた24ビット値です。例えば：
02-00-5E-FF-FE-yy-yy-yy or 03-00-5E-FF-FE-yy-yy-yy
02-00-5e-ff-fe-yyyyyyまたは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 Local/Global bit.
ここで、yy-yy-yyは（eui-48グローバルユニキャストまたはマルチキャスト識別子の部分の部分です。したがって、IANA OUIの下にある1つまたは複数のEUI-48識別子の保有者は、EUI-48識別子の中央にFF-FEを挿入し、局所/局所/挿入することで形成できる修正されたEUI-64識別子の数が同数のものを持っています。グローバルビット。
(Note: [EUI-64] defines FF-FF as the bits to be inserted to create an IEEE EUI-64 identifier from a MAC-48 identifier. That document says the FF-FE value is used when starting with an EUI-48 identifier. The IETF uses only FF-FE to create Modified EUI-64 identifiers from 48-bit Ethernet station identifiers regardless of whether they are EUI-48 or MAC-48 local identifiers. EUI-48 and local MAC-48 identifiers are syntactically equivalent, and this doesn't cause any problems in practice.)
（注：[EUI-64]は、FF-FFを挿入するビットとして定義して、MAC-48識別子からIEEE EUI-64識別子を作成します。このドキュメントでは、FF-FE値はEUI48で始まるときに使用されると述べています。識別子。IETFはFF-FEのみを使用して、EUI-48またはMAC-48のローカル識別子であるかどうかに関係なく、48ビットイーサネットステーション識別子から修正されたEUI-64識別子を作成します。EUI-48およびローカルMAC-48識別子は統合的に同等です、そして、これは実際には問題を引き起こしません。）
In addition, certain Modified EUI-64 identifiers under the IANA OUI are reserved for holders of IPv4 addresses as follows:
さらに、IANA OUIの下で特定の変更されたEUI-64識別子は、次のようにIPv4アドレスの保有者向けに予約されています。
02-00-5E-FE-xx-xx-xx-xx
02-00-5E-FE-XX-XX-XX-XX
where xx-xx-xx-xx is a 32-bit IPv4 address. For Modified EUI-64 identifiers based on an IPv4 address, the Local/Global bit should be set to correspond to whether the IPv4 address is local or global. (Keep in mind that the sense of the Modified EUI-64 identifier Local/Global bit is reversed from that in (unmodified) MAC-64 identifiers.)
ここで、XX-XX-XX-XXは32ビットIPv4アドレスです。IPv4アドレスに基づいた修正されたEUI-64識別子の場合、ローカル/グローバルビットは、IPv4アドレスがローカルかグローバルかに対応するように設定する必要があります。（修正されたEUI-64識別子ローカル/グローバルビットの感覚は、（変更されていない）MAC-64識別子のそれから逆転していることに留意してください。）
The following table shows which Modified EUI-64 identifiers under the IANA OUI are reserved, used, or available as indicated.
次の表は、IANA OUIの下でどの修正されたEUI-64識別子が予約、使用、または指定されているように利用可能であるかを示しています。
02-00-5E-00-00-00-00-00 to 02-00-5E-0F-FF-FF-FF-FF reserved
02-00-5E-00-00-00-00-00〜02-00-5E-0F-FF-FF-FFは予約されています
02-00-5E-10-00-00-00-00 to 02-00-5E-EF-FF-FF-FF-FF available for allocation
02-00-5E-10-00-00-00-00から02-00-5E-EF-FF-FF-FF-FFは、割り当てに利用可能です
02-00-5E-F0-00-00-00-00 to 02-00-5E-FD-FF-FF-FF-FF reserved
02-00-5E-F0-00-00-00-00から02-00-5E-FFF-FF-FF-FFは予約されています
02-00-5E-FE-00-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF used by IPv4 address holders as described above
02-00-5E-FE-00-00-00-00から02-00-5E-FE-FF-FF-FF-FFは、上記のようにIPv4アドレス保有者によって使用されます
02-00-5E-FF-00-00-00-00 to 02-00-5E-FF-FD-FF-FF-FF reserved
02-00-5E-FF-00-00-00-00〜02-00-5E-FF-FF-FF-FFは予約されています
02-00-5E-FF-FE-00-00-00 to 02-00-5E-FF-FE-FF-FF-FF used by holders of EUI-48 identifiers under the IANA OUI as described above
02-00-5E-FF-FE-00-00-00から02-00-5E-FF-FE-FF-FF-FFは、上記のIANA OUIの下でEUI-48識別子の保有者が使用する
02-00-5E-FF-FF-00-00-00 to 02-00-5E-FF-FF-FF-FF-FF reserved
02-00-5e-ff-ff-00-00-00〜02-00-5e-ff-ff-ff-ffは予約されています
The reserved identifiers above require IESG Ratification (see Section 5.1) for allocation. IANA EUI-64 identifier allocations under the IANA OUI must meet the following requirements:
上記の予約された識別子には、割り当てのためにIESG批准（セクション5.1を参照）が必要です。IANA EUI-64識別子の割り当てIANA OUIの下での割り当ては、次の要件を満たす必要があります。
o must be for standards purposes (either for an IETF Standard or other standard related to IETF work),
o 標準目的でなければなりません（IETF標準またはIETF作業に関連するその他の標準のいずれか）、
o must be for a block of a power-of-two identifiers starting at a boundary which is an equal or greater power of two, including the allocation of one (2**0) identifier,
o 1つの（2 ** 0）識別子の割り当てを含む、2つの等しいまたはより大きな能力である境界から始まる2つの容量識別子のブロック用でなければなりません。
o must not be used to evade the requirement for vendors to obtain their own block of identifiers from the IEEE, and
o ベンダーがIEEEから識別子の独自のブロックを取得するための要件を回避するために使用してはなりません。
o must be documented in an Internet Draft or RFC.
o インターネットドラフトまたはRFCで文書化する必要があります。
In addition, approval must be obtained as follows (see the procedure in Section 5.1):
さらに、承認は次のように取得する必要があります（セクション5.1の手順を参照）。
Small to medium allocations of a block of 1, 2, 4, ..., 134217728, 268435456 (2**0, 2**1, 2**2, ..., 2**27, 2**28) EUI-64 identifiers require Expert Review.
1、2、4、...、134217728、268435456（2 ** 0、2 ** 1、2 ** 2、...、2 ** 27、2 ** 28の1、2、4、...、134217728、268435456の小規模から中程度の割り当て）EUI-64識別子には、専門家のレビューが必要です。
Allocations of any size, including 536870912 (2**29) or more EUI-64 identifiers, may be made with IESG Ratification (see Section 5.1).
536870912（2 ** 29）以上のEUI-64識別子を含むあらゆるサイズの割り当ては、IESG批准を使用して作成できます（セクション5.1を参照）。
To simplify record keeping, all allocations of 65536 (2**16) or less EUI-64 identifiers shall have the Group bit unspecified, that is, shall be allocations of parallel equal size blocks of multicast and unicast identifiers, even if one of these two types is not needed for the proposed use.
記録保持を簡素化するには、65536（2 ** 16）以下のEUI-64の識別子のすべての割り当てを、グループを不特定のものにする必要があります。提案された使用には2つのタイプは必要ありません。
There are two other blocks of MAC-48 identifiers that are used by the IETF as described below.
以下に説明するIETFで使用されるMAC-48識別子には、他にも2つのブロックがあります。
All MAC-48 multicast identifiers prefixed "33-33" (that is, the 2**32 multicast MAC identifiers in the range from 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF) are used by the IETF for global IPv6 multicast [RFC2464]. In all these identifiers, the Group bit (the bottom bit of the first octet) is on, as is required to work properly with existing hardware as a multicast identifier. They also have the Local bit on and are used for this purpose in IPv6 networks.
すべてのMAC-48マルチキャスト識別子は「33-33」（つまり、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-FF-FF-FF-FF-FF-FF-FF-FF-FF-FFFの範囲の2 ** 32マルチキャストMAC識別子です。FF）は、IETFによってグローバルIPv6マルチキャスト[RFC2464]に使用されます。これらすべての識別子において、既存のハードウェアをマルチキャスト識別子として適切に作業するために必要なグループビット（最初のオクテットの下部ビット）がオンになっています。また、ローカルビットがあり、IPv6ネットワークでこの目的に使用されています。
(Historical note: It was the custom during IPv6 design to use "3" for unknown or example values, and 3333 Coyote Hill Road, Palo Alto, California, is the address of PARC (Palo Alto Research Center, formerly "Xerox PARC"). Ethernet was originally specified by Digital Equipment Corporation, Intel Corporation, and Xerox Corporation. The pre IEEE [802.3] Ethernet protocol has sometimes been known as "DIX" Ethernet from the first letters of the names of these companies.)
（歴史的注：IPv6デザイン中は、不明または例の値に「3」を使用することが習慣でした。カリフォルニア州パロアルトのコヨーテヒルロード3333はPARCの住所です（以前は「Xerox PARC」）イーサネットはもともと、Digital Equipment Corporation、Intel Corporation、およびXerox Corporationによって指定されていました。PreIEEE [802.3] Ethernet Protocolは、これらの会社の最初の文字から「DIX」イーサネットとして知られていることがあります。
The Informational [RFC2153] declared the 3-octet values from CF-00-00 through CF-FF-FF to be OUIs available for allocation by IANA to software vendors for use in PPP [RFC1661] or for other uses where vendors do not otherwise need an IEEE-assigned OUI. It should be noted that, when used as MAC-48 prefixes, these values have the Local and Group bits on, while all IEEE-allocated OUIs have those bits off. The Group bit is meaningless in PPP. To quote [RFC2153]: "The 'CF0000' series was arbitrarily chosen to match the PPP NLPID 'CF', as a matter of mnemonic convenience."
情報[RFC2153]は、CF-00-00からCF-FF-FFの3オクテットの値を、IANAがPPPで使用するソフトウェアベンダーへの割り当て[RFC1661]またはベンダーがそうでない場合に使用できるようにOUIを利用できるように宣言しました。IEEEが割り当てられたOUIが必要です。MAC-48のプレフィックスとして使用する場合、これらの値にはローカルおよびグループがオンになり、IEEEに割り当てられたすべてのOUIがそれらのビットをオフにしていることに注意してください。グループビットはPPPで意味がありません。[RFC2153]を引用するために、「「CF0000」シリーズは、ニーモニックな利便性の問題として、PPP NLPID「CF」と一致するように任意に選択されました。」
CF-00-00 is reserved, and IANA lists multicast identifier CF-00-00-00-00-00 as used for Ethernet loopback tests.
CF-00-00は予約されており、IANAはイーサネットループバックテストに使用されるマルチキャスト識別子CF-00-00-00-00-00をリストしています。
In over a decade of availability, only a handful of values in the 'CF Series' have been allocated. (See http://www.iana.org under both Ethernet Parameters and PPP Parameters.)
10年以上にわたる可用性で、「CFシリーズ」のほんの一握りの値だけが割り当てられています。（イーサネットパラメーターとPPPパラメーターの両方の下でhttp://www.iana.orgを参照してください。）
The IANA Considerations in [RFC2153] are updated as follows (no technical changes are made): Use of these identifiers based on IANA allocation is deprecated. IANA is directed not to allocate any further values in the 'CF Series'.
[RFC2153]のIANAの考慮事項は、次のように更新されます（技術的な変更は行われません）：IANAの割り当てに基づくこれらの識別子の使用は非推奨です。IANAは、「CFシリーズ」にそれ以上の価値を割り当てないように指示されています。
Ethernet protocol parameters provide a means of indicating the contents of a frame -- for example, that its contents are IPv4 or IPv6.
イーサネットプロトコルパラメーターは、フレームの内容を示す手段を提供します。たとえば、その内容はIPv4またはIPv6であることを示しています。
The concept has been extended to labeling by "tags". A tag in this sense is a prefix whose type is identified by an Ethertype that is then followed by either another tag, an Ethertype, or an LSAP protocol indicator for the "main" body of the frame, as described below. Traditionally in the [802_O&A] world, tags are fixed length and do not include any encoding of their own length. Thus, anything that is processing a frame cannot, in general, safely process anything in the frame past an Ethertype it does not understand. An example is the C-tag (formerly the Q-tag) [802.1Q]. It provides customer VLAN and priority information for a frame.
この概念は、「タグ」によるラベル付けに拡張されています。この意味でのタグは、以下に説明するように、フレームの「メイン」ボディの別のタグ、EtherType、またはLSAPプロトコルインジケーターのいずれかが続いて、そのタイプに識別されるプレフィックスです。伝統的に[802_O＆A]世界では、タグは固定されており、独自の長さのエンコードは含まれていません。したがって、フレームを処理しているものはすべて、一般に、理解できないetertypeを過去にフレーム内のものを安全に処理することはできません。例は、Cタグ（以前はQタグ）[802.1Q]です。顧客VLANとフレームの優先情報を提供します。
There are two types of protocol identifier parameters that can occur in Ethernet frames after the initial MAC-48 destination and source identifiers:
最初のMAC-48宛先とソース識別子の後にイーサネットフレームで発生する可能性のあるプロトコル識別子パラメーターには、次の2つのタイプがあります。
Ethertypes: These are 16-bit identifiers appearing as the initial two octets after the MAC destination and source (or after a tag) which, when considered as an unsigned integer, are equal to or larger than 0x0600.
ETHERTYPES：これらは、MACの宛先とソース（またはタグの後）の後の最初の2オクテットとして表示される16ビット識別子であり、署名されていない整数と見なされると、0x0600以上です。
LSAPs: These are 8-bit protocol identifiers that occur in pairs immediately after an initial 16-bit (two octet) remaining frame length, which is in turn after the MAC destination and source (or after a tag). Such a length must, when considered as an unsigned integer, be less than 0x5DC or it could be mistaken as an Ethertype. LSAPs (Link-Layer Subnet Access Points) occur in pairs where one is intended to indicate the source protocol handler and one the destination protocol handler; however, use cases where the two are different have been relatively rare.
LSAP：これらは、最初の16ビット（2オクテット）の残りフレーム長の直後にペアで発生する8ビットプロトコル識別子であり、Macの宛先とソースの後（またはタグの後）。このような長さは、署名されていない整数と見なされる場合、0x5dc未満であるか、倫理と誤解される可能性があります。LSAP（リンク層サブネットアクセスポイント）は、ソースプロトコルハンドラーを示し、宛先プロトコルハンドラーを示すことを目的としているペアで発生します。ただし、2つが異なるユースケースは比較的まれです。
Neither Ethertypes nor LSAPs are allocated by IANA; instead, they are allocated by the IEEE Registration Authority (see Section 1.2 above and the Ethertype Annex below). However, both LSAPs and Ethertypes have extension mechanisms so that they can be used with five-octet Ethernet protocol identifiers under an OUI, including those allocated by IANA under the IANA OUI.
EthertypesもLSAPもIANAによって割り当てられていません。代わりに、IEEE登録機関によって割り当てられます（上記のセクション1.2および以下のEtherType付録を参照）。ただし、LSAPとEthertypesの両方に拡張メカニズムがあるため、IANA OUIの下でIANAによって割り当てられたものを含む、OUIの下で5オクテットのイーサネットプロトコル識別子で使用できます。
When using the IEEE 802 LLC format (SNAP) [802_O&A] for a frame, an OUI-based protocol identifier can be expressed as follows:
フレームにIEEE 802 LLC形式（SNAP）[802_O＆A]を使用する場合、OUIベースのプロトコル識別子は次のように表現できます。
xx-xx-AA-AA-03-yy-yy-yy-zz-zz
xx-xx-aa-aa-03-yy-yy-zz-zz
where xx-xx is the frame length and, as above, must be small enough not to be confused with an Ethertype; "AA" is the LSAP that indicates this use and is sometimes referred to as the SNAP SAP; "03" is the LLC control octet indicating datagram service; yy-yy-yy is an OUI; and zz-zz is a protocol number, under that OUI, allocated by the OUI owner. The odd five-octet length for such OUI-based protocol identifiers was chosen so that, with the LLC control octet ("03"), the result is 16-bit aligned.
ここで、XX-XXはフレームの長さであり、上記のように、EtherTypeと混同しないように十分に小さくなければなりません。「AA」は、この使用を示すLSAPであり、スナップSAPと呼ばれることもあります。「03」は、データグラムサービスを示すLLCコントロールオクテットです。YY-YY-YYはOUIです。ZZ-ZZは、OUIの所有者によって割り当てられたそのOUIの下で、プロトコル番号です。このようなOUIベースのプロトコル識別子の奇妙な5オクターテの長さが選択されたため、LLCコントロールオクター（ "03"）を使用して、結果が16ビットアライメントされました。
When using an Ethertype to indicate the main type for a frame body, the special "OUI Extended Ethertype" 88-B7 is available. Using this Ethertype, a frame body can begin with
EtherTypeを使用してフレームボディのメインタイプを示す場合、特別な「OUI拡張型EtherType」88-B7が利用可能です。このETHERTYPEを使用して、フレームボディは始めることができます
88-B7-yy-yy-yy-zz-zz
88-b7-yyyyy-zz-zz
where yy-yy-yy and zz-zz have the same meaning as in the SNAP format described above.
ここで、Yy-yyとzz-zzは、上記のスナップ形式と同じ意味を持っています。
It is also possible, within the SNAP format, to use an arbitrary Ethertype. Putting the Ethertype as the zz-zz field after an all zeros OUI (00-00-00) does this. It looks like
また、スナップ形式内で、任意の倫理を使用することも可能です。すべてのZeros OUI（00-00-00）の後にEtherTypeを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です。
(Note that, at this point, the 802 protocol syntax facilities are sufficiently powerful that they could be chained indefinitely. Whether support for such chaining is generally required is not clear, but [802_O&A] requires support for
（この時点で、802プロトコル構文機能は十分に強力であり、無期限に連鎖することができます。そのようなチェーンのサポートが一般的に必要かどうかは明確ではありませんが、[802_O＆A]はサポートが必要です
xx-xx-AA-AA-03-00-00-00-88-B7-yy-yy-yy-zz-zz
xx-xx-aa-aa-03-00-00-88-b7-yyyy-zz-zz
even though this could be more efficiently expressed by simply pinching out the "00-00-00-88-B7" in the middle.)
ただし、これは、中央の「00-00-00-88-B7」を単につまむだけでより効率的に表現できます。）
As well as labeling frame contents, 802 Protocol types appear within NBMA (Non-Broadcast Multi-Access) Next Hop Resolution Protocol [RFC2332] messages. Such messages have provisions for both two octet Ethertypes and OUI based protocol types.
フレームコンテンツのラベル付けに加えて、802のプロトコルタイプがNBMA（非放送マルチアクセス）次のホップ解像度プロトコル[RFC2332]メッセージ内に表示されます。このようなメッセージには、2つのOctet EthertypesとOUIベースのプロトコルタイプの両方に関する規定があります。
Two-octet protocol numbers under the IANA OUI are available, as in
IANA OUIの下での2オクテットプロトコル番号は、ように利用可能です
xx-xx-AA-AA-03-00-00-5E-zz-zz.
xx-xx-aa-aa-03-00-00-5e-zz-zz。
A number of such allocations have been made out of the 2**16 protocol numbers available from 00-00-5E-00-00 to 00-00-5E-FF-FF (see [IANA]). The extreme values of this range, 00-00-5E-00-00 and 00-00-5E-FF-FF, are reserved and require IESG Ratification for allocation (see Section 5.1). New allocations of SNAP SAP protocol (zz-zz) numbers under the IANA OUI must meet the following requirements:
このような割り当ての多くは、00-00-5E-00-00から00-00-5E-FF-FFから利用可能な2 ** 16のプロトコル番号から作成されています（[IANA]を参照）。この範囲の00-00-5E-00-00および00-00-5E-FF-FFの極端な値は予約されており、割り当てのためにIESG批准が必要です（セクション5.1を参照）。IANA OUIの下でのSNAP SAPプロトコル（ZZ-ZZ）数の新しい割り当ては、次の要件を満たす必要があります。
o the allocation must be for standards use (either for an IETF Standard or other standard related to IETF work),
o 割り当ては、標準使用のためのものでなければなりません（IETF標準またはIETF作業に関連するその他の標準のいずれか）、
o it must be documented in an Internet-Draft or RFC, and
o インターネットドラフトまたはRFCで文書化する必要があります。
o such protocol numbers are not to be allocated for any protocol that has an Ethertype (because that can be expressed by putting an all zeros "OUI" before the Ethertype as described above).
o このようなプロトコル番号は、ethertypeを備えたプロトコルに割り当てられてはなりません（上記のようにEtherTypeの前にAll Zeros "Oui"を配置することで表現できるため）。
In addition, the Expert Review (or IESG Ratification for the two reserved values) must be obtained using the procedure specified in Section 5.1.
さらに、セクション5.1で指定された手順を使用して、専門家のレビュー（または2つの予約値のIESG批准）を取得する必要があります。
Some IEEE 802 and other protocols provide for parameters based on an OUI beyond those discussed above. Such parameters most commonly consist of an OUI plus one octet of additional value. They are usually called "vendor specific" parameters, although "organization specific" might be more accurate. They would look like
一部のIEEE 802および他のプロトコルは、上記のものを超えたOUIに基づいたパラメーターを提供します。このようなパラメーターは、最も一般的には、OUIと追加価値の1オクテットで構成されています。これらは通常、「ベンダー固有の」パラメーターと呼ばれますが、「組織固有の」はより正確かもしれません。彼らはどのように見えるでしょう
yy-yy-yy-zz
yyyyyy-zz
where yy-yy-yy is the OUI and zz is the additional specifier. An example is the Cipher Suite Selector in IEEE 802.11 ([802.11], page 125).
ここで、yy-yy-yyはoui、zzは追加の仕様です。例は、IEEE 802.11（[802.11]、125ページ）の暗号スイートセレクターです。
Values may be allocated under the IANA OUI for such other OUI-based parameter usage by Expert Review except that, for each use, the additional specifier values consisting of all zero bits and all one bits (0x00 and 0xFF for a one-octet specifier) are reserved and require IESG Ratification (see Section 5.1) for allocation. The allocations must be for standards use (either for an IETF Standard or other standard related to IETF work) and be documented in an Internet-Draft or RFC. The first time a value is allocated for a particular parameter of this type, an IANA registry will be created to contain that allocation and any subsequent allocations of values for that parameter under the IANA OUI. The Expert will specify the name of the registry.
値は、すべてのゼロビットとすべてのビット（1オクセット仕様の0x00および0xff）で構成される追加の仕様値を使用することを除いて、そのような他のOUIベースのパラメーター使用にIANA OUIの下で割り当てられる場合があります。割り当てには予約されており、IESG批准（セクション5.1を参照）が必要です。割り当ては、標準の使用（IETF標準またはIETF作業に関連するその他の標準のいずれか）に使用し、インターネットドラフトまたはRFCで文書化する必要があります。このタイプの特定のパラメーターに値が最初に割り当てられたとき、IANA OUIの下でそのパラメーターのその配分とその後の値の割り当てを含むようにIANAレジストリが作成されます。専門家はレジストリの名前を指定します。
(If a different policy from that above is required for such a parameter, a BCP or Standards Track RFC must be adopted updating this BCP and specifying the new policy and parameter.)
（このようなパラメーターに上記とは異なるポリシーが必要な場合、BCPまたは標準の追跡RFCを採用して、このBCPを更新し、新しいポリシーとパラメーターを指定する必要があります。）
The entirety of this document concerns IANA Considerations for the allocation of Ethernet parameters in connection with the IANA OUI and related matters.
このドキュメント全体は、IANA OUIおよび関連する問題に関連するイーサネットパラメーターの割り当てに関するIANAの考慮事項に関するものです。
Specifically:
具体的には：
Section 1.2.1 provides information on the IANA-assigned OUI.
セクション1.2.1は、IANAが割り当てられたOUIに関する情報を提供します。
Section 2.1.1 lists current EUI-48 assignments under this OUI.
セクション2.1.1には、このOUIに基づく現在のEUI-48の割り当てを示します。
Section 2.1.2 specifies IANA considerations for EUI-48 assignments.
セクション2.1.2は、EUI-48の割り当てに関するIANAの考慮事項を指定します。
Section 2.2.2 specifies IANA considerations for EUI-64 assignments.
セクション2.2.2は、EUI-64割り当てのIANAの考慮事項を指定します。
Section 3.1 provides a pointer to current protocol identifier assignments under the IANA OUI, and specifies IANA considerations for protocol identifier assignments.
セクション3.1は、IANA OUIの下での現在のプロトコル識別子割り当てへのポインターを提供し、プロトコル識別子割り当てのIANAの考慮事項を指定します。
Section 4 briefly provides IANA considerations relating to OUI-based miscellaneous allocations.
セクション4では、OUIベースのその他の割り当てに関するIANAの考慮事項を簡単に説明します。
This section specifies the procedure for Expert Review and IESG Ratification of MAC, protocol, and other IANA OUI-based identifiers. The Expert(s) referred to in this document shall consist of one or more persons appointed by and serving at the pleasure of the IESG. The procedure described for Expert Review allocations in this document is fully consistent with the IANA Expert Review policy described in Section 4.1 of [RFC5226].
このセクションでは、MAC、プロトコル、およびその他のIANA OUIベースの識別子の専門家レビューとIESG批准の手順を指定します。この文書で言及されている専門家は、IESGの喜びで任命され、奉仕する1人以上の人で構成されます。このドキュメントの専門家レビューの割り当てについて説明した手順は、[RFC5226]のセクション4.1で説明されているIANAの専門家レビューポリシーと完全に一致しています。
While finite, the universe of code points from which Expert judged allocations will be made is felt to be large enough that the requirements given in this document and the Experts' good judgment are sufficient guidance. The idea is for the Expert to provide a light sanity check for small allocations of EUI identifiers with increased scrutiny by the Expert for medium-sized allocations of EUI identifiers, and allocations of protocol identifiers and other IANA OUI based parameters. However, it can make sense to allocate very large portions of the MAC identifier code point space. (Note that existing allocations include one for 1/2 of the entire multicast code point space and one for 1/16 of the multicast code point space.) In those cases, and in cases of the allocation of "reserved" values, IESG Ratification of an Expert Review approval recommendation is required as described below. The procedure is as follows:
有限ですが、専門家が割り当てを審査するコードポイントの宇宙は、この文書と専門家の良い判断に与えられた要件が十分なガイダンスであるほど十分に大きいと感じられます。アイデアは、専門家がEUI識別子の中規模の割り当て、およびプロトコル識別子およびその他のIANA OUIベースのパラメーターの割り当てについて専門家による精査を増やし、EUI識別子のわずかな割り当てに軽い正気チェックを提供することです。ただし、Mac Identifierコードポイントスペースの非常に大きな部分を割り当てることは理にかなっています。（既存の割り当てには、マルチキャストコードポイントスペース全体の1/2に1つ、マルチキャストコードポイントスペースの1/16用に1つが含まれていることに注意してください。）これらの場合、「予約済み」値の割り当ての場合、IESG批准以下に説明するように、専門家のレビュー承認の推奨が必要です。手順は次のとおりです。
The applicant always completes the appropriate Template from the Template Annex below and sends it to IANA <iana@iana.org>.
申請者は常に、以下のテンプレート付録から適切なテンプレートを完成させ、IANA <iana@iana.org>に送信します。
IANA always sends the Template to an appointed Expert. If the Expert recuses themselves or is non-responsive, IANA may choose an alternative appointed Expert or, if none are available, will contact the IESG.
IANAは常に任命された専門家にテンプレートを送信します。専門家が自分自身を拒否したり、反応していない場合、IANAは代替の任命された専門家を選択したり、利用可能な場合はIESGに連絡します。
If the allocation is based on Expert Review:
割り当てが専門家のレビューに基づいている場合：
If IANA receives a disapproval from an Expert selected to review an application Template, the application will be denied. If IANA receives approval and code points are available, IANA will make the requested allocation.
IANAがアプリケーションテンプレートを確認するために選択された専門家から不承認を受け取った場合、アプリケーションは拒否されます。IANAが承認を受け、コードポイントが利用可能な場合、IANAは要求された割り当てを行います。
If the allocation is based on IESG Ratification, the procedure starts with the first two steps above for Expert Review. If the Expert disapproves the application, they simply inform IANA; however, if the Expert believes the application should be approved, or is uncertain and believes that the circumstances warrant the attention of the IESG, the Expert will inform IANA about their advice and IANA will forward the application, together with the reasons for approval or uncertainty, to the IESG. The IESG must decide whether the allocation will be granted. This can be accomplished by a management item in an IESG telechat as done for other types of requests. If the IESG decides not to ratify a favorable opinion by the Expert or decides against an application where the Expert is uncertain, the application is denied, otherwise it is granted. The IESG will communicate its decision to the Expert and to IANA.
割り当てがIESG批准に基づいている場合、手順は、専門家のレビューのために上記の最初の2つのステップから始まります。専門家が申請を不承認にした場合、彼らは単にIANAに通知します。ただし、専門家が申請を承認する必要があると考えている場合、または不確実であり、状況がIESGの注意を必要とすると信じている場合、専門家はIANAにアドバイスについて通知し、IANAは承認または不確実性の理由とともに申請を転送します、IESGへ。IESGは、割り当てが許可されるかどうかを決定する必要があります。これは、他の種類のリクエストに対して行われるように、IESGテレカットの管理アイテムによって実現できます。IESGが専門家による有利な意見を批准しないことを決定した場合、または専門家が不確実であるアプリケーションに対して決定する場合、申請は拒否されます。IESGは、その決定を専門家とIANAに伝えます。
IANA also maintains an informational listing on its web site concerning Ethertypes, OUIs, and multicast addresses allocated under OUIs other than the IANA OUI. IANA shall update that list when changes are provided by the Expert.
IANAは、IANA OUI以外のOUIに割り当てられた倫理、OUI、およびマルチキャストアドレスに関する情報リストをWebサイトに維持しています。IANAは、エキスパートによって変更が提供されたときにそのリストを更新するものとします。
When the available space for either multicast or unicast EUI-48 identifiers under OUI 00-00-5E have been 90% or more exhausted, IANA should request an additional OUI from the IEEE Registration Authority (see Section 1.2) for further IANA allocation use.
OUI 00-00-5Eの下でのマルチキャストまたはユニキャストEUI-48の識別子のいずれかで利用可能なスペースが90％以上疲れている場合、IANAはIEAE登録局（セクション1.2を参照）から追加のOUIを要求する必要があります。
This document is concerned with allocation of parameters under the IANA OUI and closely related matters. It is not directly concerned with security.
このドキュメントは、IANA OUIの下でのパラメーターの割り当ておよび密接に関連する問題に関係しています。セキュリティに直接関係していません。
[802_O&A] "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE 802-2001, 8 March 2002.
[802_O＆A]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ」、IEEE 802-2001、2002年3月8日。
"IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture / Amendment 1: Ethertypes for Prototype and Vendor-Specific Protocol Development", IEEE 802a-2003, 18 September 2003.
「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ /修正1：プロトタイプおよびベンダー固有のプロトコル開発の倫理」、IEEE 802A-2003、2003年9月18日。
[802.1Q] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", IEEE 802.1Q-2005, 19 May 2006.
[802.1Q]「ローカルおよびメトロポリタンエリアネットワーク /仮想ブリッジ型ローカルエリアネットワークのIEEE標準」、IEEE 802.1Q-2005、2006年5月19日。
[802.3] "IEEE Standard for Information technology / Telecommunications and information exchange between systems / Local and metropolitan area networks / Specific requirements / Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE 802.3-2005, 9 December 2005.
[802.3]「情報技術 /電気通信およびシステム /ローカルエリアネットワーク /特定の要件間の情報交換のIEEE標準 /パート3：衝突検出付きの複数アクセス（CSMA / CD）アクセス法と物理層仕様」、IEEE802.3-2005、2005年12月9日。
[802.11] "IEEE Standard for Information technology / Telecommunications and information exchange between systems / Local and metropolitan area networks / Specific requirements / Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11-2007, 11 June 2007.
[802.11]「システム /ローカルおよびメトロポリタンエリアネットワーク /特定の要件 /パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様の間の情報技術 /電気通信と情報交換のIEEE標準」、IEEE 802.11-2007、2007年6月11日。
[EUI-64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", <http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html>, March 1997.
[EUI-64] IEEE、「64ビットグローバル識別子（EUI-64）登録局のガイドライン」、<http://standards.ieee.org/ regauth/oui/tutorials/eui64.html>、1997年3月。
[IANA] Internet Assigned Numbers Authority, Ethernet Types, <http://www.iana.org>.
[IANA]インターネットに割り当てられた数字の権限、イーサネットタイプ、<http://www.iana.org>。
[IEEE] Institute of Electrical and Electronics Engineers, <http://www.ieee.org>.
[IEEE]電子エンジニア研究所、<http://www.ieee.org>。
[IEEE802] IEEE 802 LAN/MAN (Local Area Network / Metropolitan Area Network) Standards Committee, <http://www.ieee802.org>.
[IEEE802] IEEE 802 LAN/MAN（ローカルエリアネットワーク/メトロポリタンエリアネットワーク）標準委員会、<http://www.ieee802.org>。
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、スタンフォード大学、1989年8月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC2153] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
[RFC2153]シンプソン、W。、「PPPベンダー拡張機能」、RFC 2153、1997年5月。
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[RFC2332] Luciani、J.、Katz、D.、Piscitello、D.、Cole、B。、およびN. Doraswamy、「NBMA Next Hop Resolution Protocol（NHRP）」、RFC 2332、1998年4月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、1998年12月。
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.
[RFC3768] Hinden、R。、「仮想ルーター冗長プロトコル（VRRP）」、RFC 3768、2004年4月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（ISATAP）」、RFC 5214、2008年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332] Eckert、T.、Rosen、E.、ed。、Aggarwal、R。、およびY. Rekhter、「MPLS Multicast Capsulations」、RFC 5332、2008年8月。
This annex provides the specific templates for IANA allocations of parameters. Explanatory words in parenthesis in the templates below may be deleted in a completed template as submitted to IANA.
この付属書は、パラメーターのIANA割り当てのための特定のテンプレートを提供します。以下のテンプレートの括弧内の説明的な単語は、IANAに提出された完成したテンプレートで削除される場合があります。
Applicant Name:
申請者名：
Applicant Email:
申請者のメール：
Applicant Telephone: (starting with country code)
申請者の電話：（カントリーコードから始まる）
Use Name: (brief name of Parameter use such as "Foo Protocol")
使用名前：（「Foo Protocol」などのパラメーター使用の簡単な名前）
Document: (ID or RFC specifying use to which the identifier or block of identifiers will be put.)
ドキュメント：（ IDまたはRFC指定識別子の識別子またはブロックが配置される使用法。）
Specify whether this is an application for EUI-48 or EUI-64 identifiers:
これがEUI-48またはEUI-64識別子のアプリケーションであるかどうかを指定します。
Size of Block requested: (must be a power-of-two-sized block, can be a block of size one (2**0))
要求されたブロックのサイズ：（ 2つのサイズのブロックのパワーでなければなりません、サイズ1（2 ** 0）のブロックにすることができます）
Specify multicast, unicast, or both:
マルチキャスト、ユニキャスト、またはその両方を指定します。
Applicant Name:
申請者名：
Applicant Email:
申請者のメール：
Applicant Telephone: (starting with country code)
申請者の電話：（カントリーコードから始まる）
Use Name: (brief name of use of code point such as "Foo Protocol")
使用名：（「Foo Protocol」などのコードポイントの使用の簡単な名前）
Document: (ID or RFC specifying use to which the protocol identifier will be put.)
ドキュメント：（ IDまたはRFCプロトコル識別子が配置される使用を指定します。）
Applicant Name:
申請者名：
Applicant Email:
申請者のメール：
Applicant Telephone: (starting with country code)
申請者の電話：（カントリーコードから始まる）
Protocol where the OUI Based Parameter for which a value is being requested appears: (such as: Cipher Suite selection in IEEE 802.11)
値がリクエストされているOUIベースのパラメーターが表示されるプロトコル：（など：IEEE 802.11のCipherスイート選択）
Use Name: (brief name of use of code point to be allocated, such as "Foo Cipher Suite")
使用名：（「Foo Cipher Suite」などの割り当てられるコードポイントの使用の簡単な名前）
Document: (ID or RFC specifying use to which the other IANA OUI based parameter value will be put.)
ドキュメント：（ IDまたはRFC他のIANA OUIベースのパラメーター値が配置される使用を指定します。）
This annex lists some Ethertypes specified for IETF Protocols or by IEEE 802 as known at the time of publication. A more up-to-date list may be available on the IANA web site, currently at [IANA]. The IEEE Registration Authority page of Ethertypes, http://standards.ieee.org/regauth/ethertype/eth.txt, may also be useful. See Section 3 above.
この付属書には、IETFプロトコルまたはIEEE 802に指定されたいくつかの倫理が、公開時に知られているようにリストされています。より最新のリストは、現在[IANA]でIANA Webサイトで入手できます。EthertypesのIEEE登録機関ページhttp://standards.ieee.org/regauth/ethertype/eth.txtも役立つ場合があります。上記のセクション3を参照してください。
0x0800 Internet Protocol Version 4 (IPv4) 0x0806 Address Resolution Protocol (ARP) 0x0808 Frame Relay ARP 0x880B Point-to-Point Tunneling Protocol (PPTP) 0x880C General Switch Management Protocol (GSMP) 0x8035 Reverse Address Resolution Protocol (RARP) 0x86DD Internet Protocol Version 6 (IPv6) 0x8847 MPLS 0x8848 MPLS with upstream-assigned label 0x8861 Multicast Channel Allocation Protocol (MCAP) 0x8863 PPP over Ethernet (PPPoE) Discovery Stage 0x8864 PPP over Ethernet (PPPoE) Session Stage
0x0800インターネットプロトコルバージョン4（IPv4）0x0806アドレス解像度プロトコル（ARP）0x0808フレイリレーARP 0x880Bポイントツーポイントトンネルリングプロトコル（PPTP）0x880C一般スイッチ管理プロトコル（GSMP）0x8035逆解決版（RARP）0X86DDDDDDDDDDDDDDDDDD6（IPv6）0x8847 MPLS 0x8848上流のラベル付きMPLS 0x8861マルチキャストチャネルアロケーションプロトコル（MCAP）0x8863 PPP上のイーサネット（PPPOE）
0x8100 IEEE Std 802.1Q - Customer VLAN Tag Type (C-Tag, formerly called the Q-Tag) 0x8808 IEEE Std 802.3 - Ethernet Passive Optical Network (EPON) 0x888E IEEE Std 802.1X - Port-based network access control 0x88A8 IEEE Std 802.1Q - Service VLAN tag identifier (S-Tag) 0x88B5 IEEE Std 802 - Local Experimental Ethertype 0x88B6 IEEE Std 802 - Local Experimental Ethertype 0x88B7 IEEE Std 802 - OUI Extended Ethertype 0x88C7 IEEE Std 802.11i - Pre-Authentication 0x88CC IEEE Std 802.1AB - Link Layer Discovery Protocol (LLDP) 0x88E5 IEEE Std 802.1AE - Media Access Control Security 0x88F5 IEEE Std 802.1ak - Multiple VLAN Registration Protocol (MVRP) 0x88F6 IEEE Std 802.1Q - Multiple Multicast Registration Protocol (MMRP) 0x890D IEEE 802.11r - Fast Roaming Remote Request
0x8100 IEEE STD 802.1Q-カスタマーVLANタグタイプ（C -TAG、以前はQ -TAGと呼ばれていた）0x8808 IEEE STD 802.3-イーサネットパッシブ光ネットワーク（EPON）0x888E IEEE STD 802.1x-ポートベースのネットワークアクセス制御0x88A8 IEEE STD 802.11Q-サービスVLANタグ識別子（S -TAG）0x88B5 IEEE STD 802-ローカル実験倫理0x88B6 IEEE STD 802-ローカル実験倫理0x88B7 IEEE STD 802 -OUI拡張ethertype 0x88C7 IEEE STD 802.11-11I -11I -11I -11I -11I- Pre -authEntintionリンクレイヤーディスカバリープロトコル（LLDP）0x88E5 IEEE STD 802.1AE-メディアアクセス制御セキュリティ0x88F5 IEEE STD 802.1AK-複数のVLAN登録プロトコル（MVRP）0x88F6 IEEE STD 802.1Q -MMMRP）0X890D IEEEリモートリクエスト
Author's Address
著者の連絡先
Donald E. Eastlake 3rd 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク3rd 155ビーバーストリートミルフォード、マサチューセッツ州01757 USA
Phone: +1-508-634-2066
EMail: d3e3e3@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。