Internet Engineering Task Force (IETF) T. Henderson, Ed.
Request for Comments: 8047 University of Washington
Category: Standards Track C. Vogt
ISSN: 2070-1721 Independent
J. Arkko
Ericsson
February 2017
Internet Engineering Task Force (IETF) T. Henderson, Ed.
Request for Comments: 8047 University of Washington
Category: Standards Track C. Vogt
ISSN: 2070-1721 Independent
J. Arkko
Ericsson
February 2017
Host Multihoming with the Host Identity Protocol
使用主机标识协议的主机多宿主
Abstract
摘要
This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility.
本文档通过利用为主机移动性定义的协议组件，定义了主机标识协议（HIP）的主机多归属扩展。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8047.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8047.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Multiple Addresses . . . . . . . . . . . . . . . . . 6
4.2.2. Multiple Security Associations . . . . . . . . . . . 6
4.2.3. Host Multihoming for Fault Tolerance . . . . . . . . 7
4.2.4. Host Multihoming for Load Balancing . . . . . . . . . 9
4.2.5. Site Multihoming . . . . . . . . . . . . . . . . . . 10
4.2.6. Dual-Host Multihoming . . . . . . . . . . . . . . . . 10
4.2.7. Combined Mobility and Multihoming . . . . . . . . . . 11
4.2.8. Initiating the Protocol in R1, I2, or R2 . . . . . . 11
4.2.9. Using LOCATOR_SETs across Addressing Realms . . . . . 13
4.3. Interaction with Security Associations . . . . . . . . . 13
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 14
5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 16
5.3. Verifying Address Reachability . . . . . . . . . . . . . 18
5.4. Changing the Preferred Locator . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Multiple Addresses . . . . . . . . . . . . . . . . . 6
4.2.2. Multiple Security Associations . . . . . . . . . . . 6
4.2.3. Host Multihoming for Fault Tolerance . . . . . . . . 7
4.2.4. Host Multihoming for Load Balancing . . . . . . . . . 9
4.2.5. Site Multihoming . . . . . . . . . . . . . . . . . . 10
4.2.6. Dual-Host Multihoming . . . . . . . . . . . . . . . . 10
4.2.7. Combined Mobility and Multihoming . . . . . . . . . . 11
4.2.8. Initiating the Protocol in R1, I2, or R2 . . . . . . 11
4.2.9. Using LOCATOR_SETs across Addressing Realms . . . . . 13
4.3. Interaction with Security Associations . . . . . . . . . 13
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sending LOCATOR_SETs . . . . . . . . . . . . . . . . . . 14
5.2. Handling Received LOCATOR_SETs . . . . . . . . . . . . . 16
5.3. Verifying Address Reachability . . . . . . . . . . . . . 18
5.4. Changing the Preferred Locator . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
The Host Identity Protocol (HIP) [RFC7401] supports an architecture that decouples the transport layer (TCP, UDP, etc.) from the internetworking layer (IPv4 and IPv6) by using public/private key pairs, instead of IP addresses, as host identities. When a host uses HIP, the overlying protocol sublayers (e.g., transport-layer sockets and Encapsulating Security Payload (ESP) Security Associations (SAs)) are instead bound to representations of these host identities, and the IP addresses are only used for packet forwarding. However, each host must also know at least one IP address at which its peers are reachable. Initially, these IP addresses are the ones used during the HIP base exchange.
主机标识协议（HIP）[RFC7401]支持通过使用公钥/私钥对（而不是IP地址）作为主机标识，将传输层（TCP、UDP等）与互联网层（IPv4和IPv6）解耦的体系结构。当主机使用HIP时，覆盖的协议子层（例如，传输层套接字和封装安全有效负载（ESP）安全关联（SA））被绑定到这些主机标识的表示，并且IP地址仅用于数据包转发。但是，每个主机还必须知道至少一个可以访问其对等机的IP地址。最初，这些IP地址是HIP-base交换期间使用的IP地址。
One consequence of such a decoupling is that new solutions to network-layer mobility and host multihoming are possible. Basic host mobility is defined in [RFC8046] and covers the case in which a host has a single address and changes its network point of attachment while desiring to preserve the HIP-enabled security association. Host multihoming is somewhat of a dual case to host mobility, in that, a host may simultaneously have more than one network point of attachment. There are potentially many variations of host multihoming possible. [RFC8046] specifies the format of the HIP parameter (LOCATOR_SET parameter) used to convey IP addressing information between peers, the procedures for sending and processing this parameter to enable basic host mobility, and procedures for an address verification mechanism. The scope of this document encompasses messaging and elements of procedure for some basic host multihoming scenarios of interest.
这种解耦的一个结果是，网络层移动性和主机多址的新解决方案成为可能。[RFC8046]中定义了基本主机移动性，并涵盖了主机具有单个地址并更改其网络连接点，同时希望保留支持HIP的安全关联的情况。主机多归属在某种程度上是一种双主机移动性，即主机可能同时具有多个网络连接点。可能存在多种不同的主机多宿主。[RFC8046]指定用于在对等方之间传输IP地址信息的HIP参数（LOCATOR_SET参数）的格式、发送和处理该参数以实现基本主机移动性的过程以及地址验证机制的过程。本文档的范围包括一些感兴趣的基本主机多宿主场景的消息传递和过程元素。
Another variation of multihoming that has been heavily studied is site multihoming. Solutions for host multihoming in multihomed IPv6 networks have been specified by the IETF shim6 working group. The Shim6 protocol [RFC5533] bears many architectural similarities to HIP, but there are differences in the security model and in the protocol.
另一个被大量研究的多归宿变体是站点多归宿。IETF shim6工作组已经指定了多宿主IPv6网络中的主机多宿主解决方案。Shim6协议[RFC5533]与HIP有许多架构上的相似之处，但在安全模型和协议上存在差异。
While HIP can potentially be used with transports other than the ESP transport format [RFC7402], this document largely assumes the use of ESP and leaves other transport formats for further study.
虽然HIP可能用于ESP传输格式[RFC7402]以外的传输，但本文件主要假设使用ESP，并将其他传输格式留作进一步研究。
Finally, making underlying IP multihoming transparent to the transport layer has implications on the proper response of transport congestion control, path MTU selection, and Quality of Service (QoS). Transport-layer mobility triggers, and the proper transport response to a HIP multihoming address change, are outside the scope of this document.
最后，使底层IP多归属对传输层透明对传输拥塞控制、路径MTU选择和服务质量（QoS）的正确响应具有影响。传输层移动性触发器以及对HIP多宿地址更改的正确传输响应不在本文档范围内。
This specification relies on implementing Sections 4 ("LOCATOR_SET Parameter Format") and 5 ("Processing Rules") of [RFC8046] as a starting point for this implementation.
本规范依赖于[RFC8046]第4节（“定位器设置参数格式”）和第5节（“处理规则”）的实施作为本实施的起点。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The following terms used in this document are defined in [RFC8046]: LOCATOR_SET, Locator, locator, Address, preferred locator, and Credit-Based Authorization.
本文件中使用的下列术语在[RFC8046]中有定义：定位器集、定位器、定位器、地址、首选定位器和基于信用的授权。
The protocol model for HIP support of host multihoming extends the model for host mobility described in Section 3 of [RFC8046]. This section only highlights the differences.
主机多宿的HIP支持协议模型扩展了[RFC8046]第3节中描述的主机移动性模型。本节仅强调差异。
In host multihoming, a host has multiple locators simultaneously rather than sequentially, as in the case of mobility. By using the LOCATOR_SET parameter defined in [RFC8046], a host can inform its peers of additional (multiple) locators at which it can be reached. When multiple locators are available and announced to the peer, a host can designate a particular locator as a "preferred" locator, meaning that the host prefers that its peer send packets to the designated address before trying an alternative address. Although this document defines a basic mechanism for multihoming, it does not define all possible policies and procedures, such as which locators to choose when more than one is available, the operation of simultaneous mobility and multihoming, source address selection policies (beyond those specified in [RFC6724]), and the implications of multihoming on transport protocols.
在主机多宿系统中，主机同时具有多个定位器，而不是像移动性那样按顺序具有多个定位器。通过使用[RFC8046]中定义的LOCATOR_SET参数，主机可以通知其对等方可以到达的其他（多个）定位器。当多个定位器可用并向对等方宣布时，主机可以将特定定位器指定为“首选”定位器，这意味着主机更希望其对等方在尝试替代地址之前将数据包发送到指定的地址。尽管本文件定义了多主定位的基本机制，但并未定义所有可能的策略和程序，例如当多个定位器可用时选择哪个定位器，同时移动和多主定位的操作，源地址选择策略（超出[RFC6724]中规定的策略），以及多宿对传输协议的影响。
In this section, we briefly introduce a number of usage scenarios for HIP multihoming. These scenarios assume that HIP is being used with the ESP transport [RFC7402], although other scenarios may be defined in the future. To understand these usage scenarios, the reader should be at least minimally familiar with the HIP protocol specification [RFC7401], the use of the ESP transport format [RFC7402], and the HIP mobility specification [RFC8046]. However, for the (relatively) uninitiated reader, it is most important to keep in mind that in HIP, the actual payload traffic is protected with ESP, and that the ESP Security Parameter Index (SPI) acts as an index to the right host-to-host context.
在本节中，我们将简要介绍HIP multihoming的一些使用场景。这些场景假设HIP正在与ESP传输[RFC7402]一起使用，尽管将来可能会定义其他场景。为了理解这些使用场景，读者至少应至少熟悉HIP协议规范[RFC7401]、ESP传输格式[RFC7402]的使用和HIP移动规范[RFC8046]。但是，对于（相对）不熟悉的读取器，最重要的是要记住，在HIP中，实际有效负载流量由ESP保护，ESP安全参数索引（SPI）充当正确主机到主机上下文的索引。
The multihoming scenarios can be explained in contrast to the non-multihoming case described in the base protocol specification [RFC7401]. We review the pertinent details here. In the base specification, when used with the ESP transport format, the HIP base exchange will set up a single SA in each direction. The IP addresses associated with the SAs are the same as those used to convey the HIP packets. For data traffic, a security policy database (SPD) and security association database (SAD) will likely exist, following the IPsec architecture. One distinction between HIP and IPsec, however, is that the host IDs, and not the IP addresses, are conceptually used as selectors in the SPD. In the outbound direction, as a result of SPD processing, when an outbound SA is selected, the correct IP destination address for the peer must also be assigned. Therefore, outbound SAs are conceptually associated with the peer IP address that must be used as the destination IP address below the HIP layer. In the inbound direction, the IP addresses may be used as selectors in the SAD to look up the SA, but they are not strictly required; the ESP SPI may be used alone. To summarize, in the non-multihoming case, there is only one source IP address, one destination IP address, one inbound SA, and one outbound SA.
与基本协议规范[RFC7401]中描述的非多主情况相比，可以解释多主情况。我们在此回顾相关细节。在基本规范中，当与ESP传输格式一起使用时，HIP基本交换将在每个方向上设置一个SA。与SAs关联的IP地址与用于传输HIP数据包的IP地址相同。对于数据流量，按照IPsec体系结构，可能存在安全策略数据库（SPD）和安全关联数据库（SAD）。然而，HIP和IPsec之间的一个区别是，从概念上讲，主机ID而不是IP地址被用作SPD中的选择器。在出站方向，作为SPD处理的结果，当选择出站SA时，还必须为对等方分配正确的IP目标地址。因此，出站SA在概念上与对等IP地址相关联，对等IP地址必须用作HIP层下的目标IP地址。在入站方向上，IP地址可以用作SAD中的选择器来查找SA，但它们不是严格要求的；ESP SPI可单独使用。总之，在非多宿情况下，只有一个源IP地址、一个目标IP地址、一个入站SA和一个出站SA。
The HIP readdressing protocol [RFC8046] is an asymmetric protocol in which a mobile or multihomed host informs a peer host about changes of IP addresses on affected SPIs. IP address and ESP SPI information is carried in Locator fields in a HIP parameter called a LOCATOR_SET. The HIP mobility specification [RFC8046] describes how the LOCATOR_SET is carried in a HIP UPDATE packet.
HIP ReadDrapping协议[RFC8046]是一种非对称协议，其中移动或多址主机将受影响SPI上IP地址的变化通知对等主机。IP地址和ESP SPI信息在称为定位器集的HIP参数的定位器字段中携带。髋关节移动规范[RFC8046]描述了如何在髋关节更新包中携带定位器集合。
To summarize the mobility elements of procedure, as background for multihoming, the basic idea of host mobility is to communicate a local IP address change to the peer when active HIP-maintained SAs are in use. To do so, the IP address must be conveyed, any association between the IP address and an inbound SA (via the SPI index) may be conveyed, and protection against flooding attacks must be ensured. The association of an IP address with an SPI is performed by a Locator Type of "1", which is a concatenation of an ESP SPI with an IP address.
为了总结程序的移动性要素，作为多宿的背景，主机移动性的基本思想是在使用活动的HIP维护SA时，将本地IP地址更改传达给对等方。为此，必须传输IP地址，可以传输IP地址和入站SA（通过SPI索引）之间的任何关联，并且必须确保针对洪水攻击的保护。IP地址与SPI的关联由定位器类型“1”执行，该定位器类型是ESP SPI与IP地址的串联。
An address verification method is specified in [RFC8046]. It is expected that addresses learned in multihoming scenarios also are subject to the same verification rules. At times, the scenarios describe addresses as being in either an ACTIVE, VERIFIED, or DEPRECATED state. From the perspective of a host, newly learned addresses of the peer must be verified before put into active
[RFC8046]中规定了地址验证方法。在多主场景中学习到的地址也应遵守相同的验证规则。有时，场景将地址描述为处于活动、已验证或已弃用状态。从主机的角度来看，新学习的对等方地址必须在进入活动状态之前进行验证
service, and addresses removed by the peer are put into a deprecated state. Under limited conditions described in [RFC8046], an UNVERIFIED address may be used.
对等方删除的服务和地址将处于不推荐状态。在[RFC8046]中描述的有限条件下，可以使用未经验证的地址。
With this background, we next describe an additional protocol to facilitate scenarios in which one or both hosts have multiple IP addresses available. Increasingly, this is the common case with network-connected hosts on the Internet.
在这样的背景下，我们接下来将描述一个附加协议，以促进一个或两个主机具有多个可用IP地址的场景。互联网上的网络连接主机越来越常见。
Hosts may have multiple IP addresses within different address families (IPv4 and IPv6) and scopes available to support HIP messaging and HIP-enabled SAs. The multiple addresses may be on a single network interface or multiple network interfaces. It is outside of the scope of this document to specify how a host decides which of possibly multiple addresses may be used to support a HIP association. Some IP addresses may be held back from usage due to privacy, security, or cost considerations.
主机可能在不同的地址系列（IPv4和IPv6）中具有多个IP地址，并且作用域可用于支持HIP消息传递和支持HIP的SAs。多个地址可以位于单个网络接口或多个网络接口上。指定主机如何决定可能使用多个地址中的哪一个来支持HIP关联超出了本文档的范围。出于隐私、安全或成本考虑，某些IP地址可能被禁止使用。
When multiple IP addresses are shared with a peer, the procedures described in the HIP mobility specification [RFC8046] allow for a host to set a preferred locator ("P") bit, requesting that one of the multiple addresses be preferred for control- or data-plane traffic. It is also permitted to leave the preferred bit unset for all addresses, allowing the peer to make address selection decisions.
当多个IP地址与对等方共享时，HIP移动规范[RFC8046]中描述的过程允许主机设置首选定位器（“P”）位，请求多个地址中的一个优先用于控制或数据平面通信。还允许为所有地址保留未设置的首选位，从而允许对等方做出地址选择决策。
Hosts that use link-local addresses as source addresses in their HIP handshakes may not be reachable by a mobile peer. Such hosts SHOULD provide a globally routable address either in the initial handshake or via the LOCATOR_SET parameter.
在HIP握手中使用链路本地地址作为源地址的主机可能无法被移动对等方访问。此类主机应在初始握手或通过LOCATOR_SET参数提供全局可路由地址。
To support mobility, as described in the HIP mobility specification [RFC8046], the LOCATOR_SET may be sent in a HIP UPDATE packet. To support multihoming, the LOCATOR_SET may also be sent in R1, I2, or R2 packets defined in the HIP protocol specification [RFC7401]. The reason to consider sending LOCATOR_SET parameters in base exchange packets is to convey all usable addresses for fault-tolerance or load-balancing considerations.
为了支持移动性，如髋关节移动性规范[RFC8046]中所述，定位器集合可以在髋关节更新分组中发送。为了支持多归属，定位器_集也可以在HIP协议规范[RFC7401]中定义的R1、I2或R2包中发送。考虑在基交换分组中发送LoopAtter设置参数的原因是为了容错或负载平衡考虑，传送所有可用的地址。
When multiple addresses are available between peer hosts, a question that arises is whether to use one or multiple SAs. The intent of this specification is to support different use cases but to leave the policy decision to the hosts.
当对等主机之间有多个地址可用时，出现的问题是使用一个还是多个SA。本规范的目的是支持不同的用例，但将策略决策留给主机。
When one host has n addresses and the other host has m addresses, it is possible to set up as many as (n * m) SAs in each direction. In such a case, every combination of source and destination IP addresses would have a unique SA, and the possibility of the reordering of datagrams on each SA will be lessened (ESP SAs may have an anti-replay window [RFC4303] sensitive to reordering). However, the downside to creating a mesh of SAs is the signaling overhead required (for exchanging UPDATE messages conveying ESP_INFO parameters) and the state maintenance required in the SPD/SAD.
当一台主机有n个地址而另一台主机有m个地址时，可以在每个方向上设置多达（n*m）个SAs。在这种情况下，源和目标IP地址的每个组合将具有唯一的SA，并且每个SA上数据报重新排序的可能性将减小（ESP SA可能具有对重新排序敏感的反重播窗口[RFC4303]）。然而，创建SAs网格的缺点是所需的信令开销（用于交换传递ESP_信息参数的更新消息）和SPD/SAD中所需的状态维护。
For load balancing, when multiple paths are to be used in parallel, it may make sense to create different SAs for different paths. In this use case, while a full mesh of 2 * (n * m) SAs may not be required, it may be beneficial to create one SA pair per load-balanced path to avoid anti-replay window issues.
对于负载平衡，当要并行使用多个路径时，为不同的路径创建不同的SA可能是有意义的。在此用例中，虽然可能不需要2*（n*m）个SA的完整网格，但为每个负载平衡路径创建一个SA对可能是有益的，以避免反重播窗口问题。
For fault tolerance, it is more likely that a single SA and multiple IP addresses associated with that SA can be used, and the alternative addresses can be used only upon failure detection of the addresses in use. Techniques for path failure detection are outside the scope of this specification. An implementation may use ICMP interactions, reachability checks, or other means to detect the failure of a locator.
对于容错，更有可能使用单个SA和与该SA相关联的多个IP地址，并且只有在检测到使用中的地址失败时才能使用替代地址。路径故障检测技术不在本规范的范围内。实现可以使用ICMP交互、可达性检查或其他方法来检测定位器的故障。
In summary, whether and how a host decides to leverage additional addresses in a load-balancing or fault-tolerant manner is outside the scope of the specification (although the academic literature on multipath TCP schedulers may provide guidance on how to design such a policy). However, in general, this document recommends that for fault tolerance, it is likely sufficient to use a single SA pair for all addresses, and for load balancing, to support a different SA pair for all active paths being balanced across.
总之，主机是否以及如何决定以负载平衡或容错方式利用附加地址不在本规范的范围内（尽管有关多路径TCP调度器的学术文献可能会提供如何设计此类策略的指导）。但是，一般来说，本文档建议，对于容错，对于所有地址使用单个SA对可能就足够了，对于负载平衡，对于所有正在平衡的活动路径，支持不同的SA对就足够了。
A (mobile or stationary) host may have more than one interface or global address. The host may choose to notify the peer host of the additional interface or address by using the LOCATOR_SET parameter. The LOCATOR_SET parameter may be included in an I2, R1, or R2 packet, or it may be conveyed, after the base exchange completes in an UPDATE packet.
（移动或固定）主机可能有多个接口或全局地址。主机可以选择使用LOCATOR_SET参数通知对等主机附加接口或地址。定位器集合参数可以包括在I2、R1或R2分组中，或者可以在更新分组中的基本交换完成之后传送。
When more than one locator is provided to the peer host, the host MAY indicate which locator is preferred (the locator on which the host prefers to receive traffic). By default, the address that a host uses in the base exchange is its preferred locator (for the address
当向对等主机提供多个定位器时，主机可指示优选哪个定位器（主机优选在其上接收流量的定位器）。默认情况下，主机在基本exchange中使用的地址是其首选定位器（用于地址）
family and address scope in use during the base exchange) until indicated otherwise. It may be the case that the host does not express any preferred locators.
家庭和地址范围（在基本交换期间使用），除非另有说明。可能是主机不表示任何首选定位器的情况。
In the multihoming case, the sender may also have multiple valid locators from which to source traffic. In practice, a HIP association in a multihoming configuration may have both a preferred peer locator and a preferred local locator. The host should try to use the peer's preferred locator unless policy or other circumstances prevent such usage. A preferred local locator may be overridden if source address selection rules on the destination address (peer's preferred locator) suggest the use of a different source address.
在多归属的情况下，发送方也可能有多个有效的定位器，从这些定位器发送到源流量。在实践中，多归宿配置中的髋部关联可能同时具有优选对等定位器和优选局部定位器。主机应尝试使用对等方的首选定位器，除非策略或其他情况阻止此类使用。如果目标地址（对等方的首选定位器）上的源地址选择规则建议使用不同的源地址，则可以覆盖首选本地定位器。
Although the protocol may allow for configurations in which there is an asymmetric number of SAs between the hosts (e.g., one host has two interfaces and two inbound SAs, while the peer has one interface and one inbound SA), it is suggested that inbound and outbound SAs be created pairwise between hosts. When an ESP_INFO arrives to rekey a particular outbound SA, the corresponding inbound SA should also be rekeyed at that time. Section 4.3 discusses the interaction between addresses and security associations in more detail.
尽管协议允许主机之间SA数量不对称的配置（例如，一台主机有两个接口和两个入站SA，而对等机有一个接口和一个入站SA），但建议在主机之间成对创建入站和出站SA。当ESP_信息到达重新输入特定出站SA时，相应的入站SA也应在该时间重新输入。第4.3节更详细地讨论了地址和安全关联之间的交互。
Consider the case of two hosts, one single-homed and one multihomed. The multihomed host may decide to inform the single-homed host about its other address(es). It may choose to do so as follows.
考虑两个主机的情况，一个单宿主和一个多宿主。多宿主机可决定将其其他地址通知单宿主机。它可以选择这样做如下。
If the multihomed host wishes to convey the additional address(es) for fault tolerance, it should include all of its addresses in Locator fields, indicating the Traffic Type, Locator Type, and whether the locator is a preferred locator. If it wishes to bind any particular address to an existing SPI, it may do so by using a Locator Type of "1" as specified in the HIP mobility specification [RFC8046]. It does not need to rekey the existing SA or request additional SAs at this time.
如果多宿主机希望传送用于容错的附加地址，则应在定位器字段中包括其所有地址，指示通信量类型、定位器类型以及定位器是否为首选定位器。如果它希望将任何特定地址绑定到现有SPI，它可以使用髋部移动规范[RFC8046]中规定的定位器类型“1”来绑定。此时无需重新设置现有SA的密钥或请求其他SA。
Figure 1 illustrates this scenario. Note that the conventions for message parameter notations in figures (use of parentheses and brackets) is defined in Section 2.2 of [RFC7401].
图1说明了这个场景。请注意，[RFC7401]第2.2节定义了图中消息参数符号的约定（使用括号和方括号）。
Multihomed Host Peer Host
多宿主主机对等主机
UPDATE(LOCATOR_SET, SEQ)
----------------------------------->
UPDATE(ACK)
<-----------------------------------
UPDATE(LOCATOR_SET, SEQ)
----------------------------------->
UPDATE(ACK)
<-----------------------------------
Figure 1: Basic Multihoming Scenario
图1：基本多主场景
In this scenario, the peer host associates the multiple addresses with the SA pair between it and the multihomed host. It may also undergo address verification procedures to transition the addresses to ACTIVE state. For inbound data traffic, it may choose to use the addresses along with the SPI as selectors. For outbound data traffic, it must choose among the available addresses of the multihomed host, considering the state of address verification [RFC8046] of each address, and also considering available information about whether an address is in a working state.
在这种情况下，对等主机将多个地址与其与多宿主主机之间的SA对相关联。它还可能经历地址验证过程，以将地址转换为活动状态。对于入站数据流量，它可以选择使用地址和SPI作为选择器。对于出站数据通信，它必须在多宿主机的可用地址中进行选择，考虑每个地址的地址验证状态[RFC8046]，还考虑有关地址是否处于工作状态的可用信息。
A multihomed host may decide to set up new SA pairs corresponding to new addresses, for the purpose of load balancing. The decision to load balance and the mechanism for splitting load across multiple SAs is out of scope of this document. The scenario can be supported by sending the LOCATOR_SET parameter with one or more ESP_INFO parameters to initiate new ESP SAs. To do this, the multihomed host sends a LOCATOR_SET with an ESP_INFO, indicating the request for a new SA by setting the OLD SPI value to zero and the NEW SPI value to the newly created incoming SPI. A Locator Type of "1" is used to associate the new address with the new SPI. The LOCATOR_SET parameter also contains a second Type "1" Locator, that of the original address and SPI. To simplify parameter processing and avoid explicit protocol extensions to remove locators, each LOCATOR_SET parameter MUST list all locators in use on a connection (a complete listing of inbound locators and SPIs for the host). The multihomed host waits for a corresponding ESP_INFO (new outbound SA) from the peer and an ACK of its own UPDATE. As in the mobility case, the peer host must perform an address verification before actively using the new address.
出于负载平衡的目的，多宿主主机可能会决定设置与新地址对应的新SA对。负载平衡决策和跨多个SA拆分负载的机制超出了本文档的范围。通过发送带有一个或多个ESP\u信息参数的LOCATOR\u SET参数来启动新的ESP SA，可以支持该方案。为此，多宿主机发送一个带有ESP_信息的定位器_集，通过将旧SPI值设置为零，将新SPI值设置为新创建的传入SPI来指示对新SA的请求。定位器类型“1”用于将新地址与新SPI关联。LOCATOR_SET参数还包含第二种类型的“1”定位器，即原始地址和SPI的定位器。为了简化参数处理并避免显式协议扩展以删除定位器，每个LOCATOR_SET参数必须列出连接上使用的所有定位器（主机入站定位器和SPI的完整列表）。多宿主主机等待来自对等主机的相应ESP_信息（新出站SA）及其自身更新的确认。与移动性情况一样，对等主机必须在主动使用新地址之前执行地址验证。
Figure 2 illustrates this scenario.
图2说明了这个场景。
Multihomed Host Peer Host
多宿主主机对等主机
UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN])
----------------------------------->
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
<-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
----------------------------------->
Figure 2: Host Multihoming for Load Balancing
图2：用于负载平衡的主机多宿主
In multihoming scenarios, it is important that hosts receiving UPDATEs associate them correctly with the destination address used in the packet carrying the UPDATE. When processing inbound LOCATOR_SETs
在多宿主场景中，重要的是接收更新的主机将其与承载更新的数据包中使用的目标地址正确关联。处理入站定位器集时
that establish new security associations on an interface with multiple addresses, a host uses the destination address of the UPDATE containing the LOCATOR_SET as the local address to which the LOCATOR_SET plus ESP_INFO is targeted. This is because hosts may send UPDATEs with the same (locator) IP address to different peer addresses -- this has the effect of creating multiple inbound SAs implicitly affiliated with different peer source addresses.
若要在具有多个地址的接口上建立新的安全关联，主机将包含定位器集的更新的目标地址用作定位器集加ESP信息的目标本地地址。这是因为主机可能会将具有相同（定位器）IP地址的更新发送到不同的对等地址——这会导致创建多个与不同对等源地址隐式关联的入站SA。
A host may have an interface that has multiple globally routable IP addresses. Such a situation may be a result of the site having multiple upper Internet Service Providers, or just because the site provides all hosts with both IPv4 and IPv6 addresses. The host should stay reachable at all or any subset of the currently available global routable addresses, independent of how they are provided.
主机可能具有具有多个全局可路由IP地址的接口。这种情况可能是由于站点具有多个上层Internet服务提供商，或者只是因为站点为所有主机提供IPv4和IPv6地址。主机应该在当前可用的全局可路由地址的所有或任何子集上保持可访问性，而与它们的提供方式无关。
This case is handled the same as if there were different IP addresses, described above in Sections 4.2.3 and 4.2.4. Note that a single interface may have addresses corresponding to site multihoming while the host itself may also have multiple network interfaces.
本案例的处理方式与上文第4.2.3节和第4.2.4节所述的不同IP地址的处理方式相同。请注意，单个接口可能具有与站点多宿主相对应的地址，而主机本身也可能具有多个网络接口。
Note that a host may be multihomed and mobile simultaneously, and that a multihomed host may want to protect the location of some of its interfaces while revealing the real IP address of some others.
请注意，主机可能同时是多主机和移动主机，多主机主机可能希望保护其某些接口的位置，同时显示其他一些接口的真实IP地址。
This document does not present additional site multihoming extensions to HIP; such extensions are for further study.
本文件不提供对HIP的额外站点多宿主扩展；这些扩展有待进一步研究。
Consider the case in which both hosts are multihomed and would like to notify the peer of an additional address after the base exchange completes. It may be the case that both hosts choose to simply announce the second address in a LOCATOR_SET parameter using an UPDATE message exchange. It may also be the case that one or both hosts decide to ask for new SA pairs to be created using the newly announced address. In the case that both hosts request this, the result will be a full mesh of SAs as depicted in Figure 3. In such a scenario, consider that host1, which used address addr1a in the base exchange to set up SPI1a and SPI2a, wants to add address addr1b. It would send an UPDATE with LOCATOR_SET (containing the address addr1b) to host2, using destination address addr2a, and a new ESP_INFO, and a new set of SPIs would be added between hosts 1 and 2 (call them SPI1b and SPI2b; not shown in the figure). Next, consider host2 deciding to add addr2b to the relationship. Host2 must select one of host1's addresses towards which to initiate an UPDATE. It may choose to initiate an UPDATE to addr1a, addr1b, or both. If it chooses to send
考虑两个主机都是多宿主的情况，并希望在基础交换完成后通知对等体的另一个地址。在这种情况下，两台主机可能都选择使用更新消息交换简单地宣布LOCATOR_SET参数中的第二个地址。也可能是一个或两个主机决定请求使用新公布的地址创建新的SA对。在两台主机都请求此操作的情况下，结果将是SA的完整网格，如图3所示。在这样的场景中，考虑在基础交换机中使用地址ADDR1A建立SPI1A和SPI2A的HoST1想要添加地址ADDR1B。它将使用目标地址addr2a和新的ESP_信息向主机2发送一个带有定位器_集（包含地址addr1b）的更新，并在主机1和主机2之间添加一组新的SPI（称为SPI1b和SPI2b；图中未显示）。接下来，考虑HoST2决定向该关系添加ADDR2B。Host2必须选择host1的其中一个地址来启动更新。它可以选择启动对addr1a、addr1b或两者的更新。如果它选择发送
to both, then a full mesh (four SA pairs) of SAs would exist between the two hosts. This is the most general case; the protocol is flexible enough to accommodate this choice.
对于这两个主机，两个主机之间将存在一个完整的SAs网格（四个SA对）。这是最普遍的情况；该协议具有足够的灵活性来适应这种选择。
-<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<-
-<- SPI1a -- -- SPI2a ->-
host1 < > addr1a <---> addr2a < > host2
->- SPI2a -- -- SPI1a -<-
addr1b <---> addr2a (second SA pair)
addr1a <---> addr2b (third SA pair)
addr1b <---> addr2b (fourth SA pair)
addr1b <---> addr2a (second SA pair)
addr1a <---> addr2b (third SA pair)
addr1b <---> addr2b (fourth SA pair)
Figure 3: Dual-Multihoming Case in which Each Host Uses LOCATOR_SET to Add a Second Address
图3：双多址情况，其中每个主机使用定位器_集添加第二个地址
Mobile hosts may be simultaneously mobile and multihomed, i.e., have multiple mobile interfaces. Furthermore, if the interfaces use different access technologies, it is fairly likely that one of the interfaces may appear stable (retain its current IP address) while some others may experience mobility (undergo IP address change).
移动主机可以同时是移动和多址的，即具有多个移动接口。此外，如果接口使用不同的访问技术，则其中一个接口很可能看起来稳定（保留其当前IP地址），而其他一些接口可能会经历移动性（经历IP地址更改）。
The use of LOCATOR_SET plus ESP_INFO should be flexible enough to handle most such scenarios, although more complicated scenarios have not been studied so far.
定位器集和ESP信息的使用应足够灵活，以处理大多数此类场景，尽管到目前为止还没有研究过更复杂的场景。
A Responder host MAY include a LOCATOR_SET parameter in the R1 packet that it sends to the Initiator. This parameter MUST be protected by the R1 signature. If the R1 packet contains LOCATOR_SET parameters with a new preferred locator, the Initiator SHOULD directly set the new preferred locator to status ACTIVE without performing address verification first, and it MUST send the I2 packet to the new preferred locator. The I1 destination address and the new preferred locator may be identical. All new non-preferred locators must still undergo address verification once the base exchange completes. It is also possible for the host to send the LOCATOR_SET without any preferred bits set, in which case the exchange will continue as normal and the newly learned addresses will be in an UNVERIFIED state at the initiator.
响应者主机可以在其发送给发起方的R1分组中包括定位器设置参数。此参数必须由R1签名保护。如果R1数据包包含带有新首选定位器的定位器设置参数，则发起方应直接将新首选定位器设置为活动状态，而无需首先执行地址验证，并且必须将I2数据包发送给新首选定位器。I1目的地地址和新的优选定位器可以相同。一旦基本交换完成，所有新的非首选定位器仍必须进行地址验证。主机也可以在没有任何首选位集的情况下发送定位器_集，在这种情况下，交换将继续正常进行，并且新读入的地址将在启动器处处于未验证状态。
Initiator Responder
发起者响应者
R1 with LOCATOR_SET
<-----------------------------------
record additional addresses
change Responder address
I2 sent to newly indicated preferred address
----------------------------------->
(process normally)
R2
<-----------------------------------
(process normally, later verification of non-preferred locators)
R1 with LOCATOR_SET
<-----------------------------------
record additional addresses
change Responder address
I2 sent to newly indicated preferred address
----------------------------------->
(process normally)
R2
<-----------------------------------
(process normally, later verification of non-preferred locators)
Figure 4: LOCATOR_SET Inclusion in R1
图4:R1中包含的定位器集
An Initiator MAY include one or more LOCATOR_SET parameters in the I2 packet, independent of whether or not there was a LOCATOR_SET parameter in the R1. These parameters MUST be protected by the I2 signature. Even if the I2 packet contains LOCATOR_SET parameters, the Responder MUST still send the R2 packet to the source address of the I2. The new preferred locator, if set, SHOULD be identical to the I2 source address. If the I2 packet contains LOCATOR_SET parameters, all new locators must undergo address verification as usual, and the ESP traffic that subsequently follows should use the preferred locator.
发起者可以在I2分组中包括一个或多个定位器集参数，这与R1中是否存在定位器集参数无关。这些参数必须受到I2签名的保护。即使I2数据包包含定位器设置参数，响应者仍必须将R2数据包发送到I2的源地址。新的首选定位器（如果设置）应与I2源地址相同。如果I2数据包包含LOCATOR_SET参数，则所有新定位器必须像往常一样进行地址验证，随后的ESP通信量应使用首选定位器。
Initiator Responder
发起者响应者
I2 with LOCATOR_SET
----------------------------------->
(process normally)
record additional addresses
R2 sent to source address of I2
<-----------------------------------
(process normally)
I2 with LOCATOR_SET
----------------------------------->
(process normally)
record additional addresses
R2 sent to source address of I2
<-----------------------------------
(process normally)
Figure 5: LOCATOR_SET Inclusion in I2
图5:I2中包含的定位器集
The I1 and I2 may be arriving from different source addresses if the LOCATOR_SET parameter is present in R1. In this case, implementations simultaneously using multiple pre-created R1s, indexed by Initiator IP addresses, may inadvertently fail the puzzle solution of I2 packets due to a perceived puzzle mismatch. See, for instance, the example in Appendix A of [RFC7401]. As a solution, the Responder's puzzle indexing mechanism must be flexible enough to accommodate the situation when R1 includes a LOCATOR_SET parameter.
如果定位器设置参数存在于R1中，则I1和I2可能来自不同的源地址。在这种情况下，同时使用多个预先创建的R1（由启动器IP地址索引）的实现可能会由于感知到的谜题不匹配而导致I2数据包的谜题解决方案意外失败。例如，参见[RFC7401]附录A中的示例。作为一种解决方案，响应者的谜题索引机制必须足够灵活，以适应R1包含定位器集参数的情况。
Finally, the R2 may be used to carry the LOCATOR_SET parameter. In this case, the LOCATOR_SET is covered by the HIP_MAC_2 and HIP_SIGNATURE. Including LOCATOR_SET in R2 as opposed to R1 may have some advantages when a host prefers not to divulge additional locators until after the I2 is successfully processed.
最后，R2可用于携带定位器设置参数。在这种情况下，定位器集被HIP_MAC_2和HIP_签名覆盖。当主机希望在成功处理I2之前不泄露其他定位器时，将定位器_设置在R2中而不是R1中可能具有一些优势。
When the LOCATOR_SET parameter is sent in an UPDATE packet, the receiver will respond with an UPDATE acknowledgment. When the LOCATOR_SET parameter is sent in an R1, I2, or R2 packet, the base exchange retransmission mechanism will confirm its successful delivery.
当LOCATOR_SET参数在更新包中发送时，接收器将以更新确认响应。当LOCATOR_SET参数在R1、I2或R2数据包中发送时，基本交换重传机制将确认其成功传递。
It is possible for HIP associations to use these mechanisms to migrate their HIP associations and security associations from addresses in the IPv4 addressing realm to IPv6, or vice versa. It may be possible for a state to arise in which both hosts are only using locators in different addressing realms, but in such a case, some type of mechanism for interworking between the different realms must be employed; such techniques are outside the scope of the present text.
HIP关联可以使用这些机制将其HIP关联和安全关联从IPv4寻址域中的地址迁移到IPv6，反之亦然。可能出现两个主机仅在不同寻址域中使用定位器的状态，但在这种情况下，必须采用某种类型的机制在不同域之间进行互通；这些技术不在本案文的范围之内。
A host may establish any number of security associations (or SPIs) with a peer. The main purpose of having multiple SPIs with a peer is to group the addresses into collections that are likely to experience fate sharing, or to perform load balancing.
主机可以与对等机建立任意数量的安全关联（或SPI）。将多个SPI与一个对等点连接的主要目的是将地址分组到可能经历命运共享或执行负载平衡的集合中。
A basic property of HIP SAs is that the inbound IP address is not used to look up the incoming SA. However, the use of different source and destination addresses typically leads to different paths, with different latencies in the network, and if packets were to arrive via an arbitrary destination IP address (or path) for a given SPI, the reordering due to different latencies may cause some packets to fall outside of the ESP anti-replay window. For this reason, HIP provides a mechanism to affiliate destination addresses with inbound SPIs, when there is a concern that anti-replay windows might be violated. In this sense, we can say that a given inbound SPI has an "affinity" for certain inbound IP addresses, and this affinity is communicated to the peer host. Each physical interface SHOULD have a separate SA, unless the ESP anti-replay window is extended or disabled.
HIP SA的一个基本属性是入站IP地址不用于查找入站SA。然而，使用不同的源地址和目标地址通常会导致不同的路径，在网络中具有不同的延迟，并且如果数据包通过给定SPI的任意目标IP地址（或路径）到达，则由于不同延迟而导致的重新排序可能会导致一些数据包落在ESP防重播窗口之外。因此，当担心可能违反反重播窗口时，HIP提供了将目标地址与入站SPI关联的机制。从这个意义上讲，我们可以说，给定的入站SPI对某些入站IP地址具有“亲缘关系”，并且该亲缘关系被传送到对等主机。除非扩展或禁用ESP防重播窗口，否则每个物理接口都应具有单独的SA。
Moreover, even when the destination addresses used for a particular SPI are held constant, the use of different source interfaces may also cause packets to fall outside of the ESP anti-replay window,
此外，即使当用于特定SPI的目的地地址保持不变时，使用不同的源接口也可能导致数据包落在ESP反重放窗口之外，
since the path traversed is often affected by the source address or interface used. A host has no way to influence the source interface on which a peer sends its packets on a given SPI. A host SHOULD consistently use the same source interface and address when sending to a particular destination IP address and SPI. For this reason, a host may find it useful to change its SPI or at least reset its ESP anti-replay window when the peer host readdresses.
因为遍历的路径通常受所使用的源地址或接口的影响。主机无法影响对等方在给定SPI上发送其数据包的源接口。当发送到特定的目标IP地址和SPI时，主机应始终使用相同的源接口和地址。因此，当对等主机重新加载时，主机可能会发现更改其SPI或至少重置其ESP防重播窗口很有用。
Basic processing rules for the LOCATOR_SET parameter are specified in [RFC8046]. This document focuses on multihoming-specific rules.
[RFC8046]中规定了LOCATOR_SET参数的基本处理规则。本文档重点介绍多宿主特定规则。
The decision of when to send a LOCATOR_SET, and which addresses to include, is a local policy issue. [RFC8046] recommends that a host "send a LOCATOR_SET whenever it recognizes a change of its IP addresses in use on an active HIP association and [when it] assumes that the change is going to last at least for a few seconds." It is possible to delay the exposure of additional locators to the peer, and to send data from previously unannounced locators, as might arise in certain mobility or multihoming situations.
何时发送定位器集以及包含哪些地址是本地策略问题。[RFC8046]建议主机“在识别到活动HIP association上使用的IP地址发生变化并且[当它]假设该变化将持续至少几秒钟时，发送定位器集。”可以延迟向对等方暴露其他定位器，以及从以前未经通知的定位器发送数据，这在某些移动或多址情况下可能会出现。
When a host decides to inform its peers about changes in its IP addresses, it has to decide how to group the various addresses with SPIs. If hosts are deployed in an operational environment in which HIP-aware NATs and firewalls (that may perform parameter inspection) exist, and different such devices may exist on different paths, hosts may take that knowledge into consideration about how addresses are grouped, and may send the same LOCATOR_SET in separate UPDATEs on the different paths. However, more detailed guidelines about how to operate in the presence of such HIP-aware NATs and firewalls are a topic for further study. Since each SPI is associated with a different security association, the grouping policy may also be based on ESP anti-replay protection considerations. In the typical case, simply basing the grouping on actual kernel-level physical and logical interfaces may be the best policy. The grouping policy is outside of the scope of this document.
当主机决定通知其对等方其IP地址的更改时，它必须决定如何使用SPI对各种地址进行分组。如果主机部署在存在HIP感知NAT和防火墙（可执行参数检查）的操作环境中，并且不同路径上可能存在不同的此类设备，则主机可能会考虑有关地址分组方式的知识，并且可以在不同路径上的单独更新中发送相同的定位器_集。然而，关于如何在这种HIP感知NAT和防火墙存在的情况下操作的更详细的指南是一个有待进一步研究的主题。由于每个SPI都与不同的安全关联相关联，因此分组策略也可能基于ESP防重播保护考虑。在典型情况下，仅根据实际内核级物理和逻辑接口进行分组可能是最佳策略。分组策略超出了本文档的范围。
Locators corresponding to tunnel interfaces (e.g., IPsec tunnel interfaces or Mobile IP home addresses) or other virtual interfaces MAY be announced in a LOCATOR_SET, but implementations SHOULD avoid announcing such locators as preferred locators if more direct paths may be obtained by instead preferring locators from non-tunneling interfaces if such locators provide a more direct path to the HIP peer.
与隧道接口（例如，IPsec隧道接口或移动IP主地址）或其他虚拟接口相对应的定位器可以在定位器集中公布，但是，如果可以通过从非隧道接口首选定位器来获得更直接的路径（如果此类定位器提供到HIP对等方的更直接路径），则实现应该避免将此类定位器宣布为首选定位器。
[RFC8046] specifies that hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs. Link-local addresses MAY be announced to peers that are known to be neighbors on the same link, such as when the IP destination address of a peer is also link local. The announcement of link-local addresses in this case is a policy decision; link-local addresses used as preferred locators will create reachability problems when the host moves to another link. In any case, link-local addresses MUST NOT be announced to a peer unless that peer is known to be on the same link.
[RFC8046]指定主机不得在定位器_集中宣布广播或多播地址。链路本地地址可以向已知为同一链路上的邻居的对等方宣布，例如当对等方的IP目的地地址也是链路本地时。在这种情况下，公布链路本地地址是一项政策决定；当主机移动到另一个链路时，用作首选定位器的链路本地地址将产生可达性问题。在任何情况下，链路本地地址都不得向对等方宣布，除非已知该对等方位于同一链路上。
Once the host has decided on the groups and assignment of addresses to the SPIs, it creates a LOCATOR_SET parameter that serves as a complete representation of the addresses and associated SPIs intended for active use. We now describe a few cases introduced in Section 4. We assume that the Traffic Type for each locator is set to "0" (other values for Traffic Type may be specified in documents that separate the HIP control plane from data-plane traffic). Other mobility and multihoming cases are possible but are left for further experimentation.
一旦主机决定了SPI的地址组和分配，它将创建一个LOCATOR_SET参数，作为地址和相关SPI的完整表示，以供活动使用。我们现在描述第4节中介绍的几个案例。我们假设每个定位器的交通类型设置为“0”（交通类型的其他值可以在分离HIP控制平面和数据平面交通的文档中指定）。其他机动性和多归宿情况也是可能的，但仍有待进一步试验。
1. Host multihoming (addition of an address). We only describe the simple case of adding an additional address to a (previously) single-homed, non-mobile host. The host MAY choose to simply announce this address to the peer, for fault tolerance. To do this, the multihomed host creates a LOCATOR_SET parameter including the existing address and SPI as a Type "1" Locator, and the new address as a Type "0" Locator. The host sends this in an UPDATE message with the SEQ parameter, which is acknowledged by the peer.
1. 主机多宿主（添加地址）。我们只描述一个简单的例子，即向（以前）一个单独的、非移动主机添加一个额外的地址。为了容错，主机可以选择简单地向对等方宣布该地址。为此，多宿主主机创建一个LOCATOR_SET参数，包括现有地址和SPI作为类型“1”定位器，以及新地址作为类型“0”定位器。主机在更新消息中使用SEQ参数发送此消息，并由对等方确认。
2. The host MAY set up a new SA pair between this new address and an address of the peer host. To do this, the multihomed host creates a new inbound SA and creates a new SPI. For the outgoing UPDATE message, it inserts an ESP_INFO parameter with an OLD SPI field of "0", a NEW SPI field corresponding to the new SPI, and a KEYMAT Index as selected by local policy. The host adds to the UPDATE message a LOCATOR_SET with two Type "1" Locators: the original address and SPI active on the association, and the new address and new SPI being added (with the SPI matching the NEW SPI contained in the ESP_INFO). The preferred bit SHOULD be set depending on the policy to tell the peer host which of the two locators is preferred. The UPDATE also contains a SEQ parameter and optionally a DIFFIE_HELLMAN parameter and follows rekeying procedures with respect to this new address. The UPDATE message SHOULD be sent to the peer's preferred address with a source address corresponding to the new locator.
2. 主机可以在这个新地址和对等主机的地址之间建立一个新的SA对。为此，多宿主主机创建一个新的入站SA并创建一个新的SPI。对于传出的更新消息，它插入一个ESP_INFO参数，其中旧SPI字段为“0”，新SPI字段对应于新SPI，以及本地策略选择的KEYMAT索引。主机向更新消息中添加一个定位器集，该定位器集具有两个类型“1”定位器：在关联上处于活动状态的原始地址和SPI，以及正在添加的新地址和新SPI（SPI与ESP_信息中包含的新SPI相匹配）。应根据策略设置首选位，以告知对等主机两个定位器中的哪一个是首选的。更新还包含一个SEQ参数和一个DIFFIE_HELLMAN参数（可选），并遵循与此新地址相关的密钥更新过程。更新消息应发送到对等方的首选地址，其源地址对应于新定位器。
The sending of multiple LOCATOR_SETs is unsupported. Note that the inclusion of LOCATOR_SET in an R1 packet requires the use of Type "0" Locators since no SAs are set up at that point.
不支持发送多个定位器集。请注意，在R1数据包中包含定位器_SET需要使用类型“0”定位器，因为在该点未设置SA。
A host SHOULD be prepared to receive a LOCATOR_SET parameter in the following HIP packets: R1, I2, R2, and UPDATE.
主机应准备好接收以下HIP数据包中的LOCATOR_SET参数：R1、I2、R2和UPDATE。
This document describes sending both ESP_INFO and LOCATOR_SET parameters in an UPDATE. The ESP_INFO parameter is included when there is a need to rekey or key a new SPI and can otherwise be included for the possible benefit of HIP-aware middleboxes. The LOCATOR_SET parameter contains a complete map of the locators that the host wishes to make or keep active for the HIP association.
本文档介绍在更新中发送ESP_信息和定位器_设置参数。当需要重新输入或输入一个新的SPI时，会包含ESP_INFO参数，此外，还可以包含该参数，以实现HIP感知的中间盒的可能优势。LOCATOR_SET参数包含宿主希望为髋部关联创建或保持活动状态的定位器的完整地图。
In general, the processing of a LOCATOR_SET depends upon the packet type in which it is included. Here, we describe only the case in which ESP_INFO is present and a single LOCATOR_SET and ESP_INFO are sent in an UPDATE message; other cases are for further study. The steps below cover each of the cases described in Section 5.1.
通常，定位器集合的处理取决于其所包括的分组类型。这里，我们仅描述存在ESP_信息并且在更新消息中发送单个定位器_集和ESP_信息的情况；其他案例有待进一步研究。以下步骤涵盖第5.1节所述的每种情况。
The processing of ESP_INFO and LOCATOR_SET parameters is intended to be modular and support future generalization to the inclusion of multiple ESP_INFO and/or multiple LOCATOR_SET parameters. A host SHOULD first process the ESP_INFO before the LOCATOR_SET, since the ESP_INFO may contain a new SPI value mapped to an existing SPI, while a Type "1" Locator will only contain a reference to the new SPI.
ESP_信息和定位器_集参数的处理旨在模块化，并支持将来的通用化，以包括多个ESP_信息和/或多个定位器_集参数。主机应在设置定位器之前首先处理ESP_信息，因为ESP_信息可能包含映射到现有SPI的新SPI值，而类型“1”定位器将仅包含对新SPI的引用。
When a host receives a validated HIP UPDATE with a LOCATOR_SET and ESP_INFO parameter, it processes the ESP_INFO as follows. The ESP_INFO parameter indicates whether an SA is being rekeyed, created, deprecated, or just identified for the benefit of middleboxes. The host examines the OLD SPI and NEW SPI values in the ESP_INFO parameter:
当主机接收到带有定位器集和ESP\U信息参数的已验证髋部更新时，它将按如下方式处理ESP\U信息。ESP_INFO参数表示SA是否正在被重新设置密钥、创建、弃用，或者只是为了中间包的利益而被识别。主机检查ESP_INFO参数中的旧SPI和新SPI值：
1. (no rekeying) If the OLD SPI is equal to the NEW SPI and both correspond to an existing SPI, the ESP_INFO is gratuitous (provided for middleboxes), and no rekeying is necessary.
1. （无密钥更新）如果旧的SPI等于新的SPI，并且两者都对应于现有的SPI，则ESP_信息是免费的（为中间盒提供），无需密钥更新。
2. (rekeying) If the OLD SPI indicates an existing SPI and the NEW SPI is a different non-zero value, the existing SA is being rekeyed and the host follows HIP ESP rekeying procedures by creating a new outbound SA with an SPI corresponding to the NEW SPI, with no addresses bound to this SPI. Note that locators in the LOCATOR_SET parameter will reference this new SPI instead of the old SPI.
2. （重设密钥）如果旧SPI指示现有SPI，而新SPI是不同的非零值，则现有SA将被重设密钥，主机将通过创建一个新的出站SA，该出站SA具有与新SPI对应的SPI，并且没有地址绑定到此SPI，从而遵循HIP ESP重设密钥的过程。请注意，LOCATOR_SET参数中的定位器将引用此新SPI，而不是旧SPI。
3. (new SA) If the OLD SPI value is zero and the NEW SPI is a new non-zero value, then a new SA is being requested by the peer. This case is also treated like a rekeying event; the receiving host must create a new SA and respond with an UPDATE ACK.
3. （新SA）如果旧SPI值为零，而新SPI为新的非零值，则对等方正在请求新SA。这种情况也被视为一个重新键入事件；接收主机必须创建一个新SA并用更新确认进行响应。
4. (deprecating the SA) If the OLD SPI indicates an existing SPI and the NEW SPI is zero, the SA is being deprecated and all locators uniquely bound to the SPI are put into the DEPRECATED state.
4. （弃用SA）如果旧SPI指示现有SPI，而新SPI为零，则SA将弃用，并且唯一绑定到SPI的所有定位器将处于弃用状态。
If none of the above cases apply, a protocol error has occurred and the processing of the UPDATE is stopped.
如果上述情况均不适用，则会发生协议错误并停止更新处理。
Next, the locators in the LOCATOR_SET parameter are processed. For each locator listed in the LOCATOR_SET parameter, check that the address therein is a legal unicast or anycast address. That is, the address MUST NOT be a broadcast or multicast address. Note that some implementations MAY accept addresses that indicate the local host, since it may be allowed that the host runs HIP with itself.
接下来，处理LOCATOR_SET参数中的定位器。对于locator_SET参数中列出的每个定位器，请检查其中的地址是否为合法的单播或选播地址。也就是说，地址不能是广播或多播地址。请注意，一些实现可能接受指示本地主机的地址，因为可能允许主机自身运行HIP。
For each Type "1" address listed in the LOCATOR_SET parameter, the host checks whether the address is already bound to the SPI indicated. If the address is already bound, its lifetime is updated. If the status of the address is DEPRECATED, the status is changed to UNVERIFIED. If the address is not already bound, the address is added, and its status is set to UNVERIFIED. If there exist remaining addresses corresponding to the SPI that were NOT listed in the LOCATOR_SET parameter, the host sets the status of such addresses to DEPRECATED.
对于LOCATOR_SET参数中列出的每种类型的“1”地址，主机将检查该地址是否已绑定到指定的SPI。如果地址已绑定，则更新其生存期。如果地址的状态不推荐使用，则状态将更改为未验证。如果该地址尚未绑定，则会添加该地址，并将其状态设置为未验证。如果存在与未在LOCATOR_SET参数中列出的SPI相对应的剩余地址，则主机会将这些地址的状态设置为不推荐。
For each Type "0" address listed in the LOCATOR_SET parameter, if the status of the address is DEPRECATED, or the address was not previously known, the status is changed to UNVERIFIED. The host MAY choose to associate this address with one or more SAs. The association with different SAs is a local policy decision, unless the peer has indicated that the address is preferred, in which case the address should be put into use on an SA that is prioritized in the security policy database.
对于LOCATOR_SET参数中列出的每种类型的“0”地址，如果该地址的状态已弃用，或者该地址以前未知，则状态将更改为未验证。主机可以选择将此地址与一个或多个SAs关联。与不同SA的关联是一个本地策略决策，除非对等方已指示首选该地址，在这种情况下，该地址应在安全策略数据库中优先排序的SA上使用。
As a result, at the end of processing, the addresses listed in the LOCATOR_SET parameter have a state of either UNVERIFIED or ACTIVE, and any old addresses on the old SA not listed in the LOCATOR_SET parameter have a state of DEPRECATED.
因此，在处理结束时，LOCATOR_集参数中列出的地址的状态为未验证或活动，而LOCATOR_集参数中未列出的旧SA上的任何旧地址的状态为不推荐。
Once the host has processed the locators, if the LOCATOR_SET parameter contains a new preferred locator, the host SHOULD initiate a change of the preferred locator. This requires that the host first verifies reachability of the associated address and only then changes the preferred locator; see Section 5.4.
一旦主机处理了定位器，如果LOCATOR_SET参数包含新的首选定位器，则主机应启动首选定位器的更改。这要求主机首先验证关联地址的可达性，然后才更改首选定位器；见第5.4节。
If a host receives a locator with an unsupported Locator Type, and when such a locator is also declared to be the preferred locator for the peer, the host SHOULD send a NOTIFY error with a Notify Message Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field containing the locator(s) that the receiver failed to process. Otherwise, a host MAY send a NOTIFY error if a (non-preferred) locator with an unsupported Locator Type is received in a LOCATOR_SET parameter.
如果主机接收到具有不支持的定位器类型的定位器，并且当该定位器也被声明为对等方的首选定位器时，主机应发送通知错误，通知消息类型为locator_Type_unsupported，通知数据字段包含接收方未能处理的定位器。否则，如果在locator_SET参数中接收到不支持定位器类型的（非首选）定位器，主机可能会发送NOTIFY错误。
Address verification is defined in [RFC8046].
[RFC8046]中定义了地址验证。
When address verification is in progress for a new preferred locator, the host SHOULD select a different locator listed as ACTIVE, if one such locator is available, to continue communications until address verification completes. Alternatively, the host MAY use the new preferred locator while in UNVERIFIED status to the extent Credit-Based Authorization permits. Credit-Based Authorization is explained in [RFC8046]. Once address verification succeeds, the status of the new preferred locator changes to ACTIVE.
当对新的首选定位器进行地址验证时，主机应选择列为活动的不同定位器（如果有一个此类定位器可用），以继续通信，直到地址验证完成。或者，在基于信用的授权许可的范围内，主机可以在处于未验证状态时使用新的优选定位器。[RFC8046]中解释了基于信用的授权。一旦地址验证成功，新首选定位器的状态将更改为活动。
A host MAY want to change the preferred outgoing locator for different reasons, e.g., because traffic information or ICMP error messages indicate that the currently used preferred address may have become unreachable. Another reason may be due to receiving a LOCATOR_SET parameter that has the preferred bit set.
主机可能出于不同的原因想要更改首选传出定位器，例如，因为流量信息或ICMP错误消息表明当前使用的首选地址可能无法访问。另一个原因可能是由于接收到具有首选位集的定位器集参数。
To change the preferred locator, the host initiates the following procedure:
要更改首选定位器，主机将启动以下过程：
1. If the new preferred locator has ACTIVE status, the preferred locator is changed and the procedure succeeds.
1. 如果新的首选定位器处于活动状态，则首选定位器将更改，并且过程将成功。
2. If the new preferred locator has UNVERIFIED status, the host starts to verify its reachability. The host SHOULD use a different locator listed as ACTIVE until address verification completes if one such locator is available. Alternatively, the host MAY use the new preferred locator, even though in UNVERIFIED status, to the extent Credit-Based Authorization permits. Once address verification succeeds, the status of the new preferred locator changes to ACTIVE, and its use is no longer governed by Credit-Based Authorization.
2. 如果新的首选定位器具有未验证状态，主机将开始验证其可达性。如果有一个定位器可用，主机应使用列为活动的其他定位器，直到地址验证完成。或者，主机可以在基于信用的授权许可的范围内使用新的首选定位器，即使处于未验证状态。一旦地址验证成功，新首选定位器的状态将更改为活动，并且其使用不再受基于信用的授权的控制。
3. If the peer host has not indicated a preference for any address, then the host picks one of the peer's ACTIVE addresses randomly or according to policy. This case may arise if, for example, ICMP error messages that deprecate the preferred locator arrive, but the peer has not yet indicated a new preferred locator.
3. 如果对等主机未表示对任何地址的偏好，则主机随机或根据策略选择对等主机的一个活动地址。例如，如果不推荐首选定位器的ICMP错误消息到达，但对等方尚未指示新的首选定位器，则可能出现这种情况。
4. If the new preferred locator has DEPRECATED status and there is at least one non-deprecated address, the host selects one of the non-deprecated addresses as a new preferred locator and continues. If the selected address is UNVERIFIED, the address verification procedure described above will apply.
4. 如果新的首选定位器处于不推荐状态，并且至少有一个未推荐的地址，则主机将选择其中一个未推荐的地址作为新的首选定位器并继续。如果所选地址未经验证，将采用上述地址验证程序。
This document extends the scope of host mobility solutions defined in [RFC8046] to also include host multihoming, and as a result, many of the same security considerations for mobility also pertain to multihoming. In particular, [RFC8046] describes how HIP host mobility is resistant to different types of impersonation attacks and denial-of-service (DoS) attacks.
本文档扩展了[RFC8046]中定义的主机移动性解决方案的范围，也包括主机多宿，因此，许多相同的移动性安全注意事项也适用于多宿。具体而言，[RFC8046]描述了HIP主机移动性如何抵抗不同类型的模拟攻击和拒绝服务（DoS）攻击。
The security considerations for this document are similar to those of [RFC8046] because the strong authentication capabilities for mobility also carry over to end-host multihoming. [RFC4218] provides a threat analysis for IPv6 multihoming, and the remainder of this section first describes how HIP host multihoming addresses those previously described threats, and then it discusses some additional security considerations.
本文档的安全注意事项与[RFC8046]的安全注意事项类似，因为移动性的强大身份验证功能也适用于终端主机多主。[RFC4218]提供了IPv6多宿主的威胁分析，本节的其余部分首先介绍了HIP主机多宿主如何应对上述威胁，然后讨论了一些其他安全注意事项。
The high-level threats discussed in [RFC4218] involve redirection attacks for the purposes of packet recording, data manipulation, and availability. There are a few types of attackers to consider: on-path attackers, off-path attackers, and malicious hosts.
[RFC4218]中讨论的高级威胁涉及重定向攻击，用于数据包记录、数据操纵和可用性。有几种类型的攻击者需要考虑：路径内攻击者、路径外攻击者和恶意主机。
[RFC4218] also makes the comment that in identifier/locator split solutions such as HIP, application security mechanisms should be tied to the identifier, not the locator, and attacks on the identifier mechanism and on the mechanism binding locators to the identifier are of concern. This document does not consider the former issue (application-layer security bindings) to be within scope. The latter issue (locator bindings to identifier) is directly addressed by the cryptographic protections of the HIP protocol, in that locators associated to an identifier are listed in HIP packets that are signed using the identifier key.
[RFC4218]还指出，在标识符/定位器拆分解决方案（如HIP）中，应用程序安全机制应绑定到标识符，而不是定位器，对标识符机制和将定位器绑定到标识符的机制的攻击值得关注。本文档不考虑前一个问题（应用层安全绑定）在范围内。后一个问题（定位器与标识符的绑定）由HIP协议的加密保护直接解决，因为与标识符关联的定位器列在使用标识符密钥签名的HIP数据包中。
Section 3.1 of [RFC4218] lists several classes of security configurations in use in the Internet. HIP maps to the fourth (strong identifier) and fifth ("leap-of-faith") categories, the
[RFC4218]第3.1节列出了互联网中使用的几种安全配置。HIP映射到第四个（强标识符）和第五个（“信仰的飞跃”）类别
latter being associated with the optional opportunistic mode of HIP operation. The remainder of Section 3 describes existing security problems in the Internet and comments that the goal of a multihoming solution is not to solve them specifically but rather not to make any of them worse. HIP multihoming should not increase the severity of the identified risks. One concern for both HIP mobility and multihoming is the susceptibility of the mechanisms to misuse flooding-based redirections due to a malicious host. The mechanisms described in [RFC8046] for address verification are important in this regard.
后者与髋关节手术的选择性机会主义模式有关。第3节的其余部分描述了Internet中存在的安全问题，并指出多宿解决方案的目标不是专门解决这些问题，而是不会使任何问题变得更糟。髋关节多中心不应增加已识别风险的严重性。HIP移动性和多宿主的一个问题是，由于恶意主机，这些机制容易误用基于洪泛的重定向。[RFC8046]中描述的地址验证机制在这方面很重要。
Regarding the new types of threats introduced by multihoming (Section 4 of [RFC4218]), HIP multihoming should not introduce new concerns. Classic and premeditated redirection are prevented by the strong authentication in HIP messages. Third-party DoS attacks are prevented by the address verification mechanism. Replay attacks can be avoided via use of replay protection in ESP SAs. In addition, accepting packets from unknown locators is protected by either the strong authentication in the HIP control packets or by the ESP-based encryption in use for data packets.
关于多宿引入的新类型威胁（RFC4218第4节），HIP多宿不应引入新问题。HIP消息中的强身份验证阻止了经典和有预谋的重定向。地址验证机制可防止第三方DoS攻击。通过在ESP SAs中使用重播保护，可以避免重播攻击。此外，接受来自未知定位器的数据包受HIP控制数据包中的强身份验证或用于数据包的基于ESP的加密保护。
The HIP mechanisms are designed to limit the ability to introduce DoS on the mechanisms themselves (Section 7 of [RFC4218]). Care is taken in the HIP base exchange to avoid creating state or performing much work before hosts can authenticate one another. A malicious host involved in HIP multihoming with another host might attempt to misuse the mechanisms for multihoming by, for instance, increasing the state required or inducing a resource limitation attack by sending too many candidate locators to the peer host. Therefore, implementations supporting the multihoming extensions should consider avoiding accepting large numbers of peer locators and rate limiting any UPDATE messages being exchanged.
HIP机构设计用于限制在机构本身上引入DoS的能力（RFC4218第7节）。在HIP-base exchange中要小心，以避免在主机相互验证之前创建状态或执行大量工作。与另一台主机进行HIP多宿主的恶意主机可能会尝试滥用多宿主机制，例如，通过增加所需状态或通过向对等主机发送太多候选定位器来诱导资源限制攻击。因此，支持多归属扩展的实现应该考虑避免接受大量对等点定位器和速率限制被交换的任何更新消息。
The exposure of a host's IP addresses through HIP mobility and multihoming extensions may raise the following privacy concern. The administrator of a host may be trying to hide its location in some context through the use of a VPN or other virtual interfaces. Similar privacy issues also arise in other frameworks such as WebRTC and are not specific to HIP. Implementations SHOULD provide a mechanism to allow the host administrator to block the exposure of selected addresses or address ranges.
通过HIP移动和多宿扩展暴露主机的IP地址可能会引起以下隐私问题。主机管理员可能试图通过使用VPN或其他虚拟接口在某些上下文中隐藏其位置。类似的隐私问题也出现在其他框架中，如WebRTC，并且不特定于HIP。实现应提供一种机制，允许主机管理员阻止所选地址或地址范围的公开。
Finally, some implementations of VPN tunneling have experienced instances of 'leakage' of flows that were intended to have been protected by a security tunnel but are instead sent in the clear, perhaps because some of the addresses used fall outside of the range of addresses configured for the tunnel in the security policy or association database. Implementors are advised to take steps to
最后，VPN隧道的一些实现已经经历了流的“泄漏”实例，这些流本打算受到安全隧道的保护，但却以明文形式发送，可能是因为使用的某些地址超出了安全策略或关联数据库中为隧道配置的地址范围。建议实施者采取措施
ensure that the usage of multiple addresses between hosts does not cause accidental leakage of some data session traffic outside of the ESP-protected envelope.
确保主机之间使用多个地址不会导致某些数据会话流量意外泄漏到ESP保护的信封之外。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 6724，DOI 10.17487/RFC67242012年9月<http://www.rfc-editor.org/info/rfc6724>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <http://www.rfc-editor.org/info/rfc7401>.
[RFC7401]Moskowitz，R.，Ed.，Heer，T.，Jokela，P.，和T.Henderson，“主机身份协议版本2（HIPv2）”，RFC 7401，DOI 10.17487/RFC7401，2015年4月<http://www.rfc-editor.org/info/rfc7401>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, <http://www.rfc-editor.org/info/rfc7402>.
[RFC7402]Jokela，P.，Moskowitz，R.，和J.Melen，“将封装安全有效载荷（ESP）传输格式与主机标识协议（HIP）结合使用”，RFC 7402，DOI 10.17487/RFC7402，2015年4月<http://www.rfc-editor.org/info/rfc7402>.
[RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017, <http://www.rfc-editor.org/info/rfc8046>.
[RFC8046]Henderson，T.，Ed.，Vogt，C.，和J.Arkko，“主机身份协议下的主机移动性”，RFC 8046，DOI 10.17487/RFC8046，2017年2月<http://www.rfc-editor.org/info/rfc8046>.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, October 2005, <http://www.rfc-editor.org/info/rfc4218>.
[RFC4218]Nordmark，E.和T.Li，“与IPv6多宿主解决方案相关的威胁”，RFC 4218，DOI 10.17487/RFC4218，2005年10月<http://www.rfc-editor.org/info/rfc4218>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，DOI 10.17487/RFC4303，2005年12月<http://www.rfc-editor.org/info/rfc4303>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的三级多主Shim协议”，RFC 5533，DOI 10.17487/RFC5533，2009年6月<http://www.rfc-editor.org/info/rfc5533>.
Acknowledgments
致谢
This document contains content that was originally included in RFC 5206. Pekka Nikander and Jari Arkko originated RFC 5206, and Christian Vogt and Thomas Henderson (editor) later joined as coauthors. Also in RFC 5206, Greg Perkins contributed the initial draft of the security section, and Petri Jokela was a coauthor of the initial individual submission.
本文档包含最初包含在RFC 5206中的内容。Pekka Nikander和Jari Arkko创立了RFC 5206，Christian Vogt和Thomas Henderson（编辑）后来加入为合著者。同样在RFC 5206中，Greg Perkins提供了安全部分的初稿，Petri Jokela是初次个人提交的合著者。
The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan Melen for many improvements to the document. Concepts from a paper on host multihoming across address families, by Samu Varjonen, Miika Komu, and Andrei Gurtov, contributed to this revised specification.
作者感谢Miika Komu、Mika Kousa、Jeff Ahrenholz和Jan Melen对文档的许多改进。Samu Varjonen、Miika Komu和Andrei Gurtov在一篇关于跨地址族的主机多宿主的论文中提出了一些概念，这些概念为本修订规范做出了贡献。
Authors' Addresses
作者地址
Thomas R. Henderson (editor) University of Washington Campus Box 352500 Seattle, WA United States of America
Thomas R. Henderson（编辑）华盛顿大学校园352500号箱，西雅图，美利坚合众国
Email: tomhend@u.washington.edu
Email: tomhend@u.washington.edu
Christian Vogt Independent 3473 North First Street San Jose, CA 95134 United States of America
Christian Vogt Independent美国加利福尼亚州圣何塞北第一街3473号，邮编95134
Email: mail@christianvogt.net
Email: mail@christianvogt.net
Jari Arkko Ericsson Jorvas, FIN-02420 Finland
芬兰FIN-02420雅丽阿尔科爱立信乔瓦斯酒店
Phone: +358 40 5079256
Email: jari.arkko@piuha.net
Phone: +358 40 5079256
Email: jari.arkko@piuha.net