Network Working Group G. Montenegro, Editor
Request for Comments: 3024 Sun Microsystems, Inc.
Obsoletes: 2344 January 2001
Category: Standards Track
Network Working Group G. Montenegro, Editor
Request for Comments: 3024 Sun Microsystems, Inc.
Obsoletes: 2344 January 2001
Category: Standards Track
Reverse Tunneling for Mobile IP, revised
移动IP反向隧道，修订版
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) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
Mobile Internet Protocol (IP) uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent.
移动互联网协议（IP）使用从归属代理到移动节点转交地址的隧道，但很少反向。通常，移动节点通过外部网络上的路由器发送数据包，并假定路由独立于源地址。当该假设不成立时，可以方便地建立从转交地址到归属代理的拓扑正确的反向隧道。
This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address.
本文档建议对移动IP进行向后兼容的扩展，以支持拓扑正确的反向隧道。本文档并不试图解决位于归属代理和移动节点转交地址之间的防火墙所带来的问题。
This document obsoletes RFC 2344.
本文件淘汰RFC 2344。
Table of Contents
目录
1. Introduction ................................................... 3
1.1. Terminology .................................................. 4
1.2. Assumptions .................................................. 4
1.3. Justification ................................................ 5
2. Overview ....................................................... 5
3. New Packet Formats ............................................. 6
3.1. Mobility Agent Advertisement Extension ....................... 6
3.2. Registration Request ......................................... 6
3.3. Encapsulating Delivery Style Extension ....................... 7
3.4. New Registration Reply Codes ................................. 8
4. Changes in Protocol Behavior ................................... 9
4.1. Mobile Node Considerations ................................... 9
4.1.1. Sending Registration Requests to the Foreign Agent ......... 9
4.1.2. Receiving Registration Replies from the Foreign Agent ...... 10
4.2. Foreign Agent Considerations ................................. 10
4.2.1. Receiving Registration Requests from the Mobile Node ....... 11
4.2.2. Relaying Registration Requests to the Home Agent ........... 11
4.3. Home Agent Considerations .................................... 11
4.3.1. Receiving Registration Requests from the Foreign Agent ..... 12
4.3.2. Sending Registration Replies to the Foreign Agent .......... 12
5. Mobile Node to Foreign Agent Delivery Styles ................... 13
5.1. Direct Delivery Style ........................................ 13
5.1.1. Packet Processing .......................................... 13
5.1.2. Packet Header Format and Fields ............................ 13
5.2. Encapsulating Delivery Style ................................. 14
5.2.1 Packet Processing ........................................... 14
5.2.2. Packet Header Format and Fields ............................ 15
5.3. Support for Broadcast and Multicast Datagrams ................ 16
5.4. Selective Reverse Tunneling .................................. 16
6. Security Considerations ........................................ 17
6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ....... 17
6.2. Ingress Filtering ............................................ 18
6.3. Reverse Tunneling for Disparate Address Spaces ............... 18
7. IANA Considerations ............................................ 18
8. Acknowledgements ............................................... 18
References ........................................................ 19
Editor and Chair Addresses ........................................ 20
Appendix A: Disparate Address Space Support ....................... 21
A.1. Scope of the Reverse Tunneling Solution ................... 21
A.2. Terminating Forward Tunnels at the Foreign Agent .......... 24
A.3. Initiating Reverse Tunnels at the Foreign Agent ........... 26
A.4. Limited Private Address Scenario .......................... 26
Appendix B: Changes from RFC2344 .................................. 29
Full Copyright Statement .......................................... 30
1. Introduction ................................................... 3
1.1. Terminology .................................................. 4
1.2. Assumptions .................................................. 4
1.3. Justification ................................................ 5
2. Overview ....................................................... 5
3. New Packet Formats ............................................. 6
3.1. Mobility Agent Advertisement Extension ....................... 6
3.2. Registration Request ......................................... 6
3.3. Encapsulating Delivery Style Extension ....................... 7
3.4. New Registration Reply Codes ................................. 8
4. Changes in Protocol Behavior ................................... 9
4.1. Mobile Node Considerations ................................... 9
4.1.1. Sending Registration Requests to the Foreign Agent ......... 9
4.1.2. Receiving Registration Replies from the Foreign Agent ...... 10
4.2. Foreign Agent Considerations ................................. 10
4.2.1. Receiving Registration Requests from the Mobile Node ....... 11
4.2.2. Relaying Registration Requests to the Home Agent ........... 11
4.3. Home Agent Considerations .................................... 11
4.3.1. Receiving Registration Requests from the Foreign Agent ..... 12
4.3.2. Sending Registration Replies to the Foreign Agent .......... 12
5. Mobile Node to Foreign Agent Delivery Styles ................... 13
5.1. Direct Delivery Style ........................................ 13
5.1.1. Packet Processing .......................................... 13
5.1.2. Packet Header Format and Fields ............................ 13
5.2. Encapsulating Delivery Style ................................. 14
5.2.1 Packet Processing ........................................... 14
5.2.2. Packet Header Format and Fields ............................ 15
5.3. Support for Broadcast and Multicast Datagrams ................ 16
5.4. Selective Reverse Tunneling .................................. 16
6. Security Considerations ........................................ 17
6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ....... 17
6.2. Ingress Filtering ............................................ 18
6.3. Reverse Tunneling for Disparate Address Spaces ............... 18
7. IANA Considerations ............................................ 18
8. Acknowledgements ............................................... 18
References ........................................................ 19
Editor and Chair Addresses ........................................ 20
Appendix A: Disparate Address Space Support ....................... 21
A.1. Scope of the Reverse Tunneling Solution ................... 21
A.2. Terminating Forward Tunnels at the Foreign Agent .......... 24
A.3. Initiating Reverse Tunnels at the Foreign Agent ........... 26
A.4. Limited Private Address Scenario .......................... 26
Appendix B: Changes from RFC2344 .................................. 29
Full Copyright Statement .......................................... 30
Section 1.3 of the Mobile IP specification [1] lists the following assumption:
移动IP规范[1]第1.3节列出了以下假设：
It is assumed that IP unicast datagrams are routed based on the destination address in the datagram header (i.e., not by source address).
假设IP单播数据报是基于数据报报头中的目的地地址（即，不是通过源地址）路由的。
Because of security concerns (for example, IP spoofing attacks), and in accordance with RFC 2267 [8] and CERT [3] advisories to this effect, routers that break this assumption are increasingly more common.
出于安全考虑（例如，IP欺骗攻击），根据RFC 2267[8]和CERT[3]的建议，打破这一假设的路由器越来越常见。
In the presence of such routers, the source and destination IP address in a packet must be topologically correct. The forward tunnel complies with this, as its endpoints (home agent address and care-of address) are properly assigned addresses for their respective locations. On the other hand, the source IP address of a packet transmitted by the mobile node does not correspond to the network prefix from where it emanates.
在存在此类路由器的情况下，数据包中的源和目标IP地址必须在拓扑上正确。转发隧道符合这一点，因为其端点（归属代理地址和转交地址）是为其各自位置正确分配的地址。另一方面，由移动节点发送的分组的源IP地址不对应于其发出的网络前缀。
This document discusses topologically correct reverse tunnels.
本文档讨论拓扑正确的反向隧道。
Mobile IP does dictate the use of reverse tunnels in the context of multicast datagram routing and mobile routers. However, the source IP address is set to the mobile node's home address, so these tunnels are not topologically correct.
移动IP确实规定了在多播数据报路由和移动路由器的上下文中使用反向隧道。但是，源IP地址设置为移动节点的主地址，因此这些隧道在拓扑上不正确。
Notice that there are several uses for reverse tunnels regardless of their topological correctness:
请注意，反向隧道有多种用途，无论其拓扑正确性如何：
- Mobile routers: reverse tunnels obviate the need for recursive tunneling [1].
- 移动路由器：反向隧道消除了递归隧道的需要[1]。
- Multicast: reverse tunnels enable a mobile node away from home to (1) join multicast groups in its home network, and (2) transmit multicast packets such that they emanate from its home network [1].
- 多播：反向隧道使远离家乡的移动节点能够（1）加入其家庭网络中的多播组，以及（2）传输多播数据包，以便它们从其家庭网络发出[1]。
- The TTL of packets sent by the mobile node (for example, when sending packets to other hosts in its home network) may be so low that they might expire before reaching their destination. A reverse tunnel solves the problem as it represents a TTL decrement of one [5].
- 由移动节点发送的分组的TTL（例如，当向其家庭网络中的其他主机发送分组时）可能很低，以至于它们可能在到达目的地之前过期。反向隧道解决了这个问题，因为它表示TTL减量为1[5]。
The discussion below uses terms defined in the Mobile IP specification. Additionally, it uses the following terms:
下面的讨论使用了移动IP规范中定义的术语。此外，它还使用以下术语：
Forward Tunnel
前方隧道
A tunnel that shuttles packets towards the mobile node. It starts at the home agent, and ends at the mobile node's care-of address.
将数据包传送到移动节点的隧道。它从归属代理开始，在移动节点的转交地址结束。
Reverse Tunnel
反向隧道
A tunnel that starts at the mobile node's care-of address and terminates at the home agent.
从移动节点的转交地址开始并在归属代理处终止的隧道。
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 RFC 2119 [9].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[9]中所述进行解释。
Mobility is constrained to a common IP address space (that is, the routing fabric between, say, the mobile node and the home agent is not partitioned into a "private" and a "public" network).
移动性受限于公共IP地址空间（即，例如，移动节点和归属代理之间的路由结构未划分为“专用”和“公用”网络）。
This document does not attempt to solve the firewall traversal problem. Rather, it assumes one of the following is true:
本文档并不试图解决防火墙穿越问题。相反，它假设以下情况之一为真：
- There are no intervening firewalls along the path of the tunneled packets.
- 在隧道数据包的路径上没有中间防火墙。
- Any intervening firewalls share the security association necessary to process any authentication [6] or encryption [7] headers which may have been added to the tunneled packets.
- 任何介入防火墙共享处理可能已添加到隧道数据包的任何身份验证[6]或加密[7]头所需的安全关联。
The reverse tunnels considered here are symmetric, that is, they use the same configuration (encapsulation method, IP address endpoints) as the forward tunnel. IP in IP encapsulation [2] is assumed unless stated otherwise.
这里考虑的反向隧道是对称的，也就是说，它们使用与正向隧道相同的配置（封装方法、IP地址端点）。除非另有说明，否则假定IP封装[2]中的IP。
Route optimization [4] introduces forward tunnels initiated at a correspondent host. Since a mobile node may not know if the correspondent host can decapsulate packets, reverse tunnels in that context are not discussed here.
路由优化[4]引入了在对应主机上启动的前向隧道。由于移动节点可能不知道对应主机是否可以解除分组封装，因此在此不讨论该上下文中的反向隧道。
Why not let the mobile node itself initiate the tunnel to the home agent? This is indeed what it should do if it is already operating with a topologically correct co-located care-of address.
为什么不让移动节点本身启动到归属代理的隧道？这确实是它应该做的，如果它已经使用一个拓扑正确的同一位置的转交地址运行。
However, one of the primary objectives of the Mobile IP specification is not to require this mode of operation.
然而，移动IP规范的主要目标之一是不需要这种操作模式。
The mechanisms outlined in this document are primarily intended for use by mobile nodes that rely on the foreign agent for forward tunnel support. It is desirable to continue supporting these mobile nodes, even in the presence of filtering routers.
本文档中概述的机制主要用于依赖外部代理进行前向隧道支持的移动节点。希望继续支持这些移动节点，即使存在过滤路由器。
A mobile node arrives at a foreign network, listens for agent advertisements and selects a foreign agent that supports reverse tunnels. It requests this service when it registers through the selected foreign agent. At this time, and depending on how the mobile node wishes to deliver packets to the foreign agent, it also requests either the Direct or the Encapsulating Delivery Style (section 5).
移动节点到达外部网络，侦听代理播发并选择支持反向隧道的外部代理。它通过选定的外部代理注册时请求此服务。此时，并且取决于移动节点希望如何向外部代理递送数据包，它还请求直接递送或封装递送样式（第5节）。
In the Direct Delivery Style, the mobile node designates the foreign agent as its default router and proceeds to send packets directly to the foreign agent, that is, without encapsulation. The foreign agent intercepts them, and tunnels them to the home agent.
在直接传递样式中，移动节点将外部代理指定为其默认路由器，并继续直接向外部代理发送数据包，即不进行封装。外国特工截获了他们，并通过隧道将他们交给本国特工。
In the Encapsulating Delivery Style, the mobile node encapsulates all its outgoing packets to the foreign agent. The foreign agent decapsulates and re-tunnels them to the home agent, using the foreign agent's care-of address as the entry-point of this new tunnel.
在封装传递样式中，移动节点将其所有传出数据包封装到外部代理。外国代理使用外国代理的转交地址作为此新隧道的入口点，将其解封并重新隧道至本国代理。
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|V|T| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|V|T| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
The only change to the Mobility Agent Advertisement Extension [1] is the additional 'T' bit:
Mobility Agent广告扩展[1]的唯一更改是附加的“T”位：
T Agent offers reverse tunneling service.
T代理提供反向隧道服务。
A foreign agent that sets the 'T' bit MUST support the Direct Delivery Style. Encapsulating Delivery Style SHOULD be supported as well (section 5).
设置“T”位的外部代理必须支持直接交付样式。还应支持封装交付样式（第5节）。
Using this information, a mobile node is able to choose a foreign agent that supports reverse tunnels. Notice that if a mobile node does not understand this bit, it simply ignores it as per [1].
使用此信息，移动节点能够选择支持反向隧道的外部代理。请注意，如果移动节点不理解该位，它将根据[1]忽略该位。
Reverse tunneling support is added directly into the Registration Request by using one of the "rsvd" bits. If a foreign or home agent that does not support reverse tunnels receives a request with the 'T' bit set, the Registration Request fails. This results in a registration denial (failure codes are specified in section 3.4).
反向隧道支持通过使用“rsvd”位之一直接添加到注册请求中。如果不支持反向隧道的外国或本国代理接收到设置了“T”位的请求，则注册请求失败。这将导致注册被拒绝（第3.4节规定了故障代码）。
Home agents SHOULD NOT object to providing reverse tunnel support, because they "SHOULD be able to decapsulate and further deliver packets addressed to themselves, sent by a mobile node" [1]. In the case of topologically correct reverse tunnels, the packets are not sent by the mobile node as distinguished by its home address. Rather, the outermost (encapsulating) IP source address on such datagrams is the care-of address of the mobile node.
归属代理不应反对提供反向隧道支持，因为它们“应该能够解除封装，并进一步传递由移动节点发送给自己的数据包”[1]。在拓扑正确的反向隧道的情况下，分组不是由移动节点发送的，因为移动节点通过其归属地址进行区分。相反，这种数据报上最外层（封装）的IP源地址是移动节点的转交地址。
In Registration Requests sent by a mobile node, the Time to Live field in the IP header MUST be set to 255. This limits a denial of service attack in which malicious hosts send false Registration Requests (see Section 6).
在移动节点发送的注册请求中，IP头中的生存时间字段必须设置为255。这限制了恶意主机发送虚假注册请求的拒绝服务攻击（请参阅第6节）。
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 |S|B|D|M|G|V|T|-| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
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 |S|B|D|M|G|V|T|-| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
The only change to the Registration Request packet is the additional 'T' bit:
对注册请求数据包的唯一更改是附加的“T”位：
T If the 'T' bit is set, the mobile node asks its home agent to accept a reverse tunnel from the care-of address. Mobile nodes using a foreign agent care-of address ask the foreign agent to reverse-tunnel its packets.
T如果设置了“T”位，则移动节点要求其归属代理接受来自转交地址的反向隧道。使用外部代理转交地址的移动节点要求外部代理反向隧道其数据包。
The Encapsulating Delivery Style Extension MAY be included by the mobile node in registration requests to further specify reverse tunneling behavior. It is expected to be used only by the foreign agent. Accordingly, the foreign agent MUST consume this extension (that is, it must not relay it to the home agent or include it in replies to the mobile node). As per Section 3.6.1.3 of [1], the mobile node MUST include the Encapsulating Delivery Style Extension after the Mobile-Home Authentication Extension, and before the Mobile-Foreign Authentication Extension, if present.
移动节点可以在注册请求中包括封装传递样式扩展，以进一步指定反向隧道行为。预计只能由外国代理商使用。因此，外部代理必须使用该扩展（即，它不得将其中继到归属代理或将其包括在对移动节点的应答中）。根据[1]的第3.6.1.3节，移动节点必须在移动归属认证扩展之后、移动外部认证扩展之前（如果存在）包含封装交付样式扩展。
The Encapsulating Delivery Style Extension MUST NOT be included if the 'T' bit is not set in the Registration Request.
如果在注册请求中未设置“T”位，则封装传递样式扩展不得包括在内。
If this extension is absent, Direct Delivery is assumed. Encapsulation is done according to what was negotiated for the forward tunnel (that is, IP in IP is assumed unless specified otherwise). For more details on the delivery styles, please refer to section 5.
如果没有此扩展，则假定直接交付。封装是根据为转发隧道协商的内容进行的（即，除非另有规定，否则假定IP中的IP）。有关交付样式的更多详细信息，请参阅第5节。
Foreign agents SHOULD support the Encapsulating Delivery Style Extension.
外部代理应支持封装交付样式扩展。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
130
130
Length
长
0
0
Foreign and home agent registration replies MUST convey if the reverse tunnel request failed. These new reply codes are defined:
如果反向隧道请求失败，外国和本国代理注册回复必须传达。这些新的回复代码定义如下：
Service denied by the foreign agent:
外国代理拒绝的服务：
74 requested reverse tunnel unavailable 75 reverse tunnel is mandatory and 'T' bit not set 76 mobile node too distant 79 delivery style not supported
74请求的反向通道不可用75反向通道是必需的，未设置“T”位76移动节点太远79不支持传递样式
NOTE: Code 79 has not yet been assigned by IANA.
注：IANA尚未分配代码79。
and
和
Service denied by the home agent:
本地代理拒绝的服务：
137 requested reverse tunnel unavailable 138 reverse tunnel is mandatory and 'T' bit not set 139 requested encapsulation unavailable
137请求的反向通道不可用138反向通道是必需的且未设置“T”位139请求的封装不可用
In response to a Registration Request with the 'T' bit set, mobile nodes may receive (and MUST accept) code 70 (poorly formed request) from foreign agents and code 134 (poorly formed request) from home agents. However, foreign and home agents that support reverse tunneling MUST use codes 74 and 137, respectively.
响应于设置了“T”位的注册请求，移动节点可以从外部代理接收（并且必须接受）代码70（格式不良的请求），从本地代理接收（并且必须接受）代码134（格式不良的请求）。但是，支持反向隧道的外国和本国代理必须分别使用代码74和137。
In addition to setting the 'T' bit, the mobile node also MAY request the Encapsulating Delivery Style by including the corresponding extension. If a foreign agent does not implement the Encapsulating
除了设置“T”位之外，移动节点还可以通过包括相应的扩展来请求封装传递样式。如果外部代理未实现封装
Delivery Style, it MUST respond to the mobile node with code 79 (delivery style not supported). This also applies if the foreign agent does not support a requested delivery style that may be defined in the future.
传递样式，它必须以代码79响应移动节点（不支持传递样式）。如果外部代理不支持将来可能定义的请求的交付样式，这也适用。
Absence of the 'T' bit in a Registration Request MAY elicit denials with codes 75 and 138 at the foreign agent and the home agent, respectively.
注册请求中缺少“T”位可能导致外国代理和本国代理分别拒绝代码为75和138的申请。
Forward and reverse tunnels are symmetric, that is, both are able to use the same tunneling options negotiated at registration. This implies that the home agent MUST deny registrations if an unsupported form of tunneling is requested (code 139). Notice that Mobile IP [1] already defines the analogous failure code 72 for use by the foreign agent.
正向和反向隧道是对称的，也就是说，两者都能够使用注册时协商的相同隧道选项。这意味着，如果请求不受支持的隧道形式，则归属代理必须拒绝注册（代码139）。请注意，移动IP[1]已经定义了类似的故障代码72，以供外部代理使用。
Unless otherwise specified, behavior specified by Mobile IP [1] is assumed. In particular, if any two entities share a mobility security association, they MUST use the appropriate Authentication Extension (Mobile-Foreign, Foreign-Home or Mobile-Home Authentication Extension) when exchanging registration protocol datagrams. An admissible authentication extension (for example the Mobile-Home Authentication Extension) MUST always be present to authenticate registration messages between a mobile node and its home agent.
除非另有规定，否则假定移动IP[1]规定的行为。特别是，如果任何两个实体共享移动安全关联，则它们在交换注册协议数据报时必须使用适当的身份验证扩展（移动外部、外部家庭或移动家庭身份验证扩展）。必须始终存在可接受的认证扩展（例如移动归属认证扩展），以认证移动节点及其归属代理之间的注册消息。
Reverse tunneling imposes additional protocol processing requirements on mobile entities. Differences in protocol behavior with respect to Mobile IP [1] are specified in the subsequent sections.
反向隧道对移动实体提出了额外的协议处理要求。关于移动IP[1]的协议行为差异在后续章节中有详细说明。
This section describes how the mobile node handles registrations that request a reverse tunnel.
本节描述移动节点如何处理请求反向隧道的注册。
In addition to the considerations in [1], a mobile node sets the 'T' bit in its Registration Request to petition a reverse tunnel.
除了[1]中的注意事项外，移动节点在其注册请求中设置“T”位以请求反向隧道。
The mobile node MUST set the TTL field of the IP header to 255. This is meant to limit the reverse tunnel hijacking attack (Section 6).
移动节点必须将IP头的TTL字段设置为255。这是为了限制反向隧道劫持攻击（第6节）。
The mobile node MAY optionally include an Encapsulating Delivery Style Extension.
移动节点可任选地包括封装递送样式扩展。
Possible valid responses are:
可能的有效答复如下：
- A registration denial issued by either the home agent or the foreign agent:
- 由本国代理或外国代理签发的注册拒绝：
a. The mobile node follows the error checking guidelines in [1], and depending on the reply code, MAY try modifying the registration request (for example, by eliminating the request for alternate forms of encapsulation or delivery style), and issuing a new registration.
a. 移动节点遵循[1]中的错误检查准则，并且根据回复代码，可以尝试修改注册请求（例如，通过消除对其他封装形式或交付样式的请求），并发布新的注册。
b. Depending on the reply code, the mobile node MAY try zeroing the 'T' bit, eliminating the Encapsulating Delivery Style Extension (if one was present), and issuing a new registration. Notice that after doing so the registration may succeed, but due to the lack of a reverse tunnel data transfer may not be possible.
b. 根据回复代码，移动节点可能会尝试将“T”位归零，消除封装传递样式扩展（如果存在），并发出新的注册。请注意，这样做后，注册可能会成功，但由于缺少反向通道，可能无法进行数据传输。
- The home agent returns a Registration Reply indicating that the service will be provided.
- 归属代理返回一个注册回复，指示将提供该服务。
In this last case, the mobile node has succeeded in establishing a reverse tunnel between its care-of address and its home agent. If the mobile node is operating with a co-located care-of address, it MAY encapsulate outgoing data such that the destination address of the outer header is the home agent. This ability to selectively reverse-tunnel packets is discussed further in section 5.4.
在最后一种情况下，移动节点成功地在其转交地址和其归属代理之间建立了反向隧道。如果移动节点使用共同定位的转交地址操作，则其可以封装传出数据，使得外部报头的目的地地址是归属代理。第5.4节将进一步讨论选择性反转隧道数据包的能力。
If the care-of address belongs to a separate foreign agent, the mobile node MUST employ whatever delivery style was requested (Direct or Encapsulating) and proceed as specified in section 5.
如果转交地址属于单独的外部代理，则移动节点必须采用所请求的任何交付方式（直接或封装），并按照第5节的规定进行处理。
A successful registration reply is an assurance that both the foreign agent and the home agent support whatever alternate forms of encapsulation (other than IP in IP) were requested. Accordingly, the mobile node MAY use them at its discretion.
成功的注册回复保证了外国代理和本国代理都支持所请求的任何其他封装形式（IP中的IP除外）。因此，移动节点可自行决定使用它们。
This section describes how the foreign agent handles registrations that request a reverse tunnel.
本节描述外部代理如何处理请求反向隧道的注册。
A foreign agent that receives a Registration Request with the 'T' bit set processes the packet as specified in the Mobile IP specification [1], and determines whether it can accommodate the forward tunnel request. If it cannot, it returns an appropriate code. In particular, if the foreign agent is unable to support the requested form of encapsulation it MUST return code 72. If it cannot support the requested form of delivery style it MUST return code 79 (delivery style not supported).
接收具有“T”位集的注册请求的外部代理按照移动IP规范[1]中的规定处理数据包，并确定其是否能够容纳前向隧道请求。如果不能，则返回相应的代码。特别是，如果外部代理无法支持请求的封装形式，它必须返回代码72。如果它不能支持所请求的交付样式形式，则必须返回代码79（不支持交付样式）。
The foreign agent MAY reject Registration Requests without the 'T' bit set by denying them with code 75 (reverse tunnel is mandatory and 'T' bit not set).
外国代理可以通过代码75拒绝未设置“T”位的注册请求（反向隧道是强制性的，未设置“T”位）。
The foreign agent MUST verify that the TTL field of the IP header is set to 255. Otherwise, it MUST reject the registration with code 76 (mobile node too distant). The foreign agent MUST limit the rate at which it sends these registration replies to a maximum of one per second.
外部代理必须验证IP标头的TTL字段是否设置为255。否则，它必须拒绝代码为76的注册（移动节点太远）。外国代理必须将其发送这些注册回复的速率限制为每秒最多一次。
As a last check, the foreign agent verifies that it can support a reverse tunnel with the same configuration. If it cannot, it MUST return a Registration Reply denying the request with code 74 (requested reverse tunnel unavailable).
作为最后一项检查，外部代理验证它是否可以支持具有相同配置的反向隧道。如果不能，则必须返回注册回复，拒绝代码为74的请求（请求的反向隧道不可用）。
Otherwise, the foreign agent MUST relay the Registration Request to the home agent.
否则，外国代理必须将注册请求转发给本国代理。
Upon receipt of a Registration Reply that satisfies validity checks, the foreign agent MUST update its visitor list, including indication that this mobile node has been granted a reverse tunnel and the delivery style expected (section 5).
在收到满足有效性检查的注册回复后，外国代理必须更新其访客列表，包括该移动节点已被授予反向隧道和预期交付方式的指示（第5节）。
While this visitor list entry is in effect, the foreign agent MUST process incoming traffic according to the delivery style, encapsulate it and tunnel it from the care-of address to the home agent's address.
当此访客列表条目生效时，外国代理必须根据交付样式处理传入流量，将其封装并将其从转交地址传输到本国代理的地址。
This section describes how the home agent handles registrations that request a reverse tunnel.
本节描述归属代理如何处理请求反向隧道的注册。
A home agent that receives a Registration Request with the 'T' bit set processes the packet as specified in the Mobile IP specification [1] and determines whether it can accommodate the forward tunnel request. If it cannot, it returns an appropriate code. In particular, if the home agent is unable to support the requested form of encapsulation it MUST return code 139 (requested encapsulation unavailable).
接收具有“T”比特集的注册请求的归属代理按照移动IP规范[1]中的规定处理分组，并确定其是否能够容纳前向隧道请求。如果不能，则返回相应的代码。特别是，如果归属代理无法支持请求的封装形式，它必须返回代码139（请求的封装不可用）。
The home agent MAY reject registration requests without the 'T' bit set by denying them with code 138 (reverse tunnel is mandatory and ' T' bit not set).
归属代理可以通过使用代码138拒绝未设置“T”位的注册请求（反向隧道是强制性的，未设置“T”位）。
As a last check, the home agent determines whether it can support a reverse tunnel with the same configuration as the forward tunnel. If it cannot, it MUST send back a registration denial with code 137 (requested reverse tunnel unavailable).
作为最后一项检查，归属代理确定它是否可以支持与前向隧道具有相同配置的反向隧道。如果不能，则必须发回代码为137的注册拒绝（请求的反向隧道不可用）。
Upon receipt of a Registration Reply that satisfies validity checks, the home agent MUST update its mobility bindings list to indicate that this mobile node has been granted a reverse tunnel and the type of encapsulation expected.
在收到满足有效性检查的注册回复后，归属代理必须更新其移动绑定列表，以指示此移动节点已被授予反向隧道和预期的封装类型。
In response to a valid Registration Request, a home agent MUST issue a Registration Reply to the mobile node.
为了响应有效的注册请求，归属代理必须向移动节点发出注册回复。
After a successful registration, the home agent may receive encapsulated packets addressed to itself. Decapsulating such packets and blindly injecting them into the network is a potential security weakness (section 6.1). Accordingly, the home agent MUST implement, and, by default, SHOULD enable the following check for encapsulated packets addressed to itself:
在成功注册之后，归属代理可以接收寻址到自身的封装包。将此类数据包解封并将其盲目注入网络是一个潜在的安全弱点（第6.1节）。因此，归属代理必须实现，并且在默认情况下，应该启用以下针对寻址到自身的封装数据包的检查：
The home agent searches for a mobility binding whose care-of address is the source of the outer header, and whose mobile node address is the source of the inner header.
归属代理搜索其转交地址是外部报头的源并且其移动节点地址是内部报头的源的移动绑定。
If no such binding is found, or if the packet uses an encapsulation mechanism that was not negotiated at registration the home agent MUST silently discard the packet and SHOULD log the event as a security exception.
如果未找到此类绑定，或者如果数据包使用在注册时未协商的封装机制，则归属代理必须悄悄地丢弃该数据包，并应将该事件记录为安全异常。
Home agents that terminate tunnels unrelated to Mobile IP (for example, multicast tunnels) MAY turn off the above check, but this practice is discouraged for the aforementioned reasons.
终止与移动IP无关的隧道（例如，多播隧道）的归属代理可能会关闭上述检查，但出于上述原因，不鼓励这种做法。
While the registration is in effect, a home agent MUST process each valid reverse tunneled packet (as determined by checks like the above) by decapsulating it, recovering the original packet, and then forwarding it on behalf of its sender (the mobile node) to the destination address (the correspondent host).
当注册生效时，归属代理必须处理每个有效的反向隧道数据包（由上述检查确定），方法是将其解封，恢复原始数据包，然后代表其发送方（移动节点）将其转发到目标地址（对应主机）。
This section specifies how the mobile node sends its data traffic via the foreign agent. In all cases, the mobile node learns the foreign agent's link-layer address from the link-layer header in the agent advertisement.
本节指定移动节点如何通过外部代理发送其数据流量。在所有情况下，移动节点从代理广告中的链路层报头学习外部代理的链路层地址。
This delivery mechanism is very simple to implement at the mobile node, and uses small (non-encapsulated) packets on the link between the mobile node and the foreign agent (potentially a very slow link). However, it only supports reverse-tunneling of unicast packets, and does not allow selective reverse tunneling (section 5.4).
这种传递机制非常容易在移动节点上实现，并且在移动节点和外部代理（可能是非常慢的链路）之间的链路上使用小的（非封装的）数据包。但是，它只支持单播数据包的反向隧道，不允许选择性反向隧道（第5.4节）。
The mobile node MUST designate the foreign agent as its default router. Not doing so will not guarantee encapsulation of all the mobile node's outgoing traffic, and defeats the purpose of the reverse tunnel. The foreign agent MUST:
移动节点必须将外部代理指定为其默认路由器。不这样做将不能保证封装所有移动节点的传出流量，并破坏反向隧道的目的。外国代理人必须：
- detect packets sent by the mobile node, and
- 检测由移动节点发送的分组，以及
- modify its forwarding function to encapsulate them before forwarding.
- 修改其转发功能，以便在转发前对其进行封装。
This section shows the format of the packet headers used by the Direct Delivery style. The formats shown assume IP in IP encapsulation [2].
本节显示直接传递样式使用的数据包头的格式。所示格式假定IP封装中的IP[2]。
Packet format received by the foreign agent (Direct Delivery Style):
国外代理收到的数据包格式（直接交付方式）：
IP fields: Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol
IP字段：源地址=移动节点的家庭地址目标地址=对应主机的地址上层协议
Packet format forwarded by the foreign agent (Direct Delivery Style):
外部代理转发的数据包格式（直接交付方式）：
IP fields (encapsulating header): Source Address = foreign agent's care-of address Destination Address = home agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol
IP字段（封装标头）：源地址=外部代理的转交地址目标地址=归属代理的地址协议字段：4（IP中的IP）IP字段（原始标头）：源地址=移动节点的归属地址目标地址=对应主机的地址上层协议
These fields of the encapsulating header MUST be chosen as follows:
封装标头的这些字段必须按如下方式选择：
IP Source Address
IP源地址
Copied from the Care-of Address field within the Registration Request.
从注册请求中的转交地址字段复制。
IP Destination Address
IP目的地址
Copied from the Home Agent field within the most recent successful Registration Reply.
从最近成功注册回复中的“归属代理”字段复制。
IP Protocol Field
IP协议字段
Default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time.
默认值为4（IP中的IP[2]），但在注册时可以使用协商的其他封装方法。
This mechanism requires that the mobile node implement encapsulation, and explicitly directs packets at the foreign agent by designating it as the destination address in a new outermost header. Mobile nodes that wish to send either broadcast or multicast packets MUST use the Encapsulating Delivery Style.
该机制要求移动节点实现封装，并通过在新的最外层报头中将数据包指定为目标地址，显式地将数据包定向到外部代理。希望发送广播或多播数据包的移动节点必须使用封装传递样式。
The foreign agent does not modify its forwarding function. Rather, it receives an encapsulated packet and after verifying that it was sent by the mobile node, it:
外部代理不修改其转发功能。相反，它接收封装的分组，并且在验证它是由移动节点发送的之后，它：
- decapsulates to recover the inner packet,
- 解除封装以恢复内部数据包，
- re-encapsulates, and sends it to the home agent.
- 重新封装，并将其发送给home agent。
If a foreign agent receives an un-encapsulated packet from a mobile node which had explicitly requested the Encapsulated Delivery Style, then the foreign agent MUST NOT reverse tunnel such a packet and rather MUST forward it using standard, IP routing mechanisms.
如果外部代理从已明确请求封装传递样式的移动节点接收到未封装的数据包，则外部代理不得反向隧道这样的数据包，而必须使用标准的IP路由机制转发它。
This section shows the format of the packet headers used by the Encapsulating Delivery style. The formats shown assume IP in IP encapsulation [2].
本节显示封装传递样式使用的数据包头的格式。所示格式假定IP封装中的IP[2]。
Packet format received by the foreign agent (Encapsulating Delivery Style):
外部代理接收的数据包格式（封装交付样式）：
IP fields (encapsulating header): Source Address = mobile node's home address Destination Address = foreign agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol
IP字段（封装标头）：源地址=移动节点的家庭地址目标地址=外部代理的地址协议字段：4（IP中的IP）IP字段（原始标头）：源地址=移动节点的家庭地址目标地址=对应主机的地址上层协议
The fields of the encapsulating IP header MUST be chosen as follows:
封装IP报头的字段必须选择如下：
IP Source Address
IP源地址
The mobile node's home address.
移动节点的主地址。
IP Destination Address
IP目的地址
The address of the agent as learned from the IP source address of the agent's most recent successful registration reply.
从代理最近成功注册回复的IP源地址中得知的代理地址。
IP Protocol Field
IP协议字段
Default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time.
默认值为4（IP中的IP[2]），但在注册时可以使用协商的其他封装方法。
Packet format forwarded by the foreign agent (Encapsulating Delivery Style):
外部代理转发的数据包格式（封装交付样式）：
IP fields (encapsulating header): Source Address = foreign agent's care-of address Destination Address = home agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = correspondent host's address Upper Layer Protocol
IP字段（封装标头）：源地址=外部代理的转交地址目标地址=归属代理的地址协议字段：4（IP中的IP）IP字段（原始标头）：源地址=移动节点的归属地址目标地址=对应主机的地址上层协议
These fields of the encapsulating IP header MUST be chosen as follows:
封装IP报头的这些字段必须按如下方式选择：
IP Source Address
IP源地址
Copied from the Care-of Address field within the Registration Request.
从注册请求中的转交地址字段复制。
IP Destination Address
IP目的地址
Copied from the Home Agent field within the most recent successful Registration Reply.
从最近成功注册回复中的“归属代理”字段复制。
IP Protocol Field
IP协议字段
Default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time.
默认值为4（IP中的IP[2]），但在注册时可以使用协商的其他封装方法。
If a mobile node is operating with a co-located care-of address, broadcast and multicast datagrams are handled according to Sections 4.3 and 4.4 of the Mobile IP specification [1]. Mobile nodes using a foreign agent care-of address MAY have their broadcast and multicast datagrams reverse-tunneled by the foreign agent. However, any mobile nodes doing so MUST use the encapsulating delivery style.
如果移动节点使用同一位置的转交地址运行，则根据移动IP规范[1]第4.3节和第4.4节处理广播和多播数据报。使用外部代理转交地址的移动节点可以由外部代理对其广播和多播数据报进行反向隧道传输。但是，任何这样做的移动节点都必须使用封装传递样式。
This delivers the datagram only to the foreign agent. The latter decapsulates it and then processes it as any other packet from the mobile node, namely, by reverse tunneling it to the home agent.
这只将数据报传递给外部代理。后者将其解封，然后将其作为来自移动节点的任何其他数据包进行处理，即通过反向隧道将其传输到归属代理。
Packets destined to local resources (for example, a nearby printer) might be unaffected by ingress filtering. A mobile node with a co-located care-of address MAY optimize delivery of these packets by not reverse tunneling them. On the other hand, a mobile node using a foreign agent care-of address MAY use this selective reverse tunneling capability by requesting the Encapsulating Delivery Style, and following these guidelines:
发送到本地资源（例如，附近的打印机）的数据包可能不受入口过滤的影响。具有共同定位的转交地址的移动节点可以通过不反向隧道它们来优化这些分组的递送。另一方面，使用外部代理转交地址的移动节点可以通过请求封装交付样式并遵循以下准则来使用该选择性反向隧道功能：
Packets NOT meant to be reversed tunneled:
不打算反向隧道传输的数据包：
Sent using the Direct Delivery style. The foreign agent MUST process these packets as regular traffic: they MAY be forwarded but MUST NOT be reverse tunneled to the home agent.
使用直接送达方式发送。外部代理必须将这些数据包作为常规通信进行处理：它们可以被转发，但不能反向隧道到本地代理。
Packets meant to be reverse tunneled:
要反向隧道的数据包：
Sent using the Encapsulating Delivery style. The foreign agent MUST process these packets as specified in section 5.2: they MUST be reverse tunneled to the home agent.
使用封装传递样式发送。外部代理必须按照第5.2节的规定处理这些数据包：它们必须通过反向隧道传输到本地代理。
The extensions outlined in this document are subject to the security considerations outlined in the Mobile IP specification [1]. Essentially, creation of both forward and reverse tunnels involves an authentication procedure, which reduces the risk for attack.
本文档中概述的扩展受移动IP规范[1]中概述的安全注意事项的约束。本质上，创建正向和反向隧道都涉及身份验证过程，从而降低了攻击风险。
Once the tunnel is set up, a malicious node could hijack it to inject packets into the network. Reverse tunnels might exacerbate this problem, because upon reaching the tunnel exit point packets are forwarded beyond the local network. This concern is also present in the Mobile IP specification, as it already dictates the use of reverse tunnels for certain applications.
一旦建立了隧道，恶意节点可能会劫持它，将数据包注入网络。反向隧道可能会加剧此问题，因为到达隧道出口点后，数据包将转发到本地网络之外。移动IP规范中也存在这一问题，因为它已经规定在某些应用中使用反向隧道。
Unauthenticated exchanges involving the foreign agent allow a malicious node to pose as a valid mobile node and re-direct an existing reverse tunnel to another home agent, perhaps another malicious node. The best way to protect against these attacks is by employing the Mobile-Foreign and Foreign-Home Authentication Extensions defined in [1].
涉及外部代理的未经验证的交换允许恶意节点冒充有效的移动节点，并将现有反向隧道重新定向到另一个归属代理，可能是另一个恶意节点。防范这些攻击的最佳方法是使用[1]中定义的移动国外和国外家庭身份验证扩展。
If the necessary mobility security associations are not available, this document introduces a mechanism to reduce the range and effectiveness of the attacks. The mobile node MUST set to 255 the TTL value in the IP headers of Registration Requests sent to the foreign agent. This prevents malicious nodes more than one hop away from posing as valid mobile nodes. Additional codes for use in registration denials make those attacks that do occur easier to track.
如果没有必要的移动安全关联，本文档将引入一种机制来减少攻击的范围和有效性。移动节点必须将发送到外部代理的注册请求的IP头中的TTL值设置为255。这可以防止恶意节点冒充有效的移动节点一跳以上。在注册拒绝中使用的附加代码使那些确实发生的攻击更容易跟踪。
With the goal of further reducing the attacks the Mobile IP Working Group considered other mechanisms involving the use of unauthenticated state. However, these introduce the possibilities of denial-of-service attacks. The consensus was that this was too much of a trade-off for mechanisms that guarantee no more than weak (non-cryptographic) protection against attacks.
为了进一步减少攻击，移动IP工作组考虑了使用未经验证状态的其他机制。然而，这些都引入了拒绝服务攻击的可能性。大家一致认为，对于那些仅能保证针对攻击的弱（非加密）保护的机制来说，这是一种太多的折衷。
There has been some concern regarding the long-term effectiveness of reverse-tunneling in the presence of ingress filtering. The conjecture is that network administrators will target reverse-tunneled packets (IP in IP encapsulated packets) for filtering. The ingress filtering recommendation spells out why this is not the case [8]:
在存在入口过滤的情况下，存在一些关于反向隧道的长期有效性的担忧。推测是网络管理员将反向隧道包（IP封装包中的IP）作为过滤的目标。入口过滤建议阐明了为什么情况并非如此[8]：
Tracking the source of an attack is simplified when the source is more likely to be "valid."
当攻击源更有可能“有效”时，可以简化对攻击源的跟踪
There are security implications involved with the foreign agent's using link-layer information to select the proper reverse tunnel for mobile node packets (section A.3). Unauthenticated link-layers allow a malicious mobile node to misuse another's existing reverse tunnel, and inject packets into the network.
外部代理使用链路层信息为移动节点数据包选择适当的反向隧道涉及安全问题（第A.3节）。未经验证的链路层允许恶意移动节点滥用另一个现有的反向隧道，并将数据包注入网络。
For this solution to be viable, the link-layer MUST securely authenticate traffic received by the foreign agent from the mobile nodes. Unauthenticated link-layer technologies (for example shared ethernet) are not recommended to implement disparate address support.
为了使此解决方案可行，链路层必须安全地验证外部代理从移动节点接收的通信量。不建议使用未经验证的链路层技术（例如，共享以太网）来实现完全不同的地址支持。
The Encapsulating Delivery Style extension defined in section 3.3 is a Mobile IP registration extension as defined in [1]. IANA assigned the value of 130 for this purpose at the time of the publication of RFC 2344.
第3.3节中定义的封装交付样式扩展是[1]中定义的移动IP注册扩展。在发布RFC 2344时，IANA为此目的分配了130的值。
The Code values defined in section 3.4 are error codes as defined in [1]. They correspond to error values associated with rejection by the home and foreign agents. At the time of the publication of RFC 2344, IANA assigned codes 74-76 for the foreign agent rejections and codes 137-139 for the home agent rejections. The code for 'delivery style not supported' has been assigned a value of 79 by the IANA for this purpose.
第3.4节中定义的代码值是[1]中定义的错误代码。它们对应于与本国和外国代理拒绝相关的错误值。在RFC 2344发布时，IANA为外国代理拒绝分配代码74-76，为本国代理拒绝分配代码137-139。为此，IANA为“不支持交付样式”的代码分配了79的值。
The encapsulating style of delivery was proposed by Charlie Perkins. Jim Solomon has been instrumental in shaping this document into its present form. Thanks to Samita Chakrabarti for helpful comments on disparate address space support, and for most of the text in section A.4.
封装式交付是由Charlie Perkins提出的。吉姆·所罗门（Jim Solomon）在将本文件塑造成当前形式方面发挥了重要作用。感谢Samita Chakrabarti对不同地址空间支持的有用评论，以及第A.4节中的大部分文本。
References
工具书类
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[1] Perkins，C.，“IP移动支持”，RFC 2002，1996年10月。
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2] Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org in /pub/cert_advisories.
[3] 计算机应急响应小组（CERT），“IP欺骗攻击和被劫持的终端连接”，CA-95:01，1995年1月。可通过匿名ftp从info.cert.org的/pub/cert\u advisories获得。
[4] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.
[4] Perkins，C.和D.Johnson，“移动IP中的路由优化”，正在进行中。
[5] Manuel Rodriguez, private communication, August 1995.
[5] Manuel Rodriguez，《私人通讯》，1995年8月。
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[6] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[7] Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC 2406, November 1998.
[7] Kent，S.和R.Atkinson，“IP封装有效载荷”，RFC 2406，1998年11月。
[8] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998.
[8] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，RFC 2267，1998年1月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[10] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[10] Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[11] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[11] Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[12] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[12] Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.J.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[13] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, August 2000.
[13] Dommety，G.“GRE的密钥和序列号扩展”，RFC 28902000年8月。
Editor and Chair Addresses
编辑和主席致辞
Questions about this document may be directed at:
有关本文件的问题，请联系：
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
加布里埃尔E.黑山太阳微系统实验室，欧洲29号，法国墨西哥chemin du Vieux Chene 38240
Phone: +33 476 18 80 45
EMail: gab@sun.com
Phone: +33 476 18 80 45
EMail: gab@sun.com
The working group can be contacted via the current chairs:
可通过现任主席联系工作组：
Basavaraj Patil Nokia Networks 6000 Connection Drive Irving, TX 75039 USA
美国德克萨斯州欧文市Basavaraj Patil诺基亚网络6000连接驱动器75039
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Raj.Patil@nokia.com
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Raj.Patil@nokia.com
Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA
美国伊利诺伊州阿灵顿高地舒尔西路1501号菲尔·罗伯茨摩托罗拉60004
Phone: +1 847-632-3148
EMail: QA3445@email.mot.com
Phone: +1 847-632-3148
EMail: QA3445@email.mot.com
Appendix A: Disparate Address Space Support
附录A：全异地址空间支持
Mobile IP [1] assumes that all the entities involved (mobile node, foreign agent and home agent) have addresses within the same globally routable address space. In many deployment scenarios, when a mobile node leaves its home network it may wander into a region where its home address is not routable or known by the local routing fabric. Similarly, the IP addresses of the foreign agent and the home agent may belong to disparate address spaces, which precludes their exchanging registration protocol messages directly. These issues are possible particularly if the entities involved use addresses from the ranges specified in RFC1918 [12] to support private networks.
移动IP[1]假设所有涉及的实体（移动节点、外部代理和归属代理）在相同的全局可路由地址空间内拥有地址。在许多部署场景中，当移动节点离开其家庭网络时，它可能会漫游到其家庭地址不可路由或本地路由结构不知道的区域。类似地，外部代理和归属代理的IP地址可以属于不同的地址空间，这阻止了它们直接交换注册协议消息。如果涉及的实体使用RFC1918[12]中指定范围内的地址来支持专用网络，则这些问题尤其可能出现。
Accurately speaking, the use of private addresses is not the only cause. It may, in fact, be the most common, but the root of the problem lies in the use of disparate address spaces. For example, corporations often have several properly allocated address ranges. They typically advertise reachability to only a subset of those ranges, leaving the others for use exclusively within the corporate network. Since these ranges are not routable in the general Internet, their use leads to the same problems encountered with "private" addresses, even though they are not taken from the ranges specified in RFC1918.
准确地说，使用私人地址不是唯一的原因。事实上，它可能是最常见的，但问题的根源在于使用不同的地址空间。例如，公司通常有几个正确分配的地址范围。它们通常只对这些范围中的一个子集宣传可达性，而其他范围则只在公司网络中使用。由于这些范围在通用Internet中不可路由，因此使用它们会导致“专用”地址遇到相同的问题，即使它们不是从RFC1918中指定的范围中获取的。
Even if the mobile node, home agent and foreign agent all reside within the same address space, problems may arise if the correspondent node does not. However, this problem is not specific to Mobile IP, and is beyond the scope of this document. The next section limits even further the scope of the issues relevant to this document. A subsequent section explains how reverse tunneling may be used to tackle them.
即使移动节点、归属代理和外部代理都驻留在同一地址空间内，如果对应节点不驻留，也可能出现问题。但是，此问题并非特定于移动IP，并且超出了本文档的范围。下一节将进一步限制与本文件相关的问题的范围。下一节将解释如何使用反向隧道来解决这些问题。
Reverse tunneling (as defined in this document) may be used to cope with disparate address spaces, within the following constraints:
反向隧道（如本文件所定义）可用于在以下限制条件下处理不同的地址空间：
- There are no provisions to solve the case in which the correspondent node and the mobile node are in disparate address spaces. This limits the scope of the problem to only those issues specific to Mobile IP.
- 没有解决对应节点和移动节点位于不同地址空间的情况的规定。这将问题的范围限制为仅针对移动IP的那些问题。
- The foreign agent and the home agent are directly reachable to each other by virtue of residing in the same address space. This limits the scope of the problem to only the simplest of cases. This also implies that the registration
- 由于驻留在相同的地址空间中，外部代理和本地代理彼此可以直接访问。这将问题的范围限制在最简单的情况下。这也意味着注册
protocol itself has a direct path between the foreign agent and the home agent, and, in this respect, is not affected by disparate address spaces. This restriction also applies to mobile nodes operating with a co-located care-of address. In this case, reverse tunneling is a complete and elegant solution.
协议本身在外部代理和归属代理之间有一条直接路径，在这方面，不受不同地址空间的影响。此限制也适用于使用同一位置转交地址操作的移动节点。在这种情况下，反向隧道是一个完整而优雅的解决方案。
- There are no additional protocol elements beyond those defined by Mobile IP [1] and reverse tunneling. In particular, additional extensions to the registration requests or replies, or additional bits in the header--although potentially useful--are outside the scope of this document.
- 除了移动IP[1]和反向隧道定义的协议元素外，没有其他协议元素。特别是，注册请求或回复的附加扩展，或标头中的附加位（尽管可能有用）超出了本文档的范围。
In spite of the limitations, reverse tunneling may be used to solve the most common issues. The range of problems that can be solved are best understood by looking at some simple diagrams:
尽管有这些限制，反向隧道技术可以用来解决最常见的问题。通过查看一些简单的图表，可以更好地理解可以解决的问题范围：
Figure A1: NON-ROUTABLE PACKETS IN DISPARATE ADDRESS SPACES
图A1：不同地址空间中的不可路由数据包
Mc Fa Fb Hb Hc Yc
[MN]-----------------[FA]----------------[HA]---------------[Y]
Addr space A Addr space B Addr space C
Mc Fa Fb Hb Hc Yc
[MN]-----------------[FA]----------------[HA]---------------[Y]
Addr space A Addr space B Addr space C
In this diagram, there are three disparate address spaces: A, B and C. The home agent (HA) has one address each on address spaces B and C, and the foreign agent (FA), on address spaces A and B. The mobile node's (MN) has a permanent address, Mc, within address space C.
在此图中，有三个不同的地址空间：A、B和C。归属代理（HA）在地址空间B和C上各有一个地址，外部代理（FA）在地址空间A和B上。移动节点（MN）在地址空间C内有一个永久地址Mc。
In the most common scenario both A and C are "private" address spaces, and B is the public Internet.
在最常见的场景中，A和C都是“私有”地址空间，B是公共互联网。
Suppose MN sends a packet to correspondent node (Y) in its home network. Presumably, MN has no difficulties delivering this packet to the FA, because it does so using layer 2 mechanisms. Somehow, the FA must realize that this packet must be reverse tunneled, and it must fetch the proper binding to do so. Possible mechanisms are outlined in section A.3.
假设MN向其家庭网络中的对应节点（Y）发送数据包。据推测，MN将此数据包传送到FA没有困难，因为它使用第2层机制来实现。不知何故，FA必须意识到这个数据包必须是反向隧道的，并且它必须获取正确的绑定才能这样做。第A.3节概述了可能的机制。
However, once the packet is in address space B it becomes non-routable. Note that ingress filtering only exacerbates the problem, because it adds a requirement of topological significance to the source IP address in addition to the that of the destination address. As Mobile IP matures, others entities may be defined (for example, AAA servers). Their addition places even more requirements on the address spaces in use.
然而，一旦数据包在地址空间B中，它就变得不可路由。请注意，入口过滤只会加剧问题，因为除了目标地址的要求外，它还增加了源IP地址的拓扑重要性要求。随着移动IP的成熟，可能会定义其他实体（例如，AAA服务器）。它们的添加对正在使用的地址空间提出了更高的要求。
Reverse tunneling adds a topologically significant IP header to the packet (source IP address of Fb, destination of Hb) during its transit within address space B. Assuming IP in IP encapsulation (although others, like GRE are also possible), this is what the packet looks like:
反向隧道在地址空间B内传输期间向数据包（Fb的源IP地址，Hb的目的地）添加具有拓扑意义的IP报头。假设IP封装中存在IP（尽管也可能存在其他封装，如GRE），则数据包的外观如下：
Figure A2: IP IN IP REVERSE TUNNELED PACKET FROM FA TO HA
图A2：从FA到HA的IP-IN-IP反向隧道数据包
+-----------------+
| +-------+|
| Fb->Hb | Mc->Yc||
| +-------+|
+--------+--------+
+-----------------+
| +-------+|
| Fb->Hb | Mc->Yc||
| +-------+|
+--------+--------+
HA receives this packet, recovers the original packet, and since it is cognizant of address space C, delivers it to the appropriate interface.
HA接收该数据包，恢复原始数据包，并且因为它知道地址空间C，所以将其发送到适当的接口。
Of course, for this to happen, the care-of address registered by the MN is not the usual Fa, but Fb. How this happens is outside the scope of this document. Some possible mechanisms are:
当然，对于这种情况，MN注册的转交地址不是通常的Fa，而是Fb。这种情况如何发生超出了本文档的范围。一些可能的机制包括：
- FA recognizes mobile nodes whose addresses fall within the private address ranges specified by RFC1918. In this case, the foreign agent could force the use of Fb as the care-of address, perhaps by rejecting the initial registration request with an appropriate error message and supplemental information.
- FA识别地址在RFC1918指定的专用地址范围内的移动节点。在这种情况下，外国代理可以强制使用Fb作为转交地址，可能是通过拒绝带有适当错误消息和补充信息的初始注册请求。
- FA could be configured to always advertise Fb as long as H->Fb and Fb->H are guaranteed to be valid forward and reverse tunnels, respectively, for all values of H. Here, H is the address of any home agent whose mobile nodes may register via FA.
- 只要H->Fb和Fb->H分别保证对H的所有值都是有效的正向和反向隧道，则可以将FA配置为始终播发Fb。这里，H是其移动节点可以通过FA注册的任何归属代理的地址。
- FA could indicate that it supports disparate address spaces via a currently undefined 'P' bit in its advertisements, and an indication of the relevant address space for any or all of its care-of addressed by including an NAI [11] or a realm indicator (perhaps a variant of the NAI). Alternatively, mobile nodes so configured could solicit the NAI or realm indicator information in response to advertisements with the 'P' bit set.
- FA可通过其广告中当前未定义的“P”位表示其支持不同的地址空间，并通过包括NAI[11]或领域指示符（可能是NAI的变体）来表示其任何或所有照管的相关地址空间。或者，这样配置的移动节点可以请求NAI或领域指示符信息，以响应设置了“P”位的广告。
Additionally, the mobile node needs to supply the appropriate address for its home agent: Hb instead of the usual Hc. How this happens is outside the scope of this document. Some possible mechanisms are:
此外，移动节点需要为其归属代理提供适当的地址：Hb而不是通常的Hc。这种情况如何发生超出了本文档的范围。一些可能的机制包括：
- This determination could be triggered in response to using the foreign agent's Fb as the care-of address.
- 该决定可在使用外国代理的Fb作为转交地址时触发。
- The mobile node could always use Hb as its home agent address, specially (1) if Hb is routable within address space C, or (2) if MN is certain never to be at home (in some configurations, the mobile nodes are always roaming).
- 移动节点可以始终使用Hb作为其归属代理地址，特别是（1）如果Hb可在地址空间C内路由，或者（2）如果MN确定永远不在家（在某些配置中，移动节点总是漫游）。
- The mobile node could be configured with different home agent addresses and their corresponding address space (perhaps indicated via an NAI [11] or a variant of it).
- 移动节点可以配置不同的归属代理地址及其对应的地址空间（可能通过NAI[11]或其变体指示）。
Another major issue introduced by private addresses is that of two or more mobile nodes with the same numeric IP address:
私有地址带来的另一个主要问题是具有相同数字IP地址的两个或多个移动节点的问题：
Figure A3: MOBILE NODES WITH CONFLICTING ADDRESSES
图A3：地址冲突的移动节点
Mc=M H1b H1c
[MN1]-------+ +----[HA1]----+---------
| | | Address
| | | space C
Address | | Address +----------
Space Fa-[FA]-Fb Space
A | | B +---------
| | | Address
| | | space D
[MN2]-------+ +----[HA2]----+---------
Md=M H2b H2d
Mc=M H1b H1c
[MN1]-------+ +----[HA1]----+---------
| | | Address
| | | space C
Address | | Address +----------
Space Fa-[FA]-Fb Space
A | | B +---------
| | | Address
| | | space D
[MN2]-------+ +----[HA2]----+---------
Md=M H2b H2d
Suppose there are two address spaces A and B, and a foreign agent (FA) with interfaces on both. There are two home agents (HA1 and HA2) in address space B, with addresses H1b and H2b, respectively. Each of the home agents has an interface in a private address space in addition to address space B: HA1 has H1c on C, and HA2 has H2d on D. MN1 and MN2 are two mobile nodes with home addresses Mc and Md, corresponding to address space C and D, respectively.
假设有两个地址空间A和B，以及两个地址空间上都有接口的外部代理（FA）。在地址空间B中有两个归属代理（HA1和HA2），分别具有地址H1b和H2b。除了地址空间B之外，每个归属代理在私有地址空间中都有一个接口：HA1在C上有H1c，HA2在D上有H2d。MN1和MN2是两个具有归属地址Mc和Md的移动节点，分别对应于地址空间C和D。
If Mc and Md are private addresses as defined in RFC1918, they may be numerically equivalent (both equal to M). Because of this, the foreign agent can no longer rely on only the mobile node's home address to disambiguate amongst its different bindings.
如果Mc和Md是RFC1918中定义的专用地址，则它们在数字上可能相等（两者都等于M）。因此，外部代理不能再仅依赖移动节点的主地址来消除其不同绑定之间的歧义。
In figure A1, suppose the correspondent node Y sends a packet to the mobile node at address Mc. The packet is intercepted by the home agent at Hc and tunneled towards the mobile node via address Fb.
在图A1中，假设对应节点Y在地址Mc处向移动节点发送数据包。该数据包被Hc处的归属代理截获，并通过地址Fb通过隧道传输到移动节点。
Once the packet reaches FA (via address Fb), the foreign agent must identify which of its registered mobile nodes is the ultimate destination for the internal packet. In order to do so, it needs to identify the proper binding via a tuple guaranteed to be unique among all of its mobile nodes.
一旦数据包到达FA（通过地址Fb），外部代理必须识别其注册的移动节点中的哪一个是内部数据包的最终目的地。为了做到这一点，它需要通过保证在所有移动节点中唯一的元组来识别正确的绑定。
The unique tuple sufficient for demultiplexing IP in IP packets [IPIP] (protocol 4) is:
足以在IP数据包[IPIP]（协议4）中解复用IP的唯一元组为：
- destination IP address of the encapsulated (internal) header
- 封装（内部）报头的目标IP地址
This is mobile node MN's home address (Mc in the above example). At first glance, it seems like this is unique among all mobile nodes, but as mentioned above, with private addresses another mobile may have an address Md numerically equivalent to Mc.
这是移动节点MN的家庭地址（上例中为Mc）。乍一看，这似乎在所有移动节点中都是唯一的，但如上所述，对于私有地址，另一个移动节点可能有一个地址Md在数字上等同于Mc。
- source IP address of the external header
- 外部标头的源IP地址
This, the remote end of the tunnel, is Hb in the above example.
在上述示例中，隧道的远端为Hb。
- destination IP address of the external header
- 外部标头的目标IP地址
This, the local end of the tunnel, is Fb in the above example.
在上述示例中，隧道的局部端为Fb。
The three values above are learned from a successful registration and are the mobile node's home address, the home agent's address and the care-of address. Thus, it is possible to identify the right binding. Once FA identifies the ultimate destination of the packet, Mc, it delivers the internal packet using link layer mechanisms.
上述三个值是从成功注册中学习的，分别是移动节点的家庭地址、家庭代理地址和转交地址。因此，可以识别正确的绑定。一旦FA确定了数据包的最终目的地Mc，它就使用链路层机制来交付内部数据包。
GRE packets [10] (protocol 47) are only handled if their Protocol Type field has a value of 0x800 (other values are outside the scope of this document), and are demultiplexed based on the same tuple as IP in IP packets. In GRE terminology, the tuple is:
GRE数据包[10]（协议47）仅在其协议类型字段的值为0x800（其他值不在本文档的范围内）时才进行处理，并基于与IP数据包中的IP相同的元组进行解复用。在GRE术语中，元组是：
- destination IP address of the payload (internal) packet
- 有效负载（内部）数据包的目标IP地址
- source IP address of the delivery (external) packet
- 传递（外部）数据包的源IP地址
- destination IP address of the delivery (external) packet
- 传递（外部）数据包的目标IP地址
Notice that the Routing, Sequence Number, Strict Source Route and Key fields have been deprecated from GRE [10]. However, a separate document specifies their use [13].
请注意，路由、序列号、严格源路由和键字段已从GRE中弃用[10]。但是，另一份文件规定了它们的用途[13]。
The above tuples work for IP-in-IP or GRE encapsulation, and assume that the inner packet is in the clear. Encapsulations which encrypt the inner packet header are outside the scope of this document.
上述元组适用于IP或GRE封装中的IP，并假设内部数据包是透明的。加密内部数据包头的封装不在本文档的范围内。
In figure A3, suppose mobile node M1 sends a packet to a correspondent node in its home address space, C, and mobile node M2 sends a packet to a correspondent node in its home address space, D.
在图A3中，假设移动节点M1向其家庭地址空间C中的对应节点发送数据包，移动节点M2向其家庭地址空间D中的对应节点发送数据包。
At FA, the source addresses for both packets will be seen as M, thus this is not sufficient information. The unique tuple required to identify the proper binding is:
在FA，两个数据包的源地址都将被视为M，因此这不是足够的信息。标识正确绑定所需的唯一元组是：
- link-layer information related to the MN
- 与MN相关的链路层信息
This may be in the form of a MAC address, a PPP session (or incoming interface) or channel coding for a digital cellular service. Device ID's can also be used in this context.
这可以是用于数字蜂窝服务的MAC地址、PPP会话（或传入接口）或信道编码的形式。设备ID也可在此上下文中使用。
- source IP address of the IP header.
- IP头的源IP地址。
As was pointed out, this by itself is not guaranteed to be unique.
正如所指出的那样，这本身并不能保证是独一无二的。
This information must be established and recorded at registration time. The above items are sufficient for the foreign agent to select the proper binding to use. This, in turn, produces the address of the home agent, and the reverse tunneling options negotiated during the registration process. The foreign agent can now proceed with reverse tunneling.
必须在注册时建立并记录此信息。以上各项足以让外国代理选择合适的绑定使用。这反过来会产生归属代理的地址，以及在注册过程中协商的反向隧道选项。外国代理现在可以进行反向隧道。
The Limited Private Address Scenario (LPAS) has received much attention from the cellular wireless industry, so it is useful to define it and to clarify what its requirements are.
有限专用地址场景（LPAS）受到了蜂窝无线行业的广泛关注，因此对其进行定义并阐明其需求是非常有用的。
LPAS is a subset of the disparate address space scenario discussed in this appendix. This section explains how LPAS could be deployed given the current state of the Mobile IP specifications.
LPA是本附录中讨论的完全不同的地址空间场景的子集。本节解释了在移动IP规范的当前状态下如何部署LPA。
Figure A4: EXAMPLE PRIVATE ADDRESS SCENARIO
图A4：示例专用地址场景
10.10.1.2
+----+ IF1=COA1+-------+ HAA2 +-----+
| MN1|------------------------| FA |---------| HA2 |
+----+ +------------| | +-----+
| IF2=COA2+-------+
+---+ |
| |
+-----+ |
| MN2 | |
+-----+ |
10.10.1.2 |
| HAA1
+------+
| HA1 |
+------+
10.10.1.2
+----+ IF1=COA1+-------+ HAA2 +-----+
| MN1|------------------------| FA |---------| HA2 |
+----+ +------------| | +-----+
| IF2=COA2+-------+
+---+ |
| |
+-----+ |
| MN2 | |
+-----+ |
10.10.1.2 |
| HAA1
+------+
| HA1 |
+------+
The above figure presents a very simple scenario in which private addresses are used. Here, "private addresses" are strictly those defined in RFC 1918 [12]. In this deployment scenario, the only entities that have private addresses are the mobile nodes. Foreign agent and home agent addresses are publicly routable on the general Internet. More specifically, the care-of addresses advertised by the foreign agents (COA1 and COA2 in Figure A4) and the home agent addresses used by mobile nodes in registration requests (HAA1 and HAA2 in Figure A4) are publicly routable on the general Internet. As a consequence, any Mobile IP tunnels can be established between any home agent home address and any foreign agent care-of address.
上图显示了一个使用私有地址的非常简单的场景。此处，“专用地址”严格按照RFC 1918[12]中的定义。在此部署场景中，只有移动节点具有专用地址。外国代理和本国代理地址可在通用Internet上公开路由。更具体地说，由外部代理（图A4中的COA1和COA2）公布的转交地址以及由移动节点在注册请求中使用的归属代理地址（图A4中的HAA1和HAA2）可在通用互联网上公开路由。因此，可以在任何归属代理归属地址和任何外国代理托管地址之间建立任何移动IP隧道。
Also, note that two different mobile nodes (MN1 and MN2) with the same private address (10.10.1.2) are visiting the same foreign agent FA. This is supported as long as MN1 and MN2 are serviced by different home agents. Hence, from any given home agent's perspective, each mobile node has a unique IP address, even if it happens to be a private address as per RFC 1918.
另外，请注意，具有相同专用地址（10.10.1.2）的两个不同移动节点（MN1和MN2）正在访问相同的外部代理FA。只要MN1和MN2由不同的家庭代理提供服务，就支持此功能。因此，从任何给定的归属代理的角度来看，每个移动节点都有一个唯一的IP地址，即使根据RFC1918它恰好是一个私有地址。
Operation in the presence of route optimization [4] is outside the scope of this document.
存在路线优化[4]时的操作不在本文件范围内。
Requirements for the above private address scenario:
上述专用地址方案的要求：
Mobile node requirements:
移动节点要求：
Mobile nodes intending to use private addresses with Mobile IP MUST set the 'T' bit and employ reverse tunneling. Mobile node's private addresses within a given address space MUST be unique. Thus two mobile nodes belonging to a single home agent
打算使用移动IP专用地址的移动节点必须设置“T”位并采用反向隧道。给定地址空间内移动节点的专用地址必须是唯一的。因此，两个移动节点属于一个归属代理
cannot have the same private addresses. Thus, when receiving or sending tunneled traffic for a mobile node, the tunnel endpoints are used to disambiguate amongst conflicting mobile node addresses.
不能有相同的专用地址。因此，当接收或发送移动节点的隧道流量时，隧道端点用于在冲突的移动节点地址之间消除歧义。
If the mobile node happens to register with multiple home agents simultaneously through the same foreign agent, there must be some link-layer information that is distinct for each mobile node. If no such distinct link-layer information is available, the mobile nodes MUST use unique address.
如果移动节点碰巧通过同一个外部代理同时向多个归属代理注册，则对于每个移动节点必须有一些不同的链路层信息。如果没有此类不同的链路层信息可用，则移动节点必须使用唯一地址。
Foreign agent requirements:
外国代理要求：
All advertising interfaces of the foreign agent MUST have publicly routable care-of address. Thus, a mobile node with a private address visits the foreign agent only in its publicly routable network.
外国代理的所有广告界面必须具有可公开路由的转交地址。因此，具有专用地址的移动节点仅在其可公开路由的网络中访问外部代理。
Foreign agents MUST support reverse tunneling in order to support private addressed mobile nodes. If a foreign agent receives a registration request from a mobile node with a private address, and the mobile node has not set the 'T' bit, the foreign agent SHOULD reject it.
外部代理必须支持反向隧道，以支持专用寻址移动节点。如果外部代理接收到来自具有专用地址的移动节点的注册请求，并且移动节点未设置“T”位，则外部代理应拒绝该请求。
When delivering packets to or receiving packets from mobile nodes, foreign agents MUST disambiguate among mobile node with conflicting private addresses by using link-layer information as mentioned previously (Appendix section A.2 and A.3). A foreign agent in absence of route optimization, should make sure that two mobile nodes visiting the same foreign agent corresponds with each other through their respective home agents.
当向移动节点发送数据包或从移动节点接收数据包时，外部代理必须使用前面提到的链路层信息（附录A.2和A.3节）在具有冲突专用地址的移动节点之间消除歧义。在没有路由优化的情况下，外部代理应确保访问同一外部代理的两个移动节点通过各自的归属代理相互通信。
If a foreign agent supports reverse tunneling, then it MUST support the simple scenario of private address support described in this section.
如果外部代理支持反向隧道，那么它必须支持本节中描述的私有地址支持的简单场景。
Home agent requirements:
国内代理要求：
Any home agent address used by mobile nodes in registration request MUST be a publicly routable address. Home agents will not support overlapping private home addresses, thus each private home address of a mobile node registered with a home agent is unique. When the 'T' bit is set in the registration request from the mobile node, the home agent MUST recognize and accept registration request from mobile nodes with private
移动节点在注册请求中使用的任何归属代理地址必须是可公开路由的地址。归属代理不支持重叠的私有归属地址，因此向归属代理注册的移动节点的每个私有归属地址都是唯一的。当在来自移动节点的注册请求中设置了“T”位时，归属代理必须识别并接受来自具有私钥的移动节点的注册请求
addresses. Also, the home agent SHOULD be able to assign private addresses out of its address pool to mobile nodes for use as home addresses. This does not contravene home agent processing in section 3.8 of [1].
地址。此外，归属代理应该能够将其地址池中的私有地址分配给移动节点以用作归属地址。这不违反[1]第3.8节中的home agent处理。
Appendix B: Changes from RFC2344
附录B：RFC2344的变更
This section lists the changes with respect to the previous version of this document (RFC2344).
本节列出了与本文件先前版本（RFC2344）相关的变更。
- Added Appendix A on support for Disparate Addresses spaces and private addresses.
- 增加了附录A关于对不同地址空间和专用地址的支持。
- Added the corresponding section (6.3) under 'Security Considerations'.
- 在“安全注意事项”下添加了相应的章节（6.3）。
- Made Encapsulating Delivery Support optional by demoting from a MUST to a should. This also required defining a new error code 79 (assigned by IANA).
- 通过从“必须”降级为“应该”，使封装传递支持成为可选。这还需要定义一个新的错误代码79（由IANA分配）。
- Mentioned the possibility of an admissible authentication extension which may be different from the Mobile-Home authentication extension.
- 提到了允许的认证扩展的可能性，该扩展可能不同于移动家庭认证扩展。
- An IANA considerations section was added.
- 增加了IANA注意事项部分。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。