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

Versions: 00                                                            
Internet Engineering Task Force                              M. C. Chuah
INTERNET DRAFT                                       Lucent Technologies
                                                                   Y. Li
                                                      Bay Networks, Inc.
                                                         30 October 1997



             Distributed Registration Extension to Mobile IP
                  draft-chuahli-mobileip-dremip-00.txt


Status of This Memo

   This document is a submission to the Mobile-IP Working Group of the
   Internet Engineering Task Force (IETF). Comments should be submitted
   to the mobile-ip@smallworks.com mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   This document proposes an extension to the Mobile IP base protocol.
   The features in this extension allow us to (i) reduce frequent
   distant registrations at the mobility agents, (ii) be more scalable
   by a separation of registration and forwarding services, (iii) ease
   the key management problem among mobility agents, and (iv) be
   interoperable with other mobility agents/mobile nodes running
   standard Mobile-IP specified in RFC2002.




Expires  April 1998                                             [Page i]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997

                        Contents


Abstract ............................................................  i

1. Introduction .....................................................  1
    1.1. Architectural Entities .....................................  2
    1.3. Terminology ................................................  2
    1.3. Design Goals ...............................................  4
    1.3.1 Reduce Distant Registration Frequency .....................  4
    1.3.2 Ease of Key Management ....................................  5
    1.3.3 Increase Scalability ......................................  5

2. Protocol Overview ................................................  6
    2.1. Agent Discovery ............................................  6
    2.2. Local Registration .........................................  6
    2.3. Home Registration ..........................................  7
    2.4. Transit Registration .......................................  7
    2.5. Datagram Routing ...........................................  8
    2.6. Local/Home Service..........................................  8
    2.7. Foreign Server Smooth Handoffs .............................  9
    2.8. Optimizing Registrations ...................................  9
    2.9. Interoperability with the Base Protocol .................... 10

3. Message Formats .................................................. 11
    3.1. Agent Advertisement ........................................ 11
    3.2. Registration Request ....................................... 11
    3.3. Registration Reply ......................................... 12
    3.4. Route Request .............................................. 12
    3.5. Route Reply ................................................ 13

4. Newly Defined Extensions ......................................... 14
    4.1. Registration Server Extension .............................. 14
    4.2. Care-of Address Extension .................................. 14
    4.3. Agent-Server Authentication Extension ...................... 16
    4.4. Mobile-Server Authentication Extension ..................... 16
    4.5. Server-Server Authentication Extension ..................... 17

5. Care-of Agent Considerations ..................................... 17
    5.1. Receiving Route Request .................................... 17
    5.2. Binding Route Enable/Disable................................ 18

6. Registration Server Considerations ............................... 18
    6.1. Data Structure ............................................. 19
    6.2. Receiving Registration Request as a Binding Registrar ...... 19
    6.3. Receiving Registration Request as a Binding Relay .......... 20
    6.4. Sending Route Request ...................................... 21
    6.5. Receiving Route Reply ...................................... 21
    6.6. Load Balancing ............................................. 22


Expires  April 1998                                            [Page ii]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997
7. Mobility Agent Considerations .................................... 22
    7.1. Sending Agent Advertisement ................................ 22
    7.2. Receiving Registration Request as a Foreign Agent .......... 22
    7.3. Receiving Registration Request as a Home Agent ............. 22
    7.4. Receiving Registration Reply ............................... 22
    7.5. Receiving Route Request .................................... 22

8. Mobile Node Considerations ....................................... 23
    8.1. Receiving Agent Advertisement .............................. 23
    8.2. Sending Registration Request ............................... 23
    8.3. Receiving REgistration Reply ............................... 24
    8.4. Handoff .................................................... 24

Appendix A Registration Server Discovery Procedure .................. 25
Appendix B Care-of Agent Discovery Procedure ........................ 25
Appendix C Key Distribution Between Registration Servers ............ 25
Appendix D Example Scenarios ........................................ 26
Appendix D.1 Local/Home Registrations ............................... 26
Appendix D.2 Transit/Home Registrations ............................. 27
Appendix D.3 Optimizing Registrations ............................... 31
Appendix D.4 Interoperability with RFC2002 .......................... 32

Reference ........................................................... 33

Acknowledgement ..................................................... 34

Authors's Address ................................................... 34

































Expires  April 1998                                           [Page iii]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997




1. Introduction

   Mobile IP base protocol [1] provides an efficient, scalable mechanism
   for node mobility within the Internet. However, the key management
   between the home and foreign agents, and between the foreign agents
   and the mobile node is still a problem.

   Secondly, as Perkins [2] addresses in the hierarchical foreign agents
   model, each time the mobile node moves, a Registration Request
   message has to be approved by the mobile node's Home Agent. In cases
   where the home agent is far away, it may become too expensive or even
   impossible to complete these frequent registrations. This document
   proposes an extension to the Mobile IP base protocol to solve these
   problems.

   In this internet draft, we introduce some extensions to the base
   protocol to provide a more scalable solution to the mobility
   management problem. Our proposed extension separates the the
   registration and forwarding services. The registration service can
   be provided additionally by a network entity called registration
   server while the forwarding service can be provided by a network
   entity called care-of agents. The introduction of registration
   servers allow us to reduce the number of trusted entities in the
   network and hence enable us to ease the key management problem. It
   also allows us to do authentications such that illegal use of routing
   services. The introduction of care-of agents allow us to do
   load-balancing according to the dynamically changing traffic needs.
   In addition, we define 3 types of registrations, namely local, home
   and transit registrations. By having these different types of
   registrations, we are able to reduce the frequency of distant
   registrations. Our new features are introduced in such a way that the
   mobile nodes and mobility agents supporting our new features can
   still interoperate with mobile nodes and mobility agents supporting
   the base protocol specified in RFC2002.


Expires  April 1998                                             [Page 1]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997
1.1. Architectural Entities

   The memo introduces the following new architectural entities:

      Registration Server (RS)

         An entity providing registration service within a routing
         domain. A registration server in the mobile node's home routing
         domain is called a Home Registration Server. A registration
         server in the routing domain that the mobile node is visiting
         is called a Local Registration Server. Otherwise, it is called
         a Transit Registration Server.

      Care-of Agent (COA)

         An entity providing forwarding service and hence care-of
         addresses. In the base protocol, a care-of agent is the foreign
         agent itself. However, we propose here to separate it from the
         foreign agent.

1.2. Terminology

     Care-of Address

         The care-of address is redefined, in this memo, as an IP
         address from which datagrams can be relayed to the mobile
         node, whether or not through one or more intermediate nodes.

     Mobility Binding

         The mobility binding is redefined the same as in the base
         protocol except that the care-of address takes the above
         definition.

     Registration

         The registration is redefined as a procedure for mobile node to
         register a mobility binding with a registration server or a
         home agent and to obtain a care-of address closer to the home
         agent, by exchange of Registration Request and Registration
         Reply messages. In the base protocol, this is a registration
         with a home agent.

         The care-of address submitted in the Registration Request is
         called the CHILD care-of address of the registration. The one
         obtained by this registration is called the PARENT care-of
         address of the registration.

     Binding Registrar

         A registration server or home agent, with which the mobile node
         registers a mobility binding. In the base protocol, this is the
         home agent, with which a mobility binding is associated.

Expires  April 1998                                             [Page 2]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997

     Binding Relay

         A foreign agent or registration server, through which the
         Registration Reply for a mobility binding can be delivered to
         the mobile node. In the base protocol, this is the foreign
         agent.

         A mobile node is allowed to register a mobility binding with a
         binding registrar via a binding relay.

     Home/Local/Transit Registration

         A registration where the binding registrar is in the mobile
         node's home routing domain is called a home registration. A
         registration where the binding registrar is in the routing
         domain that is visited by the mobile node is called a local
         registration. Otherwise, the registration is called a transit
         registration.

     Complete Registration

         The combination of one or more registrations, which allows
         tunnels to be built such that there will be at least one
         forwarding path from the home agent to the visiting mobile
         node.

     Binding Route Enabled/Disabled

         A binding route is enabled by a care-of agent if, a datagram
         destined for the mobile node is relayed by this care-of agent
         from the parent care-of address of a registration to the child
         care-of address. In the base protocol, this means to build a
         tunnel from the home agent to the care-of address and to add a
         routing entry to the care-of address for the mobile node.

         A binding route is disabled by a care-of agent if, the care-of
         agent functions as a regular router disregarding the existence
         of a mobility binding if any. Thus, a datagram destined for the
         mobile node will be forwarded to the mobile node's home network
         or simply discarded with an ICMP message bounced if the
         datagram was tunneled to the care-of agent.

Expires  April 1998                                             [Page 3]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


1.3  Design Goals

   There are 5 major design goals for this protocol, namely,

      (i)   reduce frequent distant registrations,
      (ii)  ease key management,
      (iii  prevent illegal use of routing services,
      (iv) increase scalability,
      (iv)  interoperable with RFC2002.

   This protocol separates the the registration and forwarding services.
   The registration service is provided by the registration server while
   the forwarding service is provided by the care-of agents. Since each
   routing domain may only have one registration server and many care-of
   agents, the number of trusted entities in mobile networks are reduced
   and hence enable us to ease the key management problem. It also
   allows us to do authentications such that illegal use of routing
   services can be prevented.

1.3.1 Reduce Frequent Distant Registrations

   To reduce frequent distant registrations, we define 3 types of
   registrations, namely local, home and transit registrations. When the
   mobile node moves from one routing domain to another, it needs to
   perform a home registration with the home registration server (HRS)
   to inform the HRS of the identity of the local Registration Server it
   is currently registered.

   When the mobile node moves within the same routing domain, even
   though its point of attachment may change from one foreign agent to
   another, the mobile node only needs to perform local registrations.
   As long as the parent care-of address in the local Registration Reply
   message matches with the one obtained previously, the mobile node
   needs not perform any home registrations. That way, the number of
   distant registrations with HRS can be reduced.

   The transit registrations are used when the mobile node's home
   registration server does not have security association with the
   local registration server. The local server will give the mobile
   node the identity of a registration server which can act as a
   middleman for the home registration. The mobile node will first
   perform a transit registration with this transit registration
   server to get a parent care-of address. Using this allocated
   care-of address from the transit registration, the mobile node
   can then do a home registration via the transit registration
   server.


Expires  April 1998                                             [Page 4]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


   In our proposed registration extension MobileIP protocol, we
   assume that the home registration life time exceeds the transit
   registration life time which exceeds the local registration life
   time.

1.3.2 Ease of Key Management/Prevent Illegal Usage

   One of the design goals in this protocol is to prevent replay attacks
   in the mobile node's registration procedure, and to prevent an
   illegal mobile node from stealing services from a routing domain. The
   existing mobile IP base protocol does not require an existence of
   security associations between the mobile node and the foreign agent,
   and between the home agent and the foreign agent.

   If there are already such security associations, this protocol works
   exactly the same way as the base protocol. Otherwise, this protocol
   provides a means to compensate for a lack of such security
   associations. We assume that there are security associations between
   registration servers. Since the number of registration servers are
   much less than the number of mobility agents, we have a reduction in
   key management problem. This makes the our enhanced Mobile-IP model
   more scalable.

   If there is no security association between the mobile node and the
   foreign agent or no security association between the foreign agent
   and the home agent, the mobile node will not be allowed to register
   directly with its home agent, but to first register with a
   registration server in the local routing domain. This local server
   in turn allocates a parent care-of address and returns to the mobile
   node via the registration reply.

   If there is a security association between the foreign server and the
   mobile node's home agent, the mobile node can subsequently register
   the parent care-of address allocated by the foreign server with the
   home agent.

   Otherwise, the mobile node is advised  to register with its home
   registration server via the foreign server. This is feasible because
   there are security associations between the foreign server and the
   home server, and between the mobile node and the home server. Thus, a
   completely secured binding is established, which allows packets to be
   delivered to the mobile node.

1.3.3 Increase Scalability

   As mentioned above, the introduction of registration servers reduces
   the number of trusted entities and hence reduce the severity of key
   management problem. Hence, our enhanced Mobile-IP model is more
   scalable than the Base protocol. In addition, by separating the
   registration service with the forwarding services and introducing
   as many care-of agents as we need, we can perform some load-balancing
   to cater to the dynamically changing traffic needs.




Expires  April 1998                                             [Page 5]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


2. Protocol Overview

   A mobile node should have a complete registration when it moves away
   from its home network. A complete registration consists of local
   registrations, home registrations and/or transit registrations. A
   registration starts with receiving Agent Advertisements. Thus,
   changes for this protocol will apply to both the Agent Discovery and
   the Registration procedures.

2.1 Agent Discovery

   In the base protocol, the foreign agents advertise their presence via
   Agent Advertisement messages. The mobile node obtains a care-of
   address (which usually is the foreign agent's address) from the
   advertisements. The mobile node may initiate a registration using
   this care-of address.

   In this proposal, the care-of address obtained from the Agent
   Advertisement and used in a registration request is referred to
   as the child care-of address of this registration.

   In addition to the care-of addresses in the Agent Advertisement
   message, our proposal requires that the Agent Advertisement
   message includes a registration server extension so that
   prospective mobile nodes can choose a registration server for the
   local registration. The registration extension contains one or more
   registration server addresses. There is a priority value and a
   lifetime associated with each registration server's address.

2.2 Local Registrations

   When the mobile node detects a change in the point of attachment, it
   performs a local registration with the local registration server via
   a foreign agent. The mobile node sends a Registration Request
   message to the local server. The local server replies with a
   Registration Reply message. This message contains a parent
   care-of address which usually is the IP address of a care-of
   agent that has been assigned to provide forwarding service for
   the visiting mobile node. One can consider this care-of agent as
   the local home agent in terms of forwarding. Note that if the local
   registration server happens to be the home agent or
   the Home Registration Server of the mobile node, then usually the
   care-of agent assigned will be the home agent of the mobile node.

   The local server may request the assigned care-of agent to enable the
   binding route via an exchange of Route Request and Route Reply
   messages with the care-of agent. Thereafter, packets from any node
   within the local routing domain may be able to reach the mobile node.
   This may additionally require changes to relevant intra-domain
   routing protocols, which is beyond the scope of this document.

   For any registration, we require that a care-of address, called the
   parent care-of address, be returned to the mobile node by
   means of the registration reply.


Expires  April 1998                                             [Page 6]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


2.3 Home Registrations

   If the parent care-of address obtained via local registration is not
   the same as the address of the mobile node's home agent, and the
   parent care-of address is also different from that obtained
   previously, then, the mobile node should perform home registrations.
   The mobile node builds a new mobility binding using this parent
   care-of address by registering this binding with its home
   registration server, via the local server. The mobile node does so
   via an exchange of Registration Request and Registration Reply
   message with the home server.

   In this home registration, the parent care-of address obtained
   through a previous local registration becomes the child care-of
   address. The care-of address returned from the home registration
   server is a new parent care-of address which usually is the address
   of the mobile node's home agent. In this manner, a complete
   registration is performed among the mobile node, the foreign agent,
   the local server, the home server and the home agent.

   The home server may request the home agent to enable the binding
   route, that is, to build a tunnel from the new parent care-of
   address (the home agent's address) to the child care-of address
   (a care-of agent's address at the visiting domain) via an exchange
   of Route Request and Route Reply messages.

2.4 Transit Registrations

   There are two scenarios where transit registrations may be used.
   Type 1 Transit Registrations are used when the mobile node moves
   from one routing domain to another and has a valid mobility binding
   with a previous foreign server. In this case, the mobile node may
   issue a transit registration request to that previous foreign
   server to enable a binding route from the previous parent care-of
   address to the current one.

   Such a mobility binding is transitional and helps to ensure that data
   that has been delivered to the previous parent care-of address can be
   forwarded to the new parent care-of address. This transitional
   binding can be removed once the mobile node has completed its
   registration of the new parent care-of address with the home
   registration server.

   Type 2 Transit Registrations are used when a foreign server in the
   visiting domain has no security association with the home server. In
   this case, the mobile node may register, via the local server, the
   local parent care-of address with a transit registration server,
   which in turn allocates a new parent care-of address to the mobile
   node. The mobile node then registers, via the transit server, this
   new parent care-of address with the home server. It is expected
   that the mobile node has security association with the transit
   registration server.



Expires  April 1998                                             [Page 7]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


2.5 Datagram Routing

   Through a series of local, transit and home registrations, the mobile
   node obtains a path from the home agent to the foreign agent. The
   path consists of a sequence of tunnels with the starting point of the
   first tunnel being the home agent, and the termination point of the
   last tunnel being the foreign agent, and each of the tunnels begins
   with a parent care-of address and ends with a child care-of address.

   Datagrams sent to the mobile node's home address are intercepted
   by its home agent, tunnelled from one care-of agent to another until
   they reach the foreign agent, and finally being delivered to the
   mobile node by the foreign agent.

   These tunnels fall into three categories: home tunnels, transit
   tunnels, and local tunnels. A home tunnel begins with a home agent or
   a care-of agent allocated by a home registration server, and ends
   with a care-of agent allocated by another registration server. A
   transit tunnel begins with a care-of agent allocated by a transit
   registration server and ends with a care-of agent allocated by the
   current visiting registration server. A local tunnel begins with a
   care-of agent allocated by the current visiting registration server
   and ends at the foreign agent. Each of these tunnels is authorised by
   two registration servers or by a registration server and a mobility
   agent.

   In the reverse direction, datagrams sent by the mobile node are
   generally delivered to their destination using standard IP routing
   mechanisms, not necessarily passing through the care-of agents, the
   home or foreign agent.


2.6 Local/Home Service

    In some cases, the mobile node may just be interested in
    communicating with the hosts in its visiting domain but not
    interested in having home traffic forwarded to its visiting
    location. For such scenarios, if the visiting network has
    pre-arrangement with the mobile node's home registration server
    to provide local services to mobile nodes that belong to that
    home registration server, then the mobile node only needs to
    perform local registration.



Expires  April 1998                                             [Page 8]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997



2.7 Foreign Server Smooth Handoffs

    When a mobile node moves and discovers that the local
    registration server does not change, then it only needs to
    perform a local registration.

    When a mobile node moves and discovers that the local
    registration server has changed, then it not only performs
    a local registration, it also performs a home registration.
    As in the route optimization draft [6], a Previous Foreign Server
    Notification option can be implemented so that the new foreign
    server can notify the old foreign server about the mobile node's
    new mobility binding. This notification can be used by the
    previous server to tear down existing tunnels. Such notification
    also allows any datagrams that have been delivered to the
    previous care-of agent to be delivered to the new care-of agent.

    If the new foreign registration server does not have a security
    association with the home registration server, then all 3 types
    of registrations, namely local, transit and home registrations
    have to be performed.


2.8 Optimizing Registrations

   In earlier sections, we describe how DREMIP supports local,
   transit and home registrations. In this section, we elaborate
   a bit on how a mobile node can combine both the local and home
   registrations within one Registration Request message.

   A mobile node who wishes to make a local and home registrations
   can send a Registration Request message with a registration
   server extension. The binding registrar in the Registration
   Request message will be the local server and a MN/Local Server
   authentication extension can be appended. The Home Registration
   Server identity is contained in the Registration
   Server Extension. The Mobile Node can also attach the MN/Home
   Server Extension at the back of the Registration Server
   Extension.

   We refer the readers to Appendix D.3 for more details on such
   registration optimizations.

   In addition, it is a requirement in DREMIP that the following
   inequality holds for local, home and transit registration
   lifetimes:

   Local Registration LifeTimes <= Transit Registration LifeTimes
     <= Home Registration LifeTimes

   Note also that the lifetimes of the different tunnels: local,
   transit and home tunnels can be set according to the local,
   transit and home registration lifetimes respsectively. If
   the Previous Foreign Agent Notification feature is implemented,
   then the tunnel lifetimes can be set to infinity and the
   deregistration message can be used to tear down the tunnel.



Expires  April 1998                                             [Page 9]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


2.9 Interoperability with the Base Protocol

   To make the this protocol compatible with the base protocol, a few
   requirements apply to the mobile node, foreign agent and home agent.

   Upon receipt of an Agent Advertisement message without registration
   server extension, the mobile node should be able to register with a
   home agent via the foreign agent as in the base protocol. In this
   case, the mobile node should not check for the presence of any
   care-of address extension in the Registration Reply.
   In addition, the Registration Request should be sent as a Home
   Registration Request. The binding registrar address field should be
   the home registration server address or the home agent address. If
   there is no security association between the mobile node and the home
   agent, but there exists one between the mobile node and the home
   server, then the Registration Request should be directed to the home
   server.

   A home or foreign agent should check the R-bit in the Registration
   Request message to determine whether the mobile node is supported by
   this protocol. A foreign agent, upon receipt of a Registration
   Request with R-Bit cleared, should not require that there be a
   mobile-foreign authentication extension in the request and a
   foreign-home authentication extension in the further reply message.

   In Appendix D.4, we give two example scenarios and explain in
   greater details how a mobile node without DREMIP feature can use
   the Mobile-IP service in a DREMIP network and how a mobile node
   with DREMIP feature can use the Mobile-IP service in a
   RFC2002-compliant foreign network.


Expires  April 1998                                            [Page 10]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


3. Message Formats

3.1 Agent Advertisement

   The Agent Advertisement messages additionally include a registration
   server extension, which contains one or more registration server
   addresses. Thus, the mobile node can be informed of the registration
   server addresses and register its mobility binding with one of them.

3.2. Registration Request

   One bit is added to the Registration Request message to indicate the
   registration is supported by this distributed registration extension
   protocol. The IP and UDP fields of the Registration Request message
   is the same as described in RFC2002. The UDP header is followed by
   the Mobile IP fields shown below:

    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|V|R|r|          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Binding Registrar                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

   distributed Registration extension (R):

      The R-bit is set by a mobile node or a binding registrar to
      indicate that the procedure is supported by this registration
      extension protocol. This bit is for the purpose of
      interoperability with the base protocol.

   Reserved (r):

      The r-bit should be set to 0.

   Binding Registrar:

      A home agent or a registration server.


Expires  April 1998                                            [Page 11]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997

3.3. Registration Reply

   There is no change in the format of the Registration Reply message
   except that, the "Home Agent" field is renamed to "Binding Registrar"
   field.

   In addition to a few authentication extensions, the Registration
   Reply MUST include a care-of address extension so that a
   registration server can allocate a parent care-of address to the
   mobile node. The Registration Reply MAY additionally appends a
   registration server extension to advise the mobile node to choose a
   registration server address as the next binding registrar.

3.4. Route Request Message

   Route Request is sent by a registration server to a care-of
   agent to enable a binding route between the care-of agent and a
   child care-of address of a registration.

   IP fields:

      Source Address        Typically the interface address from which
                            the message is sent.

      Destination Address   Typically the IP address of the care-of
                            agent.

   UDP fields:

      Source Port           <variable>

      Destination Port      434

   The UDP header is followed by the fields shown below:

    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      |   Reserved    |          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Destination Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Next Hop Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type     32 (Route Request)

      Reserved sent as zero; ignored on reception.

      Lifetime
               The number of seconds remaining before the route is
               considered expired.  A value of zero indicates a request
               for disabling.  A value of 0xffff indicates infinity.

      Destination Address
               The home address of the mobile node.

      Next Hop Address
             The child care-of address of a registration

      Identification
              A 64-bit number, constructed by the server, used for
              matching Route Requests with Route Replies, and for
              protecting against replay attacks of these messages.

      Extensions
               The fixed portion of the Route Request is followed
               by one or more of the Extensions.


Expires  April 1998                                            [Page 12]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997



3.5. Route Reply Message

   The care-of agent returns a Route Reply message to the server which
   has sent a Route Request (Section 3.4) message. The Reply message
   contains the necessary codes to inform the server about the status
   of its request, along with the lifetime granted by the care-of
   agent, which MAY be smaller than the original Request.

   IP fields:

      Source Address        Typically copied from the destination
                            address of the Route Request to which
                            the care-of agent is replying.

      Destination Address   Copied from the source address of the
                            Route Request to which the care-of agent
                            is replying

   UDP fields:

      Source Port           <variable>

      Destination Port      Copied from the source port of the
                            corresponding Route Request

   The UDP header is followed by the fields shown below:

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Destination Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Next Hop Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type     33 (Route Reply)

      Code     A value indicating the result of the Route Request.
               See below for a list of currently defined Code values.

      Lifetime
               If the Code field indicates that the care-of agent agrees
               to add the route capability, the Lifetime field is set to
               the number of seconds remaining before the route is
               considered expired.  A value of zero indicates that the
               route has been disabled.  A value of 0xffff indicates
               infinity.

               If the Code field indicates that the route was denied,
               the contents of the Lifetime field are unspecified and
               MUST be ignored on reception.



Expires  April 1998                                            [Page 13]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997



      Destination Address
               The home address of the mobile node.

      Next Hop Address
               The child care-of address of a registration

      Identification
               A 64-bit number used for matching Route Requests with
               Route Replies, and for protecting against replay attacks
               of tunnel messages.  The value is based on the
               Identification field from the Route Request message from
               the client.

      Extensions
               The fixed portion of the Route Reply is followed by one
               or more of the Extensions.

   The following values are defined for use within the Code field.

        0 route added

       64 reason unspecified
       65 administratively prohibited
       67 server failed authentication
       68 requested Lifetime too long
       69 poorly formed message

   Up-to-date values of the Code field are specified in the most recent
   "Assigned Numbers" [5].




Expires  April 1998                                            [Page 14]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997



4. Newly Defined Extensions

4.1. Registration Server Extension

   This extension is placed in the Agent Advertisement message or
   Registration Reply message, and is used to provide the mobile node
   with addresses of a collection of available registration servers.
   Note that we have included a priority level for different
   registration servers. One can use this priority level to provide
   hierarchical registrations or as an congestion-level indicator to
   prevent mobile nodes from registering with an overloaded
   registration server.

    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     |       Lifetime                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Registration Server Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Priority                     |       Lifetime                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Registration Server Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Priority                     |       Lifetime                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           .                                   |
   |                           .                                   |
   |                           .                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     81

      Length   2 + 8 * number of registration server addresses

      Lifetime
               The number of seconds remaining before the registration
               server is considered invalid. A value of zero indicates
               the registration server doesn't provide service to more
               mobile nodes.  A value of 0xffff indicates infinity.

      Priority
               The level of authorization.

4.2. Care-of Address Extension

   This extension is placed in the Registration Reply so that a
   registration server can allocate a care-of address to the mobile
   node.

    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     | Reserved                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       care-of address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     82

      Length   6

      Reserved 0

      care-of address
               parent care-of address or home agent address


Expires  April 1998                                            [Page 15]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


4.3. Agent-Server Authentication Extension

   This extension is included in the Registration Request and
   Registration Reply messages between the foreign agent and the foreign
   registration server, and between the home agent and the home
   registration server. The protcol here requires that there exists a
   security association between an agent and a registration server in
   the same routing domain.

   The extension MUST also be included in the Route Request and Route
   Reply messages between a registration server and a care-of agent.

    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    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ... SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     83

      Length   4 plus the number of bytes in the Authenticator.

      SPI      Security Parameter Index (4 bytes).  An opaque identifier

      Authenticator
               (variable length)

4.4. Mobile-Server Authentication Extension

   This extension is included in the Registration Request and
   Registration Reply messages between the mobile node and the foreign
   registration server, and between the mobile node and the home
   registration server. The protocol here requires that there exists a
   security association between a mobile node and a registration server
   whether they are in the same routing domain or not.

    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    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ... SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     84

      Length   4 plus the number of bytes in the Authenticator.

      SPI      Security Parameter Index (4 bytes).  An opaque identifier

      Authenticator
               (variable length)



Expires  April 1998                                            [Page 16]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997

4.5. Server-Server Authentication Extension

   This extension is included in the Registration Request and
   Registration Reply messages between two registration servers,
   especially between the foreign registration server and the home
   registration server. The protocol here requires that there exists a
   security association between two registration servers whether they
   are in the same routing domain or not.

    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    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ... SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type 85

    Length 4 plus the number of bytes in the Authenticator

    SPI Security Parameter Index (4 bytes). An opaque identifier

    Authenticator
             (variable length)


5. Care-of Agent Considerations

   The care-of agent could be an OSPF area border router, an autonomous
   system border router or a backbone router. In the base Mobile-IP
   protocol, the care-of address was originally associated with a
   foreign agent and a foreign agent has the responsibility of
   forwarding the traffic destined to the mobile node. In this
   registration extension protocol, the care-of agent is designed to
   forward traffic destined to the mobile node.

5.1. Receiving Route Request

   Upon receipt of a Route Request, the care-of agent MUST check the
   validity of the message. The request is valid if

   - the UDP checksum is valid; AND

   - the message MUST include an Agent-Server Authentication extension at
     the end and the Authenticator is valid.

   An invalid request SHOULD be discarded and an error SHOULD be logged.

   On receipt of a valid Route Request message, the care-of agent SHOULD
   respond with a Route Reply with the lower 32-bit identification
   copied from the original request.

   If the care-of agent is not able to honor the request, it SHOULD put
   a proper code in the reply.



Expires  April 1998                                            [Page 17]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997



   If the care-of agent denies the request and disable the binding route
   to the child care-of address, it SHOULD set the code to a positive
   value (0) and the lifetime to 0.

   Otherwise, if the care-of agent agrees to enable a binding route to
   the child care-of address, it SHOULD set the code to a positive value
   (0) and the lifetime to a value not greater than that in the original
   Request. The binding route is valid within the granted lifetime and
   SHOULD be disabled upon its expiry.

5.2. Binding Route Enable/Disable

   In general, a care-of agent MAY enable or disable a binding route
   using tunneling mechanism ([4]). Within a routing domain, however,
   the care-of agent MAY take advantage of underlying routing protocols
   instead. This approach may be discussed elsewhere. In this document,
   we assume a care-of agent uses the tunneling mechanism.

   To enable a binding route, the care-of agent MAY first build a tunnel
   to the next hop address specified in the Route Request message if
   such a tunnel does not exist previously. The care-of agent then
   installs in its forwarding cache an entry with the tunnel as the
   outgoing circuit. To disable the registration delivery, the care-of
   agent can simply remove the entry from its forwarding cache. If there
   is no entry associated with the tunnel, the care-of agent SHOULD
   additionally remove this tunnel.

6. Registration Server Considerations

   A registration server MAY not be a router. It is designed to be
   independent of the forwarding path for mobile traffic, and to monitor
   and switch the forwarding path. A registration server performs local
   registrations at most times but less frequently does home and transit
   registrations.

   The local registration is used to establish the local mobility
   binding of a mobile node, that is, the association of the mobile node
   with a local registration server, a foreign agent, and the lifetime
   of this association. The local mobility binding MAY create the mobile
   node's connectivity to the local routing domain.

   The local registration server, taking the advantage of the above
   local mobility binding, then establishes a home mobility binding,
   that is, the association of the mobile node with the home agent or
   the home registration server of the mobile node, the local
   registration server, and the lifetime of the association.

   The registration server MAY be configured with one or more care-of
   agent addresses, which are allocated to mobile nodes such that
   traffic load can be balanced.



Expires  April 1998                                            [Page 18]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


6.1. Data Structure

   For each registration server and each visiting mobile node, there are
   generally two registrations: one where the registration server acts
   as the binding registrar and the other where the registration server
   acts as a binding relay. Each registration creates an entry in the
   registration server cache. Since the mobile node may perform mutiple
   registrations (home and/or transit) based on an existing local
   registration, a registration server SHOULD NOT merge the two entries
   into one. The entry created by a local registration where the
   registration server is the binding registrar consists of

     - mobile node's home address
     - child care-of address and
     - parent care-of address
     - lifetime, and
     - the forwarding status over the tunnel between parent and child
       care-of address.

   Each entry created by the home or transit registration where the
   registration server is the binding relay should have a pointer to the
   above entry, and additionally includes

     - binding registrar, and - lifetime

6.2. Receiving Registration Request as a Binding Registrar

   Upon receiving a valid registration request where the registration
   server is the binding registrar, the server should check if the
   mobile node is previously associated with any care-of agent. If it is
   not, the server should choose a parent care-of address. The server
   SHOULD exchange a pair of Route Request and Route Reply with the
   relevant care-of agent in order for the care-of agent to enable a
   binding route for the lifetime requested by the mobile node. The
   server SHOULD NOT return Registration Request to the mobile node
   until it receives a Route Reply from the care-of agent.

   After the server receives a positive Route Reply from the care-of
   agent, the server will verify that the tunnel lifetime is
   consistent with the registration life time. Then, the server SHOULD
   send a positive Registration Reply to the mobile node if there is a
   security association between itself and the mobile node. The server
   SHOULD deny this request by sending a negative Registration Reply to
   the mobile node. In this case, the server SHOULD additionally ask
   the care-of agent to disable the binding
   route by exchange of negative Route Request and Route Reply.


   For this case, if the registration server previously does not have
   a mobility binding yet with the mobile node, it SHOULD allocate a
   parent care-of address, put it in a care-of address extension, and
   append the extension to the Registration Reply. However, if the
   registration server has a binding with the mobile node previously,
   the old care-of address SHOULD be put in that extension. This
   ensures that the mobile node can obtain the same parent care-of
   address if repeatedly registering with the registration server.



Expires  April 1998                                            [Page 19]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


   The registration server MAY include a registration server extension
   in the Registration Reply message for the mobile node to perform
   further transit/home registrations.

   The registration server SHOULD include an agent-server or server-
   server authentication extension in the reply if the binding relay
   is the foreign agent or another registration server, respectively.

   If there is no tunnel currently between the parent and child care-of
   address, the registration server SHOULD direct the care-of agent, by
   issuing a Route Request message, to build a tunnel from the parent
   care-of address to the child care-of address of the mobile node. The
   child care-of address is specified in the Registration Request while
   the parent care-of address is allocated by the binding registrar.

   If the registration server is a home server, the parent care-of
   address it allocates MAY be the home agent address. In this case,
   the care-of agent is the home agent.

6.3. Receiving Registration Request as a Binding Relay

   Upon receiving a valid registration request where the registration
   server is the binding relay, the registration server MUST verify
   that there is already an entry for this mobile node where it acts as
   a binding registrar. If not, the Registration Request MUST deny this
   request. The registration server SHOULD also verify that there is a
   security association between itself and the binding registrar. If
   not, the server SHOULD deny this request. The binding lifetime SHOULD


   not be greater than the one with the current mobility binding where
   the registration server acts as a binding registrar.  Otherwise, the
   server SHOULD deny this request.

   If the Registration Request message meets all the requirements above,
   the registration server MAY relay this request to the binding
   registrar in the same way as the foreign agent deals with the
   Registration Request in the base protocol.

   The registration server MAY deny the request and include a
   registration server extension for the mobile node to perform
   a transit registration with another server. The mobile node
   can then perform further home registration via this transit
   server.

   The registration server SHOULD include a server-server authentication

   extension in the request to be relayed, or a mobile-server
   authentication extension in the reply if the server denies the
   request above.



Expires  April 1998                                            [Page 20]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997




6.4. Sending Route Request

   To ensure the care-of agent can forward traffic to the mobile node,
   the server SHOULD send a Route Request to the care-of agent. The
   server SHOULD copy lifetime from the Registration Request to the
   Route Request.

   The server SHOULD retransmit Route Request if it has not received a
   matched Route Reply in a reasonable time. Failure in receipt of such
   a Route Reply message after a maximum of retransmissions SHOULD be
   logged for further administrative option. The server MAY choose
   another care-of agent and repeat the procedure above until no
   care-of agent is available. In this case, the server SHOULD send a
   negative Registration Reply to the mobile node.

   The server MUST append an Agent-Server Authentication extension to
   the Route Request message. The SOMIP model requires that there be a
   security association between the server and the care-of agent.

6.5. Receiving Route Reply

   Upon receipt of a Route Reply, the server MUST check the validity of
   the message. The reply is valid if

   - the UDP checksum is valid;

   - the low-order 32 bits of the Identification field in the Route
     Reply equals to the low-order 32 bits of the Identification field
     in the most recent Route Request sent to the care-of agent; AND

   - the reply MUST include a Agent-Server Authentication extension.


   If the code field is negative or the lifetime is zero, the server
   MUST send a Registration Reply message with a negative code or
   lifetime set to 0.

   Otherwise, the server must check for consistency between the
   tunnel life time and the registration lifetime. If no previous
   agent notification feature is implemented, then the tunnel life
   time should not exceed the remaining registration life time.
   Otherwise, it may be allowed to exceed to reduce the bandwidth
   overhead required in refreshing tunnel lifetimes.



Expires  April 1998                                            [Page 21]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997



6.6. Load Balancing

   Each registration server occasionally probes their care-of agents on
   the traffic load that each of them is supporting. The care-of agents
   each return a metric that has a higher value when the traffic load is

   higher. Based on such replies, the server can order the list of
   care-of addresses with the least loaded one being at the top of the
   list. When the server receives a local registration request, it
   assigns the least loaded care-of address to that request.


7. Mobility Agent Considerations

7.1  Sending Agent Advertisement

   A mobility agent SHOULD include a registration server extension in
   the Agent Advertisements. This can facilitate the mobile node in
   finding a registration server with whom it has security association
   for subsequent registrations.

7.2. Receiving Registration Request As a Foreign Agent

   Upon receiving a Registration Request, a foreign agent SHOULD verify
   that there is a security association between itself and the binding
   registrar. If there is, the agent works exactly the same as the
   foreign agent in the base protocol.

   Otherwise, the agent SHOULD deny the Registration Request. The agent
   MAY include a registration server extension in the Registration Reply

   message for the mobile node to choose another binding registrar and
   to perform further registrations.

7.3. Receiving Registration Request as a Home Agent

   The home agent deals with a received Registration Request in the same

   way as the home agent in the base protocol.

7.4. Receiving Registration Reply

   The mobility agent deals with a received Registration Reply in the
   same way as in the base protocol.

7.5. Receiving Route Request

   The foreign agent SHOULD disregard this message.


   The home agent SHOULD deal with the Route Request in the same way as
   the care-of agent. The home agent SHOULD additionally send proxy ARP
   and gratuitous ARP on the home network. The procedure SHOULD be the
   same as in the base protocol.


Expires  April 1998                                            [Page 22]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997




8. Mobile Node Considerations

8.1. Receiving Agent Advertisement

   When a mobile node receives an agent advertisement, it SHOULD check
   to see if the mobility agent is its home agent. If it is, it does
   nothing since it is at home. Otherwise, it checks to see if there is
   a registration server extension in the agent advertisement. If yes,
   the mobile node SHOULD choose one of the registration servers whose
   addresses appear in the registration server extension and perform a
   local registration with the selected server. Note that if the
   mobile node is in its home domain i.e. the home registration
   server appears in the registration server extension, then the
   mobile node SHOULD choose its home registration server.

8.2 Sending Registration Request

   The mobile node SHOULD choose a proper binding relay and a binding
   registrar from previously received Agent Advertisement messages.
   For local registrations, the binding relay is the foreign agent, and
   the binding registrar is one of the local registration servers whose
   addresses appear in the registration server extension. Note that
   if the mobile node is in its home domain, then the binding
   registrar that the mobile node chooses SHOULD be its home
   registration server.

   For the case where the mobile node is visiting a foreign network,
   the mobile node will use the local registration
   server as the binding relay and the home registration server as
   the binding registrar in the mobile node's home registration
   request.

   For transit registrations, the binding registrar is a registration
   server with whom the mobile node has previously established a
   mobility binding or with whom the mobile node has a security
   association, while the binding relay could be a foreign agent or
   another registration server.

   If the mobile node previously receives a negative Registration Reply,
   which includes a registration server extension, it SHOULD choose a
   proper binding registrar to proceed further registration.

   The mobile node SHOULD include a mobile-server authentication
   extension in the request if the binding relay is a registration
   server.



Expires  April 1998                                            [Page 23]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


8.3 Receiving Registration Reply

   Upon receiving a valid local registration reply, the mobile node
   SHOULD check to see if the binding registrar or the parent care-of
   address returned in the reply is its home agent. If yes, this is a
   complete registration. If it is not, however, the mobile node SHOULD
   check to see if it has previously established a mobility binding with
   its home registration server or home agent, using this parent care-of
   address.

   If it has, nothing needs to be done since the mobile node just
   changes its point of attachment locally. Otherwise, the mobile node
   SHOULD perform a home registration using this parent care-of address.
   In this second registration, the local server will be used as the
   binding relay and the binding registrar will be set to the home
   registration server's address. The mobile node SHOULD make sure
   that the home registration life time exceeds the local
   registration life time.

   If the reply includes a registration server extension, it means the
   the binding registrar advises the mobile node to perform further
   registration with one of the registration servers in the extension.
   In this case, the mobile node SHOULD choose one of them and proceed
   with a registration with the local server set to the binding relay,
   and the selected registration server set to the binding registrar.
   Again, the mobile node SHOULD make sure that the transit
   registration life time exceeds the local registration lifetime.
   Later, if the mobile node needs to perform home registration, the
   mobile node SHOULD make sure that the home registration lifetime
   exceeds the transit registration lifetime.

8.4. Handoff

   When a mobile node moves from one foreign routing domain to another,
   the mobile node performs a local registration with the new local
   server. Then, it can first do a transit registration with its
   previous foreign registration server such that a tunnel can be built
   from the previous foreign server's care-of address to the new local
   server's care-of address.  This tunnel is a transitional tunnel that
   enables the forwarding of packets that have been sent to the previous

   foreign server but have not been delivered to the mobile node. Later,

   it performs a home registration with its home registration server
   using the new local server's care of address. After establishing a
   complete binding with the home registration server, the transitional
   tunnel can be torn down.



Expires  April 1998                                            [Page 24]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997



Appendix A Registration Server Discovery Procedures

Here, we describe a procedure for mobility agents to discover the
registration servers. We assume that a multicast address has been
assigned to all registration servers. A mobility agent merely needs
to send a Neighbor Request message to the multicast address of the
registration servers. All registration servers that can hear this
Neighbor Request message will respond with a unicast Neighbor Reply
message. The Neighbor Reply message contains a priority level
field. The mobility agent then puts the addresses of all
registration servers and their associated priority levels in the
Agent Advertisement messages that it broadcasts.
The Neighbor Request message can be repeated periodically with
a period long enough to limit the overhead bandwidth consumption.
Details of this registration server discovery procedure will be
provided in another upcoming internet draft.

Appendix B Care-of Agent Discovery Procedures

In practice, we may just manually configure care-of agents.
However, when there are a lot of care-of agents available and
more than one registration servers exist, we may want a more dynamic
assignment of care-of agents to registration servers.
Here, we describe a procedure for registration servers to discover
the presence of care-of agents in its vicinity. Again, we assume
that a multicast address is defined for registration server and
all care-of agents in a routing domain. The registration server
can send a Care-of Agent Solicit message to that multicast
address. All care-of agents that can hear this Care-of Agent
Solicit message will have to respond to the Registration Server
with a unicast Care-of Agent Advertisement message.

Appendix C Key Distribution between Registration Servers

We assume that all cooperating registration servers share a public
key and has a private key. We can use the same approach discussed in
[6].



Expires  April 1998                                            [Page 25]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


Appendix D Example Scenarios

This section shows example Registration Requests for several common
scenarios.

D.1  Local/Home Registrations
D.1.1 Local Registration
The mobile node receives an Agent Advertisement from a foreign agent
which has a registration server extension showing RS2 as the local
registration server. Assume that the mobile node has a security
association with RS2. The mobile node wishes to register with that
agent using the advertised foreign agent care-of address. The mobile
node wishes only IP-in-IP encapsulation, does not want broadcasts,
does not want simultaneous mobility bindings:

   IP fields:
     Source Address = mobile node's home address
     Destination Address = copied from IP source address of the
       Agent Advertisement
     Time to Live = 1 (?)
   UDP fields:
      Source Port = <any>
      Destination Port = 434
   Registration Request fields:
      Type = 1
      S=0, B=0, D=0, M=0,G=0, R=1
      Lifetime= the Registration Lifetime copied from the Mobility
        Agent Advertisement Extension of the Router Advertisement
        message
      Home Address = the mobile node's home address
      Binding Registrar = IP address of RS2 copied from Registration
        Server extension
      Care-of Address = the Care-of Address copied from the Mobility
        Agent Advertisement Extension of the Router Advertisement
        message
      Identification = Network Time Protocol timestamp or Nonce
      Extensions:
         The Mobile-Foreign(RS2) Authentication Extension
         The Mobile-Agent Authentication Extension (?)

The foreign agent will relay the Registration Request to RS2.
The mobile node upon hearing a positive registration reply from
RS2 (which is relayed by the foreign agent) will copy the parent
care-of address (COA1) allocated from the Care-of Address Extension
in the Registration Reply. The mobile node will create an
entry to record the local registration server's IP address, the
parent care-of address, and the local registration life time.

If we allow for local service and that the foreign network prefers a
tunnel to be built between the care-of agent and the foreign agent
for routing mobile node's traffic packets, then RS2 will direct the
care-of agent whose IP address is the parent care-of address (COA1) to
build a tunnel to the foreign agent.



Expires  April 1998                                            [Page 26]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


D.1.2 Home Registration
Then, the mobile node will send another Registration Request
   IP fields:
     Source Address = mobile node's home address
     Destination Address = RS2's IP address
     Time to Live = 1 (?)
   UDP fields:
      Source Port = <any>
      Destination Port = 434
   Registration Request fields:
      Type = 1
      S=0, B=0, D=0, M=0,G=0, R=1
      Lifetime=  Oxffff
      Home Address = the mobile node's home address
      Binding Registrar = MN's Home Server (RS1) 's IP address
      Care-of Address = the allocated parent care-of address extracted
        from the Care-of Address extension in the Local Registration
        Reply.
      Identification = Network Time Protocol timestamp or Nonce
      Extensions:
         The Mobile-Home (RS1) Authentication Extension
         The Mobile-Foreign(RS2) Authentication Extension

The local server, RS2, will relay the Home Registration Request to the
MN's Home Server (RS1) by adding the Server (RS2)-Server (RS1)
Authentication Extension. The MN's Home Server will check for the
validity of the Registration Request and sends a Registration Reply
via the local server to the mobile node. The Registration Reply will
contain the MN/Home Server Authentication Extension and the
Server/Server Authentication Extension. If the Home Server approves the
home registration, then the Home Registration Reply
will contain a Care-of Address extension that gives the home agent's
IP address as the parent care-of address. The Home Server
will direct the home agent to build a tunnel to COA1. The Home
Server does so by sending a Route Request Message with Server/Agent
Authentication Extension (if the Home Server does not trust the Home




Expires  April 1998                                            [Page 27]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


D.2  Transit/Home Registration
D.2.1 Transit Registration
Assume that RS2 does not have any server/server authentication with
RS1 in Example D.1.2 above. Then, RS2 will reject the Home
Registration Request and attaches a Registration Server Extension in
its reply:

   Registration Reply from RS2 will be as follows:
   IP fields:

     Source Address = copied from destination address of the
       Registration Request to which RS2 is replying
     Destination Address = copied from the source address of the
       Registration Request to which RS2 is replying

   UDP fields:
      Source Port = <any>
      Destination Port = 434

   Registration Request fields:
      Type = 3
      Code = 67
      Lifetime= ignored
      Home Address = the mobile node's home address
      Binding Registrar = MN's Home Server (RS1) 's IP address
      Identification = copied from Registration Request message

      Extensions:
         Registration Server Extension which gives RS3 as the
           transit registration server.
         The Mobile-Home (RS1) Authentication Extension
         The Mobile-Foreign(RS2) Authentication Extension



Expires  April 1998                                            [Page 28]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997



The mobile node will then send a Registration Request with
RS3 as the binding registrar.
   IP fields:
     Source Address = mobile node's home address
     Destination Address = RS2's IP address
     Time to Live = 1 (?)
   UDP fields:
      Source Port = <any>
      Destination Port = 434
   Registration Request fields:
      Type = 1
      S=0, B=0, D=0, M=0,G=0, R=1
      Lifetime=  Oxffff
      Home Address = the mobile node's home address
      Binding Registrar = RS3's IP address
      Care-of Address = the allocated parent care-of address extracted
        from the Care-of Address extension in the Local Registration
        Reply.
      Identification = Network Time Protocol timestamp or Nonce
      Extensions:
         The Mobile-Home (RS1) Authentication Extension
         The Mobile-Foreign(RS3) Authentication Extension
         The Mobile-Foreign(RS2) Authentication Extension

The local server, RS2, will relay the Transit Registration Request to
RS3. RS3 will validate the Registration Request and sends a
Registration Reply to MN. If RS3 approves the transit registration,
it will attach a Care-of Address extension which contains information
on the new parent care-of address (COA2).




Expires  April 1998                                            [Page 29]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997




D.2.2 Home Registration
The mobile node then sends a Home Registration Request to its
Home Server via RS3
   IP fields:
     Source Address = mobile node's home address
     Destination Address = RS3's IP address
     Time to Live = 1 (?)
   UDP fields:
      Source Port = <any>
      Destination Port = 434
   Registration Request fields:
      Type = 1
      S=0, B=0, D=0, M=0,G=0, R=1
      Lifetime=  Oxffff
      Home Address = the mobile node's home address
      Binding Registrar = MN's Home Server
      Care-of Address = the allocated parent care-of address, COA2
        extracted from the Care-of Address extension in the Transit
        Registration Reply.
      Identification = Network Time Protocol timestamp or Nonce
      Extensions:
         The Mobile-Home (RS1) Authentication Extension
         The Mobile-Foreign(RS3) Authentication Extension

If the Home Server approves the registration, it will send
a Registration Reply with an attached Care-of Address Registration
that gives home agent address as the parent care-of address.
The Home Server will also instruct the Home Agent to build a tunnel
to COA2. When RS3 receives the Registration Reply, it will also
instruct COA2 to build a tunnel to COA1. If local service is not
provided by the local server, then we can let transit server
notifies the local server upon successful home registration and the
local server can then instruct COA1 to build a tunnel to the foreign
agent.




Expires  April 1998                                            [Page 30]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997



D.3 Optimizing Registrations
Based on the examples described above, we describe in this section
how the number of registrations can be reduced.

D.3.1 Local/Home Registration
With the requirement that the Agent Advertisement contains
all registration servers' addresses that the local server has
authentication with, a mobile node can decide if it can perform
a home registration together with a local registration.
If the mobile node finds its Home Server's address in the
Agent Advertisement, it can send a Registration Request
Message with an attached Registration Server Extension
which contains the Home Server address and its life time.
   IP fields:
     Source Address = mobile node's home address
     Destination Address = foreign agent's IP address
     Time to Live = 1 (?)
   UDP fields:
      Source Port = <any>
      Destination Port = 434
   Registration Request fields:
      Type = 1
      S=0, B=0, D=0, M=0,G=0, R=1
      Lifetime=  LifeTime copied from Agent Advertisement
      Home Address = the mobile node's home address
      Binding Registrar =  local server (RS2)'s IP address
      Care-of Address = foregin agent address
      Identification = Network Time Protocol timestamp or Nonce
      Extensions:
         The Registration Server Extension with Home Server
           information and Home Registration Lifetime
         The Mobile-Home (RS1) Authentication Extension
         The Mobile-Agent Authentication Extension(?)
         The Mobile-Foreign(RS2) Authentication Extension

If the local server RS2 approves the registration, it will
change the binding registrar to the Home Server's IP address
(extracted from Registration Server Extension), replaces
the Lifetime with Home Registration Lifetime, and change the care-of
address to a newly allocated parent care-of address. Then, it relay
this registration request message (without the registration server
extension) to the Home Server. Upon receiving a reply from
the Home Server, the local server formulates the following
Registration Reply:

   IP fields:

     Source Address = copied from destination address of the
       Registration Request to which RS2 is replying
     Destination Address = copied from the source address of the
       Registration Request to which RS2 is replying

   UDP fields:
      Source Port = <any>
      Destination Port = 434



Expires  April 1998                                            [Page 31]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


   Registration Request fields:
      Type = 3
      Code =
      Lifetime= Local Registration LifeTime
      Home Address = the mobile node's home address
      Binding Registrar = RS2's IP address
      Identification = copied from Registration Request message

      Extensions:
         Registration Server Extension which gives Home Server's
          IP address as well as Home Registration LifeTime
         The Mobile-Home (RS1) Authentication Extension
         The Mobile-Foreign(RS2) Authentication Extension

Similar optimizations can be done for the case of transit
registrations.

D.4  Interoperability with RFC2002

D.4.1 Mobile Node with DREMIP feature in a RFC2002-compliant
network

Assume that MN1 which has DREMIP feature visits a foreign network
that runs RFC2002-compliant base Mobile-IP protocol. MN1 receives
an Agent Advertisement without Registration Server Extension. Hence,
it issues a Registration Request Message with R bit cleared to its
Home Agent/Home Registration Server via the Foreign Agent. The
Registration Request Message will not have a Registration Server
Extension. To the foreign agent, the binding registrar's field is
like the Home Agent field in the base protocol. MN1 attaches the
MN/Server or MN/Home Agent Authentication extension. If there exists
authentication extension between MN1 and the Foreign Agent,
MN1 will also attach that extension. The Foreign Agent will
then deliver the Registration Request to the binding registrar
which can either be the Home Registration Server or Home Agent.
If the binding registrar is the Home Registration Server (HRS), then
the HRS will issue a Registration Reply which has the MN's home
address and its home agent address just like in base Mobile-IP
protocol without attaching any Care-of Address extension.



Expires  April 1998                                            [Page 32]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997



D.4.2 Mobile Node without DREMIP feature in a DREMIP compliant
network

The mobile node will ignore the registration server extension in the
Agent Advertisement. The mobile node will issue a Registration
Request with R bit cleared to the foreign agent. The Registration
Request contains the MN's home address and MN's home agent address.
The mobile node attaches the MN/Home Agent Authentication
and the MN/Foreign Agent Authentication extensions. Note that here,
we assume that unless there is a MN/Foreign Agent Authentication
extensions, the mobile node cannot use the service in this foreign
network. The foreign agent in the DREMIP network notices that the
R-bit is clear and hence just relays the Registration Request message
to the MN's Home Agent. The Home Agent issues a Registration Reply which
doesn't contain Care-of-Address extension to the Foreign Agent.
The Foreign Agent faithfully delivers the Registration Reply message
to the mobile node.


References


   [1]  Charles Perkins, editor. IP mobility support. RFC 2002, Oct
1996.

   [2]  Charles Perkins.  Mobile-IP Local Registration with
        Hierarchical Foreign Agents. Internet Draft,
        draft-perkins-mobileip-hierfa-00.txt, February 1996. Work in
        progress.

   [3]  Charles Perkins.  IP Encapsulation within IP.  RFC 2003,
        October 1996.

   [4]  David B. Johnson and Charles Perkins. Route Optimization in
        Mobile IP.  Internet Draft, draft-ietf-mobileip-optim-04.txt,
        February 1996.  Work in progress.

   [5]  Joyce K. Reynolds and Jon Postel.  Assigned Numbers.  RFC 1700,
        October 1994.

   [6]  J. Zao, etc.  A Public-Key Based Secure Mobile IP, Proceedings
        of Mobicom97, October, 1997.

   [7]  D. Johnson, etc.  Route Optimizations in Mobile-IP networks
        Internet Draft. draft-optim-05.txt, October, 1997. Work in
        progress.


Expires  April 1998                                            [Page 33]


Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997


Acknowledgement


The authors wish to thank Week Tuck Teo from National University of
Singapore for some useful comments on an earlier draft.


Authors' Address

     Questions about this memo can also be directed to:

      M. C. Chuah,
      Performance Analysis Department,
      Room 3K-320,
      Bell Laboratories,
      Lucent Technologies,
      101, Crawfords Corner Road,
      Holmdel, NJ 07733, USA.
      Phone: 732-949-7206
      Fax: 732-834-5906
      Email: chuah@lucent.com

      Y. Li
      Protocol Development Group
      Engineering Department
      Bay Networks, Inc.
      BL60-304, 600 Technology Park Drive
      Billerica, MA 01821
      Phone: (508) 916-1130
      Fax:   (508) 670-8760
      Email: yli@BayNetworks.COM











Expires  April 1998                                            [Page 34]

Internet Draft    Dynamic Registration Extension of Mobile-IP   30 Oct 1997