Network Working Group P. Eronen
Request for Comments: 4718 Nokia
Category: Informational P. Hoffman
VPN Consortium
October 2006
Network Working Group P. Eronen
Request for Comments: 4718 Nokia
Category: Informational P. Hoffman
VPN Consortium
October 2006
IKEv2 Clarifications and Implementation Guidelines
IKEv2澄清和实施指南
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations.
本文件澄清了IKEv2规范的许多方面。它不需要对协议进行任何更改，而是提供了不太容易产生歧义的描述。本文档的目的是鼓励开发可互操作的实现。
Table of Contents
目录
1. Introduction ....................................................4
2. Creating the IKE_SA .............................................4
2.1. SPI Values in IKE_SA_INIT Exchange .........................4
2.2. Message IDs for IKE_SA_INIT Messages .......................5
2.3. Retransmissions of IKE_SA_INIT Requests ....................5
2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD ...............6
2.5. Invalid Cookies ............................................8
3. Authentication ..................................................9
3.1. Data Included in AUTH Payload Calculation ..................9
3.2. Hash Function for RSA Signatures ...........................9
3.3. Encoding Method for RSA Signatures ........................10
3.4. Identification Type for EAP ...............................11
3.5. Identity for Policy Lookups When Using EAP ................11
3.6. Certificate Encoding Types ................................12
3.7. Shared Key Authentication and Fixed PRF Key Size ..........12
3.8. EAP Authentication and Fixed PRF Key Size .................13
3.9. Matching ID Payloads to Certificate Contents ..............13
3.10. Message IDs for IKE_AUTH Messages ........................14
4. Creating CHILD_SAs .............................................14
4.1. Creating SAs with the CREATE_CHILD_SA Exchange ............14
4.2. Creating an IKE_SA without a CHILD_SA .....................16
4.3. Diffie-Hellman for First CHILD_SA .........................16
4.4. Extended Sequence Numbers (ESN) Transform .................17
4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED ..............17
4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO ...................18
4.7. Semantics of Complex Traffic Selector Payloads ............18
4.8. ICMP Type/Code in Traffic Selector Payloads ...............19
4.9. Mobility Header in Traffic Selector Payloads ..............20
4.10. Narrowing the Traffic Selectors ..........................20
4.11. SINGLE_PAIR_REQUIRED .....................................21
4.12. Traffic Selectors Violating Own Policy ...................21
4.13. Traffic Selector Authorization ...........................22
5. Rekeying and Deleting SAs ......................................23
5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange ............23
5.2. Rekeying the IKE_SA vs. Reauthentication ..................24
5.3. SPIs When Rekeying the IKE_SA .............................25
5.4. SPI When Rekeying a CHILD_SA ..............................25
5.5. Changing PRFs When Rekeying the IKE_SA ....................26
5.6. Deleting vs. Closing SAs ..................................26
5.7. Deleting a CHILD_SA Pair ..................................26
5.8. Deleting an IKE_SA ........................................27
5.9. Who is the original initiator of IKE_SA ...................27
5.10. Comparing Nonces .........................................27
5.11. Exchange Collisions ......................................28
5.12. Diffie-Hellman and Rekeying the IKE_SA ...................36
1. Introduction ....................................................4
2. Creating the IKE_SA .............................................4
2.1. SPI Values in IKE_SA_INIT Exchange .........................4
2.2. Message IDs for IKE_SA_INIT Messages .......................5
2.3. Retransmissions of IKE_SA_INIT Requests ....................5
2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD ...............6
2.5. Invalid Cookies ............................................8
3. Authentication ..................................................9
3.1. Data Included in AUTH Payload Calculation ..................9
3.2. Hash Function for RSA Signatures ...........................9
3.3. Encoding Method for RSA Signatures ........................10
3.4. Identification Type for EAP ...............................11
3.5. Identity for Policy Lookups When Using EAP ................11
3.6. Certificate Encoding Types ................................12
3.7. Shared Key Authentication and Fixed PRF Key Size ..........12
3.8. EAP Authentication and Fixed PRF Key Size .................13
3.9. Matching ID Payloads to Certificate Contents ..............13
3.10. Message IDs for IKE_AUTH Messages ........................14
4. Creating CHILD_SAs .............................................14
4.1. Creating SAs with the CREATE_CHILD_SA Exchange ............14
4.2. Creating an IKE_SA without a CHILD_SA .....................16
4.3. Diffie-Hellman for First CHILD_SA .........................16
4.4. Extended Sequence Numbers (ESN) Transform .................17
4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED ..............17
4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO ...................18
4.7. Semantics of Complex Traffic Selector Payloads ............18
4.8. ICMP Type/Code in Traffic Selector Payloads ...............19
4.9. Mobility Header in Traffic Selector Payloads ..............20
4.10. Narrowing the Traffic Selectors ..........................20
4.11. SINGLE_PAIR_REQUIRED .....................................21
4.12. Traffic Selectors Violating Own Policy ...................21
4.13. Traffic Selector Authorization ...........................22
5. Rekeying and Deleting SAs ......................................23
5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange ............23
5.2. Rekeying the IKE_SA vs. Reauthentication ..................24
5.3. SPIs When Rekeying the IKE_SA .............................25
5.4. SPI When Rekeying a CHILD_SA ..............................25
5.5. Changing PRFs When Rekeying the IKE_SA ....................26
5.6. Deleting vs. Closing SAs ..................................26
5.7. Deleting a CHILD_SA Pair ..................................26
5.8. Deleting an IKE_SA ........................................27
5.9. Who is the original initiator of IKE_SA ...................27
5.10. Comparing Nonces .........................................27
5.11. Exchange Collisions ......................................28
5.12. Diffie-Hellman and Rekeying the IKE_SA ...................36
6. Configuration Payloads .........................................37
6.1. Assigning IP Addresses ....................................37
6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS ...................38
6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ...................38
6.4. INTERNAL_IP4_NETMASK ......................................41
6.5. Configuration Payloads for IPv6 ...........................42
6.6. INTERNAL_IP6_NBNS .........................................43
6.7. INTERNAL_ADDRESS_EXPIRY ...................................43
6.8. Address Assignment Failures ...............................44
7. Miscellaneous Issues ...........................................45
7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR ....................45
7.2. Relationship of IKEv2 to RFC 4301 .........................45
7.3. Reducing the Window Size ..................................46
7.4. Minimum Size of Nonces ....................................46
7.5. Initial Zero Octets on Port 4500 ..........................46
7.6. Destination Port for NAT Traversal ........................47
7.7. SPI Values for Messages outside an IKE_SA .................47
7.8. Protocol ID/SPI Fields in Notify Payloads .................48
7.9. Which message should contain INITIAL_CONTACT ..............48
7.10. Alignment of Payloads ....................................48
7.11. Key Length Transform Attribute ...........................48
7.12. IPsec IANA Considerations ................................49
7.13. Combining ESP and AH .....................................50
8. Implementation Mistakes ........................................50
9. Security Considerations ........................................51
10. Acknowledgments ...............................................51
11. References ....................................................51
11.1. Normative References .....................................51
11.2. Informative References ...................................52
Appendix A. Exchanges and Payloads ................................54
A.1. IKE_SA_INIT Exchange ......................................54
A.2. IKE_AUTH Exchange without EAP .............................54
A.3. IKE_AUTH Exchange with EAP ................................55
A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying
CHILD_SAs .................................................56
A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA ..........56
A.6. INFORMATIONAL Exchange ....................................56
6. Configuration Payloads .........................................37
6.1. Assigning IP Addresses ....................................37
6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS ...................38
6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ...................38
6.4. INTERNAL_IP4_NETMASK ......................................41
6.5. Configuration Payloads for IPv6 ...........................42
6.6. INTERNAL_IP6_NBNS .........................................43
6.7. INTERNAL_ADDRESS_EXPIRY ...................................43
6.8. Address Assignment Failures ...............................44
7. Miscellaneous Issues ...........................................45
7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR ....................45
7.2. Relationship of IKEv2 to RFC 4301 .........................45
7.3. Reducing the Window Size ..................................46
7.4. Minimum Size of Nonces ....................................46
7.5. Initial Zero Octets on Port 4500 ..........................46
7.6. Destination Port for NAT Traversal ........................47
7.7. SPI Values for Messages outside an IKE_SA .................47
7.8. Protocol ID/SPI Fields in Notify Payloads .................48
7.9. Which message should contain INITIAL_CONTACT ..............48
7.10. Alignment of Payloads ....................................48
7.11. Key Length Transform Attribute ...........................48
7.12. IPsec IANA Considerations ................................49
7.13. Combining ESP and AH .....................................50
8. Implementation Mistakes ........................................50
9. Security Considerations ........................................51
10. Acknowledgments ...............................................51
11. References ....................................................51
11.1. Normative References .....................................51
11.2. Informative References ...................................52
Appendix A. Exchanges and Payloads ................................54
A.1. IKE_SA_INIT Exchange ......................................54
A.2. IKE_AUTH Exchange without EAP .............................54
A.3. IKE_AUTH Exchange with EAP ................................55
A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying
CHILD_SAs .................................................56
A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA ..........56
A.6. INFORMATIONAL Exchange ....................................56
This document clarifies many areas of the IKEv2 specification that may be difficult to understand to developers not intimately familiar with the specification and its history. The clarifications in this document come from the discussion on the IPsec WG mailing list, from experience in interoperability testing, and from implementation issues that have been brought to the editors' attention.
本文档澄清了IKEv2规范的许多方面，对于不熟悉该规范及其历史的开发人员来说，这些方面可能很难理解。本文档中的澄清来自IPsec WG邮件列表的讨论、互操作性测试的经验以及引起编辑注意的实现问题。
IKEv2/IPsec can be used for several different purposes, including IPsec-based remote access (sometimes called the "road warrior" case), site-to-site virtual private networks (VPNs), and host-to-host protection of application traffic. While this document attempts to consider all of these uses, the remote access scenario has perhaps received more attention here than the other uses.
IKEv2/IPsec可用于多种不同的目的，包括基于IPsec的远程访问（有时称为“road warrior”案例）、站点到站点虚拟专用网络（VPN）以及应用程序流量的主机到主机保护。虽然该文档试图考虑所有这些用途，但远程访问方案在这里可能比其他用途更受关注。
This document does not place any requirements on anyone and does not use [RFC2119] keywords such as "MUST" and "SHOULD", except in quotations from the original IKEv2 documents. The requirements are given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic algorithms document [IKEv2ALG].
本文件未对任何人提出任何要求，也未使用[RFC2119]关键词，如“必须”和“应该”，原始IKEv2文件的引用除外。IKEv2规范[IKEv2]和IKEv2加密算法文件[IKEv2ALG]中给出了这些要求。
In this document, references to a numbered section (such as "Section 2.15") mean that section in [IKEv2]. References to mailing list messages or threads refer to the IPsec WG mailing list at ipsec@ietf.org. Archives of the mailing list can be found at <http://www.ietf.org/mail-archive/web/ipsec/index.html>.
在本文件中，提及编号章节（如“第2.15节”）是指[IKEv2]中的章节。对邮件列表消息或线程的引用请参阅以下位置的IPsec WG邮件列表：ipsec@ietf.org. 邮件列表的档案可在以下网址找到：<http://www.ietf.org/mail-archive/web/ipsec/index.html>.
Normal IKE messages include the initiator's and responder's Security Parameter Indexes (SPIs), both of which are non-zero, in the IKE header. However, there are some corner cases where the IKEv2 specification is not fully consistent about what values should be used.
正常的IKE消息在IKE头中包括发起方和响应方的安全参数索引（SPI），它们都是非零的。然而，在某些情况下，IKEv2规范对于应使用的值并不完全一致。
First, Section 3.1 says that the Responder's SPI "...MUST NOT be zero in any other message" (than the first message of the IKE_SA_INIT exchange). However, the figure in Section 2.6 shows the second IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text in 3.1.
首先，第3.1节规定响应者的SPI“……在任何其他消息中不得为零”（IKE_SA_INIT交换的第一条消息除外）。但是，第2.6节中的图显示第二条IKE_SA_INIT消息为“HDR（A，0），N（COOKIE）”，与3.1中的文本相矛盾。
Since the responder's SPI identifies security-related state held by the responder, and in this case no state is created, sending a zero value seems reasonable.
由于响应者的SPI识别响应者持有的安全相关状态，并且在这种情况下不创建任何状态，因此发送零值似乎是合理的。
Second, in addition to cookies, there are several other cases when the IKE_SA_INIT exchange does not result in the creation of an IKE_SA (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). What responder SPI value should be used in the IKE_SA_INIT response in this case?
其次，除了cookie之外，还有其他几种情况下IKE_SA_INIT交换不会导致IKE_SA的创建（例如，无效的有效负载或未选择任何建议）。在这种情况下，IKE_SA_INIT响应中应该使用什么响应程序SPI值？
Since the IKE_SA_INIT request always has a zero responder SPI, the value will not be actually used by the initiator. Thus, we think sending a zero value is correct also in this case.
由于IKE_SA_INIT请求始终具有零响应程序SPI，因此该值实际上不会被启动器使用。因此，我们认为在这种情况下发送零值也是正确的。
If the responder sends a non-zero responder SPI, the initiator should not reject the response only for that reason. However, when retrying the IKE_SA_INIT request, the initiator will use a zero responder SPI, as described in Section 3.1: "Responder's SPI [...] This value MUST be zero in the first message of an IKE Initial Exchange (including repeats of that message including a cookie) [...]". We believe the intent was to cover repeats of that message due to other reasons, such as INVALID_KE_PAYLOAD, as well.
如果响应程序发送非零响应程序SPI，则发起程序不应仅出于该原因拒绝响应。但是，当重试IKE_SA_INIT请求时，启动器将使用零响应程序SPI，如第3.1节所述：“响应程序的SPI[…]此值在IKE初始交换的第一条消息中必须为零（包括该消息的重复，包括cookie）[…]”。我们认为其目的是为了涵盖由于其他原因（例如无效的负载）导致的该消息的重复。
(References: "INVALID_KE_PAYLOAD and clarifications document" thread, Sep-Oct 2005.)
（参考资料：“无效的有效载荷和澄清文件”thread，2005年9月至10月。）
The Message ID for IKE_SA_INIT messages is always zero. This includes retries of the message due to responses such as COOKIE and INVALID_KE_PAYLOAD.
IKE_SA_INIT消息的消息ID始终为零。这包括由于COOKIE和无效负载等响应而重试消息。
This is because Message IDs are part of the IKE_SA state, and when the responder replies to IKE_SA_INIT request with N(COOKIE) or N(INVALID_KE_PAYLOAD), the responder does not allocate any state.
这是因为消息ID是IKE_SA状态的一部分，并且当响应者使用N（COOKIE）或N（无效的_KE_负载）响应IKE_SA_INIT请求时，响应者不会分配任何状态。
(References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD) combination" thread, Oct 2004. Tero Kivinen's mail "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
（参考资料：“关于N（COOKIE）和N（无效负载）组合的问题”thread，2004年10月。Tero Kivinen的邮件“draft-eronen-ipsec-ikev2-Diclarations-02.txt的评论”，2005-04-05。）
When a responder receives an IKE_SA_INIT request, it has to determine whether the packet is a retransmission belonging to an existing "half-open" IKE_SA (in which case the responder retransmits the same response), or a new request (in which case the responder creates a new IKE_SA and sends a fresh response).
当响应者接收到IKE_SA_INIT请求时，它必须确定该数据包是属于现有“半开放”IKE_SA的重传（在这种情况下，响应者重传相同的响应）还是新的请求（在这种情况下，响应者创建新的IKE_SA并发送新的响应）。
The specification does not describe in detail how this determination is done. In particular, it is not sufficient to use the initiator's SPI and/or IP address for this purpose: two different peers behind a single NAT could choose the same initiator SPI (and the probability
本规范未详细说明如何进行该测定。特别是，仅使用启动器的SPI和/或IP地址是不够的：单个NAT后面的两个不同对等方可以选择相同的启动器SPI（和概率）
of this happening is not necessarily small, since IKEv2 does not require SPIs to be chosen randomly). Instead, the responder should do the IKE_SA lookup using the whole packet or its hash (or at the minimum, the Ni payload which is always chosen randomly).
这种情况发生的概率不一定很小，因为IKEv2不需要随机选择SPI）。相反，响应者应该使用整个数据包或其散列（或至少是总是随机选择的Ni有效载荷）进行IKE_SA查找。
For all other packets than IKE_SA_INIT requests, looking up right IKE_SA is of course done based on the recipient's SPI (either the initiator or responder SPI depending on the value of the Initiator bit in the IKE header).
对于IKE_SA_INIT请求以外的所有其他数据包，当然根据接收方的SPI（启动器或响应程序SPI，取决于IKE头中启动器位的值）查找右侧IKE_SA。
There are two common reasons why the initiator may have to retry the IKE_SA_INIT exchange: the responder requests a cookie or wants a different Diffie-Hellman group than was included in the KEi payload. Both of these cases are quite simple alone, but it is not totally obvious what happens when they occur at the same time, that is, the IKE_SA_INIT exchange is retried several times.
发起方可能必须重试IKE_SA_INIT交换有两个常见原因：响应方请求cookie或想要不同于KEi有效负载中包含的Diffie Hellman组。这两种情况都很简单，但它们同时发生时会发生什么并不完全清楚，即IKE_SA_INIT交换会重试几次。
The main question seems to be the following: if the initiator receives a cookie from the responder, should it include the cookie in only the next retry of the IKE_SA_INIT request, or in all subsequent retries as well? Section 3.10.1 says that:
主要问题似乎是：如果发起方从响应方接收到cookie，那么它应该只在IKE_SA_INIT请求的下一次重试中包含cookie，还是在所有后续重试中也包含cookie？第3.10.1节规定：
"This notification MUST be included in an IKE_SA_INIT request retry if a COOKIE notification was included in the initial response."
“如果初始响应中包含COOKIE通知，则此通知必须包含在IKE_SA_INIT请求重试中。”
This could be interpreted as saying that when a cookie is received in the initial response, it is included in all retries. On the other hand, Section 2.6 says that:
这可以解释为，当在初始响应中接收到cookie时，它将包含在所有重试中。另一方面，第2.6节规定：
"Initiators who receive such responses MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE containing the responder supplied cookie data as the first payload and all other payloads unchanged."
“接收此类响应的启动器必须重试IKE_SA_INIT，并使用COOKIE类型的通知有效负载，其中包含响应者提供的COOKIE数据作为第一个有效负载，所有其他有效负载保持不变。”
Including the same cookie in later retries makes sense only if the "all other payloads unchanged" restriction applies only to the first retry, but not to subsequent retries.
只有当“所有其他有效负载不变”限制仅适用于第一次重试，而不适用于后续重试时，在以后的重试中包含相同的cookie才有意义。
It seems that both interpretations can peacefully coexist. If the initiator includes the cookie only in the next retry, one additional roundtrip may be needed in some cases:
这两种解释似乎可以和平共存。如果启动器仅在下一次重试中包含cookie，则在某些情况下可能需要一次额外的往返：
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), SAi1, KEi', Ni -->
<-- HDR(A,0), N(COOKIE')
HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), SAi1, KEi', Ni -->
<-- HDR(A,0), N(COOKIE')
HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
An additional roundtrip is needed also if the initiator includes the cookie in all retries, but the responder does not support this functionality. For instance, if the responder includes the SAi1 and KEi payloads in cookie calculation, it will reject the request by sending a new cookie (see also Section 2.5 of this document for more text about invalid cookies):
如果发起方在所有重试中都包含cookie，但响应方不支持此功能，则还需要额外的往返。例如，如果响应者在cookie计算中包含SAi1和KEi有效负载，它将通过发送新cookie拒绝请求（有关无效cookie的更多文本，请参见本文档第2.5节）：
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
<-- HDR(A,0), N(COOKIE')
HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
<-- HDR(A,0), N(COOKIE')
HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
If both peers support including the cookie in all retries, a slightly shorter exchange can happen:
如果两个对等方都支持在所有重试中包含cookie，则可能会发生稍短的交换：
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
This document recommends that implementations should support this shorter exchange, but it must not be assumed the other peer also supports the shorter exchange.
本文档建议实现应支持此较短的交换，但不能假设其他对等方也支持此较短的交换。
In theory, even this exchange has one unnecessary roundtrip, as both the cookie and Diffie-Hellman group could be checked at the same time:
理论上，即使这种交换也有一个不必要的往返，因为cookie和Diffie Hellman组可以同时检查：
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE),
N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi',Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE),
N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi',Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
However, it is clear that this case is not allowed by the text in Section 2.6, since "all other payloads" clearly includes the KEi payload as well.
然而，很明显，第2.6节中的文本不允许这种情况，因为“所有其他有效载荷”显然也包括KEi有效载荷。
(References: "INVALID_KE_PAYLOAD and clarifications document" thread, Sep-Oct 2005.)
（参考资料：“无效的有效载荷和澄清文件”thread，2005年9月至10月。）
There has been some confusion what should be done when an IKE_SA_INIT request containing an invalid cookie is received ("invalid" in the sense that its contents do not match the value expected by the responder).
当接收到包含无效cookie的IKE_SA_INIT请求时（在其内容与响应者期望的值不匹配的意义上为“无效”），应该怎么做有些混乱。
The correct action is to ignore the cookie and process the message as if no cookie had been included (usually this means sending a response containing a new cookie). This is shown in Section 2.6 when it says "The responder in that case MAY reject the message by sending another response with a new cookie [...]".
正确的操作是忽略cookie，并像未包含cookie一样处理消息（通常这意味着发送包含新cookie的响应）。第2.6节显示了这一点，其中说“在这种情况下，响应者可以通过发送另一个带有新cookie的响应来拒绝消息[…]”。
Other possible actions, such as ignoring the whole request (or even all requests from this IP address for some time), create strange failure modes even in the absence of any malicious attackers and do not provide any additional protection against DoS attacks.
其他可能的操作，例如忽略整个请求（甚至在一段时间内忽略来自此IP地址的所有请求），即使在没有任何恶意攻击者的情况下也会创建奇怪的故障模式，并且不会提供任何针对DoS攻击的额外保护。
(References: "Invalid Cookie" thread, Sep-Oct 2005.)
（参考资料：“无效Cookie”线程，2005年9月至10月。）
Section 2.15 describes how the AUTH payloads are calculated; this calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The text describes the method in words, but does not give clear definitions of what is signed or MACed (i.e., protected with a message authentication code).
第2.15节描述了如何计算AUTH有效载荷；该计算涉及prf（SK_pi，IDi'）和prf（SK_pr，IDr'）的值。本文用文字描述了该方法，但没有给出签名或标记内容的明确定义（即，使用消息身份验证代码进行保护）。
The initiator's signed octets can be described as:
启动器的签名八位字节可以描述为：
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData
MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData
MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
The responder's signed octets can be described as:
响应者的签名八位字节可以描述为：
ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage2 = RealIKEHDR | RestOfMessage2
NonceIPayload = PayloadHeader | NonceIData
ResponderIDPayload = PayloadHeader | RestOfIDPayload
RestOfRespIDPayload = IDType | RESERVED | InitIDData
MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage2 = RealIKEHDR | RestOfMessage2
NonceIPayload = PayloadHeader | NonceIData
ResponderIDPayload = PayloadHeader | RestOfIDPayload
RestOfRespIDPayload = IDType | RESERVED | InitIDData
MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
Section 3.8 says that RSA digital signature is "Computed as specified in section 2.15 using an RSA private key over a PKCS#1 padded hash."
第3.8节说，RSA数字签名“按照第2.15节的规定，使用PKCS#1填充哈希上的RSA私钥计算。”
Unlike IKEv1, IKEv2 does not negotiate a hash function for the IKE_SA. The algorithm for signatures is selected by the signing party who, in general, may not know beforehand what algorithms the verifying party supports. Furthermore, [IKEv2ALG] does not say what algorithms implementations are required or recommended to support. This clearly has a potential for causing interoperability problems, since authentication will fail if the signing party selects an algorithm that is not supported by the verifying party, or not acceptable according to the verifying party's policy.
与IKEv1不同，IKEv2不协商IKE_SA的哈希函数。签名算法由签名方选择，通常，签名方可能事先不知道验证方支持什么算法。此外，[IKEv2ALG]没有说明需要或建议支持哪些算法实现。这显然有可能导致互操作性问题，因为如果签名方选择了验证方不支持的算法，或者根据验证方的策略不可接受的算法，则身份验证将失败。
This document recommends that all implementations support SHA-1 and use SHA-1 as the default hash function when generating the signatures, unless there are good reasons (such as explicit manual configuration) to believe that the peer supports something else.
本文档建议所有实现都支持SHA-1，并在生成签名时使用SHA-1作为默认哈希函数，除非有充分的理由（如显式手动配置）相信对等方支持其他功能。
Note that hash function collision attacks are not important for the AUTH payloads, since they are not intended for third-party verification, and the data includes fresh nonces. See [HashUse] for more discussion about hash function attacks and IPsec.
请注意，哈希函数冲突攻击对于身份验证有效负载并不重要，因为它们不用于第三方验证，并且数据包含新的nonce。有关哈希函数攻击和IPsec的更多讨论，请参阅[HashUse]。
Another reasonable choice would be to use the hash function that was used by the CA when signing the peer certificate. However, this does not guarantee that the IKEv2 peer would be able to validate the AUTH payload, because the same code might not be used to validate certificate signatures and IKEv2 message signatures, and these two routines may support a different set of hash algorithms. The peer could be configured with a fingerprint of the certificate, or certificate validation could be performed by an external entity using [SCVP]. Furthermore, not all CERT payloads types include a signature, and the certificate could be signed with some algorithm other than RSA.
另一个合理的选择是使用CA在签署对等证书时使用的哈希函数。然而，这并不保证IKEv2对等方能够验证验证有效载荷，因为相同的代码可能不用于验证证书签名和IKEv2消息签名，并且这两个例程可能支持不同的哈希算法集。对等方可以配置证书的指纹，或者可以由外部实体使用[SCVP]执行证书验证。此外，并非所有证书有效负载类型都包含签名，并且可以使用RSA以外的算法对证书进行签名。
Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20] signature encoding method (see next section for details), which includes the algorithm identifier for the hash algorithm. Thus, when the verifying party receives the AUTH payload it can at least determine which hash function was used.
请注意，与IKEv1不同，IKEv2使用PKCS#1 v1.5[PKCS1v20]签名编码方法（详见下一节），其中包括哈希算法的算法标识符。因此，当验证方接收到AUTH有效载荷时，它至少可以确定使用了哪个散列函数。
(References: Magnus Alstrom's mail "RE:", 2005-01-03. Pasi Eronen's reply, 2005-01-04. Tero Kivinen's reply, 2005-01-04. "First draft of IKEv2.1" thread, Dec 2005/Jan 2006.)
（参考资料：Magnus Alstrom的邮件“RE:”，2005-01-03。Pasi Eronen的回复，2005-01-04。Tero Kivinen的回复，2005-01-04。“IKEv2.1”的初稿，2005年12月/2006年1月。）
Section 3.8 says that the RSA digital signature is "Computed as specified in section 2.15 using an RSA private key over a PKCS#1 padded hash."
第3.8节说，RSA数字签名“按照第2.15节的规定，使用PKCS#1填充哈希上的RSA私钥进行计算。”
The PKCS#1 specification [PKCS1v21] defines two different encoding methods (ways of "padding the hash") for signatures. However, the Internet-Draft approved by the IESG had a reference to the older PKCS#1 v2.0 [PKCS1v20]. That version has only one encoding method for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity.
PKCS#1规范[PKCS1v21]为签名定义了两种不同的编码方法（“填充哈希”的方式）。然而，IESG批准的互联网草案参考了较旧的PKCS#1 v2.0[PKCS1v20]。该版本只有一种签名编码方法（EMSA-PKCS1-v1_5），因此不存在歧义。
Note that this encoding method is different from the encoding method used in IKEv1. If future revisions of IKEv2 provide support for other encoding methods (such as EMSA-PSS), they will be given new Auth Method numbers.
请注意，此编码方法与IKEv1中使用的编码方法不同。如果IKEv2的未来版本支持其他编码方法（如EMSA-PSS），则将为其提供新的Auth方法编号。
(References: Pasi Eronen's mail "RE:", 2005-01-04.)
（参考文献：帕西·埃隆的邮件“RE:”，2005-01-04）
Section 3.5 defines several different types for identification payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID. EAP [EAP] does not mandate the use of any particular type of identifier, but often EAP is used with Network Access Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like email addresses (e.g., "joe@example.com"), the syntax is not exactly the same as the syntax of email address in [RFC822]. This raises the question of which identification type should be used.
第3.5节定义了识别有效载荷的几种不同类型，包括，例如，ID_FQDN、ID_RFC822_ADDR和ID_KEY_ID。EAP[EAP]不强制使用任何特定类型的标识符，但通常EAP与[NAI]中定义的网络访问标识符（NAI）一起使用。虽然NAI看起来有点像电子邮件地址（例如“joe@example.com），语法与[RFC822]中电子邮件地址的语法不完全相同。这就提出了应该使用哪种标识类型的问题。
This document recommends that ID_RFC822_ADDR identification type is used for those NAIs that include the realm component. Therefore, responder implementations should not attempt to verify that the contents actually conform to the exact syntax given in [RFC822] or [RFC2822], but instead should accept any reasonable looking NAI.
本文档建议对包含领域组件的NAI使用ID \u RFC822 \u ADDR标识类型。因此，响应程序实现不应尝试验证内容是否确实符合[RFC822]或[RFC2822]中给出的确切语法，而应接受任何外观合理的NAI。
For NAIs that do not include the realm component, this document recommends using the ID_KEY_ID identification type.
对于不包括领域组件的NAI，本文档建议使用ID_KEY_ID标识类型。
(References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2 identifier issue with EAP" threads, Aug 2004.)
（参考资料：“在这个IKEv2/i18n/EAP问题上需要您的帮助”和“关于EAP的IKEv2标识符问题”，2004年8月。）
When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method (see [EAP], Sections 5.1 and 7.3).
当启动器身份验证使用EAP时，IDi有效负载的内容可能仅用于AAA路由目的和选择要使用的EAP方法。该值可能不同于EAP方法认证的身份（见[EAP]，第5.1和7.3节）。
It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder using, e.g., RADIUS [RADEAP]. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder.
重要的是，策略查找和访问控制决策使用实际的经过身份验证的身份。EAP服务器通常在单独的AAA服务器中实现，该服务器使用RADIUS[RADEAP]等与IKEv2响应程序进行通信。在这种情况下，必须将经过身份验证的标识从AAA服务器发送到IKEv2响应程序。
(References: Pasi Eronen's mail "RE: Reauthentication in IKEv2", 2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748, Section 7.3.)
（参考文献：Pasi Eronen的邮件“RE:IKEv2中的重新验证”，2004-10-28，“策略查找”线程，2004年10月/11月。RFC 3748，第7.3节。）
Section 3.6 defines a total of twelve different certificate encoding types, and continues that "Specific syntax is for some of the certificate type codes above is not defined in this document." However, the text does not provide references to other documents that would contain information about the exact contents and use of those values.
第3.6节定义了总共12种不同的证书编码类型，并继续说明“本文件中未定义上述某些证书类型代码的特定语法”。但是，本文本未提供包含这些值的确切内容和使用信息的其他文件的参考。
Without this information, it is not possible to develop interoperable implementations. Therefore, this document recommends that the following certificate encoding values should not be used before new specifications that specify their use are available.
没有这些信息，就不可能开发可互操作的实现。因此，本文档建议在指定使用的新规范可用之前，不应使用以下证书编码值。
PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 Kerberos Token 6 SPKI Certificate 9
PKCS#7包装的X.509证书1 PGP证书2 DNS签名密钥3 Kerberos令牌6 SPKI证书9
This document recommends that most implementations should use only those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e., "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle" (13).
本文件建议大多数实施应仅使用[IKEv2]中“必须”/“应该”要求的值；i、 例如，“X.509证书-签名”（4）、“原始RSA密钥”（11）、“X.509证书的哈希和URL”（12）和“X.509捆绑包的哈希和URL”（13）。
Furthermore, Section 3.7 says that the "Certificate Encoding" field for the Certificate Request payload uses the same values as for Certificate payload. However, the contents of the "Certification Authority" field are defined only for X.509 certificates (presumably covering at least types 4, 10, 12, and 13). This document recommends that other values should not be used before new specifications that specify their use are available.
此外，第3.7节指出，证书请求有效负载的“证书编码”字段使用与证书有效负载相同的值。但是，“Certificate Authority”字段的内容仅为X.509证书定义（可能至少涵盖类型4、10、12和13）。本文件建议，在指定其用途的新规范可用之前，不应使用其他值。
The "Raw RSA Key" type needs one additional clarification. Section 3.6 says it contains "a PKCS #1 encoded RSA key". What this means is a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21].
“原始RSA密钥”类型需要一个额外的说明。第3.6节说它包含“一个PKCS#1编码的RSA密钥”。这意味着来自PKCS#1[PKCS1v21]的DER编码的RSACPublicKey结构。
Section 2.15 says that "If the negotiated prf takes a fixed-size key, the shared secret MUST be of that fixed size". This statement is correct: the shared secret must be of the correct size. If it is not, it cannot be used; there is no padding, truncation, or other processing involved to force it to that correct size.
第2.15节规定，“如果协商的prf采用固定大小的密钥，则共享密钥必须具有该固定大小”。此语句正确：共享机密的大小必须正确。如果没有，就不能使用；不需要填充、截断或其他处理来强制它达到正确的大小。
This requirement means that it is difficult to use these pseudo-random functions (PRFs) with shared key authentication. The authors think this part of the specification was very poorly thought out, and using PRFs with a fixed key size is likely to result in interoperability problems. Thus, we recommend that such PRFs should not be used with shared key authentication. PRF_AES128_XCBC [RFC3664] originally used fixed key sizes; that RFC has been updated to handle variable key sizes in [RFC4434].
这一要求意味着很难将这些伪随机函数（PRF）与共享密钥身份验证一起使用。作者认为规范的这一部分考虑得非常糟糕，使用具有固定密钥大小的PRF可能会导致互操作性问题。因此，我们建议此类PRF不应与共享密钥身份验证一起使用。PRF_AES128_XCBC[RFC3664]最初使用固定密钥大小；该RFC已在[RFC4434]中更新，以处理可变密钥大小。
Note that Section 2.13 also contains text that is related to PRFs with fixed key size: "When the key for the prf function has fixed length, the data provided as a key is truncated or padded with zeros as necessary unless exceptional processing is explained following the formula". However, this text applies only to the prf+ construction, so it does not contradict the text in Section 2.15.
请注意，第2.13节还包含与具有固定键大小的prf相关的文本：“当prf函数的键具有固定长度时，作为键提供的数据根据需要被截断或用零填充，除非按照公式解释异常处理”。但是，本文本仅适用于prf+结构，因此与第2.15节中的文本不矛盾。
(References: Paul Hoffman's mail "Re: ikev2-07: last nits", 2003-05-02. Hugo Krawczyk's reply, 2003-05-12. Thread "Question about PRFs with fixed size key", Jan 2005.)
（参考文献：Paul Hoffman的邮件“Re:ikev2-07:最后一次nits”，2003-05-02。Hugo Krawczyk的回复，2003-05-12。线程“关于固定大小键的PRF的问题”，2005年1月。）
As described in the previous section, PRFs with a fixed key size require a shared secret of exactly that size. This restriction applies also to EAP authentication. For instance, a PRF that requires a 128-bit key cannot be used with EAP since [EAP] specifies that the MSK is at least 512 bits long.
如前一节所述，具有固定密钥大小的PRF需要一个大小正好相同的共享秘密。此限制也适用于EAP身份验证。例如，需要128位密钥的PRF不能与EAP一起使用，因为[EAP]指定MSK的长度至少为512位。
(References: Thread "Question about PRFs with fixed size key", Jan 2005.)
（参考文献：2005年1月“关于固定大小键的PRF的问题”一文。）
In IKEv1, there was some confusion about whether or not the identities in certificates used to authenticate IKE were required to match the contents of the ID payloads. The PKI4IPsec Working Group produced the document [PKI4IPsec] which covers this topic in much more detail. However, Section 3.5 of [IKEv2] explicitly says that the ID payload "does not necessarily have to match anything in the CERT payload".
在IKEv1中，对于用于认证IKE的证书中的标识是否需要与ID有效负载的内容匹配，存在一些混淆。PKI4IPsec工作组编制了文件[PKI4IPsec]，其中更详细地介绍了这一主题。然而，[IKEv2]第3.5节明确指出，ID有效载荷“不一定必须与证书有效载荷中的任何内容相匹配”。
According to Section 2.2, "The IKE_SA initial setup messages will always be numbered 0 and 1." That is true when the IKE_AUTH exchange does not use EAP. When EAP is used, each pair of messages has their message numbers incremented. The first pair of AUTH messages will have an ID of 1, the second will be 2, and so on.
根据第2.2节，“IKE_SA初始设置消息将始终编号为0和1。”这在IKE_认证交换不使用EAP时是正确的。使用EAP时，每对消息的消息编号都会递增。第一对身份验证消息的ID为1，第二对为2，依此类推。
(References: "Question about MsgID in AUTH exchange" thread, April 2005.)
（参考资料：“关于身份验证交换中MsgID的问题”线程，2005年4月。）
Section 1.3's organization does not lead to clear understanding of what is needed in which environment. The section can be reorganized with subsections for each use of the CREATE_CHILD_SA exchange (creating child SAs, rekeying IKE SAs, and rekeying child SAs.)
第1.3节的组织无法清晰地理解在哪个环境中需要什么。对于每次使用CREATE_CHILD_SA交换（创建子SA、为IKE SA重新设置密钥和为子SA重新设置密钥），可以使用子部分重新组织该部分
The new Section 1.3 with subsections and the above changes might look like the following.
新的第1.3节（包含小节）和上述更改可能如下所示。
NEW-1.3 The CREATE_CHILD_SA Exchange
新建-1.3创建子交换
The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and to rekey both IKE_SAs and CHILD_SAs. This exchange consists of a single request/response pair, and some of its function was referred to as a phase 2 exchange in IKEv1. It MAY be initiated by either end of the IKE_SA after the initial exchanges are completed.
CREATE_CHILD_SA交换用于创建新的CHILD_SA以及为IKE_SA和CHILD_SA重新设置密钥。此交换由单个请求/响应对组成，其部分功能在IKEv1中称为阶段2交换。初始交换完成后，可由IKE_SA的任何一端启动。
All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the first two messages of the IKE exchange. These subsequent messages use the syntax of the Encrypted Payload described in section 3.14. All subsequent messages include an Encrypted Payload, even if they are referred to in the text as "empty".
初始交换之后的所有消息都使用在IKE交换的前两条消息中协商的加密算法和密钥进行加密保护。这些后续消息使用第3.14节中描述的加密有效负载的语法。所有后续消息都包含加密的有效负载，即使它们在文本中被称为“空”。
The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs. This section describes the first part of rekeying, the creation of new SAs; Section 2.8 covers the mechanics of rekeying, including moving traffic from old to new SAs and the deletion of the old SAs. The two sections must be read together to understand the entire process of rekeying.
CREATE_CHILD_SA用于为IKE_SA和CHILD_SA重新设置密钥。本节介绍了密钥更新的第一部分，即新SA的创建；第2.8节介绍了密钥更新机制，包括将流量从旧SA移动到新SA以及删除旧SA。这两个部分必须一起阅读，以了解重新键入的整个过程。
Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this section the term initiator refers to the endpoint initiating this exchange. An implementation MAY refuse all CREATE_CHILD_SA requests within an IKE_SA.
任何一个端点都可以启动CREATE_CHILD_SA交换，因此在本节中，术语initiator指启动此交换的端点。实现可以拒绝IKE_SA中的所有CREATE_CHILD_SA请求。
The CREATE_CHILD_SA request MAY optionally contain a KE payload for an additional Diffie-Hellman exchange to enable stronger guarantees of forward secrecy for the CHILD_SA or IKE_SA. The keying material for the SA is a function of SK_d established during the establishment of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA exchange, and the Diffie-Hellman value (if KE payloads are included in the CREATE_CHILD_SA exchange). The details are described in sections 2.17 and 2.18.
CREATE_CHILD_SA请求可以选择性地包含用于额外Diffie-Hellman交换的KE有效载荷，以实现对CHILD_SA或IKE_SA的前向保密性的更有力保证。SA的键控材料是在IKE_SA建立期间建立的SK_d、在CREATE_CHILD_SA交换期间交换的nonce和Diffie Hellman值（如果在CREATE_CHILD_SA交换中包括KE有效载荷）的函数。详情见第2.17节和第2.18节。
If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of the SA offers MUST include the Diffie-Hellman group of the KEi. The Diffie-Hellman group of the KEi MUST be an element of the group the initiator expects the responder to accept (additional Diffie-Hellman groups can be proposed). If the responder rejects the Diffie-Hellman group of the KEi payload, the responder MUST reject the request and indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification payload. In the case of such a rejection, the CREATE_CHILD_SA exchange fails, and the initiator SHOULD retry the exchange with a Diffie-Hellman proposal and KEi in the group that the responder gave in the INVALID_KE_PAYLOAD.
如果一个组中至少有一个keisa包含keisa，则必须创建一个组中的keisa。KEi的Diffie-Hellman组必须是发起方希望响应方接受的组的一个元素（可以提出其他Diffie-Hellman组）。如果响应者拒绝KEi有效负载的Diffie-Hellman组，则响应者必须拒绝该请求，并在无效的KEU有效负载通知有效负载中指示其首选的Diffie-Hellman组。在这种拒绝的情况下，CREATE_CHILD_SA交换失败，发起方应使用Diffie Hellman建议和响应方在无效的_KE_负载中给出的组中的KEi重试交换。
NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
新建-1.3.1使用创建子SA交换创建新的子SA
A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The CREATE_CHILD_SA request for creating a new CHILD_SA is:
可以通过发送创建子SA请求来创建子SA。用于创建新子项的创建子项请求是：
Initiator Responder
----------- -----------
HDR, SK {[N+], SA, Ni, [KEi],
TSi, TSr} -->
Initiator Responder
----------- -----------
HDR, SK {[N+], SA, Ni, [KEi],
TSi, TSr} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, optionally a Diffie-Hellman value in the KEi payload, and the proposed traffic selectors for the proposed CHILD_SA in the TSi and TSr payloads. The request can also contain Notify payloads that specify additional details for the CHILD_SA: these include IPCOMP_SUPPORTED, USE_TRANSPORT_MODE, ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO.
发起者发送SA有效载荷中的SA offer、Ni有效载荷中的nonce、KEi有效载荷中可选的Diffie-Hellman值，以及TSi和TSr有效载荷中建议的子_SA的建议流量选择器。该请求还可以包含通知有效载荷，这些载荷指定子级SA的其他详细信息：这些载荷包括支持的IPCOMP、使用传输模式、不支持的ESP、TFC和非优先片段。
The CREATE_CHILD_SA response for creating a new CHILD_SA is:
Usa_正在为子对象创建一个新的响应：
<-- HDR, SK {[N+], SA, Nr,
[KEr], TSi, TSr}
<-- HDR, SK {[N+], SA, Nr,
[KEr], TSi, TSr}
The responder replies with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group. As with the request, optional Notification payloads can specify additional details for the CHILD_SA.
如果请求中包含KEi且所选加密套件包含该组，则响应者在SA有效负载中回复接受的报价，并在KEr有效负载中回复Diffie Hellman值。与请求一样，可选通知有效负载可以指定子_SA的其他详细信息。
The traffic selectors for traffic to be sent on that SA are specified in the TS payloads in the response, which may be a subset of what the initiator of the CHILD_SA proposed.
要在该SA上发送的流量的流量选择器在响应中的TS有效负载中指定，这可能是子SA的发起方所建议的子集。
The text about rekeying SAs can be found in Section 5.1 of this document.
本文件第5.1节中提供了有关重新设置SAs密钥的文本。
CHILD_SAs can be created either by being piggybacked on the IKE_AUTH exchange, or using a separate CREATE_CHILD_SA exchange. The specification is not clear about what happens if creating the CHILD_SA during the IKE_AUTH exchange fails for some reason.
可以通过在IKE_身份验证交换上搭载或使用单独的CREATE_CHILD_SA交换来创建子SA。该规范不清楚如果在IKE_身份验证交换期间创建子_SA由于某种原因失败会发生什么。
Our recommendation in this situation is that the IKE_SA is created as usual. This is also in line with how the CREATE_CHILD_SA exchange works: a failure to create a CHILD_SA does not close the IKE_SA.
在这种情况下，我们建议像往常一样创建IKE_SA。这也与CREATE_CHILD_SA交换的工作原理一致：未能创建CHILD_SA不会关闭IKE_SA。
The list of responses in the IKE_AUTH exchange that do not prevent an IKE_SA from being set up include at least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
IKE_身份验证交换中不阻止IKE_SA设置的响应列表至少包括以下内容：未选择提议、TS_不可接受、需要单对、内部地址失败以及需要失败的CP。
(References: "Questions about internal address" thread, April 2005.)
（参考资料：“关于内部地址的问题”线程，2005年4月。）
Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. This implies that the SA payload in IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with any other value than NONE. Implementations should probably leave the transform out entirely in this case.
第1.2节显示IKE_AUTH消息不包含KEi/KEr或Ni/Nr有效载荷。这意味着IKE_AUTH exchange中的SA有效负载不能包含转换类型4（Diffie Hellman组）以及除NONE之外的任何其他值。在这种情况下，实现可能应该完全忽略转换。
The description of the ESN transform in Section 3.3 has be proved difficult to understand. The ESN transform has the following meaning:
第3.3节中ESN变换的描述已证明难以理解。ESN转换具有以下含义：
o A proposal containing one ESN transform with value 0 means "do not use extended sequence numbers".
o 包含一个值为0的ESN转换的提案意味着“不要使用扩展序列号”。
o A proposal containing one ESN transform with value 1 means "use extended sequence numbers".
o 包含一个值为1的ESN转换的提案意味着“使用扩展序列号”。
o A proposal containing two ESN transforms with values 0 and 1 means "I support both normal and extended sequence numbers, you choose". (Obviously this case is only allowed in requests; the response will contain only one ESN transform.)
o 包含两个值为0和1的ESN转换的提案意味着“我支持正常序列号和扩展序列号，由您选择”。（显然，这种情况只允许在请求中使用；响应将只包含一个ESN转换。）
In most cases, the exchange initiator will include either the first or third alternative in its SA payload. The second alternative is rarely useful for the initiator: it means that using normal sequence numbers is not acceptable (so if the responder does not support ESNs, the exchange will fail with NO_PROPOSAL_CHOSEN).
在大多数情况下，exchange启动器将在其SA负载中包括第一个或第三个备选方案。第二种选择对发起方来说很少有用：这意味着使用正常序列号是不可接受的（因此，如果响应方不支持ESN，则交换将失败，且不选择任何建议）。
Note that including the ESN transform is mandatory when creating ESP/AH SAs (it was optional in earlier drafts of the IKEv2 specification).
请注意，在创建ESP/AH SA时，必须包含ESN转换（在早期的IKEv2规范草案中是可选的）。
(References: "Technical change needed to IKEv2 before publication", "STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2" and "Results of straw poll regarding: IKEv2 interoperability issue" threads, March-April 2005.)
（参考资料：“IKEv2出版前需要进行技术更改”、“STRAW民意测验：处理IKEv2中的ESN协商互操作问题”和“关于IKEv2互操作性问题的STRAW民意测验结果”，2005年3月至4月）
The description of ESP_TFC_PADDING_NOT_SUPPORTED notification in Section 3.10.1 says that "This notification asserts that the sending endpoint will NOT accept packets that contain Flow Confidentiality (TFC) padding".
第3.10.1节中对ESP_TFC_PADDING_NOT_SUPPORTED通知的描述表示“此通知声明发送端点将不接受包含流机密性（TFC）PADDING的数据包”。
However, the text does not say in which messages this notification should be included, or whether the scope of this notification is a single CHILD_SA or all CHILD_SAs of the peer.
但是，文本没有说明此通知应包含在哪些消息中，也没有说明此通知的范围是对等方的单个子SA还是所有子SA。
Our interpretation is that the scope is a single CHILD_SA, and thus this notification is included in messages containing an SA payload negotiating a CHILD_SA. If neither endpoint accepts TFC padding, this notification will be included in both the request proposing an SA and the response accepting it. If this notification is included
我们的解释是，作用域是一个CHILD_SA，因此此通知包含在包含与CHILD_SA协商的SA有效负载的消息中。如果两个端点都不接受TFC填充，则此通知将包含在提出SA的请求和接受SA的响应中。如果包含此通知
in only one of the messages, TFC padding can still be sent in one direction.
在只有一条消息中，TFC填充仍然可以向一个方向发送。
NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1 simply as "Used for fragmentation control. See [RFC4301] for explanation."
第3.10.1节也将非第一个碎片通知简单描述为“用于碎片控制。有关解释，请参阅[RFC4301]”
[RFC4301] says "Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port (or ICMP type/code or MH type) selectors MUST notify a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. The peer MUST reject this proposal if it will not accept non-initial fragments in this context. If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA."
[RFC4301]表示“将在隧道模式SA上传输非初始片段的实现，该模式SA使用非平凡端口（或ICMP类型/代码或MH类型）选择器必须通过IKE notify NON_FIRST_FRAGMENTS（IKE notify NON_FIRST_FRAGMENTS（IKE notify NON_FIRST_FRAGMENTS（IKE notify NON_FIRST_FRAGMENTS（IKE notify NON_FIRST_FRAGMENTS））有效载荷通知对等方。如果对等方在此上下文中不接受非初始片段，则该对等
However, it is not clear exactly how the negotiation works. Our interpretation is that the negotiation works the same way as for IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included in both the request proposing an SA and the response accepting it. In other words, if the peer "rejects this proposal", it only omits NON_FIRST_FRAGMENTS_ALSO notification from the response, but does not reject the whole CHILD_SA creation.
然而，目前尚不清楚谈判是如何进行的。我们的解释是，协商的工作方式与支持IPCOMP_并使用_传输_模式的方式相同：仅当提出SA的请求和接受SA的响应中都包含非第一个碎片通知时，才启用发送非第一个碎片。换句话说，如果对等方“拒绝该提议”，它只会从响应中省略非优先片段通知，而不会拒绝整个子SA创建。
As described in Section 3.13, the TSi/TSr payloads can include one or more individual traffic selectors.
如第3.13节所述，TSi/TSr有效载荷可包括一个或多个单独的流量选择器。
There is no requirement that TSi and TSr contain the same number of individual traffic selectors. Thus, they are interpreted as follows: a packet matches a given TSi/TSr if it matches at least one of the individual selectors in TSi, and at least one of the individual selectors in TSr.
没有要求TSi和TSr包含相同数量的单个流量选择器。因此，它们被解释为：如果数据包与TSi中的至少一个单独选择器以及TSr中的至少一个单独选择器相匹配，则它与给定TSi/TSr相匹配。
For instance, the following traffic selectors:
例如，以下流量选择器：
TSi = ((17, 100, 192.0.1.66-192.0.1.66),
(17, 200, 192.0.1.66-192.0.1.66))
TSr = ((17, 300, 0.0.0.0-255.255.255.255),
(17, 400, 0.0.0.0-255.255.255.255))
TSi = ((17, 100, 192.0.1.66-192.0.1.66),
(17, 200, 192.0.1.66-192.0.1.66))
TSr = ((17, 300, 0.0.0.0-255.255.255.255),
(17, 400, 0.0.0.0-255.255.255.255))
would match UDP packets from 192.0.1.66 to anywhere, with any of the four combinations of source/destination ports (100,300), (100,400), (200,300), and (200, 400).
将从192.0.1.66到任意位置的UDP数据包与源/目标端口（100300）、（100400）、（200300）和（200400）的四种组合中的任意一种匹配。
This implies that some types of policies may require several CHILD_SA pairs. For instance, a policy matching only source/destination ports (100,300) and (200,400), but not the other two combinations, cannot be negotiated as a single CHILD_SA pair using IKEv2.
这意味着某些类型的策略可能需要多个子策略对。例如，仅匹配源/目标端口（100300）和（200400），但不匹配其他两个组合的策略不能使用IKEv2作为单个子_SA对进行协商。
(References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)
（参考资料：“IKEv2流量选择器？”线程，2005年2月）
The traffic selector types 7 and 8 can also refer to ICMP type and code fields. As described in Section 3.13.1, "For the ICMP protocol, the two one-octet fields Type and Code are treated as a single 16-bit integer (with Type in the most significant eight bits and Code in the least significant eight bits) port number for the purposes of filtering based on this field."
流量选择器类型7和8也可以引用ICMP类型和代码字段。如第3.13.1节所述，“对于ICMP协议，两个一个八位字节字段类型和代码被视为单个16位整数（类型为最高有效八位，代码为最低有效八位）端口号，以便基于此字段进行过滤。”
Since ICMP packets do not have separate source and destination port fields, there is some room for confusion what exactly the four TS payloads (two in the request, two in the response, each containing both start and end port fields) should contain.
由于ICMP数据包没有单独的源端口和目标端口字段，因此有一些混淆的余地，即四个TS有效负载（两个在请求中，两个在响应中，每个都包含开始和结束端口字段）到底应该包含什么。
The answer to this question can be found from [RFC4301] Section 4.4.1.3.
该问题的答案可从[RFC4301]第4.4.1.3节中找到。
To give a concrete example, if a host at 192.0.1.234 wants to create a transport mode SA for sending "Destination Unreachable" packets (ICMPv4 type 3) to 192.0.2.155, but is not willing to receive them over this SA pair, the CREATE_CHILD_SA exchange would look like this:
举一个具体的例子，如果192.0.1.234处的主机想要创建一个传输模式SA，用于向192.0.2.155发送“目的地不可到达”数据包（ICMPv4类型3），但不愿意通过该SA对接收它们，则create_CHILD_SA交换如下所示：
Initiator Responder
----------- -----------
HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } -->
Initiator Responder
----------- -----------
HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } -->
<-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 65535-0, 192.0.2.155-192.0.2.155) }
<-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 65535-0, 192.0.2.155-192.0.2.155) }
Since IKEv2 always creates IPsec SAs in pairs, two SAs are also created in this case, even though the second SA is never used for data traffic.
由于IKEv2始终成对创建IPsec SA，因此在这种情况下也会创建两个SA，即使第二个SA从未用于数据通信。
An exchange creating an SA pair that can be used both for sending and receiving "Destination Unreachable" places the same value in all the port:
创建可用于发送和接收“目标不可访问”的SA对的exchange在所有端口中放置相同的值：
Initiator Responder
----------- -----------
HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } -->
Initiator Responder
----------- -----------
HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } -->
<-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) }
<-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) }
(References: "ICMP and MH TSs for IKEv2" thread, Sep 2005.)
（参考资料：“IKEv2的ICMP和MH TSs”线程，2005年9月。）
Traffic selectors can use IP Protocol ID 135 to match the IPv6 mobility header [MIPv6]. However, the IKEv2 specification does not define how to represent the "MH Type" field in traffic selectors.
流量选择器可以使用IP协议ID 135来匹配IPv6移动报头[MIPv6]。但是，IKEv2规范没有定义如何在流量选择器中表示“MH类型”字段。
At some point, it was expected that this will be defined in a separate document later. However, [RFC4301] says that "For IKE, the IPv6 mobility header message type (MH type) is placed in the most significant eight bits of the 16 bit local "port" selector". The direction semantics of TSi/TSr port fields are the same as for ICMP and are described in the previous section.
在某种程度上，预计这将在稍后的单独文档中定义。然而，[RFC4301]表示，“对于IKE，IPv6移动报头消息类型（MH类型）位于16位本地“端口”选择器的最重要8位。TSi/TSr端口字段的方向语义与ICMP相同，在上一节中进行了描述。
(References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header message type as selector", 2003-10-14. "ICMP and MH TSs for IKEv2" thread, Sep 2005.)
（参考文献：Tero Kivinen的邮件“问题86：添加IPv6移动头消息类型作为选择器”，2003-10-14。“IKEv2的ICMP和MH TSs”线程，2005年9月。）
Section 2.9 describes how traffic selectors are negotiated when creating a CHILD_SA. A more concise summary of the narrowing process is presented below.
第2.9节描述了创建子SA时如何协商流量选择器。下文对收窄过程进行了更简明的总结。
o If the responder's policy does not allow any part of the traffic covered by TSi/TSr, it responds with TS_UNACCEPTABLE.
o 如果响应者的策略不允许TSi/TSr覆盖的任何部分流量，则响应者将使用TS_不可接受。
o If the responder's policy allows the entire set of traffic covered by TSi/TSr, no narrowing is necessary, and the responder can return the same TSi/TSr values.
o 如果响应者的策略允许TSi/TSr覆盖的整个流量集，则无需缩小，响应者可以返回相同的TSi/TSr值。
o Otherwise, narrowing is needed. If the responder's policy allows all traffic covered by TSi[1]/TSr[1] (the first traffic selectors in TSi/TSr) but not entire TSi/TSr, the responder narrows to an acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].
o 否则，需要缩小。如果响应者的策略允许TSi[1]/TSr[1]（TSi/TSr中的第一个流量选择器）覆盖的所有流量，但不允许整个TSi/TSr，则响应者会缩小到TSi/TSr的可接受子集，其中包括TSi[1]/TSr[1]。
o If the responder's policy does not allow all traffic covered by TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to an acceptable subset of TSi/TSr.
o 如果响应者的策略不允许TSi[1]/TSr[1]覆盖的所有流量，但允许TSi/TSr的某些部分，则会缩小到TSi/TSr的可接受子集。
In the last two cases, there may be several subsets that are acceptable (but their union is not); in this case, the responder arbitrarily chooses one of them and includes ADDITIONAL_TS_POSSIBLE notification in the response.
在最后两种情况下，可能有几个子集是可接受的（但它们的联合不是）；在这种情况下，响应者任意选择其中一个，并在响应中包括额外的可能通知。
The description of the SINGLE_PAIR_REQUIRED notify payload in Sections 2.9 and 3.10.1 is not fully consistent.
第2.9节和第3.10.1节中对所需通知有效载荷的描述不完全一致。
We do not attempt to describe this payload in this document either, since it is expected that most implementations will not have policies that require separate SAs for each address pair.
我们也不打算在本文档中描述此有效负载，因为预计大多数实现不会有要求每个地址对使用单独SA的策略。
Thus, if only some part (or parts) of the TSi/TSr proposed by the initiator is (are) acceptable to the responder, most responders should simply narrow TSi/TSr to an acceptable subset (as described in the last two paragraphs of Section 2.9), rather than use SINGLE_PAIR_REQUIRED.
因此，如果发起者提出的TSi/TSr只有一部分（或多部分）是响应者可以接受的，大多数响应者应该简单地将TSi/TSr缩小到可接受的子集（如第2.9节最后两段所述），而不是使用所需的单对。
Section 2.9 describes traffic selector negotiation in great detail. One aspect of this negotiation that may need some clarification is that when creating a new SA, the initiator should not propose traffic selectors that violate its own policy. If this rule is not followed, valid traffic may be dropped.
第2.9节详细描述了流量选择器协商。此协商可能需要澄清的一个方面是，在创建新SA时，发起人不应提出违反其自身策略的流量选择器。如果不遵守此规则，则可能会丢弃有效的通信量。
This is best illustrated by an example. Suppose that host A has a policy whose effect is that traffic to 192.0.1.66 is sent via host B encrypted using Advanced Encryption Standard (AES), and traffic to all other hosts in 192.0.1.0/24 is also sent via B, but encrypted using Triple Data Encryption Standard (3DES). Suppose also that host B accepts any combination of AES and 3DES.
一个例子最好地说明了这一点。假设主机A有一个策略，其效果是到192.0.1.66的流量通过主机B发送，该主机B使用高级加密标准（AES）加密，到192.0.1.0/24中所有其他主机的流量也通过B发送，但使用三重数据加密标准（3DES）加密。还假设主机B接受AES和3DE的任意组合。
If host A now proposes an SA that uses 3DES, and includes TSr containing (192.0.1.0-192.0.1.0.255), this will be accepted by host B. Now, host B can also use this SA to send traffic from 192.0.1.66, but those packets will be dropped by A since it requires the use of AES for those traffic. Even if host A creates a new SA only for 192.0.1.66 that uses AES, host B may freely continue to use the first SA for the traffic. In this situation, when proposing the SA, host A should have followed its own policy, and included a TSr containing ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.
如果主机A现在建议使用3DES的SA，并且包含TSr（192.0.1.0-192.0.1.0.255），这将被主机B接受。现在，主机B也可以使用此SA从192.0.1.66发送流量，但这些数据包将被A丢弃，因为它需要对这些流量使用AES。即使主机A仅为使用AES的192.0.1.66创建了一个新SA，主机B也可以自由地继续为流量使用第一个SA。在这种情况下，当提议SA时，主机A应该遵循自己的策略，并包含一个TSr，其中包含（（192.0.1.0-192.0.1.65），（192.0.1.67-192.0.1.255））。
In general, if (1) the initiator makes a proposal "for traffic X (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator does not actually accept traffic X' with SA, and (3) the initiator would be willing to accept traffic X' with some SA' (!=SA), valid traffic can be unnecessarily dropped since the responder can apply either SA or SA' to traffic X'.
通常，如果（1）发起者提出“针对流量X（TSi/TSr），do SA”的建议，（2）对于X的某些子集X'，发起者实际上不接受SA的流量X'，并且（3）发起者愿意接受带有某些SA'（！=SA）的流量X'，则，由于响应者可以将SA或SA‘应用于流量X’，有效流量可能会被不必要地丢弃。
(References: "Question about "narrowing" ..." thread, Feb 2005. "IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2 Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector negotiation examples", 2004-08-08.)
（参考资料：“关于“缩小”线程的问题”，2005年2月。“IKEv2需要一个“策略使用模式”线程，2005年2月。“IKEv2流量选择器？”线程，2005年2月。“IKEv2流量选择器协商示例”，2004-08-08。）
IKEv2 relies on information in the Peer Authorization Database (PAD) when determining what kind of IPsec SAs a peer is allowed to create. This process is described in [RFC4301] Section 4.4.3. When a peer requests the creation of an IPsec SA with some traffic selectors, the PAD must contain "Child SA Authorization Data" linking the identity authenticated by IKEv2 and the addresses permitted for traffic selectors.
IKEv2在确定允许对等方创建何种IPsec SA时，依赖于对等方授权数据库（PAD）中的信息。[RFC4301]第4.4.3节描述了该过程。当对等方请求使用某些流量选择器创建IPsec SA时，PAD必须包含“子SA授权数据”，链接IKEv2验证的身份和流量选择器允许的地址。
For example, the PAD might be configured so that authenticated identity "sgw23.example.com" is allowed to create IPsec SAs for 192.0.2.0/24, meaning this security gateway is a valid "representative" for these addresses. Host-to-host IPsec requires similar entries, linking, for example, "fooserver4.example.com" with 192.0.1.66/32, meaning this identity a valid "owner" or "representative" of the address in question.
例如，PAD可以配置为允许经过身份验证的标识“sgw23.example.com”为192.0.2.0/24创建IPsec SAs，这意味着此安全网关是这些地址的有效“代表”。主机到主机IPsec需要类似的条目，例如，将“fooserver4.example.com”链接到192.0.1.66/32，这意味着此标识是相关地址的有效“所有者”或“代表”。
As noted in [RFC4301], "It is necessary to impose these constraints on creation of child SAs to prevent an authenticated peer from spoofing IDs associated with other, legitimate peers." In the example given above, a correct configuration of the PAD prevents sgw23 from creating IPsec SAs with address 192.0.1.66 and prevents fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24.
如[RFC4301]中所述，“有必要对子SA的创建施加这些约束，以防止经过身份验证的对等方欺骗与其他合法对等方关联的ID。”在上述示例中，PAD的正确配置可防止sgw23创建地址为192.0.1.66的IPsec SAs，并防止fooserver4创建地址为192.0.2.0/24的IPsec SAs。
It is important to note that simply sending IKEv2 packets using some particular address does not imply a permission to create IPsec SAs with that address in the traffic selectors. For example, even if sgw23 would be able to spoof its IP address as 192.0.1.66, it could not create IPsec SAs matching fooserver4's traffic.
需要注意的是，仅使用某个特定地址发送IKEv2数据包并不意味着允许在流量选择器中使用该地址创建IPsec SAs。例如，即使sgw23能够伪造其IP地址为192.0.1.66，它也无法创建与fooserver4通信量匹配的IPsec SAs。
The IKEv2 specification does not specify how exactly IP address assignment using configuration payloads interacts with the PAD. Our interpretation is that when a security gateway assigns an address
IKEv2规范没有指定使用配置有效负载的IP地址分配如何与PAD交互。我们的解释是，当安全网关分配地址时
using configuration payloads, it also creates a temporary PAD entry linking the authenticated peer identity and the newly allocated inner address.
使用配置有效负载，它还创建一个临时PAD条目，链接经过身份验证的对等身份和新分配的内部地址。
It has been recognized that configuring the PAD correctly may be difficult in some environments. For instance, if IPsec is used between a pair of hosts whose addresses are allocated dynamically using Dynamic Host Configuration Protocol (DHCP), it is extremely difficult to ensure that the PAD specifies the correct "owner" for each IP address. This would require a mechanism to securely convey address assignments from the DHCP server and link them to identities authenticated using IKEv2.
人们已经认识到，在某些环境中，正确配置PAD可能很困难。例如，如果在一对使用动态主机配置协议（DHCP）动态分配地址的主机之间使用IPsec，则很难确保PAD为每个IP地址指定正确的“所有者”。这需要一种机制来安全地传递来自DHCP服务器的地址分配，并将它们链接到使用IKEv2进行身份验证的身份。
Due to this limitation, some vendors have been known to configure their PADs to allow an authenticated peer to create IPsec SAs with traffic selectors containing the same address that was used for the IKEv2 packets. In environments where IP spoofing is possible (i.e., almost everywhere) this essentially allows any peer to create IPsec SAs with any traffic selectors. This is not an appropriate or secure configuration in most circumstances. See [Aura05] for an extensive discussion about this issue, and the limitations of host-to-host IPsec in general.
由于这一限制，已知一些供应商将其PAD配置为允许经过身份验证的对等方使用包含IKEv2数据包使用的相同地址的流量选择器创建IPsec SAs。在可能进行IP欺骗的环境中（即，几乎任何地方），这基本上允许任何对等方使用任何流量选择器创建IPsec SA。在大多数情况下，这不是一种适当或安全的配置。请参阅[Aura05]了解有关此问题的详细讨论，以及主机对主机IPsec的一般限制。
Continued from Section 4.1 of this document.
续本文件第4.1节。
NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
新增-1.3.2使用CREATE_CHILD_SA交换重新键入IKE_SA
The CREATE_CHILD_SA request for rekeying an IKE_SA is:
重新设置IKE_SA密钥的CREATE_CHILD_SA请求为：
Initiator Responder
----------- -----------
HDR, SK {SA, Ni, [KEi]} -->
Initiator Responder
----------- -----------
HDR, SK {SA, Ni, [KEi]} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, and optionally a Diffie-Hellman value in the KEi payload.
启动器发送SA有效负载中的SA offer、Ni有效负载中的nonce以及KEi有效负载中的Diffie-Hellman值（可选）。
The CREATE_CHILD_SA response for rekeying an IKE_SA is:
用于重新键入IKE_SA的CREATE_CHILD_SA响应为：
<-- HDR, SK {SA, Nr, [KEr]}
<-- HDR, SK {SA, Nr, [KEr]}
The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, a nonce in the Nr payload, and, optionally, a Diffie-Hellman value in the KEr payload.
响应者使用SA有效负载中的已接受要约、Nr有效负载中的nonce以及KEr有效负载中的Diffie-Hellman值（可选）进行响应（使用相同的消息ID进行响应）。
The new IKE_SA has its message counters set to 0, regardless of what they were in the earlier IKE_SA. The window size starts at 1 for any new IKE_SA. The new initiator and responder SPIs are supplied in the SPI fields of the SA payloads.
新的IKE_SA将其消息计数器设置为0，而不管它们在早期的IKE_SA中是什么。对于任何新IKE_SA，窗口大小从1开始。新的启动器和响应程序SPI在SA有效负载的SPI字段中提供。
NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
新增-1.3.3使用CREATE_CHILD_SA交换重新键入子SA
The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
用于重新键入子项的CREATE_CHILD_SA请求为：
Initiator Responder
----------- -----------
HDR, SK {N(REKEY_SA), [N+], SA,
Ni, [KEi], TSi, TSr} -->
Initiator Responder
----------- -----------
HDR, SK {N(REKEY_SA), [N+], SA,
Ni, [KEi], TSi, TSr} -->
The leading Notify payload of type REKEY_SA identifies the CHILD_SA being rekeyed, and it contains the SPI that the initiator expects in the headers of inbound packets. In addition, the initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, optionally a Diffie-Hellman value in the KEi payload, and the proposed traffic selectors in the TSi and TSr payloads. The request can also contain Notify payloads that specify additional details for the CHILD_SA.
REKEY_SA类型的前导Notify有效负载标识正在被重新KEY的子_SA，并且它包含启动器在入站数据包的报头中期望的SPI。此外，发起方发送SA有效载荷中的SA offer、Ni有效载荷中的nonce、KEi有效载荷中可选的Diffie-Hellman值以及TSi和TSr有效载荷中的建议流量选择器。请求还可以包含Notify有效载荷，这些载荷指定子_SA的其他详细信息。
The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
用于重新键入子项的CREATE_CHILD_SA响应为：
<-- HDR, SK {[N+], SA, Nr,
[KEr], TSi, TSr}
<-- HDR, SK {[N+], SA, Nr,
[KEr], TSi, TSr}
The responder replies with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group.
如果请求中包含KEi且所选加密套件包含该组，则响应者在SA有效负载中回复接受的报价，并在KEr有效负载中回复Diffie Hellman值。
The traffic selectors for traffic to be sent on that SA are specified in the TS payloads in the response, which may be a subset of what the initiator of the CHILD_SA proposed.
要在该SA上发送的流量的流量选择器在响应中的TS有效负载中指定，这可能是子SA的发起方所建议的子集。
Rekeying the IKE_SA and reauthentication are different concepts in IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and resets the Message ID counters, but it does not authenticate the parties again (no AUTH or EAP payloads are involved).
在IKEv2中，重新键入IKE_SA和重新验证是不同的概念。为IKE_SA重新设置密钥为IKE_SA建立新密钥并重置消息ID计数器，但不会再次对各方进行身份验证（不涉及身份验证或EAP有效负载）。
While rekeying the IKE_SA may be important in some environments, reauthentication (the verification that the parties still have access to the long-term credentials) is often more important.
虽然在某些环境中，为IKE_SA重新键入密钥可能很重要，但重新验证（验证各方仍然可以访问长期凭据）通常更为重要。
IKEv2 does not have any special support for reauthentication. Reauthentication is done by creating a new IKE_SA from scratch (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify payloads), creating new CHILD_SAs within the new IKE_SA (without REKEY_SA notify payloads), and finally deleting the old IKE_SA (which deletes the old CHILD_SAs as well).
IKEv2对重新验证没有任何特殊支持。通过从头创建新的IKE_SA（使用IKE_SA_INIT/IKE_AUTH交换，不使用任何REKEY_SA notify有效负载），在新IKE_SA内创建新的子SA（不使用REKEY_SA notify有效负载），最后删除旧IKE_SA（这也会删除旧的子SA），可以完成重新身份验证。
This means that reauthentication also establishes new keys for the IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed more often than reauthentication, the situation where "authentication lifetime" is shorter than "key lifetime" does not make sense.
这意味着重新验证还为IKE_SA和CHILD_SA建立新密钥。因此，虽然可以比重新认证更频繁地执行密钥更新，但是“认证生存期”比“密钥生存期”短的情况没有意义。
While creation of a new IKE_SA can be initiated by either party (initiator or responder in the original IKE_SA), the use of EAP authentication and/or configuration payloads means in practice that reauthentication has to be initiated by the same party as the original IKE_SA. IKEv2 base specification does not allow the responder to request reauthentication in this case; however, this functionality is added in [ReAuth].
虽然新IKE_SA的创建可以由任何一方（原始IKE_SA中的发起方或响应方）发起，但EAP身份验证和/或配置有效载荷的使用实际上意味着重新身份验证必须由与原始IKE_SA相同的一方发起。在这种情况下，IKEv2基本规范不允许响应者请求重新验证；但是，此功能是在[ReAuth]中添加的。
(References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)
（参考文献：“IKEv2中的重新认证”线程，2004年10月/11月。）
Section 2.18 says that "New initiator and responder SPIs are supplied in the SPI fields". This refers to the SPI fields in the Proposal structures inside the Security Association (SA) payloads, not the SPI fields in the IKE header.
第2.18节说“新的启动器和响应程序SPI在SPI字段中提供”。这指的是安全关联（SA）有效负载内提案结构中的SPI字段，而不是IKE头中的SPI字段。
(References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24. Geoffrey Huang's reply, 2005-01-24.)
（参考资料：汤姆·斯蒂默林的邮件“雷凯·艾克·萨”，2005-01-24。杰弗里·黄的回复，2005-01-24。）
Section 3.10.1 says that in REKEY_SA notifications, "The SPI field identifies the SA being rekeyed."
第3.10.1节指出，在更新SA通知中，“SPI字段标识正在更新的SA。”
Since CHILD_SAs always exist in pairs, there are two different SPIs. The SPI placed in the REKEY_SA notification is the SPI the exchange initiator would expect in inbound ESP or AH packets (just as in Delete payloads).
由于CHILD_sa总是成对存在，因此存在两种不同的spi。将AH或RESA数据包删除到ESP中的入站SPI密钥通知中。
When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for the new IKE_SA is computed using SK_d from the existing IKE_SA as follows:
在为IKE_SA重新设置密钥时，第2.18节规定“新IKE_SA的密钥使用现有IKE_SA中的密钥计算，如下所示：
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"
If the old and new IKE_SA selected a different PRF, it is not totally clear which PRF should be used.
如果新旧IKE_SA选择了不同的PRF，则不完全清楚应使用哪个PRF。
Since the rekeying exchange belongs to the old IKE_SA, it is the old IKE_SA's PRF that is used. This also follows the principle that the same key (the old SK_d) should not be used with multiple cryptographic algorithms.
由于密钥交换属于旧IKE_SA，因此使用的是旧IKE_SA的PRF。这也遵循了同一密钥（旧密钥）不应与多个加密算法一起使用的原则。
Note that this may work poorly if the new IKE_SA's PRF has a fixed key size, since the output of the PRF may not be of the correct size. This supports our opinion earlier in the document that the use of PRFs with a fixed key size is a bad idea.
请注意，如果新IKE_SA的PRF具有固定的密钥大小，这可能会很糟糕，因为PRF的输出可能没有正确的大小。这支持了我们在文档前面的观点，即使用具有固定密钥大小的PRF是一个坏主意。
(References: "Changing PRFs when rekeying the IKE_SA" thread, June 2005.)
（参考资料：“在为IKE_SA重新设置密钥时更改PRF”线程，2005年6月。）
The IKEv2 specification talks about "closing" and "deleting" SAs, but it is not always clear what exactly is meant. However, other parts of the specification make it clear that when local state related to a CHILD_SA is removed, the SA must also be actively deleted with a Delete payload.
IKEv2规范讨论了“关闭”和“删除”SA，但并不总是清楚其确切含义。然而，规范的其他部分明确指出，当移除与子_SA相关的本地状态时，还必须使用删除有效负载主动删除SA。
In particular, Section 2.4 says that "If an IKE endpoint chooses to delete CHILD_SAs, it MUST send Delete payloads to the other end notifying it of the deletion". Section 1.4 also explains that "ESP and AH SAs always exist in pairs, with one SA in each direction. When an SA is closed, both members of the pair MUST be closed."
特别是，第2.4节说，“如果IKE端点选择删除子_SA，它必须向另一端发送删除有效负载，通知其删除”。第1.4节还解释了“ESP和AH SA始终成对存在，每个方向都有一个SA。当SA关闭时，成对的两个成员都必须关闭。”
Section 1.4 describes how to delete SA pairs using the Informational exchange: "To delete an SA, an INFORMATIONAL exchange with one or more delete payloads is sent listing the SPIs (as they would be expected in the headers of inbound packets) of the SAs to be deleted. The recipient MUST close the designated SAs."
第1.4节描述了如何使用信息交换删除SA对：“要删除SA，将发送一个具有一个或多个删除有效负载的信息交换，其中列出要删除的SA的SPI（如入站数据包头中所预期的那样）。收件人必须关闭指定的SA。”
The "one or more delete payloads" phrase has caused some confusion. You never send delete payloads for the two sides of an SA in a single message. If you have many SAs to delete at the same time (such as the nested example given in that paragraph), you include delete payloads for the inbound half of each SA in your Informational exchange.
“一个或多个删除有效载荷”短语引起了一些混乱。您永远不会在一条消息中发送SA两侧的删除有效负载。如果同时要删除多个SA（如该段中给出的嵌套示例），则在信息交换中为每个SA的入站部分包含删除有效负载。
Since IKE_SAs do not exist in pairs, it is not totally clear what the response message should contain when the request deleted the IKE_SA.
由于IKE_SA不成对存在，因此当请求删除IKE_SA时，响应消息应该包含什么并不完全清楚。
Since there is no information that needs to be sent to the other side (except that the request was received), an empty Informational response seems like the most logical choice.
由于没有需要发送给另一方的信息（除了收到请求之外），因此空的信息响应似乎是最合乎逻辑的选择。
(References: "Question about delete IKE SA" thread, May 2005.)
（参考资料：“关于删除IKE SA的问题”线程，2005年5月。）
In the IKEv2 document, "initiator" refers to the party who initiated the exchange being described, and "original initiator" refers to the party who initiated the whole IKE_SA. However, there is some potential for confusion because the IKE_SA can be rekeyed by either party.
在IKEv2文件中，“发起人”指发起所述交易的一方，“原始发起人”指发起整个IKE_SA的一方。然而，由于任何一方都可以重新确定IKE_SA，因此可能会出现一些混乱。
To clear up this confusion, we propose that "original initiator" always refers to the party who initiated the exchange that resulted in the current IKE_SA. In other words, if the "original responder" starts rekeying the IKE_SA, that party becomes the "original initiator" of the new IKE_SA.
为了澄清这一混淆，我们建议“原始发起人”总是指发起导致当前IKE_SA的交换的一方。换句话说，如果“原始响应者”开始重新键入IKE_SA，则该方成为新IKE_SA的“原始发起人”。
(References: Paul Hoffman's mail "Original initiator in IKEv2", 2005-04-21.)
（参考资料：保罗·霍夫曼的邮件“IKEv2的原始发起人”，2005-04-21。）
Section 2.8 about rekeying says that "If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it."
关于密钥更新的第2.8节说，“如果通过这种冲突创建了冗余SA，则使用两个交换中使用的四个nonce中最低的nonce创建的SA应由创建它的端点关闭。”
Here "lowest" uses an octet-by-octet (lexicographical) comparison (instead of, for instance, comparing the nonces as large integers). In other words, start by comparing the first octet; if they're equal, move to the next octet, and so on. If you reach the end of one nonce, that nonce is the lower one.
这里“lower”使用一个八位字节一个八位字节（字典）的比较（而不是，例如，将nonce作为大整数进行比较）。换句话说，从比较第一个八位组开始；如果它们相等，则移动到下一个八位组，依此类推。如果到达一个nonce的末尾，则该nonce是较低的一个。
(References: "IKEv2 rekeying question" thread, July 2005.)
（参考文献：“IKEv2更新问题”线程，2005年7月。）
Since IKEv2 exchanges can be initiated by both peers, it is possible that two exchanges affecting the same SA partly overlap. This can lead to a situation where the SA state information is temporarily not synchronized, and a peer can receive a request it cannot process in a normal fashion. Some of these corner cases are discussed in the specification, some are not.
由于IKEv2交换可以由两个对等方发起，因此影响相同SA的两个交换可能部分重叠。这可能会导致SA状态信息暂时不同步的情况，并且对等方可以接收其无法以正常方式处理的请求。规范中讨论了其中一些拐角情况，但有些没有讨论。
Obviously, using a window size greater than one leads to infinitely more complex situations, especially if requests are processed out of order. In this section, we concentrate on problems that can arise even with window size 1.
显然，使用大于1的窗口大小会导致无限复杂的情况，特别是在请求处理无序的情况下。在本节中，我们将重点讨论窗口大小为1时可能出现的问题。
(References: "IKEv2: invalid SPI in DELETE payload" thread, Dec 2005/ Jan 2006. "Problem with exchanges collisions" thread, Dec 2005.)
（参考资料：“IKEv2:删除有效负载中的SPI无效”线程，2005年12月/2006年1月。“交换冲突问题”线程，2005年12月。）
Probably the simplest case happens if both peers decide to close the same CHILD_SA pair at the same time:
可能最简单的情况是，如果两个同龄人决定同时关闭同一个子对象对：
Host A Host B
-------- --------
send req1: D(SPIa) -->
<-- send req2: D(SPIb)
--> recv req1
<-- send resp1: ()
recv resp1
recv req2
send resp2: () -->
--> recv resp2
Host A Host B
-------- --------
send req1: D(SPIa) -->
<-- send req2: D(SPIb)
--> recv req1
<-- send resp1: ()
recv resp1
recv req2
send resp2: () -->
--> recv resp2
This case is described in Section 1.4 and is handled by omitting the Delete payloads from the response messages.
第1.4节描述了这种情况，通过从响应消息中省略删除有效载荷来处理。
Both peers can also decide to close the IKE_SA at the same time. The desired end result is obvious; however, in certain cases the final exchanges may not be fully completed.
两个对等方也可以同时决定关闭IKE_SA。预期的最终结果是明显的；但是，在某些情况下，最终交换可能无法完全完成。
Host A Host B
-------- --------
send req1: D() -->
<-- send req2: D()
--> recv req1
Host A Host B
-------- --------
send req1: D() -->
<-- send req2: D()
--> recv req1
At this point, host B should reply as usual (with empty Informational response), close the IKE_SA, and stop retransmitting req2. This is because once host A receives resp1, it may not be able to reply any longer. The situation is symmetric, so host A should behave the same way.
此时，主机B应该像往常一样回复（信息响应为空），关闭IKE_SA，并停止重新传输req2。这是因为一旦主机A接收到resp1，它可能无法再回复。这种情况是对称的，因此主机A的行为应该是相同的。
Host A Host B
-------- --------
<-- send resp1: ()
send resp2: ()
Host A Host B
-------- --------
<-- send resp1: ()
send resp2: ()
Even if neither resp1 nor resp2 ever arrives, the end result is still correct: the IKE_SA is gone. The same happens if host A never receives req2.
即使resp1和resp2都没有出现，最终的结果仍然是正确的：艾克萨已经消失了。如果主机A从未收到req2，也会发生同样的情况。
Another case that is described in the specification is simultaneous rekeying. Section 2.8 says
规范中描述的另一种情况是同时密钥更新。第2.8节说
"If the two ends have the same lifetime policies, it is possible that both will initiate a rekeying at the same time (which will result in redundant SAs). To reduce the probability of this happening, the timing of rekeying requests SHOULD be jittered (delayed by a random amount of time after the need for rekeying is noticed).
“如果两端具有相同的生存期策略，则两者可能同时启动密钥更新（这将导致冗余SA）。为降低发生这种情况的可能性，应抖动密钥更新请求的时间（在注意到需要密钥更新后延迟随机时间）。
This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it."
这种形式的密钥更新可能会暂时导致同一对节点之间出现多个类似的SA。当有两个SA有资格接收数据包时，节点必须通过任一SA接收传入数据包。如果通过这种冲突创建了冗余SA，则创建该SA的端点应关闭使用两个交换中使用的四个nonce中最低的nonce创建的SA。”
However, a better explanation on what impact this has on implementations is needed. Assume that hosts A and B have an existing IPsec SA pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same time:
然而，需要更好地解释这对实现的影响。假设主机A和主机B有一个现有的IPsec SA对和SPI（SPIa1、SPIb1），并同时开始对其重新设置密钥：
Host A Host B
-------- --------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. -->
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2,..
recv req2 <--
Host A Host B
-------- --------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. -->
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2,..
recv req2 <--
At this point, A knows there is a simultaneous rekeying going on. However, it cannot yet know which of the exchanges will have the lowest nonce, so it will just note the situation and respond as usual.
在这一点上，A知道有一个同步的密钥更新正在进行。然而，它还不知道哪一家交易所的市盈率最低，因此它只会注意到情况并像往常一样做出反应。
send resp2: SA(..,SPIa3,..),Nr1,.. -->
--> recv req1
send resp2: SA(..,SPIa3,..),Nr1,.. -->
--> recv req1
Now B also knows that simultaneous rekeying is going on. Similarly as host A, it has to respond as usual.
现在B也知道同步重新键入正在进行。与主机A类似，它必须像往常一样响应。
<-- send resp1: SA(..,SPIb3,..),Nr2,..
recv resp1 <--
--> recv resp2
<-- send resp1: SA(..,SPIb3,..),Nr2,..
recv resp1 <--
--> recv resp2
At this point, there are three CHILD_SA pairs between A and B (the old one and two new ones). A and B can now compare the nonces. Suppose that the lowest nonce was Nr1 in message resp2; in this case, B (the sender of req2) deletes the redundant new SA, and A (the node that initiated the surviving rekeyed SA) deletes the old one.
此时，A和B之间有三对子_SA（旧的和两个新的）。A和B现在可以比较nonce。假设消息resp2中的最低nonce为Nr1；在这种情况下，B（req2的发送方）删除冗余的新SA，A（启动幸存的密钥更新SA的节点）删除旧SA。
send req3: D(SPIa1) -->
<-- send req4: D(SPIb2)
--> recv req3
<-- send resp4: D(SPIb1)
recv req4 <--
send resp4: D(SPIa3) -->
send req3: D(SPIa1) -->
<-- send req4: D(SPIb2)
--> recv req3
<-- send resp4: D(SPIb1)
recv req4 <--
send resp4: D(SPIa3) -->
The rekeying is now finished.
重新键入现在已完成。
However, there is a second possible sequence of events that can happen if some packets are lost in the network, resulting in retransmissions. The rekeying begins as usual, but A's first packet (req1) is lost.
但是，如果某些数据包在网络中丢失，导致重新传输，则可能会发生第二个可能的事件序列。密钥更新照常开始，但A的第一个数据包（req1）丢失。
Host A Host B
-------- --------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. --> (lost)
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2,..
recv req2 <--
send resp2: SA(..,SPIa3,..),Nr1,.. -->
--> recv resp2
<-- send req3: D(SPIb1)
recv req3 <--
send resp3: D(SPIa1) -->
--> recv resp3
Host A Host B
-------- --------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. --> (lost)
<-- send req2: N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2,..
recv req2 <--
send resp2: SA(..,SPIa3,..),Nr1,.. -->
--> recv resp2
<-- send req3: D(SPIb1)
recv req3 <--
send resp3: D(SPIa1) -->
--> recv resp3
From B's point of view, the rekeying is now completed, and since it has not yet received A's req1, it does not even know that these was simultaneous rekeying. However, A will continue retransmitting the message, and eventually it will reach B.
从B的角度来看，重新键入现在已经完成，而且由于它还没有收到A的req1，它甚至不知道这些是同时重新键入的。但是，A将继续重新传输消息，最终它将到达B。
resend req1 -->
--> recv req1
resend req1 -->
--> recv req1
What should B do in this point? To B, it looks like A is trying to rekey an SA that no longer exists; thus failing the request with something non-fatal such as NO_PROPOSAL_CHOSEN seems like a reasonable approach.
在这一点上B应该做什么？对B来说，看起来A试图重新输入一个不再存在的SA；因此，用一些非致命的东西（如未选择提案）来拒绝请求似乎是一种合理的方法。
<-- send resp1: N(NO_PROPOSAL_CHOSEN)
recv resp1 <--
<-- send resp1: N(NO_PROPOSAL_CHOSEN)
recv resp1 <--
When A receives this error, it already knows there was simultaneous rekeying, so it can ignore the error message.
当A收到此错误时，它已经知道同时进行了密钥更新，因此可以忽略错误消息。
Probably the most complex case occurs when both peers try to rekey the IKE_SA at the same time. Basically, the text in Section 2.8 applies to this case as well; however, it is important to ensure that the CHILD_SAs are inherited by the right IKE_SA.
最复杂的情况可能发生在两个对等方同时尝试为IKE_SA重新设置密钥时。基本上，第2.8节中的文本也适用于本案例；但是，确保子女由正确的IKE_SA继承很重要。
The case where both endpoints notice the simultaneous rekeying works the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges, three IKE_SAs exist between A and B; the one containing the lowest nonce inherits the CHILD_SAs.
两个端点同时注意到密钥更新的情况与使用CHILD_sa的情况相同。在CREATE_CHILD_SA交换之后，A和B之间存在三个IKE_SA；包含最低nonce的将继承子变量。
However, there is a twist to the other case where one rekeying finishes first:
但是，在另一种情况下，一个重设关键帧会首先完成：
Host A Host B
-------- --------
send req1:
SA(..,SPIa1,..),Ni1,.. -->
<-- send req2: SA(..,SPIb1,..),Ni2,..
--> recv req1
<-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <--
send req3: D() -->
--> recv req3
Host A Host B
-------- --------
send req1:
SA(..,SPIa1,..),Ni1,.. -->
<-- send req2: SA(..,SPIb1,..),Ni2,..
--> recv req1
<-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <--
send req3: D() -->
--> recv req3
At this point, host B sees a request to close the IKE_SA. There's not much more to do than to reply as usual. However, at this point host B should stop retransmitting req2, since once host A receives resp3, it will delete all the state associated with the old IKE_SA and will not be able to reply to it.
此时，主机B看到关闭IKE_SA的请求。没有什么比照常回答更多的了。但是，此时主机B应停止重新传输req2，因为一旦主机A接收到resp3，它将删除与旧IKE_SA关联的所有状态，并且将无法回复该状态。
<-- send resp3: ()
<--发送响应3:（）
A case similar to simultaneous rekeying can occur if one peer decides to close an SA and the other peer tries to rekey it:
如果一个对等方决定关闭SA，而另一个对等方尝试对其重新设置密钥，则可能发生类似于同时重新设置密钥的情况：
Host A Host B
-------- --------
send req1: D(SPIa) -->
<-- send req2: N(REKEY_SA,SPIb),SA,..
--> recv req1
Host A Host B
-------- --------
send req1: D(SPIa) -->
<-- send req2: N(REKEY_SA,SPIb),SA,..
--> recv req1
At this point, host B notices that host A is trying to close an SA that host B is currently rekeying. Replying as usual is probably the best choice:
此时，主机B注意到主机A正在尝试关闭主机B当前正在重新设置密钥的SA。照常回答可能是最好的选择：
<-- send resp1: D(SPIb)
<-- send resp1: D(SPIb)
Depending on in which order req2 and resp1 arrive, host A sees either a request to rekey an SA that it is currently closing, or a request to rekey an SA that does not exist. In both cases, NO_PROPOSAL_CHOSEN is probably fine.
根据req2和resp1订单的到达顺序，主机A会看到一个请求，请求重新输入当前正在关闭的SA，或者请求重新输入不存在的SA。在这两种情况下，没有选择的方案可能是好的。
recv req2
recv resp1
send resp2: N(NO_PROPOSAL_CHOSEN) -->
--> recv resp2
recv req2
recv resp1
send resp2: N(NO_PROPOSAL_CHOSEN) -->
--> recv resp2
Yet another case occurs when host A creates a CHILD_SA pair, but soon thereafter host B decides to delete it (possible because its policy changed):
还有一种情况发生在主机A创建子_SA对时，但不久之后主机B决定删除该子_SA对（可能是因为其策略已更改）：
Host A Host B
-------- --------
send req1: [N(REKEY_SA,SPIa1)],
SA(..,SPIa2,..),.. -->
--> recv req1
(lost) <-- send resp1: SA(..,SPIb2,..),..
Host A Host B
-------- --------
send req1: [N(REKEY_SA,SPIa1)],
SA(..,SPIa2,..),.. -->
--> recv req1
(lost) <-- send resp1: SA(..,SPIb2,..),..
<-- send req2: D(SPIb2) recv req2
<--发送请求2:D（SPIb2）接收请求2
At this point, host A has not yet received message resp1 (and is retransmitting message req1), so it does not recognize SPIb in message req2. What should host A do?
此时，主机A尚未收到消息resp1（并且正在重新传输消息req1），因此它无法识别消息req2中的SPIb。主持人应该做什么？
One option would be to reply with an empty Informational response. However, this same reply would also be sent if host A has received resp1, but has already sent a new request to delete the SA that was just created. This would lead to a situation where the peers are no longer in sync about which SAs exist between them. However, host B would eventually notice that the other half of the CHILD_SA pair has not been deleted. Section 1.4 describes this case and notes that "a node SHOULD regard half-closed connections as anomalous and audit their existence should they persist", and continues that "if connection state becomes sufficiently messed up, a node MAY close the IKE_SA".
一种选择是使用空的信息性响应进行回复。但是，如果主机A已收到resp1，但已发送新请求以删除刚刚创建的SA，则也会发送相同的答复。这将导致对等方不再同步它们之间存在哪些SA的情况。但是，主机B最终会注意到子_SA对的另一半没有被删除。第1.4节描述了这种情况，并指出“节点应将半关闭的连接视为异常，并在其持续存在的情况下审核其存在”，并继续指出“如果连接状态变得足够混乱，节点可能会关闭IKE_SA”。
Another solution that has been proposed is to reply with an INVALID_SPI notification that contains SPIb. This would explicitly tell host B that the SA was not deleted, so host B could try deleting it again later. However, this usage is not part of the IKEv2 specification and would not be in line with normal use of the INVALID_SPI notification where the data field contains the SPI the recipient of the notification would put in outbound packets.
提出的另一个解决方案是使用包含SPIb的无效_SPI通知进行回复。这将明确告诉主机B SA未被删除，因此主机B可以稍后再次尝试删除它。但是，此用法不属于IKEv2规范的一部分，也不符合无效_SPI通知的正常使用，其中数据字段包含通知接收者将放入出站数据包中的SPI。
Yet another solution would be to ignore req2 at this time and wait until we have received resp1. However, this alternative has not been fully analyzed at this time; in general, ignoring valid requests is always a bit dangerous, because both endpoints could do it, leading to a deadlock.
另一个解决方案是此时忽略req2，并等待我们收到resp1。然而，目前尚未对该备选方案进行充分分析；一般来说，忽略有效请求总是有点危险，因为两个端点都可以这样做，从而导致死锁。
This document recommends the first alternative.
本文件建议采用第一种备选方案。
Yet another case occurs when a CHILD_SA is rekeyed soon after it has been created:
另一种情况是，子_SA在创建后不久被重新键入：
Host A Host B
-------- --------
send req1: [N(REKEY_SA,SPIa1)],
SA(..,SPIa2,..),.. -->
(lost) <-- send resp1: SA(..,SPIb2,..),..
Host A Host B
-------- --------
send req1: [N(REKEY_SA,SPIa1)],
SA(..,SPIa2,..),.. -->
(lost) <-- send resp1: SA(..,SPIb2,..),..
<-- send req2: N(REKEY_SA,SPIb2),
SA(..,SPIb3,..),..
recv req2 <--
<-- send req2: N(REKEY_SA,SPIb2),
SA(..,SPIb3,..),..
recv req2 <--
To host A, this looks like a request to rekey an SA that does not exist. Like in the simultaneous rekeying case, replying with NO_PROPOSAL_CHOSEN is probably reasonable:
对于主机A，这看起来像是对不存在的SA重新设置密钥的请求。与同时更新密钥的情况一样，在没有选择建议的情况下进行回复可能是合理的：
send resp2: N(NO_PROPOSAL_CHOSEN) -->
recv resp1
send resp2: N(NO_PROPOSAL_CHOSEN) -->
recv resp1
Another set of cases occurs when one peer starts rekeying the IKE_SA at the same time the other peer starts creating, rekeying, or closing a CHILD_SA. Suppose that host B starts creating a CHILD_SA, and soon after, host A starts rekeying the IKE_SA:
另一组情况发生在一个对等方开始为IKE_SA重新键入密钥的同时，另一个对等方开始创建、重新键入或关闭子_SA。假设主机B开始创建子_SA，不久之后，主机a开始为IKE_SA重新设置密钥：
Host A Host B
-------- --------
<-- send req1: SA,Ni1,TSi,TSr
send req2: SA,Ni2,.. -->
--> recv req2
Host A Host B
-------- --------
<-- send req1: SA,Ni1,TSi,TSr
send req2: SA,Ni2,.. -->
--> recv req2
What should host B do at this point? Replying as usual would seem like a reasonable choice:
此时主机B应该做什么？像往常一样回复似乎是一个合理的选择：
<-- send resp2: SA,Ni2,..
recv resp2 <--
send req3: D() -->
--> recv req3
<-- send resp2: SA,Ni2,..
recv resp2 <--
send req3: D() -->
--> recv req3
Now, a problem arises: If host B now replies normally with an empty Informational response, this will cause host A to delete state associated with the IKE_SA. This means host B should stop retransmitting req1. However, host B cannot know whether or not host A has received req1. If host A did receive it, it will move the
现在，出现了一个问题：如果主机B现在以空信息响应正常响应，这将导致主机a删除与IKE_SA关联的状态。这意味着主机B应停止重新传输req1。但是，主机B无法知道主机A是否收到req1。如果主机A确实收到它，它将移动
CHILD_SA to the new IKE_SA as usual, and the state information will then be out of sync.
与往常一样，CHILD_SA与新IKE_SA连接，然后状态信息将不同步。
It seems this situation is tricky to handle correctly. Our proposal is as follows: if a host receives a request to rekey the IKE_SA when it has CHILD_SAs in "half-open" state (currently being created or rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host receives a request to create or rekey a CHILD_SA after it has started rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.
这种情况似乎很难正确处理。我们的建议如下：如果主机在其子SA处于“半开放”状态（当前正在创建或重新设置密钥）时收到重新设置IKE_SA密钥的请求，则主机应在未选择任何建议的情况下进行回复。如果主机在开始为IKE_SA重新设置密钥后收到创建或重新设置子SA密钥的请求，则应不使用其他_SA进行回复。
The case where CHILD_SAs are being closed is even worse. Our recommendation is that if a host receives a request to rekey the IKE_SA when it has CHILD_SAs in "half-closed" state (currently being closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host receives a request to close a CHILD_SA after it has started rekeying the IKE_SA, it should reply with an empty Informational response. This ensures that at least the other peer will eventually notice that the CHILD_SA is still in "half-closed" state and will start a new IKE_SA from scratch.
关闭儿童公寓的情况更糟。我们的建议是，如果主机在其子SA处于“半关闭”状态（当前处于关闭状态）时收到重新设置IKE SA密钥的请求，则应在未选择任何建议的情况下进行回复。如果主机在开始为IKE_SA重新设置密钥后收到关闭子SA的请求，则应以空信息响应进行回复。这确保了至少另一个对等方最终会注意到孩子仍然处于“半封闭”状态，并从头开始新的IKE SA。
The final case considered in this section occurs if one peer decides to close the IKE_SA while the other peer tries to rekey it.
如果一个对等方决定关闭IKE_SA，而另一个对等方尝试重新设置密钥，则会发生本节中考虑的最后一种情况。
Host A Host B
-------- --------
send req1: SA(..,SPIa1,..),Ni1 -->
<-- send req2: D()
--> recv req1
recv req2 <--
Host A Host B
-------- --------
send req1: SA(..,SPIa1,..),Ni1 -->
<-- send req2: D()
--> recv req1
recv req2 <--
At this point, host B should probably reply with NO_PROPOSAL_CHOSEN, and host A should reply as usual, close the IKE_SA, and stop retransmitting req1.
此时，主机B可能应该在未选择任何建议的情况下进行回复，主机A应该像往常一样进行回复，关闭IKE SA，并停止重新传输req1。
<-- send resp1: N(NO_PROPOSAL_CHOSEN)
send resp2: ()
<-- send resp1: N(NO_PROPOSAL_CHOSEN)
send resp2: ()
If host A wants to continue communication with B, it can now start a new IKE_SA.
如果主机A想继续与B通信，它现在可以启动一个新的IKE_SA。
If a host receives a request to rekey:
如果主机收到重新设置密钥的请求：
o a CHILD_SA pair that the host is currently trying to close: reply with NO_PROPOSAL_CHOSEN.
o 主机当前试图关闭的子项对：答复时未选择任何建议。
o a CHILD_SA pair that the host is currently rekeying: reply as usual, but prepare to close redundant SAs later based on the nonces.
o 主机当前正在重新设置密钥的子SA对：照常回复，但准备稍后根据nonce关闭冗余SA。
o a CHILD_SA pair that does not exist: reply with NO_PROPOSAL_CHOSEN.
o 不存在的子项对：答复时不选择任何建议。
o the IKE_SA, and the host is currently rekeying the IKE_SA: reply as usual, but prepare to close redundant SAs and move inherited CHILD_SAs later based on the nonces.
o IKE_SA，主机当前正在为IKE_SA重新设置密钥：按常规回复，但准备关闭冗余SA，并在稍后基于nonce移动继承的子SA。
o the IKE_SA, and the host is currently creating, rekeying, or closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.
o IKE_SA和主机当前正在创建、重新设置密钥或关闭子_SA:reply，但未选择任何建议。
o the IKE_SA, and the host is currently trying to close the IKE_SA: reply with NO_PROPOSAL_CHOSEN.
o IKE_SA，主机当前正在尝试关闭IKE_SA：在未选择任何建议的情况下回复。
If a host receives a request to close:
如果主机收到关闭请求：
o a CHILD_SA pair that the host is currently trying to close: reply without Delete payloads.
o 主机当前试图关闭的子对象对：不删除有效负载回复。
o a CHILD_SA pair that the host is currently rekeying: reply as usual, with Delete payload.
o 主机当前正在重新键入的子_SA对：按常规回复，并删除有效负载。
o a CHILD_SA pair that does not exist: reply without Delete payloads.
o 不存在的子对象对：答复而不删除有效负载。
o the IKE_SA, and the host is currently rekeying the IKE_SA: reply as usual, and forget about our own rekeying request.
o IKE_SA，主机当前正在重新键入IKE_SA：像往常一样回复，忘记我们自己的重新键入请求。
o the IKE_SA, and the host is currently trying to close the IKE_SA: reply as usual, and forget about our own close request.
o IKE_SA，主机当前正试图关闭IKE_SA：像往常一样回复，忘记我们自己的关闭请求。
If a host receives a request to create or rekey a CHILD_SA when it is currently rekeying the IKE_SA: reply with NO_ADDITIONAL_SAS.
如果主机在当前为IKE_SA重新设置密钥时收到创建或重新设置子SA密钥的请求：无其他_SA回复。
If a host receives a request to delete a CHILD_SA when it is currently rekeying the IKE_SA: reply without Delete payloads.
如果主机在当前为IKE_SA重新设置密钥时收到删除子_SA的请求：回复而不删除有效负载。
There has been some confusion whether doing a new Diffie-Hellman exchange is mandatory when the IKE_SA is rekeyed.
当IKE_SA重新加密时，是否必须进行一次新的Diffie-Hellman交换一直存在一些困惑。
It seems that this case is allowed by the IKEv2 specification. Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets. Section 3.3.3 does not contradict this when it says that including
似乎IKEv2规范允许这种情况。第2.18节显示了括号中的Diffie-Hellman术语（g^ir）。当第3.3.3节说包括
the D-H transform is mandatory: although including the transform is mandatory, it can contain the value "NONE".
D-H转换是必需的：尽管包含转换是必需的，但它可以包含值“NONE”。
However, having the option to skip the Diffie-Hellman exchange when rekeying the IKE_SA does not add useful functionality to the protocol. The main purpose of rekeying the IKE_SA is to ensure that the compromise of old keying material does not provide information about the current keys, or vice versa. This requires performing the Diffie-Hellman exchange when rekeying. Furthermore, it is likely that this option would have been removed from the protocol as unnecessary complexity had it been discussed earlier.
但是，在为IKE_SA重新设置密钥时，可以选择跳过Diffie-Hellman交换，这不会为协议添加有用的功能。对IKE_SA重新设置密钥的主要目的是确保旧密钥材料的泄露不会提供有关当前密钥的信息，反之亦然。这需要在重新键入时执行Diffie-Hellman交换。此外，如果早些时候讨论过，这一选项可能会从协议中删除，因为它不必要的复杂性。
Given this, we recommend that implementations should have a hard-coded policy that requires performing a new Diffie-Hellman exchange when rekeying the IKE_SA. In other words, the initiator should not propose the value "NONE" for the D-H transform, and the responder should not accept such a proposal. This policy also implies that a successful exchange rekeying the IKE_SA always includes the KEi/KEr payloads.
有鉴于此，我们建议实现应具有硬编码策略，该策略要求在为IKE_SA重新设置密钥时执行新的Diffie-Hellman交换。换句话说，发起者不应该为D-H转换提出值“NONE”，响应者也不应该接受这样的建议。该策略还意味着成功的IKE_SA密钥交换始终包括KEi/KEr有效载荷。
(References: "Rekeying IKE_SAs with the CREATE_CHILD_SA exhange" thread, Oct 2005. "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt" thread, Apr 2005.)
（参考资料：“用创建子项重新设置IKE SAs”线程，2005年10月。“draft-eronen-ipsec-ikev2-Diclarations-02.txt注释”线程，2005年4月。）
Section 2.9 talks about traffic selector negotiation and mentions that "In support of the scenario described in section 1.1.3, an initiator may request that the responder assign an IP address and tell the initiator what it is."
第2.9节讨论了流量选择器协商，并提到“为了支持第1.1.3节中描述的场景，发起者可以请求响应者分配IP地址，并告诉发起者它是什么。”
This sentence is correct, but its placement is slightly confusing. IKEv2 does allow the initiator to request assignment of an IP address from the responder, but this is done using configuration payloads, not traffic selector payloads. An address in a TSi payload in a response does not mean that the responder has assigned that address to the initiator; it only means that if packets matching these traffic selectors are sent by the initiator, IPsec processing can be performed as agreed for this SA. The TSi payload itself does not give the initiator permission to configure the initiator's TCP/IP stack with the address and use it as its source address.
这个句子是正确的，但它的位置有点混乱。IKEv2允许发起者请求从响应者分配IP地址，但这是使用配置有效载荷而不是流量选择器有效载荷完成的。响应中TSi有效负载中的地址并不意味着响应者已将该地址分配给发起方；这仅意味着，如果启动器发送与这些流量选择器匹配的数据包，则可以按照此SA的约定执行IPsec处理。TSi有效负载本身不允许启动器使用地址配置启动器的TCP/IP堆栈并将其用作源地址。
In other words, IKEv2 does not have two different mechanisms for assigning addresses, but only one: configuration payloads. In the scenario described in Section 1.1.3, both configuration and traffic selector payloads are usually included in the same message, and they
换句话说，IKEv2没有两种不同的地址分配机制，只有一种：配置有效负载。在第1.1.3节中描述的场景中，配置和流量选择器有效载荷通常包含在同一消息中，并且
often contain the same information in the response message (see Section 6.3 of this document for some examples). However, their semantics are still different.
通常在响应消息中包含相同的信息（有关一些示例，请参阅本文件第6.3节）。然而，它们的语义仍然不同。
When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section 3.15.1 says that "In a request message, the address specified is a requested address (or zero if no specific address is requested)". The question here is whether "zero" means an address "0.0.0.0" or a zero-length string.
在描述内部_IP4/IP6_地址属性时，第3.15.1节指出“在请求消息中，指定的地址是请求的地址（如果没有请求特定地址，则为零）”。这里的问题是“零”是指地址“0.0.0.0”还是长度为零的字符串。
Earlier, the same section also says that "If an attribute in the CFG_REQUEST Configuration Payload is not zero-length, it is taken as a suggestion for that attribute". Also, the table of configuration attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0 or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17 octets".
早些时候，同一节还说“如果CFG_请求配置负载中的属性不是零长度，则将其作为该属性的建议”。此外，配置属性表显示内部_IP4_地址的长度为“0或4个八位字节”，同样，内部_IP6_地址的长度为“0或17个八位字节”。
Thus, if the client does not request a specific address, it includes a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute containing an all-zeroes address. The example in 2.19 is thus incorrect, since it shows the attribute as "INTERNAL_ADDRESS(0.0.0.0)".
因此，如果客户机不请求特定地址，它将包括一个零长度的内部_IP4/IP6_地址属性，而不是一个包含全零地址的属性。因此，2.19中的示例是不正确的，因为它将属性显示为“内部_地址（0.0.0.0）”。
However, since the value is only a suggestion, implementations are recommended to ignore suggestions they do not accept; or in other words, to treat the same way a zero-length INTERNAL_IP4_ADDRESS, "0.0.0.0", and any other addresses the implementation does not recognize as a reasonable suggestion.
但是，由于该值只是一个建议，建议实现忽略它们不接受的建议；或者换句话说，以同样的方式对待零长度内部_IP4_地址，“0.0.0.0”，以及实施不认为是合理建议的任何其他地址。
Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected sub-networks that this edge-device protects. This attribute is made up of two fields: the first is an IP address and the second is a netmask. Multiple sub-networks MAY be requested. The responder MAY respond with zero or more sub-network attributes." INTERNAL_IP6_SUBNET is defined in a similar manner.
第3.15.1节将内部_IP4_子网描述为“此边缘设备保护的受保护子网。此属性由两个字段组成：第一个是IP地址，第二个是网络掩码。可以请求多个子网。响应者可以使用零或多个子网属性进行响应。”内部_IP6_子网以类似方式定义。
This raises two questions: first, since this information is usually included in the TSr payload, what functionality does this attribute add? And second, what does this attribute mean in CFG_REQUESTs?
这引发了两个问题：首先，由于此信息通常包含在TSr有效负载中，因此此属性添加了什么功能？第二个属性u是什么意思？
For the first question, there seem to be two sensible interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA response) indicates which subnets are accessible through the SA that was just created.
对于第一个问题，似乎有两种合理的解释。显然，TSr（在IKE_AUTH或CREATE_CHILD_SA响应中）指示哪些子网可以通过刚刚创建的SA访问。
The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is that they indicate additional subnets that can be reached through this gateway, but need a separate SA. According to this interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful mainly when they contain addresses not included in TSr.
内部_IP4/6_子网属性的第一种解释是，它们表示可以通过此网关访问的其他子网，但需要单独的SA。根据这种解释，内部IP 4/6子网属性主要在包含TSr中未包含的地址时有用。
The second interpretation is that the INTERNAL_IP4/6_SUBNET attributes express the gateway's policy about what traffic should be sent through the gateway. The client can choose whether other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent through the gateway or directly to the destination. According to this interpretation, the attributes are useful mainly when TSr contains addresses not included in the INTERNAL_IP4/6_SUBNET attributes.
第二种解释是，内部_IP4/6_子网属性表示网关关于应通过网关发送哪些流量的策略。客户端可以选择是否通过网关或直接向目的地发送其他流量（TSr覆盖，但不在内部_IP4/6_子网中）。根据这种解释，这些属性主要在TSr包含内部_IP4/6_子网属性中未包含的地址时有用。
It turns out that these two interpretations are not incompatible, but rather two sides of the same principle: traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via this gateway. If there are no existing IPsec SAs whose traffic selectors cover the address in question, new SAs have to be created.
事实证明，这两种解释并非不兼容，而是同一原则的两个方面：到内部_IP4/6_子网属性中列出的地址的通信量应通过此网关发送。如果没有现有的IPsec SA，其流量选择器覆盖所述地址，则必须创建新的SA。
A couple of examples are given below. For instance, if there are two subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request contains the following:
下面给出了几个例子。例如，如果有两个子网，192.0.1.0/26和192.0.2.0/24，并且客户端的请求包含以下内容：
CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
Then a valid response could be the following (in which TSr and INTERNAL_IP4_SUBNET contain the same information):
然后，有效响应可以是以下内容（其中TSr和内部_IP4_子网包含相同的信息）：
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63),
(0, 0-65535, 192.0.2.0-192.0.2.255))
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63),
(0, 0-65535, 192.0.2.0-192.0.2.255))
In these cases, the INTERNAL_IP4_SUBNET does not really carry any useful information. Another possible reply would have been this:
在这些情况下，内部IP4子网实际上并不携带任何有用的信息。另一个可能的答复是：
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
This would mean that the client can send all its traffic through the gateway, but the gateway does not mind if the client sends traffic not included by INTERNAL_IP4_SUBNET directly to the destination (without going through the gateway).
这意味着客户端可以通过网关发送其所有通信量，但网关并不介意客户端是否将内部_IP4_子网未包含的通信量直接发送到目标（而不通过网关）。
A different situation arises if the gateway has a policy that requires the traffic for the two subnets to be carried in separate SAs. Then a response like this would indicate to the client that if it wants access to the second subnet, it needs to create a separate SA:
如果网关的策略要求在单独的SAs中承载两个子网的流量，则会出现不同的情况。然后，类似这样的响应将向客户端指示，如果它想要访问第二个子网，则需要创建一个单独的SA：
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)
INTERNAL_IP4_SUBNET can also be useful if the client's TSr included only part of the address space. For instance, if the client requests the following:
如果客户端的TSr仅包含部分地址空间，则内部IP 4子网也会很有用。例如，如果客户端请求以下内容：
CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
Then the gateway's reply could be this:
那么网关的回答可能是：
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
It is less clear what the attributes mean in CFG_REQUESTs, and whether other lengths than zero make sense in this situation (but for INTERNAL_IP6_SUBNET, zero length is not allowed at all!). This document recommends that implementations should not include INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in CFG_REQUESTs.
不太清楚属性在CFG_请求中的含义，以及在这种情况下除零以外的其他长度是否有意义（但对于内部_IP6_子网，根本不允许零长度！）。本文档建议实施不应在CFG_请求中包含内部_IP4_子网或内部_IP6_子网属性。
For the IPv4 case, this document recommends using only netmasks consisting of some amount of "1" bits followed by "0" bits; for
对于IPv4情况，本文档建议仅使用由一定数量的“1”位后跟“0”位组成的网络掩码；对于
instance, "255.0.255.0" would not be a valid netmask for INTERNAL_IP4_SUBNET.
实例“255.0.255.0”将不是内部_IP4_子网的有效网络掩码。
It is also worthwhile to note that the contents of the INTERNAL_IP4/ 6_SUBNET attributes do not imply link boundaries. For instance, a gateway providing access to a large company intranet using addresses from the 10.0.0.0/8 block can send a single INTERNAL_IP4_SUBNET attribute (10.0.0.0/255.0.0.0) even if the intranet has hundreds of routers and separate links.
还值得注意的是，内部IP4/6子网属性的内容并不意味着链路边界。例如，使用10.0.0.0/8块中的地址访问大型公司内部网的网关可以发送单个内部_IP4_子网属性（10.0.0.0/255.0.0.0），即使内部网有数百个路由器和单独的链接。
(References: Tero Kivinen's mail "Intent of couple of attributes in Configuration Payload in IKEv2?", 2004-11-19. Srinivasa Rao Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in IKEv2", 2004-09-10. Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and Implementation Guidelines", 2005-02-07. "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
（参考文献：Tero Kivinen的邮件“IKEv2中配置有效负载中的两个属性的意图？”，2004-11-19。Srinivasa Rao Addepalli的邮件“IKEv2中的内部IP4子网和内部IP6子网”，2004-09-10。Yoav Nir的邮件“Re:新的I-D:IKEv2澄清和实施指南”，2005-02-07）。“澄清公开问题：内部_IP4_子网/网络掩码”线程，2005年4月）
Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute and says that "The internal network's netmask. Only one netmask is allowed in the request and reply messages (e.g., 255.255.255.0) and it MUST be used only with an INTERNAL_IP4_ADDRESS attribute".
第3.15.1节定义了内部_IP4_网络掩码属性，并说明“内部网络的网络掩码。请求和回复消息（例如255.255.255.0）中只允许一个网络掩码，并且只能与内部_IP4_地址属性一起使用”。
However, it is not clear what exactly this attribute means, as the concept of "netmask" is not very well defined for point-to-point links (unlike multi-access links, where it means "you can reach hosts inside this netmask directly using layer 2, instead of sending packets via a router"). Even if the operating system's TCP/IP stack requires a netmask to be configured, for point-to-point links it could be just set to 255.255.255.255. So, why is this information sent in IKEv2?
但是，不清楚该属性的确切含义，因为“网络掩码”的概念对于点到点链路的定义不是很好（与多址链路不同，多址链路的意思是“您可以使用第2层直接到达该网络掩码内的主机，而不是通过路由器发送数据包”）。即使操作系统的TCP/IP堆栈需要配置网络掩码，对于点到点链接，也可以将其设置为255.255.255.255。那么，为什么这些信息是用IKEv2发送的呢？
One possible interpretation would be that the host is given a whole block of IP addresses instead of a single address. This is also what Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed-IPv6-Prefix attribute does in [RADIUS6]. However, nothing in the specification supports this interpretation, and discussions on the IPsec WG mailing list have confirmed it was not intended. Section 3.15.1 also says that multiple addresses are assigned using multiple INTERNAL_IP4/6_ADDRESS attributes.
一种可能的解释是，给主机一整块IP地址，而不是一个地址。这也是[RADIUS]中框架IP网络掩码所做的，PPP[IPCPUSBNET]中IPCP“子网掩码”扩展所做的，以及[RADIUS6]中IPv6 Framed-IPv6-prefix属性中的前缀长度所做的。然而，规范中的任何内容都不支持这种解释，关于IPsec WG邮件列表的讨论也证实了这一点。第3.15.1节还规定，使用多个内部_IP4/6_地址属性分配多个地址。
Currently, this document's interpretation is the following: INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET containing the same information ("send traffic to these addresses through me"), but also implies a link boundary. For
目前，本文件的解释如下：CFG_回复中的INTERNAL_IP4_NETMASK与包含相同信息的INTERNAL_IP4_子网大致相同（“通过我向这些地址发送流量”），但也意味着链路边界。对于
instance, the client could use its own address and the netmask to calculate the broadcast address of the link. (Whether the gateway will actually deliver broadcast packets to other VPN clients and/or other nodes connected to this link is another matter.)
例如，客户端可以使用自己的地址和网络掩码来计算链路的广播地址。（网关是否实际向其他VPN客户端和/或连接到此链路的其他节点发送广播数据包是另一回事。）
An empty INTERNAL_IP4_NETMASK attribute can be included in a CFG_REQUEST to request this information (although the gateway can send the information even when not requested). However, it seems that non-empty values for this attribute do not make sense in CFG_REQUESTs.
CFG_请求中可以包含一个空的内部_IP4_NETMASK属性来请求此信息（尽管网关即使在未请求时也可以发送此信息）。但是，该属性的非空值在CFG_请求中似乎没有意义。
Fortunately, Section 4 clearly says that a minimal implementation does not need to include or understand the INTERNAL_IP4_NETMASK attribute, and thus this document recommends that implementations should not use the INTERNAL_IP4_NETMASK attribute or assume that the other peer supports it.
幸运的是，第4节明确指出，最低限度的实现不需要包括或理解内部_IP4_NETMASK属性，因此本文档建议实现不应使用内部_IP4_NETMASK属性或假设其他对等方支持它。
(References: Charlie Kaufman's mail "RE: Proposed Last Call based revisions to IKEv2", 2004-05-27. Email discussion with Tero Kivinen, Jan 2005. Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and Implementation Guidelines", 2005-02-07. "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
（参考文献：Charlie Kaufman的邮件“RE:IKEv2的最后一次基于呼叫的修订建议”，2004-05-27。与Tero Kivinen的电子邮件讨论，2005年1月。Yoav Nir的邮件“RE:新I-D:IKEv2澄清和实施指南”，2005-02-07。“澄清公开问题：内部_IP4_子网/网络掩码”线程，2005年4月。）
IKEv2 also defines configuration payloads for IPv6. However, they are based on the corresponding IPv4 payloads and do not fully follow the "normal IPv6 way of doing things".
IKEv2还定义了IPv6的配置有效负载。但是，它们基于相应的IPv4有效负载，并没有完全遵循“正常的IPv6做事方式”。
A client can be assigned an IPv6 address using the INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange could look like this:
可以使用内部IP地址配置负载为客户端分配IPv6地址。最小交换可能如下所示：
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
In particular, IPv6 stateless autoconfiguration or router advertisement messages are not used; neither is neighbor discovery.
特别是，不使用IPv6无状态自动配置或路由器广告消息；邻居发现也不是。
The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST to request a specific address or interface identifier. The gateway first checks if the specified address is acceptable, and if it is, returns that one. If the address was not acceptable, the gateway will attempt to use the interface identifier with some other prefix; if even that fails, the gateway will select another interface identifier.
客户端还可以在CFG_请求中发送非空的内部_IP6_ADDRESS属性，以请求特定的地址或接口标识符。网关首先检查指定的地址是否可接受，如果可接受，则返回该地址。如果地址不可接受，网关将尝试使用带有其他前缀的接口标识符；即使失败，网关也会选择另一个接口标识符。
The INTERNAL_IP6_ADDRESS attribute also contains a prefix length field. When used in a CFG_REPLY, this corresponds to the INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft). See the previous section for more details.
内部_IP6_ADDRESS属性还包含前缀长度字段。在CFG_回复中使用时，它对应于IPv4情况下的内部_IP4_网络掩码属性（实际上，在早期版本的IKEv2草案中称为内部_IP6_网络掩码）。有关更多详细信息，请参见上一节。
While this approach to configuring IPv6 addresses is reasonably simple, it has some limitations: IPsec tunnels configured using IKEv2 are not fully-featured "interfaces" in the IPv6 addressing architecture [IPv6Addr] sense. In particular, they do not necessarily have link-local addresses, and this may complicate the use of protocols that assume them, such as [MLDv2]. (Whether they are called "interfaces" in some particular operating system is a different issue.)
虽然这种配置IPv6地址的方法相当简单，但它有一些局限性：使用IKEv2配置的IPsec隧道在IPv6寻址体系结构[IPv6Addr]意义上不是功能齐全的“接口”。特别是，它们不一定具有链路本地地址，这可能会使采用它们的协议（如[MLDv2]）的使用复杂化。（在某些特定操作系统中，它们是否被称为“接口”是另一个问题。）
(References: "VPN remote host configuration IPv6 ?" thread, May 2004. "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
（参考资料：“VPN远程主机配置IPv6？”线程，2004年5月。“澄清公开问题：内部_IP4_子网/网络掩码”线程，2005年4月。）
Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending the IPv6 address of NetBIOS name servers.
第3.15.1节定义了用于发送NetBIOS名称服务器的IPv6地址的内部_IP6nbns属性。
However, NetBIOS is not defined for IPv6 and probably never will be. Thus, this attribute most likely does not make much sense.
然而，NetBIOS并没有为IPv6定义，而且可能永远也不会。因此，这个属性很可能没有多大意义。
(Pointed out by Bernard Aboba in the IP Configuration Security (ICOS) BoF at IETF62.)
（Bernard Aboba在IETF62的IP配置安全（ICOS）BoF中指出。）
Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as "Specifies the number of seconds that the host can use the internal IP address. The host MUST renew the IP address before this expiry time. Only one of these attributes MAY be present in the reply."
第3.15.1节将INTERNAL_ADDRESS_expiration属性定义为“指定主机可以使用内部IP地址的秒数。主机必须在此到期时间之前续订IP地址。回复中只能出现其中一个属性。”
Expiry times and explicit renewals are primarily useful in environments like DHCP, where the server cannot reliably know when
到期时间和显式续订主要在DHCP这样的环境中有用，因为服务器无法可靠地知道何时续订
the client has gone away. However, in IKEv2 this is known, and the gateway can simply free the address when the IKE_SA is deleted.
客户走了。然而，在IKEv2中这是已知的，当IKE_SA被删除时，网关可以简单地释放地址。
Also, Section 4 says that supporting renewals is not mandatory. Given that this functionality is usually not needed, we recommend that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute. (And since this attribute does not seem to make much sense for CFG_REQUESTs, clients should not send it either.)
此外，第4节说，支持续约不是强制性的。鉴于通常不需要此功能，我们建议网关不应发送内部地址到期属性。（由于该属性对于CFG_请求似乎没有多大意义，客户端也不应该发送它。）
Note that according to Section 4, clients are required to understand INTERNAL_ADDRESS_EXPIRY if they receive it. A minimum implementation would use the value to limit the lifetime of the IKE_SA.
请注意，根据第4节的规定，如果客户收到内部地址，则需要了解其有效期。最小实现将使用该值限制IKE_SA的生存期。
(References: Tero Kivinen's mail "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05. "Questions about internal address" thread, April 2005.)
（参考文献：Tero Kivinen的邮件“draft-eronen-ipsec-ikev2-Diclarations-02.txt的评论”，2005-04-05，“内部地址问题”线程，2005年4月。）
If the responder encounters an error while attempting to assign an IP address to the initiator, it responds with an INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1. However, there are some more complex error cases.
如果响应者在尝试将IP地址分配给启动器时遇到错误，则响应者将发出内部地址失败通知，如第3.10.1节所述。但是，还有一些更复杂的错误情况。
First, if the responder does not support configuration payloads at all, it can simply ignore all configuration payloads. This type of implementation never sends INTERNAL_ADDRESS_FAILURE notifications. If the initiator requires the assignment of an IP address, it will treat a response without CFG_REPLY as an error.
首先，如果响应程序根本不支持配置有效负载，它可以忽略所有配置有效负载。这种类型的实现从不发送内部地址失败通知。如果发起者需要分配IP地址，它会将没有CFG_REPLY的响应视为错误。
A second case is where the responder does support configuration payloads, but only for particular type of addresses (IPv4 or IPv6). Section 4 says that "A minimal IPv4 responder implementation will ignore the contents of the CP payload except to determine that it includes an INTERNAL_IP4_ADDRESS attribute". If, for instance, the initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the IPv6 part and process the IPv4 request as usual.
第二种情况是响应程序确实支持配置有效负载，但仅支持特定类型的地址（IPv4或IPv6）。第4节说，“最小IPv4响应程序实现将忽略CP有效负载的内容，除非确定它包含内部的_IP4_ADDRESS属性”。例如，如果发起方在CFG_请求中同时包含内部_IP4_地址和内部_IP6_地址，则仅IPv4响应方可以忽略IPv6部分，并像往常一样处理IPv4请求。
A third case is where the initiator requests multiple addresses of a type that the responder supports: what should happen if some (but not all) of the requests fail? It seems that an optimistic approach would be the best one here: if the responder is able to assign at least one address, it replies with those; it sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
第三种情况是发起者请求响应者支持的类型的多个地址：如果部分（但不是全部）请求失败，该怎么办？在这里，乐观的方法似乎是最好的：如果响应者能够分配至少一个地址，它会用这些地址进行回复；仅当无法分配地址时，才会发送内部地址失败。
(References: "ikev2 and internal_ivpn_address" thread, June 2005.)
（参考文献：“ikev2和内部地址”线程，2005年6月。）
When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match anything in the TSi/TSr payloads. For example, in a site-to-site VPN between two security gateways, the gateways could authenticate each other as ID_IPV4_ADDR(192.0.1.1) and ID_IPV4_ADDR(192.0.2.1), and then create a CHILD_SA for protecting traffic between 192.0.1.55/32 (a host behind the first security gateway) and 192.0.2.240/28 (a network behind the second security gateway). The authenticated identities (IDi/IDr) are linked to the authorized traffic selectors (TSi/TSr) using "Child SA Authorization Data" in the Peer Authorization Database (PAD).
在IDi/IDr有效载荷中使用ID_IPV4_ADDR/ID_IPV6_ADDR标识类型时，IKEv2不需要此地址来匹配TSi/TSr有效载荷中的任何内容。例如，在两个安全网关之间的站点到站点VPN中，网关可以将彼此身份验证为ID_IPV4_ADDR（192.0.1.1）和ID_IPV4_ADDR（192.0.2.1），然后创建子_SA以保护192.0.1.55/32（第一个安全网关后面的主机）和192.0.2.240/28（第二个安全网关后面的网络）之间的流量。已验证身份（IDi/IDr）使用对等授权数据库（PAD）中的“子SA授权数据”链接到授权流量选择器（TSi/TSr）。
Furthermore, IKEv2 does not require that the addresses in ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the IKE packets. However, other specifications may place additional requirements regarding this. For example, [PKI4IPsec] requires that implementation must be capable of comparing the addresses in the ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the IKE packets, and this comparison must be enabled by default.
此外，IKEv2不要求ID_IPV4_ADDR/ID_IPV6_ADDR中的地址与IKE数据包的IP报头中的地址匹配。但是，其他规范可能对此提出额外要求。例如，[PKI4IPsec]要求实现必须能够将ID_IPV4_ADDR/ID_IPV6_ADDR中的地址与IKE数据包的IP报头中的地址进行比较，并且默认情况下必须启用此比较。
(References: "Identities types IP address,FQDN/user FQDN and DN and its usage in preshared key authentication" thread, Jan 2005. "Matching ID_IPV4_ADDR and ID_IPV6_ADDR" thread, May 2006.)
（参考资料：“身份类型IP地址、FQDN/用户FQDN和DN及其在预共享密钥身份验证中的使用”线程，2005年1月。“匹配ID_IPV4_地址和ID_IPV6_地址”线程，2006年5月。）
The IKEv2 specification refers to [RFC4301], but it never clearly defines the exact relationship.
IKEv2规范引用了[RFC4301]，但它从未明确定义确切的关系。
However, there are some requirements in the specification that make it clear that IKEv2 requires [RFC4301]. In other words, an implementation that does IPsec processing strictly according to [RFC2401] cannot be compliant with the IKEv2 specification.
然而，规范中有一些要求明确说明IKEv2需要[RFC4301]。换句话说，严格按照[RFC2401]进行IPsec处理的实现不能符合IKEv2规范。
One such example can be found in Section 2.24: "Specifically, tunnel encapsulators and decapsulators for all tunnel-mode SAs created by IKEv2 [...] MUST implement the tunnel encapsulation and decapsulation processing specified in [RFC4301] to prevent discarding of ECN congestion indications."
在第2.24节中可以找到这样一个示例：“具体而言，IKEv2[…]创建的所有隧道模式SA的隧道封装器和去封装器必须实现[RFC4301]中规定的隧道封装和去封装处理，以防止丢弃ECN拥塞指示。”
Nevertheless, the changes required to existing [RFC2401] implementations are not very large, especially since supporting many of the new features (such as Extended Sequence Numbers) is optional.
然而，对现有[RFC2401]实现所需的更改并不是很大，特别是因为支持许多新特性（如扩展序列号）是可选的。
In IKEv2, the window size is assumed to be a (possibly configurable) property of a particular implementation and is not related to congestion control (unlike the window size in TCP, for instance).
在IKEv2中，窗口大小被假定为特定实现的（可能可配置）属性，与拥塞控制无关（例如，与TCP中的窗口大小不同）。
In particular, it is not defined what the responder should do when it receives a SET_WINDOW_SIZE notification containing a smaller value than is currently in effect. Thus, there is currently no way to reduce the window size of an existing IKE_SA. However, when rekeying an IKE_SA, the new IKE_SA starts with window size 1 until it is explicitly increased by sending a new SET_WINDOW_SIZE notification.
特别是，未定义响应程序在收到包含小于当前有效值的SET_WINDOW_SIZE通知时应执行的操作。因此，目前没有办法减小现有IKE_SA的窗口大小。但是，在为IKE_SA重新设置密钥时，新IKE_SA从窗口大小1开始，直到通过发送新的SET_window_size通知显式增加。
(References: Tero Kivinen's mail "Comments of draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
（参考文献：Tero Kivinen的邮件“draft-eronen-ipsec-ikev2-Diclarations-02.txt的评论”，2005-04-05。）
Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST be at least half the key size of the negotiated prf."
第2.10节说，“IKEv2中使用的nonce必须随机选择，大小必须至少为128位，并且必须至少为协商prf密钥大小的一半。”
However, the initiator chooses the nonce before the outcome of the negotiation is known. In this case, the nonce has to be long enough for all the PRFs being proposed.
但是，发起者在知道协商结果之前选择nonce。在这种情况下，nonce必须足够长，以满足所有提议的PRF。
It is not clear whether a peer sending an IKE_SA_INIT request on port 4500 should include the initial four zero octets. Section 2.23 talks about how to upgrade to tunneling over port 4500 after message 2, but it does not say what to do if message 1 is sent on port 4500.
不清楚在端口4500上发送IKE_SA_INIT请求的对等方是否应该包括最初的四个零八位字节。第2.23节讨论了在消息2之后如何通过端口4500升级到隧道，但没有说明如果消息1在端口4500上发送，该怎么办。
IKE MUST listen on port 4500 as well as port 500.
IKE必须侦听端口4500和端口500。
[...]
[...]
The IKE initiator MUST check these payloads if present and if they do not match the addresses in the outer packet MUST tunnel all future IKE and ESP packets associated with this IKE_SA over UDP port 4500.
IKE启动器必须检查这些有效负载（如果存在），如果它们与外部数据包中的地址不匹配，则必须通过UDP端口4500对与此IKE_SA关联的所有未来IKE和ESP数据包进行隧道传输。
To tunnel IKE packets over UDP port 4500, the IKE header has four octets of zero prepended and the result immediately follows the UDP header. [...]
要通过UDP端口4500对IKE数据包进行隧道传输，IKE报头有四个八位字节，前缀为零，结果紧跟在UDP报头之后。[...]
The very beginning of Section 2 says "... though IKE messages may also be received on UDP port 4500 with a slightly different format (see section 2.23)."
第2节一开始就说“……虽然IKE消息也可能在UDP端口4500上以稍微不同的格式接收（见第2.23节）。”
That "slightly different format" is only described in discussing what to do after changing to port 4500. However, [RFC3948] shows clearly the format has the initial zeros even for initiators on port 4500. Furthermore, without the initial zeros, the processing engine cannot determine whether the packet is an IKE packet or an ESP packet.
“稍微不同的格式”仅在讨论更改为端口4500后的操作时描述。但是，[RFC3948]清楚地显示，即使对于端口4500上的启动器，格式也具有初始零。此外，没有初始零，处理引擎无法确定该分组是IKE分组还是ESP分组。
Thus, all packets sent on port 4500 need the four-zero prefix; otherwise, the receiver won't know how to handle them.
因此，在端口4500上发送的所有分组都需要四个零前缀；否则，接收者将不知道如何处理它们。
Section 2.23 says that "an IPsec endpoint that discovers a NAT between it and its correspondent MUST send all subsequent traffic to and from port 4500".
第2.23节说，“在IPsec端点与其对应方之间发现NAT时，必须向端口4500发送所有后续通信量。”。
This sentence is misleading. The peer "outside" the NAT uses source port 4500 for the traffic it sends, but the destination port is, of course, taken from packets sent by the peer behind the NAT. This port number is usually dynamically allocated by the NAT.
这句话有误导性。NAT“外部”的对等方将源端口4500用于其发送的流量，但目标端口当然是从NAT后面的对等方发送的数据包中获取的。此端口号通常由NAT动态分配。
The IKEv2 specification is not quite clear what SPI values should be used in the IKE header for the small number of notifications that are allowed to be sent outside an IKE_SA. Note that such notifications are explicitly not Informational exchanges; Section 1.5 makes it clear that these are one-way messages that must not be responded to.
对于允许在IKE_SA外部发送的少量通知，IKEv2规范不太清楚IKE头中应该使用哪些SPI值。请注意，此类通知显然不是信息交换；第1.5节明确指出，这些信息是单向的，不得回应。
There are two cases when such a one-way notification can be sent: INVALID_IKE_SPI and INVALID_SPI.
可以发送这种单向通知的情况有两种：无效的\u IKE\u SPI和无效的\u SPI。
In case of INVALID_IKE_SPI, the message sent is a response message, and Section 2.21 says that "If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied."
在IKE SPI无效的情况下，发送的消息为响应消息，第2.21节规定“如果发送响应，则必须将响应发送到IP地址和端口，该IP地址和端口具有相同的IKE SPI和复制的消息ID。”
In case of INVALID_SPI, however, there are no IKE SPI values that would be meaningful to the recipient of such a notification. Also, the message sent is now an INFORMATIONAL request. A strict interpretation of the specification would require the sender to invent garbage values for the SPI fields. However, we think this was not the intention, and using zero values is acceptable.
但是，在无效_SPI的情况下，没有对此类通知的接收者有意义的IKE SPI值。此外，发送的消息现在是一个信息请求。对规范的严格解释要求发送方为SPI字段创建垃圾值。然而，我们认为这不是目的，使用零值是可以接受的。
(References: "INVALID_IKE_SPI" thread, June 2005.)
（参考文献：“无效的IKE_SPI”线程，2005年6月。）
Section 3.10 says that the Protocol ID field in Notify payloads "For notifications that do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt". However, the specification does not clearly say which notifications are related to existing SAs and which are not.
第3.10节指出，Notify payloads中的Protocol ID字段“对于与现有SA无关的通知，此字段必须作为零发送，并且在收到时必须忽略”。但是，该规范没有明确说明哪些通知与现有SA相关，哪些与现有SA无关。
Since the main purpose of the Protocol ID field is to specify the type of the SPI, our interpretation is that the Protocol ID field should be non-zero only when the SPI field is non-empty.
由于协议ID字段的主要目的是指定SPI的类型，因此我们的解释是，只有当SPI字段为非空时，协议ID字段才应为非零。
There are currently only two notifications where this is the case: INVALID_SELECTORS and REKEY_SA.
目前只有两个通知出现这种情况：无效的选择器和重新设置密钥。
The description of the INITIAL_CONTACT notification in Section 3.10.1 says that "This notification asserts that this IKE_SA is the only IKE_SA currently active between the authenticated identities". However, neither Section 2.4 nor 3.10.1 says in which message this payload should be placed.
第3.10.1节中对初始联系通知的描述表示，“该通知声明该IKE_SA是当前在认证身份之间活动的唯一IKE_SA”。但是，第2.4节和第3.10.1节均未说明该有效载荷应放在哪个消息中。
The general agreement is that INITIAL_CONTACT is best communicated in the first IKE_AUTH request, not as a separate exchange afterwards.
总的协议是，最初的联系最好在第一个IKE_认证请求中进行沟通，而不是在之后作为单独的交换。
(References: "Clarifying the use of INITIAL_CONTACT in IKEv2" thread, April 2005. "Initial Contact messages" thread, December 2004. "IKEv2 and Initial Contact" thread, September 2004 and April 2005.)
（参考资料：“澄清IKEv2中初始联系人的使用”线程，2005年4月。“初始联系人消息”线程，2004年12月。“IKEv2和初始联系人”线程，2004年9月和2005年4月。）
Many IKEv2 payloads contain fields marked as "RESERVED", mostly because IKEv1 had them, and partly because they make the pictures easier to draw. In particular, payloads in IKEv2 are not, in general, aligned to 4-octet boundaries. (Note that payloads were not aligned to 4-octet boundaries in IKEv1 either.)
许多IKEv2有效负载包含标记为“保留”的字段，主要是因为IKEv1有这些字段，部分是因为它们使图片更容易绘制。特别是，IKEv2中的有效载荷通常不与4-八位组边界对齐。（请注意，在IKEv1中，有效载荷也没有与4个八位组边界对齐。）
(References: "IKEv2: potential 4-byte alignment problem" thread, June 2004.)
（参考文献：“IKEv2：潜在的4字节对齐问题”thread，2004年6月。）
Section 3.3.5 says that "The only algorithms defined in this document that accept attributes are the AES based encryption, integrity, and pseudo-random functions, which require a single attribute specifying key width."
第3.3.5节指出，“本文件中定义的唯一接受属性的算法是基于AES的加密、完整性和伪随机函数，它们需要一个指定密钥宽度的属性。”
This is incorrect. The AES-based integrity and pseudo-random functions defined in [IKEv2] always use a 128-bit key. In fact, there are currently no integrity or PRF algorithms that use the key length attribute (and we recommend that they should not be defined in the future either).
这是不正确的。[IKEv2]中定义的基于AES的完整性和伪随机函数始终使用128位密钥。事实上，目前还没有使用密钥长度属性的完整性或PRF算法（我们建议以后也不要定义它们）。
For encryption algorithms, the situation is slightly more complex since there are three different types of algorithms:
对于加密算法，情况稍微复杂一些，因为有三种不同类型的算法：
o The key length attribute is never used with algorithms that use a fixed length key, such as DES and IDEA.
o 密钥长度属性从未用于使用固定长度密钥的算法，如DES和IDEA。
o The key length attribute is always included for the currently defined AES-based algorithms (Cipher Block Chaining (CBC), Counter (CTR) Mode, Counter with CBC-MAC (CCM), and Galois/Counter Mode (GCM)). Omitting the key length attribute is not allowed; if the proposal does not contain it, the proposal has to be rejected.
o 当前定义的基于AES的算法（密码块链接（CBC）、计数器（CTR）模式、带CBC-MAC的计数器（CCM）和伽罗瓦/计数器模式（GCM））始终包含密钥长度属性。不允许省略键长度属性；如果提案中未包含，则必须拒绝该提案。
o For other algorithms, the key length attribute can be included but is not mandatory. These algorithms include, e.g., RC5, CAST, and BLOWFISH. If the key length attribute is not included, the default value specified in [RFC2451] is used.
o 对于其他算法，可以包括“密钥长度”属性，但不是强制性的。这些算法包括，例如RC5、CAST和河豚。如果未包括密钥长度属性，则使用[RFC2451]中指定的默认值。
There are currently three different IANA registry files that contain important numbers for IPsec: ikev2-registry, isakmp-registry, and ipsec-registry. Implementers should note that IKEv2 may use numbers different from those of IKEv1 for a particular algorithm.
目前有三个不同的IANA注册表文件包含IPsec的重要编号：ikev2注册表、isakmp注册表和IPsec注册表。实现者应该注意，对于特定算法，IKEv2可能使用不同于IKEv1的数字。
For instance, an encryption algorithm can have up to three different numbers: the IKEv2 "Transform Type 1" identifier in ikev2-registry, the IKEv1 phase 1 "Encryption Algorithm" identifier in ipsec-registry, and the IKEv1 phase 2 "IPSEC ESP Transform Identifier" isakmp-registry. Although some algorithms have the same number in all three registries, the registries are not identical.
例如，加密算法最多可以有三个不同的数字：IKEv2注册表中的IKEv2“Transform Type 1”标识符、ipsec注册表中的IKEv1 phase 1“encryption algorithm”标识符以及IKEv1 phase 2“ipsec ESP Transform identifier”isakmp注册表。尽管某些算法在所有三个注册中心中的编号相同，但注册中心并不相同。
Similarly, an integrity algorithm can have at least the IKEv2 "Transform Type 3" identifier in ikev2-registry, the IKEv1 phase 2 "IPSEC AH Transform Identifier" in isakmp-registry, and the IKEv1 phase 2 ESP "Authentication Algorithm Security Association Attribute" identifier in isakmp-registry. And there is also the IKEv1 phase 1 "Hash Algorithm" list in ipsec-registry.
类似地，完整性算法至少可以在IKEv2注册表中具有IKEv2“转换类型3”标识符，在isakmp注册表中具有IKEv1阶段2“IPSEC AH转换标识符”，在isakmp注册表中具有IKEv1阶段2 ESP“验证算法安全关联属性”标识符。ipsec注册表中还有IKEv1第1阶段“哈希算法”列表。
This issue needs special care also when writing a specification for how a new algorithm is used with IPsec.
在编写新算法如何与IPsec一起使用的规范时，也需要特别注意这个问题。
The IKEv2 specification contains some misleading text about how ESP and AH can be combined.
IKEv2规范包含一些关于ESP和AH如何组合的误导性文本。
IKEv2 is based on [RFC4301], which does not include "SA bundles" that were part of [RFC2401]. While a single packet can go through IPsec processing multiple times, each of these passes uses a separate SA, and the passes are coordinated by the forwarding tables. In IKEv2, each of these SAs has to be created using a separate CREATE_CHILD_SA exchange. Thus, the text in Section 2.7 about a single proposal containing both ESP and AH is incorrect.
IKEv2基于[RFC4301]，其中不包括作为[RFC2401]一部分的“SA包”。虽然单个数据包可以多次通过IPsec处理，但每个过程都使用单独的SA，并且这些过程由转发表协调。在IKEv2中，必须使用单独的CREATE_CHILD_SA交换创建每个SA。因此，第2.7节中关于包含ESP和AH的单一提案的文本是不正确的。
Moreover, the combination of ESP and AH (between the same endpoints) had already become largely obsolete in 1998 when RFC 2406 was published. Our recommendation is that IKEv2 implementations should not support this combination, and implementers should not assume the combination can be made to work in an interoperable manner.
此外，ESP和AH的组合（在相同的端点之间）在1998年RFC 2406发布时已经基本过时。我们的建议是IKEv2实现不应该支持这种组合，并且实现者不应该假设这种组合可以以互操作的方式工作。
(References: "Rekeying SA bundles" thread, Oct 2005.)
（参考：2005年10月“重新设置SA捆绑包”线程。）
Some implementers at the early IKEv2 bakeoffs didn't do everything correctly. This may seem like an obvious statement, but it is probably useful to list a few things that were clear in the document, but that some implementers didn't do. All of these things caused interoperability problems.
早期IKEv2 bakeoffs的一些实现者没有正确地完成所有事情。这似乎是一个显而易见的声明，但是列出文档中明确的一些事情可能是有用的，但是一些实现者没有做到。所有这些都导致了互操作性问题。
o Some implementations continued to send traffic on a CHILD_SA after it was rekeyed, even after receiving an DELETE payload.
o 一些实现在重新设置密钥后，甚至在接收到删除负载后，仍继续在CHILD_SA上发送流量。
o After rekeying an IKE_SA, some implementations did not reset their message counters to zero. One set the counter to 2, another did not reset the counter at all.
o 在为IKE_SA重新设置密钥后，一些实现没有将其消息计数器重置为零。一个将计数器设置为2，另一个根本没有重置计数器。
o Some implementations could only handle a single pair of traffic selectors or would only process the first pair in the proposal.
o 有些实现只能处理一对流量选择器，或者只能处理提案中的第一对流量选择器。
o Some implementations responded to a delete request by sending an empty INFORMATIONAL response and then initiated their own INFORMATIONAL exchange with the pair of SAs to delete.
o 一些实现通过发送一个空的信息响应来响应删除请求，然后启动它们自己与要删除的SA对的信息交换。
o Although this did not happen at the bakeoff, from the discussion there, it is clear that some people had not implemented message window sizes correctly. Some implementations might have sent
o 尽管在bakeoff没有发生这种情况，但从那里的讨论可以看出，有些人没有正确地实现消息窗口大小。一些实现可能已经发送了
messages that did not fit into the responder's message windows, and some implementations may not have torn down an SA if they did not ever receive a message that they know they should have.
不适合响应者的消息窗口的消息，如果某些实现从未收到他们知道应该收到的消息，则可能没有拆毁SA。
This document does not introduce any new security considerations to IKEv2. If anything, clarifying complex areas of the specification can reduce the likelihood of implementation problems that may have security implications.
本文档未向IKEv2引入任何新的安全注意事项。如果说有什么区别的话，那么澄清规范的复杂领域可以降低可能具有安全影响的实现问题的可能性。
This document is mainly based on conversations on the IPsec WG mailing list. The authors would especially like to thank Bernard Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Francis Dupont, Alfred Hoenes, Mika Joutsenvirta, Charlie Kaufman, Stephen Kent, Tero Kivinen, Yoav Nir, Michael Richardson, and Joel Snyder for their contributions.
本文档主要基于IPsec WG邮件列表上的对话。作者特别要感谢伯纳德·阿博巴、贾里·阿尔科、维杰·德瓦拉帕利、威廉·迪克森、弗朗西斯·杜邦、阿尔弗雷德·霍恩斯、米卡·朱特森维塔、查理·考夫曼、斯蒂芬·肯特、泰罗·基维宁、约夫·尼尔、迈克尔·理查森和乔尔·斯奈德的贡献。
In addition, the authors would like to thank all the participants of the first public IKEv2 bakeoff, held in Santa Clara in February 2005, for their questions and proposed clarifications.
此外，提交人要感谢2005年2月在圣克拉拉举行的第一次IKEv2 bakeoff公开会议的所有与会者提出的问题和提出的澄清。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]考夫曼，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[IKEv2ALG] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[IKEv2ALG]Schiller，J.，“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，2005年12月。
[PKCS1v20] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998.
[PKCS1v20]Kaliski，B.和J.Staddon，“PKCS#1:RSA加密规范2.0版”，RFC 2437，1998年10月。
[PKCS1v21] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[PKCS1v21]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[Aura05] Aura, T., Roe, M., and A. Mohammed, "Experiences with Host-to-Host IPsec", 13th International Workshop on Security Protocols, Cambridge, UK, April 2005.
[Aura，T.，Roe，M.，和A.Mohammed，“主机对主机IPsec的经验”，第13届安全协议国际研讨会，英国剑桥，2005年4月。
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[EAP]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[HashUse] Hoffman, P., "Use of Hash Algorithms in IKE and IPsec", Work in Progress, July 2006.
[HashUse]Hoffman，P.，“哈希算法在IKE和IPsec中的使用”，正在进行的工作，2006年7月。
[IPCPSubnet] Cisco Systems, Inc., "IPCP Subnet Mask Support Enhancements", http://www.cisco.com/univercd/cc/td/ doc/product/software/ios121/121newft/121limit/121dc/ 121dc3/ipcp_msk.htm, January 2003.
[IPCPUSBNET]思科系统公司，“IPCP子网掩码支持增强”，http://www.cisco.com/univercd/cc/td/ doc/product/software/ios121/121newft/121limit/121dc/121dc3/ipcp_msk.htm，2003年1月。
[IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[IPv6Addr]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[MIPv6]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MLDv2]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[NAI]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络接入标识符”，RFC 42822005年12月。
[PKI4IPsec] Korver, B., "Internet PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Work in Progress, April 2006.
[PKI4IPsec]Korver，B.，“IKEv1/ISAKMP、IKEv2和PKIX的互联网PKI配置文件”，正在进行的工作，2006年4月。
[RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RADEAP]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RADIUS]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RADIUS6] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RADIUS6]Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC 3162，2001年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[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月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 3664, January 2004.
[RFC3664]Hoffman，P.，“互联网密钥交换协议（IKE）的AES-XCBC-PRF-128算法”，RFC 3664，2004年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4434, February 2006.
[RFC4434]Hoffman，P.，“互联网密钥交换协议（IKE）的AES-XCBC-PRF-128算法”，RFC 4434，2006年2月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，RFC 822，1982年8月。
[ReAuth] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[ReAuth]Nir，Y，“互联网密钥交换（IKEv2）协议中的重复认证”，RFC 4478，2006年4月。
[SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and T. Polk, "Simple Certificate Validation Protocol (SCVP)", Work in Progress, June 2006.
[SCVP]Freeman，T.，Housley，R.，Malpani，A.，Cooper，D.，和T.Polk，“简单证书验证协议（SCVP）”，正在进行的工作，2006年6月。
This appendix contains a short summary of the IKEv2 exchanges, and what payloads can appear in which message. This appendix is purely informative; if it disagrees with the body of this document or the IKEv2 specification, the other text is considered correct.
本附录包含IKEv2交换的简短摘要，以及在哪个消息中可以显示哪些有效负载。本附录仅供参考；如果与本文件正文或IKEv2规范不一致，则认为其他文本正确。
Vendor-ID (V) payloads may be included in any place in any message. This sequence shows what are, in our opinion, the most logical places for them.
供应商ID（V）有效载荷可包含在任何消息的任何位置。在我们看来，这一顺序显示了它们最符合逻辑的位置。
The specification does not say which messages can contain N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is not yet shown below.
规范没有说明哪些消息可以包含N（设置窗口大小）。它可能包含在任何消息中，但下面尚未显示。
request --> [N(COOKIE)],
SA, KE, Ni,
[N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP)],
[V+]
request --> [N(COOKIE)],
SA, KE, Ni,
[N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP)],
[V+]
normal response <-- SA, KE, Nr,
(no cookie) [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[V+]
normal response <-- SA, KE, Nr,
(no cookie) [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[V+]
request --> IDi, [CERT+],
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
AUTH,
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[V+]
request --> IDi, [CERT+],
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
AUTH,
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[V+]
response <-- IDr, [CERT+],
AUTH,
[CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)],
[V+]
response <-- IDr, [CERT+],
AUTH,
[CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)],
[V+]
first request --> IDi,
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[V+]
first request --> IDi,
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[V+]
first response <-- IDr, [CERT+], AUTH, EAP, [V+]
第一个响应<--IDr、[CERT+]，认证，EAP，[V+]
/ --> EAP repeat 1..N times | \ <-- EAP
/-->EAP重复1..N次| \<--EAP
last request --> AUTH
上次请求-->身份验证
last response <-- AUTH,
[CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)],
[V+]
last response <-- AUTH,
[CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)],
[V+]
request --> [N(REKEY_SA)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Ni, [KEi], TSi, TSr
request --> [N(REKEY_SA)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Ni, [KEi], TSi, TSr
response <-- [N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Nr, [KEr], TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)]
response <-- [N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Nr, [KEr], TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)]
request --> SA, Ni, [KEi]
请求-->SA，Ni，[KEi]
response <-- SA, Nr, [KEr]
响应<--SA，Nr，[KEr]
request --> [N+],
[D+],
[CP(CFG_REQUEST)]
request --> [N+],
[D+],
[CP(CFG_REQUEST)]
response <-- [N+], [D+], [CP(CFG_REPLY)]
答复<-[N+]，[D+]，[CP（CFG_答复）]
Authors' Addresses
作者地址
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen诺基亚研究中心邮政信箱407 FIN-00045诺基亚集团芬兰
EMail: pasi.eronen@nokia.com
EMail: pasi.eronen@nokia.com
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA
美国加利福尼亚州圣克鲁斯塞格雷广场127号保罗·霍夫曼VPN联盟，邮编95060
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。