[要約] RFC 6740は、ILNP（Identifier-Locator Network Protocol）のアーキテクチャの説明を提供するものであり、ILNPの目的は、インターネット上のノードの識別子とその場所（ロケータ）を分離することにより、ネットワークの柔軟性と拡張性を向上させることです。
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6740 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Identifier-Locator Network Protocol (ILNP) Architectural Description
Identifier-Locator Network Protocol（ILNP）アーキテクチャの説明
Abstract
概要
This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This 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/rfc6740.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6740で入手できます。
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 ...........................................5
1.2. History ....................................................6
1.3. Terminology ................................................7
2. Architectural Overview ..........................................7
2.1. Identifiers and Locators ...................................7
2.2. Deprecating IP Addresses ...................................9
2.3. Session Terminology .......................................10
2.4. Other Goals ...............................................12
3. Architectural Changes Introduced by ILNP .......................12
3.1. Identifiers ...............................................12
3.2. Locators ..................................................14
3.3. IP Address and Identifier-Locator Vector (I-LV) ...........16
3.4. Notation ..................................................16
3.5. Transport-Layer State and Transport Pseudo-Headers ........18
3.6. Rationale for This Document ...............................18
3.7. ILNP Multicasting .........................................19
4. ILNP Basic Connectivity ........................................20
4.1. Basic Local Configuration .................................20
4.2. I-L Communication Cache ...................................21
4.3. Packet Forwarding .........................................22
4.4. Packet Routing ............................................23
5. Multihoming and Multi-Path Transport ...........................24
5.1. Host Multihoming (H-MH) ...................................25
5.2. Support for Multi-Path Transport Protocols ................27
5.3. Site Multihoming (S-MH) ...................................28
5.4. Multihoming Requirements for Site Border Routers ..........29
6. Mobility .......................................................30
6.1. Mobility / Multihoming Duality in ILNP ....................31
6.2. Host Mobility .............................................32
6.3. Network Mobility ..........................................34
6.4. Mobility Requirements for Site Border Routers .............36
6.5. Mobility with Multiple SBRs ...............................36
7. IP Security for ILNP ...........................................36
7.1. Adapting IP Security for ILNP .............................37
7.2. Operational Use of IP Security with ILNP ..................37
8. Backwards Compatibility and Incremental Deployment .............38
9. Security Considerations ........................................39
9.1. Authentication of Locator Updates .........................39
9.2. Forged Identifier Attacks .................................40
9.3. IP Security Enhancements ..................................42
9.4. DNS Security ..............................................42
9.5. Firewall Considerations ...................................42
9.6. Neighbour Discovery Authentication ........................42
9.7. Site Topology Obfuscation .................................43
10. Privacy Considerations ........................................43
10.1. Location Privacy .........................................43
10.2. Identity Privacy .........................................44
11. References ....................................................45
11.1. Normative References .....................................45
11.2. Informative References ...................................47
12. Acknowledgements ..............................................53
This document is part of the ILNP document set, which has had extensive review within the IRTF Routing RG. ILNP is one of the recommendations made by the RG Chairs. Separately, various refereed research papers on ILNP have also been published during this decade. So, the ideas contained herein have had much broader review than the IRTF Routing RG. The views in this document were considered controversial by the Routing RG, but the RG reached a consensus that the document still should be published. The Routing RG has had remarkably little consensus on anything, so virtually all Routing RG outputs are considered controversial.
このドキュメントは、IRTF Routing RG内で広範囲に渡って検討されたILNPドキュメントセットの一部です。 ILNPは、RG議長が行った勧告の1つです。これとは別に、ILNPに関するさまざまな査読付き研究論文もこの10年間に発行されています。したがって、ここに含まれているアイデアは、IRTF Routing RGよりもはるかに広範なレビューを受けています。このドキュメントの見解は、ルーティングRGによって物議を醸すと見なされましたが、RGは、ドキュメントを引き続き公開する必要があるというコンセンサスに達しました。ルーティングRGのコンセンサスは著しく低いため、事実上すべてのルーティングRG出力は物議を醸すと見なされています。
At present, the Internet research and development community 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つのクラスは「マップとカプセル化」と呼ばれることが多く、トラフィックはマップされ、インターネットのドメイン間コアを介してトンネリングされます。検討中の別のクラスは、「識別子/ロケータースプリット」と呼ばれることもあります。この文書は、進化論的アプローチの後者のクラスにある提案に関連しています。
There has been substantial research relating to naming in the Internet through the years [IEN1] [IEN19] [IEN23] [IEN31] [IEN135] [RFC814] [RFC1498] [RFC2956]. Much of that research has indicated that binding the end-to-end transport-layer session state with a specific interface of a node at a specific location is undesirable, for example, creating avoidable issues for mobility, multihoming, and end-to-end security. More recently, mindful of that important prior work, and starting well before the Routing RG was re-chartered to focus on inter-domain routing scalability, the authors have been examining enhancements to certain naming aspects of the Internet Architecture. Separately, the Internet Architecture Board (IAB) recently considered the matter of Internet evolution, including naming [RFC6250].
[IEN1] [IEN19] [IEN23] [IEN31] [IEN135] [RFC814] [RFC1498] [RFC2956]は、長年にわたってインターネットでの命名に関連する実質的な調査が行われてきました。その調査の多くは、エンドツーエンドのトランスポート層セッション状態を特定の場所にあるノードの特定のインターフェースにバインドすることは望ましくないことを示しています。たとえば、モビリティ、マルチホーミング、エンドツーエンドの回避可能な問題が発生します。セキュリティ。最近では、その重要な以前の作業を念頭に置き、ルーティングRGがドメイン間ルーティングのスケーラビリティに焦点を合わせるために再チャーターされる前に、筆者はインターネットアーキテクチャの特定のネーミングアスペクトの拡張を調査してきました。これとは別に、インターネットアーキテクチャボード（IAB）は、ネーミング[RFC6250]を含むインターネットの進化の問題を最近検討しました。
Our ideas and progress so far are embodied in the ongoing definition of an experimental protocol that we call the Identifier-Locator Network Protocol (ILNP).
これまでの私たちのアイデアと進歩は、Identifier-Locator Network Protocol（ILNP）と呼ぶ実験プロトコルの継続的な定義に具体化されています。
Links to relevant material are all available at:
http://ilnp.cs.st-andrews.ac.uk/
At the time of writing, the main body of peer-reviewed research from which the ideas in this and the accompanying documents draw is given in [LABH06], [ABH07a], [ABH07b], [ABH08a], [ABH08b], [ABH09a], [ABH09b], [RAB09], [ABH10], [RB10], [BA11], [BAK11], and [BA12].
執筆時点では、このレビューと付随するドキュメントのアイデアが引き出された査読済み研究の本体は、[LABH06]、[ABH07a]、[ABH07b]、[ABH08a]、[ABH08b]、[ABH09aに記載されています。 ]、[ABH09b]、[RAB09]、[ABH10]、[RB10]、[BA11]、[BAK11]、および[BA12]。
In this document, we:
このドキュメントでは、次のことを行います。
a) describe the architectural concepts behind ILNP and how various ILNP capabilities operate: this document deliberately focuses on describing the key architectural changes that ILNP introduces and defers engineering discussion to separate documents.
a) ILNPの背後にあるアーキテクチャの概念と、さまざまなILNP機能の動作について説明します。このドキュメントでは、ILNPが導入する主要なアーキテクチャの変更を説明することに重点を置き、エンジニアリングに関する議論を別のドキュメントに延期しています。
Other documents (listed below):
その他のドキュメント（以下にリスト）：
b) show how functions based on ILNP would be realised on today's Internet by proposing an instance of ILNP based on IPv6, which we call ILNPv6 (there is also a document describing ILNPv4, which is how ILNP could be applied to IPv4).
b) ILNPv6と呼ばれるIPv6に基づくILNPのインスタンスを提案することにより、ILNPに基づく機能が今日のインターネットでどのように実現されるかを示します（ILNPをIPv4に適用する方法であるILNPv4を説明するドキュメントもあります）。
c) discuss salient operational and engineering issues impacting the deployment of ILNPv6 and the impact on the Internet.
c) ILNPv6の展開とインターネットへの影響に影響を与える、運用上およびエンジニアリング上の顕著な問題について話し合う。
d) give architectural descriptions of optional advanced capabilities in advanced deployments based on the ILNP approach.
d) ILNPアプローチに基づく高度な導入におけるオプションの高度な機能のアーキテクチャの説明を提供します。
This document describes the architecture for the Identifier-Locator Network Protocol (ILNP) including concept of operations. The authors recommend reading and understanding this document as the starting point to understanding ILNP.
このドキュメントでは、操作の概念を含むIdentifier-Locator Network Protocol（ILNP）のアーキテクチャについて説明します。著者は、ILNPを理解するための出発点として、このドキュメントを読んで理解することをお勧めします。
The ILNP architecture can have more than one engineering instantiation. For example, one can imagine a "clean-slate" engineering design based on the ILNP architecture. In separate documents, we describe two specific engineering instances of ILNP. The term "ILNPv6" refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv6. The term "ILNPv4" refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv4.
ILNPアーキテクチャーは、複数のエンジニアリングのインスタンス化を持つことができます。たとえば、ILNPアーキテクチャに基づく「白紙」のエンジニアリング設計を想像できます。別のドキュメントで、ILNPの2つの特定のエンジニアリングインスタンスについて説明します。 「ILNPv6」という用語は、IPv6に基づいており、IPv6と下位互換性があるILNPのインスタンスを正確に指します。 「ILNPv4」という用語は、IPv4に基づいており、IPv4と下位互換性があるILNPのインスタンスを正確に指します。
Many engineering aspects common to both ILNPv4 and ILNPv6 are described in [RFC6741]. A full engineering specification for either ILNPv6 or ILNPv4 is beyond the scope of this document.
ILNPv4とILNPv6の両方に共通する多くの工学的側面が[RFC6741]で説明されています。 ILNPv6またはILNPv4の完全なエンジニアリング仕様は、このドキュメントの範囲外です。
Readers are referred to other related ILNP documents for details not described here:
ここで説明されていない詳細については、読者は関連する他のILNP文書を参照されます。
a) [RFC6741] describes engineering and implementation considerations that are common to both ILNPv4 and ILNPv6.
a) [RFC6741]では、ILNPv4とILNPv6の両方に共通するエンジニアリングと実装の考慮事項について説明しています。
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 the 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の操作または使用に必要ではなく、追加のオプションとして提供されます。
In 1977, Internet researchers at University College London wrote the first Internet Experiment Note (IEN), which discussed issues with the interconnection of networks [IEN1]. This identified the inclusion of network-layer addresses in the transport-layer session state (e.g., TCP checksum) as a significant problem for mobile and multihomed nodes and networks. It also proposed separation of identity from location as a better approach to take when designing the TCP/IP protocol suite. Unfortunately, that separation did not occur, so the deployed IPv4 and IPv6 Internet entangles upper-layer protocols (e.g., TCP, UDP) with network-layer routing and topology information (e.g., IP Addresses) [IEN1] [RFC768] [RFC793].
1977年、ロンドン大学ユニバーシティカレッジのインターネット研究者は、ネットワークの相互接続に関する問題を論じた最初のインターネット実験ノート（IEN）を書きました[IEN1]。これにより、トランスポート層のセッション状態（TCPチェックサムなど）にネットワーク層のアドレスが含まれることが、モバイルおよびマルチホームのノードとネットワークにとって重大な問題であることがわかりました。また、TCP / IPプロトコルスイートを設計するときに採用するより良いアプローチとして、場所からIDを分離することを提案しました。残念ながら、その分離は行われなかったため、展開されたIPv4およびIPv6インターネットは、上位層プロトコル（TCP、UDPなど）とネットワーク層ルーティングおよびトポロジー情報（IPアドレスなど）を絡み合わせています[IEN1] [RFC768] [RFC793] 。
The architectural concept behind ILNP derives from a June 1994 note by Bob Smart to the IETF SIPP WG mailing list [SIPP94]. In January 1995, Dave Clark sent a similar note to the IETF IPng WG mailing list, suggesting that the IPv6 address be split into separate Identifier and Locator fields [IPng95].
ILNPの背後にあるアーキテクチャの概念は、1994年6月のBob SmartによるIETF SIPP WGメーリングリスト[SIPP94]へのメモに由来しています。 1995年1月に、デイブクラークは同様のメモをIETF IPng WGメーリングリストに送信し、IPv6アドレスを個別の識別子フィールドとロケーターフィールドに分割するよう提案しました[IPng95]。
Afterwards, Mike O'Dell pursued this concept in Internet-Drafts describing "8+8" [8+8] and "GSE" (Global, Site, and End-system) [GSE]. More recently, the IRTF Namespace Research Group (NSRG) studied this matter around the turn of the century. Unusually for an IRTF RG, the NSRG operated on the principle that unanimity was required for the NSRG to make a recommendation. Atkinson was a member of the IRTF NSRG. At least one other protocol, the Host Identity Protocol (HIP), also derives in part from the IRTF NSRG studies (and related antecedent work). This current proposal differs from O'Dell's work in various ways, notably in that it does not require deployment or use of Locator rewriting.
その後、Mike O'Dellは「8 + 8」[8 + 8]および「GSE」（グローバル、サイト、およびエンドシステム）[GSE]を説明するインターネットドラフトでこのコンセプトを追求しました。最近では、IRTF名前空間研究グループ（NSRG）が世紀の変わり目にこの問題を調査しました。通常、IRTF RGの場合、NSRGは、NSRGが勧告を行うには全会一致が必要であるという原則に基づいて活動しました。アトキンソンはIRTF NSRGのメンバーでした。少なくとも1つの他のプロトコル、ホストアイデンティティプロトコル（HIP）も、IRTF NSRG研究（および関連する先行研究）から一部派生しています。この現在の提案は、特にロケーターの書き換えの導入や使用を必要としないという点で、オデルの作業とはさまざまな点で異なります。
The key idea proposed for ILNP is to directly and specifically change the overloaded semantics of the IP Address. The Internet community has indicated explicitly, several times, that this use of overloaded semantics is a significant problem with the use of the Internet protocol today [RFC1498] [RFC2101] [RFC2956] [RFC4984].
ILNPに提案された主要なアイデアは、IPアドレスのオーバーロードされたセマンティクスを直接かつ具体的に変更することです。インターネットコミュニティは、オーバーロードされたセマンティクスのこの使用が、今日のインターネットプロトコルの使用[RFC1498] [RFC2101] [RFC2956] [RFC4984]の重大な問題であることを、何度か明示的に示しています。
While the research community has made a number of proposals that could provide solutions, so far there has been little progress on changing the status quo.
研究コミュニティは解決策を提供することができる多くの提案をしましたが、これまでのところ現状を変えることについてほとんど進展がありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
ILNP takes a different approach to naming of communication objects within the network stack. Two new data types are introduced which subsume the role of the IP Address at the network and transport layers in the current IP architecture.
ILNPは、ネットワークスタック内の通信オブジェクトの命名に別のアプローチを採用しています。現在のIPアーキテクチャのネットワーク層とトランスポート層でのIPアドレスの役割を担う2つの新しいデータタイプが導入されました。
ILNP explicitly replaces the use of IP Addresses with two distinct name spaces, each having distinct and different semantics:
ILNPは、IPアドレスの使用を2つの異なる名前空間に明示的に置き換え、それぞれが異なる、異なるセマンティクスを持つ：
a) Identifier: a non-topological name for uniquely identifying a node.
a) 識別子：ノードを一意に識別するための非トポロジ名。
b) Locator: a topologically bound name for an IP subnetwork.
b) ロケーター：IPサブネットワークのトポロジー的にバインドされた名前。
The use of these two new namespaces in comparison to IP is given in Table 1. The table shows where existing names are used for state information in end-systems or protocols.
IPと比較したこれら2つの新しい名前空間の使用法を表1に示します。表は、既存の名前がエンドシステムまたはプロトコルの状態情報に使用される場所を示しています。
Layer | IP | ILNP
---------------+----------------------+---------------
Application | FQDN or IP Address | FQDN
Transport | IP Address | Identifier
Network | IP Address | Locator
Physical i/f | IP Address | MAC address
---------------+----------------------+---------------
FQDN = Fully Qualified Domain Name i/f = interface MAC = Media Access Control
FQDN =完全修飾ドメイン名i / f =インターフェイスMAC =メディアアクセスコントロール
Table 1: Use of Names for State Information in Various Communication Layers for IP and ILNP
表1：IPおよびILNPのさまざまな通信層における状態情報の名前の使用
As shown in Table 1, if an application uses a Fully Qualified Domain Name at the application-layer, rather than an IP Address or other lower-layer identifier, then the application perceives no architectural difference between IP and ILNP. We call such applications "well-behaved" with respect to naming as use of the FQDN at the application-layer is recommended in [RFC1958]. Some other applications also avoid use of IP Address information within the application-layer protocol; we also consider these applications to be "well-behaved". Any well-behaved application should be able to operate on ILNP without any changes. Note that application-level use of IP Addresses includes application-level configuration information, e.g., Apache web server (httpd) configuration files make extensive use of IP Addresses as a form of identity.
表1に示すように、アプリケーションがIPアドレスやその他の下位層の識別子ではなく、完全修飾ドメイン名をアプリケーション層で使用する場合、アプリケーションはIPとILNPのアーキテクチャ上の違いを認識しません。アプリケーション層でのFQDNの使用は[RFC1958]で推奨されているため、このようなアプリケーションは命名に関して「適切に動作する」と呼びます。他の一部のアプリケーションも、アプリケーション層プロトコル内でのIPアドレス情報の使用を回避しています。また、これらのアプリケーションは「正常に動作する」と見なします。正常に動作するアプリケーションは、変更を加えなくてもILNPを操作できる必要があります。アプリケーションレベルでのIPアドレスの使用には、アプリケーションレベルの構成情報が含まれることに注意してください。たとえば、Apache Webサーバー（httpd）構成ファイルは、IPアドレスをIDの形式として広範囲に使用します。
ILNP does not require applications to be rewritten to use a new Networking Application Programming Interface (API). So existing well-behaved IP-based applications should be able to work over ILNP as is.
ILNPでは、新しいNetworking Application Programming Interface（API）を使用するためにアプリケーションを書き直す必要はありません。そのため、既存の正常に動作するIPベースのアプリケーションは、そのままILNPで機能するはずです。
In ILNP, transport-layer protocols use only an end-to-end, non-topological node Identifier in any transport-layer session state. It is important to note that the node Identifier names the node, not a specific interface of the node. In this way, it has different semantics and properties than either the IPv4 address, the IPv6 address, or the IPv6 interface identifier [RFC791] [RFC4291].
ILNPでは、トランスポート層プロトコルは、トランスポート層セッション状態でエンドツーエンドの非トポロジノード識別子のみを使用します。ノード識別子はノードの名前であり、ノードの特定のインターフェイスではないことに注意することが重要です。このように、IPv4アドレス、IPv6アドレス、またはIPv6インターフェース識別子[RFC791] [RFC4291]とは異なるセマンティクスとプロパティがあります。
The use of the ILNP Identifier value within application-layer protocols is not recommended. Instead, the use of either a FQDN or some different topology-independent namespace is recommended.
アプリケーション層プロトコル内でILNP ID値を使用することはお勧めしません。代わりに、FQDNまたはトポロジに依存しないさまざまな名前空間の使用をお勧めします。
At the network-layer, Locator values, which have topological significance, are used for routing and forwarding of ILNP packets, but Locators are not used in upper-layer protocols.
ネットワーク層では、トポロジー上重要なロケーター値がILNPパケットのルーティングと転送に使用されますが、ロケーターは上位層プロトコルでは使用されません。
As well as the new namespaces, another significant difference in ILNP, as shown in Table 1, is that there is no binding of a routable name to an interface, or Sub-Network Point of Attachment (SNPA), as there is in IP. The existence of such a binding in IP effectively binds transport protocol flows to a specific, single interface on a node. Also, applications that include IP Addresses in their application-layer session state effectively bind to a specific, single interface on a node [RFC2460] [RFC6724].
表1に示すように、新しい名前空間だけでなく、ILNPのもう1つの大きな違いは、ルーティング可能な名前がインターフェイスにバインドされていないこと、またはIPにあるようなサブネットワーク接続点（SNPA）がないことです。 IPにこのようなバインディングが存在すると、トランスポートプロトコルフローがノード上の特定の単一のインターフェースに効果的にバインドされます。また、アプリケーション層のセッション状態にIPアドレスを含むアプリケーションは、ノード上の特定の単一のインターフェースに効果的にバインドします[RFC2460] [RFC6724]。
In ILNP, dynamic bindings exist between Identifier values and associated Locator values, as well as between {Identifier, Locator} pairs and (physical or logical) interfaces on the node.
ILNPでは、識別子の値と関連付けられたロケーター値の間、および{Identifier、Locator}ペアとノード上の（物理的または論理的）インターフェースの間に動的バインディングが存在します。
This change enhances the Internet Architecture by adding crisp and clear semantics for the Identifier and for the Locator, removing the overloaded semantics of the IP Address [RFC1992] [RFC4984], by updating end-system protocols, but without requiring any router or backbone changes. In ILNP, the closest approximation to an IP Address is an I-L Vector (I-LV), which is a given binding between an Identifier and Locator pair, written as [I, L]. I-LVs are discussed in more detail below.
この変更は、エンドシステムプロトコルを更新することにより、IPアドレス[RFC1992] [RFC4984]の過負荷セマンティクスを削除し、ルーターやバックボーンの変更を必要とせずに、識別子とロケーターに明確で明確なセマンティクスを追加することにより、インターネットアーキテクチャを強化します。 。 ILNPでは、IPアドレスに最も近いのはI-Lベクトル（I-LV）です。これは、[I、L]と書かれた識別子とロケーターのペアの間の特定のバインディングです。 I-LVについては、以下で詳しく説明します。
Where, today, IP packets have:
現在、IPパケットには次のものが含まれています。
- Source IP Address, Destination IP Address
- 送信元IPアドレス、宛先IPアドレス
instead, ILNP packets have:
代わりに、ILNPパケットには以下が含まれます。
- source I-LV, destination I-LV
- ソースI-LV、宛先I-LV
However, it must be emphasised that the I-LV and the IP Address are *not* equivalent.
ただし、I-LVとIPアドレスは同等ではないことに注意してください。
With these naming enhancements, we will improve the Internet Architecture by adding explicit harmonised support for many functions, such as multihoming, mobility, and IPsec.
これらの名前の拡張により、マルチホーミング、モビリティ、IPsecなどの多くの機能に対する明示的な調和のとれたサポートを追加することにより、インターネットアーキテクチャを改善します。
ILNP places an explicit Locator and Identifier in the IP packet header, replacing the usual IP Address. Locators are tied to the topology of the network. They may change frequently, as the node or site changes its network connectivity. The node Identifier is normally much more static and remains constant throughout the life of a given transport-layer session, and frequently much longer. However, there are various options for Identifier values, as discussed in [RFC6741]. The way that I-LVs are encoded into packet headers is different for IPv4 and IPv6, as explained in [RFC6741].
ILNPは、IPパケットヘッダーに明示的なロケーターと識別子を配置し、通常のIPアドレスを置き換えます。ロケーターはネットワークのトポロジーに関連付けられています。ノードまたはサイトのネットワーク接続が変更されると、それらは頻繁に変更される可能性があります。ノード識別子は通常、はるかに静的であり、特定のトランスポート層セッションの存続期間を通じて一定であり、多くの場合はずっと長くなります。ただし、[RFC6741]で説明されているように、識別子の値にはさまざまなオプションがあります。 [RFC6741]で説明されているように、IPv4とIPv6では、I-LVがパケットヘッダーにエンコードされる方法が異なります。
Identifiers and Locators for hosts are advertised explicitly in DNS, through the use of new Resource Records (RRs). This is a logical and reasonable use of DNS, completely analogous to the capability that DNS provides today. At present, among other current uses, the DNS is used to map from an FQDN to a set of addresses. As ILNP replaces IP Addresses with Identifiers and Locators, it is then clearly rational to use the DNS to map an FQDN to a set of Identifiers and a set of Locators for a node.
ホストの識別子とロケーターは、新しいリソースレコード（RR）を使用して、DNSで明示的にアドバタイズされます。これはDNSの論理的かつ合理的な使用法であり、DNSが今日提供する機能に完全に類似しています。現在、他の現在の用途の中で、DNSはFQDNからアドレスのセットへのマッピングに使用されています。 ILNPはIPアドレスを識別子とロケーターに置き換えるため、DNSを使用してFQDNをノードの識別子のセットとロケーターのセットにマップすることは明らかに合理的です。
The presence of ILNP Locators and Identifiers in the DNS for a DNS owner name is an indicator to correspondents that the correspondents can try to establish an ILNP-based transport-layer session with that DNS owner name.
DNS所有者名のDNSにILNPロケーターと識別子が存在することは、通信相手がそのDNS所有者名を使用してILNPベースのトランスポート層セッションを確立しようとすることができることを示す、通信相手の指標です。
Specifically in response to [RFC4984], ILNP improves routing scalability by helping multihomed sites operate effectively with Provider Aggregated (PA) address prefixes. Many multihomed sites today request provider-independent (PI) address prefixes so they can provide session survivability despite the failure of one or more access links or Internet Service Providers (ISPs). ILNP provides this transport-layer session survivability by having a provider-independent Node Identifier (NID) value that is free of any topological semantics. This NID value can be bound dynamically to a Provider Aggregated Locator (L) value, the latter being a topological name, i.e., a PA network prefix. By allowing correspondents to change arbitrarily among multiple PA Locator values, survivability is enabled as changes to the L values need not disrupt transport-layer sessions. In turn, this allows an ILNP multihomed site to have both the full transport-layer and full network-layer session resilience that is today offered by PI addressing while using the equivalent of PA addressing. In turn, this eliminates the current need to use globally visible PI routing prefixes for each multihomed site.
特に[RFC4984]に対応して、ILNPはマルチホームサイトがプロバイダー集約（PA）アドレスプレフィックスで効果的に動作するのを支援することにより、ルーティングのスケーラビリティを向上させます。今日のマルチホームサイトの多くは、プロバイダーに依存しない（PI）アドレスプレフィックスを要求しているため、1つ以上のアクセスリンクまたはインターネットサービスプロバイダー（ISP）に障害が発生しても、セッションの存続可能性を提供できます。 ILNPは、トポロジーセマンティクスのないプロバイダーに依存しないノード識別子（NID）値を持つことにより、このトランスポート層セッションの存続可能性を提供します。このNID値は、プロバイダー集約ロケーター（L）値に動的にバインドできます。後者はトポロジー名、つまりPAネットワークプレフィックスです。通信相手が複数のPAロケーター値の間で任意に変更できるようにすることで、L値の変更がトランスポート層セッションを中断する必要がないため、存続可能性が有効になります。これにより、ILNPマルチホームサイトは、PAアドレッシングと同等の機能を使用しながら、PIアドレッシングによって現在提供されている完全なトランスポートレイヤーと完全なネットワークレイヤーの両方のセッション回復力を持つことができます。次に、これにより、マルチホームサイトごとにグローバルに表示されるPIルーティングプレフィックスを使用する必要がなくなります。
To improve clarity and readability of the several ILNP specification documents, this section defines the terms "network-layer session" and "transport-layer session" both for IP-based networks and ILNP-based networks.
いくつかのILNP仕様ドキュメントの明確さと読みやすさを向上させるために、このセクションでは、IPベースのネットワークとILNPベースのネットワークの両方について、「ネットワーク層セッション」と「トランスポート層セッション」という用語を定義します。
Today, network-layer IP sessions have 2 components:
現在、ネットワーク層IPセッションには2つのコンポーネントがあります。
- Source IP Address (A_S) - Destination IP Address (A_D)
- 送信元IPアドレス（A_S）-宛先IPアドレス（A_D）
For example, a tuple for an IP layer session would be:
たとえば、IPレイヤーセッションのタプルは次のようになります。
<IP: A_S, A_D>
Instead, network-layer ILNP sessions have 4 components:
代わりに、ネットワーク層ILNPセッションには4つのコンポーネントがあります。
- Source Locator(s) (L_S) - Source Identifier(s) (I_S) - Destination Locator(s) (L_D) - Destination Identifier(s) (L_S)
- ソースロケータ（L_S）-ソース識別子（I_S）-デスティネーションロケータ（L_D）-デスティネーション識別子（L_S）
and a tuple for an ILNP session would be:
ILNPセッションのタプルは次のようになります。
<ILNP: I_S, L_S, I_D, L_D>
The phrase "ILNP session" refers to an ILNP-based network-layer session, having the 4 components in the definition above.
「ILNPセッション」という語句は、ILNPベースのネットワーク層セッションを指し、上記の定義に4つのコンポーネントがあります。
For engineering efficiency, multiple transport-layer sessions between a pair of ILNP correspondents normally share a single ILNP session (I-LV pairs and associated Nonce values). Also, for engineering convenience (and to cope with situation where different nodes, at different locations, might use the same I values), in the specific implementation of ILNPv6 and ILNPv4, we define the use of nonce values:
エンジニアリング効率を高めるために、通常、ILNP対応者のペア間の複数のトランスポート層セッションは、単一のILNPセッション（I-LVペアと関連するナンス値）を共有します。また、エンジニアリングの便宜のため（および異なる場所にある異なるノードが同じI値を使用する可能性がある状況に対処するため）、ILNPv6とILNPv4の特定の実装では、ナンス値の使用を定義します。
- Source-to-destination Nonce value (N_S) - Destination-to-source Nonce value (N_D)
- ソースから宛先へのノンス値（N_S）-ターゲットからソースへのノンス値（N_D）
These are explained in more detail in [RFC6741], with [RFC6744] for ILNPv6 and [RFC6746] for ILNPv4.
これらは[RFC6741]でより詳細に説明されており、ILNPv6の場合は[RFC6744]、ILNPv4の場合は[RFC6746]です。
Today, transport-layer sessions using IP include these 5 components:
現在、IPを使用するトランスポート層セッションには、次の5つのコンポーネントが含まれています。
- Source IP Address (A_S) - Destination IP Address (A_D) - Transport-layer protocol (e.g., UDP, TCP, SCTP) - Source transport-layer port number (P_S) - Destination transport-layer port number (P_D)
- ソースIPアドレス（A_S）-宛先IPアドレス（A_D）-トランスポート層プロトコル（UDP、TCP、SCTPなど）-ソーストランスポート層ポート番号（P_S）-宛先トランスポート層ポート番号（P_D）
For example, a TCP tuple would be:
たとえば、TCPタプルは次のようになります。
<TCP: P_S, P_D, A_S, A_D>
Instead, transport-layer sessions using ILNP include these 5 components:
代わりに、ILNPを使用するトランスポート層セッションには、次の5つのコンポーネントが含まれます。
- Source Identifier (I_S) - Destination Identifier (I_D) - Transport-layer protocol (e.g., UDP, TCP, SCTP) - Source transport-layer port number (P_S) - Destination transport-layer port number (P_D) and an example tuple:
-ソース識別子（I_S）-宛先識別子（I_D）-トランスポート層プロトコル（UDP、TCP、SCTPなど）-ソーストランスポート層ポート番号（P_S）-宛先トランスポート層ポート番号（P_D）およびタプルの例：
<TCP: P_S, P_D, I_S, I_D>
While we seek to make significant enhancements to the current Internet Architecture, we also wish to ensure that instantiations of ILNP are:
現在のインターネットアーキテクチャを大幅に強化することを目指していますが、ILNPのインスタンス化が次のようになっていることも確認します。
a) Backwards compatible: implementations of ILNP should be able to work with existing IPv6 or IPv4 deployments, without requiring application changes.
a) 下位互換性：ILNPの実装は、アプリケーションの変更を必要とせずに、既存のIPv6またはIPv4デプロイメントで機能する必要があります。
b) Incrementally deployable: to deploy an implementation of ILNP, changes to the network nodes should only be for those nodes that choose to use ILNP. The use of ILNP by some nodes does not require other nodes (that do not use ILNP) to be upgraded.
b) 段階的に展開可能：ILNPの実装を展開するには、ネットワークノードへの変更は、ILNPの使用を選択したノードに対してのみ行う必要があります。一部のノードでILNPを使用する場合、他のノード（ILNPを使用しない）をアップグレードする必要はありません。
In this section, we describe the key changes that are made to the current Internet Architecture. These key changes impact end-systems, rather than routers.
このセクションでは、現在のインターネットアーキテクチャに加えられた主要な変更について説明します。これらの重要な変更は、ルーターではなくエンドシステムに影響を与えます。
Identifiers, also called Node Identifiers (NIDs), are non-topological values that identify an ILNP node. A node might be a physical node or a virtual node. For example, a single physical device might contain multiple independent virtual nodes. Alternately, a single virtual device might be composed from multiple physical devices. In the case of a Multi-Level Secure (MLS) system [DIA] [DoD85] [DoD87] [RFC5570], each valid Sensitivity Label of that system might be a separate virtual node.
識別子はノード識別子（NID）とも呼ばれ、ILNPノードを識別する非トポロジ値です。ノードは、物理ノードまたは仮想ノードです。たとえば、単一の物理デバイスに複数の独立した仮想ノードが含まれる場合があります。または、単一の仮想デバイスが複数の物理デバイスから構成される場合もあります。マルチレベルセキュア（MLS）システム[DIA] [DoD85] [DoD87] [RFC5570]の場合、そのシステムの有効な機密ラベルはそれぞれ個別の仮想ノードである可能性があります。
A node MAY have multiple Identifier values associated with it, which MAY be used concurrently.
ノードには複数の識別子の値が関連付けられている場合があり（MAY）、同時に使用される場合があります。
In normal operation, when a node is responding to a received ILNP packet that creates a new network-layer session, the correct NID value to use for that network-layer session with that correspondent node will be learned from the received ILNP packet.
通常の操作では、ノードが新しいネットワーク層セッションを作成する受信したILNPパケットに応答している場合、その対応するノードとのそのネットワーク層セッションに使用する正しいNID値は、受信したILNPパケットから学習されます。
In normal operation, when a node is initiating communication with a correspondent node, the correct I value to use for that session with that correspondent node will be learned either through the application-layer naming, through DNS name resolution, or through some alternative name resolution system. Another option is an application may be able to select different I values directly -- as Identifiers are visible above the network layer via the transport protocol.
通常の操作では、ノードがコレスポンデントノードとの通信を開始すると、そのコレスポンデントノードとのセッションに使用する正しいI値は、アプリケーション層の名前付け、DNS名前解決、または代替の名前解決のいずれかによって学習されますシステム。別のオプションは、アプリケーションがさまざまなI値を直接選択できる場合があることです。識別子はトランスポートプロトコルを介してネットワーク層の上に表示されるためです。
Once a Node Identifier (NID) value has been used to establish a transport-layer session, that Node Identifier value forms part of the end-to-end (invariant) transport-layer session state and so MUST remain fixed for the duration of that session. This means, for example, that throughout the duration of a given TCP session, the Source Node Identifier and Destination Node Identifier values will not change.
トランスポート層セッションを確立するためにノード識別子（NID）値が使用されると、そのノード識別子値はエンドツーエンド（不変）トランスポート層セッション状態の一部を形成するため、その期間中は固定したままにする必要があります。セッション。これは、たとえば、特定のTCPセッションの期間中、送信元ノード識別子と宛先ノード識別子の値が変化しないことを意味します。
In normal operation, a node will not change its set of valid Identifier values frequently. However, a node MAY change its set of valid Identifier values over time, for example, in an effort to provide identity obfuscation, while remaining subject to the architectural rule of the preceding paragraph. When a node has more than one Node Identifier value concurrently, the node might have multiple concurrent ILNP sessions with some correspondent node, in which case Node Identifier values MAY differ between the different concurrent ILNP sessions.
通常の操作では、ノードは有効な識別子の値のセットを頻繁に変更しません。ただし、ノードは、たとえば、前の段落のアーキテクチャのルールに従いながら、IDの難読化を提供するために、時間の経過とともに有効な識別子の値のセットを変更する場合があります。ノードに複数のノードID値が同時に存在する場合、ノードには対応するノードとの複数の同時ILNPセッションが存在する可能性があります。その場合、ノードID値は、異なる同時ILNPセッション間で異なる場合があります。
ILNP Identifiers have the same syntax as IPv6 interface identifiers [RFC4291], based on the EUI-64 format [IEEE-EUI], which helps with backwards compatibility. There is no semantic equivalent to an ILNP Identifier in IPv4 or IPv6 today.
ILNP識別子の構文は、EUI-64形式[IEEE-EUI]に基づくIPv6インターフェイス識別子[RFC4291]と同じであり、下位互換性に役立ちます。今日のIPv4またはIPv6には、ILNP IDに相当するセマンティックはありません。
The Modified EUI-64 syntax used by both ILNP Identifiers and IPv6 interface identifiers contains a bit indicating whether the value has global scope or local scope [IEEE-EUI] [RFC4291]. ILNP Identifiers have either global scope or local scope. If they have global scope, they SHOULD be globally unique.
ILNP IDとIPv6インターフェイスIDの両方で使用されるModified EUI-64構文には、値にグローバルスコープまたはローカルスコープがあるかどうかを示すビットが含まれています[IEEE-EUI] [RFC4291]。 ILNP識別子には、グローバルスコープまたはローカルスコープがあります。それらがグローバルスコープを持つ場合、それらはグローバルに一意である必要があります。
Regardless of whether an Identifier is global scope or local scope, an Identifier MUST be unique within the scope of a given Locator value to which it is bound for a given ILNP session or packet flow. As an example, with ILNPv6, the ordinary IPv6 Neighbour Discovery (ND) processes ensure that this is true, just as ND ensures that no two IPv6 nodes on the same IPv6 subnetwork have the same IPv6 address at the same time.
識別子がグローバルスコープであるかローカルスコープであるかに関係なく、識別子は、特定のILNPセッションまたはパケットフローにバインドされる特定のロケーター値のスコープ内で一意である必要があります。例として、ILNPv6では、通常のIPv6近隣探索（ND）プロセスはこれが真であることを保証します。これは、NDが同じIPv6サブネットワーク上の2つのIPv6ノードが同時に同じIPv6アドレスを持たないことを保証するのと同じです。
Both the IEEE EUI-64 specification and the Modified EUI-64 syntax also has a 'Group' bit [IEEE-EUI] [RFC4291]. For both ILNP node Identifiers and also IPv6 interface identifiers, this Group bit is set to 0.
IEEE EUI-64仕様とModified EUI-64構文の両方にも「グループ」ビットがあります[IEEE-EUI] [RFC4291]。 ILNPノード識別子とIPv6インターフェイス識別子の両方で、このグループビットは0に設定されます。
Unicast ILNP Identifier values name the node, rather than naming a specific interface on that node. So ILNP Identifiers have different semantics than IPv6 interface identifiers.
ユニキャストILNP識別子の値は、ノード上の特定のインターフェイスではなく、ノードに名前を付けます。そのため、ILNP識別子は、IPv6インターフェイス識別子とは異なるセマンティクスを持っています。
Locators are topologically significant names, analogous to (sub)network routing prefixes. The Locator names the IP subnetwork that a node is connected to. ILNP neither prohibits nor mandates in-transit modification of Locator values.
ロケーターはトポロジ的に重要な名前で、（サブ）ネットワークルーティングプレフィックスに類似しています。ロケーターは、ノードが接続されているIPサブネットワークに名前を付けます。 ILNPは、ロケーター値の移動中の変更を禁止または義務付けていません。
A host MAY have several Locators at the same time, for example, if it has a single network interface connected to multiple subnetworks (e.g., VLAN deployments on wired Ethernet) or has multiple interfaces each on a different subnetwork. Locator values normally have Locator Preference Indicator (LPI) values associated with them. These LPIs indicate that a specific Locator value has higher or lower preference for use at a given time. Local LPI values may be changed through local policy or via management interfaces. Remote LPI values are normally learned from the DNS, but the local copy of a remote LPI value might be modified by local policy relating to preferred paths or prefixes.
たとえば、ホストが複数のサブネットワークに接続されている単一のネットワークインターフェイス（たとえば、有線イーサネット上のVLAN展開）を持っている場合、またはそれぞれが異なるサブネットワーク上に複数のインターフェイスを持っている場合、ホストは同時に複数のロケーターを持つことができます（MAY）。ロケーター値には通常、ロケーター設定インジケーター（LPI）値が関連付けられています。これらのLPIは、特定のロケーター値が特定の時間に使用するための優先順位が高いまたは低いことを示しています。ローカルLPI値は、ローカルポリシーまたは管理インターフェイスを介して変更できます。リモートLPI値は通常DNSから学習されますが、リモートLPI値のローカルコピーは、優先パスまたはプレフィックスに関連するローカルポリシーによって変更される可能性があります。
Locator values are used only at the network layer. Locators are not used in end-to-end transport state. For example, Locators are not used in transport-layer session state or application-layer session state. However, this does not preclude an end-system setting up local dynamic bindings for a single transport flow to multiple Locator values concurrently.
ロケーター値は、ネットワーク層でのみ使用されます。ロケーターは、エンドツーエンドのトランスポート状態では使用されません。たとえば、ロケーターはトランスポート層セッション状態またはアプリケーション層セッション状態では使用されません。ただし、これは、複数のロケーター値への単一のトランスポートフローに対するローカル動的バインディングを同時にセットアップするエンドシステムを排除するものではありません。
The routing system only uses Locators, not Identifiers. For unicast traffic, ILNP uses longest-prefix match routing, just as the IP Internet does.
ルーティングシステムはロケーターのみを使用し、識別子は使用しません。ユニキャストトラフィックの場合、ILNPはIPインターネットと同じように最長プレフィックス一致ルーティングを使用します。
Section 4 below describes in more detail how Locators are used in forwarding and routing packets from a sending node on a source subnetwork to one or more receiving nodes on one or more destination subnetworks.
以下のセクション4では、送信元サブネットワークの送信ノードから1つ以上の宛先サブネットワークの1つ以上の受信ノードにパケットを転送およびルーティングする際にロケーターがどのように使用されるかについて詳しく説明します。
A difference from earlier proposals [GSE] [8+8] is that, in normal operation, the originating host supplies both Source Locator and Destination Locator values in the packets it sends out.
以前の提案[GSE] [8 + 8]との違いは、通常の操作では、発信元ホストが送信するパケットで送信元ロケーターと宛先ロケーターの両方の値を提供することです。
Section 4.3 describes packet forwarding in more detail, while Section 4.4 describes packet routing in more detail.
セクション4.3ではパケット転送について詳しく説明し、セクション4.4ではパケットルーティングについて詳しく説明します。
The ILNP architecture recognises that Locator values are topologically significant, so the set of Locator values associated with a node normally will need to change when the node's connectivity to the Internet topology changes. For example, a mobile or multihomed node is likely to have connectivity changes from time to time, along with the corresponding changes to the set of Locator values.
ILNPアーキテクチャは、ロケーター値がトポロジ的に重要であることを認識しているため、ノードに関連付けられているロケーター値のセットは、通常、ノードのインターネットトポロジへの接続が変更されたときに変更する必要があります。たとえば、モバイルノードまたはマルチホームノードでは、ロケーター値のセットに対する対応する変更と共に、接続が時々変更される可能性があります。
When a node using a specific set of Locator values changes one or more of those Locator values, then the node (1) needs to update its local knowledge of its own Locator values, (2) needs to inform all active Correspondent Nodes (CNs) of those changes to its set of Locator values so that ILNP session continuity is maintained, and (3) if it expects incoming connections the node also needs to update its Locator-related entries in the Domain Name System. [RFC6741] describes the engineering and implementation details of this process.
特定のロケーター値のセットを使用するノードがこれらのロケーター値の1つ以上を変更する場合、ノード（1）は自身のロケーター値のローカル情報を更新する必要があります、（2）すべてのアクティブな対応ノード（CN）に通知する必要がありますILNPセッションの継続性が維持されるように、ロケーター値のセットに対するこれらの変更のほか、（3）着信接続が予想される場合、ノードはドメインネームシステムのロケーター関連のエントリも更新する必要があります。 [RFC6741]は、このプロセスのエンジニアリングと実装の詳細を説明しています。
As Locator values can be dynamic, and they could change for a node during an ILNP session, correspondents need to be notified when a Locator value for a node changes for any existing ILNP session. To enable this, a node that sees its Locator values have changed MUST send a Locator Update (LU) message to its correspondent nodes. The details of this procedure are discussed in other ILNP documents -- [RFC6741], [RFC6743], and [RFC6745]. (The change in Locator values may also need to be notified to DNS but that is discussed elsewhere.)
ロケーター値は動的である可能性があり、ILNPセッション中にノードに対して変更される可能性があるため、ノードのロケーター値が既存のILNPセッションに対して変更されたときに、通信相手に通知する必要があります。これを有効にするには、ロケーター値が変更されたことを確認するノードが、対応するノードにロケーター更新（LU）メッセージを送信する必要があります。この手順の詳細は、他のILNPドキュメント-[RFC6741]、[RFC6743]、および[RFC6745]で説明されています。 （ロケーター値の変更もDNSに通知する必要があるかもしれませんが、それは他の場所で議論されます。）
ILNP Locators have the same syntax as an IP unicast routing prefix.
ILNPロケーターの構文は、IPユニキャストルーティングプレフィックスと同じです。
ILNP unicast Locators have the same semantics as an IP unicast routing prefix, since they name a specific subnetwork. ILNP neither prohibits nor requires in-transit modification of Locator values.
ILNPユニキャストロケーターは、特定のサブネットワークを指定するため、IPユニキャストルーティングプレフィックスと同じセマンティクスを持っています。 ILNPは、ロケーター値の移動中の変更を禁止も要求もしません。
Historically, an IP Address has been considered to be an atomic datum, even though it is recognised that an IP Address has an internal structure: the network prefix plus either the host ID (IPv4) or the interface identifier (IPv6). However, this internal structure has not been used in end-system protocols; instead, all the bits of the IP Address are used. (Additionally, in IPv4 the IPv4 subnet mask uses bits from the host ID, a further confusion of the structure, even thought it is an extremely useful engineering mechanism.)
歴史的に、IPアドレスは内部構造（ネットワークプレフィックスとホストID（IPv4）またはインターフェース識別子（IPv6）のいずれか）を持つことが認識されていても、IPアドレスはアトミックデータムと見なされてきました。ただし、この内部構造はエンドシステムプロトコルでは使用されていません。代わりに、IPアドレスのすべてのビットが使用されます。 （さらに、IPv4では、IPv4サブネットマスクはホストIDからのビットを使用します。これは、構造がさらに混乱しますが、非常に有用なエンジニアリングメカニズムであるとさえ考えられます。）
In ILNP, the IP Address is replaced by an "Identifier-Locator Vector" (I-LV). This consists of a pairing of an Identifier value and a Locator value for that packet, written as [I, L]. All ILNP packets have Source Identifier, Source Locator, Destination Identifier, and Destination Locator values. The I value of the I-LV is used by upper-layer protocols (e.g., TCP, UDP, SCTP), so needs to be immutable. Locators are not used by upper-layer protocols (e.g., TCP, UDP, SCTP). Instead, Locators are similar to IP routing prefixes, and are only used to name a specific subnetwork.
ILNPでは、IPアドレスは「Identifier-Locator Vector」（I-LV）に置き換えられます。これは、[I、L]と書かれた、そのパケットの識別子値とロケーター値のペアで構成されます。すべてのILNPパケットには、Source Identifier、Source Locator、Destination Identifier、およびDestination Locatorの値があります。 I-LVのI値は、上位層プロトコル（TCP、UDP、SCTPなど）で使用されるため、不変である必要があります。ロケーターは、上位層プロトコル（TCP、UDP、SCTPなど）では使用されません。代わりに、ロケーターはIPルーティングプレフィックスに似ており、特定のサブネットワークに名前を付けるためにのみ使用されます。
While it is possible to say that an I-LV is an approximation to an IP Address of today, it should be understood that an I-LV:
I-LVは今日のIPアドレスの近似値であると言うことはできますが、I-LVは次のことを理解する必要があります。
a) is not an atomic datum, being a pairing of two data types, an Identifier and a Locator.
a) はアトミックデータムではなく、識別子とロケーターの2つのデータ型のペアです。
b) has different semantics and properties to an IP Address, as is described in this document.
b) このドキュメントで説明されているように、IPアドレスに対するセマンティクスとプロパティは異なります。
In our discussion, it will be convenient sometimes to refer to an I-LV, but sometimes to refer only to an Identifier value, or only to a Locator value.
ここでの説明では、I-LVを参照する方が便利な場合がありますが、Identifier値のみ、またはLocator値のみを参照する場合もあります。
ILNP packets always contain a source I-LV and a destination I-LV.
ILNPパケットには、常に送信元I-LVと宛先I-LVが含まれています。
In describing how capabilities are implemented in ILNP, we will consider the differences in end-systems' state between IP and ILNP in order to highlight the architectural changes.
ILNPで機能がどのように実装されるかを説明する際に、アーキテクチャの変更を強調するために、IPとILNPの間のエンドシステムの状態の違いを考慮します。
We define a formal notation to represent the data contained in the transport-layer session state. We define:
トランスポート層セッション状態に含まれるデータを表す正式な表記法を定義します。以下を定義します：
A = IP Address I = Identifier L = Locator P = Transport-layer port number
A = IPアドレスI =識別子L =ロケーターP =トランスポート層ポート番号
To differentiate the local and remote values for the above items, we also use suffixes, for example:
上記の項目のローカル値とリモート値を区別するために、サフィックスも使用します。次に例を示します。
_L = local _R = remote
_L =ローカル_R =リモート
With IPv4 and IPv6 today, the invariant state at the transport-layer for TCP can be represented by the tagged tuple:
今日のIPv4とIPv6では、TCPのトランスポート層での不変状態はタグ付きタプルで表すことができます。
<TCP: A_L, A_R, P_L, P_R> --- (1)
Tag values that will be used are:
使用されるタグ値は次のとおりです。
IP Internet Protocol ILNP Identifier-Locator Network Protocol TCP Transmission Control Protocol UDP User Datagram Protocol
IPインターネットプロトコルILNP Identifier-LocatorネットワークプロトコルTCP伝送制御プロトコルUDPユーザーデータグラムプロトコル
So, for example, with IP, a UDP packet would have the tagged tuple:
したがって、たとえば、IPの場合、UDPパケットにはタグ付けされたタプルがあります。
<UDP: A_L, A_R, P_L, P_R> --- (2)
A TCP segment carried in an IP packet may be represented by the tagged tuple binding:
IPパケットで運ばれるTCPセグメントは、タグ付けされたタプルバインディングで表すことができます。
<TCP: A_L, A_R, P_L, P_R><IP: A_L, A_R> --- (3)
and a UDP packet would have the tagged tuple binding:
そしてUDPパケットはタグ付けされたタプルバインディングを持っています：
<UDP: A_L, A_R, P_L, P_R><IP: A_L, A_R> --- (4)
In ILNP, the transport-layer state for TCP is:
ILNPでは、TCPのトランスポート層の状態は次のとおりです。
<TCP: I_L, I_R, P_L, P_R> --- (5)
The binding for a TCP segment within an ILNP packet:
ILNPパケット内のTCPセグメントのバインディング：
<TCP: I_L, I_R, P_L, P_R><ILNP: L_L, L_R> --- (6)
When comparing tuple expressions (3) and (6), we see that for IP, any change to network addresses impacts the end-to-end state, but for ILNP, changes to Locator values do not impact end-to-end state. This provides end-system session state invariance, a key feature of ILNP compared to IP as it is used in some situations today. ILNP adopts the end-to-end approach for its architecture [SRC84]. As noted previously, nodes MAY have more than one Locator concurrently, and nodes MAY change their set of active Locator values as required.
タプル式（3）と（6）を比較すると、IPの場合、ネットワークアドレスの変更はエンドツーエンドの状態に影響しますが、ILNPの場合、ロケーター値の変更はエンドツーエンドの状態に影響しません。これは、エンドシステムのセッション状態の不変性を提供します。これは、現在の状況で使用されているIPと比較したILNPの主要な機能です。 ILNPは、そのアーキテクチャ[SRC84]にエンドツーエンドのアプローチを採用しています。前述のように、ノードは複数のロケーターを同時に持つことができ（MAY）、ノードは必要に応じてアクティブなロケーター値のセットを変更できます（MAY）。
While these documents do not include SCTP examples, the same notation can be used, simply substituting the string "SCTP" for the string "TCP" or the string "UDP" in the above examples.
これらのドキュメントにはSCTPの例が含まれていませんが、同じ表記法を使用できます。上記の例の文字列「TCP」または文字列「UDP」を文字列「SCTP」に置き換えるだけです。
In ILNP, protocols above the network layer do not use the Locator values. Thus, the transport layer uses only the I values for the transport-layer session state (e.g., TCP pseudo-header checksum, UDP pseudo-header checksum), as is shown, for example, in expression (6) above.
ILNPでは、ネットワーク層より上のプロトコルはロケーター値を使用しません。したがって、トランスポート層は、たとえば上記の式（6）に示すように、トランスポート層セッション状態（たとえば、TCP疑似ヘッダーチェックサム、UDP疑似ヘッダーチェックサム）のI値のみを使用します。
Additionally, from a practical perspective, while the I values are only used in protocols above the network layer, it is convenient for them to be carried in network packets, so that the namespace for the I values can be used by any transport-layer protocols operating above the common network layer.
さらに、実用的な観点から見ると、I値はネットワークレイヤーより上のプロトコルでのみ使用されますが、ネットワークパケットで運ぶのが便利です。そのため、I値の名前空間は、どのトランスポートレイヤープロトコルでも使用できます。共通ネットワーク層の上で動作します。
This document provides an architectural description of the core ILNP capabilities and functions. It is based around the use of example scenarios so that practical issues can be highlighted.
このドキュメントでは、ILNPのコア機能と機能のアーキテクチャについて説明します。これは、実際的な問題を強調できるように、シナリオ例の使用に基づいています。
In some cases, illustrative suggestions and light discussion are presented with respect to engineering issues, but detailed discussion of engineering issues are deferred to other ILNP documents.
場合によっては、エンジニアリングの問題に関して例示的な提案と軽い議論が提示されますが、エンジニアリングの問題の詳細な議論は他のILNPドキュメントに委ねられています。
The order of the examples presented below is intended to allow an incremental technical understanding of ILNP to be developed. There is no other reason for the ordering of the examples listed below.
以下に示す例の順序は、ILNPの技術的な理解を深めるためのものです。下記の例を注文する理由は他にありません。
Many of the descriptions are based on the use of an example site network as shown in Figure 3.1.
説明の多くは、図3.1に示すように、サンプルサイトネットワークの使用に基づいています。
site . . . . +----+
network . .-----+ CN |
. . . . +------+ link1 . . +----+
. . | +------. .
. D . | | . .
. .----+ SBR | . Internet .
. H . | | . .
. . | +------. .
. . . . +------+ link2 . .
. .
. . . .
CN = Correspondent Node D = Device H = Host SBR = Site Border Router
CN =対応するノードD =デバイスH =ホストSBR =サイト境界ルーター
Figure 3.1: A Simple Site Network for ILNP Examples
図3.1：ILNPの例の単純なサイトネットワーク
In some cases, hosts (H) or devices (D) act as end-systems within the site network, and communicate with (one or more) Correspondent Node (CN) instances that are beyond the site.
場合によっては、ホスト（H）またはデバイス（D）がサイトネットワーク内のエンドシステムとして機能し、サイト外にある（1つ以上の）対応ノード（CN）インスタンスと通信します。
Note that the figure is illustrative and presents a logical view. For example, the CN may itself be on a site network, just like H or D.
この図は例示であり、論理的なビューを示していることに注意してください。たとえば、CN自体がHまたはDのようにサイトネットワーク上にある場合があります。
Also, for formulating examples, we assume ILNPv6 is in use, which has the same packet header format (as viewed by routers) as IPv6, and can be seen as a superset of IPv6 capabilities.
また、例を定式化するために、IPv6と同じパケットヘッダー形式（ルーターから見た場合）を持ち、IPv6機能のスーパーセットとして見ることができるILNPv6が使用されていると想定しています。
For simplicity, we assume that name resolution is via the deployed DNS, which has been updated to store DNS records for ILNP [RFC6742].
わかりやすくするために、名前解決は、ILNP [RFC6742]のDNSレコードを格納するように更新されている、展開されたDNSを介して行われると想定しています。
Note that, from an engineering viewpoint, this does NOT mean that the DNS also has to be ILNP capable: existing IPv4 or IPv6 infrastructure can be used for DNS transport.
エンジニアリングの観点からは、これはDNSもILNP対応である必要があることを意味しないことに注意してください。既存のIPv4またはIPv6インフラストラクチャをDNSトランスポートに使用できます。
Multicast forwarding and routing are unchanged, in order to avoid requiring changes in deployed IP routers and routing protocols. ILNPv4 multicasting is the same as IETF Standards Track IPv4 multicasting [RFC1112] [RFC3376]. ILNPv6 multicasting is the same as IETF Standards Track IPv6 multicasting [RFC4291] [RFC2710] [RFC3810].
展開されたIPルーターとルーティングプロトコルの変更を必要としないようにするために、マルチキャスト転送とルーティングは変更されていません。 ILNPv4マルチキャストは、IETF標準トラックIPv4マルチキャスト[RFC1112] [RFC3376]と同じです。 ILNPv6マルチキャストは、IETF Standards Track IPv6マルチキャスト[RFC4291] [RFC2710] [RFC3810]と同じです。
In this section, we describe basic packet forwarding and routing in ILNP. We highlight areas where it is similar to current IP, and also where it is different from current IP. We use examples in order to illustrate the intent and show the feasibility of the approach.
このセクションでは、ILNPでの基本的なパケット転送とルーティングについて説明します。現在のIPと類似している領域と、現在のIPとは異なる領域を強調表示します。例を使用して、意図を説明し、アプローチの実現可能性を示します。
For this section, in Figure 4.1, H is a fixed host in a simple site network, and CN is a remote Correspondent Node outside the site; H and CN are ILNP-capable, while the Site Border Router (SBR) does not need to be ILNP-capable.
このセクションの図4.1では、Hは単純なサイトネットワーク内の固定ホストであり、CNはサイト外のリモートコレスポンデントノードです。 HおよびCNはILNP対応ですが、Site Border Router（SBR）はILNP対応である必要はありません。
site . . . . +----+
network . .-----+ CN |
. . . . +------+ . . +----+
. . | +------. .
. . | | . .
. .----+ SBR | . Internet .
. H . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
CN = Correspondent Node H = Host SBR = Site Border Router
CN =対応するノードH =ホストSBR =サイト境界ルーター
Figure 4.1: A Simple Site Network for ILNP Examples
図4.1：ILNPの例の単純なサイトネットワーク
This section uses the term "address management", in recognition of the analogy with capabilities present in IP today. In this document, address management is about enabling hosts to attach to a subnetwork and enabling network-layer communication between and among hosts, also including:
このセクションでは、今日のIPに存在する機能との類似性を認識して、「アドレス管理」という用語を使用します。このドキュメントでは、アドレス管理とは、ホストがサブネットワークに接続できるようにし、ホスト間のネットワークレイヤー通信を有効にすることです。
a) enabling identification of a node within a site. b) allowing basic routing/forwarding from a node acting as an end-system.
a) サイト内のノードの識別を可能にします。 b）エンドシステムとして機能するノードからの基本的なルーティング/転送を可能にする。
If we consider Figure 4.1, imagine that host H has been connected to the site network. Administratively, it needs at least one I value and one L value in order to be able to communicate.
図4.1を検討する場合、ホストHがサイトネットワークに接続されていることを想像してください。管理上、通信するには、少なくとも1つのI値と1つのL値が必要です。
Today, local administrative procedures allocate IP Addresses, often using various protocol mechanisms (e.g., NETCONF-based router configuration, DHCP for IPv4, DHCP for IPv6, IPv6 Router Advertisements). Similarly, local administrative procedures can allocate I and L values as required, e.g., I_H and L_H. This may be through manual configuration.
今日、ローカル管理手順では、多くの場合、さまざまなプロトコルメカニズム（NETCONFベースのルーター構成、IPv4のDHCP、IPv6のDHCP、IPv6ルーターアドバタイズメントなど）を使用してIPアドレスを割り当てています。同様に、ローカル管理手順では、必要に応じてI値とL値を割り当てることができます（I_HやL_Hなど）。これは、手動構成による場合があります。
Additionally, if it is expected or desired that H might have incoming communication requests, e.g., it is a server, then the values I_H and L_H can be added to the relevant name services (e.g., DNS, NIS/YP), so that FQDN lookups for H resolve to the appropriate DNS resource records (e.g., NID, L32, L64, and LP [RFC6742]) for node H.
さらに、Hがサーバーなどの着信通信要求を持つことが予想または望まれる場合は、値I_HおよびL_Hを関連するネームサービス（DNS、NIS / YPなど）に追加して、FQDNをHのルックアップは、ノードHの適切なDNSリソースレコード（NID、L32、L64、LP [RFC6742]など）に解決されます。
From a network operations perspective, this whole process also can be automated. As an example, consider that in Figure 3.1 the Site Border Router (SBR) is an IPv6-capable router and is connected via link1 to an ISP that supports IPv6. The SBR will have been allocated one (or more) IPv6 prefixes that it will multicast using IPv6 Routing Advertisements (RAs) into the site network, e.g., prefix L_1. L_1 is actually a local IPv6 prefix (/64), which is formed from an address assignment by the upstream ISP, according to [RFC3177] or [RFC6177]. Host H will see these RAs, for example, on its local interface with name eth0, will be able to use that prefix as a Locator value, and will cache that Locator value locally.
ネットワーク運用の観点からは、このプロセス全体を自動化することもできます。例として、図3.1のサイトボーダールーター（SBR）がIPv6対応ルーターであり、link1を介してIPv6をサポートするISPに接続されていることを考慮してください。 SBRには、IPv6ルーティングアドバタイズ（RA）を使用してサイトネットワークにマルチキャストする1つ（または複数）のIPv6プレフィックスが割り当てられます（プレフィックスL_1など）。 [RFC3177]または[RFC6177]によれば、L_1は実際にはローカルIPv6プレフィックス（/ 64）であり、上流のISPによるアドレス割り当てから形成されます。ホストHは、たとえばeth0という名前のローカルインターフェイスでこれらのRAを確認し、そのプレフィックスをLocator値として使用でき、そのLocator値をローカルにキャッシュします。
Also, node H can use the mechanism documented in either Section 2.5.1 of [RFC4291], in [RFC3972], [RFC4581], [RFC4982], or in [RFC4941] in order to create a default I value (say, I_H), just as an IPv6 host can. For DNS, the I_H and L_1 values may be pre-configured in DNS by an administrator who already has knowledge of these, or added to DNS by H using Secure DNS Dynamic Update [RFC3007] to add or update the correct NID and L64 records to DNS for the FQDN for H.
また、ノードHは、[RFC4291]のセクション2.5.1、[RFC3972]、[RFC4581]、[RFC4982]、または[RFC4941]に記載されているメカニズムを使用して、デフォルトのI値（たとえば、I_H）を作成できます。 ）、IPv6ホストと同じように。 DNSの場合、I_HおよびL_1の値は、これらの知識をすでに持っている管理者がDNSで事前設定するか、HがセキュアDNS動的更新[RFC3007]を使用してDNSに追加し、正しいNIDおよびL64レコードをHのFQDNのDNS。
For the purposes of explaining the concept of operations, we talk of a local I-L Communication Cache (ILCC). This is an engineering convenience and does not form part of the ILNP architecture, but is used in our examples. More details on the ILCC can be found in [RFC6741]. The ILCC contains information that is required for the operation of ILNP. This will include, amongst other things, the current set of valid Identifier and Locator values in use by a node, the bindings between them, and the bindings between Locator values and interfaces.
操作の概念を説明する目的で、ローカルI-L通信キャッシュ（ILCC）について説明します。これはエンジニアリングの便宜であり、ILNPアーキテクチャの一部ではありませんが、例で使用されています。 ILCCの詳細については、[RFC6741]を参照してください。 ILCCには、ILNPの運用に必要な情報が含まれています。これには、とりわけ、ノードで使用されている有効な識別子とロケーターの現在のセット、それらの間のバインディング、およびロケーター値とインターフェースの間のバインディングが含まれます。
When the SBR needs to send a packet to H, it uses local address resolution mechanisms to discover the bindings between interface addresses and currently active I-LVs for H. For our example of Figure 3.1, IPv6 Neighbour Discovery (ND) can be used without modification, as the I-LV for ILNPv6 occupies the same bits as the IPv6 address in the IPv6 header. For packets from H to SBR, the same basic mechanism applies, as long as SBR supports IPv6 and even if it is not ILNPv6-capable, as IPv6 ND is used unmodified for ILNPv6.
SBRはパケットをHに送信する必要がある場合、ローカルアドレス解決メカニズムを使用して、インターフェイスアドレスとHの現在アクティブなI-LV間のバインディングを検出します。図3.1の例では、IPv6近隣探索（ND）を使用せずに使用できます。 ILNPv6のI-LVがIPv6ヘッダーのIPv6アドレスと同じビットを占有するため、変更。 HBRからSBRへのパケットの場合、IPv6 NDがILNPv6に対して変更されずに使用されるため、SBRがIPv6をサポートし、ILNPv6対応でない場合でも、同じ基本メカニズムが適用されます。
For Figure 3.1, assuming:
図3.1の場合：
- SBR advertises prefix L_1 locally, uses I value I_S, and has an Ethernet MAC address M_S on interface with local name sbr0
- SBRはプレフィックスL_1をローカルにアドバタイズし、I値I_Sを使用し、ローカル名sbr0のインターフェイスにイーサネットMACアドレスM_Sを持っています
- H uses I value I_H, and has an Ethernet MAC address of M_H on the interface with local name eth0
- HはI値I_Hを使用し、ローカル名eth0のインターフェース上にM_HのイーサネットMACアドレスを持っています
then H will have in its ILCC:
その後、HはILCCに次のようにいます。
[I_H, L_1] --- (7a)
L_1, eth0 --- (7b)
After the IPv6 RA and ND mechanism has executed, the ILCC at H would contain, as well as expressions (7a) and (7b), the following entry for SBR:
IPv6 RAおよびNDメカニズムが実行された後、HのILCCには、式（7a）および（7b）に加えて、SBRの次のエントリが含まれます。
[I_S, L_1], M_S --- (8)
For ILNPv6, it does not matter that the SBR is not ILNPv6-capable, as the I-LV [I_S, L_1] is physically equivalent to the IPv6 address for the internal interface sbr0.
ILNPv6の場合、I-LV [I_S、L_1]は内部インターフェイスsbr0のIPv6アドレスと物理的に同等であるため、SBRがILNPv6対応でないことは問題ではありません。
At SBR, which is not ILNP-capable, there would be the following entries in its local cache and configuration:
ILNPに対応していないSBRでは、ローカルキャッシュと構成に次のエントリがあります。
L_1:I_S --- (9a)
L_1, sbr0 --- (9b)
Expression (9a) represents a valid IPv6 ND entry: in this case, the I_S value (which is 64 bits in ILNPv6) and the L_1 values are, effectively, concatenated and treated as if they were a single IPv6 address. Expression (9b) binds transmissions for L_1 to interface sbr0. (Again, sbr0 is a local, implementation-specific name, and such a binding is possible with standard tools today, for example, ifconfig(8).)
式（9a）は有効なIPv6 NDエントリを表します。この場合、I_S値（ILNPv6では64ビット）とL_1値は、実質的に連結され、1つのIPv6アドレスであるかのように扱われます。式（9b）は、L_1の送信をインターフェースsbr0にバインドします。 （ここでも、sbr0はローカルの実装固有の名前であり、そのようなバインディングは、現在の標準ツール、たとえばifconfig（8）で可能です。）
If we assume that host H is configured as in the previous section, it is now ready to send and receive ILNP packets.
ホストHが前のセクションのように構成されていると想定すると、ILNPパケットを送受信する準備ができています。
Let us assume that, for Figure 4.1, it wishes to contact the node CN, which has FQDN cn.example.com and is ILNP-capable. A DNS query by H for cn.example.com will result in NID and L64 records for CN, with values I_CN and L_CN, respectively, being returned to H and stored in its ILCC:
図4.1の場合、FQDN cn.example.comを持ち、ILNP対応のノードCNに接続したいとします。 cn.example.comに対するHによるDNSクエリの結果、CNのNIDおよびL64レコードが生成され、それぞれI_CNおよびL_CNの値がHに返され、ILCCに格納されます。
[I_CN, L_CN] --- (10)
This will be considered active as long as the TTL values for the DNS records are valid. If the TTL for an I or L value is zero, then the value is still usable but becomes stale as soon as it has been used once. However, it is more likely that the TTL value will be greater than zero [BA11] [SBK01].
これは、DNSレコードのTTL値が有効である限り、アクティブと見なされます。 IまたはL値のTTLがゼロの場合、値は引き続き使用できますが、一度使用されるとすぐに古くなります。ただし、TTL値がゼロより大きい可能性が高くなります[BA11] [SBK01]。
Once the CN's I value is known, the upper-layer protocol, e.g., the transport protocol, can set up suitable transport-layer session state:
CNのI値がわかると、トランスポートプロトコルなどの上位層プロトコルは、適切なトランスポート層セッション状態を設定できます。
<UDP: I_H, I_CN, P_H, P_CN> --- (11)
For routing of ILNP packets, the destination L value in an ILNPv6 packet header is semantically equivalent to a routing prefix. So, once a packet has been forwarded from a host to its first-hop router, only the destination L value needs to be used for getting the packet to the destination network. Once the packet has arrived at the router for the site network, local mechanisms and the packet-forwarding mechanism, as described above in Section 4.3, allow the packet to be delivered to the host.
ILNPパケットのルーティングでは、ILNPv6パケットヘッダーの宛先L値はルーティングプレフィックスと意味的に同等です。したがって、パケットがホストからその最初のホップのルーターに転送されると、宛先L値のみを使用して、パケットを宛先ネットワークに到達させることができます。パケットがサイトネットワークのルーターに到達すると、セクション4.3で説明したローカルメカニズムとパケット転送メカニズムにより、パケットがホストに配信されます。
For our example of Figure 4.1, H will send a UDP packet over ILNP as:
図4.1の例では、HはILNPを介してUDPパケットを次のように送信します。
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (12a)
and CN will send UDP packets to H as:
CNはUDPパケットを次のようにHに送信します。
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1> --- (12b)
The I value for H used in the transport-layer state (I_H in expression (12a)) selects the correct L value (L_1 in this case) from the bindings in the ILCC (expression (7a)), and that, in turn, selects the correct interface from the ILCC (expression (7b)), as described in Section 4.2. This gets the packet to the first hop router; beyond that, the ILNPv6 packet is treated as if it were an IPv6 packet.
トランスポート層の状態で使用されるHのI値（式（12a）のI_H）は、ILCC（式（7a））のバインディングから正しいL値（この場合はL_1）を選択します。セクション4.2で説明されているように、ILCC（式（7b））から正しいインターフェースを選択します。これにより、パケットが最初のホップのルーターに送られます。それを超えると、ILNPv6パケットはIPv6パケットであるかのように扱われます。
For multihoming, there are three cases to consider:
マルチホーミングの場合、考慮すべき3つのケースがあります。
a) Host Multihoming (H-MH): a single host is, individually, connected to multiple upstream links, via separate routing paths, and those multiple paths are used by that host as it wishes. That is, use of multiple upstream links is managed by the single host itself. For example, the host might have multiple valid Locator values on a single interface, with each Locator value being associated with a different upstream link (provider).
a) ホストマルチホーミング（H-MH）：単一のホストは、個別に、個別のルーティングパスを介して複数のアップストリームリンクに接続され、それらの複数のパスは、必要に応じてそのホストによって使用されます。つまり、複数のアップストリームリンクの使用は、単一のホスト自体によって管理されます。たとえば、ホストの単一のインターフェイスに複数の有効なLocator値があり、各Locator値が異なるアップストリームリンク（プロバイダー）に関連付けられている場合があります。
b) Multi-Path Transport (MTP): This is similar to using ILNP's support for host multihoming (i.e., H-MH), so we describe multi-path transport here. (Indeed, for ILNP, this can be considered a special case of H-MH.)
b) マルチパストランスポート（MTP）：これはILNPのホストマルチホーミング（つまり、H-MH）のサポートを使用するのと似ているため、ここではマルチパストランスポートについて説明します。 （実際、ILNPの場合、これはH-MHの特殊なケースと見なすことができます。）
c) Site Multihoming (S-MH): a site network is connected to multiple upstream links via separate routing paths, and hosts on the site are not necessarily aware of the multiple upstream paths. That is, the multiple upstream paths are managed, typically, through a site border router, or via the providers.
c) サイトマルチホーミング（S-MH）：サイトネットワークは別々のルーティングパスを介して複数のアップストリームリンクに接続されており、サイト上のホストは複数のアップストリームパスを認識しているとは限りません。つまり、複数のアップストリームパスは、通常、サイト境界ルーターを介して、またはプロバイダーを介して管理されます。
Essentially, for ILNP, multihoming is implemented by enabling:
基本的に、ILNPでは、マルチホーミングは以下を有効にすることで実装されます。
a) multiple Locator values to be used simultaneously by a node
a) ノードで同時に使用される複数のロケーター値
b) dynamic, simultaneous binding between one (or more) Identifier value(s) and multiple Locator values
b) 1つ（または複数）の識別子値と複数のロケーター値の間の動的な同時バインディング
With respect to the requirements for hosts [RFC1122], the multihoming function provided by ILNP is very flexible. It is not useful to discuss ILNP multihoming strictly within the confines of the exposition presented in Section 3.3.4 of [RFC1122], as that text is couched in terms of relationships between IP Addresses and interfaces, which can be dynamic in ILNP. The closest relationship between ILNP multihoming and [RFC1122] would be that certainly ILNP could support the notion of "Multiple Logical Networks", "Multiple Logical Hosts", and "Simple Multihoming".
ホストの要件[RFC1122]に関して、ILNPが提供するマルチホーミング機能は非常に柔軟です。 [RFC1122]のセクション3.3.4で説明されている説明の範囲内でILNPマルチホーミングについて厳密に説明することは有用ではありません。そのテキストは、IPアドレスとILNPで動的である可能性のあるインターフェース間の関係の観点から説明されているためです。 ILNPマルチホーミングと[RFC1122]の間の最も近い関係は、ILNPが「マルチ論理ネットワーク」、「マルチ論理ホスト」、および「シンプルマルチホーミング」の概念を確実にサポートできることです。
At present, host multihoming is not common in the deployed Internet. When TCP or UDP are in use with an IP-based network-layer session, host multihoming cannot provide session resilience, because the transport protocol's pseudo-header checksum binds the transport-layer session to a single IP Address of the multihomed node, and hence to a single interface of that node. SCTP has a protocol-specific mechanism to support node multihoming; SCTP can support session resilience both at present and also without change in the proposed approach [RFC5061].
現在、ホストマルチホーミングは展開されたインターネットでは一般的ではありません。 TCPまたはUDPがIPベースのネットワーク層セッションで使用されている場合、トランスポートプロトコルの疑似ヘッダーチェックサムがトランスポート層セッションをマルチホームノードの単一のIPアドレスにバインドするため、ホストマルチホーミングはセッションの復元力を提供できません。そのノードの単一のインターフェースに。 SCTPには、ノードのマルチホーミングをサポートするプロトコル固有のメカニズムがあります。 SCTPは、現在および提案されたアプローチ[RFC5061]を変更することなく、セッションの回復力をサポートできます。
Host multihoming in ILNP is supported directly in each host by ILNP. The simplest explanation of H-MH for ILNP is that an ILNP-capable host can simultaneously use multiple Locator values, for example, by having a binding between an I value and two different L values, e.g., the ILCC may contain the I-LVs:
ILNPのホストマルチホーミングは、ILNPによって各ホストで直接サポートされます。 ILNPのH-MHの最も簡単な説明は、ILNP対応ホストが複数のロケーター値を同時に使用できることです。たとえば、I値と2つの異なるL値の間のバインディングを使用すると、ILCCにI-LVが含まれる場合があります。 ：
[I_1, L_1] --- (14a)
[I_1, L_2] --- (14b)
Additionally, a host may use several I values concurrently, e.g., the ILCC may contain the I-LVs:
さらに、ホストは複数のI値を同時に使用する場合があります。たとえば、ILCCにはI-LVが含まれる場合があります。
[I_1, L_1] --- (15a)
[I_1, L_2] --- (15b)
[I_2, L_2] --- (15c)
[I_3, L_1] --- (15d)
Architecturally, ILNP considers these all to be cases of multihoming: the host is connected to more than one subnetwork, each subnetwork being named by a different Locator value.
構造上、ILNPはこれらすべてをマルチホーミングの場合と見なします。ホストは複数のサブネットワークに接続され、各サブネットワークは異なるロケーター値によって名前が付けられます。
In the cases above, the selection of which I-LV to use would be through local policy or through management mechanisms. Additionally, suitably modified transport-layer protocols, such as multi-path transport-layer protocol implementations, may make use of multiple I-LVs. Note that in such a case, the way in which multiple I-LVs are used would be under the control of the higher-layer protocol.
上記の場合、使用するI-LVの選択は、ローカルポリシーまたは管理メカニズムによって行われます。さらに、マルチパストランスポート層プロトコルの実装など、適切に変更されたトランスポート層プロトコルは、複数のI-LVを利用できます。このような場合、複数のI-LVが使用される方法は、上位層プロトコルの制御下にあることに注意してください。
Recall, however, that L values also have preference -- LPI values -- and these LPI values can be used at the network layer, or by a transport-layer protocol implementation, in order make use of L values in a specific manner.
ただし、L値には優先順位（LPI値）もあります。これらのLPI値は、特定の方法でL値を使用するために、ネットワーク層で、またはトランスポート層プロトコルの実装で使用できます。
Note that, from a practical perspective, ILNP dynamically binds L values to interfaces on a node to indicate the SNPA for that L value, so the multihoming is very flexible: a node could have a single interface and have multiple L values bound to that interface. For example, for expressions (14a) and (14b), if the end-system has a single interface with local name eth0, then the entries in the ILCC will be:
実用的な観点から、ILNPはL値をノード上のインターフェースに動的にバインドして、そのL値のSNPAを示すため、マルチホーミングは非常に柔軟であることに注意してください。ノードには単一のインターフェースがあり、そのインターフェースにバインドされた複数のL値を持つことができます。 。たとえば、式（14a）および（14b）の場合、エンドシステムにローカル名eth0の単一のインターフェースがある場合、ILCCのエントリは次のようになります。
L_1, eth0 --- (16a)
L_2, eth0 --- (16b)
And, if we assume that for expressions (15a-c) the end-system has two interfaces, eth0 and eth1, then these ILCC entries are possible:
また、式（15a-c）について、エンドシステムにeth0とeth1の2つのインターフェイスがあると仮定すると、これらのILCCエントリが可能です。
L_1, eth0 --- (17a)
L_2, eth1 --- (17b)
Let us consider the network in Figure 5.1.
図5.1のネットワークについて考えてみましょう。
site . . . .
network . .
. . . . +------+ L_1 . .
. . | +------. .
. . | | . .
. .----+ SBR | . Internet .
. . | | . .
. H . | +------. .
. . . . +------+ L_2 . .
. .
. . . .
L_1 = global Locator value 1 L_2 = global Locator value 2 SBR = Site Border Router
L_1 =グローバルロケーター値1 L_2 =グローバルロケーター値2 SBR =サイト境界ルーター
Figure 5.1: A Simple Multihoming Scenario for ILNP
図5.1：ILNPの単純なマルチホーミングシナリオ
We assume that H has a single interface, eth0. SBR will advertise L_1 and L_2 internally to the site. Host H will configure these as both reachable via its single interface, eth0, by using ILCC entries as in expressions (16a) and (16b). When packets from H that are to egress the site network reach SBR, it can make appropriate decisions on which link to use based on the source Locator value (which has been inserted by H) or based on other local policy.
Hには単一のインターフェースeth0があると仮定します。 SBRはL_1およびL_2を内部的にサイトにアドバタイズします。ホストHは、式（16a）および（16b）のようにILCCエントリを使用することにより、これらの両方を単一のインターフェースeth0を介して到達可能として構成します。サイトネットワークを出て行くHからのパケットがSBRに到達すると、送信元ロケータ値（Hによって挿入された）または他のローカルポリシーに基づいて、使用するリンクを適切に決定できます。
If, however, H has two interfaces, eth0 and eth1, then it can use ILCC entries as in expressions (17a) and (17b).
ただし、Hにeth0とeth1の2つのインターフェイスがある場合、式（17a）と（17b）のようにILCCエントリを使用できます。
Note that the values L_1 and L_2 do not need to be PI-based Locator values, and can be taken from ISP-specific PA routing prefix allocations from the upstream ISPs providing the two links.
値L_1およびL_2はPIベースのロケーター値である必要はなく、2つのリンクを提供する上流ISPからのISP固有のPAルーティングプレフィックス割り当てから取得できることに注意してください。
Of course, this example is illustrative: many other configurations are also possible, but the fundamental mechanism remains the same, as described above.
もちろん、この例は例示的なものです。他の多くの構成も可能ですが、基本的なメカニズムは上記のとおり同じです。
If any Locator values change, then H will discover this when it sees new Locator values in RAs from SBR, and sees that L values that were previously used are no longer advertised. When this happens, H will:
Locator値が変更された場合、HはSBRからのRAに新しいLocator値を検出し、以前に使用されていたL値がアドバタイズされていないことを検出すると、これを検出します。これが発生すると、Hは次のことを行います。
a) maintain existing active network-layer sessions: based on its current ILCC entries and active sessions, send Locator Update (LU) messages to CNs to notify them of the change of L values. (LU messages are synonymous to Mobile IPv6 Binding Updates.)
a) 既存のアクティブなネットワーク層セッションを維持します。現在のILCCエントリとアクティブなセッションに基づいて、ロケーター更新（LU）メッセージをCNに送信し、L値の変更を通知します。 （LUメッセージは、モバイルIPv6バインディング更新と同義です。）
b) if required, update its relevant DNS entries with the new L value in the appropriate DNS records, to enable correct resolution for new incoming session requests.
b) 必要に応じて、関連するDNSエントリを適切なDNSレコードの新しいL値で更新し、新しい着信セッション要求を正しく解決できるようにします。
From an engineering viewpoint, H also updates its ILCC data, removing the old L value(s) and replacing with new L value(s) as required.
エンジニアリングの観点から、HはILCCデータも更新し、古いL値を削除して、必要に応じて新しいL値に置き換えます。
Depending on the nature of the physical change in connectivity that the L value change represents, this may disrupt upper-level protocols, e.g., a fibre cut. Dealing with such physical-level disruption is beyond the scope of ILNP. However, ILNP supports graceful changes in L values, and this is explained below in Section 6 in the discussion on mobility support.
L値の変化が表す接続性の物理的変化の性質によっては、これにより上位レベルのプロトコル（ファイバーの切断など）が中断される場合があります。このような物理レベルの混乱に対処することは、ILNPの範囲を超えています。ただし、ILNPはL値の適切な変更をサポートしています。これについては、モビリティサポートに関する説明のセクション6で説明しています。
ILNP supports deployment and use of multi-path transport protocols, such as the Multi-Path extensions to TCP (MP-TCP) being defined by the IETF TCPM Working Group. Specifically, ILNP will support the use of multiple paths as it allows a single I value to be bound to multiple L values -- see Section 5.1, specifically expressions (15a) and (15b).
ILNPは、IETF TCPMワーキンググループによって定義されているTCPへのマルチパス拡張（MP-TCP）などのマルチパストランスポートプロトコルの導入と使用をサポートしています。具体的には、ILNPは、単一のI値を複数のL値にバインドできるため、複数のパスの使用をサポートします。セクション5.1、具体的には式（15a）および（15b）を参照してください。
Of course, there will be specific mechanisms for: - congestion control - signalling for connection/session management - path discovery and path management - engineering and implementation issues
もちろん、次の特定のメカニズムがあります。-輻輳制御-接続/セッション管理のシグナリング-パスの検出とパスの管理-エンジニアリングと実装の問題
These transport-layer mechanisms fall outside the scope of ILNP and would be defined in the multi-path transport protocol specifications.
これらのトランスポート層メカニズムはILNPの範囲外であり、マルチパストランスポートプロトコル仕様で定義されます。
As far as the ILNP architecture is concerned, the transport protocol connection is simply using multiple I-LVs, but with the same I value in each, and different L values, i.e., a multihomed host.
ILNPアーキテクチャに関する限り、トランスポートプロトコル接続は単に複数のI-LVを使用していますが、それぞれに同じI値があり、異なるL値、つまりマルチホームホストがあります。
At present, site multihoming is common in the deployed Internet. This is primarily achieved by advertising the site's routing prefix(es) to more than one upstream Internet service provider at a given time. In turn, this requires de-aggregation of routing prefixes within the inter-domain routing system. This increases the entropy of the inter-domain routing system (e.g., RIB/FIB size increases beyond the minimal RIB/FIB size that would be required to reach all sites).
現在、サイトマルチホーミングは展開されたインターネットで一般的です。これは主に、所定の時間にサイトのルーティングプレフィックスを複数のアップストリームインターネットサービスプロバイダーにアドバタイズすることによって実現されます。次に、これには、ドメイン間ルーティングシステム内のルーティングプレフィックスの集約解除が必要です。これにより、ドメイン間ルーティングシステムのエントロピーが増加します（たとえば、RIB / FIBサイズが、すべてのサイトに到達するために必要な最小のRIB / FIBサイズを超えて増加します）。
Site multihoming, in its simplest form in ILNP, is an extension of the H-MH scenario described in Section 5.1. If we consider Figure 5.1, and assume that there are many hosts in the site network, then each host can choose (a) whether or not to manage its own ILNP connectivity, and (b) whether or not to use multiple Locator values. This allows maximal control of connectivity for each host.
ILNPでの最も単純な形式のサイトマルチホーミングは、セクション5.1で説明されているH-MHシナリオの拡張です。図5.1を検討し、サイトネットワークに多数のホストがあると仮定すると、各ホストは（a）独自のILNP接続を管理するかどうか、および（b）複数のロケーター値を使用するかどうかを選択できます。これにより、各ホストの接続を最大限に制御できます。
Of course, with ILNPv6, just as any IPv6 router is required to generate IPv6 Router Advertisement messages with the correct routing prefix information for the link the RA is advertised upon, the SBR is also required to generate RAs containing the correct Locator value(s) for the link that the RA is advertised upon. The correct values for these RA messages are typically configured by system administration, or might be passed down from the upstream provider.
もちろん、ILNPv6では、RAがアドバタイズされるリンクの正しいルーティングプレフィックス情報を含むIPv6ルーターアドバタイズメッセージを生成するためにIPv6ルーターが必要であるのと同様に、正しいロケーター値を含むRAを生成するためにSBRも必要です。 RAがアドバタイズされるリンク。これらのRAメッセージの正しい値は通常、システム管理者によって設定されるか、上流のプロバイダーから渡される可能性があります。
To avoid a DNS Update burst when a site or (sub)network changes location, a DNS record optimisation is possible by using the new LP record for ILNP. This would change the number of DNS Updates required from Order(Number of nodes within the site/subnetwork that moved) to Order(1) [RFC6742].
サイトまたは（サブ）ネットワークが場所を変更したときにDNS更新バーストを回避するために、ILNPの新しいLPレコードを使用してDNSレコードの最適化を行うことができます。これにより、必要なDNS更新の数がOrder（移動したサイト/サブネットワーク内のノードの数）からOrder（1）[RFC6742]に変更されます。
The scenario of Figure 5.1 is an example to illustrate the architectural operation of multihoming for ILNP. For site multihoming, a scenario such as the one depicted in Figure 5.2 is also common. Here, there are two SBRs, each with its own global connectivity.
図5.1のシナリオは、ILNPのマルチホーミングのアーキテクチャー操作を示す例です。サイトマルチホーミングの場合、図5.2に示すようなシナリオも一般的です。ここには、2つのSBRがあり、それぞれ独自のグローバル接続があります。
site . . . .
network . .
. . . . +-------+ L_1 . .
. . | +------. .
. . | | . .
. .---+ SBR_A | . .
. . | | . .
. . | | . .
. . +-------+ . .
. . ^ . .
. . | CP . Internet .
. . v . .
. . +-------+ L_2 . .
. . | +------. .
. . | | . .
. .---+ SBR_B | . .
. . | | . .
. . | | . .
. . . . +-------+ . .
. .
. . . .
CP = coordination protocol L_1 = global Locator value 1 L_2 = global Locator value 2 SBR_A = Site Border Router A SBR_B = Site Border Router B
CP =調整プロトコルL_1 =グローバルロケーター値1 L_2 =グローバルロケーター値2 SBR_A =サイトボーダールーターA SBR_B =サイトボーダールーターB
Figure 5.2: A Dual-Router Multihoming Scenario for ILNP
図5.2：ILNPのデュアルルーターマルチホーミングシナリオ
The use of two physical routers provides an extra level of resilience compared to the scenario of Figure 5.1. The coordination protocol (CP) between the two routers keeps their actions in synchronisation according to whatever management policy is in place for the site network. Such capabilities are available today in products. Note that, logically, there is little difference between Figures 5.1 and 5.2, but with two distinct routers in Figure 5.2, the interaction using CP is required. Of course, it is also possible to have multiple interfaces in each router and more than two routers.
2つの物理ルーターを使用すると、図5.1のシナリオと比較して、回復力がさらに向上します。 2つのルーター間の調整プロトコル（CP）は、サイトネットワークに適用されている管理ポリシーに従って、それらのアクションの同期を維持します。このような機能は、現在製品で利用できます。論理的には、図5.1と5.2の間にはほとんど違いはありませんが、図5.2の2つの異なるルーターでは、CPを使用した対話が必要です。もちろん、各ルーターと3つ以上のルーターに複数のインターフェイスを設定することもできます。
For multihoming, the SBR does NOT need to be ILNP-capable for host multihoming or site multihoming. This is true provided the multihoming is left to individual hosts as described above. In this deployment approach, the SBR need only issue Routing Advertisements (RAs) that are correct with respect to its upstream connectivity; that is, the SBR properly advertises routing prefixes (Locator values) to the ILNP hosts.
マルチホーミングの場合、ホストマルチホーミングまたはサイトマルチホーミングでSBRがILNP対応である必要はありません。これは、前述のようにマルチホーミングが個々のホストに任されている場合に当てはまります。この展開アプローチでは、SBRはアップストリーム接続に関して正しいルーティングアドバタイズ（RA）を発行するだけで済みます。つまり、SBRはルーティングプレフィックス（ロケーター値）をILNPホストに適切にアドバタイズします。
In such a scenario, when hosts in the site network see new Locator values, and see that a previous Locator value is no longer being advertised, those hosts can update their ILCCs, send Locator Updates to CNs, and change connectivity as required.
このようなシナリオでは、サイトネットワークのホストが新しいロケーター値を確認し、以前のロケーター値がアドバタイズされなくなったことを確認すると、それらのホストはILCCを更新し、ロケーター更新をCNに送信し、必要に応じて接続を変更できます。
ILNP supports mobility directly, rather than relying upon special-purpose mobility extensions as is the case with both IPv4 [RFC2002] (which was obsoleted by [RFC5944]) and IPv6 [RFC6275].
ILNPは、IPv4 [RFC2002]（これは[RFC5944]で廃止された）とIPv6 [RFC6275]の両方の場合のように、特殊目的のモビリティ拡張に依存するのではなく、モビリティを直接サポートします。
There are two different mobility cases to consider:
考慮すべきモビリティのケースは2つあります。
a) Host Mobility: individual hosts may be mobile, moving across administrative boundaries or topological boundaries within an IP-based network, or across the Internet. Such hosts would need to independently manage their own mobility.
a) ホストの移動性：個々のホストはモバイルであり、IPベースのネットワーク内の管理上の境界やトポロジ上の境界を越えたり、インターネットを越えたりします。このようなホストは、独自のモビリティを個別に管理する必要があります。
b) Network (Site) Mobility: a whole site, i.e., one or more IP subnetworks may be mobile, moving across administrative boundaries or topological boundaries within an IP-based network, or across the Internet. The site as a whole needs to maintain consistency in connectivity.
b) ネットワーク（サイト）モビリティ：サイト全体、つまり1つ以上のIPサブネットワークはモバイルであり、IPベースのネットワーク内の管理境界またはトポロジ境界を越えて移動するか、インターネットを介して移動します。サイト全体として、接続の一貫性を維持する必要があります。
Essentially, for ILNP, mobility is implemented by enabling:
基本的に、ILNPの場合、モビリティは以下を有効にすることで実装されます。
a) Locator values to be changed dynamically by a node, including for active network-layer sessions.
a) アクティブなネットワーク層セッションを含む、ノードによって動的に変更されるロケーター値。
b) use of Locator Updates to allow active network-layer sessions to be maintained.
b) ロケーター更新を使用して、アクティブなネットワーク層セッションを維持できるようにします。
c) for those hosts that expect incoming network-layer or transport-layer session requests (e.g., servers), updates to the relevant DNS entries for those hosts.
c) 着信ネットワークレイヤーまたはトランスポートレイヤーセッション要求を予期するホスト（サーバーなど）の場合、それらのホストに関連するDNSエントリを更新します。
It is possible that a device is both a mobile host and part of a mobile network, e.g., a smartphone in a mobile site network. This is supported in ILNP as the mechanism for mobile hosts and mobile networks are very similar and work in harmony.
デバイスがモバイルホストであり、モバイルサイトネットワークのスマートフォンなどのモバイルネットワークの一部である可能性があります。モバイルホストとモバイルネットワークのメカニズムは非常によく似ており、調和して機能するため、これはILNPでサポートされています。
For mobility, there are two general features that must be supported:
モビリティのために、サポートする必要がある2つの一般的な機能があります。
a) Handover (or Hand-off): when a host changes its connectivity (e.g., it has a new SNPA as it moves to a new ILNP subnetwork), any active network-layer sessions for that host must be maintained with minimal disruption (i.e., transparently) to the upper-layer protocols.
a) ハンドオーバー（またはハンドオフ）：ホストが接続を変更する場合（たとえば、新しいILNPサブネットワークに移動するときに新しいSNPAが存在する場合）、そのホストのアクティブなネットワーク層セッションは、最小限の中断（つまり、透過的に）上位層プロトコルに。
b) Rendezvous: when a host that expects incoming network-layer or transport-layer session requests has new connectivity (e.g., it has a new SNPA as it moves to a new ILNP subnetwork), it needs to update its relevant DNS entries so that name resolution will provide the correct I and L values to remote nodes.
b) ランデブー：ネットワーク層またはトランスポート層の着信セッション要求を予期するホストに新しい接続がある場合（たとえば、新しいILNPサブネットワークに移動するときに新しいSNPAがある場合）、名前解決のために関連するDNSエントリを更新する必要があります正しいIおよびL値をリモートノードに提供します。
Mobility and multihoming present the same set of issues for ILNP. Indeed, mobility and multihoming form a duality: the set of Locators associated with a node or site changes. The reason for the change might be different for the case of mobility and multihoming, but the effects on the network-layer session state and on correspondents is identical.
モビリティとマルチホーミングは、ILNPと同じ一連の問題を提示します。実際、モビリティとマルチホーミングは二重性を形成します。ノードまたはサイトに関連付けられたロケーターのセットが変更されます。変更の理由は、モビリティとマルチホーミングの場合では異なる場合がありますが、ネットワーク層のセッション状態と通信相手への影響は同じです。
With ILNP, mobility and multihoming are supported using a common set of mechanisms. In both cases, different Locator values are used to identify different IP subnetworks. Also, ILNP nodes that expect incoming network-layer or transport-layer session requests are assumed to have a Fully Qualified Domain Name (FQDN) stored in the Domain Name System (DNS), as is already done within the deployed Internet. ILNP mobility normally relies upon the Secure Dynamic DNS Update standard for mobile nodes to update their location information in the DNS. This approach of using DNS for rendezvous with mobile systems was proposed earlier by others [PHG02].
ILNPでは、モビリティとマルチホーミングが共通のメカニズムセットを使用してサポートされます。どちらの場合も、異なるIPサブネットワークを識別するために異なるロケーター値が使用されます。また、着信ネットワークレイヤーまたはトランスポートレイヤーセッション要求を予期するILNPノードは、既に展開されたインターネット内で行われているように、完全修飾ドメイン名（FQDN）がドメインネームシステム（DNS）に格納されていると想定されます。 ILNPモビリティは、通常、モバイルノードがDNS内の位置情報を更新するために、Secure Dynamic DNS Update標準に依存しています。モバイルシステムとのランデブーにDNSを使用するこのアプローチは、以前に他の人によって提案されました[PHG02]。
Host Mobility considers individual hosts that are individually mobile -- for example, a mobile telephone carried by a person walking in a city. Network (Site) Mobility considers a group of hosts within a local topology that move jointly and periodically change their uplinks to the rest of the Internet -- for example, a ship that has wired connections internally but one or more wireless uplinks to the rest of the Internet.
ホストモビリティは、個別に移動可能な個々のホストを考慮します。たとえば、都市を歩く人が携帯する携帯電話などです。ネットワーク（サイト）モビリティは、ローカルトポロジ内の共同で移動し、定期的に残りのインターネットへのアップリンクを変更するホストのグループを考慮します-たとえば、内部に有線接続があるが、残りの1つ以上のワイヤレスアップリンクを持つ船インターネット。
For ILNP, Host Mobility is analogous to host multihoming (H-MH) and Network Mobility is analogous to site multihoming (S-MH). So, mobility and multihoming capabilities can be used together, without conflict.
ILNPの場合、ホストモビリティはホストマルチホーミング（H-MH）に類似しており、ネットワークモビリティはサイトマルチホーミング（S-MH）に類似しています。したがって、モビリティ機能とマルチホーミング機能は、競合することなく一緒に使用できます。
With Host Mobility, each individual end-system manages its own connectivity through the use of Locator values. (This is very similar to the situation described for H-MH in Section 5.1.)
ホストモビリティでは、個々のエンドシステムがロケーター値を使用して独自の接続を管理します。 （これは、セクション5.1でH-MHについて説明した状況と非常に似ています。）
Let us consider the network in Figure 6.1.
図6.1のネットワークについて考えてみましょう。
site . . . .
network A . .
. . . . +-------+ L_A . .
. . | +------. .
. . | | . .
. .---+ SBR_A | . .
. . | | . .
. H(1) . | | . .
. . +-------+ . .
. . . . . . . .
. H(2) . . Internet .
. . . . . . . .
. . +-------+ L_B . .
. H(3) . | +------. .
. . | | . .
. .---+ SBR_B | . .
. . | | . .
. . | | . .
. . . . +-------+ . .
site . .
network B . . . .
H(X) = host H at position X L_A = global Locator value A L_B = global Locator value B SBR = Site Border Router
H（X）=位置XのホストH L_A =グローバルロケーター値A L_B =グローバルロケーター値B SBR =サイトボーダールーター
Figure 6.1: A Simple Mobile Host Scenario for ILNP
図6.1：ILNPの単純なモバイルホストシナリオ
A host H is at position (1), hence H(1) in a site network A. This site network might be, for example, a single radio cell under administrative domain A. We assume that the host will move into site network B, which might be a single radio cell under administrative domain B. We also assume that the site networks have a region of overlap so that connectivity can be maintained; else, of course, the host will lose connectivity. Also, let us assume that the host already has ILNP connectivity in site network A.
ホストHは（1）の位置にあるため、サイトネットワークAのH（1）になります。このサイトネットワークは、たとえば、管理ドメインAの単一の無線セルである可能性があります。ホストはサイトネットワークBに移動すると仮定します。 、これは管理ドメインBの単一の無線セルである可能性があります。また、接続を維持できるように、サイトネットワークには重複領域があると想定しています。そうでなければ、もちろん、ホストは接続を失います。また、ホストがサイトネットワークAですでにILNP接続を持っていると仮定します。
If site network A has connectivity via Locator value L_A, and H uses Identifier value I_H with a single interface ra0, then the host's ILCC will contain:
サイトネットワークAがロケーター値L_Aを介して接続していて、Hが単一のインターフェイスra0で識別子値I_Hを使用している場合、ホストのILCCには次のものが含まれます。
[I_H, L_A] --- (18a)
L_A, ra0 --- (18b)
Note the equivalence of expressions (18a) and (18b), respectively, with the expressions (15a) and (16a) for host multihoming.
ホストマルチホーミングの式（15a）および（16a）とそれぞれ式（18a）および（18b）が等しいことに注意してください。
The host now moves into the overlap region of site networks A and B, and has position (2), hence H(2) as indicated in Figure 6.1. As this region is now in site network B, as well as site network A, H should see RAs from SBR_B for L_B, as well as the RAs for L_A from SBR_A. The host can now start to use L_B for its connectivity. The host H must now:
これで、ホストはサイトネットワークAとBのオーバーラップ領域に移動し、図6.1に示すように位置（2）、つまりH（2）になります。このリージョンはサイトネットワークBとサイトネットワークAにあるので、HにはL_BのSBR_BからのRAと、SBR_AからのL_AのRAが表示されます。これで、ホストは接続にL_Bの使用を開始できます。ホストHは次のことを行う必要があります。
a) maintain existing active upper-layer sessions: based on its current ILCC entries and active sessions, send Locator Update (LU) messages to CNs to notify them of the change of L values. (LU messages are synonymous to Mobile IPv6 Binding Updates.)
a) 既存のアクティブな上位層セッションを維持する：現在のILCCエントリとアクティブなセッションに基づいて、Locator Update（LU）メッセージをCNに送信し、L値の変更を通知します。 （LUメッセージは、モバイルIPv6バインディング更新と同義です。）
b) if required, update its relevant DNS entries with the new L value in the appropriate DNS records, to enable correct resolution for new incoming network-layer or transport-layer session requests.
b) 必要に応じて、関連するDNSエントリを適切なDNSレコードの新しいL値で更新し、新しい着信ネットワークレイヤーまたはトランスポートレイヤーセッション要求の正しい解決を可能にします。
However, it can opt to do this one of two ways:
ただし、次の2つの方法のいずれかを選択できます。
1) immediate handover: the host sends Locator Update (LU) messages to CNs, immediately stops using L_A, and switches to using L_B only. In this case, its ILCC entries change to:
1）即時のハンドオーバー：ホストはロケーター更新（LU）メッセージをCNに送信し、L_Aの使用を直ちに停止し、L_Bのみの使用に切り替えます。この場合、ILCCエントリは次のように変わります。
[I_H, L_B] --- (19a)
L_B, ra0 --- (19b)
There might be packets in flight to H that use L_A, and H MAY choose to ignore these on reception.
L_Aを使用するHへの飛行中のパケットが存在する可能性があり、Hは受信時にこれらを無視することを選択できます。
2) soft handover: the host sends Locator Update (LU) messages to CNS, but it uses both L_A and L_B until (i) it no longer receives incoming packets with destination Locator values set to L_A within a given time period and (ii) it no longer sees RAs for L_A (i.e., it has left the overlap region and so has left site network A). In this case, its ILCC entries change to:
2）ソフトハンドオーバー：ホストはロケーター更新（LU）メッセージをCNSに送信しますが、（i）所定の期間内に宛先ロケーター値がL_Aに設定された着信パケットを受信しなくなるまで、L_AとL_Bの両方を使用し、（ii） L_AのRAはもう見えません（つまり、オーバーラップ領域を離れたため、サイトネットワークAを離れました）。この場合、ILCCエントリは次のように変わります。
[I_H, L_A] --- (20a)
L_A, ra0 --- (20b)
[I_H, L_B] --- (20c)
L_B, ra0 --- (20d)
ILNP does not mandate the use of one handover option over another. Indeed, a host may implement both and decide, through local policy or other mechanisms (e.g., under the control of a particular transport protocol implementation), to use one or other for a specific transport-layer session, as required.
ILNPは、あるハンドオーバーオプションの使用を別のハンドオーバーオプションに義務付けていません。実際、ホストは両方を実装し、ローカルポリシーまたは他のメカニズムを通じて（たとえば、特定のトランスポートプロトコル実装の制御下で）、必要に応じて特定のトランスポート層セッションにどちらか一方を使用することを決定できます。
Note that if using soft handover, when in the overlap region, the host is multihomed. Also, soft handover is likely to provide a less disruptive handover (e.g., lower packet loss) compared to immediate handover, all other things being equal.
ソフトハンドオーバーを使用している場合、オーバーラップ領域では、ホストはマルチホームです。また、ソフトハンドオーバーは、即時ハンドオーバーと比較して、中断の少ないハンドオーバー（パケット損失の減少など）を提供する可能性が高く、他のすべての条件は同じです。
There is a case where both the host and its correspondent node are mobile. In the unlikely event of simultaneous motion that changes both nodes' Locators within a very small time period, there is the possibility that communication may be lost. If the communication between the nodes was direct (i.e., one node initiated communication with another, through a DNS lookup), a node can use the DNS to discover the new Locator value(s) for the other node. If the communication was through some sort of middlebox providing a relay service, then communication is more likely to disrupted only if the middlebox is also mobile.
ホストとそのコレスポンデントノードの両方がモバイルである場合があります。非常に短い時間内に両方のノードのロケーターを変更する同時のモーションのまれなイベントでは、通信が失われる可能性があります。ノード間の通信が直接的な場合（つまり、あるノードがDNSルックアップを介して別のノードとの通信を開始した場合）、ノードはDNSを使用して他のノードの新しいロケーター値を検出できます。リレーサービスを提供するある種のミドルボックスを介して通信が行われた場合、ミドルボックスもモバイルである場合にのみ、通信が中断される可能性が高くなります。
It is also possible that high packet loss results in Locator Updates being lost, which could disrupt handover. However, this is an engineering issue and does not impact the basic concept of operation; additional discussion on this issue is provided in [RFC6741].
また、パケット損失が多いと、ロケーターの更新が失われ、ハンドオーバーが中断する可能性があります。ただし、これは技術的な問題であり、操作の基本概念には影響しません。この問題に関する追加の議論は[RFC6741]で提供されています。
Of course, for any handover, the new end-to-end path through SBR_B might have very different end-to-end path characteristics (e.g., different end-to-end delay, packet loss, throughput). Also, the physical connectivity on interface ra0 as well as through SBR_B's uplink may be different. Such impacts on end-to-end packet transfer are outside the scope of ILNP.
もちろん、どのようなハンドオーバーでも、SBR_Bを介した新しいエンドツーエンドパスは、非常に異なるエンドツーエンドパス特性（たとえば、異なるエンドツーエンド遅延、パケット損失、スループット）を持つ場合があります。また、インターフェースra0の物理接続とSBR_Bのアップリンクを介した物理接続は異なる場合があります。エンドツーエンドのパケット転送に対するこのような影響は、ILNPの範囲外です。
For network mobility, a whole site may be mobile, e.g., the SBRs of Figure 6.1 have a radio uplink on a moving vehicle. Within the site, individual hosts may or may not be mobile.
ネットワークモビリティの場合、サイト全体がモバイルである可能性があります。たとえば、図6.1のSBRには、移動中の車両に無線アップリンクがあります。サイト内では、個々のホストがモバイルである場合とそうでない場合があります。
In the simplest case, ILNP deals with mobile networks in the same way as for site multihoming: the management of mobility is delegated to each host in the site, so it needs to be ILNP-capable. Each host, effectively, behaves as if it were a mobile host, even though it may not actually be mobile. Indeed, in this way, the mechanism is very similar to that for site multihoming. Let us consider the mobile network in Figure 6.2.
最も単純なケースでは、ILNPはサイトマルチホーミングと同じ方法でモバイルネットワークを扱います。モビリティの管理はサイト内の各ホストに委任されるため、ILNP対応である必要があります。各ホストは、実際にはモバイルではない場合でも、事実上、モバイルホストのように動作します。実際、この方法では、メカニズムはサイトマルチホーミングのメカニズムと非常に似ています。図6.2のモバイルネットワークについて考えてみましょう。
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . | ra1+------. .
. .----+ | . .
. H . | ra2+-- . .
. . . . +------+ . .
. . .
Figure 6.2a: ILNP Mobile Network before Handover
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . | ra1+------. . . . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . . . . .
. .
. . .
ISP_2
Figure 6.2b: ILNP Mobile Network during Handover
site ISP_2
network SBR . . .
. . . . +------+ . .
. . | ra1+-- . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ . .
. . .
Figure 6.2c: ILNP Mobile Network after Handover
H = host L_1 = global Locator value 1 L_2 = global Locator value 2 SBR = Site Border Router
H =ホストL_1 =グローバルロケーター値1 L_2 =グローバルロケーター値2 SBR =サイト境界ルーター
Figure 6.2: A Simple Mobile Network Scenario for ILNP
図6.2：ILNPの単純なモバイルネットワークシナリオ
In Figure 6.2, we assume that the site network is mobile, and the SBR has two radio interfaces ra1 and ra2. However, this particular figure is chosen for simplicity and clarity for our scenario, and other configurations are possible, e.g., a single radio interface which uses separate radio channels (separate carriers, coding channels, etc.). In the figure, ISP_1 and ISP_2 are separate, radio-based service providers, accessible via ra1 and ra2.
図6.2では、サイトネットワークがモバイルであり、SBRに2つの無線インターフェイスra1とra2があると想定しています。ただし、この特定の図は、シナリオの簡素化と明確化のために選択されたものであり、他の構成、たとえば、個別の無線チャネル（個別のキャリア、コーディングチャネルなど）を使用する単一の無線インターフェイスも可能です。この図では、ISP_1とISP_2は別々の無線ベースのサービスプロバイダーであり、ra1とra2を介してアクセスできます。
In Figure 6.2a, the SBR has connectivity via ISP_1 using Locator value L_1. The host H, with interface ra0 and Identifier I_H, has an established connectivity via the SBR and so has ILCC entries as shown in (21):
図6.2aでは、SBRはロケーター値L_1を使用してISP_1経由で接続しています。ホストraは、インターフェースra0と識別子I_Hを持ち、SBRを介して接続が確立されているため、（21）に示すようにILCCエントリがあります。
[I_H, L_1] --- (21a)
L_1, ra0 --- (21b)
Note the equivalence to expressions (18a) and (18b). As the whole network moves, the SBR detects a new radio provider, ISP_2, and connects to it using ra2, as shown in Figure 6.2b, with the service areas of ISP_1 and ISP_2 overlapping. ISP_2 provides Locator L_2, which the SBR advertises into the site network along with L_1. As with the mobile host scenario above, individual hosts may decide to perform immediate handover or soft handover. So, the ILCC state for H will be as for expressions (19a) and (19b) and (20a)-(20d), but with L_1 in place of L_A, and L_2 in place of L_B. Finally, as in Figure 6.2c, the site network moves and is no longer served by ISP_1, and handover is complete. Note that during the handover the site is multihomed, as in Figure 6.2b.
式（18a）と（18b）が等しいことに注意してください。ネットワーク全体が移動すると、SBRは新しい無線プロバイダーISP_2を検出し、ra2を使用してそれに接続します（図6.2bを参照）。ISP_1とISP_2のサービスエリアは重複しています。 ISP_2は、SBRがL_1とともにサイトネットワークにアドバタイズするロケーターL_2を提供します。上記のモバイルホストシナリオと同様に、個々のホストは即時のハンドオーバーまたはソフトハンドオーバーの実行を決定する場合があります。したがって、HのILCC状態は式（19a）と（19b）および（20a）-（20d）の場合と同じですが、L_Aの代わりにL_1、L_Bの代わりにL_2を使用します。最後に、図6.2cのように、サイトネットワークが移動し、ISP_1のサービスを受けなくなり、ハンドオーバーが完了します。図6.2bのように、ハンドオーバー中、サイトはマルチホームであることに注意してください。
As for multihoming, the SBR does NOT need to be ILNP-capable: it simply needs to advertise the available routing prefixes into the site network. The mobility capability is handled completely by the hosts.
マルチホーミングに関しては、SBRはILNP対応である必要はありません。利用可能なルーティングプレフィックスをサイトネットワークにアドバタイズする必要があるだけです。モビリティ機能はホストによって完全に処理されます。
Just as Section 5.3.1 describes the use of multiple routers for multihoming, so it is possible to have multiple routers for mobility for ILNP, for both mobile hosts and mobile networks.
セクション5.3.1がマルチホーミング用の複数のルーターの使用について説明しているように、モバイルホストとモバイルネットワークの両方で、ILNPのモビリティ用に複数のルーターを使用することが可能です。
IP Security for ILNP [RFC6741] becomes simpler, in principle, than IPsec as it is today, based on the use of IP Addresses as Identifiers.
ILNPのIPセキュリティ[RFC6741]は、識別子としてのIPアドレスの使用に基づいて、現在のIPsecよりも原理的に単純になります。
An operational issue in the deployed IP Internet is that the IPsec protocols, AH and ESP, have Security Associations (IPsec SAs) that include the IP Addresses of the secure IPsec session endpoints. This was understood to be a problem when AH and ESP were originally defined in [RFC1825], [RFC1826], and [RFC1827] (which were obsoleted by [RFC4301], [RFC4302], and [RFC4303]). However, the limited set of namespaces in the Internet Architecture did not provide any better choices at that time. ILNP provides more namespaces, thus now enabling better IPsec architecture and engineering.
展開されたIPインターネットの運用上の問題は、IPsecプロトコル、AHおよびESPに、安全なIPsecセッションエンドポイントのIPアドレスを含むセキュリティアソシエーション（IPsec SA）があることです。これは、AHとESPが[RFC1825]、[RFC1826]、および[RFC1827]（[RFC4301]、[RFC4302]、および[RFC4303]によって廃止された）で最初に定義されたときに問題であると理解されていました。ただし、インターネットアーキテクチャの限られた名前空間のセットでは、現時点でこれ以上の選択肢はありませんでした。 ILNPはより多くの名前空間を提供するため、より良いIPsecアーキテクチャとエンジニアリングが可能になります。
In essence, ILNP provides a very simple architectural change to IPsec: in place of IP Addresses as used today for IPsec SAs, ILNP uses Node Identifier values instead. Recall that Identifier values are immutable once in use, so they can be used to maintain end-to-end state for any protocol that requires it. Note from the discussion above that the Identifier values for a host remain unchanged when multihoming and mobility are in use, so IPsec using ILNP can work in harmony with multihoming and mobility [ABH08b] [ABH09a].
本質的に、ILNPはIPsecに非常に単純なアーキテクチャの変更を提供します。現在IPsec SAに使用されているIPアドレスの代わりに、ILNPは代わりにノード識別子の値を使用します。識別子の値は、一度使用すると不変であることを思い出してください。そのため、これらの値を使用して、それを必要とするプロトコルのエンドツーエンドの状態を維持できます。上記の説明から、マルチホーミングとモビリティが使用されている場合、ホストのID値は変更されないため、ILNPを使用するIPsecはマルチホーミングとモビリティと連携して機能することがわかります[ABH08b] [ABH09a]。
To resolve the issue of IPsec interoperability through a Network Address Translator (NAT) deployment [RFC1631] [RFC3022], UDP encapsulation of IPsec [RFC3948] is commonly used as of the date this document was published. This special-case handling for IPsec traffic traversing a NAT is not needed with ILNP IPsec.
Network Address Translator（NAT）展開[RFC1631] [RFC3022]によるIPsec相互運用性の問題を解決するために、このドキュメントの発行日現在、IPsec [RFC3948]のUDPカプセル化が一般的に使用されています。 NATを通過するIPsecトラフィックのこの特別なケースの処理は、ILNP IPsecでは必要ありません。
Further, it would obviate the need for specialised IPsec NAT traversal mechanisms, thus simplifying IPsec implementations while enhancing deployability and interoperability [RFC3948].
さらに、特別なIPsec NATトラバーサルメカニズムが不要になるため、IPsecの実装が簡素化され、展開性と相互運用性が向上します[RFC3948]。
This architectural change does not reduce the security provided by the IPsec protocols. In fact, had the Node Identifier namespace existed back in the early 1990s, IPsec would always have bound to that location-independent Node Identifier and would not have bound to IP Addresses.
このアーキテクチャの変更によって、IPsecプロトコルによって提供されるセキュリティが低下することはありません。実際、ノード識別子の名前空間が1990年代初頭に存在していた場合、IPsecは常にその場所に依存しないノード識別子にバインドされ、IPアドレスにはバインドされませんでした。
Operationally, this change in SA bindings to use Identifiers rather than IP Addresses causes problems for the use of the IPsec protocols through IP Network Address Translation (NAT) devices, with mobile nodes (because the mobile node's IP Address changes at each network-layer handoff), and with multihomed nodes (because the network-layer IPsec session is bound to a particular interface of the multihomed node, rather than being bound to the node itself) [RFC3027] [RFC3715].
運用上、IPアドレスではなく識別子を使用するようにSAバインディングを変更すると、モバイルノードでIPネットワークアドレス変換（NAT）デバイスを介してIPsecプロトコルを使用するときに問題が発生します（モバイルノードのIPアドレスが各ネットワーク層のハンドオフで変更されるため） ）、およびマルチホームノードの場合（ネットワーク層IPsecセッションは、ノード自体にバインドされるのではなく、マルチホームノードの特定のインターフェイスにバインドされるため）[RFC3027] [RFC3715]。
ILNPv6 is fully backwards compatible with existing IPv6. No router software or silicon changes are necessary to support the proposed enhancements. An IPv6 router would be unaware whether the packet being forwarded were classic IPv6 or the proposed enhancement in ILNPv6. IPv6 Neighbour Discovery will work unchanged for ILNPv6. ILNPv6 multicasting is the same as IETF standards-track IPv6 multicasting.
ILNPv6は、既存のIPv6と完全に下位互換性があります。提案された拡張機能をサポートするために、ルーターソフトウェアやシリコンの変更は必要ありません。 IPv6ルーターは、転送されるパケットが従来のIPv6であるか、ILNPv6で提案されている拡張機能であるかを認識しません。 IPv6ネイバー探索は、ILNPv6では変更なしで機能します。 ILNPv6マルチキャストは、IETF標準トラックIPv6マルチキャストと同じです。
ILNPv4 is backwards compatible with existing IPv4. As the IPv4 address fields are used as 32-bit Locators, using only the address prefix bits of the 32-bit space, IPv4 routers also would not require changes. An IPv4 router would be unaware whether the packet being forwarded were classic IPv4 or the proposed enhancement in ILNPv4 [RFC6746]. ARP [RFC826] requires enhancements to support ILNPv4 [RFC6747] [RFC6741]. ILNPv4 multicasting is the same as IETF standards-track IPv4 multicasting.
ILNPv4は、既存のIPv4と下位互換性があります。 IPv4アドレスフィールドは32ビットロケーターとして使用され、32ビットスペースのアドレスプレフィックスビットのみを使用するため、IPv4ルーターも変更を必要としません。 IPv4ルーターは、転送されるパケットが従来のIPv4であるか、ILNPv4 [RFC6746]で提案された拡張機能であるかを認識しません。 ARP [RFC826]では、ILNPv4 [RFC6747] [RFC6741]をサポートするための機能拡張が必要です。 ILNPv4マルチキャストは、IETF標準トラックIPv4マルチキャストと同じです。
If a node supports ILNP and intends to receive incoming network-layer or transport-layer sessions, the node's Fully Qualified Domain Name (FQDN) normally will have one or more NID records and one or more Locator (i.e., L32, L64, and/or LP) records associated with the node within the DNS [RFC6741] [RFC6742].
ノードがILNPをサポートし、着信ネットワークレイヤーセッションまたはトランスポートレイヤーセッションを受信する場合、ノードの完全修飾ドメイン名（FQDN）には通常、1つ以上のNIDレコードと1つ以上のロケーター（L32、L64など）があります。またはLP）DNS [RFC6741] [RFC6742]内のノードに関連付けられたレコード。
When an IP host ("initiator") initiates a new network-layer session with a correspondent ("responder"), it normally will perform a DNS lookup to determine the address(es) of the responder. An ILNP host normally will look for Node Identifier ("NID") and Locator (i.e., L32, L64, and LP) records in any received DNS replies. DNS servers that support NID and Locator (i.e., L32, L64, and LP) records SHOULD include them (when they exist) as additional data in all DNS replies to queries for DNS AAAA records [RFC6742].
IPホスト（「イニシエーター」）がコレスポンデント（「レスポンダー」）との新しいネットワーク層セッションを開始すると、通常、DNSルックアップを実行してレスポンダーのアドレスを決定します。 ILNPホストは通常、受信したDNS応答でノード識別子（「NID」）およびロケーター（L32、L64、LPなど）レコードを探します。 NIDおよびロケーター（つまり、L32、L64、およびLP）レコードをサポートするDNSサーバーは、DNS AAAAレコード[RFC6742]へのクエリに対するすべてのDNS応答に追加データとして（存在する場合）追加する必要があります（SHOULD）。
If the initiator supports ILNP, and from DNS information learns that the responder also supports ILNP, then the initiator will generate an unpredictable ILNP Nonce value, cache that value locally as part of the network-layer ILNP session, and will include the ILNP Nonce value in its initial packet(s) to the responder [RFC6741] [RFC6744] [RFC6746].
イニシエーターがILNPをサポートし、DNS情報からレスポンダーもILNPをサポートしていることがわかった場合、イニシエーターは予測不可能なILNP Nonce値を生成し、その値をネットワークレイヤーILNPセッションの一部としてローカルにキャッシュし、ILNP Nonce値を含めます。応答者への最初のパケットで[RFC6741] [RFC6744] [RFC6746]。
If the initiator node does not find any ILNP-specific DNS resource records for the responder node, then the initiator uses classic IP for the new network-layer session with the responder, rather than trying to use ILNP for that network-layer session. Of course, multiple transport-layer sessions can concurrently share a single network-layer (e.g., IP or ILNP) session.
イニシエーターノードがレスポンダーノードのILNP固有のDNSリソースレコードを検出しない場合、イニシエーターはそのネットワークレイヤーセッションにILNPを使用するのではなく、レスポンダーとの新しいネットワークレイヤーセッションにクラシックIPを使用します。もちろん、複数のトランスポート層セッションが単一のネットワーク層（IPまたはILNPなど）セッションを同時に共有できます。
If the responder node for a new network-layer session does not support ILNP and the responder node receives initial packet(s) containing the ILNP Nonce, then the responder will drop the packet and send an ICMP error message back to the initiator. If the responder node for a new network-layer session supports ILNP and receives initial packet(s) containing the ILNP Nonce, the responder learns that ILNP is in use for that network-layer session (i.e., by the presence of that ILNP Nonce).
新しいネットワーク層セッションのレスポンダノードがILNPをサポートせず、レスポンダノードがILNP Nonceを含む最初のパケットを受信した場合、レスポンダはパケットをドロップし、ICMPエラーメッセージをイニシエータに送り返します。新しいネットワークレイヤーセッションのレスポンダーノードがILNPをサポートし、ILNPナンスを含む最初のパケットを受信した場合、レスポンダーはILNPがそのネットワークレイヤーセッションで使用されていることを学習します（つまり、そのILNPナンスの存在により） 。
If the initiator node using ILNP does not receive a response from the responder in a timely manner (e.g., within TCP timeout for a TCP session) and also does not receive an ICMP Unreachable error message for that packet, OR if the initiator receives an ICMP Parameter Problem error message for that packet, then the initiator concludes that the responder does not support ILNP. In this case, the initiator node SHOULD try again to create the new network-layer session, but this time using IP (and therefore omitting the ILNP Nonce).
ILNPを使用するイニシエーターノードがレスポンダーからタイムリーに（TCPセッションのTCPタイムアウト内など）応答を受信せず、そのパケットのICMP到達不能エラーメッセージも受信しない場合、またはイニシエーターがICMPを受信した場合そのパケットのパラメータ問題エラーメッセージの場合、イニシエータはレスポンダがILNPをサポートしていないと結論付けます。この場合、イニシエーターノードは新しいネットワークレイヤーセッションの作成を再試行する必要がありますが、今回はIPを使用します（したがって、ILNPナンスを省略します）。
Finally, since an ILNP node also is a fully capable IP node, the upgraded node can use any standardised IP mechanisms for communicating with a legacy IP-only node. So, ILNP will not be worse than existing IP, but when ILNP is used, the enhanced capabilities described in these ILNP documents will be available.
最後に、ILNPノードは完全に機能するIPノードでもあるため、アップグレードされたノードは、標準化されたIPメカニズムを使用して、レガシーIPのみのノードと通信できます。したがって、ILNPは既存のIPよりも劣ることはありませんが、ILNPを使用すると、これらのILNPドキュメントで説明されている拡張機能を利用できます。
This proposal outlines a proposed evolution for the Internet Architecture to provide improved capabilities. This section discusses security considerations for this proposal.
この提案は、改善された機能を提供するためのインターネットアーキテクチャの提案された進化の概要を示しています。このセクションでは、この提案のセキュリティに関する考慮事項について説明します。
Note that ILNP provides security equivalent to IP for similar threats when similar mitigations (e.g., IPsec or not) are in use. In some cases, but not all, ILNP exceeds that objective and has lower security risk than IP. Additional engineering details for several of these topics can be found in [RFC6741].
ILNPは、同様の緩和策（IPsecなど）が使用されている場合、同様の脅威に対してIPと同等のセキュリティを提供します。すべてではありませんが、ILNPはその目的を超え、IPよりもセキュリティリスクが低い場合があります。これらのトピックのいくつかの追加のエンジニアリングの詳細は、[RFC6741]にあります。
All Locator Update messages are authenticated. ILNP requires use of an ILNP session nonce [RFC6744] [RFC6746] to prevent off-path attacks, and also allows use of IPsec cryptography to provide stronger protection where required.
すべてのロケーター更新メッセージが認証されます。 ILNPは、パス外の攻撃を防ぐためにILNPセッションnonce [RFC6744] [RFC6746]を使用する必要があり、必要に応じてIPsec暗号化を使用してより強力な保護を提供することもできます。
Ordinary network-layer sessions based on IP are vulnerable to on-path attacks unless IPsec is used. So the Nonce Destination Option only seeks to provide protection against off-path attacks on an ILNP-based network-layer session -- equivalent to ordinary IP-based network-layer sessions that are not using IPsec.
IPsecが使用されない限り、IPに基づく通常のネットワーク層セッションは、パス上の攻撃に対して脆弱です。したがって、Nonce Destination Optionは、ILNPベースのネットワークレイヤーセッションでのオフパス攻撃に対する保護を提供することのみを目的としています-IPsecを使用していない通常のIPベースのネットワークレイヤーセッションと同等です。
It is common to have non-symmetric paths between two nodes on the Internet. To reduce the number of on-path nodes that know the Nonce value for a given session when ILNP is in use, a nonce value is unidirectional, not bidirectional. For example, for a network-layer ILNP-based session between nodes A and B, one nonce value is used from A to B and a different nonce value is used from B to A.
インターネット上の2つのノード間に非対称パスを持つことは一般的です。 ILNPの使用中に特定のセッションのナンス値を認識するパス上ノードの数を減らすために、ナンス値は双方向ではなく単方向です。たとえば、ノードAとBの間のネットワーク層ILNPベースのセッションの場合、AからBへの1つのナンス値とBからAへの別のナンス値が使用されます。
ILNP sessions operating in higher risk environments SHOULD also use the cryptographic authentication provided by IPsec *in addition* to concurrent use of the ILNP Nonce.
よりリスクの高い環境で動作するILNPセッションは、ILNPナンスの同時使用に加えて、IPsecによって提供される暗号化認証も使用する必要があります。
It is important to note that, at present, a network-layer IP-based session is entirely vulnerable to on-path attacks unless IPsec is in use for that particular IP session, so the security properties of the new proposal are never worse than for existing IP.
現在、ネットワーク層のIPベースのセッションは、その特定のIPセッションでIPsecが使用されていない限り、パス上の攻撃に対して完全に脆弱であるため、新しい提案のセキュリティプロパティは、既存のIP。
In the deployed Internet, active attacks using packets with a forged Source IP Address have been publicly known at least since early 1995 [CA-1995-01]. While these exist in the deployed Internet, they have not been widespread. This is equivalent to the issue of a forged Identifier value and demonstrates that this is not a new threat created by ILNP.
展開されたインターネットでは、偽造された送信元IPアドレスを持つパケットを使用したアクティブな攻撃が、少なくとも1995年の初めから公に知られています[CA-1995-01]。これらは配備されたインターネットに存在しますが、広くは普及していません。これは、偽造された識別子の値の問題に相当し、これがILNPによって作成された新しい脅威ではないことを示しています。
One mitigation for these attacks has been to deploy Source IP Address filtering [RFC2827] [RFC3704]. Jun Bi at Tsinghua University cites Arbor Networks as reporting that this mechanism has less than 50% deployment and cites an MIT analysis indicating that at least 25% of the deployed Internet permits forged Source IP Addresses.
これらの攻撃の緩和策の1つは、送信元IPアドレスフィルタリング[RFC2827] [RFC3704]を導入することです。清華大学のJun Bi氏は、Arbor Networksがこのメカニズムの導入が50％未満であることを報告し、導入されたインターネットの少なくとも25％が偽のソースIPアドレスを許可していることを示すMITの分析を引用しています。
In [RFC6741], there is a discussion of an accidental use of a duplicate Identifier on the Internet. However, this sub-section instead focuses on methods for mitigating attacks based on packets containing deliberately forged Source Identifier values.
[RFC6741]では、インターネット上で重複した識別子を誤って使用することについての議論があります。ただし、このサブセクションでは、意図的に偽造されたソース識別子の値を含むパケットに基づいて攻撃を軽減する方法に焦点を当てています。
Firstly, the recommendations of [RFC2827] and [RFC3704] remain. So, any packets that have a forged Locator value can be easily filtered using existing widely available mechanisms.
まず、[RFC2827]と[RFC3704]の推奨事項が残っています。したがって、偽造されたロケータ値を持つパケットは、既存の広く利用可能なメカニズムを使用して簡単にフィルタリングできます。
Secondly, the receiving node does not blindly accept any packet with the proper Source Identifier and proper Destination Identifier as an authentic packet. Instead, each ILNP node maintains an ILNP Communication Cache (ILCC) for each of its correspondents, as described in [RFC6741]. Information in the cache is used in validating received messages and preventing off-path attackers from succeeding. This process is discussed more in [RFC6741].
第2に、受信ノードは、適切な送信元識別子と適切な宛先識別子を含むパケットを本物のパケットとして盲目的に受け入れません。代わりに、[RFC6741]で説明されているように、各ILNPノードは、対応する各ノードのILNP通信キャッシュ（ILCC）を維持します。キャッシュ内の情報は、受信したメッセージを検証し、パス外の攻撃者が成功するのを防ぐために使用されます。このプロセスについては、[RFC6741]で詳しく説明されています。
Thirdly, any node can distinguish different nodes using the same Identifier value by other properties of their ILNP sessions. For example, IPv6 Neighbor Discovery prevents more than one node from using the same source I-LV at the same time on the same link [RFC4861]. So, cases of different nodes using the same Identifier value will involve nodes that have different sets of valid Locator values. A node thus can demultiplex based on the combination of Source Locator and Source Identifier if necessary. If IPsec is in use, the combination of the Source Identifier and the Security Parameter Index (SPI) value would be sufficient to demux two different ILNP sessions.
第3に、どのノードでも、ILNPセッションの他のプロパティによって、同じ識別子の値を使用して異なるノードを区別できます。たとえば、IPv6近隣探索は、複数のノードが同じリンクで同じソースI-LVを同時に使用することを防ぎます[RFC4861]。したがって、同じID値を使用する異なるノードのケースには、有効なロケーター値の異なるセットを持つノードが含まれます。したがって、ノードは、必要に応じて、ソースロケータとソース識別子の組み合わせに基づいて逆多重化できます。 IPsecが使用されている場合、2つの異なるILNPセッションを分離するには、ソース識別子とセキュリティパラメータインデックス（SPI）値の組み合わせで十分です。
Fourthly, deployments in high-threat environments also SHOULD use IPsec to authenticate control traffic and data traffic. Because IPsec for ILNP binds only to the Identifier values, and never to the Locator values, a mobile or multihomed node can use IPsec even when its Locator value(s) have just changed.
第4に、脅威の多い環境での展開でもIPsecを使用して制御トラフィックとデータトラフィックを認証する必要があります（SHOULD）。 ILsecのIPsecは識別子の値にのみバインドし、ロケーターの値には決してバインドしないため、モバイルまたはマルチホームノードは、ロケーターの値が変更された場合でもIPsecを使用できます。
Lastly, note well that ordinary IPv4, ordinary IPv6, Mobile IPv4, and also Mobile IPv6 already are vulnerable to forged Identifier and/or forged IP Address attacks. An attacker on the same link as the intended victim simply forges the victims MAC address and the victim's IP Address. With IPv6, when Secure Neighbour Discovery (SEND) and Cryptographically Generated Addresses (CGAs) are in use, the victim node can defend its use of its IPv6 address using SEND. With ILNP, when SEND and CGAs are in use, the victim node also can defend its use of its IPv6 address using SEND. There are no standard mechanisms to authenticate ARP messages, so IPv4 is especially vulnerable to this sort of attack. These attacks also work against Mobile IPv4 and Mobile IPv6. In fact, when either form of Mobile IP is in use, there are additional risks, because the attacks work not only when the attacker has access to the victim's current IP subnetwork but also when the attacker has access to the victim's home IP subnetwork. Thus, the risks of using ILNP are not greater than exist today with IP or Mobile IP.
最後に、通常のIPv4、通常のIPv6、モバイルIPv4、さらにモバイルIPv6は、偽造された識別子や偽造されたIPアドレスの攻撃に対して既に脆弱であることに注意してください。対象の被害者と同じリンク上の攻撃者は、被害者のMACアドレスと被害者のIPアドレスを偽造するだけです。 IPv6では、Secure Neighbor Discovery（SEND）とCryptographically Generated Address（CGA）が使用されている場合、犠牲ノードはSENDを使用してIPv6アドレスの使用を防御できます。 ILNPを使用すると、SENDおよびCGAが使用されている場合、犠牲ノードはSENDを使用してIPv6アドレスの使用を防御することもできます。 ARPメッセージを認証する標準的なメカニズムはないため、IPv4はこの種の攻撃に対して特に脆弱です。これらの攻撃は、モバイルIPv4およびモバイルIPv6に対しても機能します。実際、いずれかの形式のモバイルIPが使用されている場合、攻撃が被害者の現在のIPサブネットワークにアクセスできる場合だけでなく、攻撃者が被害者のホームIPサブネットワークにアクセスできる場合にも攻撃が機能するため、追加のリスクがあります。したがって、ILNPを使用することによるリスクは、IPまたはモバイルIPで現在存在するものよりも大きくありません。
The IPsec standards are enhanced here by binding IPsec Security Associations (SAs) to the Node Identifiers of the endpoints, rather than binding IPsec SAs to the IP Addresses of the endpoints as at present. This change enhances the deployability and interoperability of the IPsec standards, but does not decrease the security provided by those protocols. See Section 7 for a more detailed explanation.
ここでは、現在のようにIPsec SAをエンドポイントのIPアドレスにバインドするのではなく、IPsecセキュリティアソシエーション（SA）をエンドポイントのノード識別子にバインドすることにより、IPsec標準が強化されています。この変更により、IPsec標準の展開性と相互運用性が強化されますが、これらのプロトコルによって提供されるセキュリティは低下しません。詳細については、セクション7を参照してください。
The DNS enhancements proposed here are entirely compatible with, and can be protected using, the existing IETF standards for DNS Security [RFC4033]. The Secure DNS Dynamic Update mechanism used here is also used unchanged [RFC3007]. So, ILNP does not change the security properties of the DNS or of DNS servers.
ここで提案されているDNS拡張機能は、DNSセキュリティ[RFC4033]の既存のIETF標準と完全に互換性があり、これを使用して保護できます。ここで使用されているセキュアDNS動的更新メカニズムは、変更されずに使用されます[RFC3007]。したがって、ILNPはDNSまたはDNSサーバーのセキュリティプロパティを変更しません。
In the proposed new scheme, stateful firewalls are able to authenticate ILNP-specific control messages arriving on the external interface. This enables more thoughtful handling of ICMP messages by firewalls than is commonly the case at present. As the firewall is along the path between the communicating nodes, the firewall can snoop on the ILNP Nonce being carried in the initial packets of an ILNP session. The firewall can verify the correct ILNP Nonce is present on incoming control packets, dropping any control packets that lack the correct nonce value.
提案された新しいスキームでは、ステートフルファイアウォールは、外部インターフェイスに到着するILNP固有の制御メッセージを認証できます。これにより、現在一般的な場合よりも、ファイアウォールによるICMPメッセージのより慎重な処理が可能になります。ファイアウォールは通信ノード間のパスに沿っているため、ファイアウォールはILNPセッションの最初のパケットで運ばれるILNPナンスをスヌープできます。ファイアウォールは、着信制御パケットに正しいILNPナンスが存在することを確認し、正しいnonce値がない制御パケットをドロップできます。
By always including the ILNP Nonce in ILNP-specific control messages, even when IPsec is also in use, the firewall can filter out off-path attacks against those ILNP messages without needing to perform computationally expensive IPsec processing. In any event, a forged packet from an on-path attacker will still be detected when the IPsec input processing occurs in the receiving node; this will cause that forged packet to be dropped rather than acted upon.
IPsecも使用されている場合でも、ILNP固有の制御メッセージにILNP Nonceを常に含めることにより、ファイアウォールは、計算に負荷のかかるIPsec処理を実行する必要なく、それらのILNPメッセージに対するオフパス攻撃を除外できます。いずれの場合も、受信ノードでIPsec入力処理が発生すると、経路上の攻撃者からの偽造パケットが引き続き検出されます。これにより、偽造されたパケットは処理されるのではなく破棄されます。
Nothing in this proposal prevents sites from using the Secure Neighbour Discovery (SEND) proposal for authenticating IPv6 Neighbour Discovery with ILNPv6 [RFC3971].
この提案では、サイトがSecure Neighbor Discovery（SEND）提案を使用して、ILNPv6 [RFC3971]でIPv6近隣探索を認証することを妨げるものはありません。
A site that wishes to obscure its internal topology information MAY do so by deploying site border routers that rewrite the Locator values for the site as packets enter or leave the site. This operational scenario was presented in [ABH09a] and is discussed in more detail in [RFC6748].
内部トポロジー情報を隠したいサイトは、パケットがサイトに出入りするときにサイトのロケーター値を書き換えるサイト境界ルーターを配置することにより、そうすることができます。この運用シナリオは[ABH09a]で提示され、[RFC6748]でより詳細に説明されています。
For example, a site might choose to use a ULA prefix internally for this reason [RFC4193] [ID-ULA]. In this case, the site border routers would rewrite the Source Locator of ILNP packets leaving the site to a global-scope Locator associated with the site. Also, those site border routers would rewrite the Destination Locator of packets entering the site from the global-scope Locator to an appropriate interior ULA Locator for the destination node [ABH08b] [ABH09a] [RFC6748].
たとえば、サイトがこの理由で内部的にULAプレフィックスを使用することを選択する場合があります[RFC4193] [ID-ULA]。この場合、サイト境界ルーターは、サイトを離れるILNPパケットのソースロケーターを、サイトに関連付けられたグローバルスコープロケーターに書き換えます。また、これらのサイト境界ルーターは、サイトに入るパケットの宛先ロケーターをグローバルスコープロケーターから宛先ノードの適切な内部ULAロケーターに書き換えます[ABH08b] [ABH09a] [RFC6748]。
ILNP has support for both:
ILNPは次の両方をサポートしています。
- Location Privacy: to hide a node's topological location by obfuscating the ILNP Locator information. (See also Section 7 of [RFC6748].)
- ロケーションプライバシー：ILNPロケーター情報を難読化することにより、ノードのトポロジロケーションを非表示にします。 （[RFC6748]のセクション7もご覧ください）。
- Identity Privacy: to hide a node's identity by allowing the use of Node Identifier values that are not tied to the node in some permanent or semi-permanent manner. (See also Section 11 of [RFC6741].)
- IDプライバシー：永続的または半永続的な方法でノードに関連付けられていないノードID値の使用を許可することにより、ノードのIDを非表示にします。 （[RFC6741]のセクション11もご覧ください）。
A more detailed exposition of the possibilities is given in [BAK11].
可能性のより詳細な説明は[BAK11]で与えられます。
Some users have concerns about the issue of "location privacy", whereby the user's location might be determined by others. The term "location privacy" does not have a crisp definition within the Internet community at present. Some mean the location of a node relative to the Internet's routing topology, while others mean the geographic coordinates of the node (i.e., latitude X, longitude Y). The concern seems to focus on Internet-enabled devices, most commonly handheld devices such as a smartphone, that might have 1:1 mappings with individual users.
一部のユーザーは、「場所のプライバシー」の問題について懸念を抱いており、ユーザーの場所は他のユーザーによって決定される場合があります。 「ロケーションプライバシー」という用語は、現在インターネットコミュニティ内で明確に定義されていません。インターネットのルーティングトポロジに対するノードの場所を意味するものもあれば、ノードの地理座標（つまり、緯度X、経度Y）を意味するものもあります。懸念は、インターネット対応デバイス、最も一般的にはスマートフォンなどのハンドヘルドデバイスに集中しており、個々のユーザーと1：1でマッピングされる可能性があります。
There is a fundamental trade-off here. Quality of a node's Internet connectivity tends to be inversely proportional to the "location privacy" of that node. For example, if a node were to use a router with NAT as a privacy proxy, routing all traffic to and from the Internet via that proxy, then (a) latency will increase as the distance increases between the node seeking privacy and its proxy, and (b) communications with the node seeking privacy will be more vulnerable to communication faults -- both due to the proxy itself (which might fail) and due to the longer path (which has more points of potential failure than a more direct path would have).
ここには根本的なトレードオフがあります。ノードのインターネット接続の品質は、そのノードの「ロケーションプライバシー」に反比例する傾向があります。たとえば、ノードがNATを備えたルーターをプライバシープロキシとして使用し、そのプロキシを介してインターネットとの間のすべてのトラフィックをルーティングする場合、（a）プライバシーを求めるノードとそのプロキシの間の距離が増加すると、遅延が増加します。 （b）プライバシーを求めるノードとの通信は、通信障害に対してより脆弱になります-プロキシ自体（失敗する可能性があります）と長いパス（直接パスよりも潜在的な障害のポイントが多いため）の両方が原因です。持ってる）。
Any Internet node that wishes for other Internet nodes to be able to initiate transport-layer or network-layer sessions with it needs to include associated address (e.g., A, AAAA) or Locator (e.g., L32, L64, LP) records in the publicly accessible Domain Name System (DNS). Information placed in the DNS is publicly accessible. Since the goal of DNS is to distribute information to other Internet nodes, it does not provide mechanisms for selective privacy. Of course, a node that does not wish to be contacted need not be present in the DNS.
他のインターネットノードがトランスポート層またはネットワーク層のセッションを開始できるようにするインターネットノードは、関連するアドレス（A、AAAAなど）またはロケーター（L32、L64、LPなど）のレコードを公的にアクセス可能なドメインネームシステム（DNS）。 DNSに配置された情報は一般にアクセス可能です。 DNSの目的は他のインターネットノードに情報を配信することであるため、選択的なプライバシーのメカニズムは提供しません。もちろん、接続したくないノードがDNSに存在する必要はありません。
In some cases, various parties have attempted to create mappings between IP Address blocks and geographic locations. The quality of such mappings appears to vary [GUF07]. Many such mapping efforts are driven themselves by efforts to comply with legal requirements in various legal jurisdictions. For example, some content providers reportedly have licenses authorising distribution of content in one set of locations, but not in a different set of locations.
場合によっては、さまざまな関係者がIPアドレスブロックと地理的位置の間のマッピングを作成しようとしました。このようなマッピングの品質はさまざまです[GUF07]。このようなマッピングの取り組みの多くは、さまざまな法域の法的要件に準拠するための取り組みによって推進されています。たとえば、一部のコンテンツプロバイダーは、ある場所のセットでのコンテンツの配布を許可するライセンスを持っていると報告されていますが、別の場所のセットでは許可されていません。
ILNP does not compromise user location privacy any more than base IPv6. In fact, by its nature ILNP provides additional choices to the user to protect their location privacy.
ILNPは、ベースIPv6を超えてユーザーロケーションのプライバシーを侵害しません。実際、ILNPはその性質上、位置プライバシーを保護するためにユーザーに追加の選択肢を提供します。
Both ILNP and IPv6 permit use of identifier values generated using the IPv6 Privacy Address extension [RFC4941]. ILNP and IPv6 also support a node having multiple unicast addresses/locators at the same time, which facilitates changing the node's addresses/locators over time. IPv4 does not have any non-topological identifiers, and many IPv4 nodes only support one IPv4 unicast address per interface, so IPv4 is not directly comparable with IPv6 or ILNP.
ILNPとIPv6の両方で、IPv6プライバシーアドレス拡張[RFC4941]を使用して生成された識別子の値を使用できます。 ILNPおよびIPv6は、同時に複数のユニキャストアドレス/ロケーターを持つノードもサポートします。これにより、時間の経過とともにノードのアドレス/ロケーターを簡単に変更できます。 IPv4には非トポロジーIDがなく、多くのIPv4ノードはインターフェースごとに1つのIPv4ユニキャストアドレスしかサポートしないため、IPv4はIPv6またはILNPと直接比較できません。
In normal operation with IPv4, IPv6, or ILNP, a mobile node might intend to be accessible for new connection attempts from the global Internet and also might wish to have both optimal routing and maximal Internet availability, both for sent and received packets. In that case, the node will want to have its addressing or location information kept in the DNS and made available to others.
IPv4、IPv6、またはILNPを使用した通常の動作では、モバイルノードはグローバルインターネットからの新しい接続試行のためにアクセスできるようになり、送信パケットと受信パケットの両方に対して最適なルーティングと最大のインターネット可用性の両方が必要になる場合があります。その場合、ノードはそのアドレスまたは位置情報をDNSに保持し、他のユーザーが利用できるようにする必要があります。
In some cases, a mobile node might only desire to initiate network-layer or transport-layer sessions with other Internet nodes, and thus not desire to be a responder, in which case that node need not be present in the DNS. Some potential correspondent nodes might, as a matter of local security policy, decline to communicate with nodes that do not have suitable DNS records present in the DNS. For example, some deployed IPv4-capable mail relays refuse to communicate with an initiating node that lacks an appropriate PTR record in the DNS.
場合によっては、モバイルノードは他のインターネットノードとのネットワーク層またはトランスポート層のセッションを開始することのみを望み、レスポンダになることを望まない場合があります。その場合、そのノードはDNSに存在する必要はありません。一部の潜在的なコレスポンデントノードは、ローカルセキュリティポリシーの問題として、適切なDNSレコードがDNSに存在しないノードとの通信を拒否する場合があります。たとえば、配備された一部のIPv4対応メールリレーは、DNSに適切なPTRレコードがない開始ノードとの通信を拒否します。
In some cases (for example, intermittent electronic mail access or browsing specific web pages), support for long-lived network sessions (i.e., where network-layer session lifetime is longer than the time the node remains on the same subnetwork) is not required. In those cases, support for node mobility (i.e., network-layer session continuity even when the SNPA changes) is not required and need not be used.
場合によっては（たとえば、断続的な電子メールアクセスや特定のWebページの閲覧）、長寿命のネットワークセッション（つまり、ネットワークレイヤーセッションの存続時間がノードが同じサブネットワークに留まっている時間よりも長い場合）のサポートは不要です。 。このような場合、ノードモビリティのサポート（つまり、SNPAが変更された場合でもネットワークレイヤーセッションの継続性）は不要であり、使用する必要はありません。
If an ILNP node that is mobile chooses not to use DNS for rendezvous, yet desires to permit any node on the global Internet to initiate communications with that node, then that node may fall back to using Mobile IPv4 or Mobile IPv6 instead.
モバイルのILNPノードがランデブーにDNSを使用しないことを選択したが、グローバルインターネット上の任意のノードがそのノードとの通信を開始することを許可したい場合、そのノードは代わりにモバイルIPv4またはモバイルIPv6の使用にフォールバックする場合があります。
Many residential broadband Internet users are subject to involuntary renumbering, usually when their ISP's DHCP server(s) deny a DHCP RENEW request and instead issue different IP addressing information to the residential user's device(s). In many cases, such users want their home server(s) or client(s) to be externally reachable. Such users today often use Secure DNS Dynamic Update to update their addressing or location information in the DNS entries, for the devices they wish to make reachable from the global Internet [RFC2136] [RFC3007] [LA2006]. This option exists for those users, whether they use IPv4, IPv6, or ILNP. Users also have the option not to use such mechanisms.
多くの住宅のブロードバンドインターネットユーザーは、通常、ISPのDHCPサーバーがDHCP RENEW要求を拒否し、代わりに住宅のユーザーのデバイスに異なるIPアドレッシング情報を発行する場合、非自発的な再番号付けの対象となります。多くの場合、このようなユーザーは、ホームサーバーまたはクライアントに外部からアクセスできるようにしたいと考えています。このようなユーザーは今日、グローバルDNS [RFC2136] [RFC3007] [LA2006]から到達可能にしたいデバイスに対して、Secure DNS Dynamic Updateを使用してDNSエントリのアドレス情報または場所情報を更新します。このオプションは、ユーザーがIPv4、IPv6、ILNPのいずれを使用しているかに関係なく存在します。ユーザーは、このようなメカニズムを使用しないオプションもあります。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[RFC826] Plummer、D.、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、1982年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[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月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「Default Protocol Selection for Internet Protocol Version 6（IPv6）」、RFC 6724、2012年9月。
[RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations", RFC 6741, November 2012.
[RFC6741] Atkinson、R。およびS. Bhatti、「Identifier-Locator Network Protocol（ILNP）Engineering and Implementation Considerations」、RFC 6741、2012年11月。
[RFC6742] Atkinson, R., Bhatti, S., and S. Rose, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", RFC 6742, November 2012.
[RFC6742] Atkinson、R.、Bhatti、S。、およびS. Rose、「Identifier-Locator Network Protocol（ILNP）のDNSリソースレコード」、RFC 6742、2012年11月。
[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。
[8+8] O'Dell, M., "8+8 - An Alternate Addressing Architecture for IPv6", Work in Progress, October 1996.
[8 + 8] O'Dell、M。、「8 + 8-IPv6の代替アドレス指定アーキテクチャ」、作業中、1996年10月。
[ABH07a] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an Integrated Service Through the Use of Naming", Proceedings of ACM MobiArch 2007, August 2007, Kyoto, Japan.
[ABH07a] Atkinson、R.、Bhatti、S。、およびS. Hailes、「ネーミングの使用による統合サービスとしてのモビリティ」、ACM MobiArch 2007、2007年8月、京都、日本。
[ABH07b] Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for Unifying Mobility with Multi-Homing, NAT, & Security", Proceedings of ACM MobiWAC 2007, Chania, Crete. ACM, October 2007.
[ABH07b] Atkinson、R.、Bhatti、S。、およびS. Hailes、「マルチホーミング、NAT、およびセキュリティでモビリティを統合するための提案」、ACM MobiWAC 2007の議事録、ハニア、クレタ。 ACM、2007年10月。
[ABH08a] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through Naming: Impact on DNS", Proceedings of ACM MobiArch 2008, August 2008, ACM, Seattle, WA, USA.
[ABH08a] Atkinson、R.、Bhatti、S.、and S. Hailes、 "Mobility Through Naming：Impact on DNS"、Proceedings of ACM MobiArch 2008、August 2008、ACM、Seattle、WA、USA。
[ABH08b] Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised Resilience, Security, and Mobility Capability for IP", Proceedings of IEEE Military Communications (MILCOM) Conference, San Diego, CA, USA, November 2008.
[ABH08b] Atkinson、R.、Bhatti、S.、and S. Hailes、 "Harmonised Resilience、Security、and Mobility Capability for IP"、Proceedings of IEEE Military Communications（MILCOM）Conference、San Diego、CA、USA、2008年11月。
[ABH09a] Atkinson, R., Bhatti, S., and S. Hailes, "Site-Controlled Secure Multi-Homing and Traffic Engineering For IP", Proceedings of IEEE Military Communications (MILCOM) Conference, Boston, MA, USA, October 2009.
[ABH09a] Atkinson、R.、Bhatti、S.、and S. Hailes、 "Site-Controlled Secure Multi-Homing and Traffic Engineering For IP"、Proceedings of IEEE Military Communications（MILCOM）Conference、Boston、MA、USA、October 2009。
[ABH09b] Atkinson, R., Bhatti, S., and S. Hailes, "ILNP: Mobility, Multi-Homing, Localised Addressing and Security Through Naming", Telecommunications Systems, Volume 42, Number 3-4, pp. 273-291, Springer-Verlag, December 2009, ISSN 1018-4864.
[ABH09b] Atkinson、R.、Bhatti、S.、and S. Hailes、 "ILNP：Mobility、Multi-Homing、Localized Addressing and Security Through Naming"、Telecommunications Systems、Volume 42、Number 3-4、pp。273- 291、Springer-Verlag、2009年12月、ISSN 1018-4864。
[ABH10] Atkinson, R., Bhatti, S., S. Hailes, "Evolving the Internet Architecture Through Naming", IEEE Journal on Selected Areas in Communication (JSAC), vol. 28, no. 8, pp. 1319-1325, IEEE, Piscataway, NJ, USA, Oct 2010.
[ABH10] Atkinson、R.、Bhatti、S.、S. Hailes、 "Evolving the Internet Architecture through Naming"、IEEE Journal on Selected Areas in Communication（JSAC）、vol。 28、いいえ。 8、pp。1319-1325、IEEE、Piscataway、NJ、USA、Oct 2010。
[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日。
[BA12] Bhatti, S. and R. Atkinson, "Secure and Agile Wide-area Virtual Machine Mobility", Proceedings of IEEE Military Communications Conference (MILCOM), Orlando, FL, USA, Oct 2012.
[BA12] Bhatti、S。およびR. Atkinson、「Secure and Agile Wide-area Virtual Machine Mobility」、Proceedings of IEEE Military Communications Conference（MILCOM）、Orlando、FL、USA、2012年10月。
[BAK11] Bhatti, S., Atkinson, R., and J. Klemets, "Integrating Challenged Networks", Proceedings of IEEE Military Communications Conference (MILCOM), Baltimore, MD, USA, November 2011.
[BAK11] Bhatti、S.、Atkinson、R。、およびJ. Klemets、「Integrating Challenged Networks」、Proceedings of IEEE Military Communications Conference（MILCOM）、Baltimore、MD、USA、2011年11月。
[CA-1995-01] US CERT, "IP Spoofing Attacks and Hijacked Terminal Connections", CERT Advisory 1995-01, Issued 23 Jan 1995, Revised 23 Sep 1997.
[CA-1995-01] US CERT、「IPスプーフィング攻撃とハイジャックされた端末接続」、CERT Advisory 1995-01、1995年1月23日発行、1997年9月23日改訂。
[DIA] Defense Intelligence Agency, "Compartmented Mode Workstation Specification", Technical Report DDS-2600-6243-87, US Defense Intelligence Agency, Bolling AFB, DC, USA.
[DIA]国防情報局、「コンパートメントモードワークステーション仕様」、テクニカルレポートDDS-2600-6243-87、米国国防情報局、Bolling AFB、DC、米国。
[DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD, USA, December 1985.
[DoD85]米国国立コンピューターセキュリティセンター、「国防総省の信頼できるコンピューターシステムの評価基準」、DoD 5200.28-STD、米国国防総省、フォート。ミード、メリーランド州、米国、1985年12月。
[DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD, USA, 31 July 1987.
[DoD87] US National Computer Security Center、「Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria」、NCSC-TG-005、バージョン1、米国国防総省、フォート。ミード、メリーランド州、米国、1987年7月31日。
[GSE] O'Dell, M., "GSE - An Alternate Addressing Architecture for IPv6", Work in Progress, February 1997.
[GSE] O'Dell、M。、「GSE-IPv6の代替アドレス指定アーキテクチャ」、作業中、1997年2月。
[GUF07] Gueye, B., Uhlig, S., and S. Fdida, "Investigating the Imprecision of IP Block-Based Geolocation", Lecture Notes in Computer Science, Volume 4427, pp. 237-240, Springer-Verlag, Heidelberg, Germany, 2007.
[GUF07] Gueye、B.、Uhlig、S。、およびS. Fdida、「IPブロックベースの地理位置情報の不正確さの調査」、コンピュータサイエンスの講義ノート、第4427巻、237〜240ページ、Springer-Verlag、ハイデルベルク、ドイツ、2007年。
[ID-ULA] Hinden, R., Huston, G., and T. Narten, "Centrally Assigned Unique Local IPv6 Unicast Addresses", Work in Progress, June 2007.
[ID-ULA] Hinden、R.、Huston、G。、およびT. Narten、「中央で割り当てられた一意のローカルIPv6ユニキャストアドレス」、2007年6月、作業中。
[IEEE-EUI] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", Piscataway, NJ, USA, March 1997, <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[IEEE-EUI] IEEE、「64ビットグローバルID（EUI-64）登録局のガイドライン」、米国ニュージャージー州ピスカタウェイ、1997年3月、<http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>。
[IEN1] Bennett, C., Edge, S., and A. Hinchley, "Issues in the Interconnection of Datagram Networks", Internet Experiment Note (IEN) 1, INDRA Note 637, PSPWN 76, 29 July 1977, <http://www.rfc-editor.org/ien/ien1.pdf>.
[IEN1]ベネット、C。、エッジ、S。、およびA.ヒンチリー、「データグラムネットワークの相互接続の問題」、インターネット実験ノート（IEN）1、INDRAノート637、PSPWN 76、1977年7月29日、<http： //www.rfc-editor.org/ien/ien1.pdf>。
[IEN19] Shoch, J., "Inter-Network Naming, Addressing, and Routing", IEN 19, January 1978, <http://www.rfc-editor.org/ien/ien19.txt>.
[IEN19] Shoch、J。、「Inter-Network Naming、Addressing、and Routing」、IEN 19、January 1978、<http://www.rfc-editor.org/ien/ien19.txt>。
[IEN23] Cohen, D., "On Names, Addresses, and Routings", IEN 23, January 1978, <http://www.rfc-editor.org/ien/ien23.pdf>.
[IEN23]コーエン、D。、「名前、アドレス、およびルーティングについて」、IEN 23、1978年1月、<http://www.rfc-editor.org/ien/ien23.pdf>。
[IEN31] Cohen, D., "On Names, Addresses, and Routings (II)", IEN 31, April 1978, <http://www.rfc-editor.org/ien/ien31.pdf>.
[IEN31]コーエン、D。、「名前、アドレス、およびルーティング（II）」、IEN 31、1978年4月、<http://www.rfc-editor.org/ien/ien31.pdf>。
[IEN135] Sunshine, C. and J. Postel, "Addressing Mobile Hosts in the ARPA Internet Environment", IEN 135, March 1980, <http://www.rfc-editor.org/ien/ien135.pdf>.
[IEN135] Sunshine、C。およびJ. Postel、「ARPAインターネット環境でのモバイルホストのアドレス指定」、IEN 135、1980年3月、<http://www.rfc-editor.org/ien/ien135.pdf>。
[IPng95] Clark, D., "A thought on addressing", electronic mail message to IETF IPng WG, Message-ID: 9501111901.AA28426@caraway.lcs.mit.edu, Laboratory for Computer Science, MIT, Cambridge, MA, USA, 11 January 1995.
[IPng95]クラークD.、「アドレス指定についての考え」、IETF IPng WGへの電子メールメッセージ、メッセージID：9501111901.AA28426@caraway.lcs.mit.edu、コンピュータサイエンス研究所、MIT、ケンブリッジ、MA、米国、1995年1月11日。
[LA2006] Liu, C. and P. Albitz, "DNS & Bind", 5th Edition, O'Reilly & Associates, Sebastopol, CA, USA, May 2006, ISBN 0-596-10057-4.
[LA2006] Liu、C。およびP. Albitz、「DNS and Bind」、第5版、O'Reilly＆Associates、カリフォルニア州セバストポル、米国、2006年5月、ISBN 0-596-10057-4。
[LABH06] Lad, M., Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for Coalition Networking in Dynamic Operational Environments", Proceedings of IEEE Military Communications Conference, Washington, DC, USA, Nov. 2006.
[LABH06] Lad、M.、Atkinson、R.、Bhatti、S。、およびS. Hailes、「動的運用環境における連合ネットワーキングの提案」、IEEE軍事通信会議の議事録、ワシントンDC、米国、11月。 2006年
[PHG02] Pappas, A., Hailes, S., and R. Giaffreda, "Mobile Host Location Tracking through DNS", Proceedings of IEEE London Communications Symposium, IEEE, London, England, UK, September 2002.
[PHG02] Pappas、A.、Hailes、S。、およびR. Giaffreda、「DNSによるモバイルホストロケーショントラッキング」、IEEEロンドンコミュニケーションシンポジウムの議事録、IEEE、ロンドン、イギリス、イギリス、2002年9月。
[RAB09] Rehunathan, D., Atkinson, R., and S. Bhatti, "Enabling Mobile Networks Through Secure Naming", Proceedings of IEEE Military Communications Conference (MILCOM), Boston, MA, USA, October 2009.
[RAB09] Rehunathan、D.、Atkinson、R。、およびS. Bhatti、「Enabling Mobile Networks Through Secure Naming」、Proceedings of IEEE Military Communications Conference（MILCOM）、Boston、MA、USA、2009年10月。
[RB10] Rehunathan, D. and S. Bhatti, "A Comparative Assessment of Routing for Mobile Networks", Proceedings of IEEE International Conference on Wireless and Mobile Computing Networking and Communications (WiMob), IEEE, Niagara Falls, ON, Canada, Oct. 2010.
[RB10] Rehunathan、D。およびS. Bhatti、「モバイルネットワークのルーティングの比較評価」、IEEE International Conference on Wireless and Mobile Computing Networking and Communications（WiMob）、IEEE、ナイアガラフォールズ、ON、カナダ、10月。2010。
[SBK01] 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.
[SBK01] Snoeren、A.、Balakrishnan、H。、およびM. Frans Kaashoek、「インターネットモビリティの再考」、オペレーティングシステムのホットトピックに関する第8回ワークショップの議事録、IEEE、ドイツ、エルマウ、2001年5月。
[SIPP94] Smart, B., "Re: IPng Directorate meeting in Chicago; possible SIPP changes", electronic mail to the IETF SIPP WG mailing list, Message-ID: 199406020647.AA09887@shark.mel.dit.csiro.au, Commonwealth Scientific & Industrial Research Organisation (CSIRO), Melbourne, VIC, 3001, Australia, 2 June 1994.
[SIPP94]スマート、B。、「Re：シカゴでのIPng理事会会議、可能性のあるSIPPの変更」、IETF SIPP WGメーリングリストへの電子メール、メッセージID：199406020647.AA09887@shark.mel.dit.csiro.au、 Commonwealth Scientific＆Industrial Research Organization（CSIRO）、メルボルン、VIC、3001、オーストラリア、1994年6月2日。
[SRC84] Saltzer, J., Reed, D., and D. Clark, "End to End Arguments in System Design", ACM Transactions on Computer Systems, Volume 2, Number 4, ACM, New York, NY, USA, November 1984.
[SRC84] Saltzer、J.、Reed、D。、およびD. Clark、「End to End Arguments in System Design」、ACM Transactions on Computer Systems、Volume 2、Number 4、ACM、ニューヨーク、NY、USA、11月1984年。
[RFC814] Clark, D., "Name, addresses, ports, and routes", RFC 814, July 1982.
[RFC814]クラークD.、「名前、アドレス、ポート、ルート」、RFC 814、1982年7月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993.
[RFC1498] Saltzer、J。、「ネットワーク宛先の命名とバインディングについて」、RFC 1498、1993年8月。
[RFC1631] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
[RFC1631] Egevang、K。およびP. Francis、「The IP Network Address Translator（NAT）」、RFC 1631、1994年5月。
[RFC1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[RFC1825] Atkinson、R。、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 1825、1995年8月。
[RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[RFC1826] Atkinson、R。、「IP Authentication Header」、RFC 1826、1995年8月。
[RFC1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[RFC1827] Atkinson、R。、「IP Encapsulating Security Payload（ESP）」、RFC 1827、1995年8月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]カーペンター、B。、編、「インターネットのアーキテクチャ原則」、RFC 1958、1996年6月。
[RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996.
[RFC1992] Castineyra、I.、Chiappa、N。、およびM. Steenstrup、「The Nimrod Routing Architecture」、RFC 1992、1996年8月。
[RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, October 1996.
[RFC2002]パーキンス、C。、編、「IPモビリティサポート」、RFC 2002、1996年10月。
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC2101] Carpenter、B.、Crowcroft、J。、およびY. Rekhter、「IPv4 Address Behavior Today」、RFC 2101、1997年2月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Ed。、Thomson、S.、Rekhter、Y.、and J. Bound、 "Dynamic Updates in the Domain Name System（DNS UPDATE）"、RFC 2136、April 1997。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、1999年10月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを採用するサービス拒否攻撃の打破」、BCP 38、RFC 2827、2000年5月。
[RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", RFC 2956, October 2000.
[RFC2956] Kaat、M。、「Overview of 1999 IAB Network Layer Workshop」、RFC 2956、2000年10月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[RFC3027] Holdrege、M。およびP. Srisuresh、「プロトコルの複雑化とIPネットワークアドレストランスレータ」、RFC 3027、2001年1月。
[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月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F。、およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B。およびW. Dixon、「IPsecネットワークアドレス変換（NAT）互換性要件」、RFC 3715、2004年3月。
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。、編、およびL. Costa、編、「IPv6のマルチキャストリスナーディスカバリバージョン2（MLDv2）」、RFC 3810、2004年6月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、DiBurro、L。、およびM. Stenberg、「IPsec ESPパケットのUDPカプセル化」、RFC 3948、2005年1月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、March 2005。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、2005年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[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月。
[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月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「Stream Control Transmission Protocol（SCTP）Dynamic Address Reconfiguration」、RFC 5061、2007年9月。
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, July 2009.
[RFC5570] StJohns、M.、Atkinson、R。、およびG. Thomas、「Common Architecture Label IPv6 Security Option（CALIPSO）」、RFC 5570、2009年7月。
[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月。
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May 2011.
[RFC6250]ターラーD。、「IPモデルの進化」、RFC 6250、2011年5月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Ed。、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[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問題の技術的および手続き的側面について専門家のガイダンスを提供しました。
Noel Chiappa graciously provided the authors with copies of the original email messages cited here as [SIPP94] and [IPng95], which enabled the precise citation of those messages herein.
Noel Chiappaは、ここで[SIPP94]および[IPng95]として引用されている元の電子メールメッセージのコピーを著者に提供してくれたため、これらのメッセージを正確に引用できました。
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