Network Working Group A. Patel
Request for Comments: 4285 K. Leung
Category: Informational Cisco Systems
M. Khalil
H. Akhtar
Nortel Networks
K. Chowdhury
Starent Networks
January 2006
Network Working Group A. Patel
Request for Comments: 4285 K. Leung
Category: Informational Cisco Systems
M. Khalil
H. Akhtar
Nortel Networks
K. Chowdhury
Starent Networks
January 2006
Authentication Protocol for Mobile IPv6
移动IPv6认证协议
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. RFC 3775 and 3776 define Mobile IPv6 and its security mechanism. This document presents an alternate security mechanism for Mobile IPv6 used in 3GPP2 networks.
本RFC不适用于任何级别的互联网标准。RFC 3775和3776定义了移动IPv6及其安全机制。本文档介绍3GPP2网络中使用的移动IPv6的替代安全机制。
The security properties of this mechanism have not been reviewed in the IETF. Conducting this review proved difficult because the standards-track security mechanism for Mobile IPv6 is tightly integrated into the protocol; extensions to Mobile IPv6 and the core documents make assumptions about the properties of the security model without explicitly stating what assumptions are being made. There is no documented service model. Thus it is difficult to replace the security mechanism and see if the current protocol and future extensions meet appropriate security requirements both under the original and new security mechanisms. If a service model for Mobile IPv6 security is ever formally defined and reviewed, a mechanism similar to this one could be produced and fully reviewed.
IETF中未对该机制的安全属性进行审查。由于移动IPv6的标准跟踪安全机制紧密集成在协议中，因此进行此审查很困难；移动IPv6和核心文档的扩展对安全模型的属性进行了假设，但没有明确说明所做的假设。没有文档化的服务模型。因此，在原有和新的安全机制下，很难替换安全机制，也很难确定当前协议和未来扩展是否满足适当的安全要求。如果曾经正式定义和审查过移动IPv6安全服务模型，那么可以产生类似于此的机制并进行全面审查。
Section 1.1 of this document provides an applicability statement for this RFC. The IESG recommends against the usage of this specification outside of environments that meet the conditions of that applicability statement. In addition the IESG recommends those
本文件第1.1节提供了本RFC的适用性声明。IESG建议不要在满足适用性声明条件的环境之外使用本规范。此外，IESG建议：
considering deploying or implementing this specification conduct a sufficient security review to meet the conditions of the environments in which this RFC will be used.
考虑部署或实施本规范时，应进行充分的安全审查，以满足使用本RFC的环境条件。
Abstract
摘要
IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages.
IPsec被指定为移动节点和移动IPv6（MIPv6）的归属代理之间的信令消息安全手段。受保护的MIPv6信令消息包括用于管理移动节点及其归属代理之间的绑定的绑定更新和确认消息。本文档提出了一种用于保护移动节点和归属代理之间的MIPv6信令消息的替代方法。此处定义的替代方法包括可添加到MIPv6信令消息的MIPv6特定移动消息认证选项。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Applicability Statement ....................................3
2. Overview ........................................................4
3. Terminology .....................................................5
3.1. General Terms ..............................................5
4. Operational Flow ................................................6
5. Mobility Message Authentication Option ..........................7
5.1. MN-HA Mobility Message Authentication Option ...............8
5.1.1. Processing Considerations ...........................9
5.2. MN-AAA Mobility Message Authentication Option ..............9
5.2.1. Processing Considerations ..........................10
5.3. Authentication Failure Detection at the Mobile Node .......11
6. Mobility Message Replay Protection Option ......................11
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................15
Appendix A. Rationale for mobility message replay protection
option ................................................16
1. Introduction ....................................................3
1.1. Applicability Statement ....................................3
2. Overview ........................................................4
3. Terminology .....................................................5
3.1. General Terms ..............................................5
4. Operational Flow ................................................6
5. Mobility Message Authentication Option ..........................7
5.1. MN-HA Mobility Message Authentication Option ...............8
5.1.1. Processing Considerations ...........................9
5.2. MN-AAA Mobility Message Authentication Option ..............9
5.2.1. Processing Considerations ..........................10
5.3. Authentication Failure Detection at the Mobile Node .......11
6. Mobility Message Replay Protection Option ......................11
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................15
Appendix A. Rationale for mobility message replay protection
option ................................................16
The base Mobile IPv6 specification [RFC3775] specifies the signaling messages, Binding Update (BU) and Binding Acknowledgement (BA), between the Mobile Node (MN) and Home Agent (HA) to be secured by the IPsec Security Associations (IPsec SAs) that are established between these two entities.
基本移动IPv6规范[RFC3775]规定了移动节点（MN）和归属代理（HA）之间的信令消息、绑定更新（BU）和绑定确认（BA），由这两个实体之间建立的IPsec安全关联（IPsec SA）保护。
This document proposes a solution for securing the Binding Update and Binding Acknowledgment messages between the Mobile Node and Home Agent using a mobility message authentication option that is included in these messages. Such a mechanism enables IPv6 mobility in a host without having to establish an IPsec SA with its Home Agent. A Mobile Node can implement Mobile IPv6 without having to integrate it with the IPsec module, in which case the Binding Update and Binding Acknowledgement messages (between MN-HA) are secured with the mobility message authentication option.
本文档提出了一种解决方案，用于使用包括在移动节点和归属代理之间的移动消息认证选项来保护绑定更新和绑定确认消息。这样的机制可以在主机中实现IPv6移动性，而无需使用其归属代理建立IPsec SA。移动节点可以实现移动IPv6，而无需将其与IPsec模块集成，在这种情况下，绑定更新和绑定确认消息（MN-HA之间）通过移动消息认证选项进行保护。
The authentication mechanism proposed here is similar to the authentication mechanism used in Mobile IPv4 [RFC3344].
这里提出的身份验证机制类似于移动IPv4[RFC3344]中使用的身份验证机制。
The mobility message authentication option specified in Section 5 is applicable in certain types of networks that have the following characteristics:
第5节中规定的移动消息认证选项适用于具有以下特征的某些类型的网络：
- Networks in which the authentication of the MN for network access is done by an authentication server in the home network via the home agent. The security association is established by the network operator (provisioning methods) between the MN and a backend authentication server (e.g., Authentication, Authorization, and Accounting (AAA) home server). MIPv6 as per RFCs 3775 and 3776 relies on the IPsec SA between the MN and an HA. In cases where the assignment of the HA is dynamic and the only static or long-term SA is between the MN and a backend authentication server, the mobility message authentication option is desirable.
- 网络，其中用于网络访问的MN的认证由家庭网络中的认证服务器通过家庭代理完成。安全关联由网络运营商（供应方法）在MN和后端身份验证服务器（例如，身份验证、授权和计费（AAA）家庭服务器）之间建立。根据RFCs 3775和3776，MIPv6依赖于MN和HA之间的IPsec SA。在HA的分配是动态的并且唯一的静态或长期SA在MN和后端认证服务器之间的情况下，移动消息认证选项是可取的。
- In certain deployment environments, the mobile node needs dynamic assignment of a home agent and home address. The assignment of such can be on a per-session basis or on a per-MN power-up basis. In such scenarios, the MN relies on an identity such as a Network Access Identifier (NAI) [RFC4283], and a security association with a AAA server to obtain such bootstrapping information. The security association is created via an out-of-band mechanism or by non Mobile IPv6 signaling. The out-of-band mechanism can be specific to the deployment environment of a network operator. In Code Division Multiple Access (CDMA) network deployments, this information can be
- 在某些部署环境中，移动节点需要动态分配归属代理和归属地址。可以基于每个会话或基于每个MN加电来分配此类资源。在这样的场景中，MN依赖诸如网络访问标识符（NAI）[RFC4283]之类的身份以及与AAA服务器的安全关联来获得这样的引导信息。安全关联是通过带外机制或非移动IPv6信令创建的。带外机制可以特定于网络运营商的部署环境。在码分多址（CDMA）网络部署中，这些信息可以
obtained at the time of network access authentication via [3GPP2] specific extensions to PPP or DHCPv6 on the access link and by AAA extensions in the core. It should be noted that the out-of-band mechanism is not within the scope of the mobility message authentication option (Section 5) and hence is not described therein.
通过接入链路上PPP或DHCPv6的[3GPP2]特定扩展以及核心中的AAA扩展在网络接入认证时获得。应当注意，带外机制不在移动消息认证选项（第5节）的范围内，因此在本文中没有描述。
- Network deployments in which not all Mobile Nodes and Home Agents have IKEv2 implementations and support for the integration of IKEv2 with backend AAA infrastructures. IKEv2 as a technology has yet to reach maturity status and widespread implementations needed for commercial deployments on a large scale. At the time of this writing, [RFC4306] is yet to be published as an RFC. Hence from a practical perspective that operators face, IKEv2 is not yet capable of addressing the immediate need for MIPv6 deployment.
- 并非所有移动节点和家庭代理都有IKEv2实现并支持IKEv2与后端AAA基础设施集成的网络部署。IKEv2作为一种技术尚未达到成熟状态，大规模商业部署需要广泛实施。在撰写本文时，[RFC4306]尚未作为RFC发布。因此，从运营商面临的实际角度来看，IKEv2还不能满足部署MIPv6的迫切需要。
- Networks that expressly rely on the backend AAA infrastructure as the primary means for identifying and authentication/authorizing a mobile user for MIPv6 service.
- 明确依赖后端AAA基础设施作为识别和验证/授权移动用户使用MIPv6服务的主要手段的网络。
- Networks in which the establishment of the security association between the Mobile Node and the authentication server (AAA Home) is established using an out-of-band mechanism and not by any key exchange protocol. Such networks will also rely on out-of-band mechanisms to renew the security association (between MN and AAA Home) when needed.
- 使用带外机制而不是任何密钥交换协议在移动节点和认证服务器（AAA Home）之间建立安全关联的网络。这种网络还将依赖带外机制在需要时更新安全关联（MN和AAA Home之间）。
- Networks that are bandwidth constrained (such as cellular wireless networks) and for which there exists a strong desire to minimize the number of signaling messages sent over such interfaces. MIPv6 signaling that relies on Internet Key Exchange (IKE) as the primary means for setting up an SA between the MN and HA requires more signaling messages compared with the use of an mobility message authentication option carried in the BU/BA messages.
- 带宽受限的网络（如蜂窝无线网络），并且存在最大限度地减少通过此类接口发送的信令消息数量的强烈愿望。与使用BU/BA消息中携带的移动消息认证选项相比，依赖于因特网密钥交换（IKE）作为在MN和HA之间建立SA的主要手段的MIPv6信令需要更多信令消息。
One such example of networks that have such characteristics are CDMA networks as defined in [3GPP2].
具有这种特性的网络的一个这样的示例是[3GPP2]中定义的CDMA网络。
This document presents a lightweight mechanism to authenticate the Mobile Node at the Home Agent or at the Authentication, Authorization, and Accounting (AAA) server in Home network (AAAH) based on a shared-key-based mobility security association between the Mobile Node and the respective authenticating entity. This shared-key-based mobility security association (shared-key-based mobility SA) may be statically provisioned or dynamically created. The term
本文档提供了一种轻量级机制，用于基于移动节点和相应认证实体之间基于共享密钥的移动安全关联，在归属代理处或在归属网络（AAAH）中的认证、授权和计费（AAA）服务器处认证移动节点。这种基于共享密钥的移动性安全关联（基于共享密钥的移动性SA）可以是静态供应的或动态创建的。术语
"mobility security association" referred to in this document is understood to be a "shared-key-based Mobile IPv6 authentication" security association.
本文档中提到的“移动安全关联”被理解为“基于共享密钥的移动IPv6认证”安全关联。
This document introduces new mobility options to aid in authentication of the Mobile Node to the Home Agent or AAAH server. The confidentiality protection of Return Routability messages and authentication/integrity protection of Mobile Prefix Discovery (MPD) is not provided when these options are used for authentication of the Mobile Node to the Home Agent. Thus, unless the network can guarantee such protection (for instance, like in 3GPP2 networks), Route Optimization and Mobile Prefix Discovery should not be used when using the mobility message authentication option.
本文档介绍了新的移动选项，以帮助将移动节点验证到归属代理或AAAH服务器。当这些选项用于向归属代理认证移动节点时，不提供返回路由性消息的机密性保护和移动前缀发现（MPD）的认证/完整性保护。因此，除非网络能够保证这样的保护（例如，类似于3GPP2网络），否则在使用移动消息认证选项时不应使用路由优化和移动前缀发现。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中所述进行解释。
First (size, input)
第一（大小、输入）
Some formulas in this specification use a functional form "First (size, input)" to indicate truncation of the "input" data so that only the first "size" bits remain to be used.
本规范中的一些公式使用函数形式“First（size，input）”来表示“input”数据的截断，以便只保留第一个“size”位。
Shared-key-based Mobility Security Association
基于共享密钥的移动安全关联
Security relation between the Mobile Node and its Home Agent, used to authenticate the Mobile Node for mobility service. The shared-key-based mobility security association between Mobile Node and Home Agent consists of a mobility Security Parameter Index (SPI), a shared key, an authentication algorithm, and the replay protection mechanism in use.
移动节点与其归属代理之间的安全关系，用于验证移动节点的移动服务。移动节点和归属代理之间基于共享密钥的移动安全关联由一个移动安全参数索引（SPI）、一个共享密钥、一个认证算法和正在使用的重播保护机制组成。
Mobility SPI
移动性SPI
A number in the range [0-4294967296] used to index into the shared-key-based mobility security associations.
范围为[0-4294967296]的数字，用于索引基于共享密钥的移动安全关联。
The figure below describes the sequence of messages sent and received between the MN and HA in the registration process. Binding Update (BU) and Binding Acknowledgement (BA) messages are used in the registration process.
下图描述了注册过程中MN和HA之间发送和接收的消息序列。在注册过程中使用绑定更新（BU）和绑定确认（BA）消息。
MN HA/AAAH
MN HA/AAAH
| BU to HA |
(a) |----------------------------------------------------->|
| (including MN-ID option, |
| mobility message replay protection option[optional],|
| mobility message authentication option) |
| |
| HA/AAAH authenticates MN
| |
| |
| BA to MN |
(b) |<-----------------------------------------------------|
| (including MN-ID option, |
| mobility message replay protection option[optional],|
| mobility message authentication option) |
| |
| BU to HA |
(a) |----------------------------------------------------->|
| (including MN-ID option, |
| mobility message replay protection option[optional],|
| mobility message authentication option) |
| |
| HA/AAAH authenticates MN
| |
| |
| BA to MN |
(b) |<-----------------------------------------------------|
| (including MN-ID option, |
| mobility message replay protection option[optional],|
| mobility message authentication option) |
| |
Figure 1: Home Registration with Authentication Protocol
图1：使用身份验证协议的家庭注册
The Mobile Node MUST use the Mobile Node Identifier option, specifically the MN-NAI mobility option as defined in [RFC4283] to identify itself while authenticating with the Home Agent. The Mobile Node uses the Mobile Node Identifier option as defined in [RFC4283] to identify itself as may be required for use with some existing AAA infrastructure designs.
移动节点必须使用移动节点标识符选项，特别是[RFC4283]中定义的MN-NAI移动选项，以在与归属代理进行身份验证时识别自身。移动节点使用[RFC4283]中定义的移动节点标识符选项来识别自身，以与一些现有AAA基础设施设计一起使用。
The Mobile Node MAY use the Message Identifier option as defined in Section 6 for additional replay protection.
移动节点可以使用第6节中定义的消息标识符选项进行额外的重播保护。
The mobility message authentication option described in Section 5 may be used by the Mobile Node to transfer authentication data when the Mobile Node and the Home Agent are utilizing a mobility SPI (a number in the range [0-4294967296] used to index into the shared-key-based mobility security associations) to index between multiple mobility security associations.
当移动节点和归属代理使用移动SPI（用于索引到基于共享密钥的移动安全关联的范围[0-4294967296]中的数字）时，第5节中描述的移动消息认证选项可由移动节点用于传输认证数据在多个移动安全关联之间建立索引。
This section defines a mobility message authentication option that may be used to secure Binding Update and Binding Acknowledgement messages. This option can be used along with IPsec or preferably as an alternate mechanism to authenticate Binding Update and Binding Acknowledgement messages in the absence of IPsec.
本节定义了可用于保护绑定更新和绑定确认消息的移动消息认证选项。此选项可以与IPsec一起使用，或者最好作为备用机制，在没有IPsec的情况下对绑定更新和绑定确认消息进行身份验证。
This document also defines subtype numbers, which identify the mode of authentication and the peer entity to authenticate the message. Two subtype numbers are specified in this document. Other subtypes may be defined for use in the future.
本文档还定义了子类型编号，用于标识身份验证模式和用于验证消息的对等实体。本文档中指定了两个子类型编号。可以定义其他子类型以供将来使用。
Only one instance of a mobility message authentication option of a particular subtype can be present in the message. One message may contain multiple instances of the mobility message authentication option with different subtype values. If both MN-HA and MN-AAA authentication options are present, the MN-HA authentication option must be present before the MN-AAA authentication option (else, the HA MUST discard the message).
消息中只能存在特定子类型的移动消息身份验证选项的一个实例。一条消息可能包含具有不同子类型值的移动消息认证选项的多个实例。如果同时存在MN-HA和MN-AAA身份验证选项，则MN-HA身份验证选项必须位于MN-AAA身份验证选项之前（否则，HA必须丢弃消息）。
When a Binding Update or Binding Acknowledgement is received without a mobility message authentication option and the entity receiving it is configured to use the mobility message authentication option or has the shared-key-based mobility security association for the mobility message authentication option, the entity should silently discard the received message.
当在没有移动消息认证选项的情况下接收到绑定更新或绑定确认，并且接收它的实体被配置为使用移动消息认证选项或具有用于移动消息认证选项的基于共享密钥的移动安全关联时，实体应以静默方式放弃接收到的消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Mobility Message Authentication Option
图2：移动消息认证选项
Option Type:
选项类型：
AUTH-OPTION-TYPE value 9 has been defined by IANA. An 8-bit identifier of the type mobility option.
IANA已定义AUTH-OPTION-TYPE值9。移动选项类型的8位标识符。
Option Length:
选项长度：
8-bit unsigned integer, representing the length in octets of the Subtype, mobility Security Parameter Index (SPI) and Authentication Data fields.
8位无符号整数，表示子类型、移动安全参数索引（SPI）和身份验证数据字段的长度（以八位字节为单位）。
Subtype:
子类型：
A number assigned to identify the entity and/or mechanism to be used to authenticate the message.
分配用于标识用于验证消息的实体和/或机制的编号。
Mobility SPI:
流动性SPI：
Mobility Security Parameter Index
移动安全参数索引
Authentication Data:
身份验证数据：
This field has the information to authenticate the relevant mobility entity. This protects the message beginning at the Mobility Header up to and including the mobility SPI field.
该字段具有验证相关移动实体的信息。这将保护从移动报头开始直到并包括移动SPI字段的消息。
Alignment requirements :
定线要求：
The alignment requirement for this option is 4n + 1.
该选项的对齐要求为4n+1。
The format of the MN-HA mobility message authentication option is as defined in Figure 2. This option uses the subtype value of 1. The MN-HA mobility message authentication option is used to authenticate the Binding Update and Binding Acknowledgement messages based on the shared-key-based security association between the Mobile Node and the Home Agent.
MN-HA移动消息认证选项的格式如图2所示。此选项使用子类型值1。MN-HA移动消息认证选项用于基于移动节点和归属代理之间基于共享密钥的安全关联来认证绑定更新和绑定确认消息。
The shared-key-based mobility security association between Mobile Node and Home Agent used within this specification consists of a mobility SPI, a key, an authentication algorithm, and the replay protection mechanism in use. The mobility SPI is a number in the range [0-4294967296], where the range [0-255] is reserved. The key consists of an arbitrary value and is 16 octets in length. The authentication algorithm is HMAC_SHA1. The replay protection mechanism may use the Sequence number as specified in [RFC3775] or the Timestamp option as defined in Section 6. If the Timestamp option is used for replay protection, the mobility security association includes a "close enough" field to account for clock drift. A default value of 7 seconds SHOULD be used. This value SHOULD be greater than 3 seconds.
本规范中使用的移动节点和归属代理之间基于共享密钥的移动安全关联包括移动SPI、密钥、认证算法和使用中的重播保护机制。移动SPI是范围[0-4294967296]内的一个数字，其中范围[0-255]是保留的。密钥由任意值组成，长度为16个八位字节。认证算法是HMAC_SHA1。重播保护机制可使用[RFC3775]中规定的序列号或第6节中定义的时间戳选项。如果时间戳选项用于重播保护，则移动安全关联包括一个“足够近”字段，以说明时钟漂移。应使用默认值7秒。该值应大于3秒。
The MN-HA mobility message authentication option MUST be the last option in a message with a mobility header if it is the only mobility message authentication option in the message.
如果MN-HA移动消息认证选项是消息中唯一的移动消息认证选项，则它必须是具有移动报头的消息中的最后一个选项。
The authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option.
在消息上计算认证数据，该消息从移动性报头开始，直到并包括该选项的移动性SPI值。
Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility Data))
认证数据=第一（96，HMAC_SHA1（MN-HA共享密钥，移动数据））
Mobility Data = care-of address | home address | Mobility Header (MH) Data
移动性数据=转交地址|家庭地址|移动性报头（MH）数据
MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option. The Checksum field in the Mobility Header MUST be set to 0 to calculate the Mobility Data.
MH数据是移动报头的内容，包括该选项的移动SPI字段。移动报头中的校验和字段必须设置为0以计算移动数据。
The first 96 bits from the Message Authentication Code (MAC) result are used as the Authentication Data field.
消息认证码（MAC）结果的前96位用作认证数据字段。
The assumption is that the Mobile Node has a shared-key-based security association with the Home Agent. The Mobile Node MUST include this option in a BU if it has a shared-key-based mobility security association with the Home Agent. The Home Agent MUST include this option in the BA if it received this option in the corresponding BU and Home Agent has a shared-key-based mobility security association with the Mobile Node.
假设移动节点与归属代理具有基于共享密钥的安全关联。如果移动节点与归属代理具有基于共享密钥的移动安全关联，则移动节点必须在BU中包括该选项。如果归属代理在相应的BU中接收到该选项，并且归属代理与移动节点具有基于共享密钥的移动安全关联，则归属代理必须在BA中包括该选项。
The Mobile Node or Home Agent receiving this option MUST verify the authentication data in the option. If authentication fails, the Home Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home Agent does not have shared-key-based mobility SA, Home Agent MUST discard the BU. The Home Agent MAY log such events.
接收此选项的移动节点或归属代理必须验证选项中的身份验证数据。如果身份验证失败，则归属代理必须发送状态代码为MIPV6-AUTH-FAIL的BA。如果归属代理没有基于共享密钥的移动SA，则归属代理必须放弃BU。归属代理可以记录此类事件。
The format of the MN-AAA mobility message authentication option is as defined in Figure 2. This option uses the subtype value of 2. The MN-AAA authentication mobility option is used to authenticate the Binding Update message based on the shared mobility security association between the Mobile Node and AAA server in Home network (AAAH). It is not used in Binding Acknowledgement messages. The corresponding Binding Acknowledgement messages must be authenticated using the MN-HA mobility message authentication option (Section 5.1).
MN-AAA移动消息认证选项的格式如图2所示。此选项使用子类型值2。MN-AAA认证移动选项用于基于移动节点和家庭网络中AAA服务器（AAAH）之间的共享移动安全关联来认证绑定更新消息。它不用于绑定确认消息。必须使用MN-HA移动消息认证选项（第5.1节）对相应的绑定确认消息进行认证。
The MN-AAA mobility message authentication option must be the last option in a message with a mobility header. The corresponding response MUST include the MN-HA mobility message authentication option, and MUST NOT include the MN-AAA mobility message authentication option.
MN-AAA移动消息身份验证选项必须是具有移动报头的消息中的最后一个选项。相应的响应必须包括MN-HA移动消息认证选项，并且不得包括MN-AAA移动消息认证选项。
The Mobile Node MAY use the Mobile Node Identifier option [RFC4283] to enable the Home Agent to make use of available AAA infrastructure.
移动节点可以使用移动节点标识符选项[RFC4283]来使归属代理能够利用可用的AAA基础设施。
The authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option.
在消息上计算认证数据，该消息从移动性报头开始，直到并包括该选项的移动性SPI值。
The authentication data shall be calculated as follows:
认证数据的计算方法如下：
Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data)
身份验证数据=哈希值fn（MN-AAA共享密钥，MAC移动数据）
hash_fn() is decided by the value of mobility SPI field in the MN-AAA mobility message authentication option.
hash_fn（）由MN-AAA移动消息身份验证选项中移动SPI字段的值决定。
SPI = HMAC_SHA1_SPI:
SPI=HMAC_SHA1_SPI：
If mobility SPI has the well-known value HMAC_SHA1_SPI, then hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is authenticated by AAA using HMAC_SHA1 authentication. In that case, MAC_Mobility Data is calculated as follows:
如果mobility SPI具有众所周知的值HMAC_SHA1_SPI，那么hash_fn（）就是HMAC_SHA1。当使用HMAC_SHA1_SPI时，BU由AAA使用HMAC_SHA1身份验证进行身份验证。在这种情况下，MAC_移动性数据计算如下：
MAC_Mobility Data = SHA1(care-of address | home address | MH Data)
MAC|U移动数据=SHA1（托管地址|家庭地址| MH数据）
MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option.
MH数据是移动报头的内容，包括该选项的移动SPI字段。
The use of the MN-AAA mobility message authentication option assumes that AAA entities at the home site communicate with the HA via an authenticated channel. Specifically, a BU with the MN-AAA mobility message authentication option is authenticated via a home AAA server. The specific details of the interaction between the HA and the AAA server is beyond the scope of this document.
MN-AAA移动消息认证选项的使用假设主站点上的AAA实体通过认证信道与HA通信。具体而言，通过家庭AAA服务器对具有MN-AAA移动消息认证选项的BU进行认证。HA和AAA服务器之间交互的具体细节超出了本文档的范围。
When the Home Agent receives a Binding Update with the MN-AAA mobility message authentication option, the Binding Update is authenticated by an entity external to the Home Agent, typically a AAA server.
当归属代理接收到具有MN-AAA移动消息认证选项的绑定更新时，绑定更新由归属代理外部的实体（通常是AAA服务器）认证。
In case of authentication failure, the Home Agent MUST send a Binding Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node, if a shared-key-based mobility security association to be used between Mobile Node and Home Agent for authentication exists. If there is no shared-key-based mobility security association, HA drops the Binding Update. HA may log the message for administrative action.
在认证失败的情况下，如果移动节点和归属代理之间存在用于认证的基于共享密钥的移动安全关联，则归属代理必须向移动节点发送状态代码为MIPV6-AUTH-FAIL的绑定确认。如果没有基于共享密钥的移动安全关联，HA将删除绑定更新。医管局可记录该消息以采取行政行动。
Upon receiving a Binding Acknowledgement with status code MIPV6- AUTH-FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the Home Agent.
在收到状态代码为MIPV6-AUTH-FAIL的绑定确认后，移动节点应停止向归属代理发送新的绑定更新。
The Mobility message replay protection option MAY be used in Binding Update/Binding Acknowledgement messages when authenticated using the mobility message authentication option as described in Section 5.
当使用第5节中描述的移动消息认证选项进行认证时，移动消息重放保护选项可用于绑定更新/绑定确认消息。
The mobility message replay protection option is used to let the Home Agent verify that a Binding Update has been freshly generated by the Mobile Node and not replayed by an attacker from some previous Binding Update. This is especially useful for cases where the Home Agent does not maintain stateful information about the Mobile Node after the binding entry has been removed. The Home Agent does the replay protection check after the Binding Update has been authenticated. The mobility message replay protection option when included is used by the Mobile Node for matching BA with BU.
mobility message replay protection（移动消息重播保护）选项用于让归属代理验证绑定更新是由移动节点新生成的，而不是由攻击者从以前的某个绑定更新中重播的。这对于在移除绑定条目后归属代理不维护关于移动节点的有状态信息的情况特别有用。归属代理在绑定更新经过身份验证后执行重播保护检查。移动节点使用包括的移动消息重放保护选项来匹配BA和BU。
If this mode of replay protection is used, it needs to be part of the shared-key-based mobility security association.
如果使用这种重播保护模式，它需要成为基于共享密钥的移动安全关联的一部分。
If the policy at Home Agent mandates replay protection using this option (as opposed to the sequence number in the Mobility Header in Binding Update) and the Binding Update from the Mobile Node does not include this option, the Home Agent discards the BU and sets the Status Code in BA to MIPV6-MESG-ID-REQD.
如果本地代理的策略使用此选项强制重播保护（与绑定更新中移动标头中的序列号相反），并且来自移动节点的绑定更新不包括此选项，则本地代理将丢弃BU，并将BA中的状态代码设置为MIPV6-MESG-ID-REQD。
When the Home Agent receives the mobility message replay protection option in Binding Update, it MUST include the mobility message replay protection option in Binding Acknowledgement. Appendix A provides details regarding why the mobility message replay protection option MAY be used when using the authentication option.
当归属代理在绑定更新中接收到移动消息重放保护选项时，它必须在绑定确认中包括移动消息重放保护选项。附录A提供了有关在使用身份验证选项时为什么可以使用移动消息重播保护选项的详细信息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Mobility Message Replay Protection Option
图3：移动消息重播保护选项
Option Type:
选项类型：
MESG-ID-OPTION-TYPE value 10 has been defined by IANA. An 8-bit identifier of the type mobility option.
IANA已定义MESG-ID-OPTION-TYPE值10。移动选项类型的8位标识符。
Option Length:
选项长度：
8-bit unsigned integer, representing the length in octets of the Timestamp field.
8位无符号整数，表示时间戳字段的长度（以八位字节为单位）。
Timestamp:
时间戳：
This field carries the 64 bit timestamp.
此字段带有64位时间戳。
Alignment requirements :
定线要求：
The alignment requirement for this option is 8n + 2.
该选项的对齐要求为8n+2。
The basic principle of timestamp replay protection is that the node generating a message inserts the current time of day, and the node receiving the message checks that this timestamp is sufficiently close to its own time of day. Unless specified differently in the shared-key-based mobility security association between the nodes, a default value of 7 seconds MAY be used to limit the time difference. This value SHOULD be greater than 3 seconds. The two nodes must have adequately synchronized time-of-day clocks.
时间戳重放保护的基本原理是，生成消息的节点插入当前时间，接收消息的节点检查该时间戳是否足够接近其自己的时间。除非在节点之间基于共享密钥的移动安全关联中不同地指定，否则可以使用7秒的默认值来限制时间差。该值应大于3秒。这两个节点必须具有充分同步的时钟。
The Mobile Node MUST set the Timestamp field to a 64-bit value formatted as specified by the Network Time Protocol (NTP) [RFC1305]. The low-order 32 bits of the NTP format represent fractional seconds, and those bits that are not available from a time source SHOULD be generated from a good source of randomness. Note, however, that when using timestamps, the 64-bit timestamp used in a Binding Update from the Mobile Node MUST be greater than that used in any previous successful Binding Update.
移动节点必须将时间戳字段设置为网络时间协议（NTP）[RFC1305]指定格式的64位值。NTP格式的低阶32位表示分数秒，时间源中不可用的那些位应该从良好的随机性源中生成。但是，请注意，当使用时间戳时，来自移动节点的绑定更新中使用的64位时间戳必须大于任何先前成功的绑定更新中使用的时间戳。
After successful authentication of Binding Update (either locally at the Home Agent or when a success indication is received from the AAA server), the Home Agent MUST check the Timestamp field for validity. In order to be valid, the timestamp contained in the Timestamp field MUST be close enough to the Home Agent's time-of-day clock and the timestamp MUST be greater than all previously accepted timestamps for the requesting Mobile Node.
成功验证绑定更新后（在归属代理本地或从AAA服务器接收到成功指示时），归属代理必须检查时间戳字段的有效性。为了有效，时间戳字段中包含的时间戳必须足够接近归属代理的时间时钟，并且时间戳必须大于请求移动节点先前接受的所有时间戳。
If the timestamp is valid, the Home Agent copies the entire Timestamp field into the Timestamp field in the BA it returns to the Mobile Node. If the timestamp is not valid, the Home Agent copies only the low-order 32 bits into the BA, and supplies the high-order 32 bits from its own time of day.
如果时间戳有效，则归属代理将整个时间戳字段复制到其返回给移动节点的BA中的时间戳字段中。如果时间戳无效，归属代理仅将低阶32位复制到BA中，并从其自己的时间提供高阶32位。
If the Timestamp field is not valid but the authentication of the BU succeeds, the Home Agent MUST send a Binding Acknowledgement with status code MIPV6-ID-MISMATCH. The Home Agent does not create a binding cache entry if the timestamp check fails.
如果时间戳字段无效，但BU的身份验证成功，则归属代理必须发送状态代码为MIPV6-ID-MISMATCH的绑定确认。如果时间戳检查失败，则归属代理不会创建绑定缓存项。
If the Mobile Node receives a Binding Acknowledgement with the code MIPV6-ID-MISMATCH, the Mobile Node MUST authenticate the BA by processing the MN-HA authentication mobility option.
如果移动节点接收到代码为MIPV6-ID-MISMATCH的绑定确认，则移动节点必须通过处理MN-HA认证移动选项来认证BA。
If authentication succeeds, the Mobile Node MUST adjust its timestamp and send subsequent Binding Update using the updated value.
如果认证成功，移动节点必须调整其时间戳，并使用更新的值发送后续绑定更新。
Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH status code, the Mobile Node MUST compare the Timestamp value in the BA to the Timestamp value it sent in the corresponding BU. If the values match, the Mobile Node proceeds to process the MN-HA authentication data in the BA. If the values do not match, the Mobile Node silently discards the BA.
在接收到不包含MIPV6-ID-MISMATCH状态代码的BA时，移动节点必须将BA中的时间戳值与它在相应的BU中发送的时间戳值进行比较。如果值匹配，则移动节点继续处理BA中的MN-HA认证数据。如果这些值不匹配，移动节点将自动丢弃BA。
This document proposes new mobility message authentication options to authenticate the control message between Mobile Node, Home Agent, and/or home AAA (as an alternative to IPsec). The new options provide for authentication of Binding Update and Binding Acknowledgement messages. The MN-AAA mobility message authentication option provide for authentication with AAA infrastructure.
本文档提出了新的移动消息认证选项，用于认证移动节点、归属代理和/或归属AAA（作为IPsec的替代方案）之间的控制消息。新选项提供了绑定更新和绑定确认消息的身份验证。MN-AAA移动消息认证选项提供AAA基础设施的认证。
This specification also introduces an optional replay protection mechanism in Section 6, to prevent replay attacks. The sequence number field in the Binding Update is not used if this mechanism is used. This memo defines the timestamp option to be used for mobility message replay protection.
本规范还在第6节中引入了可选的重播保护机制，以防止重播攻击。如果使用此机制，则不使用绑定更新中的序列号字段。此备忘录定义了用于移动消息重播保护的时间戳选项。
IANA services are required for this specification. The values for new mobility options and status codes must be assigned from the Mobile IPv6 [RFC3775] numbering space.
本规范要求IANA服务。新移动选项和状态代码的值必须从移动IPv6[RFC3775]编号空间分配。
The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID-OPTION-TYPE, as defined in Section 5 and Section 6, have been assigned. The values are 9 for the AUTH-OPTION-TYPE and 10 for the MESG-ID-OPTION-TYPE Mobility Option.
已分配第5节和第6节中定义的移动选项类型AUTH-Option-TYPE和MESG-ID-Option-TYPE的值。AUTH-OPTION-TYPE的值为9，MESG-ID-OPTION-TYPE移动选项的值为10。
The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL, and MIPV6-MESG-ID-REQD, as defined in Section 6 and Section 5.3, have been assigned. The values are 144 for MIPV6-ID-MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL.
已分配第6节和第5.3节中定义的状态代码MIPV6-ID-Mitch、MIPV6 AUTH FAIL和MIPV6-MESG-ID-REQD的值。MIPV6-ID-MITCH的值为144，MIPV6-MESG-ID-REQD的值为145，MIPV6-AUTH-FAIL的值为146。
A new section for enumerating algorithms identified by specific mobility SPIs within the range 0-255 has to be added to
必须添加一个新的部分，用于枚举0-255范围内特定移动性SPI识别的算法
http://www.iana.org/assignments/mobility-parameters
http://www.iana.org/assignments/mobility-parameters
The currently defined values are as follows:
当前定义的值如下所示：
The value 0 should not be assigned.
不应指定值0。
The value 3 is reserved for HMAC_SHA1_SPI as defined in Section 5.2.
值3为第5.2节中定义的HMAC_SHA1_SPI保留。
The value 5 is reserved for use by 3GPP2.
值5保留供3GPP2使用。
New values for this namespace can be allocated using IETF Consensus. [RFC2434].
可以使用IETF共识分配此命名空间的新值。[RFC2434]。
In addition, IANA has created a new namespace for the Subtype field of the MN-HA and MN-AAA mobility message authentication options under
此外，IANA还为下的MN-HA和MN-AAA移动消息身份验证选项的子类型字段创建了一个新名称空间
http://www.iana.org/assignments/mobility-parameters
http://www.iana.org/assignments/mobility-parameters
The currently allocated values are as follows:
当前分配的值如下所示：
1 MN-HA mobility message authentication option Section 5.1
1 MN-HA移动消息认证选项第5.1节
2 MN-AAA mobility message authentication option Section 5.2
2 MN-AAA移动消息认证选项第5.2节
New values for this namespace can be allocated using IETF Consensus. [RFC2434].
可以使用IETF共识分配此命名空间的新值。[RFC2434]。
The authors would like to thank Basavaraj Patil, Charlie Perkins, Vijay Devarapalli, Jari Arkko, and Gopal Dommety, and Avi Lior for their thorough review and suggestions on the document. The authors would like to acknowledge the fact that a similar authentication method was considered in base protocol [RFC3775] at one time.
作者要感谢Basavaraj Patil、Charlie Perkins、Vijay Devarapalli、Jari Arkko和Gopal Dommety以及Avi Lior对该文件的全面审查和建议。作者希望承认，在基本协议[RFC3775]中曾考虑过类似的身份验证方法。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, November 2005.
[RFC4283]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6的移动节点标识符选项”，RFC 4283，2005年11月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（版本3）规范，实施”，RFC1305，1992年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[3GPP2] "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D, September 2005.
[3GPP2]“cdma2000无线IP网络标准”，3GPP2 X.S0011-D，2005年9月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility header to prevent replay attacks. There are two aspects that stand out in regards to using the Sequence Number to prevent replay attacks.
移动IPv6[RFC3775]在移动报头中定义了一个序列号，以防止重播攻击。关于使用序列号防止重播攻击，有两个方面非常突出。
First, the specification states that the Home Agent should accept a BU with a Sequence Number greater than the Sequence Number from the previous Binding Update. This implicitly assumes that the Home Agent has some information regarding the Sequence Number from the previous BU (even when the binding cache entry is not present). Second, the specification states that if the Home Agent has no binding cache entry for the indicated home address, it MUST accept any Sequence Number value in a received Binding Update from this Mobile Node.
首先，规范规定归属代理应接受序列号大于先前绑定更新序列号的BU。这隐式地假设归属代理具有关于来自上一个BU的序列号的一些信息（即使绑定缓存条目不存在）。其次，该规范规定，如果归属代理对于所指示的归属地址没有绑定缓存条目，则它必须接受从该移动节点接收的绑定更新中的任何序列号值。
With the mechanism defined in this document, it is possible for the Mobile Node to register with a different Home Agent during each mobility session. Thus, it is unreasonable to expect each Home Agent in the network to maintain state about the Mobile Node. Also, if the Home Agent does not cache information regarding sequence number, as per the second point above, a replayed BU can cause a Home Agent to create a binding cache entry for the Mobile Node. Thus, when authentication option is used, Sequence Number does not provide protection against replay attack.
利用本文中定义的机制，移动节点可以在每个移动会话期间向不同的归属代理注册。因此，期望网络中的每个归属代理保持关于移动节点的状态是不合理的。此外，如果归属代理不缓存关于序列号的信息，则根据上面的第二点，重播的BU可以导致归属代理为移动节点创建绑定缓存条目。因此，当使用身份验证选项时，序列号不提供防止重播攻击的保护。
One solution to this problem (when the Home Agent does not save state information for every Mobile Node) would be for the Home Agent to reject the first BU and assign a (randomly generated) starting sequence number for the session and force the Mobile Node to send a fresh BU with the suggested sequence number. While this would work in most cases, it would require an additional round trip, and this extra signaling and latency is not acceptable in certain deployments [3GPP2]. Also, this rejection and using sequence number as a nonce in rejection is a new behavior that is not specified in [RFC3775].
该问题的一个解决方案（当归属代理不保存每个移动节点的状态信息时）是归属代理拒绝第一个BU并为会话分配（随机生成的）开始序列号，并强制移动节点发送具有建议序列号的新BU。虽然这在大多数情况下都有效，但它需要额外的往返，并且这种额外的信令和延迟在某些部署中是不可接受的[3GPP2]。此外，这种拒绝以及在拒绝中使用序列号作为nonce是[RFC3775]中未指定的新行为。
Thus, this specification uses the mobility message replay protection option to prevent replay attacks. Specifically, timestamps are used to prevent replay attacks as described in Section 6.
因此，本规范使用移动消息重播保护选项来防止重播攻击。具体而言，时间戳用于防止重播攻击，如第6节所述。
It is important to note that as per Mobile IPv6 [RFC3775] this problem with sequence number exists. Since the base specification mandates the use of IPsec (and naturally that goes with IKE in most cases), the real replay protection is provided by IPsec/IKE. In case of BU/BA between Mobile Node and Client Node (CN), the liveness proof is provided by the use of nonces that the CN generates.
需要注意的是，根据移动IPv6[RFC3775]，序列号存在此问题。由于基本规范要求使用IPsec（在大多数情况下，IKE自然会使用IPsec），因此真正的重播保护由IPsec/IKE提供。在移动节点和客户端节点（CN）之间存在BU/BA的情况下，通过使用CN生成的nonce来提供活动性证明。
Authors' Addresses
作者地址
Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
美国加利福尼亚州圣何塞塔斯曼大道西170号阿尔佩什帕特尔思科系统公司，邮编95134
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Phone: +1 408-853-9580
EMail: alpesh@cisco.com
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
美国加利福尼亚州圣何塞塔斯曼大道西170号肯特梁思科系统公司，邮编95134
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
Mohamed Khalil Nortel Networks 2221 Lakeside Blvd。德克萨斯州理查森75082美国
Phone: +1 972-685-0574
EMail: mkhalil@nortel.com
Phone: +1 972-685-0574
EMail: mkhalil@nortel.com
Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
Haseeb Akhtar Nortel Networks 2221湖滨大道。德克萨斯州理查森75082美国
Phone: +1 972-684-4732
EMail: haseebak@nortel.com
Phone: +1 972-684-4732
EMail: haseebak@nortel.com
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US
Kuntal Chowdhury Starent Networks美国马萨诸塞州托克斯伯里国际广场30号01876
Phone: +1 214 550 1416
EMail: kchowdhury@starentnetworks.com
Phone: +1 214 550 1416
EMail: kchowdhury@starentnetworks.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。