Network Working Group H. Levkowetz
Request for Comments: 3519 ipUnplugged
Category: Standards Track S. Vaarala
Netseal
April 2003
Network Working Group H. Levkowetz
Request for Comments: 3519 ipUnplugged
Category: Standards Track S. Vaarala
Netseal
April 2003
Mobile IP Traversal of Network Address Translation (NAT) Devices
网络地址转换（NAT）设备的移动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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic.
移动IP的数据报隧道与网络地址转换（NAT）不兼容。本文档介绍了移动IP协议的扩展和隧道方法，该方法允许使用移动IP的移动节点在专用地址网络中运行，专用地址网络通过NAT设备与公共互联网分离。NAT遍历基于使用移动IP Home Agent UDP端口封装数据流量。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem description . . . . . . . . . . . . . . . . . . 3
1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . 4
2. NAT Traversal Overview. . . . . . . . . . . . . . . . . . . . 5
2.1 Basic Message Sequence. . . . . . . . . . . . . . . . . 5
3. New Message Formats . . . . . . . . . . . . . . . . . . . . . 6
3.1 UDP Tunnel Request Extension. . . . . . . . . . . . . . 6
3.1.1 F (Force) Flag. . . . . . . . . . . . . . . . . . 7
3.1.2 R (Registration through FA Required) flag . . . . 8
3.1.3 Reserved Fields . . . . . . . . . . . . . . . . . 8
3.1.4 Encapsulation . . . . . . . . . . . . . . . . . . 8
3.1.5 Mobile IP Registration Bits . . . . . . . . . . . 9
3.2 UDP Tunnel Reply Extension. . . . . . . . . . . . . . . 9
3.2.1 Reply Code. . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem description . . . . . . . . . . . . . . . . . . 3
1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . 4
2. NAT Traversal Overview. . . . . . . . . . . . . . . . . . . . 5
2.1 Basic Message Sequence. . . . . . . . . . . . . . . . . 5
3. New Message Formats . . . . . . . . . . . . . . . . . . . . . 6
3.1 UDP Tunnel Request Extension. . . . . . . . . . . . . . 6
3.1.1 F (Force) Flag. . . . . . . . . . . . . . . . . . 7
3.1.2 R (Registration through FA Required) flag . . . . 8
3.1.3 Reserved Fields . . . . . . . . . . . . . . . . . 8
3.1.4 Encapsulation . . . . . . . . . . . . . . . . . . 8
3.1.5 Mobile IP Registration Bits . . . . . . . . . . . 9
3.2 UDP Tunnel Reply Extension. . . . . . . . . . . . . . . 9
3.2.1 Reply Code. . . . . . . . . . . . . . . . . . . . 10
3.3 MIP Tunnel Data Message . . . . . . . . . . . . . . . . 10
3.4 UDP Tunnelling Flag in Agent Advertisements . . . . . . 11
3.5 New Registration Reply Codes. . . . . . . . . . . . . . 12
4. Protocol Behaviour. . . . . . . . . . . . . . . . . . . . . . 12
4.1 Relation to standard MIP tunnelling . . . . . . . . . . 12
4.2 Encapsulating IP Headers in UDP . . . . . . . . . . . . 13
4.3 Decapsulation . . . . . . . . . . . . . . . . . . . . . 15
4.4 Mobile Node Considerations. . . . . . . . . . . . . . . 15
4.5 Foreign Agent Considerations. . . . . . . . . . . . . . 16
4.6 Home Agent Considerations . . . . . . . . . . . . . . . 18
4.6.1 Error Handling. . . . . . . . . . . . . . . . . . 19
4.7 MIP signalling versus tunnelling. . . . . . . . . . . . 20
4.8 Packet fragmentation. . . . . . . . . . . . . . . . . . 21
4.9 Tunnel Keepalive. . . . . . . . . . . . . . . . . . . . 21
4.10 Detecting and compensating for loss of NAT mapping. . . 22
4.11 Co-located registration through FA. . . . . . . . . . . 24
5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
5.1 Movement Detection and Private Address Aliasing . . . . 24
5.2 Mobility Binding Lifetime . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6.1 Traffic Redirection Vulnerabilities . . . . . . . . . . 27
6.1.1 Manipulation of the Registration
Request Message . . . . . . . . . . . . . . . . . 27
6.1.2 Sending a Bogus Keepalive Message . . . . . . . . 27
6.2 Use of IPsec. . . . . . . . . . . . . . . . . . . . . . 28
6.3 Firewall Considerations . . . . . . . . . . . . . . . . 28
7. UNSAF Considerations. . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Intellectual Property Rights. . . . . . . . . . . . . . . . . 30
10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 31
11. Normative References. . . . . . . . . . . . . . . . . . . . . 31
12. Informative References. . . . . . . . . . . . . . . . . . . . 32
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 33
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 34
3.3 MIP Tunnel Data Message . . . . . . . . . . . . . . . . 10
3.4 UDP Tunnelling Flag in Agent Advertisements . . . . . . 11
3.5 New Registration Reply Codes. . . . . . . . . . . . . . 12
4. Protocol Behaviour. . . . . . . . . . . . . . . . . . . . . . 12
4.1 Relation to standard MIP tunnelling . . . . . . . . . . 12
4.2 Encapsulating IP Headers in UDP . . . . . . . . . . . . 13
4.3 Decapsulation . . . . . . . . . . . . . . . . . . . . . 15
4.4 Mobile Node Considerations. . . . . . . . . . . . . . . 15
4.5 Foreign Agent Considerations. . . . . . . . . . . . . . 16
4.6 Home Agent Considerations . . . . . . . . . . . . . . . 18
4.6.1 Error Handling. . . . . . . . . . . . . . . . . . 19
4.7 MIP signalling versus tunnelling. . . . . . . . . . . . 20
4.8 Packet fragmentation. . . . . . . . . . . . . . . . . . 21
4.9 Tunnel Keepalive. . . . . . . . . . . . . . . . . . . . 21
4.10 Detecting and compensating for loss of NAT mapping. . . 22
4.11 Co-located registration through FA. . . . . . . . . . . 24
5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
5.1 Movement Detection and Private Address Aliasing . . . . 24
5.2 Mobility Binding Lifetime . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6.1 Traffic Redirection Vulnerabilities . . . . . . . . . . 27
6.1.1 Manipulation of the Registration
Request Message . . . . . . . . . . . . . . . . . 27
6.1.2 Sending a Bogus Keepalive Message . . . . . . . . 27
6.2 Use of IPsec. . . . . . . . . . . . . . . . . . . . . . 28
6.3 Firewall Considerations . . . . . . . . . . . . . . . . 28
7. UNSAF Considerations. . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Intellectual Property Rights. . . . . . . . . . . . . . . . . 30
10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 31
11. Normative References. . . . . . . . . . . . . . . . . . . . . 31
12. Informative References. . . . . . . . . . . . . . . . . . . . 32
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 33
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 34
The Mobile IP related terminology described in RFC 3344 [10] is used in this document. In addition, the following terms are used:
本文件使用RFC 3344[10]中描述的移动IP相关术语。此外，还使用了以下术语：
Forward Tunnel A tunnel that forwards 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.
反向隧道从移动节点的转交地址开始并在归属代理处终止的隧道。
NAT Network Address Translation. "Traditional NAT would allow hosts within a private network to transparently access hosts in the external network, in most cases. In a traditional NAT, sessions are uni-directional, outbound from the private network." -- RFC 2663 [11]. Basic NAT and NAPT are two varieties of NAT.
NAT网络地址转换。“在大多数情况下，传统NAT允许专用网络内的主机透明地访问外部网络中的主机。在传统NAT中，会话是单向的，从专用网络出站。”——RFC 2663[11]。基本NAT和NAPT是NAT的两个变种。
Basic NAT "With Basic NAT, a block of external addresses are set aside for translating addresses of hosts in a private domain as they originate sessions to the external domain. For packets outbound from the private network, the source IP address and related fields such as IP, TCP, UDP and ICMP header checksums are translated. For inbound packets, the destination IP address and the checksums as listed above are translated." -- RFC 2663 [11].
基本NAT“使用基本NAT时，会留出一个外部地址块，用于将私有域中的主机的地址转换为外部域中的会话。对于从专用网络出站的数据包，将转换源IP地址和相关字段，如IP、TCP、UDP和ICMP报头校验和。对于入站数据包，将转换上面列出的目标IP地址和校验和。“--RFC 2663[11]。
NAPT Network Address Port Translation. "NAPT extends the notion of translation one step further by also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). This allows the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address. NAPT allows a set of hosts to share a single external address. Note that NAPT can be combined with Basic NAT so that a pool of external addresses are used in conjunction with port translation." -- RFC 2663 [11].
NAPT网络地址端口转换。“NAPT通过转换传输标识符（例如TCP和UDP端口号、ICMP查询标识符）进一步扩展了转换的概念。这允许将多个专用主机的传输标识符多路复用到单个外部地址的传输标识符中。NAPT允许一组主机共享单个外部地址。请注意，NAPT可以与基本NAT结合使用，以便将外部地址池与端口转换结合使用。”——RFC 2663[11]。
In this document, the more general term NAT is used to cover both NATs and NAPTs. In most deployment cases today, we believe that the NATs used are of the NAPT variety.
在本文档中，更一般的术语NAT用于涵盖NAT和NAPT。在今天的大多数部署案例中，我们相信所使用的NAT属于NAPT类型。
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 BCP 14, RFC 2119 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[6]中的描述进行解释。
A basic assumption that Mobile IP [10] makes is that mobile nodes and foreign agents are uniquely identifiable by a globally routable IP address. This assumption breaks down when a mobile node attempts to communicate from behind a NAT.
移动IP[10]的一个基本假设是，移动节点和外部代理可通过全局可路由IP地址唯一识别。当移动节点试图从NAT后面进行通信时，这种假设就失效了。
Mobile IP relies on sending traffic from the home network to the mobile node or foreign agent through IP-in-IP tunnelling. IP nodes which communicate from behind a NAT are reachable only through the NAT's public address(es). IP-in-IP tunnelling does not generally contain enough information to permit unique translation from the common public address(es) to the particular care-of address of a mobile node or foreign agent which resides behind the NAT; in particular there are no TCP/UDP port numbers available for a NAT to work with. For this reason, IP-in-IP tunnels cannot in general pass through a NAT, and Mobile IP will not work across a NAT.
移动IP依赖于通过IP隧道将流量从家庭网络发送到移动节点或外部代理。从NAT后面进行通信的IP节点只能通过NAT的公共地址进行访问。IP隧道中的IP通常不包含足够的信息，以允许从公共公共地址到位于NAT后面的移动节点或外部代理的特定转交地址的唯一转换；尤其是，NAT无法使用TCP/UDP端口号。因此，IP隧道中的IP通常不能通过NAT，移动IP也不能跨NAT工作。
Mobile IP's Registration Request and Reply will on the other hand be able to pass through NATs and NAPTs on the mobile node or foreign agent side, as they are UDP datagrams originated from the inside of the NAT or NAPT. When passing out, they make the NAT set up an address/port mapping through which the Registration Reply will be able to pass in to the correct recipient. The current Mobile IP protocol does however not permit a registration where the mobile node's IP source address is not either the CoA, the Home Address, or 0.0.0.0.
另一方面，移动IP的注册请求和回复将能够通过移动节点或外部代理端的NAT和NAPT，因为它们是源自NAT或NAPT内部的UDP数据报。当发送时，他们让NAT设置一个地址/端口映射，通过该映射，注册回复将能够传递到正确的收件人。然而，当前移动IP协议不允许在移动节点的IP源地址不是CoA、归属地址或0.0.0.0的情况下进行注册。
What is needed is an alternative data tunnelling mechanism for Mobile IP which will provide the means needed for NAT devices to do unique mappings so that address translation will work, and a registration mechanism which will permit such an alternative tunnelling mechanism to be set up when appropriate.
需要的是移动IP的替代数据隧道机制，该机制将为NAT设备提供进行唯一映射所需的手段，以便地址转换能够工作，以及注册机制，该机制将允许在适当时设置此类替代隧道机制。
This mechanism will address 3 different scenarios:
该机制将处理3种不同的场景：
- A mobile node with co-located address behind a NAT; no FA
- 在NAT后面具有共同定位地址的移动节点；无FA
- A mobile node registered with an FA where both the mobile node and the FA are behind the same NAT
- 向FA注册的移动节点，其中移动节点和FA都位于同一NAT后面
- A mobile node with co-located address using an FA which demands that registrations pass through the FA (sets the "R" bit) where both the mobile node and the FA are behind the same NAT
- 一种移动节点，其地址位于同一位置，使用FA，要求注册通过FA（设置“R”位），其中移动节点和FA都位于同一NAT后面
The primary assumption in this document is that the network allows communication between an UDP port chosen by the mobile node and the home agent UDP port 434. If this assumption does not hold, neither Mobile IP registration nor data tunnelling will work.
本文中的主要假设是，网络允许移动节点选择的UDP端口与归属代理UDP端口434之间的通信。如果这个假设不成立，那么移动IP注册和数据隧道都不起作用。
This document does NOT assume that mobility is constrained to a common IP address space. On the contrary, the routing fabric between the mobile node and the home agent may be partitioned into a
本文档不假设移动受限于公共IP地址空间。相反，移动节点和归属代理之间的路由结构可以被划分成多个区域
"private" and a "public" network, and the assumption is that some mechanism is needed in addition to vanilla Mobile IP according to RFC 3344 [10] in order to achieve mobility within disparate IP address spaces.
“私有”和“公共”网络，并且假设除了根据RFC 3344[10]的普通移动IP之外，还需要一些机制，以便在不同的IP地址空间内实现移动性。
For a more extensive discussion of the problems with disparate address spaces, and how they may be solved, see RFC 3024 [9].
有关不同地址空间问题的更广泛讨论，以及如何解决这些问题，请参见RFC 3024[9]。
The reverse tunnels considered here are symmetric, that is, they use the same configuration (encapsulation method, IP address endpoints) as the forward tunnel.
这里考虑的反向隧道是对称的，也就是说，它们使用与正向隧道相同的配置（封装方法、IP地址端点）。
This section gives a brief overview of the MIP UDP tunnelling mechanism which may be used to achieve NAT traversal for Mobile IP.
本节简要概述了可用于实现移动IP NAT穿越的MIP UDP隧道机制。
In MIP UDP tunnelling, the mobile node may use an extension (described below) in its Registration Request to indicate that it is able to use Mobile IP UDP tunnelling instead of standard Mobile IP tunnelling if the home agent sees that the Registration Request seems to have passed through a NAT. The home agent may then send a registration reply with an extension indicating acceptance (or denial). After assent from the home agent, MIP UDP tunnelling will be available for use for both forward and reverse tunnelling. UDP tunnelled packets sent by the mobile node use the same ports as the registration request message. In particular, the source port may vary between new registrations, but remains the same for all tunnelled data and re-registrations. The destination port is always 434. UDP tunnelled packets sent by the home agent uses the same ports, but in reverse.
在MIP UDP隧道中，如果归属代理看到注册请求似乎已经通过NAT，则移动节点可以在其注册请求中使用扩展（如下所述）来指示其能够使用移动IP UDP隧道而不是标准移动IP隧道。然后，归属代理可以发送带有表示接受（或拒绝）的扩展的注册回复。在获得归属代理的同意后，MIP UDP隧道将可用于正向和反向隧道。移动节点发送的UDP隧道数据包使用与注册请求消息相同的端口。特别是，源端口在新注册之间可能有所不同，但对于所有隧道数据和重新注册，源端口保持不变。目标端口始终为434。归属代理发送的UDP隧道数据包使用相同的端口，但使用相反的端口。
The message sequence diagram below exemplifies setting up and using a Mobile IP UDP tunnel as described in this document. The tunnel is set up by the use of specific extensions in the initial Mobile IP Registration Request and Reply exchange. Thereafter, any traffic from the home agent to the mobile node is sent through the UDP tunnel. The mobile node may at its discretion use the UDP tunnel for reverse tunnelling or not, although in most cases where MIP UDP tunnelling is needed, reverse tunnelling will also be needed.
下面的消息序列图举例说明了如何按照本文档所述设置和使用移动IP UDP隧道。隧道是通过在初始移动IP注册请求和应答交换中使用特定扩展来建立的。此后，从归属代理到移动节点的任何流量都通过UDP隧道发送。移动节点可自行决定是否将UDP隧道用于反向隧道，尽管在大多数需要MIP UDP隧道的情况下，也将需要反向隧道。
mobile node NAT home agent
| | |
| | |
| Registration | |
| Request with | |
|-----------------///--------------->>|
|UDP Tunnel Request| |
| | +
| | || IP Source and
| | || CCoA address
| | || discrepancy
| | || seen
| | Registration +
| | Reply with |
|<<---------------///-----------------|
| | UDP Tunnel Reply.|
| | |
| UDP tunnelled pkg| |
|=================///===============>>|
| | UDP tunnelled pkg|
|<<===============///=================|
| | ||absence of
| | ||traffic for
| | ||UDP keepalive
| UDP keepalive | ||period
|-----------------///--------------->>+
. . +
. . .
. . .
mobile node NAT home agent
| | |
| | |
| Registration | |
| Request with | |
|-----------------///--------------->>|
|UDP Tunnel Request| |
| | +
| | || IP Source and
| | || CCoA address
| | || discrepancy
| | || seen
| | Registration +
| | Reply with |
|<<---------------///-----------------|
| | UDP Tunnel Reply.|
| | |
| UDP tunnelled pkg| |
|=================///===============>>|
| | UDP tunnelled pkg|
|<<===============///=================|
| | ||absence of
| | ||traffic for
| | ||UDP keepalive
| UDP keepalive | ||period
|-----------------///--------------->>+
. . +
. . .
. . .
This extension is a skippable extension. It signifies that the sender is capable of handling MIP UDP tunnelling, and optionally that a particular encapsulation format is requested in the MIP UDP tunnel. The format of this extension is as shown below. It adheres to the short extension format described in [10].
此扩展是可跳过的扩展。它表示发送方能够处理MIP UDP隧道，并且可以选择在MIP UDP隧道中请求特定的封装格式。此扩展的格式如下所示。它遵循[10]中描述的简短扩展格式。
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 | Sub-Type | Reserved 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|R| Reserved 2| Encapsulation | Reserved 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Sub-Type | Reserved 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|R| Reserved 2| Encapsulation | Reserved 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 144
144型
Length 6. Length in bytes of this extension, not including the Type and Length bytes.
长度6。此扩展的长度（字节），不包括类型和长度字节。
Sub-Type 0
子类型0
Reserved 1 Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception.
保留1保留供将来使用。发送时必须设置为0，接收时必须忽略。
F F (Force) flag. Indicates that the mobile node wants to force MIP UDP tunnelling to be established.
F（部队）旗。指示移动节点希望强制建立MIP UDP隧道。
R R (Registration through FA Required) flag. Indicates that the R bit was set in the FA's Agent Advertisement. Registration is being made using a co-located care-of address, but through the FA.
R（需要通过FA注册）标志。表示在FA的代理播发中设置了R位。登记使用同一地点的托管地址，但通过FA进行。
Reserved 2 Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception.
保留2保留供将来使用。发送时必须设置为0，接收时必须忽略。
Encapsulation Indicates the type of tunnelled data, using the same numbering as the IP Header Protocol Field.
封装表示隧道数据的类型，使用与IP头协议字段相同的编号。
Reserved 3 Reserved for future use. MUST be set to 0 on sending, MUST be verified as 0 on receipt; otherwise the extension must be handled as not understood and silently skipped.
保留3保留供将来使用。发送时必须设置为0，接收时必须验证为0；否则，必须将扩展处理为未理解，并以静默方式跳过。
Indicates that the mobile node wants to use traversal regardless of the outcome of NAT detection performed by the home agent. This is useful if the route between the mobile node and the home agent works for Mobile IP signalling packets, but not for generic data packets (e.g., because of firewall filtering rules). If the home agent supports this protocol, it SHOULD either accept the traversal and reply with a UDP Tunnel Reply Extension or reject the Registration Request. In case of the registration failing, the Home Agent SHOULD send a Registration Reply with Code field set to 129 ("administratively prohibited").
指示移动节点希望使用遍历，而不管归属代理执行的NAT检测结果如何。如果移动节点和归属代理之间的路由适用于移动IP信令分组，但不适用于一般数据分组（例如，由于防火墙过滤规则），则这是有用的。如果归属代理支持此协议，它应该接受遍历并使用UDP隧道应答扩展进行应答，或者拒绝注册请求。如果注册失败，归属代理应发送注册回复，代码字段设置为129（“行政禁止”）。
If the HA does not understand the UDP Tunnel Request Extension, it will silently discard it, and if everything else is fine, it will reply with a registration reply with reply code 0 (registration accepted), but without any UDP Tunnel Reply Extension. In this case, the mobile node MUST NOT use MIP UDP tunnelling.
如果HA不理解UDP隧道请求扩展，它将自动放弃它，如果其他一切正常，它将使用回复代码为0（接受注册）的注册回复进行回复，但不包含任何UDP隧道回复扩展。在这种情况下，移动节点不得使用MIP UDP隧道。
This flag MUST be set by the mobile node when it is using a co-located address, but registering through an FA because it has received an Agent Advertisement with the 'R' bit set.
当移动节点使用同一地址但通过FA注册时，必须由移动节点设置此标志，因为它已接收到设置了“R”位的代理播发。
The 'Reserved 1' and 'Reserved 2' fields must be ignored on receipt, while the 'Reserved 3' field must be 0 on receipt, otherwise this extension MUST be handled as not understood and silently skipped. This permits future additions to this extension to be made which either can co-exist with old implementations, or will force a rejection of the extension from an old implementation.
“保留1”和“保留2”字段在接收时必须忽略，而“保留3”字段在接收时必须为0，否则必须将此扩展处理为未理解并自动跳过。这允许将来对此扩展进行添加，这些添加可以与旧实现共存，也可以强制拒绝来自旧实现的扩展。
The 'Encapsulation' field defines the mode of encapsulation requested if MIP UDP tunnelling is accepted by the home agent. This field uses the same values as the IP header Protocol field:
“封装”字段定义了在归属代理接受MIP UDP隧道时请求的封装模式。此字段使用与IP标头协议字段相同的值：
4 IP header (IP-in-UDP tunnelling) RFC 2003 [4]
4 IP头（UDP隧道中的IP）RFC 2003[4]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
47 GRE头（UDP隧道中的GRE）RFC 2784[8]
55 Minimal IP encapsulation header RFC 2004 [5]
55最小IP封装头RFC 2004[5]
If the home agent finds that UDP tunnelling is not needed, the encapsulation will be determined by the 'M' and 'G' flags of the registration request; but if the home agent finds that MIP UDP tunnelling should be done, the encapsulation is determined from the value of the Encapsulation field. If the value of this field is zero, it defaults to the value of 'M' and 'G' fields in the Registration Request message, but if it is non-zero, it indicates that a particular encapsulation is desired.
如果归属代理发现不需要UDP隧道，则封装将由注册请求的“M”和“G”标志确定；但是，如果归属代理发现应该进行MIP-UDP隧道，则根据封装字段的值确定封装。如果该字段的值为零，则默认为注册请求消息中“M”和“G”字段的值，但如果该值为非零，则表示需要特定的封装。
The Mobile IP registration bits S, B, D, M, G and T retain their meaning as described in RFC 3344 [10] and RFC 3024 [9] (except that the significance of the M and G bits may be modified by the Encapsulation field when MIP UDP tunnelling is used, as described above). The use of the M and G bits together with MIP UDP tunnelling is also touched upon in Section 4.1.
移动IP注册比特S、B、D、M、G和T保留其含义，如RFC 3344[10]和RFC 3024[9]中所述（除了如上所述，当使用MIP UDP隧道时，可以通过封装字段修改M和G比特的重要性）。第4.1节还涉及M和G位以及MIP UDP隧道的使用。
When the MN requests MIP UDP tunnelling, the 'D' bit (Decapsulation by the mobile node) MUST be set, otherwise UDP tunnelling would not be meaningful.
当MN请求MIP UDP隧道时，必须设置“D”位（由移动节点解除封装），否则UDP隧道将没有意义。
Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP tunnelling, even if not all traffic will be reverse tunnelled. This ensures that a HA which is not prepared to accept reverse tunnelling will not accept a registration which may later turn out to be unusable. Also see the discussion of use of the 'T' bit in Foreign Agent Considerations (Section 4.5).
当请求MIP UDP隧道时，MN和FA都应设置“T”位，即使并非所有流量都将反向隧道。这可确保不准备接受反向隧道的医管局不会接受日后可能无法使用的注册。另请参见“外国代理注意事项”中“T”位使用的讨论（第4.5节）。
This extension is a non-skippable extension. It is sent in reply to a UDP Tunnel Request extension, and indicates whether or not the HA will use MIP UDP tunnelling for the current mobility binding. The format of this extension is as shown below.
此扩展是不可跳过的扩展。它被发送以响应UDP隧道请求扩展，并指示HA是否将对当前移动绑定使用MIP UDP隧道。此扩展的格式如下所示。
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 | Sub-Type | Reply Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved | Keepalive Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Sub-Type | Reply Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved | Keepalive Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 44
类型44
Length 6. Length in bytes of this extension, not including the Type and Length bytes.
长度6。此扩展的长度（字节），不包括类型和长度字节。
Sub-Type 0
子类型0
Reply Code Indicates whether the HA assents or declines to use UDP tunnelling for the current mobility binding. See Section 3.2.1 below.
回复代码表示HA是否同意或拒绝对当前移动绑定使用UDP隧道。见下文第3.2.1节。
F F (Forced) flag. Indicates that tunnelling is being forced because the F flag was set in the tunnelling request, irrespective of the detection of a NAT or not.
F（强制）标志。指示由于在隧道请求中设置了F标志而强制隧道，无论是否检测到NAT。
Keepalive Interval Specifies the NAT keepalive interval that the mobile node SHOULD use. A keepalive packet SHOULD be sent if Keepalive Interval seconds have elapsed without any signalling or data traffic being sent. If this field is set to 0, the mobile node MUST use its default configured keepalive interval.
Keepalive Interval指定移动节点应使用的NAT Keepalive间隔。如果在未发送任何信令或数据通信的情况下，已过keepalive间隔秒，则应发送keepalive数据包。如果此字段设置为0，则移动节点必须使用其默认配置的keepalive间隔。
Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception.
保留以备将来使用。发送时必须设置为0，接收时必须忽略。
The Reply Code field of the UDP Tunnel Reply Extension indicates if UDP tunnelling have been accepted and will be used by the HA. Values in the range 0 .. 63 indicate assent, i.e., that tunnelling will be done, while values in the range 64 .. 255 indicate that tunnelling should not be done. More information may be given by the value of the response code.
UDP隧道回复扩展的回复代码字段指示UDP隧道是否已被接受并将由HA使用。值的范围为0。。63表示同意，即将进行隧道开挖，而值在64范围内。。255表示不应进行隧道开挖。响应代码的值可以提供更多信息。
The following response codes are defined for use in the code field of the UDP Tunnel Reply Extension:
以下响应代码定义用于UDP隧道应答扩展的代码字段：
0 Will do tunnelling
0将进行隧道挖掘
64 Tunnelling declined, reason unspecified
64拒绝挖掘隧道，原因不明
This MIP message header serves to differentiate traffic tunnelled through the well-known port 434 from other Mobile IP messages, e.g., Registration Requests and Registration Replies.
该MIP消息报头用于区分通过众所周知的端口434隧道传输的流量与其他移动IP消息，例如，注册请求和注册回复。
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 | Next Header | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Next Header | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4
类型4
Next Header Indicates the type of tunnelled data, using the same numbering as the IP Header Protocol Field.
下一个标头指示隧道数据的类型，使用与IP标头协议字段相同的编号。
Reserved Reserved for future use. MUST be set to 0 on sending, MUST be ignored on reception.
保留以备将来使用。发送时必须设置为0，接收时必须忽略。
The Next Header field uses the same values as the IP header Protocol field. Immediately relevant for use with Mobile IP are the following values:
下一个标头字段使用与IP标头协议字段相同的值。与移动IP使用直接相关的是以下值：
4 IP header (IP-in-UDP tunnelling) RFC 2003 [4]
4 IP头（UDP隧道中的IP）RFC 2003[4]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
47 GRE头（UDP隧道中的GRE）RFC 2784[8]
55 Minimal IP encapsulation header RFC 2004 [5]
55最小IP封装头RFC 2004[5]
The receiver of a tunnelled packet MUST check that the Next Header value matches the tunnelling mode established for the mobility binding with which the packet was sent. If a discrepancy is detected, the packet MUST be dropped. A log entry MAY be written, but in this case the receiver SHOULD ensure that the amount of log entries written is not excessive.
隧道数据包的接收者必须检查下一个报头值是否与为发送数据包的移动性绑定建立的隧道模式匹配。如果检测到差异，则必须丢弃数据包。可以写入日志条目，但在这种情况下，接收方应确保写入的日志条目不会过多。
In addition to the encapsulation forms listed above, the MIP UDP tunnelling can potentially support other encapsulations, by use of the Next Header field in the MIP Tunnel Data Header and the Encapsulation Header field of the UDP Tunnel Request Extension (Section 3.1).
除了上面列出的封装形式外，通过使用MIP隧道数据头中的下一个头字段和UDP隧道请求扩展的封装头字段（第3.1节），MIP UDP隧道可能支持其他封装。
The only change to the Mobility Agent Advertisement Extension defined in RFC 3344 [10] is a flag indicating that the foreign agent generating the Agent Advertisement supports MIP UDP Tunnelling. The flag is inserted after the flags defined in [10].
RFC 3344[10]中定义的移动代理播发扩展的唯一更改是一个标志，指示生成代理播发的外部代理支持MIP UDP隧道。在[10]中定义的标志之后插入该标志。
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|r|T|U| 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|r|T|U| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
The flag is defined as follows:
该标志的定义如下：
U UDP Tunnelling support. This Agent supports MIP UDP Tunnelling as specified in this document. This flag SHOULD be set in advertisements sent by a foreign agent which supports MIP UDP tunnelling and is situated behind a NAT. It MUST NOT be set in advertisements from foreign agents which are not situated behind a NAT, and thus has no need to advertise the capability.
U UDP隧道支持。此代理支持本文档中指定的MIP UDP隧道。此标志应在由支持MIP UDP隧道且位于NAT后面的外部代理发送的广告中设置。不得在不位于NAT后面的外国代理商的广告中设置该功能，因此无需宣传该功能。
One new registration reply code is defined:
定义了一个新的注册回复代码：
ERROR_HA_UDP_ENCAP_UNAVAIL Requested UDP tunnel encapsulation unavailable
错误\u HA\u UDP\u ENCAP\u UNAVAIL请求的UDP隧道封装不可用
This is used by the HA to distinguish the registration denial caused by an unavailable UDP tunnel encapsulation mode from a denial caused by unavailable standard tunnel encapsulation requested by use of the 'T' bit together with either 'M' or 'G' bit.
HA使用它来区分不可用的UDP隧道封装模式导致的注册拒绝，以及使用“T”位和“M”或“G”位请求的不可用标准隧道封装导致的拒绝。
The default encapsulation mode for MIP UDP tunnelling is IP-in-UDP encapsulation. The mobile node MAY request alternative forms of encapsulation to be used with UDP tunnelling by setting the 'M' bit and/or the 'G' bit of a Mobile IP registration request, or by explicitly requesting a particular encapsulation for the MIP UDP tunnel by using the Encapsulation field. The M and G bits retain the meaning as described in RFC 3344 [10] within the context of MIP UDP tunnelling. The UDP tunnelling version of the classic MIP encapsulation methods can be summarised as:
MIP-UDP隧道的默认封装模式是IP-in-UDP封装。移动节点可以通过设置移动IP注册请求的“M”位和/或“G”位，或者通过使用封装字段显式地请求MIP UDP隧道的特定封装，来请求用于UDP隧道的替代封装形式。M和G位在MIP UDP隧道的上下文中保留RFC 3344[10]中所述的含义。经典MIP封装方法的UDP隧道版本可以总结为：
IP in UDP. When Mobile IP UDP tunnelling is used, this is the default encapsulation type. Any home agent and mobile node that implements Mobile IP UDP tunnelling MUST implement this encapsulation type.
UDP中的IP。使用移动IP UDP隧道时，这是默认的封装类型。任何实现移动IP UDP隧道的归属代理和移动节点都必须实现此封装类型。
GRE in UDP. If the 'G' bit is set in a registration request and the Encapsulation field is zero, the mobile node requests that its home agent use GRE encapsulation [3] for datagrams tunnelled to the mobile node. If MIP UDP tunnelling is also requested and accepted, GRE-in-UDP encapsulation SHALL be used in the same cases as GRE in IP encapsulation would be used if the MIP UDP tunnelling had not been requested.
UDP的GRE。如果在注册请求中设置了“G”位且封装字段为零，则移动节点请求其归属代理对隧道传输到移动节点的数据报使用GRE封装[3]。如果还请求并接受MIP UDP隧道，则应在与未请求MIP UDP隧道时使用GRE in IP封装相同的情况下使用GRE in UDP封装。
Minimal encapsulation in UDP. If the 'M' bit is set and the Encapsulation field is zero, the mobile node requests that its home agent use minimal encapsulation [5] for datagrams tunnelled to the mobile node. If MIP UDP tunnelling is also used, minimal encapsulation in UDP SHALL be used in the same cases as minimal encapsulation according to RFC 2004 [5] would be used if the MIP UDP tunnelling had not been requested.
UDP中的最小封装。如果设置了“M”位且封装字段为零，则移动节点请求其归属代理对隧道传输到移动节点的数据报使用最小封装[5]。如果还使用MIP UDP隧道，则UDP中的最小封装应在与RFC 2004[5]中的最小封装相同的情况下使用，如果未请求MIP UDP隧道，则将使用最小封装。
When the Encapsulation field is non-zero, a particular encapsulation format is requested for the MIP UDP tunnel. If tunnelling is indicated, the request MUST either be accepted using the requested encapsulation, or rejected with the error code ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation unavailable" defined in Section 3.5. On receipt of this error, the mobile node MAY choose to send a new Registration Request with different requirements on MIP UDP tunnelling encapsulation.
当封装字段为非零时，将为MIP UDP隧道请求特定的封装格式。如果指示了隧道，则必须使用请求的封装接受请求，或使用错误代码error_HA_UDP_ENCAP_UNAVAIL拒绝请求，错误代码为第3.5节中定义的“请求的UDP隧道封装不可用”。在收到该错误时，移动节点可以选择发送对MIP UDP隧道封装有不同要求的新注册请求。
MIP IP-in-UDP tunnelling, or UDP tunnelling for short, is done in a manner analogous to that described for IP-in-IP tunnelling in RFC 2003 [4], with the exception of the addition of an UDP header [1] and MIP Message header [10] between the outer and inner IP header.
UDP隧道中的MIP IP，简称UDP隧道，以类似于RFC 2003[4]中描述的IP隧道中的IP的方式完成，除了在外部和内部IP报头之间添加UDP报头[1]和MIP消息报头[10]之外。
Mobile IP Registration Requests and Registration Replies are already in the form of UDP messages, and SHALL NOT be tunnelled even when MIP IP-in-UDP tunnelling is in force.
移动IP注册请求和注册回复已采用UDP消息的形式，即使UDP隧道中的MIP IP有效，也不应进行隧道传输。
To encapsulate an IP datagram using MIP IP-in-UDP encapsulation, an outer IP header [2], UDP header [1] and MIP Message header [10] is inserted before the datagram's existing IP header, as follows:
要使用UDP封装中的MIP IP封装IP数据报，在数据报的现有IP报头之前插入外部IP报头[2]、UDP报头[1]和MIP消息报头[10]，如下所示：
+---------------------------+
| |
| Outer IP Header |
+---------------------------+
| |
| UDP Header |
+---------------------------+
| MIP Tunnel Data |
| Message Header |
+---------------------------+ +---------------------------+
| | | |
| IP Header | | IP Header |
+---------------------------+ ====> +---------------------------+
| | | |
| IP Payload | | IP Payload |
| | | |
| | | |
+---------------------------+ +---------------------------+
+---------------------------+
| |
| Outer IP Header |
+---------------------------+
| |
| UDP Header |
+---------------------------+
| MIP Tunnel Data |
| Message Header |
+---------------------------+ +---------------------------+
| | | |
| IP Header | | IP Header |
+---------------------------+ ====> +---------------------------+
| | | |
| IP Payload | | IP Payload |
| | | |
| | | |
+---------------------------+ +---------------------------+
The outer IP header Source Address and Destination Address, together with the UDP header Source Port and Destination Port, identify the "endpoints" of the tunnel. The inner IP header Source Address and Destination Addresses identify the original sender and the recipient of the datagram, respectively. The inner IP header is not changed by the encapsulator, except to decrement the TTL by one if the tunnelling is being done as part of forwarding the datagram as noted in RFC 2003 [4], and remains unchanged during its delivery to the tunnel exit point. No change to IP options in the inner header occurs during delivery of the encapsulated datagram through the tunnel. Note that the security options of the inner IP header MAY affect the choice of security options for the encapsulating (outer) IP header.
外部IP头源地址和目标地址，以及UDP头源端口和目标端口，标识隧道的“端点”。内部IP报头源地址和目标地址分别标识数据报的原始发送方和接收方。封装器不会更改内部IP报头，除非如RFC 2003[4]中所述，如果隧道作为转发数据报的一部分进行，则将TTL减少1，并且在将其传送到隧道出口点期间保持不变。在通过隧道传递封装的数据报期间，内部报头中的IP选项不会发生更改。请注意，内部IP头的安全选项可能会影响封装（外部）IP头的安全选项选择。
Minimal Encapsulation and GRE encapsulation is done in an analogous manner, following RFC 2004 [5] for Minimal Encapsulation and RFC 2784 [8] for GRE Encapsulation, but using outer IP, UDP and MIP headers in place of the outer IP header.
最小封装和GRE封装是以类似的方式完成的，遵循RFC 2004[5]进行最小封装，RFC 2784[8]进行GRE封装，但使用外部IP、UDP和MIP报头代替外部IP报头。
All other provisions and requirements of RFC 2003 [4] and RFC 3024 [9] are in force, except in one respect, as covered in Packet Fragmentation (Section 4.8).
RFC 2003[4]和RFC 3024[9]的所有其他规定和要求均有效，但包碎片（第4.8节）中涵盖的一个方面除外。
Before decapsulation is actually done, the decapsulating node MUST verify that the outer IP addresses and UDP port numbers exactly match the values used for the tunnel, with the exception of tunnels that are "half bound" (as described in Section 4.11) where the source UDP port can change.
在实际完成解除封装之前，解除封装节点必须验证外部IP地址和UDP端口号是否与隧道使用的值完全匹配，但源UDP端口可以更改的“半绑定”（如第4.11节所述）隧道除外。
IP-in-UDP encapsulated traffic is decapsulated simply by stripping off the outer IP, UDP and MIP header, which leaves the original IP packet which is forwarded as is.
UDP封装流量中的IP只需剥离外部IP、UDP和MIP报头即可解除封装，从而保留原始IP数据包，并按原样转发。
Minimal IP encapsulation is processed by the receiver conceptually as follows. First, the UDP and the Mobile IP headers are removed from the packet, and the Protocol field of the IP header replaced with the Next Header field in the MIP Tunnel Data header. Second, the remaining IP header total length and checksum are adjusted to match the stripped packet. Third, ordinary minimal IP encapsulation processing is done.
接收器在概念上处理最小IP封装，如下所示。首先，从数据包中删除UDP和移动IP报头，并用MIP隧道数据报头中的下一个报头字段替换IP报头的协议字段。其次，调整剩余的IP报头总长度和校验和以匹配剥离的数据包。第三，完成普通的最小IP封装处理。
GRE encapsulated traffic is processed according to RFC 2784 [8] and RFC 1701 [3], with the delivery header consisting of the outer IP, UDP and MIP headers.
GRE封装的通信量根据RFC 2784[8]和RFC 1701[3]进行处理，传输报头由外部IP、UDP和MIP报头组成。
The UDP Tunnel Request Extension MAY be used in a Mobile IP Registration Request from the mobile node to the home agent when the mobile node uses a co-located care-of address. It SHALL NOT be used by the mobile node when it is registering with a foreign agent care-of address.
当移动节点使用同一位置的转交地址时，可以在从移动节点到归属代理的移动IP注册请求中使用UDP隧道请求扩展。当移动节点向外国代理转交地址注册时，它不得被移动节点使用。
The purpose of this extension is to indicate to the home agent that the mobile node is able to accept MIP UDP tunnelling if the home agent has an indication that the mobile node resides behind a NAT or NAPT. It thus functions as a conditional solicitation for the use of MIP UDP tunnelling.
此扩展的目的是向归属代理指示，如果归属代理指示移动节点位于NAT或NAPT后面，则移动节点能够接受MIP UDP隧道。因此，它可以作为使用MIP-UDP隧道的条件请求。
As per Section 3.2 and 3.6.1.3 of RFC 3344 [10], the mobile node MUST place this Extension before the Mobile-Home Authentication Extension in registration messages, so that it is covered by the Mobile-Home Authentication Extension.
根据RFC 3344[10]的第3.2节和第3.6.1.3节，移动节点必须在注册消息中将此扩展置于移动家庭认证扩展之前，以便它被移动家庭认证扩展覆盖。
If the mobile node includes the UDP Tunnel Request extension in a registration request, but receives a registration reply without a UDP Tunnel Reply extension, it MUST assume that the HA does not
如果移动节点在注册请求中包含UDP隧道请求扩展，但收到的注册回复没有UDP隧道回复扩展，则必须假定HA没有
understand this extension, and it MUST NOT use UDP tunnelling. If the mobile node is in fact behind a NAT, the registration may then succeed, but traffic will not be able to traverse the NAT.
了解此扩展，它不能使用UDP隧道。如果移动节点实际上位于NAT后面，则注册可能会成功，但通信量将无法穿越NAT。
When the mobile node sends MIP UDP tunnelled data, it MUST use the same UDP source port as was used for the most recent registration request.
当移动节点发送MIP UDP隧道数据时，它必须使用与最近的注册请求相同的UDP源端口。
When the mobile node re-registers without having moved, it SHOULD take care to use the same source port as was used for the original registration of the current mobility binding. Otherwise, while the home agent would change destination port on acceptance of the new registration, and the mobile node would presumably start listening on the new port, the packets in flight from the home agent at the time of change will be dropped when arriving at the mobile node's old port. (This does not mean that the home agent should refuse a registration request using MIP UDP tunnelling where a new port have been used, as this might be the result of the NAT dropping state, the mobile node re-booting, changing interface, etc.)
当移动节点在未移动的情况下重新注册时，应注意使用与当前移动绑定的原始注册相同的源端口。否则，虽然归属代理将在接受新注册时更改目的地端口，并且移动节点可能会开始侦听新端口，但是在更改时来自归属代理的正在飞行的分组将在到达移动节点的旧端口时丢弃。（这并不意味着归属代理应在使用了新端口的情况下，使用MIP UDP隧道拒绝注册请求，因为这可能是NAT丢弃状态、移动节点重新引导、更改接口等的结果。）
If a mobile node is registering through a foreign agent but using a co-located care-of address, and the agent advertisement from the foreign agent had the 'U' bit set, the mobile node MUST set the 'R' flag in its UDP Tunnel Request Extension, in order to make the HA use MIP UDP tunnelling. In this case, the mobile node also MUST send a keepalive as soon as its registration has been accepted.
如果移动节点通过外部代理注册，但使用同一位置的转交地址，并且来自外部代理的代理播发设置了“U”位，则移动节点必须在其UDP隧道请求扩展中设置“R”标志，以便使HA使用MIP UDP隧道。在这种情况下，移动节点还必须在其注册被接受后立即发送keepalive。
If a mobile node is registering through a foreign agent but using a co-located care-of address, and the agent advertisement from the foreign agent does not have the 'U' bit set, the mobile node MUST NOT include a UDP Tunnel Request Extension in the registration request.
如果移动节点通过外部代理注册，但使用同一位置的转交地址，并且来自外部代理的代理播发未设置“U”位，则移动节点不得在注册请求中包括UDP隧道请求扩展。
The UDP Tunnel Request Extension MAY be used by a foreign agent when it is forwarding a Mobile IP Registration Request to a home agent, when the foreign agent is situated behind a NAT or has some other compelling reason to require MIP UDP tunnelling.
当外部代理将移动IP注册请求转发给归属代理时，当外部代理位于NAT后面或有其他强制理由需要MIP UDP隧道时，可以使用UDP隧道请求扩展。
The purpose of this extension is to indicate to the home agent that the foreign agent is able to accept MIP UDP tunnelling if the home agent has an indication that the foreign agent resides behind a NAT or NAPT. It thus functions as a conditional solicitation for the use of MIP UDP tunnelling.
此扩展的目的是向归属代理指示，如果归属代理指示该外部代理驻留在NAT或NAPT后面，则该外部代理能够接受MIP UDP隧道。因此，它可以作为使用MIP-UDP隧道的条件请求。
A foreign agent which requires the mobile node to register through a foreign agent by setting the 'R' bit in the agent advertisement, MUST NOT add the UDP Tunnel Request Extension when forwarding a
通过在代理播发中设置“R”位，要求移动节点通过外部代理注册的外部代理在转发请求时不得添加UDP隧道请求扩展
registration request which uses a co-located care-of address, as this will lead to a UDP tunnel being set up from the home agent to the foreign agent instead of to the mobile node.
使用同一位置转交地址的注册请求，因为这将导致从本地代理到外部代理而不是移动节点建立UDP隧道。
As per Section 3.2 and 3.7.2.2 of RFC 3344 [10], the foreign agent when using this extension MUST place it after the Mobile-Home Authentication Extension in registration messages. If the foreign agent shares a mobility security association with the home agent and therefore appends a Foreign-Home Authentication Extension, the UDP Tunnel Request Extension MUST be placed before the Foreign-Home Authentication Extension.
根据RFC 3344[10]第3.2节和第3.7.2.2节的规定，外国代理在使用此扩展时，必须在注册消息中将其置于移动家庭身份验证扩展之后。如果外部代理与归属代理共享移动安全关联，因此附加了外部归属身份验证扩展，则UDP隧道请求扩展必须放在外部归属身份验证扩展之前。
As the home agent detects the presence of a NAT in the path between the sender and itself by seeing a mismatch between the IP source address and the care-of address given in the registration request, it is REQUIRED that the foreign agent, when using this extension, sends the registration request with an IP source address matching the care-of address.
由于归属代理通过查看IP源地址和注册请求中给出的转交地址之间的不匹配来检测发送方和自身之间的路径中是否存在NAT，因此要求外部代理在使用此扩展时，使用与转交地址匹配的IP源地址发送注册请求。
A foreign agent using MIP UDP tunnelling to a home agent because the FA is situated behind a NAT may be configured to encourage reverse tunnelling, or be neutral about it, depending on the characteristics of the NAT. If the NAT translates all source addresses of outgoing packets to its own public address, it will not be possible to maintain sessions when moving away from this network if the mobile node has used triangular routing instead of reverse tunnelling. On the other hand, if it is known that the NAT is smart enough to not translate publicly routable source addresses, AND does not do ingress filtering, triangular routing may succeed. The leg from the home agent to the foreign agent will still use MIP UDP tunnelling to pass through the NAT.
由于FA位于NAT后面，因此使用MIP-UDP隧道到归属代理的外部代理可以被配置为鼓励反向隧道，或者对其保持中立，这取决于NAT的特性。如果NAT将传出数据包的所有源地址转换为其自己的公共地址，则如果移动节点使用三角形路由而不是反向隧道，则在离开该网络时将不可能维持会话。另一方面，如果已知NAT足够聪明，不会转换公开可路由的源地址，并且不进行入口过滤，则三角路由可能会成功。从本地代理到外部代理的分支仍将使用MIP UDP隧道通过NAT。
Therefore, if it is known when configuring a foreign agent behind a NAT that the NAT will translate public as well as private addresses, or it is known that ingress filtering is being done between the private and public networks, the foreign agent SHOULD reply to registration requests which don't have the 'T' bit set with a reply code 75, "reverse tunnel is mandatory and 'T' bit not set".
因此，如果在NAT后面配置外部代理时知道NAT将转换公共地址和私有地址，或者知道在私有网络和公共网络之间进行入口过滤，则外部代理应使用回复代码75回复未设置“t”位的注册请求，“反向通道是必需的，未设置'T'位”。
Conversely, if it is known that the NAT is smart about not translating public addresses, and no ingress filtering is done, so it is reasonable to believe that a mobile node with a publicly routable address may be able to keep up sessions when moving to or from this network, the foreign agent MAY be configured to forward registration requests even if they don't have the 'T' bit set.
相反，如果已知NAT在不转换公共地址方面是聪明的，并且没有进行入口过滤，那么有理由相信具有公共路由地址的移动节点在移动到该网络或从该网络移动时能够保持会话，外部代理可以配置为转发注册请求，即使它们没有设置“t”位。
If the behaviour of the NAT is unknown in this respect, it SHOULD be assumed that it will translate all addresses, thus the foreign agent SHOULD be configured to reply to registration requests which don't have the 'T' bit set with a reply code 75, "reverse tunnel is mandatory and 'T' bit not set".
如果NAT的行为在这方面是未知的，则应假定它将转换所有地址，因此，应将外部代理配置为回复未设置“t”位的注册请求，回复代码为75，“反向隧道是必需的，且未设置“t”位”。
The purpose of the MIP UDP Tunnel Reply Extension is to indicate whether or not the home agent accepts the use of MIP UDP tunnelling for this mobility binding, and to inform the mobile node or foreign agent of the suggested tunnel keepalive interval to be used.
MIP-UDP隧道应答扩展的目的是指示归属代理是否接受使用MIP-UDP隧道进行此移动绑定，并通知移动节点或外部代理要使用的建议隧道keepalive间隔。
The UDP Tunnel Reply Extension MUST be used in a Mobile IP Registration Reply from the home agent to the mobile node when it has received and accepted a UDP Tunnel Request (Section 3.1) from a mobile node.
当从移动节点接收并接受UDP隧道请求（第3.1节）时，必须在从归属代理到移动节点的移动IP注册回复中使用UDP隧道回复扩展。
The home agent MUST use a mismatch between source IP address and care-of address in the Mobile IP Registration Request message as the indication that a mobile node may reside behind a NAT. If the Registration Request also contains the UDP Tunnel Request extension without the 'R' flag set, and the home agent is capable of, and permits MIP UDP tunnelling, the home agent SHALL respond with a registration reply containing an assenting UDP Tunnel Reply Extension as described in Section 3.2. If the 'R' flag is set, special considerations apply, as described below.
The home agent MUST use a mismatch between source IP address and care-of address in the Mobile IP Registration Request message as the indication that a mobile node may reside behind a NAT. If the Registration Request also contains the UDP Tunnel Request extension without the 'R' flag set, and the home agent is capable of, and permits MIP UDP tunnelling, the home agent SHALL respond with a registration reply containing an assenting UDP Tunnel Reply Extension as described in Section 3.2. If the 'R' flag is set, special considerations apply, as described below.translate error, please retry
If the home agent receives a Registration Request with matching source IP address and co-located care-of address which contains a MIP UDP Tunnel Request Extension, the home agent SHOULD respond with a Registration Reply containing a declining UDP Tunnel Reply - unless tunnelling has been explicitly requested by the mobile node using the 'F' flag as described in Section 3.1.
If the home agent receives a Registration Request with matching source IP address and co-located care-of address which contains a MIP UDP Tunnel Request Extension, the home agent SHOULD respond with a Registration Reply containing a declining UDP Tunnel Reply - unless tunnelling has been explicitly requested by the mobile node using the 'F' flag as described in Section 3.1.translate error, please retry
If the home agent assents to UDP tunnelling, it MUST use the source address of the registration request as the effective care-of address, rather than the care-of address given in the registration request, except in the case where the 'R' flag is set in the UDP Tunnel Request Extension.
如果归属代理同意UDP隧道，它必须使用注册请求的源地址作为有效转交地址，而不是注册请求中给出的转交地址，UDP隧道请求扩展中设置了“R”标志的情况除外。
If the home agent receives a Registration Request with the 'R' flag set in the UDP Tunnel Request Extension, it SHOULD reply with an assenting UDP Tunnel Reply Extension if it is capable of, and permits MIP UDP tunnelling. In this case, however, the source address and port of the registration request may be a NAT'ed version of the foreign agent source address and port. In order to direct tunnelled traffic correctly to the mobile node, the home agent MUST wait for
如果归属代理接收到一个注册请求，并且在UDP隧道请求扩展中设置了“R”标志，则如果它能够并允许MIP UDP隧道，它应该使用一个同意的UDP隧道回复扩展进行回复。然而，在这种情况下，注册请求的源地址和端口可能是外部代理源地址和端口的NAT版本。为了将隧道传输的流量正确地引导到移动节点，归属代理必须等待
the first keepalive packet from the mobile node to arrive, before it can send traffic back to the correct NAT port (the one which is mapped to the MN). In this case, the home agent MUST check that the outer source address (but not the port) of this keepalive packet is identical with the source address of the corresponding registration request. The inner source address (that of the encapsulated ICMP echo request) MUST be the home address of the mobile node, and the inner destination address MUST be that of the home agent. If all this holds, the outer source address and port of this keepalive packet SHALL be used by the HA as the outer destination address and port of the MIP UDP tunnel when forwarding traffic to the mobile node.
在移动节点将流量发送回正确的NAT端口（映射到MN的端口）之前，要到达的第一个keepalive数据包。在这种情况下，归属代理必须检查此keepalive数据包的外部源地址（而不是端口）是否与相应注册请求的源地址相同。内部源地址（封装的ICMP回显请求的源地址）必须是移动节点的归属地址，内部目标地址必须是归属代理的归属地址。如果所有这些都成立，HA在将流量转发到移动节点时，应将此keepalive数据包的外部源地址和端口用作MIP UDP隧道的外部目标地址和端口。
The home agent SHOULD be consistent in acknowledging support for UDP tunnelling or not. A home agent which understands the UDP Tunnel Request Extension and is prepared to respond positively to such a request SHOULD also respond with a UDP Tunnel Reply Extension containing a declining reply code if use of MIP UDP tunnelling is not indicated for a session. The mobile node MUST NOT assume such behaviour from the home agent, since the home agent may undergo a software change with reboot, a policy change or a replacement; and consequently a change of behaviour.
归属代理在确认是否支持UDP隧道时应保持一致。如果会话中未指示使用MIP UDP隧道，则理解UDP隧道请求扩展并准备积极响应此类请求的归属代理也应使用包含拒绝应答代码的UDP隧道应答扩展进行响应。移动节点不得从归属代理处承担此类行为，因为归属代理可能会经历软件更改以及重新启动、策略更改或替换；从而导致行为的改变。
The following actions take place when things go wrong.
出现问题时，会发生以下操作。
The HA does not support the UDP Tunnel Request extension:
HA不支持UDP隧道请求扩展：
The home agent ignores the extension and proceeds normally, which would be to refuse the registration if the IP source address does not match the care-of address, the home address or 0.0.0.0. Even if the HA mistakenly does accept the registration, the mobile node will not be able to receive forward tunnelled data if it is behind a NAT.
归属代理忽略扩展并正常进行，如果IP源地址与转交地址、归属地址或0.0.0.0不匹配，则将拒绝注册。即使HA错误地接受了注册，如果移动节点位于NAT后面，它也将无法接收前向隧道数据。
(It would be beneficial to have the mobile node de-register in this case. The mobile node, however, normally has no way of telling that it is behind a NAT if it does not receive a UDP Tunnelling Reply.)
（在这种情况下，让移动节点取消注册是有益的。但是，如果移动节点没有收到UDP隧道应答，则通常无法判断它在NAT后面。）
NAT detected by home agent, but traversal not allowed:
归属代理检测到NAT，但不允许遍历：
In some cases the home agent may disable NAT traversal even though it supports the UDP Tunnel Request extension and a NAT is detected. In this case, the home agent SHOULD send a Registration Reply with the Code field set to 129, "administratively prohibited".
在某些情况下，归属代理可能会禁用NAT遍历，即使它支持UDP隧道请求扩展并且检测到NAT。在这种情况下，归属代理应发送代码字段设置为129“行政禁止”的注册回复。
NAT not detected, 'F' flag set, but home agent does not allow forced use of MIP UDP tunnelling:
未检测到NAT，设置了“F”标志，但home agent不允许强制使用MIP UDP隧道：
The home agent SHOULD send a Registration Reply with the Code field set to 129, "administratively prohibited".
归属代理应发送注册回复，代码字段设置为129，“行政禁止”。
UDP Tunnel Request extension sent by the mobile node (placed before the MN-HA authentication extension), but 'D' bit in registration request header not set:
移动节点发送的UDP隧道请求扩展（位于MN-HA身份验证扩展之前），但未设置注册请求标头中的“D”位：
The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request".
归属代理应发送注册回复，代码字段设置为134，“格式错误的请求”。
UDP Tunnel Request extension sent by the foreign agent (placed after the MN-HA authentication extension), but 'D' bit is set:
外部代理发送的UDP隧道请求扩展（位于MN-HA身份验证扩展之后），但设置了“D”位：
The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request".
归属代理应发送注册回复，代码字段设置为134，“格式错误的请求”。
Reserved 3 field of UDP Tunnel Request extension is nonzero:
UDP隧道请求扩展的保留3字段为非零：
The home agent SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request".
归属代理应发送注册回复，代码字段设置为134，“格式错误的请求”。
Encapsulation type requested in UDP Tunnel Request extension is unsupported:
UDP隧道请求扩展中请求的封装类型不受支持：
The home agent SHOULD send a Registration Reply with the Code field set to ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation unavailable" defined in Section 3.5.
归属代理应发送注册回复，代码字段设置为错误\u HA\u UDP\u ENCAP\u UNAVAIL，第3.5节中定义的“请求的UDP隧道封装不可用”。
UDP tunnelling SHALL be used only for data packets, and only when the mobility binding used for sending was established using the UDP Tunnel Request, and accepted by an UDP Tunnel Reply from the home agent. After MIP UDP tunnelling has been established for a mobility binding, data packets that are forward or reverse tunnelled using this mobility binding MUST be tunnelled using MIP UDP tunnelling, not IP-in-IP tunnelling or some other tunnelling method.
UDP隧道只能用于数据包，并且只能在使用UDP隧道请求建立用于发送的移动绑定，并被来自归属代理的UDP隧道回复接受时使用。为移动性绑定建立MIP UDP隧道后，使用此移动性绑定进行正向或反向隧道的数据包必须使用MIP UDP隧道，而不是IP-in-IP隧道或其他隧道方法进行隧道。
As a consequence:
因此：
- Mobile IP signalling is never tunnelled.
- 移动IP信令永远不会通过隧道传输。
- When using simultaneous bindings, each binding may have a different type (i.e., UDP tunnelling bindings may be mixed with non-UDP tunnelling bindings).
- 使用同时绑定时，每个绑定可能具有不同的类型（即UDP隧道绑定可能与非UDP隧道绑定混合）。
- Tunnelling is only allowed for the duration of the binding lifetime.
- 隧道仅在绑定生存期内允许。
From RFC 3022 [12]:
来自RFC 3022[12]：
"Translation of outbound TCP/UDP fragments (i.e., those originating from private hosts) in NAPT set-up are doomed to fail. The reason is as follows. Only the first fragment contains the TCP/UDP header that would be necessary to associate the packet to a session for translation purposes. Subsequent fragments do not contain TCP/UDP port information, but simply carry the same fragmentation identifier specified in the first fragment. Say, two private hosts originated fragmented TCP/UDP packets to the same destination host. And, they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned host address, it is unable to determine which of the two sessions the datagrams belong to. Consequently, both sessions will be corrupted."
出站TCP/UDP片段的转换（即，来自私有主机的片段）在NAPT中，设置注定会失败。原因如下。只有第一个片段包含TCP/UDP标头，该标头是将数据包与会话关联以进行转换所必需的。后续片段不包含TCP/UDP端口信息，只携带在第一个片段中指定的相同片段标识符。Say、 两个专用主机向同一目标主机发送了分段TCP/UDP数据包。而且，它们碰巧使用了相同的分段标识符。当目标主机接收到两个不相关的数据报时，目标主机从相同的分配主机地址接收到相同的分段id，它无法确定这两个会话中的哪个会话包含数据报b私奔到。因此，两个会话都将被破坏。”
Because of this, if the mobile node or foreign agent for any reason needs to send fragmented packets, the fragmentation MUST be done prior to the encapsulation. This differs from the case for IP-in-IP tunnelling, where fragmentation may be done before or after encapsulation, although RFC 2003 [4] recommends doing it before encapsulation.
因此，如果移动节点或外部代理出于任何原因需要发送分段数据包，则必须在封装之前完成分段。这与IP隧道中的IP情况不同，IP隧道中的碎片可以在封装之前或之后完成，尽管RFC 2003[4]建议在封装之前完成。
A similar issue exists with some firewalls, which may have rules that only permit traffic on certain TCP and UDP ports, and not arbitrary outbound (or inbound) IP traffic. If this is the case and the firewall is not set to do packet reassembly, a home agent behind a firewall will also have to do packet fragmentation before MIP UDP encapsulation. Otherwise, only the first fragment (which contains the UDP header) will be allowed to pass from the home agent out through the firewall.
一些防火墙也存在类似的问题，其规则可能只允许某些TCP和UDP端口上的流量，而不允许任意出站（或入站）IP流量。如果是这种情况，并且防火墙未设置为执行数据包重组，则防火墙后面的归属代理也必须在MIP UDP封装之前执行数据包分段。否则，只允许第一个片段（包含UDP头）从归属代理通过防火墙传出。
For this reason, the home agent SHOULD do packet fragmentation before it does MIP UDP encapsulation.
因此，归属代理应该在进行MIP UDP封装之前先进行数据包分段。
As the existence of the bi-directional UDP tunnel through the NAT is dependent on the NAT keeping state information associated with a session, as described in RFC 2663 [11], and as the NAT may decide that the session has terminated after a certain time, keepalive messages may be needed to keep the tunnel open. The keepalives should be sent more often than the timeout value used by the NAT.
由于通过NAT的双向UDP隧道的存在取决于保持与会话相关联的状态信息的NAT，如RFC 2663[11]中所述，并且由于NAT可能决定会话在一定时间后已终止，因此可能需要keepalive消息来保持隧道打开。keepalives的发送频率应高于NAT使用的超时值。
This timeout may be assumed to be a couple of minutes, according to RFC 2663 [11], but it is conceivable that shorter timeouts may exist in some NATs.
根据RFC 2663[11]，该超时可以假定为几分钟，但可以想象，在某些NAT中可能存在较短的超时。
For this reason the extension used to set up the UDP tunnel has the option of setting the keepalive message interval to another value than the default value, see Section 3.2.
因此，用于设置UDP隧道的扩展可以选择将keepalive消息间隔设置为默认值以外的其他值，请参见第3.2节。
The keepalive message sent MUST consist of a properly UDP encapsulated ICMP echo request directed to the home agent.
发送的keepalive消息必须由定向到归属代理的正确UDP封装ICMP回显请求组成。
For each mobility binding which has UDP tunnelling established, the non-HA endpoint of the Mobile-IP UDP tunnel MUST send a keepalive packet if no other packet to the HA has been sent in K seconds. Here K is a parameter with a default value of 110 seconds. K may be set to another value by the HA as described in the UDP tunnelling reply extension (Section 3.2).
对于已建立UDP隧道的每个移动绑定，如果在K秒内未向HA发送其他数据包，则移动IP UDP隧道的非HA端点必须发送keepalive数据包。这里K是一个默认值为110秒的参数。可由HA将K设置为UDP隧道应答扩展（第3.2节）中所述的另一个值。
Except for the case where the mobile node registers with a co-located address through an FA (see Section 4.11) MIP UDP tunnelling is done using the same ports that have already been used for the registration request / reply exchange. The MN or FA will send its first keepalive message at the earliest K seconds after the registration request was sent. The same UDP source port MUST be used for the keepalive messages as was used for the original Registration Messages and for data messages.
除了移动节点通过FA（参见第4.11节）使用同一地址注册的情况外，MIP UDP隧道使用已用于注册请求/应答交换的相同端口完成。MN或FA将在发送注册请求后最早的K秒发送其第一条keepalive消息。keepalive消息必须使用与原始注册消息和数据消息相同的UDP源端口。
The remote UDP tunnel endpoint MUST use two-way keepalives consisting of UDP encapsulated ICMP Echo Request/Reply messages. The rationale for using two-way keepalives is two-fold:
远程UDP隧道终结点必须使用由UDP封装的ICMP回显请求/回复消息组成的双向keepalives。使用双向keepalives的理由有两个：
1. Two-way keepalives allow the mobile node to detect loss of a NAT mapping. Detection of NAT mapping loss in turn allows the MN to compensate by re-registering and using a shorter keepalive to avoid loss of NAT mappings in the future.
1. 双向保留允许移动节点检测NAT映射的丢失。NAT映射丢失的检测反过来允许MN通过重新注册和使用较短的保留期进行补偿，以避免将来NAT映射丢失。
2. One-way keepalives (keepalives sent by MN or FA, but without any reply from the home agent) actually cause more keepalive traffic overhead; the keepalive messages have to be sent more frequently to compensate for occasional loss of keepalive messages. In contrast, two-way keepalives are acknowledged, and retransmissions occur only when a response is not received for a keepalive request within a reasonable time.
2. 单向keepalives（由MN或FA发送的keepalives，但没有来自家乡代理的任何回复）实际上会导致更多keepalive流量开销；必须更频繁地发送keepalive消息，以补偿keepalive消息的偶尔丢失。相反，双向保留被确认，并且只有当在合理的时间内没有收到保留请求的响应时，才会发生重传。
When a mobile node is using UDP encapsulated ICMP Echo Request/Reply messages as keepalives, it will have to deal with the possibility
当移动节点使用UDP封装的ICMP回显请求/回复消息作为keepalive时，它必须处理这种可能性
that a NAT mapping is lost by a NAT device. The crucial thing here is of course not the loss of the NAT mapping in itself; but rather that the home agent, in the absence of a Registration Request through the new mapping, will continue to send traffic to the NAT port associated with the old mapping.
NAT设备丢失NAT映射。这里的关键当然不是NAT映射本身的丢失；但是，在没有通过新映射的注册请求的情况下，归属代理将继续向与旧映射相关联的NAT端口发送通信量。
If the mobile node does not get a reply to its UDP encapsulated ICMP Echo Request even after a number of retransmissions, and is still connected to the same router that was used to establish the current mobility binding, the mobile node SHOULD re-register with the home agent by sending an Registration Request. This lets the HA know about the new NAT mapping and restores connectivity between mobile node and home agent.
如果移动节点即使在多次重传之后也没有收到对其UDP封装ICMP回显请求的回复，并且仍然连接到用于建立当前移动绑定的同一路由器，则移动节点应通过发送注册请求向归属代理重新注册。这让HA知道新的NAT映射，并恢复移动节点和归属代理之间的连接。
Having established a new mobility binding, the mobile node MAY use a shorter keepalive interval than before the NAT mapping was lost; in particular, the mobile node MAY deviate from the keepalive interval assigned by the home agent. If the binding loss continues to occur, the mobile node may shorten the keepalive interval each time it re-registers, in order to end up with a keepalive interval that is sufficient to keep the NAT mapping alive. The strategy used to arrive at a keepalive interval when a NAT mapping is lost is implementation dependent. However, the mobile node MUST NOT use a keepalive less than 10 seconds.
在建立了新的移动性绑定之后，移动节点可以使用比NAT映射丢失之前更短的保持间隔；具体地，移动节点可以偏离由归属代理分配的保持间隔。如果绑定丢失继续发生，则移动节点可以在每次重新注册时缩短keepalive间隔，以便以足以保持NAT映射活动的keepalive间隔结束。当NAT映射丢失时，用于达到保持间隔的策略取决于实现。但是，移动节点不能使用少于10秒的keepalive。
Note that the above discussion only applies when the mobile node is re-registering through the same router, and thus presumably through the same NAT device that lost a NAT mapping earlier. If the MN moves and still finds itself behind a NAT, it SHOULD return to its original keepalive interval (the default value, or as assigned by the home agent) and it SHOULD NOT do any keepalive interval compensation unless it discovers a loss of NAT mapping in the new environment.
注意，上述讨论仅适用于移动节点通过同一路由器重新注册的情况，因此可能是通过先前丢失NAT映射的同一NAT设备。如果MN移动后仍然发现自己在NAT后面，它应该返回到其原始的keepalive interval（默认值，或由归属代理指定的值），并且不应该执行任何keepalive interval补偿，除非它在新环境中发现NAT映射丢失。
The home agent MUST NOT attempt to detect or compensate for NAT binding loss by dynamically changing the keepalive interval assigned in the Registration Reply; the home agent does not have enough information to do this reliably and should thus not do it at all. The mobile node is in a much better position to determine when a NAT mapping has actually been lost. Note also that a MN is allowed to let a NAT mapping expire if the MN no longer needs connectivity.
归属代理不得试图通过动态更改注册回复中分配的保持间隔来检测或补偿NAT绑定丢失；归属代理没有足够的信息来可靠地执行此操作，因此根本不应该执行此操作。移动节点可以更好地确定NAT映射何时实际丢失。还请注意，如果MN不再需要连接，则允许MN让NAT映射过期。
The discussion above does only in a limited sense apply to a foreign agent which is situated behind a NAT and using MIP UDP tunnelling. In this case, it is a matter of permanently configuring the FA to use a keepalive interval which is lower than the NAT mapping lifetime, rather than trying to dynamically adapt to the binding lifetimes of different NATs.
上述讨论仅在有限的意义上适用于位于NAT后面并使用MIP UDP隧道的外部代理。在这种情况下，需要将FA永久配置为使用低于NAT映射生存期的keepalive间隔，而不是尝试动态地适应不同NAT的绑定生存期。
This section summarizes the protocol details which have been necessary in order to handle and support the case when a mobile node registers with a co-located address through a foreign agent, due to the FA advertisements having the 'R' bit set. It gives background information, but lists no new requirements.
本节总结了必要的协议细节，以便处理和支持移动节点通过外部代理向同一地址注册的情况，因为FA广告设置了“R”位。它提供了背景信息，但没有列出新的要求。
When a mobile registers a co-located care-of address through an FA, the registration request which reaches the HA will have a different care-of address in the registration request compared to the source address in the registration request IP-header. If the registration request also contains a UDP Tunnel Request Extension, the HA will erroneously set up a UDP tunnel, which will go to the FA instead of the MN. For this reason, as mentioned in Section 4.4, the mobile node must not include a UDP Tunnel Request Extension in the registration if it is registering a co-located address through an FA which does not have the 'U' bit set in its advertisements.
当移动设备通过FA注册一个共址转交地址时，到达HA的注册请求在注册请求中的转交地址将与注册请求IP报头中的源地址不同。如果注册请求还包含UDP隧道请求扩展，HA将错误地设置UDP隧道，该隧道将转到FA而不是MN。因此，如第4.4节所述，如果移动节点通过在其广告中未设置“U”位的FA注册同一地址，则移动节点不得在注册中包括UDP隧道请求扩展。
In order to still be able to use MIP UDP tunnelling in this case, foreign agents which are situated behind a NAT are encouraged to send advertisements which have the 'U' bit set, as described in Section 3.4.
为了在这种情况下仍然能够使用MIP UDP隧道，鼓励位于NAT后面的外国代理发送设置了“U”位的广告，如第3.4节所述。
If the FA advertisement has the 'U' bit set, indicating that it is behind a NAT, and also the 'R' bit set, and the mobile node wishes to use a co-located care-of address, it MUST set the 'R' flag in the UDP Tunnel Request Extension, in order to inform the HA of the situation so that it may act appropriately, as described in Section 4.4.
如果FA广告具有“U”位集，指示其位于NAT后面，并且具有“R”位集，并且移动节点希望使用同一位置的转交地址，则它必须在UDP隧道请求扩展中设置“R”标志，以便通知HA该情况，以便它可以适当地采取行动，如第4.4节所述。
Because the UDP tunnel is now taking another path than the registration requests, the home agent, when handling registrations of this type, must wait till the arrival of the first keepalive packet before it can set up the tunnel to the correct address and port. To reduce the possibility of tunnel hijacking by sending a keepalive with a phony source address, it is required that only the port of the keepalive packet may be different from that of the registration request; the source address must be the same. This means that if the FA and MN are communicating with the HA through different NATs, the connection will fail.
由于UDP隧道现在采用的是注册请求以外的另一条路径，因此在处理此类注册时，归属代理必须等到第一个keepalive数据包到达后，才能将隧道设置为正确的地址和端口。为了通过发送带有虚假源地址的keepalive来减少隧道劫持的可能性，要求只有keepalive数据包的端口可能与注册请求的端口不同；源地址必须相同。这意味着，如果FA和MN通过不同的NAT与HA通信，则连接将失败。
In providing a mobile node with a mechanism for NAT traversal of Mobile IP traffic, we expand the address space where a mobile node may function and acquire care-of addresses. With this comes a new
在为移动节点提供移动IP流量的NAT遍历机制时，我们扩展了移动节点可以在其中工作和获取转交地址的地址空间。随之而来的是一场新的战争
problem of movement detection and address aliasing. We here have a case which may not occur frequently, but is mentioned for completeness:
移动检测和地址混叠问题。我们这里有一个可能不经常发生的案例，但为了完整性，我们提到了：
Since private networks use overlapping address spaces, they may be mistaken for one another in some situations; this is referred to as private address aliasing in this document. For this reason, it may be necessary for mobile nodes implementing this specification to monitor the link layer address(es) of the gateway(s) used for sending packets. A change in the link layer address indicates probable movement to a new network, even if the IP address remains reachable using the new link layer address.
由于专用网络使用重叠的地址空间，在某些情况下，它们可能会相互误解；在本文档中，这称为专用地址别名。因此，实现该规范的移动节点可能需要监视用于发送分组的网关的链路层地址。链路层地址的更改表示可能移动到新网络，即使使用新的链路层地址仍然可以访问IP地址。
For instance, a mobile node may obtain the co-located care-of address 10.0.0.1, netmask 255.0.0.0, and gateway 10.255.255.254 using DHCP from network #1. It then moves to network #2, which uses an identical addressing scheme. The only difference for the mobile node is the gateway's link layer address. The mobile node should store the link layer address it initially obtains for the gateway (using ARP, for instance). The mobile node may then detect changes in the link layer address in successive ARP exchanges as part of its ordinary movement detection mechanism.
例如，移动节点可以使用DHCP从网络#1获得共同定位的转交地址10.0.0.1、网络掩码255.0.0.0和网关10.255.255.254。然后移动到网络2，它使用相同的寻址方案。移动节点的唯一区别是网关的链路层地址。移动节点应该存储它最初为网关获得的链路层地址（例如，使用ARP）。然后，作为其普通移动检测机制的一部分，移动节点可以在连续的ARP交换中检测链路层地址的变化。
In rare cases the mobile nodes may not be able to monitor the link layer address of the gateway(s) it is using, and may thus confuse one point of attachment with another. This specification does not explicitly address this issue. The potential traffic blackout caused by this situation may be limited by ensuring that the mobility binding lifetime is short enough; the re-registration caused by expiration of the mobility binding fixes the problem (see Section 5.2).
在极少数情况下，移动节点可能无法监视其正在使用的网关的链路层地址，因此可能会将一个连接点与另一个连接点混淆。本规范未明确解决此问题。通过确保移动性绑定寿命足够短，可以限制由这种情况引起的潜在通信中断；由于移动绑定过期而导致的重新注册修复了该问题（请参见第5.2节）。
When responding to a registration request with a registration reply, the home agent is allowed to decrease the lifetime indicated in the registration request, as covered in RFC 3344 [10]. When using UDP tunnelling, there are some cases where a short lifetime is beneficial.
当使用注册回复响应注册请求时，允许归属代理减少注册请求中指示的生存期，如RFC 3344[10]所述。当使用UDP隧道时，在某些情况下，短生命周期是有益的。
First, if the NAT mapping maintained by the NAT device is dropped, a connection blackout will arise. New packets sent by the mobile node (or the foreign agent) will establish a new NAT mapping, which the home agent will not recognize until a new mobility binding is established by a new registration request.
首先，如果NAT设备维护的NAT映射被丢弃，将出现连接中断。由移动节点（或外部代理）发送的新分组将建立新的NAT映射，在新的注册请求建立新的移动性绑定之前，归属代理将不会识别新的NAT映射。
A second case where a short lifetime is useful is related to the aliasing of private network addresses. In case the mobile node is
第二种情况是短生命周期很有用，这与专用网络地址的别名有关。如果移动节点是
not able to detect mobility and ends up behind a new NAT device (as described in Section 5.1), a short lifetime will ensure that the traffic blackout will not be exceedingly long, and is terminated by a re-registration.
无法检测到移动性，并最终落在新NAT设备后面（如第5.1节所述），短的使用寿命将确保通信中断不会过长，并通过重新注册终止。
The definition of "short lifetime" in this context is dependent on the requirements of the usage scenario. Suggested maximum lifetime returned by the home agent is 60 seconds, but in case the abovementioned scenarios are not considered a problem, longer lifetimes may of course be used.
在此上下文中，“短生命周期”的定义取决于使用场景的需求。归属代理返回的建议最大生存期为60秒，但如果上述情况不被视为问题，则当然可以使用更长的生存期。
The ordinary Mobile IP security mechanisms are also used with the NAT traversal mechanism described in this document. However, there is one noticeable change: the NAT traversal mechanism requires that the HA trust unauthenticated address (and port) fields possibly modified by NATs.
普通移动IP安全机制也与本文档中描述的NAT遍历机制一起使用。然而，有一个明显的变化：NAT遍历机制要求HA信任可能被NAT修改的未经验证的地址（和端口）字段。
Relying on unauthenticated address information when forming or updating a mobility binding leads to several redirection attack vulnerabilities. In essence, an attacker may do what NATs do, i.e., modify addresses and ports and thus cause traffic to be redirected to a chosen address. The same vulnerabilities apply to both MN-HA and FA-HA NAT traversal.
在形成或更新移动绑定时依赖未经验证的地址信息会导致多个重定向攻击漏洞。本质上，攻击者可能会执行NAT所做的操作，即修改地址和端口，从而导致流量重定向到所选地址。同样的漏洞也适用于MN-HA和FA-HA NAT穿越。
In more detail: without a NAT, the care-of address in the registration request will be directly used by the HA to send traffic back to the MN (or the FA), and the care-of address is protected by the MN-HA (or FA-HA) authentication extension. When communicating across a NAT, the effective care-of address from the HA point of view is that of the NAT, which is not protected by any authentication extension, but inferred from the apparent IP source address of received packets. This means that by using the mobile IP registration extensions described in this document to enable traversal of NATs, one is opening oneself up to having the care-of address of a MN (or a FA) maliciously changed by an attacker.
更详细地说：如果没有NAT，HA将直接使用注册请求中的转交地址将流量发送回MN（或FA），并且转交地址受MN-HA（或FA-HA）身份验证扩展的保护。当通过NAT进行通信时，从HA的角度来看，有效的转交地址是NAT的转交地址，NAT不受任何认证扩展的保护，而是从接收到的数据包的明显IP源地址推断出来的。这意味着，通过使用本文档中描述的移动IP注册扩展来实现NAT的遍历，攻击者可以恶意更改MN（或FA）的托管地址。
Some, but not all, of the attacks could be alleviated to some extent by using a simple routability check. However, this document does not specify such a mechanism for simplicity reasons and because the mechanism would not protect against all redirection attacks. To limit the duration of such redirection attacks, it is RECOMMENDED to use a conservative (that is, short) mobility binding lifetime when using the NAT traversal mechanism specified in this document.
通过使用简单的可路由性检查，可以在一定程度上缓解部分（但不是全部）攻击。但是，出于简单的原因，并且由于该机制无法防止所有重定向攻击，因此本文档未指定此类机制。为了限制此类重定向攻击的持续时间，建议在使用本文档中指定的NAT遍历机制时使用保守的（即短的）移动绑定生存期。
The known security issues are described in the sections that follow.
以下各节将介绍已知的安全问题。
An attacker on the route between the mobile node (or foreign agent) and the home agent may redirect mobility bindings to a desired address simply by modifying the IP and UDP headers of the Registration Request message. Having modified the binding, the attacker no longer needs to listen to (or manipulate) the traffic. The redirection is in force until the mobility binding expires or the mobile node re-registers.
移动节点（或外部代理）和归属代理之间路由上的攻击者只需修改注册请求消息的IP和UDP头，即可将移动绑定重定向到所需地址。修改绑定后，攻击者不再需要监听（或操纵）流量。重定向一直有效，直到移动绑定过期或移动节点重新注册。
This vulnerability may be used by an attacker to read traffic destined to a mobile node, and to send traffic impersonating the mobile node. The vulnerability may also be used to redirect traffic to a victim host in order to cause denial-of-service on the victim.
攻击者可利用此漏洞读取发送到移动节点的流量，并发送模拟移动节点的流量。该漏洞还可用于将流量重定向到受害主机，以便在受害主机上造成拒绝服务。
The only defense against this vulnerability is to have a short time between re-registrations, which limits the duration of the redirection attack after the attacker has stopped modifying registration messages.
针对此漏洞的唯一防御措施是在重新注册之间有一段短时间，这限制了攻击者停止修改注册消息后重定向攻击的持续时间。
When registering through an FA using a co-located care-of address, another redirection vulnerability opens up. Having exchanged Registration Request/Reply messages with the HA through the FA, the MN is expected to send the first keepalive message to the HA, thus finalizing the mobility binding (the binding will remain in a "half bound" state until the keepalive is received).
当使用同一位置的转交地址通过FA注册时，会打开另一个重定向漏洞。在通过FA与HA交换注册请求/回复消息后，MN将向HA发送第一条keepalive消息，从而完成移动绑定（在收到keepalive之前，绑定将保持“半绑定”状态）。
Having observed a Registration Request/Reply exchange, an attacker may send a bogus keepalive message assuming that the mobility binding is in the "half bound" state. This opens up a similar redirection attack as discussed in Section 6.1.1. Note, however, that the attacker does not need to be able to modify packets in flight; simply being able to observe the Registration Request/Reply message exchange is sufficient to mount the attack.
在观察到注册请求/应答交换后，攻击者可能会发送虚假的keepalive消息，假设移动绑定处于“半绑定”状态。这会引发类似的重定向攻击，如第6.1.1节所述。但是，请注意，攻击者不需要能够在飞行中修改数据包；只要能够观察注册请求/回复消息交换就足以发起攻击。
With this in mind, the home agent MUST NOT accept a keepalive message from a different source IP address than where the Registration Request came from, as specified in Section 4.6. This requirement limits the extent of the attack to redirecting the traffic to a bogus UDP port, while the IP address must remain the same as in the initial Registration Request.
考虑到这一点，如第4.6节所述，归属代理不得接受来自不同于注册请求来源的源IP地址的keepalive消息。此要求将攻击范围限制为将流量重定向到伪造的UDP端口，而IP地址必须与初始注册请求中的地址相同。
The only defenses against this vulnerability are: (1) to have a short time between re-registrations, which limits the duration of the redirection attack after the attacker has stopped sending bogus keepalive messages, and (2) to minimize the time the binding is in a "half bound" state by having the mobile node send the first keepalive message immediately after receiving an affirmative registration reply.
针对此漏洞的唯一防御措施是：（1）在重新注册之间有一段短时间，这限制了攻击者停止发送虚假keepalive消息后重定向攻击的持续时间；（2）将绑定处于“半绑定”状态的时间减至最少通过让移动节点在接收到肯定的注册回复后立即发送第一个keepalive消息来进行状态。
If the intermediate network is considered insecure, it is recommended that IPsec be used to protect user data traffic. However, IPsec does not protect against the redirection attacks described previously, other than to protect confidentiality of hijacked user data traffic.
如果认为中间网络不安全，建议使用IPsec保护用户数据流量。但是，IPsec除了保护被劫持的用户数据通信的机密性之外，不能防止前面描述的重定向攻击。
The NAT traversal mechanism described in this document allows all IPsec-related traffic to go through NATs without any modifications to IPsec. In addition, the IPsec security associations do not need to be re-established when the mobile node moves.
本文档中描述的NAT遍历机制允许所有与IPsec相关的流量通过NAT，而无需对IPsec进行任何修改。此外，当移动节点移动时，不需要重新建立IPsec安全关联。
This document does not specify a general firewall traversal mechanism. However, the mechanism makes it possible to use only a single address and a port for all MN-HA (or FA-HA) communication. Furthermore, using the same port for the MIP UDP tunnelled traffic as for control messages makes it quite probable that if a MIP registration can reach the home agent, MIP tunnelling and reverse tunnelling using the described mechanism will also work.
本文档未指定通用防火墙遍历机制。然而，该机制使所有MN-HA（或FA-HA）通信仅使用单个地址和端口成为可能。此外，对MIP UDP隧道通信量使用与控制消息相同的端口使得如果MIP注册可以到达归属代理，则使用所述机制的MIP隧道和反向隧道也将工作。
The mechanism described in this document is not an "UNilateral Self-Address Fixing" (UNSAF) mechanism. Although the mobile node makes no attempt to determine or use the NAT translated address, the mobile node through the registration process does attempt to keep the NAT mapping alive through refresh messages. This section attempts to address issues that may be raised through this usage through the framework of the unsaf considerations IAB document [13].
本文件中所述的机制不是“单边自定址”（UNSAF）机制。尽管移动节点不尝试确定或使用NAT转换的地址，但移动节点通过注册过程确实尝试通过刷新消息保持NAT映射活动。本节试图通过unsaf考虑事项IAB文件[13]的框架，解决这种用法可能引起的问题。
1. Precise definition. This proposal extends the Mobile IP v4 registration process to work across intervening NATs. The Home Agent detects the presence of the NAT by examining the source address in the packet header and comparing it with the address contained in the registration message.
1. 精确的定义。该提案将移动IP v4注册过程扩展到跨介入NAT的工作。归属代理通过检查分组报头中的源地址并将其与注册消息中包含的地址进行比较来检测NAT的存在。
The NAT address and port detected by the home agent are not exported or communicated to any other node anywhere.
归属代理检测到的NAT地址和端口不会导出或传送到任何其他节点。
2. Exit strategy. This mechanism will go out of use as IPv6 and Mobile IP v6 is deployed, obviating the need for MIPv4 NAT traversal.
2. 退出战略。随着IPv6和移动IP v6的部署，此机制将不再使用，从而无需进行MIPv4 NAT遍历。
It can also be noted that this mechanism makes no changes to the base MIPv4 protocol which makes it dependent on the presence of NATs or the current extensions - i.e., no additional protocol changes would be needed if NATs were to go away.
还可以注意到，该机制不会对基本MIPv4协议进行任何更改，这使其依赖于NAT的存在或当前扩展，即，如果NAT消失，则不需要对其他协议进行更改。
3. Issues making systems more brittle. The specific issue which is relevant here is that the effective care-of address (being the source address in the IP header received by the HA) is not protected by the Mobile IP authentication extension, and therefore may be spoofed. This is discussed in some detail in Section 6, Security Considerations.
3. 使系统更脆弱的问题。此处相关的具体问题是，有效转交地址（由HA接收的IP报头中的源地址）不受移动IP认证扩展的保护，因此可能被欺骗。第6节“安全注意事项”对此进行了详细讨论。
4. Requirements for longer term solutions. The trivial long term solution is a transition to an environment where NATs are not required. The most obvious such environment would be an IPv6 based internet.
4. 长期解决方案的要求。简单的长期解决方案是过渡到不需要NAT的环境。最明显的环境是基于IPv6的互联网。
In the presence of NATs, an improved solution would require
在存在NAT的情况下，需要改进的解决方案
* the ability to discover the translations done by each NAT along the route
* 能够发现路由上每个NAT所做的翻译
* the ability to validate the authority of each NAT to do those translations
* 验证每个NAT进行这些翻译的权限的能力
* communicating as part of the signed registration request the address of the NAT closest to the HA, for use as the effective care-of address from the viewpoint of the HA.
* 作为签名注册请求的一部分，通信最接近HA的NAT地址，以便从HA的角度用作有效的转交地址。
* configuration of all intermediate NATs to accept only packets from the neighbour NATs.
* 将所有中间NAT配置为仅接受来自相邻NAT的数据包。
5. Impact on existing, deployed NATs. One precursor of the mechanism described here has been used successfully across deployed NATs in Sweden, Germany, England, Japan and the USA, without necessitating neither adjustments of the NATs in question, nor adjustment of any protocol parameters. At the time of writing, little experience exist with the exact implementation proposed in this document, but effort has been put into making this mechanism even more robust and adaptive than its precursors.
5. 对现有已部署NAT的影响。本文所述机制的一个前身已在瑞典、德国、英国、日本和美国的已部署NAT中成功使用，无需调整所述NAT，也无需调整任何协议参数。在编写本报告时，在本文件中提出的具体实施方面几乎没有经验，但已作出努力，使这一机制比其前身更加稳健和适应性更强。
With respect to the base Mobile IP specification, the impact of this document is that an increased frequency of registration requests is recommended from a security perspective when the NAT traversal mechanism is used.
关于基本移动IP规范，本文档的影响是，当使用NAT遍历机制时，从安全角度来看，建议增加注册请求的频率。
The numbers for the extensions defined in this document have been taken from the numbering space defined for Mobile IP messages, registration extensions and error codes defined in RFC 3344 [10]. This document proposes one new message, two new extensions and a new error code that require type numbers and an error code value that have been assigned by IANA. The two new extensions also introduce two new sub-type numbering spaces to be managed by IANA.
本文件中定义的扩展名编号取自RFC 3344[10]中定义的移动IP消息、注册扩展名和错误代码的编号空间。本文档提出了一条新消息、两个新扩展名和一个新错误代码，它们需要IANA分配的类型号和错误代码值。这两个新的扩展还引入了两个新的子类型编号空间，由IANA管理。
Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request Extension. The type number for this extension is 144. This extension introduces a new sub-type numbering space where the value 0 has been assigned to this extension. Approval of new Tunnel Request Extension sub-type numbers is subject to Expert Review, and a specification is required [7].
第3.1节定义了一个新的移动IP扩展，即UDP隧道请求扩展。此扩展的类型号为144。此扩展引入了一个新的子类型编号空间，其中值0已分配给此扩展。新隧道请求扩展子类型编号的批准需经专家审查，且需要规范[7]。
Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply Extension. The type value for this extension is 44. This extension introduces a new sub-type numbering space where the value 0 has been assigned to this extension. Approval of new Tunnel Reply Extension sub-type numbers is subject to Expert Review, and a specification is required [7].
第3.2节定义了一个新的移动IP扩展，即UDP隧道应答扩展。此扩展的类型值为44。此扩展引入了一个新的子类型编号空间，其中值0已分配给此扩展。新隧道应答扩展子类型编号的批准需经专家审查，且需要规范[7]。
Section 3.3 defines a new Mobile IP message, the Tunnel Data message. The type value for this message is 4.
第3.3节定义了一种新的移动IP消息，即隧道数据消息。此消息的类型值为4。
Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL: "Requested UDP tunnel encapsulation unavailable", from the numbering space for values defined for use with the Code field of Mobile IP Registration Reply Messages. Code number 142 has been assigned from the subset "Error Codes from the Home Agent".
第3.5节定义了一个新的错误代码，error_HA_UDP_ENCAP_UNAVAIL：“请求的UDP隧道封装不可用”，该代码来自编号空间，用于定义的值，用于移动IP注册回复消息的代码字段。代码编号142已从子集“来自归属代理的错误代码”中分配。
The values for the Next Header field in the MIP Tunnel Data Message (Section 3.3) shall be the same as those used for the Protocol field of the IP header [2], and requires no new number assignment.
MIP隧道数据消息（第3.3节）中下一个报头字段的值应与IP报头[2]的协议字段的值相同，并且不需要新的号码分配。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights (www.ietf.org/ipr.html).
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利声明列表（www.ietf.org/ipr.html）。
Much of the text in Section 4.2 has been taken almost verbatim from RFC 2003, IP Encapsulation within IP [4].
第4.2节中的大部分内容几乎一字不差地取自RFC 2003，IP内的IP封装[4]。
Adding support for the FA case was suggested by George Tsirtsis and Frode B. Nilsen. Roy Jose pointed out a problem with binding updates, and Frode, Roy and George pointed out that there are cases where triangular routes may work, and suggested that reverse tunnelling need not be mandatory. Roy and Qiang Zhang drew attention to a number of sections which needed to be corrected or stated more clearly.
乔治·齐尔茨（George Tsirtsis）和弗罗德·尼尔森（Frode B.Nilsen）建议为足总案增加支持。Roy Jose指出绑定更新存在问题，Frode、Roy和George指出，在某些情况下，三角形路线可能会起作用，并建议不必强制进行反向隧道挖掘。Roy和Liang Zhang提请注意一些需要更正或更清楚说明的章节。
Phil Roberts helped remove a number of rough edges. Farid Adrangi pointed out the DoS issue now covered in Security Considerations (Section 6). Francis Dupont's helpful comments made us extend the Security Considerations section to make it more comprehensive and clear. Milind Kulkarni and Madhavi Chandra pointed out the required match between the FA source and care-of addresses when the mechanism is used by an FA, and also contributed a number of clarifications to the text.
菲尔·罗伯茨帮助去除了一些粗糙的边缘。Farid Adrangi指出DoS问题现在已经包含在安全考虑中（第6节）。弗朗西斯·杜邦（Francis Dupont）的有益评论使我们扩展了安全考虑部分，使其更加全面和清晰。Milind Kulkarni和Madhavi Chandra指出了FA使用该机制时FA来源和转交地址之间的必要匹配，并对文本进行了一些澄清。
Thanks also to our co-workers, Ilkka Pietikainen, Antti Nuopponen and Timo Aalto at Netseal and Hans Sjostrand, Fredrik Johansson and Erik Liden at ipUnplugged. They have read and re-read the text, and contributed many valuable corrections and insights.
还要感谢我们的同事，Netseal的Ilkka Pietikainen、Antti Nuopponen和Timo Aalto，以及IPE的Hans Sjostrand、Fredrik Johansson和Erik Liden。他们反复阅读了课文，做出了许多有价值的更正和见解。
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[1] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[3] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[3] Hanks，S.，Li，T.，Farinaci，D.和P.Traina，“通用路由封装（GRE）”，RFC 17011994年10月。
[4] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[4] Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[5] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[5] Perkins，C.，“IP内的最小封装”，RFC 2004，1996年10月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[8] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[8] Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[9] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[9] 黑山G.“移动IP反向隧道，修订版”，RFC 3024，2001年1月。
[10] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[10] Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[11] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[11] Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[12] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[12] Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[13] Daigle, L., Editor, and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF)", RFC 3424, November 2002.
[13] Daigle，L.，编辑和IAB，“IAB对单边自定址（UNSAF）的考虑”，RFC 34242002年11月。
Henrik Levkowetz ipUnplugged AB Arenavagen 23 Stockholm S-121 28 SWEDEN
Henrik Levkowetz AB Arenavagen 23斯德哥尔摩S-121 28瑞典
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
Sami Vaarala Netseal Niittykatu 6 Espoo 02201 FINLAND
Sami Vaarala Netseal Niittykatu 6 Espoo 02201芬兰
Phone: +358 9 435 310
EMail: sami.vaarala@iki.fi
Phone: +358 9 435 310
EMail: sami.vaarala@iki.fi
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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编辑功能的资金目前由互联网协会提供。