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 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 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 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]