[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Mobile IP Working Group                                  Jari T. Malinen
INTERNET DRAFT                                                 Franck Le
2 March 2001                                          Charles E. Perkins
Category:  Standards Track                         Nokia Research Center

                   Mobile IPv6 Regional Registrations
                 draft-malinen-mobileip-regreg6-01.txt


Status of This Memo

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

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at:
        http://www.ietf.org/shadow.html.


Abstract

   This document describes Mobile IPv6 regional registration as an
   optional extension to Mobile IPv6.  Regional registration introduces
   visited-domain mobility agent functionality for proxying a public
   care-of-address which remains the same while the mobile node
   moves in the visited domain.  This reduces the binding update
   signaling latency for the mobile node and signaling load outside the
   visited domain.  The protocol defines regional mobility capability
   negotiation, regional binding update signaling, and regional-aware
   data routing through a hierarchy of visited-domain mobility agents.
   The protocol allows for an arbitrary point in the visited-domain
   hierarchy to distribute the connection-state maintenance between
   several mobility agents.  IPSec AH is used for securing the protocol
   as in basic Mobile IPv6.






Malinen, Le, Perkins          Expires 2 November 2001           [Page 1]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


                                Contents


Status of This Memo                                                    1

Abstract                                                               1

 1. Introduction                                                       3

 2. Terms                                                              4

 3. Protocol Operation Overview                                        5
     3.1. Movement to a new Link  . . . . . . . . . . . . . . . . .    7
     3.2. Visited-domain capability discovery . . . . . . . . . . .    8
     3.3. Regional Registrations signaling  . . . . . . . . . . . .    8
     3.4. Regional-Aware Data Routing . . . . . . . . . . . . . . .   10

 4. Protocol Extensions                                               11
     4.1. Router Advertisement modifications  . . . . . . . . . . .   12
     4.2. Regional CoA Extension  . . . . . . . . . . . . . . . . .   12
     4.3. Regional Binding Update . . . . . . . . . . . . . . . . .   14
     4.4. Previous Access Router Sub-Option . . . . . . . . . . . .   14

 5. New requirements for IPv6 Nodes                                   15
     5.1. Visited Domain Router Requirements  . . . . . . . . . . .   16
     5.2. Mobile Node Requirements  . . . . . . . . . . . . . . . .   16

 6. IANA Considerations                                               16

 7. Security Considerations                                           16

 A. Changes to the previous version                                   18

 B. Regional Registrations Security                                   19
     B.1. Trust delegation  . . . . . . . . . . . . . . . . . . . .   20
     B.2. Key distribution principles . . . . . . . . . . . . . . .   20
     B.3. The full per -mobile trust delegation model   . . . . . .   21
           B.3.1. Regional Registrations Key Distribution . . . . .   21
           B.3.2. Anti replay attacks . . . . . . . . . . . . . . .   21
           B.3.3. Key Material Destination Option . . . . . . . . .   22
     B.4. "trust delegated to edge routers" security model  . . . .   23
           B.4.1. Security Association Acquisition from AAA . . . .   23
           B.4.2. Movement to a new Link  . . . . . . . . . . . . .   25
           B.4.3. Anti replay attacks . . . . . . . . . . . . . . .   25
     B.5. Forwarding Modes and comparison of these different modes from
             a security point of view . . . . . . . . . . . . . . .   26

Addresses                                                             28




Malinen, Le, Perkins          Expires 2 November 2001           [Page 2]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


1. Introduction

   Mobile IPv6 regional registration reduces the binding update
   signaling latency and the signaling load for a mobile node moving
   within the same visited domain.  The latency is reduced by localizing
   binding updates to the visited domain and the signaling load is
   reduced by using a regional-aware router for a proxy care-of-address,
   as seen by hosts outside the visited domain.  The protocol re-uses
   the general idea of regional registrations for Mobile IPv4 [3], but
   is a different IPv6-specific protocol.

   The regional care-of address can be in an arbitrary node in the
   visited domain, not just in an edge router or the gateway mobility
   agent highest in the hierarchy.  The selection of a particular
   regional care-of address is done by the mobile node from a list of
   addresses advertised by the access router.

   The regional binding update is transported over an arbitrary-depth
   tree hierarchy of regional-aware routers up to the closest possible
   router in the hierarchy.  This router is the crossover between the
   old path from the gateway router to the previous access router and
   from the gateway router to the new access router.  The protocol
   supports network-controlled selection of the crossover router
   which hides the inner structure of the hierarchy and enables
   constant-length signaling independent of the depth of the hierarchy.

   The regional registration protocol does not require modifications
   to any network elements other than the mobile node and the
   regional-aware routers.  These modifications are optional additions
   to basic Mobile IPv6.  Non-regional-aware routers, hosts, home
   agents, and mobile nodes can interoperate with regional-aware
   entities without change.

   The added routing state maintenance in the visited domain is minimal.
   It does not involve the routing tables at all; all per-mobile state
   is kept in the regional binding cache.  This data structure is
   internal to the regional mobility agent and can re-use the existing
   binding cache.

   Security is provided with the same signaling protection extensions as
   in the basic Mobile IP. However, for an efficient MN-visited domain
   signaling security, dynamic security association acquisition and
   usage is discussed Appendix B.

   A special anycast address represents the visited domain and the
   visited-domain part of the obtained key material is propagated within
   the anycast group.





Malinen, Le, Perkins          Expires 2 November 2001           [Page 3]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   This protocol defines the regional registration signaling for IPv6
   and it can be used in combination with other components of the
   general smooth hand-over framework [6] for gaining cost-efficient
   signaling.  In such a combination, the mobile node sends the message
   over the wireless interface encapsulated with the state transfer SHIN
   option up to the access router.  The encapsulating header may carry
   e.g. buffering [7] or header compression [5] state transfer signaling
   needed for smooth and efficient handovers.


2. Terms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].

   In addition, this document uses the following terms:

      Access Router
               The closest router to the mobile node in the visited
               domain that the mobile node uses to access the network.

      Crossover Router
               When a mobile node is performing a regional registration,
               the Crossover Router is the router where the old path
               leading to a mobile node and the new path cross, i.e.
               the regional router in the hierarchy where a connection
               state change is needed to maintain an up-to-date
               communication path to the mobile node.

      Gateway Mobility Agent
               The software module implementing regional registrations
               in the gateway router.

      Gateway Router
               A router controlling the regional care-of-address of a
               mobile node which may be located anywhere in the physical
               hierarchy.

      Highest Router
               Router used in a visited domain as the root of a physical
               hierarchy; The visible hierarchy for a mobile node is
               thus rooted at the gateway router possibly below the
               highest router.

      Home Binding
               The binding cache entry in a home agent used for storing
               home registration state.




Malinen, Le, Perkins          Expires 2 November 2001           [Page 4]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


      Home Registration
               Sending a binding update to the home agent to create a
               home binding.

      Regional-aware Router
               Router that supports regional registrations.

      Regional Binding Cache
               A conceptual data structure in regional-aware routers;
               it is keyed on the home address of a mobile node and
               contains the care-of-address, lifetime, flags, security
               association, and network interface as data elements.  All
               regional routing state is contained in this entry.

      Regional Care-of-address
               A care-of-address, as seen from outside the visited
               domain, used to locate a mobile node.  Remains the same
               while the mobile node does regional binding updates
               within a visited domain.

      Regional Mobility Agent
               The software module implementing regional registrations
               in a regional-aware router.

      Visited Domain
               A domain that is visited by the mobile node; a set of
               subnets usually administered by one entity.  In this
               document, all routers in a visited domain are assumed to
               have a security association with one another.

   This terminology is intended to conform to those that have been
   used in Mobile IP and other Internet protocols.  Basic Mobile IPv6
   terminology is used as defined in [4].


3. Protocol Operation Overview

   A foreign domain advertises its capability for regional registrations
   with a newly defined router advertisement flag.  When entering a
   visited domain for the first time, the mobile node registers with its
   home domain.  During or after this registration, the mobile node can
   perform a regional registration.

   A regional registration establishes a regional care-of-address
   that is seen from outside the visited domain as the mobile node's
   primary care-of-address.  This address is controlled by one of the
   visited-domain routers and the mobile node obtains the address from a
   list of Regional CoA extensions (Section 4.2), attached to the router
   advertisement.



Malinen, Le, Perkins          Expires 2 November 2001           [Page 5]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001



                              ________
        +------------+       /        \     +--------------------+
        | Home Agent |------( Internet )----| Corresponding node |
        +------------+       \________/     +--------------------+
                                  |
                                  | regional          \
                                  | care-of-address    +
                      +------------------------+       |
                      | Gateway Mobility Agent |       |
                      |         (GMA)          |       |
                      +------------------------+       |
                                /  \                   |
                             1./    \                  |
                              /      \                 |
              +------------------+  +--------+         |
              | Crossover Router |  | Router |         |
              +------------------+  +--------+         \
                      /  \                              \   Visited
                   1./    \ 2.                          /   Domain
                    /      \                           /
           +----------+     +--------+                 |
           | Previous |     |   New  |                 |
           |  Access  |     | Access |                 |
           |  Router  |     | Router |                 |
           +----------+     +--------+                 |
                  ^           ^                        |
                  |1.         |2.                      |
                  |           |                        |
                  +-+         +-+  (on-link) primary   |
                  | |   --->  | |   care-of-address    |
                  +-+         +-+                      +
                 Mobile      Mobile                   /
                  Node        Node



             Figure 1: Hierarchy of regional-aware routers



   After obtaining a regional care-of-address, the mobile node stores
   the current visited domain identity, and sends binding updates to
   its home agent and corresponding nodes.  The mobile node uses the
   regional care-of-address as the alternate care-of-address when
   sending basic Mobile IPv6 binding updates to nodes outside the
   visited domain.





Malinen, Le, Perkins          Expires 2 November 2001           [Page 6]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   While staying within the visited domain, the mobile node MAY send
   regional binding updates for the duration of its home binding.  The
   mobile node may also send ordinary binding updates to the home agent
   or to corresponding nodes at any time.

   Figure 1 illustrates a typical regional registration scenario.  The
   mobile node sends a regional binding update to the crossover router
   which updates its connection state from the old path to the new path.
   The gateway router is the crossover router during the first regional
   registration (signal 1).  After this (signal 2), the crossover may
   exist lower in the hierarchy.

   The regional binding update is a modified Binding Update destination
   option.  It updates the regional binding cache entries of a mobile
   node in regional-aware router hierarchy.  The binding update also
   enables the visited domain to decide the crossover router.  The
   mobile node attaches additional information to this binding update
   such that a regional-aware router can decide from it whether it is a
   crossover router.

   The regional binding cache is used for regional data routing,
   forwarding of encapsulated or source-routed Mobile IPv6 data packets
   to the mobile node.  The binding cache entries are deleted by timeout
   or by de-registration.  The semantics of this is identical to that in
   basic Mobile IPv6.


3.1. Movement to a new Link

   When entering a new foreign link, with the same or another visited
   domain, the mobile node performs movement detection and uses router
   discovery to discover new routers as defined in Mobile IPv6.  The
   mobile node may also receive a handover indication from the link
   layer and consequently send a router solicitation.  Similarly,
   the mobile node may receive an unsolicited router advertisement
   containing the indication that handover is imminent.

   The mobile node also performs visited domain detection as an
   additional part of the movement detection of basic Mobile IPv6.
   The mobile node uses as visited domain identity a ``visited
   domain routers'' anycast address.  This is derived from the
   selected regional care-of-address in the router advertisement
   option (Section 4.1) and used for detecting movement to a new visited
   domain.  This identity MUST be unique.

   The anycast address is formed from the prefix in the regional
   care-of-address extension and a host number 0 (TBD). The prefix
   can e.g.  be shorter than the actual prefix of the regional
   care-of-address in the gateway router.  Such a shorter prefix can



Malinen, Le, Perkins          Expires 2 November 2001           [Page 7]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   thus contain many regional care-of-addresses in the same visited
   domain.

   When the mobile node changes its regional care-of-address, or
   when the selected regional care-of-address is not in the router
   advertisement of the new access router, the mobile node SHOULD behave
   as if it arrived to a new visited domain.  This avoids the situation
   where the crossover router would be beyond the GMA in the hierarchy.

   The mobile node then selects its primary care-of-address, which
   is on the same link as is the access router, as defined in Mobile
   IPv6.  The address is co-located to the mobile node together with its
   routing identity, its home address, and used as the target for local
   communication between the visited domain and the mobile node.  The
   mobile node MAY also use this address as the care-of-address in its
   binding updates for corresponding nodes within the visited domain.


3.2. Visited-domain capability discovery

   The router advertisement from a regional-aware router contains flags
   to indicate the supported capabilities.  The supported capability
   flag for regional registrations is the `I' bit in the Reserved1 field
   of the Mobile IPv6 Modified Router Advertisement Message's Modified
   Prefix Information Option [4].

   If the `I' bit is set, the mobile node SHOULD make use of regional
   registration.  In this case, the mobile node selects its regional
   care-of-address from the one or more regional care-of-address
   extensions in the router advertisement.


3.3. Regional Registrations signaling

   When entering the visited domain, the mobile node performs a home
   registration in combination with the first regional binding update.
   The regional binding update MAY be an outer encapsulator around the
   home registration binding update.

   The regional binding update is a modified Mobile IPv6 binding update
   destination option.  It propagates upwards hop-by-hop through a
   hierarchy of regional-aware routers to a router controlling the
   selected regional care-of-address.  There may be regional-unaware
   routers between adjacent regional-aware routers in a hierarchy.

   The regional care-of-address can be an address of the visited domain
   router or an address from a pool of regional care-of-addresses
   controlled by a router.  Association between such a care-of-address




Malinen, Le, Perkins          Expires 2 November 2001           [Page 8]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   and a router within the visited domain, selected as target of the
   first regional binding update, is implementation-specific.

   The destination address in the IP header of the regional binding
   update at the sending mobile node is the ``visited domain routers''
   anycast address.  It MAY also be the IP address of the access router.
   A packet sent to this address is first received by the regional-aware
   access router.  There MUST be a home address destination option in
   the IPv6 packet carrying the regional binding update as with basic
   Mobile IPv6.

   The regional binding update is then propagated to the next-higher
   regional-aware router by encapsulation.  The encapsulating header
   around the regional binding update or around the returned binding
   acknowledgement MAY carry key material within the anycast group as
   described in Appendix B.

   When the regional binding update is re-sent from the receiving router
   up to the next higher router, each regional-aware router establishes
   or updates its regional binding cache entry for the mobile node.
   The key to the entry is the home address, and the care-of-address
   is the source address of the regional binding update received from
   the next lower regional-aware router.  In the access router, the
   care-of-address is the sending link address of the mobile node.
   Implementation of the regional binding cache can reuse the basic
   Mobile IPv6 binding cache entry with a new `I' flag set.

   Since the network controls the crossover router selection, the
   responding visited domain target router is not known to the mobile
   node.  It sends the packet to the anycast address or the unicast
   address of the router.  The packet is received by the router
   from which the mobile node received the router advertisement.
   The regional care-of-address MUST be inserted as a alternate
   care-of-address sub-option of the regional binding update.  The `A'
   bit MUST be set and the `H' bit MUST NOT be set.

   The mobile node appends the previous access router sub-option (Section 4.4)
   to the regional binding update.  This sub-option identifies the
   previous access router so that each router can locally decide whether
   it is the crossover router.  When the signal is propagated upwards,
   the first router that has the previous access router among its
   descendants is the crossover router.  When this sub-option is absent,
   the regional binding update propagates up to the gateway mobility
   agent.  To know its descendants, a regional-aware router maintains a
   list of all of its descendants.  How this list is configured is out
   of the scope of this protocol; it can be statically configured from a
   parameter file, for example.  Alternatively, a mobile router can set
   the 'R' bit in the regional binding update to join the hierarchy as
   a leaf router.  Then, a descendant list entry is established with a



Malinen, Le, Perkins          Expires 2 November 2001           [Page 9]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   lifetime, and the mobile router marks the upper regional router as a
   father router.

   After a successful regional binding update, a basic Mobile IPv6
   binding acknowledgement is returned to the mobile node back through
   the hierarchy.  In case of signaling where anycast address is
   used all the way through the hierarchy, a binding acknowledgement
   SHOULD be sent to the MN and to the anycast address.  A successful
   regional registration is denoted by a new success status value
   1.  This denotes regional-aware success; status value 0 denotes
   regional-unaware success.  In the latter case, the receiving node
   accepted the binding update as any corresponding node would.  The
   mobile node can thus send regional binding updates to any node and
   recognize regional-awareness of the other end from this status
   value.  This gives the protocol robustness against mis-configured
   regional-aware routers.

   The mobile node SHOULD NOT send binding updates with the regional
   care-of-address to regular nodes until it has received the
   regional-aware success status value 1.  If the regional-aware
   router fails to accept the regional registration, it returns a
   Reason Unspecified status value 128 in the binding acknowledgement.
   However, if the mobile node does not receive status value 1 from
   the gateway mobility agent, the mobile node MUST re-send a binding
   updates with the primary care-of-address.

   A regional-aware mobile node MAY support mobile multi-homing,
   i.e. the mobile node MAY register more than one home address
   simultaneously with one or more home agents.  Operation of these
   addresses occur independently, i.e. as if there were multiple mobile
   nodes within the same physical host.  The mobile node MUST NOT
   register more than one care-of-address for each home address.

   If regional-aware propagation uses unicast addresses, the regional
   binding update is re-generated in each intermediate router.  If the
   first target is anycast address, the propagation MAY change into
   unicast-based inside visited domain or it MAY remain anycast-based.
   A discussion on differencies with these modes is in Appendix B


3.4. Regional-Aware Data Routing

   Since the regional care-of-address is in the visited domain, packets
   targeted to it go through the regional-aware routing hierarchy from
   the GMA towards the mobile node.  The other direction is not affected
   by regional registrations.

   When a corresponding node sends data packets to a mobile node to
   which it does not yet have an entry in its binding cache, these



Malinen, Le, Perkins          Expires 2 November 2001          [Page 10]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   packets are intercepted by the home agent and encapsulated to
   the registered care-of-address mobile node, as specified in the
   basic Mobile IPv6.  However, this care-of-address is the regional
   care-of-address.

   For tunneled packets, the regional care-of-address of the mobile node
   is selected as the target for the outer encapsulation header.  The
   router which controls that regional care-of-address decapsulates the
   tunneled packets.  The destination of the encapsulated packet is the
   home address of the mobile node.

   If there is an entry in the regional binding cache for this home
   address, the router SHOULD re-encapsulate these packets to the
   corresponding lower care-of-address.  This is in the next lower
   regional-aware router or in the mobile node if the forwarder is the
   access router.  Thus, the data packets SHOULD get re-capsulated at
   each regional-aware router on their way down the hierarchy.

   If the lower regional-aware router is at link-distance from the
   forwarding regional-aware router, or a routing protocol maintains
   host-based routes between regional-aware routers, the router
   MAY forward these packets simply by using host-based routes.
   The forwarding MAY also use other methods such that the packet
   propagation occurs as with the above methods.  A method of forwarding
   is local to a router in a way that multiple methods of forwarding can
   be used in a visited domain without a negotiation mechanism.


4. Protocol Extensions

   The following protocol extensions are defined:

    -  A modification to the Modified Router Advertisement Message
       to indicate whether the visited domain supports regional
       registrations (the `I' bit) (Section 4.1).

    -  A regional care-of-address extension to the router
       advertisement (Section 4.2).

    -  A modification to the Binding Update destination option to
       indicate whether the option is a Regional Binding Update (the `I'
       bit) (Section 4.3).

    -  An previous access router sub-option for the binding
       update (Section 4.4).







Malinen, Le, Perkins          Expires 2 November 2001          [Page 11]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


4.1. Router Advertisement modifications

   The router advertisement, as defined in the basic Mobile IPv6,
   contains additionally the `I' bit and the visited domain identity in
   the Modified Prefix Information Option of the Router Advertisement
   Message.  The format of the new Modified Prefix Information Option is
   the following:


    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     | Prefix Length |L|A|R|I|Rsrvd1 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Valid Lifetime                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Preferred Lifetime                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Reserved2                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                            Prefix                             +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


            Figure 2: The Modified Prefix Information Option


      I          Indicates regional registrations support.

   The Rsvrd1 field is here a 4-bit field instead of the 5 bits
   Reserved1 prior to adding the `I' bit.  Other fields are as described
   in the Mobile IPv6 and the Neighbor Discovery [8] documents.


4.2. Regional CoA Extension

   The router advertisement may contain one or more visited-domain
   care-of-addresses from which the mobile node chooses a regional
   care-of-address.  Each such address is advertised in a Regional CoA
   Extension of the modified Router Advertisement.

   The format of the regional CoA extension is the following :




Malinen, Le, Perkins          Expires 2 November 2001          [Page 12]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


    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     | Prefix Length |     Index     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Lifetime                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                   Regional Care-of-Addresses                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 3: Regional CoA extension



      Type       6, TBD (skippable)

      Length     8-bit unsigned integer.  The length of the option
                 (including the type and length fields) in units of 8
                 octets.  This field MUST be 3.

      Lifetime   The time the advertised CoA is valid in the visited
                 domain.

      Prefix Length

                  An 8 bit unsigned integer.  This denotes prefix length
                 of the ``visited domain routers'' anycast address where
                 the prefix is taken from the regional care-of-address
                 and the host number is 0 (TBD). One of these options
                 MUST identify the visited domain.  Prefix length fields
                 in the other regional CoA options in the same router
                 advertisement MUST be zero.

      Index      Index describing which of the global prefixes can be
                 used with this address.  1 denotes the first prefix in
                 the advertisement.  Special value 0 denotes that this
                 address applies to all prefixes.  The options SHOULD be
                 ordered so that regional CoA extensions associated with
                 a given prefix are immediately after that prefix.

      Regional Care-of-Address

                  The advertised address, which MUST be a global IPv6
                 address from the visited domain.





Malinen, Le, Perkins          Expires 2 November 2001          [Page 13]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


4.3. Regional Binding Update

   The Regional Binding Update is a Mobile IP Binding Update with the
   following modifications.  In the Reserved field after the flags
   field, there will be the following additional bit.

   Description of extensions to the BU option:

      I     Indicates regional registrations support.  This implies
            that the receiving router will use the BU information to
            establish or maintain a regional binding cache entry.  The
            bit is the first bit from the Reserved field of the Mobile
            IPv6 Binding Update destination option.

      Previous Access Router Sub-Option

             A sub-option for determining the crossover router.


4.4. Previous Access Router Sub-Option

   The previous access router sub-option is used by the network
   to determine the crossover router.  A crossover router address
   is obtained from the IP header source address of the router
   advertisement.  The mobile node remembers this for the previous
   router and uses it to create an previous access router sub-option.


    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     |    PathId     |  PathCount    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Previous access router                    |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 4: Previous Access Router Sub-option












Malinen, Le, Perkins          Expires 2 November 2001          [Page 14]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


      Type       5, TBD (skippable)

      Length     8-bit unsigned integer.  The length of the sub-option
                 (including the type and length fields) in units of 8
                 octets.

      PathId     8-bit unsigned integer.  This optional field identifies
                 a route for one mobile node with multiple routes within
                 a visited domain from the edge router to GMA.ix from
                 the

      PathCount  8-bit unsigned integer.  Identifies the number of path
                 branches on the path of a regional binding update.
                 This optional field is also used for multiple routes
                 support.  A crossover functionality can e.g.  propagate
                 regional binding updates to the GMA if the PathCount is
                 greater than one.

      Previous access router



                 The IP address of the previous access router as seen by
                 the mobile node.

   There is no requirement for alignment of the Previous Access Router
   sub-option.

   The previous access router sub-option is valid in the Binding Update
   destination option.  The previous access router contains the IPv6
   address of the access router as seen by the mobile node.  It is used
   to identify the crossover router in the visited domain regional
   router graph.  This is done by comparing the previous access router
   to the known descendants when the regional binding update gets
   forwarded upward in the tree of regional-aware routers.  When the
   router finds the previous access router in its list of descendants,
   it is the crossover router.


5. New requirements for IPv6 Nodes

   The presented option requires modifications to the visited-domain
   routers and to the mobile node.  The option does pose no new
   requirements to the home agent, to correspondent nodes, or to other
   network elements than to the regional-aware routers in the visited
   domain.






Malinen, Le, Perkins          Expires 2 November 2001          [Page 15]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


5.1. Visited Domain Router Requirements

   The support of the protocol is optional to basic Mobile IPv6;
   elements can function in both regional-aware and regional-unaware
   visited domains.  Introducing regional-aware routers to a visited
   domain does not mandate the use of regional registrations.

   The regional-aware access router MUST be capable of advertising
   regional registration support.  The router MUST be capable of
   maintaining regional binding cache entries based on regional
   binding updates.  These routers MUST route the data packets to the
   regional-registered mobile nodes so that a mobile node can recognize
   the use of route optimization from the presence of a routing header,
   as described in Section 3.4.


5.2. Mobile Node Requirements

   A regional non-aware mobile node can operate in a regional-aware
   network.  The regional-aware mobile node SHOULD select a regional
   care-of-address and send a regional binding update accordingly.


6. IANA Considerations

   The presented protocol does require the addition of one skippable
   option type to the router advertisement [8] and one skippable
   sub-option type to the Binding Update destination option.

   Also, the protocol requires two modifications from the Modified
   Router Advertisement Message`s Prefix Information Option, one bit in
   its Reserved1 field, from the format specified in the basic Mobile
   IPv6 [4].  The protocol also needs one new bit from the Reserved
   field of the Mobile IPv6 Binding Update option.

   The Binding Acknowledgement would need one new regional-aware success
   code, with a proposed value of 1 to be added to the list of known
   status field values.

   A host number for the ``visited domain routers'' anycast address
   would be needed.  The value 0 is suggested.


7. Security Considerations

   The regional-aware mobile node SHOULD use a mobile-visited-domain key
   for authentication.  The IPSec authentication header (AH) is used for
   security as in basic Mobile IPv6.  In regional signaling, the mobile
   node and visited domain share a security association, in form of a



Malinen, Le, Perkins          Expires 2 November 2001          [Page 16]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   mobile-visited-domain key for IPSec.  The mobile-visited-domain key
   is obtained when entering the visited domain and transported to the
   visited domain routers and to the mobile node.

   The protocol in this document assumes that the routers have a way to
   authenticate messages based on anycast security associations.  The
   usage of AAAL as a source of unique SPIs among all visited domain
   routers, as explained in Appendix A, is utilized to enable the use
   of anycast address -based security association identification.  As
   long as the visited domain anycast address -based SPD entries are
   not created by means other than specified, this allows for the
   use of anycast security association in this particular case.  A
   challenge-response -based replay service for aycast in this case is
   also introduced.






































Malinen, Le, Perkins          Expires 2 November 2001          [Page 17]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


References

   [1] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund.  AAA for
       IPv6 Network Access (work in progress).  Internet Draft, Internet
       Engineering Task Force, March 2000.

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

   [3] Eva Gustafsson, A. Jonsson, and C. Perkins.  Mobile IP Regional
       Registration.  draft-ietf-mobileip-regtun-03.txt, July 2000.
       (work in progress).

   [4] D. Johnson and C. Perkins.  Mobility Support in IPv6 (work in
       progress).  Internet Draft, Internet Engineering Task Force,
       November 2000.

   [5] R. Koodli, M. Tiwari, and C. Perkins.  Header Compression
       State Relocation in IP Mobile Networks (work in
       progress).  Internet Draft, Internet Engineering Task
       Force.  draft-koodli-rhoc-hcompr6-00.txt, July 2000.

   [6] Rajeev Koodli and Charles E. Perkins.  A Framework for
       Smooth Handovers with Mobile IPv6 (work in progress).
       Internet Draft, Internet Engineering Task Force.
       draft-koodli-mobileip-smoothv6-02.txt, November 2000.

   [7] G. Krishnamurthi, R. Chalmers, and C. Perkins.  Buffer
       Management for Smooth Hand-Overs in Mobile IPv6 (work in
       progress).  Internet Draft, Internet Engineering Task Force.
       draft-krishnamurthi-mobileip-ipv6buf-00.txt, July 2000.

   [8] T. Narten, E. Nordmark, and W. Simpson.  Neighbor Discovery for
       IP Version 6 (IPv6).  Request for Comments (Draft Standard) 2461,
       Internet Engineering Task Force, December 1998.

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


A. Changes to the previous version

   This version introduces an anycast address to represent the
   visited domain as a distributed network endpoint in addition to
   supporting the unicast-based approach of the previous version.  A
   one message-exchange multi-level signaling is efficient e.g. when
   the mobile node needs to communicate both with the access router



Malinen, Le, Perkins          Expires 2 November 2001          [Page 18]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   and the gateway mobility agent (GMA). The other changes address
   problems mentioned in earlier working group minutes, in security and
   in providing uniqueness of the visited domain identity.

    -  This version distributes the network endpoint of communication
       identifying it with an anycast address.  A common security
       association per mobile node can be used in the visited domain
       when key material received from AAAv6 is propagated to members of
       the anycast group, as described in Appendix B.  This change also
       preserves the cost-efficiency of having a single message exchange
       with the deep hierarchy while now providing a fully specified
       security option.

    -  The regional forwarding now is based on encapsulation or
       host-based routes.  Other methods specified elsewhere may also be
       used.  The earlier regional forwarding of route-optimized packets
       is now separated into another draft.

    -  The router advertisement now also uniquely identifies the
       visited domain with the special ``visited domain routers''
       anycast address.  This address is formed using prefix of the
       regional care-of-address and a host number 0 (TBD). Thus, no
       visited domain identifier is used in this version from the
       prefix information option.  The same anycast address is used
       by the mobile node to send the regional binding update to the
       distributed endpoint, the destination IP address of the regional
       binding update.

    -  The unicast address of the advertising router can also be used
       as a destination of a regional binding update.  Internally this
       means a different propagation of the regional binding update
       but does not require any extra negotiation between the mobile
       node and the access router.  The mobile node can now send the
       regional binding update to either to the unicast or to the
       anycast address.

    -  A security appendix now describes a temporary security
       association acquisition and propagation mechanisms with
       alternative regional binding update propagation schemes.  These
       give the visited domain builder several configuration options
       while remaining transparent to the mobile node.


B. Regional Registrations Security

   Mobile IPv6 Regional Registrations signaling is secured using
   Authentication Header using binding updates as with Mobile IPv6 home
   registration binding updates.  However, since the communicating
   parties in sending regional binding updates are the mobile node



Malinen, Le, Perkins          Expires 2 November 2001          [Page 19]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   and regional routers, a static security association can not be
   assumed between mobile node and each visited domain in a scalable
   solution.  Regional registrations security considers scalable
   acquisition of the needed security association(s) and their use with
   Authenitcation Header -based security.  This document specifies
   mechanisms and extensions to the Mobile IP Binding Update, and
   binding acknowledgements messages that can be used to distribute such
   security information to the mobile node and visited domain.


B.1. Trust delegation

   A mobile-visited domain security association can be obtained in a
   multiple ways, depending on availability of mechansims and policy
   requirements of the visited domain.  The visited domain can also
   provide open access.

   A regional-aware visited domain can view trust delegation in
   two distinct ways.  A full per-mobile trust delegation from an
   authorization center provides trust from a key distribution center
   in form of per-mobile session key material to every regional-aware
   router which participates to regional signaling.  This can be
   used when propagating a regional binding update unmodified to the
   crossover router.

   A model with trust propagated to the edge routers of a visited domain
   can be used with a policy where the more static intra-visited-domain
   security associations are used for protecting the propagated regional
   binding update.  In this case the regional signals are re-transmitted
   from intermediate regionals routers using new authentication header.
   A benefit is that the visited domain does not need to have per-mobile
   security associations in all routers making the visited domain more
   scalable for a very large number of mobile nodes.


B.2. Key distribution principles

   Security credentials for mobile-visited domain security associations
   can be obtained in a multiple ways.  One way is to assume an
   AAA-based key distribution and use mechanisms like AAA registration
   keys for Mobile IP [9].  The latter provides two key distribution
   schemes for getting temporary session keys for the mobile node and a
   router.

   If trust is delegated to the edge routers, and no per-mobile key
   distribution inside the visited domain is desired, a regional
   binding update is propagated by recreating it with authentication
   headers used between adjacent regional routers.  The regional binding
   acknowledgement is then propagated in a similar way back to the edge



Malinen, Le, Perkins          Expires 2 November 2001          [Page 20]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   router which finally re-sends the binding acknowledgement to the
   mobile node using the mobile-visited-domain security association.

   An intra-visited-domain key distribution mechanism may be applied
   with regional signaling, if full per-mobile trust delegation is
   desired.  A regional binding update is propagated with its original
   authentication header to the crossover router, encapulated with an
   outer IP header and a key distribution option.

   The two modes have the same signaling behavior seen from the mobile
   node.  Thus the visited domain administrator can locally configure
   either of the modes without it being visible to mobile nodes.


B.3. The full per -mobile trust delegation model

B.3.1. Regional Registrations Key Distribution

   A regional-aware gateway router with the selected regional
   care-of-address MAY communicate with the AAAv6 local authority
   during the first regional binding update into a visited domain,
   depending on the local requirements for authorizing network access.
   The visited domain MAY provide temporary access rights for regional
   registrations while the AAA infrastructure is generating a reply to
   the authorization request.  When the AAA has granted access, the
   access to the visited domain is decisively granted.

   AAAv6 is expected to provide temporary key material for the mobile
   node and the visited domain to be used in subsequent regional
   authentications.  As mentioned previously, many solutions currently
   exist like AAA registration keys for Mobile IP IP [9].  This material
   is provided for the mobile node in combination with a Binding
   Acknowledgement, and also for the visited domain.  The latter is then
   propagated together with regional registration signaling in a key
   material destination option.  This option is inserted to the outer
   encapsulation header when propagating subsequent regional binding
   updates or binding acknowledgements inside the visited domain.  It
   can be protected with IPsec using intra-visited-domain security
   associations.

   Or as an alternative, the intermediate routers retrieve the user
   specific session key from the AAA-L which also stores it.


B.3.2. Anti replay attacks

   Anti replay attacks can not be provided by the Sequence number
   specified in the Authentication Header protocol since this requires




Malinen, Le, Perkins          Expires 2 November 2001          [Page 21]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   all the intermediate routers to have synchronized counters which is
   difficult.

   Instead, nonces SHOULD be used to provide anti replay attacks:  The
   mobile node takes the Local Challenge  citedraft-ietf-perkins-aaav6,
   sent in Router advertisements messages, as an input to the
   authentication data computation of the regional binding update
   message.  The Local challenge is then included in the Regional
   Binding Update and the access router first ensures the freshness of
   the message by verifying that the Local Challenge carried in the
   Binding Update message is a recent one.  This Local Challenge is also
   encapsulated with the Regional Binding Update message until the cross
   over router which ensures freshness of the message by verifying that
   the authentication data takes into account the recent Local Challenge
   carried in the message.

   The mobile node SHOULD also generate a Host Challenge that is also
   included in the Binding Update message as a destination option and
   encapsulated until the cross over router which tales that Host
   Challenge as an imput when computing the authentication data of the
   Binding Acknowledgement message.  The Host Challenge is then sent
   back in the Binding Acknowledgement message and the mobile node
   can thus verify the freshness of the reply from the access router
   by making sure the authentication data computationtook this Host
   Challenge into consideration.


B.3.3. Key Material Destination Option

   This is a possible extension to carry the user specific key between
   the intermediate routers.  The message carrying this extension should
   be encrypted and intergrity protected by using intra domain security
   (e.g.  IPsec)


    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    |      Alg      |   Key Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SPI                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Key...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 5: Key Material Destination Option





Malinen, Le, Perkins          Expires 2 November 2001          [Page 22]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


      Type       TBD (skippable), one for key request, one for key reply

      Length     8-bit unsigned integer.  The length of the option
                 (including the type and length fields) in units of 8
                 octets.

      Alg        8-bit algorithm indication as specified for the
                 Authentication Header.

      Key Length

                  8-bit unsigned integer.  The length of the key in
                 units of 4 octets.

      SPI        32-bit Security Parameter Index value.

      Key        Encrypted key material of at most 1024 octets.

   As an alternative, the intermediate routers can retrieve the user
   specific session key fro the AAA-L: this requires only security
   associations between intermediate routers and AAA-L whereas the
   propagation of the user keys requires security associations between
   all the intermediate routers.


B.4. "trust delegated to edge routers" security model

   This section describes another alternative of a security model where
   Regional Registration could deployed securely.  This solution is
   more scalable requiring only user specific security association
   between the MN and the Access routers and then relying on intra
   domain security to authenticate the regional binding update within
   the visited domain.


B.4.1. Security Association Acquisition from AAA

   When entering a visited domain, the mobile node performs a home
   registration in combination with the first regional binding update:

   The mobile node computes some authentication data (e.g. from a
   Local challenge sent to the Hosts in Router advertisments messages,
   from a Home Challenge generated by the Home domain for anti replay
   attacks [1], and using the Long term key shared between the mobile
   node and its Home domain), and adds a Regional Registration key
   request in the regional binding update.

   The destination address in the IP header of the regional binding
   update at the sending mobile node is the source address of the router



Malinen, Le, Perkins          Expires 2 November 2001          [Page 23]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   advertisement containing the selected regional care-of-address or the
   anycast address identifying the visited domain.

   The receiving Access Router, due to the presence of the
   authentication extension, forwards the message to the AAA-L, which
   invokes the AAA-H for entity authentication:  the serving system
   wants to make sure the user is a valid one before giving him access
   to its network resources.  If the Home agent is in the home network,
   this AAA invocation to the Home domain may include the Home Binding
   Update [1] to the Home Agent.  If Home agent is dynamically assigned
   in the home network, AAA-H assigns the Home agent and sends a Binding
   update to the assigned Home agent.  These are possible optimizations
   to save round trips between the visited and home domain reducing time
   delay and load over the network.  In such cases, the home binding
   update may indicate the regional care of address as the alternate
   care-of-address and if regional registration fails (e.g. RcoA is not
   valid), the mobile node will update the Home agent.

   Once authentication succeeded, thanks to the keying material, AAA-L
   can compute a regional registration key K wich is specific to the
   mobile node.  AAA-L sends it to the Access Router with the keying
   material destined to the mobile node for it to be able to derive K.

   The access router then sends the Binding Acknowledgement with some
   extension carrying the keying material to the mobile node which will
   derive K and create a regional binding update authenticated using K.

   As another optimization, since in wireless networks, radio resources
   are limited, the Access router, on receipt of the network access
   authorization from AAA-L, knows the mobile node is valid and can
   perform regional registration thus saving one additional round trip
   over the air interface.

   The access router sends a new binding update to the next-hop cross
   over router to create the binding between the mobile node home
   address and the access router care of address.  This binding update
   is authenticated using a intra domain security association:  Access
   Router and Cross over router share a key which can be set up in
   different ways and is operator dependant.  This key is not user
   specific.

   The Cross over router propagates the binding update until the GMA
   using as previously intra domain security.  Thus, only Access routers
   needs to maintain user specific security asociations which is more
   scalable than having user specific security associations up to the
   GMA requiring the GMA to maintain the security associations for all
   the users it is serving.





Malinen, Le, Perkins          Expires 2 November 2001          [Page 24]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


B.4.2. Movement to a new Link

   When entering a new foreign link within the same domain, the mobile
   node sends a regional binding update authenticated using K. The
   receiving access router can either retrieves the key from the
   previous access router indicated by the mobile node or from the
   AAA-L. The latter option only requires security association between
   access router and AAA-L whereas the first option also needs security
   association between Access routers.

   The access router then verifies the authenticity of the binding
   update message and if succeeded, it sends binding update messages up
   to the crossover router using intra domain security.  Alternatively,
   if so wished by trust delegation policy, the binding update can be
   propagated to the crossover router with the original authentication
   header, and with an outer encapsulation containing a key material
   destination option (Section B.3.3) with the distributed key encrypted
   using intra domain security.  Each router decapsulating this option
   inserts it to its security policy database prior to using it for
   authenticating the regional binding update.


B.4.3. Anti replay attacks

   Between the mobile node and the access router, since the access
   router creates the binding acknowledgement message to the mobile
   node, replay protection can be provided by various methods:

   Timestamps:  The MN and the access router verify the freshness of the
   messages by making sure that the timestamp used is the current one.

   Sequence number:  Authentication header has a Sequence number to
   provide anti replay service.  This counter is one possibility and in
   such cases, when mobile node moves to a new link, the new serving
   access router when retrieving the user specific key K, also needs to
   retrieve the value of this sequence number from the previous access
   router.

   Nonces:  The mobile node can take the Local challenge [1] sent in
   Router Advertisements messages as an input to the AH authentication
   data of regional binding update messages.  The access router
   ensures freshness of binding update message from the mobile node
   by verifying that the local challenge included in the Request is a
   recent one.  The mobile also generates a Host Challenge that will
   be included in the authentication data of the Binding update and
   binding acknowledgement messages.  This way, the host can verify the
   freshness of the reply from the access router.





Malinen, Le, Perkins          Expires 2 November 2001          [Page 25]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


B.5. Forwarding Modes and comparison of these different modes from a
   security point of view

   First, as described in the security models in the previous section,
   the Access Router can either re-create new binding update message
   or encapsulate the mobile node's binding update message to perform
   regional registration within the visted domain.

   The trust model is different but in both cases, the MN needs to
   rely on the intra domain security of the visted domain:  Either
   to re-create binding update message in the "trust delegated to
   edge routers model" or to distribute the keys to the different
   intermediate routers in the "full per-mobile trust delagation model".

   These two models also differ on a scalability point of view:  the
   "trust delegated to edge routers model" only requires user specific
   security associations between mobile nodes and access routers whereas
   the "full per-mobile trust delegation model" requires user specific
   security associations between all the intermediate routers from the
   Access router serving the MN up to the GMA. This may requires many
   security associations to be maintained in particularly for the GMA
   and thus may have some scalability issues.

   In addition, a visited domain can be administratively configured
   to different forwarding schemes.  The visited domain can forward
   the regional binding update and acknowledgement by receiving and
   re-sending them between intermediate regional routers.  This can
   take place when the mobile node initially sends the regional binding
   update either to the advertising router's unicast or to the anycast
   address.  Also, the regional binding update, sent to the anycast
   address can be forwarded unmodified to the crossover router.

   In the case of RBU re-sending, the key distribution principle of
   delegation to the edge routers is used.  This enables two different
   modes of key propagation where a session key is acquired either from
   the previous access router or from the AAAL. Session keys are not
   propagated deeper into the visited domain so the state space for
   a large number of mobile nodes is smaller than in the full trust
   delegation mode.  Also, network topology is not revealed in this
   case since the binding acknowledgements seem to come from the edge
   routers.

   In the full trust delegation mode we use the anycast-based unmodified
   RBU forwarding.  This provides direct mobile node authentication in
   the crossover with a fast forwarding of the unmodified RBU. It also
   results in propagating the key material, either in-line with the key
   material destination option, or by asking the key from the AAAL in
   each router.  This can be considered inefficient in a large visited




Malinen, Le, Perkins          Expires 2 November 2001          [Page 26]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


   domain.  Since the mobile node in this case directly gets replies
   from crossover routers, the visited domain topology is revealed.


















































Malinen, Le, Perkins          Expires 2 November 2001          [Page 27]


Internet Draft      Mobile IPv6 Regional Registrations      2 March 2001


Addresses

   The working group can be contacted via the current chairs:

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


   Questions about this memo can also be directed to the authors:

        Jari T. Malinen                  Charles E. Perkins
        Communications Systems Lab       Communications Systems Lab
        Nokia Research Center            Nokia Research Center
        313 Fairchild Drive              313 Fairchild Drive
        Mountain View, California 94043  Mountain View, California 94043
        USA                              USA
        Phone:  +1-650 625-2355          Phone:  +1-650 625-2986
        E-mail:  jmalinen@iprg.nokia.com E-mail:  charliep@iprg.nokia.com
        Fax:  +1 650 625-2502            Fax:  +1 650 625-2502


























Malinen, Le, Perkins          Expires 2 November 2001          [Page 28]