RFC4177 日本語訳
4177 Architectural Approaches to Multi-homing for IPv6. G. Huston. September 2005. (Format: TXT=95374 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Huston Request for Comments: 4177 APNIC Category: Informational September 2005
コメントを求めるワーキンググループG.ヒューストン要求をネットワークでつないでください: 4177年のAPNICカテゴリ: 情報の2005年9月
Architectural Approaches to Multi-homing for IPv6
IPv6のためのマルチホーミングへの建築アプローチ
Status of this Memo
この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)インターネット協会(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プロトコル群のマルチホーミングサポートの建築局面の分析を提供します。 この分析の目的はマルチホーミングへの様々な提案されたアプローチの分類に分類学を提供することです。 また、それは研究のこのドメインの一般相を特定して、また、マルチホーミングを支持することを意図する様々な建築拡大のさらなるいくつかの含意の探検を許すことができる枠組みを提供するこの運動の目的です。
Huston Informational [Page 1] RFC 4177 Multi6 Architecture September 2005
[1ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 マルチホーミングスペース. . . . . . . . . . . . . . . . . . . . 5 4。 機能的な目標と問題. . . . . . . . . . . . . 7 5。 マルチホーミング. . . . . . . . . . . . . . . . . . 7 5.1へのアプローチ。 マルチホーミング: ルート設定. . . . . . . . . . . . . . . . . 8 5.2。 マルチホーミング: 移動性. . . . . . . . . . . . . . . . . 9 5.3。 マルチホーミング: アイデンティティ問題. . . . . . . . . 12 5.4。 マルチホーミング: アイデンティティプロトコル要素. . . . . . . . 14 5.5。 マルチホーミング: 変更されたプロトコル要素. . . . . . . . 15 5.6。 変更されたサイト出口とホストの振舞い. . . . . . . . . 16 6。 終点のアイデンティティ. . . . . . . . . . . . . . . 17 6.1へのアプローチ。 終点アイデンティティ構造. . . . . . . . . . . . . . 18 6.2。 しつこくて、便宜主義的で、はかないアイデンティティ. . 20 6.3。 マルチホーミングアプローチ. . . . . . . 23 6.3.1のための共通の課題。 .2にロケータスイッチ. . . . . . . . . . 23 6.3の引き金となります。 ロケータ選択. . . . . . . . . . . . . . . 26 6.3.3。 アイデンティティ. . . . . . . . . . . . . . . 27 6.3.4を層にします。 セッション始動と維持. . . . . . . . 29 6.3.5。 ダイナミックな能力交渉. . . . . . . . . 31 6.3.6。 アイデンティティのユニークさと安定性. . . . . . . 31 7。 マルチホーミングアプローチ. . . . . 32 7.1の機能的な分解。 セッション状態. . . . . . . . . . . . . . . 32 7.2を設置します。 再の家へ帰りは.337.3の引き金となります。 再の家へ帰りロケータ組選択. . . . . . . . . . . . 33 7.4。 ロケータ変化. . . . . . . . . . . . . . . . . . . . . 34 7.5。 セッション状態. . . . . . . . . . . . . . . . 34 8の取り外し。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 34 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 34 10。 有益な参照. . . . . . . . . . . . . . . . . . . . 34
Huston Informational [Page 2] RFC 4177 Multi6 Architecture September 2005
[2ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
1. Introduction
1. 序論
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アプローチを参照しますが。
2. Terminology
2. 用語
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.
注意、-、ユニキャスト「ルート-可能」アドレスが外国リンクを訪問している間に可動のノードに関連づけた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.
通信員Node(CN)A同輩ノードはどのa可動のノードで交信しているか。 通信員ノードは、可動であるか、または静止しているかもしれません。
Endpoint
A term for the identity for a network host. This is normally
assumed to be a constant or long-lived association.
ネットワークホストのためのアイデンティティのための終点A用語。 通常、これは一定の、または、長命の協会であると思われます。
Endpoint Identity Protocol Stack Element (EIP)
An added element in a protocol stack model that explicitly manages
the association of locators to endpoints.
プロトコル・スタックの加えられた要素がそんなに明らかにモデル化する終点IdentityプロトコルStack Element(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.
ユニキャスト「ルート-可能」アドレスが可動のノードの本籍として使用される可動のノードに割り当てたホームAddress(HoA)。 可動のノードの家のリンクの中にこのアドレスはあります。 標準のIPルーティングメカニズムは可動のノードのホームアドレスのために家のリンクに運命づけられたパケットを届けるでしょう。 例えば、家のリンクの上に複数の家の接頭語があるとき、モバイルノードは複数のホームアドレスを持つことができます。
Huston Informational [Page 3] RFC 4177 Multi6 Architecture September 2005
[3ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
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.
考えられて、低レベルがプロトコルスタック・モデルでプロトコル層に比例して議定書の中で述べるLayerプロトコル(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.
ホームアドレスでまだ届いている間に別のものへの1個のリンクから接着点を変えることができるモバイルNode Aノード。
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.
1つ以上のトランジットプロバイダーがあるマルチHomed Site Aサイト。 「サイトマルチホーミング」がサイトをアレンジする習慣である、マルチ、家へ帰り、サイトが接続性サービスにトランジットプロバイダーのどれかを使用できるように。
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を使用することで自主的にネットワークを経営するサイトAn実体。
Site-Exit Router
A boundary router of the site that provides the site's interface
to one or more transit providers.
1つ以上のトランジットプロバイダーにサイトのインタフェースを提供するサイトのサイト出口Router A境界ルータ。
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.
そんなに直接サイトを操作するトランジットProvider Aプロバイダーが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.
考えられて、上側のレベルがプロトコル・スタックで議定書の中で述べる上側のLayerプロトコル(ULP)はプロトコル層に比例してモデル化します。 インターネット構造では、インターネットプロトコルのULPはトランスポート・プロトコルです、そして、トランスポート・プロトコルのULPはアプリケーション・プロトコルです。
Huston Informational [Page 4] RFC 4177 Multi6 Architecture September 2005
[4ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
3. The Multi-Homing Space
3. マルチホーミングスペース
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 | |
+-----------+
+ - - - - - - - - - - - - - - - - - - - - +
+------+ |リモート| | ホスト| | R| +------+ | + - - - - - - - - - - - + | インターネットの接続性| + - - - - - - - - - - - + / \ +---------+ +---------+ | ISP A| | ISP B| +---------+ +---------+ | 経路A| 経路B+--、--、--、--、--、--、--、--、--、--、--、--、--、--、--、--、--、--、--、--、+| マルチ| | | 家へ帰り、+------+ +------+ | サイト| サイト| | サイト| | | 出口| | 出口| | |ルータ| |ルータ| | | A| | B| | +------+ +------+ | | | | ローカル・サイトの接続性| | | +-----------+ | |マルチ、家へ帰り| | | ホスト| | +-----------+ + - - - - - - - - - - - - - - - - - - - - +
Figure 1: The Multi-Homed Domain
図1: マルチ、家へ帰り、ドメイン
The environment of multi-homing is intended to provide sufficient support to local hosts so as to allow local hosts to exchange IP packets with remote hosts, such that this exchange of packets is transparently supported across dynamic changes in connectivity. Session resilience implies that if a local multi-homed-aware host establishes an application session with the remote host using "Path
マルチホーミングの環境がローカル・ホストがリモートホストとIPパケットを交換するのを許容するために十分なサポートをローカル・ホストに提供することを意図します、パケットのこの交換が接続性でダイナミックな変化の向こう側に透明に支持されるように。 セッション弾力がローカルであるならそれを含意する、マルチ、意識していた状態で家へ帰る、ホストは「経路」を使用するリモートホストとのアプリケーションセッションを確立します。
Huston Informational [Page 5] RFC 4177 Multi6 Architecture September 2005
[5ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
A", and this path fails, the application session should be mapped across to "Path B" without requiring any application-visible re-establishment of the session. In other words, the application session should not be required to be explicitly aware of underlying path changes at the level of packet forwarding paths chosen by the network. Established sessions should survive dynamic changes in network-level reachability.
「A」、およびこの経路やり損ない、セッションの目に見えるアプリケーション再建を必要としないで、アプリケーションセッションは横切って「経路B」に写像されるべきです。 言い換えれば、ネットワークによって選ばれたパケット推進経路のレベルで明らかに基本的な経路変化を意識しているためにアプリケーションセッションを必要とするべきではありません。 確立したセッションはネットワークレベルの可到達性におけるダイナミックな変化を乗り切るべきです。
There are also considerations of providing mechanisms to support sustained site visibility to support session establishment. Sustained site visibility implies that external attempts to initiate a communication with hosts within the site will succeed as long as there is at least one viable path between the external host and the multi-homed site. This also implies that local attempts to initiate a communication with remote hosts should take into account the current connectivity state in undertaking locator selection and setting up initial locator sets.
セッション設立を支持するために持続しているサイト目に見えることを支持するために、提供メカニズムの問題もあります。 そして、持続しているサイト目に見えることが、外部のホストの間には、少なくともある実行可能な経路がある限り、サイトの中のホストとのコミュニケーションを開始する外部の試みが成功するのを含意する、マルチ、家へ帰り、サイト。 また、これは、リモートホストとのコミュニケーションを開始する地方の試みが仕事ロケータ選択と初期のロケータセットを設立する際に現在の接続性状態を考慮に入れるべきであるのを含意します。
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
この簡単なシナリオが基本的なマルチホーミング環境を例証することを意図します。 変化はトランジットの接続性の追加外部のプロバイダーをローカル・サイトに含むかもしれません。 複雑なサイト要件と規制そこではサイトが一様にすべての外部のトランジットプロバイダーに連結しないかもしれません。 同時であるというよりむしろ連続した外部のトランジットの可到達性。 リモートであるとのコミュニケーション、マルチ、家へ帰り、ホスト。 多方向コミュニケーション。 参考の文脈(第三者紹介)におけるホスト・アドレスの使用。 そして、経路選択への方針規制の賦課。 しかしながら、基本的な簡単なサイトマルチホーミングシナリオは、少佐を例証するために十分です。
Huston Informational [Page 6] RFC 4177 Multi6 Architecture September 2005
[6ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
architectural aspects of support for multi-homing, so this simple scenario will be used as the reference model for this analysis.
マルチホーミングのサポートの建築局面であり、したがって、この簡単なシナリオはこの分析に規範モデルとして使用されるでしょう。
4. Functional Goals and Considerations
4. 機能的な目標と問題
RFC 3582 [RFC3582] documents some goals that a multi-homing approach should attempt to address. These goals include:
RFC3582[RFC3582]はマルチホーミングアプローチが記述するのを試みるべきであるいくつかの目標を記録します。 これらの目標は:
* redundancy
* load sharing
* traffic engineering
* policy constraints
* simplicity of approach
* transport-layer survivability
* DNS compatibility
* packet filtering capability
* scaleability
* legacy compatibility
* アプローチ*トランスポート層生存性*DNS互換性*パケットフィルタリング能力*scaleability*遺産互換性の冗長*負荷分割法*交通工学*方針規制*簡単さ
The reader is referred to [RFC3582] for a complete description of each of these goals.
読者はそれぞれのこれらの目標の完全な記述について言及されます[RFC3582]。
In addition, [thinks] documents further considerations for IPv6 multi-homing. Again, the reader is referred to this document for the detailed enumeration of these considerations. The general topic areas considered in this study include:
さらに、[思います]ドキュメントはIPv6マルチホーミングのために問題を促進します。 一方、読者はこれらの問題の詳細な列挙のためのこのドキュメントを参照されます。 この研究で考えられた一般的な話題領域は:
* interaction with routing systems,
* aspects of a split between endpoint-identifier and forwarding
locator,
* changes to packets on the wire, and
* the interaction between names, endpoints, and the DNS.
* *ルーティングシステムとの相互作用、終点識別子と推進ロケータ、*の間の分裂の局面はワイヤ、および*で名前と、終点と、DNSとの相互作用をパケットに変えます。
In evaluating various approaches, further considerations also include:
様々なアプローチを評価することでは、さらなる問題は:も
* the role of helpers and agents in the approach,
* modifications to host behaviours,
* the required trust model to support the interactions, and
* the nature of potential vulnerabilities in the approach.
* アプローチにおけるアシスタントとエージェントの役割、ホストのふるまいへの*変更、*は相互作用を支持するためにモデル化されます、そして、必要が、信じる*はアプローチにおける潜在的脆弱性の本質をモデル化します。
5. Approaches to Multi-Homing
5. マルチホーミングへのアプローチ
There appear to be five generic forms of architectural approaches to this problem, namely:
5つの一般的な形式のこの問題への建築アプローチがあるように見える、すなわち:
Huston Informational [Page 7] RFC 4177 Multi6 Architecture September 2005
[7ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
Routing
Use the IPv4 multi-homing approach
IPv4マルチホーミングがアプローチするルート設定Use
Mobility
Use the IPv6 Mobility approach
移動性Use IPv6 Mobilityはアプローチします。
New Protocol Element
Insert a new element in the protocol stack that manages a
persistent identity for the session
新しいプロトコルElement Insertはセッションのために永続的なアイデンティティを管理するプロトコル・スタックの新しい要素です。
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
変更、aプロトコルElement Modifyの輸送か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
ソースベースの推進を含む様々なふるまいを許容する変更されたSite-出口Router/ローカルのHost相互作用Modifyサイト出口ルータの、そして、ローカルの転送システム、サイト出口手-offs、およびサイト出口ルータによるアドレスの書き直し
These approaches will be described in detail in the following sections.
これらのアプローチは以下のセクションで詳細に説明されるでしょう。
5.1. Multi-Homing: Routing
5.1. マルチホーミング: ルート設定
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つ、または、現在接続されない何らかの第三者プロバイダーから直接ローカル・サイトまで広告に掲載されたアドレス空間から得られたより特定のアドレス接頭語であるかもしれません。 あるいはまた、アドレス空間はProvider無党派スペースとしてRegionalインターネットRegistryからのダイレクト課題で入手された異なったあて先ブロックであるかもしれません。 ローカル・サイトの中の各ホストはサイトのアドレス接頭語から唯一宛てられます。
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
サイトへのすべてのトランジットプロバイダーが接頭語広告を受け入れる、マルチ、家へ帰り、グローバルに相互ドメイン経路指定テーブルにこの接頭語の位置して、広告を出してください。 ローカル・サイトと個々のトランジットプロバイダーの間の接続性であるときに、プロトコルがそれを確実にするルーティングの無くなっていて、通常の操作はルーティング広告ですか?
Huston Informational [Page 8] RFC 4177 Multi6 Architecture September 2005
[8ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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つの注目に値する例外に関するマルチホーミングアプローチのすべての目標を達成します: scaleability。 このファッションによるそんなにマルチホームのそれぞれのサイトはグローバルな相互ドメイン経路指定テーブルで一層のエントリーを加えます。 現在のルーティングと推進技術の規制の中では、これが人口を取り囲む缶のスケールにアプローチするのが、明確に明白でない、マルチ、家へ帰り、例えば、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つの目標(トランスポート層surviveability)がこのアプローチで潜在的に危険です。 ネットワークの中のダイナミックな変化は新しい安定した分散推進状態に一点に集めるルーティングシステムの引き金となります。 分配されたルーティングシステムの中の集合のこのプロセスは不確定の時かかること完成すると同様に不安定な一時的な推進が経路であると生成するネットワークを含むかもしれません。 用語によるこれは上側のレベルプロトコルタイムアウトと可能なセッションリセットの引き金となるかもしれません。
5.2. Multi-Homing: Mobility
5.2. マルチホーミング: 移動性
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.
動きで確立したコミュニケーションを保存するのが中に供給停止で確立したコミュニケーションを保存するのと同様である、マルチ、家へ帰り、両方のシナリオとしてのサイトはダイナミックにコミュニケーションの間に使用される維持している間、ロケータを変える能力を必要とします、変わりがありません、Upper Layerプロトコル(ULP)によって使用される終点識別子。 MIPv6プロトコル[RFC3775]が動きで確立したコミュニケーションを保存するために既に必要なサポートを提供するので、セッションの生存性を提供するのにそれを使用できたか否かに関係なくも、探検するために価値があるように見える、マルチ、家へ帰り、環境。
Huston Informational [Page 9] RFC 4177 Multi6 Architecture September 2005
[9ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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はモバイルノード(ミネソタ)に、安定した識別子として都合のよいIPアドレス、ホームAddress(HoA)を使用します。 次に、この識別子がダイナミックに有効なロケータに写像される、(注意、-、Address、CoA) それはネットワーク形態の中の現在の付着点に対応しています。 ミネソタがホームNetworkにあるとき、HoAはロケータとして識別子として使用されます。 ミネソタがホームNetworkにないとき、HoAは識別子として使用されます、そして、CoAはロケータとして使用されます。 ホームNetworkに置かれたリレーしているエージェント(ホームのエージェント)は、CoAによって指定された現在の位置にHoAに扱われたパケットを送るのに使用されます。 各動きの後に、ミネソタは、新しいCoAについてホームのエージェントに知らせて、任意に、それがコミュニケーション(通信員Nodes、またはCNs)を確立したそれらの実体を知らせなければなりません。 HoAと現在のCoAの間のマッピングは、Binding Update(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メッセージを交換するとき、拘束力がある情報を保護するのに使用できるプレ確立したSecurity Associationの存在を仮定するのは可能です。 しかしながら、ミネソタとCNの間でBUメッセージを交換するとき、そのようなSecurity Associationの存在を仮定するのは可能ではありません。 この場合、メッセージに含まれた拘束力がある情報を保護するために代替のメカニズムを採用するのが必要です。 選択されたメカニズムはReturn Routeability手順と呼ばれます、そして、デザインのためのバックグラウンドは[rosec]で詳細です。 メカニズムの目標はCNが、HoAが現在CoAに位置していると主張しているミネソタがそのようなクレームをする権利を与えられることを確かめるのを許容することです。 これは、HoAがミネソタに配属されて、ミネソタが現在CoAに位置していることを本質的には意味します。 これらのアップデートについて確かめるために、CNは2つの異なった秘密、要求されたHoAへの1、および要求されたCoAへの別の1つを行かせます。 ミネソタが両方の秘密を受け取るなら、これは、ホームNetworkに位置するホームのエージェントがミネソタとの信頼関係を持って、HoAに送られた秘密を転送して、ミネソタがCoAに送られたパケットを受けていることを意味します。 BUメッセージの中で両方の秘密から得られた認可情報を含んでいることによって、ミネソタは、HoAとCoAの間の要求された結合が有効であるとCNに立証できるでしょう。
The lifetime of the binding that is created in the CN using authorisation information obtained through the Return Routeability procedure is limited to 7 minutes, in order to prevent time-shifted attacks [rosec]. In a time-shifted attack, an attacker located along the path between the CN and the MN forges the Return Routeability packet exchange. The result of such an attack is that the CN will forward all the traffic addressed to the HoA to the CoA selected by the attacker. The attacker can then leave the position along the path, but the effects of the attack will remain until the binding is deleted, shifting in time the effect of the attack. By limiting the
CNでReturn Routeability手順で得られた認可情報を使用することで作成される結合の寿命は7分まで制限されます、時間で移行している攻撃[rosec]を防ぐために。 時間で移行している攻撃では、CNとミネソタの間の経路に沿って位置する攻撃者はReturn Routeabilityパケット交換を鍛造します。 そのような攻撃の結果はCNがHoAに扱われたすべてのトラフィックを攻撃者によって選択されたCoAに送るということです。 次に、攻撃者は経路に沿って位置を出ることができますが、結合が削除されるまで、攻撃の効果は残るでしょう、時間内に攻撃の効果を移行させて。 制限すること。
Huston Informational [Page 10] RFC 4177 Multi6 Architecture September 2005
[10ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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での結合の生涯、この攻撃の効果は7分まで減少します、新しいReturn Routeability手順がその期間の後に拘束力がある生涯を広げるのに必要であるので。 Return Routeability手順が「中央の男性」攻撃に被害を受け易いことに注意されるべきです、CNとミネソタの間の経路に沿って位置する攻撃者が周期的なReturn Routeabilityパケット交換を鍛造できるので。
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.
このシナリオでマルチ、家へ帰り、ホストが外にミネソタの役割とホストを採用する、マルチ、家へ帰り、サイトはCNの役割を採用します。 コミュニケーションがいつで確立されるか、マルチ、家へ帰り、ホストと外部のホスト、コミュニケーションを開始するのに使用されるアドレスはHoAとして使用されます。 コミュニケーションは、供給停止が全く起こらない限り、このアドレスを使用し続けています。 供給停止が起こるか、そして、HoAは手が届かなくなります、代替アドレス、マルチ、家へ帰り、ノードがCoAとして使用されます。 この場合、マルチ、家へ帰り、ノードはBUメッセージを外部のホストに送ります、HoAに使用されるために新しいCoAに関してそれを知らせて、代替アドレスを使用することで確立したコミュニケーションを保存できるように。 しかしながら、そのようなBUメッセージは、拘束力がある寿命が7分未満の一定期間まで制限されるのを含意するReturn Routeability手順で得られた認可情報を使用することで有効にされなければなりません。 結果はこの間隔が経過した後にHoAと新しいCoAの間の結合が期限が切れて、次に、HoAがコミュニケーションに使用されるということです。 HoAが供給停止のために手が届かないので、コミュニケーションは中断されるでしょう。 新しいReturn Routeability手順を実行することによって新しい認可情報を取得するのが可能でないことに注意されるべきです、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の局面はReturn Routeability手順です。 MIPv6では、アイデンティティの正当性は定期的にアイデンティティアドレスのリターンrouteabilityによってテストされます。 アイデンティティトークンがマルチホーミング文脈の経路の拡張失敗の場合、リターンの可到達性にそれをサポートすることができないので、顕著なロケータのこの定期的な使用はアイデンティティロケータに関連しています。
Huston Informational [Page 11] RFC 4177 Multi6 Architecture September 2005
[11ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
5.3. Multi-homing: Identity Considerations
5.3. マルチホーミング: アイデンティティ問題
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の例のネットワーク、地方、マルチ、家へ帰り、ホストは多分2つの方法で宛てられるでしょう: トランジットプロバイダービーズアドレス接頭語を使用することでトランジットプロバイダーAのアドレス接頭語ともう片方を使用する1つ。
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は、B接頭語を使用することでA接頭語ともう片方を使用することで2つのアドレス1つを返すでしょう。 リモートホストは、これらのアドレスの1つを選択して、この送付先アドレスにパケットを送るでしょう。 これはAかBを通して経路に沿ったローカル・ホストにパケットを向けるでしょう、選択されたアドレスによって。 ローカル・サイトとトランジットプロバイダーの間の経路が失敗すると、トランジットプロバイダーによって相互ドメインルーティングシステムに発表されたアドレス接頭語はずっとプロバイダーのアドレス接頭語になるでしょう。 リモートホストはルーティングにおける少しの変化も見ないでしょう、しかし、今、ローカル・ホストに送られたパケットは提供されないでしょう。 マルチホーミング問題によって提出された質問は以下の通りです。 「リモートホストがマルチホーミングを意識しているなら、どのように地方に同等なアドレスを使用するのに転換するかもしれないか、マルチ、家へ帰り、もう片方のプロバイダーを通過するホスト--、」
If the local multi-homed host wishes to initiate a session with remote host R, it needs to send a packet to R with a valid source and destination address. While the destination address is that of R, what source address should the local host use? There are two implications for this choice. Firstly, the remote host will, by default use this source address as the destination address in its response, and hence this choice of source address will direct the
地方である、マルチ、家へ帰り、リモートホストRとのセッションを開始するというホスト願望、それは有効なソースと送付先アドレスと共にパケットをRに送る必要があります。 送付先アドレスである間、R、ソースアドレスがそうするべきであることに関するそれはローカル・ホスト使用ですか? この選択のための2つの含意があります。 まず第一に、リモートホストは、デフォルトで望んでいて、応答における送付先アドレスとしてのこのソースアドレスを使用して、したがって、アドレスが指示するソースのこの選択を使用します。
Huston Informational [Page 12] RFC 4177 Multi6 Architecture September 2005
[12ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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からローカル・ホストまで経路を逆にしてください。 第二に、ISP AとBはソースの上でISPに通過されたパケットのアドレスをフィルターにかける何らかのフォームの逆のユニキャストアドレスを使用しているかもしれません、ソースアドレススプーフィングを防ぐ手段として。 これがそれを含意する、マルチ、家へ帰り、アドレスはアドレス接頭語Aからのソースアドレスを選択して、RへのローカルのルーティングはISP Bで最も良い経路を選択して、次に、ISPビーズイングレスフィルタはパケットを捨てるでしょう。
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で外部のルーティング同輩に作ったルートにありません。 マルチ、家へ帰り、サイトはISP Bでずっと届いていて、ISP Aの接頭語を使用することでサイトに向けられたパケットはISP Aによって捨てられるでしょう、目的地が手が届かないときに。 ローカル・ホストがそのようなイベントの向こう側にセッションを維持したいなら送付先アドレスに切り替わるのが可能であるリモートホストRに交信するのが必要であるという含意がここにある、マルチ、家へ帰り、ISPビーズアドレス接頭語に基づいているホスト。 ローカル・ホストが次に、それが唯一の実行可能な目的地が扱う状況を反映する初期のソースロケータを使用するのにここに使用する必要があるかもしれないセッションを開始したいと思う場合、ISPビーズに基づいているのはアドレス接頭語ですか? それは、ローカル・ホストがこのリターンrouteability規制を意識していないのが、事実であるかもしれないか直接R、その場合発見するRの必要性にこの情報を伝えることができませんし、他の方法でこの情報を通過できないかもしれません。
In an aggregated routing environment, multiple transit paths to a host imply multiple address prefixes for the host, where each possible transit path is identified by an address for the host. The implication of this constraint on multi-homing is that paths being passed to the local multi-homed site via transit provider ISP A must use a forwarding-level destination IP address drawn from ISP A's advertised address prefix set that maps to the multi-homed host. Equally, packets being passed via the transit of ISP B must use a destination address drawn from ISP B's address prefix set. The further implication here is that path selection (ISP A vs. ISP B transit for incoming packets) is an outcome of the process of selecting an address for the destination host.
集められたルーティング環境で、ホストへの複数のトランジット経路がホストにとって複数のアドレス接頭語を含意します。そこでは、それぞれの可能なトランジット経路がホストのためにアドレスによって特定されます。 マルチホーミングにおけるこの規制の含意がローカルに渡されるその経路である、マルチ、家へ帰り、トランジットプロバイダーISP A必須使用でAの広告を出しているアドレス接頭語がその地図を設定したISPから得られた推進レベル送付先IPアドレスを位置させてください、マルチ、家へ帰り、ホスト。 等しく、ISP Bのトランジットで通過されるパケットはISPビーズアドレス接頭語セットから得られた送付先アドレスを使用しなければなりません。 経路選択(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アドレスによって使用される同じアイデンティティであるという仮定が従来のIPプロトコルアーキテクチャでされるということです。
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
そして、複数の推進経路がただ一つの輸送セッションのためにサポートされるかどうかことであり、経路選択が輸送セッション開始の機能から衝撃を吸収されるかどうかことであり、メインテナンス
Huston Informational [Page 13] RFC 4177 Multi6 Architecture September 2005
[13ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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アドレスの意味論で根本的変化です。 推進層がダイナミックにセッションの操作のときに影響を与えないで経路と関連終点ロケータのアイデンティティを変えるのを許容している間、プロトコルアーキテクチャにおけるこの変化は、輸送セッションがセッションを開始して、維持するのに不変な終点アイデンティティ価値を使用することを許可するでしょう。 アイデンティティとロケータの概念のそのようなデカップリングは相互ドメインルーティングシステムにどんな増分ロードも追加しないでしょう。
Some generic approaches to this form of separation of endpoint identity and locator value are described in the following sections.
いくつかの一般的方法が以下のセクションでこの形式の終点のアイデンティティとロケータ価値の分離に説明されます。
5.4. Multi-homing: Identity Protocol Element
5.4. マルチホーミング: アイデンティティプロトコル要素
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
新しいプロトコル・スタック要素(ここに、「終点アイデンティティプロトコル・スタック要素」、またはEIPを呼ぶ)の操作はリモート対応者と共に連動した状態を設置するでしょう。 これで、スタック要素はセッションの文脈の中で使用されるかもしれない1セットのロケータを交換できるでしょう。 現在の終点アイデンティティ価値とロケータの間の局所束縛における変化は推進レベルパケットのヘッダーで使用されるソースロケータ価値を変えるでしょう。 新しさがあるこのパケットを受け取り次第リモートEIPの機能
Huston Informational [Page 14] RFC 4177 Multi6 Architecture September 2005
[14ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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.
ロケータは既存のセッションの一部としてこのロケータを認識することになっています、そして、何らかの引き金の状態では、リモート終点のアイデンティティに関するマッピングに関するセッション意見を対応するロケータに変えて、目的地ロケータとしてその後のパケットでこのロケータを使用するのは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かインターネットワーク層がロケータを使用することで機能するでしょう、そして、終点識別子からロケータまでのマッピングはEIPスタック要素の中で引き受けられます。
5.5. Multi-homing: Modified Protocol Element
5.5. マルチホーミング: 変更されたプロトコル要素
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.
トランスポート層の中では、例えば、1セットのロケータを縛ることによってただ一つのセッションまで実現できて、次にこのロケータを伝えるこの機能性がリモート輸送実体にセットしました。 これで、ローカル運送実体は地方の終点か遠く離れた終点のどちらかのために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
IPレベルの中では、それがプロトコル要素によって処理されるとき、パケットのヘッダーのダイナミックな書き直しのフォームはこの機能性をサポートすることができました。 同等な終点識別子が両方の分野にある状態で、ソースがある入って来るパケットとパケットのヘッダーの目的地ロケータはパケットに写像されます、そして、逆のマッピングはトランスポート層から通過された出発しているパケットに実行されます。 パケットのヘッダーのダイレクト書き直しをサポートするメカニズムはこのアプローチで有力候補です。 他の可能性
Huston Informational [Page 15] RFC 4177 Multi6 Architecture September 2005
[15ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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.
候補はカプセル化を使用する様々なフォームのパケットのヘッダー変換です、オリジナルの終点識別子パケットのヘッダーがパケットに保存されて、インターネットプロトコル・スタック要素を通り抜けるとき外側のレベルロケータパケットのヘッダーがパケットに巻きつけられるところで。
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)層で加えられるなら、能動輸送セッションの文脈が全くありません、終えられたセッションのためのアイデンティティ/ロケータ州の情報の取り外しが、何らかの追加メカニズムによってトランスポート層からインターネットワーキング層まで引き起こされる必要があるように。
5.6. Modified Site-Exit and Host Behaviors
5.6. 変更されたサイト出口とホストの振舞い
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.
すべてが仮定するホストが明らかに意識している上のアプローチ、マルチ、家へ帰り、環境と使用は、マルチホーミングの機能性をサポートするようにプロトコルのふるまいを変更しました。 この目的へのさらなるアプローチは、多くのネットワーク要素の向こう側にこの機能性を分けて、遠隔点で潜在的に永続的な終点アイデンティティ価値からロケータ値までのパケットのヘッダーの書き直しを実行することです。
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.
リモートネットワークで要素を書き直しているパケットのヘッダーが多くの関連セキュリティ問題を持っています。 メカニズムを書き直すどんなパケットも[脅威]で説明された攻撃と、特にリダイレクション攻撃に対する適切な保護を提供しなければなりません。
Huston Informational [Page 16] RFC 4177 Multi6 Architecture September 2005
[16ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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.Theseアプローチに通過されるという終端効果を伴うすべてがソースアドレスルーティングとサイト出口ルータの間のルーティング情報の増大と同じくらい良くてローカルのサイト出口ルータ引き渡しメカニズムのフォームを含んでいる、マルチ、家へ帰り、ホスト; リモートホストのためのローカル・ホストによるロケータの選択がローカル・サイトがリモートホストに届く現在の地方のルーティング状態と一致しているように。
6. Approaches to Endpoint Identity
6. 終点のアイデンティティへのアプローチ
Both the approach of the addition of an identity protocol element and the approach of modification of an existing protocol element assume some form of exchange of information that allows both parties to the communication to be aware of the other party's endpoint identity and the associated mapping to locators. There are a number of possible approaches for implementing this information exchange.
アイデンティティプロトコル要素の追加のアプローチと既存のプロトコル要素の変更のアプローチの両方が、コミュニケーションに双方を許容する何らかの形式の情報交換が相手の終点のアイデンティティと関連マッピングをロケータに意識していると仮定します。 この情報交換を実装するための多くの可能なアプローチがあります。
The first such possible approach, termed here a "conventional" approach, encapsulates the protocol data unit (PDU) passed from the ULP with additional data elements that specifically refer to the function of the EIP. The compound data element is passed to the LLP as its PDU. The corresponding actions on receipt of a PDU from a LLP is to extract the fields of the data unit that correspond to the EIP function, and pass the remainder of the PDU to the ULP. The EIP operates in an "in-band" mode, communicating with its remote peer entity through additional information wrapped around the ULP PDU. This is equivalent to generic tunnelling approaches where the outer encapsulation of the transmitted packet contains location address information, while the next-level packet header contains information that is to be exposed and used at the location endpoints and, in this case, is identity information.
明確にEIPの機能について言及する追加データ要素に応じて、「従来」がアプローチして、プロトコルデータ単位(PDU)であるとカプセル化する最初に、そのような可能なアプローチであって、ここの呼ばれるのはULPから変化しました。 合成データ要素は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
別のアプローチはEIPが交信するのをEIPが同輩EIPに向けられるひたむきなメッセージを生成して、それがEIPに渡されるPDUsの如何にかかわらずこれらのPDUsをLLPに渡すところで別々のコミュニケーションチャンネルを使用することで許容することです。
Huston Informational [Page 17] RFC 4177 Multi6 Architecture September 2005
[17ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
ULP. This allows an EIP to exchange information and synchronise state with the remote EIP semi-independently of the ULP protocol exchange. As one part of the EIP function is to transform the ULP PDU to include locator information, there is an associated requirement to ensure that the EIP peering state remains synchronised to the exchange of ULP PDUs, so that the remote EIP can correctly recognise the locator-to-endpoint mapping for each active session.
ULP。 の如何にかかわらず、これが許容する、情報交換して、連動するEIPがリモートでEIPを述べる、準、ULPは交換について議定書の中で述べます。 EIP機能の一部がロケータ情報を含むようにULP PDUを変えることになっているとき、EIPのじっと見ている州の残りがULP PDUsの交換に連動したのを保証するという関連要件があります、リモート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.
ここでの別のポテンシャル法は終点からロケータへのマッピングが第三者によって保持されるのを許容することです。 名前からIPへのマッピングがすなわち、第三者、DNSレゾルバについての言及で得られるドメインネームシステム(DNS)によって実行されたアドレス・マッピングを支持するのに既にこのモデルを使用しました。DNSの使用か同様の第三者参考のメカニズムを通して終点とロケータセットの間の同様のフォームに関する第三者マッピングを支持できました。 むしろ、このアプローチはDNS Endpointからロケータへのセット例えば、DNS Resource Recordsとして含まれた地図のためのルックアップの結果、各当事者交換終点からロケータへのマッピングを持っているよりこのマッピングを得るでしょう。
6.1. Endpoint Identity Structure
6.1. 終点アイデンティティ構造
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つの可能なフォームは基本的なプロトコルの「アドレス空間」から持ち上げられたアイデンティティ象徴の使用です。 言い換えれば、終点のアイデンティティはIPv6プロトコルアドレスの特別なケース例です。 このフォームの終点のアイデンティティを使用するのにおいて多くの利点があります、IPプロトコルと関連するアプリケーションの一組が既にIPアドレスを操るので。 終点のアイデンティティとロケータを見分けるドメインの本質的な相違はプロトコルの終点のアイデンティティ部分が終点のアイデンティティの役割を引き受けるそれらのアドレスを作動させて、終点アイデンティティ/ロケータマッピング機能が終点「アドレス」から潜在的1セットのロケータ「アドレス」までマッピングを引き受けるだろうということです。 また、それはロケータ「アドレス」から顕著な「アドレス」という終点識別子まで逆のマッピングを引き受けるでしょう。 適当に効率的なマッピングが両方の方向に実行されることを許可して、IPアドレス空間は階層的で構造化されます。 公共のネットワークの文脈のアドレスの基本的な意味論は終点アイデンティティ象徴値のグローバルなユニークさの必要な問題を含んでいます。
Huston Informational [Page 18] RFC 4177 Multi6 Architecture September 2005
[18ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
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.
アドレスでフォーマットされた識別子のための代替的アプローチはグローバルなユニキャストロケータスペースの一部でない顕著なアイデンティティアドレス値を使用することです、アプリケーションとプロトコル要素が終点アイデンティティ値とアドレス接頭語価値に基づくロケータを見分けるのを許容して。
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.
アイデンティティ値がプロトコルのアドレス空間から得ることであるなら、基本的な選択がロケータとアイデンティティの両方としてアドレス空間の異なった部分かaが区別した使用かホームアドレスにこれらのアイデンティティ値を引くことであるように見えるでしょう。 この後者のオプション(プロバイダーの集められたアドレス分配構造に結びつけられると終点のアイデンティティの基礎としてロケータの上でロケータを使用するもの)がaに通じる、マルチ、家へ帰り、一般的なアイデンティティ接頭語としてプロバイダーベースのアドレス接頭語を使用するサイト。 文脈のロケータアドレス、aがシングル家へ帰った、ネットワーク、プロバイダーの接続性の変化がアイデンティティに横切って番号を付け替えさせる結果を含意する、マルチ、家へ帰り、サイト。 そのような無理矢理の番号を付け替えることを避けるのが、ここの目標であるなら、ネットワーク形態に並べられないプールからアイデンティティ象徴を得るのにおいて優先があるでしょう。 これは、ロケータアドレス空間から得られないアイデンティティ象徴値を使用するためにこのセクターから優先を示すかもしれません。
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
また、終点のアイデンティティとして完全修飾ドメイン名(FQDN)を使用するのも可能です、上で説明されるように同様のマッピングを引き受けて、ルックアップ「キー」としてFQDNを使用して。 含意は終点識別子に関連しているどんなデフォルト「アドレス」もないということです、セッション設立の文脈でFQDNを使用できて、1セットの初期のロケータを証明するのにDNS質問を使用できるとき。 もちろん、また、それがそこでそうしないかもしれないのは、ケースです。
Huston Informational [Page 19] RFC 4177 Multi6 Architecture September 2005
[19ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
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に関連していて、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つの異なったアイデンティティ分野の構文の特性に、明白な問題がこれらのアイデンティティがPDUsの中で使用されるかもしれない方法であります。
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.
終点のアイデンティティからロケータセットまでマッピングを得るためにルックアップキーの役目も兼ねる構造化された象徴の代わりに代替手段が不統一な象徴スペースを使用することである、マルチ、家へ帰り、セッション文脈。そこでは、個々の象徴値が使用のためにaの中に便宜主義的に描かれます。 そのような不統一な象徴が限られた文脈で使用されるなら、終点のアイデンティティの意味論はかすかに変えられます。 終点のアイデンティティは、終点のアイデンティティのしつこい別名でない、また参照ではありませんが、それはアイデンティティプロトコル要素が、2つのロケータが遠く離れた終点のときに予定された同じ写像しているロケータの一部であると確認するのを許容する手段です。 このような関係においては、不統一な便宜主義的な終点識別子値は何らかのフォームのルックアップ関数でというよりむしろロケータの等価性を決定する際に使用されます。
6.2. Persistent, Opportunistic, and Ephemeral Identities
6.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
1つのフォームがしつこいアイデンティティ分野を使用します、連続したセッションと同様に同時発生のセッションを支持して。(分野で、同じアイデンティティ値がこのフォームのアイデンティティが必要であるすべての文脈で使用されると推論されます)。 このフォームのアイデンティティが基本的な接続性で時間と変化の上で一定のままで残っていることを意図します。 また、このアイデンティティがネットワーク形態と完全に異なっているのは、事実であるかもしれません、同じアイデンティティがサイトとホストによって使用された現在の接続性とロケータアドレシングの如何にかかわらず使用されるように。 この場合、アイデンティティはしつこいです、そして、終点スタックの参照としてアイデンティティ値は使用できます。 これはマルチパーティ紹介、どこを支持するか。
Huston Informational [Page 20] RFC 4177 Multi6 Architecture September 2005
[20ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
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.
パーティーAとBはコミュニケーションを確立して、BはAのアイデンティティを第三者Cに渡すことができます。(次に、その第三者は、コミュニケーションをAに確立することにおける活動的なパーティーになるのにこのアイデンティティ値を使用できます)。
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.
しつこい識別子がセッションを開始するのに使用されることであるなら、アイデンティティは1セットの特定された終点に関連しているロケータを証明するために主要なルックアップとして使用されます。 このルックアップ機能が決定論で、信頼できて、強健で、効率的で、「信用-可能」であることは、望ましいです。 この含意は唯一そのようなアイデンティティを割り当てなければならなくて、アイデンティティシステムの経験が象徴の部品の内部の階層構造を持っている構造化されたアイデンティティ象徴スペースのための強い優先を示すということです。 これらのアイデンティティの特性に、ユニキャストアドレスとドメイン名のものがある重要な共通点があります。 また、しつこい構造化されたアイデンティティがそれらの保全とユーティリティを保持するために秩序立っている分配と管理メカニズムの採用に依存するというさらなる含意はここにあります。 一般に、そのようなメカニズムは管理業務に関して重要なオーバーヘッドを含意します。
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.
前項で注意されるように、選択方式のアイデンティティは不統一なアイデンティティスペースです。(そこでは、特定の値がスペースから便宜主義的に得られます)。 この場合、どんな特定のアイデンティティ価値のユニークさも確実にされません。 また、ロケータを証明するために主要なルックアップのようなアイデンティティの使用は変更されます、スペースの不統一な本質にはルックアップの効率に関連する意味があって、ルックアップの信憑性がアイデンティティキー値をユニークさに保証できないことのため弱められるとき。 不統一なアイデンティティへの保守的なアプローチはそれらの1セッションあたりのアイデンティティキーなどのユーティリティの範囲を制限します。 このシナリオでは、選択されたアイデンティティの範囲は交信しているパーティーに制限されます、そして、範囲はコミュニケーションセッションの持続時間に制限されます。 この制限の含意はアイデンティティが複数のロケータが制限されているのをセッションまで許容するためにポイントを縛るセッションレベルであるということです、そして、セッションの文脈を超えた終点の参照としてアイデンティティは使用できません。 明らかに限られた範囲があるそのような便宜主義的なアイデンティティは象徴分配と管理のどんな秩序立っているメカニズムの採用も必要としません。
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
別のフォームのアイデンティティはセッションのアイデンティティが終点の間の共有された状態であるところでアイデンティティキーの役割を果たす特定の象徴値の交換なしで確立されたはかないフォームです。 これは定義されたロケータセットの形か例えば、何らかのセットのセッションの共用属性から得られたセッションキーの形を取るかもしれません。 この状況に、セッションを開始する手段として識別子の参照か使用のフォームが全くありません。 はかないアイデンティティ値には、意味を確かに決定するために各端を許容することに関して非常に限られた役割があります。
Huston Informational [Page 21] RFC 4177 Multi6 Architecture September 2005
[21ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
equivalence of a set of locators within the context of membership of a particular session.
特定のセッションの会員資格の文脈の中の1セットのロケータの等価性。
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つのフォームが管理オーバーヘッドを最小とならせて、範囲でセッション保全を支持するのに制限されるメカニズムを提供するアイデンティティへのアプローチを表します。 これは、他の文脈と遠く離れた終点とのコミュニケーションセッションを開始する紹介、アプリケーションのデータペイロード、またはキーなどのプロトコル・スタックの他のレベルにおける、アイデンティティ機能のサポートが、ある他のアイデンティティ機能によって支持される必要であるのを含意します。 そのような1セッションあたりの限られた範囲のアイデンティティは、関連マルチホーミングアプローチがセッション始動に既存のメカニズムを使用しなければならないのを含意します、そして、セッションベースのアイデンティティと関連ロケータスイッチの機敏さの採用は交渉されたセッション能力になります。
On the other hand, the use of a persistent identity as a session initiation key implies that identity is part of the established session state, and locator agility can be an associated attribute of the session rather than a subsequent negotiated capability. In a heterogeneous environment where such identity capability is not uniformly deployed, this would imply that if a session cannot be established with a split identity/locator binding, the application should be able to back off to a conventional session startup by mapping the identity to a specific locator value and initiating a session using such a value. The reason why the application may want to be aware of this distinction is that if the application wishes to use self-referential mechanisms within the application payload, it would appear to be appropriate to use an identity-based self- reference only in the context of a session where the remote party was aware of the semantic properties of this referential tag.
他方では、セッション開始キーがそのアイデンティティを含意するとき、しつこいアイデンティティの使用は設立されたセッション状態の一部です、そして、ロケータの機敏さはその後の交渉された能力よりむしろセッションの関連属性であるかもしれません。 異機種混在環境では、そのようなアイデンティティ能力が一様に配備されないところでこれは、分裂アイデンティティ/ロケータが付いていてセッションを確立できないなら、アプリケーションが特定のロケータ値へのアイデンティティを写像して、そのような値を使用することでセッションを開始することによって従来のセッション始動に引き返すことができるべきであるのを含意するでしょう。 アプリケーションがこの区別が意識するようになりたがっているかもしれない理由はアプリケーションがアプリケーションペイロードの中に自己参考のメカニズムを使用したいと思うなら、リモートパーティーがこの参考のタグの意味特性を意識していたセッションの文脈だけにおけるアイデンティティベースの自己参照を使用するのが適切であるように見えるだろうということです。
In terms of functionality and semantics, opportunistic identities form a superset of ephemeral identities, although their implementation is significantly different. Persistent identities support a superset of the functionality of opportunistic identities, and again the implementations will differ.
機能性と意味論に関して、彼らの実現はかなり異なっていますが、便宜主義的なアイデンティティははかないアイデンティティのスーパーセットを形成します。 しつこいアイデンティティは便宜主義的なアイデンティティの機能性のスーパーセットを支持します、そして、一方、実現は異なるでしょう。
In the context of support for multi-homing configurations, use of ephemeral identities in the context of locator equivalence appears to represent a viable approach that allows a negotiated use of multiple locators within the context of communication between a pair of hosts in most contexts of multi-homing. However, ephemeral identities offer little more in terms of functionality. They cannot be used in referential contexts, cannot be used to initiate communications, provide limited means of support for various forms of mobility, and impose some constraints on the class of multi-homed scenarios that can be supported. Ephemeral identities are generated in the context
マルチホーミング構成のサポートの文脈では、ロケータの等価性の文脈におけるはかないアイデンティティの使用はマルチホーミングのほとんどの文脈の1組のホストのコミュニケーションの文脈の中の複数のロケータの交渉された使用を許す実行可能なアプローチを表すように見えます。 しかしながら、はかないアイデンティティは機能性に関して少ししかさらに提供しません。 彼らが参考の文脈で使用できないで、開始コミュニケーションに使用されて、様々なフォームの移動性のサポートの小資本を提供して、いくつかの規制をクラスに課すことができない、マルチ、家へ帰り、支持できるシナリオ。 はかないアイデンティティは文脈で発生します。
Huston Informational [Page 22] RFC 4177 Multi6 Architecture September 2005
[22ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
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.
マルチホーミングが、ある規制の中で一般的に完全に異なったしつこいアイデンティティスペースと関連アイデンティティ解決の機能性のオーバーヘッドを必要としないのを観測するのが妥当に見えて、はかないアイデンティティはこの文脈のマルチホーミングスペースの本質がセッションsurviveabilityのためにロケータの等価性の効率的な検出を許すのに象徴を使用することであるなら適切なメカニズムであるように見えます。
6.3. Common Issues for Multi-Homing Approaches
6.3. マルチホーミングアプローチのための共通の課題
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.
しかしながら、すべてのアプローチの向こう側に一般的であるように見える1セットの問題があります。 それらはこのセクションの詳細で調べられます。
6.3.1. Triggering Locator Switches
6.3.1. ロケータスイッチの引き金となります。
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
世代の方法にかかわらず結局ローカルから発生するパケット、マルチ、家へ帰り、それがトランジットネットワークに通過されるとき、リモートホストのホストはソースロケータを運ばなければなりません。 a、マルチ、家へ帰り、状況、地方、マルチ、家へ帰り、ホストはほとんどあらゆる点で同等な別名である多くの自己参考のロケータを持っています。 ロケータの違いが推論である、それ
Huston Informational [Page 23] RFC 4177 Multi6 Architecture September 2005
[23ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
the remote end, the choice of locator may determine the path used to send a packet back to the local multi-homed host. The issue here is: how does the local host make a selection of the "best" source locator to use? Obviously, an objective is to select a locator that represents a currently viable path from the remote host to the local multi-homed host. Local routing information for the multi-homed host does not include this reverse path information. Equally, the local host does not necessarily know any additional policy constraints that apply to the remote host and that may result in a remote host's preference to use one locator over another for the local host. Considerations of unicast reverse-path forwarding filters also indicate that the selection of a source locator should result in the packet being passed to a site-exit router that is connected to the associated ISP transit provider, and that the site-exit router passes the packet to the associated ISP.
リモートエンド、ロケータの選択が経路が以前はよくパケットを地方に送り返していたことを決定するかもしれない、マルチ、家へ帰り、ホスト。 ここの問題は以下の通りです。 ローカル・ホストはどのように使用する「最も良い」ソースロケータの選択をしますか? 明らかに、目的がリモートホストから地方のホストまで現在実行可能な経路を表すロケータを選択することである、マルチ、家へ帰り、ホスト。 地方、情報を発送する、マルチ、家へ帰り、ホストはこの逆の経路情報を入れません。 等しく、ローカル・ホストは、ローカル・ホストに別のものの上で1つのロケータを使用するために、必ず、リモートホストに適用してください。そうすれば、それがリモートホストの好みをもたらしてもよいという少しの追加方針規制も知っているというわけではありません。 また、ユニキャスト逆経路推進フィルタの問題は、ソースロケータの選択が関連ISPトランジットプロバイダーに関連づけられるサイト出口ルータに通過されるパケットをもたらすべきであり、サイト出口ルータが関連ISPにパケットを通過するのを示します。
If the local multi-homed host is communicating with a remote multi-homed host, the local host may have some discretion in the choice of a destination locator. The considerations relating to the selection of a destination locator include considerations of local routing state (to ensure that the chosen destination locator reflects a viable path to the remote endpoint) and policy constraints that may determine a "best" path to the remote endpoint. It may also be the case that the source address selection should be considered in relation to the destination locator selection.
地方である、マルチ、家へ帰り、aがリモートな状態でホストが交信する予定である、マルチ、家へ帰り、ホスト、ローカル・ホストには、目的地ロケータの選択における何らかの思慮深さがあるかもしれません。 目的地ロケータの選択に関連する問題は地方のルーティング州(選ばれた目的地ロケータが実行可能な経路を遠く離れた終点に反映するのを保証する)と「最も良い」経路を遠く離れた終点に決定するかもしれない方針規制の問題を含んでいます。 また、ソースアドレス選択が目的地ロケータ選択と関連して考えられるべきであるのは、事実であるかもしれません。
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 Destination Unreachableパケットを発生させるかもしれません。 セッション失敗のインディケータとしてこの信号を輸送レベルに送るよりむしろ、IP層はロケータスイッチのための引き金として通知アイデンティティモジュールを向け直すはずです。
Huston Informational [Page 24] RFC 4177 Multi6 Architecture September 2005
[24ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
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-リンク]の使用不能を示します)。 このアプローチの制限はリンク・レベル指示がネットワーク放送イベントでなく、リンクだけのすぐに接続された装置がリンク変遷信号を受信するということです。 このアプローチがaの堕落したケースに関連しているかもしれない、マルチ、家へ帰り、サイトは、ホストがロケータ変化のために引き起こされるために上の指摘の1つを発生させるようにリンク指示がサイト出口ルータによって使用されるために必要とするマルチホストサイトの場合で独身のホストで構成されました。 この場合、これは伝統的な形式のリンク状態のルータ検出です。
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
輸送スタック要素とロケータプール管理スタック要素の間には、内部の合図メカニズムがある状態で、この問題はモデルによって一部解決されているだけです、非失敗のために
Huston Informational [Page 25] RFC 4177 Multi6 Architecture September 2005
[25ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
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によって確立される予約とのセッションに関するケースを考えてください。(その時、ルーティング変化はちょうど経路に沿った多くの要素の予約状態に適応型のアップデートを引き起こしました)。 経路を使用するトランスポート・プロトコルはいくつかの遅れかタイムアウトを見そうです、そして、これらの出来事への反応はロケータ変化のための引き金であるかもしれません。(それは、別の予約アップデートを意味しそうです)。 予約アップデートのこの推論は高いオーバーヘッドを表すかもしれません。 個々のトランスポート・プロトコルがそれらがロケータ変化引き金として与えるどんなフィードバックも調整しなければならないかもしれないという含意がここにあります、彼らがロケータ変化引き金で、あるフォームの一時的なルーティング変化遅れ(それらの原因を知らない)に応じないように。 また、異なったトランスポート・プロトコルには管理のためのかなり異なった振舞いとフックがあることに注意されるべきです。
6.3.2. Locator Selection
6.3.2. ロケータ選択
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つ以上の実行可能なロケータがあるところでは、特定のロケータの選択は1セットの追加問題によって影響を及ぼされるかもしれません。
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つの特定のネットワーク経路を含意します。 このホストベースのロケータ選択の過程の含意はその経路選択です、そして、推論で、交通工学機能はネットワーク要素の中で推進状態の調整による経路操作のネットワークベースの操作に抑制されません。 ロケータ選択の過程と交通工学機能との結果の相互作用があります。 アドレス選択方針テーブルのRFC3484[RFC3484]で説明される使用は選択の過程に関連しています。
The element that performs the locator selection, either as a protocol element within the host or as a selection undertaken at a site-exit router, also determines traffic policy, so the choice of using remote packet locator rewriting or host based locator selection shifts the policy capability from one element to the other.
また、ホストの中のプロトコル要素として、または、サイト出口ルータで引き受けられた選択としてロケータ選択を実行する要素が交通方針を決定するので、リモートパケットロケータ書き直しているかホストに基づいているロケータ選択を使用することの選択は1つの要素からもう片方に方針能力を移行させます。
If hosts perform this policy determination, then a more fine-grained outcome may be achievable, particularly if the anticipated traffic characteristics of the application can be signalled to the locator
ホストがこの方針決断を実行するなら、きめ細かにより粒状の結果は達成可能であるかもしれません、特にアプリケーションの予期された交通の特性にロケータに合図できるなら
Huston Informational [Page 26] RFC 4177 Multi6 Architecture September 2005
[26ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
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.
後者の場合には、ホストがネットワークと対話することになっているかどうかと、そうだとすれば、この相互作用がどのようにホストに合図されることになっているかに関する考慮もあります。
6.3.3. Layering Identity
6.3.3. レイヤリングのアイデンティティ
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
このアイデンティティの機能性を輸送プロトコル層にみなすのは、しっかりアイデンティティ機能を輸送セッションに関連づけることができるのを含意します。 このアプローチでは、セッション始動はアイデンティティ/ロケータの初期の拘束力がある動きの引き金となることができます、そして、ロケータスイッチ動作に引き金としてトランスポート・プロトコルタイムアウトは使用できます。 セッション終了は地方のアイデンティティ/ロケータの拘束力がある状態の満了の引き金となることができます。 1セッションあたりの便宜主義的なアイデンティティ象徴値が使用されているところでは、総合的なセッション州の中にアイデンティティ情報を保持できます。 また、しつこいアイデンティティ象徴値の場合では、アイデンティティの実現が、1セッションあたりの状態を使用するのを選ぶことができますか、またはそれは、ダイナミックな発見のオーバーヘッドを下げるために複数のセッションの向こう側にこの情報をプールするのを選ぶかもしれません。
Huston Informational [Page 27] RFC 4177 Multi6 Architecture September 2005
[27ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
identity/locator bindings for remote identities in the case of multiple sessions to the same remote endpoint.
同じ遠く離れた終点への複数のセッションの場合におけるリモートアイデンティティのためのアイデンティティ/ロケータ結合。
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つは各トランスポート・プロトコルがアイデンティティの機能性の異なった実装を必要とするのが、可能であるということです。 これは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.
代替的アプローチはプロトコル・スタックの輸送とインターネット層の間に置かれた異なったプロトコル要素を使用することです。 このアプローチの利点はすべてのフォームのトランスポート・プロトコルのためにアイデンティティとロケータの間に一貫したマッピングを提供するだろうということです。 しかしながら、このプロトコル要素的に、明らかにセッションを意識していなくて、そのようなマッピングが存在しているかどうかと、これがセッション文脈の一部であるかどうかの如何にかかわらずすべてのアイデンティティで扱われたパケットのための適切なアイデンティティ/ロケータマッピングが後でトランスポート・プロトコルから変化したと発見しなければならないか、またはそのようなマッピングがいつ発見されて、適用されるかことであることを決定すると合図する追加メカニズムを持たなければならないでしょう。 また、このレベルに、状態を写像するアイデンティティ/ロケータがもう必要でない時に関する形式知が全くありません、目的地と、そして、特定の目的地からのすべての流れが止まって、状態をサポートする際に消費されたリソースを発表できる時に関する明白な合図がないとき。 また、そのようなプロトコル要素も輸送レベルタイムアウトを意識していないでしょう、追加機能性が、アイデンティティプロトコルレベルでロケータスイッチの引き金となるようにトランスポート・プロトコルに追加される必要があるように。 この環境で1セッションあたりの便宜主義的なアイデンティティ構造のサポートは、よりやりがいがあります、輸送プロトコル層が1セッションあたりの状態を保存して、操るのに使用されるとき。 プロトコル・スタックのこのレベルでアイデンティティ要素を構成する際に、適切な情報量がアイデンティティプロトコル要素が終わりから活発なセッションか端へのネットワーク経路の現状頃にことによると不正確な仮定をするのに強制されないのを保証するためにトランスポート・プロトコルと、インターネットプロトコルと、アイデンティティプロトコル要素の間で通過されているのを保証するのは必要に見えるでしょう。
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
また、プロトコル・スタックのインターネットプロトコル層の中でこのアイデンティティ機能を埋め込むのも可能です。 前項で注意されるように、1セッションあたりの情報は容易にアイデンティティモジュールに利用可能ではありません、1セッションあたりの便宜主義的なアイデンティティ値がこのアプローチでサポートするためにやりがいがあるように。 また、アイデンティティ/ロケータ州の情報がいつセットアップされて、発表されるべきであるかを決定するのもやりがいがあります。 また、ロケータスイッチ引き金としてアイデンティティモジュールへの輸送レベルタイムアウトに合図するのは必要に見えるでしょう。 何らかの注意が、この場合与えられる必要があります。
Huston Informational [Page 28] RFC 4177 Multi6 Architecture September 2005
[28ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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.
連動しているロケータスイッチとIPパケット断片化。 また、IPSecの考慮もこの場合必要です、パケットが正しい文脈で認識可能でないところでIPパケットのヘッダーのアドレス・フィールドへのリモートエンドにおける状態の引き金となる変更を行うのを避けるために。
6.3.4. Session Startup and Maintenance
6.3.4. セッション始動とメインテナンス
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).
分裂終点識別子/ロケータ環境で、終点識別子に関連している少なくとも1つの初期のロケータが、2人のホストの間の初期の接続を確立するのにあるのが必要です。 従来のファッションでこのロケータをDNSに積み込むことができるでしょうか、または初期のコミュニケーションは、終点識別子が顕著なアドレス値であるならロケータ(すなわち、従来のアドレスとしてこれを使用する)の役割に終点識別子を使用することで確立されるかもしれません。
The initial actions in establishing a session would be similar. If the session is based on specification of a FQDN, the FQDN is first mapped to an endpoint identity value, and this endpoint identity value could then be mapped to a locator set. The locators in this set are then candidate locators for use in establishing an initial synchronised state between the two hosts. Once the state is established, it is possible to update the initial locator set with the current set of useable locators. This update could be part of the initial synchronisation actions, or deferred until required.
セッションを確立することにおける初期の動きは同様でしょう。 セッションがFQDNの仕様に基づいているなら、最初に終点アイデンティティ価値にFQDNを写像しました、そして、次に、この終点アイデンティティ価値をロケータセットに写像できました。 このセットにおけるロケータは2人のホストの間の初期の連動した状態を設置することにおける使用のための当時の候補ロケータです。 状態がいったん設置されると、現在のセットのuseableロケータで初期のロケータセットをアップデートするのは可能です。 初並列動作の一部であるかもしれない、または延期されたこの必要になるまでのアップデート。
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
便宜主義的なアイデンティティがアイデンティティが固定発見可能な値ではなく、セッションの文脈で生成されるものであるところで使用されるなら、セッション始動で追加動作を実行しなければなりません。 この場合、セッションを証明するのに使用される定義されたロケータの必要がまだありますが、追加ステップが、続くセッション中にアイデンティティが複数のロケータの等価性であるとサポートするためにセッションキーを生成して、これらの値を交換するのに必要です。 これはバンドにおけるアプローチが使用されているなら輸送の中の交換が議定書の中で述べるか、またはそれがレベルにおける異なったプロトコル交換の形を取るかもしれないa能力交換の形、追加握手、および関連トークン値を取るかもしれません。
Huston Informational [Page 29] RFC 4177 Multi6 Architecture September 2005
[29ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
identity protocol element, performed out-of-band from the transport session.
バンドの外で輸送セッションから実行されたアイデンティティプロトコル要素。
Some approaches are capable of a further distinction, namely, that of initial session establishment and that of establishment of additional shared state within the session to allow multiple locators to be treated as being bound to a common endpoint identity. It is not strictly necessary that such additional actions be performed at session startup, but it appears that such actions need to be performed prior to any loss of end-to-end connectivity on the selected initial locator, so that any delay in this additional state exchange does increase the risk of session disruption due to connectivity changes.
すなわち、さらなる区別で、初期のセッション設立のものでいくつかのアプローチが複数のロケータが扱われるのを許容するセッション中の一般的な終点のアイデンティティに縛られる追加共有された状態の設立のものであることができます。 そのような追加動作がセッション始動で実行されるのは厳密に必要ではありませんが、そのような動作が、選択された初期のロケータにおける終わりから終わりへの接続性のどんな損失の前にも実行される必要なように見えます、この追加州の交換のどんな遅れも接続性変化によるセッション分裂の危険を増強するように。
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
あるいはまた、受け身の終わりは、初めは提供されたロケータを使用して、これがうまくいくなら、各端の間、現在の完全なロケータセットを証明するために情報交換するように各スタックのアイデンティティモジュールに任せるでしょう。 このアプローチは、コミュニケーションのアクティブな終わりが、それで応答を受けるか、またはロケータがくたくたになるまでソースアドレスがセットしたとき関連ロケータのすべてを通して循環する必要であるのを含意します。 また、もう一方の端がそうである、マルチ、家へ帰り、(そして、したがって、複数のロケータを持っています)、そして、アクティブな終わりは、それぞれのソースロケータのためにすべての可能な目的地ロケータを通して循環する必要があるかもしれません。 これは経路が全くリモートエンドに存在しないと確認する時間を延ばすかもしれませんが、それには、向上する可能性があります。
Huston Informational [Page 30] RFC 4177 Multi6 Architecture September 2005
[30ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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.
リモートエンドがやむを得ず偽りのロケータルックアップの高いボリュームに従事できたサービス不能攻撃に対する初期の交換の特性。
6.3.5. Dynamic Capability Negotiation
6.3.5. ダイナミックな能力交渉
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つのフォームの機能性しか交渉できないのは厳密に必要ではありません。 特定の終点アイデンティティ/ロケータマッピング体系の採用が終点の間の交渉の結果であるなら、多くの可能なアプローチの1つを使用するのを交渉するのは可能でしょう。 使用されるアプローチと終点のアイデンティティのフォームとのいくつかの相互作用があります、そして、いずれも形成する終点アイデンティティ能力交渉の許容できる結果のいくつかの取られるべき注意の必要性が上側のレベルアプリケーションが作動し続けることができるものです。
6.3.6. Identity Uniqueness and Stability
6.3.6. アイデンティティのユニークさと安定性
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.
長命のアイデンティティの特性を考えるとき、アイデンティティ密会が必ず永久的で不変であることのものであるというわけではないと仮定するのは妥当です。 構造化されたアイデンティティ空間の場合では、アイデンティティ値は分配階層構造を反映します。 多くの事情がアイデンティティ価値の変化が適切であるところにあります。 例えば、終点デバイスがこの分配階層構造の管理分野の向こう側に動かされると、終点のアイデンティティ値が新しい分野を反映するのが再選任されそうでしょう。 また、終点が時間内に任意な点に1つ以上のアイデンティティを持っているかもしれないと仮定するのも妥当です。 RFC3014[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
終点のアイデンティティが時間がたつにつれて、変化できて、時間内に任意な単一の点の1つ以上のアイデンティティで終点を特定できるなら、終点識別子のさらなるいくつかの特性がそうであるべきです。
Huston Informational [Page 31] RFC 4177 Multi6 Architecture September 2005
[31ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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.
定義にされる。 これらはアプリケーションの中の終点のアイデンティティの不変性、およびそうだとすれば、輸送セッションがただ一つの終点アイデンティティ価値を当てにするかどうかと、輸送セッション以内に終点のアイデンティティを変えることができるかどうかと、古いアイデンティティが、どんな条件のもとで何かそのような変化に続いて、使用され続けることができるかに関する質問に関連します。 終点のアイデンティティが遠く離れた終点の長命の参照であり、複数のアイデンティティが単一のユニークな終点に存在できるなら、アプリケーションが等価性のためにアイデンティティを比較できるかどうかと、アプリケーションが状態を認識するのが必要であるかどうかに関して異なったアイデンティティが同じ終点についてどこに言及するかという質問は起こります。 これらのアイデンティティが独身のホストの上でアプリケーションの中で使用されるかもしれませんか、またはそれらは使用されます。異なったホストの上でアプリケーションの中で特定します。
7. Functional Decomposition of Multi-Homing Approaches
7. マルチホーミングアプローチの機能的な分解
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.
以下のセクションがaの文脈でセッション設立、メインテナンス、および完成に関連している機能の分解によるマルチホーミングアプローチの特殊化にフレームワークを提供する、マルチ、家へ帰り、環境。
7.1. Establishing Session State
7.1. セッション状態を設置します。
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?
セッション創始者は、セッションのリモートエンドがプロトコル・スタックでどうしたらマルチホーミング能力をサポートすることができるのを確証しますか? リモートエンドがそうすることができないなら、マルチホーミングのできるプロトコル要素がセッション設立失敗を上側のレベルプロトコルに報告するか、または静かにaへ後ろへ下がる、非、マルチ、家へ帰り、プロトコル操作?
Huston Informational [Page 32] RFC 4177 Multi6 Architecture September 2005
[32ページ]RFC4177Multi6アーキテクチャ2005年9月の情報のヒューストン
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?
どんなフォームのメカニズムは、選択されたサイト出口経路が選択されたパケットソースロケータに合っているのを保証するのに使用されますか?
7.2. Re-homing Triggers
7.2. 再の家へ帰り引き金
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?
適切なロケータ修理機能の引き金となるように失敗した経路の指示を示すのにどんな引き金を使用できますか?
7.3. Re-homing Locator Pair Selection
7.3. 再の家へ帰りロケータ組選択
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?
どうしたら既存のセッションのロケータプールに新しいロケータを加えることができますか?
Huston Informational [Page 33] RFC 4177 Multi6 Architecture September 2005
[33ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
7.4. Locator Change
7.4. ロケータ変化
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?
どんな相互作用がロケータ変化と輸送セッションのふるまいの連動に必要ですか?
7.5. Removal of Session State
7.5. セッション状態の取り外し
How is identity/locator binding state removal synchronised with session closure?
取り外しが連動したアイデンティティ/ロケータの拘束力がある状態はどのようにセッション閉鎖ですか?
What binding information is cached for possible future use?
どんな拘束力がある情報が可能な今後の使用のためにキャッシュされますか?
8. Security Considerations
8. セキュリティ問題
There are a significant number of security considerations that result from the action of distinguishing within the protocol suite endpoint identity and locator identity.
プロトコル群終点のアイデンティティとロケータのアイデンティティの中で区別する動作から生じる多くのセキュリティ問題があります。
It is not proposed to enumerate these considerations in detail within this document, but to reference a distinct document that describes the security considerations of this domain [threats].
それはこのドキュメントの中に詳細にこれらの問題を列挙するために提案されるのではなく、参照へのこのドメイン[脅威]のセキュリティ問題について説明する異なったドキュメントです。
9. Acknowledgements
9. 承認
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.
作者は以下の評論家から支援を承諾します: ブライアンCarpenter、カーティス・ルントクビスト、エリックNordmark、IljitschはBeijnum、マルセロBagnulo、ジョンLoughney、ティエリー・エルンスト、ジョーTouch、マイケル・パットン、テッド・ハーディー、およびアリソン・マンキンをバンに積みます。
10. Informative References
10. 有益な参照
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3041] NartenとT.とR.Draves、「IPv6"での国がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6
Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582] Abley、J.、黒、B.、およびV.エラ、「IPv6サイトマルチホーミング構造の目標」、RFC3582、2003年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
Huston Informational [Page 34] RFC 4177 Multi6 Architecture September 2005
[34ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
[iab-link] Aboba, B., Ed., "Architectural Implications of Link Layer
Indications", Work in Progress, January 2005.
[iab-リンク] Aboba、B.、エド、1月2005、「リンクレイヤ指摘の建築含意」は進行中で働いています。
[e2e] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
in System Design", ACM TOCS Vol 2, Number 4, pp 277-288,
November 1984, <http://web.mit.edu/Saltzer/www/
publications/endtoend/endtoend.txt>.
[e2e] Saltzer、J.、リード、D.、およびD.クラーク、「システム設計における終わりから終わりへの議論」、ACM TOCS Vol2、Number4、pp277-288、1984年11月(<http://web.mit.edu/Saltzer/www/刊行物/endtoend/endtoend.txt>)。
[rosec] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", Work in Progress, October 2004.
Progress(2004年10月)の[rosec]Nikander、P.、Arkko、J.、Aura、T.、モンテネグロ、G.、およびE.Nordmark、「モバイルIPバージョン6Route Optimization Security Design Background」Work。
[thinks] Lear, E., "Things MULTI6 Developers should think about",
Work in Progress, January 2005.
[思います] リア、E.、「MULTI6 Developersが考えるはずであるもの」、Progress、2005年1月のWork。
[threats] Nordmark, E. and T. Li, "Threats relating to IPv6
multi-homing solutions", Work in Progress, January 2005.
[脅威] NordmarkとE.とT.李、「IPv6マルチホーミング解決に関係する脅威」、ProgressのWork、2005年1月。
Author's Address
作者のアドレス
Geoff Huston APNIC
ジェフヒューストンAPNIC
EMail: gih@apnic.net
メール: gih@apnic.net
Huston Informational [Page 35] RFC 4177 Multi6 Architecture September 2005
[35ページ]RFC4177Multi6構造2005年9月の情報のヒューストン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Huston Informational [Page 36]
ヒューストンInformationalです。[36ページ]
一覧
スポンサーリンク
