Internet DRAFT - draft-huang-mobileip-napt
draft-huang-mobileip-napt
Internet Engineering Task Force Ching-Yang Huang
Internet-Draft Jyh-Cheng Chen
Expires: February 2003 Ming-Chia Jiang
Hong-Wei Lin
National Tsing Hua University
Jen-Chi Liu
Industrial Technology Research Institute
September 2002
Guidelines for Integrating Mobile IP with NAPT
<draft-huang-mobileip-napt-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 February 28, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002) All Rights Reserved.
Abstract
As the number of mobile terminals increases, Mobile IP[1] potentially
could make users roam around the world while also keep their
connection to the Internet uninterruptedly. In the mean time, many
organizations are using NAPT[2] (Network Address Port Translator) to
isolate private network from public realms. The integration of NAPT
with Mobile IP, however, introduces technical issues that must be
NTHU & ITRI Expires February 2003 [Page 1]
Internet Draft Mobile IP Integrates with NAPT September 2002
resolved before they can function together. Although techniques such
as UDP tunneling[3] and reverse tunneling[4] can be utilized to solve
part of the problem, there are still some scenarios which need more
discussion. This document reviews these mechanisms and presents a
guideline for the integration of Mobile IP and NAPT in various
scenarios.
1. Introduction
Mobile IP introduced mobility to mobile users using tunneling
technology, allowing mobile users to take their notebook PC or PDA
roaming around the world without reconfiguring. In the design
principle of Mobile IP, every node is assumed to have an unique IP
address, but many organizations use NAPT and provide private address
in their network that conflicts with this assumption. There had been
many discussions on this topic, eg. Reverse Tunneling, UDP tunneling.
However, the solutions focused on part of the integration and are not
for all scenarios. This document reviews these mechanisms and will
discuss various scenarios and provides a guideline to the integration
of Mobile IP and NAPT.
2. Terminology
NAT (Network Address Translator)
RFC 2663: " Traditional NAT would allow hosts within a private
network to transparently access hosts in the external network, in
most cases. In a traditional NAT, sessions are uni-directional,
outbound from the private network. This is in contrast with Bi-
directional NAT, which permits sessions in both inbound and
outbound directions."
Basic NAT
RFC 2663: "With Basic NAT, a block of external addresses are set
aside for translating addresses of hosts in a private domain as
they originate sessions to the external domain. For packets
outbound from the private network, the source IP address and
related fields such as IP, TCP, UDP and ICMP header checksums are
translated. For inbound packets, the destination IP address and
the checksums as listed above are translated."
NAPT (Network Address Port Translator)
RFC 2663: " NAPT extends the notion of translation one step
further by also translating transport identifier (e.g., TCP and
UDP port numbers, ICMP query identifiers). This allows the
transport identifiers of a number of private hosts to be
NTHU & ITRI Expires February 2003 [Page 2]
Internet Draft Mobile IP Integrates with NAPT September 2002
multiplexed into the transport identifiers of a single external
address. NAPT allows a set of hosts to share a single external
address. Note that NAPT can be combined with Basic NAT so that a
pool of external addresses are used in conjunction with port
translation."
Home NAPT
The NAPT which located in the home network.
Foreign NAPT
The NAPT which located in the foreign network.
UDP Tunneling
NAT traversal for MIP Draft: "In MIP UDP tunnelling, the mobile
node may use an extension (described below) in its Registration
Request to indicate that it is able to use Mobile IP UDP
tunnelling instead of standard Mobile IP tunnelling if the home
agent sees that the Registration Request seems to have passed
through a NAT. The home agent may then send a registration reply
with an extension indicating acceptance (or denial). After assent
from the home agent, MIP UDP tunnelling will be available for use
for both forward and reverse tunnelling. UDP tunnelled packets
sent by the mobile node use the same ports as the registration
request message. In particular, the source port may vary between
new registrations, but remains the same for all tunnelled data and
re-registrations. The destination port is always 434. UDP
tunnelled packets sent by the home agent uses the same ports, but
in reverse."
Reverse Tunneling
RFC 3024: "A mobile node arrives at a foreign network, listens for
agent advertisements and selects a foreign agent that supports
reverse tunnels. It requests this service when it registers
through the selected foreign agent. At this time, and depending
on how the mobile node wishes to deliver packets to the foreign
agent, it also requests either the Direct or the Encapsulating
Delivery Style (section 5).
In the Direct Delivery Style, the mobile node designates the
foreign agent as its default router and proceeds to send packets
directly to the foreign agent, that is, without encapsulation.
The foreign agent intercepts them, and tunnels them to the home
agent.
In the Encapsulating Delivery Style, the mobile node encapsulates
all its outgoing packets to the foreign agent. The foreign agent
decapsulates and re-tunnels them to the home agent, using the
NTHU & ITRI Expires February 2003 [Page 3]
Internet Draft Mobile IP Integrates with NAPT September 2002
foreign agent's care-of address as the entry-point of this new
tunnel."
3. Problem Statement
When Mobile IP runs on private networks will cause the following
problems:
3.1 Unreachable HA
According to NAPT operation, session can only be initiated from the
inside of NAPT. Thus the path is blocked to be single direction in
session initiation stage. Since MN registers its CoA at foreign
network, the registration is initiated from the outside of NAPT. HA
is not reachable from MN.
3.2 Insufficient Translation Information
NAPT translates packet by checking IP address and port numbers. After
encapsulating by tunneling methods defined in Mobile IP, packets are
not compatible with NAPT. NAPT cannot find port numbers, that is,
NAPT cannot translate them properly.
3.3 Identical Home Address
There may be some MNs with identical private home address come to the
same foreign network. If foreign agent mode is used, these MNs will
use FA's IP as CoA. FA will be conflict when it forward packet to
them.
3.4 Handoff Detection
When MN handoffs from a private foreign network to another, the IP
address of FA may be the same as previous one. The change of IP
address of FA is not sufficient for MN to detect the handover.
3.5 Unknown Home NAPT
Another problem similar to problem1 is Unknown Home NAPT. MN uses
private address in both its home network and foreign network. But the
private address is not routable in the Internet. Registration
messages that MN sent will not be sent back to their home network.
4. Integration Requirements
This section lists the requirements correspond to problems listed in
section 3.
NTHU & ITRI Expires February 2003 [Page 4]
Internet Draft Mobile IP Integrates with NAPT September 2002
4.1 There must exist a direct path between MN and HA, so that
registration and data packets can be initiated from the outside of
NAPT.
4.2 Tunneled packets must be compatible with NAPT so that they can be
preceded by NAPT boxes.
4.3 When there are multiple MNs having identical private home address,
FA must uniquely identify each MN and forward packets to them
correctly.
4.4 When MN handoffs between 2 FAs that have identical private address,
MN should know when it have to re-register again.
4.5 MN should provide information about the NAPT in its home network.
5. Leveraging Exist Technologies
In appendix A of Reverse Tunneling, there is a discussion in
Disparate Address Space Support. But NAT is not considered. The I-D
"NAT traversal for MIP" has discussed the integration of NAPT and
MIP. But it only referred the scenario that only foreign network is
private network with NAPT. The case that Home network is also private
with NAPT is not mentioned. But this case will create more problem
than what is solved or discussed in Reverse Tunneling and NAT
traversal for MIP. In [6], the combination of MIP and NAT is
discussed. NAT box referred in this doc is the "Bi-directional NAT
(or) Two-Way NAT" form as described in 4.2 of [2]. We believe that
NAPT is more popular than the "Two-Way NAT"; in next section we will
discuss different scenarios and use techniques currently available to
integrate MIP and NAPT.
6. Scenarios and Considerations
The permutation of Mobile IP components, HA, FA, MN and CN together
with NAPT box may result in various scenarios. The case that CN is
behind NAPT is not considered, because the location of CN will not
effect the mobility of MN even though it is one part of the operation
of Mobile IP. And MN will always be considered and will not take
count into the permutation. Thus we got 4 scenarios of the
permutation. They are:
6.1. No NAPT is present
This is the original Internet, Mobile IP runs normally.
NTHU & ITRI Expires February 2003 [Page 5]
Internet Draft Mobile IP Integrates with NAPT September 2002
6.2. Only Freign Network is Private, FA is Behind NAPT
Foreign network is private:
Foreign Network1 Home Network
--------------+ +-------------
MN4 | | HA MN1
FA -----NAPT----Internet------+ MN2
| / \ | MN3
--------------+ / \ +-------------
/ \
Foreign Network2 / \
--------------+ / \
MN5 | / CN
DHCP--NAPT
|
--------------+
This scenario will cause the "Insufficient Translation Information
problem" and "Handoff Detection problem". I-D "NAT traversal for MIP"
considered this scenario, and provides a solution that really works.
We needs UDP tunneling runs on FA, HA, MN.
6.3. Only Home Network is Private, HA is Behind NAPT
Home network is private:
Foreign Network1 Home Network
--------------+ +-------------
MN4 FA | | MN1
|------Internet-----NAPT--HA MN2
| / \ | MN3
--------------+ / \ +-------------
/ \
Foreign Network2 / \
--------------+ / \
MN5 DHCP | / CN
---'
|
--------------+
This scenario will cause the "Unreachable HA", "Insufficient
Translation Information", "Identical Home Address" and "Unknown Home
NAPT" problems. If foreign network uses co-located mode, every MN get
a co-located CoA which is unique in foreign network, Identical Home
Address problem will be eliminated. There is no solution currently
designed for this scenario.
NTHU & ITRI Expires February 2003 [Page 6]
Internet Draft Mobile IP Integrates with NAPT September 2002
Since packets that CN replies must be tunneled to MN by HA, but if
triangle routing is used before these packets can arrive HA they will
meet Home NAPT first. This causes an example of "session initiate
from outside of NAPT" which will not be translated by NAPT. These
packets cannot traverse though Home NAPT turns out reach HA.
We need reverse tunneling. MN's packets will be sent back to HA and
forwarded to CN by HA. And replied packet can back HA again then be
tunneled to MN. For tunneled packets to traverse though Home NAPT, we
need UDP tunneling runs on FA, HA and MN, too. But when MN reverse
tunnels packets to home network will be an example of session
initiated outside of NAPT. Because UDP tunneled packets sent from
foreign network to home network will have destination port set to
434, we can simply bind port 434 of HA to port 434 of Home NAPT. Thus
all the packets received from port 434 by Home NAPT will be
redirected to HA and then tunneled to CN.
6.3.1 MN Considerations
When MN first moves out from home network, it have to send RRQ to HA
registering its current location. If MN do not know Home NAPT's IP
address, the RRQ could not reach HA since HA's IP address is private
that is not routable in the Internet. MN must provide Home NAPT's
public IP address, so that packets can be sent back to home network.
The way MN to provide Home NAPT's public IP address could be manually
recorded in the configuration file or use NAI[5] to find out.
If there is a FA in foreign network, MN may tell FA Home NAPT's
public address in the registration message. This may need an
extension in registration message.
6.3.2 FA Considerations
MNs from different home network may have the same private home
address. If they use FA's CoA as CoA, FA may not distinguish them
properly by just check the IP address in packet. FA needs some other
mechanisms to do this. Link layer address could help in distributing
packets to MN. A table mapping from MN's link-layer address to MN's
Home NAPT address and MN's home address maybe useful. When FA
receives a packet form MN's home network, it checks the source IP
both in inner header and outer header to determine the ultimate
destination. Then FA forwards the packet to correspondent link-layer
address. Thus MN will receive what it should receive.
6.3.3 HA Considerations
When HA receives a data packet reverse tunneled from MN, it must
NTHU & ITRI Expires February 2003 [Page 7]
Internet Draft Mobile IP Integrates with NAPT September 2002
decapsulate the packet and then forward this packet to CN. This
packet will traverse through Home NAPT and will trigger Home NAPT to
keep a record in NAPT's mapping table. So that when CN replies,
packets can be translated properly and be tunneled to MN by HA.
6.4. Both Home Network and Foreign Network are Private; FA, HA are
Behind NAPT
Both are private:
Foreign Network1 Home Network
--------------+ +-------------
MN4 | | MN1
FA -----NAPT----Internet------NAPT--HA MN2
| / \ | MN3
--------------+ / \ +-------------
/ \
Foreign Network2 / \
--------------+ / \
MN5 | / CN
DHCP--NAPT
|
--------------+
This scenario will have all the problems list in section 3. We need
all mechanisms used in 6.3: Apply Reverse tunneling, UDP tunneling in
HA, MN, FA; and let MN provide Home NAPT's public IP address and bind
port 434 of NAPT to port 434 of HA.
6.4.1 MN Considerations
MN still have the same problem as 6.3.1, and MN must provide Home
NAPT's public IP address, too.
When MN handoffs to foreign network, it must aware whether this
foreign network is private or not. The same mechanism as what used in
"NAT traversal for MIP"[3] to detect private network could be used.
6.4.2 FA Considerations
If FA CoA is used, a problem like 6.3.2 will occur. FA will need a
table as referred in 6.3.2.
6.4.3 HA Considerations
In this scenario, HA should do the same action as 6.3.3 do.
7. Overall Suggestions
NTHU & ITRI Expires February 2003 [Page 8]
Internet Draft Mobile IP Integrates with NAPT September 2002
Since there will be various scenarios and what we can control is
usually either home network or foreign network. For a most flexible
consideration, we propose the following implementation suggestion:
7.1 Implementation Suggestions
1. Reverse tunneling must be implemented.
2. UDP tunneling must be implemented.
3. MN must provide Home NAPT's public address
4. FA must distinguish MN by link-layer address and maintain a
mapping between MN's Home NAPT's IP, MN's private address and
MN's link-layer address.
5. The destination address in RRQ should be Home NAPT's public
address.
7.2 Usage Suggestion
1. All hosts in a private domain must have unique IP address, include
MNs that moved to foreign domain.
2. If home network uses NAPT, bind port 434 of NAPT to port 434 of
HA.
8. IANA Considerations
This document does not create any new numbers for IANA
administration.
References
[1] C. Perkins, "IP Mobility Support for IPv4", RFC 3220, January 2002.
[2] P. Srisuresh, "IP Network Address Translator (NAT) Terminology and
Considerations", RFC 2663, August 1999.
[3] H. Levkowetz, "Mobile IP NAT/NAPT Traversal using UDP Tunneling",
IETF draft, (draft-ietf-mobileip-nat-traversal-04.txt) May 2002.
[4] G. Montenegro, "Reverse Tunneling for Mobile IP, revised", RFC 3024,
January 2001.
[5] B. Aboba, M. Beadles, "The Network Access Identifier", RFC 2486,
NTHU & ITRI Expires February 2003 [Page 9]
Internet Draft Mobile IP Integrates with NAPT September 2002
January 1999.
[6] Toshihiko Kato, Akira Idoue and Hidetoshi Yokota, "Mobile IP Using
Private Address", Proceedings of IEEE Computer and Communications,
P 491 - P 497, Hammamet, Tunisia, July 2001.
[7] Y. Rekhter, B. Moskowitz , D. Karrenberg , G. J. de Groot, E. Lear,
"Address Allocation for Private Internets", RFC 1918, February 1996.
[8] Douglas E. Comer, "Internetworking with TCP/IP principles,
protocols, and architectures", 4th edition, Prentice Hall, 2000.
[9] C. Perkins, "IP Encapsulation within IP", RFC 2003, October 1996.
[10] T. Li, S. Hanks, D. Meyer, P. Traina, "Generic Routing
Encapsulation (GRE)", RFC 2784, March 2000.
[11] C. Perkins, "Minimal Encapsulation within IP", RFC 2004, October
1996.
[12] J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981.
[13] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier
Extension for IPv4", RFC 2794, March 2000.
Authors:
Ching-Yang Huang
Institute of Communications Engineering
National Tsing Hua University
101, Section 2 Kuang Fu Road, Hsinchu, Taiwan 300, ROC
Phone: +886-3-5715131 ext.3599
E-mail: g905630@oz.nthu.edu.tw
Jyh-Cheng Chen
Department of Computer Science
National Tsing Hua University
101, Section 2 Kuang Fu Road, Hsinchu, Taiwan 300, ROC
Phone: +886-3-5715131 ext.2961
E-mail: jcchen@cs.nthu.edu.tw
Jen-Chi Liu
Computer & Communications Research Laboratories
Industrial Technology Research Institute
195-11 Sec. 4, Chung Hsing Rd., Chutung, Hsinchu, Taiwan 310, ROC
NTHU & ITRI Expires February 2003 [Page 10]
Internet Draft Mobile IP Integrates with NAPT September 2002
Phone: +886-3-5914663
E-mail: jcliu@itri.org.tw
Ming-Cha Jiang
Department of Computer Science
National Tsing Hua University
101, Section 2 Kuang Fu Road, Hsinchu, Taiwan 300, ROC
Phone: +886-3-5715131 ext.3599
E-mail: jmc@cs.nthu.edu.tw
Hon-Wei Lin
Department of Computer Science
National Tsing Hua University
101, Section 2 Kuang Fu Road, Hsinchu, Taiwan 300, ROC
Phone: +886-3-5715131 ext.3529
E-mail: willie@cs.nthu.edu.tw
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
NTHU & ITRI Expires February 2003 [Page 11]
