Subject: [mobile-ip] Next step for MIPv4 LPAS draft

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 4 Nov 2002 10:33:23 -0800 (PST)

Gabriel Montenegro presented the LPAS draft at Yokohoma IETF.
We have published a revision of LPAS draft which will be available
in the draft directory shortly.  Attached is a copy that we submitted.

We have received comments from several individuals in the working
group; as per discussions with the chairs, we have decided to
add two more extensions in the draft. Therefore, this draft is
no longer an informational draft, but it is now in "standards track".

To clarify the goal of this draft:

1) Any implementation which provides 'full LPAS' support MUST support 
   this draft should it become a standard. Implementations which 
   supports RFC3024(reverse tunnel) is NOT required to implement  
   the new extensions provided in this revision. 
 
2) 'Full LPAS' support now means: 
 
    1) Agent is able to advertise LPAS extension to guarantee 'full
       LPAS' support. 
 
    2) A Mobile Node will be able to specifically request a
       private or public address type during dynamic home-address 
       assignment (using a new AT-NAI extension). 

    3)  MN, FA, HA meet requirements specified in this draft

Comments are welcome. We would like to know whether these new 
extensions will be useful to implementations that like to offer
private home address services to its mobile nodes.

Thanks,

Gabriel Montenegro
Hidetoshi Yokota
Samita Chakrabarti

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 [email-masked] or [email-masked].
     
     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: [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 April 2003           [Page 14]

INTERNET DRAFT                                            October 2002

   Phil Roberts
   Megisto Systems, Inc.

   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]

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]