RFC 5494 - IANA Allocation Guidelines for the Address Resolution Protocol (ARP) 日本語訳

URL : https://tools.ietf.org/html/rfc5494
タイトル : RFC 5494 - アドレス解決プロトコル（ARP）のためのIANA配分ガイドライン
翻訳編集 : 自動生成

Network Working Group                                           J. Arkko
Request for Comments: 5494                                      Ericsson
Updates: 826, 951, 1044, 1329, 2131,                        C. Pignataro
         2132, 2176, 2225, 2834, 2835,                     Cisco Systems
         3315, 4338, 4361, 4701                               April 2009
Category: Standards Track

IANA Allocation Guidelines for the Address Resolution Protocol (ARP)

アドレス解決プロトコル（ARP）のためのIANA配分ガイドライン

Status of This Memo

このメモのステータス

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

Abstract

抽象

This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. The changes also affect other protocols that employ values from the ARP name spaces.

この文書では、アドレス解決プロトコル（ARP）に新しい値を割り当てるためのIANAガイドラインを指定します。また、このドキュメントでは、実験の目的のためにいくつかの数字を留保します。変更はまた、ARPの名前空間からの値を採用する他のプロトコルに影響を与えます。

1. Introduction

1. はじめに

This document specifies the IANA guidelines [RFC5226] for allocating new values for various fields in the Address Resolution Protocol (ARP) [RFC0826]. The change is also applicable to extensions of ARP that use the same message format, such as [RFC0903], [RFC1931], and [RFC2390].

この文書では、アドレス解決プロトコル（ARP）[RFC0826]のさまざまなフィールドの新しい値を割り当てるためのIANAガイドライン[RFC5226]を指定します。変化はまた、[RFC0903]、[RFC1931]及び[RFC2390]と同じメッセージフォーマットを使用してARPの拡張にも適用可能です。

The change also affects other protocols that employ values from the ARP name spaces. For instance, the ARP hardware address type (ar$hrd) number space is also used in the "htype" (hardware address type) fields in the Bootstrap Protocol (BOOTP) [RFC0951] and Dynamic Host Configuration Protocol (DHCP) [RFC2131], as well as in the "hardware type" field in the DHCP Unique Identifiers in DHCPv6 [RFC3315]. These protocols are therefore affected by the update in the IANA rules. Other affected specifications include the specialized address resolution mechanisms in:

変更は、ARPの名前空間からの値を採用する他のプロトコルに影響を与えます。例えば、ARPハードウェアアドレスのタイプ（AR $のHRD）番号空間はまた、「htypeフィールド」（ハードウェアアドレスタイプ）ブートストラッププロトコル（BOOTP）[RFC0951]とのフィールドで使用されている動的ホスト構成プロトコル（DHCP）[RFC2131] 、などのDHCPv6 [RFC3315]でDHCP固有識別子で、「ハードウェアタイプ」フィールドに入力します。これらのプロトコルは、したがって、IANA規則で更新の影響を受けています。他の影響を受けた仕様は、特殊なアドレス解決メカニズムでは、次のとおりです。

o HYPERchannel [RFC1044]

O HYPERchannel [RFC1044]

o DHCP options [RFC2132] [RFC4361]

OのDHCPオプション[RFC2132] [RFC4361]

o ATM (Asynchronous Transfer Mode) ARP [RFC2225]

O ATM（非同期転送モード）ARP [RFC2225]

o HARP (High-Performance Parallel Interface ARP) [RFC2834] [RFC2835]

O HARP（高性能パラレルインターフェイスARP）[RFC2834] [RFC2835]

o Dual MAC (Media Access Control) FDDI (Fiber Distributed Data Interface) ARP [RFC1329]

OデュアルMAC（メディアアクセス制御）、FDDI（ファイバ分散データインタフェース）ARP [RFC1329]

o MAPOS (Multiple Access Protocol over Synchronous Optical Network/ Synchronous Digital Hierarchy) ARP [RFC2176]

O MAPOS（同期光ネットワーク/同期デジタル階層以上の多重アクセスプロトコル）ARP [RFC2176]

o FC (Fibre Channel) ARP [RFC4338]

O FC（ファイバチャネル）ARP [RFC4338]

o DNS DHCID Resource Record [RFC4701]

O DNS DHCIDリソースレコード[RFC4701]

The IANA guidelines are given in Section 2. Previously, no IANA guidance existed for such allocations. The purpose of this document is to allow IANA to manage number assignments based on these guidelines in a consistent manner.

IANAガイドラインは以前、何のIANAのガイダンスは、このような割り当てのために存在していないセクション2に記載されています。このドキュメントの目的は、IANAが一貫した方法でこれらのガイドラインに基づいて、番号の割り当てを管理することができるようにすることです。

This document also reserves some numbers for experimentation purposes. These numbers are given in Section 3.

また、このドキュメントでは、実験の目的のためにいくつかの数字を留保します。これらの数字は、第3節に記載されています。

2. IANA Considerations

2. IANAの考慮事項

The following rules apply to the fields of ARP:

次の規則は、ARPの分野に適用されます。

ar$hrd (16 bits) Hardware address space

AR $ HRD（16ビット）ハードウェアアドレス空間

Requests for ar$hrd values below 256 or for a batch of more than one new value are made through Expert Review [RFC5226].

256以下または複数の新たな価値のバッチのAR $のHRD値に対する要求は、専門家レビュー[RFC5226]を介して行われます。

Note that certain protocols, such as BOOTP and DHCPv4, employ these values within an 8-bit field. The expert should determine that a need to allocate the new values exists and that the existing values are insufficient to represent the new hardware address types. The expert should also determine the applicability of the request and assign values higher than 255 for requests that do not apply to BOOTP/DHCPv4. Similarly, the expert should assign 1-octet values for requests that apply to BOOTP/DHCPv4, as for example the "IPsec tunnel" with value 31 [RFC3456]. Conversely, ARP-only uses, without a foreseeable reason to use the same value in BOOTP/DHCPv4, should favor 2-octet values.

そのようなBOOTPとDHCPv4のような特定のプロトコルは、8ビットのフィールド内のこれらの値を使用することに留意されたいです。専門家は、新しい値を割り当てる必要が存在していることと、既存の値が新しいハードウェアアドレスの種類を表すには不十分であることを確認する必要があります。専門家はまた、要求の適用を決定し、BOOTP / DHCPv4のには適用されない要求のための255よりも高い値を割り当てる必要があります。同様に、専門家は値31を有する「IPsecトンネル」[RFC3456]例えばように、BOOTP / DHCPv4のに適用される要求のための1オクテットの値を割り当てなければなりません。逆に、ARPのみの用途は、BOOTP / DHCPv4の中に同じ値を使用するには予見可能な理由なしに、2オクテットの値を優先すべきです。

Requests for individual new ar$hrd values that do not specify a value, or where the requested value is greater than 255, are made through First Come First Served [RFC5226]. The assignment will always result in a 2-octet value.

値を指定しない場合、または要求された値が255より大きい場合、個々の新しいAR $ HRD値に対する要求は、まず[RFC5226]を務め、是非まずを通じて行われます。割り当ては、常に2オクテットの値になります。

ar$pro (16 bits) Protocol address space

AR $プロ（16ビット）のプロトコルアドレス空間

These numbers share the Ethertype space. The Ethertype space is administered as described in [RFC5342].

これらの数字は、イーサタイプ空間を共有します。 [RFC5342]に記載されているようにイーサタイプ空間が投与されます。

ar$op (16 bits) Opcode

AR $ OP（16ビット）オペコード

Requests for new ar$op values are made through IETF Review or IESG Approval [RFC5226].

新しいARの$オペアンプ値に対する要求は、IETFレビューやIESG承認[RFC5226]を介して行われます。

3. Allocations Defined in This Document

この文書で定義される3.割り当て

When testing new protocol extension ideas, it is often necessary to use an actual constant in order to use the new function, even when testing in a closed environment. This document reserves the following numbers for experimentation purposes in ARP:

新しいプロトコル拡張のアイデアをテストするとき、閉鎖された環境でテストする場合でも、新しい機能を使用するために、実際の定数を使用する必要があることが多いです。この文書では、ARPでの実験のために、次の番号を留保します。

o Two new ar$hrd values are allocated for experimental purposes: HW_EXP1 (36) and HW_EXP2 (256). Note that these two new values were purposely chosen so that one would be below 256 and the other would be above 255, and so that there would be different values in the least and most significant octets.

HW_EXP1（36）とHW_EXP2（256）：O二つの新しいARの$のHRD値は、実験目的のために割り当てられています。 1が256を下回るとなり、他方が255を超えるだろう、と最小かつ最も重要なオクテットで異なる値が存在することになるので、というように、これら二つの新しい値が故意に選ばれたことに注意してください。

o Two new values for the ar$op are allocated for experimental purposes: OP_EXP1 (24) and OP_EXP2 (25).

OP_EXP1（24）とOP_EXP2（25）：Oのar $オペアンプのための二つの新しい値は、実験的な目的のために割り当てられています。

Note that Appendix B.2 of [RFC5342] lists two Ethertypes that can be used for experimental purposes.

[RFC5342]の付録B.2は、実験目的のために使用することができる2つのイーサタイプをリストしていることに注意してください。

In addition, for both ar$hrd and ar$op, the values 0 and 65535 are marked as reserved. This means that they are not available for allocation.

また、ARの$のHRDとARの$オペアンプの両方のために、値が0と65535は予約としてマークされています。これは、彼らが割り当てのために利用できないことを意味します。

4. Security Considerations

4.セキュリティについての考慮事項

This specification does not change the security properties of the affected protocols.

この仕様は、影響を受けるプロトコルのセキュリティプロパティを変更しません。

However, a few words are necessary about the use of the experimental code points defined in Section 3. Potentially harmful side effects from the use of the experimental values need to be carefully evaluated before deploying any experiment across networks that the owner of the experiment does not entirely control. Guidance given in [RFC3692] about the use of experimental values needs to be followed.

しかし、いくつかの単語は、実験値の使用から第3節潜在的に有害な副作用で定義された実験的なコードポイントの使用について必要な慎重な実験の所有者がないネットワークを介して任意の実験を展開する前に評価する必要が完全に制御します。実験値の使用について[RFC3692]で与えられたガイダンスに従うことが必要です。

5. Acknowledgments

5.謝辞

The lack of any current rules has come up as new values were requested from IANA, who contacted the IESG for advice. The author would like to thank Michelle Cotton in particular for bringing up this issue. The author would also like to thank Brian Carpenter, Thomas Narten, Scott Bradner, Donald Eastlake, Andrew G. Malis, Brian Haberman, Robert Sparks, Larry Zhu, and Dave Thaler for feedback.

新しい値がアドバイスをIESGに連絡をIANAから要求されたとして、任意の現在のルールの欠如が来ています。著者はこの問題を持ち出すために特にミシェルコットンに感謝したいと思います。著者はまた、フィードバックのためにブライアン・カーペンター、トーマスNarten氏、スコット・ブラッドナー、ドナルドイーストレイク、アンドリューG. Malis、ブライアンハーバーマン、ロバート・スパークス、ラリー朱、とDaveターラーに感謝したいと思います。

6. References

6.参照

6.1. Normative References

6.1. 引用規格

[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.

[RFC0826]プラマー、D.、「イーサネットアドレス解決プロトコル：またはイーサネットハードウェア上で送信するためのイーサネットアドレスを48ビットに、ネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。

[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.

[RFC0951]クロフト、B.及びJ.ギルモア、 "ブートストラッププロトコル"、RFC 951、1985年9月。

[RFC1044] Hardwick, K. and J. Lekashman, "Internet Protocol on Network System's HYPERchannel: Protocol specification", STD 45, RFC 1044, February 1988.

[RFC1044]ハードウィック、K.とJ. Lekashman、 "ネットワークシステムのHYPERchannel上のインターネット・プロトコル：プロトコル仕様"、STD 45、RFC 1044、1988年2月。

[RFC1329] Kuehn, P., "Thoughts on Address Resolution for Dual MAC FDDI Networks", RFC 1329, May 1992.

[RFC1329]キューン、P.、RFC 1329、1992年5月 "デュアルMAC FDDIネットワークのアドレス解決に関する考察"。

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。

[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.

[RFC2132]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。

[RFC2176] Murakami, K. and M. Maruyama, "IPv4 over MAPOS Version 1", RFC 2176, June 1997.

[RFC2176]村上、K.およびM.丸山、 "MAPOS版1上のIPv4"、RFC 2176、1997年6月。

[RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.

[RFC2225]ラウバッハ、M.及びJ.アルペルン、 "古典IPおよびATM上ARP"、RFC 2225、1998年4月。

[RFC2834] Pittet, J., "ARP and IP Broadcast over HIPPI-800", RFC 2834, May 2000.

[RFC2834] Pittet、J.、 "HIPPI-800を超えるARPおよびIPブロードキャスト"、RFC 2834、2000年5月。

[RFC2835] Pittet, J., "IP and ARP over HIPPI-6400 (GSN)", RFC 2835, May 2000.

[RFC2835] Pittet、J.、 "HIPPI-6400（GSN）オーバーIP及びARP"、RFC 2835、2000年5月。

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。

[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.

[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。

[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel", RFC 4338, January 2006.

[RFC4338] DeSanti、C.、カールソン、C.、およびR.ニクソン、 "IPv6の、IPv4のの送信、アドレス解決プロトコル（ARP）、ファイバチャネル上のパケット"、RFC 4338、2006年1月。

[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.

[RFC4361]レモン、T.とB.ゾンマーフェルト、RFC 4361、2006年2月「動的ホスト構成プロトコルバージョン四つ（のDHCPv4）のためのノード固有のクライアント識別子」。

[RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)", RFC 4701, October 2006.

[RFC4701]スタップ、M.、レモン、T.、およびA.グスタフソン、RFC 4701 "エンコーディング動的ホスト構成プロトコル（DHCP）の情報（DHCID RR）のためのDNSリソースレコード（RR）"、2006年10月。

[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月。

[RFC5342] Eastlake. , D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008.

[RFC5342]イーストレイク。、D.、 "IANAの考慮事項およびIEEE 802個のパラメータのためのIETFプロトコルの使用"、BCP 141、RFC 5342、2008年9月。

6.2. Informative References

6.2. 参考文献

[RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.

[RFC0903]フィンレイソン、R.、マン、T.、モーグル、J.、およびM. Theimer、 "逆アドレス解決プロトコル"、STD 38、RFC 903、1984年6月。

[RFC1931] Brownell, D., "Dynamic RARP Extensions for Automatic Network Address Acquisition", RFC 1931, April 1996.

[RFC1931]ブラウネル、D.、1996年4月、RFC 1931の "自動ネットワークの動的RARP拡張機能は、買収アドレス"。

[RFC2390] Bradley, T., Brown, C., and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, September 1998.

[RFC2390]ブラッドリー、T.、ブラウン、C.、およびA. Malis、 "逆アドレス解決プロトコル"、RFC 2390、1998年9月。

[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.

[RFC3456]パテル、B.、Aboba、B.、ケリー、S.、およびV.グプタ、 "IPsecのトンネルモードの動的ホスト構成プロトコル（DHCPv4の）設定"、RFC 3456、2003年1月。

Appendix A. Changes from the Original RFCs

オリジナルのRFCから付録A.変更点

This document specifies only the IANA rules associated with various fields in ARP. The specification of these rules also affects the allocation of corresponding fields in protocols listed in Section 1 that share the registry. This document does not make any changes in the operation of these protocols themselves.

この文書では、ARPでの様々な分野に関連する唯一IANA規則を指定します。これらのルールの仕様は、レジストリを共有項1に記載されているプロトコルに対応するフィールドの割り当てに影響を与えます。この文書では、これらのプロトコルそのものの動作中に変更を加えることはありません。

Authors' Addresses

著者のアドレス

Jari Arkko Ericsson Jorvas 02420 Finland

ヤリArkkoエリクソン02420 Jorvasフィンランド

EMail: jari.arkko@piuha.net

メールアドレス：jari.arkko@piuha.net

Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA

カルロスPignataroシスコシステムズ7200から12キットクリーク道路リサーチトライアングルパーク、NC 27709 USA

EMail: cpignata@cisco.com

メールアドレス：cpignata@cisco.com