Network Working Group G. Huston
Request for Comments: 4177 APNIC
Category: Informational September 2005
Architectural Approaches to Multi-homing for IPv6
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing.
このメモは、IPv6プロトコルスイートのマルチホーミング支援の建築側面の分析を提供します。この分析の目的は、マルチホーミングに種々の提案手法の分類のための分類を提供することです。また、研究のこのドメインの共通点を識別するために、また、マルチホーミングをサポートすることを意図している様々な建築の拡張のさらなる意味合いのいくつかの探査を許可することができますフレームワークを提供するために、この演習の目的です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Multi-Homing Space . . . . . . . . . . . . . . . . . . . . 5
4. Functional Goals and Considerations . . . . . . . . . . . . . 7
5. Approaches to Multi-Homing . . . . . . . . . . . . . . . . . . 7
5.1. Multi-Homing: Routing . . . . . . . . . . . . . . . . . 8
5.2. Multi-Homing: Mobility . . . . . . . . . . . . . . . . . 9
5.3. Multi-homing: Identity Considerations . . . . . . . . . 12
5.4. Multi-homing: Identity Protocol Element . . . . . . . . 14
5.5. Multi-homing: Modified Protocol Element . . . . . . . . 15
5.6. Modified Site-Exit and Host Behaviors . . . . . . . . . 16
6. Approaches to Endpoint Identity . . . . . . . . . . . . . . . 17
6.1. Endpoint Identity Structure . . . . . . . . . . . . . . 18
6.2. Persistent, Opportunistic, and Ephemeral Identities . . 20
6.3. Common Issues for Multi-Homing Approaches . . . . . . . 23
6.3.1. Triggering Locator Switches . . . . . . . . . . 23
6.3.2. Locator Selection . . . . . . . . . . . . . . . 26
6.3.3. Layering Identity . . . . . . . . . . . . . . . 27
6.3.4. Session Startup and Maintenance . . . . . . . . 29
6.3.5. Dynamic Capability Negotiation . . . . . . . . . 31
6.3.6. Identity Uniqueness and Stability . . . . . . . 31
7. Functional Decomposition of Multi-Homing Approaches . . . . . 32
7.1. Establishing Session State . . . . . . . . . . . . . . . 32
7.2. Re-homing Triggers . . . . . . . . . . . . . . . . . . . 33
7.3. Re-homing Locator Pair Selection . . . . . . . . . . . . 33
7.4. Locator Change . . . . . . . . . . . . . . . . . . . . . 34
7.5. Removal of Session State . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
10. Informative References . . . . . . . . . . . . . . . . . . . . 34
The objective of this analysis is to allow various technical proposals relating to the support of multi-homing environment in IPv6 to be placed within an architectural taxonomy. This is intended to allow these proposals to be classified and compared in a structured fashion. It is also an objective of this exercise to identify common aspects across all proposals within this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing. The scope of this study is limited to the IPv6 protocol suite architecture, although reference is made to IPv4 approaches as required.
この分析の目的は、IPv6でのマルチホーミング環境のサポートに関連する様々な技術提案が建築の分類内に配置できるようにすることです。これは、これらの提案は、構造化された方法で分類して比較できるようにするためのものです。また、研究のこのドメイン内のすべての提案に共通点を識別するために、また、マルチホーミングをサポートすることを意図している様々な建築の拡張のさらなる意味合いのいくつかの探査を許可することができますフレームワークを提供するために、この演習の目的です。参照がIPv4のために必要なアプローチがなされているが、本研究の範囲は、IPv6プロトコルスイートのアーキテクチャに制限されます。
Care-of Address (CoA) A unicast routeable address associated with a mobile node while visiting a foreign link; the subnet prefix of this IP address is a foreign subnet prefix. Among the multiple care-of addresses that a mobile node may have at any given time (e.g., with different subnet prefixes), the one registered with the mobile node's home agent for a given home address is called its "primary" care-of address.
気付アドレス（CoA）外部リンクを訪問している間、移動ノードに関連付けられたユニキャストルーティング可能アドレス。このIPアドレスのサブネットプレフィックスは、外国サブネットプレフィックスです。複数の気付アドレスモバイルノードが持っていることを、任意の時点で（例えば、異なるサブネットプレフィックス付き）、与えられたホームアドレスがその「プライマリー」気付アドレスと呼ばれているため、モバイルノードのホームエージェントに登録1のうち、 。
Correspondent Node (CN) A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary.
コレスポンデントノード（CN）は、移動ノードが通信しているピア・ノード。コレスポンデントノードは、モバイルまたは固定のいずれであってもよいです。
Endpoint A term for the identity for a network host. This is normally assumed to be a constant or long-lived association.
ネットワークホストのアイデンティティのための用語をエンドポイント。これは通常、定数や長寿命の関連を想定しています。
Endpoint Identity Protocol Stack Element (EIP) An added element in a protocol stack model that explicitly manages the association of locators to endpoints.
エンドポイントのアイデンティティプロトコルスタック要素（EIP）明示的にエンドポイントにロケータの関連付けを管理するプロトコルスタックモデルに追加された要素。
Home Address (HoA) A unicast routeable address assigned to a mobile node, used as the permanent address of the mobile node. This address is within the mobile node's home link. Standard IP routing mechanisms will deliver packets destined for a mobile node's home address to its home link. Mobile nodes can have multiple home addresses, for instance, when there are multiple home prefixes on the home link.
モバイルノードのパーマネントアドレスとして使用されるホーム・アドレス（HoA）モバイルノードに割り当てられたユニキャストルーティング可能アドレス。このアドレスは、モバイルノードのホームリンク内にあります。標準的なIPルーティングの仕組みは、そのホームリンクに移動ノードのホームアドレス宛のパケットを配信します。モバイルノードがホームリンク上の複数のホームプレフィックスがある場合、例えば、複数のホームアドレスを持つことができます。
Lower Layer Protocol (LLP) The lower-level protocol in the protocol stack model relative to the protocol layer being considered. In the Internet architecture, the LLP of the transport protocol is the Internet Protocol, and the LLP of the application protocol is the transport protocol.
下位レイヤプロトコル（LLP）プロトコル層にプロトコルスタックモデル相対的に低いレベルのプロトコルが検討されています。インターネットアーキテクチャでは、トランスポートプロトコルのLLPは、インターネットプロトコルであり、アプリケーションプロトコルのLLPは、トランスポートプロトコルです。
Locator The term "locator" is used as the location token for a network host. This is a network-level address that can be used as a destination field for IP packets.
用語「ロケータ」ロケーターネットワークホストの場所トークンとして使用されます。これは、IPパケットの宛先フィールドとして使用することができるネットワークレベルアドレスです。
Mobile Node A node that can change its point of attachment from one link to another, while still being reachable via its home address.
モバイルノードはまだそのホームアドレス経由で到達可能でありながら、別のリンクから接続点を変更することができますノード。
Multi-Homed Site A site with more than one transit provider. "Site multi-homing" is the practice of arranging a site to be multi-homed such that the site may use any of its transit providers for connectivity services.
マルチホームのサイトに複数のトランジットプロバイダとサイト。 「サイトマルチホーミングは」サイトは、接続サービスのためのトランジットプロバイダーのいずれかを使用することができるようにマルチホームであることをサイトを配置する方法です。
Re-homing The transition of a site between two states of connectedness, due to a change in the connectivity between the site and its transit providers.
再ホーミングサイトとそのトランジットプロバイダ間の接続性の変化によるつながりの二つの状態の間、サイトの移行を。
Site An entity autonomously operating a network using IP.
サイトアンエンティティは、自律的にIPを使用してネットワークを動作させます。
Site-Exit Router A boundary router of the site that provides the site's interface to one or more transit providers.
サイト出口ルータの一つ以上のトランジットプロバイダーへのサイトのインターフェースを提供し、サイトの境界ルータ。
Transit Provider A provider that operates a site that directly provides connectivity to the Internet to one or more external sites. The connectivity provided extends beyond the transit provider's own site. A transit provider's site is directly connected to the sites for which it provides transit.
トランジットプロバイダーに直接1つまたは複数の外部サイトへのインターネットへの接続性を提供し、サイトを運営するプロバイダ。提供される接続は、トランジットプロバイダ自身のサイトを越えて延びています。トランジットプロバイダーのサイトでは、それはトランジットを提供しているサイトに直接接続されています。
Upper Layer Protocol (ULP) The upper-level protocol in the protocol stack model relative to the protocol layer being considered. In the Internet architecture, the ULP of the Internet Protocol is the transport protocol, and the ULP of the transport protocol is the application protocol.
上位層プロトコル（ULP）プロトコル層にプロトコルスタックモデル相対的に上位プロトコルが検討されています。インターネットアーキテクチャでは、インターネットプロトコルのULPは、トランスポートプロトコルであり、トランスポートプロトコルのULPは、アプリケーションプロトコルです。
A simple formulation of the site multi-homing environment is indicated in Figure 1.
サイトマルチホーミング環境の単純な製剤は、図1に示されています。
+------+
|remote|
| host |
| R |
+------+
|
+ - - - - - - - - - - - +
| Internet Connectivity |
+ - - - - - - - - - - - +
/ \
+---------+ +---------+
| ISP A | | ISP B |
+---------+ +---------+
| Path A | Path B
+ - - - - - - - - - - - - - - - - - - - - +
| multi- | | |
homed +------+ +------+
| site | site-| | site-| |
| exit | | exit |
| |router| |router| |
| A | | B |
| +------+ +------+ |
| |
| local site connectivity |
|
| +-----------+ |
|multi-homed|
| | host | |
+-----------+
+ - - - - - - - - - - - - - - - - - - - - +
Figure 1: The Multi-Homed Domain
図1：マルチホームドメイン
The environment of multi-homing is intended to provide sufficient support to local hosts so as to allow local hosts to exchange IP packets with remote hosts, such that this exchange of packets is transparently supported across dynamic changes in connectivity. Session resilience implies that if a local multi-homed-aware host establishes an application session with the remote host using "Path
マルチホーミングの環境は、ローカルホストがパケットのこの交換は透過接続の動的変化を横切って支持されているように、リモート・ホストとIPパケットを交換することを可能にするようにローカルホストに十分な支持を提供することを目的とします。セッションの復元は、ローカルマルチホーム対応のホストは、リモートホストとアプリケーションセッションを確立している場合は、「パスを使用していることを意味します
A", and this path fails, the application session should be mapped across to "Path B" without requiring any application-visible re-establishment of the session. In other words, the application session should not be required to be explicitly aware of underlying path changes at the level of packet forwarding paths chosen by the network. Established sessions should survive dynamic changes in network-level reachability.
Aセッションの任意のアプリケーション可視再確立を必要とせずに、パスB 『」、およびこのパスに障害が発生した場合、アプリケーションセッションは、に渡ってマッピングされなければならない』。換言すれば、アプリケーションセッションは、基礎となるの明示的意識する必要れるべきではありませんパスは、ネットワークによって選択されたパケット転送パスのレベルに変化する。確立されたセッションは、ネットワークレベルの到達可能性の動的変化に耐えなければなりません。
There are also considerations of providing mechanisms to support sustained site visibility to support session establishment. Sustained site visibility implies that external attempts to initiate a communication with hosts within the site will succeed as long as there is at least one viable path between the external host and the multi-homed site. This also implies that local attempts to initiate a communication with remote hosts should take into account the current connectivity state in undertaking locator selection and setting up initial locator sets.
セッション確立をサポートするために、持続的なサイトの可視性をサポートするためのメカニズムを提供するの配慮もあります。持続サイトの可視性は、外部の試みは、外部ホストとマルチホームサイトとの間に少なくとも1つの実行可能な経路がある限り、成功するサイト内のホストとの通信を開始することを意味します。これは、リモートホストとの通信を開始するローカル試みがロケータの選択を行って初期ロケータセットを設定する際に考慮に現在の接続状態を取るべきであることを意味します。
In addition, there is the potential consideration of being able to distribute the total traffic load across a number of network paths according to some predetermined policy objective. This may be to achieve a form of traffic engineering, support for particular quality-of-service requirements, or localized load balancing across multiple viable links.
加えて、いくつかの所定のポリシーの目的に応じてネットワーク経路の数を横切る総トラフィック負荷を分散することができるという潜在的な考慮があります。これは、トラフィックエンジニアリング、複数の実行可能なリンクバランシング、特定のサービス品質要件、またはローカライズされた負荷のための支援の形を達成することであってもよいです。
This simple multi-homing scenario also includes "site-exit" routers, where the local site interfaces to the upstream Internet transit providers. The interactions between the external routing system and the site-exit routers, the interactions between the site-exit routers and the local multi-homed host, and the interactions between local connectivity forwarding and the local host and site exit routers are not defined a priori in this scenario, as they form part of the framework of interaction between the various multi-homing components.
この単純なマルチホーミングシナリオも上流のインターネットトランジットプロバイダーへのローカルサイトインタフェース「サイト終了」ルーターを、含まれています。外部のルーティングシステムとサイト出口ルーターとの間の相互作用は、サイト出口ルータとローカルマルチホームホスト、ローカル接続の転送とローカルホストとサイト出口ルーターとの間の相互作用の間の相互作用は、事前に定義されていませんこのシナリオでは、それらは様々なマルチホーミング構成要素間の相互作用の枠組みの一部を形成しています。
The major characteristic of this simple site multi-homing scenario is that the address space used by, and advertised as reachable by, ISP A is distinct from the address space used by ISP B.
この単純なサイトマルチホーミングシナリオの主要な特徴は、ことによって使用されるアドレス空間であり、ISP AがISP Bによって使用されるアドレス空間とは区別される、によって到達可能としてアドバタイズ
This simple scenario is intended to illustrate the basic multi-homing environment. Variations may include additional external providers of transit connectivity to the local site; complex site requirements and constraints, where the site may not interface uniformly to all external transit providers; sequential rather than simultaneous external transit reachability; communication with remote multi-homed hosts; multiway communications; use of host addresses in a referential context (third-party referrals); and the imposition of policy constraints on path selection. However, the basic simple site multi-homing scenario is sufficient to illustrate the major architectural aspects of support for multi-homing, so this simple scenario will be used as the reference model for this analysis.
この単純なシナリオは、基本的なマルチホーミング環境を説明することを意図しています。バリエーションは、ローカルサイトへのトランジット接続の追加の外部プロバイダを含むことができ;サイトはすべての外部トランジットプロバイダに均一にインタフェースしないことがあり、複雑なサイトの要件や制約、。むしろ同時外部トランジット到達可能性よりも、順次、リモートマルチホームホストとの通信。多方向コミュニケーション;参照コンテキスト（サードパーティの紹介）のホストアドレスの使用;パス選択に関する政策の制約を課します。しかし、基本的なシンプルなサイトマルチホーミングシナリオは、マルチホーミングのサポートの主要な建築局面を説明するのに十分であるので、この単純なシナリオでは、この分析のための参照モデルとして使用されます。
RFC 3582 [RFC3582] documents some goals that a multi-homing approach should attempt to address. These goals include:
RFC 3582 [RFC3582]はマルチホーミングアプローチが対処しようとしなければならないいくつかの目標を説明します。これらの目標は、次のとおりです。
* redundancy * load sharing * traffic engineering * policy constraints * simplicity of approach * transport-layer survivability * DNS compatibility * packet filtering capability * scaleability * legacy compatibility
*冗長*ロードシェアリング*トラフィックエンジニアリング*ポリシー制約*アプローチの簡潔*トランスポート層の存続* DNSの互換性*パケットフィルタリング機能*拡張性*レガシーとの互換性
The reader is referred to [RFC3582] for a complete description of each of these goals.
読者は、これらの目標のそれぞれの詳細については[RFC3582]と呼ばれます。
In addition, [thinks] documents further considerations for IPv6 multi-homing. Again, the reader is referred to this document for the detailed enumeration of these considerations. The general topic areas considered in this study include:
また、文書にIPv6のマルチホーミングのための更なる配慮を[思います]。再び、読者は、これらの考慮事項の詳細な列挙は、このドキュメントと呼ばれます。本研究で考慮一般的なトピック領域は、次のとおりです。
* interaction with routing systems, * aspects of a split between endpoint-identifier and forwarding locator, * changes to packets on the wire, and * the interaction between names, endpoints, and the DNS.
*ルーティングシステム、*エンドポイント識別子および転送ロケータとの間の分割の態様、*ワイヤ上のパケットへの変更、および*名、エンドポイント、およびDNSとの間の相互作用との相互作用。
In evaluating various approaches, further considerations also include:
様々なアプローチを評価するには、更なる検討事項も含まれます：
* the role of helpers and agents in the approach, * modifications to host behaviours, * the required trust model to support the interactions, and * the nature of potential vulnerabilities in the approach.
アプローチでのヘルパーとエージェントの役割*、*行動をホストするための修正、*必要な信頼の相互作用をサポートするためのモデル、および*アプローチにおける潜在的な脆弱性の性質。
There appear to be five generic forms of architectural approaches to this problem, namely:
つまり、この問題へのアプローチの建築の5つのジェネリックの形があるように表示されます。
Routing Use the IPv4 multi-homing approach
ルーティングIPv4を使用マルチホーミングアプローチ
Mobility Use the IPv6 Mobility approach
モビリティは、IPv6モビリティアプローチを使用します
New Protocol Element Insert a new element in the protocol stack that manages a persistent identity for the session
新しいプロトコル要素のセッションの永続的アイデンティティを管理プロトコルスタックの新しい要素を挿入します
Modify a Protocol Element Modify the transport or IP protocol stack element in the host in order to support dynamic changes to the forwarding locator
転送ロケータに動的な変更をサポートするために宿主に輸送またはIPプロトコルスタック要素を変更するプロトコル要素を変更
Modified Site-Exit Router/Local Host interaction Modify the site-exit router and local forwarding system to allow various behaviours including source-based forwarding, site-exit hand-offs, and address rewriting by site-exit routers
変更されたサイト出口ルータ/ローカルホストの相互作用は、ソースベースの転送など、さまざまな動作を可能にするために、サイト出口ルータとローカル転送システムを変更し、サイト出口ハンドオフ、およびアドレスは、サイト出口ルータによって書き換え
These approaches will be described in detail in the following sections.
これらのアプローチは、以下のセクションで詳細に説明します。
The approach used in IPv4 for multi-homing support is to preserve the semantics of the IPv4 address as both an endpoint identifier and a forwarding locator. For this to work in a multi-homing context, it is necessary for the transit ISPs to announce the local site's address prefix as a distinct routing entry in the inter-domain routing system. This approach could be used in an IPv6 context, and, as with IPv4, no modifications to the IPv6 architecture are required to support this approach.
マルチホーミング支援のIPv4で使用されるアプローチは、エンドポイント識別子と転送ロケータの両方としてIPv4アドレスのセマンティクスを保護することです。これはマルチホーミングコンテキストで動作するためには、トランジットISPがドメイン間ルーティングシステムにおける個別のルーティングエントリとしてローカルサイトのアドレスプレフィックスを発表するために必要です。このアプローチは、IPv4と同様に、IPv6のアーキテクチャへの修正は、このアプローチをサポートするために必要とされない、IPv6のコンテキストで使用することができました。
The local site's address prefix may be a more specific address prefix drawn from the address space advertised by one of the transit providers, or from some third-party provider not currently connected directly to the local site. Alternatively, the address space may be a distinct address block obtained by direct assignment from a Regional Internet Registry as Provider Independent space. Each host within the local site is uniquely addressed from the site's address prefix.
ローカルサイトのアドレスプレフィックスは、トランジットプロバイダーの一つ、または現在のローカルサイトに直接接続されていないいくつかのサードパーティのプロバイダからによってアドバタイズアドレス空間から引き出され、より具体的なアドレスプレフィックスかもしれません。あるいは、アドレス空間はプロバイダ独立空間として地域インターネットレジストリから直接代入して得られた異なるアドレス・ブロックであってもよいです。ローカルサイト内の各ホストを一意にサイトのアドレスプレフィックスからアドレス指定されています。
All transit providers for the site accept a prefix advertisement from the multi-homed site and advertise this prefix globally in the inter-domain routing table. When connectivity between the local site and an individual transit provider is lost, normal operation of the routing protocol will ensure that the routing advertisement corresponding to this particular path will be withdrawn from the routing system; those remote domains that had selected this path as the best available will select another candidate path as the best path. Upon restoration of the path, the path is re-advertised in the inter-domain routing system. Remote domains will undertake a further selection of the best path based on this re-advertised reachability information. Neither the local nor the remote host need to have multiple addresses or to undertake any form of address selection. The path chosen for forward and reverse direction path flows is a decision made by the routing system.
サイトのすべてのトランジットプロバイダーは、マルチホームのサイトからプレフィックス広告を受け入れ、ドメイン間ルーティングテーブルにグローバルこのプレフィックスを通知します。ローカルサイトおよび個々のトランジット・プロバイダとの間の接続が失われた場合、ルーティングプロトコルの通常の動作は、この特定の経路に対応する経路広告は、ルーティングシステムから引き出されることを保証します。利用可能な最善のように、このパスを選択したものをリモートドメインは最高のパスとして別の候補パスを選択します。パスの復旧時に、パスがドメイン間ルーティングシステムに再アドバタイズされます。リモートドメインは、この再公示到達可能性情報に基づいて最適なパスの選択をさらに実施します。どちらもローカルでもリモートホストが複数のアドレスを持っているか、アドレス選択の任意の形式に着手する必要はありません。順方向および逆方向経路に流れるために選択された経路は、ルーティングシステムによって行われた決定です。
This approach generally meets all the goals for multi-homing approaches with one notable exception: scaleability. Each site that multi-homes in this fashion adds a further entry in the global inter-domain routing table. Within the constraints of current routing and forwarding technologies, it is not clearly evident that this approach can scale to encompass a population of multi-homed sites of the order of, for example, 10**7 such sites. The implication here is that this would add a similar number of unique prefixes into the inter-domain routing environment, which in turn would add to the storage and computational load imposed on inter-domain routing elements within the network. This scale of additional load is not supportable within the current capabilities of the IPv4 global Internet, nor is it clear at present that the routing capabilities of the entire network could be expanded to manage this load in a cost-effective fashion, within the bounds of the current inter-domain routing protocol architecture.
スケーラビリティ：このアプローチは、一般的に、1つの注目すべき例外を除いて、マルチホーミングアプローチのためのすべての目標を満たしています。この方式でマルチ家はグローバルなドメイン間ルーティングテーブルにさらにエントリを追加する各サイト。現在のルーティングおよび転送技術の制約内で、このアプローチは、例えば、10の** 7ような部位のためのマルチホームサイトの集団を包含するように拡張できることは明らかではありません。ここでの意味は、これが今度はネットワーク内のドメイン間ルーティング要素に課せられたストレージと計算負荷に追加するドメイン間ルーティング環境へのユニークなプレフィックスの同様の番号を追加するだろうということです。追加の負荷のこのスケールは、IPv4グローバルなインターネットの現在の能力の範囲内サポート可能ではない、またそれは、ネットワーク全体のルーティング機能は、の範囲内で、費用対効果の高い方法で、この負荷を管理するために拡張できることを、現時点では明らかです現在のドメイン間ルーティングプロトコルアーキテクチャ。
One other goal, transport-layer surviveability, is potentially at risk in this approach. Dynamic changes within the network trigger the routing system to converge to a new stable distributed forwarding state. This process of convergence within the distributed routing system may include the network generating unstable transient forwarding paths, as well as taking an indeterminate time to complete. This in term may trigger upper-level protocol timeouts and possible session resets.
もう一つの目標は、トランスポート層surviveabilityは、このアプローチではリスクが潜在的にあります。ネットワーク内の動的な変更は、新しい安定した分散フォワーディング状態に収束するルーティングシステムをトリガします。分散型ルーティングシステム内の収束のこのプロセスは、不安定な過渡的な転送パスを生成、ならびに完了する不確定時間を割いてネットワークを含むことができます。この用語に上位プロトコルのタイムアウトおよび可能なセッションリセットをトリガすることができます。
Preserving established communications through movement is similar to preserving established communications through outages in multi-homed sites as both scenarios require the capability of dynamically changing the locators used during the communication while maintaining, unchanged, the endpoint identifier used by Upper Layer Protocol (ULP). Since MIPv6 protocol [RFC3775] already provides the required support to preserve established communications through movement, it seems worthwhile to explore whether it could also be used to provide session survivability in multi-homed environments.
両方のシナリオが動的に変化しない、上位層プロトコル（ULP）によって使用されるエンドポイント識別子を維持しながら通信中に使用されるロケータを変更する能力を必要とする運動を介して確立された通信を維持することは、マルチホームサイトに停止を通じて確立された通信を維持するに類似しています。 MIPv6のプロトコル[RFC3775]は既に移動により確立された通信を維持するために必要なサポートを提供するので、また、マルチホーム環境におけるセッションの存続を提供するために使用することができるかどうかを探索する価値があると思われます。
MIPv6 uses a preferred IP address, the Home Address (HoA), as a stable identifier for the mobile node (MN). This identifier is then dynamically mapped to a valid locator (Care-of Address, or CoA) that corresponds to the current attachment point within the network topology. When the MN is at the Home Network, the HoA is used both as locator and as identifier. When the MN is not at the Home Network, the HoA is used as an identifier, and the CoA is used as locator. A relaying agent (Home Agent) placed in the Home Network is used to forward packets addressed to the HoA to the current location, specified by the CoA. After each movement, the MN must inform its Home Agent of the new CoA and optionally inform those entities with which it has established communications (Correspondent Nodes, or CNs). The mapping between the HoA and the current CoA is conveyed using Binding Update (BU) messages.
MIPv6のは、モバイルノード（MN）のための安定的な識別子として、優先IPアドレス、ホームアドレス（HoA）を使用しています。この識別子は、次いで、動的にネットワーク・トポロジ内の現在のアタッチメントポイントに対応する有効なロケータ（気付アドレス、またはCOA）にマッピングされます。 MNは、ホームネットワークである場合には、HoAがロケータとして識別子としても使用されています。 MNは、ホームネットワークにない場合は、HoAが識別子として使用され、CoAがロケータとして使用されています。ホームネットワークに配置された中継エージェント（ホームエージェント）はCoAをで指定された、現在の位置にのHoA宛のパケットを転送するために使用されます。各運動の後、MNは、新たなCoAをそのホームエージェントに通知し、必要に応じて、通信を確立したこれらのエンティティ（対応ノード、またはCNS）に通知しなければなりません。 HoAと現在のCoAとの間のマッピングは、バインディングアップデート（BU）メッセージを用いて搬送されます。
When the BU message is exchanged between the MN and the Home Agent, it is possible to assume the existence of a pre-established Security Association that can be used to protect the binding information. However, when the BU message is exchanged between the MN and the CN, it is not possible to assume the existence of such a Security Association. In this case, it is necessary to adopt an alternative mechanism to protect the binding information contained in the message. The selected mechanism is called the Return Routeability procedure, and the background for its design is detailed in [rosec]. The goal of the mechanism is to allow the CN to verify that the MN that is claiming that an HoA is currently located at a CoA is entitled to make such claim; this essentially means that the HoA was assigned to the MN, and that the MN is currently located at the CoA. In order to verify these updates, the CN sends two different secrets, one to the claimed HoA and another one to the claimed CoA. If the MN receives both secrets, this means that the Home Agent located at the Home Network has a trust relationship with the MN, that it has forwarded the secret sent to the HoA, and that the MN is receiving packets sent to the CoA. By including authorisation information derived from both secrets within the BU message, the MN will be able to prove to the CN that the claimed binding between the HoA and the CoA is valid.
BUメッセージはMNとホームエージェント間で交換される場合は、バインディング情報を保護するために使用することができます事前に確立されたセキュリティアソシエーションの存在を仮定することが可能です。 BUメッセージはMNとCN間で交換されたときしかし、このようなセキュリティアソシエーションの存在を前提とすることはできません。この場合には、メッセージに含まれているバインディング情報を保護するための別の機構を採用する必要があります。選択された機構は、戻りルート機能プロシージャと呼ばれ、その設計のための背景[rosec]に詳述されています。メカニズムの目標は、CNがHoAでは、現在のCoAに位置していることを主張しているMNは、このような請求をする権利があることを確認できるようにすることです。これは、基本的にホアMNに割り当てられ、MNが現在のCoAに位置していることをされたことを意味しています。これらの更新を確認するために、CNは、二つの異なる秘密、特許請求のHoAに1および特許請求のCoAに別のものを送信します。 MNは、両方の秘密を受信した場合、これは、ホームネットワークにあるホームエージェントは、それがのHoAに送信された秘密情報を転送したこと、およびMNはCoAのに送信されたパケットを受信していることを、MNとの信頼関係を有することを意味します。 BUメッセージ内の両方の秘密由来承認情報を含めることにより、MNは、特許請求のHoAとCoA間のバインディングが有効であることをCNに証明することができるようになります。
The lifetime of the binding that is created in the CN using authorisation information obtained through the Return Routeability procedure is limited to 7 minutes, in order to prevent time-shifted attacks [rosec]. In a time-shifted attack, an attacker located along the path between the CN and the MN forges the Return Routeability packet exchange. The result of such an attack is that the CN will forward all the traffic addressed to the HoA to the CoA selected by the attacker. The attacker can then leave the position along the path, but the effects of the attack will remain until the binding is deleted, shifting in time the effect of the attack. By limiting the lifetime of the binding in the CN, the effect of this attack is reduced to 7 minutes, because after that period a new Return Routeability procedure is needed to extend the binding lifetime. It should be noted that the Return Routeability procedure is vulnerable to "man-in-the-middle" attacks, since an attacker located along the path between the CN and the MN can forge the periodic Return Routeability packet exchange.
それはリターンルート機能の手順を経て得られた認証情報を使用してCNに作成された結合の寿命は、タイムシフト攻撃[rosec]を防止するために、7分に制限されています。タイムシフト攻撃では、CNとMN間の経路に沿って配置攻撃者がリターンルート機能パケット交換を偽造します。このような攻撃の結果は、CNは、すべてのトラフィックは、攻撃者が選択したのCoAへのHoA宛に転送するということです。攻撃者は、パスに沿った位置のままにすることができるが、攻撃の影響は、時間的に攻撃の効果をずらし、結合が削除されるまで残ります。その期間の後に、新たなリターンルート機能の手順が結合寿命を延長するために必要とされるので、CNにおける結合の寿命を制限することにより、この攻撃の影響は、7分に短縮されます。 CNとMN間の経路に沿って配置、攻撃者が定期的なリターンルート機能パケット交換を偽造することができますので、戻りルート機能の手順は、「のman-in-the-middle」攻撃に対して脆弱であることに留意すべきです。
The possible application of the MIPv6 protocol to the multi-homing problem would be to use BU messages to convey information in advance about alternative addresses that could be used following an outage in the path associated with the currently used address.
マルチホーミング問題へのMIPv6プロトコルの可能な用途は、現在使用されているアドレスに関連付けられたパスで停電後に使用することができる別のアドレスを事前に情報を伝えるためにBUメッセージを使用することであろう。
In this scenario, the multi-homed host adopts the MN role and the host outside the multi-homed site adopts the CN role. When a communication is established between the multi-homed host and the external host, the address used for initiating the communication is used as an HoA. The communication continues using this address as long as no outage occurs. If an outage occurs and the HoA becomes unreachable, an alternative address of the multi-homed node is used as a CoA. In this case, the multi-homed node sends a BU message to the external host, informing it about the new CoA to be used for the HoA, so that the established communication can be preserved using the alternative address. However, such a BU message has to be validated using authorisation information obtained through the Return Routeability procedure, which implies that the binding lifetime will be limited to a fixed period of no more than 7 minutes. The result is that the binding between the HoA and the new CoA will expire after this interval has elapsed, and then the HoA will be used for the communication. Since the HoA is unreachable because of the outage, the communication will be interrupted. It should be noted that it is not possible to acquire new authorisation information by performing a new Return Routeability procedure, because it requires communication through the HoA, which is no longer reachable. Consequently, a mechanism based on the MIPv6 BU messages to convey information about alternative addresses will preserve communications only for 7 minutes.
このシナリオでは、マルチホームホストは、MNの役割を採用し、マルチホームのサイト外のホストは、CNの役割を採用しています。通信は、マルチホームホストと外部ホストとの間で確立されると、通信を開始するために使用されるアドレスがHoAをとして使用されます。通信は限り何の障害が発生していないとして、このアドレスを使用し続けています。停電が発生したHoAが到達不能になった場合、マルチホームノードの代替アドレスがCoAとして使用されます。この場合には、マルチホームノードは、確立された通信は、代替アドレスを用いて保存することができるように、HoAをするために使用される新たなCoAについてそれを知らせる、外部ホストにBUメッセージを送信します。しかしながら、そのようなBUメッセージがバインディング寿命がせいぜい7分の一定期間に限定することを意味戻りルート機能の手順を経て得られた認証情報を使用して検証されなければなりません。結果は、この間隔が経過した後のHoAと新たなCoAとの間の結合が期限切れになり、その後のHoAが通信に使用されることです。 HoAとが原因で停電の到達不能であるので、通信が中断されます。もはや到達可能であるHoAと、を介して通信を必要とするため、新しいリターンルート機能の手順を実行して、新しい認証情報を取得することができないことに留意すべきです。そのため、代替アドレスに関する情報を伝えるためにMIPv6のBUメッセージに基づくメカニズムはわずか7分間の通信を保持します。
The aspect of MIPv6 that appears to present issues in the context of multi-homing is the Return Routeability procedure. In MIPv6, identity validity is periodically tested by return routeability of the identity address. This regular use of a distinguished locator as the identity token cannot support return reachability in the multi-homing context, in the event of extended failure of the path that is associated with the identity locator.
マルチホーミングの文脈で問題を提示するように見えるのMIPv6の側面は、リターンルート機能の手順です。 MIPv6のでは、アイデンティティの有効性は、定期的アイデンティティアドレスのリターンルート機能によってテストされます。アイデンティティ・トークンとして区別ロケータのこの規則的な使用は、アイデンティティ・ロケータに関連付けられているパスの拡張障害が発生した場合に、マルチホーミングコンテキストに戻り、到達可能性をサポートすることができません。
The intent of multi-homing in the IPv6 domain is to achieve an outcome that is comparable to that of multi-homed IPv4 sites using routing to support multi-homing, without an associated additional load being imposed on the IPv6 routing system. The overall intent of IPv6 is to provide a scalable protocol framework to support the deployment of communications services for an extended period of time, and this implies that the scaling properties of the deployment environment remain tractable within projections of size of deployment and underlying technology capabilities. Within the inter-domain routing space, the basic approach used in IPv4 and IPv6 is to attempt to align address deployment with network topology, so that address aggregation can be used to create a structured hierarchy of the routing space.
IPv6ドメインにおけるマルチホーミングの目的は、IPv6ルーティングシステムに課されている関連する追加の負荷なしに、マルチホーミングを支援するために、ルーティングを使用して、マルチホームのIPv4サイトに匹敵する結果を達成することです。 IPv6の全体の目的は、長時間の通信サービスの展開をサポートするためのスケーラブルなプロトコルフレームワークを提供することであり、これは、展開環境のスケーリング特性を展開し、基礎となる技術能力の大きさの投影内に扱いやすいままであることを意味します。ドメイン間ルーティング空間内、IPv4とIPv6で使用される基本的なアプローチは、アドレス集約ルーティング空間の構造化階層を作成するために使用することができるように、ネットワークトポロジとアドレス展開を整列しようとすることです。
Within this constraint of topological-based address deployment and provider-aggregateable addressing architectures, the local site that is connected to multiple providers is delegated addresses from each of these providers' address blocks. In the example network in Figure 1, the local multi-homed host will conceivably be addressed in two ways: one using transit provider A's address prefix and the other using transit provider B's address prefix.
トポロジカルベースのアドレス展開とプロバイダaggregateableのアドレッシングアーキテクチャのこの制約の中で、複数のプロバイダに接続されているローカルサイトは、これらのプロバイダのアドレスブロックのそれぞれからアドレスを委任されます。図1の例のネットワークでは、ローカルマルチホームホストは、おそらく二つの方法で対処されますいずれかを使用して、トランジット・プロバイダAのアドレスプレフィックスおよび他の使用トランジット・プロバイダBのアドレスプレフィックス。
If remote host R is to initiate a communication with the local multi-homed host, it would normally query the DNS for an address for the local host. In this context, the DNS would return two addresses. one using the A prefix and the other using the B prefix. The remote host would select one of these addresses and send a packet to this destination address. This would direct the packet to the local host along a path through A or B, depending on the selected address. If the path between the local site and the transit provider fails, then the address prefix announced by the transit provider to the inter-domain routing system will continue to be the provider's address prefix. The remote host will not see any change in routing, yet packets sent to the local host will now fail to be delivered. The question posed by the multi-homing problem is: "If the remote host is aware of multi-homing, how could it switch over to using the equivalent address for the local multi-homed host that transits the other provider?"
リモートホストRは、ローカルマルチホームホストとの通信を開始する場合、それは通常、ローカルホストのアドレスをDNSに問い合わせることになります。この文脈では、DNSは、2つのアドレスを返します。 Bの接頭辞を使用してAのプレフィックスやその他を使用して1。リモートホストは、これらのアドレスのいずれかを選択し、この宛先アドレスにパケットを送信します。これは、選択されたアドレスに応じて、AまたはBを通る経路に沿ってローカルホストにパケットを導くだろう。ローカルサイトとトランジットプロバイダとの間のパスに障害が発生した場合は、ドメイン間ルーティングシステムへのトランジットプロバイダーによって発表されたアドレスプレフィックスは、プロバイダのアドレスプレフィックスであり続けるだろう。リモートホストは、ルーティングに変化は見られません、まだローカルホストに送信されたパケットは現在配信されるように失敗します。マルチホーミング問題によってもたらされる質問は：「リモートホストがマルチホーミングを認識している場合、どのようにそれは他のプロバイダを通過ローカルマルチホームホストのための同等のアドレスを使用するように切り替えることができます？」
If the local multi-homed host wishes to initiate a session with remote host R, it needs to send a packet to R with a valid source and destination address. While the destination address is that of R, what source address should the local host use? There are two implications for this choice. Firstly, the remote host will, by default use this source address as the destination address in its response, and hence this choice of source address will direct the reverse path from R to the local host. Secondly, ISPs A and B may be using some form of reverse unicast address filtering on source addresses of packets passed to the ISP, as a means of preventing source address spoofing. This implies that if the multi-homed address selects a source address from address prefix A, and the local routing to R selects a best path via ISP B, then ISP B's ingress filters will discard the packet.
ローカルマルチホームホストがリモートホストRとのセッションを開始することを希望する場合は、それが有効な送信元と送信先アドレスとRにパケットを送信する必要があります。宛先アドレスがRのことですが、ローカルホストは、どのようなソースアドレスを使用する必要がありますか？この選択のための2つの意味があります。まず、リモート・ホストは、デフォルトでその応答の宛先アドレスとして送信元アドレスが使用され、したがって、送信元アドレスのこの選択は、ローカルホストにRから逆の経路を指示します。第二に、ISPのA及びBは、送信元アドレスのスプーフィングを防止する手段として、ISPに渡されるパケットの送信元アドレスに逆ユニキャストアドレスフィルタリングのいくつかのフォームを使用してもよいです。これは、マルチホームアドレスがアドレスプレフィックスAから送信元アドレスを選択し、そしてRへのローカルルーティングはISP Bを介して最適なパスを選択した場合、その後、ISP Bの入口フィルタがパケットを破棄することを意味します。
Within this addressing structure there is no form of routing-based repair of certain network failures. If the link between the local site and ISP A fails, there is no change in the route advertisements made by ISP A to its external routing peers. Even though the multi-homed site continues to be reachable via ISP B, packets directed to the site using ISP A's prefix will be discarded by ISP A, as the destination is unreachable. The implication here is that, if the local host wishes to maintain a session across such events, it needs to communicate to remote host R that it is possible to switch to a destination address for the multi-homed host that is based on ISP B's address prefix. In the event that the local host wishes to initiate a session at this point, then it may need to use an initial source locator that reflects the situation that the only viable destination address to use is the one that is based on ISP B's address prefix. It may be the case that the local host is not aware of this return routeability constraint, or it may not be able to communicate this information directly to R, in which case R needs to discover or be passed this information in other ways.
このアドレッシング構造内の特定のネットワーク障害のルーティングベースの修復のno形式はありません。ローカルサイトとISP Aとの間のリンクに障害が発生した場合、その外部ルーティングピアにISP Aによって行われたルートアドバタイズメントに変化はありません。マルチホームサイトはISP Bを介して到達可能であり続けているにもかかわらず、宛先が到達不能であるように、ISP Aの接頭辞を使用してサイトに向けられたパケットは、ISP Aによって廃棄されるであろう。ここでの意味は、ローカルホストは、イベント間でセッションを維持したい場合、ISP Bのアドレスに基づいているマルチホームホストの宛先アドレスに切り替えることが可能であることをリモートホストRに通信する必要がある、ということです接頭辞。ローカルホストは、この時点でセッションを開始することを希望する場合には、それが使用する唯一の実行可能な宛先アドレスがISP Bのアドレスプレフィックスに基づいているものであるという状況を反映した最初のソース・ロケータを使用する必要があります。これは、ローカルホストは、この戻りルート機能の制約を認識していない場合であってもよいし、Rは、発見したり、他の方法でこの情報を渡す必要がある場合には直接Rにこの情報を通信することができないかもしれません。
In an aggregated routing environment, multiple transit paths to a host imply multiple address prefixes for the host, where each possible transit path is identified by an address for the host. The implication of this constraint on multi-homing is that paths being passed to the local multi-homed site via transit provider ISP A must use a forwarding-level destination IP address drawn from ISP A's advertised address prefix set that maps to the multi-homed host. Equally, packets being passed via the transit of ISP B must use a destination address drawn from ISP B's address prefix set. The further implication here is that path selection (ISP A vs. ISP B transit for incoming packets) is an outcome of the process of selecting an address for the destination host.
集約ルーティング環境では、ホストへの複数の通過経路が可能な各中継パスがホストのアドレスによって識別されるホストのための複数のアドレスプレフィックスを意味します。マルチホーミングにこの制約の含意はトランジットプロバイダーISP Aを介してローカルマルチホームのサイトに渡されるパスはマルチホームにマップISP Aの広告を出してアドレスプレフィックスセットから引き出され、転送レベルの宛先IPアドレスを使用しなければならないということですホスト。同様に、ISP Bの通過を経由して渡されるパケットは、ISP Bのアドレスプレフィックスセットから引き出された宛先アドレスを使用する必要があります。ここでさらに含意は、経路選択（着信パケットのためのISP Bトランジット対ISP A）は、宛先ホストのアドレスを選択する処理の結果です。
The architectural consideration here is that, in the conventional IP protocol architecture, the assumption is made that the transport-layer endpoint identity is the same identity used by the internet forwarding layer, namely the IP address.
ここでアーキテクチャの考慮事項は、従来のIPプロトコルアーキテクチャにおいて、仮定は、トランスポート層エンドポイントIDがインターネット転送層、すなわちIPアドレスで使用されるのと同じIDがあると判断される、ということです。
If multiple forwarding paths are to be supported for a single transport session and if path selection is to be decoupled from the functions of transport session initiation and maintenance, then the corollary in architectural terms appears to be that some changes are required in the protocol architecture to decouple the concepts of identification of the endpoint and identification of the location and associated path selection for the endpoint. This is a fundamental change in the semantics of an IP address in the context of the role of the endpoint address within the end-to-end architectural model [e2e]. This change in the protocol architecture would permit a transport session to use an invariant endpoint identity value to initiate and maintain a session, while allowing the forwarding layer to dynamically change paths and associated endpoint locator identities without impacting on the operation of the session. Such a decoupling of the concepts of identities and locators would not add any incremental load to the inter-domain routing system.
複数の転送パスは、単一のトランスポートセッションのためにサポートされるべきであり、経路選択は、トランスポートセッションの開始および維持の機能から分離される場合、建築用語に帰結は、いくつかの変更をするためのプロトコルアーキテクチャにおいて必要とされることであると思われる場合エンドポイントのエンドポイントと位置の同定および関連する経路選択の識別の概念を切り離します。これは、エンドツーエンドアーキテクチャモデル[E2E]内のエンドポイントアドレスの役割の文脈におけるIPアドレスの意味論における根本的な変化です。転送レイヤを動的セッションの操作に影響を与えることなく経路と関連したエンドポイントロケータIDを変更することを可能にしながら、プロトコルアーキテクチャにおけるこの変化は、セッションを開始し、維持するために、不変のエンドポイントID値を使用するトランスポートセッションを可能にします。アイデンティティとロケータの概念のようなデカップリングは、ドメイン間ルーティングシステムに任意の増分ロードを追加しないでしょう。
Some generic approaches to this form of separation of endpoint identity and locator value are described in the following sections.
エンドポイントのアイデンティティとロケータ値の分離は、このフォームにいくつかの一般的なアプローチは、以下のセクションで説明されています。
One approach to this objective is to add a new element into the model of the protocol stack.
この目標への一つのアプローチは、プロトコルスタックのモデルに新しい要素を追加することです。
The presentation to the upper-level protocol stack element (ULP) would be endpoint identifiers to uniquely identify both the local stack and the remote stack. This will provide the ULP with stable identifiers for the duration of the ULP session.
上位プロトコルスタック要素（ULP）への提示は、エンドポイント識別子が一意ローカルスタックおよびリモートスタックの両方を識別することであろう。これは、ULPセッションの間、安定した識別子とULPを提供します。
The presentation to the lower-level protocol stack element (LLP) would be of the form of a locator. This implies that the protocol stack element would need to maintain a mapping of endpoint identifier values to locator values. In a multi-homing context, one of the essential characteristics of this mapping is that it needs to be dynamic, in that environmental triggers should be able to trigger a change in mappings. This in turn would correspond to a change in the paths (forward and/or reverse) used by the endpoints to traverse the network. In this way, the ULP session is defined by a peering of endpoint identifiers that remain constant throughout the lifetime of the ULP session, while the locators may change to maintain end-to-end reachability for the session.
下位プロトコルスタック要素（LLP）への提示は、ロケータの形態であろう。これは、プロトコルスタック要素がロケータ値にエンドポイント識別子値のマッピングを維持する必要があることを意味します。マルチホーミングの文脈において、このマッピングの本質的な特徴の一つは、それがマッピングの変化を誘発することができなければならないという環境的トリガーで、動的である必要があるということです。これは、ネットワークを横断するためにエンドポイントが使用するパスの変化（フォワード及び/又はリバース）に対応します。ロケータは、セッションのエンドツーエンドの到達可能性を維持するために変更することができるしながらこのように、ULPセッションは、ULPセッションの寿命を通して一定のままエンドポイント識別子のピアリングによって定義されます。
The operation of the new protocol stack element (termed here the "endpoint identity protocol stack element", or EIP) will establish a synchronised state with its remote counterpart. This will allow the stack elements to exchange a set of locators that may be used within the context of the session. A change in the local binding between the current endpoint identity value and a locator will change the source locator value used in the forwarding-level packet header. The actions of the remote EIP upon receipt of this packet with the new locator is to recognise this locator as part of an existing session and, upon some trigger condition, to change its session view of the mapping of the remote endpoint identity to the corresponding locator and use this locator as the destination locator in subsequent packets passed to the LLP.
新しいプロトコルスタック要素（ここでは呼ばれる「エンドポイントのアイデンティティプロトコルスタック要素」、またはEIP）の操作は、リモートの相手との同期状態を確立します。これは、スタック要素は、セッションのコンテキスト内で使用することができるロケータのセットを交換することを可能にします。現在のエンドポイントのID値とロケータとの間の局所的結合の変化は、転送レベルのパケットヘッダに使用されるソースロケータ値を変更します。新しいロケータと、このパケットを受信すると、遠隔EIPのアクションは、対応するロケータにリモートエンドポイントのアイデンティティのマッピングのそのセッションビューを変更するには、いくつかのトリガ条件により、既存のセッションの一部として、このロケータを認識することですそしてLLPに渡された後続のパケットの宛先ロケータとしてこのロケータを使用します。
From the perspective of the IP protocol architecture, there are two possible locations to insert the EIP into the protocol stack.
IPプロトコルアーキテクチャの観点から、プロトコルスタックにEIPを挿入するための2つの可能な位置があります。
One possible location is at the upper level of the transport protocol. Here the application program interface (API) of the application-level protocols would interface to the EIP element, and use endpoint identifiers to refer to the remote entity. The EIP would pass locators to the API of the transport layer.
一つの可能な位置は、トランスポートプロトコルの上位レベルです。ここで、アプリケーションレベルのプロトコルのアプリケーション・プログラム・インターフェース（API）は、EIP要素にインターフェース、および遠隔エンティティを参照するためにエンドポイント識別子を使用するであろう。 EIPは、トランスポート層のAPIにロケータを渡します。
The second approach is to insert the EIP between the transport and internet protocol stack elements, so that the transport layer would function using endpoint identifiers and maintain a transport session using these endpoint identifiers. The IP or internetwork layer would function using locators, and the mapping from endpoint identifier to locator is undertaken within the EIP stack element.
第二のアプローチは、トランスポート層エンドポイント識別子を用いて機能し、これらのエンドポイント識別子を用いて、トランスポート・セッションを維持するように、輸送とインターネットプロトコルスタック要素間EIPを挿入することです。 IPまたはインターネットワーク層は、ロケータを使用して機能する、及びロケータにエンドポイント識別子からマッピングは、EIPスタック要素内で行われます。
As an alternative to insertion of a new protocol stack element into the protocol architecture, an existing protocol stack element could be modified to include the functionality performed by the EIP element. This modification could be undertaken within the transport protocol stack element or within the internet protocol stack element. The functional outcome from these modifications would be to create a mechanism to support the use of multiple locators within the context of single-endpoint-to-single-endpoint communication.
プロトコルアーキテクチャに新しいプロトコルスタック要素の挿入に代わるものとして、既存のプロトコルスタック要素は、EIP要素によって実行される機能を含むように修正することができます。この変更は、トランスポートプロトコルスタック要素内またはインターネット・プロトコル・スタックの要素内で行われることができました。これらの修飾の機能的結果は、単一のエンドポイント・ツー・シングル・エンドポイント通信のコンテキスト内で複数のロケータの使用をサポートするためのメカニズムを作成するであろう。
Within the transport layer, this functionality could be achieved, for example, by binding a set of locators to a single session and then communicating this locator set to the remote transport entity. This would allow the local transport entity to switch the mapping to a different locator for either the local endpoint or the remote endpoint, while maintaining the integrity of the ULP session.
トランスポート層内に、この機能は、例えば、単一のセッションにロケータのセットを結合した後、リモートトランスポートエンティティにこのロケータセットを通信することによって、達成することができます。 ULPセッションの完全性を維持しながら、これは、ローカル搬送エンティティは、ローカルエンドポイントまたはリモートエンドポイントのどちらかのために別のロケータへのマッピングを切り替えることができるようになります。
Within the IP level, this functionality could be supported by a form of dynamic rewriting of the packet header as it is processed by the protocol element. Incoming packets with the source and destination locators in the packet header are mapped to packets with the equivalent endpoint identifiers in both fields, and the reverse mapping is performed to outgoing packets passed from the transport layer. Mechanisms that support direct rewriting of the packet header are potential candidates in this approach. Other potential candidates are various forms of packet header transformations using encapsulation, where the original endpoint identifier packet header is preserved in the packet and an outer-level locator packet header is wrapped around the packet as it is passed through the internet protocol stack element.
それはプロトコル要素によって処理されるIPレベル内で、この機能はパケットヘッダの動的書き換えの形態によってサポートすることができます。パケットヘッダ内の送信元と宛先ロケータの着信パケットは、両方のフィールドに同等のエンドポイント識別子を持つパケットにマッピングされ、逆方向マッピングは、トランスポート層から渡された送信パケットに実行されます。パケットヘッダの直接書き換えをサポートするメカニズムは、このアプローチの潜在的な候補です。他の潜在的な候補は、元のエンドポイント識別子のパケットヘッダがパケット内に保存され、それがインターネット・プロトコル・スタック・エレメントを通過させるように、外側レベルロケータパケットヘッダがパケットの周りに巻かれているカプセル化を使用してパケットヘッダ変換の様々な形態です。
There are common issues in all these scenarios: what state is kept, which part of the protocol stack keeps this state, how state is maintained with additions and removals of locator bindings, and whether only one piece of code is aware of the endpoint/locator split or do multiple protocol elements have to be modified? For example, if the functionality is added at the internetworking (IP) layer, there is no context of an active transport session, so that removal of identity/locator state information for terminated sessions needs to be triggered by some additional mechanism from the transport layer to the internetworking layer.
一般的な問題は、これらすべてのシナリオであります。状態はロケータバインディングの追加と削除で維持されているか、この状態を維持しているプロトコルスタックの一部、保管、およびコードの唯一の1枚は、エンドポイント/ロケータを認識しているかどうかをされているものの状態分割または複数のプロトコル要素を変更する必要がありますか？機能がインターネットワーキング（IP）層に添加する場合に終了セッションのアイデンティティ/ロケータ状態情報の除去は、トランスポート層からのいくつかの追加のメカニズムによってトリガーされる必要があるように、例えば、能動輸送セッションのないコンテキストが、存在しませんインターネットワーキング層へ。
The above approaches all assume that the hosts are explicitly aware of the multi-homed environment and use modified protocol behaviour to support multi-homing functionality. A further approach to this objective is to split this functionality across a number of network elements and potentially perform packet header rewriting from a persistent endpoint identity value to a locator value at a remote point.
上記のアプローチはすべてのホストがマルチホーム環境の明示的に認識しているとマルチホーミング機能をサポートするために変更されたプロトコルの動作を使用することを前提としています。この目的のさらなるアプローチは、ネットワーク要素の数を横切ってこの機能を分割し、潜在的に遠隔地点におけるロケータ値に永続的なエンドポイントID値から書き換えパケットヘッダを実行することです。
One possible approach uses site-exit routers to perform some form of packet header manipulation as packets are passed from the local multi-homed site to a particular transit provider. The local site routing system will select the best path to a destination host based on the remote host's locator value. The local host will write its endpoint identity as the source address of the packet. When the packet reaches a site-exit router, the site-exit router will rewrite the source field of the packet to a corresponding locator that selects a reverse path through the same transit ISP when the locator is used as a destination locator by the remote host. In order to preserve session integrity, a corresponding reverse transformation must be undertaken on incoming packets: the destination locator has to be mapped back to the host's endpoint identifier. There are a number of considerations whether this is best performed at the site-exit router when the packet is passed into the site, or by the local host.
一つの可能なアプローチは、パケットが特定のトランジットプロバイダにローカルマルチホームサイトから渡されるパケットヘッダ操作のいくつかのフォームを実行するために、サイト出口ルータを使用します。ローカルサイトのルーティングシステムは、リモートホストのロケータ値に基づいて、宛先ホストへの最適なパスを選択します。ローカルホストは、パケットの送信元アドレスとして、そのエンドポイントのIDを書きます。パケットがサイト出口ルータに到達すると、サイト出口ルータは、ロケータがリモートホストが宛先ロケータとして使用される場合、同じトランジットISPを介して逆の経路を選択し、対応するロケータにパケットのソースフィールドを書き換えます。セッションの完全性を維持するために、対応する逆変換は、着信パケットに行われなければならない：宛先ロケータはバックホストのエンドポイント識別子にマッピングされなければなりません。パケットがサイトに渡され、またはローカルホストによってされたときに、これは最適なサイト出口ルータで実行されているかどうか検討事項がいくつかあります。
Packet header rewriting by remote network elements has a large number of associated security considerations. Any packet rewriting mechanism has to provide proper protection against the attacks described in [threats], in particular against redirection attacks.
リモートネットワーク要素によって書き換えパケットヘッダは、関連するセキュリティ問題の多くを有します。メカニズムを書き換える任意のパケットは、リダイレクション攻撃に対して特に、[脅威]で説明された攻撃に対する適切な保護を提供しなければなりません。
An alternative for packet header rewriting at the site-exit point is for the host to undertake the endpoint-to-locator mapping, using one of the approaches outlined above. The consideration here is that there is a significant deployment of unicast reverse-path filtering in Internet environments as a counter-measure to source address spoofing. Using the example in Figure 1, if a host selects a locator drawn from the ISP B address prefix and local routing directs that packet to site-exit router A, then a packet passed to ISP A would be discarded by such filters. Various approaches have been proposed to modify the behaviour of the site forwarding environment, all with the end effect that packets using a source locator drawn from the ISP B address prefix are passed to site-exit router B. These approaches include forms of source address routing and site-exit router hand-over mechanisms, as well as augmentation of the routing information between site-exit routers and local multi-homed hosts, so that the choice of locator by the local host for the remote host is consistent with the current local routing state for the local site to reach the remote host.
ホストは、上記で概説の方法のいずれかを使用して、エンドポイント・ツー・ロケータマッピングを実施するサイト出口点に書き換え、パケットヘッダのための代替です。ここでの考察は、送信元アドレススプーフィングに対抗措置として、インターネット環境でのユニキャストリバースパスフィルタリングの重要な展開があるということです。ホストはISP Bアドレスプレフィックスとローカル配線から引き出さロケータを選択サイト出口ルータAへのパケットを指示する場合、図1の例を用いて、次いでISP Aに渡されるパケットは、そのようなフィルタによって廃棄されるであろう。様々なアプローチは、すべてのこれらのアプローチは、ソースアドレスルーティングの形態を含むサイト出口ルータBに渡されるISP Bアドレスプレフィックスから引き出されたソース・ロケータを使用してパケット終了効果と、サイト転送環境の挙動を変更するために提案されていますサイト出口ルータハンドオーバーメカニズム、ならびにサイト出口ルータとローカルマルチホームホスト間のルーティング情報の増強を、リモート・ホストのローカルホストによってロケータの選択は、現在のローカルと一致するようにリモートホストに到達するために、ローカルサイトの状態をルーティングします。
Both the approach of the addition of an identity protocol element and the approach of modification of an existing protocol element assume some form of exchange of information that allows both parties to the communication to be aware of the other party's endpoint identity and the associated mapping to locators. There are a number of possible approaches for implementing this information exchange.
アイデンティティプロトコル要素と既存のプロトコル要素の変形のアプローチの添加のアプローチの両方は、通信の両当事者が他の当事者のエンドポイントアイデンティティとロケータに関連するマッピングを認識することを可能にする情報の交換の何らかの形をとります。この情報交換を実現するための可能な方法がいくつかあります。
The first such possible approach, termed here a "conventional" approach, encapsulates the protocol data unit (PDU) passed from the ULP with additional data elements that specifically refer to the function of the EIP. The compound data element is passed to the LLP as its PDU. The corresponding actions on receipt of a PDU from a LLP is to extract the fields of the data unit that correspond to the EIP function, and pass the remainder of the PDU to the ULP. The EIP operates in an "in-band" mode, communicating with its remote peer entity through additional information wrapped around the ULP PDU. This is equivalent to generic tunnelling approaches where the outer encapsulation of the transmitted packet contains location address information, while the next-level packet header contains information that is to be exposed and used at the location endpoints and, in this case, is identity information.
「従来の」アプローチここで呼ばれる最初のそのような可能なアプローチは、特異EIPの機能を参照して、追加のデータ要素とULPから渡されたプロトコルデータユニット（PDU）をカプセル化します。化合物データ要素は、そのPDUとしてLLPに渡されます。 LLPからPDUを受信すると、対応するアクションは、EIPの機能に対応するデータユニットのフィールドを抽出し、ULPのPDUの残りの部分を通過することです。 EIPはULP PDU巻き付け付加情報を通じてリモートピア・エンティティと通信する、「インバンド」モードで動作します。次のレベルのパケットヘッダは、この場合には、露出した位置のエンドポイントで使用する情報が含まれている識別情報であるが、これは、送信されたパケットの外側のカプセル化は、位置アドレス情報が含まれている一般的なトンネリングアプローチに相当します。
Another approach is to allow the EIP to communicate using a separate communications channel, where an EIP generates dedicated messages that are directed to its peer EIP, and it passes these PDUs to the LLP independently of the PDUs that are passed to the EIP from the
別のアプローチは、EIPは、EIPは、そのピアEIPに向けられた専用メッセージを生成する別個の通信チャネルを使用して通信できるようにすることであり、それは、独立してからEIPに渡されるPDUのLLPにこれらのPDUを渡します
ULP. This allows an EIP to exchange information and synchronise state with the remote EIP semi-independently of the ULP protocol exchange. As one part of the EIP function is to transform the ULP PDU to include locator information, there is an associated requirement to ensure that the EIP peering state remains synchronised to the exchange of ULP PDUs, so that the remote EIP can correctly recognise the locator-to-endpoint mapping for each active session.
ULP。これは、情報を交換し、半独立ULPプロトコル交換の遠隔EIPた状態を同期するためにEIPを可能にします。 EIPの機能の一部は、ロケータ情報を含むようにULP PDUを変換することであるように、遠隔EIPが正しくlocator-を認識できるようにEIPピアリング状態は、ULP PDUの交換に同期したままであることを保証するための関連要件があります各アクティブなセッションについてのエンドポイントのマッピング。
Another potential approach here is to allow the endpoint-to-locator mappings to be held by a third party. This model is already used for supporting the name-to-IP address mappings performed by the Domain Name System (DNS), where the mapping is obtained by reference to a third party, namely, a DNS resolver. A similar form of third-party mapping between endpoints and a locator set could be supported through the use of the DNS or a similar third party referential mechanism. Rather than have each party exchange endpoint-to-locator mappings, this approach would obtain this mapping as a result of a lookup for a DNS Endpoint-to-Locator set map contained as DNS Resource Records, for example.
ここでは別の潜在的なアプローチは、エンドポイント・ツー・ロケータのマッピングは、第三者が保有できるようにすることです。このモデルは既にマッピングが第三者、すなわち、DNSリゾルバを参照することによって得られたドメインネームシステム（DNS）によって実行される名前とIPアドレスのマッピングをサポートするために使用されます。エンドポイントとロケータセットとの間のサードパーティマッピングの同様の形態は、DNSまたは類似の第三者参照メカニズムの使用を介してサポートすることができます。各当事者交換エンドポイント・ツー・ロケーターのマッピングを持っているのではなく、このアプローチは、DNSのルックアップエンドポイント・ツー・ロケータの結果として、このマッピングを得るだろう例えば、DNSリソースレコードとして含まれているマップを設定します。
The previous section has used the term "endpoint identity" without examining what form this identity may take. A number of salient considerations regarding the structure and form of this identity should be enumerated within an architectural overview of this space.
前のセクションでは、このアイデンティティがかかる場合がありますどのような形を調べることなく、用語「エンドポイント同一性」を使用しています。このアイデンティティの構造や形状に関する顕著な検討事項の数は、この空間のアーキテクチャの概要の中に列挙されなければなりません。
One possible form of an identity is the use of identity tokens lifted from the underlying protocol's "address space". In other words an endpoint identity is a special case instance of an IPv6 protocol address. There are a number of advantages in using this form of endpoint identity, since the suite of IP protocols and associated applications already manipulates IP addresses. The essential difference in a domain that distinguishes between endpoint identity and locator is that the endpoint identity parts of the protocol would operate on those addresses that assume the role of endpoint identities, and the endpoint identity/locator mapping function would undertake a mapping from an endpoint "address" to a set of potential locator "addresses". It would also undertake a reverse mapping from a locator "address" to the distinguished endpoint identifier "address". The IP address space is hierarchically structured, permitting a suitably efficient mapping to be performed in both directions. The underlying semantics of addresses in the context of public networking includes the necessary considerations of global uniqueness of endpoint identity token values.
アイデンティティの一つの可能な形式は、基本的なプロトコルの「アドレス空間」から持ち上げアイデンティティ・トークンを使用することです。換言すれば、エンドポイント・アイデンティティは、IPv6プロトコルアドレスの特殊なケースのインスタンスです。 IPプロトコルおよび関連するアプリケーションのスイートは、すでにIPアドレスを操作するので、多くの利点は、エンドポイントのアイデンティティのこのフォームを使用してあります。エンドポイントのアイデンティティとロケータを区別し、ドメイン内の本質的な違いは、プロトコルのエンドポイントのアイデンティティパーツは、エンドポイント・アイデンティティの役割を想定し、それらのアドレスに動作する、およびエンドポイントのアイデンティティ/ロケータマッピング機能は、エンドポイントからのマッピングを行うだろうということです潜在的なロケータ「アドレス」のセットに「住所」。また、著名なエンドポイント識別子「アドレス」にロケータ「アドレス」からの逆マッピングを行うだろう。 IPアドレス空間は、階層的に両方向に実行される適切効率的なマッピングを可能に、構成されています。公共ネットワークのコンテキスト内のアドレスの根本的な意味は、エンドポイントのIDトークン値のグローバルな一意の必要な考慮事項が含まれています。
It is possible to take this approach further and allow the endpoint identifier to also be a valid locator. This would imply the existence of a "distinguished" or "home" locator, and other locators could be dynamically mapped to this initial locator peering as required. The drawback of this approach is that the endpoint identifier is now based on one of the transit provider's address prefixes, and a change of transit provider would necessarily require a change of endpoint identifier values within the multi-homed site.
さらに、このアプローチを取るとエンドポイント識別子は、有効なロケータことを可能にすることが可能です。これは、「区別」や「自宅」ロケータの存在を暗示する、および必要に応じて他のロケータを動的この初期ロケータピアリングにマッピングすることができます。このアプローチの欠点は、エンドポイント識別子は、現在のトランジットプロバイダーのアドレスプレフィックスのいずれかに基づいており、トランジットプロバイダの変化は、必ずしもマルチホームサイト内のエンドポイント識別子値の変更が必要になるということです。
An alternative approach for address-formatted identifiers is to use distinguished identity address values that are not part of the global unicast locator space, allowing applications and protocol elements to distinguish between endpoint identity values and locators based on address prefix value.
アドレス形式の識別子の別のアプローチは、アプリケーションとプロトコル要素は、アドレスプレフィックス値に基づいて、エンドポイントID値とロケータとを区別できるように、グローバルユニキャストロケータ空間の一部ではない区別同一のアドレス値を使用することです。
It is also possible to allow the endpoint identity and locator spaces to overlap, and to distinguish between the two realms by the context of usage rather than by a prefix comparison. However, this reuse of the locator token space for identity tokens has the potential to create the anomalous situation where a particular locator value is used as an identity value by a different endpoint. It is not clear that the identity and locator contexts can be clearly disambiguated in every case, which is a major drawback to this particular approach.
エンドポイントのアイデンティティとロケータ空間が重なるように、使用の文脈によってではなくプレフィックス比較することによって2つのレルム間で区別できるようにすることも可能です。しかし、アイデンティティトークンのためのロケータトークン空間のこの再利用は、特定のロケータ値を異なるエンドポイントによって識別値として使用される異常事態を作成する可能性を有します。アイデンティティとロケータの状況は明らかに、この特定のアプローチの主な欠点であるすべてのケースで明確化することが可能かどうかは明らかではありません。
If identity values are to be drawn from the protocol's address space, it would appear that the basic choice is to either draw these identity values from a different part of the address space or to use a distinguished or home address as both a locator and an identity. This latter option, that of using a locator as the basis of an endpoint identity on a locator, when coupled with a provider-aggregated address distribution architecture, leads to a multi-homed site using a provider-based address prefix as a common identity prefix. As with locator addresses in the context of a single-homed network, a change of provider connectivity implies a consequent renumbering of identity across the multi-homed site. If avoiding such forced renumbering is a goal here, there would be a preference in drawing identity tokens from a pool that is not aligned with network topology. This may point to a preference from this sector for using identity token values that are not drawn from the locator address space.
同一性値は、プロトコルのアドレス空間から引き出されることになっている場合、基本的な選択は、アドレス空間の異なる部分からこれらのID値を描画するためのいずれかまたはロケータとアイデンティティの両方として区別や自宅住所を使用することであるように思われます。この後者のオプションは、プロバイダ集約アドレス配布アーキテクチャに結合されたとき、ロケータ上のエンドポイント・アイデンティティを基準としてロケータを使用することは、共通のアイデンティティプレフィックスとしてプロバイダベースアドレスプレフィックスを使用してマルチホームサイトに導きます。単一のホームネットワークのコンテキストにおけるロケータアドレスと同様に、プロバイダの接続性の変化は、マルチホームサイト全体の同一性の結果としてリナンバリングを意味しています。こうした強制再番号付けを回避することがここでの目的である場合は、ネットワークトポロジーと整合していないプールからのIDトークンを描画で好みがあるだろう。これは、ロケータアドレス空間から描かれていないIDトークン値を使用するため、この部門からの好みを指すことがあります。
It is also feasible to use the fully qualified domain name (FQDN) as an endpoint identity, undertaking a similar mapping as described above, using the FQDN as the lookup "key". The implication is that there is no default "address" associated with the endpoint identifier, as the FQDN can be used in the context of session establishment and a DNS query can be used to establish a set of initial locators. Of course, it is also the case that there may not necessarily be a unique endpoint associated with a FQDN, and in such cases, if there were multiple locator addresses associated with the FQDN via DNS RRs, shifting between locators may imply directing the packet to a different endpoint where there is no knowledge of the active session on the original endpoint.
ルックアップ「キー」としてFQDNを使用して、上記と同様のマッピングに着手、エンドポイントのIDとして完全修飾ドメイン名（FQDN）を使用することも可能です。含意はFQDNは、セッション確立のコンテキストで使用することができ、DNSクエリが最初のロケータのセットを確立するために使用することができますよう、エンドポイントの識別子に関連付けられたデフォルトの「アドレス」は、存在しないということです。もちろん、それが必ずしもFQDNに関連付けられた一意のエンドポイントではないかもしれない、およびDNSのRRを介してFQDNに関連付けられた複数のロケータアドレスがあった場合、このような場合には、ロケータ間にシフトすることにパケットを向けることを意味するものでもよいことも同様です元のエンドポイント上のアクティブなセッションの知識がない別のエンドポイント。
The syntactic properties of these two different identity realms have obvious considerations in terms of the manner in which these identities may be used within PDUs.
これら二つの異なるアイデンティティレルムの構文プロパティは、これらのIDは、PDUの内で使用される方法の面で明らかな考慮事項があります。
It is also an option to consider a new structured identity space that is neither generated through the reuse of IPv6 address values nor drawn from the FQDN. Given that the address space would need to be structured to permit its use as a lookup key to obtain the corresponding locator set, the obvious question is what additional or altered characteristics would be used in such an endpoint identity space that would distinguish it from either of the above approaches?
また、IPv6アドレス値を再利用して生成もなく、FQDNから引き出さもされていない新しい構造化されたアイデンティティのスペースを考慮するためのオプションです。アドレス空間は、対応するロケータセットを得るために、検索キーとしての使用を許可するように構成する必要があるであろうことを考えると、明白な疑問は、追加または変更された特性は、のいずれかからそれを区別でしょう、このようなエンドポイントのアイデンティティスペースで使用されるものです上記のアプローチ？
Instead of structured tokens that double as lookup keys to obtain mappings from endpoint identities to locator sets, the alternative is to use an unstructured token space, where individual token values are drawn opportunistically for use within a multi-homed session context. If such unstructured tokens are used in a limited context, then the semantics of the endpoint identity are subtly changed. The endpoint identity is not a persistent alias or reference to the identity of the endpoint, but it is a means to allow the identity protocol element to confirm that two locators are part of the same mapped locator set for a remote endpoint. In this context, the unstructured opportunistic endpoint identifier values are used in determining locator equivalence rather than in some form of lookup function.
代わりにセットをロケータするエンドポイントのIDからのマッピングを得るために、検索キーを兼ねる構造化されたトークンの、選択肢は、個々のトークン値は日和見マルチホームセッションのコンテキスト内で使用するために描かれている構造化されていないトークンスペースを、使用することです。そのような構造化されていないトークンが制限されたコンテキストで使用されている場合は、エンドポイントのアイデンティティの意味が微妙に変更されます。エンドポイント・アイデンティティは、エンドポイントのアイデンティティへの永続的なエイリアスまたは参照しないが、アイデンティティプロトコル要素は、2つのロケータがリモートエンドポイントに設定された同じマッピングロケータの一部であることを確認することを可能にする手段です。この文脈において、構造化されていない日和見エンドポイント識別子の値は、ロケータの等価を決定するのではなく、ルックアップ機能のいくつかの形態で使用されます。
The considerations in the previous section highlight one of the major aspects of variance in the method of supporting a split between identity and location information.
前のセクションで考察はアイデンティティと位置情報との分割をサポートする方法のばらつきの主要な側面の1つのハイライト。
One form uses a persistent identity field, by which it is inferred that the same identity value is used in all contexts in which this form of identity is required, in support of concurrent sessions as well as sequential sessions. This form of identity is intended to remain constant over time and over changes in the underlying connectivity. It may also be the case that this identity is completely distinct from network topology, so that the same identity is used irrespective of the current connectivity and locator addressing used by the site and the host. In this case, the identity is persistent, and the identity value can be used as a reference to the endpoint stack. This supports multi-party referrals, where, if parties A and B establish a communication, B can pass A's identity to a third party C, who can then use this identity value to be the active party in establishing communication to A.
一の形態は、同時セッションのサポートだけでなく、連続的なセッションでは、同じID値はアイデンティティのこの形式が必要とされるすべてのコンテキストで使用されていることが推測されたことにより、永続的なアイデンティティーフィールドを、使用しています。アイデンティティのこの形式は、時間をかけて、基礎となる接続の変更の上に一定に維持することを意図しています。また、同じIDが現在の接続に関係なく使用され、ロケータがサイトとホストによって使用されるアドレス指定ように、このアイデンティティは、ネットワークトポロジーは完全に別個のものである場合であってもよいです。この場合、同一性は永続的であり、およびID値は、エンドポイント・スタックへの参照として使用することができます。パーティAとBが通信を確立する場合、これは、どこで、マルチパーティの紹介をサポートし、Bは、Aに通信を確立するには、アクティブパーティになるこのID値を使用することができ、第三者CにAのIDを渡すことができます
If persistent identifiers are to be used to initiate a session, then the identity is used as a lookup key to establish a set of locators that are associated with the identified endpoint. It is desirable that this lookup function be deterministic, reliable, robust, efficient, and trustable. The implication of this is that such identities must be uniquely assigned, and experience in identity systems points to a strong preference for a structured identity token space that has an internal hierarchy of token components. These identity properties have significant commonality with those of unicast addresses and domain names. The further implication here is that persistent structured identities also rely on the adoption of well-ordered distribution and management mechanisms to preserve their integrity and utility. Such mechanisms generally imply a significant overhead in terms of administrative tasks.
永続識別子がセッションを開始するために使用する場合は、その後、身元が特定のエンドポイントに関連付けられているロケータのセットを確立するために、検索キーとして使用されています。この検索機能は、決定論的信頼性、堅牢で、効率的、かつ信頼できることが望ましいです。これの意味は、そのような識別を一意に割り当てられなければならないということであり、同一のシステムでの経験は、トークンコンポーネントの内部階層を有する構造化されたアイデンティティトークン空間に対する強い選好を指します。これらのアイデンティティの特性は、ユニキャストアドレスとドメイン名のものと大きな共通点を持っています。ここで、さらに意味は永続的な構造化されたアイデンティティはまた、彼らの完全性と有用性を維持するために整然とした配布と管理のメカニズムの採用に依存しているということです。このようなメカニズムは、一般的な管理タスクの面で大きなオーバーヘッドを意味します。
As noted in the previous section, an alternative form of identity is an unstructured identity space, where specific values are drawn from the space opportunistically. In this case, the uniqueness of any particular identity value is not ensured. The use of such identities as a lookup key to establish locators is also altered, as the unstructured nature of the space has implications relating to the efficiency of the lookup, and the authenticity of the lookup is weakened due to the inability to assure uniqueness of the identity key value. A conservative approach to unstructured identities limits their scope of utility, such as per-session identity keys. In this scenario, the scope of the selected identity is limited to the parties that are communicating, and the scope is limited to the duration of the communication session. The implication of this limitation is that the identity is a session-level binding point to allow multiple locators to be bound to the session, and the identity cannot be used as a reference to an endpoint beyond the context of the session. Such opportunistic identities with explicitly limited scope do not require the adoption of any well-ordered mechanisms of token distribution and management.
前のセクションで述べたように、同一の別の形態は、特定の値は日和見空間から引き出される構造化されていない同一の空間です。この場合、いずれかの特定のID値の一意性が確保されていません。原因の一意性を保証することができないことに空間の構造化されていない性質が、ルックアップの効率に関連する意味を持つようにロケータを確立するための検索キー等のアイデンティティの使用はまた、変更され、ルックアップの真正性が弱くなりますアイデンティティーキーの値。構造化されていない同一の保守的なアプローチは、セッションごとの識別キーとして、ユーティリティのその範囲を制限します。このシナリオでは、選択されたアイデンティティの範囲が通信している当事者に制限され、その範囲は、通信セッションの期間に限定されます。この制限の意味は同一で複数のロケータがセッションに拘束されることを可能にするセッションレベルの結合点であり、同一セッションのコンテキストを越えたエンドポイントへの参照として使用することができないことです。明示的に限られた範囲でそのような日和見アイデンティティは、トークン配布と管理のいずれかの整然としたメカニズムの採用を必要としません。
Another form of identity is an ephemeral form, where a session identity is a shared state between the endpoints, established without the exchange of particular token values that take the role of identity keys. This could take the form of a defined locator set or the form of a session key derived from some set of shared attributes of the session, for example. In this situation, there is no form of reference to or use of an identifier as a means of initiating a session. The ephemeral identity value has a very limited role in terms of allowing each end to reliably determine the semantic equivalence of a set of locators within the context of membership of a particular session.
同一の別の形態は、セッションIDが同一キーの役割を担う特定のトークン値を交換することなく、確立されたエンドポイント間の共有状態である短命形態です。これは、定義されたロケータセットのフォームまたは例えばセッションの共有属性、いくつかのセットから派生したセッション鍵の形を取ることができます。この状況では、セッションを開始する手段としての参照または識別子の使用のno形式はありません。エフェメラルID値は、各端部が確実に特定のセッションのメンバーシップのコンテキスト内ロケータの組の意味論的等価性を決定することを可能にするという点で非常に限られた役割を有します。
The latter two forms of identity represent an approach to identity that minimises management overhead and provides mechanisms that are limited in scope to supporting session integrity. This implies that support for identity functions in other contexts and at other levels of the protocol stack, such as within referrals, within an application's data payload, or as a key to initiate a communication session with a remote endpoint, would need to be supported by some other identity function. Such per-session limited scope identities imply that the associated multi-homing approaches must use existing mechanisms for session startup, and the adoption of a session-based identity and associated locator switch agility becomes a negotiated session capability.
同一の後者の2つの形態が、管理オーバーヘッドを最小化し、セッションの整合性をサポートする範囲に限定されるメカニズムを提供するアイデンティティへのアプローチを表します。これは、アプリケーションのデータペイロード内、またはリモートエンドポイントとの通信セッションを開始するためのキーとして、他の状況において、そのような照会内のようなプロトコルスタックの他のレベルで識別機能のためのそのサポートを意味し、によってサポートされる必要がありますいくつかの他のID機能。このようなセッションごとの制限された範囲のアイデンティティは、関連するマルチホーミングアプローチはセッション起動のための既存のメカニズムを使用しなければならないことを意味するものであり、セッションベースのIDと関連付けられたロケータスイッチの俊敏性の採用が交渉されたセッション機能となります。
On the other hand, the use of a persistent identity as a session initiation key implies that identity is part of the established session state, and locator agility can be an associated attribute of the session rather than a subsequent negotiated capability. In a heterogeneous environment where such identity capability is not uniformly deployed, this would imply that if a session cannot be established with a split identity/locator binding, the application should be able to back off to a conventional session startup by mapping the identity to a specific locator value and initiating a session using such a value. The reason why the application may want to be aware of this distinction is that if the application wishes to use self-referential mechanisms within the application payload, it would appear to be appropriate to use an identity-based self-reference only in the context of a session where the remote party was aware of the semantic properties of this referential tag.
一方、セッション開始キーとしての永続的アイデンティティの使用は、アイデンティティが確立されたセッション状態の一部であり、ロケータの俊敏性がセッションではなく、その後に交渉能力を関連する属性であることを意味します。こうしたアイデンティティ機能が均一に展開されていない異機種環境では、これはセッションが分割されたアイデンティティ/ロケータ結合を確立できない場合、アプリケーションはへのアイデンティティをマッピングすることにより、従来のセッションの起動にバックオフすることができなければならないことを暗示します特定のロケータ値と、このような値を使用してセッションを開始します。アプリケーションは、この区別を意識するとよいでしょう理由は、アプリケーションがアプリケーションペイロード内自己参照メカニズムを使用したい場合は、唯一のコンテキストでアイデンティティベースの自己参照を使用することが適切であるように思われるということです相手はこの参照タグの意味の特性を知っていたセッション。
In terms of functionality and semantics, opportunistic identities form a superset of ephemeral identities, although their implementation is significantly different. Persistent identities support a superset of the functionality of opportunistic identities, and again the implementations will differ.
その実装は大きく異なっているものの、機能性と意味論の観点では、日和見アイデンティティは、はかないアイデンティティのスーパーセットを形成します。永続的なアイデンティティは、日和見アイデンティティの機能のスーパーセットをサポートし、再び実装が異なります。
In the context of support for multi-homing configurations, use of ephemeral identities in the context of locator equivalence appears to represent a viable approach that allows a negotiated use of multiple locators within the context of communication between a pair of hosts in most contexts of multi-homing. However, ephemeral identities offer little more in terms of functionality. They cannot be used in referential contexts, cannot be used to initiate communications, provide limited means of support for various forms of mobility, and impose some constraints on the class of multi-homed scenarios that can be supported. Ephemeral identities are generated in the context of an established communication state, and the implication in terms of multi-homing is that the two end points need to have discovered through existing mechanisms a viable pair of locators prior to generating an ephemeral identity binding. The implication is that there is some form of static "home" for the end points that is discovered by conventional referential lookup.
マルチホーミング構成のサポートの文脈では、ロケータ等価の文脈における短命アイデンティティの使用は、複数のほとんどのコンテキスト内のホストのペア間の通信のコンテキスト内で複数のロケータのネゴシエートされた使用を可能にする実行可能なアプローチを表すように見えます-ホーミング。しかし、はかないアイデンティティは、機能性の面でもう少しを提供します。彼らが参照コンテキストで使用することができない、通信を開始モビリティの様々な形の支援の限られた手段を提供し、サポートすることができ、マルチホームシナリオのクラスにいくつかの制約を課すために使用することはできません。エフェメラルアイデンティティが確立された通信状態のコンテキストで生成され、マルチホーミングの点で意味は、二つのエンドポイントが前結合エフェメラルアイデンティティを生成するために、既存の機構を介してロケータの生存対を発見する必要があることです。含意は、従来の参照の検索によって発見されたエンドポイントの静的な「家」のいくつかのフォームがあるということです。
The use of a persistent identity space that supports dynamic translation between an equivalent set of locators and one or more equivalent identity values offers the potential for greater flexibility in applications. Depending on how the mapping between identities and locators is managed, this may extend beyond multi-homing configuration to various contexts of nomadism and mobility as well as service-specific functions. However, it remains an open question as to the nature of secure mapping mechanisms that would be needed in the more general context of identity-to-locator mapping, and it is also an open question as to how the mapping function would relate to viable endpoint-to-endpoint connectivity. It is a common aspect of identity realms that the most critical aspect of the realm is the nature of the resolution of the identity into some other attribute space.
同等のロケータのセットと1つ以上の同等の同一性の値の間の動的変換をサポートして永続的なアイデンティティスペースの使用は、アプリケーションの柔軟性の可能性を提供しています。アイデンティティとロケータとの間のマッピングの管理方法に応じて、これはマルチホーミング遊牧とモビリティのさまざまなコンテキストに設定だけでなく、サービス固有の機能を超えて延長することができます。しかし、それはアイデンティティ・ツー・ロケータマッピングのより一般的な状況で必要とされるであろう安全なマッピングメカニズムの性質として、未解決の問題が残っており、それがマッピング機能を実行可能なエンドポイントに関連するだろうかととしても未解決の問題です-to-エンドポイントの接続。これは、レルムの最も重要な側面は、他のいくつかの属性空間へのアイデンティティの解像度の性質であるアイデンティティレルムの一般的な側面です。
It appears reasonable to observe that, within certain constraints, multi-homing does not generically require the overhead of a fully distinct persistent identity space and the associated identity resolution functionality, and, if the nature of the multi-homing space in this context is to use a token to allow efficient detection of locator equivalence for session surviveability, then ephemeral identities appear to be an adequate mechanism.
この文脈でのマルチホーミング空間の性質がにある場合、マルチホーミングは、一般的に、完全に個別の永続的なアイデンティティスペースと関連したアイデンティティ解決機能のオーバーヘッドを必要としない一定の制約の中で、それを観察するのが妥当表示されますセッションsurviveabilityのロケータ同等の効率的な検出を可能にするためにトークンを使用し、その後、はかないアイデンティティは、適切なメカニズムであると思われます。
The above overview encompasses a very wide range of potential approaches to multi-homing, and each particular approach necessarily has an associated set of considerations regarding its applicability.
上記の概要は、マルチホーミングへの潜在的なアプローチの非常に広い範囲を包含し、そして各特定のアプローチは、必ずしもその適用に関する検討事項の関連するセットを有します。
There is, however, a set of considerations that appear to be common across all approaches. They are examined in further detail in this section.
すべてのアプローチに共通であるように思わ配慮のセットは、しかし、があります。彼らは、このセクションでさらに詳細に検討されています。
Ultimately, regardless of the method of generation, a packet generated from a local multi-homed host to a remote host must carry a source locator when it is passed into the transit network. In a multi-homed situation, the local multi-homed host has a number of self-referential locators that are equivalent aliases in almost every respect. The difference between locators is the inference that, at the remote end, the choice of locator may determine the path used to send a packet back to the local multi-homed host. The issue here is: how does the local host make a selection of the "best" source locator to use? Obviously, an objective is to select a locator that represents a currently viable path from the remote host to the local multi-homed host. Local routing information for the multi-homed host does not include this reverse path information. Equally, the local host does not necessarily know any additional policy constraints that apply to the remote host and that may result in a remote host's preference to use one locator over another for the local host. Considerations of unicast reverse-path forwarding filters also indicate that the selection of a source locator should result in the packet being passed to a site-exit router that is connected to the associated ISP transit provider, and that the site-exit router passes the packet to the associated ISP.
それはトランジットネットワークに渡されたとき、最終的に関係なく、生成方法の、リモート・ホストにローカルマルチホームホストから生成されたパケットは、ソース・ロケータを運ばなければなりません。マルチホームの状況では、ローカルマルチホームホストは、ほぼすべての点で同等の別名である自己参照ロケータの数を持っています。ロケータとの間の差は、リモートエンドで、ロケータの選択はバックローカルマルチホームホストにパケットを送信するために使用されるパスを決定してもよい、推論です。ここでの問題は、次のとおりです。どのようにローカルホストが使用することを「最高」のソースロケータの選択をしていますか？もちろん、目的は、ローカルマルチホームホストへのリモートホストから、現在実行可能なパスを表すロケータを選択することです。マルチホームホストのローカルルーティング情報は、この逆の経路情報が含まれていません。同様に、ローカルホストは、必ずしもリモートホストに適用される追加のポリシーの制約を知らないと、それは、ローカルホストのために別の上に1つのロケータを使用するには、リモートホストの好みになることがあります。ユニキャストリバースパス転送フィルタの考慮事項は、ソースロケータの選択は、関連するISPのトランジット・プロバイダに接続されているサイト出口ルータに渡されるパケットをもたらすはずであることを示し、およびサイト出口ルーターは、パケットを通過させること関連するISPへ。
If the local multi-homed host is communicating with a remote multi-homed host, the local host may have some discretion in the choice of a destination locator. The considerations relating to the selection of a destination locator include considerations of local routing state (to ensure that the chosen destination locator reflects a viable path to the remote endpoint) and policy constraints that may determine a "best" path to the remote endpoint. It may also be the case that the source address selection should be considered in relation to the destination locator selection.
ローカルマルチホームホストがリモートマルチホームホストと通信している場合は、ローカルホストが宛先ロケータの選択にいくつかの裁量権を有していても良いです。宛先ロケータの選択に関する考察はとリモートエンドポイントへの「最良」の経路を決定することができるポリシー制約（選択された宛先ロケータが実行可能なリモートエンドポイントへのパスを反映することを確実にするために）ローカルルーティング状態の考慮が含まれます。また、ソースアドレス選択が宛先ロケータの選択に関連して考慮されるべきである場合であってもよいです。
Another common issue is the point when a locator is not considered to be viable and the consequences to the transport session state.
もう1つの一般的な問題は、ロケータが実行可能であると考えられ、トランスポートセッション状態に影響されていない点です。
o Transport Layer Triggers
Oトランスポート層のトリガー
A change in state for a currently-used path to another path could be triggered by indications of packet loss along the current path by transport-level signalling or by transport session timeouts, assuming an internal signalling mechanism between the transport stack element and the locator pool management stack element.
別の経路に現用パスのための状態の変化は、トランスポートスタック要素とロケータプールとの間の内部のシグナリング機構を仮定すると、トランスポートレベルのシグナリングによって、またはトランスポートセッションタイムアウトによって電流経路に沿ってパケット損失の指示によってトリガすることができます管理スタック要素。
o ICMP Triggers
O ICMPトリガ
Path failure within the network may generate an ICMP Destination Unreachable packet being directed back to the sender. Rather than sending this signal to the transport level as an indicator of session failure, the IP layer should redirect the notification identity module as a trigger for a locator switch.
ネットワーク内のパスに障害が発生すると、送信者に向けられたICMP宛先到達不能パケットを生成してもよいです。むしろセッション障害の指標として輸送レベルにこの信号を送るよりも、IP層は、ロケータスイッチのトリガとして通知識別モジュールをリダイレクトすべきです。
o Routing Triggers
Oルーティングトリガ
Alternatively, in the absence of local transport triggers, the site-exit router could communicate failure of the outbound forwarding path in the case that the remote host is multi-homed with an associated locator set. Conventional routing would be incapable of detecting a failure in the inbound forwarding path, so there are some limitations in the approach of using routing triggers to change locator bindings.
あるいは、ローカル搬送トリガーの非存在下で、サイト出口ルータは、リモートホストが関連するロケータセットとマルチホームである場合には、発信転送パスの障害を通信することができます。従来のルーティングは、着信転送パスの障害を検出することができないであろうので、ルーティングは、ロケータ・バインディングを変更するためにトリガー使用のアプローチにいくつかの制限があります。
o Heartbeat Triggers
Oハートビートトリガ
An alternative to these approaches is the use of a session heartbeat protocol, where failure of the heartbeat would cause the session to seek a new locator binding that would reestablish the heartbeat.
これらのアプローチに代わるものは、ハートビートの失敗がセッションがハートビートを再確立することをバインディング新しいロケータを模索する原因となるセッションのハートビートプロトコルの使用です。
o Link Layer Triggers
Oリンク層のトリガ
Where supported, link layer triggers could be used as a direct and immediate signal of link availability, where a "Link Down" indication indicates the unavailability of a particular link [iab-link]. The limitation of this approach is that a link level indication is not a network broadcast event, and only the link's immediately-connected devices receive the link transition signal. While this approach may be relevant to the degenerate case of a multi-homed site composed of a single host, in the case of a multi-host site the link indication would need to be used by the site-exit router to generate one of the above indications for the host to be triggered for a locator change. In this case this is a conventional form of router detection of link status.
サポートされている場合、リンク層トリガは「リンクダウン」指示は、特定のリンク[IABリンク]が利用できないことを示すリンク可用性の直接的および即時信号として使用することができます。このアプローチの限界は、リンクレベルの指示はネットワーク放送イベントではなく、リンクのみのすぐ接続デバイスは、リンク遷移信号を受信することです。このアプローチは、単一のホストからなるマルチホームサイトの縮退ケースに関連するかもしれないが、マルチホストサイトの場合にはリンク指示のいずれかを生成するために、サイト出口ルータによって使用される必要がありますホストのための上記の適応症は、ロケータ変更のためにトリガされます。この場合には、これはリンク状態のルータ検出の従来の形態です。
The sensitivity of the locator switch trigger is a consideration here. A very fine-grained sensitivity of the locator switch trigger may generate false triggers arising from short-term transient path congestion, while coarse-grained triggers may impose an undue performance penalty on the session due to an extended time to detect a path failure. The objectives for sensitivity to triggers may be very different depending on the transport session being used. There is no doubt that any session would need a trigger to re-home if its path to the locator fails, but for some transports, moving, and triggering transport-related changes, may be far less desirable than reducing the sensitivity of the trigger and waiting to see if the triggering stimulus achieves a threshold level.
ロケータスイッチ引き金の感度は、ここで考慮すべき事項です。粗粒トリガーがパス障害を検出するためにより長時間にセッションに過度のパフォーマンスペナルティを課すかもしれないが、ロケータ・スイッチ・トリガの非常にきめ細かい感度は、短期一過パスの輻輳に起因する誤ったトリガを生成することができます。トリガーに対する感度のための目的は、使用中のトランスポートセッションに応じて非常に異なっていてもよいです。そこ任意のセッションは、ロケータへのパスに障害が発生した場合、家を直すためにトリガーを必要とする疑いがあるが、いくつかのトランスポート、移動、輸送関連の変更をトリガするため、トリガーの感度を下げるよりも、はるかに少ないことが望ましいかもしれないし、トリガー刺激が閾値レベルを達成した場合に見るために待っています。
This problem is only partly solved by models with an internal signalling mechanism between the transport stack element and the locator pool management stack element, because of non-failure triggers coming from other stacks, and because of transport issues such as use of resource reservation. As an example, consider the case of a session with reservations established by RSVP or NSIS, when a routing change has just caused adaptive updates to the reservation state in a number of elements along its path. The transport protocol using the path is likely to see some delays or timeouts, and its reaction to these events may be a trigger for a locator change, which is likely to mean another reservation update. This chaining of reservation updates may represent a high overhead. The implication here is that individual transport protocols may have to tune any feedback they give as a locator change trigger, so that they don't respond to certain forms of transient routing change delays (not knowing their cause) with a locator change trigger. It should also be noted that different transport protocols have rather different behaviors and hooks for management.
この問題は部分的にのみ理由非障害の、トランスポートスタック要素とロケータプール管理スタック要素との間の内部のシグナリング機構をモデルによって解決される他のスタックからのトリガ、およびので、このようなリソース予約の使用などの輸送の問題。一例として、ルーティングの変更がちょうどその経路に沿った要素の数に予約状態に適応更新が発生した場合に、RSVPまたはNSISによって確立された予約とのセッションの場合を考えます。パスを使用して、トランスポート・プロトコルは、いくつかの遅延またはタイムアウトを参照する可能性があり、そしてこれらのイベントへの反応は、他の予約更新を意味する可能性があるロケータ変化のトリガとすることができます。予約アップデートのこの連鎖は、高いオーバーヘッドを表すことができます。ここでの意味は、個々のトランスポートプロトコルをチューニングするために、彼らはロケータ変更トリガで（その原因を知らない）過渡的なルーティング変更遅延の特定の形態には反応しないように、彼らは、ロケータ変更トリガとして与える任意のフィードバックを持っているかもしれないということです。また別のトランスポートプロトコルは、管理のためにかなり異なる振る舞いやフックを持っていることに留意すべきです。
The selection of a locator to use for the remote end is obviously constrained by the current state of the topology of the network, and the primary objective of the selection process is to choose a viable locator that allows the packet to reach the intended destination point. The selection of a source locator can be considered as an indication of preference to the remote end of a preferred locator to use for the local end. However, where there are two or more viable locators that could be used, the selection of a particular locator may be influenced by a set of additional considerations.
リモートエンドに使用するロケータの選択は、明らかに、ネットワークのトポロジーの現在の状態によって制約され、選択プロセスの主な目的は、パケットが意図した目的地点に到達することを可能にする実行可能なロケータを選択することです。ソースロケータの選択は、ローカルエンドに使用する好適なロケータのリモートエンドに嗜好の指示と考えることができます。ただし、使用できる二つ以上の実行可能なロケータが存在する場合、特定のロケータの選択は、追加の考慮事項のセットによって影響を受ける可能性があります。
The selection of a particular locator from a viable locator set implies a selection of one particular network path in preference to other viable paths. An implication of this host-based locator selection process is that path selection and, by inference, traffic engineering functions are not constrained to a network-based operation of path manipulation through adjustment of forwarding state within network elements. There is a consequent interaction between the locator selection process and traffic engineering functions. The use of an address selection policy table, as described in RFC 3484 [RFC3484], is relevant to the selection process.
実行可能なロケータセットから特定のロケータの選択は、他の実行可能な経路に優先して一つの特定のネットワーク・パスを選択することを意味します。このホストベースのロケータ選択プロセスの含意が推論によって、その経路選択であり、トラフィックエンジニアリング機能は、ネットワーク要素内の状態を転送するの調整を介してパス操作のネットワーク・ベースの操作に制約されません。ロケータ選択プロセスとトラフィックエンジニアリング機能間の必然的な相互作用があります。 RFC 3484 [RFC3484]で説明されるようにアドレス選択ポリシーテーブルの使用は、選択プロセスに関連しています。
The element that performs the locator selection, either as a protocol element within the host or as a selection undertaken at a site-exit router, also determines traffic policy, so the choice of using remote packet locator rewriting or host based locator selection shifts the policy capability from one element to the other.
ホスト内のプロトコル要素として、またはサイト出口ルータで行わ選択のいずれかと、ロケータ選択を行う要素は、また、トラフィックポリシーを決定するので、ロケータ選択を書き換えるまたはホストベースのリモートパケットロケータを使用しての選択は、ポリシーをシフト他の1つの要素からの機能。
If hosts perform this policy determination, then a more fine-grained outcome may be achievable, particularly if the anticipated traffic characteristics of the application can be signalled to the locator selection process. A further consideration appears to be that hosts may require additional information if they are to make locator address selection decisions based on some form of metric of relative load currently being imposed on select components of a number of end-to-end network paths. These considerations raise the broader issue of traffic engineering being a network function entirely independent of host function or an outcome of host interaction with the network.
ホストは、このポリシー決意を実行する場合、よりきめの細かい結果は、アプリケーションの予想されるトラフィック特性をロケータ選択プロセスに通知することができる場合は特に、達成することができます。さらなる考慮は、現在のエンドツーエンドネットワークパスの数のコンポーネントの選択に課されている相対負荷のメトリックのいくつかの形態に基づいてロケータアドレス選択決定を行うのであればホストが追加の情報を必要とするかもしれないことであると思われます。これらの考慮事項は、トラフィックエンジニアリングのより広範な問題は、ホスト機能やネットワークとホストの相互作用の結果から完全に独立したネットワーク機能であること引き上げます。
In the latter case, there is also the consideration of whether the host is to interact with the network, and, if so, how this interaction is to be signalled to hosts.
後者の場合、ホストは、この相互作用がホストに通知されるようであれば、どのように、ネットワークと相互作用することである、とするかどうかの検討もあります。
The consideration of triggering locator switch highlights the observation that differing information and context are present in each layer of the protocol stack. This impacts on how identity/locator bindings are established, maintained, and expired.
ロケータスイッチトリガの考慮は、異なる情報とコンテキストは、プロトコルスタックの各レイヤに存在する観察を強調する。アイデンティティ/ロケータバインディングが確立された方法に影響を及ぼしますが、維持、および有効期限が切れています。
These impacts include questions of what amount of state is kept, by which element of the protocol stack, and at what level of context (dynamic or fixed, and per session or per host). It also includes considerations of state maintenance, such as how stale or superfluous state information is detected and removed. Does only one piece of code have to be aware of this identity/locator binding, or do multiple transport protocols have to be altered to support this functionality? If so, are such changes common across all transport protocols, or do different protocols require different considerations in their treatment of this functionality?
これらの影響は、プロトコルスタックのどの要素によって、コンテキストのどのレベル（動的又は固定し、セッションごとまたはホストごとに）、保持された状態のもの量の質問を含みます。それはまた、古くなった、または余分の状態情報を検出して除去する方法などの状態の維持の考慮を含みます。コードの唯一の一枚は、このアイデンティティ/ロケータ結合を意識する必要がない、または複数のトランスポートプロトコルがこの機能をサポートするように変更する必要がありますか？もしそうなら、そのような変更は、すべてのトランスポートプロトコルに共通する、または異なるプロトコルがこの機能の彼らの治療に異なる配慮が必要なのですか？
It is noted that the approaches considered here include proposals to place this functionality within the IP layer, with the end-to-end transport protocol layer and as a shim between the IP and transport protocol layers.
ここで考えアプローチは、エンドツーエンドのトランスポートプロトコル層とIPおよびトランスポートプロトコル層の間にシムとして、IP層の中に、この機能を配置する提案が含まれていることを指摘しています。
Placing this identity functionality at the transport protocol layer implies that the identity function can be tightly associated with a transport session. In this approach, session startup can trigger the identity/locator initial binding actions and transport protocol timeouts can be used as triggers for locator switch actions. Session termination can trigger expiration of local identity/locator binding state. Where per-session opportunistic identity token values are being used, the identity information can be held within the overall session state. In the case of persistent identity token values, the implementation of the identity can also choose to use per-session state, or it may choose to pool this information across multiple sessions in order to reduce overheads of dynamic discovery of identity/locator bindings for remote identities in the case of multiple sessions to the same remote endpoint.
トランスポートプロトコル層で、この識別機能を配置する恒等関数をしっかりトランスポートセッションに関連付けることができることを意味します。このアプローチでは、セッションの起動は、最初の結合アクションとトランスポートプロトコルのタイムアウトはロケータスイッチアクションのトリガーとして使用することができますアイデンティティ/ロケータをトリガすることができます。セッション終了は、ローカルアイデンティティ/ロケータ結合状態の期限切れをトリガすることができます。セッションごとの日和見アイデンティティ・トークン値が使用されている場合、識別情報は、全体のセッション状態内に保持することができます。永続的なアイデンティティトークン値の場合には、同一の実装は、セッションごとの状態を使用するように選択することができ、またはそれは、リモートのID /ロケータバインディングの動的検出のオーバーヘッドを低減するために、複数のセッション間でこの情報をプールすることを選択することができます同じリモートエンドポイントへの複数のセッションの場合のアイデンティティ。
One of the potential drawbacks of placing this functionality within the transport protocol layer is that it is possible that each transport protocol will require a distinct implementation of identity functionality. This is a considerable constraint in the case of UDP, where the UDP transport protocol has no inherent notion of a session state.
トランスポートプロトコル層内にこの機能を配置するの潜在的な欠点の一つは、各トランスポート・プロトコルは、同一機能の異なる実装を必要とすることが可能であるということです。これは、UDPトランスポートプロトコルは、セッション状態のない固有の概念を持っていないUDPの場合にはかなりの制約です。
An alternative approach is to use a distinct protocol element placed between the transport and internet layers of the protocol stack. The advantage of this approach is that it would offer a consistent mapping between identities and locators for all forms of transport protocols. However this protocol element would not be explicitly aware of sessions and would either have to discover the appropriate identity/locator mapping for all identity-addressed packets passed from the transport protocol later, irrespective of whether such a mapping exists and whether this is part of a session context, or have an additional mechanism of signalling to determine when such a mapping is to be discovered and applied. At this level, there is also no explicit knowledge of when identity/locator mapping state is no longer required, as there is no explicit signalling of when all flows to and from a particular destination have stopped and resources consumed in supporting state can be released. Also, such a protocol element would not be aware of transport-level timeouts, so that additional functionality would need to be added to the transport protocol to trigger a locator switch at the identity protocol level. Support of per-session opportunistic identity structure is more challenging in this environment, as the transport protocol layer is used to store and manipulate per-session state. In constructing an identity element at this level of the protocol stack, it would appear necessary to ensure that an adequate amount of information is being passed between the transport protocol, internet protocol, and identity protocol elements, to ensure that the identity protocol element is not forced into making possibly inaccurate assumptions about the current state of active sessions or end-to-end network paths.
別のアプローチは、プロトコルスタックのトランスポートとインターネット層の間に配置された別個のプロトコル要素を使用することです。このアプローチの利点は、トランスポートプロトコルのすべての形態のためのアイデンティティとロケータの間で一貫性のマッピングを提供するだろうということです。しかしながら、このプロトコル要素は、セッションの明示的に認識しないであろうとにかかわらず、そのようなマッピングが存在するかどうかの、これはの一部であるかどうか、後のトランスポートプロトコルから渡された全て同一宛のパケットのための適切なアイデンティティ/ロケータマッピングを発見しなければならないのいずれかでセッション・コンテキスト、またはそのようなマッピングが発見され、適用される場合を決定するためのシグナリングの追加の機構を有しています。このレベルでは、停止していると支持状態で消費されるリソースを解放することができるすべてに特定の宛先から流れる際の明示的なシグナリングは存在しないように、また、アイデンティティ/ロケータマッピング状態がもはや必要とされる場合の明示的な知識がありません。追加機能は、同一のプロトコルレベルでロケータ・スイッチをトリガするために、トランスポートプロトコルに追加する必要があるように、また、そのようなプロトコル要素は、トランスポートレベルのタイムアウトを認識しないであろう。トランスポートプロトコル層はセッションごとの状態を格納し、操作するために使用されるセッションごとの日和見同一構造の支持体は、このような環境において、より困難です。プロトコルスタックのこのレベルで同一の要素を構築するには、情報の適切な量は、アイデンティティプロトコル要素がないことを保証するために、トランスポートプロトコル、インターネットプロトコル、および同一のプロトコル要素との間に渡されていることを保証するために必要と思われますアクティブなセッションまたはエンドツーエンドのネットワーク・パスの現在の状態について、おそらく不正確な仮定を行うことを余儀なく。
It is also possible to embed this identity function within the internet protocol layer of the protocol stack. As noted in the previous section, per-session information is not readily available to the identity module, so that opportunistic per-session identity values would be challenging to support in this approach. It is also challenging to determine when identity/locator state information should be set up and released. It would also appear necessary to signal transport-level timeouts to the identity module as a locator switch trigger. Some attention needs to be given in this case to synchronising locator switches and IP packet fragmentation. Consideration of IPSec is also necessary in this case, in order to avoid making changes to the address field in the IP packet header that trigger a condition at the remote end where the packet is not recognisable in the correct context.
プロトコル・スタックのインターネットプロトコル層内このアイデンティティ機能を埋め込むことも可能です。前節で述べたように日和見ごとのセッションID値が、このアプローチでサポートするために挑戦されるであろうように、セッションごとの情報は、識別モジュールに容易に入手できません。また、アイデンティティ/ロケータ状態情報を設定し、解放されるべきかを決定するために挑戦しています。また、ロケータスイッチトリガとして識別モジュールに転送レベルのタイムアウトを通知するために必要と思われます。いくつかの注意がロケータスイッチとIPパケットの断片化を同期するには、この場合に与えられる必要があります。 IPSecの考慮は、パケットが正しいコンテキストで認識できない遠隔端での状態をトリガーするIPパケットのヘッダのアドレスフィールドを変更することを避けるために、この場合にも必要です。
The next issue is the difference between the initial session startup mode of operation and the maintenance of the session state.
次の問題は、操作の最初のセッションの起動モードおよびセッション状態の維持との間の差です。
In a split endpoint identifier/locator environment, there needs to be at least one initial locator associated with an endpoint identifier in order to establish an initial connection between the two hosts. This locator could be loaded into the DNS in a conventional fashion, or, if the endpoint identifier is a distinguished address value, the initial communication could be established using the endpoint identifier in the role of a locator (i.e., using this as a conventional address).
分割エンドポイント識別子/ロケータ環境では、2つのホスト間の初期接続を確立するためにエンドポイント識別子に関連する少なくとも一つの初期のロケータが必要です。エンドポイント識別子は、初期通信を（ロケータの役割にエンドポイント識別子を使用して確立することができる識別アドレス値である場合、このロケータは、従来の方法でDNSにロード、またはすることができ、すなわち、従来のアドレスとしてこれを使用して）。
The initial actions in establishing a session would be similar. If the session is based on specification of a FQDN, the FQDN is first mapped to an endpoint identity value, and this endpoint identity value could then be mapped to a locator set. The locators in this set are then candidate locators for use in establishing an initial synchronised state between the two hosts. Once the state is established, it is possible to update the initial locator set with the current set of useable locators. This update could be part of the initial synchronisation actions, or deferred until required.
セッションを確立するの最初のアクションは同様であろう。セッションがFQDNの仕様に基づいている場合、FQDNは、第一のエンドポイントID値にマッピングされ、このエンドポイントのID値は、その後、ロケータセットにマッピングすることができます。このセットのロケータは、2つのホスト間の初期同期状態を確立する際に使用するための候補ロケータです。状態が確立されると、使用可能なロケータの現在のセットで設定された初期のロケータを更新することが可能です。このアップデートでは、最初の同期アクションの一部、または必要になるまで延期することができます。
This leads to the concept of a "distinguished" locator that acts as the endpoint identifier, and a pool of alternative locators that are associated with this "home" locator. This association may be statically defined, using referential pointers in a third-party referral structure (such as the DNS), or dynamically added to the session through the actions of the EIP, or both.
これは、エンドポイント識別子として機能し、「区別」ロケータの概念、そしてこの「家」ロケータに関連付けられている代替ロケータのプールにつながります。この関連付けは、静的（DNSなど）、サードパーティの紹介構造で参照ポインタを使用して、定義された、または動的にEIP、または両方の作用を介してセッションに追加することができます。
If opportunistic identities are used where the identity is not a fixed discoverable value but one that is generated in the context of a session, then additional actions must be performed at session startup. In this case, there is still the need for defined locators that are used to establish a session, but then an additional step is required to generate session keys and exchange these values in order to support the identity equivalence of multiple locators within the ensuing session. This may take the form of a capability exchange and an additional handshake and associated token value exchange within the transport protocol if an in-band approach is being used, or it may take the form of a distinct protocol exchange at the level of the identity protocol element, performed out-of-band from the transport session.
アイデンティティが固定値ではなく、発見セッションのコンテキストで生成されるものではないところ日和見アイデンティティが使用されている場合は、追加のアクションは、セッション開始時に実行する必要があります。この場合には、セッションを確立するために使用されるが、追加のステップは、セッション鍵を生成し、その後のセッション内で複数のロケータの識別等価性をサポートするために、これらの値を交換するために必要とされる定義されたロケータが依然として必要とされています。インバンドアプローチが使用されている場合、これは、トランスポートプロトコル内で能力交換および追加のハンドシェーク及び関連するトークン値交換の形をとることができる、またはそれはアイデンティティプロトコルのレベルで異なるプロトコル交換の形をとることができます要素は、トランスポート・セッションからのアウトオブバンド行きました。
Some approaches are capable of a further distinction, namely, that of initial session establishment and that of establishment of additional shared state within the session to allow multiple locators to be treated as being bound to a common endpoint identity. It is not strictly necessary that such additional actions be performed at session startup, but it appears that such actions need to be performed prior to any loss of end-to-end connectivity on the selected initial locator, so that any delay in this additional state exchange does increase the risk of session disruption due to connectivity changes.
いくつかのアプローチは、複数のロケータが共通のエンドポイントIDにバインドされているものとして扱われることを可能にするために、すなわち、初期セッション確立と、セッション内の追加の共有状態の確立と、さらに区別することが可能です。このような追加のアクションは、セッション開始時に実行されることは厳密には必要ありませんが、そのような行動は、選択された初期のロケータ上のエンド・ツー・エンドの接続の損失に先立って実行する必要があると表示されるので、この追加の状態で任意の遅延交換は、接続の変更によるセッション中断のリスクを高めるん。
This raises a further question of whether the identity/locator split is a capability negotiation performed per session or per remote end, or whether the use of a distinguished identity value by the upper level application to identify the remote end triggers the identity/locator mapping functionality further down in the protocol stack at the transport level, without any further capability negotiation within the session.
これは、アイデンティティ/ロケータ分割がセッションごとまたはリモートエンドごとに実行能力交渉であるかどうかのさらなる問題を提起、またはリモートエンドを識別するために上位アプリケーションによって区別識別値の使用は、アイデンティティ/ロケータマッピング機能をトリガするかどうかさらに下搬送レベルのプロトコルスタックに、セッション内の任意のさらなる機能ネゴシエーションはありません。
Within the steps related to session startup, there is also the consideration that the passive end of the connection follows a process where it may need to verify the proposed new address contained in the source address of incoming packets before using it as a destination address for outgoing packets. It is not necessarily the case that the sender's choice of source address reflects a valid path from the receiver back to the source. While using this offered address appears to offer a low-overhead response to connection attempts, if this response fails the receiver may need to discover the full locator set of the remote end through some locator discovery mechanism, to establish whether there is a viable locator that can use a forwarding path that reaches the remote end.
セッションの起動に関連する手順の中では、接続の受動端部は、それが発信の宛先アドレスとして使用する前に、着信パケットの送信元アドレスに含まれる提案された新しいアドレスを確認する必要があるかもしれないプロセスに続く考察もありますパケット。これは、送信元アドレスの送信者の選択は、送信元に受信機から有効なパスを反映していると必ずしもそうではありません。この提供されたアドレスを使用して接続試行への低オーバーヘッドの応答を提供するように見えますが、この応答が失敗した場合、受信機は、その実行可能なロケータがあるかどうかを確立するための、いくつかのロケータ発見機構を介してリモートエンドの完全なロケータセットを発見する必要があるかもしれませんリモートエンドに到達する転送パスを使用することができます。
Alternatively, the passive end would use the initially offered locator and, if this is successful, leave it to the identity modules in each stack to exchange information to establish the current complete locator set for each end. This approach implies that the active end of a communication needs to cycle through all of its associated locators as source addresses until it receives a response or exhausts its locator set. If the other end is also multi-homed (and therefore has multiple locators), then the active end may need to cycle through all possible destination locators for each source locator. While this may extend the time to confirm that no path exists to the remote end, it has the potential to improve the characteristics of the initial exchange against denial-of-service attacks that could force the remote end to engage in a high volume of spurious locator lookups.
また、受動的なエンドは、これが成功した場合、それぞれの端部に設定されている現在の完全なロケータを確立するための情報を交換するために、各スタック内の識別モジュールにそれを残して、最初に提供されたロケータを使用します。このアプローチは、それが応答を受信するか、またはそのロケータセットを使い果たすまで、通信の活性末端が送信元アドレスとしてその関連ロケータの全てを循環する必要があることを意味します。他方の端部は、また、マルチホームである（したがって、複数のロケータを有する）場合、活性末端は、各ソースロケータのすべての可能な宛先ロケータを介してサイクルする必要があるかもしれません。これは、パスがリモートエンドに存在しないことを確認するための時間を延長することができるが、それは偽の大量に係合するようにリモートエンドに強制可能性がサービス拒否攻撃に対する初期の交換の特性を改善する可能性を有しますロケータ検索。
The common aspect of these approaches is that they all involve changes to the end-to-end interaction, as both ends of the communication need to be aware of this separation. The implication is that this form of support for multi-homing is relatively sweeping in its scope, as the necessary changes to support multi-homing extend beyond changes to the hosts and/or routers within the multi-homed site and encompass changes to the IPv6 protocol itself. It would be prudent when considering these changes to evaluate associated mechanisms that allow the communicating endpoints to discover each other's capabilities and only enable this form of split identity/locator functionality when it is established that both ends can support it.
これらのアプローチの一般的な側面は、通信の両端がこの分離に注意する必要があるとして、それらはすべて、エンド・ツー・エンドの相互作用への変更を伴うということです。含意は、必要な変更は、マルチホーミングは、マルチホームサイト内のホストへの変更、および/またはルータを越えて延びるサポートとIPv6への変更を包含するようマルチホーミングのためのサポートのこの形態は、その範囲内の比較的掃引であることですプロトコル自体。通信エンドポイントが互いの能力を発見し、両端がそれをサポートできることが確立されている場合にのみ、スプリットアイデンティティ/ロケータ機能は、このフォームを使用可能にすることができ、関連するメカニズムを評価するために、これらの変更を検討する際には慎重になります。
It is a corollary of this form of negotiated capability that it is not strictly necessary that only one form of functionality can be negotiated in this way. If the adoption of a particular endpoint identity/locator mapping scheme is the outcome of a negotiation between the endpoints, then it would be possible to negotiate to use one of a number of possible approaches. There is some interaction between the approach used and the form of endpoint identity, and some care needs to be taken that any form of acceptable outcome of the endpoint identity capability negotiation is one that allows the upper-level application to continue to operate.
機能の一形態のみがこのように交渉することができることを厳密には必要ではないということで交渉の能力のこの形式の当然の結果です。特定のエンドポイントのアイデンティティ/ロケータマッピング方式の採用は、エンドポイント間の交渉の結果である場合、可能な多くのアプローチのいずれかを使用するようにネゴシエートすることが可能です。そこ使用されるアプローチとエンドポイントのアイデンティティの形の間に何らかの相互作用があり、そしていくつかのケアは、エンドポイントのアイデンティティ機能ネゴシエーションの許容可能な結果のいずれかの形式は、上位のアプリケーションが動作し続けることが可能にするものであることに注意する必要があります。
When considering the properties of long-lived identities, it is reasonable to assume that the identity assignation is not necessarily one that is permanent and unchangeable. In the case of structured identity spaces, the identity value reflects a distribution hierarchy. There are a number of circumstances where a change of identity value is appropriate. For example, if an endpoint device is moved across administrative realms of this distribution hierarchy it is likely that the endpoint's identity value will be reassigned to reflect the new realm. It is also reasonable to assume that an endpoint may have more than one identity at any point in time. RFC 3014 [RFC3041] provides a rationale for such a use of multiple identities.
長寿命のアイデンティティの性質を考えると、アイデンティティの逢引は必ずしも永続的かつ不変であるものではないと仮定することが妥当です。構造化されたアイデンティティスペースの場合には、識別値は、配布階層を反映しています。アイデンティティ値の変化が適切である状況がいくつかあります。エンドポイントデバイスは、この配布階層の管理レルムを横切って移動する場合たとえば、エンドポイントのID値は、新しい領域を反映するために再割り当てされる可能性があります。エンドポイントが任意の時点で複数のIDを持っていることを前提とすることも妥当です。 RFC 3014 [RFC3041]は、複数のアイデンティティのような使用のための理論的根拠を提供します。
If an endpoint's identity can change over time and if an endpoint can be identified by more than one identity at any single point in time, then some further characteristics of endpoint identifiers should be defined. These relate to the constancy of an endpoint identity within an application, and the question of whether a transport session relies on a single endpoint identity value, and, if so, whether an endpoint identity can be changed within a transport session, and under what conditions the old identity can continue to be used following any such change. If the endpoint identity is a long-lived reference to a remote endpoint, and if multiple identities can exist for a single unique endpoint, then the question arises as to whether applications can compare identities for equivalence, and whether it is necessary for applications to recognise the condition where different identities refer to the same endpoint. These identities may be used within applications on a single host, or they may be identifies within applications on different hosts.
エンドポイントのアイデンティティは、時間の経過とともに変化することができ、エンドポイントが時間内の任意の一点において、複数のアイデンティティで識別することができれば、その後のエンドポイント識別子のいくつかの更なる特徴が定義されている必要があります。これらは、アプリケーション内のエンドポイントのID、およびトランスポート・セッションは、単一のエンドポイントのID値に依存しているかどうかの質問の恒常に関連し、そして、もしそうであれば、エンドポイントのアイデンティティは、トランスポートセッション内で変更することができるかどうか、そしてどのような条件の下で古いアイデンティティは、その変更後に使用し続けることができます。エンドポイントのアイデンティティは、リモートエンドポイントへの長命参照され、複数のIDを単一のユニークなエンドポイントに存在することができれば、その後の質問は、アプリケーションが同等のためのアイデンティティを比較できるかどうかが発生し、アプリケーションが認識することが必要であるかどうか場合異なるアイデンティティが同じエンドポイントを参照する条件。これらのIDは、単一のホスト上のアプリケーション内で使用され得る、またはそれらは、異なるホスト上のアプリケーション内で識別することができます。
The following sections provide a framework for the characterisation of multi-homing approaches through a decomposition of the functions associated with session establishment, maintenance, and completion in the context of a multi-homed environment.
以下のセクションでは、マルチホーミングの特徴付けのためのフレームワークは、マルチホーム環境のコンテキスト内でセッションの確立、維持、および終了に関連する機能の分解により近づく提供します。
What form of token is passed to the transport layer from the upper-level protocol element as an identification of the local protocol stack?
トークンのどのような形態では、ローカルプロトコルスタックの識別として上位プロトコル素子からのトランスポート層に渡されますか？
What form of token is passed to the transport layer from the upper-level protocol element as an identification of the remote session target?
トークンのどのような形態は、リモートセッションの対象の識別として上位プロトコル素子からのトランスポート層に渡されますか？
What form of token is used by the upper-level protocol element as a self-identification mechanism for use within the application payload?
トークンのどのような形態では、アプリケーション・ペイロード内で使用するための自己識別機構として上位プロトコル要素によって使用されますか？
Does the identity protocol element need to create a mapping from the upper-level protocol's local and remote identity tokens into an identity token that identifies the session? If so, then is this translation performed before or after the initial session packet exchange handshake?
アイデンティティプロトコル要素は、セッションを識別するIDトークンに上位レベルのプロトコルのローカルおよびリモートのアイデンティティトークンからのマッピングを作成する必要がありますか？もしそうなら、この翻訳は、前または最初のセッションパケット交換ハンドシェイクの後に行われますか？
How does the session initiator establish that the remote end of the session can support the multi-homing capabilities in its protocol stack? If the remote end cannot, does the multi-homing capable protocol element report a session establishment failure to the upper-level protocol or silently fall back to a non-multi-homed protocol operation?
どのようにセッション開始剤は、セッションのリモートエンドがそのプロトコルスタックのマルチホーミング機能をサポートできることを確立していますか？リモートエンドは、マルチホーミング可能なプロトコル要素は、上位プロトコルにセッション確立の失敗を報告したりサイレント非マルチホームプロトコルの動作にフォールバックしないことができるかどうか？
How do the endpoints discover the locator set available for each other endpoint (locator discovery)?
どのようにエンドポイントがお互いのエンドポイント（ロケータ発見）に使用可能なロケータセットを発見するのですか？
What mechanisms are used to perform locator selection at each end, for the local selection of source and destination locators?
どのようなメカニズムは、送信元と宛先ロケータのローカル選択のために、各端にロケータの選択を実行するために使用されていますか？
What form of mechanism is used to ensure that the selected site exit path matches the selected packet source locator?
メカニズムのどのような形は、選択されたサイトの出口経路が選択されたパケットの送信元ロケータと一致することを確実にするために使用されていますか？
What are common denominator goals of re-homing triggers? What are the objectives that triggers conservatively should meet across all types of sessions?
再ホーミングトリガの共通分母の目標は何ですか？セッションのすべてのタイプで満足しなければならない保守的トリガーの目標は何ですか？
Are there transport session-specific triggers? If so, then what state changes within the network path should be triggers for all transport sessions, and what state changes are triggers only for selected transport sessions?
トランスポートセッション固有のトリガーはありますか？もしそうなら、ネットワーク経路内でどのような状態の変更は、すべてのトランスポートセッションのトリガーであるべきであり、唯一の選択転送セッションのためのトリガーは、どのような状態に変化していますか？
What triggers are used to identify that a switch of locators is desirable?
どのようなトリガーは、ロケータのスイッチが望ましいことを識別するために使用されていますか？
Are the triggers based on the end-to-end transport session and/or on notification of state changes within the network path from the network?
エンドツーエンドのトランスポートセッション上および/またはネットワークからネットワーク経路内の状態変化の通知に基づいてトリガーはありますか？
What triggers can be used to indicate the direction of the failed path in order to trigger the appropriate locator repair function?
どのようなトリガーは、適切なロケータ修復機能をトリガするために失敗したパスの方向を示すために使用することができますか？
What parameters are used to determine the selection of a locator to use to reference the local endpoint?
どのようなパラメータは、ローカルエンドポイントを参照するために使用するロケータの選択を決定するために使用されていますか？
If the remote endpoint is multi-homed, what parameters are used to determine the selection of a locator to use to reference the remote endpoint?
リモートエンドポイントがマルチホームである場合、どのようなパラメータは、リモートエンドポイントを参照するために使用するロケータの選択を決定するために使用されますか？
Must a change of an egress site-exit router be accompanied by a change in source and/or destination locators?
出口サイト出口ルータの変更は、ソースおよび/または宛先ロケータの変化を伴わなければなりませんか？
How can new locators be added to the locator pool of an existing session?
どのように新しいロケータは、既存のセッションのロケータプールに追加することができますか？
What are the preconditions that are necessary for a locator change?
ロケータの変更に必要な前提条件は何ですか？
How can the locator change be confirmed by both ends?
どのようにロケータの変化は、両端によって確認することができますか？
What interactions are necessary for synchronisation of locator change and transport session behaviour?
どのような相互作用は、ロケータ変更とトランスポートセッションの動作を同期させるために必要なのでしょうか。
How is identity/locator binding state removal synchronised with session closure?
どのようにアイデンティティ/ロケータ結合状態の除去は、セッションの閉鎖と同期していますか？
What binding information is cached for possible future use?
バインディングどのような情報は、可能な将来の使用のためにキャッシュされていますか？
There are a significant number of security considerations that result from the action of distinguishing within the protocol suite endpoint identity and locator identity.
プロトコルスイートのエンドポイントのアイデンティティとロケータアイデンティティ内区別の作用に起因するセキュリティ上の考慮事項のかなりの数があります。
It is not proposed to enumerate these considerations in detail within this document, but to reference a distinct document that describes the security considerations of this domain [threats].
この文書の中で詳細にこれらの考慮事項を列挙するために提案されていませんが、このドメインのセキュリティの考慮事項[脅威]を説明する個別の文書を参照すること。
The author acknowledges the assistance from the following reviewers: Brian Carpenter, Kurtis Lundqvist, Erik Nordmark, Iljitsch van Beijnum, Marcelo Bagnulo, John Loughney, Thierry Ernst, Joe Touch, Michael Patton, Ted Hardie, and Allison Mankin.
ブライアン・カーペンター、カーティスルンドクヴィスト、エリックNordmarkと、IljitschバンBeijnum、マルセロBagnulo、ジョンLoughney、ティエリーエルンスト、ジョー・タッチ、マイケル・パットン、テッドハーディー、およびアリソンマンキン：著者は、次のレビュアーからの支援を認めています。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582] Abley、J.、ブラック、B.、およびV.ギル、 "IPv6のサイトマルチホーミングアーキテクチャの目標"、RFC 3582、2003年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[iab-link] Aboba, B., Ed., "Architectural Implications of Link Layer Indications", Work in Progress, January 2005.
[IABリンク] Aboba、B.、エド。、「リンクレイヤ適応症の建築的意味」、進歩、2005年1月での作業。
[e2e] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design", ACM TOCS Vol 2, Number 4, pp 277-288, November 1984, <http://web.mit.edu/Saltzer/www/ publications/endtoend/endtoend.txt>.
[E2E] Saltzer、J.、リード、D.、およびD.クラーク、 "システム設計におけるエンドツーエンドの引数"、ACM TOCS第2巻、ナンバー4、頁277-288、1984年11月、<のhttp：/ /web.mit.edu/Saltzer/www/出版/ endtoend / endtoend.txt>。
[rosec] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", Work in Progress, October 2004.
[rosec] Nikander、P.、Arkko、J.、オーラ、T.、モンテネグロ、G.、およびE. Nordmarkと、 "モバイルIPバージョン6経路最適化セキュリティデザインの背景"、進歩、2004年10月に作業。
[thinks] Lear, E., "Things MULTI6 Developers should think about", Work in Progress, January 2005.
[思う]リア、E.は、「物事MULTI6開発者が考えなければならない」の進捗状況、2005年1月に作業します。
[threats] Nordmark, E. and T. Li, "Threats relating to IPv6 multi-homing solutions", Work in Progress, January 2005.
[脅威] Nordmarkと、E.とT.李、進歩、2005年1月に仕事の「IPv6マルチホーミングソリューションに関連する脅威」。
Author's Address
著者のアドレス
Geoff Huston APNIC
ジェフ・ヒューストンAPNIC
EMail: gih@apnic.net
メールアドレス：gih@apnic.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。