Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 6078 J. Melen
Category: Experimental Ericsson
ISSN: 2070-1721 January 2011
Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 6078 J. Melen
Category: Experimental Ericsson
ISSN: 2070-1721 January 2011
Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)
主机标识协议（HIP）上层协议信令的即时传输（HICCup）
Abstract
摘要
This document defines a new Host Identity Protocol (HIP) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks.
本文档定义了一种称为数据的新主机标识协议（HIP）数据包类型。HIP数据包用于在各种覆盖网络上可靠地传输经过身份验证的任意协议消息。
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/rfc6078.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6078.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message Formats . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. HIP Fixed Header . . . . . . . . . . . . . . . . . . . 4
3.1.2. HIP Parameter Format . . . . . . . . . . . . . . . . . 5
3.2. HIP Base Exchange, Updates, and State Removal . . . . . . 5
4. Definition of the HIP_DATA Packet . . . . . . . . . . . . . . 6
4.1. Definition of the SEQ_DATA Parameter . . . . . . . . . . . 8
4.2. Definition of the ACK_DATA Parameter . . . . . . . . . . . 8
4.3. Definition of the PAYLOAD_MIC Parameter . . . . . . . . . 9
4.4. Definition of the TRANSACTION_ID Parameter . . . . . . . . 10
5. Generation and Reception of HIP_DATA Packets . . . . . . . . . 10
5.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 10
5.2. Generation of a HIP_DATA Packet . . . . . . . . . . . . . 11
5.3. Reception of a HIP_DATA Packet . . . . . . . . . . . . . . 12
5.3.1. Handling of SEQ_DATA in a Received HIP_DATA Packet . . 13
5.3.2. Handling of ACK_DATA in a Received HIP_DATA Packet . . 14
6. Use of the HIP_DATA Packet . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative references . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message Formats . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. HIP Fixed Header . . . . . . . . . . . . . . . . . . . 4
3.1.2. HIP Parameter Format . . . . . . . . . . . . . . . . . 5
3.2. HIP Base Exchange, Updates, and State Removal . . . . . . 5
4. Definition of the HIP_DATA Packet . . . . . . . . . . . . . . 6
4.1. Definition of the SEQ_DATA Parameter . . . . . . . . . . . 8
4.2. Definition of the ACK_DATA Parameter . . . . . . . . . . . 8
4.3. Definition of the PAYLOAD_MIC Parameter . . . . . . . . . 9
4.4. Definition of the TRANSACTION_ID Parameter . . . . . . . . 10
5. Generation and Reception of HIP_DATA Packets . . . . . . . . . 10
5.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 10
5.2. Generation of a HIP_DATA Packet . . . . . . . . . . . . . 11
5.3. Reception of a HIP_DATA Packet . . . . . . . . . . . . . . 12
5.3.1. Handling of SEQ_DATA in a Received HIP_DATA Packet . . 13
5.3.2. Handling of ACK_DATA in a Received HIP_DATA Packet . . 14
6. Use of the HIP_DATA Packet . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative references . . . . . . . . . . . . . . . . . . 16
Two hosts can use HIP [RFC5201] to establish a security association (SA) between them in order to exchange arbitrary protocol messages over that security association. The establishment of such a security association involves a four-way handshake referred to as the HIP base exchange. When handling communications between the hosts, HIP supports mobility, multihoming, security, and NAT traversal. Some applications require these features for their communications but cannot accept the overhead involved in establishing a security association (i.e., the HIP base exchange) before those communications can start.
两台主机可以使用HIP[RFC5201]在它们之间建立安全关联（SA），以便通过该安全关联交换任意协议消息。建立这样一个安全协会涉及一种称为髋关节基底交换的四方握手。在处理主机之间的通信时，HIP支持移动性、多址、安全性和NAT穿越。某些应用程序的通信需要这些功能，但无法接受在这些通信开始之前建立安全关联（即HIP-base exchange）所涉及的开销。
In this document, we define the HIP DATA packet, which can be used to convey (in a authenticated and reliable way) protocol messages to a remote host without running the HIP base exchange. The HIP_DATA packet has the following semantics: unordered, duplicate free, reliable, and authenticated message-based delivery service. We also discuss the trade-offs involved in using this packet (i.e., less overhead but also less denial-of-service (DoS) protection) and the situations where it is appropriate to use this packet. The HIP_DATA packet is not intended to be a replacement for the Encapsulating Security Payload (ESP) transport; instead, it SHOULD NOT be used to exchange more than a few packets between peers. If a continuous communication is required or communication that requires confidentiality protection then hosts MUST run the HIP base exchange to set up an ESP security association. Additionally, APIs to higher-level protocols that might use this service are outside of the scope of this document.
在本文档中，我们定义了HIP数据包，该数据包可用于（以经过身份验证且可靠的方式）向远程主机传输协议消息，而无需运行HIP基交换。HIP_数据包具有以下语义：无序、无重复、可靠且经过验证的基于消息的交付服务。我们还讨论了使用此数据包所涉及的权衡（即，开销较小，但拒绝服务（DoS）保护也较少）以及使用此数据包的适当情况。HIP_数据包不打算替代封装安全有效载荷（ESP）传输；相反，它不应用于在对等方之间交换超过几个数据包。如果需要连续通信或需要保密保护的通信，则主机必须运行HIP-base exchange以建立ESP安全关联。此外，可能使用此服务的高级协议的API不在本文档的范围内。
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]. In addition, this document uses the terms defined in [RFC5201].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。此外，本文件使用[RFC5201]中定义的术语。
Message Integrity Code (MIC) is a collision-resistant hash sum calculated over the message that is being integrity protected. The MIC does not use secret keys, and thus it needs additional means to ensure that it has not been tampered with during transmission. Essentially, the MIC is same as the Message Authentication Code (MAC) with the distinction that the MIC does not use secret keys. The MIC is also often referred as the Integrity Check Value (ICV), fingerprint, or unkeyed MAC.
消息完整性代码（MIC）是在受完整性保护的消息上计算的抗冲突哈希和。麦克风不使用密钥，因此需要额外的方法来确保它在传输过程中未被篡改。本质上，MIC与消息身份验证码（MAC）相同，区别在于MIC不使用密钥。麦克风通常也被称为完整性检查值（ICV）、指纹或无眼MAC。
The HIP specification [RFC5201] defines a number of messages and parameters. The parameters are encoded as TLVs, as shown in Section 3.1.2. Furthermore, the HIP header carries a Next Header field, allowing other arbitrary packets to be carried within HIP packets.
HIP规范[RFC5201]定义了许多消息和参数。参数编码为TLV，如第3.1.2节所示。此外，HIP报头携带下一报头字段，允许在HIP分组内携带其他任意分组。
The HIP packet format consists of a fixed header followed by a variable number of parameters. The parameter format is described in Section 3.1.2.
HIP数据包格式由固定的报头和可变数量的参数组成。参数格式见第3.1.2节。
The fixed header is defined in Section 5.1 of [RFC5201] and copied below.
固定标题在[RFC5201]第5.1节中定义，并复制如下。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Length |0| Packet Type | VER. | RES.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Controls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ HIP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Length |0| Packet Type | VER. | RES.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Controls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ HIP Parameters /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The HIP header is logically an IPv6 extension header. The HIP specification [RFC5201] defines handling only for Next Header value decimal 59, IPv6-NoNxt [PROTOCOL-NUMBERS], the IPv6 'no next header' value. This document describes processing for Next Header values other than decimal 59, which indicates that there are either more extension headers and/or data following the HIP header.
HIP标头在逻辑上是IPv6扩展标头。HIP规范[RFC5201]仅定义了下一个标头值十进制59、IPv6 NoNxt[协议编号]、IPv6“无下一个标头”值的处理。本文档描述了除十进制59之外的下一个标题值的处理，这表明HIP标题后面有更多扩展标题和/或数据。
The HIP parameter format is defined in Section 5.2.1 of [RFC5201], and copied below.
HIP参数格式在[RFC5201]第5.2.1节中定义，并复制如下。
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 |C| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Contents /
/ +-+-+-+-+-+-+-+-+
| | 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 |C| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Contents /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type code for the parameter. 16 bits long, C-bit being part of the Type code. C Critical. One if this parameter is critical, and MUST be recognized by the recipient; zero otherwise. The C bit is considered to be a part of the Type field. Consequently, critical parameters are always odd and non-critical ones have an even value. Length Length of the Contents, in octets. Contents Parameter specific, defined by Type. Padding Padding, 0-7 octets, added if needed.
输入参数的类型代码。16位长，C位是类型代码的一部分。C至关重要。如果此参数是关键参数，并且必须由收件人识别，则为一个参数；否则为零。C位被视为类型字段的一部分。因此，临界参数总是奇数，而非临界参数的值是偶数。内容的长度，以八位字节为单位。特定于参数的内容，由类型定义。填充，0-7个八位字节，必要时添加。
The HIP base exchange is a four-message authentication and key exchange protocol that creates shared, mutually authenticated keying material at the communicating parties. These keying materials, together with associated public keys and IP addresses, form a HIP security association (SA). The details of the protocol are defined in the HIP base exchange specification [RFC5201].
HIP base exchange是一个四消息身份验证和密钥交换协议，它在通信各方创建共享的、相互验证的密钥材料。这些密钥材料，连同相关的公钥和IP地址，组成了HIP安全协会（SA）。协议的详细信息在HIP基站交换规范[RFC5201]中定义。
In addition to creating the HIP SA, the base exchange messages may carry additional parameters that are used to create additional state. For example, the HIP ESP specification [RFC5202] defines how HIP can be used to create end-to-end, host-to-host IPsec ESP security associations, used to carry data packets. However, it is important to understand that the HIP base exchange is by no means bound to IPsec; using IPsec ESP to carry data traffic forms just a baseline and ensures interoperability between initial HIP implementations.
除了创建HIP SA之外，基本交换消息还可以携带用于创建附加状态的附加参数。例如，HIP ESP规范[RFC5202]定义了如何使用HIP创建端到端、主机到主机的IPsec ESP安全关联，用于传输数据包。但是，重要的是要了解HIP-base交换绝不受IPsec的约束；使用IPsec ESP承载数据流量只是一个基线，可以确保初始HIP实现之间的互操作性。
Once there is a HIP SA between two HIP-enabled hosts, they can exchange further HIP control messages. Typically, UPDATE messages are used. For example, the HIP mobility and multihoming specification [RFC5206] defines how to use UPDATE messages to change the set of IP addresses associated with a HIP SA.
一旦两个支持HIP的主机之间存在HIP SA，它们就可以进一步交换HIP控制消息。通常使用更新消息。例如，HIP移动和多宿规范[RFC5206]定义了如何使用更新消息来更改与HIP SA相关联的IP地址集。
In addition to the base exchange and updates, the HIP base protocol specification also defines how one can remove a HIP SA once it is no longer needed.
除了基本交换和更新之外，HIP基本协议规范还定义了在不再需要HIP SA时如何删除它。
The HIP DATA packet can be used to convey protocol messages to a remote host without running the HIP base exchange. HIP DATA packets are transmitted reliably, as discussed in Section 5. The payload of a HIP_DATA packet is placed after the HIP header and protected by a PAYLOAD_MIC parameter, which is defined in Section 4.3. The following is the definition of the HIP_DATA packet (see the definition of notation in [RFC5201], Section 2.2):
HIP数据包可用于将协议消息传送到远程主机，而无需运行HIP基本交换。HIP数据包可靠传输，如第5节所述。HIP_数据包的有效载荷置于HIP报头之后，并由第4.3节中定义的有效载荷_MIC参数进行保护。以下是HIP_数据包的定义（参见[RFC5201]第2.2节中的符号定义）：
Header: Packet Type = 32 SRC HIT = Sender's HIT DST HIT = Receiver's HIT
报头：数据包类型=32 SRC HIT=发送方的HIT DST HIT=接收方的HIT
IP ( HIP ( [HOST_ID, ] SEQ_DATA, PAYLOAD_MIC, [ PAYLOAD_MIC, ..., ] HIP_SIGNATURE) PAYLOAD )
IP（HIP（[主机ID，]序列数据，有效负载麦克风，[有效负载麦克风，…]HIP签名）有效负载）
IP ( HIP ( [HOST_ID, ] SEQ_DATA, ACK_DATA, PAYLOAD_MIC, [ PAYLOAD_MIC, ..., ] HIP_SIGNATURE) PAYLOAD )
IP（HIP（[主机ID，]序列数据，确认数据，有效载荷麦克风，[有效载荷麦克风，…]HIP签名）有效载荷）
IP ( HIP ( [HOST_ID, ] ACK_DATA, HIP_SIGNATURE))
IP（HIP（[主机ID，]确认数据，HIP签名））
The SEQ_DATA and ACK_DATA parameters are defined in Sections 4.1 and 4.2, respectively. They are used to provide a reliable delivery of HIP_DATA packets, as discussed in Section 5.
SEQ_数据和ACK_数据参数分别在第4.1节和第4.2节中定义。它们用于提供HIP_数据包的可靠传输，如第5节所述。
The HOST_ID parameter is defined in Section 5.2.8 of [RFC5201]. This parameter is the sender's Host Identifier that is used to compute the HIP_DATA packet's signature and to verify it against the received signature. The HOST_ID parameter is optional as it MAY have been delivered using out-of-band mechanism to the receiver. If the host doesn't have reliable information that the corresponding node has its HOST_ID, it MUST always include the HOST_ID in the packet. If the receiver is unable to verify the SIGNATURE, then the packet MUST be dropped and the appropriate NOTIFY packet SHOULD be sent to the sender indicating AUTHENTICATION_FAILED as described in [RFC5201], Section 5.2.16.
[RFC5201]第5.2.8节定义了主机ID参数。此参数是发送方的主机标识符，用于计算HIP_数据包的签名，并根据接收到的签名进行验证。HOST_ID参数是可选的，因为它可能是使用带外机制传送到接收器的。如果主机没有相应节点具有其主机ID的可靠信息，则它必须始终在数据包中包含主机ID。如果接收方无法验证签名，则必须丢弃数据包，并向发送方发送适当的通知数据包，表明认证失败，如[RFC5201]第5.2.16节所述。
The PAYLOAD_MIC parameter is defined in Section 4.3. This parameter contains the MIC of the payload carried by the HIP_DATA packet. The PAYLOAD_MIC contains the collision-resistant hash of the payload following the HIP DATA. The PAYLOAD_MIC is included in the signed part of the HIP DATA packet and gives integrity protection for the packet as well as the payload carried after it.
有效载荷参数在第4.3节中定义。此参数包含HIP_数据包所承载有效载荷的MIC。有效载荷MIC包含HIP数据后有效载荷的防碰撞散列。有效载荷包括在HIP数据包的签名部分中，并为数据包及其后携带的有效载荷提供完整性保护。
The HIP_SIGNATURE parameter is defined in Section 5.2.11 of [RFC5201]. It contains a signature over the contents of the HIP_DATA packet. The calculation and verification of the signature is defined in Section 6.4.2. of [RFC5201].
[RFC5201]第5.2.11节定义了HIP_签名参数。它包含HIP_数据包内容的签名。第6.4.2节规定了签名的计算和验证。属于[RFC5201]。
Section 5.3 of [RFC5201] states the following:
[RFC5201]第5.3节规定如下：
In the future, an OPTIONAL upper-layer payload MAY follow the HIP header. The Next Header field in the header indicates if there is additional data following the HIP header.
将来，可选的上层有效载荷可能会跟随HIP收割台。标题中的下一个标题字段指示髋部标题后是否有其他数据。
We have chosen to place the payload after the HIP extension header and only to place a MIC of the payload into the HIP extension header in a PAYLOAD_MIC parameter because that way the data integrity is protected by a public key signature with the help of the MIC. The payload that is protected by the PAYLOAD_MIC parameter has been linked to the appropriate upper-layer protocol by storing the upper-layer protocol number, 8 octets of payload data, and by calculating a hash sum (MIC) over the data. The HIP_DATA packet MAY contain one or more PAYLOAD_MIC parameters, each bound to a different Next Header type. The hash algorithm used to generate the MIC is the same as the algorithm used to generate the Host Identity Tag [RFC5201].
我们选择将有效载荷放置在HIP extension标头之后，并且仅将有效载荷的MIC放置在payload_MIC参数中的HIP extension标头中，因为这样，数据完整性在MIC的帮助下由公钥签名保护。通过存储上层协议编号、8个八位字节的有效负载数据，并通过计算数据上的哈希和（MIC），受有效负载参数保护的有效负载已链接到适当的上层协议。HIP_数据分组可以包含一个或多个有效载荷MIC参数，每个参数绑定到不同的下一报头类型。用于生成MIC的哈希算法与用于生成主机标识标签的算法相同[RFC5201]。
Upper-layer protocol messages, such as overlay network control traffic, sent in HIP DATA messages may need to be matched to different transactions. For this purpose, a DATA message MAY also contain a TRANSACTION_ID parameter. The identifier value is a variable length bit string in network byte order that is unique for each transaction. A response to a request uses the same identifier value, thereby allowing the receiver to match requests to responses.
在HIP数据消息中发送的上层协议消息（如覆盖网络控制流量）可能需要与不同的事务相匹配。为此，数据消息还可以包含事务ID参数。标识符值是网络字节顺序的可变长度位字符串，对于每个事务都是唯一的。对请求的响应使用相同的标识符值，从而允许接收方将请求与响应相匹配。
The following is the definition of the SEQ_DATA parameter:
以下是SEQ_数据参数的定义：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4481 Length 4 Sequence number 32-bit unsigned integer in network byte order that MUST NOT be reused before it has been acknowledged by the receiver.
键入4481 Length 4序列号32位无符号整数，按网络字节顺序排列，在接收器确认之前不得重复使用。
This parameter has the critical bit set. If it is not supported by the receiver, the packet MUST be dropped and the appropriate NOTIFY packet SHOULD be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE as described in [RFC5201], Section 5.2.16.
此参数设置了关键位。如果接收方不支持，则必须丢弃数据包，并向发送方发送适当的通知数据包，指示不支持的\u关键\u参数\u类型，如[RFC5201]第5.2.16节所述。
The following is the definition of the ACK_DATA parameter:
以下是ACK_数据参数的定义：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acked Sequence number /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acked Sequence number /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4545 Length variable (multiple of 4) Acked Sequence number A sequence of 32-bit unsigned integers in network byte order corresponding to the sequence numbers being acknowledged.
类型4545长度变量（4的倍数）确认序列号32位无符号整数的序列，按网络字节顺序排列，对应于被确认的序列号。
This parameter has the critical bit set. If it is not supported by the receiver, the packet MUST be dropped and the appropriate NOTIFY packet SHOULD be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE as described in [RFC5201], Section 5.2.16.
此参数设置了关键位。如果接收方不支持，则必须丢弃数据包，并向发送方发送适当的通知数据包，指示不支持的\u关键\u参数\u类型，如[RFC5201]第5.2.16节所述。
The following is the definition of the PAYLOAD_MIC parameter:
以下是有效载荷参数的定义：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ MIC Value /
/ +-+-+-+-+-+-+-+-+
| | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ MIC Value /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4577 Length Length in octets, excluding Type, Length, and Padding. Next Header Identifies the data that is protected by this MIC. The values for this field are defined by IANA "Protocol Numbers" [PROTOCOL-NUMBERS]. Payload Data Last 8 octets of the payload data over which the MIC is calculated. This field is used to uniquely bind the PAYLOAD_MIC parameter to the Next Header, in case there are multiple copies of the same type. MIC Value MIC computed over the data to which the Next Header and Payload Data point. The size of the MIC is the natural size of the computation output depending on the function used.
键入4577长度八位字节，不包括类型、长度和填充。下一个标题标识受此麦克风保护的数据。此字段的值由IANA“协议编号”[协议编号]定义。有效载荷数据计算MIC的有效载荷数据的最后8个八位字节。如果存在相同类型的多个副本，此字段用于将PAYLOAD_MIC参数唯一绑定到下一个标头。MIC值MIC在下一个报头和有效负载数据指向的数据上计算得出。麦克风的大小是计算输出的自然大小，取决于所使用的函数。
This parameter has the critical bit set. If it is not supported by the receiver, the packet MUST be dropped and the appropriate NOTIFY packet SHOULD be sent to the sender indicating UNSUPPORTED_CRITICAL_PARAMETER_TYPE as described in [RFC5201], Section 5.2.16.
此参数设置了关键位。如果接收方不支持，则必须丢弃数据包，并向发送方发送适当的通知数据包，指示不支持的\u关键\u参数\u类型，如[RFC5201]第5.2.16节所述。
There is a theoretical possibility that when generating multiple PAYLOAD_MIC parameters that will be carried in a single packet, they would have identical Next Header and Payload Data fields; thus, it is required that PAYLOAD_MIC parameters MUST follow the natural order of extension headers in the packet so that it's possible to bind PAYLOAD_MICs to correct payload data. In case the receiving host is still unable to identify the payloads, it MUST drop the packet and
理论上，当生成将在单个分组中携带的多个有效载荷参数时，它们可能具有相同的下一报头和有效载荷数据字段；因此，要求有效负载MIC参数必须遵循数据包中扩展头的自然顺序，以便能够将有效负载MIC绑定到正确的有效负载数据。如果接收主机仍然无法识别有效负载，则必须丢弃数据包并
SHOULD send a NOTIFY packet to the sender indicating INVALID_SYNTAX as described in [RFC5201], Section 5.2.16.
应按照[RFC5201]第5.2.16节所述，向发送方发送一个通知数据包，指示无效的_语法。
The following is the definition of the TRANSACTION_ID parameter:
以下是事务_ID参数的定义：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4580 Length Length of the Identifier, in octets Identifier The identifier value Padding 0-7 octets of padding if needed
键入4580长度标识符的长度，以八位字节标识符表示标识符值，如果需要，填充0-7个八位字节
Figure 1
图1
HIP_DATA packets are transmitted reliably. Reliable delivery is achieved through the use of retransmissions and of the SEQ_DATA and ACK_DATA parameters.
HIP_数据包可靠传输。通过使用重传以及SEQ_数据和ACK_数据参数实现可靠的传输。
A HIP_DATA packet MUST contain at least one of a SEQ_DATA or an ACK_DATA parameter; if both parameters are missing, then packet MUST be dropped as invalid.
HIP_数据包必须包含SEQ_数据或ACK_数据参数中的至少一个；若两个参数都丢失，那个么数据包必须作为无效数据包丢弃。
A HIP_DATA packet containing a SEQ_DATA parameter MUST contain one or more PAYLOAD_MIC parameters; otherwise, the packet MUST be dropped. The presence of a SEQ_DATA parameter indicates that the receiver MUST ACK the HIP_DATA packet. A HIP_DATA packet that does not contain a SEQ_DATA parameter is simply an ACK of a previous HIP_DATA packet, and it MUST NOT be ACKed.
包含SEQ_数据参数的HIP_数据包必须包含一个或多个PAYLOAD_MIC参数；否则，必须丢弃数据包。SEQ_数据参数的存在表示接收器必须确认HIP_数据包。不包含SEQ_数据参数的HIP_数据包只是前一个HIP_数据包的ACK，不能对其进行ACK。
A HIP_DATA packet containing an ACK_DATA parameter echoes the SEQ_DATA sequence numbers of the HIP_DATA packets being acknowledged. The ACK_DATA parameter MUST acknowledge at least one SEQ_DATA sequence number and MAY acknowledge multiple SEQ_DATA sequence numbers by adding all of them to the ACK_DATA parameter.
包含ACK_数据参数的HIP_数据包回显正在确认的HIP_数据包的SEQ_数据序列号。ACK_数据参数必须确认至少一个SEQ_数据序列号，并且可以通过将所有SEQ_数据序列号添加到ACK_数据参数来确认多个SEQ_数据序列号。
A HIP_DATA packet MAY contain both a SEQ_DATA and an ACK_DATA parameter. In this case, the ACK is being piggybacked on an outgoing HIP_DATA packet. In general, HIP_DATA packets carrying SEQ_DATA SHOULD be ACKed upon completion of the processing of the HIP_DATA packet. A host MAY choose to hold the HIP DATA packet carrying an ACK for a short period of time to allow for the possibility of piggybacking the ACK_DATA parameter, in a manner similar to TCP delayed acknowledgments.
HIP_数据分组可以同时包含SEQ_数据和ACK_数据参数。在这种情况下，ACK被携带在传出的HIP_数据包上。一般来说，承载SEQ_数据的HIP_数据包应在HIP_数据包处理完成后进行确认。主机可以选择将携带ACK的HIP数据分组保持短时间，以允许以类似于TCP延迟确认的方式携带ACK_数据参数的可能性。
When a host has upper-layer protocol data to send, it either runs the HIP base exchange and sends the data over a SA, or sends the data directly using a HIP_DATA packet. Section 6 discusses when it is appropriate to use each method. This section discusses the case when the host chooses to use a HIP_DATA packet to send the upper-layer protocol data.
当主机有上层协议数据要发送时，它要么运行HIP base exchange并通过SA发送数据，要么直接使用HIP_数据包发送数据。第6节讨论何时适合使用每种方法。本节讨论主机选择使用HIP_数据包发送上层协议数据的情况。
1. The host creates a HIP_DATA packet that contains a SEQ_DATA parameter. The host is free to choose any value for the SEQ_DATA sequence number in the first HIP_DATA packet it sends to a destination. After that first packet, the host MUST choose the value of the SEQ_DATA sequence number in subsequent HIP_DATA packets to the same destination so that no SEQ_DATA sequence number is reused before the receiver has closed the processing window for the previous packet using the same SEQ_DATA sequence number. Practically, giving the values of the retransmission timers used with HIP_DATA packets, this means that hosts must wait the maximum likely lifetime of the packet before reusing a given SEQ_DATA sequence number towards a given destination. However, it is not required for the node to know the maximum packet lifetime. Rather, it is assumed that the requirement can be met by maintaining the value as a simple, 32-bit, "wrap-around" counter, incremented each time a packet is sent. It is an implementation choice whether to maintain a single counter for the node or multiple counters (one for each <source, destination> HIT pair).
1. 主机创建包含SEQ_数据参数的HIP_数据包。主机可以自由选择发送到目的地的第一个HIP_数据包中的SEQ_数据序列号的任何值。在第一个数据包之后，主机必须在到同一目的地的后续HIP_数据包中选择SEQ_数据序列号的值，以便在接收器关闭使用相同SEQ_数据序列号的前一个数据包的处理窗口之前，不会重用SEQ_数据序列号。实际上，给定与HIP_数据包一起使用的重传定时器的值，这意味着主机必须等待数据包的最长可能生存期，然后才能向给定目的地重用给定的SEQ_数据序列号。然而，节点不需要知道最大数据包生存期。相反，假设可以通过将该值保持为一个简单的32位“环绕”计数器（每次发送数据包时递增）来满足要求。是为节点维护单个计数器还是多个计数器（每个<source，destination>命中对一个计数器），这是一个实现选择。
2. The host creates the PAYLOAD_MIC parameter. The MIC is a hash calculated over the whole PAYLOAD that the Next Header field of the PAYLOAD_MIC parameter indicates. If there are multiple Next Header types that the host wants to protect, it SHOULD create separate PAYLOAD_MIC parameters for each of these. The receiver MUST validate all these MICs as described in Section 5.3.1. For calculating the MIC, the host MUST use the same hash algorithm as the one that has been used for generating the host's HIT as defined in Section 3.2. of [RFC5201].
2. 主机创建PAYLOAD_MIC参数。MIC是在整个有效载荷上计算的散列，有效载荷参数的下一个报头字段指示该散列。如果主机想要保护多个Next头类型，它应该为每个类型创建单独的有效负载参数。接收器必须按照第5.3.1节所述验证所有这些话筒。为了计算MIC，主机必须使用与第3.2节中定义的用于生成主机命中的哈希算法相同的哈希算法。属于[RFC5201]。
3. The host creates the HIP_SIGNATURE parameter. The signature is calculated over the whole HIP envelope, excluding any parameters after the HIP_SIGNATURE, as defined in Section 5.2.11. of [RFC5201]. The receiver MUST validate this signature. It MAY use either the HI in the packet or the HI acquired by some other means.
3. 主机创建HIP_签名参数。根据第5.2.11节的定义，在整个HIP包络上计算签名，不包括HIP_签名后的任何参数。属于[RFC5201]。接收方必须验证此签名。它可以使用分组中的HI或者通过某些其他方式获取的HI。
4. The host sends the created HIP_DATA packet and starts a DATA timer. The default value for the timer is 3 seconds. If multiple HIP DATA packets are outstanding, multiple timers are in effect.
4. 主机发送创建的HIP_数据包并启动数据计时器。计时器的默认值为3秒。如果多个HIP数据包未完成，则多个计时器有效。
5. If the DATA timer expires, the HIP_DATA packet is resent. The HIP DATA packet can be resent DATA_RETRY_MAX times. The DATA timer MUST be exponentially backed off for subsequent retransmissions. If no acknowledgment is received from the peer after DATA_RETRY_MAX times, the delivery of the HIP_DATA packet is considered unsuccessful and the application is notified about the error. The DATA timer is canceled upon receiving an ACK from the peer that acknowledges receipt of the HIP_DATA packet. The default value for DATA_RETRY_MAX SHOULD be 5 retries, but it MAY be changed through local policy.
5. 如果数据计时器过期，则重新发送HIP_数据包。HIP数据包最多可重新发送数据\u重试\u次。数据计时器必须以指数方式后退，以便后续重新传输。如果在数据重试\u最大次数后未收到来自对等方的确认，则认为HIP\u数据包的传递不成功，并将错误通知应用程序。当从确认接收到HIP_数据包的对等方接收到ACK时，数据计时器被取消。DATA_RETRY_MAX的默认值应为5次重试，但可以通过本地策略进行更改。
A host receiving a HIP_DATA packet makes a decision whether or not to process the packet. If the host, following its local policy, suspects that this packet could be part of a DoS attack. The host MAY respond with an R1 packet to the HIP_DATA packet, if the packet contained SEQ_DATA and PAYLOAD_MIC parameters, in order to indicate that HIP base exchange MUST be completed before accepting payload packets from the originator of the HIP_DATA packet.
接收HIP_数据包的主机决定是否处理该数据包。如果主机根据其本地策略怀疑此数据包可能是DoS攻击的一部分。如果数据包包含SEQ_数据和有效载荷MIC参数，则主机可以用R1数据包响应HIP_数据包，以指示在接受来自HIP_数据包的发起方的有效载荷数据包之前必须完成HIP基站交换。
From RFC 5201 (Section 4.1):
根据RFC 5201（第4.1节）：
The HIP base exchange serves to manage the establishment of state between an Initiator and a Responder. The first packet, I1, initiates the exchange, and the last three packets, R1, I2, and R2, constitute an authenticated Diffie-Hellman [DIF76] key exchange for session key generation.
HIP-base交换用于管理发起方和响应方之间状态的建立。第一个数据包I1启动交换，最后三个数据包R1、I2和R2构成用于会话密钥生成的经过身份验证的Diffie-Hellman[DIF76]密钥交换。
If the host chooses to respond to the HIP DATA with an R1 packet, it creates a new R1 or selects a precomputed R1 according to the format described in [RFC5201], Section 5.3.2. The host SHOULD drop the received data packet if it responded with an R1 packet to the HIP_DATA packet. The sender of HIP_DATA packet is responsible for retransmission of the upper-layer protocol data after successful completion of the HIP base exchange.
如果主机选择使用R1数据包响应HIP数据，则会根据[RFC5201]第5.3.2节所述格式创建新R1或选择预计算R1。如果主机以R1数据包响应HIP_数据包，则应丢弃接收到的数据包。HIP_数据包的发送方负责在成功完成HIP基址交换后重新传输上层协议数据。
If the host, following its local policy, decides to process the incoming HIP_DATA packet, it processes the packet according to the following rules:
如果主机根据其本地策略决定处理传入的HIP_数据包，则它将根据以下规则处理该数据包：
1. If the HIP_DATA packet contains a SEQ_DATA parameter and no ACK_DATA parameter, the HIP_DATA packet is processed and replied to as described in Section 5.3.1.
1. 如果HIP_数据包包含一个SEQ_数据参数而没有ACK_数据参数，则按照第5.3.1节的说明处理和回复HIP_数据包。
2. If the HIP_DATA packet contains an ACK_DATA parameter and no SEQ_DATA parameter, the HIP_DATA packet is processed as described in Section 5.3.2.
2. 如果HIP_数据包包含ACK_数据参数和no SEQ_数据参数，则按照第5.3.2节所述处理HIP_数据包。
3. If the HIP_DATA packet contains both a SEQ_DATA parameter and an ACK_DATA parameter, the HIP_DATA packet is processed first as described in Section 5.3.2, and then the rest of the HIP_DATA packet is processed and replied to as described in Section 5.3.1.
3. 如果HIP_数据包包含SEQ_数据参数和ACK_数据参数，则首先按照第5.3.2节所述处理HIP_数据包，然后按照第5.3.1节所述处理和回复HIP_数据包的其余部分。
The following steps define the conceptual processing rules for handling a SEQ_DATA parameter in a received HIP_DATA packet.
以下步骤定义了处理接收的HIP_数据包中的SEQ_数据参数的概念处理规则。
The system MUST verify the SIGNATURE in the HIP_DATA packet. If the verification fails, the packet SHOULD be dropped and an error message logged.
系统必须验证HIP_数据包中的签名。如果验证失败，则应丢弃数据包并记录错误消息。
If the value in the received SEQ_DATA and the MIC value in the received PAYLOAD_MIC correspond to a HIP_DATA packet that has recently been processed, the packet is treated as a retransmission. It is recommended that a host cache HIP_DATA packets with ACKs to avoid the cost of generating a new ACK packet to respond to a retransmitted HIP_DATA packet. The host MUST acknowledge, again, such (apparent) HIP_DATA packet retransmissions but SHOULD also consider rate-limiting such retransmission responses to guard against replay attacks.
如果接收到的SEQ_数据中的值和接收到的有效载荷_MIC中的MIC值对应于最近处理过的HIP_数据分组，则该分组被视为重传。建议主机缓存具有ACK的HIP_数据包，以避免生成新ACK包以响应重新传输的HIP_数据包的成本。主机必须再次确认这样的（明显的）HIPX数据包重传，但也应该考虑速率限制这样的重传响应以防止重放攻击。
The system MUST verify the PAYLOAD_MIC by calculating the MIC over the PAYLOAD that the Next Header field indicates. For calculating the MIC, the host will use the same hash algorithm that has been used to generate the sender's HIT as defined in Section 3.2. of [RFC5201]. If the packet carried multiple PAYLOAD_MIC parameters, each of them are verified as described above. If one or more of the verifications fail, the packet SHOULD be dropped and an error message logged.
系统必须通过计算下一报头字段指示的有效载荷上的MIC来验证有效载荷\u MIC。为了计算MIC，主机将使用第3.2节中定义的用于生成发送方命中的相同哈希算法。属于[RFC5201]。如果分组携带多个有效载荷参数，则如上所述验证每个有效载荷参数。如果一个或多个验证失败，则应丢弃数据包并记录错误消息。
If a new SEQ parameter is being processed, the parameters in the HIP DATA packet are then processed.
如果正在处理一个新的SEQ参数，则处理HIP数据包中的参数。
A HIP_DATA packet with an ACK_DATA parameter is prepared and sent to the peer. This ACK_DATA parameter may be included in a separate HIP DATA packet or piggybacked in a HIP_DATA packet with a SEQ_DATA parameter. The ACK_DATA parameter MAY acknowledge more than one of the peer's HIP_DATA packets.
准备带有ACK_数据参数的HIP_数据包并发送给对等方。该ACK_数据参数可以包括在单独的HIP数据分组中，或者携带在具有SEQ_数据参数的HIP_数据分组中。ACK_数据参数可以确认对等方的多个HIP_数据分组。
The following steps define the conceptual processing rules for handling an ACK_DATA parameter in a received HIP_DATA packet.
以下步骤定义了处理接收的HIP_数据包中的ACK_数据参数的概念处理规则。
The system MUST verify the SIGNATURE in the HIP_DATA packet. If the verification fails, the packet SHOULD be dropped and an error message logged.
系统必须验证HIP_数据包中的签名。如果验证失败，则应丢弃数据包并记录错误消息。
The sequence numbers reported in the ACK_DATA must match with a previously sent HIP_DATA packet containing SEQ_DATA that has not already been acknowledged. If no match is found or if the ACK_DATA does not acknowledge a new HIP_DATA packet, the packet either MUST be dropped if no SEQ_DATA parameter is present or the processing steps in Section 5.3.1 are followed.
ACK_数据中报告的序列号必须与先前发送的HIP_数据包相匹配，该数据包包含尚未确认的SEQ_数据。如果未找到匹配项，或者如果ACK_数据未确认新的HIP_数据包，则如果不存在SEQ_数据参数或遵循第5.3.1节中的处理步骤，则必须丢弃该数据包。
The corresponding DATA timer is stopped so that the now acknowledged HIP_DATA packet is no longer retransmitted. If multiple HIP_DATA packets are newly acknowledged, multiple timers are stopped.
相应的数据计时器停止，以便不再重新传输现在已确认的HIP_数据包。如果新确认了多个HIP_数据包，则停止多个计时器。
HIP currently requires that the four-message base exchange is executed at the first encounter of hosts that have not communicated before. This may add additional RTTs (Round-Trip Times) to protocols based on a single message exchange. However, the four-message exchange is essential to preserve the DoS protection nature of the base exchange. The use of the HIP_DATA packet defined in this document reduces the initial overhead in the communications between two hosts. However, the HIP_DATA packet itself does not provide any protection against DoS attacks. Therefore, the HIP_DATA packet MUST only be used in environments whose policies provide protection against DoS attacks. For example, a HIP-based overlay may have policies in place to control which nodes can join the overlay. However, authorization of who is allowed to join the overlay is beyond the scope of this specification. Any particular node in the overlay may want to accept HIP_DATA packets from other nodes in the overlay, given that those other nodes were authorized to join the overlay. However, the same node will not accept HIP_DATA packets from random nodes that are not part of the overlay. Additionally, the HIP_DATA packet itself does not provide confidentiality for its payload. Therefore, the HIP_DATA packet MUST NOT be used in
HIP目前要求在第一次遇到以前未通信的主机时执行四消息基交换。这可能会在基于单个消息交换的协议中添加额外的RTT（往返时间）。但是，四消息交换对于保持基本交换的DoS保护性质至关重要。本文档中定义的HIP_数据包的使用减少了两台主机之间通信的初始开销。但是，HIP_数据包本身不提供任何防止DoS攻击的保护。因此，HIP_数据包只能在其策略提供DoS攻击保护的环境中使用。例如，基于HIP的覆盖可能具有适当的策略来控制哪些节点可以加入覆盖。但是，允许谁加入覆盖的授权超出了本规范的范围。覆盖中的任何特定节点可能希望接受来自覆盖中其他节点的HIP_数据包，前提是这些其他节点被授权加入覆盖。但是，同一节点将不接受来自不属于覆盖的随机节点的HIP_数据包。此外，HIP_数据包本身不为其有效负载提供机密性。因此，HIP_数据包不得用于
environments that do not provide an appropriate level of confidentiality (e.g., a HIP-based overlay MUST NOT send HIP_DATA packets unless the connections between overlay nodes are encrypted).
未提供适当保密级别的环境（例如，基于HIP的覆盖不得发送HIP_数据包，除非覆盖节点之间的连接已加密）。
The type of data to be sent is also relevant to whether the use of a HIP_DATA packet is appropriate. HIP itself does not support fragmentation but relies on underlying IP-layer fragmentation. This may lead to reliability problems in the case where a message cannot be easily split over multiple HIP messages. Therefore, applications in environments where fragmentation could be an issue SHOULD NOT generate large HIP_DATA packets that may lead to fragmentation. The implementation SHOULD check the MTU of the link before sending the packet, and if the packet size is larger than MTU, it SHOULD signal to the upper-layer protocol if the packet results in an ICMP error message. Note that there are environments where fragmentation is not an issue. For example, in some HIP-based overlays, nodes can exchange HIP_DATA packets on top of TCP connections that provide transport-level fragmentation and, thus, avoid IP-level fragmentation.
要发送的数据类型也与HIP_数据包的使用是否合适有关。HIP本身不支持分段，但依赖于底层IP层分段。如果一条消息无法轻松拆分为多条HIP消息，这可能会导致可靠性问题。因此，在可能存在碎片问题的环境中，应用程序不应生成可能导致碎片的大型HIP_数据包。在发送数据包之前，实现应检查链路的MTU，如果数据包大小大于MTU，则如果数据包导致ICMP错误消息，则应向上层协议发送信号。请注意，有些环境中不存在碎片问题。例如，在一些基于HIP的覆盖中，节点可以在提供传输级碎片的TCP连接上交换HIP_数据包，从而避免IP级碎片。
HIP currently requires that all messages excluding I1s but including HIP_DATA packets are digitally signed. This adds to the packet size and the processing capacity needed to send packets. However, in applications where security is not paramount, it is possible to use very short keys, thereby reducing resource consumption.
HIP目前要求所有不包括I1s但包括HIP_数据包的消息都进行数字签名。这增加了发送数据包所需的数据包大小和处理能力。但是，在安全性不重要的应用程序中，可以使用非常短的密钥，从而减少资源消耗。
HIP is designed to provide secure authentication of hosts. HIP also attempts to limit the exposure of the host to various denial-of-service and man-in-the-middle (MitM) attacks. However, HIP_DATA packet, which can be sent without running the HIP base exchange between hosts has a trade-off that it does not provide the denial-of-service protection or confidentiality protection that HIP generally provides. Thus, the host should consider always situations where it is appropriate to send or receive HIP_DATA packet. If the communication consists more than few round trips of data or the data is highly sensitive in nature the host SHOULD run the base exchange with the peer host.
HIP旨在提供主机的安全身份验证。HIP还试图限制主机受到各种拒绝服务和中间人（MitM）攻击。但是，HIP_数据包可以在不运行主机之间的HIP-base交换的情况下发送，它有一个折衷，即它不提供HIP通常提供的拒绝服务保护或机密性保护。因此，主机应该总是考虑发送或接收HIPHO数据包的情况。如果通信包含多个数据往返，或者数据本质上高度敏感，则主机应与对等主机运行基本交换。
HIP_DATA packet is designed to protect hosts from second preimage attacks allowing receiving host to be able to detect, if the message was tampered during the transport. This property is also know as "weak collision-resistance". If a host tries to generate a second preimage, it would need to generate it such that the last 8 octets match with the original message.
HIP_数据包旨在保护主机免受第二个前映像攻击，从而使接收主机能够检测消息在传输过程中是否被篡改。这种特性也称为“弱抗碰撞性”。如果主机试图生成第二个前映像，则需要生成该前映像，以便最后8个八位字节与原始消息匹配。
When handling the PAYLOAD_MIC parameter in the receiving host, using the last 8 octets to identify the upper-layer protocol doesn't give any guarantee that the MIC would be correct; thus, an attacker could send packets where the next header and last 8 octets match the values carried by the PAYLOAD_MIC parameter. Therefore, it is always mandatory to verify the MIC value by calculating the hash over the payload.
在接收主机中处理PAYLOAD_MIC参数时，使用最后8个八位字节来识别上层协议并不能保证MIC是正确的；因此，攻击者可以发送数据包，其中下一个报头和最后8个八位字节与PAYLOAD_MIC参数携带的值相匹配。因此，始终必须通过计算有效负载上的散列来验证MIC值。
This document updates the IANA registry for HIP packet types by introducing a new packet type for the HIP_DATA (Section 4) packet. This document updates the IANA registry for HIP parameter types by introducing new parameter values for the SEQ_DATA (Section 4.1), ACK_DATA (Section 4.2), PAYLOAD_MIC (Section 4.3), and TRANSACTION_ID (Section 4.4) parameters.
本文件通过为HIP_数据包（第4节）引入一种新的数据包类型来更新IANA注册中心的HIP数据包类型。本文件通过引入SEQ_数据（第4.1节）、ACK_数据（第4.2节）、PAYLOAD_MIC（第4.3节）和TRANSACTION_ID（第4.4节）参数的新参数值来更新IANA注册中心的HIP参数类型。
Pekka Nikander was one of the original authors of the document. Also, in the usual IETF fashion, a large number of people have contributed to the actual text or ideas. The list of these people include Miika Komu, Tobias Heer, Ari Keranen, Samu Varjonen, Thomas Henderson, and Jukka Ylitalo. Our apologies to anyone whose name is missing.
Pekka Nikander是该文件的原始作者之一。此外，在通常的IETF方式中，大量的人对实际的文本或想法做出了贡献。这些人包括Miika Komu、Tobias Heer、Ari Keranen、Samu Varjonen、Thomas Henderson和Jukka Ylitalo。我们向任何姓名丢失的人道歉。
[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月。
[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月。
[PROTOCOL-NUMBERS] IANA, "Protocol Numbers", <http://www.iana.org>.
[协议编号]IANA，“协议编号”<http://www.iana.org>.
[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月。
[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月。
Authors' Addresses
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Jan Melen Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jan Melen Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Jan.Melen@ericsson.com
EMail: Jan.Melen@ericsson.com