IPv6 Working Group Charles Perkins INTERNET DRAFT IBM Corporation David B. Johnson Carnegie Mellon University 8 July 1995 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 correspondent nodes, and its nearest router. 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 and individuals 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 Expires 8 January 1996 [Page i] Internet Draft Mobility Support in IPv6 8 July 1995 1. Introduction A new version of the Internet Protocol, IPv6, is being developed with 128-bit addresses, which remedies many perceived flaws with the existing version (that is, IPv4). This document draws on the experiences of the authors 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 [4]. 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 [4]. However, the development of IPv6 presents a rare opportunity, in that there is no existing installed base of IPv6 hosts or routers with which we must be compatible, and in that the design of IPv6 may still be adjusted to account for the few special needs of mobile nodes. This draft, therefore, considers how IPv6 can most naturally fulfill the support requirements for mobile nodes. 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. In this document, we will first specify the way that the mobile node can send notifications about its current whereabouts, using mostly existing mechanisms available already in IPv6. Then we describe the mechanism by which a routing header can be used to deliver packets to the mobile node at its current whereabouts. We suppose that all IPv6 nodes and routers can support the operations required for mobility, since the additional overhead of doing so is not very high. This leads to dramatic simplifications in the required protocols. In this proposal, we preserve features analogous to all of the features available to mobile nodes using the IPv4 mobile-IP protocol. Perkins, Johnson Expires 8 January 1996 [Page 1] Internet Draft Mobility Support in IPv6 8 July 1995 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, care-of address, and binding. Accordingly, mobile computers will use (at least) two IPv6 addresses whenever they are roaming away from their home network. One is permanent; 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 present on its home network, packets arriving for it there will be intercepted by the home agent, and tunneled to a care-of address. In the configurations described first in this document, the mobile node can itself receive packets addressed to the care-of address. Alternatively, a router will receive the tunneled packets, and deliver them directly to the mobile node. Generally, mobile nodes will select one or more of the available care-of addresses, possibly by collecting offers of service from routers in the area, and make sure the home agent is aware of its 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. The method by which care-of addresses can be discovered will depend on the final form the Neighbor Discovery Protocol [7] for IPv6. The packets are preferentially delivered to mobile nodes by using routing headers instead of encapsulation. 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 specify that all IPv6 nodes be capable of caching the location of mobile nodes with which they want to communicate, and recommend 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. Routing packets directly to the mobile node also eliminates congestion at the home agent Perkins, Johnson Expires 8 January 1996 [Page 2] Internet Draft Mobility Support in IPv6 8 July 1995 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 required 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. Binding updates should be considered a form of routing updates; thus, handled incorrectly, they could be a source of security problems and routing loops. We assume that in the deployed IPv6 systems there will be access to suitable authentication mechanisms which can authenticate binding updates. Perkins, Johnson Expires 8 January 1996 [Page 3] Internet Draft Mobility Support in IPv6 8 July 1995 3.1. Binding Update Option Format We introduce a new IPv6 destination option by which a mobile node can transmit a binding update to another IPv6 node. A mobile node uses the Binding Update option to notify another node of its current care-of address. 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 is encoded as an option within the destination extension header. This 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 or IPv6. By encoding the binding update in this way, it can be included in any normal data packet or can be sent in a separate packet containing no data. The binding update should contain the mobile node's care-of address, an identification for the binding (to protect against attempts to replay the update), and possibly a lifetime for the binding. Note that the binding update is functionally similar to the previously suggested [9] "Remote Redirect", which was intended to facilitate the dissemination of mobility bindings to those correspondent hosts that need them. This option format is adapted from that suggested in the IPv4 route optimization proposal [6]. Note that the home address is required to be the source address of IPv6 packet containing the binding update, and thus is not required to be located within the data of the destination option. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|C|I|S|E|B| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Care-of Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 8-bit identifier of the type of option. The first three bits of the option are 000, indicating first that a node receiving Perkins, Johnson Expires 8 January 1996 [Page 4] Internet Draft Mobility Support in IPv6 8 July 1995 the option may discard the option and still process the rest of the packet, and second that the option may not be modified enroute. Option Length 8-bit unsigned integer. Length of the Option Data field of this option, in octets. Acknowledge (A) The Acknowledge (A) bit is set by a node if it wants a a Binding Acknowledge message to be returned upon receipt of the Binding Update Option. Co-location (C) The mobile node is itself the agent receiving datagrams at the care-of address. Identification Present (I) The (I) bit is set by the node sending the Binding Update option to indicate whether or not the Identification field is present. Simultaneous (S) The (S) bit is set by the mobile node if it wishes the receiver to maintain multiple simultaneous bindings for the mobile node. Encapsulation (E) The (E) bit is set by the mobile node to request that the receiving agent send encapsulated packets to the mobile node, instead of packets containing the care-of address in a routing header. Broadcast (B) The (B) bit is set by the mobile node to request that the home agent encapsulate and send broadcast packets to the mobile node at its care-of address. The (B) bit must only be used when sending binding updates to the home agent. Reserved Sent as 0; ignored on reception. Perkins, Johnson Expires 8 January 1996 [Page 5] Internet Draft Mobility Support in IPv6 8 July 1995 Lifetime The number of seconds remaining before the location cache entry must be considered expired. A value of all ones indicates infinity. A value of zero indicates that the indicated location cache entry (or route table entry, in the case of a mobile node's previous router) for the mobile node should be deleted. The lifetime is typically equal to the remaining lifetime of the mobile node's binding with its care-of address. Care-of Address The current care-of address of the mobile node. When set equal to the home address of the mobile node, the Binding Update option instead indicates that no location cache entry for the mobile node should be created, and any existing location cache entry (and route table entry, in the case of a mobile node's previous router) for the mobile node should be deleted. Identification If present, a 64-bit number, used to assist in matching acknowledgements with binding updates, and in protecting against replay attacks. The receiver of this message must be able to tell, say by employing whatever means adopted by the IPv6 working group for authenticating network-layer packets [1], that the mobile node is truly the agent which has generated the binding update. Perkins, Johnson Expires 8 January 1996 [Page 6] Internet Draft Mobility Support in IPv6 8 July 1995 4. Sending Binding Updates 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 set the (A) bit, instructing the home agent to send an acknowledgement. A binding update within an IPv6 header may also be included, when necessary, in any normal data packet sent to a correspondent node. 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 care-of address 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. However, if the mobile node wants to be sure, an acknowledgment can be requested. The binding update can also be sent in an otherwise empty packet whenever the mobile node wishes to update its correspondents. This would only be done if the mobile node suspects that its home agent is not operational, too far away, or that there may be an immediate need for the correspondent node to obtain the location information. An IPv6 authentication header must be used so that the recipient can be assured that the routing information is authentic. 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. Finally, some consideration should be made for the continued existence of IPv4 correspondent nodes, which are less likely to cache bindings. 5. Binding Acknowledgement Message A Binding Acknowledge message is used to acknowledge receipt of a Binding Update (section 3.1) option, if that option has the Acknowledge (A) bit set. Perkins, Johnson Expires 8 January 1996 [Page 7] Internet Draft Mobility Support in IPv6 8 July 1995 Since the Binding Acknowledgement is mostly used by home agents and is not associated with any transmission of data packets, it is specified here as an informational ICMP message to the mobile node. However, all of the error conditions specified in the Registration Reply message of the IPv4 mobile-IP protocol may apply, so the general format and codes of that message are adapted here to fit the ICMP packet layout for IPv6 [2]. Nodes should send Binding Acknowledgement messages addressed to the mobile node originating the Binding Update, and if necessary use a routing header (routing type 0) containing the care-of address given in the Binding Update. The acknowledgement message contains the necessary codes to inform the mobile node about the status of its binding. Additionally, the home agent MAY shorten the lifetime to be smaller than indicated in the original binding update. When the lifetime of the reply is greater than what was contained in the binding update, the excess time MUST be ignored. When the lifetime of the reply is smaller than the original request, another binding update SHOULD be sent before the lifetime expires. If the mobile node is using a care-of address offered by a local router, the acknowledgement from the home agent will be sent to that care-of address and (presumably) relayed to the mobile node. Routers offering care-of addresses match incoming acknowledgements with previous routing entries by using the Identification field supplied with the binding acknowledgment. The ICMP packet is organized as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (provisionally) 192 Code One of the following codes: 0 service will be provided Perkins, Johnson Expires 8 January 1996 [Page 8] Internet Draft Mobility Support in IPv6 8 July 1995 1 service will be provided; simultaneous mobility bindings unsupported Service denied by the owner of the care-of address: 16 reason unspecified 17 administratively prohibited 18 insufficient resources 19 mobile node failed authentication 20 home agent failed authentication 21 requested lifetime too long 22 home agent unreachable (ICMP error) 23 poorly formed binding update 24 poorly formed binding acknowledgement Service denied by the home agent: 32 reason unspecified 33 administratively prohibited 34 insufficient resources 35 mobile node failed authentication 36 agent at care-of address failed authentication 37 identification mismatch 38 poorly formed binding update 39 too many simultaneous mobility bindings Lifetime The seconds remaining before the binding is considered expired. A value of zero confirms a request for removal of a binding. A value of all ones indicates infinity. Identification The acknowledgment identification is derived from the binding update message, for use by the mobile node in matching the acknowledgment with an outstanding update. 6. Delivering Packets to a Mobile Node 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. Since the mobile node's location is known on the home network (namely, by the home agent), 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. Perkins, Johnson Expires 8 January 1996 [Page 9] Internet Draft Mobility Support in IPv6 8 July 1995 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 the organization's own network. Correspondent nodes that have received a binding update for a mobile node, can send packets directly to that mobile node's current care-of address. There is already a routing header defined within the current IPv6 specification which is well-suited for this purpose, the routing header (routing type 0). To use the routing header for delivery of packets to a mobile node, a correspondent host just specifies the care-of address as the intermediate routing point and the mobile node as the (final) destination. When the packet arrives at the care-of address, normal processing of the routing header will ensure delivery to the mobile node. The IPv6 routing header avoids the unfortunate semantics of the IPv4 loose source routing option which made it unsuitable for use with IPv4 mobility. In particular, it is fortunate that IPv6 routing headers do not carry the semantics which require reversal of source routes. Since the reversed source route will not be used by the mobile node, no additional security risks are introduced by using routing headers to deliver packets via the care-of address. There is only one possible advantage afforded by the use of encapsulation, compared to the use of the existing routing header defined for IPv6. That only occurs when a mobile node uses a care-of address associated with a nearby router. If a mobile node has a link to a router over a low speed wireless link, and the router receives encapsulated packets for the mobile node, the encapsulation is stripped away before final delivery is made to the mobile node. In that case, fewer bytes are transmitted over the low-speed link, than would be the case for a normally processed routing header specifying the address of the nearby router (see also section 11.1). Home agents are often unable to use routing headers to deliver packets to the mobile node, because they can't modify the packet and add to it in flight; therefore, we specify that they must always use encapsulation [8] for this purpose(section 9). It is unknown at this time whether there is sufficient reason to allow the use of alternative encapsulation protocols other than IPv6-within-IPv6, as is done in the mobile-IP specification for IPv4. If a packet to the mobile node is encapsulated, it uses the care-of address as the destination address in the outer IPv6 header. Then, when the the encapsulated packet arrives at the care-of address, the encapsulation is stripped away and the packet delivered (if possible) to the mobile node. Of course, if the mobile node is Perkins, Johnson Expires 8 January 1996 [Page 10] Internet Draft Mobility Support in IPv6 8 July 1995 itself receiving packets addressed to the care-of address, the delivery path is trivial. In that case, however, it is more likely that the packet would have been delivered using the care-of address and a routing header. 6.1. Smooth Handoffs As the mobile node moves from one place to another, in the case of wireless communications with the existing local area networks, it is probable that the mobile node will often reside within range of multiple wireless network points of attachment. If the mobile node obtains a new care-of address while it is still within range for delivery of packets to its old care-of address, then it is reasonable to expect that movement from one care-of address to the next can occur without dropping any packets. It is likely that, when a mobile node obtains a new care-of address from an address allocation authority, it would explicitly deallocate the previous care-of address. For smooth handoffs, we specify that the mobile client must still accept packets at both addresses for a short time after configuring its newly allocated IPv6 address. If the previous address were allocated by a stateful address server, then the mobile client must not release the address immediately upon acquisition of a new care-of address, and the stateful address server must allow mobile clients to acquire multiple addresses. 7. Foreign Agents 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 associated with a router neighboring the mobile node, or the network being visited by the mobile node, so that the normal routing of the Internet will deliver the packet to the appropriate network. The care-of address may either be the address of a foreign agent in that network, or may be a temporary local address obtained by means such as DHCP [3]. One reason for favoring 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 Perkins, Johnson Expires 8 January 1996 [Page 11] Internet Draft Mobility Support in IPv6 8 July 1995 obtain a new care-of address each time it enters a new area of mobile services. In this section, we outline the advantages afforded by the use of care-of addresses associated with routers nearby the mobile node, and modifications to the previously outlined methods which are made necessary when a mobile node wishes to use such care-of addresses. 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, it may be required to: - authenticate the identity of mobile clients - charge for connection services - produce or share a session key for use by new mobile clients (say, for encryption) - negotiate a compression algorithm - manage the resources of router's 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; this may depend on the form of neighbor discovery finally adopted by the IPv6 working group. The actual protocol actions performed in response to the extensions would be carried out at layers above IPv6 (e.g., UDP). For instance, if a router 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 router's requirement by responding with the appropriate protocol operations (which are undefined here). Note that if the router 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 services, then surely authentication will be needed. In addition, if billing is managed by the routers, then the billing agent should append a billing extension to its 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 router to effect the financial transactions. Similarly, encryption and/or compression Perkins, Johnson Expires 8 January 1996 [Page 12] Internet Draft Mobility Support in IPv6 8 July 1995 services might be advertised by extensions to the basic service advertisements. A nearby router can provide services to mobile nodes without requiring any registration transactions. It is also suggested that service advertisement messages issued by the router contain an indication whether 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. Otherwise, if a mobile node receives a broadcast or multicast advertisement for service that the router is not really equipped to provide, then the router might have to reject attempts by that mobile node to transmit data through its interfaces. The router could do that by sending an ICMP 'Resource Unavailable' message back to the mobile node. 7.1. Sending a Binding Update via a Foreign Agent When a mobile node is attached to the network via a foreign agent, it is no longer possible to send binding updates directly to its home agent. The mobile node can still send the update to its home agent, through the foreign agent, by using a routing header and inserting the foreign agent as an intermediate router. In this case, however, the foreign agent has to remember that the mobile node, using its home address, is its neighbor. Otherwise, the foreign agent would not know how to deliver packets after decapsulation, or packets sent to the home address using the foreign agent's care-of address in a routing header. The foreign agent will already know the mobile node by the mobile node's local-use only address, and by the mobile node's globally routable or site-local address which was obtained from the Neighbor Discovery protocol, but those two addresses are logically different than the mobile node's home address. We can insure this effect by by requiring the routing header used with the binding update to have a new routing type (routing type 1). With this routing type, the foreign agent will be required to transmit the expected binding acknowledgement back to the mobile node when it is received from the home agent. Another strategy for ensuring that the foreign agent will associate the mobile node by its home address is to require the mobile node to deliver its binding update to the home agent through the foreign agent using encapsulation. The encapsulated binding update could itself have another binding update destination option, or some more economical means can be devised. Perkins, Johnson Expires 8 January 1996 [Page 13] Internet Draft Mobility Support in IPv6 8 July 1995 7.2. Smooth Handoffs between Routers 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 router to another one simply by sending a binding update to its previous router. This binding update must be acknowledged by the previous router. Then, the router (acting as a cache agent) can forward packets to the new router for direct delivery to the mobile node. If a packet arrives at the previous router for the mobile node, the previous router encapsulates the packet and delivers it to the new router. If the previous router 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 and the address of the mobile node as the destination address. It is suggested that mobile nodes continue to receive packets at previous care-of addresses for as long as physically possible. This can be done with care-of addresses obtained by automatic or dynamic address configuration as well as those associated with routers. If wireless communications are continuously available in overlapping service areas, then mobile computers using such devices could thus reasonably expect to move between routers without dropping any packets. 8. After Decapsulating After the router 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 perhaps the cleanest technique is for the router to re-encapsulate the packet (using essentially the same encapsulation protocol) before transmitting the packet to the mobile node. The extra transmission time from the router 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. Re-encapsulation will be even rarer if the mobile node does a good job of including binding updates in the data packets it sends to its correspondent nodes. Note that, for implementation, no copying need occur for this operation; the encapsulating router may just replace the source address in the encapsulating header, and make other minor adjustments like resetting the hop limit, or the flow label. Perkins, Johnson Expires 8 January 1996 [Page 14] Internet Draft Mobility Support in IPv6 8 July 1995 A mobile node receiving such an encapsulated packet will send the correspondent node a binding update. Thus, the mobile node can quickly inform the correspondent node of its current care-of address, and the home agent will be relied upon for only a small percentage of the overall data traffic destined for the mobile node. Routers would only rarely have to perform this reencapsulation 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 (say, with the help of its router) that the first attempt probably failed. Since the mobile host sends binding updates to its active correspondents soon after entering the service area of a new router, any delays due to stale or nonexistent location caches at correspondent nodes will be short-lived. Just as a mobile node should avoid sending a rush of binding updates to its correspondent hosts when it migrates to a new care-of address, it would be advantageous if any nearby router could avoid sending a rush of advisory encapsulations to any of its newly acquired mobile clients. 9. Home Agent Considerations When the home agent receives a packet for the mobile node, it encapsulates the packet and delivers it to the mobile node. Methods by which the home agent could insert a routing header, or modify the destination address of the mobile node, may be unavailable because of the expected prevalence and operation of IPv6 authentication mechanisms [1]. If the home agent receives such an encapsulated packet for the mobile node, it decapsulates and re-encapsulates the packet (some optimization may be available here) for delivery to the mobile node's new care-of address. In this situation, the home agent must check that it is not trying to deliver the packet back to the same care-of address from which it came; otherwise, routing loops might develop. If the home agent determines that it does not have a valid binding for the mobile node, it may deliver the unencapsulated packet onto the home network, and should discontinue any proxy ARP operations it may be performing for the mobile node. 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 Perkins, Johnson Expires 8 January 1996 [Page 15] Internet Draft Mobility Support in IPv6 8 July 1995 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 is for the mobile node to use the directed broadcast address for its home IP subnet. When the packet reaches the nearest router on 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. Then, any home agent on the home network which chooses to respond will inform the mobile node of its address, and the mobile node can subsequently perform the IPv4 registration procedure with the newly discovered home agent address. In the current IPv6 specification [5], no directed broadcast technique is available. The anycast addresses proposed in IPv6 provide a similar functionality, but are restricted to addressing only the nearest of those routers at the boundary of those 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. Since all routers on the home network are assumed to process binding updates, we can be assured at least that any binding update sent to the anycast address will be processed correctly. Other routers on the home network must be instructed to forward packets to the current router which is serving as the mobile node's home agent. This can be done using the same proxy mechanisms already made available in Neighbor Discovery. The current home agent multicasts the equivalent of a Proxy ARP onto the home network, and subsequently the other routers on the home network will forward packets destined to the mobile node to the particular router which is serving as the home agent for that mobile node. 10. 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. Since in most cases such packets use a routing header containing the care-of address, this is usually not a problem. However, when a packet encapsulated at the home agent encounters such an error condition, returning the ICMP error message to mobile nodes away from home is more complicated: the ICMP error message should travel back to the original sender along the same path as Perkins, Johnson Expires 8 January 1996 [Page 16] Internet Draft Mobility Support in IPv6 8 July 1995 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 octets 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 IP version 6 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 [2]. 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. 11. Summary In this protocol document, we have proposed a departure from the mobile-IP protocol for IPv4 in several important ways: - We propose the use of routing headers instead of encapsulation for common traffic destined to a mobile node, since the problems with loose source routing in IPv4 are no longer present in IPv6 Perkins, Johnson Expires 8 January 1996 [Page 17] Internet Draft Mobility Support in IPv6 8 July 1995 - We build upon the commonality between IPv4 registration and route optimization protocols to permit a cleaner and smaller mechanism for accomplishing the same things - We emphasize the need for distributing bindings to the entities that need them, in order to reduce drastically the role of the home agent in handling traffic destined for the mobile node - We build on the expected capability for mobile nodes to receive datagrams at several IPv6 addresses, to suggest the reduced need for external care-of addresses in some common circumstances. - We specify that all IPv6 routers and nodes accept binding updates, and thus that all IPv6 routers be able to operate as home agents, affording major simplifications and optimization at reasonable implementation cost. 11.1. Open issues The common use of binding updates as Destination Options is architecturally very clean, but the IPv4 registration request has a more extensible mechanism for adding future functionality via Mobility Extensions. If the need for additional flexibility becomes important soon enough to affect this specification, then we will suggest a return to the IPv4 registration requests and replies for delivering binding updates to the home agents. When a mobile node migrates away from an area in which it had its own care-of address, there won't be any way for "straggling packets" to be redirected back to the home agent, or to the new care-of address for the mobile nodes. This probably isn't any worse than IPv4 traffic delivery anyway, as far as we know now. Nevertheless, mobile nodes can alleviate this problem if the areas of service overlap sufficiently, and they continue to receive packets at their previous care-of address. How important is it to save such straggling packets? Should we emphasize the need to overlap service areas, or build additional protocol requirements to minimize the problems resulting from non-overlapped service? Should alternative encapsulation techniques be defined for use with these protocols? Should a minimal encapsulation be defined and specified as the default? Perhaps this would be better taken care of by defining something like TCP header compression over the link from the router to the mobile node. Another alternative would be to provide another type of routing header (routing type == 2, say) which would allow an intermediate Perkins, Johnson Expires 8 January 1996 [Page 18] Internet Draft Mobility Support in IPv6 8 July 1995 node to delete itself from the list instead of just rearranging the list. This would completely eliminate the need for encapsulation for normal datagrams from correspondent host to mobile node. In the IPv4 route optimization proposal, a mechanism is outlined whereby a session key can be established between foreign agents and mobile clients, without requiring any pre-established security relationship between them. It could very well be the case that a similar mechanism should be defined for IPv6, to avoid the need for a possibly time-consuming negotiation between routers and mobile nodes for the purpose of obtaining the session key, which under many circumstances would only be used once. Perkins, Johnson Expires 8 January 1996 [Page 19] Internet Draft Mobility Support in IPv6 8 July 1995 References [1] R. Atkinson. IPv6 Authentication Header. draft-atkinson-ipng-auth-02.txt, work in progress, June 1995. [2] A. Conta and S. Deering. ICMP for the Internet Protocol Version 6 (IPv6). draft-ietf-ipngwg-icmp-02.txt -- work in progress, June 1995. [3] R. Droms. Dynamic Host Configuration Protocol. RFC 1541, October 1993. [4] IETF Mobile-IP Working Group. IPv4 Mobility Support. ietf-draft-mobileip-protocol-10.txt -- work in progress, May 1995. [5] Bob Hinden. Internet Protocol, Version 6 (IPv6) Specification. Internet draft -- work in progress, October 1994. [6] David B. Johnson and Charles E. Perkins. Route Optimization in Mobile-IP. Internet Draft -- work in progress, January 1995. [7] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor Discovery. draft-ietf-ipngwg-discovery-00.txt -- work in progress, June 1995. [8] C. Perkins. IPv6 Mobility Support. draft-perkins-mobility-ipv6-00.txt -- work in progress, May 1995. [9] Bill Simpson. IPv6 Neighbor Discover -- ICMP Message Formats. draft-simpson-ipv6-discov-formats-01.txt -- work in progress, November 1994. Perkins, Johnson Expires 8 January 1996 [Page 20] Internet Draft Mobility Support in IPv6 8 July 1995 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 Perkins, Johnson Expires 8 January 1996 [Page 21]