< draft-ietf-mobileip-nat-traversal-06.txt   draft-ietf-mobileip-nat-traversal-07.txt >
Internet Engineering Task Force H. Levkowetz Internet Engineering Task Force H. Levkowetz
Internet-Draft ipUnplugged Internet-Draft ipUnplugged
Expires: October 30, 2002 S. Vaarala Expires: May 5, 2003 S. Vaarala
Netseal Netseal
May 2002 November 4, 2002
Mobile IP NAT/NAPT Traversal using UDP Tunnelling Mobile IP NAT/NAPT Traversal using UDP Tunnelling
<draft-ietf-mobileip-nat-traversal-06.txt> <draft-ietf-mobileip-nat-traversal-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 30, 2002. This Internet-Draft will expire on May 5, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
Mobile IP's datagram tunnelling is incompatible with Network Address Mobile IP's datagram tunnelling is incompatible with Network Address
Translation (NAT). This document presents extensions to the Mobile Translation (NAT). This document presents extensions to the Mobile
IP protocol and a tunnelling method which permits mobile nodes using IP protocol and a tunnelling method which permits mobile nodes using
skipping to change at page 2, line 13 skipping to change at page 2, line 13
traffic. traffic.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Problem description . . . . . . . . . . . . . . . . . . . . 5 1.2 Problem description . . . . . . . . . . . . . . . . . . . . 5
1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 6
2. NAT Traversal Overview . . . . . . . . . . . . . . . . . . . 6 2. NAT Traversal Overview . . . . . . . . . . . . . . . . . . . 6
2.1 Basic Message Sequence . . . . . . . . . . . . . . . . . . . 6 2.1 Basic Message Sequence . . . . . . . . . . . . . . . . . . . 7
3. New Message Formats . . . . . . . . . . . . . . . . . . . . 8 3. New Message Formats . . . . . . . . . . . . . . . . . . . . 8
3.1 UDP Tunnel Request Extension . . . . . . . . . . . . . . . . 8 3.1 UDP Tunnel Request Extension . . . . . . . . . . . . . . . . 8
3.1.1 F (Force) Flag . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1 F (Force) Flag . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 R (Registration through FA Required) flag . . . . . . . . . 10 3.1.2 R (Registration through FA Required) flag . . . . . . . . . 10
3.1.3 Reserved Fields . . . . . . . . . . . . . . . . . . . . . . 10 3.1.3 Reserved Fields . . . . . . . . . . . . . . . . . . . . . . 10
3.1.4 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.4 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.5 Mobile IP Registration Bits . . . . . . . . . . . . . . . . 10 3.1.5 Mobile IP Registration Bits . . . . . . . . . . . . . . . . 10
3.2 UDP Tunnel Reply Extension . . . . . . . . . . . . . . . . . 11 3.2 UDP Tunnel Reply Extension . . . . . . . . . . . . . . . . . 11
3.2.1 Reply Code . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.1 Reply Code . . . . . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 3, line 11 skipping to change at page 3, line 11
6.1.2 Sending a Bogus Keepalive Message . . . . . . . . . . . . . 28 6.1.2 Sending a Bogus Keepalive Message . . . . . . . . . . . . . 28
6.2 Use of IPsec . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2 Use of IPsec . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3 Firewall Considerations . . . . . . . . . . . . . . . . . . 29 6.3 Firewall Considerations . . . . . . . . . . . . . . . . . . 29
7. UNSAF Considerations . . . . . . . . . . . . . . . . . . . . 30 7. UNSAF Considerations . . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
9. Intellectual property rights . . . . . . . . . . . . . . . . 32 9. Intellectual property rights . . . . . . . . . . . . . . . . 32
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
Normative References . . . . . . . . . . . . . . . . . . . . 32 Normative References . . . . . . . . . . . . . . . . . . . . 33
Informative References . . . . . . . . . . . . . . . . . . . 33 Informative References . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34
Full Copyright Statement . . . . . . . . . . . . . . . . . . 35 Full Copyright Statement . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
1.1 Terminology 1.1 Terminology
The Mobile IP related terminology described in RFC 3344 [10] is used The Mobile IP related terminology described in RFC 3344 [11] is used
in this document. In addition, the following terms are used: in this document. In addition, the following terms are used:
Forward Tunnel Forward Tunnel
A tunnel that forwards packets towards the mobile node. It A tunnel that forwards packets towards the mobile node. It
starts at the home agent, and ends at the mobile node's care-of starts at the home agent, and ends at the mobile node's care-of
address. address.
Reverse Tunnel Reverse Tunnel
A tunnel that starts at the mobile node's care-of address and A tunnel that starts at the mobile node's care-of address and
terminates at the home agent. terminates at the home agent.
NAT NAT
Network Address Translation. "Traditional NAT would allow Network Address Translation. "Traditional NAT would allow
hosts within a private network to transparently access hosts in hosts within a private network to transparently access hosts in
the external network, in most cases. In a traditional NAT, the external network, in most cases. In a traditional NAT,
sessions are uni-directional, outbound from the private sessions are uni-directional, outbound from the private
network." -- RFC 2663 [12]. Basic NAT and NAPT are two network." -- RFC 2663 [13]. Basic NAT and NAPT are two
varieties of NAT. varieties of NAT.
Basic NAT Basic NAT
"With Basic NAT, a block of external addresses are set aside "With Basic NAT, a block of external addresses are set aside
for translating addresses of hosts in a private domain as they for translating addresses of hosts in a private domain as they
originate sessions to the external domain. For packets originate sessions to the external domain. For packets
outbound from the private network, the source IP address and outbound from the private network, the source IP address and
related fields such as IP, TCP, UDP and ICMP header checksums related fields such as IP, TCP, UDP and ICMP header checksums
are translated. For inbound packets, the destination IP are translated. For inbound packets, the destination IP
address and the checksums as listed above are translated." -- address and the checksums as listed above are translated." --
RFC 2663 [12] RFC 2663 [13]
NAPT NAPT
Network Address Port Translation. "NAPT extends the notion of Network Address Port Translation. "NAPT extends the notion of
translation one step further by also translating transport translation one step further by also translating transport
identifier (e.g., TCP and UDP port numbers, ICMP query identifier (e.g., TCP and UDP port numbers, ICMP query
identifiers). This allows the transport identifiers of a identifiers). This allows the transport identifiers of a
number of private hosts to be multiplexed into the transport number of private hosts to be multiplexed into the transport
identifiers of a single external address. NAPT allows a set of identifiers of a single external address. NAPT allows a set of
hosts to share a single external address. Note that NAPT can hosts to share a single external address. Note that NAPT can
be combined with Basic NAT so that a pool of external addresses be combined with Basic NAT so that a pool of external addresses
are used in conjunction with port translation." -- RFC 2663 are used in conjunction with port translation." -- RFC 2663
[12] [13]
In this document, the more general term NAT is used to cover both 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 and NAPTs. In most deployment cases today, we believe that the
NATs used are of the NAPT variety. NATs used are of the NAPT variety.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [7]. document are to be interpreted as described in RFC 2119 [7].
1.2 Problem description 1.2 Problem description
A basic assumption that Mobile IP [10] makes is that mobile nodes and A basic assumption that Mobile IP [11] makes is that mobile nodes and
foreign agents are uniquely identifiable by a globally routable IP foreign agents are uniquely identifiable by a globally routable IP
address. This assumption breaks down when a mobile node attempts to address. This assumption breaks down when a mobile node attempts to
communicate from behind a NAT. communicate from behind a NAT.
Mobile IP relies on sending traffic from the home network to the Mobile IP relies on sending traffic from the home network to the
mobile node or foreign agent through IP-in-IP tunnelling. IP nodes mobile node or foreign agent through IP-in-IP tunnelling. IP nodes
which communicate from behind a NAT are reachable only through the which communicate from behind a NAT are reachable only through the
NAT's public address(es). IP-in-IP tunnelling does not generally NAT's public address(es). IP-in-IP tunnelling does not generally
contain enough information to permit unique translation from the contain enough information to permit unique translation from the
common public address(es) to the particular care-of address of a common public address(es) to the particular care-of address of a
skipping to change at page 5, line 48 skipping to change at page 5, line 48
What is needed is an alternative data tunnelling mechanism for Mobile What is needed is an alternative data tunnelling mechanism for Mobile
IP which will provide the means needed for NAT devices to do unique IP which will provide the means needed for NAT devices to do unique
mappings so that address translation will work, and a registration mappings so that address translation will work, and a registration
mechanism which will permit such an alternative tunnelling mechanism mechanism which will permit such an alternative tunnelling mechanism
to be set up when appropriate. to be set up when appropriate.
This mechanism will address 3 different scenarios: This mechanism will address 3 different scenarios:
- A mobile node with co-located address behind a NAT; no FA - A mobile node with co-located address behind a NAT; no FA
- A mobile node registered away with an FA which is behind a NAT - 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 - A mobile node with co-located address using an FA which demands
that registrations pass through the FA (sets the "R" bit) where that registrations pass through the FA (sets the "R" bit) where
both the mobile node and the FA are behind a NAT both the mobile node and the FA are behind the same NAT
1.3 Assumptions 1.3 Assumptions
The primary assumption in this document is that the network allows The primary assumption in this document is that the network allows
communication between an UDP port chosen by the mobile node and the communication between an UDP port chosen by the mobile node and the
home agent UDP port 434. If this assumption does not hold, neither home agent UDP port 434. If this assumption does not hold, neither
Mobile IP registration nor data tunnelling will work. Mobile IP registration nor data tunnelling will work.
This document does NOT assume that mobility is constrained to a This document does NOT assume that mobility is constrained to a
common IP address space. On the contrary, the routing fabric between common IP address space. On the contrary, the routing fabric between
the mobile node and the home agent may be partitioned into a the mobile node and the home agent may be partitioned into a
"private" and a "public" network, and the assumption is that some "private" and a "public" network, and the assumption is that some
mechanism is needed in addition to vanilla Mobile IP according to RFC mechanism is needed in addition to vanilla Mobile IP according to RFC
3344 [10] in order to achieve mobility within disparate IP address 3344 [11] in order to achieve mobility within disparate IP address
spaces. spaces.
For a more extensive discussion of the problems with disparate For a more extensive discussion of the problems with disparate
address spaces, and how they may be solved, see RFC 3024 [9]. address spaces, and how they may be solved, see RFC 3024 [10].
The reverse tunnels considered here are symmetric, that is, they use The reverse tunnels considered here are symmetric, that is, they use
the same configuration (encapsulation method, IP address endpoints) the same configuration (encapsulation method, IP address endpoints)
as the forward tunnel. as the forward tunnel.
2. NAT Traversal Overview 2. NAT Traversal Overview
This section gives a brief overview of the MIP UDP tunnelling This section gives a brief overview of the MIP UDP tunnelling
mechanism which may be used to achieve NAT traversal for Mobile IP. mechanism which may be used to achieve NAT traversal for Mobile IP.
skipping to change at page 8, line 43 skipping to change at page 8, line 43
. . . . . .
3. New Message Formats 3. New Message Formats
3.1 UDP Tunnel Request Extension 3.1 UDP Tunnel Request Extension
This extension is a skippable Extension. It signifies that the This extension is a skippable Extension. It signifies that the
sender is capable of handling MIP UDP tunnelling, and optionally that sender is capable of handling MIP UDP tunnelling, and optionally that
a particular encapsulation format is requested in the MIP UDP tunnel. a particular encapsulation format is requested in the MIP UDP tunnel.
The format of this extension is as shown below. It adheres to the The format of this extension is as shown below. It adheres to the
short extension format described in [10]. short extension format described in [11].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Type | Length | Sub-Type | Reserved 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|R| Reserved 2| Encapsulation | Reserved 3 | |F|R| Reserved 2| Encapsulation | Reserved 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (to be assigned by IANA) (skippable). Type (to be assigned by IANA) (skippable).
skipping to change at page 10, line 31 skipping to change at page 10, line 31
rejection of the extension from an old implementation. rejection of the extension from an old implementation.
3.1.4 Encapsulation 3.1.4 Encapsulation
The 'Encapsulation' field defines the mode of encapsulation requested The 'Encapsulation' field defines the mode of encapsulation requested
if MIP UDP tunnelling is accepted by the home agent. This field uses if MIP UDP tunnelling is accepted by the home agent. This field uses
the same values as the IP header Protocol field: the same values as the IP header Protocol field:
4 IP header (IP-in-UDP tunnelling) RFC 2003 [5] 4 IP header (IP-in-UDP tunnelling) RFC 2003 [5]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8] 47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [9]
55 Minimal IP encapsulation header RFC 2004 [6] 55 Minimal IP encapsulation header RFC 2004 [6]
If the home agent finds that UDP tunnelling is not needed, the If the home agent finds that UDP tunnelling is not needed, the
encapsulation will be determined by the 'M' and 'G' flags of the encapsulation will be determined by the 'M' and 'G' flags of the
registration request; but if the home agent finds that MIP UDP registration request; but if the home agent finds that MIP UDP
tunnelling should be done, the encapsulation is determined from the tunnelling should be done, the encapsulation is determined from the
value of the Encapsulation field. If the value of this field is 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 zero, it defaults to the value of 'M' and 'G' fields in the
Registration Request message, but if it is non-zero, it indicates Registration Request message, but if it is non-zero, it indicates
that a particular encapsulation is desired. that a particular encapsulation is desired.
3.1.5 Mobile IP Registration Bits 3.1.5 Mobile IP Registration Bits
The Mobile IP registration bits S, B, D, M, G and T retain their The Mobile IP registration bits S, B, D, M, G and T retain their
meaning as described in RFC 3344 [10] and RFC 3024 [9] (except that meaning as described in RFC 3344 [11] and RFC 3024 [10] (except that
the significance of the M and G bits may be modified by the the significance of the M and G bits may be modified by the
Encapsulation field when MIP UDP tunnelling is used, as described Encapsulation field when MIP UDP tunnelling is used, as described
above). The use of the M and G bits together with MIP UDP tunnelling above). The use of the M and G bits together with MIP UDP tunnelling
is also touched upon in Section 4.1. is also touched upon in Section 4.1.
When the MN requests MIP UDP tunnelling, the 'D' bit (Decapsulation When the MN requests MIP UDP tunnelling, the 'D' bit (Decapsulation
by the mobile node) MUST be set, otherwise UDP tunnelling would not by the mobile node) MUST be set, otherwise UDP tunnelling would not
be meaningful. be meaningful.
Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP
skipping to change at page 13, line 7 skipping to change at page 13, line 7
Reserved Reserved for future use. MUST be set to 0 on Reserved Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception. sending, MUST be ignored on reception.
The Next Header field uses the same values as the IP header Protocol The Next Header field uses the same values as the IP header Protocol
field. Immediately relevant for use with Mobile IP are the following field. Immediately relevant for use with Mobile IP are the following
values: values:
4 IP header (IP-in-UDP tunnelling) RFC 2003 [5] 4 IP header (IP-in-UDP tunnelling) RFC 2003 [5]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8] 47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [9]
55 Minimal IP encapsulation header RFC 2004 [6] 55 Minimal IP encapsulation header RFC 2004 [6]
The receiver of a tunnelled packet MUST check that the Next Header The receiver of a tunnelled packet MUST check that the Next Header
value matches the tunnelling mode established for the mobility value matches the tunnelling mode established for the mobility
binding with which the packet was sent. If a discrepancy is binding with which the packet was sent. If a discrepancy is
detected, the packet MUST be dropped. A log entry MAY be written, 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 but in this case the receiver SHOULD ensure that the amount of log
entries written is not excessive. entries written is not excessive.
In addition to the encapsulation forms listed above, the MIP UDP In addition to the encapsulation forms listed above, the MIP UDP
tunnelling can potentially support other encapsulations, by use of tunnelling can potentially support other encapsulations, by use of
the Next Header field in the MIP Tunnel Data Header and the the Next Header field in the MIP Tunnel Data Header and the
Encapsulation Header field of the UDP Tunnel Request Extension Encapsulation Header field of the UDP Tunnel Request Extension
(Section 3.1). (Section 3.1).
3.4 UDP Tunnelling Flag in Agent Advertisements 3.4 UDP Tunnelling Flag in Agent Advertisements
The only change to the Mobility Agent Advertisement Extension defined The only change to the Mobility Agent Advertisement Extension defined
in RFC 3344 [10] is a flag indicating that the foreign agent in RFC 3344 [11] is a flag indicating that the foreign agent
generating the Agent Advertisement supports MIP UDP Tunnelling. The generating the Agent Advertisement supports MIP UDP Tunnelling. The
flag is inserted after the flags defined in [10]. flag is inserted after the flags defined in [11].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Type | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|r|T|U| reserved | | Lifetime |R|B|H|F|M|G|r|T|U| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses | | zero or more Care-of Addresses |
| ... | | ... |
skipping to change at page 14, line 27 skipping to change at page 14, line 27
4. Protocol Behaviour 4. Protocol Behaviour
4.1 Relation to standard MIP tunnelling 4.1 Relation to standard MIP tunnelling
The default encapsulation mode for MIP UDP tunnelling is IP-in-UDP The default encapsulation mode for MIP UDP tunnelling is IP-in-UDP
encapsulation. The mobile node MAY request alternative forms of encapsulation. The mobile node MAY request alternative forms of
encapsulation to be used with UDP tunnelling by setting the 'M' bit 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 and/or the 'G' bit of a Mobile IP registration request, or by
explicitly requesting a particular encapsulation for the MIP UDP explicitly requesting a particular encapsulation for the MIP UDP
tunnel by using the Encapsulation field. The M and G bits retain the tunnel by using the Encapsulation field. The M and G bits retain the
meaning as described in RFC 3344 [10] within the context of MIP UDP meaning as described in RFC 3344 [11] within the context of MIP UDP
tunnelling. The UDP tunnelling version of the classic MIP tunnelling. The UDP tunnelling version of the classic MIP
encapsulation methods can be summarised as: encapsulation methods can be summarised as:
IP in UDP. When Mobile IP UDP tunnelling is used, this is the IP in UDP. When Mobile IP UDP tunnelling is used, this is the
default encapsulation type. Any home agent and mobile node default encapsulation type. Any home agent and mobile node
that implements Mobile IP UDP tunnelling MUST implement this that implements Mobile IP UDP tunnelling MUST implement this
encapsulation type. encapsulation type.
GRE in UDP. If the 'G' bit is set in a registration request and GRE in UDP. If the 'G' bit is set in a registration request and
the Encapsulation field is zero, the mobile node requests that the Encapsulation field is zero, the mobile node requests that
skipping to change at page 15, line 17 skipping to change at page 15, line 17
ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation
unavailable" defined in Section 3.5. On receipt of this error, the unavailable" defined in Section 3.5. On receipt of this error, the
mobile node MAY choose to send a new Registration Request with mobile node MAY choose to send a new Registration Request with
different requirements on MIP UDP tunnelling encapsulation. different requirements on MIP UDP tunnelling encapsulation.
4.2 Encapsulating IP Headers in UDP 4.2 Encapsulating IP Headers in UDP
MIP IP-in-UDP tunnelling, or UDP tunnelling for short, is done in a 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 manner analogous to that described for IP-in-IP tunnelling in RFC
2003 [5], with the exception of the addition of an UDP header [1] and 2003 [5], with the exception of the addition of an UDP header [1] and
MIP Message header [10] between the outer and inner IP header. MIP Message header [11] between the outer and inner IP header.
Mobile IP Registration Requests and Registration Replies are already Mobile IP Registration Requests and Registration Replies are already
in the form of UDP messages, and SHALL NOT be tunnelled even when MIP in the form of UDP messages, and SHALL NOT be tunnelled even when MIP
IP-in-UDP tunnelling is in force. IP-in-UDP tunnelling is in force.
To encapsulate an IP datagram using MIP IP-in-UDP encapsulation, an 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 outer IP header [2], UDP header [1] and MIP Message header [11] is
inserted before the datagram's existing IP header, as follows: inserted before the datagram's existing IP header, as follows:
+---------------------------+ +---------------------------+
| | | |
| Outer IP Header | | Outer IP Header |
+---------------------------+ +---------------------------+
| | | |
| UDP Header | | UDP Header |
+---------------------------+ +---------------------------+
| MIP Tunnel Data | | MIP Tunnel Data |
skipping to change at page 16, line 14 skipping to change at page 16, line 14
tunnelling is being done as part of forwarding the datagram as noted tunnelling is being done as part of forwarding the datagram as noted
in RFC 2003 [5], and remains unchanged during its delivery to the in RFC 2003 [5], and remains unchanged during its delivery to the
tunnel exit point. No change to IP options in the inner header tunnel exit point. No change to IP options in the inner header
occurs during delivery of the encapsulated datagram through the occurs during delivery of the encapsulated datagram through the
tunnel. Note that the security options of the inner IP header MAY tunnel. Note that the security options of the inner IP header MAY
affect the choice of security options for the encapsulating (outer) affect the choice of security options for the encapsulating (outer)
IP header. IP header.
Minimal Encapsulation and GRE encapsulation is done in an analogous Minimal Encapsulation and GRE encapsulation is done in an analogous
manner, following RFC 2004 [6] for Minimal Encapsulation and RFC 2784 manner, following RFC 2004 [6] for Minimal Encapsulation and RFC 2784
[8] for GRE Encapsulation, but using outer IP, UDP and MIP headers in [9] for GRE Encapsulation, but using outer IP, UDP and MIP headers in
place of the outer IP header. place of the outer IP header.
All other provisions and requirements of RFC 2003 [5] and RFC 3024 All other provisions and requirements of RFC 2003 [5] and RFC 3024
[9] are in force, except in one respect, as covered in Packet [10] are in force, except in one respect, as covered in Packet
Fragmentation (Section 4.8). Fragmentation (Section 4.8).
4.3 Decapsulation 4.3 Decapsulation
Before decapsulation is actually done, the decapsulating node MUST Before decapsulation is actually done, the decapsulating node MUST
verify that the outer IP addresses and UDP port numbers exactly match verify that the outer IP addresses and UDP port numbers exactly match
the values used for the tunnel, with the exception of tunnels that 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 are "half bound" (as described in Section 4.11) where the source UDP
port can change. port can change.
skipping to change at page 16, line 41 skipping to change at page 16, line 41
packet which is forwarded as is. packet which is forwarded as is.
Minimal IP encapsulation is processed by the receiver conceptually as Minimal IP encapsulation is processed by the receiver conceptually as
follows. First, the UDP and the Mobile IP headers are removed from 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 the packet, and the Protocol field of the IP header replaced with the
Next Header field in the MIP Tunnel Data header. Second, the Next Header field in the MIP Tunnel Data header. Second, the
remaining IP header total length and checksum are adjusted to match remaining IP header total length and checksum are adjusted to match
the stripped packet. Third, ordinary minimal IP encapsulation the stripped packet. Third, ordinary minimal IP encapsulation
processing is done. processing is done.
GRE encapsulated traffic is processed according to RFC 2784 [8] and GRE encapsulated traffic is processed according to RFC 2784 [9] and
RFC 1701 [3], with the delivery header consisting of the outer IP, RFC 1701 [3], with the delivery header consisting of the outer IP,
UDP and MIP headers. UDP and MIP headers.
4.4 Mobile Node Considerations 4.4 Mobile Node Considerations
The UDP Tunnel Request Extension MAY be used in a Mobile IP The UDP Tunnel Request Extension MAY be used in a Mobile IP
Registration Request from the mobile node to the home agent when the 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 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- by the mobile node when it is registering with a foreign agent care-
of address. of address.
The purpose of this extension is to indicate to the home agent that 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 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 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 NAPT. It thus functions as a conditional solicitation for the use of
MIP UDP tunnelling. MIP UDP tunnelling.
As per Section 3.2 and 3.6.1.3 of RFC 3344 [10], the mobile node MUST As per Section 3.2 and 3.6.1.3 of RFC 3344 [11], the mobile node MUST
place this Extension before the Mobile-Home Authentication Extension place this Extension before the Mobile-Home Authentication Extension
in registration messages, so that it is covered by the Mobile-Home in registration messages, so that it is covered by the Mobile-Home
Authentication Extension. Authentication Extension.
If the mobile node includes the UDP Tunnel Request extension in a If the mobile node includes the UDP Tunnel Request extension in a
registration request, but receives a registration reply without a UDP registration request, but receives a registration reply without a UDP
Tunnel Reply extension, it MUST assume that the HA does not Tunnel Reply extension, it MUST assume that the HA does not
understand this extension, and it MUST NOT use UDP tunnelling. If understand this extension, and it MUST NOT use UDP tunnelling. If
the mobile node is in fact behind a NAT, the registration may then the mobile node is in fact behind a NAT, the registration may then
succeed, but traffic will not be able to traverse the NAT. succeed, but traffic will not be able to traverse the NAT.
skipping to change at page 18, line 25 skipping to change at page 18, line 25
or NAPT. It thus functions as a conditional solicitation for the use or NAPT. It thus functions as a conditional solicitation for the use
of MIP UDP tunnelling. of MIP UDP tunnelling.
A foreign agent which requires the mobile node to register through a A foreign agent which requires the mobile node to register through a
foreign agent by setting the 'R' bit in the agent advertisement, MUST foreign agent by setting the 'R' bit in the agent advertisement, MUST
NOT add the UDP Tunnel Request Extension when forwarding a NOT add the UDP Tunnel Request Extension when forwarding a
registration request which uses a co-located care-of address, as this 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 will lead to a UDP tunnel being set up from the home agent to the
foreign agent instead of to the mobile node. foreign agent instead of to the mobile node.
As per Section 3.2 and 3.7.2.2 of RFC 3344 [10], the foreign agent As per Section 3.2 and 3.7.2.2 of RFC 3344 [11], the foreign agent
when using this extension MUST place it after the Mobile-Home when using this extension MUST place it after the Mobile-Home
Authentication Extension in registration messages. If the foreign Authentication Extension in registration messages. If the foreign
agent shares a mobility security association with the home agent and agent shares a mobility security association with the home agent and
therefore appends a Foreign-Home Authentication Extension, the UDP therefore appends a Foreign-Home Authentication Extension, the UDP
Tunnel Request Extension MUST be placed before the Foreign-Home Tunnel Request Extension MUST be placed before the Foreign-Home
Authentication Extension. Authentication Extension.
As the home agent detects the presence of a NAT in the path between 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 the sender and itself by seeing a mismatch between the IP source
address and the care-of address given in the registration request, it address and the care-of address given in the registration request, it
skipping to change at page 22, line 28 skipping to change at page 22, line 28
- When using simultaneous bindings, each binding may have a - When using simultaneous bindings, each binding may have a
different type (i.e. UDP tunnelling bindings may be mixed with different type (i.e. UDP tunnelling bindings may be mixed with
non-UDP tunnelling bindings). non-UDP tunnelling bindings).
- Tunnelling is only allowed for the duration of the binding - Tunnelling is only allowed for the duration of the binding
lifetime. lifetime.
4.8 Packet fragmentation 4.8 Packet fragmentation
From RFC 3022 [13]: From RFC 3022 [14]:
"Translation of outbound TCP/UDP fragments (i.e., those originating "Translation of outbound TCP/UDP fragments (i.e., those originating
from private hosts) in NAPT set-up are doomed to fail. The reason is 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 as follows. Only the first fragment contains the TCP/UDP header that
would be necessary to associate the packet to a session for would be necessary to associate the packet to a session for
translation purposes. Subsequent fragments do not contain TCP/UDP translation purposes. Subsequent fragments do not contain TCP/UDP
port information, but simply carry the same fragmentation identifier port information, but simply carry the same fragmentation identifier
specified in the first fragment. Say, two private hosts originated specified in the first fragment. Say, two private hosts originated
fragmented TCP/UDP packets to the same destination host. And, they fragmented TCP/UDP packets to the same destination host. And, they
happened to use the same fragmentation identifier. When the target happened to use the same fragmentation identifier. When the target
skipping to change at page 23, line 19 skipping to change at page 23, line 19
the UDP header) will be allowed to pass from the home agent out the UDP header) will be allowed to pass from the home agent out
through the firewall. through the firewall.
For this reason, the home agent SHOULD do packet fragmentation before For this reason, the home agent SHOULD do packet fragmentation before
it does MIP UDP encapsulation. it does MIP UDP encapsulation.
4.9 Tunnel Keepalive 4.9 Tunnel Keepalive
As the existence of the bi-directional UDP tunnel through the NAT is As the existence of the bi-directional UDP tunnel through the NAT is
dependent on the NAT keeping state information associated with a dependent on the NAT keeping state information associated with a
session, as described in RFC 2663 [12], and as the NAT may decide session, as described in RFC 2663 [13], and as the NAT may decide
that the session has terminated after a certain time, keepalive that the session has terminated after a certain time, keepalive
messages may be needed to keep the tunnel open. The keepalives messages may be needed to keep the tunnel open. The keepalives
should be sent more often than the timeout value used by the NAT. 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 This timeout may be assumed to be a couple of minutes, according to
RFC 2663 [12], but it is conceivable that shorter timeouts may exist RFC 2663 [13], but it is conceivable that shorter timeouts may exist
in some NATs. in some NATs.
For this reason the extension used to set up the UDP tunnel has the For this reason the extension used to set up the UDP tunnel has the
option of setting the keepalive message interval to another value option of setting the keepalive message interval to another value
than the default value, see Section 3.2. than the default value, see Section 3.2.
The keepalive message sent MUST consist of a properly UDP The keepalive message sent MUST consist of a properly UDP
encapsulated ICMP echo request directed to the home agent. encapsulated ICMP echo request directed to the home agent.
For each mobility binding which has UDP tunnelling established, the For each mobility binding which has UDP tunnelling established, the
skipping to change at page 27, line 10 skipping to change at page 27, line 10
explicitly address this issue. The potential traffic blackout caused explicitly address this issue. The potential traffic blackout caused
by this situation may be limited by ensuring that the mobility by this situation may be limited by ensuring that the mobility
binding lifetime is short enough; the re-registration caused by binding lifetime is short enough; the re-registration caused by
expiration of the mobility binding fixes the problem (see Section expiration of the mobility binding fixes the problem (see Section
5.2). 5.2).
5.2 Mobility Binding Lifetime 5.2 Mobility Binding Lifetime
When responding to a registration request with a registration reply, When responding to a registration request with a registration reply,
the home agent is allowed to decrease the lifetime indicated in the the home agent is allowed to decrease the lifetime indicated in the
registration request, as covered in RFC 3344 [10]. When using UDP registration request, as covered in RFC 3344 [11]. When using UDP
tunnelling, there are some cases where a short lifetime is tunnelling, there are some cases where a short lifetime is
beneficial. beneficial.
First, if the NAT mapping maintained by the NAT device is dropped, a First, if the NAT mapping maintained by the NAT device is dropped, a
connection blackout will arise. New packets sent by the mobile node connection blackout will arise. New packets sent by the mobile node
(or the foreign agent) will establish a new NAT mapping, which the (or the foreign agent) will establish a new NAT mapping, which the
home agent will not recognize until a new mobility binding is home agent will not recognize until a new mobility binding is
established by a new registration request. established by a new registration request.
A second case where a short lifetime is useful is related to the A second case where a short lifetime is useful is related to the
skipping to change at page 30, line 13 skipping to change at page 30, line 13
tunnelling using the described mechanism will also work. tunnelling using the described mechanism will also work.
7. UNSAF Considerations 7. UNSAF Considerations
The mechanism described in this document is not an "UNilateral Self- The mechanism described in this document is not an "UNilateral Self-
Address Fixing" (UNSAF) mechanism. Although the mobile node makes no Address Fixing" (UNSAF) mechanism. Although the mobile node makes no
attempt to determine or use the NAT translated address, the mobile attempt to determine or use the NAT translated address, the mobile
node through the registration process does attempt to keep the NAT node through the registration process does attempt to keep the NAT
mapping alive through refresh messages. This section attempts to mapping alive through refresh messages. This section attempts to
address issues that may be raised through this usage through the address issues that may be raised through this usage through the
framework of the unsaf considerations IAB document [14]. framework of the unsaf considerations IAB document [15].
1. Precise definition. 1. Precise definition.
This proposal extends the Mobile IP v4 registration process to This proposal extends the Mobile IP v4 registration process to
work across intervening NATs. The Home Agent detects the work across intervening NATs. The Home Agent detects the
presence of the NAT by examining the source address in the presence of the NAT by examining the source address in the
packet header and comparing it with the address contained in packet header and comparing it with the address contained in
the registration message. the registration message.
The NAT address and port detected by the home agent are not The NAT address and port detected by the home agent are not
exported or communicated to any other node anywhere. exported or communicated to any other node anywhere.
skipping to change at page 31, line 34 skipping to change at page 31, line 34
With respect to the base Mobile IP specification, the impact With respect to the base Mobile IP specification, the impact
of this document is that an increased frequency of of this document is that an increased frequency of
registration requests is recommended from a security registration requests is recommended from a security
perspective when the NAT traversal mechanism is used. perspective when the NAT traversal mechanism is used.
8. IANA Considerations 8. IANA Considerations
The numbers for the extensions defined in this I-D should be taken The numbers for the extensions defined in this I-D should be taken
from the numbering space defined for Mobile IP messages, registration from the numbering space defined for Mobile IP messages, registration
extensions and error codes defined in RFC 3344 [10]. This draft extensions and error codes defined in RFC 3344 [11]. This draft
proposes one new message, two new extensions and a new error code proposes one new message, two new extensions and a new error code
that require type numbers and error code value to be assigned by that require type numbers and error code value to be assigned by
IANA. The two new extensions also introduce two new sub-type IANA. The two new extensions also introduce two new sub-type
numbering spaces to be managed by IANA. numbering spaces to be managed by IANA.
Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request
Extension. The type number for this extension should be of type Extension. The type number for this extension should be of type
skippable. This extension introduces a new sub-type numbering space skippable. This extension introduces a new sub-type numbering space
where the value 0 has been assigned to this extension. where the value 0 has been assigned to this extension. Approval of
new Tunnel Request Extension sub-type numbers is subject to Expert
Review, and a specification is required [8].
Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply
Extension . The type value for this extension should be of type non- Extension . The type value for this extension should be of type non-
skippable. This extension introduces a new sub-type numbering space skippable. This extension introduces a new sub-type numbering space
where the value 0 has been assigned to this extension. where the value 0 has been assigned to this extension. Approval of
new Tunnel Reply Extension sub-type numbers is subject to Expert
Review, and a specification is required [8].
Section 3.3 defines a new Mobile IP message, the Tunnel Data message. Section 3.3 defines a new Mobile IP message, the Tunnel Data message.
The type value for this message should be taken from the numbering The type value for this message should be taken from the numbering
space defined for Mobile IP messages. space defined for Mobile IP messages.
Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL: Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL:
"Requested UDP tunnel encapsulation unavailable", from the numbering "Requested UDP tunnel encapsulation unavailable", from the numbering
space for values defined for use with the Code field of Mobile IP space for values defined for use with the Code field of Mobile IP
Registration Reply Messages. This code should be taken from the Registration Reply Messages. This code should be taken from the
subset "Error Codes from the Home Agent". subset "Error Codes from the Home Agent".
skipping to change at page 33, line 26 skipping to change at page 33, line 29
[5] Perkins, C., "IP Encapsulation within IP", RFC 2003, October [5] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996. 1996.
[6] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, [6] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996. October 1996.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[8] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[9] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[9] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC [10] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC
3024, January 2001. 3024, January 2001.
[10] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August [11] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002. 2002.
Informative References Informative References
[11] Atkinson, R., "IP Authentication Header", RFC 1826, August [12] Atkinson, R., "IP Authentication Header", RFC 1826, August
1995. 1995.
[12] Srisuresh, P. and M. Holdrege, "IP Network Address Translator [13] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999. (NAT) Terminology and Considerations", RFC 2663, August 1999.
[13] Srisuresh, P. and K. Egevang, "Traditional IP Network Address [14] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001. Translator (Traditional NAT)", RFC 3022, January 2001.
[14] Daigle, L., "IAB Considerations for UNilateral Self-Address [15] Daigle, L., "IAB Considerations for UNilateral Self-Address
Fixing (UNSAF)", draft-iab-unsaf-considerations-01 (work in Fixing (UNSAF)", draft-iab-unsaf-considerations-01 (work in
progress), February 2002. progress), February 2002.
[15] Levkowetz, H., "NAT Traversal for Mobile IP using UDP [16] Levkowetz, H., "NAT Traversal for Mobile IP using UDP
Tunnelling", draft-levkowetz-mobileip-nat-tunnel-00 (work in Tunnelling", draft-levkowetz-mobileip-nat-tunnel-00 (work in
progress), July 201. progress), July 201.
Authors' Addresses Authors' Addresses
O. Henrik Levkowetz O. Henrik Levkowetz
ipUnplugged AB ipUnplugged AB
Arenavagen 33 Arenavagen 33
Stockholm S-121 28 Stockholm S-121 28
SWEDEN SWEDEN
 End of changes. 45 change blocks. 
45 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/