[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 RFC 4857

MIP4 Working Group                                         E. Gustafsson
Internet-Draft                                                A. Jonsson
Expires: May 23, 2005                                           Ericsson
                                                              C. Perkins
                                                   Nokia Research Center
                                                       November 22, 2004


                   Mobile IPv4 Regional Registration
                     draft-ietf-mip4-reg-tunnel-00

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on May 23, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

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.  This document
   describes a new kind of 'regional' registrations, i.e.  registrations



Gustafsson, et al.        Expires May 23, 2005                  [Page 1]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   local to the visited domain.  The regional signaling is performed via
   a new network entity called a Gateway Foreign Agent and introduces a
   layer of hierarchy in 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.  This document is an
   optional extension to the Mobile IPv4 protocol.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Description of the Protocol  . . . . . . . . . . . . . . . . .  6
     3.1   General Assumptions  . . . . . . . . . . . . . . . . . . .  6
       3.1.1   Visited Domain . . . . . . . . . . . . . . . . . . . .  7
       3.1.2   Authentication . . . . . . . . . . . . . . . . . . . .  7
     3.2   Protocol Overview  . . . . . . . . . . . . . . . . . . . .  8
     3.3   Advertising Foreign Agent and GFA  . . . . . . . . . . . .  9
     3.4   Backwards compatibility with RFC3344 . . . . . . . . . . . 10
   4.  Home Registration  . . . . . . . . . . . . . . . . . . . . . . 10
     4.1   Mobile Node Considerations . . . . . . . . . . . . . . . . 10
     4.2   Foreign Agent Considerations . . . . . . . . . . . . . . . 12
     4.3   GFA Considerations . . . . . . . . . . . . . . . . . . . . 13
     4.4   Home Agent Considerations  . . . . . . . . . . . . . . . . 14
   5.  Regional Registration  . . . . . . . . . . . . . . . . . . . . 15
     5.1   Mobile Node Considerations . . . . . . . . . . . . . . . . 16
     5.2   Foreign Agent Considerations . . . . . . . . . . . . . . . 17
     5.3   GFA Considerations . . . . . . . . . . . . . . . . . . . . 17
   6.  Generalized NAI Extension  . . . . . . . . . . . . . . . . . . 18
   7.  Router Discovery Extensions  . . . . . . . . . . . . . . . . . 19
     7.1   Regional Registration Flag . . . . . . . . . . . . . . . . 19
     7.2   Foreign Agent NAI Extension  . . . . . . . . . . . . . . . 19
   8.  Regional Extensions to Mobile IPv4 Registration Messages . . . 20
     8.1   GFA IP Address Extension . . . . . . . . . . . . . . . . . 20
     8.2   Hierarchical Foreign Agent Extension . . . . . . . . . . . 21
     8.3   Replay Protection Style  . . . . . . . . . . . . . . . . . 22
     8.4   New Code Values for Registration Reply . . . . . . . . . . 23
   9.  Regional Registration Message Formats  . . . . . . . . . . . . 24
     9.1   Regional Registration Request  . . . . . . . . . . . . . . 24
     9.2   Regional Registration Reply  . . . . . . . . . . . . . . . 25
     9.3   New Regional Registration Reply Code Values  . . . . . . . 26
   10.   Authentication Extensions  . . . . . . . . . . . . . . . . . 27
   11.   Security Considerations  . . . . . . . . . . . . . . . . . . 28
   12.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 28
   13.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
   14.   References . . . . . . . . . . . . . . . . . . . . . . . . . 29
   14.1  Normative References . . . . . . . . . . . . . . . . . . . . 29
   14.2  Informative References . . . . . . . . . . . . . . . . . . . 29



Gustafsson, et al.        Expires May 23, 2005                  [Page 2]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
   A.  Hierarchical Foreign Agents  . . . . . . . . . . . . . . . . . 30
   1.  Registration with Home Agent . . . . . . . . . . . . . . . . . 31
   2.  Handling Binding Updates . . . . . . . . . . . . . . . . . . . 34
   3.  Regional Registration  . . . . . . . . . . . . . . . . . . . . 35
   4.  Regional Registrations and Smooth Handover . . . . . . . . . . 36
   5.  Co-located care of address . . . . . . . . . . . . . . . . . . 37
   6.  Data Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 37
   B.  Authentication, Authorization and Accounting (AAA)
       Interactions . . . . . . . . . . . . . . . . . . . . . . . . . 38
   C.  Anchoring at a GFA/RFA/FA  . . . . . . . . . . . . . . . . . . 38
       Intellectual Property and Copyright Statements . . . . . . . . 40







































Gustafsson, et al.        Expires May 23, 2005                  [Page 3]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


1.  Introduction

   This document is an optional extension to the Mobile IPv4 protocol,
   and proposes a means for mobile nodes to register locally within a
   visited domain.  By registering locally, the number of signaling
   messages to the home network are kept to a minimum, and the signaling
   delay is reduced.

   In Mobile IP, as specified in [RFC3344], 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.  The regional registration
   design introduces new Mobile IPv4 messages - Regional Registrations,
   new Mobile IPv4 extensions to convey information between the mobile
   node, foreign agent and home agent, and a new network entity:  the
   Gateway Foreign Agent (GFA).  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.  This will both decrease the
   load on the home network, and speed up the process of handover within
   the 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 [I-D.ietf-mip4-aaa-key]) 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 A.

   Foreign agents that support regional registrations are also required
   to support registrations according to Mobile IPv4 [RFC3344].  If
   there is a foreign agent address announced in the Agent



Gustafsson, et al.        Expires May 23, 2005                  [Page 4]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   Advertisement, the mobile node may register that foreign agent
   care-of address with its home agent [RFC3344].  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 [RFC3344].

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
   levels for compliant implementations.

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

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

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

   Home network
      As defined in [RFC3344].

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






Gustafsson, et al.        Expires May 23, 2005                  [Page 5]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004



   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 A) via the local care-of
      address.

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

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

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

   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
      signals and control messages specified by Mobile IP.

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

   Visited network
      As defined in [RFC3344].

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:



Gustafsson, et al.        Expires May 23, 2005                  [Page 6]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


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


                                Figure 1

   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.

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 A.  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 directed to the home agent, the GFA will perform the
   authentication.  Similarly, if a Foreign-Home Authentication



Gustafsson, et al.        Expires May 23, 2005                  [Page 7]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   extension is present in a Registration Request message, the
   authentication is performed between the GFA and the home agent.  To
   summarise, the GFA takes the role of a foreign agent as regards to
   security associations in the home registrations.

   Regional Registration messages also have to be protected with
   authentication extensions in the same way as registrations with the
   home agent.  This means that the mobile node and the GFA MUST have
   received the keys needed to construct the authentication extensions
   before any Regional Registration is performed.  As described above,
   since the GFA address is the registered care-of address of the mobile
   node at its home network, the GFA is the agent within the visited
   domain which has to have the appropriate security associations with
   the home agent and the mobile node.  The GFA's security association
   with the mobile node is then used to enable proper authentication for
   regional registrations (see Section 5).  How the keys are distributed
   is outside the scope of this draft.  One example is that the keys are
   distributed as part of the registration at the home network, for
   example according to [I-D.ietf-aaa-diameter-mobileip],
   [I-D.ietf-mip4-aaa-key].  Another example is pre-configured keys.

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.

   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 mobile
   node, the Registration Reply has an extension indicating the IP
   address of the GFA to the mobile node.








Gustafsson, et al.        Expires May 23, 2005                  [Page 8]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   Registration at the GFA and the home agent:


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


                                Figure 2

   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.

   Regional registration at the GFA:


     MN                     FA2                            GFA       HA
     |                       |                              |         |
     | Regional Reg.  Req.   |                              |         |
     |---------------------->| Regional Reg.  Req. w/ext.   |         |
     |                       |----------------------------->|         |
     |                       | Regional Reg.  Reply w/ext.  |         |
     | Regional Reg.  Reply  |<-----------------------------|         |
     |<----------------------|                              |         |
     |                       |                              |         |


                                Figure 3


3.3  Advertising Foreign Agent and GFA

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



Gustafsson, et al.        Expires May 23, 2005                  [Page 9]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   The 'I' flag (see Section 7) MUST be set to indicate that the domain
   supports regional tunnel management.  If the 'I' flag is set, there
   MUST be at least one care-of address in the Agent Advertisement
   message, but that address MAY be set to the "all ones" address.  If
   the 'I' flag is set, and there is only one care-of address (which is
   not all ones), it is the address of the FA.  If the 'I' flag 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.  The FA-NAI
   (see Section 7.2) SHOULD also be present to enable the mobile node 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.

3.4  Backwards compatibility with RFC3344

   A domain that supports Regional Registrations SHOULD also be
   backwards compatible.  If the Foreign Agent does not advertise an
   "all ones" care-of address, it MUST support registrations according
   to Mobile IPv4 as defined in [RFC3344].  This allows mobile nodes
   that don't support Regional Registrations to register via this
   Foreign Agent using standard Mobile IPv4.  If the Foreign Agent
   advertises both its own care-of address and a GFA care-of address, a
   mobile node that supports Regional Registrations but has a Home Agent
   that doesn't, will still be able to make use of Regional
   Registrations through that GFA care-of address.  A Foreign Agent that
   advertises an "all ones" care-of address will not be backwards
   compatible with [RFC3344].  In that case, and in other cases when the
   mobile node requests that a GFA address is dynamically assigned to it
   by setting the care-of address in a Registration Request to zero, the
   mobile node and its Home Agent MUST support the GFA IP address
   extension.

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



Gustafsson, et al.        Expires May 23, 2005                 [Page 10]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   foreign domain.  Otherwise, if the mobile node determines that it is
   in its home domain, it acts as defined in [RFC3344].

   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 8.1).  In that case, the mobile
   node MUST check to make sure that it receives a GFA IP address
   extension in the Registration Reply.  If the Foreign Agent only
   advertises an "all ones" care-of address, it only supports
   dynamically assigned GFA care-of address, and the mobile node MUST
   set the care-of address in the Registration Request to zero.

   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 (see Section 8.2), including its co-located
   care-of address, to the Registration Request before sending it.  The
   Hierarchical Foreign Agent extension MUST be protected by an
   authentication extension.  If the mobile node has established a
   mobility security association with the GFA, the Hierarchical Foreign
   Agent extension SHOULD be placed after the MN-HA authentication
   extension and before the MN-FA authentication extension.  Otherwise
   the Hierarchical Foreign Agent extension MUST be placed before the
   MN-HA authentication extension.

   If the mobile node receives an Agent Advertisement with the 'R' bit
   set, even if it has a co-located care-of address, it still formulates
   the same Registration Request message with extensions, but it sends
   the message to the advertising foreign agent instead of to the GFA.

   If the home registration is about to expire, the mobile node performs
   a new home registration using the same GFA care-of address to refresh
   the binding [RFC3344].  If the mobile node has just moved to a new
   Foreign Agent and not yet sent a Regional Registration Request when
   the home registration is due to expire, the mobile node sends only a
   home Registration Request, as this will update both the GFA and the
   HA.  This Registration Request MUST be constructed as if it was the
   first registration in this domain.  For example, if the new Foreign
   Agent only advertises an "all ones" care-of address, the mobile node
   MUST set the care-of address in the Registration Request to zero, to
   avoid problems if this new Foregin Agent doesn't support the same GFA



Gustafsson, et al.        Expires May 23, 2005                 [Page 11]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   as the mobile node had before.

   If the Registration Reply includes a Replay Protection Style
   extension, the value in the Initial Identification field is the value
   to be used for replay protection in the next Regional Registration
   Request (see Section 5.1).

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.

   If the Foreign Agent receives a Registration request where the
   care-of address is set to "all ones" (which could happen if a mobile
   node that doesn't support Regional Registrations copied an "all ones"
   care-of address from an Agent Advertisement), it must reply with the
   Code field set to "poorly formed Request" [RFC3344].

   If the Registration Request has the 'T' bit set, the mobile node is
   requesting Reverse Tunneling [RFC3024].  In this case, the foreign
   agent has to tunnel packets from the mobile node to the GFA for
   further handling.

   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 [RFC3344].  For each pending or
   current home registration, the foreign agent maintains a visitor list
   entry as described in [RFC3344].  If reverse tunneling is being used,
   the visitor list MUST, in addition to the fields required in
   [RFC3344], 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 (see Section 10).





Gustafsson, et al.        Expires May 23, 2005                 [Page 12]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


4.3  GFA Considerations

   For each pending or current home registration, the GFA maintains a
   visitor list entry as described in [RFC3344].  This visitor list
   entry is also updated for the regional registrations performed by the
   mobile node.  In addition to the fields required in [RFC3344], the
   list entry MUST contain:

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

   The default replay protection style for Regional Registrations is
   timestamp-based replay protection, as defined in Mobile IPv4
   [RFC3344].  If the timestamp sent by the mobile node in the
   Registration Request is not close enough to the GFA's time of day
   clock, the GFA adds a Replay Protection Style extension (see Section
   8.3) to the Registration Reply, with the GFAs time of day in the
   Identification field to synchronize the mobile node with the GFA for
   the Regional Registrations.  If nonce based reply protection is used,
   the GFA adds a Replay Protection Style extension to the Registration
   Reply, where the high-order 32 bits in the Identification fields is
   the nonce that should be used by the mobile node in the following
   Regional Registration.

   If the Registration Request message contains a Replay Protection
   extension (see Section 8.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 REPLAY_PROT_UNAVAIL (see Section 8.4).

   If the care-of address field of the Registration Request is set to
   zero, the GFA assigns a GFA care-of address for this Mobile Node, and
   adds a GFA IP Address extension with this address of to the
   Registration Request message.  The GFA 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.

   The GFA IP Address extension has to be protected so that it can't be
   changed by a malicious node when the Registration Request is
   forwarded to the HA.  If the HA and the GFA have a mobility security
   association, the GFA IP Address extension MUST be protected by the
   HA-FA authentication extension.  Otherwise the Registration Request



Gustafsson, et al.        Expires May 23, 2005                 [Page 13]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   MUST be sent to the HA in a secure way, for example via a secure AAA
   protocol (see e.g.  [I-D.ietf-aaa-diameter-mobileip],
   [I-D.ietf-mip4-aaa-key]).

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

   If the GFA receives a Registration Request from a mobile node that it
   already has a mobility binding for, this is an update of a binding
   that is about to expire.  If the address in the Hierarchical Foreign
   Agent extension is the same as the current care-of address in the
   visitor list for the mobile node, the entries in the visitor list
   concerning regional registrations are not changed, except to update
   the lifetime.  If the address in the Hierarchical Foreign Agent
   extension is a new address, the values for the regional registration
   are updated.

   If the Registration request has the 'T' bit set, the GFA has to
   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 (that of the FA).

4.4  Home Agent Considerations

   A Registration Request that does not contain a GFA IP Address
   extension is processed by the home agent as described in [RFC3344].
   If a home agent receives a Registration Request with this extension,
   and the home agent does not allow the use of this extension, the home
   agent must return a Registration Reply with the Code value set to
   ZERO_COA_NOT_SUPP (see Section 8.4).  (If a Home Agent that does not
   support Regional Registrations receives a Registration Request with a
   GFA IP Address extension, the request will be process as described in
   [RFC3344].) 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



Gustafsson, et al.        Expires May 23, 2005                 [Page 14]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   Request is accepted, the home agent MUST 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 (see
   Section 8.4).  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 A).  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 (the MN-FA security association in the home
   registrations).

   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
   existing mobility security association between the GFA and the mobile
   node (either using the SA established during the home registration,
   or using pre-configured keys) and the message is authenticated by the
   MN-GFA Authentication Extension (see Section 10).  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



Gustafsson, et al.        Expires May 23, 2005                 [Page 15]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   list.  The GFA then issues a Regional 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 (see
   Section 9.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 [RFC3344].  The information is
   also updated for the regional registrations performed by the mobile
   node.  In addition to the information described in [RFC3344], the
   mobile node MUST maintain the following information, if present:

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

   The replay protection for registrations and regional registrations is
   performed as described in [RFC3344].  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 [RFC3012].  In this case, the mobile node inserts the 64 bit



Gustafsson, et al.        Expires May 23, 2005                 [Page 16]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   response value (timestamp or nonce, according to Mobile IPv4
   [RFC3344]) in the Identification field in the Regional Registration
   Request.  Thus, the GFA SHOULD expect such an Identification field.
   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 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 [RFC3344].  If reverse tunneling
   is being used, the visitor list MUST contain the address of the GFA,
   in addition to the fields required in [RFC3344].  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 NO_HOME_REG.

   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, et al.        Expires May 23, 2005                 [Page 17]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


6.  Generalized NAI Extension

   The revised specification for "IP Mobility Support for IPv4"
   [RFC3344] defines a new extension header format, that is intended to
   extend the Mobile IP extension address space.  The use of a Network
   Access Identifier (NAI) [RFC2486] for mobile nodes is specified for
   Mobile IPv4 in [RFC2794].  The Generalized NAI (GNAI) extension,
   defined in this section, uses the new extension header format to
   extend this idea, enabling NAIs to be used for identifying IPv4
   mobility agents (i.e.  the Foreign Agent or the Home agent) or other
   possible network elements that may be involved with the processing of
   Registration Requests.  For Regional Registration, only a single
   sub-type is defined; it is used to carry a Foreign Agent's NAI (see
   Section 7.2).

   The GNAI extension, illustrated below, may be carried by Registration
   Request and Reply messages.

   The Generalized NAI (GNAI) Extension:


         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      |   Sub-Type    |    NAI ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type
      (Type to be assigned by IANA) (skippable)

   Length
      8-bit unsigned integer.  Length of the extension, in octets,
      excluding the extension Type and the extension Length fields, but
      including the Sub-Type field and the variable length NAI field.

   Sub-Type
      8-bit unsigned integer identifying the specific sub-type of the
      GNAI extension, and thus be implication the type of the entity
      which is to be identified by using the NAI.

   NAI
      A string containing the Network Access Identifier NAI in the
      format prescribed in [RFC2486].


   When a mobile node or home agent adds a GNAI extension to a
   registration message, the extension MUST appear prior to any



Gustafsson, et al.        Expires May 23, 2005                 [Page 18]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   authentication extensions.

   When the Foreign Agent adds an GNAI extension to a registration
   message, the extension MUST appear prior to any authentication
   extensions added by the FA.

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

7.1  Regional Registration Flag

   The only change to the Mobility Agent Advertisement Extension defined
   in [RFC3344] 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 [RFC3344], [RFC3024] and [route-optim].

   Regional registration flag:


        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.



7.2  Foreign Agent NAI Extension

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

   The foreign agent SHOULD include its NAI in the Agent Advertisement



Gustafsson, et al.        Expires May 23, 2005                 [Page 19]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


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

   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.

8.  Regional Extensions to Mobile IPv4 Registration Messages

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

8.1  GFA IP Address Extension

   If the mobile node requests a dynamically assigned GFA, the GFA adds
   a GFA IP Address extension to the Registration Request before
   relaying it to the HA.  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.

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








Gustafsson, et al.        Expires May 23, 2005                 [Page 20]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   Type
      TBD (GFA IP Address)

   Length
      4

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


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


   Type
      TBD (Hierarchical Foreign Agent)

   Length
      4







Gustafsson, et al.        Expires May 23, 2005                 [Page 21]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


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


8.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
   protection for Regional Registration messages exactly as specified in
   Mobile IPv4 [RFC3344] for timestamp-based replay protection.

   If the mobile node requires nonce-based replay protection, also as
   specified in Mobile IPv4, 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 GFA also uses this extension by adding a Replay Protection Style
   extension to a Registration Reply to synchronize the replay
   protection for Regional registrations (see Section 4.3).

   The format of the Replay Protection extension is:


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


   Type
      TBD (Replay Protection Style)








Gustafsson, et al.        Expires May 23, 2005                 [Page 22]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   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 [RFC3344]     |
                  | 1     | nonce [RFC3344]         |
                  +-------+-------------------------+

   The Replay Protection Style extension MUST be protected by an
   authentication extension.  If the mobile node has an established
   mobility security association with the GFA, the Replay Protection
   Style extension SHOULD be placed after the MN-HA authentication
   extension and before the MN-FA authentication extension.  Otherwise
   the Replay Protection Style extension MUST be placed before the MN-HA
   authentication extension.

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

8.4  New Code Values for Registration Reply

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

   Registration denied by the FA:

          +--------------------+-------+---------------------+
          | Error Name         | Value | Section of Document |
          +--------------------+-------+---------------------+
          | SMOOTH_HO_REQUIRED | TBD   | Section 4           |
          +--------------------+-------+---------------------+






Gustafsson, et al.        Expires May 23, 2005                 [Page 23]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   Registration denied by the GFA:

         +---------------------+-------+---------------------+
         | Error Name          | Value | Section of Document |
         +---------------------+-------+---------------------+
         | REPLAY_PROT_UNAVAIL | TBD   | Section 8.3         |
         | GFA_ID_MISMATCH     | TBD   | Section 4.3         |
         +---------------------+-------+---------------------+

   Registration denied by the HA:

         +---------------------+-------+---------------------+
         | Error Name          | Value | Section of Document |
         +---------------------+-------+---------------------+
         | ZERO_CAREOF_ADDRESS | TBD   | Section 4.4         |
         | ZERO_COA_NOT_SUPP   | TBD   | Section 4.4         |
         +---------------------+-------+---------------------+


 9.   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
   registration messages are protected.  The following rules apply to
   authentication extensions:

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

9.1  Regional Registration Request

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

   Regional Registration Request:





Gustafsson, et al.        Expires May 23, 2005                 [Page 24]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


        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      |S|B|D|M|G|r|T|x|          Lifetime             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Home Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         GFA IP Address                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Care-of Address                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                         Identification                        +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Extensions ...
       +-+-+-+-+-+-+-+-


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

   Type
      TBD (Regional Registration Request)

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

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

   Extensions
      For the Regional Registration Request, the Hierarchical Foreign
      Agent Extension is also an allowable extension in addition to
      those which are allowable for the Registration Request message.


9.2  Regional Registration Reply

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

   In the Regional Registration Reply message, the UDP header is
   followed by the Mobile IP fields shown below:





Gustafsson, et al.        Expires May 23, 2005                 [Page 25]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


        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      |     Code      |           Lifetime            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Home Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Regional FA IP Address                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                         Identification                        +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Extensions ...
       +-+-+-+-+-+-+-+-


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

   Type
      TBD (Regional Registration Reply)

   Regional FA IP Address
      The IP address of the Gateway Foreign Agent.  (Replaces Home Agent
      field specified in Mobile IPv4 [RFC3344]).

   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.


9.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 Mobile IPv4
   [RFC3344].











Gustafsson, et al.        Expires May 23, 2005                 [Page 26]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   Registration denied by the FA:

        +-----------------------+-------+---------------------+
        | Error Name            | Value | Section of Document |
        +-----------------------+-------+---------------------+
        | UNKNOWN_GFA           | TBD   | Section 5.2         |
        | GFA_UNREACHABLE       | TBD   |                     |
        | GFA_HOST_UNREACHABLE  | TBD   |                     |
        | GFA_PORT_UNREACHABLE  | TBD   |                     |
        | SMOOTH_HO_REQUIRED    | TBD   | Section 4           |
        +-----------------------+-------+---------------------+

   Registration denied by the GFA:

             +--------------+-------+---------------------+
             | Error Name   | Value | Section of Document |
             +--------------+-------+---------------------+
             | NO_HOME_REG  | TBD   | Section 5.3         |
             +--------------+-------+---------------------+

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

10.  Authentication Extensions

   In this section, two new subtypes for the Generalized Authentication
   Extension [RFC3012] are specified.  First, 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 [RFC3344] (e.g.  MN-AAA [RFC2794], see
   Appendix B) 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 for these new subtypes are as follows:

                   +------------------------+-------+
                   | Subtype Name           | Value |
                   +------------------------+-------+
                   | FA-FA authentication   | TBD   |
                   | MN-GFA authentication  | TBD   |
                   +------------------------+-------+




Gustafsson, et al.        Expires May 23, 2005                 [Page 27]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


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

11.  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 [RFC3344], [I-D.ietf-aaa-diameter-mobileip]
   or [route-optim].  Key distribution is to be performed, for instance,
   according to [I-D.ietf-aaa-diameter-mobileip] or
   [I-D.ietf-mip4-aaa-key].  Or the keys can be pre-configured.

   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 (see Section 10) 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.

12.  IANA Considerations

   This document defines:

   o  The Generalized NAI extension, specified in Section 6.  The type
      number for this new extension is to be assigned from the number
      space for Mobile IPv4 skippable extensions (128-255).
   o  A Sub-Type for the GNAI extension is specified in Section 7.2,
      which needs to have a value assigned from the space of GNAI
      subtypes.
   o  Three new extensions to Mobile IP Registration messages:  GFA IP
      Address, Hierarchical Foreign Agent, and Replay Protection Style
      (see Section 8.1, Section 8.2 and Section 8.3).  The Type values
      for the GFA IP Address extension must be within the range 0
      through 127, while the other two must be within the range 128
      through 255.
   o  New Code values for Registration Reply messages (see Section 8.4).
   o  Two new subtypes for the Generalized Authentication Extension
      [RFC3012]; see Section 10.
   o  Two new message types for Mobile IP: Regional Registration Request
      and Regional Registration Reply (see Section 9.1 and Section 9.2).
   o  Code values for Regional Registration Reply messages (see Section
      9.3).

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



Gustafsson, et al.        Expires May 23, 2005                 [Page 28]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   at the Nokia Research Center for his commentary on a rough version of
   this document, and providing motivation for Section 4.

   The text in Section 6 was taken directly from a previous Internet
   Draft [I-D.ietf-mobileip-gnaie] written by Mohamed M.  Khalil, Emad
   Qaddoura, Haseeb Akhtar of Nortel Networks, along with Pat R.
   Calhoun of Airespace Networks.

14.  References

14.1  Normative References

   [RFC1256]  Deering, S., "ICMP Router Discovery Messages", RFC 1256,
              September 1991.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
              RFC 2486, January 1999.

   [RFC2794]  Calhoun, P. and C. Perkins, "Mobile IP Network Access
              Identifier Extension for IPv4", RFC 2794, March 2000.

   [RFC3012]  Perkins, C. and P. Calhoun, "Mobile IPv4
              Challenge/Response Extensions", RFC 3012, November 2000.

   [RFC3024]  Montenegro, G., "Reverse Tunneling for Mobile IP,
              revised", RFC 3024, January 2001.

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

14.2  Informative References

   [I-D.ietf-aaa-diameter-mobileip]
              Calhoun, P., Johansson, T., Perkins, C. and T. Hiller,
              "Diameter Mobile IPv4 Application",
              draft-ietf-aaa-diameter-mobileip-20 (work in progress),
              August 2004.

   [I-D.ietf-mobileip-gnaie]
              Khalil, M., Qaddoura, E., Akhtar, H. and P. Calhoun,
              "Generalized NAI (GNAIE) Extension for Mobile IPv4",
              draft-ietf-mobileip-gnaie-05 (work in progress), October
              2001.

   [I-D.ietf-mip4-aaa-key]



Gustafsson, et al.        Expires May 23, 2005                 [Page 29]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


              Perkins, C. and P. Calhoun, "AAA Registration Keys for
              Mobile IPv4", draft-ietf-mip4-aaa-key-06 (work in
              progress), June 2004.

   [route-optim]
              Perkins, C. and D. Johnson, "Route Optimization in Mobile
              IP", September 2001,
              <http://www.watersprings.org/pub/id/draft-ietf-mobileip-op
              tim-11.txt>.


Authors' Addresses

   Eva Gustafsson
   Ericsson
   Torshamnsgatan 23
   SE-164 80 Stockholm
   Sweden

   EMail: eva.gustafsson@ericsson.com


   Annika Jonsson
   Ericsson
   Torshamnsgatan 23
   SE-164 80 Stockholm
   Sweden

   EMail: annika.jonsson@ericsson.com


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

   EMail: charles.perkins@nokia.com

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




Gustafsson, et al.        Expires May 23, 2005                 [Page 30]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   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 [route-optim], with some modifications as
   explained below.

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 [RFC3344].  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 [route-optim].  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):

   o  Address of announcing foreign agent
   o  Address of the next higher-level Regional Foreign Agent (RFA)
   o  ...
   o  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.



















Gustafsson, et al.        Expires May 23, 2005                 [Page 31]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   The figure below shows a domain with a GFA and multiple hierarchies
   of FAs, enabled for regional registrations:


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


                                Figure 5

   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 [route-optim].  The
   Binding Update that results is processed as described in Section 2.

   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
   constructs a Binding Update and sends it to the previous foreign
   agent, as defined in [route-optim].



Gustafsson, et al.        Expires May 23, 2005                 [Page 32]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   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 [RFC3344]), the
   list entry for regional registrations MUST contain:

   o  the address of the next lower-level RFA, or FA, in the hierarchy
   o  the remaining Lifetime of the regional registration
   o  the style of replay protection in use for the regional
      registration
   o  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 [RFC3344].  The list entry is also
   updated for regional registrations reaching the GFA.  In addition to
   the list entry contents required in [RFC3344], the list entry MUST
   contain:

   o  the address of the next lower-level RFA in the hierarchy
   o  the remaining Lifetime of the regional registration
   o  the style of replay protection in use for the regional
      registration
   o  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 way of
   other AAA functions [I-D.ietf-mip4-aaa-key].  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.  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



Gustafsson, et al.        Expires May 23, 2005                 [Page 33]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   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 [I-D.ietf-mip4-aaa-key].

   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 [RFC3344], and
   relays the Registration Reply to the mobile node.

2  Handling Binding Updates

   Meanwhile, when the previous foreign agent receives the Binding
   Update, it will process it according to [route-optim], 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.
   This is done to make sure that all RFAs in the path 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
   [route-optim], 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,
   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
   [route-optim] and it is addressed to the mobile node and sent down
   the hierarchy via the old path and the previous Foreign Agent, who



Gustafsson, et al.        Expires May 23, 2005                 [Page 34]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   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, and will send a Binding Acknowledge message to the
   mobile node (via the old route).  It also forwards the Registration
   Request up to the next FA.  The foreign agents above the crossover FA
   in the hierarchy that already got the Binding Update will see that
   the Registration Request does not supply any new care-of address
   information (the care-of address is the same as the address in the
   Binding Update) and will therefor ignore the previous Binding Update
   and update the mobility binding according to the Registration
   Request.

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



Gustafsson, et al.        Expires May 23, 2005                 [Page 35]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   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.  That means that if the
   crossover FA receives the Binding Update before it receives the
   Registration Request, it forwards the Registration Request to the
   higher level FA, so that that FA updates its visitor list according
   to the Registration Request, and ignores the Binding Update.  That FA
   also forwards the Registration Request to any FA or GFA that it has
   sent the corresponding Binding Update to.

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

4  Regional Registrations and Smooth Handover

   Multiple hierarchy levels of foreign agents requires the use of
   smooth handover from [route-optim], as discussed in Appendix A.  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



Gustafsson, et al.        Expires May 23, 2005                 [Page 36]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   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 7.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 FA-NAI will be used to identify the Previous Foreign
   agent instead.  This will be done by adding an FA-NAI extension
   (defined in Section 6) 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.

5  Co-located care of address

   If a mobile node uses a co-located care-of address, it MAY use
   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.

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.

   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 [RFC3344] or



Gustafsson, et al.        Expires May 23, 2005                 [Page 37]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   [RFC3024].

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

Appendix B.  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
   by the mobile and forward the appropriate authorization request to a
   local AAA server (see [RFC3012], [I-D.ietf-aaa-diameter-mobileip]).

   Concretely, this means that:

   o  The GFA MAY include the Mobile IP Registration Request data inside
      an authorization request, directed to a local AAA server.
   o  The GFA MAY receive the Mobile IP Registration Reply data from a
      message granting authorization, received from the AAA
      infrastructure.

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



Gustafsson, et al.        Expires May 23, 2005                 [Page 38]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


   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, et al.        Expires May 23, 2005                 [Page 39]

Internet-Draft     Mobile IPv4 Regional Registration       November 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Gustafsson, et al.        Expires May 23, 2005                 [Page 40]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/