Network Working Group G. Huston
Request for Comments: 4177 APNIC
Category: Informational September 2005
Network Working Group G. Huston
Request for Comments: 4177 APNIC
Category: Informational September 2005
Architectural Approaches to Multi-homing for IPv6
IPv6多宿的体系结构方法
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing.
本备忘录对IPv6协议套件的多主支持的体系结构方面进行了分析。本分析的目的是为多归宿的各种拟议方法的分类提供分类。这项工作的另一个目标是确定这一研究领域的共同方面，并提供一个框架，允许探索旨在支持多主的各种体系结构扩展的一些进一步含义。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Multi-Homing Space . . . . . . . . . . . . . . . . . . . . 5
4. Functional Goals and Considerations . . . . . . . . . . . . . 7
5. Approaches to Multi-Homing . . . . . . . . . . . . . . . . . . 7
5.1. Multi-Homing: Routing . . . . . . . . . . . . . . . . . 8
5.2. Multi-Homing: Mobility . . . . . . . . . . . . . . . . . 9
5.3. Multi-homing: Identity Considerations . . . . . . . . . 12
5.4. Multi-homing: Identity Protocol Element . . . . . . . . 14
5.5. Multi-homing: Modified Protocol Element . . . . . . . . 15
5.6. Modified Site-Exit and Host Behaviors . . . . . . . . . 16
6. Approaches to Endpoint Identity . . . . . . . . . . . . . . . 17
6.1. Endpoint Identity Structure . . . . . . . . . . . . . . 18
6.2. Persistent, Opportunistic, and Ephemeral Identities . . 20
6.3. Common Issues for Multi-Homing Approaches . . . . . . . 23
6.3.1. Triggering Locator Switches . . . . . . . . . . 23
6.3.2. Locator Selection . . . . . . . . . . . . . . . 26
6.3.3. Layering Identity . . . . . . . . . . . . . . . 27
6.3.4. Session Startup and Maintenance . . . . . . . . 29
6.3.5. Dynamic Capability Negotiation . . . . . . . . . 31
6.3.6. Identity Uniqueness and Stability . . . . . . . 31
7. Functional Decomposition of Multi-Homing Approaches . . . . . 32
7.1. Establishing Session State . . . . . . . . . . . . . . . 32
7.2. Re-homing Triggers . . . . . . . . . . . . . . . . . . . 33
7.3. Re-homing Locator Pair Selection . . . . . . . . . . . . 33
7.4. Locator Change . . . . . . . . . . . . . . . . . . . . . 34
7.5. Removal of Session State . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
10. Informative References . . . . . . . . . . . . . . . . . . . . 34
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Multi-Homing Space . . . . . . . . . . . . . . . . . . . . 5
4. Functional Goals and Considerations . . . . . . . . . . . . . 7
5. Approaches to Multi-Homing . . . . . . . . . . . . . . . . . . 7
5.1. Multi-Homing: Routing . . . . . . . . . . . . . . . . . 8
5.2. Multi-Homing: Mobility . . . . . . . . . . . . . . . . . 9
5.3. Multi-homing: Identity Considerations . . . . . . . . . 12
5.4. Multi-homing: Identity Protocol Element . . . . . . . . 14
5.5. Multi-homing: Modified Protocol Element . . . . . . . . 15
5.6. Modified Site-Exit and Host Behaviors . . . . . . . . . 16
6. Approaches to Endpoint Identity . . . . . . . . . . . . . . . 17
6.1. Endpoint Identity Structure . . . . . . . . . . . . . . 18
6.2. Persistent, Opportunistic, and Ephemeral Identities . . 20
6.3. Common Issues for Multi-Homing Approaches . . . . . . . 23
6.3.1. Triggering Locator Switches . . . . . . . . . . 23
6.3.2. Locator Selection . . . . . . . . . . . . . . . 26
6.3.3. Layering Identity . . . . . . . . . . . . . . . 27
6.3.4. Session Startup and Maintenance . . . . . . . . 29
6.3.5. Dynamic Capability Negotiation . . . . . . . . . 31
6.3.6. Identity Uniqueness and Stability . . . . . . . 31
7. Functional Decomposition of Multi-Homing Approaches . . . . . 32
7.1. Establishing Session State . . . . . . . . . . . . . . . 32
7.2. Re-homing Triggers . . . . . . . . . . . . . . . . . . . 33
7.3. Re-homing Locator Pair Selection . . . . . . . . . . . . 33
7.4. Locator Change . . . . . . . . . . . . . . . . . . . . . 34
7.5. Removal of Session State . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
10. Informative References . . . . . . . . . . . . . . . . . . . . 34
The objective of this analysis is to allow various technical proposals relating to the support of multi-homing environment in IPv6 to be placed within an architectural taxonomy. This is intended to allow these proposals to be classified and compared in a structured fashion. It is also an objective of this exercise to identify common aspects across all proposals within this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing. The scope of this study is limited to the IPv6 protocol suite architecture, although reference is made to IPv4 approaches as required.
此分析的目的是将与支持IPv6中的多主环境相关的各种技术方案置于体系结构分类中。这旨在以结构化方式对这些提案进行分类和比较。这项工作的另一个目标是确定该研究领域内所有提案的共同方面，并提供一个框架，允许探索旨在支持多主的各种架构扩展的一些进一步影响。本研究的范围仅限于IPv6协议套件体系结构，尽管根据需要参考了IPv4方法。
Care-of Address (CoA) A unicast routeable address associated with a mobile node while visiting a foreign link; the subnet prefix of this IP address is a foreign subnet prefix. Among the multiple care-of addresses that a mobile node may have at any given time (e.g., with different subnet prefixes), the one registered with the mobile node's home agent for a given home address is called its "primary" care-of address.
转交地址（CoA）在访问外部链路时与移动节点相关联的单播可路由地址；此IP地址的子网前缀是外部子网前缀。在移动节点在任何给定时间可能具有的多个转交地址（例如，具有不同的子网前缀）中，针对给定的归属地址向移动节点的归属代理注册的一个被称为其“主要”转交地址。
Correspondent Node (CN) A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary.
通信节点（CN）移动节点与之通信的对等节点。对应节点可以是移动的或静止的。
Endpoint A term for the identity for a network host. This is normally assumed to be a constant or long-lived association.
端点网络主机标识的术语。这通常被认为是一个恒定的或长期的关联。
Endpoint Identity Protocol Stack Element (EIP) An added element in a protocol stack model that explicitly manages the association of locators to endpoints.
端点标识协议栈元素（EIP）：协议栈模型中添加的元素，显式管理定位器与端点的关联。
Home Address (HoA) A unicast routeable address assigned to a mobile node, used as the permanent address of the mobile node. This address is within the mobile node's home link. Standard IP routing mechanisms will deliver packets destined for a mobile node's home address to its home link. Mobile nodes can have multiple home addresses, for instance, when there are multiple home prefixes on the home link.
归属地址（HoA）：分配给移动节点的单播可路由地址，用作移动节点的永久地址。此地址位于移动节点的主链接内。标准IP路由机制将把目的地为移动节点的家庭地址的数据包传送到其家庭链路。例如，当主链路上有多个主前缀时，移动节点可以有多个主地址。
Lower Layer Protocol (LLP) The lower-level protocol in the protocol stack model relative to the protocol layer being considered. In the Internet architecture, the LLP of the transport protocol is the Internet Protocol, and the LLP of the application protocol is the transport protocol.
下层协议（LLP）：协议栈模型中相对于所考虑的协议层的下层协议。在Internet架构中，传输协议的LLP是Internet协议，应用协议的LLP是传输协议。
Locator The term "locator" is used as the location token for a network host. This is a network-level address that can be used as a destination field for IP packets.
定位器术语“定位器”用作网络主机的位置令牌。这是一个网络级地址，可以用作IP数据包的目标字段。
Mobile Node A node that can change its point of attachment from one link to another, while still being reachable via its home address.
移动节点可以将其连接点从一个链接更改为另一个链接，同时仍可通过其家庭地址访问的节点。
Multi-Homed Site A site with more than one transit provider. "Site multi-homing" is the practice of arranging a site to be multi-homed such that the site may use any of its transit providers for connectivity services.
多宿站点具有多个中转提供商的站点。“站点多主”是指将站点安排为多主的做法，以便站点可以使用其任何传输提供商提供连接服务。
Re-homing The transition of a site between two states of connectedness, due to a change in the connectivity between the site and its transit providers.
由于站点与其运输提供商之间的连接发生变化，站点在两种连接状态之间的转换。
Site An entity autonomously operating a network using IP.
站点使用IP自主操作网络的实体。
Site-Exit Router A boundary router of the site that provides the site's interface to one or more transit providers.
站点出口路由器站点的边界路由器，为一个或多个传输提供商提供站点接口。
Transit Provider A provider that operates a site that directly provides connectivity to the Internet to one or more external sites. The connectivity provided extends beyond the transit provider's own site. A transit provider's site is directly connected to the sites for which it provides transit.
运输提供商运营一个站点的提供商，该站点直接向一个或多个外部站点提供互联网连接。提供的连接超出了运输提供商自己的站点。公交服务提供商的站点直接连接到其提供公交服务的站点。
Upper Layer Protocol (ULP) The upper-level protocol in the protocol stack model relative to the protocol layer being considered. In the Internet architecture, the ULP of the Internet Protocol is the transport protocol, and the ULP of the transport protocol is the application protocol.
上层协议（ULP）：协议栈模型中相对于所考虑的协议层的上层协议。在互联网体系结构中，互联网协议的ULP是传输协议，传输协议的ULP是应用协议。
A simple formulation of the site multi-homing environment is indicated in Figure 1.
图1显示了站点多主环境的简单公式。
+------+
|remote|
| host |
| R |
+------+
|
+ - - - - - - - - - - - +
| Internet Connectivity |
+ - - - - - - - - - - - +
/ \
+---------+ +---------+
| ISP A | | ISP B |
+---------+ +---------+
| Path A | Path B
+ - - - - - - - - - - - - - - - - - - - - +
| multi- | | |
homed +------+ +------+
| site | site-| | site-| |
| exit | | exit |
| |router| |router| |
| A | | B |
| +------+ +------+ |
| |
| local site connectivity |
|
| +-----------+ |
|multi-homed|
| | host | |
+-----------+
+ - - - - - - - - - - - - - - - - - - - - +
+------+
|remote|
| host |
| R |
+------+
|
+ - - - - - - - - - - - +
| Internet Connectivity |
+ - - - - - - - - - - - +
/ \
+---------+ +---------+
| ISP A | | ISP B |
+---------+ +---------+
| Path A | Path B
+ - - - - - - - - - - - - - - - - - - - - +
| multi- | | |
homed +------+ +------+
| site | site-| | site-| |
| exit | | exit |
| |router| |router| |
| A | | B |
| +------+ +------+ |
| |
| local site connectivity |
|
| +-----------+ |
|multi-homed|
| | host | |
+-----------+
+ - - - - - - - - - - - - - - - - - - - - +
Figure 1: The Multi-Homed Domain
图1：多宿主域
The environment of multi-homing is intended to provide sufficient support to local hosts so as to allow local hosts to exchange IP packets with remote hosts, such that this exchange of packets is transparently supported across dynamic changes in connectivity. Session resilience implies that if a local multi-homed-aware host establishes an application session with the remote host using "Path
多主环境旨在为本地主机提供足够的支持，以允许本地主机与远程主机交换IP数据包，从而在连接的动态变化中透明地支持这种数据包交换。会话弹性意味着，如果本地多宿主感知主机使用“路径”与远程主机建立应用程序会话
A", and this path fails, the application session should be mapped across to "Path B" without requiring any application-visible re-establishment of the session. In other words, the application session should not be required to be explicitly aware of underlying path changes at the level of packet forwarding paths chosen by the network. Established sessions should survive dynamic changes in network-level reachability.
如果此路径失败，则应用程序会话应映射到“路径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使用的地址空间是不同的，ISP A所宣传的地址空间是可访问的。
This simple scenario is intended to illustrate the basic multi-homing environment. Variations may include additional external providers of transit connectivity to the local site; complex site requirements and constraints, where the site may not interface uniformly to all external transit providers; sequential rather than simultaneous external transit reachability; communication with remote multi-homed hosts; multiway communications; use of host addresses in a referential context (third-party referrals); and the imposition of policy constraints on path selection. However, the basic simple site multi-homing scenario is sufficient to illustrate the major
这个简单的场景旨在说明基本的多主环境。变更可能包括与本地站点的交通连接的其他外部供应商；复杂的现场要求和限制，现场可能无法与所有外部交通供应商统一接口；顺序而非同时的外部传输可达性；与远程多主机通信；多路通信；在引用上下文中使用主机地址（第三方引用）；以及对路径选择施加政策约束。然而，基本的简单站点多主场景足以说明主要的
architectural aspects of support for multi-homing, so this simple scenario will be used as the reference model for this analysis.
架构方面支持多主，因此此简单场景将用作此分析的参考模型。
RFC 3582 [RFC3582] documents some goals that a multi-homing approach should attempt to address. These goals include:
RFC 3582[RFC3582]记录了多归宿方法应该尝试解决的一些目标。这些目标包括：
* redundancy * load sharing * traffic engineering * policy constraints * simplicity of approach * transport-layer survivability * DNS compatibility * packet filtering capability * scaleability * legacy compatibility
* 冗余*负载共享*流量工程*策略约束*方法简单*传输层生存能力*DNS兼容性*数据包过滤能力*可扩展性*遗留兼容性
The reader is referred to [RFC3582] for a complete description of each of these goals.
读者可参考[RFC3582]了解这些目标的完整描述。
In addition, [thinks] documents further considerations for IPv6 multi-homing. Again, the reader is referred to this document for the detailed enumeration of these considerations. The general topic areas considered in this study include:
此外，[思考]还记录了IPv6多主的进一步考虑事项。同样，读者可参考本文件详细列举这些注意事项。本研究中考虑的一般主题领域包括：
* interaction with routing systems, * aspects of a split between endpoint-identifier and forwarding locator, * changes to packets on the wire, and * the interaction between names, endpoints, and the DNS.
* 与路由系统的交互，*端点标识符和转发定位器之间拆分的方面，*对线路上数据包的更改，*名称、端点和DNS之间的交互。
In evaluating various approaches, further considerations also include:
在评估各种方法时，进一步的考虑还包括：
* the role of helpers and agents in the approach, * modifications to host behaviours, * the required trust model to support the interactions, and * the nature of potential vulnerabilities in the approach.
* 帮助者和代理在方法中的作用，*修改主机行为，*支持交互所需的信任模型，以及*方法中潜在漏洞的性质。
There appear to be five generic forms of architectural approaches to this problem, namely:
解决这个问题的架构方法有五种通用形式，即：
Routing Use the IPv4 multi-homing approach
路由使用IPv4多主方法
Mobility Use the IPv6 Mobility approach
移动性使用IPv6移动性方法
New Protocol Element Insert a new element in the protocol stack that manages a persistent identity for the session
New Protocol Element在协议堆栈中插入一个新元素，用于管理会话的持久标识
Modify a Protocol Element Modify the transport or IP protocol stack element in the host in order to support dynamic changes to the forwarding locator
修改协议元素修改主机中的传输或IP协议堆栈元素，以支持对转发定位器的动态更改
Modified Site-Exit Router/Local Host interaction Modify the site-exit router and local forwarding system to allow various behaviours including source-based forwarding, site-exit hand-offs, and address rewriting by site-exit routers
修改站点出口路由器/本地主机交互修改站点出口路由器和本地转发系统，以允许各种行为，包括基于源的转发、站点出口切换和站点出口路由器的地址重写
These approaches will be described in detail in the following sections.
这些方法将在以下章节中详细描述。
The approach used in IPv4 for multi-homing support is to preserve the semantics of the IPv4 address as both an endpoint identifier and a forwarding locator. For this to work in a multi-homing context, it is necessary for the transit ISPs to announce the local site's address prefix as a distinct routing entry in the inter-domain routing system. This approach could be used in an IPv6 context, and, as with IPv4, no modifications to the IPv6 architecture are required to support this approach.
IPv4中用于多主支持的方法是保留IPv4地址作为端点标识符和转发定位器的语义。为了在多主环境下工作，运输ISP必须宣布本地站点的地址前缀，作为域间路由系统中的一个不同路由条目。这种方法可以在IPv6环境中使用，并且与IPv4一样，不需要修改IPv6体系结构来支持这种方法。
The local site's address prefix may be a more specific address prefix drawn from the address space advertised by one of the transit providers, or from some third-party provider not currently connected directly to the local site. Alternatively, the address space may be a distinct address block obtained by direct assignment from a Regional Internet Registry as Provider Independent space. Each host within the local site is uniquely addressed from the site's address prefix.
本地站点的地址前缀可以是更具体的地址前缀，该地址前缀来自其中一个中转提供商所公布的地址空间，或者来自当前未直接连接到本地站点的某个第三方提供商。或者，地址空间可以是通过作为提供商独立空间直接从区域互联网注册处分配获得的不同地址块。本地站点中的每个主机都是从站点的地址前缀唯一寻址的。
All transit providers for the site accept a prefix advertisement from the multi-homed site and advertise this prefix globally in the inter-domain routing table. When connectivity between the local site and an individual transit provider is lost, normal operation of the routing protocol will ensure that the routing advertisement
站点的所有传输提供程序都接受来自多宿主站点的前缀播发，并在域间路由表中全局播发此前缀。当本地站点和单个运输提供商之间的连接丢失时，路由协议的正常操作将确保路由播发
corresponding to this particular path will be withdrawn from the routing system; those remote domains that had selected this path as the best available will select another candidate path as the best path. Upon restoration of the path, the path is re-advertised in the inter-domain routing system. Remote domains will undertake a further selection of the best path based on this re-advertised reachability information. Neither the local nor the remote host need to have multiple addresses or to undertake any form of address selection. The path chosen for forward and reverse direction path flows is a decision made by the routing system.
与此特定路径对应的路径将从路由系统中退出；选择此路径作为最佳可用路径的远程域将选择另一个候选路径作为最佳路径。路径恢复后，在域间路由系统中重新公布该路径。远程域将根据此重新公布的可达性信息进一步选择最佳路径。本地主机和远程主机都不需要有多个地址，也不需要进行任何形式的地址选择。为正向和反向路径流选择的路径由路由系统决定。
This approach generally meets all the goals for multi-homing approaches with one notable exception: scaleability. Each site that multi-homes in this fashion adds a further entry in the global inter-domain routing table. Within the constraints of current routing and forwarding technologies, it is not clearly evident that this approach can scale to encompass a population of multi-homed sites of the order of, for example, 10**7 such sites. The implication here is that this would add a similar number of unique prefixes into the inter-domain routing environment, which in turn would add to the storage and computational load imposed on inter-domain routing elements within the network. This scale of additional load is not supportable within the current capabilities of the IPv4 global Internet, nor is it clear at present that the routing capabilities of the entire network could be expanded to manage this load in a cost-effective fashion, within the bounds of the current inter-domain routing protocol architecture.
这种方法通常满足多归宿方法的所有目标，但有一个显著的例外：可伸缩性。以这种方式创建多个家庭的每个站点都会在全局域间路由表中添加一个进一步的条目。在当前路由和转发技术的限制范围内，不清楚这种方法是否可以扩展到包括多个多址站点的数量，例如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.
另一个目标，传输层生存性，在这种方法中可能存在风险。网络内的动态变化触发路由系统收敛到新的稳定分布式转发状态。分布式路由系统内的这种收敛过程可能包括网络产生不稳定的瞬时转发路径，以及需要不确定的时间来完成。这一术语可能会触发上层协议超时和可能的会话重置。
Preserving established communications through movement is similar to preserving established communications through outages in multi-homed sites as both scenarios require the capability of dynamically changing the locators used during the communication while maintaining, unchanged, the endpoint identifier used by Upper Layer Protocol (ULP). Since MIPv6 protocol [RFC3775] already provides the required support to preserve established communications through movement, it seems worthwhile to explore whether it could also be used to provide session survivability in multi-homed environments.
通过移动保持已建立的通信与通过多宿站点中的中断保持已建立的通信类似，因为这两种情况都要求能够动态更改通信期间使用的定位器，同时保持上层协议（ULP）使用的端点标识符不变。由于MIPv6协议[RFC3775]已经提供了通过移动保持已建立通信所需的支持，因此似乎值得探讨它是否也可以用于在多宿主环境中提供会话生存能力。
MIPv6 uses a preferred IP address, the Home Address (HoA), as a stable identifier for the mobile node (MN). This identifier is then dynamically mapped to a valid locator (Care-of Address, or CoA) that corresponds to the current attachment point within the network topology. When the MN is at the Home Network, the HoA is used both as locator and as identifier. When the MN is not at the Home Network, the HoA is used as an identifier, and the CoA is used as locator. A relaying agent (Home Agent) placed in the Home Network is used to forward packets addressed to the HoA to the current location, specified by the CoA. After each movement, the MN must inform its Home Agent of the new CoA and optionally inform those entities with which it has established communications (Correspondent Nodes, or CNs). The mapping between the HoA and the current CoA is conveyed using Binding Update (BU) messages.
MIPv6使用首选IP地址，即家庭地址（HoA），作为移动节点（MN）的稳定标识符。然后，该标识符被动态映射到与网络拓扑中的当前连接点相对应的有效定位器（转交地址，或CoA）。当MN位于家庭网络时，HoA被用作定位器和标识符。当MN不在家庭网络中时，HoA用作标识符，CoA用作定位器。放置在家庭网络中的中继代理（家庭代理）用于将发往HoA的数据包转发到CoA指定的当前位置。在每次移动之后，MN必须将新的CoA通知其归属代理，并选择性地通知与其建立通信的那些实体（通信节点或CNs）。HoA和当前CoA之间的映射使用绑定更新（BU）消息传递。
When the BU message is exchanged between the MN and the Home Agent, it is possible to assume the existence of a pre-established Security Association that can be used to protect the binding information. However, when the BU message is exchanged between the MN and the CN, it is not possible to assume the existence of such a Security Association. In this case, it is necessary to adopt an alternative mechanism to protect the binding information contained in the message. The selected mechanism is called the Return Routeability procedure, and the background for its design is detailed in [rosec]. The goal of the mechanism is to allow the CN to verify that the MN that is claiming that an HoA is currently located at a CoA is entitled to make such claim; this essentially means that the HoA was assigned to the MN, and that the MN is currently located at the CoA. In order to verify these updates, the CN sends two different secrets, one to the claimed HoA and another one to the claimed CoA. If the MN receives both secrets, this means that the Home Agent located at the Home Network has a trust relationship with the MN, that it has forwarded the secret sent to the HoA, and that the MN is receiving packets sent to the CoA. By including authorisation information derived from both secrets within the BU message, the MN will be able to prove to the CN that the claimed binding between the HoA and the CoA is valid.
当在MN和归属代理之间交换BU消息时，可以假设存在可用于保护绑定信息的预先建立的安全关联。然而，当在MN和CN之间交换BU消息时，不可能假设存在这样的安全关联。在这种情况下，有必要采用替代机制来保护消息中包含的绑定信息。所选机制称为返回可路由性程序，其设计背景详见[rosec]。该机制的目标是允许CN核实声称HoA当前位于CoA的MN是否有权提出此类索赔；这基本上意味着HoA分配给MN，MN当前位于CoA。为了验证这些更新，CN发送了两个不同的秘密，一个给声称的HoA，另一个给声称的CoA。如果MN接收到这两个秘密，这意味着位于归属网络的归属代理与MN具有信任关系，它已将发送给HoA的秘密转发给MN，并且MN正在接收发送给CoA的分组。通过在BU消息中包含来自这两个机密的授权信息，MN将能够向CN证明HoA和CoA之间声称的约束是有效的。
The lifetime of the binding that is created in the CN using authorisation information obtained through the Return Routeability procedure is limited to 7 minutes, in order to prevent time-shifted attacks [rosec]. In a time-shifted attack, an attacker located along the path between the CN and the MN forges the Return Routeability packet exchange. The result of such an attack is that the CN will forward all the traffic addressed to the HoA to the CoA selected by the attacker. The attacker can then leave the position along the path, but the effects of the attack will remain until the binding is deleted, shifting in time the effect of the attack. By limiting the
使用通过返回可路由性程序获得的授权信息在CN中创建的绑定的生存期限制为7分钟，以防止时移攻击[rosec]。在时移攻击中，位于CN和MN之间路径上的攻击者伪造返回可路由性数据包交换。这种攻击的结果是，CN将所有发送给HoA的流量转发给攻击者选择的CoA。然后，攻击者可以沿路径离开该位置，但攻击的效果将一直保持，直到删除绑定，从而及时改变攻击的效果。通过限制
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分钟，因为在这段时间之后，需要一个新的返回可路由性过程来延长绑定的生存期。应该注意，返回路由性过程容易受到“中间人”攻击，因为位于CN和MN之间的路径上的攻击者可以伪造周期性返回路由性分组交换。
The possible application of the MIPv6 protocol to the multi-homing problem would be to use BU messages to convey information in advance about alternative addresses that could be used following an outage in the path associated with the currently used address.
MIPv6协议对多主问题的可能应用是使用BU消息提前传达与当前使用地址相关的路径中断后可使用的替代地址相关的信息。
In this scenario, the multi-homed host adopts the MN role and the host outside the multi-homed site adopts the CN role. When a communication is established between the multi-homed host and the external host, the address used for initiating the communication is used as an HoA. The communication continues using this address as long as no outage occurs. If an outage occurs and the HoA becomes unreachable, an alternative address of the multi-homed node is used as a CoA. In this case, the multi-homed node sends a BU message to the external host, informing it about the new CoA to be used for the HoA, so that the established communication can be preserved using the alternative address. However, such a BU message has to be validated using authorisation information obtained through the Return Routeability procedure, which implies that the binding lifetime will be limited to a fixed period of no more than 7 minutes. The result is that the binding between the HoA and the new CoA will expire after this interval has elapsed, and then the HoA will be used for the communication. Since the HoA is unreachable because of the outage, the communication will be interrupted. It should be noted that it is not possible to acquire new authorisation information by performing a new Return Routeability procedure, because it requires communication through the HoA, which is no longer reachable. Consequently, a mechanism based on the MIPv6 BU messages to convey information about alternative addresses will preserve communications only for 7 minutes.
在此场景中，多宿主主机采用MN角色，多宿主站点之外的主机采用CN角色。在多宿主主机和外部主机之间建立通信时，用于发起通信的地址用作HoA。只要不发生中断，通信将继续使用此地址。如果发生中断且无法访问HoA，则多宿节点的替代地址将用作CoA。在这种情况下，多宿节点向外部主机发送BU消息，通知其将用于HoA的新CoA，以便可以使用替代地址保留已建立的通信。但是，必须使用通过返回可路由性程序获得的授权信息对此类BU消息进行验证，这意味着绑定寿命将限制在不超过7分钟的固定时间内。结果是，HoA和新CoA之间的绑定将在该间隔过后过期，然后HoA将用于通信。由于中断，无法访问HoA，因此通信将中断。应注意的是，不可能通过执行新的返回可路由性程序来获取新的授权信息，因为它需要通过HoA进行通信，而HoA已无法访问。因此，一种基于MIPv6 BU消息的机制来传递关于备用地址的信息，将只保留通信7分钟。
The aspect of MIPv6 that appears to present issues in the context of multi-homing is the Return Routeability procedure. In MIPv6, identity validity is periodically tested by return routeability of the identity address. This regular use of a distinguished locator as the identity token cannot support return reachability in the multi-homing context, in the event of extended failure of the path that is associated with the identity locator.
MIPv6在多主环境中出现问题的方面是返回可路由性过程。在MIPv6中，通过标识地址的返回可路由性定期测试标识有效性。在与标识定位器关联的路径发生扩展故障的情况下，这种将可分辨定位器作为标识令牌的常规使用无法支持多主上下文中的返回可达性。
The intent of multi-homing in the IPv6 domain is to achieve an outcome that is comparable to that of multi-homed IPv4 sites using routing to support multi-homing, without an associated additional load being imposed on the IPv6 routing system. The overall intent of IPv6 is to provide a scalable protocol framework to support the deployment of communications services for an extended period of time, and this implies that the scaling properties of the deployment environment remain tractable within projections of size of deployment and underlying technology capabilities. Within the inter-domain routing space, the basic approach used in IPv4 and IPv6 is to attempt to align address deployment with network topology, so that address aggregation can be used to create a structured hierarchy of the routing space.
IPv6域中的多宿主的目的是实现与使用路由支持多宿主的多宿主IPv4站点相当的结果，而不会对IPv6路由系统施加相关的额外负载。IPv6的总体意图是提供一个可扩展的协议框架，以支持在较长时间内部署通信服务，这意味着部署环境的可扩展性在部署规模和基础技术能力的预测范围内保持可控。在域间路由空间中，IPv4和IPv6中使用的基本方法是尝试将地址部署与网络拓扑相一致，以便可以使用地址聚合来创建路由空间的结构化层次结构。
Within this constraint of topological-based address deployment and provider-aggregateable addressing architectures, the local site that is connected to multiple providers is delegated addresses from each of these providers' address blocks. In the example network in Figure 1, the local multi-homed host will conceivably be addressed in two ways: one using transit provider A's address prefix and the other using transit provider B's address prefix.
在基于拓扑的地址部署和提供程序可聚合寻址体系结构的约束下，连接到多个提供程序的本地站点从这些提供程序的每个地址块中委派地址。在图1中的示例网络中，本地多宿主主机将以两种方式寻址：一种使用传输提供商A的地址前缀，另一种使用传输提供商B的地址前缀。
If remote host R is to initiate a communication with the local multi-homed host, it would normally query the DNS for an address for the local host. In this context, the DNS would return two addresses. one using the A prefix and the other using the B prefix. The remote host would select one of these addresses and send a packet to this destination address. This would direct the packet to the local host along a path through A or B, depending on the selected address. If the path between the local site and the transit provider fails, then the address prefix announced by the transit provider to the inter-domain routing system will continue to be the provider's address prefix. The remote host will not see any change in routing, yet packets sent to the local host will now fail to be delivered. The question posed by the multi-homing problem is: "If the remote host is aware of multi-homing, how could it switch over to using the equivalent address for the local multi-homed host that transits the other provider?"
如果远程主机R要启动与本地多宿主主机的通信，它通常会向DNS查询本地主机的地址。在此上下文中，DNS将返回两个地址。一个使用A前缀，另一个使用B前缀。远程主机将选择其中一个地址，并向该目标地址发送数据包。这将根据所选地址，沿着通过a或B的路径将数据包定向到本地主机。如果本地站点和传输提供商之间的路径出现故障，则传输提供商向域间路由系统宣布的地址前缀将继续作为提供商的地址前缀。远程主机将看不到路由的任何更改，但发送到本地主机的数据包现在将无法传递。多宿主问题提出的问题是：“如果远程主机知道多宿主，它如何切换到使用传输其他提供商的本地多宿主主机的等效地址？”
If the local multi-homed host wishes to initiate a session with remote host R, it needs to send a packet to R with a valid source and destination address. While the destination address is that of R, what source address should the local host use? There are two implications for this choice. Firstly, the remote host will, by default use this source address as the destination address in its response, and hence this choice of source address will direct the
如果本地多宿主主机希望启动与远程主机R的会话，则需要向R发送具有有效源地址和目标地址的数据包。当目标地址是R的地址时，本地主机应该使用什么源地址？这一选择有两个含义。首先，默认情况下，远程主机将使用此源地址作为其响应中的目标地址，因此此源地址选择将引导
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 B的入口过滤器将丢弃该数据包。
Within this addressing structure there is no form of routing-based repair of certain network failures. If the link between the local site and ISP A fails, there is no change in the route advertisements made by ISP A to its external routing peers. Even though the multi-homed site continues to be reachable via ISP B, packets directed to the site using ISP A's prefix will be discarded by ISP A, as the destination is unreachable. The implication here is that, if the local host wishes to maintain a session across such events, it needs to communicate to remote host R that it is possible to switch to a destination address for the multi-homed host that is based on ISP B's address prefix. In the event that the local host wishes to initiate a session at this point, then it may need to use an initial source locator that reflects the situation that the only viable destination address to use is the one that is based on ISP B's address prefix. It may be the case that the local host is not aware of this return routeability constraint, or it may not be able to communicate this information directly to R, in which case R needs to discover or be passed this information in other ways.
在这种寻址结构中，没有基于路由的特定网络故障修复形式。如果本地站点和ISP A之间的链路出现故障，则ISP A向其外部路由对等方发出的路由公告不会发生变化。即使多宿站点仍然可以通过ISP B访问，但由于无法访问目的地，使用ISP A前缀定向到站点的数据包将被ISP A丢弃。这里的含义是，如果本地主机希望在这些事件中保持会话，它需要与远程主机R通信，以便能够切换到基于ISP B的地址前缀的多宿主机的目标地址。如果本地主机希望在此时启动会话，则可能需要使用初始源定位器，该定位器反映了唯一可用的目标地址是基于ISP B地址前缀的地址的情况。可能是本地主机不知道该返回可路由性约束，或者它可能无法将该信息直接传递给R，在这种情况下，R需要以其他方式发现或传递该信息。
In an aggregated routing environment, multiple transit paths to a host imply multiple address prefixes for the host, where each possible transit path is identified by an address for the host. The implication of this constraint on multi-homing is that paths being passed to the local multi-homed site via transit provider ISP A must use a forwarding-level destination IP address drawn from ISP A's advertised address prefix set that maps to the multi-homed host. Equally, packets being passed via the transit of ISP B must use a destination address drawn from ISP B's address prefix set. The further implication here is that path selection (ISP A vs. ISP B transit for incoming packets) is an outcome of the process of selecting an address for the destination host.
在聚合路由环境中，到主机的多个传输路径意味着主机的多个地址前缀，其中每个可能的传输路径由主机的地址标识。此约束对多宿主的含义是，通过传输提供商ISP A传递到本地多宿主站点的路径必须使用从ISP A的播发地址前缀集中提取的转发级别目标IP地址，该地址前缀集映射到多宿主主机。同样，通过ISP B传输的数据包必须使用从ISP B地址前缀集中提取的目的地址。这里的进一步含义是路径选择（ISP 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
如果单个传输会话支持多个转发路径，并且如果路径选择与传输会话启动和维护功能分离，则
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.
以下各节介绍了这种端点标识和定位器值分离形式的一些通用方法。
One approach to this objective is to add a new element into the model of the protocol stack.
实现这一目标的一种方法是在协议栈的模型中添加一个新元素。
The presentation to the upper-level protocol stack element (ULP) would be endpoint identifiers to uniquely identify both the local stack and the remote stack. This will provide the ULP with stable identifiers for the duration of the ULP session.
向上层协议栈元素（ULP）的表示将是端点标识符，以唯一标识本地栈和远程栈。这将为ULP会话期间提供稳定的标识符。
The presentation to the lower-level protocol stack element (LLP) would be of the form of a locator. This implies that the protocol stack element would need to maintain a mapping of endpoint identifier values to locator values. In a multi-homing context, one of the essential characteristics of this mapping is that it needs to be dynamic, in that environmental triggers should be able to trigger a change in mappings. This in turn would correspond to a change in the paths (forward and/or reverse) used by the endpoints to traverse the network. In this way, the ULP session is defined by a peering of endpoint identifiers that remain constant throughout the lifetime of the ULP session, while the locators may change to maintain end-to-end reachability for the session.
下层协议栈元素（LLP）的表示形式为定位器。这意味着协议栈元素需要维护端点标识符值到定位器值的映射。在多宿主环境中，这种映射的一个基本特征是它需要是动态的，因为环境触发器应该能够触发映射的更改。这反过来将对应于端点用于穿越网络的路径（正向和/或反向）的变化。以这种方式，ULP会话通过端点标识符的对等来定义，这些端点标识符在ULP会话的整个生命周期内保持不变，而定位器可以改变以保持会话的端到端可达性。
The operation of the new protocol stack element (termed here the "endpoint identity protocol stack element", or EIP) will establish a synchronised state with its remote counterpart. This will allow the stack elements to exchange a set of locators that may be used within the context of the session. A change in the local binding between the current endpoint identity value and a locator will change the source locator value used in the forwarding-level packet header. The actions of the remote EIP upon receipt of this packet with the new
新协议栈元素（此处称为“端点标识协议栈元素”或EIP）的操作将与其远程对等方建立同步状态。这将允许堆栈元素交换一组可在会话上下文中使用的定位器。当前端点标识值和定位器之间的本地绑定的更改将更改转发级别数据包报头中使用的源定位器值。远程EIP在收到此数据包时的操作
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插入协议栈。
One possible location is at the upper level of the transport protocol. Here the application program interface (API) of the application-level protocols would interface to the EIP element, and use endpoint identifiers to refer to the remote entity. The EIP would pass locators to the API of the transport layer.
一个可能的位置位于传输协议的上层。这里，应用程序级协议的应用程序接口（API）将与EIP元素接口，并使用端点标识符来引用远程实体。EIP将向传输层的API传递定位器。
The second approach is to insert the EIP between the transport and internet protocol stack elements, so that the transport layer would function using endpoint identifiers and maintain a transport session using these endpoint identifiers. The IP or internetwork layer would function using locators, and the mapping from endpoint identifier to locator is undertaken within the EIP stack element.
第二种方法是在传输和internet协议栈元素之间插入EIP，以便传输层使用端点标识符工作，并使用这些端点标识符维护传输会话。IP或互联网层将使用定位器工作，并且从端点标识符到定位器的映射在EIP堆栈元素中进行。
As an alternative to insertion of a new protocol stack element into the protocol architecture, an existing protocol stack element could be modified to include the functionality performed by the EIP element. This modification could be undertaken within the transport protocol stack element or within the internet protocol stack element. The functional outcome from these modifications would be to create a mechanism to support the use of multiple locators within the context of single-endpoint-to-single-endpoint communication.
作为将新协议栈元素插入协议体系结构的替代方案，可以修改现有协议栈元素以包括EIP元素执行的功能。这种修改可以在传输协议栈元素内或在因特网协议栈元素内进行。这些修改的功能结果将是创建一种机制，以支持在单端点到单端点通信的上下文中使用多个定位器。
Within the transport layer, this functionality could be achieved, for example, by binding a set of locators to a single session and then communicating this locator set to the remote transport entity. This would allow the local transport entity to switch the mapping to a different locator for either the local endpoint or the remote endpoint, while maintaining the integrity of the ULP session.
在传输层内，可以实现该功能，例如，通过将一组定位器绑定到单个会话，然后将该定位器集通信到远程传输实体。这将允许本地传输实体将映射切换到本地端点或远程端点的不同定位器，同时保持ULP会话的完整性。
Within the IP level, this functionality could be supported by a form of dynamic rewriting of the packet header as it is processed by the protocol element. Incoming packets with the source and destination locators in the packet header are mapped to packets with the equivalent endpoint identifiers in both fields, and the reverse mapping is performed to outgoing packets passed from the transport layer. Mechanisms that support direct rewriting of the packet header are potential candidates in this approach. Other potential
在IP级别内，此功能可以通过在协议元素处理数据包报头时动态重写数据包报头的形式来支持。包报头中具有源和目的地定位器的传入包被映射到两个字段中具有等效端点标识符的包，并且反向映射被执行到从传输层传递的传出包。在这种方法中，支持直接重写数据包头的机制是潜在的候选机制。其他潜力
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.
在所有这些场景中都存在一些常见问题：保持什么状态，协议栈的哪个部分保持这种状态，如何通过添加和删除定位器绑定来保持状态，以及是否只有一段代码知道端点/定位器拆分，还是必须修改多个协议元素？例如，如果功能是在互联（IP）层添加的，则不存在活动传输会话的上下文，因此需要通过从传输层到互联层的一些附加机制来触发删除已终止会话的标识/定位器状态信息。
The above approaches all assume that the hosts are explicitly aware of the multi-homed environment and use modified protocol behaviour to support multi-homing functionality. A further approach to this objective is to split this functionality across a number of network elements and potentially perform packet header rewriting from a persistent endpoint identity value to a locator value at a remote point.
上述方法都假设主机明确了解多宿主环境，并使用修改后的协议行为来支持多宿主功能。实现此目标的另一种方法是将此功能跨多个网络元件分割，并可能在远程点执行从持久端点标识值到定位器值的包头重写。
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.
一种可能的方法是使用站点出口路由器执行某种形式的数据包报头操作，因为数据包从本地多宿站点传递到特定的传输提供商。本地站点路由系统将根据远程主机的定位器值选择到目标主机的最佳路径。本地主机将其端点标识写入数据包的源地址。当数据包到达站点出口路由器时，站点出口路由器将数据包的源字段重写为相应的定位器，当定位器被远程主机用作目的地定位器时，该定位器选择通过同一传输ISP的反向路径。为了保持会话完整性，必须对传入的数据包进行相应的反向转换：必须将目标定位器映射回主机的端点标识符。当数据包被传递到站点时，是否最好在站点出口路由器处执行此操作，或者由本地主机执行此操作，需要考虑很多因素。
Packet header rewriting by remote network elements has a large number of associated security considerations. Any packet rewriting mechanism has to provide proper protection against the attacks described in [threats], in particular against redirection attacks.
远程网络元素重写数据包头有大量相关的安全注意事项。任何数据包重写机制都必须针对[威胁]中描述的攻击提供适当的保护，特别是针对重定向攻击。
An alternative for packet header rewriting at the site-exit point is for the host to undertake the endpoint-to-locator mapping, using one of the approaches outlined above. The consideration here is that there is a significant deployment of unicast reverse-path filtering in Internet environments as a counter-measure to source address spoofing. Using the example in Figure 1, if a host selects a locator drawn from the ISP B address prefix and local routing directs that packet to site-exit router A, then a packet passed to ISP A would be discarded by such filters. Various approaches have been proposed to modify the behaviour of the site forwarding environment, all with the end effect that packets using a source locator drawn from the ISP B address prefix are passed to site-exit router B. These approaches include forms of source address routing and site-exit router hand-over mechanisms, as well as augmentation of the routing information between site-exit routers and local multi-homed hosts, so that the choice of locator by the local host for the remote host is consistent with the current local routing state for the local site to reach the remote host.
在站点出口点重写数据包头的另一种方法是主机使用上述方法之一进行端点到定位器的映射。这里需要考虑的是，在Internet环境中，作为源地址欺骗的一种对抗措施，单播反向路径过滤的部署非常重要。使用图1中的示例，如果主机选择从ISP B地址前缀提取的定位器，并且本地路由将该数据包定向到站点出口路由器a，则传递给ISP a的数据包将被此类过滤器丢弃。已经提出了各种方法来修改站点转发环境的行为，所有这些方法的最终效果是使用从ISP B地址前缀提取的源定位器的数据包被传递到站点出口路由器B。这些方法包括源地址路由和站点出口路由器移交机制的形式，以及增强站点出口路由器和本地多宿主主机之间的路由信息，以便本地主机为远程主机选择的定位器与本地站点到达远程主机的当前本地路由状态一致。
Both the approach of the addition of an identity protocol element and the approach of modification of an existing protocol element assume some form of exchange of information that allows both parties to the communication to be aware of the other party's endpoint identity and the associated mapping to locators. There are a number of possible approaches for implementing this information exchange.
添加身份协议元素的方法和修改现有协议元素的方法都假定某种形式的信息交换，该信息交换允许通信双方知道另一方的端点身份和与定位器相关联的映射。有许多可能的方法来实现这种信息交换。
The first such possible approach, termed here a "conventional" approach, encapsulates the protocol data unit (PDU) passed from the ULP with additional data elements that specifically refer to the function of the EIP. The compound data element is passed to the LLP as its PDU. The corresponding actions on receipt of a PDU from a LLP is to extract the fields of the data unit that correspond to the EIP function, and pass the remainder of the PDU to the ULP. The EIP operates in an "in-band" mode, communicating with its remote peer entity through additional information wrapped around the ULP PDU. This is equivalent to generic tunnelling approaches where the outer encapsulation of the transmitted packet contains location address information, while the next-level packet header contains information that is to be exposed and used at the location endpoints and, in this case, is identity information.
第一种这种可能的方法，在这里称为“传统”方法，将从ULP传递的协议数据单元（PDU）封装为特定于EIP功能的附加数据元素。复合数据元素作为其PDU传递给LLP。从LLP接收PDU时的相应操作是提取与EIP功能对应的数据单元字段，并将PDU的其余部分传递给ULP。EIP以“带内”模式运行，通过围绕ULP PDU的附加信息与其远程对等实体通信。这相当于一般隧道方法，其中传输的分组的外部封装包含位置地址信息，而下一级分组报头包含将在位置端点公开和使用的信息，并且在这种情况下是身份信息。
Another approach is to allow the EIP to communicate using a separate communications channel, where an EIP generates dedicated messages that are directed to its peer EIP, and it passes these PDUs to the LLP independently of the PDUs that are passed to the EIP from the
另一种方法是允许EIP使用单独的通信信道进行通信，其中EIP生成定向到其对等EIP的专用消息，并且它将这些pdu独立于从网络传递到EIP的pdu传递到LLP
ULP. This allows an EIP to exchange information and synchronise state with the remote EIP semi-independently of the ULP protocol exchange. As one part of the EIP function is to transform the ULP PDU to include locator information, there is an associated requirement to ensure that the EIP peering state remains synchronised to the exchange of ULP PDUs, so that the remote EIP can correctly recognise the locator-to-endpoint mapping for each active session.
乌尔普。这允许EIP半独立于ULP协议交换与远程EIP交换信息和同步状态。由于EIP功能的一部分是转换ULP PDU以包含定位器信息，因此存在相关要求以确保EIP对等状态与ULP PDU的交换保持同步，以便远程EIP能够正确识别每个活动会话的定位器到端点映射。
Another potential approach here is to allow the endpoint-to-locator mappings to be held by a third party. This model is already used for supporting the name-to-IP address mappings performed by the Domain Name System (DNS), where the mapping is obtained by reference to a third party, namely, a DNS resolver. A similar form of third-party mapping between endpoints and a locator set could be supported through the use of the DNS or a similar third party referential mechanism. Rather than have each party exchange endpoint-to-locator mappings, this approach would obtain this mapping as a result of a lookup for a DNS Endpoint-to-Locator set map contained as DNS Resource Records, for example.
另一种可能的方法是允许端点到定位器的映射由第三方持有。此模型已用于支持域名系统（DNS）执行的名称到IP地址的映射，其中映射通过引用第三方（即DNS解析程序）获得。通过使用DNS或类似的第三方引用机制，可以支持端点和定位器集之间类似形式的第三方映射。例如，这种方法不是让各方交换端点到定位器的映射，而是通过查找包含为DNS资源记录的DNS端点到定位器集映射来获得此映射。
The previous section has used the term "endpoint identity" without examining what form this identity may take. A number of salient considerations regarding the structure and form of this identity should be enumerated within an architectural overview of this space.
上一节使用了术语“端点标识”，但没有检查该标识可能采用的形式。关于该标识的结构和形式，应在该空间的建筑概述中列举一些显著的考虑因素。
One possible form of an identity is the use of identity tokens lifted from the underlying protocol's "address space". In other words an endpoint identity is a special case instance of an IPv6 protocol address. There are a number of advantages in using this form of endpoint identity, since the suite of IP protocols and associated applications already manipulates IP addresses. The essential difference in a domain that distinguishes between endpoint identity and locator is that the endpoint identity parts of the protocol would operate on those addresses that assume the role of endpoint identities, and the endpoint identity/locator mapping function would undertake a mapping from an endpoint "address" to a set of potential locator "addresses". It would also undertake a reverse mapping from a locator "address" to the distinguished endpoint identifier "address". The IP address space is hierarchically structured, permitting a suitably efficient mapping to be performed in both directions. The underlying semantics of addresses in the context of public networking includes the necessary considerations of global uniqueness of endpoint identity token values.
身份的一种可能形式是使用从底层协议的“地址空间”提取的身份令牌。换句话说，端点标识是IPv6协议地址的特例实例。使用这种形式的端点标识有许多优点，因为IP协议套件和相关应用程序已经在操纵IP地址。在区分端点标识和定位器的域中，本质区别在于协议的端点标识部分将在承担端点标识角色的地址上操作，并且端点标识/定位器映射功能将从端点“地址”进行映射到一组潜在的定位器“地址”。它还将进行从定位器“地址”到可分辨端点标识符“地址”的反向映射。IP地址空间是分层结构的，允许在两个方向上执行适当有效的映射。公共网络环境中地址的基本语义包括端点标识令牌值的全局唯一性的必要考虑。
It is possible to take this approach further and allow the endpoint identifier to also be a valid locator. This would imply the existence of a "distinguished" or "home" locator, and other locators could be dynamically mapped to this initial locator peering as required. The drawback of this approach is that the endpoint identifier is now based on one of the transit provider's address prefixes, and a change of transit provider would necessarily require a change of endpoint identifier values within the multi-homed site.
可以进一步采用这种方法，并允许端点标识符也是有效的定位器。这意味着存在“可分辨”或“主”定位器，其他定位器可以根据需要动态映射到此初始定位器对等。这种方法的缺点是端点标识符现在基于传输提供程序的一个地址前缀，传输提供程序的更改必然需要更改多宿站点内的端点标识符值。
An alternative approach for address-formatted identifiers is to use distinguished identity address values that are not part of the global unicast locator space, allowing applications and protocol elements to distinguish between endpoint identity values and locators based on address prefix value.
地址格式化标识符的另一种方法是使用不属于全局单播定位器空间的可分辨标识地址值，允许应用程序和协议元素基于地址前缀值区分端点标识值和定位器。
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.
还可以允许端点标识和定位器空间重叠，并通过使用上下文而不是通过前缀比较来区分这两个领域。然而，对于标识令牌的定位器令牌空间的这种重用有可能造成异常情况，其中特定定位器值被不同端点用作标识值。不清楚在每种情况下是否都能清楚地消除身份和定位器上下文的歧义，这是这种特定方法的一个主要缺点。
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.
如果要从协议的地址空间中提取标识值，那么基本的选择似乎是要么从地址空间的不同部分提取这些标识值，要么使用可分辨地址或家庭地址作为定位器和标识。后一种选择，即使用定位器作为定位器上端点标识的基础，当与提供者聚合地址分发体系结构结合时，导致使用基于提供者的地址前缀作为公共标识前缀的多宿主站点。与单宿网络中的定位器地址一样，提供商连接的更改意味着多宿站点中的身份重新编号。如果避免这种强制重新编号是本文的目标，那么从与网络拓扑不一致的池中提取标识标记将是一种首选。这可能表明该扇区倾向于使用非从定位器地址空间提取的标识令牌值。
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可以在会话建立的上下文中使用，DNS查询可以用于建立一组初始定位器。当然，情况也可能并非如此
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.
这两个不同身份领域的句法属性在PDU中使用这些身份的方式方面有着明显的考虑。
It is also an option to consider a new structured identity space that is neither generated through the reuse of IPv6 address values nor drawn from the FQDN. Given that the address space would need to be structured to permit its use as a lookup key to obtain the corresponding locator set, the obvious question is what additional or altered characteristics would be used in such an endpoint identity space that would distinguish it from either of the above approaches?
它也可以考虑一个新的结构化标识空间，它既不是通过重用IPv6地址值生成的，也不是从FQDN中提取的。鉴于需要对地址空间进行结构化，以允许将其用作查找键以获得相应的定位器集，显而易见的问题是，在这样一个端点标识空间中，将使用哪些附加或更改的特征，从而将其与上述两种方法中的任何一种区分开来？
Instead of structured tokens that double as lookup keys to obtain mappings from endpoint identities to locator sets, the alternative is to use an unstructured token space, where individual token values are drawn opportunistically for use within a multi-homed session context. If such unstructured tokens are used in a limited context, then the semantics of the endpoint identity are subtly changed. The endpoint identity is not a persistent alias or reference to the identity of the endpoint, but it is a means to allow the identity protocol element to confirm that two locators are part of the same mapped locator set for a remote endpoint. In this context, the unstructured opportunistic endpoint identifier values are used in determining locator equivalence rather than in some form of lookup function.
替代的方法是使用非结构化令牌空间，在该空间中，可以机会主义地绘制单个令牌值，以便在多宿主会话上下文中使用，而不是同时用作查找键以获得从端点标识到定位器集的映射。如果在有限的上下文中使用这种非结构化标记，那么端点标识的语义会发生微妙的变化。端点标识不是端点标识的持久别名或引用，而是允许identity protocol元素确认两个定位器是远程端点的同一映射定位器集的一部分的一种方法。在此上下文中，非结构化机会端点标识符值用于确定定位器等价性，而不是某种形式的查找函数。
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.
上一节中的注意事项强调了支持身份和位置信息分离的方法中差异的一个主要方面。
One form uses a persistent identity field, by which it is inferred that the same identity value is used in all contexts in which this form of identity is required, in support of concurrent sessions as well as sequential sessions. This form of identity is intended to remain constant over time and over changes in the underlying connectivity. It may also be the case that this identity is completely distinct from network topology, so that the same identity is used irrespective of the current connectivity and locator addressing used by the site and the host. In this case, the identity is persistent, and the identity value can be used as a reference to the endpoint stack. This supports multi-party referrals, where, if
一种形式使用一个持久标识字段，通过该字段可以推断，在需要这种形式标识的所有上下文中使用相同的标识值，以支持并发会话和顺序会话。这种形式的身份旨在随着时间和基础连接的变化保持不变。也可能是这种情况，即此标识与网络拓扑完全不同，因此无论站点和主机使用的当前连接和定位器地址如何，都会使用相同的标识。在这种情况下，标识是持久的，标识值可以用作端点堆栈的引用。这支持多方转介，如果
parties A and B establish a communication, B can pass A's identity to a third party C, who can then use this identity value to be the active party in establishing communication to A.
当A方和B方建立通信时，B方可以将A方的身份传递给第三方C，然后第三方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.
如果要使用持久标识符来启动会话，则该标识将用作查找键，以建立一组与已识别端点关联的定位器。希望该查找函数具有确定性、可靠性、健壮性、高效性和可信任性。这意味着这些身份必须是唯一分配的，身份系统的经验表明，人们强烈倾向于使用具有令牌组件内部层次结构的结构化身份令牌空间。这些标识属性与单播地址和域名的标识属性具有显著的共性。这里的进一步含义是，持久的结构化身份还依赖于采用有序的分布和管理机制来保持其完整性和实用性。这种机制通常意味着在管理任务方面有很大的开销。
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.
如前一节所述，身份的另一种形式是非结构化身份空间，其中特定的值是机会主义地从该空间中提取的。在这种情况下，无法确保任何特定标识值的唯一性。由于空间的非结构化性质对查找的效率有影响，并且由于无法确保标识键值的唯一性，查找的真实性被削弱，因此使用此类标识作为查找键来建立定位器也被改变。非结构化身份的保守方法限制了它们的实用范围，例如每会话身份密钥。在此场景中，所选标识的范围仅限于正在通信的各方，并且范围仅限于通信会话的持续时间。此限制的含义是标识是会话级绑定点，允许多个定位器绑定到会话，并且标识不能用作会话上下文之外端点的引用。这种范围明确有限的机会主义身份不需要采用任何有序的令牌分发和管理机制。
Another form of identity is an ephemeral form, where a session identity is a shared state between the endpoints, established without the exchange of particular token values that take the role of identity keys. This could take the form of a defined locator set or the form of a session key derived from some set of shared attributes of the session, for example. In this situation, there is no form of reference to or use of an identifier as a means of initiating a session. The ephemeral identity value has a very limited role in terms of allowing each end to reliably determine the semantic
身份的另一种形式是临时形式，其中会话身份是端点之间的共享状态，不需要交换作为身份密钥的特定令牌值即可建立。例如，这可以采用定义的定位器集的形式，也可以采用从会话的某个共享属性集派生的会话密钥的形式。在这种情况下，没有任何形式的标识符引用或使用标识符作为启动会话的手段。短暂标识值在允许每个端点可靠地确定语义方面的作用非常有限
equivalence of a set of locators within the context of membership of a particular session.
在特定会话的成员身份上下文中一组定位器的等价性。
The latter two forms of identity represent an approach to identity that minimises management overhead and provides mechanisms that are limited in scope to supporting session integrity. This implies that support for identity functions in other contexts and at other levels of the protocol stack, such as within referrals, within an application's data payload, or as a key to initiate a communication session with a remote endpoint, would need to be supported by some other identity function. Such per-session limited scope identities imply that the associated multi-homing approaches must use existing mechanisms for session startup, and the adoption of a session-based identity and associated locator switch agility becomes a negotiated session capability.
后两种形式的身份表示一种身份方法，该方法可以最大限度地减少管理开销，并提供范围有限的机制来支持会话完整性。这意味着在其他上下文和协议栈的其他级别（例如在引用内、在应用程序的数据有效负载内或作为启动与远程端点的通信会话的密钥）对标识函数的支持将需要由一些其他标识函数来支持。这样的每会话有限范围标识意味着相关联的多宿主方法必须使用现有的会话启动机制，并且采用基于会话的标识和相关联的定位器切换敏捷性成为协商会话能力。
On the other hand, the use of a persistent identity as a session initiation key implies that identity is part of the established session state, and locator agility can be an associated attribute of the session rather than a subsequent negotiated capability. In a heterogeneous environment where such identity capability is not uniformly deployed, this would imply that if a session cannot be established with a split identity/locator binding, the application should be able to back off to a conventional session startup by mapping the identity to a specific locator value and initiating a session using such a value. The reason why the application may want to be aware of this distinction is that if the application wishes to use self-referential mechanisms within the application payload, it would appear to be appropriate to use an identity-based self-reference only in the context of a session where the remote party was aware of the semantic properties of this referential tag.
另一方面，使用持久身份作为会话启动密钥意味着身份是已建立会话状态的一部分，并且定位器敏捷性可以是会话的相关属性，而不是后续协商能力。在这种身份功能未统一部署的异构环境中，这意味着如果无法使用拆分身份/定位器绑定建立会话，应用程序应该能够通过将标识映射到特定的定位器值并使用该值启动会话，从而退回到传统会话启动。应用程序可能希望了解这种区别的原因是，如果应用程序希望在应用程序有效负载内使用自引用机制，似乎只在远程方知道该引用标记的语义属性的会话上下文中使用基于身份的自引用是合适的。
In terms of functionality and semantics, opportunistic identities form a superset of ephemeral identities, although their implementation is significantly different. Persistent identities support a superset of the functionality of opportunistic identities, and again the implementations will differ.
在功能和语义方面，机会主义身份形成了短暂身份的超集，尽管它们的实现有显著不同。持久身份支持机会主义身份功能的超集，实现也会有所不同。
In the context of support for multi-homing configurations, use of ephemeral identities in the context of locator equivalence appears to represent a viable approach that allows a negotiated use of multiple locators within the context of communication between a pair of hosts in most contexts of multi-homing. However, ephemeral identities offer little more in terms of functionality. They cannot be used in referential contexts, cannot be used to initiate communications, provide limited means of support for various forms of mobility, and impose some constraints on the class of multi-homed scenarios that can be supported. Ephemeral identities are generated in the context
在支持多归属配置的背景下，在定位器等效的背景下使用临时身份似乎代表了一种可行的方法，该方法允许在多归属的大多数背景下，在一对主机之间的通信背景下协商使用多个定位器。然而，短暂的身份在功能方面提供的功能很少。它们不能用于参考上下文，不能用于启动通信，为各种形式的移动提供有限的支持手段，并对可支持的多宿场景类别施加一些限制。短暂的身份是在上下文中生成的
of an established communication state, and the implication in terms of multi-homing is that the two end points need to have discovered through existing mechanisms a viable pair of locators prior to generating an ephemeral identity binding. The implication is that there is some form of static "home" for the end points that is discovered by conventional referential lookup.
在多归宿方面的含义是，在生成短暂的身份绑定之前，两个端点需要通过现有机制发现一对可行的定位器。这意味着，对于通过常规引用查找发现的端点，存在某种形式的静态“home”。
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.
持久标识空间的使用支持在一组等效定位器和一个或多个等效标识值之间进行动态转换，这为应用程序提供了更大的灵活性。根据身份和定位器之间的映射是如何管理的，这可能会超出多归属配置，扩展到游牧和移动的各种环境以及特定于服务的功能。然而，在更一般的身份到定位器映射环境中，安全映射机制的性质仍然是一个悬而未决的问题，映射功能如何与可行的端点到端点连接相关也是一个悬而未决的问题。身份领域的一个常见方面是，该领域最关键的方面是将身份解析到其他属性空间的性质。
It appears reasonable to observe that, within certain constraints, multi-homing does not generically require the overhead of a fully distinct persistent identity space and the associated identity resolution functionality, and, if the nature of the multi-homing space in this context is to use a token to allow efficient detection of locator equivalence for session surviveability, then ephemeral identities appear to be an adequate mechanism.
可以合理地观察到，在某些约束条件下，多归宿通常不需要完全不同的持久身份空间和相关身份解析功能的开销，并且，如果在此上下文中多归属空间的性质是使用令牌来允许有效检测用于会话生存性的定位器等价性，那么短暂身份似乎是一种适当的机制。
The above overview encompasses a very wide range of potential approaches to multi-homing, and each particular approach necessarily has an associated set of considerations regarding its applicability.
上述概述涵盖了一系列非常广泛的多归宿潜在方法，每种特定方法都必须考虑其适用性。
There is, however, a set of considerations that appear to be common across all approaches. They are examined in further detail in this section.
然而，在所有方法中，似乎都有一组共同的考虑因素。本节将对其进行更详细的研究。
Ultimately, regardless of the method of generation, a packet generated from a local multi-homed host to a remote host must carry a source locator when it is passed into the transit network. In a multi-homed situation, the local multi-homed host has a number of self-referential locators that are equivalent aliases in almost every respect. The difference between locators is the inference that, at
最终，无论生成方法如何，从本地多宿主主机生成的数据包在传递到传输网络时必须携带源定位器。在多宿主情况下，本地多宿主主机具有许多自引用定位器，这些定位器在几乎所有方面都是等效的别名。定位器之间的区别在于，在
the remote end, the choice of locator may determine the path used to send a packet back to the local multi-homed host. The issue here is: how does the local host make a selection of the "best" source locator to use? Obviously, an objective is to select a locator that represents a currently viable path from the remote host to the local multi-homed host. Local routing information for the multi-homed host does not include this reverse path information. Equally, the local host does not necessarily know any additional policy constraints that apply to the remote host and that may result in a remote host's preference to use one locator over another for the local host. Considerations of unicast reverse-path forwarding filters also indicate that the selection of a source locator should result in the packet being passed to a site-exit router that is connected to the associated ISP transit provider, and that the site-exit router passes the packet to the associated ISP.
在远程端，定位器的选择可以确定用于将分组发送回本地多宿主机的路径。这里的问题是：本地主机如何选择要使用的“最佳”源定位器？显然，目标是选择一个定位器，该定位器表示从远程主机到本地多主机主机的当前可行路径。多宿主主机的本地路由信息不包括此反向路径信息。同样，本地主机不一定知道应用于远程主机的任何附加策略约束，这些约束可能导致远程主机倾向于对本地主机使用一个定位器而不是另一个定位器。单播反向路径转发过滤器的考虑还表明，源定位器的选择应导致将分组传递给连接到相关ISP传输提供商的站点出口路由器，并且站点出口路由器将分组传递给相关ISP。
If the local multi-homed host is communicating with a remote multi-homed host, the local host may have some discretion in the choice of a destination locator. The considerations relating to the selection of a destination locator include considerations of local routing state (to ensure that the chosen destination locator reflects a viable path to the remote endpoint) and policy constraints that may determine a "best" path to the remote endpoint. It may also be the case that the source address selection should be considered in relation to the destination locator selection.
如果本地多宿主主机正在与远程多宿主主机通信，则本地主机在选择目标定位器方面可能有一定的自由裁量权。与目的地定位器的选择相关的考虑包括本地路由状态的考虑（以确保所选目的地定位器反映到远程端点的可行路径）和可确定到远程端点的“最佳”路径的策略约束。也可能是源地址选择应考虑与目的地定位器选择相关的情况。
Another common issue is the point when a locator is not considered to be viable and the consequences to the transport session state.
另一个常见问题是定位器被认为不可行以及对传输会话状态的后果。
o Transport Layer Triggers
o 传输层触发器
A change in state for a currently-used path to another path could be triggered by indications of packet loss along the current path by transport-level signalling or by transport session timeouts, assuming an internal signalling mechanism between the transport stack element and the locator pool management stack element.
假设传输堆栈元素和定位器池管理堆栈元素之间存在内部信令机制，则当前使用的路径到另一路径的状态变化可以通过传输级别信令或传输会话超时沿当前路径的分组丢失指示来触发。
o ICMP Triggers
o ICMP触发器
Path failure within the network may generate an ICMP Destination Unreachable packet being directed back to the sender. Rather than sending this signal to the transport level as an indicator of session failure, the IP layer should redirect the notification identity module as a trigger for a locator switch.
网络内的路径故障可能会产生一个ICMP目的地无法到达的数据包，该数据包被定向回发送方。IP层应该重定向通知标识模块作为定位器交换机的触发器，而不是将此信号发送到传输层作为会话失败的指示器。
o Routing Triggers
o 路由触发器
Alternatively, in the absence of local transport triggers, the site-exit router could communicate failure of the outbound forwarding path in the case that the remote host is multi-homed with an associated locator set. Conventional routing would be incapable of detecting a failure in the inbound forwarding path, so there are some limitations in the approach of using routing triggers to change locator bindings.
或者，在没有本地传输触发器的情况下，站点出口路由器可以在远程主机与相关联的定位器集是多宿的情况下通信出站转发路径的故障。传统路由无法检测入站转发路径中的故障，因此使用路由触发器更改定位器绑定的方法存在一些限制。
o Heartbeat Triggers
o 心跳触发器
An alternative to these approaches is the use of a session heartbeat protocol, where failure of the heartbeat would cause the session to seek a new locator binding that would reestablish the heartbeat.
这些方法的一种替代方法是使用会话心跳协议，其中心跳失败将导致会话寻找新的定位器绑定，该绑定将重新建立心跳。
o Link Layer Triggers
o 链接层触发器
Where supported, link layer triggers could be used as a direct and immediate signal of link availability, where a "Link Down" indication indicates the unavailability of a particular link [iab-link]. The limitation of this approach is that a link level indication is not a network broadcast event, and only the link's immediately-connected devices receive the link transition signal. While this approach may be relevant to the degenerate case of a multi-homed site composed of a single host, in the case of a multi-host site the link indication would need to be used by the site-exit router to generate one of the above indications for the host to be triggered for a locator change. In this case this is a conventional form of router detection of link status.
在支持的情况下，链路层触发器可用作链路可用性的直接和即时信号，其中“链路断开”指示指示特定链路不可用[iab链路]。该方法的限制在于链路级别指示不是网络广播事件，并且只有链路的直接连接设备接收链路转换信号。虽然这种方法可能与由单个主机组成的多主机站点的退化情况有关，但在多主机站点的情况下，站点出口路由器需要使用链路指示来为要触发定位器更改的主机生成上述指示之一。在这种情况下，这是路由器检测链路状态的常规形式。
The sensitivity of the locator switch trigger is a consideration here. A very fine-grained sensitivity of the locator switch trigger may generate false triggers arising from short-term transient path congestion, while coarse-grained triggers may impose an undue performance penalty on the session due to an extended time to detect a path failure. The objectives for sensitivity to triggers may be very different depending on the transport session being used. There is no doubt that any session would need a trigger to re-home if its path to the locator fails, but for some transports, moving, and triggering transport-related changes, may be far less desirable than reducing the sensitivity of the trigger and waiting to see if the triggering stimulus achieves a threshold level.
这里需要考虑定位器开关触发器的灵敏度。定位器开关触发器的细粒度敏感度可能会产生由短期瞬态路径拥塞引起的错误触发器，而粗粒度触发器可能会由于检测路径故障的时间延长而对会话施加不适当的性能惩罚。根据所使用的传输会话，对触发器敏感的目标可能会非常不同。毫无疑问，如果到达定位器的路径失败，任何会话都需要一个触发器来重新回家，但对于某些传输，移动和触发传输相关的更改可能远不如降低触发器的灵敏度并等待触发刺激是否达到阈值水平。
This problem is only partly solved by models with an internal signalling mechanism between the transport stack element and the locator pool management stack element, because of non-failure
由于无故障，在传输堆栈元素和定位池管理堆栈元素之间具有内部信令机制的模型只能部分解决此问题
triggers coming from other stacks, and because of transport issues such as use of resource reservation. As an example, consider the case of a session with reservations established by RSVP or NSIS, when a routing change has just caused adaptive updates to the reservation state in a number of elements along its path. The transport protocol using the path is likely to see some delays or timeouts, and its reaction to these events may be a trigger for a locator change, which is likely to mean another reservation update. This chaining of reservation updates may represent a high overhead. The implication here is that individual transport protocols may have to tune any feedback they give as a locator change trigger, so that they don't respond to certain forms of transient routing change delays (not knowing their cause) with a locator change trigger. It should also be noted that different transport protocols have rather different behaviors and hooks for management.
触发器来自其他堆栈，并且由于传输问题，例如资源保留的使用。作为一个例子，考虑RSIP或NSIS所建立的保留的会话的情况，当路由改变仅仅导致沿其路径的多个元素中的保留状态的自适应更新时。使用该路径的传输协议可能会出现一些延迟或超时，其对这些事件的反应可能会触发定位器更改，这可能意味着另一个保留更新。这种预订更新链接可能会带来很高的开销。这里的含义是，单个传输协议可能必须调整它们作为定位器更改触发器提供的任何反馈，以便它们不会使用定位器更改触发器响应某些形式的瞬态路由更改延迟（不知道其原因）。还应注意，不同的传输协议具有相当不同的行为和管理挂钩。
The selection of a locator to use for the remote end is obviously constrained by the current state of the topology of the network, and the primary objective of the selection process is to choose a viable locator that allows the packet to reach the intended destination point. The selection of a source locator can be considered as an indication of preference to the remote end of a preferred locator to use for the local end. However, where there are two or more viable locators that could be used, the selection of a particular locator may be influenced by a set of additional considerations.
要用于远程端的定位器的选择显然受到网络拓扑的当前状态的约束，并且选择过程的主要目标是选择允许分组到达预定目的地的可行定位器。源定位器的选择可被视为对用于本地端的优选定位器的远端的偏好的指示。然而，如果可以使用两个或多个可行的定位器，则特定定位器的选择可能会受到一组附加考虑的影响。
The selection of a particular locator from a viable locator set implies a selection of one particular network path in preference to other viable paths. An implication of this host-based locator selection process is that path selection and, by inference, traffic engineering functions are not constrained to a network-based operation of path manipulation through adjustment of forwarding state within network elements. There is a consequent interaction between the locator selection process and traffic engineering functions. The use of an address selection policy table, as described in RFC 3484 [RFC3484], is relevant to the selection process.
从可行定位器集中选择特定定位器意味着优先选择一条特定网络路径而不是其他可行路径。这种基于主机的定位器选择过程的含义是，路径选择以及由此推断的流量工程功能不限于通过调整网络元件内的转发状态来进行基于网络的路径操纵操作。定位器选择过程和交通工程功能之间存在着相互作用。如RFC 3484[RFC3484]所述，地址选择策略表的使用与选择过程有关。
The element that performs the locator selection, either as a protocol element within the host or as a selection undertaken at a site-exit router, also determines traffic policy, so the choice of using remote packet locator rewriting or host based locator selection shifts the policy capability from one element to the other.
执行定位器选择的元件（作为主机内的协议元件或作为在站点出口路由器进行的选择）也确定通信策略，因此使用远程分组定位器重写或基于主机的定位器选择的选择将策略能力从一个元件转移到另一个元件。
If hosts perform this policy determination, then a more fine-grained outcome may be achievable, particularly if the anticipated traffic characteristics of the application can be signalled to the locator
如果主机执行此策略确定，则可以实现更细粒度的结果，特别是如果应用程序的预期流量特性可以用信号通知定位器
selection process. A further consideration appears to be that hosts may require additional information if they are to make locator address selection decisions based on some form of metric of relative load currently being imposed on select components of a number of end-to-end network paths. These considerations raise the broader issue of traffic engineering being a network function entirely independent of host function or an outcome of host interaction with the network.
选择过程。进一步的考虑似乎是，如果主机要基于当前施加在多个端到端网络路径的选择组件上的某种形式的相对负载度量来做出定位器地址选择决策，则主机可能需要额外的信息。这些考虑提出了更广泛的流量工程问题，即完全独立于主机功能的网络功能或主机与网络交互的结果。
In the latter case, there is also the consideration of whether the host is to interact with the network, and, if so, how this interaction is to be signalled to hosts.
在后一种情况下，还需要考虑主机是否与网络进行交互，如果是，如何向主机发送该交互信号。
The consideration of triggering locator switch highlights the observation that differing information and context are present in each layer of the protocol stack. This impacts on how identity/locator bindings are established, maintained, and expired.
触发定位器开关的考虑突出了以下观察结果：协议栈的每一层中存在不同的信息和上下文。这会影响标识/定位器绑定的建立、维护和过期方式。
These impacts include questions of what amount of state is kept, by which element of the protocol stack, and at what level of context (dynamic or fixed, and per session or per host). It also includes considerations of state maintenance, such as how stale or superfluous state information is detected and removed. Does only one piece of code have to be aware of this identity/locator binding, or do multiple transport protocols have to be altered to support this functionality? If so, are such changes common across all transport protocols, or do different protocols require different considerations in their treatment of this functionality?
这些影响包括以下问题：保留了多少状态、协议栈的哪个元素以及上下文的级别（动态或固定、每个会话或每个主机）。它还包括对状态维护的考虑，例如如何检测和删除陈旧或多余的状态信息。是否只有一段代码需要知道此标识/定位器绑定，或者是否需要更改多个传输协议以支持此功能？如果是这样，那么这些更改是否在所有传输协议中都很常见，或者不同的协议在处理此功能时是否需要考虑不同的因素？
It is noted that the approaches considered here include proposals to place this functionality within the IP layer, with the end-to-end transport protocol layer and as a shim between the IP and transport protocol layers.
需要注意的是，这里考虑的方法包括将此功能放在IP层内、端到端传输协议层以及作为IP和传输协议层之间的垫片的建议。
Placing this identity functionality at the transport protocol layer implies that the identity function can be tightly associated with a transport session. In this approach, session startup can trigger the identity/locator initial binding actions and transport protocol timeouts can be used as triggers for locator switch actions. Session termination can trigger expiration of local identity/locator binding state. Where per-session opportunistic identity token values are being used, the identity information can be held within the overall session state. In the case of persistent identity token values, the implementation of the identity can also choose to use per-session state, or it may choose to pool this information across multiple sessions in order to reduce overheads of dynamic discovery of
将此标识功能置于传输协议层意味着标识功能可以与传输会话紧密关联。在这种方法中，会话启动可以触发标识/定位器初始绑定操作，传输协议超时可以用作定位器切换操作的触发器。会话终止可触发本地标识/定位器绑定状态过期。在使用每会话机会主义标识令牌值的情况下，标识信息可以保存在整个会话状态中。在持久标识令牌值的情况下，标识的实现还可以选择使用每个会话状态，或者可以选择在多个会话之间共享此信息，以减少动态发现令牌的开销
identity/locator bindings for remote identities in the case of multiple sessions to the same remote endpoint.
在多个会话到同一远程端点的情况下，远程标识的标识/定位器绑定。
One of the potential drawbacks of placing this functionality within the transport protocol layer is that it is possible that each transport protocol will require a distinct implementation of identity functionality. This is a considerable constraint in the case of UDP, where the UDP transport protocol has no inherent notion of a session state.
将此功能放在传输协议层中的一个潜在缺点是，每个传输协议都可能需要不同的身份功能实现。对于UDP，这是一个相当大的限制，UDP传输协议没有会话状态的固有概念。
An alternative approach is to use a distinct protocol element placed between the transport and internet layers of the protocol stack. The advantage of this approach is that it would offer a consistent mapping between identities and locators for all forms of transport protocols. However this protocol element would not be explicitly aware of sessions and would either have to discover the appropriate identity/locator mapping for all identity-addressed packets passed from the transport protocol later, irrespective of whether such a mapping exists and whether this is part of a session context, or have an additional mechanism of signalling to determine when such a mapping is to be discovered and applied. At this level, there is also no explicit knowledge of when identity/locator mapping state is no longer required, as there is no explicit signalling of when all flows to and from a particular destination have stopped and resources consumed in supporting state can be released. Also, such a protocol element would not be aware of transport-level timeouts, so that additional functionality would need to be added to the transport protocol to trigger a locator switch at the identity protocol level. Support of per-session opportunistic identity structure is more challenging in this environment, as the transport protocol layer is used to store and manipulate per-session state. In constructing an identity element at this level of the protocol stack, it would appear necessary to ensure that an adequate amount of information is being passed between the transport protocol, internet protocol, and identity protocol elements, to ensure that the identity protocol element is not forced into making possibly inaccurate assumptions about the current state of active sessions or end-to-end network paths.
另一种方法是在协议栈的传输层和internet层之间使用不同的协议元素。这种方法的优点是，它将为所有形式的传输协议提供身份和定位器之间的一致映射。然而，该协议元素不会明确地意识到会话，并且必须为稍后从传输协议传递的所有标识寻址数据包发现适当的标识/定位器映射，而不管这种映射是否存在以及这是否是会话上下文的一部分，或者有一个额外的信号机制来确定何时发现和应用这种映射。在这个级别上，也没有关于何时不再需要标识/定位器映射状态的明确信息，因为没有关于何时停止进出特定目的地的所有流以及何时可以释放在支持状态中消耗的资源的明确信号。此外，这样的协议元素将不知道传输级别超时，因此需要向传输协议添加附加功能以在身份协议级别触发定位器开关。在这种环境中，支持每会话机会身份结构更具挑战性，因为传输协议层用于存储和操作每会话状态。在协议栈的这一级别构造标识元素时，似乎有必要确保在传输协议、互联网协议和标识协议元素之间传递足够数量的信息，确保身份协议元素不会被迫对活动会话或端到端网络路径的当前状态做出可能不准确的假设。
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
也可以将此标识功能嵌入协议栈的internet协议层中。如前一节所述，身份模块不容易获得每会话信息，因此在这种方法中支持机会主义每会话身份值将是一个挑战。确定何时设置和发布身份/定位器状态信息也是一项挑战。似乎还需要向标识模块发送传输级超时信号，作为定位器开关触发器。在这种情况下，需要注意
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数据包报头中的地址字段进行更改，从而在远程端触发在正确上下文中无法识别数据包的情况。
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).
在拆分端点标识符/定位器环境中，需要至少有一个与端点标识符关联的初始定位器，以便在两台主机之间建立初始连接。可以以常规方式将该定位器加载到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首先映射到端点标识值，然后该端点标识值可以映射到定位器集。然后，该集合中的定位器是候选定位器，用于在两个主机之间建立初始同步状态。一旦建立状态，就可以用当前可用定位器集更新初始定位器集。此更新可以是初始同步操作的一部分，也可以推迟到需要时。
This leads to the concept of a "distinguished" locator that acts as the endpoint identifier, and a pool of alternative locators that are associated with this "home" locator. This association may be statically defined, using referential pointers in a third-party referral structure (such as the DNS), or dynamically added to the session through the actions of the EIP, or both.
这就引出了充当端点标识符的“可分辨”定位器的概念，以及与该“主”定位器关联的替代定位器池。该关联可以使用第三方引用结构（如DNS）中的引用指针静态定义，也可以通过EIP的操作动态添加到会话中，或者两者兼而有之。
If opportunistic identities are used where the identity is not a fixed discoverable value but one that is generated in the context of a session, then additional actions must be performed at session startup. In this case, there is still the need for defined locators that are used to establish a session, but then an additional step is required to generate session keys and exchange these values in order to support the identity equivalence of multiple locators within the ensuing session. This may take the form of a capability exchange and an additional handshake and associated token value exchange within the transport protocol if an in-band approach is being used, or it may take the form of a distinct protocol exchange at the level of the
如果在标识不是固定的可发现值而是在会话上下文中生成的值的情况下使用机会主义标识，则必须在会话启动时执行其他操作。在这种情况下，仍然需要使用已定义的定位器来建立会话，但是随后需要额外的步骤来生成会话密钥并交换这些值，以便在随后的会话中支持多个定位器的身份等价性。如果使用带内方法，这可以采取传输协议内的能力交换和附加握手以及相关联的令牌值交换的形式，或者也可以采取传输协议级别的不同协议交换的形式
identity protocol element, performed out-of-band from the transport session.
标识协议元素，从传输会话带外执行。
Some approaches are capable of a further distinction, namely, that of initial session establishment and that of establishment of additional shared state within the session to allow multiple locators to be treated as being bound to a common endpoint identity. It is not strictly necessary that such additional actions be performed at session startup, but it appears that such actions need to be performed prior to any loss of end-to-end connectivity on the selected initial locator, so that any delay in this additional state exchange does increase the risk of session disruption due to connectivity changes.
一些方法能够进一步区分，即初始会话建立的方法和在会话内建立附加共享状态的方法，以允许将多个定位器视为绑定到公共端点标识。严格来说，在会话启动时不必执行此类附加操作，但似乎需要在所选初始定位器上的端到端连接丢失之前执行此类操作，因此此附加状态交换中的任何延迟都会增加由于连接更改而导致会话中断的风险。
This raises a further question of whether the identity/locator split is a capability negotiation performed per session or per remote end, or whether the use of a distinguished identity value by the upper level application to identify the remote end triggers the identity/locator mapping functionality further down in the protocol stack at the transport level, without any further capability negotiation within the session.
这进一步提出了一个问题，即身份/定位器拆分是针对每个会话还是针对每个远程终端执行的能力协商，或者上层应用程序使用可分辨身份值来标识远程端是否会触发传输层协议栈中更底层的身份/定位器映射功能，而不会在会话中进行任何进一步的能力协商。
Within the steps related to session startup, there is also the consideration that the passive end of the connection follows a process where it may need to verify the proposed new address contained in the source address of incoming packets before using it as a destination address for outgoing packets. It is not necessarily the case that the sender's choice of source address reflects a valid path from the receiver back to the source. While using this offered address appears to offer a low-overhead response to connection attempts, if this response fails the receiver may need to discover the full locator set of the remote end through some locator discovery mechanism, to establish whether there is a viable locator that can use a forwarding path that reaches the remote end.
在与会话启动相关的步骤中，还考虑到连接的被动端遵循一个过程，在该过程中，它可能需要验证包含在传入分组的源地址中的提议的新地址，然后再将其用作传出分组的目的地地址。发送方选择的源地址不一定反映了从接收方返回源的有效路径。虽然使用此提供的地址似乎为连接尝试提供低开销响应，但如果此响应失败，则接收器可能需要通过一些定位器发现机制发现远程端的完整定位器集，以确定是否存在可使用到达远程端的转发路径的可行定位器。
Alternatively, the passive end would use the initially offered locator and, if this is successful, leave it to the identity modules in each stack to exchange information to establish the current complete locator set for each end. This approach implies that the active end of a communication needs to cycle through all of its associated locators as source addresses until it receives a response or exhausts its locator set. If the other end is also multi-homed (and therefore has multiple locators), then the active end may need to cycle through all possible destination locators for each source locator. While this may extend the time to confirm that no path exists to the remote end, it has the potential to improve the
或者，被动端将使用最初提供的定位器，如果成功，则将其留给每个堆栈中的标识模块来交换信息，以建立每个端的当前完整定位器集。这种方法意味着通信的活动端需要在其所有关联的定位器之间循环作为源地址，直到接收到响应或耗尽定位器集。如果另一端也是多址的（因此具有多个定位器），则活动端可能需要循环遍历每个源定位器的所有可能的目标定位器。虽然这可能会延长确认不存在到远程端的路径的时间，但它有可能改善性能
characteristics of the initial exchange against denial-of-service attacks that could force the remote end to engage in a high volume of spurious locator lookups.
针对拒绝服务攻击的初始交换的特征，这些攻击可能会迫使远程端进行大量虚假定位器查找。
The common aspect of these approaches is that they all involve changes to the end-to-end interaction, as both ends of the communication need to be aware of this separation. The implication is that this form of support for multi-homing is relatively sweeping in its scope, as the necessary changes to support multi-homing extend beyond changes to the hosts and/or routers within the multi-homed site and encompass changes to the IPv6 protocol itself. It would be prudent when considering these changes to evaluate associated mechanisms that allow the communicating endpoints to discover each other's capabilities and only enable this form of split identity/locator functionality when it is established that both ends can support it.
这些方法的共同点是，它们都涉及到端到端交互的更改，因为通信的两端都需要意识到这种分离。这意味着，这种形式的多宿主支持在其范围内相对广泛，因为支持多宿主的必要更改超出了对多宿主站点内主机和/或路由器的更改，并包括对IPv6协议本身的更改。在考虑这些更改时，谨慎的做法是评估相关机制，这些机制允许通信端点发现彼此的能力，并且只有在确定两端都可以支持时才启用这种形式的分割身份/定位器功能。
It is a corollary of this form of negotiated capability that it is not strictly necessary that only one form of functionality can be negotiated in this way. If the adoption of a particular endpoint identity/locator mapping scheme is the outcome of a negotiation between the endpoints, then it would be possible to negotiate to use one of a number of possible approaches. There is some interaction between the approach used and the form of endpoint identity, and some care needs to be taken that any form of acceptable outcome of the endpoint identity capability negotiation is one that allows the upper-level application to continue to operate.
这种形式的协商能力的一个必然结果是，严格来说，没有必要仅以这种方式协商一种形式的功能。如果采用特定端点标识/定位器映射方案是端点之间协商的结果，则可以协商使用多种可能方法中的一种。所使用的方法和端点标识的形式之间存在一些交互作用，需要注意端点标识能力协商的任何形式的可接受结果都是允许上层应用程序继续运行的结果。
When considering the properties of long-lived identities, it is reasonable to assume that the identity assignation is not necessarily one that is permanent and unchangeable. In the case of structured identity spaces, the identity value reflects a distribution hierarchy. There are a number of circumstances where a change of identity value is appropriate. For example, if an endpoint device is moved across administrative realms of this distribution hierarchy it is likely that the endpoint's identity value will be reassigned to reflect the new realm. It is also reasonable to assume that an endpoint may have more than one identity at any point in time. RFC 3014 [RFC3041] provides a rationale for such a use of multiple identities.
在考虑长寿命身份的性质时，可以合理地假设身份分配不一定是永久和不可更改的。对于结构化标识空间，标识值反映了分布层次。在许多情况下，标识值的更改是适当的。例如，如果端点设备跨此分发层次结构的管理域移动，则很可能会重新分配端点的标识值以反映新域。假设一个端点在任何时间点上可能有多个标识也是合理的。RFC 3014[RFC3041]提供了使用多个身份的基本原理。
If an endpoint's identity can change over time and if an endpoint can be identified by more than one identity at any single point in time, then some further characteristics of endpoint identifiers should be
如果一个端点的标识可以随时间而改变，并且如果一个端点可以在任何单个时间点由多个标识标识，那么应该考虑端点标识符的一些进一步特征
defined. These relate to the constancy of an endpoint identity within an application, and the question of whether a transport session relies on a single endpoint identity value, and, if so, whether an endpoint identity can be changed within a transport session, and under what conditions the old identity can continue to be used following any such change. If the endpoint identity is a long-lived reference to a remote endpoint, and if multiple identities can exist for a single unique endpoint, then the question arises as to whether applications can compare identities for equivalence, and whether it is necessary for applications to recognise the condition where different identities refer to the same endpoint. These identities may be used within applications on a single host, or they may be identifies within applications on different hosts.
定义这些问题涉及应用程序中端点标识的恒定性，以及传输会话是否依赖于单个端点标识值的问题，如果是，是否可以在传输会话中更改端点标识，以及在任何此类更改后在何种条件下可以继续使用旧标识。如果端点标识是对远程端点的长期引用，并且如果单个唯一端点可以存在多个标识，则会出现应用程序是否可以比较标识以获得等效性的问题，以及应用程序是否有必要识别不同身份指向同一端点的情况。这些标识可以在单个主机上的应用程序中使用，也可以在不同主机上的应用程序中标识。
The following sections provide a framework for the characterisation of multi-homing approaches through a decomposition of the functions associated with session establishment, maintenance, and completion in the context of a multi-homed environment.
以下各节通过分解多宿主环境中与会话建立、维护和完成相关的功能，为多宿主方法的特征描述提供了一个框架。
What form of token is passed to the transport layer from the upper-level protocol element as an identification of the local protocol stack?
什么形式的令牌作为本地协议栈的标识从上层协议元素传递到传输层？
What form of token is passed to the transport layer from the upper-level protocol element as an identification of the remote session target?
什么形式的令牌作为远程会话目标的标识从上层协议元素传递到传输层？
What form of token is used by the upper-level protocol element as a self-identification mechanism for use within the application payload?
上层协议元素使用何种形式的令牌作为应用程序有效负载内使用的自识别机制？
Does the identity protocol element need to create a mapping from the upper-level protocol's local and remote identity tokens into an identity token that identifies the session? If so, then is this translation performed before or after the initial session packet exchange handshake?
identity protocol元素是否需要创建从上层协议的本地和远程标识令牌到标识会话的标识令牌的映射？如果是，那么这个转换是在初始会话数据包交换握手之前还是之后执行的？
How does the session initiator establish that the remote end of the session can support the multi-homing capabilities in its protocol stack? If the remote end cannot, does the multi-homing capable protocol element report a session establishment failure to the upper-level protocol or silently fall back to a non-multi-homed protocol operation?
会话发起方如何确定会话的远程端可以支持其协议栈中的多主功能？如果远程端不能，支持多主的协议元素是否向上层协议报告会话建立失败，或者自动退回到非多主协议操作？
How do the endpoints discover the locator set available for each other endpoint (locator discovery)?
端点如何发现可用于其他端点的定位器集（定位器发现）？
What mechanisms are used to perform locator selection at each end, for the local selection of source and destination locators?
对于源定位器和目标定位器的本地选择，使用哪些机制在每一端执行定位器选择？
What form of mechanism is used to ensure that the selected site exit path matches the selected packet source locator?
使用何种形式的机制来确保所选站点出口路径与所选数据包源定位器匹配？
What are common denominator goals of re-homing triggers? What are the objectives that triggers conservatively should meet across all types of sessions?
重新归位触发器的共同目标是什么？在所有类型的课程中，保守触发应该达到什么目标？
Are there transport session-specific triggers? If so, then what state changes within the network path should be triggers for all transport sessions, and what state changes are triggers only for selected transport sessions?
是否存在特定于传输会话的触发器？如果是这样，那么网络路径中的哪些状态更改应为所有传输会话的触发器，哪些状态更改仅为选定的传输会话的触发器？
What triggers are used to identify that a switch of locators is desirable?
使用什么触发器来确定定位器的切换是可取的？
Are the triggers based on the end-to-end transport session and/or on notification of state changes within the network path from the network?
触发器是否基于端到端传输会话和/或来自网络的网络路径内的状态更改通知？
What triggers can be used to indicate the direction of the failed path in order to trigger the appropriate locator repair function?
为了触发适当的定位器修复功能，可以使用哪些触发器指示故障路径的方向？
What parameters are used to determine the selection of a locator to use to reference the local endpoint?
哪些参数用于确定用于引用本地端点的定位器的选择？
If the remote endpoint is multi-homed, what parameters are used to determine the selection of a locator to use to reference the remote endpoint?
如果远程端点是多宿主的，那么使用哪些参数来确定要用于引用远程端点的定位器的选择？
Must a change of an egress site-exit router be accompanied by a change in source and/or destination locators?
出口站点出口路由器的变更必须伴随着源和/或目的地定位器的变更吗？
How can new locators be added to the locator pool of an existing session?
如何将新定位器添加到现有会话的定位器池中？
What are the preconditions that are necessary for a locator change?
定位器更改所需的先决条件是什么？
How can the locator change be confirmed by both ends?
双方如何确认定位器变更？
What interactions are necessary for synchronisation of locator change and transport session behaviour?
同步定位器更改和传输会话行为需要哪些交互？
How is identity/locator binding state removal synchronised with session closure?
身份/定位器绑定状态删除如何与会话关闭同步？
What binding information is cached for possible future use?
缓存哪些绑定信息以备将来使用？
There are a significant number of security considerations that result from the action of distinguishing within the protocol suite endpoint identity and locator identity.
在协议套件中区分端点标识和定位器标识的操作会导致大量安全注意事项。
It is not proposed to enumerate these considerations in detail within this document, but to reference a distinct document that describes the security considerations of this domain [threats].
不建议在本文件中详细列举这些注意事项，而是参考一份描述该领域安全注意事项的独特文件[威胁]。
The author acknowledges the assistance from the following reviewers: Brian Carpenter, Kurtis Lundqvist, Erik Nordmark, Iljitsch van Beijnum, Marcelo Bagnulo, John Loughney, Thierry Ernst, Joe Touch, Michael Patton, Ted Hardie, and Allison Mankin.
作者感谢以下审稿人的帮助：布赖恩·卡彭特、库蒂斯·伦德奎斯特、埃里克·诺德马克、伊尔吉奇·凡·贝伊纳姆、马塞洛·巴格鲁、约翰·拉夫尼、蒂埃里·恩斯特、乔·图奇、迈克尔·巴顿、泰德·哈迪和艾莉森·曼金。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582]Abley，J.，Black，B.和V.Gill，“IPv6站点多主架构的目标”，RFC 3582，2003年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[iab-link] Aboba, B., Ed., "Architectural Implications of Link Layer Indications", Work in Progress, January 2005.
[iab link]Aboba，B.，Ed.，“链路层指示的建筑影响”，正在进行的工作，2005年1月。
[e2e] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments in System Design", ACM TOCS Vol 2, Number 4, pp 277-288, November 1984, <http://web.mit.edu/Saltzer/www/ publications/endtoend/endtoend.txt>.
[e2e]Saltzer，J.，Reed，D.和D.Clark，“系统设计中的端到端参数”，ACM TOCS第2卷，第4期，第277-288页，1984年11月<http://web.mit.edu/Saltzer/www/ 出版物/endtoend/endtoend.txt>。
[rosec] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", Work in Progress, October 2004.
[rosec]Nikander，P.，Arkko，J.，Aura，T.，黑山，G.，和E.Nordmark，“移动IP版本6路由优化安全设计背景”，正在进行的工作，2004年10月。
[thinks] Lear, E., "Things MULTI6 Developers should think about", Work in Progress, January 2005.
[thinks]Lear，E.，“MULTI6开发人员应该考虑的事情”，进展中的工作，2005年1月。
[threats] Nordmark, E. and T. Li, "Threats relating to IPv6 multi-homing solutions", Work in Progress, January 2005.
[威胁]Nordmark，E.和T.Li，“与IPv6多宿主解决方案相关的威胁”，正在进行的工作，2005年1月。
Author's Address
作者地址
Geoff Huston APNIC
杰夫·休斯顿呼吸暂停
EMail: gih@apnic.net
EMail: gih@apnic.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。