Network Working Group P. Eronen, Ed.
Request for Comments: 4555 Nokia
Category: Standards Track June 2006
Network Working Group P. Eronen, Ed.
Request for Comments: 4555 Nokia
Category: Standards Track June 2006
IKEv2 Mobility and Multihoming Protocol (MOBIKE)
IKEv2移动和多址协议（MOBIKE）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working.
本文档描述了MOBIKE协议，它是Internet密钥交换（IKEv2）的移动性和多归属扩展。MOBIKE允许更改与IKEv2和隧道模式IPsec安全关联关联的IP地址。移动虚拟专用网（VPN）客户端可以使用MOBIKE在从一个地址移动到另一个地址时保持与VPN网关的连接处于活动状态。类似地，如果当前使用的接口停止工作，多宿主主机可以使用MOBIKE将流量移动到不同的接口。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 6
2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9
3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10
3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10
3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 11
3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11
3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12
3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15
3.7. Return Routability Check . . . . . . . . . . . . . . . . . 17
3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19
3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 20
3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 20
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 21
4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 24
5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 24
5.3. Denial-of-Service Attacks against Third Parties . . . . . 25
5.4. Spoofing Network Connectivity Indications . . . . . . . . 26
5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Implementation Considerations . . . . . . . . . . . . 31
A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31
A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 6
2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9
3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10
3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10
3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 11
3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11
3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12
3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15
3.7. Return Routability Check . . . . . . . . . . . . . . . . . 17
3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19
3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 20
3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 20
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 21
4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 24
5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 24
5.3. Denial-of-Service Attacks against Third Parties . . . . . 25
5.4. Spoofing Network Connectivity Indications . . . . . . . . 26
5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Implementation Considerations . . . . . . . . . . . . 31
A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31
A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 31
IKEv2 is used for performing mutual authentication, as well as establishing and maintaining IPsec Security Associations (SAs). In the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec SAs are created implicitly between the IP addresses that are used when the IKE_SA is established. These IP addresses are then used as the outer (tunnel header) addresses for tunnel mode IPsec packets (transport mode IPsec SAs are beyond the scope of this document). Currently, it is not possible to change these addresses after the IKE_SA has been created.
IKEv2用于执行相互身份验证，以及建立和维护IPsec安全关联（SA）。在基本IKEv2协议[IKEv2]中，IKE SA和隧道模式IPsec SA在建立IKE_SA时使用的IP地址之间隐式创建。然后，这些IP地址将用作隧道模式IPsec数据包的外部（隧道头）地址（传输模式IPsec SAs超出了本文档的范围）。目前，在创建IKE_SA后，无法更改这些地址。
There are scenarios where these IP addresses might change. One example is mobility: a host changes its point of network attachment and receives a new IP address. Another example is a multihoming host that would like to change to a different interface if, for instance, the currently used interface stops working for some reason.
在某些情况下，这些IP地址可能会更改。一个例子是移动性：主机更改其网络连接点并接收新的IP地址。另一个例子是多宿主主机，例如，如果当前使用的接口因某种原因停止工作，则希望更改为其他接口。
Although the problem can be solved by creating new IKE and IPsec SAs when the addresses need to be changed, this may not be optimal for several reasons. In some cases, creating a new IKE_SA may require user interaction for authentication, such as entering a code from a token card. Creating new SAs often involves expensive calculations and possibly a large number of round-trips. For these reasons, a mechanism for updating the IP addresses of existing IKE and IPsec SAs is needed. The MOBIKE protocol described in this document provides such a mechanism.
虽然当需要更改地址时，可以通过创建新的IKE和IPsec SA来解决此问题，但由于几个原因，这可能不是最佳的。在某些情况下，创建新IKE_SA可能需要用户交互进行身份验证，例如从令牌卡输入代码。创建新SA通常涉及昂贵的计算和可能的大量往返。出于这些原因，需要一种更新现有IKE和IPsec SA的IP地址的机制。本文档中描述的MOBIKE协议提供了这样一种机制。
The main scenario for MOBIKE is enabling a remote access VPN user to move from one address to another without re-establishing all security associations with the VPN gateway. For instance, a user could start from fixed Ethernet in the office and then disconnect the laptop and move to the office's wireless LAN. When the user leaves the office, the laptop could start using General Packet Radio Service (GPRS); when the user arrives home, the laptop could switch to the home wireless LAN. MOBIKE updates only the outer (tunnel header) addresses of IPsec SAs, and the addresses and other traffic selectors used inside the tunnel stay unchanged. Thus, mobility can be (mostly) invisible to applications and their connections using the VPN.
MOBIKE的主要场景是允许远程访问VPN用户从一个地址移动到另一个地址，而无需重新建立与VPN网关的所有安全关联。例如，用户可以从办公室的固定以太网开始，然后断开笔记本电脑的连接，移动到办公室的无线局域网。当用户离开办公室时，笔记本电脑可以开始使用通用分组无线服务（GPRS）；当用户到家时，笔记本电脑可以切换到家庭无线局域网。MOBIKE只更新IPsec SAs的外部（隧道头）地址，隧道内使用的地址和其他流量选择器保持不变。因此，对于使用VPN的应用程序及其连接来说，移动性（大部分）是不可见的。
MOBIKE also supports more complex scenarios where the VPN gateway also has several network interfaces: these interfaces could be connected to different networks or ISPs, they may be a mix of IPv4 and IPv6 addresses, and the addresses may change over time. Furthermore, both parties could be VPN gateways relaying traffic for other parties.
MOBIKE还支持更复杂的场景，其中VPN网关还具有多个网络接口：这些接口可以连接到不同的网络或ISP，它们可能是IPv4和IPv6地址的混合，并且地址可能会随时间而变化。此外，双方都可以是VPN网关，为其他方中继流量。
This document focuses on the main scenario outlined above and supports only tunnel mode IPsec SAs.
本文档重点介绍上述主要场景，仅支持隧道模式IPsec SAs。
The mobility support in MOBIKE allows both parties to move, but does not provide a "rendezvous" mechanism that would allow simultaneous movement of both parties or discovery of the addresses when the IKE_SA is first established. Therefore, MOBIKE is best suited for situations where the address of at least one endpoint is relatively stable and can be discovered using existing mechanisms such as DNS (see Section 3.1).
MOBIKE中的移动性支持允许双方移动，但不提供允许双方同时移动或在IKE_SA首次建立时发现地址的“会合”机制。因此，MOBIKE最适合于至少一个端点的地址相对稳定并且可以使用现有机制（如DNS）发现的情况（见第3.1节）。
MOBIKE allows both parties to be multihomed; however, only one pair of addresses is used for an SA at a time. In particular, load balancing is beyond the scope of this specification.
MOBIKE允许双方都是多址的；但是，一次只有一对地址用于SA。特别是，负载平衡超出了本规范的范围。
MOBIKE follows the IKEv2 practice where a response message is sent to the same address and port from which the request was received. This implies that MOBIKE does not work over address pairs that provide only unidirectional connectivity.
MOBIKE遵循IKEv2实践，将响应消息发送到接收请求的相同地址和端口。这意味着MOBIKE不会在仅提供单向连接的地址对上工作。
Network Address Translators (NATs) introduce additional limitations beyond those listed above. For details, refer to Section 2.3.
网络地址转换器（NAT）引入了上述限制之外的其他限制。有关详细信息，请参阅第2.3节。
The base version of the MOBIKE protocol does not cover all potential future use scenarios, such as transport mode, application to securing SCTP, or optimizations desirable in specific circumstances. Future extensions may be defined later to support additional requirements. Please consult the MOBIKE design document [Design] for further information and rationale behind these limitations.
MOBIKE协议的基本版本并未涵盖所有潜在的未来使用场景，例如传输模式、保护SCTP的应用程序或特定情况下需要的优化。以后可能会定义将来的扩展以支持其他需求。请参考MOBIKE设计文件[design]，了解这些限制背后的更多信息和基本原理。
When messages containing IKEv2 payloads are described, optional payloads are shown in brackets (for instance, "[FOO]"), and a plus sign indicates that a payload can be repeated one or more times (for instance, "FOO+"). To provide context, some diagrams also show what existing IKEv2 payloads would typically be included in the exchanges. These payloads are shown for illustrative purposes only; see [IKEv2] for an authoritative description.
当描述包含IKEv2有效载荷的消息时，可选有效载荷显示在括号中（例如，“[FOO]”），加号表示有效载荷可以重复一次或多次（例如，“FOO+”）。为了提供上下文，一些图表还显示了交换中通常包括的现有IKEv2有效负载。显示这些有效载荷仅用于说明目的；有关权威性描述，请参见[IKEv2]。
When this document describes updating the source/destination addresses of an IPsec SA, it means updating IPsec-related state so that outgoing Encapsulating Security Payload (ESP)/Authentication Header (AH) packets use those addresses in the tunnel header. Depending on how the nominal divisions between Security Association Database (SAD), Security Policy Database (SPD), and Peer Authorization Database (PAD) described in [IPsecArch] are actually implemented, an implementation can have several different places that have to be updated.
当本文档描述更新IPsec SA的源/目标地址时，它意味着更新IPsec相关状态，以便传出封装安全有效负载（ESP）/身份验证头（AH）数据包使用隧道头中的这些地址。根据[IPsecArch]中描述的安全关联数据库（SAD）、安全策略数据库（SPD）和对等授权数据库（PAD）之间的名义划分是如何实际实现的，一个实现可以有几个不同的位置需要更新。
In this document, the term "initiator" means the party who originally initiated the first IKE_SA (in a series of possibly several rekeyed IKE_SAs); "responder" is the other peer. During the lifetime of the IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA exchanges; in this case, the terms "exchange initiator" and "exchange responder" are used. The term "original initiator" (which in [IKEv2] refers to the party who started the latest IKE_SA rekeying) is not used in this document.
在本文件中，术语“发起人”是指最初发起第一个IKE_SA的一方（在一系列可能重新编制的IKE_SA中）；“响应者”是另一个对等方。在IKE_SA有效期内，双方可发起信息交流或创建儿童交流；在这种情况下，使用术语“exchange启动器”和“exchange响应者”。本文件中未使用术语“原始发起人”（在[IKEv2]中指启动最新IKE_SA密钥更新的一方）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
MOBIKE allows both parties to have several addresses, and there are up to N*M pairs of IP addresses that could potentially be used. The decision of which of these pairs to use has to take into account several factors. First, the parties may have preferences about which interface should be used due to, for instance, performance and cost reasons. Second, the decision is constrained by the fact that some of the pairs may not work at all due to incompatible IP versions, outages in the network, problems at the local link at either end, and so on.
MOBIKE允许双方拥有多个地址，并且有多达N*M对的IP地址可能被使用。决定使用哪一对必须考虑几个因素。首先，由于性能和成本等原因，各方可能对应使用哪种接口有偏好。其次，由于IP版本不兼容、网络中断、两端本地链路出现问题等原因，某些对可能根本无法工作，这一事实限制了决策。
MOBIKE solves this problem by taking a simple approach: the party that initiated the IKE_SA (the "client" in a remote access VPN scenario) is responsible for deciding which address pair is used for the IPsec SAs and for collecting the information it needs to make this decision (such as determining which address pairs work or do not work). The other party (the "gateway" in a remote access VPN scenario) simply tells the initiator what addresses it has, but does not update the IPsec SAs until it receives a message from the initiator to do so. This approach applies to the addresses in the IPsec SAs; in the IKE_SA case, the exchange initiator can decide which addresses are used.
MOBIKE通过采取一种简单的方法解决了这个问题：发起IKE_SA（远程访问VPN场景中的“客户端”）的一方负责决定哪个地址对用于IPsec SAs，并负责收集做出此决定所需的信息（例如确定哪个地址对工作或不工作）。另一方（远程访问VPN场景中的“网关”）只是告诉发起方它拥有什么地址，但在收到来自发起方的消息之前不会更新IPsec SAs。此方法适用于IPsec SAs中的地址；在IKE_SA情况下，exchange启动器可以决定使用哪些地址。
Making the decision at the initiator is consistent with how normal IKEv2 works: the initiator decides which addresses it uses when contacting the responder. It also makes sense, especially when the initiator is a mobile node: it is in a better position to decide which of its network interfaces should be used for both upstream and downstream traffic.
在发起者处做出的决定与正常的IKEv2工作方式一致：发起者在联系响应者时决定使用哪个地址。这也是有意义的，特别是当发起方是移动节点时：它处于更好的位置来决定其网络接口中的哪些应用于上游和下游流量。
The details of exactly how the initiator makes the decision, what information is used in making it, how the information is collected, how preferences affect the decision, and when a decision needs to be changed are largely beyond the scope of MOBIKE. This does not mean that these details are unimportant: on the contrary, they are likely to be crucial in any real system. However, MOBIKE is concerned with these details only to the extent that they are visible in IKEv2/IPsec messages exchanged between the peers (and thus need to be standardized to ensure interoperability).
发起人如何做出决策、决策过程中使用了哪些信息、如何收集信息、偏好如何影响决策以及何时需要更改决策等细节在很大程度上超出了MOBIKE的范围。这并不意味着这些细节不重要：相反，它们可能在任何实际系统中都是至关重要的。然而，MOBIKE只关心这些细节，因为它们在对等方之间交换的IKEv2/IPsec消息中可见（因此需要标准化以确保互操作性）。
Many of these issues are not specific to MOBIKE, but are common with the use of existing hosts in dynamic environments or with mobility protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms already exist or are being developed to deal with these issues. For instance, link-layer and IP-layer mechanisms can be used to track the status of connectivity within the local link [RFC2461]; movement detection is being specified for both IPv4 and IPv6 in [DNA4], [DNA6], and so on.
其中许多问题并非特定于MOBIKE，但在动态环境中使用现有主机或使用移动IP[MIP4][MIP6]等移动协议时很常见。已经存在或正在发展一些机制来处理这些问题。例如，链路层和IP层机制可用于跟踪本地链路内的连接状态[RFC2461]；正在[DNA4]、[DNA6]等中为IPv4和IPv6指定移动检测。
Naturally, updating the addresses of IPsec SAs has to take into account several security considerations. MOBIKE includes two features designed to address these considerations. First, a "return routability" check can be used to verify the addresses provided by the peer. This makes it more difficult to flood third parties with large amounts of traffic. Second, a "NAT prohibition" feature ensures that IP addresses have not been modified by NATs, IPv4/IPv6 translation agents, or other similar devices. This feature is enabled only when NAT Traversal is not used.
当然，更新IPsec SAs的地址必须考虑几个安全因素。MOBIKE包括两个旨在解决这些问题的功能。首先，“返回可路由性”检查可用于验证对等方提供的地址。这使得向第三方大量发送流量变得更加困难。其次，“NAT禁止”功能可确保IP地址未被NAT、IPv4/IPv6转换代理或其他类似设备修改。此功能仅在未使用NAT遍历时启用。
A simple MOBIKE exchange in a mobile scenario is illustrated below. The notation is based on [IKEv2], Section 1.2. In addition, the source/destination IP addresses and ports are shown for each packet: here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by the initiator and the responder.
移动场景中的简单MOBIKE交换如下所示。该符号基于[IKEv2]第1.2节。此外，还显示了每个数据包的源/目标IP地址和端口：此处IP_I1、IP_I2、IP_R1和IP_R2表示发起方和响应方使用的IP地址。
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
<-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
<-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
(Initiator gets information from lower layers that its attachment point and address have changed.)
（启动器从较低层获取其连接点和地址已更改的信息。）
3) (IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
3) (IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
<-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
(Responder verifies that the initiator has given it a correct IP address.)
（响应程序验证启动器是否为其提供了正确的IP地址。）
4) <-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(COOKIE2) }
4) <-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(COOKIE2) }
(IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(COOKIE2) } -->
(IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(COOKIE2) } -->
Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform each other that they support MOBIKE. In step 3, the initiator notices a change in its own address, and informs the responder about
步骤1是正常的IKE_INIT交换。在步骤2中，对等方相互告知他们支持MOBIKE。在步骤3中，发起者注意到自己的地址发生了变化，并通知响应者
this by sending an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification. The request is sent using the new IP address. At this point, it also starts to use the new address as a source address in its own outgoing ESP traffic. Upon receiving the UPDATE_SA_ADDRESSES notification, the responder records the new address and, if it is required by policy, performs a return routability check of the address. When this check (step 4) completes, the responder starts to use the new address as the destination for its outgoing ESP traffic.
这是通过发送包含更新地址通知的信息请求实现的。使用新的IP地址发送请求。在这一点上，它也开始在自己的传出ESP通信中使用新地址作为源地址。在收到更新地址通知后，响应者记录新地址，如果策略要求，则对地址执行返回可路由性检查。当该检查（步骤4）完成时，响应者开始使用新地址作为其传出ESP通信的目的地。
Another protocol run in a multihoming scenario is illustrated below. In this scenario, the initiator has one address but the responder has two.
在多主场景中运行的另一个协议如下所示。在这种情况下，发起方有一个地址，而响应方有两个地址。
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
<-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED),
N(ADDITIONAL_IP4_ADDRESS) }
<-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED),
N(ADDITIONAL_IP4_ADDRESS) }
(The initiator suspects a problem in the currently used address pair and probes its liveness.)
（启动器怀疑当前使用的地址对中存在问题，并探测其活动性。）
3) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
3) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
(IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
(IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
...
...
(Eventually, the initiator gives up on the current address pair and tests the other available address pair.)
（最终，启动器放弃当前地址对，并测试其他可用地址对。）
4) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
4) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
(This worked, and the initiator requests the peer to switch to new addresses.)
（这起作用了，发起方请求对等方切换到新地址。）
5) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) } -->
5) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) } -->
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) }
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) }
In some MOBIKE scenarios, the network may contain NATs or stateful packet filters (for brevity, the rest of this document simply describes NATs). The NAT Traversal feature specified in [IKEv2] allows IKEv2 to work through NATs in many cases, and MOBIKE can leverage this functionality: when the addresses used for IPsec SAs are changed, MOBIKE can enable or disable IKEv2 NAT Traversal, as needed.
在某些MOBIKE场景中，网络可能包含NAT或有状态数据包过滤器（为简洁起见，本文档的其余部分仅描述NAT）。[IKEv2]中指定的NAT遍历功能允许IKEv2在许多情况下通过NAT工作，MOBIKE可以利用此功能：当用于IPsec SAs的地址发生更改时，MOBIKE可以根据需要启用或禁用IKEv2 NAT遍历。
Nevertheless, there are some limitations because NATs usually introduce an asymmetry into the network: only packets coming from the "inside" cause state to be created. This asymmetry leads to
然而，由于NAT通常会在网络中引入不对称性，因此存在一些限制：只有来自“内部”的数据包才会导致创建状态。这种不对称导致
restrictions on what MOBIKE can do. To give a concrete example, consider a situation where both peers have only a single address, and the initiator is behind a NAT. If the responder's address now changes, it needs to send a packet to the initiator using its new address. However, if the NAT is, for instance, of the common "restricted cone" type (see [STUN] for one description of different NAT types), this is not possible. The NAT will drop packets sent from the new address (unless the initiator has previously sent a packet to that address -- which it cannot do until it knows the address).
对MOBIKE可以做什么的限制。为了给出一个具体的例子，考虑一个情况，其中两个对等点只有一个地址，而发起方位于NAT后面。如果响应者的地址现在发生更改，则需要使用其新地址向启动器发送数据包。然而，例如，如果NAT属于常见的“受限圆锥”类型（参见[STUN]了解不同NAT类型的一种描述），则这是不可能的。NAT将丢弃从新地址发送的数据包（除非发起方之前已将数据包发送到该地址——在知道该地址之前无法执行此操作）。
For simplicity, MOBIKE does not attempt to handle all possible NAT-related scenarios. Instead, MOBIKE assumes that if NATs are present, the initiator is the party "behind" the NAT, and the case where the responder's addresses change is not fully supported (meaning that no special effort is made to support this functionality). Responders may also be unaware of NATs or specific types of NATs they are behind. However, when a change has occurred that will cause a loss of connectivity, MOBIKE responders will still attempt to inform the initiator of the change. Depending on, for instance, the exact type of NAT, it may or may not succeed. However, analyzing the exact circumstances when this will or will not work is not done in this document.
为简单起见，MOBIKE不会尝试处理所有可能的NAT相关场景。相反，MOBIKE假设如果存在NAT，则发起方是NAT的“幕后”方，并且不完全支持响应方地址更改的情况（这意味着不需要特别努力来支持此功能）。响应者也可能不知道NAT或他们背后的特定类型的NAT。但是，当发生将导致连接丢失的更改时，MOBIKE响应者仍将尝试通知发起人该更改。例如，取决于NAT的确切类型，它可能会成功，也可能不会成功。但是，本文件中没有分析这将起作用或不起作用的确切情况。
The initiator is responsible for finding a working pair of addresses so that the initial IKE exchange can be carried out. Any information from MOBIKE extensions will only be available later, when the exchange has progressed far enough. Exactly how the addresses used for the initial exchange are discovered is beyond the scope of this specification; typical sources of information include local configuration and DNS.
发起者负责寻找一对工作地址，以便执行初始IKE交换。来自MOBIKE扩展的任何信息只有在交换进展足够快的时候才可用。用于初始交换的地址的发现方式超出了本规范的范围；典型的信息源包括本地配置和DNS。
If either or both of the peers have multiple addresses, some combinations may not work. Thus, the initiator SHOULD try various source and destination address combinations when retransmitting the IKE_SA_INIT request.
如果其中一个或两个对等点具有多个地址，则某些组合可能不起作用。因此，在重新传输IKE_SA_INIT请求时，启动器应尝试各种源地址和目标地址组合。
Implementations that wish to use MOBIKE for a particular IKE_SA MUST include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the message containing the SA payload).
希望为特定IKE_SA使用MOBIKE的实现必须在IKE_身份验证交换中包含支持MOBIKE_的通知（在多个IKE_身份验证交换的情况下，在包含SA有效负载的消息中）。
The format of the MOBIKE_SUPPORTED notification is described in Section 4.
第4节描述了MOBIKE_支持的通知的格式。
When an IPsec SA is created, the tunnel header IP addresses (and port, if doing UDP encapsulation) are taken from the IKE_SA, not the IP header of the IKEv2 message requesting the IPsec SA. The addresses in the IKE_SA are initialized from the IP header of the first IKE_AUTH request.
创建IPsec SA时，隧道头IP地址（和端口，如果进行UDP封装）取自IKE_SA，而不是请求IPsec SA的IKEv2消息的IP头。IKE_SA中的地址从第一个IKE_身份验证请求的IP头初始化。
The addresses are taken from the IKE_AUTH request because IKEv2 requires changing from port 500 to 4500 if a NAT is discovered. To simplify things, implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them (this way, there is no need to change the ports later if a NAT is detected on some other path).
地址取自IKE_AUTH请求，因为如果发现NAT，IKEv2需要将端口500更改为4500。为了简化工作，如果通信方同时支持这两种规范和NAT遍历，则支持这两种规范和NAT遍历的实现必须更改为端口4500，即使它们之间未检测到NAT（这样，如果在其他路径上检测到NAT，则以后无需更改端口）。
Both the initiator and responder MAY include one or more ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the message containing the SA payload). Here "ADDITIONAL_*_ADDRESS" means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS notification.
发起方和响应方都可以在IKE_AUTH交换中包括一个或多个附加的_IP4_地址和/或附加的_IP6_地址通知（在多个IKE_AUTH交换的情况下，在包含SA有效载荷的消息中）。此处“附加IP地址”指附加IP 4地址或附加IP 6地址通知。
Initiator Responder
----------- -----------
HDR, SK { IDi, [CERT], [IDr], AUTH,
[CP(CFG_REQUEST)]
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_*_ADDRESS)+] } -->
Initiator Responder
----------- -----------
HDR, SK { IDi, [CERT], [IDr], AUTH,
[CP(CFG_REQUEST)]
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_*_ADDRESS)+] } -->
<-- HDR, SK { IDr, [CERT], AUTH,
[CP(CFG_REPLY)],
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED)
[N(ADDITIONAL_*_ADDRESS)+] }
<-- HDR, SK { IDr, [CERT], AUTH,
[CP(CFG_REPLY)],
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED)
[N(ADDITIONAL_*_ADDRESS)+] }
The recipient stores this information, but no other action is taken at this time.
收件人存储此信息，但此时不执行其他操作。
Although both the initiator and responder maintain a set of peer addresses (logically associated with the IKE_SA), it is important to note that they use this information for slightly different purposes.
尽管发起方和响应方都维护一组对等地址（逻辑上与IKE_SA关联），但需要注意的是，它们使用此信息的目的略有不同。
The initiator uses the set of responder addresses as an input to its address selection policy; it may, at some later point, decide to move the IPsec traffic to one of these addresses using the procedure described in Section 3.5. The responder normally does not use the set of initiator addresses for anything: the addresses are used only when the responder's own addresses change (see Section 3.6).
发起方使用响应方地址集作为其地址选择策略的输入；在以后的某个时候，它可能会决定使用第3.5节中描述的过程将IPsec通信量移动到这些地址之一。响应者通常不使用启动器地址集进行任何操作：仅当响应者自己的地址发生变化时才使用这些地址（参见第3.6节）。
The set of addresses available to the peers can change during the lifetime of the IKE_SA. The procedure for updating this information is described in Section 3.6.
对等方可用的地址集可以在IKE_SA的生存期内更改。第3.6节描述了更新该信息的程序。
Note that if some of the initiator's interfaces are behind a NAT (from the responder's point of view), the addresses received by the responder will be incorrect. This means the procedure for changing responder addresses described in Section 3.6 does not fully work when the initiator is behind a NAT. For the same reason, the peers also SHOULD NOT use this information for any other purpose than what is explicitly described either in this document or a future specification updating it.
请注意，如果某些启动器接口位于NAT后面（从响应者的角度来看），则响应者接收到的地址将不正确。这意味着，当启动器位于NAT后面时，第3.6节中描述的更改响应程序地址的程序无法完全工作。出于同样的原因，对等方也不应将此信息用于本文件或未来更新规范中明确描述的目的以外的任何其他目的。
In MOBIKE, the initiator decides what addresses are used in the IPsec SAs. That is, the responder does not normally update any IPsec SAs without receiving an explicit UPDATE_SA_ADDRESSES request from the initiator. (As described below, the responder can, however, update the IKE_SA in some circumstances.)
在MOBIKE中，启动器决定IPsec SAs中使用的地址。也就是说，响应程序通常不会在未收到来自发起程序的显式更新地址请求的情况下更新任何IPsec SA。（如下所述，但是，响应者可以在某些情况下更新IKE_SA。）
The reasons why the initiator wishes to change the addresses are largely beyond the scope of MOBIKE. Typically, triggers include information received from lower layers, such as changes in IP addresses or link-down indications. Some of this information can be unreliable: for instance, ICMP messages could be spoofed by an attacker. Unreliable information SHOULD be treated only as a hint that there might be a problem, and the initiator SHOULD trigger Dead Peer Detection (that is, send an INFORMATIONAL request) to determine if the current path is still usable.
发起者希望更改地址的原因在很大程度上超出了MOBIKE的范围。通常，触发器包括从较低层接收到的信息，例如IP地址的更改或链路断开指示。其中一些信息可能不可靠：例如，ICMP消息可能被攻击者欺骗。不可靠的信息只应被视为可能存在问题的提示，发起方应触发死点检测（即，发送信息请求），以确定当前路径是否仍然可用。
Changing addresses can also be triggered by events within IKEv2. At least the following events can cause the initiator to re-evaluate its local address selection policy, possibly leading to changing the addresses.
IKEv2内的事件也会触发地址更改。至少以下事件会导致启动器重新评估其本地地址选择策略，可能导致地址更改。
o An IKEv2 request has been re-transmitted several times, but no valid reply has been received. This suggests the current path is no longer working.
o IKEv2请求已多次重新传输，但未收到有效回复。这表明当前路径不再有效。
o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is received. This means the peer's addresses may have changed. This is particularly important if the announced set of addresses no longer contains the currently used address.
o 接收到一个包含附加_IP4_地址、附加_IP6_地址或无附加_地址通知的信息请求。这意味着对等方的地址可能已更改。如果公布的地址集不再包含当前使用的地址，这一点尤为重要。
o An UNACCEPTABLE_ADDRESSES notification is received as a response to address update request (described below).
o 接收到不可接受的_地址通知，作为对地址更新请求的响应（如下所述）。
o The initiator receives a NAT_DETECTION_DESTINATION_IP notification that does not match the previous UPDATE_SA_ADDRESSES response (see Section 3.8 for a more detailed description).
o 启动器接收到与先前更新地址响应不匹配的NAT_检测_目的地_IP通知（有关更详细的说明，请参阅第3.8节）。
The description in the rest of this section assumes that the initiator has already decided what the new addresses should be. When this decision has been made, the initiator:
本节其余部分中的描述假设启动器已经决定了新地址应该是什么。做出此决定后，发起人：
o Updates the IKE_SA with the new addresses, and sets the "pending_update" flag in the IKE_SA.
o 使用新地址更新IKE_SA，并在IKE_SA中设置“挂起_更新”标志。
o Updates the IPsec SAs associated with this IKE_SA with the new addresses (unless the initiator's policy requires a return routability check before updating the IPsec SAs, and the check has not been done for this responder address yet).
o 使用新地址更新与此IKE_SA关联的IPsec SA（除非启动器的策略要求在更新IPsec SA之前进行返回路由性检查，并且尚未对此响应程序地址进行检查）。
o If the IPsec SAs were updated in the previous step: If NAT Traversal is not enabled, and the responder supports NAT Traversal (as indicated by NAT detection payloads in the IKE_SA_INIT exchange), and the initiator either suspects or knows that a NAT is likely to be present, enables NAT Traversal (that is, enables UDP encapsulation of outgoing ESP packets and sending of NAT-Keepalive packets).
o 如果在上一步中更新了IPsec SAs：如果未启用NAT遍历，并且响应程序支持NAT遍历（如IKE_SA_INIT exchange中的NAT检测有效负载所示），并且启动器怀疑或知道可能存在NAT，则启用NAT遍历（即，启用传出ESP数据包的UDP封装和NAT Keepalive数据包的发送）。
o If there are outstanding IKEv2 requests (requests for which the initiator has not yet received a reply), continues retransmitting them using the addresses in the IKE_SA (the new addresses).
o 如果存在未完成的IKEv2请求（发起方尚未收到回复的请求），则继续使用IKE_SA中的地址（新地址）重新传输这些请求。
o When the window size allows, sends an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification (which does not contain any data), and clears the "pending_update" flag. The request will be as follows:
o 当窗口大小允许时，发送包含更新地址通知（不包含任何数据）的信息性请求，并清除“挂起更新”标志。请求如下：
Initiator Responder
----------- -----------
HDR, SK { N(UPDATE_SA_ADDRESSES),
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
Initiator Responder
----------- -----------
HDR, SK { N(UPDATE_SA_ADDRESSES),
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
o If a new address change occurs while waiting for the response, starts again from the first step (and ignores responses to this UPDATE_SA_ADDRESSES request).
o 如果在等待响应时发生新地址更改，则从第一步开始重新开始（并忽略对此更新地址请求的响应）。
When processing an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification, the responder:
处理包含更新地址通知的信息性请求时，响应者：
o Determines whether it has already received a newer UPDATE_SA_ADDRESSES request than this one (if the responder uses a window size greater than one, it is possible that requests are received out of order). If it has, a normal response message (described below) is sent, but no other action is taken.
o 确定是否已接收到比此更新地址更新的更新地址请求（如果响应者使用的窗口大小大于1，则可能是收到的请求顺序错误）。如果有，则发送正常响应消息（如下所述），但不执行其他操作。
o If the NO_NATS_ALLOWED notification is present, processes it as described in Section 3.9.
o 如果存在不允许通知，则按照第3.9节所述进行处理。
o Checks that the (source IP address, destination IP address) pair in the IP header is acceptable according to local policy. If it is not, replies with a message containing the UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2).
o 根据本地策略检查IP报头中的（源IP地址、目标IP地址）对是否可接受。如果不是，则回复一条包含不可接受的_地址通知（可能还有COOKIE2）的消息。
o Updates the IP addresses in the IKE_SA with the values from the IP header. (Using the address from the IP header is consistent with normal IKEv2, and allows IKEv2 to work with NATs without needing unilateral self-address fixing [UNSAF].)
o 使用IP头中的值更新IKE_SA中的IP地址。（使用来自IP报头的地址与正常的IKEv2一致，并允许IKEv2与NAT一起工作，而无需单边自地址修复[UNSAF]。）
o Replies with an INFORMATIONAL response:
o 回复信息性回复：
Initiator Responder
----------- -----------
<-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(COOKIE2)] }
Initiator Responder
----------- -----------
<-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[N(COOKIE2)] }
o If necessary, initiates a return routability check for the new initiator address (see Section 3.7) and waits until the check is completed.
o 如有必要，启动新启动器地址的返回可路由性检查（见第3.7节），并等待检查完成。
o Updates the IPsec SAs associated with this IKE_SA with the new addresses.
o 使用新地址更新与此IKE_SA关联的IPsec SA。
o If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal.
o 如果支持NAT遍历并且包含NAT检测有效负载，则启用或禁用NAT遍历。
When the initiator receives the reply:
发起者收到回复时：
o If an address change has occurred after the request was first sent, no MOBIKE processing is done for the reply message because a new UPDATE_SA_ADDRESSES is going to be sent (or has already been sent, if window size greater than one is in use).
o 如果在第一次发送请求后发生地址更改，则不会对回复消息执行MOBIKE处理，因为将要发送新的更新地址（如果使用的窗口大小大于1，则已发送）。
o If the response contains the UNEXPECTED_NAT_DETECTED notification, the initiator processes the response as described in Section 3.9.
o 如果响应包含意外的通知，则启动器将按照第3.9节所述处理响应。
o If the response contains an UNACCEPTABLE_ADDRESSES notification, the initiator MAY select another addresses and retry the exchange, keep on using the previously used addresses, or disconnect.
o 如果响应包含不可接受的_地址通知，则发起方可以选择其他地址并重试交换，继续使用以前使用的地址，或断开连接。
o It updates the IPsec SAs associated with this IKE_SA with the new addresses (unless this was already done earlier before sending the request; this is the case when no return routability check was required).
o 它使用新地址更新与此IKE_SA关联的IPsec SA（除非在发送请求之前已完成此操作；在不需要返回可路由性检查的情况下）。
o If NAT Traversal is supported and NAT detection payloads were included, the initiator enables or disables NAT Traversal.
o 如果支持NAT遍历并且包含NAT检测有效负载，则启动器将启用或禁用NAT遍历。
There is one exception to the rule that the responder never updates any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If the source address that the responder is currently using becomes unavailable (i.e., sending packets using that source address is no longer possible), the responder is allowed to update the IPsec SAs to use some other address (in addition to initiating the procedure described in the next section).
该规则有一个例外，即响应程序在未收到更新地址请求的情况下从不更新任何IPsec SA。如果响应者当前使用的源地址变得不可用（即，不再可能使用该源地址发送数据包），则允许响应者更新IPsec SAs以使用其他地址（除了启动下一节中描述的过程）。
As described in Section 3.4, both the initiator and responder can send a list of additional addresses in the IKE_AUTH exchange. This information can be updated by sending an INFORMATIONAL exchange request message that contains either one or more ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification.
如第3.4节所述，发起方和响应方都可以在IKE_身份验证交换中发送附加地址列表。可以通过发送包含一个或多个附加_IP4_地址/附加_IP6_地址通知或无附加_地址通知的信息交换请求消息来更新此信息。
If the exchange initiator has only a single IP address, it is placed in the IP header, and the message contains the NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has several addresses, one of them is placed in the IP header, and the rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications.
如果exchange启动器只有一个IP地址，则会将其放置在IP标头中，并且消息包含“无其他IP地址”通知。如果exchange启动器有多个地址，则其中一个地址将放在IP头中，其余地址将放在附加_IP4_地址/附加_IP6_地址通知中。
The new list of addresses replaces the old information (in other words, there are no separate add/delete operations; instead, the complete list is sent every time these notifications are used).
新的地址列表将替换旧信息（换句话说，没有单独的添加/删除操作；相反，每次使用这些通知时都会发送完整的列表）。
The message exchange will look as follows:
消息交换将如下所示：
Initiator Responder
----------- -----------
HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
[N(NO_ADDITIONAL_ADDRESSES)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
Initiator Responder
----------- -----------
HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
[N(NO_ADDITIONAL_ADDRESSES)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->
<-- HDR, SK { [N(COOKIE2)] }
<-- HDR, SK { [N(COOKIE2)] }
When a request containing an ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is received, the exchange responder:
当收到包含附加_IP4_地址、附加_IP6_地址或无附加_地址通知的请求时，exchange响应者：
o Determines whether it has already received a newer request to update the addresses (if a window size greater than one is used, it is possible that the requests are received out of order). If it has, a response message is sent, but the address set is not updated.
o 确定是否已收到更新地址的较新请求（如果使用大于1的窗口大小，则可能是收到的请求顺序不正确）。如果有，则发送响应消息，但不更新地址集。
o If the NO_NATS_ALLOWED notification is present, processes it as described in Section 3.9.
o 如果存在不允许通知，则按照第3.9节所述进行处理。
o Updates the set of peer addresses based on the IP header and the ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, and NO_ADDITIONAL_ADDRESSES notifications.
o 根据IP头和附加的_IP4_地址、附加的_IP6_地址和无附加的_地址通知更新对等地址集。
o Sends a response.
o 发送响应。
The initiator MAY include these notifications in the same request as UPDATE_SA_ADDRESSES.
发起者可以将这些通知包括在与更新地址相同的请求中。
If the request to update the addresses is retransmitted using several different source addresses, a new INFORMATIONAL request MUST be sent.
如果使用多个不同的源地址重新传输更新地址的请求，则必须发送新的信息请求。
There is one additional complication: when the responder wants to update the address set, the currently used addresses may no longer work. In this case, the responder uses the additional address list received from the initiator, and the list of its own addresses, to determine which addresses to use for sending the INFORMATIONAL request. This is the only time the responder uses the additional address list received from the initiator.
还有一个额外的复杂性：当响应者想要更新地址集时，当前使用的地址可能不再工作。在这种情况下，响应者使用从发起方接收的附加地址列表及其自己的地址列表来确定用于发送信息请求的地址。这是响应者唯一一次使用从启动器收到的附加地址列表。
Note that both peers can have their own policies about what addresses are acceptable to use, and certain types of policies may simplify implementation. For instance, if the responder has a single fixed address, it does not need to process the ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring unrecognized status notifications, as already required in [IKEv2]). Furthermore, if the initiator has a policy saying that only the responder address specified in local configuration is acceptable, it does not have to send its own additional addresses to the responder (since the responder does not need them except when changing its own address).
请注意，两个对等方都可以有自己的策略来确定哪些地址是可接受的，并且某些类型的策略可以简化实现。例如，如果响应者有一个固定地址，它不需要处理它收到的额外的_-IP4_地址和额外的_-IP6_地址通知（除了忽略未识别的状态通知，如[IKEv2]中所要求的那样）。此外，如果启动器有一个策略，说明只有在本地配置中指定的响应程序地址是可接受的，则它不必向响应程序发送自己的附加地址（因为响应程序不需要这些地址，除非更改自己的地址）。
Both parties can optionally verify that the other party can actually receive packets at the claimed address. By default, this "return routability check" SHOULD be performed. In environments where the peer is expected to be well-behaved (many corporate VPNs, for instance), or the address can be verified by some other means (e.g., a certificate issued by an authority trusted for this purpose), the return routability check MAY be omitted.
双方都可以选择验证另一方是否可以在声明的地址实际接收数据包。默认情况下，应执行此“返回可路由性检查”。在期望对等方表现良好的环境中（例如，许多公司VPN），或者可以通过其他方式验证地址（例如，由为此目的受信任的机构颁发的证书），可以省略返回路由性检查。
The check can be done before updating the IPsec SAs, immediately after updating them, or continuously during the connection. By default, the return routability check SHOULD be done before updating the IPsec SAs, but in some environments it MAY be postponed until after the IPsec SAs have been updated.
可以在更新IPsec SAs之前、更新后立即或在连接过程中连续执行检查。默认情况下，应在更新IPsec SAs之前进行返回路由性检查，但在某些环境中，返回路由性检查可能会推迟到更新IPsec SAs之后。
Any INFORMATIONAL exchange can be used for return routability purposes, with one exception (described later in this section): when a valid response is received, we know the other party can receive packets at the claimed address.
任何信息交换都可以用于返回可路由性目的，但有一个例外（本节后面将介绍）：当收到有效响应时，我们知道另一方可以在声明的地址接收数据包。
To ensure that the peer cannot generate the correct INFORMATIONAL response without seeing the request, a new payload is added to INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY include a COOKIE2 notification, and if included, the recipient of an INFORMATIONAL request MUST copy the notification as-is to the response. When processing the response, the original sender MUST verify that the value is the same one as sent. If the values do not match, the IKE_SA MUST be closed. (See also Section 4.2.5 for the format of the COOKIE2 notification.)
为了确保对等方在没有看到请求的情况下无法生成正确的信息性响应，将向信息性消息添加一个新的有效负载。信息请求的发送者可能包含COOKIE2通知，如果包含，信息请求的接收者必须将通知原样复制到响应中。处理响应时，原始发件人必须验证该值是否与发送的值相同。如果值不匹配，则必须关闭。（COOKIE2通知的格式另见第4.2.5节。）
The exception mentioned earlier is as follows: If the same INFORMATIONAL request has been sent to several different addresses (i.e., the destination address in the IKE_SA has been updated after the request was first sent), receiving the INFORMATIONAL response does not tell which address is the working one. In this case, a new INFORMATIONAL request needs to be sent to check return routability.
前面提到的例外情况如下：如果相同的信息性请求已发送到多个不同的地址（即，IKE_SA中的目标地址在第一次发送请求后已更新），则接收信息性响应不会告诉哪个地址是工作地址。在这种情况下，需要发送一个新的信息请求来检查返回的可路由性。
IKEv2 performs Dead Peer Detection (DPD) if there has recently been only outgoing traffic on all of the SAs associated with the IKE_SA.
如果与IKE_SA关联的所有SA上最近只有传出流量，IKEv2将执行死点检测（DPD）。
In MOBIKE, these messages can also be used to detect if NAT mappings have changed (for example, if the keepalive interval is too long, or the NAT box is rebooted). More specifically, if both peers support both this specification and NAT Traversal, the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications MAY be included in any INFORMATIONAL request; if the request includes them, the responder MUST also include them in the response (but no other action is taken, unless otherwise specified).
在MOBIKE中，这些消息还可用于检测NAT映射是否已更改（例如，如果keepalive间隔太长，或者NAT盒已重新启动）。更具体地说，如果两个对等方都支持此规范和NAT遍历，则NAT_检测_源_IP和NAT_检测_目的地_IP通知可以包括在任何信息请求中；如果请求包含它们，响应者还必须在响应中包含它们（但除非另有规定，否则不会采取其他操作）。
When the initiator is behind a NAT (as detected earlier using the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications), it SHOULD include these notifications in DPD messages and compare the received NAT_DETECTION_DESTINATION_IP notifications with the value from the previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response). If the values do not match, the IP address and/or port seen by the responder has changed, and the initiator SHOULD send UPDATE_SA_ADDRESSES as described in Section 3.5. If the initiator suspects that the NAT mapping has changed, it MAY also skip the detection step and send UPDATE_SA_ADDRESSES immediately. This saves one roundtrip if the NAT mapping has indeed changed.
当启动器位于NAT后面时（如前面使用NAT_检测_源_IP和NAT_检测_目的地_IP通知检测到的），它应将这些通知包含在DPD消息中，并将接收到的NAT_检测_目的地_IP通知与先前更新_SA_地址响应的值进行比较（或IKE_SA_INIT响应）。如果值不匹配，则响应程序看到的IP地址和/或端口已更改，并且启动器应按照第3.5节中的说明发送更新地址。如果启动器怀疑NAT映射已更改，则还可以跳过检测步骤并立即发送更新地址。如果NAT映射这确实改变了。
Note that this approach to detecting NAT mapping changes may cause an extra address update when the IKE_SA is rekeyed. This is because the NAT_DETECTION_DESTINATION_IP hash also includes the IKE Security Parameter Indexes (SPIs), which change when performing rekeying. This unnecessary update is harmless, however.
请注意，这种检测NAT映射更改的方法可能会在IKE_SA重新设置密钥时导致额外的地址更新。这是因为NAT_DETECTION_DESTINATION_IP散列还包括IKE安全参数索引（spi），它们在执行密钥更新时会改变。然而，这种不必要的更新是无害的。
When MOBIKE is in use, the dynamic updates (specified in [IKEv2], Section 2.23), where the peer address and port are updated from the last valid authenticated packet, work in a slightly different fashion. The host not behind a NAT MUST NOT use these dynamic updates for IKEv2 packets, but MAY use them for ESP packets. This ensures that an INFORMATIONAL exchange that does not contain UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be used for, e.g., testing whether a particular path works.
当使用MOBIKE时，动态更新（在[IKEv2]第2.23节中指定），其中对等地址和端口从最后一个有效的经过身份验证的数据包更新，其工作方式略有不同。不支持NAT的主机不得将这些动态更新用于IKEv2数据包，但可以将其用于ESP数据包。这可确保不包含更新地址的信息交换不会导致任何更改，从而允许将其用于（例如）测试特定路径是否工作。
Basic IKEv2/IPsec without NAT Traversal support may work across some types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in tunnel mode. This is because the IKEv2 integrity checksum does not cover the addresses in the IP header. This may be considered a problem in some circumstances, because in some sense any modification of the IP addresses can be considered an attack.
不支持NAT遍历的基本IKEv2/IPsec可以在隧道模式下跨某些类型的一对一“基本”NAT和IPv4/IPv6转换代理工作。这是因为IKEv2完整性校验和没有覆盖IP报头中的地址。在某些情况下，这可能被视为一个问题，因为在某种意义上，对IP地址的任何修改都可以被视为攻击。
This specification addresses the issue by protecting the IP addresses when NAT Traversal has not been explicitly enabled. This means that MOBIKE without NAT Traversal support will not work if the paths contain NATs, IPv4/IPv6 translation agents, or other nodes that modify the addresses in the IP header. This feature is mainly intended for IPv6 and site-to-site VPN cases, where the administrators may know beforehand that NATs are not present, and thus any modification to the packet can be considered an attack.
本规范通过在NAT遍历未显式启用时保护IP地址来解决此问题。这意味着，如果路径包含NAT、IPv4/IPv6转换代理或修改IP报头中地址的其他节点，则不支持NAT遍历的MOBIKE将无法工作。此功能主要用于IPv6和站点到站点VPN情况，其中管理员可能事先知道NAT不存在，因此对数据包的任何修改都可能被视为攻击。
More specifically, when NAT Traversal is not enabled, all messages that can update the addresses associated with the IKE_SA and/or IPsec SAs (the first IKE_AUTH request and all INFORMATIONAL requests that contain any of the following notifications: UPDATE_SA_ADDRESSES, ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED notification. The exchange responder MUST verify that the contents of the NO_NATS_ALLOWED notification match the addresses in the IP header. If they do not match, a response containing an UNEXPECTED_NAT_DETECTED notification is sent. The response message is sent to the address and port that the corresponding request came from, not to the address contained in the NO_NATS_ALLOWED notification.
更具体地说，当未启用NAT遍历时，可以更新与IKE_SA和/或IPsec SA关联的地址的所有消息（第一个IKE_认证请求和包含以下任何通知的所有信息请求：更新_SA_地址、附加_IP4_地址、附加_IP6_地址、无附加_地址）还必须包括不允许的通知。exchange响应程序必须验证“不允许NATS”通知的内容是否与IP标头中的地址匹配。如果它们不匹配，将发送包含意外的\u NAT \u检测到的通知的响应。响应消息被发送到相应请求来自的地址和端口，而不是发送到NO_NATS_ALLOWED通知中包含的地址。
If the exchange initiator receives an UNEXPECTED_NAT_DETECTED notification in response to its INFORMATIONAL request, it SHOULD retry the operation several times using new INFORMATIONAL requests. Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several times, starting from a new IKE_SA_INIT request. This ensures that an attacker who is able to modify only a single packet does not unnecessarily cause a path to remain unused. The exact number of retries is not specified in this document because it does not affect interoperability. However, because the IKE message will also be rejected if the attacker modifies the integrity checksum field, a reasonable number here would be the number of retries that is being used for normal retransmissions.
如果exchange启动器收到响应其信息请求的意外通知，则应使用新的信息请求重试该操作数次。类似地，如果启动器接收到在IKE_身份验证交换中检测到的意外的IKE_NAT_，它应该从新的IKE_SA_INIT请求开始重试IKE_SA建立几次。这可确保仅能修改单个数据包的攻击者不会不必要地导致路径保持未使用状态。由于不影响互操作性，因此本文档中未指定重试的确切次数。但是，由于如果攻击者修改完整性校验和字段，IKE消息也将被拒绝，因此此处的合理数字将是用于正常重传的重试次数。
If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange responder MUST NOT use the contents of the NO_NATS_ALLOWED notification for any other purpose than possibly logging the information for troubleshooting purposes.
如果发送了意外的\u-NAT\u-DETECTED通知，则exchange响应程序不得将不允许通知的内容用于任何其他目的，除非可能记录信息以进行故障排除。
IKEv2 Dead Peer Detection allows the peers to detect if the currently used path has stopped working. However, if either of the peers has several addresses, Dead Peer Detection alone does not tell which of the other paths might work.
IKEv2死节点检测允许节点检测当前使用的路径是否停止工作。然而，若任何一个对等点都有多个地址，则仅死对等点检测无法判断其他路径中的哪一个可能工作。
If required by its address selection policy, the initiator can use normal IKEv2 INFORMATIONAL request/response messages to test whether a certain path works. Implementations MAY do path testing even if the path currently being used is working to, for example, detect when a better (but previously unavailable) path becomes available.
如果其地址选择策略要求，启动器可以使用普通的IKEv2信息性请求/响应消息来测试特定路径是否工作。实现可以进行路径测试，即使当前使用的路径正在工作，例如，检测更好（但以前不可用）的路径何时可用。
In MOBIKE, the initiator is responsible for detecting and recovering from most failures.
在MOBIKE中，启动器负责检测大多数故障并从中恢复。
To give the initiator enough time to detect the error, the responder SHOULD use relatively long timeout intervals when, for instance, retransmitting IKEv2 requests or deciding whether to initiate Dead Peer Detection. While no specific timeout lengths are required, it is suggested that responders continue retransmitting IKEv2 requests for at least five minutes before giving up.
为了给启动器足够的时间来检测错误，响应者应该在重新传输IKEv2请求或决定是否启动死点检测时使用相对较长的超时间隔。虽然不需要特定的超时长度，但建议响应者在放弃之前继续重新传输IKEv2请求至少五分钟。
MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but as addresses may change, it is not sufficient to just verify that the peer is alive, but also that it is synchronized with the address updates and has not, for instance, ignored an address update due to failure to complete return routability test. This means that when there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the addresses used in those packets and determine that they correspond to those that should be employed. If they do not, such packets SHOULD NOT be used as evidence that the peer is able to communicate with this node and or that the peer has received all address updates.
MOBIKE使用与普通IKEv2相同的死点检测方法，但由于地址可能会发生变化，仅验证对等点是否处于活动状态是不够的，还需要验证对等点是否与地址更新同步，并且没有（例如）由于未能完成返回路由性测试而忽略地址更新。这意味着，当有传入的IPsec数据包时，MOBIKE节点应该检查这些数据包中使用的地址，并确定它们与应该使用的地址相对应。如果没有，则不应将此类数据包用作对等方能够与该节点通信或对等方已收到所有地址更新的证据。
This specification defines several new IKEv2 Notify payload types. See [IKEv2], Section 3.10, for a general description of the Notify payload.
本规范定义了几种新的IKEv2 Notify有效负载类型。关于有效载荷的一般说明，参见第2.10节“通知有效载荷”。
The responder can include this notification in an INFORMATIONAL exchange response to indicate that the address change in the corresponding request message (which contained an UPDATE_SA_ADDRESSES notification) was not carried out.
响应者可以在信息交换响应中包含此通知，以指示未执行相应请求消息（其中包含更新地址通知）中的地址更改。
The Notify Message Type for UNACCEPTABLE_ADDRESSES is 40. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type.
不可接受的_地址的通知消息类型为40。协议ID和SPI大小字段设置为零。没有与此通知类型关联的数据。
See Section 3.9 for a description of this notification.
有关本通知的说明，请参见第3.9节。
The Notify Message Type for UNEXPECTED_NAT_DETECTED is 41. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type.
检测到的意外事件的通知消息类型为41。协议ID和SPI大小字段设置为零。没有与此通知类型关联的数据。
The MOBIKE_SUPPORTED notification is included in the IKE_AUTH exchange to indicate that the implementation supports this specification.
IKE_身份验证交换中包含支持MOBIKE_的通知，以指示实现支持此规范。
The Notify Message Type for MOBIKE_SUPPORTED is 16396. The Protocol ID and SPI Size fields are set to zero. The notification data field MUST be left empty (zero-length) when sending, and its contents (if any) MUST be ignored when this notification is received. This allows the field to be used by future versions of this protocol.
支持的MOBIKE_的通知消息类型为16396。协议ID和SPI大小字段设置为零。发送时，通知数据字段必须保留为空（长度为零），收到此通知时，必须忽略其内容（如果有）。这允许此协议的未来版本使用该字段。
4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify Payloads
4.2.2. 附加_IP4_地址和附加_IP6_地址通知有效载荷
Both parties can include ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and INFORMATIONAL exchange request messages; see Section 3.4 and Section 3.6 for more detailed description.
双方可在IKE_认证交换和信息交换请求消息中包含附加_IP4_地址和/或附加_IP6_地址通知；更多详细说明，请参见第3.4节和第3.6节。
The Notify Message Types for ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS are 16397 and 16398, respectively. The Protocol ID and SPI Size fields are set to zero. The data associated with these Notify types is either a four-octet IPv4 address or a 16-octet IPv6 address.
附加_IP4_地址和附加_IP6_地址的通知消息类型分别为16397和16398。协议ID和SPI大小字段设置为零。与这些通知类型关联的数据是四个八位字节的IPv4地址或16个八位字节的IPv6地址。
The NO_ADDITIONAL_ADDRESSES notification can be included in an INFORMATIONAL exchange request message to indicate that the exchange initiator does not have addresses beyond the one used in the exchange (see Section 3.6 for more detailed description).
“无其他地址”通知可以包含在信息性交换请求消息中，以指示交换发起人的地址不超过交换中使用的地址（有关详细说明，请参阅第3.6节）。
The Notify Message Type for NO_ADDITIONAL_ADDRESSES is 16399. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type.
无其他地址的通知消息类型为16399。协议ID和SPI大小字段设置为零。没有与此通知类型关联的数据。
This notification is included in INFORMATIONAL exchange requests sent by the initiator to update addresses of the IKE_SA and IPsec SAs (see Section 3.5).
此通知包含在启动器发送的信息交换请求中，以更新IKE_SA和IPsec SA的地址（请参阅第3.5节）。
The Notify Message Type for UPDATE_SA_ADDRESSES is 16400. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type.
更新地址的通知消息类型为16400。协议ID和SPI大小字段设置为零。没有与此通知类型关联的数据。
This notification MAY be included in any INFORMATIONAL request for return routability check purposes (see Section 3.7). If the INFORMATIONAL request includes COOKIE2, the exchange responder MUST copy the notification to the response message.
该通知可包含在任何信息性请求中，用于返回可路由性检查（见第3.7节）。如果信息请求包括COOKIE2，则exchange响应程序必须将通知复制到响应消息中。
The data associated with this notification MUST be between 8 and 64 octets in length (inclusive), and MUST be chosen by the exchange initiator in a way that is unpredictable to the exchange responder. The Notify Message Type for this message is 16401. The Protocol ID and SPI Size fields are set to zero.
与此通知关联的数据长度必须在8到64个八位字节之间（包括8到64个八位字节），并且必须由exchange启动器以exchange响应程序无法预知的方式进行选择。此消息的通知消息类型为16401。协议ID和SPI大小字段设置为零。
See Section 3.9 for a description of this notification.
有关本通知的说明，请参见第3.9节。
The Notify Message Type for this message is 16402. The notification data contains the IP addresses and ports from/to which the packet was sent. For IPv4, the notification data is 12 octets long and is defined as follows:
此消息的通知消息类型为16402。通知数据包含发送数据包的IP地址和端口。对于IPv4，通知数据的长度为12个八位字节，定义如下：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Destination IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Destination IPv4 address !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For IPv6, the notification data is 36 octets long and is defined as follows:
对于IPv6，通知数据的长度为36个八位字节，定义如下：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Source IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Destination IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Source IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! Destination IPv6 address !
! !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Source port ! Destination port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol ID and SPI Size fields are set to zero.
协议ID和SPI大小字段设置为零。
The main goals of this specification are to maintain the security offered by usual IKEv2 procedures and to counter mobility-related threats in an appropriate manner. This section describes new security considerations introduced by MOBIKE. See [IKEv2] for security considerations for IKEv2 in general.
本规范的主要目标是维护通常的IKEv2程序提供的安全性，并以适当的方式应对与移动相关的威胁。本节介绍MOBIKE引入的新安全注意事项。关于IKEv2的一般安全注意事项，请参见[IKEv2]。
MOBIKE payloads relating to updating addresses are encrypted, integrity protected, and replay protected using the IKE_SA. This assures that no one except the participants can, for instance, give a control message to change the addresses.
与更新地址相关的MOBIKE有效负载使用IKE_SA进行加密、完整性保护和重播保护。例如，这可以确保除参与者之外，没有人可以发出控制消息来更改地址。
However, as with normal IKEv2, the actual IP addresses in the IP header are not covered by the integrity protection. This means that a NAT between the parties (or an attacker acting as a NAT) can modify the addresses and cause incorrect tunnel header (outer) IP addresses to be used for IPsec SAs. The scope of this attack is limited mainly to denial of service because all traffic is protected using IPsec.
但是，与正常的IKEv2一样，IP报头中的实际IP地址不受完整性保护的保护。这意味着双方之间的NAT（或充当NAT的攻击者）可以修改地址，并导致IPsec SAs使用不正确的隧道头（外部）IP地址。此攻击的范围主要限于拒绝服务，因为所有通信都使用IPsec进行保护。
This attack can only be launched by on-path attackers that are capable of modifying IKEv2 messages carrying NAT detection payloads (such as Dead Peer Detection messages). By modifying the IP header of these packets, the attackers can lead the peers to believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying the IKEv2 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually recognize that the intended traffic is not getting through, and will update the addresses appropriately.
此攻击只能由能够修改携带NAT检测有效负载（如死点检测消息）的IKEv2消息的路径上攻击者发起。通过修改这些数据包的IP头，攻击者可以使对等方相信它们之间存在新的NAT或更改的NAT绑定。只要攻击者在路径上修改IKEv2消息，攻击就可以继续。如果情况不再如此，设计用于检测NAT映射更改的IKEv2和MOBIKE机制将最终识别出预期流量未通过，并将适当更新地址。
MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. When this notification is used, communication through NATs and other address translators is impossible, so it is sent only when not doing NAT Traversal. This feature is mainly intended for IPv6 and site-to-site VPN cases, where the administrators may know beforehand that NATs are not present.
MOBIKE引入了NO_NATS_ALLOWED通知，用于检测外部人员对IP报头中地址的修改。使用此通知时，无法通过NAT和其他地址转换器进行通信，因此只有在不进行NAT遍历时才会发送此通知。此功能主要用于IPv6和站点到站点VPN情况，管理员可能事先知道NAT不存在。
The use of IPsec protection on payload traffic protects the participants against disclosure of the contents of the traffic, should the traffic end up in an incorrect destination or be subject to eavesdropping.
在有效负载流量上使用IPsec保护可以防止参与者泄露流量的内容，如果流量最终到达错误的目的地或被窃听。
However, security associations originally created for the protection of a specific flow between specific addresses may be updated by MOBIKE later on. This has to be taken into account if the (outer) IP address of the peer was used when deciding what kind of IPsec SAs the peer is allowed to create.
但是，最初为保护特定地址之间的特定流而创建的安全关联稍后可能会由MOBIKE更新。如果在决定允许对等方创建何种IPsec SA时使用了对等方的（外部）IP地址，则必须考虑这一点。
For instance, the level of required protection might depend on the current location of the VPN client, or access might be allowed only from certain IP addresses.
例如，所需的保护级别可能取决于VPN客户端的当前位置，或者可能只允许从某些IP地址进行访问。
It is recommended that security policies, for peers that are allowed to use MOBIKE, are configured in a manner that takes into account that a single security association can be used at different times through paths of varying security properties.
建议对允许使用MOBIKE的对等方的安全策略进行配置，同时考虑到单个安全关联可以在不同时间通过不同安全属性的路径使用。
This is especially critical for traffic selector authorization. The (logical) Peer Authorization Database (PAD) contains the information used by IKEv2 when determining what kind of IPsec SAs a peer is allowed to create. This process is described in [IPsecArch], 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. See also [Clarifications] for a more extensive discussion.
这对于流量选择器授权尤其重要。（逻辑）对等授权数据库（PAD）包含IKEv2在确定允许对等方创建何种IPsec SA时使用的信息。[IPsecArch]第4.4.3节描述了该过程。当对等方请求使用某些流量选择器创建IPsec SA时，PAD必须包含“子SA授权数据”，链接IKEv2验证的身份和流量选择器允许的地址。有关更广泛的讨论，请参见[澄清]。
It is important to note that simply sending IKEv2 packets using some particular address does not automatically imply a permission to create IPsec SAs with that address in the traffic selectors. However, some implementations are known to use policies where simply being reachable at some address X implies a temporary permission to create IPsec SAs for address X. Here "being reachable" usually means the ability to send (or spoof) IP packets with source address X and receive (or eavesdrop) packets sent to X.
需要注意的是，仅使用某个特定地址发送IKEv2数据包并不自动意味着允许在流量选择器中使用该地址创建IPsec SAs。然而，一些实现已知使用策略，其中仅在某个地址X处可访问意味着为地址X创建IPsec SAs的临时权限。这里的“可访问”通常意味着能够使用源地址X发送（或欺骗）IP数据包并接收（或窃听）发送到X的数据包。
Using this kind of policies or extensions with MOBIKE may need special care to enforce the temporary nature of the permission. For example, when the peer moves to some other address Y (and is no longer reachable at X), it might be necessary to close IPsec SAs with traffic selectors matching X. However, these interactions are beyond the scope of this document.
在MOBIKE中使用此类策略或扩展可能需要特别小心，以强制执行权限的临时性。例如，当对等方移动到某个其他地址Y（并且在X处不再可访问）时，可能需要使用与X匹配的流量选择器关闭IPsec SAs。但是，这些交互超出了本文档的范围。
Traffic redirection may be performed not just to gain access to the traffic or to deny service to the peers, but also to cause a denial-of-service attack on a third party. For instance, a high-speed TCP session or a multimedia stream may be redirected towards a victim host, causing its communications capabilities to suffer.
执行流量重定向不仅是为了获得对流量的访问权或拒绝向对等方提供服务，而且也是为了对第三方造成拒绝服务攻击。例如，高速TCP会话或多媒体流可能被重定向到受害主机，导致其通信能力受到影响。
The attackers in this threat can be either outsiders or even one of the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers can be easily dealt with if the authentication performed in the initial IKEv2 negotiation can be traced to persons who can be held responsible for the attack. This may not be the case in all scenarios, particularly with opportunistic approaches to security.
此威胁中的攻击者可以是外部攻击者，也可以是IKEv2对等方中的一个。在通常的VPN使用场景中，如果在初始IKEv2协商中执行的身份验证可以追踪到可能对攻击负责的人，那么对等方的攻击可以很容易地被处理。并非所有情况下都是如此，尤其是对于机会主义的安全方法。
If the attack is launched by an outsider, the traffic flow would normally stop soon due to the lack of responses (such as transport layer acknowledgements). However, if the original recipient of the flow is malicious, it could maintain the traffic flow for an extended period of time, since it often would be able to send the required acknowledgements (see [Aura02] for more discussion).
如果攻击是由外部人员发起的，由于缺少响应（如传输层确认），流量通常会很快停止。但是，如果流的原始接收者是恶意的，它可以在较长的时间内维持流量，因为它通常能够发送所需的确认（更多讨论请参见[Aura02]）。
It should also be noted, as shown in [Bombing], that without ingress filtering in the attacker's network, such attacks are already possible simply by sending spoofed packets from the attacker to the victim directly. Furthermore, if the attacker's network has ingress filtering, this attack is largely prevented for MOBIKE as well. Consequently, it makes little sense to protect against attacks of similar nature in MOBIKE. However, it still makes sense to limit the amplification capabilities provided to attackers, so that they cannot use stream redirection to send a large number of packets to the victim by sending just a few packets themselves.
还应注意的是，如[Bombling]中所示，如果攻击者的网络中没有进入过滤，那么只要将攻击者发送的伪造数据包直接发送给受害者，就可以进行此类攻击。此外，如果攻击者的网络具有入口过滤，那么MOBIKE也可以在很大程度上防止这种攻击。因此，在MOBIKE防范类似性质的攻击毫无意义。但是，限制向攻击者提供的放大功能仍然是有意义的，这样他们就不能通过自己发送几个数据包来使用流重定向向受害者发送大量数据包。
This specification includes return routability tests to limit the duration of any "third party bombing" attacks by off-path (relative to the victim) attackers. The tests are authenticated messages that the peer has to respond to, and can be performed before the address change takes effect, immediately afterwards, or even periodically during the session. The tests contain unpredictable data, and only someone who has the keys associated with the IKE SA and has seen the request packet can properly respond to the test.
本规范包括返回可路由性测试，以限制非路径（相对于受害者）攻击者的任何“第三方轰炸”攻击的持续时间。测试是对等方必须响应的经过身份验证的消息，可以在地址更改生效之前、之后立即执行，甚至在会话期间定期执行。测试包含不可预测的数据，只有拥有与IKE SA相关联的密钥并看到请求数据包的人才能正确响应测试。
The duration of the attack can also be limited if the victim reports the unwanted traffic to the originating IPsec tunnel endpoint using ICMP error messages or INVALID_SPI notifications. As described in [IKEv2], Section 2.21, this SHOULD trigger a liveness test, which also doubles as a return routability check if the COOKIE2 notification is included.
如果受害者使用ICMP错误消息或无效的_SPI通知向发起IPsec隧道端点报告不需要的通信量，则攻击的持续时间也会受到限制。如[IKEv2]第2.21节所述，这将触发活跃度测试，如果包含COOKIE2通知，该测试还可作为返回路由性检查。
Attackers may spoof various indications from lower layers and the network in an effort to confuse the peers about which addresses are or are not working. For example, attackers may spoof link-layer error messages in an effort to cause the parties to move their traffic elsewhere or even to disconnect. Attackers may also spoof
攻击者可能伪造来自较低层和网络的各种指示，试图混淆对等方哪些地址在工作或不在工作。例如，攻击者可能伪造链路层错误消息，以使各方将其流量转移到其他地方，甚至断开连接。攻击者也可能进行欺骗
information related to network attachments, router discovery, and address assignments in an effort to make the parties believe they have Internet connectivity when, in reality, they do not.
与网络连接、路由器发现和地址分配相关的信息，以使双方相信他们有互联网连接，而实际上他们没有。
This may cause use of non-preferred addresses or even denial of service.
这可能会导致使用非首选地址，甚至拒绝服务。
MOBIKE does not provide any protection of its own for indications from other parts of the protocol stack. These vulnerabilities can be mitigated through the use of techniques specific to the other parts of the stack, such as validation of ICMP errors [ICMPAttacks], link layer security, or the use of [SEND] to protect IPv6 Router and Neighbor Discovery.
MOBIKE不为来自协议栈其他部分的指示提供任何保护。这些漏洞可以通过使用特定于堆栈其他部分的技术来缓解，例如验证ICMP错误[ICMPAttacks]、链路层安全性或使用[SEND]来保护IPv6路由器和邻居发现。
Ultimately, MOBIKE depends on the delivery of IKEv2 messages to determine which paths can be used. If IKEv2 messages sent using a particular source and destination addresses reach the recipient and a reply is received, MOBIKE will usually consider the path working; if no reply is received even after retransmissions, MOBIKE will suspect the path is broken. An attacker who can consistently control the delivery or non-delivery of the IKEv2 messages in the network can thus influence which addresses actually get used.
最终，MOBIKE依靠IKEv2消息的传递来确定可以使用哪些路径。如果使用特定的源和目的地地址发送的IKEv2消息到达接收方并收到回复，MOBIOB通常会考虑路径工作；如果即使在重新传输之后也没有收到回复，MOBIKE将怀疑路径已断开。因此，能够持续控制网络中IKEv2消息的传递或不传递的攻击者可以影响实际使用的地址。
MOBIKE address updates and the ADDITIONAL_IP4_ADDRESS/ ADDITIONAL_IP6_ADDRESS notifications reveal information about which networks the peers are connected to.
MOBIKE地址更新和附加_IP4_地址/附加_IP6_地址通知会显示对等方连接到哪些网络的信息。
For example, consider a host A with two network interfaces: a cellular connection and a wired Ethernet connection to a company LAN. If host A now contacts host B using IKEv2 and sends ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications, host B receives additional information it might not otherwise know. If host A used the cellular connection for the IKEv2 traffic, host B can also see the company LAN address (and perhaps further guess that host A is used by an employee of that company). If host A used the company LAN to make the connection, host B can see that host A has a subscription from this particular cellular operator.
例如，考虑具有两个网络接口的主机A：蜂窝连接和与公司LAN的有线以太网连接。如果主机A现在使用IKEv2与主机B联系，并发送额外的_IP4_地址/额外的_IP6_地址通知，则主机B会收到它可能不知道的额外信息。如果主机A为IKEv2通信使用蜂窝连接，那么主机B也可以看到公司LAN地址（并且可能进一步猜测主机A由该公司的员工使用）。如果主机A使用公司LAN进行连接，主机B可以看到主机A已从该特定蜂窝网络运营商处订阅。
These additional addresses can also disclose more accurate location information than just a single address. Suppose that host A uses its cellular connection for IKEv2 traffic, but also sends an ADDITIONAL_IP4_ADDRESS notification containing an IP address corresponding to, say, a wireless LAN at a particular coffee shop location. It is likely that host B can now make a much better guess at A's location than would be possible based on the cellular IP address alone.
这些额外的地址也可以披露比单个地址更准确的位置信息。假设主机A使用其蜂窝连接进行IKEv2通信，但也发送一个额外的IP地址通知，其中包含一个IP地址，该IP地址对应于（比如）特定咖啡店位置的无线LAN。很可能主机B现在可以比仅基于蜂窝IP地址更好地猜测a的位置。
Furthermore, as described in Section 3.4, some of the addresses could also be private addresses behind a NAT.
此外，如第3.4节所述，一些地址也可以是NAT后面的专用地址。
In many environments, disclosing address information is not a problem (and indeed it cannot be avoided if the hosts wish to use those addresses for IPsec traffic). For instance, a remote access VPN client could consider the corporate VPN gateway sufficiently trustworthy for this purpose. Furthermore, the ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are sent encrypted, so the addresses are not visible to eavesdroppers (unless, of course, they are later used for sending IKEv2/IPsec traffic).
在许多环境中，公开地址信息不是问题（事实上，如果主机希望将这些地址用于IPsec通信，这是无法避免的）。例如，远程访问VPN客户端可以认为企业VPN网关为此足够可信。此外，附加的_-IP4_地址和附加的_-IP6_地址通知是加密发送的，因此窃听者看不到这些地址（当然，除非它们后来用于发送IKEv2/IPsec流量）。
However, if MOBIKE is used in some more opportunistic approach, it can be desirable to limit the information that is sent. Naturally, the peers do not have to disclose any addresses they do not want to use for IPsec traffic. Also, as noted in Section 3.6, an initiator whose policy is to always use the locally configured responder address does not have to send any ADDITIONAL_IP4_ADDRESS/ ADDITIONAL_IP6_ADDRESS payloads.
然而，如果MOBIKE用于某种更为机会主义的方法，则需要限制发送的信息。当然，对等方不必透露任何他们不想用于IPsec通信的地址。此外，如第3.6节所述，其策略是始终使用本地配置的响应者地址的启动器不必发送任何额外的_IP4_地址/额外的_IP6_地址有效载荷。
This document does not create any new namespaces to be maintained by IANA, but it requires new values in namespaces that have been defined in the IKEv2 base specification [IKEv2].
本文档不创建IANA要维护的任何新名称空间，但需要在IKEv2基本规范[IKEv2]中定义的名称空间中使用新值。
This document defines several new IKEv2 notifications whose values have been allocated from the "IKEv2 Notify Message Types" namespace.
本文档定义了几个新的IKEv2通知，其值已从“IKEv2通知消息类型”命名空间中分配。
Notify Messages - Error Types Value
----------------------------- -----
UNACCEPTABLE_ADDRESSES 40
UNEXPECTED_NAT_DETECTED 41
Notify Messages - Error Types Value
----------------------------- -----
UNACCEPTABLE_ADDRESSES 40
UNEXPECTED_NAT_DETECTED 41
Notify Messages - Status Types Value
------------------------------ -----
MOBIKE_SUPPORTED 16396
ADDITIONAL_IP4_ADDRESS 16397
ADDITIONAL_IP6_ADDRESS 16398
NO_ADDITIONAL_ADDRESSES 16399
UPDATE_SA_ADDRESSES 16400
COOKIE2 16401
NO_NATS_ALLOWED 16402
Notify Messages - Status Types Value
------------------------------ -----
MOBIKE_SUPPORTED 16396
ADDITIONAL_IP4_ADDRESS 16397
ADDITIONAL_IP6_ADDRESS 16398
NO_ADDITIONAL_ADDRESSES 16399
UPDATE_SA_ADDRESSES 16400
COOKIE2 16401
NO_NATS_ALLOWED 16402
These notifications are described in Section 4.
第4节介绍了这些通知。
This document is a collaborative effort of the entire MOBIKE WG. We would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti, Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann, Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld, Maureen Stillman, Shinta Sugimoto, Hannes Tschofenig, and Sami Vaarala. This document also incorporates ideas and text from earlier MOBIKE-like protocol proposals, including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the MOBIKE design document [Design].
本文件是整个MOBIKE工作组的合作成果。我们要特别感谢贾里·阿尔科、图马斯·奥拉、马塞洛·巴格鲁、斯蒂芬·博列伊、埃尔温·戴维斯、拉克希米纳·唐德蒂、弗朗西斯·杜邦、保罗·霍夫曼、詹姆斯·坎普夫、泰罗·基维宁、皮特·麦肯、埃里克·诺德马克、莫汉·帕塔萨拉西、佩卡·萨沃拉、比尔·索末菲、莫林·斯蒂尔曼、杉本辛塔、汉内斯·茨霍芬尼和萨米·瓦拉拉。本文件还纳入了早期类似MOBIKE的协议提案的想法和文本，包括[AddrMgmt]、[Kivinen]、[MOPO]和[SMOBIKE]，以及MOBIKE设计文件[design]。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[IPsecArch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsecArch]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[AddrMgmt] Dupont, F., "Address Management for IKE version 2", Work in Progress, November 2005.
杜邦，F.，“IKE版本2的地址管理”，正在进行的工作，2005年11月。
[Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", Proc. 18th Annual Computer Security Applications Conference (ACSAC), December 2002.
[Aura02]Aura，T.，Roe，M.，和J.Arkko，“互联网位置管理的安全”，Proc。第18届计算机安全应用年会（ACSAC），2002年12月。
[Bombing] Dupont, F., "A note about 3rd party bombing in Mobile IPv6", Work in Progress, December 2005.
[轰炸]杜邦，F.，“关于移动IPv6中第三方轰炸的说明”，正在进行的工作，2005年12月。
[Clarifications] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", Work in Progress, February 2006.
[澄清]Eronen，P.和P.Hoffman，“IKEv2澄清和实施指南”，进展中的工作，2006年2月。
[DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[DNA4]Aboba，B.，Carlson，J.，和S.Cheshire，“检测IPv4中的网络连接（DNAv4）”，RFC 44362006年3月。
[DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network Attachment in IPv6 - Best Current Practices for hosts", Work in Progress, October 2005.
[DNA6]Narayanan，S.，Daley，G.，和N.Montavont，“检测IPv6中的网络连接-主机当前最佳实践”，正在进行的工作，2005年10月。
[Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", Work in Progress, January 2006.
[设计]Kivinen，T.和H.Tschofenig，“MOBIKE协议的设计”，正在进行的工作，2006年1月。
[ICMPAttacks] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2005.
[ICMPAttacks]Gont，F.，“针对TCP的ICMP攻击”，正在进行的工作，2005年10月。
[Kivinen] Kivinen, T., "MOBIKE protocol", Work in Progress, February 2004.
[Kivinen]Kivinen，T.，“MOBIKE协议”，正在进行的工作，2004年2月。
[MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[MIP4]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[MIP6]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO-IKE)", Work in Progress, February 2005.
[MOPO]Eronen，P.，“IKEv2的移动协议选项（MOPO-IKE）”，正在进行的工作，2005年2月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[发送]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（发送）”，RFC 39712005年3月。
[SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and Multihoming Extensions for IKEv2 (SMOBIKE)", Work in Progress, March 2004.
[SMOBIKE]Eronen，P.和H.Tschofenig，“IKEv2（SMOBIKE）的简单移动和多宿扩展”，正在进行的工作，2004年3月。
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[STUN]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[UNSAF] Daigle, L., "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[UNSAF]Daigle，L.，“IAB对跨网络地址转换的单边自地址固定（UNSAF）的考虑”，RFC 34242002年11月。
[IPsecArch], Section 4.4.2, says that "For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache". The document does not specify how exactly this "pointing" is done, since this is an implementation detail that does not have to be standardized.
[IPsecArch]第4.4.2节指出，“对于出站处理，每个SAD条目都由SPD缓存的SPD-S部分中的条目指向”。该文档没有具体说明如何进行“定点”，因为这是一个不需要标准化的实现细节。
However, it is clear that the links between the SPD cache and the SAD have to be done correctly to ensure that outbound packets are sent over the right SA. Some implementations are known to have problems in this area.
然而，很明显，SPD缓存和SAD之间的链接必须正确完成，以确保出站数据包通过正确的SA发送。已知一些实现在这方面存在问题。
In particular, simply storing the (remote tunnel header IP address, remote SPI) pair in the SPD cache is not sufficient, since the pair does not always uniquely identify a single SAD entry. For instance, two hosts behind the same NAT can accidentally happen to choose the same SPI value. The situation can also occur when a host is assigned an IP address previously used by some other host, and the SAs associated with the old host have not yet been deleted by Dead Peer Detection. This may lead to packets being sent over the wrong SA or, if the key management daemon ensures the pair is unique, denying the creation of otherwise valid SAs.
特别是，仅将（远程隧道头IP地址，远程SPI）对存储在SPD缓存中是不够的，因为该对并不总是唯一地标识单个SAD条目。例如，同一NAT后面的两台主机可能会意外地选择相同的SPI值。当主机被分配了一个以前由其他主机使用的IP地址，并且与旧主机关联的SA尚未通过死点检测删除时，也可能发生这种情况。这可能导致数据包通过错误的SA发送，或者，如果密钥管理守护进程确保数据包对是唯一的，则拒绝创建其他有效的SA。
Storing the remote tunnel header IP address in the SPD cache may also complicate the implementation of MOBIKE, since the address can change during the lifetime of the SA. Thus, we recommend implementing the links between the SPD cache and the SAD in a way that does not require modification when the tunnel header IP address is updated by MOBIKE.
将远程隧道头IP地址存储在SPD缓存中也可能使MOBIKE的实现复杂化，因为地址在SA的生存期内可能会发生变化。因此，我们建议在MOBIKE更新隧道头IP地址时，以不需要修改的方式实现SPD缓存和SAD之间的链路。
When an outbound packet requires IPsec processing but no suitable SA exists, a new SA will be created. In this case, the host has to determine (1) who is the right peer for this SA, (2) whether the host already has an IKE_SA with this peer, and (3) if no IKE_SA exists, the IP address(es) of the peer for contacting it.
当出站数据包需要IPsec处理，但不存在合适的SA时，将创建新的SA。在这种情况下，主机必须确定（1）谁是该SA的正确对等方，（2）主机是否已经与该对等方有IKE_SA，以及（3）如果不存在IKE_SA，则确定用于联系该对等方的IP地址。
Neither [IPsecArch] nor MOBIKE specifies how exactly these three steps are carried out. [IPsecArch], Section 4.4.3.4, says:
[IPsecArch]和MOBIKE都没有具体说明这三个步骤是如何执行的。[IPsecArch]第4.4.3.4节规定：
For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 [RFC2401] and this document do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X.
例如，假设IKE A接收到一个目的地为IP地址X（由安全网关服务的主机）的出站数据包。RFC 2401[RFC2401]和本文件未规定A如何确定服务于X的IKE对等方的地址。但是，A作为X的假定代表联系的任何对等方必须在PAD中注册，以便允许对IKE交换进行身份验证。此外，当经过身份验证的对等方断言它在其流量选择器交换中代表X时，将咨询PAD以确定所述对等方是否被授权代表X。
In step 1, there may be more than one possible peer (e.g., several security gateways that are allowed to represent X). In step 3, the host may need to consult a directory such as DNS to determine the peer IP address(es).
在步骤1中，可能存在多个可能的对等方（例如，允许代表X的多个安全网关）。在步骤3中，主机可能需要查阅诸如DNS之类的目录以确定对等IP地址。
When performing these steps, implementations may use information contained in the SPD, the PAD, and possibly some other implementation-specific databases. Regardless of how exactly the steps are implemented, it is important to remember that IP addresses can change, and that an IP address alone does not always uniquely identify a single IKE peer (for the same reasons as why the combination of the remote IP address and SPI does not uniquely identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 and 2 it may be easier to identify the "right peer" using its authenticated identity instead of its current IP address. However, these implementation details are beyond the scope of this specification.
在执行这些步骤时，实现可能会使用SPD、PAD中包含的信息，可能还会使用一些其他特定于实现的数据库。无论这些步骤是如何实现的，重要的是要记住，IP地址可能会发生变化，并且单独的IP地址并不总是唯一标识单个IKE对等方（原因与远程IP地址和SPI的组合不能唯一标识出站IPsec SA的原因相同；请参阅附录a.1）。因此，在步骤1和2中，使用其经过身份验证的身份而不是其当前IP地址来识别“正确的对等方”可能更容易。但是，这些实现细节超出了本规范的范围。
Author's Address
作者地址
Pasi Eronen (editor) 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
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）提供。