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

Versions: 00                                                            
Internet Engineering Task Force                               Yunzhou Li
INTERNET DRAFT                                       National University
                                                            of Singapore
                                                         5 November 1996


       Proximity Proxies for Mobile Nodes and Mobility Agents (PPM)
                 draft-liyunzhou-mobileip-ppm-00.txt


Status of This Memo

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

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

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

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


Abstract

   This document aims to explore an approach for the interoperability
   testing of Mobile IP implementations across the Internet. It proposes
   client/server proximity proxies, two intermediate entities between
   the mobile node and the mobility agent. This model can be used to
   solve the problem addressed in the hierarchical foreign agents model.
   The document proposes to build a tunnel between proximity proxies
   using Tunnel Request and Tunnel Reply messages, and enable routing
   policies to the tunnel by using Proxy Update message and adding a bit
   in Agent Advertisement message.








Expires 5 May 1997                                              [Page i]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996




                                Contents



Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. PPM Overview                                                       2
     2.1. Client/Server Proxy . . . . . . . . . . . . . . . . . . .    2
     2.2. Client/Server Tunnel . . . . . . . . . . . .. . . . . . .    3
     2.3. Tunnel Requst and Tunnel Reply Messages . . . . . . . . .    3
     2.4. Agent Solicitation Message  . . . . . . . . . . . . . . .    3
     2.5. Agent Advertisement Message  . . . . . . . . . . .  . . .    4
     2.6. Proxy Update Message  . . . . . . . . . . . . . . . . . .    5

 3. PPM Message Formats                                                5
     3.1. Tunnel Request Message  . . . . . . . . . . . . . . . . .    6
     3.2. Tunnel Reply Message  . . . . . . . . . . . . . . . . . .    7
     3.3. Proxy Update Message  . . . . . . . . . . . . . . . . . .    8
     3.4. Agent Solicitation Message  . . . . . . . . . . . . . . .    9
     3.5. Agent Advertisement Message . . . . . . . . . . . . . . .   10

 4. PPM Extension Formats                                             11
     4.1. Server Proxy Extension  . . . . . . . . . . . . . . . . .   11
     4.2. Client Proxy Extension  . . . . . . . . . . . . . . . . .   11
     4.3. Mobile-Cleint Authentication Extension  . . . . . . . . .   12
     4.4. Client-Server Authentication Extension  . . . . . . . . .   12
     4.5. Server-Agent Authentication Extension . . . . . . . . . .   13

 5. Mobile Node Considerations                                        14
     5.1. Sending Agent Solicitation  . . . . . . . . . . . . . . .   14
     5.2. Receiving Agent Advertisement . . . . . . . . . . . . . .   14
     5.3. Handover  . . . . . . . . . . . . . . . . . . . . . . . .   14
     5.4. Sending Proxy Update  . . . . . . . . . . . . . . . . . .   15

 6. Client Proxy Considerations                                       16
     6.1. Sending Tunnel Request  . . . . . . . . . . . . . . . . .   16
     6.2. Receiving Tunnel Reply  . . . . . . . . . . . . . . . . .   16
     6.3. Receiving Agent Solicitation  . . . . . . . . . . . . . .   17
     6.4. Receiving Agent Advertisement . . . . . . . . . . . . . .   17
     6.5. Receiving Proxy Update  . . . . . . . . . . . . . . . . .   18





Expires 5 May 1997                                             [Page ii]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


 7. Server Proxy Consideration                                        19
     7.1. Receiving Tunnel Request  . . . . . . . . . . . . . . . .   19
     7.2. Receiving Agent Solicitation  . . . . . . . . . . . . . .   19
     7.3. Receiving Agent Advertisement . . . . . . . . . . . . . .   20
     7.4. Receiving Proxy Update  . . . . . . . . . . . . . . . . .   20

 8. Agent Considerations                                              21
     8.1. Receiving Agent Solicitation  . . . . . . . . . . . . . .   21
     8.2. Receiving Agent Advertisement . . . . . . . . . . . . . .   21
     8.3. Receiving Proxy Update  . . . . . . . . . . . . . . . . .   21

 9. Security Considerations                                           21

 References                                                           22
 Author's Address                                                     23





































Expires 5 May 1997                                            [Page iii]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


1. Introduction

   The mobile IP base protocol [1] allows mobile nodes to move from one
   point of physical attachment within the Internet to another. Under
   this physical attachment, it is difficult to test interoperability
   of a few Mobile-IP softwares over the Internet. For example, a mobile
   node running one Mobile-IP software is not able to connect to a
   foreign agent running another Mobile-IP software. Furthermore, a
   mobile node is not able to switch, over the Internet, from a subnet
   at one remote site to a subnet at another remote site.

   The second problem to be addressed here is what the hierarchical
   foreign agents model [2] discloses and has solved. That is, each time
   the mobile node moves, a Registration Request message has to be
   approved by the mobile node's Home Agent. In cases where the home
   agent is far away, it may become too expensive or even impossible to
   complete these frequent registrations.

   This document proposes Proximity Proxies for Mobile Nodes and
   Mobility Agents (PPM), as an extension to the base protocol, in
   anticipation to solve these two problems. Under the base protocol, a
   mobile node can change its physical attachment to various links while
   maintaining its Internet connection. The PPM model provides a tunnel
   attachment mechanism by introducing pairs of proximity proxies,
   intermediate entities between mobile nodes and mobility agents.

   The proximity proxies are built on a client-server model.  A client
   proxy has a physical attachment to and serves mobile nodes, and a
   server proxy has a physical attachment to and serves mobility agents.
   A mobile node is said to have a tunnel attachment to a mobility agent
   if, there is a tunnel between the client and the server, and the
   client and the server respectively act as proximity proxies to the
   agent and the mobile node. By proximity proxies, we mean they have
   proximity function not necessarily using Proxy ARP. Thus the server
   will be able to attract packets from the agent and tunnel them to the
   mobile node via the client. In the reverse direction, the client will
   be able to attract packets from the mobile node and tunnel them to
   the agent via the server.

   Under this model, Mobile-IP tests over the Internet become feasible.
   Each mobile node can be constantly connected to a client. The client
   can frequently request to switch its tunnel from a server in a remote
   site to that in another remote site. Thus a mobile node can change
   its tunnel attachment from one remote agent to another. This model is
   also able to assist a mobile node in mobility diagnostic. Before a
   mobile node departs from its home subnet, it can have a client in
   control and diagnose whether the Internet connection to its
   destination will be broken or not.



Expires 5 May 1997                                              [Page 1]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


   Under this model, the second problem can be solved by properly
   deploying servers and clients. For example, a foreign agent and a
   server proxy can be deployed in an autonomous system (AS), but more
   clients can be deployed within the AS. The clients maintains constant
   tunnels with the server. A mobile node moves around in the AS but is
   always attached to the agent over a tunnel. Thus no mobile node
   necessarily re-registers a new binding or registers simultaneous
   bindings while moving within the AS. Later the document demonstrates
   that both the agent and the server are able to keep track of mobile
   nodes and thus act as exchangers in this "switching network".

   Tunneling methods can be found in [4] and [5]. The document also
   allows to use other methods to build a tunnel, especially provided in
   a heterogeneous network. To synchronize bi-directional tunnel between
   client proxy and server proxy, a client is allowed to send a Tunnel
   Request message to the server, and the server responds with a Tunnel
   Reply message.

   To get a client to be a proximity proxy to a mobility agent, the
   document requires the server to tunnel Agent Advertisement messages
   to the client. To get a server to be a proximity proxy to a mobile
   node, the mobile node is required to address Proxy Update messages to
   the server via a client. Proxy Update messages can be used by the
   mobility agent and the server to keep track of the mobile node.

   To indicate an intent to receive Proxy Update or request more
   information, the document defines a P-bit in Agent Solicitation
   message and Agent Advertisement message, and allows to include Server
   Proxy extension and Client Proxy extension in Agent Advertisement
   messages and Proxy Update messages.


2. PPM Overview

2.1. Client/Server Proxy

   The PPM model provides two new entities, client proxy and server
   proxy. These two entities are intermediate proximity proxies between
   mobile node and mobility agent.

   A client proxy, in short, client, is an Internet node that is on a
   link, on which mobile nodes may visit. It is called "client" in that
   it may request a server to build a tunnel towards itself. The client
   may work as a proximity proxy to a mobility agent without necessarily
   using proxy ARP. The client should enable a routing policy so that
   packets for the agent can be routed to the tunnel.

   A server proxy, in short, server, is an Internet node on a link, on
   which one or more mobility agents reside. It is called "server" in


Expires 5 May 1997                                              [Page 2]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


   that it can serve to build a tunnel towards a client upon its request.
   The server may work as a proximity proxy to a mobile node without
   necessarily using proxy ARP.  The server should enable a routing
   policy so that packets for the mobile node can be routed to the
   tunnel.

2.2. Client/Server Tunnel

   A tunnel between a client and a server can be built using methods in
   [4] and [5], or other methods. Hereafter, it is assumed that a method
   in [4] or [5] is used, and thus the tunnel could be bi-directional.

   The bi-directional tunnel should be built simultaneously. A client
   should build a uni-directional tunnel from the client to a server if
   and only if the server agrees to build a tunnel from the server to
   the client.

2.3. Tunnel Requst and Tunnel Reply Messages

   Tunnel Request and Tunnel Reply messages are designed to synchronize
   building the bi-directional tunnel between a client and a server.

   To build a tunnel, the client needs to know the IP address of the
   server. However, the discovery of server addresses is not the purpose
   of this document and should be specified elsewhere.

   A client should maintain at least a tunnel to a server. Thus at the
   system startup, the client should send a Tunnel Request to a server.
   The client should retransmit Tunnel Request if it does not receive a
   Tunnel Reply in a reasonable time, until it reaches a maximum number
   of retransmissions. The client can build more tunnels to other
   servers if necessary.

   Upon receipt of a Tunnel Request, the server should respond with
   a Tunnel Reply with a proper lifetime if the server can honor this
   request. The server should build a uni-directional tunnel to the
   client under the agreement with the client.

   Upon receipt of a matched Tunnel Reply, the client should build a
   uni-directional tunnel to the server. Thus the building of the
   bi-directional tunnel is synchronized.

   The bi-directional tunnel is valid within the lifetime granted by the
   server. The client should extend the lifetime by starting another
   transaction of Tunnel Request/Tunnel Reply before the tunnel expires.

2.4. Agent Solicitation Message

   Agent Solictation messages are sent from mobile node to mobility


Expires 5 May 1997                                              [Page 3]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


   agents via clients and servers. If a mobile node or a client turns on
   the P-bit in a solicitation, it means to know more information. A
   client or a server receiving such a solicitation should respectively
   append Client Proxy extension and Server Proxy extension to
   subsequent Agent Advertisement messages.

   On receiving an Agent Solicitation message,

   - a client should tunnel the message to all the associated servers;
     the client should set up a solicitation P-bit flag for the mobile
     node if the message comes with the P-bit set;

   - a server should forward the message to a link on which mobility
     agents reside; the server should set up a solicitation P-bit flag
     for the client if the message comes with the P-bit set;

   - an agent should respond with an Agent Advertisement message.

2.5. Agent Advertisement Message

   Agent Advertisement messages are critical to clients. A client can
   enable a routing policy for an agent only if it receives an Agent
   Advertisement.

   To encourage a mobile node to issue Proxy Update messages, the P-bit
   in advertisement should be turned on. If a mobility agent or a server
   turns on the P-bit, it means to know more information. A server or a
   client receiving such an advertisement should respectively append
   Server Proxy extension and Client Proxy extension to subsequent Proxy
   Update messages.

   On receiving an Agent Advertisement,

   - a server should tunnel the message to all the associated clients;
     if there is a solicitation P-bit flag for a client, the server
     should individually append a Server Proxy extension to the message
     for the client; the server should update the advertisement P-bit
     status for the agent with the P-bit in the message;

   - a client should forward the message to the link on which mobile
     nodes may visit, and enable a routing policy so that, all packets
     addressed to the advertising agent can be tunneled to the server;
     the routing policy is valid within the advertisement lifetime in
     the message, and should be disabled upon its expiry;

     if there is a solicitation P-bit flag for a mobile node, the client
     should individually append a Client Proxy extension to the message
     for the mobile node; the client should update the advertisement
     P-bit status for the server with the P-bit in the message;


Expires 5 May 1997                                              [Page 4]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


   - a mobile node should update the advertisement P-bit status for the
     agent or the client with the P-bit in the message; the mobile node
     should send a Proxy Update message before starting a registration
     procedure if the advertisement P-bit status for the agent or the
     client is on.

2.6. Proxy Update Message

   Proxy Update messages are critical to servers. A server can enable
   a routing policy for a mobile node only if it receives a Proxy Update
   message.

   On receiving a Proxy Update message,

   - a client should forward the message to the server, to which the
     client imposed a routing policy for the agent specifed in the
     message;

     the client should append a Client Proxy extension to the message
     if the advertisement P-bit status for the server is on;

   - a server should enable a routing policy so that, all packets
     addressed to the mobile node (specified in the message) can be
     tunneled to the client, from which the message comes. The routing
     policy is valid within the lifetime specified in the message, and
     should be disabled upon its expiry.

     The server should append a Server Proxy extension to the message
     and forward the message to the agent (specified in the message) if
     the advertisement P-bit status for the agent is on;

   - an agent may locate the relevant mobile node, and redirect mobile
     traffic to a relevant server if a change in the mobile node's
     attachment is detected.


3. PPM Message Formats

   The PPM model defines three types of UDP messages, with the first
   one-octet defined as message type:

       32 = Tunnel Request Message
       33 = Tunnel Reply Message
       34 = Proxy Update Message

   The PPM model also requires two minor changes: a new flag bit must be
   added to the Agent Solicitation message and the Agent Advertisement
   message, replacing a previously unused, reserved bit in the message.


Expires 5 May 1997                                              [Page 5]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


3.1. Tunnel Request Message

   Tunnel Request is used for a client to request a tunnel from a server
   to it. A client should maintain the tunnel or otherwise stop
   forwarding Agent Advertisements.

   IP fields:

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

      Destination Address   Typically the IP address of the server.

   UDP fields:

      Source Port           <variable>

      Destination Port      434

   The UDP header is followed by the fields shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Reserved    |          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type     32 (Tunnel Request)

      Reserved sent as zero; ignored on reception.

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

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

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

Expires 5 May 1997                                              [Page 6]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


3.2. Tunnel Reply Message

   A server returns a Tunnel Reply message to a client which has sent a
   Tunnel Request (Section 3.1) message. The Reply message contains the
   necessary codes to inform the client about the status of its Request,
   along with the lifetime granted by the server, which MAY be smaller
   than the original Request.

   IP fields:

      Source Address        Typically copied from the destination
                            address of the Tunnel Request to which
                            the server is replying.

      Destination Address   Copied from the source address of the
                            Tunnel Request to which the server is replying

   UDP fields:

      Source Port           <variable>

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

   The UDP header is followed by the fields shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type     33 (Tunnel Reply)

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









Expires 5 May 1997                                              [Page 7]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


      Lifetime
               If the Code field indicates that the server agrees to
               build the tunnel, the Lifetime field is set to the number
               of seconds remaining before the tunnel is considered
               expired.  A value of zero indicates that the tunnel has
               been disconnected.  A value of 0xffff indicates infinity.
               If the Code field indicates that the tunnel was denied,
               the contents of the Lifetime field are unspecified and
               MUST be ignored on reception.

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

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

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

        0 tunnel connected

       64 reason unspecified
       65 administratively prohibited
       66 insufficient resources
       67 client failed authentication
       68 requested Lifetime too long
       69 poorly formed message

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

3.3. Proxy Update Message

   Proxy Update messages are used not only for server to enable routing
   policies, but for client, server and mobility agent to keep track of
   mobile nodes. A Proxy Update can be sent from a mobile node to a
   client, from the client to a server, and from the server to the agent
   in that order. A mobile node should issue Proxy Update periodically.

   IP fields:

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




Expires 5 May 1997                                              [Page 8]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


      Destination Address   Typically that of the client, the server or
                            the agent if the message is sent from the
                            mobile node, the client or the server,
                            respectively.

   UDP fields:

      Source Port           <variable>

      Destination Port      434

   The UDP header is followed by the fields shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Reserved   |          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Home Address                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Agent Address                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type     34 (Proxy Update)

      Reserved sent as zero; ignored on reception.

      Lifetime
               The number of seconds remaining before the mobile node is
               considered away from a client.

      Home Address
               The home address of the mobile node.

      Agent Address
               The mobility agent address at the interface towards the
               mobile node.

      Extensions
               The fixed portion of the Proxy Update is followed by one
               or more of the Extensions

3.4. Agent Solicitation Message

   One bit is added to the flag bits in the Agent Solicitation message
   to indicate an intent to receive more information from subsequent
   Agent Advertisement messages.


Expires 5 May 1997                                              [Page 9]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


   Thus, the Agent Solicitation message under the PPM model is:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |P|                         Reserved                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Proxy (P)

         The Proxy (P) bit is set by the mobile node or the client
         to indicate its intent to receive more information from
         subsequent Agent Advertisement messages.

3.5. Agent Advertisement Message

   One bit is added to the flag bits in the Agent Advertisement message
   to indicate an intent to receive Proxy Update messages or to receive
   more information from subsequent Proxy Update messages.

   Thus, the Agent Advertisement message under the PPM model begins as
   follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Registration Lifetime      |R|B|H|F|M|G|V|T|P|  reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | (unchanged...)
   +-+-+-

      Proxy (P)

         The Proxy (P) bit is set by the agent or the client to indicate
         its intent to receive Proxy Update messages, or by the server
         or the client to indicate its intent to receive more
         information from subsequent Proxy Update messages. A client
         MUST have this bit set when it forwards an Agent Advertisement
         message.








Expires 5 May 1997                                             [Page 10]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


4. PPM Extension Formats

   The PPM model defines the following Mobile IP message extensions:

      112 = Server Proxy Extension
      113 = Client Proxy Extension
      114 = Mobile-Client Authentication Extension
      115 = Client-Server Authentication Extension
      116 = Server-Agent Authentication Extension

   The PPM messages may include Mobile-Foreign Authentication extension
   defined in [1].

   This section describes each of the new PPM message extensions.

4.1. Server Proxy Extension

   The Server Proxy extension may be included in an Agent Advertisement
   message, or a Proxy Update 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      |     Length    | No. of Agents | No. of Clients|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Server Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type            112

      Length          12

      No. of Agents   The number of agents on the same link as the
                      server.

      No. of Clients  The number of clients associated with the
                      server over tunnels.

      Server Address  The IP address of the server proxy

4.2. Client Proxy Extension

   The Client Proxy extension may be included in an Agent Advertisement
   message or a Proxy Update message.







Expires 5 May 1997                                             [Page 11]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    | No. of Servers|  No. of MNs   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Client Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type            113

      Length          12

      No. of Servers  The number of servers associated with the
                      client over tunnels.

      No. of MNs      The number of mobile nodes on the same link
                      as the client.

      Client Address  The IP address of the client proxy

4.3. Mobile-Cleint Authentication Extension

   This extension MAY be present in Proxy Update messages from a mobile
   node to a client, in cases in which a mobility security association
   exists between the mobile node and the client.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ... SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type            114

      Length          4 plus the number of bytes in the Authenticator.

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

      Authenticator   (variable length)

4.4. Client-Server Authentication Extension

   This extension MUST be present in Agent Solicitation messages, Agent
   Advertisement messages and Proxy Update messages between a client to
   a server. The document requires that a proxy security association
   must exist between the client and the server.


Expires 5 May 1997                                             [Page 12]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ... SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type            115

      Length          4 plus the number of bytes in the Authenticator.

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

      Authenticator   (variable length)

4.5. Server-Agent Authentication Extension

   This extension MAY be present in a Proxy Update message from a server
   to an agent, in cases in which a mobility security association exists
   between the server and the agent.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ... SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type            116

      Length          4 plus the number of bytes in the Authenticator.

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

      Authenticator   (variable length)












Expires 5 May 1997                                             [Page 13]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


5. Mobile Node Considerations

   The PPM model requires that a mobile node keep looking at the P-bit
   and the source link address in received Agent Advertisement messages.

   An advertisement without P-bit set is directly from a mobility agent.
   An advertisement with P-bit set is from either a mobility agent or a
   client.

   A change in the source IP address of advertisement means that a
   different agent has been detected. But a change in the source link
   address means that a different client has been detected.

   A mobile node is considered away from an agent if, the mobile node
   does not receive any advertisement from the agent IP address within
   the advertisement lifetime. A mobile node is considered away from a
   client if, the mobile node does not receive any advertisement from
   the client link address within the advertisement lifetime.

5.1. Sending Agent Solicitation

   The mobile node MAY send an Agent Solicitation message with P-bit
   set to request more information from clients or agents.

5.2. Receiving Agent Advertisement

   Once the mobile node receives an Agent Advertisement, it MUST update
   the advertisement P-bit status for the agent or the client with the
   P-bit in the message, and copy its source IP address and source link
   address.

   If the P-bit status changes from on to off, the mobile node SHOULD
   stop sending Proxy Update messages. But if the P-bit status changes
   from off to on, the mobile node MUST send Proxy Update messages as
   in section 5.4.

   If the agent table is empty before the mobile node receives this
   advertisement with P-bit set, the mobile node SHOULD send Proxy
   Update messages before attempting to register a binding.

5.3. Handover

   When the mobile node considers itself away from the agent currently
   serving it, it SHOULD check its agent table to find another agent. If
   there is no more agent on the table, no further action SHOULD be
   taken. Otherwise, before the mobile node attempts to register a new
   binding with the new agent,




Expires 5 May 1997                                             [Page 14]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


   - if the client associated with the disappearing agent is still on
     the client table and also sends advertisements on behalf of the new
     agent, the mobile node SHOULD put the new agent address in the
     subsequent Proxy Update messages to this client;

   - or otherwise, the mobile node MUST stop sending Proxy Update
     messages to this client, choose another client that is sending
     advertisements on behalf of the new agent, and send Proxy Update
     messages to the new client by updating with the new agent.

   If the mobile node is not away from the agent currently serving it
   but away from the client currently serving it, it MUST stop sending
   Proxy Update messages to the client. It SHOULD search its client
   table for another client that is sending advertisements on behalf of
   the same agent. A failure in this search is an error and SHOULD be
   logged. If there is such a client, the mobile node SHOULD send Proxy
   Update messages to the new client by updating with the agent.

5.4. Sending Proxy Update

   The mobile node SHOULD send Proxy Update messages

   - before it attempts to register a binding and the P-bit status for
     the relevant agent or client is on; or

   - if the mobile node is away from the client currently serving it,
     and has chosen a new client on the client table.

   The lifetime in the Proxy Update is the time within which the mobile
   node is considered reachable to the client. The mobile node SHOULD
   send a new Proxy Update message before it is considered away from the
   client, unless the mobile node does not require the service from the
   agent via the client.

   The mobile node MAY append a Mobile-Client Authetication extension to
   the Proxy Update messages if there exists the mobility security
   association between the mobile node and the client.














Expires 5 May 1997                                             [Page 15]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


6. Client Proxy Considerations

   A client works on behalf of mobility agents. It can be associated
   with an agent upon receipt of an Agent Advertisement message. To
   receive such an advertisement, a tunnel from a server to it SHOULD
   be built up by sending Tunnel Request message.

6.1. Sending Tunnel Request

   At the system startup, A client SHOULD build up at least one tunnel
   to a server. The discovery of server addresses is not the purpose of
   this document, and SHOULD be discussed elsewhere.

   To build a bidirectional tunnel between a client and a server, the
   client SHOULD send a Tunnel Request to the server. The client SHOULD
   include a desired lifetime in the Tunnel Request.

   The client SHOULD retransmit Tunnel Request if it has not received
   a matched Tunnel Reply in a reasonable time. Failure in receipt of
   such a Tunnel Reply message after a maximum of retransmissions SHOULD
   be logged for further administrative option.

   The identification SHOULD be implemented as a timestamp or a nonce
   specified in the base protocol [1].

   The client SHOULD append a Client-Server Autentication extension to
   the Tunnel Request message. The PPM model requires that there be a
   proxy security association between the client and the server.

6.2. Receiving Tunnel Reply

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

   - the UDP checksum is valid;

   - the low-order 32 bits of the Identification field in the Tunnel
     Reply equals to the low-order 32 bits of the Identification field
     in the most recent Tunnel Request sent to the server; AND

   - the reply include a Client-Server Autentication extension at the
     end and the Authenticator is valid.

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

   If the code field indicates that the server refuses to build the
   tunnel because the lifetime is too long, the client MAY resend a
   Tunnel Request with a proper lifetime.



Expires 5 May 1997                                             [Page 16]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


   If the code field indicates that the server refuses to build the
   tunnel, but there already exists a tunnel to the server, the tunnel
   SHOULD remain until its expiry. The code SHOULD be logged.

   If the code field is positive but the lifetime is zero, the client
   MUST remove the existing tunnel to the server if any.

   If the server agrees to build the tunnel by granting a proper
   lifetime, the client MUST build or reset the unidirectional tunnel to
   the server. The tunnel is valid within the granted lifetime and
   SHOULD be removed upon its expiry. To extend the lifetime of the
   tunnel, the client SHOULD send a Tunnel Request message to the server
   a reasonable time before the tunnel expires.

6.3. Receiving Agent Solicitation

   If the client receives an Agent Solicitation message, it SHOULD
   set up a solicitation P-bit flag for the mobile node if the message
   comes with the P-bit set, and MUST tunnel it to all the associated
   servers. The client MAY turn on the P-bit to request more information
   from servers.

   The client SHOULD append a Client-Server Autentication extension to
   the solicitation message. The PPM model requires that there be a proxy
   security association between the client and the server.

6.4. Receiving Agent Advertisement

   Upon receipt of an Agent Advertisement, the client MUST check the
   validity of the message. The advertisement is valid if

   - the ICMP checksum is valid;

   - it is received from a tunnel; AND

   - the message includes a Client-Server Autentication extension at the
     end and the Authenticator is valid.

   An invalid advertisement SHOULD be silently discarded.

   If the client receives a valid Agent Advertisement message, it SHOULD
   update the advertisemnt P-bit status for the server with the P-bit in
   the advertisement. The client SHOULD forward the advertisement to the
   link on which the client serves mobile nodes. In the advertisement to
   be forwarded, the client MUST turn on the P-bit and strip off the
   Client-Server Authetication extension. If there is a solicitation
   P-bit flag for a mobile node, the client SHOULD individually append a
   Client Proxy Extension for the mobile node.



Expires 5 May 1997                                             [Page 17]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


   the client MUST additionally enable a routing policy so that all
   packets addressed to the advertising agent can be tunneled to the
   server from which the message comes. The routing policy is valid
   within the the advertisement lifetime and SHOULD be disabled upon its
   expiry.

6.5. Receiving Proxy Update

   Upon receipt of a Proxy Update message from a mobile node, the client
   MUST check the validity of the message. The Proxy Update is valid if

   - the UDP checksum is valid;

   - there is a routing policy for tunneling to a server all the packets
     destined for the agent specified in the message; AND

   - the Authenticator is valid if the message includes a Mobile-Client
     Autentication extension at the end.

   An invalid Proxy Update SHOULD be silently discarded.

   The client MUST forward a valid Proxy Update message to the relevant
   server.  In the message to be forwarded, the client MUST strip off
   the Mobile-Client Authetication extension if any, and SHOULD append a
   Client Proxy extension if the advertisement P-bit status for the
   server is on.

   The client SHOULD additionally append a Client-Server Autentication
   extension to the message. The PPM model requires that there be a
   proxy security association between the client and the server.





















Expires 5 May 1997                                             [Page 18]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


7. Server Proxy Considerations

   A server works on behalf of mobile nodes. It can be associated with a
   mobile node upon receipt of a Proxy Update message. To receive such a
   message, a tunnel from a client to it SHOULD be built up by answering
   Tunnel Request with Tunnel Reply.

7.1. Receiving Tunnel Request

   Upon receipt of a Tunnel Request, the client MUST check the validity
   of the message. The request is valid if

   - the UDP checksum is valid; AND

   - the message includes a Client-Server Autentication extension at the
     end and the Authenticator is valid.

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

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

   If the server is not able to honor the request, it SHOULD put a
   proper code in the reply.

   If the server denies the request and remove the existing tunnel to
   the client, it SHOULD set the code to a positive value (0) and the
   lifetime to 0.

   Otherwise, if the server agrees to build or reset a tunnel to the
   client, it SHOULD set the code to a positive value (0) and the
   lifetime to a value not greater than that in the original Request.
   The server MUST build a tunnel to the client if there is not such a
   tunnel, or reset the existing tunnel to the client with the granted
   lifetime. The tunnel is valid within the granted lifetime and SHOULD
   be removed upon its expiry.

7.2. Receiving Agent Solicitation

   Upon receipt of an Agent Solicitation, the server MUST check the
   validity of the message. The solicitation is valid if

   - the ICMP checksum is valid;

   - it is received from a tunnel; AND

   - the message includes a Client-Server Autentication extension at the
     end and the Authenticator is valid.


Expires 5 May 1997                                             [Page 19]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


   An invalid solicitation SHOULD be silently discarded.

   If the server receives a valid Agent Solicitation message, it SHOULD
   set up a solicitation P-bit flag for the client if the message comes
   with the P-bit set, and MUST broadcast the message on the link
   connected to a mobility agent. The server MUST strip off the Client-
   Server Autentication extension from the broadcast message.

7.3. Receiving Agent Advertisement

   Upon receipt of an Agent Advertisement message, the server SHOULD
   update the advertisement P-bit status with the P-bit in the message,
   and MUST tunnel the message to the relevant client if it is a
   unicast, or to all the associated clients if it is a broadcast. If
   there is a solicitation P-bit flag for a client, the server SHOULD
   individually append a Server Proxy extension for the client.

   The server SHOULD append a Client-Server Autentication extension to
   the advertisement message. The PPM model requires that there be a
   proxy security association between the server and the server.

7.4. Receiving Proxy Update

   Upon receipt of a Proxy Update message, the server MUST check the
   validity of the message. The Proxy Update is valid if

   - the UDP checksum is valid;

   - it is received from a tunnel; AND

   - the message includes a Client-Server Autentication extension at the
     end and the Authenticator is valid.

   An invalid Proxy Update SHOULD be silently discarded.

   Upon receipt of a valid Proxy Update message, the server MUST enable
   a routing policy so that all packets addressed to the mobile node
   (specified in the message) can be tunneled to the client from which
   the message comes. The routing policy is valid within the lifetime
   specified in the Porxy Update message and SHOULD be disabled upon its
   expiry.

   If the advertisement P-bit status for the agent is on, the server
   SHOULD forward the message to the agent. In this message, the server
   MUST strip off the Client-Server Autentication extension, SHOULD
   append a Server Proxy extension, and MAY append a Server-Agent
   Authetication extension.




Expires 5 May 1997                                             [Page 20]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


8. Agent Considerations

   In general, the PPM model does not impose more requirements to the
   mobility agent. But an enhancement to the agent is recommended.

8.1. Receiving Agent Solicitation

   There is no further requirement and enhancement to this message for
   mobility agents.

8.2. Sending Agent Advertisement

   A mobility agent MAY refuse to receive Proxy Update messages by
   turning off the P-bit in Agent Advertisement messages.

   If the agent intends to keep track of mobile nodes, however, it
   SHOULD turn on the P-bit in Agent Advertisement messages.

8.3. Receiving Proxy Update

   An mobility agent MAY silently discard a received Proxy Update
   message if it does not support the PPM model.

   If the agent supports the PPM model, upon receipt of a Proxy Update
   message, the agent MUST check the validity of the message. The Proxy
   Update is valid if

   - the UDP checksum is valid;

   - the Authenticator is valid if the message includes a Server-Agent
     Autentication extension at the end.

   An invalid Proxy Update SHOULD be silently discarded.

   If the agent intends to keep track of  mobile nodes, however, it
   SHOULD look into the message. Packets addressed to the mobile node
   SHOULD be sent to a server or the mobile node, from which a most
   recent Proxy Update was received.  In addition, the agent SHOULD
   balance traffic load among servers by looking into Proxy Update
   messages.


9. Security Considerations

   The security issue is open for further discussion.






Expires 5 May 1997                                             [Page 21]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


References

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

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

   [3]  W. Simpson.  IP in IP Tunneling.  RFC 1853, October 1995.

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

   [5]  Charles Perkins.  Minimal Encapsulation within IP. RFC 2004.
        October 1996.

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

   [7]  David C. Plummer.  An Ethernet Address Resolution Protocol:
        Or Converting Network Protocol Addresses to 48.bit Ethernet
        Addresses for Transmission on Ethernet Hardware.  RFC 826,
        November 1982.

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

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

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

















Expires 5 May 1997                                             [Page 22]


Internet Draft        Mobile IP Proximity Proxies        5 November 1996


Author's Address

   Questions about this memo can also be directed to:

          Yunzhou Li
          Department of Information Systems and Computer Science
          National University of Singapore
          Lower Kent Ridge Road
          Singapore 119260

          Work:   +65 772-6891 (Y.C. Tay c/o)
          Fax:    +65 779-5452 (Y.C. Tay c/o)
          E-mail: scip4166@nus.sg






































Expires 5 May 1997                                             [Page 23]