[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
2 March 2001                                              Annika Jonsson
                                                                Ericsson
                                                      Charles E. Perkins
                                                   Nokia Research Center

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

   Using 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" registration, i.e., registration 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 2 September 2001      [Page i]


Internet Draft            Regional Registration             2 March 2001




                                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

 4. Home Registration                                                  8
     4.1. Mobile Node Considerations  . . . . . . . . . . . . . . .    8
     4.2. Foreign Agent Considerations  . . . . . . . . . . . . . .    9
     4.3. GFA Considerations  . . . . . . . . . . . . . . . . . . .   10
     4.4. Home Agent Considerations . . . . . . . . . . . . . . . .   10

 5. Regional Registration                                             11
     5.1. Mobile Node Considerations  . . . . . . . . . . . . . . .   12
     5.2. Foreign Agent Considerations  . . . . . . . . . . . . . .   13
     5.3. GFA Considerations  . . . . . . . . . . . . . . . . . . .   13

 6. Router Discovery Extensions                                       14
     6.1. Regional Registration Flag  . . . . . . . . . . . . . . .   14
     6.2. Use of the Foreign Agent NAI Extension  . . . . . . . . .   14

 7. Regional Extensions to RFC 2002 Registration Messages             15
     7.1. GFA IP Address Extension  . . . . . . . . . . . . . . . .   15
     7.2. Hierarchical Foreign Agent Extension  . . . . . . . . . .   16
     7.3. Replay Protection Style . . . . . . . . . . . . . . . . .   16
     7.4. New Code Values for Registration Reply  . . . . . . . . .   18

 8. Regional Registration Message Formats                             18
     8.1. Regional Registration Request . . . . . . . . . . . . . .   19
     8.2. Regional Registration Reply . . . . . . . . . . . . . . .   19
     8.3. New Regional Registration Reply Code Values . . . . . . .   20

 9. Authentication Extensions                                         21

10. Security Considerations                                           21

11. Acknowledgements                                                  21



Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page ii]


Internet Draft            Regional Registration             2 March 2001


 A. Changes from Previous Versions                                    24
     A.1. Updates from version 03 . . . . . . . . . . . . . . . . .   24
     A.2. Updates from version 02 . . . . . . . . . . . . . . . . .   24

 B. Hierarchical Foreign Agents                                       26
     B.1. Registration with Home Agent  . . . . . . . . . . . . . .   27
     B.2. Handling Binding Updates  . . . . . . . . . . . . . . . .   29
     B.3. Regional Registration . . . . . . . . . . . . . . . . . .   30
     B.4. Regional Registrations and Smooth Handover  . . . . . . .   32
     B.5. Co-located care of address  . . . . . . . . . . . . . . .   32
     B.6. Data Traffic  . . . . . . . . . . . . . . . . . . . . . .   32
     B.7. GFA-RFA Subtype for Generalized MN-FA Key Reply Extension   33

 C. Authentication, Authorization and Accounting AAA Interactions     33

 D. Anchoring at a GFA/RFA/FA                                         34

Addresses                                                             35


































Gustafsson, Jonsson, Perkins      Expires 2 September 2001      [Page 1]


Internet Draft            Regional Registration             2 March 2001


1. Introduction

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

   In Mobile IP, as specified in RFC 2002 [11], 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
   _home_registration -- that is, a registration with its home agent.
   At this registration, we assume that the home network generates a
   registration key (e.g.  using [14, 15]) 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.

   During a home registration, 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 a home registration; when changing
   foreign agent under the same GFA, the mobile node MAY instead perform
   a regional registration within the visited domain.  The proposed
   regional registration protocol supports one level of foreign agent
   hierarchy beneath the GFA, but the protocol may be utilized to
   support several levels of hierarchy, as discussed in Appendix B.

   Foreign agents that support regional registrations are also required
   to support registrations according to RFC 2002 [11].  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 [11].  Similarly, 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 [11].








Gustafsson, Jonsson, Perkins      Expires 2 September 2001      [Page 2]


Internet Draft            Regional Registration             2 March 2001


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

   This document uses the following terms:

      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.

      Domain   A collection of networks sharing a common network
               administration.

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

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

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

      Home network
               As defined in [11].

      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 GFA (or another RFA, see
               Appendix B) via the local care-of address.

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



Gustafsson, Jonsson, Perkins      Expires 2 September 2001      [Page 3]


Internet Draft            Regional Registration             2 March 2001


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

      Network Access Identifier(NAI)
               Some features of this protocol specification rely on use
               of the Network Access Identifier (NAI) [1].

      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 Regional Registration
               Request to a GFA, and receiving a Regional Registration
               Reply in return.

      Registration Key
               A key used by mobile nodes and mobility agents to secure
               certain control messages [14] 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 [11].


3. Description of the Protocol

   This section provides an overview of the regional registration
   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.

   For mobile nodes that cannot process a NAI, or with mobility agents
   that are not configured to advertise their NAI, regional registration
   is still useful, but the lack of certain features may result in less
   than optimal results.







Gustafsson, Jonsson, Perkins      Expires 2 September 2001      [Page 4]


Internet Draft            Regional Registration             2 March 2001


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


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



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
   must have a publicly routable address.  Beneath a GFA, there are
   one or more regional foreign agents (RFAs).  We assume that there
   exist established security associations between a GFA and the
   RFAs beneath it.  Multiple hierarchy levels of foreign agents are
   discussed in Appendix B.  When designing a domain supporting regional
   registrations, the RFAs and 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. Authentication

   With the regional registration protocol, 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.




Gustafsson, Jonsson, Perkins      Expires 2 September 2001      [Page 5]


Internet Draft            Regional Registration             2 March 2001


   As part of a registration at the home network, a registration key
   may be distributed to the mobile node and to the visited domain,
   for example according to [3, 14, 15].  The registration key is
   expected to be used for authentication of regional registrations (see
   section 3.1.2).  When the regional registration protocol 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.  The
   distributed registration keys are subsequently used to enable proper
   authentication for regional registrations (see sections 8.1 and 8.2).


3.2. Protocol Overview

   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.

   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 further mobile node movements within the visited
   domain.


    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.


   Figure 2 illustrates the signaling message flow for registration
   with the home network.  After the registration at the home agent,
   the home agent records the GFA address as the care-of address of the
   mobile node.  If the GFA address was dynamically assigned to the



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


Internet Draft            Regional Registration             2 March 2001


   mobile node, the Registration Reply has an extension indicating the
   IP address of the GFA to the mobile node.


    MN                     FA2                            GFA       HA
    |                       |                              |         |
    | Regional Reg. Req.    |                              |         |
    |---------------------->| Regional Reg. Req. w/ext.    |         |
    |                       |----------------------------->|         |
    |                       | Regional Reg. Reply w/ext.   |         |
    | Regional Reg. 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.  We introduce two new message
   types for regional registrations:  Regional Registration Request and
   Regional Registration Reply.


3.3. Advertising Foreign Agent and GFA

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

   The `I' flag (see Section 6) MUST be set to indicate that the domain
   supports regional tunnel management, and that the availability of a
   GFA 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, but that address MAY be set to zero.

   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 6.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 2 September 2001      [Page 7]


Internet Draft            Regional Registration             2 March 2001


   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.


4. Home Registration

   This section gives a detailed description of home registration,
   i.e., registration with the home agent (on the home network).  Home
   registration is performed when a mobile node first arrives at a
   visited domain, when it requests a new home agent, or when it changes
   GFA. Home registration is also performed to renew bindings which
   would otherwise expire.


4.1. Mobile Node Considerations

   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
   determine 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, it acts as defined in [11].

   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. If the mobile node sets the care-of
   address to zero, the mobile node and its home agent MUST support
   the GFA IP address extension (see section 7.1).  In that case, the
   mobile node MUST check to make sure that it receives a GFA IP address
   extension in the Registration Reply.

   A mobile node with a co-located care-of address might also want
   to use Regional Registrations.  It then finds out the address of
   a GFA, either from Agent Advertisements sent by a Foreign Agent,
   or by some means not described in this draft.  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 7.2, 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-GFA authentication extension (see Section 9).  The authentication
   data SHOULD be calculated using a mobility security association
   that has been established with the GFA (Section 3.1.2).  If the
   mobile node receives an Agent Advertisement with the `R' bit set it,
   even if it has a co-located care-of address, still formulates the



Gustafsson, Jonsson, Perkins      Expires 2 September 2001      [Page 8]


Internet Draft            Regional Registration             2 March 2001


   same Registration Request message with extensions, but it sends the
   message to the advertising foreign agent instead of to the GFA.


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.  All Foreign Agents that advertise the `I' flag
   MUST also be able to handle Registration Requests with a zero care-of
   address.  If the care-of address field is set to zero, the foreign
   agent assigns a GFA to the mobile node.  A Foreign Agent can either
   have a default GFA that it assigns to all mobile nodes or it can
   assign a GFA by some means not described in this specification.  It
   then adds a GFA IP Address extension with the address of the assigned
   GFA 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 Registration Request has the `T' bit set, the mobile node is
   requesting Reverse Tunneling [10].  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.

   If the care-of address in the Registration Request is the address of
   the foreign agent, the foreign agent relays the message directly to
   the home agent, as described in [11].  For each pending or current
   home registration, the foreign agent maintains a visitor list entry
   as described in [11].  If reverse tunneling is being used, the
   visitor list MUST, in addition to the fields required in [11],
   contain the address of the GFA.

   Otherwise, 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. The
   Hierarchical Foreign Agent extension MUST be appended at the end
   of all previous extensions that were included in the Registration
   Request message when the foreign agent received it, and it SHOULD be
   protected by an FA-FA Authentication extension.






Gustafsson, Jonsson, Perkins      Expires 2 September 2001      [Page 9]


Internet Draft            Regional Registration             2 March 2001


4.3. GFA Considerations

   For each pending or current home registration, the GFA maintains a
   visitor list entry as described in [11].  This visitor list entry is
   also updated for the regional registrations performed by the mobile
   node.  In addition to the fields required in [11], 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 7.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.  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.

   If the Replay extension (see section 7.3) is present in a home
   registration, and follows the MN-HA authentication extension, the GFA
   SHOULD remove the Replay extension after performing any necessary
   processing, before sending the home registration to the home agent.


4.4. Home Agent Considerations

   A Registration Request that does not contain a GFA IP Address
   extension or a Replay Protection Style extension is processed
   by the home agent as described in [11].  If the home agent
   receives a Registration Request with one of these extensions,
   and the home agent does not support the extension, the home
   agent must return a Registration Reply with the Code value set to
   UNSUPPORTED_EXTENSION [11].  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



Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 10]


Internet Draft            Regional Registration             2 March 2001


   include the GFA IP Address extension in the Registration Reply,
   before the Mobile-Home Authentication 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
   by sending a Registration Reply message with the Code field set to
   ZERO_CAREOF_ADDRESS. Otherwise, the home agent then generates a
   Registration Reply message, including the GFA IP Address extension,
   and sends it back to the GFA.


5. Regional Registration

   This section describes in detail 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 (or, another RFA -- see Appendix B).  In the following, we
   assume that a home registration has already occurred, as described in
   section 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
   mobile node's previous foreign agent.  Then, the mobile node can
   perform a regional registration with this foreign agent and GFA. The
   mobile node issues a Regional Registration Request message to the GFA
   via 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 and the message is authenticated by the
   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.

   If the Regional 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 Regional Registration Reply to the
   mobile node via the foreign agent.





Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 11]


Internet Draft            Regional Registration             2 March 2001


   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 (see
   section 8.3).  In this case the MN has to do a new home registration
   via the new GFA.

   It is essential for the mobile node to distinguish regional
   registrations from home registrations, since in the former case the
   nonces are not synchronized with its home agent.  Furthermore, a
   home registration MUST be directed to the home network before the
   lifetime of the GFA's regional care-of address expires.  Since the
   mobile node can use a zero Care-of Address either to request a GFA
   (in a home registration) or to signify the use of an unspecified
   (perhaps privately addressed) RFA (in a regional registration),
   it is necessary to distinguish regional registrations from home
   registration.  Thus, we introduce new message types for the Regional
   Registration messages.


5.1. Mobile Node Considerations

   For each pending or current home registration, the mobile node
   maintains the information described in [11].  The information is also
   updated for the regional registrations performed by the mobile node.
   In addition to the information described in [11], 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.

   The replay protection for registrations and regional registrations
   is performed as described in [11].  Since the mobile node performs
   regional registrations at the GFA in parallel with registrations at
   its home network, the mobile node MUST be able to keep one replay
   protection mechanism and sequence for the GFA, and a separate
   mechanism and sequence for the home agent.

   For regional registrations, replay protection may also be provided at
   the foreign agent by the challenge-response mechanism, as described
   in [7].  In this case, the mobile node inserts the 64 bit response
   value (timestamp or nonce, according to RFC 2002 [11]) in the
   Identification field in the Regional Registration Request.  Thus,
   the GFA SHOULD expect such an Identification field.  When a mobile



Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 12]


Internet Draft            Regional Registration             2 March 2001


   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 Regional Registration Request message destined to
   its old GFA.


5.2. Foreign Agent Considerations

   When the foreign agent receives a Regional Registration Request
   message from a mobile node, addressed to a GFA, it processes the
   message generally according to the rules of processing a Registration
   Request message addressed to a home agent (see section 4.2).  The
   only difference is that the GFA IP address field replaces the home
   agent address field.  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 Regional Registration Reply with
   error code UNKNOWN_GFA.

   For each pending or current registration, the foreign agent maintains
   a visitor list entry as described in [11].  If reverse tunneling is
   being used, the visitor list MUST contain the address of the GFA, in
   addition to the fields required in [11].  This is required so that
   the foreign agent can tunnel datagrams, sent by the mobile node, to
   the GFA. The GFA then decapsulates the datagrams, re-encapsulates
   them and sends them to the home agent.


5.3. GFA Considerations

   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 Regional Registration Reply.  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.  In that
   case the GFA sends a Regional Registration Reply with the value in
   the Code field set to HOME_REG_EXPIRED.

   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 2 September 2001      [Page 13]


Internet Draft            Regional Registration             2 March 2001


6. 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 [8].


6.1. Regional Registration Flag

   The only change to the Mobility Agent Advertisement Extension
   defined in [11] is a flag indicating that the domain, to which the
   foreign agent generating the Agent Advertisement belongs, supports
   regional registrations.  The flag is inserted after the flags defined
   in [11], [10] and [13].


    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     |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Lifetime            |R|B|H|F|M|G|V|T|S|I| reserved  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  zero or more Care-of Addresses               |
   |                              ...                              |


   The flag is defined as follows:

      I          Regional registration.  This domain supports Regional
                 Registration as specified in this document.


6.2. Use of the Foreign Agent NAI Extension

   The FA-NAI extension is defined as a subtype 4 of the Generalized NAI
   Extension (GNAIE) [9].

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

   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.





Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 14]


Internet Draft            Regional Registration             2 March 2001


7. Regional Extensions to RFC 2002 Registration Messages

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


7.1. GFA IP Address Extension

   In order to assign a GFA to the mobile node, the foreign agent adds a
   GFA IP Address extension to the Registration Request before relaying
   it to the selected GFA. The mobile node indicates that it wants a GFA
   to be assigned by sending a Registration Request message with the
   care-of address field set to zero.  The GFA IP Address extension MUST
   appear in the Registration Request message before the Foreign-Home
   Authentication extension, if present.


       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 4: The GFA IP Address extension


   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.  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.

   The GFA IP Address extension, illustrated in figure 4 is defined as
   follows:

      Type             24 (GFA IP Address(TBD))

      Length           4

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





Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 15]


Internet Draft            Regional Registration             2 March 2001


7.2. Hierarchical Foreign Agent Extension

   The Hierarchical Foreign Agent extension may be present in a
   Registration Request or Regional 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.  The
   Hierarchical Foreign Agent extension SHOULD be protected by an FA-FA
   Authentication extension.  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:


       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 5: The Hierarchical Foreign Agent Extension


      Type               25 (Hierarchical Foreign Agent (TBD))

      Length             4

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


7.3. Replay Protection Style

   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




Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 16]


Internet Draft            Regional Registration             2 March 2001


   protection for Regional Registration messages exactly as specified in
   RFC 2002 [11] 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 a home registration message.  Since home registrations are
   forwarded to the home agent by way of the GFA, the GFA will be able
   to establish the selected replay protection (see section 4.3).  The
   format of this extension is shown in figure 6.


       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 6: The Replay Protection Extension



      Type       26 (Replay Protection Style (TBD))

      Length     2

      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:

      Value      Replay Protection Style
      -----      -----------------------
      0          timestamp [11]
      1          nonce [11]


   The mobile node SHOULD append the Replay Protection Style Extension
   to the home registration following the MN-HA authentication
   extension, but before any MN-GFA authentication extension.  Then,



Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 17]


Internet Draft            Regional Registration             2 March 2001


   the GFA can remove the extension without damaging the MN-HA
   authentication data needed by the home agent.

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


7.4. New Code Values for Registration Reply

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

   Registration denied by the FA:

      Error Name               Value   Section of Document
      ----------------------   -----   -------------------
      SMOOTH_HO_REQUIRED       TBD     B.4



   Registration denied by the GFA:
      Error Name               Value   Section of Document
      ----------------------   -----   -------------------
      REPLAY_PROT_UNAVAIL      TBD     7.3



   Registration denied by the HA:

      Error Name               Value   Section of Document
      ----------------------   -----   -------------------
      ZERO_CAREOF_ADDRESS      144     4.4




8. Regional Registration Message Formats

   This section specifies two new registration message types:  Regional
   Registration Request and Regional Registration Reply.  These messages
   are used by the mobile node instead of the existing Registration
   Request and Registration Reply, in order to make registration work
   faster, and also to reduce network load for Mobile IP registration,
   as described in section 5.

   Regional registration messages are protected by requiring
   authentication extensions, in the same way as the existing Mobile IP




Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 18]


Internet Draft            Regional Registration             2 March 2001


   registration messages are protected.  The following rules apply to
   authentication extensions:

    -  The Mobile-GFA Authentication extension [11] MUST be included in
       all regional registration messages.
    -  The Mobile-Foreign Authentication extension [11] MAY be included
       in regional registration messages.
    -  The Foreign-Home Authentication extension [11] MUST NOT be
       included in any regional registration message.


8.1. Regional Registration Request

   The Regional Registration Request is used by a mobile node to
   register with its current GFA.

   The Regional Registration Request message is defined as the
   Registration Request message in [11], but with the following changes:

      Type       2 (Regional Registration Request)

      GFA IP Address
                 The IP address of the Gateway Foreign Agent.  (Replaces
                 Home Agent field in Registration Request message
                 in [11].)

      Care-of Address
                 Care-of address of local foreign agent; MAY be set to
                 zero.

      Extensions
                 Hierarchical Foreign Agent Extension


8.2. Regional Registration Reply

   The Regional Registration Reply message delivers the indication of
   regional registration acceptance or denial to a mobile node.  This














Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 19]


Internet Draft            Regional Registration             2 March 2001


   message is defined as the Registration Reply message in [11], but
   with the following changes:

      Type       4 (Regional Registration Reply)

      Regional FA IP Address
                 The IP address of the Gateway Foreign Agent.  (Replaces
                 Home Agent field specified in RFC 2002 [11]).

      Extensions


   The Regional FA IP Address is the address of the regional foreign
   agent generating the Regional Registration Reply message.  For the
   two-level hierarchy specified here, it is the address of the GFA. For
   more levels of hierarchy, it may be the address of an intermediate
   RFA.


8.3. New Regional Registration Reply Code Values

   For a Regional Registration Reply, the following additional Code
   values are defined in addition to those specified in RFC 2002 [11].

   Registration denied by the FA:

      Error Name               Value   Section of Document
      ----------------------   -----   -------------------
      UNKNOWN_GFA              90      5.2
      GFA_UNREACHABLE          91
      GFA_HOST_UNREACHABLE     92
      GFA_PORT_UNREACHABLE     93
      SMOOTH_HO_REQUIRED       TBD     B.4


   Registration denied by the GFA:

      Error Name               Value   Section of Document
      ----------------------   -----   -------------------
      HOME_REG_EXPIRED         TBD     5.3


   The four Code values in the range 90--93 are returned to the mobile
   node in response to ICMP errors that may be received by the foreign
   agent.







Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 20]


Internet Draft            Regional Registration             2 March 2001


9. Authentication Extensions

   Two new subtypes for the Generalized Authentication Extension [7] are
   defined in this document.  The FA-FA Authentication extension is used
   by regional foreign agents to secure the Hierarchical Foreign Agent
   (HFA) extension to the Registration Request and Regional Registration
   Request messages.  A new authentication extension is necessary
   because the HFA extension is typically added after the Mobile-Home
   (or some other authorization-enabling [11] (e.g. MN-AAA [4], see
   section C) authentication extension.

   The MN-GFA authentication extension is used whenever the mobile node
   has a co-located address.  Furthermore, the MN-GFA extension is used
   to provide authentication for a Regional Registration Request.

   The subtype values are as follows:

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



   The default algorithm for computation of the authenticator is the
   same as for the MN-AAA Authentication subtype defined in [5].


10. 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 [11], [13], or [3].  Key distribution is to
   be performed, for instance, according to [3], [14] or [15].

   If the Hierarchical Foreign Agent (HFA) extension is appended to a
   Registration Request message, that extension is to be followed by
   an FA-FA Authentication Extension to prevent any modification to
   the data.  Likewise, if the GFA IP Address extension is added to
   such a message, it is to be followed by an authentication extension.
   extension


11. 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



Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 21]


Internet Draft            Regional Registration             2 March 2001


   on a rough version of this document, and providing motivation for
   section B.4.


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
        (work in progress).  Internet Draft, Internet Engineering Task
        Force.
        draft-calhoun-diameter-mobileip-05.txt, December 1999.

    [4] P. Calhoun and C. Perkins.  Mobile IP Network Access Identifier
        Extension for IPv4.  Request for Comments (Proposed Standard)
        2794, Internet Engineering Task Force, January 2000.

    [5] P. Calhoun and C. E. Perkins.  Mobile IP Foreign Agent
        Challenge/Response Extension, December 2000.

    [6] P. Calhoun and C. E. Perkins.  Mobile IP Foreign Agent
        Challenge/Response Extension, December 2000.

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

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

    [9] Mohamed Khalil, Emad Qaddoura, Haseeb Akhtar, and Pat R.
        Calhoun.  Generalized NAI Extension (GNAIE) (work in progress).
        draft-ietf-mobileip-gnaie-00.txt, February 2000.

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

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




Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 22]


Internet Draft            Regional Registration             2 March 2001


   [12] C. Perkins and P. Calhoun.  Generalized Key Distribution
        Extensions for Mobile IP (work in progress).
        draft-ietf-mobileip-gen-key-02.txt, July 2000.

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

   [14] C. E. Perkins, D. Johnson, and N. Asokan.  Registration Keys for
        Route Optimization (work in progress).
        draft-ietf-mobileip-regkey-03.txt, July 2000.

   [15] Charles E. Perkins and Pat R. Calhoun.  AAA Registration Keys
        for Mobile IP (work in progress).
        draft-ietf-mobileip-aaa-key-03.txt, September 2000.





































Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 23]


Internet Draft            Regional Registration             2 March 2001


A. Changes from Previous Versions

   The following updates and changes were made in this version of the
   Mobile IP Regional Registration draft, compared to earlier versions.


A.1. Updates from version 03

      Section 3.3       Clarified that the care-of address can be zero.

      Section 4.2       Added that any Foreign Agent that supports
                        regional registrations must be able to assign a
                        GFA to a mobile node if the care-of address in
                        the Registration Request is zero.

      Section 5.2       Clarified that in regional registrations the GFA
                        address field replaces the HA address field.

      Section 5.3       Added a new error code:  HOME_REG_EXPIRED that
                        the GFA use when denying a regional registration
                        because the home registration lifetime has
                        expired.

      Section 6.1       Clarified the placement of the 'I' flag.

      Section 9         Added reference to a default algorithm for the
                        authentication extensions.

      Section B.5       Added a section to allow a mobile node with a
                        co-located care of address to use multi-level
                        hierarchies.

      Section B.4       Interactions with delivery of Binding Update
                        messages to RFAs along the previous routing
                        path have been suggested in order to prevent
                        various race conditions that have been observed
                        in practice.


A.2. Updates from version 02

   The following updates and changes were made in this version of the
   Mobile IP Regional Registration draft, compared to the earlier
   version (version 02).

      Section 4.3       The contents of the visitor list entry at the
                        GFA have been clarified.  A GFA keeps a visitor
                        list entry for each pending or current home
                        registration.  The entry is also updated for the



Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 24]


Internet Draft            Regional Registration             2 March 2001


                        regional registrations performed by the mobile
                        node.

      Section 7.4       A new code value for the Registration Reply has
                        been defined:  MISSING_GFA_ADDRESS. This section
                        has also been re-structured for clarification.

      Section 5.1       Specific message types for regional
                        registrations messages (Regional Registration
                        Request and Regional Registration Reply) were
                        defined.  The reason for defining specific
                        message types for the regional registration
                        messages, instead of using the Registration
                        Request and Reply as defined in [RFC 2002] are
                        the following:

                         -  a mobile node must be able to distinguish
                            between regional registrations and home
                            registrations, because when it uses
                            regional registration, the nonces are not
                            synchronized with its home agent;

                         -  a mobile node can use a zero care-of
                            address either to request a GFA (in a home
                            registration) or to signify the use of an
                            unspecified regional foreign agent (in a
                            regional registration).

                        For regional registrations, the
                        challenge-response mechanism may be used
                        to provide replay protection.  In this case, the
                        mobile node inserts the 64 bit response value
                        in the Identification field in the Regional
                        Registration Request.

      Section 6.2       The FA-NAI extension is defined as a subtype 4
                        of the Generalized NAI Extension (GNAIE).

      Section 8         This entire section is added to the draft, and
                        it describes the Regional Registration Request
                        and Regional Registration Reply messages.

      Appendix B        The contents of the visitor list entry at the
                        RFA and GFA have been clarified.  An RFA/GFA
                        keeps a visitor list entry for each pending or
                        current home registration.  The entry is also
                        updated for the regional registrations performed
                        by the mobile node.




Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 25]


Internet Draft            Regional Registration             2 March 2001


      Appendix D        This appendix has been added to the draft.  It
                        clarifies how a mobile node can register a
                        care-of address with its home agent; a GFA, RFA
                        or FA care-of address, and then maintain this
                        care-of address when it moves in the visited
                        domain.


B. 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 7).  Such
   multiple hierarchy levels are discussed in this appendix.


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


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





Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 26]


Internet Draft            Regional Registration             2 March 2001


   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.  We also
   assume that all foreign agents and the mobile node support smooth
   handover as specified in [13], with some modifications as explained
   below.


B.1. Registration with Home Agent

   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 [11].  If there is a hierarchy of foreign agents between
   the GFA and the announcing foreign agent, the foreign agent MUST
   support smooth handover (specifically, the Previous Foreign Agent
   Notification extension) as described in [13].  The foreign agent MAY
   also include the addresses of the foreign agents in the hierarchy 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
   RFA 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.  The registration Request MUST include the Previous
   Foreign Agent Notification Extension defined in [13].  The Binding
   Update that results is processed as described in Section B.2.  The
   identification field for the Binding Update MUST be the same as for
   the Registration Request.

   When the foreign agent closest to the mobile node receives the
   Registration Request, processing is as described in Section 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. It also




Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 27]


Internet Draft            Regional Registration             2 March 2001


   constructs a Binding Update and sends it to the previous foreign
   agent, as defined in  [13].

   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 [11]), 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 style of replay protection in use for the regional
       registration
    -  the Identification value for 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.

   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 home registration, the GFA maintains a
   visitor list entry as described in [11].  The list entry is also
   updated for regional registrations reaching the GFA. In addition
   to the list entry contents required in [11], the list entry MUST
   contain:

    -  the address of the next lower-level RFA in the hierarchy
    -  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 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 4.3.

   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, perhaps with the assistance of the GFA, for instance
   by deciphering the key present in the Foreign Agent Key Request
   extension [14], and adding a Home-Mobile Key Reply extension to
   the Registration Reply message, or alternatively by way of other
   AAA functions [15].  When the GFA receives the Registration Reply,



Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 28]


Internet Draft            Regional Registration             2 March 2001


   it checks its pending Registration Request record to see which
   next lower-level RFA to send the Registration Reply message to.
   It SHOULD then add, for instance, a new FA-FA Key Reply extension
   to the Registration Reply message, before relaying it to the next
   foreign agent.  The new FA-FA 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 [15].

   The next lower-level RFA receives the Registration Reply 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 [11], and relays
   the Registration Reply to the mobile node.


B.2. Handling Binding Updates

   Meanwhile, when the previous foreign agent receives the Binding
   Update, it will process it according to [13], except that instead
   of sending back a Binding Acknowledge message, it sends the Binding
   Update to the next RFA in the hierarchy towards the GFA. The previous
   foreign agent can tell whether it is a RFA for the Binding Update by
   noting at the time it receives a Home Registration whether or not the
   home agent field is occupied by the address of the GFA (or zero).
   This additional forwarding procedure ensures that all RFAs in the
   path from the crossover router to the previous FA are notified that
   the mobile node has moved.

   The previous foreign agent must be sure that the next RFA received
   the Binding Update, therefore the RFA MUST send a Binding Acknowledge
   message back to the foreign agent that it got the Binding Update
   from.  Note that this is the same Binding Acknowledge message than
   the one defined in [13], but this one is addressed to the IP address
   of the Foreign Agent that sent the Binding Update instead of to the
   mobile node.

   The RFA that received the Binding Update sends the Binding
   Acknowledge message back to the lower-layer Foreign Agent, and relays
   the Binding Update to the next RFA in the hierarchy towards the GFA.
   The RFA will also update the binding cache for the mobile node so
   that it will expire according to the lifetime in the Binding Update,




Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 29]


Internet Draft            Regional Registration             2 March 2001


   but the binding cache entry will still point to the same lower-level
   foreign agent.

   The crossover FA is the foreign agent lowest in the hierarchy which
   is part of both the old and the new path to the mobile node.  When
   the Binding Update reaches the crossover FA, which might be an RFA or
   the GFA, it will, in addition to sending a Binding Acknowledge back
   to the sending RFA, also send a Binding Acknowledge to the mobile
   node.  This Binding Acknowledge message is the one defined in [13]
   and it is addressed to the mobile node and sent down the hierarchy
   via the old path and the previous Foreign Agent, who tunnels it to
   the new Foreign Agent.

   The crossover FA will receive both a Registration Request and a
   Binding Update for the mobile node.  When the crossover FA receives
   the Registration Request, it continues to send traffic via the
   old path until it receives a valid Registration Reply with a Code
   indicating success.  Then it starts sending traffic via the new
   route.

   In the unlikely event that the crossover FA receives the Binding
   Update before it receives the Registration Request, it doesn't
   know that it is the crossover FA yet, and therefore relays the
   Binding Update to the next Foreign Agent.  When the crossover FA
   later receives the Registration Request, it will know that it is
   the crossover FA. The foreign agents above the crossover FA in the
   hierarchy that also got the Binding Update will see that the Binding
   Update does not supply any new care-of address when they process the
   Binding Update.  Typically, the latter processing will only have the
   effect of changing the available lifetime for the relevant regional
   Binding Cache entry.


B.3. Regional Registration

   A Regional Registration Request is forwarded to the GFA by way of
   one or more intermediate regional foreign agents.  When the Regional
   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 Regional Registration
   Request to.  It adds a Hierarchical Foreign Agent extension to the
   Regional 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




Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 30]


Internet Draft            Regional Registration             2 March 2001


   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 Regional
   Registration Reply and sends it to the next lower-level RFA in the
   hierarchy.  The lifetime field in the Regional 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 Regional Registration Request is relayed all the way
   to the GFA.

   The Previous Foreign Agent Notification Extension, Binding Updates
   and Binding Acknowledge messages are used for Regional Registrations
   in the same way as for Home Registrations.

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

   Replay protection can be provided at the announcing foreign agent,
   through the challenge-response mechanism described in  [7].  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.  If the challenge-response mechanism is used
   for replay protection, the mobile node inserts the 64 bit response
   value in the Identification field in the Regional Registration
   Request message.  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
   Regional Registration Reply, the GFA MUST ensure that the order of
   the Hierarchical Foreign Agent extensions is reversed from the order
   found in the Regional Registration Request.








Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 31]


Internet Draft            Regional Registration             2 March 2001


B.4. Regional Registrations and Smooth Handover

   Multiple hierarchy levels of foreign agents requires the use of
   smooth handover from [13], as discussed in Appendix B.  This is
   not needed in a two level hierarchy.  But a mobile node might not
   know how many levels of hierarchy a network has, so if the foreign
   agents in one network support both Regional Registrations and
   Smooth Handover a mobile node MAY try to use Regional Registrations
   without Smooth Handover.  If the network requires the use of Smooth
   Handover (because it has more than two levels of hierarchy, or
   for other reasons) the Foreign Agent MUST deny the request by
   sending back a Registration Reply message with the Code field set to
   SMOOTH_HO_REQUIRED.

   The Foreign Agent NAI extension (see section 6.2) is also used during
   Smooth Handover.  If Smooth Handovers are used, and the foreign
   agent does not advertise its own address in the Agent Advertisement
   message, the mobile node will identify the previous foreign agent by
   way of its FA-NAI. This will be done by adding an FA-NAI extension
   (defined in [9]) to the Registration Request (together with the
   Previous Foreign Agent Notification extension) and in the Binding
   Update, and setting the care-of address to zero.


B.5. Co-located care of address

   If a mobile node uses a co-located care-of address, it MAY send
   Regional Registrations directly to the GFA (see section 4.1 and
   section 5).  It MAY also use the same method to make use of multiple
   levels of Foreign Agents, if it can find out about the hierarchy,
   either from Mobility Agent Advertisements, or in some other way
   outside the scope of this specification.


B.6. 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 re-routed
   to the next lower-level RFA in the hierarchy.  This re-routing occurs
   at each level of the hierarchy, until the datagram reaches the last
   point which is either the mobile node itself (in case of a co-located
   care-of address) or a foreign agent that can deliver the datagram to
   the mobile node with no further special Mobile IP handling.





Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 32]


Internet Draft            Regional Registration             2 March 2001


   In case of decapsulation and re-encapsulation, it should be noted
   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 [11] or [10].

   According to the Route Optimization specification [13], 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
   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.


B.7. GFA-RFA Subtype for Generalized MN-FA Key Reply Extension

   If a GFA uses the Registration Reply to distribute an MN-FA key to
   the other RFAs in its domain, a new subtype for the Generalized MN-FA
   Key Reply Extension [12] is required.

   The subtype value is as follows:

      Subtype Name         Value
      --------------       ------------
      GFA-RFA Key Reply    5



   The subtype data for the GFA-RFA Key Reply subtype is a 4 byte SPI,
   followed by the registration key encoded according to the recipe
   indicated by the SPI.


C. Authentication, Authorization and Accounting AAA Interactions

   When the mobile node has to obtain authorization by way of
   Authentication, Authorization and Accounting (AAA) infrastructure
   services, the control flow implicit in the main body of this
   specification is likely to be modified.  Typically, the mobile node
   will supply credentials for authorization by AAA as part of its
   registration messages.  The GFA will parse the credentials supplied




Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 33]


Internet Draft            Regional Registration             2 March 2001


   by the mobile and forward the appropriate authorization request to a
   local AAA server (see [6, 3]).

   Concretely, this means that:

    -  The GFA MAY include the Mobile IP Registration Request data
       inside an authorization request, directed to a local AAA server.

    -  The GFA MAY receive the Mobile IP Registration Reply data
       from a message granting authorization, received from the AAA
       infrastructure.


D. Anchoring at a GFA/RFA/FA

   As described earlier in this draft, once a mobile node has registered
   the address of a GFA as its care-of address with its home agent, it
   MAY perform regional registrations when changing foreign agent under
   the same GFA. When detecting that is has changed foreign agent, and
   if the new foreign agent advertises the `I' flag, the mobile node MAY
   address a Regional Registration Request message to its registered
   GFA, even if the address of that particular GFA is not advertised by
   the new foreign agent.  The foreign agent MAY then relay the request
   to the GFA in question, or deny the request with error code 'unknown
   GFA'.

   Similarly, a mobile node MAY address a Regional Registration Request
   message to any Regional Foreign Agent or foreign agent that it has
   registered as the current care-of address with its home agent.
   Assume that a mobile node has registered the address of an RFA or
   foreign agent as its care-of address with its home agent.  When
   detecting that it changes foreign agent, and if the new foreign agent
   advertises the `I' flag, the mobile node MAY address a Regional
   Registration Request to that RFA/FA. The new foreign agent MAY then
   relay the request to the RFA/FA in question, or deny the request
   with error code 'unknown GFA'. If the Regional Registration Request
   reaches the RFA/FA, and if the RFA/FA also has the capability to
   act as a GFA, it MAY accept the request and generate a Regional
   Registration Reply to the mobile node.  This scenario assumes that
   keys have been distributed to the RFA/FA and to the mobile node prior
   to the regional registration, so that the Regional Registration
   Request message can be authenticated with the MN-GFA Authentication
   extension.









Gustafsson, Jonsson, Perkins     Expires 2 September 2001      [Page 34]


Internet Draft            Regional Registration             2 March 2001


Addresses

   The working group can be contacted via the current chairs:


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



   Questions about this memo can be directed to:


        Eva Gustafsson                   Annika Jonsson
        Ericsson Inc.                    Ericsson Radio Systems AB
        2100 Shattuck Avenue             Network and Systems Research
        Berkeley, CA 94704               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 2 September 2001      [Page 35]