Network Working Group Charles Perkins INTERNET DRAFT IBM Corporation David B. Johnson Carnegie Mellon University Andrew Myles Macquarie University 22 September 1994 Mobility Support in IPv6 Abstract This document presents some suggestions for mobility support in IPv6, drawing on the experiences of the authors in our work with IPv4 mobility within the Mobile IP Working Group of the IETF. The development of IPv6 presents a rare opportunity to consider in what ways mobility could explicitly be taken into account in the design of IPv6, and in what ways the current work on mobility within IPv4 can or should be changed to take advantage of IPv6. We believe that the most important function needed to support mobility is the reliable and timely notification of a mobile node's current location to other nodes that need it: the home agent, the foreign agent, and correspondent nodes. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Perkins, Johnson, Myles Expires 22 March 1995 [Page i] Internet Draft Mobility Support in IPv6 22 September 1994 1. Introduction Recent impetus has been given to the creation of a new protocol to replace IPv4; in this document, that new protocol will be called IPv6. This document draws on the experiences we have had during the design of a set of protocols for the operation of mobile computers for IPv4, in our work within the Mobile IP Working Group of the IETF. Mobile computers are very likely to account for a substantial fraction of the future population of the Internet during the lifetime of IPv6. We expect that the combination of a projected need for mobile computing, and clearly specified features within IPv6 to enable it, should make the necessary operations essentially automatic and universally available. The IETF Mobile IP Working Group's current protocol design for mobility in IPv4 could be adapted for use in IPv6, with only the straightforward changes needed to accommodate differences between IPv4 and IPv6 such as the size of addresses. However, the development of IPv6 presents a rare opportunity, in that the design of IPv6 is still in progress, and in that there is no existing installed base of IPv6 hosts or routers with which we must be compatible. This draft, therefore, considers in what ways mobility could explicitly be taken into account in the design of IPv6, and in what ways the IPv4 mobility design can or should be changed to take advantage of IPv6. We believe that the most important function needed to support mobility is the reliable and timely notification of a mobile node's current location to other nodes that need it. The home agent needs this location information in order to forward intercepted packets from the home network to the mobile node, and correspondent nodes need this information in order to send their own packets directly to the mobile node. A foreign agent must also know that the mobile node is visiting in order to deliver arriving packets to the mobile node. 2. Basic Operation From the model of operation developed for enabling mobile networking for IPv4, we borrow the concepts of Home Network, Home Address, Home Agent, Foreign Agent, Care-of address, and Binding. Accordingly, mobile computers will have two IPv6 addresses whenever they are roaming away from their home network. One is permanent, and the other is temporary. In brief, using the IPv4 language, we have a basic model of operation in which a mobile node can always be reached by sending packets to its Home (permanent) address. Assuming the mobile node is not Perkins, Johnson, Myles Expires 22 March 1995 [Page 1] Internet Draft Mobility Support in IPv6 22 September 1994 present on its home network, packets arriving for it there will be intercepted by the home agent and forwarded to a Care-of Address. When the foreign agent receives them, the packets can then be delivered directly to the mobile node. It is expected that mobile nodes will collect offers of service from foreign agents in the area, select one or more of the available care-of addresses, and make sure the home agent is aware of the currently valid care-of address(es). The method of reporting the binding to the home agent (i.e., the association between care-of address and home address) is substantially different than what is currently specified for IPv4. 3. Binding Updates Also borrowed from existing work on route optimization for IPv4 mobility is the concept of a location cache for mobile node bindings. In IPv6, we recommend that all IPv6 nodes be capable of caching the location of mobile nodes with which they want to communicate, and that this location cache be integrated with the node's conventional routing table. We view it as essential for scalability and performance that correspondent nodes be able to learn the location of a mobile node and to be able to cache this knowledge for use in sending future packets directly to the mobile node. By caching the location of a mobile node, optimal routing of packets can be achieved between the correspondent node and the mobile node. Bypassing the home agent by routing packets directly to the mobile node eliminates congestion at the home agent and thus contributes significantly to the overall health of the Internet. Moreover, many communications between the mobile nodes and its correspondent nodes can be carried out with no assistance from the home agent. Thus, the impact of failure at the home agent can be drastically reduced. This is important because many administrative domains will have a single home agent to serve a particular home network, and thus a single point of failure for communications to nodes on that home network. Besides that, communications between the home agent and any mobile node depend on perhaps many intervening networks; thus, there are many more ways that packets can fail to reach a mobile node when the home agent is depended upon as an intermediate node. This would be particularly relevant on, say, trans-oceanic links between home agent and mobile node. Caching the binding of a mobile node at the correspondent node enables communication with the mobile nodes even if the home agent fails or is difficult to contact over the Internet. Perkins, Johnson, Myles Expires 22 March 1995 [Page 2] Internet Draft Mobility Support in IPv6 22 September 1994 Binding updates are a form of routing updates; and, handled incorrectly, route updates are a source of security problems, routing loops, and congestion. We assume that in the deployed IPv6 systems there will be access to suitable authentication mechanisms which can authenticate binding updates. 4. Sending Binding Updates We introduce a new standard type of IPv6 end-to-end extension in which a mobile node can transmit a binding update to another IPv6 node. The binding update should be placed in the IPv6 packet after any routing header, since the binding update should only be processed by the destination node rather than by each hop along the path. The binding update could be encoded as a separate extension header, or as an option within the end-to-end extension header. The latter alternative has the advantage that it does not require the allocation of any new protocol number, although there isn't any shortage yet of protocol numbers for IPv4. By encoding the binding update in this way, it can be included in any normal data packet (such as TCP or UDP) or can be sent in a separate packet containing no data. The binding update should contain the mobile node's care-of address, a sequence number for the binding, and possibly a lifetime for the binding. Note that the mobile node's home address will always be available as the source address of the packet including the binding update. After moving to a new location, the mobile node registers its new binding with its home agent by sending a packet containing a binding update to its home agent. This binding update must include a bit indicating that an acknowledgement is needed from the home agent. By default, the routing infrastructure of the Internet will route packets for a mobile node to its home network; this is true of any hierarchical routing and addressing scheme, whether provider-based or geographical. When it moves to a new location, a mobile node maintains an accurate registry of its current location at its home agent by registering. Since the registry is available on the home network, packets can be addressed to the mobile node and intercepted by the home agent without the sender knowing that the node is mobile, and without requiring any special routing support for mobile nodes anywhere else in the Internet. Placing the registry of a mobile node's current location at the home network also has the benefit of allowing each organization owning a home network to manage the home agent for the mobile nodes assigned to its own network. A binding update within an IPv6 header can also be included in any normal data packet (say, transmitted via TCP) sent to a correspondent Perkins, Johnson, Myles Expires 22 March 1995 [Page 3] Internet Draft Mobility Support in IPv6 22 September 1994 node with which a mobile node has an active transport-level connection. For each correspondent node, an indication is kept by the mobile node to determine whether or not the correspondent node has been sent a fresh binding update since the last time any movement to a new foreign agent has occurred. When a packet is sent to a correspondent node which hasn't been sent a fresh update, the mobile node includes the update within the packet's IPv6 header, and indicates that the update has been sent. Thus, correspondent nodes are generally kept updated and can send almost all data packets directly to the mobile node. Such binding updates are not generally required to be acknowledged. The binding update optionally can be sent in a separate packet whenever the mobile node wishes to update its correspondents, even when there is no data which otherwise needs to be sent. This would only be done if the mobile node suspects that its home agent is not operational, too far away, or that there is an immediate need for the correspondent node to obtain the location information. 5. Delivering Packets to a Mobile Node Home agents, and correspondent nodes that have received a binding update for that mobile node, can send packets directly to the mobile node's current location. We believe that a special form of encapsulation should be used for this purpose, analogous to that defined within the IPv4 draft mobility specification. This ``thin'' encapsulation can use much less space than encapsulation with a full IPv6 header, especially because of the 16 byte length of IPv6 addresses. Better encapsulation could easily enable a significant reduction of many data streams, producing nontrivial savings. This reduction is even more important in the frequent case in which the mobile node is connected to its foreign agent by some low-speed wireless medium. A packet to the mobile node is encapsulated using the care-of address as the destination address in the outer IPv6 header. Then, when the foreign agent receives the encapsulated packet, it will strip the encapsulation and deliver the packet (if possible) to the mobile node. After the foreign agent strips the encapsulation, it is no longer possible for the mobile node to determine whether the packet was encapsulated by the home agent, or by a correspondent node. If the packet was encapsulated by the home agent, then the correspondent node must have been unaware of the current location of the mobile node, and the mobile node should be advised to send its correspondent a binding update. This advice can be obtained in several ways, but Perkins, Johnson, Myles Expires 22 March 1995 [Page 4] Internet Draft Mobility Support in IPv6 22 September 1994 perhaps the cleanest technique is for the foreign agent to send a hint, along with the data packet, to the mobile node. This hint can be included in the packet by re-encapsulating the packet at the foreign agent (using essentially the same thin encapsulation protocol) before transmitting the packet to the mobile node. The extra transmission time from the foreign agent to the mobile node due to the encapsulation should not be an issue since this action will occur only rarely compared to the flow of normal data packets. When the mobile node receives the advice, it will determine whether the correspondent node requires a binding update. Thus, the correspondent node will quickly be able to use a more optimal route for transmission to the mobile node, and the home agent will be relied upon for only a small percentage of the overall data traffic destined for the mobile node. Likewise, the foreign agent will rarely have to re-encapsulate any data packets destined for the mobile node for the purposes of transmitting such advice. Another important advantage of this scheme is that the mobile node can send binding updates to its correspondent hosts without requiring any acknowledgement. Occasionally, the binding update might be lost, but in that case the mobile node will retransmit after a short timeout when it determines that the first attempt may have failed. Since the mobile host sends binding updates to its active correspondents soon after entering the service area of a new foreign agent, any delays due to stale or nonexistent location caches at correspondent nodes will be short-lived. The mobile node achieves location privacy simply by limiting the correspondents to which it will send binding updates. No other IPv6 nodes are authorized to send binding updates on behalf of the mobile node. No matter how binding updates are transmitted to correspondent nodes, some sort of back-off scheme must be implemented in the mobile node's software to avoid a rush of updates upon every movement to a new service area. Likewise, the foreign agent should avoid sending a rush of advice encapsulations to any one of its mobile nodes. Finally, some consideration should be made for the continued existence of IPv4 correspondent nodes, which are unlikely to cache bindings. 6. Foreign Agent Considerations Given the ability to securely notify other IPv6 nodes of its current location, a mobile node can also facilitate a smooth transition between service from one foreign agent to another one simply by sending a binding update to its previous foreign agent. This binding Perkins, Johnson, Myles Expires 22 March 1995 [Page 5] Internet Draft Mobility Support in IPv6 22 September 1994 update must be acknowledged by the previous foreign agent. Then, the foreign agent (acting as a cache agent) can forward packets to the new foreign agent for direct delivery to the mobile node. If a packet arrives at the previous foreign agent for the mobile node, the previous foreign agent encapsulates the packet and delivers it to the new foreign agent. If the previous foreign agent does not receive such a binding update, and the packet cannot be delivered to the mobile node, it encapsulates the packet for delivery to the home agent, using its own address as the source address in the outer header. When the new foreign agent receives such an encapsulated packet from a previous foreign agent, it decapsulates it and delivers it to the mobile node. Likewise, if the home agent receives such an encapsulated packet for the mobile node, it decapsulates and re-encapsulates the packet (some optimization is available here :-) for delivery to the new foreign agent. In this situation, the home agent must check that it is not trying to deliver the packet back to the same foreign agent from which it came; otherwise, routing loops might develop. When the home agent determines in this way that it does not have a valid binding for the mobile node, further processing may be attempted by the home agent but is undefined here. Many other operations, related to registration of the mobile node in a new service area, are likely to become important as mobile nodes become more prevalent. For instance, a foreign agent may wish to: - authenticate the identity of its clients - charge for its services - produce or share a session key with one of its clients - negotiate a compression algorithm - manage the resources of its communications devices These considerations are mostly outside the scope of this document. In all cases, though, we suggest that the need for performing such protocol actions, to satisfy additional requirements, must be indicated in extensions to the basic service advertisement protocol. The actual protocol actions performed in response to the extensions would be carried out at layers above IPv6 (e.g., UDP). For instance, if the foreign agent wishes to authenticate the identity of its prospective clients, it should use an extension to the service advertisement message to indicate this. Then, the mobile host will satisfy the foreign agent's requirement by responding with Perkins, Johnson, Myles Expires 22 March 1995 [Page 6] Internet Draft Mobility Support in IPv6 22 September 1994 the appropriate protocol operations (which are undefined here). Note that if the foreign agent can authenticate any binding update issued by the mobile node during operation, that authentication is likely to be good enough to also authenticate the identity of the mobile node. If the mobile node is to be billed for the foreign agent's services, then surely authentication will be needed. In addition, the foreign agent should append a billing extension to the basic advertisement, so that the mobile node can select among competing services if they are available, and so that the mobile node can supply the information needed by the foreign agent to effect the financial transactions. Similarly, encryption and/or compression services might be advertised by extensions to the basic service advertisements. Further negotiations will not be described in this document, at least until the ideas have been much more thoroughly worked out. If a mobile node receives a broadcast or multicast advertisement for service that the foreign agent is not really equipped to provide, then the foreign agent will have to reject attempts by that mobile node to transmit data through its interfaces. The foreign agent can do that by sending an ICMP 'Resource Unavailable' message back to the mobile node. Implementing this model of service by the foreign agent does not require any registration transactions. It is also suggested that service advertisement messages issued by the foreign agent contain an indication that no additional resources are currently available, so that the mobile node does not have to waste time sending packets through an agent which cannot forward them. The foreign agent must clearly be aware of the addresses of the mobile nodes which consider themselves bound to its care-of address. A possible way in which this could be achieved with very low overhead is for foreign agent to inspect the source addresses of packets that it forwards. Any mobile node sending packets through a foreign agent may be assumed to have sent the advertised care-of address in a binding update to its home agent. However, this simple strategy has the disadvantage of requiring the foreign agent to inspect each incoming packet, and search a table, which might be too time consuming. Therefore, we believe it is more appropriate for the mobile node to send a binding update to its proposed foreign agent also. This binding update could be included within the same packet as the binding update sent to the home agent. As above, in order to simplify the task of authentication by the ultimate recipient (in this case the home agent), the binding update to the foreign agent must be included in an encapsulation of the original binding update. In this way, the foreign agent does not have to do a table lookup for Perkins, Johnson, Myles Expires 22 March 1995 [Page 7] Internet Draft Mobility Support in IPv6 22 September 1994 the source address of every incoming packet, and it gets each binding update in a packet addressed to itself. 7. Foreign Agents and Local Addresses In the IPv4 mobility protocol, packets for a mobile node are tunneled to the mobile node's current care-of address, for delivery to the mobile node. The care-of address must be an address within the network being visited by the mobile node, so that the normal routing of the Internet will deliver the packet to that foreign network. The care-of address may either be the address of a foreign agent in that foreign network, or may be a temporary local address obtained by means such as DHCP. One reason for requiring the use of a foreign agent in IPv4 is the preservation the limited IPv4 address space. To require each mobile node to acquire its own temporary local address within the network it is visiting would force possibly large portions of the address space to be left available for such dynamic allocation. Any network willing to have mobile nodes visit would need to leave a pool of available addresses, and the number of visiting mobile nodes would be limited to the size of that pool. The address space size is less a concern in IPv6, and so it is feasible to allow each mobile node to obtain a new care-of address each time it enters a new area of mobile services. However, such an approach would eliminate the possibility of smooth handoffs between the new and previous foreign agents, unless special arrangements are made with the agents managing the local transactions for the temporary care-of address allocation. It is likely that, when a mobile node obtains a new care-of address, it would deallocate the previous care-of address by explicitly sending a message to the address allocation authority (e.g., DHCP in IPv4). For smooth handoffs, we could specify that the latter authority contact its cluster agent (e.g., BOOTP relay in IPv4) with instructions regarding the forwarding of packets destined for the previous care-of address. What is wanted, is a good way to notify all the routers into the cluster of the previous care-of address, that packets for the mobile node should be forwarded to a new care-of address. This is likely to be a tricky operation. For this reason, as well as the possibility of offering all the services outlined in the previous section, we recommend that foreign agents be located in every cluster offering services to mobile nodes. If not, then we suggest that an address allocation authority be located on each cluster; then, of course, it might as well be designated the foreign agent for the mobile nodes. Perkins, Johnson, Myles Expires 22 March 1995 [Page 8] Internet Draft Mobility Support in IPv6 22 September 1994 8. Compatibility with ICMP When sending a packet to a mobile node, it is important to correctly return to the original sender any ICMP error messages generated by this packet. Returning the ICMP error message is complicated by the use of tunneling in sending packets to mobile nodes away from home: the ICMP error message should travel back to the original sender along the same path as the original packet, and must be in a form that makes sense to the original sender when it gets there. For example, if the original sender did not know that the mobile node is mobile, the original packet would have been routed to the mobile node's home agent, which then should have tunneled the packet to the mobile node's care-of address. If an ICMP error message were generated along the path between the home agent and the care-of address, the ICMP error message should have been returned first to the home agent, so that it could process the message and possibly attempt to recover from the error. If appropriate for the type of error, the ICMP error message should then be forwarded back to the original sender so that it may also process the error. Since the home agent added the tunneling to the original packet, it should remove this from the copy of the returned packet in the ICMP error message before returning it to the original sender. In IPv4, this handling of returned ICMP error messages was complicated by the definition of the ICMP protocol. Originally, ICMP was specified to return only the first 8 data octet of the packet in error, and even though this has been changed in the current ``Host Requirements'' RFC to specify the return of AT LEAST the first 8 octets, many implementations still return only 8 octets. The problem is that no matter how tunneling is encoded in the packet to the mobile node, returning only 8 data octets form the packet cannot return both the tunneling information and a portion of the original data of the packet. ICMP for SIPP has been specified to return as much of the original packet as will fit in the ICMP error message without the ICMP packet exceeding 576 octets. This size should be sufficient for correctly returning ICMP error messages backwards along the tunnel, as long as the original sender does not expect to get this full size returned. Since the tunneling information is removed from the original packet by the home agent, the length of the ICMP packet will in this case be less than 576 octets, and correspondingly less of the original packet will be returned in the ICMP error message. Perkins, Johnson, Myles Expires 22 March 1995 [Page 9] Internet Draft Mobility Support in IPv6 22 September 1994 9. Addressing the Home Agent It is useful to be able to send a packet to a mobile node's home agent without explicitly knowing the home agent's address. For example, a mobile node must communicate with its home agent to send it a binding update; but since the mobile node was last at home, it may have become necessary to replace the node serving as its home agent due to the failure of the original node or due to reconfiguration of the home network. It thus may not always be possible or convenient for a mobile node to know the exact address of its own home agent. In IPv4, one method for accomplishing this addressing is for the mobile node to use the directed broadcast address for its home IP subnet. When the packet reaches the nearest router onto the home network, a copy will be broadcast onto the local subnet, thus reaching the home agent, although all other nodes on the home network will also receive a copy of the packet and must ignore it. In the current SIPP specification, no directed broadcast technique seems to be available. The cluster addresses proposed in SIPP provide a similar functionality, but are restricted to addressing only the nearest of those routers at the boundary of a cluster of nodes identified by a common routing prefix. The home agent, though, may not be the nearest boundary router or may not be a boundary router at all. We suggest here two possible mechanisms to provide the needed addressing capabilities. One possibility would be to define an additional type of address similar to SIPP's current cluster addresses, in which all bits after the cluster prefix are set to 1 (rather than 0 as in the current cluster addresses); such an address could be interpreted by the cluster boundary routers to mean that the packet should be multicast into the cluster to the ``all routers'' multicast address. A further possibility, given the large address space size in IPv6, would be to extend this addressing mechanism to provide some form of ``directed multicast'' addressing capability. A range of local addresses could be reserved for use by multicast, such that any of these local addresses can be encoded with any network (or subnet) routing prefix. This technique could be used to target only the home agents on the home network rather than all routers, and may also be generally useful within the Internet for providing other services as well. Perkins, Johnson, Myles Expires 22 March 1995 [Page 10] Internet Draft Mobility Support in IPv6 22 September 1994 10. Appendix A: Delivery of Packets by Source Routing As previously noted, when a correspondent node wishes to send a packet to a mobile node, and the correspondent has received (in an extension header of a previous packet) a binding update for that mobile node, the packet can be sent directly to the mobile node's current location. Instead of encapsulation, some form of source routing header could be used for this purpose; a source route header uses much less space than encapsulation with a full IPv6 header. The current SIPP specification allows source routing headers to be added to a packet only at its original sender, and thus only encapsulation may be used by home agents for forwarding packets they have intercepted for a mobile node. If used at all, source routes could only be used by correspondent nodes. A variant of the standard source route header would also need to be defined for use (by correspondent nodes) in sending packets to a mobile node, in order to avoid requiring the mobile node to reverse and save the route. There is no need for the mobile node to use a source route header for any return packets that it sends to the correspondent node (unless the correspondent node is also mobile); it can send packets directly to the rest of the Internet just by using its current foreign agent as its default router. Although reversing the source route obtained from a correspondent node would work, it would unnecessarily add to the length of the mobile node's outgoing packets. As noted above, this is often an important consideration when the link between the foreign agent and the mobile node is a wireless link with limited bandwidth available. Perkins, Johnson, Myles Expires 22 March 1995 [Page 11] Internet Draft Mobility Support in IPv6 22 September 1994 Authors' Addresses Charles Perkins Room J1-A25 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Work: +1 914 789-7350 Fax: +1 914 784-7007 E-mail: perk@watson.ibm.com David B. Johnson Computer Science Department Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213-3891 Work: +1 412 268-7399 Fax: +1 412 268-5576 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 Perkins, Johnson, Myles Expires 22 March 1995 [Page 12]