Internet Engineering Task Force David B. Johnson INTERNET DRAFT Carnegie Mellon University draft-johnson-imhp-00.txt Andrew Myles Macquarie University Charles Perkins IBM Corporation 14 February 1994 The Internet Mobile Host Protocol (IMHP) Abstract This document specifies the Internet Mobile Host Protocol (IMHP), which allows transparent routing of IP packets to mobile hosts in the Internet, while using only the mobile host's "home" IP address. No changes are required in stationary hosts that communicate with mobile hosts, and no changes are required in mobile hosts above the IP level. IMHP quickly converges to optimal routing following the movement of a mobile host, while maintaining the "weak security" model of today's Internet. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the Mobile IP Working Group or the IETF. It is our hope to better explain the issues and to stimulate discussion, in order to assist the Working Group in its efforts to develop a single Group draft protocol specification. This document has not been approved by the Mobile IP Working Group. Johnson, Myles, Perkins Expires 14 August 1994 [Page i] Internet Draft Internet Mobile Host Protocol 14 February 1994 Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as "working drafts" or "work in progress". Please check lid-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of an Internet Draft. Johnson, Myles, Perkins Expires 14 August 1994 [Page ii] Internet Draft Internet Mobile Host Protocol 14 February 1994 Contents Abstract i Status of This Memo ii 1. Introduction 1 2. Terminology 3 3. Infrastructure 6 3.1. Mobile Host . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Foreign Agent . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Cache Agent . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Home Agent . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Home Network . . . . . . . . . . . . . . . . . . . . . . 9 4. IMHP Security 11 4.1. Security Model Definitions . . . . . . . . . . . . . . . 11 4.1.1. The Insecure Model . . . . . . . . . . . . . . . 11 4.1.2. Strong Security Model . . . . . . . . . . . . . . 11 4.1.3. Weak Security Model . . . . . . . . . . . . . . . 12 4.2. Weak Security Implementation in IMHP . . . . . . . . . . 12 4.2.1. Home Agent to Mobile Host Authentication . . . . 12 4.2.2. Obtaining Authenticated Bindings . . . . . . . . 13 4.2.3. Optimizing Previous Foreign Agent Notifications . 14 4.2.4. Security and Forwarding . . . . . . . . . . . . . 15 4.2.5. Advertising Mobile Host Locations . . . . . . . . 16 5. Tunneling 17 6. Forwarding Rules 18 7. Foreign Agent Discovery 20 7.1. Agent Advertisement Message . . . . . . . . . . . . . . . 20 7.2. Agent Solicitation Message . . . . . . . . . . . . . . . 21 7.3. Lower Network Layer Support . . . . . . . . . . . . . . . 22 7.4. Mobile Host Movement Discovery . . . . . . . . . . . . . 22 8. Registration Procedures 24 8.1. Overview of Initial Registration Procedures . . . . . . . 24 8.2. Overview of Re-registration Procedures . . . . . . . . . 25 8.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 26 8.4. Registration Request Message Fields . . . . . . . . . . . 27 Johnson, Myles, Perkins Expires 14 August 1994 [Page iii] Internet Draft Internet Mobile Host Protocol 14 February 1994 8.5. Registration Reply Message Fields . . . . . . . . . . . . 28 8.6. Foreign Agent Registration . . . . . . . . . . . . . . . 29 8.6.1. Sending the Registration Request Message . . . . 29 8.6.2. Foreign Agent Processing of Registration Request 30 8.6.3. Foreign Agent Registration Operations . . . . . . 31 8.6.4. Mobile Host Processing of Registration Reply . . 32 8.7. Home Agent Registration . . . . . . . . . . . . . . . . . 33 8.7.1. Sending the Registration Request Message . . . . 33 8.7.2. Foreign Agent Processing of Registration Request 34 8.7.3. Home Agent Processing of Registration Request . . 34 8.7.4. Home Agent Registration Operations . . . . . . . 35 8.7.5. Foreign Agent Processing of Registration Reply . 36 8.7.6. Mobile Host Processing of Registration Reply . . 36 8.8. Home Network Registration . . . . . . . . . . . . . . . . 36 8.9. De-registration . . . . . . . . . . . . . . . . . . . . . 37 8.9.1. Mobile Host Initiated De-registration . . . . . . 37 8.9.2. Foreign Agent Initiated De-registration . . . . . 38 9. Notifying Previous Foreign Agents 39 9.1. Previous Foreign Agent List . . . . . . . . . . . . . . . 39 9.2. Notification Methods . . . . . . . . . . . . . . . . . . 40 9.3. Binding Notify Message . . . . . . . . . . . . . . . . . 41 9.4. Previous Foreign Agent Operations . . . . . . . . . . . . 42 9.5. Binding Acknowledge Message . . . . . . . . . . . . . . . 43 9.6. Mobile Host Operations . . . . . . . . . . . . . . . . . 43 9.7. Retransmissions . . . . . . . . . . . . . . . . . . . . . 43 10. Other Management Procedures 44 10.1. Notifying Other Entities . . . . . . . . . . . . . . . . 44 10.2. Acquiring Authenticated Mobile Host Bindings . . . . . . 45 10.2.1. Sending a Binding Inquire Message . . . . . . . . 46 10.2.2. Processing a Binding Inquire Message . . . . . . 47 10.2.3. Processing the Binding Notify Message . . . . . . 47 11. Packet Transmission Examples 49 11.1. Mobile Host to Mobile Host Communications . . . . . . . . 49 11.2. Mobile Host Movement . . . . . . . . . . . . . . . . . . 50 11.3. Stationary Host to Mobile Host . . . . . . . . . . . . . 51 11.4. Routing Loop Resolution Between Home Agent and Foreign Agent . . . . . . . . . . . . . . . . . . . . 52 11.5. Routing Loop Resolution Between Cache Agents . . . . . . 53 12. Other Issues 54 12.1. Registration on a Home Network . . . . . . . . . . . . . 54 12.2. Location Cache and Visitor List Time Outs . . . . . . . . 56 12.3. Popups . . . . . . . . . . . . . . . . . . . . . . . . . 56 12.4. Intermediate Cache Agents . . . . . . . . . . . . . . . . 57 12.5. Password Algorithms . . . . . . . . . . . . . . . . . . . 57 Johnson, Myles, Perkins Expires 14 August 1994 [Page iv] Internet Draft Internet Mobile Host Protocol 14 February 1994 13. IMHP Management Packet Formats 59 13.1. Agent Advertisement Message . . . . . . . . . . . . . . . 61 13.2. Agent Solicitation Message . . . . . . . . . . . . . . . 63 13.3. Registration Request Message . . . . . . . . . . . . . . 65 13.4. Registration Reply Message . . . . . . . . . . . . . . . 70 13.5. Binding Inquire Message . . . . . . . . . . . . . . . . . 75 13.6. Binding Notify Message . . . . . . . . . . . . . . . . . 77 13.7. Binding Acknowledge Message . . . . . . . . . . . . . . . 80 References 82 Authors' Addresses 83 Johnson, Myles, Perkins Expires 14 August 1994 [Page v] Internet Draft Internet Mobile Host Protocol 14 February 1994 1. Introduction Computers are no longer large, expensive, and non-portable. Recent developments make it possible to buy inexpensive notebook and palmtop computers that are both portable and extremely powerful. As a result, people are not constrained to using their computers in a single location. At the same time, computer networking is becoming indispensable to the average user. The ability to access information and to communicate globally has amplified the utility of computers many times over. Users increasingly want to attach to the network with the same level of service, regardless of where they happen to be working. A typical user might usually connect to the network at his desk, but occasionally will take the computer to a conference room in another part of the building, or even at another site. However, today's networking protocols, including the TCP/IP and the OSI protocol suites, generally assume that each computer attaches to the network at a fixed physical location, logically encoded into the network address of that computer. In these protocols today, host movement is assumed to occur so rarely that it can be handled manually. For example, consider the host movement scenario described above using IP [9]. If the user's desk and the conference room have direct access to the same IP subnet, then the movement process is trivial. Otherwise, the user must acquire a new IP address on the conference room subnet from the appropriate local authority, which may not be an easy task. Numerous configuration files on the moving host, on multiple name servers, and on other hosts (that use the original IP address to identify the moving host) must then be modified to reflect the new address of the moving host. This process achieves network connectivity as the host moves, but only after a slow, error prone configuration procedure that a typical user does not have the skills or desire to carry out. In addition, the moving host has a completely different identity after these changes, and all existing network applications must be restarted. Clearly, additional protocols are needed to allow this type of host movement to be achieved transparently to the user. Ease of movement will become even more important as wireless network interfaces become widely available. Once the user is unconstrained by cable, it is likely that frequent network movement will become common. Host movement may not even be under the user's control. For example, if a mobile host operates in overlapping wireless cells, the host may move from one cell to another based on dynamic factors such Johnson, Myles, Perkins Expires 14 August 1994 [Page 1] Internet Draft Internet Mobile Host Protocol 14 February 1994 as load and noise. Protocols to support host mobility will not only have to be transparent, they will have to be efficient so that they can handle rapid host movement. Increasingly, computer networks are being interconnected into a single global network. This trend will continue with the proliferation of metropolitan and wide area network services. The Internet is a good example of a growing global network. Users already have access to network facilities anywhere in the world, not just in the local area. The new protocols should therefore be designed to operate optimally in both the local and wide area cases. This document specifies a new protocol, called the Internet Mobile Host Protocol (IMHP), that allows mobile hosts to move rapidly around both the local and the wide area network in an IP environment. The protocol attempts to optimize routing to a mobile host, and extends the existing IP architecture so that mobility can occur transparently to the user and to higher network layers. IMHP contains many features drawn from the proposals from Carnegie Mellon University [5] and from Macquarie University and IBM [6]. It uses the general architecture proposed by IBM [7], and includes aspects drawn from the proposals of Sony [13, 11, 12] and Columbia University [3, 4]. Johnson, Myles, Perkins Expires 14 August 1994 [Page 2] Internet Draft Internet Mobile Host Protocol 14 February 1994 2. Terminology The discussion in the rest of this document uses the following terms: System A device that implements the Internet Protocol, IP [9]. Router A system that forwards IP datagrams, as specified in [1]. This does not include systems that, though capable of IP forwarding, have that capability turned off, nor does it include systems that do IP forwarding only insofar as required to obey IP Source Route options. Host Any system that is not a router. Mobile Host A host that may connect to the Internet in networks other than its own home network, while still using its home address. Stationary Host A host that is not a mobile host. Correspondent Host A host communicating with another host. This term is used in discussions involving the sending of packets to a mobile host, in situations in which it is not relevant whether the sending host is a mobile host or a stationary host. Home Address The permanently assigned IP address of a mobile host, used used to identify the mobile host no matter where it may currently be located. Home Network The network on which a mobile host's home address resides. The home network may correspond to a physical network or a virtual network. Johnson, Myles, Perkins Expires 14 August 1994 [Page 3] Internet Draft Internet Mobile Host Protocol 14 February 1994 Foreign Agent A system that allows mobile hosts to connect to its local network, keeps a list of these mobile hosts in a "visitors list", and forwards received packets addressed to one of these mobile hosts to the mobile host through a local interface. Care-of Address An address offered by the foreign agent with which a mobile host is registered, which is used to define the location of a mobile host at a particular instant of time, and to which packets addressed to the mobile host may be tunneled. In many cases, the care-of address offered by a foreign agent will be one of IP addresses of the foreign agent, but other configurations are also possible. A foreign agent must use the same care-of address for all registered mobile hosts. Binding The combination of a care-of address and a home address for a mobile host is known as a binding. A binding may also have timeouts, flags, or other information associated with it. Cache Agent A system that caches the binding of one or more mobile hosts in a "location cache" and tunnels any packets it receives or originates addressed to these mobile hosts to the foreign agent indicated by the cached binding. Home Agent A system that maintains a list of mobile hosts it serves in a "home list", and when when one of these mobile hosts is registered with a foreign agent that is not also the mobile host's home agent or is not connected to its home network, intercepts packets on the home network addressed to the mobile host and forwards them using a location cache. A home agent must act as a cache agent and may act as a foreign agent for the mobile hosts it serves. Triangle Routing A situation in which a correspondent host's packets to a mobile host follow a longer than optimal path by being forwarded through the mobile host's home agent, rather than following the Johnson, Myles, Perkins Expires 14 August 1994 [Page 4] Internet Draft Internet Mobile Host Protocol 14 February 1994 shortest path directly to the foreign agent serving the mobile host. Johnson, Myles, Perkins Expires 14 August 1994 [Page 5] Internet Draft Internet Mobile Host Protocol 14 February 1994 3. Infrastructure This section defines the four types of systems used by IMHP: the mobile host, the foreign agent, the cache agent, and the home agent. Although the systems are defined here separately, any or all of them may be combined into a single system. 3.1. Mobile Host A mobile host is a system that may move through the IP internetwork. Each mobile host is assigned a constant IP address on a home network, and this address is known as the mobile host's home address. Correspondent hosts always address packets for a mobile host to the mobile host's home address. 3.2. Foreign Agent When a mobile host connects to a local network, it must identify and register with a foreign agent that can forward arriving packets locally to it. The mechanisms used to discover that the mobile host has connected to a new local network depend in part on the sub-network layer technology in use; a range of possibilities for this discovery are discussed in Section 7. When a packet arrives at a foreign agent addressed to a visiting mobile host registered with that foreign agent, the foreign agent must be able to deliver this packet to the mobile host without using normal IP routing. The simplest configuration for supporting this requirement is that the foreign agent must be located on the same physical network as the visiting mobile host, in which case it need only transmit the packet on this network to the mobile host's MAC address. Other configurations for the foreign agent are also possible but are beyond the scope of this document. Each foreign agent maintains a "visitor list" identifying those mobile hosts that are currently registered with this foreign agent. Subject to some security constraints discussed in Section 4.2.4, if a foreign agent receives a packet destined to a mobile host for which it has an entry in its visitor list, the foreign agent should deliver the packet locally to the mobile host. Each visitor list entry may be marked to be deleted after a period of time negotiated during the registration of the mobile host with this foreign agent. A mobile host must re-register before this period has expired to ensure uninterrupted service from the foreign agent. Johnson, Myles, Perkins Expires 14 August 1994 [Page 6] Internet Draft Internet Mobile Host Protocol 14 February 1994 The foreign agent, during the registration process, provides the mobile host with a care-of address, which defines the mobile host's current location. In this document, the care-of address offered by a foreign agent is assumed to be one of the IP addresses of the foreign agent, although other configurations are also possible. Any system including foreign agent functionality must offer the same care-of address on all its network interfaces. The combination of the mobile host's home address and the care-of address provided by the foreign agent is known as a binding. A mobile host's binding is tagged with a "Registration Sequence Number". This sequence number originates from the mobile host and is incremented each time the mobile host attempts to register or re-register with a foreign agent. The registration sequence number is used to compare the age of bindings for a mobile host to determine which is the most recent. When a mobile host registers with a new foreign agent, any previous foreign agents that may still have a valid visitor list entry for the mobile host must be notified. Such a previous foreign agent, subject to some security constraints, then deletes its visitor list entry for the mobile host. This notification to a previous foreign agent must be reliable in order to ensure that the previous foreign agent does not attempt to deliver packets to a mobile host that is no longer at that location. Such packets should instead be forwarded to the mobile host's new location. The mobile host may request its new foreign agent to send this notification to the previous foreign agent at registration time, or the mobile host may elect to send the notification itself. 3.3. Cache Agent The IMHP management protocol may distribute a mobile host's binding to others systems as needed. This binding may be stored in a "location cache" by systems that function as "cache agents". If a cache agent receives a packet addressed to a mobile host for which it has an entry in its location cache, the cache agent may tunnel the packet to the mobile host's currently known foreign agent, as defined by the care-of address in the binding. The tunneling protocol is discussed in Section 5. Any location cache will of necessity have a finite size; with the one exception described in Section 3.4, all entries in a location cache may be managed by the cache agent using any local cache replacement policy, such as LRU. The consistency of any location cache entries for a mobile host, with respect to the true location of that mobile host, is maintained as needed by the IMHP management protocol. Johnson, Myles, Perkins Expires 14 August 1994 [Page 7] Internet Draft Internet Mobile Host Protocol 14 February 1994 Each location cache entry is marked to be deleted after a period of time specified by the system providing the binding. A cache agent may attempt to reconfirm an entry in its location cache before the entry expires, thus extending the cache entry's timeout period. Such active reconfirmation is appropriate when it is likely that the entry will be used again in the near future and the cache agent wants to ensure uninterrupted service to the mobile host. If a foreign agent is notified that a mobile host it serves has moved, it may use the binding included with the notification, subject to some security constraints, to establish a location cache entry for the mobile host, if this foreign agent is also capable of functioning as a cache agent. The location cache entry is marked to be deleted after a period of time specified by the notification. 3.4. Home Agent Each mobile host must have a home agent, which is attached to the mobile host's home network. The home agent maintains a "home list" identifying all mobile hosts it is configured to serve. If the home network is a physical network (Section 3.5), the home agent must also function as a foreign agent for the mobile hosts in its home list, allowing those mobile hosts to register directly with it when they connect to their home network, as described in Section 8.8. A home agent must also function as a cache agent for at least those mobile hosts in its home list. For each of the mobile hosts in a home agent's home list that are not registered directly with it (in its role as a foreign agent), the home agent stores the current binding for that mobile host in its location cache. The location cache must be at least as large as the home list, and the location cache entries holding bindings for mobile hosts in its home list must not be replaced from the cache by other entries; As described in Section 3.3, all other entries in the cache may be managed by the cache agent using any local cache replacement policy. When a mobile host is not registered with the foreign agent that is also its home agent, its home agent must arrange to intercept any packets on the home network that are normally addressed to the mobile host. This can be done, for example, using proxy ARP [10] to cause all systems on the home network to change their ARP caches so that packets addressed to the mobile host's IP address will be sent to the home agent's MAC address. When the home agent intercepts a packet addressed to the mobile host, the home agent uses the binding in its location cache to forward the packet to the mobile host. The packet is tunneled to the foreign agent identified in the binding, as Johnson, Myles, Perkins Expires 14 August 1994 [Page 8] Internet Draft Internet Mobile Host Protocol 14 February 1994 described in Section 5, which then delivers the packet locally to the mobile host. A mobile host's home agent must always have a current binding for each of its mobile hosts, in order to provide service to them. Whenever a mobile registers with a foreign agent, it must also register with its home agent. The location cache entry created by the home agent during this registration (in its role as a cache agent) may be marked to be deleted after a period of time negotiated during the registration. A mobile host must re-register before this period expires to ensure uninterrupted service from the home agent. A home agent in its role as a foreign agent creates a visitor list entry for a mobile host when it registers with the home agent directly. The visitor list entry is marked to be deleted after a period of time negotiated during registration. The mobile host must re-register before this period expires to ensure uninterrupted service from the home agent. The expiration period of this visitor list entry may instead be set to infinite, in which case the mobile host does not have to re-register. This setting allows efficient operation when a mobile host is connected to its home network and registered directly with the foreign agent that is its home agent. When a home agent does not have a binding for one of its mobile hosts, the home agent should assume that the mobile host is connected to its home network. In this way, the mobile host may still operate as a stationary host in its home network if its mobile host software is not operational. 3.5. Home Network The home network may correspond to a physical network or to a virtual network. In either case, a router connected to the home network is responsible for advertising reachability to the home network. The router may optionally be incorporated into the system containing the home agent, but this is not necessary. To illustrate the range of configurations possible for the home network, Figure 1 shows the following three common home network configurations: (a) The home network is a physical network connected to the Internet by a router. The home agent is a separate system attached to the physical home network. (b) The home network is a physical network connected to the Internet by a system that contains both home agent and router functionality. Johnson, Myles, Perkins Expires 14 August 1994 [Page 9] Internet Draft Internet Mobile Host Protocol 14 February 1994 (c) The home network is a virtual network connected to the Internet by a system that contains both home agent and router functionality. This home agent is not also a foreign agent. Mobile hosts with a home address on this home network cannot connect directly to their home network. | /------------\ | Physical / \ +--------+ | home network | Internetwork +------+ Router +----+ \ / +--------+ | +--------+ \------------/ +---+ + | +--------+ | Home agent (a) Home agent as a separate system on the home network | /------------\ | Physical / \ +--------+ | home network | Internetwork +------+ Router +----+ \ / +--------+ | \------------/ Home agent | | | (b) Home agent in the router to the home network . /------------\ . Virtual / \ +--------+ . home network | Internetwork +------+ Router +----+ \ / +--------+ . \------------/ Home agent . . (c) A virtual home network Figure 1: Examples of home network configurations Johnson, Myles, Perkins Expires 14 August 1994 [Page 10] Internet Draft Internet Mobile Host Protocol 14 February 1994 4. IMHP Security IMHP is designed primarily to support a "weak security" model, which is equivalent to the level of security provided by the Internet today. IMHP could also be extended to support a "strong security" model, or its security features may be ignored in order to implement an "insecure" protocol. This section defines the insecure model, the strong security model, and the weak security model, and outlines the advantages and disadvantages of each. This section also specifies the implementation of the weak security model under IMHP. 4.1. Security Model Definitions 4.1.1. The Insecure Model The insecure model is based on the premise that a system may immediately believe a binding or other information it receives from another system. No security features are required in the protocol to support the insecure model. The insecure model provides for fast convergence to optimal routes and is easy to implement. However, this model allows a malicious or mischievous system to intercept a packet stream to a mobile host by simply sending a forged management packet containing a false binding. Although the insecure model might be appropriate in a private, closed network, it is unacceptable in the Internet where nothing may be assumed about the integrity of other users. 4.1.2. Strong Security Model The strong security model is based on the premise that no other system may be trusted unless it is fully authenticated. In particular, a system may not trust a binding or other information it receives without first fully authenticating it. Authentication, under the strong security model, almost certainly requires the use of public and private keys and trusted servers. The main disadvantage of the strong security model is its complexity and speed of operation. In particular, convergence to close to optimal routes may be a slow process. Johnson, Myles, Perkins Expires 14 August 1994 [Page 11] Internet Draft Internet Mobile Host Protocol 14 February 1994 4.1.3. Weak Security Model The weak security model is based on the premise that IMHP should provide security that is at least as good as that provided by the Internet today, which is certainly less than that provided by the strong security model. The weak security model assumes that all systems on the normal path of a packet through the Internet are trustworthy. This is the general assumption under which IP packets are routed through the Internet today. For example, in today's Internet, many packets contain plain-text passwords, which we trust intermediate systems not to intercept. By taking advantage of this assumption, a simple request-response mechanism may be used to authenticate a mobile host's binding. This mechanism is explained in the following sections. 4.2. Weak Security Implementation in IMHP In the context of IMHP, the weak security model requires a system to perform a relatively simple authentication procedure when it receives new information about the location of a mobile host. Figure 2 illustrates these procedures, which are explained in the following sections. 4.2.1. Home Agent to Mobile Host Authentication A home agent must be able to authenticate any information it receives from a mobile host in its home list. Similarly, a mobile host must be able to authenticate any information it receives from its home agent. Authentication between a mobile host and its home agent is achieved through a 64-bit password, based on secret shared between the mobile host and its home agent. This shared secret is established through some external management procedure, such as during initial configuration of the mobile host. The exact procedure used in establishing this shared secret between a mobile host and its home agent is beyond the scope of this document. This 64-bit password is included in management packets that are sent between the mobile host and its home agent. This method of authentication is no worse than a password being passed in clear-text across today's Internet, and so it may be considered to satisfy the weak security model. Johnson, Myles, Perkins Expires 14 August 1994 [Page 12] Internet Draft Internet Mobile Host Protocol 14 February 1994 +--------------+ Binding & password +--------------+ | |-------------------------->| | | Home agent | | Mobile host | | |<--------------------------| | +--------------+ Reply & password +--------------+ (a) Home agent to mobile host authentication Request for binding & +--------------+ authenticator +--------------+ | Home agent |-------------------------->| | | or | | System | | Mobile host |<--------------------------| | +--------------+ Reply & +--------------+ same authenticator (b) Obtaining an authenticated binding New binding & +--------------+ previously established +--------------+ | | authenticator | Previous | | Mobile host |-------------------------->| foreign | | | | agent | +--------------+ +--------------+ (c) Optimizing previous foreign agent notifications Figure 2: Security procedures in the weak security model in IMHP This authentication procedure is illustrated in Figure 2 (a). 4.2.2. Obtaining Authenticated Bindings In general, systems using IMHP will not have a shared secret, such as a password, that can be used to authenticate information received concerning a mobile host. However, a system may obtain an authenticated binding for a mobile host in IMHP under the weak security model by sending the mobile host's home agent (or the mobile host itself) a request that includes a randomly chosen authenticator value. If the reply contains the same authenticator value, then the reply and its contents may be Johnson, Myles, Perkins Expires 14 August 1994 [Page 13] Internet Draft Internet Mobile Host Protocol 14 February 1994 considered to be authenticated under the weak security model, since the path between this system and the destination of the request is assumed to be trusted. The randomly chosen authenticator value prevents any malicious system not on this path from forging a reply to the request. In this scheme, either the mobile host could reply, or its home agent could reply on behalf of the mobile host. In general, it is preferable that the home agent replies, as the mobile host might be temporarily inaccessible from a particular location due to out-of-date bindings in intermediate cache agents. However, a system generally does not know the home agent address of each mobile host. IMHP specifies a Routing (R) bit in management packets that, when set, forces management packets to be routed to the mobile host's home network, bypassing the use of all location caches. If the mobile host is registered directly on its home network, these packets will then be received and processed by the mobile host; otherwise, they will be intercepted by the mobile host's home agent, which will process the packets on behalf of the mobile host. This authentication procedure is illustrated in Figure 2 (b). 4.2.3. Optimizing Previous Foreign Agent Notifications When a mobile host moves, it is important that any previous foreign agents that may still have a visitor list entry for the mobile host are forced to delete that entry to avoid packet loss. If the foreign agent is also a cache agent, it is also desirable that a location cache entry is created by the previous foreign agent that indicates the mobile host's new location. This location cache entry allows packets to be forwarded by the cache agent to the mobile host's new location rather than through the mobile host's home agent. IMHP defines a technique that allows these updates to occur without having to request an authenticated binding for the mobile host from its home agent. When a mobile host registers with a new foreign agent, the mobile host choses a random authenticator value and includes this value in its registration request with the foreign agent. The foreign agent may then use this value to authenticate a future notification and a new binding that it receives from the mobile host indicating that the mobile host has moved. In effect, the authenticator acts as a temporary password between the mobile host and this foreign agent. The technique of allowing a foreign agent that is also a cache agent to create a location cache entry based on the authenticator has a Johnson, Myles, Perkins Expires 14 August 1994 [Page 14] Internet Draft Internet Mobile Host Protocol 14 February 1994 weakness when malicious hosts intercept the authenticator on the local network. However, the period of time for which the weakness exists is limited by specifying that the location cache entry should be marked to expire before the registration would have expired in any case. This authentication procedure is illustrated in Figure 2 (c). 4.2.4. Security and Forwarding Since a cache agent only creates a location cache entry when a mobile host's binding is fully authenticated, a location cache entry may always be safely used to forward any packet. However, a foreign agent creates a visitor list entry for a mobile host on a particular interface as soon as it is requested by a locally connected mobile host. Until the identity of the mobile host is authenticated, however, a visitor list entry should not generally be used to deliver packets to the mobile host. The one case in which an unauthenticated visitor list entry may be used to deliver packets to a mobile host is when the packet is tunneled to the foreign agent holding the visitor list entry. In this case, the cache agent that that tunneled the packet must have had an authenticated location cache entry for this mobile host, pointing to this foreign agent. The foreign agent can thus safely deliver the decapsulated packet to the mobile host. A foreign agent may attempt to authenticate a visitor list entry using the mechanisms for acquiring a mobile host's authenticated binding, as described in Section 4.2.2. If the binding it receives from the mobile host's home agent indicates that this foreign agent is serving the mobile host, the visitor list entry for the mobile host may be authenticated for the lifetime indicated in the binding. When the lifetime indicated in the reply expires the visitor list entry must be reauthenticated. The foreign agent is free to start this authentication procedure either immediately after the mobile host registers or at some later time (such as when the first packet arrives at the foreign agent for which the visitor list entry would have been used had it been authenticated). In many cases, a foreign agent will never use a visitor list entry to forward a non-tunneled packet, and so there is no need to ever authenticate it. This mechanism introduces a limitation to the weak security model implementation in that, if a cache agent has an old binding cached for a mobile host and an impostor mobile host registers where the Johnson, Myles, Perkins Expires 14 August 1994 [Page 15] Internet Draft Internet Mobile Host Protocol 14 February 1994 binding indicates the real mobile host is registered, then packets may be delivered to the impostor until the cache agent either times out or deletes the location cache entry. 4.2.5. Advertising Mobile Host Locations In some situations, it is desirable that the mobile host's current location not be distributed to other systems. For example, a mobile host may not want its correspondent hosts to know that it is currently away from its home network. In IMHP, a mobile host may specify that its binding should not be given to other systems, by setting a Private flag specified when the mobile host registers with its foreign agent and home agent. In this case, the foreign agent and the home agent must respond to any requests for the mobile host's binding by indicating the mobile host is connected to its home network. Similarly, the mobile host may indicate that it is connected to its home network when notifying previous foreign agents that it has moved. Even if a mobile host does not specify during registration that its binding may not be advertised, its home agent and the mobile host may restrict the binding distribution. First, they may choose to not give some systems the mobile host's binding when they request it. Second, they may set the Private flag on the bindings they do give out so that the system receiving the binding may not pass it on to others. The main cost of restricting the distribution of a mobile host's binding is an increased incidence of Triangular Routing. The advantage is that a new type of security and privacy is achieved. Johnson, Myles, Perkins Expires 14 August 1994 [Page 16] Internet Draft Internet Mobile Host Protocol 14 February 1994 5. Tunneling The operation of IMHP requires that cache agents be able to tunnel packets to a mobile host's current known location (i.e., the care-of address provided by the foreign agent that is serving the mobile host). In principle, any tunneling protocol could used. However, to achieve maximum interoperability and maximum efficiency, IMHP defines a new tunneling protocol, which is defined in [?]. A system that tunnels a packet to another system must always use the same source address for the tunnel, in order to ensure that routing loops can be detected. In the case of cache agent that is also a foreign agent, the address used must be the single care-of address that the foreign agent offers to all mobile host's on all of its interfaces. The tunneling protocol header defined in [?] does not carry any fragmentation information. Therefore, the use of this protocol requires a cache agent tunneling a packet to reassemble the packet (if fragmented) before tunneling the reassembled packet using a location cache entry. This reassembly requirement should generally cause no problems, but may prevent tunneling in networks where packets often take different routes to a given destination. If this is the case, a full encapsulation protocol will have to be used. The forwarding rules in Section 6 make use of what is known as a "special tunnel", in which a packet is tunneled with the destination of the tunnel equal to the destination of the packet. A special tunnel packet may only be forwarded using normal IP routing mechanisms, thus ensuring that it reaches to the destination network. A special tunnel may be used to force a packet to be routed to a mobile host's home agent, since the packet will be intercepted by the home agent once it reaches the mobile host's home network. Johnson, Myles, Perkins Expires 14 August 1994 [Page 17] Internet Draft Internet Mobile Host Protocol 14 February 1994 6. Forwarding Rules IMHP establishes a few rules for forwarding packets. These rules help ensure that optimal routes are used when possible. An optimal route is defined as the route a packet would normally take between two stationary hosts using the conventional IP routing protocols. In general, a system uses whatever location cache, visitor list, home list, and normal routing table information it has available to forward packets, with a small number of restrictions. If none of the rules below apply to a particular packet, then normal IP forwarding rules are followed. The following two basic rules apply to all IMHP systems, which allow for the delivery of packets addressed to these systems and for the decapsulation of tunneled packets: - If a system receives a tunneled packet, and the destination of the tunnel is one of the system's own addresses, then the system decapsulates the packet and continues processing the packet according to the remaining forwarding rules. - If a system receives a packet that is not tunneled, and the destination of the packet is one of the system's own addresses, then the system passes the packet to higher layer protocols for processing. A home agent will generally have a current authenticated binding for the mobile hosts in its home list. A home agent must also serve as a cache agent for these mobile hosts, and may be a foreign agent for the mobile hosts it serves as well. These properties help define the forwarding rules for a home agent when dealing with packets addressed to the mobile hosts in its home list. The following forwarding rules apply to packets received by a home agent: - If a home agent receives a special tunnel packet addressed to a mobile host in its home list, then the home agent decapsulates the packet and continues processing the packet according to the remaining forwarding rules. - If a home agent receives a packet addressed to a mobile host in its home list, and the home agent has a visitor list entry for the mobile host, then the home agent delivers the packet locally to the interface indicated by the visitor list entry. - If a home agent receives a packet addressed to a mobile host in its home list, and the home agent has a location cache entry for the mobile host, then the home agent tunnels the packet to the Johnson, Myles, Perkins Expires 14 August 1994 [Page 18] Internet Draft Internet Mobile Host Protocol 14 February 1994 care-of address indicated in the location cache entry, subject to the restriction in the following rule. - A home agent must never tunnel a packet to a foreign agent if the packet was just tunneled to the home agent from that same foreign agent. This rule avoids looping between a home agent and a foreign agent that no longer thinks it serves some mobile host. The home agent instead may drop the packet or buffer it in these circumstances. The home agent may also undertake other actions to locate the mobile host. - If a home agent receives a packet addressed to a mobile host in its home list, and this home agent does not have a location cache entry or a visitor list entry for the destination mobile host, the home agent either drops or buffers the packet. The home agent may also undertake other actions to locate the mobile host. Foreign agents and cache agents use forwarding rules that are similar to those used by a home agent. The differences from the rules used by a home agent are primarily due to the fact that a foreign agent or a cache agent might not have an authenticated binding for the mobile host, if that agent is not also the home agent serving that mobile host. The following forwarding rules apply to packets received by a foreign agent or a cache agent: - If a foreign agent receives a tunneled packet, and the foreign agent has an entry in its visitor list for the packet's destination after decapsulating the packet, then the foreign agent delivers the packet locally to the interface indicated by the visitor list entry. - If a foreign agent receives a packet, and the foreign agent has an authenticated visitor list entry for the packet's destination, then the foreign agent delivers the packet locally to the interface indicated by the visitor list entry. - If a cache agent receives a packet, and the cache agent has a location cache entry for the packet's destination, then the cache agent tunnels the packet to the care-of address indicated in the location cache entry. - If a cache agent or a foreign agent receives a tunneled packet, and the cache agent or foreign agent is unable to forward the packet using the above rules after decapsulating the packet, then the cache agent or foreign agent tunnels the packet to the mobile host's home network using a special tunnel. Johnson, Myles, Perkins Expires 14 August 1994 [Page 19] Internet Draft Internet Mobile Host Protocol 14 February 1994 7. Foreign Agent Discovery Before connecting to the Internet, either on its home network or on some other local network, a mobile host must identify and register with a suitable foreign agent (which may also be a home agent) on that same local network. This section describes the procedures a mobile host uses to identify a suitable foreign agent and to determine when that foreign agent is no longer available; the procedures used for registering with this foreign agent are described in Section 8. 7.1. Agent Advertisement Message A foreign agent may periodically advertise its services on a local network by multicasting an Agent Advertisement message (Section 13.1) from its network interface on this local network. One method that a mobile host may use to identify a suitable foreign agent with which to register is to simply listen for these Agent Advertisement messages. This agent discovery procedure is illustrated in Figure 3. A foreign agent must support a configuration option to specify the IP address to which Agent Advertisement messages are sent. This address may be either the reserved "all mobile hosts" multicast address, or the limited-broadcast address, 255.255.255.255. The current incarnation number of the foreign agent is included in each advertisement that it sends. The foreign agent increments its incarnation number each time it reboots and loses the state in its visitor list. The foreign agent may also increment its incarnation number at any other time in order to force all currently registered mobile hosts that it is serving to reregister. If a foreign agent sends Agent Advertisement messages over more than one network interface, it must maintain a separate incarnation number for each MH FA or HA : Agent Advertisement : : Message (multicast) : :<-----------------------: : : v v Figure 3: Agent discovery by listening for Agent Advertisement messages Johnson, Myles, Perkins Expires 14 August 1994 [Page 20] Internet Draft Internet Mobile Host Protocol 14 February 1994 interface and must ensure that no two interfaces use the same value as their current incarnation number. The time between transmissions of Agent Advertisement messages on an interface by a foreign agent is included in the Interval field of each Agent Advertisement message. Agent Advertisement messages may be sent more frequently than this interval, but at least one advertisement must be sent during each interval. A foreign agent must support a configuration option to specify the rate at which it sends periodic Agent Advertisement messages. A foreign agent, by setting the Home Agent (H) bit in its Agent Advertisement messages, may indicate that it is only willing to register mobile hosts that it also serves as a home agent. Other mobile hosts connected to the local network should not attempt registration with such a foreign agent, as the foreign agent will reject registration attempts from these hosts. A mobile host can determine that a foreign agent also serves as its home agent if the Agent Address field in the Agent Advertisement message is the same as the mobile host's configured home agent address. 7.2. Agent Solicitation Message A mobile host may also multicast an Agent Solicitation message (Section 13.2) to ask for immediate advertisements from any suitable foreign agents, rather than waiting for the next periodic Agent Advertisement message to arrive. In response to receiving an Agent Solicitation message, a foreign agent may multicast an Agent Advertisement message, or may unicast an Agent Advertisement message directly to the source of the solicitation. This agent discovery procedure is illustrated in Figure 4. A foreign agent need not respond to all Agent Solicitation messages and is free to use any criteria in deciding whether to respond to a particular Agent Solicitation message. For example, a foreign agent may silently ignore an Agent Solicitation message due to a lack of resources for serving new visiting mobile hosts, or for security reasons related to the particular mobile host that is the source of the solicitation. However, a foreign agent that is also a home agent must respond to Agent Solicitation messages from any mobile hosts in its home list. Each mobile host must support a configuration option to set the IP address to which it sends Agent Solicitation messages. This address may be either the reserved "all foreign agents" multicast address, or Johnson, Myles, Perkins Expires 14 August 1994 [Page 21] Internet Draft Internet Mobile Host Protocol 14 February 1994 MH FA or HA : Agent Solicitation : : Message (multicast) : :----------------------->: : : :<-----------------------: : Agent Advertisement : : Message (multicast : : or unicast) : v v Figure 4: Agent discovery by sending an Agent Solicitation message the limited-broadcast address, 255.255.255.255. Foreign agents must support receiving Agent Solicitation messages on both addresses. A mobile host must limit the frequency with which it sends Agent Solicitation messages. The maximum frequency is a configuration parameter. If a mobile host receives no response to its Agent Solicitation messages after a limited number of attempts, it should back off in the rate of their transmission. The back-off algorithm is also a matter of configuration. 7.3. Lower Network Layer Support A mobile host may use any facilities provided by the specific sub-network layer technology in use, to assist it in identifying a suitable foreign agent. For example, a "cell-association" event from Layer 2 in a wireless network may trigger the registration procedure within the mobile host. 7.4. Mobile Host Movement Discovery As a mobile host moves from one network to another, it is important that it be able to discover its movement in a timely manner so that it can begin registration procedures with a new foreign agent after each movement. Only once registration with a foreign agent is complete, can data communications resume. A mobile host may determine that it has moved, and therefore that it must register with a new foreign agent, in one of three ways. Johnson, Myles, Perkins Expires 14 August 1994 [Page 22] Internet Draft Internet Mobile Host Protocol 14 February 1994 First, a mobile host may determine that its current foreign agent is no longer available, by detecting that a number of consecutive expected Agent Advertisement messages from this foreign agent have not been received. A mobile host should support a configuration option to set the number of consecutive missed Agent Advertisement messages from its current foreign agent that will cause the mobile host to consider this foreign agent as no longer available. The second way in which a mobile host may determine that it has moved is by through indications provided by lower network layers. Normally, such indications will only be one input into the mobile host's decision to register with a new foreign agent, but if sufficient lower layer support is available, the mobile host may choose to rely exclusively on such support. In this case, the lower layers in the mobile host should be able to reliably indicate that the mobile host has moved. Reliable in this context means that a lower layer should never fail to indicate a movement that has occurred, but may occasionally indicate movement has occurred when it has not. After receiving an indication of movement from lower network layers, the mobile host may attempt to confirm that its current foreign agent is no longer available, either by attempting to re-register with the foreign agent or by sending the foreign agent a number of unicast Agent Solicitation messages, before attempting to identify and register with a new foreign agent. If the mobile host is not currently registered with any foreign agent, a lower layer indication should cause the mobile host to reset any back-off it had been using in its transmission of Agent Solicitation messages. Finally, a mobile host may determine that it has moved and that its current foreign agent is no longer available by waiting until the mobile host's next scheduled re-registration with this foreign agent. However, this method may result in a long delay before the movement is detected and thus may create an extended break in communications. Therefore, this last method should be used only in conjunction with one or both of the other methods for movement detection. Johnson, Myles, Perkins Expires 14 August 1994 [Page 23] Internet Draft Internet Mobile Host Protocol 14 February 1994 8. Registration Procedures Once a mobile host has identified a potential foreign agent with which to register, the mobile host may initiate registration with that foreign agent by sending a Registration Request message to it. The mobile host must also register with its home agent when registering with a new foreign agent, to ensure that its home agent always knows the mobile host's current binding. This section describes the procedures required for a mobile host to register with a foreign agent and with the mobile host's home agent. 8.1. Overview of Initial Registration Procedures When a mobile host registers with a foreign agent and with its home agent, the mobile host sends a Registration Request message (Section 13.3) to the foreign agent, with both the Foreign Agent (F) Home Agent (H) bits set and the corresponding fields filled in. If the foreign agent accepts the request, it passes the request on to the mobile host's home agent using a Registration Request message with only the Home Agent (H) bit set and the corresponding fields filled in. The home agent responds to the foreign agent with a Registration Reply message (Section 13.4) with the Home Agent (H) bit set and the corresponding fields filled in. When the foreign agent receives the Registration Reply message from the home agent, the foreign agent replies to the mobile host with a Registration Reply message with both the Foreign Agent (F) and Home Agent (H) bits set and the corresponding fields filled in. The foreign agent may also send an early Registration Reply message to the mobile host, before it receives the Registration Reply from the home agent, indicating that the foreign agent has accepted the registration and that the home agent registration is pending. Such an early reply from the foreign agent has only the Foreign Agent (F) bit set and the corresponding fields filled in. The foreign agent also later sends the normal Registration Reply message to the mobile host, with both the Foreign Agent (F) and Home Agent (H) bits set and the corresponding fields filled in, when it receives the reply from the home agent. Sending this early reply message to the mobile host may allow the mobile host to resume normal communication operations earlier, although the extra reply packet consumes additional network bandwidth on the local link and requires extra processing overhead in the mobile host. Figure 5 illustrates the normal sequence of packets exchanged when a mobile host registers with both a foreign agent and its home agent. Johnson, Myles, Perkins Expires 14 August 1994 [Page 24] Internet Draft Internet Mobile Host Protocol 14 February 1994 MH FA HA : : : : Registration Request : : : message (L & H bit set) : Registration Request : :-------------------------->: message (H bit set) : : :------------------------->: : : : : : Registration Reply : : Registration Reply : message (H bit set; : : message (L & H bit set; : accept or rejected) : : accepted or rejected) :<-------------------------: :<--------------------------: : : : : : : : v v v Figure 5: Mobile host registering with both foreign agent and its home agent 8.2. Overview of Re-registration Procedures The Registration Reply message from the home agent includes a Home Agent Service Lifetime field, and the Registration Reply message from a foreign agent includes a Foreign Agent Service Lifetime field. These lifetimes are the periods of time that the home agent and foreign agent, respectively, guarantee to maintain the mobile host's registration. The guarantee excludes unexpected outages such as failures of the foreign agent or home agent. A lifetime may be specified as being infinite. If a mobile host wishes to maintain its registration past the lifetimes specified in these replies, it must re-register before the registration expires. The re-registration procedure for a home agent is exactly the same as the initial registration procedures described in Section 8.1. Typically, the Foreign Agent Service Lifetime will be shorter than the Home Agent Service Lifetime. As a result, the mobile host will need to re-register with its foreign agent more often than it will need to re-register with its home agent. A mobile host may re-register with its foreign agent only, without needing to interact with its home agent, by sending a Registration Request message with only the Foreign Agent (F) bit set and the Johnson, Myles, Perkins Expires 14 August 1994 [Page 25] Internet Draft Internet Mobile Host Protocol 14 February 1994 corresponding fields filled in. The foreign agent replies with a Registration Reply message with the Foreign Agent (F) bit set and the corresponding fields filled in. 8.3. Retransmissions It is possible that a Registration Request messages or Registration Reply messages may be lost, particularly on a wireless link between a mobile host and its foreign agent. Thus, a mobile host may continue to periodically retransmit a Registration Request message until it has received a corresponding Registration Reply message. The foreign agent or home agent may receive a duplicate Registration Request message due to these retransmissions (or possibly due to other behavior within the network). A duplicate Registration Request message can be detected by comparing the Registration Sequence Number with the sequence number stored in the visitor list or location cache for the sending mobile host. When a duplicate Registration Request message is received, a Registration Reply message should be returned using the information about the registration maintained in the visitor list or location cache. In particular, if a foreign agent receives a duplicate of the Registration Request from a mobile host, while the foreign agent is still waiting for the Registration Reply from the home agent, the foreign agent should return an early Registration Reply message to the mobile host, as described in Section 8.1, indicating that the registration has been accepted by the foreign agent and that the registration with the home agent is pending. When a mobile host is attempting an initial registration with either a foreign agent or with the mobile host's home agent, the time between retransmissions should incorporate a back-off strategy to avoid flooding the network with Registration Request messages. If a mobile host fails to receive a reply from a foreign agent after a configured period of time, the mobile host may attempt to identify and register with another foreign agent. If no other foreign agents are available, the mobile host should continue to back-off in its Registration Request message retransmissions to the foreign agent. If a mobile host fails to receive a reply from its home agent after a configured period, the mobile host may attempt to identify and register with another foreign agent. An alternative foreign agent might have a better path through the network to the mobile host's home agent. If no other foreign agents are available, the mobile host should continue to back-off in its Registration Request message retransmissions. Johnson, Myles, Perkins Expires 14 August 1994 [Page 26] Internet Draft Internet Mobile Host Protocol 14 February 1994 When a mobile host is attempting to re-register with a foreign agent or with its home agent, the time between retransmissions may decrease down to a configured minimum period. However, once a registration's Service Lifetime has expired the mobile host shall restart the registration procedures. 8.4. Registration Request Message Fields All Registration Request messages, regardless of whether they are from a mobile host to a foreign agent or from a foreign agent to a home agent, contain at least the following fields: - The Foreign Agent (F) bit indicates whether the Registration Request message is requesting registration with a foreign agent. If this bit is set, the message contains the fields applicable to registering a mobile host with a foreign agent. - The Home Agent (H) bit indicates whether the Registration Request message is requesting registration with the mobile host's home agent. If this bit is set, the message contains the fields applicable to registering the mobile host with its home agent. - The Notify (N) bit indicates whether the Registration Request message is requesting this foreign agent to notify the mobile host's previous foreign agent of its new binding, as described by the Previous Foreign Agent Address, Previous Foreign Agent Authenticator, and Previous Foreign Agent Service Lifetime fields of the Registration Request message. The N bit may be set only when the Foreign Agent (F) bit is also set. If this bit is set, the message contains the fields applicable to notifying the mobile host's previous foreign agent. - If the Private (P) bit is set, the binding for this mobile host must be kept private and may not be advertised to systems other than this mobile host's home agent and current foreign agent. If the Private (P) bit is clear, this binding may be advertised as needed to other systems. - The Home Address field always contains the home address of the mobile host that is requesting registration. - The Registration Sequence Number field contains the mobile host's current Registration Sequence Number. The Registration Sequence Number is incremented by the mobile host each time it attempts to register or re-register with a foreign agent. Johnson, Myles, Perkins Expires 14 August 1994 [Page 27] Internet Draft Internet Mobile Host Protocol 14 February 1994 - When a mobile host sends a Registration Request message to a foreign agent, the Agent Address field contains that foreign agent's address on the local network. This field is used by the foreign agent to determine through which of its network interfaces the mobile host is accessible. When a foreign agent sends a Registration Request message to a home agent, the Agent Address field contains the care-of address that the foreign agent is offering to the mobile host. 8.5. Registration Reply Message Fields All Registration Reply messages, regardless of whether they are from a foreign agent to a mobile host or from a home agent to a foreign agent, contain at least the following fields: - The Foreign Agent (F) bit indicates whether the Registration Reply message contains a response from a foreign agent. If this bit is set, the message contains the fields applicable to a response from attempting to register the mobile host with a foreign agent. - The Home Agent (H) bit indicates whether the Registration Reply message contains a response from the mobile host's home agent. If this bit is set, the message contains the fields applicable to a response from attempting to register the mobile host with its home agent. - The Notify (N) bit indicates whether the Registration Reply message contains an acknowledgement from the mobile host's requested notification to its previous foreign agent. If this bit is set, the message contains the fields applicable to this acknowledgement. - The Reply Status field contains a code indicating the result of the registration request. A value with the high bit clear indicates success. Other values indicate rejection, possibly including a reason. The specific Reply Status codes are specified in Section 13.4. - The Home Address field contains the same value as that in the corresponding Registration Request message. - The Registration Sequence Number field normally contains the same value as that in the corresponding Registration Request message. Johnson, Myles, Perkins Expires 14 August 1994 [Page 28] Internet Draft Internet Mobile Host Protocol 14 February 1994 The only exception is when a home agent rejects a registration because the Registration Sequence Number is too low. In this case, the Registration Sequence Number field contains the value of an acceptable Registration Sequence Number. - The Agent Address field contains the care-of address that a foreign agent is offering the mobile host. - The Previous Foreign Agent Authenticator field contains the authenticator value received by the foreign agent in the Binding Acknowledge message from the mobile host's previous foreign agent. The mobile host must perform the necessary validation of this authenticator value. 8.6. Foreign Agent Registration This section describes the interaction required between a mobile host and a foreign agent for registering the mobile host with this foreign agent. The procedures defined here assumes that the foreign agent is not also the mobile host's home agent; this case is discussed in Section 8.8. 8.6.1. Sending the Registration Request Message When a mobile host wants to register with a foreign agent, the mobile host sends a Registration Request message to the foreign agent. This Registration Request message must have the Foreign Agent (F) bit set and must contain the following fields in addition to those described in Section 8.4: - The Foreign Agent Service Lifetime field indicates the maximum time that the mobile host would like this registration with the foreign agent to remain valid. The value chosen determines the maximum time communications with the mobile host might be disrupted if the mobile host reboots and loses all knowledge of the foreign agents with which it was previously registered. - The Foreign Agent Authenticator field specifies a 32-bit random number, chosen by the mobile host, which the foreign agent may later use to authenticate any future Binding Notify messages from this mobile host concerning this binding. This authenticator allows a mobile host to quickly notify its previous foreign agents that it has moved and to possibly provide them with its new binding. Johnson, Myles, Perkins Expires 14 August 1994 [Page 29] Internet Draft Internet Mobile Host Protocol 14 February 1994 This authenticator also allows the mobile host to authenticate a reply from its foreign agent. A reply is authenticated if the Authenticator field in the reply is the same as that sent in the Foreign Agent Authenticator field in the corresponding request. The Registration Request message is sent by the mobile host to the Source Address from the Agent Advertisement message received from the foreign agent, which may be different from the care-of address provided by that foreign agent in the Agent Advertisement message. 8.6.2. Foreign Agent Processing of Registration Request When a foreign agent receives a Registration Request message with the Foreign Agent (F) bit set, indicating that a mobile host is requesting registration, it must first decide whether or not to accept the request. The foreign agent may use any reasonable criteria. For example, a foreign agent might refuse to register a new mobile host unless the Registration Request message also includes a request to register with the mobile host's home agent as described in Section 8.7.4. The foreign agent might also need to authenticate the mobile host for charging purposes using a separate protocol. Applications such as this are beyond the scope of this document. If the foreign agent decides not to accept the registration request from the mobile host, the foreign agent must send a Registration Reply message to the mobile host; if the foreign agent instead accepts the registration request, it may optionally send an early Registration Reply message to the mobile host, as described in Section 8.1. This Registration Reply from the foreign agent has the Foreign Agent (F) bit set and contains the following fields in addition to those described in Section 8.5: - The Foreign Agent Service Lifetime field specifies the length of time for which the foreign agent will retain this registration for the mobile host. The Foreign Agent Service Lifetime field should normally be less than or equal to the Foreign Agent Service Lifetime field in the registration request. The exception is discussed in Section 8.8. If the foreign agent rejected the registration request, the Foreign Agent Service Lifetime field is set equal to zero. - The Foreign Agent Authenticator field is set to the same value as the foreign agent Authenticator field in the Registration Request message. The foreign agent sends the Registration Reply message to the mobile host using the network interface from which the corresponding request Johnson, Myles, Perkins Expires 14 August 1994 [Page 30] Internet Draft Internet Mobile Host Protocol 14 February 1994 was received. The MAC address used should be the same as the source MAC address from the corresponding request. All future packets sent to the mobile host during the current registration should also use this MAC address. 8.6.3. Foreign Agent Registration Operations When a foreign agent decides to accept a mobile host's request to register, the foreign agent creates or updates a visitor list entry for the mobile host. A visitor list entry for a mobile host indicates that the mobile host may be contacted directly on a local network interface. The particular interface was indicated by the Agent Address field from the Registration Request message. Initially, the visitor list entry for this mobile host is marked as unauthenticated, which means that the visitor list entry may be used only to forward packets that are tunneled to the foreign agent. Under the weak security model, it is assumed that only systems that have authenticated bindings for the mobile host will tunnel packets to the foreign agent. A visitor list entry may only be considered to be authenticated and thereafter used to forward non-tunneled packets if the foreign agent authenticates the identity of the mobile host with the mobile host's home agent. The procedures to authenticate a mobile host's identity are discussed in Section 4.2.2. A visitor list entry may be marked to be timed out after the period of time specified in the Foreign Agent Service Lifetime field sent in the Registration Reply message. Only by re-registering can a mobile host avoid the foreign agent timing out and deleting the visitor list entry for the mobile host. A visitor list entry is tagged with the Foreign Agent Authenticator sent to the foreign agent in the Registration Request message. If a notification that the mobile host has moved is subsequently received containing the same authenticator, the notification is authenticated and the appropriate actions taken, as described in Section 9. A visitor list entry is also tagged with the Private (P) bit from the Registration Request message. If the Private (P) bit is set, the foreign agent must must keep the mobile host's binding private and may not advertise this binding to other systems. In this case, the foreign agent must respond to any request for the mobile host's binding by indicating that the mobile host is connected to its home network. This procedure is described fully in Section 10.2. Johnson, Myles, Perkins Expires 14 August 1994 [Page 31] Internet Draft Internet Mobile Host Protocol 14 February 1994 The mobile host's Registration Sequence Number is also stored with its visitor list entry. The mobile host's Registration Sequence Number is used to sequence Binding Notify messages at a foreign agent. If the Notify (N) bit of the Registration Request message is set, the mobile host is requesting this new foreign agent to notify its previous foreign agent of the mobile host's new binding. The address of the previous foreign agent is specified in the Previous Foreign Agent Address field of the message, and the authenticator value to be used in notifying that agent is specified in the Previous Foreign Agent Authenticator field. The service lifetime for the mobile host's registration with that previous foreign agent is specified in the Previous Foreign Agent Service Lifetime field. After deciding to accept the registration request from the mobile host, this new foreign agent must attempt to notify the previous foreign agent of the mobile host's new binding using the Binding Notify message, as described in Section 9, 8.6.4. Mobile Host Processing of Registration Reply When a mobile host receives a Registration Reply message with the Foreign Agent (F) bit set, it must confirm that this reply corresponds to an outstanding Registration Request message that it has sent. This process includes checking that the Home Address field, the Registration Sequence Number field and the foreign agent Authenticator field are the same as that from a previous request. In addition, the Registration Sequence Number field must be the same as the mobile host's current Registration Sequence Number. If the Notify (N) bit is set in the Registration Reply message, the mobile host must check the Previous Foreign Agent Authenticator value returned in the message. If the authenticator matches the value for that previous foreign agent stored in the mobile host's previous foreign agent list, the mobile host should delete this entry from its list, as described in Section 9.2. If the Registration Reply message indicates that the request was accepted by the foreign agent, the mobile host clears its routing table except for a single default route entry pointing to the foreign agent, as specified by the Source Address field from the Registration Reply message. The foreign agent thus acts as the mobile host's default router. The mobile host may choose to commence sending data packets immediately using the foreign agent as its default router, or it may Johnson, Myles, Perkins Expires 14 August 1994 [Page 32] Internet Draft Internet Mobile Host Protocol 14 February 1994 choose to delay sending data packets until it has confirmed that it also has a valid registration with its home agent (Section 8.7.4). The Foreign Agent Service Lifetime field in the Registration Reply message is used to time out the registration with the foreign agent. Assuming that the mobile host wants to maintain a registration with this foreign agent, it may attempt to re-register with the foreign agent before the lifetime expires. If the mobile host choses not to re-register with this foreign agent or is unable to do so before the registration expires, it must remove the default route to this foreign agent and assume that it is de-registered after this lifetime has expired. The mobile host may then attempt to discover a new foreign agent, as described in Section 7. If the Registration Reply message indicates that the registration request was rejected, the mobile host continues to attempt to discover and register with foreign agents. The mobile host may also start recovery procedures, depending on the reject Reply Status code. The mobile host should back-off in its attempts to register with foreign agents that continually reject registration attempts. 8.7. Home Agent Registration This section describes the interaction between a mobile host, a foreign agent, and the mobile host's home agent for registering the mobile host with its home agent. The procedures defined here assume that the foreign agent is not also the mobile host's home agent; this case is discussed in Section 8.8. 8.7.1. Sending the Registration Request Message When a mobile host wants to register with a foreign agent and with its home agent, the mobile host sends a Registration Request message to the foreign agent. This Registration Request message must have the Foreign Agent (F) and Home Agent (H) bits set and must contain the following fields in addition to those described in Section 8.4 and Section 8.6.1: - The Home Agent Service Lifetime field. indicates the maximum time that the mobile host would like this registration with the home agent to remain valid. The time chosen determines the maximum time communications with the mobile host might be disrupted if the home agent reboots and forgets the location of the mobile host. This value also represents the maximum time the Johnson, Myles, Perkins Expires 14 August 1994 [Page 33] Internet Draft Internet Mobile Host Protocol 14 February 1994 home agent may tunnel packets to a foreign agent that has failed if the mobile host does not re-register. - The Home Agent Password is used by the home agent to authenticate the mobile host. The contents of the Home Agent Password are not specified in this document, but will usually be based on a secret that the mobile host shares with its home agent. - The Home Agent Address field is set to mobile host's configured home agent address. The Registration Request message is sent to the foreign agent in the same manner as that described in Section 8.6.1. 8.7.2. Foreign Agent Processing of Registration Request When a foreign agent receives a Registration Request message from a mobile host with the Foreign Agent (F) and Home Agent (H) bits set, it first decides whether to accept the foreign agent registration request as described in Section 8.6.2. Assuming that the request is accepted, the foreign agent then sends the Registration Request message to the mobile host's home agent at the address specified in the Home Agent Address field, after changing the following fields in the message: - The Foreign Agent (F) bit is cleared and the corresponding fields removed. - The Agent Address field is set equal to the care-of address that the foreign agent is offering the mobile host. 8.7.3. Home Agent Processing of Registration Request When a home agent receives a Registration Request message with the Home Agent (H) bit set and the Foreign Agent (F) bit cleared, indicating that a mobile host is requesting registration with this home agent, the home agent must first decide whether or not to accept the request. The home agent may use any reasonable criteria in this decision. However, the home agent must minimally check that: - it is configured to serve the mobile host as its home agent (i.e., the mobile host is listed in the home agent's home list), and Johnson, Myles, Perkins Expires 14 August 1994 [Page 34] Internet Draft Internet Mobile Host Protocol 14 February 1994 - the Registration Sequence Number field is greater (modulo 2^32) than any previous Registration Sequence Number received from this mobile host. Once the home agent decides whether or not to accept the registration request from the mobile host, the home agent sends a Registration Reply message to the foreign agent serving the mobile host in this registration. This Registration Reply message must have the Home Agent (H) bit set, and must contain the following fields in addition to those described in Section 8.5: - The Home Agent Service Lifetime field specifies the length of time for which the home agent will retain this a registration for the mobile host. The Home Agent Service Lifetime field should normally be less then or equal to the Home Agent Service Lifetime field in the registration request. If the home agent rejected the registration request, the Home Agent Service Lifetime field is set to zero. - The Home Agent Password is used by the mobile host to authenticate the home agent's reply. The contents of the Home Agent Password are not specified in this document, but will usually be based on a secret that the mobile host shares with its home agent. The home agent sends the Registration Reply message to the foreign agent specified in the Agent Address field of the Registration Request message. 8.7.4. Home Agent Registration Operations When a home agent decides to accept a mobile host's registration request, the home agent creates or updates a location cache entry for the mobile host, unless the home agent and the foreign agent with which the mobile host is registering are located in the same system. The location cache entry records the mobile host's Registration Sequence Number and the binding to the mobile host's current foreign agent. A home agent must function as a cache agent for at least the mobile hosts it serves as a home agent. This location cache entry is marked to be deleted after the Home Agent Service Lifetime period included in the Registration Reply message. The mobile host must re-register within this time in order to retain its registration with its home agent. If a home agent does not have a location cache entry for a mobile host, the home agent should assume that the mobile host is connected to its home network, unless the home network is a virtual network. Johnson, Myles, Perkins Expires 14 August 1994 [Page 35] Internet Draft Internet Mobile Host Protocol 14 February 1994 If the mobile host's home network is a virtual network, the home agent should assume that mobile host is unreachable. 8.7.5. Foreign Agent Processing of Registration Reply When a foreign agent receives a Registration Reply message with the Home Agent (H) bit set, the foreign agent uses its visitor list to pass the reply to the mobile host specified in the Home Address field of the reply message. If no visitor list entry exists for the mobile host, the reply message is instead discarded by the foreign agent. 8.7.6. Mobile Host Processing of Registration Reply When a mobile host receives a Registration Reply message with the Home Agent (H) bit set, the mobile host must first confirm that this reply corresponds to an outstanding Registration Request message sent by this mobile host. This process includes checking that the Home Address field and the Registration Sequence Number field are the same as that from a previous request. The mobile host must also ensure that the contents of the Home Agent Password are acceptable and that the Registration Sequence Number field is equal to the mobile host's current Registration Sequence Number. If the Reply Status field indicates the registration request was accepted, the mobile host is now registered with its home agent for the period specified in the Home Agent Service Lifetime field. If the Reply Status field indicates the registration request was rejected, the mobile host may attempt recovery procedures, depending on the value of the Reply Status code. In particular, if the registration was rejected because the Registration Sequence Number was too low, the mobile host should reset its Registration Sequence Number to be at least that in the reply. Generally, rejection by a mobile host's home agent is a serious problem that may indicate configuration difficulties. 8.8. Home Network Registration When a home agent is also the mobile host's foreign agent, the procedures described in Section 8.7.4 are slightly modified. First, the foreign agent does not interact with the mobile host's home agent using explicit Registration Request and Registration Reply messages, as the foreign agent and the home agent are part of the same system. A combined Registration Reply message is sent by this Johnson, Myles, Perkins Expires 14 August 1994 [Page 36] Internet Draft Internet Mobile Host Protocol 14 February 1994 home agent/foreign agent to the mobile host, with both the Home Agent (H) and Foreign Agent (F) bits set and with the corresponding fields for both filled in. Second, the home agent/foreign agent may set the Home Agent Service Lifetime and Foreign Agent Service Lifetime fields in this combined Registration Reply message to the reserved value of 0xffffffff (all ones), indicating that this registration has an infinite lifetime and will not be deleted by the home agent/foreign agent after any timeout period. The mobile host need not continue to re-register with either its home agent or its foreign agent in this case. The Reply Status field in this message should indicate the mobile host is connected to its home network. Finally, after completing the registration procedure, the mobile host should use a routing table appropriate to being connected to its home network, rather than having only a single default route through its foreign agent. 8.9. De-registration It is desirable that a mobile host de-registers from a foreign agent and from its home agent before it moves, in order to avoid any packets being lost during the period before the mobile host has registered with a new foreign agent. Unfortunately, the mobile host may be unable to explicitly de-register before it moves in some cases, since by the time the mobile host knowns it has moved, it is too late to perform any de-registration procedures, for example because it is then no longer in transmission range of its previous foreign agent. Nevertheless, this section describes two methods for explicit de-registration to occur. 8.9.1. Mobile Host Initiated De-registration A mobile host that is registered with a foreign agent or with its home agent may wish to de-register explicitly from those systems before it moves to a new location. A mobile host may explicitly de-register from foreign agent or a home agent by successfully registering with the foreign agent or home agent respectively with a proposed service time of zero. Johnson, Myles, Perkins Expires 14 August 1994 [Page 37] Internet Draft Internet Mobile Host Protocol 14 February 1994 If a mobile host requires confirmation of a home agent de-registration request, it must ensure that it does not de-register from its foreign agent until the confirmation is received from the home agent. Otherwise, the foreign agent will not have a visitor list entry that allows it to deliver the reply from the home agent to the mobile host. 8.9.2. Foreign Agent Initiated De-registration A foreign agent may de-register all the mobile hosts registered with it by changing the Incarnation Number that the foreign agent advertises in the Agent Advertisement messages that it sends. Upon receiving an Agent Advertisement message from its current foreign agent (for example, from the foreign agent's periodic multicast of this message), a mobile hosts registered with this foreign agent must consider itself to be immediately de-registered and may restart the registration procedure. This mechanism is particularly useful to handle the case when a foreign agent reboots and forgets which mobile hosts that were registered with it prior to its reboot. Johnson, Myles, Perkins Expires 14 August 1994 [Page 38] Internet Draft Internet Mobile Host Protocol 14 February 1994 9. Notifying Previous Foreign Agents When a mobile host registers with a new foreign agent, it is important to notify any previous foreign agents that might still have bindings for the mobile host in their visitor list. Otherwise, there is a danger packets will be mis-delivered or lost for up to the timeout of the registration with the previous foreign agent. Additionally, if the previous foreign agent is also a cache agent, this cache agent may create a location cache entry for the mobile host to ensure continued close to optimal routing of packets to the mobile host. This section describes the mechanisms used in notifying a mobile host's previous foreign agents. 9.1. Previous Foreign Agent List A mobile host must maintain in a "previous foreign agent list" the identity of any previous foreign agents with which it has registered or attempted to register, which may possibly still consider the mobile host to be registered with it. When a mobile host begins a registration attempt with a foreign agent, it must create an entry for this foreign agent in its previous foreign agent list. This entry must include the address of the foreign agent (the Agent Address to which it sent the Registration Request message), the Foreign Agent Authenticator value sent in that Registration Request message, and the Foreign Agent Service Lifetime value sent in the message. When a mobile host receives a Registration Reply from a foreign agent indicating that the foreign agent has accepted its registration, the mobile host must change the entry in its previous foreign agent list for this foreign agent. The foreign agent's address in the entry must be set to the Care-of Address offered by the foreign agent, and the Foreign Agent Service Lifetime must be set to the value returned in the message by the foreign agent. An entry in this list may be deleted when the mobile host explicitly de-registers from a foreign agent and receives a Registration Reply message from the foreign agent indicating that the foreign agent has accepted its de-registration. An entry in this list may also be deleted when the mobile host receives an acknowledgement that the foreign agent has received a Binding Notify message giving the mobile host's new binding. Finally, an entry can be removed from this list after the mobile host can be sure of the expiration of the Foreign Johnson, Myles, Perkins Expires 14 August 1994 [Page 39] Internet Draft Internet Mobile Host Protocol 14 February 1994 Agent Service Lifetime period in this list entry. If the mobile host completed registration with this foreign agent, the timeout period should begin after the mobile host receives the Registration Reply message from this foreign agent; if the mobile host attempted to register with this foreign agent but received no reply, the timeout period should begin after the mobile host stops retransmitting Registration Requests to this foreign agent. Generally, the previous foreign agent list will have only one entry, unless communication or system failures have prevented notifying some previous foreign agents or the mobile host has been moving very quickly. When a mobile host registers with a new foreign agent, it may request that foreign agent to attempt to notify one previous foreign agent of its new binding, as discussed in Section 8.6.3. 9.2. Notification Methods When a mobile host registers with a foreign agent, the mobile host may request the new foreign agent to notify a previous foreign agent of its new binding (Section 8.6.3). After deciding to accept the registration from the mobile host, the new foreign agent should send a Binding Notify message to the previous foreign agent specified in the Registration Request message, with the Acknowledge (A) bit set in the notification message. If the Private (P) bit was set in the Registration Request message from the mobile host, the new foreign agent should set the Agent Address field in this Binding Notify message to the mobile host's home address; otherwise, the Agent Address field should be set to the care-of address supplied by the new foreign agent. If the Binding Acknowledge message for this notification is received by the new foreign agent before it sends the Registration Reply message to the mobile host, completing the registration process, the foreign agent sets the Notify (N) bit in the Registration Reply message and includes the Authenticator value from the Binding Notification message in the Previous Foreign Agent Authenticator field of the Registration Reply message. The mobile host must perform the necessary validation of this authenticator value, and if the authenticator is correct, may then remove the entry for this previous foreign agent from its previous foreign agent list. If the Binding Acknowledge message is received by the new foreign agent after it sends the Registration Reply message to the mobile host, it simply forwards the Binding Acknowledge message to the mobile host; the mobile host may then remove this foreign agent from its previous foreign agent list. If the Binding Acknowledge message is received by the new foreign agent after the mobile host has explicitly de-registered with this foreign agent or this foreign Johnson, Myles, Perkins Expires 14 August 1994 [Page 40] Internet Draft Internet Mobile Host Protocol 14 February 1994 agent has received a Binding Notify indicating that the mobile host has registered with a new foreign agent, the foreign agent discards the Binding Acknowledge message. All other necessary notifications to any previous foreign agents are the responsibility of the mobile host itself. If, for example, a mobile host attempts to register with several foreign agents before successfully registering with a new foreign agent, the mobile host must add each of these attempted registrations to its previous foreign agent list. The Registration Request message only allows the mobile host to request its new foreign agent to notify one of these previous foreign agents, since a mobile host will usually only have one previous foreign agent. For each of the other entries in its previous foreign agent list, the mobile host must send a Binding Notify message to that foreign agent to perform the notification. The mobile host should set the Acknowledge (A) bit in each of these Binding Notify messages, and may remove that entry from its previous foreign agent list when the corresponding Binding Acknowledge message is received. 9.3. Binding Notify Message The Binding Notify message (Section 13.6) is used to notify previous foreign agents of a mobile host's new binding after it has moved. When used for this purpose, the message contains the following fields: - The Private (P) bit is either set or cleared depending on whether the mobile host wants to keep its binding private and to disallow advertising this binding to other systems. - The Acknowledge (A) bit is set indicating that an acknowledgement is required. - The Binding Present (B) bit is set indicating that a binding is included in the message. - The Home Address field contains the mobile host's home address. - The Authenticator field contains the authenticator that the mobile host sent to the previous foreign agent when registering with it. - The Registration Sequence Number field contains the mobile host's current Registration Sequence Number. Johnson, Myles, Perkins Expires 14 August 1994 [Page 41] Internet Draft Internet Mobile Host Protocol 14 February 1994 - If the mobile host wants to reveal its new binding to the previous foreign agent, the Agent Address field contains the care-of address provided by the mobile host's current foreign agent. Otherwise, the Agent Address field contains the mobile host's home address. - If the mobile host wants to reveal its new binding to the previous foreign agent, the Service Lifetime field contains the maximum time, in tenths of a second, that the previous foreign agent may keep this binding without reconfirming it. Otherwise, the Service Lifetime field is set to zero. 9.4. Previous Foreign Agent Operations When a foreign agent receives a Binding Notify message with the Binding Present (B) bit set, the foreign agent first ensures that it has a visitor list entry for the mobile host specified in the Home Address field, and that the Authenticator field is equal to the authenticator kept with this visitor list entry. If both of these condition are met, the Binding Notify message is authenticated and may be used to modify the foreign agent's visitor list. If the foreign agent also functions as a cache agent, the Binding Notify message may be used to modify the foreign agent's location cache. If the Registration Sequence Number field is greater than the Registration Sequence Number kept with the visitor list entry, the visitor list entry is deleted. Otherwise, the Binding Notify message is ignored. If the foreign agent also functions as a cache agent and the visitor list entry that was deleted was marked as authenticated, then a location cache entry may be created that indicates that the mobile host is now registered with the foreign agent specified in the Agent Address field. This entry should be marked to timeout after the minimum of the Service Lifetime specified in the Binding Notify message and the remaining time left before the original registration would have expired. However, if the Agent Address field in the Binding Notify message is equal to the mobile host's home address, then no location cache entry is created. The Registration Sequence Number field is stored with the location cache entry. The location cache entry is marked to be timed out after a period no longer than that specified in the Service Lifetime field and the time left until the visitor list would have timed out. The location cache entry is also tagged with the Private (P) bit from the Binding Notify message. Johnson, Myles, Perkins Expires 14 August 1994 [Page 42] Internet Draft Internet Mobile Host Protocol 14 February 1994 9.5. Binding Acknowledge Message If the Acknowledge (A) bit was set in the Binding Notify message, the foreign agent must send a Binding Acknowledge message to acknowledge receipt of the Binding Notify message. This acknowledgement is sent even if the foreign agent does not accept the Binding Notify message because it is not authenticated. The Binding Acknowledge message contains the following fields: - The Home Address field contains the same value as the Home Address field in the Binding Notify message. - The Registration Sequence Number field contains the same value as the Registration Sequence Number field in the Binding Notify message. - The Authenticator field contains the same value as Authenticator field in the Binding Notify message. The destination address of the Binding Acknowledge message should be set to the source address of the Binding Notify message being acknowledged. 9.6. Mobile Host Operations When a mobile host receives a Binding Acknowledge message, the mobile host deletes any entry in its previous foreign agent list with the same Home Address, Registration Sequence Number, and Authenticator as those received in the acknowledgement. 9.7. Retransmissions It is possible that Binding Notify messages or Binding Acknowledge messages used in the procedures described above might be lost, particularly on a wireless link between a mobile host and its foreign agent. A mobile host should continue to periodically retransmit a Binding Notify message corresponding to each entry in its previous foreign agent list that has not timed out or been deleted. To avoid flooding the network with Binding Notify messages, these retransmissions by the foreign agent and mobile host should be scheduled according to some back-off strategy. Johnson, Myles, Perkins Expires 14 August 1994 [Page 43] Internet Draft Internet Mobile Host Protocol 14 February 1994 10. Other Management Procedures The IMHP management philosophy is to distribute bindings only to systems as required. Generally, this means that only when a system determines that another system might be holding an incorrect binding for a mobile host should that system send it a notification advising it to acquire a current binding. However, a mobile host or its new foreign agent usually attempts to notify the mobile host's previous foreign agents that the mobile host has moved, and a mobile host always notifies its home agent that it has moved. In terms of the forwarding rules defined in Section 6, a cache agent should send a notification to the source of any packet received that the cache agent subsequently tunnels using a location cache entry. Similarly, a cache agent or a foreign agent should send a notification to the source of any tunnel that is addressed to the system if it is unable to forward the packet except by using a special tunnel. In both cases, the source of the packet or tunneled packet has either an incorrect or no binding cached for a mobile host. It is important that the network not be flooded with notifications. Thus, the frequency of notifications sent by one system to another system concerning the binding of a particular mobile host must be limited. Any systems that do not implement IMHP will ignore any notifications that they receive. Even those systems that do implement IMHP may be limited in the number of bindings they can cache or the speed with which they can process notifications. Therefore, a system must use a back-off algorithm to slowly reduce the frequency of notifications it sends another system concerning the binding of a particular mobile host when it appears that the other system is ignoring the notifications. In the unlikely event that two or more cache agents have location cache entries that form a routing loop for a particular mobile host, the mechanisms defined above ensure that the loop is quickly broken. An IMHP management packet should never give rise to other IMHP management packets. 10.1. Notifying Other Entities In addition to being used to notify previous foreign agents that a mobile host has moved, Binding Notify messages may also be used Johnson, Myles, Perkins Expires 14 August 1994 [Page 44] Internet Draft Internet Mobile Host Protocol 14 February 1994 to notify another system that it should attempt to obtain a new authenticated binding for a mobile host. In particular, if a system tunnels a packet to another system, and the second system is not serving the mobile host as its foreign agent, the second system should send a Binding Notify message to the first system. Alternatively, if a cache agent receives a regular IP packet and has to tunnel the packet to a destination mobile host, the cache agent should also send a Binding Notify Message to the source of the packet. A system must limit the frequency with which it sends Binding Notify messages to another system concerning a particular mobile host, in order to avoid flooding the network. It is thus desirable that a system backs off transmitting Binding Notify messages if it appears they are having no effect. The particular back-off algorithm used by any system is a configuration parameter of that system. An IMHP management packet should never give rise to other IMHP management packets. In particular, an IMHP management packet should not cause a Binding Notify message to be generated. In the two cases described above for sending a Binding Notify message, the message contains the following fields: - The Acknowledge (A) bit in the Binding Notify message is cleared, indicating that no acknowledgement is required. - The Binding Present (B) bit in the Binding Notify message is cleared, indicating that no binding is included in the message. - The Home Address field is set to the home address of the destination mobile host from the packet that caused the Binding Notify message to be sent. No binding is included, as the system receiving the Binding Notify message generally has no way of authenticating it. Instead this receiving system uses the notification as an indication to use the mechanisms described in Section 10.2 to obtain an authenticated binding for the mobile host. 10.2. Acquiring Authenticated Mobile Host Bindings When a foreign agent registers a mobile host and creates a new visitor list entry, the visitor list entry must be marked as unauthenticated, as described in Section 8.6.3. The foreign agent Johnson, Myles, Perkins Expires 14 August 1994 [Page 45] Internet Draft Internet Mobile Host Protocol 14 February 1994 can only mark the visitor list entry as authenticated when it authenticates the identity of the mobile host. The foreign agent may attempt to authenticate a visitor list entry immediately, or it may wait until it would have used the visitor list entry if it had been authenticated. In many configurations, there is no benefit in authenticating visitor list entries. When a foreign agent or a cache agent receives a Binding Notify message with the Binding Present (B) bit clear, the foreign agent or cache agent may use this message as an indication to attempt to acquire an authenticated binding for the mobile host. In both cases, authentication is achieved by sending the mobile host's home agent a Binding Inquire message containing a request for the mobile host's binding. The Binding Inquire message is replied to by a Binding Notify message, which provides an authenticated binding for the mobile host. The authentication must be timed out after a period specified in the Binding Notify message. In the case of a location cache entry, the entry must be deleted if the authentication times out. In the case of a visitor list entry, the entry must be marked as unauthenticated if the authentication times out. Authentication timeouts may be avoided by reauthenticating the entry before timeout occurs. A system must limit the frequency of Binding Inquire messages that it transmits, in order to avoid flooding the network. The maximum frequency is a configuration parameter. If it appears that the Binding Inquire messages are being ignored, the system should back-off in the rate of their transmission. 10.2.1. Sending a Binding Inquire Message The Binding Inquire message used to obtain an authenticated binding for a mobile host contains the following fields: - The Routing (R) bit is set to ensure that the Binding Inquire message is routed to the mobile host's home network, to be processed by either the mobile host itself or by its home agent. - The Home Address field contains the home address of the mobile host for which an authenticated binding is requested. - The Authenticator field is set equal to a random number chosen by the sending system. The reply must contain the same Authenticator value. Johnson, Myles, Perkins Expires 14 August 1994 [Page 46] Internet Draft Internet Mobile Host Protocol 14 February 1994 10.2.2. Processing a Binding Inquire Message When a home agent or mobile host receives a Binding Inquire Message, the home agent or mobile host replies to the system that sent the inquiry with a Binding Notify message. The reply contains either the mobile host's current binding or indicates that the mobile host is connected to its home network. The Binding Notify message contains the following fields: - The Private (P) bit is set if binding is to remain private and may not be advertised to other systems. - The Binding Present (B) bit is always set, as the mobile host or its home agent always knows the mobile host's current binding. - The Home Address field contains the same value as the Home Address field in the Binding Inquire message. - The Authenticator field contains the same value as the Authenticator field in the Binding Inquire message. - The Registration Sequence Number field contains the mobile host's current Registration Sequence Number. - The Agent Address field contains the mobile host's home address, if the mobile host is connected to its home network, or the mobile host's current care-of address provided by a foreign agent, otherwise. However, if the binding is to remain private and may not be advertised to other systems, the Agent Address field always contains the mobile host's home address. - The Service Lifetime field contains zero, if the mobile host is connected to its home network, or the period for which the binding contained in the reply is authenticated, otherwise. However, if the binding is to remain private and may not be advertised to other systems, the Service Lifetime field always contains zero. The Binding Notify message is sent to the system that sent the Binding Inquire message. 10.2.3. Processing the Binding Notify Message When a foreign agent or a cache agent receives a Binding Notify message with the Binding Present (B) bit set, the foreign agent or cache agent must first ensure that the message corresponds to an outstanding Binding Inquire message sent by this system, by checking Johnson, Myles, Perkins Expires 14 August 1994 [Page 47] Internet Draft Internet Mobile Host Protocol 14 February 1994 that the Home Address field and the Authenticator field match those is a previous request. The authenticated message may then be used to update a visitor list entry in a foreign agent or a location cache entry in a cache agent. The following actions occur at a foreign agent for processing an authenticated Binding Notify message: - If the Registration Sequence Number field is greater than that stored with the visitor list entry for the mobile host, the visitor list entry is deleted. - If the Registration Sequence Number field is equal to that stored with the visitor list entry for the mobile host and the Agent Address field indicates that this foreign agent serves the mobile host, the visitor list entry is be marked as authenticated for the period specified in the Service Lifetime field. The following actions occur at a cache agent for processing an authenticated Binding Notify message: - If the Registration Sequence Number field is greater than that stored with a location cache entry for the mobile host, the location cache entry is deleted. If the Agent Address field is not equal to the Home Address field and the Agent Address field does not indicate that the system receiving the reply serves the mobile host as a foreign agent, a new location cache entry is created that indicates the foreign agent specified in the Agent Address field serves the mobile host. This entry is marked to timeout after the period specified in the Service Lifetime field. - If the cache agent does not have a location cache entry for the mobile host, the Agent Address field is not equal to the Home Address field, and the Agent Address field does not indicate that the system receiving the reply serves the mobile host as a foreign agent, then the cache agent creates a location cache entry that indicates the foreign agent specified in the Agent Address field serves the mobile host. This entry is marked to timeout after the period specified in the Service Lifetime field. - If the Registration Sequence Number field is equal to that stored with the location cache entry for the mobile host, and the Agent Address field indicates the mobile host is served by the same foreign agent that is recorded in the existing location cache entry, the location cache entry is reauthenticated for the period specified in the Service Lifetime field. Johnson, Myles, Perkins Expires 14 August 1994 [Page 48] Internet Draft Internet Mobile Host Protocol 14 February 1994 11. Packet Transmission Examples The following sections describe examples of the actions that the various systems (mobile hosts, foreign agents, cache agents, and home agents) are required to perform under a range of typical scenarios. For simplicity, only the most important packet interactions are shown in each example. In these examples, it is also assumed that mobile hosts and foreign agents are always also cache agents. In each example, different line styles are used to represent the different types of packets, as follows: ---- normal IP packets ==== tunneled IP packets ~~~~ management packets 11.1. Mobile Host to Mobile Host Communications This section describes the basic operations when a mobile host (MH1) within range of a foreign agent (FA1) having a home agent (HA1) wants to communicate with another mobile host (MH2) within range of a foreign agent (FA2) having a home agent (HA2). The operations are shown diagrammatically in Figure 6. MH1 FA1 HA1 HA2 FA2 MH2 : : : : : : : : : Registration : : : 1. :<~~~~~~~~>:<~~~~~~~~>: :<~~~~~~~~>:<~~~~~~~~>: : : : : : : : : : : : : 2. :----------:------------------------>:=========>:--------->: : : : : : : : : : : : : 3. :<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~: Binding : : : : : : Notify : : : : : : : : 4. :==========:===================================>:--------->: : : : : : : : : : : : : v v v v v v Figure 6: Mobile host to mobile host communication Johnson, Myles, Perkins Expires 14 August 1994 [Page 49] Internet Draft Internet Mobile Host Protocol 14 February 1994 The following operations are shown in Figure 6: 1. MH1 and MH2 both register with their foreign agents (FA1 and FA2, respectively) and their home agents (HA1 and HA2, respectively). 2. Suppose MH1 wants to send a packet to MH2, and MH1 does not have a binding cached for MH2. MH1 transmits the packet using FA1 as its default router. Normal routing mechanisms eventually deliver the packet to MH2's home agent (HA2). H2 uses its location cache entry for MH2 to tunnel it to FA2. When FA2 receives the tunneled packet, it decapsulates it and uses its visitor list entry for MH2 to deliver the packet to MH2. 3. When HA2 receives the packet and tunnels the packet, it also sends a notification to the source (MH1) advising it to acquire a new binding for MH2. When MH1 receives the notification, it uses the methods described in section 10.2 to acquire MH2's current binding. 4. MH1 can then transmit future packets destined to MH2 by tunneling them directly to FA2. A close to optimal route is thus established. 11.2. Mobile Host Movement The example illustrated in Figure 6 can be extended by considering what happens when MH2 moves to a new network. This scenario is illustrated in Figure 7. The following operations are shown in Figure 7: 1. MH2 detects that it is connected to a new network, registers with a new foreign agent (FA3), and registers with its home agent (HA2). 2. MH2's new foreign agent (FA3) notifies MH2's previous foreign agent (FA2) that MH2 is now registered with FA3. This notification uses the previously negotiated authenticator that MH2 established with FA2 when it registered with FA2. 3. Suppose MH1 wants to send a packet to MH2. MH1 tunnels the packet to FA2, which is where its location cache indicates MH2 is currently registered. FA2 forwards the packet to FA3, using its updated location cache. Finally, FA3 decapsulates the packet for final delivery. Johnson, Myles, Perkins Expires 14 August 1994 [Page 50] Internet Draft Internet Mobile Host Protocol 14 February 1994 MH1 FA1 HA1 HA2 FA2 FA3 MH2 : : : : : : : : : : : : : : 1. : : : Regis- :<~~~~~~~~~~~~~~~~~>:<~~~~~~~>: : : : tration : : : : : : : : : : : 2. : : : : Binding :<~~~~~~~>: : : : : : Notify : : : : : : : : : : 3. :=========:============================>:========>:-------->: : : : : : : : : : : : : : : 4. :<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~: Binding : : : : : : : Notify : : : : : : : : : 5. :=========:======================================>:-------->: : : : : : : : : : : : : : : v v v v v v v Figure 7: Mobile host movement 4. FA2 recognizes that MH1 must have an old binding cached for MH2, since otherwise MH1 would not have tunneled the packet to FA2. FA2 thus sends MH1 a notification advising it to acquire a new binding for MH2. 5. Once MH1 acquires MH2's new binding, it sends future packets destined to MH2 by tunneling them to FA3. 11.3. Stationary Host to Mobile Host The example illustrated in Figure 6 can be modified by considering what happens when the source is a stationary host (denoted SH) that does not implement the IMHP protocol. This scenario is illustrated in Figure 8. The following operations are shown in Figure 8: 1. MH2 detects that it is connected to a new network. MH2 then registers with a new foreign agent (FA2) and with its home agent (HA2). Johnson, Myles, Perkins Expires 14 August 1994 [Page 51] Internet Draft Internet Mobile Host Protocol 14 February 1994 SH HA2 FA2 MH2 : : : : : Registration : : : 1. : :<~~~~~~~~~~>:<~~~~~~~~~~>: : : : : : : : : 2. :------------->:===========>:----------->: : : : : : : : : 3. :<~~~~~~~~~~~~~: Binding : : : : Notify : : : : : : v v v v Figure 8: Stationary host to mobile host communications 2. Suppose SH wants to send a packet to MH2. SH forwards the packet to MH2 using normal forwarding rules. The packet is eventually received by HA2, which tunnels it the MH2's known location, FA2. FA2 decapsulates the packet and delivers it to MH2. 3. When HA2 receives the packet from SH, HA2 notifies SH that it should attempt to acquire a new binding for MH2. SH does not understand IMHP management packets, and HA2 will eventually back off and only send the notifications occasionally. The packets from SH will continue to follow a Triangle Routing path, which is likely to be non-optimal. 11.4. Routing Loop Resolution Between Home Agent and Foreign Agent It is possible under rare circumstances for location cache inconsistencies to occur which IMHP must resolve. This section describes the resolution of the case in which a home agent has recorded that a particular foreign agent, FA, is serving a mobile host, MH, and yet the foreign agent claims not to serve that mobile host. This scenario is illustrated in Figure 9. The following operations are shown in Figure 9: 1. Assume MH's home agent, HA, has a binding in its location cache for MH that indicates FA is MH's current foreign agent. When HA receives a packet for MH it tunnels it to FA. Johnson, Myles, Perkins Expires 14 August 1994 [Page 52] Internet Draft Internet Mobile Host Protocol 14 February 1994 HA FA : : : : 1. :=============>: : : : : 2. :<=============: Special : : tunnel : : v v Figure 9: Resolution of a lost mobile host 2. If FA has no record of MH in either its location cache or visitor list, it decapsulates the packet and transmits it using a special tunnel. The packet will find its way back to HA, which will then detect the loop. HA drops the packet and may attempt to resolve the problem that caused it. 11.5. Routing Loop Resolution Between Cache Agents It is also possible under extreme circumstances relating to a faulty implementation for two or more cache agents to have location cache entries that form a loop for a particular mobile host. This example considers the case of three cache agents (CA1, CA2, and CA3) that have bindings in their location caches that form a loop for a mobile host, MH. The resolution of the loop is illustrated in Figure 10. The following operations are shown in Figure 10: 1. Assume CA1, CA2, and CA3 have location cache entries that form a loop for MH. If CA1 tunnels a packet destined for MH to CA2, CA2 will then tunnel the packet onwards to CA3, which will tunnel the packet back to CA1. 2. The loop is broken by notifications that are sent to the source of each tunnel. Each cache agent that receives the notification acquires a new binding for MH, which breaks the loop. Johnson, Myles, Perkins Expires 14 August 1994 [Page 53] Internet Draft Internet Mobile Host Protocol 14 February 1994 CA1 CA2 CA3 : : : : : : 1. :=========>:=========>: : : : : : : :<====================: : : : : : : 2. :<~~~~~~~~~:<~~~~~~~~~: : : : : : : :~~~~~~~~~~~~~~~~~~~~>: : : : : : : v v v Figure 10: Resolution of a routing loop between cache agents 12. Other Issues 12.1. Registration on a Home Network When a mobile host is connected to its home network and registered directly with a foreign agent that is also its home agent, it is important that its performance be approximately the same as that of an equivalent host that does not implement IMHP. It is also important that any hosts connected to the home network are able to communicate with the mobile host regardless of where the mobile host is connected. When a mobile host is not registered directly with its home agent/foreign agent, its home agent must answer any ARP requests for the mobile host with the home agent's own MAC address. This forces hosts on the home network to forward packets destined to the mobile host to the home agent, which will then tunnel them to the mobile host's current location. When the mobile host returns to its home network, the mobile host should register with the foreign agent that is also its home agent, in preference to any other foreign agent. This rule helps ensure optimal routing on the home network, as the home agent/foreign agent can deliver packets directly to the mobile host rather than tunneling them to another foreign agent on the same network for delivery. Johnson, Myles, Perkins Expires 14 August 1994 [Page 54] Internet Draft Internet Mobile Host Protocol 14 February 1994 When a mobile host registers with its home agent/foreign agent on its home network, the home agent/foreign agent should reply will the Foreign Service Lifetime field and Home Service Lifetime field in the Registration Reply Message set to the reserved value of 0xffffffff (all ones), indicating that this registration has an infinite lifetime. The mobile host thus need only register once with its home agent/foreign agent when it returns to its home network. The Reply Status field should also indicate that the mobile host has registered with its home agent/foreign agent. When a mobile host registers with its home agent/foreign agent on its home network, the home agent must stop answering ARP requests on the mobile host's behalf. The mobile host should answer any ARP requests, resulting in optimal routing on the home network. Either the home agent or the mobile host must also transmit a gratuitous ARP reply on the local network, so that systems on that network will begin to associate the mobile host's IP address with the mobile host's true MAC address instead of with the MAC address of the home agent. While on the home network, the movement discovery mechanisms described in Section 7.4 continue to operate. Therefore when no lower layer support is available, the home agent/foreign agent must continue to transmit regular Agent Advertisement messages. When the mobile host subsequently moves away from its home network and registers its new binding with its home agent using the mechanisms described in Section 8, the home agent must again process ARP requests on the mobile host's behalf. It must also ensure that the hosts connected to the home network that have cached the mobile host's MAC address delete this cache entry from their ARP caches. If all the hosts connected to the home network understand and process gratuitous ARPs, then the home agent may transmit a gratuitous ARP reply that indicates the mobile host's MAC address is that of the home agent. It is necessary for the gratuitous ARP reply to be retransmitted a number of times over a period of time to ensure with a high probability that that at least one ARP reply is received correctly by each host. Even if all gratuitous ARPs are lost, most ARP caches entries eventually time out. In some network configurations, it is possible that a host on a mobile host's home network can communicate with the mobile host even though the mobile host is not connected to its home network. It is therefore necessary, in these cases, for the home agent to issue the gratuitous ARPs every time the mobile host moves to a new foreign agent, even though the movement might not involve the home network. Johnson, Myles, Perkins Expires 14 August 1994 [Page 55] Internet Draft Internet Mobile Host Protocol 14 February 1994 Some existing hosts do not process gratuitous ARPs correctly. In this case, a mobile host should never answer ARP requests for itself. On the mobile host's home network, the mobile host's home agent should always answer ARP requests for the mobile host with its own MAC address. On other networks, only foreign agents need to send packets to the mobile host. These foreign agents use the MAC address that they learn during registration rather than relying on ARP for address resolution. 12.2. Location Cache and Visitor List Time Outs The location cache time outs used by cache agents and visitor list time outs used by foreign agents determine the maximum time of disruption if either a foreign agent fails or if a mobile host forgets to notify a previous foreign agent about a movement. As both these events are expected to be rare, the time out may be quite long. The latter event will usually only occur when a mobile host reboots. This effect of a reboot, however, can be eliminated by setting the visitor list time out to be equal to the average reboot time of mobile host. Unfortunately, as reboot times decrease, this option becomes unattractive. Another solution is to store the identity of previous foreign agents in non volatile memory in the mobile host. 12.3. Popups Some areas on the network will not have foreign agents available for use. When this situation arises, it is desirable that the user has at least some mobile functionality. In particular, the user might want to keep his IP address. A mobile host in this situation may operate as a "popup" [4] in order to maintain connectivity. The popup method as applied to IMHP can take one of two forms. In both forms, the mobile host would acquire a local address from a local address server (e.g., a server implementing DHCP [2]) and then report the allocated address to its home agent as its current foreign agent address. In the first form, the mobile host would specify that the home agent should not advertise this foreign agent address. The cost of this technique is that routing to the mobile host is always through a home agent, which is likely to be non-optimal. In the second form, the home agent would be allowed to advertise the mobile host's binding based on the allocated address in the same way it advertises the mobile host's binding based on a care-of address. Johnson, Myles, Perkins Expires 14 August 1994 [Page 56] Internet Draft Internet Mobile Host Protocol 14 February 1994 Although this method gives closer to optimal routing of packets, when mobile host movement does occur, communication might be lost for up to a location cache time out period, as a movement is equivalent to a foreign agent failing. In both cases, true mobile functionality depends on the ability of the mobile host to detect automatically that it has moved. Without a foreign agent this might be difficult. 12.4. Intermediate Cache Agents Any system can operate as a cache agent. This section discusses the use of cache agents in intermediate routers. A cache agent functioning in a intermediate router allows packets that it forwards from stationary hosts to avoid Triangle Routing, and can also offer some routing assistance to mobile hosts. An intermediate cache agent may learn about the bindings of mobile hosts by examining management packets that it forwards. The cache agent can then acquire acquiring authenticated bindings for these mobile hosts in the same way as any cache agent. The example illustrated in Figure 8 can be modified as shown in Figure 11 if some router near SH (such as SH's first-hop router) is capable of serving as a cache agent. The following operations are shown in Figure 11: 1. As in Figure 8. 2. As in Figure 8. 3. As in Figure 8. 4. Suppose a cache agent in some router, CA, examines the notification to SH as it forwards it. After acquiring an authenticated binding, CA can use it to tunnel packets that it receives destined for MH2 directly to FA2, thus making the route closer to optimal. 12.5. Password Algorithms IMHP does not specify the way in which the password is chosen for use in the Password field in Registration Request and Reply messages between a mobile host and its home agent. However certain issues should be noted when selecting an algorithm for choosing a Password. Johnson, Myles, Perkins Expires 14 August 1994 [Page 57] Internet Draft Internet Mobile Host Protocol 14 February 1994 SH CA HA2 FA2 MH2 : : : : : : : Registration : : : 1. : : :<~~~~~~~~>:<~~~~~~~~>: : : : : : : : : : : 2. :----------:------------->:=========>:--------->: : : : : : : : : : : 3. :<~~~~~~~~~:~~~~~~~~~~~~~~: Binding : : : : : Notify : : : : : : : 4. :----------:========================>:--------->: : : : : : : : : : : v v v v v Figure 11: Stationary host to mobile host communication with cache agent in first-hop router A password may simply remain fixed over time and be known by both the home agent and a mobile host. However, such a password may eventually be discovered by a malicious system. A better password is one that changes over time. One possibility is that the password consists of a random number and an encrypted version of that random number. However, this password is similarly open to replay attacks. An alternative, is for the password to consist of a monotonically increasing sequence number and an encrypted version of the sequence number. In the context of IMHP, the Registration Sequence number is suitable and, as it is already carried in the registration packets, does not need to be included in the Password. Replay attacks only become possible as the Registration Sequence Number wraps. The possibility of replay attacks may be reduced even further by again including a random number and an encrypted version of the random number in the Password. To allow sufficient flexibility in the Password algorithm used, the Password is set to be 64 bits in length. Johnson, Myles, Perkins Expires 14 August 1994 [Page 58] Internet Draft Internet Mobile Host Protocol 14 February 1994 13. IMHP Management Packet Formats This section describes the packet formats required to support the IMHP management protocol under the weak security model. All IMHP management packets are transmitted as UDP [8] packets using destination port ???. Each IMHP packet begins with the following common two-octet header: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |R| Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version The version number of the protocol in use. This document defines version 1 of the IMHP protocol. Routing (R) If the Routing (R) bit is set, the packet is forwarded using normal IP routing mechanisms only. Visitor list entries and location cache entries must not be used in routing the packet. If the Routing (R) bit is clear, the packet may be routed using visitor list entries and location cache entries in addition to normal routing mechanisms. This option is used to force packets addressed to a mobile host's IP address to be routed to a mobile host's home network, where they will be intercepted by the mobile host's home agent when the mobile host is currently away from its home network. Type The type of the packet, indicating which IMHP operation is being performed. The following Type codes are defined in this document: 0x10 = Agent Advertisement Message 0x11 = Agent Solicitation Message 0x20 = Registration Request Message 0x21 = Registration Reply Message Johnson, Myles, Perkins Expires 14 August 1994 [Page 59] Internet Draft Internet Mobile Host Protocol 14 February 1994 0x30 = Binding Inquire Message 0x31 = Binding Notify Message 0x32 = Binding Acknowledge Message The following sections define the packet formats for each of these IMHP management protocol packet types. The common two-octet header described above is included in each of these message format descriptions. Johnson, Myles, Perkins Expires 14 August 1994 [Page 60] Internet Draft Internet Mobile Host Protocol 14 February 1994 13.1. Agent Advertisement Message An Agent Advertisement message is sent by a foreign agent to advertise its services on a local network. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |R| Type |H| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incarnation Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertisement Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP fields: Source Address An IP address belonging to the interface of the foreign agent on which this message is sent. Destination Address This field should normally be set to the configured Agent Advertisement Address for this foreign agent, which may be either the reserved "all mobile hosts" address, or the limited-broadcast address, 255.255.255.255, although this field may also be set to the IP address of an individual host connected to the local network. Time-to-live 1 IMHP fields: Version 1 Routing (R) 0 Johnson, Myles, Perkins Expires 14 August 1994 [Page 61] Internet Draft Internet Mobile Host Protocol 14 February 1994 Type 0x10 Home Agent (H) The Home Agent (H) bit is set to indicate that the foreign agent sending this Agent Advertisement message is also acting as a home agent and will only accept registration requests for mobile hosts that it serves as a home agent. Reserved Sent as 0; ignored on reception. Incarnation Number The Incarnation Number field contains the incarnation number of the foreign agent sending the Agent Advertisement message. Advertisement Interval The Advertisement Interval field contains the maximum interval at which the foreign agent sends periodic Agent Advertisement messages, expressed in tenths of a second. If a foreign agent does not send periodic Agent Advertisements, then this field is set to 0. Agent Address The Agent Address field contains the care-of address that the foreign agent is offering for use by mobile hosts. Johnson, Myles, Perkins Expires 14 August 1994 [Page 62] Internet Draft Internet Mobile Host Protocol 14 February 1994 13.2. Agent Solicitation Message The Agent Solicitation message is used by a mobile host to request foreign agents, connected to the same network, to advertise their services. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |R| Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP fields: Source Address The Source Address field contains an IP address belonging to the interface on which this message is sent. Destination Address The Destination Address field normally contains the configured Agent Solicitation Address of the mobile host, which may be either the reserved "all foreign agents" multicast address, or the limited-broadcast address, 255.255.255.255, although this field may also be set to the IP address of an individual foreign agent on the local network. Time-to-live 1 IMHP fields: Version 1 Routing (R) 0 Type 0x11 Johnson, Myles, Perkins Expires 14 August 1994 [Page 63] Internet Draft Internet Mobile Host Protocol 14 February 1994 Reserved Sent as 0; ignored on reception. Johnson, Myles, Perkins Expires 14 August 1994 [Page 64] Internet Draft Internet Mobile Host Protocol 14 February 1994 13.3. Registration Request Message The Registration Request Message is used by a mobile host to register with a foreign agent, or by a foreign agent to register a mobile host with its home agent. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |R| Type |F|H|N|P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Agent Service Lifetime (F) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Agent Authenticator (F) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Address (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Service Lifetime (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Agent Password (H) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous Foreign Agent Address (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous Foreign Agent Authenticator (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous Foreign Agent Service Lifetime (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP fields: Source Address The Source Address field contains an IP address belonging to the interface on which this message is sent. Destination Address The Destination Address field contains an IP address of the foreign agent or the home agent that is to receive this message. Johnson, Myles, Perkins Expires 14 August 1994 [Page 65] Internet Draft Internet Mobile Host Protocol 14 February 1994 Time-to-live The Time-to-live field must be set to 1 when the message is from a mobile host to a foreign agent. Otherwise, it should be set to MAXTTL. IMHP fields: Version 1 Routing (R) 0, except as specified below. Type 0x20 Foreign Agent (F) If the Foreign Agent (F) bit is set, the mobile host is requesting registration with a foreign agent. All Registration Request messages sent by a mobile host must have the Foreign Agent (F) bit set. Fields in the message format above marked (F) are included in the packet only when the L bit is set. Home Agent (H) If the Home Agent (H) is set and the Foreign Agent (F) bit is set, the mobile host is requesting registration with a foreign agent and with its home agent. If the Home Agent (H) is set and the Foreign Agent (F) bit is clear, a foreign agent is requesting registration of the mobile host with its home agent on behalf of the mobile host. Fields in the message format above marked (H) are included in the packet only when the H bit is set. Notify (N) If the Notify (N) bit is set, the mobile host is requesting this foreign agent to notify the mobile host's previous foreign agent of its new binding, as described by the Previous Foreign Johnson, Myles, Perkins Expires 14 August 1994 [Page 66] Internet Draft Internet Mobile Host Protocol 14 February 1994 Agent Address, Previous Foreign Agent Authenticator, and Previous Foreign Agent Service Lifetime fields. The N bit may be set only when the Foreign Agent (F) bit is also set. Fields in the message format above marked (N) are included in the packet only when the N bit is set. Private (P) If the Private (P) bit is set, this binding must be kept private and may not be advertised to systems other than the mobile host's home agent and current foreign agent; other the mobile host's binding may be advertised as needed to any system. Reserved Sent as 0; ignored on reception. Home Address The Home Address field contains the home address of the mobile host attempting registration. Registration Sequence Number The Registration Sequence Number field contains the Registration Sequence Number of the mobile host attempting registration. Agent Address When the Registration Request message is from a mobile host to a foreign agent, the Agent Address field is the same as the Destination Address field. When the Registration Request message is from a foreign agent to home agent, the Agent Address contains the care-of address that the foreign agent is providing to the mobile host. Foreign Agent Service Lifetime (F) The Foreign Agent Service Lifetime field contains the length of time, expressed in tenths of a second, that the mobile host requests the foreign agent to provide service without requiring reregistration. Johnson, Myles, Perkins Expires 14 August 1994 [Page 67] Internet Draft Internet Mobile Host Protocol 14 February 1994 A value of zero implies the mobile host is requesting de-registration. The reserved value of 0xffffffff (all ones) implies an infinite period. Foreign Agent Authenticator (F) The foreign agent Authenticator field contains a value, chosen by the mobile host, that allows this foreign agent to later authenticate any notifications sent by the mobile host that it has moved. Home Agent Address (H) The home agent Address field contains either the mobile host's home agent address, or the mobile host's own home address. In the latter case, the Route (R) bit must be set to force the Registration Request message to be routed to the mobile host's home network. Home Agent Service Lifetime (H) The Home Agent Service Lifetime field contains the length of time, expressed in tenths of a second, that the mobile host requests its home agent to provide service without requiring reregistration. A value of zero implies the mobile host is requesting to de-register. The reserved value of 0xffffffff (all ones) implies an infinite period. Home Agent Password (H) The Home Agent Password field is a password used by the home agent to authenticate the mobile host's identity. The home agent Password is based on a shared secret between the mobile host and its home agent. Previous Foreign Agent Address (N) The Previous Foreign Agent Address field contains the address of a previous foreign agent of this mobile host that this foreign agent should notify of the mobile host's new binding. Previous Foreign Agent Authenticator (N) The Previous Foreign Agent Authenticator field contains the authenticator to be used by this foreign agent in notifying the mobile host's previous foreign agent of the mobile host's Johnson, Myles, Perkins Expires 14 August 1994 [Page 68] Internet Draft Internet Mobile Host Protocol 14 February 1994 new binding. This value must have been established with the previous foreign agent when the mobile host earlier registered with that foreign agent. Previous Foreign Agent Service Lifetime (N) The Previous Foreign Agent Service Lifetime field contains the length of time, expressed in tenths of a second, for which the previous foreign agent agreed to provide service to the mobile host without requiring reregistration. Johnson, Myles, Perkins Expires 14 August 1994 [Page 69] Internet Draft Internet Mobile Host Protocol 14 February 1994 13.4. Registration Reply Message The Registration Reply Message is used by a foreign agent to send registration replies to a mobile host, and by a home agent to send registration replies to a mobile host through a foreign agent. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |R| Type |F|H|N| Reserved| Reply Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Agent Service Lifetime (F) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Agent Authenticator (F) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Service Lifetime (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Agent Password (H) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous Foreign Agent Authenticator (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP fields: Source Address The Source Address field contains an IP address belonging to the interface on which this message is sent. Destination Address When the Registration Reply message is being sent from a home agent to a foreign agent, the Destination Address field contains the address of the foreign agent. When the message is being sent from a foreign agent to a mobile host, the Destination Address field contains the home address of the mobile host. Johnson, Myles, Perkins Expires 14 August 1994 [Page 70] Internet Draft Internet Mobile Host Protocol 14 February 1994 Time-to-live The Time-to-live field must be set to 1 when the Registration Reply message is being sent from a foreign agent to a mobile host. Otherwise, it should be set to MAXTTL. IMHP fields: Version 1 Routing (R) 0 Type 0x20 Foreign Agent (F) If the Foreign Agent (F) is set, the message contains a reply from a foreign agent to a mobile host. Fields in the message format above marked (F) are included in the packet only when the Foreign Agent (F) bit is set. Home Agent (H) If the Home Agent (H) bit is set, the message contains a reply from a home agent to a mobile host through its foreign agent. Fields in the message format above marked (H) are included in the packet only when the Home Agent (H) bit is set. Notify (N) If the Notify (N) bit is set, the foreign agent has received an acknowledgement from notification to the previous foregin agent requested by the mobile host in the Registration Request message. The Previous Foreign Agent Authenticator field contains the authenticator value received in the acknowledgement. The N bit may be set only when the Notify (N) bit was also set in the Registration Request message. Fields in the message format above marked (N) are included in the packet only when the N bit is set. Johnson, Myles, Perkins Expires 14 August 1994 [Page 71] Internet Draft Internet Mobile Host Protocol 14 February 1994 Reserved Sent as 0; ignored on reception. Reply Status The Reply Status field contains an acceptance or rejection code as follows: 0x00 = Registration accepted. 0x01 = Registration accepted; connected to home network. 0x40 = Registration accepted by foreign agent; home agent registration pending. 0x80 = Registration rejected; no reason given. 0x81 = Registration rejected; authentication failure with home agent. 0x82 = Registration rejected; authentication failure with foreign agent. 0x83 = Registration rejected; home agent has insufficient resources. 0x84 = Registration rejected; foreign agent has insufficient resources. 0x85 = Registration rejected; mobile host Registration Sequence Number less than expected. 0x86 = Registration rejected; foreign agent requires home agent registration. 0x87 = Registration rejected; no response received from home agent by foreign agent. Home Address The Home Address field contains the home address of the mobile host attempting registration. Johnson, Myles, Perkins Expires 14 August 1994 [Page 72] Internet Draft Internet Mobile Host Protocol 14 February 1994 Registration Sequence Number The Registration Sequence Number field contains the Registration Sequence Number of the mobile host attempting registration. Agent Address The Agent Address contains the care-of address that the foreign agent is providing the mobile host. Foreign Agent Service Lifetime (F) The Foreign Agent Service Lifetime field contains the length of time, expressed in tenths of a second, that a foreign agent guarantees it will attempt to maintain the registration. A value of zero implies the mobile host may consider itself de-registered. The reserved value of 0xffffffff (all ones) implies an infinite period. Foreign Agent Authenticator (F) The foreign agent Authenticator field contains the same value as that included in the Registration Request message for which this reply is being sent. Home Agent Service Lifetime (H) The Home Agent Service Lifetime field contains the length of time, expressed in tenths of a second, that the home agent guarantees it will attempt to maintain the registration. A value of zero implies the mobile host may consider itself de-registered. The reserved value of 0xffffffff (all ones) implies an infinite period. Home Agent Password (H) The 64-bit Home Agent Password field is a password used by the mobile host to authenticate the home agent's identity. The home agent Password is based on a shared secret between the mobile host and its home agent. Previous Foreign Agent Authenticator (N) The Previous Foreign Agent Authenticator field contains the authenticator value received by the foreign agent in the Johnson, Myles, Perkins Expires 14 August 1994 [Page 73] Internet Draft Internet Mobile Host Protocol 14 February 1994 Binding Acknowledge message from the mobile host's previous foreign agent. Johnson, Myles, Perkins Expires 14 August 1994 [Page 74] Internet Draft Internet Mobile Host Protocol 14 February 1994 13.5. Binding Inquire Message A Binding Inquire message is sent by a IMHP entity to another IMHP entity to ask it for the binding it has stored for a specified mobile host. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |R| Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP fields: Source Address An IP address belonging to the interface on which this message is sent. Destination Address The IP address of the mobile host for which the binding is requested. Time-to-live MAXTTL IMHP fields: Version 1 Routing (R) 1 Type 0x30 Johnson, Myles, Perkins Expires 14 August 1994 [Page 75] Internet Draft Internet Mobile Host Protocol 14 February 1994 Reserved Sent as 0; ignored on reception. Home Address The Home Address field contain the home address the mobile host for which the source IMHP entity is requesting a binding. Authenticator The Authenticator field contains a random number, chosen by the sender. Only replies containing the same value in the Authenticator field are authenticated. Johnson, Myles, Perkins Expires 14 August 1994 [Page 76] Internet Draft Internet Mobile Host Protocol 14 February 1994 13.6. Binding Notify Message The Binding Notify message is used to reply to a Binding Inquire message, to notify a mobile host's previous foreign agent of the mobile host's new binding, and to inform a system that it should attempt to acquire a new binding for some mobile host. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |R| Type |P|A|B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator (B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Sequence Number (B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Agent Address (B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Lifetime (B) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP fields: Source Address An IP address belonging to the interface on which this message is sent. Destination Address The IP address of the IMHP entity to which this Binding Notify message is being sent. Time-to-live MAXTTL Johnson, Myles, Perkins Expires 14 August 1994 [Page 77] Internet Draft Internet Mobile Host Protocol 14 February 1994 IMHP fields: Version 1 Routing (R) 0 Type 0x31 Private (P) If the Private (P) bit is set, the mobile host's binding must be kept private and may not be advertised to any system other than the mobile host's home agent and current foreign agent; otherwise the binding may be advertised as needed. This bit is valid only if the Binding Present (B) bit is also set. Acknowledge (A) If the Acknowledge (A) bit is set, an acknowledgement with a Binding Acknowledge message is requested. Binding Present (B) If the Binding Present (B) bit is set, the Foreign Agent Authenticator should be used by the entity receiving the Binding Notify message to authenticate the mobile host's binding also included in the message. Fields in the message format above marked (B) are included in the packet only when the Binding Present (B) bit is set. Reserved Sent as 0; ignored on reception. Home Address This field contains the IP address of the mobile host to which the notification refers. Johnson, Myles, Perkins Expires 14 August 1994 [Page 78] Internet Draft Internet Mobile Host Protocol 14 February 1994 Authenticator (B) This field contains a value that may be used by the entity receiving the Binding Notify message to authenticate the notification. In the case of a notification to a mobile host's previous foreign agent, this field should be set to the Foreign Agent Authenticator established when the mobile host registered with that foreign agent. In the case of a notification in response to a Binding Inquire message, this field should be set to the authenticator value received in the Binding Inquire message. Registration Sequence Number (B) If the Private (P) bit is not set, this field contains the mobile host's current Registration Sequence Number; otherwise, this field is sent as 0 and is ignored on reception. Agent Address (B) If the Private (P) bit is set, this field contains the mobile host's home address. If the Private (P) bit is not set, this field contains the care-of address provided by the mobile host's current foreign agent, if the mobile host is not connected to its home network, or contains the mobile host's home address, otherwise. Service Lifetime (B) This field contains the maximum time, in tenths of a second, that the binding should be kept if the notification is authenticated. Johnson, Myles, Perkins Expires 14 August 1994 [Page 79] Internet Draft Internet Mobile Host Protocol 14 February 1994 13.7. Binding Acknowledge Message A Binding Acknowledge message is used to reply to a Binding Notify message for which the Acknowledge (A) bit was set. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |R| Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP fields: Source Address An IP address belonging to the interface on which this message is sent. Destination Address The Destination Address field is set to the source address field from the Binding Notify message being acknowledged. Time-to-live MAXTTL IMHP fields: Version 1 Routing (R) 0 Type 0x32 Johnson, Myles, Perkins Expires 14 August 1994 [Page 80] Internet Draft Internet Mobile Host Protocol 14 February 1994 Reserved Sent as 0; ignored on reception. IP Address of mobile host This field contains the IP address of the mobile host to which the reply refers. Registration Sequence Number This filed contains the current Registration Sequence Number of the mobile host to which the reply refers. Foreign Agent Authenticator This field must have the same value as the Authenticator field sent in the corresponding Binding Notify Message. It is used to authenticate the acknowledgement. Johnson, Myles, Perkins Expires 14 August 1994 [Page 81] Internet Draft Internet Mobile Host Protocol 14 February 1994 References [1] R. T. Braden and J. B. Postel. Requirements for Internet gateways. RFC 1009, June 1987. [2] R. Droms. Dynamic Host Configuration Protocol. RFC 1541, October 1993. [3] John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr. IP-based protocols for mobile internetworking. In Proceedings of the SIGCOMM '91 Conference: Communications Architectures & Protocols, pages 235--245, September 1991. [4] John Ioannidis, Gerald Q. Maquire Jr, and Steve Deering. Protocols for supporting mobile IP hosts. Internet Draft, June 1992. [5] David B. Johnson. Transparent Internet routing for IP mobile hosts. Internet Draft, July 1993. [6] Andrew Myles and Charles Perkins. Mobile IP. Internet Draft, August 1993. [7] C. Perkins and Y. Rekhter. Support for mobility with connectionless network layer protocols (transport layer transparency). Internet Draft, January 1993. [8] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. [9] J. B. Postel, editor. Internet Protocol. RFC 791, September 1981. [10] J. B. Postel. Multi-LAN address resolution. RFC 925, October 1984. [11] Fumio Teraoka. VIP: IP extensions for host migration transparency. Internet Draft, July 1992. [12] Fumio Teraoka, Kim Claffy, and Mario Tokoro. Design, implementation, and evaluation of Virtual Internet Protocol. In Proceedings of the 12th International Conference on Distributed Computing Systems, pages 170--177, June 1992. [13] Fumio Teraoka, Yasuhiko Yokote, and Mario Tokoro. A network architecture providing host migration transparency. In Proceedings of the SIGCOMM '91 Conference: Communications Architectures & Protocols, pages 209--220, September 1991. Johnson, Myles, Perkins Expires 14 August 1994 [Page 82] Internet Draft Internet Mobile Host Protocol 14 February 1994 Authors' Addresses David B. Johnson School of Computer Science Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213-3891 Work: +1 412 2687399 Fax: +1 412 6815739 E-mail: dbj@cs.cmu.edu Andrew Myles Electronics Department Macquarie University 2109 Sydney, Australia Work: +61 2 8059071 Home: +61 2 8786060 Fax: +61 2 8059128 E-mail: andrewm@mpce.mq.edu.au Charles Perkins Room J1-A25 T. J. Watson Research Center IBM Corporation P. O. Box 218 Yorktown Heights, NY 10598 Work: +1 914 7897350 Fax: +1 914 7847007 E-mail: perk@watson.ibm.com Johnson, Myles, Perkins Expires 14 August 1994 [Page 83]