Network Working Group R. Moskowitz
Request for Comments: 5201 ICSAlabs
Category: Experimental P. Nikander
P. Jokela, Ed.
Ericsson Research NomadicLab
T. Henderson
The Boeing Company
April 2008
Network Working Group R. Moskowitz
Request for Comments: 5201 ICSAlabs
Category: Experimental P. Nikander
P. Jokela, Ed.
Ericsson Research NomadicLab
T. Henderson
The Boeing Company
April 2008
Host Identity Protocol
主机身份协议
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
IESG Note
IESG注释
The following issues describe IESG concerns about this document. The IESG expects that these issues will be addressed when future versions of HIP are designed.
以下问题描述了IESG对本文件的关注。IESG期望在设计未来版本的HIP时解决这些问题。
This document doesn't currently define support for parameterized (randomized) hashing in signatures, support for negotiation of a key derivation function, or support for combined encryption modes.
本文档目前未定义对签名中参数化（随机）哈希的支持、对密钥派生函数协商的支持或对组合加密模式的支持。
HIP defines the usage of RSA in signing and encrypting data. Current recommendations propose usage of, for example, RSA OAEP/PSS for these operations in new protocols. Changing the algorithms to more current best practice should be considered.
HIP定义了RSA在数据签名和加密中的用法。当前的建议建议在新协议中使用RSA OAEP/PSS等来执行这些操作。应考虑将算法更改为更当前的最佳实践。
The current specification is currently using HMAC for message authentication. This is considered to be acceptable for an experimental RFC, but future versions must define a more generic method for message authentication, including the ability for other MAC algorithms to be used.
当前规范正在使用HMAC进行消息身份验证。这被认为是可接受的实验RFC，但未来版本必须定义更通用的消息身份验证方法，包括使用其他MAC算法的能力。
SHA-1 is no longer a preferred hashing algorithm. This is noted also by the authors, and it is understood that future, non-experimental versions must consider more secure hashing algorithms.
SHA-1不再是首选的哈希算法。这也是作者所注意到的，并且可以理解，未来的非实验版本必须考虑更安全的散列算法。
HIP requires that an incoming packet's IP address be ignored. In simple cases this can be done, but when there are security policies based on incoming interface or IP address rules, the situation
HIP要求忽略传入数据包的IP地址。在简单的情况下，这是可以做到的，但当存在基于传入接口或IP地址规则的安全策略时，情况会有所不同
changes. The handling of data needs to be enhanced to cover different types of network and security configurations, as well as to meet local security policies.
变化。需要加强数据处理，以覆盖不同类型的网络和安全配置，并满足本地安全策略的要求。
Abstract
摘要
This memo 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 Sigma-compliant 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 Encapsulated 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基于符合Sigma的Diffie-Hellman密钥交换，使用来自新主机标识命名空间的公钥标识符进行相互对等身份验证。该协议旨在抵抗拒绝服务（DoS）和中间人（MitM）攻击。当与其他合适的安全协议（如封装的安全有效负载（ESP））一起使用时，它为上层协议（如TCP和UDP）提供完整性保护和可选加密。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 5
1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 6
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 7
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
3. Host Identifier (HI) and Its Representations . . . . . . . . 8
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 9
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 9
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 10
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 12
4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 13
4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 14
4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 14
4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 15
4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 16
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 18
4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 18
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 19
4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 20
4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 21
4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 28
4.5. User Data Considerations . . . . . . . . . . . . . . . . 30
4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. A New Namespace and Identifiers . . . . . . . . . . . . . 5
1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 6
1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 7
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
3. Host Identifier (HI) and Its Representations . . . . . . . . 8
3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 9
3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 9
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Creating a HIP Association . . . . . . . . . . . . . . . 10
4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 12
4.1.2. Puzzle Exchange . . . . . . . . . . . . . . . . . . . 13
4.1.3. Authenticated Diffie-Hellman Protocol . . . . . . . . 14
4.1.4. HIP Replay Protection . . . . . . . . . . . . . . . . 14
4.1.5. Refusing a HIP Exchange . . . . . . . . . . . . . . . 15
4.1.6. HIP Opportunistic Mode . . . . . . . . . . . . . . . 16
4.2. Updating a HIP Association . . . . . . . . . . . . . . . 18
4.3. Error Processing . . . . . . . . . . . . . . . . . . . . 18
4.4. HIP State Machine . . . . . . . . . . . . . . . . . . . . 19
4.4.1. HIP States . . . . . . . . . . . . . . . . . . . . . 20
4.4.2. HIP State Processes . . . . . . . . . . . . . . . . . 21
4.4.3. Simplified HIP State Diagram . . . . . . . . . . . . 28
4.5. User Data Considerations . . . . . . . . . . . . . . . . 30
4.5.1. TCP and UDP Pseudo-Header Computation for User Data . 30
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 30
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 30
4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 30
4.6. Certificate Distribution . . . . . . . . . . . . . . . . 31
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 31
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 33
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 33
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 33
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 34
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 37
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 38
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 39
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 41
5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 42
5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 43
5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 46
5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 47
5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 49
5.2.16. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 50
5.2.17. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 54
5.2.18. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 54
5.2.19. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 55
5.2.20. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 56
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 58
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 58
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 61
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 62
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 62
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 63
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 64
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 64
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 65
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 65
5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 65
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 65
5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 66
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 66
6.1. Processing Outgoing Application Data . . . . . . . . . . 66
6.2. Processing Incoming Application Data . . . . . . . . . . 67
4.5.2. Sending Data on HIP Packets . . . . . . . . . . . . . 30
4.5.3. Transport Formats . . . . . . . . . . . . . . . . . . 30
4.5.4. Reboot and SA Timeout Restart of HIP . . . . . . . . 30
4.6. Certificate Distribution . . . . . . . . . . . . . . . . 31
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 31
5.1.1. Checksum . . . . . . . . . . . . . . . . . . . . . . 33
5.1.2. HIP Controls . . . . . . . . . . . . . . . . . . . . 33
5.1.3. HIP Fragmentation Support . . . . . . . . . . . . . . 33
5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 34
5.2.1. TLV Format . . . . . . . . . . . . . . . . . . . . . 37
5.2.2. Defining New Parameters . . . . . . . . . . . . . . . 38
5.2.3. R1_COUNTER . . . . . . . . . . . . . . . . . . . . . 39
5.2.4. PUZZLE . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.5. SOLUTION . . . . . . . . . . . . . . . . . . . . . . 41
5.2.6. DIFFIE_HELLMAN . . . . . . . . . . . . . . . . . . . 42
5.2.7. HIP_TRANSFORM . . . . . . . . . . . . . . . . . . . . 43
5.2.8. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.9. HMAC . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.10. HMAC_2 . . . . . . . . . . . . . . . . . . . . . . . 46
5.2.11. HIP_SIGNATURE . . . . . . . . . . . . . . . . . . . . 46
5.2.12. HIP_SIGNATURE_2 . . . . . . . . . . . . . . . . . . . 47
5.2.13. SEQ . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.14. ACK . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.15. ENCRYPTED . . . . . . . . . . . . . . . . . . . . . . 49
5.2.16. NOTIFICATION . . . . . . . . . . . . . . . . . . . . 50
5.2.17. ECHO_REQUEST_SIGNED . . . . . . . . . . . . . . . . . 54
5.2.18. ECHO_REQUEST_UNSIGNED . . . . . . . . . . . . . . . . 54
5.2.19. ECHO_RESPONSE_SIGNED . . . . . . . . . . . . . . . . 55
5.2.20. ECHO_RESPONSE_UNSIGNED . . . . . . . . . . . . . . . 56
5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 58
5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 58
5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 61
5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 62
5.3.5. UPDATE - the HIP Update Packet . . . . . . . . . . . 62
5.3.6. NOTIFY - the HIP Notify Packet . . . . . . . . . . . 63
5.3.7. CLOSE - the HIP Association Closing Packet . . . . . 64
5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet . . 64
5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 65
5.4.1. Invalid Version . . . . . . . . . . . . . . . . . . . 65
5.4.2. Other Problems with the HIP Header and Packet
Structure . . . . . . . . . . . . . . . . . . . . . . 65
5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 65
5.4.4. Non-Existing HIP Association . . . . . . . . . . . . 66
6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 66
6.1. Processing Outgoing Application Data . . . . . . . . . . 66
6.2. Processing Incoming Application Data . . . . . . . . . . 67
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 68
6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 70
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 70
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 72
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 74
6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 75
6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 76
6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 77
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 77
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 78
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 79
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 79
6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 81
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 81
6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 84
6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 84
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 84
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 85
6.12.1. Handling a SEQ Parameter in a Received UPDATE
Message . . . . . . . . . . . . . . . . . . . . . . . 86
6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 87
6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 87
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 88
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 88
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 88
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 89
8. Security Considerations . . . . . . . . . . . . . . . . . . . 89
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 93
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95
11.1. Normative References . . . . . . . . . . . . . . . . . . 95
11.2. Informative References . . . . . . . . . . . . . . . . . 96
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 98
Appendix B. Generating a Public Key Encoding from an HI . . . . 99
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 100
C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 100
C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 100
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 101
Appendix D. 384-Bit Group . . . . . . . . . . . . . . . . . . . 101
Appendix E. OAKLEY Well-Known Group 1 . . . . . . . . . . . . . 102
6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 68
6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 70
6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 70
6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 72
6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 74
6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 75
6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 76
6.6.2. Processing Incoming ICMP Protocol Unreachable
Messages . . . . . . . . . . . . . . . . . . . . . . 77
6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 77
6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 78
6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 79
6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 79
6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 81
6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 81
6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 84
6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 84
6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 84
6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 85
6.12.1. Handling a SEQ Parameter in a Received UPDATE
Message . . . . . . . . . . . . . . . . . . . . . . . 86
6.12.2. Handling an ACK Parameter in a Received UPDATE
Packet . . . . . . . . . . . . . . . . . . . . . . . 87
6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 87
6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 88
6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 88
6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 88
7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 89
8. Security Considerations . . . . . . . . . . . . . . . . . . . 89
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 93
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95
11.1. Normative References . . . . . . . . . . . . . . . . . . 95
11.2. Informative References . . . . . . . . . . . . . . . . . 96
Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 98
Appendix B. Generating a Public Key Encoding from an HI . . . . 99
Appendix C. Example Checksums for HIP Packets . . . . . . . . . 100
C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 100
C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 100
C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 101
Appendix D. 384-Bit Group . . . . . . . . . . . . . . . . . . . 101
Appendix E. OAKLEY Well-Known Group 1 . . . . . . . . . . . . . 102
This memo 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 [RFC4423]. 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体系结构描述[RFC4423]中提供了协议和基础体系结构思想的高级描述。简单地说，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 HIP association, prior to communications. It also defines a packet format and procedures for updating an active HIP association. Other elements of the HIP architecture are specified in other documents, such as.
此备忘录指定主机之间用于在通信之前建立IP层通信上下文（称为HIP关联）的基本HIP协议（“基本交换”）。它还定义了数据包格式和更新活动髋部关联的过程。HIP体系结构的其他元素在其他文档中指定，例如。
o "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)" [RFC5202]: how to use the Encapsulating Security Payload (ESP) for integrity protection and optional encryption
o “将封装安全有效负载（ESP）传输格式与主机标识协议（HIP）一起使用”[RFC5202]：如何使用封装安全有效负载（ESP）进行完整性保护和可选加密
o "End-Host Mobility and Multihoming with the Host Identity Protocol" [RFC5206]: how to support mobility and multihoming in HIP
o “使用主机标识协议的终端主机移动性和多宿位”[RFC5206]：如何支持HIP中的移动性和多宿位
o "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions" [RFC5205]: how to extend DNS to contain Host Identity information
o “主机标识协议（HIP）域名系统（DNS）扩展”[RFC5205]：如何扩展DNS以包含主机标识信息
o "Host Identity Protocol (HIP) Rendezvous Extension" [RFC5204]: using a rendezvous mechanism to contact mobile HIP hosts
o “主机标识协议（HIP）集合扩展”[RFC5204]：使用集合机制联系移动HIP主机
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 [RFC4423].
主机标识协议引入了一个新的名称空间，即主机标识名称空间。HIP体系结构描述[RFC4423]中解释了这个新名称空间的一些分支。
There are two main representations of the Host Identity, the full Host Identifier (HI) and the Host Identity Tag (HIT). The HI is a public key and directly represents the Identity. Since there are different public key algorithms that can be used with different key
主机标识有两种主要表示形式：完整主机标识（HI）和主机标识标记（HIT）。HI是公钥，直接表示身份。因为有不同的公钥算法可以用于不同的密钥
lengths, the HI is not good for use as a packet identifier, or as an index into the various operational tables needed to support HIP. Consequently, a hash of the HI, the Host Identity Tag (HIT), becomes the operational representation. It is 128 bits long and is used in the HIP payloads 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不能用作数据包标识符，也不能用作支持HIP所需的各种操作表的索引。因此，HI的散列（主机标识标签（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 four-packet design helps to make HIP DoS resilient. The protocol exchanges Diffie-Hellman keys in the 2nd and 3rd packets, and authenticates the parties in the 3rd and 4th packets. Additionally, the Responder starts a 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]四包交换。第一方称为发起方，第二方称为响应方。四包设计有助于使HIP DoS具有弹性。该协议交换第2和第3个数据包中的Diffie-Hellman密钥，并对第3和第4个数据包中的各方进行身份验证。此外，响应者在第二个数据包中启动谜题交换，在响应者存储来自交换的任何状态之前，启动器在第三个数据包中完成谜题交换。
The exchange can use the Diffie-Hellman output to encrypt the Host Identity of the Initiator in the 3rd packet (although Aura, et al., [AUR03] notes 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 verify their identities.
交换可以使用Diffie-Hellman输出来加密第三个数据包中启动器的主机标识（尽管Aura等人[AUR03]注意到这种操作可能会干扰数据包检查中间盒），或者主机标识可以改为未加密发送。响应程序的主机标识不受保护。然而，应该注意的是，发起方和响应方的点击都是在包中以明文的形式传输的，从而允许事先知道各方的窃听者验证他们的身份。
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 are to be defined later as more implementation experience is gained.
数据包在第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 Encapsulated Security Payload (ESP) [RFC5202] 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) [RFC4306] that allows IKE to support complex gateway policies. Thus, HIP is not a replacement for IKE.
最后，HIP被设计为端到端身份验证和密钥建立协议，与封装的安全有效负载（ESP）[RFC5202]和其他端到端安全协议一起使用。基本协议没有涵盖Internet密钥交换（IKE）[RFC4306]中的所有细粒度策略控制，该协议允许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 detail 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 (SHA-1(), K) denotes the lowest order K bits of the SHA-1 result.
Ltrunc（SHA-1（），K）表示SHA-1结果的最低阶K位。
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 association.
未使用关联生存期（UAL）：特定于实现的时间，在此时间间隔内，如果没有发送或接收数据包，主机可能会开始中断活动关联。
Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is expected to spend in the network.
最大段生存期（MSL）：TCP段预计在网络中花费的最大时间。
Exchange Complete (EC): Time that the host spends at the R2-SENT before it moves to 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_重试次数的最大值。
HIT Hash Algorithm: Hash algorithm used to generate a Host Identity Tag (HIT) from the Host Identity public key. Currently SHA-1 [FIPS95] is used.
HIT哈希算法：用于从主机标识公钥生成主机标识标记（HIT）的哈希算法。目前使用SHA-1[FIPS95]。
Responder's HIT Hash Algorithm (RHASH): Hash algorithm used for various hash calculations in this document. The algorithm is the same as is used to generate the Responder's HIT. RHASH is defined by the Orchid Context ID. For HIP, the present RHASH algorithm is defined in Section 3.2. A future version of HIP may define a new RHASH algorithm by defining a new Context ID.
响应者的命中哈希算法（RHASH）：本文档中用于各种哈希计算的哈希算法。该算法与用于生成响应者命中的算法相同。RHASH由兰花上下文ID定义。对于HIP，目前的RHASH算法在第3.2节中定义。HIP的未来版本可能通过定义新的上下文ID来定义新的RHASH算法。
Opportunistic mode: HIP base exchange where the Responder's HIT is not known a priori to the Initiator.
机会主义模式：髋部基底交换，其中响应者的命中事先不为发起者所知。
In this section, the properties of the Host Identifier and Host Identifier 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 Identifier (HI). Correspondingly, the host itself is defined as the entity that holds the private key from the key pair. See the HIP architecture specification [RFC4423] for more details about the difference between an identity and the corresponding identifier.
在本节中，将讨论主机标识符和主机标识符标记的属性，并定义它们的确切格式。在HIP中，非对称密钥对的公钥用作主机标识符（HI）。相应地，主机本身被定义为持有来自密钥对的私钥的实体。请参阅HIP体系结构规范[RFC4423]，了解有关标识和相应标识符之间差异的更多详细信息。
HIP implementations MUST support the Rivest Shamir Adelman (RSA/SHA1) [RFC3110] public key algorithm, and SHOULD support the Digital Signature Algorithm (DSA) [RFC2536] algorithm; other algorithms MAY be supported.
HIP实现必须支持Rivest-Shamir-Adelman（RSA/SHA1）[RFC3110]公钥算法，并应支持数字签名算法（DSA）[RFC2536]算法；可能支持其他算法。
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 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 HIT collision between two hosts is very low.
HI的哈希编码，即主机标识标记（HIT），在协议中用于表示主机标识。HIT长度为128位，具有以下三个密钥属性：i）它与IPv6地址长度相同，可用于API和协议中的地址大小字段；ii）它是自认证的（即，给定HIT，在计算上很难找到与HIT匹配的主机标识密钥），以及iii）两台主机之间发生碰撞的概率非常低。
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
在用户数据包的报头中携带HIs和HIT会增加数据包的开销。因此，不期望在每个分组中携带它们，而是使用其他方法将数据分组映射到相应的hi。在某些情况下，这使得在用户数据中使用HIP而不需要任何额外的头成为可能
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.
小包。例如，如果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 Host Identity public key in protocols. Firstly, its fixed length makes for easier protocol coding and also better manages the packet size cost of this technology. Secondly, it presents a consistent format to the protocol whatever underlying identity technology is used.
主机标识标记是一个128位的值——主机标识符的哈希编码。与协议中的实际主机标识公钥相比，使用哈希编码有两个优点。首先，它的固定长度使得协议编码更容易，并且更好地管理了该技术的数据包大小成本。其次，它为协议提供了一种一致的格式，无论使用何种底层身份技术。
RFC 4843 [RFC4843] specifies 128-bit hash-based identifiers, called Overlay Routable Cryptographic Hash Identifiers (ORCHIDs). Their prefix, allocated from the IPv6 address block, is defined in [RFC4843]. The Host Identity Tag is a type of ORCHID, based on a SHA-1 hash of the Host Identity, as defined in Section 2 of [RFC4843].
RFC 4843[RFC4843]指定基于128位哈希的标识符，称为覆盖可路由加密哈希标识符（RAYTS）。从IPv6地址块分配的前缀在[RFC4843]中定义。根据[RFC4843]第2节中的定义，主机标识标签是一种兰花，基于主机标识的SHA-1散列。
The HIT MUST be generated according to the ORCHID generation method described in [RFC4843] 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.8) present in a HIP payload packet. The hash algorithm SHA-1 has to be used when generating HITs with this context ID. If a new ORCHID hash algorithm is needed in the future for HIT generation, a new version of HIP has to be specified with a new ORCHID context ID associated with the new hash algorithm.
必须使用上下文ID值0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA（此标记值由本规范的编辑器随机生成）和对HIP有效负载数据包中的主机标识字段（见第5.2.8节）进行编码的输入，根据[RFC4843]中所述的兰花生成方法生成HIT。当使用此上下文ID生成命中时，必须使用哈希算法SHA-1。如果将来需要新的兰花哈希算法生成命中，则必须使用与新哈希算法关联的新兰花上下文ID指定新版本的HIP。
For Identities that are either RSA or Digital Signature Algorithm (DSA) public keys, this input consists of the public key encoding as specified in the corresponding DNSSEC document, taking the algorithm-specific portion of the RDATA part of the KEY RR. There are currently only two defined public key algorithms: RSA/SHA1 and DSA. Hence, either of the following applies:
对于RSA或数字签名算法（DSA）公钥的身份，此输入由相应DNSSEC文档中指定的公钥编码组成，采用密钥RR中RDATA部分的算法特定部分。目前只有两种定义的公钥算法：RSA/SHA1和DSA。因此，以下任一项适用：
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 to be hashed 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））确定。因此，要散列的数据具有与HI相同的长度。字段必须按照[RFC3110]中定义的网络字节顺序编码。
The DSA public key is encoded as defined in [RFC2536] Section 2, taking the fields T, Q, P, G, and Y, concatenated. 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]中定义的网络字节顺序编码。
In Appendix B, the public key encoding process is illustrated using pseudo-code.
在附录B中，使用伪码说明了公钥编码过程。
The following material is an overview of the HIP protocol operation, and does not contain all 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 [RFC5202].
HIP有效载荷（第5.1节）报头可以在每个IP数据报中携带。然而，由于HIP报头相对较大（40字节），因此需要“压缩”HIP报头，以便HIP报头仅出现在用于建立或更改HIP关联状态的控制分组中。标头“压缩”和将数据包与现有HIP关联（如果有）匹配的实际方法在单独的文档中定义，描述了传输格式和方法。所有HIP实现必须至少实现HIP的ESP传输格式[RFC5202]。
By definition, the system initiating a HIP exchange is the Initiator, and the peer is the Responder. This distinction is forgotten once the base exchange completes, and either party can become the Initiator in future communications.
根据定义，发起HIP交换的系统是发起方，对等方是响应方。一旦基本交换完成，这种区别就会被忘记，任何一方都可以成为未来通信的发起方。
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. During the Diffie-Hellman key exchange, a piece of keying material is generated. The HIP association keys are drawn from this keying material. If other cryptographic keys are needed, e.g., to be used with ESP, they are expected to be drawn from the same keying material.
HIP-base交换用于管理发起方和响应方之间状态的建立。第一个数据包I1启动交换，最后三个数据包R1、I2和R2构成用于会话密钥生成的经过身份验证的Diffie-Hellman[DIF76]密钥交换。在Diffie-Hellman密钥交换过程中，会生成一段密钥材料。髋部关联关键帧是从该关键帧材质绘制的。如果需要其他加密密钥，例如与ESP一起使用，则应使用相同的密钥材料。
The Initiator first sends a trigger packet, I1, to the Responder. The packet contains only the HIT of the Initiator and possibly the HIT of the Responder, if it is known. Note that in some cases it may be possible to replace this trigger packet by some other form of a trigger, in which case the protocol starts with the Responder sending the R1 packet.
发起方首先向响应方发送一个触发包I1。数据包只包含发起方的命中，如果已知，还可能包含响应方的命中。注意，在某些情况下，可以用其他形式的触发器替换该触发器数据包，在这种情况下，协议从发送R1数据包的响应者开始。
The second packet, R1, starts the actual 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 level of trust with the Initiator, current load, or other factors. In addition, the R1 contains the initial Diffie-Hellman parameters and a signature, covering part of the message. Some fields are left outside the signature to support pre-created R1s.
第二个数据包R1开始实际的交换。它包含一个谜题——发起方在继续交换之前必须解决的加密挑战。谜题的难度可以根据对发起者的信任程度、当前负载或其他因素进行调整。此外，R1包含初始Diffie-Hellman参数和签名，覆盖部分消息。有些字段保留在签名之外，以支持预先创建的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 also contains a Diffie-Hellman parameter that carries needed information for the Responder. The packet is signed by the sender.
在I2数据包中，发起者必须显示收到的谜题的解决方案。如果没有正确的解决方案，I2消息将被丢弃。I2还包含一个Diffie-Hellman参数，该参数携带响应者所需的信息。数据包由发送方签名。
The R2 packet finalizes the base exchange. The packet is signed.
R2数据包完成基本交换。数据包已签名。
The base exchange is illustrated below. 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.
基本交换如下图所示。术语“密钥”是指主机标识公钥，“sig”表示使用这种密钥的签名。数据包包含此图中未显示的其他参数。
Initiator Responder
发起者响应者
I1: trigger exchange
-------------------------->
select precomputed R1
R1: puzzle, D-H, key, sig
<-------------------------
check sig remain stateless
solve puzzle
I2: solution, D-H, {key}, sig
-------------------------->
compute D-H check puzzle
check sig
R2: sig
<--------------------------
check sig compute D-H
I1: trigger exchange
-------------------------->
select precomputed R1
R1: puzzle, D-H, key, sig
<-------------------------
check sig remain stateless
solve puzzle
I2: solution, D-H, {key}, sig
-------------------------->
compute D-H check puzzle
check sig
R2: sig
<--------------------------
check sig compute D-H
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 I2. 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 CPU cycles in solving the puzzle.
HIP puzzle机制的目的是保护响应者免受拒绝服务威胁。它允许响应者延迟状态创建，直到接收到I2。此外，谜题允许响应者使用相当便宜的计算来检查发起者是否“真诚”，因为它在解决谜题时搅乱了CPU周期。
The puzzle mechanism has been explicitly designed to give space for various implementation options. It allows a Responder implementation to completely delay session-specific state creation until a valid I2 is received. In such a case, a correctly formatted I2 can be rejected only once the Responder has checked its validity by computing one hash function. On the other hand, the design also allows a Responder implementation to keep state about received I1s, and match the received I2s against the state, thereby allowing the implementation to avoid the computational cost of the hash function. The drawback of this latter approach is the requirement of creating state. Finally, it also allows an implementation to use other combinations of the space-saving and computation-saving mechanisms.
谜题机制被明确设计为为各种实现选项提供空间。它允许响应程序实现完全延迟特定于会话的状态创建，直到收到有效的I2。在这种情况下，只有当响应者通过计算一个散列函数来检查其有效性时，才能拒绝正确格式化的I2。另一方面，该设计还允许响应器实现保持关于接收到的i1的状态，并将接收到的i2与状态匹配，从而允许实现避免散列函数的计算开销。后一种方法的缺点是需要创建状态。最后，它还允许实现使用节省空间和节省计算的机制的其他组合。
The Responder can remain stateless and drop most spoofed I2s 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 the information carried in I1. When the Responder then later receives I2, 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, and then generate a large number of spoofed I2s that seemingly come from different HITs. The method does not protect 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. Implementations SHOULD include sufficient randomness to the algorithm so that algorithmic complexity attacks become impossible [CRO03].
响应程序可以保持无状态并删除大多数欺骗的I2，因为谜题计算基于启动器的主机标识标记。其思想是响应者具有（可能变化的）数量的预先计算的R1分组，并且它基于I1中携带的信息选择其中一个。当响应者随后收到I2时，它可以使用发起人的命中来验证谜题是否已解决。这使得攻击者无法首先交换一个I1/R1，然后生成大量看似来自不同命中的伪造I2。但是，该方法不能防止使用固定命中的攻击者。针对这种攻击者，一种可行的方法可能是创建一段本地状态，并记住之前的谜题检查失败。有关一种可能的实施方式，请参见附录A。实现应包括足够的算法随机性，以便算法复杂性攻击变得不可能[CRO03]。
The Responder can set the puzzle difficulty for 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; see below.
响应者可以根据其对发起者的信任级别为发起者设置谜题难度。因为谜题不包括在签名计算中，所以响应者可以使用预先计算的R1数据包，并在将R1发送给发起方之前包括谜题。响应者应使用启发式方法确定其何时受到拒绝服务攻击，并适当设置谜题难度值K；见下文。
The Responder starts the puzzle exchange when it receives an I1. 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 take 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 (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 did its assigned task.
为了生成一个正确的J数，发起者必须生成一个J数，直到其中一个生成零数的散列目标。发起者应在超过谜题参数中的谜题生存期后放弃（第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 was indeed selected by it and not by the Initiator. See Appendix A for an example on how to implement this.
为了防止预计算攻击，响应者必须选择数字I，使启动器无法猜到。此外，构造必须允许响应者验证该值确实是由它选择的，而不是由启动器选择的。有关如何实现这一点的示例，请参见附录A。
Using the Opaque data field in an ECHO_REQUEST_SIGNED (Section 5.2.17) or in an ECHO_REQUEST_UNSIGNED parameter (Section 5.2.18), the Responder can include some data in R1 that the Initiator must copy unmodified in the corresponding I2 packet. The Responder can generate the Opaque data in various ways; e.g., using some secret, the sent I, and possibly other related data. Using the same secret, the received I (from the I2), and the other related data (if any), the Receiver can verify that it has itself sent the I to the Initiator. The Responder MUST periodically change such a used secret.
使用ECHO_请求_签名（第5.2.17节）或ECHO_请求_未签名参数（第5.2.18节）中的不透明数据字段，响应者可以在R1中包含一些数据，发起人必须在相应的I2数据包中复制这些数据，而无需修改。响应者可以以各种方式生成不透明数据；e、 例如，使用一些秘密、发送的I以及可能的其他相关数据。使用相同的秘密、接收到的I（来自I2）和其他相关数据（如果有），接收器可以验证它自己是否已将I发送给启动器。响应者必须定期更改此类已使用的机密。
It is RECOMMENDED that the Responder generates a new puzzle and a new R1 once every few minutes. Furthermore, it is RECOMMENDED that the Responder remembers an old puzzle at least 2*Lifetime seconds after the puzzle has been deprecated. These time values allow a slower Initiator to solve the puzzle while limiting the usability that an old, solved puzzle has to an attacker.
建议响应者每隔几分钟生成一个新的谜题和一个新的R1。此外，建议响应者在旧拼图被弃用后至少2*生存期秒记住旧拼图。这些时间值允许较慢的发起者解决难题，同时限制旧的已解决难题对攻击者的可用性。
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.
注意：协议开发人员明确考虑了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 not to use memory-bound functions. At
注意：协议开发人员明确考虑了是否应该使用内存绑定函数来代替CPU绑定函数。决定是不使用内存绑定函数。在
the time of the decision, the idea of memory-bound functions was relatively new and their IPR status were unknown. Once there is more experience about memory-bound functions and once their IPR status is better known, it may be reasonable to reconsider this decision.
在作出决定时，记忆约束函数的概念相对较新，其IPR状态未知。一旦有了更多关于内存约束函数的经验，并且更好地了解了它们的IPR状态，重新考虑这个决定可能是合理的。
The packets R1, I2, and R2 implement a standard authenticated Diffie-Hellman exchange. The Responder sends one or two public Diffie-Hellman keys and its public authentication key, i.e., its Host Identity, in R1. The signature in R1 allows the Initiator to verify that the R1 has been once generated by the Responder. However, since it is precomputed and therefore does not cover all of the packet, it does not protect from replay attacks.
数据包R1、I2和R2实现标准的经过身份验证的Diffie-Hellman交换。响应者在R1中发送一个或两个公共Diffie-Hellman密钥及其公共身份验证密钥，即其主机标识。R1中的签名允许发起方验证R1是否已由响应方生成。但是，由于它是预计算的，因此不能覆盖所有数据包，因此不能防止重播攻击。
When the Initiator receives an R1, it gets one or two public Diffie-Hellman values from the Responder. If there are two values, it selects the value corresponding to the strongest supported Group ID and computes the Diffie-Hellman session key (Kij). It creates a HIP association using keying material from the session key (see Section 6.5), and may use the association to encrypt its public authentication key, i.e., Host Identity. The resulting I2 contains the Initiator's Diffie-Hellman key and its (optionally encrypted) public authentication key. The signature in I2 covers all of the packet.
当启动器收到R1时，它从响应程序获得一个或两个公共Diffie-Hellman值。如果有两个值，它将选择与支持的最强组ID对应的值，并计算Diffie-Hellman会话密钥（Kij）。它使用会话密钥中的密钥材料创建HIP关联（见第6.5节），并可使用该关联加密其公共身份验证密钥，即主机标识。生成的I2包含启动器的Diffie-Hellman密钥及其（可选加密的）公共身份验证密钥。I2中的签名覆盖了所有数据包。
The Responder extracts the Initiator Diffie-Hellman public key from the I2, 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, is needed to protect the Initiator from replay attacks.
最后一条消息R2用于保护启动器免受重播攻击。
The HIP protocol includes the following mechanisms to protect against malicious replays. Responders are protected against replays of I1 packets by virtue of the stateless response to I1s with presigned R1 messages. Initiators are protected against R1 replays by a monotonically increasing "R1 generation counter" included in the R1. Responders are protected against replays or false I2s by the puzzle mechanism (Section 4.1.1 above), and optional use of opaque data. Hosts are protected against replays to R2s and UPDATEs by use of a less expensive HMAC verification preceding HIP signature verification.
HIP协议包括以下机制以防止恶意重播。通过使用预先签名的R1消息对I1进行无状态响应，可以保护响应程序不受I1数据包重放的影响。通过R1中包含的单调递增的“R1生成计数器”，保护启动器不受R1重放的影响。通过谜题机制（上文第4.1.1节）和不透明数据的可选使用，可以保护响应者不受重播或虚假I2的影响。通过在HIP签名验证之前使用成本较低的HMAC验证，可以防止主机重播到R2s和更新。
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 SHOULD be per Host Identity, if there is more than one local host identity. The value of this counter SHOULD be kept 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 incremented at least as often as every time old R1s cease to be valid, and SHOULD never be decremented, lest the host expose its peers to the replay of previously generated, higher numbered R1s. The R1 counter SHOULD NOT roll over.
R1生成计数器是一个单调递增的64位计数器，可以初始化为任何值。计数器的范围可以是系统范围，但如果有多个本地主机标识，则应为每个主机标识。此计数器的值应在系统重新启动和调用HIP base exchange期间保持不变。此计数器表示当前一代拼图。实现必须接受当前一代的谜题，也可以接受前几代的谜题。每次旧R1s失效时，系统的本地计数器必须至少以相同的频率递增，并且不得递减，以免主机将其对等方暴露于先前生成的、编号较高的R1s的重播中。R1计数器不应翻滚。
A host may receive more than one R1, either due to sending multiple I1s (Section 6.6.1) or due to a replay of an old R1. When sending multiple I1s, 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 (still waiting for R2) 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一样。
Upon conclusion of an active HIP association with another host, the R1 generation counter associated with the peer host SHOULD be flushed. A local policy MAY override the default flushing of R1 counters on a per-HIT basis. The reason for recommending the flushing of this counter is that there may be hosts where the R1 generation counter (occasionally) decreases; e.g., due to hardware failure.
在与另一主机的活动HIP关联结束后，应刷新与对等主机关联的R1生成计数器。本地策略可以在每次命中的基础上覆盖R1计数器的默认刷新。建议刷新此计数器的原因是，可能存在R1生成计数器（偶尔）减少的主机；e、 例如，由于硬件故障。
A HIP-aware host may choose not to accept a HIP exchange. If the host's policy is to only be an Initiator, it should begin its own HIP exchange. A host MAY choose to have such a policy since only the Initiator's HI is protected in the exchange. There is a risk of a race condition if each host's policy is to only be an Initiator, at which point the HIP exchange will fail.
HIP感知主机可以选择不接受HIP交换。如果主机的策略是仅作为启动器，则它应该开始自己的HIP交换。主机可以选择使用这样的策略，因为在exchange中只有启动器的HI受到保护。如果每个主机的策略仅为启动器，则存在竞争条件的风险，此时HIP交换将失败。
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.
如果主机的策略不允许其与启动器进行HIP交换，则应发送ICMP“目的地不可访问，管理禁止”消息。这里不使用更复杂的HIP数据包，因为它实际上比简单的ICMP消息打开更多潜在的DoS攻击。
It is possible to initiate a HIP negotiation even if the Responder's HI (and HIT) is unknown. In this case, the connection initializing I1 packet contains NULL (all zeros) as the destination HIT. This kind of connection setup is called opportunistic mode.
即使响应者的HI（和HIT）未知，也可以启动髋关节协商。在这种情况下，初始化I1数据包的连接包含NULL（全零）作为目标命中。这种连接设置称为机会主义模式。
There are both security and API issues involved with the opportunistic mode.
机会主义模式涉及到安全性和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 kernel initiate 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, it 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 session still appears to be between specific locators. The locator update is still secure, however, and the session is still between the same nodes.
o 如果使用了更新消息，则实际的定位器稍后可能会更改，即使从API的角度来看，会话似乎仍然在特定定位器之间。但是，定位器更新仍然是安全的，会话仍然在相同的节点之间。
o Different sessions between the same locators may result in connections to different nodes, if the implementation no longer remembers which identifier the peer had in another session. 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 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 a session, this may even happen within the same session. For instance, an implementation may not know when HIP state can be purged for UDP-based applications.
如果HIP实现和应用程序对会话的组成没有相同的理解，那么这甚至可能发生在同一会话中。例如，实现可能不知道何时可以清除基于UDP的应用程序的HIP状态。
o As with all HIP exchanges, the handling of locator-based or interface-based policy is unclear for opportunistic mode HIP. An application may make a connection to a specific locator because the application has knowledge of the security properties along the network to that locator. If one of the nodes moves and the locators are updated, these security properties may not be maintained. Depending on the security policy of the application, this may be a problem. This is an area of ongoing study. As an
o 与所有HIP交换一样，对于机会主义HIP模式，基于定位器或基于接口的策略的处理不清楚。应用程序可以连接到特定的定位器，因为该应用程序知道该定位器在网络上的安全属性。如果其中一个节点移动且定位器更新，则可能不会维护这些安全属性。根据应用程序的安全策略，这可能是一个问题。这是一个正在进行研究的领域。作为
example, there is work to create an API that applications can use to specify their security requirements in a similar context [IPsec-APIs].
例如，我们正在创建一个API，应用程序可以使用该API在类似的上下文中指定其安全要求[IPsec API]。
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 any HI, not just the one given in the I1 packet.
此外，以下安全注意事项适用。由于响应者可以选择使用任何HI（而不仅仅是I1数据包中给出的HI）的重播，因此生成计数器机制在防止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 session 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会话，两个对等方之间路径上的攻击者可以将自己作为中间人插入。为了实现这一点，发起方必须采用机会主义模式，并且响应方必须配置为接受来自任何支持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 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 normal IP cases is denial-of-service; an entity on the path can disrupt communications, but will be unable to insert itself as a man-in-the-middle.
如果端到端安全已经到位，那么在机会主义和正常IP情况下可能发生的最坏情况就是拒绝服务；路径上的实体可以中断通信，但无法将自身作为中间人插入。
However, once the opportunistic exchange has successfully completed, HIP provides integrity protection and confidentiality for the communications, and can securely change the locators of the endpoints.
但是，一旦机会主义交换成功完成，HIP将为通信提供完整性保护和机密性，并且可以安全地更改端点的定位器。
As a result, it is believed that the HIP opportunistic mode is at least as secure as current IP.
因此，人们相信HIP机会主义模式至少与当前IP一样安全。
A HIP association between two hosts may need to be updated over time. Examples include the need to rekey expiring user data 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 HMAC and HIP_SIGNATURE parameters, since processing UPDATE signatures alone is a potential DoS attack against intermediate systems.
更新受HMAC和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 is 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 I1 and getting R1. When the Responder receives a valid I2, 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关联匹配的用户数据包时“检测”情况。接收主机必须丢弃此数据包。
Optionally, the receiving host MAY 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 negotiation. However, responding with these optional mechanisms is implementation or policy dependent.
可选地，接收主机可以发送一个ICMP数据包，带有类型参数问题，以通知发送方HIP关联不存在（参见第5.4节），并且它可以启动一个新的HIP协商。但是，使用这些可选机制进行响应取决于实现或策略。
The HIP protocol 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 presented in a single system view, representing either an Initiator or a Responder. There is not a complete overlap of processing logic here and in the packet definitions. Both are needed to completely implement HIP.
状态机显示在单个系统视图中，表示发起方或响应方。这里和包定义中的处理逻辑没有完全重叠。两者都是完全实现HIP所必需的。
Implementors must understand that the state machine, as described here, is informational. Specific implementations are free to implement the actual functions differently. Section 6 describes the packet processing rules in more detail. This state machine focuses
实现者必须理解，如本文所述，状态机是信息性的。具体实现可以自由地以不同的方式实现实际功能。第6节更详细地描述了数据包处理规则。这个状态机聚焦于
on the HIP I1, R1, I2, and R2 packets only. Other states may be introduced by mechanisms in other specifications (such as mobility and multihoming).
仅在HIP I1、R1、I2和R2数据包上。其他状态可能由其他规范中的机制引入（如移动性和多归宿）。
+---------------------+---------------------------------------------+
| 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 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 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 | Optionally send ICMP as defined in |
| for unknown HIP | Section 5.4 and stay at UNASSOCIATED |
| association | |
| | |
| 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 | Optionally send ICMP as defined in |
| for unknown HIP | Section 5.4 and stay at UNASSOCIATED |
| association | |
| | |
| 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 | If the local HIT is smaller than the peer |
| | HIT, drop I1 and stay at I1-SENT |
| | |
| | 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 successful, send I2 and go to I2-SENT |
| | |
| | If fail, stay at I1-SENT |
| | |
| Receive ANYOTHER | Drop and stay at I1-SENT |
| | |
| Timeout, increment | If counter is less than I1_RETRIES_MAX, |
| timeout counter | send I1 and stay at I1-SENT |
| | |
| | If counter is greater than I1_RETRIES_MAX, |
| | go to E-FAILED |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 | If the local HIT is smaller than the peer |
| | HIT, drop I1 and stay at I1-SENT |
| | |
| | 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 successful, send I2 and go to I2-SENT |
| | |
| | If fail, stay at I1-SENT |
| | |
| Receive ANYOTHER | Drop and stay at I1-SENT |
| | |
| Timeout, increment | If counter is less than I1_RETRIES_MAX, |
| timeout counter | send I1 and stay at I1-SENT |
| | |
| | If counter is greater than I1_RETRIES_MAX, |
| | go to E-FAILED |
+---------------------+---------------------------------------------+
Table 3: I1-SENT - Initiating HIP
表3:I1-SENT-启动HIP
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 cycle 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 ANYOTHER | Drop and stay at I2-SENT |
| | |
| Timeout, increment | If counter is less than I2_RETRIES_MAX, |
| timeout counter | 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 cycle 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 ANYOTHER | Drop and stay at I2-SENT |
| | |
| Timeout, increment | If counter is less than I2_RETRIES_MAX, |
| timeout counter | 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 HIP
表4:I2-SENT-等待完成HIP
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 cycle 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 | Move to ESTABLISHED |
| UPDATE | |
| | |
| Exchange Complete | Move to ESTABLISHED |
| Timeout | |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay at R2-SENT |
| | |
| Receive I2, process | If successful, send R2 and cycle 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 | Move to ESTABLISHED |
| UPDATE | |
| | |
| Exchange Complete | Move to ESTABLISHED |
| Timeout | |
+---------------------+---------------------------------------------+
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 | If successful, send R2, drop old HIP |
| with puzzle and | association, establish a new HIP |
| possible Opaque | association, go to R2-SENT |
| data verification | |
| | |
| | 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 CLOSE, | If successful, send CLOSE_ACK and go to |
| process | CLOSED |
| | |
| | If fail, stay at ESTABLISHED |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay at ESTABLISHED |
| | |
| Receive I2, process | If successful, send R2, drop old HIP |
| with puzzle and | association, establish a new HIP |
| possible Opaque | association, go to R2-SENT |
| data verification | |
| | |
| | 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 CLOSE, | If successful, send CLOSE_ACK and go to |
| process | CLOSED |
| | |
| | If fail, 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 stay at CLOSING |
| 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, | If successful, send CLOSE_ACK, discard |
| process | state and go to CLOSED |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive CLOSE_ACK, | If successful, discard state and go to |
| process | UNASSOCIATED |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive ANYOTHER | Drop and stay at CLOSING |
| | |
| Timeout, increment | If timeout sum is less than UAL+MSL |
| timeout sum, reset | minutes, retransmit CLOSE and stay at |
| timer | CLOSING |
| | |
| | If timeout sum is greater than UAL+MSL |
| | minutes, go to UNASSOCIATED |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| User data to send, | Send I1 and stay at CLOSING |
| 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, | If successful, send CLOSE_ACK, discard |
| process | state and go to CLOSED |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive CLOSE_ACK, | If successful, discard state and go to |
| process | UNASSOCIATED |
| | |
| | If fail, stay at CLOSING |
| | |
| Receive ANYOTHER | Drop and stay at CLOSING |
| | |
| Timeout, increment | If timeout sum is less than UAL+MSL |
| timeout sum, reset | minutes, retransmit CLOSE and stay at |
| timer | 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, | Send I1, and stay at CLOSED |
| requires the | |
| creation of another | |
| incarnation of the | |
| 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, | If successful, send CLOSE_ACK, stay at |
| process | CLOSED |
| | |
| | If fail, stay at CLOSED |
| | |
| Receive CLOSE_ACK, | If successful, discard state and go to |
| process | 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, | Send I1, and stay at CLOSED |
| requires the | |
| creation of another | |
| incarnation of the | |
| 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, | If successful, send CLOSE_ACK, stay at |
| process | CLOSED |
| | |
| | If fail, stay at CLOSED |
| | |
| Receive CLOSE_ACK, | If successful, discard state and go to |
| process | 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. Re-negotiation is |
| implementation-specific | possible after moving to UNASSOCIATED |
| time | state. |
+-------------------------+-----------------------------------------+
+-------------------------+-----------------------------------------+
| Trigger | Action |
+-------------------------+-----------------------------------------+
| Wait for | Go to UNASSOCIATED. Re-negotiation 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 shows the major state transitions. Transitions based on received packets implicitly assume that the packets are successfully authenticated or processed.
下图显示了主要的状态转换。基于接收到的数据包的转换隐式地假定数据包已成功通过身份验证或处理。
+-+ +---------------------------+
I1 received, send R1 | | | |
| v v |
Datagram to send +--------------+ I2 received, send R2 |
+---------------| UNASSOCIATED |---------------+ |
Send I1 | +--------------+ | |
v | |
+---------+ I2 received, send R2 | |
+---->| I1-SENT |---------------------------------------+ | |
| +---------+ | | |
| | +------------------------+ | | |
| | R1 received, | I2 received, send R2 | | | |
| v send I2 | v v v |
| +---------+ | +---------+ |
| +->| I2-SENT |------------+ | R2-SENT |<----+ |
| | +---------+ +---------+ | |
| | | | | |
| | | data| | |
| |receive | or| | |
| |R1, send | EC timeout| receive I2,| |
| |I2 |R2 received +--------------+ | send R2| |
| | +----------->| ESTABLISHED |<-------+| | |
| | +--------------+ | |
| | | | | receive I2, send R2 | |
| | recv+------------+ | +------------------------+ |
| | CLOSE,| | | |
| | send| No packet sent| | |
| | CLOSE_ACK| /received for | timeout | |
| | | UAL min, send | +---------+<-+ (UAL+MSL) | |
| | | CLOSE +--->| CLOSING |--+ retransmit | |
| | | +---------+ CLOSE | |
+--|------------|----------------------+ | | | | | |
+------------|------------------------+ | | +----------------+ |
| | +-----------+ +------------------|--+
| +------------+ | receive CLOSE, CLOSE_ACK | |
| | | send CLOSE_ACK received or | |
| | | timeout | |
| | | (UAL+MSL) | |
| v v | |
| +--------+ receive I2, send R2 | |
+------------------------| CLOSED |---------------------------+ |
+--------+ /----------------------+
^ | \-------/ timeout (UAL+2MSL),
+-+ move to UNASSOCIATED
CLOSE received, send CLOSE_ACK
+-+ +---------------------------+
I1 received, send R1 | | | |
| v v |
Datagram to send +--------------+ I2 received, send R2 |
+---------------| UNASSOCIATED |---------------+ |
Send I1 | +--------------+ | |
v | |
+---------+ I2 received, send R2 | |
+---->| I1-SENT |---------------------------------------+ | |
| +---------+ | | |
| | +------------------------+ | | |
| | R1 received, | I2 received, send R2 | | | |
| v send I2 | v v v |
| +---------+ | +---------+ |
| +->| I2-SENT |------------+ | R2-SENT |<----+ |
| | +---------+ +---------+ | |
| | | | | |
| | | data| | |
| |receive | or| | |
| |R1, send | EC timeout| receive I2,| |
| |I2 |R2 received +--------------+ | send R2| |
| | +----------->| ESTABLISHED |<-------+| | |
| | +--------------+ | |
| | | | | receive I2, send R2 | |
| | recv+------------+ | +------------------------+ |
| | CLOSE,| | | |
| | send| No packet sent| | |
| | CLOSE_ACK| /received for | timeout | |
| | | UAL min, send | +---------+<-+ (UAL+MSL) | |
| | | CLOSE +--->| CLOSING |--+ retransmit | |
| | | +---------+ CLOSE | |
+--|------------|----------------------+ | | | | | |
+------------|------------------------+ | | +----------------+ |
| | +-----------+ +------------------|--+
| +------------+ | receive CLOSE, CLOSE_ACK | |
| | | send CLOSE_ACK received or | |
| | | timeout | |
| | | (UAL+MSL) | |
| v v | |
| +--------+ receive I2, send R2 | |
+------------------------| CLOSED |---------------------------+ |
+--------+ /----------------------+
^ | \-------/ timeout (UAL+2MSL),
+-+ move to UNASSOCIATED
CLOSE received, send CLOSE_ACK
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 on the packet are IPv4 addresses. Additionally, the HITs MUST be used in the 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节。
A future version of this document may define how to include user data on 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 [RFC5202].
本文档中未定义用于HIP base交换后用户数据的实际数据传输格式。此类传输格式和方法在单独的规范中描述。所有HIP实现必须至少实现HIP的ESP传输格式[RFC5202]。
When new transport formats are defined, they get the type value from the HIP Transform type value space 2048-4095. The order in which the transport formats are presented in the R1 packet, is the preferred order. The last of the transport formats MUST be ESP transport format, represented by the ESP_TRANSFORM parameter.
定义新的传输格式时，它们从HIP变换类型值空间2048-4095获取类型值。传输格式在R1数据包中呈现的顺序是首选顺序。最后一种传输格式必须是ESP传输格式，由ESP_TRANSFORM参数表示。
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 SA and start sending data. The peer does not reset its state until it receives a valid I2 HIP packet.
如果主机重新启动或HIP关联超时，则它已失去HIP状态。如果丢失状态的主机有一个数据报要发送给对等机，它只需重新启动HIP base exchange。基本交换完成后，启动器可以创建新SA并开始发送数据。对等方在收到有效的I2 HIP数据包之前不会重置其状态。
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
如果系统接收到无法与任何现有HIP关联匹配的用户数据包，则可能是系统已丢失状态，而其对等方未丢失状态。它可以发送带有参数的ICMP数据包
Problem type, and with the pointer pointing to the referred 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 SA and creates a new one.
如果主机（显然已失去其状态）决定重新启动HIP base exchange，它将向对等方发送I1数据包。成功完成基本交换后，发起方可以创建新的HIP关联，对等方放弃其旧SA并创建新的SA。
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. A parameter type value, meant to be used for carrying certificates, is reserved, though: CERT, Type 768; see Section 5.2.
本文档未定义如何使用证书或如何在主机之间传输证书。这些功能预计将在未来的规范中定义。保留了一个用于携带证书的参数类型值：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 | VER. | RES.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Controls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ HIP Parameters /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Length |0| Packet Type | VER. | RES.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Controls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ HIP Parameters /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The HIP header is logically an IPv6 extension header. 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 do so. 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 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. 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标头的长度和HIP参数，以8字节为单位，不包括前8个字节。由于所有HIP头必须包含发送方和接收方的HIT字段，因此该字段的最小值为4，反之，HIP参数字段的最大长度为（255*8）-32=2008字节。注意：这为参数字段中包含的参数的大小设置了一个附加限制，与单个参数的最大长度无关。
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 unknown packet type, it MUST drop the packet.
数据包类型表示HIP数据包类型。各个数据包类型在相关章节中定义。如果HIP主机接收到包含未知数据包类型的HIP数据包，则必须丢弃该数据包。
The HIP Version is four bits. The current version is 1. 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.
HIP版本是四位的。当前版本为1。只有当协议发生不兼容的更改时，版本号才会增加。大多数扩展可以通过定义新的数据包类型、新的参数类型或新的控件来处理。
The following three bits are reserved for future use. They MUST be zero when sent, and they SHOULD be ignored when handling a received packet.
以下三位保留供将来使用。它们在发送时必须为零，在处理接收到的数据包时应忽略它们。
The two fixed bits in the header are reserved for potential SHIM6 compatibility [SHIM6-PROTO]. 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, in the case that the forthcoming SHIM6 protocol happens to be compatible with this specification, 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.
报头中的两个固定位保留用于潜在的SHIM6兼容性[SHIM6-PROTO]。对于（仅）遵守本规范的实现，它们必须在发送时按所示进行设置，在接收时必须忽略。这是为了确保最佳的前向兼容性。请注意，对于除此规范之外实现其他兼容规范的实现，相应的规则可能会有所不同。例如，在即将到来的SHIM6协议恰好与本规范兼容的情况下，实现本规范和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 4) in the Next Header field. The length field is in bytes and can be calculated from the HIP header length field: (HIP Header Length + 1) * 8.
如果IPv6用于承载HIP数据包，则伪报头[RFC2460]包含源和目标IPv6地址、伪报头长度字段中的HIP数据包长度、零字段以及下一报头字段中的HIP协议号（见第4节）。长度字段以字节为单位，可以从HIP header length字段计算：（HIP header length+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 section 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 R1 and/or I2. The peer receiving an anonymous HI may choose to refuse it.
A-匿名：如果设置了此选项，则此数据包中发件人的HI是匿名的，即未在目录中列出的HI。不应存储匿名HIs。此控件在数据包R1和/或I2中设置。接收匿名HI的对等方可以选择拒绝。
The rest of the fields are reserved for future use and MUST be set to zero on sent packets and ignored on 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 a host expects to send HIP packets that are larger than the minimum IPv6 MTU, it 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 HIP 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 MUST perform any IPv4 reassembly/fragmentation.
在IPv4网络中，HIP数据包可能会在其路由路径上遇到较低的MTU。由于HIP不提供为单个HIP数据包使用多个IP数据报的机制，因此对路径MTU发现的支持不会给IPv4网络中的HIP带来任何价值。支持HIP的NAT设备必须执行任何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攻击。
Because certificate chains can cause the packet to be fragmented and fragmentation can open implementation to denial-of-service attacks [KAU03], it is strongly recommended that the separate document specifying the certificate usage in the HIP Base Exchange defines the usage of "Hash and URL" formats rather than including certificates in exchanges. With this, most problems related to DoS attacks with fragmentation can be avoided.
由于证书链会导致数据包碎片化，碎片化会使实现面临拒绝服务攻击[KAU03]，因此强烈建议指定HIP Base Exchange中证书使用情况的单独文档定义“哈希和URL”的使用情况格式，而不是在交换中包含证书。这样，就可以避免与带有碎片的DoS攻击相关的大多数问题。
The HIP Parameters are used to carry the public key associated with the sender's HIT, together with related security and other information. They consist of ordered parameters, encoded in TLV format.
HIP参数用于携带与发送者的命中相关联的公钥，以及相关的安全性和其他信息。它们由有序参数组成，以TLV格式编码。
The following parameter types are currently defined.
当前定义了以下参数类型。
+------------------------+-------+----------+-----------------------+
| TLV | Type | Length | Data |
+------------------------+-------+----------+-----------------------+
| R1_COUNTER | 128 | 12 | System Boot 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 |
| | | | |
| DIFFIE_HELLMAN | 513 | variable | public key |
| | | | |
| HIP_TRANSFORM | 577 | variable | HIP Encryption and |
| | | | Integrity Transform |
| | | | |
| ENCRYPTED | 641 | variable | Encrypted part of I2 |
| | | | packet |
| | | | |
| HOST_ID | 705 | variable | Host Identity with |
| | | | Fully-Qualified |
| | | | Domain FQDN (Name) or |
| | | | Network Access |
| | | | Identifier (NAI) |
| | | | |
| CERT | 768 | variable | HI Certificate; used |
| | | | to transfer |
| | | | certificates. Usage |
| | | | is not currently |
| | | | defined, but it will |
| | | | be specified in a |
| | | | separate document |
| | | | once needed. |
| | | | |
| NOTIFICATION | 832 | variable | Informational data |
| | | | |
| ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be |
| | | | echoed back; under |
| | | | signature |
| | | | |
| ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed |
| | | | back; under signature |
| | | | |
+------------------------+-------+----------+-----------------------+
| TLV | Type | Length | Data |
+------------------------+-------+----------+-----------------------+
| R1_COUNTER | 128 | 12 | System Boot 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 |
| | | | |
| DIFFIE_HELLMAN | 513 | variable | public key |
| | | | |
| HIP_TRANSFORM | 577 | variable | HIP Encryption and |
| | | | Integrity Transform |
| | | | |
| ENCRYPTED | 641 | variable | Encrypted part of I2 |
| | | | packet |
| | | | |
| HOST_ID | 705 | variable | Host Identity with |
| | | | Fully-Qualified |
| | | | Domain FQDN (Name) or |
| | | | Network Access |
| | | | Identifier (NAI) |
| | | | |
| CERT | 768 | variable | HI Certificate; used |
| | | | to transfer |
| | | | certificates. Usage |
| | | | is not currently |
| | | | defined, but it will |
| | | | be specified in a |
| | | | separate document |
| | | | once needed. |
| | | | |
| NOTIFICATION | 832 | variable | Informational data |
| | | | |
| ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be |
| | | | echoed back; under |
| | | | signature |
| | | | |
| ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed |
| | | | back; under signature |
| | | | |
| HMAC | 61505 | variable | HMAC-based message |
| | | | authentication code, |
| | | | with key material |
| | | | from HIP_TRANSFORM |
| | | | |
| HMAC_2 | 61569 | variable | HMAC based message |
| | | | authentication code, |
| | | | with key material |
| | | | from HIP_TRANSFORM. |
| | | | Compared to HMAC, the |
| | | | HOST_ID parameter is |
| | | | included in HMAC_2 |
| | | | calculation. |
| | | | |
| HIP_SIGNATURE_2 | 61633 | variable | Signature of the 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; after signature |
+------------------------+-------+----------+-----------------------+
| HMAC | 61505 | variable | HMAC-based message |
| | | | authentication code, |
| | | | with key material |
| | | | from HIP_TRANSFORM |
| | | | |
| HMAC_2 | 61569 | variable | HMAC based message |
| | | | authentication code, |
| | | | with key material |
| | | | from HIP_TRANSFORM. |
| | | | Compared to HMAC, the |
| | | | HOST_ID parameter is |
| | | | included in HMAC_2 |
| | | | calculation. |
| | | | |
| HIP_SIGNATURE_2 | 61633 | variable | Signature of the 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; after signature |
+------------------------+-------+----------+-----------------------+
Because 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. Parameters numbered between 0-1023 are used in HIP handshake and update procedures and are covered by signatures. Parameters numbered between 1024-2047 are reserved. Parameters numbered between 2048-4095 are used for parameters related to HIP transform types. Parameters numbered between 4096 and (2^16 - 2^12) 61439 are reserved. Parameters numbered between 61440-62463 are used for signatures and signed MACs. Parameters numbered between 62464- 63487 are used for parameters that fall outside of the signed area of the packet. Parameters numbered between 63488-64511 are used for rendezvous and other relaying services. Parameters numbered between 64512-65535 are reserved.
由于严格执行HIP参数的顺序（从最低到最高）（见第5.2.1节），现有参数的参数类型值已隔开，以允许将来的协议扩展。编号在0-1023之间的参数用于臀部握手和更新过程，并由签名覆盖。编号在1024-2047之间的参数是保留的。编号在2048-4095之间的参数用于与髋部变换类型相关的参数。编号在4096和（2^16-2^12）61439之间的参数是保留的。编号在61440-62463之间的参数用于签名和签名MAC。编号在62464-63487之间的参数用于数据包签名区域之外的参数。编号在63488-64511之间的参数用于会合和其他中继服务。编号在64512-65535之间的参数是保留的。
The TLV-encoded parameters are described in the following subsections. The type-field value also describes the order of these fields in the packet, except for type values from 2048 to 4095 which are reserved for new transport forms. The parameters MUST be included in the packet such that their types form an increasing order. If the parameter can exist multiple times in the packet, the type value may be the same in consecutive parameters. If the order does not follow this rule, the packet is considered to be malformed and it MUST be discarded.
TLV编码参数在以下小节中描述。类型字段值还描述了这些字段在数据包中的顺序，但2048到4095之间的类型值除外，这些类型值是为新的传输表单保留的。参数必须包含在数据包中，以便其类型形成递增顺序。如果参数可以在分组中存在多次，则类型值可以在连续参数中相同。如果顺序不符合此规则，则认为数据包格式不正确，必须将其丢弃。
Parameters using type values from 2048 up to 4095 are transport formats. Currently, one transport format is defined: the ESP transport format [RFC5202]. The order of these parameters does not follow the order of their type value, but they are put in the packet in order of preference. The first of the transport formats it the most preferred, and so on.
从2048到4095使用类型值的参数是传输格式。目前，定义了一种传输格式：ESP传输格式[RFC5202]。这些参数的顺序并不遵循其类型值的顺序，而是按照首选顺序放入数据包中。它最喜欢的第一种传输格式，等等。
All of the TLV parameters have a length (including 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 becomes 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字节的倍数。此规则确保数据的正确对齐。任何添加的填充字节必须由发送方归零，接收方不应检查其值。
Consequently, the Length field indicates the length of the Contents field (in bytes). 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. Contents Parameter specific, defined by Type Padding Padding, 0-7 bytes, added if needed
输入参数的类型代码。16位长，C位是类型代码的一部分。C至关重要。如果此参数很关键，并且必须由收件人识别，则为1，否则为0。C位被视为类型字段的一部分。因此，临界参数总是奇数，而非临界参数的值是偶数。内容的长度，以字节为单位。特定于Contents参数，由类型填充定义，0-7字节，如果需要添加
Critical parameters 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 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.
1. 类型代码的低阶位C用于区分关键参数和非关键参数。
2. A new parameter may be critical only if an old recipient ignoring 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. 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 128 Length 12 R1 generation counter The current generation of valid puzzles
输入128长度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 is supposed to 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位无符号整数，表示当前生成的有效拼图。发送方应该定期递增此计数器。建议计数器值的增加频率至少与旧的拼图值的增加频率相同，以便不再接受它们的解决方案。
The R1_COUNTER parameter 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 MAY be echoed (including the Reserved field verbatim) by the Initiator in the I2.
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, 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, 8 bytes |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 257 Length 12 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
Type 257 Length 12 K K是响应程序设置的验证位生存期谜题生存期2^（值-32）秒不透明数据集的数量，为谜题随机#I随机数编制索引
Random #I is represented as a 64-bit integer, K and Lifetime as 8-bit integers, all in network byte order.
随机#I表示为64位整数，K和生存期表示为8位整数，均按网络字节顺序。
The PUZZLE parameter contains the puzzle difficulty K and a 64-bit puzzle 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, allowing the Responder to use the included information as a part of its puzzle processing.
谜题参数包含谜题难度K和64位谜题随机整数#I。谜题生存期表示谜题解决方案有效的时间，并设置发起者在尝试解决谜题时不应超过的时间限制。使用公式2^（寿命-32）秒将寿命表示为2的幂。可以使用R1中包括的ECHO_请求_签名或ECHO_请求_未签名参数来增加谜题；然后，echo请求的内容在echo_RESPONSE_SIGNED或echo_RESPONSE_UNSIGNED中回显，从而允许响应者使用包含的信息作为其谜题处理的一部分。
The Opaque and Random #I field 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, 8 bytes |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Puzzle solution #J, 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, 8 bytes |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Puzzle solution #J, 8 bytes |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 321 Length 20 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 Puzzle solution #J random number
类型321长度20 K K是发送时保留为零的验证位数，接收时忽略不透明复制未经修改从接收的拼图参数Random#I Random number拼图解决方案#J Random number复制的验证位数
Random #I and Random #J are represented as 64-bit integers, K as an 8-bit integer, all in network byte order.
Random#I和Random#J表示为64位整数，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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | Public Value Length | Public Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | Public Value Length | Public Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 513 Length length in octets, excluding Type, Length, and padding Group ID defines values for p and g Public Value length of the following Public Value in octets Length Public Value the sender's public Diffie-Hellman key
类型513长度长度（以八位字节为单位），不包括类型、长度和填充组ID定义以下公共值的p和g公共值长度值（以八位字节为单位）长度公共值发送方的公共Diffie Hellman密钥
The following Group IDs have been defined:
已定义以下组ID：
Group Value Reserved 0 384-bit group 1 OAKLEY well-known group 1 2 1536-bit MODP group 3 3072-bit MODP group 4 6144-bit MODP group 5 8192-bit MODP group 6
组值保留0 384位组1 OAKLEY著名组1 2 1536位MODP组3 3072位MODP组4 6144位MODP组5 8192位MODP组6
The MODP Diffie-Hellman groups are defined in [RFC3526]. The OAKLEY well-known group 1 is defined in Appendix E.
[RFC3526]中定义了MODP Diffie-Hellman组。奥克利著名的第1组定义见附录E。
The sender can include at most two different Diffie-Hellman public values in the DIFFIE_HELLMAN parameter. This gives the possibility, e.g., for a server to provide a weaker encryption possibility for a PDA host that is not powerful enough. It is RECOMMENDED that the Initiator, receiving more than one public value, selects the stronger one, if it supports it.
发送方在Diffie_Hellman参数中最多可以包含两个不同的Diffie Hellman公共值。这提供了一种可能性，例如，服务器为功能不够强大的PDA主机提供较弱的加密可能性。建议接收多个公共值的启动器选择一个更强的公共值（如果它支持）。
A HIP implementation MUST implement Group IDs 1 and 3. The 384-bit 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). It
HIP实现必须实现组ID 1和3。384位组可在安全性较低（例如，网上冲浪）和设备功能不足（例如，某些PDA）时使用。信息技术
is REQUIRED that the default configuration allows Group ID 1 usage, but it is RECOMMENDED that applications that need stronger security turn Group ID 1 support off. Equipment powerful enough SHOULD implement also Group ID 5. The 384-bit group is defined in Appendix D.
要求默认配置允许使用组ID 1，但建议需要更高安全性的应用程序关闭组ID 1支持。足够强大的设备也应实现组ID 5。384位组的定义见附录D。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #1 | Suite ID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #1 | Suite ID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suite ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 577 Length length in octets, excluding Type, Length, and padding Suite ID defines the HIP Suite to be used
类型577长度以八位字节为单位，不包括类型、长度和填充套件ID，用于定义要使用的髋部套件
The following Suite IDs are defined ([RFC4307],[RFC2451]):
定义了以下套件ID（[RFC4307]、[RFC2451]）：
Suite ID Value
套件ID值
RESERVED 0 AES-CBC with HMAC-SHA1 1 3DES-CBC with HMAC-SHA1 2 3DES-CBC with HMAC-MD5 3 BLOWFISH-CBC with HMAC-SHA1 4 NULL-ENCRYPT with HMAC-SHA1 5 NULL-ENCRYPT with HMAC-MD5 6
保留0 AES-CBC和HMAC-SHA1 3DES-CBC和HMAC-SHA1 3DES-CBC和HMAC-MD5 3河豚-CBC和HMAC-SHA1 4空加密和HMAC-SHA1 5空加密和HMAC-MD5 6
The sender of a HIP_TRANSFORM parameter MUST make sure that there are no more than six (6) HIP Suite IDs in one HIP_TRANSFORM parameter. Conversely, a recipient MUST be prepared to handle received transport parameters that contain more than six Suite IDs by accepting the first six Suite IDs and dropping the rest. The limited number of transforms sets the maximum size of HIP_TRANSFORM parameter. As the default configuration, the HIP_TRANSFORM parameter MUST contain at least one of the mandatory Suite IDs. There MAY be a configuration option that allows the administrator to override this default.
HIP_变换参数的发送方必须确保一个HIP_变换参数中的HIP Suite ID不超过六（6）个。相反，接收者必须准备好处理接收到的包含六个以上套件ID的传输参数，方法是接受前六个套件ID并删除其余的套件ID。有限数量的变换设置HIP_变换参数的最大大小。作为默认配置，HIP_TRANSFORM参数必须至少包含一个必需的套件ID。可能存在允许管理员覆盖此默认值的配置选项。
The Responder lists supported and desired Suite IDs in order of preference in the R1, up to the maximum of six Suite IDs. The Initiator MUST choose only one of the corresponding Suite IDs. That Suite ID will be used for generating the I2.
响应者在R1中按优先顺序列出支持的和需要的套件ID，最多六个套件ID。启动器必须只选择一个相应的套件ID。该套件ID将用于生成I2。
Mandatory implementations: AES-CBC with HMAC-SHA1 and NULL-ENCRYPTION with HMAC-SHA1.
强制实现：使用HMAC-SHA1的AES-CBC和使用HMAC-SHA1的空加密。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 FQDN or NAI in octets Host Identity actual Host Identity Domain Identifier the identifier of the sender
类型705长度八位字节长度，不包括类型、长度和填充八位字节主机标识的HI长度以下域标识符的DI类型字段DI长度FQDN或NAI八位字节主机标识的长度实际主机标识域标识符发送方的标识符
The Host Identity is represented in RFC 4034 [RFC4034] format. The algorithms used in RDATA format are the following:
主机标识以RFC 4034[RFC4034]格式表示。RDATA格式中使用的算法如下：
Algorithms Values
算法值
RESERVED 0 DSA 3 [RFC2536] (RECOMMENDED) RSA/SHA1 5 [RFC3110] (REQUIRED)
保留0 DSA 3[RFC2536]（推荐）RSA/SHA1 5[RFC3110]（必需）
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完全限定域名，二进制格式。网络访问标识符
The format for the FQDN is defined in RFC 1035 [RFC1035] Section 3.1. The format for NAI is defined in [RFC4282]
FQDN的格式在RFC 1035[RFC1035]第3.1节中定义。NAI的格式在[RFC4282]中定义
If there is no Domain Identifier, i.e., the DI-type field is zero, the DI Length field is set to zero as well.
如果没有域标识符，即DI类型字段为零，则DI长度字段也设置为零。
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 HMAC 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，不包括HMAC参数和任何以下参数，如HIP_签名、HIP_签名、ECHO_请求_未签名或ECHO_响应_未签名。校验和字段必须设置为零，并且在计算HMAC时，必须计算HIP公用标头中的HIP标头长度，以不覆盖任何排除的参数。HMAC的大小是散列计算输出的自然大小，具体取决于所使用的散列函数。
The HMAC calculation and verification process is presented in Section 6.4.1.
第6.4.1节介绍了HMAC计算和验证过程。
The parameter structure is the same as in Section 5.2.9. The fields are:
参数结构与第5.2.9节相同。这些字段是：
Type 61569 Length length in octets, excluding Type, Length, and Padding HMAC HMAC computed over the HIP packet, excluding the HMAC 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 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.
类型61569长度以八位字节为单位，不包括通过HIP数据包计算的类型、长度和填充HMAC HMAC，不包括HMAC参数和任何以下参数，如HIP_签名、HIP_签名、ECHO_请求_未签名或ECHO_响应_未签名，并在HMAC计算过程中包括附加发送方的HOST_ID参数。校验和字段必须设置为零，并且在计算HMAC时，必须计算HIP公用标头中的HIP标头长度，以不覆盖任何排除的参数。HMAC的大小是散列计算输出的自然大小，具体取决于所使用的散列函数。
The HMAC calculation and verification process is presented in Section 6.4.1.
第6.4.1节介绍了HMAC计算和验证过程。
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. The checksum field MUST be set to zero, and the HIP header length in the HIP common header MUST be calculated only to the beginning of the HIP_SIGNATURE parameter when the signature is calculated.
类型61697长度长度（以八位字节为单位），不包括类型、长度和填充SIG alg签名算法签名签名签名在HIP数据包上计算签名，不包括HIP_签名参数和HIP_签名参数后面的任何参数。校验和字段必须设置为零，并且在计算签名时，HIP common标头中的HIP标头长度必须仅计算到HIP_签名参数的开头。
The signature algorithms are defined in Section 5.2.8. The signature in the Signature field is encoded using the proper method depending on the signature algorithm (e.g., according to [RFC3110] in case of RSA/SHA1, or according to [RFC2536] in case of DSA).
第5.2.8节定义了签名算法。根据签名算法，使用适当的方法对签名字段中的签名进行编码（例如，对于RSA/SHA1，根据[RFC3110]，对于DSA，根据[RFC2536]）。
The HIP_SIGNATURE calculation and verification process is presented in Section 6.4.2.
HIP_签名计算和验证过程见第6.4.2节。
The parameter structure is the same as in Section 5.2.11. The fields are:
参数结构与第5.2.11节相同。这些字段是：
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 follows the process 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 quantity, initialized by a host to zero upon moving to ESTABLISHED state. The Update ID has scope within a single HIP association, and not across 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的作用域在单个HIP关联中，而不是跨多个关联或多个主机。更新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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 449 Length variable (multiple of 4) peer Update ID 32-bit sequence number corresponding to the Update ID being ACKed.
键入449长度变量（4的倍数）对等更新ID 32位序列号，对应于正在确认的更新ID。
The ACK parameter includes one or more Update IDs that have been received from the peer. The Length field identifies the number of peer Update IDs that are present in the parameter.
ACK参数包括从对等方接收到的一个或多个更新ID。长度字段标识参数中存在的对等更新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 IV Initialization vector, if needed, otherwise nonexistent. The length of the IV is inferred from the HIP transform. Encrypted The data is encrypted using an encryption algorithm data as defined in HIP transform.
输入641长度八位字节，不包括类型、长度和填充，发送时保留零，接收IV初始化向量时忽略，如果需要，否则不存在。IV的长度由髋部变换推断。加密使用HIP transform中定义的加密算法对数据进行加密。
The ENCRYPTED parameter encapsulates another parameter, 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 labelled "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 [FIPS01] 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 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[FIPS01]使用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 the NOTIFY packet type. 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 addition Data to the Notify Message Type. Values for this field are type specific (see below). Padding any Padding, if necessary, to make the parameter a multiple of 8 bytes.
类型832长度以八位字节为单位，不包括类型、长度和填充，发送时保留零，接收时忽略通知消息指定通知类型的类型除了通知消息类型的数据外，还发送通知信息或错误数据。此字段的值是特定于类型的（见下文）。填充任何填充，如有必要，使参数为8字节的倍数。
Notification information can be error messages specifying why an SA could not be established. It can also be status data that a process managing an SA database wishes to communicate with a peer process. The table below lists the Notification messages and their corresponding values.
通知信息可以是错误消息，指定无法建立SA的原因。它也可以是管理SA数据库的进程希望与对等进程通信的状态数据。下表列出了通知消息及其相应的值。
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.
为了避免某些类型的攻击，响应者应该避免向任何未成功验证谜题解决方案的主机发送通知。
Types in the range 0-16383 are intended for reporting errors and in the range 16384-65535 for other status information. An implementation that receives a NOTIFY packet with a NOTIFICATION error parameter in response to a request 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.
0-16383范围内的类型用于报告错误，16384-65535范围内的类型用于报告其他状态信息。接收带有通知错误参数的通知包以响应请求包（例如，I1、I2、UPDATE）的实现应假设相应的请求已完全失败。必须忽略无法识别的错误类型，但应记录它们。
Notify payloads with status types MUST be ignored if not recognized.
如果无法识别，则必须忽略状态类型为的通知有效负载。
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
NOTIFICATION PARAMETER - ERROR TYPES 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 rejected for policy reasons. To avoid a denial-of-service attack using forged messages, this status may only be returned for packets whose HMAC (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消息无效，因为某些类型、长度或值超出范围，或者由于策略原因请求被拒绝。为了避免使用伪造消息的拒绝服务攻击，只有其HMAC（如果存在）和签名已被验证的数据包才能返回此状态。此状态必须发送以响应其他状态类型之一未包含的任何错误，并且不应包含详细信息，以避免将信息泄漏给探测节点的人。为了帮助调试，应将更详细的错误信息写入控制台或日志。
NO_DH_PROPOSAL_CHOSEN 14
未选择任何方案14
None of the proposed group IDs was acceptable.
所有提议的组ID均不可接受。
INVALID_DH_CHOSEN 15
无效的_DH_选择15
The D-H Group ID field does not correspond to one offered by the Responder.
D-H组ID字段与响应者提供的字段不对应。
NO_HIP_PROPOSAL_CHOSEN 16
没有选择HIP提案16
None of the proposed HIP Transform crypto suites was acceptable.
提议的HIP变换加密套件均不可接受。
INVALID_HIP_TRANSFORM_CHOSEN 17
无效的\u HIP\u转换\u选择17
The HIP Transform crypto suite does not correspond to one offered by the Responder.
HIP Transform加密套件与响应者提供的套件不一致。
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校验和失败而发送。
HMAC_FAILED 28
HMAC_失败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., received HIT is NULL and policy does not allow opportunistic mode).
由于某些策略原因，响应者不愿意建立关联（例如，收到的命中为空，策略不允许机会主义模式）。
SERVER_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 MESSAGES - STATUS TYPES Value
------------------------------ -----
NOTIFY MESSAGES - STATUS TYPES Value
------------------------------ -----
I2_ACKNOWLEDGEMENT 16384
I2_确认16384
The Responder has an I2 from the Initiator but had to queue the I2 for processing. The puzzle was correctly solved and the Responder is willing to set up an association but currently has a number of I2s in the processing queue. R2 will be sent after the I2 has been 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 variable 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_响应_签名或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 HMAC and SIGNATURE. A HIP packet can contain only one ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED parameter. The ECHO_REQUEST_SIGNED parameter MUST be responded to with a corresponding echo response. ECHO_RESPONSE_SIGNED SHOULD be used, but if it is not possible, e.g., due to a middlebox-provided response, it MAY be responded to with an ECHO_RESPONSE_UNSIGNED.
ECHO_请求_签名和相应的ECHO响应参数可用于任何目的，其中节点希望在请求分组中携带某些状态并在响应分组中获取该状态。HMAC和签名包含已签名的回音请求。HIP数据包只能包含一个ECHO\u REQUEST\u SIGNED或ECHO\u REQUEST\u UNSIGNED参数。必须用相应的ECHO响应响应ECHO_REQUEST_SIGNED参数。应使用ECHO_-RESPONSE_-SIGNED，但如果不可能，例如，由于中间盒提供的响应，则可以使用ECHO_-RESPONSE_-SIGNED进行响应。
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 variable 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_请求_UNSIGNED并接收相应ECHO_响应_UNSIGNED的节点有意义。
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 HMAC 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 sender 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参数可用于任何目的，其中节点希望在请求数据包中携带某些状态并将其返回到响应数据包中。HMAC和签名不包括未签名的回音请求。HIP数据包可以包含一个或多个ECHO\u REQUEST\u无符号参数。中间盒可能会在经过的HIP数据包中添加ECHO_REQUEST_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 variable Opaque data opaque data, copied unmodified from the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED parameter that triggered this response.
键入961长度变量不透明数据不透明数据，未经修改地从触发此响应的ECHO_REQUEST_SIGNED或ECHO_REQUEST_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 HMAC and SIGNATURE.
ECHO_REQUEST_SIGNED和ECHO_RESPONSE_SIGNED参数可用于任何目的，其中节点希望在请求数据包中携带某些状态并将其返回到响应数据包中。HMAC和签名涵盖了签名的回声响应。
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 variable Opaque data opaque data, copied unmodified from the ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED parameter that triggered this response.
键入63425长度可变不透明数据不透明数据，未经修改地从触发此响应的ECHO_REQUEST_SIGNED或ECHO_REQUEST_UNSIGNED参数复制。
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 HMAC and SIGNATURE.
echo request和echo_RESPONSE_UNSIGNED参数可用于节点希望在请求数据包中携带某种状态并在响应数据包中获取该状态的任何目的。HMAC和签名不包括未签名的回声响应。
There are eight basic HIP packets (see Table 10). Four are for the HIP base exchange, one is for updating, one is for sending notifications, and two are for closing a HIP association.
有八种基本的髋关节包（见表10）。四个用于HIP base exchange，一个用于更新，一个用于发送通知，两个用于关闭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 10: HIP packets and packet type numbers
表10：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 will be defined later in separate specifications. For example, support for mobility and multi-homing is not included in this specification.
除了基本分组之外，其他分组类型将在稍后的单独规范中定义。例如，本规范不包括对移动性和多归属的支持。
See Notation (Section 2.2) for used 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. This limits the size of the possible additional data in the packet.
将来，可选的上层有效载荷可能会跟随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 () )
IP（HIP（））
The I1 packet contains only the fixed HIP header.
I1数据包仅包含固定HIP报头。
Valid control bits: none
有效控制位：无
The Initiator gets the Responder's HIT either from a DNS lookup of the Responder's FQDN, from some other repository, or from 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.6).
发起程序从响应程序的FQDN的DNS查找、其他存储库或本地表中获取响应程序的命中。如果发起者不知道响应者的命中，它可能会尝试使用机会模式，使用NULL（全零）作为响应者的命中。另见“髋关节机会主义模式”（第4.1.6节）。
Since this packet is so easy to spoof even if it were signed, no attempt is made to add to its generation or processing cost.
由于此数据包即使经过签名也很容易被欺骗，因此不会试图增加其生成或处理成本。
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_TRANSFORM, HOST_ID, [ ECHO_REQUEST_SIGNED, ] HIP_SIGNATURE_2 ) <, ECHO_REQUEST_UNSIGNED >i)
IP（HIP（[R1\u计数器，]PUZZLE，DIFFIE\u HELLMAN，HIP\u变换，主机ID，[ECHO\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 I1. If the Responder has multiple HIs, the Responder's HIT used MUST match 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.6).
启动器的命中必须与I1中接收到的命中匹配。如果响应者有多个HI，则响应者使用的HIT必须与启动器的请求相匹配。如果发起者使用机会主义模式，响应者可以在其HI中自由选择。另见“髋关节机会主义模式”（第4.1.6节）。
The R1 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 just prior sending it to the peer.
该拼图包含一个随机#I和难度K。难度K表示拼图哈希结果中必须为零的低阶比特数；见第4.1.2节。随机#I不在签名范围内，必须在签名计算期间归零，允许发送方在将其发送给对等方之前选择并将#I设置为预计算的R1。
The Diffie-Hellman value is ephemeral, and one value SHOULD be used only for one connection. Once the Responder has received a valid response to an R1 packet, that Diffie-Hellman value SHOULD be deprecated. Because it is possible that the Responder has sent the same Diffie-Hellman value to different hosts simultaneously in corresponding R1 packets, those responses should also be accepted. However, as a defense against I1 storms, an implementation MAY propose, and re-use if not 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值是短暂的，一个值只能用于一个连接。一旦响应程序接收到对R1数据包的有效响应，应该弃用Diffie-Hellman值。因为响应者可能在相应的R1数据包中同时向不同的主机发送了相同的Diffie-Hellman值，所以这些响应也应该被接受。然而，作为对I1风暴的防御，一个实现可能会提出相同的Diffie-Hellman值，并在一段时间内重复使用，例如15分钟。通过对给定的Diffie-Hellman值使用少量不同的谜题，R1数据包可以在I1数据包到达时进行预计算和交付。清除程序应该清除未使用的Diffie-Hellman值和谜题。
Re-using Diffie-Hellman public keys 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 re-using the same key 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 re-use of any given Responder Diffie-Hellman public key would differ from the base probability. Consequently, it is RECOMMENDED that implementations avoid re-using the same D-H key with multiple Initiators, but because the risk is considered statistical and not
然而，重复使用同一密钥所涉及的这些风险是统计性的；也就是说，作者不知道任何机制会允许操纵协议，从而使任何给定响应者Diffie-Hellman公钥的重复使用风险与基本概率不同。因此，建议实现避免在多个启动器中重复使用同一个D-H密钥，但这是因为风险被认为是统计的，而不是统计的
known to be manipulable, the implementations MAY re-use a key in order to ease resource-constrained implementations and to increase the probability of successful communication with legitimate clients even under an I1 storm. In particular, when it is too expensive to generate enough precomputed R1 packets to supply each potential Initiator with a different D-H key, the Responder MAY send the same D-H 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 D-H key, it SHOULD stop offering it. This design is aimed to allow resource-constrained Responders to offer services under I1 storms and to simultaneously make the probability of D-H key re-use both statistical and as low as possible.
已知是可操作的，这些实现可以重用密钥，以便简化资源受限的实现，并增加即使在I1风暴下与合法客户端成功通信的概率。特别地，当生成足够的预计算R1分组以向每个潜在的发起方提供不同的D-H密钥过于昂贵时，响应方可以向多个发起方发送相同的D-H密钥，从而产生多个合法发起方最终使用相同的响应方公钥的可能性。但是，一旦响应者知道它将使用特定的D-H密钥，它就应该停止提供该密钥。该设计旨在允许资源受限的响应者在I1风暴下提供服务，同时使D-H密钥重复使用的概率在统计上尽可能低。
If a future version of this protocol is considered, we strongly recommend that these issues be studied again. Especially, the current design allows hosts to become potentially more vulnerable to a statistical, low-probability problem during I1 storm attacks than what they are if no attack is taking place; whether this is acceptable or not should be reconsidered in the light of any new experience gained.
如果考虑本协议的未来版本，我们强烈建议再次研究这些问题。特别是，当前的设计允许主机在I1风暴攻击期间比在没有发生攻击时更容易受到统计上的低概率问题的攻击；这是否可以接受，应根据获得的任何新经验重新考虑。
The HIP_TRANSFORM contains the encryption and integrity algorithms supported by the Responder to protect the HI exchange, in the order of preference. All implementations MUST support the AES [RFC3602] with HMAC-SHA-1-96 [RFC2404].
HIP_变换包含响应程序支持的加密和完整性算法，以按优先顺序保护HI交换。所有实施必须支持AES[RFC3602]和HMAC-SHA-1-96[RFC2404]。
The ECHO_REQUEST_SIGNED and ECHO_REQUEST_UNSIGNED contains data that the sender wants to receive unmodified in the corresponding response packet in the ECHO_RESPONSE_SIGNED or ECHO_RESPONSE_UNSIGNED parameter.
ECHO_-REQUEST_-SIGNED和ECHO_-REQUEST_-UNSIGNED包含发送方希望在ECHO_-response_-SIGNED或ECHO_-response_-UNSIGNED参数的相应响应数据包中未经修改地接收的数据。
The signature is calculated over the whole HIP envelope, after setting the Initiator's HIT, header checksum, as well as the Opaque field and the Random #I in the PUZZLE parameter temporarily to zero, and excluding any parameters that follow the signature, as described in Section 5.2.12. This allows the Responder to use precomputed R1s. The Initiator SHOULD validate this signature. It SHOULD check that the Responder's HI received matches with the one expected, if any.
如第5.2.12节所述，在将发起人的命中、报头校验和以及谜题参数中的不透明字段和随机#I临时设置为零并排除签名后的任何参数后，在整个臀部信封上计算签名。这允许响应者使用预计算的R1s。发起人应验证此签名。它应该检查响应者的HI是否与预期的HI匹配（如果有）。
The HIP header values for the I2 packet:
I2数据包的HIP标头值：
Header: 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_TRANSFORM, ENCRYPTED { HOST_ID } or HOST_ID, [ ECHO_RESPONSE_SIGNED ,] HMAC, HIP_SIGNATURE <, ECHO_RESPONSE_UNSIGNED>i ) )
IP（HIP（[R1_计数器，]解决方案，DIFFIE_HELLMAN，HIP_变换，加密的{HOST_ID}或HOST_ID，[ECHO_-RESPONSE_-SIGNED，]HMAC，HIP_-SIGNATURE<，ECHO_-RESPONSE_-UNSIGNED>i））
Valid control bits: A
有效控制位：A
The HITs used MUST match the ones used previously.
使用的点击数必须与以前使用的匹配。
If the Initiator's HI is an anonymous one, the A control MUST be set.
如果启动器的HI是匿名的，则必须设置A控件。
The Initiator MAY include an unmodified copy of the R1_COUNTER parameter received in the corresponding R1 packet into the I2 packet.
启动器可将在相应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 re-use Diffie-Hellman values under some conditions as specified in Section 5.3.2.
Diffie-Hellman值是短暂的。如果预先计算，清道夫进程应该清理未使用的Diffie-Hellman值。响应者可在第5.3.2节规定的某些条件下重新使用Diffie-Hellman值。
The HIP_TRANSFORM contains the single encryption and integrity transform selected by the Initiator, that will be used to protect the HI exchange. The chosen transform MUST correspond to one offered by the Responder in the R1. All implementations MUST support the AES transform [RFC3602].
HIP_转换包含启动器选择的单个加密和完整性转换，用于保护HI交换。所选转换必须与R1中响应程序提供的转换相对应。所有实现必须支持AES转换[RFC3602]。
The Initiator's HI MAY be encrypted using the HIP_TRANSFORM encryption algorithm. The keying material is derived from the Diffie-Hellman exchanged 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.
ECHO_RESPONSE_SIGNED和ECHO_RESPONSE_UNSIGNED包含从相应ECHO请求参数复制的未修改的不透明数据。
The HMAC is calculated over the whole HIP envelope, excluding any parameters after the HMAC, as described in Section 6.4.1. The Responder MUST validate the HMAC.
如第6.4.1节所述，HMAC在整个髋部包络线上计算，不包括HMAC后的任何参数。响应者必须验证HMAC。
The signature is calculated over the whole HIP envelope, excluding any parameters after the HIP_SIGNATURE, as described in Section 5.2.11. The Responder MUST validate this signature. It MAY use either the HI in the packet or the HI acquired by some other means.
如第5.2.11节所述，签名在整个髋关节包络上计算，不包括髋关节签名后的任何参数。响应者必须验证此签名。它可以使用分组中的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 ( HMAC_2, HIP_SIGNATURE ) )
IP（HIP（HMAC_2，HIP_签名））
Valid control bits: none
有效控制位：无
The HMAC_2 is calculated over the whole HIP envelope, with Responder's HOST_ID parameter concatenated with the HIP envelope. The HOST_ID parameter is removed after the HMAC calculation. The procedure is described in Section 6.4.1.
HMAC_2在整个髋部包络上计算，响应者的HOST_ID参数与髋部包络连接。主机ID参数在HMAC计算后删除。第6.4.1节描述了该程序。
The signature is calculated over the whole HIP envelope.
签名是在整个臀部信封上计算的。
The Initiator MUST validate both the HMAC and the signature.
发起人必须验证HMAC和签名。
Support for the UPDATE packet is MANDATORY.
必须支持更新数据包。
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, ] HMAC, HIP_SIGNATURE ) )
IP（HIP（[顺序，确认，]HMAC，HIP_签名））
Valid control bits: None
有效控制位：无
The UPDATE packet contains mandatory HMAC and HIP_SIGNATURE parameters, and other optional parameters.
更新数据包包含必需的HMAC和HIP_签名参数以及其他可选参数。
The UPDATE packet contains zero or one SEQ parameter. The presence of a SEQ parameter indicates that the receiver MUST ACK the UPDATE. An UPDATE that does not contain a SEQ parameter is simply an ACK of a previous UPDATE and itself MUST NOT be ACKed.
更新数据包包含零个或一个SEQ参数。SEQ参数的存在表示接收器必须确认更新。不包含SEQ参数的更新只是对以前更新的确认，不能对其本身进行确认。
An UPDATE packet contains zero or one ACK parameters. The ACK parameter echoes the SEQ sequence number of the UPDATE packet being ACKed. A host MAY choose to ACK more than one UPDATE packet at a time; e.g., the ACK may contain the last two SEQ values received, for robustness to ACK loss. ACK values are not cumulative; each received unique SEQ value requires at least one corresponding ACK value in reply. Received ACKs that are redundant are ignored.
更新数据包包含零个或一个ACK参数。ACK参数回显正在确认的更新包的SEQ序列号。主机可以选择一次确认多个更新分组；e、 例如，为了对ACK丢失的鲁棒性，ACK可以包含接收到的最后两个SEQ值。ACK值不是累积的；每个收到的唯一SEQ值都需要至少一个对应的ACK值作为应答。接收到的冗余ACK将被忽略。
The UPDATE packet may contain both a SEQ and an ACK parameter. In this case, the ACK 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 ACK 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 forgo 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.
发送方可以选择放弃特定更新的可靠传输（例如，它会被事件所克服）。语义是这样的，接收方必须确认更新，但发送方可以选择不关心接收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 is OPTIONAL. 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 (Section 4.4.1) based purely on a received NOTIFY packet.
NOTIFY数据包是可选的。通知分组可用于向对等方提供信息。通常，NOTIFY用于指示某种类型的协议错误或协商失败。通知数据包未被确认。接收方只能将数据包作为信息处理，不应纯粹根据接收到的NOTIFY数据包更改其HIP状态（第4.4.1节）。
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, HMAC, HIP_SIGNATURE ) )
IP（HIP（回声请求签名、HMAC签名、HIP签名））
Valid control bits: none
有效控制位：无
The sender MUST include an ECHO_REQUEST_SIGNED used to validate CLOSE_ACK received in response, and both an HMAC and a signature (calculated over the whole HIP envelope).
发送方必须包括用于验证响应中接收到的关闭确认的签名回音请求，以及HMAC和签名（在整个HIP信封上计算）。
The receiver peer MUST validate both the HMAC and the signature if it has a HIP association state, and MUST reply with a CLOSE_ACK containing an ECHO_RESPONSE_SIGNED corresponding to the received ECHO_REQUEST_SIGNED.
接收方对等方必须验证HMAC和签名（如果其具有HIP关联状态），并且必须使用CLOSE_ACK（包含与接收到的ECHO_签名请求相对应的ECHO_签名响应）进行回复。
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, HMAC, HIP_SIGNATURE ) )
IP（HIP（回声响应签名、HMAC签名、HIP签名））
Valid control bits: none
有效控制位：无
The sender MUST include both an HMAC and signature (calculated over the whole HIP envelope).
发件人必须同时包含HMAC和签名（在整个信封上计算）。
The receiver peer MUST validate both the HMAC and the signature.
接收方对等方必须验证HMAC和签名。
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 [RFC2463]. In most cases, the ICMP packet will have the Parameter Problem type (12 for ICMPv4, 4 for ICMPv6), with the Pointer field pointing to the field that caused the ICMP message to be generated.
当HIP实现检测到传入数据包的问题，并且它不能确定数据包发送方的身份或者与数据包发送方没有任何现有的HIP关联时，它可以使用ICMP数据包进行响应。任何此类回复必须按照[RFC2463]中所述的速率限制。在大多数情况下，ICMP数据包将具有参数问题类型（ICMPv4为12，ICMPv6为4），指针字段指向导致生成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, the Pointer pointing to the VER./RES. byte in the HIP header.
如果HIP实现接收到具有无法识别的HIP版本号的HIP数据包，它应以速率受限的方式响应具有类型参数问题的ICMP数据包，指针指向HIP标头中的版本/资源字节。
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, 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, 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 of bytes from the I2 message so that the SOLUTION parameter fits into the ICMP message, the Pointer pointing to the beginning of the Puzzle solution #J
如果使用IPv4，则实现可能会响应带有类型参数问题的ICMP数据包，从I2消息复制足够的字节，以便解决方案参数适合ICMP消息，指针指向谜题解决方案的开头
field, as in the IPv6 case. Note, however, that the resulting ICMPv4 message exceeds the typical ICMPv4 message size as defined in [RFC0792].
字段，如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, and with the Pointer pointing to the beginning of the first HIT that does not match.
如果HIP实现接收到CLOSE或UPDATE数据包，或其处理需要现有关联的任何其他数据包，该数据包的接收方或发送方命中与任何现有HIP关联不匹配，则该实现可能会以速率受限的方式响应具有类型参数问题的ICMP数据包，指针指向不匹配的第一次点击的开始。
A host MUST NOT reply with such an ICMP if it receives any of the following messages: I1, R2, I2, R2, and NOTIFY. 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 protocol 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 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关联并处理新关联的请求。每个髋关节关联由一个概念状态机控制，状态定义见上文第4.4节。HIP实现可以同时维护与多个主机的HIP关联。此外，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 [HIP-APP]), using identifiers that look similar to IP addresses, or a completely new API, providing enhanced
在HIP主机中，应用程序可以使用通过底层API指定的标识符发送应用程序级数据。该API可以是向后兼容的API（参见[HIP-APP]），使用看起来类似于IP地址的标识符，也可以是一个全新的API，提供增强的
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实现，提供给应用程序的标识符可能不同；例如，它可以是HIT或IP地址。
The exact format and method for transferring the data from the source HIP host to the destination HIP host is 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 multi-homing case will be 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.
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 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 [RFC3484] 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，应遵循[RFC3484]中定义的规则。注意，该命中到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 HIT) is used as the higher-layer identifier, the verification method has to verify that the data packet was sent by a node identity and that the actual identity maps to this particular HIT. When using ESP transport format [RFC5202], 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传输格式[RFC5202]时，使用数据包中的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. When demultiplexing the datagram, the right upper-layer socket is based on the HITs.
4. 数据报被传送到上层。当解复用数据报时，右上层套接字基于命中数。
This subsection describes the puzzle-solving details.
本小节描述了解谜的细节。
In R1, the values I and K are sent in network byte order. Similarly, in I2, 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算法，按网络字节顺序，按以下顺序连接以下数据而创建的：
64-bit random value I, in network byte order, as appearing in R1 and I2.
64位随机值I，按网络字节顺序，如R1和I2所示。
128-bit Initiator's HIT, in network byte order, as appearing in the HIP Payload in R1 and I2.
128位启动器的命中，按网络字节顺序，如R1和I2中的HIP有效负载所示。
128-bit Responder's HIT, in network byte order, as appearing in the HIP Payload in R1 and I2.
128位响应器的命中，按网络字节顺序，如R1和I2中的HIP有效载荷中所示。
64-bit random value J, in network byte order, as appearing in I2.
64位随机值J，按网络字节顺序，如I2所示。
In order to be 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 48 bytes.
i) 要散列的数据长度为48字节。
ii) All the data in the hash input MUST be in network byte order.
ii）散列输入中的所有数据必须按网络字节顺序排列。
iii) The order 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节。必须注意以正确的顺序将值复制到哈希输入。
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
Accept 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
Accept if V == 0
The following subsections define the actions for processing HMAC, HIP_SIGNATURE and HIP_SIGNATURE_2 parameters.
以下小节定义了处理HMAC、HIP_签名和HIP_签名_2参数的操作。
The following process applies both to the HMAC and HMAC_2 parameters. When processing HMAC_2, the difference is that the HMAC calculation includes a pseudo HOST_ID field containing the Responder's information as sent in the R1 packet earlier.
以下过程适用于HMAC和HMAC_2参数。当处理HMAC_2时，区别在于HMAC计算包括一个伪主机ID字段，其中包含先前在R1数据包中发送的响应者信息。
Both the Initiator and the Responder should take some care when verifying or calculating the HMAC_2. Specifically, the Responder should preserve other parameters than the HOST_ID when sending the R2. Also, the Initiator has to preserve the HOST_ID exactly as it was received in the R1 packet.
在验证或计算HMAC_2时，发起者和响应者都应小心。具体来说，响应程序在发送R2时应保留主机ID以外的其他参数。此外，发起者必须保留主机ID，与R1数据包中接收到的主机ID完全相同。
The scope of the calculation for HMAC and HMAC_2 is:
HMAC和HMAC_2的计算范围为：
HMAC: { HIP header | [ Parameters ] }
HMAC: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters of the packet that is being calculated with Type values from 1 to (HMAC's Type value - 1) and exclude parameters with Type values greater or equal to HMAC's Type value.
其中，参数包括使用类型值从1到（HMAC的类型值-1）计算的数据包的所有HIP参数，并排除类型值大于或等于HMAC的类型值的参数。
During HMAC calculation, the following applies:
在HMAC计算期间，以下各项适用：
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 HMAC parameter.
o 在HIP header中，header Length字段值计算到HMAC参数的开头。
Parameter order is described in Section 5.2.1.
第5.2.1节描述了参数顺序。
HMAC_2: { HIP header | [ Parameters ] | HOST_ID }
HMAC_2: { HIP header | [ Parameters ] | HOST_ID }
where Parameters include all HIP parameters for the packet that is being calculated with Type values from 1 to (HMAC_2's Type value - 1) and exclude parameters with Type values greater or equal to HMAC_2's Type value.
其中，参数包括使用类型值从1到（HMAC_2的类型值-1）计算的数据包的所有HIP参数，并排除类型值大于或等于HMAC_2的类型值的参数。
During HMAC_2 calculation, the following applies:
在HMAC_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 HMAC_2 parameter and added to the length of the concatenated HOST_ID parameter length.
o 在HIP标头中，标头长度字段值计算到HMAC_2参数的开头，并添加到连接的HOST_ID参数长度的长度中。
o 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 HMAC parameter is defined in Section 5.2.9 and the HMAC_2 parameter in Section 5.2.10. The HMAC calculation and verification process (the process applies both to HMAC and HMAC_2 except where HMAC_2 is mentioned separately) is as follows:
第5.2.9节定义了HMAC参数，第5.2.10节定义了HMAC_2参数。HMAC计算和验证过程（该过程适用于HMAC和HMAC_2，除非单独提及HMAC_2），如下所示：
Packet sender:
数据包发送方：
1. Create the HIP packet, without the HMAC, HIP_SIGNATURE, HIP_SIGNATURE_2, or any other parameter with greater Type value than the HMAC parameter has.
1. 创建HIP数据包，不带HMAC、HIP_签名、HIP_签名或任何其他类型值大于HMAC参数的参数。
2. In case of HMAC_2 calculation, add a HOST_ID (Responder) parameter to the end of the packet.
2. 在HMAC_2计算的情况下，在数据包的末尾添加一个HOST_ID（Responder）参数。
3. Calculate the Header Length field in the HIP header including the added HOST_ID parameter in case of HMAC_2.
3. 在HMAC_2的情况下，计算HIP标头中的标头长度字段，包括添加的HOST_ID参数。
4. Compute the HMAC using either 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 HMAC_2, remove the HOST_ID parameter from the packet.
5. 在HMAC_2的情况下，从数据包中删除HOST_ID参数。
6. Add the HMAC parameter to the packet and any parameter with greater Type value than the HMAC's (HMAC_2's) that may follow, including possible HIP_SIGNATURE or HIP_SIGNATURE_2 parameters
6. 将HMAC参数添加到数据包中，并添加任何类型值大于随后可能出现的HMAC（HMAC_2）的参数，包括可能的HIP_签名或HIP_签名_2参数
7. Recalculate the Length field in the HIP header.
7. 重新计算髋部标题中的长度字段。
Packet receiver:
数据包接收器：
1. Verify the HIP header Length field.
1. 验证“髋部收割台长度”字段。
2. Remove the HMAC or HMAC_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 will be needed later.
2. 删除HMAC或HMAC_2参数，以及其后具有更大类型值的所有其他参数，包括可能的HIP_签名或HIP_签名_2字段，如果以后需要，则保存内容。
3. In case of HMAC_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. 在HMAC_2的情况下，构建主机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 HMAC_2, the length is calculated with the added HOST_ID parameter.
4. 重新计算HIP标头中的HIP数据包长度并清除校验和字段（将其设置为全零）。对于HMAC_2，使用添加的HOST_ID参数计算长度。
5. Compute the HMAC using either 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 Checksum and Header Length field in the HIP header to original values.
6. 将髋部标题中的校验和和标题长度字段设置为原始值。
7. In case of HMAC_2, remove the HOST_ID parameter from the packet before further processing.
7. 对于HMAC_2，在进一步处理之前，从数据包中删除HOST_ID参数。
The following process applies both to the HIP_SIGNATURE and HIP_SIGNATURE_2 parameters. When processing HIP_SIGNATURE_2, the only difference is that instead of 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.11 and the HIP_SIGNATURE_2 parameter in Section 5.2.12.
以下过程同时应用于HIP_签名和HIP_签名参数。处理HIP_签名_2时，唯一的区别是使用HIP_签名_2参数而不是HIP_签名参数，并且在计算签名之前清除发起人的命中和拼图不透明和随机I字段（设置为全零）。HIP_签名参数在第5.2.11节中定义，HIP_签名参数在第5.2.12节中定义。
The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2 is:
HIP_签名和HIP_签名的计算范围为：
HIP_SIGNATURE: { HIP header | [ Parameters ] }
HIP_SIGNATURE: { HIP header | [ Parameters ] }
where Parameters include all HIP parameters for the packet that is being calculated 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 HIP parameters for the packet that is being calculated with Type values from 1 to (HIP_SIGNATURE_2's Type value - 1).
其中，参数包括使用1到之间的类型值计算的数据包的所有HIP参数（HIP_签名_2的类型值-1）。
During signature calculation, the following apply:
在签名计算过程中，以下各项适用：
o In the HIP header, the Initiator's HIT field and Checksum 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 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节描述了参数顺序。
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):
签名计算和验证过程（该过程适用于HIP_签名和HIP_签名2，单独提及HIP_签名2的情况除外）：
Packet sender:
数据包发送方：
1. Create the HIP packet without the HIP_SIGNATURE parameter or any 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 Initiator's HIT field in the HIP header as well as 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.
1. 验证“髋部收割台长度”字段。
2. Save the contents of the HIP_SIGNATURE parameter and any 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 Initiator's HIT field in HIP header as well as 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 Identifier (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 from a DNS query, if the FQDN has been received in the HOST_ID packet, or one received by some other means.
验证可以使用从HIP数据包接收的HI、从DNS查询接收的HI（如果FQDN已在HOST_ID数据包中接收），也可以使用通过其他方式接收的HI。
HIP keying material is derived from the Diffie-Hellman session key, Kij, produced during the HIP base exchange (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 and the HITs into the following operation; the | operation denotes concatenation.
键盘是通过将Kij和点击输入以下操作得到的；|运算表示串联。
KEYMAT = K1 | K2 | K3 | ... where
KEYMAT=K1 | K2 | K3 |。。。哪里
K1 = RHASH( Kij | sort(HIT-I | HIT-R) | I | J | 0x01 ) K2 = RHASH( Kij | K1 | 0x02 ) K3 = RHASH( Kij | K2 | 0x03 ) ... K255 = RHASH( Kij | K254 | 0xff ) K256 = RHASH( Kij | K255 | 0x00 ) etc.
K1=RHASH（Kij | sort（HIT-I | HIT-R）| I | J | 0x01）K2=RHASH（Kij | K1 | 0x02）K3=RHASH（Kij | K2 | 0x03）。。。K255=RHASH（Kij | K254 | 0xff）K256=RHASH（Kij | K255 | 0x00）等。
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.
排序（HIT-I | HIT-R）定义为两个命中的网络字节顺序串联，较小的命中在较大的命中之前，这是由两个命中的数字比较产生的，这两个命中按网络字节顺序解释为正（无符号）128位整数。
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.
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 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 initial keys:
初始键的绘图顺序为：
HIP-gl encryption key for HOST_g's outgoing HIP packets
主机的传出HIP数据包的HIP gl加密密钥
HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets
主机的传出HIP数据包的HIP gl完整性（HMAC）密钥
HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP packets
主机的传出HIP数据包的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 bits
AES 128位
SHA-1 160 bits
SHA-1 160位
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 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
一个实现可以基于本地策略决策发起到另一个主机的HIP交换，该决策通常由应用程序数据报触发，与IPsec IKE密钥交换的方式大致相同
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.
动态创建安全关联。或者，如第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 contents are specified in Section 5.3.1. The selection of which Host Identity to use, if a host has more than one to choose from, is typically a policy decision.
该实现准备一个I1数据包并将其发送到对应于对等主机的IP地址。对等主机的IP地址可以通过诸如DNS查找之类的常规机制获得。第5.3.1节规定了I1内容。如果一个主机有多个主机可供选择，则选择使用哪个主机标识通常是一项策略决策。
The following steps define the conceptual processing rules for initiating a HIP exchange:
以下步骤定义了启动HIP交换的概念处理规则：
1. The Initiator gets the Responder's HIT and one or more addresses either from a DNS lookup of the Responder's FQDN, from some other repository, or from a local table. 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.6).
1. 启动器从响应程序FQDN的DNS查找、其他存储库或本地表中获取响应程序的HIT和一个或多个地址。如果发起者不知道响应者的命中，它可以尝试机会模式，使用NULL（全零）作为响应者的命中。另见“髋关节机会主义模式”（第4.1.6节）。
2. The Initiator sends an I1 to one of the Responder's addresses. The selection of which address to use is a local policy decision.
2. 发起者向响应者的一个地址发送I1。选择使用哪个地址是当地的政策决定。
3. Upon sending an I1, the sender shall transition to state I1-SENT, start a timer whose timeout value should be larger than the worst-case anticipated RTT, and shall increment a timeout counter associated with the I1.
3. 发送I1后，发送方应转换到状态I1-SENT，启动超时值应大于最坏情况预期RTT的计时器，并应增加与I1相关的超时计数器。
4. Upon timeout, the sender SHOULD retransmit the I1 and restart the timer, up to a maximum of I1_RETRIES_MAX tries.
4. 超时后，发送方应重新传输I1并重新启动计时器，最多可重试I1次。
For the sake of minimizing the session establishment latency, an implementation MAY send the same I1 to more than one of the Responder's addresses. However, it MUST NOT send to more than three (3) 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 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 might happen, e.g., because someone's claim to have hundreds or thousands of addresses could generate a huge number of I1 messages from the Initiator.
为了最小化会话建立延迟，实现可以向响应者的多个地址发送相同的I1。但是，它不能同时发送到三（3）个以上的地址。此外，在超时时，实现必须避免向多个地址发送相同的I1数据包。也就是说，如果在超时后重试初始化连接，则它不能将I1数据包发送到多个目标地址。设置这些限制是为了避免网络拥塞和可能发生的潜在DoS攻击，例如，因为某人声称拥有数百或数千个地址可能会从启动器生成大量I1消息。
As the Responder is not guaranteed to distinguish the duplicate I1s it receives at several of its addresses (because it avoids storing states when it answers back an R1), the Initiator may receive several duplicate R1s.
由于响应方不能保证区分在其多个地址接收到的重复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. 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, it MUST NOT terminate the wait. It MAY continue as if it had not received the ICMP message, and send a few more I1s. 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 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 source address. If the implementation is unwilling to set up a HIP association, the host MAY ignore the I1. This latter case may occur during a DoS attack such as an I1 flood.
除非实现无法或不愿意建立HIP关联，否则实现应使用R1数据包回复I1。如果实现无法设置HIP关联，则主机应向I1源地址发送ICMP目标协议无法访问、管理禁止的消息。如果实现不愿意建立HIP关联，主机可能会忽略I1。后一种情况可能发生在DoS攻击（如I1洪水）期间。
The implementation MUST 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 can result in an R1 attack on a system. An R1 sender MUST have a mechanism to rate-limit R1s to an address.
欺骗的I1可导致系统上的R1攻击。R1发送方必须具有将R1s限制到某个地址的机制。
It is RECOMMENDED that the HIP state machine does not transition upon sending an R1.
建议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 is either one of its own HITs or NULL.
1. 响应者必须检查响应者在接收到的I1中的命中是其自己的命中还是空的。
2. If the Responder is in ESTABLISHED state, the Responder MAY respond to this with an R1 packet, prepare to drop existing SAs, and stay at ESTABLISHED state.
2. 如果响应者处于建立状态，则响应者可使用R1分组对此作出响应，准备丢弃现有SA，并保持在建立状态。
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 and stay at I1-SENT. If the sender's HIT is smaller than its own HIT, it should send R1 and stay at I1-SENT. The HIT comparison goes similarly as 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 with an R1 packet, it creates a new R1 or selects a precomputed R1 according to the format described in Section 5.3.2.
4. 如果实现选择使用R1数据包响应I1，它将根据第5.3.2节中描述的格式创建新R1或选择预计算R1。
5. The R1 MUST contain the received Responder's HIT, unless the received HIT is NULL, in which case the Responder SHOULD select a HIT that is constructed with the MUST algorithm in Section 3, which is currently RSA. Other than that, selecting the HIT is a local policy matter.
5. R1必须包含接收到的响应者的命中，除非接收到的命中为空，在这种情况下，响应者应选择使用第3节中的MUST算法构造的命中，当前为RSA。除此之外，选择热门产品是当地的政策问题。
6. The Responder sends the R1 to the source IP address of the I1 packet.
6. 响应程序将R1发送到I1数据包的源IP地址。
All compliant implementations MUST produce R1 packets. An R1 packet MAY be precomputed. An R1 packet MAY be reused for time 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 re-used beyond this limit. R1 information MUST NOT be discarded until Delta S after T. Time S is the delay needed for the last I2 to arrive back to the Responder.
所有兼容的实现都必须生成R1数据包。可以预计算R1分组。R1数据包可用于时间增量T，该时间增量T依赖于实现，一旦从启动器接收到有效响应I2数据包，则应弃用该数据包，且不得使用该数据包。在I1消息风暴期间，R1数据包的重复使用可能超出此限制。R1信息在T之后的增量S之前不得丢弃。时间S是最后一个I2返回响应者所需的延迟。
An implementation MAY keep state about received I1s and match the received I2s against the state, as discussed in Section 4.1.1.
如第4.1.1节所述，一个实现可以保持关于接收到的I1的状态，并将接收到的I2与状态进行匹配。
If an implementation receives a malformed I1 message, it SHOULD NOT respond with a NOTIFY message, as such practice could open up a potential denial-of-service danger. Instead, it MAY respond with an ICMP packet, as defined in Section 5.4.
如果实现接收到格式错误的I1消息，则不应使用NOTIFY消息进行响应，因为这种做法可能会带来潜在的拒绝服务危险。相反，它可以按照第5.4节的定义，使用ICMP数据包进行响应。
A system receiving an R1 MUST first check to see if it has sent an I1 to the originator of the R1 (i.e., it is in state I1-SENT). If so, it SHOULD process the R1 as described below, send an I2, and go to state I2-SENT, setting a timer to protect the I2. If the system is in state I2-SENT, it MAY respond to an R1 if the R1 has a larger R1 generation counter; if so, it should drop its state due to processing the previous R1 and start over from state I1-SENT. If the system is in any other state with respect to that host, it SHOULD silently drop the R1.
接收R1的系统必须首先检查是否已将I1发送给R1的发起人（即处于I1-sent状态）。如果是这样的话，它应该如下所述处理R1，发送I2，并进入状态I2-SENT，设置定时器以保护I2。如果系统处于状态I2-SENT，则如果R1具有更大的R1生成计数器，则系统可能会响应R1；如果是这样，它应该由于处理前一个R1而放弃其状态，并从状态I1-SENT重新开始。如果系统处于与该主机相关的任何其他状态，则应静默删除R1。
When sending multiple I1s, an Initiator SHOULD wait for a small amount of time 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.
当发送多个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 to the originator of the R1 (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 was sent in opportunistic mode (see Section 4.1.6), the IP addresses in the received R1 packet SHOULD be ignored and, when looking up the right HIP association, the received R1 SHOULD be matched against the associations using only the HITs. If a match exists, the system should process the R1 as described below.
1. 接收R1的系统必须首先检查其是否已将I1发送给R1的发起人（即，其具有处于I1-sent状态且与R1中的命中关联的髋部关联）。除非I1以机会主义模式发送（见第4.1.6节），否则应忽略接收到的R1数据包中的IP地址，并且在查找右髋关节关联时，应仅使用点击将接收到的R1与关联进行匹配。如果存在匹配项，系统应按如下所述处理R1。
2. Otherwise, if the system is in any other state than I1-SENT or I2-SENT with respect to the HITs included in the R1, it SHOULD silently drop the R1 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, and the I1 and the Responder's HIT MUST correspond to the one used, unless the I1 contained a NULL HIT.
3. 如果HIP关联状态为I1-SENT或I2-SENT，则接收到的启动器的命中必须与原始中使用的命中相对应，并且I1和响应者的命中必须与使用的命中相对应，除非I1包含空命中。
4. The system SHOULD validate the R1 signature before applying further packet processing, according to Section 5.2.12.
4. 根据第5.2.12节，系统应在应用进一步的数据包处理之前验证R1签名。
5. If the HIP association state is I1-SENT, and multiple valid R1s are present, the system SHOULD select from among the R1s with the largest R1 generation counter.
5. 如果HIP关联状态为I1-SENT，且存在多个有效R1s，则系统应从R1生成计数器最大的R1s中进行选择。
6. If the HIP association state is I2-SENT, the system MAY reenter state I1-SENT and process the received R1 if it has a larger R1 generation counter than the R1 responded to previously.
6. 如果HIP关联状态为I2-SENT，则系统可重新进入状态I1-SENT并处理接收到的R1，前提是其R1生成计数器大于先前响应的R1。
7. The R1 packet may have the A bit set -- in this case, the system MAY choose to refuse it by dropping the R1 and returning to state UNASSOCIATED. The system SHOULD consider dropping the R1 only if it used a NULL HIT in I1. If the A bit is set, the Responder's HIT is anonymous and should not be stored.
7. R1数据包可能设置了A位——在这种情况下，系统可以选择通过丢弃R1并返回到未关联状态来拒绝它。系统只有在I1中使用空命中时才应该考虑删除R1。如果设置了A位，则响应者的命中是匿名的，不应存储。
8. 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.
8. 系统应尝试使用接收到的主机标识构造HIT并验证其是否与发送方的HIT匹配，从而根据接收到的主机标识验证HIT。
9. The system MUST store the received R1 generation counter for future reference.
9. 系统必须存储接收到的R1生成计数器，以备将来参考。
10. The system attempts to solve the puzzle in R1. 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 I1 within the retry bounds or abandon the HIP exchange.
10. 系统试图解决R1中的难题。超过谜题的剩余生存期后，系统必须终止搜索。如果谜题没有成功解决，则实现可以在重试范围内重新发送I1，或者放弃HIP交换。
11. 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. If the received Diffie-Hellman Group ID is not supported, the implementation may either resend I1 within the retry bounds or abandon the HIP exchange.
11. 系统根据Diffie_Hellman参数中提供的公共值和组ID计算标准Diffie Hellman键控材料。Diffie-Hellman键控材料Kij用于第6.5节规定的键提取。如果接收到的Diffie-Hellman组ID不受支持，则实现可以在重试范围内重新发送I1，或者放弃HIP交换。
12. The system selects the HIP transform 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. If the proposed alternatives are not acceptable to the system, it may either resend I1 within the retry bounds or abandon the HIP exchange.
12. 系统从R1数据包中提供的选择中选择HIP变换，并在随后生成和使用加密密钥以及发送I2时使用所选值。如果建议的替代方案不被系统接受，它可以在重试范围内重新发送I1，或者放弃HIP交换。
13. The system initializes the remaining variables in the associated state, including Update ID counters.
13. 系统初始化处于关联状态的其余变量，包括更新ID计数器。
14. The system prepares and sends an I2, as described in Section 5.3.3.
14. 系统准备并发送I2，如第5.3.3节所述。
15. The system SHOULD start a timer whose timeout value should be larger than the worst-case anticipated RTT, and MUST increment a timeout counter associated with the I2. The sender SHOULD retransmit the I2 upon a timeout and restart the timer, up to a maximum of I2_RETRIES_MAX tries.
15. 系统应启动一个计时器，其超时值应大于最坏情况下预期的RTT，并且必须增加与I2相关联的超时计数器。发送方应在超时后重新传输I2，并重新启动计时器，最多可重试I2次。
16. 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.
16. 如果系统处于状态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 typically doesn't have any state. An implementation SHOULD wait for some more time for a possibly good R1, after which it MAY try again by sending a new I1 packet.
如果实现接收到格式错误的R1消息，它必须以静默方式丢弃数据包。发送通知或ICMP不会有帮助，因为R1的发送方通常没有任何状态。一个实现应该为可能良好的R1再等待一段时间，之后它可以通过发送一个新的I1数据包重试。
Upon receipt of an I2, the system MAY perform initial checks to determine whether the I2 corresponds to a recent R1 that has been sent out, if the Responder keeps such state. For example, the sender could check whether the I2 is from an address or HIT that has recently received an R1 from it. The R1 may have had Opaque data included that was echoed back in the I2. If the I2 is considered to be suspect, it MAY be silently discarded by the system.
在接收到I2时，如果响应者保持这种状态，则系统可以执行初始检查以确定I2是否对应于最近发送的R1。例如，发送方可以检查I2是否来自最近从其收到R1的地址或HIT。R1可能包含了在I2中回显的不透明数据。如果I2被认为是可疑的，系统可能会悄悄地丢弃它。
Otherwise, the HIP implementation SHOULD process the I2. This includes validation of the puzzle solution, generating the Diffie-Hellman key, decrypting the Initiator's Host Identity, verifying the signature, creating state, and finally sending an R2.
否则，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 corresponds to a recently sent R1. 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.
2. 系统必须检查响应者的点击是否与自己的一次点击相对应。
3. If the system's state machine is in the R2-SENT state, the system MAY check if the newly received I2 is similar to the one that triggered moving to R2-SENT. If so, it MAY retransmit a previously sent R2, reset the R2-SENT timer, and the state machine stays in R2-SENT.
3. 如果系统的状态机处于R2-SENT状态，系统可能会检查新接收到的I2是否与触发移动到R2-SENT的I2相似。如果是这样，它可能会重新传输先前发送的R2，重置R2-sent计时器，并且状态机保持在R2-sent状态。
4. If the system's state machine is in the I2-SENT state, the system makes a comparison between its local and sender's HITs (similarly as 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 previously. The peer Diffie-Hellman key and the nonce J are taken from the just arrived I2 packet. The local Diffie-Hellman key and the nonce I are the ones that were earlier sent in the R1 packet.
4. 如果系统的状态机处于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数据包中发送的密钥。
5. If the system's state machine is in the I1-SENT state, and the HITs in the I2 match those used in the previously sent I1, the system uses this received I2 as the basis for the HIP association it was trying to form, and stops retransmitting I1 (provided that the I2 passes the below additional checks).
5. 如果系统的状态机处于I1-SENT状态，并且I2中的命中与之前发送的I1中使用的命中匹配，则系统将此接收到的I2用作其试图形成的HIP关联的基础，并停止重传I1（前提是I2通过以下附加检查）。
6. If the system's state machine is in any other state than R2- SENT, the system SHOULD check that the echoed R1 generation counter in I2 is within the acceptable range. Implementations MUST accept puzzles from the current generation and MAY accept puzzles from earlier generations. If the newly received I2 is outside the accepted range, the I2 is stale (perhaps replayed) and SHOULD be dropped.
6. 如果系统的状态机处于R2发送以外的任何其他状态，系统应检查I2中的回波R1生成计数器是否在可接受范围内。实现必须接受当前一代的谜题，也可以接受前几代的谜题。如果新接收到的I2超出了可接受的范围，则I2已过时（可能已重放），应丢弃。
7. The system MUST validate the solution to the puzzle by computing the hash described in Section 5.3.3 using the same RHASH algorithm.
7. 系统必须通过使用相同的RHASH算法计算第5.3.3节中描述的哈希值来验证谜题的解决方案。
8. The I2 MUST have a single value in the HIP_TRANSFORM parameter, which MUST match one of the values offered to the Initiator in the R1 packet.
8. I2在HIP_TRANSFORM参数中必须有一个值，该值必须与R1数据包中提供给启动器的一个值相匹配。
9. 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.
9. 系统必须根据Diffie_Hellman参数中的公共值和组ID派生Diffie Hellman键控材料Kij。如第6.5节所述，该键用于衍生髋部关联键。如果Diffie-Hellman组ID不受支持，I2数据包将被静默丢弃。
10. The encrypted HOST_ID is decrypted by the Initiator encryption key defined in Section 6.5. If the decrypted data is not a HOST_ID parameter, the I2 packet is silently dropped.
10. 加密的主机ID由第6.5节中定义的启动器加密密钥解密。如果解密的数据不是主机ID参数，则I2数据包将被静默丢弃。
11. The implementation SHOULD also verify that the Initiator's HIT in the I2 corresponds to the Host Identity sent in the I2. (Note: some middleboxes may not able to make this verification.)
11. 实现还应验证I2中启动器的命中是否与I2中发送的主机标识相对应。（注意：某些中间盒可能无法进行此验证。）
12. The system MUST verify the HMAC according to the procedures in Section 5.2.9.
12. 系统必须根据第5.2.9节中的程序验证HMAC。
13. The system MUST verify the HIP_SIGNATURE according to Section 5.2.11 and Section 5.3.3.
13. 系统必须根据第5.2.11节和第5.3.3节验证HIP_签名。
14. 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.
14. 如果上述检查有效，则系统继续进行进一步的I2处理；否则，它将丢弃I2，其状态机将保持相同的状态。
15. 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.
15. I2数据包可能设置了A位——在这种情况下，系统可能会选择通过丢弃I2来拒绝它，并且状态机返回到未关联状态。如果设置了A位，则启动器的命中是匿名的，不应存储。
16. The system initializes the remaining variables in the associated state, including Update ID counters.
16. 系统初始化处于关联状态的其余变量，包括更新ID计数器。
17. Upon successful processing of an I2 when the system's state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or R2-SENT, an R2 is sent and the system's state machine transitions to state R2-SENT.
17. 当系统的状态机处于未关联、I1-SENT、I2-SENT或R2-SENT状态时，成功处理I2后，将发送R2，系统的状态机将转换为状态R2-SENT。
18. Upon successful processing of an I2 when the system's state machine is in state ESTABLISHED, the old HIP association is dropped and a new one is installed, an R2 is sent, and the system's state machine transitions to R2-SENT.
18. 当系统的状态机处于已建立状态时，成功处理I2后，旧的HIP关联将被删除并安装新的HIP关联，发送R2，系统的状态机将转换为R2-sent。
19. 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 maximal retransmissions of I2s), the state machine transitions to ESTABLISHED.
19. 当系统的状态机转换为R2-SENT时，系统启动计时器。如果在传入的HIP关联上已接收到一些数据，或已接收到更新数据包（或指示对等系统的状态机已移动到已建立状态的其他数据包），则状态机将转换为已建立状态机。如果计时器过期（允许I2s的最大重传），状态机将转换为已建立。
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 received in states UNASSOCIATED, I1-SENT, or ESTABLISHED results in the R2 being dropped and the state machine staying in the same state. If an R2 is received in state I2-SENT, it SHOULD be processed.
以未关联、I1-SENT或已建立状态接收的R2会导致R2被丢弃，并且状态机保持在相同状态。如果在I2-SENT状态下接收到R2，则应对其进行处理。
The following steps define the conceptual processing rules for an incoming R2 packet:
以下步骤定义传入R2数据包的概念处理规则：
1. The system MUST verify that the HITs in use correspond to the HITs that were received in the R1.
1. 系统必须验证使用中的命中与R1中接收到的命中相对应。
2. The system MUST verify the HMAC_2 according to the procedures in Section 5.2.10.
2. 系统必须根据第5.2.10节中的程序验证HMAC_2。
3. The system MUST verify the HIP signature according to the procedures in Section 5.2.11.
3. 系统必须根据第5.2.11节中的程序验证HIP签名。
4. 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.
4. 如果上述任何一项检查失败，则极有可能发生中间人攻击或其他安全攻击。该系统应根据其当地政策采取相应行动。
5. If the system is in any other state than I2-SENT, the R2 is silently dropped.
5. 如果系统处于I2-SENT以外的任何其他状态，R2将自动删除。
6. Upon successful processing of the R2, the state machine moves to state ESTABLISHED.
6. 成功处理R2后，状态机移动到已建立状态。
A host sends an UPDATE packet when it wants to update some information related to a HIP association. There are a number of likely situations, 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 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. Therefore, any new UPDATEs that depend on a previous outstanding UPDATE being successfully received and acknowledged MUST be postponed 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 Update ID of zero. Otherwise, the system increments its own Update ID value by one before continuing the below steps.
1. 发送第一个更新数据包时更新ID为零。否则，系统会将其自身的更新ID值增加1，然后继续执行以下步骤。
2. The system creates an UPDATE packet that contains a SEQ parameter with the current value of Update ID. The UPDATE packet may also include an ACK of the peer's Update ID found in a received UPDATE SEQ parameter, if any.
2. 系统创建一个更新包，其中包含一个具有更新ID当前值的SEQ参数。更新包还可以包括在接收到的更新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.3. The UPDATE timer is cancelled upon receiving an ACK from the peer that acknowledges receipt of the UPDATE.
4. 如果更新计时器过期，则重新发送更新。可以重新更新\u重试\u最多次。更新计时器应以指数方式后退，以便后续重新传输。如果在更新_重试_最大次数后未收到来自对等方的确认，则认为HIP关联已中断，状态机应按照第4.4.3节所述从已建立状态移动到关闭状态。当从确认接收到更新的对等方接收到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, the peer's next expected in-sequence Update ID ("peer Update ID") is stored. Initially, this value is zero. Update ID comparisons of "less than" and "greater than" are performed with respect to a circular sequence number space.
对于每个关联，将存储对等方的下一个预期顺序更新ID（“对等方更新ID”）。最初，该值为零。针对循环序列号空间执行“小于”和“大于”的更新ID比较。
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 is 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 HMAC verification (next step) MUST NOT be skipped. (A byte-by-byte comparison of the received and a stored packet would be OK, though.) It is recommended that a host cache 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对应于最近处理的更新，则分组被视为重传。不得跳过HMAC验证（下一步）。（不过，对接收到的数据包和存储的数据包进行逐字节比较是可以的。）建议主机缓存更新随ACK发送的数据包，以避免生成新ACK数据包以响应重播更新的成本。系统必须再次确认这样的（明显的）更新消息重传，但也应该考虑速率限制这样的重传响应以防止重放攻击。
3. The system MUST verify the HMAC in the UPDATE packet. If the verification fails, the packet MUST be dropped.
3. 系统必须验证更新数据包中的HMAC。如果验证失败，则必须丢弃数据包。
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 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 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 earlier sent UPDATE packet that has not already been acknowledged. If no match is found or if the ACK does not acknowledge a new UPDATE, the packet MUST either 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 HMAC in the UPDATE packet. If the verification fails, the packet MUST be dropped.
2. 系统必须验证更新数据包中的HMAC。如果验证失败，则必须丢弃数据包。
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 newly acknowledged, multiple timers are stopped.
4. 相应的更新计时器停止（参见第6.11节），以便不再重新传输现在已确认的更新。如果新确认了多个更新，则会停止多个计时器。
Processing 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 (Section 4.4.1) purely based on the received NOTIFY message.
处理通知数据包是可选的。如果已处理，则应记录收到的通知参数中的任何错误。接收到的错误必须仅被视为信息性错误，接收方不应纯粹根据接收到的NOTIFY消息更改其HIP状态（第4.4.1节）。
When the host receives a CLOSE message, it responds with a CLOSE_ACK message and moves to CLOSED state. (The authenticity of the CLOSE message is verified using both HMAC and SIGNATURE). This processing applies whether or not the HIP association state is CLOSING in order to handle CLOSE messages from both ends that cross in flight.
当主机接收到关闭消息时，它会以关闭确认消息作出响应，并移动到关闭状态。（使用HMAC和签名验证关闭消息的真实性）。无论髋部关联状态是否处于关闭状态，此处理都将应用，以便处理来自飞行中交叉的两端的关闭消息。
The HIP association is not discarded before the host moves from the UNASSOCIATED state.
在主体从未关联状态移动之前，不会放弃髋部关联。
Once the closing process has started, any need to send data packets will trigger creating and establishing of a new HIP association, starting with sending an I1.
一旦关闭过程开始，任何发送数据包的需要都将触发创建和建立新的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 CLOSING or CLOSED state and that the CLOSE_ACK was in response to the CLOSE (using the included ECHO_RESPONSE_SIGNED in response to the sent ECHO_REQUEST_SIGNED).
当主机收到CLOSE_ACK消息时，它将验证它是否处于关闭或关闭状态，以及CLOSE_ACK是否响应关闭（使用为响应发送的ECHO_请求而签名的包含的ECHO_响应）。
The CLOSE_ACK uses HMAC and SIGNATURE 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).
关闭确认使用HMAC和签名进行验证。当状态更改为“未关联”时，该状态将被丢弃，之后，主机可能会对传入的关闭消息响应ICMP参数问题（请参阅第5.4.4节）。
In the case of 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 on stable 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 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 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。
Many Initiators would want to use a different HI for different Responders. The implementations SHOULD provide for an ACL of Initiator's HIT to Responder's HIT. This ACL SHOULD also include preferred transform and local lifetimes.
许多发起者希望为不同的响应者使用不同的HI。这些实现应该提供发起方命中到响应方命中的ACL。此ACL还应包括首选转换和本地生存期。
The value of K used in the HIP R1 packet can also vary by policy. K should never be greater than 20, but for trusted partners it could be as low as 0.
HIP R1数据包中使用的K值也可能因策略而异。K不应大于20，但对于受信任的合作伙伴，它可以低至0。
Responders would need a similar ACL, representing which hosts they accept HIP exchanges, and the preferred transform and local lifetimes. Wildcarding SHOULD be supported for this ACL also.
响应者需要一个类似的ACL，表示他们接受HIP交换的主机，以及首选的转换和本地生存时间。此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 so doing, 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攻击，这可能会对主机正常开展业务的能力造成更大的损害。
The 384-bit Diffie-Hellman Group is targeted to be used in hosts that either do not require or are not powerful enough for handling strong cryptography. Although there is a risk that with suitable equipment the encryption can be broken in real time, the 384-bit group can provide some protection for end-hosts that are not able to handle any stronger cryptography. When the security provided by the 384-bit group is not enough for applications on a host, the support for this group should be turned off in the configuration.
384位Diffie-Hellman组的目标是在不需要或功能不足以处理强加密的主机中使用。虽然使用合适的设备可能会实时破坏加密，但384位组可以为无法处理任何更强加密的终端主机提供一些保护。当384位组提供的安全性不足以支持主机上的应用程序时，应在配置中关闭对此组的支持。
Denial-of-service attacks often take advantage of the cost of start of state for a protocol on the Responder compared to the 'cheapness' on the Initiator. HIP makes no attempt to increase the cost of the start of state on the Initiator, but makes an effort to reduce the cost to the Responder. This is done by having the Responder start the 3-way exchange instead of the Initiator, making the HIP protocol 4 packets long. In doing this, packet 2 becomes a 'stock' packet that the Responder MAY use many times, until some Initiator has
拒绝服务攻击通常利用响应程序上协议的启动状态成本，而不是启动器上的“廉价性”。HIP不试图增加启动器的状态开始成本，但努力降低响应者的成本。这是通过让响应者启动3路交换而不是启动器来完成的，使HIP协议4数据包变长。在这样做的过程中，数据包2成为响应者可以多次使用的“库存”数据包，直到某个发起方收到该数据包为止
provided a valid response to such an R1 packet. During an I1 storm, the host may reuse the same D-H value also even if some Initiator has provided a valid response using that particular D-H 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.
提供了对此类R1数据包的有效响应。在I1风暴期间，即使某些启动器使用该特定D-H值提供了有效响应，主机也可以重用相同的D-H值。然而，这种行为是不鼓励的，应该避免。使用相同的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 spoofs the I1 HIP 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 HIP packet. The defense against this attack is to simply ignore any R1 packet where a corresponding I1 was not sent.
在创建I2 HIP数据包时，将起始状态成本转移到启动器，这是另一种DoS攻击。攻击者伪造I1 HIP数据包，响应者发送R1 HIP数据包。这可能会将“启动器”与评估R1 HIP数据包和创建I2 HIP数据包联系起来。针对这种攻击的防御措施是忽略没有发送相应I1的任何R1数据包。
A second form of DoS attack arrives in the I2 HIP packet. Once the attacking Initiator has solved the puzzle, it can send packets with spoofed IP source addresses with either an invalid encrypted HIP payload component or a bad HIP signature. 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 after N bad I2 packets, the Responder would discard any I2s that contain the given Initiator HIT. This will shut down the attack. The attacker would have to request another R1 and use that to launch a new attack. The Responder could up the value of K while under attack. On the downside, valid I2s might get dropped too.
第二种形式的DoS攻击出现在I2 HIP数据包中。一旦攻击发起方解决了这个难题，它就可以发送带有伪造IP源地址的数据包，这些IP源地址包含无效的加密HIP有效负载组件或错误的HIP签名。这将需要响应者的资源来发现I2数据包无法完全处理。针对此攻击的防御措施是在N个坏I2数据包之后，响应者将丢弃包含给定启动器命中的任何I2。这将使攻击停止。攻击者必须请求另一个R1并使用该R1发起新的攻击。响应者可以在受到攻击时提高K值。另一方面，有效的I2s也可能被丢弃。
A third form of DoS attack is emulating the restart of state after a reboot of one of the partners. A restarting host would send an I1 to a peer, which would respond with an R1 even if it were in the ESTABLISHED state. If the I1 were spoofed, the resulting R1 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 end of state. HIP relies on timers plus a CLOSE/CLOSE_ACK handshake to explicitly signal the end of a HIP association. Because both CLOSE and CLOSE_ACK messages contain an HMAC, an outsider cannot close a connection. The presence of an additional SIGNATURE allows middleboxes to inspect these messages and discard the associated state (for e.g., 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 IP spoofer sending CLOSE messages to launch reflection attacks.
第四种形式的拒绝服务攻击是模拟状态结束。HIP依靠计时器加上闭合/闭合确认握手来明确表示HIP关联的结束。因为CLOSE和CLOSE_ACK消息都包含HMAC，所以外部人员无法关闭连接。附加签名的存在允许中间盒检查这些消息并丢弃相关状态（例如，防火墙、基于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. However, since an Initiator may choose to use an anonymous HI, it knowingly risks a MitM attack. The Responder may choose not to accept a HIP exchange with an anonymous Initiator.
同样，如果发起方的HI位于安全DNS区域、可信证书或其他安全可用的位置，则响应方可以检索HI（在获得I2 HIP数据包之后），并验证HI确实可以被信任。但是，由于启动器可能选择使用匿名HI，因此它会故意冒MitM攻击的风险。响应者可以选择不接受与匿名发起人的HIP交换。
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.6.
本文档中介绍了HIP机会主义模式的概念，但本文档未指定应用程序的此类连接设置的语义。如第4.1.6节所述，机会主义模式存在某些问题。
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. It SHOULD NOT change any state information based purely 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 present 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 from 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 a behavior and try to break up the HIP 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
由于并非所有主机都支持HIP，因此预计ICMP“目标协议不可访问”消息会导致DoS攻击。针对发起方，攻击看起来像响应方不支持HIP，但在收到ICMP消息后不久，发起方将收到有效的R1 HIP数据包。因此，为了防止这种攻击，发起者不应该对ICMP消息做出反应，直到一个合理的增量时间才能得到真正响应者的R1 HIP数据包。针对响应者的类似攻击更为复杂。通常，如果响应者收到的I1消息是攻击者发送的伪造消息，则响应者可能会从R1消息发送到的IP地址接收ICMP消息。但是，老练的攻击者可以尝试利用这种行为，在发起方有机会发送有效的I2消息之前，通过向响应方发送这样的ICMP消息，尝试破坏HIP交换。因此，响应者不应对此类ICMP消息采取行动。特别是，它不应该删除创建的任何最小状态
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.
当它发送R1 HIP数据包时（如果它确实创建了一个），但要等待有效的I2 HIP数据包或自然超时（即，如果完全跟踪R1数据包）。同样，在等待R2 HIP数据包时，启动器应忽略任何ICMP消息，并应仅在自然超时后删除任何挂起状态。
IANA has reserved protocol number 139 for the Host Identity Protocol.
IANA为主机标识协议保留了协议编号139。
This document defines a new 128-bit value under the CGA Message Type namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be used for HIT generation as specified in ORCHID [RFC4843].
本文档在CGA消息类型命名空间[RFC3972]下定义了一个新的128位值，0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA，用于生成RATCH[RFC4843]中指定的命中。
This document also creates a set of new namespaces. These are described below.
本文档还创建了一组新名称空间。下文对这些问题进行了说明。
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. The current values are defined in Sections 5.3.1 through 5.3.8.
HIP协议数据包中的7位数据包类型字段描述HIP协议消息的类型。其定义见第5.1节。电流值在第5.3.1节至第5.3.8节中定义。
New values are assigned through IETF Consensus [RFC2434].
通过IETF共识[RFC2434]分配新值。
HIP Version
髋关节型
The four-bit Version field in a HIP protocol packet describes the version of the HIP protocol. It is defined in Section 5.1. The only currently defined value is 1. New values are assigned through IETF Consensus.
HIP协议数据包中的四位版本字段描述HIP协议的版本。其定义见第5.1节。当前唯一定义的值是1。通过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.20.
HIP参数中的16位类型字段描述参数的类型。其定义见第5.2.1节。电流值在第5.2.3节至第5.2.20节中定义。
With the exception of the assigned Type codes, the Type codes 0 through 1023 and 61440 through 65535 are reserved for future base protocol extensions, and are assigned through IETF Consensus.
除分配的类型代码外，类型代码0至1023和61440至65535保留用于未来的基本协议扩展，并通过IETF协商一致分配。
The Type codes 32768 through 49141 are reserved for experimentation. Types SHOULD be selected 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至49141保留用于试验。应从该范围内随机选择类型，从而降低碰撞的概率。应该使用一种真正随机的方法（比如掷硬币）。
All other Type codes are assigned through First Come First Served, with Specification Required [RFC2434].
所有其他类型代码均通过先到先得的方式分配，且需要规范[RFC2434]。
Group ID
组ID
The eight-bit Group ID values appear in the DIFFIE_HELLMAN parameter and are defined in Section 5.2.6. New values either from the reserved or unassigned space are assigned through IETF Consensus.
八位组ID值出现在DIFFIE_HELLMAN参数中，并在第5.2.6节中定义。通过IETF共识分配保留或未分配空间中的新值。
Suite ID
套房ID
The 16-bit Suite ID values in a HIP_TRANSFORM parameter are defined in Section 5.2.7. New values either from the reserved or unassigned space are assigned through IETF Consensus.
HIP_变换参数中的16位套件ID值在第5.2.7节中定义。通过IETF共识分配保留或未分配空间中的新值。
DI-Type
DI型
The four-bit DI-Type values in a HOST_ID parameter are defined in Section 5.2.8. New values are assigned through IETF Consensus.
主机ID参数中的四位DI类型值在第5.2.8节中定义。通过IETF共识分配新值。
Notify Message Type
通知消息类型
The 16-bit Notify Message Type values in a NOTIFICATION parameter are defined in Section 5.2.16.
通知参数中的16位通知消息类型值在第5.2.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, 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. Values 51-8191 are error types reserved to be allocated by IANA. Values 8192-16383 are error types for experimentation. Values 16385- 40959 are status types to be allocated by IANA, and values 40960- 65535 are status types for experimentation. New values in ranges 51-8191 and 16385-40959 are assigned through First Come First Served, with Specification Required.
通知消息类型值1-10用于通知数据包结构中的错误，值11-20用于通知包含加密相关材料的参数中的问题，值21-30用于通知身份验证或数据包完整性验证中的问题。大于30的参数编号可用于通知其他类型的错误或事件。值51-8191是保留由IANA分配的错误类型。值8192-16383是用于实验的错误类型。值16385-40959是IANA分配的状态类型，值40960-65535是实验的状态类型。51-8191和16385-40959范围内的新值通过先到先得的方式分配，并要求规格。
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
在参加第43届IETF会议的MALLOC会议后，产生了创建HIP的动力。Baiju Patel和Hilarie Orman为原作者Bob Moskowitz提供了帮助，帮助他超越5段的想法。由于IETFers的广泛投入，自早期版本以来，它已经相当成熟。最重要的是，它的设计目标是明确的，不同于这方面的其他努力。特别提到
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.
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 include Jeff Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew McGregor, Julien Laganier, Miika Komu, Mika Kousa, 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., [AUR03] were added at a later stage.
HIP工作组于2004年初成立后，通过工作组流程引入了一些变化。最值得注意的是，原始文档分为两部分，一部分包含基本交换，另一部分定义如何使用ESP。Aura等人[AUR03]提出的协议的一些修改在后期添加。
[FIPS95] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995.
[FIPS95]NIST，“FIPS PUB 180-1：安全哈希标准”，1995年4月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[RFC2463]Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC2463，1998年12月。
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC2536]Eastlake，D.，“域名系统（DNS）中的DSA密钥和SIG”，RFC 25361999年3月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[RFC2898]Kaliski，B.，“PKCS#5：基于密码的加密规范版本2.0”，RFC 28982000年9月。
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3110]Eastlake，D.，“域名系统（DNS）中的RSA/SHA-1 SIGs和RSA密钥”，RFC 3110，2001年5月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4307]Schiller，J.“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，2005年12月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843]Nikander，P.，Laganier，J.，和F.Dupont，“覆盖可路由加密哈希标识符（RAYD）的IPv6前缀”，RFC 4843，2007年4月。
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5202]Jokela，P.，Moskowitz，R.，和P.Nikander，“将封装安全有效载荷（ESP）传输格式与主机标识协议（HIP）结合使用”，RFC 52022008年4月。
[AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the HIP Base Exchange Protocol", in Proceedings of 10th Australasian Conference on Information Security and Privacy, July 2003.
[AUR03]Aura，T.，Nagarajan，A.，和A.Gurtov，“髋关节基底交换协议分析”，载于第十届澳大拉西亚信息安全和隐私会议记录，2003年7月。
[CRO03] Crosby, SA. and DS. Wallach, "Denial of Service via Algorithmic Complexity Attacks", in Proceedings of Usenix Security Symposium 2003, Washington, DC., August 2003.
[CRO03]克罗斯比，南非。和DS。Wallach，“通过算法复杂度攻击的拒绝服务”，2003年8月，华盛顿特区，Usenix安全研讨会论文集。
[DIF76] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory vol. IT-22, number 6, pages 644-654, Nov 1976.
[DIF76]Diffie，W.和M.Hellman，“密码学的新方向”，IEEE信息论交易卷IT-22，第6期，第644-654页，1976年11月。
[FIPS01] NIST, "FIPS PUB 197: Advanced Encryption Standard", Nov 2001.
[FIPS01]NIST，“FIPS PUB 197：高级加密标准”，2001年11月。
[HIP-APP] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", Work in Progress, November 2007.
[HIP-APP]Henderson，T.，Nikander，P.，和M.Komu，“将主机身份协议用于遗留应用程序”，正在进行的工作，2007年11月。
[IPsec-APIs] Richardson, M., Williams, N., Komu, M., and S. Tarkoma, "IPsec Application Programming Interfaces", Work in Progress, February 2008.
[IPsec API]Richardson，M.，Williams，N.，Komu，M.，和S.Tarkoma，“IPsec应用程序编程接口”，正在进行的工作，2008年2月。
[KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security , Oct 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.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC 4423，2006年5月。
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
[RFC5204]Laganier，J.和L.Eggert，“主机身份协议（HIP）会合扩展”，RFC 52042008年4月。
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, April 2008.
[RFC5205]Nikander，P.和J.Laganier，“主机身份协议（HIP）域名系统（DNS）扩展”，RFC 52052008年4月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Henderson，T.，Ed.“终端主机移动性和主机身份协议的多宿”，RFC 5206，2008年4月。
[SHIM6-PROTO] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", Work in Progress, February 2008.
[SHIM6-PROTO]Nordmark，E.和M.Bagnulo，“SHIM6:IPv6的3级多宿主垫片协议”，正在进行的工作，2008年2月。
As mentioned in Section 4.1.1, the Responder may delay state creation and still reject most spoofed I2s by using a number of pre-calculated R1s 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 on 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节所述，响应者可通过使用大量预先计算的R1s和本地选择功能延迟状态创建，并仍然拒绝大多数欺骗的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 gets 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 ), 64)
I值计算：I=Ltrunc（RHASH（S | HIT-I | HIT-R | IP-I | IP-R），64）
The RHASH algorithm is the same that is used to generate the Responder's HIT value.
RHASH算法与用于生成响应者命中值的算法相同。
From an incoming I2 packet, the Responder gets 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 )
break;
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 )
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 )
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 3.5. The examples below use IP addresses of 192.168.0.1 and 192.168.0.2 (and their respective IPv4- compatible IPv6 formats), and HITs with the prefix of 2001:10 followed by zeros, followed by a decimal 1 or 2, respectively.
第5.1.1节规定了HIP数据包的HIP校验和。第3.5节规定了通过支持HIP的安全关联运行的TCP和UDP数据包的校验和。下面的示例使用192.168.0.1和192.168.0.2的IP地址（以及它们各自的IPv4兼容IPv6格式），HITs的前缀分别为2001:10和0，后跟十进制1或2。
The following example is defined only for testing a checksum calculation. The address format for the IPv4-compatible IPv6 address is not a valid one, but using these IPv6 addresses when testing an IPv6 implementation gives the same checksum output as an IPv4 implementation with the corresponding IPv4 addresses.
以下示例仅用于测试校验和计算。与IPv4兼容的IPv6地址的地址格式无效，但在测试IPv6实现时使用这些IPv6地址将提供与具有相应IPv4地址的IPv4实现相同的校验和输出。
Source Address: ::192.168.0.1
Destination Address: ::192.168.0.2
Upper-Layer Packet Length: 40 0x28
Next Header: 139 0x8b
Payload Protocol: 59 0x3b
Header Length: 4 0x4
Packet Type: 1 0x1
Version: 1 0x1
Reserved: 1 0x1
Control: 0 0x0
Checksum: 446 0x1be
Sender's HIT : 2001:10::1
Receiver's HIT: 2001:10::2
Source Address: ::192.168.0.1
Destination Address: ::192.168.0.2
Upper-Layer Packet Length: 40 0x28
Next Header: 139 0x8b
Payload Protocol: 59 0x3b
Header Length: 4 0x4
Packet Type: 1 0x1
Version: 1 0x1
Reserved: 1 0x1
Control: 0 0x0
Checksum: 446 0x1be
Sender's HIT : 2001:10::1
Receiver's HIT: 2001:10::2
The IPv4 checksum value for the same example I1 packet is the same as the IPv6 checksum (since the checksums due to the IPv4 and IPv6 pseudo-header components are the same).
同一示例I1数据包的IPv4校验和值与IPv6校验和值相同（因为IPv4和IPv6伪报头组件的校验和相同）。
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:10::1
Receiver's HIT: 2001:10::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
Header length: 20 0x14
Flags: SYN 0x02
Window size: 65535 0xffff
Checksum: 28618 0x6fca
Urgent pointer: 0 0x0000
Sender's HIT: 2001:10::1
Receiver's HIT: 2001:10::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
Header length: 20 0x14
Flags: SYN 0x02
Window size: 65535 0xffff
Checksum: 28618 0x6fca
Urgent pointer: 0 0x0000
0x0000: 6000 0000 0014 0640 2001 0010 0000 0000 0x0010: 0000 0000 0000 0001 2001 0010 0000 0000 0x0020: 0000 0000 0000 0002 ffdc 0016 0000 0001 0x0030: 0000 0000 5002 ffff 6fca 0000
0x0000:6000 0000 0014 0640 2001 0010 0000 0x0010:0000 0000 0001 2001 0010 0000 0x0020:0000 0000 0000 0002 ffdc 0016 0000 0001 0x0030:0000 0000 5002 ffff 6fca 0000
This 384-bit group is defined only to be used with HIP. NOTE: The security level of this group is very low! The encryption may be broken in a very short time, even real-time. It should be used only when the host is not powerful enough (e.g., some PDAs) and when security requirements are low (e.g., during normal web surfing).
此384位组仅用于HIP。注意：此组的安全级别非常低！加密可能在很短的时间内被破坏，甚至是实时破坏。只有在主机功能不够强大（例如，某些PDA）和安全要求较低（例如，在正常的网络冲浪过程中）时才应使用它。
This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 }
This prime is: 2^384 - 2^320 - 1 + 2^64 * { [ 2^254 pi] + 5857 }
Its hexadecimal value is:
其十六进制值为：
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B13B202 FFFFFFFF FFFFFFFF
FFFFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B13B202 FFFFFFFF FFFFFF
The generator is: 2.
发电机是：2。
See also [RFC2412] for definition of OAKLEY well-known group 1.
另见[RFC2412]了解奥克利著名集团1的定义。
OAKLEY Well-Known Group 1: A 768-bit prime
OAKLEY著名的第1组：768位素数
The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.
素数是2^768-2^704-1+2^64*{[2^638pi]+149686}。
The hexadecimal value is:
十六进制值为：
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
FFFFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E6 F44C42E9 A63A3620 FFFFFFFFFF FFFFFF
This has been rigorously verified as a prime.
这已经被严格地证明是一个基本的。
The generator is: 22 (decimal)
发电机为：22（十进制）
Authors' Addresses
作者地址
Robert Moskowitz ICSAlabs, An Independent Division of Verizon Business Systems 1000 Bent Creek Blvd, Suite 200 Mechanicsburg, PA USA
Robert Moskowitz ICSAlabs，Verizon Business Systems的一个独立部门，地址：美国宾夕法尼亚州Mechanicsburg Bent Creek Blvd 1000号200室
EMail: rgm@icsalabs.com
EMail: rgm@icsalabs.com
Pekka Nikander Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
佩卡·尼坎德·爱立信研究实验室JORVAS FIN-02420芬兰
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Petri Jokela (editor) Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND
Petri Jokela（编辑）爱立信研究实验室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 The Boeing Company P.O. Box 3707 Seattle, WA USA
托马斯·亨德森波音公司美国华盛顿州西雅图3707号邮政信箱
EMail: thomas.r.henderson@boeing.com
EMail: thomas.r.henderson@boeing.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.