Network Working Group H. Soliman, Ed.
Request for Comments: 5555 Elevate Technologies
Category: Standards Track June 2009
Network Working Group H. Soliman, Ed.
Request for Comments: 5555 Elevate Technologies
Category: Standards Track June 2009
Mobile IPv6 Support for Dual Stack Hosts and Routers
对双栈主机和路由器的移动IPv6支持
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
摘要
The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent.
当前的移动IPv6和网络移动（NEMO）规范仅支持IPv6。该规范扩展了这些标准，允许分别注册IPv4地址和前缀，并允许通过隧道将IPv4和IPv6数据包传输到归属代理。该规范还允许移动节点在IPv6和IPv4上漫游，包括在移动节点与其归属代理之间的路径上存在网络地址转换的情况。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Motivation for Using Mobile IPv6 Only ......................4
1.3. Scenarios Considered by This Specification .................4
2. Solution Overview ...............................................6
2.1. Home Agent Address Discovery ...............................6
2.2. Mobile Prefix Solicitation and Advertisement ...............7
2.3. Binding Management .........................................8
2.3.1. Foreign Network Supports IPv6 .......................8
2.3.2. Foreign Network Supports IPv4 Only ..................9
2.4. Route Optimization ........................................11
2.5. Dynamic IPv4 Home Address Allocation ......................11
3. Extensions and Modifications to Mobile IPv6 ....................11
3.1. Binding Update Extensions .................................11
3.1.1. IPv4 Home Address Option ...........................11
3.1.2. The IPv4 Care-of Address Option ....................13
3.1.3. The Binding Update Message Extensions ..............13
3.2. Binding Acknowledgement Extensions ........................14
3.2.1. IPv4 Address Acknowledgement Option ................14
3.2.2. The NAT Detection Option ...........................16
4. Protocol Operation .............................................17
4.1. Tunnelling Formats ........................................17
4.1.1. Tunnelling Impacts on Transport and MTU ............18
4.2. NAT Detection .............................................19
4.3. NAT Keepalives ............................................21
4.4. Mobile Node Operation .....................................22
4.4.1. Selecting a Care-of Address ........................22
4.4.2. Sending Binding Updates ............................23
4.4.3. Sending Packets from a Visited Network .............25
4.4.4. Movement Detection in IPv4-Only Networks ...........26
4.5. Home Agent Operation ......................................26
4.5.1. Sending Packets to the Mobile Node .................28
4.6. Correspondent Node Operation ..............................29
5. Security Considerations ........................................29
5.1. Handover Interactions for IPsec and IKE ...................30
5.2. IKE Negotiation Messages between the Mobile Node
and Home Agent ............................................33
5.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling .....33
5.2.2. IKEv2 Operation for Securing Data over IPv4 ........36
6. Protocol Constants .............................................38
7. Acknowledgements ...............................................38
8. IANA Considerations ............................................38
9. References .....................................................39
9.1. Normative References ......................................39
9.2. Informative References ....................................40
10. Contributors ..................................................41
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Motivation for Using Mobile IPv6 Only ......................4
1.3. Scenarios Considered by This Specification .................4
2. Solution Overview ...............................................6
2.1. Home Agent Address Discovery ...............................6
2.2. Mobile Prefix Solicitation and Advertisement ...............7
2.3. Binding Management .........................................8
2.3.1. Foreign Network Supports IPv6 .......................8
2.3.2. Foreign Network Supports IPv4 Only ..................9
2.4. Route Optimization ........................................11
2.5. Dynamic IPv4 Home Address Allocation ......................11
3. Extensions and Modifications to Mobile IPv6 ....................11
3.1. Binding Update Extensions .................................11
3.1.1. IPv4 Home Address Option ...........................11
3.1.2. The IPv4 Care-of Address Option ....................13
3.1.3. The Binding Update Message Extensions ..............13
3.2. Binding Acknowledgement Extensions ........................14
3.2.1. IPv4 Address Acknowledgement Option ................14
3.2.2. The NAT Detection Option ...........................16
4. Protocol Operation .............................................17
4.1. Tunnelling Formats ........................................17
4.1.1. Tunnelling Impacts on Transport and MTU ............18
4.2. NAT Detection .............................................19
4.3. NAT Keepalives ............................................21
4.4. Mobile Node Operation .....................................22
4.4.1. Selecting a Care-of Address ........................22
4.4.2. Sending Binding Updates ............................23
4.4.3. Sending Packets from a Visited Network .............25
4.4.4. Movement Detection in IPv4-Only Networks ...........26
4.5. Home Agent Operation ......................................26
4.5.1. Sending Packets to the Mobile Node .................28
4.6. Correspondent Node Operation ..............................29
5. Security Considerations ........................................29
5.1. Handover Interactions for IPsec and IKE ...................30
5.2. IKE Negotiation Messages between the Mobile Node
and Home Agent ............................................33
5.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling .....33
5.2.2. IKEv2 Operation for Securing Data over IPv4 ........36
6. Protocol Constants .............................................38
7. Acknowledgements ...............................................38
8. IANA Considerations ............................................38
9. References .....................................................39
9.1. Normative References ......................................39
9.2. Informative References ....................................40
10. Contributors ..................................................41
Mobile IPv6 [RFC3775] and NEMO [RFC3963] allow mobile nodes to move within the Internet while maintaining reachability and ongoing sessions, using an IPv6 home address or prefix. However, since IPv6 is not widely deployed, it is unlikely that mobile nodes will initially use only IPv6 addresses for their connections. It is reasonable to assume that mobile nodes will, for a long time, need an IPv4 home address that can be used by upper layers. It is also reasonable to assume that mobile nodes will move to networks that might not support IPv6 and would therefore need the capability to support an IPv4 care-of address. Hence, this specification extends Mobile IPv6 capabilities to allow dual stack mobile nodes to request that their home agent (also dual stacked) tunnel IPv4/IPv6 packets addressed to their home addresses, as well as IPv4/IPv6 care-of address(es).
移动IPv6[RFC3775]和NEMO[RFC3963]允许移动节点在互联网内移动，同时使用IPv6主地址或前缀保持可达性和正在进行的会话。然而，由于IPv6没有广泛部署，移动节点最初不太可能只使用IPv6地址进行连接。可以合理地假设，在很长一段时间内，移动节点将需要一个可供上层使用的IPv4家庭地址。还可以合理地假设，移动节点将移动到可能不支持IPv6的网络，因此需要支持IPv4转交地址的能力。因此，该规范扩展了移动IPv6功能，允许双栈移动节点请求其归属代理（也是双栈）隧道IPv4/IPv6数据包寻址到其归属地址，以及IPv4/IPv6转交地址。
Using this specification, mobile nodes would only need Mobile IPv6 and [RFC3963] to manage mobility while moving within the Internet, hence eliminating the need to run two mobility management protocols simultaneously. This specification provides the extensions needed in order to allow dual stack mobile nodes to use IPv6 mobility only.
使用此规范，移动节点只需要移动IPv6和[RFC3963]即可在互联网内移动时管理移动性，因此无需同时运行两个移动性管理协议。本规范提供了允许双栈移动节点仅使用IPv6移动所需的扩展。
This specification will also consider cases where a mobile node moves into a private IPv4 network and gets configured with a private IPv4 care-of address. In these scenarios, the mobile node needs to be able to traverse the IPv4 NAT in order to communicate with the home agent. IPv4 NAT traversal for Mobile IPv6 is presented in this specification.
该规范还将考虑移动节点移入私有IPv4网络并配置私有IPv4照护地址的情况。在这些场景中，移动节点需要能够遍历IPv4 NAT，以便与归属代理通信。本规范介绍了移动IPv6的IPv4 NAT穿越。
In this specification, the term "mobile node" refers to both a mobile host and a mobile router unless the discussion is specific to either hosts or routers. Similarly, we use the term "home address" to reflect an address/prefix format. Note that both mobile host and router functionality have already been defined in [RFC3775] and [RFC3963], respectively. This specification does not change those already defined behaviors, nor does it extend the specific types of hosts and router support already defined, with the following two exceptions: (i) allowing the mobile node to communicate with its home agent even over IPv4 networks, and (ii) allowing the use of IPv4 home addresses and prefixes.
在本说明书中，术语“移动节点”指的是移动主机和移动路由器，除非讨论特定于主机或路由器。类似地，我们使用术语“家庭地址”来反映地址/前缀格式。请注意，[RFC3775]和[RFC3963]中分别定义了移动主机和路由器功能。本规范不会改变那些已经定义的行为，也不会扩展已经定义的特定类型的主机和路由器支持，但有以下两个例外：（i）允许移动节点甚至通过IPv4网络与其归属代理通信，以及（ii）允许使用IPv4归属地址和前缀。
In this specification, extensions are defined for the binding update and binding acknowledgement. It should be noted that all these extensions apply to cases where the mobile node communicates with a Mobility Anchor Point (MAP) as defined in [RFC5380]. The
在本规范中，为绑定更新和绑定确认定义了扩展。应该注意，所有这些扩展都适用于移动节点与[RFC5380]中定义的移动锚定点（MAP）通信的情况。这个
requirements on the MAP are identical to those stated for the home agent; however, it is unlikely that NAT traversal would be needed with a MAP, as it is expected to be in the same address domain.
地图上的要求与针对国内代理商的要求相同；但是，映射不太可能需要NAT遍历，因为它应该位于同一地址域中。
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]中所述进行解释。
IPv6 offers a number of improvements over today's IPv4, primarily due to its large address space. Mobile IPv6 offers a number of improvements over Mobile IPv4 [RFC3344], mainly due to capabilities inherited from IPv6. For instance, route optimization and dynamic home agent discovery can only be achieved with Mobile IPv6.
IPv6与今天的IPv4相比有许多改进，主要是由于其巨大的地址空间。移动IPv6比移动IPv4[RFC3344]提供了许多改进，主要是由于从IPv6继承的功能。例如，路由优化和动态归属代理发现只能通过移动IPv6实现。
One of the advantages of the large address space provided by IPv6 is that it allows mobile nodes to obtain a globally unique care-of address wherever they are. Hence, there is no need for Network Address Translator (NAT) traversal techniques designed for Mobile IPv4. This allows Mobile IPv6 to be a significantly simpler and more bandwidth-efficient mobility management protocol. At the same time, during the transition towards IPv6, NAT traversal for existing private IPv4 networks needs to be considered. This specification introduces NAT traversal for this purpose.
IPv6提供的大地址空间的优点之一是，它允许移动节点在任何位置都获得全局唯一的转交地址。因此，不需要为移动IPv4设计网络地址转换器（NAT）遍历技术。这使得移动IPv6成为一种更简单、带宽效率更高的移动管理协议。同时，在向IPv6过渡期间，需要考虑现有专用IPv4网络的NAT穿越。本规范介绍了用于此目的的NAT遍历。
The above benefits make the case for using only Mobile IPv6 for dual stack mobile nodes, as it allows for a long-lasting mobility solution. The use of Mobile IPv6 for dual stack mobility eliminates the need for changing the mobility solution due to the introduction of IPv6 within a deployed network.
上述优点使得双栈移动节点仅使用移动IPv6成为可能，因为它支持持久的移动解决方案。由于在已部署的网络中引入了IPv6，因此将移动IPv6用于双栈移动无需更改移动解决方案。
There are several scenarios that illustrate potential incompatibilities for mobile nodes using Mobile IPv6. Some of the problems associated with mobility and transition issues were presented in [RFC4977]. This specification considers the scenarios that address all the problems discussed in [RFC4977]. The scenarios considered in this specification are listed below.
有几个场景说明了使用移动IPv6的移动节点的潜在不兼容性。[RFC4977]中介绍了与移动性和过渡问题相关的一些问题。本规范考虑了解决[RFC4977]中讨论的所有问题的场景。本规范中考虑的场景如下所示。
All of the following scenarios assume that both the mobile node and the home agent are IPv4- and IPv6-enabled and that only Mobile IPv6 is used between the mobile node and the home agent. We also assume
以下所有场景都假设移动节点和归属代理都启用了IPv4和IPv6，并且移动节点和归属代理之间仅使用移动IPv6。我们还假设
that the home agent is always reachable through a globally unique IPv4 address. Finally, it's important to note that the following scenarios are not mutually exclusive.
始终可以通过全局唯一的IPv4地址访问归属代理。最后，需要注意的是，以下场景并不是相互排斥的。
Scenario 1: IPv4-only foreign network
场景1：仅IPv4外部网络
In this scenario, a mobile node is connected to an IPv4-only foreign network. The mobile node can only configure an IPv4 care-of address.
在此场景中，移动节点连接到仅IPv4的外部网络。移动节点只能配置IPv4转交地址。
Scenario 2: Mobile node behind a NAT
场景2：NAT后面的移动节点
In this scenario, the mobile node is in a private IPv4 foreign network that has a NAT device connecting it to the Internet. If the home agent is located outside the NAT device, the mobile node will need a NAT traversal mechanism to communicate with the home agent.
在此场景中，移动节点位于专用IPv4外部网络中，该网络具有将其连接到Internet的NAT设备。如果归属代理位于NAT设备之外，则移动节点将需要NAT穿越机制来与归属代理通信。
It should be noted that [RFC5389] highlights issues with some types of NATs that act as generic Application Level Gateways (ALGs) and rewrite any 32-bit field containing the NAT's public IP addresses. This specification will not support such NATs.
应该注意的是，[RFC5389]突出了某些类型的NAT的问题，这些NAT充当通用应用程序级网关（ALG），并重写包含NAT公共IP地址的任何32位字段。本规范不支持此类NAT。
Scenario 3: Home agent behind a NAT
场景3：NAT背后的归属代理
In this scenario, the communication between the mobile node and the home agent is further complicated by the fact that the home agent is located within a private IPv4 network. However, in this scenario, we assume that the home agent is allocated a globally unique IPv4 address. The address might not be physically configured on the home agent interface. Instead, it is associated with the home agent on the Network Address Port Translation (NAPT) device, which allows the home agent to be reachable through address or port mapping.
在该场景中，移动节点和归属代理之间的通信由于归属代理位于专用IPv4网络内的事实而进一步复杂化。但是，在此场景中，我们假设为归属代理分配了一个全局唯一的IPv4地址。该地址可能未在home agent接口上进行物理配置。相反，它与网络地址端口转换（NAPT）设备上的归属代理关联，该设备允许通过地址或端口映射访问归属代理。
Scenario 4: Use of IPv4-only applications
场景4：仅使用IPv4应用程序
In this scenario, the mobile node may be located in an IPv4, IPv6, or dual network. However, the mobile node might be communicating with an IPv4-only node. In this case, the mobile node would need a stable IPv4 address for its application. The alternative to using an IPv4 address is to use protocol translators; however, end-to-end communication with IPv4 is preferred to the use of protocol translators.
在这种情况下，移动节点可能位于IPv4、IPv6或双网络中。但是，移动节点可能正在与仅IPv4的节点通信。在这种情况下，移动节点的应用程序需要一个稳定的IPv4地址。使用IPv4地址的替代方法是使用协议转换器；但是，与使用协议转换器相比，使用IPv4进行端到端通信更为可取。
The mobile node may also be communicating with an IPv4-only application that requires an IPv4 address.
移动节点还可能正在与只需要IPv4地址的IPv4应用程序通信。
The cases above illustrate the need for the allocation of a stable IPv4 home address to the mobile node. This is done using an IPv4 home address. Since running Mobile IPv4 and Mobile IPv6
上述案例说明了需要将稳定的IPv4家庭地址分配给移动节点。这是使用IPv4家庭地址完成的。自从运行移动IPv4和移动IPv6以来
simultaneously is problematic (as illustrated in [RFC4977]), this scenario adds a requirement on Mobile IPv6 to support IPv4 home addresses.
同时也存在问题（如[RFC4977]所示），此场景增加了移动IPv6支持IPv4家庭地址的要求。
Scenario 5: IPv6 and IPv4-enabled networks
场景5：支持IPv6和IPv4的网络
In this scenario, the mobile node should prefer the use of an IPv6 care-of address for either its IPv6 or IPv4 home address. Normal IP-in-IP tunnelling should be used in this scenario as described in [RFC3775]. Under rare exceptions, where IP-in-IP tunnelling for IPv6 does not allow the mobile node to reach the home agent, the mobile node follows the sending algorithm described in Section 4.4.1. UDP tunnelling in IPv6 networks is proposed in this document as a last-resort mechanism when reachability cannot be achieved through normal IP-in-IP tunnelling. It should not be viewed as a normal mode of operation and should not be used as a first resort.
在这种情况下，移动节点应该更喜欢使用IPv6转交地址作为其IPv6或IPv4家庭地址。如[RFC3775]所述，在这种情况下，应使用IP隧道中的正常IP。在极少数例外情况下，如果IPv6的IP隧道中的IP不允许移动节点到达归属代理，则移动节点遵循第4.4.1节中描述的发送算法。本文提出了IPv6网络中的UDP隧道，作为在IP隧道中无法通过正常IP实现可达性时的最后手段。不应将其视为正常操作模式，也不应将其作为第一种手段。
In order to allow Mobile IPv6 to be used by dual stack mobile nodes, the following needs to be done:
为了允许双栈移动节点使用移动IPv6，需要执行以下操作：
o Mobile nodes should be able to use IPv4 and IPv6 home or care-of addresses simultaneously and to update their home agents accordingly.
o 移动节点应该能够同时使用IPv4和IPv6家庭或托管地址，并相应地更新其家庭代理。
o Mobile nodes need to be able to know the IPv4 address of the home agent as well as its IPv6 address. There is no need for IPv4 prefix discovery, however.
o 移动节点需要能够知道归属代理的IPv4地址及其IPv6地址。但是，不需要IPv4前缀发现。
o Mobile nodes need to be able to detect the presence of a NAT device and traverse it in order to communicate with the home agent.
o 移动节点需要能够检测NAT设备的存在并遍历它，以便与归属代理通信。
This section presents an overview of the extensions required in order to allow mobile nodes to use only Mobile IPv6 for IP mobility management.
本节概述了允许移动节点仅使用移动IPv6进行IP移动性管理所需的扩展。
Dynamic Home Agent Address Discovery (DHAAD) is defined in [RFC3775] to allow mobile nodes to discover their home agents by appending a well-known anycast interface identifier to their home link's prefix. However, this mechanism is based on IPv6-anycast routing. If a mobile node (MN) is located in an IPv4-only foreign network, it cannot rely on native IPv6 routing. In this scenario, the solution for discovering the home agent's IPv4 address is through the Domain Name System (DNS). If the MN is attached to an IPv6-only or dual
[RFC3775]中定义了动态归属代理地址发现（DHAAD），以允许移动节点通过在其归属链路的前缀中附加众所周知的选播接口标识符来发现其归属代理。然而，这种机制是基于IPv6选播路由的。如果移动节点（MN）位于仅IPv4的外部网络中，则它不能依赖本机IPv6路由。在此场景中，发现归属代理的IPv4地址的解决方案是通过域名系统（DNS）。如果MN连接到仅IPv6或双IPv6
stack network, it may also use procedures defined in [CHOWDHURY] to discover home agent information. Note that the use of [CHOWDHURY] cannot give the mobile node information that allows it to communicate with the home agent if the mobile node is located in an IPv4-only network. In this scenario, the mobile node needs to discover the IPv4 address of its home agent through the DNS.
堆栈网络，它也可以使用[CHOWDHURY]中定义的过程来发现归属代理信息。请注意，如果移动节点位于仅IPv4网络中，则使用[CHOWDHURY]不能提供允许其与归属代理通信的移动节点信息。在这种情况下，移动节点需要通过DNS发现其归属代理的IPv4地址。
For DNS lookup by name, the mobile node should be configured with the name of the home agent. When the mobile node needs to discover a home agent, it sends a DNS request with QNAME set to the configured name. An example is "ha1.example.com". If a home agent has an IPv4 and IPv6 address, the corresponding DNS record should be configured with both 'AAAA' and 'A' records. Accordingly, the DNS reply will contain 'AAAA' and 'A' records.
对于按名称进行DNS查找，应使用归属代理的名称配置移动节点。当移动节点需要发现归属代理时，它发送一个将QNAME设置为配置名称的DNS请求。例如“ha1.example.com”。如果归属代理具有IPv4和IPv6地址，则应使用“AAAA”和“a”记录配置相应的DNS记录。因此，DNS回复将包含“AAAA”和“A”记录。
For DNS lookup by service, the SRV record defined in [RFC5026] is reused. For instance, if the service name is "mip6" and the protocol name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS request with the QNAME set to "_mip6._ipv6.example.com". The response should contain the home agent's FQDN(s) and may include the corresponding 'AAAA' and 'A' records as well.
对于按服务进行的DNS查找，将重用[RFC5026]中定义的SRV记录。例如，如果SRV记录中的服务名称为“mip6”，协议名称为“ipv6”，则移动节点应发送QNAME设置为“_mip6._ipv6.example.com”的DNS请求。响应应包含归属代理的FQDN，并可能包括相应的“AAAA”和“A”记录。
If multiple home agents reside on the home link, each configured with a public IPv4 address, then the operation above applies. The correct DNS entries can be configured accordingly.
如果多个家庭代理驻留在家庭链路上，每个家庭代理都配置有公共IPv4地址，则上述操作适用。可以相应地配置正确的DNS条目。
According to [RFC3775], the mobile node can send a Mobile Prefix Solicitation and receive a Mobile Prefix Advertisement containing all prefixes advertised on the home link.
根据[RFC3775]，移动节点可以发送移动前缀请求并接收包含在归属链路上广告的所有前缀的移动前缀广告。
A dual stack mobile node MAY send a Mobile Prefix Solicitation message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where the mobile node has no access to IPv6 within the local network. Securing these messages requires the mobile node to have a security association with the home agent, using IPsec and based on the mobile node's IPv4 care-of address as described in [RFC3775] and [RFC4877].
在移动节点不能访问本地网络内的IPv6的情况下，双栈移动节点可以发送封装在IPv4中的移动前缀请求消息（即，IPv4中的IPv6）。保护这些消息需要移动节点使用IPsec并基于[RFC3775]和[RFC4877]中所述移动节点的IPv4转交地址与归属代理建立安全关联。
[RFC3775] requires the mobile node to include the home address option in the solicitation message sent to the home agent. If the mobile node is located in an IPv4 network, it will not be assigned an IPv6 address to include in the source address. In this case, the mobile node MUST use its home address in the source address field of the IPv6 packet, in addition to using the home address option as expected by [RFC3775].
[RFC3775]要求移动节点在发送给归属代理的请求消息中包括归属地址选项。如果移动节点位于IPv4网络中，则不会为其分配要包含在源地址中的IPv6地址。在这种情况下，除了按照[RFC3775]的预期使用home address选项外，移动节点还必须在IPv6数据包的source address字段中使用其home address。
A dual stack mobile node will need to update its home agent with its care-of address. If a mobile node has an IPv4 and an IPv6 home address, it will need to create a binding cache entry for each address. The format of the IP packet carrying the binding update and acknowledgement messages will vary depending on whether the mobile node has access to IPv6 in the visited network. There are three different scenarios to consider with respect to the visited network:
双栈移动节点将需要使用其转交地址更新其归属代理。如果移动节点具有IPv4和IPv6主地址，则需要为每个地址创建绑定缓存项。承载绑定更新和确认消息的IP分组的格式将根据移动节点是否能够访问访问的网络中的IPv6而有所不同。对于访问的网络，有三种不同的场景需要考虑：
o The visited network has IPv6 connectivity and provides the mobile node with a care-of address (in a stateful or stateless manner).
o 访问的网络具有IPv6连接，并为移动节点提供转交地址（以有状态或无状态的方式）。
o The mobile node can only configure a globally unique IPv4 address in the visited network.
o 移动节点只能在访问的网络中配置全局唯一的IPv4地址。
o The mobile node can only configure a private IPv4 address in the visited network.
o 移动节点只能在访问的网络中配置专用IPv4地址。
In this case, the mobile node is able to configure a globally unique IPv6 address. The mobile node will send a binding update to the IPv6 address of its home agent, as defined in [RFC3775]. The binding update MAY include the IPv4 home address option introduced in this document. After receiving the binding update, the home agent creates two binding cache entries: one for the mobile node's IPv4 home address and another for the mobile node's IPv6 home address. Both entries will point to the mobile node's IPv6 care-of address. Hence, whenever a packet is addressed to the mobile node's IPv4 or IPv6 home address, the home agent will tunnel it in IPv6 to the mobile node's IPv6 care-of address that is included in the binding update. Effectively, the mobile node establishes two different tunnels, one for its IPv4 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6), with a single binding update.
在这种情况下，移动节点能够配置全局唯一的IPv6地址。移动节点将向其归属代理的IPv6地址发送绑定更新，如[RFC3775]中所定义。绑定更新可能包括本文档中介绍的IPv4 home address选项。收到绑定更新后，归属代理将创建两个绑定缓存项：一个用于移动节点的IPv4主地址，另一个用于移动节点的IPv6主地址。这两个条目都将指向移动节点的IPv6转交地址。因此，每当数据包被寻址到移动节点的IPv4或IPv6主地址时，归属代理将在IPv6中将其隧道到绑定更新中包含的移动节点的IPv6转交地址。实际上，移动节点通过单个绑定更新建立两个不同的隧道，一个用于其IPv4流量（IPv6中的IPv4），另一个用于其IPv6流量（IPv6中的IPv6）。
In this scenario, this document extends [RFC3775] by including the IPv4 home address option in the binding update message. Furthermore, if the network supports both IPv4 and IPv6, or if the mobile node is experiencing problems with IP-in-IP tunnelling, this document proposes some mitigating actions as described in Section 4.4.1.
在这种情况下，本文档通过在绑定更新消息中包含IPv4 home address选项来扩展[RFC3775]。此外，如果网络同时支持IPv4和IPv6，或者如果移动节点在IP隧道中遇到IP问题，本文档将提出一些缓解措施，如第4.4.1节所述。
After accepting the binding update and creating the corresponding binding cache entries, the home agent MUST send a binding acknowledgement to the mobile node as defined in [RFC3775]. In addition, if the binding update included an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option as described in Section 3.2.1. This option
在接受绑定更新并创建相应的绑定缓存项后，归属代理必须按照[RFC3775]中的定义向移动节点发送绑定确认。此外，如果绑定更新包括IPv4主地址选项，则绑定确认必须包括IPv4地址确认选项，如第3.2.1节所述。此选项
informs the mobile node whether the binding was accepted for the IPv4 home address. If this option is not included in the binding acknowledgement and the IPv4 home address option was included in the binding update, the mobile node MUST assume that the home agent does not support the IPv4 home address option and therefore SHOULD NOT include the option in future binding updates to that home agent address.
通知移动节点IPv4主地址是否接受绑定。如果绑定确认中未包含此选项，并且绑定更新中包含IPv4 home address选项，则移动节点必须假定归属代理不支持IPv4 home address选项，因此不应在将来对该归属代理地址的绑定更新中包含此选项。
When a mobile node acquires both IPv4 and IPv6 care-of addresses at the foreign network, it SHOULD prioritize the IPv6 care-of address for its MIPv6 binding as described in Section 4.4.1.
当移动节点在外部网络上同时获取IPv4和IPv6转交地址时，它应按照第4.4.1节中的说明，为其MIPv6绑定优先考虑IPv6转交地址。
If the mobile node is in a foreign network that only supports IPv4, it needs to detect whether a NAT is in its communication path to the home agent. This is done while exchanging the binding update and acknowledgement messages as shown later in this document. NAT detection is needed for the purposes of the signaling presented in this specification.
如果移动节点位于仅支持IPv4的外部网络中，则需要检测NAT是否位于其到归属代理的通信路径中。这是在交换绑定更新和确认消息时完成的，如本文档后面所示。NAT检测对于本规范中提出的信令而言是必需的。
In this scenario, the mobile node will need to tunnel IPv6 packets containing the binding update to the home agent's IPv4 address. The mobile node uses the IPv4 address it gets from the foreign network as a source address in the outer header. The binding update will contain the mobile node's IPv6 home address. However, since the care-of address in this scenario is the mobile node's IPv4 address, the mobile node MUST include its IPv4 care-of address in the IPv6 packet. The IPv4 address is represented in the IPv4 care-of address option defined in this specification. If the mobile node had an IPv4 home address, it MUST also include the IPv4 home address option described in this specification.
在这种情况下，移动节点需要将包含绑定更新的IPv6数据包通过隧道传输到归属代理的IPv4地址。移动节点使用从外部网络获取的IPv4地址作为外部标头中的源地址。绑定更新将包含移动节点的IPv6主地址。但是，由于此场景中的转交地址是移动节点的IPv4地址，因此移动节点必须在IPv6数据包中包含其IPv4转交地址。IPv4地址在本规范中定义的IPv4转交地址选项中表示。如果移动节点具有IPv4家庭地址，则它还必须包括本规范中描述的IPv4家庭地址选项。
After accepting the binding update, the home agent MUST create a new binding cache entry for the mobile node's IPv6 home address. If an IPv4 home address option is included, the home agent MUST create another entry for that address. All entries MUST point to the mobile node's IPv4 care-of address. Hence, all packets addressed to the mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in an IPv4 header that includes the home agent's IPv4 address in the source address field and the mobile node's IPv4 care-of address in the destination address field.
在接受绑定更新后，归属代理必须为移动节点的IPv6主地址创建新的绑定缓存项。如果包含IPv4主地址选项，则主代理必须为该地址创建另一个条目。所有条目必须指向移动节点的IPv4转交地址。因此，寻址到移动节点的归属地址（IPv4或IPv6）的所有数据包将封装在IPv4报头中，该报头在源地址字段中包括归属代理的IPv4地址，在目标地址字段中包括移动节点的IPv4转交地址。
After accepting the binding updates and creating the corresponding entries, the home agent MUST send a binding acknowledgement as specified in [RFC3775]. In addition, if the binding update included
在接受绑定更新并创建相应条目后，归属代理必须按照[RFC3775]中的规定发送绑定确认。此外，如果包含绑定更新
an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option as described in Section 3.2.1. The binding acknowledgement is encapsulated to the IPv4 care-of address, which was included in the source address field of the IPv4 header encapsulating the binding update.
作为IPv4主地址选项，绑定确认必须包括IPv4地址确认选项，如第3.2.1节所述。绑定确认被封装到IPv4转交地址，该地址包含在封装绑定更新的IPv4标头的源地址字段中。
In this scenario the mobile node will need to tunnel IPv6 packets containing the binding update to the home agent's IPv4 address. In order to traverse the NAT device, IPv6 packets are tunneled using UDP and IPv4. The UDP port allocated for the home agent is 4191 (dsmipv6).
在这种情况下，移动节点需要将包含绑定更新的IPv6数据包通过隧道传输到归属代理的IPv4地址。为了穿越NAT设备，IPv6数据包使用UDP和IPv4进行隧道传输。为归属代理分配的UDP端口为4191（DSMPv6）。
The mobile node uses the IPv4 address it gets from the visited network as a source address in the IPv4 header. The binding update will contain the mobile node's IPv6 home address.
移动节点使用从访问的网络获取的IPv4地址作为IPv4标头中的源地址。绑定更新将包含移动节点的IPv6主地址。
After accepting the binding update, the home agent MUST create a new binding cache entry for the mobile node's IPv6 home address. If an IPv4 home address option is included, the home agent MUST create another entry for that address. All entries MUST point to the mobile node's IPv4 care-of address included in the source address of the IPv4 header that encapsulated the binding update message. In addition, the tunnel used MUST indicate UDP encapsulation for NAT traversal. Hence, all packets addressed to the mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in UDP and then encapsulated in an IPv4 header that includes the home agent's IPv4 address in the source address field and the mobile node's IPv4 care-of address in the destination address field. Note that the home agent MUST store the source UDP port numbers contained in the packet carrying the binding update in order to be able to forward packets to the mobile node.
在接受绑定更新后，归属代理必须为移动节点的IPv6主地址创建新的绑定缓存项。如果包含IPv4主地址选项，则主代理必须为该地址创建另一个条目。所有条目都必须指向移动节点的IPv4转交地址，该地址包含在封装绑定更新消息的IPv4标头的源地址中。此外，所使用的隧道必须指示用于NAT遍历的UDP封装。因此，所有寻址到移动节点的主地址（IPv4或IPv6）的数据包将封装在UDP中，然后封装在IPv4报头中，该报头在源地址字段中包括归属代理的IPv4地址，在目标地址字段中包括移动节点的IPv4转交地址。请注意，归属代理必须存储包含在携带绑定更新的数据包中的源UDP端口号，以便能够将数据包转发到移动节点。
After accepting the binding updates and creating the corresponding entries, the home agent MUST send a binding acknowledgement as specified in [RFC3775]. In addition, if the binding update included an IPv4 home address option, the binding acknowledgement MUST include the IPv4 address acknowledgment option as described later in this specification. The binding acknowledgement is encapsulated in UDP and then in IPv4 with the home agent's IPv4 address in the source address field and the mobile node's IPv4 care-of address in the destination field. The IPv4 address in the destination field of the IPv4 packet is the source address that was received in the IPv4 header containing the binding update message. The inner IPv6 packet will contain the home agent's IPv6 address as a source address and the mobile node's IPv6 home address in the destination address field.
在接受绑定更新并创建相应条目后，归属代理必须按照[RFC3775]中的规定发送绑定确认。此外，如果绑定更新包括IPv4主地址选项，则绑定确认必须包括IPv4地址确认选项，如本规范后面所述。绑定确认先封装在UDP中，然后封装在IPv4中，源地址字段中包含归属代理的IPv4地址，目标字段中包含移动节点的IPv4转交地址。IPv4数据包目标字段中的IPv4地址是在包含绑定更新消息的IPv4标头中接收到的源地址。内部IPv6数据包将包含作为源地址的归属代理的IPv6地址，以及目标地址字段中移动节点的IPv6归属地址。
The mobile node needs to maintain the NAT bindings for its current IPv4 care-of address. This is done through sending the binding update regularly to the home agent.
移动节点需要维护其当前IPv4转交地址的NAT绑定。这是通过定期向归属代理发送绑定更新来完成的。
Route optimization, as specified in [RFC3775], will operate in an identical manner for dual stack mobile nodes when they are located in a visited network that provides IPv6 addresses to the mobile node and while communicating with an IPv6-enabled correspondent node. However, when located in an IPv4-only network, or when using the IPv4 home address to communicate with an IPv4 correspondent node, route optimization will not be possible due to the difficulty of performing the return-routability test. In this specification, UDP encapsulation is only used between the mobile node and its home agent. Therefore, mobile nodes will need to communicate through the home agent.
[RFC3775]中规定的路由优化将以相同的方式对双栈移动节点进行操作，当它们位于向移动节点提供IPv6地址的访问网络中，并与启用IPv6的对应节点通信时。但是，当位于仅IPv4网络中时，或者当使用IPv4主地址与IPv4对应节点通信时，由于执行返回可路由性测试的困难，将无法进行路由优化。在本规范中，UDP封装仅在移动节点及其归属代理之间使用。因此，移动节点将需要通过归属代理进行通信。
Route optimization will not be possible for IPv4 traffic -- that is, traffic addressed to the mobile node's IPv4 home address. This is similar to using Mobile IPv4; therefore, there is no reduction of features resulting from using this specification.
IPv4流量不可能进行路由优化——也就是说，发送到移动节点IPv4主地址的流量。这类似于使用移动IPv4；因此，使用本规范不会减少特性。
It is possible to allow for the mobile node's IPv4 home address to be allocated dynamically. This is done by including 0.0.0.0 in the IPv4 home address option that is included in the binding update. The home agent SHOULD allocate an IPv4 address to the mobile node and include it in the IPv4 address acknowledgement option sent to the mobile node. In this case, the lifetime of the binding is bound to the minimum of the lifetimes of the IPv6 binding and the lease time of the IPv4 home address.
可以允许动态分配移动节点的IPv4家庭地址。这是通过在绑定更新中包含的IPv4 home address选项中包含0.0.0.0来实现的。归属代理应将IPv4地址分配给移动节点，并将其包括在发送给移动节点的IPv4地址确认选项中。在这种情况下，绑定的生存期绑定到IPv6绑定的生存期和IPv4主地址的租用时间中的最小值。
This section highlights the protocol and implementation additions required to support this specification.
本节重点介绍支持本规范所需的协议和实现添加。
This option is included in the mobility header, including the binding update message sent from the mobile node to a home agent or Mobility Anchor Point. The alignment requirement for this option is 4n.
该选项包括在移动报头中，包括从移动节点发送到归属代理或移动锚定点的绑定更新消息。该选项的对齐要求为4n。
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 |Prefix-len |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |Prefix-len |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv4 Home Address Option
图1:IPv4主地址选项
Type
类型
29
29
Length
长
6
6.
Prefix-len
前缀len
The length of the prefix allocated to the mobile node. If only a single address is allocated, this field MUST be set to 32. In the first binding update requesting a prefix, the field contains the prefix length requested. However, in the following binding updates, this field must contain the length of the prefix allocated. A value of zero is invalid and MUST be considered an error.
分配给移动节点的前缀的长度。如果只分配了一个地址，则此字段必须设置为32。在请求前缀的第一次绑定更新中，该字段包含请求的前缀长度。但是，在以下绑定更新中，此字段必须包含所分配前缀的长度。零值无效，必须视为错误。
P
P
A flag indicating, when set, that the mobile node requests a mobile network prefix. This flag is only relevant for new requests, and must be ignored for binding refreshes.
设置时，指示移动节点请求移动网络前缀的标志。此标志仅与新请求相关，在绑定刷新时必须忽略。
Reserved
含蓄的
This field is reserved for future use. It MUST be set to zero by the sender and ignored by the receiver.
此字段保留供将来使用。发送方必须将其设置为零，接收方必须忽略它。
IPv4 Home Address
IPv4家庭地址
The mobile node's IPv4 home address that should be defended by the home agent. This field could contain any unicast IPv4 address (public or private) that was assigned to the mobile node. The value 0.0.0.0 is used to request an IPv4 home address from the home agent. A mobile node may choose to use this option to request a prefix by setting the address to All Zeroes and setting the P flag. The mobile node could then form an IPv4 home address
应由归属代理保护的移动节点的IPv4归属地址。此字段可以包含分配给移动节点的任何单播IPv4地址（公用或专用）。值0.0.0.0用于从归属代理请求IPv4归属地址。移动节点可以通过将地址设置为全零并设置P标志来选择使用该选项来请求前缀。然后，移动节点可以形成IPv4主地址
based on the allocated prefix. Alternatively, the mobile node may use two different options, one for requesting an address (static or dynamic) and another for requesting a prefix.
基于分配的前缀。或者，移动节点可以使用两个不同的选项，一个用于请求地址（静态或动态），另一个用于请求前缀。
This option is included in the mobility header, including the binding update message sent from the mobile node to a home agent or Mobility Anchor Point. The alignment requirement for this option is 4n.
该选项包括在移动报头中，包括从移动节点发送到归属代理或移动锚定点的绑定更新消息。该选项的对齐要求为4n。
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Care-of address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Care-of address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The IPv4 CoA Option
图2:IPv4 CoA选项
Type
类型
32
32
Length
长
6
6.
Reserved
含蓄的
This field is set to zero by the sender and ignored by the receiver.
发送方将此字段设置为零，接收方将忽略此字段。
IPv4 Care-of Address
IPv4转交地址
This field contains the mobile node's IPv4 care-of address. The IPv4 care-of address is used when the mobile node is located in an IPv4-only network.
此字段包含移动节点的IPv4转交地址。当移动节点位于仅IPv4的网络中时，将使用IPv4转交地址。
This specification extends the binding update message with one new flag. The flag is shown and described below.
此规范使用一个新标志扩展绑定更新消息。下面显示并描述了该标志。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Binding Update Message
图3：绑定更新消息
F
F
When set, this flag indicates a request for forcing UDP encapsulation regardless of whether a NAT is present on the path between the mobile node and the home agent. This flag may be set by the mobile node if it is required to use UDP encapsulation regardless of the presence of a NAT. This flag SHOULD NOT be set when the mobile node is configured with an IPv6 care-of address -- with the exception of the scenario mentioned in Section 4.4.1.
设置此标志后，该标志指示强制UDP封装的请求，而不管移动节点和归属代理之间的路径上是否存在NAT。如果无论是否存在NAT，都需要使用UDP封装，则移动节点可以设置该标志。当移动节点配置了IPv6转交地址时，不应设置此标志——第4.4.1节中提到的情况除外。
This option is included in the mobility header, including the binding acknowledgement message sent from the home agent or Mobility Anchor Point to the mobile node. This option indicates whether a binding cache entry was created for the mobile node's IPv4 address. Additionally, this option includes an IPv4 home address in the case of dynamic IPv4 home address configuration (i.e., if the unspecified IPv4 address was included in the binding update). The alignment requirement for this option is 4n.
该选项包括在移动报头中，包括从归属代理或移动锚定点发送到移动节点的绑定确认消息。此选项指示是否为移动节点的IPv4地址创建了绑定缓存项。此外，在动态IPv4家庭地址配置的情况下，此选项包括IPv4家庭地址（即，如果绑定更新中包含未指定的IPv4地址）。该选项的对齐要求为4n。
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 | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Address Acknowledgement Option
图4:IPv4地址确认选项
Type
类型
30
30
Length
长
6
6.
Status
地位
Indicates success or failure for the IPv4 home address binding. Values from 0 to 127 indicate success. Higher values indicate failure.
指示IPv4主地址绑定的成功或失败。从0到127的值表示成功。较高的值表示失败。
Pref-len
优先权
The prefix length of the address allocated. This field is only valid in case of success and MUST be set to zero and ignored in case of failure. This field overrides what the mobile node requested (if not equal to the requested length).
分配的地址的前缀长度。此字段仅在成功时有效，必须设置为零，在失败时忽略。此字段覆盖移动节点请求的内容（如果不等于请求的长度）。
Res
雷斯
This field is reserved for future use. It MUST be set to zero by the sender and ignored by the receiver
此字段保留供将来使用。发送方必须将其设置为零，接收方必须忽略它
IPv4 Home Address
IPv4家庭地址
The IPv4 home address that the home agent will use in the binding cache entry. This could be a public or private address. This field MUST contain the mobile node's IPv4 home address. If the address were dynamically allocated, the home agent will add the address to inform the mobile node. Otherwise, if the address is statically allocated to the mobile node, the home agent will copy it from the binding update message.
归属代理将在绑定缓存项中使用的IPv4归属地址。这可以是公共或私人地址。此字段必须包含移动节点的IPv4主地址。如果地址是动态分配的，则归属代理将添加地址以通知移动节点。否则，如果该地址被静态分配给移动节点，则归属代理将从绑定更新消息复制该地址。
The following values are allocated for the status field:
为状态字段分配以下值：
o 0 Success
o 0成功
o 128 Failure, reason unspecified
o 128失败，原因不明
o 129 Administratively prohibited
o 129行政禁止
o 130 Incorrect IPv4 home address
o 130不正确的IPv4家庭地址
o 131 Invalid IPv4 address
o 131无效的IPv4地址
o 132 Dynamic IPv4 home address assignment not available
o 132动态IPv4家庭地址分配不可用
o 133 Prefix allocation unauthorized
o 133未经授权的前缀分配
This option is sent from the home agent to the mobile node to indicate whether a NAT was in the path. This option MAY also include a suggested NAT binding refresh time for the mobile node. This might be useful for scenarios where the mobile node is known to be moving within the home agent's administrative domain and, therefore, the NAT timeout is known (through configuration) to the home agent. Section 3.5 of [RFC5405] discusses issues with NAT timeout in some detail.
此选项从归属代理发送到移动节点，以指示NAT是否在路径中。该选项还可以包括移动节点的建议NAT绑定刷新时间。这对于已知移动节点在归属代理的管理域内移动，因此归属代理已知（通过配置）NAT超时的场景可能很有用。[RFC5405]的第3.5节详细讨论了NAT超时问题。
The alignment requirement for this option is 4n. If a NAT is detected, this option MUST be sent by the home agent.
该选项的对齐要求为4n。如果检测到NAT，则必须由归属代理发送此选项。
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 |F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The NAT Detection Option
图5:NAT检测选项
Type
类型
31
31
Length
长
6
6.
F
F
This flag indicates to the mobile node that UDP encapsulation is required. When set, this flag indicates that the mobile node MUST use UDP encapsulation even if a NAT is not located between the mobile node and home agent. This flag SHOULD NOT be set when the mobile node is assigned an IPv6 care-of address -- with the exception of accommodating the scenarios discussed in Section 4.4.1.
此标志向移动节点指示需要UDP封装。设置时，此标志指示移动节点必须使用UDP封装，即使NAT不位于移动节点和归属代理之间。当为移动节点分配IPv6转交地址时，不应设置此标志，但第4.4.1节中讨论的场景除外。
Reserved
含蓄的
This field is reserved for future use. It MUST be set to zero by the sender and ignored by the receiver.
此字段保留供将来使用。发送方必须将其设置为零，接收方必须忽略它。
Refresh Time
刷新时间
A suggested time (in seconds) for the mobile node to refresh the NAT binding. If set to zero, it is ignored. If this field is set to all 1s, it means that keepalives are not needed, i.e., no NAT was detected. The home agent MUST be configured with a default value for the refresh time. The recommended value is outlined in Section 6.
移动节点刷新NAT绑定的建议时间（秒）。如果设置为零，则忽略该值。如果此字段设置为所有1，则表示不需要keepalives，即未检测到NAT。必须为home agent配置刷新时间的默认值。第6节概述了建议值。
This section presents the protocol operation and processing for the messages presented above. In addition, this section introduces the NAT detection and traversal mechanism used by this specification.
本节介绍上述消息的协议操作和处理。此外，本节还介绍了本规范使用的NAT检测和遍历机制。
This specification allows the mobile node to use various tunnelling formats depending on its location and the visited network's capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6, or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this specification also supports tunnelling IPv6 in IPv6 [RFC2473].
该规范允许移动节点根据其位置和访问网络的能力使用各种隧道格式。移动节点可以在IPv4中隧道IPv6，在IPv6中隧道IPv4，或者使用UDP封装在IPv4中隧道IPv6。当然，该规范也支持IPv6[RFC2473]中的隧道IPv6。
This specification allows UDP-based tunnelling to be used between the mobile node and its home agent or MAP. A UDP encapsulation format means the following order of headers:
此规范允许在移动节点与其归属代理或映射之间使用基于UDP的隧道。UDP封装格式表示以下标题顺序：
IPv4/v6
IPv4/v6
UDP
UDP
IP (v4 or v6)
IP（v4或v6）
Other headers
其他标题
Note that the use of UDP encapsulation for IPv6 care-of addresses SHOULD NOT be done except in the circumstances highlighted in Section 4.4.1.
请注意，除非在第4.4.1节强调的情况下，否则不应将UDP封装用于IPv6转交地址。
When using this format, the receiver parses the version field following the UDP header in order to determine whether the following header is IPv4 or IPv6. The rest of the headers are processed normally. The above order of headers does not take IPsec headers
使用此格式时，接收器解析UDP标头后面的版本字段，以确定下面的标头是IPv4还是IPv6。其余的页眉处理正常。上述头的顺序不接受IPsec头
into account as they may be placed in different parts of the packet. The above format MUST be supported by all implementations of this specification and MUST always be used to send the binding update message.
考虑到它们可能被放置在数据包的不同部分。上述格式必须得到本规范所有实现的支持，并且必须始终用于发送绑定更新消息。
UDP tunnelling can also encapsulate an Encapsulating Security Payload (ESP) header as shown below:
UDP隧道还可以封装封装安全有效负载（ESP）头，如下所示：
IPv4/v6
IPv4/v6
UDP
UDP
ESP
ESP
IP (v4 or v6)
IP（v4或v6）
Other headers
其他标题
The negotiation of the secure tunnel format described above is discussed in Section 5.2. The receiver of a UDP tunnel detects whether or not an ESP header is present based on the UDP port used.
第5.2节讨论了上述安全隧道格式的协商。UDP隧道的接收器根据使用的UDP端口检测是否存在ESP报头。
Changing the tunnel format may occur due to movement of the mobile node from one network to another. This can impact the link and path MTU, which may affect the amount of bandwidth available to the applications. The mobile node may use Path MTU Discovery (PMTUD) as specified in [RFC4459].
由于移动节点从一个网络移动到另一个网络，可能发生隧道格式的改变。这可能会影响链路和路径MTU，这可能会影响应用程序可用的带宽量。移动节点可以使用[RFC4459]中指定的路径MTU发现（PMTUD）。
To accommodate traffic that uses Explicit Congestion Notification (ECN), it is RECOMMENDED that the ECN and Differentiated Services Code Point (DSCP) information be 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和差异化服务代码点（DSCP）信息。建议使用[RFC3168]第9.1.1节中定义的完整功能选项来处理ECN。
Note that some implementations may not be able to use ECN over the UDP tunnel. This is due to the lack of access to ECN bits in the UDP API on most platforms. However, this issue can be avoided if UDP encapsulation is done in the kernel.
请注意，某些实现可能无法通过UDP隧道使用ECN。这是由于在大多数平台上无法访问UDP API中的ECN位。但是，如果在内核中进行UDP封装，则可以避免此问题。
Note that, when using UDP encapsulation, the Time to Live (TTL) field must be decremented in the same manner as when IP-in-IP encapsulation is used.
请注意，当使用UDP封装时，生存时间（TTL）字段的递减方式必须与使用IP-in-IP封装时的递减方式相同。
This section deals with NAT detection for the purpose of encapsulating packets between the mobile node and the home agent when the mobile node is present in a private IPv4 network. Mobile IPv6 uses IKEv2 to establish the IPsec security association (SA) between the mobile node and the home agent. IKEv2 has its own NAT detection mechanism. However, IKEv2's NAT detection is only used for the purpose of setting up the IPsec SA for secure traffic. The interactions between the two NAT traversal mechanisms are described in Section 5.
本节讨论NAT检测，以便在移动节点位于专用IPv4网络中时封装移动节点和归属代理之间的数据包。移动IPv6使用IKEv2在移动节点和归属代理之间建立IPsec安全关联（SA）。IKEv2有自己的NAT检测机制。但是，IKEv2的NAT检测仅用于为安全流量设置IPsec SA。第5节描述了两个NAT遍历机制之间的交互。
NAT detection is done when the initial binding update message is sent from the mobile node to the home agent. When located in an IPv4-only foreign link, the mobile node sends the binding update message encapsulated in UDP and IPv4. The source address of the IPv6 packet is the mobile node's IPv6 home address. The destination address is the IPv6 address of the home agent. The IPv4 header contains the IPv4 care-of address in the source address field and the IPv4 address of the home agent in the destination address field.
当初始绑定更新消息从移动节点发送到归属代理时，完成NAT检测。当位于仅IPv4的外部链路中时，移动节点发送UDP和IPv4中封装的绑定更新消息。IPv6数据包的源地址是移动节点的IPv6主地址。目标地址是归属代理的IPv6地址。IPv4标头在源地址字段中包含IPv4转交地址，在目标地址字段中包含归属代理的IPv4地址。
When the home agent receives the encapsulated binding update, it compares the IPv4 address of the source address field in the IPv4 header with the IPv4 address included in the IPv4 care-of address option. If the two addresses match, no NAT device was in the path. Otherwise, a NAT was in the path and the NAT detection option is included in the binding acknowledgement. The binding acknowledgement and all future packets are then encapsulated in UDP and IPv4. The source address in the IPv4 header is the IPv4 address of the home agent. The destination address is the IPv4 address received in the IPv4 header encapsulating the binding update (this address will be different from the IPv4 care-of address when a NAT is in the path). The source port in the packet is the home agent's source port. The destination port is the source port received in the binding update message. Note that the home agent stores the port numbers and associates them with the mobile node's tunnel in order to forward future packets.
当归属代理接收到封装的绑定更新时，它会将IPv4标头中源地址字段的IPv4地址与IPv4转交地址选项中包含的IPv4地址进行比较。如果两个地址匹配，则路径中没有NAT设备。否则，路径中存在NAT，绑定确认中包含NAT检测选项。绑定确认和所有未来的数据包随后封装在UDP和IPv4中。IPv4标头中的源地址是归属代理的IPv4地址。目标地址是在封装绑定更新的IPv4标头中接收到的IPv4地址（当NAT位于路径中时，此地址将不同于IPv4转交地址）。数据包中的源端口是归属代理的源端口。目标端口是绑定更新消息中接收的源端口。注意，归属代理存储端口号并将其与移动节点的隧道相关联，以便转发未来的数据包。
Upon receiving the binding acknowledgement with the NAT detection option, the mobile node sets the tunnel to the home agent to UDP encapsulation. Hence, all future packets to the home agent are tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source address in the IPv6 header is the mobile node's IPv6 home address and the destination address is the correspondent node's IPv6 address. All tunneled IPv4 packets will contain the mobile node's IPv4 home address in the source address field of the inner IPv4 packet and the
在接收到带有NAT检测选项的绑定确认后，移动节点将到归属代理的隧道设置为UDP封装。因此，将来发送到归属代理的所有数据包都通过UDP和IPv4进行隧道传输。对于所有隧道式IPv6数据包，IPv6标头中的源地址是移动节点的IPv6主地址，目标地址是对应节点的IPv6地址。所有隧道IPv4数据包将在内部IPv4数据包的源地址字段和
correspondent node's IPv4 address in the destination address field. The outer IPv4 header is the same whether the inner packet is IPv4 or IPv6.
目标地址字段中对应节点的IPv4地址。无论内部数据包是IPv4还是IPv6，外部IPv4报头都是相同的。
If no NAT device was detected in the path between the mobile node and the home agent, then IPv6 packets are tunneled in an IPv4 header unless the home agent forces UDP encapsulation using the F flag. The content of the inner and outer headers are identical to the UDP encapsulation case.
如果在移动节点和归属代理之间的路径中未检测到NAT设备，则IPv6数据包将在IPv4报头中进行隧道传输，除非归属代理使用F标志强制UDP封装。内部和外部头的内容与UDP封装情况相同。
A mobile node MUST always tunnel binding updates in UDP when located in an IPv4-only network. Essentially, this process allows for perpetual NAT detection. Similarly, the home agent MUST encapsulate binding acknowledgements in a UDP header whenever the binding update is encapsulated in UDP.
移动节点位于仅IPv4网络中时，必须始终以UDP进行隧道绑定更新。本质上，这个过程允许永久的NAT检测。类似地，每当绑定更新被封装在UDP中时，归属代理必须将绑定确认封装在UDP报头中。
In conclusion, the packet formats for the binding update and acknowledgement messages are shown below:
总之，绑定更新和确认消息的数据包格式如下所示：
Binding update received by the home agent:
归属代理接收到的绑定更新：
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
IPv4标头（src=V4ADDR，dst=HA_V4ADDR）
UDP header
UDP标题
IPv6 header (src=V6HOA, dst=HAADDR)
IPv6标头（src=V6HOA，dst=HAADDR）
ESP header
ESP头
Mobility header
移动头
BU [IPv4 HAO]
卜[郝]
IPv4 CoA option
IPv4 CoA选项
Where V4ADDR is either the IPv4 care-of address or the address provided by the NAT device. V6HOA is the IPv6 home address of the mobile node. The binding update MAY also contain the IPv4 home address option, IPv4 HAO.
其中V4ADDR是IPv4转交地址或NAT设备提供的地址。V6HOA是移动节点的IPv6主地址。绑定更新还可能包含IPv4主地址选项IPv4 HAO。
Binding acknowledgement sent by the home agent:
归属代理发送的具有约束力的确认函：
IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
IPv4标头（src=HA_V4ADDR，dst=V4ADDR）
UDP header
UDP标题
IPv6 header (src=HAADDR, dst=V6HOA)
IPv6标头（src=HAADDR，dst=V6HOA）
ESP header
ESP头
Mobility header
移动头
BA ([IPv4 ACK], NAT DET)
BA（[IPv4确认]，NAT检测）
Where V6HOA is the IPv6 home address of the mobile node. The IPv4 ACK is the IPv4 address acknowledgement option, which is only included if the IPv4 home address option is present in the BU. The NAT DET is the NAT detection option, which MUST be present in the binding acknowledgement message if the binding update was encapsulated in UDP.
其中，V6HOA是移动节点的IPv6主地址。IPv4 ACK是IPv4地址确认选项，仅当BU中存在IPv4家庭地址选项时才包括该选项。NAT DET是NAT检测选项，如果绑定更新封装在UDP中，则该选项必须出现在绑定确认消息中。
If a NAT is detected, the mobile node will need to refresh the NAT bindings in order to be reachable from the home agent. NAT bindings can be refreshed through sending and receiving traffic encapsulated in UDP. However, if the mobile node is not active, it will need to periodically send a message to the home agent in order to refresh the NAT binding. This can be done using the binding update message. The binding update/acknowledgement pair will ensure that the NAT bindings are refreshed in a reliable manner. There is no way for the mobile node to know the exact time of the NAT binding. The default time suggested in this specification is NATKATIMEOUT (see Section 6). If the home agent suggests a different refresh period in the binding acknowledgement, the mobile node SHOULD use the value suggested by the home agent.
如果检测到NAT，移动节点将需要刷新NAT绑定，以便可以从归属代理访问。NAT绑定可以通过发送和接收UDP中封装的流量来刷新。但是，如果移动节点不处于活动状态，则需要定期向归属代理发送消息以刷新NAT绑定。这可以使用绑定更新消息来完成。绑定更新/确认对将确保以可靠的方式刷新NAT绑定。移动节点无法知道NAT绑定的确切时间。本规范中建议的默认时间为NATKATIMEOUT（参见第6节）。如果归属代理在绑定确认中建议不同的刷新周期，则移动节点应使用归属代理建议的值。
If the refresh time in the NAT detection option in the binding acknowledgement is set to all 1s, the mobile node need not send messages to refresh the NAT binding. However, the mobile node may still be required to encapsulate traffic in UDP. This scenario may take place when a NAT is not detected but the home agent still requires the mobile node to use UDP encapsulation.
如果绑定确认中的NAT检测选项中的刷新时间设置为所有1，则移动节点无需发送消息来刷新NAT绑定。但是，移动节点可能仍然需要在UDP中封装流量。当未检测到NAT但归属代理仍要求移动节点使用UDP封装时，可能会发生这种情况。
It should be noted that a mobile node that does not need to be reachable (i.e., one that only cares about the session continuity aspect of Mobile IP) does not need to refresh the NAT binding. In this case, the mobile node would only be able to initiate communication with other nodes. However, this is likely to imply that the mobile node will need to send a binding update before initiating communication after a long idle period as it is likely to be assigned a different port and IPv4 address by the NAT when it initiates communication. Hence, an implementation may choose, for the sake of simplicity, to always maintain the NAT bindings even when it does not need reachability.
应当注意，不需要可到达的移动节点（即，仅关心移动IP的会话连续性方面的移动节点）不需要刷新NAT绑定。在这种情况下，移动节点将只能发起与其他节点的通信。然而，这可能意味着移动节点将需要在长空闲时间之后启动通信之前发送绑定更新，因为当其启动通信时，NAT可能会为其分配不同的端口和IPv4地址。因此，为了简单起见，实现可以选择始终维护NAT绑定，即使它不需要可访问性。
Note that keepalives are also needed by IKEv2 over UDP port 4500. This is needed for IKE (Internet Key Exchange Protocol) dead-peer detection, which is not handled by DSMIPv6 keepalives.
请注意，IKEv2通过UDP端口4500也需要keepalives。这是IKE（Internet密钥交换协议）死点检测所必需的，DSMPv6 keepalives无法处理该检测。
In addition to the operations specified in [RFC3775] and [RFC3963], this specification requires mobile nodes to be able to support an IPv4 home address. This specification also requires the mobile node to choose an IPv4 or an IPv6 care-of address. We first discuss care-of address selection, then continue with binding management and transmission of normal traffic.
除了[RFC3775]和[RFC3963]中规定的操作外，本规范要求移动节点能够支持IPv4家庭地址。此规范还要求移动节点选择IPv4或IPv6转交地址。我们首先讨论地址选择的注意事项，然后继续进行绑定管理和正常流量的传输。
When a mobile node is in a dual stacked, visited network, it will have a choice between an IPv4 and an IPv6 care-of address. The mobile node SHOULD prefer the IPv6 care-of address and bind it to its home address(es). If a mobile node attempted to bind the IPv6 care-of address to its home address(es) and the binding update timed out, the mobile node SHOULD:
当移动节点位于双堆叠访问网络中时，它将在IPv4和IPv6转交地址之间进行选择。移动节点应首选IPv6转交地址，并将其绑定到其主地址。如果移动节点尝试将IPv6转交地址绑定到其家庭地址，并且绑定更新超时，则移动节点应：
o Resend the binding update using the exponential back-off algorithm described in [RFC3775].
o 使用[RFC3775]中描述的指数退避算法重新发送绑定更新。
o If after three attempts, in total, a binding acknowledgement was not received, the mobile node SHOULD send a new binding update using the IPv4 care-of address. The exponential backoff algorithm described in [RFC3775] should be used for re-transmission of the binding update if needed.
o 如果在总共三次尝试后未收到绑定确认，则移动节点应使用IPv4转交地址发送新的绑定更新。如果需要，应使用[RFC3775]中描述的指数退避算法重新传输绑定更新。
This procedure should be used to avoid scenarios where IPv6 connectivity may not be as reliable as IPv4. This unreliability may take place during early deployments of IPv6 or may simply be due to temporary outages affecting IPv6 routing.
此过程应用于避免IPv6连接可能不如IPv4可靠的情况。这种不可靠性可能发生在IPv6的早期部署期间，也可能只是由于影响IPv6路由的临时中断。
It is RECOMMENDED that upon movement, the mobile node not change the IP address family chosen for the previous binding update unless the mobile node is aware that it has moved to a different administrative domain where previous problems with IPv6 routing may not be present. Repeating the above procedure upon every movement can cause significant degradation of the mobile node's applications' performance due to extended periods of packet losses after handover, if the routing outage is still in effect.
建议移动节点在移动时不要更改为上一次绑定更新选择的IP地址系列，除非移动节点知道它已移动到另一个管理域，在该域中可能不存在以前的IPv6路由问题。如果路由中断仍然有效，则在每次移动时重复上述过程会导致移动节点的应用程序的性能显著降低，这是由于在切换后分组丢失的时间延长所致。
When using an IPv4 care-of address and IP-in-IP encapsulation, if the mobile node implementation is made aware by upper layers of persistent packet losses, it may attempt to resend the binding update
在IP封装中使用IPv4转交地址和IP时，如果移动节点实现被上层察觉到持续数据包丢失，则它可能会尝试重新发送绑定更新
with the F flag set, requesting UDP encapsulation for all packets. This may avoid packet losses due to situations where local firewalling policies prevent the use of IP-in-IP encapsulation.
设置F标志后，请求对所有数据包进行UDP封装。这可以避免由于本地防火墙策略阻止在IP封装中使用IP而导致的数据包丢失。
The effect of this address selection mechanism is to allow the following preferences in the absence of NAT:
此地址选择机制的作用是在没有NAT的情况下允许以下首选项：
1. IPv6
1. IPv6
2. IPv4 (using IP-in-IP or UDP encapsulation if a NAT is detected)
2. IPv4（如果检测到NAT，则在IP或UDP封装中使用IP）
3. UDP encapsulation when IP-in-IP is not allowed by the local domain.
3. 本地域不允许IP中的IP时的UDP封装。
When sending an IPv6 packet containing a binding update while connected to an IPv4-only access network, mobile nodes MUST ensure the following:
在连接到仅IPv4访问网络时发送包含绑定更新的IPv6数据包时，移动节点必须确保以下各项：
o The IPv6 packet is encapsulated in UDP.
o IPv6数据包封装在UDP中。
o The source address in the IPv4 header is the mobile node's IPv4 care-of address.
o IPv4标头中的源地址是移动节点的IPv4转交地址。
o The destination address in the IPv4 header is the home agent's IPv4 address.
o IPv4标头中的目标地址是归属代理的IPv4地址。
o The source address in the IPv6 header is the mobile node's IPv6 home address.
o IPv6标头中的源地址是移动节点的IPv6主地址。
o The IPv4 home address option MAY be included in the mobility header. This option contains the IPv4 home address. If the mobile node did not have a static home address, it MAY include the unspecified IPv4 address, which acts as a request for a dynamic IPv4 home address. Alternatively, one or more IPv4 home address options may be included with requests for IPv4 prefixes (i.e., with the P flag set).
o IPv4家庭地址选项可以包括在移动报头中。此选项包含IPv4主地址。如果移动节点没有静态主地址，则它可能包括未指定的IPv4地址，该地址充当对动态IPv4主地址的请求。或者，一个或多个IPv4家庭地址选项可以包括在IPv4前缀请求中（即，设置了P标志）。
o If the mobile node wishes to use UDP encapsulation only, it must set the F flag in the binding update message.
o 如果移动节点希望仅使用UDP封装，则必须在绑定更新消息中设置F标志。
o The IPv6 packet MUST be authenticated as per [RFC3775], based on the mobile node's IPv6 home address.
o IPv6数据包必须根据[RFC3775]基于移动节点的IPv6主地址进行身份验证。
When sending a binding update from a visited network that supports IPv6, the mobile node MUST follow the rules specified in [RFC3775]. In addition, if the mobile node has an IPv4 home address or needs
当从支持IPv6的访问网络发送绑定更新时，移动节点必须遵循[RFC3775]中指定的规则。此外，如果移动节点具有IPv4家庭地址或需要
one, it MUST include the IPv4 home address option in the mobility header. If the mobile node already has a static IPv4 home address, this address MUST be included in the IPv4 home address option. Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST include the IPv4 0.0.0.0 address in the IPv4 home address option.
首先，它必须在移动报头中包含IPv4家庭地址选项。如果移动节点已具有静态IPv4主地址，则此地址必须包含在IPv4主地址选项中。否则，如果移动节点需要动态IPv4地址，则必须在IPv4主地址选项中包含IPv4 0.0.0.0地址。
In addition to the rules in [RFC3775], the mobile node should follow the care-of address selection guidelines in Section 4.4.1.
除了[RFC3775]中的规则外，移动节点还应遵循第4.4.1节中的转交地址选择指南。
When the mobile node receives a binding acknowledgement from the home agent, it follows the rules in [RFC3775] and [RFC3963]. In addition, the following actions MUST be made:
当移动节点从归属代理接收到绑定确认时，它遵循[RFC3775]和[RFC3963]中的规则。此外，必须采取以下措施：
o If the status field indicated failure with error code 144, the mobile node MAY resend the binding update without setting the F flag.
o 如果状态字段指示错误代码为144的故障，则移动节点可以在不设置F标志的情况下重新发送绑定更新。
o If the mobility header includes an IPv4 address acknowledgement option indicating success, the mobile node should create two entries in its binding update list: one for the IPv6 home address and another for the IPv4 home address.
o 如果移动报头包括指示成功的IPv4地址确认选项，则移动节点应在其绑定更新列表中创建两个条目：一个用于IPv6家庭地址，另一个用于IPv4家庭地址。
o If the NAT detection option is present, the mobile node MUST tunnel future packets in UDP and IPv4. This MUST be indicated in the binding update list.
o 如果存在NAT检测选项，则移动节点必须在UDP和IPv4中隧道未来的数据包。这必须在绑定更新列表中指明。
o If no IPv4 address acknowledgement option is present, and an IPv4 home address option was present in the binding update, the mobile node MUST only create one binding update list entry for its IPv6 home address. The mobile node MAY include the IPv4 home address option in future binding updates.
o 如果不存在IPv4地址确认选项，并且绑定更新中存在IPv4家庭地址选项，则移动节点必须仅为其IPv6家庭地址创建一个绑定更新列表条目。移动节点可以在将来的绑定更新中包括IPv4家庭地址选项。
o If an IPv4 address acknowledgement option is present and it indicates failure for the IPv4 home address binding, the mobile node MUST NOT create an entry for that address in its binding update list. The mobile node MAY include the IPv4 home address option in future binding updates.
o 如果存在IPv4地址确认选项，并且该选项指示IPv4家庭地址绑定失败，则移动节点不得在其绑定更新列表中为该地址创建条目。移动节点可以在将来的绑定更新中包括IPv4家庭地址选项。
Mobile nodes will remove bindings from the home agent's binding cache whenever they move to the home link, or simply when mobility support is not needed.
无论何时移动节点移动到主链路，或者仅仅在不需要移动支持时，移动节点都将从主代理的绑定缓存中删除绑定。
Deregistering the IPv6 home address is described in [RFC3775]. The same mechanism applies in this specification. Mobile nodes may remove the binding for only the IPv4 home address by sending a binding update that does not include the IPv4 home address option.
[RFC3775]中描述了取消注册IPv6主地址。相同的机制适用于本规范。移动节点可以通过发送不包括IPv4 home address选项的绑定更新来仅删除IPv4 home address的绑定。
Upon receiving this binding update, the home agent will replace the existing cache entries with the content of the new message. This ensures that the IPv4 home address binding is removed while maintaining an IPv6 binding.
收到此绑定更新后，归属代理将用新消息的内容替换现有缓存项。这可确保在维护IPv6绑定的同时删除IPv4主地址绑定。
Note that the mobile node cannot remove the IPv6 home address binding while maintaining an IPv4 home address binding.
请注意，移动节点无法在维护IPv4家庭地址绑定的同时删除IPv6家庭地址绑定。
A binding update message with a lifetime of zero will remove all bindings for the mobile node.
生存期为零的绑定更新消息将删除移动节点的所有绑定。
When the mobile node is located in an IPv6-enabled network, it sends and receives IPv6 packets as described in [RFC3775]. In cases where IP-in-IP encapsulation is not providing connectivity to the home agent, the mobile node may choose to encapsulate in UDP as suggested in Section 4.4.1. However, this encapsulation of IPv6 traffic should be used as a last resort, as described. IPv4 traffic is encapsulated in IPv6 packets to the home agent.
当移动节点位于启用IPv6的网络中时，它发送和接收IPv6数据包，如[RFC3775]中所述。在IP-In-IP封装不提供到归属代理的连接的情况下，移动节点可以选择按照第4.4.1节中的建议以UDP封装。但是，如前所述，这种IPv6通信量的封装应作为最后手段使用。IPv4通信量封装在IPv6数据包中，发送到归属代理。
When the mobile node is located in an IPv4-only network, it will send IPv6 packets to its home agent according to the following format:
当移动节点位于仅IPv4网络中时，它将按照以下格式向其归属代理发送IPv6数据包：
IPv4 header (src=V4CoA, dst=HA_V4ADDR)
IPv4标头（src=V4CoA，dst=HA_V4ADDR）
[UDP header]
[UDP标头]
IPv6 header (src=V6HoA, dst=CN)
IPv6标头（src=V6HoA，dst=CN）
Upper layer protocols
上层协议
Here, the UDP header is only used if a NAT has been detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation. V4CoA is the IPv4 care-of address configured by the mobile node in the visited network.
这里，仅当在移动节点和归属代理之间检测到NAT，或者归属代理强制UDP封装时，才使用UDP报头。V4CoA是由访问网络中的移动节点配置的IPv4转交地址。
Similarly, IPv4 packets are sent according to the following format:
类似地，IPv4数据包按照以下格式发送：
IPv4 header (src=V4CoA, dst=HA_V4ADDR)
IPv4标头（src=V4CoA，dst=HA_V4ADDR）
[UDP header]
[UDP标头]
IPv4 header (src=V4HoA, dst=V4CN)
IPv4标头（src=V4HoA，dst=V4CN）
Upper Layer protocols
上层协议
Here, the UDP header is only used if a NAT has been detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation.
这里，仅当在移动节点和归属代理之间检测到NAT，或者归属代理强制UDP封装时，才使用UDP报头。
[RFC3775] describes movement detection mostly based on IPv6-specific triggers and Neighbor Discovery [RFC4861] information. These triggers are not available in an IPv4-only network. Hence, a mobile node located in an IPv4-only network SHOULD use [RFC4436] for guidance on movement-detection mechanisms in IPv4-only networks.
[RFC3775]主要基于IPv6特定触发器和邻居发现[RFC4861]信息描述移动检测。这些触发器在仅IPv4的网络中不可用。因此，位于仅IPv4网络中的移动节点应使用[RFC4436]来指导仅IPv4网络中的移动检测机制。
The mobile node detects that it's in an IPv4-only network when the IPv6 movement-detection algorithm fails to configure an IPv6 address.
当IPv6移动检测算法无法配置IPv6地址时，移动节点检测到它位于仅IPv4的网络中。
This specification does not support mobile nodes returning home while using IPv4. That is, the IPv4 support is only defined for mobile nodes that are in a visited network.
此规范不支持移动节点在使用IPv4时返回家乡。也就是说，IPv4支持仅为访问网络中的移动节点定义。
In addition to the home agent specification in [RFC3775] and [RFC3963], the home agent needs to be able to process the IPv4 home address option and generate the IPv4 address acknowledgement option. Both options are included in the mobility header. Furthermore, the home agent MUST be able to detect the presence of a NAT device and indicate that presence in the NAT detection option included in the binding acknowledgement.
除了[RFC3775]和[RFC3963]中的归属代理规范外，归属代理还需要能够处理IPv4归属地址选项并生成IPv4地址确认选项。这两个选项都包含在移动标题中。此外，归属代理必须能够检测NAT设备的存在，并在绑定确认中包括的NAT检测选项中指示该存在。
A home agent must also act as a proxy for address resolution in IPv4 for the registered IPv4 home addresses of mobile nodes it is serving. Moreover, the administrative domain of the home agent is responsible for advertising the routing information of registered IPv4 mobile-network prefixes of the mobile nodes.
归属代理还必须充当IPv4中地址解析的代理，用于它所服务的移动节点的已注册IPv4归属地址。此外，归属代理的管理域负责公布移动节点的已注册IPv4移动网络前缀的路由信息。
In order to comply with this specification, the home agent MUST be able to find the IPv4 home address of a mobile node when given the IPv6 home address. That is, given an IPv6 home address, the home agent MUST store the corresponding IPv4 home address if a static one is present. If a dynamic address is requested by the mobile node, the home agent MUST store that address (associated with the IPv6 home address) after it's allocated to the mobile node.
为了遵守此规范，归属代理必须能够在给定IPv6归属地址时找到移动节点的IPv4归属地址。也就是说，给定IPv6主地址，如果存在静态的IPv4主地址，则归属代理必须存储相应的IPv4主地址。如果移动节点请求动态地址，则归属代理必须在将该地址分配给移动节点后存储该地址（与IPv6归属地址关联）。
When the home agent receives a binding update encapsulated in UDP and containing the IPv4 home address option, it needs to follow all the steps in [RFC3775] and [RFC3963]. In addition, the following checks MUST be done:
当归属代理接收到以UDP封装并包含IPv4 home address选项的绑定更新时，它需要遵循[RFC3775]和[RFC3963]中的所有步骤。此外，必须进行以下检查：
o If the IPv4 care-of address in the IPv4 CoA option is not the same as the IPv4 address in the source address in the IPv4 header, then a NAT was in the path. This information should be flagged for the binding acknowledgement.
o 如果IPv4 CoA选项中的IPv4转交地址与IPv4标头中源地址中的IPv4地址不同，则NAT位于路径中。该信息应标记为绑定确认。
o If the F flag in the binding update is set, the home agent needs to determine whether it accepts forcing UDP encapsulation. If it does not, the binding acknowledgement is sent with error code 144. UDP encapsulation SHOULD NOT be used when the mobile node is located in an IPv6-enabled link, with the exception of the scenarios outlined in Section 4.4.1.
o 如果在绑定更新中设置了F标志，则归属代理需要确定是否接受强制UDP封装。如果没有，则发送绑定确认，错误代码为144。当移动节点位于启用IPv6的链路中时，不应使用UDP封装，第4.4.1节中概述的情况除外。
o If the IPv4 home address option contains a valid unicast IPv4 address, the home agent MUST check that this address is allocated to the mobile node that has the IPv6 home address included in the home address option. The same MUST be done for an IPv4 prefix.
o 如果IPv4家庭地址选项包含有效的单播IPv4地址，则家庭代理必须检查此地址是否分配给家庭地址选项中包含IPv6家庭地址的移动节点。对于IPv4前缀，必须执行相同的操作。
o If the IPv4 home address option contained the unspecified IPv4 address, the home agent SHOULD dynamically allocate an IPv4 home address to the mobile node. If none is available, the home agent MUST return error code 132 in the status field of the IPv4 address acknowledgement option. If a prefix is requested, the home agent SHOULD allocate a prefix with the requested length; if prefix allocation (of any length) is not possible, the home agent MUST indicate failure of the operation with the appropriate error code.
o 如果IPv4 home address选项包含未指定的IPv4地址，则归属代理应将IPv4 home address动态分配给移动节点。如果没有可用的，则归属代理必须在IPv4地址确认选项的状态字段中返回错误代码132。如果请求前缀，则归属代理应分配具有请求长度的前缀；如果无法进行前缀分配（任何长度），则归属代理必须使用适当的错误代码指示操作失败。
o If the binding update is accepted for the IPv4 home address, the home agent creates a binding cache entry for the IPv4 home address/prefix. The home agent MUST include an IPv4 acknowledgement option in the mobility header containing the binding acknowledgement.
o 如果IPv4主地址接受绑定更新，则归属代理将为IPv4主地址/前缀创建绑定缓存项。归属代理必须在包含绑定确认的移动报头中包含IPv4确认选项。
o If the binding update is accepted for both IPv4 and IPv6 home addresses, the home agent creates separate binding cache entries, one for each home address. The care-of address is the one included in the binding update. If the care-of address is an IPv4 address, the home agent MUST set up a tunnel to the IPv4 care-of address of the mobile node.
o 如果IPv4和IPv6主地址都接受绑定更新，则主代理将创建单独的绑定缓存项，每个主地址一个。转交地址是绑定更新中包含的地址。如果转交地址是IPv4地址，则归属代理必须设置到移动节点的IPv4转交地址的隧道。
When sending a binding acknowledgement to the mobile node, the home agent constructs the message according to [RFC3775] and [RFC3963]. Note that the routing header MUST always contain the IPv6 home address as specified in [RFC3775].
当向移动节点发送绑定确认时，归属代理根据[RFC3775]和[RFC3963]构造消息。请注意，路由标头必须始终包含[RFC3775]中指定的IPv6主地址。
If the care-of address of the mobile node is an IPv4 address, the home agent includes the mobile node's IPv6 home address in the destination address field in the IPv6 header. If a NAT is detected, the home agent MUST then encapsulate the packet in UDP and in an IPv4
如果移动节点的转交地址是IPv4地址，则归属代理将移动节点的IPv6归属地址包括在IPv6报头的目标地址字段中。如果检测到NAT，则归属代理必须将数据包封装在UDP和IPv4中
header. The source address is set to the home agent's IPv4 address and the destination address is set to the address received in the source address of the IPv4 header encapsulating the binding update.
标题。源地址设置为归属代理的IPv4地址，目标地址设置为在封装绑定更新的IPv4标头的源地址中接收的地址。
After creating a binding cache entry for the mobile node's home addresses, all packets sent to the mobile node's home addresses are tunneled by the home agent to the mobile node's care-of address. If a NAT is detected, packets are encapsulated in UDP and IPv4. Otherwise, if the care-of address is an IPv4 address and no NAT is detected, packets are encapsulated in an IPv4 header unless UDP encapsulation is forced by the home agent.
在为移动节点的家庭地址创建绑定缓存条目之后，发送到移动节点的家庭地址的所有数据包都由家庭代理通过隧道传输到移动节点的转交地址。如果检测到NAT，数据包将封装在UDP和IPv4中。否则，如果转交地址是IPv4地址且未检测到NAT，则数据包将封装在IPv4报头中，除非归属代理强制UDP封装。
The home agent follows the rules specified in [RFC3775] for sending IPv6 packets to mobile nodes located in IPv6 networks. When sending IPv4 packets to mobile nodes in an IPv6 network, the home agent must encapsulate the IPv4 packets in IPv6.
归属代理遵循[RFC3775]中指定的规则向位于IPv6网络中的移动节点发送IPv6数据包。当向IPv6网络中的移动节点发送IPv4数据包时，归属代理必须在IPv6中封装IPv4数据包。
When sending IPv6 packets to a mobile node located in an IPv4 network, the home agent uses the following format:
向位于IPv4网络中的移动节点发送IPv6数据包时，归属代理使用以下格式：
IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
IPv4标头（src=HA_V4ADDR，dst=V4ADDR）
[UDP header]
[UDP标头]
IPv6 header (src=CN, dst= V6HoA)
IPv6标头（src=CN，dst=V6HoA）
Upper layer protocols
上层协议
Where the UDP header is only included if a NAT is detected between the mobile node and the home agent or if the home agent forced UDP encapsulation. V4ADDR is the IPv4 address received in the source address field of the IPv4 packet containing the binding update.
其中，仅当在移动节点和归属代理之间检测到NAT或归属代理强制UDP封装时，才包括UDP报头。V4ADDR是在包含绑定更新的IPv4数据包的源地址字段中接收的IPv4地址。
When sending IPv4 packets to a mobile node located in an IPv4 network, the home agent must follow the format negotiated in the binding update/acknowledgement exchange. In the absence of a negotiated format, the default format that MUST be supported by all implementations is:
向位于IPv4网络中的移动节点发送IPv4数据包时，归属代理必须遵循绑定更新/确认交换中协商的格式。如果没有协商格式，所有实现必须支持的默认格式为：
IPv4 header (src= HA_V4ADDR, dst= V4ADDR)
IPv4标头（src=HA_V4ADDR，dst=V4ADDR）
[UDP header]
[UDP标头]
IPv4 header (src=V4CN, dst= V4HoA)
IPv4标头（src=V4CN，dst=V4HoA）
Upper layer protocols
上层协议
Where the UDP header is only included if a NAT is detected between the mobile node and home agent or if the home agent forced UDP encapsulation.
其中，仅当在移动节点和归属代理之间检测到NAT或归属代理强制UDP封装时，才包括UDP报头。
This specification has no impact on IPv4 or IPv6 correspondent nodes.
此规范对IPv4或IPv6对应节点没有影响。
This specification allows a mobile node to send one binding update for its IPv6 and IPv4 home addresses. This is a slight deviation from [RFC3775], which requires one binding update per home address. However, like [RFC3775], the IPsec security association needed to authenticate the binding update is still based on the mobile node's IPv6 home address. Therefore, in order to authorize the mobile node's IPv4 home address binding, the home agent MUST store the IPv4 address corresponding to the IPv6 address that is allocated to a mobile node. Therefore, it is sufficient for the home agent to know that the IPsec verification for the packet containing the binding update was valid, provided that it knows which IPv4 home address is associated with which IPv6 home address. Hence, the security of the IPv4 home address binding is the same as the IPv6 binding.
此规范允许移动节点为其IPv6和IPv4主地址发送一个绑定更新。这与[RFC3775]略有不同，后者要求每个家庭地址进行一次绑定更新。但是，与[RFC3775]一样，验证绑定更新所需的IPsec安全关联仍然基于移动节点的IPv6主地址。因此，为了授权移动节点的IPv4归属地址绑定，归属代理必须存储与分配给移动节点的IPv6地址相对应的IPv4地址。因此，只要归属代理知道哪个IPv4归属地址与哪个IPv6归属地址关联，就足以知道包含绑定更新的数据包的IPsec验证是有效的。因此，IPv4家庭地址绑定的安全性与IPv6绑定相同。
In effect, associating the mobile node's IPv4 home address with its IPv6 home address moves the authorization of the binding update for the IPv4 address to the Mobile IPv6 implementation, which infers it from the fact that the mobile node has an IPv6 home address and the right credentials for sending an authentic binding update for the IPv6 address.
实际上，将移动节点的IPv4家庭地址与其IPv6家庭地址相关联会将IPv4地址的绑定更新授权移动到移动IPv6实现，这是从移动节点具有IPv6主地址和用于发送IPv6地址的真实绑定更新的正确凭据这一事实推断出来的。
This specification requires the use of IKEv2 as the default mechanism for dynamic keying.
本规范要求使用IKEv2作为动态键控的默认机制。
In cases where this specification is used for NAT traversal, it is important to note that it has the same vulnerabilities associated with [RFC3519]. An attacker is able to hijack the mobile node's session with the home agent if it can modify the contents of the outer IPv4 header. The contents of the header are not authenticated and there is no way for the home agent to verify their validity. Hence, a man in the middle attack, where a change in the contents of the IPv4 header can cause a legitimate mobile node's traffic to be diverted to an illegitimate receiver independently of the authenticity of the binding update message, is possible.
在本规范用于NAT遍历的情况下，需要注意的是，它具有与[RFC3519]相关的相同漏洞。如果移动节点可以修改外部IPv4报头的内容，则攻击者可以劫持移动节点与归属代理的会话。标头的内容未经过身份验证，并且归属代理无法验证其有效性。因此，在中间攻击中，IPv4报头内容的改变可能导致合法移动节点的流量独立于绑定更新消息的真实性而转移到非法接收器，这是可能的。
In this specification, the binding update message MUST be protected using ESP transport mode. When the mobile node is located in an IPv4-only network, the binding update message is encapsulated in UDP
在本规范中，必须使用ESP传输模式保护绑定更新消息。当移动节点位于仅IPv4网络中时，绑定更新消息将封装在UDP中
as described earlier in Section 4.2. However, UDP SHOULD NOT be used to encapsulate the binding update message when the mobile node is located in an IPv6-enabled network. If protection of payload traffic is needed when the mobile node is located in an IPv4-only network, encapsulation is done using tunnel mode ESP over port 4500 as described in [RFC3948]. During the IKE negotiation with the home agent, if the mobile node and home agent support the use of port 4500, the mobile node MUST establish the security association over port 4500, regardless of the presence of a NAT. This is done to avoid switching between ports 500 and 4500 and the potential traffic disruption resulting from this switch.
如上文第4.2节所述。但是，当移动节点位于启用IPv6的网络中时，不应使用UDP封装绑定更新消息。如果当移动节点位于仅IPv4的网络中时需要保护有效负载流量，则使用[RFC3948]中所述的隧道模式ESP通过端口4500进行封装。在与归属代理的IKE协商期间，如果移动节点和归属代理支持端口4500的使用，则无论是否存在NAT，移动节点必须在端口4500上建立安全关联。这样做是为了避免在端口500和4500之间切换，以及由此切换导致的潜在通信中断。
Handovers within private IPv4 networks or from IPv6 to IPv4 networks will impact the security association between the mobile node and the home agent. The following section presents the expected behaviour of the mobile node and home agent in those situations. The details of the IKE negotiations and messages are illustrated in Section 5.2.
在专用IPv4网络内或从IPv6到IPv4网络的切换将影响移动节点和归属代理之间的安全关联。以下部分介绍移动节点和归属代理在这些情况下的预期行为。IKE协商和消息的详细信息见第5.2节。
After the mobile node detects movement, it configures a new care-of address. If the mobile node is in an IPv4-only network, it removes binding update list entries for correspondent nodes, since route optimisation cannot be supported. This may cause inbound packet losses, as remote correspondent nodes are unaware of such movement. To avoid confusion in the correspondent node, the mobile node SHOULD deregister its binding with each correspondent node by sending a deregistration binding update. The deregistration binding update message is tunnelled to the home agent and onto the correspondent node. This is done after the mobile node updates the home agent with its new location as discussed below.
移动节点检测到移动后，将配置新的转交地址。如果移动节点位于仅IPv4网络中，则会删除对应节点的绑定更新列表项，因为无法支持路由优化。这可能会导致入站数据包丢失，因为远程通信节点不知道这种移动。为了避免对应节点中的混淆，移动节点应通过发送撤销注册绑定更新来撤销其与每个对应节点的绑定。注销绑定更新消息通过隧道传输到归属代理和对应节点。这是在移动节点使用其新位置更新归属代理之后完成的，如下所述。
The mobile node sends the binding update message to the home agent. If the mobile node is in an IPv6-enabled network, the binding update SHOULD be sent without IPv4/UDP encapsulation, unless UDP encapsulation is needed as described in Section 4.4.1. If the mobile node is in an IPv4-only network, then -- after IPsec processing of the binding update (BU) message -- it encapsulates the BU in UDP/IPv4 as discussed in Sections 4.2 and 4.4. In order to be able to send the binding update while in an IPv4-only network, the mobile node needs to use the new IPv4 care-of address in the outer header, which is different from the care-of address used in the existing tunnel. This should be done without permanently updating the tunnel within the mobile node's implementation in order to allow the mobile node to receive packets on the old care-of address until the binding acknowledgement is received. The method used to achieve this effect is implementation dependent and is outside the scope of this specification. This implies that the IP forwarding function (which
移动节点向归属代理发送绑定更新消息。如果移动节点位于启用IPv6的网络中，则应在不使用IPv4/UDP封装的情况下发送绑定更新，除非如第4.4.1节所述需要UDP封装。如果移动节点位于仅IPv4的网络中，则在对绑定更新（BU）消息进行IPsec处理后，它将BU封装在UDP/IPv4中，如第4.2节和第4.4节所述。为了能够在仅IPv4网络中发送绑定更新，移动节点需要在外部报头中使用新的IPv4转交地址，这与现有隧道中使用的转交地址不同。这应该在不永久更新移动节点的实现内的隧道的情况下完成，以便允许移动节点接收旧转交地址上的分组，直到接收到绑定确认为止。用于实现此效果的方法取决于实现，不在本规范的范围内。这意味着IP转发功能
selects the interface or tunnel through which a packet is sent) is not based solely on the destination address: some IPv6 packets destined to the home agent are sent via the existing tunnel, while BUs are sent using the new care-of address. Since BUs are protected by IPsec, the forwarding function cannot necessarily determine the correct treatment from the packet headers. Thus, the DSMIPv6 implementation has to attach additional information to BUs, and this information has to be preserved after IPsec processing and made available to the forwarding function or to DSMIP extensions included in the forwarding function. Depending on the mobile node's implementation, meeting this requirement may require changes to the IPsec implementation.
选择发送数据包所通过的接口或隧道（不完全基于目标地址）：某些发送到归属代理的IPv6数据包通过现有隧道发送，而总线使用新的转交地址发送。由于总线受IPsec保护，转发功能不一定能从数据包头确定正确的处理方法。因此，DSMIPv6实现必须将附加信息附加到总线上，并且该信息必须在IPsec处理后保留，并提供给转发功能或包含在转发功能中的DSMIP扩展。根据移动节点的实现，满足此要求可能需要更改IPsec实现。
Upon receiving the binding update message encapsulated in UDP/IPv4, the home agent processes it as follows. In order to allow the DSMIPv6 implementation in the home agent to detect the presence of a NAT on the path to the mobile node, it needs to compare the outer IPv4 source address with the IPv4 address in the IPv4 care-of address option. This implies that the information in the outer header will be preserved after IPsec processing and made available to the DSMIPv6 implementation in the home agent. Depending on the home agent's implementation, meeting this requirement may require changes to the IPsec implementation.
在接收到UDP/IPv4中封装的绑定更新消息后，归属代理按如下方式处理该消息。为了允许归属代理中的DSMPv6实现检测到移动节点路径上存在NAT，它需要将外部IPv4源地址与IPv4转交地址选项中的IPv4地址进行比较。这意味着外部报头中的信息将在IPsec处理后保留，并可供归属代理中的DSMPv6实现使用。根据归属代理的实现，满足此要求可能需要更改IPsec实现。
The home agent updates its tunnel mode security association to include the mobile node's care-of address as the remote-tunnel header address and 4500 as the port number. The IPv4 address and port number are likely to be wrong; the mobile node provides the correct information in a separate exchange as described below. When the mobile node is located in a private IPv4 network (which is detected as described above), the new address and port number are allocated by the NAT. The home agent will also enable or disable UDP encapsulation for outgoing ESP packets for the purpose of NAT traversal.
归属代理更新其隧道模式安全关联，以包括移动节点的转交地址作为远程隧道报头地址和4500作为端口号。IPv4地址和端口号可能错误；移动节点在单独的交换中提供正确的信息，如下所述。当移动节点位于专用IPv4网络（如上所述检测到）中时，新地址和端口号由NAT分配。出于NAT穿越的目的，归属代理还将启用或禁用传出ESP数据包的UDP封装。
If the Key Management Mobility Capability (K) bit was set in the binding update, and the home agent supports this feature, the home agent updates its IKE security associations to include the mobile node's care-of address as the peer address and 4500 as the port number. The home agent may also need to change NAT traversal fields in the IKE_SA to enable the dynamic update of the IP address and port number, based on the reception of authenticated IKE messages or authenticated packets using tunnel mode ESP. The dynamic updates are described in Section 2.23 of [RFC4306]. As described above, when the mobile node is located in a private IPv4 network, the address and port number used for IPsec and IKE traffic is not yet known by the home agent at this point.
如果在绑定更新中设置了密钥管理移动能力（K）位，并且归属代理支持此功能，则归属代理更新其IKE安全关联，以包括移动节点的转交地址作为对等地址，4500作为端口号。归属代理还可能需要更改IKE_SA中的NAT遍历字段，以便基于使用隧道模式ESP接收经验证的IKE消息或经验证的数据包来启用IP地址和端口号的动态更新。动态更新在[RFC4306]的第2.23节中描述。如上所述，当移动节点位于专用IPv4网络中时，此时归属代理尚不知道用于IPsec和IKE通信的地址和端口号。
The mobile node updates the IKE SA in one of two ways. If the K flag was set in the binding acknowledgement message, the mobile node SHOULD send an empty informational message, which results in the IKE module in the home agent dynamically updating the SA information. The IKE implementation in the home agent is REQUIRED to support this feature. Alternatively, the IKE SA should be re-negotiated. Note that updating the IKE SA MUST take place after the mobile node has sent the binding update and received the acknowledgement from the home agent.
移动节点以两种方式之一更新IKE SA。如果在绑定确认消息中设置了K标志，则移动节点应发送空的信息消息，这导致归属代理中的IKE模块动态更新SA信息。家庭代理中的IKE实现需要支持此功能。或者，应重新协商IKE SA。注意，更新IKE SA必须在移动节点发送绑定更新并从归属代理接收确认之后进行。
It is important to note that the mobile node's IPv4 care-of address seen by the DSMIPv6 module in the home agent upon receiving the binding update may differ from the IPv4 care-of address seen by the IKE module and the care-of address used for forwarding IPsec tunnel mode traffic. Hence, it is probable that different modules in the home agent will have a different care-of address that should be used for encapsulating traffic to the mobile node.
需要注意的是，在接收到绑定更新时，归属代理中的DSMPv6模块看到的移动节点的IPv4转交地址可能不同于IKE模块看到的IPv4转交地址和用于转发IPsec隧道模式流量的转交地址。因此，归属代理中的不同模块很可能将具有不同的转交地址，该地址应用于封装到移动节点的通信量。
After successfully processing the binding update, the home agent sends the binding acknowledgement to the mobile node's care-of address as received in the outer header of the packet containing the binding update. Note that if the BU was rejected, the binding acknowledgement (BAck) is sent to the same address from which the BU was received. This may require special treatment in IP forwarding and/or IPsec processing that resembles the sending of BUs in the mobile node (described above).
在成功地处理绑定更新之后，归属代理将绑定确认发送到包含绑定更新的分组的外部报头中接收到的移动节点的转交地址。请注意，如果BU被拒绝，绑定确认（返回）将发送到接收BU的相同地址。这可能需要在IP转发和/或IPsec处理中进行特殊处理，类似于移动节点中的总线发送（如上所述）。
Upon receiving the binding acknowledgement, the mobile node updates its local tunnel mode security association information to include the tunnel header IP source address, which is the mobile node's address, and the tunnel header IP destination, which is the home agent's address. The mobile node may also need to enable or disable UDP encapsulation for outgoing ESP packets for the purpose of NAT traversal and the sending of keepalives.
在接收到绑定确认时，移动节点更新其本地隧道模式安全关联信息以包括隧道报头IP源地址（移动节点的地址）和隧道报头IP目的地（归属代理的地址）。移动节点还可能需要启用或禁用传出ESP数据包的UDP封装，以便NAT遍历和发送keepalives。
The mobile node MAY use MOBIKE [RFC4555] to update its IKE SA with the home agent. Using MOBIKE requires negotiating this capability with the home agent when establishing the SA. In this case, the mobile node and the home agent MUST NOT update their IPsec SAs locally, as this step is performed by MOBIKE. Furthermore, the use of MOBIKE allows the mobile node to update the SA independently of the binding update exchange. Hence, there is no need for the mobile node to wait for a binding acknowledgement before performing MOBIKE. The use of MOBIKE is OPTIONAL in this specification.
移动节点可以使用MOBIKE[RFC4555]用归属代理更新其IKE SA。使用MOBIKE需要在建立SA时与归属代理协商此功能。在这种情况下，移动节点和归属代理不得在本地更新其IPsec sa，因为此步骤由MOBIKE执行。此外，MOBIKE的使用允许移动节点独立于绑定更新交换来更新SA。因此，移动节点在执行MOBIKE之前不需要等待绑定确认。在本规范中，MOBIKE的使用是可选的。
This specification defines a number of possible data encapsulation formats, depending on the mobile node's connectivity to the visited network. When connected to an IPv6-enabled network, the tunnelling formats are clear. However, when connected to an IPv4-only network, care should be taken when negotiating the IKE association and the consequential tunnelling formats used for secure and insecure traffic. This section illustrates the IKE message exchange between the mobile node and home agent when the mobile node is located in an IPv4-only network. Two different IKE negotiations are considered:
该规范定义了许多可能的数据封装格式，具体取决于移动节点与访问网络的连接。当连接到支持IPv6的网络时，隧道格式是清晰的。但是，当连接到仅IPv4网络时，在协商IKE关联和用于安全和不安全通信的相应隧道格式时，应小心。本节说明当移动节点位于仅IPv4网络中时，移动节点和归属代理之间的IKE消息交换。考虑两种不同的IKE谈判：
o IKEv2 operation for securing DSMIPv6 signaling.
o 用于保护IPv6信令的IKEv2操作。
o IKEv2 operation for securing data over IPv4
o 用于通过IPv4保护数据的IKEv2操作
A mobile node connected to an IPv4-only network SHOULD follow the procedures described below in order to establish an SA for the protection of binding update and binding acknowledgement messages. Note that V4ADDR refers to either the mobile node's care-of address in the visited link or the public address allocated to the mobile node by the NAT.
连接到仅IPv4网络的移动节点应遵循以下描述的过程，以便建立SA以保护绑定更新和绑定确认消息。注意，V4ADDR指的是移动节点在访问链路中的转交地址，或者是NAT分配给移动节点的公共地址。
Mobile Node Home Agent
----------- ----------
IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (500, 500) HDR, SAi1, KEi, Ni
NAT-D, NAT-D -->
Mobile Node Home Agent
----------- ----------
IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (500, 500) HDR, SAi1, KEi, Ni
NAT-D, NAT-D -->
<- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ]
NAT-D, NAT-D
<- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ]
NAT-D, NAT-D
IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (4500,4500) <non-ESP Marker > HDR, SK
{IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE),
SAi2, TSi, TSr}
-->
IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (4500,4500) <non-ESP Marker > HDR, SK
{IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE),
SAi2, TSi, TSr}
-->
<-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP (4500,Y) <non-ESP Marker > HDR, SK
{IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE),
SAr2, TSi, TSr}
<-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP (4500,Y) <non-ESP Marker > HDR, SK
{IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE),
SAr2, TSi, TSr}
The corresponding Security Policy Database (SPD) entries are shown below.
相应的安全策略数据库（SPD）条目如下所示。
Mobile node SPD-S:
移动节点SPD-S：
IF local_address = home_address_1 &
如果本地地址=家庭地址1&
remote_address = home_agent_1 &
远程\地址=主\代理\ 1&
proto = MH & local_mh_type = BU &
proto=MH和local_MH_类型=BU&
remote_mh_type = BAck
remote_mh_type = BAck
Then use SA ESP transport mode
然后使用SA ESP传输模式
Initiate using IDi = user_1 to address home_agent_1
使用IDi=user_1初始化以寻址home_代理_1
Home Agent SPD-S:
归属代理SPD-S：
IF local_address = home_agent_1 &
如果本地地址=家庭代理1&
remote_address = home_address_1 &
远程地址=主地址1&
proto = MH &
proto=MH&
local_mh_type = BAck &
本地_mh_类型=背面&
remote_mh_type = BU
remote_mh_type = BU
Then use SA ESP transport mode
然后使用SA ESP传输模式
Where home_address_1 is the mobile node's registered IPv6 home address and home_agent_1 is the IP address of the home agent.
其中，home_address_1是移动节点注册的IPv6 home address，home_agent_1是home agent的IP地址。
The above should result in BU/BA messages with the following BU received by the home agent:
上述情况应导致BU/BA消息，其中家乡代理接收到以下BU：
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
IPv4标头（src=V4ADDR，dst=HA_V4ADDR）
UDP header (sport=Z, dport=DSMIPv6)
UDP报头（sport=Z，dport=dsmpv6）
IPv6 header (src=V6HOA, dst=HAADDR)
IPv6标头（src=V6HOA，dst=HAADDR）
ESP header in transport mode
ESP标头处于传输模式
Mobility header
移动头
BU [IPv4 HAO]
卜[郝]
IPv4 CoA option
IPv4 CoA选项
(and others as needed)
（和其他需要的）
At the home agent, following UDP de-capsulation, the binding update is delivered to the IPsec module as shown below:
在home agent中，在UDP解除封装之后，绑定更新将传递到IPsec模块，如下所示：
IPv6 header (src=V6HOA, dst=HAADDR)
IPv6标头（src=V6HOA，dst=HAADDR）
ESP header in transport mode
ESP标头处于传输模式
Mobility header
移动头
BU [IPv4 HAO]
卜[郝]
IPv4 CoA option
IPv4 CoA选项
(and others as needed)
（和其他需要的）
In addition, V4ADDR and the sport (Z) need to be passed with the packet to ensure correct processing.
此外，V4ADDR和sport（Z）需要与数据包一起传递，以确保正确处理。
Following IPsec processing, the binding update is delivered to the DSMIPv6 home agent module as follows:
在IPsec处理之后，绑定更新将按如下方式传递到DSMPv6 home agent模块：
IPv6 header (src=V6HOA, dst=HAADDR)
IPv6标头（src=V6HOA，dst=HAADDR）
Mobility header
移动头
BU [IPv4 HAO]
卜[郝]
IPv4 CoA option
IPv4 CoA选项
(and others as needed)
（和其他需要的）
In addition, V4ADDR and the sport (Z) need to be passed with the packet to ensure correct processing.
此外，V4ADDR和sport（Z）需要与数据包一起传递，以确保正确处理。
The binding acknowledgement sent by the home agent module to the IPsec module is as follows:
归属代理模块发送到IPsec模块的绑定确认如下：
IPv6 header (src=HAADDR, dst=V6HOA)
IPv6标头（src=HAADDR，dst=V6HOA）
Mobility header
移动头
BA ([IPv4 ACK], NAT DET)
BA（[IPv4确认]，NAT检测）
(and others as needed)
（和其他需要的）
In addition, V4ADDR, the sport from the BU (Z), and an indication that UDP encapsulation must be used need to be passed with the packet to ensure correct processing.
此外，V4ADDR、来自BU（Z）的运动以及必须使用UDP封装的指示需要与数据包一起传递，以确保正确处理。
The binding acknowledgement sent by the home agent to the mobile node is as follows:
归属代理向移动节点发送的绑定确认如下：
IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
IPv4标头（src=HA_V4ADDR，dst=V4ADDR）
UDP header (sport=DSMIPv6, dport=Z)
UDP报头（sport=dsmpv6，dport=Z）
IPv6 header (src=HAADDR, dst=V6HOA)
IPv6标头（src=HAADDR，dst=V6HOA）
ESP header in transport mode
ESP标头处于传输模式
Mobility header
移动头
BA ([IPv4 ACK], NAT DET)
BA（[IPv4确认]，NAT检测）
To secure data traffic when the mobile node is located in an IPv4- only network, the mobile node MUST establish a child_SA for that purpose. Note that V4ADDR refers to either the mobile node's care-of address in the visited link or the public address allocated to the mobile node by the NAT. The procedure is as follows:
为了在移动节点位于仅IPv4的网络中时保护数据流量，移动节点必须为此目的建立子_SA。注意，V4ADDR指的是移动节点在访问链路中的转交地址，或者是NAT分配给移动节点的公共地址。程序如下：
Mobile Node Home Agent
----------- ----------
IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (4500,4500) < non-ESP Marker > HDR, SK
{[N], SA, Ni, [KEi], TSi, TSr} -->
Mobile Node Home Agent
----------- ----------
IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
UDP (4500,4500) < non-ESP Marker > HDR, SK
{[N], SA, Ni, [KEi], TSi, TSr} -->
<--IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP (4500,Y) < non-ESP Marker > HDR, SK
SA, Nr, [KEr], TSi, TSr}
<--IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
UDP (4500,Y) < non-ESP Marker > HDR, SK
SA, Nr, [KEr], TSi, TSr}
If no NAT is detected, the encapsulation used will be:
如果未检测到NAT，则使用的封装为：
IPv4 (source_addr=v4CoA, dest_addr=HAAddr)
IPv4（源地址=v4CoA，目标地址=HAAddr）
ESP
ESP
IP (source_addr=HoA, set_addr=CNAddr)
IP（源地址=HoA，集地址=CNAddr）
Upper_layer_HDR
上层
Where IP is either IPv4 or IPv6 and HoA is either the IPv4 HoA or the IPv6 HoA.
其中，IP为IPv4或IPv6，HoA为IPv4 HoA或IPv6 HoA。
If a NAT is detected, the encapsulation used will be:
如果检测到NAT，将使用以下封装：
IPv4 (source_addr=v4Addr, dest_addr=HAAddr)
IPv4（源地址=v4Addr，目标地址=HAAddr）
UDP (sport=Y, dport=4500)
UDP（运动=Y，dport=4500）
ESP
ESP
IP (source_addr=HoA, set_addr=CNAddr)
IP（源地址=HoA，集地址=CNAddr）
Upper_layer_HDR
上层
Where v4CoA may be the external IPv4 address of the NAT, IP is either an IPv4 or IPv6 header, and HoA is either the IPv4 or the IPv6 HoA. The above format shows the packet as seen by the home agent.
其中，v4CoA可能是NAT的外部IPv4地址，IP是IPv4或IPv6报头，HoA是IPv4或IPv6 HoA。上面的格式显示归属代理看到的数据包。
The SPD, whether a NAT is detected or not, is set as follows. Note that this rule is designed to match all data from the MN to nodes other than the home agent. This is done so that this rule does not overlap with the earlier rule securing BU/BA signaling between the MN and the HA.
无论是否检测到NAT，SPD设置如下。请注意，此规则旨在将MN中的所有数据与归属代理以外的节点进行匹配。这样做的目的是使该规则不与先前的保护MN和HA之间的BU/BA信令的规则重叠。
Mobile Node SPD-S:
移动节点SPD-S：
IF local_address = home_address &
如果本地地址=家庭地址&
remote_address != home_agent &
远程地址！=家政代理&
proto=any
proto=any
Then use SA ESP tunnel mode
然后使用SA ESP隧道模式
Initiate using IDi = user_1 to address home_agent_1
使用IDi=user_1初始化以寻址home_代理_1
home agent SPD-S:
归属代理SPD-S：
IF local_address != home_agent &
如果是本地地址！=家政代理&
remote_address = home_address &
远程地址=主地址&
proto=any
proto=any
Then use SA ESP tunnel mode
然后使用SA ESP隧道模式
Where home_address is the MN's registered IPv6 or IPv4 home address and home_agent is the IPv6 or the IPv4 address of the home agent.
其中home_address是MN注册的IPv6或IPv4 home address，home_agent是home agent的IPv6或IPv4地址。
NATKATIMEOUT = 110 seconds.
NATKATIMEOUT=110秒。
Thanks to the following members (in alphabetical order) of the MIP6 and NEMO Working Groups for their contributions, discussions, and reviews: Jari Arkko, Sri Gundavelli, Wassim Haddad, Alfred Hoenes, Conny Larsson, Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen, and Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen, and Christian Kaas-Petersen for raising the issue of IKEv2 interactions and proposing the solution included in this document. Thanks to Pasi Eronen for many thorough reviews of this document.
感谢MIP6和NEMO工作组的以下成员（按字母顺序）的贡献、讨论和评论：贾里·阿尔科、斯里·冈达维利、瓦西姆·哈达德、阿尔弗雷德·霍恩斯、康尼·拉尔森、亚齐·林登、艾哈迈德·穆汉纳、维迪亚·纳拉亚南、卡伦·尼尔森和石庆一。感谢Karen Nielsen、Pasi Eronen和Christian Kaas Petersen提出IKEv2交互问题并提出本文档中包含的解决方案。感谢Pasi Eronen对本文件进行了全面的审查。
IANA has made the following allocations according to this specification:
IANA已根据本规范进行了以下分配：
A UDP port (4191) has been assigned for the NAT traversal mechanism described in Section 4.2.
已为第4.2节中描述的NAT遍历机制分配了UDP端口（4191）。
The IPv4 home address option described in Section 3.1.1 has been assigned value 29. This option is included in the mobility header described in [RFC3775].
已为第3.1.1节中描述的IPv4家庭地址选项分配了值29。此选项包含在[RFC3775]中描述的移动标头中。
The IPv4 address acknowledgement option described in Section 3.2.1 has been assigned value 29. This option is included in the mobility header described in [RFC3775].
第3.2.1节中描述的IPv4地址确认选项已分配值29。此选项包含在[RFC3775]中描述的移动标头中。
The NAT detection option described in Section 3.2.2 has been assigned a value 31. This option is included in the mobility header described in [RFC3775].
第3.2.2节中描述的NAT检测选项已分配值31。此选项包含在[RFC3775]中描述的移动标头中。
The IPv4 care-of address option described in Section 3.1.2 has been assigned value 32. This option is included in the mobility header described in [RFC3775].
第3.1.2节中描述的IPv4转交地址选项已分配值32。此选项包含在[RFC3775]中描述的移动标头中。
The status field in the IPv4 home address option has been allocated by IANA under the new registry: "DSMIPv6 IPv4 Home Address Option Status Codes".
IANA已在新注册表下分配了IPv4家庭地址选项中的状态字段：“DSMPv6 IPv4家庭地址选项状态代码”。
The status field values are allocated using the following procedure:
使用以下步骤分配状态字段值：
1. New status field values are allocated through IETF review. This is for all RFC types including standards track, informational, and experimental status that originate from the IETF and have been approved by the IESG for publication.
1. 通过IETF审查分配新的状态字段值。这适用于所有RFC类型，包括源于IETF并经IESG批准发布的标准跟踪、信息和实验状态。
2. Requests for new option type value assignments from outside the IETF are only made through the publication of an IETF document, per 1 above. Note also that documents published as Independent "RFC Editor contributions" [RFC4844] are not considered to be IETF documents.
2. 根据上述第1条，只有通过发布IETF文件，才能从IETF外部请求新的选项类型值分配。另请注意，作为独立的“RFC编辑器贡献”[RFC4844]发布的文件不被视为IETF文件。
[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月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[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月。
[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月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[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月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436]Aboba，B.，Carlson，J.，和S.Cheshire，“检测IPv4中的网络连接（DNAv4）”，RFC 44362006年3月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC4555，2006年6月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877]Devarapalli，V.和F.Dupont，“使用IKEv2的移动IPv6操作和修订的IPsec架构”，RFC 4877，2007年4月。
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026]Giaretta，G.，Ed.，Kempf，J.，和V.Devarapalli，Ed.，“拆分场景中的移动IPv6引导”，RFC 5026，2007年10月。
[CHOWDHURY] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[CHOWDHURY]CHOWDHURY，K.和A.Yegin，“集成场景的MIP6引导”，正在进行的工作，2008年4月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，Ed.，“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月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]Savola，P.，“网络隧道中的MTU和碎片问题”，RFC 4459，2006年4月。
[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.
[RFC4844]Daigle，L.，Ed.，和互联网架构委员会，“RFC系列和RFC编辑器”，RFC 48442007年7月。
[RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual Stack Mobility", RFC 4977, August 2007.
[RFC4977]Tsirtsis，G.和H.Soliman，“问题陈述：双堆栈移动性”，RFC 4977，2007年8月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380]Soliman，H.，Castelluccia，C.，ElMalki，K.，和L.Bellier，“分层移动IPv6（HMIPv6）移动性管理”，RFC 53802008年10月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
This document reflects discussions and contributions from several people including (in alphabetical order):
本文件反映了几个人的讨论和贡献，包括（按字母顺序排列）：
Vijay Devarapalli: vijay.devarapalli@azairenet.com
维杰·德瓦拉帕利：维杰。devarapalli@azairenet.com
James Kempf: kempf@docomolabs-usa.com
詹姆斯·坎普夫：kempf@docomolabs-美国网
Henrik Levkowetz: henrik@levkowetz.com
Henrik Levkowetz：henrik@levkowetz.com
Pascal Thubert: pthubert@cisco.com
帕斯卡·苏伯特：pthubert@cisco.com
George Tsirtsis: G.Tsirtsis@Qualcomm.com
乔治·齐尔蒂斯：G。Tsirtsis@Qualcomm.com
Ryuji Wakikawa: ryuji@sfc.wide.ad.jp
若川龙治：ryuji@sfc.wide.ad.jp
Author's Address
作者地址
Hesham Soliman (editor) Elevate Technologies
Hesham Soliman（编辑）提升技术
EMail: hesham@elevatemobile.com
EMail: hesham@elevatemobile.com