Mobile IP穿越NAT
声明：本文章所述的方法描述均来自RFC，再加上自己对此的理解。如果有什么和原文档有冲突或者理解不准确的地方，请以相关权威文档为主。希望不要误导初学者。
RFC术语：
家乡代理HA：是位于移动节点家乡链路的路由器。当移动节点离开家乡网络时，它负责把发往移动节点的分组通过隧道发送给移动节点，并维护移动节点当前的位置信息。
外地代理FA：是位于移动节点当前链路（一般不在家乡链路）的路由器，为注册的移动节点提供路由服务——接受来自家乡代理的分组，进行拆封后，发给移动节点；转发移动节点的数据包（直接发给通信对端，或者发往家乡代理）。
外地代理转交地址（FA Care-of
Address）：从移动代理的代理通告获得，通常为移动代理的一个IP地址，是隧道的终点，可遇其他漫游的移动节点共享。
配置转交地址（Co-located
Care-of Address）：通过DHCP动态分配的地址，也是隧道的终点，不可遇其他漫游的移动节点共享。
前向隧道(Forward Tunnel)：分组到移动节点的隧道。始于家乡代理，止于移动节点的转交地址。（包括外地转交和配置转交）
反向隧道(Reverse Tunnel)：始于移动节点的转交地址，止于家乡代理。
移动IPv4的基本操作过程：
1.
移动代理（包括家乡代理和外地代理）通过代理通告消息告诉移动节点移动代理的存在，移动节点也可以发送代理请求获得代理通告消息。移动节点通过代理通告消息判断自己是否漫游到外地；
2.
如果漫游到外地，移动节点会获得外地链路的一个转交地址（或者是外地转交，或者是配置转交）；
3.
移动节点与家乡代理进行注册请求（注册转交地址），家乡代理注册应答；
4.
家乡代理截获发往移动节点的数据分组，封装后通过隧道发往移动节点注册转交地址；
5.
隧道的输出端——转交地址，将收到的封装报文解封，交给移动节点；
6.
移动节点发送报文时，可以直接通过外地代理发送到通信对端（产生三角路由）；也可以通过外地代理封装通过反向隧道发送到家乡代理，由家乡代理解封后发给通信对端（反向隧道）。
问题：
移动IP的家乡代理到移动节点或者外地代理的通信是使用IP-IN-IP隧道。IP节点和在NAT后的对端通信时，只能使用NAT的公网地址。IP-IN-IP隧道一般不会包含足够的信息来使得公网地址和移动节点的转交地址或者在NAT后的外地代理有唯一的映射关系；特别是没有TCP/UDP端口供NAT使用。所以如果是IP-IN-IP隧道封装移动IP包，NAT是无法穿越的。
以下为三种不同的NAT情况：
1.
移动节点的配置转交地址在NAT后，没有外地代理；
2.
移动节点和外地代理都在NAT后面；
3.
移动节点和外地代理都在NAT后面，使用配置转交地址；
RFC3519假设移动节点和家乡代理在UDP434通信。移动IP定义了一些新的控制消息（使用UDP434），对现有的ICMP路由通告和请求消息扩充。
我们所需要的是能够让NAT设备建立惟一映射的数据可选的隧道机制和支持这种隧道的注册机制。
UDP隧道的建立过程：
1． 在Mobile IP的UDP隧道中，移动节点使用普通情况下的移动节点的注册请求的扩展项，来表明Mobile IP的UDP隧道可用。
2． 家乡代理也会响应一个注册回复扩展项来表示接受Mobile IP的UDP隧道。
3． 在家乡代理接受之后，Mobile IP的UDP隧道就可以在前向和反向隧道使用了。
注意：移动节点发送的UDP隧道包使用和注册请求消息同样的端口号。源端口要能够在所有的隧道包和再注册中保持不变。目的端口就是434。
（UDP tunnelled packets sent by the home agent uses the same ports,
but in reverse.）
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
|-----------------///--------------->>+
. . +
. . .
. . .
UDP隧道请求扩展（对应于一般的注册请求的扩展）：表明发送端UDP隧道可用性，以及在UDP隧道的特殊的封装格式。只适用于配置转交地址，不适用于注册到外地代理转交地址。请求的扩展必须在Mobile-Home认证扩展的前面。如果移动节点发出了此请求扩展，但是没有收到相应的响应扩展，那就表明家乡代理不支持这种扩展，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 | Reserved 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|R| Reserved 2| Encapsulation | Reserved 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
l Type：144；
l Length：6；扩展的长度，不包括类型和长度字节。
l Sub-Type：0；
l Reserved 1：保留以后用；发送端置0；接收端忽略；
l F：强制UDP隧道建立；
l R：由外地代理通告置位。配置转交地址置1，外地转交地址置0；
l Reserved 2：保留以后用；发送端置0；接收端忽略；
l Encapsulation：表明封装数据的隧道类型；4表示IP-IN-IP，47表示GRE，55表示最小封装；和IP头的协议值一样的含义；
l Reserved 3：保留以后用；发送端置0；接收端忽略；
UDP隧道响应扩展（对应于一般注册应答的扩展）：UDP隧道请求的回应，表明家乡代理是否使用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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
l Type：44；
l Length：6；扩展的长度，不包括类型和长度字节。
l Sub-Type：0；
l Reply Code：表明家乡代理是否同意使用UDP隧道；
l F：强制UDP隧道建立；
l Reserved：保留以后用；发送端置0；接收端忽略；
l Keepalive Interval ：指定Keepalive包的发送间隔；
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 | Next Header | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
l Type：4；
l Next Header：表明隧道数据的类型，和IP头的协议值一样的含义；和UDP隧道请求扩展中的Encapsulation字段保持一致。
另外，在代理公告（移动代理公告跟在ICMP路由公告字段之后，表明这个ICMP路由公告消息也是移动代理发送的一个代理公告）中，也有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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|r|T|U| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
其中U就表示对UDP隧道的支持。
UDP隧道封装示意图：
Mobile IP的注册请求和响应始终是UDP包的格式(移动IP的注册请求和应答比较特殊，因为他们本身就是UDP包)，即使UDP隧道强制，也不应该被IP-in-UDP隧道封装。UDP隧道只是用来传输数据包的。当移动节点注册完成之后，在和对端通信时，UDP源端口号须使用最近注册请求的端口号。
下图只是IP in UDP，这是默认的封装形式，还有GRE in UDP，Minimal encapsulation in UDP形式。
+---------------------------+
| |
| Outer IP Header |
+---------------------------+
| |
| UDP Header |
+---------------------------+
| MIP Tunnel Data |
| Message Header |
+---------------------------+ +---------------------------+
| | | |
| IP Header | | IP Header |
+---------------------------+ ====> +---------------------------+
| | | |
| IP Payload | | IP Payload |
| | | |
| | | |
+---------------------------+ +---------------------------+
l 隧道终点（源/目的）标识：外部IP地址（源/目的）+UDP端口号（源/目的）；（源UDP端口可能会被NAT