Internet Engineering Task Force (IETF) M. Komu
Request for Comments: 5770 HIIT
Category: Experimental T. Henderson
ISSN: 2070-1721 The Boeing Company
H. Tschofenig
Nokia Siemens Networks
J. Melen
A. Keranen, Ed.
Ericsson Research Nomadiclab
April 2010
Internet Engineering Task Force (IETF) M. Komu
Request for Comments: 5770 HIIT
Category: Experimental T. Henderson
ISSN: 2070-1721 The Boeing Company
H. Tschofenig
Nokia Siemens Networks
J. Melen
A. Keranen, Ed.
Ericsson Research Nomadiclab
April 2010
Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators
用于遍历网络地址转换器的基本主机标识协议（HIP）扩展
Abstract
摘要
This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications.
本文档指定了主机标识协议（HIP）的扩展，以促进网络地址转换器（NAT）的遍历。这些扩展基于使用交互式连接建立（ICE）方法来发现两个终端主机之间的工作路径，以及在用户数据报协议（UDP）中封装安全有效负载（ESP）数据包的标准技术。本文档还定义了NAT遍历过程的元素，包括HIP中继服务器的可选使用。通过这些扩展，HIP能够在具有NAT的环境中工作，并为更高层的网络应用程序提供通用的NAT遍历解决方案。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第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/rfc5770.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5770.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Overview of Operation ...........................................7
4. Protocol Description ............................................8
4.1. Relay Registration .........................................8
4.2. ICE Candidate Gathering ...................................10
4.3. NAT Traversal Mode Negotiation ............................10
4.4. Connectivity Check Pacing Negotiation .....................12
4.5. Base Exchange via HIP Relay Server ........................12
4.6. ICE Connectivity Checks ...................................15
4.7. NAT Keepalives ............................................16
4.8. Base Exchange without ICE Connectivity Checks .............16
4.9. Initiating a Base Exchange Both with and without
UDP Encapsulation .........................................17
4.10. Sending Control Packets after the Base Exchange ..........18
5. Packet Formats .................................................18
5.1. HIP Control Packets .......................................19
5.2. Connectivity Checks .......................................19
5.3. Keepalives ................................................20
5.4. NAT Traversal Mode Parameter ..............................21
5.5. Connectivity Check Transaction Pacing Parameter ...........22
5.6. Relay and Registration Parameters .........................22
5.7. LOCATOR Parameter .........................................23
5.8. RELAY_HMAC Parameter ......................................25
5.9. Registration Types ........................................25
5.10. Notify Packet Types ......................................26
5.11. ESP Data Packets .........................................26
6. Security Considerations ........................................27
6.1. Privacy Considerations ....................................27
6.2. Opportunistic Mode ........................................27
6.3. Base Exchange Replay Protection for HIP Relay Server ......28
6.4. Demuxing Different HIP Associations .......................28
7. IANA Considerations ............................................28
8. Contributors ...................................................29
9. Acknowledgments ................................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................30
Appendix A. Selecting a Value for Check Pacing ....................32
Appendix B. Base Exchange through a Rendezvous Server .............33
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Overview of Operation ...........................................7
4. Protocol Description ............................................8
4.1. Relay Registration .........................................8
4.2. ICE Candidate Gathering ...................................10
4.3. NAT Traversal Mode Negotiation ............................10
4.4. Connectivity Check Pacing Negotiation .....................12
4.5. Base Exchange via HIP Relay Server ........................12
4.6. ICE Connectivity Checks ...................................15
4.7. NAT Keepalives ............................................16
4.8. Base Exchange without ICE Connectivity Checks .............16
4.9. Initiating a Base Exchange Both with and without
UDP Encapsulation .........................................17
4.10. Sending Control Packets after the Base Exchange ..........18
5. Packet Formats .................................................18
5.1. HIP Control Packets .......................................19
5.2. Connectivity Checks .......................................19
5.3. Keepalives ................................................20
5.4. NAT Traversal Mode Parameter ..............................21
5.5. Connectivity Check Transaction Pacing Parameter ...........22
5.6. Relay and Registration Parameters .........................22
5.7. LOCATOR Parameter .........................................23
5.8. RELAY_HMAC Parameter ......................................25
5.9. Registration Types ........................................25
5.10. Notify Packet Types ......................................26
5.11. ESP Data Packets .........................................26
6. Security Considerations ........................................27
6.1. Privacy Considerations ....................................27
6.2. Opportunistic Mode ........................................27
6.3. Base Exchange Replay Protection for HIP Relay Server ......28
6.4. Demuxing Different HIP Associations .......................28
7. IANA Considerations ............................................28
8. Contributors ...................................................29
9. Acknowledgments ................................................29
10. References ....................................................29
10.1. Normative References .....................................29
10.2. Informative References ...................................30
Appendix A. Selecting a Value for Check Pacing ....................32
Appendix B. Base Exchange through a Rendezvous Server .............33
HIP [RFC5201] is defined as a protocol that runs directly over IPv4 or IPv6, and HIP coordinates the setup of ESP security associations [RFC5202] that are also specified to run over IPv4 or IPv6. This approach is known to have problems traversing NATs and other middleboxes [RFC5207]. This document defines HIP extensions for the traversal of both Network Address Translator (NAT) and Network Address and Port Translator (NAPT) middleboxes. The document generally uses the term NAT to refer to these types of middleboxes.
HIP[RFC5201]定义为直接在IPv4或IPv6上运行的协议，HIP协调ESP安全关联[RFC5202]的设置，这些关联也被指定在IPv4或IPv6上运行。众所周知，这种方法在穿越NAT和其他中间盒时存在问题[RFC5207]。本文档定义了用于遍历网络地址转换器（NAT）和网络地址和端口转换器（NAPT）中间盒的HIP扩展。文档通常使用术语NAT来指代这些类型的中间盒。
Currently deployed NAT devices do not operate consistently even though a recommended behavior is described in [RFC4787]. The HIP protocol extensions in this document make as few assumptions as possible about the behavior of the NAT devices so that NAT traversal will work even with legacy NAT devices. The purpose of these extensions is to allow two HIP-enabled hosts to communicate with each other even if one or both of the communicating hosts are in a network that is behind one or more NATs.
即使[RFC4787]中描述了推荐的行为，当前部署的NAT设备也无法持续运行。本文档中的HIP协议扩展对NAT设备的行为做出尽可能少的假设，以便NAT遍历即使在传统NAT设备上也能工作。这些扩展的目的是允许两个支持HIP的主机相互通信，即使一个或两个通信主机位于一个或多个NAT后面的网络中。
Using the extensions defined in this document, HIP end-hosts use techniques drawn from the Interactive Connectivity Establishment (ICE) methodology [RFC5245] to find operational paths for the HIP control protocol and for ESP encapsulated data traffic. The hosts test connectivity between different locators and try to discover a direct end-to-end path between them. However, with some legacy NATs, utilizing the shortest path between two end-hosts located behind NATs is not possible without relaying the traffic through a relay, such as a Traversal Using Relay NAT (TURN) server [RFC5128]. Because relaying traffic increases the roundtrip delay and consumes resources from the relay, with the extensions described in this document, hosts try to avoid using the TURN server whenever possible.
使用本文档中定义的扩展，HIP端主机使用从交互式连接建立（ICE）方法[RFC5245]中提取的技术来查找HIP控制协议和ESP封装数据流量的操作路径。主机测试不同定位器之间的连接，并尝试发现它们之间的直接端到端路径。然而，对于某些传统NAT，如果不通过中继中继（例如使用中继NAT（TURN）服务器进行遍历[RFC5128]，则不可能利用NAT后面的两个终端主机之间的最短路径。由于中继通信增加了往返延迟，并消耗了中继的资源，因此使用本文档中描述的扩展，主机尽可能避免使用TURN服务器。
HIP has defined a rendezvous server [RFC5204] to allow for mobile HIP hosts to establish a stable point-of-contact in the Internet. This document defines extensions to the rendezvous server that solve the same problems, but for both NATed and non-NATed networks. The extended rendezvous server, called a "HIP relay server", forwards HIP control packets between an Initiator and a Responder, allowing hosts to be located behind NATs. This behavior is in contrast to the HIP rendezvous service that forwards only the initial I1 packet of the base exchange; an approach that is less likely to work in a NATed environment [RFC5128]. Therefore, when using relays to traverse NATs, HIP uses a HIP relay server for the control traffic and a TURN server for the data traffic.
HIP定义了一个会合服务器[RFC5204]，允许移动HIP主机在互联网上建立稳定的联系点。本文档定义了对会合服务器的扩展，这些扩展解决了相同的问题，但同时适用于NATed和非NATed网络。被称为“HIP中继服务器”的扩展会合服务器在发起方和响应方之间转发HIP控制数据包，允许主机位于NAT后面。这种行为与仅转发基站交换的初始I1数据包的HIP会合服务形成对比；一种不太可能在不稳定环境中工作的方法[RFC5128]。因此，当使用中继穿越NAT时，HIP使用HIP中继服务器进行控制流量，使用TURN服务器进行数据流量。
The basis for the connectivity checks is ICE [RFC5245]. [RFC5245] describes ICE as follows:
连接检查的基础是ICE[RFC5245]。[RFC5245]对ICE的描述如下：
A technique for NAT traversal for UDP-based media streams (though ICE can be extended to handle other transport protocols, such as TCP) established by the offer/answer model. ICE is an extension to the offer/answer model, and works by including a multiplicity of IP addresses and ports in SDP offers and answers, which are then tested for connectivity by peer-to-peer connectivity checks. The IP addresses and ports included in the SDP and the connectivity checks are performed using the revised [Simple Traversal of the UDP Protocol through NAT (STUN)] specification [RFC5389], now renamed to Session Traversal Utilities for NAT.
一种通过提供/应答模型建立的基于UDP的媒体流（尽管ICE可以扩展到处理其他传输协议，如TCP）的NAT遍历技术。ICE是提供/应答模型的扩展，其工作原理是在SDP提供和应答中包含多个IP地址和端口，然后通过对等连接检查对其进行连接测试。SDP中包含的IP地址和端口以及连接检查使用修订的[通过NAT简单遍历UDP协议（STUN）]规范[RFC5389]执行，该规范现已重命名为NAT会话遍历实用程序。
The standard ICE [RFC5245] is specified with SIP in mind and it has some features that are not necessary or suitable as such for other protocols. [MMUSIC-ICE] gives instructions and recommendations on how ICE can be used for other protocols and this document follows those guidelines.
标准ICE[RFC5245]是在考虑SIP的情况下指定的，它具有一些其他协议不需要或不适用的特性。[MMUSIC-ICE]给出了ICE如何用于其他协议的说明和建议，本文档遵循这些指导原则。
Two HIP hosts that implement this specification communicate their locators to each other in the HIP base exchange. The locators are then paired with the locators of the other endpoint and prioritized according to recommended and local policies. These locator pairs are then tested sequentially by both of the end-hosts. The tests may result in multiple operational pairs but ICE procedures determine a single preferred address pair to be used for subsequent communication.
实现此规范的两个HIP主机在HIP base exchange中相互通信其定位器。然后将定位器与另一个端点的定位器配对，并根据推荐的和本地的策略确定优先级。然后由两个终端主机依次测试这些定位器对。测试可能会产生多个操作对，但ICE程序会确定用于后续通信的单个首选地址对。
In summary, the extensions in this document define:
总之，本文档中的扩展定义：
o UDP encapsulation of HIP packets
o HIP数据包的UDP封装
o UDP encapsulation of IPsec ESP packets
o IPsec-ESP数据包的UDP封装
o registration extensions for HIP relay services
o 髋关节接力服务注册延期
o how the ICE "offer" and "answer" are carried in the base exchange
o ICE“报价”和“答复”在基础交换中的传递方式
o interaction with ICE connectivity check messages
o 与ICE连接检查消息的交互
o backwards compatibility issues with rendezvous servers
o 与集合服务器的向后兼容性问题
o a number of optimizations (such as when the ICE connectivity tests can be omitted)
o 许多优化（例如，当可以省略ICE连接测试时）
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document borrows terminology from [RFC5201], [RFC5206], [RFC4423], [RFC5245], and [RFC5389]. Additionally, the following terms are used:
本文件借用了[RFC5201]、[RFC5206]、[RFC4423]、[RFC5245]和[RFC5389]中的术语。此外，还使用以下术语：
Rendezvous server: A host that forwards I1 packets to the Responder.
会合服务器：将I1数据包转发给响应程序的主机。
HIP relay server: A host that forwards any kind of HIP control packets between the Initiator and the Responder.
HIP中继服务器：在发起方和响应方之间转发任何类型HIP控制数据包的主机。
TURN server: A server that forwards data traffic between two end-hosts as defined in [RFC5766].
TURN server：在[RFC5766]中定义的两个终端主机之间转发数据流量的服务器。
Locator: As defined in [RFC5206]: "A name that controls how the packet is routed through the network and demultiplexed by the end-host. It may include a concatenation of traditional network addresses such as an IPv6 address and end-to-end identifiers such as an ESP SPI. It may also include transport port numbers or IPv6 Flow Labels as demultiplexing context, or it may simply be a network address."
定位器：如[RFC5206]中所定义：“控制数据包如何通过网络路由并由终端主机解复用的名称。它可以包括传统网络地址（如IPv6地址）和端到端标识符（如ESP SPI）的串联。它还可能包括传输端口号或IPv6流标签作为解复用上下文，也可能只是一个网络地址。”
LOCATOR (written in capital letters): Denotes a HIP control packet parameter that bundles multiple locators together.
定位器（大写）：表示将多个定位器捆绑在一起的HIP控制数据包参数。
ICE offer: The Initiator's LOCATOR parameter in a HIP I2 control packet.
ICE报价：HIP I2控制数据包中启动器的定位器参数。
ICE answer: The Responder's LOCATOR parameter in a HIP R2 control packet.
ICE回答：HIP R2控制数据包中响应者的定位器参数。
Transport address: Transport layer port and the corresponding IPv4/v6 address.
传输地址：传输层端口和相应的IPv4/v6地址。
Candidate: A transport address that is a potential point of contact for receiving data.
候选地址：一个传输地址，是接收数据的潜在联系人。
Host candidate: A candidate obtained by binding to a specific port from an IP address on the host.
候选主机：通过从主机上的IP地址绑定到特定端口而获得的候选主机。
Server reflexive candidate: A translated transport address of a host as observed by a HIP relay server or a STUN/TURN server.
服务器自反候选：HIP中继服务器或STUN/TURN服务器观察到的主机的转换传输地址。
Peer reflexive candidate: A translated transport address of a host as observed by its peer.
对等自反候选：对等方观察到的主机的翻译传输地址。
Relayed candidate: A transport address that exists on a TURN server. Packets that arrive at this address are relayed towards the TURN client.
中继候选地址：存在于TURN服务器上的传输地址。到达该地址的数据包被中继到TURN客户端。
+-------+
| HIP |
+--------+ | Relay | +--------+
| TURN | +-------+ | STUN |
| Server | / \ | Server |
+--------+ / \ +--------+
/ \
/ \
/ \
/ <- Signaling -> \
/ \
+-------+ +-------+
| NAT | | NAT |
+-------+ +-------+
/ \
/ \
+-------+ +-------+
| Init- | | Resp- |
| iator | | onder |
+-------+ +-------+
+-------+
| HIP |
+--------+ | Relay | +--------+
| TURN | +-------+ | STUN |
| Server | / \ | Server |
+--------+ / \ +--------+
/ \
/ \
/ \
/ <- Signaling -> \
/ \
+-------+ +-------+
| NAT | | NAT |
+-------+ +-------+
/ \
/ \
+-------+ +-------+
| Init- | | Resp- |
| iator | | onder |
+-------+ +-------+
Figure 1: Example Network Configuration
图1：示例网络配置
In the example configuration depicted in Figure 1, both Initiator and Responder are behind one or more NATs, and both private networks are connected to the public Internet. To be contacted from behind a NAT, the Responder must be registered with a HIP relay server reachable on the public Internet, and we assume, as a starting point, that the Initiator knows both the Responder's Host Identity Tag (HIT) and the
在图1所示的示例配置中，发起方和响应方都位于一个或多个NAT后面，并且两个专用网络都连接到公共Internet。要从NAT后面联系，响应者必须在公共互联网上可访问的HIP中继服务器上注册，并且我们假设，作为起点，启动器知道响应者的主机标识标签（HIT）和
address of one of its relay servers (how the Initiator learns of the Responder's relay server is outside of the scope of this document, but may be through DNS or another name service).
其一个中继服务器的地址（发起方了解响应方中继服务器的方式不在本文档范围内，但可能通过DNS或其他名称服务）。
The first steps are for both the Initiator and Responder to register with a relay server (need not be the same one) and gather a set of address candidates. The hosts may use TURN and STUN servers for gathering the candidates. Next, the HIP base exchange is carried out by encapsulating the HIP control packets in UDP datagrams and sending them through the Responder's relay server. As part of the base exchange, each HIP host learns of the peer's candidate addresses through the ICE offer/answer procedure embedded in the base exchange.
第一步是启动器和响应程序向中继服务器注册（不一定是同一个服务器）并收集一组候选地址。主持人可以使用TURN和STUN服务器收集候选人。接下来，通过将HIP控制数据包封装在UDP数据报中并通过响应者的中继服务器发送它们来执行HIP基本交换。作为基本交换的一部分，每个HIP主机通过嵌入在基本交换中的ICE提供/应答过程了解对等方的候选地址。
Once the base exchange is completed, HIP has established a working communication session (for signaling) via a relay server, but the hosts still work to find a better path, preferably without a relay, for the ESP data flow. For this, ICE connectivity checks are carried out until a working pair of addresses is discovered. At the end of the procedure, if successful, the hosts will have enabled a UDP-based flow that traverses both NATs, with the data flowing directly from NAT to NAT or via a TURN server. Further HIP signaling can be sent over the same address/port pair and is demultiplexed from data traffic via a marker in the payload. Finally, NAT keepalives will be sent as needed.
一旦基本交换完成，HIP已经通过中继服务器建立了工作通信会话（用于信令），但主机仍在为ESP数据流寻找更好的路径，最好没有中继。为此，执行ICE连接检查，直到发现一对工作地址。在过程结束时，如果成功，主机将启用一个基于UDP的流，该流将遍历两个NAT，数据将直接从NAT流到NAT或通过TURN服务器。进一步的HIP信令可以通过相同的地址/端口对发送，并通过有效负载中的标记从数据通信中解复用。最后，NAT keepalives将根据需要发送。
If either one of the hosts knows that it is not behind a NAT, hosts can negotiate during the base exchange a different mode of NAT traversal that does not use ICE connectivity checks, but only UDP encapsulation of HIP and ESP. Also, it is possible for the Initiator to simultaneously try a base exchange with and without UDP encapsulation. If a base exchange without UDP encapsulation succeeds, no ICE connectivity checks or UDP encapsulation of ESP are needed.
如果任一主机知道它不在NAT后面，则主机可以在基本交换期间协商不同的NAT穿越模式，该模式不使用ICE连接检查，而只使用HIP和ESP的UDP封装。此外，启动器还可以同时尝试使用UDP封装和不使用UDP封装的基本交换。如果没有UDP封装的基本交换成功，则不需要ICE连接检查或ESP的UDP封装。
This section describes the normative behavior of the protocol extension. Examples of packet exchanges are provided for illustration purposes.
本节描述协议扩展的规范行为。出于说明目的，提供了分组交换的示例。
HIP rendezvous servers operate in non-NATed environments and their use is described in [RFC5204]. This section specifies a new middlebox extension, called the HIP relay server, for operating in NATed environments. A HIP relay server forwards HIP control packets between the Initiator and the Responder.
HIP会合服务器在非固定环境中运行，其使用在[RFC5204]中进行了说明。本节指定了一个新的中间盒扩展，称为HIP中继服务器，用于在网络环境中运行。HIP中继服务器在发起方和响应方之间转发HIP控制数据包。
End-hosts cannot use the HIP relay service for forwarding the ESP data plane. Instead, they use TURN servers [RFC5766].
终端主机无法使用HIP中继服务转发ESP数据平面。相反，他们使用TURN服务器[RFC5766]。
A HIP relay server MUST silently drop packets to a HIP relay client that has not previously registered with the HIP relay. The registration process follows the generic registration extensions defined in [RFC5203] and is illustrated in Figure 2.
HIP中继服务器必须以静默方式将数据包丢弃到以前未向HIP中继注册的HIP中继客户端。注册过程遵循[RFC5203]中定义的通用注册扩展，如图2所示。
HIP HIP
Relay Relay
Client Server
| 1. UDP(I1) |
+------------------------------------------------------->|
| |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) |
|<-------------------------------------------------------+
| |
| 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) |
+------------------------------------------------------->|
| |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) |
|<-------------------------------------------------------+
| |
HIP HIP
Relay Relay
Client Server
| 1. UDP(I1) |
+------------------------------------------------------->|
| |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP))) |
|<-------------------------------------------------------+
| |
| 3. UDP(I2(REG_REQ(RELAY_UDP_HIP))) |
+------------------------------------------------------->|
| |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM)) |
|<-------------------------------------------------------+
| |
Figure 2: Example Registration with a HIP Relay
图2：髋关节接力器的注册示例
In step 1, the relay client (Initiator) starts the registration procedure by sending an I1 packet over UDP. It is RECOMMENDED that the Initiator select a random port number from the ephemeral port range 49152-65535 for initiating a base exchange. Alternatively, a host MAY also use a single fixed port for initiating all outgoing connections. However, the allocated port MUST be maintained until all of the corresponding HIP Associations are closed. It is RECOMMENDED that the HIP relay server listen to incoming connections at UDP port 10500. If some other port number is used, it needs to be known by potential Initiators.
在步骤1中，中继客户端（启动器）通过UDP发送I1数据包来启动注册过程。建议启动器从临时端口范围49152-65535中选择一个随机端口号，以启动基本交换。或者，主机也可以使用单个固定端口来启动所有传出连接。但是，在关闭所有相应的HIP关联之前，必须保持分配的端口。建议HIP中继服务器侦听UDP端口10500处的传入连接。如果使用其他端口号，则潜在的启动器需要知道该端口号。
In step 2, the HIP relay server (Responder) lists the services that it supports in the R1 packet. The support for HIP-over-UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP (see Section 5.9).
在步骤2中，HIP中继服务器（响应器）列出了它在R1数据包中支持的服务。对HIP over UDP中继的支持由注册类型值中继_UDP_HIP表示（参见第5.9节）。
In step 3, the Initiator selects the services for which it registers and lists them in the REG_REQ parameter. The Initiator registers for HIP relay service by listing the RELAY_UDP_HIP value in the request parameter.
在步骤3中，启动器选择其注册的服务，并在REG_REQ参数中列出这些服务。启动器通过在请求参数中列出relay_UDP_HIP值来注册HIP中继服务。
In step 4, the Responder concludes the registration procedure with an R2 packet and acknowledges the registered services in the REG_RES parameter. The Responder denotes unsuccessful registrations (if any) in the REG_FAILED parameter of R2. The Responder also includes a REG_FROM parameter that contains the transport address of the client as observed by the relay (Server Reflexive candidate). After the registration, the client sends NAT keepalives, as described in Section 4.7, periodically to the relay to keep possible NAT bindings between the client and the relay alive. The relay client maintains the HIP association with the relay server as long as it requires relaying service from it.
在步骤4中，响应者使用R2数据包结束注册过程，并在REG_RES参数中确认已注册的服务。响应者在R2的REG_FAILED参数中表示注册失败（如果有）。响应程序还包括REG_FROM参数，该参数包含中继（服务器自反候选）观察到的客户端传输地址。注册后，客户机定期向中继发送NAT keepalives，如第4.7节所述，以保持客户机和中继之间可能的NAT绑定处于活动状态。中继客户端保持与中继服务器的HIP关联，只要它需要来自它的中继服务。
If a host is going to use ICE, it needs to gather a set of address candidates. The candidate gathering SHOULD be done as defined in Section 4.1 of [RFC5245]. Candidates need to be gathered for the UDP-encapsulated flow of HIP and ESP traffic. This flow corresponds to one ICE media stream and component. Since ICE component IDs are not needed, they are not explicitly signaled and ID value of 1 SHOULD be used for ICE processing, where needed. The Initiator takes the role of the ICE controlling agent.
如果主机要使用ICE，它需要收集一组候选地址。应按照[RFC5245]第4.1节的规定收集候选人。需要为HIP和ESP流量的UDP封装流收集候选对象。该流对应于一个ICE媒体流和组件。由于不需要ICE组件ID，因此不会显式通知它们，并且在需要时，ID值1应用于ICE处理。发起人扮演ICE控制代理的角色。
The candidate gathering can be done at any time, but it needs to be done before sending an I2 or R2 in the base exchange if ICE is to be used for the connectivity checks. It is RECOMMENDED that all three types of candidates (host, server reflexive, and relayed) are gathered to maximize the probability of successful NAT traversal. However, if no TURN server is used, and the host has only a single local IP address to use, the host MAY use the local address as the only host candidate and the address from the REG_FROM parameter discovered during the relay registration as a server reflexive candidate. In this case, no further candidate gathering is needed.
候选收集可以在任何时候完成，但如果ICE用于连接检查，则需要在基本交换机中发送I2或R2之前完成。建议收集所有三种候选类型（主机、服务器自反和中继），以最大限度地提高NAT穿越成功的概率。但是，如果未使用TURN服务器，且主机只有一个本地IP地址可供使用，则主机可将本地地址用作唯一的主机候选，并将中继注册期间发现的REG_from参数中的地址用作服务器自反候选。在这种情况下，不需要进一步收集候选人。
This section describes the usage of a new non-critical parameter type. The presence of the parameter in a HIP base exchange means that the end-host supports NAT traversal extensions described in this document. As the parameter is non-critical (as defined in Section 5.2.1 of [RFC5201]), it can be ignored by an end-host, which means that the host does not support or is not willing to use these extensions.
本节介绍新的非关键参数类型的用法。HIP base exchange中存在该参数意味着终端主机支持本文档中描述的NAT遍历扩展。由于该参数是非关键参数（如[RFC5201]第5.2.1节所定义），因此终端主机可以忽略该参数，这意味着主机不支持或不愿意使用这些扩展。
With registration with a HIP relay, it is usually sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since the relay is assumed to be in public address space. Thus, the relay SHOULD propose the UDP-ENCAPSULATION mode as the preferred or only mode.
在向HIP中继注册时，通常使用NAT遍历的UDP封装模式就足够了，因为该中继假定位于公共地址空间中。因此，中继应建议UDP封装模式作为首选或唯一模式。
The NAT traversal mode negotiation in a HIP base exchange is illustrated in Figure 3.
HIP-base交换中的NAT遍历模式协商如图3所示。
Initiator Responder
| 1. UDP(I1) |
+--------------------------------------------------------------->|
| |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) |
|<---------------------------------------------------------------+
| |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR, ..)) |
+--------------------------------------------------------------->|
| |
| 4. UDP(R2(.., LOCATOR, ..)) |
|<---------------------------------------------------------------+
| |
Initiator Responder
| 1. UDP(I1) |
+--------------------------------------------------------------->|
| |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) |
|<---------------------------------------------------------------+
| |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR, ..)) |
+--------------------------------------------------------------->|
| |
| 4. UDP(R2(.., LOCATOR, ..)) |
|<---------------------------------------------------------------+
| |
Figure 3: Negotiation of NAT Traversal Mode
图3:NAT穿越模式的协商
In step 1, the Initiator sends an I1 to the Responder. In step 2, the Responder responds with an R1. The NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal modes the Responder supports. The modes specified in this document are shown in Table 1 and their values are specified in Section 5.4.
在步骤1中，发起方向响应方发送I1。在步骤2中，响应者用R1响应。R1中的NAT_transversal_MODE参数包含响应程序支持的NAT遍历模式列表。本文件中规定的模式见表1，其值见第5.4节。
+-------------------+-----------------------------------------------+
| Type | Purpose |
+-------------------+-----------------------------------------------+
| RESERVED | Reserved for future use |
| | |
| UDP-ENCAPSULATION | Use only UDP encapsulation of the HIP |
| | signaling traffic and ESP (no ICE |
| | connectivity checks) |
| | |
| ICE-STUN-UDP | UDP-encapsulated control and data traffic |
| | with ICE-based connectivity checks using STUN |
| | messages |
+-------------------+-----------------------------------------------+
+-------------------+-----------------------------------------------+
| Type | Purpose |
+-------------------+-----------------------------------------------+
| RESERVED | Reserved for future use |
| | |
| UDP-ENCAPSULATION | Use only UDP encapsulation of the HIP |
| | signaling traffic and ESP (no ICE |
| | connectivity checks) |
| | |
| ICE-STUN-UDP | UDP-encapsulated control and data traffic |
| | with ICE-based connectivity checks using STUN |
| | messages |
+-------------------+-----------------------------------------------+
Table 1: NAT Traversal Modes
表1:NAT穿越模式
In step 3, the Initiator sends an I2 that includes a NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the Initiator from the list of modes offered by the Responder. If ICE mode was selected, the I2 also includes the "Transport address" locators (as defined in Section 5.7) of the Initiator in a LOCATOR parameter. The locators in I2 are the "ICE offer".
在步骤3中，发起者发送包括NAT_遍历模式参数的I2。它包含发起者从响应者提供的模式列表中选择的模式。如果选择了ICE模式，I2还包括定位器参数中启动器的“传输地址”定位器（定义见第5.7节）。I2中的定位器是“ICE报价”。
In step 4, the Responder concludes the base exchange with an R2 packet. If the Initiator chose ICE NAT traversal mode, the Responder includes a LOCATOR parameter in the R2 packet. The locators in R2, encoded like the locators in I2, are the "ICE answer". If the NAT traversal mode selected by the Initiator is not supported by the Responder, the Responder SHOULD reply with a NOTIFY packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange.
在步骤4中，响应者使用R2数据包结束基本交换。如果发起方选择ICE NAT穿越模式，则响应方在R2数据包中包含定位器参数。R2中的定位器编码与I2中的定位器类似，是“ICE应答”。如果发起方选择的NAT遍历模式不受响应方支持，则响应方应使用类型为NO_VALID_NAT_traversal_mode_参数的NOTIFY数据包进行响应，并中止基本交换。
As explained in [RFC5245], when a NAT traversal mode with connectivity checks is used, new transactions should not be started too fast to avoid congestion and overwhelming the NATs.
如[RFC5245]中所述，当使用带有连接检查的NAT遍历模式时，新事务不应启动得太快，以避免拥塞和淹没NAT。
For this purpose, during the base exchange, hosts can negotiate a transaction pacing value, Ta, using a TRANSACTION_PACING parameter in R1 and I2 packets. The parameter contains the minimum time (expressed in milliseconds) the host would wait between two NAT traversal transactions, such as starting a new connectivity check or retrying a previous check. If a host does not include this parameter in the base exchange, a Ta value of 500 ms MUST be used as that host's minimum value. The value that is used by both of the hosts is the higher out of the two offered values.
为此，在基本交换期间，主机可以使用R1和I2数据包中的transaction_起搏参数协商事务起搏值Ta。该参数包含主机在两个NAT遍历事务（例如启动新的连接检查或重试以前的检查）之间等待的最短时间（以毫秒为单位）。如果主机在基本交换中不包含此参数，则必须使用500 ms的Ta值作为该主机的最小值。两台主机使用的值都是两个提供值中较高的值。
Hosts SHOULD NOT use values smaller than 20 ms for the minimum Ta, since such values may not work well with some NATs, as explained in [RFC5245]. The Initiator MUST NOT propose a smaller value than what the Responder offered.
主机不应使用小于20 ms的值作为最小Ta，因为此类值可能无法与某些NAT配合使用，如[RFC5245]中所述。发起者提出的值不得小于响应者提供的值。
The minimum Ta value SHOULD be configurable, and if no value is configured, a value of 500 ms MUST be used. Guidelines for selecting a Ta value are given in Appendix A. Currently this feature applies only to the ICE-STUN-UDP NAT traversal mode, but any other mode using connectivity checks SHOULD utilize this feature.
最小Ta值应可配置，如果未配置值，则必须使用500 ms的值。附录a中给出了选择Ta值的指导原则。目前，此功能仅适用于ICE-STUN-UDP NAT穿越模式，但使用连接检查的任何其他模式都应使用此功能。
This section describes how the Initiator and Responder perform a base exchange through a HIP relay server. The NAT traversal mode negotiation (denoted as NAT_TM in the example) was described in Section 4.3 and is not repeated here. If a relay receives an R1 or I2 packet without the NAT traversal mode parameter, it MUST drop it and SHOULD send a NOTIFY error packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1/I2.
本节介绍启动器和响应程序如何通过HIP中继服务器执行基本交换。NAT穿越模式协商（在本例中表示为NAT_TM）在第4.3节中进行了描述，此处不再重复。如果中继接收到没有NAT遍历模式参数的R1或I2数据包，它必须丢弃该数据包，并应向R1/I2的发送方发送类型为NO_VALID_NAT_Travers_mode_参数的NOTIFY error数据包。
It is RECOMMENDED that the Initiator send an I1 packet encapsulated in UDP when it is destined to an IPv4 address of the Responder. Respectively, the Responder MUST respond to such an I1 packet with a UDP-encapsulated R1 packet and the rest of the base exchange, I2 and R2, MUST also use UDP encapsulation.
当I1数据包的目的地是响应方的IPv4地址时，建议发起方发送UDP封装的I1数据包。响应者必须分别使用UDP封装的R1数据包响应这样的I1数据包，而基础交换的其余部分I2和R2也必须使用UDP封装。
Initiator HIP relay Responder
| 1. UDP(I1) | |
+----------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->|
| | |
| | 3. UDP(R1(RELAY_TO, NAT_TM)) |
| 4. UDP(R1(RELAY_TO, NAT_TM)) |<-------------------------------+
|<-----------------------------+ |
| | |
| 5. UDP(I2(LOCATOR, NAT_TM)) | |
+----------------------------->| 6. UDP(I2(LOCATOR, RELAY_FROM, |
| | NAT_TM)) |
| +------------------------------->|
| | |
| | 7. UDP(R2(LOCATOR, RELAY_TO)) |
| 8. UDP(R2(LOCATOR, RELAY_TO))|<-------------------------------+
|<-----------------------------+ |
| | |
Initiator HIP relay Responder
| 1. UDP(I1) | |
+----------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->|
| | |
| | 3. UDP(R1(RELAY_TO, NAT_TM)) |
| 4. UDP(R1(RELAY_TO, NAT_TM)) |<-------------------------------+
|<-----------------------------+ |
| | |
| 5. UDP(I2(LOCATOR, NAT_TM)) | |
+----------------------------->| 6. UDP(I2(LOCATOR, RELAY_FROM, |
| | NAT_TM)) |
| +------------------------------->|
| | |
| | 7. UDP(R2(LOCATOR, RELAY_TO)) |
| 8. UDP(R2(LOCATOR, RELAY_TO))|<-------------------------------+
|<-----------------------------+ |
| | |
Figure 4: Base Exchange via a HIP Relay Server
图4：通过HIP中继服务器的基本交换
In step 1 of Figure 4, the Initiator sends an I1 packet over the transport layer to the HIT of the Responder and IP address and port of the HIP relay server. The source address is one of the locators of the Initiator.
在图4的步骤1中，发起方通过传输层将I1数据包发送到响应方的HIT以及HIP中继服务器的IP地址和端口。源地址是启动器的定位器之一。
In step 2, the HIP relay server receives the I1 packet. If the destination HIT belongs to a registered Responder, the relay processes the packet. Otherwise, the relay MUST drop the packet silently. The relay appends a RELAY_FROM parameter to the I1 packet, which contains the transport source address and port of the I1 as observed by the relay. The relay protects the I1 packet with RELAY_HMAC as described in [RFC5204], except that the parameter type is different (see Section 5.8). The relay changes the source and destination ports and IP addresses of the packet to match the values the Responder used when registering to the relay, i.e., the reverse of the R2 used in the registration. The relay MUST recalculate the transport checksum and forward the packet to the Responder.
在步骤2中，HIP中继服务器接收I1分组。如果目标命中属于已注册的响应者，则中继处理该数据包。否则，中继必须无声地丢弃数据包。中继器向I1数据包附加一个中继器_FROM参数，该数据包包含中继器观察到的I1的传输源地址和端口。继电器使用[RFC5204]中所述的继电器保护I1数据包，但参数类型不同（见第5.8节）。中继更改数据包的源端口和目标端口以及IP地址，以匹配响应程序在向中继注册时使用的值，即注册中使用的R2的相反值。中继必须重新计算传输校验和，并将数据包转发给响应程序。
In step 3, the Responder receives the I1 packet. The Responder processes it according to the rules in [RFC5201]. In addition, the Responder validates the RELAY_HMAC according to [RFC5204] and silently drops the packet if the validation fails. The Responder replies with an R1 packet to which it includes RELAY_TO and NAT traversal mode parameters. The RELAY_TO parameter MUST contain the same information as the RELAY_FROM parameter, i.e., the Initiator's transport address, but the type of the parameter is different. The RELAY_TO parameter is not integrity protected by the signature of the R1 to allow pre-created R1 packets at the Responder.
在步骤3中，响应者接收I1分组。响应者根据[RFC5201]中的规则进行处理。此外，响应者根据[RFC5204]验证中继_HMAC，并在验证失败时无声地丢弃数据包。应答器使用R1数据包进行应答，其中包括中继和NAT穿越模式参数。中继至参数必须包含与中继自参数相同的信息，即启动器的传输地址，但参数的类型不同。RELAY_TO参数不受R1签名的完整性保护，以允许在响应程序中预创建R1数据包。
In step 4, the relay receives the R1 packet. The relay drops the packet silently if the source HIT belongs to an unregistered host. The relay MAY verify the signature of the R1 packet and drop it if the signature is invalid. Otherwise, the relay rewrites the source address and port, and changes the destination address and port to match RELAY_TO information. Finally, the relay recalculates transport checksum and forwards the packet.
在步骤4中，中继器接收R1分组。如果源命中属于未注册主机，则中继会无声地丢弃数据包。中继可以验证R1数据包的签名，如果签名无效，则丢弃该签名。否则，中继器将重写源地址和端口，并更改目标地址和端口以使中继器_与信息匹配。最后，中继重新计算传输校验和并转发数据包。
In step 5, the Initiator receives the R1 packet and processes it according to [RFC5201]. The Initiator MAY use the address in the RELAY_TO parameter as a local peer-reflexive candidate for this HIP association if it is different from all known local candidates. The Initiator replies with an I2 packet that uses the destination transport address of R1 as the source address and port. The I2 packet contains a LOCATOR parameter that lists all the ICE candidates (ICE offer) of the Initiator. The candidates are encoded using the format defined in Section 5.7. The I2 packet MUST also contain a NAT traversal mode parameter with the mode the Initiator selected.
在步骤5中，启动器接收R1数据包并根据[RFC5201]对其进行处理。如果中继_TO参数中的地址不同于所有已知的本地候选地址，则发起者可以使用该地址作为该HIP关联的本地对等自反候选地址。启动器使用I2数据包进行应答，该数据包使用R1的目标传输地址作为源地址和端口。I2数据包包含一个定位器参数，该参数列出了启动器的所有ICE候选（ICE报价）。使用第5.7节中定义的格式对候选人进行编码。I2数据包还必须包含一个NAT遍历模式参数，该参数具有启动器选择的模式。
In step 6, the relay receives the I2 packet. The relay appends a RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in step 2.
在步骤6中，中继器接收I2分组。如步骤2所述，中继器将来自的中继器和中继器HMAC附加到I2分组。
In step 7, the Responder receives the I2 packet and processes it according to [RFC5201]. It replies with an R2 packet and includes a RELAY_TO parameter as explained in step 3. The R2 packet includes a LOCATOR parameter that lists all the ICE candidates (ICE answer) of the Responder. The RELAY_TO parameter is protected by the HMAC.
在步骤7中，应答器接收I2分组并根据[RFC5201]对其进行处理。如步骤3所述，它以R2数据包进行回复，并包括中继至参数。R2数据包包括一个定位器参数，该参数列出了响应者的所有ICE候选（ICE答案）。继电器至参数由HMAC保护。
In step 8, the relay processes the R2 as described in step 4. The relay forwards the packet to the Initiator. After the Initiator has received the R2 and processed it successfully, the base exchange is completed.
在步骤8中，继电器按照步骤4中所述处理R2。中继将数据包转发给启动器。启动器收到R2并成功处理后，基本交换完成。
Hosts MUST include the address of one or more HIP relay servers (including the one that is being used for the initial signaling) in the LOCATOR parameter in I2/R2 if they intend to use such servers for relaying HIP signaling immediately after the base exchange completes.
如果主机打算在基本交换完成后立即使用一个或多个HIP中继服务器中继HIP信令，则主机必须在I2/R2中的定位器参数中包含一个或多个HIP中继服务器（包括用于初始信令的服务器）的地址。
The traffic type of these addresses MUST be "HIP signaling" and they MUST NOT be used as ICE candidates. If the HIP relay server locator used for the base exchange is not included in I2/R2 LOCATOR parameters, it SHOULD NOT be used after the base exchange, but further HIP signaling SHOULD use the same path as the data traffic.
这些地址的通信量类型必须为“HIP信令”，且不得用作ICE候选地址。如果用于基本交换的HIP中继服务器定位器未包含在I2/R2定位器参数中，则不应在基本交换后使用，但进一步的HIP信令应使用与数据通信相同的路径。
If a HIP relay server was used, the Responder completes the base exchange with the R2 packet through the relay. However, the destination address the Initiator and Responder used for the base exchange packets belongs to the HIP relay server. Therefore, that address MUST NOT be used as a destination for ESP traffic. Instead, if a NAT traversal mode with ICE connectivity checks was selected, the Initiator and Responder MUST start the connectivity checks.
如果使用了HIP中继服务器，则响应者通过中继完成与R2数据包的基本交换。但是，用于基本交换数据包的启动器和响应程序的目标地址属于HIP中继服务器。因此，该地址不得用作ESP通信的目的地。相反，如果选择了带有ICE连接检查的NAT穿越模式，则启动器和响应程序必须启动连接检查。
Creating the checklist for the ICE connectivity checks should be performed as described in Section 5.7 of [RFC5245] bearing in mind that only one media stream and component is needed (so there will be only a single checklist and all candidates should have the same component ID value). The actual connectivity checks MUST be performed as described in Section 7 of [RFC5245]. Regular mode SHOULD be used for the candidate nomination. Section 5.2 defines the details of the STUN control packets. As a result of the ICE connectivity checks, ICE nominates a single transport address pair to be used if an operational address pair was found. The end-hosts MUST use this address pair for the ESP traffic.
应按照[RFC5245]第5.7节中的说明创建ICE连接检查清单，同时注意只需要一个媒体流和组件（因此只有一个清单，所有候选组件应具有相同的组件ID值）。实际连接检查必须按照[RFC5245]第7节所述进行。候选人提名应使用常规模式。第5.2节定义了眩晕控制数据包的详细信息。作为ICE连接检查的结果，ICE指定一个传输地址对，以便在找到操作地址对时使用。终端主机必须使用此地址对进行ESP通信。
The connectivity check messages MUST be paced by the value negotiated during the base exchange as described in Section 4.4. If neither one of the hosts announced a minimum pacing value, a value of 500 ms MUST be used.
连接检查消息必须按照第4.4节所述的基本交换期间协商的值进行调整。如果两台主机均未宣布最小起搏值，则必须使用500 ms的值。
For retransmissions, the retransmission timeout (RTO) value SHOULD be calculated as follows:
对于重传，重传超时（RTO）值的计算如下：
RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress))
RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress))
In the RTO formula, Ta is the value used for the connectivity check pacing, Num-Waiting is the number of pairs in the checklist in the "Waiting" state, and Num-In-Progress is the number of pairs in the "In-Progress" state. This is identical to the formula in [RFC5245] if there is only one checklist.
在RTO公式中，Ta是用于连接检查调整的值，Num Waiting是检查表中处于“等待”状态的对数，Num In Progress是处于“进行中”状态的对数。如果只有一个检查表，则这与[RFC5245]中的公式相同。
If the ICE connectivity checks failed, the hosts MUST NOT send ESP traffic to each other but MAY continue communicating using HIP packets and the locators used for the base exchange. Also, the hosts SHOULD notify each other about the failure with a CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10).
如果ICE连接检查失败，主机不得相互发送ESP通信，但可以使用HIP数据包和用于基本交换的定位器继续通信。此外，主机应使用连接检查失败通知数据包相互通知故障（见第5.10节）。
To prevent NAT states from expiring, communicating hosts send periodic keepalives to each other. HIP relay servers MAY refrain from sending keepalives if it's known that they are not behind a middlebox that requires keepalives. An end-host MUST send keepalives every 15 seconds to refresh the UDP port mapping at the NAT(s) when the control or data channel is idle. To implement failure tolerance, an end-host SHOULD have a shorter keepalive period.
为了防止NAT状态过期，通信主机彼此定期发送keepalive。如果已知HIP中继服务器不在需要keepalives的中间盒后面，则HIP中继服务器可能会避免发送keepalives。当控制或数据通道空闲时，终端主机必须每15秒发送一次keepalives，以刷新NAT上的UDP端口映射。要实现容错，终端主机的保持期应该更短。
The keepalives are STUN Binding Indications if the hosts have agreed on ICE-STUN-UDP NAT traversal mode during the base exchange. Otherwise, HIP NOTIFY packets MAY be used as keepalives.
如果主机在基本交换期间已同意ICE-STUN-UDP NAT遍历模式，则keepalives是STUN绑定指示。否则，HIP NOTIFY数据包可以用作keepalives。
The communicating hosts MUST send keepalives to each other using the transport locators they agreed to use for data and signaling when they are in the ESTABLISHED state. Also, the Initiator MUST send a NOTIFY packet to the relay to keep the NAT states alive on the path between the Initiator and relay when the Initiator has not received any response to its I1 or I2 from the Responder in 15 seconds.
当通信主机处于已建立状态时，它们必须使用它们同意用于数据和信令的传输定位器相互发送keepalive。此外，当启动器在15秒内未收到响应方对其I1或I2的任何响应时，启动器必须向中继器发送通知数据包，以保持启动器和中继器之间路径上的NAT状态处于活动状态。
In certain network environments, the ICE connectivity checks can be omitted to reduce initial connection set-up latency because a base exchange acts as an implicit connectivity test itself. For this to work, the Initiator MUST be able to reach the Responder by simply UDP encapsulating HIP and ESP packets sent to the Responder's address. Detecting and configuring this particular scenario is prone to failure unless carefully planned.
在某些网络环境中，可以省略ICE连接检查以减少初始连接设置延迟，因为基本交换本身充当隐式连接测试。为了实现这一点，发起者必须能够通过UDP封装发送到响应者地址的HIP和ESP数据包到达响应者。除非仔细计划，否则检测和配置此特定场景很容易失败。
In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT traversal mode as one of the supported modes in the R1 packet. If the Responder has registered to a HIP relay server, it MUST also include a LOCATOR parameter in R1 that contains a preferred address where the Responder is able to receive UDP-encapsulated ESP and HIP packets. This locator MUST be of type "Transport address", its Traffic type MUST be "both", and it MUST have the "Preferred bit" set (see Table 2). If there is no such locator in R1, the source address of R1 is used as the Responder's preferred address.
在这样的场景中，响应者可以包括UDP封装NAT遍历模式作为R1分组中支持的模式之一。如果响应者已注册到HIP中继服务器，则还必须在R1中包含定位器参数，该参数包含响应者能够接收UDP封装ESP和HIP数据包的首选地址。该定位器必须为“传输地址”类型，其通信类型必须为“两者”，并且必须设置“首选位”（见表2）。如果R1中没有此类定位器，则R1的源地址将用作响应者的首选地址。
The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder listed it in the supported modes and the Initiator does not wish to use ICE for searching for a more optimal path. In this case, the Initiator sends the I2 with UDP-ENCAPSULATION mode in the NAT traversal mode parameter directly to the Responder's preferred address (i.e., to the preferred locator in R1 or to the address where R1 was received from if there was no preferred locator in R1). The Initiator MAY include locators in I2 but they MUST NOT be taken as ICE candidates, since ICE will not be used for connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if R2 and I2 are received and processed successfully, a security association can be created and UDP-encapsulated ESP can be exchanged between the hosts after the base exchange completes. However, the Responder SHOULD NOT send any ESP to the Initiator's address before it has received data from the Initiator, as specified in Sections 4.4.2. and 6.9 of [RFC5201] and in Sections 3.2.9 and 5.4 of [RFC5206].
如果响应程序在支持的模式中列出UDP封装模式，并且启动器不希望使用ICE搜索更优化的路径，则启动器可以选择UDP封装模式。在这种情况下，发起者在NAT遍历模式参数中将具有UDP封装模式的I2直接发送到响应者的首选地址（即，发送到R1中的首选定位器，或者如果R1中没有首选定位器，发送到接收R1的地址）。启动器可以在I2中包含定位器，但它们不能被视为ICE候选，因为ICE将不用于UDP封装NAT遍历模式的连接。相反，如果成功接收并处理R2和I2，则可以创建安全关联，并在基本交换完成后在主机之间交换UDP封装的ESP。但是，按照第4.4.2节的规定，响应方在收到来自发起方的数据之前，不应向发起方的地址发送任何ESP。以及[RFC5201]的第6.9节和[RFC5206]的第3.2.9节和第5.4节。
Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected MUST NOT be sent via a relay, the Responder SHOULD reject such I2 packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packet (see Section 5.10).
由于选择UDP封装NAT遍历模式的I2数据包不得通过中继发送，因此响应者应拒绝此类I2数据包，并使用无效的NAT遍历参数NOTIFY数据包进行回复（见第5.10节）。
If there is no answer for the I2 packet sent directly to the Responder's preferred address, the Initiator MAY send another I2 via the HIP relay server, but it MUST NOT choose UDP-ENCAPSULATION NAT traversal mode for that I2.
如果直接发送到响应者首选地址的I2数据包没有应答，则发起方可以通过HIP中继服务器发送另一个I2，但不得为该I2选择UDP封装NAT遍历模式。
The Initiator MAY also try to simultaneously perform a base exchange with the Responder without UDP encapsulation. In such a case, the Initiator sends two I1 packets, one without and one with UDP encapsulation, to the Responder. The Initiator MAY wait for a while before sending the other I1. How long to wait and in which order to send the I1 packets can be decided based on local policy. For retransmissions, the procedure is repeated.
发起方还可以尝试在没有UDP封装的情况下与响应方同时执行基本交换。在这种情况下，发起方向响应方发送两个I1数据包，一个没有UDP封装，另一个有UDP封装。在发送另一个I1之前，启动器可能会等待一段时间。等待多长时间以及发送I1数据包的顺序可以根据本地策略决定。对于重传，重复该过程。
The I1 packet without UDP encapsulation may arrive directly, without any relays, at the Responder. When this happens, the procedures in [RFC5201] are followed for the rest of the base exchange. The Initiator may receive multiple R1 packets, with and without UDP encapsulation, from the Responder. However, after receiving a valid R1 and answering it with an I2, further R1 packets that are not retransmits of the original R1 MUST be ignored.
没有UDP封装的I1数据包可以直接到达响应程序，而不需要任何中继。当发生这种情况时，基本交换的其余部分将遵循[RFC5201]中的过程。发起方可以从响应方接收多个R1数据包，包括UDP封装和不包括UDP封装。然而，在接收到有效R1并用I2应答它之后，必须忽略不是原始R1重传的其他R1数据包。
The I1 packet without UDP encapsulation may also arrive at a HIP-capable middlebox. When the middlebox is a HIP rendezvous server and the Responder has successfully registered with the rendezvous service, the middlebox follows rendezvous procedures in [RFC5204].
没有UDP封装的I1数据包也可能到达支持HIP的中间盒。当中间箱是HIP会合服务器且响应者已成功注册会合服务时，中间箱遵循[RFC5204]中的会合程序。
If the Initiator receives a NAT traversal mode parameter in R1 without UDP encapsulation, the Initiator MAY ignore this parameter and send an I2 without UDP encapsulation and without any selected NAT traversal mode. When the Responder receives the I2 without UDP encapsulation and without NAT traversal mode, it will assume that no NAT traversal mechanism is needed. The packet processing will be done as described in [RFC5201]. The Initiator MAY store the NAT traversal modes for future use, e.g., in case of a mobility or multihoming event that causes NAT traversal to be used during the lifetime of the HIP association.
如果启动器在R1中接收到一个NAT穿越模式参数，而没有UDP封装，则启动器可能会忽略此参数，并在没有UDP封装和任何选定NAT穿越模式的情况下发送I2。当响应程序在没有UDP封装和NAT遍历模式的情况下接收到I2时，它将假定不需要NAT遍历机制。数据包处理将按照[RFC5201]中所述进行。发起者可存储NAT穿越模式以供将来使用，例如，在导致在HIP关联的生存期期间使用NAT穿越的移动性或多归属事件的情况下。
After the base exchange, the end-hosts MAY send HIP control packets directly to each other using the transport address pair established for a data channel without sending the control packets through the HIP relay server. When a host does not get acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout based on local policies, the host SHOULD resend the packet through the relay, if it was listed in the LOCATOR parameter in the base exchange.
在基本交换之后，终端主机可以使用为数据信道建立的传输地址对直接向彼此发送HIP控制分组，而无需通过HIP中继服务器发送控制分组。当主机未收到确认时，例如，根据本地策略在超时后更新或关闭数据包，主机应通过中继重新发送数据包（如果数据包列在基本交换中的LOCATOR参数中）。
If control packets are sent through a HIP relay server, the host registered with the relay MUST utilize the RELAY_TO parameter as in the base exchange. The HIP relay server SHOULD forward HIP packets to the registered hosts and forward packets from a registered host to the address in the RELAY_TO parameter. The relay MUST add a RELAY_FROM parameter to the control packets it relays to the registered hosts.
如果控制数据包通过HIP中继服务器发送，则向中继注册的主机必须使用中继参数，如在基本交换中一样。HIP中继服务器应将HIP数据包转发至注册主机，并将数据包从注册主机转发至中继参数中的地址。中继必须向其中继到已注册主机的控制数据包中添加中继\ FROM参数。
If the HIP relay server is not willing or able to relay a HIP packet, it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error notification (see Section 5.10).
如果HIP中继服务器不愿意或不能中继HIP数据包，它可以使用消息“未中继错误通知”通知数据包的发送者（见第5.10节）。
The following subsections define the parameter and packet encodings for the HIP, ESP, and ICE connectivity check packets. All values MUST be in network byte order.
以下小节定义HIP、ESP和ICE连接检查数据包的参数和数据包编码。所有值必须按网络字节顺序排列。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits of zeroes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HIP Header and Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bits of zeroes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ HIP Header and Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of UDP-Encapsulated HIP Control Packets
图5:UDP封装的HIP控制数据包的格式
HIP control packets are encapsulated in UDP packets as defined in Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except a different port number is used. Figure 5 illustrates the encapsulation. The UDP header is followed by 32 zero bits that can be used to differentiate HIP control packets from ESP packets. The HIP header and parameters follow the conventions of [RFC5201] with the exception that the HIP header checksum MUST be zero. The HIP header checksum is zero for two reasons. First, the UDP header already contains a checksum. Second, the checksum definition in [RFC5201] includes the IP addresses in the checksum calculation. The NATs unaware of HIP cannot recompute the HIP checksum after changing IP addresses.
HIP控制数据包封装在[RFC3948]第2.2节“端口4500的IKE头格式”中定义的UDP数据包中，但使用的端口号不同。图5说明了封装。UDP报头后面是32个零位，可用于区分HIP控制数据包和ESP数据包。HIP标头和参数遵循[RFC5201]的约定，但HIP标头校验和必须为零。髋部头部校验和为零有两个原因。首先，UDP报头已经包含校验和。其次，[RFC5201]中的校验和定义包括校验和计算中的IP地址。不知道HIP的NAT在更改IP地址后无法重新计算HIP校验和。
A HIP relay server or a Responder without a relay SHOULD listen at UDP port 10500 for incoming UDP-encapsulated HIP control packets. If some other port number is used, it needs to be known by potential Initiators.
HIP中继服务器或无中继的响应程序应在UDP端口10500侦听传入的UDP封装的HIP控制数据包。如果使用其他端口号，则潜在的启动器需要知道该端口号。
The connectivity checks are performed using STUN Binding requests as defined in [RFC5245]. This section describes the details of the parameters in the STUN messages.
使用[RFC5245]中定义的STUN绑定请求执行连接检查。本节介绍STUN消息中参数的详细信息。
The Binding requests MUST use STUN short-term credentials with the last 32 bits of the HITs of the Initiator and Responder as the username fragments. The username is formed from the username fragments as defined in Section 7.1.1.3 of [RFC5245]. The 32-bit username fragments are expressed using lowercase hexadecimal ASCII characters. The leading zeroes MUST NOT be omitted so that the
绑定请求必须使用STUN短期凭据，并将启动器和响应程序命中的最后32位作为用户名片段。用户名由[RFC5245]第7.1.1.3节中定义的用户名片段构成。32位用户名片段使用小写十六进制ASCII字符表示。不得省略前导零，以便
username's size is fixed (8 characters); for example, if the local HIT is 2001:15:8ebe:1aa7:42f5:b413:7237:6c0a and the remote HIT is 2001:18:46fa:97c0:ba5:cd77:51:47b, the local username would be 72376c0a and the remote username 0051047b.
用户名的大小是固定的（8个字符）；例如，如果本地命中为2001:15:8ebe:1aa7:42f5:b413:7237:6c0a，远程命中为2001:18:46fa:97c0:ba5:cd77:51:47b，则本地用户名为72376c0a，远程用户名为0051047b。
The STUN password is drawn from the Diffie-Hellman (DH) keying material. Drawing of HIP keys is defined in [RFC5201], Section 6.5 and drawing of ESP keys in [RFC5202], Section 7. Correspondingly, the hosts MUST draw symmetric keys for STUN according to [RFC5201], Section 6.5. The hosts draw the STUN key after HIP keys, or after ESP keys if ESP transform was successfully negotiated in the base exchange. Both hosts draw a 128-bit key from the DH keying material, express that in hexadecimal ASCII format using only lowercase letters (resulting in 32 numbers or lowercase letters), and use that as both the local and peer password. [RFC5389] describes how hosts use the password for message integrity of STUN messages.
眩晕密码来自Diffie Hellman（DH）键控材料。[RFC5201]第6.5节和[RFC5202]第7节定义了髋关节键图纸和ESP键图纸。相应地，主机必须根据[RFC5201]第6.5节为STUN绘制对称密钥。主机在髋部关键点之后绘制眩晕关键点，如果在基本交换中成功协商ESP转换，则在ESP关键点之后绘制眩晕关键点。两台主机都从DH keying材质中提取一个128位密钥，以十六进制ASCII格式仅使用小写字母表示（结果是32个数字或小写字母），并将其用作本地密码和对等密码。[RFC5389]描述主机如何使用密码实现STUN消息的消息完整性。
Both the username and password are expressed in ASCII hexadecimal format to prevent the need to run them through SASLPrep as defined in [RFC5389].
用户名和密码均以ASCII十六进制格式表示，以防止需要通过[RFC5389]中定义的SASLPrep运行它们。
The connectivity checks MUST contain the PRIORITY attribute. They MAY contain the USE-CANDIDATE attribute as defined in Section 7.1.1.1 of [RFC5245].
连接检查必须包含优先级属性。它们可能包含[RFC5245]第7.1.1.1节中定义的使用候选属性。
The Initiator is always in the controlling role during a base exchange. When two hosts are initiating a connection to each other simultaneously, the HIP state machine detects it and assigns the host with the larger HIT as the Responder as explained in Sections 4.4.2 and 6.7 in [RFC5201]. Hence, the ICE-CONTROLLED and ICE-CONTROLLING attributes are not needed to resolve role conflicts. However, the attributes SHOULD be added to the connectivity check messages to ensure interoperability with different ICE stacks, and they can be safely ignored on received connectivity checks.
在基本交换期间，启动器始终处于控制角色。当两台主机同时启动彼此的连接时，HIP状态机会检测到该连接，并按照[RFC5201]第4.4.2节和第6.7节中的说明，将具有较大命中率的主机指定为响应者。因此，解决角色冲突不需要ICE-CONTROLED和ICE-CONTROLING属性。但是，应将这些属性添加到连接检查消息中，以确保与不同ICE堆栈的互操作性，并且在收到连接检查时可以安全地忽略这些属性。
The keepalives for HIP associations that are created with ICE are STUN Binding Indications, as defined in [RFC5389]. In contrast to the UDP-encapsulated HIP header, the non-ESP-marker between the UDP header and the STUN header is excluded. Keepalives MUST contain the FINGERPRINT STUN attribute but SHOULD NOT contain any other STUN attributes and SHOULD NOT utilize any authentication mechanism. STUN messages are demultiplexed from ESP and HIP control packets using the STUN markers, such as the magic cookie value and the FINGERPRINT attribute.
根据[RFC5389]中的定义，使用ICE创建的髋部关联的keepalives是眩晕绑定指示。与UDP封装的HIP头不同，UDP头和STUN头之间的非ESP标记被排除。Keepalives必须包含指纹眩晕属性，但不应包含任何其他眩晕属性，并且不应使用任何身份验证机制。使用眩晕标记（如魔法cookie值和指纹属性）将眩晕消息从ESP和HIP控制数据包中分离。
Keepalives for HIP associations created without ICE are HIP control packets that have NOTIFY as the packet type. The keepalive NOTIFY packets do not contain any parameters.
不使用ICE创建的HIP关联的Keepalives是以NOTIFY作为数据包类型的HIP控制数据包。keepalive NOTIFY数据包不包含任何参数。
The format of the NAT_TRAVERSAL_MODE parameter is similar to the format of the ESP_TRANSFORM parameter in [RFC5202] and is shown in Figure 6. This specification defines traversal mode identifiers UDP-ENCAPSULATION and ICE-STUN-UDP. The identifier RESERVED is reserved for future use. Future specifications may define more traversal modes.
NAT_TRAVERSAL_MODE参数的格式类似于[RFC5202]中ESP_TRANSFORM参数的格式，如图6所示。本规范定义了遍历模式标识符UDP-enclosuration和ICE-STUN-UDP。保留的标识符保留供将来使用。未来的规范可能会定义更多的遍历模式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 608 Length length in octets, excluding Type, Length, and padding Reserved zero when sent, ignored when received Mode ID defines the proposed or selected NAT traversal mode(s)
类型608长度以八位字节为单位，不包括类型、长度和填充，发送时保留零，接收时忽略模式ID定义建议或选择的NAT遍历模式
The following NAT traversal mode IDs are defined:
定义了以下NAT穿越模式ID：
ID name Value RESERVED 0 UDP-ENCAPSULATION 1 ICE-STUN-UDP 2
保留的ID名称值0 UDP封装1 ICE-STUN-UDP 2
Figure 6: Format of the NAT_TRAVERSAL_MODE Parameter
图6:NAT_遍历_模式参数的格式
The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE parameter. Conversely, a recipient MUST be prepared to handle received NAT traversal mode parameters that contain more than six Mode IDs by accepting the first six Mode IDs and dropping the rest. The limited number of Mode IDs sets the maximum size of the NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, most preferred mode(s) first.
NAT_TRAVERSAL_MODE参数的发送方必须确保一个NAT_TRAVERSAL_MODE参数中的模式ID不超过六（6）个。相反，接收者必须准备好处理接收到的NAT遍历模式参数，这些参数包含六个以上的模式ID，方法是接受前六个模式ID并删除其余的模式ID。有限数量的模式ID设置NAT_遍历模式参数的最大大小。模式必须按优先顺序排列，优先选择最优先的模式。
The TRANSACTION_PACING parameter shown in Figure 7 contains only the connectivity check pacing value, expressed in milliseconds, as a 32- bit unsigned integer.
图7中显示的TRANSACTION_packing参数仅包含连接检查调整值，以毫秒为单位，表示为32位无符号整数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Ta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Ta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 610 Length 4 Min Ta the minimum connectivity check transaction pacing value the host would use
键入610 Length 4 Min Ta主机将使用的最小连接检查事务调整值
Figure 7: Format of the TRANSACTION_PACING Parameter
图7:TRANSACTION_起搏参数的格式
The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is shown in Figure 8. All parameters are identical except for the type. REG_FROM is the only parameter covered with the signature.
REG_FROM、RELAY_FROM和RELAY_TO参数的格式如图8所示。除类型外，所有参数都相同。REG_FROM是签名包含的唯一参数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type REG_FROM: 950 RELAY_FROM: 63998 RELAY_TO: 64002 Length 20 Port transport port number; zero when plain IP is used Protocol IANA assigned, Internet Protocol number. 17 for UDP, 0 for plain IP
类型REG_FROM:950继电器_FROM:63998继电器_TO:64002长度20端口传输端口号；使用普通IP时为零协议IANA分配，互联网协议编号。17表示UDP，0表示普通IP
Reserved reserved for future use; zero when sent, ignored when received Address an IPv6 address or an IPv4 address in "IPv4-Mapped IPv6 address" format
留作日后使用；发送时为零，接收时忽略IPv6地址或“IPv4映射IPv6地址”格式的IPv4地址
Figure 8: Format of the REG_FROM, RELAY_FROM, and RELAY_TO Parameters
图8:REG_FROM、RELAY_FROM和RELAY_TO参数的格式
REG_FROM contains the transport address and protocol from which the HIP relay server sees the registration coming. RELAY_FROM contains the address from which the relayed packet was received by the relay server and the protocol that was used. RELAY_TO contains the same information about the address to which a packet should be forwarded.
REG_FROM包含HIP中继服务器从中看到注册的传输地址和协议。中继_FROM包含中继服务器从中接收中继数据包的地址以及使用的协议。中继_TO包含关于数据包应转发到的地址的相同信息。
The generic LOCATOR parameter format is the same as in [RFC5206]. However, presenting ICE candidates requires a new locator type. The generic and NAT-traversal-specific locator parameters are illustrated in Figure 9.
通用定位器参数格式与[RFC5206]中的相同。但是，呈现ICE候选对象需要新的定位器类型。通用和NAT遍历特定定位器参数如图9所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Loc Type = 2 | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Port | Transp. Proto| Kind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Loc Type = 2 | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Port | Transp. Proto| Kind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: LOCATOR Parameter
图9：定位器参数
The individual fields in the LOCATOR parameter are described in Table 2.
定位器参数中的各个字段如表2所示。
+-----------+----------+--------------------------------------------+
| Field | Value(s) | Purpose |
+-----------+----------+--------------------------------------------+
| Type | 193 | Parameter type |
| Length | Variable | Length in octets, excluding Type and |
| | | Length fields and padding |
| Traffic | 0-2 | Is the locator for HIP signaling (1), for |
| Type | | ESP (2), or for both (0) |
| Locator | 2 | "Transport address" locator type |
| Type | | |
| Locator | 7 | Length of the fields after Locator |
| Length | | Lifetime in 4-octet units |
| Reserved | 0 | Reserved for future extensions |
| Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the |
| (P) bit | | Responder can use it for the rest of the |
| | | base exchange, otherwise set to zero |
| Locator | Variable | Locator lifetime in seconds |
| Lifetime | | |
| Transport | Variable | Transport layer port number |
| Port | | |
| Transport | Variable | IANA assigned, transport layer Internet |
| Protocol | | Protocol number. Currently only UDP (17) |
| | | is supported. |
| Kind | Variable | 0 for host, 1 for server reflexive, 2 for |
| | | peer reflexive or 3 for relayed address |
| Priority | Variable | Locator's priority as described in |
| | | [RFC5245] |
| SPI | Variable | Security Parameter Index (SPI) value that |
| | | the host expects to see in incoming ESP |
| | | packets that use this locator |
| Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 |
| | | address" format IPv4 address [RFC4291] |
+-----------+----------+--------------------------------------------+
+-----------+----------+--------------------------------------------+
| Field | Value(s) | Purpose |
+-----------+----------+--------------------------------------------+
| Type | 193 | Parameter type |
| Length | Variable | Length in octets, excluding Type and |
| | | Length fields and padding |
| Traffic | 0-2 | Is the locator for HIP signaling (1), for |
| Type | | ESP (2), or for both (0) |
| Locator | 2 | "Transport address" locator type |
| Type | | |
| Locator | 7 | Length of the fields after Locator |
| Length | | Lifetime in 4-octet units |
| Reserved | 0 | Reserved for future extensions |
| Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the |
| (P) bit | | Responder can use it for the rest of the |
| | | base exchange, otherwise set to zero |
| Locator | Variable | Locator lifetime in seconds |
| Lifetime | | |
| Transport | Variable | Transport layer port number |
| Port | | |
| Transport | Variable | IANA assigned, transport layer Internet |
| Protocol | | Protocol number. Currently only UDP (17) |
| | | is supported. |
| Kind | Variable | 0 for host, 1 for server reflexive, 2 for |
| | | peer reflexive or 3 for relayed address |
| Priority | Variable | Locator's priority as described in |
| | | [RFC5245] |
| SPI | Variable | Security Parameter Index (SPI) value that |
| | | the host expects to see in incoming ESP |
| | | packets that use this locator |
| Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 |
| | | address" format IPv4 address [RFC4291] |
+-----------+----------+--------------------------------------------+
Table 2: Fields of the LOCATOR Parameter
表2：定位器参数的字段
The RELAY_HMAC parameter value has the TLV type 65520. It has the same semantics as RVS_HMAC [RFC5204].
继电器HMAC参数值为TLV 65520型。它与RVS_HMAC[RFC5204]具有相同的语义。
The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain Registration Type [RFC5203] values for HIP relay server registration.
REG_INFO、REG_REQ、REG_RESP和REG_FAILED参数包含HIP中继服务器注册的注册类型[RFC5203]值。
The value for RELAY_UDP_HIP is 2.
中继_UDP_HIP的值为2。
A HIP relay server and end-hosts can use NOTIFY packets to signal different error conditions. The new Notify Packet Types [RFC5201] defined in this document are shown below. The Notification Data field for the error notifications SHOULD contain the HIP header of the rejected packet and SHOULD be empty for the CONNECTIVITY_CHECKS_FAILED type.
HIP中继服务器和终端主机可以使用NOTIFY数据包来表示不同的错误情况。本文档中定义的新通知包类型[RFC5201]如下所示。错误通知的通知数据字段应包含被拒绝数据包的HIP头，对于连接检查失败类型，该字段应为空。
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60
没有有效的\u NAT\u遍历\u模式\u参数60
If a HIP relay server does not forward a base exchange packet due to missing NAT traversal mode parameter, or the Initiator selects a NAT traversal mode that the Responder did not expect, the relay or the Responder may send back a NOTIFY error packet with this type.
如果HIP中继服务器由于缺少NAT遍历模式参数而不转发基本交换数据包，或者发起方选择了响应方未预料到的NAT遍历模式，则中继或响应方可以发回此类型的NOTIFY error数据包。
CONNECTIVITY_CHECKS_FAILED 61
连接检查失败61
Used by the end-hosts to signal that NAT traversal connectivity checks failed and did not produce a working path.
由终端主机用来表示NAT遍历连接检查失败且未生成工作路径。
MESSAGE_NOT_RELAYED 62
消息未转发62
Used by a HIP relay server to signal that is was not able or willing to relay a HIP packet.
HIP中继服务器用来表示不能或不愿意中继HIP数据包。
[RFC3948] describes the UDP encapsulation of the IPsec ESP transport and tunnel mode. On the wire, the HIP ESP packets do not differ from the transport mode ESP, and thus the encapsulation of the HIP ESP packets is same as the UDP encapsulation transport mode ESP. However, the (semantic) difference to Bound End-to-End Tunnel (BEET) mode ESP packets used by HIP is that IP header is not used in BEET integrity protection calculation.
[RFC3948]描述IPsec ESP传输和隧道模式的UDP封装。在线路上，HIP ESP数据包与传输模式ESP没有区别，因此HIP ESP数据包的封装与UDP封装传输模式ESP相同。但是，HIP使用的绑定端到端隧道（BEET）模式ESP数据包的（语义）区别在于，在BEET完整性保护计算中未使用IP报头。
During the HIP base exchange, the two peers exchange parameters that enable them to define a pair of IPsec ESP security associations (SAs) as described in [RFC5202]. When two peers perform a UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs that produces UDP-encapsulated ESP data traffic.
在HIP base交换期间，两个对等方交换参数，使它们能够定义一对IPsec ESP安全关联（SA），如[RFC5202]中所述。当两个对等方执行UDP封装的基本交换时，它们必须定义一对IPsec SA，以产生UDP封装的ESP数据流量。
The management of encryption/authentication protocols and SPIs is defined in [RFC5202]. The UDP encapsulation format and processing of HIP ESP traffic is described in Section 6.1 of [RFC5202].
[RFC5202]中定义了加密/认证协议和SPI的管理。[RFC5202]第6.1节描述了HIP ESP流量的UDP封装格式和处理。
The locators are in plain text format in favor of inspection at HIP-aware middleboxes in the future. The current document does not specify encrypted versions of LOCATORs, even though it could be beneficial for privacy reasons to avoid disclosing them to middleboxes.
定位器采用纯文本格式，便于将来在HIP-aware中间盒进行检查。当前的文档没有指定定位器的加密版本，即使出于隐私原因，避免向中间人透露定位器可能是有益的。
It is also possible that end-users may not want to reveal all locators to each other. For example, tracking the physical location of a multihoming end-host may become easier if it reveals all locators to its peer during a base exchange. Also, revealing host addresses exposes information about the local topology that may not be allowed in all corporate environments. For these two reasons, an end-host may exclude certain host addresses from its LOCATOR parameter. However, such behavior creates non-optimal paths when the hosts are located behind the same NAT. Especially, this could be problematic with a legacy NAT that does not support routing from the private address realm back to itself through the outer address of the NAT. This scenario is referred to as the hairpin problem [RFC5128]. With such a legacy NAT, the only option left would be to use a relayed transport address from a TURN server.
最终用户也可能不希望彼此透露所有定位器。例如，如果在基本交换期间向其对等方显示所有定位器，则跟踪多主终端主机的物理位置可能会变得更容易。此外，暴露主机地址会暴露有关本地拓扑的信息，这在所有公司环境中都是不允许的。出于这两个原因，终端主机可能会从其定位器参数中排除某些主机地址。但是，当主机位于同一NAT后面时，这种行为会创建非最佳路径。特别是，如果传统NAT不支持通过NAT的外部地址从私有地址域路由回自身，这可能会有问题。这种情况称为发夹问题[RFC5128]。有了这样一个遗留NAT，剩下的唯一选择就是使用来自TURN服务器的中继传输地址。
The use of HIP relay servers and TURN relays can be also useful for privacy purposes. For example, a privacy concerned Responder may reveal only its HIP relay server and Relayed candidates to Initiators. This same mechanism also protects the Responder against Denial-of-Service (DoS) attacks by allowing the Responder to initiate new connections even if its relays would be unavailable due to a DoS attack.
HIP中继服务器和转向中继的使用也可用于隐私目的。例如，关注隐私的响应者可能只向发起人透露其HIP中继服务器和中继候选对象。该机制还允许响应者启动新连接，即使其中继因DoS攻击而不可用，从而保护响应者免受拒绝服务（DoS）攻击。
A HIP relay server should have one address per relay client when a HIP relay is serving more than one relay client and supports opportunistic mode. Otherwise, it cannot be guaranteed that the HIP relay server can deliver the I1 packet to the intended recipient.
当HIP中继服务于多个中继客户端并支持机会主义模式时，HIP中继服务器应为每个中继客户端提供一个地址。否则，无法保证HIP中继服务器能够将I1数据包交付给预期的接收者。
In certain scenarios, it is possible that an attacker, or two attackers, can replay an earlier base exchange through a HIP relay server by masquerading as the original Initiator and Responder. The attack does not require the attacker(s) to compromise the private key(s) of the attacked host(s). However, for this attack to succeed, the Responder has to be disconnected from the HIP relay server.
在某些情况下，一个或两个攻击者可能伪装成原始发起方和响应方，通过HIP中继服务器重播早期的基本交换。攻击不需要攻击者泄露受攻击主机的私钥。但是，要使此攻击成功，必须断开响应者与HIP中继服务器的连接。
The relay can protect itself against replay attacks by becoming involved in the base exchange by introducing nonces that the end-hosts (Initiator and Responder) are required to sign. One way to do this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as described in [HIP-MIDDLE] and drop the I2 or R2 packets if the corresponding ECHO_RESPONSE_M parameters are not present.
中继可以通过引入终端主机（发起方和响应方）需要签名的nonce来参与基本交换，从而保护自己免受重播攻击。一种方法是将ECHO_请求_M参数添加到R1和I2数据包中，如[HIP-MIDDLE]中所述，如果相应的ECHO_响应_M参数不存在，则丢弃I2或R2数据包。
Section 5.1 of [RFC3948] describes a security issue for the UDP encapsulation in the standard IP tunnel mode when two hosts behind different NATs have the same private IP address and initiate communication to the same Responder in the public Internet. The Responder cannot distinguish between two hosts, because security associations are based on the same inner IP addresses.
[RFC3948]的第5.1节描述了在标准IP隧道模式下，当不同NAT后面的两台主机具有相同的专用IP地址并启动与公共互联网中相同响应程序的通信时，UDP封装的安全问题。响应程序无法区分两台主机，因为安全关联基于相同的内部IP地址。
This issue does not exist with the UDP encapsulation of HIP ESP transport format because the Responder uses HITs to distinguish between different Initiators.
HIP ESP传输格式的UDP封装不存在此问题，因为响应程序使用HITs来区分不同的启动器。
This section is to be interpreted according to [RFC5226].
本节将根据[RFC5226]进行解释。
This document updates the IANA Registry for HIP Parameter Types [RFC5201] by assigning new HIP Parameter Type values for the new HIP Parameters: RELAY_FROM, RELAY_TO, and REG_FROM (defined in Section 5.6), RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING (defined in Section 5.5), and NAT_TRAVERSAL_MODE (defined in Section 5.4).
本文件通过为新髋关节参数分配新髋关节参数类型值来更新IANA髋关节参数类型注册表[RFC5201]：中继起始、中继起始和注册起始（定义见第5.6节）、中继HMAC（定义见第5.8节）、事务起搏（定义见第5.5节）和NAT穿越模式（定义见第5.4节）。
This document defines an additional registration type for the HIP Registration Extension [RFC5203] that allows registering with a HIP relay server for relaying service: RELAY_UDP_HIP (defined in Section 5.9).
本文件为HIP注册扩展[RFC5203]定义了一种额外的注册类型，该注册类型允许向HIP中继服务器注册中继服务：relay_UDP_HIP（在第5.9节中定义）。
This document also defines NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER, CONNECTIVITY_CHECKS_FAILED, and MESSAGE_NOT_RELAYED Notify Packet Types [RFC5201] in Section 5.10.
本文件还在第5.10节中定义了无有效的NAT遍历模式参数、连接检查失败和消息未中继通知包类型[RFC5201]。
The NAT_TRAVERSAL_MODE parameter has 16-bit unsigned integer fields for different modes, for which IANA has created and maintains a new sub-registry entitled "HIP NAT Traversal Modes" under the "Host Identity Protocol (HIP) Parameters". Initial values for the NAT traversal mode registry are given in Section 5.4; future assignments are to be made through IETF Review [RFC5226]. Assignments consist of a NAT traversal mode identifier name and its associated value.
NAT_transversal_MODE参数具有不同模式的16位无符号整数字段，IANA已为这些字段创建并维护了一个新的子注册表，名为“主机标识协议（HIP）参数”下的“HIP NAT transversal modes”。NAT遍历模式注册表的初始值见第5.4节；未来的任务将通过IETF审查[RFC5226]完成。分配由NAT遍历模式标识符名称及其关联值组成。
This RFC is a product of a design team that also included Marcelo Bagnulo and Philip Matthews, who both have made major contributions to this document.
本RFC是一个设计团队的产品，该团队还包括Marcelo Bagnulo和Philip Matthews，他们都对本文件做出了重大贡献。
Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for the excellent work on ICE. In addition, the authors would like to thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, Vivien Schmitt, and Abhinav Pathak for their contributions and Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, and Jani Hautakorpi for their comments on this document.
感谢Jonathan Rosenberg和其他MMUSIC工作组成员在冰上的出色工作。此外，作者还要感谢Andrei Gurtov、Simon Schuetz、Martin Stiemerling、Lars Eggert、Vivien Schmitt和Abhinav Pathak的贡献，以及Tobias Heer、Teemu Koponen、Juhana Mattila、Jeffrey M.Ahrenholz、Kristian Slavov、Janne Lindqvist、Pekka Nikander、Lauri Silvennoinen、Jukka Ylitalo、Juha Heinanen、，Joakim Koskela、Samu Varjonen、Dan Wing和Jani Hautakorpi感谢他们对本文件的评论。
Miika Komu has been working in the Networking Research group at Helsinki Institute for Information Technology (HIIT). The work has been funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence Forces, Ericsson and Birdstep in InfraHIP I and II projects.
Miika Komu一直在赫尔辛基信息技术研究所（HIIT）的网络研究小组工作。这项工作得到了Tekes、Telia Sonera、Elisa、诺基亚、芬兰国防军、爱立信和Birdstep在InfraHIP I和II项目中的资助。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC 4423，2006年5月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202]Jokela，P.，Moskowitz，R.，和P.Nikander，“将封装安全有效载荷（ESP）传输格式与主机标识协议（HIP）结合使用”，RFC 52022008年4月。
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008.
[RFC5203]Laganier，J.，Koponen，T.，和L.Eggert，“主机身份协议（HIP）注册扩展”，RFC 52032008年4月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204]Laganier，J.和L.Eggert，“主机身份协议（HIP）会合扩展”，RFC 52042008年4月。
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Nikander，P.，Henderson，T.，Vogt，C.，和J.Arkko，“使用主机身份协议的终端主机移动性和多宿”，RFC 52062008年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5766] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766]Rosenberg，J.，Mahy，R.，和P.Matthews，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，2010年4月。
[HIP-MIDDLE] Heer, T., Wehrle, K., and M. Komu, "End-Host Authentication for HIP Middleboxes", Work in Progress, February 2009.
[HIP-MIDDLE]Heer，T.，Wehrle，K.，和M.Komu，“HIP MiddleBox的终端主机身份验证”，正在进行的工作，2009年2月。
[MMUSIC-ICE] Rosenberg, J., "Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non Session Initiation Protocol (SIP) Protocols", Work in Progress, July 2008.
[MMUSIC-ICE]Rosenberg，J.，“非会话启动协议（SIP）协议使用交互式连接建立（ICE）的指南”，正在进行的工作，2008年7月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008.
[RFC5128]Srisuresh，P.，Ford，B.，和D.Kegel，“跨网络地址转换器（NAT）的对等（P2P）通信状态”，RFC 51282008年3月。
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008.
[RFC5207]Stieemerling，M.，Quittek，J.，和L.Eggert，“主机身份协议（HIP）通信的NAT和防火墙穿越问题”，RFC 5207，2008年4月。
Selecting a suitable value for the connectivity check transaction pacing is essential for the performance of connectivity check-based NAT traversal. The value should not be so small that the checks cause network congestion or overwhelm the NATs. On the other hand, a pacing value that is too high makes the checks last for a long time, thus increasing the connection setup delay.
为连接检查事务调整选择合适的值对于基于连接检查的NAT遍历的性能至关重要。该值不应太小，以至于检查会导致网络拥塞或覆盖NAT。另一方面，调宽值过高会使检查持续很长时间，从而增加连接设置延迟。
The Ta value may be configured by the user in environments where the network characteristics are known beforehand. However, if the characteristics are not known, it is recommended that the value is adjusted dynamically. In this case, it's recommended that the hosts estimate the round-trip time (RTT) between them and set the minimum Ta value so that only two connectivity check messages are sent on every RTT.
Ta值可由用户在网络特性事先已知的环境中配置。但是，如果特性未知，建议动态调整该值。在这种情况下，建议主机估计它们之间的往返时间（RTT），并设置最小Ta值，以便在每个RTT上只发送两条连接检查消息。
One way to estimate the RTT is to use the time it takes for the HIP relay server registration exchange to complete; this would give an estimate on the registering host's access link's RTT. Also, the I1/R1 exchange could be used for estimating the RTT, but since the R1 can be cached in the network, or the relaying service can increase the delay notably, it is not recommended.
估计RTT的一种方法是使用HIP中继服务器注册交换完成所需的时间；这将估计注册主机的访问链路的RTT。此外，I1/R1交换可用于估计RTT，但由于R1可缓存在网络中，或者中继服务可显著增加延迟，因此不推荐使用。
When the Initiator looks up the information of the Responder from DNS, it's possible that it discovers a rendezvous server (RVS) record [RFC5204]. In this case, if the Initiator uses NAT traversal methods described in this document, it MAY use its own HIP relay server to forward HIP traffic to the rendezvous server. The Initiator will send the I1 packet using its HIP relay server, which will then forward it to the RVS server of the Responder. In this case, the value of the protocol field in the RELAY_TO parameter MUST be IP since RVS does not support UDP-encapsulated base exchange packets. The Responder will send the R1 packet directly to the Initiator's HIP relay server and the following I2 and R2 packets are also sent directly using the relay.
当发起者从DNS中查找响应者的信息时，它可能会发现会合服务器（RVS）记录[RFC5204]。在这种情况下，如果启动器使用本文档中描述的NAT遍历方法，则它可以使用自己的HIP中继服务器将HIP流量转发到集合服务器。发起方将使用其HIP中继服务器发送I1数据包，然后将其转发到响应方的RVS服务器。在这种情况下，RELAY_TO参数中的protocol字段的值必须是IP，因为RVS不支持UDP封装的基本交换数据包。响应者将直接将R1数据包发送到启动器的HIP中继服务器，并使用中继直接发送以下I2和R2数据包。
In case the Initiator is not able to distinguish which records are RVS address records and which are Responder's address records (e.g., if the DNS server did not support HIP extensions), the Initiator SHOULD first try to contact the Responder directly, without using a HIP relay server. If none of the addresses are reachable, it MAY try them out using its own HIP relay server as described above.
如果发起者无法区分哪些记录是RVS地址记录，哪些记录是响应者的地址记录（例如，如果DNS服务器不支持HIP扩展），发起者应首先尝试直接联系响应者，而不使用HIP中继服务器。如果没有一个地址是可访问的，它可以使用上面描述的自己的HIP中继服务器来尝试它们。
Authors' Addresses
作者地址
Miika Komu
Helsinki Institute for Information Technology
Metsanneidonkuja 4
Espoo
Finland
Phone: +358503841531
Fax: +35896949768
EMail: miika@iki.fi
URI: http://www.hiit.fi/
Miika Komu
Helsinki Institute for Information Technology
Metsanneidonkuja 4
Espoo
Finland
Phone: +358503841531
Fax: +35896949768
EMail: miika@iki.fi
URI: http://www.hiit.fi/
Thomas Henderson The Boeing Company P.O. Box 3707 Seattle, WA USA EMail: thomas.r.henderson@boeing.com
Thomas Henderson波音公司美国华盛顿州西雅图3707信箱电子邮件：Thomas.r。henderson@boeing.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at/
Hannes Tschofenig诺基亚西门子网络Linnoitustie 6 Espoo 02600芬兰电话：+358（50）4871445电子邮件：Hannes。Tschofenig@gmx.netURI:http://www.tschofenig.priv.at/
Jan Melen Ericsson Research Nomadiclab Hirsalantie 11 02420 Jorvas Finland Phone: +358 9 2991 EMail: jan.melen@ericsson.com
Jan Melen Ericsson Research Nomadiclab Hirsalantie 11 02420 Jorvas Finland电话：+358 9 2991电子邮件：Jan。melen@ericsson.com
Ari Keranen (editor) Ericsson Research Nomadiclab Hirsalantie 11 02420 Jorvas Finland Phone: +358 9 2991 EMail: ari.keranen@ericsson.com
Ari Keranen（编辑）爱立信研究实验室Hirsalantie 11 02420 Jorvas Finland电话：+358 9 2991电子邮件：Ari。keranen@ericsson.com