INTERNET DRAFT Samita Chakrabarti Category: Informational Gabriel Montenegro Title: draft-chakrabarti-mobileip-privaddr-00.txt Sun Microsystems, Inc. Date: February 2002 Hidetoshi Yokota KDDI R&D Laboratories, Inc. Limited Private Address Support: An addendum to Reverse Tunneling for Mobile IP (RFC3024) Status of this Memo This document is an individual contribution for consideration by the Mobile IP Working Group of the Internet Engineering Task Force. Distribution of this memo is unlimited. 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. Copyright (C) The Internet Society 2000. All Rights Reserved. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 1]
INTERNET DRAFT February 2002 Abstract Reverse Tunneling for Mobile IP [1] defines limited private address support for mobile nodes and mobile agents. This document provides information and guidance to the users on the requirements and desc- ribes implementation issues regarding Limited Private Address Support for Mobile IP [2]. This document's purpose is to clarify Mobile IPv4 temporary deployment scenarios within an operator's environment where private IPv4 addresses are required for the mobile devices. However, the scenarios and communication between private addressed mobile nodes have limited usage. Solutions involving Network Address Translation are out of scope of this document. Table of Contents 1.0 Introduction 2.0 Terminology 3.0 Mobile Node Requirements 4.0 Home Agent Requirements 5.0 Foreign Agent Requirments 6.0 Possible usage scenarios 7.0 Implementation Considerations and Limitations 8.0 Acknowledgements 9.0 References 10.0 Authors' Addresses 11.0 Full Copyright Statement 1.0 Introduction Appendix A.4 of Reverse Tunneling for Mobile IP [1] discusses Limited Privated Address Scenarios (LPAS), but it is not very clear from the appendix that a reverse tunnel implementation MUST also support Limited Private Address Scenarios. This document clarifies Appendix A.4 of Reverse Tunneling for Mobile IP [1]. The private addresses discussed here are limited to mobile node addresses only. Private addresses are defined in RFC1918 [3]. The solutions discussed in the document is solely based upon Mobile IP [2] and Reverse Tunneling for Mobile IP [1]. No other mechanisms such as Network Address Trnaslators etc. are part of this solution. It has been deemed by ISPs that having reverse tunnel and limited private address support in their operating environment are essential for deployment of mobile IP devices as number of publicly routable IP-addresses are scarce and do not meet the demand of high volume of mobile devices, such as laptops, PDAs and cell-phones. Private addressed mobile nodes can be deployed in 3G wireless environment and as well as in enterprise realms. The private addressed mobile nodes are associated with it's home agent and thus two mobile nodes belonging to same home agent can Chakrabarti, Montenegro, Yokota expires August 2002 [Page 2]
INTERNET DRAFT February 2002 communicate with each other through reverse tunnel even when they are visiting foreign domains. The packets from the private mobile nodes to each other must be reverse tunneled, as the private addresses are not routable through the internet. However, the assumption is that the foreign agent's care-of-address and home agent address are all publicly routable addresses. Operation in the presence of route optimization [4] is outside the scope of this document. 2.0 Terminology The document uses the following terms in addition to what is defined in [1] and [2]. LPAS Limited Privated address Scenario which can be used by ISPs and enterprizes given the current state of Mobile IP specifications. 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 [9]. 3.0 Mobile Node Requirements The following are the requirements for private addressed mobile nodes in the limited private address support scenario. o Mobile node MUST obtain reverse tunnel through registration as described in Reverse Tunneling for Mobile IP [1]. o A mobile node MUST have unique home address in it's home domain o A mobile node with public co-located COA may use private home address via reverse tunnel o A mobile node may never visit home and always roams. An example will be cell-phones. 4.0 Home Agent Requirements o Home Agent MUST support reverse tunnel encapsulation and decapsulation and process registration request with 'T' bit set. o The home agent MUST not support overlapping private addresses for mobile node's home address. Thus it MUST assign unique private home address to each of it's mobile nodes. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 3]
INTERNET DRAFT February 2002 o The home agent SHOULD be able to assign private addresses out of it's address pool to the mobile nodes for use of home addresses. This is in accordance with section 3.8 of [2]. o Home agent address MUST be a publicly routable address. 5.0 Foreign Agent Requirements o All advertising interfaces of the foreign agent MUST have publicly routable care-of address. Thus, a mobile node with a private address visits the foreign agent only in its publicly routable network. This restriction is to avoid visiting private addressed subnets in the foreign network. o Foreign agents MUST support reverse tunneling in order to support private addressed mobile nodes. If a foreign agent receives a registration request from a mobile node with a private address, and the mobile node has not set the 'T' bit, the foreign agent SHOULD reject it. o If a foreign agent supports reverse tunneling, then it MUST support the simple scenario of private address support, i.e LPAS. o A foreign agent MUST disambiguate among mobile nodes with conflicting private addresses by using link-layer inforamtion and or home-agent information. o A foreign agent should make sure that two mobile nodes visiting the same foreign agent corresponds with each other through their respective home agents. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 4]
INTERNET DRAFT February 2002 6.0 Possible Usage Scenarios 1) Two private addressed mobile nodes visiting same foreign agent and the mobile nodes have same home agent. 10.10.1.2 +----+ IF1=COA1+-------+ | MN1|------------------------| FA | +----+ +------------| | | IF2=COA2+-------+ +---+ | | | +-----+ | | MN2 | | +-----+ | 10.10.3.2 | | HAA1 +------+ | HA1 | +------+ Note that if IF1 = IF2, then COA1 = COA2 and this is a valid scenario or configuration. COA1, COA2 and HAA1 are all publicly routable addresses. 2) Two private addressed mobile nodes visiting same foreign agent and the mobile nodes have different home agent. MN1 and MN2 may or may not have same (overlapping) IP -addresses. 10.10.1.2 +----+ IF1=COA1+-------+ HAA2 +-----+ | MN1|------------------------| FA |---------| HA2 | +----+ +------------| | +-----+ | IF2=COA2+-------+ +---+ | | | +-----+ | | MN2 | | +-----+ | 10.10.1.2 | | HAA1 +------+ | HA1 | +------+ Note that even if MN1 and MN2 are connected to the same FA, they are Chakrabarti, Montenegro, Yokota expires August 2002 [Page 5]
INTERNET DRAFT February 2002 logically separated by reverse tunneling, and they don't communicate each other since they belong to different HAs. For the case that IF1 = IF2, refer to section 7.0. 3) Two mobile nodes are visiting different foreign networks/foreign agents, the mobile nodes actually belong to a single home agent. 10.10.1.2 +----+ IF1=COA1+-------+ HAA2 +-----+ | MN1|------------------------| FA1 |---------| HA | +----+ | | +-----+ +-------+ | 10.10.1.5 | +-----+ | | MN2 |-----+ | +-----+ | IF2=COA2 | +-------+ | | | +------+ | FA2 | | | +------+ 7.0 Implementation Considerations and Limitations When two mobile nodes with same private addresses visit a single foreign agent on the same shared link or share the same COA, foreign agent must distinguish between the two, in both direction of packet flow. For example, in forward direction, if mobile nodes use unique point to point links, foreign agent can distinguish easily by their interface identification. But there is a problem when the mobile nodes sharing same private addresses visit the foreign agent on the same shared link such as ethernet. In this case, IP address to ethernet address mapping becomes ambigous, thus ethernet address lookup must consider some other mobile-node specific information to support private addressed mobile nodes correctly on the shared link. The same problem appears while forwarding to the reverse tunnel, to avoid this problem reverse tunnel lookup may consider matching with ethernet address as well. This may not be an easy solution and may require architectural change in the IP kernel implementation. In a nutshell, it is better to provide mobility service to the private addressed mobile nodes through one-to-one link - such as point-to- point link in 3G wireless CDMA environment. Some implementations may choose to use other link-level information, such as mobile node identification number to distinguish between two conflicting private addressed mobile nodes visitng the same agent on the same link. Appendix A.3 of RFC3024 [1] has elaborated this situation. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 6]
INTERNET DRAFT February 2002 If a private addressed mobile node registers with two diferent home agents using the same shared link or via same COA, it SHOULD use different home addresses. Thus a foreign agent should use <MN's IP address, HA's address, MN's unique id> to distinguish two different private addressed mobile nodes in the reverse direction (for reverse tunnel). Note that MN's unique identification is implementation dependent. From the above scenarios it can be observed that two private mobile nodes can communicate to each other if they belong to the same home agent. A private-addressed mobile node can communicate to a correspondent node in its home network. But the mobile node will not be able to communicate with a correspondent node in the global internet. In order to solve this problem, it is recommended that the mobile node implementation should request a global address to it's home-agent through NAI. This requires modification of RFC2794 as currently it does not distinguish between private and global addresses. (XXX: How about having a modification in rfc2794 to introduce another field for address type ?) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address Type | MN-NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Type = 0 (global) 1(private) Alternatively, a mobile node may be configured with separate home agent services for supplying private and public addresses to it. Thus, it can obtain public address through the designated home agent when necessary to use a global home-address. This solution implies that a address-less mobile-node can be configured with two home-agent addresses, each providing private ip-address and global ip-address respectively via NAI [8] request. The expiration period of the assignment of a global address to a mobile node should not be shorter than the accepted lifetime of the registration, and it should be extended when the registration is successfully updated. Private addressed mobile nodes using Network Address Translation [6] are out of scope of this document. Such situations are discussed in Mobile IP NAT/NATPT traversal [7] document. However, adoption of Mobile IPv6 [9] will provide a long term solution for device address scalability. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 7]
INTERNET DRAFT February 2002 8.0 Acknowledgements The authors like to acknowledge Tom Hiller and David Welch of Lucent Technologies for the idea of having private addressed only mobile nodes in the MobileIP deployment scenarios. Also we acknowledge Erik Nordmark of Sun Microsystems for the intial idea on 'limited' private address usage as a temporary solution of Mobile IPv4 deployment scenario. 9.0 References [1] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 3024, January 2001. [2] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. [3] Rekhter, Y.et al., "Address Allocation for Private Internets", RFC 1918, February, 1996. [4] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress. [6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [7] Levkowetz, H and S. Vaarala, "Mobile IP NAT/NAPT Traversal using UDP Tunnelling", draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt, Work in Progress. [8] Calhoun, P and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC2794, March 2000. [9] D. Johnson, C. Perkins. "Mobility Support in IPv6", draft- ietf-mobileip-ipv6-15.txt. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 8]
INTERNET DRAFT February 2002 Editor and Chair Addresses Questions about this document may be directed at: Samita Chakrabarti Sun Microsystems 901 San Antonio Road Palo Alto, CA 94303 USA Phone: +1 650-786-5068 EMail: samita.chakrabarti@Sun.com Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE Phone: +33 476 18 80 45 EMail: gab@sun.com Hidetoshi Yokota Mobile IP Network Laboratory KDDI R&D Laboratories, Inc. 2-1-15 Ohara, Kamifukuoka Saitama 356-8502 JAPAN Phone: +81 (492) 78-7894 Fax: +81 (492) 78-7510 EMail: yokota@kddilabs.jp The working group can be contacted via the current chairs: Basavaraj Patil Nokia Networks 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972-894-6709 Fax : +1 972-894-5349 EMail: Raj.Patil@nokia.com Chakrabarti, Montenegro, Yokota expires August 2002 [Page 9]
INTERNET DRAFT February 2002 Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA Phone: +1 847-632-3148 EMail: QA3445@email.mot.com 11.0 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. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 10]