Network Working Group G. Giaretta
Request for Comments: 5637 Qualcomm
Category: Informational I. Guardini
E. Demaria
Telecom Italia
J. Bournelle
Orange Labs
R. Lopez
University of Murcia
September 2009
Network Working Group G. Giaretta
Request for Comments: 5637 Qualcomm
Category: Informational I. Guardini
E. Demaria
Telecom Italia
J. Bournelle
Orange Labs
R. Lopez
University of Murcia
September 2009
Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6
移动IPv6的身份验证、授权和计费（AAA）目标
Abstract
摘要
In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the Authentication, Authorization, and Accounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface.
在商业和企业部署中，移动IPv6可以是移动服务提供商（MSP）提供的服务。在这种情况下，可能需要明确授权和跟踪所有协议操作，这需要移动IPv6和AAA基础设施之间的交互。集成身份验证、授权和计费（AAA）基础设施（例如，网络访问服务器和AAA服务器）还为移动IPv6引导提供了一个解决方案组件。本文档描述了需要移动IPv6 AAA接口的各种场景。此外，它还列出了此类接口的设计目标和要求。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Motivation ......................................................4
4. Bootstrapping Scenarios .........................................4
4.1. Split Scenario .............................................5
4.2. Integrated Scenario ........................................6
5. Goals for AAA-HA Interface ......................................6
5.1. General Goals ..............................................6
5.2. Service Authorization ......................................7
5.3. Accounting .................................................8
5.4. Mobile Node Authentication .................................8
5.5. Provisioning of Configuration Parameters ...................8
6. Goals for the AAA-NAS Interface .................................9
7. Security Considerations .........................................9
8. Acknowledgements ................................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Motivation ......................................................4
4. Bootstrapping Scenarios .........................................4
4.1. Split Scenario .............................................5
4.2. Integrated Scenario ........................................6
5. Goals for AAA-HA Interface ......................................6
5.1. General Goals ..............................................6
5.2. Service Authorization ......................................7
5.3. Accounting .................................................8
5.4. Mobile Node Authentication .................................8
5.5. Provisioning of Configuration Parameters ...................8
6. Goals for the AAA-NAS Interface .................................9
7. Security Considerations .........................................9
8. Acknowledgements ................................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
Mobile IPv6 [1] provides the basic IP mobility functionality for IPv6. When Mobile IPv6 is used in tightly managed environments with the use of the AAA (Authentication, Authorization, and Accounting) infrastructure, an interface between Mobile IPv6 and AAA protocols needs to be defined. Also, two scenarios for bootstrapping Mobile IPv6 service [2], i.e., split [3] and integrated [6] scenarios, require the specification of a message exchange between the Home Agent (HA) and AAA infrastructure for authentication and authorization purposes and a message exchange between the AAA server and the NAS in order to provide the visited network with the necessary configuration information (e.g., Home Agent address).
移动IPv6[1]为IPv6提供了基本的IP移动功能。当移动IPv6在使用AAA（身份验证、授权和计费）基础设施的严格管理环境中使用时，需要定义移动IPv6和AAA协议之间的接口。此外，引导移动IPv6服务[2]的两种场景，即拆分[3]和集成[6]场景，需要指定归属代理（HA）之间的消息交换以及用于认证和授权目的的AAA基础设施，以及AAA服务器和NAS之间的消息交换，以向访问的网络提供必要的配置信息（例如，归属代理地址）。
This document describes various scenarios where a AAA interface is required. Additionally, it lists design goals and requirements for the communication between the HA and the AAA server and between the NAS and the AAA server needed in the split and integrated scenarios. Requirements are listed in case either IPsec or RFC 4285 [4] is used for Mobile IPv6 authentication.
本文档描述了需要AAA接口的各种场景。此外，它还列出了拆分和集成方案中所需的HA和AAA服务器之间以及NAS和AAA服务器之间通信的设计目标和要求。如果IPsec或RFC 4285[4]用于移动IPv6身份验证，则会列出要求。
This document only describes requirements, goals, and scenarios. It does not provide solutions.
本文档仅描述需求、目标和场景。它不提供解决方案。
Notice that this document builds on the security model of the AAA infrastructure. As such, the end host/user shares credentials with the home AAA server and the communication between the AAA server and the AAA client may be protected. If the AAA server and the AAA client are not part of the same administrative domain, then some sort of contractual relationship between the involved administrative domains is typically in place in the form of roaming agreements.
请注意，本文档以AAA基础设施的安全模型为基础。因此，最终主机/用户与家庭AAA服务器共享凭据，并且AAA服务器和AAA客户端之间的通信可以受到保护。如果AAA服务器和AAA客户端不是同一管理域的一部分，则相关管理域之间通常以漫游协议的形式存在某种契约关系。
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 [5], with the qualification that, unless otherwise stated, these words apply to the design of the AAA protocol extension, not its implementation or its usage.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释，除非另有说明，否则这些词适用于AAA协议扩展的设计，而不是它的实现或使用。
The following terms are extracted from [2].
以下术语摘自[2]。
o Access Service Authorizer (ASA). A network operator that authenticates a Mobile Node and establishes the Mobile Node's authorization to receive Internet service.
o 访问服务授权人（ASA）。一种网络运营商，对移动节点进行认证，并建立移动节点接收互联网服务的授权。
o Access Service Provider (ASP). A network operator that provides direct IP packet forwarding to and from the end host.
o 访问服务提供商（ASP）。提供与终端主机之间的直接IP数据包转发的网络运营商。
o Mobility Service Authorizer (MSA). A service provider that authorizes Mobile IPv6 service.
o 移动服务授权人（MSA）。授权移动IPv6服务的服务提供商。
o Mobility Service Provider (MSP). A service provider that provides Mobile IPv6 service. In order to obtain such service, the Mobile Node must be authenticated and prove authorization to obtain the service.
o 移动服务提供商（MSP）。提供移动IPv6服务的服务提供商。为了获得这样的服务，必须对移动节点进行身份验证并证明其获得服务的授权。
Mobile IPv6 specification [1] requires that Mobile Nodes (MNs) are provisioned with a set of configuration parameters -- namely, the Home Address and the Home Agent Address, in order to accomplish a home registration. Moreover, MNs and Home Agents (HAs) must share the cryptographic material needed in order to set up IPsec security associations to protect Mobile IPv6 signaling (e.g., shared keys or certificates). This is referred as the bootstrapping problem: as described in [2], the AAA infrastructure can be used as the central element to enable dynamic Mobile IPv6 bootstrapping. In this case, the AAA infrastructure can be exploited to offload the end host's authentication to the AAA server as well as to deliver the necessary configuration parameters to the visited network (e.g., Home Agent address as specified in [6]).
移动IPv6规范[1]要求为移动节点（MN）提供一组配置参数，即家庭地址和家庭代理地址，以便完成家庭注册。此外，MNs和归属代理（HA）必须共享所需的加密材料，以便建立IPsec安全关联以保护移动IPv6信令（例如，共享密钥或证书）。这被称为引导问题：如[2]中所述，AAA基础设施可以用作支持动态移动IPv6引导的中心元素。在这种情况下，可以利用AAA基础设施将终端主机的身份验证卸载到AAA服务器，并将必要的配置参数传送到访问的网络（例如，[6]中指定的归属代理地址）。
Moreover, in case Mobile IPv6 is a service offered by a Mobility Service Provider (MSP), all protocol operations (e.g., home registrations) may need to be explicitly authorized and monitored (e.g., for accounting purposes). This can be accomplished relying on the AAA infrastructure of the Mobility Service Authorizer (MSA) that stores user profiles and credentials.
此外，如果移动IPv6是由移动服务提供商（MSP）提供的服务，则可能需要明确授权和监控所有协议操作（例如，家庭注册）（例如，出于计费目的）。这可以依靠存储用户配置文件和凭据的移动服务授权器（MSA）的AAA基础设施来实现。
This section describes some bootstrapping scenarios in which communication between the AAA infrastructure of the Mobility Service Provider and the Home Agent is needed. The need of MIPv6-aware communication between the AAA server and the Network Access Server (NAS) is also described. The purpose of this section is only to explain the situation where bootstrapping is required. The actual mechanisms and additional details are specified elsewhere or are left for future work (see, e.g., [2], [3], and [6]).
本节描述了一些引导场景，其中移动服务提供商的AAA基础设施和归属代理之间需要通信。还描述了AAA服务器和网络访问服务器（NAS）之间的MIPv6感知通信的需要。本节的目的只是解释需要引导的情况。实际机制和其他细节在别处指定，或留作将来的工作（例如，参见[2]、[3]和[6]）。
In the split scenario [3], there is the assumption that the mobility service and network access service are not provided by the same administrative entity. This implies that the mobility service is authorized by the MSA that is a different entity from the ASA.
在拆分场景[3]中，假设移动服务和网络接入服务不是由同一管理实体提供的。这意味着移动服务由MSA授权，MSA是与ASA不同的实体。
In this scenario, the Mobile Node discovers the Home Agent Address using the Domain Name Service (DNS). It queries the address based on the Home Agent name or by service name. In the former case, the Mobile Node is configured with the Fully Qualified Domain Name (FDQN) of the Home Agent. In the latter case, [3] defines a new service resource record (SRV RR).
在此场景中，移动节点使用域名服务（DNS）发现归属代理地址。它根据归属代理名称或服务名称查询地址。在前一种情况下，移动节点配置有归属代理的完全限定域名（FDQN）。在后一种情况下，[3]定义了一个新的服务资源记录（SRV RR）。
Then the Mobile Node performs an IKEv2 [7] exchange with the HA to set up IPsec Security Associations (SAs) to protect Mobile IPv6 signaling and to configure its Home Address (HoA). Mutual authentication for IKEv2 between Mobile Node and Home Agent can be done with or without use of the Extensible Authentication Protocol (EAP).
然后，移动节点与HA执行IKEv2[7]交换，以建立IPsec安全关联（SA），以保护移动IPv6信令并配置其家庭地址（HoA）。移动节点和归属代理之间的IKEv2相互认证可以通过使用或不使用可扩展认证协议（EAP）来完成。
If EAP is used for authentication, the operator can choose any available EAP methods. Use of EAP with the AAA infrastructure allows the HA to check the validity of each MN's credentials with the AAA infrastructure, rather than having to maintain credentials for each MN itself. It also allows roaming in terms of Mobile IPv6 service where the MSP and MSA belong to different administrative domains. In this case, the HA in the MSP can check the validity of the credentials provided by the MN with the AAA infrastructure of MSA, receiving the relevant authorization information.
如果EAP用于身份验证，操作员可以选择任何可用的EAP方法。在AAA基础设施中使用EAP允许HA使用AAA基础设施检查每个MN的凭据的有效性，而不必维护每个MN本身的凭据。它还允许在移动IPv6服务方面进行漫游，其中MSP和MSA属于不同的管理域。在这种情况下，MSP中的HA可以使用MSA的AAA基础设施检查MN提供的凭据的有效性，并接收相关授权信息。
The Mobile Node may also want to update its FQDN in the DNS with the newly allocated Home Address. [3] recommends that the HA performs the DNS entry update on behalf of the Mobile Node. For that purpose, the Mobile Node indicates its FDQN in the IKEv2 exchange (in the IDi field in IKE_AUTH) and adds a DNS Update Option in the Binding Update message sent to the HA.
移动节点还可能希望使用新分配的家庭地址更新其在DNS中的FQDN。[3] 建议HA代表移动节点执行DNS条目更新。为此，移动节点在IKEv2交换中指示其FDQN（在IKE_AUTH中的IDi字段中），并在发送给HA的绑定更新消息中添加DNS更新选项。
When the Mobile Node uses a Home Agent belonging to a different administrative domain (MSP != MSA), the local HA may not share a security association with the home DNS server. In this case, [3] suggests that the home AAA server is responsible for the update. Thus, the HA should send to the home AAA server the (FDQN, HoA) pair.
当移动节点使用属于不同管理域（MSP！=MSA）的归属代理时，本地HA可能不会与归属DNS服务器共享安全关联。在这种情况下，[3]建议家庭AAA服务器负责更新。因此，HA应该向家庭AAA服务器发送（FDQN，HoA）对。
In the integrated scenario, the assumption is that the Access Service Authorizer (ASA) is the same as the Mobility Service Authorizer (MSA). Further details of this type of a scenario are being worked on separately [6].
在集成场景中，假设接入服务授权人（ASA）与移动服务授权人（MSA）相同。关于这类场景的更多细节正在单独研究[6]。
The Home Agent can be assigned either in the Access Service Provider's network or in the separate network. In the former case, the MSP is the same entity as the ASP, whereas in the latter case the MSP and ASP are different entities.
可以在接入服务提供商的网络中或在单独的网络中分配归属代理。在前一种情况下，MSP是与ASP相同的实体，而在后一种情况下，MSP和ASP是不同的实体。
In this scenario, the Mobile Node discovers the Home Agent Address using DHCPv6. If the user is authorized for Mobile IPv6 service, during the network access authentication the AAAH (the AAA server in the home network) sends the information about the assigned Home Agent to the NAS where the Mobile Node is currently attached. To request Home Agent data, the Mobile Node sends a DHCPv6 Information Request to the All_DHCP_Relay_Agents_and_Servers multicast address. With this request, the Mobile Node can specify if it wants a Home Agent provided by the visited domain (ASP/MSP) or by the home domain (ASA/MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS receives the DHCPv6 Information Request, it passes Home Agent information received from the AAAH server to the DHCP server, for instance using mechanisms defined in [6].
在此场景中，移动节点使用DHCPv6发现归属代理地址。如果用户被授权使用移动IPv6服务，则在网络访问认证期间，AAAH（家庭网络中的AAA服务器）将有关分配的家庭代理的信息发送到移动节点当前连接的NAS。为了请求归属代理数据，移动节点将DHCPv6信息请求发送到所有DHCP_中继_代理_和_服务器多播地址。通过该请求，移动节点可以指定它是否希望由访问域（ASP/MSP）或归属域（ASA/MSA）提供归属代理。在这两种情况下，NAS都充当DHCPv6中继。当NAS接收到DHCPv6信息请求时，它将从AAAH服务器接收到的归属代理信息传递给DHCP服务器，例如使用[6]中定义的机制。
In case the Mobile Node cannot acquire Home Agent information via DHCPv6, it can try the default mechanism based on DNS described in [3]. After the Mobile Node has acquired the Home Agent information, the mechanisms used to bootstrap the HoA, the IPsec Security Association, and the authentication and authorization with the MSA are the same as described in the bootstrapping solution for the split scenario [3].
如果移动节点无法通过DHCPv6获取归属代理信息，则可以尝试基于[3]中描述的DNS的默认机制。移动节点获取归属代理信息后，用于引导HoA、IPsec安全关联以及MSA的身份验证和授权的机制与剥离场景的引导解决方案中描述的相同[3]。
Section 4 raises the need to define extensions for the AAA protocol used between the AAA server of the MSA and the HA. The following sections list the goals for such an interface. This communication is needed for both the split and integrated scenarios.
第4节提出需要为MSA的AAA服务器和HA之间使用的AAA协议定义扩展。以下各节列出了此类接口的目标。拆分和集成场景都需要这种通信。
G1.1 The communication between the AAAH server and the HA MUST reuse existing AAA security mechanisms with regard to authentication, replay, integrity, and confidentiality protection. These communication security mechanisms prevent a number of classical
G1.1 AAAH服务器和HA之间的通信必须在身份验证、重播、完整性和保密保护方面重用现有的AAA安全机制。这些通信安全机制阻止了一些经典的
threats, including the alteration of exchanged data (e.g., Mobile IPv6 configuration parameters) and the installation of unauthorized state.
威胁，包括更改交换的数据（例如，移动IPv6配置参数）和安装未经授权的状态。
G2.1 The AAA-HA interface MUST allow the use of a Network Access Identifier (NAI) to identify the user.
G2.1 AAA-HA接口必须允许使用网络访问标识符（NAI）来识别用户。
G2.2 The HA MUST be able to query the AAAH server to verify Mobile IPv6 service authorization for the Mobile Node.
G2.2 HA必须能够查询AAAH服务器，以验证移动节点的移动IPv6服务授权。
G2.3 The AAAH server MAY assign explicit operational limitations and authorization restrictions on the HA (e.g., packet filters, QoS parameters).
G2.3 AAAH服务器可以为HA分配明确的操作限制和授权限制（例如，数据包过滤器、QoS参数）。
G2.4 The AAAH server MUST be able to send an authorization lifetime to the HA to limit Mobile IPv6 session duration for the MN.
G2.4 AAAH服务器必须能够向HA发送授权生存期，以限制MN的移动IPv6会话持续时间。
G2.5 The HA MUST be able to request that the AAAH server grant an extension of the authorization lifetime to the MN.
G2.5 HA必须能够请求AAAH服务器向MN授予授权生存期的延长。
G2.6 The AAAH server MUST be able to force the HA to terminate an active Mobile IPv6 session for authorization policy reasons (e.g., credit exhaustion).
G2.6 AAAH服务器必须能够出于授权策略原因（例如，信用耗尽）强制HA终止活动的移动IPv6会话。
G2.7 The HA MUST be able to indicate to the AAAH server the IPv6 HoA that will be assigned to the MN.
G2.7 HA必须能够向AAAH服务器指示将分配给MN的IPv6 HoA。
G2.8 The AAAH server MUST be able to authorize the MN to use an IPv6 HoA and MUST indicate that to the HA.
G2.8 AAAH服务器必须能够授权MN使用IPv6 HoA，并且必须向HA表明这一点。
G2.9 The AAAH server MUST be able to indicate to the HA whether or not the return routability test (HoT (Home Test) and HoTi (Home Test Init)) shall be permitted via the HA for a given MN.
G2.9 AAAH服务器必须能够向HA指示是否允许通过HA对给定MN进行返回路由性测试（HoT（Home test）和HoTi（Home test Init））。
G2.10 The AAAH server MUST be able to support different levels of Mobile IPv6 authorization. For example, the AAAH server may authorize the MN to use MIPv6 (as defined in [1]) or may authorize the MN to utilize an IPv4 HoA assigned for Dual Stack MIPv6 [8].
G2.10 AAAH服务器必须能够支持不同级别的移动IPv6授权。例如，AAAH服务器可以授权MN使用MIPv6（如[1]中所定义的），或者可以授权MN使用分配给双栈MIPv6的IPv4 HoA[8]。
G2.11 The AAAH server MUST be able to indicate to the HA whether the bearer traffic for the MN needs to receive IPsec Encapsulating Security Payload (ESP) protection.
G2.11 AAAH服务器必须能够向HA指示MN的承载流量是否需要接收IPsec封装安全有效负载（ESP）保护。
G2.12 The HA MUST be able to authenticate the MN through the AAAH server in case a pre-shared key is used in IKEv2 for user authentication. The exact procedure is part of the solution space.
G2.12如果IKEv2中使用预共享密钥进行用户身份验证，HA必须能够通过AAAH服务器对MN进行身份验证。精确的过程是解空间的一部分。
G3.1 The AAA-HA interface MUST support the transfer of accounting records needed for service control and charging. These include (but may not be limited to): time of binding cache entry creation and deletion, octets sent and received by the Mobile Node in bi-directional tunneling, etc.
G3.1 AAA-HA接口必须支持传输服务控制和收费所需的会计记录。这些包括（但不限于）：绑定缓存项创建和删除的时间、移动节点在双向隧道中发送和接收的八位字节等。
G4.1 The AAA-HA interface MUST allow the HA to act as a pass-through EAP authenticator.
G4.1 AAA-HA接口必须允许HA充当直通EAP验证器。
G4.2 The AAA-HA interface MUST support authentication based on the Mobility Message Authentication Options defined in [4].
G4.2 AAA-HA接口必须支持基于[4]中定义的移动消息认证选项的认证。
G4.3 The AAAH server MUST be able to provide a MN-HA key (or data used for subsequent key derivation of the MN-HA key by the HA) to the HA if requested. Additional data, such as the Security Parameter Index (SPI) or lifetime parameters, are sent along with the keying material.
G4.3如果请求，AAAH服务器必须能够向HA提供MN-HA密钥（或用于HA后续MN-HA密钥派生的数据）。其他数据，如安全参数索引（SPI）或寿命参数，将与密钥材料一起发送。
G4.4 The HA supporting the Authentication Protocol MUST be able to request that the AAAH server authenticate the MN with the value in the MN-AAA Mobility Message Authentication Option.
G4.4支持认证协议的HA必须能够请求AAAH服务器使用MN-AAA移动消息认证选项中的值对MN进行认证。
G4.5 The HA MUST include an identifier of the Mobile Node in the AAA transactions with the AAAH server.
G4.5 HA必须在与AAAH服务器的AAA事务中包含移动节点的标识符。
o The HA SHOULD be able to communicate to the AAAH server the Home Address allocated to the MN and the FQDN of the MN (e.g., for allowing the AAAH server to perform a DNS update on behalf of the MN).
o HA应该能够将分配给MN的家庭地址和MN的FQDN（例如，允许AAAH服务器代表MN执行DNS更新）传递给AAAH服务器。
o The AAAH server SHOULD be able to indicate to the HA if the MN is authorized to autoconfigure its Home Address. If the AAAH does not indicate to the HA if a MN is authorized to autoconfigure its address, the MN is not authorized.
o AAAH服务器应该能够向HA指示MN是否被授权自动配置其家庭地址。如果AAAH没有向HA指示MN是否被授权自动配置其地址，则MN未被授权。
In the integrated scenario, the AAA server provides the HA information to the NAS as part of the whole AAA operation for network access.
在集成场景中，AAA服务器向NAS提供HA信息，作为整个AAA网络访问操作的一部分。
G6.1 The AAAH server MUST be able to communicate the Home Agent Information (IP address or FQDN) to the NAS.
G6.1 AAAH服务器必须能够将归属代理信息（IP地址或FQDN）传送到NAS。
G6.2 The NAS MUST be able to notify the AAAH server if it supports the AAA extensions designed to receive the HA assignment information.
G6.2 NAS必须能够通知AAAH服务器是否支持设计用于接收HA分配信息的AAA扩展。
G6.3 The ASP/MSP supporting the allocation of a Home Agent MUST be able to indicate to the MSA if it can allocate a Home Agent to the MN. Therefore, the NAS MUST be able to include a suggested HA address in the ASP in the AAA-NAS interaction.
G6.3支持归属代理分配的ASP/MSP必须能够向MSA指示是否可以将归属代理分配给MN。因此，NAS必须能够在AAA-NAS交互的ASP中包含建议的HA地址。
G6.4 The AAA server of the MSA MUST be able to indicate to the NAS whether the MN is authorized to use a local Home Agent (i.e., a Home Agent in the ASP/MSP).
G6.4 MSA的AAA服务器必须能够向NAS指示MN是否有权使用本地归属代理（即ASP/MSP中的归属代理）。
G6.5 The overall AAA solution for the integrated scenario MUST support the scenario where the AAA server of the ASA/MSA used for network access authentication is different from the AAA server used for mobility service authentication and authorization.
G6.5集成场景的整体AAA解决方案必须支持用于网络访问身份验证的ASA/MSA的AAA服务器与用于移动服务身份验证和授权的AAA服务器不同的场景。
As stated in Section 5.1, the AAA-HA interface must provide mutual authentication, integrity, and replay protection. Furthermore, if security parameters (e.g., IKE pre-shared key) are transferred through this interface, confidentiality is strongly recommended to be supported. In this case, the links between the HA and the AAA server of the MSA and between the NAS and the AAA server MUST be secure.
如第5.1节所述，AAA-HA接口必须提供相互认证、完整性和重播保护。此外，如果通过该接口传输安全参数（例如IKE预共享密钥），强烈建议支持保密性。在这种情况下，HA和MSA的AAA服务器之间以及NAS和AAA服务器之间的链路必须是安全的。
The authors would like to thank James Kempf, Alper Yegin, Vijay Devarapalli, Basavaraj Patil, Gopal Dommety, Marcelo Bagnulo, and Madjid Nakhjiri for their comments and feedback. Moreover, the authors would like to thank Hannes Tschofenig for his deep technical and editorial review of the document. Finally the authors would like to thank Kuntal Chowdhury who contributed by identifying the goals related to RFC 4285 authentication.
作者感谢詹姆斯·肯普夫、阿尔珀·耶金、维杰·德瓦拉帕利、巴萨瓦拉吉·帕蒂尔、戈帕尔·多梅蒂、马塞洛·巴格努洛和马吉德·纳赫吉里的评论和反馈。此外，作者还要感谢Hannes Tschofenig对该文件进行了深入的技术和编辑审查。最后，作者要感谢Kuntal Chowdhury，他通过确定与RFC 4285认证相关的目标做出了贡献。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[2] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[2] Patel，A.和G.Giaretta，“引导移动IPv6（MIPv6）的问题陈述”，RFC4640，2006年9月。
[3] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[3] Giaretta，G.，Kempf，J.，和V.Devarapalli，“拆分场景中的移动IPv6引导”，RFC 5026，2007年10月。
[4] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[4] Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6认证协议”，RFC 42852006年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Chowdhury, K., Ed., and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[6] Chowdhury，K.，Ed.，和A.Yegin，“集成场景的MIP6引导”，正在进行的工作，2008年4月。
[7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[7] Kaufman，C.，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[8] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[8] Soliman，H.，Ed.，“双栈主机和路由器的移动IPv6支持”，RFC 55552009年6月。
Authors' Addresses
作者地址
Gerardo Giaretta Qualcomm 5775 Morehouse Drive San Diego, CA 92109 USA
美国加利福尼亚州圣地亚哥莫尔豪斯大道5775号Gerardo Giaretta高通公司，邮编92109
EMail: gerardo@qualcomm.com
EMail: gerardo@qualcomm.com
Ivano Guardini Telecom Italia Lab via G. Reiss Romoli, 274 TORINO 10148 Italy
Ivano Guardini Telecom Italia Lab via G.Reiss Romoli，274都灵10148意大利
EMail: ivano.guardini@telecomitalia.it
EMail: ivano.guardini@telecomitalia.it
Elena Demaria Telecom Italia Lab via G. Reiss Romoli, 274 TORINO 10148 Italy
Elena Demaria Telecom Italia Lab via G.Reiss Romoli，274都灵10148意大利
EMail: elena.demaria@telecomitalia.it
EMail: elena.demaria@telecomitalia.it
Julien Bournelle Orange Labs
朱利安·博内尔橙色实验室
EMail: julien.bournelle@gmail.com
EMail: julien.bournelle@gmail.com
Rafa Marin Lopez University of Murcia 30071 Murcia Spain
拉法马林洛佩兹大学穆尔西亚30071西班牙穆尔西亚
EMail: rafa@dif.um.es
EMail: rafa@dif.um.es