[要約] RFC 6747は、IPv4のIdentifier-Locator Network Protocol（ILNPv4）のためのAddress Resolution Protocol（ARP）に関する規格です。このRFCの目的は、ILNPv4ネットワークでのARPの動作と機能を定義し、ILNPv4の実装と展開をサポートすることです。
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6747 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
Identifier-Locator Network Protocol for IPv4（ILNPv4）のアドレス解決プロトコル（ARP）
Abstract
概要
This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group.
このドキュメントでは、IPv4のIdentifier-Locator Network Protocol（ILNPv4）をサポートするためのアドレス解決プロトコル（ARP）拡張を定義します。 ILNPは、IPを実験的に進化させたものです。この文書はIRTF Routing Research Groupの製品です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Routing Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、Internet Research Task Force（IRTF）のRouting Research Groupの1人以上のメンバーの個々の意見を表します。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6747.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6747で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントは、RFCとして公開するためにフォーマットしたり、英語以外の言語に翻訳したりする場合を除き、変更したり、その派生物を作成したりすることはできません。
Table of Contents
目次
1. Introduction ....................................................3
1.1. ILNP Document Roadmap ......................................3
1.2. Terminology ................................................5
2. ARP Extensions for ILNPv4 .......................................5
2.1. ILNPv4 ARP Request Packet Format ...........................5
2.2. ILNPv4 ARP Reply Packet Format .............................7
2.3. Operation and Implementation of ARP for ILNPv4 .............8
3. Security Considerations .........................................9
4. IANA Considerations .............................................9
5. References .....................................................10
5.1. Normative References ......................................10
5.2. Informative References ....................................11
6. Acknowledgements ...............................................11
This document is part of the ILNP document set, which has had extensive review within the IRTF Routing RG. ILNP is one of the recommendations made by the RG Chairs. Separately, various refereed research papers on ILNP have also been published during this decade. So, the ideas contained herein have had much broader review than the IRTF Routing RG. The views in this document were considered controversial by the Routing RG, but the RG reached a consensus that the document still should be published. The Routing RG has had remarkably little consensus on anything, so virtually all Routing RG outputs are considered controversial.
このドキュメントは、IRTF Routing RG内で広範囲に渡って検討されたILNPドキュメントセットの一部です。 ILNPは、RG議長が行った勧告の1つです。これとは別に、ILNPに関するさまざまな査読付き研究論文もこの10年間に発行されています。したがって、ここに含まれているアイデアは、IRTF Routing RGよりもはるかに広範なレビューを受けています。このドキュメントの見解は、ルーティングRGによって物議を醸すと見なされましたが、RGは、ドキュメントを引き続き公開する必要があるというコンセンサスに達しました。ルーティングRGのコンセンサスは著しく低いため、事実上すべてのルーティングRG出力は物議を醸すと見なされています。
At present, the Internet research and development community are exploring various approaches to evolving the Internet Architecture to solve a variety of issues including, but not limited to, scalability of inter-domain routing [RFC4984]. A wide range of other issues (e.g., site multihoming, node multihoming, site/subnet mobility, node mobility) are also active concerns at present. Several different classes of evolution are being considered by the Internet research and development community. One class is often called "Map and Encapsulate", where traffic would be mapped and then tunnelled through the inter-domain core of the Internet. Another class being considered is sometimes known as "Identifier/Locator Split". This document relates to a proposal that is in the latter class of evolutionary approaches.
現在、インターネットの研究開発コミュニティは、ドメイン間ルーティング[RFC4984]のスケーラビリティなど、さまざまな問題を解決するためにインターネットアーキテクチャを進化させるさまざまなアプローチを模索しています。他のさまざまな問題（サイトマルチホーミング、ノードマルチホーミング、サイト/サブネットモビリティ、ノードモビリティなど）も、現在、活発に懸念されています。いくつかの異なるクラスの進化が、インターネットの研究開発コミュニティによって検討されています。 1つのクラスは「マップとカプセル化」と呼ばれることが多く、トラフィックはマップされ、インターネットのドメイン間コアを介してトンネリングされます。検討中の別のクラスは、「識別子/ロケータースプリット」と呼ばれることもあります。この文書は、進化論的アプローチの後者のクラスにある提案に関連しています。
The Identifier Locator Network Protocol (ILNP) is a proposal for evolving the Internet Architecture. It differs from the current Internet Architecture primarily by deprecating the concept of an IP Address, and instead defining two new objects, each having crisp syntax and semantics. The first new object is the Locator, a topology-dependent name for a subnetwork. The other new object is the Identifier, which provides a topology-independent name for a node.
Identifier Locator Network Protocol（ILNP）は、インターネットアーキテクチャを進化させるための提案です。これは、主にIPアドレスの概念を廃止し、代わりにそれぞれが明確な構文とセマンティクスを持つ2つの新しいオブジェクトを定義することで、現在のインターネットアーキテクチャとは異なります。最初の新しいオブジェクトは、トポロジーに依存するサブネットワークの名前であるLocatorです。もう1つの新しいオブジェクトはIdentifierで、トポロジーに依存しない名前をノードに提供します。
This document describes extensions to ARP for use with ILNPv4.
このドキュメントでは、ILNPv4で使用するためのARPの拡張について説明します。
The ILNP architecture can have more than one engineering instantiation. For example, one can imagine a "clean-slate" engineering design based on the ILNP architecture. In separate documents, we describe two specific engineering instances of ILNP. The term ILNPv6 refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv6. The term ILNPv4 refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv4.
ILNPアーキテクチャーは、複数のエンジニアリングのインスタンス化を持つことができます。たとえば、ILNPアーキテクチャに基づく「白紙」のエンジニアリング設計を想像できます。別のドキュメントで、ILNPの2つの特定のエンジニアリングインスタンスについて説明します。 ILNPv6という用語は、IPv6に基づいており、IPv6と下位互換性があるILNPのインスタンスを正確に指します。 ILNPv4という用語は、IPv4に基づいており、IPv4と下位互換性があるILNPのインスタンスを正確に指します。
Many engineering aspects common to both ILNPv4 and ILNPv6 are described in [RFC6741]. A full engineering specification for either ILNPv6 or ILNPv4 is beyond the scope of this document.
ILNPv4とILNPv6の両方に共通する多くの工学的側面が[RFC6741]で説明されています。 ILNPv6またはILNPv4の完全なエンジニアリング仕様は、このドキュメントの範囲外です。
Readers are referred to other related ILNP documents for details not described here:
ここで説明されていない詳細については、読者は関連する他のILNP文書を参照されます。
a) [RFC6740] is the main architectural description of ILNP, including the concept of operations.
a) [RFC6740]は、運用の概念を含む、ILNPの主要なアーキテクチャの説明です。
b) [RFC6741] describes engineering and implementation considerations that are common to both ILNPv4 and ILNPv6.
b) [RFC6741]では、ILNPv4とILNPv6の両方に共通するエンジニアリングと実装の考慮事項について説明しています。
c) [RFC6742] defines additional DNS resource records that support ILNP.
c) [RFC6742]は、ILNPをサポートする追加のDNSリソースレコードを定義します。
d) [RFC6743] defines a new ICMPv6 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
d) [RFC6743]は、ILNPノードがその対応するノードに有効なロケーターのセットに対する変更を通知するために使用する新しいICMPv6ロケーター更新メッセージを定義します。
e) [RFC6744] defines a new IPv6 Nonce Destination Option used by ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by inclusion within the initial packets of an ILNP session) that the node is operating in the ILNP mode and (2) to prevent off-path attacks against ILNP ICMP messages. This Nonce is used, for example, with all ILNP ICMPv6 Locator Update messages that are exchanged among ILNP correspondent nodes.
e) [RFC6744]は、ILNPv6ノードによって使用される新しいIPv6ナンス宛先オプションを定義して（1）ILNP対応ノードに（ILNPセッションの初期パケット内に含めることにより）ノードがILNPモードで動作していることを示し、（2） ILNP ICMPメッセージに対するオフパス攻撃。このノンスは、たとえば、ILNP対応ノード間で交換されるすべてのILNP ICMPv6ロケーター更新メッセージで使用されます。
f) [RFC6745] defines a new ICMPv4 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
f) [RFC6745]は、ILNPノードが対応するノードに有効なロケーターのセットに対する変更を通知するために使用する新しいICMPv4ロケーター更新メッセージを定義します。
g) [RFC6746] defines a new IPv4 Nonce Option used by ILNPv4 nodes to carry a security nonce to prevent off-path attacks against ILNP ICMP messages and also defines a new IPv4 Identifier Option used by ILNPv4 nodes.
g) [RFC6746]は、ILNPv4ノードによって使用される新しいIPv4 Nonceオプションを定義して、ILNP ICMPメッセージに対するオフパス攻撃を防ぐためのセキュリティナンスを伝送し、ILNPv4ノードによって使用される新しいIPv4識別子オプションも定義します。
h) [RFC6748] describes optional engineering and deployment functions for ILNP. These are not required for the operation or use of ILNP and are provided as additional options.
h) [RFC6748]は、ILNPのオプションのエンジニアリングおよび展開機能について説明しています。これらはILNPの操作または使用に必要ではなく、追加のオプションとして提供されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
ILNP for IPv4 (ILNPv4) is merely a different instantiation of the ILNP architecture, so it retains the crisp distinction between the Locator and the Identifier. As with ILNPv6, only the Locator values are used for routing and forwarding ILNPv4 packets [RFC6740]. As with ILNP for IPv6 (ILNPv6), when ILNPv4 is used for a network-layer session, the upper-layer protocols (e.g., TCP/UDP pseudo-header checksum, IPsec Security Association) bind only to the Identifiers, never to the Locators [RFC6741].
ILNP for IPv4（ILNPv4）は、ILNPアーキテクチャの単なる別のインスタンス化であるため、ロケーターと識別子の明確な区別が維持されます。 ILNPv6と同様に、ILNPv4パケットのルーティングと転送には、ロケーター値のみが使用されます[RFC6740]。 ILNP for IPv6（ILNPv6）と同様に、ILNPv4がネットワーク層セッションに使用される場合、上位層プロトコル（たとえば、TCP / UDP疑似ヘッダーチェックサム、IPsecセキュリティアソシエーション）は識別子にのみバインドし、ロケーターにはバインドしません。 [RFC6741]。
However, just as the packet format for IPv4 is different to IPv6, so the engineering details for ILNPv4 are different also. While ILNPv6 is carefully engineered to be fully backwards-compatible with IPv6 Neighbor Discovery, ILNPv4 relies upon an extended version of the Address Resolution Protocol (ARP) [RFC826], which is defined here. While ILNPv4 could have been engineered to avoid changes in ARP, that would have required that the ILNPv4 Locator (i.e., L32) have slightly different semantics, which was architecturally undesirable.
ただし、IPv4のパケット形式がIPv6とは異なるため、ILNPv4のエンジニアリングの詳細も異なります。 ILNPv6は、IPv6近隣探索と完全に下位互換性を持つように慎重に設計されていますが、ILNPv4は、ここで定義されているアドレス解決プロトコル（ARP）[RFC826]の拡張バージョンに依存しています。 ILNPv4はARPの変更を回避するように設計されている可能性がありますが、ILNPv4ロケーター（つまり、L32）のセマンティクスがわずかに異なる必要があり、これはアーキテクチャ的に望ましくありませんでした。
The packet formats used are direct extensions of the existing widely deployed ARP Request (OP code 1) and ARP Reply (OP code 2) packet formats. This design was chosen for practical engineering reasons (i.e., to maximise code reuse), rather than for maximum protocol design purity.
使用されるパケット形式は、既存の広く展開されているARP要求（OPコード1）およびARP応答（OPコード2）パケット形式を直接拡張したものです。この設計は、プロトコル設計の純粋さを最大にするためではなく、実際のエンジニアリング上の理由（つまり、コードの再利用を最大化するため）で選択されました。
We anticipate that ILNPv6 is much more likely to be widely implemented and deployed than ILNPv4. However, having a clear definition of ILNPv4 helps demonstrate the difference between architecture and engineering, and also demonstrates that the common ILNP architecture can be instantiated in different ways with different existing network-layer protocols.
ILNPv6は、ILNPv4よりも広く実装および展開される可能性がはるかに高いと予想されます。ただし、ILNPv4の明確な定義は、アーキテクチャとエンジニアリングの違いを実証するのに役立ち、一般的なILNPアーキテクチャが、既存の異なるネットワーク層プロトコルを使用してさまざまな方法でインスタンス化できることも示しています。
The ILNPv4 ARP Request is an extended version of the widely deployed ARP Request (OP code 1). For experimentation purposes, the ILNPv4 ARP Request OP code uses decimal value 24. It is important to note that decimal value 24 is a pre-defined, shared-use experimental OP code for ARP [RFC5494], and is not uniquely assigned to ILNPv4 ARP Requests. The ILNPv4 ARP Request extension permits the Node Identifier (NID) values to be carried in the ARP message, in addition to the node's 32-bit Locator (L32) values [RFC6742].
ILNPv4 ARP要求は、広く展開されているARP要求（OPコード1）の拡張バージョンです。実験の目的で、ILNPv4 ARP要求OPコードは10進数値24を使用します。10進数値24はARP [RFC5494]の事前定義された共有使用の実験OPコードであり、ILNPv4 ARPに一意に割り当てられないことに注意することが重要ですリクエスト。 ILNPv4 ARP要求拡張では、ノードの32ビットロケーター（L32）値に加えて、ノード識別子（NID）値をARPメッセージで運ぶことができます[RFC6742]。
0 7 15 23 31
+--------+--------+--------+--------+
| HT | PT |
+--------+--------+--------+--------+
| HAL | PAL | OP |
+--------+--------+--------+--------+
| S_HA (bytes 0-3) |
+--------+--------+--------+--------+
| S_HA (bytes 4-5)|S_L32 (bytes 0-1)|
+--------+--------+--------+--------+
|S_L32 (bytes 2-3)|S_NID (bytes 0-1)|
+--------+--------+--------+--------+
| S_NID (bytes 2-5) |
+--------+--------+--------+--------+
|S_NID (bytes 6-7)| T_HA (bytes 0-1)|
+--------+--------+--------+--------+
| T_HA (bytes 3-5) |
+--------+--------+--------+--------+
| T_L32 (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 4-7) |
+--------+--------+--------+--------+
Figure 2.1: ILNPv4 ARP Request packet format
図2.1：ILNPv4 ARP要求パケット形式
In Figure 2.1, the fields are as follows:
図2.1では、フィールドは次のとおりです。
HT Hardware Type (*) PT Protocol Type (*) HAL Hardware Address Length (*) PAL Protocol Address Length (uses new value 12) OP Operation Code (uses experimental value OP_EXP1=24) S_HA Sender Hardware Address (*) S_L32 Sender L32 (* same as Sender IPv4 address for ARP) S_NID Sender Node Identifier (8 bytes) T_HA Target Hardware Address (*) T_L32 Target L32 (* same as Target IPv4 address for ARP) T_NID Target Node Identifier (8 bytes)
HTハードウェアタイプ（*）PTプロトコルタイプ（*）HALハードウェアアドレス長（*）PALプロトコルアドレス長（新しい値12を使用）OPオペレーションコード（実験値OP_EXP1 = 24を使用）S_HA送信者ハードウェアアドレス（*）S_L32送信者L32 （* ARPの送信者IPv4アドレスと同じ）S_NID送信者ノード識別子（8バイト）T_HAターゲットハードウェアアドレス（*）T_L32ターゲットL32（* ARPのターゲットIPv4アドレスと同じ）T_NIDターゲットノード識別子（8バイト）
The changed OP code indicates that this is ILNPv4 and not IPv4. The semantics and usage of the ILNPv4 ARP Request are identical to the existing ARP Request (OP code 2), except that the ILNPv4 ARP Request is sent only by nodes that support ILNPv4.
変更されたOPコードは、これがIPv4ではなくILNPv4であることを示しています。 ILNPv4 ARP要求の意味と使用法は、ILNPv4 ARP要求がILNPv4をサポートするノードによってのみ送信されることを除いて、既存のARP要求（OPコード2）と同じです。
The field descriptions marked with "*" should have the same values as for ARP as used for IPv4.
「*」の付いたフィールドの説明には、IPv4で使用されるARPと同じ値を指定する必要があります。
The ILNPv4 ARP Reply is an extended version of the widely deployed ARP Reply (OP code 2). For experimentation purposes, the ILNPv4 ARP Request OP code uses decimal value 25. It is important to note that decimal value 25 is a pre-defined, shared-use experimental OP code for ARP [RFC5494], and is not uniquely assigned to ILNPv4 ARP Requests. The ILNPv4 ARP Reply extension permits the Node Identifier (NID) values to be carried in the ARP message, in addition to the node's 32-bit Locator (L32) values [RFC6742].
ILNPv4 ARP応答は、広く展開されているARP応答（OPコード2）の拡張バージョンです。実験の目的で、ILNPv4 ARP要求OPコードは10進値25を使用します。10進値25はARP [RFC5494]の事前定義された共有使用の実験OPコードであり、ILNPv4 ARPに一意に割り当てられないことに注意することが重要ですリクエスト。 ILNPv4 ARP応答拡張では、ノードの32ビットロケーター（L32）値に加えて、ノード識別子（NID）値をARPメッセージで運ぶことができます[RFC6742]。
0 7 15 23 31
+--------+--------+--------+--------+
| HT | PT |
+--------+--------+--------+--------+
| HAL | PAL | OP |
+--------+--------+--------+--------+
| S_HA (bytes 0-3) |
+--------+--------+--------+--------+
| S_HA (bytes 4-5)|S_L32 (bytes 0-1)|
+--------+--------+--------+--------+
|S_L32 (bytes 2-3)|S_NID (bytes 0-1)|
+--------+--------+--------+--------+
| S_NID (bytes 2-5) |
+--------+--------+--------+--------+
|S_NID (bytes 6-7)| T_HA (bytes 0-1)|
+--------+--------+--------+--------+
| T_HA (bytes 3-5) |
+--------+--------+--------+--------+
| T_L32 (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 4-7) |
+--------+--------+--------+--------+
Figure 2.2: ILNPv4 ARP Reply packet format
図2.2：ILNPv4 ARP応答パケットの形式
In Figure 2.2, the fields are as follows:
図2.2では、フィールドは次のとおりです。
HT Hardware Type (*) PT Protocol Type (*) HAL Hardware Address Length (*) PAL Protocol Address Length (uses new value 12) OP Operation Code (uses experimental value OP_EXP2=25) S_HA Sender Hardware Address (*) S_L32 Sender L32 (* same as Sender IPv4 address for ARP) S_NID Sender Node Identifier (8 bytes) T_HA Target Hardware Address (*) T_L32 Target L32 (* same as Target IPv4 address for ARP) T_NID Target Node Identifier (8 bytes)
HTハードウェアタイプ（*）PTプロトコルタイプ（*）HALハードウェアアドレス長（*）PALプロトコルアドレス長（新しい値12を使用）OPオペレーションコード（実験値OP_EXP2 = 25を使用）S_HA送信者ハードウェアアドレス（*）S_L32送信者L32 （* ARPの送信者IPv4アドレスと同じ）S_NID送信者ノード識別子（8バイト）T_HAターゲットハードウェアアドレス（*）T_L32ターゲットL32（* ARPのターゲットIPv4アドレスと同じ）T_NIDターゲットノード識別子（8バイト）
The changed OP code indicates that this is ILNPv4 and not IPv4. The semantics and usage of the ILNPv4 ARP Reply are identical to the existing ARP Reply (OP code 2), except that the ILNPv4 ARP Reply is sent only by nodes that support ILNPv4.
変更されたOPコードは、これがIPv4ではなくILNPv4であることを示しています。 ILNPv4 ARP応答がILNPv4をサポートするノードによってのみ送信されることを除いて、ILNPv4 ARP応答のセマンティクスと使用法は既存のARP応答（OPコード2）と同じです。
The field descriptions marked with "*" should have the same values as for ARP as used for IPv4.
「*」の付いたフィールドの説明には、IPv4で使用されるARPと同じ値を指定する必要があります。
The operation of ARP for ILNPv4 is almost identical to that for IPv4. Essentially, the key differences are:
ILNPv4のARPの動作は、IPv4の場合とほぼ同じです。基本的に、主な違いは次のとおりです。
a) where an IPv4 ARP Request would use IPv4 addresses, an ILNPv4 ARP Request MUST use: 1. a 32-bit L32 value (_L32 suffixes in Figures 2.1 and 2.2) 2. a 64-bit NID value (_NID suffixes in Figures 2.1 and 2.2)
a) IPv4 ARP要求がIPv4アドレスを使用する場合、ILNPv4 ARP要求は以下を使用する必要があります。1. 32ビットL32値（図2.1および2.2の_L32サフィックス）2. 64ビットNID値（図2.1および2.2の_NIDサフィックス） ）
b) where an IPv4 ARP Reply would use IPv4 addresses, an ILNPv4 ARP Reply MUST use: 1. a 32-bit L32 value (_L32 suffixes in Figures 2.1 and 2.2) 2. a 64-bit NID value (_NID suffixes in Figures 2.1 and 2.2)
b) IPv4 ARP応答がIPv4アドレスを使用する場合、ILNPv4 ARP応答は以下を使用する必要があります。1. 32ビットL32値（図2.1および2.2の_L32サフィックス）2. 64ビットNID値（図2.1および2.2の_NIDサフィックス） ）
As the OP codes 24 and 25 are distinct from ARP for IPv4, but the packet formats in Figures 2.1 and 2.2 are, effectively, extended versions of the corresponding ARP packets. It should be possible to implement this extension of ARP by extending existing ARP implementations rather than having to write an entirely new implementation for ILNPv4. It should be emphasised, however, that OP codes 24 and 25 are for experimental use as defined in [RFC5494], and so it is possible that other experimental protocols could be using these OP codes concurrently.
OPコード24および25はIPv4のARPとは異なりますが、図2.1および2.2のパケット形式は、対応するARPパケットの拡張バージョンです。 ILNPv4の完全に新しい実装を作成する必要はなく、既存のARP実装を拡張することにより、このARPの拡張を実装できるはずです。ただし、OPコード24と25は[RFC5494]で定義されている実験用であり、他の実験プロトコルがこれらのOPコードを同時に使用している可能性があることを強調しておく必要があります。
Security considerations for the overall ILNP architecture are described in [RFC6740]. Additional common security considerations applicable to ILNP are described in [RFC6741]. This section describes security considerations specific to the specific ILNPv4 topics discussed in this document.
ILNPアーキテクチャ全体のセキュリティに関する考慮事項は、[RFC6740]で説明されています。 ILNPに適用可能な追加の一般的なセキュリティの考慮事項は、[RFC6741]で説明されています。このセクションでは、このドキュメントで説明する特定のILNPv4トピックに固有のセキュリティの考慮事項について説明します。
The existing widely deployed Address Resolution Protocol (ARP) for IPv4 is a link-layer protocol, so it is not vulnerable to off-link attackers. In this way, it is a bit different than IPv6 Neighbor Discovery (ND); IPv6 ND is a subset of the Internet Control Message Protocol (ICMP), which runs over IPv6.
IPv4用の既存の広く展開されているアドレス解決プロトコル（ARP）はリンク層プロトコルであるため、オフリンク攻撃者に対して脆弱ではありません。この点で、IPv6近隣探索（ND）とは少し異なります。 IPv6 NDは、IPv6上で実行されるインターネット制御メッセージプロトコル（ICMP）のサブセットです。
However, ARP does not include any form of authentication, so current ARP deployments are vulnerable to a range of attacks from on-link nodes. For example, it is possible for one node on a link to forge an ARP packet claiming to be from another node, thereby "stealing" the other node's IPv4 address. [RFC5227] describes several of these risks and some measures that an ARP implementation can use to reduce the chance of accidental IPv4 address misconfiguration and also to detect such misconfiguration if it should occur.
ただし、ARPには認証の形式が含まれていないため、現在のARP展開は、リンク上のノードからのさまざまな攻撃に対して脆弱です。たとえば、リンク上の1つのノードが別のノードからのものであると主張するARPパケットを偽造して、他のノードのIPv4アドレスを「盗む」ことが可能です。 [RFC5227]は、これらのリスクのいくつかと、ARP実装が偶発的なIPv4アドレスの誤った構成の可能性を減らすために使用でき、発生した場合にそのような誤った構成を検出するためのいくつかの対策について説明しています。
This extension does not change the security risks that are inherent in using ARP.
この拡張機能は、ARPの使用に固有のセキュリティリスクを変更しません。
In situations where additional protection against on-link attackers is needed (for example, within high-risk operational environments), the IEEE standards for link-layer security [IEEE-802.1-AE] SHOULD be implemented and deployed.
リンク上の攻撃者に対する追加の保護が必要な状況（たとえば、リスクの高い運用環境内）では、リンク層セキュリティのIEEE標準[IEEE-802.1-AE]を実装して展開する必要があります（SHOULD）。
Implementers of this specification need to understand that the two OP code values used for these 2 extensions are not uniquely assigned to ILNPv4. Other experimenters might be using the same two OP code values at the same time for different ARP-related experiments. Absent prior coordination among all users of a particular IP subnetwork, different experiments might be occurring on the same IP subnetwork. So, implementations of these two ARP extensions ought to be especially defensively coded.
この仕様の実装者は、これらの2つの拡張に使用される2つのOPコード値がILNPv4に一意に割り当てられていないことを理解する必要があります。他の実験者は、異なる2つのARP関連実験に同じ2つのOPコード値を同時に使用している可能性があります。特定のIPサブネットワークのすべてのユーザー間で事前の調整がない場合、同じIPサブネットワークで異なる実験が行われる可能性があります。したがって、これらの2つのARP拡張の実装は、特に防御的にコーディングする必要があります。
This document makes no request of IANA.
このドキュメントは、IANAの要求を行いません。
If in the future the IETF decided to standardise ILNPv4, then allocation of unique ARP OP codes for the two extensions above would be sensible as part of the IETF standardisation process.
IETFが将来ILNPv4を標準化することを決定した場合、上記の2つの拡張に対する一意のARP OPコードの割り当ては、IETF標準化プロセスの一部として賢明です。
[IEEE-802.1-AE] IEEE, "Media Access Control (MAC) Security", IEEE Standard 802.1 AE, 18 August 2006, IEEE, New York, NY, 10016, USA.
[IEEE-802.1-AE] IEEE、「Media Access Control（MAC）Security」、IEEE Standard 802.1 AE、2006年8月18日、IEEE、ニューヨーク、ニューヨーク、10016、USA。
[RFC826] 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.
[RFC826] Plummer、D.、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、1982年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, July 2008.
[RFC5227] Cheshire、S。、「IPv4 Address Conflict Detection」、RFC 5227、2008年7月。
[RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines for the Address Resolution Protocol (ARP)", RFC 5494, April 2009.
[RFC5494] Arkko、J。およびC. Pignataro、「IANA Allocation Allocation Guidelines for the Address Resolution Protocol（ARP）」、RFC 5494、2009年4月。
[RFC6740] Atkinson, R. and S. Bhatti, "Identifier Locator Network Protocol (ILNP) Architectural Description", RFC 6740, November 2012.
[RFC6740] Atkinson、R。およびS. Bhatti、「Identifier Locator Network Protocol（ILNP）Architectural Description」、RFC 6740、2012年11月。
[RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations", RFC 6741, November 2012.
[RFC6741] Atkinson、R。およびS. Bhatti、「Identifier-Locator Network Protocol（ILNP）Engineering and Implementation Considerations」、RFC 6741、2012年11月。
[RFC6742] Atkinson, R., Bhatti, S., and S. Rose, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", RFC 6742, November 2012.
[RFC6742] Atkinson、R.、Bhatti、S。、およびS. Rose、「Identifier-Locator Network Protocol（ILNP）のDNSリソースレコード」、RFC 6742、2012年11月。
[RFC6745] Atkinson, R. and S. Bhatti, "ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)", RFC 6745, November 2012.
[RFC6745] Atkinson、R。およびS. Bhatti、「IPv4のIdentifier-Locatorネットワークプロトコル用のICMPロケーター更新メッセージ（ILNPv4）」、RFC 6745、2012年11月。
[RFC6746] Atkinson, R. and S.Bhatti, "IPv4 Options for the Identifier-Locator Network Protocol (ILNP)", RFC 6746, November 2012.
[RFC6746] Atkinson、R。およびS.Bhatti、「Identifier-Locator Network Protocol（ILNP）のIPv4オプション」、RFC 6746、2012年11月。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984] Meyer、D。、編、Zhang、L。、編、およびK. Fall、編、「ルーティングとアドレッシングに関するIABワークショップからの報告」、RFC 4984、2007年9月。
[RFC6743] Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update Message", RFC 6743, November 2012.
[RFC6743] Atkinson、R。およびS. Bhatti、「ICMPv6 Locator Update Message」、RFC 6743、2012年11月。
[RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6744, November 2012.
[RFC6744] Atkinson、R。およびS. Bhatti、「IPv6のIdentifier-Locator Network ProtocolのIPv6 Nonce宛先オプション（ILNPv6）」、RFC 6744、2012年11月。
[RFC6748] Atkinson, R. and S. Bhatti, "Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)", RFC 6748, November 2012.
[RFC6748] Atkinson、R。およびS. Bhatti、「Identifier-Locator Network Protocol（ILNP）のオプションの高度な配備シナリオ」、RFC 6748、2012年11月。
Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson, Robin Whittle, and John Wroclawski (in alphabetical order) provided review and feedback on earlier versions of this document. Steve Blake provided an especially thorough review of an early version of the entire ILNP document set, which was extremely helpful. We also wish to thank the anonymous reviewers of the various ILNP papers for their feedback.
スティーブブレイク、ステファンボルツマイヤー、モハメドブーカデール、ノエルチアッパ、ウェスジョージ、スティーブヘイルズ、ジョエルハルパーン、マークハンドラリー、フォルカーヒルト、ポールジャクマ、デヨンキム、トニーリー、ヤコフレクター、ブルースシンプソン、ロビンウィットル、ジョンブロツラフスキ（アルファベット順）このドキュメントの以前のバージョンのレビューとフィードバックを提供しました。 Steve Blakeは、ILNPドキュメントセット全体の初期バージョンの特に徹底的なレビューを提供しました。これは非常に役に立ちました。また、フィードバックをいただいたさまざまなILNP論文の匿名の査読者にも感謝します。
Roy Arends provided expert guidance on technical and procedural aspects of DNS issues.
Roy Arendsは、DNS問題の技術的および手続き的側面について専門家のガイダンスを提供しました。
Authors' Addresses
著者のアドレス
RJ Atkinson Consultant San Jose, CA, 95125 USA
ＲＪ あｔきんそん こんすｌたんｔ さん じょせ、 か、 ９５１２５ うさ
EMail: rja.lists@gmail.com
SN Bhatti School of Computer Science University of St Andrews North Haugh, St Andrews, Fife KY16 9SX Scotland, UK
SN Bhattiコンピュータサイエンススクールセントアンドリュース大学ノースハウ、セントアンドリュース、ファイフKY16 9SXスコットランド、イギリス
EMail: saleem@cs.st-andrews.ac.uk