[要約] 要約： RFC 6741は、Identifier-Locator Network Protocol（ILNP）のエンジニアリングに関する考慮事項を提供しています。このプロトコルは、ネットワーク上の識別子と場所情報を分離することで、ネットワークの拡張性と柔軟性を向上させることを目的としています。目的： 1. ILNPのエンジニアリングに関する考慮事項を提供する。 2. ネットワークの拡張性と柔軟性を向上させるために、識別子と場所情報の分離を実現する。 3. ILNPの実装や設計に関わる技術者や研究者に向けて、ガイドラインを提供する。
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6741 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Identifier-Locator Network Protocol (ILNP) Engineering Considerations
Identifier-Locator Network Protocol（ILNP）エンジニアリングの考慮事項
Abstract
概要
This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group.
このドキュメントでは、Identifier-Locator Network Protocol（ILNP）の一般的な（つまり、バージョンに依存しない）エンジニアリングの詳細について説明します。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/rfc6741.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6741で入手できます。
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. Document Roadmap ...........................................4
1.2. Terminology ................................................5
2. ILNP Identifiers ................................................5
2.1. Syntax .....................................................6
2.2. Default Values for an Identifier ...........................6
2.3. Local-Scoped Identifier Values .............................6
2.4. Multicast Identifiers ......................................7
2.5. Administration of Identifier Values ........................7
3. Encoding of Identifiers and Locators for ILNPv6 .................7
3.1. Encoding of I and L Values .................................7
3.2. Network-Level Packet Formats ..............................10
3.3. Encoding of Identifiers and Locators for ILNPv4 ...........11
4. Transport-Layer Changes ........................................12
4.1. End-System State ..........................................12
4.2. TCP/UDP Checksum Handling .................................12
4.3. ICMP Checksum Handling ....................................12
5. ILNP Communication Cache (ILCC) ................................13
5.1. Formal Definition .........................................13
5.2. Ageing ILCC Entries .......................................15
5.3. Large Numbers of Locators .................................15
5.4. Lookups into the ILCC .....................................16
6. Handling Location/Connectivity Changes .........................16
6.1. Node Location/Connectivity Changes ........................16
6.2. Network Connectivity/Locator Changes ......................17
7. Subnetting .....................................................17
7.1. Subnetting for ILNPv6 .....................................18
7.2. Subnetting for ILNPv4 .....................................19
7.3. Subnetting for Router-Router Links in IPv6/ILNPv6 .........19
8. DNS Considerations .............................................19
8.1. Secure Dynamic DNS Update .................................19
8.2. New DNS RR Types ..........................................20
8.4. DNS TTL Values for ILNP RRS Types .........................21
8.5. IP/ILNP Dual Operation and Transition .....................21
9. IP Security for ILNP ...........................................22
9.1. IPsec Security Association Enhancements for ILNP ..........22
9.2. IP Authentication Header Enhancements for ILNP ............23
9.3. Key Management Considerations .............................23
10. Backwards Compatibility and Incremental Deployment ............24
10.1. Priorities in the Design of ILNPv6 and ILNPv4 ............24
10.2. Infrastructure ...........................................25
10.3. Core Protocols ...........................................25
10.4. Scope of End-System Changes ..............................26
10.5. Applications .............................................27
10.6. Interworking between IP and ILNP .........................27
11. Security Considerations .......................................28
11.1. Authenticating ICMP Messages .............................29
11.2. Forged Identifier Attacks ................................31
12. Privacy Considerations ........................................31
13. Operational Considerations ....................................31
13.1. Session Liveness and Reachability ........................32
13.2. Key Management Considerations ............................33
13.3. Point-to-Point Router Links ..............................33
14. Referrals and Application Programming Interfaces ..............34
14.1. BSD Sockets APIs .........................................34
14.2. Java (and Other) APIs ....................................34
14.3. Referrals in the Future ..................................35
15. References ....................................................35
15.1. Normative References .....................................35
15.2. Informative References ...................................36
16. Acknowledgements ..............................................38
The ILNP document set 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 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.
ILNPドキュメントセットは、IRTF Routing RG内で広範囲に渡ってレビューされています。 ILNPは、RG議長が行った勧告の1つです。これとは別に、ILNPに関するさまざまな査読付き研究論文もこの10年間に発行されています。したがって、ここに含まれているアイデアは、IRTF Routing RGよりもはるかに広範なレビューを受けています。このドキュメントの見解は、ルーティングRGによって物議を醸すと見なされましたが、RGは、ドキュメントを引き続き公開する必要があるというコンセンサスに達しました。ルーティングRGのコンセンサスは著しく低いため、事実上すべてのルーティングRG出力は物議を醸すと見なされています。
At present, the Internet research and development community is 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 an experimental network protocol that provides evolutionary enhancements to IP. ILNP is backwards compatible with IP and is incrementally deployable. The best starting point for learning about ILNP is the ILNP Architectural Description, which includes a document roadmap [RFC6740].
Identifier-Locator Network Protocol（ILNP）は、IPに進化的な拡張機能を提供する実験的なネットワークプロトコルです。 ILNPはIPと下位互換性があり、段階的に展開できます。 ILNPについて学習するための最適な開始点は、ILNPアーキテクチャの説明であり、ドキュメントロードマップ[RFC6740]が含まれています。
This document describes engineering and implementation considerations that are common to both ILNP for IPv4 (ILNPv4) and ILNP for IPv6 (ILNPv6).
このドキュメントでは、ILNP for IPv4（ILNPv4）とILNP for IPv6（ILNPv6）の両方に共通するエンジニアリングと実装の考慮事項について説明します。
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 this document. A full engineering specification for either ILNPv6 or ILNPv4 is beyond the scope of this document.
このドキュメントでは、ILNPv4とILNPv6の両方に共通する多くのエンジニアリングの側面について説明します。 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) [RFC6742] defines additional DNS resource records that support ILNP.
b) [RFC6742]は、ILNPをサポートする追加のDNSリソースレコードを定義します。
c) [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.
c) [RFC6743]は、ILNPノードがその対応するノードに有効なロケーターのセットに対する変更を通知するために使用する新しいICMPv6ロケーター更新メッセージを定義します。
d) [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.
d) [RFC6744]は、ILNPv6ノードによって使用される新しいIPv6ナンス宛先オプションを定義して（1）ILNP対応ノードに（ILNPセッションの初期パケット内に含めることにより）ノードがILNPモードで動作していることを示し、（2） ILNP ICMPメッセージに対するオフパス攻撃。このノンスは、たとえば、ILNP対応ノード間で交換されるすべてのILNP ICMPv6ロケーター更新メッセージで使用されます。
e) [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.
e) [RFC6745]は、ILNPノードが対応するノードに有効なロケーターのセットに対する変更を通知するために使用する新しいICMPv4ロケーター更新メッセージを定義します。
f) [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.
f) [RFC6746]は、ILNPv4ノードによって使用される新しいIPv4 Nonceオプションを定義して、ILNP ICMPメッセージに対するオフパス攻撃を防ぐためのセキュリティナンスを伝送し、ILNPv4ノードによって使用される新しいIPv4識別子オプションも定義します。
g) [RFC6747] describes extensions to Address Resolution Protocol (ARP) for use with ILNPv4.
g) [RFC6747]は、ILNPv4で使用するためのアドレス解決プロトコル（ARP）の拡張について説明しています。
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]で説明されているように解釈されます。
Several technical terms (e.g., "ILNP session") that are used by this document are defined in [RFC6740]. It is strongly recommended that one read [RFC6740] before reading this document.
このドキュメントで使用されているいくつかの技術用語（「ILNPセッション」など）は、[RFC6740]で定義されています。この文書を読む前に[RFC6740]を読むことを強くお勧めします。
All ILNP nodes must have at least one Node Identifier (or just "Identifier") value. However, there are various options for generating those Identifier values. We describe, in this section, the relevant engineering issues related to Identifier generation and usage.
すべてのILNPノードには、少なくとも1つのノード識別子（または単に「識別子」）の値が必要です。ただし、これらの識別子の値を生成するためのさまざまなオプションがあります。このセクションでは、識別子の生成と使用に関連するエンジニアリングの問題について説明します。
Note well that an ILNP Node Identifier names an ILNP-capable node, and it is NOT bound to a specific interface of that node. So a given ILNP Node Identifier is valid on all active interfaces of the node to which that ILNP Identifier is bound. This is true even if the bits used to form the Identifier value happened to be taken from a specific interface as an engineering convenience.
ILNPノード識別子はILNP対応ノードを指定し、そのノードの特定のインターフェイスにバインドされていないことに注意してください。したがって、特定のILNPノードIDは、そのILNP IDがバインドされているノードのすべてのアクティブなインターフェースで有効です。 Identifier値を形成するために使用されるビットが、エンジニアリングの便宜上、たまたま特定のインターフェイスから取得された場合でも、これは当てはまります。
ILNP Identifiers are always unsigned 64-bit strings, and they may be realised as 64-bit unsigned integers. Both ILNPv4 and ILNPv6 use the Modified EUI-64 [IEEE-EUI] syntax that is used by IPv6 interface identifiers [RFC4291], Section 2.5.1, as shown in Figure 2.1.
ILNP IDは常に符号なし64ビット文字列であり、64ビット符号なし整数として実現される場合があります。 ILNPv4とILNPv6はどちらも、図2.1に示すように、IPv6インターフェース識別子[RFC4291]、セクション2.5.1で使用されるModified EUI-64 [IEEE-EUI]構文を使用します。
+--------------------------------------------------+
| 6 id bits | U bit | G bit | 24 id bits |
+--------------------------------------------------+
| 32 id bits |
+--------------------------------------------------+
Figure 2.1: Node Identifier Format as Used for IPv6, Using the Same Syntax as in RFC 4291, Section 2.5.1.
図2.1：IPv6で使用されるノード識別子形式、RFC 4291、セクション2.5.1と同じ構文を使用
That syntax contains two special reserved bit flags. One flag (the U bit) indicates whether the value has "universal" (i.e., global) scope (1) or "local" (0) scope. The other flag (the G bit) indicates whether the value is an "individual" address (1) or "group" (i.e., multicast) (0) address.
その構文には、2つの特別な予約済みビットフラグが含まれています。 1つのフラグ（Uビット）は、値が「ユニバーサル」（つまり、グローバル）スコープ（1）または「ローカル」（0）スコープを持つかどうかを示します。もう1つのフラグ（Gビット）は、値が「個別の」アドレス（1）か「グループ」（つまり、マルチキャスト）（0）のアドレスかを示します。
However, this format does allow other values to be set, by use of administrative or other policy control, as required, by setting the U bit to "local".
ただし、このフォーマットでは、Uビットを「ローカル」に設定することにより、必要に応じて管理またはその他のポリシー制御を使用して、他の値を設定できます。
By default, this value, including the U bit and G bit, are set as described in Section 2.5.1 of [RFC4291]. Where no other value of Identifier is available for an ILNP node, this is the value that MUST be used.
デフォルトでは、UビットとGビットを含むこの値は、[RFC4291]のセクション2.5.1の説明に従って設定されています。 ILNPノードで利用可能なIdentifierの他の値がない場合、これは使用する必要がある値です。
Because ILNP Identifiers might have local scope, and also to handle the case where two nodes at different locations happen to be using the same global scope Identifier (e.g., due to a manufacturing fault in a network chipset or card), implementers must be careful in how ILNP Identifiers are handled within an end system's networking implementation. Some details are discussed in Section 4 below.
ILNP IDにはローカルスコープがあり、異なる場所にある2つのノードが偶然に同じグローバルスコープIDを使用している場合（ネットワークチップセットまたはカードの製造上の欠陥など）を処理するため、実装者は注意する必要があります。 ILNP IDがエンドシステムのネットワーク実装内でどのように処理されるか。詳細については、以下のセクション4で説明します。
ILNP Identifiers for a node also MAY have the Scope bit of the Node Identifier set to "local" scope. Locally unique identifiers MAY be Cryptographically Generated, created following the procedures used for IPv6 Cryptographically Generated Addresses (CGAs) [RFC3972] [RFC4581] [RFC4982].
ノードのILNP識別子でも、ノード識別子のスコープビットが「ローカル」スコープに設定されている場合があります。ローカルで一意の識別子は、暗号で生成されてもよく、IPv6の暗号で生成されたアドレス（CGA）[RFC3972] [RFC4581] [RFC4982]に使用される手順に従って作成されてもよい。
Also, locally unique identifiers MAY be used to create the ILNP equivalent to the Privacy Extensions for IPv6, generating ILNP Identifiers following the procedures used for IPv6 [RFC4941].
また、ローカルで一意の識別子を使用して、IPv6のプライバシー拡張と同等のILNPを作成し、IPv6 [RFC4941]で使用される手順に従ってILNP識別子を生成できます。
An ILNP Identifier with the G bit set to "group" names an ILNP multicast group, while an ILNP Identifier with the G bit set to "individual" names an individual ILNP node. However, this usage of multicast for Identifiers for ILNP is currently undefined: ILNP uses IPv6 multicast for ILNPv6 and IPv4 multicast for ILNPv4 and uses the multicast address formats defined as appropriate.
Gビットが「グループ」に設定されたILNP IDはILNPマルチキャストグループを指定し、Gビットが「個別」に設定されたILNP IDは個々のILNPノードを指定します。ただし、ILNPの識別子のマルチキャストのこの使用法は現在定義されていません。ILNPは、ILNPv6のIPv6マルチキャストとILNPv4のIPv4マルチキャストを使用し、必要に応じて定義されたマルチキャストアドレス形式を使用します。
The use of multicast Identifiers and design of an enhanced multicast capability for ILNPv6 and ILNPv4 is currently work in progress.
マルチキャスト識別子の使用とILNPv6およびILNPv4の拡張マルチキャスト機能の設計は現在進行中です。
Note that just as IPv6 does not need global, centralised administrative management of its interface identifiers, so ILNPv6 does not need global, centralised administrative management of the Node Identifier (NID) values.
IPv6がインターフェイス識別子のグローバルな集中管理管理を必要としないのと同様に、ILNPv6はノード識別子（NID）値のグローバルな集中管理管理を必要としないことに注意してください。
With ILNPv6, the Identifier and Locator values within a packet are encoded in the existing space for the IPv6 address. In general, the ILNPv6 Locator has the same syntax and semantics as the current IPv6 unicast routing prefix, as shown in Figure 3.1:
ILNPv6では、パケット内の識別子とロケーターの値がIPv6アドレスの既存のスペースにエンコードされます。一般に、ILNPv6ロケーターの構文とセマンティクスは、図3.1に示すように、現在のIPv6ユニキャストルーティングプレフィックスと同じです。
/* IPv6 */
| 64 bits | 64 bits |
+-------------------------------------+-------------------------+
| IPv6 Unicast Routing Prefix | Interface Identifier |
+-------------------------------------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+-------------------------------------+-------------------------+
| Locator | Node Identifier (NID) |
+-------------------------------------+-------------------------+
Figure 3.1: The General Format of Encoding of I/NID and L Values for ILNPv6 into the IPv6 Address Bits The syntactical structure of the IPv6 address spaces remains as given in Section 2.5.4 of [RFC4291], and an example is shown in Figure 3.2, which is based in part on [RFC3177] (which has since been obsoleted by [RFC6177]).
図3.1：ILNPv6のI / NIDとL値をIPv6アドレスビットにエンコードする一般的な形式3.2、これは[RFC3177]（[RFC6177]によって廃止された）に部分的に基づいています。
/* IPv6 */
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
|001|global routing prefix| subnet ID | Interface Identifier |
+---+---------------------+-----------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
| Locator (L64) | Node Identifier (NID) |
+---+---------------------+-----------+-------------------------+
Figure 3.2: Example of IPv6 Address Format as Used in ILNPv6
図3.2：ILNPv6で使用されるIPv6アドレス形式の例
The global routing prefix bits and subnet ID bits above are as for [RFC3177], but could be different, e.g., as for [RFC6177].
上記のグローバルルーティングプレフィックスビットとサブネットIDビットは[RFC3177]の場合と同じですが、[RFC6177]のように異なる場合があります。
The ILNPv6 Locator uses the upper 64-bits of the 128-bit IPv6 address space. It has the same syntax and semantics as today's IPv6 routing prefix. So, an ILNPv6 packet carrying a Locator value can be used just like an IPv6 packet today as far as core routers are concerned.
ILNPv6ロケーターは、128ビットIPv6アドレス空間の上位64ビットを使用します。現在のIPv6ルーティングプレフィックスと同じ構文とセマンティクスを持っています。したがって、ロケーター値を運ぶILNPv6パケットは、コアルーターに関する限り、IPv6パケットと同じように使用できます。
The example in Figure 3.2 happens to use a /48 prefix, as was recommended by [RFC3177]. However, more recent advice is that prefixes need not be fixed at /48 and could be up to /64 [RFC6177]. This change, however, does not impact the syntax or semantics of the Locator value.
[RFC3177]で推奨されているように、図3.2の例ではたまたま/ 48プレフィックスが使用されています。しかし、より最近のアドバイスは、プレフィックスを/ 48に固定する必要はなく、最大/ 64にすることができるということです[RFC6177]。ただし、この変更はLocator値の構文またはセマンティクスには影響しません。
The ILNPv6 Identifier value uses the lower 64-bits of the 128-bit IPv6 address. It has the same syntax as an IPv6 identifier, but different semantics. This provides a fixed-length non-topological name for a node. Identifiers are bound to nodes, not to interfaces of a node. All ILNP Identifiers MUST comply with the modified EUI-64 syntax already specified for IPv6's "interface identifier" values, as described in Section 2.1.
ILNPv6識別子の値は、128ビットIPv6アドレスの下位64ビットを使用します。構文はIPv6識別子と同じですが、セマンティクスが異なります。これにより、ノードに固定長の非トポロジ名が提供されます。識別子は、ノードのインターフェースではなくノードにバインドされます。セクション2.1で説明されているように、すべてのILNP識別子は、IPv6の「インターフェース識別子」値にすでに指定されている変更されたEUI-64構文に準拠する必要があります。
IEEE EUI-64 Identifiers can have either global-scope or local-scope. So ILNP Identifiers also can have either global-scope or local-scope. A reserved bit in the modified EUI-64 syntax clearly indicates whether a given Identifier has global-scope or local-scope. A node is not required to use a global-scope Identifier, although that is the recommended practice. Note that the syntax of the Node Identifier field has exactly the same syntax as that defined for IPv6 address in Section 2.5.1 of [RFC4291]. (This is based on the IEEE EUI-64 syntax [IEEE-EUI], but is not the same.)
IEEE EUI-64識別子は、グローバルスコープまたはローカルスコープを持つことができます。そのため、ILNP識別子は、グローバルスコープまたはローカルスコープを持つこともできます。変更されたEUI-64構文の予約済みビットは、特定の識別子がグローバルスコープまたはローカルスコープを持っているかどうかを明確に示します。ノードはグローバルスコープ識別子を使用する必要はありませんが、推奨される方法です。 [Node Identifier]フィールドの構文は、[RFC4291]のセクション2.5.1でIPv6アドレスに対して定義された構文とまったく同じであることに注意してください。 （これは、IEEE EUI-64構文[IEEE-EUI]に基づいていますが、同じではありません。）
Most commonly, Identifiers have global-scope and are derived from one or more IEEE 802 or IEEE 1394 'MAC Addresses' (sic) already associated with the node, following the procedure already defined for IPv6 [RFC4291]. Global-scope identifiers have a high probability of being globally unique. This approach eliminates the need to manage Identifiers, among other benefits.
最も一般的には、識別子はグローバルスコープを持ち、すでにノードに関連付けられている1つ以上のIEEE 802またはIEEE 1394 'MACアドレス'（sic）から派生し、IPv6 [RFC4291]ですでに定義されている手順に従います。グローバルスコープ識別子は、グローバルに一意である可能性が高くなります。このアプローチにより、とりわけ、識別子を管理する必要がなくなります。
Local-scope Identifiers MUST be unique within the context of their Locators. The existing mechanisms of the IPv4 Address Resolution Protocol [RFC826] and IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] automatically enforce this constraint.
ローカルスコープ識別子は、ロケーターのコンテキスト内で一意である必要があります。 IPv4アドレス解決プロトコル[RFC826]およびIPv6ステートレスアドレス自動構成（SLAAC）[RFC4862]の既存のメカニズムは、この制約を自動的に適用します。
For example, on an Ethernet-based IPv4 subnetwork the ARP Reply message is sent via link-layer broadcast, thereby advertising the current binding between an IPv4 address and a Media Access Control (MAC) address to all nodes on that IPv4 subnetwork. (Note also that a well-known, long standing, issue with ARP is that it cannot be authenticated.) Local-scope Identifiers MUST NOT be used with other Locators without first ensuring uniqueness in the context of those other Locators e.g., by using IPv6 Neighbour Discovery's Duplicate Address Detection mechanism when using ILNPv6 or by sending an ARP Request when using ILNPv4.
たとえば、イーサネットベースのIPv4サブネットワークでは、ARP応答メッセージがリンク層ブロードキャストを介して送信されるため、IPv4アドレスとメディアアクセスコントロール（MAC）アドレス間の現在のバインディングが、そのIPv4サブネットワーク上のすべてのノードにアドバタイズされます。 （ARPのよく知られている、長年にわたる問題は認証できないということにも注意してください。）ローカルスコープ識別子は、他のロケーターのコンテキストで一意性を最初に保証せずに（たとえばIPv6を使用して）、他のロケーターで使用してはなりません（MUST NOT）。 ILNPv6を使用する場合、またはILNPv4を使用する場合にARP要求を送信することによる、近隣探索の重複アドレス検出メカニズム。
Other methods might be used to generate local-scope Identifiers. For example, one might derive Identifiers using some form of cryptographic generation or using the methods specified in the IPv6 Privacy Extensions [RFC4941] to Stateless Address Autoconfiguration (SLAAC) [RFC4862]. When cryptographic generation of Identifiers using methods described in RFC 3972 is in use, only the Identifier is included, never the Locator, thereby preserving roaming capability. One could also imagine creating a local-scope Identifier by taking a cryptographic hash of a node's public key. Of course, in the unlikely event of an Identifier collision, for example, when a node has chosen to use a local-scope Identifier value, the node remains free to use some other local-scope Identifier value(s).
ローカルスコープの識別子を生成するために、他の方法が使用される場合があります。たとえば、何らかの形式の暗号化生成を使用して、またはIPv6プライバシー拡張[RFC4941]からステートレスアドレス自動構成（SLAAC）[RFC4862]で指定された方法を使用して、識別子を導出できます。 RFC 3972で説明されている方法を使用した識別子の暗号生成が使用されている場合、ロケーターではなく識別子のみが含まれるため、ローミング機能が維持されます。また、ノードの公開鍵の暗号化ハッシュを取得してローカルスコープの識別子を作成することもできます。もちろん、ノードがローカルスコープの識別子の値を使用することを選択した場合など、識別子の衝突が発生する可能性はほとんどありませんが、ノードは他のローカルスコープの識別子の値を自由に使用できます。
It is worth remembering here that an IPv6 address names a specific network interface on a specific node, but an ILNPv6 Identifier names the node itself, not a specific interface on the node. This difference in definition is essential to providing seamless support for mobility and multihoming, which are discussed in more detail later in this note.
ここで、IPv6アドレスは特定のノードの特定のネットワークインターフェイスを指定しますが、ILNPv6識別子はノード自体を指定し、ノードの特定のインターフェイスは指定しないことを覚えておく価値があります。この定義の違いは、モビリティとマルチホーミングのシームレスなサポートを提供するために不可欠です。これらについては、このノートで後ほど詳しく説明します。
ILNPv6 Locator and Identifier values are encoded into IPv6 address space and ILNPv6 uses directly the Classic IPv6 packet format, as shown in Figure 3.3. This is also the view of an ILNPv6 packet as seen by core routers -- they simply use the Locator value (top 64-bits of the address field) just as they would use an IPv6 prefix today (e.g., either as /48 or as /64 when using sub-network routing).
図3.3に示すように、ILNPv6ロケーターと識別子の値はIPv6アドレス空間にエンコードされ、ILNPv6はクラシックIPv6パケット形式を直接使用します。これは、コアルーターから見たILNPv6パケットのビューでもあります。それらは、今日IPv6プレフィックスを使用するのと同じように、ロケーター値（アドレスフィールドの上位64ビット）を使用します（たとえば、/ 48または/ 64サブネットワークルーティングを使用する場合）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.3: Existing ("Classic") IPv6 Header
図3.3：既存の（「クラシック」）IPv6ヘッダー
In essence, the Locator names a subnetwork. (Locators can also be referred to as Routing Prefixes if discussing Classic IPv6). Of course, backwards compatibility requirements mean that ILNPv6 Locators use the same number space as IPv6 routing prefixes. This ensures that no changes are needed to deployed IPv6 routers when deploying ILNPv6.
基本的に、ロケーターはサブネットワークに名前を付けます。 （クラシックIPv6について説明する場合、ロケーターはルーティングプレフィックスとも呼ばれます）。もちろん、下位互換性の要件は、ILNPv6ロケーターがIPv6ルーティングプレフィックスと同じ番号スペースを使用することを意味します。これにより、ILNPv6を展開するときに、展開されたIPv6ルーターに変更を加える必要がなくなります。
The low-order 64-bits of the IPv6 address become the Identifier. Details of the Identifier were discussed above. The Identifier is only used by end-systems, so Figure 3.4 shows the view of the same packet format, but as viewed by an ILNPv6 node. As this only needs to be parsed in this way by the end-system, so ILNPv6 deployment is enabled incrementally by updating end-systems as required.
IPv6アドレスの下位64ビットが識別子になります。識別子の詳細は上記で説明しました。識別子はエンドシステムでのみ使用されるため、図3.4は同じパケット形式のビューを示していますが、ILNPv6ノードで表示されています。これはエンドシステムでこのように解析する必要があるだけなので、ILNPv6の展開は、必要に応じてエンドシステムを更新することで段階的に有効になります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Locator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier |
| |
+ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Locator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Identifier |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.4: ILNPv6 Header as Seen by ILNPv6-Enabled End-Systems
図3.4：ILNPv6対応エンドシステムから見たILNPv6ヘッダー
Encoding of Identifier and Locator values for ILNPv4 is not as straightforward as for ILNPv6. In analogy to ILNPv6, in ILNPv4, the Locator value is a routing prefix for IPv4, but is at most 30 bits. Source Locator values are carried in the source address field of the IPv4 header, and destination Locator values in the destination address field. So, just like for ILNPv6, for ILNPv4, packet routing can be performed by routers examining existing prefix values in the IPv4 header.
ILNPv4の識別子とロケーターの値のエンコードは、ILNPv6の場合ほど簡単ではありません。 ILNPv6と同様に、ILNPv4では、Locator値はIPv4のルーティングプレフィックスですが、最大で30ビットです。送信元ロケーターの値はIPv4ヘッダーの送信元アドレスフィールドに含まれ、宛先ロケーターの値は宛先アドレスフィールドに含まれます。したがって、ILNPv6の場合と同様に、ILNPv4の場合、IPv4ヘッダーの既存のプレフィックス値を調べるルーターでパケットルーティングを実行できます。
However, for ILNPv4, additional option headers have to be used to carry the Identifier value as there is not enough room in the normal IPv4 header fields. A 64-bit Identifier value is carried in an option header. So, the detailed explanation of the ILNPv4 packet header is to be found in [RFC6746].
ただし、ILNPv4の場合、通常のIPv4ヘッダーフィールドに十分なスペースがないため、識別子の値を運ぶために追加のオプションヘッダーを使用する必要があります。 64ビットの識別子の値は、オプションヘッダーに含まれています。したがって、ILNPv4パケットヘッダーの詳細な説明は、[RFC6746]にあります。
ILNP uses an Identifier value in order to form the invariant end-system state for end-to-end protocols. Currently, transport protocols such as TCP and UDP use all the bits of an IP Address to form such state. So, transport protocol implementations MUST be modified in order to operate over ILNP.
ILNPは、エンドツーエンドプロトコルの不変のエンドシステム状態を形成するために、識別子の値を使用します。現在、TCPやUDPなどのトランスポートプロトコルは、IPアドレスのすべてのビットを使用してそのような状態を形成しています。したがって、トランスポートプロトコルの実装は、ILNP上で動作するように変更する必要があります。
Currently, TCP and UDP, for example, use the 4-tuple:
現在、たとえば、TCPとUDPは4タプルを使用します。
<local port, remote port, local IP Address, remote IP Address>
<ローカルポート、リモートポート、ローカルIPアドレス、リモートIPアドレス>
for the end-system state for a transport layer end-point. For ILNP, implementations must be modified to instead use the following:
トランスポート層のエンドポイントのエンドシステム状態。 ILNPの場合、代わりに以下を使用するように実装を変更する必要があります。
<local port, remote port, local Identifier, remote Identifier>
<ローカルポート、リモートポート、ローカル識別子、リモート識別子>
In IP-based implementations, the TCP or UDP pseudo-header checksum calculations include all the bits of the IP Address. By contrast, when calculating the TCP or UDP pseudo-header checksums for use with ILNP, only the Identifier values are included in the TCP or UDP pseudo-header checksum calculations.
IPベースの実装では、TCPまたはUDPの疑似ヘッダーチェックサム計算には、IPアドレスのすべてのビットが含まれます。対照的に、ILNPで使用するためのTCPまたはUDP疑似ヘッダーチェックサムを計算する場合、TCPまたはUDP疑似ヘッダーチェックサムの計算には識別子の値のみが含まれます。
To minimise the changes required within transport protocol implementations, and to maximise interoperability, current implementations are modified to zero the Locator fields (only for the purpose of TCP or UDP checksum calculations). For example, for ILNPv6, this means that the existing code for IPv6 can be used, with the ILNPv6 Identifier bits occupying the lower 64 bits of the IPv6 address field, and the upper 64 bits of the IPv6 address filed being set to zero. For ILNPv4, the Identifier fields are carried in an IPv4 Option [RFC6746].
トランスポートプロトコル実装内で必要な変更を最小限に抑え、相互運用性を最大化するために、現在の実装はロケーターフィールドをゼロに変更します（TCPまたはUDPチェックサム計算の目的のみ）。たとえば、ILNPv6の場合、これは、IPv6の既存のコードを使用できることを意味し、ILNPv6識別子ビットはIPv6アドレスフィールドの下位64ビットを占有し、ファイルされたIPv6アドレスの上位64ビットはゼロに設定されます。 ILNPv4の場合、識別子フィールドはIPv4オプション[RFC6746]で伝達されます。
Section 7 describes methods for incremental deployment of this ILNP-specific change and backwards compatibility with non-upgraded nodes (e.g., classic IPv4 or IPv6 nodes) in more detail.
セクション7では、このILNP固有の変更を段階的に展開する方法と、アップグレードされていないノード（従来のIPv4ノードやIPv6ノードなど）との下位互換性について詳しく説明します。
To maximise backwards compatibility, the ILNPv6 ICMP checksum is always calculated in the same way as for IPv6 ICMP. Similarly, the ILNPv4 ICMP checksum is always calculated in the same way as for IPv4 ICMP.
下位互換性を最大化するために、ILNPv6 ICMPチェックサムは常にIPv6 ICMPの場合と同じ方法で計算されます。同様に、ILNPv4 ICMPチェックサムは、常にIPv4 ICMPの場合と同じ方法で計算されます。
For operational purposes, implementations need to have a local cache of state information that allow communication endpoints to be constructed and for communication protocols to operate. Such cache information is common today, e.g., IPv4 nodes commonly maintain an Address Resolution Protocol (ARP) cache with information relating to current and recent Correspondent Nodes (CNs); IPv6 nodes maintain a Neighbor Discovery (ND) table with information relating to current and CNs. Likewise, ILNP maintains an Identifier Locator Communication Cache (ILCC) with information relating to the operation of ILNP.
運用目的のために、実装には、通信エンドポイントを構築し、通信プロトコルが動作できるようにする状態情報のローカルキャッシュが必要です。そのようなキャッシュ情報は今日では一般的です。たとえば、IPv4ノードは一般に、現在および最近のコレスポンデントノード（CN）に関する情報を持つアドレス解決プロトコル（ARP）キャッシュを維持します。 IPv6ノードは、現在およびCNに関する情報を含む近隣探索（ND）テーブルを維持します。同様に、ILNPは、ILNPの操作に関連する情報を含む識別子ロケーター通信キャッシュ（ILCC）を維持します。
The ILCC is a (logical) set of data values required for ILNP to operate. These values are maintained by the endpoints of each ILNP session.
ILCCは、ILNPの動作に必要なデータ値の（論理）セットです。これらの値は、各ILNPセッションのエンドポイントによって維持されます。
In theory, this cache is within the ILNP network-layer. However, many network protocol implementations do not have strict protocol separation or layering. So there is no requirement that the ILCC be kept partitioned from transport-layer protocols.
理論的には、このキャッシュはILNPネットワーク層内にあります。ただし、多くのネットワークプロトコル実装には、厳密なプロトコルの分離または階層化がありません。したがって、ILCCをトランスポート層プロトコルから分割しておく必要はありません。
Note that, in many implementations, much of the information required for the ILCC may already be present. Where some additional information is required for ILNP, from an engineering viewpoint, the ILCC could be implemented by extending or enhancing existing data structures within existing implementations. For example, by adding appropriate flags to the data structures in existing implementations.
多くの実装では、ILCCに必要な情報の多くがすでに存在している場合があることに注意してください。 ILNPにいくつかの追加情報が必要な場合、エンジニアリングの観点から、ILCCは、既存の実装内の既存のデータ構造を拡張または拡張することによって実装できます。たとえば、既存の実装のデータ構造に適切なフラグを追加します。
Note that the ILCC does not impose any extra state maintenance requirements for applications or applications servers. For example, in the case of, say, HTTP, there will be no additional state for a server to maintain, and any TCP state will be handled by the ILNP code in the OS just as for IP.
ILCCは、アプリケーションまたはアプリケーションサーバーに追加の状態維持要件を課さないことに注意してください。たとえば、HTTPなどの場合、サーバーが維持する追加の状態はなく、TCP状態はIPの場合と同様にOSのILNPコードによって処理されます。
The ILCC contains information about both the local node and also about current or recent correspondent nodes, as follows.
ILCCには、次のように、ローカルノードと現在または最近のコレスポンデントノードの両方に関する情報が含まれています。
Information about the local node:
ローカルノードに関する情報：
- Each currently valid Identifier value, including its Identifier Precedence and whether it is active at present.
- 識別子の優先順位や現在アクティブかどうかなど、現在有効な識別子の値。
- Each currently valid Locator value, including its associated local interface(s), its Locator Precedence and whether it is active at present.
- 関連付けられているローカルインターフェイス、ロケーターの優先順位、現在アクティブかどうかなど、現在有効な各ロケーター値。
- Each currently valid IL Vector (I-LV), including whether it is active at present.
- 現在有効な各ILベクター（I-LV）（現在アクティブかどうかを含む）。
Information about each correspondent node:
各コレスポンデントノードに関する情報：
- Most recent set of Identifiers, including lifetime and validity for each.
- それぞれの寿命と有効性を含む、最新の識別子のセット。
- Most recent set of Locators, including lifetime and validity for each.
- それぞれの寿命と有効性を含む、最新のロケーターのセット。
- Nonce value for packets from the local host to the correspondent.
- ローカルホストから通信相手へのパケットのノンス値。
- Nonce value for packets from the correspondent to the local host.
- 通信相手からローカルホストへのパケットのノンス値。
In the above list for the ILNP Communication Cache:
上記のILNP通信キャッシュのリスト：
- A "valid" item is usable, from an administrative point of view, but it might or might not be in use at present.
- 「有効な」アイテムは、管理の観点からは使用できますが、現在使用されている場合とそうでない場合があります。
- The "validity" parameter for the correspondent node indicates one of several different states for a datum. These include at least the following:
- コレスポンデントノードの「有効性」パラメーターは、データムのいくつかの異なる状態の1つを示します。これらには、少なくとも次のものが含まれます。
- "valid": data is usable and has not expired.
- 「有効」：データは使用可能で、有効期限が切れていません。
- "active": data is usable, has not expired, and is in active use at present.
- 「アクティブ」：データは使用可能で、有効期限が切れておらず、現在アクティブに使用されています。
- "expired": data is still in use at present, but is beyond its expiration (i.e., without a replacement value).
- 「期限切れ」：データは現在も使用中ですが、期限切れです（つまり、置換値なし）。
- "aged": data was recently in use, but is not in active use at present, and is beyond its expiration.
- 「古くなった」：データは最近使用されましたが、現在アクティブに使用されておらず、有効期限が切れています。
- The "lifetime" parameter is an implementation-specific representation of the validity lifetime for the associated data element. In normal operation, the Lifetime for a correspondent node's Locator(s) are learned from the DNS Time-To-Live (DNS TTL) value associated with DNS records (NID, L32, L64, etc.) of the Fully Qualified Domain Name (FQDN) owner name of the correspondent node. For time, a node might use UTC (e.g., via Network Time Protocol) or perhaps some node-specific time (e.g., seconds since node boot).
- 「lifetime」パラメーターは、関連するデータ要素の有効期間の実装固有の表現です。通常の操作では、対応するノードのロケーターの存続期間は、完全修飾ドメイン名のDNSレコード（NID、L32、L64など）に関連付けられているDNS存続時間（DNS TTL）値から学習されます（ FQDN）コレスポンデントノードの所有者名。時間については、ノードはUTC（Network Time Protocolなど）を使用するか、ノード固有の時間（ノードの起動からの秒数）を使用する場合があります。
As a practical engineering matter, it is not sensible to flush all Locator values associated with an existing ILNP session's correspondent node even if the DNS TTL associated with those Locator values expires.
実際のエンジニアリングの問題として、既存のILNPセッションの対応するノードに関連付けられたすべてのロケーター値をフラッシュすることは、それらのロケーター値に関連付けられたDNS TTLが期限切れになったとしても、賢明ではありません。
In some situations, a CN might be disconnected briefly when moving location (e.g., immediate handover, which sometimes is called "break before make"). If this happens, there might be a brief pause before the Correspondent Node can (a) update its own L values in the DNS, and (b) send an ICMP Locator Update message to the local node with information about its new location. Implementers ought to try to maintain ILNP sessions even when such events occur.
状況によっては、場所を移動するときにCNが一時的に切断されることがあります（たとえば、即時のハンドオーバー。これは「ブレークビフォアメイク」と呼ばれることもあります）。これが発生した場合、コレスポンデントノードが（a）DNS内の自身のL値を更新し、（b）ICMPロケーター更新メッセージを新しい場所に関する情報とともにローカルノードに送信する前に、少し休止する可能性があります。実装者は、そのようなイベントが発生した場合でもILNPセッションを維持しようとする必要があります。
Instead, Locator values cached for a correspondent node SHOULD be marked as "aged" when their TTL has expired, but retained until either the next Locator Update message is received, there is other indication that a given Locator is not working any longer, there is positive indication that the Correspondent Node has terminated the ILNP session (e.g., TCP RST if the only transport-layer session for this ILNP session is a TCP session), until some appropriate timeout (e.g., 2*MSL for TCP if the only transport-layer session for this ILNP session is a TCP session), or the ILNP session has been inactive for several minutes (e.g., no transport-layer session exists for this ILNP session) and the storage space associated with the aged entry needs to be reclaimed.
代わりに、コレスポンデントノードにキャッシュされたロケーター値は、TTLが期限切れになったときに「エージド」としてマークする必要がありますが、次のロケーター更新メッセージが受信されるまで保持されます。コレスポンデントノードがILNPセッション（たとえば、このILNPセッションの唯一のトランスポート層セッションがTCPセッションの場合はTCP RST）を終了したことを示す肯定的な兆候（適切なタイムアウト（たとえば、トランスポートのみの場合はTCPの2 MSL）このILNPセッションのレイヤーセッションはTCPセッションです）、またはILNPセッションが数分間非アクティブになっていて（たとえば、このILNPセッションにトランスポートレイヤーセッションが存在しない）、古くなったエントリに関連付けられたストレージスペースを再利用する必要があります。
Separately, received authenticated Locator Update messages cause the ILCC entries listed above to be updated.
これとは別に、認証済みのロケーター更新メッセージを受信すると、上記のILCCエントリが更新されます。
Similarly, if there is indication that an ILNP session with a Correspondent Node remains active and the DNS TTL associated with that Correspondent Node's active Identifier value(s) has expired, those remote Identifier value(s) ought to be marked as "expired", but retained since they are in active use.
同様に、コレスポンデントノードとのILNPセッションがアクティブなままであり、そのコレスポンデントノードのアクティブな識別子の値に関連付けられているDNS TTLが期限切れである場合、それらのリモート識別子の値は「期限切れ」としてマークされているはずです。ただし、アクティブに使用されているため保持されます。
Implementers should keep in mind that a node or site might have a large number of concurrent Locators, and it should ensure that a system fault does not arise if the system receives an authentic ICMP Locator Update containing a large number of Locator values.
実装者は、ノードまたはサイトに多数のロケーターが同時に存在する可能性があること、およびシステムが多数のロケーター値を含む本物のICMPロケーター更新を受信した場合にシステム障害が発生しないようにする必要があります。
For received packets containing an ILNP Nonce Option, lookups in the ILCC MUST use the <remote Identifier, Nonce> tuple as the lookup key.
ILNPノンスオプションを含む受信パケットの場合、ILCCでのルックアップでは、<リモートID、ノンス>タプルをルックアップキーとして使用する必要があります。
For all other ILNP packets, lookups in the ILNP Correspondent Cache MUST use the <remote Locator, remote Identifier> tuple, i.e., the remote I-LV, as the lookup key.
他のすべてのILNPパケットの場合、ILNPコレスポンデントキャッシュでのルックアップは、<リモートロケーター、リモートID>タプル、つまりリモートI-LVをルックアップキーとして使用する必要があります。
These two checks between them facilitate situations where, perhaps due to deployment of Local-scope Identifiers, more than one correspondent node is using the same Identifier value.
これらの間のこれら2つのチェックは、おそらくローカルスコープ識別子の展開が原因で、複数のコレスポンデントノードが同じ識別子値を使用している状況を容易にします。
(NOTE: Other mechanisms, such as IPv6 Neighbor Discovery, ensure that two different nodes are incapable of using a given I-LV at the same location, i.e., on the same link.)
（注：IPv6近隣探索などの他のメカニズムでは、2つの異なるノードが同じ場所、つまり同じリンク上で特定のI-LVを使用できないようにします。）
While Locators are omitted from the transport-layer checksum, an implementation SHOULD use Locator values to distinguish between correspondents coincidentally using the same Identifier value (e.g., due to deployment of Local-scope Identifier values) when demultiplexing to determine which application(s) should receive the user data delivered by the transport-layer protocol.
ロケーターはトランスポート層のチェックサムから省略されますが、実装は、分離するときにアプリケーションを決定するときに（たとえば、ローカルスコープの識別子の値の展開により）同じ識別子の値を同時に使用して、対応するものを区別するためにロケーターの値を使用する必要があります（複数の場合があります）。トランスポート層プロトコルによって配信されたユーザーデータを受信します。
In normal operation, an ILNP node uses the DNS for initial rendezvous in setting up ILNP sessions. The use of DNS for initial rendezvous with mobile nodes was earlier proposed by others [PHG02] and then separately reinvented by the current authors later on.
通常の操作では、ILNPノードは、ILNPセッションのセットアップで最初のランデブーにDNSを使用します。モバイルノードとの最初のランデブーにDNSを使用することは、以前に他の人によって提案されました[PHG02]。
To handle the move of a node or a change to the upstream connectivity of a multihomed node, we add a new ICMP control message [RFC6745] [RFC6743]. The ICMP Locator Update (LU) message is used by a node to inform its existing CNs that the set of valid Locators for the node has changed. This mechanism can be used to add newly valid Locators, to remove no longer valid Locators, or to do both at the same time. The LU mechanism is analogous to the Binding Update mechanism in Mobile IPv6, but in ILNP, such messages are used any time Locator value changes need to be notified to CNs, e.g., for multihomed hosts as well as for mobile hosts.
ノードの移動またはマルチホームノードのアップストリーム接続への変更を処理するために、新しいICMP制御メッセージ[RFC6745] [RFC6743]を追加します。 ICMPロケーター更新（LU）メッセージは、ノードの既存のCNに、ノードの有効なロケーターのセットが変更されたことを通知するために使用されます。このメカニズムを使用して、新しく有効なロケーターを追加したり、無効になったロケーターを削除したり、同時に両方を実行したりできます。 LUメカニズムはモバイルIPv6のバインディング更新メカニズムに似ていますが、ILNPでは、このようなメッセージは、ロケーター値の変更をCNに通知する必要がある場合に常に使用されます（マルチホームホストやモバイルホストなど）。
Further, if the node wishes to be able to receive new incoming ILNP sessions, the node normally uses Secure Dynamic DNS Update [RFC3007] to ensure that a correct set of Locator values are present in the appropriate DNS records (i.e., L32, L64) in the DNS for that node [RFC6742]. This enables any new correspondents to correctly initiate a new ILNP session with the node at its new location.
さらに、ノードが新しい着信ILNPセッションを受信できるようにしたい場合、ノードは通常、セキュアダイナミックDNSアップデート[RFC3007]を使用して、正しいロケーター値のセットが適切なDNSレコード（L32、L64）に存在することを確認します。そのノードのDNS [RFC6742]。これにより、新しい特派員は、新しい場所にあるノードとの新しいILNPセッションを正しく開始できます。
While the Locator Update control message could be an entirely new protocol running over UDP, for example, there is no obvious advantage to creating a new protocol rather than using a new ICMP message. So ILNP defines a new ICMP Locator Update message for both IPv4 and IPv6.
たとえば、ロケーター更新制御メッセージは、UDP上で実行されるまったく新しいプロトコルである可能性がありますが、新しいICMPメッセージを使用するのではなく、新しいプロトコルを作成することには明らかな利点はありません。したがって、ILNPは、IPv4とIPv6の両方に対して新しいICMPロケーター更新メッセージを定義します。
As a DNS performance optimisation, the LP DNS resource record MAY be used to avoid requiring each node on a subnetwork to update its DNS L64 record entries when that subnetwork's location (e.g., upstream connectivity) changes [RFC6742]. This can reduce the number of DNS updates required when a subnetwork moves from Order (number of nodes on subnetwork) to Order(1).
DNSパフォーマンスの最適化として、LP DNSリソースレコードを使用して、サブネットワークの場所（アップストリーム接続など）が変更されたときに、サブネットワーク上の各ノードがDNS L64レコードエントリを更新する必要がないようにすることができます[RFC6742]。これにより、サブネットワークがOrder（サブネットワーク上のノードの数）からOrder（1）に移動するときに必要なDNS更新の数を減らすことができます。
In this case, the nodes on the subnetwork each would have an LP record pointing to a common FQDN used to name that subnetwork. In turn, that subnetwork's domain name would have one or more L64 record(s) in the DNS. Since the contents of an LP record are stable, relatively long DNS TTL values can be associated with these records facilitating DNS caching. By contrast, the DNS TTL of an L32 or L64 record for a mobile or multihomed node should be small. Experimental work at the University of St Andrews indicates that the DNS continues to work well even with very low (e.g., zero) DNS TTL values [BA11].
この場合、サブネットワーク上のノードにはそれぞれ、そのサブネットワークの名前に使用される共通のFQDNを指すLPレコードがあります。次に、そのサブネットワークのドメイン名は、DNSに1つ以上のL64レコードを持っています。 LPレコードの内容は安定しているため、比較的長いDNS TTL値をこれらのレコードに関連付けて、DNSキャッシュを容易にすることができます。対照的に、モバイルまたはマルチホームノードのL32またはL64レコードのDNS TTLは小さいはずです。セントアンドリュース大学での実験的研究によれば、DNS TTL値が非常に低い（ゼロなど）場合でもDNSは引き続き適切に機能します[BA11]。
Correspondents of a node on a mobile subnetwork using this DNS performance optimisation would initially perform a normal FQDN lookup for a node. If that lookup returned another FQDN in an LP record as additional data, then the correspondent would perform a lookup on that FQDN and expect an L32 or L64 record returned as additional data, in order to learn the Locator value to use to reach that target node. (Of course, a lookup that did not return any ILNP-related DNS records would result in an ordinary IPv4 session or ordinary IPv6 session being initiated, instead.)
このDNSパフォーマンス最適化を使用するモバイルサブネットワーク上のノードの通信相手は、最初にノードの通常のFQDNルックアップを実行します。そのルックアップがLPレコード内の別のFQDNを追加データとして返した場合、通信相手はそのFQDNでルックアップを実行し、L32またはL64レコードが追加データとして返されることを期待して、そのターゲットノードに到達するために使用するロケーター値を学習します。 。 （もちろん、ILNP関連のDNSレコードを返さなかったルックアップの結果、通常のIPv4セッションまたは通常のIPv6セッションが開始されます。）
For ILNPv4 and ILNPv6, the Locator value includes the subnetting information, as that also is topological information. As well as being architecturally correct, the placement of subnetting as part of the Locator is also convenient from an engineering point of view in both IPv4 and IPv6.
ILNPv4およびILNPv6の場合、トポロジー情報でもあるため、Locator値にはサブネット情報が含まれます。構造的に正しいだけでなく、ロケーターの一部としてのサブネットの配置は、IPv4とIPv6の両方のエンジニアリングの観点からも便利です。
We consider that a Locator value, L consists of two parts:
Locator値Lは次の2つの部分で構成されると考えます。
- L_pp: the Locator prefix part, which occupies the most significant bits in the address (for both ILNPv4 and ILNPv6).
- L_pp：ロケータープレフィックス部分。アドレスの最上位ビットを占めます（ILNPv4とILNPv6の両方）。
- L_ss: Locator subnetwork selector, which occupies bits just after the L_pp.
- L_ss：ロケーターサブネットワークセレクター。L_ppの直後のビットを占有します。
For each of ILNPv4 and ILNPv6, L_pp gets its value from the provider-assigned routing prefix for IPv4 and IPv6, respectively. For L_ss, in each case of ILNPv4 and ILNPv6, the L_ss bits are located in the part of the address space which you might expect them to be located if IPv4 or IPv6 addresses were being used, respectively.
ILNPv4とILNPv6のそれぞれについて、L_ppは、プロバイダーが割り当てたIPv4とIPv6のルーティングプレフィックスからそれぞれ値を取得します。 L_ssの場合、ILNPv4およびILNPv6のいずれの場合も、L_ssビットは、IPv4またはIPv6アドレスがそれぞれ使用されている場合に配置されると予想されるアドレス空間の一部に配置されます。
For ILNPv6, recall that the Locator value is encoded to be syntactically similar to an IPv6 address prefix, as shown in Figure 7.1.
ILNPv6の場合、図7.1に示すように、Locator値がIPv6アドレスプレフィックスと構文的に類似するようにエンコードされていることを思い出してください。
/* IPv6 */
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
|001|global routing prefix| subnet ID | Interface Identifier |
+---+---------------------+-----------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
| Locator (L64) | Node Identifier (NID) |
+---+---------------------+-----------+-------------------------+
+<-------- L_pp --------->+<- L_ss -->+
L_pp = Locator prefix part (assigned IPv6 prefix) L_ss = Locator subnet selector (locally managed subnet ID)
L_pp =ロケータープレフィックスパーツ（割り当てられたIPv6プレフィックス）L_ss =ロケーターサブネットセレクター（ローカルで管理されたサブネットID）
Figure 7.1: IPv6 Address Format [RFC3587] as Used in ILNPv6, Showing How Subnets Can Be Identified
図7.1：ILNPv6で使用されるIPv6アドレス形式[RFC3587]、サブネットの識別方法を示す
Note that the subnet ID forms part of the Locator value. Note also that [RFC6177] allows the global routing prefix to be more than 45 bits, and for the subnet ID to be smaller, but still preserving the 64-bit size of the Locator.
サブネットIDはロケーター値の一部であることに注意してください。また、[RFC6177]では、グローバルルーティングプレフィックスを45ビットを超えて、サブネットIDを小さくすることができますが、ロケーターの64ビットサイズは維持されます。
For ILNPv4, the L_pp value is an IPv4 routing prefix as used today, which is typically less than 32 bits. However, the ILNPv4 Locator value is carried in the 32-bit IP Address space, so the bits not used for the routing prefix could be used for L_ss, e.g., for a /24 IPv4 prefix, the situation would be as shown in Figure 7.2.
ILNPv4の場合、L_pp値は現在使用されているIPv4ルーティングプレフィックスであり、通常は32ビット未満です。ただし、ILNPv4ロケーター値は32ビットのIPアドレス空間で運ばれるため、ルーティングプレフィックスに使用されていないビットをL_ssに使用できます（例：/ 24 IPv4プレフィックス）、状況は図7.2のようになります。 。
24 bits 8 bits
+------------------------+----------+
| Locator (L32) |
+------------------------+----------+
+<------- L_pp --------->+<- L_ss ->+
L_pp = Locator prefix part (assigned IPv4 prefix) L_ss = Locator subnet selector (locally managed subnet ID)
L_pp =ロケータープレフィックスパーツ（割り当てられたIPv4プレフィックス）L_ss =ロケーターサブネットセレクター（ローカルで管理されたサブネットID）
Figure 7.2: IPv4 Address Format for /24 IPv4 Prefix, as Used in ILNPv4, Showing How Subnets Can Be Identified
図7.2：ILNPv4で使用される/ 24 IPv4プレフィックスのIPv4アドレス形式、サブネットの識別方法を示す
Note that the L_ss occupies bits that in an IPv4 address would normally be the host part of the address, which the site network could use for subnetting in any case.
L_ssは、IPv4アドレスでは通常、アドレスのホスト部分であるビットを占有します。サイトネットワークは、どのような場合でもサブネット化に使用できます。
There is a special case of /127 prefixes used in router-router, point-to-point links for IPv6 [RFC6164]. ILNPv6 does not preclude such use.
IPv6のルータールーターポイントツーポイントリンクで使用される/ 127プレフィックスの特殊なケースがあります[RFC6164]。 ILNPv6はそのような使用を排除しません。
ILNP makes use of DNS for name resolution, as does IP. Unlike IP, ILNP also uses DNS to support features such as mobility and multihoming. While such usage is appropriate use of the DNS, it is important to discuss operational and engineering issues that may impact DNS usage.
ILNPは、IPと同様に、名前解決にDNSを利用します。 IPとは異なり、ILNPはDNSを使用して、モビリティやマルチホーミングなどの機能をサポートします。このような使用法はDNSの適切な使用法ですが、DNSの使用法に影響を与える可能性がある運用上およびエンジニアリング上の問題について話し合うことが重要です。
When a host that expects incoming connections changes one or more of its Locator values, the host normally uses the IETF Secure Dynamic DNS Update protocol [RFC3007] to update the set of currently valid Locator values associated with its FQDN. This ensures that the authoritative DNS server for its FQDN will be able to generate an accurate set of Locator values if the DNS server receives DNS name resolution request for its FQDN.
着信接続を予期するホストが1つ以上のロケーター値を変更する場合、ホストは通常、IETFセキュアダイナミックDNSアップデートプロトコル[RFC3007]を使用して、そのFQDNに関連付けられている現在有効なロケーター値のセットを更新します。これにより、DNSサーバーがFQDNのDNS名前解決要求を受信した場合、FQDNの信頼できるDNSサーバーがロケーター値の正確なセットを生成できるようになります。
Liu and Albitz [LA06] report that Secure Dynamic DNS Update has been supported on the client-side for several years now in widely deployed operating systems (e.g., MS Windows, Apple Mac OS X, UNIX, and Linux) and also in DNS server software (e.g., BIND). Publicly available product data sheets indicate that some other DNS server software packages, such as that from Nominum, also support this capability.
LiuとAlbitz [LA06]は、広く導入されているオペレーティングシステム（MS Windows、Apple Mac OS X、UNIX、Linuxなど）およびDNSサーバーでも、数年前からクライアント側でSecure Dynamic DNS Updateがサポートされていると報告していますソフトウェア（BINDなど）。一般に入手可能な製品データシートは、Nominumのパッケージなど、他の一部のDNSサーバーソフトウェアパッケージもこの機能をサポートしていることを示しています。
For example, Microsoft Windows XP (and later versions), the freely distributable BIND DNS software package (used in Apple Mac OS X and in most UNIX systems), and the commercial Nominum DNS server all implement support for Secure Dynamic DNS Update and are known to interoperate [LA06]. There are credible reports that when a site deploys Microsoft's Active Directory, the site (silently) automatically deploys Secure Dynamic DNS Update [LA06]. So, many sites have already deployed Secure Dynamic DNS Update even though they are not actively using it (and might not be aware they have already deployed that protocol) [LA06].
たとえば、Microsoft Windows XP（およびそれ以降のバージョン）、無料で配布可能なBIND DNSソフトウェアパッケージ（Apple Mac OS XおよびほとんどのUNIXシステムで使用）、および商用のNominum DNSサーバーはすべて、Secure Dynamic DNS Updateのサポートを実装しており、既知です相互運用する[LA06]。サイトがMicrosoftのActive Directoryを展開すると、サイトが（サイレントで）セキュアな動的DNS更新を自動的に展開するという信頼できるレポートがあります[LA06]。そのため、多くのサイトはセキュアな動的DNS更新を積極的に使用していなくても、既に展開しています（そのプロトコルが既に展開されていることに気付いていない可能性があります）[LA06]。
So DNS update via Secure Dynamic DNS Update is not only standards-based, but also readily available in widely deployed systems today.
そのため、Secure Dynamic DNS Updateを介したDNSアップデートは、標準ベースであるだけでなく、現在広く展開されているシステムですぐに利用できます。
As part of this proposal, additional DNS resource records have been proposed in a separate document [RFC6742]. These new records are summarised in Table 6.1.
この提案の一部として、追加のDNSリソースレコードが別のドキュメント[RFC6742]で提案されています。これらの新しいレコードを表6.1にまとめます。
new DNS RR type | Purpose
-----------------+------------------------------------------------
NID | store the value of a Node Identifier
L32 | store the value of a 32-bit Locator for ILNPv4
L64 | store the value of a 64-bit Locator for ILNPv6
LP | points to a (several) L32 and/or L64 record(s)
-----------------+------------------------------------------------
Table 6.1. Summary of new DNS RR Types for ILNP
表6.1 ILNPの新しいDNS RRタイプの概要
With this proposal, mobile or multihomed nodes and sites are expected to use the existing "Secure Dynamic DNS Update" protocol to keep their Node Identifier (NID) and Locator (L32 and/or L43) records correct in their authoritative DNS server(s) [RFC3007] [RFC6742].
この提案では、モバイルまたはマルチホームのノードとサイトは、既存の「Secure Dynamic DNS Update」プロトコルを使用して、信頼できるDNSサーバーでノード識別子（NID）とロケーター（L32またはL43）のレコードを正しく保つことが期待されています。 [RFC3007] [RFC6742]。
Reverse DNS lookups, to find a node's FQDN from the combination of a Locator and related Identifier value, can be performed as at present.
ロケーターと関連する識別子の値の組み合わせからノードのFQDNを見つけるためのDNS逆引きは、現在のように実行できます。
Existing DNS specifications require that DNS clients and DNS resolvers honour the TTL values provided by the DNS servers. In the context of this proposal, short DNS TTL values are assigned to particular DNS records to ensure that the ubiquitous DNS caching resolvers do not cache volatile values (e.g., Locator records of a mobile node) and consequently return stale information to new requestors.
既存のDNS仕様では、DNSクライアントとDNSリゾルバーは、DNSサーバーによって提供されるTTL値を尊重する必要があります。この提案のコンテキストでは、特定のDNSレコードに短いDNS TTL値が割り当てられ、ユビキタスDNSキャッシングリゾルバーが揮発性の値（モバイルノードのロケーターレコードなど）をキャッシュせず、結果として古い情報が新しいリクエスターに返されないようにします。
The TTL values for L32 and L64 records may have to be relatively low (perhaps a few seconds) in order to support mobility and multihoming. Low TTL values may be of concern to administrators who might think that this would reduce efficacy of DNS caching increase DNS load significantly.
モビリティとマルチホーミングをサポートするために、L32およびL64レコードのTTL値を比較的低く（おそらく数秒）する必要がある場合があります。 TTL値が低いと、DNSキャッシュの有効性が低下し、DNSの負荷が大幅に増加すると考えている管理者にとって問題になる場合があります。
Previous research by others indicates that DNS caching is largely ineffective, with the exception of NS records and the addresses of DNS servers referred to by NS records [SBK02]. This means DNS caching performance and DNS load will not be adversely affected by assigning very short TTL values (down to zero) to the Locator records of typical nodes for an edge site [BA11]. It also means that it is preferable to deploy the DNS server function on nodes that have longer DNS TTL values, rather than on nodes that have shorter DNS TTL values.
他の人による以前の研究は、NSレコードとNSレコードによって参照されるDNSサーバーのアドレスを除いて、DNSキャッシングはほとんど効果がないことを示しています[SBK02]。つまり、エッジサイトの一般的なノードのロケーターレコードに非常に短いTTL値（ゼロまで）を割り当てることで、DNSキャッシュのパフォーマンスとDNSの負荷に悪影響が及ぶことはありません[BA11]。また、DNS TTL値が短いノードではなく、DNS TTL値が長いノードにDNSサーバー機能を展開することをお勧めします。
LP records normally are stable and will have relatively long TTL values, even if the L32 or L64 records they point to have values that have relatively low TTL values.
LPレコードは通常、安定しており、比較的低いTTL値を持つ値を持っていることをL32またはL64レコードがポイントしている場合でも、比較的長いTTL値を持ちます。
Identifier values might be very long-lived (e.g., days) when they have been generated from an IEEE MAC address on the system. Identifier values might have a shorter lifetime (e.g., hours or minutes) if they have been cryptographically generated [RFC3972], have been created by the IPv6 Privacy Extensions [RFC4941], or otherwise have the EUI-64 scope bit set to "local-scope". Note that when ILNP is used, the cryptographic generation method described in RFC 3972 is used only for the Identifier, omitting the Locator, thereby preserving roaming capability. Note that a given ILNP session normally will use a single Identifier value for the lifetime of that ILNP session.
識別子の値は、システムのIEEE MACアドレスから生成された場合、非常に長期間（たとえば、数日）になることがあります。識別子の値は、暗号で生成された場合[RFC3972]、IPv6プライバシー拡張[RFC4941]によって作成された場合、またはEUI-64スコープビットが "local-範囲"。 ILNPを使用する場合、RFC 3972で説明されている暗号化生成方法は識別子にのみ使用され、ロケーターが省略されるため、ローミング機能が維持されます。特定のILNPセッションは、通常、そのILNPセッションの存続期間中に単一のID値を使用することに注意してください。
During a long transition period, a node that is ILNP-capable SHOULD have not only NID and L32/L64 (or NID and LP) records present in its authoritative DNS server but also SHOULD have A/AAAA records in the DNS for the benefit of non-upgraded nodes. Then, when any CN performs an FQDN lookup for that node, it will receive the A/AAAA with the appropriate NID, L32/L64 records, and/or LP records as "additional data".
長い移行期間中、ILNP対応のノードは、信頼できるDNSサーバーにNIDとL32 / L64（またはNIDとLP）のレコードが存在するだけでなく、DNSにA / AAAAレコードが存在する必要がある（SHOULD）アップグレードされていないノード。次に、任意のCNがそのノードに対してFQDNルックアップを実行すると、適切なNID、L32 / L64レコード、LPレコード、またはそのいずれかが「追加データ」としてA / AAAAを受け取ります。
Existing DNS specifications require that a DNS resolver or DNS client ignore unrecognised DNS record types. So, gratuitously appending NID and Locator (i.e., L32, L64, or LP) records as "additional data" in DNS responses to A/AAAA queries ought not to create any operational issues. So, IP only nodes would use the A/AAAA RRs, but ILNP-capable nodes would be able to use the NID, L32/L64 and/or LP records are required.
既存のDNS仕様では、DNSリゾルバーまたはDNSクライアントが認識されないDNSレコードタイプを無視する必要があります。したがって、A / AAAAクエリへのDNS応答で「追加データ」としてNIDおよびロケーター（つまり、L32、L64、またはLP）レコードを不必要に追加しても、運用上の問題は発生しません。したがって、IPのみのノードはA / AAAA RRを使用しますが、ILNP対応のノードはNIDを使用できます。L32/ L64および/またはLPレコードが必要です。
There is nothing to prevent this capability being implemented strictly inside a DNS server, whereby the DNS server synthesises a set of A/AAAA records to advertise from the NID and Locator (i.e., L32, L64, or LP) values that the node has kept updated in that DNS server. Indeed, such a capability may be desirable, reducing the amount of manual configuration required for a site, and reducing the potential for errors as the A/AAAA records would be automatically generated.
この機能がDNSサーバー内に厳密に実装されていることを妨げるものは何もありません。これにより、DNSサーバーは、ノードが保持したNIDとロケーター（つまり、L32、L64、またはLP）の値からアドバタイズするA / AAAAレコードのセットを合成します。そのDNSサーバーで更新されます。実際、このような機能は望ましい場合があり、サイトに必要な手動構成の量を減らし、A / AAAAレコードが自動的に生成されるため、エラーの可能性を減らします。
The primary conceptual difference from ordinary IP security (IPsec) is that ILNP IP Security omits all use of, and all reference to, Locator values. This leads to several small, but important, changes to IPsec when it is used with ILNP sessions.
通常のIPセキュリティ（IPsec）との概念上の主な違いは、ILNP IPセキュリティはロケーター値のすべての使用とすべての参照を省略していることです。このため、ILNPセッションでIPsecを使用すると、IPsecにいくつかの小さな、しかし重要な変更が加えられます。
IPsec Security Associations for ILNP only include the Identifier values for the endpoints, and omit the Locator values. As an implementation detail, ILNP implementations MUST be able to distinguish between different Security Associations with ILNP correspondents (at different locations, with different ILNP Nonce values in use) that happen to use the same Identifier values (e.g., due to an inadvertent Identifier collision when using identifier values generated by using the IPv6 Privacy Addressing extension). One possible way to distinguish between such different ILNP sessions is to maintain a mapping between the IPsec Security Association Database (SAD) entry and the corresponding ILCC entry.
ILNPのIPsecセキュリティアソシエーションには、エンドポイントの識別子の値のみが含まれ、ロケーターの値は省略されます。実装の詳細として、ILNP実装は、（たとえば、不注意な識別子の衝突が原因で偶発的な識別子の衝突が原因で）偶然に同じ識別子の値を使用するILNP対応者との異なるセキュリティアソシエーション（異なる場所で、使用中の異なるILNPナンス値）を区別できなければなりませんIPv6プライバシーアドレッシング拡張機能を使用して生成された識別子の値を使用）。そのような異なるILNPセッションを区別する1つの可能な方法は、IPsecセキュリティアソシエーションデータベース（SAD）エントリと対応するILCCエントリの間のマッピングを維持することです。
Consistent with this enhancement to the definition of an IPsec Security Association, when processing received IPsec packets associated with an ILNP session, ILNP implementations ignore the Locator bits of the received packet and only consider the Identifier bits. This means, for example, that if an ILNP correspondent node moves to a different subnetwork, and thus is using a different Source Locator in the header of its ILNP IPsec packets, the ILNP session will continue to work and will continue to be secure.
IPsecセキュリティアソシエーションの定義に対するこの拡張と一致して、ILNPセッションに関連付けられた受信IPsecパケットを処理するとき、ILNP実装は受信パケットのロケータービットを無視し、識別子ビットのみを考慮します。これは、たとえば、ILNP対応ノードが別のサブネットワークに移動し、ILNP IPsecパケットのヘッダーで別のソースロケーターを使用している場合、ILNPセッションは引き続き機能し、安全性が維持されることを意味します。
Since implementations of ILNP are also required to support IP, implementers need to ensure that ILNP IPsec Security Associations can be distinguished from ordinary IPsec Security Associations. The details of this are left to the implementer. As an example, one possible implementation strategy would be to retain a single IPsec Security Association Database (SAD), but add an internal flag bit to each entry of that IPsec SAD to indicate whether ILNP is in use for that particular IPsec Security Association.
ILNPの実装もIPをサポートする必要があるため、実装者はILNP IPsecセキュリティアソシエーションを通常のIPsecセキュリティアソシエーションと区別できるようにする必要があります。詳細は実装者に任されています。例として、1つの可能な実装戦略は、単一のIPsecセキュリティアソシエーションデータベース（SAD）を保持することですが、そのIPsec SADの各エントリに内部フラグビットを追加して、ILNPがその特定のIPsecセキュリティアソシエーションで使用されているかどうかを示します。
Similarly, for an ILNP session using IPsec, the IPsec Authentication Header (AH) only includes the Identifier values for the endpoints in its authentication calculations, and it omits the Source Locator and Destination Locator fields from its authentication calculations. This enables IPsec AH to work well even when used with ILNP localised numbering [RFC6748] or other situations where a Locator value might change while the packet travels from origin to destination.
同様に、IPsecを使用するILNPセッションの場合、IPsec認証ヘッダー（AH）の認証計算にはエンドポイントのID値のみが含まれ、認証計算から送信元ロケーターフィールドと宛先ロケーターフィールドが省略されます。これにより、IPsec AHは、ILNPローカライズされた番号付け[RFC6748]や、パケットが起点から宛先に移動する間にロケーター値が変更される可能性がある他の状況で使用された場合でもうまく機能します。
In order to distinguish at the network-layer between multiple ILNP nodes that happen to be using the same Node Identifier values (e.g., because the identifier values were generated using the IPv6 Privacy Addressing method), key management packets being used to set up an ILNP IPsec session MUST include the ILNP Nonce Option.
同じノードID値を使用している複数のILNPノードをネットワーク層で区別するため（たとえば、IPv6プライバシーアドレッシング方式を使用してID値が生成されたため）、ILNPのセットアップに使用されるキー管理パケットIPsecセッションにはILNPナンスオプションを含める必要があります。
Similarly, key management protocols used with IPsec are enhanced to deprecate use of IP Addresses as identifiers and to substitute the use of the new Node Identifier values for that purpose. This results in an ILNP IPsec Security Association that is independent of the Locator values that might be used.
同様に、IPsecで使用されるキー管理プロトコルは、IPアドレスの識別子としての使用を廃止し、その目的のために新しいノード識別子の値の使用を置き換えるように拡張されています。これにより、使用される可能性のあるロケーター値から独立したILNP IPsecセキュリティアソシエーションになります。
For ILNPv6 implementations, the ILNP Node Identifier (64-bits) is smaller than the IPv6 Address (128-bits). So support for ILNPv6 IPsec is accomplished by zeroing the upper-64 bits of the IPv6 Address fields in the application-layer key management protocol, while retaining the Node Identifier value in the lower-64 bits of the application-layer key management protocol.
ILNPv6実装の場合、ILNPノード識別子（64ビット）はIPv6アドレス（128ビット）よりも小さくなります。そのため、ILNPv6 IPsecのサポートは、アプリケーション層のキー管理プロトコルの下位64ビットにノード識別子の値を保持しながら、アプリケーション層のキー管理プロトコルのIPv6アドレスフィールドの上位64ビットをゼロにすることによって実現されます。
For ILNPv4 implementations, enhancements to the key management protocol likely will be needed, because existing key management protocols rely on 32-bit IPv4 addresses, while ILNP Node Identifiers are 64-bits. Such enhancements are beyond the scope of this specification.
ILNPv4の実装では、ILNPノード識別子が64ビットであるのに対し、既存のキー管理プロトコルは32ビットのIPv4アドレスに依存しているため、キー管理プロトコルの拡張が必要になる可能性があります。このような拡張は、この仕様の範囲を超えています。
Experience with IPv6 deployment over the past many years has shown that it is important for any new network protocol to provide backwards compatibility with the deployed IP base and should be incrementally deployable, ideally requiring modification of only those nodes that wish to use ILNP and not requiring the modification of nodes that do not intend to use ILNP. The two instances of ILNP, ILNPv4 and ILNPv6, are intended to be, respectively, backwards compatible with, and incrementally deployable on, the existing IPv4 and IPv6 installed bases. Indeed, ILNPv4 and ILNPv6 can each be seen, from an engineering viewpoint, as supersets of the IPv4 and IPv6, respectively.
過去何年にもわたるIPv6導入の経験から、新しいネットワークプロトコルは導入されたIPベースとの下位互換性を提供することが重要であり、段階的に導入可能であることが理想的です。 ILNPを使用する予定のないノードの変更。 ILNPの2つのインスタンスであるILNPv4とILNPv6は、それぞれ、既存のIPv4およびIPv6インストールベースと下位互換性があり、段階的に展開できるようになっています。実際、ILNPv4とILNPv6はそれぞれ、エンジニアリングの観点から、それぞれIPv4とIPv6のスーパーセットと見なすことができます。
However, in some cases, ILNP introduces functions that supersede equivalent functions available in IP. For example, ILNP has a mobility model, and so it does not need to use the models for Mobile IPv4 or Mobile IPv6.
ただし、場合によっては、ILNPはIPで使用可能な同等の機能に取って代わる機能を導入します。たとえば、ILNPにはモビリティモデルがあるため、モバイルIPv4またはモバイルIPv6のモデルを使用する必要はありません。
As ILNP changes, the use of end-to-end namespaces, for the most part, it is only end-systems that need to be modified. However, in order to leverage existing engineering (e.g., existing protocols), in some cases, there is a compromise, and these are highlighted in this section.
ILNPの変更、エンドツーエンドのネームスペースの使用、ほとんどの場合、変更が必要なのはエンドシステムのみです。ただし、既存のエンジニアリング（既存のプロトコルなど）を活用するために、場合によっては妥協点があり、これらはこのセクションで強調表示されています。
In the engineering design of ILNPv6 and ILNPv4, we have used the following priorities. In some ways, this choice is arbitrary, and it may be equally valid to "invert" these priorities for a different architectural and engineering design.
ILNPv6およびILNPv4のエンジニアリング設計では、次の優先順位を使用しています。いくつかの点で、この選択は任意であり、異なる建築およびエンジニアリング設計に対してこれらの優先順位を「逆転」することも同様に有効です。
1. Infrastructure
1. インフラ
As much of the deployed IP network infrastructure should be used without change. That is, routers and switches should require minimal or zero modifications in order to run ILNP. As much as possible of the existing installed base of core protocols should be reused.
導入されたIPネットワークインフラストラクチャのほとんどを変更せずに使用する必要があります。つまり、ルーターとスイッチは、ILNPを実行するために最小限またはゼロの変更を必要とします。コアプロトコルの既存のインストールベースを可能な限り再利用する必要があります。
2. Core protocols
2. コアプロトコル
As much of the deployed network control protocols, such as routing, should be used without change. That is, existing routing protocols and switch configuration should require minimal or zero modifications in order to run ILNP.
ルーティングなど、展開されているネットワーク制御プロトコルのほとんどは、変更せずに使用する必要があります。つまり、既存のルーティングプロトコルとスイッチ構成では、ILNPを実行するために変更を最小限またはゼロにする必要があります。
3. Scope of end-system changes
3. エンドシステム変更の範囲
Any nodes that do not need to run ILNP should not need to be upgraded. It should be possible to have a site network that has a mix of IP-only and ILNP-capable nodes without any changes required to the IP-only nodes.
ILNPを実行する必要のないノードは、アップグレードする必要はありません。 IPのみのノードに変更を加えることなく、IPのみのノードとILNP対応のノードが混在するサイトネットワークを構築できるはずです。
4. Applications
4. 用途
There should be minimal impact on applications, even though ILNP requires end-to-end protocols to be upgraded. Indeed, for those applications that are "well behaved" (e.g., do not use IP Address values directly for application state or application configuration), there should be little or no effort required in enabling them to operate over ILNP.
ILNPではエンドツーエンドのプロトコルをアップグレードする必要がありますが、アプリケーションへの影響は最小限である必要があります。実際、「適切に動作する」（たとえば、アプリケーションの状態またはアプリケーション構成にIPアドレス値を直接使用しない）アプリケーションの場合、それらをILNPで動作させるために必要な労力はほとんどまたはまったくないはずです。
Each of these items is discussed in its own section below.
これらの各項目については、以下の独自のセクションで説明します。
ILNP is designed to be deployed on existing infrastructure. No new infrastructure is required to run ILNP as it will be implemented as a software upgrade impacting only end-to-end protocols. Existing routing protocols can be reused: no new routing protocols are required. This means that network operators and service providers do not need to learn about, test, and deploy new protocols, or change the structure of their network in order for ILNP to be deployed. Exceptionally, edge routers supporting ILNPv4 hosts will need to support an enhanced version of ARP.
ILNPは、既存のインフラストラクチャに展開するように設計されています。 ILNPはエンドツーエンドプロトコルにのみ影響するソフトウェアアップグレードとして実装されるため、ILNPを実行するために新しいインフラストラクチャは必要ありません。既存のルーティングプロトコルを再利用できます。新しいルーティングプロトコルは必要ありません。これは、ILNPを展開するために、ネットワークオペレーターとサービスプロバイダーが新しいプロトコルについて学習、テスト、および展開したり、ネットワークの構造を変更したりする必要がないことを意味します。例外的に、ILNPv4ホストをサポートするエッジルーターは、ARPの拡張バージョンをサポートする必要があります。
Existing routing and other control protocols should not need to change in devices such as switches and routers. We believe this to be true for ILNPv6. However, for ILNPv4, we believe that ARP will need to be enhanced in edge routers (or Layer 3 switches) that support ILNPv4 hosts. Backbone and transit routers still ought not require changes for either ILNPv4 or ILNPv6.
既存のルーティングやその他の制御プロトコルは、スイッチやルーターなどのデバイスで変更する必要はありません。これはILNPv6にも当てはまると考えています。ただし、ILNPv4の場合、ILNPv4ホストをサポートするエッジルーター（またはレイヤー3スイッチ）でARPを強化する必要があると考えています。バックボーンとトランジットルーターは、ILNPv4またはILNPv6のいずれかを変更する必要はありません。
For both ILNPv4 and ILNPv6, the basic packet format for packets reuses that format that is seen by routers for IPv4 and IPv6, respectively. Specifically, as the ILNP Locator value is always a routing prefix (either IPv4 or IPv6), routing protocols should work unchanged.
ILNPv4とILNPv6の両方で、パケットの基本的なパケット形式は、IPv4とIPv6のルーターでそれぞれ見られる形式を再利用します。具体的には、ILNPロケーターの値は常にルーティングプレフィックス（IPv4またはIPv6のいずれか）であるため、ルーティングプロトコルは変更されずに機能します。
Both ILNPv4 and ILNPv6 introduce new header options (e.g., Nonce Option messages) and ICMP messages (e.g., Locator Update messages) that are used to enable end-to-end signalling. For packet forwarding, depending on the forwarding policies used by some providers or site border routers, there may need to be modifications to those policies to allow the new header options and new ICMP messages to be forwarded. However, as the header options and new ICMP messages are end-to-end, such modifications are likely to be in configuration files (or firewall policy on edge routers), as core routers do NOT need to parse and act upon the information contained in the header options or ICMP messages.
ILNPv4とILNPv6の両方で、エンドツーエンドのシグナリングを有効にするために使用される新しいヘッダーオプション（Nonce Optionメッセージなど）とICMPメッセージ（Locator Updateメッセージなど）が導入されています。パケット転送の場合、一部のプロバイダーまたはサイト境界ルーターで使用される転送ポリシーによっては、これらのポリシーを変更して、新しいヘッダーオプションと新しいICMPメッセージを転送できるようにする必要があります。ただし、ヘッダーオプションと新しいICMPメッセージはエンドツーエンドであるため、コアルーターはに含まれる情報を解析して操作する必要がないため、このような変更は構成ファイル（またはエッジルーターのファイアウォールポリシー）に含まれる可能性があります。ヘッダーオプションまたはICMPメッセージ。
Only end-systems that need to use ILNP need to be updated in order for ILNP to be used at a site.
ILNPをサイトで使用するには、ILNPを使用する必要があるエンドシステムのみを更新する必要があります。
There are three exceptions to this statement as follows:
このステートメントには、次の3つの例外があります。
a) ILNPv4 ARP: as the Identifier value for IPv4 cannot fit into the normal 20-byte IPv4 packet header (a header extension is used), ARP must be modified. This only impacts end-systems that use ILNPv4 and those switches or site border routers that are the first hop from an ILNPv4 node. For ILNPv6, as the I and L values fit into the existing basic IPv6 packet, IPv6 Neighbour Discovery can operate without modification.
a) ILNPv4 ARP：IPv4の識別子の値は通常の20バイトのIPv4パケットヘッダーに適合しないため（ヘッダー拡張が使用されます）、ARPを変更する必要があります。これは、ILNPv4を使用するエンドシステムと、ILNPv4ノードからの最初のホップであるスイッチまたはサイト境界ルーターにのみ影響します。 ILNPv6の場合、IおよびLの値が既存の基本的なIPv6パケットに適合するため、IPv6近隣探索は変更なしで動作できます。
b) Use of IP NAT: Where IP NAT or NAPT is in use for a site, existing NAT/NAPT device will rewrite address fields in ILNPv4 packets or ILNPv6 packets. To avoid this, the NAT should either (i) be configured to allow the pass-through of packets originating from ILNP-capable nodes (e.g., by filtering on source address fields in the IP header); or (ii) should be enhanced to recognise ILNPv4 or ILNPv6 packets (e.g., by looking for the ILNP Nonce Option).
b) IP NATの使用：IP NATまたはNAPTがサイトで使用されている場合、既存のNAT / NAPTデバイスはILNPv4パケットまたはILNPv6パケットのアドレスフィールドを書き換えます。これを回避するには、NATを（i）ILNP対応ノードから発信されたパケットのパススルーを許可するように構成する必要があります（たとえば、IPヘッダーのソースアドレスフィールドでフィルタリングすることにより）。または（ii）ILNPv4またはILNPv6パケットを認識するように拡張する必要があります（たとえば、ILNPナンスオプションを探すことにより）。
c) Site Border Routers (SBRs) in ILNP Advanced Deployment scenarios: There are options to use an ILNP-capable Site Border Router (SBR) as described in another document [RFC6748]. In such scenarios, the SBR(s) need to be ILNP-capable.
c) ILNP Advanced Deploymentシナリオのサイトボーダールーター（SBR）：別のドキュメント[RFC6748]で説明されているように、ILNP対応のサイトボーダールーター（SBR）を使用するオプションがあります。このようなシナリオでは、SBRはILNP対応である必要があります。
Other than these exceptions, it is entirely possible to have a site that uses a mix of IP and ILNP nodes and requires no changes to nodes other than the nodes that wish to use ILNP. For example, if a user on a site wishes to have his laptop use ILNPv6, only that laptop would need to have an upgraded stack: no other devices (end-systems, Layer 2 switches or routers) at that site would need to be upgraded.
これらの例外を除いて、IPノードとILNPノードを組み合わせて使用し、ILNPを使用するノード以外のノードを変更する必要がないサイトを作成することは完全に可能です。たとえば、サイトのユーザーがラップトップでILNPv6を使用したい場合、そのラップトップだけがアップグレードされたスタックを持つ必要があります。そのサイトの他のデバイス（エンドシステム、レイヤー2スイッチまたはルーター）はアップグレードする必要がありません。 。
As noted, in the Architecture Description [RFC6740], those applications that do not use IP Address values in application state or configuration data are considered to be "well behaved". Applications that work today through a NAT or Network Address Port Translation (NAPT) device without application-specific support are also considered "well behaved". Such applications might use DNS FQDNs or application-specific name spaces. (Note Well: application-specific name spaces should not be derived from IP Address values.)
前述のように、アーキテクチャの説明[RFC6740]では、アプリケーションの状態または構成データでIPアドレス値を使用しないアプリケーションは、「正常に動作」していると見なされます。アプリケーション固有のサポートなしに、NATまたはネットワークアドレスポート変換（NAPT）デバイスを介して今日機能するアプリケーションも、「正常に動作」していると見なされます。このようなアプリケーションは、DNS FQDNまたはアプリケーション固有の名前空間を使用する場合があります。 （よく注意してください：アプリケーション固有の名前空間は、IPアドレス値から派生してはいけません。）
For well-behaved applications, replacing IP with ILNP should have no impact. That is, well-behaved applications should work unmodified over ILNP.
正常に動作するアプリケーションの場合、IPをILNPに置き換えても影響はありません。つまり、正常に動作するアプリケーションは、ILNPを介して変更せずに動作する必要があります。
Those applications that directly use IP Address values in application state or configuration will need to be modified for operation over ILNP. Examples of such applications include the following:
アプリケーションの状態または構成でIPアドレス値を直接使用するアプリケーションは、ILNPを介して動作するように変更する必要があります。このようなアプリケーションの例には次のものがあります。
- FTP: which uses IP Address values in the application-layer protocol. In practice, use of Secure Copy (SCP) is growing, while use of FTP is either flat or declining, in part due to the improved security provided by SCP.
- FTP：アプリケーション層プロトコルでIPアドレス値を使用します。実際には、セキュアコピー（SCP）の使用は増加していますが、FTPの使用は、一部にはSCPによって提供されるセキュリティの向上により、横ばいまたは減少しています。
- SNMP: which uses IP Address values in MIB definitions, and values derived from IP Address values in SNMP object names.
- SNMP：MIB定義のIPアドレス値、およびSNMPオブジェクト名のIPアドレス値から派生した値を使用します。
Further experimentation in this area is planned to validate these details.
これらの詳細を検証するために、この領域でのさらなる実験が計画されています。
A related topic is interworking: for example, how would an IPv6 node communicate with an ILNPv6 node? Currently, we make the assumption that ILNP nodes "drop down" to using IP when communicating with a non-ILNP capable node, i.e., there is no interworking as such. In the future, it may be beneficial to define interworking scenarios that do not rely on having ILNP nodes fall back to IP, for example, by the use of suitable protocol translation gateways or middleboxes.
関連トピックはインターワーキングです。たとえば、IPv6ノードはILNPv6ノードとどのように通信しますか？現在、ILNP非対応ノードと通信する場合、ILNPノードはIPを使用するように「ドロップダウン」する、つまり、そのようなインターワーキングは存在しないと想定しています。将来的には、たとえば適切なプロトコル変換ゲートウェイまたはミドルボックスを使用することにより、ILNPノードがIPにフォールバックすることに依存しないインターワーキングシナリオを定義することが有益になる可能性があります。
For now, a simplified summary of the process for interaction between ILNP hosts and non-ILNP hosts is as follows:
ここでは、ILNPホストと非ILNPホスト間の相互作用のプロセスの簡単な要約を以下に示します。
a) For a host initiating communication using DNS, the resolution of the FQDN for the remote host will return at least one NID record and at least one of an L32 record (for ILNPv4) or an L64 record (for ILNPv6). Then, the host knows that the remote host supports ILNP.
a) DNSを使用して通信を開始するホストの場合、リモートホストのFQDNの解決により、少なくとも1つのNIDレコードと少なくとも1つのL32レコード（ILNPv4の場合）またはL64レコード（ILNPv6の場合）が返されます。次に、ホストは、リモートホストがILNPをサポートしていることを認識します。
b) When a host has I and L values for a remote host, the initial packet to initiate communication MUST contain a Nonce Header [RFC6746] [RFC6744] that indicates to the remote host that this packet is attempting to set up an ILNP session.
b) ホストにリモートホストのIおよびL値がある場合、通信を開始する最初のパケットには、このパケットがILNPセッションをセットアップしようとしていることをリモートホストに示すノンスヘッダー[RFC6746] [RFC6744]が含まれている必要があります。
c) When a receiving host sees a Nonce Header, if it DOES support ILNP it will proceed to set up an ILNP session.
c) 受信側ホストがノンスヘッダーを確認したときに、ILNPをサポートしていれば、ILNPセッションのセットアップに進みます。
d) When a receiving host sees a Nonce Header, if it DOES NOT support ILNP, it will reject the packet and this will be indicated to the sender through an ICMP message [RFC6743] [RFC6745]. Upon receiving the ICMP messages, the sender will re-initiate communication using standard IPv4 or IPv6.
d) 受信側ホストがノンスヘッダーを参照するときに、ILNPをサポートしていない場合、パケットを拒否し、これはICMPメッセージ[RFC6743] [RFC6745]を通じて送信者に通知されます。 ICMPメッセージを受信すると、送信者は標準のIPv4またはIPv6を使用して通信を再開します。
Many observers in the community expect IPv4 to remain in place for a long time even though IPv6 has been available for over a decade. With a similar anticipation, it is likely that in the future there will be a mixed environment of both IP and ILNP hosts. Until there is a better understanding of the deployment and usage scenarios that will develop, it is not clear what interworking scenarios would be useful to define and focus on between IP and ILNP.
コミュニティの多くの観測者は、IPv6が10年以上利用可能であったとしても、IPv4が長期間適切な場所に留まることを期待しています。同様の期待で、将来的にはIPホストとILNPホストの両方が混在する環境になる可能性があります。開発される展開と使用のシナリオをよりよく理解するまでは、IPとILNPを定義してそれに焦点を当てるのに役立つインターワーキングシナリオが明確になるかは明らかではありません。
There are numerous security considerations for ILNP from an engineering viewpoint. Overall, ILNP and its capabilities are no less secure than IP and equivalent IP capabilities. In some cases, ILNP has the potential to be more secure, or offer security capability in a more harmonised manner, for example, with ILNP's use of IPsec in conjunction with multihoming and mobility. [RFC6740] describes several security considerations that apply to ILNP and is included here by reference.
ILNPには、エンジニアリングの観点から多くのセキュリティ上の考慮事項があります。全体として、ILNPとその機能は、IPおよび同等のIP機能と同じくらい安全です。場合によっては、ILNPは、たとえば、マルチホーミングやモビリティと組み合わせてIPsecを使用するなど、より安全な、またはより調和した方法でセキュリティ機能を提供する可能性があります。 [RFC6740]は、ILNPに適用されるいくつかのセキュリティの考慮事項を説明しており、参照によりここに含まれています。
ILNP offers an enhanced version of IP security (IPsec). The details of IP Security for ILNP were described separately above. All ILNP implementations MUST support the use of the IP Authentication Header (AH) for ILNP and also the IP Encapsulating Security Payload (ESP) for ILNP, but deployment and use of IPsec for ILNP remains a matter for local operational security policy.
ILNPは、IPセキュリティ（IPsec）の拡張バージョンを提供します。 ILNPのIPセキュリティの詳細については、上記で個別に説明しました。すべてのILNP実装は、ILNPのIP認証ヘッダー（AH）の使用とILNPのIPカプセル化セキュリティペイロード（ESP）の使用をサポートする必要がありますが、ILNPのIPsecの展開と使用はローカルの運用セキュリティポリシーの問題のままです。
Separate documents propose a new IPv4 Option [RFC6746] and a new IPv6 Destination Option [RFC6744]. Each of these options can be used to carry an ILNP Nonce value end-to-end between communicating nodes. That nonce provides protection against off-path attacks on an ILNP session. These ILNP Nonce Options are used ONLY for ILNP and not for IP. The nonce values are exchanged in the initial packets of an ILNP session by including them in those initial/handshake packets.
別のドキュメントで、新しいIPv4オプション[RFC6746]と新しいIPv6宛先オプション[RFC6744]が提案されています。これらの各オプションを使用して、通信ノード間でエンドツーエンドのILNPナンス値を伝送できます。そのnonceは、ILNPセッションでのオフパス攻撃に対する保護を提供します。これらのILNP Nonceオプションは、IPではなくILNPに対してのみ使用されます。 nonce値は、それらの初期/ハンドシェイクパケットに含めることにより、ILNPセッションの初期パケットで交換されます。
ALL ICMP Locator Update messages MUST include an ILNP Nonce Option and MUST include the correct ILNP Nonce value for the claimed sender and intended recipient of that ICMP Locator Update message. There are no exceptions to this rule. ICMP Locator Update messages MAY be protected by IPsec, but they still MUST include an ILNP Nonce Option and the ILNP Nonce Option still MUST include the correct ILNP Nonce value.
すべてのICMPロケーター更新メッセージには、ILNPナンスオプションを含める必要があり、そのICMPロケーター更新メッセージの要求された送信者と対象受信者の正しいILNPノンス値を含める必要があります。このルールに例外はありません。 ICMP Locator UpdateメッセージはIPsecによって保護される場合がありますが、それらには依然としてILNP Nonce Optionが含まれている必要があり、ILNP Nonce Optionには正しいILNP Nonce値が含まれている必要があります。
When a node has an active ILNP session, and that node changes its Locator set, it SHOULD include the appropriate ILNP Nonce Option in the first few data packets sent using a new Locator value so that the recipient can validate the received data packets as valid (despite having an unexpected Source Locator value).
ノードにアクティブなILNPセッションがあり、そのノードがロケーターセットを変更する場合、受信者が受信したデータパケットを有効なものとして検証できるように、新しいロケーター値を使用して送信される最初のいくつかのデータパケットに適切なILNPナンスオプションを含める必要があります（SHOULD）。予期しないソースロケータ値があるにもかかわらず）。
Any ILNP Locator Update messages received without an ILNP Nonce Option MUST be discarded as forgeries.
ILNPナンスオプションなしで受信されたILNPロケーター更新メッセージは、偽造として破棄する必要があります。
Any ILNP Locator Update messages received with an ILNP Nonce Option, but that do NOT have the correct ILNP Nonce value inside the ILNP Nonce Option, MUST be discarded as forgeries.
ILNP Nonce Optionで受信されたILNP Locator Updateメッセージは、ILNP Nonce Option内に正しいILNP Nonce値がないため、偽造として破棄する必要があります。
When the claimed sender of an ICMP message is known to be a current ILNP correspondent of the recipient (e.g., has a valid, non-expired, ILCC entry), then any ICMP error messages from that claimed sender MUST include the ILNP Nonce Option and MUST include the correct ILNP Nonce value (i.e., correct for that sender recipient pair) in that ILNP Nonce Option.
ICMPメッセージの要求された送信者が受信者の現在のILNPコレスポンデントであることがわかっている場合（たとえば、有効で、有効期限が切れていないILCCエントリがある場合）、その要求された送信者からのICMPエラーメッセージにはILNPナンスオプションとそのILNP Nonceオプションに正しいILNP Nonce値（つまり、その送信者と受信者のペアに対して正しい）を含める必要があります。
When the claimed sender of an ICMP error message is known to be a current ILNP correspondent of the recipient (e.g., has a valid, non-expired, ILCC entry), then any ICMP error messages from that claimed sender that are received without an ILNP Nonce Option MUST be discarded as forgeries.
ICMPエラーメッセージの要求された送信者が受信者の現在のILNPコレスポンデントであることがわかっている場合（たとえば、有効で期限切れでないILCCエントリがある場合）、ILNPなしで受信されたその要求された送信者からのICMPエラーメッセージナンスオプションは偽造品として破棄する必要があります。
When the claimed sender of an ICMP error message is known to be a current ILNP correspondent of the recipient (e.g., has a valid, non-expired, ILCC entry), then any ICMP error messages from that claimed sender that contain an ILNP Nonce Option, but that do NOT have the correct ILNP Nonce value inside the ILNP Nonce Option, MUST be discarded as forgeries.
ICMPエラーメッセージの要求された送信者が受信者の現在のILNPコレスポンデントであることがわかっている場合（たとえば、有効で、有効期限が切れていないILCCエントリがある場合）、ILNPナンスオプションを含むその要求された送信者からのICMPエラーメッセージ、ただし、ILNP Nonceオプション内に正しいILNP Nonce値がない場合は、偽造として破棄する必要があります。
ICMP messages (not including ICMP Locator Update messages) with a claimed sender that is NOT known to be a current ILNP correspondent of the recipient (e.g., does not have a valid, non-expired, ILCC entry) MAY include the ILNP Nonce Option, but, in this case, the ILNP Nonce Option is ignored by the recipient upon receipt, since the recipient has no way to authenticate the received ILNP Nonce value.
受信者の現在のILNPコレスポンデントであることがわかっていない（たとえば、有効な、有効期限が切れていない、ILCCエントリがない）主張された送信者のICMPメッセージ（ICMPロケーター更新メッセージは含まない）には、ILNPノンスオプションを含めることができます。ただし、この場合、受信者は受信したILNP Nonce値を認証する方法がないため、受信時にILNP Nonce Optionは無視されます。
Received ICMP messages (not including ICMP Locator Update messages) with a claimed sender that is NOT known to be a current ILNP correspondent of the recipient (e.g., does not have a valid, non-expired, ILCC entry) do NOT require the ILNP Nonce Option because the security risks are no different than for deployed IPv4 and IPv6 -- provided that the received ICMP message is not an ICMP Locator Update message. Such ICMP messages (e.g., Destination Unreachable, Packet Too Big) might legitimately originate in an intermediate system along the path of an ILNP session. That intermediate system might not be ILNP capable. Even if ILNP capable itself, that intermediate system might not know which of the packets it forwards are part of ILNP sessions.
受信者の現在のILNPコレスポンデントであることが知られていない（たとえば、有効な、有効期限が切れていない、ILCCエントリがない）主張された送信者で受信したICMPメッセージ（ICMPロケーター更新メッセージは含まない）は、ILNPナンスを必要としません受信したICMPメッセージがICMPロケーターアップデートメッセージではない場合、セキュリティリスクは展開されたIPv4およびIPv6の場合と同じであるため、オプション。このようなICMPメッセージ（Destination Unreachable、Packet Too Bigなど）は、ILNPセッションのパスに沿った中間システムで合法的に発生する可能性があります。その中間システムはILNPに対応していない可能性があります。 ILNP対応であっても、その中間システムは、転送するパケットがILNPセッションの一部であることを認識していない場合があります。
When ILNP is in use, IP Security for ILNP also MAY be used to protect stronger protections for ICMP packets associated with an ILNP session. Even in this case, the ILNP Nonce Option also MUST be present and MUST contain the correct ILNP Nonce value. This simplifies packet processing and enables rapid discard of any forged packets from an off-path attacker that lack either the ILNP Nonce Option or the correct ILNP Nonce value -- without requiring computationally expensive IPsec processing. Received ICMP messages that are protected by ILNP IP Security, but fail the recipient's IPsec checks, MUST be dropped as forgeries. If a deployment chooses to use ILNP IPsec ESP to protect its ICMP messages and is NOT also using ILNP IPsec AH with those messages, then the ILNP Nonce Option MUST be placed in the ILNP packet after the ILNP IPsec ESP header, rather than before the ILNP IPsec ESP header, to ensure that the Nonce Option is protected in transit.
ILNPが使用されている場合、ILNPのIPセキュリティを使用して、ILNPセッションに関連付けられたICMPパケットのより強力な保護を保護することもできます（MAY）。この場合でも、ILNP Nonceオプションが存在しなければならず、正しいILNP Nonce値を含んでいる必要があります。これにより、パケット処理が簡素化され、ILNP Nonceオプションまたは正しいILNP Nonce値のいずれかを持たないオフパス攻撃者からの偽造パケットを迅速に破棄できるようになります。 ILNP IPセキュリティによって保護されているが、受信者のIPsecチェックに失敗した受信ICMPメッセージは、偽造としてドロップする必要があります。 ICMPメッセージを保護するためにデプロイメントがILNP IPsec ESPを使用することを選択し、それらのメッセージでILNP IPsec AHも使用していない場合、ILNPノンスオプションはILNPの前ではなく、ILNP IPsec ESPヘッダーの後のILNPパケットに配置する必要があります。 IPSec ESPヘッダー。ノンスオプションが転送中に保護されるようにします。
Receipt of any ICMP message that is dropped or discarded as a forgery SHOULD cause the details of the received forged ICMP packet (e.g., Source and Destination Locators / Source and Destination Identifiers / Source and Destination IP Addresses, ICMP message type, receiving interface, receive date, receive time) to be logged in the receiving system's security logs. Implementations MAY rate-limit such logging in order to reduce operational risk of denial-of-service attacks on the system logging functions. The details of system logging are implementation specific.
偽造としてドロップまたは破棄されたICMPメッセージを受信すると、偽造された受信ICMPパケットの詳細（SHOULD）が発生します（例：送信元と宛先のロケーター/送信元と宛先の識別子/送信元と宛先のIPアドレス、ICMPメッセージタイプ、受信インターフェイス、受信）日付、受信時刻）を受信システムのセキュリティログに記録します。実装は、システムロギング機能に対するサービス拒否攻撃の運用リスクを低減するために、そのようなロギングをレート制限してもよい（MAY）。システムロギングの詳細は実装固有です。
The ILNP Communication Cache (ILCC) contains two unidirectional nonce values (one used in control messages sent by this node, a different one used to authenticate messages from the other node) for each active or recent ILNP session. The ILCC also contains the currently valid set of Locators and set of Identifiers for each correspondent node.
ILNP通信キャッシュ（ILCC）には、アクティブまたは最近のILNPセッションごとに、2つの単方向ナンス値（このノードが送信する制御メッセージで使用されるもの、他のノードからのメッセージの認証に使用されるもの）が含まれています。 ILCCには、対応するノードごとに現在有効なロケーターのセットと識別子のセットも含まれています。
If a received ILNP packet contains valid Identifier values and a valid Destination Locator, but contains a Source Locator value that is not present in the ILCC, the packet MUST be dropped as an invalid packet and a security event SHOULD be logged, UNLESS the packet also contains a Nonce Destination Option with the correct value used for packets from the node with that Source Identifier to this node. This prevents an off-path attacker from stealing an existing ILNP session.
受信したILNPパケットに有効な識別子の値と有効な宛先ロケーターが含まれているが、ILCCには存在しないソースロケーター値が含まれている場合、パケットは無効なパケットとしてドロップする必要があり、セキュリティイベントをログに記録する必要があります（パケットもない場合）そのソースIDを持つノードからこのノードへのパケットに使用される正しい値を持つナンス宛先オプションが含まれています。これにより、オフパス攻撃者が既存のILNPセッションを盗むのを防ぎます。
There are no additional privacy issues created by ILNP compared to IP. Please see Section 10 of [RFC6740] for more detailed discussion of Privacy Considerations.
IPと比較して、ILNPによって作成される追加のプライバシー問題はありません。プライバシーに関する考慮事項の詳細については、[RFC6740]のセクション10をご覧ください。
ILNPv6 supports use of the IPv6 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC4941] to enable identity privacy (see also Section 2).
ILNPv6は、IPv6 [RFC4941]のステートレスアドレス自動構成用のIPv6プライバシー拡張の使用をサポートして、アイデンティティプライバシーを有効にします（セクション2も参照）。
Location Privacy can be provided by locator rewriting techniques as described in Section 7 of [RFC6748].
[RFC6748]のセクション7で説明されているように、位置情報のプライバシーはロケーターの書き換え技術によって提供できます。
A description of various possibilities for obtaining both identity privacy and location privacy with ILNP can be found in [BAK11].
ILNPでIDプライバシーとロケーションプライバシーの両方を取得するためのさまざまな可能性の説明は、[BAK11]にあります。
This section covers various operational considerations relating to ILNP, including potential session liveness and reachability considerations and Key Management considerations. Again, the situation is similar to IP, but it is useful to explain the issues in relation to ILNP nevertheless.
このセクションでは、潜在的なセッションの活性と到達可能性の考慮事項、キー管理の考慮事項など、ILNPに関連するさまざまな運用上の考慮事項について説明します。繰り返しになりますが、状況はIPに似ていますが、それでもILNPに関連する問題を説明するのに役立ちます。
For bidirectional flows, such as a TCP/ILNP session, each node knows whether the current path in use is working by the reception of data packets, acknowledgements, or both. Therefore, as with TCP/IP, TCP/ILNP does not need special path probes. UDP/ILNP sessions with acknowledgements work similarly and do not need special path probes.
TCP / ILNPセッションなどの双方向フローの場合、各ノードは、使用中の現在のパスがデータパケットの受信、確認応答、またはその両方によって機能しているかどうかを認識しています。したがって、TCP / IPと同様に、TCP / ILNPは特別なパスプローブを必要としません。確認応答付きのUDP / ILNPセッションは同様に機能し、特別なパスプローブを必要としません。
In the deployed Internet, the sending node for a UDP/IP session without acknowledgements does not know for certain that all packets are received by the intended receiving node. Such UDP/ILNP sessions have the same properties as UDP/IP sessions in this respect. The receiver(s) of such an UDP/ILNP session SHOULD send a gratuitous IP packet containing an ILNP Nonce Option to the sender, in order to enable the receiver to subsequently send ICMP Locator Updates if appropriate [RFC6744]. In this case, UDP/ILNP sessions fare better than UDP/IP sessions, still without using network path probes.
展開されたインターネットでは、確認応答のないUDP / IPセッションの送信ノードは、すべてのパケットが意図された受信ノードによって受信されたことを確実に認識していません。このようなUDP / ILNPセッションには、この点でUDP / IPセッションと同じプロパティがあります。そのようなUDP / ILNPセッションの受信者は、受信者がICMPロケーター更新を適切に送信できるようにするために、ILNPナンスオプションを含む無償のIPパケットを送信者に送信する必要があります（SHOULD）[RFC6744]。この場合、UDP / ILNPセッションは、UDP / IPセッションよりも優れていますが、ネットワークパスプローブを使用していません。
A mobile (or multihomed) node may change its connectivity more quickly than DNS can be updated. This situation is unlikely, particularly given the widespread use of link-layer mobility mechanisms (e.g., GSM, IEEE 802 bridging) in combination with network-layer mobility. However, the situation is equivalent to the situation where a traditional IP node is moving faster than the Mobile IPv4 or Mobile IPv6 agents/servers can be updated with the mobile node's new location. So the issue is not new in any way to ILNP. In all cases, Mobile IPv4 and Mobile IPv6 and ILNP, a node moving that quickly might be temporarily unreachable until it remains at a given network-layer location (e.g., IP subnetwork, ILNP Locator value) long enough for the location update mechanisms (for Mobile IPv4, for Mobile IPv6, or ILNP) to catch up.
モバイル（またはマルチホーム）ノードは、DNSを更新するよりも速く接続を変更する可能性があります。この状況は、ネットワーク層モビリティと組み合わせたリンク層モビリティメカニズム（たとえば、GSM、IEEE 802ブリッジング）の広範な使用を考えると、特にありそうにありません。ただし、この状況は、従来のIPノードがモバイルIPv4またはモバイルIPv6エージェント/サーバーをモバイルノードの新しい場所で更新できるよりも速く移動している状況と同等です。したがって、問題はILNPにとって決して新しいものではありません。すべてのケースで、モバイルIPv4とモバイルIPv6とILNPは、移動中のノードであり、場所の更新メカニズムに十分な長さ（IPサブネットワーク、ILNPロケーター値など）が特定のネットワークレイヤーの場所に留まるまで、一時的に到達不能になる可能性があります。モバイルIPv4、モバイルIPv6、またはILNP）が追いつきます。
Another potential issue for IP is what is sometimes called "Path Liveness" or, in the case of ILNP, "Locator Liveness". This refers to the question of whether an IP packet with a particular destination Locator value will be able to reach the intended destination network or not, given that some otherwise valid paths might be unusable by the sending node (e.g., due to security policy or other administrative choice). In fact, this issue has existed in the IPv4 Internet for decades.
IPのもう1つの潜在的な問題は、「パスの活性」またはILNPの場合は「ロケーターの活性」と呼ばれることもあります。これは、特定の宛先ロケーター値を持つIPパケットが、目的の宛先ネットワークに到達できるかどうかという問題を指します。他の有効なパスが送信ノードで使用できない場合がある（たとえば、セキュリティポリシーまたはその他の理由により）管理上の選択）。実際、この問題は何十年もの間IPv4インターネットに存在しています。
For example, an IPv4 server might have multiple valid IP Addresses, each advertised to the world via a DNS A record. However, at a given moment in time, it is possible that a given sending node might not be able to use a given (otherwise valid) destination IPv4 address in an IP packet to reach that IPv4 server.
たとえば、IPv4サーバーには複数の有効なIPアドレスがあり、それぞれがDNS Aレコードを介して世界にアドバタイズされる場合があります。ただし、特定の瞬間に、特定の送信ノードが特定の（そうでなければ有効な）宛先IPv4アドレスをIPパケットで使用してそのIPv4サーバーに到達できない可能性があります。
Indeed, for ILNPv6, as the ILNP packet reuses the IPv6 packet header and uses IPv6 routing prefixes as Locator values, such liveness considerations are no worse than they are for IPv6 today. For example, for IPv6, if a host, H, performs a DNS lookup for an FQDN for remote host F, and receives a AAAA RR with IPv6 address F_A, this does not mean necessarily that H can reach F on its F_A using its current connectivity, i.e., an IPv6 path may not be available from H to F at that point in time.
実際、ILNPv6の場合、ILNPパケットはIPv6パケットヘッダーを再利用し、IPv6ルーティングプレフィックスをロケーター値として使用するため、このような活性に関する考慮事項は、現在のIPv6の場合よりも悪くありません。たとえば、IPv6の場合、ホストHがリモートホストFのFQDNのDNSルックアップを実行し、IPv6アドレスF_AのAAAA RRを受信しても、必ずしもHが現在のF_AでFに到達できることを意味するわけではありません接続性、つまり、その時点でHからFへのIPv6パスが利用できない場合があります。
So we see that using an Identifier/Locator Split architecture does not create this issue, nor does it make this issue worse than it is with the deployed IPv4 Internet.
したがって、識別子/ロケータースプリットアーキテクチャを使用してもこの問題は発生せず、展開されたIPv4インターネットの場合よりもこの問題が悪化することはありません。
In ILNP, the same conceptual approach described in [RFC5534] (Locator Pair Exploration for SHIM6) can be reused. Alternatively, an ILNP node can reuse the existing IPv4 methods for determining whether a given path to the target destination is currently usable, for which existing methods leverage transport-layer session state information that the communicating end systems are already keeping for transport-layer protocol reasons.
ILNPでは、[RFC5534]（SHIM6のロケーターペア探索）で説明されているのと同じ概念的アプローチを再利用できます。または、ILNPノードは既存のIPv4メソッドを再利用して、ターゲットの宛先への特定のパスが現在使用可能かどうかを判断できます。既存のメソッドは、通信するエンドシステムがトランスポート層プロトコルの理由ですでに保持しているトランスポート層セッション状態情報を利用します。 。
Lastly, it is important to note that the ICMP Locator Update mechanism described in [RFC6743] [RFC6745] is a performance optimisation, significantly shortening the network-layer handoff time if/when a correspondent changes location. Architecturally, using ICMP is no different from using UDP, of course.
最後に、[RFC6743] [RFC6745]で説明されているICMPロケーター更新メカニズムはパフォーマンスの最適化であり、通信相手が場所を変更した場合にネットワーク層のハンドオフ時間を大幅に短縮することに注意することが重要です。もちろん、アーキテクチャ上、ICMPの使用はUDPの使用と何の違いもありません。
ILNP potentially has advantages over either form of Mobile IP with respect to key management, given that ILNP is using Secure Dynamic DNS Update -- which capability is much more widely available today in deployed desktop and server environments (e.g., Microsoft Windows, Mac OS X, Linux, other UNIX), as well as being widely available today in deployed DNS server software (e.g., Microsoft and the freely available BIND) and appliances [LA06], than the security enhancements needed by either Mobile IPv4 or Mobile IPv6.
ILNPがセキュアダイナミックDNSアップデートを使用していることを考えると、ILNPはキー管理に関してモバイルIPのどちらの形式よりも潜在的に利点があります-この機能は、展開されたデスクトップおよびサーバー環境（Microsoft Windows、Mac OS Xなど）で今日より広く利用可能です、Linux、その他のUNIX）、さらに、現在配備されているDNSサーバーソフトウェア（Microsoftや無料で入手できるBINDなど）およびアプライアンス[LA06]で、モバイルIPv4またはモバイルIPv6で必要なセキュリティ強化よりも広く利用可能です。
In the IESG, there is work in progress that addresses use of DNS to support key management for entities having DNS Fully Qualified Domain Names.
IESGには、DNSの完全修飾ドメイン名を持つエンティティのキー管理をサポートするためのDNSの使用に対処する作業が進行中です。
As a special case, for the operational reasons described in [RFC6164], ILNPv6 deployments MAY continue to use classic IPv6 with a /127 routing prefix on router to router point-to-point links (e.g., SONET/SDH). Because an ILNPv6 packet and an IPv6 packet are indistinguishable for forwarding purposes to a transit router, this should not create any operational difficulty for ILNPv6 traffic travelling over such links.
特別なケースとして、[RFC6164]で説明されている運用上の理由から、ILNPv6の展開では、ルーターからルーターへのポイントツーポイントリンク（SONET / SDHなど）に/ 127ルーティングプレフィックスを付けた従来のIPv6を引き続き使用できます。 ILNPv6パケットとIPv6パケットは、中継ルーターへの転送の目的では区別できないため、このようなリンク上を移動するILNPv6トラフィックの運用上の問題は発生しません。
This section is concerned with support for using existing ("legacy") applications over ILNP, including both referrals and Application Programming Interfaces (APIs).
このセクションは、紹介とアプリケーションプログラミングインターフェイス（API）の両方を含む、ILNPを介した既存の（「レガシー」）アプリケーションの使用のサポートに関係しています。
ILNP does NOT require that well-behaved applications be modified to use a new networking API, nor does it require applications be modified to use extensions to an existing API. Existing well-behaved IP applications should work over ILNP without modification using existing networking APIs.
ILNPは、新しいネットワークAPIを使用するように適切に動作するアプリケーションを変更する必要がなく、既存のAPIの拡張機能を使用するようにアプリケーションを変更する必要もありません。既存の正常に動作するIPアプリケーションは、既存のネットワークAPIを使用して変更することなくILNPで動作するはずです。
The existing BSD Sockets API can continue to be used with ILNP underneath the API. That API can be implemented in a manner that hides the underlying protocol changes from the applications. For example, the combination of a Locator and an Identifier can be used with the API in the place of an IPv6 address.
既存のBSDソケットAPIは、APIの下でILNPと共に引き続き使用できます。そのAPIは、基になるプロトコルの変更をアプリケーションから隠す方法で実装できます。たとえば、ロケーターと識別子の組み合わせは、IPv6アドレスの代わりにAPIで使用できます。
So it is believed that existing IP address referrals can continue to work properly in most cases. For a rapidly moving target node, referrals might break in at least some cases. The potential for referral breakage is necessarily dependent upon the specific application and implementation being considered.
そのため、既存のIPアドレスの参照は、ほとんどの場合、引き続き適切に機能すると考えられています。ターゲットノードが急速に移動している場合、少なくともいくつかのケースで紹介が中断する可能性があります。紹介の破損の可能性は、検討されている特定のアプリケーションと実装に必ず依存します。
It is suggested, however, that a new, optional, more abstract, C language API be created so that new applications may avoid delving into low-level details of the underlying network protocols. Such an API would be useful today, even with the existing IPv4 and IPv6 Internet, whether or not ILNP were ever widely deployed.
ただし、新しいオプションの、より抽象的なC言語APIを作成して、新しいアプリケーションが基礎となるネットワークプロトコルの低レベルの詳細を掘り下げるのを避けることをお勧めします。このようなAPIは、ILNPが広く展開されているかどうかにかかわらず、既存のIPv4およびIPv6インターネットを使用していても、今日は有用です。
Most existing Java APIs already use abstracted network programming interfaces, for example, in the java.Net.URL class. Because these APIs already hide the low-level network-protocol details from the applications, the applications using these APIs (and the APIs themselves) don't need any modification to work equally well with IPv4, IPv6, ILNP, and probably also HIP.
ほとんどの既存のJava APIは、たとえばjava.Net.URLクラスなどで、抽象化されたネットワークプログラミングインターフェイスをすでに使用しています。これらのAPIはすでにアプリケーションから低レベルのネットワークプロトコルの詳細を隠しているため、これらのAPIを使用するアプリケーション（およびAPI自体）を変更する必要はなく、IPv4、IPv6、ILNP、およびおそらくHIPでも同じように機能します。
Other programming languages, such as C++, python and ruby, also provide higher-level APIs that abstract away from sockets, even though sockets may be used beneath those APIs.
C ++、python、rubyなどの他のプログラミング言語も、ソケットを抽象化する高レベルのAPIを提供しますが、これらのAPIの下でソケットを使用することもできます。
The approach proposed in [REFERRAL] appears to be very suitable for use with ILNP, in addition to being suitable for use with the deployed Internet. Protocols using that approach would not need modification to have their referrals work well with IPv4, IPv6, ILNP, and probably also other network protocols (e.g., HIP).
[REFERRAL]で提案されているアプローチは、配備されたインターネットでの使用に適しているだけでなく、ILNPでの使用にも非常に適しているようです。そのアプローチを使用するプロトコルは、紹介がIPv4、IPv6、ILNP、およびおそらく他のネットワークプロトコル（HIPなど）でも適切に機能するように変更する必要はありません。
A sensible approach to referrals is to use FQDNs, as is commonly done today with web URLs. This approach is highly portable across different network protocols, even with both the IPv4 Internet or the IPv6 Internet.
紹介への賢明なアプローチは、今日Web URLで一般的に行われているように、FQDNを使用することです。このアプローチは、IPv4インターネットまたはIPv6インターネットの両方を使用する場合でも、さまざまなネットワークプロトコル間で移植性が高くなります。
[IEEE-EUI] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", <http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html>, IEEE, Piscataway, NJ, USA, March 1997.
[IEEE-EUI] IEEE、「64ビットグローバル識別子（EUI-64）登録局のガイドライン」、<http://standards.ieee.org/ regauth / oui / tutorials / EUI64.html>、IEEE、Piscataway、米国ニュージャージー州、1997年3月。
[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月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177] IABおよびIESG、「サイトへのIPv6アドレス割り当てに関するIAB / IESGの推奨事項」、RFC 3177、2001年9月。
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003.
[RFC3587] Hinden、R.、Deering、S。、およびE. Nordmark、「IPv6 Global Unicast Address Format」、RFC 3587、2003年8月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[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月。
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, March 2011.
[RFC6177] Narten、T.、Huston、G。、およびL. Roberts、「エンドサイトへのIPv6アドレスの割り当て」、BCP 157、RFC 6177、2011年3月。
[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月。
[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月。
[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月。
[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月。
[RFC6747] Atkinson, R. and S. Bhatti, "Address Resolution Protocol (ARP) Extension for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)", RFC 6747, November 2012.
[RFC6747] Atkinson、R. and S. Bhatti、 "Address Resolution Protocol（ARP）Extension for the Identifier-Locator Network Protocol for IPv4（ILNPv4）"、RFC 6747、November 2012。
[BA11] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proceedings of IEEE Global Internet Symposium (GI2011), Shanghai, P.R. China, 15 April 2011.
[BA11] Bhatti、S.およびR. Atkinson、「Reducing DNS Caching」、Proceedings of IEEE Global Internet Symposium（GI2011）、上海、PR中国、2011年4月15日。
[BAK11] Bhatti, S.N., Atkinson, R., and J. Klemets, "Integrating Challenged Networks", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Baltimore, MD, USA, Nov 2011.
[BAK11] Bhatti、S.N.、Atkinson、R。、およびJ. Klemets、「Integrating Challenged Networks」、Proceedings of IEEE Military Communications Conference（MILCOM）、IEEE、Baltimore、MD、USA、2011年11月。
[LA06] Liu, C. and P. Albitz, "DNS and Bind", 5th Edition, O'Reilly & Associates, Sebastopol, CA, USA, 2006. ISBN 0-596-10057-4.
[LA06] Liu、C。およびP. Albitz、「DNS and Bind」、第5版、O'Reilly＆Associates、カリフォルニア州セバストポル、2006年。ISBN0-596-10057-4。
[PHG02] Pappas, A., Hailes, S. and R. Giaffreda, "Mobile Host Location Tracking through DNS", Proceedings of IEEE London Communications Symposium, IEEE, September 2002, London, England, UK.
[PHG02] Pappas、A.、Hailes、S。およびR. Giaffreda、「DNSによるモバイルホストロケーショントラッキング」、IEEE London Communications Symposiumの議事録、IEEE、2002年9月、ロンドン、イギリス、英国。
[SBK02] Snoeren, A., Balakrishnan, H. and M. Frans Kaashoek, "Reconsidering Internet Mobility", Proceedings of 8th Workshop on Hot Topics in Operating Systems, IEEE, Elmau, Germany, May 2001.
[SBK02] Snoeren、A.、Balakrishnan、H。およびM. Frans Kaashoek、「インターネットモビリティの再考」、オペレーティングシステムのホットトピックに関する第8回ワークショップの議事録、IEEE、ドイツ、エルマウ、2001年5月。
[REFERRAL] Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and K. Moore, "A Generic Referral Object for Internet Entities", Work in Progress, October 2009.
[参照] Carpenter、B.、Boucadair、M.、Halpern、J.、Jiang、S。、およびK. Moore、「インターネットエンティティの一般的な参照オブジェクト」、作業中、2009年10月。
[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月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、2005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses (CGA) Extension Field Format", RFC 4581, October 2006.
[RFC4581] Bagnulo、M。およびJ. Arkko、「Cryptographically Generated Addresses（CGA）Extension Field Format」、RFC 4581、2006年10月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6でのステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、2007年9月。
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC 4982, July 2007.
[RFC4982] Bagnulo、M。およびJ. Arkko、「Cryptographically Generated Addresses（CGAs）での複数のハッシュアルゴリズムのサポート」、RFC 4982、2007年7月。
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009.
[RFC5534] Arkko、J。およびI. van Beijnum、「IPv6マルチホーミング用の障害検出およびロケータペア探索プロトコル」、RFC 5534、2009年6月。
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, April 2011.
[RFC6164]河野雅夫、ニッサン、B。、ブッシュ、R。、松崎、Y。、コリッティ、L。、およびT.ナルテン、「ルーター間リンクでの127ビットIPv6プレフィックスの使用」、RFC 6164、 2011年4月。
[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