Network Working Group D. Eastlake 3rd
Request for Comments: 5342 Eastlake Enterprises
BCP: 141 September 2008
Updates: 2153
Category: Best Current Practice
IANA Considerations and IETF Protocol Usage
for IEEE 802 Parameters
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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（Media Access Control）識別子とプロトコル識別子が含まれます。
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進数が符号なし整数としてオクテットの値を与えることによって表されています。連続したオクテットは、ハイフンで区切られています。 IEEE [802.3]リンク上のオクテット内のビット伝送の物理的な順序は、最上位ビットの最下位ビットからのものであるが、この文書は、一貫してIETFビット順序を使用して（すなわち、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.
「YES」組織固有識別子を表します。
"**" indicates exponentiation. For example, 2**24 is two to the twenty-fourth power.
「**」、べき乗を示します。例えば、2 ** 24は、第二十四乗に2です。
Originally the responsibility of Xerox Corporation, the registration authority for Ethernet parameters is now the IEEE Registration Authority, available on the web at:
もともとイーサネットパラメータのゼロックス社、登録機関の責任は、今ではWeb上で利用できるIEEE登録機関、次のとおりです。
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.
いくつかの割り当てられたのOUIと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.
バーナードAboba、スコットO.ブラドナーの、イアン・カルダー、ミシェル・コットン、ラースEggertの、エリックグレー、アルフレッドHoenes、ラスHousley、チャーリー・カウフマン、エリックNordmarkと、ダンRomascanu、マークTownsley、そしてジェフ・トンプソン。
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とIABSとの関係、及び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は、IAB 1 1/2オクテットのホルダーを与え、第4の1/2オクテット（36ビット）が割り当てられている代わりに、IABS（個別アドレスブロック）、割り当て（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.
グループのビット（01-00-00）とローカルビット（02-00-00）：EUI-48の最初の3つのオクテット内の2つのビットは、特別な意味を持っています。 OUIとIABSが指定されていないローカルビットにゼロとグループビットを割り当てられています。マルチキャスト識別子は、グループのビットをオンにすることによって構築することができ、脱離基によって構築ユニキャスト識別子はゼロビット。
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.
上記1.2.1項で述べたようOUI 00-00-5EはIANAに割り当てられています。これは、01-00-5E-FF-FF-FFし、00-00-から2 ** 24 EUI-48ユニキャスト識別子を-00-00-00 01-00-5Eから2 ** 24 EUI-48マルチキャスト識別子を含みます5E-00-00-00-FF-FF-FFを00-00-5Eします。
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-FFスルー00-00-5E-00-00-00から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-FFスルー00-00-5E-00-01-00から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の下のEUI-48の割り当ては、次の要件を満たす必要があります（5.2節を参照してください）：
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のべき乗の識別子のブロックのためでなければなりません
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.
図2に示すように、媒体1のブロックの割り当て、2、4、...、32768、65536（2 ** 0に小さな** 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）個以下の識別子のすべての将来の割り当ては、マルチキャストおよびユニキャスト識別子の平行等しいサイズのブロックの割り当てなければならない、すなわち、グループビット不特定のこれらの二つの場合でもいずれかを有するものタイプが提案された使用のために必要されていません。唯一の例外は、任意のサイズのユニキャスト専用識別子ブロックに対する要求が00-00-5E-00-02-00する00-00-5E-8F-FFからの大きなユニキャスト範囲内の残りの識別子のうちの割り当てられてもよいということです-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」の識別子の取り込みは限られていました。彼らは現在、以下に述べるように、いくつかのIPv6インタフェース識別子を構築するには、以下のIEEE規格で使用されます。
o IEEE 1394 (also known as FireWire and i.Link),
IEEE 1394（また、FireWireおよびi.Linkとしても知られる）、O、
o IEEE 802.15.4 (also known as ZigBee).
IEEE 802.15.4（ZigBeeのもとして知られている）、O。
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.
OUIは、OUI下EUI-64識別子を形成する3オクテット（24ビット）に5オクテット（40ビット）拡張を追加すること。 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アドレス（セクション2.5.1と[RFC4291]の付録Aと[RFC5214]の付録A）の下位64ビットを形成するために使用されます。そのように使用される場合、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識別子と比較反転され、02よりもむしろ00理由として示されています。このビットのものがオフローカルに割り当てられ、グローバル割り当てのための範囲の外いる間それは、最初のオクテット内に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-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、延長部の残りの部分は、EUI-48 OUI所有者によって割り当てられる24ビットの値です。例えば：
02-00-5E-FF-FE-yy-yy-yy or 03-00-5E-FF-FE-yy-yy-yy
02-00-5E-FF-FE-YY-YY-YYまたは03-00-5E-FF-FE-YY-YY-YY
where yy-yy-yy is the portion (of an EUI-48 global unicast or multicast identifier) that is assigned by the OUI owner (IANA in this case). Thus, any holder of one or more EUI-48 identifiers under the IANA OUI also has an equal number of Modified EUI-64 identifiers that can be formed by inserting FF-FE in the middle of their EUI-48 identifiers and inverting the Local/Global bit.
YY-YY-yyはOUI所有者（この場合はIANA）によって割り当てられ（EUI-48グローバルユニキャストまたはマルチキャスト識別子の）部分があります。このように、IANA OUIの下の一つ以上の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]ビットは、MAC-48識別子からIEEE EUI-64識別子を作成するために挿入されるようにFF-FFを定義する文書は、EUI-48で始まる場合FF-FEの値が使用されていると言います。識別子。IETFは、EUI-48。かかわらず、それらがEUI-48またはMAC-48ローカル識別子であるか否かの48ビットイーサネットステーション識別子から修正EUI-64識別子を作成するだけFF-FEを使用し、ローカル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-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
予約-FD-FF-FF-FF-FFを02-00-5Eする02-00-5E-F0-00-00-00-00
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
上記のように、IPv4アドレス保有者によって使用-FE-FF-FF-FF-FFを02-00-5Eする02-00-5E-FE-00-00-00-00
02-00-5E-FF-00-00-00-00 to 02-00-5E-FF-FD-FF-FF-FF reserved
予約-FF-FD-FF-FF-FFを02-00-5Eする02-00-5E-FF-00-00-00-00
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上記のようにIANA OUI下EUI-48識別子の保有者によって使用-FF-FE-FF-FF-FFを02-00-5Eします
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予約-FF-FF-FF-FF-FFを02-00-5Eします
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:
上記予約識別子は、割り当てのために（セクション5.1を参照）IESG批准を必要とします。 IANA OUIの下でIANA EUI-64識別子の割り当ては、次の要件を満たす必要があります。
o must be for standards purposes (either for an IETF Standard or other standard related to IETF work),
oは、（いずれかのIETF標準またはIETF仕事に関連する他の規格のための）標準化目的のためでなければなりません
o must be for a 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のべき乗の識別子のブロックのためでなければなりません
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に小）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識別子は、グループビットが指定されていないなければならない、即ち、これらの場合でも、一つのマルチキャストおよびユニキャスト識別子の平行等しいサイズのブロックの割り当てなければなりません二つのタイプが提案された使用のために必要されていません。
There are two other blocks of MAC-48 identifiers that are used by the IETF as described below.
後述のようにIETFによって使用されるMAC-48識別子の二つの他のブロックが存在します。
All MAC-48 multicast identifiers prefixed "33-33" (that is, the 2**32 multicast MAC identifiers in the range from 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF) are used 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"（すなわち、範囲内の2 ** 32マルチキャストMAC識別子である33-33-00-00-00-00乃至33-33-FF-FF-FF- FF）グローバルIPv6マルチキャスト[RFC2464]のためにIETFによって使用されます。マルチキャスト識別子として既存のハードウェアで正しく動作するために必要とされるように、すべてのこれらの識別子は、グループビット（最初のオクテットの底ビット）は、上にあります。彼らはまた、上のローカルビットを持っており、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.)
（ヒストリカルノート：それが不明または例の値は「3」を使用してIPv6の設計中にカスタムした、と3333コヨーテヒルロード、パロアルト、カリフォルニア州、）以前は「ゼロックスPARC」、PARC（パロアルト研究所のアドレスです。イーサネットは元々、事前IEEE [802.3]イーサネットプロトコルは時々これらの企業の名前の最初の文字から「DIX」イーサネットとして知られている。）。ディジタルイクイップメント社、インテル社、およびゼロックス社によって指定されました
The Informational [RFC2153] declared the 3-octet values from CF-00-00 through CF-FF-FF to be OUIs available for 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]はベンダーがそうでなければない場合PPP [RFC1661]の中、または他の用途のために使用するためのソフトウェアベンダーにIANAによって割り当て可能のOUIことがCF-FF-FFを介してCF-00-00から3オクテットの値を宣言しました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.)
可用性の十年間では、「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.
コンセプトは、「タグ」によってラベルに拡張されました。この意味では、タグは、その種類、以下に記載のように、別のタグ、イーサタイプ、またはフレームの「メイン」体にLSAPプロトコルインジケータのいずれかが続いているイーサタイプによって識別されるプレフィックスです。伝統的に[802_O＆A]世界では、タグは固定長であり、自分自身の長さの任意のエンコーディングが含まれていません。このように、フレームを処理しているものは、一般的に、安全に、それは理解していないイーサタイプ過去のフレームには何も処理することはできません。例はC-TAG（旧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.
さらにEthertype：これらは、符号なし整数として考え、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.
LSAPs：これらは直ちにMAC宛先およびソース（またはタグの後）の後に順番に初期の16ビット（2オクテット）の残りのフレーム長、後にペアで発生する8ビットのプロトコル識別子です。符号なし整数として考えた場合にこのような長さは、0x5DCより小さくなければならないか、イーサタイプとして誤解される可能性があります。 LSAPs（リンク層サブネットアクセスポイント）は、一方がソースプロトコルハンドラと1つの宛先プロトコルハンドラを示すことを意図している対に起こります。しかし、両者が異なっているユースケースは比較的まれていました。
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.
イーサタイプもLSAPsどちらも、IANAによって割り当てられています。代わりに、彼らはIEEEの登録機関によって割り当てられている（上記のセクション1.2および以下のイーサタイプの附属書を参照）。それらはIANA OUIの下でIANAによって割り当てられたものを含めて、OUI下で5オクテットイーサネットプロトコル識別子に使用できるようにしかし、LSAPsとさらにEthertypeの両方が拡張機構を有します。
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-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は、フレーム長であり、上記のように、イーサタイプと混同しないように十分に小さくなければならない場合。 「AA」は、この使用を示し、時にはSNAPのSAPと呼ばれるLSAPです。 「03」のデータグラムサービスを示すLLC制御オクテットです。 YY-YY-yyがOUIです。そしてZZ-ZZはOUI所有者によって割り当てられ、そのOUI下プロトコル番号、、です。 LLC制御オクテット（「03」）と、結果は16ビットで整列され、ようにそのようなOUIベースのプロトコル識別子の奇数5オクテットの長さを選択しました。
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
枠体のための主要なタイプを示すために、イーサタイプを使用する場合は、特別な「OUI拡張イーサタイプ」88-B7が利用可能です。このイーサタイプを使用して、フレーム本体はで始めることができます
88-B7-yy-yy-yy-zz-zz
88-B7-YY-YY-YY-ZZ-ZZ
where yy-yy-yy and zz-zz have the same meaning as in the SNAP format described above.
ここでYY-YY-YYおよびZZ-ZZは、上述SNAP形式の場合と同じ意味を有します。
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
これはSNAPフォーマット内、任意のEthertypeを使用することも可能です。すべてゼロのOUI（00-00-00）の後ZZ-ZZフィールドとしてイーサタイプを置くことは、これを行います。それは次のようになります
xx-xx-AA-AA-03-00-00-00-zz-zz
XX-XX-AA-AA-03-00-00-00-ZZ-ZZ
where zz-zz is the Ethertype.
どこZZ-ZZは、イーサタイプがあります。
(Note that, at this point, the 802 protocol syntax facilities are sufficiently powerful that they could be chained indefinitely. Whether support for such chaining is generally required is not clear, but [802_O&A] requires support for
（この時点では、802件のプロトコル構文の施設は、彼らは無限に連鎖させることができることを十分に強力である、ということに注意してください。そのようなチェーンのためかどうか、サポートが一般的に必要とされる明確ではないが、[802_O＆Aは]のサポートが必要です
xx-xx-AA-AA-03-00-00-00-88-B7-yy-yy-yy-zz-zz
XX-XX-AA-AA-03-00-00-00-88-B7-YY-YY-YY-ZZ-ZZ
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つのオクテットイーサタイプと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:
そのような割り当ての数は、（[IANA]参照）-FF-FFを00-00-5Eする00-00-5E-00-00から入手可能な2 ** 16プロトコル番号から作られてきました。この範囲の極値、00-00-5E-00-00及び00-00-5E-FF-FFは、予約され（セクション5.1を参照）割り当てのためIESG批准を必要としています。 SNAPのSAPプロトコル（ZZ-ZZ）IANA OUIの下の数字の新しい割り当ては、次の要件を満たす必要があります。
o the allocation must be for standards use (either for an IETF Standard or other standard related to IETF work),
規格は（いずれかのIETF標準またはIETF仕事に関連する他の標準のために）使用するためのO割当がなければなりません、
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、プロトコル番号は、イーサタイプを（上記のようにそれがイーサタイプする前に、すべてゼロ「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.
また、エキスパートレビュー（または2つの予約値のためのIESG批准）はセクション5.1で指定された手順を使用して取得しなければなりません。
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
YY-YY-YY-ZZ
where yy-yy-yy is the OUI and zz is the additional specifier. An example is the Cipher Suite Selector in IEEE 802.11 ([802.11], page 125).
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.
値は、各使用のために、それ以外のエキスパートレビューすることにより、このような他のOUIベースのパラメータの使用のためのIANA OUIの下にあるすべてのゼロのビットおよびすべての1つのビット（1オクテット指定するための0x00から0xFFの）からなる追加の指定子値を割り当てることができます予約とIESG批准を必要としている割り当てのために（セクション5.1を参照してください）。割り当ては標準で使用するためにでなければなりません（どちらかIETF標準または他のIETF仕事に関連する標準用）とインターネットドラフトやRFCで文書化すること。値は、このタイプの特定のパラメータ、IANAレジストリに割り当てられる最初の時間は、IANA OUIの下でその割り当て、そのパラメータの値の任意の後続の割り当てを含むように作成されます。専門家は、レジストリの名前を指定します。
(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リストの現在のEUI-48このOUIの下での割り当て。
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].
このセクションでは、専門家のレビューとIESG批准MACの、プロトコル、および他のIANA OUIベースの識別子のための手順を指定します。エキスパート（複数可）によって任命され、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識別子コードポイント空間の非常に大きな部分を割り当てるために意味をなすことができます。 （既存の割り当てが全体マルチキャストコードポイントの空間およびマルチキャストコードポイントスペースの1/16のための1つの1/2のための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は常に任命エキスパートにテンプレートを送信します。専門家が自分自身をrecusesまたは非応答性である場合には、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のtelechatに管理項目によって達成することができます。 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はまた、イーサタイプ、のOUI、およびIANA OUI以外のOUIの下に割り当てられたマルチキャストアドレスに関するそのウェブサイト上の情報のリストを維持します。変更が専門家によって提供されたときに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は、さらに、IANA割り当て用のIEEE登録機関（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.
[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]「情報技術/通信およびシステム/ローカルおよびメトロポリタンエリアネットワーク間の情報交換/固有の要件/パート3のためのIEEE規格：衝突検出（CSMA / CD）アクセス方式および物理層仕様とキャリア検知多重アクセス」、IEEE 802.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との間の情報交換のためのIEEE規格：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様」、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 /チュートリアル/ 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]デアリング、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]ルチアーニ、J.、カッツ、D.、Piscitello、D.、コール、B.、およびN. Doraswamy、 "NBMAネクストホップ解決プロトコル（NHRP）"、RFC 2332、1998年4月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、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.デアリング、 "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]テンプリン、F.、グリーソン、T.、およびD.ターラーは、 "イントラサイト自動トンネルは、プロトコル（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]エッカート、T.、ローゼン、E.、編、アガルワル、R.、およびY. Rekhter、 "MPLSマルチキャストカプセル化"、RFC 5332、2008年8月。
Appendix A. Templates
付録A.テンプレート
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に提出して、以下のテンプレートでは括弧内の説明の言葉は、完成したテンプレートで削除することができます。
A.1. EUI-48/EUI-64 Identifier or Identifier Block Template
A.1。 EUI-48 / EUI-64識別子または識別子ブロックテンプレート
Applicant Name:
申請者名：
Applicant Email:
申請者メールアドレス：
Applicant Telephone: (starting with country code)
申請者電話番号：（国コードで始まります）
Use Name: (brief name of Parameter use such as "Foo Protocol")
使用する名前は：（パラメータの簡潔な名前は、「Fooの議定書」として使用します）
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（** 0 2）のブロックであってもよいです）
Specify multicast, unicast, or both:
マルチキャスト、ユニキャスト、またはその両方を指定します。
A.2. 5-Octet Ethernet Protocol Identifier Template
A.2。 5オクテットイーサネットプロトコル識別子テンプレート
Applicant Name:
申請者名：
Applicant Email:
申請者メールアドレス：
Applicant Telephone: (starting with country code)
申請者電話番号：（国コードで始まります）
Use Name: (brief name of use of code point such as "Foo Protocol")
（例えば、「Fooの議定書」としてコードポイントの使用の簡単な名前）：名前を使用します
Document: (ID or RFC specifying use to which the protocol identifier will be put.)
文書：（IDまたはRFCプロトコル識別子が置かれる先の使用を指定します）。
A.3. Other IANA OUI-Based Parameter Template
A.3。他のIANA OUIベースのパラメータテンプレート
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)
（のような：IEEE 802.11での暗号スイートの選択）の値が要求されているOUIベースのパラメータが表示されたプロトコル
Use Name: (brief name of use of code point to be allocated, such as "Foo Cipher Suite")
使用する名前：（コード・ポイントの使用の簡単な名前は、「Fooの暗号スイート」として、割り当てられます）
Document: (ID or RFC specifying use to which the other IANA OUI based parameter value will be put.)
ドキュメント：（IDまたはRFC他のIANA OUIベースのパラメータ値が置かれる先の使用を指定します。）
Appendix B. Ethertypes
付録B.イーサタイプ
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サイトで入手可能です。イーサタイプ、http://standards.ieee.org/regauth/ethertype/eth.txtのIEEE登録機関のページには、また、有用である可能性があります。上記のセクション3を参照してください。
B.1. Some Ethertypes Specified by the IETF
B.1。 IETFによって指定されたいくつかのイーサタイプ
0x0800 Internet Protocol Version 4 (IPv4)
0x0806 Address Resolution Protocol (ARP)
0x0808 Frame Relay ARP
0x880B Point-to-Point Tunneling Protocol (PPTP)
0x880C General Switch Management Protocol (GSMP)
0x8035 Reverse Address Resolution Protocol (RARP)
0x86DD Internet Protocol Version 6 (IPv6)
0x8847 MPLS
0x8848 MPLS with upstream-assigned label
0x8861 Multicast Channel Allocation Protocol (MCAP)
0x8863 PPP over Ethernet (PPPoE) Discovery Stage
0x8864 PPP over Ethernet (PPPoE) Session Stage
B.2. Some IEEE 802 Ethertypes
B.2。いくつかのIEEE 802イーサタイプ
0x8100 IEEE Std 802.1Q - Customer VLAN Tag Type (C-Tag, formerly
called the Q-Tag)
0x8808 IEEE Std 802.3 - Ethernet Passive Optical Network (EPON)
0x888E IEEE Std 802.1X - Port-based network access control
0x88A8 IEEE Std 802.1Q - Service VLAN tag identifier (S-Tag)
0x88B5 IEEE Std 802 - Local Experimental Ethertype
0x88B6 IEEE Std 802 - Local Experimental Ethertype
0x88B7 IEEE Std 802 - OUI Extended Ethertype
0x88C7 IEEE Std 802.11i - Pre-Authentication
0x88CC IEEE Std 802.1AB - Link Layer Discovery Protocol (LLDP)
0x88E5 IEEE Std 802.1AE - Media Access Control Security
0x88F5 IEEE Std 802.1ak - Multiple VLAN Registration Protocol
(MVRP)
0x88F6 IEEE Std 802.1Q - Multiple Multicast Registration
Protocol (MMRP)
0x890D IEEE 802.11r - Fast Roaming Remote Request
Author's Address
著者のアドレス
Donald E. Eastlake 3rd 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク第三155ビーバー通りミルフォード、MA 01757 USA
Phone: +1-508-634-2066 EMail: d3e3e3@gmail.com
電話：+ 1-508-634-2066 Eメール：d3e3e3@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。