INTERNET-DRAFT Samita Chakrabarti Category: Standards Track Gabriel Montenegro Title: Sun Microsystems, Inc. draft-chakrabarti-mobileip-privaddr-01.txt Hidetoshi Yokota Date: October 2002 KDDI R&D Laboratories, Inc. Limited Private Address Support for Mobile IPv4 Status of this Memo This document is an Internet-Draft and is subject to 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. 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. 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 April 2003 [Page 1]
INTERNET DRAFT October 2002 Abstract Reverse Tunneling for Mobile IP describes Limited Private Address Scenario for mobile nodes and mobile agents. This document specifies the requirements of Mobile IP components for Limited Private Address Support and discusses implementation issues and options. It also specifies two new Mobile IP skippable extensions for the interoperability of deployment in Limited Private Address Scenarios. Solutions involving Network Address Translation are out of scope of this document. Table of Contents 1. Introduction 2. Terminology 3. Mobile Node Requirements 4. Home Agent Requirements 5. Foreign Agent Requirments 6. Possible usage scenarios 7. Implementation Considerations and Limitations 7.1 Handling overlapping home-addresses 7.2 Mobile Node to Correspondent Node Communication 8. New Extensions for Limited Private Address Support 8.1 Address Type NAI Extension (AT-NAI) 8.2 Mobile Node considerations using AT-NAI 8.3 Processing AT-NAI at Foreign Agent and Home Agent 8.4 LPAS Agent Advertisement Extension 9. Other Considerations 10. Acknowledgements 11. References 12. Authors' and the Chairs' Addresses 13. Full Copyright Statement Chakrabarti, Montenegro, Yokota expires April 2003 [Page 2]
INTERNET DRAFT October 2002 1. Introduction It has been deemed by the ISPs that having Mobile IP reverse tunnel and Limited Private Address Support in their operating environment are key to the deployment of mobile IP services, 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 3GPP2 wireless environment and as well as in both wireless and wired IP networks in the enterprise realms. Appendix A.4 of Reverse Tunneling for Mobile IP [1] discusses Limited Privated Address Scenarios (LPAS). This document clarifies LPAS and specifies the requirements of mobile nodes, home agents and foreign agents which support limited usage of private home addresses. It introduces two new Mobile IP [2] extensions in section 8 for interoperability among deployments. The private addresses [3] discussed here are limited to mobile node home addresses only. The solutions discussed in the document is solely based upon Mobile IP [2], Reverse Tunneling for Mobile IP [1] and Mobile IP Network Access Identifier Extension for IPv4 [7]. No other mechanisms such as Network Address Translators etc. are part of this solution. Operation in the presence of route optimization [4] is outside the scope of this document. 2. 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. NAI Network Access Identifier used as identifier for dynamic home address allocation in Mobile IP. AT-NAI A new NAI extension type which lets the user request for private or global IP-address. Chakrabarti, Montenegro, Yokota expires April 2003 [Page 3]
INTERNET DRAFT October 2002 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. Mobile Node Requirements The following are the requirements for private home 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 its 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. o A mobile node may request for a public or private dynamic home address using the new NAI extension described in section 8. 4. 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 its mobile nodes. o The home agent SHOULD be able to assign private addresses out of its address pool to the mobile nodes for use of home addresses. This is in accordance with section 3.8 of [2]. Chakrabarti, Montenegro, Yokota expires April 2003 [Page 4]
INTERNET DRAFT October 2002 o Home agent address MUST be a publicly routable address, if it is serving the roaming mobile nodes over the public internet. When home agent is used in a intranet environment and it is reachable by the corresponding mobile nodes and the foreign agent via the intranet, then it is sufficient for the home agent to have a uniquely routable address within the intranet. o A home agent which implements section 8.1 of this specification, can handle both private and public dynamic home-address allocation simultaneously. Otherwise, it can also assign public or private home address if it implements RFC2794 (see section 7.2 for details). 5. 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. Note: for mobility within a intranet or private network, it will be sufficient if the care-of-addreses of foreign agents are uniquely routable within that 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 A foreign agent which implements this specification MUST use LPAS agent advertisement extension described in section 8.4. A foreign agent which implements RFC3024 [1] is not required to implement section 8 in this document, but it SHOULD support LPAS described in section A.4 of RFC3024 [1]. o A foreign agent MUST disambiguate among mobile nodes with conflicting private addresses by using link-layer inforamtion and or home-agent information in forward and reverse paths. 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. This ensures that packets coming from visiting mobile nodes are not directly routed to each other via the foreign agent. Chakrabarti, Montenegro, Yokota expires April 2003 [Page 5]
INTERNET DRAFT October 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 | INTERNET +-----+ | 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 | INTERNET +-----+ | 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 April 2003 [Page 6]
INTERNET DRAFT October 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 | +----+ | | INTERNET +-----+ +-------+ | 10.10.1.5 | +-----+ INTERNET | MN2 |-----+ | +-----+ | IF2=COA2 | +-------+ | | | +------+ | FA2 | | | +------+ 7. Implementation Considerations and Limitations 7.1 Handling overlapping home-addresses When two mobile nodes with same private addresses visit a single foreign agent to share the same COA, foreign agent distinguishes between the two, in both directions of packet flow. For example, in forward direction, if mobile nodes use unique point to point links, the foreign agent can distinguish them easily by the interfaces or point-to-point link identification. But the same interface identification does not apply when two mobile nodes with same private home addresses visit the foreign agent on the same shared link such as ethernet. In this case, the mobile node's unique identification could be its link-layer address or some other unique id such as mobile terminal id. Chakrabarti, Montenegro, Yokota expires April 2003 [Page 7]
INTERNET DRAFT October 2002 In the case of ethernet address being the unique identification, there might be some problems with most of the existing implementations. IP address to ethernet address mapping is usually one-to-one, thus ethernet address lookup algorithm must consider some other mobile-node specific information to match the correct ethernet address for a given overlapped private home address. Similar problem appears while forwarding to the reverse tunnel. Appendix A.3 of RFC3024 [1] has elaborated this situation. If a private addressed mobile node registers with two different home agents using the same shared link or via same COA, it SHOULD use different private home addresses. Thus a foreign agent should use {MN's home address, HA's address, MN's unique id} to distinguish packets from the same mobile node destined to different reverse tunnels. Note that MN's unique identification is implementation dependent. 7.2 Mobile Node to Correspondent Node Communication From the scenarios in section 6, it can be observed that two private mobile nodes can communicate with each other if their home-addresses belong to the same home agent or same private network. But the mobile node is not able to communicate with a correspondent node in the global internet using its non-routable private home-address. Note, we are assuming that there is no Network Address Translator involved in address translation between the correspondent node and Home agent. Chakrabarti, Montenegro, Yokota expires April 2003 [Page 8]
INTERNET DRAFT October 2002 There could be several situations as described below: a) A visiting mobile node is a mulit-homed device. It uses one interface to communicate with another mobile node or a correspondent node in its private home network. The mobile node uses the second interface to communicate with a webserver in the Internet. In this scenario, the mobile node should use publicly routable home-address for the second interface. b) A visiting mobile node has single network interface. It uses private home address for communicating with nodes in the home-network. But it needs to use a global home-address in order to communicate with a node in the Internet. It's possible that the Home agent has different charging policies depending on the type of address usage. c) A visiting mobile node does not have a fixed home-address. It has a Network Access Identifier and it uses Mobile IP NAI [7] to get itself a home address. The mobile node needs to acquire public address or private home address depending on public internet access or private home network access. When mobile node depends on dynamic home address assignment, it's possible that it might register with different home agents for obtaining private or public home-addresses. Thus a mobile node can use same NAI for receiving different types of addresses. Alternatively, an ISP may assign two NAIs per user, one for private home address and the other for public home address. Depending on ISP billing policy, the user might get charged differently for using user-private@isp.com or user-public@isp.com. However, it's difficult for mobile applications to switch to different configurations according to Home Agent Service Options. Hence this draft proposes a specification on requesting address type in dynamic home address assignment for interoperability. Chakrabarti, Montenegro, Yokota expires April 2003 [Page 9]
INTERNET DRAFT October 2002 8. New Extensions for Limited Private Address Support 8.1 Address Type NAI (AT-NAI) Extension RFC2794 specifies dynamic home address allocation using network access identifier for Mobile IPv4, but it does not have any provision for mobile-node to request specific address type or any other specific address requirement. Thus this document specifies a skippable NAI extension for requesting a specific 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [2] Length The length in bytes of the MN-NAI field plus one Address Type It is a 8-bit flag uniquely identifies each NAI address type request. The flag is defined as +-+-+-+-+-+-+-+-+ |P R R R R R R R| +-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 P - Private Address R - Reserved for future use MN-NAI A string in the NAI format defined in [7] If P bit is 0, it requests for a global IP address, otherwise it specifically requests for a private home address. Other reserved bits may be defined and used in future by other documents for mobile nodes which have more specific address type requirements. The expiration period of the assignment of a home 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. Chakrabarti, Montenegro, Yokota expires April 2003 [Page 10]
INTERNET DRAFT October 2002 8.2 Mobile Node considerations using AT-NAI A mobile node which implements this specification MUST use AT-NAI extension in order to request a private or public dynamic home address assignment. Any home agent which does not implement this specification may ignore the extension. In this situation, the mobile node gets an error back from foreign agent and it then decides to try another home agent or use RFC2794 style NAI request. Note that RFC2794 style NAI and AT-NAI MUST NOT be used in the same registration request. 8.3 Processing AT-NAI at Foreign Agent and Home Agent Both Foreign and Home agents which implement this specification MUST be able to process the above NAI extension type. If this extension is present along with regular [7] NAI extension, Foreign agent should consider that as poorly formatted request. Cases when agents don't implement this specification: a) Only Home agent does not understand AT-NAI Home agent returns an error to the foreign agent. Foreign agent replies with MISSING_HOMEADDR [7] error to the mobile node. b) Foreign agent does not understand AT-NAI Foreign Agent replies with NONZERO_HOMEADDR_REQD [7] error to the mobile node. 8.4 LPAS Agent Advertisement Extension Foreign and Home agents which advertise Reverse Tunneling support along with the following extension, MUST support the specification provided in this document. Thus a mobile node which understands the following extension upon receipt of an agent advertisement, can safely assume that its foreign agent provides full Limited Private Address Support. The recipient of home agent advertisements, similarly can assume that they can receive LPAS support as specified in this document. Chakrabarti, Montenegro, Yokota expires April 2003 [Page 11]
INTERNET DRAFT October 2002 The LPAS agent advertisement extension is defined as follows: 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 | Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (Skippable) Length 1 Byte Data This field does not contain any relevant information. It's length could be 0 or more bytes depending on alignment requirement. The receiver of this extension MUST use the Type field alone to determine that the advertising agent supports LPAS requirements specified in this document. 9. Other Considerations Private addressed mobile nodes using Network Address Translation [5] are out of scope of this document. Such situations are discussed in Mobile IP NAT/NATPT traversal [6] document. However, Mobile IPv6 [8] will provide a long term solution for device address scalability in mobile internet. 10. 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 initial idea on 'limited' private address usage as a temporary solution of Mobile IPv4 deployment scenario. The authors also like to thank the following reviewers (in alphabetical order): Farid Adrangi (Intel), Steven Glass (Sun), Milind Kulkarni (Cisco), Pete McCann (Lucent), Alpesh Patel (Cisco) and Phil Roberts (Megisto) for their comments and suggestions. Chakrabarti, Montenegro, Yokota expires April 2003 [Page 12]
INTERNET DRAFT October 2002 11. References [1] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 3024, January 2001. [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [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. [5] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [6] Levkowetz, H and S. Vaarala, "Mobile IP NAT/NAPT Traversal using UDP Tunnelling", draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt, Work in Progress. [7] Calhoun, P and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC2794, March 2000. [8] D. Johnson, C. Perkins., J. Arkko, "Mobility Support in IPv6", draft- ietf-mobileip-ipv6-19.txt. [9] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels". BCP 14, RFC 2119, March 1997. Chakrabarti, Montenegro, Yokota expires April 2003 [Page 13]
INTERNET DRAFT October 2002 12. Authors' and Chairs' 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@kddlabs.co.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 April 2003 [Page 14]
INTERNET DRAFT October 2002 Phil Roberts Megisto Systems, Inc. EMail: proberts@megisto.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 13. 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 April 2003 [Page 15]