Internet Engineering Task Force H. Levkowetz
Internet-Draft ipUnplugged
Expires: May 2, 2002 S. Vaarala
NetSeal
November 2001
Mobile IP NAT/NAPT Traversal using UDP Tunnelling
<draft-ietf-mobileip-nat-traversal-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 2, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). 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.
Levkowetz & Vaarala Expires May 2, 2002 [Page 1]
Internet-Draft NAT Traversal for MIP November 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Problem description . . . . . . . . . . . . . . . . . . . . 4
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 U (Unconditional) Flag . . . . . . . . . . . . . . . . . . . 7
3.1.2 Reserved Fields . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.4 Mobile IP Registration Bits . . . . . . . . . . . . . . . . 8
3.2 UDP Tunnel Reply Extension . . . . . . . . . . . . . . . . . 8
3.3 MIP Tunnel Data Message . . . . . . . . . . . . . . . . . . 9
3.4 New Registration Reply Codes . . . . . . . . . . . . . . . . 10
4. Protocol Behaviour . . . . . . . . . . . . . . . . . . . . . 10
4.1 Relation to standard MIP tunnelling . . . . . . . . . . . . 10
4.2 Encapsulating IP Headers in UDP . . . . . . . . . . . . . . 11
4.3 Decapsulation . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 Mobile Node Considerations . . . . . . . . . . . . . . . . . 13
4.5 Foreign Agent Considerations . . . . . . . . . . . . . . . . 13
4.6 Home Agent Considerations . . . . . . . . . . . . . . . . . 14
4.6.1 Error Handling . . . . . . . . . . . . . . . . . . . . . . . 15
4.7 MIP signalling versus tunnelling . . . . . . . . . . . . . . 16
4.8 Packet fragmentation . . . . . . . . . . . . . . . . . . . . 17
4.9 Tunnel Keepalive . . . . . . . . . . . . . . . . . . . . . . 17
5. Implementation Issues . . . . . . . . . . . . . . . . . . . 18
5.1 Movement Detection and Private Address Aliasing . . . . . . 18
5.2 Mobility Binding Lifetime . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . 19
6.1 Firewall Considerations . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
8. Intellectual property rights . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
Levkowetz & Vaarala Expires May 2, 2002 [Page 2]
Internet-Draft NAT Traversal for MIP November 2001
1. Introduction
1.1 Terminology
The Mobile IP related terminology described in RFC 2002 [5] 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 [9]. 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." --
RFC 2663 [9]
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 [9]
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.
Levkowetz & Vaarala Expires May 2, 2002 [Page 3]
Internet-Draft NAT Traversal for MIP November 2001
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [8].
1.2 Problem description
A basic assumption that Mobile IP [5] makes is that mobile nodes and
foreign agents are uniquely identifiable by a 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. 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 Request will be
able to pass in to the correct recipient. The current Mobile IP
protocol does however not permit a registration where the 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.
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
Levkowetz & Vaarala Expires May 2, 2002 [Page 4]
Internet-Draft NAT Traversal for MIP November 2001
2002 [5] 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 RFC 3024 [12].
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. 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| |
Levkowetz & Vaarala Expires May 2, 2002 [Page 5]
Internet-Draft NAT Traversal for MIP November 2001
| | +
| | || 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 proposed in [13].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Reserved 2 | Encapsulation | Reserved 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (to be assigned by IANA) (skippable)
Length 6. Length in bytes of this extension, not
including the Type and Length bytes.
Sub-Type (to be assigned by IANA)
Levkowetz & Vaarala Expires May 2, 2002 [Page 6]
Internet-Draft NAT Traversal for MIP November 2001
Reserved 1 Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
U U (Unconditional) flag. Indicates that the
mobile node unconditionally wants MIP UDP
tunnelling to be established.
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, any bit not understood MUST be 0 on
receipt.
3.1.1 U (Unconditional) 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. The suggested value for the Registration Reply Code field
in case of failed registration is 129 ("administratively
prohibited").
3.1.2 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 ignored 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.3 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) RFC 2003 [6]
Levkowetz & Vaarala Expires May 2, 2002 [Page 7]
Internet-Draft NAT Traversal for MIP November 2001
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [10]
55 Minimal IP encapsulation header RFC 2004 [7]
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.4 Mobile IP Registration Bits
The Mobile IP registration bits S, B, D, M, G and T retain their
meaning as described in RFC 2002 [5] and RFC 3024 [12] (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 signifies that 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 | Reserved 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved 2 | Keepalive Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (to be assigned by IANA) (non-skippable)
Levkowetz & Vaarala Expires May 2, 2002 [Page 8]
Internet-Draft NAT Traversal for MIP November 2001
Length 6. Length in bytes of this extension, not
including the Type and Length bytes.
Sub-Type (to be assigned by IANA)
Reserved 1 Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
F F (Forced) flag. Indicates that no NAT was
detected, but tunnelling is being forced
anyway because the U bit was set in the
tunnelling request.
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 2 Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
3.3 MIP Tunnel Data Message
This MIP message header serves to differentiate traffic tunnelled
trough 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 (to be assigned by IANA)
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
Levkowetz & Vaarala Expires May 2, 2002 [Page 9]
Internet-Draft NAT Traversal for MIP November 2001
values:
4 IP header (IP-in-UDP tunnelling) RFC 2003 [6]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [10]
55 Minimal IP encapsulation header RFC 2004 [7]
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 New Registration Reply Codes
One new registration reply code is defined:
140 Requested UDP tunnel encapsulation unavailable
This is used 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 RFC 2002 [5] 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
Levkowetz & Vaarala Expires May 2, 2002 [Page 10]
Internet-Draft NAT Traversal for MIP November 2001
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 [7] 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 [7] would
be used if the MIP UDP tunnelling had not been requested.
When the Ecapsulation 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 code 140, "Requested UDP tunnel
encapsulation unavailable". On receipt of this error, the mobile 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 [6], with the exception of the addition of an UDP header [1] and
IP Message header [5] 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 [5] is
inserted before the datagram's existing IP header, as follows:
+---------------------------+
| |
| Outer IP Header |
+---------------------------+
| |
| UDP Header |
Levkowetz & Vaarala Expires May 2, 2002 [Page 11]
Internet-Draft NAT Traversal for MIP November 2001
+---------------------------+
| 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 [6], 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. If need be, other protocol headers such as the IP
Authentication Header [4] may be inserted between the outer IP header
and the UDP header. 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 RFC 2004 [7] for Minimal Encapsulation and RFC 2784
[10] for GRE Encapsulation, but using outer IP, UDP and MIP headers
in place of the outer IP header.
All other provisions and requirements of RFC 2003 [6] and RFC 3024
[12] are in force, except in one respect, as covered in Packet
Fragmentation (Section 4.8).
4.3 Decapsulation
IP-in-UDP encapsulated traffic is processed by the receiver simply by
stripping of 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
Levkowetz & Vaarala Expires May 2, 2002 [Page 12]
Internet-Draft NAT Traversal for MIP November 2001
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 RFC 2784 [10] and
RFC 1701 [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 RFC 2002 [5], 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.
When the mobile node sends MIP UDP tunnelled data, it MUST use the
same UDP source port as was used for the original registration
request.
When the mobile node re-registers without having moved, it MUST take
care to use the same source port as was used for the original
registration of the current mobility binding. (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.)
4.5 Foreign Agent Considerations
The UDP Tunnel Request Extension MAY be used in a Mobile IP
Registration Request forwarded by a foreign agent 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
Levkowetz & Vaarala Expires May 2, 2002 [Page 13]
Internet-Draft NAT Traversal for MIP November 2001
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.
As per Section 3.2 and 3.7.2.2 of RFC 2002 [5], the foreign agent
MUST place this extension 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.
A foreign agent using MIP UDP tunnelling to a home agent because it
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.
4.6 Home Agent Considerations
The purpose of the MIP UDP Tunnel Reply Extension is to indicate that
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 MAY be used in a Mobile IP
Registration Reply from the home agent to the mobile node. It MUST
Levkowetz & Vaarala Expires May 2, 2002 [Page 14]
Internet-Draft NAT Traversal for MIP November 2001
be added to a Mobile IP Registration Reply by the home agent 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
defined here, and the home agent is capable of, and permits MIP UDP
tunnelling, the home agent SHALL respond with a registration reply
containing the UDP Tunnel Reply extension described in Section 3.2.
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 SHALL NOT respond with a
Registration Reply containing a UDP Tunnel Reply (Section 3.2) unless
explicitly requested by the mobile node using the U flag as described
in Section 3.1.
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, 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 respond with
Code 129, "administratively prohibited".
NAT not detected, 'U'-bit set, but home agent does not allow
unconditional traversal:
The home agent SHOULD respond with Code 129, "administratively
Levkowetz & Vaarala Expires May 2, 2002 [Page 15]
Internet-Draft NAT Traversal for MIP November 2001
prohibited".
UDP Tunnel Request extension sent by the mobile node, but 'D' bit in
registration request header not set:
The home agent SHOULD respond with Code 134, "poorly formed
Request".
UDP Tunnel Request extension sent by the foreign agent, but 'D' bit
is set:
The home agent SHOULD respond with Code 134, "poorly formed
Request".
Reserved 3 field of UDP Tunnel Request extension is nonzero and the
home agent does not recognize the value:
The home agent SHOULD respond with Code 134, "poorly formed
Request".
Encapsulation type requested in UDP Tunnel Request extension is
unsupported.
The home agent SHOULD respond with Code 140, "requested UDP
tunnel encapsulation unavailable".
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.
Levkowetz & Vaarala Expires May 2, 2002 [Page 16]
Internet-Draft NAT Traversal for MIP November 2001
4.8 Packet fragmentation
From RFC 3022 [11]:
"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 RFC 2003 [6] 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 RFC 2663 [9], 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 RFC 2663 [9], but
it is conceivable that shorter timeouts may exist in some NATs.
Levkowetz & Vaarala Expires May 2, 2002 [Page 17]
Internet-Draft NAT Traversal for MIP November 2001
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.
Sending a keepalive message SHALL consist of doing a regular Mobile
IP Registration Request, exactly as would otherwise have been done
before the expiration of the current registration. For each mobility
binding which has UDP tunnelling established, the Mobile node SHALL
do an extra Registration Request if no other packet to the HA has
been sent in K seconds, where K is a parameter with a default value
of 20 seconds. K may be set to another value by the HA as described
in the UDP tunnelling reply extension (Section 3.2).
As MIP UDP tunnelling is done using the same ports that have already
been used for the registration request / reply exchange, the MN will
send its first keepalive message at the earliest K seconds after the
registration request was sent. The mobile node MUST use the same UDP
source port for the keepalive messages (which are Registration
Requests) as was used for the original Registration Messages and for
data messages. The home agent MUST be prepared to receive re-
registration requests at the rate indicated by the Keepalive Interval
in the UDP Tunnel Reply Extension.
5. Implementation Issues
5.1 Movement Detection and Private Address Aliasing
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
problem of movement detection and address aliasing. It is maybe 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 a new link layer address.
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
Levkowetz & Vaarala Expires May 2, 2002 [Page 18]
Internet-Draft NAT Traversal for MIP November 2001
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.
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 Mobility Binding Lifetime
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 RFC2002 [5]. When using UDP
tunnelling, there are some cases where a short lifetime is
beneficial.
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.
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.
The definition of "short lifetime" in this context is dependent on
the requirements of the use 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.
6. Security Considerations
The authors do not think this mechanism exposes any security
vulnerabilities above those of using IP in IP encapsulation.
However, if the intermediate network is considered insecure, IPSec
should be used.
Levkowetz & Vaarala Expires May 2, 2002 [Page 19]
Internet-Draft NAT Traversal for MIP November 2001
A security advantage of this mechanism is that IKE and IPSec (both
ESP and AH), if run on top of Mobile IP, will survive NAT traversal
without modifications. IKE and IPsec could be used transparently
both between the MN and the HA, as well as between the MN and the CN.
MIP UDP tunnelling is vulnerable to Denial of Service (DoS) attacks
to the same extent as MIP IP-in-IP tunnelling is. The Registration
Request still has to carry a valid MN-HA authentication, which
protects the nonce or time based ID field, so there is no difference
with respect to replay attacks. In a man-in-the-middle scenario,
what the attacker may do is exactly what the NAT does, change
addresses and ports. The scenario will play out a bit differently
for MIP UDP tunnelling, in that with IP-in-IP tunnelling the man in
the middle could inspect, stop or redirect traffic, while with MIP
UDP tunnelling redirection would be effective from the time when the
HA accepted the registration and tunnelling till the next re-
registration (which would come pretty soon if the response to the MN
went to some bogus address). The effect is still the same; a man in
the middle may by various actions inspect, block or redirect traffic
with both IP-in-IP and MIP UDP tunnelling.
6.1 Firewall Considerations
This is not a general firewall traversal mechanism. However, using
MIP UDP encapsulation instead of IP-in-IP encapsulation may make it
more acceptable to configure a firewall to allow for the traffic.
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.
7. IANA Considerations
The value for the "Tunnel Data" header type field in Section 3.3,
must be assigned from the numbering space defined for Mobile IP
messages as defined in RFC2002 [5]. This must not conflict with any
numbers used in RFC2002 [5].
Likewise, the values for the "Tunnel Request" and "Tunnel Reply"
extension type fields in Section 3.1 and Section 3.2 must be assigned
from the numbering space defined for Mobile IP extensions as defined
in RFC2002 [5].
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].
Levkowetz & Vaarala Expires May 2, 2002 [Page 20]
Internet-Draft NAT Traversal for MIP November 2001
8. Intellectual property rights
ipUnplugged has one or more patents or patent applications that may
be relevant to this internet-draft. If any claims of these are
necessary for implementing this standard, any party will be able to
obtain a license from ipUnplugged to use any such patent claims under
openly specified, reasonable, non-discriminatory terms, free of
charge, for the purpose of implementing it.
9. Acknowledgements
Much of the text in Section 4.2 has been taken almost verbatim from
RFC 2003, IP Encapsulation within IP [6].
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.
Phil Roberts helped remove a number of rough edges, and Farid Adrangi
pointed out the DoS issue now covered in Security Considerations
(Section 6).
Thanks also to our coworkers, 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.
References
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[3] Hanks, S., Li, R., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[4] Atkinson, R., "IP Authentication Header", RFC 1826, August
1995.
[5] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
Levkowetz & Vaarala Expires May 2, 2002 [Page 21]
Internet-Draft NAT Traversal for MIP November 2001
1996.
[7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[9] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[10] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[11] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001.
[12] Montenegro, G., "Reverse Tunnelling for Mobile IP, revised",
RFC 3024, January 2001.
[13] Perkins, editor, C., "IP Mobility Support for IPv4, revised",
draft-ietf-mobileip-rfc2002-bis-08.txt (work in progress),
September 2001.
Authors' Addresses
O. Henrik Levkowetz
ipUnplugged AB
Arenavagen 33
Stockholm S-121 28
SWEDEN
Phone: +46 8 725 9513
EMail: henrik@levkowetz.com
Sami Vaarala
NetSeal Technologies
Niittykatu 6
Espoo 02201
FINLAND
Phone: +358 9 435 310
EMail: sami.vaarala@netseal.com
Levkowetz & Vaarala Expires May 2, 2002 [Page 22]
Internet-Draft NAT Traversal for MIP November 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
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.
Levkowetz & Vaarala Expires May 2, 2002 [Page 23]