Request for Comments: 3519 ipUnplugged
Category: Standards Track S. Vaarala
Netseal
April 2003
Mobile IP Traversal of Network Address Translation (NAT) Devices
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
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.
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
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
1. Introduction
1.1 Terminology
The Mobile IP related terminology described in RFC3344 [10] is used
in this document. In addition, the following terms are used:
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.
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." -- RFC2663 [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." -- RFC2663 [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.
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, RFC2119 [6].
1.2 Problem description
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.
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.
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.
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.
This mechanism will address 3 different scenarios:
- A mobile node with co-located address behind a NAT; no FA
- A mobile node registered with an FA where both the mobile node and
the FA are behind the same 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
1.3 Assumptions
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.
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
"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.
For a more extensive discussion of the problems with disparate
address spaces, and how they may be solved, see RFC3024 [9].
The reverse tunnels considered here are symmetric, that is, they use
the same configuration (encapsulation method, IP address endpoints)
as the forward tunnel.
2. NAT Traversal Overview
This section gives a brief overview of the MIP UDP tunnelling
mechanism which may be used to achieve NAT traversal for Mobile IP.
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.
2.1 Basic Message Sequence
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.
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
|-----------------///--------------->>+
. . +
. . .
. . .
3. New Message Formats
3.1 UDP Tunnel Request Extension
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].
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
Length 6. Length in bytes of this extension, not
including the Type and Length bytes.
Sub-Type 0
Reserved 1 Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
F F (Force) flag. Indicates that the mobile
node wants to force MIP UDP tunnelling to be
established.
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.
Reserved 2 Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
Encapsulation Indicates the type of tunnelled data, using
the same numbering as the IP Header Protocol
Field.
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.1.1 F (Force) Flag
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").
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.
3.1.2 R (Registration through FA Required) flag
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.
3.1.3 Reserved Fields
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.
3.1.4 Encapsulation
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:
4 IP header (IP-in-UDP tunnelling) RFC2003 [4]
47 GRE Header (GRE-in-UDP tunnelling) RFC2784 [8]
55 Minimal IP encapsulation header RFC2004 [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.
3.1.5 Mobile IP Registration Bits
The Mobile IP registration bits S, B, D, M, G and T retain their
meaning as described in RFC3344 [10] and RFC3024 [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.
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.
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).
3.2 UDP Tunnel Reply Extension
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.
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
Length 6. Length in bytes of this extension, not
including the Type and Length bytes.
Sub-Type 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.
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.
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.
Reserved Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
3.2.1 Reply Code
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.
The following response codes are defined for use in the code field of
the UDP Tunnel Reply Extension:
0 Will do tunnelling
64 Tunnelling declined, reason unspecified
3.3 MIP Tunnel Data Message
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.
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
Next Header Indicates the type of tunnelled data, using
the same numbering as the IP Header Protocol
Field.
Reserved Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
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:
4 IP header (IP-in-UDP tunnelling) RFC2003 [4]
47 GRE Header (GRE-in-UDP tunnelling) RFC2784 [8]
55 Minimal IP encapsulation header RFC2004 [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).
3.4 UDP Tunnelling Flag in Agent Advertisements
The only change to the Mobility Agent Advertisement Extension defined
in RFC3344 [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].
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.
3.5 New Registration Reply Codes
One new registration reply code is defined:
ERROR_HA_UDP_ENCAP_UNAVAIL Requested UDP tunnel encapsulation
unavailable
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.
4. Protocol Behaviour
4.1 Relation to standard MIP tunnelling
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 RFC3344 [10] within the context of MIP UDP
tunnelling. The UDP tunnelling version of the classic MIP
encapsulation methods can be summarised as:
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.
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.
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 RFC2004 [5] would be used if the MIP
UDP tunnelling had not been requested.
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.
4.2 Encapsulating IP Headers in 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.
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.
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:
+---------------------------+
| |
| 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 RFC2003 [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.
Minimal Encapsulation and GRE encapsulation is done in an analogous
manner, following RFC2004 [5] for Minimal Encapsulation and RFC2784
[8] for GRE Encapsulation, but using outer IP, UDP and MIP headers in
place of the outer IP header.
All other provisions and requirements of RFC2003 [4] and RFC3024
[9] are in force, except in one respect, as covered in Packet
Fragmentation (Section 4.8).
4.3 Decapsulation
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-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.
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.
GRE encapsulated traffic is processed according to RFC2784 [8] and
RFC1701 [3], with the delivery header consisting of the outer IP,
UDP and MIP headers.
4.4 Mobile Node Considerations
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.
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.
As per Section 3.2 and 3.6.1.3 of RFC3344 [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.
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
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.
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.
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.)
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.
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.
4.5 Foreign Agent Considerations
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.
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.
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
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.
As per Section 3.2 and 3.7.2.2 of RFC3344 [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.
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.
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.
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".
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.
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".
4.6 Home Agent Considerations
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.
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.
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.
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 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.
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
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.
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.
4.6.1 Error Handling
The following actions take place when things go wrong.
The HA does not support the UDP Tunnel Request extension:
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.
(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.)
NAT detected by home agent, but traversal not allowed:
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 not detected, 'F' flag set, but home agent does not allow forced
use of MIP UDP tunnelling:
The home agent SHOULD send a Registration Reply with the Code
field set to 129, "administratively prohibited".
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:
The home agent SHOULD send a Registration Reply with the Code
field set to 134, "poorly formed Request".
UDP Tunnel Request extension sent by the foreign agent (placed after
the MN-HA authentication extension), but 'D' bit is set:
The home agent SHOULD send a Registration Reply with the Code
field set to 134, "poorly formed Request".
Reserved 3 field of UDP Tunnel Request extension is nonzero:
The home agent SHOULD send a Registration Reply with the Code
field set to 134, "poorly formed Request".
Encapsulation type requested in UDP Tunnel Request extension is
unsupported:
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.
4.7 MIP signalling versus tunnelling
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.
As a consequence:
- Mobile IP signalling is never tunnelled.
- When using simultaneous bindings, each binding may have a
different type (i.e., UDP tunnelling bindings may be mixed with
non-UDP tunnelling bindings).
- Tunnelling is only allowed for the duration of the binding
lifetime.
4.8 Packet fragmentation
From RFC3022 [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."
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 RFC2003 [4] recommends doing it before
encapsulation.
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.
For this reason, the home agent SHOULD do packet fragmentation before
it does MIP UDP encapsulation.
4.9 Tunnel Keepalive
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 RFC2663 [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.
This timeout may be assumed to be a couple of minutes, according to
RFC2663 [11], but it is conceivable that shorter timeouts may exist
in some NATs.
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.
The keepalive message sent MUST consist of a properly UDP
encapsulated ICMP echo request directed to the home agent.
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).
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.
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:
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.
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.
4.10 Detecting and compensating for loss of NAT mapping
When a mobile node is using UDP encapsulated ICMP Echo Request/Reply
messages as keepalives, it will have to deal with the possibility
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.
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