Network Working Group J. Arkko
Request for Comments: 3776 Ericsson
Category: Standards Track V. Devarapalli
Nokia Research Center
F. Dupont
GET/ENST Bretagne
June 2004
Network Working Group J. Arkko
Request for Comments: 3776 Ericsson
Category: Standards Track V. Devarapalli
Nokia Research Center
F. Dupont
GET/ENST Bretagne
June 2004
Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents
使用IPsec保护移动节点和归属代理之间的移动IPv6信令
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
移动IPv6使用IPsec保护归属代理和移动节点之间的信令。移动IPv6基本文档定义了这些节点必须遵循的主要要求。本文档更深入地讨论了这些需求，说明了使用的数据包格式，描述了合适的配置过程，并展示了实现如何以正确的顺序处理数据包。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Binding Updates and Acknowledgements . . . . . . . . . 5
3.2 Return Routability Signaling . . . . . . . . . . . . . 7
3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 8
3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 10
4.2 Policy Requirements . . . . . . . . . . . . . . . . . 10
4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 13
4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 15
5. Example Configurations . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Binding Updates and Acknowledgements . . . . . . . . . 5
3.2 Return Routability Signaling . . . . . . . . . . . . . 7
3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 8
3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 10
4.2 Policy Requirements . . . . . . . . . . . . . . . . . 10
4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 13
4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 15
5. Example Configurations . . . . . . . . . . . . . . . . . . . 16
5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Manual Configuration . . . . . . . . . . . . . . . . . 18
5.2.1 Binding Updates and Acknowledgements . . . . . . 18
5.2.2 Return Routability Signaling . . . . . . . . . . 19
5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 20
5.2.4 Payload Packets . . . . . . . . . . . . . . . . 21
5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Binding Updates and Acknowledgements . . . . . . 22
5.3.2 Return Routability Signaling . . . . . . . . . . 23
5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 24
5.3.4 Payload Packets . . . . . . . . . . . . . . . . 25
6. Processing Steps within a Node . . . . . . . . . . . . . . . 25
6.1 Binding Update to the Home Agent . . . . . . . . . . . 25
6.2 Binding Update from the Mobile Node . . . . . . . . . 26
6.3 Binding Acknowledgement to the Mobile Node . . . . . . 27
6.4 Binding Acknowledgement from the Home Agent . . . . . 28
6.5 Home Test Init to the Home Agent . . . . . . . . . . . 29
6.6 Home Test Init from the Mobile Node . . . . . . . . . 30
6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 30
6.8 Home Test from the Home Agent . . . . . . . . . . . . 31
6.9 Prefix Solicitation Message to the Home Agent . . . . 31
6.10 Prefix Solicitation Message from the Mobile Node . . . 31
6.11 Prefix Advertisement Message to the Mobile Node . . . 32
6.12 Prefix Advertisement Message from the Home Agent . . . 32
6.13 Payload Packet to the Home Agent . . . . . . . . . . . 32
6.14 Payload Packet from the Mobile Node . . . . . . . . . 32
6.15 Payload Packet to the Mobile Node . . . . . . . . . . 32
6.16 Payload Packet from the Home Agent . . . . . . . . . . 32
6.17 Establishing New Security Associations . . . . . . . . 32
6.18 Rekeying Security Associations . . . . . . . . . . . . 33
6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 34
7. Implementation Considerations . . . . . . . . . . . . . . . 35
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 IKE . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3 Bump-in-the-Stack . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . 37
10 References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1 Normative References . . . . . . . . . . . . . . . . . 38
10.2 Informative References . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 40
5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Manual Configuration . . . . . . . . . . . . . . . . . 18
5.2.1 Binding Updates and Acknowledgements . . . . . . 18
5.2.2 Return Routability Signaling . . . . . . . . . . 19
5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 20
5.2.4 Payload Packets . . . . . . . . . . . . . . . . 21
5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Binding Updates and Acknowledgements . . . . . . 22
5.3.2 Return Routability Signaling . . . . . . . . . . 23
5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 24
5.3.4 Payload Packets . . . . . . . . . . . . . . . . 25
6. Processing Steps within a Node . . . . . . . . . . . . . . . 25
6.1 Binding Update to the Home Agent . . . . . . . . . . . 25
6.2 Binding Update from the Mobile Node . . . . . . . . . 26
6.3 Binding Acknowledgement to the Mobile Node . . . . . . 27
6.4 Binding Acknowledgement from the Home Agent . . . . . 28
6.5 Home Test Init to the Home Agent . . . . . . . . . . . 29
6.6 Home Test Init from the Mobile Node . . . . . . . . . 30
6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 30
6.8 Home Test from the Home Agent . . . . . . . . . . . . 31
6.9 Prefix Solicitation Message to the Home Agent . . . . 31
6.10 Prefix Solicitation Message from the Mobile Node . . . 31
6.11 Prefix Advertisement Message to the Mobile Node . . . 32
6.12 Prefix Advertisement Message from the Home Agent . . . 32
6.13 Payload Packet to the Home Agent . . . . . . . . . . . 32
6.14 Payload Packet from the Mobile Node . . . . . . . . . 32
6.15 Payload Packet to the Mobile Node . . . . . . . . . . 32
6.16 Payload Packet from the Home Agent . . . . . . . . . . 32
6.17 Establishing New Security Associations . . . . . . . . 32
6.18 Rekeying Security Associations . . . . . . . . . . . . 33
6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 34
7. Implementation Considerations . . . . . . . . . . . . . . . 35
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 IKE . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3 Bump-in-the-Stack . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . 37
10 References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1 Normative References . . . . . . . . . . . . . . . . . 38
10.2 Informative References . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 40
This document illustrates the use of IPsec in securing Mobile IPv6 [7] traffic between mobile nodes and home agents. In Mobile IPv6, a mobile node is always expected to be addressable at its home address, whether it is currently attached to its home link or is away from home. The "home address" is an IP address assigned to the mobile node within its home subnet prefix on its home link. While a mobile node is at home, packets addressed to its home address are routed to the mobile node's home link.
本文档说明了如何使用IPsec保护移动节点和归属代理之间的移动IPv6[7]流量。在移动IPv6中，无论移动节点当前连接到其家庭链路还是远离家庭，都希望移动节点能够在其家庭地址进行寻址。“家庭地址”是在其家庭链路上的家庭子网前缀内分配给移动节点的IP地址。当移动节点在家时，发往其家地址的数据包被路由到移动节点的家链路。
While a mobile node is attached to some foreign link away from home, it is also addressable at a care-of address. A care-of address is an IP address associated with a mobile node that has a subnet prefix from a particular foreign link. The association between a mobile node's home address and care-of address is known as a "binding" for the mobile node. While away from home, a mobile node registers its primary care-of address with a router on its home link, requesting this router to function as the "home agent" for the mobile node. The mobile node performs this binding registration by sending a "Binding Update" message to the home agent. The home agent replies to the mobile node by returning a "Binding Acknowledgement" message.
当移动节点连接到远离家乡的某个外部链路时，它也可以在转交地址处寻址。转交地址是与具有来自特定外部链路的子网前缀的移动节点相关联的IP地址。移动节点的家庭地址和转交地址之间的关联称为移动节点的“绑定”。离开家时，移动节点向其家庭链路上的路由器注册其主要照顾地址，请求该路由器充当移动节点的“家庭代理”。移动节点通过向归属代理发送“绑定更新”消息来执行该绑定注册。归属代理通过返回“绑定确认”消息来回复移动节点。
Any other nodes communicating with a mobile node are referred to as "correspondent nodes". Mobile nodes can provide information about their current location to correspondent nodes, again using Binding Updates and Acknowledgements. Additionally, return routability test is performed between the mobile node, home agent, and the correspondent node in order to authorize the establishment of the binding. Packets between the mobile node and the correspondent node are either tunneled via the home agent, or sent directly if a binding exists in the correspondent node for the current location of the mobile node.
与移动节点通信的任何其他节点被称为“对应节点”。移动节点可以再次使用绑定更新和确认，向对应节点提供有关其当前位置的信息。此外，在移动节点、归属代理和对应节点之间执行返回路由性测试，以授权绑定的建立。移动节点和对应节点之间的分组要么通过归属代理进行隧道传输，要么在对应节点中存在移动节点当前位置的绑定时直接发送。
Mobile IPv6 tunnels payload packets between the mobile node and the home agent in both directions. This tunneling uses IPv6 encapsulation [6]. Where these tunnels need to be secured, they are replaced by IPsec tunnels [2].
移动IPv6在移动节点和归属代理之间双向传输有效负载数据包。此隧道使用IPv6封装[6]。在需要保护这些隧道的地方，它们被IPsec隧道所取代[2]。
Mobile IPv6 also provides support for the reconfiguration of the home network. Here, the home subnet prefixes may change over time. Mobile nodes can learn new information about home subnet prefixes through the "prefix discovery" mechanism.
移动IPv6还支持家庭网络的重新配置。在这里，主子网前缀可能会随时间而变化。移动节点可以通过“前缀发现”机制了解有关家庭子网前缀的新信息。
This document discusses security mechanisms for the control traffic between the mobile node and the home agent. If this traffic is not protected, mobile nodes and correspondent nodes are vulnerable to man-in-the-middle, hijacking, passive wiretapping, impersonation, and
本文档讨论了移动节点和归属代理之间控制流量的安全机制。如果该通信量未得到保护，移动节点和对应节点容易受到中间人、劫持、被动窃听、模拟和攻击的攻击
denial-of-service attacks. Any third parties are also vulnerable to denial-of-service attacks, for instance if an attacker could direct the traffic flowing through the home agent to a innocent third party. These attacks are discussed in more detail in Section 15.1 of the Mobile IPv6 base specification [7].
拒绝服务攻击。任何第三方也容易受到拒绝服务攻击，例如，如果攻击者可以将流经home agent的流量指向无辜的第三方。移动IPv6基本规范[7]第15.1节详细讨论了这些攻击。
In order to avoid these attacks, the base specification uses IPsec Encapsulating Security Payload (ESP) [3] to protect control traffic between the home agent and the mobile node. This control traffic consists of various messages carried by the Mobility Header protocol in IPv6 [5]. The traffic takes the following forms:
为了避免这些攻击，基本规范使用IPsec封装安全有效负载（ESP）[3]来保护归属代理和移动节点之间的控制流量。此控制流量由IPv6中的移动报头协议承载的各种消息组成[5]。交通采用以下形式：
o Binding Update and Acknowledgement messages exchanged between the mobile node and the home agent, as described in Sections 10.3.1, 10.3.2, 11.7.1, and 11.7.3 of the base specification [7].
o 移动节点和归属代理之间交换的绑定更新和确认消息，如基本规范第10.3.1、10.3.2、11.7.1和11.7.3节所述[7]。
o Return routability messages Home Test Init and Home Test that pass through the home agent on their way to a correspondent node, as described in Section 10.4.6 of the base specification [7].
o 如基本规范[7]第10.4.6节所述，返回路由性消息Home Test Init和Home Test，这些消息通过Home agent到达对应节点。
o ICMPv6 messages exchanged between the mobile node and the home agent for the purposes of prefix discovery, as described in Sections 10.6 and 11.4 of the base specification [7].
o 如基本规范[7]第10.6节和第11.4节所述，移动节点和归属代理之间为了前缀发现而交换的ICMPv6消息。
The nodes may also optionally protect payload traffic passing through the home agent, as described in Section 5.5 of the base specification [7]. If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection support is required.
如基本规范[7]第5.5节所述，节点还可以选择性地保护通过归属代理的有效负载流量。如果支持多播组成员控制协议或有状态地址自动配置协议，则需要负载数据保护支持。
The control traffic between the mobile node and the home agent requires message authentication, integrity, correct ordering and anti-replay protection. The mobile node and the home agent must have an IPsec security association to protect this traffic. IPsec does not proving correct ordering of messages. Correct ordering of the control traffic is ensured by a sequence number in the Binding Update and Binding Acknowledgement messages. The sequence number in the Binding Updates also provides protection to a certain extent. It fails in some scenarios, for example, if the Home Agent loses the Binding Cache state. Full protection against replay attacks is possible only when IKE is used.
移动节点和归属代理之间的控制流量需要消息身份验证、完整性、正确排序和防重放保护。移动节点和归属代理必须具有IPsec安全关联才能保护此流量。IPsec无法证明消息的顺序正确。绑定更新和绑定确认消息中的序列号确保了控制流量的正确顺序。绑定更新中的序列号也在一定程度上提供了保护。它在某些情况下失败，例如，如果归属代理丢失绑定缓存状态。只有在使用IKE时，才能对重播攻击提供全面保护。
Great care is needed when using IKE [4] to establish security associations to Mobile IPv6 home agents. The right kind of addresses must be used for transporting IKE. This is necessary to avoid circular dependencies in which the use of a Binding Update triggers the need for an IKE exchange that cannot complete prior to the Binding Update having been completed.
在使用IKE[4]与移动IPv6家庭代理建立安全关联时，需要非常小心。传输IKE必须使用正确类型的地址。这对于避免循环依赖是必要的，在循环依赖中，绑定更新的使用会触发对IKE交换的需要，而IKE交换在绑定更新完成之前无法完成。
The mobile IPv6 base document defines the main requirements the mobile nodes and home agents must follow when securing the above traffic. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
移动IPv6基本文档定义了移动节点和归属代理在保护上述流量时必须遵循的主要要求。本文档更深入地讨论了这些需求，说明了使用的数据包格式，描述了合适的配置过程，并展示了实现如何以正确的顺序处理数据包。
We begin our description by showing the required wire formats for the protected packets in Section 3. Section 4 describes rules which associated Mobile IPv6, IPsec, and IKE implementations must observe. Section 5 discusses how to configure either manually keyed IPsec security associations or how to configure IKE to establish them automatically. Section 6 shows examples of how packets are processed within the nodes.
在第3节中，我们首先展示了受保护数据包所需的有线格式。第4节描述了关联的移动IPv6、IPsec和IKE实现必须遵守的规则。第5节讨论如何配置手动键控的IPsec安全关联，或者如何配置IKE以自动建立它们。第6节显示了如何在节点内处理数据包的示例。
All implementations of Mobile IPv6 mobile node and home agent MUST support at least the formats described in Section 3 and obey the rules in Section 4.
移动IPv6移动节点和归属代理的所有实现必须至少支持第3节中描述的格式，并遵守第4节中的规则。
The configuration and processing sections are informative, and should only be considered as one possible way of providing the required functionality.
配置和处理部分是信息性的，只应被视为提供所需功能的一种可能方式。
Note that where this document indicates a feature MUST be supported and SHOULD be used, this implies that all implementations must be capable of using the specified feature, but there may be cases where, for instance, a configuration option disables to use of the feature in a particular situation.
请注意，如果本文档指出必须支持并应使用某个功能，这意味着所有实现都必须能够使用指定的功能，但在某些情况下，例如，配置选项可能会禁用在特定情况下使用该功能。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
When the mobile node is away from its home, the BUs sent by it to the home agent MUST support at least the following headers in the following order:
当移动节点不在其家中时，由其发送到归属代理的总线必须按照以下顺序至少支持以下报头：
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header in transport mode
IPv6标头（源=转交地址，目的地=归属代理）目的地选项标头传输模式下的归属地址选项（归属地址）ESP标头
Mobility header Binding Update Alternate Care-of Address option (care-of address)
移动性标头绑定更新替代转交地址选项（转交地址）
Note that the Alternate Care-of Address option is used to ensure that the care-of address is protected by ESP. The home agent considers the address within this option as the current care-of address for the mobile node. The home address is not protected by ESP directly, but the use of a specific home address with a specific security association is required by policy.
请注意，备用转交地址选项用于确保转交地址受ESP保护。归属代理将此选项中的地址视为移动节点的当前转交地址。家庭地址不受ESP直接保护，但策略要求使用具有特定安全关联的特定家庭地址。
The Binding Acknowledgements sent back to the mobile node when it is away from home MUST support at least the following headers in the following order:
当移动节点不在家时，发送回移动节点的绑定确认必须按照以下顺序至少支持以下标头：
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header in transport mode Mobility header Binding Acknowledgement
IPv6标头（源=归属代理，目标=转交地址）路由标头（类型2）传输模式下的归属地址ESP标头移动标头绑定确认
When the mobile node is at home, the above rules are different as the mobile node can use its home address as a source address. This typically happens for the de-registration Binding Update when the mobile is returning home. In this situation, the Binding Updates MUST support at least the following headers in the following order:
当移动节点在家中时，上述规则不同，因为移动节点可以使用其家庭地址作为源地址。这通常发生在移动设备回家时的取消注册绑定更新中。在这种情况下，绑定更新必须按以下顺序至少支持以下标头：
IPv6 header (source = home address, destination = home agent) ESP header in transport mode Mobility header Binding Update
IPv6标头（源=家庭地址，目标=家庭代理）ESP标头处于传输模式移动标头绑定更新
The Binding Acknowledgement messages sent to the home address MUST support at least the following headers in the following order:
发送到家庭地址的绑定确认消息必须按照以下顺序至少支持以下标头：
IPv6 header (source = home agent, destination = home address) ESP header in transport mode Mobility header Binding Acknowledgement
传输模式下的IPv6标头（源=归属代理，目标=归属地址）ESP标头移动标头绑定确认
When the Home Test Init messages tunneled to the home agent are protected by IPsec, they MUST support at least the following headers in the following order:
当隧道传输到Home agent的Home Test Init消息受IPsec保护时，它们必须按照以下顺序至少支持以下标头：
IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = correspondent node) Mobility Header Home Test Init
IPv6标头（源=转交地址，目的地=归属代理）隧道模式下的ESP标头IPv6标头（源=归属地址，目的地=对应节点）移动性标头home Test Init
This format assumes that the mobile node's current care-of address is used as the outer header destination address in the security association. As discussed in Section 4.3, this requires the home agent to update the destination address when the mobile node moves. Policy entries and security association selectors stay the same, however, as the inner packets do not change upon movements.
此格式假定移动节点的当前转交地址用作安全关联中的外部报头目标地址。如第4.3节所述，这要求归属代理在移动节点移动时更新目的地地址。但是，策略条目和安全关联选择器保持不变，因为内部数据包在移动时不会改变。
Note that there are trade-offs in using care-of addresses as the destination addresses versus using the home address and attaching an additional Home Address destination option and/or Routing header to the packets. The basis for requiring support for at least the care-of address case has been discussed in Section 7.
请注意，使用转交地址作为目的地地址与使用家庭地址并向数据包附加附加家庭地址目的地选项和/或路由报头之间存在权衡。第7节讨论了要求至少为转交地址案件提供支持的依据。
Similarly, when the Home Test messages tunneled from the home agent are protected by IPsec, they MUST support at least the following headers in the following order:
类似地，当从归属代理隧道传输的归属测试消息受IPsec保护时，它们必须按照以下顺序至少支持以下标头：
IPv6 header (source = home agent, destination = care-of address) ESP header in tunnel mode IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test
IPv6标头（源=归属代理，目的地=转交地址）隧道模式下的ESP标头IPv6标头（源=对应节点，目的地=归属地址）移动性标头home Test
The format used to protect return routability packets relies on the destination of the tunnel packets to change for the mobile node as it moves. The home agent's address stays the same, but the mobile node's address changes upon movements, as if the security association's outer header destination address had changed. When the mobile node adopts a new care-of address, it adopts also a new source address for outgoing tunnel packets. The home agent accepts packets sent like this, as the outer source address in tunnel packets is not checked according to the rules in RFC 2401. (We note, however, that
用于保护返回路由性数据包的格式取决于移动节点在移动时要更改的隧道数据包的目的地。归属代理的地址保持不变，但移动节点的地址随着移动而改变，就好像安全关联的外部报头目的地地址已经改变一样。当移动节点采用一个新的转交地址时，它也为传出的隧道数据包采用一个新的源地址。归属代理接受这样发送的分组，因为没有根据RFC 2401中的规则检查隧道分组中的外部源地址。（然而，我们注意到
some implementations are known to make source address checks.) For a discussion of the role of source addresses in outer tunnel headers, see Section 5.1.2.1 of RFC 2401 [2]. Note also that the home agent requires the packets to be authenticated regardless of the source address change, hence the "new" sender must possess the same keys for the security association as it had in the previous location. This proves that the sender is the same entity, regardless of the changes in the addresses.
已知一些实现会进行源地址检查。）有关外部隧道头中源地址作用的讨论，请参阅RFC 2401[2]第5.1.2.1节。还请注意，归属代理要求对数据包进行身份验证，而不管源地址如何更改，因此“新”发送方必须拥有与前一位置相同的安全关联密钥。这证明了发送者是同一个实体，而不管地址如何变化。
The process is more complicated in the home agent side, as the home agent has stored the previous care-of address in its Security Association Database as the outer header destination address. When IKE is being used, the mobile node runs it on top of its current care-of address, and the resulting tunnel-mode security associations will use the same addresses as IKE run over. In order for the home agent to be able to tunnel a Home Test message to the mobile node, it uses the current care-of address as the destination of the tunnel packets, as if the home agent had modified the outer header destination address in the security association used for this protection. This implies that the same security association can be used in multiple locations, and no new configuration or re-establishment of IKE phases is needed per movement. Section 5.2.2 discusses the security policy and security association database entries that are needed to accomplish this.
在归属代理端，该过程更为复杂，因为归属代理已将先前的转交地址存储在其安全关联数据库中作为外部报头目标地址。当使用IKE时，移动节点在其当前转交地址上运行IKE，并且产生的隧道模式安全关联将使用与IKE run-over相同的地址。为了使归属代理能够将归属测试消息隧道到移动节点，它使用当前转交地址作为隧道分组的目的地，就好像归属代理已经修改了用于此保护的安全关联中的外部报头目的地地址一样。这意味着相同的安全关联可以在多个位置使用，并且每次移动都不需要新的配置或重建IKE阶段。第5.2.2节讨论了实现此目的所需的安全策略和安全关联数据库条目。
If IPsec is used to protect prefix discovery, requests for prefixes from the mobile node to the home agent MUST support at least the following headers in the following order.
如果IPsec用于保护前缀发现，则从移动节点到归属代理的前缀请求必须至少支持以下顺序的头。
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header in transport mode ICMPv6 Mobile Prefix Solicitation
IPv6标头（源=转交地址，目的地=归属代理）目的地选项标头归属地址选项（归属地址）传输模式下的ESP标头ICMPv6移动前缀请求
Again if IPsec is used, solicited and unsolicited prefix information advertisements from the home agent to the mobile node MUST support at least the following headers in the following order.
同样，如果使用IPsec，则从归属代理到移动节点的请求和非请求的前缀信息广告必须按照以下顺序至少支持以下报头。
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header in transport mode
IPv6标头（源=归属代理，目标=转交地址）路由标头（类型2）传输模式下的归属地址ESP标头
ICMPv6 Mobile Prefix Advertisement
ICMPv6移动前缀广告
If IPsec is used to protect payload packets tunneled to the home agent from the mobile node, we use a format similar to the one in Section 3.2. However, instead of the MobilityHeader, these packets may contain any legal IPv6 protocol(s):
如果IPsec用于保护从移动节点传输到归属代理的有效负载数据包，我们将使用类似于第3.2节的格式。但是，这些数据包可能包含任何合法的IPv6协议，而不是MobilityHeader：
IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = correspondent node) Any protocol
IPv6头（源=转交地址，目的地=归属代理）隧道模式下的ESP头IPv6头（源=归属地址，目的地=对应节点）任何协议
Similarly, when the payload packets are tunneled from the home agent to the mobile node with ESP encapsulation, they MUST support at least the following headers in the following order:
类似地，当使用ESP封装将有效负载数据包从归属代理隧道传输到移动节点时，它们必须按照以下顺序至少支持以下报头：
IPv6 header (source = home agent, destination = care-of address) ESP header in tunnel mode IPv6 header (source = correspondent node, destination = home address) Any protocol
IPv6头（源=归属代理，目标=转交地址）隧道模式下的ESP头IPv6头（源=对应节点，目标=归属地址）任何协议
This section describes mandatory rules for all Mobile IPv6 mobile nodes and home agents. These rules are necessary in order for it to be possible to enable IPsec communications despite movements, guarantee sufficient security, and to ensure correct processing order of packets.
本节介绍所有移动IPv6移动节点和归属代理的强制性规则。这些规则是必要的，以便能够在移动的情况下启用IPsec通信，保证足够的安全性，并确保数据包的正确处理顺序。
The rules in the following sections apply only to the communications between home agents and mobile nodes. They should not be taken as requirements on how IPsec in general is used by mobile nodes.
以下各节中的规则仅适用于归属代理和移动节点之间的通信。不应将它们视为移动节点通常如何使用IPsec的要求。
The following requirements apply to both home agents and mobile nodes:
以下要求适用于家庭代理和移动节点：
o Manual configuration of IPsec security associations MUST be supported. The configuration of the keys is expected to take place out-of-band, for instance at the time the mobile node is configured to use its home agent.
o 必须支持IPsec安全关联的手动配置。密钥的配置预期在带外进行，例如在移动节点被配置为使用其归属代理时。
o Automatic key management with IKE [4] MAY be supported. Only IKEv1 is discussed in this document. Other automatic key management mechanisms exist and will appear beyond IKEv1, but this document does not address the issues related to them.
o 可能支持IKE[4]的自动密钥管理。本文档仅讨论IKEv1。其他自动密钥管理机制已经存在，并将出现在IKEv1之外，但本文档并未解决与之相关的问题。
o ESP encapsulation of Binding Updates and Acknowledgements between the mobile node and home agent MUST be supported and MUST be used.
o 必须支持并使用移动节点和归属代理之间绑定更新和确认的ESP封装。
o ESP encapsulation of the Home Test Init and Home Test messages tunneled between the mobile node and home agent MUST be supported and SHOULD be used.
o 必须支持并使用在移动节点和归属代理之间隧道传输的归属测试初始化和归属测试消息的ESP封装。
o ESP encapsulation of the ICMPv6 messages related to prefix discovery MUST be supported and SHOULD be used.
o 必须支持并应使用与前缀发现相关的ICMPv6消息的ESP封装。
o ESP encapsulation of the payload packets tunneled between the mobile node and home agent MAY be supported and used.
o 可以支持并使用在移动节点和归属代理之间隧道传输的有效载荷分组的ESP封装。
o If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection MUST be supported for those protocols.
o 如果支持多播组成员控制协议或有状态地址自动配置协议，则这些协议必须支持有效负载数据保护。
The following requirements apply to both home agents and mobile nodes:
以下要求适用于家庭代理和移动节点：
o As required in the base specification [7], when a packet destined to the receiving node is matched against IPsec security policy or selectors of a security association, an address appearing in a Home Address destination option is considered as the source address of the packet.
o 根据基本规范[7]的要求，当目的地为接收节点的数据包与IPsec安全策略或安全关联的选择器相匹配时，出现在家庭地址目的地选项中的地址被视为数据包的源地址。
Note that the home address option appears before IPsec headers. Section 11.3.2 of the base specification describes one possible implementation approach for this: The IPsec policy operations can be performed at the time when the packet has not yet been modified per Mobile IPv6 rules, or has been brought back to its normal form
请注意，home address选项出现在IPsec头之前。基本规范的第11.3.2节描述了一种可能的实现方法：IPsec策略操作可以在数据包尚未按照移动IPv6规则修改或恢复正常形式时执行
after Mobile IPv6 processing. That is, the processing of the Home Address option is seen as a fixed transformation of the packets that does not affect IPsec processing.
经过移动IPv6处理。也就是说，Home Address选项的处理被视为不影响IPsec处理的包的固定转换。
o Similarly, a home address within a Type 2 Routing header destined to the receiving node is considered as the destination address of the packet, when a packet is matched against IPsec security policy or selectors of a security association.
o 类似地，当分组与IPsec安全策略或安全关联的选择器相匹配时，目的地为接收节点的类型2路由报头内的归属地址被视为分组的目的地地址。
Similar implementation considers apply to the Routing header processing as was described above for the Home Address destination option.
类似的实现考虑应用于路由报头处理，如上文针对Home Address destination选项所述。
o When IPsec is used to protect return routability signaling or payload packets, this protection MUST only be applied to the return routability packets entering the IPv6 encapsulated tunnel interface between the mobile node and the home agent. This can be achieved, for instance, by defining the security policy database entries specifically for the tunnel interface. That is, the policy entries are not generally applied on all traffic on the physical interface(s) of the nodes, but rather only on traffic that enters this tunnel.
o 当IPsec用于保护返回路由性信令或有效负载数据包时，此保护必须仅应用于进入移动节点和归属代理之间的IPv6封装隧道接口的返回路由性数据包。例如，可以通过专门为隧道接口定义安全策略数据库条目来实现。也就是说，策略条目通常不会应用于节点物理接口上的所有流量，而是仅应用于进入此隧道的流量。
o The authentication of mobile nodes MAY be based either on machine or user credentials. Note that multi-user operating systems typically allow all users of a node to use any of the IP addresses assigned to the node. This limits the capability of the home agent to restrict the use of a home address to a particular user in such environment. Where user credentials are applied in a multi-user environment, the configuration should authorize all users of the node to control all home addresses assigned to the node.
o 移动节点的认证可以基于机器或用户凭证。请注意，多用户操作系统通常允许节点的所有用户使用分配给该节点的任何IP地址。这限制了归属代理在此类环境中限制特定用户使用归属地址的能力。在多用户环境中应用用户凭据时，配置应授权节点的所有用户控制分配给节点的所有家庭地址。
o When the mobile node returns home and de-registers with the Home Agent, the tunnel between the home agent and the mobile node's care-of address is torn down. The security policy entries, which were used for protecting tunneled traffic between the mobile node and the home agent MUST be made inactive (for instance, by removing them and installing them back later through an API). The corresponding security associations could be kept as they are or deleted depending on how they were created. If the security associations were created dynamically using IKE, they are automatically deleted when they expire. If the security associations were created through manual configuration, they MUST be retained and used later when the mobile node moves away from home again. The security associations protecting Binding Updates and Acknowledgements, and prefix discovery SHOULD NOT be deleted as they do not depend on care-of addresses and can be used again.
o 当移动节点返回家乡并向家乡代理注销时，家乡代理和移动节点的转交地址之间的隧道被拆除。用于保护移动节点和归属代理之间的隧道流量的安全策略条目必须处于非活动状态（例如，通过删除它们并稍后通过API重新安装）。相应的安全关联可以按原样保留或删除，具体取决于它们的创建方式。如果安全关联是使用IKE动态创建的，则它们将在过期时自动删除。如果安全关联是通过手动配置创建的，则必须保留这些关联，并在移动节点再次离开家时使用。不应删除保护绑定更新和确认以及前缀发现的安全关联，因为它们不依赖于转交地址，并且可以再次使用。
The following rules apply to mobile nodes:
以下规则适用于移动节点：
o The mobile node MUST use the Home Address destination option in Binding Updates and Mobile Prefix Solicitations, sent to the home agent from a care-of address.
o 移动节点必须在绑定更新和移动前缀请求中使用Home Address destination选项，从转交地址发送给归属代理。
o When the mobile node receives a changed set of prefixes from the home agent during prefix discovery, there is a need to configure new security policy entries, and there may be a need to configure new security associations. It is outside the scope of this specification to discuss automatic methods for this.
o 当移动节点在前缀发现期间从归属代理接收到更改的前缀集时，需要配置新的安全策略条目，并且可能需要配置新的安全关联。讨论自动方法不在本规范的范围内。
The following rules apply to home agents:
以下规则适用于国内代理：
o The home agent MUST use the Type 2 Routing header in Binding Acknowledgements and Mobile Prefix Advertisements sent to the mobile node, again due to the need to have the home address visible when the policy checks are made.
o 归属代理必须在发送到移动节点的绑定确认和移动前缀播发中使用类型2路由报头，这也是因为在进行策略检查时需要使归属地址可见。
o It is necessary to avoid the possibility that a mobile node could use its security association to send a Binding Update on behalf of another mobile node using the same home agent. In order to do this, the security policy database entries MUST unequivocally identify a single security association for protecting Binding Updates between any given home address and home agent when manually keyed IPsec security associations are used. When dynamic keying is used, the security policy database entries MUST unequivocally identify the IKE phase 1 credentials which can be used to authorize the creation of security associations for protecting Binding Updates for a particular home address. How these mappings are maintained is outside the scope of this specification, but they may be maintained, for instance, as a locally administered table in the home agent. If the phase 1 identity is a Fully Qualified Domain Name (FQDN), secure forms of DNS may also be used.
o 有必要避免移动节点可能使用其安全关联来代表使用相同归属代理的另一移动节点发送绑定更新。为此，安全策略数据库条目必须明确标识单个安全关联，以便在使用手动键控IPsec安全关联时保护任何给定家庭地址和家庭代理之间的绑定更新。使用动态键控时，安全策略数据库条目必须明确标识IKE阶段1凭据，该凭据可用于授权创建安全关联，以保护特定家庭地址的绑定更新。如何维护这些映射不在本规范的范围内，但它们可以作为本地管理的表在归属代理中进行维护。如果阶段1标识是完全限定域名（FQDN），则也可以使用DNS的安全形式。
o When the set of prefixes advertised by the home agent changes, there is a need to configure new security policy entries, and there may be a need to configure new security associations. It is outside the scope of this specification to discuss automatic methods for this, if new home addresses are required.
o 当归属代理播发的前缀集更改时，需要配置新的安全策略条目，并且可能需要配置新的安全关联。如果需要新的家庭地址，讨论自动方法不在本规范的范围内。
The following requirements apply to both home agents and mobile nodes:
以下要求适用于家庭代理和移动节点：
o When securing Binding Updates, Binding Acknowledgements, and prefix discovery, both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [3] header in transport mode and MUST use a non-null payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection.
o 当保护绑定更新、绑定确认和前缀发现时，移动节点和归属代理都必须支持并且应该在传输模式下使用封装安全有效负载（ESP）[3]头，并且必须使用非空有效负载验证算法来提供数据源验证，无连接完整性和可选的防重放保护。
Mandatory support for encryption and integrity protection algorithms is as defined in RFC 2401 [2], RFC 2402 [8], and RFC 2406 [3]. Care is needed when selecting suitable encryption algorithms for ESP, however. Currently available integrity protection algorithms are in general considered to be secure. The encryption algorithm, DES, mandated by the current IPsec standards is not, however. This is particularly problematic when IPsec security associations are configured manually, as the same key is used for a long time.
RFC 2401[2]、RFC 2402[8]和RFC 2406[3]中定义了对加密和完整性保护算法的强制支持。然而，在为ESP选择合适的加密算法时需要小心。目前可用的完整性保护算法通常被认为是安全的。但是，当前IPsec标准强制使用的加密算法DES不是。当手动配置IPsec安全关联时，这一问题尤其严重，因为长时间使用同一密钥。
o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the protection of packets belonging to the return routability procedure. A non-null encryption transform and a non-null authentication algorithm MUST be applied.
o 必须支持隧道模式IPsec ESP，并应将其用于保护属于返回可路由性过程的数据包。必须应用非空加密转换和非空身份验证算法。
Note that the return routability procedure involves two message exchanges from the mobile node to the correspondent node. The purpose of these exchanges is to assure that the mobile node is live at the claimed home and care-of addresses. One of the exchanges is sent directly to and from the correspondent node, while another one is tunneled through the home agent. If an attacker is on the mobile node's link and the mobile node's current link is an unprotected wireless link, the attacker would able to see both sets of messages, and launch attacks based on it (these attacks are discussed further in Section 15.4 of the base specification [7].) One can prevent the attack by making sure that the packets tunneled through the home agent are encrypted.
注意，返回可路由性过程涉及从移动节点到对应节点的两次消息交换。这些交换的目的是确保移动节点在所声称的家庭和照顾地址处处于活动状态。其中一个交换直接发送到对应节点，另一个交换通过归属代理进行隧道传输。如果攻击者位于移动节点的链路上，且移动节点的当前链路是未受保护的无线链路，则攻击者将能够看到这两组消息，并基于这两组消息发起攻击（这些攻击将在基本规范[7]的第15.4节中进一步讨论）可以通过确保通过归属代理隧道传输的数据包被加密来防止攻击。
Note that this specification concerns itself only with on-the-wire formats, and does not dictate specific implementations mechanisms. In the case of IPsec tunnel mode, the use of IP-in-IP encapsulation followed by IPsec transport mode encapsulation may also be possible.
请注意，本规范仅涉及在线格式，并不规定具体的实现机制。在IPsec隧道模式的情况下，也可以在IP封装中使用IP，然后使用IPsec传输模式封装。
The following rules apply to mobile nodes:
以下规则适用于移动节点：
o When ESP is used to protect Binding Updates, there is no protection for the care-of address which appears in the IPv6 header outside the area protected by ESP. It is important for the home agent to verify that the care-of address has not been tampered with. As a result, the attacker would have redirected the mobile node's traffic to another address. In order to prevent this, Mobile IPv6 implementations MUST use the Alternate Care-of Address mobility option in Binding Updates sent by mobile nodes while away from home. The exception to this is when the mobile node returns home and sends a Binding Update to the home agent in order to de-register. In this case no Alternate Care-of Address option is needed, as described in Section 3.1.
o 当ESP用于保护绑定更新时，对ESP保护区域之外的IPv6标头中显示的转交地址没有任何保护。归属代理必须验证转交地址未被篡改。因此，攻击者会将移动节点的流量重定向到另一个地址。为了防止这种情况，移动IPv6实施必须在绑定移动节点在离家时发送的更新时使用备用转交地址移动选项。例外情况是，当移动节点返回家乡并向家乡代理发送绑定更新以取消注册时。在这种情况下，如第3.1节所述，不需要替代转交地址选项。
When IPsec is used to protect return routability signaling or payload packets, the mobile node MUST set the source address it uses for the outgoing tunnel packets to the current primary care-of address. The mobile node starts to use a new primary care-of address immediately after sending a Binding Update to the home agent to register this new address. Similarly, it starts to use the new address as the required destination address of tunneled packets received from the home agent.
当IPsec用于保护返回可路由性信令或有效负载数据包时，移动节点必须将其用于传出隧道数据包的源地址设置为当前主要转交地址。移动节点在向归属代理发送绑定更新以注册该新地址之后立即开始使用新的主要转交地址。类似地，它开始使用新地址作为从归属代理接收的隧道数据包的所需目的地地址。
The following rules apply to home agents:
以下规则适用于国内代理：
o When IPsec is used to protect return routability signaling or payload packets, IPsec security associations are needed to provide this protection. When the care-of address for the mobile node changes as a result of an accepted Binding Update, special treatment is needed for the next packets sent using these security associations. The home agent MUST set the new care-of address as the destination address of these packets, as if the outer header destination address in the security association had changed. Similarly, the home agent starts to expect the new source address in the tunnel packets received from the mobile node.
o 当IPsec用于保护返回路由性信令或有效负载数据包时，需要IPsec安全关联来提供这种保护。当移动节点的转交地址由于接受的绑定更新而改变时，需要对使用这些安全关联发送的下一个数据包进行特殊处理。归属代理必须将新的转交地址设置为这些数据包的目标地址，就像安全关联中的外部报头目标地址已更改一样。类似地，归属代理开始期望从移动节点接收的隧道分组中的新源地址。
Such address changes can be implemented, for instance, through an API from the Mobile IPv6 implementation to the IPsec implementation. It should be noted that the use of such an API and the address changes MUST only be done based on the Binding Updates received by the home agent and protected by the use of IPsec. Address modifications based on other sources, such as Binding Updates to the correspondent nodes protected by return routability, or open access to an API from any application may result in security vulnerabilities.
例如，可以通过从移动IPv6实现到IPsec实现的API来实现这种地址更改。应该注意的是，这种API的使用和地址更改只能基于归属代理接收到的绑定更新来完成，并通过使用IPsec进行保护。基于其他来源的地址修改，例如绑定到受返回路由性保护的对应节点的更新，或从任何应用程序开放访问API，都可能导致安全漏洞。
The following requirements apply to both home agents and mobile nodes:
以下要求适用于家庭代理和移动节点：
o If anti-replay protection is required, dynamic keying MUST be used. IPsec can provide anti-replay protection only if dynamic keying is used (which may not always be the case). IPsec also does not guarantee correct ordering of packets, only that they have not been replayed. Because of this, sequence numbers within the Mobile IPv6 messages are used to ensure correct ordering. However, if the 16 bit Mobile IPv6 sequence number space is cycled through, or the home agent reboots and loses its state regarding the sequence numbers, replay and reordering attacks become possible. The use of dynamic keying, IPsec anti-replay protection, and the Mobile IPv6 sequence numbers can together prevent such attacks.
o 如果需要防重放保护，则必须使用动态键控。IPsec只能在使用动态键控时提供防重放保护（可能并非总是如此）。IPsec也不能保证数据包的正确顺序，只是它们没有被重放。因此，移动IPv6消息中的序列号用于确保正确排序。但是，如果16位移动IPv6序列号空间被循环使用，或者归属代理重新启动并丢失其有关序列号的状态，则可能会发生重播和重新排序攻击。使用动态密钥、IPsec反重放保护和移动IPv6序列号可以共同防止此类攻击。
o If IKE version 1 is used with preshared secrets in main mode, it determines the shared secret to use from the IP address of the peer. With Mobile IPv6, however, this may be a care-of address and does not indicate which mobile node attempts to contact the home agent. Therefore, if preshared secret authentication is used in IKEv1 between the mobile node and the home agent then aggressive mode MUST be used. Note also that care needs to be taken with phase 1 identity selection. Where the ID_IPV6_ADDR Identity Payloads is used, unambiguous mapping of identities to keys is not possible. (The next version of IKE may not have these limitations.)
o 如果IKE版本1在主模式下与预共享机密一起使用，它将根据对等方的IP地址确定要使用的共享机密。然而，对于移动IPv6，这可能是转交地址，并不表示哪个移动节点试图联系归属代理。因此，如果在移动节点和归属代理之间的IKEv1中使用预共享秘密认证，则必须使用主动模式。还要注意的是，在第一阶段身份选择时需要小心。在使用ID_IPV6_ADDR Identity有效载荷的情况下，不可能将标识明确地映射到密钥。（下一版本的IKE可能没有这些限制。）
Note that the difficulties with main mode and preshared secrets in IKE version 1 are well known for dynamic addresses. With static addresses, there has not been a problem. With Mobile IPv6, however, the use of the care-of addresses to run IKE to the home agent presents a problem even when the home address stays stable. Further discussion about the use of care-of addresses in this way appears in Section 7.
请注意，IKE版本1中主模式和预共享机密的困难在动态地址方面是众所周知的。对于静态地址，没有问题。然而，在移动IPv6中，使用转交地址来向归属代理运行IKE会出现问题，即使在归属地址保持稳定的情况下也是如此。关于以这种方式使用转交地址的进一步讨论见第7节。
The following rules apply to mobile nodes:
以下规则适用于移动节点：
o In addition to the rules above, if dynamic keying is used, the key management protocol MUST use the care-of address as the source address in the protocol exchanges with the mobile node's home agent.
o 除上述规则外，如果使用动态密钥，则密钥管理协议必须使用转交地址作为与移动节点的归属代理交换的协议中的源地址。
o However, the IPsec security associations with the mobile node's home agent use home addresses. That is, the IPsec security associations MUST be requested from the key management protocol using the home address of the mobile node as the client identity.
o 但是，与移动节点的归属代理的IPsec安全关联使用归属地址。也就是说，必须使用移动节点的家庭地址作为客户端标识，从密钥管理协议请求IPsec安全关联。
The security associations for protecting Binding Updates and Acknowledgements are requested for the Mobility header protocol in transport mode and for specific IP addresses as endpoints. No other selectors are used. Similarly, the security associations for protecting prefix discovery are requested for the ICMPv6 protocol and the specific IP addresses, again without other selectors. Security associations for payload and return routability protection are requested for a specific tunnel interface and either the payload protocol or the Mobility header protocol, in tunnel mode. In this case one requested endpoint is an IP address and the other one is a wildcard, and there are no other selectors.
为传输模式下的移动报头协议和作为端点的特定IP地址请求用于保护绑定更新和确认的安全关联。不使用其他选择器。类似地，为ICMPv6协议和特定IP地址请求用于保护前缀发现的安全关联，同样不需要其他选择器。在隧道模式下，针对特定隧道接口和有效负载协议或移动报头协议，请求有效负载和返回路由能力保护的安全关联。在这种情况下，一个请求的端点是IP地址，另一个是通配符，并且没有其他选择器。
o If the mobile node has used IKE version 1 to establish security associations with its home agent, it should follow the procedures discussed in Section 11.7.1 and 11.7.3 of the base specification [7] to determine whether the IKE endpoints can be moved or if IKE phase 1 has to be re-established.
o 如果移动节点已使用IKE版本1与其归属代理建立安全关联，则应遵循基本规范[7]第11.7.1节和第11.7.3节中讨论的程序，以确定是否可以移动IKE端点或是否必须重新建立IKE阶段1。
The following rules apply to home agents:
以下规则适用于国内代理：
o If the home agent has used IKE version 1 to establish security associations with the mobile node, it should follow the procedures discussed in Section 10.3.1 and 10.3.2 of the base specification [7] to determine whether the IKE endpoints can be moved or if IKE phase 1 has to be re-established.
o 如果归属代理已使用IKE版本1与移动节点建立安全关联，则应遵循基本规范[7]第10.3.1节和第10.3.2节中讨论的程序，以确定是否可以移动IKE端点或是否必须重新建立IKE阶段1。
In the following we describe the Security Policy Database (SPD) and Security Association Database (SAD) entries necessary to protect Binding Updates and Binding Acknowledgements exchanged between the mobile node and the home agent.
在下文中，我们描述了保护移动节点和归属代理之间交换的绑定更新和绑定确认所需的安全策略数据库（SPD）和安全关联数据库（SAD）条目。
Section 5.1 introduces the format we use in the description of the SPD and the SAD. Section 5.2 describes how to configure manually keyed IPsec security associations without dynamic keying, and Section 5.3 describes how to use dynamic keying.
第5.1节介绍了我们在描述SPD和SAD时使用的格式。第5.2节描述了如何在没有动态键控的情况下配置手动键控的IPsec安全关联，第5.3节描述了如何使用动态键控。
The format used in the examples is as follows. The SPD description has the format
示例中使用的格式如下所示。SPD说明的格式如下所示
<node> "SPD OUT:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
<node> "SPD OUT:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
<node> "SPD IN:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
<node> "SPD IN:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
Where <node> represents the name of the node, and <spdentry> has the following format:
其中，<node>表示节点的名称，<spdentry>具有以下格式：
"IF" <condition> "THEN USE SA " <sa> |
"IF" <condition> "THEN USE SA " <pattern> |
"IF" <condition> "THEN USE SA " <sa> |
"IF" <condition> "THEN USE SA " <pattern> |
Where <condition> is a boolean expression about the fields of the
IPv6 packet, <sa> is the name of a specific security association, and
<pattern> is a specification for a security association to be
negotiated via IKE [4]. The SAD description has the format
Where <condition> is a boolean expression about the fields of the
IPv6 packet, <sa> is the name of a specific security association, and
<pattern> is a specification for a security association to be
negotiated via IKE [4]. The SAD description has the format
<node> "SAD:"
"-" <sadentry>
"-" <sadentry>
...
"-" <sadentry>
<node> "SAD:"
"-" <sadentry>
"-" <sadentry>
...
"-" <sadentry>
Where <node> represents the name of the node, and <sadentry> has the following format:
其中，<node>表示节点的名称，<sadentry>具有以下格式：
<sa> "(" <dir> ","
<spi> ","
<destination> ","
<ipsec-proto> ","
<mode> ")" ":"
<rule>
<sa> "(" <dir> ","
<spi> ","
<destination> ","
<ipsec-proto> ","
<mode> ")" ":"
<rule>
Where <dir> is "IN" or "OUT", <spi> is the SPI of the security association, <destination> is its destination, <ipsec-proto> is in our case "ESP", <mode> is either "TUNNEL" or "TRANSPORT", and <rule> is an expression which describes the IPsec selectors, i.e., which fields of the IPv6 packet must have which values.
其中，<dir>是“IN”或“OUT”，<spi>是安全关联的spi，<destination>是其目的地，<ipsec proto>在我们的例子中是“ESP”，<mode>是“TUNNEL”或“TRANSPORT”，并且<rule>是描述ipsec选择器的表达式，即IPv6数据包的哪些字段必须具有哪些值。
We will be using an example mobile node in this section with the home address "home_address_1". The user's identity in this mobile node is "user_1". The home agent's address is "home_agent_1".
在本节中，我们将使用一个家庭地址为“home\u address\u 1”的示例移动节点。此移动节点中的用户标识为“用户1”。家庭代理的地址是“家庭代理1”。
Here are the contents of the SPD and SAD for protecting Binding Updates and Acknowledgements:
以下是用于保护绑定更新和确认的SPD和SAD的内容：
mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA SA1
移动节点SPD OUT:-如果源=主\地址\目标=主\代理\协议\ MH，则使用SA SA1
mobile node SPD IN: - IF source = home_agent_1 & destination = home_address_1 & proto = MH THEN USE SA SA2
移动节点SPD IN:-如果源=主\代理\目标=主\地址\ 1&协议=MH，则使用SA SA2
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
home agent SPD OUT: - IF source = home_agent_1 & destination = home_address_1 & proto = MH THEN USE SA SA2
归属代理SPD OUT:-如果源=归属代理\u 1&目的地=归属地址\u 1&协议=MH，则使用SA SA2
home agent SPD IN: - IF source = home_address_1 & destination = home_agent_1 & proto = MH THEN USE SA SA1
归属代理SPD IN:-如果源=归属地址\u 1和目的地=归属代理\u 1和协议=MH，则使用SA SA1
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
proto = MH
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
In the above, "MH" refers to the protocol number for the Mobility Header [7].
在上面，“MH”是指移动性报头的协议编号[7]。
In the following we describe the necessary SPD and SAD entries to protect return routability signaling between the mobile node and the home agent. Note that the rules in the SPD are ordered, and the ones in the previous section must take precedence over these ones. In other words, the higher precedence entries must occur first in the RFC 2401 [2] ordered list of SPD entries.
在下文中，我们将描述必要的SPD和SAD条目，以保护移动节点和归属代理之间的返回路由性信令。请注意，SPD中的规则是有序的，上一节中的规则必须优先于这些规则。换句话说，较高优先级的条目必须首先出现在SPD条目的RFC 2401[2]有序列表中。
mobile node SPD OUT: - IF interface = IPv6 IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA SA3
移动节点SPD OUT:-如果接口=IPv6 IPv6隧道到主\u代理\u 1&源=主\u地址\u 1&目的地=任意&proto=MH，则使用SA SA3
mobile node SPD IN: - IF interface = IPv6 tunnel from home_agent_1 & source = any & destination = home_address_1 & proto = MH THEN USE SA SA4
移动节点SPD IN:-如果接口=来自家乡的IPv6隧道\u代理\u 1&源=任何&目的地=家乡\u地址\u 1&协议=MH，则使用SA SA4
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
home agent SPD OUT: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = MH THEN USE SA SA4
归属代理SPD OUT:-如果接口=IPv6隧道到归属地址\u 1&源=任何&目的地=归属地址\u 1&协议=MH，则使用SA SA4
home agent SPD IN: - IF interface = IPv6 tunnel from home_address_1 & source = home_address_1 & destination = any & proto = MH THEN USE SA SA3
归属代理SPD IN:-如果接口=来自归属地的IPv6隧道\u地址\u 1&源=归属地\u地址\u 1&目的地=任意&proto=MH，则使用SA SA3
home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
The security association from the home agent to the mobile node uses the current care-of address as the destination. As discussed earlier, this address is updated in the SAD as the mobile node moves. It can be initialized to the home address before the mobile node has registered.
从归属代理到移动节点的安全关联使用当前转交地址作为目的地。如前所述，该地址在移动节点移动时在SAD中更新。可以在移动节点注册之前将其初始化为家庭地址。
In the following we describe some additional SPD and SAD entries to protect prefix discovery. Note that the SPDs described above protect all ICMPv6 traffic between the mobile node and the home agent, as IPsec may not have the ability to distinguish between different ICMPv6 types.
在下文中，我们将介绍一些额外的SPD和SAD条目，以保护前缀发现。注意，上面描述的SPD保护移动节点和归属代理之间的所有ICMPv6流量，因为IPsec可能无法区分不同的ICMPv6类型。
mobile node SPD OUT: - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 THEN USE SA SA5.
移动节点SPD OUT:-如果源=主\地址\目标=主\代理\协议\ ICMPv6，则使用SA SA5。
mobile node SPD IN: - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 THEN USE SA SA6
移动节点SPD IN:-如果源=主\代理\目标=主\地址\ 1&协议=ICMPv6，则使用SA SA6
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
home agent SPD OUT: - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 THEN USE SA SA6
归属代理SPD OUT:-如果源=归属代理\u 1&目的地=归属地址\u 1&协议=ICMPv6，则使用SA SA6
home agent SPD IN: - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 THEN USE SA SA5
归属代理SPD IN:-如果源=归属地址\u 1和目的地=归属代理\u 1和协议=ICMPv6，则使用SA SA5
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
It is also possible to perform some additional, optional, protection of tunneled payload packets. This protection takes place in a similar manner to the return routability protection above, but requires a different value for the protocol field. The necessary SPD and SAD entries are shown below. It is assumed that the entries for protecting Binding Updates and Acknowledgements, and the entries to protect Home Test Init and Home Test messages take precedence over these entries.
还可以对隧道有效载荷数据包执行一些附加的、可选的保护。此保护以与上面的返回可路由性保护类似的方式进行，但协议字段需要不同的值。必要的SPD和SAD条目如下所示。假定用于保护绑定更新和确认的条目以及用于保护Home Test Init和Home Test消息的条目优先于这些条目。
mobile node SPD OUT: - IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = X THEN USE SA SA7
移动节点SPD OUT:-如果接口=IPv6隧道到主\u代理\u 1&源=主\u地址\u 1&目标=任意&proto=X，则使用SA SA7
mobile node SPD IN: - IF interface = IPv6 tunnel from home_agent_1 & source = any & destination = home_address_1 & proto = X THEN USE SA SA8
移动节点SPD IN:-如果接口=来自家乡的IPv6隧道\u代理\u 1&source=任意&destination=家乡\u地址\u 1&proto=X，则使用SA SA8
mobile node SAD:
- SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
- SA8(IN, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
mobile node SAD:
- SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
- SA8(IN, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
home agent SPD OUT: - IF interface = IPv6 tunnel to home_address_1 & source = any & destination = home_address_1 & proto = X THEN USE SA SA8
归属代理SPD OUT:-如果接口=IPv6隧道到归属地址\u 1&源=任意&目标=归属地址\u 1&协议=X，则使用SA SA8
home agent SPD IN: - IF interface = IPv6 tunnel from home_address_1 & source = home_address_1 & destination = any & proto = X THEN USE SA SA7
归属代理SPD IN:-如果接口=来自归属地的IPv6隧道\u地址\u 1&源=归属地\u地址\u 1&目的地=任意&proto=X，则使用SA SA7
home agent SAD:
- SA8(OUT, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
- SA7(IN, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
home agent SAD:
- SA8(OUT, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
- SA7(IN, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
If multicast group membership control protocols such as MLDv1 [9] or MLDv2 [11] need to be protected, these packets may use a link-local address rather than the home address of the mobile node. In this case the source and destination can be left as a wildcard and the SPD entries will work solely based on the used interface and the protocol, which is ICMPv6 for both MLDv1 and MLDv2.
如果需要保护诸如MLDv1[9]或MLDv2[11]之类的多播组成员资格控制协议，则这些分组可以使用链路本地地址而不是移动节点的归属地址。在这种情况下，源和目标可以保留为通配符，SPD条目将仅基于所使用的接口和协议工作，该协议对于MLDv1和MLDv2都是ICMPv6。
Similar problems are encountered when stateful address autoconfiguration protocols such as DHCPv6 [10] are used. The same approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP protocol.
当使用DHCPv6[10]等有状态地址自动配置协议时，也会遇到类似的问题。同样的方法也适用于DHCPv6。DHCPv6使用UDP协议。
Support for multiple layers of encapsulation (such as ESP encapsulated in ESP) is not required by RFC 2401 [2] and is also otherwise often problematic. It is therefore useful to avoid setting the protocol X in the above entries to either AH or ESP.
RFC 2401[2]不要求支持多层封装（如ESP封装在ESP中的ESP），否则通常会出现问题。因此，避免将上述条目中的协议X设置为AH或ESP非常有用。
In this section we show an example configuration that uses IKE to negotiate security associations.
在本节中，我们将展示一个使用IKE协商安全关联的示例配置。
Here are the contents of the SPD for protecting Binding Updates and Acknowledgements:
以下是用于保护绑定更新和确认的SPD的内容：
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
We have omitted details of the proposed transforms in the above, and all details related to the particular authentication method such as certificates beyond listing a specific identity that must be used.
在上面，我们省略了建议转换的细节，以及与特定身份验证方法（如证书）相关的所有细节，除了列出必须使用的特定身份之外。
We require IKE version 1 to be run using the care-of addresses but still negotiate IPsec SAs that use home addresses. The extra conditions set by the home agent SPD for the peer phase 1 identity to be "user_1" must be verified by the home agent. The purpose of the condition is to ensure that the IKE phase 2 negotiation for a given user's home address can not be requested by another user. In the mobile node, we simply set our local identity to be "user_1".
我们要求IKE版本1使用转交地址运行，但仍然协商使用主地址的IPsec SA。归属代理SPD为对等阶段1身份设置的额外条件为“用户\ 1”，必须由归属代理验证。该条件的目的是确保给定用户的家庭地址的IKE阶段2协商不能被另一个用户请求。在移动节点中，我们只需将本地身份设置为“user_1”。
These checks also imply that the configuration of the home agent is user-specific: every user or home address requires a specific configuration entry. It would be possible to alleviate the configuration tasks by using certificates that have home addresses in the Subject AltName field. However, it is not clear if all IKE implementations allow one address to be used for carrying the IKE negotiations when another address is mentioned in the used certificates. In any case, even this approach would have required user-specific tasks in the certification authority.
这些检查还意味着归属代理的配置是特定于用户的：每个用户或归属地址都需要特定的配置条目。通过使用在Subject AltName字段中具有家庭地址的证书，可以减轻配置任务。然而，当所用证书中提到另一个地址时，不清楚是否所有IKE实现都允许使用一个地址来承载IKE协商。在任何情况下，即使是这种方法也需要在证书颁发机构中执行特定于用户的任务。
Protection for the return routability signaling can be configured in a similar manner as above.
返回可路由性信令的保护可以以与上述类似的方式配置。
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
The security association from the home agent to the mobile node uses the current care-of address as the destination. As discussed earlier, this address is updated in the SAD as the mobile node moves. The SPD entries can be written using the home address (as above), if the care-of address update in the SAD is also done upon the creation of security associations.
从归属代理到移动节点的安全关联使用当前转交地址作为目的地。如前所述，该地址在移动节点移动时在SAD中更新。如果SAD中的转交地址更新也在创建安全关联时完成，则可以使用家庭地址（如上所述）写入SPD条目。
In the following we describe some additional SPD entries to protect prefix discovery with IKE. (Note that when actual new prefixes are discovered, there may be a need to enter new manually configured SPD entries to specify the authorization policy for the resulting new home addresses.)
在下文中，我们将介绍一些附加的SPD条目，以使用IKE保护前缀发现。（请注意，当发现实际的新前缀时，可能需要输入新的手动配置的SPD条目，以指定生成的新家庭地址的授权策略。）
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
Protection for the payload packets happens similarly to the protection of return routability signaling. As in the manually keyed case, these SPD entries have lower priority than the above ones.
对有效负载数据包的保护类似于对返回路由性信令的保护。与手动键入的情况一样，这些SPD条目的优先级低于上述条目。
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD OUT:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
Step 1. At the mobile node, Mobile IPv6 module first produces the following packet:
第一步。在移动节点，移动IPv6模块首先产生以下数据包：
IPv6 header (source = home address, destination = home agent) Mobility header Binding Update
IPv6标头（源=主地址，目标=主代理）移动标头绑定更新
Step 2. This packet is matched against the IPsec SPD on the mobile node and we make a note that IPsec must be applied.
第二步。此数据包与移动节点上的IPsec SPD匹配，我们注意必须应用IPsec。
Step 3. Then, we add the necessary Mobile IPv6 options but do not change the addresses yet, as described in Section 11.3.2 of the base specification [7]. This results in:
第三步。然后，我们添加了必要的移动IPv6选项，但尚未更改地址，如基本规范第11.3.2节所述[7]。这导致：
IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (care-of address) Mobility header Binding Update
IPv6标头（源=主地址，目标=主代理）目标选项标头主地址选项（转交地址）移动标头绑定更新
Step 4. Finally, IPsec headers are added and the necessary authenticator values are calculated:
第四步。最后，添加IPsec头并计算必要的验证器值：
IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (care-of address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6标头（源=主地址，目标=主代理）目标选项标头主地址选项（转交地址）ESP标头（SPI=SPI_a）移动标头绑定更新
Here spi_a is the SPI value that was either configured manually, or agreed upon in an earlier IKE negotiation.
这里，spi_a是手动配置的spi值，或者是在早期IKE协商中商定的spi值。
Step 5. Before sending the packet, the addresses in the IPv6 header and the Destination Options header are changed:
第五步。在发送数据包之前，IPv6标头和目标选项标头中的地址会发生更改：
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6标头（源=转交地址，目的地=归属代理）目的地选项标头归属地址选项（归属地址）ESP标头（SPI=SPI_a）移动标头绑定更新
Step 1. The following packet is received at the home agent:
第一步。在归属代理处接收到以下数据包：
IPv6 header (source = care-of address, destination = home agent) Destination Options header Home Address option (home address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6标头（源=转交地址，目的地=归属代理）目的地选项标头归属地址选项（归属地址）ESP标头（SPI=SPI_a）移动标头绑定更新
Step 2. The home address option is processed first, which results in
第二步。首先处理home address选项，这将导致
IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (care-of address) ESP header (SPI = spi_a) Mobility header Binding Update
IPv6标头（源=主地址，目标=主代理）目标选项标头主地址选项（转交地址）ESP标头（SPI=SPI_a）移动标头绑定更新
Step 3. ESP header is processed next, resulting in
第三步。下一步处理ESP头，导致
IPv6 header (source = home address, destination = home agent) Destination Options header Home Address option (care-of address) Mobility header Binding Update
IPv6标头（源=主地址，目标=主代理）目标选项标头主地址选项（转交地址）移动标头绑定更新
Step 4. This packet matches the policy required for this security association (source = home address, destination = home agent, proto = MH).
第四步。此数据包与此安全关联所需的策略相匹配（源=家庭地址，目标=家庭代理，proto=MH）。
Step 5. Mobile IPv6 processes the Binding Update. The Binding Update is delivered to the Mobile IPv6 module.
第五步。移动IPv6处理绑定更新。绑定更新将传递到移动IPv6模块。
Step 6. If there are any security associations in the security association database for the protection of return routability or payload packets for this mobile node, those security associations are updated with the new care-of address.
第六步。如果安全关联数据库中存在用于保护该移动节点的返回路由性或有效负载分组的任何安全关联，则使用新的转交地址更新这些安全关联。
Step 1. Mobile IPv6 produces the following packet:
第一步。移动IPv6生成以下数据包：
IPv6 header (source = home agent, destination = home address) Mobility header Binding Acknowledgement
IPv6标头（源=归属代理，目标=归属地址）移动标头绑定确认
Step 2. This packet matches the IPsec policy entries, and we remember that IPsec has to be applied.
第二步。此数据包与IPsec策略条目匹配，我们记得必须应用IPsec。
Step 3. Then, we add the necessary Route Headers but do not change the addresses yet, as described in Section 9.5.4 of the base specification [7]. This results in:
第三步。然后，我们添加了必要的路由头，但尚未更改地址，如基本规范第9.5.4节所述[7]。这导致：
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address Mobility header Binding Acknowledgement
IPv6标头（源=归属代理，目标=归属地址）路由标头（类型2）转交地址移动标头绑定确认
Step 4. We apply IPsec:
第四步。我们应用IPsec：
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
IPv6标头（源=归属代理，目标=归属地址）路由标头（类型2）转交地址ESP标头（SPI=SPI_b）移动标头绑定确认
Step 5. Finally, before sending the packet out we change the addresses in the IPv6 header and the Route header:
第五步。最后，在发送数据包之前，我们更改IPv6报头和路由报头中的地址：
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
IPv6报头（源=归属代理，目标=转交地址）路由报头（类型2）归属地址ESP报头（SPI=SPI_b）移动报头绑定确认
Step 1. The following packet is received at the mobile node
第一步。在移动节点处接收以下分组
IPv6 header (source = home agent, destination = care-of address) Routing header (type 2) home address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
IPv6报头（源=归属代理，目标=转交地址）路由报头（类型2）归属地址ESP报头（SPI=SPI_b）移动报头绑定确认
Step 2. After the routing header is processed the packet becomes
第二步。在处理路由报头后，数据包变为
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address ESP header (SPI = spi_b) Mobility header Binding Acknowledgement
IPv6标头（源=归属代理，目标=归属地址）路由标头（类型2）转交地址ESP标头（SPI=SPI_b）移动标头绑定确认
Step 3. ESP header is processed next, resulting in:
第三步。下一步处理ESP标头，结果是：
IPv6 header (source = home agent, destination = home address) Routing header (type 2) care-of address Mobility header Binding Acknowledgement
IPv6标头（源=归属代理，目标=归属地址）路由标头（类型2）转交地址移动标头绑定确认
Step 4. This packet matches the policy required for this security association (source = home agent, destination = home address, proto = MH).
第四步。此数据包与此安全关联所需的策略匹配（源=归属代理，目标=归属地址，proto=MH）。
Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6 module.
第五步。绑定确认被传递到移动IPv6模块。
Step 1. The mobile node constructs a Home Test Init message:
第一步。移动节点构造Home Test Init消息：
IPv6 header (source = home address, destination = correspondent node) Mobility header Home Test Init
IPv6标头（源=主地址，目标=对应节点）移动标头home Test Init
Step 2. Mobile IPv6 determines that this packet should go to the tunnel to the home agent.
第二步。移动IPv6确定此数据包应进入到归属代理的隧道。
Step 3. The packet is matched against IPsec policy entries for the interface, and we find that IPsec needs to be applied.
第三步。数据包与接口的IPsec策略条目相匹配，我们发现需要应用IPsec。
Step 4. IPsec tunnel mode headers are added. Note that we use a care-of address as a source address for the tunnel packet.
第四步。添加了IPsec隧道模式标头。注意，我们使用转交地址作为隧道数据包的源地址。
IPv6 header (source = care-of address, destination = home agent) ESP header (SPI = spi_c) IPv6 header (source = home address,
IPv6标头（源=转交地址，目标=归属代理）ESP标头（SPI=SPI_c）IPv6标头（源=归属地址，
destination = correspondent node) Mobility header Home Test Init
目的地=对应节点）移动报头Home Test Init
Step 5. The packet is sent directly to the home agent using IPsec encapsulation.
第五步。使用IPsec封装将数据包直接发送到归属代理。
Step 1. The home agent receives the following packet:
第一步。归属代理接收以下数据包：
IPv6 header (source = care-of address, destination = home agent) ESP header (SPI = spi_c) IPv6 header (source = home address, destination = correspondent node) Mobility Header Home Test Init
IPv6标头（源=转交地址，目的地=归属代理）ESP标头（SPI=SPI_c）IPv6标头（源=归属地址，目的地=对应节点）移动标头home Test Init
Step 2. IPsec processing is performed, resulting in:
第二步。执行IPsec处理，导致：
IPv6 header (source = home address, destination = correspondent node) Mobility Header Home Test Init
IPv6标头（源=主地址，目标=对应节点）移动标头home Test Init
Step 3. The resulting packet matches the policy required for this security association and the packet can be processed further.
第三步。生成的数据包与此安全关联所需的策略相匹配，并且可以进一步处理该数据包。
Step 4. The packet is then forwarded to the correspondent node.
第四步。然后，数据包被转发到对应节点。
Step 1. The home agent receives a Home Test packet from the correspondent node:
第一步。归属代理从对应节点接收归属测试数据包：
IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6标头（源=对应节点，目的地=家庭地址）移动标头家庭测试初始化
Step 2. The home agent determines that this packet is destined to a mobile node that is away from home, and decides to tunnel it.
第二步。归属代理确定该分组的目的地是远离家乡的移动节点，并决定对其进行隧道传输。
Step 3. The packet matches the IPsec policy entries for the tunnel interface, and we note that IPsec needs to be applied.
第三步。数据包与隧道接口的IPsec策略条目相匹配，我们注意到需要应用IPsec。
Step 4. IPsec is applied, resulting in a new packet. Note that the home agent must keep track of the location of the mobile node, and update the tunnel endpoint address in the security association(s) accordingly.
第四步。应用IPsec，生成一个新的数据包。请注意，归属代理必须跟踪移动节点的位置，并相应地更新安全关联中的隧道端点地址。
IPv6 header (source = home agent, destination = care-of address) ESP header (SPI = spi_d) IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6标头（源=归属代理，目标=转交地址）ESP标头（SPI=SPI_d）IPv6标头（源=对应节点，目标=归属地址）移动标头home Test Init
Step 5. The packet is sent directly to the care-of address using IPsec encapsulation.
第五步。使用IPsec封装将数据包直接发送到转交地址。
Step 1. The mobile node receives the following packet:
第一步。移动节点接收以下分组：
IPv6 header (source = home agent, destination = care-of address) ESP header (SPI = spi_d) IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6标头（源=归属代理，目标=转交地址）ESP标头（SPI=SPI_d）IPv6标头（源=对应节点，目标=归属地址）移动标头home Test Init
Step 2. IPsec is processed, resulting in:
第二步。IPsec被处理，导致：
IPv6 header (source = correspondent node, destination = home address) Mobility Header Home Test Init
IPv6标头（源=对应节点，目的地=家庭地址）移动标头家庭测试初始化
Step 3. This matches the policy required for this security association (source = any, destination = home address).
第三步。这与此安全关联所需的策略匹配（源=任何，目标=家庭地址）。
Step 4. The packet is given to Mobile IPv6 processing.
第四步。将数据包发送给移动IPv6处理。
This procedure is similar to the one presented in Section 6.1.
该程序与第6.1节中的程序类似。
This procedure is similar to the one presented in Section 6.2.
该程序与第6.2节中的程序类似。
This procedure is similar to the one presented in Section 6.3.
该程序与第6.3节中的程序类似。
This procedure is similar to the one presented in Section 6.4.
该程序与第6.4节中的程序类似。
This procedure is similar to the one presented in Section 6.5.
该程序与第6.5节中的程序类似。
This procedure is similar to the one presented in Section 6.6.
该程序与第6.6节中的程序类似。
This procedure is similar to the one presented in Section 6.7.
该程序与第6.7节中的程序类似。
This procedure is similar to the one presented in Section 6.8.
该程序与第6.8节中的程序类似。
Step 1. The mobile node wishes to send a Binding Update to the home agent.
第一步。移动节点希望向归属代理发送绑定更新。
IPv6 header (source = home address, destination = home agent) Mobility header Binding Update
IPv6标头（源=主地址，目标=主代理）移动标头绑定更新
Step 2. There is no existing security association to protect the Binding Update, so the mobile node initiates IKE. The IKE packets are sent as shown in the following examples. The first packet is an example of an IKE packet sent from the mobile node, and the second one is from the home agent. The examples shows also that the phase 1 identity used for the mobile node is a FQDN.
第二步。没有现有的安全关联来保护绑定更新，因此移动节点启动IKE。如以下示例所示发送IKE分组。第一分组是从移动节点发送的IKE分组的示例，第二分组来自归属代理。示例还显示，用于移动节点的阶段1标识是FQDN。
IPv6 header (source = care-of address, destination = home agent) UDP IKE ... IDii = ID_FQDN mn123.ha.net ...
IPv6标头（源=转交地址，目标=归属代理）UDP IKE。。。IDii=ID_FQDN mn123.ha.net。。。
IPv6 header (source = home agent destination = care-of address) UDP IKE ... IDir = ID_FQDN ha.net ...
IPv6标头（源=归属代理目标=转交地址）UDP IKE。。。IDir=ID_FQDN ha.net。。。
Step 3. IKE phase 1 completes, and phase 2 is initiated to request security associations for protecting traffic between the mobile node's home address and the home agent. These addresses will be used as selectors. This involves sending and receiving additional IKE packets. The below example shows again one packet sent by the mobile node and another sent by the home agent. The example shows also that the phase 2 identity used for the mobile node is the mobile node's home address.
第三步。IKE阶段1完成，阶段2启动以请求安全关联以保护移动节点的归属地址和归属代理之间的通信量。这些地址将用作选择器。这涉及发送和接收额外的IKE数据包。下面的示例再次显示了由移动节点发送的一个分组和由归属代理发送的另一个分组。该示例还显示了用于移动节点的阶段2标识是移动节点的家庭地址。
IPv6 header (source = care-of address, destination = home agent) UDP IKE ... IDci = ID_IPV6_ADDR home address ...
IPv6标头（源=转交地址，目标=归属代理）UDP IKE。。。IDci=ID\U IPV6\U地址家庭地址。。。
IPv6 header (source = home agent, destination = care-of address) UDP IKE ... IDcr = ID_IPV6_ADDR home agent ...
IPv6标头（源=归属代理，目标=转交地址）UDP IKE。。。IDcr=ID\U IPV6\U地址主代理。。。
Step 4. The remaining steps are as shown in Section 6.1.
第四步。其余步骤如第6.1节所示。
Step 1. The mobile node and the home agent have existing security associations. Either side may decide at any time that the security associations need to be rekeyed, for instance, because the specified lifetime is approaching.
第一步。移动节点和归属代理具有现有的安全关联。任何一方都可以在任何时候决定需要重新设置安全关联的密钥，例如，因为指定的生存期即将到来。
Step 2. Mobility header packets sent during rekey may be protected by the existing security associations.
第二步。在重新密钥期间发送的移动性报头分组可由现有安全关联进行保护。
Step 3. When the rekeying is finished, new security associations are established. In practice there is a time interval during which an old, about-to-expire security association and newly established security association will both exist. The new ones should be used as soon as they become available.
第三步。当密钥更新完成时，将建立新的安全关联。实际上，存在一个时间间隔，在此时间间隔内，旧的、即将到期的安全关联和新建立的安全关联将同时存在。新的应在可用时立即使用。
Step 4. A notification of the deletion of the old security associations is received. After this, only the new security associations can be used.
第四步。收到删除旧安全关联的通知。在此之后，只能使用新的安全关联。
Note that there is no requirement that the existence of the IPsec and IKE security associations is tied to the existence of bindings. It is not necessary to delete a security association if a binding is removed, as a new binding may soon be established after this.
请注意，不需要将IPsec和IKE安全关联的存在与绑定的存在联系起来。如果删除了绑定，则无需删除安全关联，因为在此之后可能会很快建立新的绑定。
Since cryptographic acceleration hardware may only be able to handle a limited number of active security associations, security associations may be deleted via IKE in order to keep the number of active cryptographic contexts to a minimum. Such deletions should not be interpreted as a sign of losing a contact to the peer or as a reason to remove a binding. Rather, if additional traffic needs to be sent, it is preferable to bring up another security association to protect it.
由于加密加速硬件可能只能处理有限数量的活动安全关联，因此可以通过IKE删除安全关联，以将活动加密上下文的数量保持在最小。这种删除不应被解释为与对等方失去联系的迹象，也不应被解释为删除绑定的理由。相反，如果需要发送额外的流量，最好启用另一个安全关联来保护它。
In this section we describe the sequence of events that relate to movement with IKE-based security associations. In the initial state, the mobile node is not registered in any location and has no security associations with the home agent. Depending on whether the peers will be able to move IKE endpoints to new care-of addresses, the actions taken in Step 9 and 10 are different.
在本节中，我们将描述与基于IKE的安全关联的移动相关的事件序列。在初始状态下，移动节点未在任何位置注册，并且与归属代理没有安全关联。根据对等方是否能够将IKE端点移动到新的转交地址，步骤9和步骤10中采取的操作是不同的。
Step 1. Mobile node with the home address A moves to care-of address B.
第一步。具有归属地址A的移动节点移动到转交地址B。
Step 2. Mobile node runs IKE from care-of address B to the home agent, establishing a phase 1. The home agent can only act as the responder before it knows the current location of the mobile node.
第二步。移动节点从转交地址B运行IKE到归属代理，建立阶段1。归属代理只能在知道移动节点的当前位置之前充当响应者。
Step 3. Protected by this phase 1, mobile node establishes a pair of security associations for protecting Mobility Header traffic to and from the home address A.
第三步。受该阶段1的保护，移动节点建立一对安全关联，用于保护往返于归属地址a的移动报头通信量。
Step 4. Mobile node sends a Binding Update and receives a Binding Acknowledgement using the security associations created in Step 3.
第四步。移动节点使用在步骤3中创建的安全关联发送绑定更新并接收绑定确认。
Step 5. Mobile node establishes a pair of security associations for protecting return routability packets. These security associations are in tunnel mode and their endpoint in the mobile node side is care-of address B. For the purposes of our example, this step uses the phase 1 connection established in Step 2. Multiple phase 1 connections are also possible.
第五步。移动节点建立一对安全关联来保护返回的路由性数据包。这些安全关联处于隧道模式，它们在移动节点端的端点是转交地址B。出于我们示例的目的，此步骤使用在步骤2中建立的阶段1连接。也可以进行多相1连接。
Step 6. The mobile node uses the security associations created in Step 5 to run return routability.
第六步。移动节点使用在步骤5中创建的安全关联来运行return routability。
Step 7. The mobile node moves to a new location and adopts a new care-of address C.
第七步。移动节点移动到新位置并采用新的转交地址C。
Step 8. Mobile node sends a Binding Update and receives a Binding Acknowledgement using the security associations created in Step 3. The home agent ensures that the next packets sent using the security associations created in Step 5 will have the new care-of address as their destination address, as if the outer header destination address in the security association had changed.
第八步。移动节点使用在步骤3中创建的安全关联发送绑定更新并接收绑定确认。归属代理确保使用在步骤5中创建的安全关联发送的下一个数据包将具有新的转交地址作为其目的地地址，就像安全关联中的外部报头目的地地址已经更改一样。
Step 9. If the mobile node and the HA have the capability to change the IKE endpoints, they change the address to C. If they do not have the capability, both nodes remove their phase 1 connections created on top of the care-of address B and will establish a new IKE phase 1 on top of the care-of address C. This capability to change the IKE phase 1 end points is indicated through setting the Key Management Mobility Capability (K) flag [7] in the Binding Update and Binding Acknowledgement messages.
第九步。如果移动节点和HA有能力更改IKE端点，他们会将地址更改为C。如果他们没有能力，两个节点都将删除在转交地址B上创建的阶段1连接，并将在转交地址C上建立新的IKE阶段1。通过在绑定更新和绑定确认消息中设置密钥管理移动能力（K）标志[7]来指示更改IKE阶段1端点的能力。
Step 10. If a new IKE phase 1 connection was setup after movement, the MN will not be able to receive any notifications delivered on top of the old IKE phase 1 security association. Notifications delivered on top of the new security association are received and processed normally. If the mobile node and HA were able to update the IKE endpoints, they can continue using the same IKE phase 1 connection.
第十步。如果在移动后建立了新的IKE阶段1连接，MN将无法接收在旧的IKE阶段1安全关联之上传递的任何通知。在新安全关联上发送的通知将正常接收和处理。如果移动节点和HA能够更新IKE端点，则它们可以继续使用相同的IKE第1阶段连接。
Note that packet formats and header ordering discussed in Section 3 must be supported, but implementations may also support other formats. In general, the use of formats not required here may lead to incorrect processing of the packets by the peer (such as silently discarding them), unless support for these formats has been verified off-line. Such verification can take place at the same time the parameters of the security associations are agreed upon. In some cases, however, basic IPv6 specifications call for support of options not discussed here. In these cases, such a verification step might be unnecessary as long as the peer fully supports the relevant IPv6 specifications. However, no claims are made in this document about the validity of these other formats in the context of Mobile IPv6. It is also likely that systems that support Mobile IPv6 have been tested more extensively with the required formats.
请注意，必须支持第3节中讨论的数据包格式和报头顺序，但实现也可能支持其他格式。通常，使用此处不需要的格式可能会导致对等方对数据包的错误处理（例如，悄悄地丢弃它们），除非离线验证了对这些格式的支持。这种验证可以在商定安全关联参数的同时进行。但是，在某些情况下，基本IPv6规范要求支持此处未讨论的选项。在这些情况下，只要对等方完全支持相关的IPv6规范，就可能不需要这样的验证步骤。但是，本文档中没有声明这些其他格式在移动IPv6环境中的有效性。支持移动IPv6的系统也可能已经使用所需的格式进行了更广泛的测试。
We have chosen to require an encapsulation format for return routability and payload packet protection which can only be realized if the destination of the IPsec packets sent from the home agent can
我们已经选择需要一种用于返回路由性和有效负载数据包保护的封装格式，只有当从归属代理发送的IPsec数据包的目的地可以被访问时，才能实现这种封装格式
be changed as the mobile node moves. One of the main reasons for choosing such a format is that it removes the overhead of twenty four bytes when a home address option or routing header is added to the tunneled packet. Such an overhead would not be significant for the protection of the return routability packets, but would create an additional overhead if IPsec is used to protect the tunneling of payload packets to the home agent. This overhead may be significant for real-time traffic. Given that the use of the shorter packet formats for any traffic requires the existence of suitable APIs, we have chosen to require support for the shorter packet formats both for payload and return routability packets.
可以随着移动节点的移动而更改。选择这种格式的一个主要原因是，当在隧道数据包中添加家庭地址选项或路由头时，它消除了24个字节的开销。这样的开销对于保护返回路由性数据包来说并不重要，但是如果使用IPsec来保护有效负载数据包到归属代理的隧道传输，则会产生额外的开销。此开销对于实时通信量可能非常重要。考虑到对任何流量使用较短的数据包格式需要存在合适的API，我们选择了对有效负载和返回可路由性数据包的较短数据包格式的支持。
In order to support the care-of address as the destination address on the mobile node side, the home agent must act as if the outer header destination address in the security association to the mobile node would have changed upon movements. Implementations are free to choose any particular method to make this change, such as using an API to the IPsec implementation to change the parameters of the security association, removing the security association and installing a new one, or modification of the packet after it has gone through IPsec processing. The only requirement is that after registering a new binding at the home agent, the next IPsec packets sent on this security association will be addressed to the new care-of address.
为了支持转交地址作为移动节点侧的目的地地址，归属代理必须如同移动节点的安全关联中的外部报头目的地地址在移动时会发生改变一样。实现可以自由选择进行此更改的任何特定方法，例如使用IPsec实现的API来更改安全关联的参数，删除安全关联并安装新的安全关联，或者在数据包经过IPsec处理后对其进行修改。唯一的要求是，在home agent上注册新绑定后，在此安全关联上发送的下一个IPsec数据包将被发送到新的转交地址。
We have chosen to require policy entries that are specific to a tunnel interface. This means that implementations have to regard the Home Agent - Mobile Node tunnel as a separate interface on which IPsec SPDs can be based. A further complication of the IPsec processing on a tunnel interface is that this requires access to the BITS implementation before the packet actually goes out.
我们选择要求特定于隧道接口的策略条目。这意味着实现必须将归属代理-移动节点隧道视为IPsec SPD可以基于的单独接口。隧道接口上IPsec处理的另一个复杂性是，这需要在数据包实际发出之前访问BITS实现。
We have chosen to require that a dynamic key management protocol must be able to make an authorization decision for IPsec security association creation with different addresses than with what the key management protocol is run. We expect this to be done typically by configuring the allowed combinations of phase 1 user identities and home addresses.
我们选择要求动态密钥管理协议必须能够使用与密钥管理协议运行地址不同的地址为创建IPsec安全关联做出授权决策。我们希望这通常通过配置允许的第1阶段用户身份和家庭地址的组合来实现。
When certificate authentication is used, IKE fragmentation can be encountered. This can occur when certificate chains are used, or even with single certificates if they are large. Many firewalls do not handle fragments properly, and may drop them. Routers in the path may also discard fragments after the initial one, since they
使用证书身份验证时，可能会遇到IKE碎片。使用证书链时可能会发生这种情况，如果证书链很大，甚至可以使用单个证书。许多防火墙不能正确处理碎片，可能会丢弃碎片。路径中的路由器也可能丢弃初始片段之后的片段，因为它们
typically will not contain full IP headers that can be compared against an access list. Where fragmentation occurs, the endpoints will not always be able to establish a security association.
通常不包含可与访问列表进行比较的完整IP头。在出现碎片的情况下，端点并不总是能够建立安全关联。
Fortunately, typical Mobile IPv6 deployment uses short certificate chains, as the mobile node is communicating directly with its home network. Where the problem appears, it may be difficult (at least away from home) to replace the firewalls or routers with equipment that can properly support fragments. It may help to store the peer certificates locally, or to obtain them through other means.
幸运的是，典型的移动IPv6部署使用短证书链，因为移动节点直接与其家庭网络通信。在出现问题的地方，可能很难（至少在离家之外）用能够正确支持碎片的设备替换防火墙或路由器。它可以帮助本地存储对等证书，或者通过其他方式获取它们。
Mobile IPv6 sets high requirements for a so-called Bump-In-The-Stack (BITS) implementation model of IPsec. As Mobile IPv6 specific modifications of the packets are required before or after IPsec processing, the BITS implementation has to perform also some tasks related to mobility. This may increase the complexity of the implementation, even if it already performs some tasks of the IP layer (such as fragmentation).
移动IPv6对所谓的IPsec堆栈中的Bump（BITS）实现模型提出了很高的要求。由于在IPsec处理之前或之后需要对数据包进行特定于移动IPv6的修改，因此BITS实现还必须执行一些与移动性相关的任务。这可能会增加实现的复杂性，即使它已经执行了IP层的某些任务（例如碎片）。
Specifically, Bump-in-the-Stack implementations may have to deal with the following issues:
具体而言，堆栈中的Bump实现可能必须处理以下问题：
o Processing the Home Address destination option and Routing header type 2 to a form suitable for IPsec processing to take place. This is needed, among other things, for the security association and policy lookups. While relatively straightforward, the required processing may have a hardware effect in BITS implementations, if they use hardware support beyond the cryptographic operations.
o 正在处理Home Address destination选项，并将头类型2路由到适合进行IPsec处理的表单。除其他外，这是安全关联和策略查找所必需的。虽然相对简单，但如果BITS实现使用加密操作以外的硬件支持，所需的处理可能会产生硬件效果。
o Detecting packets sent between the mobile node and its home agent using IPv6 encapsulation.
o 使用IPv6封装检测移动节点与其归属代理之间发送的数据包。
o Offering the necessary APIs for updating the IPsec and IKE security association endpoints.
o 为更新IPsec和IKE安全关联端点提供必要的API。
No IANA actions are necessary based on this document. IANA actions for the Mobile IPv6 protocol itself have been covered in [7].
根据本文件，无需IANA行动。[7]中介绍了移动IPv6协议本身的IANA操作。
The Mobile IPv6 base specification [7] requires strong security between the mobile node and the home agent. This memo discusses how that security can be arranged in practice, using IPsec. The security
移动IPv6基本规范[7]要求移动节点和归属代理之间具有强大的安全性。本备忘录讨论了如何在实践中使用IPsec安排安全性。保安
considerations related to this are documented in the base specification, including a discussion of the implications of using either manual or dynamic keying.
与此相关的注意事项记录在基本规范中，包括使用手动或动态键控的含义的讨论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[2] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[3] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[4] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[6] Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[7] Johnson，D.，Perkins，C.和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[8] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[8] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[9] Deering，S.，Fenner，W.和B.Haberman，“IPv6多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[10] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[10] Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[11] Vida, R. and L. Costa, Eds., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[11] Vida，R.和L.Costa，编辑，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
The authors would like to thank Greg O'Shea, Michael Thomas, Kevin Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, Gabriel Montenegro, Steven Kent, and Santeri Paavolainen for interesting discussions in this problem space.
作者要感谢Greg O'Shea、Michael Thomas、Kevin Miles、Cheryl Madson、Bernard Aboba、Erik Nordmark、Gabriel Montegon、Steven Kent和Santeri Paavolainen在这个问题空间进行了有趣的讨论。
Jari Arkko Ericsson 02420 Jorvas Finland
雅丽阿尔科爱立信02420 Jorvas芬兰
EMail: jari.arkko@ericsson.com
EMail: jari.arkko@ericsson.com
Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA
Vijay Devarapalli诺基亚研究中心313美国加利福尼亚州仙童大道山景城94043号
EMail: vijayd@iprg.nokia.com
EMail: vijayd@iprg.nokia.com
Francis Dupont ENST Bretagne Campus de Rennes 2, rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France
弗朗西斯·杜邦·恩斯特·布列塔尼校区雷恩2号，法国皇家海军陆战队17607 35576塞森塞维涅塞德克斯
EMail: Francis.Dupont@enst-bretagne.fr
EMail: Francis.Dupont@enst-bretagne.fr
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。