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 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]