Network Working Group B. Patil
Request for Comments: 5419 Nokia
Category: Informational G. Dommety
Cisco
January 2009
Network Working Group B. Patil
Request for Comments: 5419 Nokia
Category: Informational G. Dommety
Cisco
January 2009
Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
为什么移动IPv6（MIPv6）需要身份验证数据子选项
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the Binding Update (BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments.
移动IPv6定义了一组信令消息，使移动节点（MN）能够通过其归属代理（HA）进行身份验证和注册。移动节点和归属代理之间的这些认证信令消息由MN和HA之间建立的IPsec安全关联（SA）保护。MIP6工作组已经指定了一种机制，以使用身份验证选项（类似于移动IPv4中的身份验证选项）来保护绑定更新（BU）和绑定确认（BAck）消息，该身份验证选项携带在MN和HA之间交换的信令消息中，以建立绑定。本文档提供了在某些环境中部署移动IPv6需要身份验证选项机制的理由。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Background ......................................................3
4. Applicability Statement .........................................3
5. Justification for the Use of the Authentication Option ..........5
5.1. Motivation for Use of the Authentication Option in
CDMA2000 ...................................................5
5.2. Additional Arguments for the Use of the
Authentication Option ......................................6
6. Application of Mobile IPv6 in CDMA Networks .....................9
6.1. IPv4-Based Mobility Architecture in CDMA2000 Networks ......9
6.2. IPv6-Based Mobility Architecture in CDMA2000 Networks .....11
6.2.1. Overview of the Mobility Operation in
IPv6-Based CDMA2000 Networks .......................11
6.2.2. Authentication and Security Details ................12
7. Limitations of the Authentication Protocol Option ..............14
8. Security Considerations ........................................16
9. Conclusion .....................................................16
10. Acknowledgements ..............................................17
11. References ....................................................17
11.1. Normative References .....................................17
11.2. Informative References ...................................18
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Background ......................................................3
4. Applicability Statement .........................................3
5. Justification for the Use of the Authentication Option ..........5
5.1. Motivation for Use of the Authentication Option in
CDMA2000 ...................................................5
5.2. Additional Arguments for the Use of the
Authentication Option ......................................6
6. Application of Mobile IPv6 in CDMA Networks .....................9
6.1. IPv4-Based Mobility Architecture in CDMA2000 Networks ......9
6.2. IPv6-Based Mobility Architecture in CDMA2000 Networks .....11
6.2.1. Overview of the Mobility Operation in
IPv6-Based CDMA2000 Networks .......................11
6.2.2. Authentication and Security Details ................12
7. Limitations of the Authentication Protocol Option ..............14
8. Security Considerations ........................................16
9. Conclusion .....................................................16
10. Acknowledgements ..............................................17
11. References ....................................................17
11.1. Normative References .....................................17
11.2. Informative References ...................................18
Mobile IPv6 relies on the IPsec Security Association between the Mobile Node (MN) and the Home Agent (HA) for authentication of the MN to its HA before a binding cache can be created at the HA. An alternate mechanism that does not rely on the existence of the IPsec SA between the MN and HA for authenticating the MN is needed in certain deployment environments. Such an alternate mechanism is outlined in [RFC4285]. This document is intended to capture for archival purposes the reasoning behind the need for the authentication protocol [RFC4285]. It should be noted that the alternate solution does not imply that the IPsec-based solution will be deprecated. It simply means that in certain deployment scenarios there is a need for supporting MIPv6 without an IPsec SA between the MN and HA. So the alternate solution is in addition to the IPsec-based mechanism specified in the base RFCs, i.e., [RFC3775], [RFC3776], and [RFC4877]. It has been noted that some of the challenges of deploying MIPv6 in certain types of networks arose from dependence on the Internet Key Exchange (IKE), which did not integrate well with an Authentication, Authorization, and Accounting (AAA) backend infrastructure. IKEv2 solves this problem. However, at the time of discussion on the need for the authentication
移动IPv6依赖于移动节点（MN）和归属代理（HA）之间的IPsec安全关联，以便在可以在HA处创建绑定缓存之前，将MN身份验证到其HA。在某些部署环境中，需要一种不依赖于MN和HA之间是否存在IPsec SA来验证MN的替代机制。[RFC4285]中概述了这种替代机制。本文件旨在为存档目的，获取认证协议[RFC4285]需求背后的原因。应该注意的是，替代解决方案并不意味着基于IPsec的解决方案将被弃用。这仅仅意味着在某些部署场景中，需要在MN和HA之间支持没有IPsec SA的MIPv6。因此，替代解决方案是对基本RFC中指定的基于IPsec的机制的补充，即[RFC3775]、[RFC3776]和[RFC4877]。已经注意到，在某些类型的网络中部署MIPv6的一些挑战源于对Internet密钥交换（IKE）的依赖，IKE没有很好地与身份验证、授权和计费（AAA）后端基础设施集成。IKEv2解决了这个问题。但是，在讨论认证的必要性时
protocol, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture" [RFC4877] was still a work in progress and, as a result, an alternative solution was needed.
协议“使用IKEv2和经修订的IPsec体系结构的移动IPv6操作”[RFC4877]仍在进行中，因此需要一个替代解决方案。
It should be noted that some of the arguments for justifying the specification of the authentication protocol have been made redundant as a result of the specification of Mobile IPv6 operation with IKEv2 [RFC4877]. However, some of the arguments discussed in this document are still applicable and justify usage of the authentication protocol in certain deployment environments.
应该注意的是，由于IKEv2[RFC4877]的移动IPv6操作规范，证明认证协议规范的一些论点变得多余。然而，本文档中讨论的一些参数仍然适用，并证明在某些部署环境中使用身份验证协议是合理的。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Mobile IPv6 signaling involves several messages. These include:
移动IPv6信令涉及多条消息。这些措施包括：
o The Binding Update/Binding Acknowledgment between the mobile node and the home agent.
o 移动节点和归属代理之间的绑定更新/绑定确认。
o The route optimization signaling messages, which include the HoTI-HoT (Home Test Init/Home Test), CoTI-CoT (Care-of Test Init/ Care-of Test), and BU-BAck messages between the MN and CN. HoTI and HoT signaling messages are routed through the MN's HA.
o 路由优化信令消息，包括MN和CN之间的HoTI HoT（Home Test Init/Home Test）、CoTI CoT（Care of Test Init/Care of Test）和BU BAck消息。HoTI和HoT信令消息通过MN的HA路由。
o Mobile prefix solicitation and advertisements between the MN and HA.
o MN和HA之间的移动前缀请求和广告。
o Home agent discovery by MNs.
o MNs的Home agent发现。
The signaling messages between the MN and HA are secured using the IPsec SA that is established between these entities. The exception to this are the messages involved in the home agent discovery process. [RFC4877] specifies the establishment of the IPsec SA using IKEv2.
MN和HA之间的信令消息使用在这些实体之间建立的IPsec SA进行保护。例外情况是归属代理发现过程中涉及的消息。[RFC4877]指定使用IKEv2建立IPsec SA。
The authentication option specified in "Authentication Protocol for MIPv6" [RFC4285] provides a solution for MIPv6 deployment in environments in which an operator may not require IPsec-based security for the signaling. The reasons for an operator choosing to
“MIPv6的身份验证协议”[RFC4285]中指定的身份验证选项为在运营商可能不需要基于IPsec的信令安全性的环境中部署MIPv6提供了解决方案。运营商选择
deploy MIPv6 without mandating IPsec-based security for signaling messages between the MN and HA could be many. Some of these are, for example:
部署MIPv6而不强制要求MN和HA之间的信令消息具有基于IPsec的安全性可能很多。其中一些是，例如：
1. Operators deploying MIPv6 in cellular networks may consider IPsec and IKEv2 as adding overhead to the limited bandwidth over the air interface. The overhead here is in terms of the bytes that IPsec and IKEv2 introduce to the signaling.
1. 在蜂窝网络中部署MIPv6的运营商可以考虑将IPSec和IKEv2作为开销增加到空中接口上的有限带宽。这里的开销是IPsec和IKEv2引入信令的字节数。
2. Operators may consider the number of messages between the MN and HA that are required to establish the IPsec SA as too many. The number of transactions chew into the capacity of limited bandwidth air interfaces when MIPv6 is used in such environments. It also adds additional latency to the establishment of the binding.
2. 运营商可能会考虑MN和HA之间的消息数量，需要建立IPSec SA太多。在这种环境中使用MIPv6时，事务的数量会影响有限带宽空中接口的容量。它还为绑定的建立增加了额外的延迟。
3. In many deployments, authentication credentials already exist in a AAA server. These credentials are used for authenticating a user and authorizing network access. The same credentials and security parameters cannot be reused for MIPv6 security as well, if IKEv1 is used.
3. 在许多部署中，AAA服务器中已经存在身份验证凭据。这些凭据用于验证用户和授权网络访问。如果使用了IKEv1，那么同样的凭证和安全参数也不能用于MIPv6安全性。
4. Dynamic assignment of home agents is needed in certain deployments to minimize the latency of the backhaul. This is done by allocating an HA in a visited network, for example. Requiring IPsec SAs with home agents that are dynamically assigned is an overhead, especially when the HA is in a visited network.
4. 在某些部署中需要动态分配归属代理，以最小化回程延迟。例如，这是通过在访问的网络中分配HA来实现的。需要具有动态分配的归属代理的IPsec SAs是一种开销，特别是当HA位于访问的网络中时。
5. In certain deployments, signaling messages between the MN and HA may be over secure link layers. The lower layers provide ciphering and security for the messages, and hence the need for IPsec to do the same for MIPv6 messages does not exist.
5. 在某些部署中，MN和HA之间的信令消息可以通过安全链路层。较低的层为消息提供加密和安全性，因此不需要IPsec对MIPv6消息执行同样的操作。
One example of networks that have such characteristics are Code Division Multiple Access (CDMA) networks as defined in the 3GPP2 [3GPP2 X.S0011-002-D] specification. Mobile WiMAX (Worldwide Interoperability for Microwave Access), which is based on IEEE 802.16e, also specifies in the network architecture the use of MIPv6, with the default security for signaling being the authentication protocol [RFC4285]. The WiMAX network architecture specifications are available at [WiMAX-NWG].
具有这种特性的网络的一个示例是3GPP2[3GPP2 X.S0011-002-D]规范中定义的码分多址（CDMA）网络。基于IEEE 802.16e的移动WiMAX（微波接入的全球互操作性）也在网络体系结构中指定了MIPv6的使用，信令的默认安全性是认证协议[RFC4285]。WiMAX网络架构规范可从[WiMAX NWG]获得。
The following two sections provide the reasoning for why the authentication option-based registration process for Mobile IPv6 is needed. Section 5.1 provides key arguments for the use of the authentication option. Section 5.2 provides further explanation and additional motivations for the authentication option.
以下两部分说明了为什么需要移动IPv6的基于身份验证选项的注册过程。第5.1节提供了使用身份验证选项的关键参数。第5.2节提供了认证选项的进一步解释和其他动机。
5.1. Motivation for Use of the Authentication Option in CDMA2000 Wireless Networks
5.1. CDMA2000无线网络中使用认证选项的动机
CDMA2000 networks deployed and operational today use Mobile IPv4 for IP mobility. Operators have gained a significant amount of operational experience in the process of deploying and operating these networks. 3GPP2 has specified Mobile IPv6 operation in the [3GPP2 X.S0011-002-D] specification. The following are the deployment constraints that existing CDMA networks have to deal with when deploying mobility service based on IPv6:
目前部署和运行的CDMA2000网络使用移动IPv4进行IP移动。运营商在部署和运营这些网络的过程中积累了大量的运营经验。3GPP2在[3GPP2 X.S0011-002-D]规范中指定了移动IPv6操作。以下是现有CDMA网络在部署基于IPv6的移动服务时必须处理的部署约束：
o Operators intend to leverage the Mobile IPv4 deployment and operational experience by ensuring that Mobile IPv6 has a similar deployment and operating model.
o 运营商打算利用移动IPv4部署和运营经验，确保移动IPv6具有类似的部署和运营模式。
o Operators will have two parallel networks: one that offers IPv4 mobility with MIPv4 and another providing IPv6 mobility using MIPv6.
o 运营商将拥有两个并行网络：一个使用MIPv4提供IPv4移动，另一个使用MIPv6提供IPv6移动。
o The same backend subscriber profile database, security keys, etc. are intended to be used for both Mobile IPv4 and Mobile IPv6 service. However, from a security standpoint, the reuse of the same keys with multiple algorithms/protocols is a bad idea.
o 相同的后端订户配置文件数据库、安全密钥等将用于移动IPv4和移动IPv6服务。然而，从安全的角度来看，在多个算法/协议中重用相同的密钥是一个坏主意。
o The same user-configuration information, i.e., the identity and keys associated with a user, will be used for IP mobility service in IPv4 and/or IPv6 networks. The only security association that is preconfigured is a shared secret between the mobile node and the home AAA server. This is in contrast with an earlier version of the Mobile IPv6 model, which required an IPsec SA between the MN and HA. At the time of this writing, the IKEv2-based solution for establishing an IPsec SA [RFC4877] was not available. IKEv2 does enable integration with a AAA backend.
o 相同的用户配置信息，即与用户关联的身份和密钥，将用于IPv4和/或IPv6网络中的IP移动服务。预配置的唯一安全关联是移动节点和家庭AAA服务器之间的共享机密。这与较早版本的移动IPv6模型形成对比，后者需要在MN和HA之间使用IPsec SA。在撰写本文时，用于建立IPsec SA的基于IKEv2的解决方案[RFC4877]不可用。IKEv2支持与AAA后端的集成。
o At the time of specifying the authentication protocol, the Mobile IPv6 specification did not support the dynamic assignment of home agent and home address. However, work done in the MIP6 working group on bootstrapping of Mobile IPv6 as specified in [RFC5026] and "MIPv6-Bootstrapping for the Integrated Scenario" [BOOT] addresses this deficiency. The mechanism defined in
o 在指定身份验证协议时，移动IPv6规范不支持动态分配归属代理和归属地址。然而，MIP6工作组在[RFC5026]和“集成场景的MIPv6引导”[BOOT]中规定的移动IPv6引导方面所做的工作解决了这一缺陷。中定义的机制
"Authentication Protocol for Mobile IPv6" [RFC4285] is capable of handling authentication even in the case of dynamic assignments (and is similar to what is used in current MIPv4 deployments).
“移动IPv6身份验证协议”[RFC4285]即使在动态分配的情况下也能够处理身份验证（与当前MIPv4部署中使用的类似）。
Consequently, MIPv6 as specified at the time the authentication protocol was being specified, did not satisfy many of the deployment requirements. "Authentication Protocol for MIPv6" [RFC4285] along with "MN Identifier Option for MIPv6" [RFC4283] are enabling the deployment of Mobile IPv6 in a manner that is similar to what is deployed in CDMA2000 networks today. This authentication model is very similar to the one adopted by the MIP4 WG. This is explained in detail in [3GPP2 X.S0011-002-D].
因此，在指定身份验证协议时指定的MIPv6不能满足许多部署要求。“用于MIPv6的身份验证协议”[RFC4285]以及“用于MIPv6的MN标识符选项”[RFC4283]正在以类似于当今CDMA2000网络中部署的方式实现移动IPv6的部署。此身份验证模型与MIP4 WG采用的身份验证模型非常相似。[3GPP2 X.S0011-002-D]对此进行了详细说明。
The earlier MIPv6 deployment model, which requires an IPsec SA that is either configured manually or established using IKE, does not have synergy with the deployment models of 3GPP2 or WiMAX networks. This issue has however been alleviated with the publication of RFC 4877, which enables the establishment of an IPsec SA using IKEv2 and which is also able to integrate with the backend AAA infrastructure that is responsible for the authentication of the MN in 3GPP2 and WiMAX networks.
早期的MIPv6部署模型需要手动配置或使用IKE建立的IPsec SA，与3GPP2或WiMAX网络的部署模型没有协同作用。然而，随着RFC 4877的发布，这一问题得到了缓解，RFC 4877支持使用IKEv2建立IPsec SA，并且还能够与后端AAA基础设施集成，后者负责3GPP2和WiMAX网络中MN的认证。
The use of IPsec for performing Registration with a home agent is not always an optimal solution. While it is true that IPsec is viewed as an integral part of the IPv6 stack, it is still a considerable overhead from a deployment perspective of using IPsec as the security mechanism for the signaling messages between the MN and HA. This statement is a result of experience gained from deployment of Mobile IPv4. MIPv4 does not rely on IPsec for securing the Registration signaling messages.
使用IPsec执行与归属代理的注册并不总是最佳解决方案。虽然IPsec确实被视为IPv6协议栈的一个组成部分，但从部署的角度来看，将IPsec用作MN和HA之间的信令消息的安全机制仍然是相当大的开销。此声明是从部署移动IPv4中获得的经验的结果。MIPv4不依赖IPsec来保护注册信令消息。
Deployment of Mobile IPv6 on a large scale is possible only when the protocol is flexible for being adapted to various scenarios. The scenario being considered is the deployment in CDMA2000 networks or WiMAX networks. CDMA2000 networks are currently deployed in many countries today. WiMAX deployments in many countries began in 2008. The packet data network architecture of CDMA2000 [3GPP2 X.S0011-002-D] includes a MIPv4 foreign agent/home agent and a RADIUS-based AAA infrastructure for Authentication, Authorization, and Accounting purposes. The AAA infrastructure provides authentication capability in the case of Mobile IPv4.
只有当协议能够灵活地适应各种场景时，才能大规模部署移动IPv6。正在考虑的方案是在CDMA2000网络或WiMAX网络中部署。CDMA2000网络目前已在许多国家部署。WiMAX在许多国家的部署始于2008年。CDMA2000[3GPP2 X.S0011-002-D]的分组数据网络架构包括MIPv4外部代理/归属代理和基于RADIUS的AAA基础设施，用于身份验证、授权和计费。AAA基础设施在移动IPv4的情况下提供身份验证功能。
Typically, the mobile node shares a security association with the AAA-Home entity. This is the preferred mode of operation over having a shared secret between the MN and HA because the AAA-Home entity provides a central location for provisioning and administering the
通常，移动节点与AAA归属实体共享安全关联。与在MN和HA之间拥有共享机密相比，这是首选的操作模式，因为AAA Home实体为资源调配和管理提供了一个中心位置
shared secrets for a large number of mobiles (millions). This mode of operation also makes dynamic home address and dynamic home agent assignment easier. A similar approach is needed for the deployment of Mobile IPv6 in these networks. There is no practical mechanism to use IPsec directly with the AAA infrastructure without the use of IKEv2 or some other mechanism that enables the establishment of the IPsec SA between the MN and HA.
共享大量手机的秘密（百万）。这种操作模式还使动态家庭地址和动态家庭代理分配更容易。在这些网络中部署移动IPv6也需要类似的方法。如果不使用IKEv2或其他一些能够在MN和HA之间建立IPsec SA的机制，就没有实际的机制可以将IPsec直接用于AAA基础设施。
Mobile IPv6 as specified in [RFC3775] and [RFC3776] is based on a very specific model for deployment. It anticipates the mobile node's having a static home IPv6 address and a designated home agent. This is not practical in most deployment scenarios being considered. An IPsec SA is expected to be created via manual keying or established dynamically via IKE or IKEv2. These assumptions do not necessarily fit in very well for the deployment model envisioned in CDMA2000 or WiMAX networks. These limitations have however been overcome as a result of the bootstrapping specifications as per [RFC5026] and "MIPv6-Bootstrapping for the Integrated Scenario" [BOOT].
[RFC3775]和[RFC3776]中规定的移动IPv6基于非常特定的部署模型。它预期移动节点具有静态归属IPv6地址和指定的归属代理。这在正在考虑的大多数部署场景中是不实际的。IPsec SA应通过手动键控创建，或通过IKE或IKEv2动态建立。这些假设不一定非常适合CDMA2000或WiMAX网络中设想的部署模型。然而，由于[RFC5026]和“集成场景的MIPv6引导”[BOOT]中的引导规范，这些限制已被克服。
CDMA2000 and WiMAX networks would prefer to allocate home addresses to MNs on a dynamic basis. The advantage of doing so is the fact that the HA can be assigned on a link that is close to the MN's point of attachment. While route optimization negates the benefit of having a home agent on a link close to the MN, it cannot always be guaranteed that the MN and correspondent node (CN) will use or support route optimization. There may also be instances where the operator prefers to not allow route optimization for various reasons, such as accounting aggregation or enforcing service contracts. In such cases, an HA that is close to the MN's point of attachment reduces the issues of latency, etc. of forward and reverse tunnelling of packets between the MN and HA.
CDMA2000和WiMAX网络更倾向于动态地向MN分配家庭地址。这样做的优点是，可以在靠近MN连接点的链路上分配HA。虽然路由优化否定了在靠近MN的链路上具有归属代理的好处，但不能总是保证MN和对应节点（CN）将使用或支持路由优化。也可能存在这样的情况，即运营商出于各种原因（例如会计汇总或强制执行服务契约）而不允许路由优化。在这种情况下，靠近MN的连接点的HA减少了MN和HA之间的分组的正向和反向隧道的延迟等问题。
CDMA2000 networks that are operational today have large numbers of subscribers who are authenticated via the AAA infrastructure. Deployment of Mobile IPv6 should leverage the existing AAA infrastructure. The security model needed in these networks is an SA between the MN and AAA-Home entity. This is the primary security association that should be used for authenticating and authorizing users to utilize MIPv6 service. This SA is then used for establishing session keys between the MN and the dynamically assigned HA for authenticating subsequent Binding Updates and Binding Acknowledgements between them. Establishing an IPsec SA between the MN and HA using AAA infrastructure was not specified for Mobile IPv6 at the time the authentication protocol was being specified. RFC 3776 explains how IKE is used for establishing the SA between the MN and HA. [RFC4877] has been published subsequently and hence the issue of establishing an IPsec SA dynamically between the MN and HA no longer exists. CDMA2000 network operators would prefer to assign
目前运行的CDMA2000网络拥有大量通过AAA基础设施进行身份验证的用户。移动IPv6的部署应利用现有的AAA基础设施。这些网络中需要的安全模型是MN和AAA归属实体之间的SA。这是应用于验证和授权用户使用MIPv6服务的主要安全关联。然后，该SA用于在MN和动态分配的HA之间建立会话密钥，以验证它们之间的后续绑定更新和绑定确认。在指定身份验证协议时，未为移动IPv6指定使用AAA基础结构在MN和HA之间建立IPsec SA。RFC 3776解释了IKE如何用于在MN和HA之间建立SA。[RFC4877]随后发布，因此不再存在在MN和HA之间动态建立IPsec SA的问题。CDMA2000网络运营商更愿意分配
home addresses to the MN on a dynamic basis -- preferably using the AAA infrastructure, which contains subscriber profile and capability information. This was not possible prior to the specification of the bootstrapping mechanism in [RFC5026].
MN的主地址是动态的——最好使用AAA基础设施，其中包含订户配置文件和能力信息。在[RFC5026]中指定引导机制之前，这是不可能的。
A large subset of MNs in CDMA2000 networks do not have IKE capability. As a result, the use of RFC 3776 for setting up the MN-HA IPsec SA is not an option. It should also be noted that IKE requires several transactions before it is able to establish the IPsec SA. [RFC4877] specifies the establishment of an IPsec SA between the MN and HA using IKEv2. It is possible that not all MNs in a deployment will support IKEv2, and hence an alternative mechanism provides the needed flexibility.
CDMA2000网络中的很大一部分MN不具备IKE能力。因此，使用RFC 3776来设置MN-HA IPsec SA不是一个选项。还应注意，IKE在能够建立IPsec SA之前需要几个事务。[RFC4877]指定使用IKEv2在MN和HA之间建立IPsec SA。部署中的所有MN可能都不支持IKEv2，因此另一种机制提供了所需的灵活性。
CDMA2000 network operators are extremely conscious in terms of the number of messages sent and received over the air interface for signaling. The overhead associated with sending/receiving a large number of signaling messages over the air interface has a direct impact on the overall capacity and cost for the operator. Optimization of the number of messages needed for using a service like Mobile IPv6 is of great concern. As a result, the use of IKE for Mobile IPv6 deployment is considered as being suboptimal in certain network architectures and deployment scenarios from the perspective of message overhead.
CDMA2000网络运营商对于通过信令空中接口发送和接收的消息数量非常敏感。通过空中接口发送/接收大量信令消息的相关开销直接影响运营商的总体容量和成本。优化使用移动IPv6等服务所需的消息数量是一个非常令人关注的问题。因此，从消息开销的角度来看，在某些网络体系结构和部署场景中，将IKE用于移动IPv6部署被认为是次优的。
Another downside of IKE for setting up the IPsec SA between the MN and HA is that IKE does not integrate very well with the RADIUS-based AAA backend. Since operators rely on the AAA infrastructure to provision subscribers as well as define profiles, keys, etc. in the AAA-Home, there is no getting away from the use of AAA in CDMA2000 networks. IKEv2 does address this problem. However, from a timeline perspective, the availability of IKEv2 specifications for "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture" [RFC4877] and its implementations did not meet the need of operators that were relying on 3GPP2 specifications. With the specification of IKEv2 and publication of RFC 4877, integration with AAA backends is no longer an issue.
IKE在MN和HA之间设置IPsec SA的另一个缺点是IKE不能很好地与基于RADIUS的AAA后端集成。由于运营商依靠AAA基础设施为用户提供服务，并在AAA家庭中定义配置文件、密钥等，因此在CDMA2000网络中使用AAA是不可避免的。IKEv2确实解决了这个问题。然而，从时间轴的角度来看，“使用IKEv2和修订的IPsec体系结构的移动IPv6操作”[RFC4877]及其实现的IKEv2规范的可用性并不能满足依赖3GPP2规范的运营商的需求。随着IKEv2的规范和RFC4877的发布，与AAA后端的集成不再是一个问题。
In summary, the model of Mobile IPv6 deployment that mandated the existence of an IPsec SA between the MN and HA, as specified in RFCs 3775 and 3776, was too rigid and did not meet the requirements of operators building networks based on the CDMA2000 [3GPP2 X.S0011-002-D] specifications. To address this shortcoming, the authentication protocol [RFC4285] was specified.
总之，按照RFCs 3775和3776的规定，移动IPv6部署模式要求在MN和HA之间存在IPsec SA，该模式过于严格，不符合运营商基于CDMA2000[3GPP2 X.S0011-002-D]规范构建网络的要求。为了解决这个缺点，指定了身份验证协议[RFC4285]。
Sections 6.1 and 6.2 describe the IPv4- and IPv6-based mobility architectures in CDMA networks, respectively. For further details associated with the description below, please refer to Section 5, "MIP6 Operation", in the 3GPP2 specification [3GPP2 X.S0011-002-D].
第6.1节和第6.2节分别描述了CDMA网络中基于IPv4和IPv6的移动架构。有关以下描述的更多详细信息，请参阅3GPP2规范[3GPP2 X.S0011-002-D]中的第5节“MIP6操作”。
The figure below shows a high level view of the key network elements that play a role in providing IP mobility using Mobile IPv4.
下图显示了在使用移动IPv4提供IP移动性方面发挥作用的关键网络元素的高级视图。
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| |F-AAA | | | |H-AAAH| |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ PDSN + -- -- -- -- - + HA | |
| | | | /FA | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| |F-AAA | | | |H-AAAH| |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ PDSN + -- -- -- -- - + HA | |
| | | | /FA | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+
Figure 1: CDMA2000 Packet Data Network Architecture with Mobile IPv4
图1：使用移动IPv4的CDMA2000分组数据网络体系结构
The CDMA mobility architecture based on MIPv4 is explained below. In this architecture, mobility is tightly integrated with the AAA infrastructure. The Mobile Node is configured with an NAI (Network Access Identifier) and an MN-AAA key. The MN-AAA key is a shared key that is shared between the MN and the home AAA server.
下面解释基于MIPv4的CDMA移动架构。在这种架构中，移动性与AAA基础设施紧密集成。移动节点配置有NAI（网络接入标识符）和MN-AAA密钥。MN-AAA密钥是MN和家庭AAA服务器之间共享的共享密钥。
Below is the access link setup procedure:
以下是访问链接设置过程：
(1) Bring up the PPP on the MN/PDSN (access router link). PPP authentication is skipped. Mobile IP authentication is performed via the FA (Foreign Agent).
(1) 在MN/PDSN（接入路由器链路）上启动PPP。跳过PPP身份验证。通过FA（外部代理）执行移动IP身份验证。
(2) The PDSN (Packet Data Serving Node) sends a Mobile IP challenge to the MN on the PPP link (RFC 3012).
(2) PDSN（分组数据服务节点）在PPP链路上向MN发送移动IP质询（rfc3012）。
(3) The MN sends a MIP Registration Request (RRQ), which includes the user's NAI, challenge, and MN-AAA extension that has a challenge response, and an MN-HA extension, which is generated based on the MN-HA key.
(3) MN发送MIP注册请求（RRQ），该请求包括用户的NAI、质询和具有质询响应的MN-AAA扩展，以及基于MN-HA密钥生成的MN-HA扩展。
(4) The PDSN extracts the MIP NAI, challenge, and the response to the challenge, from the MIP MN-AAA extension, and sends an Access Request to the F-AAA (challenge/response using MD5).
(4) PDSN从MIP MN-AAA扩展提取MIP NAI、质询和质询响应，并向F-AAA发送访问请求（使用MD5的质询/响应）。
(5) The F-AAA (Foreign AAA) may forward it to the H-AAA (Home AAA) if needed (based on realm).
(5) 如果需要（基于领域），F-AAA（国外AAA）可以将其转发给H-AAA（国内AAA）。
(6) AAA authenticates the CHAP-challenge/response and returns "success" if authentication succeeds.
(6) AAA验证CHAP质询/响应，如果验证成功，则返回“成功”。
(7) The PDSN forwards the Registration Request (RRQ) to the HA.
(7) PDSN将注册请求（RRQ）转发给HA。
(8) The HA authenticates the RRQ (MHAE (Mobile-Home Authentication Extension)). The HA may optionally authenticate with the AAA infrastructure (just like the PDSN in #4).
(8) HA认证RRQ（MHAE（移动家庭认证扩展））。HA可以选择使用AAA基础设施进行身份验证（就像#4中的PDSN）。
(9) If authentication is successful, the HA creates a binding and sends a success Registration Reply (RRP) to the PDSN.
(9) 如果身份验证成功，HA将创建绑定并向PDSN发送成功注册回复（RRP）。
(10) The PDSN creates a visitor entry and forwards the RRP to the MN.
（10） PDSN创建访客条目并将RRP转发给MN。
Due to the need for co-existence with MIPv4, and having the same operational model, the 3GPP2 standards body is adopting the following mobility architecture for MIPv6.
由于需要与MIPv4共存，并且具有相同的操作模型，3GPP2标准机构正在为MIPv6采用以下移动性架构。
Access Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| |F-AAA | | | |H-AAA | |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ PDSN + -- -- -- -- - + HA | |
| | | | /AR | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+
Access Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| |F-AAA | | | |H-AAA | |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ PDSN + -- -- -- -- - + HA | |
| | | | /AR | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+
Figure 2: CDMA2000 Packet Data Network Architecture with Mobile IPv6
图2：使用移动IPv6的CDMA2000分组数据网络体系结构
The Mobile Node is configured with an NAI (Network Access Identifier) and an MN-AAA key. The MN-AAA key is a shared key between the MN and the home AAA server.
移动节点配置有NAI（网络接入标识符）和MN-AAA密钥。MN-AAA密钥是MN和家庭AAA服务器之间的共享密钥。
6.2.1. Overview of the Mobility Operation in IPv6-Based CDMA2000 Networks
6.2.1. 基于IPv6的CDMA2000网络中的移动性操作概述
The following steps explain at a very generic level the operation of IP mobility in CDMA2000 networks:
以下步骤在非常一般的层面上解释了CDMA2000网络中IP移动性的操作：
(1) The MN performs link-layer establishment. This includes setting up the PPP link. PPP-CHAP authentication is performed. This is authenticated by the PDSN/AR (Access Router) by sending an Access Request to the F-AAA (and to the H-AAA when/if needed). Optionally, the MN acquires bootstrap information from the Home Network (via the PDSN; the PDSN receives this information in Access Accept). The bootstrap information includes home address and home agent assignment. The MN uses stateless DHCPv6 [RFC3736] to obtain the bootstrap information from the PDSN.
(1) MN执行链路层建立。这包括建立PPP链接。执行PPP-CHAP身份验证。这由PDSN/AR（接入路由器）通过向F-AAA（以及在需要时/如果需要的话向H-AAA）发送接入请求来认证。可选地，MN从家庭网络获取引导信息（通过PDSN；PDSN在Access Accept中接收该信息）。引导信息包括家庭地址和家庭代理分配。MN使用无状态DHCPv6[RFC3736]从PDSN获取引导信息。
(2) The MN begins to use the home address (HoA) that was assigned in step 1. If no HoA was assigned at step 1, the MN generates (auto-configures) an IPv6 global unicast address based on the prefix information received at step 1.
(2) MN开始使用在步骤1中分配的家庭地址（HoA）。如果在步骤1没有分配HoA，MN将根据在步骤1接收到的前缀信息生成（自动配置）IPv6全局单播地址。
(3) The MN sends a Binding Update to the selected home agent. In the BU, the MN includes the NAI option, timestamp option, and MN-AAA auth option.
(3) MN向所选的归属代理发送绑定更新。在BU中，MN包括NAI选项、时间戳选项和MN-AAA认证选项。
(4) The HA extracts the NAI, authenticator, etc. from the BU and sends an Access Request to the Home RADIUS server.
(4) HA从BU提取NAI、验证器等，并向家庭RADIUS服务器发送访问请求。
(5) The Home RADIUS server authenticates and authorizes the user and sends back a RADIUS Access Accept to the HA indicating successful authentication and authorization.
(5) 家庭RADIUS服务器对用户进行身份验证和授权，并向HA发回RADIUS访问接受，表示身份验证和授权成功。
(6) The HA performs a replay check with the ID field in the received BU. The HA also performs proxy Duplicate Address Detection (DAD) on the MN's home address (global) using proxy Neighbor Solicitation as specified in [RFC4861].
(6) HA使用接收到的BU中的ID字段执行重播检查。HA还使用[RFC4861]中规定的代理邻居请求对MN的家庭地址（全局）执行代理重复地址检测（DAD）。
(7) Assuming that proxy DAD is successful, the HA sends back a Binding Acknowledgment to the MN. In this BAck message, the HA includes the MN-HA mobility option, NAI mobility option, and ID mobility option.
(7) 假设代理DAD成功，HA向MN发回绑定确认。在该返回消息中，HA包括MN-HA移动性选项、NAI移动性选项和ID移动性选项。
Access Link Setup, Access Authentication, and Bootstrapping:
访问链接设置、访问身份验证和引导：
(1) The MN brings up a PPP session. The PDSN triggers the MN to perform CHAP authentication, as part of access authentication, while bringing up the PPP link.
(1) MN启动PPP会话。PDSN触发MN执行CHAP身份验证，作为访问身份验证的一部分，同时启动PPP链路。
(2) The MN is authenticated using the PPP-CHAP by the H-AAA (Home AAA), via the F-AAA (Foreign AAA).
(2) MN由H-AAA（家庭AAA）通过F-AAA（外国AAA）使用PPP-CHAP进行身份验证。
(3) The H-AAA may optionally send the HoA and HA IP address to the PDSN for bootstrapping the MN (skipping details).
(3) H-AAA可以选择性地将HoA和HA IP地址发送到PDSN以引导MN（跳过详细信息）。
Mobile IPv6 Authentication:
移动IPv6身份验证：
The call flow for the initial authentication (the numbers in the parentheses correspond to the explanation below):
初始身份验证的调用流（括号中的数字对应于以下说明）：
MN HA H-AAA
| BU to HA (4) | RADIUS Access-ReQ(5)
|------------------------------------>|------------------->|(6)
| (includes NAI option, MN-ID option, | |
| Mesg ID option, MN-AAA auth option) |RADIUS Access Accept|(7)
|
|<-------------------|
| | |
| HA/AAAH authenticates MN
|
| |(8)
|
| |
|
| BAck to MN (9) |
|
|<------------------------------------|--------------------|
| (including MN-ID option, | (10)
| Message ID option, |
| MN-HA auth options) | |
MN HA H-AAA
| BU to HA (4) | RADIUS Access-ReQ(5)
|------------------------------------>|------------------->|(6)
| (includes NAI option, MN-ID option, | |
| Mesg ID option, MN-AAA auth option) |RADIUS Access Accept|(7)
|
|<-------------------|
| | |
| HA/AAAH authenticates MN
|
| |(8)
|
| |
|
| BAck to MN (9) |
|
|<------------------------------------|--------------------|
| (including MN-ID option, | (10)
| Message ID option, |
| MN-HA auth options) | |
Figure 3: Flow Diagram for Initial Authentication
图3：初始身份验证的流程图
(4) The MN sends a Binding Update (BU) to the HA. The Binding Update is authenticated using the MN-AAA option. The authenticator in the MN-AAA option is calculated using the hash of the BU and MN-AAA shared key. It uses the HMAC_SHA1 algorithm. The Security Parameter Index (SPI) field in MN-AAA is set to 3 (as per [RFC4285]). The BU also includes the NAI and timestamp, among other details. The hash of the BU includes the 'timestamp' option and thus provides proof of liveness to prevent replay.
(4) MN向HA发送绑定更新（BU）。绑定更新使用MN-AAA选项进行身份验证。MN-AAA选项中的验证器是使用BU和MN-AAA共享密钥的散列计算的。它使用HMAC_SHA1算法。MN-AAA中的安全参数索引（SPI）字段设置为3（根据[RFC4285]）。BU还包括NAI和时间戳等细节。BU的散列包含“timestamp”选项，因此提供活动性证明以防止重播。
(5) The HA, on receiving the BU, extracts the NAI, timestamp, and authenticator from the MN-AAA option, and generates the hash of the BU. The HA sends an Access Request to the AAA and puts this information in 3GPP2-defined VSAs (Vendor Specific Attributes). The NAI is inserted in the username option in the Access Request message. The other attributes sent are: the timestamp option, the hash of the BU (till SPI field of MN-AAA auth option), and the authentication data from the MN-AAA auth option.
(5) HA在接收到BU时，从MN-AAA选项中提取NAI、时间戳和验证器，并生成BU的哈希。HA向AAA发送访问请求，并将该信息放入3GPP2定义的VSA（供应商特定属性）中。NAI插入到访问请求消息的用户名选项中。发送的其他属性有：timestamp选项、BU的哈希（MN-AAA auth选项的直到SPI字段），以及来自MN-AAA auth选项的身份验证数据。
(6) AAA (RADIUS server that interprets these attributes) authenticates the MN based on the hash of the BU and the authenticator. Proceed to step 7.
(6) AAA（解释这些属性的RADIUS服务器）基于BU和验证器的哈希对MN进行身份验证。继续执行步骤7。
(7) AAA calculates a session key based on the MN-AAA shared secret and timestamp, and sends this to the HA in an Access Accept (in a 3GPP2-defined VSA).
(7) AAA基于MN-AAA共享秘密和时间戳计算会话密钥，并在访问接受（在3GPP2定义的VSA中）中将其发送给HA。
(8) The HA creates a binding and a security association per Authentication Protocol for MIPv6 [RFC4285]. The key for this association is retrieved from the Access Accept and is referred to as the session key. The HA associates a fixed SPI of 5 with this SA, and is associated with the binding for the MN. (The description of this step skips the details for timestamp processing at the HA.)
(8) HA根据MIPv6[RFC4285]的身份验证协议创建绑定和安全关联。此关联的密钥从Access Accept中检索，称为会话密钥。HA将5的固定SPI与该SA关联，并与MN的绑定关联。（此步骤的描述跳过HA时间戳处理的详细信息。）
(9) The HA sends a Binding Acknowledgement (BAck) to the MN. The BAck has the MN-HA authentication option, authenticated using the session key. This option has the SPI set to 5.
(9) HA向MN发送绑定确认（返回）。背面有MN-HA身份验证选项，使用会话密钥进行身份验证。此选项将SPI设置为5。
(10) On receiving a BAck, the MN calculates the session key (using the same method as AAA) and associates it with an SPI value of 5.
（10） 在收到回执时，MN计算会话密钥（使用与AAA相同的方法），并将其与SPI值5相关联。
The MN derives the session key and SA using the timestamp in the BU that the MN sent and the MN-AAA shared key. The MN uses this key to authenticate the MN-HA option in the Binding Ack. If authentication is successful, the MN creates a security association with SPI=5. This key is used to authenticate further BUs to the HA using the MN-HA auth option. Once the binding lifetime expires and the binding is deleted, the binding as well as the security association based on the integrity key is removed at the MN and HA.
MN使用MN发送的BU中的时间戳和MN-AAA共享密钥导出会话密钥和SA。MN使用此密钥对绑定Ack中的MN-HA选项进行身份验证。如果身份验证成功，MN将创建SPI=5的安全关联。此密钥用于使用MN-HA auth选项对HA的进一步总线进行身份验证。一旦绑定生存期到期并且绑定被删除，绑定以及基于完整性密钥的安全关联将在MN和HA上删除。
Migration from MobileIPv4 to MobileIPv6 utilizes the same network architecture and, specifically, the same AAA infrastructure. Thus, it is natural to have similar signaling in MIPv6 as in MIPv4, specifically the authentication with AAA infrastructure.
从MobileIPv4迁移到MobileIPv6使用相同的网络体系结构，特别是相同的AAA基础设施。因此，在MIPv6中使用与MIPv4中类似的信令是很自然的，特别是使用AAA基础结构的身份验证。
While the authentication protocol as specified in [RFC4285] provides Mobile IPv6 [RFC3775] deployments a certain degree of flexibility, it does have a few disadvantages as well. These are:
虽然[RFC4285]中指定的身份验证协议为移动IPv6[RFC3775]部署提供了一定程度的灵活性，但它也有一些缺点。这些是：
(1) The route optimization feature specified in RFC 3775 requires a secure transport (IPsec/ESP (Encapsulating Security Payload) mode) between the MN and HA. In cases where the authentication protocol [RFC4285] is used as the means for securing the MIPv6
(1) RFC 3775中指定的路由优化功能要求在MN和HA之间进行安全传输（IPsec/ESP（封装安全有效负载）模式）。在使用认证协议[RFC4285]作为保护MIPv6的手段的情况下
signaling between the MN and HA, route optimization should be switched off unless the security of the signaling between the MN and HA can be guaranteed via other means (such as link-layer security in the case of 3GPP2 networks).
MN和HA之间的信令，除非MN和HA之间的信令的安全性可以通过其他方式得到保证（例如3GPP2网络的情况下的链路层安全性），否则应关闭路由优化。
(2) The MIPv6 protocol is responsible for the security of the signaling messages as opposed to relying on IPsec for providing the security.
(2) MIPv6协议负责信令消息的安全性，而不是依赖IPsec来提供安全性。
(3) In 3GPP2 networks, link-layer security mechanisms, ingress filtering at the PDSN, and various network domain security mechanisms largely ensure that reverse tunnelled packets received by the HA do not have spoofed source addresses, and that their contents have not been modified. This implies the HA can determine the specific MN that sent the packet simply by verifying the outer-source IP address matches the currently registered care-of address. Authentication of payload packets can be necessary for, e.g.:
(3) 在3GPP2网络中，链路层安全机制、PDSN处的入口过滤以及各种网络域安全机制在很大程度上确保由HA接收的反向隧道包没有伪造的源地址，并且它们的内容没有被修改。这意味着HA可以通过验证外部源IP地址与当前注册的转交地址匹配来确定发送数据包的特定MN。有效负载数据包的认证可能是必要的，例如：
- Authenticating signaling messages other than BU/BAck between the MN and HA, such as ICMPv6, MLD, and DHCPv6.
- 验证MN和HA之间除BU/BAck之外的信令消息，例如ICMPv6、MLD和DHCPv6。
- Enforcing access control to the network behind the HA.
- 对HA背后的网络实施访问控制。
- Accounting or other flow-specific processing performed by the HA.
- 由医管局执行的会计或其他特定流程处理。
This means the authentication option is of limited applicability in environments where the HA can receive reverse-tunneled packets with spoofed source IP addresses and/or modified contents.
这意味着认证选项在HA可以接收具有伪造源IP地址和/或修改内容的反向隧道数据包的环境中的适用性有限。
(4) As described in [RFC4285], the authentication option assumes that the MN-AAA shared key and security association are created by out-of-band mechanisms. These mechanisms are specific to specific deployment environments. IKEv2, on the other hand, supports a wide range of authentication mechanisms, such as certificates and Extensible Authentication Protocol (EAP) methods, and is independent of the access network technology being used. However, it would be possible to specify a similar authentication and key management protocol for the authentication option in the future.
(4) 如[RFC4285]所述，身份验证选项假定MN-AAA共享密钥和安全关联由带外机制创建。这些机制特定于特定的部署环境。另一方面，IKEv2支持广泛的身份验证机制，例如证书和可扩展身份验证协议（EAP）方法，并且独立于所使用的接入网络技术。但是，将来可以为身份验证选项指定类似的身份验证和密钥管理协议。
(5) Sending the long-term user identity (NAI) in the clear raises privacy concerns. These concerns are addressed by access network and network domain security mechanisms in 3GPP2 networks, but do limit the applicability in networks where sniffing other users' traffic is possible.
(5) 以明文形式发送长期用户身份（NAI）会引起隐私问题。3GPP2网络中的接入网络和网络域安全机制解决了这些问题，但限制了在可能嗅探其他用户流量的网络中的适用性。
(6) RFC 4285 does not specify a mechanism for creating the MN-HA shared key and SA from the MN-AAA SA (unlike similar Mobile IPv4 mechanisms defined in [RFC3957]), and thus relies on deployment-specific mechanisms not standardized in the IETF.
(6) RFC 4285未指定从MN-AAA SA创建MN-HA共享密钥和SA的机制（与[RFC3957]中定义的类似移动IPv4机制不同），因此依赖于IETF中未标准化的部署特定机制。
(7) The authentication option does not support negotiation of cryptographic algorithms.
(7) 身份验证选项不支持加密算法的协商。
(8) The replay protection mechanisms in [RFC4285] rely on timestamps, and thus require reasonably synchronized clocks (by default, +/- 7 seconds). This assumes the MN implements, and is configured to use, some mechanism for synchronizing its clock.
(8) [RFC4285]中的重播保护机制依赖于时间戳，因此需要合理的同步时钟（默认情况下，+/-7秒）。这假定MN实现并配置为使用某种机制来同步其时钟。
When MIPv6 signaling messages use IPsec with ESP encapsulation, they are accorded privacy on the links over which the messages traverse. When MIPv6 signaling messages are secured using the authentication protocol, such ciphering capability will have to be enabled by the underlying link layers. It should be noted that the MIPv6 signaling messages are susceptible to snooping/sniffing when the authentication protocol [RFC4285] is used. Route optimization messages need to be secured between the MN and HA and this is not possible with the authentication protocol. However, route optimization is not supported in the current specification of the authentication protocol in [RFC4285].
当MIPv6信令消息使用带有ESP封装的IPsec时，它们在消息所经过的链路上被赋予隐私权。当使用身份验证协议保护MIPv6信令消息时，必须由底层链路层启用此类加密功能。应注意，当使用身份验证协议[RFC4285]时，MIPv6信令消息易受窥探/嗅探的影响。路由优化消息需要在MN和HA之间进行保护，这在身份验证协议中是不可能的。但是，[RFC4285]中认证协议的当前规范不支持路由优化。
Security issues with RFC 4285 are specifically:
RFC 4285的安全问题具体如下：
1. Key length. This is being addressed in [AUTH-PRO].
1. 键长度。[AUTH-PRO]对此进行了说明。
2. The keys used for securing the signaling between the MN and HA are derived from a security association that exists between the MN and AAA. The MIPv6 keys, which are bootstrapped from the MN-AAA SA, are transient. Limiting the lifetime of the keys to shorter periods should be recommended.
2. 用于保护MN和HA之间的信令的密钥来自MN和AAA之间存在的安全关联。从MN-AAA SA引导的MIPv6密钥是瞬态的。建议将钥匙的使用寿命限制在较短的时间内。
3. Location privacy is an issue in the absence of lower-layer security in the case of shared links.
3. 在共享链接缺乏较低层安全性的情况下，位置隐私是一个问题。
Mobile IPv6 was published as a Standards Track RFC [RFC3775] in 2004. Deployment of this protocol on a large scale is in the interest of the IETF and the working group, as well as that of many people who have worked on this. A rigid model for deployment will cause the protocol to be limited to an academic exercise only. It is extremely critical that the working group consider the needs of the industry
移动IPv6于2004年作为标准轨道RFC[RFC3775]发布。大规模部署此协议符合IETF和工作组的利益，也符合许多从事此工作的人员的利益。严格的部署模型将导致协议仅限于学术练习。工作组考虑行业需求是极为关键的。
and the deployment scenarios, and address them accordingly. This document captures the reasoning behind the need for the authentication protocol, which has been published as RFC 4285. RFC 4877 has alleviated some of the issues that have been of primary concern and were motivators for the authentication protocol. However, the IETF should consider the architectures of networks such as 3GPP2 and WiMAX and their security models, and enable deployment of Mobile IPv6 without requiring IPsec.
以及部署场景，并相应地解决它们。本文档捕获了认证协议需求背后的原因，该协议已发布为RFC 4285。RFC 4877缓解了一些主要关注的问题，这些问题是认证协议的动力。然而，IETF应该考虑诸如3GPP2和WiMAX之类的网络体系结构及其安全模型，并在不需要IPSec的情况下启用移动IPv6的部署。
The authors would like to thank Alpesh Patel, AC Mahendra, Kuntal Chowdhury, and Vijay Devarapalli for their input and discussions. Jari Arkko has reviewed the ID and provided valuable feedback. Thomas Narten has provided valuable reviews and made significant improvements to the text in this document. In his role as the IETF liaison to 3GPP2, Thomas Narten has ensured that the IETF understands the 3GPP2 requirements. Pasi Eronen, in his role as the Security AD, has reviewed and helped improve the document. Vidya Narayanan has reviewed the document from a security directorate perspective and provided input that has been incorporated.
作者要感谢阿尔佩什·帕特尔、AC·马亨德拉、昆塔·乔杜里和维杰·德瓦拉帕利的投入和讨论。Jari Arkko审查了ID并提供了宝贵的反馈。Thomas Narten提供了有价值的评论，并对本文档中的文本进行了重大改进。作为IETF与3GPP2的联络人，Thomas Narten确保IETF了解3GPP2要求。帕西·埃隆（Pasi Eronen）担任安全广告，审查并帮助改进了该文件。维迪亚·纳拉亚南（Vidya Narayanan）从安全理事会的角度审查了该文件，并提供了已纳入的意见。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[RFC3776]Arkko，J.，Devarapalli，V.，和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 37762004年6月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6的移动节点标识符选项（MIPv6）”，RFC 4283，2005年11月。
[3GPP2 X.S0011-002-D] 3GPP2 X.S0011-002-D, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services", http://www.3gpp2.org/ Public_html/specs/ X.S0011-002-D_v1.0_060301.pdf, February 2006.
[3GPP2 X.S0011-002-D]3GPP2 X.S0011-002-D，“cdma2000无线IP网络标准：简单IP和移动IP接入服务”，http://www.3gpp2.org/ Public_html/specs/X.S0011-002-D_v1.0_060301.pdf，2006年2月。
[AUTH-PRO] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", Work in Progress, July 2008.
[AUTH-PRO]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6认证协议”，正在进行的工作，2008年7月。
[BOOT] Chowdhury, K. and A. Yegin, "MIP6- Bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[BOOT]Chowdhury，K.和A.Yegin，“MIP6-集成场景的自举”，正在进行的工作，2008年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC3957] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[RFC3957]Perkins，C.和P.Calhoun，“移动IPv4的身份验证、授权和计费（AAA）注册密钥”，RFC 3957，2005年3月。
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[RFC4285]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6认证协议”，RFC 4285，2006年1月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877]Devarapalli，V.和F.Dupont，“使用IKEv2的移动IPv6操作和修订的IPsec架构”，RFC 4877，2007年4月。
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026]Giaretta，G.，Kempf，J.，和V.Devarapalli，“拆分场景中的移动IPv6引导”，RFC 5026，2007年10月。
[WiMAX-NWG] "WiMAX Network Architecture - WiMAX End-to-End Network Systems Architecture", May 2008, <http ://www.wimaxforum.org/documents/documents/ WiMAX_Forum_Network_Architecture_Stage_2- 3_Rel_1v1.2.zip>.
[WiMAX NWG]“WiMAX网络体系结构-WiMAX端到端网络系统体系结构”，2008年5月，<http://www.WiMAX论坛.org/documents/documents/WiMAX论坛网络体系结构阶段2-3\u Rel\u 1v1.2.zip>。
Authors' Addresses
作者地址
Basavaraj Patil Nokia 6021 Connection Drive Irving, TX 75039 USA
美国德克萨斯州欧文市Basavaraj Patil诺基亚6021连接驱动器75039
EMail: basavaraj.patil@nokia.com
EMail: basavaraj.patil@nokia.com
Gopal Dommety Cisco 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号Gopal Dommety Cisco，邮编95134
EMail: gdommety@cisco.com
EMail: gdommety@cisco.com