Network Working Group T. Kivinen
Request for Comments: 4621 Safenet, Inc.
Category: Informational H. Tschofenig
Siemens
August 2006
Network Working Group T. Kivinen
Request for Comments: 4621 Safenet, Inc.
Category: Informational H. Tschofenig
Siemens
August 2006
Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
IKEv2移动和多址（MOBIKE）协议的设计
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
摘要
The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).
IKEv2移动和多归属（MOBIKE）协议是Internet密钥交换协议版本2（IKEv2）的扩展。当主机拥有多个IP地址和/或IPsec主机的IP地址随时间变化（例如，由于移动性）时，这些扩展应该能够有效地管理IKE和IPsec安全关联。
This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded.
本文件讨论了涉及的网络实体以及IKEv2信令和其他协议提供的信息之间的关系。记录MOBIKE协议的设计决策、背景信息和工作组内的讨论。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Scenarios .......................................................6
3.1. Mobility Scenario ..........................................6
3.2. Multihoming Scenario .......................................7
3.3. Multihomed Laptop Scenario .................................8
4. Scope of MOBIKE .................................................8
5. Design Considerations ..........................................10
5.1. Choosing Addresses ........................................10
5.1.1. Inputs and Triggers ................................11
5.1.2. Connectivity .......................................11
5.1.3. Discovering Connectivity ...........................12
5.1.4. Decision Making ....................................12
5.1.5. Suggested Approach .................................12
5.2. NAT Traversal (NAT-T) .....................................12
5.2.1. Background and Constraints .........................12
5.2.2. Fundamental Restrictions ...........................13
5.2.3. Moving behind a NAT and Back .......................13
5.2.4. Responder behind a NAT .............................14
5.2.5. NAT Prevention .....................................15
5.2.6. Suggested Approach .................................15
5.3. Scope of SA Changes .......................................15
5.4. Zero Address Set Functionality ............................16
5.5. Return Routability Check ..................................17
5.5.1. Employing MOBIKE Results in Other Protocols ........19
5.5.2. Return Routability Failures ........................20
5.5.3. Suggested Approach .................................21
5.6. IPsec Tunnel or Transport Mode ............................22
6. Protocol Details ...............................................22
6.1. Indicating Support for MOBIKE .............................22
6.2. Path Testing and Window size ..............................23
6.3. Message Presentation ......................................24
6.4. Updating Address Set ......................................25
7. Security Considerations ........................................26
8. Acknowledgements ...............................................26
9. References .....................................................27
9.1. Normative references ......................................27
9.2. Informative References ....................................27
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Scenarios .......................................................6
3.1. Mobility Scenario ..........................................6
3.2. Multihoming Scenario .......................................7
3.3. Multihomed Laptop Scenario .................................8
4. Scope of MOBIKE .................................................8
5. Design Considerations ..........................................10
5.1. Choosing Addresses ........................................10
5.1.1. Inputs and Triggers ................................11
5.1.2. Connectivity .......................................11
5.1.3. Discovering Connectivity ...........................12
5.1.4. Decision Making ....................................12
5.1.5. Suggested Approach .................................12
5.2. NAT Traversal (NAT-T) .....................................12
5.2.1. Background and Constraints .........................12
5.2.2. Fundamental Restrictions ...........................13
5.2.3. Moving behind a NAT and Back .......................13
5.2.4. Responder behind a NAT .............................14
5.2.5. NAT Prevention .....................................15
5.2.6. Suggested Approach .................................15
5.3. Scope of SA Changes .......................................15
5.4. Zero Address Set Functionality ............................16
5.5. Return Routability Check ..................................17
5.5.1. Employing MOBIKE Results in Other Protocols ........19
5.5.2. Return Routability Failures ........................20
5.5.3. Suggested Approach .................................21
5.6. IPsec Tunnel or Transport Mode ............................22
6. Protocol Details ...............................................22
6.1. Indicating Support for MOBIKE .............................22
6.2. Path Testing and Window size ..............................23
6.3. Message Presentation ......................................24
6.4. Updating Address Set ......................................25
7. Security Considerations ........................................26
8. Acknowledgements ...............................................26
9. References .....................................................27
9.1. Normative references ......................................27
9.2. Informative References ....................................27
The purpose of IKEv2 is to mutually authenticate two hosts, to establish one or more IPsec Security Associations (SAs) between them, and subsequently to manage these SAs (for example, by rekeying or deleting). IKEv2 enables the hosts to share information that is relevant to both the usage of the cryptographic algorithms that should be employed (e.g., parameters required by cryptographic algorithms and session keys) and to the usage of local security policies, such as information about the traffic that should experience protection.
IKEv2的目的是相互验证两台主机，在它们之间建立一个或多个IPsec安全关联（SA），然后管理这些SA（例如，通过重新键入或删除）。IKEv2使主机能够共享与应采用的加密算法的使用（例如，加密算法和会话密钥所需的参数）和本地安全策略的使用相关的信息，例如关于应受到保护的流量的信息。
IKEv2 assumes that an IKE SA is created implicitly between the IP address pair that is used during the protocol execution when establishing the IKEv2 SA. This means that, in each host, only one IP address pair is stored for the IKEv2 SA as part of a single IKEv2 protocol session, and, for tunnel mode SAs, the host places this single pair in the outer IP headers. Existing IPsec documents make no provision to change this pair after an IKE SA is created (except for dynamic address update of Network Address Translation Traversal (NAT-T)).
IKEv2假设在建立IKEv2 SA时，在协议执行期间使用的IP地址对之间隐式创建IKE SA。这意味着，在每个主机中，作为单个IKEv2协议会话的一部分，只为IKEv2 SA存储一个IP地址对，对于隧道模式SAs，主机将这一对放在外部IP报头中。现有IPsec文档没有规定在创建IKE SA后更改此对（除了网络地址转换遍历（NAT-T）的动态地址更新）。
There are scenarios where one or both of the IP addresses of this pair may change during an IPsec session. In principle, the IKE SA and all corresponding IPsec SAs could be re-established after the IP address has changed. However, this is a relatively expensive operation, and it can be problematic when such changes are frequent. Moreover, manual user interaction (for example, when using human-operated token cards (SecurID)) might be required as part of the IKEv2 authentication procedure. Therefore, an automatic mechanism is needed that updates the IP addresses associated with the IKE SA and the IPsec SAs. The MOBIKE protocol provides such a mechanism.
在某些情况下，此对的一个或两个IP地址可能在IPsec会话期间发生更改。原则上，IKE SA和所有相应的IPsec SA可以在IP地址更改后重新建立。然而，这是一个相对昂贵的操作，并且在频繁进行此类更改时可能会出现问题。此外，作为IKEv2身份验证过程的一部分，可能需要手动用户交互（例如，在使用人工操作的令牌卡（SecurID）时）。因此，需要一种自动机制来更新与IKE SA和IPsec SA关联的IP地址。MOBIKE协议提供了这样一种机制。
The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306]. As IKEv2 is built on the IPsec architecture [RFC4301], all protocols developed within the MOBIKE working group must be compatible with both IKEv2 and the architecture described in RFC 4301. This document does not discuss mobility and multi-homing support for IKEv1 [RFC2409] or the obsoleted IPsec architecture described in RFC 2401 [RFC2401].
假设MOBIKE协议在IKEv2[RFC4306]之上工作。由于IKEv2构建在IPsec体系结构[RFC4301]上，MOBIKE工作组内开发的所有协议必须与IKEv2和RFC 4301中描述的体系结构兼容。本文档不讨论IKEv1[RFC2409]或RFC 2401[RFC2401]中描述的过时IPsec体系结构的移动性和多归属支持。
This document is structured as follows: After some important terms are introduced in Section 2, a number of relevant usage scenarios are discussed in Section 3. Section 4 describes the scope of the MOBIKE protocol. Section 5 discusses design considerations affecting the MOBIKE protocol. Section 6 investigates details regarding the MOBIKE protocol. Finally, this document concludes in Section 7 with security considerations.
本文档的结构如下：在第2节介绍了一些重要术语之后，第3节讨论了一些相关的使用场景。第4节描述了MOBIKE协议的范围。第5节讨论了影响MOBIKE协议的设计考虑因素。第6节研究了有关MOBIKE协议的细节。最后，本文档在第7节中总结了安全考虑。
This section introduces the terminology that is used in this document.
本节介绍本文档中使用的术语。
Peer
同龄人
A peer is an IKEv2 endpoint. In addition, a peer implements the MOBIKE extensions, defined in [RFC4555].
对等点是IKEv2端点。此外，对等机实现了[RFC4555]中定义的MOBIKE扩展。
Available address
可用地址
An address is said to be available if the following conditions are met:
如果满足以下条件，则称地址可用：
* The address has been assigned to an interface.
* 地址已分配给接口。
* If the address is an IPv6 address, we additionally require (a) that the address is valid as defined in RFC 2461 [RFC2461], and (b) that the address is not tentative as defined in RFC 2462 [RFC2462]. In other words, we require the address assignment to be complete.
* 如果该地址是IPv6地址，我们还要求（a）该地址按照RFC 2461[RFC2461]中的定义有效，（b）该地址不是RFC 2462[RFC2462]中定义的暂定地址。换句话说，我们要求完成地址分配。
Note that this explicitly allows an address to be optimistic as defined in [RFC4429].
请注意，这显式地允许地址是[RFC4429]中定义的乐观地址。
* If the address is an IPv6 address, it is a global unicast or unique site-local address, as defined in [RFC4193]. That is, it is not an IPv6 link-local address.
* 如果地址是IPv6地址，则它是全局单播或唯一站点本地地址，如[RFC4193]中所定义。也就是说，它不是IPv6链路本地地址。
* The address and interface is acceptable for sending and receiving traffic according to a local policy.
* 地址和接口可用于根据本地策略发送和接收流量。
This definition is taken from [WIP-Ark06] and adapted for the MOBIKE context.
此定义取自[WIP-Ark06]，并适用于MOBIKE上下文。
Locally operational address
本地操作地址
An address is said to be locally operational if it is available and its use is locally known to be possible and permitted. This definition is taken from [WIP-Ark06].
如果一个地址是可用的，并且它的使用在本地被认为是可能的和允许的，那么它就被称为是本地操作的。该定义取自[WIP-Ark06]。
Operational address pair
操作地址对
A pair of operational addresses are said to be an operational address pair if and only if bidirectional connectivity can be shown between the two addresses. Note that sometimes it is necessary to consider connectivity on a per-flow level between two
当且仅当两个地址之间可以显示双向连接时，一对操作地址称为操作地址对。注意，有时需要考虑两个流之间的连接性。
endpoints. This differentiation might be necessary to address certain Network Address Translation types or specific firewalls. This definition is taken from [WIP-Ark06] and adapted for the MOBIKE context. Although it is possible to further differentiate unidirectional and bidirectional operational address pairs, only bidirectional connectivity is relevant to this document, and unidirectional connectivity is out of scope.
端点。这种区别对于解决某些网络地址转换类型或特定防火墙可能是必要的。此定义取自[WIP-Ark06]，并适用于MOBIKE上下文。虽然可以进一步区分单向和双向操作地址对，但本文档仅涉及双向连接，单向连接超出范围。
Path
路径
The sequence of routers traversed by the MOBIKE and IPsec packets exchanged between the two peers. Note that this path may be affected not only by the involved source and destination IP addresses, but also by the transport protocol. Since MOBIKE and IPsec packets have a different appearance on the wire, they might be routed along a different path, for example, due to load balancing. This definition is taken from [RFC2960] and adapted to the MOBIKE context.
两个对等方之间交换的MOBIKE和IPsec数据包所经过的路由器序列。请注意，此路径可能不仅受涉及的源和目标IP地址的影响，还受传输协议的影响。由于MOBIKE和IPsec数据包在线路上的外观不同，例如，由于负载平衡，它们可能沿着不同的路径路由。此定义取自[RFC2960]，并适用于MOBIKE上下文。
Current path
当前路径
The sequence of routers traversed by an IP packet that carries the default source and destination addresses is said to be the Current Path. This definition is taken from [RFC2960] and adapted to the MOBIKE context.
承载默认源地址和目标地址的IP数据包所经过的路由器序列称为当前路径。此定义取自[RFC2960]，并适用于MOBIKE上下文。
Preferred address
首选地址
The IP address of a peer to which MOBIKE and IPsec traffic should be sent by default. A given peer has only one active preferred address at a given point in time, except for the small time period where it switches from an old to a new preferred address. This definition is taken from [WIP-Nik06] and adapted to the MOBIKE context.
默认情况下应向其发送MOBIKE和IPsec通信的对等方的IP地址。给定的对等方在给定的时间点上只有一个活动的首选地址，但从旧的首选地址切换到新的首选地址的小时间段除外。该定义取自[WIP-Nik06]，并适用于MOBIKE上下文。
Peer address set
对等地址集
We denote the two peers of a MOBIKE session by peer A and peer B. A peer address set is the subset of locally operational addresses of peer A that is sent to peer B. A policy available at peer A indicates which addresses are included in the peer address set. Such a policy might be created either manually or automatically through interaction with other mechanisms that indicate new available addresses.
我们用对等方a和对等方B表示MOBIKE会话的两个对等方。对等方地址集是发送给对等方B的对等方a的本地操作地址的子集。对等方a可用的策略指示对等方地址集中包括哪些地址。这种策略可以手动创建，也可以通过与指示新可用地址的其他机制交互自动创建。
Bidirectional address pair
双向地址对
The address pair, where traffic can be sent to both directions, simply by reversing the IP addresses. Note that the path of the packets going to each direction might be different.
地址对，其中的流量可以发送到两个方向，只需颠倒IP地址即可。请注意，每个方向的数据包路径可能不同。
Unidirectional address pair
单向地址对
The address pair, where traffic can only be sent in one direction, and reversing the IP addresses and sending reply back does not work.
地址对，其中流量只能向一个方向发送，而反转IP地址并发送回复不起作用。
For mobility-related terminology (e.g., Make-before-break or Break-before-make), see [RFC3753].
有关移动性相关术语（例如，先通后断或先断后通），请参见[RFC3753]。
In this section, we discuss three typical usage scenarios for the MOBIKE protocol.
在本节中，我们将讨论MOBIKE协议的三种典型使用场景。
Figure 1 shows a break-before-make mobility scenario where a mobile node (MN) changes its point of network attachment. Prior to the change, the mobile node had established an IPsec connection with a security gateway that offered, for example, access to a corporate network. The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took place over the path labeled as 'old path'. The involved packets carried the MN's "old" IP address and were forwarded by the "old" access router (OAR) to the security gateway (GW).
图1显示了先断后通的移动场景，其中移动节点（MN）更改其网络连接点。在更改之前，移动节点已与安全网关建立了IPsec连接，该安全网关提供例如对公司网络的访问。促进IPsec SA设置的IKEv2交换在标记为“旧路径”的路径上进行。所涉及的数据包携带MN的“旧”IP地址，并由“旧”访问路由器（OAR）转发到安全网关（GW）。
When the MN changes its point of network attachment, it obtains a new IP address using stateful or stateless address configuration. The goal of MOBIKE, in this scenario, is to enable the MN and the GW to continue using the existing SAs and to avoid setting up a new IKE SA. A protocol exchange, denoted by 'MOBIKE Address Update', enables the peers to update their state as necessary.
当MN更改其网络连接点时，它使用有状态或无状态地址配置获得新的IP地址。在这种情况下，MOBIKE的目标是使MN和GW能够继续使用现有SA，并避免建立新的IKE SA。协议交换由“MOBIKE地址更新”表示，允许对等方根据需要更新其状态。
Note that in a break-before-make scenario the MN obtains the new IP address after it can no longer be reached at the old IP address. In a make-before-break scenario, the MN is, for a given period of time, reachable at both the old and the new IP address. MOBIKE should work in both of the above scenarios.
请注意，在先断后通场景中，MN在旧IP地址无法再访问新IP地址后获得新IP地址。在先通后断的场景中，MN在给定的时间段内可以在旧IP地址和新IP地址上访问。MOBIKE应该在上述两种情况下都能工作。
(Initial IKEv2 Exchange)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
Old IP +--+ +---+ v
address |MN|------> |OAR| -------------V v
+--+ +---+ Old path V v
. +----+ v>>>>> +--+
.move | R | -------> |GW|
. | | >>>>> | |
v +----+ ^ +--+
+--+ +---+ New path ^ ^
New IP |MN|------> |NAR|--------------^ ^
address +--+ +---+ ^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
(MOBIKE Address Update)
(Initial IKEv2 Exchange)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
Old IP +--+ +---+ v
address |MN|------> |OAR| -------------V v
+--+ +---+ Old path V v
. +----+ v>>>>> +--+
.move | R | -------> |GW|
. | | >>>>> | |
v +----+ ^ +--+
+--+ +---+ New path ^ ^
New IP |MN|------> |NAR|--------------^ ^
address +--+ +---+ ^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
(MOBIKE Address Update)
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
...> = End host movement
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
...> = End host movement
Figure 1: Mobility Scenario
图1：移动性场景
Another MOBIKE usage scenario is depicted in Figure 2. In this scenario, the MOBIKE peers are equipped with multiple interfaces (and multiple IP addresses). Peer A has two interface cards with two IP addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 and IP_B2. Each peer selects one of its IP addresses as the preferred address, which is used for subsequent communication. Various reasons (e.g., hardware or network link failures) may require a peer to switch from one interface to another.
另一个MOBIKE使用场景如图2所示。在此场景中，MOBIKE对等点配备有多个接口（和多个IP地址）。对等A有两个接口卡，两个IP地址为IP_A1和IP_A2，对等B有两个IP地址为IP_B1和IP_B2。每个对等方选择其一个IP地址作为首选地址，用于后续通信。各种原因（例如，硬件或网络链路故障）可能要求对等机从一个接口切换到另一个接口。
+------------+ +------------+
| Peer A | *~~~~~~~~~* | Peer B |
| |>>>>>>>>>> * Network *>>>>>>>>>>| |
| IP_A1 +-------->+ +--------->+ IP_B1 |
| | | | | |
| IP_A2 +********>+ +*********>+ IP_B2 |
| | * * | |
+------------+ *~~~~~~~~~* +------------+
+------------+ +------------+
| Peer A | *~~~~~~~~~* | Peer B |
| |>>>>>>>>>> * Network *>>>>>>>>>>| |
| IP_A1 +-------->+ +--------->+ IP_B1 |
| | | | | |
| IP_A2 +********>+ +*********>+ IP_B2 |
| | * * | |
+------------+ *~~~~~~~~~* +------------+
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
***> = Potential future path through the network
(if Peer A and Peer B change their preferred
address)
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
***> = Potential future path through the network
(if Peer A and Peer B change their preferred
address)
Figure 2: Multihoming Scenario
图2：多主场景
Note that MOBIKE does not aim to support load balancing between multiple IP addresses. That is, each peer uses only one of the available address pairs at a given point in time.
请注意，MOBIKE并不旨在支持多个IP地址之间的负载平衡。也就是说，每个对等方在给定的时间点仅使用一个可用地址对。
The third scenario we consider is about a laptop that has multiple interface cards and therefore several ways to connect to the network. It may, for example, have a fixed Ethernet card, a WLAN interface, a General Packet Radio Service (GPRS) adaptor, a Bluetooth interface, or USB hardware. Not all interfaces are used for communication all the time for a number of reasons (e.g., cost, network availability, user convenience). The policies that determine which interfaces are connected to the network at any given point in time is outside the scope of the MOBIKE protocol and, as such, this document. However, as the laptop changes its point of attachment to the network, the set of IP addresses under which the laptop is reachable changes too.
我们考虑的第三种情况是关于一台笔记本电脑，它有多个接口卡，因此有几种连接到网络的方法。例如，它可能具有固定以太网卡、WLAN接口、通用分组无线业务（GPRS）适配器、蓝牙接口或USB硬件。由于许多原因（例如，成本、网络可用性、用户便利性），并非所有接口都始终用于通信。确定在任何给定时间点连接到网络的接口的策略不在MOBIKE协议的范围内，因此也不在本文档的范围内。但是，随着笔记本电脑更改其与网络的连接点，可访问笔记本电脑的IP地址集也会更改。
In all of these scenarios, even if IP addresses change due to interface switching or mobility, the IP address obtained via the configuration payloads within IKEv2 remain unaffected. The IP address obtained via the IKEv2 configuration payloads allow the configuration of the inner IP address of the IPsec tunnel. As such, applications might not detect any change at all.
在所有这些场景中，即使IP地址由于接口交换或移动性而改变，通过IKEv2内的配置有效负载获得的IP地址也不会受到影响。通过IKEv2配置有效负载获得的IP地址允许配置IPsec隧道的内部IP地址。因此，应用程序可能根本检测不到任何更改。
Getting mobility and multihoming actually working requires many different components to work together, including coordinating decisions between different layers, different mobility mechanisms, and IPsec/IKEv2. Most of those aspects are beyond the scope of MOBIKE: MOBIKE focuses only on what two peers need in order to agree at the IKEv2 level (like new message formats and some aspects of their processing) required for interoperability.
要使移动性和多归属真正发挥作用，需要许多不同的组件协同工作，包括协调不同层、不同移动性机制和IPsec/IKEv2之间的决策。这些方面中的大多数都超出了MOBIKE的范围：MOBIKE只关注两个对等方需要什么，以便在互操作性所需的IKEv2级别（如新的消息格式及其处理的某些方面）达成一致。
The MOBIKE protocol is not trying to be a full mobility protocol; there is no support for simultaneous movement or rendezvous mechanism, and there is no support for route optimization, etc. The design document focuses on tunnel mode; everything going inside the tunnel is unaffected by the changes in the tunnel header IP address, and this is the mobility feature provided by the MOBIKE. That is, applications running inside the MOBIKE-controlled IPsec tunnel might not detect the movement since their IP addresses remain constant.
MOBIKE协议并不试图成为一个完全移动性协议；不支持同时移动或会合机制，也不支持路线优化等。设计文件侧重于隧道模式；隧道内的一切都不受隧道头IP地址变化的影响，这是MOBIKE提供的移动性特性。也就是说，在MOBIKE控制的IPsec隧道内运行的应用程序可能检测不到移动，因为它们的IP地址保持不变。
The MOBIKE protocol should be able to perform the following operations (not all of which are done explicitly by the current protocol):
MOBIKE协议应该能够执行以下操作（并非所有操作都由当前协议显式完成）：
o Inform the other peer about the peer address set
o 将对等地址集通知其他对等方
o Inform the other peer about the preferred address
o 将首选地址告知其他对等方
o Test connectivity along a path and thereby detect an outage situation
o 沿路径测试连接性，从而检测中断情况
o Change the preferred address
o 更改首选地址
o Change the peer address set
o 更改对等地址集
o Ability to deal with Network Address Translation devices
o 能够处理网络地址转换设备
Figure 3 shows an example protocol interaction between a pair of MOBIKE peers. MOBIKE interacts with the packet processing module of the IPsec implementation using an internal API (such as those based on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create entries in the Security Association (SAD) and Security Policy Databases (SPD). The packet processing module of the IPsec implementation may also interact with IKEv2 and MOBIKE module using this API. The content of the Security Policy and Security Association Databases determines what traffic is protected with IPsec in which fashion. MOBIKE, on the other hand, receives information from a number of sources that may run both in kernel-mode and in user-mode. These sources form the basis on which MOBIKE makes decisions regarding the set of available addresses, the peer address set, and the preferred address. Policies may also affect the selection process.
图3显示了一对MOBIKE对等点之间的协议交互示例。MOBIKE使用内部API（例如基于PF_密钥[RFC2367]的API）与IPsec实现的数据包处理模块进行交互。使用此API，MOBIKE模块可以在安全关联（SAD）和安全策略数据库（SPD）中创建条目。IPsec实现的分组处理模块还可以使用该API与IKEv2和MOBIKE模块交互。安全策略和安全关联数据库的内容决定了IPsec以何种方式保护哪些流量。另一方面，MOBIKE从许多源接收信息，这些源可以在内核模式和用户模式下运行。这些源构成了MOBIKE做出关于可用地址集、对等地址集和首选地址的决策的基础。策略也可能影响选择过程。
The peer address set and the preferred address needs to be made available to the other peer. In order to address certain failure cases, MOBIKE should perform connectivity tests between the peers (potentially over a number of different paths). Although a number of address pairs may be available for such tests, the most important is the pair (source address, destination address) of the current path. This is because this pair is selected for sending and receiving MOBIKE signaling and IPsec traffic. If a problem along this current path is detected (e.g., due to a router failure), it is necessary to switch to a new current path. In order to be able to do so quickly, it may be helpful to perform connectivity tests of other paths periodically. Such a technique would also help identify previously disconnected paths that become operational again.
对等地址集和首选地址需要提供给其他对等方。为了解决某些故障情况，MOBIKE应该在对等方之间执行连接测试（可能通过许多不同的路径）。尽管有许多地址对可用于此类测试，但最重要的是当前路径的地址对（源地址、目标地址）。这是因为选择该对用于发送和接收MOBIKE信令和IPsec流量。如果检测到此当前路径上存在问题（例如，由于路由器故障），则有必要切换到新的当前路径。为了能够快速执行此操作，定期执行其他路径的连接测试可能会有所帮助。这种技术还将有助于识别以前断开的路径，这些路径将再次运行。
+---------------------+ +----------------+
| User-space | | |
| Protocols and | | MOBIKE and |
| Functions Relevant |<---------->| IKEv2 Module |
| MOBIKE (e.g., DHCP, | | |
| policies) | +----------------+
+---------------------+ ^
^ |
| | User space
++++++++++API++++++++++++++++++++++++++++PF_KEY+++++++++++++++
| | Kernel space
| v
| +----------------+
v | |
+---------------------+ | IPsec engine |
| Kernel-space |<---------->| (and databases)|
| Protocols | | |
| Relevant for | +----------------+
| MOBIKE (e.g., ND, | ^
| DNA, L2) |<---------------+ |
+---------------------+ v v
|| +----------------+
\/ | |
Inter- =====================>| IP forwarding, |
faces <=====================|input and output|
| |
+----------------+
+---------------------+ +----------------+
| User-space | | |
| Protocols and | | MOBIKE and |
| Functions Relevant |<---------->| IKEv2 Module |
| MOBIKE (e.g., DHCP, | | |
| policies) | +----------------+
+---------------------+ ^
^ |
| | User space
++++++++++API++++++++++++++++++++++++++++PF_KEY+++++++++++++++
| | Kernel space
| v
| +----------------+
v | |
+---------------------+ | IPsec engine |
| Kernel-space |<---------->| (and databases)|
| Protocols | | |
| Relevant for | +----------------+
| MOBIKE (e.g., ND, | ^
| DNA, L2) |<---------------+ |
+---------------------+ v v
|| +----------------+
\/ | |
Inter- =====================>| IP forwarding, |
faces <=====================|input and output|
| |
+----------------+
===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations
===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations
Figure 3: Framework
图3：框架
Please note that Figure 3 illustrates an example of how a MOBIKE implementation could work. It serves illustrative purposes only.
请注意，图3展示了MOBIKE实现如何工作的示例。它仅用于说明目的。
This section discusses aspects affecting the design of the MOBIKE protocol.
本节讨论影响MOBIKE协议设计的方面。
One of the core aspects of the MOBIKE protocol is the selection of the address for the IPsec packets we send. Choosing addresses for the IKEv2 request is a somewhat separate problem. In many cases, they will be the same (and in some design choice they will always be the same and could be forced to be the same by design).
MOBIKE协议的一个核心方面是为我们发送的IPsec数据包选择地址。为IKEv2请求选择地址是一个独立的问题。在许多情况下，它们都是相同的（在某些设计选择中，它们总是相同的，并且可能会被设计强迫相同）。
How address changes are triggered is largely beyond the scope of MOBIKE. The triggers can include changes in the set of addresses, various link-layer indications, failing dead peer detection, and changes in preferences and policies. Furthermore, there may be less reliable sources of information (such as lack of IPsec packets and incoming ICMP packets) that do not trigger any changes directly, but rather cause Dead Peer Detection (DPD) to be scheduled earlier and, if it fails, it might cause a change of the preferred address.
如何触发地址更改在很大程度上超出了MOBIKE的范围。触发器可以包括地址集的更改、各种链路层指示、失效对等检测以及首选项和策略的更改。此外，可能存在不太可靠的信息源（例如缺少IPsec数据包和传入ICMP数据包），这些信息源不会直接触发任何更改，而是会导致提前安排死对等检测（DPD），如果失败，可能会导致首选地址的更改。
These triggers are largely the same as for other mobility protocols such as Mobile IP, and they are beyond the scope of MOBIKE.
这些触发器在很大程度上与其他移动协议（如移动IP）相同，并且它们超出了MOBIKE的范围。
There can be two kinds of connectivity "failures": local failures and path failures. Local failures are problems locally at a MOBIKE peer (e.g., an interface error). Path failures are a property of an address pair and failures of nodes and links along this path. MOBIKE does not support unidirectional address pairs. Supporting them would require abandoning the principle of sending an IKEv2 reply to the address from which the request came. MOBIKE decided to deal only with bidirectional address pairs. It does consider unidirectional address pairs as broken and does not use them, but the connection between peers will not break even if unidirectional address pairs are present, provided there is at least one bidirectional address pair MOBIKE can use.
可以有两种连接“故障”：本地故障和路径故障。本地故障是MOBIKE对等点的本地问题（例如，接口错误）。路径故障是地址对的属性，以及沿此路径的节点和链接的故障。MOBIKE不支持单向地址对。支持它们需要放弃向请求发出地址发送IKEv2回复的原则。MOBIKE决定只处理双向地址对。它确实考虑单向地址对被破坏，并且不使用它们，但是如果存在至少一个双向地址对MOBIKE可以使用的话，如果存在单向地址对，对等体之间的连接不会中断。
Note that MOBIKE is not concerned about the actual path used; it cannot even detect if some path is unidirectionally operational if the same address pair has some other unidirectional path back. Ingress filters might still cause such path pairs to be unusable, and in that case MOBIKE will detect that there is no operational address pair.
注意MOBIKE并不关心实际使用的路径；如果同一地址对有其他单向路径返回，它甚至无法检测某些路径是否单向运行。入口过滤器仍可能导致此类路径对不可用，在这种情况下，MOBIKE将检测到没有可操作的地址对。
In a sense having both an IPv4 and an IPv6 address is basically a case of partial connectivity (putting both an IPv4 and an IPv6 address in the same IP header does not work). The main difference is that it is known beforehand; there is no need to discover that an IPv4/IPv6 combination does not work.
从某种意义上讲，同时拥有IPv4和IPv6地址基本上是部分连接的情况（将IPv4和IPv6地址放在同一个IP报头中不起作用）。主要区别在于它是事先知道的；没有必要发现IPv4/IPv6组合不起作用。
To detect connectivity, the MOBIKE protocol needs to have a mechanism to test connectivity. If a MOBIKE peer receives a reply, it can be sure about the existence of a working (bidirectional) address pair. If a MOBIKE peer does not see a reply after multiple retransmissions, it may assume that the tested address pair is broken.
为了检测连接性，MOBIKE协议需要有一个测试连接性的机制。如果MOBIKE对等方收到回复，它可以确定是否存在工作（双向）地址对。如果MOBIKE对等方在多次重传后未看到回复，则可能认为测试的地址对已断开。
The connectivity tests require congestion problems to be taken into account because the connection failure might be caused by congestion. The MOBIKE protocol should not make the congestion problem worse by sending many DPD packets.
连接测试要求考虑拥塞问题，因为连接失败可能是由拥塞引起的。MOBIKE协议不应通过发送多个DPD数据包使拥塞问题恶化。
One of the main questions in designing the MOBIKE protocol was who makes the decisions how to fix a situation when failure is detected, e.g., symmetry vs. asymmetry in decision making. Symmetric decision making (i.e., both peers can make decisions) may cause the different peers to make different decisions, thus causing asymmetric upstream/ downstream traffic. In the mobility case, it is desirable that the mobile peer can move both upstream and downstream traffic to some particular interface, and this requires asymmetric decision making (i.e. only one peer makes decisions).
设计MOBIKE协议的一个主要问题是，当检测到故障时，由谁来决定如何修复情况，例如，决策过程中的对称与不对称。对称决策（即，两个对等方都可以做出决策）可能会导致不同的对等方做出不同的决策，从而导致不对称的上游/下游流量。在移动性情况下，希望移动对等方能够将上游和下游业务移动到某个特定接口，并且这需要不对称决策（即，只有一个对等方做出决策）。
Working with stateful packet filters and NATs is easier if the same address pair is used in both upstream and downstream directions. Also, in common cases, only the peer behind NAT can actually perform actions to recover from the connectivity problems, as the other peer might not be able to initiate any connections to the peer behind NAT.
如果在上游和下游方向使用相同的地址对，则使用有状态数据包过滤器和NAT更容易。此外，在常见情况下，只有NAT后面的对等方可以实际执行操作以从连接问题中恢复，因为另一个对等方可能无法启动到NAT后面的对等方的任何连接。
The working group decided to select a method whereby the initiator will decide which addresses are used. As a consequence, the outcome is always the same for both parties. It also works best with NATs, as the initiator is most likely the node that is located behind a NAT.
工作组决定选择一种由发起者决定使用哪些地址的方法。因此，双方的结果总是一样的。它也最适合NAT，因为启动器很可能是位于NAT后面的节点。
Another core aspect of MOBIKE is the treatment of different NATs and Network Address Port Translations (NAPTs). In IKEv2 the tunnel header IP addresses are not sent inside the IKEv2 payloads, and thus there is no need to do unilateral self-address fixing (UNSAF
MOBIKE的另一个核心方面是处理不同的NAT和网络地址端口转换（NAPT）。在IKEv2中，隧道头IP地址不在IKEv2有效负载内发送，因此不需要进行单边自地址修复（UNSAF）
[RFC3424]). The tunnel header IP addresses are taken from the outer IP header of the IKE packets; thus, they are already processed by the NAT.
[RFC3424]）。隧道报头IP地址取自IKE分组的外部IP报头；因此，NAT已经对它们进行了处理。
The NAT detection payloads are used to determine whether the addresses in the IP header were modified by a NAT along the path. Detecting a NAT typically requires UDP encapsulation of IPsec ESP packets to be enabled, if desired. MOBIKE is not to change how IKEv2 NAT-T works in particular, any kind of UNSAF or explicit interaction with NATs (e.g., MIDCOM [RFC3303] or NSIS NATFW NSLP [WIP-Sti06]) is beyond the scope of the MOBIKE protocol. The MOBIKE protocol will need to define how MOBIKE and NAT-T are used together.
NAT检测有效负载用于确定IP报头中的地址是否被NAT沿路径修改。如果需要，检测NAT通常需要启用IPsec ESP数据包的UDP封装。MOBIKE不会改变IKEv2 NAT-T的工作方式。特别是，任何类型的UNSAF或与NAT的显式交互（例如，MIDCOM[RFC3303]或NSIS NATFW NSLP[WIP-Sti06]）都超出了MOBIKE协议的范围。MOBIKE协议需要定义如何将MOBIKE和NAT-T一起使用。
The NAT-T support should also be optional. If the IKEv2 implementation does not implement NAT-T, as it is not required in some particular environment, implementing MOBIKE should not require adding support for NAT-T either.
NAT-T支持也应该是可选的。如果IKEv2实现没有实现NAT-T，因为在某些特定环境中不需要它，那么实现MOBIKE也不需要添加对NAT-T的支持。
The property of being behind NAT is actually a property of the address pair and thereby of the path taken by a packet. Thus, one peer can have multiple IP addresses, and some of those might be behind NAT and some might not.
NAT后面的属性实际上是地址对的属性，因此也是数据包所采用的路径的属性。因此，一个对等方可以有多个IP地址，其中一些可能在NAT后面，而另一些可能不在NAT后面。
There are some cases that cannot be carried out within MOBIKE. One of those cases is when the party "outside" a symmetric NAT changes its address to something not known by the other peer (and the old address has stopped working). It cannot send a packet containing the new addresses to the peer because the NAT does not contain the necessary state. Furthermore, since the party behind the NAT does not know the new IP address, it cannot cause the NAT state to be created.
有些案例无法在MOBIKE内执行。其中一种情况是，对称NAT“外部”的一方将其地址更改为其他对等方不知道的地址（并且旧地址已停止工作）。它无法向对等方发送包含新地址的数据包，因为NAT不包含必要的状态。此外，由于NAT背后的一方不知道新的IP地址，因此无法创建NAT状态。
This case could be solved using some rendezvous mechanism outside IKEv2, but that is beyond the scope of MOBIKE.
这种情况可以使用IKEv2之外的某种会合机制来解决，但这超出了MOBIKE的范围。
The MOBIKE protocol should provide a mechanism whereby a peer that is initially not behind a NAT can move behind NAT when a new preferred address is selected. The same effect might be accomplished with the change of the address pair if more than one path is available (e.g., in the case of a multi-homed host). An impact for the MOBIKE protocol is only caused when the currently selected address pair causes MOBIKE packets to traverse a NAT.
MOBIKE协议应该提供一种机制，当选择新的首选地址时，初始不在NAT后面的对等方可以移动到NAT后面。如果有多条路径可用（例如，在多宿主主机的情况下），则通过更改地址对可以实现相同的效果。只有当当前选定的地址对导致MOBIKE数据包穿越NAT时，才会对MOBIKE协议造成影响。
Similarly, the MOBIKE protocol provides a mechanism to detect when a NATed path is changed to a non-NATed path with the change of the address pair.
类似地，MOBIKE协议提供了一种机制，用于检测何时通过地址对的更改将非指定路径更改为非指定路径。
As we only use one address pair at time, effectively the MOBIKE peer is either behind NAT or not behind NAT, but each address change can change this situation. Because of this, and because the initiator always chooses the addresses, it is enough to send keepalive packets only to that one address pair.
由于我们一次只使用一个地址对，实际上MOBIKE对等方要么在NAT后面，要么不在NAT后面，但每次地址更改都会改变这种情况。因此，由于启动器总是选择地址，所以只向该地址对发送keepalive数据包就足够了。
Enabling NAT-T involves a few different things. One is to enable the UDP encapsulation of ESP packets. Another is to change the IKE SA ports from port 500 to port 4500. We do not want to do unnecessary UDP encapsulation unless there is really a NAT between peers, i.e., UDP encapsulation should only be enabled when we actually detect NAT. On the other hand, as all implementations supporting NAT-T must be able to respond to port 4500 all the time, it is simpler from the protocol point of view to change the port numbers from 500 to 4500 immediately upon detecting that the other end supports NAT-T. This way it is not necessary to change ports after we later detected NAT, which would have caused complications to the protocol.
启用NAT-T涉及一些不同的事情。一种是启用ESP数据包的UDP封装。另一个是将IKE SA端口从端口500更改为端口4500。我们不希望进行不必要的UDP封装，除非对等方之间确实存在NAT，即只有在实际检测到NAT时才应启用UDP封装。另一方面，由于所有支持NAT-T的实现都必须能够始终响应端口4500，因此从协议的角度来看，在检测到另一端支持NAT-T时，立即将端口号从500更改为4500更简单。这样，在我们后来检测到NAT后就不必更改端口，这会给协议带来麻烦。
If we changed the port only after we detected NAT, then the responder would not be able to use the IKE and IPsec SAs immediately after their address is changed to be behind NAT. Instead, it would need to wait for the next packet from the initiator to see what IP and port numbers are used after the initiator changed its port from 500 to 4500. The responder would also not be able to send anything to the initiator before the initiator sent something to the responder. If we do the port number changing immediately after the IKE_SA_INIT and before IKE_AUTH phase, then we get the rid of this problem.
如果我们仅在检测到NAT后才更改端口，那么在IKE和IPsec SAs的地址更改为NAT之后，响应者将无法立即使用它们。相反，它需要等待来自启动器的下一个数据包，以查看在启动器将其端口从500更改为4500后使用的IP和端口号。在发起者向响应者发送内容之前，响应者也无法向发起者发送任何内容。如果我们在IKE_SA_INIT之后和IKE_AUTH阶段之前立即更改端口号，那么我们就可以解决这个问题。
MOBIKE can work in cases where the responder is behind a static NAT, but the initiator would need to know all the possible addresses to which the responder can move. That is, the responder cannot move to an address which is not known by the initiator, in case initiator also moves behind NAT.
MOBIKE可以在响应程序位于静态NAT后面的情况下工作，但是启动器需要知道响应程序可以移动到的所有可能地址。也就是说，如果启动器也移动到NAT后面，则响应程序无法移动到启动器未知的地址。
If the responder is behind a NAPT, then it might need to communicate with the NAT to create a mapping so the initiator can connect to it. Those external firewall pinhole opening mechanisms are beyond the scope of MOBIKE.
如果响应者在NAPT后面，那么它可能需要与NAT通信以创建映射，以便启动器可以连接到NAT。这些外部防火墙针孔打开机制超出了MOBIKE的范围。
In case the responder is behind NAPT, then finding the port numbers used by the responder is outside the scope of MOBIKE.
如果响应程序位于NAPT之后，则查找响应程序使用的端口号超出了MOBIKE的范围。
One new feature created by MOBIKE is NAT prevention. If we detect NAT between the peers, we do not allow that address pair to be used. This can be used to protect IP addresses in cases where the configuration knows that there is no NAT between the nodes (for example IPv6, or fixed site-to-site VPN). This avoids any possibility of on-path attackers modifying addresses in headers. This feature means that we authenticate the IP address and detect if they were changed. As this is done on purpose to break the connectivity if NAT is detected, and decided by the configuration, there is no need to do UNSAF processing.
MOBIKE创建的一个新特性是NAT预防。如果我们在对等方之间检测到NAT，我们将不允许使用该地址对。在配置知道节点之间没有NAT的情况下（例如IPv6或固定站点到站点VPN），这可用于保护IP地址。这避免了路径上攻击者修改头中地址的任何可能性。此功能意味着我们对IP地址进行身份验证，并检测它们是否已更改。由于这样做是为了在检测到NAT时中断连接，并且由配置决定，因此不需要进行UNSAF处理。
The working group decided that MOBIKE uses NAT-T mechanisms from the IKEv2 protocol as much as possible, but decided to change the dynamic address update (see [RFC4306], Section 2.23, second to last paragraph) for IKEv2 packets to "MUST NOT" (it would break path testing using IKEv2 packets; see Section 6.2). The working group also decided only to send keepalives to the current address pair.
工作组决定MOBIKE尽可能使用IKEv2协议中的NAT-T机制，但决定将IKEv2数据包的动态地址更新（见[RFC4306]，第2.23节，倒数第二段）更改为“不得”（它将中断使用IKEv2数据包的路径测试；见第6.2节）。工作组还决定只向当前地址对发送keepalives。
Most sections of this document discuss design considerations for updating and maintaining addresses in the database entries that relate to an IKE SA. However, changing the preferred address also affects the entries of the IPsec SA database. The outer tunnel header addresses (source and destination IP addresses) need to be modified according to the current path to allow the IPsec protected data traffic to travel along the same path as the MOBIKE packets. If the MOBIKE messages and the IPsec protected data traffic travel along a different path, then NAT handling is severely complicated.
本文档的大部分章节讨论了更新和维护与IKE SA相关的数据库条目中的地址的设计注意事项。但是，更改首选地址也会影响IPsec SA数据库的条目。外部隧道头地址（源和目标IP地址）需要根据当前路径进行修改，以允许受IPsec保护的数据流量沿着与MOBIKE数据包相同的路径传输。如果MOBIKE消息和受IPsec保护的数据通信沿着不同的路径传输，那么NAT处理将非常复杂。
The basic question is then how the IPsec SAs are changed to use the new address pair (the same address pair as the MOBIKE signaling traffic). One option is that when the IKE SA address is changed, all IPsec SAs associated with it are automatically moved along with it to a new address pair. Another option is to have a separate exchange to move the IPsec SAs separately.
基本问题是如何更改IPsec SAs以使用新的地址对（与MOBIKE信令流量相同的地址对）。一个选项是，当IKE SA地址更改时，与之关联的所有IPsec SA将自动随它一起移动到新的地址对。另一种选择是使用单独的交换机单独移动IPsec SAs。
If IPsec SAs should be updated separately, then a more efficient format than the Notify payload is needed to preserve bandwidth. A Notify payload can only store one Security Parameter Index (SPI) per payload. A separate payload could have a list of IPsec SA SPIs and the new preferred address. If there is a large number of IPsec SAs, those payloads can be quite large unless list of ranges of SPI values are supported. If we automatically move all IPsec SAs when the IKE
如果IPsec SAs应单独更新，则需要比Notify有效负载更有效的格式来保留带宽。Notify负载只能为每个负载存储一个安全参数索引（SPI）。一个单独的负载可以有一个IPsec SA SPI列表和新的首选地址。如果存在大量IPsec SA，则这些有效负载可能相当大，除非支持SPI值范围的列表。如果我们在IKE启动时自动移动所有IPsec SA
SA moves, then we only need to keep track of which IKE SA was used to create the IPsec SA, and fetch the IP addresses from the IKE SA, i.e., there is no need to store IP addresses per IPsec SA. Note that IKEv2 [RFC4306] already requires the implementations to keep track of which IPsec SAs are created using which IKE SA.
SA移动，那么我们只需要跟踪使用哪个IKE SA创建IPsec SA，并从IKE SA获取IP地址，即不需要为每个IPsec SA存储IP地址。注意，IKEv2[RFC4306]已经要求实现跟踪使用哪个IKE SA创建的IPsec SA。
If we do allow the address set of each IPsec SA to be updated separately, then we can support scenarios where the machine has fast and/or cheap connections and slow and/or expensive connections and wants to allow moving some of the SAs to the slower and/or more expensive connection, and prevent the move, for example, of the news video stream from the WLAN to the GPRS link.
如果我们允许单独更新每个IPsec SA的地址集，那么我们可以支持以下情况：机器具有快速和/或廉价连接以及慢速和/或昂贵连接，并且希望允许将一些SA移动到较慢和/或更昂贵的连接，并阻止移动，例如，将新闻视频流从WLAN传输到GPRS链路。
On the other hand, even if we tie the IKE SA update to the IPsec SA update, we can create separate IKE SAs for this scenario. For example, we create one IKE SA that has both links as endpoints, and it is used for important traffic; then we create another IKE SA which has only the fast and/or cheap connection, which is used for that kind of bulk traffic.
另一方面，即使我们将IKE SA更新绑定到IPsec SA更新，我们也可以为此场景创建单独的IKE SA。例如，我们创建了一个IKE SA，它将两个链接都作为端点，并用于重要的流量；然后我们创建另一个IKE SA，它只有快速和/或廉价的连接，用于这种批量流量。
The working group decided to move all IPsec SAs implicitly when the IKE SA address pair changes. If more granular handling of the IPsec SA is required, then multiple IKE SAs can be created one for each set of IPsec SAs needed.
工作组决定在IKE SA地址对更改时隐式移动所有IPsec SA。如果需要对IPsec SA进行更精细的处理，则可以为所需的每组IPsec SA创建多个IKE SA。
One of the features that is potentially useful is for the peer to announce that it will now disconnect for some time, i.e., it will not be reachable at all. For instance, a laptop might go to suspend mode. In this case, it could send address notification with zero new addresses, which would mean that it will not have any valid addresses anymore. The responder would then acknowledge that notification and could then temporarily disable all SAs and therefore stop sending traffic. If any of the SAs get any packets, they are simply dropped. This could also include some kind of ACK spoofing to keep the TCP/IP sessions alive (or simply setting the TCP/IP keepalives and timeouts large enough not to cause problems), or it could simply be left to the applications, e.g., allow TCP/IP sessions to notice if the link is broken.
其中一个潜在的有用特性是对等方宣布它现在将断开连接一段时间，也就是说，它将根本无法访问。例如，笔记本电脑可能会进入暂停模式。在这种情况下，它可以发送带有零个新地址的地址通知，这意味着它将不再具有任何有效地址。然后，响应者将确认该通知，然后可以暂时禁用所有SA，从而停止发送流量。如果任何SA收到任何数据包，它们将被丢弃。这还可能包括某种形式的ACK欺骗，以保持TCP/IP会话处于活动状态（或者简单地将TCP/IP保留和超时设置为足够大而不会导致问题），或者可以简单地将其留给应用程序，例如，允许TCP/IP会话注意链路是否断开。
The local policy could then indicate how long the peer should allow remote peers to remain disconnected.
然后，本地策略可以指示对等方应允许远程对等方保持断开连接的时间。
From a technical point of view, this would provide following two features:
从技术角度来看，这将提供以下两个特点：
o There is no need to transmit IPsec data traffic. IPsec-protected data can be dropped, which saves bandwidth. This does not provide a functional benefit, i.e., nothing breaks if this feature is not provided.
o 不需要传输IPsec数据通信。可以删除受IPsec保护的数据，从而节省带宽。这并不提供功能上的好处，也就是说，如果不提供此功能，任何东西都不会损坏。
o MOBIKE signaling messages are also ignored. The IKE SA must not be deleted, and the suspend functionality (realized with the zero address set) may require the IKE SA to be tagged with a lifetime value since the IKE SA should not be kept alive for an undefined period of time. Note that IKEv2 does not require that the IKE SA has a lifetime associated with it. In order to prevent the IKE SA from being deleted, the dead-peer detection mechanism needs to be suspended as well.
o MOBIKE信令消息也被忽略。不得删除IKE SA，并且由于IKE SA在未定义的时间段内不应保持活动状态，因此挂起功能（通过零地址集实现）可能需要使用生存期值标记IKE SA。注意，IKEv2不要求IKE SA具有与其相关联的生存期。为了防止IKE SA被删除，还需要暂停死点检测机制。
Due to its complexity and no clear requirement for it, it was decided that MOBIKE does not support this feature.
由于其复杂性和没有明确的要求，决定MOBIKE不支持此功能。
Changing the preferred address and subsequently using it for communication is associated with an authorization decision: Is a peer allowed to use this address? Does this peer own this address? Two mechanisms have been proposed in the past to allow a peer to determine the answer to these questions:
更改首选地址并随后将其用于通信与授权决策相关联：是否允许对等方使用此地址？这个同伴拥有这个地址吗？过去提出了两种机制，允许对等方确定这些问题的答案：
o The addresses a peer is using are part of a certificate. [RFC3554] introduced this approach. If the other peer is, for example, a security gateway with a limited set of fixed IP addresses, then the security gateway may have a certificate with all the IP addresses appearing in the certificate.
o 对等方使用的地址是证书的一部分。[RFC3554]介绍了这种方法。例如，如果另一对等方是具有有限组固定IP地址的安全网关，则安全网关可以具有证书，其中所有IP地址都出现在证书中。
o A return routability check is performed by the remote peer before the address is updated in that peer's Security Association Database. This is done in order to provide a certain degree of confidence to the remote peer that the local peer is reachable at the indicated address.
o 在远程对等方的安全关联数据库中更新地址之前，远程对等方将执行返回路由性检查。这样做是为了向远程对等方提供一定程度的信心，即本地对等方可以在指定的地址访问。
Without taking an authorization decision, a malicious peer can redirect traffic towards a third party or a black hole.
在不作出授权决定的情况下，恶意对等方可以将流量重定向到第三方或黑洞。
A MOBIKE peer should not use an IP address provided by another MOBIKE peer as a current address without computing the authorization decision. If the addresses are part of the certificate, then it is not necessary to execute the return routability check. The return routability check is a form of authorization check, although it provides weaker guarantees than the inclusion of the IP address as a part of a certificate. If multiple addresses are communicated to the remote peer, then some of these addresses may be already verified.
在未计算授权决策的情况下，MOBIKE对等方不应将另一个MOBIKE对等方提供的IP地址用作当前地址。如果地址是证书的一部分，则无需执行返回可路由性检查。返回路由性检查是授权检查的一种形式，尽管它提供的保证不如将IP地址作为证书的一部分。如果多个地址被传送到远程对等方，那么其中一些地址可能已经被验证。
Finally, it would be possible not to execute return routability checks at all. In case of indirect change notifications (i.e., something we notice from the network, not from the peer directly), we only move to the new preferred address after successful dead-peer detection (i.e., a response to a DPD test) on the new address, which is already a return routability check. With a direct notification (i.e., notification from the other end directly) the authenticated peer may have provided an authenticated IP address (i.e., inside IKE encrypted and authenticated payload; see Section 5.2.5). Thus, it is would be possible simply to trust the MOBIKE peer to provide a proper IP address. In this case, a protection against an internal attacker (i.e., the authenticated peer forwarding its traffic to the new address) would not provided. On the other hand, we know the identity of the peer in that case. There might be problems when extensions are added to IKEv2 that do not require authentication of end points (e.g., opportunistic security using anonymous Diffie-Hellman).
最后，可能根本不执行返回路由性检查。在间接更改通知的情况下（即，我们从网络而不是直接从对等方注意到的内容），我们只有在新地址上成功检测到死点（即，对DPD测试的响应）后才移动到新的首选地址，这已经是一个返回路由性检查。通过直接通知（即，来自另一端的直接通知），经过身份验证的对等方可能已经提供了经过身份验证的IP地址（即，在IKE加密和经过身份验证的有效负载内；参见第5.2.5节）。因此，可以简单地信任MOBIKE对等方提供适当的IP地址。在这种情况下，不会提供针对内部攻击者的保护（即，将其流量转发到新地址的经过身份验证的对等方）。另一方面，在这种情况下，我们知道对等方的身份。在IKEv2中添加不需要端点身份验证的扩展时可能会出现问题（例如，使用匿名Diffie-Hellman的机会主义安全）。
There is also a policy issue of when to schedule a return routability check. Before moving traffic? After moving traffic?
还存在一个政策问题，即何时安排退货可路由性检查。在移动交通之前？在移动交通之后？
The basic format of the return routability check could be similar to dead-peer detection, but potential attacks are possible if a return routability check does not include some kind of a nonce. In these attacks, the valid end point could send an address update notification for a third party, trying to get all the traffic to be sent there, causing a denial-of-service attack. If the return routability check does not contain any nonce or other random information not known to the other peer, then the other peer could reply to the return routability checks even when it cannot see the request. This might cause a peer to move the traffic to a location where the original recipient cannot be reached.
返回可路由性检查的基本格式可能类似于死点检测，但如果返回可路由性检查不包括某种nonce，则可能发生潜在的攻击。在这些攻击中，有效的端点可能会向第三方发送地址更新通知，试图将所有流量发送到第三方，从而导致拒绝服务攻击。如果返回可路由性检查不包含其他对等方不知道的任何nonce或其他随机信息，则其他对等方可以回复返回可路由性检查，即使它看不到请求。这可能会导致对等方将流量移动到无法联系到原始收件人的位置。
The IKEv2 NAT-T mechanism does not perform return routability checks. It simply uses the last seen source IP address used by the other peer as the destination address to which response packets are to be sent. An adversary can change those IP addresses and can cause the response packets to be sent to a wrong IP address. The situation is self-fixing when the adversary is no longer able to modify packets and the first packet with an unmodified IP address reaches the other peer. Mobility environments make this attack more difficult for an adversary since the attack requires the adversary to be located somewhere on the individual paths ({CoA1, ..., CoAn} towards the destination IP address), to have a shared path, or, if the adversary is located near the MOBIKE client, to follow the user mobility patterns. With IKEv2 NAT-T, the genuine client can cause third-party bombing by redirecting all the traffic pointed to him to a third
IKEv2 NAT-T机制不执行返回路由性检查。它只是使用另一个对等方使用的最后一次看到的源IP地址作为响应包要发送到的目标地址。对手可以更改这些IP地址，并可能导致响应数据包被发送到错误的IP地址。当对手不再能够修改数据包，并且具有未修改IP地址的第一个数据包到达另一个对等方时，这种情况是自我修复的。移动环境使对手更难进行此攻击，因为攻击要求对手位于朝向目标IP地址的单独路径（{CoA1，…，CoAn}）上的某个位置，拥有共享路径，或者，如果对手位于MOBIKE客户端附近，则遵循用户移动模式。有了IKEv2 NAT-T，真正的客户可以通过将指向他的所有流量重定向到第三方来引起第三方轰炸
party. As the MOBIKE protocol tries to provide equal or better security than IKEv2 NAT-T mechanism, it should protect against these attacks.
政党由于MOBIKE协议试图提供与IKEv2 NAT-T机制相同或更好的安全性，它应该能够抵御这些攻击。
There may be return routability information available from the other parts of the system too (as shown in Figure 3), but the checks done may have a different quality. There are multiple levels for return routability checks:
系统的其他部分也可能提供返回可路由性信息（如图3所示），但完成的检查可能具有不同的质量。返回可路由性检查有多个级别：
o None; no tests.
o 没有一个没有测试。
o A party willing to answer the return routability check is located along the path to the claimed address. This is the basic form of return routability check.
o 愿意回答返回可路由性检查的一方位于声称地址的路径上。这是返回可路由性检查的基本形式。
o There is an answer from the tested address, and that answer was authenticated and integrity- and replay-protected.
o 有一个来自测试地址的答案，该答案经过身份验证，完整性和重播受到保护。
o There was an authenticated and integrity- and replay-protected answer from the peer, but it is not guaranteed to originate at the tested address or path to it (because the peer can construct a response without seeing the request).
o 对等方提供了一个经过身份验证、完整性和重播保护的应答，但不能保证该应答来自测试地址或路径（因为对等方可以在不看到请求的情况下构造响应）。
The return routability checks do not protect against third-party bombing if the attacker is along the path, as the attacker can forward the return routability checks to the real peer (even if those packets are cryptographically authenticated).
如果攻击者在路径上，则返回路由性检查无法防止第三方轰炸，因为攻击者可以将返回路由性检查转发给真正的对等方（即使这些数据包经过加密验证）。
If the address to be tested is carried inside the MOBIKE payload, then the adversary cannot forward packets. Thus, third-party bombings are prevented (see Section 5.2.5).
如果要测试的地址携带在MOBIKE有效负载内，则对手无法转发数据包。因此，防止了第三方爆炸（见第5.2.5节）。
If the reply packet can be constructed without seeing the request packet (for example, if there is no nonce, challenge, or similar mechanism to show liveness), then the genuine peer can cause third-party bombing, by replying to those requests without seeing them at all.
如果可以在没有看到请求包的情况下构造回复包（例如，如果没有nonce、challenge或类似的机制来显示活跃性），那么真正的对等方可以通过在根本看不到请求的情况下回复这些请求来引起第三方轰炸。
Other levels might only provide a guarantee that there is a node at the IP address that replied to the request. There is no indication as to whether or not the reply is fresh or whether or not the request may have been transmitted from a different source address.
其他级别可能只能保证IP地址上有一个节点响应请求。没有迹象表明答复是否是新的，或者请求是否是从不同的源地址发送的。
If MOBIKE has learned about new locations or verified the validity of a remote address through a return routability check, can this information be useful for other protocols?
如果MOBIKE已经了解了新的位置，或者通过返回可路由性检查验证了远程地址的有效性，那么这些信息对其他协议有用吗？
When the basic MOBIKE VPN scenario is considered, the answer is no. Transport and application layer protocols running inside the VPN tunnel are unaware of the outer addresses or their status.
当考虑基本的MOBIKE VPN场景时，答案是否定的。在VPN隧道内运行的传输层和应用层协议不知道外部地址或它们的状态。
Similarly, IP-layer tunnel termination at a gateway rather than a host endpoint limits the benefits for "other protocols" that could be informed -- all application protocols at the other side are unaware of IPsec, IKE, or MOBIKE.
类似地，IP层隧道终止于网关而非主机端点限制了可以通知的“其他协议”的好处——另一端的所有应用程序协议都不知道IPsec、IKE或MOBIKE。
However, it is conceivable that future uses or extensions of the MOBIKE protocol make such information distribution useful. For instance, if transport mode MOBIKE and SCTP were made to work together, it would potentially be useful for SCTP dynamic address reconfiguration [WIP-Ste06] to learn about the new addresses at the same time as MOBIKE. Similarly, various IP-layer mechanisms may make use of the fact that a return routability check of a specific type has been performed. However, care should be exercised in all these situations.
然而，可以想象，MOBIKE协议的未来使用或扩展使这种信息分发变得有用。例如，如果让传输模式MOBIKE和SCTP一起工作，那么SCTP动态地址重新配置[WIP-Ste06]在了解MOBIKE的同时了解新地址可能会很有用。类似地，各种IP层机制可以利用已执行特定类型的返回路由性检查这一事实。然而，在所有这些情况下都应谨慎行事。
[WIP-Cro04] discusses the use of common locator information pools in a IPv6 multi-homing context; it assumes that both transport and IP-layer solutions are used in order to support multi-homing, and that it would be beneficial for different protocols to coordinate their results in some way, for instance, by sharing throughput information of address pairs. This may apply to MOBIKE as well, assuming it coexists with non-IPsec protocols that are faced with the same or similar multi-homing choices.
[WIP-Cro04]讨论了公共定位器信息池在IPv6多主环境中的使用；它假设使用传输层和IP层解决方案来支持多归属，并且不同的协议以某种方式协调其结果将是有益的，例如，通过共享地址对的吞吐量信息。这也适用于MOBIKE，假设它与面临相同或类似多宿主选择的非IPsec协议共存。
Nevertheless, all of this is outside the scope of the current MOBIKE base protocol design and may be addressed in future work.
然而，所有这些都超出了当前MOBIKE基本协议设计的范围，可能会在未来的工作中解决。
If the return routability check fails, we need to tear down the IKE SA if we are using IKEv2 INFORMATIONAL exchanges to send return routability checks. On the other hand, return routability checks can only fail permanently if there was an attack by the other end; thus, tearing down the IKE SA is a suitable action in that case.
如果返回可路由性检查失败，如果使用IKEv2信息交换发送返回可路由性检查，则需要拆除IKE SA。另一方面，只有在另一端发生攻击时，返回路由性检查才能永久失败；因此，在这种情况下，拆除IKE SA是合适的操作。
There are some cases, where the return routability check temporarily fails, that need to be considered here. In the first case, there is no attacker, but the selected address pair stops working immediately after the address update, before the return routability check.
有些情况下，返回可路由性检查暂时失败，需要在此处加以考虑。在第一种情况下，没有攻击者，但所选地址对在地址更新后，即返回可路由性检查之前立即停止工作。
What happens is that the initiator performs the normal address update; it succeeds, and then the responder starts a return routability check. If the address pair has broken down before that, the responder will never get back the reply to the return routability
发生的情况是启动器执行正常的地址更新；它成功，然后响应程序开始返回可路由性检查。如果地址对在此之前发生故障，响应者将永远无法获得返回路由的回复
check. The responder might still be using the old IP address pair, which could still work.
检查响应程序可能仍在使用旧的IP地址对，这仍然可以工作。
The initiator might be still seeing traffic from the responder, but using the old address pair. The initiator should detect that this traffic is not using the latest address pair, and after a while it should start dead peer detection on the current address pair. If that fails, then it should find a new working address pair and update addresses to that. The responder should notice that the address pair was updated after the return routability check was started and change the ongoing return routability check to use the new address pair. The result of that return routability check needs to be discarded as it cannot be trusted; the packets were retransmitted to a different IP address. So normally the responder starts a new return routability check afterward with the new address pair.
发起方可能仍然看到来自响应方的通信量，但使用的是旧地址对。启动器应检测到该通信量未使用最新地址对，并在一段时间后对当前地址对启动死对等检测。如果失败，那么它应该找到一个新的工作地址对，并更新地址。响应者应该注意到地址对在返回可路由性检查启动后被更新，并将正在进行的返回可路由性检查更改为使用新的地址对。返回可路由性检查的结果需要丢弃，因为它不可信；数据包被重新传输到不同的IP地址。因此，通常响应程序在新地址对之后开始新的返回路由性检查。
The second case is where there is an attacker along the path modifying the IP addresses. The peers will detect this as NAT and will enable NAT-T recovery of changes in the NAT mappings. If the attacker is along the path long enough for the return routability check to succeed, then the normal recovery of changes in the NAT mappings will take care of the problem. If the attacker disappears before return routability check is finished, but after the update, we have a case similar to the last. The only difference is that now the dead peer detection started by the initiator will succeed because the responder will reply to the addresses in the headers, not the current address pair. The initiator will then detect that the NAT mappings are changed, and it will fix the situation by doing an address update.
第二种情况是，攻击者沿着路径修改IP地址。对等方会将其检测为NAT，并启用NAT-T恢复NAT映射中的更改。如果攻击者在路径上停留的时间足以使返回路由性检查成功，则NAT映射中更改的正常恢复将解决问题。如果攻击者在返回可路由性检查完成之前消失，但在更新之后，我们的情况与上次类似。唯一的区别是，现在由启动器启动的死点检测将成功，因为响应程序将回复头中的地址，而不是当前地址对。然后，启动器将检测到NAT映射已更改，并通过执行地址更新来修复这种情况。
The important thing for both of these cases is that the initiator needs to see that the responder is both alive and synchronized with initiator address pair updates. That is, it is not enough that the responder is sending traffic to an initiator; it must also be using the correct IP addresses before the initiator can believe it is alive and synchronized. From the implementation point of view, this means that the initiator must not consider packets having wrong IP addresses as packets that prove the other end is alive, i.e., they do not reset the dead peer detection timers.
对于这两种情况，重要的是启动器需要看到响应程序处于活动状态，并且与启动器地址对更新同步。也就是说，响应者向发起方发送通信量是不够的；它还必须使用正确的IP地址，启动器才能相信它处于活动状态并已同步。从实施的角度来看，这意味着发起方不必考虑具有错误IP地址的分组作为证明另一端是活的分组，即，它们不重置死的对等检测计时器。
The working group selected to use IKEv2 INFORMATIONAL exchanges as a return routability check, but included a random cookie to prevent redirection by an authenticated attacker. Return routability checks are performed by default before moving the traffic. However, these tests are optional. Nodes may also perform these tests upon their own initiative at other times.
工作组选择使用IKEv2信息交换作为返回可路由性检查，但包括一个随机cookie，以防止经过身份验证的攻击者重定向。默认情况下，在移动流量之前执行返回路由性检查。但是，这些测试是可选的。节点也可以在其他时间主动执行这些测试。
It is worth noting that the return routability check in MOBIKE is different from Mobile IPv6 [RFC3775], which does not perform return routability operations between the mobile node and its home agent at all.
值得注意的是，MOBIKE中的返回路由性检查与移动IPv6[RFC3775]不同，后者根本不执行移动节点与其归属代理之间的返回路由性操作。
The current MOBIKE design is focused only on the VPN type usage and tunnel mode. Transport mode behavior would also be useful and might be discussed in future documents.
当前的MOBIKE设计只关注VPN类型的使用和隧道模式。传输模式行为也很有用，可能会在将来的文档中讨论。
In order for MOBIKE to function, both peers must implement the MOBIKE extension of IKEv2. If one of the peers does not support MOBIKE, then, whenever an IP address changes, IKEv2 will have to be re-run in order to create a new IKE SA and the respective IPsec SAs. In MOBIKE, a peer needs to be confident that its address change messages are understood by the other peer. If these messages are not understood, it is possible that connectivity between the peers is lost.
为了让MOBIKE正常工作，两个对等方都必须实现IKEv2的MOBIKE扩展。如果其中一个对等方不支持MOBIKE，则每当IP地址更改时，都必须重新运行IKEv2以创建新的IKE SA和相应的IPsec SA。在MOBIKE中，一个对等方需要确信其地址更改消息被另一个对等方理解。如果不理解这些消息，则可能会丢失对等点之间的连接。
One way to ensure that a peer receives feedback on whether its messages are understood by the other peer is to use IKEv2 messaging for MOBIKE and to mark some messages as "critical". According to the IKEv2 specification, either such messages have to be understood by the receiver, or an error message has to be returned to the sender.
确保一个对等方收到关于其消息是否被另一个对等方理解的反馈的一种方法是对MOBIKE使用IKEv2消息，并将一些消息标记为“关键”。根据IKEv2规范，接收方必须理解此类消息，或者必须将错误消息返回给发送方。
A second way to ensure receipt of the above-mentioned feedback is by using Vendor ID payloads that are exchanged during the initial IKEv2 exchange. These payloads would then indicate whether or not a given peer supports the MOBIKE protocol.
确保收到上述反馈的第二种方法是使用初始IKEv2交换期间交换的供应商ID有效载荷。然后，这些有效载荷将指示给定对等方是否支持MOBIKE协议。
A third approach would use the Notify payload to indicate support of MOBIKE extension. Such Notify payloads are also used for indicating NAT traversal support (via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads).
第三种方法将使用Notify有效负载来表示对MOBIKE扩展的支持。此类通知有效负载还用于指示NAT遍历支持（通过NAT_检测、源IP和NAT_检测、目的IP有效负载）。
Both a Vendor ID and a Notify payload may be used to indicate the support of certain extensions.
供应商ID和Notify有效负载都可用于指示对某些扩展的支持。
Note that a MOBIKE peer could also attempt to execute MOBIKE opportunistically with the critical bit set when an address change has occurred. The drawback of this approach is, however, that an unnecessary message exchange is introduced.
请注意，当发生地址更改时，MOBIKE对等方还可以尝试利用设置的关键位机会主义地执行MOBIKE。然而，这种方法的缺点是引入了不必要的消息交换。
Although Vendor ID payloads and Notify payloads are technically equivalent, Notify payloads are already used in IKEv2 as a capability negotiation mechanism. Hence, Notify payloads are used in MOBIKE to indicate support of MOBIKE protocol.
尽管供应商ID有效载荷和Notify有效载荷在技术上是等效的，但Notify有效载荷已在IKEv2中用作能力协商机制。因此，在MOBIKE中使用Notify有效负载来表示对MOBIKE协议的支持。
Also, as the information of the support of MOBIKE is not needed during the IKE_SA_INIT exchange, the indication of the support is done inside the IKE_AUTH exchange. The reason for this is the need to keep the IKE_SA_INIT messages as small as possible so that they do not get fragmented. IKEv2 allows that the responder can do stateless processing of the first IKE_SA_INIT packet and request a cookie from the other end if it is under attack. To mandate the responder to be able to reassemble initial IKE_SA_INIT packets would not allow fully stateless processing of the initial IKE_SA_INIT packets.
此外，由于在IKE_SA_INIT交换期间不需要MOBIKE支持的信息，因此支持的指示在IKE_AUTH交换内部完成。这样做的原因是需要将IKE_SA_INIT消息保持尽可能小，以便它们不会碎片化。IKEv2允许响应者对第一个IKE_SA_INIT数据包进行无状态处理，并在另一端受到攻击时请求cookie。若要求响应者能够重新组装初始IKE_SA_INIT数据包，则不允许对初始IKE_SA_INIT数据包进行完全无状态处理。
As IKEv2 has a window of outgoing messages, and the sender is not allowed to violate that window (meaning that if the window is full, then the sender cannot send packets), it can cause some complications to path testing. Another complication created by IKEv2 is that once the message is created and sent to the other end, it cannot be modified in its future retransmissions. This makes it impossible to know what packet actually reached the other end first. We cannot use IP headers to find out which packet reached the other end first because if the responder gets retransmissions of the packet it has already processed and replied to (and those replies might have been lost due unidirectional address pair), it will retransmit the previous reply using the new address pair of the request. Because of this, it might be possible that the responder has already used the IP address information from the header of the previous packet, and the reply packet ending up at the initiator has a different address pair.
由于IKEv2有一个传出消息窗口，并且不允许发送方违反该窗口（这意味着如果窗口已满，则发送方无法发送数据包），因此它可能会导致路径测试的一些复杂性。IKEv2造成的另一个复杂问题是，一旦消息被创建并发送到另一端，它就不能在将来的重传中被修改。这使得不可能知道什么数据包实际上首先到达了另一端。我们不能使用IP报头来找出哪个数据包首先到达了另一端，因为如果响应者获得了它已经处理和回复的数据包的重传（并且这些回复可能由于单向地址对而丢失），它将使用请求的新地址对重传先前的回复。因此，可能响应者已经使用了来自前一个分组的报头的IP地址信息，并且在发起方结束的应答分组具有不同的地址对。
Another complication comes from NAT-T. The current IKEv2 document says that if NAT-T is enabled, the node not behind NAT SHOULD detect if the IP address changes in the incoming authenticated packets and update the remote peers' addresses accordingly. This works fine with NAT-T, but it causes some complications in MOBIKE, as MOBIKE needs the ability to probe other address pairs without breaking the old one.
另一个复杂问题来自NAT-T。当前的IKEv2文档指出，如果启用了NAT-T，则NAT后面的节点应检测传入的经过身份验证的数据包中的IP地址是否发生了变化，并相应地更新远程对等方的地址。这在NAT-T中工作得很好，但在MOBIKE中会导致一些复杂情况，因为MOBIKE需要能够探测其他地址对而不破坏旧的地址对。
One approach to fix this would be to add a completely new protocol that is outside the IKE SA message id limitations (window code), outside identical retransmission requirements, and outside the dynamic address updating of NAT-T.
解决此问题的一种方法是添加一个全新的协议，该协议不受IKE SA消息id限制（窗口代码）、相同的重传要求以及NAT-T的动态地址更新的限制。
Another approach is to make the protocol so that it does not violate window restrictions and does not require changing the packet on retransmissions, and change the dynamic address updating of NAT-T to "MUST NOT" for IKE SA packets if MOBIKE is used. In order not to violate window restrictions, the addresses of the currently ongoing exchange need to be changed to test different paths. In order not to require that the packet be changed after it is first sent requires that the protocol restart from the beginning in case the packet was retransmitted to different addresses (because the sender does not know which packet the responder got first, i.e., which IP addresses it used).
另一种方法是使协议不违反窗口限制，并且不需要在重传时更改数据包，并且如果使用MOBIKE，则将IKE SA数据包的NAT-T的动态地址更新更改为“不得”。为了不违反窗口限制，需要更改当前正在进行的交换的地址以测试不同的路径。为了不要求在第一次发送后更改数据包，要求协议从头开始重新启动，以防数据包被重新传输到不同的地址（因为发送方不知道响应方首先获得了哪个数据包，即使用了哪个IP地址）。
The working group decided to use normal IKEv2 exchanges for path testing and decided to change the dynamic address updating of NAT-T to MUST NOT for IKE SA packets; a new protocol outside of IKEv2 was not adopted.
工作组决定使用普通IKEv2交换进行路径测试，并决定将NAT-T的动态地址更新更改为不得用于IKE SA数据包；IKEv2之外的新协议未被采纳。
The IP address change notifications can be sent either via an informational exchange already specified in IKEv2, or via a MOBIKE-specific message exchange. Using an informational exchange has the main advantage that it is already specified in the IKEv2 protocol and implementations can already incorporate the functionality.
IP地址更改通知可以通过IKEv2中已经指定的信息交换发送，也可以通过特定于MOBIKE的消息交换发送。使用信息交换的主要优点是它已经在IKEv2协议中指定，并且实现已经可以包含该功能。
Another question is the format of the address update notifications. The address update notifications can include multiple addresses, of which some may be IPv4 and some IPv6 addresses. The number of addresses is most likely going to be limited in typical environments (with less than 10 addresses). The format may need to indicate a preference value for each address. The format could either contain a preference number that determines the relative order of the addresses or could simply be an ordered list of IP addresses. If using preference numbers, then two addresses can have the same preference value; an ordered list avoids this situation.
另一个问题是地址更新通知的格式。地址更新通知可以包括多个地址，其中一些可能是IPv4地址，一些可能是IPv6地址。在典型环境中，地址的数量很可能会受到限制（少于10个地址）。格式可能需要指示每个地址的首选项值。该格式可以包含决定地址相对顺序的首选项编号，也可以只是IP地址的有序列表。如果使用首选项编号，则两个地址可以具有相同的首选项值；有序列表可以避免这种情况。
Load balancing is currently outside the scope of MOBIKE; however, future work might include support for it. The selected format needs to be flexible enough to include additional information in future versions of the protocol (e.g., to enable load balancing). This may be realized with an reserved field, which can later be used to store additional information. As other information may arise that may have to be tied to an address in the future, a reserved field seems like a prudent design in any case.
负载平衡目前不在MOBIKE的范围之内；然而，未来的工作可能包括对它的支持。所选格式需要足够灵活，以便在协议的未来版本中包含附加信息（例如，启用负载平衡）。这可以通过保留字段来实现，该字段稍后可用于存储附加信息。由于将来可能会出现与地址相关的其他信息，因此在任何情况下，保留字段似乎都是一种谨慎的设计。
There are two basic formats that place IP address lists into a message. One includes each IP address as separate payload (where the payload order indicates the preference order, or the payload itself
有两种基本格式可将IP地址列表放入消息中。一个包括每个IP地址作为单独的有效负载（其中有效负载顺序指示首选顺序，或有效负载本身）
might include the preference number). Alternatively, we can put the IP address list as one payload to the exchange, and that one payload will then have an internal format that includes the list of IP addresses.
可能包括首选项编号）。或者，我们可以将IP地址列表作为一个有效负载放在exchange中，然后该有效负载将具有包含IP地址列表的内部格式。
Having multiple payloads, each one carrying one IP address, makes the protocol probably easier to parse, as we can already use the normal IKEv2 payload parsing procedures. It also offers an easy way for the extensions, as the payload probably contains only the type of the IP address (or the type is encoded to the payload type), and the IP address itself. As each payload already has a length field associated to it, we can detect if there is any extra data after the IP address. Some implementations might have problems parsing more than a certain number of IKEv2 payloads, but if the sender sends them in the most preferred first, the receiver can only use the first addresses it was willing to parse.
拥有多个有效负载，每个负载携带一个IP地址，这使得协议可能更容易解析，因为我们已经可以使用正常的IKEv2有效负载解析过程。它还为扩展提供了一种简单的方法，因为有效负载可能只包含IP地址的类型（或者该类型被编码为有效负载类型）和IP地址本身。由于每个有效负载已经有一个与之关联的长度字段，因此我们可以检测IP地址之后是否有任何额外数据。一些实现可能在解析超过一定数量的IKEv2有效负载时遇到问题，但是如果发送方以最优先的方式发送它们，接收方只能使用它愿意解析的第一个地址。
Having all IP addresses in one big MOBIKE-specified internal format provides more compact encoding and keeps the MOBIKE implementation more concentrated to one module.
将所有IP地址放在一个大的MOBIKE指定的内部格式中可以提供更紧凑的编码，并使MOBIKE实现更集中于一个模块。
Another choice is which type of payloads to use. IKEv2 already specifies a Notify payload. It includes some extra fields (SPI size, SPI, protocol, etc.), which gives 4 bytes of the extra overhead, and there is the notification data field, which could include the MOBIKE-specific data.
另一个选择是使用哪种类型的有效载荷。IKEv2已经指定了通知有效负载。它包括一些额外的字段（SPI大小、SPI、协议等），这些字段提供了4字节的额外开销，还有通知数据字段，其中可能包含MOBIKE特定的数据。
Another option would be to have a custom payload type, which would then include the information needed for the MOBIKE protocol.
另一个选择是拥有一个定制的有效负载类型，它将包含MOBIKE协议所需的信息。
The working group decided to use IKEv2 Notify payloads, and put only one data item per notify. There will be one Notify payload for each item to be sent.
工作组决定使用IKEv2 Notify有效负载，并且每个Notify只放置一个数据项。每个要发送的项目将有一个Notify有效负载。
Because the initiator decides all address updates, the initiator needs to know all the addresses used by the responder. The responder also needs that list in case it happens to move to an address not known by the initiator, and it needs to send an address update notification to the initiator. It might need to try different addresses for the initiator.
因为发起方决定所有地址更新，所以发起方需要知道响应方使用的所有地址。响应者还需要该列表，以防它恰好移动到发起者不知道的地址，并且它需要向发起者发送地址更新通知。它可能需要尝试启动器的不同地址。
MOBIKE could send the whole peer address list every time any of the IP addresses change (addresses are added or removed, the order changes, or the preferred address is updated) or an incremental update. Sending incremental updates provides more compact packets (meaning we can support more IP addresses), but on the other hand
MOBIKE可以在每次IP地址更改（添加或删除地址、更改顺序或更新首选地址）或增量更新时发送整个对等地址列表。发送增量更新提供了更紧凑的数据包（这意味着我们可以支持更多的IP地址），但另一方面
this approach has more problems in the synchronization and packet reordering cases. That is, incremental updates must be processed in order, but for full updates we can simply use the most recent one and ignore old ones, even if they arrive after the most recent one (IKEv2 packets have a message ID that is incremented for each packet; thus, it is easy to know the sending order).
这种方法在同步和数据包重新排序的情况下有更多的问题。也就是说，增量更新必须按顺序处理，但对于完整更新，我们可以简单地使用最新的更新，忽略旧的更新，即使它们在最新的更新之后到达（IKEv2数据包的消息ID为每个数据包递增；因此，很容易知道发送顺序）。
The working group decided to use a protocol format where both ends send a full list of their addresses to the other end, and that list overwrites the previous list. To support NAT-T, the IP addresses of the received packet are considered as one address of the peer, even when they are not present in the list.
工作组决定使用一种协议格式，其中两端向另一端发送其地址的完整列表，该列表覆盖了先前的列表。为了支持NAT-T，接收数据包的IP地址被视为对等方的一个地址，即使它们不在列表中。
As all the packets are already authenticated by IKEv2, there is no risk that any attackers would undetectedly modify the contents of the packets. The IP addresses in the IP header of the packets are not authenticated; thus, the protocol defined must take care that they are only used as an indication that something might be different, and that they do not cause any direct actions, except when doing NAT traversal.
由于所有数据包都已通过IKEv2的身份验证，因此任何攻击者都不会不知不觉地修改数据包的内容。分组的IP报头中的IP地址未经认证；因此，所定义的协议必须注意，它们仅用于指示某些内容可能不同，并且它们不会导致任何直接操作，除非在进行NAT遍历时。
An attacker can also spoof ICMP error messages in an effort to confuse the peers about which addresses are not working. At worst, this causes denial of service and/or the use of non-preferred addresses.
攻击者还可以伪造ICMP错误消息，试图混淆对等方哪些地址不工作。在最坏的情况下，这会导致拒绝服务和/或使用非首选地址。
One type of attack that needs to be taken care of in the MOBIKE protocol is the bombing attack type. See [RFC4225] and [Aur02] for more information about flooding attacks.
MOBIKE协议中需要注意的一种攻击类型是轰炸攻击类型。有关洪水攻击的更多信息，请参阅[RFC4225]和[Aur02]。
See the security considerations section of [RFC4555] for more information about security considerations of the actual protocol.
有关实际协议的安全注意事项的更多信息，请参阅[RFC4555]的安全注意事项部分。
This document is the result of discussions in the MOBIKE working group. The authors would like to thank Jari Arkko, Pasi Eronen, Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, Udo Schilcher, Tom Henderson, Andreas Pashalidis, and Maureen Stillman for their input.
本文件是MOBIKE工作组讨论的结果。作者要感谢贾里·阿尔科、帕西·埃隆、弗朗西斯·杜邦、莫汉·帕塔萨拉西、保罗·霍夫曼、比尔·索末菲、詹姆斯·坎普夫、维杰·德瓦拉帕利、阿图尔·夏尔马、博拉·阿约尔、乔·图奇、乌多·席尔谢尔、汤姆·亨德森、安德烈亚斯·帕沙利迪斯和莫林·斯蒂尔曼的投入。
We would like to particularly thank Pasi Eronen for tracking open issues on the MOBIKE mailing list. He helped us make good progress on the document.
我们要特别感谢Pasi Eronen跟踪MOBIKE邮件列表上的未决问题。他帮助我们在文件上取得了良好的进展。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", In Proc. 18th Annual Computer Security Applications Conference, pages 78-87, Las Vegas, NV USA, December 2002.
[Aur02]Aura，T.，Roe，M.，和J.Arkko，“互联网位置管理的安全”，在Proc。第18届计算机安全应用年会，第78-87页，美国内华达州拉斯维加斯，2002年12月。
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367]McDonald，D.，Metz，C.，和B.Phan，“PF_密钥管理API，版本2”，RFC 2367，1998年7月。
[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月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[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月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC3303]Srisuresh，P.，Kuthan，J.，Rosenberg，J.，Molitor，A.，和A.Rayhan，“中间箱通信架构和框架”，RFC 33032002年8月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC3554]Bellovin，S.，Ioannidis，J.，Keromytis，A.，和R.Stewart，“关于流控制传输协议（SCTP）与IPsec的使用”，RFC 3554，2003年7月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[RFC4225]Nikander，P.，Arkko，J.，Aura，T.，黑山，G.，和E.Nordmark，“移动IP版本6路由优化安全设计背景”，RFC 42252005年12月。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[RFC4429]Moore，N.，“IPv6的乐观重复地址检测（DAD）”，RFC4429，2006年4月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC4555，2006年6月。
[WIP-Ark06] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Work in Progress, June 2006.
[WIP-Ark06]Arkko，J.和I.Beijnum，“IPv6多宿的故障检测和定位对探测协议”，正在进行的工作，2006年6月。
[WIP-Cro04] Crocker, D., "Framework for Common Endpoint Locator Pools", Work in Progress, February 2004.
[WIP-Cro04]Crocker，D.，“公共端点定位器池框架”，正在进行的工作，2004年2月。
[WIP-Nik06] Nikander, P., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, June 2006.
[WIP-Nik06]Nikander，P.，“使用主机身份协议的终端主机移动性和多宿主”，正在进行的工作，2006年6月。
[WIP-Ste06] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Work in Progress, June 2006.
[WIP-Ste06]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）动态地址重新配置”，正在进行的工作，2006年6月。
[WIP-Sti06] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, June 2006.
[WIP-Sti06]Stiemerling，M.，Tschofenig，H.，Aoun，C.，和E.Davies，“NAT/防火墙NSIS信令层协议（NSLP）”，正在进行的工作，2006年6月。
Authors' Addresses
作者地址
Tero Kivinen Safenet, Inc. Fredrikinkatu 47 HELSINKI FI-00100 FI
Tero Kivinen Safenet，Inc.Fredrikinkatu 47赫尔辛基FI-00100 FI
EMail: kivinen@safenet-inc.com
EMail: kivinen@safenet-inc.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
德国巴伐利亚州慕尼黑第6环汉内斯·茨霍芬尼西门子奥托·哈恩81739
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.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）提供。