[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09                                 
Mobile IP Working Group                                   Eva Gustafsson
INTERNET DRAFT                                                  Ericsson
6 March 2000                                              Annika Jonsson
                                                                Ericsson
                                                      Charles E. Perkins
                                                   Nokia Research Center

                    Mobile IP Regional Registration
                   draft-ietf-mobileip-reg-tunnel-02.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

   In Mobile IP a mobile node registers with its home agent each time it
   changes care-of address.  If the distance between the visited network
   and the home network of the mobile node is large, the signaling
   delay for these registrations may be long.  We propose a new kind of
   "regional" registrations, i.e., registrations local to the visited
   domain.  Regional registrations reduce the number of signaling
   messages to the home network, and reduce the signaling delay when a
   mobile node moves from one foreign agent to another, within the same
   visited domain.








Gustafsson, Jonsson, Perkins      Expires 6 September 2000      [Page i]


Internet Draft            Regional Registration             6 March 2000




                                Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       2

 2. Terminology                                                        3

 3. Description of the Protocol                                        4
     3.1. General Assumptions . . . . . . . . . . . . . . . . . . .    4
     3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . .    6
     3.3. Advertising Foreign Agent and GFA . . . . . . . . . . . .    7
     3.4. Home Registration . . . . . . . . . . . . . . . . . . . .    8
     3.5. Regional Registration . . . . . . . . . . . . . . . . . .   11

 4. Router Discovery Extensions                                       14
     4.1. Regional Tunnel Management Flag . . . . . . . . . . . . .   14
     4.2. Foreign Agent NAI Extension . . . . . . . . . . . . . . .   14
     4.3. New Regional Registration Reply Code Values . . . . . . .   15

 5. Regional Extensions to Registration Messages                      15
     5.1. GFA IP Address Extension  . . . . . . . . . . . . . . . .   15
     5.2. Hierarchical Foreign Agent Extension  . . . . . . . . . .   16
     5.3. Replay Protection . . . . . . . . . . . . . . . . . . . .   17

 6. Authentication Extensions                                         18

 7. Security Considerations                                           18

 8. Acknowledgements                                                  19

 A. Hierarchical Foreign Agents                                       21
     A.1. Registration with Home Agent  . . . . . . . . . . . . . .   22
     A.2. Regional Registration . . . . . . . . . . . . . . . . . .   24
     A.3. Data Traffic  . . . . . . . . . . . . . . . . . . . . . .   26

Addresses                                                             27










Gustafsson, Jonsson, Perkins      Expires 6 September 2000      [Page 1]


Internet Draft            Regional Registration             6 March 2000


1. Introduction

   This document adds to the Mobile IP protocol, by proposing a means
   for mobile nodes to register locally in a visited domain.  By
   registering locally, the signaling delay is reduced, and this may
   improve the performance of handoff.

   In Mobile IP, as specified in RFC 2002 [8], a mobile node registers
   with its home agent each time it changes care-of address.  If the
   distance between the visited network and the home network of the
   mobile node is large, the signaling delay for these registrations
   may be long.  We propose a solution for performing registrations
   locally in the visited domain:  regional registrations.  Regional
   registrations reduce the number of signaling messages to the home
   network, and reduce the signaling delay when a mobile node moves from
   one foreign agent to another, within the same visited domain.

   When a mobile node first arrives at a visited domain, it performs a
   registration with its home network.  At this registration, we assume
   that the home network generates a registration key [10, 12] for the
   mobile node.  This registration key is distributed to the mobile node
   and to the visited domain, and can be used for authentication of
   regional registrations.

   At registration with the home network, the home agent registers the
   care-of address of the mobile node.  When the visited domain supports
   regional tunnel management, the care-of address that is registered
   at the home agent is the publicly routable address of a Gateway
   Foreign Agent (GFA). This care-of address will not change when the
   mobile node changes foreign agent under the same GFA. When changing
   GFA, a mobile node MUST perform registration at its home network;
   when changing foreign agent under the same GFA, the mobile node MAY
   perform a regional registration within the visited domain.

   The proposed regional tunnel management protocol supports one level
   of foreign agent hierarchy beneath the GFA, but the protocol may be
   extended to support several levels of hierarchy.  Such a hierarchy is
   discussed in the appendix.

   Foreign agents that support regional registrations are also required
   to support registrations according to RFC 2002 [8].  If the mobile
   node chooses not to employ regional registrations, it may register a
   co-located care-of address directly with its home agent, according
   to [8], or, if there is a foreign agent address announced in the
   Agent Advertisement, the mobile node may register that foreign agent
   care-of address with its home agent [8].






Gustafsson, Jonsson, Perkins      Expires 6 September 2000      [Page 2]


Internet Draft            Regional Registration             6 March 2000


2. Terminology

   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 [2].

   In addition, this document frequently uses the following terms:

      AAA server
               Authentication, Authorization and Accounting server.

      Critical type
               A type value for an extension in the range 0-127, which
               indicates that the extension MUST either be known to the
               recipient, or that the message containing the extension
               MUST be rejected.  In other words, an extension with a
               critical type value is non-skippable.

      Foreign Agent (FA)
               As defined in [8].

      Gateway Foreign Agent (GFA)
               A Foreign Agent which has a publicly routable IP address.
               A GFA may, for instance, be placed in or near a firewall.

      Home Agent (HA)
               As defined in [8].

      Home domain
               The domain where the home network and home agent are
               located.

      Home network
               As defined in [8].

      Home Registration
               A registration, processed by the home agent and the
               GFA, using the specification in RFC 2002 possibly with
               additional extensions defined in this document.

      Local Care-of Address
               A Care-of Address which is either assigned to a mobile
               node, or to a foreign agent offering local connectivity
               to a mobile node.  A registration message from the mobile
               node is subsequently sent to a RFA via the local care-of
               address.

      Mobile Node (MN)
               As defined in [8].



Gustafsson, Jonsson, Perkins      Expires 6 September 2000      [Page 3]


Internet Draft            Regional Registration             6 March 2000


      Mobility Agent (MA)
               As defined in [8].

      Network Access Identifier(NAI)
               Some features of this protocol specification rely on
               use of the Network Access Identifier (NAI) [1].  For
               mobile nodes and mobility agents that do not have a NAI,
               regional registration is still useful, but the lack of
               certain features may result in less than optimal results.

      Regional Foreign Agent (RFA)
               A Foreign Agent which may be the target of a request for
               regional registration.

      Regional Registration
               A mobile node performs registration locally at the
               visited domain, by sending a Registration Request to a
               GFA, and receiving a Registration Reply in return.

      Registration Key
               A key used by mobile nodes and mobility agents to secure
               certain control messages related to Mobile IP.

      Visited domain
               The domain where the visited network, the current foreign
               agent and the GFA are located.

      Visited network
               As defined in [8].


3. Description of the Protocol

   This section provides an overview of the regional tunnel management
   protocol.


3.1. General Assumptions

   Our general model of operation is illustrated in figure 1, showing a
   visited domain with foreign agent and GFA, and a home network with a
   home agent.


3.1.1. Visited Domain

   We assume two hierarchy levels of foreign agents in the visited
   domain.  At the top level of the hierarchy, there is at least one
   GFA, which is a foreign agent with additional features.  A GFA



Gustafsson, Jonsson, Perkins      Expires 6 September 2000      [Page 4]


Internet Draft            Regional Registration             6 March 2000


   +---------------------------+                 +----------------+
   |       Visited Domain      |                 |      Home      |
   |                           |   +---------+   |     Network    |
   |                           |   |         |   |                |
   |  +------+      +-------+  |   | Public  |   |    +------+    |
   |  |  FA  |------|  GFA  |-------------------------|  HA  |    |
   |  +--+---+      +-------+  |   | Network |   |    +------+    |
   |     |                     |   |         |   |                |
   +-----|---------------------+   +---------+   +----------------+
         |
      +--+---+
      |  MN  |
      +------+


    Figure 1: Visited domain with a GFA, and a home network with HA.



   must have a publicly routable address.  Beneath a GFA, there are
   one or more regional foreign agents.  We assume that there exist
   established security associations between a GFA and the regional
   foreign agents beneath it.  Multiple hierarchy levels of foreign
   agents are discussed in the Appendix.  When designing a domain
   supporting regional registrations, the regional foreign agents and
   their GFA must be compatible.  That is, they should support the same
   encapsulation types, compression mechanisms etc.

   When a mobile node changes care-of address under the same GFA, it MAY
   perform a regional registration.  If the mobile node changes GFA,
   within a visited domain or between visited domains, it MUST perform a
   home registration.


3.1.2. Registration Key Distribution

   As part of a registration at the home network, registration keys may
   be distributed to the mobile node and to the visited domain, for
   example according to [3, 10, 12].  When regional tunnel management
   is employed, the GFA is the agent within the visited domain which
   receives the registration keys.  This is because the GFA address
   is the registered care-of address of the mobile node at its home
   network.

   These registration keys are subsequently used to enable proper
   authentication for regional registrations.






Gustafsson, Jonsson, Perkins      Expires 6 September 2000      [Page 5]


Internet Draft            Regional Registration             6 March 2000


3.1.3. Authentication Extensions

   With regional tunnel management, a GFA address is registered at
   the home agent as the care-of address of the mobile node.  If a
   Mobile-Foreign Authentication extension is present in a Registration
   Request message, the GFA will perform the authentication.  Similarly,
   if a Foreign-Home Authentication extension is present in a
   Registration Request message, the authentication is performed between
   the GFA and the home agent.


3.2. Protocol Overview


    MN                     FA1                     GFA              HA
    |                       |                       |                |
    | Registration Request  |                       |                |
    |---------------------->|  Reg. Request w/ext.  |                |
    |                       |---------------------->|  Reg. Request  |
    |                       |                       |--------------->|
    |                       |                       |   Reg. Reply   |
    |                       |  Reg. Reply w/ext.    |<---------------|
    |  Registration Reply   |<----------------------|                |
    |<----------------------|                       |                |
    |                       |                       |                |


         Figure 2: Registration at the GFA and the home agent.


   When a mobile node first arrives at a visited domain, it performs a
   registration with its home network.  At this registration, the home
   agent registers the care-of address of the mobile node.  In case the
   visited domain supports regional registrations, the care-of address
   that is registered at the home agent is the address of a GFA. The GFA
   keeps a visitor list of all the mobile nodes currently registered
   with it.

   As part of a home registration, the home network typically
   distributes a registration key for the mobile node and the GFA. It is
   expected to be used for authentication of regional registrations.

   Since the care-of address registered at the home agent is the GFA
   address, it will not change when the mobile node changes foreign
   agent under the same GFA. Thus, the home agent does not need to be
   informed of any mobile node movements beneath the GFA.

   Figure 2 illustrates the signaling message flow for registration
   with the home network.  After the registration at the home agent,



Gustafsson, Jonsson, Perkins      Expires 6 September 2000      [Page 6]


Internet Draft            Regional Registration             6 March 2000


   the home agent records the GFA address as the care-of address of the
   mobile node.  If the GFA address was assigned to the mobile node, the
   Registration Reply has an extension indicating the IP address of the
   GFA to the mobile node.


    MN                     FA2                            GFA       HA
    |                       |                              |         |
    | Registration Request  |                              |         |
    |---------------------->| Registration Request w/ext.  |         |
    |                       |----------------------------->|         |
    |                       | Registration Reply w/ext.    |         |
    | Registration Reply    |<-----------------------------|         |
    |<----------------------|                              |         |
    |                       |                              |         |


              Figure 3: Regional registration at the GFA.


   Figure 3 illustrates the signaling message flow for regional
   registration.  Even though the mobile node's local care-of address
   changes, the home agent continues to record the GFA address as the
   care-of address of the mobile node.


3.3. Advertising Foreign Agent and GFA

   A foreign agent typically announces its presence via an Agent
   Advertisement message [8].  If the domain to which a foreign agent
   belongs supports regional registrations, the following applies to the
   Agent Advertisement message.

   The 'I' flag (see Section 4) MUST be set to indicate that the
   domain supports regional tunnel management, and that a GFA address
   is advertised in the Agent Advertisement message.  If the 'I' bit
   is set, there MUST be at least one care-of address in the Agent
   Advertisement message.

   If the 'I' bit is set, and there is only one care-of address, it is
   the address of the GFA. When only the GFA address is present, and
   thus the local foreign agent is not advertising its care-of address,
   the FA-NAI (see section 4.2) SHOULD also be present to enable the
   mobile node to determine whether or not it has changed foreign agent
   (so that a new regional registration may be initiated).  The mobile
   node also uses the FA-NAI to decide whether or not it is in its home
   domain.  The decision is based on whether the realm part of the
   advertised FA-NAI matches the mobile node's realm.  If the 'I' bit




Gustafsson, Jonsson, Perkins      Expires 6 September 2000      [Page 7]


Internet Draft            Regional Registration             6 March 2000


   is set, and there are multiple care-of addresses, the first care-of
   address is the local FA, and the last care-of address is the GFA.


3.4. Home Registration

   This section describes registration at the home network.
   Registration at the home network is performed when a mobile node
   first arrives at a visited domain, when it requests a new home agent,
   or when it changes GFA. Registration at the home network is also
   performed to renew bindings which would otherwise expire soon.


3.4.1. Mobile Node Considerations

   Suppose the mobile node receives an Agent Advertisement from the
   foreign agent.  If the 'I' flag in the Agent Advertisement is set, if
   the mobile node determines that it is in a visited domain, it SHOULD
   either use the advertised GFA address in the care-of address field
   in the Registration Request message, or set this field to zero to
   request to be assigned a GFA. In the latter case, the mobile node
   and its home agent MUST support the GFA IP address extension (see
   section 5.1).  The home agent will then register the GFA address
   as the care-of address of the mobile node.  If the mobile node is
   assigned a GFA, it learns the address of that GFA from the GFA IP
   address extension in the Registration Reply.  If the mobile node,
   when receiving an Agent Advertisement, determines that it is in its
   home domain, it acts according to [8].  The mobile node may also
   find the GFA address by some other means outside the scope of this
   specification.  If the 'I' bit is set, but the GFA address is zero
   (0), the mobile node MUST check to make sure that it receives a GFA
   IP address extension as part of any home registration, or else send
   its home registration using the care-of address of some previously
   known GFA in the same visited domain.

   Suppose a mobile node with a co-located care-of address wishes to use
   the address of GFA as its care-of address in a Registration Request
   message.  The mobile node MAY then generate a Registration Request
   message, with the GFA address in the care-of address field, and send
   it directly to the GFA (not via a foreign agent).  In this case,
   the mobile node MUST add a Hierarchical Foreign Agent extension,
   including its co-located care-of address, to the Registration Request
   before sending it.  The Hierarchical Foreign Agent extension SHOULD
   be placed after the MN-HA authentication extension.  It SHOULD be
   authenticated by using the MN-FA authentication extension.  The
   authentication data SHOULD be calculated using a mobility security
   association that has been established with the GFA.





Gustafsson, Jonsson, Perkins      Expires 6 September 2000      [Page 8]


Internet Draft            Regional Registration             6 March 2000


   Upon receipt of an Agent Advertisement message with the 'I' flag set
   and a FA-NAI extension, the mobile node compares the domain part of
   the foreign agent NAI with the domain part of its own NAI, to help
   in the determination about whether it is in its home domain or in
   a visited domain.  If the NAIs do not match, the mobile node MUST
   assume it is in a foreign domain.  Otherwise, if the mobile node
   determines that it is in its home domain, and furthermore that it
   is attached to its home network, it acts as defined in [8].  If the
   mobile node determines that it is in its home domain, but not on its
   home network, the mobile node SHOULD behave as defined in [8], and
   not register via a GFA.

   If the mobile node determines that it is in a visited domain, and if
   it registers via a foreign agent, the mobile node SHOULD register
   the GFA address as its care-of address.  This can be done either
   by (i) putting the GFA address in the care-of address field in the
   Registration Request message; or (ii) setting the care-of address
   field in the Registration Request message to zero, thereby requesting
   to be assigned a GFA care-of address.

   All of these operations are still possible if the mobile node
   receives an Agent Advertisement with the 'R' bit set.  In that case,
   the mobile node, even if it has a co-located care-of address, still
   formulates the same Registration Request message with extensions,
   but it sends the message to the advertising foreign agent (not, for
   example, the GFA).

   If the mobile node had requested to be dynamically assigned a GFA, it
   learns the address of that GFA from the GFA IP address extension in
   the Registration Reply.


3.4.2. Foreign Agent Considerations

   When the foreign agent receives a Registration Request message
   from a mobile node, it extracts the care-of address field in the
   Registration Request message, to find the GFA to which the message
   shall be relayed.  If the care-of address field is set to zero, the
   foreign agent assigns a GFA to the mobile node, by some means not
   described in this specification, and adds a GFA IP Address extension
   to the Registration Request message.  The foreign agent MUST NOT
   insert the GFA address directly in the care-of address field in the
   Registration Request message, since that would cause the Mobile-Home
   authentication to fail.

   If the care-of address in the Registration Request is the address of
   a GFA (or zero), the foreign agent adds a Hierarchical Foreign Agent
   extension, including its own address, to the Registration Request
   message, and relays it to the GFA. If the care-of address in the



Gustafsson, Jonsson, Perkins      Expires 6 September 2000      [Page 9]


Internet Draft            Regional Registration             6 March 2000


   Registration Request is the address of the foreign agent, the foreign
   agent relays the message directly to the home agent, as described
   in [8].

   If the registration request has the 'T' bit set, the mobile node is
   requesting Reverse Tunneling [7].  In this case, the foreign agent
   has to tunnel packets from the mobile node to the GFA for further
   handling.  The GFA will then decapsulate the packets from the foreign
   agent and re-encapsulate them for further delivery back to the home
   agent.  These actions are required because the home agent has to
   receive such packets from the expected care-of address (i.e., that of
   the GFA) instead of the local care-of address.


3.4.3. GFA Considerations

   For each pending or current registration, the GFA maintains a visitor
   list entry as described in [8].  In addition to the fields required
   in [8], the list entry MUST contain:

    -  the current care-of address of the mobile node, i.e., the foreign
       agent (or co-located) address in the Hierarchical Foreign Agent
       extension.
    -  the remaining Lifetime of the regional registration.
    -  the style of replay protection in use for the regional
       registration
    -  the Identification value for the regional registration

   If the Registration Request message contains a Replay Protection
   extension (see section 5.3) requesting a style of replay protection
   not supported by the GFA, the GFA MUST reject the registration
   request and send a Registration Reply with the value in the Code
   field set to UNSUPPORTED_REPLAY_PROTECTION.

   If the Hierarchical Foreign Agent extension comes after the
   MN-FA authentication extension, the GFA MUST remove it from the
   Registration Request message.  The GFA then sends the request to the
   home agent, possibly via AAA servers as described in [3].

   Upon receipt of the Registration Reply message, the GFA consults
   its pending registration record to find the care-of address within
   its domain that is currently used by the mobile node, and sends the
   Registration Reply to that care-of address.


3.4.4. Home Agent Considerations

   The Registration Request is processed by the home agent as described
   in [8], with additional processing for extensions specified in



Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 10]


Internet Draft            Regional Registration             6 March 2000


   this document.  If a home agent receives a Registration Request
   message with the care-of address set to zero, and a GFA IP Address
   extension, it MUST register the IP address of the GFA as the care-of
   address of the mobile node in its mobility binding list.  If the
   Registration Request is accepted, the home agent MUST include the
   GFA IP Address extension in the Registration Reply, before the
   Mobile-Home Authentication extension.  If the home agent does not
   support the GFA IP address extension, it MUST deny any registration
   request containing that extension.  If a home agent receives a
   Registration Request message with the care-of address set to zero,
   but no GFA IP Address extension, it MUST deny the request and send an
   error.

   Otherwise, the home agent then generates a Registration Reply
   message, including the GFA IP Address extension, and sends it back to
   the GFA. As with the Registration Request, the message may be relayed
   directly, or via AAA servers.


3.4.5. New Code value for Registration Reply

   The values to use within the Code field of the Registration Reply are
   defined in [8].  In addition, the following values are defined:

   Registration denied by the GFA:

       -  TBD requested replay protection unavailable (see
          section 5.3)


3.5. Regional Registration

   This section describes regional registration.  Once the home agent
   has registered the GFA address as the care-of address of the mobile
   node, the mobile node may perform regional registrations.  When
   performing regional registrations, the mobile node may either
   register a foreign agent care-of address or a co-located address with
   the GFA. In the following, we assume that a home registration has
   already occurred, as described in section 3.4, and that the GFA has a
   mobility security association with the mobile node.

   Suppose the mobile node moves from one foreign agent to another
   foreign agent within the same visited domain.  It will then receive
   an Agent Advertisement from the new foreign agent.  Suppose further
   that the Agent Advertisement indicates that the visited domain
   supports regional registrations, and that either the advertised GFA
   address is the same as the one the mobile node has registered as its
   care-of address during its last home registration, or the realm part
   of the newly advertised FA-NAI matches the FA-NAI advertised by the



Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 11]


Internet Draft            Regional Registration             6 March 2000


   mobile node's previous foreign agent.  Then, the mobile node can
   perform a regional registration with this GFA.

   The mobile node issues a Registration Request message to the new
   foreign agent.  The request is authenticated using the registration
   key that was distributed to the GFA and to the mobile node from the
   home network.  When a mobile node performs a regional registration,
   it addresses the Registration Request to the GFA, and inserts the
   GFA IP address in the home agent field.  The MN-HA Authentication
   Extension is replaced by a MN-GFA Authentication Extension.  The
   care-of address should be set to the address of the local foreign
   agent, or else zero if the local foreign agent is not advertising its
   own care-of address (see section 3.4.1).

   If the Registration Request does not contain its care-of address,
   the foreign agent adds a Hierarchical Foreign Agent extension to the
   message and relays it to the GFA. Based on the information in the
   Hierarchical Foreign Agent extension, the GFA updates the mobile
   node's current point of attachment in its visitor list.  The GFA then
   issues a Registration Reply to the mobile node via the foreign agent.

   If the advertised GFA is not the same as the one the mobile node has
   registered as its care-of address, and if the mobile node is still
   within the same domain as it was when it registered that care-of
   address, the mobile node MAY try to perform a regional registration
   with its registered GFA. If the foreign agent cannot support regional
   registration to a GFA, other than advertised, the foreign agent
   denies the regional registration with code 'unknown GFA'. In this
   case the MN has to do a new home registration via the new GFA.


3.5.1. Mobile Node Considerations

   For each pending or current registration (that is, either
   registration with the home network or regional registration), the
   mobile node maintains the information described in [8].  In addition
   to that, the mobile node MUST maintain the following information, if
   present:

    -  the GFA address
    -  the style of replay protection in use for the regional
       registration
    -  the Identification value for the regional registration

   It is essential for the mobile node to be able to distinguish
   regional registrations from registrations with the home network,
   since it needs to know that when using regional registration, the
   nonces are not synchronized with its home agent.  Further, in order




Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 12]


Internet Draft            Regional Registration             6 March 2000


   to renew bindings before the lifetime expires, a home registration
   MUST be directed to the home network.

   The replay protection for registrations and regional registrations
   is performed as described in [8].  Since the mobile node performs
   regional registrations at the GFA in parallel with registrations at
   its home network, the mobile node MUST keep one replay protection
   mechanism and sequence for the GFA, and a separate mechanism and
   sequence for the home agent.  Replay protection may also be provided
   at the foreign agent by the challenge-response mechanism, as
   described in [4].

   When a mobile node, which has already registered a GFA care-of
   address with its home agent, changes foreign agent within the same
   domain and receives an Agent Advertisement which advertises another
   GFA address, it MAY still generate a Registration Request message
   destined to its old GFA.


3.5.2. Foreign Agent Considerations

   When the foreign agent receives a Registration Request message
   from a mobile node, addressed to a GFA, it processes the message
   generally according the rules of processing a Registration Request
   message addressed to a home agent (see section 3.4.2).  The only
   difference is that the home agent field contains the GFA IP address.
   If that address belongs to a known GFA, the foreign agent forwards
   the request to the indicated GFA. Otherwise, the foreign agent MUST
   generate a Registration Reply with error code 'unknown GFA'.


3.5.3. GFA Considerations

   The GFA MUST NOT accept a request for a regional registration if the
   lifetime of the mobile node's registration with its home agent has
   expired.  If the GFA accepts a request for regional registration, it
   MUST set the lifetime to be no greater than the remaining lifetime
   of the mobile node's registration with its home agent, and put this
   lifetime into the corresponding Registration Reply.

   If the GFA receives a tunneled packet from a foreign agent in its
   domain, then after decapsulation the GFA looks to see whether it has
   an entry in its visitor list for the source IP address of the inner
   IP header after decapsulation.  If so, then it checks the visitor
   list to see whether reverse tunneling has been requested; if it was
   requested, the GFA re-encapsulates the packet with its own address
   as the source IP address, and the address of the home agent as the
   destination IP address.




Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 13]


Internet Draft            Regional Registration             6 March 2000


4. Router Discovery Extensions

   This section specifies a new flag within the Mobile IP Agent
   Advertisement, and an optional extension to the ICMP Router Discovery
   Protocol [6].


4.1. Regional Tunnel Management Flag

   The Agent Advertisement message MAY include a flag indicating
   whether the domain, to which the foreign agent generating the Agent
   Advertisement belongs, supports regional tunnel management.  The flag
   is inserted in one of the reserved fields, after the flags defined
   in [8].

   The flag is defined as follows:

      I          Regional tunnel management.  This domain supports
                 regional registrations.


4.2. Foreign Agent NAI Extension

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


                 Figure 4: Foreign Agent NAI Extension



      Type       TBD

      Length     The length in bytes of the FA NAI field

      FA NAI     A string in the NAI format defined in [1].

   The foreign agent SHOULD include its NAI in the Agent Advertisement
   message.  If present, the Foreign Agent NAI (FA NAI) extension
   MUST appear in the Agent Advertisement message after any of the
   advertisement extensions defined in [8].





Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 14]


Internet Draft            Regional Registration             6 March 2000


   By comparing the domain part of the foreign agent NAI with the domain
   part of its own NAI, the mobile node can determine whether it is in
   its home domain or in a visited domain, and whether it has changed
   domain since it last registered.


4.3. New Regional Registration Reply Code Values

   For a Registration Reply, the following additional Code values
   are defined in addition to those specified in RFC 2002 [8] or in
   section 3.4.5:

   Registration denied by the FA:

         TBD        unknown GFA

         TBD        GFA unreachable (ICMP error received)

         TBD        GFA host unreachable (ICMP error received)

         TBD        GFA port unreachable (ICMP error received)

         TBD        GFA unreachable (other ICMP error received)


5. Regional Extensions to Registration Messages

   In this section we specify new Mobile IP registration extensions for
   the purpose of managing regional registrations.


5.1. GFA IP Address Extension

   The mobile node indicates that it needs the IP address of a GFA by
   sending a a Registration Request message with the care-of address
   field set to zero.  The foreign agent assigns a GFA to the mobile
   node, and adds a GFA IP Address extension to the Registration Request
   before relaying it to the GFA in question.  The GFA IP Address
   extension MUST appear in the Registration Request message before the
   Foreign-Home Authentication extension, if present.

   If a home agent receives a Registration Request message with the
   care-of address set to zero, and a GFA IP Address extension, it
   registers the IP address of the GFA as the care-of address of the
   mobile node.  When generating a Registration Reply message, the home
   agent MUST include the GFA IP Address extension from the Registration
   Request in the Registration Reply message.  The GFA IP Address
   extension MUST appear in the Registration Reply message before the
   Mobile-Home Authentication extension.



Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 15]


Internet Draft            Regional Registration             6 March 2000


   The GFA IP Address 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    |        GFA IP Address ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               GFA IP Address         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 5: The GFA IP Address extension


      Type             TBD

      Length           4

      GFA IP Address   The GFA IP Address field contains the Gateway
                       Foreign Agent's publicly routable address.


5.2. Hierarchical Foreign Agent Extension

   The Hierarchical Foreign Agent extension MAY be present in a
   Registration Request message.  When this extension is added to a
   registration request by a foreign agent, the receiving mobility agent
   sets up a pending registration record for the mobile node, using
   the IP address in the Hierarchical Foreign Agent extension as the
   care-of address for the mobile node.  Furthermore, in this case, the
   extension MUST be appended at the end of all previous extensions
   that had been included in the registration message as received by
   the foreign agent.  When the receiving foreign agent receives the
   registration message, it MUST remove the Hierarchical Foreign Agent
   extension added by the sending foreign agent.

   The Hierarchical Foreign Agent extension is defined as follows:

      Type       TBD (Hierarchical Foreign Agent)

      Length     4

      FA IP Address The IP Address of the foreign agent relaying the
                 Registration Request.







Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 16]


Internet Draft            Regional Registration             6 March 2000


       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 IP Address ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              FA IP Address ....      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           Figure 6: The Hierarchical Foreign Agent Extension



5.3. Replay Protection

   When a mobile node uses Mobile IP to register a care-of address
   with its home agent, the style of replay protection used for the
   registration messages is assumed to be known by way of a Mobility
   Security Association that is required to exist between the mobile
   node and the home agent receiving the request.  No such pre-existing
   security association between the mobile node and the GFA is likely
   to be available.  By default, the mobile node SHOULD treat replay
   protection for Regional Registration messages exactly as specified in
   RFC 2002 [8] for timestamp-based replay protection.

   If the mobile node requires nonce-based replay protection, also as
   specified in RFC 2002, it MAY append a Replay Protection extension to
   the Registration Request message.  The format of this extension is
   shown in figure 7.


       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    |    Replay Protection Style    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Initial Identification                      +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 7: The Replay Protection Extension



      Type       TBD (Replay Protection)

      Length     2



Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 17]


Internet Draft            Regional Registration             6 March 2000


      Replay Protection Style
                 An integer specifying the style of replay protection
                 desired by the mobile node.

      Initial Identification
                 The timestamp or nonce to be used for initial
                 synchronization for the replay mechanism.

   Admissible values for the Replay Protection Style are as follows:

     0 timestamp [8]
     1 nonce [8]

   Replay protection MAY also be provided through a challenge-response
   mechanism, at the foreign agent issuing the Agent Advertisement, as
   described in  [4].


6. Authentication Extensions

   Two new subtypes for the Generalized Authentication Extension [4] are
   defined in this document.  Both are used to secure the Hierarchical
   Foreign Agent (HFA) extension to the Registration Request message.
   Another authentication extension is necessary because HFA extension
   is typically added after the MN-HA (or MN-AAA [5]) authentication
   extension.

   The FA-FA authentication extension is used by regional foreign
   agents.  The MN-GFA authentication extension is used whenever the
   mobile node has a co-located address.  Furthermore, the MN-GFA
   extension MUST be used to provide authentication information for a
   Regional Registration Request that is not processed by the mobile
   node's home agent.

   The subtype values are as follows:

      Subtype Name           Value
      ---------------------- ------
      FA-FA authentication   4
      MN-GFA authentication  5




7. Security Considerations

   This document proposes a method for a mobile node to register
   locally in a visited domain.  The authentication extensions to be
   used are those defined either in [8], [11], or [3].  Furthermore,



Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 18]


Internet Draft            Regional Registration             6 March 2000


   we assume key distribution to be performed according to, for
   instance, [3], [10] or [12].

   If the Hierarchical Foreign Agent extension is appended to the a
   registration request message, that extension SHOULD be followed by
   an authentication extension to prevent any modification to the data.
   Likewise, if the GFA IP Address extension is added to such a message,
   it should be also followed by an authentication extension.


8. Acknowledgements

   This document is a logical successor to documents written with
   Pat Calhoun and Gabriel Montenegro; thanks to them and their many
   efforts to help explore this problem space.  Many thanks also to Jari
   Malinen at the Helsinki University of Technology for his commentary
   on a rough version of this document, and providing motivation for
   section A.2.1.


References

    [1] B. Aboba and M. Beadles.  The Network Access Identifier.
        Request for Comments (Proposed Standard) 2486, Internet
        Engineering Task Force, January 1999.

    [2] S. Bradner.  Key words for use in RFCs to Indicate Requirement
        Levels.  Request for Comments (Best Current Practice) 2119,
        Internet Engineering Task Force, March 1997.

    [3] P. Calhoun and C. Perkins.  DIAMETER Mobile IP Extensions.
        Internet Draft, Internet Engineering Task Force.
        draft-calhoun-diameter-mobileip-05.txt, December 1999.  Work in
        progress.

    [4] P. Calhoun and C. E. Perkins.  Mobile IP Foreign Agent
        Challenge/Response Extension.
        draft-ietf-mobileip-challenge-08.txt, January 2000.  (work in
        progress).

    [5] Pat R. Calhoun and Charles E. Perkins.  Mobile IP Network
        Address Identifier Extension.
        draft-ietf-mobileip-mn-nai-07.txt, January 2000.  (work in
        progress).

    [6] S. Deering.  ICMP Router Discovery Messages.  Request for
        Comments (Proposed Standard) 1256, Internet Engineering Task
        Force, September 1991.




Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 19]


Internet Draft            Regional Registration             6 March 2000


    [7] G. Montenegro.  Reverse Tunneling for Mobile IP.  Request for
        Comments (Proposed Standard) 2344, Internet Engineering Task
        Force, May 1998.

    [8] C. Perkins.  IP Mobility Support.  Request for Comments
        (Proposed Standard) 2002, Internet Engineering Task Force,
        October 1996.

    [9] C. Perkins.  Mobile-IP Local Registration with Hierarchical
        Foreign Agents.  draft-perkins-mobileip-hierfa-00.txt, February
        1996.  (work in progress).

   [10] C. E. Perkins and D. Johnson.  Registration Keys for Route
        Optimization.
        draft-ietf-mobileip-regkey-01.txt, February 2000.  (work in
        progress).

   [11] C. E. Perkins and D. Johnson.  Route Optimization in Mobile
        IP.
        draft-ietf-mobileip-optim-09.txt, February 2000.  (work in
        progress).

   [12] Charles E. Perkins and Pat R. Calhoun.  AAA Registration Keys
        for Mobile IP.
        draft-ietf-mobileip-aaa-key-00.txt, June 1999.  (work in
        progress).


























Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 20]


Internet Draft            Regional Registration             6 March 2000


A. Hierarchical Foreign Agents

   The main body of this specification assumes two hierarchy levels of
   foreign agents in the visited domain.  At the top level, there is one
   or several GFAs, and on the lower level, there is a number of foreign
   agents.  The structure can be extended to include multiple hierarchy
   levels of foreign agents beneath the GFA level (Figure 8).  Such
   multiple hierarchy levels are discussed in this appendix.


                         +--------+
                         |        |
                         |  GFA   |
                         |        |
                         +--------+
                          /   |  \
                        ...  ...  ...
                              |
                         +--------+
                         |        |
                         |  RFA3  |
                         |        |
                         +--------+
                          /       \
                   +--------+   +--------+
                   |        |   |        |
                   |   FA2  |   |   FA1  |
                   |        |   |        |
                   +--------+   +--------+
                        |            |
                        |       +--------+
                       ...      |        |
                                |   MN   |
                                |        |
                                +--------+


  Figure 8: Domain with a GFA and multiple hierarchies of FAs, enabled
                      for regional registrations.


   We assume that security associations have been established among
   a GFA and all the foreign agents beneath it in the hierarchy.  As
   before, we assume that when a mobile node performs registration at
   its home network, registration keys are generated and distributed to
   the mobile node and to the GFA. The GFA may then in turn distribute
   the registration keys to the foreign agents beneath it in the
   hierarchy, using methods not specified in this document.




Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 21]


Internet Draft            Regional Registration             6 March 2000


A.1. Registration with Home Agent

      DISCUSSION (for multiple levels, as in appendix):

         How does regional registration work on the home
         network, where the mobile node should NOT have to go
         through a GFA?

   As described in this specification, a foreign agent announces itself
   and a GFA in the Agent Advertisement in the first and last address
   in the care-of address field in the Mobility Agent Advertisement
   extension [8].  If there is a hierarchy of foreign agents between the
   GFA and the announcing foreign agent, the foreign agent MAY include
   the corresponding addresses in order between its own address (first)
   and the GFA address (last):

    -  Address of announcing foreign agent
    -  Address of the next higher-level Regional Foreign Agent (RFA)
    -  ...
    -  Address of GFA

   If a foreign agent advertises the entire hierarchy between itself and
   the GFA, the Registration Request messages MUST be delivered to each
   care-of address in turn within that hierarchy.

   When newly arriving at a visited domain, the mobile node sends
   a Registration Request, with the care-of address set to the GFA
   address announced in the Agent Advertisement.  The mobile node may
   also request a GFA to be assigned, as described earlier in this
   specification.

   When the foreign agent closest to the mobile node receives the
   Registration Request, processing is as described in Section 3.4.2.
   It adds a Hierarchical Foreign Agent extension to the Registration
   Request, including its own address, and relays the Registration
   Request to the next RFA in the hierarchy toward the GFA.

   The next RFA receives the Registration Request.  For each pending
   or current registration, an RFA maintains a visitor list entry.  In
   addition to the list entry contents (described in [8]), the list
   entry for regional registrations MUST contain:

    -  the address of the next lower-level RFA, or FA, in the hierarchy
    -  the remaining Lifetime of the regional registration.

   The RFA removes the Hierarchical Foreign Agent extension that the
   last FA or RFA added, and adds a new Hierarchical Foreign Agent
   extension with its own address.  This procedure is repeated at each
   RFA, or FA, in the hierarchy under the GFA.



Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 22]


Internet Draft            Regional Registration             6 March 2000


   When the GFA receives the Registration Request, it removes the
   Hierarchical Foreign Agent extension and caches information about
   the next lower-level RFA in the hierarchy.  It then relays the
   Registration Request to the home agent, possibly via AAA servers.

   For each pending or current registration, the GFA maintains a visitor
   list entry as described in [8].  In addition to the list entry
   contents required in [8], the list entry MUST contain:

    -  the address of the next lower-level RFA in the hierarchy
    -  the remaining Lifetime of the regional registration.

   If there is only one level of hierarchy beneath the GFA, the address
   of the next lower-level RFA is the current care-of address of the
   mobile node, as stated in Section 3.4.3, unless the mobile node has
   registered a co-located care-of address, as discussed in  3.4.1.

   The home agent, as described before, processes the Registration
   Request, stores the GFA address as the current care-of address of
   the mobile node, generates a Registration Reply, and sends it to the
   GFA. The home agent also distributes a registration key to the mobile
   node and to the GFA, for instance by using a Home-Mobile Key Reply
   extension and a Foreign Agent Key Reply extension [10], added to the
   Registration Reply message, or via other AAA functions [12].

   When the GFA receives the Registration Reply, it checks its pending
   registration request record to see which next lower-level RFA to send
   the Registration Reply message to.  If, for instance, the Foreign
   Agent Key Reply extension [11] is present, the GFA decrypts the key.
   It SHOULD then add, for instance, a new Foreign Agent Key Reply
   extension to the Registration Reply message, before relaying it to
   the next foreign agent.  The new Foreign Agent Key Reply extension
   contains the registration key, encrypted with a secret shared between
   the GFA and the next lower-level RFA in the hierarchy.  Similar
   procedures are to be used with [12].

   The next lower-level RFA receives the Registration Request and checks
   its pending registration request record to see which lower-level
   foreign agent should next receive the Registration Reply.  It
   extracts, decrypts and caches the registration key, and relays the
   Registration Reply to the next foreign agent.  This procedure is
   repeated in every foreign agent in the hierarchy, until the message
   reaches the foreign agent closest to the mobile node.

   When the lowest-level foreign agent receives the Registration Reply,
   it checks its cached information, as described in [8], and relays the
   Registration Reply to the mobile node.





Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 23]


Internet Draft            Regional Registration             6 March 2000


A.2. Regional Registration

   A Registration Request is forwarded to the GFA by way of one or
   more intermediate regional foreign agents.  When the Registration
   Request message arrives at the first foreign agent, the foreign
   agent checks its visitor list to see if this mobile node is already
   registered with it.  If it is not, the foreign agent checks which
   next higher-level RFA to relay the Registration Request to.  It adds
   a Hierarchical Foreign Agent extension to the Registration Request,
   including its address, and relays the message to the next RFA in the
   hierarchy toward the GFA.

   The next RFA checks its visitor list to see if the mobile node is
   already registered with it.  If it is not, the RFA removes the
   Hierarchical Foreign Agent extension and adds a new one, with its own
   address, and relays the message to the next higher-level RFA in the
   hierarchy toward the GFA.

   This process is repeated in each RFA in the hierarchy, until an RFA
   recognizes the mobile node as already registered.  This RFA may be
   the GFA, or any RFA beneath it in the hierarchy.  If the mobile node
   is already registered with this RFA, the RFA generates a Registration
   Reply and sends it to the next lower-level RFA in the hierarchy.  The
   lifetime field in the Registration Reply is set to the remaining
   lifetime that was earlier agreed upon between the mobile node and
   the GFA. If the lifetime of the GFA registration has expired, the
   Registration Request is relayed all the way to the GFA.

   If the hierarchy between the advertising foreign agent and the GFA is
   announced in the Agent Advertisement, the mobile node may generate a
   Registration Request not destined to the GFA, but to the closest RFA
   with which it can register.

      DISCUSSION:

         Need to specify how nonces can be used with multiple
         levels of hierarchy.  Use idea of "nonce vector" from
         old hierarchical foreign agent proposal [9].  If
         structure of foreign agents with private addresses is
         to be hidden from the mobile node, define new FA-FA
         extensions to transmit current nonce values.

   Replay protection can be provided at the announcing foreign agent,
   through the challenge-response mechanism described in  [4].  If the
   GFA, and the RFAs in the hierarchy, trust the announcing foreign
   agent to perform the replay protection, timestamps or nonces between
   the mobile node and the GFA, or between the mobile node and each RFA,
   are not needed.




Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 24]


Internet Draft            Regional Registration             6 March 2000


   If a mobile node includes a Hierarchical Foreign Agent extension in
   its Registration Request message, it MAY insert the extension before
   the MN-HA or MN-FA authentication extension.  In this case, the
   Hierarchical Foreign Agent extension MUST NOT be removed by the GFA
   or any other RFA prior to the generation of the Registration Reply
   message.

   If more than one Hierarchical Foreign Agent extension is inserted
   by the mobile node into the registration message, the order of the
   extensions MUST be maintained through the hierarchy.  When sending
   a Registration Reply, the GFA MUST ensure that the order of the
   Hierarchical Foreign Agent extensions is reversed from the order
   found in the Registration Request.


A.2.1. Deregistration

   If the GFA receives a Registration Request message from a mobile
   node, and the mobile node uses a foreign agent care-of address
   for its regional registration, then there are the following
   possibilities:

   1.  The mobile node is registering at the same foreign agent as
   during its previous registration.

   2.  The mobile node is registering at a different foreign agent and
   using smooth handoff extensions [11].

   3.  The mobile node is registering at a different foreign agent but
   not using any smooth handoff extensions.

   In case (1), there is no need for a deregistration, while in case
   (3) and (2), there is.  Since any foreign agent in the hierarchy,
   that recognizes the mobile node as already registered, may generate a
   Registration Reply, not all Registration Requests will reach the GFA.
   Therefore, if old locations are not deregistered, it is possible that
   tunnels are not correctly redirected when a mobile node moves back to
   a previous foreign agent.

   In case (2), when the mobile node uses smooth handoff extensions, the
   previous foreign agent is notified that the mobile node has moved.
   The previous foreign agent then forwards traffic to the new foreign
   agent.

   In case (3), the mobile node sends a Registration Request to its new
   foreign agent.  If the mobile node does not request smooth handoff,
   the previous foreign agent is not notified.  The Registration Request
   is relayed upwards in the hierarchy until it reaches a foreign agent
   that recognizes the mobile node as already registered.  This foreign



Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 25]


Internet Draft            Regional Registration             6 March 2000


   agent generates a Registration Reply and sends it downwards in the
   hierarchy toward the new location of the mobile node, updating
   its own visitor list.  At the same time, it also sends a Binding
   Update with a zero lifetime to the previous care-of address it had
   registered for the mobile node.  Each foreign agent receiving the
   (authenticated!)  Binding Update removes the mobile node from its
   visitor lists.  The Binding Update is relayed down to the care-of
   address of the mobile node known to that foreign agent, and each
   foreign agent in the hierarchy receiving this notification removes
   the mobile node from its visitor list.

   If the mobile node uses a co-located care-of address for its regional
   registration, there is no need to deregister its previous location
   when it moves, since regional registrations with a co-located care-of
   address are performed directly with the GFA.


A.3. Data Traffic

   When a correspondent node sends traffic to the mobile node, the
   traffic arrives at the home agent, and the home agent tunnels the
   traffic to the GFA. The GFA or RFA at each level of the hierarchy has
   a visitor list for the mobile node, showing the address of the next
   lower-level RFA or FA in the hierarchy.

   Thus, a datagram arriving at the top level of the hierarchy, that
   is, the GFA, will be decapsulated and re-encapsulated with the
   new tunnel endpoint at the next lower-level RFA in the hierarchy.
   This decapsulation and re-encapsulation occurs at each level of
   the hierarchy, until the datagram reaches the last tunnel endpoint
   which is either the mobile node itself (in case of a co-located
   care-of address) or a foreign agent that can deliver the decapsulated
   datagram to the mobile node with no further special Mobile IP
   handling.

   Note that the actual decapsulation need not occur at each step of
   the hierarchy.  Instead, the foreign agent at that level can merely
   change the source and destination IP addresses of the encapsulating
   IP header.

   Traffic from the mobile node is sent as described in [8] or [7].

   According to the Route Optimization specification [11], Binding
   Updates send to the correspondent node from the Home Agent
   will contain the address of the GFA, since this is the only
   care-of address known to the Home Agent.  Therefore, Binding Updates
   from the mobile node sent to the correspondent node SHOULD also have
   the care-of address belonging to the GFA. This also has the advantage
   of reducing the number of Binding Update messages that have to be



Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 26]


Internet Draft            Regional Registration             6 March 2000


   sent to the correspondent node, at a modest increase in routing path
   length.  Furthermore, the local network domain may be configured to
   admit such traffic into the local domain only if packets are tunneled
   directly to the GFA.


Addresses

   The working group can be contacted via the current chairs:


        Basavaraj Patil               Phil Roberts
        Nokia Corporation             Motorola
        M/S M8-540
        6000 Connection Drive         1501 West Shure Drive
        Irving, TX 75039              Arlington Heights, IL 60004
        USA                           USA
        Phone:  +1 972-894-6709       Phone:  +1 847-632-3148
        EMail:  Raj.Patil@nokia.com   EMail:  QA3445@email.mot.com
        Fax :  +1 972-894-5349

   Questions about this memo can be directed to:

     Eva Gustafsson                    Annika Jonsson
     Ericsson Inc.                     Ericsson Radio Systems AB
     1555 Adams Drive                  Network and Systems Research
     Menlo Park, CA 94025              SE-164 80 Stockholm
     USA                               SWEDEN
     +1 510 305-6107                   +46 8 4047242
     eva.gustafsson@ericsson.com       annika.jonsson@ericsson.com


     Charles E. Perkins
     Nokia Research Center
     313 Fairchild Drive
     Mountain View, California 94043
     USA

     Phone:  +1-650 625-2986
     EMail:  charliep@iprg.nokia.com
     Fax:  +1 650 625-2502











Gustafsson, Jonsson, Perkins     Expires 6 September 2000      [Page 27]