Network Working Group V. Devarapalli
Request for Comments: 4877 Azaire Networks
Updates: 3776 F. Dupont
Category: Standards Track CELAR
April 2007
Network Working Group V. Devarapalli
Request for Comments: 4877 Azaire Networks
Updates: 3776 F. Dupont
Category: Standards Track CELAR
April 2007
Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture
使用IKEv2和改进的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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2.
本文档介绍了使用修订的IPsec体系结构和IKEv2的移动IPv6操作。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 5
4.2. Policy Requirements . . . . . . . . . . . . . . . . . . . 5
4.3. IPsec Protocol Processing Requirements . . . . . . . . . . 7
4.4. Dynamic Keying Requirements . . . . . . . . . . . . . . . 9
5. Selector Granularity Considerations . . . . . . . . . . . . . 10
6. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 11
6.1. Binding Updates and Acknowledgements . . . . . . . . . . . 12
6.2. Return Routability Messages . . . . . . . . . . . . . . . 13
6.3. Mobile Prefix Discovery Messages . . . . . . . . . . . . . 14
6.4. Payload Packets . . . . . . . . . . . . . . . . . . . . . 14
7. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 15
7.1. Peer Authorization Database Entries . . . . . . . . . . . 15
7.2. Security Policy Database Entries . . . . . . . . . . . . . 15
7.2.1. Binding Updates and Acknowledgements . . . . . . . . . 16
7.2.2. Return Routability Messages . . . . . . . . . . . . . 17
7.2.3. Mobile Prefix Discovery Messages . . . . . . . . . . . 17
7.2.4. Payload Packets . . . . . . . . . . . . . . . . . . . 18
7.3. Security Association Negotiation Using IKEv2 . . . . . . . 18
7.4. Movements and Dynamic Keying . . . . . . . . . . . . . . . 20
8. The Use of EAP Authentication . . . . . . . . . . . . . . . . 21
9. Dynamic Home Address Configuration . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 5
4.2. Policy Requirements . . . . . . . . . . . . . . . . . . . 5
4.3. IPsec Protocol Processing Requirements . . . . . . . . . . 7
4.4. Dynamic Keying Requirements . . . . . . . . . . . . . . . 9
5. Selector Granularity Considerations . . . . . . . . . . . . . 10
6. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 11
6.1. Binding Updates and Acknowledgements . . . . . . . . . . . 12
6.2. Return Routability Messages . . . . . . . . . . . . . . . 13
6.3. Mobile Prefix Discovery Messages . . . . . . . . . . . . . 14
6.4. Payload Packets . . . . . . . . . . . . . . . . . . . . . 14
7. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 15
7.1. Peer Authorization Database Entries . . . . . . . . . . . 15
7.2. Security Policy Database Entries . . . . . . . . . . . . . 15
7.2.1. Binding Updates and Acknowledgements . . . . . . . . . 16
7.2.2. Return Routability Messages . . . . . . . . . . . . . 17
7.2.3. Mobile Prefix Discovery Messages . . . . . . . . . . . 17
7.2.4. Payload Packets . . . . . . . . . . . . . . . . . . . 18
7.3. Security Association Negotiation Using IKEv2 . . . . . . . 18
7.4. Movements and Dynamic Keying . . . . . . . . . . . . . . . 20
8. The Use of EAP Authentication . . . . . . . . . . . . . . . . 21
9. Dynamic Home Address Configuration . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 24
RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used with Mobile IPv6 [2] to protect the signaling messages. It also illustrates examples of Security Policy Database and Security Association Database entries that can be used to protect Mobile IPv6 signaling messages.
RFC 3776描述了如何将RFC 2401[11]中描述的IPsec与移动IPv6[2]一起使用，以保护信令消息。它还举例说明了可用于保护移动IPv6信令消息的安全策略数据库和安全关联数据库条目。
The IPsec architecture has been revised in RFC 4301 [5]. Among the many changes, the list of selectors has been expanded to include the Mobility Header message type. This has an impact on how security policies and security associations are configured for protecting mobility header messages. It becomes easier to differentiate between the various Mobility Header messages based on the type value instead of checking if a particular mobility header message is being sent on a tunnel interface between the mobile node and the home agent, as it was in RFC 3776. The revised IPsec architecture specification also includes ICMP message type and code as selectors. This makes it possible to protect Mobile Prefix Discovery messages without applying the same security associations to all ICMPv6 messages.
RFC 4301[5]中对IPsec体系结构进行了修订。在众多更改中，选择器列表已扩展为包括移动报头消息类型。这会影响如何配置安全策略和安全关联以保护移动头消息。基于类型值来区分各种移动报头消息变得更容易，而不是像在RFC 3776中那样，检查特定的移动报头消息是否正在移动节点和归属代理之间的隧道接口上发送。修订后的IPsec体系结构规范还包括ICMP消息类型和代码作为选择器。这样就可以保护移动前缀发现消息，而无需对所有ICMPv6消息应用相同的安全关联。
This document discusses new requirements for the home agent and the mobile node to use the revised IPsec architecture and IKEv2. Section 4 lists the requirements. Sections 6 and 7 describe the required Security Policy Database (SPD) and Security Association Database (SAD) entries.
本文档讨论了归属代理和移动节点使用改进的IPsec体系结构和IKEv2的新要求。第4节列出了要求。第6节和第7节描述了所需的安全策略数据库（SPD）和安全关联数据库（SAD）条目。
The Internet Key Exchange (IKE) protocol has also been substantially revised and simplified [4]. Section 7.3 of this document describes how IKEv2 can be used to set up security associations for Mobile IPv6.
互联网密钥交换（IKE）协议也已被大幅修订和简化[4]。本文档第7.3节描述了如何使用IKEv2为移动IPv6建立安全关联。
The use of EAP within IKEv2 is allowed to authenticate the mobile node to the home agent. This is described in Section 8. A method for dynamically configuring a home address from the home agent using the Configuration Payload in IKEv2 is described in Section 9.
允许在IKEv2中使用EAP向归属代理验证移动节点。第8节对此进行了描述。第9节描述了使用IKEv2中的配置有效负载从归属代理动态配置归属地址的方法。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
The mobile node and the home agent MUST support the packet formats as defined in Section 3 of RFC 3776.
移动节点和归属代理必须支持RFC 3776第3节中定义的分组格式。
In case the mobile node reverse tunnels all traffic including Mobile IPv6 signaling messages exchanged between the mobile node and the home agent, then the Home Address Option is not required to be present in the messages sent to the home agent. The packet format for the binding update when sent in the tunnel mode looks as follows.
如果移动节点反向隧道所有流量，包括移动节点和归属代理之间交换的移动IPv6信令消息，则不需要在发送给归属代理的消息中存在归属地址选项。当以隧道模式发送时，绑定更新的数据包格式如下所示。
IPv6 hdr (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 hdr (source = home address, destination = home agent) Mobility Header Binding Update Alternate Care-of Address option (care-of address)
IPv6 hdr（源=转交地址，目的地=归属代理）隧道模式下的ESP标头IPv6 hdr（源=归属地址，目的地=归属代理）移动标头绑定更新备用转交地址选项（转交地址）
The binding acknowledgement sent to the mobile node when it is away from the home link looks as follows.
当移动节点离开主链路时，发送到移动节点的绑定确认如下所示。
IPv6 hdr (source = home agent, destination = care-of address) ESP header in tunnel mode IPv6 hdr (source = home agent, destination = home address) Mobility Header Binding Acknowledgement
IPv6 hdr（源=归属代理，目的地=转交地址）隧道模式下的ESP标头IPv6 hdr（源=归属代理，目的地=归属地址）移动标头绑定确认
The packet formats for tunneled mobile prefix discovery messages are very similar to the tunneled Binding Update and Binding Acknowledgment with the with the home address as the source address in the inner IP header.
隧道式移动前缀发现消息的数据包格式与隧道式绑定更新和绑定确认非常相似，在内部IP报头中以家庭地址作为源地址。
The support for the above tunneled packet format is optional on the mobile node and the home agent.
对上述隧道数据包格式的支持在移动节点和归属代理上是可选的。
This section describes mandatory rules and requirements for all Mobile IPv6 mobile nodes and home agents so that IPsec, with IKEv2 as the key management protocol, can be used to protect traffic between the mobile node and the home agent. Many of the requirements are repeated from RFC 3776 to make this document self-contained and complete.
本节描述了所有移动IPv6移动节点和归属代理的强制性规则和要求，以便使用IKEv2作为密钥管理协议的IPsec来保护移动节点和归属代理之间的通信量。RFC 3776中重复了许多要求，以使本文件自包含且完整。
o RFC 3775 states that manual configuration of IPsec security associations MUST be supported, and automated key management MAY be supported. This document does not make any recommendations regarding the support of manual IPsec configuration and dynamic IPsec configuration. This document just describes the use of manually created IPsec security associations and the use of IKEv2 as the automated IPsec key management protocol for protecting Mobile IPv6 signaling messages.
o RFC 3775指出，必须支持IPsec安全关联的手动配置，并且可以支持自动密钥管理。本文档不提供有关支持手动IPsec配置和动态IPsec配置的任何建议。本文档仅介绍如何使用手动创建的IPsec安全关联，以及如何使用IKEv2作为自动IPsec密钥管理协议来保护移动IPv6信令消息。
o ESP encapsulation for Binding Updates and Binding Acknowledgements MUST be supported and used.
o 必须支持并使用绑定更新和绑定确认的ESP封装。
o ESP encapsulation in tunnel mode for the Home Test Init (HoTi) and Home Test (HoT) messages tunneled between the mobile node and the home agent MUST be supported and SHOULD be used.
o 必须支持并使用在移动节点和归属代理之间隧道传输的归属测试初始化（HoTi）和归属测试（HoT）消息的隧道模式ESP封装。
o ESP encapsulation of the ICMPv6 messages related to mobile 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 the 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 如果支持多播组成员控制协议或有状态地址自动配置协议，则这些协议必须支持有效负载数据保护。
o The home agent and the mobile node MAY support authentication using EAP in IKEv2 as described in Section 8.
o 如第8节所述，归属代理和移动节点可以支持在IKEv2中使用EAP进行认证。
o The home agent and the mobile node MAY support remote configuration of the home address as described in Section 9. When the home agent receives a configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDRESS, it must reply with a valid home address for the mobile node. The home agent can pick a home address from a local database or from a DHCPv6 server on the home link.
o 归属代理和移动节点可支持如第9节所述的归属地址的远程配置。当归属代理接收到一个配置有效负载，其中包含一个针对内部\u IP6\u地址的CFG\u请求时，它必须使用移动节点的有效归属地址进行回复。归属代理可以从本地数据库或归属链接上的DHCPv6服务器中选择归属地址。
The following requirements are related to the configuration of the security policy database on the home agent and the mobile node.
以下要求与归属代理和移动节点上的安全策略数据库的配置有关。
o RFC 3776 required configuration of the security policies per interface in order to be able to differentiate between mobility header messages sent to the home agent and those tunneled through the home agent to the correspondent node. Since the Mobility Header message type is a selector, it is now easy to differentiate
o RFC 3776要求对每个接口的安全策略进行配置，以便能够区分发送到归属代理的移动报头消息和通过归属代理隧道发送到对应节点的移动报头消息。由于Mobility Header消息类型是一个选择器，因此现在很容易区分
between HoTi and HoT messages from other mobility header messages. Therefore per-interface configuration of security policies is not required for protecting mobility header messages. Note that without per-interface security policies, payload packet protection is limited to packets originating/terminating at the home address. Traffic using a link local address within the Mobile IP tunnel cannot be provided IPsec protection without per-interface security policies.
在HoTi和来自其他移动头消息的热消息之间。因此，保护移动头消息不需要每个接口配置安全策略。注意，如果没有每个接口的安全策略，有效负载数据包保护仅限于在主地址发起/终止的数据包。如果没有每接口安全策略，则无法在移动IP隧道中使用链路本地地址的流量提供IPsec保护。
o The home agent MUST be able to prevent a mobile node from using its security association to send a Binding Update on behalf of another mobile node. With manual IPsec configuration, the home agent MUST be able to verify that a security association was created for a particular home address. With dynamic keying, the home agent MUST be able to verify that the identity presented in the IKE_AUTH exchange is allowed to create security associations for a particular home address.
o 归属代理必须能够阻止移动节点使用其安全关联来代表另一个移动节点发送绑定更新。通过手动IPsec配置，归属代理必须能够验证是否为特定的归属地址创建了安全关联。使用动态密钥，归属代理必须能够验证IKE_身份验证交换中显示的身份是否允许为特定的归属地址创建安全关联。
o The home agent uses the Peer Authorization Database (PAD) [5] to store per-mobile node state. More specifically the per-mobile state stores information that is used to authenticate the mobile node and the authorization information that ties the mobile node's identity to the home address of the mobile node. This will allow the home agent to prevent a mobile node from creating IPsec security associations for another mobile node's home address. In case of dynamic home address assignment, the home agent creates a temporary PAD entry linking the authenticated peer identity and the newly allocated home address.
o 归属代理使用对等授权数据库（PAD）[5]来存储每个移动节点的状态。更具体地说，每移动状态存储用于认证移动节点的信息以及将移动节点的身份与移动节点的归属地址联系起来的授权信息。这将允许归属代理阻止移动节点为另一个移动节点的归属地址创建IPsec安全关联。在动态家庭地址分配的情况下，家庭代理创建一个临时PAD条目，链接经过身份验证的对等身份和新分配的家庭地址。
o As required in the base specification [2], 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 根据基本规范[2]的要求，当目的地为接收节点的数据包与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 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.
请注意，home address选项出现在IPsec头之前。基本规范的第11.3.2节描述了一种可能的实现方法：当数据包尚未按照移动IPv6规则进行修改，或者在移动IPv6处理后恢复到其正常形式时，可以执行IPsec策略操作。也就是说，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 considerations apply to the Routing header processing as was described above for the Home Address destination option.
类似的实现注意事项适用于路由报头处理，如上所述的Home Address destination选项。
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, SHOULD 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, Binding Acknowledgements and Mobile Prefix Discovery messages SHOULD NOT be deleted as they do not depend on care-of addresses and can be used again.
o 当移动节点返回家乡并向家乡代理注销时，家乡代理和移动节点的转交地址之间的隧道被拆除。用于保护移动节点和归属代理之间的隧道流量的安全策略条目应处于非活动状态（例如，通过删除它们并稍后通过API重新安装）。相应的安全关联可以按原样保留或删除，具体取决于它们的创建方式。如果安全关联是使用IKE动态创建的，则它们将在过期时自动删除。如果安全关联是通过手动配置创建的，则必须保留这些关联，并在移动节点再次离开家时使用。不应删除保护绑定更新、绑定确认和移动前缀发现消息的安全关联，因为它们不依赖于转交地址，可以再次使用。
o The mobile node MUST use the Home Address destination option in Binding Updates and Mobile Prefix Solicitations when transport mode IPsec protection is used, so that the home address is visible when the IPsec policy checks are made.
o 使用传输模式IPsec保护时，移动节点必须在绑定更新和移动前缀请求中使用Home Address destination选项，以便在进行IPsec策略检查时可以看到Home Address。
o The home agent MUST use the Type 2 Routing header in Binding Acknowledgements and Mobile Prefix Advertisements sent to the mobile node when transport mode IPsec protection is used, again due to the need to have the home address visible when the policy checks are made.
o 在使用传输模式IPsec保护时，归属代理必须在发送到移动节点的绑定确认和移动前缀播发中使用类型2路由报头，这也是因为在进行策略检查时需要使归属地址可见。
The following lists requirements for IPsec processing at the Home Agent and the mobile node.
以下列出了在归属代理和移动节点上进行IPsec处理的要求。
o The home agent and mobile node SHOULD support Mobility Header message type as an IPsec selector.
o 归属代理和移动节点应支持移动报头消息类型作为IPsec选择器。
o The home agent and mobile node SHOULD support ICMPv6 message type as an IPsec selector.
o 归属代理和移动节点应支持ICMPv6消息类型作为IPsec选择器。
o The home agent MUST be able to distinguish between HoTi messages sent to itself (when it is acting as a Correspondent Node) and those sent to Correspondent Nodes (when it is acting as a home agent) based on the destination address of the packet.
o 归属代理必须能够根据数据包的目的地地址区分发送给自身（当它作为对应节点时）和发送给对应节点（当它作为归属代理时）的HoTi消息。
o When securing Binding Updates, Binding Acknowledgements, and Mobile Prefix Discovery messages, both the mobile node and the home agent MUST support the use of the Encapsulating Security Payload (ESP) [6] 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. The use of sequence number in the ESP header to provide anti-replay protection is optional because the sequence numbers in the Binding Updates provide anti-replay protection. However, the anti-replay protection fails if the home agent loses the binding cache state, for example, due to a reboot. Since the IPsec security association state can also be assumed to be lost, ESP cannot provide anti-replay protection in this case. Complete anti-replay protection can only be provided by the use of a dynamic keying mechanism, like IKEv2.
o 当保护绑定更新、绑定确认和移动前缀发现消息时，移动节点和归属代理都必须支持在传输模式下使用封装安全有效负载（ESP）[6]头，并且必须使用非空有效负载验证算法来提供数据源验证、无连接完整性，和可选的防重放保护。在ESP头中使用序列号提供防重播保护是可选的，因为绑定更新中的序列号提供防重播保护。但是，如果主代理丢失绑定缓存状态（例如，由于重新启动），则防重播保护将失败。由于也可以假定IPsec安全关联状态已丢失，因此在此情况下，ESP无法提供防重播保护。只有使用动态键控机制（如IKEv2）才能提供完整的防重放保护。
Support for protecting these messages using ESP in tunnel mode is optional.
支持在隧道模式下使用ESP保护这些消息是可选的。
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，并应将其用于保护属于返回可路由性过程的数据包。必须应用非空加密转换和非空身份验证算法。
o When ESP is used to protect Binding Updates, there is no protection for the care-of address that 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.
o 当ESP用于保护绑定更新时，对ESP保护的区域之外的IPv6标头中显示的转交地址没有任何保护。归属代理必须验证转交地址是否未被篡改。因此，攻击者会将移动节点的流量重定向到另一个地址。为了防止这种情况，移动IPv6实施必须在绑定移动节点在离家时发送的更新时使用备用转交地址移动选项。例外情况是，当移动节点返回家乡并向家乡代理发送绑定更新以取消注册时。
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.
当IPsec用于保护返回可路由性信令或有效负载数据包时，移动节点必须将其用于传出隧道数据包的源地址设置为当前主要转交地址。
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
o 当IPsec用于保护返回路由性信令或有效负载数据包时，需要IPsec安全关联来提供这种保护。当移动节点的转交地址由于接受的绑定更新而改变时，需要对使用这些安全关联发送的下一个数据包进行特殊处理。归属代理必须将新的转交地址设置为这些数据包的目标地址，就像外部报头一样
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.
安全关联中的目标地址已更改。类似地，归属代理开始期望从移动节点接收的隧道分组中的新源地址。
Such address changes can be implemented, for instance, through an API from the Mobile IPv6 implementation to the IPsec implementation. One such API is described in [12]. 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来实现这种地址更改。[12]中描述了一种这样的API。应该注意的是，这种API的使用和地址更改只能基于归属代理接收到的绑定更新来完成，并通过使用IPsec进行保护。基于其他来源的地址修改，例如绑定到受返回路由性保护的对应节点的更新，或从任何应用程序开放访问API，都可能导致安全漏洞。
The following requirements are related to the use of a dynamic key management protocol by the mobile node and the home agent. Section 7.3 describes the use of IKEv2 as the dynamic key management protocol.
以下要求与移动节点和归属代理使用动态密钥管理协议有关。第7.3节描述了IKEv2作为动态密钥管理协议的使用。
o The mobile node MUST use its care-of address as source address in protocol exchanges, when using dynamic keying.
o 当使用动态键控时，移动节点必须在协议交换中将其转交地址用作源地址。
o The mobile node and the home agent MUST create security associations based on the home address, so that the security associations survive changes in care-of address. When using IKEv2 as the key exchange protocol, the home address should be carried as the initiator IP address in the TSi payload during the CREATE_CHILD_SA exchange [4].
o 移动节点和归属代理必须基于归属地址创建安全关联，以便安全关联在转交地址的更改中幸存。当使用IKEv2作为密钥交换协议时，在CREATE_CHILD_SA交换期间，家庭地址应作为TSi有效负载中的启动器IP地址携带[4]。
o If the mobile node has used IKEv2 to establish security associations with its home agent, it should follow the procedures discussed in Sections 11.7.1 and 11.7.3 of the base specification [2] to determine whether the IKE endpoints can be moved or if the SAs, including the IKEv2 SA, have to be re-established.
o 如果移动节点已使用IKEv2与其归属代理建立安全关联，则应遵循基本规范[2]第11.7.1节和第11.7.3节中讨论的程序，以确定是否可以移动IKE端点，或者是否必须重新建立SA，包括IKEv2 SA。
o If the home agent has used IKEv2 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 [2] to determine whether the IKE endpoints can be moved or if the SAs, including the IKEv2 SA, have to be re-established.
o 如果归属代理已使用IKEv2与移动节点建立安全关联，则应遵循基本规范[2]第10.3.1节和第10.3.2节中讨论的程序，以确定是否可以移动IKE端点，或者是否必须重新建立SA，包括IKEv2 SA。
IPsec implementations are compatible with this document even if they do not support fine-grain selectors such as the Mobility Header message type and ICMPv6 message type. Note that such IPsec implementations are not compliant with RFC 4301 [5]. For various reasons, some implementations may choose to support only coarse-grain selectors (i.e., addresses and in some cases the protocol field) for forwarded traffic. As finer-grain selectors give better control, i.e., the protection is only applied when required, the examples in this document always use the finest granularity.
IPsec实现与本文档兼容，即使它们不支持细粒度选择器，如Mobility Header消息类型和ICMPv6消息类型。请注意，此类IPsec实现不符合RFC 4301[5]。出于各种原因，一些实现可能选择仅支持转发流量的粗粒度选择器（即，地址，在某些情况下还支持协议字段）。由于更细的粒度选择器提供更好的控制，即仅在需要时应用保护，因此本文档中的示例始终使用最细的粒度。
The following describes different ways of setting up IPsec policies for protecting Mobile IPv6 messages:
以下介绍了设置IPsec策略以保护移动IPv6消息的不同方法：
1. The IPsec implementations on the mobile node and the home agent support fine-grain selectors, including the Mobility Header message type. This is the case assumed in the IPsec SPD and SAD examples in this document.
1. 移动节点和归属代理上的IPsec实现支持细粒度选择器，包括移动头消息类型。这是本文档中IPsec SPD和SAD示例中假设的情况。
2. The IPsec implementations only support selectors at a protocol level. Such an IPsec implementation can only identify mobility header traffic and cannot identify the individual mobility header messages. In this case, the protection of Return Routability Messages uses a setup similar to the regular payload packets sent to the correspondent node with the protocol selector set to Mobility Header. All tunneled Mobility Header messages will be protected.
2. IPsec实现仅支持协议级别的选择器。这样的IPsec实现只能识别移动报头通信量，而不能识别单个移动报头消息。在这种情况下，返回可路由性消息的保护使用类似于发送到对应节点的常规有效负载分组的设置，协议选择器设置为Mobility Header。所有隧道移动头消息都将受到保护。
3. The third case is where the protocol selector is not available in the IPsec implementation. In this case, all traffic sent by the mobile node that is reverse tunneled through the home agent is protected using ESP in tunnel mode. This case is also applicable when the mobile node, due to privacy considerations, tunnels all traffic to the home agent. This includes Mobile IPv6 signaling messages exchanged between the mobile node and the home agent and all traffic exchanged between the mobile node and the correspondent node. This case uses IPsec tunnel mode SA with the protocol selector set to 'any'.
3. 第三种情况是协议选择器在IPsec实现中不可用。在这种情况下，通过归属代理反向隧道传输的移动节点发送的所有流量都使用隧道模式下的ESP进行保护。当移动节点出于隐私考虑将所有流量隧道传输到归属代理时，这种情况也适用。这包括移动节点和归属代理之间交换的移动IPv6信令消息以及移动节点和对应节点之间交换的所有通信量。本例使用IPsec隧道模式SA，协议选择器设置为“any”。
The third case where all tunneled traffic is protected introduces some additional considerations:
第三种情况下，所有隧道交通都受到保护，这将引入一些额外的注意事项：
o If there is just one IPsec SA providing protection for all traffic, then the SA MUST fulfill the requirements for protecting the Return Routability messages which require confidentiality protection. If the third case is being used for privacy considerations, then there can also be separate tunnel mode SPD
o 如果只有一个IPsec SA为所有流量提供保护，则SA必须满足保护需要保密保护的返回路由性消息的要求。如果第三种情况是出于隐私考虑，那么也可以使用单独的隧道模式SPD
entries for protecting the Return Routability messages with a higher priority in the SPD so that the SPD entry with the higher priority gets applied first.
用于保护SPD中具有较高优先级的返回可路由性消息的条目，以便优先应用具有较高优先级的SPD条目。
o The receipt of a Binding Update from the new care-of address updates the tunnel endpoint of the IPsec SA as described in Section 4.3. Since the Binding Update that updates the tunnel endpoint is received through the same tunnel interface that needs to be updated, special care should be taken on the home agent to ensure that the Binding Update is not dropped. This can be achieved either by performing the source address check on the outer IPv6 header after the binding update is processed or by having exception handling to check the inner packet for a Binding Update when the source address match on the outer source address fails. Typical IPsec processing does not check the outer source address when the originator of the packet has already been authenticated.
o 如第4.3节所述，接收到来自新转交地址的绑定更新将更新IPsec SA的隧道端点。由于更新隧道端点的绑定更新是通过需要更新的同一隧道接口接收的，因此应该特别注意归属代理，以确保不会删除绑定更新。这可以通过在处理绑定更新后对外部IPv6报头执行源地址检查来实现，也可以通过在外部源地址上的源地址匹配失败时进行异常处理来检查内部数据包的绑定更新来实现。当数据包的发起人已经过身份验证时，典型的IPsec处理不会检查外部源地址。
This section describes the SPD and SAD entries that can be used to protect Mobile IPv6 signaling messages. The SPD and SAD entries are only example configurations. A particular mobile node implementation and a home agent implementation could configure different SPD and SAD entries as long as they provide the required security of the Mobile IPv6 signaling messages.
本节介绍可用于保护移动IPv6信令消息的SPD和SAD条目。SPD和SAD条目只是示例配置。特定移动节点实现和归属代理实现可以配置不同的SPD和SAD条目，只要它们提供移动IPv6信令消息所需的安全性。
For the examples described in this document, a mobile node with home address, "home_address_1", primary care-of address, "care_of_address_1", a home agent with address, "home_agent_1" and a user of the mobile node with identity "user_1" are assumed. If the home address of the mobile node changes, the SPD and SAD entries need to be re-created or updated for the new home address.
对于本文档中描述的示例，假设具有家庭地址“家庭地址”的移动节点、“初级护理地址”、“护理地址”的移动节点、具有地址“家庭代理”的家庭代理和具有身份“用户”的移动节点的用户。如果移动节点的家庭地址发生变化，则需要为新的家庭地址重新创建或更新SPD和SAD条目。
The Peer Authorization Database is not used when manual IPsec configuration is used for setting up security associations for protecting Mobile IPv6 signaling messages.
当手动IPsec配置用于设置安全关联以保护移动IPv6信令消息时，不会使用对等授权数据库。
The following are the SPD and SAD entries on the mobile node and the home agent to protect Binding Updates and Acknowledgements.
以下是移动节点和归属代理上的SPD和SAD条目，用于保护绑定更新和确认。
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 & proto = MH &
local_mh_type = BU & remote_mh_type = BAck
Then use SA SA1 (OUT) and SA2 (IN)
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 & proto = MH &
local_mh_type = BU & remote_mh_type = BAck
Then use SA SA1 (OUT) and SA2 (IN)
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & mh_type = BU
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & mh_type = BAck
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & mh_type = BU
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & mh_type = BAck
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 & proto = MH &
local_mh_type = BAck & remote_mh_type = BU
Then use SA SA2 (OUT) and SA1 (IN)
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 & proto = MH &
local_mh_type = BAck & remote_mh_type = BU
Then use SA SA2 (OUT) and SA1 (IN)
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & mh_type = BAck
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & mh_type = BU
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & mh_type = BAck
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & mh_type = BU
The following are the SPD and SAD entries on the mobile node and the home agent to protect Return Routability messages.
以下是移动节点和归属代理上的SPD和SAD条目，用于保护返回的可路由性消息。
mobile node SPD-S:
- IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
Then use SA SA3 (OUT) and SA4 (IN)
mobile node SPD-S:
- IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
Then use SA SA3 (OUT) and SA4 (IN)
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
local_address = home_address_1 & remote_address = any &
proto = MH & mh_type = HoTi
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
local_address = any & remote_address = home_address_1 &
proto = MH & mh_type = HoT
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
local_address = home_address_1 & remote_address = any &
proto = MH & mh_type = HoTi
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
local_address = any & remote_address = home_address_1 &
proto = MH & mh_type = HoT
home agent SPD-S:
- IF remote_address = home_address_1 & local_address = any &
proto = MH & local_mh_type = HoT & remote_mh_type = HoTi
Then use SA SA4 (OUT) and SA3 (IN)
home agent SPD-S:
- IF remote_address = home_address_1 & local_address = any &
proto = MH & local_mh_type = HoT & remote_mh_type = HoTi
Then use SA SA4 (OUT) and SA3 (IN)
home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
local_address = any & remote_address = home_address_1 &
proto = MH & mh_type = HoT
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
local_address = home_address_1 & remote_address = any &
proto = MH & mh_type = HoTi
home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
local_address = any & remote_address = home_address_1 &
proto = MH & mh_type = HoT
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
local_address = home_address_1 & remote_address = any &
proto = MH & mh_type = HoTi
The following are the SPD and SAD entries used to protect Mobile Prefix Discovery messages.
以下是用于保护移动前缀发现消息的SPD和SAD条目。
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 & proto = ICMPv6 &
local_icmp6_type = MPS & remote_icmp6_type = MPA
Then use SA SA5 (OUT) and SA6 (IN)
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 & proto = ICMPv6 &
local_icmp6_type = MPS & remote_icmp6_type = MPA
Then use SA SA5 (OUT) and SA6 (IN)
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 & proto = ICMPv6 &
local_icmp6_type = MPA & remote_icmp6_type = MPS
Then use SA SA6 (OUT) and SA5 (IN)
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 & proto = ICMPv6 &
local_icmp6_type = MPA & remote_icmp6_type = MPS
Then use SA SA6 (OUT) and SA5 (IN)
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS
Regular payload traffic between the mobile node and the correspondent node tunneled through the home agent can be protected by IPsec, if required. The mobile node and the home agent use ESP in tunnel mode to protect the tunneled traffic. The SPD and SAD entries shown in Section 5.2.4 of [3] are applicable here.
如果需要，可以通过IPsec保护移动节点和通过归属代理隧道传输的对应节点之间的常规有效负载流量。移动节点和归属代理在隧道模式下使用ESP来保护隧道流量。[3]第5.2.4节所示的SPD和SAD条目适用于此处。
This section describes the use of IKEv2 to set up the required security associations.
本节介绍如何使用IKEv2设置所需的安全关联。
The following describes PAD entries on the mobile node and the home agent. The PAD entries are only example configurations. Note that the PAD is a logical concept; a particular mobile node and a home agent can implement the PAD in an implementation-specific manner. The PAD state may also be distributed across various databases in a specific implementation.
以下描述移动节点和归属代理上的PAD条目。焊盘条目仅为示例配置。注意，PAD是一个逻辑概念；特定移动节点和归属代理可以以特定于实现的方式实现PAD。在特定的实现中，PAD状态也可以分布在各种数据库中。
mobile node PAD: - IF remote_identity = home_agent_identity_1 Then authenticate (shared secret/certificate/) and authorize CHILD_SA for remote address home_agent_1
移动节点PAD:-如果远程\u标识=主\u代理\u标识\u 1，则对远程地址主\u代理\u 1进行身份验证（共享机密/证书/）并授权子\u SA
home agent PAD: - IF remote_identity = user_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address home_address_1
归属代理PAD:-如果远程\u标识=用户\u 1，则对远程地址归属\u地址\u 1进行身份验证（共享机密/证书/EAP）并授权子级\u SA
The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD.
上述示例中的认证机制列表并不详尽。PAD中可能存储有用于身份验证的其他凭据。
In case of dynamic home address assignment, the home agent creates a temporary PAD entry linking the authenticated peer identity and the newly allocated home address.
在动态家庭地址分配的情况下，家庭代理创建一个临时PAD条目，链接经过身份验证的对等身份和新分配的家庭地址。
The following sections describe the security policy entries on the mobile node and the home agent. The SPD entries are only example configurations. A particular mobile node implementation and a Home Agent implementation could configure different SPD entries as long as they provide the required security of the Mobile IPv6 signaling messages.
以下各节描述移动节点和归属代理上的安全策略条目。SPD条目仅为示例配置。特定移动节点实现和归属代理实现可以配置不同的SPD条目，只要它们提供移动IPv6信令消息所需的安全性。
In the examples shown below, the identity of the user of the mobile node is assumed to be user_1, the home address of the mobile node is assumed to be home_address_1, the primary care-of address of the mobile node is assumed to be care_of_address_1, and the IPv6 address of the Home Agent is assumed to be home_agent_1.
在下面所示的示例中，移动节点的用户的身份被假定为用户_1，移动节点的家庭地址被假定为家庭_地址_1，移动节点的主要照顾地址被假定为家庭_地址_1，并且家庭代理的IPv6地址被假定为家庭_代理_1。
The following are the SPD entries on the mobile node and the home agent for protecting Binding Updates and Acknowledgements.
以下是移动节点和归属代理上用于保护绑定更新和确认的SPD条目。
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BAck
Then use SA ESP transport mode
Initiate using IDi = user_1 to address home_agent_1
mobile node SPD-S:
- IF local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BAck
Then use SA ESP transport mode
Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & local_mh_type = BAck & remote_mh_type = BU
Then use SA ESP transport mode
home agent SPD-S:
- IF local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & local_mh_type = BAck & remote_mh_type = BU
Then use SA ESP transport mode
In the examples shown above, the home address of the mobile node might not be available all the time. For instance, the mobile node might not have configured a home address yet. When the mobile node acquires a new home address, it must either add the address to the corresponding SPD entries or create the SPD entries for the home address.
在上面所示的示例中，移动节点的家庭地址可能并非始终可用。例如，移动节点可能尚未配置家庭地址。当移动节点获取新的家庭地址时，它必须将该地址添加到相应的SPD条目中，或者为家庭地址创建SPD条目。
The home agent should have named SPD entries per mobile node, based on the identity of the mobile node. The identity of the mobile node is stored in the "Name" selector in the SPD [5]. The home address presented by the mobile node during the IKE negotiation is stored as the remote IP address in the resultant IPsec security associations. If the mobile node dynamically configures a home agent and the home address, the home agent may not know which mobile nodes it is supposed to be serving. Therefore, the home agent cannot have SPD entries configured per mobile node. Instead, the home agent should have generic SPD entries to prevent mobility header traffic that requires IPsec protection from bypassing the IPsec filters. Once a mobile node authenticates to the home agent and configures a home address, appropriate SPD entries are created for the mobile node.
归属代理应该根据移动节点的身份为每个移动节点命名SPD条目。移动节点的标识存储在SPD中的“名称”选择器中[5]。IKE协商期间移动节点提供的家庭地址作为远程IP地址存储在结果IPsec安全关联中。如果移动节点动态地配置归属代理和归属地址，则归属代理可能不知道它应该为哪些移动节点服务。因此，归属代理不能为每个移动节点配置SPD条目。相反，归属代理应该具有通用SPD条目，以防止需要IPsec保护的移动报头流量绕过IPsec筛选器。一旦移动节点向归属代理进行身份验证并配置归属地址，就会为移动节点创建适当的SPD条目。
The Mobility Header message type is negotiated by placing it in the most significant eight bits of the 16-bit local "port" selector during IKEv2 exchange. For more details, refer to [5]. The TSi and TSr payloads in the above examples will contain many other selectors apart from home_address_1. For the sake of brevity, we show only those values that are relevant for Mobile IPv6.
在IKEv2交换期间，移动报头消息类型通过将其置于16位本地“端口”选择器的最高有效8位来协商。有关更多详细信息，请参阅[5]。上述示例中的TSi和TSr有效负载将包含除home_address_1之外的许多其他选择器。为简洁起见，我们仅显示与移动IPv6相关的值。
The following are the SPD entries on the mobile node and the home agent for protecting the Return Routability messages.
以下是移动节点和归属代理上用于保护返回路由性消息的SPD条目。
mobile node SPD-S:
- IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1
mobile node SPD-S:
- IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S:
- IF local_address = any & remote_address = home_address_1 &
proto = MH & local_mh_type = HoT & remote_mh_type = HoTi
Then use SA ESP tunnel mode
home agent SPD-S:
- IF local_address = any & remote_address = home_address_1 &
proto = MH & local_mh_type = HoT & remote_mh_type = HoTi
Then use SA ESP tunnel mode
When the mobile node's care-of address changes, the SPD entries on both the mobile node and the home agent must be updated. The home agent knows about the change in care-of address of the mobile node when it receives a Binding Update from the mobile node.
当移动节点的转交地址更改时，必须更新移动节点和归属代理上的SPD条目。当归属代理从移动节点接收到绑定更新时，它知道移动节点的转交地址的变化。
The following are the SPD entries on the mobile node and the home agent for protecting Mobile Prefix Discovery messages.
以下是移动节点和归属代理上用于保护移动前缀发现消息的SPD条目。
mobile node SPD-S: - IF local_address = home_address_1 & remote_address = home_agent_1 & proto = ICMPv6 & local_icmp6_type = MPS & remote_icmp6_type = MPA Then use SA ESP transport mode Initiate using IDi = user_1 to address home_agent_1
移动节点SPD-S:-如果本地\地址=主\地址\ 1和远程\地址=主\代理\ 1和协议=ICMPv6和本地\ icmp6 \类型=MPS和远程\ icmp6 \类型=MPA，则使用SA ESP传输模式启动，使用IDi=用户\ 1来寻址主\代理\ 1
home agent SPD-S: - IF local_address = home_agent_1 & remote_address = home_address_1 & proto = ICMPv6 & local_icmp6_type = MPA & remote_icmp6_type = MPS Then use SA ESP transport mode
归属代理SPD-S:-如果本地地址=归属代理1和远程地址=归属地址1和协议=ICMPv6和本地icmp6类型=MPA和远程icmp6类型=MPS，则使用SA ESP传输模式
In the examples shown above, the home address of the mobile node might not be available all the time. When the mobile node acquires a new home address, it must add the address to the corresponding SPD entries.
在上面所示的示例中，移动节点的家庭地址可能并非始终可用。当移动节点获取新的家庭地址时，它必须将该地址添加到相应的SPD条目中。
The TSi and TSr payloads in the above examples will contain many other selectors apart from home_address_1. For brevity, they are not shown here.
上述示例中的TSi和TSr有效负载将包含除home_address_1之外的许多其他选择器。为简洁起见，此处未显示它们。
The following are the SPD entries on the mobile node and the home agent if payload traffic exchanged between the mobile node and its Correspondent Node needs to be protected. The SPD entries are similar to the entries for protecting Return Routability messages and have lower priority than the above SPD entries.
如果移动节点及其对应节点之间交换的有效负载流量需要保护，则以下是移动节点和归属代理上的SPD条目。SPD条目与保护返回可路由性消息的条目相似，优先级低于上述SPD条目。
mobile node SPD-S:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any & proto = X
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1
mobile node SPD-S:
- IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any & proto = X
Then use SA ESP tunnel mode
Initiate using IDi = user_1 to address home_agent_1
home agent SPD-S:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 & proto = X
Then use SA ESP tunnel mode
home agent SPD-S:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 & proto = X
Then use SA ESP tunnel mode
Mobile IPv6 signaling messages are typically initiated by the mobile node. The mobile node sends a Binding Update to the home agent whenever it moves and acquires a new care-of address.
移动IPv6信令消息通常由移动节点发起。每当移动节点移动并获取新的转交地址时，移动节点向归属代理发送绑定更新。
The mobile node initiates an IKEv2 protocol exchange if the required security associations are not present. A possible mechanism used for mutual authentication is a shared secret between the mobile node and the home agent. The home agent uses the identity of the mobile node to identify the corresponding shared secret. When a public-key-based mechanism is available, it should be the preferred mechanism for mutual authentication.
如果所需的安全关联不存在，则移动节点发起IKEv2协议交换。用于相互认证的可能机制是移动节点和归属代理之间的共享秘密。归属代理使用移动节点的身份来识别相应的共享秘密。当基于公钥的机制可用时，它应该是相互身份验证的首选机制。
If a shared secret is being used, the mobile node uses the shared secret to generate the AUTH payload in the IKE_AUTH exchange. If the mobile node is using a public-key-based mechanism, then it uses its private key to generate the AUTH payload in the IKE_AUTH exchange.
如果正在使用共享密钥，则移动节点使用该共享密钥在IKE_身份验证交换中生成身份验证有效负载。如果移动节点使用的是基于公钥的机制，那么它将使用其私钥在IKE_身份验证交换中生成身份验证有效负载。
Mobile Node Home Agent
----------- ----------
HDR, SAi1, KEi, Ni -->
Mobile Node Home Agent
----------- ----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
<--HDR、SAr1、KEr、Nr、[CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} -->
HDR，SK{IDi，[CERT，][CERTREQ，][IDr，]AUTH，SAi2，TSi，TSr}-->
<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}
<--HDR，SK{IDr，[CERT，]AUTH，SAr2，TSi，TSr}
The mobile node always includes its identity in the IDi payload in the IKE_AUTH exchange. The mobile node could use the following different types of identities to identify itself to the home agent.
移动节点总是将其身份包含在IKE_认证交换的IDi有效负载中。移动节点可以使用以下不同类型的身份向归属代理标识自己。
o Home Address - The mobile node could use its statically configured home address as its identity. In this case the ID Type field is set to ID_IPV6_ADDR.
o 家庭地址-移动节点可以使用其静态配置的家庭地址作为其标识。在这种情况下，ID Type字段设置为ID\u IPV6\u ADDR。
o FQDN - The mobile node can use a Fully Qualified Domain Name as the identifier and set the ID Type field to ID_FQDN.
o FQDN-移动节点可以使用完全限定的域名作为标识符，并将ID类型字段设置为ID_FQDN。
o RFC 822 identifier - If the mobile node uses a RFC 822 identifier [9], it sets the ID Type field to ID_RFC822_ADDR.
o RFC 822标识符-如果移动节点使用RFC 822标识符[9]，它会将ID类型字段设置为ID_RFC822_ADDR。
The above list of identities is not exhaustive.
上述身份列表并非详尽无遗。
In the IKE_AUTH exchange, the mobile node includes the home address and the appropriate selectors in the TSi (Traffic Selector-initiator) payload to negotiate IPsec security associations for protecting the Binding Update and Binding Acknowledgement messages. The mobile node MAY use a range of selectors that includes the mobility message types for Binding Update and Binding Acknowledgement to use the same pair of IPsec security associations for both messages.
在IKE_AUTH交换中，移动节点在TSi（流量选择器启动器）负载中包括归属地址和适当的选择器，以协商IPsec安全关联以保护绑定更新和绑定确认消息。移动节点可以使用包括用于绑定更新和绑定确认的移动消息类型的一系列选择器来为这两个消息使用相同的IPsec安全关联对。
After the IKE_AUTH exchange completes, the mobile node initiates CREATE_CHILD_SA exchanges to negotiate additional security associations for protecting Return Routability signaling, Mobile Prefix Discovery messages, and (optionally) payload traffic. The CREATE_CHILD_SA exchanges are protected by IKEv2 security associations created during the IKE_SA_INIT exchange. If a correspondent node, that is also a mobile node, initiates the return routability exchange, then the home agent initiates the CREATE_CHILD_SA exchange to negotiate security associations for protecting Return Routabilty messages.
在IKE_AUTH交换完成后，移动节点发起CREATE_CHILD_SA交换，以协商用于保护返回路由性信令、移动前缀发现消息和（可选）有效负载流量的附加安全关联。CREATE_CHILD_SA交换受IKEv2安全关联的保护，该关联是在IKE_SA_INIT交换期间创建的。如果通信节点（也是移动节点）启动返回路由性交换，则归属代理启动创建子节点交换以协商安全关联以保护返回路由性消息。
It is important that the security associations are created based on the home address of the mobile node, so that the security associations survive care-of address change. The mobile node MUST use its home address as the initiator IP address in the TSi payload in the CREATE_CHILD_SA exchange in order to create the IPsec security associations for the home address.
重要的是，安全关联是基于移动节点的家庭地址创建的，以便安全关联在地址更改后仍然有效。移动节点必须使用其家庭地址作为CREATE_CHILD_SA交换中TSi有效负载中的启动器IP地址，以便为家庭地址创建IPsec安全关联。
Mobile Node Home Agent
----------- ----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
Mobile Node Home Agent
----------- ----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
<-- HDR, SK {SA, Nr, [KEr], [TSi, TSr]}
<--HDR，SK{SA，Nr，[KEr]，[TSi，TSr]}
When PKI-based authentication is used between the mobile node and the Home Agent, the identity presented by the mobile node in the IDi payload MUST correspond to the identity in the certificate obtained by the Home Agent. The home agent uses the identity presented in the IDi payload to lookup the policy and the certificate that corresponds to the mobile node. If the mobile node presents its home address in the IDi payload, then the home agent MUST verify that the home address matches the address in an iPAddress field in the SubjectAltName extension [8].
当在移动节点和归属代理之间使用基于PKI的认证时，移动节点在IDi有效载荷中提供的身份必须与归属代理获得的证书中的身份相对应。归属代理使用IDi有效负载中提供的标识来查找与移动节点对应的策略和证书。如果移动节点在IDi有效负载中显示其家庭地址，则家庭代理必须验证家庭地址是否与SubjectAltName扩展[8]中iPAddress字段中的地址匹配。
When the mobile node uses its home address in the IDi field, implementations are not required to match the source address in the outermost IP header with the IP address in the IDi field. According to RFC 4306 [4], the IP header fields in the IKEv2 messages are ignored and used only in the IP headers for IKEv2 messages sent as replies.
当移动节点在IDi字段中使用其主地址时，不需要实现将最外层IP报头中的源地址与IDi字段中的IP地址相匹配。根据RFC 4306[4]，IKEv2消息中的IP头字段被忽略，仅用于作为回复发送的IKEv2消息的IP头中。
If the mobile node moves and its care-of address changes, the IKEv2 SA might not be valid. RFC 3775 defines a mechanism based on the successful exchange of Binding Update and Binding Acknowledgement messages. The mobile node establishes the IKE SA with the home agent using its primary care-of address. The IKE SA endpoints are updated on the home agent when it receives the Binding Update from the mobile node's new care-of address and on the mobile node when it sends the Binding Update to the home agent or when it receives the Binding acknowledgement sent by the home agent. This capability to change IKE endpoints is indicated through setting the Key Management Capability (K) flag [2] in the Binding Update and Binding Acknowledgement messages. If the mobile node or the home agent does
如果移动节点移动且其转交地址更改，则IKEv2 SA可能无效。RFC3775定义了一种基于绑定更新和绑定确认消息成功交换的机制。移动节点使用其主要转交地址与归属代理建立IKE SA。当家庭代理从移动节点的新转交地址接收到绑定更新时，IKE SA端点在家庭代理上更新；当移动节点将绑定更新发送给家庭代理或当其接收到家庭代理发送的绑定确认时，IKE SA端点在移动节点上更新。通过在绑定更新和绑定确认消息中设置密钥管理能力（K）标志[2]来指示更改IKE端点的能力。如果移动节点或归属代理
not support this capability, and has no other means to update the addresses, then an IKEv2 exchange MUST be initiated to re-establish a new IKE SA.
如果不支持此功能，并且没有其他方法更新地址，则必须启动IKEv2交换以重新建立新的IKE SA。
In addition to using public key signatures and shared secrets, EAP [10] can be used with IKEv2 for authenticating the mobile node to the home agent.
除了使用公钥签名和共享秘密外，EAP[10]还可以与IKEv2一起用于向归属代理验证移动节点。
The mobile node indicates that it wants to use EAP by including the IDi payload but leaving out the AUTH payload in the first message during the IKE_AUTH exchange. The home agent then includes an EAP payload if it is willing to use an extensible authentication method. Security associations are not created until the subsequent IKE_AUTH exchange after successful EAP authentication. The use of EAP adds at least two round trips to the IKE negotiation. The number of round trips depends on the EAP method used.
移动节点通过在IKE_AUTH交换期间在第一条消息中包括IDi有效载荷但省略AUTH有效载荷来指示它想要使用EAP。然后，如果归属代理愿意使用可扩展的认证方法，则其包括EAP有效负载。在成功进行EAP身份验证后的后续IKE_身份验证交换之前，不会创建安全关联。EAP的使用为IKE协商增加了至少两次往返。往返次数取决于使用的EAP方法。
Mobile Node Home Agent
------------ ----------
HDR, SAi1, KEi, Ni -->
Mobile Node Home Agent
------------ ----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
<--HDR、SAr1、KEr、Nr、[CERTREQ]
HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr}-->
HDR，SK{IDi，[CERTREQ，][IDr，]SAi2，TSi，TSr}-->
<-- HDR, SK {IDr, [CERT,] AUTH, EAP } . . .
<--HDR，SK{IDr，[CERT，]AUTH，EAP}。
HDR, SK {EAP} -->
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH} -->
HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr}
<--HDR，SK{AUTH，SAr2，TSi，TSr}
When EAP is used, the identity presented by the mobile node in the IDi field may not be the actual identity of the mobile node. It could be set to an identity that is used only for Authentication, Authorization, and Accounting (AAA) routing purposes and selecting the right EAP method. It is possible that the actual identity is
当使用EAP时，移动节点在IDi字段中呈现的身份可能不是移动节点的实际身份。可以将其设置为仅用于身份验证、授权和记帐（AAA）路由目的以及选择正确的EAP方法的标识。有可能实际身份是
carried inside EAP, invisible to the home agent. While IKEv2 does not allow an EAP Identity Request/Response message exchange, EAP methods may exchange identities within themselves. In this case, the home agent MUST acquire the mobile node's identity from the corresponding AAA server. How the home agent acquires the mobile node's identity is out of scope for this document.
携带在EAP内，对home agent不可见。虽然IKEv2不允许EAP身份请求/响应消息交换，但EAP方法可以在其内部交换身份。在这种情况下，归属代理必须从相应的AAA服务器获取移动节点的身份。归属代理如何获取移动节点的身份超出了本文档的范围。
Some EAP methods, when used with IKEv2, generate a shared key on the mobile node and the Home Agent once the EAP authentication succeeds. This shared key is used to generate the AUTH payloads in the subsequent IKEv2 messages. The shared key, if used to generate the AUTH payloads, MUST NOT be used for any other purpose. For more details, refer to [4].
某些EAP方法与IKEv2一起使用时，一旦EAP身份验证成功，就会在移动节点和归属代理上生成共享密钥。此共享密钥用于在后续IKEv2消息中生成身份验证有效负载。共享密钥如果用于生成身份验证有效载荷，则不得用于任何其他目的。有关更多详细信息，请参阅[4]。
The use of EAP between the mobile node and the home agent might require the home agent to contact an authorization server like the AAA Home server, on the home link, to authenticate the mobile node. Please refer to [7] for more details.
在移动节点和归属代理之间使用EAP可能需要归属代理在归属链路上联系授权服务器，如AAA归属服务器，以认证移动节点。有关更多详细信息，请参阅[7]。
The mobile node can dynamically configure a home address by including a Configuration Payload in the IKE_AUTH exchange, with a request for an address from the home link. The mobile node should include a zero-length INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Payload. The mobile node MAY include multiple instances of the INTERNAL_IP6_ADDRESS to request multiple home address to the assigned by the home agent.
移动节点可以通过在IKE_AUTH交换中包括配置有效负载来动态配置归属地址，并从归属链路请求地址。移动节点应在CFG_请求有效负载中包含长度为零的内部_IP6_地址属性。移动节点可以包括内部ip地址的多个实例，以请求由归属代理分配给移动节点的多个归属地址。
When the home agent receives a configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY contains the prefix length of the home prefix in addition to a 128 bit home address. The home agent could use a local database or contact a DHCPv6 server on the home link to allocate a home address. The duration for which the home address is allocated to the mobile node is the same as the duration for which an IKEv2 security association exists between the mobile node and the home agent. If the IKEv2 security association is rekeyed, the home address lifetime is also extended.
当归属代理接收到一个配置有效负载，该配置有效负载带有一个针对内部\u IP6\u地址的CFG\u请求时，它会使用移动节点的有效归属地址进行回复。CFG_回复中的INTERNAL_IP6_ADDRESS属性除了包含128位主地址外，还包含主前缀的前缀长度。归属代理可以使用本地数据库或通过归属链接联系DHCPv6服务器来分配归属地址。归属地址分配给移动节点的持续时间与移动节点和归属代理之间存在IKEv2安全关联的持续时间相同。如果IKEv2安全关联被重新设置密钥，则家庭地址生存期也会延长。
Mobile Node Home Agent
----------- ----------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, CP(CFG_REQUEST),
SAi2, TSi, TSr}
-->
Mobile Node Home Agent
----------- ----------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, CP(CFG_REQUEST),
SAi2, TSi, TSr}
-->
<-- HDR, SK {IDr, [CERT,] AUTH, CP(CFG_REPLY), SAr2, TSi, TSr}
<--HDR，SK{IDr，[CERT，]AUTH，CP（CFG_回复），SAr2，TSi，TSr}
The mobile node could suggest a home address that it wants to use in the CFG_REQUEST. For example, this could be a home address that was allocated for the mobile node before or an address that the mobile node auto-configured from the IPv6 prefix on the home link. The Home Agent could let the mobile node use the same home address by setting the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same home address. If the home agent wants the mobile node to use a different home address, it sends a new home address in the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload. The Mobile Node MUST stop using its old home address and start using the newly allocated home address.
移动节点可以建议它希望在CFG_请求中使用的家庭地址。例如，这可以是之前为移动节点分配的家庭地址，也可以是移动节点根据家庭链路上的IPv6前缀自动配置的地址。归属代理可以通过将CFG_应答负载中的INTERNAL_IP6_address属性设置为相同的归属地址，让移动节点使用相同的归属地址。如果归属代理希望移动节点使用不同的归属地址，它将在CFG_应答负载的内部_IP6_address属性中发送一个新的归属地址。移动节点必须停止使用其旧的家庭地址，并开始使用新分配的家庭地址。
In case the home agent is unable to allocate a home address for the mobile node during the IKE_AUTH exchange, it MUST send a Notify Payload with an INTERNAL_ADDRESS_FAILURE message. When the mobile node receives a Notify Payload with an INTERNAL_ADDRESS_FAILURE message, it SHOULD terminate the IKE_AUTH exchange. The mobile node then should initiate a new IKE_SA_INIT and IKE_AUTH exchange and try to auto-configure a home address as described in [13]. The mobile node MAY also switch to another home agent. The new home agent address can be obtained by consulting a home agent list received during a previous home agent discovery phase or, if such list is empty or not available, by attempting a new home agent discovery.
如果归属代理在IKE_身份验证交换期间无法为移动节点分配归属地址，则它必须发送带有内部_地址_失败消息的通知有效负载。当移动节点接收到带有内部地址失败消息的Notify有效负载时，它应该终止IKE身份验证交换。然后，移动节点应启动新的IKE_SA_INIT和IKE_AUTH交换，并尝试按照[13]中所述自动配置家庭地址。移动节点还可以切换到另一归属代理。新的归属代理地址可以通过查阅在先前归属代理发现阶段期间接收到的归属代理列表来获得，或者，如果该列表为空或不可用，则可以通过尝试新的归属代理发现来获得。
If the mobile node wants to configure a DNS server from the home link, it can request the DNS server information by including an INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload.
如果移动节点想要从主链路配置DNS服务器，它可以通过在CFG_请求有效负载中包括内部_IP6_DNS属性来请求DNS服务器信息。
This document describes how IPsec can be used to secure Mobile IPv6 signaling messages. Please refer to RFC 3775 [2] for security considerations related to the use of IPsec with Mobile IPv6.
本文档介绍如何使用IPsec保护移动IPv6信令消息。请参考RFC 3775[2]，了解与移动IPv6使用IPsec相关的安全注意事项。
A misbehaving mobile node could create IPsec security associations for a home address that belongs to another mobile node. Therefore, the home agent should check if a particular mobile node is authorized
行为不端的移动节点可能会为属于另一个移动节点的家庭地址创建IPsec安全关联。因此，归属代理应检查特定移动节点是否被授权
to use a home address before creating IPsec security associations for the home address. If the home address is assigned as described in Section 9, the home agent MUST associate the home address with the identity used in IKE negotiation. The home agent MAY store the assigned home address in the SPD entries created for the mobile node.
在为家庭地址创建IPsec安全关联之前使用家庭地址。如果按照第9节所述分配家庭地址，则家庭代理必须将家庭地址与IKE协商中使用的标识相关联。归属代理可以将分配的归属地址存储在为移动节点创建的SPD条目中。
The use of EAP for authenticating the mobile node to the home agent is described in Section 8. Security considerations related to the use of EAP with IKEv2 are described in [4].
第8节描述了使用EAP向归属代理认证移动节点。[4]中描述了与IKEv2使用EAP相关的安全注意事项。
The authors would like to thank Mika Joutsenvirta, Pasi Eronen, Jari Arkko, Gerardo Giaretta, Shinta Sugimoto, Tero Kivinen, Steve Bellovin, Kilian Weniger, and Vijay Gurbani for reviewing the document.
作者要感谢Mika Joutsenvirta、Pasi Eronen、Jari Arkko、Gerardo Giaretta、Shinta Sugimoto、Tero Kivinen、Steve Bellovin、Kilian Weniger和Vijay Gurbani审阅了该文件。
Many of the requirements listed in Section 4 are copied from RFC 3776. Therefore, the authors of RFC 3776 are acknowledged.
第4节中列出的许多要求是从RFC 3776中复制的。因此，RFC3776的作者是公认的。
[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] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[2] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[3] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[3] Arkko，J.，Devarapalli，V.，和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 37762004年6月。
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[4] Kaufman，C.，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[5] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[6] Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[7] Giaretta, G., "AAA Goals for Mobile IPv6", Work in Progress, September 2006.
[7] Giaretta，G.，“移动IPv6的AAA目标”，进展中的工作，2006年9月。
[8] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ ISAKMP, IKEv2, and PKIX", Work in Progress, February 2007.
[8] Korver，B.，“IKEv1/ISAKMP、IKEv2和PKIX的互联网IP安全PKI配置文件”，正在进行的工作，2007年2月。
[9] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[9] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[10] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[10] Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[11] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[11] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[12] Sugimoto, S., "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", Work in Progress, September 2006.
[12] Sugimoto，S.，“作为移动IPv6和IPsec/IKE之间接口的PF_密钥扩展”，正在进行的工作，2006年9月。
[13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", Work in Progress, December 2006.
[13] Giaretta，G.“拆分场景中的移动IPv6引导”，正在进行的工作，2006年12月。
Authors' Addresses
作者地址
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA
Vijay Devarapalli Azaire Networks美国加利福尼亚州圣克拉拉市杰街3121号，邮编95054
EMail: vijay.devarapalli@azairenet.com
EMail: vijay.devarapalli@azairenet.com
Francis Dupont CELAR
弗朗西斯·杜邦·塞拉
EMail: Francis.Dupont@fdupont.fr
EMail: Francis.Dupont@fdupont.fr
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。