Internet Engineering Task Force                         David B. Johnson
INTERNET DRAFT                                Carnegie Mellon University
draft-johnson-imhp-00.txt                                   Andrew Myles
                                                    Macquarie University
                                                         Charles Perkins
                                                         IBM Corporation
                                                        14 February 1994


                The Internet Mobile Host Protocol (IMHP)


Abstract

   This document specifies the Internet Mobile Host Protocol (IMHP),
   which allows transparent routing of IP packets to mobile hosts in
   the Internet, while using only the mobile host's "home" IP address.
   No changes are required in stationary hosts that communicate with
   mobile hosts, and no changes are required in mobile hosts above the
   IP level.  IMHP quickly converges to optimal routing following the
   movement of a mobile host, while maintaining the "weak security"
   model of today's Internet.

   The views and conclusions contained in this document are those of
   the authors and should not be interpreted as representing the Mobile
   IP Working Group or the IETF.  It is our hope to better explain
   the issues and to stimulate discussion, in order to assist the
   Working Group in its efforts to develop a single Group draft protocol
   specification.  This document has not been approved by the Mobile IP
   Working Group.
























Johnson, Myles, Perkins         Expires 14 August 1994          [Page i]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


Status of This Memo

   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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as "working
   drafts" or "work in progress".

   Please check lid-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of an Internet Draft.


































Johnson, Myles, Perkins         Expires 14 August 1994         [Page ii]

Internet Draft      Internet Mobile Host Protocol       14 February 1994




                                Contents



Abstract                                                               i

Status of This Memo                                                   ii

 1. Introduction                                                       1

 2. Terminology                                                        3

 3. Infrastructure                                                     6
     3.1. Mobile Host . . . . . . . . . . . . . . . . . . . . . . .    6
     3.2. Foreign Agent . . . . . . . . . . . . . . . . . . . . . .    6
     3.3. Cache Agent . . . . . . . . . . . . . . . . . . . . . . .    7
     3.4. Home Agent  . . . . . . . . . . . . . . . . . . . . . . .    8
     3.5. Home Network  . . . . . . . . . . . . . . . . . . . . . .    9

 4. IMHP Security                                                     11
     4.1. Security Model Definitions  . . . . . . . . . . . . . . .   11
           4.1.1. The Insecure Model  . . . . . . . . . . . . . . .   11
           4.1.2. Strong Security Model . . . . . . . . . . . . . .   11
           4.1.3. Weak Security Model . . . . . . . . . . . . . . .   12
     4.2. Weak Security Implementation in IMHP  . . . . . . . . . .   12
           4.2.1. Home Agent to Mobile Host Authentication  . . . .   12
           4.2.2. Obtaining Authenticated Bindings  . . . . . . . .   13
           4.2.3. Optimizing Previous Foreign Agent Notifications .   14
           4.2.4. Security and Forwarding . . . . . . . . . . . . .   15
           4.2.5. Advertising Mobile Host Locations . . . . . . . .   16

 5. Tunneling                                                         17

 6. Forwarding Rules                                                  18

 7. Foreign Agent Discovery                                           20
     7.1. Agent Advertisement Message . . . . . . . . . . . . . . .   20
     7.2. Agent Solicitation Message  . . . . . . . . . . . . . . .   21
     7.3. Lower Network Layer Support . . . . . . . . . . . . . . .   22
     7.4. Mobile Host Movement Discovery  . . . . . . . . . . . . .   22

 8. Registration Procedures                                           24
     8.1. Overview of Initial Registration Procedures . . . . . . .   24
     8.2. Overview of Re-registration Procedures  . . . . . . . . .   25
     8.3. Retransmissions . . . . . . . . . . . . . . . . . . . . .   26
     8.4. Registration Request Message Fields . . . . . . . . . . .   27



Johnson, Myles, Perkins        Expires 14 August 1994         [Page iii]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


     8.5. Registration Reply Message Fields . . . . . . . . . . . .   28
     8.6. Foreign Agent Registration  . . . . . . . . . . . . . . .   29
           8.6.1. Sending the Registration Request Message  . . . .   29
           8.6.2. Foreign Agent Processing of Registration Request    30
           8.6.3. Foreign Agent Registration Operations . . . . . .   31
           8.6.4. Mobile Host Processing of Registration Reply  . .   32
     8.7. Home Agent Registration . . . . . . . . . . . . . . . . .   33
           8.7.1. Sending the Registration Request Message  . . . .   33
           8.7.2. Foreign Agent Processing of Registration Request    34
           8.7.3. Home Agent Processing of Registration Request . .   34
           8.7.4. Home Agent Registration Operations  . . . . . . .   35
           8.7.5. Foreign Agent Processing of Registration Reply  .   36
           8.7.6. Mobile Host Processing of Registration Reply  . .   36
     8.8. Home Network Registration . . . . . . . . . . . . . . . .   36
     8.9. De-registration . . . . . . . . . . . . . . . . . . . . .   37
           8.9.1. Mobile Host Initiated De-registration . . . . . .   37
           8.9.2. Foreign Agent Initiated De-registration . . . . .   38

 9. Notifying Previous Foreign Agents                                 39
     9.1. Previous Foreign Agent List . . . . . . . . . . . . . . .   39
     9.2. Notification Methods  . . . . . . . . . . . . . . . . . .   40
     9.3. Binding Notify Message  . . . . . . . . . . . . . . . . .   41
     9.4. Previous Foreign Agent Operations . . . . . . . . . . . .   42
     9.5. Binding Acknowledge Message . . . . . . . . . . . . . . .   43
     9.6. Mobile Host Operations  . . . . . . . . . . . . . . . . .   43
     9.7. Retransmissions . . . . . . . . . . . . . . . . . . . . .   43

10. Other Management Procedures                                       44
    10.1. Notifying Other Entities  . . . . . . . . . . . . . . . .   44
    10.2. Acquiring Authenticated Mobile Host Bindings  . . . . . .   45
          10.2.1. Sending a Binding Inquire Message . . . . . . . .   46
          10.2.2. Processing a Binding Inquire Message  . . . . . .   47
          10.2.3. Processing the Binding Notify Message . . . . . .   47

11. Packet Transmission Examples                                      49
    11.1. Mobile Host to Mobile Host Communications . . . . . . . .   49
    11.2. Mobile Host Movement  . . . . . . . . . . . . . . . . . .   50
    11.3. Stationary Host to Mobile Host  . . . . . . . . . . . . .   51
    11.4. Routing Loop Resolution Between Home Agent and
             Foreign Agent  . . . . . . . . . . . . . . . . . . . .   52
    11.5. Routing Loop Resolution Between Cache Agents  . . . . . .   53

12. Other Issues                                                      54
    12.1. Registration on a Home Network  . . . . . . . . . . . . .   54
    12.2. Location Cache and Visitor List Time Outs . . . . . . . .   56
    12.3. Popups  . . . . . . . . . . . . . . . . . . . . . . . . .   56
    12.4. Intermediate Cache Agents . . . . . . . . . . . . . . . .   57
    12.5. Password Algorithms . . . . . . . . . . . . . . . . . . .   57



Johnson, Myles, Perkins         Expires 14 August 1994         [Page iv]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


13. IMHP Management Packet Formats                                    59
    13.1. Agent Advertisement Message . . . . . . . . . . . . . . .   61
    13.2. Agent Solicitation Message  . . . . . . . . . . . . . . .   63
    13.3. Registration Request Message  . . . . . . . . . . . . . .   65
    13.4. Registration Reply Message  . . . . . . . . . . . . . . .   70
    13.5. Binding Inquire Message . . . . . . . . . . . . . . . . .   75
    13.6. Binding Notify Message  . . . . . . . . . . . . . . . . .   77
    13.7. Binding Acknowledge Message . . . . . . . . . . . . . . .   80

References                                                            82

Authors' Addresses                                                    83







































Johnson, Myles, Perkins         Expires 14 August 1994          [Page v]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


1. Introduction

   Computers are no longer large, expensive, and non-portable.  Recent
   developments make it possible to buy inexpensive notebook and palmtop
   computers that are both portable and extremely powerful.  As a
   result, people are not constrained to using their computers in a
   single location.

   At the same time, computer networking is becoming indispensable
   to the average user.  The ability to access information and to
   communicate globally has amplified the utility of computers many
   times over.  Users increasingly want to attach to the network with
   the same level of service, regardless of where they happen to be
   working.

   A typical user might usually connect to the network at his desk, but
   occasionally will take the computer to a conference room in another
   part of the building, or even at another site.  However, today's
   networking protocols, including the TCP/IP and the OSI protocol
   suites, generally assume that each computer attaches to the network
   at a fixed physical location, logically encoded into the network
   address of that computer.  In these protocols today, host movement is
   assumed to occur so rarely that it can be handled manually.

   For example, consider the host movement scenario described above
   using IP  [9].  If the user's desk and the conference room have
   direct access to the same IP subnet, then the movement process is
   trivial.  Otherwise, the user must acquire a new IP address on
   the conference room subnet from the appropriate local authority,
   which may not be an easy task.  Numerous configuration files on the
   moving host, on multiple name servers, and on other hosts (that use
   the original IP address to identify the moving host) must then be
   modified to reflect the new address of the moving host.

   This process achieves network connectivity as the host moves, but
   only after a slow, error prone configuration procedure that a typical
   user does not have the skills or desire to carry out.  In addition,
   the moving host has a completely different identity after these
   changes, and all existing network applications must be restarted.
   Clearly, additional protocols are needed to allow this type of host
   movement to be achieved transparently to the user.

   Ease of movement will become even more important as wireless network
   interfaces become widely available.  Once the user is unconstrained
   by cable, it is likely that frequent network movement will become
   common.  Host movement may not even be under the user's control.  For
   example, if a mobile host operates in overlapping wireless cells, the
   host may move from one cell to another based on dynamic factors such



Johnson, Myles, Perkins         Expires 14 August 1994          [Page 1]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   as load and noise.  Protocols to support host mobility will not only
   have to be transparent, they will have to be efficient so that they
   can handle rapid host movement.

   Increasingly, computer networks are being interconnected into
   a single global network.  This trend will continue with the
   proliferation of metropolitan and wide area network services.  The
   Internet is a good example of a growing global network.  Users
   already have access to network facilities anywhere in the world,
   not just in the local area.  The new protocols should therefore be
   designed to operate optimally in both the local and wide area cases.

   This document specifies a new protocol, called the Internet Mobile
   Host Protocol (IMHP), that allows mobile hosts to move rapidly around
   both the local and the wide area network in an IP environment.  The
   protocol attempts to optimize routing to a mobile host, and extends
   the existing IP architecture so that mobility can occur transparently
   to the user and to higher network layers.

   IMHP contains many features drawn from the proposals from Carnegie
   Mellon University [5] and from Macquarie University and IBM [6].
   It uses the general architecture proposed by IBM [7], and includes
   aspects drawn from the proposals of Sony [13, 11, 12] and Columbia
   University [3, 4].



























Johnson, Myles, Perkins         Expires 14 August 1994          [Page 2]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


2. Terminology

   The discussion in the rest of this document uses the following terms:

      System

         A device that implements the Internet Protocol, IP [9].

      Router

         A system that forwards IP datagrams, as specified in [1].  This
         does not include systems that, though capable of IP forwarding,
         have that capability turned off, nor does it include systems
         that do IP forwarding only insofar as required to obey IP
         Source Route options.

      Host

         Any system that is not a router.

      Mobile Host

         A host that may connect to the Internet in networks other than
         its own home network, while still using its home address.

      Stationary Host

         A host that is not a mobile host.

      Correspondent Host

         A host communicating with another host.  This term is used in
         discussions involving the sending of packets to a mobile host,
         in situations in which it is not relevant whether the sending
         host is a mobile host or a stationary host.

      Home Address

         The permanently assigned IP address of a mobile host, used used
         to identify the mobile host no matter where it may currently be
         located.

      Home Network

         The network on which a mobile host's home address resides.  The
         home network may correspond to a physical network or a virtual
         network.




Johnson, Myles, Perkins         Expires 14 August 1994          [Page 3]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      Foreign Agent

         A system that allows mobile hosts to connect to its local
         network, keeps a list of these mobile hosts in a "visitors
         list", and forwards received packets addressed to one of these
         mobile hosts to the mobile host through a local interface.

      Care-of Address

         An address offered by the foreign agent with which a mobile
         host is registered, which is used to define the location of
         a mobile host at a particular instant of time, and to which
         packets addressed to the mobile host may be tunneled.  In
         many cases, the care-of address offered by a foreign agent
         will be one of IP addresses of the foreign agent, but other
         configurations are also possible.  A foreign agent must use the
         same care-of address for all registered mobile hosts.

      Binding

         The combination of a care-of address and a home address for a
         mobile host is known as a binding.  A binding may also have
         timeouts, flags, or other information associated with it.

      Cache Agent

         A system that caches the binding of one or more mobile hosts
         in a "location cache" and tunnels any packets it receives or
         originates addressed to these mobile hosts to the foreign agent
         indicated by the cached binding.

      Home Agent

         A system that maintains a list of mobile hosts it serves in
         a "home list", and when when one of these mobile hosts is
         registered with a foreign agent that is not also the mobile
         host's home agent or is not connected to its home network,
         intercepts packets on the home network addressed to the mobile
         host and forwards them using a location cache.  A home agent
         must act as a cache agent and may act as a foreign agent for
         the mobile hosts it serves.

      Triangle Routing

         A situation in which a correspondent host's packets to a mobile
         host follow a longer than optimal path by being forwarded
         through the mobile host's home agent, rather than following the




Johnson, Myles, Perkins         Expires 14 August 1994          [Page 4]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


         shortest path directly to the foreign agent serving the mobile
         host.

















































Johnson, Myles, Perkins         Expires 14 August 1994          [Page 5]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


3. Infrastructure

   This section defines the four types of systems used by IMHP: the
   mobile host, the foreign agent, the cache agent, and the home agent.
   Although the systems are defined here separately, any or all of them
   may be combined into a single system.


3.1. Mobile Host

   A mobile host is a system that may move through the IP internetwork.
   Each mobile host is assigned a constant IP address on a home
   network, and this address is known as the mobile host's home address.
   Correspondent hosts always address packets for a mobile host to the
   mobile host's home address.


3.2. Foreign Agent

   When a mobile host connects to a local network, it must identify
   and register with a foreign agent that can forward arriving packets
   locally to it.  The mechanisms used to discover that the mobile
   host has connected to a new local network depend in part on the
   sub-network layer technology in use; a range of possibilities for
   this discovery are discussed in Section 7.  When a packet arrives
   at a foreign agent addressed to a visiting mobile host registered
   with that foreign agent, the foreign agent must be able to deliver
   this packet to the mobile host without using normal IP routing.
   The simplest configuration for supporting this requirement is that
   the foreign agent must be located on the same physical network as
   the visiting mobile host, in which case it need only transmit the
   packet on this network to the mobile host's MAC address.  Other
   configurations for the foreign agent are also possible but are beyond
   the scope of this document.

   Each foreign agent maintains a "visitor list" identifying those
   mobile hosts that are currently registered with this foreign agent.
   Subject to some security constraints discussed in Section 4.2.4, if a
   foreign agent receives a packet destined to a mobile host for which
   it has an entry in its visitor list, the foreign agent should deliver
   the packet locally to the mobile host.

   Each visitor list entry may be marked to be deleted after a period of
   time negotiated during the registration of the mobile host with this
   foreign agent.  A mobile host must re-register before this period has
   expired to ensure uninterrupted service from the foreign agent.





Johnson, Myles, Perkins         Expires 14 August 1994          [Page 6]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   The foreign agent, during the registration process, provides the
   mobile host with a care-of address, which defines the mobile host's
   current location.  In this document, the care-of address offered by a
   foreign agent is assumed to be one of the IP addresses of the foreign
   agent, although other configurations are also possible.  Any system
   including foreign agent functionality must offer the same care-of
   address on all its network interfaces.  The combination of the mobile
   host's home address and the care-of address provided by the foreign
   agent is known as a binding.

   A mobile host's binding is tagged with a "Registration Sequence
   Number".  This sequence number originates from the mobile host and
   is incremented each time the mobile host attempts to register or
   re-register with a foreign agent.  The registration sequence number
   is used to compare the age of bindings for a mobile host to determine
   which is the most recent.

   When a mobile host registers with a new foreign agent, any previous
   foreign agents that may still have a valid visitor list entry for
   the mobile host must be notified.  Such a previous foreign agent,
   subject to some security constraints, then deletes its visitor list
   entry for the mobile host.  This notification to a previous foreign
   agent must be reliable in order to ensure that the previous foreign
   agent does not attempt to deliver packets to a mobile host that is no
   longer at that location.  Such packets should instead be forwarded
   to the mobile host's new location.  The mobile host may request its
   new foreign agent to send this notification to the previous foreign
   agent at registration time, or the mobile host may elect to send the
   notification itself.


3.3. Cache Agent

   The IMHP management protocol may distribute a mobile host's binding
   to others systems as needed.  This binding may be stored in a
   "location cache" by systems that function as "cache agents".  If a
   cache agent receives a packet addressed to a mobile host for which it
   has an entry in its location cache, the cache agent may tunnel the
   packet to the mobile host's currently known foreign agent, as defined
   by the care-of address in the binding.  The tunneling protocol is
   discussed in Section 5.

   Any location cache will of necessity have a finite size; with the one
   exception described in Section 3.4, all entries in a location cache
   may be managed by the cache agent using any local cache replacement
   policy, such as LRU.  The consistency of any location cache entries
   for a mobile host, with respect to the true location of that mobile
   host, is maintained as needed by the IMHP management protocol.



Johnson, Myles, Perkins         Expires 14 August 1994          [Page 7]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   Each location cache entry is marked to be deleted after a period of
   time specified by the system providing the binding.  A cache agent
   may attempt to reconfirm an entry in its location cache before the
   entry expires, thus extending the cache entry's timeout period.  Such
   active reconfirmation is appropriate when it is likely that the entry
   will be used again in the near future and the cache agent wants to
   ensure uninterrupted service to the mobile host.

   If a foreign agent is notified that a mobile host it serves has
   moved, it may use the binding included with the notification, subject
   to some security constraints, to establish a location cache entry for
   the mobile host, if this foreign agent is also capable of functioning
   as a cache agent.  The location cache entry is marked to be deleted
   after a period of time specified by the notification.


3.4. Home Agent

   Each mobile host must have a home agent, which is attached to the
   mobile host's home network.  The home agent maintains a "home list"
   identifying all mobile hosts it is configured to serve.  If the home
   network is a physical network (Section 3.5), the home agent must also
   function as a foreign agent for the mobile hosts in its home list,
   allowing those mobile hosts to register directly with it when they
   connect to their home network, as described in Section 8.8.

   A home agent must also function as a cache agent for at least those
   mobile hosts in its home list.  For each of the mobile hosts in a
   home agent's home list that are not registered directly with it (in
   its role as a foreign agent), the home agent stores the current
   binding for that mobile host in its location cache.  The location
   cache must be at least as large as the home list, and the location
   cache entries holding bindings for mobile hosts in its home list
   must not be replaced from the cache by other entries; As described
   in Section 3.3, all other entries in the cache may be managed by the
   cache agent using any local cache replacement policy.

   When a mobile host is not registered with the foreign agent that is
   also its home agent, its home agent must arrange to intercept any
   packets on the home network that are normally addressed to the mobile
   host.  This can be done, for example, using proxy ARP [10] to cause
   all systems on the home network to change their ARP caches so that
   packets addressed to the mobile host's IP address will be sent to the
   home agent's MAC address.  When the home agent intercepts a packet
   addressed to the mobile host, the home agent uses the binding in
   its location cache to forward the packet to the mobile host.  The
   packet is tunneled to the foreign agent identified in the binding, as




Johnson, Myles, Perkins         Expires 14 August 1994          [Page 8]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   described in Section 5, which then delivers the packet locally to the
   mobile host.

   A mobile host's home agent must always have a current binding for
   each of its mobile hosts, in order to provide service to them.
   Whenever a mobile registers with a foreign agent, it must also
   register with its home agent.  The location cache entry created by
   the home agent during this registration (in its role as a cache
   agent) may be marked to be deleted after a period of time negotiated
   during the registration.  A mobile host must re-register before this
   period expires to ensure uninterrupted service from the home agent.

   A home agent in its role as a foreign agent creates a visitor
   list entry for a mobile host when it registers with the home agent
   directly.  The visitor list entry is marked to be deleted after a
   period of time negotiated during registration.  The mobile host
   must re-register before this period expires to ensure uninterrupted
   service from the home agent.  The expiration period of this visitor
   list entry may instead be set to infinite, in which case the mobile
   host does not have to re-register.  This setting allows efficient
   operation when a mobile host is connected to its home network and
   registered directly with the foreign agent that is its home agent.

   When a home agent does not have a binding for one of its mobile
   hosts, the home agent should assume that the mobile host is connected
   to its home network.  In this way, the mobile host may still operate
   as a stationary host in its home network if its mobile host software
   is not operational.


3.5. Home Network

   The home network may correspond to a physical network or to a virtual
   network.  In either case, a router connected to the home network is
   responsible for advertising reachability to the home network.  The
   router may optionally be incorporated into the system containing
   the home agent, but this is not necessary.  To illustrate the range
   of configurations possible for the home network, Figure 1 shows the
   following three common home network configurations:

   (a) The home network is a physical network connected to the Internet
       by a router.  The home agent is a separate system attached to the
       physical home network.

   (b) The home network is a physical network connected to the
       Internet by a system that contains both home agent and router
       functionality.




Johnson, Myles, Perkins         Expires 14 August 1994          [Page 9]
Internet Draft      Internet Mobile Host Protocol       14 February 1994



   (c) The home network is a virtual network connected to the
       Internet by a system that contains both home agent and router
       functionality.  This home agent is not also a foreign agent.
       Mobile hosts with a home address on this home network cannot
       connect directly to their home network.







                                             |
          /------------\                     | Physical
         /              \      +--------+    | home network
         | Internetwork +------+ Router +----+
         \              /      +--------+    |   +--------+
          \------------/                     +---+        +
                                             |   +--------+
                                             |   Home agent

        (a) Home agent as a separate system on the home network


                                             |
          /------------\                     | Physical
         /              \      +--------+    | home network
         | Internetwork +------+ Router +----+
         \              /      +--------+    |
          \------------/       Home agent    |
                                             |
                                             |

            (b) Home agent in the router to the home network


                                             .
          /------------\                     . Virtual
         /              \      +--------+    . home network
         | Internetwork +------+ Router +----+
         \              /      +--------+    .
          \------------/       Home agent    .
                                             .

                       (c) A virtual home network


           Figure 1: Examples of home network configurations



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 10]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


4. IMHP Security

   IMHP is designed primarily to support a "weak security" model, which
   is equivalent to the level of security provided by the Internet
   today.  IMHP could also be extended to support a "strong security"
   model, or its security features may be ignored in order to implement
   an "insecure" protocol.

   This section defines the insecure model, the strong security
   model, and the weak security model, and outlines the advantages
   and disadvantages of each.  This section also specifies the
   implementation of the weak security model under IMHP.


4.1. Security Model Definitions

4.1.1. The Insecure Model

   The insecure model is based on the premise that a system may
   immediately believe a binding or other information it receives from
   another system.  No security features are required in the protocol to
   support the insecure model.

   The insecure model provides for fast convergence to optimal routes
   and is easy to implement.  However, this model allows a malicious or
   mischievous system to intercept a packet stream to a mobile host by
   simply sending a forged management packet containing a false binding.

   Although the insecure model might be appropriate in a private, closed
   network, it is unacceptable in the Internet where nothing may be
   assumed about the integrity of other users.


4.1.2. Strong Security Model

   The strong security model is based on the premise that no other
   system may be trusted unless it is fully authenticated.  In
   particular, a system may not trust a binding or other information
   it receives without first fully authenticating it.  Authentication,
   under the strong security model, almost certainly requires the use of
   public and private keys and trusted servers.

   The main disadvantage of the strong security model is its complexity
   and speed of operation.  In particular, convergence to close to
   optimal routes may be a slow process.






Johnson, Myles, Perkins         Expires 14 August 1994         [Page 11]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


4.1.3. Weak Security Model

   The weak security model is based on the premise that IMHP should
   provide security that is at least as good as that provided by the
   Internet today, which is certainly less than that provided by the
   strong security model.

   The weak security model assumes that all systems on the normal path
   of a packet through the Internet are trustworthy.  This is the
   general assumption under which IP packets are routed through the
   Internet today.  For example, in today's Internet, many packets
   contain plain-text passwords, which we trust intermediate systems
   not to intercept.  By taking advantage of this assumption, a simple
   request-response mechanism may be used to authenticate a mobile
   host's binding.  This mechanism is explained in the following
   sections.


4.2. Weak Security Implementation in IMHP

   In the context of IMHP, the weak security model requires a system to
   perform a relatively simple authentication procedure when it receives
   new information about the location of a mobile host.  Figure 2
   illustrates these procedures, which are explained in the following
   sections.


4.2.1. Home Agent to Mobile Host Authentication

   A home agent must be able to authenticate any information it receives
   from a mobile host in its home list.  Similarly, a mobile host must
   be able to authenticate any information it receives from its home
   agent.

   Authentication between a mobile host and its home agent is achieved
   through a 64-bit password, based on secret shared between the
   mobile host and its home agent.  This shared secret is established
   through some external management procedure, such as during initial
   configuration of the mobile host.  The exact procedure used in
   establishing this shared secret between a mobile host and its home
   agent is beyond the scope of this document.  This 64-bit password is
   included in management packets that are sent between the mobile host
   and its home agent.

   This method of authentication is no worse than a password being
   passed in clear-text across today's Internet, and so it may be
   considered to satisfy the weak security model.




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 12]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      +--------------+     Binding & password    +--------------+
      |              |-------------------------->|              |
      |  Home agent  |                           |  Mobile host |
      |              |<--------------------------|              |
      +--------------+      Reply & password     +--------------+

              (a) Home agent to mobile host authentication


                         Request for binding &
      +--------------+       authenticator       +--------------+
      |  Home agent  |-------------------------->|              |
      |      or      |                           |    System    |
      |  Mobile host |<--------------------------|              |
      +--------------+          Reply &          +--------------+
                           same authenticator

                 (b) Obtaining an authenticated binding


                             New binding &
      +--------------+   previously established  +--------------+
      |              |       authenticator       |    Previous  |
      |  Mobile host |-------------------------->|    foreign   |
      |              |                           |     agent    |
      +--------------+                           +--------------+

          (c) Optimizing previous foreign agent notifications


    Figure 2: Security procedures in the weak security model in IMHP



   This authentication procedure is illustrated in Figure 2 (a).


4.2.2. Obtaining Authenticated Bindings

   In general, systems using IMHP will not have a shared secret, such
   as a password, that can be used to authenticate information received
   concerning a mobile host.

   However, a system may obtain an authenticated binding for a mobile
   host in IMHP under the weak security model by sending the mobile
   host's home agent (or the mobile host itself) a request that includes
   a randomly chosen authenticator value.  If the reply contains the
   same authenticator value, then the reply and its contents may be



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 13]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   considered to be authenticated under the weak security model, since
   the path between this system and the destination of the request is
   assumed to be trusted.  The randomly chosen authenticator value
   prevents any malicious system not on this path from forging a reply
   to the request.

   In this scheme, either the mobile host could reply, or its home
   agent could reply on behalf of the mobile host.  In general, it is
   preferable that the home agent replies, as the mobile host might
   be temporarily inaccessible from a particular location due to
   out-of-date bindings in intermediate cache agents.

   However, a system generally does not know the home agent address of
   each mobile host.  IMHP specifies a Routing (R) bit in management
   packets that, when set, forces management packets to be routed to the
   mobile host's home network, bypassing the use of all location caches.
   If the mobile host is registered directly on its home network, these
   packets will then be received and processed by the mobile host;
   otherwise, they will be intercepted by the mobile host's home agent,
   which will process the packets on behalf of the mobile host.

   This authentication procedure is illustrated in Figure 2 (b).


4.2.3. Optimizing Previous Foreign Agent Notifications

   When a mobile host moves, it is important that any previous foreign
   agents that may still have a visitor list entry for the mobile host
   are forced to delete that entry to avoid packet loss.  If the foreign
   agent is also a cache agent, it is also desirable that a location
   cache entry is created by the previous foreign agent that indicates
   the mobile host's new location.  This location cache entry allows
   packets to be forwarded by the cache agent to the mobile host's new
   location rather than through the mobile host's home agent.

   IMHP defines a technique that allows these updates to occur without
   having to request an authenticated binding for the mobile host from
   its home agent.  When a mobile host registers with a new foreign
   agent, the mobile host choses a random authenticator value and
   includes this value in its registration request with the foreign
   agent.  The foreign agent may then use this value to authenticate
   a future notification and a new binding that it receives from the
   mobile host indicating that the mobile host has moved.  In effect,
   the authenticator acts as a temporary password between the mobile
   host and this foreign agent.

   The technique of allowing a foreign agent that is also a cache agent
   to create a location cache entry based on the authenticator has a



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 14]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   weakness when malicious hosts intercept the authenticator on the
   local network.  However, the period of time for which the weakness
   exists is limited by specifying that the location cache entry should
   be marked to expire before the registration would have expired in any
   case.

   This authentication procedure is illustrated in Figure 2 (c).


4.2.4. Security and Forwarding

   Since a cache agent only creates a location cache entry when a mobile
   host's binding is fully authenticated, a location cache entry may
   always be safely used to forward any packet.  However, a foreign
   agent creates a visitor list entry for a mobile host on a particular
   interface as soon as it is requested by a locally connected mobile
   host.  Until the identity of the mobile host is authenticated,
   however, a visitor list entry should not generally be used to deliver
   packets to the mobile host.

   The one case in which an unauthenticated visitor list entry may
   be used to deliver packets to a mobile host is when the packet is
   tunneled to the foreign agent holding the visitor list entry.  In
   this case, the cache agent that that tunneled the packet must have
   had an authenticated location cache entry for this mobile host,
   pointing to this foreign agent.  The foreign agent can thus safely
   deliver the decapsulated packet to the mobile host.

   A foreign agent may attempt to authenticate a visitor list entry
   using the mechanisms for acquiring a mobile host's authenticated
   binding, as described in Section 4.2.2.  If the binding it receives
   from the mobile host's home agent indicates that this foreign agent
   is serving the mobile host, the visitor list entry for the mobile
   host may be authenticated for the lifetime indicated in the binding.
   When the lifetime indicated in the reply expires the visitor list
   entry must be reauthenticated.

   The foreign agent is free to start this authentication procedure
   either immediately after the mobile host registers or at some later
   time (such as when the first packet arrives at the foreign agent
   for which the visitor list entry would have been used had it been
   authenticated).  In many cases, a foreign agent will never use a
   visitor list entry to forward a non-tunneled packet, and so there is
   no need to ever authenticate it.

   This mechanism introduces a limitation to the weak security model
   implementation in that, if a cache agent has an old binding cached
   for a mobile host and an impostor mobile host registers where the



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 15]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   binding indicates the real mobile host is registered, then packets
   may be delivered to the impostor until the cache agent either times
   out or deletes the location cache entry.


4.2.5. Advertising Mobile Host Locations

   In some situations, it is desirable that the mobile host's current
   location not be distributed to other systems.  For example, a
   mobile host may not want its correspondent hosts to know that it is
   currently away from its home network.

   In IMHP, a mobile host may specify that its binding should not be
   given to other systems, by setting a Private flag specified when
   the mobile host registers with its foreign agent and home agent.
   In this case, the foreign agent and the home agent must respond to
   any requests for the mobile host's binding by indicating the mobile
   host is connected to its home network.  Similarly, the mobile host
   may indicate that it is connected to its home network when notifying
   previous foreign agents that it has moved.

   Even if a mobile host does not specify during registration that its
   binding may not be advertised, its home agent and the mobile host may
   restrict the binding distribution.  First, they may choose to not
   give some systems the mobile host's binding when they request it.
   Second, they may set the Private flag on the bindings they do give
   out so that the system receiving the binding may not pass it on to
   others.

   The main cost of restricting the distribution of a mobile host's
   binding is an increased incidence of Triangular Routing.  The
   advantage is that a new type of security and privacy is achieved.



















Johnson, Myles, Perkins         Expires 14 August 1994         [Page 16]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


5. Tunneling

   The operation of IMHP requires that cache agents be able to tunnel
   packets to a mobile host's current known location (i.e., the care-of
   address provided by the foreign agent that is serving the mobile
   host).  In principle, any tunneling protocol could used.  However, to
   achieve maximum interoperability and maximum efficiency, IMHP defines
   a new tunneling protocol, which is defined in [?].

   A system that tunnels a packet to another system must always use the
   same source address for the tunnel, in order to ensure that routing
   loops can be detected.  In the case of cache agent that is also a
   foreign agent, the address used must be the single care-of address
   that the foreign agent offers to all mobile host's on all of its
   interfaces.

   The tunneling protocol header defined in [?]  does not carry any
   fragmentation information.  Therefore, the use of this protocol
   requires a cache agent tunneling a packet to reassemble the packet
   (if fragmented) before tunneling the reassembled packet using a
   location cache entry.  This reassembly requirement should generally
   cause no problems, but may prevent tunneling in networks where
   packets often take different routes to a given destination.  If this
   is the case, a full encapsulation protocol will have to be used.

   The forwarding rules in Section 6 make use of what is known as a
   "special tunnel", in which a packet is tunneled with the destination
   of the tunnel equal to the destination of the packet.  A special
   tunnel packet may only be forwarded using normal IP routing
   mechanisms, thus ensuring that it reaches to the destination network.
   A special tunnel may be used to force a packet to be routed to a
   mobile host's home agent, since the packet will be intercepted by the
   home agent once it reaches the mobile host's home network.


















Johnson, Myles, Perkins         Expires 14 August 1994         [Page 17]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


6. Forwarding Rules

   IMHP establishes a few rules for forwarding packets.  These rules
   help ensure that optimal routes are used when possible.  An optimal
   route is defined as the route a packet would normally take between
   two stationary hosts using the conventional IP routing protocols.

   In general, a system uses whatever location cache, visitor list,
   home list, and normal routing table information it has available to
   forward packets, with a small number of restrictions.  If none of the
   rules below apply to a particular packet, then normal IP forwarding
   rules are followed.

   The following two basic rules apply to all IMHP systems, which allow
   for the delivery of packets addressed to these systems and for the
   decapsulation of tunneled packets:

    -  If a system receives a tunneled packet, and the destination of
       the tunnel is one of the system's own addresses, then the system
       decapsulates the packet and continues processing the packet
       according to the remaining forwarding rules.

    -  If a system receives a packet that is not tunneled, and the
       destination of the packet is one of the system's own addresses,
       then the system passes the packet to higher layer protocols for
       processing.

   A home agent will generally have a current authenticated binding for
   the mobile hosts in its home list.  A home agent must also serve as
   a cache agent for these mobile hosts, and may be a foreign agent for
   the mobile hosts it serves as well.  These properties help define the
   forwarding rules for a home agent when dealing with packets addressed
   to the mobile hosts in its home list.  The following forwarding rules
   apply to packets received by a home agent:

    -  If a home agent receives a special tunnel packet addressed to a
       mobile host in its home list, then the home agent decapsulates
       the packet and continues processing the packet according to the
       remaining forwarding rules.

    -  If a home agent receives a packet addressed to a mobile host in
       its home list, and the home agent has a visitor list entry for
       the mobile host, then the home agent delivers the packet locally
       to the interface indicated by the visitor list entry.

    -  If a home agent receives a packet addressed to a mobile host in
       its home list, and the home agent has a location cache entry for
       the mobile host, then the home agent tunnels the packet to the



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 18]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


       care-of address indicated in the location cache entry, subject to
       the restriction in the following rule.

    -  A home agent must never tunnel a packet to a foreign agent if
       the packet was just tunneled to the home agent from that same
       foreign agent.  This rule avoids looping between a home agent and
       a foreign agent that no longer thinks it serves some mobile host.
       The home agent instead may drop the packet or buffer it in these
       circumstances.  The home agent may also undertake other actions
       to locate the mobile host.

    -  If a home agent receives a packet addressed to a mobile host in
       its home list, and this home agent does not have a location cache
       entry or a visitor list entry for the destination mobile host,
       the home agent either drops or buffers the packet.  The home
       agent may also undertake other actions to locate the mobile host.

   Foreign agents and cache agents use forwarding rules that are similar
   to those used by a home agent.  The differences from the rules used
   by a home agent are primarily due to the fact that a foreign agent or
   a cache agent might not have an authenticated binding for the mobile
   host, if that agent is not also the home agent serving that mobile
   host.  The following forwarding rules apply to packets received by a
   foreign agent or a cache agent:

    -  If a foreign agent receives a tunneled packet, and the foreign
       agent has an entry in its visitor list for the packet's
       destination after decapsulating the packet, then the foreign
       agent delivers the packet locally to the interface indicated by
       the visitor list entry.

    -  If a foreign agent receives a packet, and the foreign agent has
       an authenticated visitor list entry for the packet's destination,
       then the foreign agent delivers the packet locally to the
       interface indicated by the visitor list entry.

    -  If a cache agent receives a packet, and the cache agent has a
       location cache entry for the packet's destination, then the cache
       agent tunnels the packet to the care-of address indicated in the
       location cache entry.

    -  If a cache agent or a foreign agent receives a tunneled packet,
       and the cache agent or foreign agent is unable to forward the
       packet using the above rules after decapsulating the packet, then
       the cache agent or foreign agent tunnels the packet to the mobile
       host's home network using a special tunnel.





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 19]
Internet Draft      Internet Mobile Host Protocol       14 February 1994



7. Foreign Agent Discovery

   Before connecting to the Internet, either on its home network or on
   some other local network, a mobile host must identify and register
   with a suitable foreign agent (which may also be a home agent) on
   that same local network.  This section describes the procedures
   a mobile host uses to identify a suitable foreign agent and to
   determine when that foreign agent is no longer available; the
   procedures used for registering with this foreign agent are described
   in Section 8.


7.1. Agent Advertisement Message

   A foreign agent may periodically advertise its services on a local
   network by multicasting an Agent Advertisement message (Section 13.1)
   from its network interface on this local network.  One method that
   a mobile host may use to identify a suitable foreign agent with
   which to register is to simply listen for these Agent Advertisement
   messages.  This agent discovery procedure is illustrated in Figure 3.

   A foreign agent must support a configuration option to specify the IP
   address to which Agent Advertisement messages are sent.  This address
   may be either the reserved "all mobile hosts" multicast address, or
   the limited-broadcast address, 255.255.255.255.

   The current incarnation number of the foreign agent is included in
   each advertisement that it sends.  The foreign agent increments its
   incarnation number each time it reboots and loses the state in its
   visitor list.  The foreign agent may also increment its incarnation
   number at any other time in order to force all currently registered
   mobile hosts that it is serving to reregister.  If a foreign agent
   sends Agent Advertisement messages over more than one network
   interface, it must maintain a separate incarnation number for each



                      MH                    FA or HA

                       :   Agent Advertisement  :
                       :   Message (multicast)  :
                       :<-----------------------:
                       :                        :
                       v                        v


               Figure 3: Agent discovery by listening for
                      Agent Advertisement messages



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 20]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   interface and must ensure that no two interfaces use the same value
   as their current incarnation number.

   The time between transmissions of Agent Advertisement messages on
   an interface by a foreign agent is included in the Interval field
   of each Agent Advertisement message.  Agent Advertisement messages
   may be sent more frequently than this interval, but at least one
   advertisement must be sent during each interval.

   A foreign agent must support a configuration option to specify the
   rate at which it sends periodic Agent Advertisement messages.

   A foreign agent, by setting the Home Agent (H) bit in its Agent
   Advertisement messages, may indicate that it is only willing to
   register mobile hosts that it also serves as a home agent.  Other
   mobile hosts connected to the local network should not attempt
   registration with such a foreign agent, as the foreign agent will
   reject registration attempts from these hosts.  A mobile host can
   determine that a foreign agent also serves as its home agent if the
   Agent Address field in the Agent Advertisement message is the same as
   the mobile host's configured home agent address.


7.2. Agent Solicitation Message

   A mobile host may also multicast an Agent Solicitation message
   (Section 13.2) to ask for immediate advertisements from any suitable
   foreign agents, rather than waiting for the next periodic Agent
   Advertisement message to arrive.  In response to receiving an
   Agent Solicitation message, a foreign agent may multicast an Agent
   Advertisement message, or may unicast an Agent Advertisement message
   directly to the source of the solicitation.  This agent discovery
   procedure is illustrated in Figure 4.

   A foreign agent need not respond to all Agent Solicitation messages
   and is free to use any criteria in deciding whether to respond to a
   particular Agent Solicitation message.  For example, a foreign agent
   may silently ignore an Agent Solicitation message due to a lack of
   resources for serving new visiting mobile hosts, or for security
   reasons related to the particular mobile host that is the source of
   the solicitation.  However, a foreign agent that is also a home agent
   must respond to Agent Solicitation messages from any mobile hosts in
   its home list.

   Each mobile host must support a configuration option to set the IP
   address to which it sends Agent Solicitation messages.  This address
   may be either the reserved "all foreign agents" multicast address, or




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 21]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


                     MH                    FA or HA

                      :   Agent Solicitation   :
                      :   Message (multicast)  :
                      :----------------------->:
                      :                        :
                      :<-----------------------:
                      :   Agent Advertisement  :
                      :   Message (multicast   :
                      :      or unicast)       :
                      v                        v


                Figure 4: Agent discovery by sending an
                       Agent Solicitation message



   the limited-broadcast address, 255.255.255.255.  Foreign agents must
   support receiving Agent Solicitation messages on both addresses.

   A mobile host must limit the frequency with which it sends Agent
   Solicitation messages.  The maximum frequency is a configuration
   parameter.  If a mobile host receives no response to its Agent
   Solicitation messages after a limited number of attempts, it should
   back off in the rate of their transmission.  The back-off algorithm
   is also a matter of configuration.


7.3. Lower Network Layer Support

   A mobile host may use any facilities provided by the specific
   sub-network layer technology in use, to assist it in identifying a
   suitable foreign agent.  For example, a "cell-association" event from
   Layer 2 in a wireless network may trigger the registration procedure
   within the mobile host.


7.4. Mobile Host Movement Discovery

   As a mobile host moves from one network to another, it is important
   that it be able to discover its movement in a timely manner so
   that it can begin registration procedures with a new foreign agent
   after each movement.  Only once registration with a foreign agent
   is complete, can data communications resume.  A mobile host may
   determine that it has moved, and therefore that it must register with
   a new foreign agent, in one of three ways.




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 22]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   First, a mobile host may determine that its current foreign agent
   is no longer available, by detecting that a number of consecutive
   expected Agent Advertisement messages from this foreign agent have
   not been received.  A mobile host should support a configuration
   option to set the number of consecutive missed Agent Advertisement
   messages from its current foreign agent that will cause the mobile
   host to consider this foreign agent as no longer available.

   The second way in which a mobile host may determine that it has
   moved is by through indications provided by lower network layers.
   Normally, such indications will only be one input into the mobile
   host's decision to register with a new foreign agent, but if
   sufficient lower layer support is available, the mobile host may
   choose to rely exclusively on such support.  In this case, the lower
   layers in the mobile host should be able to reliably indicate that
   the mobile host has moved.  Reliable in this context means that
   a lower layer should never fail to indicate a movement that has
   occurred, but may occasionally indicate movement has occurred when it
   has not.

   After receiving an indication of movement from lower network layers,
   the mobile host may attempt to confirm that its current foreign
   agent is no longer available, either by attempting to re-register
   with the foreign agent or by sending the foreign agent a number of
   unicast Agent Solicitation messages, before attempting to identify
   and register with a new foreign agent.

   If the mobile host is not currently registered with any foreign
   agent, a lower layer indication should cause the mobile host to
   reset any back-off it had been using in its transmission of Agent
   Solicitation messages.

   Finally, a mobile host may determine that it has moved and that its
   current foreign agent is no longer available by waiting until the
   mobile host's next scheduled re-registration with this foreign agent.
   However, this method may result in a long delay before the movement
   is detected and thus may create an extended break in communications.
   Therefore, this last method should be used only in conjunction with
   one or both of the other methods for movement detection.












Johnson, Myles, Perkins         Expires 14 August 1994         [Page 23]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


8. Registration Procedures

   Once a mobile host has identified a potential foreign agent with
   which to register, the mobile host may initiate registration with
   that foreign agent by sending a Registration Request message to
   it.  The mobile host must also register with its home agent when
   registering with a new foreign agent, to ensure that its home agent
   always knows the mobile host's current binding.

   This section describes the procedures required for a mobile host to
   register with a foreign agent and with the mobile host's home agent.


8.1. Overview of Initial Registration Procedures

   When a mobile host registers with a foreign agent and with its
   home agent, the mobile host sends a Registration Request message
   (Section 13.3) to the foreign agent, with both the Foreign Agent (F)
   Home Agent (H) bits set and the corresponding fields filled in.  If
   the foreign agent accepts the request, it passes the request on to
   the mobile host's home agent using a Registration Request message
   with only the Home Agent (H) bit set and the corresponding fields
   filled in.  The home agent responds to the foreign agent with a
   Registration Reply message (Section 13.4) with the Home Agent (H) bit
   set and the corresponding fields filled in.  When the foreign agent
   receives the Registration Reply message from the home agent, the
   foreign agent replies to the mobile host with a Registration Reply
   message with both the Foreign Agent (F) and Home Agent (H) bits set
   and the corresponding fields filled in.

   The foreign agent may also send an early Registration Reply message
   to the mobile host, before it receives the Registration Reply from
   the home agent, indicating that the foreign agent has accepted the
   registration and that the home agent registration is pending.  Such
   an early reply from the foreign agent has only the Foreign Agent (F)
   bit set and the corresponding fields filled in.  The foreign agent
   also later sends the normal Registration Reply message to the mobile
   host, with both the Foreign Agent (F) and Home Agent (H) bits set and
   the corresponding fields filled in, when it receives the reply from
   the home agent.  Sending this early reply message to the mobile host
   may allow the mobile host to resume normal communication operations
   earlier, although the extra reply packet consumes additional network
   bandwidth on the local link and requires extra processing overhead in
   the mobile host.

   Figure 5 illustrates the normal sequence of packets exchanged when a
   mobile host registers with both a foreign agent and its home agent.




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 24]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      MH                          FA                         HA

       :                           :                          :
       :  Registration Request     :                          :
       :  message (L & H bit set)  :  Registration Request    :
       :-------------------------->:  message (H bit set)     :
       :                           :------------------------->:
       :                           :                          :
       :                           :  Registration Reply      :
       :  Registration Reply       :  message (H bit set;     :
       :  message (L & H bit set;  :  accept or rejected)     :
       :  accepted or rejected)    :<-------------------------:
       :<--------------------------:                          :
       :                           :                          :
       :                           :                          :
       v                           v                          v


              Figure 5: Mobile host registering with both
                    foreign agent and its home agent



8.2. Overview of Re-registration Procedures

   The Registration Reply message from the home agent includes a Home
   Agent Service Lifetime field, and the Registration Reply message
   from a foreign agent includes a Foreign Agent Service Lifetime
   field.  These lifetimes are the periods of time that the home agent
   and foreign agent, respectively, guarantee to maintain the mobile
   host's registration.  The guarantee excludes unexpected outages such
   as failures of the foreign agent or home agent.  A lifetime may be
   specified as being infinite.

   If a mobile host wishes to maintain its registration past the
   lifetimes specified in these replies, it must re-register before the
   registration expires.  The re-registration procedure for a home agent
   is exactly the same as the initial registration procedures described
   in Section 8.1.

   Typically, the Foreign Agent Service Lifetime will be shorter than
   the Home Agent Service Lifetime.  As a result, the mobile host will
   need to re-register with its foreign agent more often than it will
   need to re-register with its home agent.

   A mobile host may re-register with its foreign agent only, without
   needing to interact with its home agent, by sending a Registration
   Request message with only the Foreign Agent (F) bit set and the



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 25]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   corresponding fields filled in.  The foreign agent replies with a
   Registration Reply message with the Foreign Agent (F) bit set and the
   corresponding fields filled in.


8.3. Retransmissions

   It is possible that a Registration Request messages or Registration
   Reply messages may be lost, particularly on a wireless link between a
   mobile host and its foreign agent.  Thus, a mobile host may continue
   to periodically retransmit a Registration Request message until it
   has received a corresponding Registration Reply message.

   The foreign agent or home agent may receive a duplicate Registration
   Request message due to these retransmissions (or possibly due to
   other behavior within the network).  A duplicate Registration Request
   message can be detected by comparing the Registration Sequence Number
   with the sequence number stored in the visitor list or location
   cache for the sending mobile host.  When a duplicate Registration
   Request message is received, a Registration Reply message should be
   returned using the information about the registration maintained in
   the visitor list or location cache.  In particular, if a foreign
   agent receives a duplicate of the Registration Request from a mobile
   host, while the foreign agent is still waiting for the Registration
   Reply from the home agent, the foreign agent should return an early
   Registration Reply message to the mobile host, as described in
   Section 8.1, indicating that the registration has been accepted by
   the foreign agent and that the registration with the home agent is
   pending.

   When a mobile host is attempting an initial registration with either
   a foreign agent or with the mobile host's home agent, the time
   between retransmissions should incorporate a back-off strategy to
   avoid flooding the network with Registration Request messages.

   If a mobile host fails to receive a reply from a foreign agent after
   a configured period of time, the mobile host may attempt to identify
   and register with another foreign agent.  If no other foreign agents
   are available, the mobile host should continue to back-off in its
   Registration Request message retransmissions to the foreign agent.

   If a mobile host fails to receive a reply from its home agent after
   a configured period, the mobile host may attempt to identify and
   register with another foreign agent.  An alternative foreign agent
   might have a better path through the network to the mobile host's
   home agent.  If no other foreign agents are available, the mobile
   host should continue to back-off in its Registration Request message
   retransmissions.



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 26]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   When a mobile host is attempting to re-register with a foreign agent
   or with its home agent, the time between retransmissions may decrease
   down to a configured minimum period.  However, once a registration's
   Service Lifetime has expired the mobile host shall restart the
   registration procedures.


8.4. Registration Request Message Fields

   All Registration Request messages, regardless of whether they are
   from a mobile host to a foreign agent or from a foreign agent to a
   home agent, contain at least the following fields:

    -  The Foreign Agent (F) bit indicates whether the Registration
       Request message is requesting registration with a foreign agent.
       If this bit is set, the message contains the fields applicable to
       registering a mobile host with a foreign agent.

    -  The Home Agent (H) bit indicates whether the Registration Request
       message is requesting registration with the mobile host's home
       agent.  If this bit is set, the message contains the fields
       applicable to registering the mobile host with its home agent.

    -  The Notify (N) bit indicates whether the Registration Request
       message is requesting this foreign agent to notify the mobile
       host's previous foreign agent of its new binding, as described
       by the Previous Foreign Agent Address, Previous Foreign Agent
       Authenticator, and Previous Foreign Agent Service Lifetime fields
       of the Registration Request message.  The N bit may be set only
       when the Foreign Agent (F) bit is also set.  If this bit is set,
       the message contains the fields applicable to notifying the
       mobile host's previous foreign agent.

    -  If the Private (P) bit is set, the binding for this mobile host
       must be kept private and may not be advertised to systems other
       than this mobile host's home agent and current foreign agent.  If
       the Private (P) bit is clear, this binding may be advertised as
       needed to other systems.

    -  The Home Address field always contains the home address of the
       mobile host that is requesting registration.

    -  The Registration Sequence Number field contains the mobile host's
       current Registration Sequence Number.  The Registration Sequence
       Number is incremented by the mobile host each time it attempts to
       register or re-register with a foreign agent.





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 27]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


    -  When a mobile host sends a Registration Request message to a
       foreign agent, the Agent Address field contains that foreign
       agent's address on the local network.  This field is used by
       the foreign agent to determine through which of its network
       interfaces the mobile host is accessible.

       When a foreign agent sends a Registration Request message to a
       home agent, the Agent Address field contains the care-of address
       that the foreign agent is offering to the mobile host.


8.5. Registration Reply Message Fields

   All Registration Reply messages, regardless of whether they are from
   a foreign agent to a mobile host or from a home agent to a foreign
   agent, contain at least the following fields:

    -  The Foreign Agent (F) bit indicates whether the Registration
       Reply message contains a response from a foreign agent.  If
       this bit is set, the message contains the fields applicable to
       a response from attempting to register the mobile host with a
       foreign agent.

    -  The Home Agent (H) bit indicates whether the Registration Reply
       message contains a response from the mobile host's home agent.
       If this bit is set, the message contains the fields applicable to
       a response from attempting to register the mobile host with its
       home agent.

    -  The Notify (N) bit indicates whether the Registration Reply
       message contains an acknowledgement from the mobile host's
       requested notification to its previous foreign agent.  If this
       bit is set, the message contains the fields applicable to this
       acknowledgement.

    -  The Reply Status field contains a code indicating the result
       of the registration request.  A value with the high bit clear
       indicates success.  Other values indicate rejection, possibly
       including a reason.  The specific Reply Status codes are
       specified in Section 13.4.

    -  The Home Address field contains the same value as that in the
       corresponding Registration Request message.

    -  The Registration Sequence Number field normally contains the same
       value as that in the corresponding Registration Request message.





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 28]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


       The only exception is when a home agent rejects a registration
       because the Registration Sequence Number is too low.  In this
       case, the Registration Sequence Number field contains the value
       of an acceptable Registration Sequence Number.

    -  The Agent Address field contains the care-of address that a
       foreign agent is offering the mobile host.

    -  The Previous Foreign Agent Authenticator field contains the
       authenticator value received by the foreign agent in the Binding
       Acknowledge message from the mobile host's previous foreign
       agent.  The mobile host must perform the necessary validation of
       this authenticator value.


8.6. Foreign Agent Registration

   This section describes the interaction required between a mobile host
   and a foreign agent for registering the mobile host with this foreign
   agent.

   The procedures defined here assumes that the foreign agent is
   not also the mobile host's home agent; this case is discussed in
   Section 8.8.


8.6.1. Sending the Registration Request Message

   When a mobile host wants to register with a foreign agent, the mobile
   host sends a Registration Request message to the foreign agent.  This
   Registration Request message must have the Foreign Agent (F) bit set
   and must contain the following fields in addition to those described
   in Section 8.4:

    -  The Foreign Agent Service Lifetime field indicates the maximum
       time that the mobile host would like this registration with the
       foreign agent to remain valid.  The value chosen determines
       the maximum time communications with the mobile host might be
       disrupted if the mobile host reboots and loses all knowledge of
       the foreign agents with which it was previously registered.

    -  The Foreign Agent Authenticator field specifies a 32-bit random
       number, chosen by the mobile host, which the foreign agent may
       later use to authenticate any future Binding Notify messages from
       this mobile host concerning this binding.  This authenticator
       allows a mobile host to quickly notify its previous foreign
       agents that it has moved and to possibly provide them with its
       new binding.



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 29]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


       This authenticator also allows the mobile host to authenticate a
       reply from its foreign agent.  A reply is authenticated if the
       Authenticator field in the reply is the same as that sent in the
       Foreign Agent Authenticator field in the corresponding request.

   The Registration Request message is sent by the mobile host to the
   Source Address from the Agent Advertisement message received from
   the foreign agent, which may be different from the care-of address
   provided by that foreign agent in the Agent Advertisement message.


8.6.2. Foreign Agent Processing of Registration Request

   When a foreign agent receives a Registration Request message with
   the Foreign Agent (F) bit set, indicating that a mobile host is
   requesting registration, it must first decide whether or not to
   accept the request.  The foreign agent may use any reasonable
   criteria.  For example, a foreign agent might refuse to register a
   new mobile host unless the Registration Request message also includes
   a request to register with the mobile host's home agent as described
   in Section 8.7.4.  The foreign agent might also need to authenticate
   the mobile host for charging purposes using a separate protocol.
   Applications such as this are beyond the scope of this document.

   If the foreign agent decides not to accept the registration request
   from the mobile host, the foreign agent must send a Registration
   Reply message to the mobile host; if the foreign agent instead
   accepts the registration request, it may optionally send an early
   Registration Reply message to the mobile host, as described in
   Section 8.1.  This Registration Reply from the foreign agent has
   the Foreign Agent (F) bit set and contains the following fields in
   addition to those described in Section 8.5:

    -  The Foreign Agent Service Lifetime field specifies the length of
       time for which the foreign agent will retain this registration
       for the mobile host.  The Foreign Agent Service Lifetime
       field should normally be less than or equal to the Foreign
       Agent Service Lifetime field in the registration request.  The
       exception is discussed in Section 8.8.  If the foreign agent
       rejected the registration request, the Foreign Agent Service
       Lifetime field is set equal to zero.

    -  The Foreign Agent Authenticator field is set to the same value as
       the foreign agent Authenticator field in the Registration Request
       message.

   The foreign agent sends the Registration Reply message to the mobile
   host using the network interface from which the corresponding request



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 30]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   was received.  The MAC address used should be the same as the source
   MAC address from the corresponding request.  All future packets sent
   to the mobile host during the current registration should also use
   this MAC address.


8.6.3. Foreign Agent Registration Operations

   When a foreign agent decides to accept a mobile host's request
   to register, the foreign agent creates or updates a visitor list
   entry for the mobile host.  A visitor list entry for a mobile host
   indicates that the mobile host may be contacted directly on a local
   network interface.  The particular interface was indicated by the
   Agent Address field from the Registration Request message.

   Initially, the visitor list entry for this mobile host is marked
   as unauthenticated, which means that the visitor list entry may be
   used only to forward packets that are tunneled to the foreign agent.
   Under the weak security model, it is assumed that only systems that
   have authenticated bindings for the mobile host will tunnel packets
   to the foreign agent.

   A visitor list entry may only be considered to be authenticated and
   thereafter used to forward non-tunneled packets if the foreign agent
   authenticates the identity of the mobile host with the mobile host's
   home agent.  The procedures to authenticate a mobile host's identity
   are discussed in Section 4.2.2.

   A visitor list entry may be marked to be timed out after the period
   of time specified in the Foreign Agent Service Lifetime field sent in
   the Registration Reply message.  Only by re-registering can a mobile
   host avoid the foreign agent timing out and deleting the visitor list
   entry for the mobile host.

   A visitor list entry is tagged with the Foreign Agent Authenticator
   sent to the foreign agent in the Registration Request message.  If a
   notification that the mobile host has moved is subsequently received
   containing the same authenticator, the notification is authenticated
   and the appropriate actions taken, as described in Section 9.

   A visitor list entry is also tagged with the Private (P) bit from
   the Registration Request message.  If the Private (P) bit is set,
   the foreign agent must must keep the mobile host's binding private
   and may not advertise this binding to other systems.  In this case,
   the foreign agent must respond to any request for the mobile host's
   binding by indicating that the mobile host is connected to its home
   network.  This procedure is described fully in Section 10.2.




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 31]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   The mobile host's Registration Sequence Number is also stored with
   its visitor list entry.  The mobile host's Registration Sequence
   Number is used to sequence Binding Notify messages at a foreign
   agent.

   If the Notify (N) bit of the Registration Request message is set,
   the mobile host is requesting this new foreign agent to notify its
   previous foreign agent of the mobile host's new binding.  The address
   of the previous foreign agent is specified in the Previous Foreign
   Agent Address field of the message, and the authenticator value to
   be used in notifying that agent is specified in the Previous Foreign
   Agent Authenticator field.  The service lifetime for the mobile
   host's registration with that previous foreign agent is specified in
   the Previous Foreign Agent Service Lifetime field.  After deciding
   to accept the registration request from the mobile host, this new
   foreign agent must attempt to notify the previous foreign agent of
   the mobile host's new binding using the Binding Notify message, as
   described in Section 9,


8.6.4. Mobile Host Processing of Registration Reply

   When a mobile host receives a Registration Reply message with
   the Foreign Agent (F) bit set, it must confirm that this reply
   corresponds to an outstanding Registration Request message that it
   has sent.  This process includes checking that the Home Address
   field, the Registration Sequence Number field and the foreign agent
   Authenticator field are the same as that from a previous request.  In
   addition, the Registration Sequence Number field must be the same as
   the mobile host's current Registration Sequence Number.

   If the Notify (N) bit is set in the Registration Reply message, the
   mobile host must check the Previous Foreign Agent Authenticator value
   returned in the message.  If the authenticator matches the value for
   that previous foreign agent stored in the mobile host's previous
   foreign agent list, the mobile host should delete this entry from its
   list, as described in Section 9.2.

   If the Registration Reply message indicates that the request was
   accepted by the foreign agent, the mobile host clears its routing
   table except for a single default route entry pointing to the foreign
   agent, as specified by the Source Address field from the Registration
   Reply message.  The foreign agent thus acts as the mobile host's
   default router.

   The mobile host may choose to commence sending data packets
   immediately using the foreign agent as its default router, or it may




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 32]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   choose to delay sending data packets until it has confirmed that it
   also has a valid registration with its home agent (Section 8.7.4).

   The Foreign Agent Service Lifetime field in the Registration Reply
   message is used to time out the registration with the foreign agent.
   Assuming that the mobile host wants to maintain a registration with
   this foreign agent, it may attempt to re-register with the foreign
   agent before the lifetime expires.  If the mobile host choses not
   to re-register with this foreign agent or is unable to do so before
   the registration expires, it must remove the default route to this
   foreign agent and assume that it is de-registered after this lifetime
   has expired.  The mobile host may then attempt to discover a new
   foreign agent, as described in Section 7.

   If the Registration Reply message indicates that the registration
   request was rejected, the mobile host continues to attempt to
   discover and register with foreign agents.  The mobile host may also
   start recovery procedures, depending on the reject Reply Status code.
   The mobile host should back-off in its attempts to register with
   foreign agents that continually reject registration attempts.


8.7. Home Agent Registration

   This section describes the interaction between a mobile host, a
   foreign agent, and the mobile host's home agent for registering the
   mobile host with its home agent.

   The procedures defined here assume that the foreign agent is not also
   the mobile host's home agent; this case is discussed in Section 8.8.


8.7.1. Sending the Registration Request Message

   When a mobile host wants to register with a foreign agent and with
   its home agent, the mobile host sends a Registration Request message
   to the foreign agent.  This Registration Request message must have
   the Foreign Agent (F) and Home Agent (H) bits set and must contain
   the following fields in addition to those described in Section 8.4
   and Section 8.6.1:

    -  The Home Agent Service Lifetime field.  indicates the maximum
       time that the mobile host would like this registration with
       the home agent to remain valid.  The time chosen determines
       the maximum time communications with the mobile host might be
       disrupted if the home agent reboots and forgets the location of
       the mobile host.  This value also represents the maximum time the




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 33]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


       home agent may tunnel packets to a foreign agent that has failed
       if the mobile host does not re-register.

    -  The Home Agent Password is used by the home agent to authenticate
       the mobile host.  The contents of the Home Agent Password are not
       specified in this document, but will usually be based on a secret
       that the mobile host shares with its home agent.

    -  The Home Agent Address field is set to mobile host's configured
       home agent address.

   The Registration Request message is sent to the foreign agent in the
   same manner as that described in Section 8.6.1.


8.7.2. Foreign Agent Processing of Registration Request

   When a foreign agent receives a Registration Request message from a
   mobile host with the Foreign Agent (F) and Home Agent (H) bits set,
   it first decides whether to accept the foreign agent registration
   request as described in Section 8.6.2.

   Assuming that the request is accepted, the foreign agent then sends
   the Registration Request message to the mobile host's home agent at
   the address specified in the Home Agent Address field, after changing
   the following fields in the message:

    -  The Foreign Agent (F) bit is cleared and the corresponding fields
       removed.

    -  The Agent Address field is set equal to the care-of address that
       the foreign agent is offering the mobile host.


8.7.3. Home Agent Processing of Registration Request

   When a home agent receives a Registration Request message with
   the Home Agent (H) bit set and the Foreign Agent (F) bit cleared,
   indicating that a mobile host is requesting registration with this
   home agent, the home agent must first decide whether or not to accept
   the request.  The home agent may use any reasonable criteria in this
   decision.  However, the home agent must minimally check that:

    -  it is configured to serve the mobile host as its home agent
       (i.e., the mobile host is listed in the home agent's home list),
       and





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 34]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


    -  the Registration Sequence Number field is greater (modulo 2^32)
       than any previous Registration Sequence Number received from this
       mobile host.

   Once the home agent decides whether or not to accept the registration
   request from the mobile host, the home agent sends a Registration
   Reply message to the foreign agent serving the mobile host in this
   registration.  This Registration Reply message must have the Home
   Agent (H) bit set, and must contain the following fields in addition
   to those described in Section 8.5:

    -  The Home Agent Service Lifetime field specifies the length of
       time for which the home agent will retain this a registration for
       the mobile host.  The Home Agent Service Lifetime field should
       normally be less then or equal to the Home Agent Service Lifetime
       field in the registration request.  If the home agent rejected
       the registration request, the Home Agent Service Lifetime field
       is set to zero.

    -  The Home Agent Password is used by the mobile host to
       authenticate the home agent's reply.  The contents of the Home
       Agent Password are not specified in this document, but will
       usually be based on a secret that the mobile host shares with its
       home agent.

   The home agent sends the Registration Reply message to the foreign
   agent specified in the Agent Address field of the Registration
   Request message.


8.7.4. Home Agent Registration Operations

   When a home agent decides to accept a mobile host's registration
   request, the home agent creates or updates a location cache entry for
   the mobile host, unless the home agent and the foreign agent with
   which the mobile host is registering are located in the same system.
   The location cache entry records the mobile host's Registration
   Sequence Number and the binding to the mobile host's current foreign
   agent.  A home agent must function as a cache agent for at least the
   mobile hosts it serves as a home agent.  This location cache entry
   is marked to be deleted after the Home Agent Service Lifetime period
   included in the Registration Reply message.  The mobile host must
   re-register within this time in order to retain its registration with
   its home agent.

   If a home agent does not have a location cache entry for a mobile
   host, the home agent should assume that the mobile host is connected
   to its home network, unless the home network is a virtual network.



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 35]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   If the mobile host's home network is a virtual network, the home
   agent should assume that mobile host is unreachable.


8.7.5. Foreign Agent Processing of Registration Reply

   When a foreign agent receives a Registration Reply message with the
   Home Agent (H) bit set, the foreign agent uses its visitor list to
   pass the reply to the mobile host specified in the Home Address field
   of the reply message.  If no visitor list entry exists for the mobile
   host, the reply message is instead discarded by the foreign agent.


8.7.6. Mobile Host Processing of Registration Reply

   When a mobile host receives a Registration Reply message with the
   Home Agent (H) bit set, the mobile host must first confirm that this
   reply corresponds to an outstanding Registration Request message sent
   by this mobile host.  This process includes checking that the Home
   Address field and the Registration Sequence Number field are the same
   as that from a previous request.  The mobile host must also ensure
   that the contents of the Home Agent Password are acceptable and that
   the Registration Sequence Number field is equal to the mobile host's
   current Registration Sequence Number.

   If the Reply Status field indicates the registration request was
   accepted, the mobile host is now registered with its home agent for
   the period specified in the Home Agent Service Lifetime field.

   If the Reply Status field indicates the registration request was
   rejected, the mobile host may attempt recovery procedures, depending
   on the value of the Reply Status code.  In particular, if the
   registration was rejected because the Registration Sequence Number
   was too low, the mobile host should reset its Registration Sequence
   Number to be at least that in the reply.  Generally, rejection by
   a mobile host's home agent is a serious problem that may indicate
   configuration difficulties.


8.8. Home Network Registration

   When a home agent is also the mobile host's foreign agent, the
   procedures described in Section 8.7.4 are slightly modified.

   First, the foreign agent does not interact with the mobile host's
   home agent using explicit Registration Request and Registration Reply
   messages, as the foreign agent and the home agent are part of the
   same system.  A combined Registration Reply message is sent by this



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 36]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   home agent/foreign agent to the mobile host, with both the Home Agent
   (H) and Foreign Agent (F) bits set and with the corresponding fields
   for both filled in.

   Second, the home agent/foreign agent may set the Home Agent Service
   Lifetime and Foreign Agent Service Lifetime fields in this combined
   Registration Reply message to the reserved value of 0xffffffff (all
   ones), indicating that this registration has an infinite lifetime and
   will not be deleted by the home agent/foreign agent after any timeout
   period.  The mobile host need not continue to re-register with either
   its home agent or its foreign agent in this case.  The Reply Status
   field in this message should indicate the mobile host is connected to
   its home network.

   Finally, after completing the registration procedure, the mobile host
   should use a routing table appropriate to being connected to its home
   network, rather than having only a single default route through its
   foreign agent.


8.9. De-registration

   It is desirable that a mobile host de-registers from a foreign
   agent and from its home agent before it moves, in order to avoid
   any packets being lost during the period before the mobile host has
   registered with a new foreign agent.

   Unfortunately, the mobile host may be unable to explicitly
   de-register before it moves in some cases, since by the time the
   mobile host knowns it has moved, it is too late to perform any
   de-registration procedures, for example because it is then no longer
   in transmission range of its previous foreign agent.

   Nevertheless, this section describes two methods for explicit
   de-registration to occur.


8.9.1. Mobile Host Initiated De-registration

   A mobile host that is registered with a foreign agent or with its
   home agent may wish to de-register explicitly from those systems
   before it moves to a new location.

   A mobile host may explicitly de-register from foreign agent or a home
   agent by successfully registering with the foreign agent or home
   agent respectively with a proposed service time of zero.





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 37]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   If a mobile host requires confirmation of a home agent
   de-registration request, it must ensure that it does not
   de-register from its foreign agent until the confirmation is received
   from the home agent.  Otherwise, the foreign agent will not have a
   visitor list entry that allows it to deliver the reply from the home
   agent to the mobile host.


8.9.2. Foreign Agent Initiated De-registration

   A foreign agent may de-register all the mobile hosts registered
   with it by changing the Incarnation Number that the foreign agent
   advertises in the Agent Advertisement messages that it sends.  Upon
   receiving an Agent Advertisement message from its current foreign
   agent (for example, from the foreign agent's periodic multicast of
   this message), a mobile hosts registered with this foreign agent must
   consider itself to be immediately de-registered and may restart the
   registration procedure.

   This mechanism is particularly useful to handle the case when a
   foreign agent reboots and forgets which mobile hosts that were
   registered with it prior to its reboot.





























Johnson, Myles, Perkins         Expires 14 August 1994         [Page 38]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


9. Notifying Previous Foreign Agents

   When a mobile host registers with a new foreign agent, it is
   important to notify any previous foreign agents that might still
   have bindings for the mobile host in their visitor list.  Otherwise,
   there is a danger packets will be mis-delivered or lost for up to the
   timeout of the registration with the previous foreign agent.

   Additionally, if the previous foreign agent is also a cache agent,
   this cache agent may create a location cache entry for the mobile
   host to ensure continued close to optimal routing of packets to the
   mobile host.

   This section describes the mechanisms used in notifying a mobile
   host's previous foreign agents.


9.1. Previous Foreign Agent List

   A mobile host must maintain in a "previous foreign agent list" the
   identity of any previous foreign agents with which it has registered
   or attempted to register, which may possibly still consider the
   mobile host to be registered with it.

   When a mobile host begins a registration attempt with a foreign
   agent, it must create an entry for this foreign agent in its previous
   foreign agent list.  This entry must include the address of the
   foreign agent (the Agent Address to which it sent the Registration
   Request message), the Foreign Agent Authenticator value sent in that
   Registration Request message, and the Foreign Agent Service Lifetime
   value sent in the message.

   When a mobile host receives a Registration Reply from a foreign agent
   indicating that the foreign agent has accepted its registration, the
   mobile host must change the entry in its previous foreign agent list
   for this foreign agent.  The foreign agent's address in the entry
   must be set to the Care-of Address offered by the foreign agent, and
   the Foreign Agent Service Lifetime must be set to the value returned
   in the message by the foreign agent.

   An entry in this list may be deleted when the mobile host explicitly
   de-registers from a foreign agent and receives a Registration Reply
   message from the foreign agent indicating that the foreign agent has
   accepted its de-registration.  An entry in this list may also be
   deleted when the mobile host receives an acknowledgement that the
   foreign agent has received a Binding Notify message giving the mobile
   host's new binding.  Finally, an entry can be removed from this list
   after the mobile host can be sure of the expiration of the Foreign



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 39]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   Agent Service Lifetime period in this list entry.  If the mobile host
   completed registration with this foreign agent, the timeout period
   should begin after the mobile host receives the Registration Reply
   message from this foreign agent; if the mobile host attempted to
   register with this foreign agent but received no reply, the timeout
   period should begin after the mobile host stops retransmitting
   Registration Requests to this foreign agent.

   Generally, the previous foreign agent list will have only one entry,
   unless communication or system failures have prevented notifying
   some previous foreign agents or the mobile host has been moving very
   quickly.  When a mobile host registers with a new foreign agent, it
   may request that foreign agent to attempt to notify one previous
   foreign agent of its new binding, as discussed in Section 8.6.3.


9.2. Notification Methods

   When a mobile host registers with a foreign agent, the mobile host
   may request the new foreign agent to notify a previous foreign agent
   of its new binding (Section 8.6.3).  After deciding to accept the
   registration from the mobile host, the new foreign agent should send
   a Binding Notify message to the previous foreign agent specified in
   the Registration Request message, with the Acknowledge (A) bit set
   in the notification message.  If the Private (P) bit was set in the
   Registration Request message from the mobile host, the new foreign
   agent should set the Agent Address field in this Binding Notify
   message to the mobile host's home address; otherwise, the Agent
   Address field should be set to the care-of address supplied by the
   new foreign agent.

   If the Binding Acknowledge message for this notification is received
   by the new foreign agent before it sends the Registration Reply
   message to the mobile host, completing the registration process,
   the foreign agent sets the Notify (N) bit in the Registration
   Reply message and includes the Authenticator value from the Binding
   Notification message in the Previous Foreign Agent Authenticator
   field of the Registration Reply message.  The mobile host must
   perform the necessary validation of this authenticator value, and
   if the authenticator is correct, may then remove the entry for this
   previous foreign agent from its previous foreign agent list.  If the
   Binding Acknowledge message is received by the new foreign agent
   after it sends the Registration Reply message to the mobile host,
   it simply forwards the Binding Acknowledge message to the mobile
   host; the mobile host may then remove this foreign agent from its
   previous foreign agent list.  If the Binding Acknowledge message
   is received by the new foreign agent after the mobile host has
   explicitly de-registered with this foreign agent or this foreign



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 40]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   agent has received a Binding Notify indicating that the mobile host
   has registered with a new foreign agent, the foreign agent discards
   the Binding Acknowledge message.

   All other necessary notifications to any previous foreign agents are
   the responsibility of the mobile host itself.  If, for example, a
   mobile host attempts to register with several foreign agents before
   successfully registering with a new foreign agent, the mobile host
   must add each of these attempted registrations to its previous
   foreign agent list.  The Registration Request message only allows the
   mobile host to request its new foreign agent to notify one of these
   previous foreign agents, since a mobile host will usually only have
   one previous foreign agent.

   For each of the other entries in its previous foreign agent list,
   the mobile host must send a Binding Notify message to that foreign
   agent to perform the notification.  The mobile host should set the
   Acknowledge (A) bit in each of these Binding Notify messages, and
   may remove that entry from its previous foreign agent list when the
   corresponding Binding Acknowledge message is received.


9.3. Binding Notify Message

   The Binding Notify message (Section 13.6) is used to notify previous
   foreign agents of a mobile host's new binding after it has moved.
   When used for this purpose, the message contains the following
   fields:

    -  The Private (P) bit is either set or cleared depending on whether
       the mobile host wants to keep its binding private and to disallow
       advertising this binding to other systems.

    -  The Acknowledge (A) bit is set indicating that an acknowledgement
       is required.

    -  The Binding Present (B) bit is set indicating that a binding is
       included in the message.

    -  The Home Address field contains the mobile host's home address.

    -  The Authenticator field contains the authenticator that the
       mobile host sent to the previous foreign agent when registering
       with it.

    -  The Registration Sequence Number field contains the mobile host's
       current Registration Sequence Number.




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 41]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


    -  If the mobile host wants to reveal its new binding to the
       previous foreign agent, the Agent Address field contains the
       care-of address provided by the mobile host's current foreign
       agent.  Otherwise, the Agent Address field contains the mobile
       host's home address.

    -  If the mobile host wants to reveal its new binding to the
       previous foreign agent, the Service Lifetime field contains the
       maximum time, in tenths of a second, that the previous foreign
       agent may keep this binding without reconfirming it.  Otherwise,
       the Service Lifetime field is set to zero.


9.4. Previous Foreign Agent Operations

   When a foreign agent receives a Binding Notify message with the
   Binding Present (B) bit set, the foreign agent first ensures that
   it has a visitor list entry for the mobile host specified in the
   Home Address field, and that the Authenticator field is equal to
   the authenticator kept with this visitor list entry.  If both of
   these condition are met, the Binding Notify message is authenticated
   and may be used to modify the foreign agent's visitor list.  If the
   foreign agent also functions as a cache agent, the Binding Notify
   message may be used to modify the foreign agent's location cache.

   If the Registration Sequence Number field is greater than the
   Registration Sequence Number kept with the visitor list entry, the
   visitor list entry is deleted.  Otherwise, the Binding Notify message
   is ignored.

   If the foreign agent also functions as a cache agent and the visitor
   list entry that was deleted was marked as authenticated, then a
   location cache entry may be created that indicates that the mobile
   host is now registered with the foreign agent specified in the Agent
   Address field.  This entry should be marked to timeout after the
   minimum of the Service Lifetime specified in the Binding Notify
   message and the remaining time left before the original registration
   would have expired.  However, if the Agent Address field in the
   Binding Notify message is equal to the mobile host's home address,
   then no location cache entry is created.

   The Registration Sequence Number field is stored with the location
   cache entry.  The location cache entry is marked to be timed out
   after a period no longer than that specified in the Service Lifetime
   field and the time left until the visitor list would have timed out.
   The location cache entry is also tagged with the Private (P) bit from
   the Binding Notify message.




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 42]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


9.5. Binding Acknowledge Message

   If the Acknowledge (A) bit was set in the Binding Notify message, the
   foreign agent must send a Binding Acknowledge message to acknowledge
   receipt of the Binding Notify message.  This acknowledgement is sent
   even if the foreign agent does not accept the Binding Notify message
   because it is not authenticated.  The Binding Acknowledge message
   contains the following fields:

    -  The Home Address field contains the same value as the Home
       Address field in the Binding Notify message.

    -  The Registration Sequence Number field contains the same value
       as the Registration Sequence Number field in the Binding Notify
       message.

    -  The Authenticator field contains the same value as Authenticator
       field in the Binding Notify message.

   The destination address of the Binding Acknowledge message should
   be set to the source address of the Binding Notify message being
   acknowledged.


9.6. Mobile Host Operations

   When a mobile host receives a Binding Acknowledge message, the mobile
   host deletes any entry in its previous foreign agent list with the
   same Home Address, Registration Sequence Number, and Authenticator as
   those received in the acknowledgement.


9.7. Retransmissions

   It is possible that Binding Notify messages or Binding Acknowledge
   messages used in the procedures described above might be lost,
   particularly on a wireless link between a mobile host and its foreign
   agent.

   A mobile host should continue to periodically retransmit a Binding
   Notify message corresponding to each entry in its previous foreign
   agent list that has not timed out or been deleted.  To avoid flooding
   the network with Binding Notify messages, these retransmissions by
   the foreign agent and mobile host should be scheduled according to
   some back-off strategy.






Johnson, Myles, Perkins         Expires 14 August 1994         [Page 43]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


10. Other Management Procedures

   The IMHP management philosophy is to distribute bindings only to
   systems as required.  Generally, this means that only when a system
   determines that another system might be holding an incorrect binding
   for a mobile host should that system send it a notification advising
   it to acquire a current binding.  However, a mobile host or its new
   foreign agent usually attempts to notify the mobile host's previous
   foreign agents that the mobile host has moved, and a mobile host
   always notifies its home agent that it has moved.

   In terms of the forwarding rules defined in Section 6, a cache agent
   should send a notification to the source of any packet received
   that the cache agent subsequently tunnels using a location cache
   entry.  Similarly, a cache agent or a foreign agent should send
   a notification to the source of any tunnel that is addressed to
   the system if it is unable to forward the packet except by using a
   special tunnel.  In both cases, the source of the packet or tunneled
   packet has either an incorrect or no binding cached for a mobile
   host.

   It is important that the network not be flooded with notifications.
   Thus, the frequency of notifications sent by one system to another
   system concerning the binding of a particular mobile host must be
   limited.

   Any systems that do not implement IMHP will ignore any notifications
   that they receive.  Even those systems that do implement IMHP may be
   limited in the number of bindings they can cache or the speed with
   which they can process notifications.  Therefore, a system must use
   a back-off algorithm to slowly reduce the frequency of notifications
   it sends another system concerning the binding of a particular
   mobile host when it appears that the other system is ignoring the
   notifications.

   In the unlikely event that two or more cache agents have location
   cache entries that form a routing loop for a particular mobile host,
   the mechanisms defined above ensure that the loop is quickly broken.

   An IMHP management packet should never give rise to other IMHP
   management packets.


10.1. Notifying Other Entities

   In addition to being used to notify previous foreign agents that
   a mobile host has moved, Binding Notify messages may also be used




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 44]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   to notify another system that it should attempt to obtain a new
   authenticated binding for a mobile host.

   In particular, if a system tunnels a packet to another system, and
   the second system is not serving the mobile host as its foreign
   agent, the second system should send a Binding Notify message to the
   first system.  Alternatively, if a cache agent receives a regular IP
   packet and has to tunnel the packet to a destination mobile host, the
   cache agent should also send a Binding Notify Message to the source
   of the packet.

   A system must limit the frequency with which it sends Binding Notify
   messages to another system concerning a particular mobile host, in
   order to avoid flooding the network.  It is thus desirable that a
   system backs off transmitting Binding Notify messages if it appears
   they are having no effect.  The particular back-off algorithm used by
   any system is a configuration parameter of that system.

   An IMHP management packet should never give rise to other IMHP
   management packets.  In particular, an IMHP management packet should
   not cause a Binding Notify message to be generated.

   In the two cases described above for sending a Binding Notify
   message, the message contains the following fields:

    -  The Acknowledge (A) bit in the Binding Notify message is cleared,
       indicating that no acknowledgement is required.

    -  The Binding Present (B) bit in the Binding Notify message is
       cleared, indicating that no binding is included in the message.

    -  The Home Address field is set to the home address of the
       destination mobile host from the packet that caused the Binding
       Notify message to be sent.

   No binding is included, as the system receiving the Binding Notify
   message generally has no way of authenticating it.  Instead this
   receiving system uses the notification as an indication to use the
   mechanisms described in Section 10.2 to obtain an authenticated
   binding for the mobile host.


10.2. Acquiring Authenticated Mobile Host Bindings

   When a foreign agent registers a mobile host and creates a new
   visitor list entry, the visitor list entry must be marked as
   unauthenticated, as described in Section 8.6.3.  The foreign agent




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 45]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   can only mark the visitor list entry as authenticated when it
   authenticates the identity of the mobile host.

   The foreign agent may attempt to authenticate a visitor list entry
   immediately, or it may wait until it would have used the visitor list
   entry if it had been authenticated.  In many configurations, there is
   no benefit in authenticating visitor list entries.

   When a foreign agent or a cache agent receives a Binding Notify
   message with the Binding Present (B) bit clear, the foreign agent
   or cache agent may use this message as an indication to attempt to
   acquire an authenticated binding for the mobile host.

   In both cases, authentication is achieved by sending the mobile
   host's home agent a Binding Inquire message containing a request for
   the mobile host's binding.  The Binding Inquire message is replied to
   by a Binding Notify message, which provides an authenticated binding
   for the mobile host.

   The authentication must be timed out after a period specified in the
   Binding Notify message.  In the case of a location cache entry, the
   entry must be deleted if the authentication times out.  In the case
   of a visitor list entry, the entry must be marked as unauthenticated
   if the authentication times out.  Authentication timeouts may be
   avoided by reauthenticating the entry before timeout occurs.

   A system must limit the frequency of Binding Inquire messages that
   it transmits, in order to avoid flooding the network.  The maximum
   frequency is a configuration parameter.  If it appears that the
   Binding Inquire messages are being ignored, the system should
   back-off in the rate of their transmission.


10.2.1. Sending a Binding Inquire Message

   The Binding Inquire message used to obtain an authenticated binding
   for a mobile host contains the following fields:

    -  The Routing (R) bit is set to ensure that the Binding Inquire
       message is routed to the mobile host's home network, to be
       processed by either the mobile host itself or by its home agent.

    -  The Home Address field contains the home address of the mobile
       host for which an authenticated binding is requested.

    -  The Authenticator field is set equal to a random number
       chosen by the sending system.  The reply must contain the same
       Authenticator value.



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 46]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


10.2.2. Processing a Binding Inquire Message

   When a home agent or mobile host receives a Binding Inquire Message,
   the home agent or mobile host replies to the system that sent the
   inquiry with a Binding Notify message.  The reply contains either the
   mobile host's current binding or indicates that the mobile host is
   connected to its home network.  The Binding Notify message contains
   the following fields:

    -  The Private (P) bit is set if binding is to remain private and
       may not be advertised to other systems.

    -  The Binding Present (B) bit is always set, as the mobile host or
       its home agent always knows the mobile host's current binding.

    -  The Home Address field contains the same value as the Home
       Address field in the Binding Inquire message.

    -  The Authenticator field contains the same value as the
       Authenticator field in the Binding Inquire message.

    -  The Registration Sequence Number field contains the mobile host's
       current Registration Sequence Number.

    -  The Agent Address field contains the mobile host's home address,
       if the mobile host is connected to its home network, or the
       mobile host's current care-of address provided by a foreign
       agent, otherwise.  However, if the binding is to remain private
       and may not be advertised to other systems, the Agent Address
       field always contains the mobile host's home address.

    -  The Service Lifetime field contains zero, if the mobile host
       is connected to its home network, or the period for which the
       binding contained in the reply is authenticated, otherwise.
       However, if the binding is to remain private and may not be
       advertised to other systems, the Service Lifetime field always
       contains zero.

   The Binding Notify message is sent to the system that sent the
   Binding Inquire message.


10.2.3. Processing the Binding Notify Message

   When a foreign agent or a cache agent receives a Binding Notify
   message with the Binding Present (B) bit set, the foreign agent or
   cache agent must first ensure that the message corresponds to an
   outstanding Binding Inquire message sent by this system, by checking



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 47]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   that the Home Address field and the Authenticator field match those
   is a previous request.  The authenticated message may then be used to
   update a visitor list entry in a foreign agent or a location cache
   entry in a cache agent.

   The following actions occur at a foreign agent for processing an
   authenticated Binding Notify message:

    -  If the Registration Sequence Number field is greater than that
       stored with the visitor list entry for the mobile host, the
       visitor list entry is deleted.

    -  If the Registration Sequence Number field is equal to that stored
       with the visitor list entry for the mobile host and the Agent
       Address field indicates that this foreign agent serves the mobile
       host, the visitor list entry is be marked as authenticated for
       the period specified in the Service Lifetime field.

   The following actions occur at a cache agent for processing an
   authenticated Binding Notify message:

    -  If the Registration Sequence Number field is greater than that
       stored with a location cache entry for the mobile host, the
       location cache entry is deleted.  If the Agent Address field is
       not equal to the Home Address field and the Agent Address field
       does not indicate that the system receiving the reply serves the
       mobile host as a foreign agent, a new location cache entry is
       created that indicates the foreign agent specified in the Agent
       Address field serves the mobile host.  This entry is marked to
       timeout after the period specified in the Service Lifetime field.

    -  If the cache agent does not have a location cache entry for the
       mobile host, the Agent Address field is not equal to the Home
       Address field, and the Agent Address field does not indicate
       that the system receiving the reply serves the mobile host as
       a foreign agent, then the cache agent creates a location cache
       entry that indicates the foreign agent specified in the Agent
       Address field serves the mobile host.  This entry is marked to
       timeout after the period specified in the Service Lifetime field.

    -  If the Registration Sequence Number field is equal to that stored
       with the location cache entry for the mobile host, and the Agent
       Address field indicates the mobile host is served by the same
       foreign agent that is recorded in the existing location cache
       entry, the location cache entry is reauthenticated for the period
       specified in the Service Lifetime field.





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 48]
Internet Draft      Internet Mobile Host Protocol       14 February 1994



11. Packet Transmission Examples

   The following sections describe examples of the actions that the
   various systems (mobile hosts, foreign agents, cache agents, and home
   agents) are required to perform under a range of typical scenarios.

   For simplicity, only the most important packet interactions are shown
   in each example.  In these examples, it is also assumed that mobile
   hosts and foreign agents are always also cache agents.

   In each example, different line styles are used to represent the
   different types of packets, as follows:

      ----   normal IP packets
      ====   tunneled IP packets
      ~~~~   management packets


11.1. Mobile Host to Mobile Host Communications

   This section describes the basic operations when a mobile host (MH1)
   within range of a foreign agent (FA1) having a home agent (HA1)
   wants to communicate with another mobile host (MH2) within range of
   a foreign agent (FA2) having a home agent (HA2).  The operations are
   shown diagrammatically in Figure 6.



        MH1        FA1        HA1            HA2        FA2        MH2

         :          :          :              :          :          :
         :          :          : Registration :          :          :
     1.  :<~~~~~~~~>:<~~~~~~~~>:              :<~~~~~~~~>:<~~~~~~~~>:
         :          :          :              :          :          :
         :          :          :              :          :          :
     2.  :----------:------------------------>:=========>:--------->:
         :          :          :              :          :          :
         :          :          :              :          :          :
     3.  :<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~: Binding  :          :
         :          :          :              : Notify   :          :
         :          :          :              :          :          :
     4.  :==========:===================================>:--------->:
         :          :          :              :          :          :
         :          :          :              :          :          :
         v          v          v              v          v          v


           Figure 6: Mobile host to mobile host communication



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 49]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   The following operations are shown in Figure 6:

    1. MH1 and MH2 both register with their foreign agents (FA1 and FA2,
       respectively) and their home agents (HA1 and HA2, respectively).

    2. Suppose MH1 wants to send a packet to MH2, and MH1 does not have
       a binding cached for MH2.  MH1 transmits the packet using FA1 as
       its default router.  Normal routing mechanisms eventually deliver
       the packet to MH2's home agent (HA2).  H2 uses its location
       cache entry for MH2 to tunnel it to FA2.  When FA2 receives the
       tunneled packet, it decapsulates it and uses its visitor list
       entry for MH2 to deliver the packet to MH2.

    3. When HA2 receives the packet and tunnels the packet, it also
       sends a notification to the source (MH1) advising it to acquire a
       new binding for MH2.  When MH1 receives the notification, it uses
       the methods described in section 10.2 to acquire MH2's current
       binding.

    4. MH1 can then transmit future packets destined to MH2 by
       tunneling them directly to FA2.  A close to optimal route is thus
       established.


11.2. Mobile Host Movement

   The example illustrated in Figure 6 can be extended by considering
   what happens when MH2 moves to a new network.  This scenario is
   illustrated in Figure 7.

   The following operations are shown in Figure 7:

    1. MH2 detects that it is connected to a new network, registers with
       a new foreign agent (FA3), and registers with its home agent
       (HA2).

    2. MH2's new foreign agent (FA3) notifies MH2's previous foreign
       agent (FA2) that MH2 is now registered with FA3.  This
       notification uses the previously negotiated authenticator that
       MH2 established with FA2 when it registered with FA2.

    3. Suppose MH1 wants to send a packet to MH2.  MH1 tunnels the
       packet to FA2, which is where its location cache indicates MH2 is
       currently registered.  FA2 forwards the packet to FA3, using its
       updated location cache.  Finally, FA3 decapsulates the packet for
       final delivery.





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 50]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


       MH1       FA1       HA1       HA2       FA2       FA3       MH2

        :         :         :         :         :         :         :
        :         :         :         :         :         :         :
    1.  :         :         : Regis-  :<~~~~~~~~~~~~~~~~~>:<~~~~~~~>:
        :         :         : tration :         :         :         :
        :         :         :         :         :         :         :
    2.  :         :         :         : Binding :<~~~~~~~>:         :
        :         :         :         :  Notify :         :         :
        :         :         :         :         :         :         :
    3.  :=========:============================>:========>:-------->:
        :         :         :         :         :         :         :
        :         :         :         :         :         :         :
    4.  :<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~: Binding :         :
        :         :         :         :         : Notify  :         :
        :         :         :         :         :         :         :
    5.  :=========:======================================>:-------->:
        :         :         :         :         :         :         :
        :         :         :         :         :         :         :
        v         v         v         v         v         v         v


                     Figure 7: Mobile host movement



    4. FA2 recognizes that MH1 must have an old binding cached for MH2,
       since otherwise MH1 would not have tunneled the packet to FA2.
       FA2 thus sends MH1 a notification advising it to acquire a new
       binding for MH2.

    5. Once MH1 acquires MH2's new binding, it sends future packets
       destined to MH2 by tunneling them to FA3.


11.3. Stationary Host to Mobile Host

   The example illustrated in Figure 6 can be modified by considering
   what happens when the source is a stationary host (denoted SH) that
   does not implement the IMHP protocol.  This scenario is illustrated
   in Figure 8.

   The following operations are shown in Figure 8:

    1. MH2 detects that it is connected to a new network.  MH2 then
       registers with a new foreign agent (FA2) and with its home agent
       (HA2).




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 51]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


               SH             HA2          FA2          MH2

                :              :            :            :
                : Registration :            :            :
            1.  :              :<~~~~~~~~~~>:<~~~~~~~~~~>:
                :              :            :            :
                :              :            :            :
            2.  :------------->:===========>:----------->:
                :              :            :            :
                :              :            :            :
            3.  :<~~~~~~~~~~~~~: Binding    :            :
                :              : Notify     :            :
                :              :            :            :
                v              v            v            v


        Figure 8: Stationary host to mobile host communications



    2. Suppose SH wants to send a packet to MH2.  SH forwards the packet
       to MH2 using normal forwarding rules.  The packet is eventually
       received by HA2, which tunnels it the MH2's known location, FA2.
       FA2 decapsulates the packet and delivers it to MH2.

    3. When HA2 receives the packet from SH, HA2 notifies SH that it
       should attempt to acquire a new binding for MH2.  SH does not
       understand IMHP management packets, and HA2 will eventually back
       off and only send the notifications occasionally.  The packets
       from SH will continue to follow a Triangle Routing path, which is
       likely to be non-optimal.


11.4. Routing Loop Resolution Between Home Agent and Foreign Agent

   It is possible under rare circumstances for location cache
   inconsistencies to occur which IMHP must resolve.  This section
   describes the resolution of the case in which a home agent has
   recorded that a particular foreign agent, FA, is serving a mobile
   host, MH, and yet the foreign agent claims not to serve that mobile
   host.  This scenario is illustrated in Figure 9.

   The following operations are shown in Figure 9:

    1. Assume MH's home agent, HA, has a binding in its location cache
       for MH that indicates FA is MH's current foreign agent.  When HA
       receives a packet for MH it tunnels it to FA.




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 52]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


                          HA             FA

                           :              :
                           :              :
                       1.  :=============>:
                           :              :
                           :              :
                       2.  :<=============: Special
                           :              : tunnel
                           :              :
                           v              v


               Figure 9: Resolution of a lost mobile host



    2. If FA has no record of MH in either its location cache or visitor
       list, it decapsulates the packet and transmits it using a special
       tunnel.  The packet will find its way back to HA, which will then
       detect the loop.  HA drops the packet and may attempt to resolve
       the problem that caused it.


11.5. Routing Loop Resolution Between Cache Agents

   It is also possible under extreme circumstances relating to a faulty
   implementation for two or more cache agents to have location cache
   entries that form a loop for a particular mobile host.

   This example considers the case of three cache agents (CA1, CA2, and
   CA3) that have bindings in their location caches that form a loop
   for a mobile host, MH. The resolution of the loop is illustrated in
   Figure 10.

   The following operations are shown in Figure 10:

    1. Assume CA1, CA2, and CA3 have location cache entries that form a
       loop for MH.  If CA1 tunnels a packet destined for MH to CA2, CA2
       will then tunnel the packet onwards to CA3, which will tunnel the
       packet back to CA1.

    2. The loop is broken by notifications that are sent to the source
       of each tunnel.  Each cache agent that receives the notification
       acquires a new binding for MH, which breaks the loop.






Johnson, Myles, Perkins         Expires 14 August 1994         [Page 53]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


                       CA1        CA2        CA3

                        :          :          :
                        :          :          :
                    1.  :=========>:=========>:
                        :          :          :
                        :          :          :
                        :<====================:
                        :          :          :
                        :          :          :
                    2.  :<~~~~~~~~~:<~~~~~~~~~:
                        :          :          :
                        :          :          :
                        :~~~~~~~~~~~~~~~~~~~~>:
                        :          :          :
                        :          :          :
                        v          v          v


      Figure 10: Resolution of a routing loop between cache agents



12. Other Issues

12.1. Registration on a Home Network

   When a mobile host is connected to its home network and registered
   directly with a foreign agent that is also its home agent, it is
   important that its performance be approximately the same as that
   of an equivalent host that does not implement IMHP.  It is also
   important that any hosts connected to the home network are able to
   communicate with the mobile host regardless of where the mobile host
   is connected.

   When a mobile host is not registered directly with its home
   agent/foreign agent, its home agent must answer any ARP requests for
   the mobile host with the home agent's own MAC address.  This forces
   hosts on the home network to forward packets destined to the mobile
   host to the home agent, which will then tunnel them to the mobile
   host's current location.

   When the mobile host returns to its home network, the mobile host
   should register with the foreign agent that is also its home agent,
   in preference to any other foreign agent.  This rule helps ensure
   optimal routing on the home network, as the home agent/foreign agent
   can deliver packets directly to the mobile host rather than tunneling
   them to another foreign agent on the same network for delivery.



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 54]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   When a mobile host registers with its home agent/foreign agent on
   its home network, the home agent/foreign agent should reply will the
   Foreign Service Lifetime field and Home Service Lifetime field in the
   Registration Reply Message set to the reserved value of 0xffffffff
   (all ones), indicating that this registration has an infinite
   lifetime.  The mobile host thus need only register once with its home
   agent/foreign agent when it returns to its home network.  The Reply
   Status field should also indicate that the mobile host has registered
   with its home agent/foreign agent.

   When a mobile host registers with its home agent/foreign agent on
   its home network, the home agent must stop answering ARP requests
   on the mobile host's behalf.  The mobile host should answer any ARP
   requests, resulting in optimal routing on the home network.  Either
   the home agent or the mobile host must also transmit a gratuitous
   ARP reply on the local network, so that systems on that network will
   begin to associate the mobile host's IP address with the mobile
   host's true MAC address instead of with the MAC address of the home
   agent.

   While on the home network, the movement discovery mechanisms
   described in Section 7.4 continue to operate.  Therefore when no
   lower layer support is available, the home agent/foreign agent must
   continue to transmit regular Agent Advertisement messages.

   When the mobile host subsequently moves away from its home network
   and registers its new binding with its home agent using the
   mechanisms described in Section 8, the home agent must again process
   ARP requests on the mobile host's behalf.  It must also ensure that
   the hosts connected to the home network that have cached the mobile
   host's MAC address delete this cache entry from their ARP caches.

   If all the hosts connected to the home network understand and process
   gratuitous ARPs, then the home agent may transmit a gratuitous ARP
   reply that indicates the mobile host's MAC address is that of the
   home agent.  It is necessary for the gratuitous ARP reply to be
   retransmitted a number of times over a period of time to ensure with
   a high probability that that at least one ARP reply is received
   correctly by each host.  Even if all gratuitous ARPs are lost, most
   ARP caches entries eventually time out.

   In some network configurations, it is possible that a host on a
   mobile host's home network can communicate with the mobile host even
   though the mobile host is not connected to its home network.  It is
   therefore necessary, in these cases, for the home agent to issue the
   gratuitous ARPs every time the mobile host moves to a new foreign
   agent, even though the movement might not involve the home network.




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 55]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   Some existing hosts do not process gratuitous ARPs correctly.  In
   this case, a mobile host should never answer ARP requests for itself.
   On the mobile host's home network, the mobile host's home agent
   should always answer ARP requests for the mobile host with its own
   MAC address.  On other networks, only foreign agents need to send
   packets to the mobile host.  These foreign agents use the MAC address
   that they learn during registration rather than relying on ARP for
   address resolution.


12.2. Location Cache and Visitor List Time Outs

   The location cache time outs used by cache agents and visitor list
   time outs used by foreign agents determine the maximum time of
   disruption if either a foreign agent fails or if a mobile host
   forgets to notify a previous foreign agent about a movement.  As both
   these events are expected to be rare, the time out may be quite long.

   The latter event will usually only occur when a mobile host reboots.
   This effect of a reboot, however, can be eliminated by setting the
   visitor list time out to be equal to the average reboot time of
   mobile host.  Unfortunately, as reboot times decrease, this option
   becomes unattractive.  Another solution is to store the identity of
   previous foreign agents in non volatile memory in the mobile host.


12.3. Popups

   Some areas on the network will not have foreign agents available for
   use.  When this situation arises, it is desirable that the user has
   at least some mobile functionality.  In particular, the user might
   want to keep his IP address.

   A mobile host in this situation may operate as a "popup" [4] in
   order to maintain connectivity.  The popup method as applied to IMHP
   can take one of two forms.  In both forms, the mobile host would
   acquire a local address from a local address server (e.g., a server
   implementing DHCP [2]) and then report the allocated address to its
   home agent as its current foreign agent address.

   In the first form, the mobile host would specify that the home agent
   should not advertise this foreign agent address.  The cost of this
   technique is that routing to the mobile host is always through a home
   agent, which is likely to be non-optimal.

   In the second form, the home agent would be allowed to advertise the
   mobile host's binding based on the allocated address in the same way
   it advertises the mobile host's binding based on a care-of address.



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 56]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   Although this method gives closer to optimal routing of packets, when
   mobile host movement does occur, communication might be lost for up
   to a location cache time out period, as a movement is equivalent to a
   foreign agent failing.

   In both cases, true mobile functionality depends on the ability of
   the mobile host to detect automatically that it has moved.  Without a
   foreign agent this might be difficult.


12.4. Intermediate Cache Agents

   Any system can operate as a cache agent.  This section discusses
   the use of cache agents in intermediate routers.  A cache agent
   functioning in a intermediate router allows packets that it forwards
   from stationary hosts to avoid Triangle Routing, and can also offer
   some routing assistance to mobile hosts.

   An intermediate cache agent may learn about the bindings of mobile
   hosts by examining management packets that it forwards.  The cache
   agent can then acquire acquiring authenticated bindings for these
   mobile hosts in the same way as any cache agent.

   The example illustrated in Figure 8 can be modified as shown in
   Figure 11 if some router near SH (such as SH's first-hop router) is
   capable of serving as a cache agent.

   The following operations are shown in Figure 11:

    1. As in Figure 8.

    2. As in Figure 8.

    3. As in Figure 8.

    4. Suppose a cache agent in some router, CA, examines the
       notification to SH as it forwards it.  After acquiring an
       authenticated binding, CA can use it to tunnel packets that it
       receives destined for MH2 directly to FA2, thus making the route
       closer to optimal.


12.5. Password Algorithms

   IMHP does not specify the way in which the password is chosen for
   use in the Password field in Registration Request and Reply messages
   between a mobile host and its home agent.  However certain issues
   should be noted when selecting an algorithm for choosing a Password.



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 57]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


            SH         CA             HA2        FA2        MH2

             :          :              :          :          :
             :          : Registration :          :          :
         1.  :          :              :<~~~~~~~~>:<~~~~~~~~>:
             :          :              :          :          :
             :          :              :          :          :
         2.  :----------:------------->:=========>:--------->:
             :          :              :          :          :
             :          :              :          :          :
         3.  :<~~~~~~~~~:~~~~~~~~~~~~~~: Binding  :          :
             :          :              : Notify   :          :
             :          :              :          :          :
         4.  :----------:========================>:--------->:
             :          :              :          :          :
             :          :              :          :          :
             v          v              v          v          v


      Figure 11: Stationary host to mobile host communication with
                    cache agent in first-hop router



   A password may simply remain fixed over time and be known by both
   the home agent and a mobile host.  However, such a password may
   eventually be discovered by a malicious system.

   A better password is one that changes over time.  One possibility
   is that the password consists of a random number and an encrypted
   version of that random number.  However, this password is similarly
   open to replay attacks.

   An alternative, is for the password to consist of a monotonically
   increasing sequence number and an encrypted version of the sequence
   number.  In the context of IMHP, the Registration Sequence number is
   suitable and, as it is already carried in the registration packets,
   does not need to be included in the Password.  Replay attacks only
   become possible as the Registration Sequence Number wraps.

   The possibility of replay attacks may be reduced even further by
   again including a random number and an encrypted version of the
   random number in the Password.

   To allow sufficient flexibility in the Password algorithm used, the
   Password is set to be 64 bits in length.





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 58]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


13. IMHP Management Packet Formats

   This section describes the packet formats required to support
   the IMHP management protocol under the weak security model.  All
   IMHP management packets are transmitted as UDP [8] packets using
   destination port ???.

   Each IMHP packet begins with the following common two-octet header:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |R|    Type     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version

         The version number of the protocol in use.  This document
         defines version 1 of the IMHP protocol.

      Routing (R)

         If the Routing (R) bit is set, the packet is forwarded using
         normal IP routing mechanisms only.  Visitor list entries and
         location cache entries must not be used in routing the packet.

         If the Routing (R) bit is clear, the packet may be routed using
         visitor list entries and location cache entries in addition to
         normal routing mechanisms.

         This option is used to force packets addressed to a mobile
         host's IP address to be routed to a mobile host's home network,
         where they will be intercepted by the mobile host's home agent
         when the mobile host is currently away from its home network.

      Type

         The type of the packet, indicating which IMHP operation is
         being performed.  The following Type codes are defined in this
         document:

            0x10 = Agent Advertisement Message
            0x11 = Agent Solicitation Message

            0x20 = Registration Request Message
            0x21 = Registration Reply Message





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 59]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


            0x30 = Binding Inquire Message
            0x31 = Binding Notify Message
            0x32 = Binding Acknowledge Message

   The following sections define the packet formats for each of
   these IMHP management protocol packet types.  The common two-octet
   header described above is included in each of these message format
   descriptions.











































Johnson, Myles, Perkins         Expires 14 August 1994         [Page 60]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


13.1. Agent Advertisement Message

   An Agent Advertisement message is sent by a foreign agent to
   advertise its services on a local network.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |R|    Type     |H|         Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Incarnation Number                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertisement Interval                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Agent Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         An IP address belonging to the interface of the foreign agent
         on which this message is sent.

      Destination Address

         This field should normally be set to the configured Agent
         Advertisement Address for this foreign agent, which may
         be either the reserved "all mobile hosts" address, or the
         limited-broadcast address, 255.255.255.255, although this
         field may also be set to the IP address of an individual host
         connected to the local network.

      Time-to-live

         1

   IMHP fields:

      Version

         1

      Routing (R)

         0





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 61]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      Type

         0x10

      Home Agent (H)

         The Home Agent (H) bit is set to indicate that the foreign
         agent sending this Agent Advertisement message is also acting
         as a home agent and will only accept registration requests for
         mobile hosts that it serves as a home agent.

      Reserved

         Sent as 0; ignored on reception.

      Incarnation Number

         The Incarnation Number field contains the incarnation number of
         the foreign agent sending the Agent Advertisement message.

      Advertisement Interval

         The Advertisement Interval field contains the maximum interval
         at which the foreign agent sends periodic Agent Advertisement
         messages, expressed in tenths of a second.  If a foreign agent
         does not send periodic Agent Advertisements, then this field is
         set to 0.

      Agent Address

         The Agent Address field contains the care-of address that the
         foreign agent is offering for use by mobile hosts.



















Johnson, Myles, Perkins         Expires 14 August 1994         [Page 62]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


13.2. Agent Solicitation Message

   The Agent Solicitation message is used by a mobile host to request
   foreign agents, connected to the same network, to advertise their
   services.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |R|    Type     |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         The Source Address field contains an IP address belonging to
         the interface on which this message is sent.

      Destination Address

         The Destination Address field normally contains the configured
         Agent Solicitation Address of the mobile host, which may be
         either the reserved "all foreign agents" multicast address,
         or the limited-broadcast address, 255.255.255.255, although
         this field may also be set to the IP address of an individual
         foreign agent on the local network.

      Time-to-live

         1

   IMHP fields:

      Version

         1

      Routing (R)

         0

      Type

         0x11






Johnson, Myles, Perkins         Expires 14 August 1994         [Page 63]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      Reserved

         Sent as 0; ignored on reception.
















































Johnson, Myles, Perkins         Expires 14 August 1994         [Page 64]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


13.3. Registration Request Message

   The Registration Request Message is used by a mobile host to register
   with a foreign agent, or by a foreign agent to register a mobile host
   with its home 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |R|     Type    |F|H|N|P|       Reserved        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Home Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Registration Sequence Number                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Agent Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Foreign Agent Service Lifetime (F)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Foreign Agent Authenticator (F)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Home Agent Address (H)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Home Agent Service Lifetime (H)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                      Home Agent Password (H)                  +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Previous Foreign Agent Address (N)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Previous Foreign Agent Authenticator (N)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Previous Foreign Agent Service Lifetime (N)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         The Source Address field contains an IP address belonging to
         the interface on which this message is sent.

      Destination Address

         The Destination Address field contains an IP address of
         the foreign agent or the home agent that is to receive this
         message.



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 65]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      Time-to-live

         The Time-to-live field must be set to 1 when the message is
         from a mobile host to a foreign agent.  Otherwise, it should be
         set to MAXTTL.

   IMHP fields:

      Version

         1

      Routing (R)

         0, except as specified below.

      Type

         0x20

      Foreign Agent (F)

         If the Foreign Agent (F) bit is set, the mobile host is
         requesting registration with a foreign agent.  All Registration
         Request messages sent by a mobile host must have the Foreign
         Agent (F) bit set.

         Fields in the message format above marked (F) are included in
         the packet only when the L bit is set.

      Home Agent (H)

         If the Home Agent (H) is set and the Foreign Agent (F) bit is
         set, the mobile host is requesting registration with a foreign
         agent and with its home agent.

         If the Home Agent (H) is set and the Foreign Agent (F) bit is
         clear, a foreign agent is requesting registration of the mobile
         host with its home agent on behalf of the mobile host.

         Fields in the message format above marked (H) are included in
         the packet only when the H bit is set.

      Notify (N)

         If the Notify (N) bit is set, the mobile host is requesting
         this foreign agent to notify the mobile host's previous foreign
         agent of its new binding, as described by the Previous Foreign



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 66]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


         Agent Address, Previous Foreign Agent Authenticator, and
         Previous Foreign Agent Service Lifetime fields.  The N bit may
         be set only when the Foreign Agent (F) bit is also set.

         Fields in the message format above marked (N) are included in
         the packet only when the N bit is set.

      Private (P)

         If the Private (P) bit is set, this binding must be kept
         private and may not be advertised to systems other than the
         mobile host's home agent and current foreign agent; other
         the mobile host's binding may be advertised as needed to any
         system.

      Reserved

         Sent as 0; ignored on reception.

      Home Address

         The Home Address field contains the home address of the mobile
         host attempting registration.

      Registration Sequence Number

         The Registration Sequence Number field contains the
         Registration Sequence Number of the mobile host attempting
         registration.

      Agent Address

         When the Registration Request message is from a mobile host to
         a foreign agent, the Agent Address field is the same as the
         Destination Address field.

         When the Registration Request message is from a foreign agent
         to home agent, the Agent Address contains the care-of address
         that the foreign agent is providing to the mobile host.

      Foreign Agent Service Lifetime (F)

         The Foreign Agent Service Lifetime field contains the length
         of time, expressed in tenths of a second, that the mobile host
         requests the foreign agent to provide service without requiring
         reregistration.





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 67]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


         A value of zero implies the mobile host is requesting
         de-registration.  The reserved value of 0xffffffff (all ones)
         implies an infinite period.

      Foreign Agent Authenticator (F)

         The foreign agent Authenticator field contains a value, chosen
         by the mobile host, that allows this foreign agent to later
         authenticate any notifications sent by the mobile host that it
         has moved.

      Home Agent Address (H)

         The home agent Address field contains either the mobile host's
         home agent address, or the mobile host's own home address.  In
         the latter case, the Route (R) bit must be set to force the
         Registration Request message to be routed to the mobile host's
         home network.

      Home Agent Service Lifetime (H)

         The Home Agent Service Lifetime field contains the length of
         time, expressed in tenths of a second, that the mobile host
         requests its home agent to provide service without requiring
         reregistration.

         A value of zero implies the mobile host is requesting to
         de-register.  The reserved value of 0xffffffff (all ones)
         implies an infinite period.

      Home Agent Password (H)

         The Home Agent Password field is a password used by the home
         agent to authenticate the mobile host's identity.  The home
         agent Password is based on a shared secret between the mobile
         host and its home agent.

      Previous Foreign Agent Address (N)

         The Previous Foreign Agent Address field contains the address
         of a previous foreign agent of this mobile host that this
         foreign agent should notify of the mobile host's new binding.

      Previous Foreign Agent Authenticator (N)

         The Previous Foreign Agent Authenticator field contains the
         authenticator to be used by this foreign agent in notifying
         the mobile host's previous foreign agent of the mobile host's



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 68]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


         new binding.  This value must have been established with the
         previous foreign agent when the mobile host earlier registered
         with that foreign agent.

      Previous Foreign Agent Service Lifetime (N)

         The Previous Foreign Agent Service Lifetime field contains the
         length of time, expressed in tenths of a second, for which the
         previous foreign agent agreed to provide service to the mobile
         host without requiring reregistration.









































Johnson, Myles, Perkins         Expires 14 August 1994         [Page 69]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


13.4. Registration Reply Message

   The Registration Reply Message is used by a foreign agent to send
   registration replies to a mobile host, and by a home agent to send
   registration replies to a mobile host through a foreign 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Version   |R|    Type     |F|H|N| Reserved|  Reply Status |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Home Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Registration Sequence Number                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Agent Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Foreign Agent Service Lifetime (F)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Foreign Agent Authenticator (F)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Home Agent Service Lifetime (H)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Home Agent Password (H)                    +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Previous Foreign Agent Authenticator (N)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         The Source Address field contains an IP address belonging to
         the interface on which this message is sent.

      Destination Address

         When the Registration Reply message is being sent from a
         home agent to a foreign agent, the Destination Address field
         contains the address of the foreign agent.  When the message
         is being sent from a foreign agent to a mobile host, the
         Destination Address field contains the home address of the
         mobile host.






Johnson, Myles, Perkins         Expires 14 August 1994         [Page 70]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      Time-to-live

         The Time-to-live field must be set to 1 when the Registration
         Reply message is being sent from a foreign agent to a mobile
         host.  Otherwise, it should be set to MAXTTL.

   IMHP fields:

      Version

         1

      Routing (R)

         0

      Type

         0x20

      Foreign Agent (F)

         If the Foreign Agent (F) is set, the message contains a reply
         from a foreign agent to a mobile host.

         Fields in the message format above marked (F) are included in
         the packet only when the Foreign Agent (F) bit is set.

      Home Agent (H)

         If the Home Agent (H) bit is set, the message contains a reply
         from a home agent to a mobile host through its foreign agent.

         Fields in the message format above marked (H) are included in
         the packet only when the Home Agent (H) bit is set.

      Notify (N)

         If the Notify (N) bit is set, the foreign agent has received
         an acknowledgement from notification to the previous foregin
         agent requested by the mobile host in the Registration
         Request message.  The Previous Foreign Agent Authenticator
         field contains the authenticator value received in the
         acknowledgement.  The N bit may be set only when the Notify (N)
         bit was also set in the Registration Request message.

         Fields in the message format above marked (N) are included in
         the packet only when the N bit is set.



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 71]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      Reserved

         Sent as 0; ignored on reception.

      Reply Status

         The Reply Status field contains an acceptance or rejection code
         as follows:

            0x00 = Registration accepted.

            0x01 = Registration accepted; connected to home network.


            0x40 = Registration accepted by foreign agent; home agent
                   registration pending.


            0x80 = Registration rejected; no reason given.

            0x81 = Registration rejected; authentication failure with
                   home agent.

            0x82 = Registration rejected; authentication failure with
                   foreign agent.

            0x83 = Registration rejected; home agent has insufficient
                   resources.

            0x84 = Registration rejected; foreign agent has insufficient
                   resources.

            0x85 = Registration rejected; mobile host Registration
                   Sequence Number less than expected.

            0x86 = Registration rejected; foreign agent requires home
                   agent registration.

            0x87 = Registration rejected; no response received from home
                   agent by foreign agent.

      Home Address

         The Home Address field contains the home address of the mobile
         host attempting registration.






Johnson, Myles, Perkins         Expires 14 August 1994         [Page 72]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      Registration Sequence Number

         The Registration Sequence Number field contains the
         Registration Sequence Number of the mobile host attempting
         registration.

      Agent Address

         The Agent Address contains the care-of address that the foreign
         agent is providing the mobile host.

      Foreign Agent Service Lifetime (F)

         The Foreign Agent Service Lifetime field contains the length
         of time, expressed in tenths of a second, that a foreign agent
         guarantees it will attempt to maintain the registration.

         A value of zero implies the mobile host may consider itself
         de-registered.  The reserved value of 0xffffffff (all ones)
         implies an infinite period.

      Foreign Agent Authenticator (F)

         The foreign agent Authenticator field contains the same value
         as that included in the Registration Request message for which
         this reply is being sent.

      Home Agent Service Lifetime (H)

         The Home Agent Service Lifetime field contains the length of
         time, expressed in tenths of a second, that the home agent
         guarantees it will attempt to maintain the registration.

         A value of zero implies the mobile host may consider itself
         de-registered.  The reserved value of 0xffffffff (all ones)
         implies an infinite period.

      Home Agent Password (H)

         The 64-bit Home Agent Password field is a password used by the
         mobile host to authenticate the home agent's identity.  The
         home agent Password is based on a shared secret between the
         mobile host and its home agent.

      Previous Foreign Agent Authenticator (N)

         The Previous Foreign Agent Authenticator field contains the
         authenticator value received by the foreign agent in the



Johnson, Myles, Perkins         Expires 14 August 1994         [Page 73]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


         Binding Acknowledge message from the mobile host's previous
         foreign agent.

















































Johnson, Myles, Perkins         Expires 14 August 1994         [Page 74]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


13.5. Binding Inquire Message

   A Binding Inquire message is sent by a IMHP entity to another IMHP
   entity to ask it for the binding it has stored for a specified mobile
   host.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |R|    Type     |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Home Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Authenticator                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         An IP address belonging to the interface on which this message
         is sent.

      Destination Address

         The IP address of the mobile host for which the binding is
         requested.

      Time-to-live

         MAXTTL

   IMHP fields:

      Version

         1

      Routing (R)

         1

      Type

         0x30






Johnson, Myles, Perkins         Expires 14 August 1994         [Page 75]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      Reserved

         Sent as 0; ignored on reception.

      Home Address

         The Home Address field contain the home address the mobile host
         for which the source IMHP entity is requesting a binding.

      Authenticator

         The Authenticator field contains a random number, chosen by
         the sender.  Only replies containing the same value in the
         Authenticator field are authenticated.





































Johnson, Myles, Perkins         Expires 14 August 1994         [Page 76]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


13.6. Binding Notify Message

   The Binding Notify message is used to reply to a Binding Inquire
   message, to notify a mobile host's previous foreign agent of the
   mobile host's new binding, and to inform a system that it should
   attempt to acquire a new binding for some mobile host.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |R|    Type     |P|A|B|         Reserved        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Authenticator (B)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Registration Sequence Number (B)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Agent Address (B)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Service Lifetime (B)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         An IP address belonging to the interface on which this message
         is sent.

      Destination Address

         The IP address of the IMHP entity to which this Binding Notify
         message is being sent.

      Time-to-live

         MAXTTL













Johnson, Myles, Perkins         Expires 14 August 1994         [Page 77]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


   IMHP fields:

      Version

         1

      Routing (R)

         0

      Type

         0x31

      Private (P)

         If the Private (P) bit is set, the mobile host's binding must
         be kept private and may not be advertised to any system other
         than the mobile host's home agent and current foreign agent;
         otherwise the binding may be advertised as needed.  This bit is
         valid only if the Binding Present (B) bit is also set.

      Acknowledge (A)

         If the Acknowledge (A) bit is set, an acknowledgement with a
         Binding Acknowledge message is requested.

      Binding Present (B)

         If the Binding Present (B) bit is set, the Foreign Agent
         Authenticator should be used by the entity receiving the
         Binding Notify message to authenticate the mobile host's
         binding also included in the message.

         Fields in the message format above marked (B) are included in
         the packet only when the Binding Present (B) bit is set.

      Reserved

         Sent as 0; ignored on reception.

      Home Address

         This field contains the IP address of the mobile host to which
         the notification refers.






Johnson, Myles, Perkins         Expires 14 August 1994         [Page 78]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      Authenticator (B)

         This field contains a value that may be used by the entity
         receiving the Binding Notify message to authenticate the
         notification.  In the case of a notification to a mobile host's
         previous foreign agent, this field should be set to the Foreign
         Agent Authenticator established when the mobile host registered
         with that foreign agent.  In the case of a notification in
         response to a Binding Inquire message, this field should be
         set to the authenticator value received in the Binding Inquire
         message.

      Registration Sequence Number (B)

         If the Private (P) bit is not set, this field contains the
         mobile host's current Registration Sequence Number; otherwise,
         this field is sent as 0 and is ignored on reception.

      Agent Address (B)

         If the Private (P) bit is set, this field contains the mobile
         host's home address.  If the Private (P) bit is not set, this
         field contains the care-of address provided by the mobile
         host's current foreign agent, if the mobile host is not
         connected to its home network, or contains the mobile host's
         home address, otherwise.

      Service Lifetime (B)

         This field contains the maximum time, in tenths of a second,
         that the binding should be kept if the notification is
         authenticated.



















Johnson, Myles, Perkins         Expires 14 August 1994         [Page 79]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


13.7. Binding Acknowledge Message

   A Binding Acknowledge message is used to reply to a Binding Notify
   message for which the Acknowledge (A) bit was set.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version     |R|    Type     |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Registration Sequence Number                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Authenticator                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP fields:

      Source Address

         An IP address belonging to the interface on which this message
         is sent.

      Destination Address

         The Destination Address field is set to the source address
         field from the Binding Notify message being acknowledged.

      Time-to-live

         MAXTTL

   IMHP fields:

      Version

         1

      Routing (R)

         0

      Type

         0x32





Johnson, Myles, Perkins         Expires 14 August 1994         [Page 80]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


      Reserved

         Sent as 0; ignored on reception.

      IP Address of mobile host

         This field contains the IP address of the mobile host to which
         the reply refers.

      Registration Sequence Number

         This filed contains the current Registration Sequence Number of
         the mobile host to which the reply refers.

      Foreign Agent Authenticator

         This field must have the same value as the Authenticator field
         sent in the corresponding Binding Notify Message.  It is used
         to authenticate the acknowledgement.
































Johnson, Myles, Perkins         Expires 14 August 1994         [Page 81]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


References

    [1] R. T. Braden and J. B. Postel.  Requirements for Internet
        gateways.  RFC 1009, June 1987.

    [2] R. Droms.  Dynamic Host Configuration Protocol.  RFC 1541,
        October 1993.

    [3] John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr.  IP-based
        protocols for mobile internetworking.  In Proceedings of
        the SIGCOMM '91 Conference:  Communications Architectures &
        Protocols, pages 235--245, September 1991.

    [4] John Ioannidis, Gerald Q. Maquire Jr, and Steve Deering.
        Protocols for supporting mobile IP hosts.  Internet Draft, June
        1992.

    [5] David B. Johnson.  Transparent Internet routing for IP mobile
        hosts.  Internet Draft, July 1993.

    [6] Andrew Myles and Charles Perkins.  Mobile IP.  Internet Draft,
        August 1993.

    [7] C. Perkins and Y. Rekhter.  Support for mobility with
        connectionless network layer protocols (transport layer
        transparency).  Internet Draft, January 1993.

    [8] J. B. Postel.  User Datagram Protocol.  RFC 768, August 1980.

    [9] J. B. Postel, editor.  Internet Protocol.  RFC 791, September
        1981.

   [10] J. B. Postel.  Multi-LAN address resolution.  RFC 925, October
        1984.

   [11] Fumio Teraoka.  VIP: IP extensions for host migration
        transparency.  Internet Draft, July 1992.

   [12] Fumio Teraoka, Kim Claffy, and Mario Tokoro.  Design,
        implementation, and evaluation of Virtual Internet Protocol.  In
        Proceedings of the 12th International Conference on Distributed
        Computing Systems, pages 170--177, June 1992.

   [13] Fumio Teraoka, Yasuhiko Yokote, and Mario Tokoro.  A network
        architecture providing host migration transparency.  In
        Proceedings of the SIGCOMM '91 Conference:  Communications
        Architectures & Protocols, pages 209--220, September 1991.




Johnson, Myles, Perkins         Expires 14 August 1994         [Page 82]

Internet Draft      Internet Mobile Host Protocol       14 February 1994


Authors' Addresses

   David B. Johnson
   School of Computer Science
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA  15213-3891

   Work:  +1 412 2687399
   Fax:   +1 412 6815739
   E-mail: dbj@cs.cmu.edu


   Andrew Myles
   Electronics Department
   Macquarie University 2109
   Sydney, Australia

   Work:  +61 2 8059071
   Home:  +61 2 8786060
   Fax:   +61 2 8059128
   E-mail: andrewm@mpce.mq.edu.au


   Charles Perkins
   Room J1-A25
   T. J. Watson Research Center
   IBM Corporation
   P. O. Box 218
   Yorktown Heights, NY  10598

   Work:  +1 914 7897350
   Fax:   +1 914 7847007
   E-mail: perk@watson.ibm.com

















Johnson, Myles, Perkins         Expires 14 August 1994         [Page 83]