Internet-Draft O. H. Levkowetz
Expires: January 1, 2002 J. Forslow
H. Sjostrand
ipUnplugged
July 3, 2001
NAT Traversal for Mobile IP using UDP Tunnelling
<draft-levkowetz-mobileip-nat-tunnel-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 January 1, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Mobile IP is now being deployed, providing connectivity to mobile
users. This is happening well ahead of the widespread use of IPv6,
which may not have been expected at the time when the Mobile IP
standard was originally formulated. At the same time, networks with
private address spaces are proliferating, using NAT devices to reach
the public internet. Today NATs are widely deployed in home
gateways, as well as in other locations likely to be used by mobile
users, such as hotels. The result is that MIP-NAT incompatibility
issues have become a major barrier to deployment of Mobile IP in one
of its principal uses. This draft describes a known incompatibility
between NAT and Mobile IP, and also describes a possible solution
using Mobile IP's vendor specific extensions.
Levkowetz, et. al. Expires January 1, 2002 [Page 1]
Internet-Draft NAT Traversal for MIP July 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Problem description . . . . . . . . . . . . . . . . . . . . 3
1.3 One possible solution . . . . . . . . . . . . . . . . . . . 5
2. ipUnplugged UDP Tunnelling . . . . . . . . . . . . . . . . . 6
2.1 Basic Message Sequence . . . . . . . . . . . . . . . . . . . 6
2.2 Tunnel Keepalive . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Tunnelling Termination . . . . . . . . . . . . . . . . . . . 7
2.3.1 Mobile Node . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Home Agent . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Extension Formats . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 Vendor Specific Extensions . . . . . . . . . . . . . . . . . 8
2.4.2 UDP Port Request . . . . . . . . . . . . . . . . . . . . . . 8
2.4.3 UDP Port Request Extension Format . . . . . . . . . . . . . 9
2.4.4 UDP Port Assignment . . . . . . . . . . . . . . . . . . . . 9
2.4.5 UDP Port Assignment Extension Format . . . . . . . . . . . . 10
3. IP-in-UDP Tunnelling . . . . . . . . . . . . . . . . . . . . 10
4. Advantages . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . 12
5.1 Firewall Considerations . . . . . . . . . . . . . . . . . . 13
6. Intellectual property rights . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
Levkowetz, et. al. Expires January 1, 2002 [Page 2]
Internet-Draft NAT Traversal for MIP July 2001
1. Introduction
Mobile IP is expected to become of great benefit as a technology for
remote access to mobile-VPNs by allowing the traversal of one or
more exterior domains. However, it is likely that the traffic and
mobile IP signalling in a remote mobile-VPN access scenario will
have to traverse a network address port translation (NAPT) [RFC
2663] at one or more inter-domain borders. The current mobile IP RFC
2002 cannot survive such a NAPT traversal.
The NAPT traversal scenario is expected to be particularly common in
the broadband access deployment scenario to residential homes, as
many broadband access providers only allocate a private IP address
to each house/apartment. Furthermore, it is unlikely that the NAPT
in the broadband access operator's network can be controlled by the
customer/corporate IT-manager in any way. This may be acerbated by
the existence of small private NAPT devices inside residential
broadband access routers, supporting multiple IP nodes in a private
residential address space.
The following paper describes a possible solution to solve NAPT
traversal for mobile IP. The solution makes this possible by way of
using the co-located care-of option in a mobile node, enhancements
inside the home agent and an extra UDP header in what would
otherwise be regular IP-in-IP tunnelled payload data.
1.1 Terminology
Forward Tunnel
A tunnel that shuttles 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.
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
The major incompatibility between MIP and NATs occurs when the
Mobile Node (MN) acquires a co-located care-of address which is a
private address. RFC 2002[6], in describing the use of co-located
care-of addresses, states that
"The mode of using a co-located care-of address has the
advantage that it allows a mobile node to function without a
foreign agent, for example, in networks that have not yet
deployed a foreign agent. It does, however, place additional
Levkowetz, et. al. Expires January 1, 2002 [Page 3]
Internet-Draft NAT Traversal for MIP July 2001
burden on the IPv4 address space because it requires a pool of
addresses within the foreign network to be made available to
visiting mobile nodes. It is difficult to efficiently maintain
pools of addresses for each subnet that may permit mobile
nodes to visit."
However, in most cases involving networks using private addresses
and NATs, this option will not be available, and for some time to
come many visited networks will not have a foreign agent present. We
then get the following situation:
| +------+ Public
| 10.0.4.3 | | Internet
|------------| CN | |
| | | |
| +------+ |
| |
| +------+ |
| 10.0.4.1 | | 204.8.8.2 |
|------------| HA |--------------------------------------|
| | | |
| +------+ |
| |
Home |
Network |
|
| +------+ |
| | FW | 204.68.9.2 |
| |-------| |-------------|
| +------+ | | NAPT | |
| | R | | +------+ |
|-----------| |-------| |
| | DHCP | | |
| +------+ | |
| |
| |
| |
| +------+ |
| 10.0.0.2 | | CCoA = 10.0.0.2 |
|-----------| MN | |
| | | Home |
| +------+ Addr. = 10.0.4.15 |
| |
Foreign
Network
Figure 1
Fig. 1 shows a scenario where the mobile node MN is hidden behind a
network address port translation (NAPT) in the foreign network. The
Levkowetz, et. al. Expires January 1, 2002 [Page 4]
Internet-Draft NAT Traversal for MIP July 2001
home agent is considered having a public (unique) IP address towards
the Internet. A residential broadband access network is shown as the
foreign network and is allocating a private IP address to each
house/apartment. The mobile users connect to the home agent HA at
the office or the internet service provider (seen as the home
network).
The mobile node will request a temporary care-of address from the
local router R and its DHCP server in the visited network. In fig.
1, the care-of address is set to 10.0.0.2 -- an address that is
allocated from within the address realm in the visited network. In
addition, the mobile node has a stable address set to 10.0.4.15 --
an address that is allocated from within the address realm of the
home network. The details of the registration request procedure will
be explained below; however, for now it is enough to know that the
registration will survive the traversal of the firewall and its NAPT
when the firewall changes the source IP address to its own public
address, i.e. 204.68.9.2, and allocates a new UDP source port.
1.3 One possible solution
The home agent will discover that a NAPT traversal has occurred by
comparing the source IP address 204.68.9.2 and the care-of address
10.0.0.2. The mobile IP tunnel is then modified to contain a UDP
header as well, in order to facilitate traversal of the NAPT with
payload datagrams between the mobile node and the correspondent node
CN (10.0.4.3). Note also that the source IP header of the
registration request as received by the home agent, i.e. 204.68.9.2,
will be used as destination IP address for the outer IP header in
the mobile IP tunnel as seen from the home agent, instead of the
care-of address, i.e. 10.0.0.2, that is normally applied.
There are two differences in the way payload transfer would be
performed when a NAPT is present in the path. First of all the
payload datagrams to be sent through the mobile IP tunnel would be
encapsulated with an outer IP and UDP header, instead of only an IP
header. This will ensure that the datagrams will pass through the
NAPT and allow the NAPT to use the UDP source port to create a
unique id for the payload session in order to be able to map back to
the correct IP address and source UDP port on the inside of the
firewall when traffic is coming back from the home agent. The second
difference is that the home agent is applying the source IP header
of the registration request, i.e. the IP address of the NAPT
204.68.9.2, as the destination IP address also for datagrams
destined for the mobile node 3. This is in contrast with the current
IETF standard RFC 2002[6], where the home agent is using the care-of
address as the destination IP address.
Levkowetz, et. al. Expires January 1, 2002 [Page 5]
Internet-Draft NAT Traversal for MIP July 2001
2. ipUnplugged UDP Tunnelling
This section describes a vendor-specific implementation of the
solution described above. Briefly, the mobile node may use a vendor
specific extension in its Registration Request to indicate that it
would like to use IP in UDP Tunnelling instead of standard IP in IP
Tunnelling[7] if the home agent sees that the Registration Request
seems to have passed trough a NAPT. The home agent may then do a UDP
port assignment and send a registration reply with a vendor
extension indicating which port to use. IP in UDP Tunnelling will
then be used in both directions.
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 inclusion of specific extensions in the initial Mobile IP
registration request and reply exchange. Thereafter, any traffic
between the mobile node and the home agent are sent trough the UDP
tunnel.
mobile node NAPT home agent
| | |
| | |
| Registration | |
| Request with | |
|-----------------///--------------->>|
| UDP Port Request | |
| | +
| | | IP Source and
| | | CCoa address
| | | discrepancy
| | | seen
| | Registration +
| | Reply with |
|<<---------------///-----------------|
| | UDP Port Assignm.|
| | |
| UDP keepalive | |
|-----------------///--------------->>|
| | |
| | |
| UDP tunnelled pkg| |
|=================///===============>>|
| | UDP tunnelled pkg|
|<<===============///=================|
. . .
. . .
. . .
Levkowetz, et. al. Expires January 1, 2002 [Page 6]
Internet-Draft NAT Traversal for MIP July 2001
2.2 Tunnel Keepalive
As the existence of the bi-directional UDP tunnel through the NAPT
is dependent on the NAPT keeping state information associated with a
session, as described in RFC 2663[10], and as the NAPT 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 NAPT.
This timeout should be 4 minutes, according to RFC 2663[10] and as
explained in RFC 793[3], but it is conceivable that shorter timeouts
may exist in some NAPTs.
The keepalive messages SHALL consist simply of a UDP message with
zero length payload, and otherwise conforming to Section 3, and
SHALL be sent by the mobile node at least as often as every 4
minutes. The frequency of keepalive messages MAY be configurable
within this limitation.
The first keepalive message SHALL be sent by the mobile node
immediately after the receipt of the Registration Reply with an UDP
Port Assignment Extension (Section 2.4.4), in order to open the NAPT
up to incoming tunnelled packets.
2.3 Tunnelling Termination
2.3.1 Mobile Node
Whenever the mobile node detects a change in its network
connectivity and initiates a registration, according to RFC 2002[6]
section 3.6, it MUST stop using any UDP Tunnelling according to this
paper, and return to standard Mobile IP operation as covered by RFC
2002[6]. If UDP Tunnelling is needed, it MUST be re-established
without any state kept from earlier Tunnelling, using the extensions
described in Section 2.4.2 and Section 2.4.4 in this document.
2.3.2 Home Agent
Whenever the home agent receives a Registration Request from a
mobile node with a new care-of address, it MUST stop using any UDP
Tunnelling according to this paper. If UDP Tunnelling is needed
under the new registration, it MUST be re-established without any
state kept from earlier Tunnelling.
This does not apply when the mobile node is re-registering due to
the upcoming expiration of the lifetime of its registration, keeping
the same care-of address. In this case, termination and
re-establishment of Tunnelling SHOULD NOT be done.
Levkowetz, et. al. Expires January 1, 2002 [Page 7]
Internet-Draft NAT Traversal for MIP July 2001
2.4 Extension Formats
2.4.1 Vendor Specific Extensions
All Mobile IP extensions described in this paper are Vendor Specific
Extensions[11], with the SMI Network Management Private Enterprise
Code of ipUnplugged, which is 5925.
As per Section 3.2 and 3.6.1.3 of [6], the sender MUST include these
Extensions before the Mobile-Home Authentication Extension in
registration messages, so that they are covered by the Mobile-Home
Authentication Extension.
2.4.2 UDP Port Request
This 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. It is
not defined for use by a foreign agent.
The purpose of this extension is to indicate to the home agent that
the mobile node is able to accept IP-UDP Tunnelling if the home
agent has an indication that the mobile node resides behind a NAPT.
It thus functions as a conditional solicitation for the assignment
of a UDP port for the home agent endpoint of the IP-UDP tunnel.
The home agent SHALL 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 NAPT. If the
Registration Request also contains the UDP Port Request extension
defined here, the home agent SHALL respond with a registration reply
containing the UDP Port Assignment extension described in Section
2.4.4.
If the home agent receives a Registration Request with matching
source IP address and co-located care-of address which contains a
UDP Port Request Extension, the home agent SHALL NOT respond with a
Registration Reply containing a UDP Port Assignment (Section 2.4.4).
The mobile node MAY propose a port number, by setting the 'Proposed
UDP Port' field to a value different from zero, and the home agent
MAY accept this proposed port.
This extension MAY also be used in a Registration Request during
re-registering if an earlier assigned UDP port (Section 2.4.4) turns
out to be blocked and unusable.
If the home agent receives a UDP port request when it already has an
Levkowetz, et. al. Expires January 1, 2002 [Page 8]
Internet-Draft NAT Traversal for MIP July 2001
UDP port association for the sending mobile node at the source IP
address, it SHALL interpret this as an indication that the prior UDP
port assignment is or has become unusable, and SHOULD assign another
port for the mobile node to use.
The mobile node MUST NOT request alternative forms of encapsulation
by setting the 'M' bit and/or the 'G' bit of a Mobile IP
registration request together with this extension.
The well-known Mobile IP port number 434 SHALL NOT be used for the
UDP tunnel, neither in port requests or port assignments. Use of
this port would require a mechanism to multiplex regular Mobile IP
control traffic according to RFC 2002[6] with the tunnel traffic.
This document does not provide any mechanisms to do so.
2.4.3 UDP Port Request Extension Format
This extension is a Normal Vendor/Organization Specific Extension
(NVSE). 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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-NVSE-Type | Proposed UDP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type NVSE-TYPE-NUMBER = 134
Reserved Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
Length Length in bytes of this extension, not
including the Type and Length bytes.
Vendor/Org-ID The SMI Network Management Private Enterprise
Code of ipUnplugged = 5925
Vendor-NVSE-Type UDP-Port-Request = 17
Proposed UDP Port The mobile node may propose a port number to
use for the Tunnelling, but the home agent is
not bound to use this.
2.4.4 UDP Port Assignment
This extension MAY be used in a Mobile IP Registration Reply from
the home agent to the mobile node.
The purpose of this extension is to indicate that the home agent
Levkowetz, et. al. Expires January 1, 2002 [Page 9]
Internet-Draft NAT Traversal for MIP July 2001
accepts the use of IP-UDP Tunnelling, and to inform the mobile node
of the UDP port number of the home agent endpoint of the tunnel. On
receipt of this message, the mobile node MUST use IP-UDP Tunnelling
when sending IP packets to the home agent, and it MUST expect and
accept IP-UDP tunnelled packets from the home agent.
The mobile node MUST use the assigned UDP port number for the IP-UDP
tunnel for the lifetime of the mobility binding, unless explicitly
reassigned. Reassignment SHALL ONLY be done on request, during
re-registration, as described above.
This extension is added to a Mobile IP Registration Reply by the
home agent when it has received and accepted a UDP Port Request
(Section 2.4.2) from a mobile node.
2.4.5 UDP Port Assignment Extension Format
This extension is a Critical Vendor/Organization Specific Extension
(CVSE). 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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor/Org-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-NVSE-Type | Assigned UDP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type CVSE-TYPE-NUMBER = 38
Reserved Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
Length Length in bytes of this extension, not
including the Type and Length fields.
Vendor/Org-ID The SMI Network Management Private Enterprise
Code of ipUnplugged = 5925
Vendor-NVSE-Type UDP-Port-Assignment = 18
Assigned UDP Port The UDP Port to be used as the home agent
endpoint of the UDP tunnel.
3. IP-in-UDP Tunnelling
IP-in-UDP Tunnelling, or UDP Tunnelling for short, is done
completely analogous to RFC 2003[7], with the sole exception of the
addition of an UDP header[1] between the outer and inner IP header.
Mobile IP Registration Requests and Registration Replies are already
Levkowetz, et. al. Expires January 1, 2002 [Page 10]
Internet-Draft NAT Traversal for MIP July 2001
in the form of UDP messages, and SHALL NOT be tunnelled even when
IP-in-UDP Tunnelling is in force.
To encapsulate an IP datagram using IP in UDP encapsulation, an
outer IP header[2] and UDP header[1] is inserted before the
datagram's existing IP header, as follows:
+---------------------------+
| |
| Outer IP Header |
| |
+---------------------------+
| |
| UDP 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 recipient of
the datagram, respectively. The inner IP header is not changed by
the encapsulator, except to decrement the TTL as noted in RFC
2003[7], 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.
All other provisions and requirements of RFC 2003[7] are in force.
4. Advantages
One advantage with this mechanism for handling NAT devices and
private addressing is that the mechanism is backwards compatible
with RFC2002[6] and that minimal new procedures are introduced. This
proposal uses no new control messages and introduces no additional
Levkowetz, et. al. Expires January 1, 2002 [Page 11]
Internet-Draft NAT Traversal for MIP July 2001
signalling latency.
Additionally this proposal does not require any specific port number
to be used. This is an advantage since there are existing firewalls
that might not allow specific ports. The configuration and
negotiation possibility allows a flexible way to get through these
firewalls.
This mechanism does not only solves the Mobile IP protocol NAPT
traversal problem, but also other protocols that will run above it
will benefit. One protocol of particular interest in mobile-VPNs is
IPSec. If IKE and IPSec runs on top of Mobile IP, these protocols
will not only be capable of surviving mobile node movements between
subnets, but also survive NAPT traversal without modifications.
Mobile IP is much more suited for handling the NAPT traversal than
e.g. IKE[9] with its requirement of a specific port number (500) in
both the source and destination field. This proposal allows not
only for ESP to be used totally without modifications, but also AH
to protect against source address spoofing if desired[12]. Also,
there is no limitation between which entities the security
associations may be established, the SA's could be set up between
the MN and the HA, as well as between the MN and the CN.
Most importantly, this mechanism does not require change of,
interaction with or preconditions on the NAT device itself - which
would be totally impracticable. The NAT device is typically not
controllable by the customer/corporate IT-manager in any way. Many
hotel Internet connections are using NAT, airport & wireless
services in public areas use NAT. Even some ISP use NAT to connect
their clients to the internet, especially in Europe. None of these
NAT devices will permit any control or interaction from a host
device in a near future.
One alternative solution that could be considered is to create a
HTTP session between the Home Agent and the mobile node and then
tunnel Mobile IP and IP payload packets on top. The disadvantages of
introducing HTTP into the solution is, not only extra overhead, but
also its restrictions on real time applications and less optimal
mobile node implementations. Another less advantageous alternative
is to run Mobile IP over TCP. This would have negative effects on
real time applications, as well as the added vulnerability for
spoofed TCP connection reset attacks.
5. Security Considerations
The authors do not think this mechanism exposes any security
vulnerabilities above those of using IP in IP encapsulation. There
are less security issues to open up the HA access rules for a
specific UDP port than to allow all IP-IP encapsulation packets in.
Levkowetz, et. al. Expires January 1, 2002 [Page 12]
Internet-Draft NAT Traversal for MIP July 2001
However, if the intermediate network is considered insecure, IPSec
should be used.
An security advantage of this mechanism is that IKE and IPSec (both
ESP and AH), if run on top of Mobile IP, will survive NAPT traversal
without modifications. It could be used transparently both between
the MN and the HA, as well as between the MN and the CN.
5.1 Firewall Considerations
This is not a general firewall traversal mechanism. However, using
IP-in-UDP encapsulation instead of IP-in-IP encapsulation makes it
easier to configure a firewall to allow for the traffic. It's simple
to allow for UPD packets with a predetermined port number. There
could however potentially be an issue with the increasing use of
personal firewalls, which are most often deployed with the default
settings intact. Some well-known, generally open port numbers could
however be used with this proposal, e.g. 80 which is allowed by most
firewalls and not used for other services by most HAs.
6. Intellectual property rights
ipUnplugged has one or more patents or patent applications that may
be relevant to this internet-draft. If this specification is adopted
by IETF and any claims of this or any other ipUnplugged patents are
necessary for practicing 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 to
implement and fully comply with the standard.
7. Acknowledgements
Much of the text in Section 3 has been taken almost verbatim from
RFC 2003, IP Encapsulation within IP[7].
Many thanks to Peter Larsson, Olavi Kumpulianen, ipUnplugged, for
essential contributions.
References
[1] Postel, J., Editor, "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[2] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[3] Postel, J., Editor, "Transmission Control Protocol (TCP)
Specification", STD 7, RFC 793, September 1981.
Levkowetz, et. al. Expires January 1, 2002 [Page 13]
Internet-Draft NAT Traversal for MIP July 2001
[4] Atkinson, R., "IP Authentication Header", RFC 1826, August
1995.
[5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, J. G.
and E. Lear, "Address Allocation for Private Internets", RFC
1918, February 1996.
[6] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October
1996.
[7] Perkins, C., Editor, "IP Encapsulation within IP", RFC 2003,
October 1996.
[8] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[10] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[11] Dommety, G. and K. Leung, "Mobile IP
Vendor/Organization-Specific Extensions", RFC 3115, April 2001.
[12] Aboba, B., "IPsec-NAT Compatibility Requirements",
draft-ietf-ipsec-nat-reqts-00.txt (work in progress), June
2001.
Authors' Addresses
O. Henrik Levkowetz
ipUnplugged AB
Arenavagen 33
Stockholm S-121 28
SWEDEN
Phone: +46 8 725 9513
EMail: henrik@levkowetz.com
Levkowetz, et. al. Expires January 1, 2002 [Page 14]
Internet-Draft NAT Traversal for MIP July 2001
Jan Forslow
ipUnplugged AB
Arenavagen 33
Stockholm S-121 28
SWEDEN
Phone: +46 725 5912
EMail: jan@ipunplugged.com
Hans Sjostrand
ipUnplugged AB
Arenavagen 33
Stockholm S-121 28
SWEDEN
Phone: +46 8 725 5930
EMail: hans@ipunplugged.com
Levkowetz, et. al. Expires January 1, 2002 [Page 15]
Internet-Draft NAT Traversal for MIP 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.
Levkowetz, et. al. Expires January 1, 2002 [Page 16]