Internet DRAFT - draft-chakrabarti-mobileip-privaddr
draft-chakrabarti-mobileip-privaddr
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]
