HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 10:48:09 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 09 Jun 1995 22:00:00 GMT ETag: "361e4e-ca30-2fd8c460" Accept-Ranges: bytes Content-Length: 51760 Connection: close Content-Type: text/plain IPv6 Working Group Charles Perkins INTERNET DRAFT IBM Corporation David B. Johnson Carnegie Mellon University 8 June 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 the foreign agent. 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 December 1995 [Page i] Internet Draft Mobility Support in IPv6 8 June 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. Afterwards, we describe how the basic system can be modified to include the intermediate delivery agents called foreign agents in IPv4. 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 December 1995 [Page 1] Internet Draft Mobility Support in IPv6 8 June 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 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 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 foreign agent 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 foreign agents in the area, 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. 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 December 1995 [Page 2] Internet Draft Mobility Support in IPv6 8 June 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 December 1995 [Page 3] Internet Draft Mobility Support in IPv6 8 June 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 this form of 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 December 1995 [Page 4] Internet Draft Mobility Support in IPv6 8 June 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 December 1995 [Page 5] Internet Draft Mobility Support in IPv6 8 June 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 foreign agent) 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 foreign agent) 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 December 1995 [Page 6] Internet Draft Mobility Support in IPv6 8 June 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 expected 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 Acknowledment Message A Binding Acknowledge message is used to acknowledge receipt of a Binding Update (section 3.1) message. It is sent by a node receiving Perkins, Johnson Expires 8 December 1995 [Page 7] Internet Draft Mobility Support in IPv6 8 June 1995 the Binding Update option, if it has Acknowledge (A) bit is set in the Binding Update option. 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 accepting service from a foreign agent, that foreign agent will receive the acknowledgement from the home agent and subsequently relay it to the mobile node. The foreign agent matches 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) 134 Code One of the following codes: Perkins, Johnson Expires 8 December 1995 [Page 8] Internet Draft Mobility Support in IPv6 8 June 1995 0 service will be provided 1 service will be provided; simultaneous mobility bindings unsupported Service denied by the foreign agent: 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 foreign agent 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 December 1995 [Page 9] Internet Draft Mobility Support in IPv6 8 June 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 that mobile node, can send packets directly to the 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 foreign agent. If a mobile node has a link to a foreign agent over a low speed wireless link, and the foreign agent 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 care-of address of the foreign agent (see also section 12.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] to deliver packets to the mobile node(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 Perkins, Johnson Expires 8 December 1995 [Page 10] Internet Draft Mobility Support in IPv6 8 June 1995 possible) to the mobile node. Of course, if the mobile node is 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 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 [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 Perkins, Johnson Expires 8 December 1995 [Page 11] Internet Draft Mobility Support in IPv6 8 June 1995 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. In this section, we outline the advantages afforded by the use of foreign agents, and the modifications to the previously outlined methods which are made necessary when a mobile node wishes to use the services of the foreign agent. 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 (say, for encryption) - 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; 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 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 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 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 foreign agent to effect the financial transactions. Perkins, Johnson Expires 8 December 1995 [Page 12] Internet Draft Mobility Support in IPv6 8 June 1995 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. 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 is its neighbor. This may already be taken care of by the use of the Neighbor Discovery protocol. If not, then we can get the same effect 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. 7.2. Smooth Handoffs between Foreign Agents 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 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 Perkins, Johnson Expires 8 December 1995 [Page 13] Internet Draft Mobility Support in IPv6 8 June 1995 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 and the address of the mobile node as the destination address. 8. After Decapsulating 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 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 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. This re-encapsulation by the foreign agent 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, the no copying need occur for this operation; the foreign agent may just replace the source address in the encapsulating header, and make other minor adjustments like resetting the hop limit, or the flow label. When the mobile node receives such an encapsulated packet, it will likely determine that the correspondent node requires a binding update. Thus, the mobile node can quickly inform the correspondent node about 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 (say, by getting the hint from its foreign agent) 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 foreign Perkins, Johnson Expires 8 December 1995 [Page 14] Internet Draft Mobility Support in IPv6 8 June 1995 agent, 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 the foreign agent could avoid sending a rush of advice 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, are not always available because of the expected prevalance 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 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. 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 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 Perkins, Johnson Expires 8 December 1995 [Page 15] Internet Draft Mobility Support in IPv6 8 June 1995 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 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. 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 Perkins, Johnson Expires 8 December 1995 [Page 16] Internet Draft Mobility Support in IPv6 8 June 1995 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 seems to be 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. We suggest here several possible mechanisms to provide the needed addressing capabilities. The first, and best, would be for home networks to configure their boundary routers as home agents. This is reasonable, since a home network offering services to mobile clients already has to be administered in IPv6 to provide security and other features. Another possibility would be to define an additional type of address similar to IPv6's current anycast addresses, in which all bits after the routing prefix are set to 1 (rather than 0 as in the current prefixes); such an address could be interpreted by the boundary routers to mean that the packet should be multicast 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. 12. 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 - We build upon the commonality between IPv4 registration and route optimization protocols to permit a cleaner and smaller mechanism for accomplishing the same things Perkins, Johnson Expires 8 December 1995 [Page 17] Internet Draft Mobility Support in IPv6 8 June 1995 - 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 foreign agents in some common circumstances. 12.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 mobile nodes migrate from an area in which there was no foreign agent delivering packets to the mobile node, 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 we emphasize the need for foreign agents? One possibility would be to place additional requirements on border routers, so that mobile nodes could rely on them to forward packets to a new care-of address when they move. This would open the way to additional generality and flexibility in the specification, since then effectively every IPv6 router could perform the rather minimal functions still required of home agents and foreign agents. In view of the role played by routing headers in directing traffic towards mobile nodes, most of the extra work for mobility lies only in distributing and authenticating the mobility bindings needed by correspondent hosts to build the correct routing headers. 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 foreign agent to the mobile node. Perkins, Johnson Expires 8 December 1995 [Page 18] Internet Draft Mobility Support in IPv6 8 June 1995 Another alternative would be to provide another type of routing header (routing type == 2, say) which would allow an intermediate 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 the foreign agent and mobile node for the purpose of obtaining the session key, which under many circumstances will only be used once. Perkins, Johnson Expires 8 December 1995 [Page 19] Internet Draft Mobility Support in IPv6 8 June 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 . draft-ietf-ipngwg-ipv6-spec-01.txt -- work in progress, March 1995. [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 no longer in progress, November 1994. Perkins, Johnson Expires 8 December 1995 [Page 20] Internet Draft Mobility Support in IPv6 8 June 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 December 1995 [Page 21]