[要約] RFC 4177は、IPv6のマルチホーミングに対するアーキテクチャ的アプローチを提供するものであり、その目的は、IPv6ネットワークにおける複数の接続先への効果的なアクセスを実現することです。
Network Working Group G. Huston
Request for Comments: 4177 APNIC
Category: Informational September 2005
Architectural Approaches to Multi-homing for IPv6
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).
Copyright（c）The Internet Society（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のマルチホーミング環境のサポートに関連するさまざまな技術提案を、建築分類法の範囲内に配置できるようにすることです。これは、これらの提案を構造化された方法で分類および比較できるようにすることを目的としています。また、この研究のドメイン内のすべての提案にわたって共通の側面を特定し、マルチホーミングをサポートすることを目的としたさまざまな建築拡張のさらなる意味を調査できるフレームワークを提供することも、この演習の目的です。この研究の範囲はIPv6プロトコルスイートアーキテクチャに限定されていますが、必要に応じてIPv4アプローチを参照しています。
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.
Care-of Address（COA）外国リンクのアクセス中にモバイルノードに関連付けられたユニキャストルーティング可能なアドレス。このIPアドレスのサブネットプレフィックスは、外部サブネットプレフィックスです。モバイルノードがいつでも持っている可能性のある複数のケアアドレス（例：異なるサブネットプレフィックスを使用）の中で、特定のホームアドレスのモバイルノードのホームエージェントに登録されているものは、その「プライマリ」ケアオブアドレスと呼ばれます。。
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.
エンドポイントネットワークホストのIDの用語。これは通常、一定または長寿命の関連であると想定されています。
Endpoint Identity Protocol Stack Element (EIP) An added element in a protocol stack model that explicitly manages the association of locators to endpoints.
エンドポイントIDプロトコルスタック要素（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.
サイトとその輸送プロバイダー間の接続性の変化により、2つの接続性の州間のサイトの移行を再ホーミングします。
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.
サイト拡張ルーター1つ以上のトランジットプロバイダーにサイトのインターフェイスを提供するサイトの境界ルーター。
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.
Transit Provider 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 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.
マルチホミングの環境は、ローカルホストがIPパケットをリモートホストと交換できるように、ローカルホストに十分なサポートを提供することを目的としています。セッションの復元力は、ローカルマルチホームアウェアホストが「PATH 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.
*ルーティングシステムとの相互作用、
* Endpoint-Identifierと転送ロケーターの間の分割の側面、
*ワイヤー上のパケットに変更します
*名前、エンドポイント、および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がローカルサイトのアドレスプレフィックスをドメイン間ルーティングシステムの明確なルーティングエントリとして発表する必要があります。このアプローチはIPv6コンテキストで使用でき、IPv4と同様に、このアプローチをサポートするために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.
ローカルサイトのアドレスプレフィックスは、トランジットプロバイダーの1つによって宣伝されているアドレススペースから、または現在ローカルサイトに直接接続されていない一部のサードパーティプロバイダーから描かれたより具体的なアドレスプレフィックスである場合があります。あるいは、アドレススペースは、プロバイダー独立したスペースとして地域のインターネットレジストリからの直接割り当てによって得られる明確なアドレスブロックである場合があります。ローカルサイト内の各ホストは、サイトのアドレスプレフィックスから一意に扱われます。
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.
もう1つの目標である輸送層の生存率は、このアプローチで潜在的に危険にさらされています。ネットワーク内の動的変化は、ルーティングシステムをトリガーして、新しい安定した分散型転送状態に収束します。分散ルーティングシステム内でのこの収束のプロセスには、不安定な一時的な転送パスを生成するネットワークが含まれる場合、および完了するための時間をかけることが含まれます。これは、期間中に上位レベルのプロトコルのタイムアウトをトリガーし、セッションのリセットをリセットする可能性があります。
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）を使用します。この識別子は、ネットワークトポロジ内の現在のアタッチメントポイントに対応する有効なロケーター（Care-of Address、またはCOA）に動的にマッピングされます。MNがホームネットワークにある場合、HOAはロケーターと識別子として使用されます。MNがホームネットワークにない場合、HOAは識別子として使用され、COAはロケーターとして使用されます。ホームネットワークに配置された中継エージェント（ホームエージェント）は、COAで指定された現在の場所にアドレス指定されたパケットを転送するために使用されます。各動きの後、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がそのような主張をする権利があることを確認できるようにすることです。これは本質的に、HOAがMNに割り当てられ、MNが現在COAにあることを意味します。これらの更新を検証するために、CNは2つの異なる秘密を送信します。1つは主張されたHOAに、もう1つは主張されたCOAに送信されます。MNが両方の秘密を受け取る場合、これはホームネットワークにあるホームエージェントがMNとの信頼関係を持ち、HOAに送られた秘密を転送し、MNがCOAに送信されたパケットを受信していることを意味します。BUメッセージ内の両方の秘密から派生した許可情報を含めることにより、MNはCNに、HOAとCOAの間の請求された結合が有効であることを証明することができます。
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はHOAに宛てたすべてのトラフィックを攻撃者が選択したCOAに転送します。その後、攻撃者はパスに沿って位置を離れることができますが、攻撃の影響はバインディングが削除されるまで残り、攻撃の影響をやり直します。CNでの結合の寿命を制限することにより、この攻撃の効果は7分に減少します。その期間後、結合寿命を延長するために新しいリターンルービリティ手順が必要であるためです。CNとMNの間の経路に沿って位置する攻撃者は、定期的な返品ルータビリティパケット交換を築くことができるため、リターンルービリティ手順は「中間者」攻撃に対して脆弱であることに注意する必要があります。
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として使用されます。この場合、マルチホームのノードはBUメッセージを外部ホストに送信し、HOAに使用される新しいCOAについて通知し、確立された通信を代替アドレスを使用して保存できるようにします。ただし、このような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では、IDの妥当性は、IDアドレスのreturn readeabilityによって定期的にテストされます。IDのトークンとしての著名なロケーターの定期的な使用は、IDロケーターに関連付けられているパスの拡張障害が発生した場合、マルチホミングコンテキストでの到達能力をサポートできません。
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.
トポロジベースのアドレスの展開とプロバイダーに凝集可能なアドレス指定アーキテクチャのこの制約の中で、複数のプロバイダーに接続されているローカルサイトは、これらの各プロバイダーのアドレスブロックから委任されたアドレスです。図1のネットワークの例では、ローカルマルチホームのホストは、トランジットプロバイダーAのアドレスプレフィックスを使用し、もう1つはトランジットプロバイダーBのアドレスプレフィックスを使用して、2つの方法で対処される可能性があります。
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つのアドレスを返します。1つはAプレフィックスを使用し、もう1つはBプレフィックスを使用しています。リモートホストは、これらのアドレスのいずれかを選択し、この宛先アドレスにパケットを送信します。これにより、選択したアドレスに応じて、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からローカルホストに逆パスを向けます。第二に、ISPS 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.
このアドレス指定構造には、特定のネットワーク障害のルーティングベースの修理の形式はありません。ローカルサイトとISP Aの間のリンクが失敗した場合、ISP Aが作成したルート広告に外部ルーティングピアに変更されることはありません。Multi-Homedサイトは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.
集約されたルーティング環境では、ホストへの複数のトランジットパスは、ホストの各通過パスがホストのアドレスによって識別されるホストの複数のアドレスプレフィックスを意味します。この制約のマルチホーミングに対する意味は、Transit Provider ISPを介してローカルマルチホームサイトに渡されるパスが、ISP Aの広告アドレスプレフィックスセットからマルチホームにマップされた転送レベルの宛先IPアドレスを使用する必要があることです。ホスト。同様に、ISP Bのトランジットを介して渡されるパケットは、ISP Bのアドレスプレフィックスセットから描かれた宛先アドレスを使用する必要があります。ここでのさらなる意味は、パス選択（ISP A対入ってくるパケットのISP Bトランジット）が、宛先ホストのアドレスを選択するプロセスの結果であることです。
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値を使用してセッションを開始および維持することができます。アイデンティティとロケーターの概念のこのような分離は、ドメイン間ルーティングシステムに増分負荷を追加しません。
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.
この目的に対する1つのアプローチは、プロトコルスタックのモデルに新しい要素を追加することです。
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）へのプレゼンテーションは、ロケーターの形式です。これは、プロトコルスタック要素がロケーター値にエンドポイント識別子値のマッピングを維持する必要があることを意味します。マルチホームのコンテキストでは、このマッピングの本質的な特性の1つは、環境トリガーがマッピングの変更をトリガーできるようにする必要があることです。これは、エンドポイントがネットワークを横断するために使用するパス（フォワードおよび/または逆）の変化に対応します。このようにして、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.
新しいプロトコルスタック要素（ここでは「エンドポイントIDプロトコルスタック要素」と呼ばれる）の動作は、リモートの対応物と同期された状態を確立します。これにより、スタック要素は、セッションのコンテキスト内で使用できるロケーターのセットを交換できます。現在のエンドポイントID値とロケーターの間のローカルバインディングの変更により、転送レベルのパケットヘッダーで使用されるソースロケーター値が変更されます。新しいロケーターを使用したこのパケットを受け取ったリモートEIPのアクションは、このロケーターを既存のセッションの一部として認識し、トリガー条件で、リモートエンドポイントIDのマッピングのセッションビューを対応するロケーターに変更することです。このロケーターを、後続のパケットの宛先ロケーターとして使用して、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.
可能な場所の1つは、輸送プロトコルの上位レベルです。ここでは、アプリケーションレベルのプロトコルのアプリケーションプログラムインターフェイス（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.
2番目のアプローチは、トランスポートレイヤーとインターネットプロトコルスタック要素の間にEIPを挿入することです。これにより、輸送層はエンドポイント識別子を使用して機能し、これらのエンドポイント識別子を使用してトランスポートセッションを維持します。IPまたはインターネットワークレイヤーはロケーターを使用して機能し、Endpoint IdentifierからLocatorへのマッピングは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）レイヤーに機能が追加されている場合、アクティブトランスポートセッションのコンテキストはないため、終了セッションのID/ロケーター状態情報の削除は、輸送層からの追加のメカニズムによってトリガーする必要があります。インターネットワーキングレイヤーに。
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.
1つの可能なアプローチでは、サイト排除ルーターを使用して、パケットがローカルマルチホームサイトから特定のトランジットプロバイダーに渡されるため、何らかの形のパケットヘッダー操作を実行します。ローカルサイトルーティングシステムは、リモートホストのロケーター値に基づいて、宛先ホストへの最適なパスを選択します。ローカルホストは、パケットのソースアドレスとしてエンドポイントアイデンティティを書き込みます。パケットがサイトを排除するルーターに到達すると、サイトエキシットルーターは、リモートホストによってロケーターが宛先ロケーターとして使用されるときに同じトランジット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.
サイトエキシットポイントでのパケットヘッダーの書き換えの代替手段は、上記のアプローチの1つを使用して、ホストがエンドポイント間マッピングを引き受けることです。ここでの考慮事項は、ソースアドレスのスプーフィングへの対策として、インターネット環境でのユニキャスト逆パスフィルタリングの重要な展開があることです。図1の例を使用して、ホストがISP Bアドレスのプレフィックスから描かれたロケーターを選択し、ローカルルーティングがそのパケットをサイトエキシットルーターAに指示する場合、ISP Aに渡されたパケットはそのようなフィルターによって破棄されます。サイト転送環境の動作を変更するためにさまざまなアプローチが提案されています。すべてがISP Bアドレスプレフィックスから描かれたソースロケーターを使用したパケットをサイトエキシットルーター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.
IDプロトコル要素の追加のアプローチと既存のプロトコル要素の変更のアプローチは、コミュニケーションの両当事者が相手のエンドポイントアイデンティティとロケーターへの関連マッピングを認識できるようにする何らかの形の情報交換を想定しています。。この情報交換を実装するための多くの可能なアプローチがあります。
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.
ここでは「従来の」アプローチと呼ばれる最初のこのような可能なアプローチは、ULPから渡されたプロトコルデータユニット（PDU）を、EIPの関数を特異的に参照する追加のデータ要素でカプセル化します。化合物データ要素は、PDUとしてLLPに渡されます。LLPからPDUを受け取った対応するアクションは、EIP関数に対応するデータユニットのフィールドを抽出し、PDUの残りをULPに渡すことです。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 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.
別のアプローチは、EIPが別の通信チャネルを使用して通信できるようにすることです。ここでは、EIPがピアEIPに向けられた専用のメッセージを生成し、ULPからEIPに渡されるPDUとは無関係にこれらのPDUをLLPに渡します。。これにより、EIPは情報を交換し、状態をULPプロトコル交換のリモートEIPと同期することができます。EIP関数の一部はULP PDUを変換してロケーター情報を含めることであるため、EIPピアリング状態がULP PDUの交換と同期したままであることを確認するために関連する要件があり、リモートEIPがロケーターを正しく認識できるようにします。アクティブセッションごとに終了します。
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.
ここでのもう1つの潜在的なアプローチは、エンドポイントからロケーターのマッピングをサードパーティによって保持できるようにすることです。このモデルは、Domain Name System（DNS）によって実行される名前からIPへの名前のアドレスマッピングをサポートするために既に使用されています。マッピングは、サードパーティ、つまりDNS Resolverを参照することにより取得されます。エンドポイントとロケーターセットの間の同様の形式のサードパーティマッピングは、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.
アイデンティティの考えられる形式の1つは、基礎となるプロトコルの「アドレス空間」から持ち上げられたアイデンティティトークンの使用です。言い換えれば、エンドポイントIDは、IPv6プロトコルアドレスの特別なケースインスタンスです。IPプロトコルのスイートと関連するアプリケーションのスイートは、すでにIPアドレスを操作しているため、この形式のエンドポイントIDを使用することには多くの利点があります。エンドポイントのアイデンティティとロケーターを区別するドメインの本質的な違いは、プロトコルのエンドポイントIDパーツがエンドポイントアイデンティティの役割を仮定するアドレスで動作し、エンドポイントID/ロケーターマッピング関数がエンドポイントからマッピングを引き受けることです。潜在的なロケーター「アドレス」のセットへの「アドレス」。また、ロケーターの「アドレス」から著名なエンドポイント識別子「アドレス」への逆マッピングを行います。IPアドレススペースは階層的に構造化されており、両方向で適切に効率的なマッピングを実行することができます。パブリックネットワーキングのコンテキストでのアドレスの基礎となるセマンティクスには、エンドポイントアイデンティティトークン値のグローバルな一意性に関する必要な考慮事項が含まれます。
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.
このアプローチをさらに進めて、エンドポイント識別子を有効なロケーターにすることができます。これは、「著名な」または「ホーム」ロケーターの存在を意味し、他のロケーターを必要に応じてこの最初のロケーターのピアリングに動的にマッピングすることができます。このアプローチの欠点は、エンドポイント識別子がトランジットプロバイダーのアドレスプレフィックスの1つに基づいており、トランジットプロバイダーの変更には、マルチホームサイト内のエンドポイント識別子値の変更が必然的に必要なことです。
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アドレス値を使用し、アプリケーションとプロトコル要素がアドレスプレフィックス値に基づいてエンドポイント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の両方として著名なまたはホームアドレスを使用することであると思われます。。この後者のオプションは、ロケーターのエンドポイント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）をエンドポイントのアイデンティティとして使用することも可能です。FQDNをルックアップ「キー」として使用して、上記のように同様のマッピングを行います。fqdnをセッション確立のコンテキストで使用できるため、エンドポイント識別子に関連付けられたデフォルトの「アドレス」がないことを意味し、DNSクエリを使用して初期ロケーターのセットを確立できるためです。もちろん、FQDNに関連する一意のエンドポイントが必ずしもあるとは限らない場合もあります。そのような場合、DNS RRSを介して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.
これら2つの異なるアイデンティティレルムの構文特性は、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.
1つのフォームは、永続的なアイデンティティフィールドを使用します。これにより、同時セッションとシーケンシャルセッションをサポートするために、この形式のアイデンティティが必要なすべてのコンテキストで同じID値が使用されていると推測されます。この形式のアイデンティティは、基礎となる接続の変化の経過とともに一定のままであることを目的としています。また、このアイデンティティがネットワークトポロジとは完全に異なる場合があるため、サイトやホストが使用する現在の接続性とロケーターアドレス指定に関係なく、同じアイデンティティが使用されます。この場合、アイデンティティは永続的であり、アイデンティティ値はエンドポイントスタックへの参照として使用できます。これは、マルチパーティの紹介をサポートします。この紹介では、パーティーAとBがコミュニケーションを確立する場合、BはAのIDをサードパーティCに渡すことができます。
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値の一意性は確保されていません。空間の非構造化された性質がルックアップの効率に関連する影響を及ぼし、ルックアップの真正性が弱体化するため、ロケーターを確立するためのルックアップキーとしてのそのようなアイデンティティの使用も変更されます。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.
別の形式のアイデンティティは短命形式です。セッションアイデンティティは、アイデンティティキーの役割を引き受ける特定のトークン値の交換なしに確立されたエンドポイント間の共有状態です。これにより、定義されたロケーターセットの形式またはセッションの共有属性のセットから派生したセッションキーの形式を使用できます。この状況では、セッションを開始する手段としての識別子への参照または使用の形式はありません。一時的なアイデンティティ値は、特定のセッションのメンバーシップのコンテキスト内でロケーターのセットのセマンティック等価性を確実に決定できるようにするという点で、非常に限られた役割を持っています。
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と関連するロケータースイッチの俊敏性の採用は、ネゴシエートされたセッション機能になります。
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.
一方、セッション開始キーとしての永続的なアイデンティティを使用することは、アイデンティティが確立されたセッション状態の一部であり、ロケーターの俊敏性がその後のネゴシエートされた能力ではなく、セッションの関連属性になることを意味します。そのようなアイデンティティ機能が均一に展開されていない不均一な環境では、これは、スプリットアイデンティティ/ロケーターバインディングでセッションを確立できない場合、アプリケーションがアイデンティティをマッピングすることで従来のセッションの起動に戻すことができるはずであることを意味します。特定のロケーター値とそのような値を使用してセッションを開始します。アプリケーションがこの区別を認識したい理由は、アプリケーションがアプリケーションペイロード内で自己参照メカニズムを使用したい場合、IDベースの自己参照を使用することが適切であると思われるためです。リモートパーティーがこの参照タグのセマンティックプロパティを認識していたセッション。
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.
マルチホーミング構成のサポートのコンテキストでは、ロケーターの等価性のコンテキストでのはかないアイデンティティの使用は、マルチのほとんどのコンテキストでホストのペア間の通信のコンテキスト内で複数のロケーターを交渉した使用を可能にする実行可能なアプローチを表しているように見えます。-ホーミング。ただし、一時的なアイデンティティは機能性の観点からはほとんど提供されません。参照コンテキストで使用することはできません。通信を開始するために使用することはできません。さまざまな形態のモビリティをサポートするための限られた手段を提供し、サポートできるマルチホームのシナリオのクラスにいくつかの制約を課します。一時的なアイデンティティは、確立されたコミュニケーション状態のコンテキストで生成され、マルチホミングの観点からの意味は、2つのエンドポイントが、一時的なアイデンティティ結合を生成する前に、既存のメカニズムを通じて実行可能なロケーターのペアを発見する必要があることです。意味は、従来の参照ルックアップによって発見されるエンドポイントには、静的な「ホーム」が何らかの形であるということです。
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つ以上の同等のアイデンティティ値間の動的翻訳をサポートする永続的なアイデンティティ空間の使用は、アプリケーションの柔軟性を高める可能性を提供します。アイデンティティとロケーターの間のマッピングがどのように管理されるかに応じて、これはマルチホミング構成を超えて、遊牧民とモビリティのさまざまなコンテキスト、およびサービス固有の機能にまで及ぶ可能性があります。ただし、アイデンティティ間マッピングのより一般的なコンテキストで必要とされる安全なマッピングメカニズムの性質については、未解決の疑問のままであり、マッピング機能が実行可能なエンドポイントにどのように関連するかについての未解決の問題でもあります。 - エンドポイントへの接続。アイデンティティの領域の一般的な側面は、領域の最も重要な側面は、アイデンティティの解像度の性質が他の属性空間に分解されることです。
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.
特定の制約の中で、マルチホミングは完全に異なる永続的なアイデンティティ空間のオーバーヘッドと関連するアイデンティティ解決機能を一般的に必要としないこと、およびこのコンテキストのマルチホーミング空間の性質がトークンを使用して、セッションの生存性のためにロケーターの等価性を効率的に検出できるようにし、一時的なアイデンティティが適切なメカニズムであると思われます。
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へ。
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.
別の一般的な問題は、ロケーターが実行可能であると見なされないポイントと、輸送セッションの状態への結果です。
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レイヤーは、ロケータースイッチのトリガーとして通知IDモジュールをリダイレクトする必要があります。
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-Link]が利用できないことを示します。このアプローチの制限は、リンクレベルの表示がネットワークブロードキャストイベントではなく、リンクのすぐに接続されたデバイスのみがリンク遷移信号を受信することです。このアプローチは、単一のホストで構成されるマルチホームサイトの退化したケースに関連する可能性がありますが、マルチホストサイトの場合、リンクの表示を使用する必要があります。ロケーターの変更のためにホストをトリガーするための上記の適応症。この場合、これはリンクステータスのルーター検出の従来の形式です。
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.
リモートエンドに使用するロケーターの選択は、ネットワークのトポロジの現在の状態によって明らかに制約されており、選択プロセスの主な目的は、パケットが目的の目的地ポイントに到達できるようにする実行可能なロケーターを選択することです。ソースロケーターの選択は、ローカルエンドに使用する優先ロケーターのリモートエンドの好みを示すことと見なすことができます。ただし、使用できる2つ以上の実行可能なロケーターがある場合、特定のロケーターの選択は、一連の追加の考慮事項の影響を受ける可能性があります。
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.
実行可能なロケーターセットから特定のロケーターを選択することは、他の実行可能なパスよりも優先される1つの特定のネットワークパスの選択を意味します。このホストベースのロケーター選択プロセスの意味は、パスの選択と、推論により、トラフィックエンジニアリング機能は、ネットワーク要素内の転送状態の調整によるパス操作のネットワークベースの操作に制約されていないことです。結果として、ロケーターの選択プロセスとトラフィックエンジニアリング機能の間には相互作用があります。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.
ホスト内のプロトコル要素として、またはサイトエキシットルーターで行われた選択としてロケーターの選択を実行する要素もトラフィックポリシーを決定するため、リモートパケットロケーターの書き換えまたはホストベースのロケーターの選択を使用する選択がポリシーをシフトしますある要素から他の要素への機能。
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?
これらの影響には、どのような状態が保持されているか、プロトコルスタックの要素、およびコンテキストのレベル（動的または固定、およびセッションごとまたはホストごと）の質問が含まれます。また、州の情報がどのように検出され、削除され、削除されているかなど、州の維持に関する考慮事項も含まれています。この機能をサポートするために、このアイデンティティ/ロケーターのバインディングを認識する必要があるのは1つのコードのみですか？もしそうなら、そのような変更はすべての輸送プロトコルで一般的ですか、または異なるプロトコルには、この機能の治療において異なる考慮事項が必要ですか？
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関数がトランスポートセッションにしっかりと関連付けられることを意味します。このアプローチでは、セッションの起動はID/ロケーターの初期バインディングアクションをトリガーでき、トランスポートプロトコルのタイムアウトはロケータースイッチアクションのトリガーとして使用できます。セッション終了は、ローカルID/ロケーターバインディング状態の有効期限をトリガーする可能性があります。セッションごとの日和見アイデンティティトークン値が使用されている場合、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.
この機能を輸送プロトコル層内に配置する潜在的な欠点の1つは、各輸送プロトコルがID機能の明確な実装を必要とする可能性があることです。これは、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.
別のアプローチは、プロトコルスタックのトランスポートレイヤーとインターネット層の間に配置された明確なプロトコル要素を使用することです。このアプローチの利点は、あらゆる形態の輸送プロトコルに対して、アイデンティティとロケーター間の一貫したマッピングを提供することです。ただし、このプロトコル要素はセッションを明示的に認識しておらず、そのようなマッピングが存在するかどうか、これがその一部であるかどうかに関係なく、後で輸送プロトコルから渡されたすべてのIDアドレスパケットの適切なID/ロケーターマッピングを発見する必要があります。セッションのコンテキスト、またはそのようなマッピングがいつ発見され、適用されるかを決定するためのシグナル伝達の追加メカニズムがあります。このレベルでは、特定の目的地へのすべてのフローが停止し、サポート状態で消費されるリソースがリリースされる場合の明示的なシグナルがないため、ID/ロケーターマッピング状態が不要になった場合の明示的な知識もありません。また、このようなプロトコル要素はトランスポートレベルのタイムアウトを認識していないため、IDプロトコルレベルでロケータースイッチをトリガーするには、トランスポートプロトコルに追加の機能を追加する必要があります。輸送プロトコル層を使用してセッションごとの状態を保存および操作するために、セッションごとの日和見的アイデンティティ構造のサポートは、この環境でより困難です。このレベルのプロトコルスタックでアイデンティティ要素を構築する際には、輸送プロトコル、インターネットプロトコル、およびアイデンティティプロトコル要素の間に適切な量の情報が渡されていることを確認する必要があるように思われます。アクティブセッションの現在の状態またはエンドツーエンドネットワークパスについて、おそらく不正確な仮定を行わせることを余儀なくされました。
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関数を埋め込むこともできます。前のセクションで述べたように、セッションごとの情報はアイデンティティモジュールでは容易に利用できないため、日和見的なセッションごとのアイデンティティ値は、このアプローチでサポートするのが難しいでしょう。また、ID/ロケーターの状態情報をいつ設定してリリースするかを判断することも困難です。また、ロケータースイッチトリガーとして輸送レベルのタイムアウトを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つのホスト間の初期接続を確立するために、エンドポイント識別子に関連付けられた少なくとも1つの初期ロケーターが必要です。このロケーターは、従来の方法で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.
アイデンティティが固定された検出可能な値ではなく、セッションのコンテキストで生成される値である場合に日和見的なアイデンティティが使用される場合、セッションの起動時に追加のアクションを実行する必要があります。この場合、セッションの確立に使用される定義されたロケーターの必要性はまだ必要ですが、次にセッションキーを生成し、これらの値を交換するために追加のステップが必要です。これにより、インバンドアプローチが使用されている場合、輸送プロトコル内の能力交換と追加の握手と関連するトークン価値交換の形をとるか、IDプロトコルのレベルで異なるプロトコル交換の形をとることがあります。要素は、輸送セッションから帯域外に実行されました。
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.
いくつかのアプローチは、さらに区別される可能性があります。つまり、初期セッションの確立のアプローチとセッション内の追加の共有状態の確立のアプローチは、複数のロケーターを共通のエンドポイントアイデンティティに縛られると扱われることを可能にします。このような追加のアクションをセッションスタートアップで実行することは厳密には必要ありませんが、選択した初期ロケーターのエンドツーエンド接続の損失の前にそのようなアクションを実行する必要があるため、この追加の状態の遅延交換は、接続の変化によりセッションの混乱のリスクを高めます。
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.
あるいは、パッシブエンドは最初に提供されたロケーターを使用し、これが成功した場合は、各スタックのIDモジュールに任せて情報を交換して、各端に現在の完全なロケーターセットを確立します。このアプローチは、通信のアクティブな端が、応答を受信またはロケーターセットを排出するまで、ソースアドレスとして、関連するすべてのロケーターを介してサイクリングする必要があることを意味します。もう一方の端がマルチホーム（したがって複数のロケーターがある）の場合、アクティブエンドは、各ソースロケーターのすべての可能な宛先ロケーターをサイクリングする必要があります。これにより、リモートエンドへのパスが存在しないことを確認するために時間が長くなる可能性がありますが、リモートエンドが大量のスプリアスに関与するように強制する可能性のあるサービス拒否攻撃に対する初期交換の特性を改善する可能性がありますロケータールックアップ。
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.
この方法で、この方法で1つの形式の機能を交渉できることは厳密に必要ではないというこの形式の交渉能力の結果です。特定のエンドポイントID/ロケーターマッピングスキームの採用がエンドポイント間のネゴシエーションの結果である場合、多くの可能なアプローチのいずれかを使用することを交渉することが可能です。使用されたアプローチとエンドポイントのアイデンティティの形式との間にはある程度の相互作用があり、エンドポイントID機能の交渉のあらゆる形態の許容可能な結果は、上位レベルのアプリケーションが引き続き動作し続けることができることに注意する必要があります。
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?
アイデンティティプロトコル要素は、セッションを識別する上位レベルのプロトコルのローカルおよびリモートアイデンティティトークンからマッピングを作成する必要がありますか？もしそうなら、この翻訳は最初のセッションパケット交換の握手の前または後に実行されますか？
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?
ID/ロケーターのバインディング状態の除去は、セッションの閉鎖と同期していますか？
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.
プロトコルスイートエンドポイントのIDとロケーターのアイデンティティ内で区別するアクションに起因する、かなりの数のセキュリティ上の考慮事項があります。
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.
著者は、ブライアン・カーペンター、クルティス・ランドクヴィスト、エリック・ノードマーク、イルジッチ・ヴァン・ベイニュム、マルセロ・バグヌロ、ジョン・ラフニー、ティエリー・エルンスト、ジョー・タッチ、マイケル・パットン、テッド・ハーディ、アリソン・マンキン。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten、T。およびR. Draves、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582] Eabley、J.、Black、B。、およびV. Gill、「IPv6サイト総構築の目標」、RFC 3582、2003年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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-link] Aboba、B.、ed。、「リンク層の表示の建築的意味」、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.、Reed、D。、およびD. Clark、「システム設計におけるエンドツーエンドの引数」、ACM TOCS Vol 2、Number 4、PP 277-288、1984年11月、<http：//web.mit.edu/saltzer/www/ publications/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.、Aura、T.、Montenegro、G。、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティデザイン背景」、2004年10月の作業。
[thinks] Lear, E., "Things MULTI6 Developers should think about", Work in Progress, January 2005.
[思考] Lear、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. Li、「IPv6マルチホミングソリューションに関連する脅威」、2005年1月、進行中の作業。
Author's Address
著者の連絡先
Geoff Huston APNIC
Geoff Huston Apnic
EMail: gih@apnic.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。