Network Working Group G. Tsirtsis
Request for Comments: 5454 V. Park
Category: Standards Track Qualcomm
H. Soliman
Elevate Technologies
March 2009
Network Working Group G. Tsirtsis
Request for Comments: 5454 V. Park
Category: Standards Track Qualcomm
H. Soliman
Elevate Technologies
March 2009
Dual-Stack Mobile IPv4
双栈移动IPv4
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual-stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures.
本规范提供了移动IPv4协议的IPv6扩展。扩展允许双栈节点使用IPv4和IPv6主地址，以及在IPv4和双栈网络基础架构之间移动。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Notation ......................................3
1.2. Goals ......................................................3
1.3. Non-Goals ..................................................4
1.4. Implicit and Explicit Modes ................................4
2. Extension Formats ...............................................4
2.1. IPv6 Prefix Request Extension ..............................4
2.2. IPv6 Prefix Reply Extension ................................5
2.3. IPv6 Tunneling Mode Extension ..............................7
3. Mobile IP Registrations .........................................8
3.1. Registration Request .......................................8
3.2. Registration Reply .........................................8
3.3. Home Agent Considerations ..................................9
3.3.1. IPv6 Reachability ..................................10
3.3.2. Processing Intercepted IPv6 Packets ................10
3.3.3. IPv6 Multicast Membership Control ..................12
3.4. Foreign Agent Considerations ..............................12
3.5. Mobile Node Considerations ................................12
3.6. Tunneling Impacts .........................................13
3.7. IPv6 Prefixes .............................................14
3.7.1. Dynamic IPv6 Prefix Delegation .....................14
3.8. Deregistration of IPv6 Prefix .............................15
3.9. Registration with a Private CoA ...........................15
4. Security Considerations ........................................15
5. IANA Considerations ............................................16
6. Acknowledgements ...............................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
1. Introduction ....................................................3
1.1. Requirements Notation ......................................3
1.2. Goals ......................................................3
1.3. Non-Goals ..................................................4
1.4. Implicit and Explicit Modes ................................4
2. Extension Formats ...............................................4
2.1. IPv6 Prefix Request Extension ..............................4
2.2. IPv6 Prefix Reply Extension ................................5
2.3. IPv6 Tunneling Mode Extension ..............................7
3. Mobile IP Registrations .........................................8
3.1. Registration Request .......................................8
3.2. Registration Reply .........................................8
3.3. Home Agent Considerations ..................................9
3.3.1. IPv6 Reachability ..................................10
3.3.2. Processing Intercepted IPv6 Packets ................10
3.3.3. IPv6 Multicast Membership Control ..................12
3.4. Foreign Agent Considerations ..............................12
3.5. Mobile Node Considerations ................................12
3.6. Tunneling Impacts .........................................13
3.7. IPv6 Prefixes .............................................14
3.7.1. Dynamic IPv6 Prefix Delegation .....................14
3.8. Deregistration of IPv6 Prefix .............................15
3.9. Registration with a Private CoA ...........................15
4. Security Considerations ........................................15
5. IANA Considerations ............................................16
6. Acknowledgements ...............................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
Mobile IPv4 [RFC3344] allows a mobile node with an IPv4 address to maintain communications while moving in an IPv4 network.
移动IPv4[RFC3344]允许具有IPv4地址的移动节点在IPv4网络中移动时保持通信。
Extensions defined in this document allow a node that has IPv4 and IPv6 addresses [RFC2460] to maintain communications through any of its addresses while moving in IPv4 or dual stack networks.
本文档中定义的扩展允许具有IPv4和IPv6地址[RFC2460]的节点在IPv4或双栈网络中移动时通过其任何地址保持通信。
Essentially, this specification separates the Mobile IPv4 signaling from the IP version of the traffic it tunnels. Mobile IPv4 with the present extensions remains a signaling protocol that runs over IPv4, and yet can set up both IPv4 and IPv6 tunnels over IPv4.
本质上，该规范将移动IPv4信令与它所隧道的流量的IP版本分开。具有当前扩展的移动IPv4仍然是一种在IPv4上运行的信令协议，但可以在IPv4上设置IPv4和IPv6隧道。
The aim is two-fold:
目标有两个方面：
On one hand, Mobile IPv4 with the present extensions becomes a useful transition mechanism, allowing automated but controlled tunneling of IPv6 traffic over IPv4 tunnels. Dual-stack nodes in dual-stack home networks can now roam to and from legacy IPv4 networks, while IPv4 mobile nodes and networks can migrate to IPv6 without changing mobility management, and without upgrading all network nodes to IPv6 at once.
一方面，具有当前扩展的移动IPv4成为一种有用的转换机制，允许通过IPv4隧道对IPv6流量进行自动但受控的隧道传输。双栈家庭网络中的双栈节点现在可以往返于传统IPv4网络，而IPv4移动节点和网络可以迁移到IPv6，而无需更改移动性管理，也无需将所有网络节点一次性升级到IPv6。
On the other hand, and more importantly, it allows dual-stack mobile nodes and networks to utilize a single protocol for the movement of both IPv4 and IPv6 stacks in the network topology.
另一方面，更重要的是，它允许双栈移动节点和网络利用单个协议在网络拓扑中移动IPv4和IPv6栈。
Note that features like Mobile IPv6 [RFC3775] style route optimization will not be possible with this solution as it still relies on Mobile IPv4 signaling, which does not provide route optimization.
请注意，类似移动IPv6[RFC3775]样式的路由优化功能在该解决方案中不可能实现，因为它仍然依赖于移动IPv4信令，而移动IPv4信令不提供路由优化。
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]中所述进行解释。
a. The solution supports the registration of IPv6 home prefix(es) in addition to regular IPv4 home address (HoA) registration.
a. 除了常规IPv4家庭地址（HoA）注册外，该解决方案还支持IPv6家庭前缀的注册。
b. The solution supports static and dynamic IPv6 prefix delegation.
b. 该解决方案支持静态和动态IPv6前缀委派。
a. The solution does not provide support for IPv6 care-of address (CoA) registration.
a. 该解决方案不支持IPv6转交地址（CoA）注册。
As defined in Network Mobility (NEMO) [RFC3963], this specification also supports two modes of operation; the implicit mode and the explicit mode.
如网络移动性（NEMO）[RFC3963]中所定义，本规范还支持两种操作模式；隐式模式和显式模式。
In the implicit mode, the mobile node does not include any IPv6 prefix request extensions in the registration request. The home agent can use any mechanism (not defined in this document) to determine the IPv6 prefix(es) owned by the mobile node and to set up forwarding for these prefixes. In this mode of operation, all traffic to and from the IPv6 prefixes MUST be encapsulated over the IPv4 tunnel between the mobile node's IPv4 home address and the IPv4 address of the home agent, and as such, it is transparent to any foreign agent in the path. This IPv4 tunnel is established by mechanisms that are out of the scope of this document on both the mobile node and home agent when operating in the implicit mode.
在隐式模式下，移动节点在注册请求中不包括任何IPv6前缀请求扩展。归属代理可以使用任何机制（本文档中未定义）来确定移动节点拥有的IPv6前缀，并为这些前缀设置转发。在这种操作模式下，进出IPv6前缀的所有流量必须通过IPv4隧道封装在移动节点的IPv4主地址和归属代理的IPv4地址之间，因此，它对路径中的任何外部代理都是透明的。当以隐式模式操作时，此IPv4隧道由移动节点和归属代理上不在本文档范围内的机制建立。
In the explicit mode, IPv6 bindings are signaled explicitly. The mobile node includes one or more IPv6 prefix request extensions in the registration request, while the home agent returns corresponding IPv6 prefix reply extensions to accept/reject the IPv6 bindings.
在显式模式下，IPv6绑定会显式地发出信号。移动节点在注册请求中包括一个或多个IPv6前缀请求扩展，而归属代理返回相应的IPv6前缀应答扩展以接受/拒绝IPv6绑定。
Additionally, in the explicit mode, the mobile node (when co-located mode of operation is used) can indicate whether IPv6 traffic should be tunneled to the care-of address or the home address of the mobile node.
此外，在显式模式中，移动节点（当使用同一位置的操作模式时）可以指示IPv6通信量是否应该隧道到移动节点的转交地址或家庭地址。
The rest of this specification is primarily defining the explicit mode.
本规范的其余部分主要定义显式模式。
The following extensions are defined according to this specification.
以下扩展是根据本规范定义的。
A new skippable extension to the Mobile IPv4 registration request message in accordance to the short extension format of [RFC3344] is defined here.
此处定义了符合[RFC3344]短扩展格式的移动IPv4注册请求消息的新可跳过扩展。
This extension contains a Mobile IPv6 network prefix and its prefix length.
此扩展包含移动IPv6网络前缀及其前缀长度。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile IPv6 Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile IPv6 Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 Prefix Request Extension
图1:IPv6前缀请求扩展
Type
类型
152 (Dual-Stack Mobile IPv4 (DSMIPv4) Extension)
152（双栈移动IPv4（DSMPv4）扩展）
Length
长
18
18
Subtype
亚型
1 (IPv6 Prefix Request)
1（IPv6前缀请求）
Prefix Length
前缀长度
A sixteen-byte field containing the Mobile IPv6 Network Prefix; all insignificant (low-order) bits (beyond the Prefix Length) MUST be set to 0 by the originator of the option and ignored by the receiver.
包含移动IPv6网络前缀的16字节字段；所有不重要（低阶）位（超出前缀长度）必须由选项的发起人设置为0，并由接收方忽略。
Mobile IPv6 Network Prefix
移动IPv6网络前缀
A sixteen-byte field containing the Mobile IPv6 Network Prefix
包含移动IPv6网络前缀的16字节字段
A new skippable extension to the Mobile IPv4 registration reply message in accordance to the short extension format of [RFC3344] is defined here.
此处定义了符合[RFC3344]短扩展格式的移动IPv4注册回复消息的新可跳过扩展。
This extension defines a Mobile IPv6 Network Prefix and its prefix length, as well as a code.
此扩展定义移动IPv6网络前缀及其前缀长度以及代码。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Mobile IPv6 Network Prefix +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Mobile IPv6 Network Prefix +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 Prefix Reply Extension
图2:IPv6前缀应答扩展
Type
类型
152 (DSMIPv4 Extension)
152（IPv4扩展）
Length
长
20
20
Subtype
亚型
2 (IPv6 Prefix Reply)
2（IPv6前缀应答）
Code
密码
A value indicating the result of the registration request with respect to the IPv6 home prefix registration. See below for currently defined Codes.
一个值，指示与IPv6主前缀注册相关的注册请求的结果。有关当前定义的代码，请参见下文。
Prefix Length
前缀长度
Indicates the prefix length of the prefix included in the Mobile IPv6 Network Prefix field. A value of 255 indicates that a link-local address is included in the Mobile IPv6 Network Prefix field.
指示移动IPv6网络前缀字段中包含的前缀的前缀长度。值255表示链路本地地址包含在移动IPv6网络前缀字段中。
Reserved
含蓄的
Set to 0 by the sender, ignored by the receiver
发送方设置为0，接收方忽略
Mobile IPv6 Network Prefix
移动IPv6网络前缀
A sixteen-byte field containing the Mobile IPv6 Network Prefix; all insignificant (low-order) bits (beyond the Prefix Length) MUST be set to 0 by the originator of the option and ignored by the receiver.
包含移动IPv6网络前缀的16字节字段；所有不重要（低阶）位（超出前缀长度）必须由选项的发起人设置为0，并由接收方忽略。
The following values are defined for use as a Code value in the above extension:
以下值定义为在上述扩展中用作代码值：
0 registration accepted, IPv6 to be tunneled to HoA
0注册已接受，IPv6将通过隧道传输到HoA
1 registration accepted, IPv6 to be tunneled to CoA
1个注册已接受，IPv6将通过隧道传输至CoA
8 registration rejected, reason unspecified
8注册被拒绝，原因不明
9 registration rejected, administratively prohibited
9注册被拒绝，行政禁止
Note that a registration reply that does not include an IPv6 prefix reply extension, when received in response to a registration request carrying at least one instance of the IPv6 prefix request extension, indicates that the home agent does not support IPv6 extensions and thus has ignored such extensions in the registration request.
注意，当响应包含至少一个IPv6前缀请求扩展实例的注册请求而接收到不包括IPv6前缀回复扩展的注册回复时，表示归属代理不支持IPv6扩展，因此在注册请求中忽略了此类扩展。
A new skippable extension to the Mobile IPv4 registration request message in accordance to the short extension format of [RFC3344] is defined here.
此处定义了符合[RFC3344]短扩展格式的移动IPv4注册请求消息的新可跳过扩展。
By including this extension in a registration request, the sender indicates that IPv6 traffic can be tunneled to the mobile node's CoA.
通过在注册请求中包含此扩展，发送方表示IPv6流量可以通过隧道传输到移动节点的CoA。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv6 Tunneling Mode Extension
图3:IPv6隧道模式扩展
Type
类型
152 (DSMIPv4 Extension)
152（IPv4扩展）
Length
长
2
2.
Subtype
亚型
3 (IPv6 Tunneling Mode)
3（IPv6隧道模式）
Reserved
含蓄的
Set to 0 by the sender, ignored by the receiver
发送方设置为0，接收方忽略
A mobile node MAY include in a registration request one or more IPv6 prefix request extensions defined in this specification.
移动节点可以在注册请求中包括本规范中定义的一个或多个IPv6前缀请求扩展。
A mobile node MAY also include exactly one IPv6 tunneling mode extension when it uses the co-located care-of address mode of [RFC3344].
当移动节点使用[RFC3344]的共址转交地址模式时，它还可以仅包括一个IPv6隧道模式扩展。
When IPv6 prefix and/or IPv6 tunneling mode extensions are used by the mobile IP client, they MUST be placed after the registration request header and before the mobile -- home authentication extension so they MUST be included in the computation of any authentication extension.
当移动IP客户端使用IPv6前缀和/或IPv6隧道模式扩展时，它们必须放在注册请求头之后，移动-家庭身份验证扩展之前，因此它们必须包含在任何身份验证扩展的计算中。
The mechanism described in this specification depends on skippable extensions. For that reason, a registration reply that does not include an IPv6 prefix reply extension, in response to a registration request including an IPv6 prefix request extension, indicates that the home agent does not support IPv6 extensions and has ignored the request.
本规范中描述的机制依赖于可跳过的扩展。因此，响应包括IPv6前缀请求扩展的注册请求，不包括IPv6前缀应答扩展的注册应答表示归属代理不支持IPv6扩展，并且已忽略该请求。
If an IPv6 prefix reply extension is included in a registration reply, then the extension indicates the success or failure of the IPv6 prefix registration. The IPv6 prefix reply extension does not affect, in any way, the code value in the registration reply header but it is superseded by it. In other words, if the code field in the registration reply header is set to a reject code, then all IPv6 prefix request extensions are also rejected. If the code field in the registration reply header, however, is set to an accept code,
如果注册回复中包含IPv6前缀回复扩展，则该扩展指示IPv6前缀注册的成功或失败。IPv6前缀回复扩展不会以任何方式影响注册回复标头中的代码值，但会被其取代。换句话说，如果注册回复标头中的代码字段设置为拒绝代码，则所有IPv6前缀请求扩展也将被拒绝。但是，如果注册回复标题中的代码字段设置为接受代码，
then an IPv6 prefix reply extension with a code field set to a reject code only rejects the binding for the specific IPv6 prefix indicated in the same extension.
然后，代码字段设置为拒绝代码的IPv6前缀应答扩展仅拒绝同一扩展中指定的特定IPv6前缀的绑定。
Note that a rejecting IPv6 prefix reply extension has the same effect as not including such an extension at all, in the sense that, in both cases, the mobile node must act as if the corresponding IPv6 prefix request extension included in the registration request was rejected. Of course, the inclusion of the IPv6 prefix reply extension allows the home agent to indicate why a given IPv6 prefix request extension was rejected. A detailed description of how the mobile node handles different IPv6 prefix reply extension code values and the absence of IPv6 prefix reply extensions is given in Section 3.5.
注意，拒绝IPv6前缀应答扩展与根本不包括这样的扩展具有相同的效果，在这两种情况下，移动节点必须像拒绝注册请求中包含的相应IPv6前缀请求扩展一样工作。当然，包含IPv6前缀应答扩展允许归属代理指示拒绝给定IPv6前缀请求扩展的原因。第3.5节详细描述了移动节点如何处理不同的IPv6前缀应答扩展代码值以及是否存在IPv6前缀应答扩展。
The dual-stack home agent defined in this specification is a Mobile IPv4 home agent in that, it MUST operate as defined in MIPv4 [RFC3344]. In addition to that, the following mechanisms are defined in this specification.
本规范中定义的双栈归属代理是移动IPv4归属代理，因为它必须按照MIPv4[RFC3344]中的定义进行操作。除此之外，本规范中还定义了以下机制。
For each IPv6 prefix request extension included in a valid registration request, a home agent that supports this specification SHOULD include a corresponding IPv6 prefix reply extension in the registration reply message. The home agent MUST NOT include more than one IPv6 prefix reply extension for the same prefix. For each accepted IPv6 prefix, the home agent MUST decide the tunneling mode it is going to use and set the code field of the IPv6 prefix reply extension to the appropriate value. The IPv6 prefix field of each of the IPv6 prefix reply extensions included in the registration reply MUST match the IPv6 prefix field of an IPv6 prefix request extension included in the corresponding registration request message.
对于有效注册请求中包含的每个IPv6前缀请求扩展，支持此规范的归属代理应在注册回复消息中包含相应的IPv6前缀回复扩展。归属代理不能为同一前缀包含多个IPv6前缀应答扩展。对于每个接受的IPv6前缀，归属代理必须决定它将要使用的隧道模式，并将IPv6前缀应答扩展的代码字段设置为适当的值。注册回复中包含的每个IPv6前缀回复扩展的IPv6前缀字段必须与相应注册请求消息中包含的IPv6前缀请求扩展的IPv6前缀字段匹配。
When the home agent sends a successful registration reply to the mobile node, with the code field of a corresponding IPv6 prefix reply extension set to one of the "registration accepted" values, the home agent indicates that the IPv6 prefix is registered for the lifetime granted for the binding. It also indicates the tunneling mode used i.e., tunneling to home address or care-of address, based on the value of the code field used in the IPv6 prefix reply extension.
当归属代理向移动节点发送成功的注册回复时，相应IPv6前缀回复扩展的代码字段设置为“注册已接受”值之一，归属代理指示已在为绑定授予的生存期内注册IPv6前缀。它还指示所使用的隧道模式，即根据IPv6前缀应答扩展中使用的代码字段的值，隧道到家庭地址或转交地址。
Note that since only IPv6 prefixes (and not addresses) are supported by this specification, there is no need for Duplicate Address Detection. The home agent, however, MUST check that registered prefixes are not overlapping so that all addresses under each registered prefix belong to a single mobile node at any one time. These prefixes MUST NOT appear as on-link to any other node (e.g., via Router Advertisements).
请注意，由于此规范只支持IPv6前缀（而不支持地址），因此不需要重复地址检测。然而，归属代理必须检查注册前缀是否重叠，以便每个注册前缀下的所有地址在任何时候都属于单个移动节点。这些前缀不得出现在任何其他节点的链接上（例如，通过路由器广告）。
For each registered IPv6 prefix, the home agent MUST advertise its reachability as defined in NEMO Section 6.3 of [RFC3963].
对于每个注册的IPv6前缀，归属代理必须公布其可达性，如[RFC3963]的NEMO第6.3节所定义。
A dual-stack home agent that supports the IPv6 extensions defined in this specification MUST keep track of the following IPv6 related state for the mobile nodes it supports, in addition to the state defined in [RFC3344].
除[RFC3344]中定义的状态外，支持本规范中定义的IPv6扩展的双栈归属代理必须跟踪其支持的移动节点的以下IPv6相关状态。
- Registered IPv6 prefix(es) and prefix length(s).
- 已注册IPv6前缀和前缀长度。
- Tunneling mode for IPv6 traffic:
- IPv6流量的隧道模式：
- Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA.
- 通过隧道连接到IPv4 HoA并接受从IPv4 HoA通过隧道连接的IPv6。
- Tunnel to CoA and accept IPv6 tunneled from CoA.
- 隧道到CoA并接受从CoA隧道传输的IPv6。
When IPv6 traffic is encapsulated over the tunnel between the home agent (HA) and the mobile node's care-of address, the tunneling mechanism used should be the same as the mechanism negotiated by the Mobile IP header as defined in MIPv4 [RFC3344]. In that case, when IPinIP encapsulation is negotiated, IPv6 is tunneled over IPv4 according to [RFC4213]. Generic Routing Encapsulation (GRE) also allows tunneling of IPv6 packets by setting the Protocol Type [RFC2784] field, to the appropriate payload type defined for IPv6 by IANA. Minimal Encapsulation [RFC2004] cannot be used, since the second (inner) IP header is IPv6, which is not supported by [RFC2004].
当IPv6通信通过归属代理（HA）和移动节点转交地址之间的隧道进行封装时，使用的隧道机制应与MIPv4[RFC3344]中定义的移动IP报头协商的机制相同。在这种情况下，当协商IPNIP封装时，IPv6将根据[RFC4213]通过IPv4进行隧道传输。通过将协议类型[RFC2784]字段设置为IANA为IPv6定义的适当有效负载类型，通用路由封装（GRE）还允许通过隧道传输IPv6数据包。无法使用最小封装[RFC2004]，因为第二个（内部）IP标头是IPv6，而[RFC2004]不支持该标头。
When IPv6 traffic is encapsulated over the tunnel between the HA and the mobile node's home address, IPv6 is always tunneled over IPv4 according to [RFC4213]. The resulting IPv4 packet is then delivered just like any other IPv4 packet addressed to the IPv4 HoA (using the tunneling for normal IPv4 traffic, possibly going via the foreign agent (FA)).
当IPv6通信量通过HA和移动节点的家庭地址之间的隧道进行封装时，根据[RFC4213]，IPv6始终通过IPv4进行隧道传输。然后，生成的IPv4数据包将像寻址到IPv4 HoA的任何其他IPv4数据包一样交付（使用正常IPv4流量的隧道，可能通过外部代理（FA））。
Tunneling mode selection for IPv6 traffic depends on the following parameters in a successful registration request:
IPv6流量的隧道模式选择取决于成功注册请求中的以下参数：
1) A registration request is received with one or more IPv6 prefix request extensions. An IPv6 tunneling mode extension is not included.
1) 接收到带有一个或多个IPv6前缀请求扩展的注册请求。不包括IPv6隧道模式扩展。
All IPv6 packets destined to the registered IPv6 prefix(es) MUST be tunneled by the home agent to the registered IPv4 home address of the mobile node. The home agent first encapsulates the IPv6 packet, addressing it to the mobile node's IPv4 home address, and then tunnels this encapsulated packet to the foreign agent. This extra level of encapsulation is required so that IPv6 routing remains transparent to a foreign agent that does not support IPv6. When received by the foreign agent, the unicast encapsulated packet is de-tunneled and delivered to the mobile node in the same way as any other packet. The mobile node must decapsulate the received IPv4 packet in order to recover the original IPv6 packet.
所有发往注册IPv6前缀的IPv6数据包必须由归属代理通过隧道传输到移动节点的注册IPv4归属地址。归属代理首先封装IPv6数据包，将其寻址到移动节点的IPv4归属地址，然后通过隧道将此封装数据包传输到外部代理。需要额外的封装级别，以便IPv6路由对不支持IPv6的外部代理保持透明。当外部代理接收到单播封装的分组时，单播封装的分组以与任何其他分组相同的方式被解隧道并传送到移动节点。移动节点必须解除接收到的IPv4数据包的封装，以便恢复原始IPv6数据包。
Additionally, the home agent MUST be prepared to accept reverse-tunneled packets from the IPv4 home address of the mobile node encapsulating IPv6 packets sent by that mobile node.
此外，归属代理必须准备好接受来自移动节点的IPv4归属地址的反向隧道数据包，该移动节点封装了该移动节点发送的IPv6数据包。
2) A registration request is received with one or more IPv6 prefix request extensions. An IPv6 tunneling mode extension is included.
2) 接收到带有一个或多个IPv6前缀请求扩展的注册请求。包括IPv6隧道模式扩展。
All IPv6 packets destined to the registered IPv6 prefix(es) SHOULD be tunneled by the home agent to the registered care-of address of the mobile node. Additionally, the home agent SHOULD be prepared to accept reverse-tunneled packets from the care-of address of the mobile node encapsulating IPv6 packets sent by that mobile node. The home agent MAY ignore the presence of the IPv6 tunneling mode extension and act as in case (1) above.
所有发往注册IPv6前缀的IPv6数据包应由归属代理通过隧道传输到移动节点的注册转交地址。此外，归属代理应当准备好接受来自移动节点的转交地址的反向隧道分组，该移动节点的转交地址封装了由该移动节点发送的IPv6分组。归属代理可以忽略IPv6隧道模式扩展的存在，并与上述情况（1）中的情况相同。
The home agent MUST check that all inner IPv6 packets received from the mobile node over a tunnel with the mobile node's home address or the care-of address as the outer source address, include a source address that falls under the registered IPv6 prefix(es) for that mobile node. If the source address of the outer header of a tunneled packet is not the registered IPv4 care-of address or the registered IPv4 home addresses, the packet SHOULD be dropped. If the source address of the inner header of an tunneled packet does not match any of the registered prefixes, the packet SHOULD be dropped.
归属代理必须检查通过隧道从移动节点接收的所有内部IPv6数据包（移动节点的归属地址或转交地址作为外部源地址）是否包含属于该移动节点的已注册IPv6前缀的源地址。如果隧道数据包的外部报头的源地址不是注册的IPv4转交地址或注册的IPv4主地址，则应丢弃该数据包。如果隧道数据包的内部报头的源地址与任何注册前缀都不匹配，则应丢弃该数据包。
Multicast packets addressed to a group to which the mobile node has successfully subscribed, MUST be tunneled to the mobile node.
发往移动节点已成功订阅的组的多播数据包必须通过隧道传输到移动节点。
IPv6 multicast membership control is provided as defined in MIPv6 [RFC3775], Section 10.4.3. The only clarification required for the purpose of this specification is that all Multicast Listener Discovery (MLD) [RFC2710] or MLDv2 [RFC3810] messages between the mobile node and the home agent MUST be tunneled over an IPv4 tunnel between the mobile node's IPv4 home address and the home agent's IPv4 address, bypassing the foreign agent. Note that if tunneling to the care-of address has been negotiated for other traffic, then the rest of the traffic continues using this tunnel.
IPv6多播成员资格控制按照MIPv6[RFC3775]第10.4.3节的定义提供。本规范要求的唯一澄清是，移动节点和归属代理之间的所有多播侦听器发现（MLD）[RFC2710]或MLDv2[RFC3810]消息必须绕过外部代理，通过移动节点的IPv4归属地址和归属代理的IPv4地址之间的IPv4隧道进行隧道传输。请注意，如果已为其他流量协商到转交地址的隧道，则其余流量将继续使用此隧道。
This specification does not affect the operation of the foreign agent.
本规范不影响外国代理的操作。
A dual-stack mobile node that supports the extensions described in this document MAY use these extensions to register its IPv6 prefix(es) while moving between access routers.
支持本文档中描述的扩展的双栈移动节点可以在访问路由器之间移动时使用这些扩展来注册其IPv6前缀。
The mobile node MAY include one or more IPv6 prefix request extension(s) in the registration request.
移动节点可以在注册请求中包括一个或多个IPv6前缀请求扩展。
In this case, the mobile node MUST take the following action depending on the extensions included in the registration reply it receives in response to the registration request:
在这种情况下，移动节点必须根据其在响应注册请求时接收到的注册回复中包括的扩展采取以下操作：
1) The registration reply does not include any IPv6 prefix reply extensions.
1) 注册回复不包括任何IPv6前缀回复扩展。
The mobile node MUST assume that the home agent does not support the extensions defined in this specification. The mobile node SHOULD continue to operate according to MIPv4 [RFC3344].
移动节点必须假设归属代理不支持本规范中定义的扩展。移动节点应根据MIPv4[RFC3344]继续运行。
2) The registration reply includes one or more IPv6 prefix reply extensions.
2) 注册回复包括一个或多个IPv6前缀回复扩展。
The mobile node MUST match each IPv6 prefix reply extension with one of the IPv6 prefix request extensions included earlier in the corresponding registration request message.
移动节点必须将每个IPv6前缀应答扩展与之前包含在相应注册请求消息中的一个IPv6前缀请求扩展相匹配。
If a matching IPv6 prefix reply extension is not included for one or more of corresponding IPv6 prefix request extensions included in the registration request message, the mobile node MUST assume that these IPv6 prefixes are rejected.
如果注册请求消息中包含的一个或多个相应IPv6前缀请求扩展未包含匹配的IPv6前缀应答扩展，则移动节点必须假定这些IPv6前缀被拒绝。
For each matching IPv6 prefix reply extension, the mobile node MUST inspect the code field. If the field is set to a rejection code, then the corresponding IPv6 prefix registration has been rejected. If the code field is set to an acceptance code, then the corresponding IPv6 prefix registration has been accepted.
对于每个匹配的IPv6前缀应答扩展，移动节点必须检查代码字段。如果该字段设置为拒绝代码，则相应的IPv6前缀注册已被拒绝。如果代码字段设置为接受代码，则相应的IPv6前缀注册已被接受。
If the code field is set to "0", then the mobile node MUST be prepared to send/receive IPv6 packets encapsulated in the bidirectional tunnel between the home agent address and the registered IPv4 home address of the mobile node.
如果代码字段设置为“0”，则移动节点必须准备发送/接收封装在归属代理地址和移动节点的注册IPv4归属地址之间的双向隧道中的IPv6数据包。
If the code field is set to "1", then the mobile node MUST act as follows:
如果代码字段设置为“1”，则移动节点必须按如下方式操作：
- Assuming the co-located care-of address mode is used, the mobile node MUST be prepared to send/receive IPv6 packets over the bidirectional tunnel between the home agent address and its co-located care-of address. Otherwise, the mobile node SHOULD act as in the case where the code field is set to "0".
- 假设使用了同位转交地址模式，移动节点必须准备好通过归属代理地址与其同位转交地址之间的双向隧道发送/接收IPv6数据包。否则，移动节点应与代码字段设置为“0”的情况相同。
The mobile node SHOULD include exactly one IPv6 tunneling mode extension if it uses the co-located care-of address model and it wants to request that IPv6 packets are tunneled to its co-located care-of address. If the mobile node uses the co-located care-of address model but it does not include the IPv6 tunneling mode extension, the home agent will tunnel IPv6 traffic to the mobile node's IPv4 home address. The mobile node MUST NOT include an IPv6 tunneling mode extension if it uses the foreign agent care-of address mode of operation. Note that if the mobile node includes an IPv6 tunneling mode extension in this case, IPv6 packets could be tunneled to the FA by the HA. The FA is then likely to drop them since it will not have appropriate state to process them.
如果移动节点使用同一位置的转交地址模型，并且希望请求将IPv6数据包通过隧道传输到其同一位置的转交地址，则移动节点应仅包括一个IPv6隧道模式扩展。如果移动节点使用共同定位的转交地址模型，但不包括IPv6隧道模式扩展，则归属代理将通过隧道将IPv6通信量传输到移动节点的IPv4归属地址。如果移动节点使用外部代理转交地址操作模式，则该移动节点不得包含IPv6隧道模式扩展。注意，在这种情况下，如果移动节点包括IPv6隧道模式扩展，则IPv6分组可以由HA隧道传输到FA。FA很可能会放弃它们，因为它没有适当的状态来处理它们。
When IPv6 runs over an IPv4 tunnel, the IPv6 tunnel endpoints can treat the IPv4 tunnel as a single hop link as defined in [RFC4213]. The two tunnel endpoints, e.g., mobile node and home agent, MUST configure link-local IPv6 addresses as defined in Section 3.7 of
当IPv6在IPv4隧道上运行时，IPv6隧道端点可以将IPv4隧道视为[RFC4213]中定义的单跳链路。两个隧道端点（例如，移动节点和归属代理）必须配置本协议第3.7节中定义的链路本地IPv6地址
[RFC4213], while they MUST also adhere to the neighbor discovery requirements of the same specification, Section 3.8, and the hop limit requirements of Section 3.3.
[RFC4213]，同时它们还必须遵守相同规范第3.8节的邻居发现要求和第3.3节的跃点限制要求。
With respect to the Tunnel MTU, an implementation MUST support the Static Tunnel MTU approach as defined in Section 3.2 of [RFC4213]. Implementation and use of the Dynamic Tunnel MTU method defined in the same section of [RFC4213] is OPTIONAL.
关于隧道MTU，实施必须支持[RFC4213]第3.2节中定义的静态隧道MTU方法。[RFC4213]同一节中定义的动态隧道MTU方法的实施和使用是可选的。
To accommodate traffic that uses Explicit Congestion Notification (ECN), it is RECOMMENDED that the ECN and Diffserv Code Point (DSCP) information is copied between the inner and outer header as defined in [RFC3168] and [RFC2983]. It is RECOMMENDED that the full-functionality option defined in Section 9.1.1 of [RFC3168] be used to deal with ECN.
为了适应使用显式拥塞通知（ECN）的流量，建议在[RFC3168]和[RFC2983]中定义的内部和外部报头之间复制ECN和Diffserv代码点（DSCP）信息。建议使用[RFC3168]第9.1.1节中定义的完整功能选项来处理ECN。
An implementation can use any number of mechanisms to allocate IPv6 prefixes to a mobile node. Once one or more IPv6 prefixes are allocated, they can be registered using the extensions and mechanism already described in this specification.
实现可以使用任意数量的机制将IPv6前缀分配给移动节点。一旦分配了一个或多个IPv6前缀，就可以使用本规范中已经描述的扩展和机制注册它们。
How a home agent decides to accept an IPv6 prefix for a given mobile node is out of scope of this specification. Local configuration or external authorization via an authorization system, e.g., Diameter [RFC3588], or other mechanisms may be used to make such determination.
归属代理如何决定接受给定移动节点的IPv6前缀超出了本规范的范围。可使用本地配置或通过授权系统的外部授权，例如直径[RFC3588]或其他机制来进行此类确定。
A dual-stack mobile node MAY use prefix delegation as defined in DHCPv6 Prefix Delegation [RFC3633] to get access to IPv6 prefixes. In that case, if the mobile node is not directly attached to its home agent, the mobile node MUST first register its IPv4 home address as per MIPv4 [RFC3344]. When that is done, the mobile node can generate a link-local IPv6 address as per Section 3.7 of [RFC4213]. The mobile node then sends a registration request to its home agent, including an IPv6 prefix request extension with the prefix length field set to 255 and setting the Mobile IPv6 Network Prefix field to the locally generated link-local address. If the registration reply message includes an IPv6 prefix reply extension with the code field set to a success code, the mobile node can use the tunnel to send and receive IPv6 link-local packets. The mobile node can now send DHCPv6 messages according to [RFC3633]. All IPv6 messages at this stage MUST be tunneled over the IPv4 tunnel between the mobile node's IPv4 home address and the home agent's IPv4 address.
双栈移动节点可以使用DHCPv6前缀委派[RFC3633]中定义的前缀委派来访问IPv6前缀。在这种情况下，如果移动节点未直接连接到其归属代理，则移动节点必须首先按照MIPv4[RFC3344]注册其IPv4归属地址。完成后，移动节点可以根据[RFC4213]第3.7节生成链路本地IPv6地址。然后，移动节点向其归属代理发送注册请求，包括前缀长度字段设置为255的IPv6前缀请求扩展，以及将移动IPv6网络前缀字段设置为本地生成的链路本地地址。如果注册回复消息包括IPv6前缀回复扩展，并且代码字段设置为成功代码，则移动节点可以使用隧道发送和接收IPv6链路本地分组。移动节点现在可以根据[RFC3633]发送DHCPv6消息。此阶段的所有IPv6消息必须通过IPv4隧道在移动节点的IPv4主地址和归属代理的IPv4地址之间传输。
Once prefixes are delegated, and assuming explicit mode is used, the mobile node SHOULD send a registration request with the appropriate IPv6 prefix request extensions to the home agent to register the delegated prefixes.
一旦委派了前缀，并且假设使用了显式模式，移动节点应向归属代理发送带有适当IPv6前缀请求扩展的注册请求，以注册委派的前缀。
The mobile IP registration lifetime included in the registration request header is valid for all the bindings created by the registration request, which may include bindings for IPv6 prefix(es).
注册请求标头中包含的移动IP注册生存期对于注册请求创建的所有绑定都有效，其中可能包括IPv6前缀的绑定。
A registration request with a zero lifetime can be used to remove all bindings from the home agent.
具有零生存期的注册请求可用于从归属代理中删除所有绑定。
A re-registration request with non-zero lifetime can be used to deregister some of the registered IPv6 prefixes by not including corresponding IPv6 prefix request extensions in the registration request message.
具有非零生存期的重新注册请求可用于取消注册某些已注册的IPv6前缀，方法是不在注册请求消息中包含相应的IPv6前缀请求扩展。
If the care-of address is a private address, then Mobile IP NAT Traversal as [RFC3519] MAY be used in combination with the extensions described in this specification. In that case, to transport IPv6 packets, the next header field of the Mobile Tunnel Data message header [RFC3519] MUST be set to the value for IPv6. Note that in that case, the encapsulation field of the UDP Tunnel Request Extension defined in [RFC3519] MUST be set to zero.
如果转交地址是私有地址，那么移动IP NAT遍历as[RFC3519]可以与本规范中描述的扩展结合使用。在这种情况下，要传输IPv6数据包，必须将移动隧道数据消息头[RFC3519]的下一个头字段设置为IPv6的值。注意，在这种情况下，[RFC3519]中定义的UDP隧道请求扩展的封装字段必须设置为零。
This specification operates in the security constraints and requirements of [RFC3344]. It extends the operations defined in [RFC3344] for IPv4 home addresses to cover home IPv6 prefixes and provides the same level of security for both IP address versions.
本规范在[RFC3344]的安全约束和要求下运行。它扩展了[RFC3344]中定义的IPv4家庭地址操作，以覆盖家庭IPv6前缀，并为两个IP地址版本提供相同级别的安全性。
Home agents MUST perform appropriate checks for reverse-tunneled IPv6 packets similar to what is defined in [RFC3024] for IPv4 packets. The check defined in [RFC3024] requires that the outer header's source address is set to a registered care-of address for the mobile node and as such the same check protects from attacks whether the encapsulated (inner) header is IPv4 or IPv6.
归属代理必须对反向隧道IPv6数据包执行适当的检查，类似于[RFC3024]中对IPv4数据包的定义。[RFC3024]中定义的检查要求将外部报头的源地址设置为移动节点的注册转交地址，因此，无论封装（内部）报头是IPv4还是IPv6，该检查都可以防止攻击。
In addition to that, the home agent MUST check that the source address of the inner header is a registered IPv4 home address or IPv6 prefix for this mobile node. If that is not the case, the home agent SHOULD silently discard the packet and log the event as a security exception.
除此之外，归属代理必须检查内部报头的源地址是否是此移动节点的已注册IPv4归属地址或IPv6前缀。如果情况并非如此，则归属代理应默默地丢弃该数据包，并将该事件记录为安全异常。
Security devices should look for IPv6 packets encapsulated over IPv4 either directly to the mobile node's care-of address or via double encapsulation first to the mobile node's IPv4 home address and then to the mobile node's care-of address. Interactions with Mobile IPv4 and IPsec have been covered elsewhere, for instance in [RFC5265] and [RFC5266].
安全设备应查找通过IPv4封装的IPv6数据包，这些数据包可以直接封装到移动节点的转交地址，也可以通过双重封装首先封装到移动节点的IPv4家庭地址，然后再封装到移动节点的转交地址。其他地方已经介绍了与移动IPv4和IPsec的交互，例如[RFC5265]和[RFC5266]。
A new type number (152) for DSMIPv4 extensions has been registered from the space of numbers for skippable mobility extensions (i.e., 128-255), defined for Mobile IPv4 [RFC3344]. This registry is available from http://www.iana.org under "Extensions appearing in Mobile IP control messages".
已从为移动IPv4[RFC3344]定义的可跳过移动扩展（即128-255）的编号空间中注册了DSMPV4扩展的新类型编号（152）。此注册表可从http://www.iana.org 在“移动IP控制消息中出现的扩展”下。
A new subtype space for the type number of this extension has been created: "DSMIPv4 Extension subtypes". The subtype values 1, 2, and 3 are defined in this specification, while the rest of the subtypes are reserved and available for allocation based on Expert Review.
已为此扩展的类型号创建了一个新的子类型空间：“DSMPV4扩展子类型”。子类型值1、2和3在本规范中定义，而其余子类型保留并可根据专家评审进行分配。
Finally, a new space for the code field of the IPv6 prefix reply extension has been created: "IPv6 Prefix Reply Extension Codes". Values 0, 1, 8, and 9 are defined in this specification. Values 2-7 are reserved for accept codes, and values 10-255 are reserved for reject codes.
最后，为IPv6前缀应答扩展的代码字段创建了一个新的空间：“IPv6前缀应答扩展代码”。本规范中定义了值0、1、8和9。值2-7保留用于接受代码，值10-255保留用于拒绝代码。
Similar to the procedures specified for Mobile IPv4 [RFC3344] number spaces, future allocations from the two number spaces require Expert Review [RFC5226].
与移动IPv4[RFC3344]号码空间指定的程序类似，将来从这两个号码空间进行分配需要专家审查[RFC5226]。
Thanks to Pat Calhoun, Paal Engelstad, Tom Hiller, and Pete McCann for earlier work on this subject. Thanks also to Alex Petrescu for various suggestions. Special thanks also to Sri Gundavelli and Kent Leung for their thorough review and suggestions.
感谢Pat Calhoun、Paal Engelstad、Tom Hiller和Pete McCann在此主题上的早期工作。还感谢Alex Petrescu提出的各种建议。特别感谢Sri Gundavelli和Kent Leung的全面审查和建议。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024]黑山，G.“移动IP的反向隧道，修订版”，RFC 3024，2001年1月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
[RFC3519]Levkowetz，H.和S.Vaarala，“网络地址转换（NAT）设备的移动IP遍历”，RFC 3519，2003年4月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[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月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963]Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[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月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004]Perkins，C.，“IP内的最小封装”，RFC 2004，1996年10月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, June 2008.
[RFC5265]Vaarala，S.和E.Kloving，“跨基于IPsec的VPN网关的移动IPv4穿越”，RFC 5265，2008年6月。
[RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008.
[RFC5266]Devarapalli，V.和P.Eronen，“使用移动IPv4和IKEv2移动和多址（MOBIKE）实现安全连接和移动”，BCP 136，RFC 5266，2008年6月。
Authors' Addresses
作者地址
George Tsirtsis Qualcomm
George Tsirtsis高通公司
EMail: tsirtsis@googlemail.com
EMail: tsirtsis@googlemail.com
Vincent Park Qualcomm
文森特公园高通公司
Phone: +908-947-7084
EMail: vpark@qualcomm.com
Phone: +908-947-7084
EMail: vpark@qualcomm.com
Hesham Soliman Elevate Technologies
Hesham Soliman提升技术公司
Phone: +614-111-410-445
EMail: hesham@elevatemobile.com
Phone: +614-111-410-445
EMail: hesham@elevatemobile.com