Internet DRAFT - draft-ietf-mobileip-packet-forward

draft-ietf-mobileip-packet-forward



group.  Our draft is attached below.

Thanks in advance.


- Hiromi Wada (Internet:hwada@isl.mei.co.jp)
- Information Systems Research Laboratory        PHONE +81-6-906-2431
- Matsushita Electric Industrial Co., Ltd., JAPAN  FAX +81-6-906-5547


------

Mobile IP Working Group                                      Hiromi Wada
INTERNET DRAFT                                           Tatsuya Ohnishi
                                Matsushita Electric Industrial Co., Ltd.
                                                             Brian Marsh
                            Matsushita Information Technology Laboratory
                                                               July 1993


                Packet Forwarding for Mobile Hosts


Abstract

        This memo describes a new protocol for mobile internetworking:
        the Internet Packet Transmission Protocol (IPTP). IPTP
        provides packet forwarding and host location functions that
        make mobility transparent to all protocols above IP. IPTP
        specifies control messages between the networking software on
        mobile hosts and a special Packet Forwarding Service.
        Backward compatibility is provided by requiring no
        modifications to stationary hosts or internetwork routers. To
        reduce overhead, IPTP provides for lazy propagation of
        location updates. To enhance performance, routes adapt as
        mobile hosts move.

Status of this memo

        This document describes an approach to transparent mobile
        internetworking.  This RFC requests discussion and suggestions
        for improvements.  Distribution of this memo is unlimited.  It
        expires on January 2, 1994.  Please respond with comments to the
        mobile-ip@parc.xerox.com mailing list.

        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 a ``working draft'' or ``work in progress.''

        Please check the 1id-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 any Internet Draft.


1 Introduction




Expires 2 January 1994                                          [Page 1]

Internet-Draft             Packet Forwarding                   July 1993


1.1 Goals

   Our aim is to support a computing environment where hosts can
   communicate with each other continuously as they migrate across
   networks.  We describe an IP-level solution designed to minimize the
   impact on existing protocols and applications.  Our solution
   provides packet forwarding and host tracking to allow IP packets to
   find their way between mobile and non-mobile hosts.

   From a practical point of view, we have two goals: backward
   compatibility and performance.  To provide backward compatibility
   we try to minimize the amount of software that must be modified.
   First, IPTP requires no changes to router software.
   Second, it requires no changes at all to the software of stationary
   hosts.  Finally, it requires no changes to mobile hosts above the
   network layer.

   To enhance performance, we need to minimize the overhead added to
   each forwarded packet, and to make migration as inexpensive as
   possible.  Per-packet overhead is due to encapsulation and any
   additional hops that are added to a route.  Host migration, or
   handoff as other proposals refer to it, has costs associated with
   the propagation of location information.  IPTP requires
   encapsulation only for packets sent to the mobile host.  Packets
   from the mobile host have no additional overhead.  IPTP also
   provides adaptive routing to elminate unnecessary hops between
   communicating hosts.  To cut down on the overhead of migration,
   IPTP provides lazy propagation of host location information,
   reducing the number of messages sent when a host moves.

1.2 Basic Concepts

   IPTP assumes three active entities: Mobile Hosts (MH), Stationary
   Hosts (SH), and Packet Forwarding Servers (PFS).  IPTP is the
   protocol used between these entities to implement the functions of
   MH location tracking and packet forwarding.  An MH is a machine
   that can roam between networks.  We assume that the kernel on this
   machine can be modified, but that protocols above IP will not be
   changed.  In addition, we assume that applications will not be
   changed to account for roaming.  Next, an SH is a machine that does
   not move.  In the worst case we assume that no software can be
   changed. When such modifications are possible, IPTP specifies
   important performance enhancements that can be made. Finally, a PFS
   is a user-level server that runs on an SH (We assume that the
   kernel allows user-level programs to receive arbitrary packets,
   e.g., through a facility such as NIT in SunOS Release 4.0).
   It forwards packets for roaming MHs.  In addition, it provides the
   primary copy of MH location information for any MHs for which it is
   the home PFS.



Expires 2 January 1994                                          [Page 2]

Internet-Draft             Packet Forwarding                   July 1993



   The basic idea is as follows.  An MH has two addresses: a home
   address and a temporary address.  The home address is a legitimate
   IP address on a subnet distinguished as the home network for the
   MH. Home addresses are statically assigned and never change.
   A temporary address is assigned as the
   MH moves between networks.  Packets are sent to an MH using its
   home address.  When an MH has moved away from its home network,
   IPTP uses the temporary address to forward packets to the new
   location of the MH.  IPTP is designed to maintain the mappings
   between an MH's home and temporary addresses, and to forward
   packets to roaming MHs.

   Packets are forwarded by encapsulating them in special IPTP
   packets.  IPTP provides two operational modes
   whose use depends on whether the SH can be modified or not:
   forwarding mode and autonomous mode.  Forwarding mode allows an
   unmodified host to communicate with an MH. Packets sent to a
   roaming MH are transmitted via standard IP but are intercepted by a
   PFS.  The PFS then encapsulates the packets and forwards them to
   the MH's current temporary address. In autonomous mode, the packet
   forwarding facility is built directly into the networking software
   of the SH.  A packet sent to the MH is encapsulated in an IPTP
   packet whose destination address is the MH's temporary address.
   The PFS is removed from the transmission path except for tracking
   MHs.  MH-to-MH communication works exactly the same way as
   SH-to-MH communication.

   We have two kind of PFSs.  One is a home PFS, and the other is an
   Autonomous Supporter(AS) PFS.  The home PFS is located on a home
   network of MHs.  The PFS is responsible for forwarding packets
   to an MH's temporary networks and for managing location information.
   The AS are located on a new network that an MH has visited.  After
   the MH again migrates to another network, the AS forwards packets
   destined for the MH to its current network.


1.3 Overview

   This document is organized as follows.  In Section 2 we discuss how
   mobile hosts are addressed.  In Section 3 we detail how packet
   forwarding is done, both for backward compatibility and performance.
   In Section 4 we focus on how location information is maintained.  In
   Section 5 we present the details of the IPTP protocol.  In Section 6
   we describe important implementation issues.

2 Addressing

   Each MH has two addresses: a home address and a temporary address.



Expires 2 January 1994                                          [Page 3]

Internet-Draft             Packet Forwarding                   July 1993


   The "home" address distinguishes the network from which the MH
   originates.  The home address remains the same even while the MH is
   roaming.  The network part of the home address is equal to the home
   network address.  The notion of a home is useful because it
   provides an easily found source of reliable information about a
   roaming MH.  In particular, a PFS located on an MH's home network
   is responsible for tracking its whereabouts at all times.  That PFS
   is also responsible for forwarding packets sent to a roaming
   MH's home address.

   The temporary address reflects the current real location
   of the MH (we also refer to it as the "real address"). The network
   part of the address is equal to the network address where the MH
   currently lives. A temporary address changes every time the host
   migrates to a new network.  The exact process of assigning
   temporary addresses is beyond the scope of this document.

   Applications address an MH using its home address, regardless of its
   location.  This is true both for applications running on the MH and
   for applications on other machines that must communicate with the MH.
   To send data to an MH, a host builds an IP packet whose destination
   address is the home address of the MH.  The IP packet is then
   encapsulated in an IPTP packet whose destination address is the
   current temporary address of the MH.  The packet is then delivered to
   the MH using existing routing mechanisms.  An MH receiving an
   encapsulated packet decapsulates it to yield the original IP packet.

   Because the temporary address of an MH is assigned dynamically when
   the MH visits a network, encapsulated packets might mistakenly be
   sent to a temporary address that has been reassigned to another MH.
   To filter out such packets, each encapsulated packet is tagged with
   the home address of the destination MH.  Since each MH has a unique
   home address, it is possible to distinguish packets that should not
   actually be delivered.  An encapsulated packet is accepted only if
   the temporary and home addresses match those of the receiving host.

3 Packet Forwarding

   In this section, we describe packet forwarding in detail.  As
   described in Section 1.2, packet forwarding is done in one of two
   modes: forwarding mode and autonomous mode.  In forwarding mode,
   the SH is unmodified and packets are forwarded by a PFS.  In
   autonomous mode, packet forwarding is performed by the sending
   host.  Both modes can co-exist in one environment.

3.1 Forwarding Mode

   In forwarding mode, packet forwarding for an MH is performed by a PFS
   on the MH's home network.  In Figure 1 we consider communication



Expires 2 January 1994                                          [Page 4]

Internet-Draft             Packet Forwarding                   July 1993


   between an SH and an MH.

                             +--------+
                             |        |
                       +---> |  PFS   | ---+
          (1) SH to MH |     |        |    |(2)Packet Forwarding
                       |     +--------+    |   (normal packet(1) is
                       |                   |   encapsulated in it)
         +--------+    |                   |     +--------+
         |        | ---+                   +---> |        |
         |   SH   |                              |   MH   |
         |        | <--------------------------- |        |
         +--------+       (3) normal packet      +--------+

                 Figure 1. Forwarding Mode

   (1) SH to MH - An SH sends a packet to an MH specifying the MH's home
       address.  The packet is routed to the MH's home network where it
       is intercepted by a PFS.  Packet interception is arranged by the
       PFS either by using some sort of promiscuous mode or by arranging
       with local gateways for packets to be routed to the SH on which
       the PFS is running.

   (2) Packet Forwarding - The PFS encapsulates the packet sent in (1)
       into a "Packet Transmission" packet (the exact format is
       described in Section 5.2).  The destination address in the IPTP
       message is the temporary address of the MH.  The PFS maintains a
       mapping between the home address and the temporary address by
       the IPTP protocol.  This location information management is
       described below.

       When the MH receives the "Packet Transmission" message, its
       IPTP layer decapsulates the IP packet it contains.  From the
       perspective of applications running on the MH, the MH appears
       to still reside on its home network.

   (3) MH to SH - The packet decapsulated from the "Packet
       Transmission" message contains the IP address of the SH in its
       source address field.  The MH sends a reply packet directly to
       the SH using standard IP.  The source address used for the
       reply packet is the MH's home address.  Because reply packets
       are standard IP packets, they are routed using normal IP
       routing mechanisms.  We assume that the MH dynamically acquires
       such routing information through a protocol such as DHCP[2].

3.2 Autonomous Mode

   Autonomous mode allows an SH to transmit packets directly to an MH,
   without relaying them via a PFS.  The packet routes that result can



Expires 2 January 1994                                          [Page 5]

Internet-Draft             Packet Forwarding                   July 1993


   be significantly shorter.  An autonomous mode connection has two
   key requirements.  First, the SH must have been modified to do its
   own packet forwarding.  Second, the MH must be able to find a PFS
   on its current network to act as an AS.
   An AS acts like a home PFS in the following way:
   if an MH migrates away from that network, the AS
   will intercept packets sent to it, and forward them to the MH's new
   address.

3.2.1 SH Transmission

   In this mode, packet forwarding is performed directly by the
   SH, instead of by the PFS.  Figure 2 illustrates this
   case.  The SH maintains a mapping between the home address and the
   temporary address of the target MH.  In this respect the
   functionality added to the networking software of the SH is
   similiar to that added to the PFS.  The difference is
   in how location information is propagated.  Location updates are
   sent by the MH to its home PFS, a PFS acting as an autonomous
   supporter and an modified SH.  If an SH initiates communication with
   an MH after the MH has migrated, it receives updates lazily when it
   uses stale addresses to send packets to the MH.  If not, the peer MH
   sends its current temporary address to the SH before the MH sends its
   first packet to the SH after its migration.  The SH mappings can be
   viewed as a cache of the primary copy maintained by the home PFS.
   Details of location information management is described in the
   Section 4.

                          (1) SH to MH
                          (SH's normal packet
         +--------+        is encapsulated)     +--------+
         |        | --------------------------> |        |
         |   SH   |                             |   MH   |
         |        | <-------------------------- |        |
         +--------+       (2) MH to SH          +--------+

                 Figure 2. Autonomous Mode

   (1) SH to MH - The SH sends a packet directly to the MH.
       Applications on the SH use the MH's home address.  IPTP
       software on the SH encapsulates the packet into a "Packet
       Transmission" message and sends it to the MH using the MH's
       current temporary address.  On receiving the packet, the MH's
       IPTP software decapsulates the original IP packet and passes it
       to the appropriate higher-level protocol.

   (2) MH to SH - The MH sends a packet directly to the SH using
       standard IP.  This is the same as in the forwarding mode above.




Expires 2 January 1994                                          [Page 6]

Internet-Draft             Packet Forwarding                   July 1993


3.2.2 Autonomous Supporter Transmission

   An AS will forward packets destined for an MH that is no longer
   present on the local network.  It knows the MH's temporary address
   there, because it was notified it by "Ping Autonomous Supporter"
   message when it visited the network.  It will also get the MH's
   current temporary address, because it will be notified it by "MH
   Location Information" message when the MH will visit a new network.

   Recall that the AS is a local PFS that has agreed
   to provide support for autonomous mode communications with visiting
   MHs.  When the MH migrates to a new network, it notifies the AS.
   The AS will then begin to look for packets destined for the MH's
   local IP address (the temporary one assigned when the MH first
   arrived). If the AS knows the current temporary address of the MH,
   it will forward any packets it intercepts.  If it doesn't know the
   current address of the MH, the packets are sent to the home PFS,
   which should have the MH's current location.  The home PFS address
   is contained in the IPTP header of the intercepted packet.
   Figure 3 illustrates this case.


             (current network)                    (home network)
                 +====+   (3) Packet Forwarding      +=====+
                 | MH |<-----------------------------| home|
          +----->|    |<------+                  +-->| PFS |
          |      +====+       |(2a) Packet       |   +=====+
          |                   |     Forwarding   |
          |                   | +----------------+
      migration               | | (2b) Packet Forwarding
          |                   | |
          |      (Ghost)      | |
          |         +----+  +=====+              +====+
          |         |    |  | PFS |<-------------| SH |
          +---------|    |  |     | (1) SH to MH |    |
                    +----+  +=====+              +====+
                   (previous network)


        Figure 3. Forwarding mode by an autonomous supporter PFS


   (1) SH to MH - The SH in autonomous mode sends a packet directly to
       the temporary address of the MH, although the MH is not at the
       temporary address any longer.

   (2) Packet Forwarding by Autonomous Supporter - If the autonomous
       supporter PFS learns the current address of the MH
       through the mechanism described in Section 4,



Expires 2 January 1994                                          [Page 7]

Internet-Draft             Packet Forwarding                   July 1993


       it forwards the packet to the current temporary
       address(2a).  If not, it forwards the packet to the home
       address(2b).  When forwarding, the PFS does not encapsulate the
       packet because it is already encapsulated.  Instead, it
       decrements the counter field in the IPTP header by 1 and if the
       value is 0, the PFS discards the packet.

   (3) Packet Forwarding - This takes place only when preceded by (2b).
       The home PFS forwards the packet to the current temporary address
       of the MH. Forwarding process is the same as (2) above (counter
       decrement and no encapsulation).

4 Location Information Management

   In this section we describe how IPTP is used to maintain location
   information.  A home PFS maintains the primary copy of location
   data for its local network.  When an MH migrates, it transmits its
   new configuration information to its home PFS.  This data includes
   the MH's new temporary address and whether there is an Autonomous
   Supporter on the new network.  The home PFS is then responsible
   for propagating the data to all concerned hosts.  This data may be
   cached by MHs, SHs, and autonomous supporters (ASs).  PFSs need it
   to support packets transmitted in Forwarding Mode.  MHs and SHs
   need it when communicating in Autonomous Mode.  Below, we describe
   how updates are first sent when an MH migrates and later propagated
   to other MHs, SHs, and ASs.

4.1 MH Migration/PFS Notification

   When an MH moves to a new network, it transmits new configuration
   information to its home PFS and its previous AS.  Notification to
   the home PFS is for redirecting packets sent in Forwarding
   Mode.  Notification to the AS is for redirecting packets sent in
   Autonomous Mode.  Figure 4 describes how configuration information
   is collected and distributed.

















Expires 2 January 1994                                          [Page 8]

Internet-Draft             Packet Forwarding                   July 1993


         (current network)
                Ping Autonomous Supporter         (home network)
         +====+ (1)  +=====+                         +=====+
         | MH |----->| PFS |                         | home|
     +-->|    |      |     |                     +-->| PFS |
     |   +====+      +=====+                     |   +=====+
     |     ||                                    |
     |     |+------------------------------------+
     |     |        (2) MH Location Information
     |     |
     |     +-------------------------+
     |                               |(3) MH Location Information
     |                  (Ghost)      v
     |                  +----+     +=====+
   migration            |    |     | PFS |
     +------------------|    |     | (AS)|
                        +----+     +=====+
                        (previous network)

           Figure 4. Location information distribution

    (0) The MH is assigned a temporary address using a protocol such
        as DHCP.

    (1) Autonomous Supporter -- The MH tries to find a PFS which
        can support autonomous mode in the new network.  The MH
        broadcasts a "Ping Autonomous Supporter" message. If
        any PFS responds, the MH will transmit packets in autonomous
        mode.  When a PFS receives a "Ping Autonomous Supporter", it
        sends to the sender a reply message with an autonomous flag
        which indicates whether it supports the mode or not.  A PFS
        supporting Autonomous Mode registers the MH in a list of
        visiting MHs.

    (2) MH Location Information - The MH sends an "MH Location
        Information" message to a PFS on its home network.  This message
        carries the home and temporary addresses of the MH, an
        autonomous flag which indicates whether the MH can communicate
        in autonomous mode or not, and the address of the PFS which
        responded to the "Ping Autonomous Supporter" message.

        When a PFS in the home network receives an "MH Location
        Information" message, it returns an acknowledgement to the MH,
        and updates its mapping for the home address of the MH.

    (3) MH Location Information to a Previous PFS - The MH also sends an
        "MH Location Information" message to an AS (if any) on its
        previous network.  If the MH has not just migrated from its home
        network and if it was operating in autonomous mode on the



Expires 2 January 1994                                          [Page 9]

Internet-Draft             Packet Forwarding                   July 1993


        previous remote network, there must have been an Autonomous
        Supporter on that network.  Hence, the MH sends it an "MH
        Location Information".  When the AS receives the "MH Location
        Information" message, it acknowledges the message and flags its
        mapping (if any) for the MH.  The flag indicates that the MH has
        migrated, and means that the AS may delete the MH's entry if
        necessary.  After that, the AS starts looking for packets
        destined for the MH's obsolete temporary address.


4.2 Autonomous Sender Notification

    Notifying the home PFS only takes care of packets sent in forwarding
    mode.  If a host can use autonomous mode to communicate with an MH
    which is migrating from its home network to another network,
    and if an AS in the new network works for the MH, then the host
    should change to autonomous mode.  This notification is described in
    Section 4.2.1.

    If a host is using autonomous mode to communicate with the MH,
    there are two possibilities for how to distribute the MH's
    current temporary address to the host.
    In one case, the host has sent a "Packet Transmission" message
    to the network previously occupied by the MH.
    An AS in that network works on behalf of the MH.
    If the AS knows the MH's current temporary
    address, it will inform the host of it.
    This case is described in Section 4.2.2.
    In the other case, the MH has sent a
    "MH Location Information" message to the host prior
    to re-starting communication after migration.
    This case is described in Section 4.2.3.
    In both
    cases, IPTP provides lazy notification by waiting until a message is
    sent to the host.

4.2.1 Packets to the Home Address

      A host that communicates with an MH that has migrated may address
      its packet to the home address of the MH.  If the sending host
      supports autonomous mode, then its location tables must be updated
      to reflect the new location of the MH.  Figure 5 depicts how this
      update procedure takes place.









Expires 2 January 1994                                         [Page 10]

Internet-Draft             Packet Forwarding                   July 1993


                            +====+
                      +-----| SH |-----+
                      |     |    |<--+ |
                   (4)|     +====+   | |(1) Normal
                Packet|        MH(3) | |    Packet
          Transmission|      Location| |    Transmission
                      |   Information| |
                      |              | |     +=====+
            +====+    |              | +---->| home|
            | MH |<---+              +-------| PFS |
            |    |<------------------------- +=====+
            +====+      (2)Packet Forwarding

       (current network)                  (home network)


           Figure 5. Packets to the Home Address


    (1) Normal Packet Transmission - The SH sends a normal IP packet to
        the MH's home address.

    (2) Packet Forwarding - The home PFS picks up the packet,
        encapsulates it within an IPTP "Packet Transmission" message,
        and sends it to the MH's current temporary address.

    (3) MH Location Information - If the MH has moved to a network that
        supports autonomous mode then the home PFS attempts to notify
        the SH that autonomous mode communication is possible.  If the
        SH is capable of autonomous mode communication, when it receives
        the "MH Location Information" message, it caches the MH's new
        temporary address, and enters autonomous mode for all packets
        destined for the MH.

    (4) The SH can now send packets to the MH without an intervening hop
        through the PFS.

4.2.2 Packets from an AS

      If an SH using autonomous mode is communicating with an MH which
      is not located in its home network, an AS must be in the network
      where the MH exists.  If the MH has migraterd to a new network and
      if another AS exists there, the SH can continue to communicate
      with the MH using autonomous mode.  The AS in the previous network
      forwards "Packet Transmission" messages destined for the MH to its
      current temporary address and informs the SH of the address.
      Figure 6 illustrates this case.





Expires 2 January 1994                                         [Page 11]

Internet-Draft             Packet Forwarding                   July 1993


           (current network)             (home network)
           +====+    +=====+                 +=====+
           | MH |    | PFS |                 | home|
           |    |<-+ | (AS)|                 | PFS |
           +====+  | +=====+                 +=====+
             ^ ^   |
             | |   +----------------------------+
             | |                                |
             | +--------+(2) Packet             |(4) Packet
         migration      |    Transmission       |    Transmission
             |          |                       |
             |          |                       |
          (Ghost)       |    (3) Location       |
           +----+    +=====+     Information  +====+
           |    |    | PFS |----------------->| SH |
           |    |    | (AS)|<-----------------|    |
           +----+    +=====+ (1) Packet       +====+
           (previous network)    Transmission


                Figure 6. Packets from an AS


    (1) Packet Transmission - The SH using autonomous mode sends "Packet
        Transmission" message to the previous temporary address of the
        MH.

    (2) Packet Transmission - The AS in the previous network forwards it
        to the current temporary address of the MH.

    (3) Location Information - The AS in the previous network informs
        the SH of the current temporary address of the MH.

    (4) Packet Transmission - The SH sends subsequent packets to the
        MH's current temporary address.


4.2.3 Packets from a Migrated MH

      Before a migrated MH initiates communication with an SH, the MH
      sends an "MH Location Information" message to the SH.  If the SH
      supports autonomous mode, it extracts the MH's current temporary
      address.  Therefore, when the SH responds a packet sent by the MH,
      it can send the packet directly to the MH via normal IP routing
      instead of through a PFS.  Figure 7 illustrates this case.







Expires 2 January 1994                                         [Page 12]

Internet-Draft             Packet Forwarding                   July 1993


                  (1) MH Location Information
              +-------------------------------------+
              |                                     |
              v                                     |
          +-------+  (2) Normal IP Packet        +-------+
          |       | <--------------------------- |       |
          |  SH   |                              |  MH   |
          |       | ---------------------------> |       |
          +-------+  (3) Packet Transmission     +-------+


           Figure 7. Packets from a Migrated MH


    (1) MH Location Information - The MH informs the SH of its own
        current temporary address, before it starts communicating with
        the SH.

    (2) Normal IP Packet - The MH sends a normal IP packet to the SH.

    (3) Packet Transmission - The SH can encapsulate packets to the MH
        into the "Packet Transmission" messages.


4.3 Packets to an Obsolete Temporary Address

   Figure 8 illustrates what happens if a PFS acting as an autonomous
   supporter (AS) receives a packet destined for an MH that has
   already left its network. The AS must encapsulate and forward the
   packet.  More importantly, however, it must notify the sending host
   of the MH's new address.





















Expires 2 January 1994                                         [Page 13]

Internet-Draft             Packet Forwarding                   July 1993


           (current network)             (home network)
                +====+                      +=====+
             +->| MH |<---------+(4b)       | home|
             |  |    |<--+      |Subsequest | PFS |---+(5)
             |  +====+   |      |Packet     +=====+   |MH
             |           |      |Transmission   ^     |Location
         migration       |(2)   +---------+     |     |Information
             |           |Packet          |     |     |
             |           |Forwarding      |     |(4a) |
             |           |                |     |Subsequest
             |           |                |     |Packet
          (Ghost)        | (3)MH Location |     |Transmission
           +----+    +=====+  Information +---+====+  |
           |    |    | PFS |----------------->| SH |<-+
           |    |    | (AS)|<-----------------|    |
           +----+    +=====+   (1)Packet      +====+
           (previous network)     Transmission


       Figure 8. Packets to an Obsolete Temporary Address

    (1) Packet Transmission - The SH sends a "Packet Transmission"
        message to the MH's old temporary address.  The autonomous
        supporter for the MH's old temporary address will intercept the
        packet.  It knows that the MH is gone because it received a "MH
        Location Information" message as described in Section 4.1,
        paragraph 3.

    (2) Packet Forwarding - The AS may attempt to forward the packet to
        the MH if the MH's new temporary address is still in its cache.
        However, the AS is not required to maintain the new address
        of the MH. If it is not in the cache, the AS knows only that
        it has gone.  If so, the packet is instead forwarded to the
        home PFS for correct rerouting.

    (3) MH Location Information - The AS must now notify the SH that
        it has an out of date address for the MH.  It therefore sends
        to the SH an "MH Location Information" message.  The AS
        includes the MH's new address if possible, allowing subsequent
        packets to be routed directly to the MH without going through
        the home PFS.  If the AS does not know the MH's new address
        then the address field is set to NULL, indicating that the SH
        should route packets to the MH's home network where they are
        picked up by the home PFS.

    (4) Subsequent Packet Transmission(SH to MH) - The SH knows that its
        mapping for the MH is stale.  If no new address for the MH was
        received in (3), then it will transmit subsequent packets to
        the MH's home network for processing by the home PFS (4a).



Expires 2 January 1994                                         [Page 14]

Internet-Draft             Packet Forwarding                   July 1993


        Otherwise, it will transmit subsequent packets to the new
        temporary address of the MH (4b).

    (5) MH Location Information - When the home PFS receives the next
        packet destined for the home address of the MH, if the MH is
        available for autonomous mode communication, the home PFS sends
        an "MH Location Information" message to the sender.  At the same
        time, it forwards the packet to the current temporary address of
        the MH.  When the sender receives the "MH Location Information"
        message, it updates the cache entry of the MH's location and
        enters autonomous mode. This step takes place only if preceded
        by step(4b).


5 Internet Packet Transmission Protocol(IPTP)

   In this Section we describe the Internet Packet Transmission
   Protocol(IPTP).  IPTP consists of four packet types that fit within
   one packet format.  The packet types provide packet forwarding, new
   address notification, pinging for an autonomous supporter, and an
   IPTP echo check.

5.1 Message Type

   In this subsection, we describe the different IPTP message types.
   The parameter types are defined in detail in Section 5.2.

    (1) Packet Transmission

        This message is used to forward packets from a PFS to an MH and
        to send packets from an SH to an MH.  It does not require a
        response.

        The following parameters should be set:
               - Type
               - Aim
               - Counter
               - Home address of MH
               - Temporary address of MH
               - Encapsulated packet

    (2) MH Location Information

        This message is used to notify a PFS or an SH of an MH's new
        address.  It requires a response.

        The following parameters should be set:
               - Type
               - Aim



Expires 2 January 1994                                         [Page 15]

Internet-Draft             Packet Forwarding                   July 1993


               - Sequence
               - Autonomous
               - Home address of MH
               - Temporary address of MH
               - Address of PFS: See Section 5.2.
               - Authentication information

        The following parameters should be set in a response:
               - Type
               - Aim
               - Sequence
               - Status

    (3) Ping Autonomous Supporter message

        This message is used for an MH to find a PFS which supports the
        autonomous mode in a new temporary network. This message
        requires a response.

        The following parameters should be set in a request message:
               - Type
               - Aim
               - Sequence
               - Home address of MH
               - Temporary address of MH
               - Authentication information

        The following parameters should be set in a response message:
               - Type
               - Aim
               - Sequence
               - Autonomous
               - Status

    (4) Echo message

        This message is used to examine whether a host employs IPTP or
        not.  It requires a response.

        The Following parameters should be set in both a request and a
        response:
               - Type
               - Aim
               - Sequence

5.2 Parameters

        Type:
           This field indicates a message type of an IPTP packet.



Expires 2 January 1994                                         [Page 16]

Internet-Draft             Packet Forwarding                   July 1993


                Value    : Meaning
                --------------------------------------------
                    0    : Packet Transmission message
                    1    : MH Location Information message
                    2    : Ping Autonomous Supporter message
                    3    : Echo message

        Aim:
           This field indicates whether the packet contains either a
           request or a response. Each message except "Packet
           Transmission" message requires a response.

                Value    : Meaning
                ----------------------------------------------------
                    0    : neither request nor response
                           (That is "Packet Transmission" message.)
                    1    : request
                    2    : response

        Sequence number:
           The sequence number of the packet between a requester and a
           responder.  It is used to indicate the relationship between a
           request and a response packet.

        Autonomous:
           Used only on "MH Location Information" messages from an MH to
           the home PFS.  It indicates whether the home PFS should
           notify SHs of the MH's temporary address or not.

                Value    : Meaning
                -------------------------------------------------------
                    0    : The home PFS must not notify SHs of the MH's
                           temporary address,
                    1    : The home PFS may notify SHs of the MH's
                           temporary address.

        Counter:
           The counter is used to detect forwarding loops.  It is set to
           an implementation-specific number whenever a "Packet
           Transmission" message originates.  When a PFS receives the
           "Packet Transmission" message, the PFS decrements the counter
           by 1.  If the counter is equal to 0, the PFS discards the
           packet instead of forwarding it.









Expires 2 January 1994                                         [Page 17]

Internet-Draft             Packet Forwarding                   July 1993


        Status:
           The status of the packet.
                Value    : Meaning
                --------------------------------------------
                    0    : No problem
                    1    : Authentication error
                    2    : Specified MH's address is unknown

        Home address of MH:
           The address of an MH on its home network.

        Temporary address of MH:
           The address of an MH on a temporary network.  Assigned using
           some dynamic configuration protocol such as DHCP.

        Address of PFS:
           The IP address of a PFS.  Possible values are:

                Situation             : Meaning
                --------------------------------------------------
                1. MH migrates to new : Address of PFS which
                   network              is an autonomous supporter
                2. PFS notifies Auto. : Address of home PFS
                   mode supporter

        Authentication information:
           A password or token that PFSs use to decide whether an MH has
           sufficient credentials to be given service. The exact nature
           of this is beyond the current scope of this document.  To
           allow for multiple types of authentication information, the
           following format should be obeyed. Multiple authentication
           fields may be present to accommodate a variety of
           authentication mechanisms.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Auth Type   |    Version    |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Authentication Data ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-...

           The Authentication Type field describes which authentication
           mechanism is being used, with the Version field detailing
           which version of that mechanism. The Length field indicates
           the length of the authentication data in octets.

           Authentication Type 0 is just padding, and as such, only the
           type field is used (i.e., it is just a 0-filled octet).



Expires 2 January 1994                                         [Page 18]

Internet-Draft             Packet Forwarding                   July 1993



           Authentication Type 1 indicates that the authentication data
           are just a plaintext password; Version is 0; the Length field
           indicates the length of the password, and the authentication
           data is a cleartext password.
           This type of authentication should only be used
           when the physical medium can be trusted.

           Authentication Types 2-127 are reserved for future standard
           definitions.

           Authentication Types 128-255 are reserved for future
           definition by vendors and/or implementors.

        Encapsulated packet:
           This is an original IP packet destined for MH.  This field is
           only included in "Packet Transmission" messages.

        Optional data:
           This is a field for optional data.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            length             |     optional data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...


5.3 Packet Format

  (1) Packet Transmission message

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             type              |     aim       |  (not used)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  (not used)   |    counter    |  (not used)   |  (not used)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     home address of MH                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     temporary address of MH                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     (not used)                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     encapsulated packet
     +-+-+-+-+-+-+-+-+-+-+-+-+-...

  (2) MH Location Information message



Expires 2 January 1994                                         [Page 19]

Internet-Draft             Packet Forwarding                   July 1993



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             type              |     aim       |   sequence    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  autonomous   |  (not used)   |    status     |  (not used)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     home address of MH                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     temporary address of MH                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     address of PFS                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     authentication information
     +-+-+-+-+-+-+-+-+-+-+-+-+-...

  (3) Ping Autonomous Supporter message

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             type              |     aim       |   sequence    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  autonomous   |  (not used)   |    status     |  (not used)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     home address of MH                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     temporary address of MH                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     (not used)                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     authentication information
     +-+-+-+-+-+-+-+-+-+-+-+-+-...

  (4) Echo message

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             type              |     aim       |   sequence    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  autonomous   |    counter    |    status     |  (not used)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     optional data
     +-+-+-+-+-+-+-+-+-+-+-+-+-...






Expires 2 January 1994                                         [Page 20]

Internet-Draft             Packet Forwarding                   July 1993


5.4 State Diagrams

                    +------------+
                    | non-mobile |
+------------------>| mode       |
|    migrate to     +------------+
|    home network         | migrate to another network
|    -------------        | -------------------------------
|                         v send a request to get a tmp adr
|                   +-------------+
+------------------>| waiting for |
|    migrate to     | tmp adr     |
|    another        +-------------+
|    network              | get a tmp adr
|    --------------       | -------------
|    send a request       v send MHLI
|    to get a tmp   +-------------+
|    adr            | waiting for |
|                   | MHLI ack    |
|                   +-------------+
|                         | receive MHLI ack
|              PT         | ----------------
|              --         | send PAS
|            +-----+      |      +-------+
|            v     |      v      v       | PT
|  +------------+  |  +-------------+    | --
|  | forwarding |--+  | waiting for |----+
+--| mode       |<----| PAS ack     |
^  +------------+     +-------------+
|               timeout   | receive PAS ack
|               -------   | ---------------
|                         |
|                         |    +-------+
|                         v    v       | PT
|                   +-------------+    | --  PT   : Packet Transmission
+-------------------| autonomous  |----+     MHLI : MH Location Info.
       migrate      | mode        |          PAS  : Ping Auto. Supporter
       -------      +-------------+

                Figure 9. State Diagram of an MH












Expires 2 January 1994                                         [Page 21]

Internet-Draft             Packet Forwarding                   July 1993


                       +------------+
                       | forwarding |
                       | mode       |
                       +------------+
     receive MHLI           ^   | receive MHLI
     without MH's address   |   | ------------
     ---------------------- |   |
                            |   v
                       +-------------+
                       | autonomous  |
                       | mode        |<-+ send a packet to MH
                       +-------------+  | -------------------
                                   |    | send PT
                                   +----+

           Figure 10. State Diagram of an SH




































Expires 2 January 1994                                         [Page 22]

Internet-Draft             Packet Forwarding                   July 1993


                       +------------+
                       | waiting for|<------------------------------+
                       | MHLI ack   |                               |
                       +------------+                               |
                            |  ^ receive MHLI                       |
           receive MHLI ack |  |   without Autonomous               |
           ---------------- |  | --------------------               |
                            |  | update address table               |
                            |  |                                    |
 receive MHLI               |  |  +-----+ receive a normal packet   |
   with Autonomous          v  |  v     |   for the home MH         |
 --------------------  +------------+   | ------------------------  |
 update address table  | forwarding |---+ send PT                   |
+----------------------| mode       |                               |
|                      +------------+                               |
|   migrate to home network |  ^ receive MHLI                       |
|     (receive MHLI)        |  |   without Autonomous               |
|   ----------------------- |  | ---------------------------------  |
|   replace ARP entry for   |  | update address table               |
|            the home MH    |  | replace ARP entry for the home MH  |
|   send MHLI ack           v  | send MHLI ack                      |
|                      +------------+                               |
|                      |  initial   |                               |
|                      |  state     |                               |
|                      +------------+                               |
|   migrate to home network ^  | receive MHLI                       |
|     (receive MHLI)        |  |      with Autonomous               |
|   ----------------------- |  | ---------------------------------  |
|   replace ARP entry for   |  | update address table               |
|            the home MH    |  | replace ARP entry for the home MH  |
|   send MHLI ack           |  v send MHLI ack                      |
|                      +-------------+                              |
|                      | autonomous  |------------------------------+
| +--------------------| mode        | receive MHLI without Autonomous
| |                    +-------------+ -------------------------------
| |        receive MHLI ack ^  |       update address table
| |        ---------------- |  |       send MHLI to previous PFS
| |                         |  |
| |receive MHLI             |  | receive a normal packet
| |  without Autonomous     |  |   for the home MH
| |--------------------     |  | -----------------------
| |update address table     |  | send PT
| |send MHLI to             |  v send MHLI to sender
| |  previous PFS      +------------+
| +------------------->| waiting for|
+--------------------->| MHLI ack   |
                       +------------+

                Figure 11. State Diagram of a home PFS



Expires 2 January 1994                                         [Page 23]

Internet-Draft             Packet Forwarding                   July 1993


                 +---------------+
                 | waiting for   |
                 | MHLI ack      |
                 +---------------+
                       |  ^
                       |  | receive PT
      receive MHLI ack |  | --------------------------------
      ---------------- |  | forward it to home adr (send PT)
                       |  | send MHLI without MH's address
                       v  |
                 +---------------+
                 | forwarding to |
                 | home adr mode |----------+
                 |(initial state)|          |
                 +---------------+          |
                       ^  |                 |
    receive MHLI       |  | receive PAS     | receive MHLI
      without MH's adr |  | ------------    | -------------
    ------------------ |  | send PAS ack    | send MHLI ack
    send MHLI ack      |  |                 |
                       |  v                 |
                 +-------------+            |
                 | forwarding  |<-----------+
                 | mode        |<------+ receive MHLI
                 +-------------+       | -------------
                       ^  |  |         | send MHLI ack
                       |  |  +---------+
                       |  |
      receive MHLI ack |  | receive PT
      ---------------- |  | ------------------------------------
                       |  | forward it to new location (send PT)
                       |  | send MHLI
                       |  v
                 +---------------+
                 | waiting for   |
                 | MHLI ack      |
                 +---------------+

            Figure 12. State Diagram of an Autonomous Supporter
                                        (a PFS for visitor MHs)












Expires 2 January 1994                                         [Page 24]

Internet-Draft             Packet Forwarding                   July 1993


5.5 Packet Transmission Parameters

   Two important transmission parameters for IPTP are the timeout
   interval and the retransmission count.  The timeout interval is the
   length of time IPTP will wait before retransmitting a packet.  The
   retransmission count is the number of times a packet will be resent.
   IPTP defines these parameters for all messages except "Packet
   Transmission" messages. IPTP "Packet Transmission" messages can be
   lost without a loss of correctness because IP makes no guarantee
   about reliable packet delivery. Reliable delivery is left to higher
   level protocols in the transport and network layers.  For the other
   message types, we assume that the timeout interval will be tuned to
   specific implementations.  The remaining issue, therefore, is the
   number of retransmissions.

   The "MH Location Information" message should be retransmitted an
   infinite number of times. If for any reason, such as a network
   failure, an MH cannot notify its home PFS of its new address the MH
   will become temporarily lost.  Continuous retransmission guarantees
   that the time of the network partition will never exceed the
   transmission of the last "MH Location Information" message.  If
   communication between the MH and PFS is ever possible again, then a
   packet will eventually get through, allowing hosts communicating
   with the MH to reestablish contact through the home PFS.

   The other packet types, "Ping Autonomous Supporter",
   and "Echo", should be retransmitted only a finite number of times.
   Loss of these packets may result in a less efficient routing, but
   will not be fatal.  For instance, a host capable of autonomous mode
   communication may mistakenly use forwarding mode if a "Ping"
   message is lost.

6 Implementation Notes

6.1 Translation Tables

   Address Translation tables are maintained by PFSs, and by SHs and MHs
   using autonomous mode.  All table entries contain the home address
   and the current temporary address of a MH.  In addition, table
   entries in a home PFS will contain the address of the PFS in the MH's
   current temporary network.  Table entries in SHs and MHs will contain
   the address of the MH's home PFS.

   PFSs are responsible for providing non-volatile storage for
   translation information.  SH and MH tables are only caches for data
   managed by PFSs.  An SH or an MH can easily refresh its tables by
   interacting with the appropriate PFS.  Of course, a disasterous
   failure might cause a PFS to lose its translation information.  If
   this occurs, the information must be recovered by inducing MHs to



Expires 2 January 1994                                         [Page 25]

Internet-Draft             Packet Forwarding                   July 1993


   resend "MH Location Information" messages.

6.2 Avoiding Redundant "MH Location Information" Messages

   In an environment where both forwarding mode and autonomous mode are
   utilized, a PFS might send unnecessary "MH Location Information"
   messages to SHs using forwarding mode.  Because they are using
   forwarding mode, these SHs will ignore the "MH Location Information"
   messages.  Packets from the SH to the MH will continue to be sent to
   the PFS, resulting in the generation of ineffective and unnecessary
   "MH Location Information" messages.

   To avoid this, a PFS should keep a list of hosts it serves that are
   using forwarding mode.  The PFS can then refrain from sending "MH
   Location Information" messages to any host on this list.  Hosts can
   be added to this list when the first "MH Location Information"
   message cannot be delivered to the SH.  The failure can be detected
   either by an ICMP message that indicating that the destination port
   is unreachable or when the SH fails to acknowledge the "MH Location
   Information" message.

6.3 PFS Packet Interception

   In order to correctly forward packets for mobile hosts, a PFS must be
   able to intercept packets addressed to hosts that have migrated away
   from the local network.  One possible implementation is to use
   promiscuous mode, if the the underlying interface supports it.  Such
   a solution, however, may impose a substantial load as the PFS is
   forced to inspect every packet.

   A more attractive alternative is to use a proxy ARP.  When a PFS
   receives a "MH Location Information" message from an MH, it
   broadcasts an ARP reply packet for the MH's home address.  The reply
   packet specifies that the MH's IP address now resolves to the address
   of the PFS's physical interface. Subsequent packets addressed to the
   MH's home address will be received by the PFS.

   If a PFS is already forwarding packets for an MH, it responds as a
   proxy to any ARP requests for the MH's address. The ARP reply
   message indicates that packets destined for the home (IP) address
   of the MH should be physically (i.e. at the hardware address level)
   addressed to the PFS.

   Unfortunately, because of the need to reuse temporary IP addresses,
   this technique cannot be applied to a PFS acting as an autonomous
   supporter for a visiting MH.  A visiting MH will use a temporary
   address.  This address will eventually be reused when the visiting
   MH migrates to a new network.  If the PFS issues a Proxy ARP for
   this address, packets intended for the new user of the address



Expires 2 January 1994                                         [Page 26]

Internet-Draft             Packet Forwarding                   July 1993


   might be lost.  Temporary addresses must be reusable because of the
   limited number of address bits available.  The consequence is that
   a PFS may only act as an autonomous supporter if it has a
   promiscuous interface on a broadcast medium that allows it to see
   all network traffic.

6.4 Adaptive Mode Selection

   An MH that transmits a "Ping Autonomous Supporter" message may have
   to wait some time for a local PFS to reply.  This delay is passed to
   applications as additional latency introduced by MH migration.  To
   avoid this problem, the MH may send the "MH Location Information" to
   the home PFS without the Autonomous flag set.  After the MH finds a
   PFS which supports autonomous mode, it may resend "MH Location
   Information" message, this time with the Autonomous flag set.

6.5 Detection of Forwarding Loops

   If an MH is roaming among temporary networks where PFSs support
   autonomous mode, it is possible that forwarding relays will occur.
   To prevent a forwarding loop, the "Packet Forwarding" message
   contains a special counter.
   When a PFS forwards a packet for the first time,
   it sets the counter to an upper bound defined by the system.  Before
   another PFS forwards the packet, it decrements the counter by 1 and
   it checks to see if the the value is zero.  If the PFS finds the
   counter equal to zero, the packet is discarded.  Otherwise the packet
   is forwarded normally.

6.6 Gateway Packet Filters

   For security reasons, some gateways filter packets based on port
   numbers.  Because an original packet is encapsulated in an IPTP
   packet in our approach, the gateways will check the IPTP port number.
   Such gateways will fail to filter out packets that might otherwise be
   objectionable because the packet filters do not see within the IPTP
   packet.  Similarly, a filter applied to IPTP will remove all
   encapsulated packets, regardless of how the local system
   administrator feels about them.

   If the gateway host filters packets of specified port numbers and
   IPTP port number itself is not included in the port number list for
   filtering, the IPTP packet will pass through, even if the original
   packet in the IPTP packet should be filtered.  On the other hand, if
   the gateway host makes packets of specified port numbers pass through
   and IPTP port number is not included in the list for passing, the
   IPTP packet will be filtered.

   One way to solve this problem is to redesign the IPTP packet format.



Expires 2 January 1994                                         [Page 27]

Internet-Draft             Packet Forwarding                   July 1993


   "Packet Transmission" messages could reflect the packet type in a
   newly defined IP option field rather than be indicated in the port
   number field.

6.7 Handling IP options

   When a PFS encapsulates a packet, it should copy IP options of the
   packet to the encapsulated packet.  When an MH decapsulates the
   packet, it should restore IP options of the packet to the original
   packet.

7 Acknowledgement

   The description of authentication is almost fully derived from
   Columbia University's draft "Protocols for Supporting Mobile IP
   Hosts"[3] and IBM's draft "Support for Mobility with Connectionless
   Network Layer Protocols(Transport Layer Transparency)"[4].

8 Authors' Addresses

         Hiromi Wada
         Information Systems Research Laboratory
         Matsushita Electric Industrial Co., Ltd.
         1006 Kadoma, Kadoma-shi, Osaka, 571 JAPAN
         Internet : hwada@isl.mei.co.jp
         Phone    : +81-6-906-2431
         Fax      : +81-6-906-5547

         Tatsuya Ohnishi
         Information Systems Research Laboratory
         Matsushita Electric Industrial Co., Ltd.
         1006 Kadoma, Kadoma-shi, Osaka, 571 JAPAN
         Internet : ohnishi@isl.mei.co.jp
         Phone    : +81-6-906-2431
         Fax      : +81-6-906-5547

         Brian Marsh
         Matsushita Information Technology Laboratory
         182 Nassau St, 3rd floor
         Princeton, NJ 08542
         Internet : marsh@mitl.com











Expires 2 January 1994                                         [Page 28]

Internet-Draft             Packet Forwarding                   July 1993


                           References

1. H.Wada, T.Yozawa, T.Ohnishi, and Y.Tanaka, "Mobile Computing
   Environment Based on Internet Packet Forwarding", 1993 Winter USENIX

2. R.Droms, "Dynamic Host Configuration Protocol", Internet Engineering
   Task Force, INTERNET-DRAFT, November 1992

3. J.Ioannidis, D.Duchamp, G.Q.Maguire Jr, and S.Deering, "Protocols for
   Supporting Mobile IP Hosts", Internet Engineering Task Force,
   INTERNET-DRAFT, June 1992

4. C.Perkins and Y.Rekhter, "Support for Mobility with Connectionless
   Network Layer Protocols(Transport Layer Transparency)", Internet
   Engineering Task Force, INTERNET-DRAFT, January 1993

5. F.Teraoka, "VIP:IP Extentions for Host Migration Transparency",
   Internet Engineering Task Force, INTERNET-DRAFT, Novenber 1992


































Expires 2 January 1994                                         [Page 29]

Internet-Draft             Packet Forwarding                   July 1993


                           TABLE OF CONTENTS

1 Introduction                                                         1
     1.1 Goals                                                         2
     1.2 Basic Concept                                                 2
     1.3 Overview                                                      3
2 Addressing                                                           3
3 Packet Forwarding                                                    4
     3.1 Forwarding Mode                                               4
     3.2 Autonomous Mode                                               5
            3.2.1 SH Transmission                                      6
            3.2.2 Autonomous Supporter Transmission                    7
4 Location Information Management                                      8
     4.1 MH Migration/PFS Notification                                 8
     4.2 Autonomous Sender Notification                               10
            4.2.1 Packets to the Home Address                         10
            4.2.2 Packets from an AS                                  11
            4.2.3 Packets from a Migrated MH                          12
     4.3 Packets to an Obsolete Temporary Address                     13
5 Internet Packet Transmission Protocol(IPTP)                         15
     5.1 Message Type                                                 15
     5.2 Parameters                                                   16
     5.3 Packet Format                                                19
     5.4 State Diagrams                                               21
     5.5 Packet Transmission Parameters                               25
6 Implementation Notes                                                25
     6.1 Translation Tables                                           25
     6.2 Avoiding Redundant "MH Location Information" Messages        26
     6.3 PFS Packet Interception                                      26
     6.4 Adaptive Mode Selection                                      27
     6.5 Detection of Forwarding Loops                                27
     6.6 Gateway Packet Filters                                       27
     6.7 Handling IP options                                          28
7 Acknowledgement                                                     28
8 Authors' Addresses                                                  28

















Expires 2 January 1994                                          [Page i]

Internet-Draft             Packet Forwarding                   July 1993


                           FIGURES

Figure 1. Forwarding Mode                                              5
Figure 2. Autonomous Mode                                              6
Figure 3. Forwarding mode by an autonomous supporter PFS               7
Figure 4. Location information distribution                            9
Figure 5. Packets to the Home Address                                 11
Figure 6. Packets from an AS                                          12
Figure 7. Packets from a Migrated MH                                  13
Figure 8. Packets to an Obsolete Temporary Address                    14
Figure 9. State diagram of an MH                                      21
Figure 10. State diagram of an SH                                     23
Figure 11. State diagram of a home PFS                                23
Figure 12. State diagram of an Autonomous Supporter                   24






































Expires 2 January 1994                                         [Page ii]