Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 5778 H. Tschofenig
Category: Standards Track Nokia Siemens Networks
ISSN: 2070-1721 J. Bournelle
Orange Labs
G. Giaretta
Qualcomm
M. Nakhjiri
Motorola
February 2010
Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 5778 H. Tschofenig
Category: Standards Track Nokia Siemens Networks
ISSN: 2070-1721 J. Bournelle
Orange Labs
G. Giaretta
Qualcomm
M. Nakhjiri
Motorola
February 2010
Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction
Diameter移动IPv6：支持归属代理到Diameter服务器的交互
Abstract
摘要
Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the home agent and the Diameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP home agent and a Diameter server.
移动IPv6部署可能希望根据归属代理和移动服务提供商的Diameter服务器之间的交互动态引导其操作。本文档指定了移动IP主代理和Diameter服务器之间的交互。
This document defines the home agent to the Diameter server communication when the mobile node authenticates using the Internet Key Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6- specific parameters and accounting is specified in this document.
本文档定义了当移动节点使用Internet Key Exchange v2协议和可扩展身份验证协议或使用移动IPv6身份验证协议进行身份验证时，归属代理与Diameter服务器之间的通信。除了身份验证和授权之外，本文档还指定了移动IPv6特定参数和记帐的配置。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5778.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5778.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Application Identifiers .........................................6
4. Protocol Description ............................................7
4.1. Support for Mobile IPv6 with IKEv2 and EAP .................7
4.2. Support for the Mobile IPv6 Authentication Protocol .......10
4.3. Mobile IPv6 Session Management ............................11
4.3.1. Session-Termination-Request ........................11
4.3.2. Session-Termination-Answer .........................11
4.3.3. Abort-Session-Request ..............................12
4.3.4. Abort-Session-Answer ...............................12
4.4. Accounting for Mobile IPv6 Services .......................12
4.4.1. Accounting-Request .................................13
4.4.2. Accounting-Answer ..................................13
5. Command Codes ..................................................13
5.1. Command Code for Mobile IPv6 with IKEv2 and EAP ...........13
5.1.1. Diameter-EAP-Request ...............................13
5.1.2. Diameter-EAP-Answer ................................14
5.2. Command Codes for Mobile IPv6 Authentication
Protocol Support ..........................................15
5.2.1. MIP6-Request .......................................16
5.2.2. MIP6-Answer ........................................17
6. AVPs ...........................................................18
6.1. User-Name AVP .............................................21
6.2. Service-Selection AVP .....................................21
6.3. MIP-MN-AAA-SPI AVP ........................................21
6.4. MIP-MN-HA-SPI AVP .........................................22
6.5. MIP-Mobile-Node-Address AVP ...............................22
6.6. MIP6-Agent-Info AVP .......................................22
6.7. MIP-Careof-Address AVP ....................................23
6.8. MIP-Authenticator AVP .....................................23
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Application Identifiers .........................................6
4. Protocol Description ............................................7
4.1. Support for Mobile IPv6 with IKEv2 and EAP .................7
4.2. Support for the Mobile IPv6 Authentication Protocol .......10
4.3. Mobile IPv6 Session Management ............................11
4.3.1. Session-Termination-Request ........................11
4.3.2. Session-Termination-Answer .........................11
4.3.3. Abort-Session-Request ..............................12
4.3.4. Abort-Session-Answer ...............................12
4.4. Accounting for Mobile IPv6 Services .......................12
4.4.1. Accounting-Request .................................13
4.4.2. Accounting-Answer ..................................13
5. Command Codes ..................................................13
5.1. Command Code for Mobile IPv6 with IKEv2 and EAP ...........13
5.1.1. Diameter-EAP-Request ...............................13
5.1.2. Diameter-EAP-Answer ................................14
5.2. Command Codes for Mobile IPv6 Authentication
Protocol Support ..........................................15
5.2.1. MIP6-Request .......................................16
5.2.2. MIP6-Answer ........................................17
6. AVPs ...........................................................18
6.1. User-Name AVP .............................................21
6.2. Service-Selection AVP .....................................21
6.3. MIP-MN-AAA-SPI AVP ........................................21
6.4. MIP-MN-HA-SPI AVP .........................................22
6.5. MIP-Mobile-Node-Address AVP ...............................22
6.6. MIP6-Agent-Info AVP .......................................22
6.7. MIP-Careof-Address AVP ....................................23
6.8. MIP-Authenticator AVP .....................................23
6.9. MIP-MAC-Mobility-Data AVP .................................23
6.10. MIP-Session-Key AVP ......................................23
6.11. MIP-MSA-Lifetime AVP .....................................23
6.12. MIP-MN-HA-MSA AVP ........................................24
6.13. MIP-Algorithm-Type AVP ...................................24
6.14. MIP-Replay-Mode AVP ......................................24
6.15. MIP6-Feature-Vector AVP ..................................25
6.16. MIP-Timestamp AVP ........................................25
6.17. QoS-Capability AVP .......................................25
6.18. QoS-Resources AVP ........................................25
6.19. Chargeable-User-Identity AVP .............................25
6.20. MIP6-Auth-Mode AVP .......................................25
6.21. Accounting AVPs ..........................................26
7. Result-Code AVP Values .........................................27
7.1. Success ...................................................27
7.2. Permanent Failures ........................................27
8. AVP Occurrence Tables ..........................................27
8.1. DER, DEA, MIR, and MIA AVP/Command-Code Table .............28
8.2. Coupled Accounting Model AVP Table ........................28
9. IANA Considerations ............................................29
9.1. Command Codes .............................................29
9.2. AVP Codes .................................................29
9.3. Result-Code AVP Values ....................................30
9.4. Application Identifier ....................................30
9.5. Namespaces ................................................30
10. Security Considerations .......................................31
11. Acknowledgements ..............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................33
6.9. MIP-MAC-Mobility-Data AVP .................................23
6.10. MIP-Session-Key AVP ......................................23
6.11. MIP-MSA-Lifetime AVP .....................................23
6.12. MIP-MN-HA-MSA AVP ........................................24
6.13. MIP-Algorithm-Type AVP ...................................24
6.14. MIP-Replay-Mode AVP ......................................24
6.15. MIP6-Feature-Vector AVP ..................................25
6.16. MIP-Timestamp AVP ........................................25
6.17. QoS-Capability AVP .......................................25
6.18. QoS-Resources AVP ........................................25
6.19. Chargeable-User-Identity AVP .............................25
6.20. MIP6-Auth-Mode AVP .......................................25
6.21. Accounting AVPs ..........................................26
7. Result-Code AVP Values .........................................27
7.1. Success ...................................................27
7.2. Permanent Failures ........................................27
8. AVP Occurrence Tables ..........................................27
8.1. DER, DEA, MIR, and MIA AVP/Command-Code Table .............28
8.2. Coupled Accounting Model AVP Table ........................28
9. IANA Considerations ............................................29
9.1. Command Codes .............................................29
9.2. AVP Codes .................................................29
9.3. Result-Code AVP Values ....................................30
9.4. Application Identifier ....................................30
9.5. Namespaces ................................................30
10. Security Considerations .......................................31
11. Acknowledgements ..............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................33
Performing the Mobile IPv6 protocol [RFC3775] requires the mobile node (MN) to own a home address and to have an assigned home agent (HA) to the MN. The MN needs to register with the HA in order to enable its reachability and mobility, when away from its home link. The registration process itself may require an establishment of IPsec security associations (SAs) and cryptographic material between the MN and the HA. Alternatively, the registration process may be secured using a mobility message authentication option, which enables IPv6 mobility in an MN without having to establish an IPsec SA with its HA. Providing the collection of home address, HA address, and keying material is generally referred to as the Mobile IPv6 bootstrapping problem [RFC4640]. The purpose of this specification is to provide Diameter support for the interaction between the HA and the Authentication, Authorization, and Accounting (AAA) server. This specification satisfies the requirements defined in [RFC5637] for the bootstrapping problem in the split scenario [RFC5026] and also specifies Diameter support for the Authentication Protocol for Mobile IPv6 [RFC4285]. The Diameter support defined in this specification also applies to Dual Stack Mobile IPv6 [RFC5555].
执行移动IPv6协议[RFC3775]需要移动节点（MN）拥有一个归属地址，并向MN分配一个归属代理（HA）。MN需要向HA注册，以便在远离其主链路时实现其可达性和移动性。注册过程本身可能需要在MN和HA之间建立IPsec安全关联（SA）和加密材料。或者，可以使用移动消息认证选项来保护注册过程，该选项启用MN中的IPv6移动，而不必建立具有其HA的IPsec SA。提供家庭地址、HA地址和密钥材料的集合通常被称为移动IPv6引导问题[RFC4640]。本规范的目的是为HA和身份验证、授权和计费（AAA）服务器之间的交互提供Diameter支持。本规范满足[RFC5637]中针对拆分方案[RFC5026]中的引导问题定义的要求，并规定了对移动IPv6认证协议[RFC4285]的Diameter支持。本规范中定义的Diameter支持也适用于双栈移动IPv6[RFC5555]。
From a Mobility Service Provider (MSP) perspective, it is important to verify that the MN is authenticated and authorized to utilize Mobile IPv6 service, and is accounted for those. Only when the MN is authenticated and authorized does the MSP allow the bootstrapping of Mobile IPv6 parameters. Thus, prior to processing the Mobile IPv6 registrations, the HA participates in the authentication of the MN to verify the MN's identity. The HA also participates in the Mobile IPv6 authorization process involving the Diameter infrastructure. The HA, due to its role in traffic forwarding, may also perform accounting for the Mobile IPv6 service provided to the MN.
从移动服务提供商（MSP）的角度来看，重要的是验证MN是否经过身份验证和授权以使用移动IPv6服务，并对这些服务进行说明。只有当MN经过身份验证和授权时，MSP才允许引导移动IPv6参数。因此，在处理移动IPv6注册之前，HA参与MN的认证以验证MN的身份。医管局亦参与涉及Diameter基础设施的移动IPv6授权过程。由于其在业务转发中的作用，HA还可以对提供给MN的移动IPv6服务进行计费。
This document enables the following functionality:
本文档启用以下功能：
Authentication: The MN's identity needs to be verified. As a Diameter client supporting the new Diameter Mobile IPv6 application, the HA may need to support more than one authentication type depending on the environment. Although the authentication is performed by the AAA server, there is an impact for the HA as different sets of command codes are needed for the respective authentication procedures.
身份验证：需要验证MN的身份。作为支持新Diameter移动IPv6应用程序的Diameter客户端，HA可能需要支持多种身份验证类型，具体取决于环境。尽管认证由AAA服务器执行，但由于各个认证过程需要不同的命令代码集，因此对HA有影响。
Authorization: The HA must verify that the user is authorized to the Mobile IPv6 service using the assistance of the MSP Diameter servers. This is accomplished through the use of new Diameter applications specifically designed for performing Mobile IPv6
授权：HA必须在MSP Diameter服务器的协助下验证用户是否已被授权使用移动IPv6服务。这是通过使用专为执行移动IPv6而设计的新Diameter应用程序实现的
authorization decisions. This document defines required AAA procedures and requires the HA to support them and to participate in this authorization signaling.
授权决定。本文件定义了所需的AAA程序，并要求HA支持这些程序，并参与该授权信号。
Accounting: For accounting purposes and capacity planning, it is required that the HA provides accounting reports to the Diameter infrastructure and thus supports the related Diameter accounting procedures.
会计：出于会计目的和容量规划，要求医管局向Diameter基础设施提供会计报告，从而支持相关的Diameter会计程序。
Session Management: The management of the mobility services may require the Diameter server or the HA to terminate the Mobile IPv6 service before the binding expires. This document defines procedures for the AAA-based session management.
会话管理：移动服务的管理可能要求Diameter服务器或HA在绑定到期之前终止移动IPv6服务。本文档定义了基于AAA的会话管理程序。
Figure 1 depicts the reference architecture for this document.
图1描述了本文档的参考体系结构。
+--------+
|Diameter|
|Server |
+--------+
^
Back-End | Diameter Mobile IPv6
Protocol | HA<->AAA Server
Support | Interaction
| (this document)
v
+---------+ +---------------+
| Mobile | Front-End Protocol |Home Agent / |
| Node |<-------------------->|Diameter Client|
+---------+ IKEv2 or RFC 4285 +---------------+
+--------+
|Diameter|
|Server |
+--------+
^
Back-End | Diameter Mobile IPv6
Protocol | HA<->AAA Server
Support | Interaction
| (this document)
v
+---------+ +---------------+
| Mobile | Front-End Protocol |Home Agent / |
| Node |<-------------------->|Diameter Client|
+---------+ IKEv2 or RFC 4285 +---------------+
Figure 1: Architecture Overview
图1：架构概述
Mobile IPv6 signaling between the MN and the HA can be protected using two different mechanisms, namely, using IPsec or the Authentication Protocol for Mobile IPv6 [RFC4285]. For these two approaches, several different authentication and key exchange solutions are available. When IPsec is used to protect Mobile IPv6 signaling messages, Internet Key Exchange v2 (IKEv2) is used [RFC4877] for the setup of the IPsec SAs. IKEv2 supports EAP-based (Extensible Authentication Protocol) initiator authentication, certificates, and pre-shared secrets. Alternatively, the Authentication Protocol for Mobile IPv6 uses a mechanism that is very similar to the one used for protecting Mobile IPv4 signaling messages.
可以使用两种不同的机制来保护MN和HA之间的移动IPv6信令，即使用IPsec或移动IPv6的身份验证协议[RFC4285]。对于这两种方法，可以使用几种不同的身份验证和密钥交换解决方案。当IPsec用于保护移动IPv6信令消息时，使用Internet密钥交换v2（IKEv2）[RFC4877]设置IPsec SAs。IKEv2支持基于EAP（可扩展身份验证协议）的启动器身份验证、证书和预共享机密。或者，移动IPv6的身份验证协议使用的机制与用于保护移动IPv4信令消息的机制非常相似。
The ability to use different credentials and methods to authenticate the MN has an impact on the AAA interactions between the HA (acting as a Diameter client) and the Diameter server. This specification is only limited to the following MN authentication methods:
使用不同凭据和方法对MN进行身份验证的能力会影响HA（充当Diameter客户端）和Diameter服务器之间的AAA交互。本规范仅限于以下MN认证方法：
o IKEv2 usage with EAP
o IKEv2与EAP的使用
o Mobile IPv6 Authentication Protocol
o 移动IPv6认证协议
New authentication mechanisms may be added later by separate specifications.
稍后可以通过单独的规范添加新的身份验证机制。
For accounting of Mobile IPv6 services provided to the MN, this specification uses the Diameter base protocol accounting defined in [RFC3588].
对于向MN提供的移动IPv6服务的计费，本规范使用[RFC3588]中定义的Diameter基本协议计费。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The Mobile IPv6 bootstrapping terminology is taken from [RFC4640]. Additional terminology is defined below:
移动IPv6引导术语取自[RFC4640]。其他术语定义如下：
Authentication, Authorization, and Accounting (AAA):
身份验证、授权和记帐（AAA）：
AAA protocol based on Diameter [RFC3588] with required EAP support [RFC4072].
基于Diameter[RFC3588]的AAA协议，需要EAP支持[RFC4072]。
Home AAA (AAAH):
家庭AAA（AAAH）：
An authentication, authorization, and accounting server located in the user's home network, i.e., in the home realm.
位于用户家庭网络（即家庭域）中的身份验证、授权和记帐服务器。
This specification defines two new Diameter applications and their respective Application Identifiers:
本规范定义了两种新的直径应用及其各自的应用标识符：
Diameter Mobile IPv6 IKE (MIP6I) 7 Diameter Mobile IPv6 Auth (MIP6A) 8
Diameter移动IPv6 IKE（MIP6I）7 Diameter移动IPv6身份验证（MIP6A）8
The MIP6I Application Identifier is used when the MN is authenticated and authorized using IKEv2. The MIP6A Application Identifier is used when the MN is authenticated and authorized using the Mobile IPv6 Authentication Protocol.
当使用IKEv2对MN进行身份验证和授权时，使用MIP6I应用程序标识符。当使用移动IPv6身份验证协议对MN进行身份验证和授权时，将使用MIP6A应用程序标识符。
Mobile IPv6-related accounting information generated by the HA uses either the MIP6I or the MIP6A Application Identifier in the case of the coupled accounting model. The Diameter Base Accounting Application Identifier (value of 3) is used in the case of the split accounting model. Refer to Section 4.4 for more information regarding the accounting models.
在耦合计费模型的情况下，HA生成的移动IPv6相关计费信息使用MIP6I或MIP6A应用程序标识符。在拆分会计模型的情况下，使用直径基础会计应用程序标识符（值3）。有关会计模型的更多信息，请参阅第4.4节。
The use of IKEv2 with EAP between the MN and the HA allows the AAA to authenticate the MN. When EAP is used with IKEv2, the Diameter EAP application logic and procedures, as defined in [RFC4072], are re-used. EAP methods that do not establish a shared key SHOULD NOT be used, as they are subject to a number of man-in-the-middle attacks as stated in Section 2.16 and Section 5 of [RFC4306]. Attribute-value pairs (AVPs) specific to Mobile IPv6 bootstrapping are added to the EAP application commands.
在MN和HA之间使用IKEv2和EAP允许AAA对MN进行身份验证。当EAP与IKEv2一起使用时，将重复使用[RFC4072]中定义的直径EAP应用逻辑和程序。不应使用未建立共享密钥的EAP方法，因为它们会受到[RFC4306]第2.16节和第5节中所述的大量中间人攻击。特定于移动IPv6引导的属性值对（AVP）被添加到EAP应用程序命令中。
Figure 2 shows the message flow involved during the authentication phase when EAP is used. The communication between the mobile node and the home agent uses the conventions defined in [RFC4306]. Similarly, the communication between the home agent and the Diameter server uses the conventions defined in [RFC4072].
图2显示了使用EAP时身份验证阶段涉及的消息流。移动节点和归属代理之间的通信使用[RFC4306]中定义的约定。类似地，归属代理和Diameter服务器之间的通信使用[RFC4072]中定义的约定。
Mobile Home Diameter
Node Agent Server
| | |
| HDR, SAi1, KEi, Ni (1) | |
|-------------------------------->| |
| | |
| HDR, SAr1, KEr, Nr, [CERTREQ](2)| |
|<--------------------------------| |
| | |
| HDR, SK{IDi,[CERTREQ,] [IDr,] | |
| [CP(CFG_REQUEST),] | |
| SAi2, TSi, TSr} (3) | DER (EAP-Response) (4) + |
|-------------------------------->| MIP6 Bootstrapping AVPs |
| |------------------------->|
| | |
| | DEA (EAP-Request) (5) |
| HDR, SK{IDr, [CERT,] AUTH, EAP} |<-------------------------|
|<------------------------------- | |
| | |
| HDR, SK{EAP} | |
|-------------------------------->| DER (EAP-Response) |
| |------------------------->|
| | |
| | DEA (EAP-Request) |
| HDR, SK{EAP-Request} |<-------------------------|
|<--------------------------------| |
| | |
| HDR, SK{EAP-Response} | |
|-------------------------------->| DER (EAP-Response) |
| |------------------------->|
: ... : ... :
| | |
| | DEA (EAP-Success) + |
| | MIP6 Bootstrapping AVPs |
| HDR, SK{EAP-Success} |<-------------------------|
|<--------------------------------| |
| | |
| HDR, SK{AUTH} | |
|-------------------------------->| |
| | |
| HDR, SK{AUTH, [CP(CFG_REPLY,] | |
| SAr2, TSi, TSr} | |
|<--------------------------------| |
| | |
Mobile Home Diameter
Node Agent Server
| | |
| HDR, SAi1, KEi, Ni (1) | |
|-------------------------------->| |
| | |
| HDR, SAr1, KEr, Nr, [CERTREQ](2)| |
|<--------------------------------| |
| | |
| HDR, SK{IDi,[CERTREQ,] [IDr,] | |
| [CP(CFG_REQUEST),] | |
| SAi2, TSi, TSr} (3) | DER (EAP-Response) (4) + |
|-------------------------------->| MIP6 Bootstrapping AVPs |
| |------------------------->|
| | |
| | DEA (EAP-Request) (5) |
| HDR, SK{IDr, [CERT,] AUTH, EAP} |<-------------------------|
|<------------------------------- | |
| | |
| HDR, SK{EAP} | |
|-------------------------------->| DER (EAP-Response) |
| |------------------------->|
| | |
| | DEA (EAP-Request) |
| HDR, SK{EAP-Request} |<-------------------------|
|<--------------------------------| |
| | |
| HDR, SK{EAP-Response} | |
|-------------------------------->| DER (EAP-Response) |
| |------------------------->|
: ... : ... :
| | |
| | DEA (EAP-Success) + |
| | MIP6 Bootstrapping AVPs |
| HDR, SK{EAP-Success} |<-------------------------|
|<--------------------------------| |
| | |
| HDR, SK{AUTH} | |
|-------------------------------->| |
| | |
| HDR, SK{AUTH, [CP(CFG_REPLY,] | |
| SAr2, TSi, TSr} | |
|<--------------------------------| |
| | |
Figure 2: Mobile IPv6 Bootstrapping Using IKEv2 and EAP
图2：使用IKEv2和EAP的移动IPv6引导
The MN and the HA start the interaction with an IKE_SA_INIT exchange.
MN和HA开始与IKE_SA_INIT交换进行交互。
In this phase, cryptographic algorithms are negotiated, and nonces and Diffie-Hellman parameters are exchanged. Message (3) starts the IKE_AUTH phase. This second phase authenticates the previous messages, exchanges identities and certificates, and establishes the first CHILD_SA. It is used to mutually authenticate the MN (acting as an IKEv2 initiator) and the HA (acting as an IKEv2 responder). The identity of the user/MN is provided in the IDi field. The MN indicates its willingness to be authenticated via EAP by omitting the AUTH field in message (3) (see Section 2.16 of [RFC4306]).
在此阶段，协商密码算法，并交换nonce和Diffie-Hellman参数。消息（3）启动IKE_验证阶段。第二阶段验证先前的消息，交换身份和证书，并建立第一个子系统。它用于相互验证MN（充当IKEv2启动器）和HA（充当IKEv2响应程序）。IDi字段中提供了用户/MN的身份。MN通过省略消息（3）中的AUTH字段表示其愿意通过EAP进行身份验证（参见[RFC4306]第2.16节）。
As part of the authentication process, the MN MAY request a home address or a home prefix or suggest one (see [RFC4877]), using a CFG_REQUEST payload in the message (3).
作为认证过程的一部分，MN可以使用消息（3）中的CFG_请求有效载荷请求归属地址或归属前缀或建议归属地址或归属前缀（参见[RFC4877]）。
The HA extracts the IDi field from the message (3) and sends a Diameter-EAP-Request (DER) message (4) towards the authenticating Diameter server. The EAP-Payload AVP contains a EAP-Response/ Identity with the identity extracted from the IDi field.
HA从消息（3）中提取IDi字段，并向身份验证Diameter服务器发送Diameter EAP请求（DER）消息（4）。EAP有效负载AVP包含EAP响应/标识，标识从IDi字段中提取。
This message is routed to the MN's Diameter server/EAP server. The Diameter server selects the EAP method and replies with the Diameter-EAP-Answer (DEA) message. Depending on the type of EAP method chosen, a number of DER and DEA messages carry the method-specific exchanges between the MN and the Diameter server/EAP server.
此消息被路由到MN的Diameter服务器/EAP服务器。Diameter服务器选择EAP方法并使用Diameter EAP应答（DEA）消息进行应答。根据所选EAP方法的类型，许多DER和DEA消息在MN和Diameter服务器/EAP服务器之间进行方法特定的交换。
At the end of the EAP authentication phase, the Diameter server indicates the result of the authentication in the Result-Code AVP and provides the corresponding EAP packet (EAP Success or EAP Failure). The last IKEv2 message sent by the HA contains the home address or the home prefix. In the latter case, a CREATE_CHILD_SA exchange is necessary to set up IPsec SAs for Mobile IPv6 signaling.
在EAP认证阶段结束时，Diameter服务器在结果代码AVP中指示认证结果，并提供相应的EAP数据包（EAP成功或EAP失败）。HA发送的最后一条IKEv2消息包含家庭地址或家庭前缀。在后一种情况下，需要创建子SA交换来为移动IPv6信令设置IPsec SAs。
In some deployment scenarios, the HA may also act as an IKEv2 responder for a conventional IPsec VPN access. The challenge in this case is that the IKEv2 responder may not know if IKEv2 is used for Mobile IPv6 service or for IPsec VPN access service. A network operator needs to be aware of this limitation. One solution already supported by IKEv2 is to use different responder identities when operating as a conventional IPsec VPN gateway or as an HA. The MN can then indicate the preferred responder type using the appropriate IDr payload in the IKE_AUTH message.
在某些部署场景中，HA还可以充当传统IPsec VPN访问的IKEv2响应程序。这种情况下的挑战是IKEv2响应程序可能不知道IKEv2是用于移动IPv6服务还是用于IPsec VPN访问服务。网络运营商需要意识到这一限制。IKEv2已经支持的一个解决方案是在作为传统IPsec VPN网关或HA运行时使用不同的响应者身份。然后，MN可以使用IKE_AUTH消息中的适当IDr有效负载指示首选响应器类型。
Eventually, when the HA receives a Binding Update (BU), the HA authenticates and authorizes the MN. It is RECOMMENDED that the HA sends an accounting request message every time it receives a BU.
最终，当HA收到绑定更新（BU）时，HA对MN进行身份验证和授权。建议HA在每次收到BU时发送记帐请求消息。
Figure 3 shows the message sequence between the MN, the HA, and the Diameter server during the registration when Mobile IPv6 Authentication Protocol is used. A BU and a Binding Acknowledgement (BA) messages are used in the binding registration process.
图3显示了使用移动IPv6身份验证协议时注册期间MN、HA和Diameter服务器之间的消息序列。BU和绑定确认（BA）消息用于绑定注册过程。
Receiving a BU at the HA initiates a MIP6-Request to be sent to the Diameter server. The Diameter server in turn responds with a MIP6- Answer. The HA may assign a home address to the MN and provide it to the Diameter server in the MIP-Mobile-Node-Address AVP.
在HA处接收BU将启动发送到Diameter服务器的MIP6请求。Diameter服务器依次响应一个MIP6-Answer。HA可以向MN分配归属地址，并在MIP移动节点地址AVP中将其提供给Diameter服务器。
According to [RFC4285], the MN uses the Mobile Node Identifier Option, specifically the MN-NAI mobility option (as defined in [RFC4283]) to identify itself. The HA MUST copy the MN-NAI mobility option value to the User-Name AVP in the subsequent request messages.
根据[RFC4285]，MN使用移动节点标识符选项，特别是MN-NAI移动性选项（如[RFC4283]中所定义）来识别自身。HA必须在后续请求消息中将MN-NAI移动选项值复制到用户名AVP。
The procedure described in this specification for the Mobile IPv6 Authentication Protocol is only needed for the initially received BU for which the HA does not have an existing security association. When the HA receives subsequent BUs, they are processed locally in the HA. It is RECOMMENDED that the HA sends an accounting request message every time it receives a Binding Update. However, the HA MAY re-authorize the MN with the Diameter server at any time depending on the deployment and the local policy.
本规范中描述的移动IPv6认证协议的过程仅适用于HA没有现有安全关联的初始接收BU。当医管局收到后续总线时，它们将在医管局本地处理。建议HA在每次收到绑定更新时发送记帐请求消息。但是，根据部署和本地策略，HA可以随时使用Diameter服务器重新授权MN。
This specification assumes that in the case where Mobile IPv6 Authentication Protocol is used, the MN-AAA option is included in the BU as defined in [RFC4285] and the Diameter server computes required session keys after having successfully authenticated the MN. The computation of the session keys is out of scope of this specification. Other possible ways of using the Mobile IPv6 Authentication Protocol are also out of scope of this specification and would require a new specification to describe the detailed behavior of the HA-AAAH interface and corresponding session key derivation.
本规范假设在使用移动IPv6认证协议的情况下，MN-AAA选项包括在[RFC4285]中定义的BU中，并且Diameter服务器在成功认证MN后计算所需的会话密钥。会话密钥的计算超出了本规范的范围。使用移动IPv6认证协议的其他可能方式也超出了本规范的范围，需要一个新规范来描述HA-AAAH接口的详细行为和相应的会话密钥派生。
Mobile Home Diameter
Node Agent Server
| | |
| | MIP6-Request + MIP6 |
| Binding Update | Bootstrapping AVPs |
|------------------------------------>|-------------------->|
| (Mobile Node Identifier Option, | |
| Mobility Message Replay Protection | |
| Option, Authentication Option) | |
| | |
| | MIP6-Answer + MIP6 |
| Binding Acknowledgement | Bootstrapping AVPs |
|<------------------------------------|<--------------------|
| (Mobile Node Identifier Option | |
| Mobility Message Replay Protection | |
| Option, Authentication Option) | |
Mobile Home Diameter
Node Agent Server
| | |
| | MIP6-Request + MIP6 |
| Binding Update | Bootstrapping AVPs |
|------------------------------------>|-------------------->|
| (Mobile Node Identifier Option, | |
| Mobility Message Replay Protection | |
| Option, Authentication Option) | |
| | |
| | MIP6-Answer + MIP6 |
| Binding Acknowledgement | Bootstrapping AVPs |
|<------------------------------------|<--------------------|
| (Mobile Node Identifier Option | |
| Mobility Message Replay Protection | |
| Option, Authentication Option) | |
Figure 3: Mobile IPv6 Bootstrapping Using the Mobile IPv6 Authentication Protocol
图3：使用移动IPv6身份验证协议的移动IPv6引导
The Diameter server may maintain state or may be stateless. This is indicated in the Auth-Session-State AVP (or its absence). The HA MUST support the Authorization Session State Machine defined in [RFC3588].
Diameter服务器可能保持状态，也可能是无状态的。这在身份验证会话状态AVP（或其不存在）中指示。HA必须支持[RFC3588]中定义的授权会话状态机。
This specification makes an assumption that each SA created between the MN and the HA as a result of a successful IKEv2 negotiation or a Mobile IPv6 Authentication Protocol exchange corresponds to one Diameter session. In the IKEv2 case, we specifically mean the created IKE SA.
本规范假设由于成功的IKEv2协商或移动IPv6认证协议交换而在MN和HA之间创建的每个SA对应于一个Diameter会话。在IKEv2案例中，我们特别指创建的IKE SA。
The Session-Termination-Request (STR) message [RFC3588] is sent by the HA to inform the Diameter server that an authorized session is being terminated. This means that the HA MUST terminate the corresponding Mobile IPv6 binding and also terminate the corresponding SA.
会话终止请求（STR）消息[RFC3588]由HA发送，以通知Diameter服务器正在终止授权会话。这意味着HA必须终止相应的移动IPv6绑定，并终止相应的SA。
The Session-Termination-Answer (STA) message [RFC3588] is sent by the Diameter server to acknowledge the notification that the session has been terminated.
Diameter服务器发送会话终止应答（STA）消息[RFC3588]以确认会话已终止的通知。
The Abort-Session-Request (ASR) message [RFC3588] is sent by the Diameter server to the HA to terminate the authorized session. This fulfills one of the requirement described in [RFC5637]. When the HA receives the ASR message, it MUST terminate the corresponding SA. Subsequently, the HA MUST take further actions to terminate the corresponding Mobile IPv6 binding.
Diameter服务器向HA发送中止会话请求（ASR）消息[RFC3588]，以终止授权会话。这满足了[RFC5637]中描述的要求之一。当HA收到ASR消息时，它必须终止相应的SA。随后，医管局必须采取进一步行动，终止相应的移动IPv6绑定。
The Abort-Session-Answer (ASA) message [RFC3588] is sent by the home agent in response to an ASR message.
中止会话应答（ASA）消息[RFC3588]由归属代理发送以响应ASR消息。
The HA MUST be able act as a Diameter client collecting accounting records needed for service control and charging. The HA MUST support the accounting procedures (specifically the command codes mentioned below) and the Accounting Session State Machine as defined in [RFC3588]. The command codes, exchanged between the HA and Diameter server for accounting purposes, are provided in the following subsections.
医管局必须能够充当Diameter客户，收集服务控制和收费所需的会计记录。HA必须支持记帐过程（特别是下面提到的命令代码）和[RFC3588]中定义的记帐会话状态机。以下小节提供了HA和Diameter服务器之间为记帐目的交换的命令代码。
The Diameter application design guideline [DIME-APP] defines two separate models for accounting:
直径应用设计指南[DIME-APP]定义了两种单独的核算模型：
Split accounting model:
拆分会计模式：
According to this model, the accounting messages use the Diameter Base Accounting Application Identifier (value of 3). Since accounting is treated as an independent application, accounting commands may be routed separately from the rest of application messages and thus the accounting messages generally end up in a central accounting server. Since the Diameter Mobile IPv6 application does not define its own unique accounting commands, this is the preferred choice, since it permits use of centralized accounting for several applications.
根据此模型，记帐消息使用Diameter基础记帐应用程序标识符（值3）。由于记帐被视为一个独立的应用程序，记帐命令可以与应用程序消息的其余部分分开路由，因此记帐消息通常在中央记帐服务器中结束。由于Diameter Mobile IPv6应用程序没有定义自己独特的记帐命令，因此这是首选，因为它允许对多个应用程序使用集中记帐。
Coupled accounting model:
耦合会计模型：
In this model, the accounting messages will use either the MIP6I or the MIP6A Application Identifiers. This means that accounting messages will be routed like any other Mobile IPv6 application messages. This requires the Diameter server in charge of Mobile IPv6 application to handle the accounting records (e.g., sends them to a proper accounting server).
在此模型中，记帐消息将使用MIP6I或MIP6A应用程序标识符。这意味着记帐消息将像任何其他移动IPv6应用程序消息一样进行路由。这要求负责移动IPv6应用程序的Diameter服务器处理记帐记录（例如，将其发送到适当的记帐服务器）。
As mentioned above, the preferred choice is to use the split accounting model and thus to choose Diameter Base Accounting Application Identifier (value of 3) for accounting messages.
如上所述，首选的选择是使用分割记帐模型，从而为记帐消息选择基于Diameter的记帐应用程序标识符（值3）。
The Accounting-Request command [RFC3588] is sent by the HA to the Diameter server to exchange accounting information regarding the MN with the Diameter server.
HA向Diameter服务器发送记帐请求命令[RFC3588]，以与Diameter服务器交换有关MN的记帐信息。
The Accounting-Answer command [RFC3588] is sent by the Diameter server to the HA to acknowledge an Accounting-Request.
Diameter服务器向HA发送记帐应答命令[RFC3588]，以确认记帐请求。
For the use of Mobile IPv6 with IKEv2 and EAP, this document reuses the Diameter EAP application [RFC4072] commands: Diameter-EAP-Request (DER) and Diameter-EAP-Answer (DEA). This specification extends the existing DER and DEA command ABNFs with a number of AVPs to support Mobile IPv6 split scenario bootstrapping. Other than new additional AVPs and the corresponding additions to the command ABNFs, the Diameter EAP application command ABNFs remain unchanged. The ABNF language is defined in [RFC3588].
为了将移动IPv6与IKEv2和EAP结合使用，本文档重用Diameter EAP应用程序[RFC4072]命令：Diameter EAP请求（DER）和Diameter EAP应答（DEA）。本规范使用大量AVP扩展了现有的DER和DEA命令ABNFs，以支持移动IPv6拆分场景引导。除了新的附加AVP和命令ABNFs的相应添加之外，Diameter EAP应用程序命令ABNFs保持不变。ABNF语言在[RFC3588]中定义。
Command-Name Abbrev. Code Reference Application
---------------------------------------------------------------------
Diameter-EAP-Request DER 268 RFC 4072 Diameter Mobile IPv6 IKE
Diameter-EAP-Answer DEA 268 RFC 4072 Diameter Mobile IPv6 IKE
Command-Name Abbrev. Code Reference Application
---------------------------------------------------------------------
Diameter-EAP-Request DER 268 RFC 4072 Diameter Mobile IPv6 IKE
Diameter-EAP-Answer DEA 268 RFC 4072 Diameter Mobile IPv6 IKE
Figure 4: Command Codes
图4：命令代码
The Diameter-EAP-Request (DER) message, indicated by the Command-Code field set to 268 and the 'R' bit set in the Command Flags field, is sent by the HA to the Diameter server to initiate a Mobile IPv6 service authentication and authorization procedure. The Application-ID field of the Diameter Header MUST be set to the Diameter Mobile IPv6 IKE Application ID (value of 7). The grouped AVP has the following modified ABNF (as defined in [RFC3588]):
由设置为268的命令代码字段和在命令标志字段中设置的“R”位指示的Diameter EAP请求（DER）消息由HA发送到Diameter服务器，以启动移动IPv6服务认证和授权过程。Diameter标头的应用程序ID字段必须设置为Diameter Mobile IPv6 IKE应用程序ID（值7）。分组的AVP具有以下修改的ABNF（定义见[RFC3588]）：
<Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port-Type ]
[ User-Name ]
...
{ EAP-Payload }
...
[ MIP6-Feature-Vector ]
[ MIP6-Agent-Info ]
*2[ MIP-Mobile-Node-Address ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ QoS-Capability ]
* [ QoS-Resources ]
...
* [ AVP ]
<Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port-Type ]
[ User-Name ]
...
{ EAP-Payload }
...
[ MIP6-Feature-Vector ]
[ MIP6-Agent-Info ]
*2[ MIP-Mobile-Node-Address ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ QoS-Capability ]
* [ QoS-Resources ]
...
* [ AVP ]
Mobile IPv6 bootstrapping AVPs are only included in the first DER message send by the HA. The subsequent DER messages required by the EAP method do not need to include any Mobile IPv6 bootstrapping AVPs. The MN is both authenticated and authorized for the mobility service during the EAP authentication. Thus, the Auth-Request-Type AVP MUST be set to the value AUTHORIZE_AUTHENTICATE.
移动IPv6引导AVP仅包含在HA发送的第一条DER消息中。EAP方法所需的后续DER消息不需要包括任何移动IPv6引导AVP。在EAP认证期间，MN被认证并授权用于移动服务。因此，身份验证请求类型AVP必须设置为值AUTHORIZE\u AUTHENTICATE。
The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code field set to 268 and 'R' bit cleared in the Command Flags field, is sent in response to the Diameter-EAP-Request (DER) message. The Application-Id field in the Diameter message header MUST be set to the Diameter Mobile IPv6 IKE Application-Id (value of 7). If the Mobile IPv6 authentication procedure was successful, then the response MAY include any set of bootstrapping AVPs.
Diameter EAP应答（DEA）消息由设置为268的命令代码字段和在命令标志字段中清除的“R”位指示，作为对Diameter EAP请求（DER）消息的响应而发送。Diameter消息头中的应用程序Id字段必须设置为Diameter Mobile IPv6 IKE应用程序Id（值7）。如果移动IPv6身份验证过程成功，则响应可能包括任何一组引导AVP。
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ EAP-Payload ]
[ EAP-Reissued-Payload ]
[ EAP-Master-Session-Key ]
[ EAP-Key-Name ]
[ Multi-Round-Time ]
...
*2[ MIP-Mobile-Node-Address ]
[ MIP6-Feature-Vector ]
[ MIP6-Agent-Info ]
[ Service-Selection ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
...
* [ AVP ]
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ EAP-Payload ]
[ EAP-Reissued-Payload ]
[ EAP-Master-Session-Key ]
[ EAP-Key-Name ]
[ Multi-Round-Time ]
...
*2[ MIP-Mobile-Node-Address ]
[ MIP6-Feature-Vector ]
[ MIP6-Agent-Info ]
[ Service-Selection ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
...
* [ AVP ]
If the EAP-based authentication and the authorization for the mobility service succeeds, then the Mobile IPv6 bootstrapping AVPs are included in the last DEA message that also carries the EAP-Success EAP payload. The other DEA messages required by the used EAP-method do not include any Mobile IPv6 bootstrapping AVPs.
如果基于EAP的身份验证和移动服务授权成功，则移动IPv6引导AVP将包含在最后一条DEA消息中，该消息也携带EAP Success EAP有效负载。所用EAP方法所需的其他DEA消息不包括任何移动IPv6引导AVP。
This section defines the commands that are used for support with the Mobile IPv6 Authentication Protocol.
本节定义了用于支持移动IPv6身份验证协议的命令。
There are multiple ways of deploying and utilizing the Mobile IPv6 Authentication Protocol, especially regarding the associated AAA interactions. In order to support multiple deployment models, this specification defines the MIP6-Auth-Mode AVP that in the request message tells the mode that the HA supports. This specification defines a method that requires the use of the MN-AAA option with the Mobile IPv6 Authentication Protocol.
部署和利用移动IPv6身份验证协议有多种方式，特别是在相关AAA交互方面。为了支持多个部署模型，本规范定义了MIP6 Auth Mode AVP，该AVP在请求消息中告知HA支持的模式。本规范定义了一种方法，该方法要求在移动IPv6身份验证协议中使用MN-AAA选项。
Command-Name Abbrev. Code Reference Application
---------------------------------------------------------------------
MIP6-Request MIR 325 5.3.1 Diameter Mobile IPv6 Auth
MIP6-Answer MIA 325 5.3.2 Diameter Mobile IPv6 Auth
Command-Name Abbrev. Code Reference Application
---------------------------------------------------------------------
MIP6-Request MIR 325 5.3.1 Diameter Mobile IPv6 Auth
MIP6-Answer MIA 325 5.3.2 Diameter Mobile IPv6 Auth
Command Codes
命令代码
The MIP6-Request (MIR), indicated by the Command-Code field set to 325 and the 'R' bit set in the Command Flags field, is sent by the HA, acting as a Diameter client, in order to request the authentication and authorization of an MN.
MIP6请求（MIR）由设置为325的命令代码字段和命令标志字段中设置的“R”位表示，由HA作为Diameter客户端发送，以请求MN的身份验证和授权。
Although the HA provides the Diameter server with replay protection-related information, the HA is responsible for the replay protection.
虽然HA向Diameter服务器提供重播保护相关信息，但HA负责重播保护。
The message format is shown below.
消息格式如下所示。
<MIP6-Request> ::= < Diameter Header: 325, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ Origin-State-Id ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port-Type ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
[ MIP6-Feature-Vector ]
{ MIP6-Auth-Mode }
[ MIP-MN-AAA-SPI ]
[ MIP-MN-HA-SPI ]
1*2{ MIP-Mobile-Node-Address }
{ MIP6-Agent-Info }
{ MIP-Careof-Address }
[ MIP-Authenticator ]
[ MIP-MAC-Mobility-Data ]
[ MIP-Timestamp ]
[ QoS-Capability ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
<MIP6-Request> ::= < Diameter Header: 325, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ Origin-State-Id ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port-Type ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
[ MIP6-Feature-Vector ]
{ MIP6-Auth-Mode }
[ MIP-MN-AAA-SPI ]
[ MIP-MN-HA-SPI ]
1*2{ MIP-Mobile-Node-Address }
{ MIP6-Agent-Info }
{ MIP-Careof-Address }
[ MIP-Authenticator ]
[ MIP-MAC-Mobility-Data ]
[ MIP-Timestamp ]
[ QoS-Capability ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
If the MN is both authenticated and authorized for the mobility service, then the Auth-Request-Type AVP is set to the value AUTHORIZE_AUTHENTICATE. This is the case when the MIP6-Auth-Mode is set to the value MIP6_AUTH_MN_AAA.
如果MN已针对移动服务进行了身份验证和授权，则身份验证请求类型AVP将设置为值AUTHORIZE\u AUTHENTICATE。当MIP6 Auth Mode设置为值MIP6_Auth_MN_AAA时，就是这种情况。
The MIP6-Answer (MIA) message, indicated by the Command-Code field set to 325 and the 'R' bit cleared in the Command Flags field, is sent by the Diameter server in response to the MIP6-Request message.
MIP6应答（MIA）消息由Diameter服务器发送以响应MIP6请求消息，该消息由设置为325的命令代码字段和命令标志字段中清除的“R”位指示。
The User-Name AVP MAY be included in the MIA if it is present in the MIR. The Result-Code AVP MAY contain one of the values defined in Section 7, in addition to the values defined in [RFC3588].
如果MIR中存在用户名AVP，则可以将其包含在MIA中。除[RFC3588]中定义的值外，结果代码AVP还可能包含第7节中定义的值之一。
An MIA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Mobile-Node-Address AVP.
结果代码AVP设置为DIAMETER_SUCCESS的MIA消息必须包含MIP移动节点地址AVP。
The message format is shown below.
消息格式如下所示。
<MIP6-Answer> ::= < Diameter Header: 325, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Request-Type }
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP6-Feature-Vector ]
[ MIP-Agent-Info ]
*2[ MIP-Mobile-Node-Address ]
[ MIP-MN-HA-MSA ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Failed-AVP ]
* [ AVP ]
<MIP6-Answer> ::= < Diameter Header: 325, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Request-Type }
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP6-Feature-Vector ]
[ MIP-Agent-Info ]
*2[ MIP-Mobile-Node-Address ]
[ MIP-MN-HA-MSA ]
* [ QoS-Resources ]
[ Chargeable-User-Identity ]
[ Service-Selection ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Failed-AVP ]
* [ AVP ]
To provide support for [RFC4285] and for [RFC4877], the AVPs in the following subsections are needed. [RFC3588], [RFC4004], and [RFC4005] defined AVPs are reused whenever possible without changing the existing semantics of those AVPs.
为支持[RFC4285]和[RFC4877]，需要以下小节中的AVP。[RFC3588]、[RFC4004]和[RFC4005]定义的AVP尽可能重复使用，而不改变这些AVP的现有语义。
+--------------------+
| AVP Flag Rules |
+----+---+------+----+----+
AVP Defined | | |SHOULD|MUST|MAY |
Attribute Name Code in Value Type |MUST|MAY| NOT | NOT|Encr|
+------------------------------------------+----+---+------+----+----+
|MIP6-Feature- 124 RFC 5447 Unsigned64 | M | P | | V | Y |
| Vector | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-Mobile- | M | P | | V | Y |
| Node-Address 333 RFC 4004 Address | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP6-Agent-Info 486 RFC 5447 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|User-Name 1 RFC 3588 UTF8String | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Service- 493 6.2 UTF8String | M | P | | V | Y |
| Selection | | | | | |
+------------------------------------------+----+---+------+----+----+
|QoS-Capability 578 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|QoS-Resources 508 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-HA-MSA 492 6.12 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Chargeable-User- OctetString| M | P | | V | Y |
| Identity 89 6.19 | | | | | |
+------------------------------------------+----+---+------+----+----+
+--------------------+
| AVP Flag Rules |
+----+---+------+----+----+
AVP Defined | | |SHOULD|MUST|MAY |
Attribute Name Code in Value Type |MUST|MAY| NOT | NOT|Encr|
+------------------------------------------+----+---+------+----+----+
|MIP6-Feature- 124 RFC 5447 Unsigned64 | M | P | | V | Y |
| Vector | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-Mobile- | M | P | | V | Y |
| Node-Address 333 RFC 4004 Address | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP6-Agent-Info 486 RFC 5447 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|User-Name 1 RFC 3588 UTF8String | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Service- 493 6.2 UTF8String | M | P | | V | Y |
| Selection | | | | | |
+------------------------------------------+----+---+------+----+----+
|QoS-Capability 578 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|QoS-Resources 508 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-HA-MSA 492 6.12 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Chargeable-User- OctetString| M | P | | V | Y |
| Identity 89 6.19 | | | | | |
+------------------------------------------+----+---+------+----+----+
AVPs for Mobile IPv6 IKE Application
移动ipv6ike应用的AVPs
Note 1: The QoS-Capability and the QoS-Resource AVPs are defined in Sections 4.1 and 4.3 of [RFC5777].
注1:QoS能力和QoS资源AVP在[RFC5777]的第4.1节和第4.3节中定义。
+--------------------+
| AVP Flag Rules |
+----+---+------+----+----+
AVP Section | | |SHOULD|MUST|MAY |
Attribute Name Code Defined Value Type |MUST|MAY| NOT | NOT|Encr|
+------------------------------------------+----+---+------+----+----+
|MIP6-Feature- 124 RFC 5447 Unsigned64 | M | P | | V | Y |
| Vector | | | | | |
+------------------------------------------+----+---+------+----+----+
|User-Name 1 RFC 3588 UTF8String | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Service- 493 6.2 UTF8String | M | P | | V | Y |
| Selection | | | | | |
+------------------------------------------+----+---+------+----+----+
+--------------------+
| AVP Flag Rules |
+----+---+------+----+----+
AVP Section | | |SHOULD|MUST|MAY |
Attribute Name Code Defined Value Type |MUST|MAY| NOT | NOT|Encr|
+------------------------------------------+----+---+------+----+----+
|MIP6-Feature- 124 RFC 5447 Unsigned64 | M | P | | V | Y |
| Vector | | | | | |
+------------------------------------------+----+---+------+----+----+
|User-Name 1 RFC 3588 UTF8String | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Service- 493 6.2 UTF8String | M | P | | V | Y |
| Selection | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-AAA-SPI 341 RFC 4004 Unsigned32 | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-HA-SPI 491 6.4 Unsigned32 | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Mobile- 333 RFC 4004 Address | M | P | | V | Y |
| Node-Address | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP6-Agent-Info 486 RFC 5447 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Careof- 487 6.7 Address | M | P | | V | Y |
| Address | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP- 488 6.8 OctetString| M | P | | V | Y |
| Authenticator | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-MAC- 489 6.9 OctetString| M | P | | V | Y |
| Mobility-Data | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-Session-Key 343 6.10 OctetString| M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-MSA- 367 RFC 4004 Unsigned32 | M | P | | V | Y |
| Lifetime | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-HA-MSA 492 6.12 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Algorithm- 345 6.13 Enumerated | M | P | | V | Y |
| Type | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-Replay-Mode 346 6.14 Enumerated | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Timestamp 490 6.16 OctetString| M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|QoS-Capability 578 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|QoS-Resources 508 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Chargeable-User- OctetString| M | P | | V | Y |
| Identity 89 6.19 | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP6-Auth-Mode 494 6.20 Enumerated | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Rest of the AVPs RFC 3588 | M | P | | V | Y |
|in the MIR & MIA RFC 4005 | | | | | |
|excluding *[AVP] | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-AAA-SPI 341 RFC 4004 Unsigned32 | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-HA-SPI 491 6.4 Unsigned32 | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Mobile- 333 RFC 4004 Address | M | P | | V | Y |
| Node-Address | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP6-Agent-Info 486 RFC 5447 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Careof- 487 6.7 Address | M | P | | V | Y |
| Address | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP- 488 6.8 OctetString| M | P | | V | Y |
| Authenticator | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-MAC- 489 6.9 OctetString| M | P | | V | Y |
| Mobility-Data | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-Session-Key 343 6.10 OctetString| M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-MSA- 367 RFC 4004 Unsigned32 | M | P | | V | Y |
| Lifetime | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-MN-HA-MSA 492 6.12 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Algorithm- 345 6.13 Enumerated | M | P | | V | Y |
| Type | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP-Replay-Mode 346 6.14 Enumerated | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|MIP-Timestamp 490 6.16 OctetString| M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|QoS-Capability 578 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|QoS-Resources 508 Note 1 Grouped | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Chargeable-User- OctetString| M | P | | V | Y |
| Identity 89 6.19 | | | | | |
+------------------------------------------+----+---+------+----+----+
|MIP6-Auth-Mode 494 6.20 Enumerated | M | P | | V | Y |
+------------------------------------------+----+---+------+----+----+
|Rest of the AVPs RFC 3588 | M | P | | V | Y |
|in the MIR & MIA RFC 4005 | | | | | |
|excluding *[AVP] | | | | | |
+------------------------------------------+----+---+------+----+----+
AVPs for the Mobile IPv6 Auth Application
移动IPv6身份验证应用程序的AVPs
Note 1: The QoS-Capability and the QoS-Resource AVPs are defined in Sections 4.1 and 4.3 of [RFC5777].
注1:QoS能力和QoS资源AVP在[RFC5777]的第4.1节和第4.3节中定义。
The User-Name AVP (AVP Code 1) is of type UTF8String and contains a Network Access Identifier (NAI) extracted from the MN-NAI mobility option included in the received BU message. Alternatively, the NAI can be extracted from the IKEv2 IDi payload included in the IKE_AUTH message sent by the IKE initiator.
用户名AVP（AVP代码1）为UTF8String类型，包含从接收到的BU消息中包含的MN-NAI移动选项中提取的网络访问标识符（NAI）。或者，可以从IKE发起方发送的IKE_AUTH消息中包括的IKEv2 IDi有效载荷中提取NAI。
The Service-Selection AVP (AVP Code 493) is of type UTF8String and contains the name of the service or the external network with which the mobility service should be associated. In the scope of this specification, the value can be extracted from the IKEv2 IDr payload, if available in the IKE_AUTH message sent by the IKE initiator. Alternatively, if the Mobile IPv6 Authentication Protocol is used, then the Service-Selection AVP contains the string extracted from the Service Selection Mobility Option [RFC5149], if available in the received BU. Future specifications may define additional ways to populate the Service-Selection AVP with the required information.
服务选择AVP（AVP代码493）为UTF8String类型，包含移动服务应关联的服务或外部网络的名称。在本规范的范围内，如果IKE启动器发送的IKE_AUTH消息中有该值，则可以从IKEv2 IDr有效负载中提取该值。或者，如果使用移动IPv6认证协议，则服务选择AVP包含从服务选择移动选项[RFC5149]提取的字符串（如果在接收到的BU中可用）。未来的规范可能会定义用所需信息填充服务选择AVP的其他方法。
The AVP is also available to be used in messages sent from the Diameter server to the Diameter client. For example, if the request message did not contain the Service-Selection AVP but the MN was assigned with a default service, the Diameter server MAY return the name of the assigned default service to the HA.
AVP也可用于从Diameter服务器发送到Diameter客户端的消息中。例如，如果请求消息不包含服务选择AVP，但是MN被分配了默认服务，Diameter服务器可以将分配的默认服务的名称返回给HA。
If the Service-Selection AVP is present in both the request and the reply messages, it SHOULD contain the same service name. If the services differ, the HA MAY treat that as authorization failure.
如果服务选择AVP同时出现在请求和回复消息中，则它应该包含相同的服务名称。如果服务不同，医管局可将其视为授权失败。
The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and contains a Security Parameter Index (SPI) code extracted from the Mobility Message Authentication Option included in the received BU message. This AVP is reused from [RFC4004].
MIP-MN-AAA-SPI AVP（AVP代码341）的类型为Unsigned32，并且包含从接收到的BU消息中包括的移动消息认证选项提取的安全参数索引（SPI）代码。此AVP从[RFC4004]重新使用。
When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, this AVP MUST be present in the MIR message.
当MIP6 Auth Mode AVP设置为值MIP6_Auth_MN_AAA时，该AVP必须出现在MIR消息中。
The MIP-MN-HA-SPI AVP (AVP Code 491) is of type Unsigned32 and contains an SPI value that can be used with other parameters for identifying the security association required for the validation of the Mobile IPv6 MN-HA Authentication Option.
MIP-MN-HA-SPI AVP（AVP代码491）的类型为Unsigned32，并包含一个SPI值，该值可与其他参数一起用于标识验证移动IPv6 MN-HA身份验证选项所需的安全关联。
When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, and the Diameter server returns a valid MIP-MN-HA-MSA AVP in the MIA message, this AVP MUST be present inside the MIP-MN-HA-MSA AVP.
当MIP6 Auth Mode AVP设置为值MIP6_Auth_MN_AAA，并且Diameter服务器在MIA消息中返回有效的MIP-MN-HA-MSA AVP时，此AVP必须存在于MIP-MN-HA-MSA AVP中。
The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and contains the HA assigned IPv6 or IPv4 home address of the mobile node.
MIP移动节点地址AVP（AVP代码333）属于Address类型，并且包含移动节点的HA分配的IPv6或IPv4家庭地址。
If the MIP-Mobile-Node-Address AVP contains the unspecified IPv6 address (0::0) or the all-zeroes IPv4 address (0.0.0.0) in a request message, then the HA expects the Diameter server to assign the home address in a subsequent answer message. If the Diameter server assigns only an IPv6 home network prefix to the mobile node, the lower 64 bits of the MIP-Mobile-Node-Address AVP provided address MUST be set to zero.
如果MIP移动节点地址AVP在请求消息中包含未指定的IPv6地址（0:：0）或全零IPv4地址（0.0.0.0），则HA希望Diameter服务器在后续应答消息中分配家庭地址。如果Diameter服务器仅为移动节点分配IPv6家庭网络前缀，则MIP移动节点地址AVP提供的地址的低64位必须设置为零。
This AVP is reused from [RFC4004].
此AVP从[RFC4004]重新使用。
The MIP6-Agent-Info AVP (AVP Code 486) is defined in Section 4.2.1 of [RFC5447] and contains the IPv6 or the IPv4 address information of the HA. The HA address in a request message is the same as in the received BU message that triggered the authentication and authorization procedure towards the Diameter server. One use case is, e.g., to inform the Diameter server of the dynamically assigned HA.
MIP6代理信息AVP（AVP代码486）在[RFC5447]的第4.2.1节中定义，包含HA的IPv6或IPv4地址信息。请求消息中的HA地址与接收到的BU消息中的HA地址相同，BU消息触发了针对Diameter服务器的身份验证和授权过程。一个用例是，例如，通知Diameter服务器动态分配的HA。
If the MIP6-Agent-Info AVP is present in an answer message and the Result-Code AVP is set to DIAMETER_SUCCESS_RELOCATE_HA, then the Diameter server is indicating to the HA that it MUST initiate an HA switch procedure towards the MN (e.g., using the procedure defined in [RFC5142]). If the Result-Code AVP is set to any other value, then the HA SHOULD initiate the HA switch procedure towards the MN. The address information of the assigned HA is defined in the MIP6-Agent-Info AVP.
如果MIP6代理信息AVP出现在应答消息中，并且结果代码AVP设置为DIAMETER_SUCCESS_RELOCATE_HA，则DIAMETER服务器向HA指示它必须向MN启动HA切换过程（例如，使用[RFC5142]中定义的过程）。如果结果代码AVP设置为任何其他值，则HA应向MN启动HA切换程序。已分配HA的地址信息在MIP6代理信息AVP中定义。
The MIP-Careof-Address AVP (AVP Code 487) is of type Address and contains the IPv6 or the IPv4 care-of address of the mobile node. The HA extracts this IP address from the received BU message.
MIP转交地址AVP（AVP代码487）属于Address类型，包含移动节点的IPv6或IPv4转交地址。HA从收到的BU消息中提取此IP地址。
The MIP-Authenticator AVP (AVP Code 488) is of type OctetString and contains the Authenticator Data from the received BU message. The HA extracts this data from the MN-AAA Mobility Message Authentication Option included in the received BU message.
MIP验证器AVP（AVP代码488）为OctetString类型，包含来自接收到的BU消息的验证器数据。HA从接收到的BU消息中包含的MN-AAA移动消息认证选项中提取该数据。
When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, this AVP MUST be present in the MIR message.
当MIP6 Auth Mode AVP设置为值MIP6_Auth_MN_AAA时，该AVP必须出现在MIR消息中。
The MIP-MAC-Mobility-Data AVP (AVP Code 489) is of type OctetString and contains the MAC_Mobility_Data calculated by the HA as defined in [RFC4285] for the MN-AAA Mobility Message Authentication Option.
MIP MAC移动性数据AVP（AVP代码489）为OctetString类型，包含由HA计算的MAC_移动性_数据，如[RFC4285]中针对MN-AAA移动性消息认证选项所定义。
When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, this AVP MUST be present in the MIR message.
当MIP6 Auth Mode AVP设置为值MIP6_Auth_MN_AAA时，该AVP必须出现在MIR消息中。
The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and contains the MN-HA shared secret (i.e., the session key) for the associated Mobile IPv6 MN-HA authentication option. When the Diameter server computes the session key, it is placed in this AVP. How the Diameter server computes the session key is not defined in this specification. The Session key derivation is deployment specific and needs to be defined in a respective deployment-specific system specification.
MIP会话密钥AVP（AVP代码343）是OctetString类型，并且包含用于相关移动IPv6 MN-HA认证选项的MN-HA共享密钥（即会话密钥）。当Diameter服务器计算会话密钥时，它被放置在此AVP中。Diameter服务器如何计算会话密钥未在本规范中定义。会话密钥派生是特定于部署的，需要在相应的特定于部署的系统规范中定义。
This AVP is reused from [RFC4004].
此AVP从[RFC4004]重新使用。
The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and represents the period of time (in seconds) for which the session key (see Section 6.10) is valid. The associated session key MUST NOT be used if the lifetime has expired.
MIP MSA生存期AVP（AVP代码367）类型为Unsigned32，表示会话密钥（见第6.10节）有效的时间段（以秒为单位）。如果生存期已过期，则不得使用关联的会话密钥。
This AVP is reused from [RFC4004].
此AVP从[RFC4004]重新使用。
The MIP-MN-HA-MSA AVP (AVP Code 492) is of type Grouped and contains the session-related information for use with the Mobile IPv6 Authentication Protocol.
MIP-MN-HA-MSA AVP（AVP代码492）属于分组类型，包含用于移动IPv6身份验证协议的会话相关信息。
MIP-MN-HA-MSA ::= < AVP Header: 492 >
{ MIP-Session-Key }
{ MIP-MSA-Lifetime }
[ MIP-MN-HA-SPI ]
[ MIP-Algorithm-Type ]
[ MIP-Replay-Mode ]
* [ AVP ]
MIP-MN-HA-MSA ::= < AVP Header: 492 >
{ MIP-Session-Key }
{ MIP-MSA-Lifetime }
[ MIP-MN-HA-SPI ]
[ MIP-Algorithm-Type ]
[ MIP-Replay-Mode ]
* [ AVP ]
The MIP-MN-HA-SPI sub-AVP within the MIP-MN-HA-MSA grouped AVP identifies the security association required for the validation of the Mobile IPv6 MN-HA Authentication Option. The absence of the MIP-Replay-Mode AVP MUST be treated as no replay protection was selected.
MIP-MN-HA-MSA分组AVP中的MIP-MN-HA-SPI子AVP标识验证移动IPv6 MN-HA身份验证选项所需的安全关联。必须将缺少MIP Replay Mode AVP视为未选择Replay保护。
The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and contains the Algorithm identifier for the associated Mobile IPv6 MN-HA Authentication Option. The Diameter server selects the algorithm type. Existing algorithm types are defined in [RFC4004] that also fulfill current RFC 4285 requirements. This AVP is reused from [RFC4004].
MIP算法类型AVP（AVP代码345）属于枚举类型，并且包含相关移动IPv6 MN-HA认证选项的算法标识符。Diameter服务器选择算法类型。[RFC4004]中定义了现有的算法类型，这些算法类型也满足当前的RFC 4285要求。此AVP从[RFC4004]重新使用。
When the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA, and the Diameter server returns a valid MIP-MN-HA-MSA AVP in the MIA message, this AVP MUST be present inside the MIP-MN-HA-MSA AVP.
当MIP6 Auth Mode AVP设置为值MIP6_Auth_MN_AAA，并且Diameter服务器在MIA消息中返回有效的MIP-MN-HA-MSA AVP时，此AVP必须存在于MIP-MN-HA-MSA AVP中。
The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and contains the replay mode of the HA for authenticating the mobile node. Out of all possible replay modes defined in [RFC4004], the following are supported by this specification:
MIP重播模式AVP（AVP代码346）是枚举的类型，并且包含用于认证移动节点的HA的重播模式。在[RFC4004]中定义的所有可能的重播模式中，本规范支持以下模式：
1 None 2 Timestamp
1无2时间戳
This AVP is reused from [RFC4004].
此AVP从[RFC4004]重新使用。
The MIP6-Feature-Vector AVP (AVP Code 124) is defined in [RFC5447]. However, this specification does not define any Mobile IPv6 split scenario bootstrapping specific capability flag.
MIP6特征向量AVP（AVP代码124）在[RFC5447]中定义。但是，本规范未定义任何移动IPv6拆分场景引导特定功能标志。
The MIP-Timestamp AVP (AVP Code 490) is of type OctetString and contains an 8-octet timestamp value (i.e., 64-bit timestamp) from the Mobility message replay protection option, defined in [RFC4285]. The HA extracts this value from the received BU message, if available. The HA includes this AVP in the MIR message when the MN-AAA Mobility Message Authentication Option is available in the received BU and the Diameter server is expected to return the key material required for the calculation and validation of the Mobile IPv6 MN-HA Authentication Option (and the MIP6-Auth-Mode AVP is set to value MIP6_AUTH_MN_AAA).
MIP时间戳AVP（AVP代码490）是OctetString类型，并且包含来自移动消息重放保护选项的8-八位时间戳值（即64位时间戳），在[RFC4285]中定义。HA从收到的BU消息中提取该值（如果可用）。当MN-AAA移动消息认证选项在接收到的BU中可用时，HA将该AVP包括在MIR消息中，并且Diameter服务器预计将返回计算和验证移动IPv6 MN-HA认证选项所需的密钥材料（并且MIP6 Auth Mode AVP设置为值MIP6_Auth_MN_AAA）。
The QoS-Capability AVP is defined in [RFC5777] and contains a list of supported Quality of Service profiles.
QoS能力AVP在[RFC5777]中定义，并包含支持的服务质量配置文件列表。
The QoS-Resources AVP is defined in [RFC5777] and provides QoS and packet filtering capabilities.
QoS资源AVP在[RFC5777]中定义，并提供QoS和数据包过滤功能。
The Chargeable-User-Identity AVP (AVP Code 89) is of type OctetString and contains a unique temporary handle of the user. The Chargeable-User-Identity is defined in [RFC4372].
收费用户标识AVP（AVP代码89）为OctetString类型，包含用户的唯一临时句柄。收费用户标识在[RFC4372]中定义。
The MIP6-Auth-Mode (AVP Code 494) is of type Enumerated and contains information of the used Mobile IPv6 Authentication Protocol mode. This specification defines only one value MIP6_AUTH_MN_AAA and the corresponding AAA interactions when MN-AAA security association is used to authenticate the Binding Update as described in [RFC4285]. When the MIP6-Auth_Mode AVP is set to the value of MIP6_AUTH_MN_AAA, the Auth-Request-Type AVP MUST be set to the value of AUTHORIZE_AUTHENTICATE.
MIP6身份验证模式（AVP代码494）属于枚举类型，包含所用移动IPv6身份验证协议模式的信息。如[RFC4285]所述，当使用MN-AAA安全关联对绑定更新进行身份验证时，本规范仅定义一个值MIP6_AUTH_MN_AAA和相应的AAA交互。当MIP6-Auth_Mode AVP设置为MIP6_Auth_MN_AAA的值时，必须将Auth请求类型AVP设置为AUTHORY_AUTHERATITICATE的值。
If the Diameter server does not support the Mobile IPv6 Authentication Protocol usage mode proposed by the HA, then the Diameter server MUST fail the authentication/authorization and MUST set the Result-Code AVP to the value of DIAMETER_ERROR_AUTH_MODE.
如果Diameter服务器不支持HA建议的移动IPv6身份验证协议使用模式，则Diameter服务器的身份验证/授权必须失败，并且必须将结果代码AVP设置为Diameter_ERROR_AUTH_mode的值。
Diameter Mobile IPv6 applications, either MIP6I or MIP6A, are used in the case of the coupled account model. Diameter Mobile IPv4 application [RFC4004] accounting AVPs are reused in this document. The following AVPs SHOULD be included in the accounting request message:
Diameter移动IPv6应用程序（MIP6I或MIP6A）用于耦合帐户模型。Diameter Mobile IPv4应用程序[RFC4004]会计AVP在本文档中重复使用。会计请求消息中应包括以下AVP：
o Accounting-Input-Octets: Number of octets in IP packets received from the mobile node.
o 记帐输入八位字节：从移动节点接收的IP数据包中的八位字节数。
o Accounting-Output-Octets: Number of octets in IP packets sent by the mobile node.
o 记帐输出八位字节：移动节点发送的IP数据包中的八位字节数。
o Accounting-Input-Packets: Number of IP packets received from the mobile node.
o 记帐输入数据包：从移动节点接收的IP数据包数。
o Accounting-Output-Packets: Number of IP packets sent by the mobile node.
o 记帐输出数据包：移动节点发送的IP数据包数。
o Acct-Multi-Session-Id: Used to link together multiple related accounting sessions, where each session would have a unique Session-Id, but the same Acct-Multi-Session-Id AVP.
o Acct Multi Session Id：用于链接多个相关的记帐会话，其中每个会话都有一个唯一的会话Id，但具有相同的Acct Multi Session Id AVP。
o Acct-Session-Time: Indicates the length of the current session in seconds.
o Acct Session Time（帐户会话时间）：以秒为单位指示当前会话的长度。
o MIP6-Feature-Vector: The supported features for this mobility service session.
o MIP6功能向量：此移动服务会话支持的功能。
o MIP-Mobile-Node-Address: The home address of the mobile node.
o MIP移动节点地址：移动节点的家庭地址。
o MIP-Agent-Info: The current home agent of the mobile node.
o MIP代理信息：移动节点的当前归属代理。
o Chargeable-User-Identity: The unique temporary identity of the user. This AVP MUST be included if it is available in the home agent.
o 计费用户标识：用户的唯一临时标识。如果该AVP在home agent中可用，则必须包含该AVP。
o Service-Selection: Currently selected mobility service.
o 服务选择：当前选择的移动服务。
o QoS-Resources: Assigned Quality-of-Service (QoS) resources for the mobile node.
o QoS资源：为移动节点分配的服务质量（QoS）资源。
o QoS-Capability: The QoS capability related to the assigned QoS-Resources.
o QoS能力：与分配的QoS资源相关的QoS能力。
o MIP-Careof-Address: The current care-of address of the mobile node.
o MIP转交地址：移动节点的当前转交地址。
This section defines new Result-Code [RFC3588] values that MUST be supported by all Diameter implementations that conform to this specification.
本节定义了符合本规范的所有直径实施必须支持的新结果代码[RFC3588]值。
Errors that fall within the Success category are used to inform a peer that a request has been successfully completed.
属于成功类别的错误用于通知对等方请求已成功完成。
DIAMETER_SUCCESS_RELOCATE_HA (Status Code 2009)
直径\u成功\u重新安置\u HA（状态代码2009）
This result code is used by the Diameter server to inform the HA that the MN MUST be switched to another HA.
Diameter服务器使用此结果代码通知HA必须将MN切换到另一个HA。
Errors that fall within the Permanent Failures category are used to inform the peer that the request failed and SHOULD NOT be attempted again.
属于永久故障类别的错误用于通知对等方请求失败，不应再次尝试。
DIAMETER_ERROR_MIP6_AUTH_MODE (Status Code 5041)
直径错误MIP6身份验证模式（状态代码5041）
This error code is used by the Diameter server to inform the peer that the requested Mobile IPv6 Authentication Protocol usage mode is not supported.
Diameter服务器使用此错误代码通知对等方不支持请求的移动IPv6身份验证协议使用模式。
The following tables present the AVPs defined in this document and their occurrences in Diameter messages. Note that AVPs that can only be present within a Grouped AVP are not represented in this table.
下表显示了本文档中定义的AVP及其在Diameter消息中的出现情况。请注意，此表中未显示只能出现在分组AVP中的AVP。
The tables use the following symbols:
这些表使用以下符号：
0:
0:
The AVP MUST NOT be present in the message.
AVP不得出现在消息中。
0+:
0+:
Zero or more instances of the AVP MAY be present in the message.
消息中可能存在零个或多个AVP实例。
0-1:
0-1:
Zero or one instance of the AVP MAY be present in the message.
消息中可能存在零个或一个AVP实例。
1:
1:
One instance of the AVP MUST be present in the message.
消息中必须有一个AVP实例。
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
AVP Name | DER | DEA | MIR | MIA |
-------------------------------|-----+-----+-----+-----+
MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Mobile-Node-Address | 1-2 | 0-2 | 1-2 | 0-2 |
MIP-MN-AAA-SPI | 0 | 0 | 0-1 | 0 |
MIP-MN-HA-SPI | 0 | 0 | 0-1 | 0 |
MIP6-Agent-Info | 1 | 0-1 | 1 | 0-1 |
MIP-Careof-Address | 0 | 0 | 0-1 | 0 |
MIP-Authenticator | 0 | 0 | 0-1 | 0 |
MIP-MAC-Mobility-Data | 0 | 0 | 0-1 | 0 |
MIP-MSA-Lifetime | 0 | 0 | 0 | 1 |
MIP-MN-HA-MSA | 0 | 0 | 0 | 0-1 |
MIP-Timestamp | 0 | 0 | 0-1 | 0-1 |
User-Name | 0-1 | 0-1 | 1 | 0-1 |
Service-Selection | 0-1 | 0-1 | 0-1 | 0-1 |
QoS-Resources | 0+ | 0+ | 0+ | 0+ |
QoS-Capability | 0-1 | 0 | 0-1 | 0 |
Chargeable-User-Identity | 0-1 | 0-1 | 0-1 | 0-1 |
MIP6-Auth-Mode | 0 | 0 | 1 | 0 |
+-----+-----+-----+-----+
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
AVP Name | DER | DEA | MIR | MIA |
-------------------------------|-----+-----+-----+-----+
MIP6-Feature-Vector | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Mobile-Node-Address | 1-2 | 0-2 | 1-2 | 0-2 |
MIP-MN-AAA-SPI | 0 | 0 | 0-1 | 0 |
MIP-MN-HA-SPI | 0 | 0 | 0-1 | 0 |
MIP6-Agent-Info | 1 | 0-1 | 1 | 0-1 |
MIP-Careof-Address | 0 | 0 | 0-1 | 0 |
MIP-Authenticator | 0 | 0 | 0-1 | 0 |
MIP-MAC-Mobility-Data | 0 | 0 | 0-1 | 0 |
MIP-MSA-Lifetime | 0 | 0 | 0 | 1 |
MIP-MN-HA-MSA | 0 | 0 | 0 | 0-1 |
MIP-Timestamp | 0 | 0 | 0-1 | 0-1 |
User-Name | 0-1 | 0-1 | 1 | 0-1 |
Service-Selection | 0-1 | 0-1 | 0-1 | 0-1 |
QoS-Resources | 0+ | 0+ | 0+ | 0+ |
QoS-Capability | 0-1 | 0 | 0-1 | 0 |
Chargeable-User-Identity | 0-1 | 0-1 | 0-1 | 0-1 |
MIP6-Auth-Mode | 0 | 0 | 1 | 0 |
+-----+-----+-----+-----+
The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages, as defined in [RFC3588].
本节中的表格用于表示本文档中定义的哪些AVP将出现在会计信息中，如[RFC3588]中所定义。
+-------------+
| Command-Code|
|------+------+
Attribute Name | ACR | ACA |
-------------------------------------|------+------+
Accounting-Input-Octets | 0-1 | 0-1 |
Accounting-Input-Packets | 0-1 | 0-1 |
Accounting-Output-Octets | 0-1 | 0-1 |
Accounting-Output-Packets | 0-1 | 0-1 |
Acct-Multi-Session-Id | 0-1 | 0-1 |
Acct-Session-Time | 0-1 | 0-1 |
MIP6-Feature-Vector | 0-1 | 0-1 |
MIP6-Agent-Info | 0-1 | 0-1 |
MIP-Mobile-Node-Address | 0-2 | 0-2 |
Event-Timestamp | 0-1 | 0 |
MIP-Careof-Address | 0-1 | 0 |
Service-Selection | 0-1 | 0 |
QoS-Capability | 0+ | 0+ |
QoS-Resources | 0+ | 0+ |
Chargeable-User-Identity | 0-1 | 0 |
-------------------------------------|------+------+
+-------------+
| Command-Code|
|------+------+
Attribute Name | ACR | ACA |
-------------------------------------|------+------+
Accounting-Input-Octets | 0-1 | 0-1 |
Accounting-Input-Packets | 0-1 | 0-1 |
Accounting-Output-Octets | 0-1 | 0-1 |
Accounting-Output-Packets | 0-1 | 0-1 |
Acct-Multi-Session-Id | 0-1 | 0-1 |
Acct-Session-Time | 0-1 | 0-1 |
MIP6-Feature-Vector | 0-1 | 0-1 |
MIP6-Agent-Info | 0-1 | 0-1 |
MIP-Mobile-Node-Address | 0-2 | 0-2 |
Event-Timestamp | 0-1 | 0 |
MIP-Careof-Address | 0-1 | 0 |
Service-Selection | 0-1 | 0 |
QoS-Capability | 0+ | 0+ |
QoS-Resources | 0+ | 0+ |
Chargeable-User-Identity | 0-1 | 0 |
-------------------------------------|------+------+
This section contains the namespaces that have either been created in this specification or had their values assigned to existing namespaces managed by IANA.
本节包含在本规范中创建的名称空间，或将其值分配给IANA管理的现有名称空间。
IANA has allocated a command code value for the following new command from the Command Code namespace defined in [RFC3588]. See Section 5 for the assignment of the namespace in this specification.
IANA已从[RFC3588]中定义的命令代码命名空间为以下新命令分配了命令代码值。有关本规范中名称空间的分配，请参见第5节。
Command Code | Value
-----------------------------------+------
MIP6-Request/Answer (MIR/MIA) | 325
Command Code | Value
-----------------------------------+------
MIP6-Request/Answer (MIR/MIA) | 325
IANA has registered the following new AVPs from the AVP Code namespace defined in [RFC3588].
IANA已从[RFC3588]中定义的AVP代码命名空间注册了以下新AVP。
o MIP-Careof-Address
o MIP-Careof地址
o MIP-Authenticator
o MIP验证器
o MIP-MAC-Mobility-Data
o 移动数据
o MIP-Timestamp
o MIP时间戳
o MIP-MN-HA-SPI
o MIP-MN-HA-SPI
o MIP-MN-HA-MSA
o MIP-MN-HA-MSA
o Service-Selection
o 服务选择
o MIP6-Auth-Mode
o MIP6身份验证模式
The AVPs are defined in Section 6.
AVP的定义见第6节。
IANA has allocated new values to the Result-Code AVP (AVP Code 268) namespace defined in [RFC3588]. See Section 7 for the assignment of the namespace in this specification.
IANA已将新值分配给[RFC3588]中定义的结果代码AVP（AVP代码268）命名空间。有关本规范中名称空间的分配，请参见第7节。
Result-Code | Value
----------------------------------------------+------
DIAMETER_SUCCESS_RELOCATE_HA | 2009
DIAMETER_ERROR_MIP6_AUTH_MODE | 5041
Result-Code | Value
----------------------------------------------+------
DIAMETER_SUCCESS_RELOCATE_HA | 2009
DIAMETER_ERROR_MIP6_AUTH_MODE | 5041
IANA has allocated two new values "Diameter Mobile IPv6 IKE" and "Diameter Mobile IPv6 Auth" from the Application Identifier namespace defined in [RFC3588].
IANA已从[RFC3588]中定义的应用程序标识符命名空间中分配了两个新值“Diameter Mobile IPv6 IKE”和“Diameter Mobile IPv6 Auth”。
Application Identifier | Value
-----------------------------------+------
Diameter Mobile IPv6 IKE (MIP6I) | 7
Diameter Mobile IPv6 Auth (MIP6A) | 8
Application Identifier | Value
-----------------------------------+------
Diameter Mobile IPv6 IKE (MIP6I) | 7
Diameter Mobile IPv6 Auth (MIP6A) | 8
IANA has created a new registry, "MIP6 Authentication Mode Registry", for use with the enumerated MIP6-Auth-Mode AVP. The registry initially contains the following value:
IANA创建了一个新的注册表“MIP6身份验证模式注册表”，用于枚举的MIP6身份验证模式AVP。注册表最初包含以下值：
Token | Value | Description
---------------------------------------------+----------+------------
MIP6_AUTH_MN_AAA | 1 | RFC 5778
Token | Value | Description
---------------------------------------------+----------+------------
MIP6_AUTH_MN_AAA | 1 | RFC 5778
Allocation of new values follow the example policies described in [RFC5226]. New values for the MIP6-Auth-Mode AVP will be assigned based on the "Specification Required" policy. The value 0 (zero) is reserved, and the maximum value is 4294967295 (i.e., 2^32-1).
新值的分配遵循[RFC5226]中描述的示例策略。MIP6 Auth Mode AVP的新值将根据“所需规范”策略分配。保留值0（零），最大值为4294967295（即2^32-1）。
The security considerations for the Diameter interaction required to accomplish the split scenario are described in [RFC5026]. Additionally, the security considerations of the Diameter base protocol [RFC3588], and Diameter EAP application [RFC4072] are applicable to this document.
[RFC5026]中描述了完成拆分场景所需的Diameter交互的安全注意事项。此外，Diameter基本协议[RFC3588]和Diameter EAP应用程序[RFC4072]的安全注意事项适用于本文件。
The Diameter messages may be transported between the HA and the Diameter server via one or more AAA brokers or Diameter agents. In this case, the HA to the Diameter server AAA communication relies on the security properties of the intermediating AAA inter-connection networks, AAA brokers, and Diameter agents (such as proxies).
Diameter消息可以通过一个或多个AAA代理或Diameter代理在HA和Diameter服务器之间传输。在这种情况下，HA到Diameter服务器AAA通信依赖于中间AAA互连网络、AAA代理和Diameter代理（例如代理）的安全属性。
In the case of the Authentication Protocol for Mobile IPv6 [RFC4285], this specification expects that the Diameter server derives the MN-HA Security Association and returns the associated session key (i.e., the MN-HA shared session key) to the HA. However, this specification does not define nor do other IETF specifications define how the Diameter server actually derives required keys. The details of the key derivation depends on the deployment where this specification is used and therefore the security properties of the system depend on how this is done.
对于移动IPv6的身份验证协议[RFC4285]，本规范要求Diameter服务器导出MN-HA安全关联，并将关联的会话密钥（即MN-HA共享会话密钥）返回给HA。但是，本规范没有定义，其他IETF规范也没有定义Diameter服务器实际如何派生所需密钥。密钥派生的细节取决于使用此规范的部署，因此系统的安全属性取决于如何执行此操作。
The authors would like to thank Jari Arkko, Tolga Asversen, Pasi Eronen, Santiago Zapata Hernandez, Anders Kristensen, Avi Lior, John Loughney, Ahmad Muhanna, Behcet Sarikaya, Basavaraj Patil, Vijay Devarapalli, Lionel Morand, Domagoj Premec, Semyon Mizikovsky, and Yoshihiro Ohba for all the useful discussions. Ahmad Muhanna provided a detailed review of the document in August 2007. Pasi Eronen provided detailed comments and text proposals during the IESG review that helped to improved this document greatly.
作者要感谢贾里·阿尔科、托尔加·阿斯维森、帕西·埃隆、圣地亚哥·萨帕塔·埃尔南德斯、安德斯·克里斯滕森、阿维·利奥、约翰·洛尼、艾哈迈德·穆哈纳、贝塞特·萨里卡亚、巴萨瓦拉吉·帕蒂尔、维杰·德瓦拉帕利、莱昂内尔·莫兰、多马戈·普雷梅克、塞米扬·米齐科夫斯基和大贺吉弘，感谢所有这些有用的讨论。艾哈迈德·穆哈纳于2007年8月详细审查了该文件。Pasi Eronen在IESG审查期间提供了详细的评论和文本建议，这有助于大大改进本文件。
We would also like to thank our Area Director, Dan Romascanu, for his support.
我们还要感谢我们的区域主任Dan Romascanu的支持。
Hannes Tschofenig would like to thank the European Commission support in the co-funding of the ENABLE project, where this work is partly being developed.
Hannes Tschofenig感谢欧盟委员会对ENABLE项目的共同资助，该项目的部分工作正在开发中。
Julien Bournelle would like to thank GET/INT since he began this work while he was under their employ.
Julien Bournelle要感谢GET/INT，因为他在受雇期间开始了这项工作。
Madjid Nakhjiri would like to thank Huawei USA as most of his contributions to this document were possible while he was under their employ.
Madjid Nakhjiri要感谢华为美国公司，因为他对本文件的大部分贡献都是在受雇期间完成的。
[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月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[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月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004]Calhoun，P.，Johansson，T.，Perkins，C.，Hiller，T.，和P.McCann，“Diameter移动IPv4应用”，RFC 40042005年8月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005]Calhoun，P.，Zorn，G.，Spence，D.，和D.Mitton，“Diameter网络访问服务器应用”，RFC 4005，2005年8月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
[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月。
[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月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006.
[RFC4372]Adrangi，F.，Lior，A.，Korhonen，J.，和J.Loughney，“收费用户身份”，RFC 4372，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月。
[RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008.
[RFC5142]Haley，B.，Devarapalli，V.，Deng，H.，和J.Kempf，“移动头归属代理切换消息”，RFC 51422008年1月。
[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008.
[RFC5149]Korhonen，J.，Nilsson，U.，和V.Devarapalli，“移动IPv6的服务选择”，RFC 5149，2008年2月。
[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009.
[RFC5447]Korhonen，J.，Bournelle，J.，Tschofenig，H.，Perkins，C.，和K.Chowdhury，“Diameter移动IPv6：支持网络访问服务器到Diameter服务器的交互”，RFC 5447，2009年2月。
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, February 2010.
[RFC5777]Korhonen，J.，Tschofenig，H.，Arumaithurai，M.，Jones，M.，Ed.，和A.Lior，“直径的流量分类和服务质量（QoS）属性”，RFC 5777，2010年2月。
[DIME-APP] Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J. Loughney, "Diameter Applications Design Guidelines", Work in Progress, July 2009.
[DIME-APP]Fajardo，V.，Asveren，T.，Tschofenig，H.，McGregor，G.，和J.Loughney，“直径应用设计指南”，正在进行的工作，2009年7月。
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[RFC4640]Patel，A.和G.Giaretta，“引导移动IPv6（MIPv6）的问题陈述”，RFC 46402006年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]Soliman，H.，“双栈主机和路由器的移动IPv6支持”，RFC 55552009年6月。
[RFC5637] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and R. Lopez, "Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6", RFC 5637, September 2009.
[RFC5637]Giaretta，G.，Guardini，I.，Demaria，E.，Bournelle，J.，和R.Lopez，“移动IPv6的认证、授权和计费（AAA）目标”，RFC 5637，2009年9月。
Authors' Addresses
作者地址
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland
Jouni Korhonen（编辑）诺基亚西门子网络公司Linnoitustie 6 Espoo FIN-02600芬兰
EMail: jouni.nospam@gmail.com
EMail: jouni.nospam@gmail.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland
Hannes Tschofenig诺基亚西门子网络Linnoitustie 6 Espoo FIN-02600芬兰
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Julien Bournelle Orange Labs 38-4O rue du general Leclerc Issy-Les-Moulineaux 92794 France
Julien Bournelle Orange实验室法国莱克勒将军大道38-4O号
EMail: julien.bournelle@orange-ftgroup.com
EMail: julien.bournelle@orange-ftgroup.com
Gerardo Giaretta Qualcomm 5775 Morehouse Dr San Diego, CA 92121 USA
Gerardo Giaretta高通公司5775 Morehouse Dr San Diego，CA 92121美国
EMail: gerardo.giaretta@gmail.com
EMail: gerardo.giaretta@gmail.com
Madjid Nakhjiri Motorola USA
美国摩托罗拉公司
EMail: madjid.nakhjiri@motorola.com
EMail: madjid.nakhjiri@motorola.com