[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Mobile IP Working Group                               Charles E. Perkins
INTERNET DRAFT                                             G. Montenegro
25 June 1999                                              Pat R. Calhoun
                                                        Sun Laboratories

                     Private Addresses in Mobile IP
                  draft-ietf-mobileip-privaddr-00.txt

Status of This Memo

   This document is a submission by the mobile-ip Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.

   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.

Abstract

   The use of possibly non-unique private addresses (i.e., addresses
   that are not globally routable in the internet) for mobile nodes,
   foreign agents, or home agents is not handled by RFC 2002.  This
   document specifies changes to enable Mobile IP to handle such
   addresses.

Perkins, Montenegro, Calhoun      Expires 25 December 1999      [Page i]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

1. Introduction

   Full-scale deployment of Mobile IP would benefit from an ability to
   provide mobility across differing address spaces, sometimes called
   "realms", especially because corporate networks often use private
   address spaces.  A solution is needed to handle such addresses
   consistently with regionalized registrations and firewall traversal.
   The mechanisms proposed in this note aim to solve this problem.

   We use use the following model:

   +---------------------------+                 +----------------+
   |  Foreign Private Network  |                 |  Home Private  |
   |                           |   +---------+   |    Network     |
   |                           |   |         |   |                |
   |  +------+      +-------+  |   | Public  |   |    +------+    |
   |  |  FA  |------|  GFA  |-------------------------| SHA  |    |
   |  +--+---+      +-------+  |   | Network |   |    +--+---+    |
   |     |                     |   |         |   |       |        |
   +-----|---------------------+   +---------+   |    +--+---+    |
         |                                       |    |  HA  |    |
      +--+---+                                   |    +------+    |
      |  MN  |                                   |                |
      +------+                                   +----------------+

                Figure 1: Mobility with Private Networks

   A Home Agent using a private address cannot be the destination of
   any packets transmitted by a foreign agent in a different addressing
   domain.  Thus, such a home agent has to rely on the presence of a
   Surrogate Home Agent (a SHA). Furthermore, every mobile node on the
   Home Network served by such a home agent will also have a private
   address.

   This means that Registration Requests for the mobile node have to
   be sent to the SHA. Then, the SHA has to know how to forward such
   requests to the home agent.

   In this document, the GHAA (Global Home Agent Address) is defined to
   be either the HA, if the HA has a globally routable IP address, or
   else the SHA, if the HA does not have a globally routable IP address.

   Mobile IP has two distinct phases:

    1. tunnel setup via a UDP-based (registration) protocol, and

Perkins, Montenegro, Calhoun      Expires 25 December 1999      [Page 1]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

    2. data transfer via tunneled packets.

2. Data Transfer

   Let's examine first the data transfer phase.  Given that only systems
   within the same address space have direct reachability, the packets
   do not travel along an end-to-end tunnel.  Instead, the tunnel from
   HA to FA is a compound tunnel, used as in a previous proposal, Tunnel
   Establishment Protocol (TEP) [2].

   The segments of the tunnel are always within any given address space.
   If the home agent has a private address, there are 3 tunnel segments:

      HA->SHA, SHA->GFA, and GFA->FA

   Otherwise, if the home agent has a globally routable IP address, only
   two tunnel segments are necessary:

      HA->GFA and GFA->FA

   It is also possible that additional tunnel segments will be needed
   between the GFA and the FA, but setting up such additional tunnel
   segments is outside the scope of this document.

   The order and endpoints of the compounds tunnels are reversed when
   packets flow in the reverse direction.  Data transfer, then, proceeds
   from the correspondent node to the home agent through the SHA along
   to the FA in the manner to be described next.  In this section, MN
   refers to a particular mobile node which needs to receive data at a
   particular care-of address, which may itself be a private address
   from a separate address space than the one from which MN's IP address
   is allocated.

   In sections 2.3 through 2.5, the IP node sending the packet the GFA
   is designated as the GHAA, as defined in section 1.

2.1. From HA to SHA

   Say a correspondent node CN (not shown in figure 1) sends a packet
   to MN. If the home agent (HA) has a private address, then it MUST
   know the address of a SHA, and MUST cause the tunneled data packet to
   the MN's care-of address to seem to originate from the SHA. The HA
   first encapsulates the packet with an IP header that indicates that
   origination.  Then, the HA encapsulates it and sends it towards SHA
   as illustrated in figure 2.

Perkins, Montenegro, Calhoun      Expires 25 December 1999      [Page 2]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

         +-------------------------------+
         |         +--------------------+|
         |         |          +--------+||
         | HA->SHA | SHA->GFA | CN->MN |||
         |         |          +--------+||
         |         +--------------------+|
         +-------------------------------+

           Figure 2: IP-in-IP tunneled packet from HA to SHA

2.2. From SHA to GFA

         +--------------------+
         |          +--------+|
         | SHA->GFA | CN->MN ||
         |          +--------+|
         +--------------------+

           Figure 3: IP-in-IP tunneled packet from SHA to GFA

   Once the packet reaches SHA, the packet is decapsulated, exposing the
   still encapsulated packet with SHA as the source IP address.  The
   packet from SHA to GFA is illustrated in figure 3.

2.3. From GFA to FA

   When GFA decapsulates the packet, it looks for a binding for MN,
   the inner destination.  Following the discussion in [6], MN's IP
   address does not necessarily uniquely identify the mobile node.
   The reason is that the GFA may have another binding in place for a
   mobile node from another private address space that is using the
   same IP address as MN. The GFA has to identify the correct visitor
   list entry based on a tuple (i.e., an ordered set of information)
   which is guaranteed to be unique.  One such tuple sufficient for
   demultiplexing IP-within-IP packets [7] (protocol 4) is (MN,GHAA),
   where:

    -  MN is the destination IP address of the innermost header, and

    -  GHAA is the source IP address of the encapsulating header.

Perkins, Montenegro, Calhoun      Expires 25 December 1999      [Page 3]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

   The destination IP address of the innermost header is the mobile
   node's home address.  The source IP address of the encapsulating
   header is GHAA. The ordered pair (MN,GHAA) is presumed unique among
   all of GFA's Mobile IP clients.

   GFA requires (MN,GHAA) to fetch the next tunnel endpoint, FA. This
   tuple continues to be required for any foreign agent beyond GFA, as
   such agents MAY reside in a separate address space from MN's home
   address.  Accordingly, GFA encapsulates again so that GHAA will still
   be visible in the intermediate header.  The packet that arrives at FA
   is illustrated in figure 4.

         +--------------------------------+
         |         +---------------------+|
         |         |           +--------+||
         | GFA->FA | GHAA->GFA | CN->MN |||
         |         |           +--------+||
         |         +---------------------+|
         +--------------------------------+

           Figure 4: IP-in-IP tunneled packet from GFA to FA

2.4. From FA to MN

   Before delivering the packet to the mobile node, the FA MUST check
   that the outer source IP address (GFA) matches the intermediate
   destination IP address.  The FA MAY require that the same GFA always
   be associated with the MN, by storing this information in its routing
   table.  Note that a routing loop would result from indiscriminately
   forwarding the decapsulated packet after the outer (GFA->FA) header
   was removed, because the GFA would keep doing the same thing to the
   packet.  RFC 2002 includes language to prohibit this indiscriminate
   forwarding, and the mobility agents handling private addresses
   require at least as much care as RFC 2002 mobility agents when
   dealing with encapsulation.

   Like the GFA, the FA searches based on (MN,GHAA). Once the FA
   identifies the ultimate destination of the packet, MN, it delivers
   the packet using link-level mechanisms.

Perkins, Montenegro, Calhoun      Expires 25 December 1999      [Page 4]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

2.5. Using GRE tunnels

   GRE packets with a Routing field are outside the scope of this
   document.  GRE packets [4, 5] (protocol 47) without a Key field
   are only handled if their Protocol Type field has a value of 0x800
   (other values are outside the scope of this document), and can be
   demultiplexed based on the same tuple (MN,GHAA) as IP-within-IP
   packets.  GRE packets with a Key field could be demultiplexed
   based on that field used as a tunnel identifier [2] negotiated at
   registration time.

      Question:  how is the tunnel identifier negotiated?

   In this case, by absorbing the cost of negotiating the tunnel
   identifier and setting up the necessary routing for the GRE header,
   extra encapsulation steps can be avoided by providing a single GRE
   header, as illustrated in figure 5.

         +---------------------+
         |           +--------+|
         | GHAA->GFA | CN->MN ||
         | tunnelID  +--------+|
         +---------------------+

              Figure 5: GRE tunneled packet from GFA to FA

3. Tunnel Establishment

   Even if the HA cannot address FA directly, the HA has to send
   tunneled packets so that they eventually arrive at the FA so that the
   FA can deliver them to the mobile node.  These packets are delivered
   via GHAA and GFA. Configuring this tunnel is initiated by the Mobile
   IP Registration Request message, as defined in [8].

   If mobile node MN is registering with home agent HA, the GFA should
   be used as the care-of address, because the GHAA sends packets to MN
   via GFA.

   The mobility agents FA and GFA create the mapping (MN,GHAA) for each
   mobile node.  This information is available from the registration
   messages.  If the mobile node has acquired a co-located address,
   any foreign agent issuing agent advertisements MUST use the 'R' bit
   to force the mobile node's Registration Request to go through it.
   If a mobile node using a co-located address is not receiving any
   advertisements, then one of two things must be true:

Perkins, Montenegro, Calhoun      Expires 25 December 1999      [Page 5]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

    -  the co-located care-of address is globally routable, or

    -  the mobile node discovers the GFA; the protocol for this
       discovery operation is not specified within this document.

3.1. Privately Addressed Mobile Nodes

   Foreign agents that comply with Mobile IP as specified in RFC 2002
   are not required to handle mobile nodes with private IP addresses.
   Doing so requires additional mechanism, because it is possible for
   two mobile nodes to show up with the same identical private IP
   address.  Fortunately, at least delivery from the foreign agent's
   network interface to the mobile node will still be possible, based
   on the MAC address of the mobile node.  However, once the Foreign
   Agent has decapsulated the packets it receives for the mobile node(s)
   with a duplicated private IP address, it cannot determine which
   mobile node should receive the packet based only the value of the
   destination IP address (MN) in the inner IP header,

   In order to handle private addresses, a Foreign Agent MUST be able
   to identify its visitor list entry for the mobile node by using
   (MN,GHAA) as defined in section 2.3.  Pending Registration Requests
   using private addresses MUST be able to be identified by using the
   the Identification field along with either:

    -  the NAI [1] supplied by the mobile node, or

    -  (MN,GHAA)

   A new `P' bit is defined, from the currently reserved field of the
   Agent Advertisement defined in RFC 2002 [8], for use by Foreign
   Agents that have the mechanisms specified herein.  If the mobile node
   has a private address, then it SHOULD send registration requests
   only to a foreign agent that has advertised the ability to handle
   private addresses by setting the `P' bit.  If the mobile node has a
   private address, then it SHOULD include the NAI extension [3] in its
   Registration Request.

   When a Registration Reply is determined to match a request from a
   Mobile Node (MN) with a private address, the foreign agent MUST
   associate GHAA with its (new) visitor list entry for MN.

   DISCUSSION:

      cep:  I am not surewe should tie together the NAI with the
      use of private addresses in this way.  And, I think that the

Perkins, Montenegro, Calhoun      Expires 25 December 1999      [Page 6]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

      FA has to advertise its willingness to handle such nasty,
      unfriendly things such as private addresses.

      cep:  We could make the home agent append a Private Address
      extension to the Registration Reply, in the range 128-255.
      That would avoid making the mobile nodes have to be smart,
      and it would avoid requiring the foreign agents make the
      more difficult routing determination for mobile nodes with
      unique IP addresses.

3.2. Privately Addressed Home Agents

   Suppose the home agent has a private address.  Then, the home agent
   MUST perform the encapsulation steps specified in section 2.1.  The
   mobile node MUST be able to discover the address of its SHA. This
   discovery MAY occur in one of the following ways:

    1. The home agent can advertise an SHA's address in advertisements
       received by the mobile node when the mobile node is at home.
       This document does not specify any method by which a home agent
       can advertise a SHA.

    2. The SHA can be returned in the Home Agent field of the
       Registration Reply, when the mobile node asks for dynamic
       allocation of a Home Agent.

    3. The mobile node can be statically configured to contain the
       address of a SHA, at the same time that it is configured with a
       security association with a home agent or with a home AAA server.

3.3. Foreign Agents with Private Addresses

   A foreign agent with a private address SHOULD NOT advertise its
   care-of address within its agent advertisements (beacons), because
   the beacons are assumed to offer connectivity for mobile nodes that
   may belong in a different addressing domain.  Instead, it SHOULD
   advertise a care-of address that is reachable by the GHAA. This
   globally reachable care-of address is associated with a distinguished
   foreign agent known as the Gateway Foreign Agent (GFA).

   DISCUSSION:
   The FA could use one of three methods to indicate to the mobile node
   the necessary information about the foreign domain/GFA:

    -  can advertise FA@domain

    -  can advertise GFA

Perkins, Montenegro, Calhoun      Expires 25 December 1999      [Page 7]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

    -  can reject registration and send GFA

   If the foreign agent advertises a care-of address which is not
   associated with one of its own network interfaces, the mobile
   node must be given some other method to detect when it moves to
   a different foreign agent.  A foreign agent advertising a GFA as
   its care-of address SHOULD use the FA-NAI extension, specified in
   section 4.

   In order to advertise the GFA as a care-of address, the foreign agent
   has to find find out what it is.  This MAY be done by any of the
   following methods:

    1. The GFA can list its care-of address in advertisements received
       by the foreign agent.

    2. The GFA can be returned in the Care-of Address field of the
       Registration Reply.  This requires that the care-of address be
       made known to the home agent, in order for the Registration Reply
       to be properly authenticated.

    3. The foreign agent can be statically configured to contain the
       care-of address of a GFA.

      [gab - does an MN need to know the GFA?.  maybe not.  just
      issue the request with care-of address 0 and have the FA
      figure it out via AAA or whatever, precisely as outlined in
      the next section.]

   This document does not (yet) specify any method by which the home
   agent may obtain the GFA's globally routable care-of address.

3.4. Alternative GFAs

   If a foreign agent has access to multiple GFAs, the appropriate GFA
   for a particular mobile node MAY may be selected depending upon the
   NAI given by the mobile node, or the home agent address given by the
   mobile node.  In this case, the foreign agent MAY advertise a care-of
   address of zero, and include the FA-NAI extension specified in
   section 4.  When the mobile node first attempts to make a connection
   in a particular foreign domain, it is typically unaware of any nearby
   care-of address.  When the foreign agent advertises a zero care-of
   address, the care-of address that the mobile node uses during its
   initial registration MUST be zero.  Before the Registration Request
   reaches the home domain, the care-of address (say, of a GFA), MUST
   be inserted by an agent (call it AAAX) trusted and authenticated by
   the home domain, or an associate in the foreign domain trusted and

Perkins, Montenegro, Calhoun      Expires 25 December 1999      [Page 8]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

   verified by AAAX. The home agent, then, includes that care-of address
   in the Registration Reply, for subsequent use by the mobile node.

   DISCUSSION:

      This should perhaps go into a separate document.  It could
      depend on AAA. We need to define error numbers for the
      following cases:

       -  nonzero COA at private FA

       -  zero COA at GHAA

3.5. Protocol between SHA and HA

   In this section we assume that the home agent has a private address,
   and thus that every packet tunneled to the mobile node has the IP
   address of the SHA as the source IP address in the tunnel header.

   If a SHA receives a Registration Request, and it is not the home
   agent for the initiating mobile node, the SHA has to have an entry
   for the mobile node and a record of the associated home agent in its
   home list.  This record can be created in the following ways:

    1. Manual configuration

    2. The SHA can receive a Registration Request from a AAA agent in
       the home domain (call it AAAH) during the initial registration
       sequence for the mobile node in the foreign domain.  In this
       case, the AAAH will send the address of the appropriate home
       agent along with the Registration Request.

   When the home agent receives a data packet for delivery to the mobile
   node, the home agent MUST first deliver this packet to the SHA. It
   does this by iterated encapsulation:

    1. Encapsulate using the care-of address as the tunnel destination
       and the SHA as the tunnel source address, and then

    2. Encapsulate using the SHA as the tunnel destination and the home
       agent's private address as the tunnel source address

   When the SHA receives this tunneled packet, it only has to remove the
   outermost IP header from the packet and forward the (still at least
   singly encapsulated) result to the care-of address.

Perkins, Montenegro, Calhoun      Expires 25 December 1999      [Page 9]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

4. Foreign Agent NAI

   The Foreign Agent NAI Extension to the Agent Advertisement contains
   the foreign agent's host name following the format defined in [1].
   The NAI is used to identify the foreign agent and can be used by
   a mobile node to determine whether or not it has moved out of the
   domain in which its previous foreign agent was configured to provide
   mobility service.

       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     |           FA NAI ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 6: The FA NAI Extension

      Type       TDB

      Length     The length in bytes of the FA NAI field

      FA NAI     Contains the foreign agent's NAI in the format defined
                 in [1].

5. Security Considerations

   Since private addresses are typically administered to prevent access
   to networks inside an enterprise, privately addressed mobile nodes
   with Mobile IP must be handled with great care to avoid break-ins.
   For instance, the mobile node should probably not offer any IP
   forwarding services while registered at an external care-of address.
   It is difficult to imagine how forwarding traffic between the foreign
   and home domain could be logically consistent with the raison d'etre
   for the private address space in the home domain.

   The SHA and GFA offer access mechanisms into a private address space.
   Packets sent to the SHA or GFA for further handling may, therefore,
   require authentication and possibly encryption to maintain the
   existing security policy which originally dictated the choice of
   using a private address space within the enterprise.

Perkins, Montenegro, Calhoun     Expires 25 December 1999      [Page 10]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

6. IPv6 Considerations

   It is hoped that IPv6 will not offer any such private addresses as
   have been brought about by perceived unavailabilty of enough IPv4
   addresses.

References

   [1] B. Aboba and M. Beadles.  RFC 2486:  The network access
       identifier, January 1999.  Status:  PROPOSED STANDARD.

   [2] P. Calhoun and C. Perkins.  Tunnel Establishment Protocol (TEP).
       draft-ietf-mobileip-calhoun-tep-00.txt, December 1997.  (work in
       progress).

   [3] Pat R. Calhoun and Charles E. Perkins.  Mobile IP Network
       Address Identifier Extension.  draft-ietf-mobileip-mn-nai-01.txt,
       February 1999.  (work in progress).

   [4] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina.  Generic
       Routing Encapsulation (GRE).  RFC 1701, October 1994.

   [5] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina.  Generic
       Routing Encapsulation over IPv4 networks.  RFC 1702, October
       1994.

   [6] G. Montenegro.  Negotiated Address Reuse (NAR).
       draft-montenegro-aatn-nar-00.txt, May 1998.  (work in
       progress).

   [7] Charles Perkins.  IP Encapsulation within IP.  RFC 2003, May
       1996.

   [8] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
       1996.

Perkins, Montenegro, Calhoun     Expires 25 December 1999      [Page 11]


Internet Draft       Private Addresses for Mobile IP        25 June 1999

Addresses

   The working group can be contacted via the current chairs:

      Erik Nordmark                        Basavaraj Patil
      Sun Microsystems, Inc.               Nortel Networks Inc.
      17 Network Circle                    2201 Lakeside Blvd.
      Menlo Park, California 94025         Richardson, TX. 75082-4399
      USA                                  USA

      Phone:  +1 650 786-5166              +1 972-684-1489
      Fax:  +1 650 786-5896
      E-mail:  nordmark@sun.com            bpatil@nortelnetworks.com

   Questions about this memo can be directed to:

      Charles E. Perkins                   Pat R. Calhoun
      Sun Microsystems Laboratories        Sun Microsystems Laboratories
      15 Network Circle                    15 Network Circle
      Menlo Park, California 94025         Menlo Park, California 94025
      USA                                  USA

      Phone:  +1-650 786-6464              Phone:  +1 650-786-7733
      EMail:  cperkins@eng.sun.com         EMail:  pcalhoun@eng.sun.com
      Fax:  +1 650 786-6445

      Gabriel Montenegro
      Sun Microsystems Laboratories
      15 Network Circle
      Menlo Park, California 94025
      USA

      Phone:  +1-650-786-6288
      EMail:  gab@eng.sun.com

Perkins, Montenegro, Calhoun     Expires 25 December 1999      [Page 12]