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

原文URL : https://datatracker.ietf.org/doc/html/rfc5494
タイトル : RFC 5494 - アドレス解決プロトコル（ARP）のIANA割り当てガイドライン
翻訳編集 : 自動生成

[要約] RFC 5494は、ARPのIANA割り当てガイドラインを提供しています。その目的は、ARPプロトコルのアドレス割り当てに関する一貫性と効率性を確保することです。

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。

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）番号スペースは、ブートストラッププロトコル（BOOTP）[RFC0951]およびダイナミックホスト構成プロトコル（DHCP）[RFC2131]の「HTYPE」（ハードウェアアドレスタイプ）フィールドでも使用されます。、およびDHCPV6のDHCP一意の識別子の「ハードウェアタイプ」フィールド[RFC3315]において。したがって、これらのプロトコルは、IANAルールの更新の影響を受けます。その他の影響を受ける仕様には、以下の専門的なアドレス解決メカニズムが含まれます。

o HYPERchannel [RFC1044]

o ハイパーチャネル[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ガイドラインはセクション2に記載されています。以前は、このような割り当てのためのIANAガイダンスは存在していませんでした。このドキュメントの目的は、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 [RFC3456]の「IPSECトンネル」など、BOOTP/DHCPV4に適用されるリクエストに1-OCTET値を割り当てる必要があります。逆に、ARPのみの使用は、BOOTP/DHCPV4で同じ値を使用する予見可能な理由がないため、2-OCTET値を支持する必要があります。

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.

値を指定しない個々の新しいar $ hrd値のリクエスト、または要求された値が255を超える場所は、最初に提供されることで行われます[RFC5226]。割り当ては常に2オクタート値になります。

ar$pro (16 bits) Protocol address space

ar $ pro（16ビット）プロトコルアドレススペース

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

これらの数字は、EtherTypeスペースを共有しています。EtherType空間は、[RFC5342]に記載されているように管理されます。

ar$op (16 bits) Opcode

ar $ op（16ビット）opcode

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

新しいar $ op値のリクエストは、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.

o 実験目的で2つの新しいAR $ HRD値が割り当てられます：hw_exp1（36）とhw_exp2（256）。これらの2つの新しい値は、1つが256未満になり、もう1つが255を超えるように意図的に選択され、最小で最も重要なオクテットに異なる値があるようにすることに注意してください。

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

o AR $ OPの2つの新しい値は、実験目的で割り当てられます：OP_EXP1（24）およびOP_EXP2（25）。

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 $ opの両方で、値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から新しい値が要求されたために浮上しています。著者は、特にこの問題を育ててくれたMichelle Cottonに感謝したいと思います。著者はまた、ブライアン・カーペンター、トーマス・ナルテン、スコット・ブラッドナー、ドナルド・イーストレイク、アンドリュー・G・マリス、ブライアン・ハーバーマン、ロバート・スパークス、ラリー・ズー、デイブ・ターラーにフィードバックに感謝したいと思います。

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] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。

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

[RFC0951] Croft、B。およびJ. Gilmore、「Bootstrap Protocol」、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] Hardwick、K。およびJ. Lekashman、「ネットワークシステムのハイパーチャネルに関するインターネットプロトコル：プロトコル仕様」、STD 45、RFC 1044、1988年2月。

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

[RFC1329] Kuehn、P。、「デュアルMAC FDDIネットワークの住所解像度に関する考え」、RFC 1329、1992年5月。

[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] Alexander、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.マルヤマ、「IPv4 Over Maposバージョン1」、RFC 2176、1997年6月。

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

[RFC2225] Laubach、M。and J. Halpern、「Classical IP and ARP Over ATM」、RFC 2225、1998年4月。

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

[RFC2834] Pittet、J。、「ARPおよびIP放送hippi-800」、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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、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.、Carlson、C。、およびR. Nixon、「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] Lemon、T。およびB. Sommerfeld、「動的ホスト構成プロトコルバージョン4（DHCPV4）のノード固有のクライアント識別子」、RFC 4361、2006年2月。

[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] Stapp、M.、Lemon、T。、およびA. Gustafsson、「ダイナミックホスト構成プロトコル（DHCP）情報（DHCID RR）をエンコードするためのDNSリソースレコード（RR）」、RFC 4701、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。、「IEEE 802パラメーターに対するIANAの考慮事項と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] Finlayson、R.、Mann、T.、Mogul、J。、およびM. Theimer、「Reverse Address Resolution Protocol」、STD 38、RFC 903、1984年6月。

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

[RFC1931] Brownell、D。、「自動ネットワークアドレスの取得のための動的RARP拡張」、RFC 1931、1996年4月。

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

[RFC2390] Bradley、T.、Brown、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] Patel、B.、Aboba、B.、Kelly、S。、およびV. Gupta、「Ipsecトンネルモードの動的ホスト構成プロトコル（DHCPV4）構成」、RFC 3456、2003年1月。

Appendix A. Changes from the Original RFCs

付録A. 元のRFCからの変更

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

Jari Arkko Ericsson Jorvas 02420フィンランド

   EMail: jari.arkko@piuha.net

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

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

   EMail: cpignata@cisco.com