Internet Engineering Task Force (IETF) R. Moskowitz, Ed.
Request for Comments: 7401 HTT Consulting
Obsoletes: 5201 T. Heer
Category: Standards Track Hirschmann Automation and Control
ISSN: 2070-1721 P. Jokela
Ericsson Research NomadicLab
T. Henderson
University of Washington
April 2015
Internet Engineering Task Force (IETF) R. Moskowitz, Ed.
Request for Comments: 7401 HTT Consulting
Obsoletes: 5201 T. Heer
Category: Standards Track Hirschmann Automation and Control
ISSN: 2070-1721 P. Jokela
Ericsson Research NomadicLab
T. Henderson
University of Washington
April 2015
Host Identity Protocol Version 2 (HIPv2)
主机标识协议版本2（HIPv2）
Abstract
摘要
This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP.
本文档规定了主机标识协议（HIP）的详细信息。HIP允许同意的主机安全地建立和维护共享IP层状态，允许分离IP地址的标识符和定位器角色，从而实现跨IP地址更改的通信连续性。HIP基于Diffie-Hellman密钥交换，使用来自新主机标识命名空间的公钥标识符进行相互对等身份验证。该协议旨在抵抗拒绝服务（DoS）和中间人（MitM）攻击。当与其他合适的安全协议（如封装安全负载（ESP））一起使用时，它为上层协议（如TCP和UDP）提供完整性保护和可选加密。
This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.
本文件淘汰了RFC 5201，并解决了IESG提出的问题，尤其是加密灵活性问题。它还结合了从RFC 5201的实施中吸取的经验教训。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc7401.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7401.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 ....................................................5
1.1. A New Namespace and Identifiers ............................6
1.2. The HIP Base Exchange (BEX) ................................6
1.3. Memo Structure .............................................7
2. Terms and Definitions ...........................................7
2.1. Requirements Terminology ...................................7
2.2. Notation ...................................................8
2.3. Definitions ................................................8
3. Host Identity (HI) and Its Structure ............................9
3.1. Host Identity Tag (HIT) ...................................10
3.2. Generating a HIT from an HI ...............................11
4. Protocol Overview ..............................................12
4.1. Creating a HIP Association ................................12
4.1.1. HIP Puzzle Mechanism ...............................14
4.1.2. Puzzle Exchange ....................................15
4.1.3. Authenticated Diffie-Hellman Protocol with
DH Group Negotiation ...............................17
4.1.4. HIP Replay Protection ..............................18
4.1.5. Refusing a HIP Base Exchange .......................19
4.1.6. Aborting a HIP Base Exchange .......................20
4.1.7. HIP Downgrade Protection ...........................20
4.1.8. HIP Opportunistic Mode .............................21
4.2. Updating a HIP Association ................................24
4.3. Error Processing ..........................................24
4.4. HIP State Machine .........................................25
4.4.1. State Machine Terminology ..........................26
4.4.2. HIP States .........................................27
4.4.3. HIP State Processes ................................28
4.4.4. Simplified HIP State Diagram .......................35
1. Introduction ....................................................5
1.1. A New Namespace and Identifiers ............................6
1.2. The HIP Base Exchange (BEX) ................................6
1.3. Memo Structure .............................................7
2. Terms and Definitions ...........................................7
2.1. Requirements Terminology ...................................7
2.2. Notation ...................................................8
2.3. Definitions ................................................8
3. Host Identity (HI) and Its Structure ............................9
3.1. Host Identity Tag (HIT) ...................................10
3.2. Generating a HIT from an HI ...............................11
4. Protocol Overview ..............................................12
4.1. Creating a HIP Association ................................12
4.1.1. HIP Puzzle Mechanism ...............................14
4.1.2. Puzzle Exchange ....................................15
4.1.3. Authenticated Diffie-Hellman Protocol with
DH Group Negotiation ...............................17
4.1.4. HIP Replay Protection ..............................18
4.1.5. Refusing a HIP Base Exchange .......................19
4.1.6. Aborting a HIP Base Exchange .......................20
4.1.7. HIP Downgrade Protection ...........................20
4.1.8. HIP Opportunistic Mode .............................21
4.2. Updating a HIP Association ................................24
4.3. Error Processing ..........................................24
4.4. HIP State Machine .........................................25
4.4.1. State Machine Terminology ..........................26
4.4.2. HIP States .........................................27
4.4.3. HIP State Processes ................................28
4.4.4. Simplified HIP State Diagram .......................35
4.5. User Data Considerations ..................................37
4.5.1. TCP and UDP Pseudo Header Computation for
User Data ..........................................37
4.5.2. Sending Data on HIP Packets ........................37
4.5.3. Transport Formats ..................................37
4.5.4. Reboot, Timeout, and Restart of HIP ................37
4.6. Certificate Distribution ..................................38
5. Packet Formats .................................................38
5.1. Payload Format ............................................38
5.1.1. Checksum ...........................................40
5.1.2. HIP Controls .......................................40
5.1.3. HIP Fragmentation Support ..........................40
5.2. HIP Parameters ............................................41
5.2.1. TLV Format .........................................44
5.2.2. Defining New Parameters ............................46
5.2.3. R1_COUNTER .........................................47
5.2.4. PUZZLE .............................................48
5.2.5. SOLUTION ...........................................49
5.2.6. DH_GROUP_LIST ......................................50
5.2.7. DIFFIE_HELLMAN .....................................51
5.2.8. HIP_CIPHER .........................................52
5.2.9. HOST_ID ............................................54
5.2.10. HIT_SUITE_LIST ....................................56
5.2.11. TRANSPORT_FORMAT_LIST .............................58
5.2.12. HIP_MAC ...........................................59
5.2.13. HIP_MAC_2 .........................................59
5.2.14. HIP_SIGNATURE .....................................60
5.2.15. HIP_SIGNATURE_2 ...................................61
5.2.16. SEQ ...............................................61
5.2.17. ACK ...............................................62
5.2.18. ENCRYPTED .........................................62
5.2.19. NOTIFICATION ......................................64
5.2.20. ECHO_REQUEST_SIGNED ...............................67
5.2.21. ECHO_REQUEST_UNSIGNED .............................68
5.2.22. ECHO_RESPONSE_SIGNED ..............................69
5.2.23. ECHO_RESPONSE_UNSIGNED ............................69
5.3. HIP Packets ...............................................70
5.3.1. I1 - the HIP Initiator Packet ......................71
5.3.2. R1 - the HIP Responder Packet ......................72
5.3.3. I2 - the Second HIP Initiator Packet ...............75
5.3.4. R2 - the Second HIP Responder Packet ...............76
5.3.5. UPDATE - the HIP Update Packet .....................77
5.3.6. NOTIFY - the HIP Notify Packet .....................78
5.3.7. CLOSE - the HIP Association Closing Packet .........78
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet ..79
4.5. User Data Considerations ..................................37
4.5.1. TCP and UDP Pseudo Header Computation for
User Data ..........................................37
4.5.2. Sending Data on HIP Packets ........................37
4.5.3. Transport Formats ..................................37
4.5.4. Reboot, Timeout, and Restart of HIP ................37
4.6. Certificate Distribution ..................................38
5. Packet Formats .................................................38
5.1. Payload Format ............................................38
5.1.1. Checksum ...........................................40
5.1.2. HIP Controls .......................................40
5.1.3. HIP Fragmentation Support ..........................40
5.2. HIP Parameters ............................................41
5.2.1. TLV Format .........................................44
5.2.2. Defining New Parameters ............................46
5.2.3. R1_COUNTER .........................................47
5.2.4. PUZZLE .............................................48
5.2.5. SOLUTION ...........................................49
5.2.6. DH_GROUP_LIST ......................................50
5.2.7. DIFFIE_HELLMAN .....................................51
5.2.8. HIP_CIPHER .........................................52
5.2.9. HOST_ID ............................................54
5.2.10. HIT_SUITE_LIST ....................................56
5.2.11. TRANSPORT_FORMAT_LIST .............................58
5.2.12. HIP_MAC ...........................................59
5.2.13. HIP_MAC_2 .........................................59
5.2.14. HIP_SIGNATURE .....................................60
5.2.15. HIP_SIGNATURE_2 ...................................61
5.2.16. SEQ ...............................................61
5.2.17. ACK ...............................................62
5.2.18. ENCRYPTED .........................................62
5.2.19. NOTIFICATION ......................................64
5.2.20. ECHO_REQUEST_SIGNED ...............................67
5.2.21. ECHO_REQUEST_UNSIGNED .............................68
5.2.22. ECHO_RESPONSE_SIGNED ..............................69
5.2.23. ECHO_RESPONSE_UNSIGNED ............................69
5.3. HIP Packets ...............................................70
5.3.1. I1 - the HIP Initiator Packet ......................71
5.3.2. R1 - the HIP Responder Packet ......................72
5.3.3. I2 - the Second HIP Initiator Packet ...............75
5.3.4. R2 - the Second HIP Responder Packet ...............76
5.3.5. UPDATE - the HIP Update Packet .....................77
5.3.6. NOTIFY - the HIP Notify Packet .....................78
5.3.7. CLOSE - the HIP Association Closing Packet .........78
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet ..79
5.4. ICMP Messages .............................................79
5.4.1. Invalid Version ....................................79
5.4.2. Other Problems with the HIP Header and
Packet Structure ...................................80
5.4.3. Invalid Puzzle Solution ............................80
5.4.4. Non-existing HIP Association .......................80
6. Packet Processing ..............................................80
6.1. Processing Outgoing Application Data ......................81
6.2. Processing Incoming Application Data ......................82
6.3. Solving the Puzzle ........................................83
6.4. HIP_MAC and SIGNATURE Calculation and Verification ........84
6.4.1. HMAC Calculation ...................................84
6.4.2. Signature Calculation ..............................87
6.5. HIP KEYMAT Generation .....................................89
6.6. Initiation of a HIP Base Exchange .........................90
6.6.1. Sending Multiple I1 Packets in Parallel ............91
6.6.2. Processing Incoming ICMP Protocol
Unreachable Messages ...............................92
6.7. Processing of Incoming I1 Packets .........................92
6.7.1. R1 Management ......................................94
6.7.2. Handling of Malformed Messages .....................94
6.8. Processing of Incoming R1 Packets .........................94
6.8.1. Handling of Malformed Messages .....................97
6.9. Processing of Incoming I2 Packets .........................97
6.9.1. Handling of Malformed Messages ....................100
6.10. Processing of Incoming R2 Packets .......................101
6.11. Sending UPDATE Packets ..................................101
6.12. Receiving UPDATE Packets ................................102
6.12.1. Handling a SEQ Parameter in a Received
UPDATE Message ...................................103
6.12.2. Handling an ACK Parameter in a Received
UPDATE Packet ....................................104
6.13. Processing of NOTIFY Packets ............................104
6.14. Processing of CLOSE Packets .............................105
6.15. Processing of CLOSE_ACK Packets .........................105
6.16. Handling State Loss .....................................105
7. HIP Policies ..................................................106
8. Security Considerations .......................................106
9. IANA Considerations ...........................................109
10. Differences from RFC 5201 ....................................113
11. References ...................................................117
11.1. Normative References ....................................117
11.2. Informative References ..................................119
Appendix A. Using Responder Puzzles ..............................122
Appendix B. Generating a Public Key Encoding from an HI ..........123
5.4. ICMP Messages .............................................79
5.4.1. Invalid Version ....................................79
5.4.2. Other Problems with the HIP Header and
Packet Structure ...................................80
5.4.3. Invalid Puzzle Solution ............................80
5.4.4. Non-existing HIP Association .......................80
6. Packet Processing ..............................................80
6.1. Processing Outgoing Application Data ......................81
6.2. Processing Incoming Application Data ......................82
6.3. Solving the Puzzle ........................................83
6.4. HIP_MAC and SIGNATURE Calculation and Verification ........84
6.4.1. HMAC Calculation ...................................84
6.4.2. Signature Calculation ..............................87
6.5. HIP KEYMAT Generation .....................................89
6.6. Initiation of a HIP Base Exchange .........................90
6.6.1. Sending Multiple I1 Packets in Parallel ............91
6.6.2. Processing Incoming ICMP Protocol
Unreachable Messages ...............................92
6.7. Processing of Incoming I1 Packets .........................92
6.7.1. R1 Management ......................................94
6.7.2. Handling of Malformed Messages .....................94
6.8. Processing of Incoming R1 Packets .........................94
6.8.1. Handling of Malformed Messages .....................97
6.9. Processing of Incoming I2 Packets .........................97
6.9.1. Handling of Malformed Messages ....................100
6.10. Processing of Incoming R2 Packets .......................101
6.11. Sending UPDATE Packets ..................................101
6.12. Receiving UPDATE Packets ................................102
6.12.1. Handling a SEQ Parameter in a Received
UPDATE Message ...................................103
6.12.2. Handling an ACK Parameter in a Received
UPDATE Packet ....................................104
6.13. Processing of NOTIFY Packets ............................104
6.14. Processing of CLOSE Packets .............................105
6.15. Processing of CLOSE_ACK Packets .........................105
6.16. Handling State Loss .....................................105
7. HIP Policies ..................................................106
8. Security Considerations .......................................106
9. IANA Considerations ...........................................109
10. Differences from RFC 5201 ....................................113
11. References ...................................................117
11.1. Normative References ....................................117
11.2. Informative References ..................................119
Appendix A. Using Responder Puzzles ..............................122
Appendix B. Generating a Public Key Encoding from an HI ..........123
Appendix C. Example Checksums for HIP Packets ....................123
C.1. IPv6 HIP Example (I1 Packet) ..............................124
C.2. IPv4 HIP Packet (I1 Packet) ...............................124
C.3. TCP Segment ...............................................125
Appendix D. ECDH and ECDSA 160-Bit Groups ........................125
Appendix E. HIT Suites and HIT Generation ........................125
Acknowledgments ..................................................127
Authors' Addresses ...............................................128
Appendix C. Example Checksums for HIP Packets ....................123
C.1. IPv6 HIP Example (I1 Packet) ..............................124
C.2. IPv4 HIP Packet (I1 Packet) ...............................124
C.3. TCP Segment ...............................................125
Appendix D. ECDH and ECDSA 160-Bit Groups ........................125
Appendix E. HIT Suites and HIT Generation ........................125
Acknowledgments ..................................................127
Authors' Addresses ...............................................128
This document specifies the details of the Host Identity Protocol (HIP). A high-level description of the protocol and the underlying architectural thinking is available in the separate HIP architecture description [HIP-ARCH]. Briefly, the HIP architecture proposes an alternative to the dual use of IP addresses as "locators" (routing labels) and "identifiers" (endpoint, or host, identifiers). In HIP, public cryptographic keys, of a public/private key pair, are used as host identifiers, to which higher-layer protocols are bound instead of an IP address. By using public keys (and their representations) as host identifiers, dynamic changes to IP address sets can be directly authenticated between hosts, and if desired, strong authentication between hosts at the TCP/IP stack level can be obtained.
本文档规定了主机标识协议（HIP）的详细信息。单独的HIP架构描述[HIP-ARCH]中提供了协议和基础架构思想的高级描述。简单地说，HIP体系结构提出了一种替代方案，可以将IP地址双重用作“定位器”（路由标签）和“标识符”（端点或主机标识符）。在HIP中，公钥/私钥对的公钥用作主机标识符，上层协议绑定到主机标识符，而不是IP地址。通过使用公钥（及其表示）作为主机标识符，可以在主机之间直接对IP地址集的动态更改进行身份验证，如果需要，还可以在TCP/IP堆栈级别获得主机之间的强身份验证。
This memo specifies the base HIP protocol ("base exchange") used between hosts to establish an IP-layer communications context, called a HIP association, prior to communications. It also defines a packet format and procedures for updating and terminating an active HIP association. Other elements of the HIP architecture are specified in other documents, such as:
此备忘录指定主机之间用于在通信之前建立IP层通信上下文（称为HIP关联）的基本HIP协议（“基本交换”）。它还定义了用于更新和终止活动HIP关联的数据包格式和过程。HIP体系结构的其他元素在其他文件中有规定，例如：
o "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)" [RFC7402]: how to use the Encapsulating Security Payload (ESP) for integrity protection and optional encryption
o “将封装安全有效负载（ESP）传输格式与主机标识协议（HIP）一起使用”[RFC7402]：如何使用封装安全有效负载（ESP）进行完整性保护和可选加密
o "Host Mobility with the Host Identity Protocol" [HIP-HOST-MOB]: how to support host mobility in HIP
o “主机身份协议下的主机移动性”[HIP-Host-MOB]：如何支持HIP中的主机移动性
o "Host Identity Protocol (HIP) Domain Name System (DNS) Extension" [HIP-DNS-EXT]: how to extend DNS to contain Host Identity information
o “主机标识协议（HIP）域名系统（DNS）扩展”[HIP-DNS-EXT]：如何扩展DNS以包含主机标识信息
o "Host Identity Protocol (HIP) Rendezvous Extension" [HIP-REND-EXT]: using a rendezvous mechanism to contact mobile HIP hosts
o “主机标识协议（HIP）会合扩展”[HIP-REND-EXT]：使用会合机制联系移动HIP主机
Since the HIP base exchange was first developed, there have been a few advances in cryptography and attacks against cryptographic systems. As a result, all cryptographic protocols need to be agile. That is, the ability to switch from one cryptographic primitive to another should be a part of such protocols. It is important to support a reasonable set of mainstream algorithms to cater to different use cases and allow moving away from algorithms that are later discovered to be vulnerable. This update to the base exchange includes this needed cryptographic agility while addressing the downgrade attacks that such flexibility introduces. In addition, Elliptic Curve support via Elliptic Curve DSA (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH) has been added.
自从HIP-base exchange首次开发以来，密码技术和针对密码系统的攻击都取得了一些进展。因此，所有加密协议都需要灵活。也就是说，从一个加密原语切换到另一个加密原语的能力应该是此类协议的一部分。重要的是支持一组合理的主流算法，以满足不同的用例，并允许远离后来发现易受攻击的算法。对基本exchange的此更新包括了这种所需的加密灵活性，同时解决了这种灵活性带来的降级攻击。此外，还添加了通过椭圆曲线DSA（ECDSA）和椭圆曲线Diffie-Hellman（ECDH）的椭圆曲线支持。
The Host Identity Protocol introduces a new namespace, the Host Identity namespace. Some ramifications of this new namespace are explained in the HIP architecture description [HIP-ARCH].
主机标识协议引入了一个新的名称空间，即主机标识名称空间。这个新名称空间的一些分支在HIP体系结构描述[HIP-ARCH]中进行了解释。
There are two main representations of the Host Identity, the full Host Identity (HI) and the Host Identity Tag (HIT). The HI is a public key and directly represents the Identity of a host. Since there are different public key algorithms that can be used with different key lengths, the HI, as such, is unsuitable for use as a packet identifier, or as an index into the various state-related implementation structures needed to support HIP. Consequently, a hash of the HI, the Host Identity Tag (HIT), is used as the operational representation. The HIT is 128 bits long and is used in the HIP headers and to index the corresponding state in the end hosts. The HIT has an important security property in that it is self-certifying (see Section 3).
主机标识有两种主要表示形式：完整主机标识（HI）和主机标识标记（HIT）。HI是一个公钥，直接表示主机的身份。由于存在可用于不同密钥长度的不同公钥算法，因此HI不适合用作分组标识符，或用作支持HIP所需的各种状态相关实现结构的索引。因此，HI的散列（主机标识标签（HIT））被用作操作表示。HIT的长度为128位，用于HIP头中，并对终端主机中的相应状态进行索引。HIT有一个重要的安全属性，因为它是自认证的（参见第3节）。
The HIP base exchange is a two-party cryptographic protocol used to establish communications context between hosts. The base exchange is a SIGMA-compliant [KRA03] four-packet exchange. The first party is called the Initiator and the second party the Responder. The protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd packets, and authenticates the parties in the 3rd and 4th packets. The four-packet design helps to make HIP resistant to DoS attacks. It allows the Responder to stay stateless until the IP address and the cryptographic puzzle are verified. The Responder starts the puzzle exchange in the 2nd packet, with the Initiator completing it in the 3rd packet before the Responder stores any state from the exchange.
HIP base exchange是一种用于在主机之间建立通信上下文的双方加密协议。基本交换是符合SIGMA的[KRA03]四包交换。第一方称为发起方，第二方称为响应方。该协议交换第2和第3个数据包中的Diffie-Hellman[DIF76]密钥，并对第3和第4个数据包中的各方进行身份验证。四包设计有助于使HIP抵抗拒绝服务攻击。它允许响应者保持无状态，直到验证IP地址和密码谜题。响应者在第二个数据包中启动谜题交换，在响应者存储来自交换的任何状态之前，启动器在第三个数据包中完成谜题交换。
The exchange can use the Diffie-Hellman output to encrypt the Host Identity of the Initiator in the 3rd packet (although Aura, et al. [AUR05] note that such operation may interfere with packet-inspecting middleboxes), or the Host Identity may instead be sent unencrypted. The Responder's Host Identity is not protected. It should be noted, however, that both the Initiator's and the Responder's HITs are transported as such (in cleartext) in the packets, allowing an eavesdropper with a priori knowledge about the parties to identify them by their HITs. Hence, encrypting the HI of any party does not provide privacy against such an attacker.
交换可以使用Diffie-Hellman输出来加密第三个数据包中发起方的主机标识（尽管Aura等人[AUR05]注意，这样的操作可能会干扰数据包检查中间盒），或者主机标识可以改为未加密发送。响应程序的主机标识不受保护。然而，应该注意的是，发起方和响应方的点击都是在包中以明文的形式传输的，从而允许事先知道各方的窃听者通过点击来识别它们。因此，加密任何一方的HI不会提供针对此类攻击者的隐私。
Data packets start to flow after the 4th packet. The 3rd and 4th HIP packets may carry a data payload in the future. However, the details of this may be defined later.
数据包在第4个数据包之后开始流动。第3和第4 HIP分组将来可能携带数据有效载荷。但是，这方面的细节可能会在以后定义。
An existing HIP association can be updated using the update mechanism defined in this document, and when the association is no longer needed, it can be closed using the defined closing mechanism.
可以使用本文档中定义的更新机制更新现有髋部关联，当不再需要关联时，可以使用定义的关闭机制关闭关联。
Finally, HIP is designed as an end-to-end authentication and key establishment protocol, to be used with Encapsulating Security Payload (ESP) [RFC7402] and other end-to-end security protocols. The base protocol does not cover all the fine-grained policy control found in Internet Key Exchange (IKE) [RFC7296] that allows IKE to support complex gateway policies. Thus, HIP is not a complete replacement for IKE.
最后，HIP被设计为端到端身份验证和密钥建立协议，与封装安全有效负载（ESP）[RFC7402]和其他端到端安全协议一起使用。基本协议没有涵盖Internet密钥交换（IKE）[RFC7296]中的所有细粒度策略控制，该协议允许IKE支持复杂的网关策略。因此，髋关节不是IKE的完全替代物。
The rest of this memo is structured as follows. Section 2 defines the central keywords, notation, and terms used throughout the rest of the document. Section 3 defines the structure of the Host Identity and its various representations. Section 4 gives an overview of the HIP base exchange protocol. Sections 5 and 6 define the detailed packet formats and rules for packet processing. Finally, Sections 7, 8, and 9 discuss policy, security, and IANA considerations, respectively.
本备忘录的其余部分结构如下。第2节定义了贯穿文档其余部分的中心关键字、符号和术语。第3节定义了主机标识的结构及其各种表示。第4节概述了HIP-base交换协议。第5节和第6节定义了详细的数据包格式和数据包处理规则。最后，第7、8和9节分别讨论了策略、安全和IANA考虑事项。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
[x] indicates that x is optional.
[x] 指示x是可选的。
{x} indicates that x is encrypted.
{x} 指示x已加密。
X(y) indicates that y is a parameter of X.
X（y）表示y是X的一个参数。
<x>i indicates that x exists i times.
<x> i表示x存在i次。
--> signifies "Initiator to Responder" communication (requests).
-->表示“发起者到响应者”通信（请求）。
<-- signifies "Responder to Initiator" communication (replies).
<--表示“响应者到发起人”通信（回复）。
| signifies concatenation of information (e.g., X | Y is the concatenation of X with Y).
|表示信息的串联（例如，X | Y是X与Y的串联）。
Ltrunc (H(x), #K) denotes the lowest-order #K bits of the result of the hash function H on the input x.
Ltrunc（H（x），#K）表示输入x上散列函数H的结果的最低阶#K位。
HIP base exchange (BEX): The handshake for establishing a new HIP association.
髋关节基础交换（BEX）：建立新髋关节协会的握手。
Host Identity (HI): The public key of the signature algorithm that represents the identity of the host. In HIP, a host proves its identity by creating a signature with the private key belonging to its HI (cf. Section 3).
主机标识（HI）：表示主机标识的签名算法的公钥。在HIP中，主机通过使用属于其HI的私钥创建签名来证明其身份（参见第3节）。
Host Identity Tag (HIT): A shorthand for the HI in IPv6 format. It is generated by hashing the HI (cf. Section 3.1).
主机标识标签（HIT）：IPv6格式的HI的缩写。它是通过散列HI生成的（参见第3.1节）。
HIT Suite: A HIT Suite groups all cryptographic algorithms that are required to generate and use an HI and its HIT. In particular, these algorithms are 1) the public key signature algorithm, 2) the hash function, and 3) the truncation (cf. Appendix E).
HIT套件：HIT套件将生成和使用HI及其HIT所需的所有加密算法分组。具体而言，这些算法是1）公钥签名算法，2）哈希函数，以及3）截断（参见附录E）。
HIP association: The shared state between two peers after completion of the BEX.
髋部关联：完成BEX后两个同伴之间的共享状态。
HIP packet: A control packet carrying a HIP packet header relating to the establishment, maintenance, or termination of the HIP association.
HIP数据包：携带HIP数据包头的控制数据包，与HIP关联的建立、维护或终止有关。
Initiator: The host that initiates the BEX. This role is typically forgotten once the BEX is completed.
启动器：启动BEX的主机。一旦BEX完成，通常会忘记此角色。
Responder: The host that responds to the Initiator in the BEX. This role is typically forgotten once the BEX is completed.
响应程序：在BEX中响应启动器的主机。一旦BEX完成，通常会忘记此角色。
Responder's HIT hash algorithm (RHASH): The hash algorithm used for various hash calculations in this document. The algorithm is the same as is used to generate the Responder's HIT. The RHASH is the hash function defined by the HIT Suite of the Responder's HIT (cf. Section 5.2.10).
响应者的命中哈希算法（RHASH）：本文档中用于各种哈希计算的哈希算法。该算法与用于生成响应者命中的算法相同。RHASH是由响应者HIT的HIT套件定义的哈希函数（参见第5.2.10节）。
Length of the Responder's HIT hash algorithm (RHASH_len): The natural output length of RHASH in bits.
响应程序的命中哈希算法（RHASH_len）的长度：以位为单位的RHASH的自然输出长度。
Signed data: Data that is signed is protected by a digital signature that was created by the sender of the data by using the private key of its HI.
已签名数据：已签名的数据受数据发送方使用其HI的私钥创建的数字签名保护。
KDF: The Key Derivation Function (KDF) is used for deriving the symmetric keys from the Diffie-Hellman key exchange.
KDF：密钥派生函数（KDF）用于从Diffie-Hellman密钥交换中派生对称密钥。
KEYMAT: The keying material derived from the Diffie-Hellman key exchange by using the KDF. Symmetric keys for encryption and integrity protection of HIP packets and encrypted user data packets are drawn from this keying material.
KEYMAT：通过使用KDF从Diffie-Hellman密钥交换派生的密钥材料。用于加密和完整性保护HIP数据包和加密用户数据包的对称密钥取自此密钥材料。
In this section, the properties of the Host Identity and Host Identity Tag are discussed, and the exact format for them is defined. In HIP, the public key of an asymmetric key pair is used as the Host Identity (HI). Correspondingly, the host itself is defined as the entity that holds the private key of the key pair. See the HIP architecture specification [HIP-ARCH] for more details on the difference between an identity and the corresponding identifier.
在本节中，将讨论主机标识和主机标识标记的属性，并定义它们的确切格式。在HIP中，非对称密钥对的公钥用作主机标识（HI）。相应地，主机本身被定义为持有密钥对的私钥的实体。有关标识和相应标识符之间差异的更多详细信息，请参见HIP体系结构规范[HIP-ARCH]。
HIP implementations MUST support the Rivest Shamir Adleman [RSA] public key algorithm and the Elliptic Curve Digital Signature Algorithm (ECDSA) for generating the HI as defined in Section 5.2.9. Additional algorithms MAY be supported.
HIP实现必须支持Rivest-Shamir-Adleman[RSA]公钥算法和椭圆曲线数字签名算法（ECDSA），以生成第5.2.9节中定义的HI。可能支持其他算法。
A hashed encoding of the HI, the Host Identity Tag (HIT), is used in protocols to represent the Host Identity. The HIT is 128 bits long and has the following three key properties: i) it is the same length as an IPv6 address and can be used in fixed address-sized fields in APIs and protocols; ii) it is self-certifying (i.e., given a HIT, it is computationally hard to find a Host Identity key that matches the HIT); and iii) the probability of a HIT collision between two hosts
HI的哈希编码，即主机标识标记（HIT），在协议中用于表示主机标识。HIT的长度为128位，具有以下三个关键属性：i）它与IPv6地址的长度相同，可用于API和协议中固定地址大小的字段中；ii）它是自我认证的（即，给定命中，在计算上很难找到与命中匹配的主机标识密钥）；以及iii）两台主机之间发生碰撞的概率
is very low; hence, it is infeasible for an attacker to find a collision with a HIT that is in use. For details on the security properties of the HIT, see [HIP-ARCH].
很低,；因此，攻击者不可能找到与正在使用的命中的碰撞。有关命中的安全属性的详细信息，请参阅[HIP-ARCH]。
The structure of the HIT is defined in [RFC7343]. The HIT is an Overlay Routable Cryptographic Hash Identifier (ORCHID) and consists of three parts: first, an IANA-assigned prefix to distinguish it from other IPv6 addresses; second, a four-bit encoding of the algorithms that were used for generating the HI and the hashed representation of HI; third, a 96-bit hashed representation of the Host Identity. The encoding of the ORCHID generation algorithm and the exact algorithm for generating the hashed representation are specified in Appendix E and [RFC7343].
命中的结构在[RFC7343]中定义。HIT是一个覆盖可路由加密哈希标识符（RUCH），由三部分组成：第一，IANA分配的前缀，用于将其与其他IPv6地址区分开来；第二，对用于生成HI和HI的哈希表示的算法进行四位编码；第三，主机标识的96位哈希表示。附录E和[RFC7343]中规定了兰花生成算法的编码和生成哈希表示的精确算法。
Carrying HIs and HITs in the header of user data packets would increase the overhead of packets. Thus, it is not expected that they are carried in every packet, but other methods are used to map the data packets to the corresponding HIs. In some cases, this makes it possible to use HIP without any additional headers in the user data packets. For example, if ESP is used to protect data traffic, the Security Parameter Index (SPI) carried in the ESP header can be used to map the encrypted data packet to the correct HIP association.
在用户数据包的报头中携带HIs和HIT会增加数据包的开销。因此，不期望在每个分组中携带它们，而是使用其他方法将数据分组映射到相应的hi。在某些情况下，这使得在用户数据包中使用HIP而不需要任何额外的头成为可能。例如，如果ESP用于保护数据流量，则ESP报头中携带的安全参数索引（SPI）可用于将加密数据包映射到正确的HIP关联。
The Host Identity Tag is a 128-bit value -- a hashed encoding of the Host Identifier. There are two advantages of using a hashed encoding over the actual variable-sized Host Identity public key in protocols. First, the fixed length of the HIT keeps packet sizes manageable and eases protocol coding. Second, it presents a consistent format for the protocol, independent of the underlying identity technology in use.
主机标识标记是一个128位的值——主机标识符的哈希编码。与协议中的实际可变大小主机标识公钥相比，使用哈希编码有两个优点。首先，HIT的固定长度使数据包大小易于管理，并简化了协议编码。其次，它为协议提供了一致的格式，独立于使用的底层身份技术。
RFC 7343 [RFC7343] specifies 128-bit hash-based identifiers, called ORCHIDs. Their prefix, allocated from the IPv6 address block, is defined in [RFC7343]. The Host Identity Tag is one type of ORCHID.
RFC 7343[RFC7343]指定128位基于散列的标识符，称为RAYTS。从IPv6地址块分配的前缀在[RFC7343]中定义。寄主身份标签是一种兰花。
This document extends the original, experimental HIP specification [RFC5201] with measures to support crypto agility. One of these measures allows different hash functions for creating a HIT. HIT Suites group the sets of algorithms that are required to generate and use a particular HIT. The Suites are encoded in HIT Suite IDs. These HIT Suite IDs are transmitted in the ORCHID Generation Algorithm (OGA) field in the ORCHID. With the HIT Suite ID in the OGA ID field, a host can tell, from another host's HIT, whether it supports the necessary hash and signature algorithms to establish a HIP association with that host.
本文档扩展了原始的实验性HIP规范[RFC5201]，提供了支持加密灵活性的措施。其中一种方法允许使用不同的哈希函数来创建命中。HIT套件对生成和使用特定HIT所需的算法集进行分组。这些套件在HIT套件ID中编码。这些命中套件ID在兰花中的兰花生成算法（OGA）字段中传输。通过OGA ID字段中的HIT套件ID，主机可以从另一主机的HIT中判断它是否支持必要的哈希和签名算法，以建立与该主机的HIP关联。
The HIT MUST be generated according to the ORCHID generation method described in [RFC7343] using a context ID value of 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been generated randomly by the editor of this specification), and an input that encodes the Host Identity field (see Section 5.2.9) present in a HIP payload packet. The set of hash function, signature algorithm, and the algorithm used for generating the HIT from the HI depends on the HIT Suite (see Section 5.2.10) and is indicated by the four bits of the OGA ID field in the ORCHID. Currently, truncated SHA-1, truncated SHA-384, and truncated SHA-256 [FIPS.180-4.2012] are defined as hashes for generating a HIT.
必须使用上下文ID值0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA（该标记值由本规范的编辑器随机生成）和对HIP有效负载数据包中的主机标识字段（见第5.2.9节）进行编码的输入，根据[RFC7343]中描述的RAYD生成方法生成HIT。哈希函数集、签名算法和用于从HI生成HIT的算法取决于HIT套件（见第5.2.10节），并由RUMP中OGA ID字段的四位表示。目前，截断的SHA-1、截断的SHA-384和截断的SHA-256[FIPS.180-4.2012]被定义为生成命中的哈希。
For identities that are either RSA, Digital Signature Algorithm (DSA) [FIPS.186-4.2013], or Elliptic Curve DSA (ECDSA) public keys, the ORCHID input consists of the public key encoding as specified for the Host Identity field of the HOST_ID parameter (see Section 5.2.9). This document defines four algorithm profiles: RSA, DSA, ECDSA, and ECDSA_LOW. The ECDSA_LOW profile is meant for devices with low computational capabilities. Hence, one of the following applies:
对于RSA、数字签名算法（DSA）[FIPS.186-4.2013]或椭圆曲线DSA（ECDSA）公钥的身份，兰花输入包含为Host_ID参数的Host Identity字段指定的公钥编码（见第5.2.9节）。本文档定义了四种算法配置文件：RSA、DSA、ECDSA和ECDSA_LOW。ECDSA_LOW profile适用于计算能力较低的设备。因此，以下情况之一适用：
The RSA public key is encoded as defined in [RFC3110], Section 2, taking the exponent length (e_len), exponent (e), and modulus (n) fields concatenated. The length (n_len) of the modulus (n) can be determined from the total HI Length and the preceding HI fields including the exponent (e). Thus, the data that serves as input for the HIT generation has the same length as the HI. The fields MUST be encoded in network byte order, as defined in [RFC3110].
RSA公钥按照[RFC3110]第2节中的定义进行编码，采用串联的指数长度（e_len）、指数（e）和模（n）字段。模量（n）的长度（n_len）可根据总HI长度和前面的HI字段（包括指数（e））确定。因此，用作HIT生成输入的数据具有与HI相同的长度。字段必须按照[RFC3110]中定义的网络字节顺序编码。
The DSA public key is encoded as defined in [RFC2536], Section 2, taking the fields T, Q, P, G, and Y, concatenated as input. Thus, the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long, where T is the size parameter as defined in [RFC2536]. The size parameter T, affecting the field lengths, MUST be selected as the minimum value that is long enough to accommodate P, G, and Y. The fields MUST be encoded in network byte order, as defined in [RFC2536].
DSA公钥按照[RFC2536]第2节中的定义进行编码，将字段T、Q、P、G和Y串接为输入。因此，要散列的数据是1+20+3*64+3*8*T八位字节长，其中T是[RFC2536]中定义的大小参数。影响字段长度的大小参数T必须选择为长度足以容纳P、G和Y的最小值。字段必须按照[RFC2536]中定义的网络字节顺序编码。
The ECDSA public keys are encoded as defined in Sections 4.2 and 6 of [RFC6090].
ECDSA公钥按照[RFC6090]第4.2节和第6节的规定进行编码。
In Appendix B, the public key encoding process is illustrated using pseudo-code.
在附录B中，使用伪码说明了公钥编码过程。
This section is a simplified overview of the HIP protocol operation, and does not contain all the details of the packet formats or the packet processing steps. Sections 5 and 6 describe in more detail the packet formats and packet processing steps, respectively, and are normative in case of any conflicts with this section.
本节是HIP协议操作的简化概述，不包含数据包格式或数据包处理步骤的所有详细信息。第5节和第6节分别更详细地描述了数据包格式和数据包处理步骤，并且在与本节冲突的情况下是规范性的。
The protocol number 139 has been assigned by IANA to the Host Identity Protocol.
IANA已将协议编号139分配给主机标识协议。
The HIP payload (Section 5.1) header could be carried in every IP datagram. However, since HIP headers are relatively large (40 bytes), it is desirable to 'compress' the HIP header so that the HIP header only occurs in control packets used to establish or change HIP association state. The actual method for header 'compression' and for matching data packets with existing HIP associations (if any) is defined in separate documents, describing transport formats and methods. All HIP implementations MUST implement, at minimum, the ESP transport format for HIP [RFC7402].
HIP有效载荷（第5.1节）报头可以在每个IP数据报中携带。然而，由于HIP报头相对较大（40字节），因此需要“压缩”HIP报头，以便HIP报头仅出现在用于建立或更改HIP关联状态的控制分组中。标头“压缩”和将数据包与现有HIP关联（如果有）匹配的实际方法在单独的文档中定义，描述了传输格式和方法。所有HIP实施必须至少实现HIP的ESP传输格式[RFC7402]。
By definition, the system initiating a HIP base exchange is the Initiator, and the peer is the Responder. This distinction is typically forgotten once the base exchange completes, and either party can become the Initiator in future communications.
根据定义，发起HIP-base交换的系统是发起方，对等方是响应方。一旦基本交换完成，这种区别通常会被忘记，任何一方都可以成为未来通信的发起方。
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. In the first two packets, the hosts agree on a set of cryptographic identifiers and algorithms that are then used in and after the exchange. During the Diffie-Hellman key exchange, a piece of keying material is generated. The HIP association keys are drawn from this keying material by using a Key Derivation Function (KDF). If other cryptographic keys are needed, e.g., to be used with ESP, they are expected to be drawn from the same keying material by using the KDF.
HIP-base交换用于管理发起方和响应方之间状态的建立。第一个数据包I1启动交换，最后三个数据包R1、I2和R2构成用于会话密钥生成的经过身份验证的Diffie-Hellman[DIF76]密钥交换。在前两个数据包中，主机同意一组加密标识符和算法，然后在交换中和交换后使用这些标识符和算法。在Diffie-Hellman密钥交换过程中，会生成一段密钥材料。髋部关联关键帧是使用关键帧衍生函数（KDF）从该关键帧材质中绘制的。如果需要其他加密密钥，例如与ESP一起使用，则应使用KDF从相同的密钥材料中提取密钥。
The Initiator first sends a trigger packet, I1, to the Responder. The packet contains the HIT of the Initiator and possibly the HIT of the Responder, if it is known. Moreover, the I1 packet initializes the negotiation of the Diffie-Hellman group that is used for generating the keying material. Therefore, the I1 packet contains a list of Diffie-Hellman Group IDs supported by the Initiator. Note that in some cases it may be possible to replace this trigger packet
发起方首先向响应方发送一个触发包I1。数据包包含发起方的命中，如果已知，还可能包含响应方的命中。此外，I1分组初始化用于生成密钥材料的Diffie-Hellman组的协商。因此，I1数据包包含发起者支持的Diffie-Hellman组ID列表。请注意，在某些情况下，可能会替换此触发器数据包
with some other form of a trigger, in which case the protocol starts with the Responder sending the R1 packet. In such cases, another mechanism to convey the Initiator's supported DH groups (e.g., by using a default group) must be specified.
使用其他形式的触发器，在这种情况下，协议从响应程序发送R1数据包开始。在这种情况下，必须指定另一种机制来传递启动器支持的DH组（例如，通过使用默认组）。
The second packet, R1, starts the actual authenticated Diffie-Hellman exchange. It contains a puzzle -- a cryptographic challenge that the Initiator must solve before continuing the exchange. The level of difficulty of the puzzle can be adjusted based on the level of trust with the Initiator, the current load, or other factors. In addition, the R1 contains the Responder's Diffie-Hellman parameter and lists of cryptographic algorithms supported by the Responder. Based on these lists, the Initiator can continue, abort, or restart the base exchange with a different selection of cryptographic algorithms. Also, the R1 packet contains a signature that covers selected parts of the message. Some fields are left outside the signature to support pre-created R1s.
第二个数据包R1启动实际的经过身份验证的Diffie-Hellman交换。它包含一个谜题——发起方在继续交换之前必须解决的加密挑战。谜题的难度可以根据对发起者的信任程度、当前负载或其他因素进行调整。此外，R1包含响应者的Diffie-Hellman参数和响应者支持的加密算法列表。根据这些列表，启动器可以使用不同的加密算法选择继续、中止或重新启动基本exchange。此外，R1数据包包含覆盖消息选定部分的签名。有些字段保留在签名之外，以支持预先创建的R1s。
In the I2 packet, the Initiator MUST display the solution to the received puzzle. Without a correct solution, the I2 message is discarded. The I2 packet also contains a Diffie-Hellman parameter that carries needed information for the Responder. The I2 packet is signed by the Initiator.
在I2数据包中，发起者必须显示收到的谜题的解决方案。如果没有正确的解决方案，I2消息将被丢弃。I2数据包还包含一个Diffie-Hellman参数，该参数携带响应者所需的信息。I2数据包由发起方签名。
The R2 packet acknowledges the receipt of the I2 packet and completes the base exchange. The packet is signed by the Responder.
R2数据包确认收到I2数据包并完成基本交换。数据包由响应者签名。
The base exchange is illustrated below in Figure 1. The term "key" refers to the Host Identity public key, and "sig" represents a signature using such a key. The packets contain other parameters not shown in this figure.
基本交换如下图1所示。术语“密钥”是指主机标识公钥，“sig”表示使用这种密钥的签名。数据包包含此图中未显示的其他参数。
Initiator Responder
发起者响应者
I1: DH list
-------------------------->
select precomputed R1
R1: puzzle, DH, key, sig
<-------------------------
check sig remain stateless
solve puzzle
I2: solution, DH, {key}, sig
-------------------------->
compute DH check puzzle
check sig
R2: sig
<--------------------------
check sig compute DH
I1: DH list
-------------------------->
select precomputed R1
R1: puzzle, DH, key, sig
<-------------------------
check sig remain stateless
solve puzzle
I2: solution, DH, {key}, sig
-------------------------->
compute DH check puzzle
check sig
R2: sig
<--------------------------
check sig compute DH
Figure 1
图1
The purpose of the HIP puzzle mechanism is to protect the Responder from a number of denial-of-service threats. It allows the Responder to delay state creation until receiving the I2 packet. Furthermore, the puzzle allows the Responder to use a fairly cheap calculation to check that the Initiator is "sincere" in the sense that it has churned enough CPU cycles in solving the puzzle.
HIP puzzle机制的目的是保护响应者免受拒绝服务威胁。它允许响应者延迟状态创建，直到接收到I2数据包。此外，谜题允许响应者使用相当便宜的计算来检查发起者是否“真诚”，因为发起者在解决谜题时已经投入了足够的CPU周期。
The puzzle allows a Responder implementation to completely delay association-specific state creation until a valid I2 packet is received. An I2 packet without a valid puzzle solution can be rejected immediately once the Responder has checked the solution. The solution can be checked by computing only one hash function, and invalid solutions can be rejected before state is created, and before CPU-intensive public-key signature verification and Diffie-Hellman key generation are performed. By varying the difficulty of the puzzle, the Responder can frustrate CPU- or memory-targeted DoS attacks.
谜题允许响应程序实现完全延迟特定于关联的状态创建，直到收到有效的I2数据包。没有有效谜题解决方案的I2数据包可以在响应者检查解决方案后立即被拒绝。可以通过只计算一个哈希函数来检查解决方案，在创建状态之前，以及在执行CPU密集型公钥签名验证和Diffie-Hellman密钥生成之前，可以拒绝无效的解决方案。通过改变谜题的难度，响应者可以挫败针对CPU或内存的DoS攻击。
The Responder can remain stateless and drop most spoofed I2 packets because puzzle calculation is based on the Initiator's Host Identity Tag. The idea is that the Responder has a (perhaps varying) number of pre-calculated R1 packets, and it selects one of these based on
响应程序可以保持无状态并丢弃大多数伪造的I2数据包，因为谜题计算基于启动器的主机标识标签。其思想是响应者具有（可能是变化的）数量的预先计算的R1数据包，并且它基于这些数据包中的一个进行选择
the information carried in the I1 packet. When the Responder then later receives the I2 packet, it can verify that the puzzle has been solved using the Initiator's HIT. This makes it impractical for the attacker to first exchange one I1/R1 packet, and then generate a large number of spoofed I2 packets that seemingly come from different HITs. This method does not protect the Responder from an attacker that uses fixed HITs, though. Against such an attacker, a viable approach may be to create a piece of local state, and remember that the puzzle check has previously failed. See Appendix A for one possible implementation. Responder implementations SHOULD include sufficient randomness in the puzzle values so that algorithmic complexity attacks become impossible [CRO03].
I1数据包中携带的信息。当响应者随后接收到I2数据包时，它可以使用启动器的HIT验证谜题是否已解决。这使得攻击者无法首先交换一个I1/R1数据包，然后生成大量看似来自不同命中的伪造I2数据包。但是，此方法无法保护响应程序免受使用固定命中的攻击者的攻击。针对此类攻击者，一种可行的方法可能是创建一段本地状态，并记住之前的谜题检查失败。有关一种可能的实施方式，请参见附录A。响应者的实现应该在谜题值中包含足够的随机性，以便算法复杂性攻击变得不可能[CRO03]。
The Responder can set the puzzle difficulty for the Initiator, based on its level of trust of the Initiator. Because the puzzle is not included in the signature calculation, the Responder can use pre-calculated R1 packets and include the puzzle just before sending the R1 to the Initiator. The Responder SHOULD use heuristics to determine when it is under a denial-of-service attack, and set the puzzle difficulty value #K appropriately, as explained later.
响应者可以根据其对发起者的信任程度为发起者设置谜题难度。因为谜题不包括在签名计算中，所以响应者可以使用预先计算的R1数据包，并在将R1发送给发起方之前包括谜题。响应者应使用启发式方法确定何时受到拒绝服务攻击，并适当设置谜题难度值#K，如下文所述。
The Responder starts the puzzle exchange when it receives an I1 packet. The Responder supplies a random number #I, and requires the Initiator to find a number #J. To select a proper #J, the Initiator must create the concatenation of #I, the HITs of the parties, and #J, and calculate a hash over this concatenation using the RHASH algorithm. The lowest-order #K bits of the result MUST be zeros. The value #K sets the difficulty of the puzzle.
响应者在收到I1数据包时启动谜题交换。响应者提供一个随机数#I，并要求发起者找到一个数#J。要选择一个合适的#J，发起者必须创建#I、各方点击数和#J的串联，并使用RHASH算法计算该串联的哈希值。结果的最低阶#K位必须为零。值#K设置拼图的难度。
To generate a proper number #J, the Initiator will have to generate a number of #Js until one produces the hash target of zeros. The Initiator SHOULD give up after exceeding the puzzle Lifetime in the PUZZLE parameter (as described in Section 5.2.4). The Responder needs to re-create the concatenation of #I, the HITs, and the provided #J, and compute the hash once to prove that the Initiator completed its assigned task.
为了生成一个适当的数字#J，发起者必须生成一个数量的#J，直到其中一个生成零数的散列目标。发起者应在超过puzzle参数中的puzzle生存期后放弃（如第5.2.4节所述）。响应者需要重新创建#I、命中和提供的#J的串联，并计算一次散列，以证明发起方完成了分配的任务。
To prevent precomputation attacks, the Responder MUST select the number #I in such a way that the Initiator cannot guess it. Furthermore, the construction MUST allow the Responder to verify that the value #I was indeed selected by it and not by the Initiator. See Appendix A for an example on how to implement this.
为了防止预计算攻击，响应者必须选择数字#I，使启动器无法猜到。此外，构造必须允许响应者验证值#I确实是由它选择的，而不是由启动器选择的。有关如何实现这一点的示例，请参见附录A。
Using the Opaque data field in the PUZZLE (see Section 5.2.4) in an ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder
在已签名的回音请求（见第5.2.20节）或未签名的回音请求参数（见第5.2.21节）中，使用拼图（见第5.2.4节）中的不透明数据字段，响应者
can include some data in R1 that the Initiator MUST copy unmodified in the corresponding I2 packet. The Responder can use the opaque data to transfer a piece of local state information to the Initiator and back -- for example, to recognize that the I2 is a response to a previously sent R1. The Responder can generate the opaque data in various ways, e.g., using encryption or hashing with some secret, the sent #I, and possibly using other related data. With the same secret, the received #I (from the I2 packet), and the other related data (if any), the Responder can verify that it has itself sent the #I to the Initiator. The Responder MUST periodically change such a secret.
可以在R1中包含一些数据，发起者必须在相应的I2数据包中复制这些数据而不进行修改。响应者可以使用不透明数据将一段本地状态信息传输给发起方并返回——例如，识别I2是对先前发送的R1的响应。响应者可以以各种方式生成不透明数据，例如，使用加密或散列处理一些秘密、发送的I，以及可能使用其他相关数据。使用相同的秘密、接收到的#I（来自I2数据包）和其他相关数据（如果有），响应者可以验证自己是否已将#I发送给发起方。响应者必须定期更改此类机密。
It is RECOMMENDED that the Responder generates new secrets for the puzzle and new R1s once every few minutes. Furthermore, it is RECOMMENDED that the Responder is able to verify a valid puzzle solution at least Lifetime seconds after the puzzle secret has been deprecated. This time value guarantees that the puzzle is valid for at least Lifetime and at most 2 * Lifetime seconds. This limits the usability that an old, solved puzzle has to an attacker. Moreover, it avoids problems with the validity of puzzles if the lifetime is relatively short compared to the network delay and the time for solving the puzzle.
建议响应者每隔几分钟生成一次谜题和新R1s的新秘密。此外，建议响应者在谜题机密被弃用后至少在生命周期秒内验证有效的谜题解决方案。此时间值保证拼图至少在生存期内有效，最多2*生存期秒。这限制了攻击者对一个已解决的旧难题的可用性。此外，与网络延迟和解谜时间相比，如果生存期相对较短，则可以避免与谜题有效性相关的问题。
The puzzle value #I and the solution #J are inputs for deriving the keying material from the Diffie-Hellman key exchange (see Section 6.5). Therefore, to ensure that the derived keying material differs, a Responder SHOULD NOT use the same puzzle #I with the same DH keys for the same Initiator twice. Such uniqueness can be achieved, for example, by using a counter as an additional input for generating #I. This counter can be increased for each processed I1 packet. The state of the counter can be transmitted in the Opaque data field in the PUZZLE (see Section 5.2.4), in an ECHO_REQUEST_SIGNED parameter (see Section 5.2.20), or in an ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need to establish state.
拼图值#I和解#J是从Diffie-Hellman密钥交换中导出密钥材料的输入（参见第6.5节）。因此，为了确保派生的键控材料不同，响应者不应该对同一发起人两次使用具有相同DH键的相同拼图#I。例如，可以通过使用计数器作为生成#I的额外输入来实现这种唯一性。可以为每个处理的I1数据包增加该计数器。计数器的状态可以在拼图中的不透明数据字段（见第5.2.4节）、ECHO_REQUEST_SIGNED参数（见第5.2.20节）或ECHO_REQUEST_UNSIGNED参数（见第5.2.21节）中传输，而无需建立状态。
NOTE: The protocol developers explicitly considered whether R1 should include a timestamp in order to protect the Initiator from replay attacks. The decision was to NOT include a timestamp, to avoid problems with global time synchronization.
注意：协议开发人员明确考虑了R1是否应包含时间戳，以保护启动器免受重播攻击。决定不包括时间戳，以避免全局时间同步问题。
NOTE: The protocol developers explicitly considered whether a memory-bound function should be used for the puzzle instead of a CPU-bound function. The decision was to not use memory-bound functions.
注意：协议开发人员明确考虑了是否应该使用内存绑定函数来代替CPU绑定函数。决定是不使用内存绑定函数。
The packets R1, I2, and R2 implement a standard authenticated Diffie-Hellman exchange. The Responder sends one of its public Diffie-Hellman keys and its public authentication key, i.e., its Host Identity, in R1. The signature in the R1 packet allows the Initiator to verify that the R1 has been once generated by the Responder. However, since the R1 is precomputed and therefore does not cover association-specific information in the I1 packet, it does not protect against replay attacks.
数据包R1、I2和R2实现标准的经过身份验证的Diffie-Hellman交换。响应者在R1中发送其公共Diffie-Hellman密钥之一及其公共身份验证密钥，即其主机标识。R1数据包中的签名允许发起方验证R1是否已由响应方生成。然而，由于R1是预计算的，因此在I1数据包中不包含特定于关联的信息，因此它不能防止重播攻击。
Before the actual authenticated Diffie-Hellman exchange, the Initiator expresses its preference regarding its choice of the DH groups in the I1 packet. The preference is expressed as a sorted list of DH Group IDs. The I1 packet is not protected by a signature. Therefore, this list is sent in an unauthenticated way to avoid costly computations for processing the I1 packet at the Responder side. Based on the preferences of the Initiator, the Responder sends an R1 packet containing its most suitable public DH value. The Responder also attaches a list of its own preferences to the R1 to convey the basis for the DH group selection to the Initiator. This list is carried in the signed part of the R1 packet. If the choice of the DH group value in the R1 does not match the preferences of the Initiator and the Responder, the Initiator can detect that the list of DH Group IDs in the I1 was manipulated (see below for details).
在实际经过身份验证的Diffie-Hellman交换之前，发起方表示其在I1数据包中选择DH组的偏好。首选项表示为DH组ID的排序列表。I1数据包不受签名保护。因此，该列表以未经认证的方式发送，以避免在响应方端处理I1分组的昂贵计算。基于发起方的偏好，响应方发送包含其最合适的公共DH值的R1数据包。响应者还将其自身偏好的列表附加到R1，以将DH组选择的基础传达给发起人。此列表包含在R1数据包的签名部分。如果R1中DH group值的选择与发起方和响应方的首选项不匹配，则发起方可以检测到I1中的DH group ID列表被操纵（详见下文）。
If none of the DH Group IDs in the I1 packet are supported by the Responder, the Responder selects the DH group most suitable for it, regardless of the Initiator's preference. It then sends the R1 containing this DH group and its list of supported DH Group IDs to the Initiator.
如果响应者不支持I1数据包中的DH组id，则响应者选择最适合它的DH组，而不管启动器的偏好如何。然后，它将包含此DH组及其支持的DH组ID列表的R1发送给启动器。
When the Initiator receives an R1, it receives one of the Responder's public Diffie-Hellman values and the list of DH Group IDs supported by the Responder. This list is covered by the signature in the R1 packet to avoid forgery. The Initiator compares the Group ID of the public DH value in the R1 packet to the list of supported DH Group IDs in the R1 packets and to its own preferences expressed in the list of supported DH Group IDs. The Initiator continues the BEX only if the Group ID of the public DH value of the Responder is the most preferred of the IDs supported by both the Initiator and Responder. Otherwise, the communication is subject to a downgrade attack, and the Initiator MUST either restart the base exchange with a new I1 packet or abort the base exchange. If the Responder's choice of the DH group is not supported by the Initiator, the Initiator MAY abort the handshake or send a new I1 packet with a different list of supported DH groups. However, the Initiator MUST verify the
当启动器接收到R1时，它接收响应程序的一个公共Diffie Hellman值和响应程序支持的DH组ID列表。此列表包含在R1数据包中的签名中，以避免伪造。发起方将R1数据包中公共DH值的组ID与R1数据包中支持的DH组ID列表以及支持的DH组ID列表中表示的自身偏好进行比较。只有当响应程序的公共DH值的组ID是发起程序和响应程序都支持的ID中最优先的ID时，发起程序才继续执行BEX。否则，通信将受到降级攻击，发起方必须使用新的I1数据包重新启动基本交换或中止基本交换。如果发起方不支持响应方对DH组的选择，则发起方可中止握手或发送具有不同支持DH组列表的新I1分组。但是，启动器必须验证
signature of the R1 packet before restarting or aborting the handshake. It MUST silently ignore the R1 packet if the signature is not valid.
重新启动或中止握手前R1数据包的签名。如果签名无效，它必须默默地忽略R1数据包。
If the preferences regarding the DH Group ID match, the Initiator computes the Diffie-Hellman session key (Kij). The Initiator creates a HIP association using keying material from the session key (see Section 6.5) and may use the HIP association to encrypt its public authentication key, i.e., the Host Identity. The resulting I2 packet contains the Initiator's Diffie-Hellman key and its (optionally encrypted) public authentication key. The signature of the I2 message covers all parameters of the signed parameter ranges (see Section 5.2) in the packet without exceptions, as in the R1.
如果有关DH组ID的首选项匹配，则发起方计算Diffie-Hellman会话密钥（Kij）。发起人使用会话密钥中的密钥材料（见第6.5节）创建HIP关联，并可使用HIP关联加密其公共认证密钥，即主机标识。生成的I2数据包包含启动器的Diffie-Hellman密钥及其（可选加密的）公共身份验证密钥。I2消息的签名覆盖了数据包中签名参数范围（见第5.2节）的所有参数，与R1中一样，没有例外。
The Responder extracts the Initiator's Diffie-Hellman public key from the I2 packet, computes the Diffie-Hellman session key, creates a corresponding HIP association, and decrypts the Initiator's public authentication key. It can then verify the signature using the authentication key.
响应者从I2数据包中提取发起方的Diffie-Hellman公钥，计算Diffie-Hellman会话密钥，创建相应的HIP关联，并解密发起方的公共身份验证密钥。然后，它可以使用身份验证密钥验证签名。
The final message, R2, completes the BEX and protects the Initiator against replay attacks, because the Responder uses the shared key from the Diffie-Hellman exchange to create a Hashed Message Authentication Code (HMAC) and also uses the private key of its Host Identity to sign the packet contents.
最后一条消息R2完成BEX并保护发起方免受重播攻击，因为响应方使用Diffie-Hellman交换的共享密钥创建哈希消息身份验证码（HMAC），还使用其主机标识的私钥对数据包内容进行签名。
HIP includes the following mechanisms to protect against malicious packet replays. Responders are protected against replays of I1 packets by virtue of the stateless response to I1 packets with pre-signed R1 messages. Initiators are protected against R1 replays by a monotonically increasing "R1 generation counter" included in the R1. Responders are protected against replays of forged I2 packets by the puzzle mechanism (see Section 4.1.1 above), and optional use of opaque data. Hosts are protected against replays of R2 packets and UPDATEs by use of a less expensive HMAC verification preceding the HIP signature verification.
HIP包括以下机制以防止恶意数据包重放。通过对带有预签名R1消息的I1数据包的无状态响应，可以保护响应程序不受I1数据包重放的影响。通过R1中包含的单调递增的“R1生成计数器”，保护启动器不受R1重放的影响。通过谜题机制（见上文第4.1.1节）和不透明数据的可选使用，可以保护响应者不受伪造I2数据包重放的影响。通过在HIP签名验证之前使用成本较低的HMAC验证，可以防止主机重播R2数据包和更新。
The R1 generation counter is a monotonically increasing 64-bit counter that may be initialized to any value. The scope of the counter MAY be system-wide, but there SHOULD be a separate counter for each Host Identity, if there is more than one local Host Identity. The value of this counter SHOULD be preserved across system reboots and invocations of the HIP base exchange. This counter indicates the current generation of puzzles. Implementations MUST accept puzzles from the current generation and MAY accept puzzles from earlier generations. A system's local counter MUST be
R1生成计数器是一个单调递增的64位计数器，可以初始化为任何值。计数器的作用域可以是系统范围，但如果有多个本地主机标识，则每个主机标识都应该有一个单独的计数器。此计数器的值应在系统重新启动和调用HIP base exchange期间保留。此计数器表示当前一代拼图。实现必须接受当前一代的谜题，也可以接受前几代的谜题。系统的本地计数器必须是
incremented at least as often as every time old R1s cease to be valid. The local counter SHOULD never be decremented; otherwise, the host exposes its peers to the replay of previously generated, higher-numbered R1s.
每次旧R1s不再有效时，至少增加一次。本地计数器不应递减；否则，主机会将其对等机暴露给先前生成的、编号较高的R1s的重播。
A host may receive more than one R1, either due to sending multiple I1 packets (see Section 6.6.1) or due to a replay of an old R1. When sending multiple I1 packets to the same host, an Initiator SHOULD wait for a small amount of time (a reasonable time may be 2 * expected RTT) after the first R1 reception to allow possibly multiple R1s to arrive, and it SHOULD respond to an R1 among the set with the largest R1 generation counter. If an Initiator is processing an R1 or has already sent an I2 packet (still waiting for the R2 packet) and it receives another R1 with a larger R1 generation counter, it MAY elect to restart R1 processing with the fresher R1, as if it were the first R1 to arrive.
由于发送多个I1数据包（见第6.6.1节）或由于旧R1的重播，主机可能会收到多个R1。当向同一主机发送多个I1数据包时，启动器应在第一次R1接收后等待一小段时间（合理时间可能为2*预期RTT），以允许可能多个R1到达，并且应响应具有最大R1生成计数器的集合中的R1。如果启动器正在处理R1或已经发送了I2数据包（仍在等待R2数据包），并且它接收到另一个具有更大R1生成计数器的R1，则它可以选择使用更新的R1重新启动R1处理，就像它是第一个到达的R1一样。
The R1 generation counter may roll over or may become reset. It is important for an Initiator to be robust to the loss of state about the R1 generation counter of a peer or to a reset of the peer's counter. It is recommended that, when choosing between multiple R1s, the Initiator prefer to use the R1 that corresponds to the current R1 generation counter, but that if it is unable to make progress with that R1, the Initiator may try the other R1s, beginning with the R1 packet with the highest counter.
R1生成计数器可能会翻滚或复位。重要的是，启动器对对等机的R1生成计数器的状态丢失或对等机计数器的重置具有鲁棒性。建议在多个R1之间进行选择时，发起者优先使用与当前R1生成计数器相对应的R1，但如果无法使用该R1，发起者可以尝试其他R1，从计数器最高的R1数据包开始。
A HIP-aware host may choose not to accept a HIP base exchange. If the host's policy is to only be an Initiator and policy allows the establishment of a HIP association with the original Initiator, it should begin its own HIP base exchange. A host MAY choose to have such a policy since only the privacy of the Initiator's HI is protected in the exchange. It should be noted that such behavior can introduce the risk of a race condition if each host's policy is to only be an Initiator, at which point the HIP base exchange will fail.
HIP感知主机可以选择不接受HIP-base交换。如果主机的策略仅为启动器，并且策略允许与原始启动器建立HIP关联，则应开始其自己的HIP基础交换。主机可以选择使用这样的策略，因为只有启动器HI的隐私在exchange中受到保护。应该注意的是，如果每个主机的策略仅为启动器，则此类行为可能会引入竞争条件的风险，此时HIP-base交换将失败。
If the host's policy does not permit it to enter into a HIP exchange with the Initiator, it should send an ICMP 'Destination Unreachable, Administratively Prohibited' message. A more complex HIP packet is not used here as it actually opens up more potential DoS attacks than a simple ICMP message. A HIP NOTIFY message is not used because no HIP association exists between the two hosts at that time.
如果主机的策略不允许其与启动器进行HIP交换，则应发送ICMP“目的地不可访问，管理禁止”消息。这里不使用更复杂的HIP数据包，因为它实际上比简单的ICMP消息打开更多潜在的DoS攻击。未使用HIP NOTIFY消息，因为当时两台主机之间不存在HIP关联。
Two HIP hosts may encounter situations in which they cannot complete a HIP base exchange because of insufficient support for cryptographic algorithms, in particular the HIT Suites and DH groups. After receiving the R1 packet, the Initiator can determine whether the Responder supports the required cryptographic operations to successfully establish a HIP association. The Initiator can abort the BEX silently after receiving an R1 packet that indicates an unsupported set of algorithms. The specific conditions are described below.
两个HIP主机可能会遇到这样的情况，即由于对加密算法（尤其是HIT套件和DH组）的支持不足，它们无法完成HIP基址交换。在接收到R1数据包后，发起方可以确定响应方是否支持成功建立HIP关联所需的加密操作。在接收到指示不受支持的算法集的R1数据包后，启动器可以静默中止BEX。具体条件如下所述。
The R1 packet contains a signed list of HIT Suite IDs as supported by the Responder. Therefore, the Initiator can determine whether its source HIT is supported by the Responder. If the HIT Suite ID of the Initiator's HIT is not contained in the list of HIT Suites in the R1, the Initiator MAY abort the handshake silently or MAY restart the handshake with a new I1 packet that contains a source HIT supported by the Responder.
R1数据包包含响应程序支持的HIT套件ID的签名列表。因此，发起方可以确定响应方是否支持其源命中。如果发起者的HIT的HIT套件ID不包含在R1中的HIT套件列表中，则发起者可以无声地中止握手，或者可以使用包含响应者支持的源HIT的新I1数据包重新启动握手。
During the handshake, the Initiator and the Responder agree on a single DH group. The Responder selects the DH group and its DH public value in the R1 based on the list of DH Group IDs in the I1 packet. If the Responder supports none of the DH groups requested by the Initiator, the Responder selects an arbitrary DH and replies with an R1 containing its list of supported DH Group IDs. In such a case, the Initiator receives an R1 packet containing the DH public value for an unrequested DH group and also the Responder's DH group list in the signed part of the R1 packet. At this point, the Initiator MAY abort the handshake or MAY restart the handshake by sending a new I1 packet containing a selection of DH Group IDs that is supported by the Responder.
在握手过程中，发起者和响应者就单个DH组达成一致。响应者基于I1分组中的DH组id列表选择R1中的DH组及其DH公共值。如果响应者不支持发起者请求的DH组，则响应者选择任意DH并使用包含其支持的DH组ID列表的R1进行响应。在这种情况下，发起方接收包含未请求DH组的DH公共值的R1分组，以及R1分组的签名部分中的响应方的DH组列表。此时，发起方可中止握手或通过发送包含响应方支持的DH组id的选择的新I1分组来重新开始握手。
In a downgrade attack, an attacker attempts to unnoticeably manipulate the packets of an Initiator and/or a Responder to influence the result of the cryptographic negotiations in the BEX in its favor. As a result, the victims select weaker cryptographic algorithms than they would otherwise have selected without the attacker's interference. Downgrade attacks can only be successful if they remain undetected by the victims and the victims falsely assume a secure communication channel.
在降级攻击中，攻击者试图不知不觉地操纵发起方和/或响应方的数据包，以影响BEX中对其有利的加密协商结果。因此，受害者选择的加密算法比他们在没有攻击者干扰的情况下选择的加密算法要弱。只有当降级攻击未被受害者发现并且受害者错误地使用了安全的通信通道时，降级攻击才能成功。
In HIP, almost all packet parameters related to cryptographic negotiations are covered by signatures. These parameters cannot be directly manipulated in a downgrade attack without invalidating the signature. However, signed packets can be subject to replay attacks.
在HIP中，几乎所有与加密协商相关的数据包参数都由签名覆盖。在降级攻击中，如果不使签名无效，则无法直接操纵这些参数。但是，签名的数据包可能会受到重播攻击。
In such a replay attack, the attacker could use an old BEX packet with an outdated and weak selection of cryptographic algorithms and replay it instead of a more recent packet with a collection of stronger cryptographic algorithms. Signed packets that could be subject to this replay attack are the R1 and I2 packet. However, replayed R1 and I2 packets cannot be used to successfully establish a HIP BEX because these packets also contain the public DH values of the Initiator and the Responder. Old DH values from replayed packets lead to invalid keying material and mismatching shared secrets because the attacker is unable to derive valid keying material from the DH public keys in the R1 and cannot generate a valid HMAC and signature for a replayed I2.
在这种重放攻击中，攻击者可以使用一个旧的BEX数据包，该数据包具有过时且较弱的加密算法选择，并重放该数据包，而不是使用一组更强的加密算法重放较新的数据包。可能受到此重播攻击的签名数据包是R1和I2数据包。但是，回放的R1和I2数据包不能用于成功建立HIP BEX，因为这些数据包还包含发起方和响应方的公共DH值。由于攻击者无法从R1中的DH公钥获取有效的密钥材料，并且无法为重播的I2生成有效的HMAC和签名，因此重播数据包中的旧DH值会导致无效的密钥材料和不匹配的共享机密。
In contrast to the first version of HIP [RFC5201], version 2 of HIP as defined in this document begins the negotiation of the DH groups already in the first BEX packet, the I1. The I1 packet is, by intention, not protected by a signature, to avoid CPU-intensive cryptographic operations processing floods of I1 packets targeted at the Responder. Hence, the list of DH Group IDs in the I1 packet is vulnerable to forgery and manipulation. To thwart an unnoticed manipulation of the I1 packet, the Responder chooses the DH group deterministically and includes its own list of DH Group IDs in the signed part of the R1 packet. The Initiator can detect an attempted downgrade attack by comparing the list of DH Group IDs in the R1 packet to its own preferences in the I1 packet. If the choice of the DH group in the R1 packet does not equal the best match of the two lists (the highest-priority DH ID of the Responder that is present in the Initiator's DH list), the Initiator can conclude that its list in the I1 packet was altered by an attacker. In this case, the Initiator can restart or abort the BEX. As mentioned before, the detection of the downgrade attack is sufficient to prevent it.
与HIP[RFC5201]的第一个版本不同，本文件中定义的HIP版本2开始协商第一个BEX数据包（I1）中已经存在的DH组。I1分组有意不受签名保护，以避免CPU密集型加密操作处理针对响应者的I1分组洪水。因此，I1数据包中的DH组id列表容易被伪造和操纵。为了阻止对I1分组的未被注意的操纵，响应者确定地选择DH组，并在R1分组的签名部分中包括其自己的DH组id列表。发起方可以通过将R1数据包中的DH组ID列表与I1数据包中自己的首选项进行比较来检测试图进行的降级攻击。如果R1数据包中DH组的选择不等于两个列表中的最佳匹配（启动器的DH列表中存在的响应程序的最高优先级DH ID），则启动器可以断定其在I1数据包中的列表已被攻击者更改。在这种情况下，启动器可以重新启动或中止BEX。如前所述，降级攻击的检测足以防止它。
It is possible to initiate a HIP BEX even if the Responder's HI (and HIT) is unknown. In this case, the initial I1 packet contains all zeros as the destination HIT. This kind of connection setup is called opportunistic mode.
即使响应者的HI（和HIT）未知，也可以启动HIP BEX。在这种情况下，初始I1数据包包含所有零作为目标命中。这种连接设置称为机会主义模式。
The Responder may have multiple HITs due to multiple supported HIT Suites. Since the Responder's HIT Suite in the opportunistic mode is not determined by the destination HIT of the I1 packet, the Responder can freely select a HIT of any HIT Suite. The complete set of HIT Suites supported by the Initiator is not known to the Responder. Therefore, the Responder SHOULD select its HIT from the same HIT Suite as the Initiator's HIT (indicated by the HIT Suite information in the OGA ID field of the Initiator's HIT) because this HIT Suite is obviously supported by the Initiator. If the Responder selects a
由于支持多个命中套件，响应者可能有多个命中。由于响应者在机会主义模式下的命中套件不是由I1数据包的目标命中决定的，因此响应者可以自由选择任何命中套件的命中。响应者不知道启动器支持的完整HIT套件集。因此，响应者应该从与启动器的HIT相同的HIT套件中选择其HIT（由启动器HIT的OGA ID字段中的HIT套件信息指示），因为启动器显然支持此HIT套件。如果响应者选择
different HIT that is not supported by the Initiator, the Initiator MAY restart the BEX with an I1 packet with a source HIT that is contained in the list of the Responder's HIT Suites in the R1 packet.
发起方不支持的不同命中，发起方可使用包含在R1数据包中响应方命中套件列表中的源命中的I1数据包重新启动BEX。
Note that the Initiator cannot verify the signature of the R1 packet if the Responder's HIT Suite is not supported. Therefore, the Initiator MUST treat R1 packets with unsupported Responder HITs as potentially forged and MUST NOT use any parameters from the unverified R1 besides the HIT_SUITE_LIST. Moreover, an Initiator that uses an unverified HIT_SUITE_LIST from an R1 packet to determine a possible source HIT MUST verify that the HIT_SUITE_LIST in the first unverified R1 packet matches the HIT_SUITE_LIST in the second R1 packet for which the Initiator supports the signature algorithm. The Initiator MUST restart the BEX with a new I1 packet for which the algorithm was mentioned in the verifiable R1 if the two lists do not match. This procedure is necessary to mitigate downgrade attacks.
请注意，如果响应程序的HIT套件不受支持，则发起程序无法验证R1数据包的签名。因此，启动器必须将具有不受支持响应程序命中的R1数据包视为潜在伪造数据包，并且不得使用来自未验证R1的任何参数（除了命中套件列表）。此外，使用来自R1数据包的未验证命中套件列表来确定可能的源命中的启动器必须验证第一个未验证R1数据包中的命中套件列表与启动器支持签名算法的第二个R1数据包中的命中套件列表相匹配。如果两个列表不匹配，则启动器必须使用可验证R1中提到的算法的新I1数据包重新启动BEX。此过程对于缓解降级攻击是必要的。
There are both security and API issues involved with the opportunistic mode. These issues are described in the remainder of this section.
机会主义模式涉及到安全性和API问题。这些问题将在本节的其余部分中描述。
Given that the Responder's HI is not known by the Initiator, there must be suitable API calls that allow the Initiator to request, directly or indirectly, that the underlying system initiates the HIP base exchange solely based on locators. The Responder's HI will be tentatively available in the R1 packet, and in an authenticated form once the R2 packet has been received and verified. Hence, the Responder's HIT could be communicated to the application via new API mechanisms. However, with a backwards-compatible API the application sees only the locators used for the initial contact. Depending on the desired semantics of the API, this can raise the following issues:
鉴于发起者不知道响应者的HI，必须有合适的API调用，允许发起者直接或间接请求底层系统仅基于定位器发起HIP-base交换。响应者的HI将暂时在R1数据包中可用，并且在R2数据包被接收和验证后以经过身份验证的形式可用。因此，响应者的命中可以通过新的API机制传递给应用程序。但是，使用向后兼容的API，应用程序只能看到用于初始接触的定位器。根据API所需的语义，这可能会引发以下问题：
o The actual locators may later change if an UPDATE message is used, even if from the API perspective the association still appears to be between two specific locators. However, the locator update is still secure, and the association is still between the same nodes.
o 如果使用了更新消息，则实际的定位器稍后可能会更改，即使从API的角度来看，关联仍然出现在两个特定定位器之间。但是，定位器更新仍然是安全的，并且关联仍然在相同的节点之间。
o Different associations between the same two locators may result in connections to different nodes, if the implementation no longer remembers which identifier the peer had in an earlier association. This is possible when the peer's locator has changed for legitimate reasons or when an attacker pretends to be a node that has the peer's locator. Therefore, when using opportunistic mode, HIP implementations MUST NOT place any expectation that the peer's HI returned in the R1 message matches any HI previously seen from that address.
o 相同两个定位器之间的不同关联可能会导致连接到不同的节点，如果实现不再记住对等方在早期关联中拥有的标识符。当对等方的定位器因合法原因发生更改时，或者当攻击者假装是拥有对等方定位器的节点时，这是可能的。因此，当使用机会主义模式时，HIP实现不得期望R1消息中返回的对等HI与之前从该地址看到的任何HI匹配。
If the HIP implementation and application do not have the same understanding of what constitutes an association, this may even happen within the same association. For instance, an implementation may not know when HIP state can be purged for UDP-based applications.
如果HIP实现和应用程序对什么构成关联没有相同的理解，那么这甚至可能发生在同一关联中。例如，实现可能不知道何时可以清除基于UDP的应用程序的HIP状态。
In addition, the following security considerations apply. The generation counter mechanism will be less efficient in protecting against replays of the R1 packet, given that the Responder can choose a replay that uses an arbitrary HI, not just the one given in the I1 packet.
此外，以下安全注意事项适用。鉴于响应者可以选择使用任意HI的重播，而不仅仅是I1数据包中给出的重播，因此生成计数器机制在防止R1数据包重播方面的效率将较低。
More importantly, the opportunistic exchange is vulnerable to man-in-the-middle attacks, because the Initiator does not have any public key information about the peer. To assess the impacts of this vulnerability, we compare it to vulnerabilities in current, non-HIP-capable communications.
更重要的是，机会主义交换容易受到中间人攻击，因为发起方没有任何关于对等方的公钥信息。为了评估此漏洞的影响，我们将其与当前不支持HIP的通信中的漏洞进行比较。
An attacker on the path between the two peers can insert itself as a man-in-the-middle by providing its own identifier to the Initiator and then initiating another HIP association towards the Responder. For this to be possible, the Initiator must employ opportunistic mode, and the Responder must be configured to accept a connection from any HIP-enabled node.
在两个对等方之间的路径上的攻击者可以通过向发起方提供自己的标识符，然后向响应方发起另一个髋部关联，从而将自己作为中间人插入。为了实现这一点，发起方必须采用机会主义模式，并且响应方必须配置为接受来自任何支持HIP的节点的连接。
An attacker outside the path will be unable to do so, given that it cannot respond to the messages in the base exchange.
路径之外的攻击者将无法这样做，因为它无法响应基本exchange中的消息。
These security properties are characteristic also of communications in the current Internet. A client contacting a server without employing end-to-end security may find itself talking to the server via a man-in-the-middle, assuming again that the server is willing to talk to anyone.
这些安全属性也是当前互联网通信的特征。在没有使用端到端安全性的情况下与服务器联系的客户端可能会发现自己通过中间的人与服务器交谈，再次假设服务器愿意与任何人交谈。
If end-to-end security is in place, then the worst that can happen in both the opportunistic HIP and non-HIP (normal IP) cases is denial-of-service; an entity on the path can disrupt communications, but will be unable to successfully insert itself as a man-in-the-middle.
如果存在端到端安全，那么在机会主义HIP和非HIP（正常IP）情况下可能发生的最坏情况是拒绝服务；路径上的实体可以中断通信，但无法成功地将自身作为中间人插入。
However, once the opportunistic exchange has successfully completed, HIP provides confidentiality and integrity protection for the communications, and can securely change the locators of the endpoints.
但是，一旦机会主义交换成功完成，HIP将为通信提供机密性和完整性保护，并且可以安全地更改端点的定位器。
As a result, opportunistic mode in HIP offers a "better than nothing" security model. Initially, a base exchange authenticated in the opportunistic mode involves a leap of faith subject to man-in-the-middle attacks, but subsequent datagrams related to the same HIP
因此，HIP中的机会主义模式提供了一种“总比没有好”的安全模型。最初，在机会主义模式下进行身份验证的基础交换涉及到中间人攻击下的信仰飞跃，但随后的数据报与同一个HIP相关
association cannot be compromised by a new man-in-the-middle attack. Further, if the man-in-the-middle moves away from the path of the active association, the attack would be exposed after the fact. Thus, it can be stated that opportunistic mode in HIP is at least as secure as unprotected IP-based communications.
新的中间人攻击无法破坏关联。此外，如果中间的人离开活动关联的路径，攻击将在事后暴露。因此，可以说HIP中的机会主义模式至少与基于IP的无保护通信一样安全。
A HIP association between two hosts may need to be updated over time. Examples include the need to rekey expiring security associations, add new security associations, or change IP addresses associated with hosts. The UPDATE packet is used for those and other similar purposes. This document only specifies the UPDATE packet format and basic processing rules, with mandatory parameters. The actual usage is defined in separate specifications.
两台主机之间的HIP关联可能需要随时间更新。例如，需要为即将过期的安全关联重新设置密钥、添加新的安全关联或更改与主机关联的IP地址。更新包用于这些和其他类似目的。本文档仅指定更新数据包格式和基本处理规则，并带有强制性参数。实际使用在单独的规范中定义。
HIP provides a general-purpose UPDATE packet, which can carry multiple HIP parameters, for updating the HIP state between two peers. The UPDATE mechanism has the following properties:
HIP提供了一个通用更新包，可以携带多个HIP参数，用于更新两个对等方之间的HIP状态。更新机制具有以下属性：
UPDATE messages carry a monotonically increasing sequence number and are explicitly acknowledged by the peer. Lost UPDATEs or acknowledgments may be recovered via retransmission. Multiple UPDATE messages may be outstanding under certain circumstances.
更新消息携带单调递增的序列号，并由对等方明确确认。丢失的更新或确认可以通过重新传输来恢复。在某些情况下，多条更新消息可能未处理。
UPDATE is protected by both HIP_MAC and HIP_SIGNATURE parameters, since processing UPDATE signatures alone is a potential DoS attack against intermediate systems.
更新受HIP_MAC和HIP_签名参数的保护，因为单独处理更新签名是对中间系统的潜在DoS攻击。
UPDATE packets are explicitly acknowledged by the use of an acknowledgment parameter that echoes an individual sequence number received from the peer. A single UPDATE packet may contain both a sequence number and one or more acknowledgment numbers (i.e., piggybacked acknowledgment(s) for the peer's UPDATE).
通过使用回显从对等方接收的单个序列号的确认参数来明确确认更新数据包。单个更新数据包可能包含序列号和一个或多个确认号（即，对等方更新的附带确认）。
The UPDATE packet is defined in Section 5.3.5.
更新包在第5.3.5节中定义。
HIP error processing behavior depends on whether or not there exists an active HIP association. In general, if a HIP association exists between the sender and receiver of a packet causing an error condition, the receiver SHOULD respond with a NOTIFY packet. On the other hand, if there are no existing HIP associations between the sender and receiver, or the receiver cannot reasonably determine the identity of the sender, the receiver MAY respond with a suitable ICMP message; see Section 5.4 for more details.
髋部错误处理行为取决于是否存在活跃的髋部关联。通常，如果数据包的发送方和接收方之间存在HIP关联，导致出现错误情况，则接收方应使用NOTIFY数据包进行响应。另一方面，如果发送方和接收方之间不存在HIP关联，或者接收方不能合理地确定发送方的身份，则接收方可以使用合适的ICMP消息进行响应；详见第5.4节。
The HIP protocol and state machine are designed to recover from one of the parties crashing and losing its state. The following scenarios describe the main use cases covered by the design.
HIP协议和状态机旨在从其中一方崩溃并失去其状态中恢复。以下场景描述了设计所涵盖的主要用例。
No prior state between the two systems.
两个系统之间没有先前的状态。
The system with data to send is the Initiator. The process follows the standard four-packet base exchange, establishing the HIP association.
要发送数据的系统是启动器。该过程遵循标准的四包基本交换，建立HIP关联。
The system with data to send has no state with the receiver, but the receiver has a residual HIP association.
具有要发送的数据的系统与接收器没有状态，但接收器具有剩余的HIP关联。
The system with data to send is the Initiator. The Initiator acts as in no prior state, sending an I1 packet and receiving an R1 packet. When the Responder receives a valid I2 packet, the old association is 'discovered' and deleted, and the new association is established.
要发送数据的系统是启动器。发起方的行为与无优先状态相同，发送I1数据包并接收R1数据包。当响应者接收到有效的I2数据包时，旧关联被“发现”并删除，新关联被建立。
The system with data to send has a HIP association, but the receiver does not.
要发送数据的系统具有HIP关联，但接收器没有。
The system sends data on the outbound user data security association. The receiver 'detects' the situation when it receives a user data packet that it cannot match to any HIP association. The receiving host MUST discard this packet.
系统在出站用户数据安全关联上发送数据。接收器在接收到无法与任何HIP关联匹配的用户数据包时“检测”情况。接收主机必须丢弃此数据包。
The receiving host SHOULD send an ICMP packet, with the type Parameter Problem, to inform the sender that the HIP association does not exist (see Section 5.4), and it MAY initiate a new HIP BEX. However, responding with these optional mechanisms is implementation or policy dependent. If the sending application doesn't expect a response, the system could possibly send a large number of packets in this state, so for this reason, the sending of one or more ICMP packets is RECOMMENDED. However, any such responses MUST be rate-limited to prevent abuse (see Section 5.4).
接收主机应发送一个带有类型参数问题的ICMP数据包，通知发送方HIP关联不存在（见第5.4节），并且它可能会启动一个新的HIP BEX。但是，使用这些可选机制进行响应取决于实现或策略。如果发送应用程序不期望响应，则系统可能会在此状态下发送大量数据包，因此，出于此原因，建议发送一个或多个ICMP数据包。但是，任何此类回复都必须受到费率限制，以防止滥用（见第5.4节）。
HIP itself has little state. In the HIP base exchange, there is an Initiator and a Responder. Once the security associations (SAs) are established, this distinction is lost. If the HIP state needs to be re-established, the controlling parameters are which peer still has state and which has a datagram to send to its peer. The following state machine attempts to capture these processes.
HIP本身几乎没有状态。在HIP base exchange中，有一个启动器和一个响应器。一旦建立了安全关联（SA），这种区别就消失了。如果需要重新建立HIP状态，那么控制参数是哪个对等方仍然有状态，哪个有数据报要发送给它的对等方。以下状态机试图捕获这些进程。
The state machine is symmetric and is presented in a single system view, representing either an Initiator or a Responder. The state machine is not a full representation of the processing logic. Additional processing rules are presented in the packet definitions. Hence, both are needed to completely implement HIP.
状态机是对称的，在单个系统视图中显示，表示发起方或响应方。状态机不是处理逻辑的完整表示。数据包定义中提供了其他处理规则。因此，完全实现HIP需要两者。
This document extends the state machine as defined in [RFC5201] and introduces a restart option to allow for the negotiation of cryptographic algorithms. The extension to the previous state machine in [RFC5201] is a transition from state I1-SENT back again to I1-SENT; namely, the restart option. An Initiator is required to restart the HIP base exchange if the Responder does not support the HIT Suite of the Initiator. In this case, the Initiator restarts the HIP base exchange by sending a new I1 packet with a source HIT supported by the Responder.
本文档扩展了[RFC5201]中定义的状态机，并引入了重新启动选项，以允许协商加密算法。[RFC5201]中对前一状态机的扩展是从状态I1-SENT再次转换回状态I1-SENT；即重新启动选项。如果响应程序不支持启动器的HIT套件，则需要启动器重新启动HIP base exchange。在这种情况下，发起者通过发送一个新的I1数据包以及响应者支持的源命中来重新启动HIP-base交换。
Implementors must understand that the state machine, as described here, is informational. Specific implementations are free to implement the actual processing logic differently. Section 6 describes the packet processing rules in more detail. This state machine focuses on the HIP I1, R1, I2, and R2 packets only. New states and state transitions may be introduced by mechanisms in other specifications (such as mobility and multihoming).
实现者必须理解，如本文所述，状态机是信息性的。特定的实现可以自由地以不同的方式实现实际的处理逻辑。第6节更详细地描述了数据包处理规则。此状态机仅关注HIP I1、R1、I2和R2数据包。其他规范中的机制（如移动性和多归属）可能会引入新的状态和状态转换。
Unused Association Lifetime (UAL): Implementation-specific time for which, if no packet is sent or received for this time interval, a host MAY begin to tear down an active HIP association.
未使用关联生存期（UAL）：特定于实现的时间，在此时间间隔内，如果没有发送或接收数据包，主机可能会开始中断活动HIP关联。
Maximum Segment Lifetime (MSL): Maximum time that a HIP packet is expected to spend in the network. A default value of 2 minutes has been borrowed from [RFC0793] because it is a prevailing assumption for packet lifetimes.
最大段生存期（MSL）：HIP数据包预计在网络中花费的最大时间。从[RFC0793]借用了2分钟的默认值，因为这是数据包寿命的普遍假设。
Exchange Complete (EC): Time that the host spends at the R2-SENT state before it moves to the ESTABLISHED state. The time is n * I2 retransmission timeout, where n is about I2_RETRIES_MAX.
Exchange Complete（EC）：主机在移动到已建立状态之前处于R2-SENT状态的时间。时间为n*I2重传超时，其中n约为I2_重试次数的最大值。
Receive ANYOTHER: Any received packet for which no state transitions or processing rules are defined for a given state.
Receive ANYOTHER：没有为给定状态定义状态转换或处理规则的任何接收数据包。
+---------------------+---------------------------------------------+
| State | Explanation |
+---------------------+---------------------------------------------+
| UNASSOCIATED | State machine start |
| | |
| I1-SENT | Initiating base exchange |
| | |
| I2-SENT | Waiting to complete base exchange |
| | |
| R2-SENT | Waiting to complete base exchange |
| | |
| ESTABLISHED | HIP association established |
| | |
| CLOSING | HIP association closing, no data can be |
| | sent |
| | |
| CLOSED | HIP association closed, no data can be sent |
| | |
| E-FAILED | HIP base exchange failed |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| State | Explanation |
+---------------------+---------------------------------------------+
| UNASSOCIATED | State machine start |
| | |
| I1-SENT | Initiating base exchange |
| | |
| I2-SENT | Waiting to complete base exchange |
| | |
| R2-SENT | Waiting to complete base exchange |
| | |
| ESTABLISHED | HIP association established |
| | |
| CLOSING | HIP association closing, no data can be |
| | sent |
| | |
| CLOSED | HIP association closed, no data can be sent |
| | |
| E-FAILED | HIP base exchange failed |
+---------------------+---------------------------------------------+
Table 1: HIP States
表1：髋关节状态
System behavior in state UNASSOCIATED, Table 2.
未关联状态下的系统行为，表2。
+----------------------------+--------------------------------------+
| Trigger | Action |
+----------------------------+--------------------------------------+
| User data to send, | Send I1 and go to I1-SENT |
| requiring a new HIP | |
| association | |
| | |
| Receive I1 | Send R1 and stay at UNASSOCIATED |
| | |
| Receive I2, process | If successful, send R2 and go to |
| | R2-SENT |
| | |
| | If fail, stay at UNASSOCIATED |
| | |
| Receive user data for an | Optionally send ICMP as defined in |
| unknown HIP association | Section 5.4 and stay at UNASSOCIATED |
| | |
| Receive CLOSE | Optionally send ICMP Parameter |
| | Problem and stay at UNASSOCIATED |
| | |
| Receive ANYOTHER | Drop and stay at UNASSOCIATED |
+----------------------------+--------------------------------------+
+----------------------------+--------------------------------------+
| Trigger | Action |
+----------------------------+--------------------------------------+
| User data to send, | Send I1 and go to I1-SENT |
| requiring a new HIP | |
| association | |
| | |
| Receive I1 | Send R1 and stay at UNASSOCIATED |
| | |
| Receive I2, process | If successful, send R2 and go to |
| | R2-SENT |
| | |
| | If fail, stay at UNASSOCIATED |
| | |
| Receive user data for an | Optionally send ICMP as defined in |
| unknown HIP association | Section 5.4 and stay at UNASSOCIATED |
| | |
| Receive CLOSE | Optionally send ICMP Parameter |
| | Problem and stay at UNASSOCIATED |
| | |
| Receive ANYOTHER | Drop and stay at UNASSOCIATED |
+----------------------------+--------------------------------------+
Table 2: UNASSOCIATED - Start State
表2：未关联-启动状态
System behavior in state I1-SENT, Table 3.
状态I1-SENT下的系统行为，表3。
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 from | If the local HIT is smaller than the peer |
| Responder | HIT, drop I1 and stay at I1-SENT (see |
| | Section 6.5 for HIT comparison) |
| | |
| | If the local HIT is greater than the peer |
| | HIT, send R1 and stay at I1-SENT |
| | |
| Receive I2, process | If successful, send R2 and go to R2-SENT |
| | |
| | If fail, stay at I1-SENT |
| | |
| Receive R1, process | If the HIT Suite of the local HIT is not |
| | supported by the peer, select supported |
| | local HIT, send I1, and stay at I1-SENT |
| | |
| | If successful, send I2 and go to I2-SENT |
| | |
| | If fail, stay at I1-SENT |
| | |
| Receive ANYOTHER | Drop and stay at I1-SENT |
| | |
| Timeout | Increment trial counter |
| | |
| | If counter is less than I1_RETRIES_MAX, |
| | send I1 and stay at I1-SENT |
| | |
| | If counter is greater than I1_RETRIES_MAX, |
| | go to E-FAILED |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 from | If the local HIT is smaller than the peer |
| Responder | HIT, drop I1 and stay at I1-SENT (see |
| | Section 6.5 for HIT comparison) |
| | |
| | If the local HIT is greater than the peer |
| | HIT, send R1 and stay at I1-SENT |
| | |
| Receive I2, process | If successful, send R2 and go to R2-SENT |
| | |
| | If fail, stay at I1-SENT |
| | |
| Receive R1, process | If the HIT Suite of the local HIT is not |
| | supported by the peer, select supported |
| | local HIT, send I1, and stay at I1-SENT |
| | |
| | If successful, send I2 and go to I2-SENT |
| | |
| | If fail, stay at I1-SENT |
| | |
| Receive ANYOTHER | Drop and stay at I1-SENT |
| | |
| Timeout | Increment trial counter |
| | |
| | If counter is less than I1_RETRIES_MAX, |
| | send I1 and stay at I1-SENT |
| | |
| | If counter is greater than I1_RETRIES_MAX, |
| | go to E-FAILED |
+---------------------+---------------------------------------------+
Table 3: I1-SENT - Initiating the HIP Base Exchange
表3:I1-SENT-启动HIP-Base交换
System behavior in state I2-SENT, Table 4.
I2-SENT状态下的系统行为，表4。
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay at I2-SENT |
| | |
| Receive R1, process | If successful, send I2 and stay at I2-SENT |
| | |
| | If fail, stay at I2-SENT |
| | |
| Receive I2, process | If successful and local HIT is smaller than |
| | the peer HIT, drop I2 and stay at I2-SENT |
| | |
| | If successful and local HIT is greater than |
| | the peer HIT, send R2 and go to R2-SENT |
| | |
| | If fail, stay at I2-SENT |
| | |
| Receive R2, process | If successful, go to ESTABLISHED |
| | |
| | If fail, stay at I2-SENT |
| | |
| Receive CLOSE, | If successful, send CLOSE_ACK and go to |
| process | CLOSED |
| | |
| | If fail, stay at I2-SENT |
| | |
| Receive ANYOTHER | Drop and stay at I2-SENT |
| | |
| Timeout | Increment trial counter |
| | |
| | If counter is less than I2_RETRIES_MAX, |
| | send I2 and stay at I2-SENT |
| | |
| | If counter is greater than I2_RETRIES_MAX, |
| | go to E-FAILED |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay at I2-SENT |
| | |
| Receive R1, process | If successful, send I2 and stay at I2-SENT |
| | |
| | If fail, stay at I2-SENT |
| | |
| Receive I2, process | If successful and local HIT is smaller than |
| | the peer HIT, drop I2 and stay at I2-SENT |
| | |
| | If successful and local HIT is greater than |
| | the peer HIT, send R2 and go to R2-SENT |
| | |
| | If fail, stay at I2-SENT |
| | |
| Receive R2, process | If successful, go to ESTABLISHED |
| | |
| | If fail, stay at I2-SENT |
| | |
| Receive CLOSE, | If successful, send CLOSE_ACK and go to |
| process | CLOSED |
| | |
| | If fail, stay at I2-SENT |
| | |
| Receive ANYOTHER | Drop and stay at I2-SENT |
| | |
| Timeout | Increment trial counter |
| | |
| | If counter is less than I2_RETRIES_MAX, |
| | send I2 and stay at I2-SENT |
| | |
| | If counter is greater than I2_RETRIES_MAX, |
| | go to E-FAILED |
+---------------------+---------------------------------------------+
Table 4: I2-SENT - Waiting to Finish the HIP Base Exchange
表4:I2-SENT-等待完成HIP-Base交换
System behavior in state R2-SENT, Table 5.
R2-SENT状态下的系统行为，表5。
+------------------------+------------------------------------------+
| Trigger | Action |
+------------------------+------------------------------------------+
| Receive I1 | Send R1 and stay at R2-SENT |
| | |
| Receive I2, process | If successful, send R2 and stay at |
| | R2-SENT |
| | |
| | If fail, stay at R2-SENT |
| | |
| Receive R1 | Drop and stay at R2-SENT |
| | |
| Receive R2 | Drop and stay at R2-SENT |
| | |
| Receive data or UPDATE | Move to ESTABLISHED |
| | |
| Exchange Complete | Move to ESTABLISHED |
| Timeout | |
| | |
| Receive CLOSE, process | If successful, send CLOSE_ACK and go to |
| | CLOSED |
| | |
| | If fail, stay at ESTABLISHED |
| | |
| Receive CLOSE_ACK | Drop and stay at R2-SENT |
| | |
| Receive NOTIFY | Process and stay at R2-SENT |
+------------------------+------------------------------------------+
+------------------------+------------------------------------------+
| Trigger | Action |
+------------------------+------------------------------------------+
| Receive I1 | Send R1 and stay at R2-SENT |
| | |
| Receive I2, process | If successful, send R2 and stay at |
| | R2-SENT |
| | |
| | If fail, stay at R2-SENT |
| | |
| Receive R1 | Drop and stay at R2-SENT |
| | |
| Receive R2 | Drop and stay at R2-SENT |
| | |
| Receive data or UPDATE | Move to ESTABLISHED |
| | |
| Exchange Complete | Move to ESTABLISHED |
| Timeout | |
| | |
| Receive CLOSE, process | If successful, send CLOSE_ACK and go to |
| | CLOSED |
| | |
| | If fail, stay at ESTABLISHED |
| | |
| Receive CLOSE_ACK | Drop and stay at R2-SENT |
| | |
| Receive NOTIFY | Process and stay at R2-SENT |
+------------------------+------------------------------------------+
Table 5: R2-SENT - Waiting to Finish HIP
表5:R2-SENT-等待完成HIP
System behavior in state ESTABLISHED, Table 6.
已建立状态下的系统行为，表6。
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay at ESTABLISHED |
| | |
| Receive I2 | Process with puzzle and possible Opaque |
| | data verification |
| | |
| | If successful, send R2, drop old HIP |
| | association, establish a new HIP |
| | association, and go to R2-SENT |
| | |
| | If fail, stay at ESTABLISHED |
| | |
| Receive R1 | Drop and stay at ESTABLISHED |
| | |
| Receive R2 | Drop and stay at ESTABLISHED |
| | |
| Receive user data | Process and stay at ESTABLISHED |
| for HIP association | |
| | |
| No packet | Send CLOSE and go to CLOSING |
| sent/received | |
| during UAL minutes | |
| | |
| Receive UPDATE | Process and stay at ESTABLISHED |
| | |
| Receive CLOSE, | If successful, send CLOSE_ACK and go to |
| process | CLOSED |
| | |
| | If fail, stay at ESTABLISHED |
| | |
| Receive CLOSE_ACK | Drop and stay at ESTABLISHED |
| | |
| Receive NOTIFY | Process and stay at ESTABLISHED |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay at ESTABLISHED |
| | |
| Receive I2 | Process with puzzle and possible Opaque |
| | data verification |
| | |
| | If successful, send R2, drop old HIP |
| | association, establish a new HIP |
| | association, and go to R2-SENT |
| | |
| | If fail, stay at ESTABLISHED |
| | |
| Receive R1 | Drop and stay at ESTABLISHED |
| | |
| Receive R2 | Drop and stay at ESTABLISHED |
| | |
| Receive user data | Process and stay at ESTABLISHED |
| for HIP association | |
| | |
| No packet | Send CLOSE and go to CLOSING |
| sent/received | |
| during UAL minutes | |
| | |
| Receive UPDATE | Process and stay at ESTABLISHED |
| | |
| Receive CLOSE, | If successful, send CLOSE_ACK and go to |
| process | CLOSED |
| | |
| | If fail, stay at ESTABLISHED |
| | |
| Receive CLOSE_ACK | Drop and stay at ESTABLISHED |
| | |
| Receive NOTIFY | Process and stay at ESTABLISHED |
+---------------------+---------------------------------------------+
Table 6: ESTABLISHED - HIP Association Established
表6：已建立-已建立髋关节协会
System behavior in state CLOSING, Table 7.
关闭状态下的系统行为，表7。
+----------------------------+--------------------------------------+
| Trigger | Action |
+----------------------------+--------------------------------------+
| User data to send, | Send I1 and go to I1-SENT |
| requires the creation of | |
| another incarnation of the | |
| HIP association | |
| | |
| Receive I1 | Send R1 and stay at CLOSING |
| | |
| Receive I2, process | If successful, send R2 and go to |
| | R2-SENT |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive R1, process | If successful, send I2 and go to |
| | I2-SENT |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive CLOSE, process | If successful, send CLOSE_ACK, |
| | discard state, and go to CLOSED |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive CLOSE_ACK, process | If successful, discard state and go |
| | to UNASSOCIATED |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive ANYOTHER | Drop and stay at CLOSING |
| | |
| Timeout | Increment timeout sum and reset |
| | timer. If timeout sum is less than |
| | UAL+MSL minutes, retransmit CLOSE |
| | and stay at CLOSING. |
| | |
| | If timeout sum is greater than |
| | UAL+MSL minutes, go to UNASSOCIATED |
+----------------------------+--------------------------------------+
+----------------------------+--------------------------------------+
| Trigger | Action |
+----------------------------+--------------------------------------+
| User data to send, | Send I1 and go to I1-SENT |
| requires the creation of | |
| another incarnation of the | |
| HIP association | |
| | |
| Receive I1 | Send R1 and stay at CLOSING |
| | |
| Receive I2, process | If successful, send R2 and go to |
| | R2-SENT |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive R1, process | If successful, send I2 and go to |
| | I2-SENT |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive CLOSE, process | If successful, send CLOSE_ACK, |
| | discard state, and go to CLOSED |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive CLOSE_ACK, process | If successful, discard state and go |
| | to UNASSOCIATED |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive ANYOTHER | Drop and stay at CLOSING |
| | |
| Timeout | Increment timeout sum and reset |
| | timer. If timeout sum is less than |
| | UAL+MSL minutes, retransmit CLOSE |
| | and stay at CLOSING. |
| | |
| | If timeout sum is greater than |
| | UAL+MSL minutes, go to UNASSOCIATED |
+----------------------------+--------------------------------------+
Table 7: CLOSING - HIP Association Has Not Been Used for UAL Minutes
表7：闭合-髋关节联合已5分钟未使用
System behavior in state CLOSED, Table 8.
关闭状态下的系统行为，表8。
+----------------------------------------+--------------------------+
| Trigger | Action |
+----------------------------------------+--------------------------+
| Datagram to send, requires the | Send I1 and stay at |
| creation of another incarnation of the | CLOSED |
| HIP association | |
| | |
| Receive I1 | Send R1 and stay at |
| | CLOSED |
| | |
| Receive I2, process | If successful, send R2 |
| | and go to R2-SENT |
| | |
| | If fail, stay at CLOSED |
| | |
| Receive R1, process | If successful, send I2 |
| | and go to I2-SENT |
| | |
| | If fail, stay at CLOSED |
| | |
| Receive CLOSE, process | If successful, send |
| | CLOSE_ACK and stay at |
| | CLOSED |
| | |
| | If fail, stay at CLOSED |
| | |
| Receive CLOSE_ACK, process | If successful, discard |
| | state and go to |
| | UNASSOCIATED |
| | |
| | If fail, stay at CLOSED |
| | |
| Receive ANYOTHER | Drop and stay at CLOSED |
| | |
| Timeout (UAL+2MSL) | Discard state and go to |
| | UNASSOCIATED |
+----------------------------------------+--------------------------+
+----------------------------------------+--------------------------+
| Trigger | Action |
+----------------------------------------+--------------------------+
| Datagram to send, requires the | Send I1 and stay at |
| creation of another incarnation of the | CLOSED |
| HIP association | |
| | |
| Receive I1 | Send R1 and stay at |
| | CLOSED |
| | |
| Receive I2, process | If successful, send R2 |
| | and go to R2-SENT |
| | |
| | If fail, stay at CLOSED |
| | |
| Receive R1, process | If successful, send I2 |
| | and go to I2-SENT |
| | |
| | If fail, stay at CLOSED |
| | |
| Receive CLOSE, process | If successful, send |
| | CLOSE_ACK and stay at |
| | CLOSED |
| | |
| | If fail, stay at CLOSED |
| | |
| Receive CLOSE_ACK, process | If successful, discard |
| | state and go to |
| | UNASSOCIATED |
| | |
| | If fail, stay at CLOSED |
| | |
| Receive ANYOTHER | Drop and stay at CLOSED |
| | |
| Timeout (UAL+2MSL) | Discard state and go to |
| | UNASSOCIATED |
+----------------------------------------+--------------------------+
Table 8: CLOSED - CLOSE_ACK Sent, Resending CLOSE_ACK if Necessary
表8：关闭-发送关闭确认，必要时重新发送关闭确认
System behavior in state E-FAILED, Table 9.
状态E-FAILED下的系统行为，表9。
+-------------------------+-----------------------------------------+
| Trigger | Action |
+-------------------------+-----------------------------------------+
| Wait for | Go to UNASSOCIATED. Renegotiation is |
| implementation-specific | possible after moving to UNASSOCIATED |
| time | state. |
+-------------------------+-----------------------------------------+
+-------------------------+-----------------------------------------+
| Trigger | Action |
+-------------------------+-----------------------------------------+
| Wait for | Go to UNASSOCIATED. Renegotiation is |
| implementation-specific | possible after moving to UNASSOCIATED |
| time | state. |
+-------------------------+-----------------------------------------+
Table 9: E-FAILED - HIP Failed to Establish Association with Peer
表9:E-FAILED-HIP未能与对等方建立关联
The following diagram (Figure 2) shows the major state transitions. Transitions based on received packets implicitly assume that the packets are successfully authenticated or processed.
下图（图2）显示了主要的状态转换。基于接收到的数据包的转换隐式地假定数据包已成功通过身份验证或处理。
+--+ +----------------------------+
recv I1, send R1 | | | |
| v v |
+--------------+ recv I2, send R2 |
+----------------| UNASSOCIATED |----------------+ |
datagram | +--+ +--------------+ | |
to send, | | | Alg. not supported, | |
send I1 | | | send I1 | |
. v | v | |
. +---------+ recv I2, send R2 | |
+---->| I1-SENT |--------------------------------------+ | |
| +---------+ +----------------------+ | | |
| | recv R2, | recv I2, send R2 | | | |
| v send I2 | v v v |
| +---------+ | +---------+ |
| +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ |
| | +---------+ | +---------+ | |
| | | |recv R2 | data or| | |
| |recv R1, | | | EC timeout| | |
| |send I2 +--|-----------------+ | receive I2,| |
| | | | +-------------+ | send R2| |
| | | +------>| ESTABLISHED |<----------+ | |
| | | +-------------+ | |
| | | | | | receive I2, send R2 | |
| | +------------+ | +-------------------------------+ |
| | | +-----------+ | |
| | | no packet sent/received| +---+ | |
| | | for UAL min, send CLOSE| | |timeout | |
| | | v v |(UAL+MSL) | |
| | | +---------+ |retransmit | |
+--|----------|------------------------| CLOSING |-+CLOSE | |
| | +---------+ | |
| | | | | | | |
+----------|-------------------------+ | | +----------------+ |
| | +-----------+ +------------------|--+
| | |recv CLOSE, recv CLOSE_ACK | |
| +-------------+ |send CLOSE_ACK or timeout | |
| recv CLOSE, | | (UAL+MSL) | |
| send CLOSE_ACK v v | |
| +--------+ receive I2, send R2 | |
+---------------------| CLOSED |------------------------------+ |
+--------+ |
^ | | |
recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) |
+-+ +------------------------------------+
+--+ +----------------------------+
recv I1, send R1 | | | |
| v v |
+--------------+ recv I2, send R2 |
+----------------| UNASSOCIATED |----------------+ |
datagram | +--+ +--------------+ | |
to send, | | | Alg. not supported, | |
send I1 | | | send I1 | |
. v | v | |
. +---------+ recv I2, send R2 | |
+---->| I1-SENT |--------------------------------------+ | |
| +---------+ +----------------------+ | | |
| | recv R2, | recv I2, send R2 | | | |
| v send I2 | v v v |
| +---------+ | +---------+ |
| +--->| I2-SENT |----------+ +--------------| R2-SENT |<---+ |
| | +---------+ | +---------+ | |
| | | |recv R2 | data or| | |
| |recv R1, | | | EC timeout| | |
| |send I2 +--|-----------------+ | receive I2,| |
| | | | +-------------+ | send R2| |
| | | +------>| ESTABLISHED |<----------+ | |
| | | +-------------+ | |
| | | | | | receive I2, send R2 | |
| | +------------+ | +-------------------------------+ |
| | | +-----------+ | |
| | | no packet sent/received| +---+ | |
| | | for UAL min, send CLOSE| | |timeout | |
| | | v v |(UAL+MSL) | |
| | | +---------+ |retransmit | |
+--|----------|------------------------| CLOSING |-+CLOSE | |
| | +---------+ | |
| | | | | | | |
+----------|-------------------------+ | | +----------------+ |
| | +-----------+ +------------------|--+
| | |recv CLOSE, recv CLOSE_ACK | |
| +-------------+ |send CLOSE_ACK or timeout | |
| recv CLOSE, | | (UAL+MSL) | |
| send CLOSE_ACK v v | |
| +--------+ receive I2, send R2 | |
+---------------------| CLOSED |------------------------------+ |
+--------+ |
^ | | |
recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) |
+-+ +------------------------------------+
Figure 2
图2
When computing TCP and UDP checksums on user data packets that flow through sockets bound to HITs, the IPv6 pseudo header format [RFC2460] MUST be used, even if the actual addresses in the header of the packet are IPv4 addresses. Additionally, the HITs MUST be used in place of the IPv6 addresses in the IPv6 pseudo header. Note that the pseudo header for actual HIP payloads is computed differently; see Section 5.1.1.
在计算通过绑定到HITs的套接字的用户数据包的TCP和UDP校验和时，必须使用IPv6伪报头格式[RFC2460]，即使数据包报头中的实际地址是IPv4地址。此外，必须在IPv6伪报头中使用HITs代替IPv6地址。注意，实际髋部有效载荷的伪头部的计算方式不同；见第5.1.1节。
Other documents may define how to include user data in various HIP packets. However, currently the HIP header is a terminal header, and not followed by any other headers.
其他文档可以定义如何在各种HIP数据包中包括用户数据。但是，当前HIP头是终端头，后面没有任何其他头。
The actual data transmission format, used for user data after the HIP base exchange, is not defined in this document. Such transport formats and methods are described in separate specifications. All HIP implementations MUST implement, at minimum, the ESP transport format for HIP [RFC7402]. The transport format to be chosen is negotiated in the base exchange. The Responder expresses its preference regarding the transport format in the TRANSPORT_FORMAT_LIST in the R1 packet, and the Initiator selects one transport format and adds the respective HIP parameter to the I2 packet.
本文档中未定义用于HIP base交换后用户数据的实际数据传输格式。此类传输格式和方法在单独的规范中描述。所有HIP实施必须至少实现HIP的ESP传输格式[RFC7402]。要选择的传输格式在基本交换中协商。响应者在R1分组的transport_format_列表中表示其关于传输格式的偏好，并且发起方选择一种传输格式并将相应的HIP参数添加到I2分组。
Simulating a loss of state is a potential DoS attack. The following process has been crafted to manage state recovery without presenting a DoS opportunity.
模拟状态丢失是一种潜在的DoS攻击。以下过程是精心设计的，用于在不提供拒绝服务机会的情况下管理状态恢复。
If a host reboots or the HIP association times out, it has lost its HIP state. If the host that lost state has a datagram to send to the peer, it simply restarts the HIP base exchange. After the base exchange has completed, the Initiator can create a new payload association and start sending data. The peer does not reset its state until it receives a valid I2 packet.
如果主机重新启动或HIP关联超时，则它已失去HIP状态。如果丢失状态的主机有一个数据报要发送给对等机，它只需重新启动HIP base exchange。基本交换完成后，启动器可以创建新的有效负载关联并开始发送数据。对等方在收到有效的I2数据包之前不会重置其状态。
If a system receives a user data packet that cannot be matched to any existing HIP association, it is possible that it has lost the state and its peer has not. It MAY send an ICMP packet with the Parameter Problem type, and with the Pointer pointing to the referred
如果系统接收到无法与任何现有HIP关联匹配的用户数据包，则可能是系统已丢失状态，而其对等方未丢失状态。它可以发送一个ICMP数据包，该数据包的参数类型为Problem，指针指向所引用的
HIP-related association information. Reacting to such traffic depends on the implementation and the environment where the implementation is used.
髋关节相关信息。对此类流量的反应取决于实现和使用实现的环境。
If the host that apparently has lost its state decides to restart the HIP base exchange, it sends an I1 packet to the peer. After the base exchange has been completed successfully, the Initiator can create a new HIP association, and the peer drops its old payload associations and creates a new one.
如果显然已失去其状态的主机决定重新启动HIP base exchange，它将向对等方发送I1数据包。成功完成基本交换后，发起方可以创建新的HIP关联，对等方放弃其旧的有效负载关联并创建一个新的HIP关联。
This document does not define how to use certificates or how to transfer them between hosts. These functions are expected to be defined in a future specification, as was done for HIP version 1 (see [RFC6253]). A parameter type value, meant to be used for carrying certificates, is reserved, though: CERT, Type 768; see Section 5.2.
本文档未定义如何使用证书或如何在主机之间传输证书。这些功能预计将在未来的规范中定义，正如HIP版本1（参见[RFC6253]）。保留了一个用于携带证书的参数类型值：CERT，类型768；见第5.2节。
All HIP packets start with a fixed header.
所有HIP数据包都以固定的头开始。
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 |Version| 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 |Version| 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. However, this document does not describe processing for Next Header values other than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. Future documents MAY define behavior for other values. However, current implementations MUST ignore trailing data if an unimplemented Next Header value is received.
HIP标头在逻辑上是IPv6扩展标头。但是，本文档不描述除十进制59、IPPROTO_NONE（IPv6“无下一个标头”值）以外的下一个标头值的处理。将来的文档可能会定义其他值的行为。但是，如果接收到未实现的下一个标头值，则当前实现必须忽略尾部数据。
The Header Length field contains the combined length of the HIP Header and HIP parameters in 8-byte units, excluding the first 8 bytes. Since all HIP headers MUST contain the sender's and receiver's HIT fields, the minimum value for this field is 4, and conversely, the maximum length of the HIP Parameters field is (255 * 8) - 32 = 2008 bytes (see Section 5.1.3 regarding HIP fragmentation). Note: this sets an additional limit for sizes of parameters included in the Parameters field, independent of the individual parameter maximum lengths.
Header Length字段包含HIP Header和HIP参数的组合长度，以8字节为单位，不包括前8个字节。由于所有HIP头必须包含发送方和接收方的HIT字段，因此该字段的最小值为4，反之，HIP参数字段的最大长度为（255*8）-32=2008字节（参见第5.1.3节关于HIP碎片）。注意：这为参数字段中包含的参数的大小设置了一个附加限制，与单个参数的最大长度无关。
The Packet Type indicates the HIP packet type. The individual packet types are defined in the relevant sections. If a HIP host receives a HIP packet that contains an unrecognized packet type, it MUST drop the packet.
数据包类型表示HIP数据包类型。各个数据包类型在相关章节中定义。如果HIP主机接收到包含无法识别的数据包类型的HIP数据包，则必须丢弃该数据包。
The HIP Version field is four bits. The version defined in this document is 2. The version number is expected to be incremented only if there are incompatible changes to the protocol. Most extensions can be handled by defining new packet types, new parameter types, or new Controls (see Section 5.1.2).
HIP版本字段为四位。本文档中定义的版本为2。只有当协议发生不兼容的更改时，版本号才会增加。大多数扩展可以通过定义新的数据包类型、新的参数类型或新的控件来处理（参见第5.1.2节）。
The following three bits are reserved for future use. They MUST be zero when sent, and they MUST be ignored when handling a received packet.
以下三位保留供将来使用。它们在发送时必须为零，在处理接收到的数据包时必须忽略。
The two fixed bits in the header are reserved for SHIM6 compatibility [RFC5533], Section 5.3. For implementations adhering (only) to this specification, they MUST be set as shown when sending and MUST be ignored when receiving. This is to ensure optimal forward compatibility. Note that for implementations that implement other compatible specifications in addition to this specification, the corresponding rules may well be different. For example, an implementation that implements both this specification and the SHIM6 protocol may need to check these bits in order to determine how to handle the packet.
标头中的两个固定位保留用于第5.3节中的SHIM6兼容性[RFC5533]。对于（仅）遵守本规范的实现，它们必须在发送时按所示进行设置，在接收时必须忽略。这是为了确保最佳的前向兼容性。请注意，对于除此规范之外实现其他兼容规范的实现，相应的规则可能会有所不同。例如，同时实现本规范和SHIM6协议的实现可能需要检查这些位，以确定如何处理数据包。
The HIT fields are always 128 bits (16 bytes) long.
命中字段的长度始终为128位（16字节）。
Since the checksum covers the source and destination addresses in the IP header, it MUST be recomputed on HIP-aware NAT devices.
由于校验和覆盖了IP报头中的源地址和目标地址，因此必须在支持HIP的NAT设备上重新计算校验和。
If IPv6 is used to carry the HIP packet, the pseudo header [RFC2460] contains the source and destination IPv6 addresses, HIP packet length in the pseudo header Length field, a zero field, and the HIP protocol number (see Section 5.1) in the Next Header field. The Length field is in bytes and can be calculated from the HIP Header Length field:
如果IPv6用于承载HIP数据包，则伪报头[RFC2460]包含源和目标IPv6地址、伪报头长度字段中的HIP数据包长度、零字段以及下一报头字段中的HIP协议号（见第5.1节）。长度字段以字节为单位，可以从HIP标头长度字段计算：
(HIP Header Length + 1) * 8.
（臀部头部长度+1）*8。
In case of using IPv4, the IPv4 UDP pseudo header format [RFC0768] is used. In the pseudo header, the source and destination addresses are those used in the IP header, the zero field is obviously zero, the protocol is the HIP protocol number (see Section 4), and the length is calculated as in the IPv6 case.
如果使用IPv4，则使用IPv4 UDP伪头格式[RFC0768]。在伪报头中，源地址和目标地址是IP报头中使用的地址，零字段显然是零，协议是HIP协议号（参见第4节），长度的计算与IPv6情况相同。
The HIP Controls field conveys information about the structure of the packet and capabilities of the host.
HIP控制字段传递有关数据包结构和主机功能的信息。
The following fields have been defined:
已定义以下字段：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A - Anonymous: If this is set, the sender's HI in this packet is anonymous, i.e., one not listed in a directory. Anonymous HIs SHOULD NOT be stored. This control is set in packets using anonymous sender HIs. The peer receiving an anonymous HI in an R1 or I2 may choose to refuse it.
A-匿名：如果设置了此选项，则此数据包中发件人的HI是匿名的，即未在目录中列出的HI。不应存储匿名HIs。此控件在使用匿名发件人HIs的数据包中设置。在R1或I2中接收匿名HI的对等方可以选择拒绝它。
The rest of the fields are reserved for future use, and MUST be set to zero in sent packets and MUST be ignored in received packets.
其余字段保留供将来使用，在发送的数据包中必须设置为零，在接收的数据包中必须忽略。
A HIP implementation MUST support IP fragmentation/reassembly. Fragment reassembly MUST be implemented in both IPv4 and IPv6, but fragment generation is REQUIRED to be implemented in IPv4 (IPv4 stacks and networks will usually do this by default) and RECOMMENDED to be implemented in IPv6. In IPv6 networks, the minimum MTU is larger, 1280 bytes, than in IPv4 networks. The larger MTU size is usually sufficient for most HIP packets, and therefore fragment
HIP实现必须支持IP碎片化/重组。片段重组必须在IPv4和IPv6中实现，但片段生成需要在IPv4中实现（默认情况下，IPv4堆栈和网络通常会这样做），建议在IPv6中实现。在IPv6网络中，最小MTU比IPv4网络中的MTU大1280字节。较大的MTU大小通常足以满足大多数HIP数据包的要求，因此可以使用片段
generation may not be needed. If it is expected that a host will send HIP packets that are larger than the minimum IPv6 MTU, the implementation MUST implement fragment generation even for IPv6.
可能不需要发电。如果预期主机将发送大于最小IPv6 MTU的HIP数据包，则实现必须实现甚至IPv6的片段生成。
In IPv4 networks, HIP packets may encounter low MTUs along their routed path. Since basic HIP, as defined in this document, does not provide a mechanism to use multiple IP datagrams for a single HIP packet, support for path MTU discovery does not bring any value to HIP in IPv4 networks. HIP-aware NAT devices SHOULD perform IPv4 reassembly/fragmentation for HIP packets.
在IPv4网络中，HIP数据包可能会在其路由路径上遇到较低的MTU。由于本文档中定义的基本HIP不提供为单个HIP数据包使用多个IP数据报的机制，因此对路径MTU发现的支持不会为IPv4网络中的HIP带来任何价值。HIP感知NAT设备应为HIP数据包执行IPv4重新组装/分段。
All HIP implementations have to be careful while employing a reassembly algorithm so that the algorithm is sufficiently resistant to DoS attacks.
在使用重组算法时，所有HIP实现都必须小心，以便该算法能够充分抵抗DoS攻击。
Certificate chains can cause the packet to be fragmented, and fragmentation can open implementations to denial-of-service attacks [KAU03]. "Hash and URL" schemes as defined in [RFC6253] for HIP version 1 may be used to avoid fragmentation and mitigate resulting DoS attacks.
证书链会导致数据包碎片化，碎片化会使实现面临拒绝服务攻击[KAU03]。HIP版本1的[RFC6253]中定义的“哈希和URL”方案可用于避免碎片并减轻由此产生的DoS攻击。
The HIP parameters carry information that is necessary for establishing and maintaining a HIP association. For example, the peer's public keys as well as the signaling for negotiating ciphers and payload handling are encapsulated in HIP parameters. Additional information, meaningful for end hosts or middleboxes, may also be included in HIP parameters. The specification of the HIP parameters and their mapping to HIP packets and packet types is flexible to allow HIP extensions to define new parameters and new protocol behavior.
髋部参数包含建立和维持髋部关联所需的信息。例如，对等方的公钥以及协商密码和有效负载处理的信令都封装在HIP参数中。HIP参数中还可能包含对终端主机或中间盒有意义的其他信息。HIP参数的规范及其到HIP数据包和数据包类型的映射是灵活的，允许HIP扩展定义新的参数和新的协议行为。
In HIP packets, HIP parameters are ordered according to their numeric type number and encoded in TLV format.
在HIP数据包中，HIP参数根据其数字类型编号排序，并以TLV格式编码。
The following parameter types are currently defined.
当前定义了以下参数类型。
+------------------------+-------+-----------+----------------------+
| TLV | Type | Length | Data |
+------------------------+-------+-----------+----------------------+
| R1_COUNTER | 129 | 12 | Puzzle generation |
| | | | counter |
| | | | |
| PUZZLE | 257 | 12 | #K and Random #I |
| | | | |
| SOLUTION | 321 | 20 | #K, Random #I and |
| | | | puzzle solution #J |
| | | | |
| SEQ | 385 | 4 | UPDATE packet ID |
| | | | number |
| | | | |
| ACK | 449 | variable | UPDATE packet ID |
| | | | number |
| | | | |
| DH_GROUP_LIST | 511 | variable | Ordered list of DH |
| | | | Group IDs supported |
| | | | by a host |
| | | | |
| DIFFIE_HELLMAN | 513 | variable | public key |
| | | | |
| HIP_CIPHER | 579 | variable | List of HIP |
| | | | encryption |
| | | | algorithms |
| | | | |
| ENCRYPTED | 641 | variable | Encrypted part of a |
| | | | HIP packet |
| | | | |
| HOST_ID | 705 | variable | Host Identity with |
| | | | Fully Qualified |
| | | | Domain Name (FQDN) |
| | | | or Network Access |
| | | | Identifier (NAI) |
| | | | |
| HIT_SUITE_LIST | 715 | variable | Ordered list of the |
| | | | HIT Suites supported |
| | | | by the Responder |
| | | | |
| CERT | 768 | variable | HI Certificate; used |
| | | | to transfer |
| | | | certificates. |
| | | | Specified in a |
| | | | separate document. |
| | | | |
+------------------------+-------+-----------+----------------------+
| TLV | Type | Length | Data |
+------------------------+-------+-----------+----------------------+
| R1_COUNTER | 129 | 12 | Puzzle generation |
| | | | counter |
| | | | |
| PUZZLE | 257 | 12 | #K and Random #I |
| | | | |
| SOLUTION | 321 | 20 | #K, Random #I and |
| | | | puzzle solution #J |
| | | | |
| SEQ | 385 | 4 | UPDATE packet ID |
| | | | number |
| | | | |
| ACK | 449 | variable | UPDATE packet ID |
| | | | number |
| | | | |
| DH_GROUP_LIST | 511 | variable | Ordered list of DH |
| | | | Group IDs supported |
| | | | by a host |
| | | | |
| DIFFIE_HELLMAN | 513 | variable | public key |
| | | | |
| HIP_CIPHER | 579 | variable | List of HIP |
| | | | encryption |
| | | | algorithms |
| | | | |
| ENCRYPTED | 641 | variable | Encrypted part of a |
| | | | HIP packet |
| | | | |
| HOST_ID | 705 | variable | Host Identity with |
| | | | Fully Qualified |
| | | | Domain Name (FQDN) |
| | | | or Network Access |
| | | | Identifier (NAI) |
| | | | |
| HIT_SUITE_LIST | 715 | variable | Ordered list of the |
| | | | HIT Suites supported |
| | | | by the Responder |
| | | | |
| CERT | 768 | variable | HI Certificate; used |
| | | | to transfer |
| | | | certificates. |
| | | | Specified in a |
| | | | separate document. |
| | | | |
| NOTIFICATION | 832 | variable | Informational data |
| | | | |
| ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be |
| | | | echoed back; signed |
| | | | |
| ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed |
| | | | back by request; |
| | | | signed |
| | | | |
| TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable |
| | | list of | |
| | | preferred | |
| | | HIP | |
| | | transport | |
| | | type | |
| | | numbers | |
| | | | |
| HIP_MAC | 61505 | variable | HMAC-based message |
| | | | authentication code, |
| | | | with key material |
| | | | from KEYMAT |
| | | | |
| HIP_MAC_2 | 61569 | variable | HMAC-based message |
| | | | authentication code, |
| | | | with key material |
| | | | from KEYMAT. Unlike |
| | | | HIP_MAC, the HOST_ID |
| | | | parameter is |
| | | | included in |
| | | | HIP_MAC_2 |
| | | | calculation. |
| | | | |
| HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 |
| | | | packet |
| | | | |
| HIP_SIGNATURE | 61697 | variable | Signature of the |
| | | | packet |
| | | | |
| ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be |
| | | | echoed back; after |
| | | | signature |
| | | | |
| ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed |
| | | | back by request; |
| | | | after signature |
+------------------------+-------+-----------+----------------------+
| NOTIFICATION | 832 | variable | Informational data |
| | | | |
| ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be |
| | | | echoed back; signed |
| | | | |
| ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed |
| | | | back by request; |
| | | | signed |
| | | | |
| TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable |
| | | list of | |
| | | preferred | |
| | | HIP | |
| | | transport | |
| | | type | |
| | | numbers | |
| | | | |
| HIP_MAC | 61505 | variable | HMAC-based message |
| | | | authentication code, |
| | | | with key material |
| | | | from KEYMAT |
| | | | |
| HIP_MAC_2 | 61569 | variable | HMAC-based message |
| | | | authentication code, |
| | | | with key material |
| | | | from KEYMAT. Unlike |
| | | | HIP_MAC, the HOST_ID |
| | | | parameter is |
| | | | included in |
| | | | HIP_MAC_2 |
| | | | calculation. |
| | | | |
| HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 |
| | | | packet |
| | | | |
| HIP_SIGNATURE | 61697 | variable | Signature of the |
| | | | packet |
| | | | |
| ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be |
| | | | echoed back; after |
| | | | signature |
| | | | |
| ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed |
| | | | back by request; |
| | | | after signature |
+------------------------+-------+-----------+----------------------+
As the ordering (from lowest to highest) of HIP parameters is strictly enforced (see Section 5.2.1), the parameter type values for existing parameters have been spaced to allow for future protocol extensions.
由于严格执行HIP参数的顺序（从最低到最高）（见第5.2.1节），现有参数的参数类型值已隔开，以允许将来的协议扩展。
The following parameter type number ranges are defined.
定义了以下参数类型编号范围。
+---------------+---------------------------------------------------+
| Type Range | Purpose |
+---------------+---------------------------------------------------+
| 0 - 1023 | Handshake |
| | |
| 1024 - 2047 | Reserved |
| | |
| 2048 - 4095 | Parameters related to HIP transport formats |
| | |
| 4096 - 8191 | Signed parameters allocated through specification |
| | documents |
| | |
| 8192 - 32767 | Reserved |
| | |
| 32768 - 49151 | Reserved for Private Use. Signed parameters. |
| | |
| 49152 - 61439 | Reserved |
| | |
| 61440 - 62463 | Signatures and (signed) MACs |
| | |
| 62464 - 63487 | Parameters that are neither signed nor MACed |
| | |
| 63488 - 64511 | Rendezvous and relaying |
| | |
| 64512 - 65023 | Parameters that are neither signed nor MACed |
| | |
| 65024 - 65535 | Reserved |
+---------------+---------------------------------------------------+
+---------------+---------------------------------------------------+
| Type Range | Purpose |
+---------------+---------------------------------------------------+
| 0 - 1023 | Handshake |
| | |
| 1024 - 2047 | Reserved |
| | |
| 2048 - 4095 | Parameters related to HIP transport formats |
| | |
| 4096 - 8191 | Signed parameters allocated through specification |
| | documents |
| | |
| 8192 - 32767 | Reserved |
| | |
| 32768 - 49151 | Reserved for Private Use. Signed parameters. |
| | |
| 49152 - 61439 | Reserved |
| | |
| 61440 - 62463 | Signatures and (signed) MACs |
| | |
| 62464 - 63487 | Parameters that are neither signed nor MACed |
| | |
| 63488 - 64511 | Rendezvous and relaying |
| | |
| 64512 - 65023 | Parameters that are neither signed nor MACed |
| | |
| 65024 - 65535 | Reserved |
+---------------+---------------------------------------------------+
The process for defining new parameters is described in Section 5.2.2 of this document.
本文件第5.2.2节描述了定义新参数的过程。
The range between 32768 (2^15) and 49151 (2^15 + 2^14) is Reserved for Private Use. Types from this range SHOULD be selected in a random fashion to reduce the probability of collisions.
32768（2^15）和49151（2^15+2^14）之间的范围保留供私人使用。应以随机方式选择此范围内的类型，以减少碰撞的概率。
The TLV-encoded parameters are described in the following subsections. The Type field value also describes the order of these fields in the packet. The parameters MUST be included in the packet
TLV编码参数在以下小节中描述。类型字段值还描述了这些字段在数据包中的顺序。参数必须包含在数据包中
so that their types form an increasing order. If multiple parameters with the same type number are in one packet, the parameters with the same type MUST be consecutive in the packet. If the order does not follow this rule, the packet is considered to be malformed and it MUST be discarded.
因此，它们的类型形成一个递增的顺序。如果一个数据包中有多个具有相同类型编号的参数，则具有相同类型的参数在该数据包中必须是连续的。如果顺序不符合此规则，则认为数据包格式不正确，必须将其丢弃。
Parameters using type values from 2048 up to 4095 are related to transport formats. Currently, one transport format is defined: the ESP transport format [RFC7402].
使用从2048到4095的类型值的参数与传输格式相关。目前，定义了一种传输格式：ESP传输格式[RFC7402]。
All of the encoded TLV parameters have a length (that includes the Type and Length fields), which is a multiple of 8 bytes. When needed, padding MUST be added to the end of the parameter so that the total length is a multiple of 8 bytes. This rule ensures proper alignment of data. Any added padding bytes MUST be zeroed by the sender, and their values SHOULD NOT be checked by the receiver.
所有编码的TLV参数都有一个长度（包括类型和长度字段），是8字节的倍数。需要时，必须将填充添加到参数的末尾，以便总长度为8字节的倍数。此规则确保数据的正确对齐。任何添加的填充字节必须由发送方归零，接收方不应检查其值。
The Length field indicates the length of the Contents field (in bytes). Consequently, the total length of the TLV parameter (including Type, Length, Contents, and Padding) is related to the Length field according to the following formula:
长度字段表示内容字段的长度（以字节为单位）。因此，TLV参数的总长度（包括类型、长度、内容和填充）根据以下公式与长度字段相关：
Total Length = 11 + Length - (Length + 3) % 8;
Total Length = 11 + Length - (Length + 3) % 8;
where % is the modulo operator.
其中%是模运算符。
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 bytes, excluding Type, Length, and Padding Contents Parameter specific, defined by Type Padding Padding, 0-7 bytes, added if needed
输入参数的类型代码。16位长，C位是类型代码的一部分。C至关重要。如果此参数非常关键且必须由收件人识别，则为一，否则为零。C位被视为类型字段的一部分。因此，临界参数总是奇数，而非临界参数的值是偶数。长度内容的长度，以字节为单位，不包括特定于类型、长度和填充内容的参数，由类型填充定义，0-7字节，如果需要，可以添加
Critical parameters (indicated by the odd type number value) MUST be recognized by the recipient. If a recipient encounters a critical parameter that it does not recognize, it MUST NOT process the packet any further. It MAY send an ICMP or NOTIFY, as defined in Section 4.3.
收件人必须识别关键参数（由奇数类型数值表示）。如果收件人遇到无法识别的关键参数，则不得进一步处理数据包。它可以发送ICMP或通知，如第4.3节所定义。
Non-critical parameters MAY be safely ignored. If a recipient encounters a non-critical parameter that it does not recognize, it SHOULD proceed as if the parameter was not present in the received packet.
可以安全地忽略非关键参数。如果收件人遇到无法识别的非关键参数，则应继续处理，就像接收到的数据包中不存在该参数一样。
Future specifications may define new parameters as needed. When defining new parameters, care must be taken to ensure that the parameter type values are appropriate and leave suitable space for other future extensions. One must remember that the parameters MUST always be arranged in numerically increasing order by Type code, thereby limiting the order of parameters (see Section 5.2.1).
未来的规范可能会根据需要定义新的参数。定义新参数时，必须注意确保参数类型值适当，并为将来的其他扩展留出适当的空间。必须记住，参数必须始终按类型代码按数字递增顺序排列，从而限制参数顺序（见第5.2.1节）。
The following rules MUST be followed when defining new parameters.
定义新参数时必须遵循以下规则。
1. The low-order bit C of the Type code is used to distinguish between critical and non-critical parameters. Hence, even parameter type numbers indicate non-critical parameters while odd parameter type numbers indicate critical parameters.
1. 类型代码的低阶位C用于区分关键参数和非关键参数。因此，偶数参数类型编号表示非关键参数，而奇数参数类型编号表示关键参数。
2. A new parameter MAY be critical only if an old implementation that ignored it would cause security problems. In general, new parameters SHOULD be defined as non-critical, and expect a reply from the recipient.
2. 只有当忽略新参数的旧实现会导致安全问题时，新参数才可能是关键的。一般来说，新参数应定义为非关键参数，并期望收件人回复。
3. If a system implements a new critical parameter, it MUST provide the ability to set the associated feature off, such that the critical parameter is not sent at all. The configuration option MUST be well documented. Implementations operating in a mode adhering to this specification MUST disable the sending of new critical parameters by default. In other words, the management interface MUST allow vanilla standards-only mode as a default configuration setting, and MAY allow new critical payloads to be configured on (and off).
3. 如果系统实现了一个新的关键参数，它必须提供关闭相关功能的能力，以便根本不发送关键参数。必须充分记录配置选项。在遵循本规范的模式下运行的实现在默认情况下必须禁用发送新的关键参数。换句话说，管理界面必须允许香草标准模式作为默认配置设置，并且可能允许打开（和关闭）配置新的关键有效负载。
4. See Section 9 for allocation rules regarding Type codes.
4. 有关类型代码的分配规则，请参见第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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, 4 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R1 generation counter, 8 bytes |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, 4 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R1 generation counter, 8 bytes |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 129 Length 12 R1 generation counter The current generation of valid puzzles
类型129长度12 R1生成计数器当前生成的有效拼图
The R1_COUNTER parameter contains a 64-bit unsigned integer in network byte order, indicating the current generation of valid puzzles. The sender SHOULD increment this counter periodically. It is RECOMMENDED that the counter value is incremented at least as often as old PUZZLE values are deprecated so that SOLUTIONs to them are no longer accepted.
R1_计数器参数包含网络字节顺序的64位无符号整数，表示当前生成的有效拼图。发送方应定期递增此计数器。建议计数器值的增加频率至少与旧的拼图值的增加频率相同，以便不再接受它们的解决方案。
Support for the R1_COUNTER parameter is mandatory, although its inclusion in the R1 packet is optional. It SHOULD be included in the R1 (in which case it is covered by the signature), and if present in the R1, it MUST be echoed (including the Reserved field verbatim) by the Initiator in the I2 packet.
对R1_计数器参数的支持是强制性的，尽管其包含在R1数据包中是可选的。它应该包含在R1中（在这种情况下，它被签名覆盖），如果它存在于R1中，则必须由I2数据包中的发起人进行回音（包括保留字段逐字）。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #K, 1 byte | Lifetime | Opaque, 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random #I, RHASH_len / 8 bytes |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #K, 1 byte | Lifetime | Opaque, 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random #I, RHASH_len / 8 bytes |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 257 Length 4 + RHASH_len / 8 #K #K is the number of verified bits Lifetime puzzle lifetime 2^(value - 32) seconds Opaque data set by the Responder, indexing the puzzle Random #I random number of size RHASH_len bits
类型257 Length 4+RHASH#u len/8#K#K是响应程序设置的验证位生存期拼图生存期2^（值-32）秒不透明数据，索引拼图随机#I大小RHASH#len位的随机数
Random #I is represented as an n-bit integer (where n is RHASH_len), and #K and Lifetime as 8-bit integers, all in network byte order.
随机#I表示为n位整数（其中n为RHASH#len），而#K和生存期表示为8位整数，均以网络字节顺序表示。
The PUZZLE parameter contains the puzzle difficulty #K and an n-bit random integer #I. The Puzzle Lifetime indicates the time during which the puzzle solution is valid, and sets a time limit that should not be exceeded by the Initiator while it attempts to solve the puzzle. The lifetime is indicated as a power of 2 using the formula 2^(Lifetime - 32) seconds. A puzzle MAY be augmented with an ECHO_REQUEST_SIGNED or an ECHO_REQUEST_UNSIGNED parameter included in the R1; the contents of the echo request are then echoed back in the ECHO_RESPONSE_SIGNED or in the ECHO_RESPONSE_UNSIGNED parameter, allowing the Responder to use the included information as a part of its puzzle processing.
谜题参数包含谜题难度#K和一个n位随机整数#I。谜题生存期表示谜题解决方案有效的时间，并设置了发起者在尝试解决谜题时不应超过的时间限制。使用公式2^（寿命-32）秒将寿命表示为2的幂。可以使用R1中包括的ECHO_请求_签名或ECHO_请求_未签名参数来增加谜题；然后在echo_RESPONSE_SIGNED或echo_RESPONSE_UNSIGNED参数中回显echo请求的内容，从而允许响应者使用包含的信息作为其谜题处理的一部分。
The Opaque and Random #I fields are not covered by the HIP_SIGNATURE_2 parameter.
HIP_SIGNATURE_2参数不包括不透明和随机#I字段。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #K, 1 byte | Reserved | Opaque, 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random #I, n bytes |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Puzzle solution #J, RHASH_len / 8 bytes |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #K, 1 byte | Reserved | Opaque, 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random #I, n bytes |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Puzzle solution #J, RHASH_len / 8 bytes |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 321 Length 4 + RHASH_len / 4 #K #K is the number of verified bits Reserved zero when sent, ignored when received Opaque copied unmodified from the received PUZZLE parameter Random #I random number of size RHASH_len bits Puzzle solution #J random number of size RHASH_len bits
类型321长度4+RHASH#u len/4#K#K是发送时保留为零的验证位数，接收时忽略不透明复制，未修改自接收的拼图参数Random#I大小随机数RHASH#len位拼图解决方案#J大小随机数RHASH#len位
Random #I and Random #J are represented as n-bit unsigned integers (where n is RHASH_len), and #K as an 8-bit unsigned integer, all in network byte order.
Random#I和Random#J表示为n位无符号整数（其中n为RHASH#len），而#K表示为8位无符号整数，均以网络字节顺序表示。
The SOLUTION parameter contains a solution to a puzzle. It also echoes back the random difficulty #K, the Opaque field, and the puzzle integer #I.
SOLUTION参数包含谜题的解决方案。它还回响了随机难度#K、不透明字段和拼图整数#I。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #n| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 511 Length number of DH Group IDs DH GROUP ID identifies a DH GROUP ID supported by the host. The list of IDs is ordered by preference of the host. The possible DH Group IDs are defined in the DIFFIE_HELLMAN parameter. Each DH Group ID is one octet long.
类型511长度DH组ID的编号DH组ID标识主机支持的DH组ID。ID列表按主机的首选项排序。可能的DH组ID在DIFFIE_HELLMAN参数中定义。每个DH组ID有一个八位组长。
The DH_GROUP_LIST parameter contains the list of supported DH Group IDs of a host. The Initiator sends the DH_GROUP_LIST in the I1 packet, and the Responder sends its own list in the signed part of the R1 packet. The DH Group IDs in the DH_GROUP_LIST are listed in the order of their preference of the host sending the list. DH Group IDs that are listed first are preferred over the DH Group IDs listed later. The information in the DH_GROUP_LIST allows the Responder to select the DH group preferred by itself and supported by the Initiator. Based on the DH_GROUP_LIST in the R1 packet, the Initiator can determine if the Responder has selected the best possible choice based on the Initiator's and Responder's preferences. If the Responder's choice differs from the best choice, the Initiator can conclude that there was an attempted downgrade attack (see Section 4.1.7).
DH_GROUP_LIST参数包含主机支持的DH GROUP id列表。发起方在I1数据包中发送DH_组_列表，响应方在R1数据包的签名部分发送自己的列表。DH_Group_列表中的DH Group ID按照发送列表的主机的首选顺序列出。首先列出的DH组ID优先于后面列出的DH组ID。DH_GROUP_列表中的信息允许响应者选择自己首选且发起者支持的DH组。根据R1数据包中的DH_组_列表，发起方可确定响应方是否已根据发起方和响应方的偏好选择了最佳可能选择。如果响应者的选择与最佳选择不同，则发起者可以断定存在试图进行的降级攻击（参见第4.1.7节）。
When selecting the DH group for the DIFFIE_HELLMAN parameter in the R1 packet, the Responder MUST select the first DH Group ID in its DH_GROUP_LIST in the R1 packet that is compatible with one of the Suite IDs in the Initiator's DH_GROUP_LIST in the I1 packet. The Responder MUST NOT select any other DH Group ID that is contained in both lists, because then a downgrade attack cannot be detected.
当为R1数据包中的DIFFIE_HELLMAN参数选择DH组时，响应者必须在R1数据包中选择其DH_组列表中的第一个DH组ID，该DH组ID与I1数据包中启动器DH_组列表中的一个套件ID兼容。响应者不得选择两个列表中包含的任何其他DH组ID，因为这样就无法检测到降级攻击。
In general, hosts SHOULD prefer stronger groups over weaker ones if the computation overhead is not prohibitively high for the intended application.
一般来说，如果预期应用程序的计算开销不太高，主机应该选择更强的组而不是较弱的组。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | Public Value Length | Public 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | Public Value Length | Public Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 513 Length length in octets, excluding Type, Length, and Padding Group ID identifies values for p and g as well as the KDF Public Value length of the following Public Value in octets Length Public Value the sender's public Diffie-Hellman key
类型513长度（以八位字节为单位），不包括类型、长度和填充组ID标识p和g的值，以及以下公共值的KDF公共值长度（以八位字节为单位）长度公共值发送方的公共Diffie-Hellman密钥
A single DIFFIE_HELLMAN parameter may be included in selected HIP packets based on the DH Group ID selected (Section 5.2.6). The following Group IDs have been defined; values are assigned by this document:
基于所选DH组ID，单个DIFFIE_HELLMAN参数可包含在所选HIP数据包中（第5.2.6节）。已定义以下组ID；值由本文档指定：
Group KDF Value
组KDF值
Reserved 0 DEPRECATED 1 DEPRECATED 2 1536-bit MODP group [RFC3526] HKDF [RFC5869] 3 3072-bit MODP group [RFC3526] HKDF [RFC5869] 4 DEPRECATED 5 DEPRECATED 6 NIST P-256 [RFC5903] HKDF [RFC5869] 7 NIST P-384 [RFC5903] HKDF [RFC5869] 8 NIST P-521 [RFC5903] HKDF [RFC5869] 9 SECP160R1 [SECG] HKDF [RFC5869] 10 2048-bit MODP group [RFC3526] HKDF [RFC5869] 11
保留0不推荐1不推荐2 1536位MODP组[RFC3526]HKDF[RFC5869]3 3072位MODP组[RFC3526]HKDF[RFC5869]4不推荐5不推荐6 NIST P-256[RFC5903]HKDF[RFC5869]7 NIST P-384[RFC5903]HKDF[RFC5869]8 NIST P-521[RFC5903]HKDF[RFC5869]9 SECP160R1[SECG]HKDF[RFC5869]10 2048位MODP组[RFC5869]11
The MODP Diffie-Hellman groups are defined in [RFC3526]. ECDH groups 7-9 are defined in [RFC5903] and [RFC6090]. ECDH group 10 is covered in Appendix D. Any ECDH used with HIP MUST have a co-factor of 1.
[RFC3526]中定义了MODP Diffie-Hellman组。[RFC5903]和[RFC6090]中定义了ECDH组7-9。ECDH第10组包含在附录D中。与HIP一起使用的任何ECDH必须具有系数1。
The Group ID also defines the key derivation function that is to be used for deriving the symmetric keys for the HMAC and symmetric encryption from the keying material from the Diffie-Hellman key exchange (see Section 6.5).
组ID还定义了密钥派生函数，该函数用于从Diffie-Hellman密钥交换的密钥材料中派生HMAC的对称密钥和对称加密（见第6.5节）。
A HIP implementation MUST implement Group ID 3. The 160-bit SECP160R1 group can be used when lower security is enough (e.g., web surfing) and when the equipment is not powerful enough (e.g., some PDAs). Implementations SHOULD implement Group IDs 4 and 8.
HIP实现必须实现组ID 3。160位SECP160R1组可在安全性较低（如网络冲浪）和设备功能不足（如某些PDA）时使用。实现应该实现组ID 4和8。
To avoid unnecessary failures during the base exchange, the rest of the groups SHOULD be implemented in hosts where resources are adequate.
为了避免在基本交换期间发生不必要的故障，其余组应在资源充足的主机中实现。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher ID #1 | Cipher ID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher ID #1 | Cipher ID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 579 Length length in octets, excluding Type, Length, and Padding Cipher ID identifies the cipher algorithm to be used for encrypting the contents of the ENCRYPTED parameter
类型579长度以八位字节为单位，不包括类型、长度和填充密码ID，标识用于加密加密参数内容的密码算法
The following Cipher IDs are defined:
定义了以下密码ID：
Suite ID Value
套件ID值
RESERVED 0 NULL-ENCRYPT 1 ([RFC2410]) AES-128-CBC 2 ([RFC3602]) RESERVED 3 (unused value) AES-256-CBC 4 ([RFC3602])
保留0空加密1（[RFC2410]）AES-128-CBC 2（[RFC3602]）保留3（未使用值）AES-256-CBC 4（[RFC3602]）
The sender of a HIP_CIPHER parameter MUST make sure that there are no more than six (6) Cipher IDs in one HIP_CIPHER parameter.
HIP_密码参数的发送方必须确保一个HIP_密码参数中的密码ID不超过六（6）个。
Conversely, a recipient MUST be prepared to handle received transport parameters that contain more than six Cipher IDs by accepting the first six Cipher IDs and dropping the rest. The limited number of Cipher IDs sets the maximum size of the HIP_CIPHER parameter. As the default configuration, the HIP_CIPHER parameter MUST contain at least one of the mandatory Cipher IDs. There MAY be a configuration option that allows the administrator to override this default.
相反，收件人必须准备好处理接收到的包含六个以上密码ID的传输参数，方法是接受前六个密码ID并删除其余密码ID。有限数量的密码ID设置HIP_密码参数的最大大小。作为默认配置，HIP_CIPHER参数必须至少包含一个必需的密码ID。可能存在允许管理员覆盖此默认值的配置选项。
The Responder lists supported and desired Cipher IDs in order of preference in the R1, up to the maximum of six Cipher IDs. The Initiator MUST choose only one of the corresponding Cipher IDs. This Cipher ID will be used for generating the ENCRYPTED parameter.
响应程序在R1中按优先顺序列出支持的和需要的密码ID，最多六个密码ID。发起者必须只选择一个相应的密码ID。此密码ID将用于生成加密参数。
Mandatory implementation: AES-128-CBC. Implementors SHOULD support NULL-ENCRYPT for testing/debugging purposes but MUST NOT offer or accept this value unless explicitly configured for testing/debugging of HIP.
强制实施：AES-128-CBC。实现者应支持NULL-ENCRYPT用于测试/调试目的，但除非为HIP的测试/调试明确配置，否则不得提供或接受此值。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HI Length |DI-Type| DI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Host Identity /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Domain 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HI Length |DI-Type| DI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Host Identity /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Domain Identifier /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 705 Length length in octets, excluding Type, Length, and Padding HI Length length of the Host Identity in octets DI-Type type of the following Domain Identifier field DI Length length of the Domain Identifier field in octets Algorithm index to the employed algorithm Host Identity actual Host Identity Domain Identifier the identifier of the sender
705型长度八位字节，不包括类型、长度、，以及将八位字节中主机标识的HI-Length长度DI Type of the Lower Domain Identifier field DI Length of the Domain Identifier field in octets Algorithm index填充到所采用的算法主机标识实际主机标识域标识发送方的标识
The following DI-Types have been defined:
定义了以下DI类型：
Type Value
类型值
none included 0 FQDN 1 NAI 2
无包括0 FQDN 1 NAI 2
FQDN Fully Qualified Domain Name, in binary format NAI Network Access Identifier
FQDN完全限定域名，二进制格式NAI网络访问标识符
The format for the FQDN is defined in RFC 1035 [RFC1035], Section 3.1. The format for the NAI is defined in [RFC4282].
FQDN的格式在RFC 1035[RFC1035]第3.1节中定义。NAI的格式在[RFC4282]中定义。
A host MAY optionally associate the Host Identity with a single Domain Identifier in the HOST_ID parameter. If there is no Domain Identifier, i.e., the DI-Type field is zero, the DI Length field is set to zero as well.
主机可以选择将主机标识与主机ID参数中的单个域标识符相关联。如果没有域标识符，即DI类型字段为零，则DI长度字段也设置为零。
The following HI Algorithms have been defined:
定义了以下HI算法：
Algorithm profiles Values
算法配置文件值
RESERVED 0 DSA 3 [FIPS.186-4.2013] (RECOMMENDED) RSA 5 [RFC3447] (REQUIRED) ECDSA 7 [RFC4754] (REQUIRED) ECDSA_LOW 9 [SECG] (RECOMMENDED)
保留0 DSA 3[FIPS.186-4.2013]（推荐）RSA 5[RFC3447]（必需）ECDSA 7[RFC4754]（必需）ECDSA_LOW 9[SECG]（推荐）
For DSA, RSA, and ECDSA key types, profiles containing at least 112 bits of security strength (as defined by [NIST.800-131A.2011]) should be used. For RSA signature padding, the Probabilistic Signature Scheme (PSS) method of padding [RFC3447] MUST be used.
对于DSA、RSA和ECDSA密钥类型，应使用至少包含112位安全强度的配置文件（如[NIST.800-131A.2011]所定义）。对于RSA签名填充，必须使用概率签名方案（PSS）填充方法[RFC3447]。
The Host Identity is derived from the DNSKEY format for RSA and DSA. For these, the Public Key field of the RDATA part from RFC 4034 [RFC4034] is used. For Elliptic Curve Cryptography (ECC), we distinguish two different profiles: ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with low computational capabilities and uses shorter curves from the Standards for Efficient Cryptography Group [SECG]. Any ECDSA used with HIP MUST have a co-factor of 1.
主机标识源自RSA和DSA的DNSKEY格式。对于这些，使用来自RFC 4034[RFC4034]的RDATA部分的公钥字段。对于椭圆曲线密码（ECC），我们区分了两种不同的配置文件：ECDSA和ECDSA_LOW。ECC包含NIST批准并在RFC 4754[RFC4754]中定义的曲线。ECDSA_LOW是为计算能力较低的设备定义的，它使用了高效加密标准组[SECG]中较短的曲线。与HIP一起使用的任何ECDSA必须具有系数1。
For ECDSA and ECDSA_LOW, Host Identities are represented by the following fields:
对于ECDSA和ECDSA_LOW，主机标识由以下字段表示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECC Curve | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Public Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECC Curve | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Public Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ECC Curve Curve label Public Key Represented in octet-string format [RFC6090]
以八位字节字符串格式表示的ECC曲线标签公钥[RFC6090]
For hosts that implement ECDSA as the algorithm, the following ECC curves are required:
对于实现ECDSA作为算法的主机，需要以下ECC曲线：
Algorithm Curve Values
算法曲线值
ECDSA RESERVED 0 ECDSA NIST P-256 1 [RFC4754] ECDSA NIST P-384 2 [RFC4754]
ECDSA保留0 ECDSA NIST P-256 1[RFC4754]ECDSA NIST P-384 2[RFC4754]
For hosts that implement the ECDSA_LOW algorithm profile, the following curve is required:
对于实现ECDSA_LOW算法配置文件的主机，需要以下曲线：
Algorithm Curve Values
算法曲线值
ECDSA_LOW RESERVED 0 ECDSA_LOW SECP160R1 1 [SECG]
ECDSA_低位保留0 ECDSA_低位SECP160R1 1[SECG]
The HIT_SUITE_LIST parameter contains a list of the supported HIT Suite IDs of the Responder. The Responder sends the HIT_SUITE_LIST in the signed part of the R1 packet. Based on the HIT_SUITE_LIST, the Initiator can determine which source HIT Suite IDs are supported by the Responder.
HIT_SUITE_LIST参数包含响应程序支持的HIT SUITE ID的列表。响应者在R1数据包的签名部分发送命中套件列表。根据命中套件列表，发起方可以确定响应方支持哪些源命中套件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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID #1 | ID #2 | ID #3 | ID #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID #1 | ID #2 | ID #3 | ID #4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 715 Length number of HIT Suite IDs ID identifies a HIT Suite ID supported by the host. The list of IDs is ordered by preference of the host. Each HIT Suite ID is one octet long. The four higher-order bits of the ID field correspond to the HIT Suite ID in the ORCHID OGA ID field. The four lower-order bits are reserved and set to 0 by the sender. The reception of an ID with the four lower-order bits not set to 0 SHOULD be considered as an error that MAY result in a NOTIFICATION of type UNSUPPORTED_HIT_SUITE.
键入715长度HIT套件ID号标识主机支持的HIT套件ID。ID列表按主机的首选项排序。每个HIT套件ID都有一个八位字节长。ID字段的四个高阶位对应于兰花OGA ID字段中的HIT套件ID。发送方保留四个低阶位并将其设置为0。接收四个低阶位未设置为0的ID时，应将其视为一个错误，可能导致类型为UNSUPPORTED_HIT_SUITE的通知。
The HIT Suite ID indexes a HIT Suite. HIT Suites are composed of signature algorithms as defined in Section 5.2.9, and hash functions.
HIT套件ID为HIT套件编制索引。HIT套件由第5.2.9节中定义的签名算法和哈希函数组成。
The ID field in the HIT_SUITE_LIST is defined as an eight-bit field, as opposed to the four-bit HIT Suite ID and OGA ID field in the ORCHID. This difference is a measure to accommodate larger HIT Suite IDs if the 16 available values prove insufficient. In that case, one of the 16 values, zero, will be used to indicate that four additional bits of the ORCHID will be used to encode the HIT Suite ID. Hence,
HIT_SUITE_列表中的ID字段被定义为八位字段，而兰花列表中的四位HIT SUITE ID和OGA ID字段则相反。如果16个可用值证明不足，则此差异是一种适应更大的HIT套件ID的措施。在这种情况下，16个值中的一个零将用于指示兰花的四个附加位将用于编码命中套件ID。因此，
the current four-bit HIT Suite IDs only use the four higher-order bits in the ID field. Future documents may define the use of the four lower-order bits in the ID field.
当前的四位HIT套件ID仅使用ID字段中的四个高阶位。未来的文档可能会定义ID字段中四个低阶位的使用。
The following HIT Suite IDs are defined, and the relationship between the four-bit ID value used in the OGA ID field and the eight-bit encoding within the HIT_SUITE_LIST ID field is clarified:
定义了以下命中套件ID，并阐明了OGA ID字段中使用的四位ID值与命中套件列表ID字段中的八位编码之间的关系：
HIT Suite Four-bit ID Eight-bit encoding
HIT套件四位ID八位编码
RESERVED 0 0x00 RSA,DSA/SHA-256 1 0x10 (REQUIRED) ECDSA/SHA-384 2 0x20 (RECOMMENDED) ECDSA_LOW/SHA-1 3 0x30 (RECOMMENDED)
保留0 0x00 RSA，DSA/SHA-256 1 0x10（必需）ECDSA/SHA-384 2 0x20（推荐）ECDSA_LOW/SHA-1 3 0x30（推荐）
The following table provides more detail on the above HIT Suite combinations. The input for each generation algorithm is the encoding of the HI as defined in Section 3.2. The output is 96 bits long and is directly used in the ORCHID.
下表提供了有关上述HIT套件组合的更多详细信息。每个生成算法的输入是第3.2节中定义的HI编码。输出长度为96位，直接用于兰花。
+-------+----------+--------------+------------+--------------------+
| Index | Hash | HMAC | Signature | Description |
| | function | | algorithm | |
| | | | family | |
+-------+----------+--------------+------------+--------------------+
| 0 | | | | Reserved |
| | | | | |
| 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI |
| | | | | hashed with |
| | | | | SHA-256, truncated |
| | | | | to 96 bits |
| | | | | |
| 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed |
| | | | | with SHA-384, |
| | | | | truncated to 96 |
| | | | | bits |
| | | | | |
| 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI |
| | | | | hashed with SHA-1, |
| | | | | truncated to 96 |
| | | | | bits |
+-------+----------+--------------+------------+--------------------+
+-------+----------+--------------+------------+--------------------+
| Index | Hash | HMAC | Signature | Description |
| | function | | algorithm | |
| | | | family | |
+-------+----------+--------------+------------+--------------------+
| 0 | | | | Reserved |
| | | | | |
| 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI |
| | | | | hashed with |
| | | | | SHA-256, truncated |
| | | | | to 96 bits |
| | | | | |
| 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed |
| | | | | with SHA-384, |
| | | | | truncated to 96 |
| | | | | bits |
| | | | | |
| 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI |
| | | | | hashed with SHA-1, |
| | | | | truncated to 96 |
| | | | | bits |
+-------+----------+--------------+------------+--------------------+
Table 10: HIT Suites
表10：HIT套房
The hash of the Responder as defined in the HIT Suite determines the HMAC to be used for the RHASH function. The HMACs currently defined here are HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], and HMAC-SHA-1 [RFC2404].
HIT套件中定义的响应程序散列决定了要用于RHASH函数的HMAC。此处当前定义的HMAC为HMAC-SHA-256[RFC4868]、HMAC-SHA-384[RFC4868]和HMAC-SHA-1[RFC2404]。
The TRANSPORT_FORMAT_LIST parameter contains a list of the supported HIP transport formats (TFs) of the Responder. The Responder sends the TRANSPORT_FORMAT_LIST in the signed part of the R1 packet. Based on the TRANSPORT_FORMAT_LIST, the Initiator chooses one suitable transport format and includes the respective HIP transport format parameter in its response packet.
TRANSPORT_FORMAT_LIST参数包含响应程序支持的HIP传输格式（TFs）的列表。响应者在R1数据包的签名部分发送传输格式列表。根据传输格式列表，发起方选择一种合适的传输格式，并在其响应数据包中包含相应的HIP传输格式参数。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TF type #1 | TF type #2 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ TF type #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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TF type #1 | TF type #2 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ TF type #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2049 Length 2x number of TF types TF Type identifies a transport format (TF) type supported by the host. The TF type numbers correspond to the HIP parameter type numbers of the respective transport format parameters. The list of TF types is ordered by preference of the sender.
类型2049长度2x TF类型数TF类型标识主机支持的传输格式（TF）类型。TF类型编号对应于相应传输格式参数的HIP参数类型编号。TF类型列表按发件人的首选项排序。
The TF type numbers index the respective HIP parameters for the transport formats in the type number range between 2050 and 4095. The parameters and their use are defined in separate documents. Currently, the only transport format defined is IPsec ESP [RFC7402].
TF类型编号索引2050到4095之间类型编号范围内运输格式的各个HIP参数。参数及其使用在单独的文档中定义。目前，定义的唯一传输格式是IPsec ESP[RFC7402]。
For each listed TF type, the sender of the TRANSPORT_FORMAT_LIST parameter MUST include the respective transport format parameter in the HIP packet. The receiver MUST ignore the TF type in the TRANSPORT_FORMAT_LIST if no matching transport format parameter is present in the packet.
对于列出的每种TF类型，传输格式列表参数的发送方必须在HIP数据包中包含相应的传输格式参数。如果数据包中没有匹配的传输格式参数，则接收方必须忽略传输格式列表中的TF类型。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC |
/ /
/ +-------------------------------+
| | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC |
/ /
/ +-------------------------------+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 61505 Length length in octets, excluding Type, Length, and Padding HMAC HMAC computed over the HIP packet, excluding the HIP_MAC parameter and any following parameters, such as HIP_SIGNATURE, HIP_SIGNATURE_2, ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED. The Checksum field MUST be set to zero, and the HIP header length in the HIP common header MUST be calculated not to cover any excluded parameters when the HMAC is calculated. The size of the HMAC is the natural size of the hash computation output depending on the used hash function.
类型61505长度以八位字节为单位，不包括通过HIP数据包计算的类型、长度和填充HMAC HMAC，不包括HIP_MAC参数和任何以下参数，如HIP_签名、HIP_签名、ECHO_请求未签名或ECHO_响应未签名。校验和字段必须设置为零，并且在计算HMAC时，必须计算HIP公用标头中的HIP标头长度，以不覆盖任何排除的参数。HMAC的大小是散列计算输出的自然大小，具体取决于所使用的散列函数。
The HMAC uses RHASH as the hash algorithm. The calculation and verification process is presented in Section 6.4.1.
HMAC使用RHASH作为哈希算法。第6.4.1节介绍了计算和验证过程。
HIP_MAC_2 is a MAC of the packet and the HI of the sender in the form of a HOST_ID parameter when that parameter is not actually included in the packet. The parameter structure is the same as the structure shown in Section 5.2.12. The fields are as follows:
HIP_MAC_2是数据包的MAC和发送方的HI，其形式为主机ID参数，而该参数实际上不包括在数据包中。参数结构与第5.2.12节所示结构相同。字段如下所示：
Type 61569 Length length in octets, excluding Type, Length, and Padding HMAC HMAC computed over the HIP packet, excluding the HIP_MAC_2 parameter and any following parameters such as HIP_SIGNATURE, HIP_SIGNATURE_2, ECHO_REQUEST_UNSIGNED, or ECHO_RESPONSE_UNSIGNED, and including an additional sender's HOST_ID parameter during the HMAC calculation. The Checksum field MUST be set to zero, and the HIP
类型61569长度以八位字节为单位，不包括通过HIP数据包计算的类型、长度和填充HMAC HMAC，不包括HIP_MAC_2参数和任何以下参数，如HIP_签名、HIP_签名、ECHO_请求_未签名或ECHO_响应_未签名，并在HMAC计算过程中包括额外的发送方主机_ID参数。校验和字段必须设置为零，并且
header length in the HIP common header MUST be calculated not to cover any excluded parameters when the HMAC is calculated. The size of the HMAC is the natural size of the hash computation output depending on the used hash function.
计算HMAC时，必须计算HIP通用收割台中的收割台长度，以不覆盖任何排除的参数。HMAC的大小是散列计算输出的自然大小，具体取决于所使用的散列函数。
The HMAC uses RHASH as the hash algorithm. The calculation and verification process is presented in Section 6.4.1.
HMAC使用RHASH作为哈希算法。第6.4.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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIG alg | Signature /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIG alg | Signature /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 61697 Length length in octets, excluding Type, Length, and Padding SIG alg signature algorithm Signature the signature is calculated over the HIP packet, excluding the HIP_SIGNATURE parameter and any parameters that follow the HIP_SIGNATURE parameter. When the signature is calculated, the Checksum field MUST be set to zero, and the HIP header length in the HIP common header MUST be calculated only up to the beginning of the HIP_SIGNATURE parameter.
类型61697长度长度（以八位字节为单位），不包括类型、长度和填充SIG alg签名算法签名签名签名在HIP数据包上计算签名，不包括HIP_签名参数和HIP_签名参数后面的任何参数。计算签名时，校验和字段必须设置为零，并且HIP公共标头中的HIP标头长度必须仅计算到HIP_签名参数的开头。
The signature algorithms are defined in Section 5.2.9. The signature in the Signature field is encoded using the method depending on the signature algorithm (e.g., according to [RFC3110] in the case of RSA/ SHA-1, [RFC5702] in the case of RSA/SHA-256, [RFC2536] in the case of DSA, or [RFC6090] in the case of ECDSA).
第5.2.9节定义了签名算法。签名字段中的签名使用取决于签名算法的方法进行编码（例如，对于RSA/SHA-1，根据[RFC3110]；对于RSA/SHA-256，根据[RFC5702]；对于DSA，根据[RFC2536]；对于ECDSA，根据[RFC6090]）。
HIP_SIGNATURE calculation and verification follow the process defined in Section 6.4.2.
HIP_签名计算和验证遵循第6.4.2节中定义的流程。
HIP_SIGNATURE_2 excludes the variable parameters in the R1 packet to allow R1 pre-creation. The parameter structure is the same as the structure shown in Section 5.2.14. The fields are as follows:
HIP_签名_2排除R1数据包中的变量参数，以允许R1预创建。参数结构与第5.2.14节所示结构相同。字段如下所示：
Type 61633 Length length in octets, excluding Type, Length, and Padding SIG alg signature algorithm Signature Within the R1 packet that contains the HIP_SIGNATURE_2 parameter, the Initiator's HIT, the Checksum field, and the Opaque and Random #I fields in the PUZZLE parameter MUST be set to zero while computing the HIP_SIGNATURE_2 signature. Further, the HIP packet length in the HIP header MUST be adjusted as if the HIP_SIGNATURE_2 was not in the packet during the signature calculation, i.e., the HIP packet length points to the beginning of the HIP_SIGNATURE_2 parameter during signing and verification.
类型61633长度（以八位字节为单位），不包括R1数据包中的类型、长度和填充SIG alg签名算法签名，该R1数据包包含HIP_签名_2参数、启动器的命中、校验和字段以及PUZZLE参数中的不透明和随机I字段，在计算HIP_签名_2签名时必须设置为零。此外，必须调整HIP报头中的HIP分组长度，如同在签名计算期间HIP_签名_2不在分组中一样，即，在签名和验证期间HIP分组长度指向HIP_签名_2参数的开始。
Zeroing the Initiator's HIT makes it possible to create R1 packets beforehand, to minimize the effects of possible DoS attacks. Zeroing the Random #I and Opaque fields within the PUZZLE parameter allows these fields to be populated dynamically on precomputed R1s.
将启动器的命中率归零可以提前创建R1数据包，从而将可能的DoS攻击的影响降至最低。将PUZZLE参数中的随机#I和不透明字段归零，可以在预计算的R1s上动态填充这些字段。
Signature calculation and verification follow the process defined in Section 6.4.2.
签名计算和验证遵循第6.4.2节中定义的流程。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 385 Length 4 Update ID 32-bit sequence number
类型385长度4更新ID 32位序列号
The Update ID is an unsigned number in network byte order, initialized by a host to zero upon moving to ESTABLISHED state. The Update ID has scope within a single HIP association, and not across
更新ID是网络字节顺序的无符号数字，在移动到已建立状态时由主机初始化为零。更新ID的作用域在单个髋部关联内，而不是跨髋部关联
multiple associations or multiple hosts. The Update ID is incremented by one before each new UPDATE that is sent by the host; the first UPDATE packet originated by a host has an Update ID of 0.
多个关联或多个主机。更新ID在主机发送的每个新更新之前递增一；由主机发起的第一个更新数据包的更新ID为0。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| peer Update ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ peer Update ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| peer Update ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ peer Update ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 449 Length length in octets, excluding Type and Length peer Update ID 32-bit sequence number corresponding to the Update ID being ACKed
类型449长度（以八位字节为单位），不包括类型和长度对等更新ID 32位序列号，对应于正在确认的更新ID
The ACK parameter includes one or more Update IDs that have been received from the peer. The number of peer Update IDs can be inferred from the length by dividing it by 4.
ACK参数包括从对等方接收到的一个或多个更新ID。通过将长度除以4，可以推断出对等更新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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV /
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ Encrypted data /
/ /
/ +-------------------------------+
/ | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV /
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ Encrypted data /
/ /
/ +-------------------------------+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 641 Length length in octets, excluding Type, Length, and Padding Reserved zero when sent, ignored when received
键入641长度八位字节，不包括类型、长度和填充，发送时保留零，接收时忽略
IV Initialization vector, if needed, otherwise nonexistent. The length of the IV is inferred from the HIP_CIPHER. Encrypted The data is encrypted using the encryption algorithm data defined in the HIP_CIPHER parameter.
IV初始化向量，如果需要，否则不存在。IV的长度是根据HIP_密码推断出来的。加密使用HIP_CIPHER参数中定义的加密算法数据对数据进行加密。
The ENCRYPTED parameter encapsulates other parameters, the encrypted data, which holds one or more HIP parameters in block encrypted form.
加密参数封装了其他参数，即加密数据，它以块加密形式保存一个或多个HIP参数。
Consequently, the first fields in the encapsulated parameter(s) are Type and Length of the first such parameter, allowing the contents to be easily parsed after decryption.
因此，封装参数中的第一个字段是第一个这样的参数的类型和长度，允许在解密后容易地解析内容。
The field labeled "Encrypted data" consists of the output of one or more HIP parameters concatenated together that have been passed through an encryption algorithm. Each of these inner parameters is padded according to the rules of Section 5.2.1 for padding individual parameters. As a result, the concatenated parameters will be a block of data that is 8-byte aligned.
标记为“加密数据”的字段由一个或多个通过加密算法传递的HIP参数的输出组成。根据第5.2.1节填充单个参数的规则，填充每个内部参数。因此，连接的参数将是一个8字节对齐的数据块。
Some encryption algorithms require that the data to be encrypted must be a multiple of the cipher algorithm block size. In this case, the above block of data MUST include additional padding, as specified by the encryption algorithm. The size of the extra padding is selected so that the length of the unencrypted data block is a multiple of the cipher block size. The encryption algorithm may specify padding bytes other than zero; for example, AES [FIPS.197.2001] uses the PKCS5 padding scheme (see Section 6.1.1 of [RFC2898]) where the remaining n bytes to fill the block each have the value of n. This yields an "unencrypted data" block that is transformed to an "encrypted data" block by the cipher suite. This extra padding added to the set of parameters to satisfy the cipher block alignment rules is not counted in HIP TLV Length fields, and this extra padding should be removed by the cipher suite upon decryption.
某些加密算法要求要加密的数据必须是密码算法块大小的倍数。在这种情况下，上述数据块必须包括加密算法指定的额外填充。选择额外填充的大小，以便未加密数据块的长度是密码块大小的倍数。加密算法可以指定非零的填充字节；例如，AES[FIPS.197.2001]使用PKCS5填充方案（参见[RFC2898]第6.1.1节），其中填充块的剩余n字节的值均为n。这将产生一个“未加密数据”块，该块由密码套件转换为“加密数据”块。为满足密码块对齐规则而添加到参数集的额外填充不计入HIP TLV长度字段中，解密时密码套件应删除此额外填充。
Note that the length of the cipher suite output may be smaller or larger than the length of the set of parameters to be encrypted, since the encryption process may compress the data or add additional padding to the data.
注意，密码套件输出的长度可能小于或大于要加密的参数集的长度，因为加密过程可能压缩数据或向数据添加额外的填充。
Once this encryption process is completed, the Encrypted data field is ready for inclusion in the parameter. If necessary, additional Padding for 8-byte alignment is then added according to the rules of Section 5.2.1.
一旦此加密过程完成，加密数据字段就可以包含在参数中。如有必要，根据第5.2.1节的规则添加8字节对齐的额外填充。
The NOTIFICATION parameter is used to transmit informational data, such as error conditions and state transitions, to a HIP peer. A NOTIFICATION parameter may appear in NOTIFY packets. The use of the NOTIFICATION parameter in other packet types is for further study.
通知参数用于将信息数据（如错误条件和状态转换）传输到HIP对等方。通知参数可能出现在通知数据包中。在其他数据包类型中使用通知参数有待进一步研究。
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 | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ Notification Data /
/ +---------------+
/ | 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 | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ Notification Data /
/ +---------------+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 832 Length length in octets, excluding Type, Length, and Padding Reserved zero when sent, ignored when received Notify Message specifies the type of notification Type Notification informational or error data transmitted in Data addition to the Notify Message Type. Values for this field are type specific (see below).
类型832长度长度（以八位字节为单位），不包括类型、长度和填充。发送时保留零，接收时忽略通知消息指定除通知消息类型外，在数据中传输的通知类型、通知信息或错误数据的类型。此字段的值是特定于类型的（见下文）。
Notification information can be error messages specifying why a HIP Security Association could not be established. It can also be status data that a HIP implementation wishes to communicate with a peer process. The table below lists the notification messages and their Notify Message Types. HIP packets MAY contain multiple NOTIFICATION parameters if several problems exist or several independent pieces of information must be transmitted.
通知信息可以是错误消息，指定无法建立HIP安全关联的原因。它也可以是HIP实现希望与对等进程通信的状态数据。下表列出了通知消息及其通知消息类型。如果存在多个问题或必须传输多个独立的信息，HIP数据包可能包含多个通知参数。
To avoid certain types of attacks, a Responder SHOULD avoid sending a NOTIFICATION to any host with which it has not successfully verified a puzzle solution.
为了避免某些类型的攻击，响应者应该避免向任何未成功验证谜题解决方案的主机发送通知。
Notify Message Types in the range 0-16383 are intended for reporting errors, and those in the range 16384-65535 are for other status information. An implementation that receives a NOTIFY packet with a Notify Message Type that indicates an error in response to a request
0-16383范围内的通知消息类型用于报告错误，16384-65535范围内的通知消息类型用于其他状态信息。一种实现，它接收一个NOTIFY数据包，该数据包的NOTIFY消息类型指示响应请求时的错误
packet (e.g., I1, I2, UPDATE) SHOULD assume that the corresponding request has failed entirely. Unrecognized error types MUST be ignored, except that they SHOULD be logged.
数据包（例如，I1、I2、更新）应假定相应的请求已完全失败。必须忽略无法识别的错误类型，但应记录它们。
As currently defined, Notify Message Type values 1-10 are used for informing about errors in packet structures, and values 11-20 for informing about problems in parameters.
按照当前定义，Notify Message Type值1-10用于通知数据包结构中的错误，值11-20用于通知参数中的问题。
Notification Data in NOTIFICATION parameters where the Notify Message Type is in the status range MUST be ignored if not recognized.
如果无法识别，则必须忽略通知消息类型位于状态范围内的通知参数中的通知数据。
Notify Message Types - Errors Value
----------------------------- -----
Notify Message Types - Errors Value
----------------------------- -----
UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1
不支持的\u关键\u参数\u类型1
Sent if the parameter type has the "critical" bit set and the parameter type is not recognized. Notification Data contains the two-octet parameter type.
如果参数类型设置了“关键”位且无法识别参数类型，则发送。通知数据包含两个八位字节的参数类型。
INVALID_SYNTAX 7
无效的\u语法7
Indicates that the HIP message received was invalid because some type, length, or value was out of range or because the request was otherwise malformed. To avoid a denial-of-service attack using forged messages, this status may only be returned for packets whose HIP_MAC (if present) and SIGNATURE have been verified. This status MUST be sent in response to any error not covered by one of the other status types and SHOULD NOT contain details, to avoid leaking information to someone probing a node. To aid debugging, more detailed error information SHOULD be written to a console or log.
指示接收到的HIP消息无效，因为某些类型、长度或值超出范围，或者因为请求格式不正确。为了避免使用伪造消息的拒绝服务攻击，只有HIP_MAC（如果存在）和签名已被验证的数据包才能返回此状态。必须发送此状态以响应其他状态类型之一未包含的任何错误，并且不应包含详细信息，以避免将信息泄漏给探测节点的人。为了帮助调试，应将更详细的错误信息写入控制台或日志。
NO_DH_PROPOSAL_CHOSEN 14
未选择任何方案14
None of the proposed Group IDs were acceptable.
提议的组ID均不可接受。
INVALID_DH_CHOSEN 15
无效的_DH_选择15
The DH Group ID field does not correspond to one offered by the Responder.
DH Group ID字段与响应者提供的字段不对应。
NO_HIP_PROPOSAL_CHOSEN 16
没有选择HIP提案16
None of the proposed HIT Suites or HIP Encryption Algorithms were acceptable.
建议的HIT套件或HIP加密算法均不可接受。
INVALID_HIP_CIPHER_CHOSEN 17
无效\u HIP\u密码\u选择17
The HIP_CIPHER Crypto ID does not correspond to one offered by the Responder.
HIP_密码密码ID与响应者提供的ID不对应。
UNSUPPORTED_HIT_SUITE 20
不受支持的\u点击\u套件20
Sent in response to an I1 or R1 packet for which the HIT Suite is not supported.
为响应不支持HIT套件的I1或R1数据包而发送。
AUTHENTICATION_FAILED 24
身份验证失败24
Sent in response to a HIP signature failure, except when the signature verification fails in a NOTIFY message.
为响应HIP签名失败而发送，除非在NOTIFY消息中签名验证失败。
CHECKSUM_FAILED 26
校验和失败26
Sent in response to a HIP checksum failure.
为响应HIP校验和失败而发送。
HIP_MAC_FAILED 28
HIP_MAC_失败28
Sent in response to a HIP HMAC failure.
发送以响应HIP HMAC故障。
ENCRYPTION_FAILED 32
加密失败32
The Responder could not successfully decrypt the ENCRYPTED parameter.
响应程序无法成功解密加密的参数。
INVALID_HIT 40
打40分无效
Sent in response to a failure to validate the peer's HIT from the corresponding HI.
发送以响应验证来自相应HI的对等方命中失败。
BLOCKED_BY_POLICY 42
_被_策略阻止42
The Responder is unwilling to set up an association for some policy reason (e.g., the received HIT is NULL and the policy does not allow opportunistic mode).
由于某些策略原因，响应者不愿意建立关联（例如，收到的命中为空，策略不允许机会主义模式）。
RESPONDER_BUSY_PLEASE_RETRY 44
响应者\u忙\u请\u重试44
The Responder is unwilling to set up an association, as it is suffering under some kind of overload and has chosen to shed load by rejecting the Initiator's request. The Initiator may retry; however, the Initiator MUST find another (different) puzzle solution for any such retries. Note that the Initiator may need to obtain a new puzzle with a new I1/R1 exchange.
响应者不愿意建立一个关联，因为它正遭受某种过载的折磨，并选择通过拒绝发起者的请求来减轻负载。发起者可以重试；但是，发起人必须为任何此类重试找到另一个（不同的）谜题解决方案。注意，发起者可能需要使用新的I1/R1交换获得新的谜题。
Notify Message Types - Status Value
----------------------------- -----
Notify Message Types - Status Value
----------------------------- -----
I2_ACKNOWLEDGEMENT 16384
I2_确认16384
The Responder has an I2 packet from the Initiator but had to queue the I2 packet for processing. The puzzle was correctly solved, and the Responder is willing to set up an association but currently has a number of I2 packets in the processing queue. The R2 packet is sent after the I2 packet was processed.
响应者拥有来自启动器的I2数据包，但必须将I2数据包排队等待处理。谜题已正确解决，响应者愿意建立关联，但当前处理队列中有大量I2数据包。R2数据包在I2数据包处理后发送。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 897 Length length of the opaque data in octets Opaque data opaque data, supposed to be meaningful only to the node that sends ECHO_REQUEST_SIGNED and receives a corresponding ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED
键入897长度八位字节中不透明数据的长度不透明数据不透明数据，假定仅对发送已签名的ECHO_请求_并接收相应的已签名或未签名的ECHO_响应的节点有意义
The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data that the sender wants to get echoed back in the corresponding reply packet.
ECHO_REQUEST_SIGNED参数包含一个不透明的数据块，发送方希望在相应的回复数据包中得到回显。
The ECHO_REQUEST_SIGNED and corresponding echo response parameters MAY be used for any purpose where a node wants to carry some state in a request packet and get it back in a response packet. The ECHO_REQUEST_SIGNED is covered by the HIP_MAC and SIGNATURE. A HIP packet can contain only one ECHO_REQUEST_SIGNED parameter and MAY contain multiple ECHO_REQUEST_UNSIGNED parameters. The ECHO_REQUEST_SIGNED parameter MUST be responded to with an ECHO_RESPONSE_SIGNED.
ECHO_请求_签名和相应的ECHO响应参数可用于任何目的，其中节点希望在请求分组中携带某些状态并在响应分组中获取该状态。签名的回音请求包含在HIP\u MAC和签名中。HIP数据包只能包含一个ECHO\u REQUEST\u签名参数，并且可以包含多个ECHO\u REQUEST\u未签名参数。必须使用ECHO\u响应\u签名来响应ECHO\u请求\u签名参数。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 63661 Length length of the opaque data in octets Opaque data opaque data, supposed to be meaningful only to the node that sends ECHO_REQUEST_UNSIGNED and receives a corresponding ECHO_RESPONSE_UNSIGNED
键入63661长度八位字节中不透明数据的长度不透明数据不透明数据，假定仅对发送无符号ECHO_请求_并接收相应无符号ECHO_响应的节点有意义
The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data that the sender wants to get echoed back in the corresponding reply packet.
ECHO_REQUEST_UNSIGNED参数包含一个不透明的数据块，发送方希望在相应的回复数据包中得到回显。
The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters MAY be used for any purpose where a node wants to carry some state in a request packet and get it back in a response packet. The ECHO_REQUEST_UNSIGNED is not covered by the HIP_MAC and SIGNATURE. A HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters in HIP packets passing by. The creator of the ECHO_REQUEST_UNSIGNED (end host or middlebox) has to create the Opaque field so that it can later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED parameter.
ECHO_REQUEST_UNSIGNED和相应的ECHO-response参数可用于任何目的，其中节点希望在请求数据包中携带某些状态并将其返回到响应数据包中。HIP\u MAC和签名不包括未签名的回音请求。HIP数据包可以包含一个或多个ECHO\u REQUEST\u无符号参数。中间盒可能会在经过的HIP数据包中添加ECHO_REQUEST_UNSIGNED参数。ECHO\u REQUEST\u UNSIGNED（终端主机或中间盒）的创建者必须创建不透明字段，以便稍后可以识别并删除相应的ECHO\u RESPONSE\u UNSIGNED参数。
The ECHO_REQUEST_UNSIGNED parameter MUST be responded to with an ECHO_RESPONSE_UNSIGNED parameter.
必须使用ECHO_RESPONSE_UNSIGNED参数响应ECHO_REQUEST_UNSIGNED参数。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 961 Length length of the opaque data in octets Opaque data opaque data, copied unmodified from the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED parameter that triggered this response
键入961长度八位字节中不透明数据的长度不透明数据不透明数据，未经修改地从触发此响应的ECHO\u REQUEST\u SIGNED或ECHO\u REQUEST\u UNSIGNED参数复制
The ECHO_RESPONSE_SIGNED parameter contains an opaque blob of data that the sender of the ECHO_REQUEST_SIGNED wants to get echoed back. The opaque data is copied unmodified from the ECHO_REQUEST_SIGNED parameter.
ECHO_RESPONSE_SIGNED参数包含一个不透明的数据块，ECHO_请求_SIGNED的发送方希望得到回显。不透明数据从ECHO_REQUEST_SIGNED参数复制而来，不做任何修改。
The ECHO_REQUEST_SIGNED and ECHO_RESPONSE_SIGNED parameters MAY be used for any purpose where a node wants to carry some state in a request packet and get it back in a response packet. The ECHO_RESPONSE_SIGNED is covered by the HIP_MAC and SIGNATURE.
ECHO_REQUEST_SIGNED和ECHO_RESPONSE_SIGNED参数可用于任何目的，其中节点希望在请求数据包中携带某些状态并将其返回到响应数据包中。签名的回音响应包含在HIP\u MAC和签名中。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque data (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 63425 Length length of the opaque data in octets Opaque data opaque data, copied unmodified from the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED parameter that triggered this response
键入63425长度八位字节中不透明数据的长度不透明数据不透明数据，未经修改地从触发此响应的ECHO_请求_签名或ECHO_请求_未签名参数复制
The ECHO_RESPONSE_UNSIGNED parameter contains an opaque blob of data that the sender of the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED wants to get echoed back. The opaque data is copied unmodified from the corresponding echo request parameter.
ECHO_RESPONSE_UNSIGNED参数包含一个不透明的数据块，ECHO_请求_SIGNED或ECHO_请求_UNSIGNED的发送方希望得到回显。不透明数据未经修改地从相应的echo请求参数复制。
The echo request and ECHO_RESPONSE_UNSIGNED parameters MAY be used for any purpose where a node wants to carry some state in a request packet and get it back in a response packet. The ECHO_RESPONSE_UNSIGNED is not covered by the HIP_MAC and SIGNATURE.
echo request和echo_RESPONSE_UNSIGNED参数可用于节点希望在请求数据包中携带某种状态并在响应数据包中获取该状态的任何目的。HIP\u MAC和签名不包括未签名的回声响应。
There are eight basic HIP packets (see Table 11). Four are for the HIP base exchange, one is for updating, one is for sending notifications, and two are for closing a HIP association. Support for the NOTIFY packet type is optional, but support for all other HIP packet types listed below is mandatory.
有八种基本的髋关节包（见表11）。四个用于HIP base exchange，一个用于更新，一个用于发送通知，两个用于关闭HIP关联。对NOTIFY数据包类型的支持是可选的，但对下面列出的所有其他HIP数据包类型的支持是强制性的。
+------------------+------------------------------------------------+
| Packet type | Packet name |
+------------------+------------------------------------------------+
| 1 | I1 - the HIP Initiator Packet |
| | |
| 2 | R1 - the HIP Responder Packet |
| | |
| 3 | I2 - the Second HIP Initiator Packet |
| | |
| 4 | R2 - the Second HIP Responder Packet |
| | |
| 16 | UPDATE - the HIP Update Packet |
| | |
| 17 | NOTIFY - the HIP Notify Packet |
| | |
| 18 | CLOSE - the HIP Association Closing Packet |
| | |
| 19 | CLOSE_ACK - the HIP Closing Acknowledgment |
| | Packet |
+------------------+------------------------------------------------+
+------------------+------------------------------------------------+
| Packet type | Packet name |
+------------------+------------------------------------------------+
| 1 | I1 - the HIP Initiator Packet |
| | |
| 2 | R1 - the HIP Responder Packet |
| | |
| 3 | I2 - the Second HIP Initiator Packet |
| | |
| 4 | R2 - the Second HIP Responder Packet |
| | |
| 16 | UPDATE - the HIP Update Packet |
| | |
| 17 | NOTIFY - the HIP Notify Packet |
| | |
| 18 | CLOSE - the HIP Association Closing Packet |
| | |
| 19 | CLOSE_ACK - the HIP Closing Acknowledgment |
| | Packet |
+------------------+------------------------------------------------+
Table 11: HIP Packets and Packet Type Values
表11：HIP数据包和数据包类型值
Packets consist of the fixed header as described in Section 5.1, followed by the parameters. The parameter part, in turn, consists of zero or more TLV-coded parameters.
数据包由第5.1节中所述的固定报头和参数组成。参数部分又由零个或多个TLV编码参数组成。
In addition to the base packets, other packet types may be defined later in separate specifications. For example, support for mobility and multihoming is not included in this specification.
除了基本分组之外，其他分组类型可以稍后在单独的规范中定义。例如，本规范不包括对移动性和多址的支持。
See "Notation" (Section 2.2) for the notation used in the operations.
有关操作中使用的符号，请参见“符号”（第2.2节）。
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. The HIP packet, however, MUST NOT be fragmented into multiple extension headers by setting the Next Header field in a HIP header to the HIP protocol number. This limits the size of the possible additional data in the packet.
将来，可选的上层有效载荷可能会跟随HIP收割台。标题中的下一个标题字段指示髋部标题后是否有其他数据。但是，不得通过将HIP头中的下一个头字段设置为HIP协议号，将HIP数据包分割为多个扩展头。这限制了数据包中可能的附加数据的大小。
The HIP header values for the I1 packet:
I1数据包的HIP标头值：
Header: Packet Type = 1 SRC HIT = Initiator's HIT DST HIT = Responder's HIT, or NULL
标头：数据包类型=1 SRC HIT=发起方的HIT DST HIT=响应方的HIT，或NULL
IP ( HIP ( DH_GROUP_LIST ) )
IP（HIP（DH_组列表））
The I1 packet contains the fixed HIP header and the Initiator's DH_GROUP_LIST.
I1数据包包含固定HIP头和启动器的DH_组_列表。
Valid control bits: None
有效控制位：无
The Initiator receives the Responder's HIT from either a DNS lookup of the Responder's FQDN (see [HIP-DNS-EXT]), some other repository, or a local table. If the Initiator does not know the Responder's HIT, it may attempt to use opportunistic mode by using NULL (all zeros) as the Responder's HIT. See also "HIP Opportunistic Mode" (Section 4.1.8).
发起方从响应方FQDN的DNS查找（请参见[HIP-DNS-EXT]）、其他一些存储库或本地表接收响应方的命中。如果发起者不知道响应者的命中，它可能会尝试使用机会模式，使用NULL（全零）作为响应者的命中。另见“髋关节机会主义模式”（第4.1.8节）。
Since the I1 packet is so easy to spoof even if it were signed, no attempt is made to add to its generation or processing cost.
由于I1数据包即使经过签名也很容易被欺骗，因此不会增加其生成或处理成本。
The Initiator includes a DH_GROUP_LIST parameter in the I1 packet to inform the Responder of its preferred DH Group IDs. Note that the DH_GROUP_LIST in the I1 packet is not protected by a signature.
发起方在I1分组中包括DH_GROUP_LIST参数，以通知响应方其首选DH组id。请注意，I1数据包中的DH_组_列表不受签名保护。
Implementations MUST be able to handle a storm of received I1 packets, discarding those with common content that arrive within a small time delta.
实现必须能够处理大量接收到的I1数据包，丢弃那些在短时间内到达的具有公共内容的数据包。
The HIP header values for the R1 packet:
R1数据包的HIP标头值：
Header: Packet Type = 2 SRC HIT = Responder's HIT DST HIT = Initiator's HIT
标头：数据包类型=2 SRC HIT=响应者的HIT DST HIT=启动器的HIT
IP ( HIP ( [ R1_COUNTER, ] PUZZLE, DIFFIE_HELLMAN, HIP_CIPHER, HOST_ID, HIT_SUITE_LIST, DH_GROUP_LIST, [ ECHO_REQUEST_SIGNED, ] TRANSPORT_FORMAT_LIST, HIP_SIGNATURE_2 ) <, ECHO_REQUEST_UNSIGNED >i)
IP（HIP（[R1\u计数器，]PUZZLE，DIFFIE\u HELLMAN，HIP\u密码，主机ID，命中套件列表，DH组列表，[ECHO\u请求签名，]TRANSPORT\u格式列表，HIP\u签名\u 2）<，ECHO\u请求签名>i）
Valid control bits: A
有效控制位：A
If the Responder's HI is an anonymous one, the A control MUST be set.
如果响应者的HI是匿名的，则必须设置A控件。
The Initiator's HIT MUST match the one received in the I1 packet if the R1 is a response to an I1. If the Responder has multiple HIs, the Responder's HIT used MUST match the Initiator's request. If the Initiator used opportunistic mode, the Responder may select freely among its HIs. See also "HIP Opportunistic Mode" (Section 4.1.8).
如果R1是对I1的响应，则启动器的命中必须与I1数据包中接收到的命中匹配。如果响应者有多个HI，则响应者使用的HIT必须与启动器的请求相匹配。如果发起者使用机会主义模式，响应者可以在其HI中自由选择。另见“髋关节机会主义模式”（第4.1.8节）。
The R1 packet generation counter is used to determine the currently valid generation of puzzles. The value is increased periodically, and it is RECOMMENDED that it is increased at least as often as solutions to old puzzles are no longer accepted.
R1数据包生成计数器用于确定当前有效的拼图生成。该值会定期增加，建议至少在不再接受旧谜题的解决方案时增加该值。
The puzzle contains a Random #I and the difficulty #K. The difficulty #K indicates the number of lower-order bits, in the puzzle hash result, that must be zeros; see Section 4.1.2. The Random #I is not covered by the signature and must be zeroed during the signature calculation, allowing the sender to select and set the #I into a precomputed R1 packet just prior to sending it to the peer.
该拼图包含一个随机的#I和难度#K。难度#K表示拼图哈希结果中必须为零的低阶位的数量；见第4.1.2节。随机#I不包含在签名中，必须在签名计算期间归零，从而允许发送方在将其发送给对等方之前选择并将#I设置为预计算的R1数据包。
The Responder selects the DIFFIE_HELLMAN Group ID and Public Value based on the Initiator's preference expressed in the DH_GROUP_LIST parameter in the I1 packet. The Responder sends back its own preference based on which it chose the DH public value as
响应者根据I1数据包中DH_Group_列表参数中表示的启动器偏好选择DIFFIE_HELLMAN组ID和公共值。响应者发回自己的首选项，并根据该首选项选择DH公共值作为
DH_GROUP_LIST. This allows the Initiator to determine whether its own DH_GROUP_LIST in the sent I1 packet was manipulated by an attacker.
DH_组_列表。这允许启动器确定发送的I1数据包中自己的DH_组_列表是否被攻击者操纵。
The Diffie-Hellman public value is ephemeral, and values SHOULD NOT be reused across different HIP associations. Once the Responder has received a valid response to an R1 packet, that Diffie-Hellman value SHOULD be deprecated. It is possible that the Responder has sent the same Diffie-Hellman value to different hosts simultaneously in corresponding R1 packets, and those responses should also be accepted. However, as a defense against I1 packet storms, an implementation MAY propose, and reuse unless avoidable, the same Diffie-Hellman value for a period of time -- for example, 15 minutes. By using a small number of different puzzles for a given Diffie-Hellman value, the R1 packets can be precomputed and delivered as quickly as I1 packets arrive. A scavenger process should clean up unused Diffie-Hellman values and puzzles.
Diffie-Hellman公共值是短暂的，不应在不同的HIP关联中重用这些值。一旦响应程序接收到对R1数据包的有效响应，应该弃用Diffie-Hellman值。响应者可能在相应的R1数据包中同时向不同的主机发送了相同的Diffie-Hellman值，并且这些响应也应该被接受。然而，作为对I1数据包风暴的防御，一个实现可能会提出相同的Diffie-Hellman值，并在一段时间内重复使用，除非可以避免，例如15分钟。通过对给定的Diffie-Hellman值使用少量不同的谜题，R1数据包可以在I1数据包到达时进行预计算和交付。清除程序应该清除未使用的Diffie-Hellman值和谜题。
Reusing Diffie-Hellman public values opens up the potential security risk of more than one Initiator ending up with the same keying material (due to faulty random number generators). Also, more than one Initiator using the same Responder public key half may lead to potentially easier cryptographic attacks and to imperfect forward security.
重复使用Diffie-Hellman公共值会导致多个启动器使用相同的密钥材料（由于随机数生成器出现故障）的潜在安全风险。此外，多个启动器使用相同的响应者公钥可能会导致潜在的更容易的加密攻击和不完善的前向安全性。
However, these risks involved in reusing the same public value are statistical; that is, the authors are not aware of any mechanism that would allow manipulation of the protocol so that the risk of the reuse of any given Responder Diffie-Hellman public key would differ from the base probability. Consequently, it is RECOMMENDED that Responders avoid reusing the same DH key with multiple Initiators, but because the risk is considered statistical and not known to be manipulable, the implementations MAY reuse a key in order to ease resource-constrained implementations and to increase the probability of successful communication with legitimate clients even under an I1 packet storm. In particular, when it is too expensive to generate enough precomputed R1 packets to supply each potential Initiator with a different DH key, the Responder MAY send the same DH key to several Initiators, thereby creating the possibility of multiple legitimate Initiators ending up using the same Responder-side public key. However, as soon as the Responder knows that it will use a particular DH key, it SHOULD stop offering it. This design is aimed to allow resource-constrained Responders to offer services under I1 packet storms and to simultaneously make the probability of DH key reuse both statistical and as low as possible.
然而，重复使用相同公共价值所涉及的这些风险是统计性的；也就是说，作者不知道任何机制会允许操纵协议，从而使任何给定响应者Diffie-Hellman公钥的重用风险与基本概率不同。因此，建议响应者避免对多个启动器重复使用同一DH密钥，但因为风险被认为是统计性的，并且不可操作，这些实现可以重用密钥，以便简化资源受限的实现，并增加即使在I1分组风暴下与合法客户端成功通信的概率。特别地，当生成足够的预计算R1分组以向每个潜在发起方提供不同的DH密钥过于昂贵时，响应方可以向多个发起方发送相同的DH密钥，从而产生多个合法发起方最终使用相同的响应方公钥的可能性。但是，一旦响应者知道它将使用特定的DH密钥，它就应该停止提供该密钥。该设计旨在允许资源受限的响应者在I1数据包风暴下提供服务，同时使DH密钥重用的概率在统计上尽可能低。
If the Responder uses the same DH key pair for multiple handshakes, it must take care to avoid small subgroup attacks [RFC2785]. To avoid these attacks, when receiving the I2 message, the Responder SHOULD validate the Initiator's DH public key as described in [RFC2785], Section 3.1. If the validation fails, the Responder MUST NOT generate a DH shared key and MUST silently abort the HIP BEX.
如果响应者使用相同的DH密钥对进行多次握手，则必须注意避免小子组攻击[RFC2785]。为了避免这些攻击，当收到I2消息时，响应者应按照[RFC2785]第3.1节中的说明验证启动器的DH公钥。如果验证失败，响应者不得生成DH共享密钥，并且必须以静默方式中止HIP BEX。
The HIP_CIPHER parameter contains the encryption algorithms supported by the Responder to encrypt the contents of the ENCRYPTED parameter, in the order of preference. All implementations MUST support AES [RFC3602].
HIP_CIPHER参数包含响应程序支持的加密算法，用于按照首选顺序加密加密参数的内容。所有实现必须支持AES[RFC3602]。
The HIT_SUITE_LIST parameter is an ordered list of the Responder's preferred and supported HIT Suites. The list allows the Initiator to determine whether its own source HIT matches any suite supported by the Responder.
HIT_SUITE_LIST参数是响应者首选和支持的HIT套件的有序列表。该列表允许启动器确定其自己的源命中是否与响应程序支持的任何套件匹配。
The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED parameters contain data that the sender wants to receive unmodified in the corresponding response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero or more ECHO_REQUEST_UNSIGNED parameters as described in Section 5.2.21.
ECHO_-REQUEST_-SIGNED和ECHO_-REQUEST_-UNSIGNED参数包含发送方希望在ECHO_-response_-SIGNED或ECHO_-response_-UNSIGNED参数的相应响应数据包中未经修改地接收的数据。如第5.2.21节所述，R1数据包可能包含零个或多个ECHO_REQUEST_无符号参数。
The TRANSPORT_FORMAT_LIST parameter is an ordered list of the Responder's preferred and supported transport format types. The list allows the Initiator and the Responder to agree on a common type for payload protection. This parameter is described in Section 5.2.11.
TRANSPORT_FORMAT_LIST参数是响应者首选和支持的传输格式类型的有序列表。该列表允许发起方和响应方就有效负载保护的通用类型达成一致。第5.2.11节描述了该参数。
The signature is calculated over the whole HIP packet as described in Section 5.2.15. This allows the Responder to use precomputed R1s. The Initiator SHOULD validate this signature. It MUST check that the Responder's HI matches with the one expected, if any.
如第5.2.15节所述，在整个臀部数据包上计算签名。这允许响应者使用预计算的R1s。发起人应验证此签名。它必须检查响应者的HI是否与预期的HI匹配（如果有）。
The HIP header values for the I2 packet:
I2数据包的HIP标头值：
Header: Packet Type = 3 SRC HIT = Initiator's HIT DST HIT = Responder's HIT
标头：数据包类型=3 SRC HIT=发起方的HIT DST HIT=响应方的HIT
IP ( HIP ( [R1_COUNTER,] SOLUTION, DIFFIE_HELLMAN, HIP_CIPHER, ENCRYPTED { HOST_ID } or HOST_ID, [ ECHO_RESPONSE_SIGNED, ] TRANSPORT_FORMAT_LIST, HIP_MAC, HIP_SIGNATURE <, ECHO_RESPONSE_UNSIGNED>i ) )
IP（HIP（[R1_计数器，]解决方案，DIFFIE_HELLMAN，HIP_密码，加密的{HOST_ID}或HOST_ID，[ECHO_RESPONSE_签名，]TRANSPORT_FORMAT_列表，HIP_MAC，HIP_签名<，ECHO_RESPONSE_UNSIGNED>i））
Valid control bits: A
有效控制位：A
The HITs used MUST match the ones used in the R1.
使用的命中数必须与R1中使用的命中数匹配。
If the Initiator's HI is an anonymous one, the A control bit MUST be set.
如果启动器的HI是匿名的，则必须设置A控制位。
If present in the I1 packet, the Initiator MUST include an unmodified copy of the R1_COUNTER parameter received in the corresponding R1 packet into the I2 packet.
如果I1数据包中存在，则启动器必须将相应R1数据包中接收的R1_计数器参数的未修改副本包含在I2数据包中。
The Solution contains the Random #I from R1 and the computed #J. The low-order #K bits of the RHASH( #I | ... | #J ) MUST be zero.
该解包含来自R1的随机#I和计算的#J。RHASH（#I |…| J）的低阶#K位必须为零。
The Diffie-Hellman value is ephemeral. If precomputed, a scavenger process should clean up unused Diffie-Hellman values. The Responder MAY reuse Diffie-Hellman values under some conditions as specified in Section 5.3.2.
Diffie-Hellman值是短暂的。如果预先计算，清道夫进程应该清理未使用的Diffie-Hellman值。响应者可在第5.3.2节规定的某些条件下重新使用Diffie-Hellman值。
The HIP_CIPHER contains the single encryption suite selected by the Initiator, that it uses to encrypt the ENCRYPTED parameters. The chosen cipher MUST correspond to one of the ciphers offered by the Responder in the R1. All implementations MUST support AES [RFC3602].
HIP_密码包含启动器选择的单个加密套件，用于加密加密参数。所选密码必须与R1中响应者提供的密码之一相对应。所有实现必须支持AES[RFC3602]。
The Initiator's HI MAY be encrypted using the HIP_CIPHER encryption algorithm. The keying material is derived from the Diffie-Hellman exchange as defined in Section 6.5.
可以使用HIP_密码加密算法对启动器的HI进行加密。键控材料来源于第6.5节定义的Diffie-Hellman交换。
The ECHO_RESPONSE_SIGNED and ECHO_RESPONSE_UNSIGNED contain the unmodified opaque data copied from the corresponding echo request parameter(s).
ECHO_RESPONSE_SIGNED和ECHO_RESPONSE_UNSIGNED包含从相应的ECHO请求参数复制的未修改的不透明数据。
The TRANSPORT_FORMAT_LIST contains the single transport format type selected by the Initiator. The chosen type MUST correspond to one of the types offered by the Responder in the R1. Currently, the only transport format defined is the ESP transport format ([RFC7402]).
传输格式列表包含启动器选择的单一传输格式类型。所选类型必须与R1中响应程序提供的类型之一相对应。目前，唯一定义的传输格式是ESP传输格式（[RFC7402]）。
The HMAC value in the HIP_MAC parameter is calculated over the whole HIP packet, excluding any parameters after the HIP_MAC, as described in Section 6.4.1. The Responder MUST validate the HIP_MAC.
HIP_MAC参数中的HMAC值在整个HIP数据包上计算，不包括HIP_MAC之后的任何参数，如第6.4.1节所述。响应者必须验证HIP_MAC。
The signature is calculated over the whole HIP packet, excluding any parameters after the HIP_SIGNATURE, as described in Section 5.2.14. The Responder MUST validate this signature. The Responder uses the HI in the packet or an HI acquired by some other means for verifying the signature.
如第5.2.14节所述，在整个HIP数据包上计算签名，不包括HIP_签名后的任何参数。响应者必须验证此签名。响应者使用分组中的HI或通过某些其他手段获取的HI来验证签名。
The HIP header values for the R2 packet:
R2数据包的HIP标头值：
Header: Packet Type = 4 SRC HIT = Responder's HIT DST HIT = Initiator's HIT
标头：数据包类型=4 SRC HIT=响应者的HIT DST HIT=启动器的HIT
IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) )
IP（HIP（HIP_MAC_2，HIP_签名））
Valid control bits: None
有效控制位：无
The HIP_MAC_2 is calculated over the whole HIP packet, with the Responder's HOST_ID parameter concatenated with the HIP packet. The HOST_ID parameter is removed after the HMAC calculation. The procedure is described in Section 6.4.1.
HIP_MAC_2在整个HIP分组上计算，响应者的HOST_ID参数与HIP分组连接。主机ID参数在HMAC计算后删除。第6.4.1节描述了该程序。
The signature is calculated over the whole HIP packet.
签名是在整个HIP数据包上计算的。
The Initiator MUST validate both the HIP_MAC and the signature.
发起人必须验证HIP_MAC和签名。
The HIP header values for the UPDATE packet:
更新数据包的HIP标头值：
Header: Packet Type = 16 SRC HIT = Sender's HIT DST HIT = Recipient's HIT
标题：数据包类型=16 SRC HIT=发送方的HIT DST HIT=接收方的HIT
IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) )
IP（HIP（[顺序，确认，]HIP\u MAC，HIP\u签名））
Valid control bits: None
有效控制位：无
The UPDATE packet contains mandatory HIP_MAC and HIP_SIGNATURE parameters, and other optional parameters.
更新包包含必需的HIP_MAC和HIP_签名参数以及其他可选参数。
The UPDATE packet contains zero or one SEQ parameter. The presence of a SEQ parameter indicates that the receiver MUST acknowledge the UPDATE. An UPDATE that does not contain a SEQ but only an ACK parameter is simply an acknowledgment of a previous UPDATE and itself MUST NOT be acknowledged by a separate ACK parameter. Such UPDATE packets containing only an ACK parameter do not require processing in relative order to other UPDATE packets. An UPDATE packet without either a SEQ or an ACK parameter is invalid; such unacknowledged updates MUST instead use a NOTIFY packet.
更新数据包包含零个或一个SEQ参数。SEQ参数的存在表示接收器必须确认更新。不包含SEQ但仅包含ACK参数的更新仅是对先前更新的确认，其本身不得由单独的ACK参数确认。这种仅包含ACK参数的更新包不需要按照相对于其他更新包的顺序进行处理。没有SEQ或ACK参数的更新包无效；这种未确认的更新必须改为使用NOTIFY数据包。
An UPDATE packet contains zero or one ACK parameter. The ACK parameter echoes the SEQ sequence number of the UPDATE packet being ACKed. A host MAY choose to acknowledge more than one UPDATE packet at a time; e.g., the ACK parameter may contain the last two SEQ values received, for resilience against packet loss. ACK values are not cumulative; each received unique SEQ value requires at least one corresponding ACK value in reply. Received ACK parameters that are redundant are ignored. Hosts MUST implement the processing of ACK parameters with multiple SEQ sequence numbers even if they do not implement sending ACK parameters with multiple SEQ sequence numbers.
更新数据包包含零个或一个ACK参数。ACK参数回显正在确认的更新包的SEQ序列号。主机可以选择一次确认多个更新分组；e、 例如，ACK参数可以包含接收到的最后两个SEQ值，以抵抗分组丢失。ACK值不是累积的；每个收到的唯一SEQ值都需要至少一个对应的ACK值作为应答。忽略接收到的冗余ACK参数。主机必须使用多个序列号执行ACK参数的处理，即使它们没有使用多个序列号执行发送ACK参数。
The UPDATE packet may contain both a SEQ and an ACK parameter. In this case, the ACK parameter is being piggybacked on an outgoing UPDATE. In general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the processing of the UPDATE. A host MAY choose to hold the UPDATE carrying an ACK parameter for a short period of time to allow for the possibility of piggybacking the ACK parameter, in a manner similar to TCP delayed acknowledgments.
更新分组可以同时包含SEQ和ACK参数。在本例中，ACK参数是在传出更新时附带的。一般来说，携带SEQ的更新应在更新处理完成后确认。主机可以选择将携带ACK参数的更新保持短时间，以允许以类似于TCP延迟确认的方式携带ACK参数。
A sender MAY choose to forego reliable transmission of a particular UPDATE (e.g., it becomes overcome by events). The semantics are such that the receiver MUST acknowledge the UPDATE, but the sender MAY choose to not care about receiving the ACK parameter.
发送方可以选择放弃特定更新的可靠传输（例如，它被事件所克服）。语义是这样的，接收方必须确认更新，但发送方可以选择不关心接收ACK参数。
UPDATEs MAY be retransmitted without incrementing SEQ. If the same subset of parameters is included in multiple UPDATEs with different SEQs, the host MUST ensure that the receiver's processing of the parameters multiple times will not result in a protocol error.
更新可以在不增加SEQ的情况下重新传输。如果相同的参数子集包含在具有不同seq的多个更新中，则主机必须确保接收器多次处理参数不会导致协议错误。
The NOTIFY packet MAY be used to provide information to a peer. Typically, NOTIFY is used to indicate some type of protocol error or negotiation failure. NOTIFY packets are unacknowledged. The receiver can handle the packet only as informational, and SHOULD NOT change its HIP state (see Section 4.4.2) based purely on a received NOTIFY packet.
通知分组可用于向对等方提供信息。通常，NOTIFY用于指示某种类型的协议错误或协商失败。通知数据包未被确认。接收方只能将数据包作为信息处理，不应纯粹根据接收到的NOTIFY数据包更改其HIP状态（见第4.4.2节）。
The HIP header values for the NOTIFY packet:
NOTIFY数据包的HIP标头值：
Header: Packet Type = 17 SRC HIT = Sender's HIT DST HIT = Recipient's HIT, or zero if unknown
标头：数据包类型=17 SRC HIT=发送方的HIT DST HIT=接收方的HIT，如果未知，则为零
IP ( HIP (<NOTIFICATION>i, [HOST_ID, ] HIP_SIGNATURE) )
IP（HIP（<NOTIFICATION>i，[HOST\u ID，]HIP\u签名））
Valid control bits: None
有效控制位：无
The NOTIFY packet is used to carry one or more NOTIFICATION parameters.
NOTIFY数据包用于携带一个或多个通知参数。
The HIP header values for the CLOSE packet:
关闭数据包的HIP标头值：
Header: Packet Type = 18 SRC HIT = Sender's HIT DST HIT = Recipient's HIT
标题：数据包类型=18 SRC HIT=发送方的HIT DST HIT=接收方的HIT
IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) )
IP（HIP（回波请求签名、HIP MAC、HIP签名））
Valid control bits: None
有效控制位：无
The sender MUST include an ECHO_REQUEST_SIGNED used to validate CLOSE_ACK received in response, and both a HIP_MAC and a signature (calculated over the whole HIP packet).
发送方必须包括一个用于验证响应中收到的CLOSE_ACK的ECHO_请求_签名，以及一个HIP_MAC和一个签名（在整个HIP数据包上计算）。
The receiver peer MUST reply with a CLOSE_ACK containing an ECHO_RESPONSE_SIGNED corresponding to the received ECHO_REQUEST_SIGNED.
接收方对等方必须回复一个CLOSE_ACK，其中包含一个与接收到的ECHO_请求\u签名相对应的ECHO_响应\u签名。
The HIP header values for the CLOSE_ACK packet:
CLOSE_ACK数据包的HIP标头值：
Header: Packet Type = 19 SRC HIT = Sender's HIT DST HIT = Recipient's HIT
标题：数据包类型=19 SRC HIT=发送方的HIT DST HIT=接收方的HIT
IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) )
IP（HIP（回波响应签名、HIP MAC、HIP签名））
Valid control bits: None
有效控制位：无
The sender MUST include both an HMAC and signature (calculated over the whole HIP packet).
发送方必须包括HMAC和签名（在整个HIP数据包上计算）。
The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate both the HIP_MAC and the signature if the receiver has state for a HIP association.
如果接收器具有HIP关联的状态，则接收器对等方必须验证已签名的回声响应，并验证HIP MAC和签名。
When a HIP implementation detects a problem with an incoming packet, and it either cannot determine the identity of the sender of the packet or does not have any existing HIP association with the sender of the packet, it MAY respond with an ICMP packet. Any such replies MUST be rate-limited as described in [RFC4443]. In most cases, the ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for ICMPv6), with the Pointer pointing to the field that caused the ICMP message to be generated.
当HIP实现检测到传入数据包的问题，并且它不能确定数据包发送方的身份或者与数据包发送方没有任何现有的HIP关联时，它可以使用ICMP数据包进行响应。任何此类回复必须按照[RFC4443]中所述的速率限制。在大多数情况下，ICMP数据包具有参数问题类型（12表示ICMPv4，4表示ICMPv6），指针指向导致生成ICMP消息的字段。
If a HIP implementation receives a HIP packet that has an unrecognized HIP version number, it SHOULD respond, rate-limited, with an ICMP packet with type Parameter Problem, with the Pointer pointing to the Version/RES. byte in the HIP header.
如果HIP实现接收到具有无法识别的HIP版本号的HIP数据包，则它应以速率受限的方式响应具有类型参数问题的ICMP数据包，指针指向HIP标头中的version/RES.字节。
If a HIP implementation receives a HIP packet that has other unrecoverable problems in the header or packet format, it MAY respond, rate-limited, with an ICMP packet with type Parameter Problem, with the Pointer pointing to the field that failed to pass the format checks. However, an implementation MUST NOT send an ICMP message if the checksum fails; instead, it MUST silently drop the packet.
如果HIP实现接收到在报头或数据包格式中存在其他不可恢复问题的HIP数据包，它可能会以速率受限的方式响应具有类型参数问题的ICMP数据包，指针指向未能通过格式检查的字段。但是，如果校验和失败，则实现不得发送ICMP消息；相反，它必须默默地丢弃数据包。
If a HIP implementation receives an I2 packet that has an invalid puzzle solution, the behavior depends on the underlying version of IP. If IPv6 is used, the implementation SHOULD respond with an ICMP packet with type Parameter Problem, with the Pointer pointing to the beginning of the Puzzle solution #J field in the SOLUTION payload in the HIP message.
如果HIP实现接收到具有无效谜题解决方案的I2数据包，则行为取决于IP的底层版本。如果使用IPv6，则实现应使用带有类型参数问题的ICMP数据包进行响应，指针指向HIP消息中解决方案有效负载中谜题解决方案#J字段的开头。
If IPv4 is used, the implementation MAY respond with an ICMP packet with the type Parameter Problem, copying enough bytes from the I2 message so that the SOLUTION parameter fits into the ICMP message, with the Pointer pointing to the beginning of the Puzzle solution #J field, as in the IPv6 case. Note, however, that the resulting ICMPv4 message exceeds the typical ICMPv4 message size as defined in [RFC0792].
如果使用IPv4，则实现可能会响应带有类型参数问题的ICMP数据包，从I2消息复制足够的字节，以便解决方案参数适合ICMP消息，指针指向拼图解决方案#J字段的开头，如IPv6情况。但是，请注意，生成的ICMPv4消息超出了[RFC0792]中定义的典型ICMPv4消息大小。
If a HIP implementation receives a CLOSE or UPDATE packet, or any other packet whose handling requires an existing association, that has either a Receiver or Sender HIT that does not match with any existing HIP association, the implementation MAY respond, rate-limited, with an ICMP packet with the type Parameter Problem. The Pointer of the ICMP Parameter Problem packet is set pointing to the beginning of the first HIT that does not match.
如果HIP实现接收到CLOSE或UPDATE数据包，或其处理需要现有关联的任何其他数据包，该数据包的接收方或发送方命中与任何现有HIP关联不匹配，则该实现可能会以速率受限的方式响应具有类型参数问题的ICMP数据包。ICMP参数问题数据包的指针设置为指向不匹配的第一次命中的开始。
A host MUST NOT reply with such an ICMP if it receives any of the following messages: I1, R2, I2, R2, and NOTIFY packet. When introducing new packet types, a specification SHOULD define the appropriate rules for sending or not sending this kind of ICMP reply.
如果主机收到以下任何消息：I1、R2、I2、R2和NOTIFY数据包，则不得使用此类ICMP进行回复。在引入新的数据包类型时，规范应定义发送或不发送此类ICMP应答的适当规则。
Each host is assumed to have a single HIP implementation that manages the host's HIP associations and handles requests for new ones. Each HIP association is governed by a conceptual state machine, with states defined above in Section 4.4. The HIP implementation can
假设每个主机都有一个HIP实现，用于管理主机的HIP关联并处理新的HIP关联请求。每个髋关节关联由一个概念状态机控制，状态定义见上文第4.4节。HIP实现可以
simultaneously maintain HIP associations with more than one host. Furthermore, the HIP implementation may have more than one active HIP association with another host; in this case, HIP associations are distinguished by their respective HITs. It is not possible to have more than one HIP association between any given pair of HITs. Consequently, the only way for two hosts to have more than one parallel association is to use different HITs, at least at one end.
同时与多个宿主保持髋部关联。此外，HIP实现可以具有与另一主机的多个活动HIP关联；在这种情况下，髋关节协会通过其各自的点击来区分。在任何给定的两次点击之间不可能有多个髋部关联。因此，两台主机拥有多个并行关联的唯一方法是使用不同的命中，至少是一端。
The processing of packets depends on the state of the HIP association(s) with respect to the authenticated or apparent originator of the packet. A HIP implementation determines whether it has an active association with the originator of the packet based on the HITs. In the case of user data carried in a specific transport format, the transport format document specifies how the incoming packets are matched with the active associations.
数据包的处理取决于与数据包的已认证或明显发起人相关的HIP关联的状态。HIP实现基于点击确定它是否与数据包的发起人有活动关联。对于以特定传输格式携带的用户数据，传输格式文档指定如何将传入数据包与活动关联相匹配。
In a HIP host, an application can send application-level data using an identifier specified via the underlying API. The API can be a backwards-compatible API (see [RFC5338]), using identifiers that look similar to IP addresses, or a completely new API, providing enhanced services related to Host Identities. Depending on the HIP implementation, the identifier provided to the application may be different; for example, it can be a HIT or an IP address.
在HIP主机中，应用程序可以使用通过底层API指定的标识符发送应用程序级数据。该API可以是向后兼容的API（请参见[RFC5338]），使用看起来类似于IP地址的标识符，也可以是全新的API，提供与主机标识相关的增强服务。根据HIP实现，提供给应用程序的标识符可能不同；例如，它可以是HIT或IP地址。
The exact format and method for transferring the user data from the source HIP host to the destination HIP host are defined in the corresponding transport format document. The actual data is transferred in the network using the appropriate source and destination IP addresses.
将用户数据从源HIP主机传输到目标HIP主机的确切格式和方法在相应的传输格式文档中定义。实际数据使用适当的源和目标IP地址在网络中传输。
In this document, conceptual processing rules are defined only for the base case where both hosts have only single usable IP addresses; the multi-address multihoming case is specified separately.
在本文档中，概念处理规则仅针对两台主机只有一个可用IP地址的基本情况定义；多地址多归属情况单独指定。
The following conceptual algorithm describes the steps that are required for handling outgoing datagrams destined to a HIT.
以下概念算法描述了处理发送到HIT的传出数据报所需的步骤。
1. If the datagram has a specified source address, it MUST be a HIT. If it is not, the implementation MAY replace the source address with a HIT. Otherwise, it MUST drop the packet.
1. 如果数据报具有指定的源地址，则它必须是命中的。如果不是，实现可能会用HIT替换源地址。否则，它必须丢弃数据包。
2. If the datagram has an unspecified source address, the implementation MUST choose a suitable source HIT for the datagram. Selecting the source HIT is subject to local policy.
2. 如果数据报具有未指定的源地址，则实现必须为数据报选择合适的源命中。选择源命中取决于本地策略。
3. If there is no active HIP association with the given <source, destination> HIT pair, one MUST be created by running the base exchange. While waiting for the base exchange to complete, the implementation SHOULD queue at least one user data packet per HIP association to be formed, and it MAY queue more than one.
3. 如果给定的<source，destination>命中对没有活动的髋部关联，则必须通过运行base exchange创建一个。在等待基本交换完成时，实现应该对每个要形成的HIP关联排队至少一个用户数据包，并且它可以对多个用户数据包排队。
4. Once there is an active HIP association for the given <source, destination> HIT pair, the outgoing datagram is passed to transport handling. The possible transport formats are defined in separate documents, of which the ESP transport format for HIP is mandatory for all HIP implementations.
4. 一旦给定的<source，destination>命中对存在活动HIP关联，传出数据报将传递给传输处理。可能的传输格式在单独的文档中定义，其中HIP的ESP传输格式对于所有HIP实施都是强制性的。
5. Before sending the packet, the HITs in the datagram are replaced with suitable IP addresses. For IPv6, the rules defined in [RFC6724] SHOULD be followed. Note that this HIT-to-IP-address conversion step MAY also be performed at some other point in the stack, e.g., before wrapping the packet into the output format.
5. 在发送数据包之前，数据报中的点击被替换为合适的IP地址。对于IPv6，应遵循[RFC6724]中定义的规则。注意，该命中到IP地址转换步骤也可以在堆栈中的某个其他点执行，例如，在将分组包装成输出格式之前。
The following conceptual algorithm describes the incoming datagram handling when HITs are used at the receiving host as application-level identifiers. More detailed steps for processing packets are defined in corresponding transport format documents.
以下概念性算法描述了在接收主机上使用命中作为应用程序级标识符时的传入数据报处理。处理数据包的更详细步骤在相应的传输格式文档中定义。
1. The incoming datagram is mapped to an existing HIP association, typically using some information from the packet. For example, such mapping may be based on the ESP Security Parameter Index (SPI).
1. 传入的数据报通常使用来自数据包的一些信息映射到现有的HIP关联。例如，这种映射可以基于ESP安全参数索引（SPI）。
2. The specific transport format is unwrapped, in a way depending on the transport format, yielding a packet that looks like a standard (unencrypted) IP packet. If possible, this step SHOULD also verify that the packet was indeed (once) sent by the remote HIP host, as identified by the HIP association.
2. 根据传输格式的不同，特定的传输格式被展开，生成一个看起来像标准（未加密）IP数据包的数据包。如果可能，此步骤还应验证该数据包确实（一次）由远程HIP主机发送，如HIP关联所识别。
Depending on the used transport mode, the verification method can vary. While the HI (as well as the HIT) is used as the higher-layer identifier, the verification method has to verify that the data packet was sent by the correct node identity and that the actual identity maps to this particular HIT. When using the ESP transport format [RFC7402], the verification is done using the SPI value in the data packet to find the corresponding SA with associated HIT and key, and decrypting the packet with that associated key.
根据使用的运输模式，验证方法可能会有所不同。当HI（以及HIT）用作更高层标识符时，验证方法必须验证数据包是否由正确的节点标识发送，并且实际标识是否映射到该特定HIT。当使用ESP传输格式[RFC7402]时，使用数据包中的SPI值进行验证，以找到具有关联命中和密钥的相应SA，并使用该关联密钥解密数据包。
3. The IP addresses in the datagram are replaced with the HITs associated with the HIP association. Note that this IP-address-to-HIT conversion step MAY also be performed at some other point in the stack.
3. 数据报中的IP地址将替换为与HIP关联相关的命中。请注意，此IP地址到命中的转换步骤也可以在堆栈中的某个其他点执行。
4. The datagram is delivered to the upper layer (e.g., UDP or TCP). When demultiplexing the datagram, the right upper-layer socket is selected based on the HITs.
4. 数据报被传送到上层（例如UDP或TCP）。当解复用数据报时，将根据点击选择右上层套接字。
This subsection describes the details for solving the puzzle.
本小节描述了解决此难题的细节。
In the R1 packet, the values #I and #K are sent in network byte order. Similarly, in the I2 packet, the values #I and #J are sent in network byte order. The hash is created by concatenating, in network byte order, the following data, in the following order and using the RHASH algorithm:
在R1数据包中，值#I和#K以网络字节顺序发送。类似地，在I2数据包中，值#I和#J以网络字节顺序发送。哈希是通过使用RHASH算法，按网络字节顺序，按以下顺序连接以下数据而创建的：
n-bit random value #I (where n is RHASH_len), in network byte order, as appearing in the R1 and I2 packets.
n位随机值#I（其中n为RHASH_len），按网络字节顺序，如R1和I2数据包中所示。
128-bit Initiator's HIT, in network byte order, as appearing in the HIP Payload in the R1 and I2 packets.
128位启动器的命中，按网络字节顺序，出现在R1和I2数据包的HIP有效负载中。
128-bit Responder's HIT, in network byte order, as appearing in the HIP Payload in the R1 and I2 packets.
128位响应程序的命中，按网络字节顺序，显示在R1和I2数据包的HIP有效载荷中。
n-bit random value #J (where n is RHASH_len), in network byte order, as appearing in the I2 packet.
n位随机值#J（其中n是RHASH_len），按网络字节顺序，如I2数据包中所示。
In a valid response puzzle, the #K low-order bits of the resulting RHASH digest MUST be zero.
在有效的响应谜题中，生成的RHASH摘要的#K低位必须为零。
Notes:
笔记：
i) The length of the data to be hashed is variable, depending on the output length of the Responder's hash function RHASH.
i) 要散列的数据长度是可变的，这取决于响应程序的散列函数RHASH的输出长度。
ii) All the data in the hash input MUST be in network byte order.
ii）散列输入中的所有数据必须按网络字节顺序排列。
iii) The orderings of the Initiator's and Responder's HITs are different in the R1 and I2 packets; see Section 5.1. Care must be taken to copy the values in the right order to the hash input.
iii）在R1和I2数据包中，发起方和响应方的点击顺序不同；见第5.1节。必须注意以正确的顺序将值复制到哈希输入。
iv) For a puzzle #I, there may exist multiple valid puzzle solutions #J.
iv）对于一个谜题#I，可能存在多个有效的谜题解#J。
The following procedure describes the processing steps involved, assuming that the Responder chooses to precompute the R1 packets:
以下过程描述了所涉及的处理步骤，假设响应者选择预计算R1数据包：
Precomputation by the Responder: Sets up the puzzle difficulty #K. Creates a signed R1 and caches it.
响应者的预计算：设置谜题难度#K。创建签名R1并缓存它。
Responder: Selects a suitable cached R1. Generates a random number #I. Sends #I and #K in an R1. Saves #I and #K for a delta time.
响应程序：选择合适的缓存R1。生成一个随机数I。在R1中发送I和K。节省#I和#K的增量时间。
Initiator: Generates repeated attempts to solve the puzzle until a matching #J is found: Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0 Sends #I and #J in an I2.
发起者：生成重复尝试来解决该难题，直到找到匹配的#J：Ltrunc（RHASH（#I | HIT-I | HIT-R | J），#K）==0在I2中发送#I和#J。
Responder:
Verifies that the received #I is a saved one.
Finds the right #K based on #I.
Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K )
Rejects if V != 0
Accepts if V == 0
Responder:
Verifies that the received #I is a saved one.
Finds the right #K based on #I.
Computes V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K )
Rejects if V != 0
Accepts if V == 0
The following subsections define the actions for processing HIP_MAC, HIP_MAC_2, HIP_SIGNATURE, and HIP_SIGNATURE_2 parameters. The HIP_MAC_2 parameter is contained in the R2 packet. The HIP_SIGNATURE_2 parameter is contained in the R1 packet. The HIP_SIGNATURE and HIP_MAC parameters are contained in other HIP packets.
以下小节定义了处理HIP_MAC、HIP_MAC_2、HIP_签名和HIP_签名_2参数的操作。HIP_MAC_2参数包含在R2数据包中。HIP_签名_2参数包含在R1数据包中。HIP_签名和HIP_MAC参数包含在其他HIP数据包中。
The HMAC uses RHASH as the underlying hash function. The type of RHASH depends on the HIT Suite of the Responder. Hence, HMAC-SHA-256 [RFC4868] is used for HIT Suite RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404] is used for HIT Suite ECDSA_LOW/SHA-1, and HMAC-SHA-384 [RFC4868] is used for HIT Suite ECDSA/SHA-384.
HMAC使用RHASH作为底层哈希函数。RHASH的类型取决于响应者的命中套件。因此，HMAC-SHA-256[RFC4868]用于HIT套件RSA/DSA/SHA-256，HMAC-SHA-1[RFC2404]用于HIT套件ECDSA_LOW/SHA-1，HMAC-SHA-384[RFC4868]用于HIT套件ECDSA/SHA-384。
The following process applies both to the HIP_MAC and HIP_MAC_2 parameters. When processing HIP_MAC_2, the difference is that the HIP_MAC calculation includes a pseudo HOST_ID field containing the Responder's information as sent in the R1 packet earlier.
以下过程同时适用于HIP_MAC和HIP_MAC_2参数。当处理HIP_MAC_2时，不同之处在于HIP_MAC计算包括一个伪主机ID字段，该字段包含先前在R1包中发送的响应者信息。
Both the Initiator and the Responder should take some care when verifying or calculating the HIP_MAC_2. Specifically, the Initiator has to preserve the HOST_ID exactly as it was received in the R1 packet until it receives the HIP_MAC_2 in the R2 packet.
在验证或计算HIP_MAC_2时，发起者和响应者都应小心。具体地说，发起方必须保持主机ID与在R1数据包中接收到的主机ID完全相同，直到它在R2数据包中接收到HIP_MAC_2为止。
The scope of the calculation for HIP_MAC is as follows:
HIP_MAC的计算范围如下：
HMAC: { HIP header | [ Parameters ] }
HMAC: { HIP header | [ Parameters ] }
where Parameters include all of the packet's HIP parameters with type values ranging from 1 to (HIP_MAC's type value - 1), and excluding those parameters with type values greater than or equal to HIP_MAC's type value.
其中，参数包括类型值范围为1到（HIP_MAC的类型值-1）的数据包的所有HIP参数，并排除类型值大于或等于HIP_MAC的类型值的参数。
During HIP_MAC calculation, the following apply:
在HIP_MAC计算过程中，以下各项适用：
o In the HIP header, the Checksum field is set to zero.
o 在HIP标头中，校验和字段设置为零。
o In the HIP header, the Header Length field value is calculated to the beginning of the HIP_MAC parameter.
o 在HIP标头中，标头长度字段值计算到HIP_MAC参数的开头。
Parameter order is described in Section 5.2.1.
第5.2.1节描述了参数顺序。
The scope of the calculation for HIP_MAC_2 is as follows:
HIP_MAC_2的计算范围如下：
HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID }
HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID }
where Parameters include all of the packet's HIP parameters with type values from 1 to (HIP_MAC_2's type value - 1), and excluding those parameters with type values greater than or equal to HIP_MAC_2's type value.
其中，参数包括类型值为1到（HIP_MAC_2的类型值-1）的数据包的所有HIP参数，并排除类型值大于或等于HIP_MAC_2的类型值的参数。
During HIP_MAC_2 calculation, the following apply:
在HIP_MAC_2计算过程中，以下各项适用：
o In the HIP header, the Checksum field is set to zero.
o 在HIP标头中，校验和字段设置为零。
o In the HIP header, the Header Length field value is calculated to the beginning of the HIP_MAC_2 parameter and increased by the length of the concatenated HOST_ID parameter length (including the Type and Length fields).
o 在HIP标头中，标头长度字段值计算到HIP_MAC_2参数的开头，并增加连接的HOST_ID参数长度的长度（包括类型和长度字段）。
o The HOST_ID parameter is exactly in the form it was received in the R1 packet from the Responder.
o HOST_ID参数的格式与响应程序在R1数据包中接收到的格式完全相同。
Parameter order is described in Section 5.2.1, except that the HOST_ID parameter in this calculation is added to the end.
第5.2.1节描述了参数顺序，但本计算中的HOST_ID参数添加到末尾。
The HIP_MAC parameter is defined in Section 5.2.12 and the HIP_MAC_2 parameter in Section 5.2.13. The HMAC calculation and verification process (the process applies both to HIP_MAC and HIP_MAC_2, except where HIP_MAC_2 is mentioned separately) is as follows:
HIP_MAC参数在第5.2.12节中定义，HIP_MAC_2参数在第5.2.13节中定义。HMAC计算和验证过程（该过程适用于HIP_MAC和HIP_MAC_2，单独提及HIP_MAC_2的情况除外）如下所示：
Packet sender:
数据包发送方：
1. Create the HIP packet, without the HIP_MAC, HIP_SIGNATURE, HIP_SIGNATURE_2, or any other parameter with greater type value than the HIP_MAC parameter has.
1. 创建HIP数据包，不包含HIP_MAC、HIP_签名、HIP_签名或任何其他类型值大于HIP_MAC参数的参数。
2. In case of HIP_MAC_2 calculation, add a HOST_ID (Responder) parameter to the end of the packet.
2. 在HIP_MAC_2计算的情况下，在数据包的末尾添加一个HOST_ID（Responder）参数。
3. Calculate the Header Length field in the HIP header, including the added HOST_ID parameter in case of HIP_MAC_2.
3. 计算HIP标头中的标头长度字段，包括HIP_MAC_2情况下添加的HOST_ID参数。
4. Compute the HMAC using either the HIP-gl or HIP-lg integrity key retrieved from KEYMAT as defined in Section 6.5.
4. 使用第6.5节中定义的从KEYMAT检索的HIP gl或HIP lg完整性键计算HMAC。
5. In case of HIP_MAC_2, remove the HOST_ID parameter from the packet.
5. 如果是HIP_MAC_2，请从数据包中删除主机ID参数。
6. Add the HIP_MAC parameter to the packet and any parameter with greater type value than the HIP_MAC's (HIP_MAC_2's) that may follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 parameters.
6. 将HIP_MAC参数添加到数据包中，并添加任何类型值大于随后可能出现的HIP_MAC（HIP_MAC_2）的参数，包括可能的HIP_签名或HIP_签名参数。
7. Recalculate the Length field in the HIP header.
7. 重新计算髋部标题中的长度字段。
Packet receiver:
数据包接收器：
1. Verify the HIP Header Length field.
1. 验证“髋部收割台长度”字段。
2. Remove the HIP_MAC or HIP_MAC_2 parameter, as well as all other parameters that follow it with greater type value including possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the contents if they are needed later.
2. 删除HIP_MAC或HIP_MAC_2参数，以及其后具有更大类型值的所有其他参数，包括可能的HIP_签名或HIP_签名_2字段，如果以后需要，则保存内容。
3. In case of HIP_MAC_2, build and add a HOST_ID parameter (with Responder information) to the packet. The HOST_ID parameter should be identical to the one previously received from the Responder.
3. 在HIP_MAC_2的情况下，构建并向数据包添加一个HOST_ID参数（带有响应者信息）。HOST_ID参数应与先前从响应程序接收的参数相同。
4. Recalculate the HIP packet length in the HIP header and clear the Checksum field (set it to all zeros). In case of HIP_MAC_2, the length is calculated with the added HOST_ID parameter.
4. 重新计算HIP标头中的HIP数据包长度并清除校验和字段（将其设置为全零）。对于HIP_MAC_2，使用添加的HOST_ID参数计算长度。
5. Compute the HMAC using either the HIP-gl or HIP-lg integrity key as defined in Section 6.5 and verify it against the received HMAC.
5. 使用第6.5节中定义的HIP gl或HIP lg完整性键计算HMAC，并对照收到的HMAC进行验证。
6. Set the Checksum and Header Length fields in the HIP header to original values. Note that the Checksum and Length fields contain incorrect values after this step.
6. 将HIP标题中的校验和和标题长度字段设置为原始值。请注意，此步骤之后，校验和和和长度字段包含不正确的值。
7. In case of HIP_MAC_2, remove the HOST_ID parameter from the packet before further processing.
7. 对于HIP_MAC_2，在进一步处理之前，从数据包中删除HOST_ID参数。
The following process applies both to the HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. When processing the HIP_SIGNATURE_2 parameter, the only difference is that instead of the HIP_SIGNATURE parameter, the HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE Opaque and Random #I fields are cleared (set to all zeros) before computing the signature. The HIP_SIGNATURE parameter is defined in Section 5.2.14 and the HIP_SIGNATURE_2 parameter in Section 5.2.15.
以下过程同时应用于HIP_签名和HIP_签名参数。处理HIP_SIGNATURE_2参数时，唯一的区别是使用HIP_SIGNATURE_2参数而不是HIP_SIGNATURE参数，并且在计算签名之前，启动器的命中和拼图不透明和随机I字段被清除（设置为全零）。HIP_签名参数在第5.2.14节中定义，HIP_签名参数在第5.2.15节中定义。
The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 is as follows:
HIP_签名和HIP_签名的计算范围如下：
HIP_SIGNATURE: { HIP header | [ Parameters ] }
HIP_SIGNATURE: { HIP header | [ Parameters ] }
where Parameters include all of the packet's HIP parameters with type values from 1 to (HIP_SIGNATURE's type value - 1).
其中，参数包括类型值为1到（HIP_签名的类型值-1）的数据包的所有HIP参数。
During signature calculation, the following apply:
在签名计算过程中，以下各项适用：
o In the HIP header, the Checksum field is set to zero.
o 在HIP标头中，校验和字段设置为零。
o In the HIP header, the Header Length field value is calculated to the beginning of the HIP_SIGNATURE parameter.
o 在HIP标头中，标头长度字段值计算到HIP_签名参数的开头。
Parameter order is described in Section 5.2.1.
第5.2.1节描述了参数顺序。
HIP_SIGNATURE_2: { HIP header | [ Parameters ] }
HIP_SIGNATURE_2: { HIP header | [ Parameters ] }
where Parameters include all of the packet's HIP parameters with type values ranging from 1 to (HIP_SIGNATURE_2's type value - 1).
其中，参数包括类型值范围为1到（HIP_签名_2的类型值-1）的数据包的所有HIP参数。
During signature calculation, the following apply:
在签名计算过程中，以下各项适用：
o In the HIP header, both the Checksum and the Receiver's HIT fields are set to zero.
o 在HIP标头中，校验和和和接收器的命中字段都设置为零。
o In the HIP header, the Header Length field value is calculated to the beginning of the HIP_SIGNATURE_2 parameter.
o 在HIP header中，header Length字段值计算到HIP_SIGNATURE_2参数的开头。
o The PUZZLE parameter's Opaque and Random #I fields are set to zero.
o PUZZLE参数的不透明和随机#I字段设置为零。
Parameter order is described in Section 5.2.1.
第5.2.1节描述了参数顺序。
The signature calculation and verification process (the process applies both to HIP_SIGNATURE and HIP_SIGNATURE_2, except in the case where HIP_SIGNATURE_2 is separately mentioned) is as follows:
签名计算和验证过程（该过程适用于HIP_签名和HIP_签名，单独提及HIP_签名的情况除外）如下所示：
Packet sender:
数据包发送方：
1. Create the HIP packet without the HIP_SIGNATURE parameter or any other parameters that follow the HIP_SIGNATURE parameter.
1. 创建不带HIP_签名参数或HIP_签名参数后面的任何其他参数的HIP数据包。
2. Calculate the Length field and zero the Checksum field in the HIP header. In case of HIP_SIGNATURE_2, set the Initiator's HIT field in the HIP header as well as the PUZZLE parameter's Opaque and Random #I fields to zero.
2. 计算长度字段并将HIP标头中的校验和字段归零。在HIP_签名_2的情况下，将发起人在HIP标题中的命中字段以及拼图参数的不透明和随机#I字段设置为零。
3. Compute the signature using the private key corresponding to the Host Identifier (public key).
3. 使用与主机标识符（公钥）对应的私钥计算签名。
4. Add the HIP_SIGNATURE parameter to the packet.
4. 将HIP_签名参数添加到数据包。
5. Add any parameters that follow the HIP_SIGNATURE parameter.
5. 添加HIP_签名参数后面的任何参数。
6. Recalculate the Length field in the HIP header, and calculate the Checksum field.
6. 重新计算臀部标题中的长度字段，并计算校验和字段。
Packet receiver:
数据包接收器：
1. Verify the HIP Header Length field and checksum.
1. 验证HIP Header Length字段和校验和。
2. Save the contents of the HIP_SIGNATURE parameter and any other parameters following the HIP_SIGNATURE parameter, and remove them from the packet.
2. 保存HIP_签名参数和HIP_签名参数后面的任何其他参数的内容，并将其从数据包中删除。
3. Recalculate the HIP packet Length in the HIP header and clear the Checksum field (set it to all zeros). In case of HIP_SIGNATURE_2, set the Initiator's HIT field in the HIP header as well as the PUZZLE parameter's Opaque and Random #I fields to zero.
3. 重新计算HIP标头中的HIP数据包长度并清除校验和字段（将其设置为全零）。在HIP_签名_2的情况下，将发起人在HIP标题中的命中字段以及拼图参数的不透明和随机#I字段设置为零。
4. Compute the signature and verify it against the received signature using the packet sender's Host Identity (public key).
4. 计算签名，并使用数据包发送方的主机标识（公钥）根据收到的签名进行验证。
5. Restore the original packet by adding removed parameters (in step 2) and resetting the values that were set to zero (in step 3).
5. 通过添加移除的参数（步骤2）并重置设置为零的值（步骤3），恢复原始数据包。
The verification can use either the HI received from a HIP packet; the HI retrieved from a DNS query, if the FQDN has been received in the HOST_ID parameter; or an HI received by some other means.
验证可以使用从HIP数据包接收的HI；从DNS查询中检索到的HI（如果已在HOST_ID参数中接收到FQDN）；或者通过其他方式收到的HI。
HIP keying material is derived from the Diffie-Hellman session key, Kij, produced during the HIP base exchange (see Section 4.1.3). The Initiator has Kij during the creation of the I2 packet, and the Responder has Kij once it receives the I2 packet. This is why I2 can already contain encrypted information.
髋关节键控材料来源于髋关节基底交换期间产生的Diffie-Hellman会话键Kij（见第4.1.3节）。发起方在创建I2数据包期间拥有Kij，响应方在收到I2数据包后拥有Kij。这就是I2已经可以包含加密信息的原因。
The KEYMAT is derived by feeding Kij into the key derivation function defined by the DH Group ID. Currently, the only key derivation function defined in this document is the Hash-based Key Derivation Function (HKDF) [RFC5869] using the RHASH hash function. Other documents may define new DH Group IDs and corresponding key distribution functions.
KEYMAT是通过将Kij输入DH组ID定义的密钥派生函数来派生的。目前，本文档中定义的唯一密钥派生函数是使用RHASH哈希函数的基于哈希的密钥派生函数（HKDF）[RFC5869]。其他文件可能定义新的DH组ID和相应的密钥分发功能。
In the following, we provide the details for deriving the keying material using HKDF.
在下文中，我们提供了使用HKDF导出键控材料的详细信息。
where
哪里
info = sort(HIT-I | HIT-R)
salt = #I | #J
info = sort(HIT-I | HIT-R)
salt = #I | #J
Sort(HIT-I | HIT-R) is defined as the network byte order concatenation of the two HITs, with the smaller HIT preceding the larger HIT, resulting from the numeric comparison of the two HITs interpreted as positive (unsigned) 128-bit integers in network byte order. The #I and #J values are from the puzzle and its solution that were exchanged in R1 and I2 messages when this HIP association was set up. Both hosts have to store #I and #J values for the HIP association for future use.
排序（HIT-I | HIT-R）定义为两个命中的网络字节顺序串联，较小的命中在较大的命中之前，这是由两个命中的数字比较产生的，这两个命中按网络字节顺序解释为正（无符号）128位整数。#I和#J值来自谜题及其解决方案，在建立髋关节关联时，这些谜题及其解决方案在R1和I2消息中交换。两台主机都必须存储髋关节协会的#I和#J值，以备将来使用。
The initial keys are drawn sequentially in the order that is determined by the numeric comparison of the two HITs, with the comparison method described in the previous paragraph. HOST_g denotes the host with the greater HIT value, and HOST_l the host with the lower HIT value.
使用上一段中描述的比较方法，按照两次点击的数字比较确定的顺序顺序顺序绘制初始关键点。HOST_g表示命中值较大的主机，HOST_l表示命中值较低的主机。
The drawing order for the four initial keys is as follows:
四个初始键的绘图顺序如下所示：
HIP-gl encryption key for HOST_g's ENCRYPTED parameter
主机加密参数的HIP gl加密密钥
HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets
主机的传出HIP数据包的HIP gl完整性（HMAC）密钥
HIP-lg encryption key for HOST_l's ENCRYPTED parameter
主机加密参数的HIP lg加密密钥
HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets
主机传出HIP数据包的HIP lg完整性（HMAC）密钥
The number of bits drawn for a given algorithm is the "natural" size of the keys. For the mandatory algorithms, the following sizes apply:
为给定算法绘制的位数是密钥的“自然”大小。对于强制算法，以下尺寸适用：
AES 128 or 256 bits
AES 128或256位
SHA-1 160 bits
SHA-1 160位
SHA-256 256 bits
SHA-256 256位
SHA-384 384 bits
SHA-384 384位
NULL 0 bits
零0位
If other key sizes are used, they MUST be treated as different encryption algorithms and defined separately.
如果使用其他密钥大小，则必须将其视为不同的加密算法并单独定义。
An implementation may originate a HIP base exchange to another host based on a local policy decision, usually triggered by an application datagram, in much the same way that an IPsec IKE key exchange can dynamically create a Security Association. Alternatively, a system may initiate a HIP exchange if it has rebooted or timed out, or otherwise lost its HIP state, as described in Section 4.5.4.
实现可以基于本地策略决策（通常由应用程序数据报触发）发起到另一个主机的基于HIP的交换，其方式与IPsec-IKE密钥交换可以动态创建安全关联的方式大致相同。或者，如第4.5.4节所述，如果系统重新启动或超时，或以其他方式失去HIP状态，则系统可启动HIP交换。
The implementation prepares an I1 packet and sends it to the IP address that corresponds to the peer host. The IP address of the peer host may be obtained via conventional mechanisms, such as DNS lookup. The I1 packet contents are specified in Section 5.3.1. The
该实现准备一个I1数据包并将其发送到对应于对等主机的IP地址。对等主机的IP地址可以通过诸如DNS查找之类的常规机制获得。第5.3.1节规定了I1数据包的内容。这个
selection of which source or destination Host Identity to use, if an Initiator or Responder has more than one to choose from, is typically a policy decision.
如果启动器或响应程序有多个主机标识可供选择，则选择要使用的源主机标识或目标主机标识通常是一项策略决策。
The following steps define the conceptual processing rules for initiating a HIP base exchange:
以下步骤定义了启动髋关节基础置换的概念处理规则：
1. The Initiator receives one or more of the Responder's HITs and one or more addresses from either a DNS lookup of the Responder's FQDN, some other repository, or a local database. If the Initiator does not know the Responder's HIT, it may attempt opportunistic mode by using NULL (all zeros) as the Responder's HIT (see also "HIP Opportunistic Mode" (Section 4.1.8)). If the Initiator can choose from multiple Responder HITs, it selects a HIT for which the Initiator supports the HIT Suite.
1. 发起方从响应方FQDN的DNS查找、某些其他存储库或本地数据库接收响应方的一个或多个点击和一个或多个地址。如果发起者不知道响应者的命中率，则可以使用NULL（全零）作为响应者的命中率来尝试机会主义模式（另请参见“HIP机会主义模式”（第4.1.8节）。如果发起者可以从多个响应者点击中进行选择，它将选择发起者支持点击套件的点击。
2. The Initiator sends an I1 packet to one of the Responder's addresses. The selection of which address to use is a local policy decision.
2. 发起方向响应方的一个地址发送I1数据包。选择使用哪个地址是当地的政策决定。
3. The Initiator includes the DH_GROUP_LIST in the I1 packet. The selection and order of DH Group IDs in the DH_GROUP_LIST MUST be stored by the Initiator, because this list is needed for later R1 processing. In most cases, the preferences regarding the DH groups will be static, so no per-association storage is necessary.
3. 发起方在I1数据包中包括DH_组_列表。发起者必须存储DH_Group_列表中DH Group ID的选择和顺序，因为后续R1处理需要该列表。在大多数情况下，关于DH组的首选项是静态的，因此不需要每个关联存储。
4. Upon sending an I1 packet, the sender transitions to state I1-SENT and starts a timer for which the timeout value SHOULD be larger than the worst-case anticipated RTT. The sender SHOULD also increment the trial counter associated with the I1.
4. 发送I1数据包后，发送方转换到状态I1-SENT并启动一个计时器，该计时器的超时值应大于最坏情况下预期的RTT。发送方还应增加与I1关联的试用计数器。
5. Upon timeout, the sender SHOULD retransmit the I1 packet and restart the timer, up to a maximum of I1_RETRIES_MAX tries.
5. 超时后，发送方应重新传输I1数据包并重新启动计时器，最多可重试I1次。
For the sake of minimizing the association establishment latency, an implementation MAY send the same I1 packet to more than one of the Responder's addresses. However, it MUST NOT send to more than three (3) Responder addresses in parallel. Furthermore, upon timeout, the implementation MUST refrain from sending the same I1 packet to multiple addresses. That is, if it retries to initialize the connection after a timeout, it MUST NOT send the I1 packet to more than one destination address. These limitations are placed in order to avoid congestion of the network, and potential DoS attacks that
为了最小化关联建立延迟，实现可以向响应者的多个地址发送相同的I1分组。但是，它不能同时发送到三（3）个以上的响应者地址。此外，在超时时，实现必须避免向多个地址发送相同的I1数据包。也就是说，如果在超时后重试初始化连接，则它不得将I1数据包发送到多个目标地址。设置这些限制是为了避免网络拥塞和可能导致的DoS攻击
might occur, e.g., because someone's claim to have hundreds or thousands of addresses could generate a huge number of I1 packets from the Initiator.
可能发生，例如，因为某人声称拥有数百或数千个地址可能会从启动器生成大量I1数据包。
As the Responder is not guaranteed to distinguish the duplicate I1 packets it receives at several of its addresses (because it avoids storing states when it answers back an R1 packet), the Initiator may receive several duplicate R1 packets.
由于应答器不能保证区分它在几个地址接收到的重复I1包（因为它避免在应答R1包时存储状态），因此启动器可以接收多个重复的R1包。
The Initiator SHOULD then select the initial preferred destination address using the source address of the selected received R1, and use the preferred address as a source address for the I2 packet. Processing rules for received R1s are discussed in Section 6.8.
然后，启动器应使用所选接收R1的源地址选择初始首选目的地地址，并使用首选地址作为I2数据包的源地址。第6.8节讨论了接收到的R1s的处理规则。
A host may receive an ICMP 'Destination Protocol Unreachable' message as a response to sending a HIP I1 packet. Such a packet may be an indication that the peer does not support HIP, or it may be an attempt to launch an attack by making the Initiator believe that the Responder does not support HIP.
主机可以接收ICMP“目的地协议不可访问”消息作为发送HIP I1数据包的响应。这样的分组可能是对等方不支持HIP的指示，或者可能是试图通过使发起方相信响应方不支持HIP来发起攻击。
When a system receives an ICMP 'Destination Protocol Unreachable' message while it is waiting for an R1 packet, it MUST NOT terminate waiting. It MAY continue as if it had not received the ICMP message, and send a few more I1 packets. Alternatively, it MAY take the ICMP message as a hint that the peer most probably does not support HIP, and return to state UNASSOCIATED earlier than otherwise. However, at minimum, it MUST continue waiting for an R1 packet for a reasonable time before returning to UNASSOCIATED.
当系统在等待R1数据包时收到ICMP“Destination Protocol Unreachable”（目标协议不可访问）消息时，不得终止等待。它可能会继续，就像它没有收到ICMP消息一样，并发送更多的I1数据包。或者，它可以将ICMP消息作为一个提示，提示对等方很可能不支持HIP，并比其他情况更早地返回到未关联状态。但是，至少，它必须在返回到非关联状态之前，继续等待R1数据包一段合理的时间。
An implementation SHOULD reply to an I1 with an R1 packet, unless the implementation is unable or unwilling to set up a HIP association. If the implementation is unable to set up a HIP association, the host SHOULD send an 'ICMP Destination Protocol Unreachable, Administratively Prohibited' message to the I1 packet source IP address. If the implementation is unwilling to set up a HIP association, the host MAY ignore the I1 packet. This latter case may occur during a DoS attack such as an I1 packet flood.
除非实现无法或不愿意建立HIP关联，否则实现应使用R1数据包回复I1。如果实现无法设置HIP关联，主机应向I1数据包源IP地址发送“ICMP目标协议无法访问，管理禁止”消息。如果实现不愿意建立HIP关联，则主机可以忽略I1数据包。后一种情况可能发生在DoS攻击期间，如I1数据包泛滥。
The implementation SHOULD be able to handle a storm of received I1 packets, discarding those with common content that arrive within a small time delta.
该实现应该能够处理大量接收到的I1数据包，丢弃那些在很短的时间增量内到达的具有公共内容的数据包。
A spoofed I1 packet can result in an R1 attack on a system. An R1 packet sender MUST have a mechanism to rate-limit R1 packets sent to an address.
伪造的I1数据包可导致系统上的R1攻击。R1数据包发送方必须有一种机制来对发送到某个地址的R1数据包进行速率限制。
It is RECOMMENDED that the HIP state machine does not transition upon sending an R1 packet.
建议HIP状态机在发送R1数据包时不要转换。
The following steps define the conceptual processing rules for responding to an I1 packet:
以下步骤定义了响应I1数据包的概念处理规则：
1. The Responder MUST check that the Responder's HIT in the received I1 packet is either one of its own HITs or NULL. Otherwise, it must drop the packet.
1. 响应者必须检查响应者在接收到的I1数据包中的命中是其自己的命中还是空。否则，它必须丢弃数据包。
2. If the Responder is in ESTABLISHED state, the Responder MAY respond to this with an R1 packet, prepare to drop an existing HIP security association with the peer, and stay at ESTABLISHED state.
2. 如果响应者处于建立状态，则响应者可使用R1分组对此作出响应，准备丢弃与对等者的现有髋部安全关联，并保持在建立状态。
3. If the Responder is in I1-SENT state, it MUST make a comparison between the sender's HIT and its own (i.e., the receiver's) HIT. If the sender's HIT is greater than its own HIT, it should drop the I1 packet and stay at I1-SENT. If the sender's HIT is smaller than its own HIT, it SHOULD send the R1 packet and stay at I1-SENT. The HIT comparison is performed as defined in Section 6.5.
3. 如果响应者处于I1-SENT状态，则必须将发送者的命中与自己（即接收方）的命中进行比较。如果发送方的命中率大于其自身的命中率，则应丢弃I1数据包并保持I1-SENT状态。如果发送方的命中率小于其自身的命中率，则应发送R1数据包并保持I1-SENT。按照第6.5节的规定进行命中比较。
4. If the implementation chooses to respond to the I1 packet with an R1 packet, it creates a new R1 or selects a precomputed R1 according to the format described in Section 5.3.2. It creates or chooses an R1 that contains its most preferred DH public value that is also contained in the DH_GROUP_LIST in the I1 packet. If no suitable DH Group ID was contained in the DH_GROUP_LIST in the I1 packet, it sends an R1 with any suitable DH public key.
4. 如果实现选择使用R1数据包响应I1数据包，它将根据第5.3.2节中描述的格式创建新的R1或选择预计算的R1。它创建或选择一个R1，该R1包含其最首选的DH公共值，该值也包含在I1数据包的DH_组_列表中。如果I1数据包中的DH_Group_列表中不包含合适的DH Group ID，它将发送带有任何合适DH公钥的R1。
5. If the received Responder's HIT in the I1 is NULL, the Responder selects a HIT with the same HIT Suite as the Initiator's HIT. If this HIT Suite is not supported by the Responder, it SHOULD select a REQUIRED HIT Suite from Section 5.2.10, which is currently RSA/DSA/SHA-256. Other than that, selecting the HIT is a local policy matter.
5. 如果收到的响应者在I1中的命中为空，则响应者选择与发起方的命中具有相同命中套件的命中。如果响应者不支持此HIT套件，则应从第5.2.10节中选择所需的HIT套件，当前为RSA/DSA/SHA-256。除此之外，选择热门产品是当地的政策问题。
6. The Responder expresses its supported HIP transport formats in the TRANSPORT_FORMAT_LIST as described in Section 5.2.11. The Responder MUST provide at least one payload transport format type.
6. 如第5.2.11节所述，响应者在传输格式列表中表示其支持的髋部传输格式。响应者必须提供至少一种有效负载传输格式类型。
7. The Responder sends the R1 packet to the source IP address of the I1 packet.
7. 响应者将R1数据包发送到I1数据包的源IP地址。
All compliant implementations MUST be able to produce R1 packets; even if a device is configured by policy to only initiate associations, it must be able to process I1s in cases of recovery from loss of state or key exhaustion. An R1 packet MAY be precomputed. An R1 packet MAY be reused for a short time period, denoted here as "Delta T", which is implementation dependent, and SHOULD be deprecated and not used once a valid response I2 packet has been received from an Initiator. During an I1 message storm, an R1 packet MAY be reused beyond the normal Delta T. R1 information MUST NOT be discarded until a time period "Delta S" (again, implementation dependent) after the R1 packet is no longer being offered. Delta S is the assumed maximum time needed for the last I2 packet in response to the R1 packet to arrive back at the Responder.
所有兼容的实现必须能够产生R1数据包；即使根据策略将设备配置为仅启动关联，在从状态丢失或密钥耗尽恢复的情况下，它也必须能够处理I1。可以预计算R1分组。R1数据包可在短时间内重复使用，此处表示为“Delta T”，这取决于实现，一旦从启动器接收到有效的响应I2数据包，则应弃用且不使用。在I1消息风暴期间，R1数据包可在正常增量T之外重复使用。在R1数据包不再提供后的时间段“增量S”（同样，取决于实现）之前，不得丢弃R1信息。Delta S是响应R1数据包的最后一个I2数据包返回响应器所需的假定最大时间。
Implementations that support multiple DH groups MAY precompute R1 packets for each supported group so that incoming I1 packets with different DH Group IDs in the DH_GROUP_LIST can be served quickly.
支持多个DH组的实现可以为每个受支持组预计算R1包，以便可以快速地为DH_group_列表中具有不同DH组ID的传入I1包提供服务。
An implementation MAY keep state about received I1 packets and match the received I2 packets against the state, as discussed in Section 4.1.1.
如第4.1.1节所述，实现可以保持关于接收到的I1分组的状态，并将接收到的I2分组与该状态相匹配。
If an implementation receives a malformed I1 packet, it SHOULD NOT respond with a NOTIFY message, as such a practice could open up a potential denial-of-service threat. Instead, it MAY respond with an ICMP packet, as defined in Section 5.4.
如果实现接收到格式不正确的I1数据包，则不应使用NOTIFY消息进行响应，因为这种做法可能会造成潜在的拒绝服务威胁。相反，它可以按照第5.4节的定义，使用ICMP数据包进行响应。
A system receiving an R1 packet MUST first check to see if it has sent an I1 packet to the originator of the R1 packet (i.e., it is in state I1-SENT). If so, it SHOULD process the R1 as described below, send an I2 packet, and transition to state I2-SENT, setting a timer to protect the I2 packet. If the system is in state I2-SENT, it MAY respond to the R1 packet if the R1 packet has a larger R1 generation counter; if so, it should drop its state due to processing the
接收R1数据包的系统必须首先检查是否已将I1数据包发送给R1数据包的发起人（即，它处于I1-sent状态）。如果是这样，它应该如下所述处理R1，发送I2数据包，并转换到状态I2-SENT，设置定时器以保护I2数据包。如果系统处于状态I2-SENT，则如果R1分组具有更大的R1生成计数器，则系统可以响应R1分组；如果是这样的话，它应该由于处理
previous R1 packet and start over from state I1-SENT. If the system is in any other state with respect to that host, the system SHOULD silently drop the R1 packet.
上一个R1数据包，并从状态I1-SENT重新开始。如果系统处于与该主机相关的任何其他状态，则系统应静默地丢弃R1数据包。
When sending multiple I1 packets, an Initiator SHOULD wait for a small amount of time after the first R1 reception to allow possibly multiple R1 packets to arrive, and it SHOULD respond to an R1 packet among the set with the largest R1 generation counter.
当发送多个I1数据包时，启动器应在第一次R1接收后等待一小段时间，以允许可能多个R1数据包到达，并且它应响应具有最大R1生成计数器的集合中的R1数据包。
The following steps define the conceptual processing rules for responding to an R1 packet:
以下步骤定义了响应R1数据包的概念处理规则：
1. A system receiving an R1 MUST first check to see if it has sent an I1 packet to the originator of the R1 packet (i.e., it has a HIP association that is in state I1-SENT and that is associated with the HITs in the R1). Unless the I1 packet was sent in opportunistic mode (see Section 4.1.8), the IP addresses in the received R1 packet SHOULD be ignored by the R1 processing and, when looking up the right HIP association, the received R1 packet SHOULD be matched against the associations using only the HITs. If a match exists, the system should process the R1 packet as described below.
1. 接收R1的系统必须首先检查是否已将I1数据包发送给R1数据包的发起人（即，其具有处于I1-sent状态且与R1中的点击相关联的HIP关联）。除非I1数据包以机会主义模式发送（见第4.1.8节），否则R1处理应忽略接收到的R1数据包中的IP地址，并且在查找右HIP关联时，应仅使用命中将接收到的R1数据包与关联进行匹配。如果存在匹配项，系统应按如下所述处理R1数据包。
2. Otherwise, if the system is in any state other than I1-SENT or I2-SENT with respect to the HITs included in the R1 packet, it SHOULD silently drop the R1 packet and remain in the current state.
2. 否则，如果系统处于与R1数据包中包含的命中有关的I1-SENT或I2-SENT以外的任何状态，则系统应无声地丢弃R1数据包并保持当前状态。
3. If the HIP association state is I1-SENT or I2-SENT, the received Initiator's HIT MUST correspond to the HIT used in the original I1. Also, the Responder's HIT MUST correspond to the one used in the I1, unless the I1 packet contained a NULL HIT.
3. 如果HIP关联状态为I1-SENT或I2-SENT，则接收到的启动器的命中必须与原始I1中使用的命中相对应。此外，响应者的命中必须与I1中使用的命中相对应，除非I1数据包包含空命中。
4. The system SHOULD validate the R1 signature before applying further packet processing, according to Section 5.2.15.
4. 根据第5.2.15节，系统应在应用进一步的数据包处理之前验证R1签名。
5. If the HIP association state is I1-SENT, and multiple valid R1 packets are present, the system MUST select from among the R1 packets with the largest R1 generation counter.
5. 如果HIP关联状态为I1-SENT，并且存在多个有效R1数据包，则系统必须从R1生成计数器最大的R1数据包中进行选择。
6. The system MUST check that the Initiator's HIT Suite is contained in the HIT_SUITE_LIST parameter in the R1 packet (i.e., the Initiator's HIT Suite is supported by the Responder). If the HIT Suite is supported by the Responder, the system proceeds normally. Otherwise, the system MAY stay in state I1-SENT and restart the BEX by sending a new I1 packet with an Initiator HIT that is supported by the Responder and hence is contained in the HIT_SUITE_LIST in the R1 packet. The system
6. 系统必须检查启动器的HIT套件是否包含在R1数据包的HIT_套件_列表参数中（即，响应程序支持启动器的HIT套件）。如果响应者支持HIT套件，系统将正常运行。否则，系统可能会保持I1-SENT状态，并通过发送一个新的I1数据包来重新启动BEX，该数据包具有响应程序支持的发起程序命中，因此包含在R1数据包的命中套件列表中。系统
MAY abort the BEX if no suitable source HIT is available. The system SHOULD wait for an acceptable time span to allow further R1 packets with higher R1 generation counters or different HIT and HIT Suites to arrive before restarting or aborting the BEX.
如果没有合适的震源命中，可能会中止BEX。在重新启动或中止BEX之前，系统应等待可接受的时间跨度，以允许具有更高R1生成计数器或不同命中套件的更多R1数据包到达。
7. The system MUST check that the DH Group ID in the DIFFIE_HELLMAN parameter in the R1 matches the first DH Group ID in the Responder's DH_GROUP_LIST in the R1 packet, and also that this Group ID corresponds to a value that was included in the Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID of the DIFFIE_HELLMAN parameter does not express the Responder's best choice, the Initiator can conclude that the DH_GROUP_LIST in the I1 packet was adversely modified. In such a case, the Initiator MAY send a new I1 packet; however, it SHOULD NOT change its preference in the DH_GROUP_LIST in the new I1 packet. Alternatively, the Initiator MAY abort the HIP base exchange.
7. 系统必须检查R1中DIFFIE_HELLMAN参数中的DH Group ID是否与R1数据包中响应者的DH_Group_列表中的第一个DH Group ID匹配，并且该Group ID是否对应于I1数据包中启动器的DH_Group_列表中包含的值。如果DIFFIE_HELLMAN参数的DH Group ID不表示响应者的最佳选择，则发起方可以断定I1数据包中的DH_Group_列表被反向修改。在这种情况下，发起方可以发送新的I1分组；但是，它不应更改其在新I1数据包的DH_组_列表中的首选项。或者，发起者可以中止HIP-base交换。
8. If the HIP association state is I2-SENT, the system MAY re-enter state I1-SENT and process the received R1 packet if it has a larger R1 generation counter than the R1 packet responded to previously.
8. 如果HIP关联状态为I2-SENT，则如果接收到的R1数据包的R1生成计数器大于先前响应的R1数据包，则系统可重新进入状态I1-SENT并处理该R1数据包。
9. The R1 packet may have the A-bit set -- in this case, the system MAY choose to refuse it by dropping the R1 packet and returning to state UNASSOCIATED. The system SHOULD consider dropping the R1 packet only if it used a NULL HIT in the I1 packet. If the A-bit is set, the Responder's HIT is anonymous and SHOULD NOT be stored permanently.
9. R1数据包可能设置了A位——在这种情况下，系统可能会选择通过丢弃R1数据包并返回到未关联状态来拒绝它。该系统应该考虑仅在I1包中使用空命中时丢弃R1包。如果设置了A位，则响应者的命中是匿名的，不应永久存储。
10. The system SHOULD attempt to validate the HIT against the received Host Identity by using the received Host Identity to construct a HIT and verify that it matches the Sender's HIT.
10. 系统应尝试使用接收到的主机标识构造HIT并验证其是否与发送方的HIT匹配，从而根据接收到的主机标识验证HIT。
11. The system MUST store the received R1 generation counter for future reference.
11. 系统必须存储接收到的R1生成计数器，以备将来参考。
12. The system attempts to solve the puzzle in the R1 packet. The system MUST terminate the search after exceeding the remaining lifetime of the puzzle. If the puzzle is not successfully solved, the implementation MAY either resend the I1 packet within the retry bounds or abandon the HIP base exchange.
12. 系统试图解决R1数据包中的难题。超过谜题的剩余生存期后，系统必须终止搜索。如果谜题没有成功解决，则实现可以在重试边界内重新发送I1数据包，或者放弃HIP基交换。
13. The system computes standard Diffie-Hellman keying material according to the public value and Group ID provided in the DIFFIE_HELLMAN parameter. The Diffie-Hellman keying material Kij is used for key extraction as specified in Section 6.5.
13. 系统根据Diffie_Hellman参数中提供的公共值和组ID计算标准Diffie Hellman键控材料。Diffie-Hellman键控材料Kij用于第6.5节规定的键提取。
14. The system selects the HIP_CIPHER ID from the choices presented in the R1 packet and uses the selected values subsequently when generating and using encryption keys, and when sending the I2 packet. If the proposed alternatives are not acceptable to the system, it may either resend an I1 within the retry bounds or abandon the HIP base exchange.
14. 系统从R1数据包中提供的选项中选择HIP_密码ID，并在随后生成和使用加密密钥以及发送I2数据包时使用所选值。如果系统不接受建议的备选方案，则它可以在重试范围内重新发送I1，或者放弃HIP-base交换。
15. The system chooses one suitable transport format from the TRANSPORT_FORMAT_LIST and includes the respective transport format parameter in the subsequent I2 packet.
15. 系统从传输格式列表中选择一种合适的传输格式，并在随后的I2数据包中包含相应的传输格式参数。
16. The system initializes the remaining variables in the associated state, including Update ID counters.
16. 系统初始化处于关联状态的其余变量，包括更新ID计数器。
17. The system prepares and sends an I2 packet, as described in Section 5.3.3.
17. 系统准备并发送I2数据包，如第5.3.3节所述。
18. The system SHOULD start a timer whose timeout value SHOULD be larger than the worst-case anticipated RTT, and MUST increment a trial counter associated with the I2 packet. The sender SHOULD retransmit the I2 packet upon a timeout and restart the timer, up to a maximum of I2_RETRIES_MAX tries.
18. 系统应启动一个计时器，其超时值应大于最坏情况下预期的RTT，并且必须增加与I2数据包相关联的试验计数器。发送方应在超时后重新传输I2数据包，并重新启动计时器，最多可重试I2次。
19. If the system is in state I1-SENT, it SHALL transition to state I2-SENT. If the system is in any other state, it remains in the current state.
19. 如果系统处于状态I1-SENT，则应转换为状态I2-SENT。如果系统处于任何其他状态，它将保持当前状态。
If an implementation receives a malformed R1 message, it MUST silently drop the packet. Sending a NOTIFY or ICMP would not help, as the sender of the R1 packet typically doesn't have any state. An implementation SHOULD wait for some more time for a possibly well-formed R1, after which it MAY try again by sending a new I1 packet.
如果实现接收到格式错误的R1消息，它必须以静默方式丢弃数据包。发送通知或ICMP不会有帮助，因为R1数据包的发送方通常没有任何状态。实现应该为可能格式良好的R1再等待一段时间，之后可以通过发送新的I1数据包重试。
Upon receipt of an I2 packet, the system MAY perform initial checks to determine whether the I2 packet corresponds to a recent R1 packet that has been sent out, if the Responder keeps such state. For example, the sender could check whether the I2 packet is from an address or HIT for which the Responder has recently received an I1. The R1 packet may have had opaque data included that was echoed back in the I2 packet. If the I2 packet is considered to be suspect, it MAY be silently discarded by the system.
在接收到I2分组时，如果响应者保持这种状态，则系统可以执行初始检查以确定I2分组是否对应于最近发送的R1分组。例如，发送方可以检查I2数据包是否来自响应方最近收到I1的地址或HIT。R1数据包可能包含在I2数据包中回显的不透明数据。如果I2数据包被认为是可疑的，系统可能会悄悄地丢弃它。
Otherwise, the HIP implementation SHOULD process the I2 packet. This includes validation of the puzzle solution, generating the Diffie-Hellman key, possibly decrypting the Initiator's Host Identity, verifying the signature, creating state, and finally sending an R2 packet.
否则，HIP实现应该处理I2数据包。这包括验证谜题解决方案、生成Diffie-Hellman密钥、可能解密启动器的主机标识、验证签名、创建状态，最后发送R2数据包。
The following steps define the conceptual processing rules for responding to an I2 packet:
以下步骤定义了响应I2数据包的概念处理规则：
1. The system MAY perform checks to verify that the I2 packet corresponds to a recently sent R1 packet. Such checks are implementation dependent. See Appendix A for a description of an example implementation.
1. 系统可执行检查以验证I2分组对应于最近发送的R1分组。这种检查依赖于实现。有关示例实现的说明，请参见附录A。
2. The system MUST check that the Responder's HIT corresponds to one of its own HITs and MUST drop the packet otherwise.
2. 系统必须检查响应者的命中是否与自己的一次命中相对应，否则必须丢弃数据包。
3. The system MUST further check that the Initiator's HIT Suite is supported. The Responder SHOULD silently drop I2 packets with unsupported Initiator HITs.
3. 系统必须进一步检查启动器的HIT套件是否受支持。响应程序应该静默地丢弃具有不受支持的启动器命中的I2数据包。
4. If the system's state machine is in the R2-SENT state, the system MAY check to see if the newly received I2 packet is similar to the one that triggered moving to R2-SENT. If so, it MAY retransmit a previously sent R2 packet and reset the R2-SENT timer, and the state machine stays in R2-SENT.
4. 如果系统的状态机处于R2-SENT状态，系统可能会检查新接收的I2数据包是否与触发移动到R2-SENT的数据包相似。如果是这样，它可能会重新传输先前发送的R2数据包并重置R2-sent计时器，并且状态机保持在R2-sent状态。
5. If the system's state machine is in the I2-SENT state, the system MUST make a comparison between its local and sender's HITs (similar to the comparison method described in Section 6.5). If the local HIT is smaller than the sender's HIT, it should drop the I2 packet, use the peer Diffie-Hellman key and nonce #I from the R1 packet received earlier, and get the local Diffie-Hellman key and nonce #J from the I2 packet sent to the peer earlier. Otherwise, the system should process the received I2 packet and drop any previously derived Diffie-Hellman keying material Kij it might have formed upon sending the I2 packet previously. The peer Diffie-Hellman key and the nonce #J are taken from the I2 packet that just arrived. The local Diffie-Hellman key and the nonce #I are the ones that were sent earlier in the R1 packet.
5. 如果系统的状态机处于I2-SENT状态，则系统必须对其本地点击和发送方点击进行比较（类似于第6.5节中描述的比较方法）。如果本地命中小于发送方的命中，则应丢弃I2数据包，使用先前接收到的R1数据包中的对等Diffie-Hellman密钥和nonce#I，并从先前发送到对等方的I2数据包中获取本地Diffie-Hellman密钥和nonce#J。否则，系统应处理接收到的I2数据包，并丢弃之前在发送I2数据包时可能形成的任何先前派生的Diffie-Hellman键控材料Kij。对等Diffie-Hellman密钥和nonce#J取自刚刚到达的I2数据包。本地Diffie-Hellman密钥和nonce#I是R1数据包中较早发送的密钥。
6. If the system's state machine is in the I1-SENT state, and the HITs in the I2 packet match those used in the previously sent I1 packet, the system uses this received I2 packet as the basis for the HIP association it was trying to form, and stops retransmitting I1 packets (provided that the I2 packet passes the additional checks below).
6. 如果系统的状态机处于I1-SENT状态，并且I2数据包中的命中与之前发送的I1数据包中使用的命中匹配，则系统将此接收到的I2数据包用作其试图形成的HIP关联的基础，并停止重传I1数据包（前提是I2数据包通过以下附加检查）。
7. If the system's state machine is in any state other than R2-SENT, the system SHOULD check that the echoed R1 generation counter in the I2 packet is within the acceptable range if the counter is included. Implementations MUST accept puzzles from the current generation and MAY accept puzzles from earlier generations. If the generation counter in the newly received I2 packet is outside the accepted range, the I2 packet is stale (and perhaps replayed) and SHOULD be dropped.
7. 如果系统的状态机处于R2-SENT以外的任何状态，则系统应检查I2数据包中的回波R1生成计数器是否在可接受范围内（如果包括计数器）。实现必须接受当前一代的谜题，也可以接受前几代的谜题。如果新接收到的I2数据包中的生成计数器超出可接受范围，则I2数据包已过时（可能已重放），应丢弃。
8. The system MUST validate the solution to the puzzle by computing the hash described in Section 5.3.3 using the same RHASH algorithm.
8. 系统必须通过使用相同的RHASH算法计算第5.3.3节中描述的哈希值来验证谜题的解决方案。
9. The I2 packet MUST have a single value in the HIP_CIPHER parameter, which MUST match one of the values offered to the Initiator in the R1 packet.
9. I2数据包的HIP_CIPHER参数中必须有一个值，该值必须与R1数据包中提供给启动器的一个值相匹配。
10. The system must derive Diffie-Hellman keying material Kij based on the public value and Group ID in the DIFFIE_HELLMAN parameter. This key is used to derive the HIP association keys, as described in Section 6.5. If the Diffie-Hellman Group ID is unsupported, the I2 packet is silently dropped.
10. 系统必须根据Diffie_Hellman参数中的公共值和组ID派生Diffie Hellman键控材料Kij。如第6.5节所述，该键用于衍生髋部关联键。如果Diffie-Hellman组ID不受支持，I2数据包将被静默丢弃。
11. The encrypted HOST_ID is decrypted by the Initiator's encryption key defined in Section 6.5. If the decrypted data is not a HOST_ID parameter, the I2 packet is silently dropped.
11. 加密的主机ID由第6.5节中定义的启动器加密密钥解密。如果解密的数据不是主机ID参数，则I2数据包将被静默丢弃。
12. The implementation SHOULD also verify that the Initiator's HIT in the I2 packet corresponds to the Host Identity sent in the I2 packet. (Note: some middleboxes may not be able to make this verification.)
12. 实现还应验证I2数据包中启动器的HIT是否对应于I2数据包中发送的主机标识。（注意：某些中间盒可能无法进行此验证。）
13. The system MUST process the TRANSPORT_FORMAT_LIST parameter. Other documents specifying transport formats (e.g., [RFC7402]) contain specifications for handling any specific transport selected.
13. 系统必须处理传输\格式\列表参数。指定运输格式的其他文件（如[RFC7402]）包含处理所选任何特定运输的规范。
14. The system MUST verify the HIP_MAC according to the procedures in Section 5.2.12.
14. 系统必须根据第5.2.12节中的程序验证HIP_MAC。
15. The system MUST verify the HIP_SIGNATURE according to Sections 5.2.14 and 5.3.3.
15. 系统必须根据第5.2.14节和第5.3.3节验证HIP_签名。
16. If the checks above are valid, then the system proceeds with further I2 processing; otherwise, it discards the I2 and its state machine remains in the same state.
16. 如果上述检查有效，则系统继续进行进一步的I2处理；否则，它将丢弃I2，其状态机将保持相同的状态。
17. The I2 packet may have the A-bit set -- in this case, the system MAY choose to refuse it by dropping the I2 and the state machine returns to state UNASSOCIATED. If the A-bit is set, the Initiator's HIT is anonymous and should not be stored permanently.
17. I2数据包可能设置了A位——在这种情况下，系统可能会选择通过丢弃I2来拒绝它，并且状态机返回到未关联状态。如果设置了A位，则启动器的命中是匿名的，不应永久存储。
18. The system initializes the remaining variables in the associated state, including Update ID counters.
18. 系统初始化处于关联状态的其余变量，包括更新ID计数器。
19. Upon successful processing of an I2 message when the system's state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2-SENT, an R2 packet is sent and the system's state machine transitions to state R2-SENT.
19. 当系统的状态机处于未关联、I1-SENT、I2-SENT或R2-SENT状态时，成功处理I2消息后，将发送R2数据包，系统的状态机将转换为状态R2-SENT。
20. Upon successful processing of an I2 packet when the system's state machine is in state ESTABLISHED, the old HIP association is dropped and a new one is installed, an R2 packet is sent, and the system's state machine transitions to R2-SENT.
20. 当系统的状态机处于已建立状态时，成功处理I2数据包后，旧的HIP关联将被丢弃并安装新的HIP关联，发送R2数据包，系统的状态机将转换为R2-sent。
21. Upon the system's state machine transitioning to R2-SENT, the system starts a timer. The state machine transitions to ESTABLISHED if some data has been received on the incoming HIP association, or an UPDATE packet has been received (or some other packet that indicates that the peer system's state machine has moved to ESTABLISHED). If the timer expires (allowing for a maximal amount of retransmissions of I2 packets), the state machine transitions to ESTABLISHED.
21. 当系统的状态机转换为R2-SENT时，系统启动计时器。如果在传入的HIP关联上已接收到一些数据，或已接收到更新数据包（或指示对等系统的状态机已移动到已建立状态的其他数据包），则状态机将转换为已建立状态机。如果计时器过期（允许最大数量的I2数据包重传），状态机将转换为已建立。
If an implementation receives a malformed I2 message, the behavior SHOULD depend on how many checks the message has already passed. If the puzzle solution in the message has already been checked, the implementation SHOULD report the error by responding with a NOTIFY packet. Otherwise, the implementation MAY respond with an ICMP message as defined in Section 5.4.
如果实现接收到格式错误的I2消息，则行为应取决于消息已通过的检查次数。如果消息中的谜题解决方案已被检查，则实现应通过使用NOTIFY数据包进行响应来报告错误。否则，实施可能会响应第5.4节中定义的ICMP消息。
An R2 packet received in state UNASSOCIATED, I1-SENT, or ESTABLISHED results in the R2 packet being dropped and the state machine staying in the same state. If an R2 packet is received in state I2-SENT, it MUST be processed.
在未关联、I1发送或已建立状态下接收的R2数据包导致R2数据包被丢弃，并且状态机保持在相同状态。如果在I2-SENT状态下接收到R2数据包，则必须对其进行处理。
The following steps define the conceptual processing rules for an incoming R2 packet:
以下步骤定义传入R2数据包的概念处理规则：
1. If the system is in any state other than I2-SENT, the R2 packet is silently dropped.
1. 如果系统处于I2-SENT以外的任何状态，R2数据包将被静默丢弃。
2. The system MUST verify that the HITs in use correspond to the HITs that were received in the R1 packet that caused the transition to the I1-SENT state.
2. 系统必须验证使用中的命中与导致转换到I1-SENT状态的R1数据包中接收到的命中相对应。
3. The system MUST verify the HIP_MAC_2 according to the procedures in Section 5.2.13.
3. 系统必须根据第5.2.13节中的程序验证HIP_MAC_2。
4. The system MUST verify the HIP signature according to the procedures in Section 5.2.14.
4. 系统必须根据第5.2.14节中的程序验证HIP签名。
5. If any of the checks above fail, there is a high probability of an ongoing man-in-the-middle or other security attack. The system SHOULD act accordingly, based on its local policy.
5. 如果上述任何一项检查失败，则极有可能发生中间人攻击或其他安全攻击。该系统应根据其当地政策采取相应行动。
6. Upon successful processing of the R2 packet, the state machine transitions to state ESTABLISHED.
6. 成功处理R2数据包后，状态机将转换为已建立状态。
A host sends an UPDATE packet when it intends to update some information related to a HIP association. There are a number of possible scenarios when this can occur, e.g., mobility management and rekeying of an existing ESP Security Association. The following paragraphs define the conceptual rules for sending an UPDATE packet to the peer. Additional steps can be defined in other documents where the UPDATE packet is used.
当主机打算更新与HIP关联相关的某些信息时，会发送更新数据包。出现这种情况时有许多可能的场景，例如，移动管理和现有ESP安全关联的密钥更新。以下段落定义了向对等方发送更新数据包的概念规则。其他步骤可以在使用更新包的其他文档中定义。
The sequence of UPDATE messages is indicated by their SEQ parameter. Before sending an UPDATE message, the system first determines whether there are any outstanding UPDATE messages that may conflict with the new UPDATE message under consideration. When multiple UPDATEs are outstanding (not yet acknowledged), the sender must assume that such UPDATEs may be processed in an arbitrary order by the receiver. Therefore, any new UPDATEs that depend on a previous outstanding UPDATE being successfully received and acknowledged MUST be postponed
更新消息的顺序由其SEQ参数指示。在发送更新消息之前，系统首先确定是否有任何未完成的更新消息可能与正在考虑的新更新消息冲突。当多个更新未完成（尚未确认）时，发送方必须假设接收方可以按任意顺序处理这些更新。因此，任何依赖于成功接收和确认先前未完成更新的新更新都必须推迟
until reception of the necessary ACK(s) occurs. One way to prevent any conflicts is to only allow one outstanding UPDATE at a time. However, allowing multiple UPDATEs may improve the performance of mobility and multihoming protocols.
直到接收到必要的ACK。防止任何冲突的一种方法是一次只允许一个未完成的更新。然而，允许多次更新可能会提高移动性和多归属协议的性能。
The following steps define the conceptual processing rules for sending UPDATE packets:
以下步骤定义了发送更新数据包的概念处理规则：
1. The first UPDATE packet is sent with an Update ID of zero. Otherwise, the system increments its own Update ID value by one before continuing the steps below.
1. 发送第一个更新数据包时，更新ID为零。否则，系统会将其自身的更新ID值增加1，然后继续以下步骤。
2. The system creates an UPDATE packet that contains a SEQ parameter with the current value of the Update ID. The UPDATE packet MAY also include zero or more ACKs of the peer's Update ID(s) from previously received UPDATE SEQ parameter(s).
2. 系统创建一个更新数据包，其中包含一个具有更新ID当前值的SEQ参数。更新数据包还可以包括来自先前接收到的UPDATE SEQ参数的零个或多个对等方更新ID确认。
3. The system sends the created UPDATE packet and starts an UPDATE timer. The default value for the timer is 2 * RTT estimate. If multiple UPDATEs are outstanding, multiple timers are in effect.
3. 系统发送创建的更新数据包并启动更新计时器。计时器的默认值为2*RTT估算值。如果多个更新未完成，则多个计时器生效。
4. If the UPDATE timer expires, the UPDATE is resent. The UPDATE can be resent UPDATE_RETRY_MAX times. The UPDATE timer SHOULD be exponentially backed off for subsequent retransmissions. If no acknowledgment is received from the peer after UPDATE_RETRY_MAX times, the HIP association is considered to be broken and the state machine SHOULD move from state ESTABLISHED to state CLOSING as depicted in Section 4.4.4. The UPDATE timer is cancelled upon receiving an ACK from the peer that acknowledges receipt of the UPDATE.
4. 如果更新计时器过期，则重新发送更新。可以重新更新\u重试\u最多次。更新计时器应以指数方式后退，以便后续重新传输。如果在更新_重试_最大次数后未收到来自对等方的确认，则认为HIP关联已断开，状态机应按照第4.4.4节所述从已建立状态移动到关闭状态。当从确认接收到更新的对等方接收到ACK时，更新计时器被取消。
When a system receives an UPDATE packet, its processing depends on the state of the HIP association and the presence and values of the SEQ and ACK parameters. Typically, an UPDATE message also carries optional parameters whose handling is defined in separate documents.
当系统接收到更新数据包时，其处理取决于HIP关联的状态以及SEQ和ACK参数的存在和值。通常，更新消息还包含可选参数，这些参数的处理在单独的文档中定义。
For each association, a host stores the peer's next expected in-sequence Update ID ("peer Update ID"). Initially, this value is zero. Update ID comparisons of "less than" and "greater than" are performed with respect to a circular sequence number space. Hence, a wraparound after 2^32 updates has to be expected and MUST be handled accordingly.
对于每个关联，主机存储对等方的下一个预期顺序更新ID（“对等方更新ID”）。最初，该值为零。针对循环序列号空间执行“小于”和“大于”的更新ID比较。因此，在2^32次更新之后必须进行换行，并且必须相应地进行处理。
The sender MAY send multiple outstanding UPDATE messages. These messages are processed in the order in which they are received at the receiver (i.e., no resequencing is performed). When processing
发件人可能会发送多条未完成的更新消息。这些消息按照在接收器接收的顺序进行处理（即，不执行重新排序）。加工时
UPDATEs out of order, the receiver MUST keep track of which UPDATEs were previously processed, so that duplicates or retransmissions are ACKed and not reprocessed. A receiver MAY choose to define a receive window of Update IDs that it is willing to process at any given time, and discard received UPDATEs falling outside of that window.
更新无序，接收方必须跟踪之前处理的更新，以便重复或重新传输得到确认，而不是重新处理。接收者可以选择定义其愿意在任何给定时间处理的更新id的接收窗口，并丢弃该窗口之外的接收更新。
The following steps define the conceptual processing rules for receiving UPDATE packets:
以下步骤定义接收更新数据包的概念处理规则：
1. If there is no corresponding HIP association, the implementation MAY reply with an ICMP Parameter Problem, as specified in Section 5.4.4.
1. 如第5.4.4节所述，如果没有相应的HIP关联，则实现可能会以ICMP参数问题进行回复。
2. If the association is in the ESTABLISHED state and the SEQ (but not ACK) parameter is present, the UPDATE is processed and replied to as described in Section 6.12.1.
2. 如果关联处于已建立状态且存在SEQ（但不是ACK）参数，则按照第6.12.1节中的说明处理和回复更新。
3. If the association is in the ESTABLISHED state and the ACK (but not SEQ) parameter is present, the UPDATE is processed as described in Section 6.12.2.
3. 如果关联处于已建立状态且存在ACK（但不存在SEQ）参数，则按照第6.12.2节所述处理更新。
4. If the association is in the ESTABLISHED state and there are both an ACK and SEQ in the UPDATE, the ACK is first processed as described in Section 6.12.2, and then the rest of the UPDATE is processed as described in Section 6.12.1.
4. 如果关联处于已建立状态，且更新中同时存在ACK和SEQ，则首先按照第6.12.2节所述处理ACK，然后按照第6.12.1节所述处理其余更新。
The following steps define the conceptual processing rules for handling a SEQ parameter in a received UPDATE packet:
以下步骤定义了处理接收到的更新数据包中的SEQ参数的概念处理规则：
1. If the Update ID in the received SEQ is not the next in the sequence of Update IDs and is greater than the receiver's window for new UPDATEs, the packet MUST be dropped.
1. 如果接收序列中的更新ID不是更新ID序列中的下一个，并且大于接收器的新更新窗口，则必须丢弃数据包。
2. If the Update ID in the received SEQ corresponds to an UPDATE that has recently been processed, the packet is treated as a retransmission. The HIP_MAC verification (next step) MUST NOT be skipped. (A byte-by-byte comparison of the received packet and a stored packet would be acceptable, though.) It is recommended that a host caches UPDATE packets sent with ACKs to avoid the cost of generating a new ACK packet to respond to a replayed UPDATE. The system MUST acknowledge, again, such (apparent) UPDATE message retransmissions but SHOULD also consider rate-limiting such retransmission responses to guard against replay attacks.
2. 如果接收到的SEQ中的更新ID对应于最近处理的更新，则分组被视为重传。不得跳过HIP_MAC验证（下一步）。（接收的数据包和存储的数据包的逐字节比较是可以接受的。）建议主机缓存随ACK发送的更新数据包，以避免生成新ACK数据包以响应重播更新的成本。系统必须再次确认这样的（明显的）更新消息重传，但也应该考虑速率限制这样的重传响应以防止重放攻击。
3. The system MUST verify the HIP_MAC in the UPDATE packet. If the verification fails, the packet MUST be dropped.
3. 系统必须验证更新数据包中的HIP_MAC。如果验证失败，则必须丢弃数据包。
4. The system MAY verify the SIGNATURE in the UPDATE packet. If the verification fails, the packet SHOULD be dropped and an error message logged.
4. 系统可验证更新分组中的签名。如果验证失败，则应丢弃数据包并记录错误消息。
5. If a new SEQ parameter is being processed, the parameters in the UPDATE are then processed. The system MUST record the Update ID in the received SEQ parameter, for replay protection.
5. 如果正在处理新的SEQ参数，则会处理更新中的参数。系统必须在收到的SEQ参数中记录更新ID，以进行重播保护。
6. An UPDATE acknowledgment packet with the ACK parameter is prepared and sent to the peer. This ACK parameter MAY be included in a separate UPDATE or piggybacked in an UPDATE with the SEQ parameter, as described in Section 5.3.5. The ACK parameter MAY acknowledge more than one of the peer's Update IDs.
6. 准备一个带有ACK参数的更新确认包并发送给对等方。如第5.3.5节所述，该ACK参数可包含在单独的更新中，也可与SEQ参数一起包含在更新中。ACK参数可以确认多个对等方的更新id。
The following steps define the conceptual processing rules for handling an ACK parameter in a received UPDATE packet:
以下步骤定义了处理接收到的更新数据包中的ACK参数的概念处理规则：
1. The sequence number reported in the ACK must match with an UPDATE packet sent earlier that has not already been acknowledged. If no match is found or if the ACK does not acknowledge a new UPDATE, then either the packet MUST be dropped if no SEQ parameter is present, or the processing steps in Section 6.12.1 are followed.
1. ACK中报告的序列号必须与之前发送的尚未确认的更新数据包相匹配。如果未找到匹配项或ACK未确认新的更新，则如果不存在SEQ参数，则必须丢弃数据包，或者遵循第6.12.1节中的处理步骤。
2. The system MUST verify the HIP_MAC in the UPDATE packet. If the verification fails, the packet MUST be dropped.
2. 系统必须验证更新数据包中的HIP_MAC。如果验证失败，则必须丢弃数据包。
3. The system MAY verify the SIGNATURE in the UPDATE packet. If the verification fails, the packet SHOULD be dropped and an error message logged.
3. 系统可验证更新分组中的签名。如果验证失败，则应丢弃数据包并记录错误消息。
4. The corresponding UPDATE timer is stopped (see Section 6.11) so that the now-acknowledged UPDATE is no longer retransmitted. If multiple UPDATEs are acknowledged, multiple timers are stopped.
4. 相应的更新计时器停止（参见第6.11节），以便不再重新传输现在已确认的更新。如果确认多个更新，则停止多个计时器。
Processing of NOTIFY packets is OPTIONAL. If processed, any errors in a received NOTIFICATION parameter SHOULD be logged. Received errors MUST be considered only as informational, and the receiver SHOULD NOT change its HIP state (see Section 4.4.2) purely based on the received NOTIFY message.
NOTIFY数据包的处理是可选的。如果已处理，则应记录收到的通知参数中的任何错误。接收到的错误必须仅被视为信息性错误，接收方不应纯粹根据接收到的NOTIFY消息更改其HIP状态（见第4.4.2节）。
When the host receives a CLOSE message, it responds with a CLOSE_ACK message and moves to the CLOSED state. (The authenticity of the CLOSE message is verified using both HIP_MAC and SIGNATURE.) This processing applies whether or not the HIP association state is CLOSING, in order to handle simultaneous CLOSE messages from both ends that cross in flight.
当主机接收到关闭消息时，它会以关闭确认消息作出响应，并移动到关闭状态。（使用HIP_MAC和签名验证关闭消息的真实性。）无论HIP关联状态是否关闭，此处理都适用，以便处理来自飞行中交叉的两端的同时关闭消息。
The HIP association is not discarded before the host moves to the UNASSOCIATED state.
在主体移动到未关联状态之前，不会放弃髋部关联。
Once the closing process has started, any new need to send data packets triggers the creation and establishment of a new HIP association, starting with sending an I1 packet.
一旦关闭过程开始，任何发送数据包的新需求都会触发新HIP关联的创建和建立，从发送I1数据包开始。
If there is no corresponding HIP association, the CLOSE packet is dropped.
如果没有相应的HIP关联，则丢弃CLOSE数据包。
When a host receives a CLOSE_ACK message, it verifies that it is in the CLOSING or CLOSED state and that the CLOSE_ACK was in response to the CLOSE. A host can map CLOSE_ACK messages to CLOSE messages by comparing the value of ECHO_REQUEST_SIGNED (in the CLOSE packet) to the value of ECHO_RESPONSE_SIGNED (in the CLOSE_ACK packet).
当主机收到CLOSE_ACK消息时，它将验证主机是否处于关闭或关闭状态，以及CLOSE_ACK是否响应关闭。主机可以通过比较ECHO_REQUEST_SIGNED（在CLOSE数据包中）的值与ECHO_RESPONSE_SIGNED（在CLOSE_ACK数据包中）的值，将CLOSE_ACK消息映射到CLOSE消息。
The CLOSE_ACK contains the HIP_MAC and the SIGNATURE parameters for verification. The state is discarded when the state changes to UNASSOCIATED and, after that, the host MAY respond with an ICMP Parameter Problem to an incoming CLOSE message (see Section 5.4.4).
CLOSE_ACK包含HIP_MAC和用于验证的签名参数。当状态更改为“未关联”时，该状态将被丢弃，之后，主机可能会对传入的关闭消息响应ICMP参数问题（请参阅第5.4.4节）。
In the case of a system crash and unanticipated state loss, the system SHOULD delete the corresponding HIP state, including the keying material. That is, the state SHOULD NOT be stored in long-term storage. If the implementation does drop the state (as RECOMMENDED), it MUST also drop the peer's R1 generation counter value, unless a local policy explicitly defines that the value of that particular host is stored. An implementation MUST NOT store a peer's R1 generation counters by default, but storing R1 generation counter values, if done, MUST be configured by explicit HITs.
在系统崩溃和意外状态丢失的情况下，系统应删除相应的HIP状态，包括键控材质。也就是说，状态不应存储在长期存储中。如果实现确实删除了状态（按照建议），则还必须删除对等方的R1生成计数器值，除非本地策略明确定义存储该特定主机的值。默认情况下，实现不能存储对等方的R1生成计数器，但如果存储R1生成计数器值，则必须通过显式命中进行配置。
There are a number of variables that will influence the HIP base exchanges that each host must support. All HIP implementations MUST support more than one simultaneous HI, at least one of which SHOULD be reserved for anonymous usage. Although anonymous HIs will be rarely used as Responders' HIs, they will be common for Initiators. Support for more than two HIs is RECOMMENDED.
有许多变量将影响每个主持人必须支持的髋关节基础交换。所有HIP实现必须支持多个同时HI，其中至少一个HI应保留供匿名使用。虽然匿名HIs很少被用作响应者的HIs，但它们对于发起者来说很常见。建议支持两个以上的HIs。
Initiators MAY use a different HI for different Responders to provide basic privacy. Whether such private HIs are used repeatedly with the same Responder, and how long these HIs are used, are decided by local policy and depend on the privacy requirements of the Initiator.
发起者可以为不同的响应者使用不同的HI来提供基本的隐私。此类私人HIs是否与同一响应者重复使用，以及使用这些HIs的时间长短，由当地政策决定，并取决于发起人的隐私要求。
The value of #K used in the HIP R1 must be chosen with care. Values of #K that are too high will exclude clients with weak CPUs because these devices cannot solve the puzzle within a reasonable amount of time. #K should only be raised if a Responder is under high load, i.e., it cannot process all incoming HIP handshakes any more. If a Responder is not under high load, #K SHOULD be 0.
髋部R1中使用的#K值必须小心选择。#K值过高将排除CPU较弱的客户端，因为这些设备无法在合理的时间内解决难题#仅当响应者处于高负载下时，即不能再处理所有传入的髋部握手时，才应提升K。如果响应程序未处于高负载下，#K应为0。
Responders that only respond to selected Initiators require an Access Control List (ACL), representing for which hosts they accept HIP base exchanges, and the preferred transport format and local lifetimes. Wildcarding SHOULD be supported for such ACLs, and also for Responders that offer public or anonymous services.
仅响应选定启动器的响应程序需要访问控制列表（ACL），该列表表示它们接受HIP-base交换的主机、首选传输格式和本地生存时间。此类ACL以及提供公共或匿名服务的响应者都应支持通配符。
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. In doing so, HIP itself is subject to its own DoS and MitM attacks that potentially could be more damaging to a host's ability to conduct business as usual.
HIP旨在提供主机的安全身份验证。HIP还试图限制主机受到各种拒绝服务和中间人（MitM）攻击。在这样做的过程中，HIP本身会受到自己的DoS和MitM攻击，这些攻击可能会对主机正常开展业务的能力造成更大的损害。
Denial-of-service attacks often take advantage of asymmetries in the cost of starting an association. One example of such asymmetry is the need of a Responder to store local state while a malicious Initiator can stay stateless. HIP makes no attempt to increase the cost of the start of state at the Initiator, but makes an effort to reduce the cost for the Responder. This is accomplished by having the Responder start the 3-way exchange instead of the Initiator, making the HIP exchange 4 packets long. In doing this, the first packet from the Responder, R1, becomes a 'stock' packet that the Responder MAY use many times, until some Initiator has provided a valid response to such an R1 packet. During an I1 packet storm, the host may reuse the same DH value also, even if some Initiator has
拒绝服务攻击通常利用启动关联的不对称性。这种不对称性的一个例子是，响应程序需要存储本地状态，而恶意启动器可以保持无状态。HIP没有试图增加发起者状态开始的成本，而是努力降低响应者的成本。这是通过让响应者启动3路交换而不是启动器来实现的，使HIP交换4个数据包长。在这样做时，来自响应者R1的第一个数据包成为响应者可以多次使用的“库存”数据包，直到某个启动器已经对这样的R1数据包提供了有效响应。在I1数据包风暴期间，主机也可以重用相同的DH值，即使某些启动器已
provided a valid response using that particular DH value. However, such behavior is discouraged and should be avoided. Using the same Diffie-Hellman values and random puzzle #I value has some risks. This risk needs to be balanced against a potential storm of HIP I1 packets.
使用该特定DH值提供了有效响应。然而，这种行为是不鼓励的，应该避免。使用相同的Diffie-Hellman值和随机拼图#I值有一些风险。这种风险需要与HIP I1数据包的潜在风暴相平衡。
This shifting of the start of state cost to the Initiator in creating the I2 HIP packet presents another DoS attack. The attacker can spoof the I1 packet, and the Responder sends out the R1 HIP packet. This could conceivably tie up the 'Initiator' with evaluating the R1 HIP packet, and creating the I2 packet. The defense against this attack is to simply ignore any R1 packet where a corresponding I1 packet was not sent (as defined in Section 6.8, step 1).
在创建I2 HIP数据包时，将起始状态成本转移到发起方，这是另一种DoS攻击。攻击者可以欺骗I1数据包，响应者发送R1 HIP数据包。这可能会将“启动器”与评估R1 HIP数据包和创建I2数据包联系起来。针对该攻击的防御措施是忽略没有发送相应I1数据包的任何R1数据包（如第6.8节第1步所定义）。
The R1 packet is considerably larger than the I1 packet. This asymmetry can be exploited in a reflection attack. A malicious attacker could spoof the IP address of a victim and send a flood of I1 messages to a powerful Responder. For each small I1 packet, the Responder would send a larger R1 packet to the victim. The difference in packet sizes can further amplify a flooding attack against the victim. To avoid such reflection attacks, the Responder SHOULD rate-limit the sending of R1 packets in general or SHOULD rate-limit the sending of R1 packets to a specific IP address.
R1数据包比I1数据包大得多。这种不对称性可以在反射攻击中加以利用。恶意攻击者可以欺骗受害者的IP地址，并向功能强大的响应者发送大量I1消息。对于每个小的I1数据包，响应者将向受害者发送一个较大的R1数据包。数据包大小的差异会进一步放大针对受害者的洪水攻击。为了避免这种反射攻击，响应者通常应该对R1数据包的发送进行速率限制，或者应该对R1数据包发送到特定IP地址进行速率限制。
Floods of forged I2 packets form a second kind of DoS attack. Once the attacking Initiator has solved the puzzle, it can send packets with spoofed IP source addresses with either an invalid HIP signature or invalid encrypted HIP payload (in the ENCRYPTED parameter). This would take resources in the Responder's part to reach the point to discover that the I2 packet cannot be completely processed. The defense against this attack is that after N bad I2 packets with the same puzzle solution, the Responder would discard any I2 packets that contain the given solution. This will shut down the attack. The attacker would have to request another R1 packet and use that to launch a new attack. The Responder could increase the value of #K while under attack. Keeping a list of solutions from malformed packets requires that the Responder keeps state for these malformed I2 packets. This state has to be kept until the R1 counter is increased. As malformed packets are generally filtered by their checksum before signature verification, only solutions in packets that are forged to pass the checksum and puzzle are put into the blacklist. In addition, a valid puzzle is required before a new list entry is created. Hence, attackers that intend to flood the blacklist must solve puzzles first.
伪造I2数据包的泛滥形成了第二种DoS攻击。一旦攻击发起方解决了这个难题，它就可以发送带有伪造IP源地址的数据包，这些IP源地址具有无效的HIP签名或无效的加密HIP有效负载（在加密参数中）。这将需要响应者的资源来发现I2数据包无法完全处理。针对这种攻击的防御措施是，在N个具有相同谜题解决方案的坏I2数据包之后，响应者将丢弃包含给定解决方案的任何I2数据包。这将使攻击停止。攻击者必须请求另一个R1数据包并使用该数据包发起新的攻击。响应者可以在受到攻击时增加#K的值。从格式错误的数据包中保留解决方案列表要求响应程序保留这些格式错误的I2数据包的状态。必须保持此状态，直到R1计数器增加。由于格式错误的数据包通常在签名验证之前通过校验和过滤，因此只有伪造的数据包中的解决方案通过校验和和拼图，才会被放入黑名单。此外，在创建新的列表条目之前，需要一个有效的拼图。因此，打算淹没黑名单的攻击者必须首先解决谜题。
A third form of DoS attack is emulating the restart of state after a reboot of one of the peers. A restarting host would send an I1 packet to the peers, which would respond with an R1 packet even if it were in the ESTABLISHED state. If the I1 packet were spoofed, the resulting R1 packet would be received unexpectedly by the spoofed host and would be dropped, as in the first case above.
第三种形式的DoS攻击是模拟一个对等方重新启动后状态的重新启动。重新启动的主机将向对等方发送I1数据包，即使它处于已建立的状态，对等方也将以R1数据包进行响应。如果I1数据包被欺骗，那么被欺骗的主机将意外地接收到结果R1数据包，并将丢弃，如上述第一种情况所示。
A fourth form of DoS attack is emulating the closing of the HIP association. HIP relies on timers and a CLOSE/CLOSE_ACK handshake to explicitly signal the end of a HIP association. Because both CLOSE and CLOSE_ACK messages contain a HIP_MAC, an outsider cannot close a connection. The presence of an additional SIGNATURE allows middleboxes to inspect these messages and discard the associated state (e.g., for firewalling, SPI-based NATing, etc.). However, the optional behavior of replying to CLOSE with an ICMP Parameter Problem packet (as described in Section 5.4.4) might allow an attacker spoofing the source IP address to send CLOSE messages to launch reflection attacks.
第四种形式的拒绝服务攻击是模拟髋关节协会的关闭。HIP依赖计时器和闭合/闭合确认握手来明确表示HIP关联的结束。因为CLOSE和CLOSE_ACK消息都包含HIP_MAC，所以外部用户无法关闭连接。附加签名的存在允许中间盒检查这些消息并丢弃相关状态（例如，防火墙、基于SPI的本机等）。但是，使用ICMP参数问题数据包（如第5.4.4节所述）回复关闭的可选行为可能允许攻击者欺骗源IP地址以发送关闭消息以发起反射攻击。
A fifth form of DoS attack is replaying R1s to cause the Initiator to solve stale puzzles and become out of synchronization with the Responder. The R1 generation counter is a monotonically increasing counter designed to protect against this attack, as described in Section 4.1.4.
第五种形式的DoS攻击是重放R1s，导致发起方解决陈旧的难题，并与响应方失去同步。如第4.1.4节所述，R1生成计数器是一个单调递增计数器，旨在防止这种攻击。
Man-in-the-middle attacks are difficult to defend against, without third-party authentication. A skillful MitM could easily handle all parts of HIP, but HIP indirectly provides the following protection from a MitM attack. If the Responder's HI is retrieved from a signed DNS zone, a certificate, or through some other secure means, the Initiator can use this to validate the R1 HIP packet.
如果没有第三方身份验证，中间人攻击很难防御。一个熟练的MitM可以很容易地处理髋关节的所有部位，但髋关节间接地提供以下保护，以防MitM攻击。如果从签名DNS区域、证书或通过某些其他安全方式检索响应者的HI，则发起方可以使用此来验证R1 HIP数据包。
Likewise, if the Initiator's HI is in a secure DNS zone, a trusted certificate, or otherwise securely available, the Responder can retrieve the HI (after having got the I2 HIP packet) and verify that the HI indeed can be trusted.
同样，如果发起方的HI位于安全DNS区域、可信证书或其他安全可用的位置，则响应方可以检索HI（在获得I2 HIP数据包之后），并验证HI确实可以被信任。
The HIP "opportunistic mode" concept has been introduced in this document, but this document does not specify what the semantics of such a connection setup are for applications. There are certain concerns with opportunistic mode, as discussed in Section 4.1.8.
本文档中引入了HIP“机会主义模式”概念，但本文档未指定应用程序的这种连接设置的语义。如第4.1.8节所述，机会主义模式存在某些问题。
NOTIFY messages are used only for informational purposes, and they are unacknowledged. A HIP implementation cannot rely solely on the information received in a NOTIFY message because the packet may have been replayed. An implementation SHOULD NOT change any state information purely based on a received NOTIFY message.
NOTIFY消息仅用于提供信息，未经确认。HIP实现不能仅仅依赖于在NOTIFY消息中接收的信息，因为数据包可能已被重放。实现不应纯粹基于收到的NOTIFY消息更改任何状态信息。
Since not all hosts will ever support HIP, ICMP 'Destination Protocol Unreachable' messages are to be expected and may be used for a DoS attack. Against an Initiator, the attack would look like the Responder does not support HIP, but shortly after receiving the ICMP message, the Initiator would receive a valid R1 HIP packet. Thus, to protect against this attack, an Initiator SHOULD NOT react to an ICMP message until a reasonable delta time to get the real Responder's R1 HIP packet. A similar attack against the Responder is more involved. Normally, if an I1 message received by a Responder was a bogus one sent by an attacker, the Responder may receive an ICMP message from the IP address the R1 message was sent to. However, a sophisticated attacker can try to take advantage of such behavior and try to break up the HIP base exchange by sending such an ICMP message to the Responder before the Initiator has a chance to send a valid I2 message. Hence, the Responder SHOULD NOT act on such an ICMP message. Especially, it SHOULD NOT remove any minimal state created when it sent the R1 HIP packet (if it did create one), but wait for either a valid I2 HIP packet or the natural timeout (that is, if R1 packets are tracked at all). Likewise, the Initiator SHOULD ignore any ICMP message while waiting for an R2 HIP packet, and SHOULD delete any pending state only after a natural timeout.
由于并非所有主机都支持HIP，因此ICMP“目标协议不可访问”消息可能会被用于DoS攻击。针对发起方，攻击看起来像响应方不支持HIP，但在收到ICMP消息后不久，发起方将收到有效的R1 HIP数据包。因此，为了防止这种攻击，发起者不应该对ICMP消息做出反应，直到一个合理的增量时间才能得到真正响应者的R1 HIP数据包。针对响应者的类似攻击更为复杂。通常，如果响应者收到的I1消息是攻击者发送的伪造消息，则响应者可能会从R1消息发送到的IP地址接收ICMP消息。但是，老练的攻击者可以尝试利用这种行为，在发起方有机会发送有效的I2消息之前，通过向响应方发送这样的ICMP消息，尝试破坏HIP-base交换。因此，响应者不应对此类ICMP消息采取行动。特别是，它不应该删除发送R1 HIP数据包时创建的任何最小状态（如果它确实创建了一个），而应该等待有效的I2 HIP数据包或自然超时（即，如果完全跟踪R1数据包）。同样，在等待R2 HIP数据包时，启动器应忽略任何ICMP消息，并应仅在自然超时后删除任何挂起状态。
IANA has reserved protocol number 139 for the Host Identity Protocol and included it in the "IPv6 Extension Header Types" registry [RFC7045] and the "Assigned Internet Protocol Numbers" registry. The reference in both of these registries has been updated from [RFC5201] to this specification.
IANA为主机标识协议保留了协议编号139，并将其包括在“IPv6扩展头类型”注册表[RFC7045]和“分配的Internet协议编号”注册表中。这两个注册表中的参考已从[RFC5201]更新为本规范。
The reference to the 128-bit value under the CGA Message Type namespace [RFC3972] of "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA" has been changed from [RFC5201] to this specification.
“0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA”CGA消息类型命名空间[RFC3972]下对128位值的引用已从[RFC5201]更改为本规范。
The following changes to the "Host Identity Protocol (HIP) Parameters" have been made. In many cases, the changes involved updating the reference from [RFC5201] to this specification, but there are some differences as outlined below. Allocation terminology is defined in [RFC5226]; any existing references to "IETF Consensus" can be replaced with "IETF Review" as per [RFC5226].
对“主机标识协议（HIP）参数”进行了以下更改。在许多情况下，变更涉及将参考从[RFC5201]更新到本规范，但存在如下所述的一些差异。[RFC5226]中定义了分配术语；根据[RFC5226]，任何对“IETF共识”的现有引用可替换为“IETF审查”。
HIP Version
髋关节型
This document adds the value "2" to the existing registry. The value of "1" has been left with a reference to [RFC5201].
此文档将值“2”添加到现有注册表中。参考[RFC5201]留下了“1”的值。
Packet Type
包类型
The 7-bit Packet Type field in a HIP protocol packet describes the type of a HIP protocol message. It is defined in Section 5.1. All existing values referring to [RFC5201] have been updated to refer to this specification. Other values have been left unchanged.
HIP协议数据包中的7位数据包类型字段描述HIP协议消息的类型。其定义见第5.1节。参考[RFC5201]的所有现有值已更新为参考本规范。其他值保持不变。
HIT Suite ID
命中套件ID
This specification creates a new registry for "HIT Suite ID". This is different than the existing registry for "Suite ID", which can be left unmodified for version 1 of the protocol ([RFC5201]). The registry has been closed to new registrations.
此规范为“HIT套件ID”创建一个新注册表。这与“套件ID”的现有注册表不同，对于协议的版本1（[RFC5201]），该注册表可以保持不变。注册处已关闭，禁止新注册。
The four-bit HIT Suite ID uses the OGA ID field in the ORCHID to express the type of the HIT. This document defines three HIT Suites (see Section 5.2.10).
四位命中套件ID使用兰花中的OGA ID字段来表示命中类型。本文件定义了三个HIT套件（见第5.2.10节）。
The HIT Suite ID is also carried in the four higher-order bits of the ID field in the HIT_SUITE_LIST parameter. The four lower-order bits are reserved for future extensions of the HIT Suite ID space beyond 16 values.
命中套件ID也包含在命中套件列表参数中ID字段的四个高阶位中。四个低阶位保留用于HIT套件ID空间的未来扩展（超过16个值）。
For the time being, the HIT Suite uses only four bits because these bits have to be carried in the HIT. Using more bits for the HIT Suite ID reduces the cryptographic strength of the HIT. HIT Suite IDs must be allocated carefully to avoid namespace exhaustion. Moreover, deprecated IDs should be reused after an appropriate time span. If 15 Suite IDs (the zero value is initially reserved) prove to be insufficient and more HIT Suite IDs are needed concurrently, more bits can be used for the HIT Suite ID by using one HIT Suite ID (0) to indicate that more bits should be used. The HIT_SUITE_LIST parameter already supports 8-bit HIT Suite IDs, should longer IDs be needed. However, RFC 7343 [RFC7343] does not presently support such an extension. We suggest trying the rollover approach described in Appendix E first. Possible extensions of the HIT Suite ID space to accommodate eight bits and new HIT Suite IDs are defined through IETF Review.
目前，HIT套件仅使用四位，因为这些位必须在HIT中携带。为HIT套件ID使用更多位会降低HIT的加密强度。必须小心地分配HIT套件ID，以避免名称空间耗尽。此外，不推荐使用的ID应在适当的时间跨度后重新使用。如果15个套件ID（最初保留零值）证明不足，并且同时需要更多的HIT套件ID，则可以通过使用一个HIT套件ID（0）来为HIT套件ID使用更多位，以指示应使用更多位。如果需要更长的ID，HIT_SUITE_LIST参数已经支持8位HIT SUITE ID。但是，RFC 7343[RFC7343]目前不支持这种扩展。我们建议首先尝试附录E中描述的滚动方法。可以扩展HIT套件ID空间以容纳8位和新的HIT套件ID，这些都是通过IETF审查定义的。
Requests to register reused values should include a note that the value is being reused after a deprecation period, to ensure appropriate IETF review and approval.
注册重用值的请求应包括一个注释，说明该值在弃用期后被重用，以确保适当的IETF审查和批准。
Parameter Type
参数类型
The 16-bit Type field in a HIP parameter describes the type of the parameter. It is defined in Section 5.2.1. The current values are defined in Sections 5.2.3 through 5.2.23. The existing "Parameter Types" registry has been updated as follows.
HIP参数中的16位类型字段描述参数的类型。其定义见第5.2.1节。电流值在第5.2.3节至第5.2.23节中定义。现有的“参数类型”注册表已更新如下。
A new value (129) for R1_COUNTER has been introduced, with a reference to this specification, and the existing value (128) for R1_COUNTER has been left in place with a reference to [RFC5201]. This documents the change in value that has occurred in version 2 of this protocol. For clarity, the name for the value 128 has been changed from "R1_COUNTER" to "R1_Counter (v1 only)".
参考本规范，R1_计数器引入了一个新值（129），R1_计数器的现有值（128）参考[RFC5201]保留不变。这记录了本协议第2版中发生的值更改。为清楚起见，值128的名称已从“R1_计数器”更改为“R1_计数器（仅v1）”。
A new value (579) for a new Parameter Type HIP_CIPHER has been added, with reference to this specification. This Parameter Type functionally replaces the HIP_TRANSFORM Parameter Type (value 577), which has been left in the table with the existing reference to [RFC5201]. For clarity, the name for the value 577 has been changed from "HIP_TRANSFORM" to "HIP_TRANSFORM (v1 only)".
参考本规范，添加了新参数类型HIP_密码的新值（579）。该参数类型在功能上替代了HIP_变换参数类型（值577），该参数类型已保留在表中，并带有对[RFC5201]的现有引用。为清楚起见，值577的名称已从“HIP_变换”更改为“HIP_变换（仅v1）”。
A new value (715) for a new Parameter Type HIT_SUITE_LIST has been added, with reference to this specification.
参考本规范，添加了新参数类型HIT_SUITE_列表的新值（715）。
A new value (2049) for a new Parameter Type TRANSPORT_FORMAT_LIST has been added, with reference to this specification.
参考本规范，为新参数类型TRANSPORT_FORMAT_LIST添加了一个新值（2049）。
The name of the HMAC Parameter Type (value 61505) has been changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value 61569) has been changed to HIP_MAC_2. The reference has been changed to this specification.
HMAC参数类型（值61505）的名称已更改为HIP_MAC。HMAC_2参数类型（值61569）的名称已更改为HIP_MAC_2。参考已更改为本规范。
All other Parameter Types that reference [RFC5201] have been updated to refer to this specification, and Parameter Types that reference other RFCs are unchanged.
参考[RFC5201]的所有其他参数类型已更新为参考本规范，参考其他RFC的参数类型不变。
The Type codes 32768 through 49151 (not 49141: a value corrected from a previous version of this table) have been Reserved for Private Use. Implementors SHOULD select types in a random fashion from this range, thereby reducing the probability of collisions. A method employing genuine randomness (such as flipping a coin) SHOULD be used.
类型代码32768至49151（不是49141：根据本表先前版本更正的值）已保留供私人使用。实现者应该以随机方式从这个范围中选择类型，从而降低冲突的概率。应该使用一种真正随机的方法（比如掷硬币）。
Where the existing ranges once stated "First Come First Served with Specification Required", this has been changed to "Specification Required".
如果现有范围曾规定“先到先得，规格要求”，则已改为“规格要求”。
Group ID
组ID
The eight-bit Group ID values appear in the DIFFIE_HELLMAN parameter and the DH_GROUP_LIST parameter and are defined in Section 5.2.7. This registry has been updated based on the new values specified in Section 5.2.7; values noted as being DEPRECATED can be left in the table with reference to [RFC5201]. New values are assigned through IETF Review.
八位组ID值出现在DIFFIE_HELLMAN参数和DH_Group_列表参数中，并在第5.2.7节中定义。该注册表已根据第5.2.7节中规定的新值进行了更新；表中可参考[RFC5201]保留注释为已弃用的值。通过IETF评审分配新值。
HIP Cipher ID
HIP密码ID
The 16-bit Cipher ID values in a HIP_CIPHER parameter are defined in Section 5.2.8. This is a new registry. New values from either the reserved or unassigned space are assigned through IETF Review.
HIP_密码参数中的16位密码ID值在第5.2.8节中定义。这是一个新的注册表。保留或未分配空间中的新值通过IETF评审进行分配。
DI-Type
DI型
The four-bit DI-Type values in a HOST_ID parameter are defined in Section 5.2.9. New values are assigned through IETF Review. All existing values referring to [RFC5201] have been updated to refer to this specification.
主机ID参数中的四位DI类型值在第5.2.9节中定义。通过IETF评审分配新值。参考[RFC5201]的所有现有值已更新为参考本规范。
HI Algorithm
HI算法
The 16-bit Algorithm values in a HOST_ID parameter are defined in Section 5.2.9. This is a new registry. New values from either the reserved or unassigned space are assigned through IETF Review.
主机ID参数中的16位算法值在第5.2.9节中定义。这是一个新的注册表。保留或未分配空间中的新值通过IETF评审进行分配。
ECC Curve Label
曲线标签
When the HI Algorithm values in a HOST_ID parameter are defined to the values of either "ECDSA" or "ECDSA_LOW", a new registry is needed to maintain the values for the ECC Curve Label as defined in Section 5.2.9. This might be handled by specifying two algorithm-specific subregistries named "ECDSA Curve Label" and "ECDSA_LOW Curve Label". New values are to be assigned through IETF Review.
当HOST_ID参数中的HI算法值定义为“ECDSA”或“ECDSA_LOW”的值时，需要一个新的注册表来维护第5.2.9节中定义的ECC曲线标签的值。这可以通过指定两个名为“ECDSA曲线标签”和“ECDSA_低曲线标签”的算法特定子区域来处理。新值将通过IETF评审分配。
Notify Message Type
通知消息类型
The 16-bit Notify Message Type values in a NOTIFICATION parameter are defined in Section 5.2.19.
第5.2.19节定义了通知参数中的16位通知消息类型值。
Notify Message Type values 1-10 are used for informing about errors in packet structures, values 11-20 for informing about problems in parameters containing cryptographic related material, and values 21-30 for informing about problems in authentication or packet integrity verification. Parameter numbers above 30 can be used for informing about other types of errors or events.
通知消息类型值1-10用于通知数据包结构中的错误，值11-20用于通知包含加密相关材料的参数中的问题，值21-30用于通知身份验证或数据包完整性验证中的问题。大于30的参数编号可用于通知其他类型的错误或事件。
The existing registration procedures have been updated as follows. The range from 1-50 can remain as "IETF Review". The range from 51-8191 has been marked as "Specification Required". Values 8192-16383 remain as "Reserved for Private Use". Values 16384-40959 have been marked as "Specification Required". Values 40960-65535 remain as "Reserved for Private Use".
现行登记程序已更新如下。1-50的范围可以保留为“IETF审查”。51-8191的范围标记为“所需规格”。值8192-16383保留为“专用”。值16384-40959已标记为“所需规格”。值40960-65535保留为“专用”。
The following updates to the values have been made to the existing registry. All existing values referring to [RFC5201] have been updated to refer to this specification.
对现有注册表中的值进行了以下更新。参考[RFC5201]的所有现有值已更新为参考本规范。
INVALID_HIP_TRANSFORM_CHOSEN has been renamed to INVALID_HIP_CIPHER_CHOSEN with the same value (17).
选择的无效\u HIP\u变换\u已重命名为使用相同值选择的无效\u HIP\u密码\u（17）。
A new value of 20 for the type UNSUPPORTED_HIT_SUITE has been added.
已为类型UNSUPPORTED\u HIT\u套件添加了一个新值20。
HMAC_FAILED has been renamed to HIP_MAC_FAILED with the same value (28).
HMAC_FAILED已重命名为HIP_MAC_FAILED，具有相同的值（28）。
SERVER_BUSY_PLEASE_RETRY has been renamed to RESPONDER_BUSY_PLEASE_RETRY with the same value (44).
服务器\u忙\u请\u重试已重命名为响应者\u忙\u请\u重试，使用相同的值（44）。
This section summarizes the technical changes made from [RFC5201]. This section is informational, intended to help implementors of the previous protocol version. If any text in this section contradicts text in other portions of this specification, the text found outside of this section should be considered normative.
本节总结了[RFC5201]所做的技术更改。本节仅供参考，旨在帮助先前协议版本的实施者。如果本节中的任何文本与本规范其他部分中的文本相矛盾，则本节以外的文本应视为规范性文本。
This document specifies the HIP Version 2 protocol, which is not interoperable with the HIP Version 1 protocol specified in [RFC5201]. The main technical changes are the inclusion of additional cryptographic agility features, and an update of the mandatory and optional algorithms, including Elliptic Curve support via the
本文件规定了HIP版本2协议，该协议与[RFC5201]中规定的HIP版本1协议不可互操作。主要的技术变化是包含了额外的加密灵活性功能，以及对强制和可选算法的更新，包括通过
Elliptic Curve DSA (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH) algorithms. The mandatory cryptographic algorithm implementations have been updated, such as replacing HMAC-SHA-1 with HMAC-SHA-256 and the RSA/SHA-1 signature algorithm with RSASSA-PSS, and adding ECDSA to RSA as mandatory public key types. This version of HIP is also aligned with the ORCHID revision [RFC7343].
椭圆曲线DSA（ECDSA）和椭圆曲线Diffie-Hellman（ECDH）算法。强制加密算法实现已经更新，例如用HMAC-SHA-256替换HMAC-SHA-1，用RSASSA-PSS替换RSA/SHA-1签名算法，并将ECDSA作为强制公钥类型添加到RSA中。该版本的HIP也与兰花修订版[RFC7343]一致。
The following changes have been made to the protocol operation.
对协议操作进行了以下更改。
o Section 4.1.3 describes the new process for Diffie-Hellman group negotiation, an aspect of cryptographic agility. The Initiator may express a preference for the choice of a DH group in the I1 packet and may suggest multiple possible choices. The Responder replies with a preference based on local policy and the options provided by the Initiator. The Initiator may restart the base exchange if the option chosen by the Responder is unsuitable (unsupported algorithms).
o 第4.1.3节描述了Diffie-Hellman组协商的新过程，这是加密灵活性的一个方面。发起方可以表示对I1分组中DH组的选择的偏好，并且可以建议多个可能的选择。响应程序根据本地策略和启动器提供的选项以首选项进行响应。如果响应程序选择的选项不合适（不支持的算法），则发起程序可能会重新启动基本exchange。
o Another aspect of cryptographic agility that has been added is the ability to use different cryptographic hash functions to generate the HIT. The Responder's HIT hash algorithm (RHASH) terminology was introduced to support this. In addition, HIT Suites have been introduced to group the set of cryptographic algorithms used together for public key signature, hash function, and hash truncation. The use of HIT Suites constrains the combinatorial possibilities of algorithm selection for different functions. HIT Suite IDs are related to the ORCHID OGA ID field ([RFC7343]).
o 加密灵活性的另一个方面是使用不同的加密哈希函数生成命中的能力。响应者的命中哈希算法（RHASH）术语就是为了支持这一点而引入的。此外，还引入了HIT套件，以将公钥签名、哈希函数和哈希截断使用的加密算法集分组。HIT套件的使用限制了不同函数算法选择的组合可能性。HIT套件ID与兰花OGA ID字段（[RFC7343]）相关。
o The puzzle mechanism has been slightly changed, in that the #I parameter depends on the HIT hash function (RHASH) selected, and the specification now advises against reusing the same #I value to the same Initiator; more details are provided in Sections 4.1.2 and 5.2.4).
o 谜题机制已略有改变，即#I参数取决于所选的命中哈希函数（RHASH），规范现在建议不要将相同的#I值重用到同一启动器；更多详情见第4.1.2节和第5.2.4节）。
o Section 4.1.4 was extended to cover details about R1 generation counter rollover or reset.
o 第4.1.4节已扩展，以涵盖有关R1代计数器翻转或重置的详细信息。
o Section 4.1.6 was added to describe procedures for aborting a HIP base exchange.
o 增加了第4.1.6节，以描述中止髋关节置换的程序。
o Section 4.1.7 provides guidance on avoiding downgrade attacks on the cryptographic algorithms.
o 第4.1.7节提供了避免对加密算法进行降级攻击的指南。
o Section 4.1.8 on opportunistic mode has been updated to account for cryptographic agility by adding HIT selection procedures.
o 关于机会主义模式的第4.1.8节已经更新，通过添加命中选择程序来说明加密灵活性。
o The HIP KEYMAT generation has been updated as described in Section 6.5 to make the key derivation function a negotiable aspect of the protocol.
o HIP键盘生成已按照第6.5节所述进行更新，以使密钥派生功能成为协议的可协商方面。
o Packet processing for the I1, R1, and I2 packets has been updated to account for new parameter processing.
o I1、R1和I2数据包的数据包处理已更新，以说明新的参数处理。
o This specification adds a requirement that hosts MUST support processing of ACK parameters with several SEQ sequence numbers even when they do not support sending such parameters.
o 本规范增加了一项要求，即主机必须支持具有多个SEQ序列号的ACK参数的处理，即使它们不支持发送此类参数。
o This document now clarifies that several ECHO_REQUEST_UNSIGNED parameters may be present in an R1 and that several ECHO_RESPONSE parameters may be present in an I2.
o 本文档现在澄清了R1中可能存在多个ECHO_请求_无符号参数，I2中可能存在多个ECHO_响应参数。
o Procedures for responding to version mismatches with an ICMP Parameter Problem have been added.
o 增加了用ICMP参数问题响应版本不匹配的过程。
o The security considerations section (Section 8) has been updated to remove possible attacks no longer considered applicable.
o 安全注意事项部分（第8节）已更新，以删除不再适用的可能攻击。
o The use of the Anonymous bit for making the sender's Host Identity anonymous is now supported in packets other than the R1 and I2.
o 在R1和I2以外的数据包中，现在支持使用匿名位使发送方的主机标识匿名。
o Support for the use of a NULL HIP CIPHER is explicitly limited to debugging and testing HIP and is no longer a mandatory algorithm to support.
o 对空HIP密码使用的支持明确限于调试和测试HIP，不再是必须支持的算法。
The following changes have been made to the parameter types and encodings (Section 5.2).
对参数类型和编码进行了以下更改（第5.2节）。
o Four new parameter types have been added: DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST.
o 添加了四种新的参数类型：DH_GROUP_LIST、HIP_CIPHER、HIT_SUITE_LIST和TRANSPORT_FORMAT_LIST。
o Two parameter types have been renamed: HMAC has been renamed to HIP_MAC, and HMAC2 has been renamed to HIP_MAC_2.
o 已重命名两种参数类型：HMAC已重命名为HIP_MAC，HMAC2已重命名为HIP_MAC_2。
o One parameter type is deprecated: HIP_TRANSFORM. Functionally, it has been replaced by the HIP_CIPHER but with slightly different semantics (hashes have been removed and are now determined by RHASH).
o 不推荐使用一种参数类型：HIP_TRANSFORM。在功能上，它已被HIP_密码取代，但语义略有不同（哈希已被删除，现在由RHASH确定）。
o The TRANSPORT_FORMAT_LIST parameter allows transports to be negotiated with the list instead of by their order in the HIP packet.
o TRANSPORT_FORMAT_LIST参数允许传输与列表进行协商，而不是按照HIP数据包中的顺序进行协商。
o The type code for the R1_COUNTER has been changed from 128 to 129 to reflect that it is now considered a Critical parameter and must be echoed when present in R1.
o R1_计数器的类型代码已从128更改为129，以反映它现在被视为关键参数，并且在R1中出现时必须回显。
o The PUZZLE and SOLUTION parameter lengths are now variable and dependent on the RHASH length.
o 谜题和解决方案参数长度现在是可变的，并且取决于RHASH长度。
o The Diffie-Hellman Group IDs supported have been updated.
o 支持的Diffie Hellman组ID已更新。
o The HOST_ID parameter now requires specification of an Algorithm.
o HOST_ID参数现在需要指定算法。
o The NOTIFICATION parameter supports new Notify Message Type values.
o 通知参数支持新的通知消息类型值。
o The HIP_SIGNATURE algorithm field has been changed from 8 bits to 16 bits to achieve alignment with the HOST_ID parameters.
o HIP_签名算法字段已从8位更改为16位，以实现与HOST_ID参数的对齐。
o The specification clarifies that the SEQ parameter always contains one update ID but that the ACK parameter may acknowledge several update IDs.
o 该规范澄清了SEQ参数始终包含一个更新ID，但是ACK参数可以确认多个更新ID。
o The restriction that only one ECHO_RESPONSE_UNSIGNED parameter must be present in each HIP packet has been removed.
o 取消了每个HIP数据包中只能存在一个ECHO_RESPONSE_UNSIGNED参数的限制。
o The document creates a new type range allocation for parameters that are only covered by a signature if a signature is present and applies it to the newly created DH_GROUP_LIST parameter.
o 文档为只有签名存在时才由签名覆盖的参数创建新的类型范围分配，并将其应用于新创建的DH_GROUP_LIST参数。
o The document clarifies that several NOTIFY parameters may be present in a packet.
o 该文件澄清了一个数据包中可能存在多个NOTIFY参数。
The following changes have been made to the packet contents (Section 5.3).
对数据包内容进行了以下更改（第5.3节）。
o The I1 packet now carries the Initiator's DH_GROUP_LIST.
o I1数据包现在携带启动器的DH_组列表。
o The R1 packet now carries the HIP_CIPHER, HIT_SUITE_LIST, DH_GROUP_LIST, and TRANSPORT_FORMAT_LIST parameters.
o R1数据包现在携带HIP_密码、HIT_套件_列表、DH_组_列表和传输_格式_列表参数。
o The I2 packet now carries the HIP_CIPHER and TRANSPORT_FORMAT_LIST parameters.
o I2数据包现在携带HIP_密码和TRANSPORT_FORMAT_列表参数。
o This document clarifies that UPDATE packets that do not contain either a SEQ or ACK parameter are invalid.
o 本文档说明不包含SEQ或ACK参数的更新数据包无效。
[FIPS.180-4.2012] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.
[FIPS.180-4.2012]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-42012年3月<http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>。
[NIST.800-131A.2011] National Institute of Standards and Technology, "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths", NIST SP 800-131A, January 2011, <http://csrc.nist.gov/ publications/nistpubs/800-131A/sp800-131A.pdf>.
[NIST.800-131A.2011]国家标准与技术研究所，“转换：密码算法和密钥长度使用转换建议”，NIST SP 800-131A，2011年1月<http://csrc.nist.gov/ 出版物/nistpubs/800-131A/sp800-131A.pdf>。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981, <http://www.rfc-editor.org/ info/rfc793>.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月<http://www.rfc-editor.org/ 信息/rfc793>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998, <http://www.rfc-editor.org/info/rfc2404>.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月<http://www.rfc-editor.org/info/rfc2404>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998, <http://www.rfc-editor.org/info/rfc2410>.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月<http://www.rfc-editor.org/info/rfc2410>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999, <http://www.rfc-editor.org/info/rfc2536>.
[RFC2536]Eastlake 3rd，D.，“域名系统（DNS）中的DSA密钥和SIG”，RFC 25361999年3月<http://www.rfc-editor.org/info/rfc2536>.
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001, <http://www.rfc-editor.org/info/rfc3110>.
[RFC3110]Eastlake 3rd，D.，“域名系统（DNS）中的RSA/SHA-1 SIGs和RSA密钥”，RFC 3110，2001年5月<http://www.rfc-editor.org/info/rfc3110>.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003, <http://www.rfc-editor.org/ info/rfc3526>.
[RFC3526]Kivinen，T.和M.Kojo，“因特网密钥交换（IKE）的更模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月<http://www.rfc-editor.org/ 信息/rfc3526>。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003, <http://www.rfc-editor.org/info/rfc3602>.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月<http://www.rfc-editor.org/info/rfc3602>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005, <http://www.rfc-editor.org/ info/rfc3972>.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月<http://www.rfc-editor.org/ 信息/rfc3972>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005, <http://www.rfc-editor.org/ info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月<http://www.rfc-editor.org/ 信息/rfc4034>。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005, <http://www.rfc-editor.org/info/rfc4282>.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月<http://www.rfc-editor.org/info/rfc4282>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月<http://www.rfc-editor.org/info/rfc4443>.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007, <http://www.rfc-editor.org/ info/rfc4754>.
[RFC4754]Fu，D.和J.Solinas，“使用椭圆曲线数字签名算法（ECDSA）的IKE和IKEv2认证”，RFC 4754，2007年1月<http://www.rfc-editor.org/ 信息/rfc4754>。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，2007年5月<http://www.rfc-editor.org/info/rfc4868>.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009, <http://www.rfc-editor.org/info/rfc5702>.
[RFC5702]Jansen，J.“在DNSSEC的DNSKEY和RRSIG资源记录中使用RSA的SHA-2算法”，RFC 57022009年10月<http://www.rfc-editor.org/info/rfc5702>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月<http://www.rfc-editor.org/info/rfc6724>.
[RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", RFC 7343, September 2014, <http://www.rfc-editor.org/info/rfc7343>.
[RFC7343]Laganier，J.和F.Dupont，“覆盖可路由加密哈希标识符版本2（Vv2）的IPv6前缀”，RFC 7343，2014年9月<http://www.rfc-editor.org/info/rfc7343>.
[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, April 2015, <http://www.rfc-editor.org/info/rfc7402>.
[RFC7402]Jokela，P.，Moskowitz，R.，和J.Melen，“将封装安全有效载荷（ESP）传输格式与主机标识协议（HIP）结合使用”，RFC 7402，2015年4月<http://www.rfc-editor.org/info/rfc7402>.
[AUR05] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP Base Exchange Protocol", in Proceedings of the 10th Australasian Conference on Information Security and Privacy, July 2005.
[AUR05]Aura，T.，Nagarajan，A.，和A.Gurtov，“髋关节基底交换协议的分析”，载于第十届澳大拉西亚信息安全和隐私会议记录，2005年7月。
[CRO03] Crosby, S. and D. Wallach, "Denial of Service via Algorithmic Complexity Attacks", in Proceedings of the 12th USENIX Security Symposium, Washington, D.C., August 2003.
[CRO03]Crosby，S.和D.Wallach，“通过算法复杂性攻击的拒绝服务”，第12届USENIX安全研讨会论文集，华盛顿特区，2003年8月。
[DIF76] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory Volume IT-22, Number 6, pages 644-654, November 1976.
[DIF76]Diffie，W.和M.Hellman，“密码学的新方向”，IEEE信息论交易卷IT-22，第6期，第644-654页，1976年11月。
[FIPS.186-4.2013] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[FIPS.186-4.2013]国家标准与技术研究所，“数字签名标准（DSS）”，FIPS PUB 186-42013年7月<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>。
[FIPS.197.2001] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>.
[FIPS.197.2001]国家标准与技术研究所，“高级加密标准（AES）”，FIPS PUB 197，2001年11月<http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>。
[HIP-ARCH] Moskowitz, R., Ed., and M. Komu, "Host Identity Protocol Architecture", Work in Progress, draft-ietf-hip-rfc4423-bis-09, October 2014.
[HIP-ARCH]Moskowitz，R.，Ed.，和M.Komu，“主机身份协议体系结构”，正在进行的工作，草稿-ietf-HIP-rfc4423-bis-092014年10月。
[HIP-DNS-EXT] Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", Work in Progress, draft-ietf-hip-rfc5205-bis-06, January 2015.
[HIP-DNS-EXT]Laganier，J.，“主机身份协议（HIP）域名系统（DNS）扩展”，正在进行的工作，草稿-ietf-HIP-rfc5205-bis-06，2015年1月。
[HIP-HOST-MOB] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", Work in Progress, draft-ietf-hip-rfc5206-bis-08, January 2015.
[HIP-HOST-MOB]Henderson，T.，Ed.，Vogt，C.，和J.Arkko，“主机身份协议下的主机移动性”，正在进行的工作，草案-ietf-HIP-rfc5206-bis-082015年1月。
[HIP-REND-EXT] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", Work in Progress, draft-ietf-hip-rfc5204-bis-05, December 2014.
[HIP-REND-EXT]Laganier，J.和L.Eggert，“主机身份协议（HIP）会合扩展”，正在进行的工作，草案-ietf-HIP-rfc5204-bis-052014年12月。
[KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS protection for UDP-based protocols", in Proceedings of the 10th ACM Conference on Computer and Communications Security, October 2003.
[KAU03]Kaufman，C.，Perlman，R.，和B.Sommerfeld，“基于UDP协议的DoS保护”，第十届ACM计算机和通信安全会议记录，2003年10月。
[KRA03] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols", in Proceedings of CRYPTO 2003, pages 400-425, August 2003.
[KRA03]Krawczyk，H.，“西格玛：认证Diffie-Hellman的‘符号和MAc’方法及其在IKE协议中的应用”，《2003年密码会议录》，第400-425页，2003年8月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981, <http://www.rfc-editor.org/ info/rfc792>.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月<http://www.rfc-editor.org/ 信息/rfc792>。
[RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000, <http://www.rfc-editor.org/info/rfc2785>.
[RFC2785]Zuccherato，R.，“避免针对S/MIME的Diffie-Hellman密钥协商方法的“小子组”攻击的方法”，RFC 27852000年3月<http://www.rfc-editor.org/info/rfc2785>.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000, <http://www.rfc-editor.org/info/rfc2898>.
[RFC2898]Kaliski，B.，“PKCS#5：基于密码的加密规范2.0版”，RFC 28982000年9月<http://www.rfc-editor.org/info/rfc2898>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月<http://www.rfc-editor.org/info/rfc3447>.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004, <http://www.rfc-editor.org/info/rfc3849>.
[RFC3849]Huston，G.，Lord，A.，和P.Smith，“为文档保留IPv6地址前缀”，RFC 3849，2004年7月<http://www.rfc-editor.org/info/rfc3849>.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008, <http://www.rfc-editor.org/info/rfc5201>.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，RFC 52012008年4月<http://www.rfc-editor.org/info/rfc5201>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, September 2008, <http://www.rfc-editor.org/info/rfc5338>.
[RFC5338]Henderson，T.，Nikander，P.，和M.Komu，“在遗留应用程序中使用主机标识协议”，RFC 5338，2008年9月<http://www.rfc-editor.org/info/rfc5338>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 55332009年6月<http://www.rfc-editor.org/info/rfc5533>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010, <http://www.rfc-editor.org/info/rfc5737>.
[RFC5737]Arkko，J.，Cotton，M.和L.Vegoda，“为文档保留的IPv4地址块”，RFC 5737，2010年1月<http://www.rfc-editor.org/info/rfc5737>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, <http://www.rfc-editor.org/info/rfc5869>.
[RFC5869]Krawczyk，H.和P.Eronen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，2010年5月<http://www.rfc-editor.org/info/rfc5869>.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010, <http://www.rfc-editor.org/info/rfc5903>.
[RFC5903]Fu，D.和J.Solinas，“IKE和IKEv2的模素数的椭圆曲线群（ECP群）”，RFC 5903，2010年6月<http://www.rfc-editor.org/info/rfc5903>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011, <http://www.rfc-editor.org/info/rfc6090>.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 60902011年2月<http://www.rfc-editor.org/info/rfc6090>.
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011, <http://www.rfc-editor.org/info/rfc6253>.
[RFC6253]Heer，T.和S.Varjonen，“主机身份协议证书”，RFC 62532011年5月<http://www.rfc-editor.org/info/rfc6253>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, December 2013, <http://www.rfc-editor.org/info/rfc7045>.
[RFC7045]Carpenter，B.和S.Jiang，“IPv6扩展头的传输和处理”，RFC 70452013年12月<http://www.rfc-editor.org/info/rfc7045>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM 21 (2), pp. 120-126, February 1978.
[RSA]Rivest，R.，Shamir，A.，和L.Adleman，“获取数字签名和公钥密码系统的方法”，ACM 21（2）通信，第120-126页，1978年2月。
[SECG] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2 Version 2.0, January 2010, <http://www.secg.org/>.
[SECG]SECG，“建议的椭圆曲线域参数”，第2节2.0版，2010年1月<http://www.secg.org/>.
As mentioned in Section 4.1.1, the Responder may delay state creation and still reject most spoofed I2 packets by using a number of pre-calculated R1 packets and a local selection function. This appendix defines one possible implementation in detail. The purpose of this appendix is to give the implementors an idea of how to implement the mechanism. If the implementation is based on this appendix, it MAY contain some local modification that makes an attacker's task harder.
如第4.1.1节所述，响应者可延迟状态创建，并通过使用大量预先计算的R1数据包和本地选择函数拒绝大多数伪造的I2数据包。本附录详细定义了一种可能的实现方式。本附录的目的是让实施者了解如何实施该机制。如果实现基于此附录，它可能包含一些本地修改，使攻击者的任务更加困难。
The Responder creates a secret value S, that it regenerates periodically. The Responder needs to remember the two latest values of S. Each time the S is regenerated, the R1 generation counter value is incremented by one.
响应程序创建一个秘密值S，并定期重新生成该值。响应程序需要记住S的两个最新值。每次重新生成S时，R1生成计数器值将增加一。
The Responder generates a pre-signed R1 packet. The signature for pre-generated R1s must be recalculated when the Diffie-Hellman key is recomputed or when the R1_COUNTER value changes due to S value regeneration.
响应者生成预签名R1数据包。当重新计算Diffie Hellman密钥或当R1_计数器值因S值重新生成而更改时，必须重新计算预生成R1s的签名。
When the Initiator sends the I1 packet for initializing a connection, the Responder receives the HIT and IP address from the packet, and generates an #I value for the puzzle. The #I value is set to the pre-signed R1 packet.
当发起方发送用于初始化连接的I1数据包时，响应方从数据包接收HIT和IP地址，并为谜题生成#I值。#I值设置为预签名R1数据包。
#I value calculation:
#I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n)
where n = RHASH_len
#I value calculation:
#I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n)
where n = RHASH_len
The RHASH algorithm is the same as is used to generate the Responder's HIT value.
RHASH算法与用于生成响应者命中值的算法相同。
From an incoming I2 packet, the Responder receives the required information to validate the puzzle: HITs, IP addresses, and the information of the used S value from the R1_COUNTER. Using these values, the Responder can regenerate the #I, and verify it against the #I received in the I2 packet. If the #I values match, it can verify the solution using #I, #J, and difficulty #K. If the #I values do not match, the I2 is dropped.
从传入的I2数据包中，响应者接收验证谜题所需的信息：点击数、IP地址以及来自R1_计数器的已用S值信息。使用这些值，响应者可以重新生成#I，并根据I2数据包中接收到的#I对其进行验证。如果#I值匹配，它可以使用#I、#J和难度#K验证解决方案。如果#I值不匹配，则删除I2。
puzzle_check:
V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K )
if V != 0, drop the packet
puzzle_check:
V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K )
if V != 0, drop the packet
If the puzzle solution is correct, the #I and #J values are stored for later use. They are used as input material when keying material is generated.
如果谜题解决方案正确，则存储#I和#J值以供以后使用。生成关键帧材质时，它们将用作输入材质。
Keeping state about failed puzzle solutions depends on the implementation. Although it is possible for the Responder not to keep any state information, it still may do so to protect itself against certain attacks (see Section 4.1.1).
保留失败谜题解决方案的状态取决于实现。尽管响应者可以不保留任何状态信息，但仍然可以这样做以保护自己免受某些攻击（见第4.1.1节）。
The following pseudo-code illustrates the process to generate a public key encoding from an HI for both RSA and DSA.
以下伪代码说明了从HI为RSA和DSA生成公钥编码的过程。
The symbol ":=" denotes assignment; the symbol "+=" denotes appending. The pseudo-function "encode_in_network_byte_order" takes two parameters, an integer (bignum) and a length in bytes, and returns the integer encoded into a byte string of the given length.
符号“：=”表示分配；符号“+=”表示追加。伪函数“encode_in_network_byte_order”接受两个参数，一个整数（bignum）和一个字节长度，并返回编码为给定长度字节字符串的整数。
switch ( HI.algorithm ) {
开关（HI.algorithm）{
case RSA:
buffer := encode_in_network_byte_order ( HI.RSA.e_len,
( HI.RSA.e_len > 255 ) ? 3 : 1 )
buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len )
buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len )
case RSA:
buffer := encode_in_network_byte_order ( HI.RSA.e_len,
( HI.RSA.e_len > 255 ) ? 3 : 1 )
buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len )
buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len )
break;
打破
case DSA:
buffer := encode_in_network_byte_order ( HI.DSA.T , 1 )
buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 )
buffer += encode_in_network_byte_order ( HI.DSA.P , 64 +
8 * HI.DSA.T )
buffer += encode_in_network_byte_order ( HI.DSA.G , 64 +
8 * HI.DSA.T )
buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 +
8 * HI.DSA.T )
case DSA:
buffer := encode_in_network_byte_order ( HI.DSA.T , 1 )
buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 )
buffer += encode_in_network_byte_order ( HI.DSA.P , 64 +
8 * HI.DSA.T )
buffer += encode_in_network_byte_order ( HI.DSA.G , 64 +
8 * HI.DSA.T )
buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 +
8 * HI.DSA.T )
break;
打破
}
}
The HIP checksum for HIP packets is specified in Section 5.1.1. Checksums for TCP and UDP packets running over HIP-enabled security associations are specified in Section 4.5.1. The examples below use [RFC3849] and [RFC5737] addresses, and HITs with the prefix of 2001:20 followed by zeros, followed by a decimal 1 or 2, respectively.
第5.1.1节规定了HIP数据包的HIP校验和。第4.5.1节规定了通过支持HIP的安全关联运行的TCP和UDP数据包的校验和。下面的示例使用[RFC3849]和[RFC5737]地址，并分别使用前缀为2001:20、后跟零和十进制1或2的HITs。
The following example is defined only for testing the checksum calculation.
以下示例仅用于测试校验和计算。
Source Address: 2001:db8::1
Destination Address: 2001:db8::2
Upper-Layer Packet Length: 48 0x30
Next Header: 139 0x8b
Payload Protocol: 59 0x3b
Header Length: 5 0x5
Packet Type: 1 0x1
Version: 2 0x2
Reserved: 1 0x1
Control: 0 0x0
Checksum: 6750 0x1a5e
Sender's HIT: 2001:20::1
Receiver's HIT: 2001:20::2
DH_GROUP_LIST type: 511 0x1ff
DH_GROUP_LIST length: 3 0x3
DH_GROUP_LIST Group IDs: 3,4,8
Source Address: 2001:db8::1
Destination Address: 2001:db8::2
Upper-Layer Packet Length: 48 0x30
Next Header: 139 0x8b
Payload Protocol: 59 0x3b
Header Length: 5 0x5
Packet Type: 1 0x1
Version: 2 0x2
Reserved: 1 0x1
Control: 0 0x0
Checksum: 6750 0x1a5e
Sender's HIT: 2001:20::1
Receiver's HIT: 2001:20::2
DH_GROUP_LIST type: 511 0x1ff
DH_GROUP_LIST length: 3 0x3
DH_GROUP_LIST Group IDs: 3,4,8
The IPv4 checksum value for the example I1 packet is shown below.
示例I1数据包的IPv4校验和值如下所示。
Source Address: 192.0.2.1
Destination Address: 192.0.2.2
Upper-Layer Packet Length: 48 0x30
Next Header: 139 0x8b
Payload Protocol: 59 0x3b
Header Length: 5 0x5
Packet Type: 1 0x1
Version: 2 0x2
Reserved: 1 0x1
Control: 0 0x0
Checksum: 61902 0xf1ce
Sender's HIT: 2001:20::1
Receiver's HIT: 2001:20::2
DH_GROUP_LIST type: 511 0x1ff
DH_GROUP_LIST length: 3 0x3
DH_GROUP_LIST Group IDs: 3,4,8
Source Address: 192.0.2.1
Destination Address: 192.0.2.2
Upper-Layer Packet Length: 48 0x30
Next Header: 139 0x8b
Payload Protocol: 59 0x3b
Header Length: 5 0x5
Packet Type: 1 0x1
Version: 2 0x2
Reserved: 1 0x1
Control: 0 0x0
Checksum: 61902 0xf1ce
Sender's HIT: 2001:20::1
Receiver's HIT: 2001:20::2
DH_GROUP_LIST type: 511 0x1ff
DH_GROUP_LIST length: 3 0x3
DH_GROUP_LIST Group IDs: 3,4,8
Regardless of whether IPv6 or IPv4 is used, the TCP and UDP sockets use the IPv6 pseudo header format [RFC2460], with the HITs used in place of the IPv6 addresses.
无论使用的是IPv6还是IPv4，TCP和UDP套接字都使用IPv6伪头格式[RFC2460]，并使用HITs代替IPv6地址。
Sender's HIT: 2001:20::1
Receiver's HIT: 2001:20::2
Upper-Layer Packet Length: 20 0x14
Next Header: 6 0x06
Source port: 65500 0xffdc
Destination port: 22 0x0016
Sequence number: 1 0x00000001
Acknowledgment number: 0 0x00000000
Data offset: 5 0x5
Flags: SYN 0x02
Window size: 65535 0xffff
Checksum: 28586 0x6faa
Urgent pointer: 0 0x0000
Sender's HIT: 2001:20::1
Receiver's HIT: 2001:20::2
Upper-Layer Packet Length: 20 0x14
Next Header: 6 0x06
Source port: 65500 0xffdc
Destination port: 22 0x0016
Sequence number: 1 0x00000001
Acknowledgment number: 0 0x00000000
Data offset: 5 0x5
Flags: SYN 0x02
Window size: 65535 0xffff
Checksum: 28586 0x6faa
Urgent pointer: 0 0x0000
The ECDH and ECDSA 160-bit group SECP160R1 is rated at 80 bits symmetric strength. This was once considered appropriate for one year of security. Today, these groups should be used only when the host is not powerful enough (e.g., some embedded devices) and when security requirements are low (e.g., long-term confidentiality is not required).
ECDH和ECDSA 160位组SECP160R1的额定对称强度为80位。这一度被认为适合一年的安全。如今，只有在主机功能不够强大（例如，某些嵌入式设备）和安全要求较低（例如，不需要长期保密）时，才应使用这些组。
The HIT as an ORCHID [RFC7343] consists of three parts: A 28-bit prefix, a 4-bit encoding of the ORCHID generation algorithm (OGA), and a hash that includes the Host Identity and a context ID. The OGA is an index pointing to the specific algorithm by which the public key and the 96-bit hashed encoding are generated. The OGA is protocol specific and is to be interpreted as defined below for all protocols that use the same context ID as HIP. HIP groups sets of valid combinations of signature and hash algorithms into HIT Suites. These HIT Suites are addressed by an index, which is transmitted in the OGA ID field of the ORCHID.
HIT as A Ratch[RFC7343]由三部分组成：28位前缀、兰花生成算法（OGA）的4位编码以及包含主机标识和上下文ID的哈希。OGA是指向生成公钥和96位哈希编码的特定算法的索引。OGA是协议特定的，对于使用与HIP相同的上下文ID的所有协议，其解释如下所述。HIP将签名和散列算法的有效组合集分组到HIT套件中。这些HIT套件由索引寻址，该索引在兰花的OGA ID字段中传输。
The set of used HIT Suites will be extended to counter the progress in computation capabilities and vulnerabilities in the employed algorithms. The intended use of the HIT Suites is to introduce a new HIT Suite and phase out an old one before it becomes insecure. Since the 4-bit OGA ID field only permits 15 HIT Suites to be used at the same time (the HIT Suite with ID 0 is reserved), phased-out HIT
使用的HIT套件集将被扩展，以应对所用算法在计算能力和漏洞方面的进展。HIT套件的预期用途是引入一个新的HIT套件，并在旧套件变得不安全之前逐步淘汰它。由于4位OGA ID字段仅允许同时使用15个HIT套件（保留ID为0的HIT套件），因此逐步取消HIT
Suites must be reused at some point. In such a case, there will be a rollover of the HIT Suite ID and the next newly introduced HIT Suite will start with a lower HIT Suite index than the previously introduced one. The rollover effectively deprecates the reused HIT Suite. For a smooth transition, the HIT Suite should be deprecated a considerable time before the HIT Suite index is reused.
套件必须在某个时候重复使用。在这种情况下，将出现HIT套件ID的滚动，下一个新引入的HIT套件将以比先前引入的更低的HIT套件索引开始。滚动有效地否决了重用的HIT套件。为了平稳过渡，在重用HIT套件索引之前，应该在相当长的一段时间内弃用HIT套件。
Since the number of HIT Suites is tightly limited to 16, the HIT Suites must be assigned carefully. Hence, sets of suitable algorithms are grouped in a HIT Suite.
由于HIT套件的数量严格限制在16个，因此必须仔细分配HIT套件。因此，合适的算法集被分组在HIT套件中。
The HIT Suite of the Responder's HIT determines the RHASH and the hash function to be used for the HMAC in HIP packets as well as the signature algorithm family used for generating the HI. The list of HIT Suites is defined in Table 10.
响应者HIT的HIT套件确定HIP数据包中用于HMAC的RHASH和哈希函数，以及用于生成HI的签名算法系列。表10中定义了HIT套件列表。
Acknowledgments
致谢
The drive to create HIP came to being after attending the MALLOC meeting at the 43rd IETF meeting. Baiju Patel and Hilarie Orman really gave the original author, Bob Moskowitz, the assist to get HIP beyond 5 paragraphs of ideas. It has matured considerably since the early versions thanks to extensive input from IETFers. Most importantly, its design goals are articulated and are different from other efforts in this direction. Particular mention goes to the members of the NameSpace Research Group of the IRTF. Noel Chiappa provided valuable input at early stages of discussions about identifier handling and Keith Moore the impetus to provide resolvability. Steve Deering provided encouragement to keep working, as a solid proposal can act as a proof of ideas for a research group.
在参加第43届IETF会议的MALLOC会议后，产生了创建HIP的动力。Baiju Patel和Hilarie Orman为原作者Bob Moskowitz提供了帮助，帮助他超越5段的想法。由于IETFers的广泛投入，自早期版本以来，它已经相当成熟。最重要的是，它的设计目标是明确的，不同于这方面的其他努力。特别要提到的是IRTF名称空间研究小组的成员。Noel Chiappa在关于标识符处理的早期讨论中提供了有价值的输入，Keith Moore为提供可解析性提供了动力。史蒂夫·迪林鼓励人们继续工作，因为一份可靠的提案可以证明研究小组的想法。
Many others contributed; extensive security tips were provided by Steve Bellovin. Rob Austein kept the DNS parts on track. Paul Kocher taught Bob Moskowitz how to make the puzzle exchange expensive for the Initiator to respond, but easy for the Responder to validate. Bill Sommerfeld supplied the Birthday concept, which later evolved into the R1 generation counter, to simplify reboot management. Erik Nordmark supplied the CLOSE-mechanism for closing connections. Rodney Thayer and Hugh Daniels provided extensive feedback. In the early times of this document, John Gilmore kept Bob Moskowitz challenged to provide something of value.
许多其他人作出了贡献；Steve Bellovin提供了大量的安全提示。Rob Austein保持DNS部分正常运行。Paul Kocher教Bob Moskowitz如何使谜题交换对发起者来说代价高昂，但对响应者来说很容易验证。Bill Sommerfeld提供了生日概念，该概念后来演变为R1代计数器，以简化重启管理。Erik Nordmark提供了关闭连接的关闭机制。Rodney Thayer和Hugh Daniels提供了广泛的反馈。在本文件的早期，约翰·吉尔摩（John Gilmore）一直要求鲍勃·莫斯科维茨（Bob Moskowitz）提供有价值的东西。
During the later stages of this document, when the editing baton was transferred to Pekka Nikander, the input from the early implementors was invaluable. Without having actual implementations, this document would not be on the level it is now.
在本文档的后期阶段，当编辑接力棒移交给Pekka Nikander时，早期实现者的输入是非常宝贵的。如果没有实际的实现，本文档就不会达到现在的水平。
In the usual IETF fashion, a large number of people have contributed to the actual text or ideas. The list of these people includes Jeff Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Xin Gu, Rene Hummen, Miika Komu, Mika Kousa, Julien Laganier, Andrew McGregor, Jan Melen, Henrik Petander, Michael Richardson, Tim Shepard, Jorma Wall, and Jukka Ylitalo. Our apologies to anyone whose name is missing.
按照通常的IETF方式，大量的人对实际的文本或想法做出了贡献。这些人包括杰夫·阿伦霍尔兹、弗朗西斯·杜邦、德里克·福库斯、乔治·格罗斯、辛古、雷内·胡门、米卡·科姆、米卡·库萨、朱利安·拉詹尼尔、安德鲁·麦格雷戈、扬·梅伦、亨里克·佩坦德、迈克尔·理查森、蒂姆·谢泼德、乔玛·沃尔和朱卡·叶利塔洛。我们向任何姓名丢失的人道歉。
Once the HIP Working Group was founded in early 2004, a number of changes were introduced through the working group process. Most notably, the original document was split in two, one containing the base exchange and the other one defining how to use ESP. Some modifications to the protocol proposed by Aura, et al. [AUR05] were added at a later stage.
HIP工作组于2004年初成立后，通过工作组流程引入了一些变化。最值得注意的是，原始文档分为两部分，一部分包含基本交换，另一部分定义如何使用ESP。Aura等人[AUR05]提出的协议的一些修改在后期添加。
Authors' Addresses
作者地址
Robert Moskowitz (editor) HTT Consulting Oak Park, MI United States
罗伯特·莫斯科维茨（编辑）美国密苏里州奥克公园HTT咨询公司
EMail: rgm@labs.htt-consult.com
EMail: rgm@labs.htt-consult.com
Tobias Heer Hirschmann Automation and Control Stuttgarter Strasse 45-51 Neckartenzlingen 72654 Germany
Tobias Heer Hirschmann自动化与控制Stuttgarter Strasse 45-51 Neckartenzlingen 72654德国
EMail: tobias.heer@belden.com
EMail: tobias.heer@belden.com
Petri Jokela Ericsson Research NomadicLab Jorvas FIN-02420 Finland
Petri Jokela Ericsson研究实验室Jorvas FIN-02420芬兰
Phone: +358 9 299 1
EMail: petri.jokela@nomadiclab.com
Phone: +358 9 299 1
EMail: petri.jokela@nomadiclab.com
Thomas R. Henderson University of Washington Campus Box 352500 Seattle, WA United States
托马斯·R·亨德森华盛顿大学华盛顿大学校园352500西雅图
EMail: tomhend@u.washington.edu
EMail: tomhend@u.washington.edu