[要約] RFC 6748は、ILNP（Identifier-Locator Network Protocol）のオプションの高度な展開シナリオに関する情報を提供します。このRFCの目的は、ILNPの展開に関するガイダンスを提供し、ネットワークアーキテクチャの進化に対応するための柔軟性を提供することです。
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6748 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)
Identifier-Locator Network Protocol（ILNP）のオプションの高度な導入シナリオ
Abstract
概要
This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems.
このドキュメントでは、IPへの進化的拡張であるIdentifier-Locator Network Protocol（ILNP）のいくつかのオプションの高度な展開シナリオのアーキテクチャの説明と操作の概念を提供します。ここで説明する機能は、ILNPの使用または展開に必要ありません。代わりに、ILNPベースのシステムの管理の強化された機能または利便性を提供する可能性のあるエンジニアリングおよび展開オプションの説明を提供します。
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/rfc6748.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6748で入手できます。
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 ....................................................4
1.1. Document Roadmap ...........................................5
1.2. Terminology ................................................6
2. Localised Numbering .............................................6
2.1. Localised Locators .........................................7
2.2. Mixed Local/Global Numbering ...............................9
2.3. Dealing with Internal Subnets with Locator Rewriting .......9
2.4. Localised Name Resolution with DNS ........................11
2.5. Use of mDNS ...............................................13
2.6. Site Network Name in DNS ..................................13
2.7. Site Interior Topology Obfuscation ........................14
2.8. Other SBR Considerations ..................................14
3. An Alternative for Site Multihoming ............................16
3.1. Site Multihoming (S-MH) Connectivity Using an SBR .........16
3.2. Dealing with Link/Connectivity Changes ....................17
3.3. SBR Updates to DNS ........................................18
3.4. DNS TTL Values for L32 and L64 Records ....................18
3.5. Multiple SBRs .............................................19
4. An Alternative for Site (Network) Mobility .....................20
4.1. Site (Network) Mobility ...................................20
4.2. SBR Updates to DNS ........................................22
4.3. DNS TTL Values for L32 and L64 Records ....................22
5. Traffic Engineering Options ....................................22
5.1. Load Balancing ............................................23
5.2. Control of Egress Traffic Paths ...........................24
6. ILNP in Datacentres ............................................26
6.1. Virtual Image Mobility within a Single Datacentre .........27
6.2. Virtual Image Mobility between Datacentres - Invisible ....28
6.3. Virtual Image Mobility between Datacentres - Visible ......29
6.4. ILNP Capability in the Remote Host for VM Image Mobility ..29
7. Location Privacy ...............................................30
7.1. Locator Rewriting Relay (LRR) .............................30
7.2. Options for Installing LRR Packet Forwarding State ........31
8. Identity Privacy ...............................................32
9. Security Considerations ........................................32
10. References ....................................................33
10.1. Normative References .....................................33
10.2. Informative References ...................................34
11. Acknowledgements ..............................................37
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つのクラスは「マップとカプセル化」と呼ばれることが多く、トラフィックはマップされ、インターネットのドメイン間コアを介してトンネリングされます。検討中の別のクラスは、「識別子/ロケータースプリット」と呼ばれることもあります。この文書は、進化論的アプローチの後者のクラスにある提案に関連しています。
ILNP is, in essence, an end-to-end architecture: the functions required for ILNP are implemented in, and controlled by, only those end-systems that wish to use ILNP, as described in [RFC6740]. Other nodes, such as Site Border Routers (SBRs) need only support IP to allow operation of ILNP, e.g., an SBR should support IPv6 in order to enable end-systems to operate ILNPv6 within the site network for which an SBR provides a service [RFC6741].
ILNPは、本質的に、エンドツーエンドのアーキテクチャです。ILNPに必要な機能は、[RFC6740]で説明されているように、ILNPを使用したいエンドシステムでのみ実装および制御されます。サイトボーダールーター（SBR）などの他のノードは、IPのみをサポートしてILNPの操作を許可する必要があります。たとえば、SBRがサービスを提供するサイトネットワーク内でエンドシステムがILNPv6を操作できるようにするには、SBRがIPv6をサポートする必要があります[ RFC6741]。
However, some features of ILNP could be optimised, from an engineering perspective, by the use of an intermediate system (a router, security gateway or "middlebox") that modifies (rewrites) Locator values of transit ILNP packets. It would also perform other control functions for an entire site, as an administrative convenience, such as providing a centralised point of management for a site. For example, an SBR might manipulate the topological presence of the packet, providing an elegant solution to the provision of functions such as site (network) mobility for an entire end site [ABH09a].
ただし、ILNPのいくつかの機能は、トランジットILNPパケットのロケーター値を変更（書き換え）する中間システム（ルーター、セキュリティゲートウェイ、または「ミドルボックス」）を使用することにより、エンジニアリングの観点から最適化できます。また、サイトの集中管理ポイントを提供するなど、管理上の便宜として、サイト全体の他の制御機能も実行します。たとえば、SBRはパケットのトポロジの存在を操作し、エンドサイト全体のサイト（ネットワーク）モビリティなどの機能の提供に洗練されたソリューションを提供します[ABH09a]。
This document discusses several such optional advanced deployment scenarios for ILNP. These typically use an ILNP-capable Site Border Router (SBR).
このドキュメントでは、ILNPのこうしたオプションの高度な展開シナリオについて説明します。これらは通常、ILNP対応のSite Border Router（SBR）を使用します。
Nothing in this document is a requirement for any ILNP implementation or any ILNP deployment.
このドキュメントでは、ILNPの実装またはILNPの展開の要件はありません。
Readers are strongly advised to first read the ILNP Architecture Description [RFC6740], as this document uses the notation and terminology described or referenced in that document.
このドキュメントでは、そのドキュメントで説明または参照されている表記法と用語を使用しているため、読者は最初にILNPアーキテクチャの説明[RFC6740]を読むことを強くお勧めします。
This document describes engineering and implementation considerations that are common to ILNP for both IPv4 and IPv6.
このドキュメントでは、IPv4とIPv6の両方で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) [RFC6740] is the main architectural description of ILNP, including the concept of operations.
a) [RFC6740]は、運用の概念を含む、ILNPの主要なアーキテクチャの説明です。
b) [RFC6741] describes engineering and implementation considerations that are common to both ILNPv4 and ILNPv6.
b) [RFC6741]では、ILNPv4とILNPv6の両方に共通するエンジニアリングと実装の考慮事項について説明しています。
c) [RFC6742] defines additional DNS resource records that support ILNP.
c) [RFC6742]は、ILNPをサポートする追加のDNSリソースレコードを定義します。
d) [RFC6743] defines a new ICMPv6 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
d) [RFC6743]は、ILNPノードがその対応するノードに有効なロケーターのセットに対する変更を通知するために使用する新しいICMPv6ロケーター更新メッセージを定義します。
e) [RFC6744] defines a new IPv6 Nonce Destination Option used by ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by inclusion within the initial packets of an ILNP session) that the node is operating in the ILNP mode and (2) to prevent off-path attacks against ILNP ICMP messages. This Nonce is used, for example, with all ILNP ICMPv6 Locator Update messages that are exchanged among ILNP correspondent nodes.
e) [RFC6744]は、ILNPv6ノードによって使用される新しいIPv6ナンス宛先オプションを定義して（1）ILNP対応ノードに（ILNPセッションの初期パケット内に含めることにより）ノードがILNPモードで動作していることを示し、（2） ILNP ICMPメッセージに対するオフパス攻撃。このノンスは、たとえば、ILNP対応ノード間で交換されるすべてのILNP ICMPv6ロケーター更新メッセージで使用されます。
f) [RFC6745] defines a new ICMPv4 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
f) [RFC6745]は、ILNPノードが対応するノードに有効なロケーターのセットに対する変更を通知するために使用する新しいICMPv4ロケーター更新メッセージを定義します。
g) [RFC6746] defines a new IPv4 Nonce Option used by ILNPv4 nodes to carry a security nonce to prevent off-path attacks against ILNP ICMP messages and also defines a new IPv4 Identifier Option used by ILNPv4 nodes.
g) [RFC6746]は、ILNPv4ノードによって使用される新しいIPv4 Nonceオプションを定義して、ILNP ICMPメッセージに対するオフパス攻撃を防ぐためのセキュリティナンスを伝送し、ILNPv4ノードによって使用される新しいIPv4識別子オプションも定義します。
h) [RFC6747] describes extensions to Address Resolution Protocol (ARP) for use with ILNPv4.
h) [RFC6747]は、ILNPv4で使用するためのアドレス解決プロトコル（ARP）の拡張について説明しています。
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]で説明されているように解釈されます。
Today, Network Address Translation (NAT) [RFC3022] is used for a number of purposes. Whilst one of the original intentions of NAT was to reduce the rate of use of global IPv4 addresses, through use of IPv4 private address space [RFC1918], NAT also offers to site administrators a convenient localised address management capability combined with a local-scope/private address space, for example, [RFC1918] for IPv4.
現在、ネットワークアドレス変換（NAT）[RFC3022]はさまざまな目的で使用されています。 NATの当初の目的の1つは、IPv4プライベートアドレス空間[RFC1918]を使用してグローバルIPv4アドレスの使用率を下げることでしたが、NATはサイト管理者にローカルスコープ/プライベートアドレススペース。たとえば、IPv4の[RFC1918]。
For IPv6, NAT would not necessarily be required to reduce the rate of IPv6 address depletion, because the availability of addresses is not such an issue as for IPv4. The IETF has standardised Unique Local IPv6 Unicast Addresses [RFC4193], which provide local-scope IPv6 unicast address space that can be used by end sites. However, localised address management, in a manner similar to that provided by IPv4 NAT and private address space [RFC1918], is still desirable for IPv6 [RFC5902], even though there is debate about the efficacy of such an approach [RFC4864].
IPv6の場合、アドレスの可用性はIPv4の場合のような問題ではないため、NATは必ずしもIPv6アドレスの枯渇率を下げる必要はありません。 IETFは、固有のローカルIPv6ユニキャストアドレス[RFC4193]を標準化しており、エンドサイトで使用できるローカルスコープのIPv6ユニキャストアドレス空間を提供します。ただし、IPv4 NATとプライベートアドレススペース[RFC1918]によって提供されるのと同様の方法で、ローカライズされたアドレス管理は、IPv6 [RFC5902]にとって望ましい方法です[RFC4864]。
One of the major concerns that many have had with NAT is the loss of end-to-end transport-layer and network-layer session state invariance, which is still considered an important architectural principle by the IAB [RFC4924]. Nevertheless, the use of localised addressing remains in wide use and there is interest in its continued use in IPv6, e.g., proposals such as [RFC6296].
多くの人がNATに関して抱えていた主要な懸念の1つは、エンドツーエンドのトランスポート層およびネットワーク層のセッション状態の不変性の喪失です。これは、IAB [RFC4924]によって重要なアーキテクチャの原則と見なされています。それにもかかわらず、ローカライズされたアドレス指定の使用は依然として広く使用されており、IPv6での継続的な使用、たとえば[RFC6296]などの提案に関心があります。
It is possible to have the benefits of NAT-like functions for ILNP without losing end-to-end state. Indeed, such a mechanism -- the use of Locator rewriting in ILNP -- forms the basis of many of the optional functions described in this document. In ILNP, we call this feature "localised numbering".
エンドツーエンドの状態を失うことなく、ILNPのNATに似た機能の利点を活用できます。実際、そのようなメカニズム（ILNPでのロケーターの書き換えの使用）は、このドキュメントで説明されているオプション機能の多くの基礎を形成しています。 ILNPでは、この機能を「ローカライズされた番号付け」と呼びます。
Recall, that a Locator value in ILNP has the same semantics as a routing prefix in IP: indeed, in ILNPv4 and ILNPv6 [RFC6741], routing prefixes from IPv4 and IPv6, respectively, are used as Locator values.
ILNPのロケーター値は、IPのルーティングプレフィックスと同じセマンティクスを持っていることを思い出してください。実際、ILNPv4およびILNPv6 [RFC6741]では、IPv4およびIPv6からのルーティングプレフィックスがそれぞれロケーター値として使用されます。
We note that a deployment using private/local numbering can also provide a convenient solution to centralised management of site multihoming and network mobility by deploying SBRs in this manner -- this is described below.
プライベート/ローカルの番号付けを使用した展開は、この方法でSBRを展開することで、サイトのマルチホーミングとネットワークモビリティの集中管理に便利なソリューションを提供することもできます。これについては以下で説明します。
Please note that with this proposal, localised numbering (e.g., using the equivalent of IP NAT on the ILNP Locator bits) would work in harmony with multihoming, mobility (for individual hosts and whole networks), and IP Security (IPsec), plus the other advanced functions described in this document [BA11] [LABH06] [ABH07a] [ABH07b] [ABH08a] [ABH08b] [ABH09a] [ABH09b] [RAB09] [RB10] [ABH10] [BAK11].
この提案では、ローカライズされた番号付け（たとえば、ILNPロケータービットでIP NATに相当するものを使用）は、マルチホーミング、モビリティ（個々のホストとネットワーク全体）、およびIPセキュリティ（IPsec）と調和して機能し、さらにこのドキュメントで説明されている他の高度な機能[BA11] [LABH06] [ABH07a] [ABH07b] [ABH08a] [ABH08b] [ABH09a] [ABH09b] [RAB09] [RB10] [ABH10] [BAK11]。
For ILNP, the NAT-like function can best be descried by using a simple example, based on Figure 2.1.
ILNPの場合、NATのような機能は、図2.1に基づく簡単な例を使用することで最もよく説明できます。
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. .L_L | | . .
. .----+ | . Internet .
. H . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
CN = Correspondent Node H = Host L_1 = global Locator value L_L = local Locator value SBR = Site Border Router
CN =対応するノードH =ホストL_1 =グローバルロケーター値L_L =ローカルロケーター値SBR =サイト境界ルーター
Figure 2.1: A Simple Localised Numbering Example for ILNP
図2.1：ILNPのローカライズされた簡単な番号付けの例
In this scenario, the SBR is allocated global locator value L_1 from the upstream provider. However, the SBR advertises internally a "local" Locator value L_L. By "local" we mean that the Locator value only has significance within the site network, and any packets that have L_L as a source Locator cannot be forwarded beyond the SBR with value L_L as the source Locator. In engineering terms, L_L would, for example, in ILNPv6, be an IPv6 prefix based on the assignments possible according to IPv6 Unique Local Addresses (ULAs) [RFC4193].
このシナリオでは、SBRに上流プロバイダーからグローバルロケーター値L_1が割り当てられます。ただし、SBRは「ローカルな」ロケーター値L_Lを内部的に通知します。 「ローカル」とは、ロケーター値がサイトネットワーク内でのみ意味を持つことを意味し、ソースロケーターとしてL_Lを持つパケットは、ソースロケーターとして値L_Lを持つSBRを超えて転送できません。エンジニアリング用語では、L_Lは、たとえば、ILNPv6では、IPv6固有ローカルアドレス（ULA）[RFC4193]に従って可能な割り当てに基づくIPv6プレフィックスになります。
If we assume that H uses Identifier I_H, then it will use Identifier-Locator Vector (I-LV) [I_H, L_L], and that the correspondent node (CN) uses IL-V [I_CN, L_CN]. If we consider that H will send a UDP packet from its port P_H to CN's port P_CN, then H could send a UDP/ILNP packet with the tuple expression:
Hが識別子I_Hを使用すると仮定すると、識別子ロケーターベクトル（I-LV）[I_H、L_L]を使用し、コレスポンデントノード（CN）はIL-V [I_CN、L_CN]を使用します。 HがUDPパケットをそのポートP_HからCNのポートP_CNに送信すると考える場合、Hはタプル式を使用してUDP / ILNPパケットを送信できます。
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_L, L_CN> --- (1a)
When this packet reaches the SBR, it knows that L_L is a local Locator value and so rewrites the source Locator on the egress packet to L_1 and forwards that out onto its external-facing interface. The value L_1 is a global prefix, which allows the packet to be routed globally:
このパケットがSBRに到達すると、L_Lがローカルロケーター値であることを認識しているため、出力パケットのソースロケーターをL_1に書き換え、外部ロケーターに転送します。値L_1はグローバルプレフィックスであり、これによりパケットをグローバルにルーティングできます。
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (1b)
This packet reaches CN using normal routing based on the Locator value L_1, as it is a routing prefix.
このパケットは、ルーティングプレフィックスであるため、ロケーター値L_1に基づく通常のルーティングを使用してCNに到達します。
Note that from expressions (1a) and (1b), the end-to-end state (in the UDP tuple) remains unchanged -- end-to-end state invariance is honoured, for UDP. CN would send a UDP packet to H as:
式（1a）および（1b）から、（UDPタプル内の）エンドツーエンドの状態は変更されないことに注意してください。UDPの場合、エンドツーエンドの状態の不変性が尊重されます。 CNは次のようにUDPパケットをHに送信します。
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1> --- (2a)
and the SBR would rewrite the Locator value on the ingress packet before forwarding the packet on its internal interface:
また、SBRは、内部インターフェースでパケットを転送する前に、入力パケットのロケーター値を書き換えます。
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_L> --- (2b)
Again, this preserves the end-to-end transport-layer session state invariance.
繰り返しになりますが、これにより、エンドツーエンドのトランスポート層セッション状態の不変性が保持されます。
As the Locator values are not used in the transport-layer pseudo-header for ILNP [RFC6741], the checksum would not have to be rewritten. That is, the Locator rewriting function is stateless and has low overhead.
Locator値はILNP [RFC6741]のトランスポート層疑似ヘッダーで使用されないため、チェックサムを書き換える必要はありません。つまり、ロケーターの書き換え機能はステートレスで、オーバーヘッドが少ないです。
(A discussion on the generation of Identifier values for initial use is presented in [RFC6741].)
（初期使用のための識別子値の生成に関する議論は[RFC6741]に提示されています。）
It is possible for the SBR to advertise both L_1 and L_L within the site, and for hosts within the site to have IL-Vs using both L_1 and L_L. For example, host H may have IL-Vs [I_H, L_1] and [I_H, L_L]. The configuration and use of such a mechanism can be controlled through local policy.
SBRがサイト内のL_1とL_Lの両方をアドバタイズし、サイト内のホストがL_1とL_Lの両方を使用するIL-Vを持つことが可能です。たとえば、ホストHにはIL-V [I_H、L_1]と[I_H、L_L]があります。このようなメカニズムの構成と使用は、ローカルポリシーを通じて制御できます。
Where the site network uses subnets, packets will need to be routed correctly, internally. That is, the site network may have several internal Locator values, e.g., L_La, L_Lb, and L_Lc. When an ingress packet has I-LV [I_H, L_1], it is expected that the SBR is capable of identifying the correct internal network for I_H, and so the correct Locator value to rewrite for the ingress packet. This is not obvious as the I value and the L value are not related in any way.
サイトネットワークがサブネットを使用している場合、パケットは内部で正しくルーティングされる必要があります。つまり、サイトネットワークには、L_La、L_Lb、L_Lcなど、いくつかの内部ロケーター値がある場合があります。入力パケットにI-LV [I_H、L_1]が含まれている場合、SBRはI_Hの正しい内部ネットワークを識別できるため、正しいパケットのLocator値を入力パケット用に書き換えることができます。 I値とL値はまったく関係がないため、これは明らかではありません。
There are numerous ways the SBR could facilitate the correct lookup of the internal Locator value. This document does not prescribe any specific method. Of course, we do not preclude mappings directly from Identifier values to internal Locator values.
SBRが内部ロケーター値の正しい検索を容易にすることができる多くの方法があります。このドキュメントでは、特定の方法を規定していません。もちろん、Identifier値から内部Locator値への直接マッピングを排除することはありません。
Of course, such a "flat" mapping (between Identifier values and Locators) would serve, but maintaining such a mapping would be impractical for a large site. So, we propose the following solution.
もちろん、そのような「フラットな」マッピング（識別子の値とロケーターの間）は機能しますが、そのようなマッピングを維持することは、大規模なサイトでは実用的ではありません。そこで、以下の解決策を提案します。
Consider that the Locator value, L_x consists of two parts, L_pp and L_ss, where L_pp is a network prefix and L_ss is a subnet selector. Also, consider that this structure is true for both the local identifier, L_L, as well as the global Identifier, L_1. Then, an SBR need only know the mapping from the values of L_ss as visible in L_1 and the values of L_ss used locally.
Locatorの値であるL_xが、L_ppとL_ssの2つの部分で構成されていることを考慮してください。L_ppはネットワークプレフィックスで、L_ssはサブネットセレクターです。また、この構造がローカル識別子L_Lとグローバル識別子L_1の両方に当てはまることを考慮してください。次に、SBRは、L_1に表示されるL_ssの値とローカルで使用されるL_ssの値からのマッピングのみを知っている必要があります。
Such a mapping could be mechanical, e.g., the L_ss part of L_L and L_1 are the same and it is only the L_pp part that is different. Where this is not desirable (e.g., for obfuscation of interior topology), an administrator would need to configure a suitable mapping policy in the SBR, which could be realised as a simple lookup table. Note that with such a policy, the L_pp for L_L and L_1 do not need to be of the same size.
このようなマッピングは機械的である可能性があります。たとえば、L_LとL_1のL_ss部分は同じであり、L_pp部分のみが異なります。これが望ましくない場合（内部トポロジの難読化など）には、管理者はSBRで適切なマッピングポリシーを構成する必要があります。これは、単純なルックアップテーブルとして実現できます。このようなポリシーでは、L_LとL_1のL_ppを同じサイズにする必要がないことに注意してください。
From a practical perspective, this is possible for both ILNPv6 [RFC6177] and ILNPv4 [RFC4632]. For ILNPv6, recall that the Locator value is encoded to be syntactically similar to an IPv6 address prefix, as shown in Figure 2.2, taken from [RFC6741].
実用的な観点から、これはILNPv6 [RFC6177]とILNPv4 [RFC4632]の両方で可能です。 ILNPv6の場合、[RFC6741]から抜粋した図2.2に示すように、Locator値が構文的にIPv6アドレスプレフィックスに類似するようにエンコードされていることを思い出してください。
/* IPv6 */
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
|001|global routing prefix| subnet ID | Interface Identifier |
+---+---------------------+-----------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
| Locator (L64) | Node Identifier (NID) |
+---+---------------------+-----------+-------------------------+
+<-------- L_pp --------->+<- L_ss -->+
L_pp = Locator prefix part (assigned IPv6 prefix) L_ss = Locator subnet selector (locally managed subnet ID)
L_pp =ロケータープレフィックスパーツ（割り当てられたIPv6プレフィックス）L_ss =ロケーターサブネットセレクター（ローカルで管理されたサブネットID）
Figure 2.2: IPv6 Address format [RFC3587] as used in ILNPv6, showing how subnets can be identified.
図2.2：ILNPv6で使用されているIPv6アドレス形式[RFC3587]。サブネットの識別方法を示しています。
Note that the subnet ID forms part of the Locator value. Note also that [RFC6177] allows the global routing prefix to be more than 45 bits, and for the subnet ID to be smaller, but still preserving the 64-bit size of the Locator overall.
サブネットIDはロケーター値の一部であることに注意してください。また、[RFC6177]では、グローバルルーティングプレフィックスを45ビットを超えて、サブネットIDを小さくすることができますが、ロケーター全体の64ビットサイズは維持されます。
For ILNPv4, the L_pp value overall is an IPv4 routing prefix, which is typically less than 32 bits. However, the ILNPv4 Locator value is carried in the 32-bit IP Address space, so the bits not used for the routing prefix could be used for L_ss, e.g., for a /24 IPv4 prefix, the situation would be as shown in Figure 2.3, and L_ss could use any of the remaining 8-bits as required.
ILNPv4の場合、L_pp値は全体的にIPv4ルーティングプレフィックスであり、通常は32ビット未満です。ただし、ILNPv4ロケーターの値は32ビットのIPアドレス空間で伝達されるため、ルーティングプレフィックスに使用されていないビットをL_ssに使用できます（例：/ 24 IPv4プレフィックス）、状況は図2.3のようになります。 、およびL_ssは、必要に応じて残りの8ビットのいずれかを使用できます。
24 bits 8 bits
+------------------------+----------+
| Locator (L32) |
+------------------------+----------+
+<------- L_pp --------->+<- L_ss ->+
L_pp = Locator prefix (assigned IPv4 prefix) L_ss = Locator subnet selector (locally managed subnet ID)
L_pp =ロケータープレフィックス（割り当てられたIPv4プレフィックス）L_ss =ロケーターサブネットセレクター（ローカルで管理されたサブネットID）
Figure 2.3: IPv4 address format for /24 IPv4 prefix, as used in ILNPv4, showing how subnets can be identified.
図2.3：ILNPv4で使用される/ 24 IPv4プレフィックスのIPv4アドレス形式。サブネットの識別方法を示しています。
As an example, for the case where the interior topology is not obfuscated, an interior "engineering" node might have an LP record pointing to eng.example.com and eng.example.com might have L32/L64 records for a specific subnet inside the site. Meanwhile, an interior "operations" node might have an LP record pointing at "ops.example.com" that might have different L32/L64 records for that specific subnet within the site. That is, eng.example.com might have Locator value L_pp_1:L_ss_1 and ops.example.com might have Locator value L_pp_1:L_ss_2. However, just as for IPv6 or IPv4 routing today, the routing for the site would only need to use L_pp_1, which is a routing prefix in either IPv6 (for ILNPv6) or IPv4 (for ILNPv4).
例として、内部トポロジが難読化されていない場合、内部の「エンジニアリング」ノードには、eng.example.comを指すLPレコードがあり、eng.example.comには内部の特定のサブネットのL32 / L64レコードがある場合があります。サイト。一方、内部の「操作」ノードには、「ops.example.com」を指すLPレコードがあり、サイト内のその特定のサブネットに対して異なるL32 / L64レコードがある場合があります。つまり、eng.example.comにはLocator値L_pp_1：L_ss_1があり、ops.example.comにはLocator値L_pp_1：L_ss_2がある場合があります。ただし、今日のIPv6またはIPv4ルーティングの場合と同様に、サイトのルーティングでは、IPv6（ILNPv6の場合）またはIPv4（ILNPv4の場合）のルーティングプレフィックスであるL_pp_1のみを使用する必要があります。
To support private numbering with IPv4 and IPv6 today, some sites use a split-horizon DNS service for the site [appDNS].
現在、IPv4およびIPv6でのプライベート番号付けをサポートするために、一部のサイトでは、サイト[appDNS]にスプリットホライズンDNSサービスを使用しています。
If a site using localised numbering chooses to deploy a split-horizon DNS server, then the DNS server would return the global-scope Locator(s) (L_1 in our example above) of the SBR to DNS clients outside the site, and would advertise the local-scope Locator(s) (L_L in our example above) specific to that internal node to DNS clients inside the site. Such deployments of split-horizon DNS servers are not unusual in the IPv4 Internet today. If an internal node (e.g., portable computer) moves outside the site, it would follow the normal ILNP methods to update its authoritative DNS server with its current Locator set. In this deployment model, the authoritative DNS server for that mobile device will be either the split-horizon DNS server itself or the master DNS server providing data to the split-horizon DNS server.
ローカライズされた番号付けを使用するサイトがスプリットホライズンDNSサーバーの展開を選択した場合、DNSサーバーはSBRのグローバルスコープロケーター（上記の例ではL_1）をサイト外のDNSクライアントに返し、アドバタイズします。サイト内のDNSクライアントに対するその内部ノードに固有のローカルスコープロケーター（上記の例ではL_L）。このようなスプリットホライズンDNSサーバーの展開は、今日のIPv4インターネットでは珍しいことではありません。内部ノード（ポータブルコンピューターなど）がサイトの外部に移動した場合、通常のILNPメソッドに従って、信頼できるDNSサーバーを現在のロケーターセットで更新します。この展開モデルでは、そのモバイルデバイスの信頼できるDNSサーバーは、スプリットホライズンDNSサーバー自体、またはスプリットホライズンDNSサーバーにデータを提供するマスターDNSサーバーのいずれかになります。
If a site using localised numbering chooses not to deploy a split-horizon DNS server, then each internal node would advertise the global-scope Locator(s) of the site border routers in its respective DNS entries. To deliver packets from one internal node to another internal node, the site would choose to use either Layer 2 bridging (e.g., IEEE Spanning Tree or IEEE Rapid Spanning Tree [IEEE04], or a link-state Layer 2 algorithm such as the IETF TRILL group or IEEE 802.1 are developing), or the interior routers would forward packets up to the nearest site border router, which in turn would then rewrite the Locators to appropriate local-scope values, and forward the packet towards the interior destination node.
ローカライズされた番号付けを使用するサイトがスプリットホライズンDNSサーバーを展開しないことを選択した場合、各内部ノードは、それぞれのDNSエントリでサイト境界ルーターのグローバルスコープロケーターをアドバタイズします。ある内部ノードから別の内部ノードにパケットを配信するために、サイトはレイヤー2ブリッジング（IEEEスパニングツリーやIEEEラピッドスパニングツリー[IEEE04]など）、またはIETF TRILLなどのリンクステートレイヤー2アルゴリズムの使用を選択しますグループまたはIEEE 802.1が開発中）、または内部ルーターがパケットを最も近いサイト境界ルーターまで転送し、次にロケーターを適切なローカルスコープ値に書き換えて、パケットを内部宛先ノードに転送します。
Alternately, for sites using localised numbering but not deploying a split-horizon DNS server, the DNS server could return all global-scope and local-scope Locators to all queriers, and assume that nodes would use normal, local address/route selection criteria to choose the best Locator to use to reach a given remote node ([RFC3484] for older IPv6 nodes, [RFC6724] for newer IPv6 nodes). Hosts within the same site as the correspondent node would only have a ULA configured; hence, they would select the ULA destination Locator for the correspondent (L_L in our example). Hosts outside the site would not have the same ULA configured (L_CN for the CN in our example).
あるいは、ローカライズされた番号付けを使用しているが、スプリットホライズンDNSサーバーを展開していないサイトの場合、DNSサーバーはすべてのグローバルスコープロケーターとローカルスコープロケーターをすべてのクエリアに返し、ノードが通常のローカルアドレス/ルート選択基準を使用して、特定のリモートノードに到達するために使用する最適なロケータを選択します（古いIPv6ノードの場合は[RFC3484]、新しいIPv6ノードの場合は[RFC6724]）。コレスポンデントノードと同じサイト内のホストには、ULAのみが構成されます。したがって、彼らはコレスポンデント（この例ではL_L）のULA宛先ロケーターを選択します。サイト外のホストには同じULAが設定されていません（この例ではCNのL_CN）。
However, ILNP allows use of Locator Preference values [RFC6742] [RFC6743]. These values would indicate explicitly the relative preference value given to Locator values and so result in the selection of the appropriate Locator (and therefore interface) to use for the transmission of an outgoing packet with respect to the value to be inserted into the IPv6 Source Address field (see Section 3 of [RFC6741]). A similar argument, with respect to use of Locator preference values, applies to the value to be inserted into the IPv6 Destination Address field. Certainly, by using appropriate Preference values for a host with multiple Locator values, it would be possible to emulate some level of resemblance to the address selection rules in [RFC3484] and [RFC6724], and this could be controlled via DNS entries for ILNP nodes, for example.
ただし、ILNPでは、ロケーター設定値[RFC6742] [RFC6743]を使用できます。これらの値は、ロケーター値に与えられた相対的な優先値を明示的に示すため、IPv6送信元アドレスに挿入される値に関して、発信パケットの送信に使用する適切なロケーター（およびインターフェイス）が選択されます。フィールド（[RFC6741]のセクション3を参照）。ロケーター設定値の使用に関する同様の引数が、IPv6宛先アドレスフィールドに挿入される値に適用されます。確かに、複数のロケーター値を持つホストに適切な設定値を使用することにより、[RFC3484]と[RFC6724]のアドレス選択ルールにある程度の類似性をエミュレートすることが可能になり、これはILNPノードのDNSエントリを介して制御できます、 例えば。
Indeed, with appropriate use of localised or site-wide policy, and appropriate mechanisms in the devices (e.g. in end hosts operating systems or in Site Border Routers), Preference values for Locator values within the DNS could be used for allowing options for multi-homed transport sessions and/or site-controlled traffic engineering [ABH09a]. However, the details for this are left for further study, and overall, the rules defined in [RFC3484] and [RFC6724] cannot be applied directly to ILNPv6 nodes.
実際、ローカライズされたポリシーまたはサイト全体のポリシーを適切に使用し、デバイス（たとえば、エンドホストのオペレーティングシステムまたはサイトボーダールーター）で適切なメカニズムを使用すると、DNS内のロケーター値の優先値を使用して、マルチ-帰宅輸送セッションおよび/またはサイト制御交通工学[ABH09a]。ただし、この詳細は今後の検討のために残されており、全体として、[RFC3484]および[RFC6724]で定義されているルールをILNPv6ノードに直接適用することはできません。
Note that for split-horizon operation, there needs to be a DNS management policy for mobile hosts, as when such hosts are away from their "home" network, they will need to update DNS entries so that the global-scope Locator(s) only is (are) used, and these are consistent with the current topological position of the mobile host. Such updates would need to be done using Secure Dynamic DNS Update.
スプリットホライズン操作には、モバイルホストのDNS管理ポリシーが必要です。そのようなホストが「ホーム」ネットワークから離れている場合、グローバルスコープのロケーターが存在するように、DNSエントリを更新する必要があるためです。のみが使用されており、これらはモバイルホストの現在のトポロジ上の位置と一致しています。このような更新は、Secure Dynamic DNS Updateを使用して行う必要があります。
For an ILNP mobile network using LP records, there are likely to separate LP records for internal and external use.
LPレコードを使用するILNPモバイルネットワークの場合、LPレコードを内部用と外部用に分離する可能性があります。
Multicast DNS (mDNS) [mDNS11] is popularly used in many end-system OSs today, especially desktop OSs (such as Windows, Mac OS X and Linux). It is used for localised name resolution using names with a ".local" suffix, for both IPv4 and IPv6. This protocol would need to be modified so that when an ILNP-capable node advertises its ".local" name, another ILNP-capable node would be able to see that it is an ILNP-capable, but other, non-ILNP nodes would not be perturbed in operation. The details of a mechanism for using mDNS to enable such a feature are not defined here.
マルチキャストDNS（mDNS）[mDNS11]は、今日多くのエンドシステムOS、特にデスクトップOS（Windows、Mac OS X、Linuxなど）で広く使用されています。 IPv4とIPv6の両方で、「。local」サフィックスが付いた名前を使用してローカライズされた名前解決に使用されます。このプロトコルは、ILNP対応ノードがその「.local」名をアドバタイズするときに、別のILNP対応ノードがそれがILNP対応であることを認識できるが、他の非ILNPノードはそうしないように変更する必要があります。動作中に混乱する。 mDNSを使用してこのような機能を有効にするメカニズムの詳細は、ここでは定義しません。
In this scenario, if H expects incoming ILNP session requests, for example, then remote nodes normally will need to look up appropriate Identifier and Locator information in the DNS. Just as for IP, and as already described in [RFC6740], a Fully Qualified Domain Name (FQDN) lookup for H should resolve to the correct NID and L32/L64 records. If there are many hosts like H that need to keep DNS records (for any reason, including to allow incoming ILNP session requests), then, potentially, there are many such DNS resource records.
このシナリオでは、たとえば、Hが着信ILNPセッション要求を予期している場合、リモートノードは通常、DNSで適切な識別子とロケーター情報を検索する必要があります。 IPと同様に、[RFC6740]ですでに説明されているように、Hの完全修飾ドメイン名（FQDN）ルックアップは、正しいNIDおよびL32 / L64レコードに解決されるはずです。 DNSレコードを保持する必要があるHのようなホストが多数ある場合（着信ILNPセッション要求を許可するなど、何らかの理由で）、そのようなDNSリソースレコードが多数存在する可能性があります。
As an optimisation, the network as a whole may be configured with one or more L32 and L64 records (to store the value L_1 from our example) that are resolved from an FQDN. At the same time, individual hosts now have an FQDN that returns one or more LP record entries [RFC6742] as well as NID records. The LP record points to the L32 or L64 records for the site. A multihomed site normally will have at least one L32 or L64 record for each distinct uplink (i.e., link from a Site Border Router towards the global Internet), because ILNP uses provider-aggregatable addressing.
最適化として、ネットワーク全体は、FQDNから解決される1つ以上のL32およびL64レコード（この例の値L_1を格納するため）で構成できます。同時に、個々のホストには、1つ以上のLPレコードエントリ[RFC6742]とNIDレコードを返すFQDNがあります。 LPレコードは、サイトのL32またはL64レコードを指します。 ILNPはプロバイダー集約型アドレッシングを使用するため、マルチホームサイトには通常、個別のアップリンクごとに少なくとも1つのL32またはL64レコードがあります（つまり、Site Border Routerからグローバルインターネットへのリンク）。
More than one L32 or L64 will be required if multiple Locator values are in use. For example, if an ILNPv6 site has multiple links for multihoming, it will use one L64 record for each Locator value it is using on each link.
複数のロケーター値が使用されている場合、複数のL32またはL64が必要になります。たとえば、ILNPv6サイトにマルチホーミング用の複数のリンクがある場合、サイトは各リンクで使用しているロケーター値ごとに1つのL64レコードを使用します。
In some situations, it can be desirable to obfuscate the details of the interior topology of an end site. Alternately, in some situations, local site policy requires that local-scope routing prefixes be used within the local site. ILNP can provide these capabilities through the ILNP local addressing capability described here, under the control of the SBR.
状況によっては、エンドサイトの内部トポロジの詳細を難読化することが望ましい場合があります。あるいは、状況によっては、ローカルサイトポリシーでは、ローカルスコープのルーティングプレフィックスをローカルサイト内で使用する必要があります。 ILNPは、SBRの制御下で、ここで説明するILNPローカルアドレッシング機能を通じてこれらの機能を提供できます。
As described in Section 2.3 above, locator rewriting can be used to hide the internal structure of the network with respect to the subnetting arrangement of the site network. Specifically, the procedure described in Section 2.3 would be followed, with the following additional modification of the use of Locator values:
上記のセクション2.3で説明したように、ロケーターの書き換えを使用して、サイトネットワークのサブネット配置に関してネットワークの内部構造を隠すことができます。具体的には、セクション2.3で説明されている手順に従い、ロケーター値の使用を次のように変更します。
(1) Only the aggregated Locator value, i.e., L_pp, is advertised outside the site (e.g., in an L32 or L64 record), and L_ss is zeroed in that advertisement.
（1）集約されたLocator値、つまりL_ppのみがサイト外（L32またはL64レコードなど）にアドバタイズされ、L_ssはそのアドバタイズでゼロ化されます。
(2) The SBR needs to maintain a mapping table to restore the interior topology information for received packets, for example, by using a mapping table from I values to either L_ss values or internal Locator values.
（2）SBRは、たとえば、I値からL_ss値または内部ロケーター値へのマッピングテーブルを使用して、受信したパケットの内部トポロジ情報を復元するためにマッピングテーブルを維持する必要があります。
(3) The SBR needs to zero the L_ss values for all Source Locators of egress packets, as well as perform a Locator rewriting that affects the L_pp bits of the Locator value.
（3）SBRは、出力パケットのすべてのソースロケーターのL_ss値をゼロにする必要があり、ロケーター値のL_ppビットに影響するロケーターの書き換えを実行する必要があります。
Of course, this only obscures the interior topology of the site, not the exterior connectivity of the site. In order for the site to be reachable from the global Internet, the site's DNS entries need to advertise Locator values for the site to the global Internet (e.g., in L32, L64 records).
もちろん、これはサイトの内部トポロジを覆い隠すだけで、サイトの外部接続を覆い隠しません。グローバルインターネットからサイトにアクセスできるようにするには、サイトのDNSエントリで、サイトのロケーター値をグローバルインターネットに通知する必要があります（L32、L64レコードなど）。
For backwards compatibility, for ILNP, the ICMP checksum is always calculated identically as for IPv6 or IPv4. For ILNPv6, this means that the SBR need not be aware if ILNPv6 is operating as described in [RFC6740] and [RFC6741]. For ILNPv4, again, the SBR need not be aware of the operation if ILNPv4 is operating as it will not need to inspect the extension header carrying the I value.
下位互換性のために、ILNPでは、ICMPチェックサムは常にIPv6またはIPv4と同じように計算されます。 ILNPv6の場合、これは、ILNPv6が[RFC6740]および[RFC6741]で説明されているように動作しているかどうかをSBRが認識する必要がないことを意味します。 ILNPv4の場合も、ILNPv4が動作している場合、I値を伝送する拡張ヘッダーを検査する必要がないため、SBRは動作を認識する必要はありません。
In order to support communication between two internal nodes that happen to be using global-scope addresses (for whatever reason), the SBR MUST support the "hair pinning" behaviour commonly used in existing NAT/NAPT devices. (This behaviour is described in Section 6 of RFC 4787 [RFC4787].) In the near-term, a more common deployment scenario will be to deploy ILNP incrementally, with some ordinary classic IP traffic still existing. In this case, the SBR should maintain flow state that contains a flag for each flow indicating whether or not that flow is using ILNP. If that flag indicated ILNP were enabled for a given flow, and ILNP local numbering were also enabled, then the SBR would know that it should perform the simpler ILNP Locator rewriting mapping. If that flag indicated ILNP were not enabled for a given flow and IP NAT or IP NAPT were also enabled, then the SBR would know that it should perform the more complex NAT/NAPT translation (e.g., including TCP or UDP checksum recalculation).
（何らかの理由で）グローバルスコープアドレスを使用している2つの内部ノード間の通信をサポートするために、SBRは、既存のNAT / NAPTデバイスで一般的に使用されている「ヘアピン」動作をサポートする必要があります。 （この動作はRFC 4787 [RFC4787]のセクション6で説明されています。）近い将来、より一般的な展開シナリオは、ILNPを段階的に展開することです。通常の従来のIPトラフィックがまだ残っています。この場合、SBRは、フローがILNPを使用しているかどうかを示す各フローのフラグを含むフロー状態を維持する必要があります。 ILNPが特定のフローに対して有効であり、ILNPローカル番号付けも有効になっていることをそのフラグが示している場合、SBRは、より単純なILNP Locator書き換えマッピングを実行する必要があることを認識します。そのフラグが特定のフローに対してILNPが有効になっておらず、IP NATまたはIP NAPTも有効になっていることをそのフラグが示している場合、SBRは、より複雑なNAT / NAPT変換を実行する必要があることを認識します（たとえば、TCPまたはUDPチェックサムの再計算を含む）。
NOTE: Existing commercial security-aware routers (e.g., Juniper SRX routers) already can maintain flow state for millions of concurrent IP flows. This feature would add one flag to each flow's state, so this approach is believed scalable today using existing commercial technology.
注：既存の商用セキュリティ対応ルーター（Juniper SRXルーターなど）は、何百万もの同時IPフローのフロー状態をすでに維持できます。この機能により、各フローの状態にフラグが1つ追加されるため、このアプローチは、既存の商用テクノロジーを使用して、現在スケーラブルであると考えられています。
Those applications that do not use IP Address values in application state or configuration data are considered to be "well behaved". For well-behaved applications, no further enhancements are required. Where application-layer protocols are not well behaved, for example, the File Transfer Protocol (FTP), then the SBR might need to perform additional stateful processing -- just as NAT and NAPT equipment needs to do today for FTP. See the description in Section 7.6 of [RFC6741].
アプリケーションの状態または構成データでIPアドレス値を使用しないアプリケーションは、「正常に動作」していると見なされます。正常に動作するアプリケーションの場合、それ以上の拡張は必要ありません。ファイル転送プロトコル（FTP）など、アプリケーション層プロトコルが適切に動作しない場合、SBRは追加のステートフル処理を実行する必要がある場合があります。これは、NATおよびNAPT機器がFTPのために今日行う必要があるのと同じです。 [RFC6741]のセクション7.6の説明をご覧ください。
When the SBR rewrites a Locator in an ILNP packet, that obscures information about how well a particular path is working between the sender and the receiver of that ILNP packet. So, the SBR that rewrites Locator values needs to include mechanisms to ensure that any packet with a new Destination Locator will travel along a valid path to the intended destination node. For ILNPv4, the path liveness will be no worse than IPv4, and mechanisms already in use for IPv4 can be reused. For ILNPv6, the path liveness will be no worse than for IPv6, and mechanisms already in use for IPv6 can be reused.
SBRがILNPパケット内のロケーターを書き換えると、そのILNPパケットの送信側と受信側の間で特定のパスがどの程度適切に機能しているかに関する情報が不明瞭になります。そのため、ロケーター値を書き換えるSBRには、新しい宛先ロケーターを含むすべてのパケットが有効なパスに沿って目的の宛先ノードに移動するようにするメカニズムを含める必要があります。 ILNPv4の場合、パスの活性はIPv4よりも悪くなく、IPv4ですでに使用されているメカニズムを再利用できます。 ILNPv6の場合、パスの活性はIPv6の場合よりも悪くならず、IPv6ですでに使用されているメカニズムを再利用できます。
In the future, the Border Router Discovery Protocol (BRDP) also might be used in some deployments to indicate which routing prefixes are currently valid and which site border routers currently have a working uplink [BRDP11].
将来的には、一部の展開でボーダールーター探索プロトコル（BRDP）を使用して、現在有効なルーティングプレフィックスと現在機能しているアップリンクがあるサイトボーダールーターを示すこともできます[BRDP11]。
The ILNP Architectural Description [RFC6740] describes the basic approach to enabling Site Multihoming (S-MH) with ILNP. However, as an option, it is possible to leave the control of S-MH to an ILNP-enabled SBR. This alternative is based on the use of the Localised Numbering function described in Section 2 of this document.
ILNPアーキテクチャの説明[RFC6740]では、ILNPでサイトマルチホーミング（S-MH）を有効にする基本的なアプローチについて説明しています。ただし、オプションとして、S-MHの制御をILNP対応のSBRに任せることができます。この代替手段は、このドキュメントのセクション2で説明されているローカライズされた番号付け機能の使用に基づいています。
The approach to Site Multihoming (S-MH) using an SBR is best illustrated through an example, as shown in Figure 3.1.
図3.1に示すように、SBRを使用したサイトマルチホーミング（S-MH）へのアプローチは、例を通して最もよく説明されています。
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | sbr1+------. .
. .L_L | | . .
. .----+ | . Internet .
. H . | | . .
. . | sbr2+------. .
. . . . +------+ L_2 . .
. .
. . . .
CN = Correspondent Node H = Host L_1 = global Locator value 1 L_2 = global Locator value 2 L_L = local Locator value SBR = Site Border Router sbrN = interface N on SBR
CN =対応するノードH =ホストL_1 =グローバルロケーター値1 L_2 =グローバルロケーター値2 L_L =ローカルロケーター値SBR =サイト境界ルーターsbrN = SBRのインターフェイスN
Figure 3.1: Alternative Site Multihoming Example with an SBR
図3.1：SBRを使用した代替サイトのマルチホーミングの例
The situation here is similar to the localised numbering example, except that the SBR now has two external links, with using Locator value L_1 and another using Locator value L_2. These could, e.g., for ILNPv6, be separate, Provider Aggregated (PA) IPv6 prefixes from two different ISPs. H has IL-V [I_H, L_L], and will forward a packet to CN as given in expression (1a). However, when the packet reaches the SBR, local policy will decide whether the packet is forwarded on the link sbr1 using L_1 or on sbr2 using L_2. Of course, the correct Locator value will be rewritten into the egress packet in place of L_L.
ここでの状況は、SBRにロケーター値L_1とロケーター値L_2を使用する2つの外部リンクがあることを除いて、ローカライズされた番号付けの例と同様です。これらは、たとえばILNPv6の場合、2つの異なるISPからの個別のプロバイダー集約（PA）IPv6プレフィックスである可能性があります。 HにはIL-V [I_H、L_L]があり、式（1a）に示すようにパケットをCNに転送します。ただし、パケットがSBRに到達すると、ローカルポリシーは、パケットがL_1を使用してリンクsbr1で転送されるか、L_2を使用してsbr2で転送されるかを決定します。もちろん、正しいロケーター値は、L_Lの代わりに出力パケットに書き換えられます。
If only local numbering is being used, then the SBR need never advertise any global Locator values. However, it could do, as described in Section 2.2.
ローカル番号付けのみが使用されている場合、SBRはグローバルロケーター値をアドバタイズする必要はありません。ただし、セクション2.2で説明されているように、それは可能です。
One of the key uses for multihoming is providing resilience to link failure. If either link breaks, then the SBR can manage the change in connectivity locally. For example, assume SBR has been configured to use sbr1 for all traffic, and sbr2 only as backup link. So, SBR directs packets from H to communicate with CN using sbr1, and CN will receive packets as in expression (1b) and respond with packets as in expression (2a).
マルチホーミングの主な用途の1つは、リンク障害に対する回復力を提供することです。いずれかのリンクが切断された場合、SBRは接続の変更をローカルで管理できます。たとえば、SBRがすべてのトラフィックにsbr1を使用し、sbr2をバックアップリンクとしてのみ使用するように設定されているとします。したがって、SBRはHからのパケットをsbr1を使用してCNと通信するように指示し、CNは式（1b）のようにパケットを受信し、式（2a）のようにパケットで応答します。
However, if sbr1 goes down then SBR will move the communication to interface sbr2. As H is not aware of the actions of the SBR, the SBR must maintain some state about IL-V "pairs" in order to hand off the connectivity from sbr1 to sbr2. So, when moving the communication to sbr2, the SBR would firstly send a Locator Update (LU) message [RFC6745] [RFC6743], to CN informing it that L_2 is now the valid Locator for the communication. This operation would not be visible to H, although there might be some disruption to transmission, e.g., packets being sent from CN to H that are in flight when sbr1 goes down may be lost. The SBR might also need to update DNS entries (see Section 3.3). Since ILNP requires that all Locator Update messages be authenticated by the ILNP Nonce, the SBR will need to include the appropriate Nonce values as part of its cache of information about ILNP sessions traversing the SBR. (NOTE: Since commercial security gateways available as of this writing reportedly can handle full stateful packet inspection for millions of flows at multi-gigabit speeds, it should be practical for such devices to cache the ILNP flow information, including Nonce values.)
ただし、sbr1がダウンした場合、SBRは通信をインターフェースsbr2に移動します。 HはSBRのアクションを認識していないため、SBR1からsbr2への接続をハンドオフするために、SBRはIL-Vの「ペア」に関するいくつかの状態を維持する必要があります。そのため、通信をsbr2に移動すると、SBRはまずLocator Update（LU）メッセージ[RFC6745] [RFC6743]を送信して、L_2が通信の有効なロケーターであることをCNに通知します。この操作はHからは見えませんが、送信が中断される可能性があります。たとえば、sbr1がダウンしたときに飛行中のCNからHに送信されるパケットが失われる可能性があります。 SBRはDNSエントリを更新する必要がある場合もあります（セクション3.3を参照）。 ILNPでは、すべてのロケーター更新メッセージがILNPナンスによって認証される必要があるため、SBRは、SBRを通過するILNPセッションに関する情報のキャッシュの一部として、適切なナンス値を含める必要があります。 （注：この記事の執筆時点で利用可能な商用セキュリティゲートウェイは、何百万ものフローの完全なステートフルパケットインスペクションをマルチギガビットの速度で処理できるため、そのようなデバイスがNonce値を含むILNPフロー情報をキャッシュすることは実用的です。）
This approach has some efficiency gains over the approach for multihoming described in [RFC6740], where each hosts manages its own connectivity.
このアプローチは、[RFC6740]で説明されているマルチホーミングのアプローチよりも効率が向上し、各ホストが独自の接続を管理します。
If sbr1 was to be reinstated, now with Locator value L_3, then local policy would determine if the communication should be moved back to sbr1, with appropriate additional actions, such as transmission of LU messages with the new Locator values and also the updates to DNS.
sbr1が復元され、ロケーター値がL_3になった場合、ローカルポリシーは、新しいロケーター値を含むLUメッセージの送信やDNSの更新などの適切な追加アクションを使用して、通信をsbr1に戻すかどうかを決定します。
Note that in such movement of an ILNP session across interfaces at the SBR, only Locator values in ILNP packets are changed. As already noted in [RFC6740], end-to-end transport-layer session state invariance is maintained.
SBRのインターフェイス間でのILNPセッションのこのような移動では、ILNPパケットのロケータ値のみが変更されることに注意してください。 [RFC6740]ですでに述べたように、エンドツーエンドのトランスポート層セッション状態の不変性は維持されます。
When the SBR manages connectivity as described above, the internal hosts, such as H, are not necessarily aware of any connectivity changes. Indeed, there is certainly no requirement for them to be aware. So, if H was a server expecting incoming connections, the SBR must update the relevant DNS entries when the site connectivity changes.
SBRが上記のように接続を管理する場合、Hなどの内部ホストは必ずしも接続の変更を認識しません。確かに、彼らが気づく必要は確かにありません。したがって、Hが着信接続を予期しているサーバーである場合、SBRはサイトの接続が変更されたときに関連するDNSエントリを更新する必要があります。
There are two possibilities: each host could have its own L32 or L64 records; or the site might use a combination of LP and L32/L64 records (see Section 2.4). Either way, the SBR would need to update the relevant DNS entries. For our example, with ILNPv6 and LP records in use, the SBR would need to manage two L64 records (one for each uplink) that would resolve from a FQDN, for example, site.example.com. Meanwhile, individual hosts, such as H, have an FQDN that resolves to an NID value and an LP record that would contain the value site.example.com, which then would be used to look up the two L64 records.
2つの可能性があります。各ホストは独自のL32またはL64レコードを持つことができます。または、サイトはLPレコードとL32 / L64レコードの組み合わせを使用する場合があります（セクション2.4を参照）。どちらの方法でも、SBRは関連するDNSエントリを更新する必要があります。この例では、ILNPv6およびLPレコードを使用しているため、SBRは、site.example.comなどのFQDNから解決される2つのL64レコード（アップリンクごとに1つ）を管理する必要があります。一方、Hなどの個々のホストには、NID値に解決されるFQDNと、値site.example.comを含むLPレコードがあり、これを使用して2つのL64レコードを検索します。
If the SBR is multihomed, as in Figure 3.1, then it will have (at least) two Locator values, one for each link, and local policy will need to be used to determine how preference values are applied in the relevant L32 and L64 records.
SBRがマルチホームの場合、図3.1のように、（少なくとも）2つのロケーター値（リンクごとに1つ）があり、ローカルポリシーを使用して、関連するL32およびL64レコードに優先値を適用する方法を決定する必要があります。 。
Imagine that in the scenario described above, there was a link failure that resulted in sbr1 going down and sbr2 was used. Existing ILNP sessions in progress would move to sbr2 as described above. However, new incoming ILNP sessions to the site would need to know to use L_2 and not L_1. L_1 and L_2 would be stored in DNS records (e.g., L32 for ILNPv4 or L64 for ILNPv6). If a remote host has already resolved from DNS that L_1 is the correct Locator for sending packets to the site, then that host might be holding stale information.
上記のシナリオで、リンク障害が発生してsbr1がダウンし、sbr2が使用されたとします。進行中の既存のILNPセッションは、上記のようにsbr2に移動します。ただし、サイトへの新しい着信ILNPセッションは、L_1ではなくL_2を使用することを認識する必要があります。 L_1とL_2はDNSレコードに格納されます（たとえば、ILNPv4の場合はL32、ILNPv6の場合はL64）。リモートホストがDNSから既に解決していて、L_1がサイトにパケットを送信するための正しいロケーターである場合、そのホストは古い情報を保持している可能性があります。
DNS allows values returned to be aged using Time-To-Live (TTL), which is specified in the time unit of seconds. So that remote nodes do not hold on to stale values from DNS, the L64 records for our site should have low TTL values. An appropriate value must be considered carefully. For example, let us assume that the site administrator knows that when sbr1 fails, it takes 20 seconds to failover to sbr2. Then, 20 s would seem to be an appropriate time to use for the TTL value of an L64 for the site: if a remote node had just resolved the value L_1 for the site, and the link to sbr1 went down, that remote node would not hold the stale value of L_1 for any longer than it takes the site to failover to sbr2 and use L_2.
DNSでは、秒単位で指定される存続可能時間（TTL）を使用して、返される値をエージングすることができます。リモートノードがDNSからの古い値を保持しないようにするには、サイトのL64レコードのTTL値を低くする必要があります。適切な値を慎重に検討する必要があります。たとえば、sbr1に障害が発生した場合、sbr2にフェイルオーバーするのに20秒かかることをサイト管理者が知っていると仮定します。次に、20秒は、サイトのL64のTTL値に使用するのに適切な時間のようです。リモートノードがサイトの値L_1を解決した直後に、sbr1へのリンクがダウンした場合、そのリモートノードはサイトがsbr2にフェイルオーバーしてL_2を使用するよりも長く、L_1の古い値を保持しないでください。
Our studies for a university school site network show that low TTL values, as low as zero, are feasible for operational use [BA11].
大学の学校サイトネットワークに関する私たちの調査では、ゼロのような低いTTL値が運用での使用に適していることが示されています[BA11]。
NOTE: From 01 November 2010, the site network of the School of Computer Science, University of St Andrews, UK, has been running operational DNS with DNS A records that have TTL of zero. At the time of writing of this document (November 2012), a zero DNS TTL was still in use at the school.
注：2010年11月1日から、英国のセントアンドリュース大学のコンピュータサイエンス学部のサイトネットワークは、TTLがゼロのDNS Aレコードを使用して運用DNSを実行しています。このドキュメントの執筆時点（2012年11月）では、DNS DNS TTLはまだ学校で使用されていました。
For site multihoming, with multiple SBRs, a situation may be as follows (see also Section 5.3.1 in [RFC6740]).
複数のSBRを使用するサイトマルチホーミングの場合、状況は次のようになります（[RFC6740]のセクション5.3.1も参照）。
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 P
CP =調整プロトコルL_1 =グローバルロケーター値1 L_2 =グローバルロケーター値2 SBR_A =サイトボーダールーターA SBR_B =サイトボーダールーターP
Figure 3.2: A Dual-Router Multihoming Scenario for ILNP
図3.2：ILNPのデュアルルーターマルチホーミングシナリオ
The use of two physical routers provides an extra level of resilience compared to the scenario of Figure 3.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 functions are available today in some commercial network security products. Note that, logically, there is little difference between Figures 5.1 and 3.2, but with two distinct routers in Figure 3.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つの物理ルーターを使用すると、図3.1のシナリオと比較して、回復力がさらに向上します。 2つのルーター間の調整プロトコル（CP）は、サイトネットワークに適用されている管理ポリシーに従って、それらのアクションの同期を維持します。このような機能は、一部の商用ネットワークセキュリティ製品で現在利用できます。論理的には、図5.1と3.2の間にはほとんど違いがないことに注意してください。ただし、図3.2の2つの異なるルーターでは、CPを使用した対話が必要です。もちろん、各ルーターと3つ以上のルーターに複数のインターフェイスを設定することもできます。
The ILNP Architectural Description [RFC6740] describes the basic approach to enabling site (network) mobility with ILNP. However, as an option, it is possible to leave the control of site mobility to an ILNP-enabled SBR by exploiting the alternative site multihoming feature described in Section 3 of this document.
ILNPアーキテクチャの説明[RFC6740]は、ILNPでサイト（ネットワーク）モビリティを有効にする基本的なアプローチを説明しています。ただし、オプションとして、このドキュメントのセクション3で説明されている代替サイトマルチホーミング機能を利用することで、サイトモビリティの制御をILNP対応のSBRに任せることができます。
Again, as described in [RFC6740], we exploit the duality between mobility and multihoming for ILNP.
ここでも、[RFC6740]で説明されているように、ILNPのモビリティとマルチホーミングの二重性を活用しています。
Let us consider the mobile network in Figure 4.2, which is taken from [RFC6740].
[RFC6740]から引用した図4.2のモバイルネットワークを考えてみましょう。
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . L_L | ra1+------. .
. .----+ | . .
. H . | ra2+-- . .
. . . . +------+ . .
. . .
Figure 4.1a: ILNP Mobile Network before Handover
図4.1a：ハンドオーバー前のILNPモバイルネットワーク
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . L_L | ra1+------. . . . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . . . . .
. .
. . .
ISP_2
Figure 4.1b: ILNP Mobile Network during Handover
図4.1b：ハンドオーバー中のILNPモバイルネットワーク
site ISP_2
network SBR . . .
. . . . +------+ . .
. . L_L | ra1+-- . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . .
. . .
Figure 4.1c: ILNP Mobile Network after Handover
図4.1c：ハンドオーバ後のILNPモバイルネットワーク
H = host L_1 = global Locator value 1 L_2 = global Locator value 2 L_L = local Locator value raN = radio interface N SBR = Site Border Router
H =ホストL_1 =グローバルロケーター値1 L_2 =グローバルロケーター値2 L_L =ローカルロケーター値raN =無線インターフェイスN SBR =サイトボーダールーター
Figure 4.1: An Alternative Mobile Network Scenario with an SBR
図4.1：SBRを使用した代替モバイルネットワークシナリオ
We assume that the site (network) is mobile, and the SBR has two radio interfaces, ra1 and ra2. In the figure, ISP_1 and ISP_2 are separate, radio-based service providers, accessible via interfaces ra1 and ra2.
サイト（ネットワーク）はモバイルであり、SBRには2つの無線インターフェースra1とra2があると仮定します。この図では、ISP_1とISP_2は別々の無線ベースのサービスプロバイダーであり、インターフェイスra1とra2を介してアクセスできます。
While the SBR makes the transition from using a single link (Figure 4.1a) to the handover overlap on both links (Figure 4.1b), to only using a single link again (Figure 4.1c), the host H continues to use only Locator value L_L, as already described for Site Multihoming (S-MH). During this time the actions taken by the SBR are the same as already described in [RFC6740], except that the SBR:
SBRは単一のリンクの使用（図4.1a）から両方のリンクのハンドオーバーオーバーラップ（図4.1b）に移行しますが、再度単一のリンクのみの使用（図4.1c）に移行しますが、ホストHは引き続きロケーターのみを使用します値L_L。サイトマルチホーミング（S-MH）ですでに説明されています。この間、SBRが実行するアクションは、[RFC6740]ですでに説明されているものと同じですが、SBRは次の点が異なります。
a) also performs that ILNP localised numbering function described in Section 2.
a) セクション2で説明するILNPローカライズされた番号付け機能も実行します。
b) does not need to advertise L_1 and L_2 internally if only local numbering is being used.
b) ローカル番号付けのみが使用されている場合は、L_1およびL_2を内部でアドバタイズする必要はありません。
As for the case of S-MH above, H need not be aware of the change in connectivity for the SBR if it is only using local numbering, and the SBR would send LU messages for H (for any correspondent nodes, not shown in Figure 4.1), and would update DNS entries as required.
上記のS-MHの場合と同様に、ローカル番号付けのみを使用している場合、HはSBRの接続の変更を認識している必要はなく、SBRはHのLUメッセージを送信します（図に示されていない、対応するノードの場合）。 4.1）、必要に応じてDNSエントリを更新します。
The difference to the S-MH scenario described earlier in this document is that in the situation of Figure 4.1b, the SBR can opt to use soft handover has previously described in [RFC6740].
このドキュメントの前半で説明したS-MHシナリオとの違いは、図4.1bの状況では、SBRが以前に[RFC6740]で説明したソフトハンドオーバーの使用を選択できることです。
Again, there is an efficiency gain compared to the situation described in [RFC6740]: the SBR provides a convenient point at which to centrally manage the movement of the site as a whole. Note that in Figure 4.1b, the site is multihomed.
ここでも、[RFC6740]で説明されている状況と比較して効率が向上しています。SBRは、サイト全体の移動を集中管理するための便利なポイントを提供します。図4.1bでは、サイトがマルチホームであることに注意してください。
As for S-MH, L_1 and L_2 could be advertised internally, as a local policy decision, for those hosts that require direct control of their connectivity.
S-MHに関しては、L_1とL_2は、ローカルポリシーの決定として、接続の直接制御を必要とするホストに対して内部的にアドバタイズできます。
Note that for handover, immediate handover will have a similar behaviour to a link outage as described for S-MH. However, as ILNP allows soft-handover, during the handover period, this should help to reduce (perhaps even remove) packet loss.
ハンドオーバーの場合、即時ハンドオーバーは、S-MHについて説明したリンク障害と同様の動作をすることに注意してください。ただし、ILNPはソフトハンドオーバーを許可するので、ハンドオーバー期間中、これはパケット損失を減らす（場合によっては削除する）のに役立ちます。
As for S-MH, a similar discussion to Section 3.3 applies for mobile networks with respect to the updates to DNS. As a mobile network is likely to have more frequent changes to its connectivity than a multihomed network would due to connectivity changes, the use of LP DNS records is likely to be particularly advantageous here.
S-MHに関しては、セクション3.3と同様の議論がDNSの更新に関してモバイルネットワークに適用されます。モバイルネットワークは、接続の変更により、マルチホームネットワークよりも頻繁に接続が変更される可能性があるため、LP DNSレコードを使用すると、ここで特に有利になります。
As for S-MH, a similar discussion to Section 3.4 applies for mobile networks with respect to the TTL of L32 and/or L64 records that are used for the name of the mobile network. In the case of the mobile network, it makes sense for the TTL to be aligned to the time for handover.
S-MHについては、モバイルネットワークの名前に使用されるL32およびL64レコードのTTLに関して、セクション3.4と同様の議論がモバイルネットワークに適用されます。モバイルネットワークの場合、TTLをハンドオーバーの時間に合わせることが理にかなっています。
The use of Locator rewriting provides some simple yet useful options for traffic engineering (TE) controlled from the edge-site via the SBR, requiring no cooperation from the service provider other than the provision of basic connectivity services, e.g., physical connectivity, allocation of IP Address prefixes and packet forwarding. This does not preclude other TE options that are already in use, such as use of MPLS, but we choose to highlight here the specific options available and controllable solely through the use of ILNP.
ロケーターの書き換えの使用は、SBRを介してエッジサイトから制御されるトラフィックエンジニアリング（TE）にいくつかのシンプルでありながら有用なオプションを提供します。たとえば、物理接続、 IPアドレスのプレフィックスとパケット転送。これは、MPLSの使用など、すでに使用されている他のTEオプションを排除するものではありませんが、ここでは、ILNPを使用することによってのみ利用可能で制御可能な特定のオプションを強調表示します。
When a site network is multihomed, we have seen that the use of the Locator rewriting function permits the SBR to have packet-by-packet control when forwarding on external links. Various configuration and policies could be applied at the SBR in order to control the egress and ingress traffic to the site network.
サイトネットワークがマルチホームである場合、ロケーターの書き換え機能を使用すると、外部リンクで転送するときにSBRがパケットごとに制御できることがわかりました。サイトネットワークへの出力トラフィックと入力トラフィックを制御するために、SBRでさまざまな構成とポリシーを適用できます。
Let us consider Figure 5.1, and assume ILNP local numbering is in use; that H1, H2, and H3 use, respectively, Identifier values, I_1, I_2 and I_3; and all of them use Locator value L_L.
図5.1を検討し、ILNPローカル番号付けが使用されていると仮定します。 H1、H2、およびH3がそれぞれ識別子値I_1、I_2、およびI_3を使用すること。そして、それらすべてがロケーター値L_Lを使用します。
site . . . .
network SBR . .
. . . . +------+ L_1 . .
. . | sbr1+------. .
. H2 .L_L | | . .
. H3 .----+ | . Internet .
. . | | . .
. H1 . | sbr2+------. .
. . . . +------+ L_2 . .
. .
. . . .
HN = host N L_1 = global Locator value 1 L_2 = global Locator value 2 L_L = local Locator value SBR = Site Border Router sbrN = interface N on sbr
HN =ホストN L_1 =グローバルロケーター値1 L_2 =グローバルロケーター値2 L_L =ローカルロケーター値SBR =サイトボーダールーターsbrN = sbrのインターフェイスN
Figure 5.1: A Site Multihoming Scenario for Traffic Control
図5.1：トラフィック制御のサイトマルチホーミングシナリオ
The SBR could be configured, subject to local policy, to try to control load across the external links. For example, it could be configured initially with the following mappings:
SBRは、ローカルポリシーに従って、外部リンク全体の負荷を制御しようとするように構成できます。たとえば、最初に次のマッピングで構成できます。
srcI=I_1, sbr1 --- (3a)
srcI=I_2, sbr2 --- (3b)
srcI=I_3, sbr1 --- (3c)
These mappings direct packets matching course Identifier values to particular outgoing interfaces. As load changes, these mappings could be changed. For example, expression (3c) could be changed to:
これらのマッピングは、コース識別子の値に一致するパケットを特定の発信インターフェイスに転送します。負荷が変化すると、これらのマッピングが変更される可能性があります。たとえば、式（3c）は次のように変更できます。
srcI=I_3, sbr2 --- (4)
and the SBR would need to send LU message to the correspondents of H3 (sbr to uses L_2 while sbr1 uses L_1). The egress connectivity is totally within control of the SBR under administrative policy, as already seen in the descriptions of multihoming and mobility in this document.
また、SBRはLUメッセージをH3の通信相手に送信する必要があります（sbr1がL_1を使用する間、sbrはL_2を使用します）。このドキュメントのマルチホーミングとモビリティの説明ですでに見たように、出力接続は完全に管理ポリシーの下でSBRの制御下にあります。
Of course, more complex policies are possible, based on:
もちろん、以下に基づいて、より複雑なポリシーが可能です。
- whether ILNP sessions are incoming or outgoing - time of day - internal subnets
- ILNPセッションが着信か発信か-時刻-内部サブネット
and any number of criteria already in use for control of traffic.
トラフィックの制御にすでに使用されている任意の数の基準。
In expressions (3a,b,c) above, source I values are used. However:
上記の式（3a、b、c）では、ソースIの値が使用されます。しかしながら：
- destination I values could be used - source or destination L values could be used - mappings could be to L values, not to specific interfaces
- 宛先I値を使用できます-送信元または宛先L値を使用できます-マッピングは、特定のインターフェースではなく、L値に対して行うことができます
and, again, any number of criteria could be used to manipulate the packet path, based on filtering of values in header fields and local policy.
また、ヘッダーフィールドの値のフィルタリングとローカルポリシーに基づいて、任意の数の基準を使用してパケットパスを操作できます。
With ILNP, hosts do not need to be aware of the operation of the SBR in this manner.
ILNPを使用すると、ホストはこの方法でSBRの動作を認識する必要がありません。
Note, again, that in this scenario, there is nothing to prevent SBR from also advertising L_1 and L_2 into the site network. If required, administrative controls could be used to enable selective hosts in the site network to use L_1 and L_2 directly as described in [RFC6740].
このシナリオでも、SBRがL_1およびL_2をサイトネットワークにアドバタイズするのを妨げるものは何もないことに注意してください。必要に応じて、[RFC6740]で説明されているように、管理制御を使用して、サイトネットワーク内の選択したホストがL_1およびL_2を直接使用できるようにすることができます。
Extending the scenario for load-balancing described above, it is also be possible for the ILNP-capable SBR to direct traffic along specific network paths based on the use of different L values, i.e., by using multiple prefixes assigned from upstream providers.
上記のロードバランシングのシナリオを拡張すると、ILNP対応のSBRが、異なるL値の使用に基づいて、つまりアップストリームプロバイダーから割り当てられた複数のプレフィックスを使用して、特定のネットワークパスに沿ってトラフィックを送信することもできます。
Of course, as previously discussed, these prefixes can be Provider Aggregated (PA) and need not be Provider Independent (PI).
もちろん、前述のように、これらのプレフィックスはプロバイダー集約（PA）にすることができ、プロバイダー非依存（PI）である必要はありません。
Let us consider Figure 5.2 and assume ILNP local numbering is in use; that H1, H2 and H3 use, respectively, Identifier values, I_1, I_2, and I_3; and all of them use Locator value L_L. Let us also assume that the node CN uses IL-V [I_CN, L_CN].
図5.2を検討し、ILNPローカル番号付けが使用されていると仮定します。 H1、H2、およびH3がそれぞれ識別子の値I_1、I_2、およびI_3を使用すること。そして、それらすべてがロケーター値L_Lを使用します。また、ノードCNがIL-V [I_CN、L_CN]を使用すると仮定します。
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L1,L2 . . +----+
. . | sbr1+--------. .
. H2 .L_L | | . .
. H3 .----+ sbr2+--------. Internet .
. . | | L3,L4 . .
. . | | . .
. H1 . | sbr3+--------. .
. . . . +------+ L5,L6 . .
. .
. . . .
CN = correspondent node HN = host N LN = global Locator value N L_L = local Locator value SBR = Site Border Router sbrN = interface N on sbr
CN =コレスポンデントノードHN =ホストN LN =グローバルロケーター値N L_L =ローカルロケーター値SBR =サイトボーダールーターsbrN = sbr上のインターフェイスN
Figure 5.2: A Site Multihoming Scenario for Traffic Control
図5.2：トラフィック制御のサイトマルチホーミングシナリオ
Here, many configurations are possible. For example, for egress traffic:
ここでは、多くの構成が可能です。たとえば、下りトラフィックの場合：
srcI=I_2, L2 --- (5a)
srcI=I_3, L3 --- (5b)
dstI=I_CN, L6 --- (5c)
srcI=I_1 dstI=I_CN, L1 --- (5d)
Expression (5a) maps all egress packets from H2 to have their source Locator value rewritten to L2 (and implicitly to use interface sbr1). Expression (5b) maps all egress packets from H3 to have their source Locator value rewritten to L3 (and implicitly to use interface sbr2). Expression (5c) directs any traffic to CN to use Locator value L6 as the source Locator (and implicitly to use interface sbr3), and may override (5a) and (5b), subject to local policy, when packets to CN are from H2 or H3.
式（5a）は、H2からのすべての出力パケットをマップして、ソースロケーター値をL2に書き換えます（暗黙的にインターフェイスsbr1を使用します）。式（5b）は、H3からのすべての出力パケットをマップして、ソースロケーター値をL3に書き換えます（暗黙的にインターフェイスsbr2を使用します）。式（5c）は、ロケーター値L6をソースロケーターとして使用するように（そして暗黙的にインターフェースsbr3を使用するように）トラフィックをCNに送信し、CNへのパケットがH2からのものである場合、ローカルポリシーに従って、（5a）と（5b）をオーバーライドします。またはH3。
Meanwhile, in expression (5d), we see a further, more specific rule, in that packets from H1 destined to CN should use Locator value L1 (and implicitly to use interface sbr1).
一方、式（5d）では、H1からCN宛てのパケットがロケーター値L1を使用する（そして暗黙的にインターフェースsbr1を使用する）必要があるという、より具体的な規則が見られます。
Note the implicit bindings to interfaces in expressions (5a,b,c,d), compared to the explicit bindings in expressions (3a,b,c). ILNP only requires that the Locator values are correctly rewritten and packets forwarded in conformance with the routing already configured for the Locator values.
式（3a、b、c）の明示的なバインディングと比較して、式（5a、b、c、d）のインターフェースへの暗黙のバインディングに注意してください。 ILNPは、ロケーター値が正しく書き換えられ、ロケーター値に対して既に構成されているルーティングに従ってパケットが転送されることのみを要求します。
Of course, these rules can be changed dynamically at the SBR, and the SBR will migrate ILNP sessions across Locator values, as already described above for mobility.
もちろん、これらのルールはSBRで動的に変更でき、SBRは、モビリティについてすでに説明したように、ロケーター値全体でILNPセッションを移行します。
As ILNP has first class support for mobility and multihoming, and supports flexible options for localised addressing, there is great potential for it to be used in datacentre scenarios. Further details of possibilities are in [BA12], with a summary presented here.
ILNPはモビリティとマルチホーミングをファーストクラスでサポートし、ローカライズされたアドレス指定の柔軟なオプションをサポートしているため、データセンターシナリオで使用される可能性が非常に高くなります。可能性の詳細は[BA12]にあり、ここに要約を示します。
There are several scenarios that could be beneficial to datacentres, in order to provide functions such as load balancing, resilience and fault tolerance, and resource management:
ロードバランシング、回復力とフォールトトレランス、リソース管理などの機能を提供するために、データセンターにとって有益なシナリオがいくつかあります。
- Same datacentre, internal Virtual Machine (VM) mobility: This could be beneficial in load balancing, dynamically, where load changes are taking place. The remote user does not see the VM has moved.
- 同じデータセンター、内部仮想マシン（VM）のモビリティ：これは、負荷の変更が行われる動的な負荷分散に役立つ可能性があります。リモートユーザーには、VMが移動したことが表示されません。
- Different datacentres, transparent mobility: This is where the datacentre resources may be geographically distributed, but the geographical movement is transparent to the remote user.
- さまざまなデータセンター、透過的なモビリティ：データセンターのリソースを地理的に分散させることができますが、地理的な移動はリモートユーザーに対して透過的です。
- Different datacentres, mobility is visible: This is where the datacentre resources may be geographically distributed, but the geographical movement is visible to the remote user.
- さまざまなデータセンター、モビリティが表示されます。これは、データセンターのリソースが地理的に分散されている場所ですが、地理的な移動はリモートユーザーに表示されます。
These are three situations that may be supported by ILNP, but they are not the only ones: we provide these here as examples, and they are not intended to be prescriptive. The intention is only to show the flexibility that is possible through the use of ILNP.
これらはILNPによってサポートされる可能性のある3つの状況ですが、それらは唯一の状況ではありません。ここでは例としてこれらを提供しますが、それらは規範となることを意図していません。意図は、ILNPを使用することで可能な柔軟性を示すことだけです。
This section describes some Virtual Machine (VM) mobility capabilities that are possible with ILNP. Depending on the internal details and virtualisation model provided by a VM platform, it might be sufficient for the guest operating system to support ILNP. In some cases, again depending on the internal details and virtualisation model provided by a VM platform, the VM platform itself also might need to include support for ILNP.
このセクションでは、ILNPで可能ないくつかの仮想マシン（VM）モビリティ機能について説明します。 VMプラットフォームによって提供される内部の詳細と仮想化モデルによっては、ゲストオペレーティングシステムがILNPをサポートするだけで十分な場合があります。 VMプラットフォームによって提供される内部の詳細と仮想化モデルによっては、VMプラットフォーム自体もILNPのサポートを含める必要がある場合もあります。
Details of how a particular VM platform works, and which virtualisation model(s) a VM platform supports, are beyond the scope of this document. Internal implementation details of VM platform support for ILNP are also beyond the scope of this document, just as internal implementation details for any other networked system supporting ILNP are beyond the scope of this document.
特定のVMプラットフォームがどのように機能するか、およびVMプラットフォームがサポートする仮想化モデルの詳細は、このドキュメントの範囲外です。 ILNPをサポートする他のネットワークシステムの内部実装の詳細がこのドキュメントの範囲を超えているのと同様に、ILNPのVMプラットフォームサポートの内部実装の詳細もこのドキュメントの範囲を超えています。
Let us consider first the scenario of Figure 6.1, noting its similarity to Figure 2.1 for use of localised numbering.
最初に図6.1のシナリオを検討します。ローカライズされた番号付けを使用する場合の図2.1との類似性に注目してください。
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. H2 .L_L | | . .
. .----+ | . Internet .
. V*H1 . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
CN = Correspondent Node V = Virtual machine image Hx = Host x L_1 = global Locator value L_L = local Locator value SBR = Site Border Router
CN =対応するノードV =仮想マシンイメージHx =ホストx L_1 =グローバルロケーター値L_L =ローカルロケーター値SBR =サイトボーダールーター
Figure 6.1: A Simple Virtual Image Mobility Example for ILNP
図6.1：ILNPの簡単な仮想イメージモビリティの例
L_L is a Locator value used for the ILNP hosts H1 and H2. Here, the "V*H1" signifies that the virtual machine image V is currently resident on H1. Let us assume that V has Identifier I_V. Note that as H1 and H2 have the same Locator value (L_1), as far as CN is concerned, it does not matter if V is resident on H1 or H2, all transport packets between V and CN will have the same signature as far as CN is concerned, e.g., for a UDP flow (in analogy to (1a)):
L_Lは、ILNPホストH1およびH2に使用されるロケーター値です。ここで、「V * H1」は、仮想マシンイメージVが現在H1に常駐していることを示します。 Vに識別子I_Vがあると仮定します。 H1とH2は同じロケーター値（L_1）を持っているため、CNに関する限り、VがH1またはH2に常駐するかどうかは問題ではないことに注意してください。VとCN間のすべてのトランスポートパケットは、同じシグネチャを持ちます。 CNは、たとえばUDPフローに関係しています（（1a）と同様）。
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_1, L_CN> --- (6a)
Now, if V was to migrate to H2, the migration would be an issue purely local to the site network, and the end-to-end integrity of the transport flow would be maintained.
VがH2に移行する場合、移行はサイトネットワークに純粋にローカルな問題であり、トランスポートフローのエンドツーエンドの整合性が維持されます。
Of course, there are practical operating systems issues in enabling such a migration locally, but products exist today that could be modified and made ILNP-aware in order to enable such VM image mobility.
もちろん、そのような移行をローカルで有効にすることには実用的なオペレーティングシステムの問題がありますが、そのようなVMイメージのモビリティを有効にするために変更およびILNP対応にすることができる製品が今日存在します。
Note that for convenience, above, we have used localised numbering for ILNP, but if local Locator values were not used and the whole site simply used L_1, the principle would be the same.
上記の便宜上、ILNPにはローカライズされた番号付けを使用しましたが、ローカルロケーター値を使用せず、サイト全体が単にL_1を使用する場合も、原則は同じです。
Let us now consider an extended version of the scenario above in Fig. 6.2, where we see that there is a second site network, which is geographically distant to the first site network, and the two site networks are interconnected via their respective SBRs.
上記の図6.2のシナリオの拡張バージョンについて考えてみましょう。最初のサイトネットワークから地理的に離れた2番目のサイトネットワークがあり、2つのサイトネットワークはそれぞれのSBRを介して相互接続されています。
site . . . . +----+
network 1 SBR1 . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. .L_L1| | . .
. .----+ | . Internet .
. V*H1 . | | . .
. . | | . .
. . . . +---+--+ . .
: . .
: . .
. . . . +---+--+ L_2 . .
. . | +------. .
. H2 .L_L2| | . .
. .----+ | . .
. . | | . .
. . | | . .
. . . . +------+ . .
site SBR2 . .
network 2 . . . .
: = logical inter-router link and coordination CN = Correspondent Node V = Virtual machine image Hx = Host x L_y = global Locator value y L_Lz = local Locator value z SBR = Site Border Router
：=論理ルーター間リンクと調整CN =対応ノードV =仮想マシンイメージHx =ホストx L_y =グローバルロケーター値y L_Lz =ローカルロケーター値z SBR =サイトボーダールーター
Figure 6.2: A Simple Localised Numbering Example for ILNP
図6.2：ILNPのローカライズされた簡単な番号付けの例
Note that the logical inter-router link between SBR1 and SBR2 could be realised physically in many different ways that are available today and are not ILNP-specific, e.g., leased line, secure IP-layer or Layer 2 tunnel, etc. We assume that this link also allows coordination between the two SBRs. For now, we ignore external link L_2 on SBR2, and assume that the remote node, CN, is in communication with V through SBR1.
SBR1とSBR2間の論理ルーター間リンクは、現在利用可能でILNP固有ではないさまざまな方法で物理的に実現できることに注意してください。たとえば、専用線、セキュアIPレイヤー、レイヤー2トンネルなどです。このリンクにより、2つのSBR間の調整も可能になります。ここでは、SBR2の外部リンクL_2を無視し、リモートノードCNがSBR1を介してVと通信していると想定します。
When in initial communication, the packets have the signature is given in expression (6a). When V moves to H2, it now uses Locator value L_L2, but all communication between V and CN is still routed via SBR1. So, the remote CN still sees that same packet signature as given in expression (6a). L_L1 and L_L2 are, effectively, two internal (private) subnetworks, and are not visible to CN.
最初の通信では、パケットに署名があります（6a）。 VがH2に移動すると、ロケーター値L_L2を使用しますが、VとCN間のすべての通信はSBR1経由でルーティングされます。したがって、リモートCNは、式（6a）で指定されたものと同じパケット署名をまだ認識しています。 L_L1とL_L2は、事実上、2つの内部（プライベート）サブネットワークであり、CNからは見えません。
However, SBR2 and SBR1 must coordinate so that any further communication to V via SBR1 is routed across the inter-router link. Again, there are commercial products today that could be adapted to manage such shared state.
ただし、SBR2とSBR1は、SBR1を介したVへの通信がルーター間リンクを介してルーティングされるように調整する必要があります。繰り返しになりますが、今日、そのような共有状態を管理するために適応できる商用製品があります。
Clearly, in the scenario of the section above, once V has moved to site network 2, it may be beneficial, for a number of reasons, for communication to V to be routed via SBR2 rather than SBR1.
明らかに、上記のセクションのシナリオでは、Vがサイトネットワーク2に移動すると、さまざまな理由から、Vへの通信がSBR1ではなくSBR2経由でルーティングされることが有益になる場合があります。
When V moves from site network 1 to site network 2, this visibility of mobility could be by V sending ILNP Locator Update messages to the CN during the mobility process. Also, V would update any relevant ILNP DNS records, such as L64 records, for new ILNP session requests to be routed via SBR2.
Vがサイトネットワーク1からサイトネットワーク2に移動するとき、モビリティの可視性は、モビリティプロセス中にVがILNPロケータ更新メッセージをCNに送信することによって可能になります。また、Vは、L64レコードなどの関連するILNP DNSレコードを更新して、新しいILNPセッション要求がSBR2経由でルーティングされるようにします。
Indeed, let us now consider again Figure 6.2, and assume now that Local locators L_L1 and L_L2 are not in use on either site network, and each site networks uses its own global Locator value, L_1 and L_2, respectively, internally. In that case, the packet flow signature for V when it is in site network 1 as viewed from CN is, again as given in expression (6a). However, when V moves to site network 2, it would simply use L_2 as its new Locator, send Locator Update messages to CN as would a normal mobile node for ILNP, and complete its migration to H2. Then, CN would see the packet signatures as in expression (6b).
実際、図6.2をもう一度考えてみましょう。ローカルロケーターL_L1とL_L2はどちらのサイトネットワークでも使用されておらず、各サイトネットワークは独自のグローバルロケーター値L_1とL_2をそれぞれ内部で使用していると仮定します。その場合、ＣＮから見てサイトネットワーク１にあるときのＶのパケットフロー署名は、やはり式（６ａ）で与えられるとおりである。ただし、Vがサイトネットワーク2に移動するときは、新しいロケーターとしてL_2を使用し、ILNPの通常のモバイルノードと同様にロケーター更新メッセージをCNに送信し、H2への移行を完了します。次に、CNは式（6b）のようにパケット署名を確認します。
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_2, L_CN> --- (6b)
In this case, no "special" inter-router link is required for mobility -- the normal Internet connectivity between SBR1 and SBR2 would suffice. However, it is quite likely that some sort of tunnelled link would still be desirable to offer protection of the VM image as it migrates.
この場合、モビリティに「特別な」ルーター間リンクは必要ありません。SBR1とSBR2間の通常のインターネット接続で十分です。ただし、VMイメージが移行するときにVMイメージの保護を提供するには、何らかのトンネルリンクが依然として望ましい場合がほとんどです。
For the remote host -- the CN -- the availability of ILNP would be beneficial. However, for the first two scenarios listed above, as the packet signature of the transport flows remains fixed from the viewpoint of the CN, it seems possible that the benefits of ILNP VM mobility could be used for datacentres even while CNs remain as normal IP hosts. Of course, a major caveat here is that the application level protocols should be "well behaved": that is, the application protocol or configuration should not rely on the use of IP Addresses.
リモートホスト（CN）の場合、ILNPの可用性は有益です。ただし、上記の最初の2つのシナリオでは、トランスポートフローのパケットシグネチャはCNの観点から固定されたままであるため、CNが通常のIPホストのままであっても、ILNP VMモビリティの利点をデータセンターに使用できる可能性があります。もちろん、ここでの主な注意点は、アプリケーションレベルのプロトコルが「適切に動作する」必要があることです。つまり、アプリケーションプロトコルまたは構成は、IPアドレスの使用に依存するべきではありません。
Extending the Locator rewriting paradigm, it is possible to also enable Location privacy for ILNP by a modified version of the "onion routing" paradigm that is used for Tor [DMS04] [RSG98].
ロケーターの書き換えパラダイムを拡張すると、Tor [DMS04] [RSG98]に使用される「オニオンルーティング」パラダイムの変更バージョンによって、ILNPのロケーションプライバシーを有効にすることもできます。
To enable this function, we use a middlebox that we call the Locator Rewriting Relay. The function of this unit is described by the use of Figure 7.1.
この機能を有効にするには、ロケーター書き換えリレーと呼ばれるミドルボックスを使用します。このユニットの機能は、図7.1を使用して説明されています。
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (7a)
v
|
+--+--+
| | src=[I_H, L_1], L_X --- (7b)
| LRR | dst=[I_H, L_X], L_1 --- (7c)
| |
+--+--+
|
v
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_X, L_CN> --- (7d)
LRR = Locator Rewriting Relay
Figure 7.1: Locator Rewriting Relay (LRR) Example
図7.1：ロケーター書き換えリレー（LRR）の例
The operation of the LRR is conceptually very simple. We assume that the LRR first has mappings as given in expressions (7b) and (7c) (see next subsection). Expression (7b) says that for packets with src IL-V [I_H, L_1], the packet's source Locator value should be rewritten to value L_X and then forwarded. Expression (7c) has the complimentary mapping for packets with destination IL-V [I_H, L_1] (for the reverse direction).
LRRの操作は、概念的には非常に単純です。 LRRには、式（7b）および（7c）で指定されたマッピングが最初にあると想定します（次のサブセクションを参照）。式（7b）は、src IL-V [I_H、L_1]のパケットの場合、パケットのソースLocator値を値L_Xに書き換えてから転送する必要があることを示しています。式（7c）には、宛先IL-V [I_H、L_1]（逆方向）のパケットに対する補足マッピングがあります。
Expression (6a) is a UDP/ILNP packet as might be sent in Figure 2.1 from H to CN. However, instead of going directly to L_CN, the packet with destination Locator L_1 goes to a LRR. Expression (7d) is the result of the mapping of packet (7a) using expression (7b).
式（6a）は、図2.1でHからCNに送信される可能性のあるUDP / ILNPパケットです。ただし、L_CNに直接行くのではなく、宛先ロケーターL_1のパケットはLRRに行きます。式（7d）は、式（7b）を使用してパケット（7a）をマッピングした結果です。
Note that it is entirely possible that the packet of expression (7d) then is processed by another LRR for source Locator value L_X. Effectively, this creates and LRR path for the packet, as an overlay path on top of the normal IP routing.
式（7d）のパケットがソースロケータ値L_Xの別のLRRによって処理されることは完全に可能であることに注意してください。これにより、通常のIPルーティングの上にオーバーレイパスとしてパケットのLRRパスが作成されます。
In this way, there is a level of protection, without the need for cryptographic techniques, for the (topological) Location of the packet. Of course, an extremely well-resourced adversary could, potentially, backtrack the LRR path, but, depending on the LRR overlay path that is created, could be very difficult to trace in reality. For example, the mechanism will protect against off-path attacks, but where the threat regime includes the potential for on-path attacks, cryptographically protected tunnels between H and LRR might be required.
このようにして、パケットの（トポロジー的な）ロケーションに対して、暗号化技術を必要としないレベルの保護があります。もちろん、リソースが非常に豊富な敵はLRRパスをバックトラックする可能性がありますが、作成されたLRRオーバーレイパスによっては、実際に追跡するのが非常に難しい場合があります。たとえば、メカニズムはオフパス攻撃から保護しますが、脅威体制にオンパス攻撃の可能性が含まれる場合、HとLRRの間に暗号で保護されたトンネルが必要になる場合があります。
Again, as the Locator value is not part of the end-to-end state, this mechanism is very general and has a low overhead.
繰り返しますが、Locator値はエンドツーエンドの状態の一部ではないため、このメカニズムは非常に一般的で、オーバーヘッドが低くなっています。
There are many options for managing the "network" of LRRs that could be in place if such a system was used on a large scale, including the setting up and removal of LRR state for packet relaying, as for expressions (7b) and (7c). We consider this function to be outside the scope of these ILNP specifications, but note that there are many existing mechanisms that could modified for use, and also many possibilities for new mechanisms that would be specific to the use of ILNP LRRs.
式（7b）と（7c）のように、パケットリレー用のLRR状態の設定と削除を含め、そのようなシステムが大規模に使用された場合に適したLRRの「ネットワーク」を管理するための多くのオプションがあります。 ）。この機能はこれらのILNP仕様の範囲外であると見なしますが、使用するために変更できる既存のメカニズムが多数あり、ILNP LRRの使用に固有の新しいメカニズムにも多くの可能性があることに注意してください。
(Note also that the control/management communication with the LRR does not need to use ILNP: IPv4 or IPv6 could be used.)
（LRRとの制御/管理通信はILNPを使用する必要がないことにも注意してください。IPv4またはIPv6を使用できます。）
The host, H, by itself could install the required state, assuming it was aware of suitable information to contact the LRR. The first packet in an ILNP session might contain a header option called a Locator Redirection Option (LRO). The LRO would contain the Locator value that should be rewritten into the source Locator of the packet. When a LRR receives such a packet, it would install the required state. Such a mechanism could be soft-state, requiring periodic use of the LRO in order to maintain the state in the LRR. The LRO could also be delivered using an ICMP ECHO packet sent from H to the LRR, periodically, again to maintain a soft-state update.
ホストHは、LRRに連絡するための適切な情報を知っていれば、それ自体で必要な状態をインストールできます。 ILNPセッションの最初のパケットには、ロケーターリダイレクトオプション（LRO）と呼ばれるヘッダーオプションが含まれる場合があります。 LROには、パケットの送信元ロケーターに書き換える必要があるロケーター値が含まれます。 LRRがこのようなパケットを受信すると、必要な状態がインストールされます。このようなメカニズムはソフト状態である可能性があり、LRRの状態を維持するためにLROを定期的に使用する必要があります。 LROは、ソフト状態の更新を維持するために、HからLRRに定期的に送信されるICMP ECHOパケットを使用して配信することもできます。
It would, of course, be prudent to protect the LRR state control packets with some sort of authentication token, to prevent an adversary from easily installing false LRR state and causing packets from H or its correspondent to be subject to man-in-the-middle attacks, or black-holing. Again, such attacks are not specific to ILNP or new to ILNP.
もちろん、ある種の認証トークンでLRR状態制御パケットを保護し、攻撃者が誤ったLRR状態を簡単にインストールして、Hまたはその通信相手からのパケットがman-in-the-ミドルアタック、またはブラックホーリング。繰り返しますが、そのような攻撃はILNPに固有のものではなく、ILNPにとって新しいものでもありません。
It would also be possible to use proprietary application level protocols, with strong authentication for the control of the LRR state. For example, an application level protocol based on XMPP (http://xmpp.org/) operating over SSL.
また、LRR状態を制御するための強力な認証を備えた独自のアプリケーションレベルプロトコルを使用することもできます。たとえば、SSLで動作するXMPP（http://xmpp.org/）に基づくアプリケーションレベルのプロトコル。
Above, we have offered very brief and incomplete descriptions of some possibilities, and we do not necessarily mandate any one of them: they serve only as examples.
上記では、いくつかの可能性について非常に簡潔で不完全な説明を提供しましたが、必ずしもそれらのいずれかを強制するわけではありません。これらは例としてのみ機能します。
For the sake of completeness, and in complement to Section 6, it should be noted that ILNP can use either cryptographically verifiable Identifier values, or use Identifier values that provide a level of anonymity to protect a user's privacy. More details are given in Sections 2 and 11 of [RFC6741].
完全を期すため、およびセクション6を補足するものとして、ILNPは暗号で検証可能な識別子の値、またはユーザーのプライバシーを保護するために匿名性のレベルを提供する識別子の値を使用できることに注意してください。詳細は、[RFC6741]のセクション2と11に記載されています。
The relevant security considerations to this document are the same as for the main ILNP Architectural Description [RFC6740]. The one additional point to note is that this document describes ILNP capability in the SBR and so those adversaries wishing to subvert the operation of ILNP specifically, have a target that would, potentially, disable an entire site. However, this is not an attack vector that is specific to ILNP: today, disruption of an IPv4 or IPv6 SBR would have the same impact.
このドキュメントに関連するセキュリティの考慮事項は、メインのILNPアーキテクチャの説明[RFC6740]と同じです。注意すべきもう1つの点は、このドキュメントではSBRのILNP機能について説明しているため、ILNPの運用を具体的に妨害したい敵が、サイト全体を無効にする可能性のあるターゲットを持っているということです。ただし、これはILNPに固有の攻撃ベクトルではありません。現在、IPv4またはIPv6 SBRの中断は同じ影響を及ぼします。
The security considerations for Section 7 (Location Privacy) are already documented in [DMS04] and [RSG98]. One possibility is that the LRR mechanism itself could be used by an adversary to launch an attack and hide his own (topological) Location, for example. This is already possible for IPv4 and IPv4 with a Tor-like system today, so is not new to ILNP.
セクション7（ロケーションプライバシー）のセキュリティに関する考慮事項は、[DMS04]および[RSG98]にすでに文書化されています。 1つの可能性は、LRRメカニズム自体が攻撃者によって使用されて、たとえば攻撃を開始し、自分の（トポロジー的な）ロケーションを隠す可能性があることです。これは、今日Torのようなシステムを備えたIPv4およびIPv4ですでに可能であるため、ILNPの新機能ではありません。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[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月。
[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月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[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月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、2006年8月。
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]オーデット、F。、エド、およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、2007年1月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] Van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC4924] Aboba, B., Ed., and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007.
[RFC4924] Aboba、B.、Ed。、およびE. Davies、「Reflections on Internet Transparency」、RFC 4924、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月。
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC5902] Thaler、D.、Zhang、L。、およびG. Lebovitz、「IAB Thoughts on IPv6 Network Address Translation」、RFC 5902、2010年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月。
[RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, November 2012.
[RFC6740] Atkinson、R.およびS. Bhatti、「Identifier-Locator Network Protocol（ILNP）Architectural Description」、RFC 6740、2012年11月。
[RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations", RFC 6741, November 2012.
[RFC6741] Atkinson、R。およびS. Bhatti、「Identifier-Locator Network Protocol（ILNP）Engineering and Implementation Considerations」、RFC 6741、2012年11月。
[RFC6742] Atkinson, R., Bhatti, S. and S. Rose, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", RFC 6742, November 2012.
[RFC6742] Atkinson、R.、Bhatti、S。およびS. Rose、「Identifier-Locator Network Protocol（ILNP）のDNSリソースレコード」、RFC 6742、2012年11月。
[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。
[ABH07a] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an Integrated Service Through the Use of Naming", Proceedings of ACM Workshop on Mobility in the Evolving Internet Architecture (MobiArch), ACM SIGCOMM, Kyoto, Japan. 27 Aug 2007.
[ABH07a] Atkinson、R.、Bhatti、S。、およびS. Hailes、「ネーミングを使用した統合サービスとしてのモビリティ」、進化するインターネットアーキテクチャにおけるモビリティに関するACMワークショップのプロシーディングス（MobiArch）、ACM SIGCOMM、京都、 日本。 2007年8月27日。
[ABH07b] Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for Unifying Mobility with Multi-Homing, NAT, & Security", Proceedings of 2nd ACM Workshop on Mobility Management and Wireless Access (MobiWAC), ACM, Chania, Crete, Oct 2007. ISBN: 978-1-59593-809-1
[ABH07b] Atkinson、R.、Bhatti、S。、およびS. Hailes、「マルチホーミング、NAT、およびセキュリティでモビリティを統合するための提案」、モビリティ管理およびワイヤレスアクセスに関する第2 ACMワークショップの議事録（MobiWAC）、 ACM、ハニア、クレタ島、2007年10月。ISBN：978-1-59593-809-1
[ABH08a] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through Naming: Impact on DNS", Proceedings of 3rd ACM Workshop on Mobility in the Evolving Internet Architecture (MobiArch), ACM SIGCOMM, Seattle, WA, USA. Aug 2008.
[ABH08a] Atkinson、R.、Bhatti、S.、and S. Hailes、 "Mobility Through Naming：Impact on DNS"、Proceedings of 3rd ACM Workshop on Mobility in Mobility in the Evolving Internet Architecture（MobiArch）、ACM SIGCOMM、Seattle、WA 、 米国。 2008年8月。
[ABH08b] Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised Resilience, Security, and Mobility Capability for IP", Proceedings of the IEEE Military Communications Conference (MILCOM), IEEE, San Diego, CA, USA, Nov 2008.
[ABH08b] Atkinson、R.、Bhatti、S.、and S. Hailes、 "Harmonized Resilience、Security、and Mobility Capability for IP"、Proceedings of the IEEE Military Communications Conference（MILCOM）、IEEE、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 Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009.
[ABH09a] Atkinson、R、Bhatti、S。、およびS. Hailes、「IPのサイト制御の安全なマルチホーミングおよびトラフィックエンジニアリング」、IEEE軍事通信会議（MILCOM）の議事録、IEEE、ボストン、MA、USA、 2009年10月。
[ABH09b] Atkinson, R., Bhatti, S., and S. Hailes, "ILNP: Mobility, Multi-Homing, Localised Addressing and Security Through Naming"", Telecommunication Systems", vol. 42, no. 3-4, pp 273-291, Springer-Verlag, Dec 2009.
[ABH09b] Atkinson、R.、Bhatti、S.、and S. Hailes、 "ILNP：Mobility、Multi-Homing、Localized Addressing and Security Through Naming" "、Telecommunication Systems"、vol。 42、いいえ。 3-4、pp 273-291、Springer-Verlag、2009年12月。
[ABH10] Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the Internet Architecture Through Naming", IEEE Journal on Selected Areas in Communication (JSAC), vol. 28, no. 8, pp 1319-1325, IEEE, Oct 2010.
[ABH10] Atkinson、R.、Bhatti、S.、and S. Hailes、 "Evolving the Internet Architecture through Naming"、IEEE Journal on Selected Areas in Communication（JSAC）、vol。 28、いいえ。 8、pp 1319-1325、IEEE、Oct 2010。
[appDNS] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", Work in Progress, July 2012.
[appDNS] Peterson、J.、Kolkman、O.、Tschofenig、H。、およびB. Aboba、「DNSのアプリケーション機能に関するアーキテクチャ上の考慮事項」、Work in Progress、2012年7月。
[BA11] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proceedings of IEEE Global Internet Symposium (GI2011), Shanghai, P.R. China, 15 Apr 2011.
[BA11] Bhatti、S.およびR. Atkinson、「Reducing DNS Caching」、Proceedings of IEEE Global Internet Symposium（GI2011）、上海、PR中国、15 Apr 2011。
[BA12] Bhatti, S. and R. Atkinson, "Secure & Agile Wide-area Virtual Machine Mobility", Proceedings of IEEE Military Communications Conference (MILCOM), Orlando, FL, USA, Oct 2012.
[BA12] Bhatti、S。およびR. Atkinson、「Secure＆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), IEEE, Baltimore, MD, USA, Nov 2011.
[BAK11] Bhatti、S.、Atkinson、R。、およびJ. Klemets、「Integrating Challenged Networks」、Proceedings of IEEE Military Communications Conference（MILCOM）、IEEE、Baltimore、MD、USA、2011年11月。
[BRDP11] Boot, T. and A. Holtzer, "BRDP Framework", Work in Progress, January 2011.
[BRDP11] Boot、T。およびA. Holtzer、「BRDP Framework」、Work in Progress、2011年1月。
[DMS04] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the second-generation onion router", Proceedings of 13th USENIX Security Symposium, USENIX Association, San Diego, CA, USA, 2004.
[DMS04] Dingledine、R.、Mathewson、N。、およびP. Syverson、「Tor：第2世代オニオンルーター」、Proceedings of 13th USENIX Security Symposium、USENIX Association、San Diego、CA、USA、2004。
[IEEE04] "IEEE 802.1D - IEEE Standard for Local and Metropolitan Area Networks, Media Access Control (MAC) Bridges", IEEE Standards Association, New York, NY, USA, 9 June 2004. Print: ISBN 0-7381-3881-5 SH95213. PDF: ISBN 0-7381-3982-3 SS95213.
[IEEE04]「IEEE 802.1D-Local and Metropolitan Area Networks、Media Access Control（MAC）Bridges」、IEEE Standards Association、ニューヨーク、米国、米国、2004年6月9日。印刷：ISBN 0-7381-3881- 5 SH95213。 PDF：ISBN 0-7381-3982-3 SS95213。
[LABH06] Atkinson, R., Lad, M., Bhatti, S., and S. Hailes, "A Proposal for Coalition Networking in Dynamic Operational Environments", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Washington, DC, USA, Nov 2006.
[LABH06] Atkinson、R.、Lad、M.、Bhatti、S.、and S. Hailes、 "A Proposal for Coalition Networking in Dynamic Operational Environments"、Proceedings of IEEE Military Communications Conference（MILCOM）、IEEE、Washington、DC 、米国、2006年11月。
[mDNS11] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, December 2011.
[mDNS11] Cheshire、S.およびM. Krochmal、「Multicast DNS」、Work in Progress、2011年12月。
[RAB09] Rehunathan, D., Atkinson, R., and S. Bhatti, "Enabling Mobile Networks Through Secure Naming", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009.
[RAB09] Rehunathan、D.、Atkinson、R。、およびS. Bhatti、「安全なネーミングによるモバイルネットワークの実現」、IEEE軍事通信会議（MILCOM）の議事録、IEEE、ボストン、MA、USA、2009年10月。
[RB10] Rehunathan, D. and S. Bhatti, "A Comparative Assessment of Routing for Mobile Networks", Proceedings of 6th IEEE International Conference on Wireless and Mobile Computing Networking and Communications (WiMob), IEEE, Niagara Falls, ON, Canada, Oct 2010.
[RB10] Rehunathan、D。およびS. Bhatti、「モバイルネットワークのルーティングの比較評価」、第6回IEEE国際会議のワイヤレスおよびモバイルコンピューティングネットワーキングおよびコミュニケーション（WiMob）、IEEE、ナイアガラフォールズ、ON、カナダ、 2010年10月。
[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月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、2011年6月。
[RSG98] Reed, M., Syverson, P., and D. Goldschlag, "Anonymous Connections and Onion Routing", IEEE Journal on Selected Areas in Communications, Vol. 16, No. 4, IEEE, Piscataway, NJ, USA, May 1998.
[RSG98] Reed、M.、Syverson、P。、およびD. Goldschlag、「Anonymous Connections and Onion Routing」、IEEE Journal on Communications in Selected Areas、Vol。 16、No。4、IEEE、Piscataway、NJ、USA、1998年5月。
Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson, Robin Whittle, and John Wroclawski (in alphabetical order) provided review and feedback on earlier versions of this document. Steve Blake provided an especially thorough review of an early version of the entire ILNP document set, which was extremely helpful. We also wish to thank the anonymous reviewers of the various ILNP papers for their feedback.
スティーブブレイク、ステファンボルツマイヤー、モハメドブーカデール、ノエルチアッパ、ウェスジョージ、スティーブヘイルズ、ジョエルハルパーン、マークハンドラリー、フォルカーヒルト、ポールジャクマ、デヨンキム、トニーリー、ヤコフレクター、ブルースシンプソン、ロビンウィットル、ジョンブロツラフスキ（アルファベット順）このドキュメントの以前のバージョンのレビューとフィードバックを提供しました。 Steve Blakeは、ILNPドキュメントセット全体の初期バージョンの特に徹底的なレビューを提供しました。これは非常に役に立ちました。また、フィードバックをいただいたさまざまなILNP論文の匿名の査読者にも感謝します。
Roy Arends provided expert guidance on technical and procedural aspects of DNS issues.
Roy Arendsは、DNS問題の技術的および手続き的側面について専門家のガイダンスを提供しました。
Authors' Addresses
著者のアドレス
RJ Atkinson Consultant San Jose, CA 95125 USA
ＲＪ あｔきんそん こんすｌたんｔ さん じょせ、 か ９５１２５ うさ
EMail: rja.lists@gmail.com
SN Bhatti School of Computer Science University of St Andrews North Haugh, St Andrews Fife KY16 9SX Scotland, UK
SN Bhattiコンピュータサイエンススクールセントアンドリュース大学ノースハウ、セントアンドリュースファイフKY16 9SXスコットランド、英国
EMail: saleem@cs.st-andrews.ac.uk