Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 6618 Nokia Siemens Networks
Category: Experimental B. Patil
ISSN: 2070-1721 Nokia
H. Tschofenig
Nokia Siemens Networks
D. Kroeselberg
Siemens
May 2012
Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 6618 Nokia Siemens Networks
Category: Experimental B. Patil
ISSN: 2070-1721 Nokia
H. Tschofenig
Nokia Siemens Networks
D. Kroeselberg
Siemens
May 2012
Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent
移动IPv6安全框架使用传输层安全性在移动节点和归属代理之间进行通信
Abstract
摘要
Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent (HA) is secured using IPsec. The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol (IKE) version 1 or 2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/IPsec module of the IP stack. This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the MN and HA.
移动节点（MN）与其归属代理（HA）之间的移动IPv6信令使用IPsec进行保护。MN和HA之间的安全关联（SA）是使用Internet密钥交换协议（IKE）版本1或2建立的。为依赖IKE/IPsec的移动IPv6指定的安全模型要求移动IPv6协议组件与IP堆栈的IKE/IPsec模块之间进行交互。本文档提出了移动IPv6和双栈移动IPv6的替代安全框架，该框架依赖于传输层安全性来建立密钥材料和其他引导参数，以保护MN和HA之间的移动IPv6信令和数据流量。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6618.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6618.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................3
2. Terminology and Abbreviations ...................................4
3. Background ......................................................5
4. TLS-Based Security Establishment ................................5
4.1. Overview ...................................................5
4.2. Architecture ...............................................7
4.3. Security Association Management ............................7
4.4. Bootstrapping of Additional Mobile IPv6 Parameters .........9
4.5. Protecting Traffic between Mobile Node and Home Agent .....10
5. MN-to-HAC Communication ........................................10
5.1. Request-Response Message Framing over TLS-Tunnel ..........10
5.2. Request-Response Message Content Encoding .................11
5.3. Request-Response Message Exchange .........................12
5.4. Home Agent Controller Discovery ...........................13
5.5. Generic Request-Response Parameters .......................13
5.5.1. Mobile Node Identifier .............................13
5.5.2. Authentication Method ..............................13
5.5.3. Extensible Authentication Protocol Payload .........14
5.5.4. Status Code ........................................14
5.5.5. Message Authenticator ..............................14
5.5.6. Retry After ........................................14
5.5.7. End of Message Content .............................14
5.5.8. Random Values ......................................15
5.6. Security Association Configuration Parameters .............15
5.6.1. Security Parameter Index ...........................15
5.6.2. MN-HA Shared Keys ..................................16
5.6.3. Security Association Validity Time .................16
5.6.4. Security Association Scope (SAS) ...................16
5.6.5. Ciphersuites and Ciphersuite-to-Algorithm Mapping ..17
5.7. Mobile IPv6 Bootstrapping Parameters ......................18
5.7.1. Home Agent Address .................................18
1. Introduction ....................................................3
2. Terminology and Abbreviations ...................................4
3. Background ......................................................5
4. TLS-Based Security Establishment ................................5
4.1. Overview ...................................................5
4.2. Architecture ...............................................7
4.3. Security Association Management ............................7
4.4. Bootstrapping of Additional Mobile IPv6 Parameters .........9
4.5. Protecting Traffic between Mobile Node and Home Agent .....10
5. MN-to-HAC Communication ........................................10
5.1. Request-Response Message Framing over TLS-Tunnel ..........10
5.2. Request-Response Message Content Encoding .................11
5.3. Request-Response Message Exchange .........................12
5.4. Home Agent Controller Discovery ...........................13
5.5. Generic Request-Response Parameters .......................13
5.5.1. Mobile Node Identifier .............................13
5.5.2. Authentication Method ..............................13
5.5.3. Extensible Authentication Protocol Payload .........14
5.5.4. Status Code ........................................14
5.5.5. Message Authenticator ..............................14
5.5.6. Retry After ........................................14
5.5.7. End of Message Content .............................14
5.5.8. Random Values ......................................15
5.6. Security Association Configuration Parameters .............15
5.6.1. Security Parameter Index ...........................15
5.6.2. MN-HA Shared Keys ..................................16
5.6.3. Security Association Validity Time .................16
5.6.4. Security Association Scope (SAS) ...................16
5.6.5. Ciphersuites and Ciphersuite-to-Algorithm Mapping ..17
5.7. Mobile IPv6 Bootstrapping Parameters ......................18
5.7.1. Home Agent Address .................................18
5.7.2. Mobile IPv6 Service Port Number ....................18
5.7.3. Home Addresses and Home Network Prefix .............18
5.7.4. DNS Server .........................................19
5.8. Authentication of the Mobile Node .........................19
5.9. Extensible Authentication Protocol Methods ................22
6. Mobile Node to Home Agent Communication ........................23
6.1. General ...................................................23
6.2. PType and Security Parameter Index ........................25
6.3. Binding Management Message Formats ........................25
6.4. Reverse-Tunneled User Data Packet Formats .................27
7. Route Optimization .............................................29
8. IANA Considerations ............................................29
8.1. New Registry: Packet Type .................................29
8.2. Status Codes ..............................................29
8.3. Port Numbers ..............................................29
9. Security Considerations ........................................30
9.1. Discovery of the HAC ......................................30
9.2. Authentication and Key Exchange Executed between
the MN and the HAC ........................................30
9.3. Protection of MN and HA Communication .....................33
9.4. AAA Interworking ..........................................35
10. Acknowledgements ..............................................35
11. References ....................................................35
11.1. Normative References .....................................35
11.2. Informative References ...................................36
5.7.2. Mobile IPv6 Service Port Number ....................18
5.7.3. Home Addresses and Home Network Prefix .............18
5.7.4. DNS Server .........................................19
5.8. Authentication of the Mobile Node .........................19
5.9. Extensible Authentication Protocol Methods ................22
6. Mobile Node to Home Agent Communication ........................23
6.1. General ...................................................23
6.2. PType and Security Parameter Index ........................25
6.3. Binding Management Message Formats ........................25
6.4. Reverse-Tunneled User Data Packet Formats .................27
7. Route Optimization .............................................29
8. IANA Considerations ............................................29
8.1. New Registry: Packet Type .................................29
8.2. Status Codes ..............................................29
8.3. Port Numbers ..............................................29
9. Security Considerations ........................................30
9.1. Discovery of the HAC ......................................30
9.2. Authentication and Key Exchange Executed between
the MN and the HAC ........................................30
9.3. Protection of MN and HA Communication .....................33
9.4. AAA Interworking ..........................................35
10. Acknowledgements ..............................................35
11. References ....................................................35
11.1. Normative References .....................................35
11.2. Informative References ...................................36
Mobile IPv6 (MIPv6) [RFC6275] signaling, and optionally user traffic, between a Mobile Node (MN) and Home Agent (HA) are secured by IPsec [RFC4301]. The current Mobile IPv6 security architecture is specified in [RFC3776] and [RFC4877]. This security model requires a tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/ IPsec part of the IP stack. Client implementation experience has shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex.
移动节点（MN）和归属代理（HA）之间的移动IPv6（MIPv6）[RFC6275]信令和可选的用户流量由IPsec[RFC4301]保护。[RFC3776]和[RFC4877]中规定了当前的移动IPv6安全体系结构。此安全模型要求移动IPv6协议部分和IP堆栈的IKE（v2）/IPsec部分之间紧密耦合。客户机实施经验表明，将IKE（v2）/IPsec与移动IPv6结合使用相当复杂。
This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6. The objective is to simplify implementations as well as make it easy to deploy the protocol without compromising on security. Transport Layer Security (TLS) [RFC5246] is widely implemented in almost all major operating systems and extensively used by various applications. Instead of using IKEv2 to establish security associations, the security framework proposed in this document is based on TLS-protected messages to exchange keys and bootstrapping parameters between the MN and a new functional entity called the "Home Agent Controller" (HAC). The Mobile IPv6 signaling between the mobile node and home agent is subsequently
本文档提出了移动IPv6和双栈移动IPv6的替代安全框架。其目标是简化实现，并使部署协议变得容易，而不影响安全性。传输层安全性（TLS）[RFC5246]广泛应用于几乎所有主要的操作系统中，并被各种应用程序广泛使用。本文档中提出的安全框架不是使用IKEv2建立安全关联，而是基于TLS保护的消息，在MN和称为“归属代理控制器”（HAC）的新功能实体之间交换密钥和引导参数。随后在移动节点和归属代理之间发送移动IPv6信令
secured using the resulting keys and negotiated ciphersuite. The HAC can be co-located with the HA, or it can be an independent entity. For the latter case, communication between the HAC and HA is not defined by this document. Such communication could be built on top of AAA protocols such as Diameter.
使用生成的密钥和协商密码套件进行保护。医管局可与医管局合用同一地点，也可以是一个独立的机构。对于后一种情况，本文件未定义HAC和HA之间的通信。这种通信可以建立在诸如Diameter之类的AAA协议之上。
The primary advantage of using TLS for the establishment of Mobile IPv6 security associations as compared to the use of IKEv2 is the ease of implementation (especially on the mobile nodes) while providing an equivalent level of security. A solution which decouples Mobile IPv6 security from IPsec, for securing signaling messages and user plane traffic, is proposed herein that reduces client implementation complexity.
与使用IKEv2相比，使用TLS建立移动IPv6安全关联的主要优势是易于实施（尤其是在移动节点上），同时提供同等级别的安全性。本文提出了一种将移动IPv6安全性与IPsec分离的解决方案，用于保护信令消息和用户平面流量，从而降低客户端实现的复杂性。
The security framework proposed in this document is not intended to replace the currently specified architecture that relies on IPsec and IKEv2. It provides an alternative solution that is more optimal for certain deployment scenarios. This and other alternative security models have been considered by the MEXT working group at the IETF, and it has been decided that the alternative solutions should be published as Experimental RFCs, so that more implementation and deployment experience with these models can be gathered. The status of this proposal may be reconsidered in the future if it becomes clear that it is superior to others.
本文档中提出的安全框架无意取代当前指定的依赖IPsec和IKEv2的体系结构。它提供了一种替代解决方案，对于某些部署场景更为优化。IETF的MEXT工作组已经考虑了该和其他替代安全模型，并决定将替代解决方案作为实验性RFC发布，以便收集这些模型的更多实施和部署经验。如果这项提案明显优于其他提案，今后可能会重新审议这项提案的地位。
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]中所述进行解释。
Home Agent Controller (HAC):
主代理控制器（HAC）：
The home agent controller is a node responsible for bootstrapping Mobile IPv6 security associations between a mobile node and one or more home agents. The home agent controller also provides key distribution to both mobile nodes and home agents. Mobile IPv6 bootstrapping is also performed by the HA in addition to the security association bootstrapping between the mobile node and home agent controller.
归属代理控制器是负责在移动节点和一个或多个归属代理之间引导移动IPv6安全关联的节点。归属代理控制器还向移动节点和归属代理提供密钥分发。除了移动节点和归属代理控制器之间的安全关联引导之外，移动IPv6引导也由HA执行。
Binding Management Messages:
绑定管理消息：
Mobile IPv6 signaling messages between a mobile node and a home agent, correspondent node, or mobility access point to manage the bindings are referred to as binding management messages. Binding Updates (BUs) and Binding Acknowledgement (BA) messages are examples of binding management messages.
移动节点与归属代理、对应节点或移动接入点之间用于管理绑定的移动IPv6信令消息称为绑定管理消息。绑定更新（总线）和绑定确认（BA）消息是绑定管理消息的示例。
Mobile IPv6 design and specification began in the mid-to-late 90s. The security architecture of Mobile IPv6 was based on the understanding that IPsec is an inherent and integral part of the IPv6 stack and any protocol that needs security should use IPsec unless there is a good reason not to. As a result of this mindset, the Mobile IP6 protocol relied on the use of IPsec for security between the MN and HA. Reusing security components that are an integral part of the IP stack is a good design objective for any protocol; however, in the case of Mobile IPv6, it increases implementation complexity. It should be noted that Mobile IPv4 [RFC5944], for example, does not use IPsec for security and instead has specified its own security solution. Mobile IPv4 has been implemented and deployed on a reasonably large scale and the security model has proven itself to be sound.
移动IPv6的设计和规范始于90年代中后期。移动IPv6的安全体系结构基于这样一种理解，即IPsec是IPv6协议栈的固有组成部分，任何需要安全的协议都应该使用IPsec，除非有充分的理由不这样做。由于这种心态，移动IP6协议依赖于使用IPsec实现MN和HA之间的安全。重用作为IP协议栈组成部分的安全组件是任何协议的良好设计目标；然而，在移动IPv6的情况下，它增加了实现的复杂性。应该注意的是，例如，移动IPv4[RFC5944]不使用IPsec进行安全保护，而是指定了自己的安全解决方案。移动IPv4的实施和部署规模相当大，安全模型已经证明是可靠的。
Mobile IPv6 standardization was completed in 2005 along with the
security architecture using IKE/IPsec specified in RFC 3776
[RFC3776]. With the evolution to IKEv2 [RFC5996], Mobile IPv6
security has also been updated to rely on the use of IKEv2 [RFC4877].
Implementation exercises of Mobile IPv6 and Dual-Stack Mobile IPv6
[RFC5555] have identified the complexity of using IPsec and IKEv2 in
conjunction with Mobile IPv6. Implementing Mobile IPv6 with IPsec
and IKEv2 requires modifications to both the IPsec and IKEv2
components, due to the communication models that Mobile IPv6 uses and
the changing IP addresses. For further details, see Section 7.1 in
[RFC3776].
Mobile IPv6 standardization was completed in 2005 along with the
security architecture using IKE/IPsec specified in RFC 3776
[RFC3776]. With the evolution to IKEv2 [RFC5996], Mobile IPv6
security has also been updated to rely on the use of IKEv2 [RFC4877].
Implementation exercises of Mobile IPv6 and Dual-Stack Mobile IPv6
[RFC5555] have identified the complexity of using IPsec and IKEv2 in
conjunction with Mobile IPv6. Implementing Mobile IPv6 with IPsec
and IKEv2 requires modifications to both the IPsec and IKEv2
components, due to the communication models that Mobile IPv6 uses and
the changing IP addresses. For further details, see Section 7.1 in
[RFC3776].
This document proposes a security framework based on TLS-protected establishment of Mobile IPv6 security associations, which reduces implementation complexity while maintaining an equivalent (to IKEv2/ IPsec) level of security.
本文档提出了一个基于TLS保护的移动IPv6安全关联建立的安全框架，该框架在保持同等（IKEv2/IPsec）安全级别的同时降低了实现复杂性。
The security architecture proposed in this document relies on a secure TLS session established between the MN and the HAC for mutual authentication and MN-HA security association bootstrapping. Authentication of the HAC is done via standard TLS operation wherein the HAC uses a TLS server certificate as its credentials. MN authentication is done by the HAC via signaling messages that are secured by the TLS connection. Any Extensible Authentication Protocol (EAP) method or Pre-Shared Key (PSK) can be used for authenticating the MN to the HAC. Upon successful completion of authentication, the HAC generates keys that are delivered to the MN
本文档中提出的安全体系结构依赖于在MN和HAC之间建立的安全TLS会话，用于相互认证和MN-HA安全关联引导。HAC的认证通过标准TLS操作完成，其中HAC使用TLS服务器证书作为其凭证。MN身份验证由HAC通过TLS连接保护的信令消息完成。任何可扩展认证协议（EAP）方法或预共享密钥（PSK）都可用于向HAC认证MN。成功完成身份验证后，HAC生成密钥，并将其交付给MN
through the secure TLS channel. The same keys are also provided to the assigned HA. The HAC also provides the MN with MIPv6 bootstrapping information such as the IPv6 and IPv4 address of the HA, the home network prefix, the IPv6 and/or IPv4 Home Address (HoA), and DNS server address.
通过安全TLS通道。同样的密钥也提供给分配的HA。HAC还向MN提供MIPv6引导信息，如HA的IPv6和IPv4地址、家庭网络前缀、IPv6和/或IPv4家庭地址（HoA）以及DNS服务器地址。
The MN and HA use security associations based on the keys and Security Parameter Indexes (SPIs) generated by the HAC and delivered to the MN and HA to secure signaling and optionally user plane traffic. Figure 1 below is an illustration of the process.
MN和HA使用基于由HAC生成并交付给MN和HA的密钥和安全参数索引（SPI）的安全关联来保护信令和可选的用户平面流量。下面的图1是该过程的说明。
Signaling messages and user plane traffic between the MN and HA are always UDP encapsulated. The packet formats for the signaling and user plane traffic is described in Sections 6.3 and 6.4.
MN和HA之间的信令消息和用户平面流量始终是UDP封装的。第6.3节和第6.4节描述了信令和用户平面业务的数据包格式。
MN HAC HA
-- --- --
| | |
| /-------------------------\ | |
|/ \| |
|\ TLS session setup /| |
| \-------------------------/ | |
| | |
| /-------------------------\ | |
|/ MN Authentication \| |
|\ /| |
| \-------------------------/ | |
| | |
| /-------------------------\ | |
|/ HAC provisions the MN \| |
|\ keys, SPI, & MIPv6 parms /| |
| \-------------------------/ | |
| |--MNID, keys, SPI->|
| | |
| /--------------------------------------------\ |
|/ MN-HA SA established; Secures \ |
|\ signaling and optionally user traffic / |
| \--------------------------------------------/ |
| |
|------------BU(encrypted)----------------------->|
| |
|<---------BAck(encrypted)------------------------|
MN HAC HA
-- --- --
| | |
| /-------------------------\ | |
|/ \| |
|\ TLS session setup /| |
| \-------------------------/ | |
| | |
| /-------------------------\ | |
|/ MN Authentication \| |
|\ /| |
| \-------------------------/ | |
| | |
| /-------------------------\ | |
|/ HAC provisions the MN \| |
|\ keys, SPI, & MIPv6 parms /| |
| \-------------------------/ | |
| |--MNID, keys, SPI->|
| | |
| /--------------------------------------------\ |
|/ MN-HA SA established; Secures \ |
|\ signaling and optionally user traffic / |
| \--------------------------------------------/ |
| |
|------------BU(encrypted)----------------------->|
| |
|<---------BAck(encrypted)------------------------|
Figure 1: High-Level Architecture
图1：高层架构
The TLS-based security architecture is shown in Figure 2. The signaling message exchange between the MN and the HAC is protected by TLS. It should be noted that an HAC, a AAA server, and an HA are logically separate entities and can be collocated in all possible combinations. There MUST be a strong trust relationship between the HA and the HAC, and the communication between them MUST be both integrity and confidentially protected.
基于TLS的安全体系结构如图2所示。MN和HAC之间的信令消息交换受TLS保护。应该注意的是，HAC、AAA服务器和HA在逻辑上是独立的实体，可以在所有可能的组合中并置。医管局和医管局之间必须有紧密的信任关系，双方的沟通必须保持诚信和保密。
+------+ +------+ +------+
|Mobile| TLS |Home | AAA | AAA |
| Node |<----------->|Agent |<---------->|Server|
| | |Contrl| | |
+------+ +------+ +------+
^ ^ ^
| | |
| BU/BA/../ | e.g., AAA | AAA
| (Data) | |
| v |
| +---------+ |
| | MIPv6 | |
+--------------->| Home |<-------------+
| Agent(s)|
+---------+
+------+ +------+ +------+
|Mobile| TLS |Home | AAA | AAA |
| Node |<----------->|Agent |<---------->|Server|
| | |Contrl| | |
+------+ +------+ +------+
^ ^ ^
| | |
| BU/BA/../ | e.g., AAA | AAA
| (Data) | |
| v |
| +---------+ |
| | MIPv6 | |
+--------------->| Home |<-------------+
| Agent(s)|
+---------+
Figure 2: TLS-Based Security Architecture Overview
图2：基于TLS的安全体系结构概述
Once the MN has contacted the HAC and mutual authentication has taken place between the MN and the HAC, the HAC securely provisions the MN with all security-related information inside the TLS protected tunnel. This security-related information constitutes a security association (SA) between the MN and the HA. The created SA MUST NOT be tied to the Care-of Address (CoA) of the MN.
一旦MN联系了HAC，并且MN和HAC之间进行了相互认证，HAC将安全地向MN提供TLS保护隧道内的所有安全相关信息。该安全相关信息构成MN和HA之间的安全关联（SA）。创建的SA不得与MN的转交地址（CoA）绑定。
The HAC may proactively distribute the SA information to HAs, or the HA may query the SA information from the HAC once the MN contacts the HA. If the HA requests SA information from the HAC, then the HA MUST be able to query/index the SA information from the HAC based on the SPI identifying the correct security association between the MN and the HA.
HAC可以主动将SA信息分发给HAs，或者一旦MN联系HA，HA可以从HAC查询SA信息。如果HA向HAC请求SA信息，则HA必须能够根据识别MN和HA之间正确安全关联的SPI从HAC查询/索引SA信息。
The HA may want the MN to re-establish the SA even if the existing SA is still valid. The HA can indicate this to the MN using a dedicated Status Code in a BA (value set to REINIT_SA_WITH_HAC). As a result, the MN SHOULD contact the HAC prior to the SA timing out, and the HAC would provision the MN and HAs with a new SA to be used subsequently.
即使现有SA仍然有效，医管局也可能希望MN重新建立SA。HA可以使用BA中的专用状态代码（值设置为REINIT_SA_WITH_HAC）向MN指示这一点。因此，MN应在SA超时之前联系HAC，HAC将为MN和HAs提供一个新SA，以供后续使用。
The SA established between MN and HAC SHALL contain at least the following information:
MN和HAC之间建立的SA应至少包含以下信息：
Mobility SPI:
流动性SPI：
This parameter is an SPI used by the MN and the HA to index the SA between the MN and the HA. The HAC is responsible for assigning SPIs to MNs. There is only one SPI for both binding management messaging and possible user data protection. The same SPI is used for both directions between the MN and the HA. The SPI values are assigned by the HAC. The HAC MUST ensure uniqueness of the SPI values across all MNs controlled by the HAC.
此参数是MN和HA用于索引MN和HA之间SA的SPI。HAC负责将SPI分配给MNs。绑定管理消息和可能的用户数据保护只有一个SPI。相同的SPI用于MN和HA之间的两个方向。SPI值由HAC分配。HAC必须确保由HAC控制的所有MN中SPI值的唯一性。
MN-HA keys for ciphering:
用于加密的MN-HA密钥：
A pair of symmetric keys (MN -> HA, HA -> MN) used for ciphering Mobile IPv6 traffic between the MN and the HA. The HAC is responsible for generating these keys. The key generation algorithm is specific to the HAC implementation.
一对对称密钥（MN->HA，HA->MN），用于加密MN和HA之间的移动IPv6流量。HAC负责生成这些密钥。密钥生成算法特定于HAC实现。
MN-HA shared key for integrity protection:
用于完整性保护的MN-HA共享密钥：
A pair of symmetric keys (MN -> HA, HA -> MN) used for integrity protecting Mobile IPv6 traffic between the MN and the HA. This includes both binding management messages and reverse-tunneled user data traffic between the MN and the HA. The HAC is responsible for generating these keys. The key generation algorithm is specific to the HAC implementation. In the case of combined algorithms, a separate integrity protection key is not needed and may be omitted, i.e., the encryption keys SHALL be used.
一对对称密钥（MN->HA，HA->MN），用于保护MN和HA之间的移动IPv6流量的完整性。这包括MN和HA之间的绑定管理消息和反向隧道用户数据通信。HAC负责生成这些密钥。密钥生成算法特定于HAC实现。在组合算法的情况下，不需要单独的完整性保护密钥，可以省略，即应使用加密密钥。
Security association validity time:
安全关联有效时间：
This parameter represents the validity time for the security association. The HAC is responsible for defining the lifetime value based on its policies. The lifetime may be in the order of hours or weeks. The MN MUST re-contact the HAC before the SA validity time ends.
此参数表示安全关联的有效时间。HAC负责根据其政策定义生命周期价值。生命周期可以是几个小时或几个星期。MN必须在SA有效期结束前重新联系HAC。
Security association scope:
安全关联范围：
This parameter defines whether the security association is applied to Mobile IPv6 signaling messages only or to both Mobile IPv6 signaling messages and data traffic.
此参数定义安全关联是仅应用于移动IPv6信令消息，还是同时应用于移动IPv6信令消息和数据流量。
Selected ciphersuite:
所选密码套件：
This parameter is the ciphersuite used to protect the traffic between the MN and the HA. This includes both binding management messages and reverse-tunneled user data traffic between the MN and the HA. The selected algorithms SHOULD be one of the mutually supported ciphersuites of the negotiated TLS version between the MN and the HAC. The HAC is responsible for choosing the mutually supported ciphersuite that complies with the policy of the HAC. Obviously, the HAs under HAC's management must have at least one ciphersuite with the HAC in common and need to be aware of the implemented ciphersuites. The selected ciphersuite is the same for both directions (MN -> HA and HA -> MN).
此参数是用于保护MN和HA之间流量的密码套件。这包括MN和HA之间的绑定管理消息和反向隧道用户数据通信。所选算法应该是MN和HAC之间协商的TLS版本的相互支持的密码套件之一。HAC负责选择符合HAC政策的相互支持的密码套件。显然，HAC管理的HAs必须至少有一个与HAC相同的密码套件，并且需要了解已实施的密码套件。所选密码套件在两个方向（MN->HA和HA->MN）都是相同的。
Sequence numbers:
序列号：
A monotonically increasing unsigned sequence number used in all protected packets exchanged between the MN and the HA in the same direction. Sequence numbers are maintained per direction, so each SA includes two independent sequence numbers (MN -> HA, HA -> MN). The initial sequence number for each direction MUST always be set to 0 (zero). Sequence numbers cycle to 0 (zero) when increasing beyond their maximum defined value.
一种单调递增的无符号序列号，用于MN和HA在同一方向上交换的所有受保护数据包中。序列号按方向维护，因此每个SA包括两个独立的序列号（MN->HA，HA->MN）。每个方向的初始序列号必须始终设置为0（零）。当增加超过其最大定义值时，序列号循环为0（零）。
When the MN contacts the HAC to distribute the security-related information, the HAC may also provision the MN with various MIPv6- related bootstrapping information. Bootstrapping of the following information SHOULD at least be possible:
当MN联系HAC以分发安全相关信息时，HAC还可以向MN提供各种与MIPv6相关的引导信息。至少可以引导以下信息：
Home Agent IP Address:
归属代理IP地址：
The IPv6 and IPv4 address of the home agent assigned by the HAC.
HAC分配的归属代理的IPv6和IPv4地址。
Mobile IPv6 Service Port Number:
移动IPv6服务端口号：
The port number where the HA is listening to UDP [RFC0768] packets.
HA侦听UDP[RFC0768]数据包的端口号。
Home Address:
家庭住址：
The IPv6 and/or IPv4 home address assigned to the mobile node by the HAC.
HAC分配给移动节点的IPv6和/或IPv4主地址。
Home Link Prefix:
主链接前缀：
Concerns the IPv6 Home link prefix and the associated prefix length.
涉及IPv6主链路前缀和相关前缀长度。
DNS Server Address:
DNS服务器地址：
The address of a DNS server that can be reached via the HA. DNS queries in certain cases cannot be routed to the DNS servers assigned by the access network to which the MN is attached; hence, an additional DNS server address that is reachable via the HA needs to be configured.
可通过HA访问的DNS服务器的地址。在某些情况下，DNS查询不能路由到MN所连接的接入网络分配的DNS服务器；因此，需要配置可通过HA访问的附加DNS服务器地址。
The MIPv6-related bootstrapping information is delivered from the HAC to the MN over the same TLS protected tunnel as the security related information.
与MIPv6相关的引导信息通过与安全相关信息相同的TLS保护隧道从HAC传送到MN。
The same integrity and confidentiality algorithms MUST be used to protect both binding management messages and reverse-tunneled user data traffic between the MN and the HA. Generally, all binding management messages (BUs, BAs, and so on) MUST be integrity protected and SHOULD be confidentially protected. The reverse-tunneled user data traffic SHOULD be equivalently protected. Generally, the requirements stated in [RFC6275] concerning the protection of the traffic between the MN and the HA also apply to the mechanisms defined by this specification.
必须使用相同的完整性和机密性算法来保护MN和HA之间的绑定管理消息和反向隧道用户数据通信。通常，所有绑定管理消息（总线、BAs等）都必须受到完整性保护，并且应该受到保密保护。反向隧道用户数据通信应受到同等保护。一般而言，[RFC6275]中规定的有关MN和HA之间流量保护的要求也适用于本规范定义的机制。
The MN and the HAC communicate with each other using a simple lockstep request-response protocol that is run inside the protected TLS-tunnel. A generic message container framing for the request messages and for the response messages is defined. The message containers are only meant to be exchanged on top of a connection-oriented TLS-layer. Therefore, the end of message exchange is determined by the other end closing the transport connection (assuming the "application layer" has also indicated the completion of the message exchange). The peer initiating the TLS connection is
MN和HAC使用在受保护的TLS隧道内运行的简单锁定步骤请求-响应协议相互通信。定义了请求消息和响应消息的通用消息容器框架。消息容器只能在面向连接的TLS层上进行交换。因此，消息交换的结束由关闭传输连接的另一端确定（假设“应用层”也指示消息交换的完成）。启动TLS连接的对等方是
always sending "Requests", and the peer accepting the TLS connection is always sending "Responses". The format of the message container is shown in Figure 3.
始终发送“请求”，接受TLS连接的对等方始终发送“响应”。消息容器的格式如图3所示。
All data inside the Content portion of the message container MUST be encoded using octets. Fragmentation of message containers is not supported, which means one request or response at the "application layer" MUST NOT exceed the maximum size allowed by the message container format.
消息容器内容部分内的所有数据必须使用八位字节进行编码。不支持消息容器的分段，这意味着“应用程序层”上的一个请求或响应不得超过消息容器格式允许的最大大小。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rsrvd | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Content portion.. ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rsrvd | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Content portion.. ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Request-Response Message Container
图3：请求-响应消息容器
The 3-bit Ver field identifies the protocol version. The current version is 0, i.e., all bits are set to a value of 0 (zero).
3位版本字段标识协议版本。当前版本为0，即所有位均设置为0（零）。
The Rsrvd field MUST be set to a value of 0 (zero),
Rsrvd字段必须设置为0（零）的值，
The Identifier field is meant to match requests and responses. The valid Identifier values are between 1-255. The value 0 MUST NOT be used. The first request for each communication session between the MN and the HAC MUST have the Identifier values set to 1.
标识符字段用于匹配请求和响应。有效标识符值介于1-255之间。不得使用值0。MN和HAC之间的每个通信会话的第一个请求必须将标识符值设置为1。
The Length field tells the length of the Content portion of the container (i.e., Reserved octet, Identifier octet, and Length field are excluded). The Content portion length MUST always be at least one octet and up to 65535 octets. The value is in network order.
长度字段表示容器内容部分的长度（即，不包括保留八位字节、标识符八位字节和长度字段）。内容部分长度必须始终至少为一个八位字节，最多为65535个八位字节。该值按网络顺序排列。
The encoding of the message content is similar to HTTP header encoding and complies with the augmented Backus-Naur Form (BNF) defined in Section 2.1 of [RFC2616]. All presented hexadecimal numbers are in network byte order. From now on, we use the TypeValue header (TV-header) term to refer to request-response message content HTTP-like headers.
消息内容的编码类似于HTTP报头编码，并符合[RFC2616]第2.1节中定义的扩展巴科斯诺尔格式（BNF）。所有显示的十六进制数字均按网络字节顺序排列。从现在起，我们使用TypeValue标头（TV标头）术语来指代请求-响应消息内容HTTP类标头。
The message exchange between the MN and the HAC is a simple lockstep request-response type as stated in Section 5.1. A request message includes a monotonically increasing Identifier value that is copied to the corresponding response message. Each request MUST have a different Identifier value. Hence, a reliable connection-oriented transport below the message container framing is assumed. The number of request-response message exchanges MUST NOT exceed 255.
MN和HAC之间的消息交换是一种简单的锁步请求-响应类型，如第5.1节所述。请求消息包括复制到相应响应消息的单调递增的标识符值。每个请求必须具有不同的标识符值。因此，假定在消息容器框架下有可靠的面向连接的传输。请求-响应消息交换的数量不得超过255。
Each new communication session between the MN and the HAC MUST reset the Identifier value to 1. The MN is also the peer that always sends only request messages and the HAC only sends response messages. Once the request-response message exchange completes, the HAC and the MN MUST close the transport connection and the corresponding TLS-tunnel.
MN和HAC之间的每个新通信会话必须将标识符值重置为1。MN也是始终仅发送请求消息而HAC仅发送响应消息的对等方。请求-响应消息交换完成后，HAC和MN必须关闭传输连接和相应的TLS隧道。
In the case of an HAC-side error, the HAC MUST send a response back to an MN with an appropriate status code and then close the transport connection.
在发生HAC端错误的情况下，HAC必须向MN发送带有适当状态代码的响应，然后关闭传输连接。
The first request message - MHAuth-Init - (i.e., the Identifier is 1) MUST always contain at least the following parameters:
第一条请求消息-MHAuth Init-（即标识符为1）必须始终至少包含以下参数：
MN-Identity - See Section 5.5.1.
MN标识-见第5.5.1节。
Authentication Method - See Section 5.5.2.
认证方法-见第5.5.2节。
The first response message - MHAuth-Init - (i.e., the Identifier is 1) MUST contain at minimum the following parameters:
第一条响应消息-MHAuth Init-（即标识符为1）必须至少包含以下参数：
Selected authentication Method - See Section 5.5.2.
选择的认证方法-见第5.5.2节。
The last request message from the MN side - MHAuth-Done - MUST contain the following parameters:
来自MN端的最后一条请求消息-MHAuth Done-必须包含以下参数：
Security association scope - See Section 5.6.4.
安全关联范围-见第5.6.4节。
Proposed ciphersuites - See Section 5.6.5.
建议的密码套件-见第5.6.5节。
Message Authenticator - See Section 5.5.5.
消息验证器-见第5.5.5节。
The last response message - MHAuth-Done - that ends the request-response message exchange MUST contain the following parameters:
结束请求-响应消息交换的最后一条响应消息（MHAuth Done）必须包含以下参数：
Status Code - See Section 5.5.4.
状态代码-见第5.5.4节。
Message Authenticator - See Section 5.5.5.
消息验证器-见第5.5.5节。
In the case of successful authentication, the following additional parameters:
如果身份验证成功，请使用以下附加参数：
Selected ciphersuite - See Section 5.6.5.
所选密码套件-见第5.6.5节。
Security association scope - See Section 5.6.4.
安全关联范围-见第5.6.4节。
The rest of the security association data - See Section 5.6.
其余安全关联数据-见第5.6节。
All bootstrapping information, whether for setting up the SA or for bootstrapping MIPv6-specific information, is exchanged between the MN and the HAC using the framing protocol defined in Section 5.1. The IP address of the HAC MAY be statically configured in the MN or alternatively MAY be dynamically discovered using DNS. In the case of DNS-based HAC discovery, the MN queries either an A/AAAA or a SRV record for the HAC IP address. The actual domain name used in queries is up to the deployment to decide and out of scope of this specification.
所有引导信息，无论是用于设置SA还是用于引导MIPv6特定信息，都使用第5.1节中定义的帧协议在MN和HAC之间交换。可以在MN中静态地配置HAC的IP地址，或者可以使用DNS动态地发现HAC的IP地址。在基于DNS的HAC发现的情况下，MN查询HAC IP地址的A/AAAA或SRV记录。查询中使用的实际域名由部署决定，不在本规范的范围内。
The grammar used in the following sections is the augmented Backus-Naur Form (BNF), the same as that used by HTTP [RFC2616].
下面几节中使用的语法是扩充的巴科斯-诺尔形式（BNF），与HTTP[RFC2616]使用的语法相同。
An identifier that identifies an MN. The Mobile Node Identifier is in the form of a Network Access Identifier (NAI) [RFC4282].
标识MN的标识符。移动节点标识符采用网络接入标识符（NAI）[RFC4282]的形式。
mn-id = "mn-id" ":" RFC4282-NAI CRLF
mn id=“mn id”“：“RFC4282-NAI CRLF
The HAC is the peer that mandates the authentication method. The MN sends its authentication method proposal to the HAC. The HAC, upon receipt of the MN proposal, returns the selected authentication method. The MN MUST propose at least one authentication method. The HAC MUST select exactly one authentication method or return an error and then close the connection.
HAC是授权验证方法的对等方。MN向HAC发送其认证方法建议。HAC在收到MN建议后，返回所选的身份验证方法。MN必须提出至少一种认证方法。HAC必须只选择一种身份验证方法或返回错误，然后关闭连接。
auth-method = "auth-method" ":" a-method *("," a-method) CRLF
a-method =
"psk" ; PSK-based authentication
| "eap" ; EAP-based authentication
auth-method = "auth-method" ":" a-method *("," a-method) CRLF
a-method =
"psk" ; PSK-based authentication
| "eap" ; EAP-based authentication
Each Extensible Authentication Protocol (EAP) [RFC3748] message is an encoded string of hexadecimal numbers. The "eap-payload" is completely transparent as to which EAP-method or EAP message is carried inside it. The "eap-payload" can appear in both request and response messages:
每个可扩展身份验证协议（EAP）[RFC3748]消息都是十六进制数的编码字符串。“eap有效载荷”对于在其内部携带的eap方法或eap消息是完全透明的。“eap有效负载”可以出现在请求和响应消息中：
eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF
eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF
The "status-code" MUST only be present in the response message that ends the request-response message exchange. The "status-code" follows the principles of HTTP and the definitions found in Section 10 of RFC 2616 also apply for these status codes listed below:
“状态代码”只能出现在结束请求-响应消息交换的响应消息中。“状态代码”遵循HTTP的原则，RFC 2616第10节中的定义也适用于下列状态代码：
status-code = "status-code" ":" status-value CRLF
status-value =
"100" ; Continue
| "200" ; OK
| "400" ; Bad Request
| "401" ; Unauthorized
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
status-code = "status-code" ":" status-value CRLF
status-value =
"100" ; Continue
| "200" ; OK
| "400" ; Bad Request
| "401" ; Unauthorized
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
The "auth" header contains data used for authentication purposes. It MUST be the last TV-header in the message and calculated over the whole message till the start of the "msg-header":
“auth”标头包含用于身份验证目的的数据。它必须是消息中的最后一个TV标头，并在整个消息上计算，直到“msg标头”开始：
msg-auth = "auth" ":" 1*(HEX HEX) CRLF
msg-auth = "auth" ":" 1*(HEX HEX) CRLF
retry-after = "retry-after" ":" rfc1123-date CRLF
retry after=“retry after”“：”rfc1123日期CRLF
end-of-message = 2CRLF
end-of-message = 2CRLF
Random numbers generated by the MN and the HAC, respectively. The length of the random number MUST be 32 octets (before TV-header encoding):
分别由MN和HAC生成的随机数。随机数的长度必须为32个八位字节（在电视报头编码之前）：
mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF
hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF
mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF
hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF
During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate a single ciphersuite for protecting the traffic between the MN and the HA. The allowed ciphersuites for this specification are a subset of those in TLS version 1.2 (see Appendix A.5 of [RFC5246]) per Section 5.6.5. This might appear as a constraint as the HA and the HAC may have implemented different ciphersuites. These two nodes are, however, assumed to belong to the same administrative domain. In order to avoid exchanging supported MN-HA ciphersuites in the MN-HAC protocol and to reuse the TLS ciphersuite negotiation procedure, we make this simplifying assumption. The selected ciphersuite MUST provide integrity and confidentiality protection.
在移动IPv6引导期间，MN和HAC协商单个密码套件，以保护MN和HA之间的流量。根据第5.6.5节，本规范允许的密码套件是TLS版本1.2（见[RFC5246]附录a.5）中密码套件的子集。这可能是一个约束，因为HA和HAC可能实现了不同的密码套件。但是，假设这两个节点属于同一管理域。为了避免交换MN-HAC协议中受支持的MN-HA密码套件，并重用TLS密码套件协商过程，我们做出了这一简化假设。所选密码套件必须提供完整性和机密性保护。
Section 5.6.5 provides the mapping from the TLS ciphersuites to the integrity and encryption algorithms allowed for MN-HA protection. This mapping mainly ignores the authentication algorithm part that is not required within the context of this specification. For example, [RFC5246] defines a number of AES-based ciphersuites for TLS including 'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification, the relevant part is 'AES_128_CBC_SHA'.
第5.6.5节提供了从TLS密码套件到MN-HA保护所允许的完整性和加密算法的映射。此映射主要忽略本规范上下文中不需要的身份验证算法部分。例如，[RFC5246]为TLS定义了许多基于AES的密码套件，包括“TLS_RSA_WITH_AES_128_CBC_SHA”。对于本规范，相关部分为“AES_128_CBC_SHA”。
All the parameters described in the following sections apply only to a request-response protocol response message to the MN. The MN has no way of affecting the provisioning decision of the HAC.
以下各节中描述的所有参数仅适用于MN的请求-响应协议-响应消息。MN无法影响HAC的供应决策。
The 28-bit unsigned SPI number identifies the SA used between the MN and the HA. The value 0 (zero) is reserved and MUST NOT be used. Therefore, values ranging from 1 to 268435455 are valid.
28位无符号SPI编号标识MN和HA之间使用的SA。值0（零）为保留值，不得使用。因此，从1到268435455的值是有效的。
The TV-header corresponding to the SPI number is as follows:
与SPI编号对应的TV标头如下所示：
mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF
mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF
The MN-HA shared integrity (ikey) and encryption (ekey) keys are used to protect the traffic between the MN and the HA. The length of these keys depend on the selected ciphersuite.
MN-HA共享完整性（ikey）和加密（ekey）密钥用于保护MN和HA之间的通信量。这些密钥的长度取决于所选密码套件。
The TV-headers that carry these two parameters are the following:
携带这两个参数的电视标题如下所示：
mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF
mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF
mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF
mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF
mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF
mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF
mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF
mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF
The end of the SA validity time is encoded using the "rfc1123-date" format, as defined in Section 3.3.1 of [RFC2616].
SA有效期结束时使用[RFC2616]第3.3.1节中定义的“rfc1123日期”格式进行编码。
The TV-header corresponding to the SA validity time value is as follows:
SA有效时间值对应的TV报头如下：
mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date CRLF
mip6 sa validity end=“mip6 sa validity end”“：”rfc1123日期CRLF
The SA is applied either to Mobile IPv6 signaling messages only or to both Mobile IPv6 signaling messages and data traffic. This policy MUST be agreed between the MN and HA prior to using the SA. Otherwise, the receiving side will be unaware of whether the SA applies to data traffic and hence unable to decide how to act when receiving unprotected packets of PType 1 (see Section 6.4).
SA仅应用于移动IPv6信令消息，或同时应用于移动IPv6信令消息和数据流量。在使用SA之前，MN和HA必须就该政策达成一致。否则，接收方将不知道SA是否适用于数据通信，因此无法决定在接收未受保护的PType 1数据包时如何操作（参见第6.4节）。
mip6-sas = "mip6-sas" ":" 1DIGIT CRLF
mip6 sas=“mip6 sas”“：“1数字CRLF
where a value of "O" indicates that the SA does not protect data traffic and a value of "1" indicates that all data traffic MUST be protected by the SA. If the mip6-sas value of an SA is set to 1, any packet received with a PType value that does not match the mip6-sas value of the SA MUST be silently discarded.
其中，值“O”表示SA不保护数据通信量，“1”表示SA必须保护所有数据通信量。如果SA的mip6 sas值设置为1，则接收到的PType值与SA的mip6 sas值不匹配的任何数据包都必须以静默方式丢弃。
The HAC is the peer that mandates the used security association scope. The MN sends its proposal to the HAC, but eventually the security association scope returned from the HAC defines the used scope.
HAC是授权使用的安全关联范围的对等方。MN将其建议发送给HAC，但最终从HAC返回的安全关联范围定义了使用的范围。
The ciphersuite negotiation between HAC and MN uses a subset of the TLS 1.2 ciphersuites and follows the TLS 1.2 numeric representation defined in Appendix A.5 of [RFC5246]. The TV-headers corresponding to the selected ciphersuite and ciphersuite list are the following:
HAC和MN之间的密码套件协商使用TLS 1.2密码套件的子集，并遵循[RFC5246]附录a.5中定义的TLS 1.2数字表示法。与所选ciphersuite和ciphersuite列表相对应的TV标头如下所示：
mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF
csuite = "{" suite "}"
suite =
"00" "," "02" ; CipherSuite NULL_SHA = {0x00,0x02}
| "00" "," "3B" ; CipherSuite NULL_SHA256 = {0x00,0x3B}
| "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA = {0x00,0x0A}
| "00" "," "2F" ; CipherSuite AES_128_CBC_SHA = {0x00,0x2F}
| "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C}
mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF
csuite = "{" suite "}"
suite =
"00" "," "02" ; CipherSuite NULL_SHA = {0x00,0x02}
| "00" "," "3B" ; CipherSuite NULL_SHA256 = {0x00,0x3B}
| "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA = {0x00,0x0A}
| "00" "," "2F" ; CipherSuite AES_128_CBC_SHA = {0x00,0x2F}
| "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C}
mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF
mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF
All other Ciphersuite values are reserved.
保留所有其他Ciphersuite值。
The following integrity algorithms MUST be supported by all implementations:
所有实现都必须支持以下完整性算法：
HMAC-SHA1-96 [RFC2404] AES-XCBC-MAC-96 [RFC3566]
HMAC-SHA1-96[RFC2404]AES-XCBC-MAC-96[RFC3566]
The binding management messages between the MN and HA MUST be integrity protected. Implementations MUST NOT use a NULL integrity algorithm.
MN和HA之间的绑定管理消息必须受到完整性保护。实现不能使用空完整性算法。
The following encryption algorithms MUST be supported:
必须支持以下加密算法：
NULL [RFC2410]
TripleDES-CBC [RFC2451]
AES-CBC with 128-bit keys [RFC3602]
NULL [RFC2410]
TripleDES-CBC [RFC2451]
AES-CBC with 128-bit keys [RFC3602]
Traffic between MN and HA MAY be encrypted. Any integrity-only Ciphersuite makes use of the NULL encryption algorithm.
MN和HA之间的流量可以加密。任何仅完整性密码套件都使用空加密算法。
Note: This document does not consider combined algorithms. The following table provides the mapping of each ciphersuite to a combination of integrity and encryption algorithms that are part of the negotiated SA between MN and HA.
注：本文档不考虑组合算法。下表提供了每个密码套件到完整性和加密算法组合的映射，这些算法是MN和HA之间协商SA的一部分。
+-------------------+-----------------+--------------------------+
|Ciphersuite |Integ. Algorithm |Encr. Algorithm |
+-------------------+-----------------+--------------------------+
|NULL_SHA |HMAC-SHA1-96 |NULL |
|NULL_SHA256 |AES-XCBC-MAC-96 |NULL |
|3DES_EDE_CBC_SHA |HMAC-SHA1-96 |TripleDES-CBC |
|AES_128_CBC_SHA |HMAC-SHA1-96 |AES-CBC with 128-bit keys |
|AES_128_CBC_SHA256 |AES-XCBC-MAC-96 |AES-CBC with 128-bit keys |
+-------------------+----------------+---------------------------+
+-------------------+-----------------+--------------------------+
|Ciphersuite |Integ. Algorithm |Encr. Algorithm |
+-------------------+-----------------+--------------------------+
|NULL_SHA |HMAC-SHA1-96 |NULL |
|NULL_SHA256 |AES-XCBC-MAC-96 |NULL |
|3DES_EDE_CBC_SHA |HMAC-SHA1-96 |TripleDES-CBC |
|AES_128_CBC_SHA |HMAC-SHA1-96 |AES-CBC with 128-bit keys |
|AES_128_CBC_SHA256 |AES-XCBC-MAC-96 |AES-CBC with 128-bit keys |
+-------------------+----------------+---------------------------+
Ciphersuite-to-Algorithm Mapping
算法映射的密码套件
In parallel with the SA bootstrapping, the HAC SHOULD provision the MN with relevant MIPv6-related bootstrapping information.
在SA引导的同时，HAC应向MN提供相关的MIPv6引导信息。
The following generic BNFs are used to form IP addresses and prefixes. They are used in subsequent sections.
以下通用BNF用于形成IP地址和前缀。它们将在后续章节中使用。
ip6-addr = 7( word ":" ) word CRLF
word = 1*4HEX
ip6-prefix = ip6-addr "/" 1*2DIGIT
ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
ip4-subnet = ip4-addr "/" 1*2DIGIT
ip6-addr = 7( word ":" ) word CRLF
word = 1*4HEX
ip6-prefix = ip6-addr "/" 1*2DIGIT
ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
ip4-subnet = ip4-addr "/" 1*2DIGIT
The HAC MAY provision the MN with an IPv4 or an IPv6 address of an HA, or both.
HAC可向MN提供HA的IPv4或IPv6地址，或两者兼备。
mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF
mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF
mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF
mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF
The HAC SHOULD provision the MN with an UDP port number, where the HA expects to receive UDP packets. If this parameter is not present, then the IANA reserved port number (mipv6tls) MUST be used instead.
HAC应该为MN提供UDP端口号，HA希望在该端口号接收UDP数据包。如果此参数不存在，则必须使用IANA保留端口号（mipv6tls）。
mip6-port = "mip6-port" ":" 1*5DIGIT CRLF
mip6-port = "mip6-port" ":" 1*5DIGIT CRLF
The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or both. The HAC MAY also provision the MN with its home network prefix.
The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or both. The HAC MAY also provision the MN with its home network prefix.translate error, please retry
mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF
mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF
mip6-ip6-hnp = "mip6-ip6-hnp" ":" ip6-prefix CRLF
mip6-ip4-hnp = "mip6-ip4-hnp" ":" ip4-subnet CRLF
mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF
mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF
mip6-ip6-hnp = "mip6-ip6-hnp" ":" ip6-prefix CRLF
mip6-ip4-hnp = "mip6-ip4-hnp" ":" ip4-subnet CRLF
The HAC may also provide the MN with DNS server configuration options. These DNS servers are reachable via the home agent.
HAC还可以为MN提供DNS服务器配置选项。可以通过归属代理访问这些DNS服务器。
dns-ip6 = "dns-ip6" ":" ip6-addr CRLF
dns-ip4 = "dns-ip4" ":" ip4-addr CRLF
dns-ip6 = "dns-ip6" ":" ip6-addr CRLF
dns-ip4 = "dns-ip4" ":" ip4-addr CRLF
This section describes the basic operation required for the MN-HAC mutual authentication and the channel binding. The authentication protocol described as part of this section is a simple exchange that follows the Generalized Pre-Shared Key (GPSK) exchange used by EAP-GPSK [RFC5433]. It is secured by the TLS tunnel and is cryptographically bound to the TLS tunnel through channel binding based on [RFC5056] and on the channel binding type 'tls-server-endpoint' described in [RFC5929]. As a result of the channel binding type, this method can only be used with TLS ciphersuites that use server certificates and the Certificate handshake message. For example, TLS ciphersuites based on PSK or anonymous authentication cannot be used.
本节描述MN-HAC相互认证和通道绑定所需的基本操作。本节描述的认证协议是一个简单的交换，遵循EAP-GPSK使用的通用预共享密钥（GPSK）交换[RFC5433]。它由TLS隧道保护，并通过基于[RFC5056]和[RFC5929]中所述的通道绑定类型“TLS服务器端点”的通道绑定以加密方式绑定到TLS隧道。由于通道绑定类型的原因，此方法只能用于使用服务器证书和证书握手消息的TLS密码套件。例如，不能使用基于PSK或匿名身份验证的TLS密码套件。
The authentication exchange MUST be performed through the encrypted TLS tunnel. It performs mutual authentication between the MN and the HAC based on a PSK or based on an EAP-method (see Section 5.9). Note that an HAC MUST NOT allow MNs to renegotiate TLS sessions. The PSK protocol is described in this section. It consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth-Done) in which both sides exchange nonces and their identities, and compute and exchange a message authenticator 'auth' over the previously exchanged values, keyed with the pre-shared key. The MHAuth-Done messages are used to deal with error situations. Key binding with the TLS tunnel is ensured by channel binding of the type "tls-server-endpoint" as described by [RFC5929] where the hash of the TLS server certificate serves as input to the 'auth' calculation of the MHAuth messages.
身份验证交换必须通过加密的TLS隧道执行。它基于PSK或EAP方法在MN和HAC之间执行相互认证（见第5.9节）。请注意，HAC不得允许MNs重新协商TLS会话。本节介绍了PSK协议。它由消息交换（MHAuth Init、MHAuth Mid、MHAuth Done）组成，在这些消息交换中，双方交换nonce及其标识，并在先前交换的值上计算和交换消息验证器“auth”，并使用预共享密钥进行键控。MHAuth Done消息用于处理错误情况。通过[RFC5929]所述的“TLS服务器端点”类型的通道绑定确保与TLS隧道的密钥绑定，其中TLS服务器证书的哈希用作MHAuth消息的“auth”计算的输入。
Note: The authentication exchange is based on the GPSK exchange used by EAP-GPSK. In comparison to GPSK, it does not support exchanging an encrypted container (it always runs through an already protected TLS tunnel). Furthermore, the initial request of the authentication exchange (MHAuth-Init) is sent by the MN (client side) and is
注意：身份验证交换基于EAP-GPSK使用的GPSK交换。与GPSK相比，它不支持交换加密的容器（它总是通过已经受保护的TLS隧道运行）。此外，认证交换的初始请求（MHAuth Init）由MN（客户端）发送，并且
comparable to EAP-Response/Identity, which reverses the roles of request and response messages compared to EAP-GPSK. Figure 4 shows a successful protocol exchange.
与EAP响应/标识类似，与EAP-GPSK相比，它颠倒了请求和响应消息的角色。图4显示了一个成功的协议交换。
MN HAC
| |
| Request/MHAuth-Init (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Init (...) |
|<------------------------------------------------------|
| |
| Request/MHAuth-Done (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Done (...) |
|<------------------------------------------------------|
| |
MN HAC
| |
| Request/MHAuth-Init (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Init (...) |
|<------------------------------------------------------|
| |
| Request/MHAuth-Done (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Done (...) |
|<------------------------------------------------------|
| |
Figure 4: Authentication of the Mobile Node Using Shared Secrets
图4：使用共享机密对移动节点进行身份验证
1) Request/MHAuth-Init: (MN -> HAC)
1) Request/MHAuth-Init: (MN -> HAC)
mn-id, mn-rand, auth-method=psk
mn id，mn rand，auth method=psk
2) Response/MHAuth-Init: (MN <- HAC)
2) Response/MHAuth-Init: (MN <- HAC)
[mn-rand, hac-rand, auth-method=psk, [status],] auth
[mn rand，hac rand，auth method=psk，[status]，]auth
3) Request/MHAuth-Done: (MN -> HAC)
3) Request/MHAuth-Done: (MN -> HAC)
mn-rand, hac-rand, sa-scope, ciphersuite-list, auth
mn rand、hac rand、sa范围、密码套件列表、身份验证
4) Response/MHAuth-Done: (MN <- HAC)
4) Response/MHAuth-Done: (MN <- HAC)
[sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand, hac-rand, status, auth
[sa范围，sa数据，密码套件，引导数据，]mn rand，hac rand，状态，身份验证
Where 'auth' for MN -> HAC direction is as follows:
其中MN->HAC方向的“auth”如下所示：
auth = HMAC-SHA256(PSK, "MN" | msg-octets | CB-octets)
auth=HMAC-SHA256（PSK，“MN”| msg八位字节| CB八位字节）
Where 'auth' for MN <- HAC direction is as follows:
其中MN的“认证”<-HAC方向如下：
auth = HMAC-SHA256(PSK, "HAC" | msg-octets | CB-octets)
auth=HMAC-SHA256（PSK，“HAC”| msg八位字节| CB八位字节）
In the above, "MN" is 2 ASCII characters without null termination and "HAC" is 3 ASCII characters without null termination.
在上面的例子中，“MN”是2个ASCII字符，没有空终止，“HAC”是3个ASCII字符，没有空终止。
The length "mn-rand", "hac-rand" is 32 octets. Note that "|" indicates concatenation and optional parameters are shown in square brackets [..]. The square brackets can be nested.
长度“mn-rand”、“hac-rand”为32个八位字节。请注意，“|”表示串联，可选参数显示在方括号[…]中。方括号可以嵌套。
The shared secret PSK can be variable length. 'msg-octets' includes all payload parameters of the respective message to be signed except the 'auth' payload. CB-octets is the channel binding input to the auth calculation that is the "TLS-server-endpoint" channel binding type. The content and algorithm (only required for the "TLS-server-endpoint" type) are the same as described in [RFC5929].
共享秘密PSK可以是可变长度的。”msg octets'包括要签名的各个消息的所有有效负载参数，但“auth”有效负载除外。CB octets是身份验证计算的通道绑定输入，身份验证计算是“TLS服务器端点”通道绑定类型。内容和算法（仅“TLS服务器端点”类型需要）与[RFC5929]中所述相同。
The MN starts by selecting a random number 'mn-rand' and choosing a list of supported authentication methods coded in 'auth-method'. The MN sends its identity 'mn-id', 'mn-rand', and 'auth-method' to the HAC in MHAuth-Init. The decision of which authentication method to offer and which to pick is policy and implementation dependent and, therefore, outside the scope of this document.
MN首先选择一个随机数“MN rand”，然后选择一个在“auth method”中编码的受支持的身份验证方法列表。MN将其标识“MN id”、“MN rand”和“auth METHORY”发送到MHAuth Init中的HAC。提供哪种身份验证方法和选择哪种身份验证方法取决于策略和实现，因此不在本文档的范围内。
In MHAuth-Done, the HAC sends a random number 'hac-rand' and the selected ciphersuite. The selection MUST be one of the MN-supported ciphersuites as received in 'ciphersuite-list'. Furthermore, it repeats the received parameters of the MHAuth-Init message 'mn-rand'. It computes a message authenticator 'auth' over all the transmitted parameters except 'auth' itself. The HAC calculates 'auth' over all parameters and appends it to the message.
在MHAuth Done中，HAC发送一个随机数“HAC rand”和所选密码套件。所选内容必须是在“ciphersuite列表”中收到的MN支持的密码套件之一。此外，它还重复MHAuth Init消息“mn rand”的接收参数。它在除“auth”本身之外的所有传输参数上计算消息验证器“auth”。HAC计算所有参数的“auth”，并将其附加到消息中。
The MN verifies the received Message Authentication Code (MAC) and the consistency of the identities, nonces, and ciphersuite parameters transmitted in MHAuth-Auth. In case of successful verification, the MN computes a MAC over the session parameter and returns it to the HAC in MHAuth-Done. The HAC verifies the received MAC and the consistency of the identities, nonces, and ciphersuite parameters transmitted in MHAuth-Init. If the verification is successful, MHAuth-Done is prepared and sent by the HAC to confirm successful completion of the exchange.
MN验证接收到的消息认证码（MAC）以及在MHAuth Auth中传输的标识、nonce和密码套件参数的一致性。在验证成功的情况下，MN通过会话参数计算MAC，并将其返回给MHAuth Done中的HAC。HAC验证接收到的MAC以及在MHAuth Init中传输的标识、nonce和密码套件参数的一致性。如果验证成功，HAC准备并发送MHAuth Done以确认交换成功完成。
Basic operation required for the MN-HAC mutual authentication using EAP-based methods.
使用基于EAP的方法进行MN-HAC相互认证所需的基本操作。
MN HAC
| |
| Request/MHAuth-Init (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Init (..., |
| eap-payload=EAP-Request/Identity) |
|<------------------------------------------------------|
| |
| Request/MHAuth-Mid (eap-payload= |
| EAP-Response/Identity) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Mid (eap-payload=EAP-Request/...) |
|<------------------------------------------------------|
| |
: :
: ..EAP-method specific exchanges.. :
: :
| |
| Request/MHAuth-Done (eap-payload=EAP-Response/..., |
| ..., auth) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Done (eap-payload=EAP-Success, |
| ..., auth) |
|<------------------------------------------------------|
| |
MN HAC
| |
| Request/MHAuth-Init (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Init (..., |
| eap-payload=EAP-Request/Identity) |
|<------------------------------------------------------|
| |
| Request/MHAuth-Mid (eap-payload= |
| EAP-Response/Identity) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Mid (eap-payload=EAP-Request/...) |
|<------------------------------------------------------|
| |
: :
: ..EAP-method specific exchanges.. :
: :
| |
| Request/MHAuth-Done (eap-payload=EAP-Response/..., |
| ..., auth) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Done (eap-payload=EAP-Success, |
| ..., auth) |
|<------------------------------------------------------|
| |
Figure 5: Authentication of the Mobile Node Using EAP
图5：使用EAP对移动节点进行身份验证
1) Request/MHAuth-Init: (MN -> HAC)
1) Request/MHAuth-Init: (MN -> HAC)
mn-id, mn-rand, auth-method=eap
mn id，mn rand，auth method=eap
2) Response/MHAuth-Init: (MN <- HAC)
2) Response/MHAuth-Init: (MN <- HAC)
[auth-method=eap, eap, [status,]] auth
[auth method=eap，eap，[status，]]auth
3) Request/MHAuth-Mid: (MN -> HAC)
3) Request/MHAuth-Mid: (MN -> HAC)
eap, auth
eap，auth
4) Response/MHAuth-Mid: (MN <- HAC)
4) Response/MHAuth-Mid: (MN <- HAC)
eap, auth
eap，auth
MHAuth-Mid exchange is repeated as many times as needed by the used EAP-method.
MHAuth Mid交换根据所用EAP方法的需要重复多次。
5) Request/MHAuth-Done: (MN -> HAC)
5) Request/MHAuth-Done: (MN -> HAC)
sa-scope, ciphersuite-list, eap, auth
sa作用域、密码套件列表、eap、身份验证
6) Response/MHAuth-Done: (MN <- HAC)
6) Response/MHAuth-Done: (MN <- HAC)
[sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, status, auth
[sa作用域，sa数据，密码套件，引导数据，]eap，状态，身份验证
Where 'auth' for MN -> HAC direction is as follows:
其中MN->HAC方向的“auth”如下所示：
auth = HMAC-SHA256(shared-key, "MN" | msg-octets | CB-octets)
auth=HMAC-SHA256（共享密钥，“MN”| msg八位字节| CB八位字节）
Where 'auth' for MN <- HAC direction is as follows:
其中MN的“认证”<-HAC方向如下：
auth = HMAC-SHA256(shared-key, "HAC" | msg-octets | CB-octets)
auth=HMAC-SHA256（共享密钥，“HAC”| msg八位字节| CB八位字节）
In the above, "MN" is 2 ASCII characters without null termination and "HAC" is 3 ASCII characters without null termination.
在上面的例子中，“MN”是2个ASCII字符，没有空终止，“HAC”是3个ASCII字符，没有空终止。
In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1". If the EAP-method is key-deriving and creates a shared Master Session Key (MSK) as a side effect of Authentication shared-key MUST be the MSK in all MHAuth-Done messages. This MSK MUST NOT be used for any other purpose. In case the EAP method does not generate an MSK, shared-key is set to "1".
在MHAuth Init和MHAuth Mid消息中，共享密钥设置为“1”。如果EAP方法是密钥派生并创建共享主会话密钥（MSK）作为身份验证的副作用，则共享密钥必须是所有MHAuth Done消息中的MSK。此MSK不得用于任何其他用途。如果EAP方法不生成MSK，则将共享密钥设置为“1”。
'msg-octets' includes all payload parameters of the respective message to be signed except the 'auth' payload. CB-octets is the channel binding input to the AUTH calculation that is the "TLS-server-endpoint" channel binding type. The content and algorithm (only required for the "TLS-server-endpoint" type) are the same as described in [RFC5929].
“msg八位字节”包括要签名的各个消息的所有有效负载参数，但“auth”有效负载除外。CB octets是身份验证计算的通道绑定输入，身份验证计算是“TLS服务器端点”通道绑定类型。内容和算法（仅“TLS服务器端点”类型需要）与[RFC5929]中所述相同。
The following subsections describe the packet formats used for the traffic between the MN and the HA. This traffic includes binding management messages (for example, BU and BA messages), reverse-
以下小节描述用于MN和HA之间的通信的数据包格式。此流量包括绑定管理消息（例如，BU和BA消息），反之亦然-
tunneled and encrypted user data, and reverse-tunneled plaintext user data. This specification defines a generic packet format, where everything is encapsulated inside UDP. See Sections 6.3 and 6.4 for detailed illustrations of the corresponding packet formats.
隧道和加密用户数据，以及反向隧道明文用户数据。该规范定义了一种通用的数据包格式，其中所有内容都封装在UDP中。有关相应数据包格式的详细说明，请参见第6.3节和第6.4节。
The Mobile IPv6 service port number is where the HA expects to receive UDP packets. The same port number is used for both binding management messages and user data packets. The reason for multiplexing data and control messages over the same port number is due to the possibility of Network Address and Port Translators located along the path between the MN and the HA. The Mobile IPv6 service MAY use any ephemeral port number as the UDP source port, and it MUST use the Mobile IPv6 service port number as the UDP destination port. The Mobile IPv6 service port is dynamically assigned to the MN during the bootstrapping phase (i.e., the mip6- port parameter) or, in absence of the bootstrapping parameter, the IANA reserved port (mipv6tls) MUST be used.
移动IPv6服务端口号是HA希望接收UDP数据包的位置。绑定管理消息和用户数据包使用相同的端口号。在相同端口号上多路复用数据和控制消息的原因是，网络地址和端口转换器可能位于MN和HA之间的路径上。移动IPv6服务可以使用任何临时端口号作为UDP源端口，并且必须使用移动IPv6服务端口号作为UDP目标端口。移动IPv6服务端口在引导阶段（即mip6-port参数）动态分配给MN，或者在没有引导参数的情况下，必须使用IANA保留端口（mipv6tls）。
The encapsulating UDP header is immediately followed by a 4-bit Packet Type (PType) field that defines whether the packet contains an encrypted mobility management message, an encrypted user data packet, or a plaintext user data packet.
封装UDP报头后面紧跟着一个4位数据包类型（PType）字段，该字段定义数据包是包含加密的移动管理消息、加密的用户数据包还是纯文本用户数据包。
The Packet Type field is followed by a 28-bit SPI value, which identifies the correct SA concerning the encrypted packet. For any packet that is neither integrity protected nor encrypted (i.e., no SA is applied by the originator), the SPI MUST be set to 0 (zero). Mobility management messages MUST always be at least integrity protected. Hence, mobility management messages MUST NOT be sent with an SPI value of 0 (zero).
数据包类型字段后面跟着一个28位SPI值，该值标识与加密数据包相关的正确SA。对于既没有完整性保护也没有加密的任何数据包（即，发起者没有应用SA），SPI必须设置为0（零）。移动管理消息必须始终至少受到完整性保护。因此，在发送移动性管理消息时，SPI值不得为0（零）。
There is always only one SPI per MN-HA mobility session and the same SPI is used for all types of protected packets independent of the direction.
每个MN-HA移动性会话始终只有一个SPI，并且相同的SPI用于所有类型的受保护数据包，与方向无关。
The SPI value is followed by a 32-bit Sequence Number value that is used to identify retransmissions of protected messages (integrity protected or both integrity protected and encrypted, see Figures 7 and 8) . Each endpoint in the security association maintains two "current" Sequence Numbers: the next one to be used for a packet it initiates and the next one it expects to see in a packet from the other end. If the MN and the HA ends initiate very different numbers of messages, the Sequence Numbers in the two directions can be very different. In the case data protection is not used (see Figure 9), the Sequence Number MUST be set to 0 (zero). Note that the HA SHOULD initiate a re-establishment of the SA before any of the Sequence Number cycle.
SPI值后面是一个32位序列号值，用于标识受保护消息的重新传输（完整性保护或完整性保护和加密，见图7和图8）。安全关联中的每个端点维护两个“当前”序列号：下一个用于它发起的数据包，下一个用于它期望在来自另一端的数据包中看到的数据包。如果MN和HA端发起的消息数量非常不同，则两个方向上的序列号可能非常不同。如果未使用数据保护（见图9），则序列号必须设置为0（零）。请注意，HA应在任何序列号周期之前启动SA的重新建立。
Finally, the Sequence Number field is followed by the data portion, whose content is identified by the Packet Type. The data portion may be protected.
最后，序列号字段后面是数据部分，其内容由分组类型标识。数据部分可以被保护。
The PType is a 4-bit field that indicates the Packet Type (PType) of the UDP encapsulated packet. The PType is followed by a 28-bit SPI value. The PType and the SPI fields are treated as one 32-bit field during the integrity protection calculation.
PType是一个4位字段，指示UDP封装数据包的数据包类型（PType）。PType后面跟着一个28位SPI值。完整性保护计算期间，PType和SPI字段被视为一个32位字段。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Security Parameter Index with Packet Type
图6：包类型的安全参数索引
A SPI value of 0 (zero) indicates a plaintext packet. If the packet is integrity protected or both integrity protected and encrypted, the SPI value MUST be different from 0. When the SPI value is set to 0, then the PType MUST also be 0.
SPI值为0（零）表示纯文本数据包。如果数据包受完整性保护或同时受完整性保护和加密，则SPI值必须不同于0。当SPI值设置为0时，PType也必须为0。
The binding management messages that are only meant to be exchanged between the MN and the HA MUST be integrity protected and MAY be encrypted. They MUST use the packet format shown in Figure 7.
仅用于在MN和HA之间交换的绑定管理消息必须受到完整性保护，并且可以进行加密。它们必须使用图7所示的数据包格式。
All packets that are specific to the Mobile IPv6 protocol, contain a Mobility Header (as defined in Section 6.1.1. of RFC 6275) and are used between the MN and the HA shall use the packet format shown in Figure 7. (This means that some Mobile IPv6 mobility management messages, such as the Home Test Init (HoTI) message, are treated as data packets and using encapsulation described in Section 6.4 and shown in Figures 8 and 9).
特定于移动IPv6协议、包含移动报头（如RFC 6275第6.1.1节所定义）且在MN和HA之间使用的所有数据包应使用图7所示的数据包格式。（这意味着一些移动IPv6移动性管理消息，如Home Test Init（HoTI）消息，被视为数据包，并使用第6.4节中描述的封装，如图8和图9所示）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|PType=8| SPI | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data (variable) | | ^
: : | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|PType=8| SPI | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data (variable) | | ^
: : | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: UDP-Encapsulated Binding Management Message Format
图7:UDP封装的绑定管理消息格式
The PType value 8 (eight) identifies that the UDP-encapsulated packet contains a Mobility Header (defined by RFC 6275) and other relevant IPv6 extension headers. Note, there is no additional IP header inside the encapsulated part. The Next Header field MUST be set to value of the first encapsulated header. The encapsulated headers follow the natural IPv6 and Mobile IPv6 extension header alignment and formatting rules.
PType值8（八）标识UDP封装的数据包包含移动报头（由RFC 6275定义）和其他相关IPv6扩展报头。注意，封装部件内没有额外的IP头。下一个标题字段必须设置为第一个封装标题的值。封装的标头遵循自然IPv6和移动IPv6扩展标头对齐和格式化规则。
The Padding, Pad Length, Next Header, and ICV fields follow the rules of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this document. For an SPI value of 0 (zero) that indicates an unprotected packet, the Padding, Pad Length, Next Header, and ICV fields MUST NOT be present.
除非本文件另有规定，否则填充、焊盘长度、下一个标题和ICV字段遵循[RFC4303]第2.4节至第2.8节的规则。对于表示未受保护的数据包的SPI值0（零），填充、填充长度、下一个报头和ICV字段不得存在。
The source and destination IP addresses of the outer IP header (i.e., the src-addr and the dst-addr in Figure 7) use the current CoA of the MN and the HA address.
外部IP头的源和目标IP地址（即图7中的src addr和dst addr）使用MN的当前CoA和HA地址。
There are two types of reverse-tunneled user data packets between the MN and the HA: those that are integrity protected and/or encrypted and those that are sent in the clear. The MN or the HA decides whether to apply integrity protection and/or encryption to a packet or to send it in the clear based on the mip6-sas value in the SA. If the mip6-sas is set to 1, the originator MUST NOT send any user data packets in the clear, and the receiver MUST silently discard any packet with the PType set to 0 (unprotected). It is RECOMMENDED that confidentiality and integrity protection of user data traffic be applied. The reverse-tunneled IPv4 or IPv6 user data packets are encapsulated as is inside the 'Payload Data' shown in Figures 8 and 9.
MN和HA之间有两种类型的反向隧道用户数据包：受完整性保护和/或加密的数据包和以明文形式发送的数据包。MN或HA根据SA中的mip6 sas值决定是对数据包应用完整性保护和/或加密，还是以明文形式发送数据包。如果mip6 sas设置为1，则发端人不得以明文形式发送任何用户数据包，并且接收方必须以静默方式丢弃任何PType设置为0（未受保护）的数据包。建议应用用户数据通信的机密性和完整性保护。反向隧道IPv4或IPv6用户数据包封装在图8和图9所示的“有效负载数据”中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=1| SPI | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data (variable) | | ^
: : | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=1| SPI | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data (variable) | | ^
: : | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: UDP-Encapsulated Protected User Data Packet Format
图8:UDP封装的受保护用户数据包格式
The PType value 1 (one) identifies that the UDP-encapsulated packet contains an encrypted-tunneled IPv4/IPv6 user data packet. The Next Header field header MUST be set to value corresponding the tunneled IP packet (e.g., 41 for IPv6).
PType值1（一）标识UDP封装的数据包包含加密的隧道式IPv4/IPv6用户数据包。下一个报头字段报头必须设置为与隧道IP数据包对应的值（例如，IPv6为41）。
The Padding, Pad Length, Next Header, and ICV fields follow the rules of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this document. For an SPI value of 0 (zero) that indicates an unprotected packet, the Padding, Pad Length, Next Header, and ICV fields MUST NOT be present.
除非本文件另有规定，否则填充、焊盘长度、下一个标题和ICV字段遵循[RFC4303]第2.4节至第2.8节的规则。对于表示未受保护的数据包的SPI值0（零），填充、填充长度、下一个报头和ICV字段不得存在。
The source and destination IP addresses of the outer IP header (i.e., the src-addr and the dst-addr in Figure 8) use the current CoA of the MN and the HA address. The ESP-protected inner IP header, which is not shown in Figure 8, uses the home address of the MN and the correspondent node (CN) address.
外部IP头的源和目标IP地址（即图8中的src addr和dst addr）使用MN的当前CoA和HA地址。ESP保护的内部IP报头（图8中未显示）使用MN的家庭地址和对应节点（CN）地址。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Payload Data (plain IPv4 or IPv6 Packet) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Payload Data (plain IPv4 or IPv6 Packet) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: UDP-Encapsulated Non-Protected User Data Packet Format
图9:UDP封装的非保护用户数据包格式
The PType value 0 (zero) identifies that the UDP-encapsulated packet contains a plaintext-tunneled IPv4/IPv6 user data packet. Also, the SPI and the Sequence Number fields MUST be set to 0 (zero).
PType值0（零）标识UDP封装的数据包包含明文隧道IPv4/IPv6用户数据包。此外，SPI和序列号字段必须设置为0（零）。
The source and destination IP addresses of the outer IP header (i.e., the src-addr and the dst-addr in Figure 9) use the current CoA of the MN and the HA address. The plaintext inner IP header uses the home address of the MN and the CN address.
外部IP头的源和目标IP地址（即图9中的src addr和dst addr）使用MN的当前CoA和HA地址。明文内部IP报头使用MN的家庭地址和CN地址。
Mobile IPv6 route optimization as described in [RFC6275] is not affected by this specification. Route optimization is possible only between an IPv6 MN and CN. UDP encapsulation of signaling and data traffic is only between the MN and HA. The return routability signaling messages such as HoTI/HoT and CoTI/CoT [RFC6275] are treated as data packets and encapsulation, when needed, is per the description in Section 6.4 of this specification. The data packets between an MN and CN that have successfully completed the return routability test and created the appropriate entries in their binding cache are not UDP encapsulated using the packet formats defined in this specification but follow the [RFC6275] specification.
[RFC6275]中所述的移动IPv6路由优化不受本规范的影响。只能在IPv6 MN和CN之间进行路由优化。信令和数据通信的UDP封装仅在MN和HA之间。返回路由性信令消息，如HoTI/HoT和CoTI/CoT[RFC6275]被视为数据包，必要时，按照本规范第6.4节中的说明进行封装。MN和CN之间已成功完成返回可路由性测试并在其绑定缓存中创建适当条目的数据包不是使用本规范中定义的数据包格式进行UDP封装的，而是遵循[RFC6275]规范。
IANA has created a new registry under the [RFC6275] Mobile IPv6 parameters registry for the Packet Type as described in Section 6.1.
IANA已在[RFC6275]移动IPv6参数注册表下为第6.1节所述的数据包类型创建了一个新注册表。
Description | Value
----------------------------------+----------------------------------
non-encrypted IP packet | 0
encrypted IP packet | 1
mobility header | 8
Description | Value
----------------------------------+----------------------------------
non-encrypted IP packet | 0
encrypted IP packet | 1
mobility header | 8
Following the allocation policies from [RFC5226], new values for the Packet Type AVP MUST be assigned based on the "RFC Required" policy.
按照[RFC5226]中的分配策略，必须根据“需要RFC”策略为数据包类型AVP分配新值。
A new Status Code (to be used in BA messages) is reserved for the cases where the HA wants to indicate to the MN that it needs to re-establish the SA information with the HAC. The following value is reserved in the [RFC6275] Status Codes registry:
在HA希望向MN指示需要与HAC重新建立SA信息的情况下，保留了一个新的状态代码（将在BA消息中使用）。[RFC6275]状态代码注册表中保留以下值：
REINIT_SA_WITH_HAC 176
雷尼特·萨乌与哈奇176
A new port number (mipv6tls) for UDP packets is reserved from the existing PORT NUMBERS registry.
从现有端口号注册表中保留UDP数据包的新端口号（mipv6tls）。
mipv6tls 7872
mipv6tls 7872
This document describes and uses a number of building blocks that introduce security mechanisms and need to interwork in a secure manner.
本文档描述并使用了许多构建块，这些构建块引入了安全机制，并且需要以安全的方式进行交互。
The following building blocks are considered from a security point of view:
从安全角度考虑以下构造块：
1. Discovery of the HAC
1. HAC的发现
2. Authentication and MN-HA SA establishment executed between the MN and the HAC (PSK- or EAP-based) through a TLS tunnel
2. 通过TLS隧道在MN和HAC（基于PSK或EAP）之间执行身份验证和MN-HA SA建立
3. Protection of MN-HA communication
3. MN-HA通信的保护
4. AAA interworking
4. AAA互通
No dynamic procedure for discovering the HAC by the MN is described in this document. As such, no specific security considerations apply to the scope of this document.
本文件中没有描述MN发现HAC的动态过程。因此，本文件的范围不适用任何特定的安全注意事项。
9.2. Authentication and Key Exchange Executed between the MN and the HAC
9.2. 在MN和HAC之间执行身份验证和密钥交换
This document describes a simple authentication and MN-HA SA negotiation exchange over TLS. The TLS procedures remain unchanged; however, channel binding is provided.
本文档描述了TLS上的简单身份验证和MN-HA SA协商交换。TLS程序保持不变；但是，提供了通道绑定。
Authentication: Server-side certificate-based authentication MUST be performed using TLS version 1.2 [RFC5246]. The MN MUST verify the HAC's TLS server certificate, using either the subjectAltName extension [RFC5280] dNSName identities as described in [RFC6125] or subjectAltName iPAddress identities. In case of iPAddress identities, the MN MUST check the IP address of the TLS connection against these iPAddress identities and SHOULD reject the connection if none of the iPAddress identities match the connection. In case of dNSName identities, the rules and guidelines defined in [RFC6125] apply here, with the following considerations:
身份验证：必须使用TLS 1.2版[RFC5246]执行基于服务器端证书的身份验证。MN必须使用[RFC6125]中所述的subjectAltName扩展[RFC5280]dNSName标识或subjectAltName IP地址标识验证HAC的TLS服务器证书。对于iPAddress标识，MN必须对照这些iPAddress标识检查TLS连接的IP地址，如果没有一个iPAddress标识与连接匹配，则应拒绝连接。对于dNSName标识，[RFC6125]中定义的规则和指南在此适用，并考虑以下因素：
* Support for DNS-ID identifier type (the dNSName identity in the subjectAltName extension) is REQUIRED in the HAC and the MN TLS implementations.
* HAC和MN TLS实现中需要支持DNS-ID标识符类型（subjectAltName扩展中的dNSName标识）。
* DNS names in the HAC server certificates MUST NOT contain the wildcard character "*".
* HAC服务器证书中的DNS名称不得包含通配符“*”。
* The CN-ID MUST NOT be used for authentication within the rules described in [RFC6125].
* CN-ID不得用于[RFC6125]中所述规则内的身份验证。
* The MN MUST set its "reference identifier" to the DNS name of the HAC.
* MN必须将其“参考标识符”设置为HAC的DNS名称。
The client-side authentication may depend on the specific deployment and is therefore not mandated. Note that TLS-PSK [RFC4279] cannot be used in conjunction with the methods described in Sections 5.8 and 5.9 of this document due to the limitations of the channel binding type used.
客户端身份验证可能取决于特定的部署，因此不是强制要求的。请注意，由于所用通道绑定类型的限制，TLS-PSK[RFC4279]不能与本文件第5.8节和第5.9节所述方法结合使用。
Through the protected TLS tunnel, an additional authentication exchange is performed that provides client-side or mutual authentication and exchanges SA parameters and optional configuration data to be used in the subsequent protection of MN-HA communication. The additional authentication exchange can be either PSK-based (Section 5.8) or EAP-based (Section 5.9). Both exchanges are always performed within the protected TLS tunnel and MUST NOT be used as standalone protocols.
通过受保护的TLS隧道，执行额外的身份验证交换，该交换提供客户端或相互身份验证，并交换SA参数和可选配置数据，以用于MN-HA通信的后续保护。附加认证交换可以是基于PSK（第5.8节）或基于EAP（第5.9节）。这两种交换始终在受保护的TLS隧道内执行，不得用作独立协议。
The simple PSK-based authentication exchange provides mutual authentication and follows the GPSK exchange used by EAP-GPSK [RFC5433] and has similar properties, although some features of GPSK like the exchange of a protected container are not supported.
基于PSK的简单身份验证交换提供相互身份验证，遵循EAP-GPSK[RFC5433]使用的GPSK交换，并具有类似的属性，但不支持GPSK的某些功能，如受保护容器的交换。
The EAP-based authentication exchange simply defines message containers to allow carrying the EAP packets between the MN and the HAC. In principle, any EAP method can be used. However, it is strongly recommended to use only EAP methods that provide mutual authentication and that derive keys including an MSK in compliance with [RFC3748].
基于EAP的身份验证交换仅定义消息容器，以允许在MN和HAC之间承载EAP数据包。原则上，可以使用任何EAP方法。但是，强烈建议仅使用提供相互身份验证并根据[RFC3748]派生密钥（包括MSK）的EAP方法。
Both exchanges use channel binding with the TLS tunnel. The channel binding type 'TLS-server-endpoint' per [RFC5929] MUST be used.
两个交换机都使用与TLS隧道的通道绑定。必须使用符合[RFC5929]的通道绑定类型“TLS server endpoint”。
Dictionary Attacks: All messages of the authentication exchanges specified in this document are protected by TLS. However, any implementation SHOULD assume that the properties of the authentication exchange are the same as for GPSK [RFC5433], in case the PSK-based method per Section 5.8 is used, and are the same as those of the underlying EAP method, in case the EAP-based exchange per Section 5.9 is used.
字典攻击：本文档中指定的身份验证交换的所有消息都受TLS保护。但是，如果使用第5.8节规定的基于PSK的方法，则任何实现都应假设验证交换的属性与GPSK[RFC5433]的属性相同，如果使用第5.9节规定的基于EAP的交换，则验证交换的属性与基础EAP方法的属性相同。
Replay Protection: The underlying TLS protection provides protection against replays.
重播保护：底层TLS保护针对重播提供保护。
Key Derivation and Key Strength: For TLS, the TLS-specific considerations apply unchanged. For the authentication exchanges defined in this document, no key derivation step is performed as the MN-HA keys are generated by the HAC and are distributed to the MN through the secure TLS connection.
密钥派生和密钥强度：对于TLS，TLS的特定注意事项不变。对于本文档中定义的身份验证交换，不执行密钥派生步骤，因为MN-HA密钥由HAC生成，并通过安全TLS连接分发给MN。
Key Control: No joint key control for MN-HA keys is provided by this version of the specification.
密钥控制：本规范版本未提供MN-HA密钥的联合密钥控制。
Lifetime: The TLS-protected authentication exchange between the MN and the HAC is only to bootstrap keys and other parameters for usage with MN-HA security. The SAs that contain the keys have an associated lifetime. The usage of Transport Layer Security (TLS) Session Resumption without Server-Side State, described in [RFC5077], provides the ability for the MN to minimize the latency of future exchanges towards the HA without having to keep state at the HA itself.
生存期：MN和HAC之间受TLS保护的身份验证交换仅用于引导密钥和其他参数，以用于MN-HA安全性。包含密钥的SA具有关联的生存期。[RFC5077]中所述的在没有服务器端状态的情况下使用传输层安全性（TLS）会话恢复，使MN能够最大限度地减少未来向HA的交换延迟，而无需将状态保持在HA本身。
Denial-of-Service (DoS) Resistance: The level of resistance against DoS attacks SHOULD be considered the same as for common TLS operation, as TLS is used unchanged. For the PSK-based authentication exchange, no additional factors are known. For the EAP-based authentication exchange, any considerations regarding DoS resistance specific to the chosen EAP method are expected to be applicable and need to be taken into account.
拒绝服务（DoS）抵抗：对DoS攻击的抵抗水平应与普通TLS操作的抵抗水平相同，因为TLS的使用方式不变。对于基于PSK的身份验证交换，不知道其他因素。对于基于EAP的身份验证交换，任何与所选EAP方法特定的DoS抵抗有关的考虑都是适用的，并且需要加以考虑。
Session Independence: Each individual TLS protocol run is independent from any previous exchange based on the security properties of the TLS handshake protocol. However, several PSK-or EAP-based authentication exchanges can be performed across the same TLS connection.
会话独立性：根据TLS握手协议的安全属性，每个单独的TLS协议运行都独立于以前的任何交换。但是，可以在同一TLS连接上执行多个基于PSK或EAP的身份验证交换。
Fragmentation: TLS runs on top of TCP and no fragmentation-specific considerations apply to the MN-HAC authentication exchanges.
分段：TLS在TCP之上运行，MN-HAC身份验证交换不适用于特定于分段的注意事项。
Channel Binding: Both the PSK and the EAP-based exchanges use channel binding with the TLS tunnel. The channel binding type 'TLS-server-endpoint' per [RFC5929] MUST be used.
通道绑定：基于PSK和EAP的交换机都使用TLS隧道的通道绑定。必须使用符合[RFC5929]的通道绑定类型“TLS server endpoint”。
Fast Reconnect: This protocol provides session resumption as part of TLS and optionally the support for [RFC5077]. No fast reconnect is supported for the PSK-based authentication exchange. For the EAP-based authentication exchange, availability of fast reconnect depends on the EAP method used.
快速重新连接：该协议作为TLS的一部分提供会话恢复，并可选地支持[RFC5077]。基于PSK的身份验证交换不支持快速重新连接。对于基于EAP的身份验证交换，快速重新连接的可用性取决于所使用的EAP方法。
Identity Protection: Based on the security properties of the TLS tunnel, passive user identity protection is provided. An attacker acting as man-in-the-middle in the TLS connection would be able to observe the MN identity value sent in MHAuth-Init messages.
身份保护：基于TLS隧道的安全属性，提供被动用户身份保护。在TLS连接中充当中间人的攻击者将能够观察MHAuth Init消息中发送的MN标识值。
Protected Ciphersuite Negotiation: This protocol provides ciphersuite negotiation based on TLS.
受保护的密码套件协商：该协议提供基于TLS的密码套件协商。
Confidentiality: Confidentiality protection of payloads exchanged between the MN and the HAC are protected with the TLS Record Layer. TLS ciphersuites with confidentiality and integrity protection MUST be negotiated and used in order to exchange security sensitive material inside the TLS connection.
机密性：MN和HAC之间交换的有效载荷的机密性保护通过TLS记录层进行保护。必须协商并使用具有机密性和完整性保护的TLS密码套件，以便在TLS连接内部交换安全敏感材料。
Cryptographic Binding: No cryptographic bindings are provided by this protocol specified in this document.
加密绑定：本文档中指定的协议未提供加密绑定。
Perfect Forward Secrecy: Perfect forward secrecy is provided with appropriate TLS ciphersuites.
完美前向保密：完美前向保密配有适当的TLS密码套件。
Key confirmation: Key confirmation of the keys established with TLS is provided by the TLS Record Layer when the keys are used to protect the subsequent TLS exchange.
密钥确认：当密钥用于保护后续的TLS交换时，TLS记录层提供对使用TLS建立的密钥的密钥确认。
Authentication: Data origin authentication is provided for the communication between the MN and the HA. The chosen level of security of this authentication depends on the selected ciphersuite. Entity authentication is offered by the MN to HAC protocol exchange.
身份验证：为MN和HA之间的通信提供数据源身份验证。此身份验证的选定安全级别取决于选定的密码套件。实体认证由MN到HAC协议交换提供。
Dictionary Attacks: The concept of dictionary attacks is not applicable to the MN-HA communication as the keying material used for this communication is randomly created by the HAC and its length depends on the chosen cryptographic algorithms.
字典攻击：字典攻击的概念不适用于MN-HA通信，因为用于此通信的密钥材料是由HAC随机创建的，其长度取决于所选的加密算法。
Replay Protection: Replay protection for the communication between the MN and the HA is provided based on sequence numbers and follows the design of IPsec ESP.
重放保护：MN和HA之间通信的重放保护基于序列号提供，并遵循IPsec ESP的设计。
Key Derivation and Key Strength: The strength of the keying material established for the communication between the MN and the HA is selected based on the negotiated ciphersuite (based on the MN-HAC exchange) and the key created by the HAC. The randomness requirements for security described in [RFC4086] are applicable to the key generation by the HAC.
密钥派生和密钥强度：为MN和HA之间的通信建立的密钥材料的强度是基于协商密码套件（基于MN-HAC交换）和HAC创建的密钥选择的。[RFC4086]中描述的安全性随机性要求适用于HAC生成密钥。
Key Control: The keying material established during the MN-HAC protocol exchange for subsequent protection of the MN-HA communication is created by the HA and therefore no joint key control is provided for it.
密钥控制：在MN-HAC协议交换期间为后续保护MN-HA通信而建立的密钥材料由HA创建，因此不为其提供联合密钥控制。
Key Naming: For the MN-HA communication, the security associations are indexed with the help of the SPI and additionally based on the direction (inbound communication or outbound communication).
密钥命名：对于MN-HA通信，安全关联在SPI的帮助下被编入索引，另外还基于方向（入站通信或出站通信）。
Lifetime: The lifetime of the MN-HA security associations is based on the value in the mip6-sa-validity-end header field exchanged during the MN-HAC exchange. The HAC controls the SA lifetime.
生存期：MN-HA安全关联的生存期基于在MN-HAC交换期间交换的mip6 sa有效性结束标头字段中的值。HAC控制SA寿命。
DoS Resistance: For the communication between the MN and the HA, there are no heavy cryptographic operations (such as public key computations). As such, there are no DoS concerns.
DoS抵抗：对于MN和HA之间的通信，没有繁重的加密操作（例如公钥计算）。因此，不存在DoS问题。
Session Independence: Sessions are independent from each other when new keys are created via the MN-HAC protocol. A new MN-HAC protocol run produces fresh and unique keying material for protection of the MN-HA communication.
会话独立性：通过MN-HAC协议创建新密钥时，会话彼此独立。新的MN-HAC协议运行产生了新的和独特的密钥材料，用于保护MN-HA通信。
Fragmentation: There is no additional fragmentation support provided beyond what is offered by the network layer.
碎片化：除了网络层提供的支持之外，没有提供额外的碎片化支持。
Channel Binding: Channel binding is not applicable to the MN-HA communication.
通道绑定：通道绑定不适用于MN-HA通信。
Fast Reconnect: The concept of fast reconnect is not applicable to the MN-HA communication.
快速重新连接：快速重新连接的概念不适用于MN-HA通信。
Identity Protection: User identities SHOULD NOT be exchanged between the MN and the HA. In the case where binding management messages contain the user identity, the messages SHOULD be confidentiality protected.
身份保护：MN和HA之间不应交换用户身份。在绑定管理消息包含用户标识的情况下，消息应受到保密保护。
Protected Ciphersuite Negotiation: The MN-HAC protocol provides protected ciphersuite negotiation through a secure TLS connection.
受保护的密码套件协商：MN-HAC协议通过安全的TLS连接提供受保护的密码套件协商。
Confidentiality: Confidentiality protection of payloads exchanged between the MN and the HAC (for Mobile IPv6 signaling and optionally for the data traffic) is provided utilizing algorithms negotiated during the MN-HAC exchange.
机密性：利用在MN-HAC交换期间协商的算法，提供MN和HAC之间交换的有效负载的机密性保护（用于移动IPv6信令和可选的数据流量）。
Cryptographic Binding: No cryptographic bindings are provided by this protocol specified in this document.
加密绑定：本文档中指定的协议未提供加密绑定。
Perfect Forward Secrecy: Perfect forward secrecy is provided when the MN bootstraps new keying material with the help of the MN-HAC protocol (assuming that a proper TLS ciphersuite is used).
完美前向保密：当MN在MN-HAC协议的帮助下引导新的密钥材料时（假设使用了正确的TLS密码套件），提供了完美前向保密。
Key Confirmation: Key confirmation of the MN-HA keying material conveyed from the HAC to the MN is provided when the first packets are exchanged between the MN and the HA (in both directions as two different keys are used).
密钥确认：当MN和HA之间交换第一个数据包时（在两个方向上使用两个不同的密钥），提供从HAC传送到MN的MN-HA密钥材料的密钥确认。
The AAA backend infrastructure interworking is not defined in this document and is therefore out of scope.
本文档中未定义AAA后端基础架构互通，因此超出范围。
The authors would like to thank Pasi Eronen, Domagoj Premec, Julien Laganier, Jari Arkko, Stephen Farrell, Peter Saint-Andre and Christian Bauer for their comments.
作者要感谢Pasi Eronen、Domagoj Premec、Julien Laganier、Jari Arkko、Stephen Farrell、Peter Saint Andre和Christian Bauer的评论。
[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月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其在IPsec中的使用”，RFC 3566，2003年9月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[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月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.
[RFC5929]Altman，J.，Williams，N.，和L.Zhu，“TLS的通道绑定”，RFC 59292010年7月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[RFC3776]Arkko，J.，Devarapalli，V.，和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 37762004年6月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279]Eronen，P.和H.Tschofenig，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[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月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，2008年1月。
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, February 2009.
[RFC5433]Clancy，T.和H.Tschofenig，“可扩展认证协议-通用预共享密钥（EAP-GPSK）方法”，RFC 5433，2009年2月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]Soliman，H.，“双栈主机和路由器的移动IPv6支持”，RFC 55552009年6月。
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]Perkins，C.，“IPv4的IP移动支持，修订版”，RFC 59442010年11月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
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
Basavaraj Patil Nokia 6021 Connection Drive Irving, TX 75039 USA
美国德克萨斯州欧文市Basavaraj Patil诺基亚6021连接驱动器75039
EMail: basavaraj.patil@nokia.com
EMail: basavaraj.patil@nokia.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
Dirk Kroeselberg Siemens Otto-Hahn-Ring 6 Munich 81739 Germany
德国慕尼黑第6环德克·克罗塞尔伯格西门子奥托·哈恩81739
EMail: dirk.kroeselberg@siemens.com
EMail: dirk.kroeselberg@siemens.com