Network Working Group S. Vaarala
Internet-Draft NetSeal Technologies
Expires: January 10, 2002 July 12, 2001
Mobile IP NAT/NAPT/Firewall Traversal
draft-vaarala-mobileip-nat-traversal-00
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 January 10, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Mobile IP and Network Address Translation (NAT) are incompatible.
This draft presents a mechanism of establishing a Mobile IP NAT
traversal binding in a backwards compatible manner. The NAT
traversal is based on using the Mobile IP Home Agent UDP port for
encapsulation of data traffic, thus requiring only a single NAT
address mapping. The presented method optimizes round trips required
to set up the NAT address mapping, which is a critical measure for
handover performance.
Vaarala Expires January 10, 2002 [Page 1]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Previous work . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Specification language . . . . . . . . . . . . . . . . . . 4
2. Protocol description . . . . . . . . . . . . . . . . . . . 5
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Message exchanges . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Message exchange with NAT devices present . . . . . . . . 6
2.2.2 Message exchange without NAT devices present . . . . . . . 7
2.2.3 Message exchange with a non-compliant home agent . . . . . 8
2.3 Packet formats . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Data packet encapsulation . . . . . . . . . . . . . . . . 8
2.3.2 Keepalive message . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Registration Request . . . . . . . . . . . . . . . . . . . 10
2.3.4 Registration Reply . . . . . . . . . . . . . . . . . . . . 11
2.3.5 New extensions . . . . . . . . . . . . . . . . . . . . . . 11
2.3.5.1 Mobile node traversal extension . . . . . . . . . . . . . 12
2.3.5.2 Home agent traversal extension . . . . . . . . . . . . . . 13
2.4 Version considerations . . . . . . . . . . . . . . . . . . 14
3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Overhead . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Network requirements . . . . . . . . . . . . . . . . . . . 15
4. Security considerations . . . . . . . . . . . . . . . . . 16
5. Intellectual property rights . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . 21
Vaarala Expires January 10, 2002 [Page 2]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
1. Introduction
1.1 Overview
Network Address Translation (NAT) [7] is an algorithm for modifying
IP packet address and optionally transport protocol fields in order
to map private addresses to public addresses. While NAT is
inherently incompatible with the Internet Protocol (IP) [1], it is
widely deployed in practice, and cannot be ignored in protocol
design. In addition to NAT devices there are routers that filter
certain kinds of packets in the route between the mobile node and
its home agent.
Mobile IP [4] is a protocol that provides IP layer mobility for
nodes. While Mobile IP itself is an established protocol, its design
does not take NAT devices into account. Thus, Mobile IP will not
work when the mobile node resides behind a NAT device (or several
NAT devices). Packet filtering routers also pose a problem for
Mobile IP connectivity because success in establishing a mobility
binding does not ensure that packets can actually be routed between
the mobile node and the home agent.
This document presents a simple protocol for UDP-based Mobile IP NAT
traversal. The protocol assumes that the network allows
communication between an UDP port chosen by the mobile node, and the
home agent UDP port 434. The user data is encapsulated in UDP
packets that use the same port numbers as the Mobile IP signalling
traffic, which has the following advantages. Firstly, only a single
NAT mapping is required for both Mobile IP signalling and user data
traffic. Secondly, server-to-client data can start flowing as
quickly as possible, optimizing handover performance. Thirdly, a
successful Mobile IP binding usually indicates that encapsulated
packets will flow unfiltered.
The protocol provides a method of NAT detection, and automatic use
of NAT traversal if the home agent determines that it is necessary.
In addition, the mobile node may request traversal to be used
regardless of NAT detection outcome, which is useful if intervening
firewalls block some types of traffic but let the Mobile IP traffic
pass thru. To keep the NAT mapping constant, empty UDP packets are
sent as keepalives in absence of traffic. The keepalive interval is
controlled by the home agent, which may be useful since the home
agent may have better knowledge of misbehaving NAT devices, and the
proper keepalive interval to be used with each such device.
Compatibility with existing Mobile IP implementations is ensured by
using the standard Mobile IP vendor extension mechanism to implement
the features described.
Vaarala Expires January 10, 2002 [Page 3]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
1.2 Previous work
Similar schemes have been presented previously for both Mobile IP
and IPsec. The scheme presented for Mobile IP in [10] assumes a
separate UDP port for data encapsulation, which requires extra
message exchanges to establish a NAT mapping before server-to-client
traffic may begin. Also, firewall traversal may be difficult since
the UDP port chosen by the home agent for data encapsulation may be
blocked even though the Mobile IP port 434 is not; there is no
efficient method of discovering acceptable ports.
The IPsec working group has presented a draft for IPsec NAT
traversal [11], which incorporates NAT traversal negotiation into
the IKE protocol [12] and reuses the IKE port (UDP port 500) for
data encapsulation. A generalization of this approach (reusing a
signalling channel for data encapsulation) is used in this document
for Mobile IP NAT traversal.
1.3 Terminology
The Mobile IP related terminology described in [4] is used in this
document. In addition, the following terms are used:
Traversal Mobility Binding: An extended kind of Mobile IP Mobility
Binding, that includes NAT traversal state.
Optimized Traversal: A method of UDP-based NAT traversal where the
Mobile IP data port is used for tunnelling of IPv4 packets
without extra overhead for any marker octets to distinguish
Mobile IP and user data packets.
Non-Optimized Traversal: A method of UDP-based NAT traversal where
the Mobile IP data port is used for tunnelling of IPv4 packets. A
reserved Mobile IP message type (marker) is used to distinguish
data packets from Mobile IP packets.
Data Encapsulation Marker: Mobile IP message type value(s) that are
used to distinguish user data packets from Mobile IP packets.
1.4 Specification language
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 [6].
Vaarala Expires January 10, 2002 [Page 4]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
2. Protocol description
2.1 Overview
The protocol described in this document has functionality (1) to
negotiate NAT traversal support in a backwards compatible manner,
(2) to detect the presence of NAT device(s), (3) to determine
whether NAT traversal should be used or not, and if so, to assign a
NAT keepalive interval, and (4) to tunnel data packets. The protocol
assumes that the mobile node is registering using a co-located
care-of address.
All functionality except data packet tunnelling are performed within
the standard Registration Request (RREQ) and Registration Reply
(RREP) message exchange. The RREQ message contains a Mobile Node
Traversal Extension, which is a Normal Vendor-Specific Extension
(NVSE) [9], which indicates that the mobile node supports this
protocol. The extension also contains a flag, which indicates that
the mobile node requests unconditional tunnelling of data packets,
regardless of the outcome of NAT detection performed by the home
agent. The extension also contains the data encapsulation marker
used by the mobile node.
The home agent detects the presence of NAT device(s) by comparing
the source IP address of the RREQ message, and the co-located
care-of address contained within the message. A discrepancy
indicates that an address translation has been performed. Traversal
MUST be enabled if NAT is detected, or if the mobile node has
requested unconditional tunnelling. However, the home agent MAY also
enable traversal unilaterally. Should traversal be used, a Home
Agent Traversal Extension, which is a Critical Vendor-Specific
Extension (CVSE) [9], is inserted into the RREP message. The
presence of the extension indicates that this protocol is supported
by the home agent, and that NAT traversal has been enabled in the
mobility binding shared by the mobile node and the home agent. The
extension also includes the server data encapsulation marker, and
the NAT keepalive interval that the mobile node should use.
If NAT traversal is not used, or if the home agent does not support
this protocol, the RREP message will not include the Home Agent
Traversal Extension.
Once NAT traversal has been enabled for a given Mobile IP binding,
both the home agent and the mobile node encapsulate IPv4 packets
inside UDP payloads, using the same ports as in the RREQ/RREP
messages. Ordinary Mobile IP packets are differentiated from
tunnelled IPv4 packets by means of the Mobile IP message type field.
The data encapsulation markers exchanged in the RREQ/RREP message
vendor extensions determine which message type octets serve as data
Vaarala Expires January 10, 2002 [Page 5]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
encapsulation markers for each direction of traffic. Two types of
encapsulation behavior are supported: optimized, with eight octet
overhead, and non-optimized, with nine octet overhead. Empty UDP
packets are used as NAT keepalive messages, should there be no user
data or Mobile IP traffic within the NAT keepalive interval. Once
the registration lifetime expires, the NAT traversal MUST be
stopped. The traversal state is a part of the mobility binding, so a
new RREQ/RREP message exchange is required to re-establish NAT
traversal.
Since the same UDP port is used for both Mobile IP traffic and
encapsulated data traffic, the only requirements for firewalls and
NAT devices is to pass traffic between the home agent UDP port 434
and the UDP port chosen by the mobile node. Also, if the RREQ/RREP
message exchange succeeds, the data traffic encapsulation will
almost certainly pass the routers between the mobile node and the
home agent.
2.2 Message exchanges
The notation "src-addr:src-udp-port -> dst-addr:dst-udp-port" is
used in the following diagrams to indicate addressing fields of
packets. COA is the possibly private co-located care-of address of
the mobile node. HA is the home agent address, which is assumed to
be a public address. X is the UDP source port used by the mobile
node for Mobile IP (or data encapsulation) messages destined to the
home agent. This port is assumed static for the duration of a given
RREQ/RREP exchange, and the (possible) data encapsulation and
keepalive traffic that follows. NAT-COA is the translated COA
address, while NAT-X is the possibly translated UDP port X (NAT and
NAPT are handled identically in the protocol, so the worst case, ie
NAPT, is assumed).
2.2.1 Message exchange with NAT devices present
This exchange of messages takes place when both mobile node and home
agent are compliant, and one or more NAT/NAPT devices exist in the
route between mobile node and home agent.
Vaarala Expires January 10, 2002 [Page 6]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
mobile node NAT/NAPT device(s) home agent
=========== ================== ==========
----------------> COA:X -> HA:434
Registration Request
+ co-located address COA
+ Mobile Node Traversal Extension
(U-flag, mobile node encapsulation marker)
--------------> NAT-COA:NAT-X -> HA:434
Registration Request
Discrepancy: IP header source address is NAT-COA,
while RREQ care-of address field is COA.
HA->MN traffic can start flowing.
<------------- HA:434 -> NAT-COA:NAT-X
Registration Reply
+ Home Agent Traversal Extension
(home agent encapsulation marker,
NAT keepalive interval)
<---------------- HA:434 -> COA:X
Registration completed, MN->HA traffic can also
start flowing.
[data traffic]
[NAT keepalive interval passed without traffic, send keepalive]
----------------> COA:X -> HA:434
keepalive (empty UDP)
--------------> NAT-COA:NAT-X -> HA:434
2.2.2 Message exchange without NAT devices present
This exchange of messages takes place when both mobile node and home
agent are compliant, but no NAT/NAPT devices seem to be present.
Vaarala Expires January 10, 2002 [Page 7]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
mobile node home agent
=========== ==========
-----------------------------------> COA:X -> HA:434
Registration Request
+ co-located address COA
+ Mobile Node Traversal Extension
(U-flag, mobile node encapsulation marker)
No discrepancy between the IP header source address
field and the RREQ care-of address field.
If the U-flag (unconditional tunnelling requested)
is set, or if the home agent determines that UDP
data encapsulation should be performed, the scenario
reverts to the one described above.
HA->MN traffic can start flowing.
<---------------------------------- HA:434 -> COA:X
Registration Reply
[no keepalive traffic, behave as required by RFC 2002.]
2.2.3 Message exchange with a non-compliant home agent
If the home agent does not support this protocol, it will ignore the
NVSE sent by the mobile node. If NAT/NAPT devices are present, the
dscrepancy in the Mobile IP headers should cause the HA to discard
or reject the registration.
2.3 Packet formats
2.3.1 Data packet encapsulation
Since the same UDP ports are used to send both Mobile IP packets and
encapsulated data packets, there must be a method of identifying
which kind of packet was received by a mobile node or by a home
agent. This protocol uses the first octet of the UDP payload data to
make this determination. The IPv4 header has the following format
[1]:
Vaarala Expires January 10, 2002 [Page 8]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Mobile IP messages have a one octet message type identifier,
with rest of the message being message type specific. For instance,
Registration Request has the following format [4]:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |S|B|D|M|G|V|rsv| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
The first octet of an IPv4 header contains both an IP version field
(always 4 for IPv4) and the Internet Header Length field, which is
always in the range 5...15. Thus the first octet of IPv4 header is
always in the range 0x45...0x4f.
This fact is used by the optimized traversal mode to differentiate
packet types. If the first octet of the UDP payload is in the range
0x45...0x4f, the UDP payload (including the first octet) is assumed
to be an encapsulated IPv4 packet. Otherwise the payload is assumed
to be a Mobile IP message. The optimized traversal mode does not add
extra overhead (in addition to the UDP header), but requires that
Vaarala Expires January 10, 2002 [Page 9]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
the receiver has reserved the Mobile IP message types 0x45...0x4f
for data encapsulation markers.
In non-optimized traversal a single message type is used as a data
encapsulation marker. The marker message type can be chosen
dynamically, and is sent as part of both Mobile Node Traversal
Extension and Home Agent Traversal Extension. If the first octet of
the UDP payload equals the marker chosen by the receiving host, the
UDP payload excluding the first octet is assumed to be an
encapsulated IPv4 packet. Otherwise the payload is assumed to be a
Mobile IP message. Non-optimized traversal mode adds one octet
overhead (in addition to the UDP header), but only requires that a
single Mobile IP message type be reserved to serve as a marker.
Since the marker is not pre-defined by this protocol, any Mobile IP
message type can serve as one; thus there is no possibility of
conflict with future Mobile IP message types, as long as there is at
least one unused message type to serve as a marker.
Both modes of traversal MUST be supported. The receiving host
chooses which type of traversal it expects in packets sent to it,
and if non-optimized traversal is used, which marker octet is used.
To emphasize, the marker may be different in each direction.
2.3.2 Keepalive message
A keepalive message is an empty UDP packet sent using the same port
information as Mobile IP and encapsulated data packets. This packet
is differentiated from Mobile IP and encapsulated data packets using
the UDP length field (which MUST be eight) [2].
2.3.3 Registration Request
When using this protocol, the Registration Request message consists
of an IPv4 header, followed by an UDP header, followed by the fixed
Mobile IP Registration Request header [4], followed by extensions,
including the Mobile Node Traversal Extension, followed by the
Mobile-Home Authentication Extension ([4], Section 3.5.2), which
MUST NOT be followed by any extensions.
The UDP source port of the Registration Request may be chosen freely
by the mobile node. However, the source port MUST stay constant for
the duration of the binding being requested, and for the
data/keepalive traffic that follows. This ensures that the NAT
mapping stays valid. The mobile node SHOULD use the same source
port for all interactions with the home agent.
The Registration Request message fields operate normally, with the
following exceptions. The 'D' (decapsulation by mobile node) bit
MUST be set, because only co-located care-of address mode is
Vaarala Expires January 10, 2002 [Page 10]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
supported. The 'M' (minimal encapsulation) bit MUST NOT be set,
since it conflicts with NAT. The 'G' (generic routing encapsulation,
or GRE [8]) bit operates normally, as do the other flag bits. The
Care-of Address field is set to the possibly private co-located
care-of address.
When simultaneous bindings are used, the usage of traversal applies
to each binding individually, ie each binding has a different
keepalive interval and potentially different encapsulation markers.
2.3.4 Registration Reply
The Registration Reply message consists of an IPv4 header, followed
by an UDP header, followed by the fixed Mobile IP Registration Reply
header [4], followed by extensions, possibly including the Home
Agent Traversal Extension, followed by the Mobile-Home
Authentication Extension, which MUST NOT be followed by any
extensions.
The Registration Reply message fields are set normally.
Because there is nothing to guarantee that the NAT mapping is not
lost -- data and keepalive packets may be lost, or the NAT device
may be rebooted -- the home agent implementation MUST take the
special case of a lost NAT mapping into consideration. To avoid a
long traffic blackout in such situations the home agent SHOULD set
the lifetime of the binding to a conservative value, such as one
minute. This ensures that if the NAT mapping is lost, a new one is
formed by a new RREQ/RREP exchange in a reasonable time.
The NAT traversal state is conceptually added into the Mobile IP
binding state, and thus, it MUST be re-negotiated for every
RREQ/RREP message pair exchange.
2.3.5 New extensions
The Normal Vendor-Specific Extensions (NVSE) and Critical
Vendor-Specific Extensions (CVSE) used in this document conform to
[9]. Unauthenticated extensions MUST NOT be processed.
Vaarala Expires January 10, 2002 [Page 11]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
2.3.5.1 Mobile node traversal extension
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-NVSE-Type |U| Reserved | Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Mobile Node Traversal Extension is a NVSE (Normal
Vendor-Specific Extension), which indicates support for this
protocol. It is ignored by the receiver if the extension is not
supported.
The fields are set as follows:
Type: NVSE-TYPE-NUMBER 134 [9].
Length: 10.
Vendor/Org-Id: 9213, hex 0x23fd, registered to NetSeal Technologies.
Vendor-NVSE-Type: 16385 (0x4001)
U-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 (eg because of firewall filtering
rules). If the home agent supports this protocol, it MUST either
accept the traversal and reply with a Home Agent Traversal
Extension or reject the traversal. The suggested value for the
Registration Reply Code field in case of failed registration is
129 ("administratively prohibited").
Marker: If zero, indicates that the mobile node uses optimized
traversal. If non-zero, indicates that the mobile node uses
non-optimized traversal, and the value of the field is the marker
octet to be placed in the UDP payload prior to the actual
encapsulated IPv4 packet. The home agent MUST use the
encapsulation method and marker octet indicated by the mobile
node in encapsulated packets sent to the mobile node.
All reserved fields MUST be set to zero. If a reserved field is
non-zero when the extension is received, the whole extension MUST be
ignored.
Vaarala Expires January 10, 2002 [Page 12]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
2.3.5.2 Home agent traversal extension
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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-CVSE-Type | Reserved | Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keepalive-Interval-Secs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Home Agent Traversal Extension is a CVSE, which indicates that
(1) the home agent supports this protocol, and (2) that the
traversal has been enabled for the mobility binding established
using the RREQ/RREP exchange.
The fields are set as follows:
Type: CVSE-TYPE-NUMBER 38 [9].
Length: 12.
Vendor/Org-Id: 9213, hex 0x23fd, registered to NetSeal Technologies.
Vendor-CVSE-Type: 16386 (0x4002)
Marker: If zero, indicates that the home agent uses optimized
traversal. If non-zero, indicates that the home agent uses
non-optimized traversal, and the value of the field is the marker
octet to be placed in the UDP payload prior to the actual
encapsulated IPv4 packet. The mobile node MUST use the
encapsulation method and marker octet indicated by the home agent
in encapsulated packets sent to the home agent.
Keepalive-Interval-Secs: Specifies the NAT keepalive interval that
the mobile node SHOULD use. A keepalive packet SHOULD be sent if
Keepalive-Interval-Secs seconds have elapsed without any
signalling or data traffic being sent.
The keepalive interval may depend on specific NAT devices. It may be
the case that the home agent is aware of parts of the network, and
can "recommend" proper keepalive traffic intervals for mobile nodes.
For example, the server wants keepalive traffic to be sent with an
interval of 60 seconds by default, but certain problem devices
require shorter keepalive packet intervals. These "problem devices"
can be configured to the home agent one by one, while other devices
Vaarala Expires January 10, 2002 [Page 13]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
are handled using the default value. Note that the mobile node is
incapable of making an informed decision since it does not see the
external address that the NAT device assigns to it.
All reserved fields MUST be set to zero. If a reserved field is
non-zero when the extension is received, the mobile node MUST assume
that the registration failed.
2.4 Version considerations
There are no version negotiation fields in this protocol. If
functionality is changed radically new vendor extension IDs are
allocated to the new traversal protocol. The mobile node may
indicate support for several versions of this protocol by appending
several NVSE extensions in the Registration Request message.
If the home agent detects a flag in the currently reserved area of
the Mobile Node Traversal Extension that it does not support, it
MUST reject the registration. Suggested Code is 134 (poorly formed
Request). If the mobile node detects a flag in the currently
reserved area, it MUST act as if the registration had failed, and
that the binding was not completed.
Vaarala Expires January 10, 2002 [Page 14]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
3. Analysis
3.1 Overhead
This draft does not add significant latency to the ordinary Mobile
IP Registration Request / Registration Reply message exchange. In
particular, the NAT address mapping is formed when the mobile node
sends its first Registration Request message, and is already valid
when the home agent receives the packet. Thus, the home agent may
start forwarding traffic to the client immediately after receiving
the Registration Request (assuming, of course, that the binding is
accepted).
In other words, the latency for server-to-client traffic flow is 0.5
roundtrips, and for client-to-server traffic, one roundtrip. The
extra data in the form of vendor extensions does add some
transmission latency, and may be noticeable especially using slow
media.
If optimized data encapsulation is used, there is an eight octet
overhead (compared to IP-IP tunnelling) per data packet caused by
the UDP header required for traversal. For non-optimized data
encapsulation, the corresponding overhead is nine octets per data
packet.
3.2 Network requirements
The protocol described in this document works in networks where
there are ordinary routers, NAT/NAPT routers, and firewalls that are
configured to pass Mobile IP packets (variable mobile node port and
fixed home agent port 434). There are no other requirements with
regards to UDP ports, and since there are no extra UDP ports for
data encapsulation, there is no need to use heuristics to determine
which UDP port might actually work for data encapsulation: if the
Registration Request is received, both the Registration Reply and
encapsulated data is typically received properly.
Since the Mobile IP home agent port is used for data encapsulation,
there MUST NOT be foreign agents in the route (which might be
confused by such packets). In particular, only the co-located
care-of address mode of Mobile IP is supported. (In fact, a DHCP
server that also performs NAT is a viable replacement for a FA.)
Vaarala Expires January 10, 2002 [Page 15]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
4. Security considerations
The Traversal Extensions used by this protocol are authenticated by
the Mobile IP Mobile-Home Authentication Extension. The presence of
the extensions do not seem to cause vulnerabilities, since the
information contained in them is not confidential. Support of this
protocol may be considered as useful information for an attacker,
though.
A strong attacker is free to modify the IP packets sent, and thus eg
cause the home agent to mistakenly believe there are NAT device(s)
in the route between mobile node and the home agent. However, such
modifications require read-write access to the packet flow, which
already enable other more powerful attacks to be performed.
Vaarala Expires January 10, 2002 [Page 16]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
5. Intellectual property rights
NetSeal Technologies has no patent applications related to the
protocol described in this document.
Vaarala Expires January 10, 2002 [Page 17]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
6. Acknowledgements
Levkowetz et al. have proposed a similar scheme in [10], the
difference being a dedicated UDP tunnelling port. Kivinen, Stenberg,
Huttunen et al. have proposed a NAT traversal protocol for IPsec
[11], which uses the same approach taken here, in particular reusing
the NAT address mapping of the signalling channel (in their draft,
IKE) for data encapsulation.
The author would like to thank the staff at NetSeal Technologies for
useful feedback.
Vaarala Expires January 10, 2002 [Page 18]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
References
[1] Defense Advanced Research Projects Agency (DARPA), Information
Processing Techniques Office and , "Internet Protocol", STD
5, RFC 791, September 1981.
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[3] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
[4] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[5] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[6] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[8] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[9] Dommety, G. and K. Leung, "Mobile IP
Vendor/Organization-Specific Extensions", RFC 3115, April 2001.
[10] Levkowetz, O. H., Forslow, J. and H. Sjostrand, "NAT Traversal
for Mobile IP using UDP Tunnelling (Work in Progress)", July
2001.
[11] Huttunen, A., Dixon, W., Swander, B., Kivinen, T., Stenberg,
M., Volpe, V. and L. DiBurro, "UDP Encapsulation of IPsec
Packets (Work in Progress)", June 2001.
[12] Kivinen, T., Stenberg, M., Huttunen, A., Dixon, W., Swander,
B., Volpe, V. and L. DiBurro, "Negotiation of NAT-Traversal in
the IKE (Work in Progress)", June 2001.
Vaarala Expires January 10, 2002 [Page 19]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001
Author's Address
Sami Vaarala
NetSeal Technologies
P.O Box 38
Niittykatu 6
02201 Espoo
Phone: +358-9-435 310
Fax: +358-9-435 311 00
EMail: sami.vaarala@netseal.com
URI: http://www.netseal.com/
Vaarala Expires January 10, 2002 [Page 20]
Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 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.
Vaarala Expires January 10, 2002 [Page 21]