Yakov Rekhter T.J. Watson Research Center, IBM Corp. Charles Perkins T.J. Watson Research Center, IBM Corp. Optimal routing for mobile hosts using IP's Loose Source Route option. Abstract This memo describes an approach to transparent mobile internetworking, meaning that unchanged hosts can move among networks in a fashion transparent to protocols above IP, while at the same time providing steady state optimal routing between either a pair of moving hosts or between a moving host and a stationary host. The approach rests upon the existence of a limited set of entities, called Base Access Stations (MAS) and Mobile Routers (MR) that coordinate forwarding among mobile hosts (MH). Status of this Memo This document describes an approach to transparent mobile internetworking. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this document is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". This document expires in January 1993. Please respond with comments to mobile-ip@parc.xerox.com. Security Considerations Security issues are not discussed in this memo. 1 Introduction The goal of this work is to permit a host to move around a network, transparently to layers above IP. Transparent means that switching networks might produce a pause, but no other observable effect. For a presentation of motivation, design choices, and evaluation, see [2], [4]. For the approach to be practical, the following goals must be met: - No changes are required to non-mobile hosts, even if these hosts communicate with mobile hosts. - No changes are required to the software of routers that do not share a common Level 2 subnetwork with one or more mobile hosts. Thus, most of the routers in the Internet should be unaffected, even if they are involved in forwarding IP packets to/from mobile hosts. - A mobile host retains its IP address while moving. - Routing optimality should not be affected by the fact that the IP address retained by a mobile host may not bear any direct information about the actual location of the mobile host (i.e, topology information). - No changes are required to networking software of mobile hosts at layers above the network layer. Our approach is to view the world as a set of Level 2 subnetworks interconnected together by Level 3 (Network Layer) routers. In contrast with [2] our approach places no distinction between intra-domain (intra-campus) and inter-domain (inter-campus) mobility. The proposed scheme works with either unidirectional or bidirectional traffic between hosts. Since most of the traffic between a pair of computers is bidirectional, the scheme is optimized for bidirectional traffic. 1.1 Basic components This approach to the optimal routing rests on three bases, and involves three distinct entities: Mobile Hosts (MH), Mobile Routers (MR), and Base Stations (MAS). 1.1.1 Mobile Hosts The first basis is that each mobile host (MH) has an IP address that does not change during the lifetime of any reliable data connections ("virtual circuits"). This address provides an association between an MH and a Mobile Router (MR). 1.1.2 Base Stations The second basis is the presence of a limited set of entities, called Base Access Stations (MAS). Each MAS must have at least one interface on a "regular" level 2 subnetwork (e.g. Ethernet), and at least one interface on a Level 2 subnetwork that supports mobility (e.g. infrared, RF). Each such Level 2 subnetwork forms a cell. A cell is a link-layer concept. A range over which a wireless interface attached to a MAS can be reached determines the boundaries of the cell. A MAS may serve multiple cells, for instance if it has multiple adapters supporting "wireless" interfaces. Cells may overlap. A MAS may support host mobility on other than "wireless" interfaces (e.g. Ethernet). In this case cell's boundaries are determined by the Level 2 subnetwork over which mobility is supported (e.g. Ethernet). A MAS acts as an IP router. Each MH is served by exactly one MAS. For a MAS to serve an MH means, first, that the MAS and the MH are located within the same cell (have common Level 2 subnetwork), second, that the MAS acts as the MH's default gateway and, third, that packets from outside the cell are sent through the MAS, which forwards them across the cell to the MH. In other words, from the Network Layer Routing point of view the MAS that serves an MH acts as the first hop for packets outgoing from the MH IP (destined to hosts outside the cell), and as the last hop for packets incoming to the MH IP (coming from hosts outside the cell). A MAS is required to keep track of the IP addresses of the MHs within its cell. Likewise, an MH is required to keep track of at least one IP address of a MAS reachable over a single Level 2 subnetwork (cells may overlap). 1.1.3 Mobile Routers The third basis is the presence of a limited set of entities, called Mobile Routers (MR). Each MR has a range of IP addresses that are designated to be assigned to interfaces attached to MHs and to which the MR claims direct network layer reachability. The advertisement of such reachability information establishes an association between an MR and an interface attached to a MH. This association is retained as long as the IP address of the MH stays the same. Each MH has a list of IP addresses of one or more of the MRs associated with the MH. A range of addresses to which different MRs claim direct reachability need not be related to each other. While conceptually a range of addresses to which a given MR claims direct reachability may consist of randomly chosen IP addresses, in practice the range is likely to consist of a small number of IP address prefixes. An MR advertises direct reachability to all the destinations indicated by these prefixes (whether or not these destinations are up or down, and regardless of whether a particular address within the prefix is assigned to an MH or is unassigned). Thus, an IP packet with no IP options destined to an MH will be forwarded to the MR associated with the MH by means of either intra- or inter-autonomous system routing (or a combination of both). In addition, for each MH associated with a given MR, the MR keeps track of the MAS that presently serves the MH. This is achieved by requiring an MH to inform the MR associated with it about the IP address of the MAS presently serving the MH. Note that despite claiming direct reachability to the associated MHs, the MR may not have single network layer hop connectivity to any of these MHs (an MR and an MH may be separated by more than one Network Layer hop). However, by associating the IP addresses of a MAS with each MH, the MR is capable of relaying IP packets destined to these MHs via the correct MASs using normal internet routing. A MAS may be colocated with an MR, or may be a separate entity. 1.1.4 Interaction between the components. Communication between two MHs within the same cell may involve the participation of at most one MAS (depending on the Level 2 subnetwork technology employed within the cell); no MR participation is required. Communication between an MH and a stationary host always involves participation of exactly one MAS, as long as the MH is not moving; at most one MR may be involved, but even if involved the MR's participation is likely to be sporadic. Communication between two MHs in different cells always involves participation of exactly two MASs, as long as neither MH is moving. At most two MRs will be involved, but their involvement is likely to be sporadic. 2 Short-cut routing. The proposed approach utilizes the IP Loose Source Route (LSR) option. Appendix A contains excerpts from various documents related to the LSR option. 2.1 Packet Movement To/From a Mobile Host Short-cut routing is most easily introduced through examples of the four basic cases: 1. MH sends to an MH in same cell. 2. MH sends to a stationary host. 3. Stationary host sends to an MH. 4. MH sends to an MH in another cell. 2.1.1 MH to MH in Same Cell. Mechanisms to support direct MH to MH communication within a cell depend on the capabilities of the underlying Level 2 (Link) subnetwork technology used within the cell. 2.1.1.1 Direct intra-cell communication. The following discussion assumes that the Level 2 (link) subnetwork technology is capable of supporting direct MH to MH communication within a single cell. The sending MH inserts the IP address of the destination MH as the only entry in the Loose Source Route (LSR) option of its outgoing packet. The Destination Address field of the IP header in the outgoing packets is set to the IP address of the MAS serving the cell. Then the source MH sends a packet to the MAS. Since the MAS is required to keep track of all the MHs within the cell the MAS can determine whether the destination address in the packet indicates an MH within the same cell. If that is the case the MAS forwards the packet to the destination MH (see Section 2.1.6), and sends an ICMP Redirect message to the source MH. When the source MH receives the ICMP Redirect it attempts to ARP for the destination address (regardless of whether the destination address is on the same or different Level 3 network/subnetwork). As soon as the source MH receives an ARP Reply from the destination MH it starts to forward subsequent packets directly to the destination MH bypassing the MAS (note that these packets should not carry any LSR option at all). Since an MH may move out of the cell, the holding time associated with the ARP entry needs to be short enough to ensure the detection of such move. A short holding time will ensure periodic ARP probing. Other techniques may be used to ensure ARP consistency (see Section 3). Once an MH moves outside the cell the routing will be handled as described in Section 2.1.4 (MH to MH in another cell). In some implementations, it may that an MH can send out messages as it prepares to change cells. The other MHs can then listen to such messages, and would immediately purge the ARP entry (if present) associated with the MH that sent the message. 2.1.1.2 Indirect intra-cell communication If the underlying Level 2 (Link) subnetwork technology can't support direct MH to MH communication within a cell, then MHs within a cell communicate with each other via the MAS serving the cell. The cell's topology is modeled as a star with the MAS in the middle. Since communication between an MH within a cell and any other host always involves the MAS serving the cell as the first hop, the MH has to know the MAC Layer address of the MAS. This address may be ascertained in the process of MH to MAS communications (see Section 3.1). The sending MH inserts the IP address of the destination MH as the only entry in the Loose Source Route (LSR) option of its outgoing packets. The Destination Address field of the IP header in the outgoing packets is set to the IP address of the MAS serving the cell. The MAS serving the cell keeps track of all the MHs within the cell. If the destination address in a packet indicates an MH within the cell, the MAS forwards the packet directly to that MH (see Section 2.1.6) 2.1.2 MH to Stationary Host. The MH constructs the IP header of the packet by setting the Destination Address field of the header to the IP address of the MAS, and setting the Loose Source Route (LSR) option to a single entry consisting of the IP address of the stationary host (with 4 as the value of the Pointer field of the option, and 7 as the value of the Length field of the option). After that, forwarding of the packet is handled via normal internet routing. Once the packet reaches the destination host, if the destination host wants to send a packet back to the MH, it will be required to use the LSR it received from the MH in that packet (see Section 3.2.1.8 of [1]). The IP header of the packet generated by the stationary host and destined to the MH will carry the IP address of the MAS serving the MH in the Destination Address field of the header, and the IP address of the MH as the sole entry in the Route Data of the LSR option (with 4 as the value of the Pointer field of the option, and 7 as the value of the Length field of the option). Normal internet routing will deliver the packet first to the MAS, and then to the MH. Note, that there is no MR involved here. If during communication between an MH and a Stationary Host the MH moves from one cell to another, the MH is required to modify the Destination Address field of the IP header on its outgoing packets to reflect the IP address of the MAS that is presently services the MH. No modifications to the LSR option is needed. IP packets from the Stationary Host with the stale information will be forwarded to a MAS that no longer services the MH, and thus will ultimately be forwarded to the MR associated with the MH (see Section 2.1.6). Handling of IP packets by the MR is described in Section 2.1.5. 2.1.3 Stationary Host to MH. Since the MR associated with the MH claims direct network layer reachability to the range of addresses assigned to the MR (this range includes the address of the MH as well), the normal internet routing will deliver the packet to the MR associated with the MH. The MR modifies the IP header of the packet by taking the IP address specified in the Destination Address field of the header, and using it to create the LSR option consisting solely of that address (with 4 as the value of the Pointer field of the option, and 7 as the value of the Length field of the option), and placing the IP address of the MAS presently serving the MH in the Destination Address field of the header. The MR then proceeds with the normal internet routing. The packet will be delivered to the MAS presently serving the MH, and then to the MH. If the traffic is bidirectional, then packets from the MH to the Stationary Host will contain the LSR option along with the IP address of the MAS (see discussion in Section 2.1.2). That would force subsequent packets from the Stationary Host to the MH to flow directly to the MAS, bypassing the MR in the steady state. This results in the desired steady state optimal routing between the MH and the Stationary Host. As MH moves from one cell to another it modifies its outbound packets to reflect the IP address of the MAS that presently serves the MH, as described in Section 2.1.2. 2.1.4 MH to MH in Another Cell. The source MH creates a LSR option containing the IP address of the destination MH (with 4 as the value of the Pointer field of the option, and 7 as the value of the Length field of the option), and will place the IP address of the the MAS presently serving the source MH into the Destination Address field of the IP header. The packet is then forwarded to the MAS presently serving the source MH. The packet will be forwarded via normal internet forwarding to the MR associated with the destination MH. The MR modifies the IP header of the packet by appending the IP address specified in the Destination Address field of the header to the end of the LSR option, increases the value of the Length field of the option by 4, and placing the IP address of the MAS serving the destination MH into the Destination Address field of the header. Normal internet forwarding procedures will ensure that the packet will be delivered to the MAS serving the destination MH, and then to the destination MH, itself. Observe that the LSR option of the packet arriving at the destination MH contains IP addresses of two MASs -- one serving the source MH, and one serving the destination MH. If during communication between a pair of MHs one of the MHs moves from one cell to another, the MH is required to modify the Destination Address field of the IP header on its outgoing packets to reflect the IP address of the MAS that is presently services the MH. No modifications to the LSR option is needed. If the traffic is bidirectional, the destination MH will just reverse the LSR when sending packets back to the source MH. Thus, after the initial exchange of packets, all the subsequent packets will flow over optimal routes bypassing altogether MRs associated with both of the MHs. Each MH is required to modify the Destination Address field in its outgoing packets to reflect the IP address of the current MAS serving the MH. 2.1.5 Handling IP packets by MR (Summary) To take care of unforeseen error conditions when an MR receives an IP packet destined to one of the MHs associated with the MR, and the LSR option in the packet already contains the IP address of the MAS that serves the MH (as presently known by the MR), the MR drops the packet and sends an ICMP Destination Unreachable (Source Route Failed) message to the originator of the packet. If the IP address of the MAS stored in the record associated with the destination MH (as indicated by the Destination Address field of the received packet) is invalid (see Section 4.1), the MR sends an ICMP Destination Unreachable message to the originator of the packet and performs no additional actions. Otherwise, a) if the packet already has the LSR option the MR appends the IP address specified in the Destination Address as the last entry of the LSR option (incrementing the value of the Length field of the option by 4), b) if the packet does not have the LSR option, the MR creates the option consisting solely of the IP address specified in the Destination Address field of the IP header. Finally, the MR places the IP address of the MAS serving the destination MH in the Destination Address field of the IP header. The resulting IP packet is then handled via normal internet forwarding. When an MR receives an IP packet destined to an MH associated with the MR, and the LSR option in the packet is exhausted, the MR shall check to see whether the last entry in the LSR coincides with the destination of the packet. That unusual condition signals to the MR that the packet was routed to it by a MAS which was unable to deliver the packet to the MH, because the MH was no longer present in the MAS's cell. In this case the MR replaces the last address in the list by the address currently known by the MR to be the MAS serving the MH. If there is no such match, the MR must assume that no MAS has touched the packet yet, and create space for the MAS by enlarging the LSR by one slot (of length appropriate for the address of the MAS). If there is no MAS currently serving the MH, the MR shall discard the packet and send ICMP Destination Unreachable to the source of the packet. 2.1.6 Handling IP packets by MAS (Summary) When a MAS receives an IP packet, the MAS first performs any normal IP processing on the packet, including processing of the LSR option. If the packet was received over one of the interfaces attached to a Level 2 subnetwork that supports mobility, then the packet is handled via normal internet forwarding. If the interface over which the packet should be sent is the same as the one over which that packet was received, and the Link Layer technology associated with the interface supports direct intra-cell communications the MAS sends an ICMP Redirect message to the MH originating the packet. If the packet was received over one of the interfaces attached to a "regular" level 2 subnetwork, then after the processing the MAS shall determine whether the IP address specified in the Destination Address of the IP header indicates an MH presently served by the MAS. If that is the case, then the MAS forwards the packet directly to the MH. Otherwise, the MAS replaces the destination field of the header with the address of the MH, which will then match the last address of the LSR. Then the MAS allows normal routing mechanisms to forward the packet to the MR, which then will forward the packet to the current MAS serving the MH. 3 MH determination of cell location A MAS must maintain the following information: - A cache of MHs it believes are currently in its cell and being served by it. Entries in the cache are created when an MH moves into the MAS's cell and handshakes with it. They may be expired or deleted if: o the MH in question has not pinged the MAS and the MAS did not forward any IP packets from the MH in a specified period of time, o the MAS receives a message from an MH presently associated with the MAS indicating that the MH decided to establish association with another MAS. o when a MAS determines that the MH is no longer in its cell - A list of packets recently returned to the MR. If a new packet is located on this list, the new packet is discarded. Packets may be identified by recording the ip_id, source, and destination fields of the IP header. This procedure guards against packet looping in the pathological case where the MR shows a MAS as serving some MH, but the MAS does not think it is serving that MH. 3.1 Identifying MHs in a Cell It is important to emphasize that the method of identifying cell connections can be different for different media, and should be considered to be part of the Link Layer protocol. The following is an example of how cell discovery might occur. Additional study may be needed to determine whether ICMP Router Discovery messages, appropriately modified BEACON, GREET, and GRACK/GRNACK suggested in [2], or a new protocol, should be used to provide the appropriate mechanism to identify MHs in a Cell. Every MAS periodically broadcasts a beacon. MASs that receive the beacon should ignore it. To acquire MAS service, an MH that hears beacons from one or more MASs (because cells may overlap physically) may pick up any of these MASs. The selection is a local matter. In the most simple form the above procedure may be accomplished via ICMP Router Discovery message exchange ([3]). A MAS periodically transmits ICMP Router Advertisement Message. Note that the ICMP Router advertisement Message shall carry in the Route Address field of the message the IP addresses of all of the MAS's interfaces attached to "regular" Level 2 subnetworks. 3.2 Cell Switch The MAS will continue to believe the MH is in its cell either until it receives a message from the MH indicating that the MH is about to leave the cell or already left the cell, or because the corresponding entry is expired. Once an MH decides to change the MAS it shall notify the MAS that had been serving the MH about this decision. This is accomplished by sending MH2MR to the old MAS, but the address of the MH's new MAS may not be specified if doing so would create difficulties with security. When the former MAS receives this packet from the MH, it must remove the MH from its list of hosts currently reachable via its "cell" interface. The MAS is not required to acknowledge the MH2MR message. Each time an MH changes its MAS, the MH is required to flush its ARP cache. If the Link technology employed within a cell supports direct intra-cell communication (see Section 2.1.1.1), then each time an MH changes its MAS, the MH is required to send ARP request (for its own IP address) in the new entered cell. This would allow other MHs within a cell to adjust their ARP caches, if needed. 4 Propagating location information to the mobile routers and base stations An MH must maintain the following information (along with its own IP address): - An IP address of the MR associated with the MH. - An IP address of the MAS presently serving the MH. Note that only the first item (address of the MR) must always be known. The other item may be discovered dynamically, as might the MH's address. An MR must maintain the following information: - A list of IP addresses of the MASs that presently serve the MHs associated with the MR. Entries in the cache are changed when an MH moves from one cell to another, and they may be expired if the MH in question has not pinged the MR in a specified period of time. Section 3 describes mechanisms for maintaining location information in MHs and MASs. 4.1 Maintaining location and routing information in MRs As MH moves from one cell to another, it changes the MAS that serves the MH. Each such change needs to be propagated to the MR associated with the MH. To propagate the change the MH sends an MH2MR packet containing the address of the MAS presently serving the MH, sequence number, lifetime, and optional authentication data. The MH may also send a similar packet to the MAS serving the previous cell of the MH, as described in section (3.2). Each time an MH generates the MH2MR message carrying an address of a different MAS, the sequence number needs to be incremented (but it may be incremented by more than 1). The only requirement imposed on the sequence number is that it should monotonically increase. Thus, a timestamp may be used as a sequence number. For each MH associated with a given MR, the MR maintains a record. Among other things, the record contains the information about the highest valid sequence number of the MH2MR packets received from the MH, the IP address of the MAS presently serving the MH. In addition, to guard against certain anomalies arising from crashed MASs, this table may include a specification for the lifetime of the record. Once the lifetime of the record expires, the MR invalidates the MAS IP address and the sequence number stored in the record. Additional study is needed to ascertain the need for this lifetime specification. When an MR receives the MH2MR packet it verifies that the packet comes from one of the MHs served by the MR. This verification may be optionally augmented by using the authentication information in the MH2MR packet (if present). If the verification fails the MR discards the packet. Otherwise, it compares the sequence number on the packet with the sequence number stored in the record associated with the MH. If the sequence number in the packet is not greater that the store sequence number, the information in the packet is ignored, but the packet itself if sent back to the originating MH. Otherwise, the MR updates the address of the MAS presently serving the MH, stores the sequence number of the received packet and sends the received packet back to the source MH. An MH stops retransmitting its MH2MR packet once it receives an MH2MR packet echoing the packet the MH is presently retransmitting. If an MH has to generate an MH2MR message with the address of a new MAS (as a result of switching to a new cell), and the MH still did not receive the echo of its previously sent MH2MR message (carrying the IP address of the MAS in the old cell), the MH shall stop retransmitting the old message and start retransmitting the new one. An MH receiving echo of the MH2MR packet it sent to its associated MR may perform additional authentication checking before deciding to stop retransmission. If a MR receives a packet from a MAS which can no longer serve some MH, the LSR list will be exhausted, and the last entry of the LSR may be the MAS which the MR has recorded as the current MAS for the destination MH. This can only happen if the MAS has detected the absence of the MH in some way, or if certain error conditions arise. (See Section 2.1.5) If the last entry is different from the address of the current MAS for the destination MH, then the MR fills in the correct MAS address and adjusts the pointer and length fields, and re-forwards the packet. If a lifetime specification has been made for the MAS <--> MH record at the MR, then even in absence of any movement an MH is required to periodically transmit MH2MR message to its associated MR to ensure that the information stored in the MR would not expire. We suggest to transmit this information with period of at least 1/3 the value of the Lifetime field in the MH2MR packets that the MH sends to its MR. Note that such transmission does not involve incrementing sequence number and does not require acknowledgement (in the form of echoed MH2MR message). In other words, no retransmission is necessary. Note that communication between an MH and its associated MR is accomplished in precisely the same fashion as communication between an MH and a stationary host (see Section 2.1.2). 4.2 Format of the MH2MR message MH2MR messages are exchange over UDP with port number ZZZ. MH2MR Packet format: 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 | subcode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address of MH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sequence number (timestamp) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +---------------+-----------------------------------------------+ | Num of Addr | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address of the current MAS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address of the current MAS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication info... +-+-+-+-+-+-+-+-+-+-+-+-+-... Packet type: MH2MR 1 Subcode: Lower two bits: Reserved, must be 0. Upper six bits: If 0, no authentication information provided. If non-0, length of authentication info, in four-octet words. (Masking out the lower two bits of the subcode gives the length of authentication info in octets). IP address of MH: This is the home address of the MH. It should match the IP source address on the packet. Sequence number (timestamp): A 32-bit sequence number; the only limitation on the sequence number is that it never wraps around while the MR maintains a valid sequence number for that MH. Once the sequence number reaches its upper limit the MH is required to stay down for at least Lifetime seconds. Lifetime: A 32-bit field specifying the maximum time the MR receiving the MH2MR message can rely on the information in the message. Num of Addr: This is the number of IP addresses of the interfaces attached to the MAS selected by the MH IP address of the current MAS: This is the IP addresses of the MAS (IP address of one of the MAS's interfaces) in whose cell the MH is presently (at the time of sending the message) in. Authentication info: A password or token that the MR uses to decide whether the MH has sufficient credentials to be given service. The exact nature of this is beyond the current scope of the document. To allow for multiple types of authentication information, the following format should be obeyed. Multiple authentication fields may be present to accommodate a variety of authentication mechanisms. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Version | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-... The Authentication Type field describes which authentication mechanism is being used, with the Version field detailing which version of that mechanism. The Length field indicates the length of the authentication data in octets. Authentication Type 0 is just padding, and as such, only the type field is used (i.e., it is just a 0-filled octet). Authentication Type 1 indicates that the authentication data are just a plaintext password; Version is 0; the Length field indicates the length of the password, and the authentication data is a cleartext password. It is recommended that this type of authentication is only used when the physical medium can be trusted. Authentication Types 2-127 are reserved for future standard definitions. Authentication Types 128-255 are reserved for future definition by vendors and/or implementors. 5 Robustness in presence of failures To improve robustness of the scheme a given MH may be associated not with one, but with multiple MRs. This is accomplished by requiring a group of MRs to advertise direct reachability to a common range of addresses. As an MH moves from one cell to another it is required to notify all of its associated MRs about such moves. To deal with MR failures (e.g. MR crash) the MR is required to wait at least the amount of time greater than the maximum amount of time between consecutive MH2MR messages allowed by the MHs associated with that group of MRs before claiming reachability to the range of addresses given to the MR. To improve robustness it is recommended that this group of MRs will be located in places with redundant connectivity. That would reduce the probability that communication between MHs and associated with them group of MRs would be affected by network failures. No communication between the participating MRs is required. 6 Implications on using Loose Source Routing The proposed scheme assumes that mobile hosts satisfy Host Requirements ([1]) when handling Loose Source Route IP option. Specifically, the proposal assumes that as stated in [1]: "If host receives a datagram containing a completed source route (i.e., the pointer points beyond the last field), the datagram has reached its final destination; the option as received (the recorded route) MUST be passed up to the transport layer (or to ICMP message processing). The recorded route will be reversed and used to form a return source route for reply datagrams." A stationary host that ignores the LSR option would be able to maintain connectivity with a mobile host, albeit the routing may be suboptimal. The impact on the communication between a stationary host that processes the LSR option, but processes it incorrectly and a mobile host depends on the details of the incorrect processing of the option by the stationary host. The proposal assumes that a router involved in forwarding IP packets from/to MHs is either correctly supports the Loose Source Route option, or doesn't support it at all. Observe that only the MASs and MRs are involved in manipulating the LSR option. 7 Acknowledgments Some of the introductory material and text on authentication information was taken almost verbatim from [2]. We would like to express our thanks to Deborah Estrin (University of Southern California), Andrew Myles (Macquarie University), Radia Perlman (DEC), and Pravin Bhagwat (IBM) for their review and constructive comments. Appendix A IP Loose Source Route option. The following material from [5] describes the IP Loose Source Route option. Loose Source and Record Route +--------+--------+--------+---------//--------+ |10000011| length | pointer| route data | +--------+--------+--------+---------//--------+ Type=131 The loose source and record route (LSRR) option provides a means for the source of an internet datagram to supply routing information to be used by the gateways in forwarding the datagram to the destination, and to record the route information. The option begins with the option type code. The second octet is the option length which includes the option type code and the length octet, the pointer octet, and length-3 octets of route data. The third octet is the pointer into the route data indicating the octet which begins the next source address to be processed. The pointer is relative to this option, and the smallest legal value for the pointer is 4. A route data is composed of a series of internet addresses. Each internet address is 32 bits or 4 octets. If the pointer is greater than the length, the source route is empty (and the recorded route full) and the routing is to be based on the destination address field. If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and pointer is increased by four. The recorded route address is the internet module's own internet address as known in the environment into which this datagram is being forwarded. This procedure of replacing the source route with the recorded route (though it is in the reverse of the order it must be in to be used as a source route) means the option (and the IP header as a whole) remains a constant length as the datagram progresses through the internet. This option is a loose source route because the gateway or host IP is allowed to use any route of any number of other intermediate gateways to reach the next address in the route. Must be copied on fragmentation. Appears at most once in a datagram. The following material from [1] describes handling the IP Loose Source Route option by hosts. (c) Source Route Options A host MUST support originating a source route and MUST be able to act as the final destination of a source route. If host receives a datagram containing a completed source route (i.e., the pointer points beyond the last field), the datagram has reached its final destination; the option as received (the recorded route) MUST be passed up to the transport layer (or to ICMP message processing). This recorded route will be reversed and used to form a return source route for reply datagrams (see discussion of IP Options in Section 4). When a return source route is built, it MUST be correctly formed even if the recorded route included the source host (see case (B) in the discussion below). An IP header containing more than one Source Route option MUST NOT be sent; the effect on routing of multiple Source Route options is implementation- specific. Section 3.3.5 presents the rules for a host acting as an intermediate hop in a source route, i.e., forwarding a source-routed datagram. DISCUSSION: If a source-routed datagram is fragmented, each fragment will contain a copy of the source route. Since the processing of IP options (including a source route) must precede reassembly, the original datagram will not be reassembled until the final destination is reached. Suppose a source routed datagram is to be routed from host S to host D via gateways G1, G2, ... Gn. There was an ambiguity in the specification over whether the source route option in a datagram sent out by S should be (A) or (B): (A): {>>G2, G3, ... Gn, D} <--- CORRECT (B): {S, >>G2, G3, ... Gn, D} <---- WRONG (where >> represents the pointer). If (A) is sent, the datagram received at D will contain the option: {G1, G2, ... Gn >>}, with S and D as the IP source and destination addresses. If (B) were sent, the datagram received at D would again contain S and D as the same IP source and destination addresses, but the option would be: {S, G1, ...Gn >>}; i.e., the originating host would be the first hop in the route. The following material from [6] describes handling the IP Loose Source Route option by routers. 5.2.4 Determining the Next Hop Address When a router is going to forward a packet, it must determine whether it can send it directly to its destination, or whether it needs to forward it through another router. If the latter, it needs to determine which router to use. This section explains how these determinations are made. This section makes use of the following definitions: o "LSRR" -- IP Loose Source and Record Route option o "SSRR" -- IP Strict Source and Record Route option o "source route option" -- an LSRR or an SSRR o "ultimate destination address", or simply "destination address" -- where the packet is being sent to: the last address in the source route of a source-routed packet, or the destination address in the IP header of a non-source- routed packet o "adjacent" -- reachable without going through any IP routers o "next hop address" -- the IP address of the adjacent host or router to which the packet should be sent next o "immediate destination address" -- the ultimate destination address, except in source routed packets, where it is the next address specified in the source route 5.2.4.1 Immediate Destination Address If the destination address in the IP header is one of the addresses of the router and the packet contains a source route option, the immediate destination address is the address pointed at by the pointer in that option if the pointer does not point past the end of the option. Otherwise, the immediate destination address is the same as the IP destination address in the IP header. A router MUST use the immediate destination address, not the ultimate destination address, when determining how to handle a packet. It is an error for more than one source route option to appear in a datagram. A router MUST NOT originate such a packet. If it receives one, it SHOULD discard the packet and reply with an ICMP Parameter Problem message whose pointer points at the beginning of the second source route option. References 1. R. Braden. Requirements for Internet Hosts -- Communication Layers. Tech. Rept. RFC 1122, Network Working Group, October, 1989. 2. John Ioannidis and Dan Duchamp and Gerald Q. Maguire Jr. IP-Based protocols for mobile internetworking. Proceedings of SIGCOMM'91, ACM, September, 1991, pp. 235--245. 3. S. Deering. ICMP Router Discover Messages. Tech. Rept. RFC1256, Network Working Group, September 1991. 4. Fumio Teraoka, Yasuhiko Yokote, and Mario Tokoro, A Network Architecture Providing Host Migration Transparency, Proceedings of SIGCOMM'91, ACM, September, 1991, pp. 209-220 5. John Postel, Internet Protocol, Tech Rept. RFC791, Network Working Group, September 1981. 6. Philip Almquist, Requirements for IP Routers, Internet Draft, October 1991. Authors' Addresses Yakov Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598 Phone: (914) 945-3896 email: yakov@watson.ibm.com Charles Perkins T.J. Watson Research Center IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598 Phone: email: perk@watson.ibm.com