Subject: [mobile-ip] A guideline draft fro LPAS (extension to RFC3024)

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 14 Mar 2002 19:21:43 -0800 (PST)

A few IETFs ago it was decided at the working group to produce a
draft clarifying limited private address support ( manadatory
part if you support reverse tunneling) described in the appendix 
of RFC3024. 

Gabriel Montenegro, Hidetoshi Yokota and myself submitted a draft
explaining the LPAS scenarios and guidlines for implementations.

For some reason the announcement did not go out on the list.
But it's available in the draft directory as 
draft-chakrabarti-mobileip-privaddr-00.txt

Please provide your comments.

Thanks,
-Samita

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: [email-masked]

   Gabriel E. Montenegro
   Sun Microsystems
   Laboratories, Europe
   29, chemin du Vieux Chene
   38240 Meylan
   FRANCE

   Phone: +33 476 18 80 45
   EMail: [email-masked]

   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: [email-masked]

   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:  [email-masked]

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:  [email-masked]

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]