group. Our draft is attached below. Thanks in advance. - Hiromi Wada (Internet:hwada@isl.mei.co.jp) - Information Systems Research Laboratory PHONE +81-6-906-2431 - Matsushita Electric Industrial Co., Ltd., JAPAN FAX +81-6-906-5547 ------ Mobile IP Working Group Hiromi Wada INTERNET DRAFT Tatsuya Ohnishi Matsushita Electric Industrial Co., Ltd. Brian Marsh Matsushita Information Technology Laboratory July 1993 Packet Forwarding for Mobile Hosts Abstract This memo describes a new protocol for mobile internetworking: the Internet Packet Transmission Protocol (IPTP). IPTP provides packet forwarding and host location functions that make mobility transparent to all protocols above IP. IPTP specifies control messages between the networking software on mobile hosts and a special Packet Forwarding Service. Backward compatibility is provided by requiring no modifications to stationary hosts or internetwork routers. To reduce overhead, IPTP provides for lazy propagation of location updates. To enhance performance, routes adapt as mobile hosts move. Status of this memo This document describes an approach to transparent mobile internetworking. This RFC requests discussion and suggestions for improvements. Distribution of this memo is unlimited. It expires on January 2, 1994. Please respond with comments to the mobile-ip@parc.xerox.com mailing list. 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.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 1 Introduction Expires 2 January 1994 [Page 1] Internet-Draft Packet Forwarding July 1993 1.1 Goals Our aim is to support a computing environment where hosts can communicate with each other continuously as they migrate across networks. We describe an IP-level solution designed to minimize the impact on existing protocols and applications. Our solution provides packet forwarding and host tracking to allow IP packets to find their way between mobile and non-mobile hosts. From a practical point of view, we have two goals: backward compatibility and performance. To provide backward compatibility we try to minimize the amount of software that must be modified. First, IPTP requires no changes to router software. Second, it requires no changes at all to the software of stationary hosts. Finally, it requires no changes to mobile hosts above the network layer. To enhance performance, we need to minimize the overhead added to each forwarded packet, and to make migration as inexpensive as possible. Per-packet overhead is due to encapsulation and any additional hops that are added to a route. Host migration, or handoff as other proposals refer to it, has costs associated with the propagation of location information. IPTP requires encapsulation only for packets sent to the mobile host. Packets from the mobile host have no additional overhead. IPTP also provides adaptive routing to elminate unnecessary hops between communicating hosts. To cut down on the overhead of migration, IPTP provides lazy propagation of host location information, reducing the number of messages sent when a host moves. 1.2 Basic Concepts IPTP assumes three active entities: Mobile Hosts (MH), Stationary Hosts (SH), and Packet Forwarding Servers (PFS). IPTP is the protocol used between these entities to implement the functions of MH location tracking and packet forwarding. An MH is a machine that can roam between networks. We assume that the kernel on this machine can be modified, but that protocols above IP will not be changed. In addition, we assume that applications will not be changed to account for roaming. Next, an SH is a machine that does not move. In the worst case we assume that no software can be changed. When such modifications are possible, IPTP specifies important performance enhancements that can be made. Finally, a PFS is a user-level server that runs on an SH (We assume that the kernel allows user-level programs to receive arbitrary packets, e.g., through a facility such as NIT in SunOS Release 4.0). It forwards packets for roaming MHs. In addition, it provides the primary copy of MH location information for any MHs for which it is the home PFS. Expires 2 January 1994 [Page 2] Internet-Draft Packet Forwarding July 1993 The basic idea is as follows. An MH has two addresses: a home address and a temporary address. The home address is a legitimate IP address on a subnet distinguished as the home network for the MH. Home addresses are statically assigned and never change. A temporary address is assigned as the MH moves between networks. Packets are sent to an MH using its home address. When an MH has moved away from its home network, IPTP uses the temporary address to forward packets to the new location of the MH. IPTP is designed to maintain the mappings between an MH's home and temporary addresses, and to forward packets to roaming MHs. Packets are forwarded by encapsulating them in special IPTP packets. IPTP provides two operational modes whose use depends on whether the SH can be modified or not: forwarding mode and autonomous mode. Forwarding mode allows an unmodified host to communicate with an MH. Packets sent to a roaming MH are transmitted via standard IP but are intercepted by a PFS. The PFS then encapsulates the packets and forwards them to the MH's current temporary address. In autonomous mode, the packet forwarding facility is built directly into the networking software of the SH. A packet sent to the MH is encapsulated in an IPTP packet whose destination address is the MH's temporary address. The PFS is removed from the transmission path except for tracking MHs. MH-to-MH communication works exactly the same way as SH-to-MH communication. We have two kind of PFSs. One is a home PFS, and the other is an Autonomous Supporter(AS) PFS. The home PFS is located on a home network of MHs. The PFS is responsible for forwarding packets to an MH's temporary networks and for managing location information. The AS are located on a new network that an MH has visited. After the MH again migrates to another network, the AS forwards packets destined for the MH to its current network. 1.3 Overview This document is organized as follows. In Section 2 we discuss how mobile hosts are addressed. In Section 3 we detail how packet forwarding is done, both for backward compatibility and performance. In Section 4 we focus on how location information is maintained. In Section 5 we present the details of the IPTP protocol. In Section 6 we describe important implementation issues. 2 Addressing Each MH has two addresses: a home address and a temporary address. Expires 2 January 1994 [Page 3] Internet-Draft Packet Forwarding July 1993 The "home" address distinguishes the network from which the MH originates. The home address remains the same even while the MH is roaming. The network part of the home address is equal to the home network address. The notion of a home is useful because it provides an easily found source of reliable information about a roaming MH. In particular, a PFS located on an MH's home network is responsible for tracking its whereabouts at all times. That PFS is also responsible for forwarding packets sent to a roaming MH's home address. The temporary address reflects the current real location of the MH (we also refer to it as the "real address"). The network part of the address is equal to the network address where the MH currently lives. A temporary address changes every time the host migrates to a new network. The exact process of assigning temporary addresses is beyond the scope of this document. Applications address an MH using its home address, regardless of its location. This is true both for applications running on the MH and for applications on other machines that must communicate with the MH. To send data to an MH, a host builds an IP packet whose destination address is the home address of the MH. The IP packet is then encapsulated in an IPTP packet whose destination address is the current temporary address of the MH. The packet is then delivered to the MH using existing routing mechanisms. An MH receiving an encapsulated packet decapsulates it to yield the original IP packet. Because the temporary address of an MH is assigned dynamically when the MH visits a network, encapsulated packets might mistakenly be sent to a temporary address that has been reassigned to another MH. To filter out such packets, each encapsulated packet is tagged with the home address of the destination MH. Since each MH has a unique home address, it is possible to distinguish packets that should not actually be delivered. An encapsulated packet is accepted only if the temporary and home addresses match those of the receiving host. 3 Packet Forwarding In this section, we describe packet forwarding in detail. As described in Section 1.2, packet forwarding is done in one of two modes: forwarding mode and autonomous mode. In forwarding mode, the SH is unmodified and packets are forwarded by a PFS. In autonomous mode, packet forwarding is performed by the sending host. Both modes can co-exist in one environment. 3.1 Forwarding Mode In forwarding mode, packet forwarding for an MH is performed by a PFS on the MH's home network. In Figure 1 we consider communication Expires 2 January 1994 [Page 4] Internet-Draft Packet Forwarding July 1993 between an SH and an MH. +--------+ | | +---> | PFS | ---+ (1) SH to MH | | | |(2)Packet Forwarding | +--------+ | (normal packet(1) is | | encapsulated in it) +--------+ | | +--------+ | | ---+ +---> | | | SH | | MH | | | <--------------------------- | | +--------+ (3) normal packet +--------+ Figure 1. Forwarding Mode (1) SH to MH - An SH sends a packet to an MH specifying the MH's home address. The packet is routed to the MH's home network where it is intercepted by a PFS. Packet interception is arranged by the PFS either by using some sort of promiscuous mode or by arranging with local gateways for packets to be routed to the SH on which the PFS is running. (2) Packet Forwarding - The PFS encapsulates the packet sent in (1) into a "Packet Transmission" packet (the exact format is described in Section 5.2). The destination address in the IPTP message is the temporary address of the MH. The PFS maintains a mapping between the home address and the temporary address by the IPTP protocol. This location information management is described below. When the MH receives the "Packet Transmission" message, its IPTP layer decapsulates the IP packet it contains. From the perspective of applications running on the MH, the MH appears to still reside on its home network. (3) MH to SH - The packet decapsulated from the "Packet Transmission" message contains the IP address of the SH in its source address field. The MH sends a reply packet directly to the SH using standard IP. The source address used for the reply packet is the MH's home address. Because reply packets are standard IP packets, they are routed using normal IP routing mechanisms. We assume that the MH dynamically acquires such routing information through a protocol such as DHCP[2]. 3.2 Autonomous Mode Autonomous mode allows an SH to transmit packets directly to an MH, without relaying them via a PFS. The packet routes that result can Expires 2 January 1994 [Page 5] Internet-Draft Packet Forwarding July 1993 be significantly shorter. An autonomous mode connection has two key requirements. First, the SH must have been modified to do its own packet forwarding. Second, the MH must be able to find a PFS on its current network to act as an AS. An AS acts like a home PFS in the following way: if an MH migrates away from that network, the AS will intercept packets sent to it, and forward them to the MH's new address. 3.2.1 SH Transmission In this mode, packet forwarding is performed directly by the SH, instead of by the PFS. Figure 2 illustrates this case. The SH maintains a mapping between the home address and the temporary address of the target MH. In this respect the functionality added to the networking software of the SH is similiar to that added to the PFS. The difference is in how location information is propagated. Location updates are sent by the MH to its home PFS, a PFS acting as an autonomous supporter and an modified SH. If an SH initiates communication with an MH after the MH has migrated, it receives updates lazily when it uses stale addresses to send packets to the MH. If not, the peer MH sends its current temporary address to the SH before the MH sends its first packet to the SH after its migration. The SH mappings can be viewed as a cache of the primary copy maintained by the home PFS. Details of location information management is described in the Section 4. (1) SH to MH (SH's normal packet +--------+ is encapsulated) +--------+ | | --------------------------> | | | SH | | MH | | | <-------------------------- | | +--------+ (2) MH to SH +--------+ Figure 2. Autonomous Mode (1) SH to MH - The SH sends a packet directly to the MH. Applications on the SH use the MH's home address. IPTP software on the SH encapsulates the packet into a "Packet Transmission" message and sends it to the MH using the MH's current temporary address. On receiving the packet, the MH's IPTP software decapsulates the original IP packet and passes it to the appropriate higher-level protocol. (2) MH to SH - The MH sends a packet directly to the SH using standard IP. This is the same as in the forwarding mode above. Expires 2 January 1994 [Page 6] Internet-Draft Packet Forwarding July 1993 3.2.2 Autonomous Supporter Transmission An AS will forward packets destined for an MH that is no longer present on the local network. It knows the MH's temporary address there, because it was notified it by "Ping Autonomous Supporter" message when it visited the network. It will also get the MH's current temporary address, because it will be notified it by "MH Location Information" message when the MH will visit a new network. Recall that the AS is a local PFS that has agreed to provide support for autonomous mode communications with visiting MHs. When the MH migrates to a new network, it notifies the AS. The AS will then begin to look for packets destined for the MH's local IP address (the temporary one assigned when the MH first arrived). If the AS knows the current temporary address of the MH, it will forward any packets it intercepts. If it doesn't know the current address of the MH, the packets are sent to the home PFS, which should have the MH's current location. The home PFS address is contained in the IPTP header of the intercepted packet. Figure 3 illustrates this case. (current network) (home network) +====+ (3) Packet Forwarding +=====+ | MH |<-----------------------------| home| +----->| |<------+ +-->| PFS | | +====+ |(2a) Packet | +=====+ | | Forwarding | | | +----------------+ migration | | (2b) Packet Forwarding | | | | (Ghost) | | | +----+ +=====+ +====+ | | | | PFS |<-------------| SH | +---------| | | | (1) SH to MH | | +----+ +=====+ +====+ (previous network) Figure 3. Forwarding mode by an autonomous supporter PFS (1) SH to MH - The SH in autonomous mode sends a packet directly to the temporary address of the MH, although the MH is not at the temporary address any longer. (2) Packet Forwarding by Autonomous Supporter - If the autonomous supporter PFS learns the current address of the MH through the mechanism described in Section 4, Expires 2 January 1994 [Page 7] Internet-Draft Packet Forwarding July 1993 it forwards the packet to the current temporary address(2a). If not, it forwards the packet to the home address(2b). When forwarding, the PFS does not encapsulate the packet because it is already encapsulated. Instead, it decrements the counter field in the IPTP header by 1 and if the value is 0, the PFS discards the packet. (3) Packet Forwarding - This takes place only when preceded by (2b). The home PFS forwards the packet to the current temporary address of the MH. Forwarding process is the same as (2) above (counter decrement and no encapsulation). 4 Location Information Management In this section we describe how IPTP is used to maintain location information. A home PFS maintains the primary copy of location data for its local network. When an MH migrates, it transmits its new configuration information to its home PFS. This data includes the MH's new temporary address and whether there is an Autonomous Supporter on the new network. The home PFS is then responsible for propagating the data to all concerned hosts. This data may be cached by MHs, SHs, and autonomous supporters (ASs). PFSs need it to support packets transmitted in Forwarding Mode. MHs and SHs need it when communicating in Autonomous Mode. Below, we describe how updates are first sent when an MH migrates and later propagated to other MHs, SHs, and ASs. 4.1 MH Migration/PFS Notification When an MH moves to a new network, it transmits new configuration information to its home PFS and its previous AS. Notification to the home PFS is for redirecting packets sent in Forwarding Mode. Notification to the AS is for redirecting packets sent in Autonomous Mode. Figure 4 describes how configuration information is collected and distributed. Expires 2 January 1994 [Page 8] Internet-Draft Packet Forwarding July 1993 (current network) Ping Autonomous Supporter (home network) +====+ (1) +=====+ +=====+ | MH |----->| PFS | | home| +-->| | | | +-->| PFS | | +====+ +=====+ | +=====+ | || | | |+------------------------------------+ | | (2) MH Location Information | | | +-------------------------+ | |(3) MH Location Information | (Ghost) v | +----+ +=====+ migration | | | PFS | +------------------| | | (AS)| +----+ +=====+ (previous network) Figure 4. Location information distribution (0) The MH is assigned a temporary address using a protocol such as DHCP. (1) Autonomous Supporter -- The MH tries to find a PFS which can support autonomous mode in the new network. The MH broadcasts a "Ping Autonomous Supporter" message. If any PFS responds, the MH will transmit packets in autonomous mode. When a PFS receives a "Ping Autonomous Supporter", it sends to the sender a reply message with an autonomous flag which indicates whether it supports the mode or not. A PFS supporting Autonomous Mode registers the MH in a list of visiting MHs. (2) MH Location Information - The MH sends an "MH Location Information" message to a PFS on its home network. This message carries the home and temporary addresses of the MH, an autonomous flag which indicates whether the MH can communicate in autonomous mode or not, and the address of the PFS which responded to the "Ping Autonomous Supporter" message. When a PFS in the home network receives an "MH Location Information" message, it returns an acknowledgement to the MH, and updates its mapping for the home address of the MH. (3) MH Location Information to a Previous PFS - The MH also sends an "MH Location Information" message to an AS (if any) on its previous network. If the MH has not just migrated from its home network and if it was operating in autonomous mode on the Expires 2 January 1994 [Page 9] Internet-Draft Packet Forwarding July 1993 previous remote network, there must have been an Autonomous Supporter on that network. Hence, the MH sends it an "MH Location Information". When the AS receives the "MH Location Information" message, it acknowledges the message and flags its mapping (if any) for the MH. The flag indicates that the MH has migrated, and means that the AS may delete the MH's entry if necessary. After that, the AS starts looking for packets destined for the MH's obsolete temporary address. 4.2 Autonomous Sender Notification Notifying the home PFS only takes care of packets sent in forwarding mode. If a host can use autonomous mode to communicate with an MH which is migrating from its home network to another network, and if an AS in the new network works for the MH, then the host should change to autonomous mode. This notification is described in Section 4.2.1. If a host is using autonomous mode to communicate with the MH, there are two possibilities for how to distribute the MH's current temporary address to the host. In one case, the host has sent a "Packet Transmission" message to the network previously occupied by the MH. An AS in that network works on behalf of the MH. If the AS knows the MH's current temporary address, it will inform the host of it. This case is described in Section 4.2.2. In the other case, the MH has sent a "MH Location Information" message to the host prior to re-starting communication after migration. This case is described in Section 4.2.3. In both cases, IPTP provides lazy notification by waiting until a message is sent to the host. 4.2.1 Packets to the Home Address A host that communicates with an MH that has migrated may address its packet to the home address of the MH. If the sending host supports autonomous mode, then its location tables must be updated to reflect the new location of the MH. Figure 5 depicts how this update procedure takes place. Expires 2 January 1994 [Page 10] Internet-Draft Packet Forwarding July 1993 +====+ +-----| SH |-----+ | | |<--+ | (4)| +====+ | |(1) Normal Packet| MH(3) | | Packet Transmission| Location| | Transmission | Information| | | | | +=====+ +====+ | | +---->| home| | MH |<---+ +-------| PFS | | |<------------------------- +=====+ +====+ (2)Packet Forwarding (current network) (home network) Figure 5. Packets to the Home Address (1) Normal Packet Transmission - The SH sends a normal IP packet to the MH's home address. (2) Packet Forwarding - The home PFS picks up the packet, encapsulates it within an IPTP "Packet Transmission" message, and sends it to the MH's current temporary address. (3) MH Location Information - If the MH has moved to a network that supports autonomous mode then the home PFS attempts to notify the SH that autonomous mode communication is possible. If the SH is capable of autonomous mode communication, when it receives the "MH Location Information" message, it caches the MH's new temporary address, and enters autonomous mode for all packets destined for the MH. (4) The SH can now send packets to the MH without an intervening hop through the PFS. 4.2.2 Packets from an AS If an SH using autonomous mode is communicating with an MH which is not located in its home network, an AS must be in the network where the MH exists. If the MH has migraterd to a new network and if another AS exists there, the SH can continue to communicate with the MH using autonomous mode. The AS in the previous network forwards "Packet Transmission" messages destined for the MH to its current temporary address and informs the SH of the address. Figure 6 illustrates this case. Expires 2 January 1994 [Page 11] Internet-Draft Packet Forwarding July 1993 (current network) (home network) +====+ +=====+ +=====+ | MH | | PFS | | home| | |<-+ | (AS)| | PFS | +====+ | +=====+ +=====+ ^ ^ | | | +----------------------------+ | | | | +--------+(2) Packet |(4) Packet migration | Transmission | Transmission | | | | | | (Ghost) | (3) Location | +----+ +=====+ Information +====+ | | | PFS |----------------->| SH | | | | (AS)|<-----------------| | +----+ +=====+ (1) Packet +====+ (previous network) Transmission Figure 6. Packets from an AS (1) Packet Transmission - The SH using autonomous mode sends "Packet Transmission" message to the previous temporary address of the MH. (2) Packet Transmission - The AS in the previous network forwards it to the current temporary address of the MH. (3) Location Information - The AS in the previous network informs the SH of the current temporary address of the MH. (4) Packet Transmission - The SH sends subsequent packets to the MH's current temporary address. 4.2.3 Packets from a Migrated MH Before a migrated MH initiates communication with an SH, the MH sends an "MH Location Information" message to the SH. If the SH supports autonomous mode, it extracts the MH's current temporary address. Therefore, when the SH responds a packet sent by the MH, it can send the packet directly to the MH via normal IP routing instead of through a PFS. Figure 7 illustrates this case. Expires 2 January 1994 [Page 12] Internet-Draft Packet Forwarding July 1993 (1) MH Location Information +-------------------------------------+ | | v | +-------+ (2) Normal IP Packet +-------+ | | <--------------------------- | | | SH | | MH | | | ---------------------------> | | +-------+ (3) Packet Transmission +-------+ Figure 7. Packets from a Migrated MH (1) MH Location Information - The MH informs the SH of its own current temporary address, before it starts communicating with the SH. (2) Normal IP Packet - The MH sends a normal IP packet to the SH. (3) Packet Transmission - The SH can encapsulate packets to the MH into the "Packet Transmission" messages. 4.3 Packets to an Obsolete Temporary Address Figure 8 illustrates what happens if a PFS acting as an autonomous supporter (AS) receives a packet destined for an MH that has already left its network. The AS must encapsulate and forward the packet. More importantly, however, it must notify the sending host of the MH's new address. Expires 2 January 1994 [Page 13] Internet-Draft Packet Forwarding July 1993 (current network) (home network) +====+ +=====+ +->| MH |<---------+(4b) | home| | | |<--+ |Subsequest | PFS |---+(5) | +====+ | |Packet +=====+ |MH | | |Transmission ^ |Location migration |(2) +---------+ | |Information | |Packet | | | | |Forwarding | |(4a) | | | | |Subsequest | | | |Packet (Ghost) | (3)MH Location | |Transmission +----+ +=====+ Information +---+====+ | | | | PFS |----------------->| SH |<-+ | | | (AS)|<-----------------| | +----+ +=====+ (1)Packet +====+ (previous network) Transmission Figure 8. Packets to an Obsolete Temporary Address (1) Packet Transmission - The SH sends a "Packet Transmission" message to the MH's old temporary address. The autonomous supporter for the MH's old temporary address will intercept the packet. It knows that the MH is gone because it received a "MH Location Information" message as described in Section 4.1, paragraph 3. (2) Packet Forwarding - The AS may attempt to forward the packet to the MH if the MH's new temporary address is still in its cache. However, the AS is not required to maintain the new address of the MH. If it is not in the cache, the AS knows only that it has gone. If so, the packet is instead forwarded to the home PFS for correct rerouting. (3) MH Location Information - The AS must now notify the SH that it has an out of date address for the MH. It therefore sends to the SH an "MH Location Information" message. The AS includes the MH's new address if possible, allowing subsequent packets to be routed directly to the MH without going through the home PFS. If the AS does not know the MH's new address then the address field is set to NULL, indicating that the SH should route packets to the MH's home network where they are picked up by the home PFS. (4) Subsequent Packet Transmission(SH to MH) - The SH knows that its mapping for the MH is stale. If no new address for the MH was received in (3), then it will transmit subsequent packets to the MH's home network for processing by the home PFS (4a). Expires 2 January 1994 [Page 14] Internet-Draft Packet Forwarding July 1993 Otherwise, it will transmit subsequent packets to the new temporary address of the MH (4b). (5) MH Location Information - When the home PFS receives the next packet destined for the home address of the MH, if the MH is available for autonomous mode communication, the home PFS sends an "MH Location Information" message to the sender. At the same time, it forwards the packet to the current temporary address of the MH. When the sender receives the "MH Location Information" message, it updates the cache entry of the MH's location and enters autonomous mode. This step takes place only if preceded by step(4b). 5 Internet Packet Transmission Protocol(IPTP) In this Section we describe the Internet Packet Transmission Protocol(IPTP). IPTP consists of four packet types that fit within one packet format. The packet types provide packet forwarding, new address notification, pinging for an autonomous supporter, and an IPTP echo check. 5.1 Message Type In this subsection, we describe the different IPTP message types. The parameter types are defined in detail in Section 5.2. (1) Packet Transmission This message is used to forward packets from a PFS to an MH and to send packets from an SH to an MH. It does not require a response. The following parameters should be set: - Type - Aim - Counter - Home address of MH - Temporary address of MH - Encapsulated packet (2) MH Location Information This message is used to notify a PFS or an SH of an MH's new address. It requires a response. The following parameters should be set: - Type - Aim Expires 2 January 1994 [Page 15] Internet-Draft Packet Forwarding July 1993 - Sequence - Autonomous - Home address of MH - Temporary address of MH - Address of PFS: See Section 5.2. - Authentication information The following parameters should be set in a response: - Type - Aim - Sequence - Status (3) Ping Autonomous Supporter message This message is used for an MH to find a PFS which supports the autonomous mode in a new temporary network. This message requires a response. The following parameters should be set in a request message: - Type - Aim - Sequence - Home address of MH - Temporary address of MH - Authentication information The following parameters should be set in a response message: - Type - Aim - Sequence - Autonomous - Status (4) Echo message This message is used to examine whether a host employs IPTP or not. It requires a response. The Following parameters should be set in both a request and a response: - Type - Aim - Sequence 5.2 Parameters Type: This field indicates a message type of an IPTP packet. Expires 2 January 1994 [Page 16] Internet-Draft Packet Forwarding July 1993 Value : Meaning -------------------------------------------- 0 : Packet Transmission message 1 : MH Location Information message 2 : Ping Autonomous Supporter message 3 : Echo message Aim: This field indicates whether the packet contains either a request or a response. Each message except "Packet Transmission" message requires a response. Value : Meaning ---------------------------------------------------- 0 : neither request nor response (That is "Packet Transmission" message.) 1 : request 2 : response Sequence number: The sequence number of the packet between a requester and a responder. It is used to indicate the relationship between a request and a response packet. Autonomous: Used only on "MH Location Information" messages from an MH to the home PFS. It indicates whether the home PFS should notify SHs of the MH's temporary address or not. Value : Meaning ------------------------------------------------------- 0 : The home PFS must not notify SHs of the MH's temporary address, 1 : The home PFS may notify SHs of the MH's temporary address. Counter: The counter is used to detect forwarding loops. It is set to an implementation-specific number whenever a "Packet Transmission" message originates. When a PFS receives the "Packet Transmission" message, the PFS decrements the counter by 1. If the counter is equal to 0, the PFS discards the packet instead of forwarding it. Expires 2 January 1994 [Page 17] Internet-Draft Packet Forwarding July 1993 Status: The status of the packet. Value : Meaning -------------------------------------------- 0 : No problem 1 : Authentication error 2 : Specified MH's address is unknown Home address of MH: The address of an MH on its home network. Temporary address of MH: The address of an MH on a temporary network. Assigned using some dynamic configuration protocol such as DHCP. Address of PFS: The IP address of a PFS. Possible values are: Situation : Meaning -------------------------------------------------- 1. MH migrates to new : Address of PFS which network is an autonomous supporter 2. PFS notifies Auto. : Address of home PFS mode supporter Authentication information: A password or token that PFSs use to decide whether an MH has sufficient credentials to be given service. The exact nature of this is beyond the current scope of this 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). Expires 2 January 1994 [Page 18] Internet-Draft Packet Forwarding July 1993 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. This type of authentication should only be 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. Encapsulated packet: This is an original IP packet destined for MH. This field is only included in "Packet Transmission" messages. Optional data: This is a field for optional data. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | optional data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 5.3 Packet Format (1) Packet Transmission message 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 | aim | (not used) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (not used) | counter | (not used) | (not used) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | home address of MH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | temporary address of MH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (not used) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encapsulated packet +-+-+-+-+-+-+-+-+-+-+-+-+-... (2) MH Location Information message Expires 2 January 1994 [Page 19] Internet-Draft Packet Forwarding July 1993 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 | aim | sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | autonomous | (not used) | status | (not used) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | home address of MH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | temporary address of MH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | address of PFS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | authentication information +-+-+-+-+-+-+-+-+-+-+-+-+-... (3) Ping Autonomous Supporter message 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 | aim | sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | autonomous | (not used) | status | (not used) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | home address of MH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | temporary address of MH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (not used) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | authentication information +-+-+-+-+-+-+-+-+-+-+-+-+-... (4) Echo message 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 | aim | sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | autonomous | counter | status | (not used) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional data +-+-+-+-+-+-+-+-+-+-+-+-+-... Expires 2 January 1994 [Page 20] Internet-Draft Packet Forwarding July 1993 5.4 State Diagrams +------------+ | non-mobile | +------------------>| mode | | migrate to +------------+ | home network | migrate to another network | ------------- | ------------------------------- | v send a request to get a tmp adr | +-------------+ +------------------>| waiting for | | migrate to | tmp adr | | another +-------------+ | network | get a tmp adr | -------------- | ------------- | send a request v send MHLI | to get a tmp +-------------+ | adr | waiting for | | | MHLI ack | | +-------------+ | | receive MHLI ack | PT | ---------------- | -- | send PAS | +-----+ | +-------+ | v | v v | PT | +------------+ | +-------------+ | -- | | forwarding |--+ | waiting for |----+ +--| mode |<----| PAS ack | ^ +------------+ +-------------+ | timeout | receive PAS ack | ------- | --------------- | | | | +-------+ | v v | PT | +-------------+ | -- PT : Packet Transmission +-------------------| autonomous |----+ MHLI : MH Location Info. migrate | mode | PAS : Ping Auto. Supporter ------- +-------------+ Figure 9. State Diagram of an MH Expires 2 January 1994 [Page 21] Internet-Draft Packet Forwarding July 1993 +------------+ | forwarding | | mode | +------------+ receive MHLI ^ | receive MHLI without MH's address | | ------------ ---------------------- | | | v +-------------+ | autonomous | | mode |<-+ send a packet to MH +-------------+ | ------------------- | | send PT +----+ Figure 10. State Diagram of an SH Expires 2 January 1994 [Page 22] Internet-Draft Packet Forwarding July 1993 +------------+ | waiting for|<------------------------------+ | MHLI ack | | +------------+ | | ^ receive MHLI | receive MHLI ack | | without Autonomous | ---------------- | | -------------------- | | | update address table | | | | receive MHLI | | +-----+ receive a normal packet | with Autonomous v | v | for the home MH | -------------------- +------------+ | ------------------------ | update address table | forwarding |---+ send PT | +----------------------| mode | | | +------------+ | | migrate to home network | ^ receive MHLI | | (receive MHLI) | | without Autonomous | | ----------------------- | | --------------------------------- | | replace ARP entry for | | update address table | | the home MH | | replace ARP entry for the home MH | | send MHLI ack v | send MHLI ack | | +------------+ | | | initial | | | | state | | | +------------+ | | migrate to home network ^ | receive MHLI | | (receive MHLI) | | with Autonomous | | ----------------------- | | --------------------------------- | | replace ARP entry for | | update address table | | the home MH | | replace ARP entry for the home MH | | send MHLI ack | v send MHLI ack | | +-------------+ | | | autonomous |------------------------------+ | +--------------------| mode | receive MHLI without Autonomous | | +-------------+ ------------------------------- | | receive MHLI ack ^ | update address table | | ---------------- | | send MHLI to previous PFS | | | | | |receive MHLI | | receive a normal packet | | without Autonomous | | for the home MH | |-------------------- | | ----------------------- | |update address table | | send PT | |send MHLI to | v send MHLI to sender | | previous PFS +------------+ | +------------------->| waiting for| +--------------------->| MHLI ack | +------------+ Figure 11. State Diagram of a home PFS Expires 2 January 1994 [Page 23] Internet-Draft Packet Forwarding July 1993 +---------------+ | waiting for | | MHLI ack | +---------------+ | ^ | | receive PT receive MHLI ack | | -------------------------------- ---------------- | | forward it to home adr (send PT) | | send MHLI without MH's address v | +---------------+ | forwarding to | | home adr mode |----------+ |(initial state)| | +---------------+ | ^ | | receive MHLI | | receive PAS | receive MHLI without MH's adr | | ------------ | ------------- ------------------ | | send PAS ack | send MHLI ack send MHLI ack | | | | v | +-------------+ | | forwarding |<-----------+ | mode |<------+ receive MHLI +-------------+ | ------------- ^ | | | send MHLI ack | | +---------+ | | receive MHLI ack | | receive PT ---------------- | | ------------------------------------ | | forward it to new location (send PT) | | send MHLI | v +---------------+ | waiting for | | MHLI ack | +---------------+ Figure 12. State Diagram of an Autonomous Supporter (a PFS for visitor MHs) Expires 2 January 1994 [Page 24] Internet-Draft Packet Forwarding July 1993 5.5 Packet Transmission Parameters Two important transmission parameters for IPTP are the timeout interval and the retransmission count. The timeout interval is the length of time IPTP will wait before retransmitting a packet. The retransmission count is the number of times a packet will be resent. IPTP defines these parameters for all messages except "Packet Transmission" messages. IPTP "Packet Transmission" messages can be lost without a loss of correctness because IP makes no guarantee about reliable packet delivery. Reliable delivery is left to higher level protocols in the transport and network layers. For the other message types, we assume that the timeout interval will be tuned to specific implementations. The remaining issue, therefore, is the number of retransmissions. The "MH Location Information" message should be retransmitted an infinite number of times. If for any reason, such as a network failure, an MH cannot notify its home PFS of its new address the MH will become temporarily lost. Continuous retransmission guarantees that the time of the network partition will never exceed the transmission of the last "MH Location Information" message. If communication between the MH and PFS is ever possible again, then a packet will eventually get through, allowing hosts communicating with the MH to reestablish contact through the home PFS. The other packet types, "Ping Autonomous Supporter", and "Echo", should be retransmitted only a finite number of times. Loss of these packets may result in a less efficient routing, but will not be fatal. For instance, a host capable of autonomous mode communication may mistakenly use forwarding mode if a "Ping" message is lost. 6 Implementation Notes 6.1 Translation Tables Address Translation tables are maintained by PFSs, and by SHs and MHs using autonomous mode. All table entries contain the home address and the current temporary address of a MH. In addition, table entries in a home PFS will contain the address of the PFS in the MH's current temporary network. Table entries in SHs and MHs will contain the address of the MH's home PFS. PFSs are responsible for providing non-volatile storage for translation information. SH and MH tables are only caches for data managed by PFSs. An SH or an MH can easily refresh its tables by interacting with the appropriate PFS. Of course, a disasterous failure might cause a PFS to lose its translation information. If this occurs, the information must be recovered by inducing MHs to Expires 2 January 1994 [Page 25] Internet-Draft Packet Forwarding July 1993 resend "MH Location Information" messages. 6.2 Avoiding Redundant "MH Location Information" Messages In an environment where both forwarding mode and autonomous mode are utilized, a PFS might send unnecessary "MH Location Information" messages to SHs using forwarding mode. Because they are using forwarding mode, these SHs will ignore the "MH Location Information" messages. Packets from the SH to the MH will continue to be sent to the PFS, resulting in the generation of ineffective and unnecessary "MH Location Information" messages. To avoid this, a PFS should keep a list of hosts it serves that are using forwarding mode. The PFS can then refrain from sending "MH Location Information" messages to any host on this list. Hosts can be added to this list when the first "MH Location Information" message cannot be delivered to the SH. The failure can be detected either by an ICMP message that indicating that the destination port is unreachable or when the SH fails to acknowledge the "MH Location Information" message. 6.3 PFS Packet Interception In order to correctly forward packets for mobile hosts, a PFS must be able to intercept packets addressed to hosts that have migrated away from the local network. One possible implementation is to use promiscuous mode, if the the underlying interface supports it. Such a solution, however, may impose a substantial load as the PFS is forced to inspect every packet. A more attractive alternative is to use a proxy ARP. When a PFS receives a "MH Location Information" message from an MH, it broadcasts an ARP reply packet for the MH's home address. The reply packet specifies that the MH's IP address now resolves to the address of the PFS's physical interface. Subsequent packets addressed to the MH's home address will be received by the PFS. If a PFS is already forwarding packets for an MH, it responds as a proxy to any ARP requests for the MH's address. The ARP reply message indicates that packets destined for the home (IP) address of the MH should be physically (i.e. at the hardware address level) addressed to the PFS. Unfortunately, because of the need to reuse temporary IP addresses, this technique cannot be applied to a PFS acting as an autonomous supporter for a visiting MH. A visiting MH will use a temporary address. This address will eventually be reused when the visiting MH migrates to a new network. If the PFS issues a Proxy ARP for this address, packets intended for the new user of the address Expires 2 January 1994 [Page 26] Internet-Draft Packet Forwarding July 1993 might be lost. Temporary addresses must be reusable because of the limited number of address bits available. The consequence is that a PFS may only act as an autonomous supporter if it has a promiscuous interface on a broadcast medium that allows it to see all network traffic. 6.4 Adaptive Mode Selection An MH that transmits a "Ping Autonomous Supporter" message may have to wait some time for a local PFS to reply. This delay is passed to applications as additional latency introduced by MH migration. To avoid this problem, the MH may send the "MH Location Information" to the home PFS without the Autonomous flag set. After the MH finds a PFS which supports autonomous mode, it may resend "MH Location Information" message, this time with the Autonomous flag set. 6.5 Detection of Forwarding Loops If an MH is roaming among temporary networks where PFSs support autonomous mode, it is possible that forwarding relays will occur. To prevent a forwarding loop, the "Packet Forwarding" message contains a special counter. When a PFS forwards a packet for the first time, it sets the counter to an upper bound defined by the system. Before another PFS forwards the packet, it decrements the counter by 1 and it checks to see if the the value is zero. If the PFS finds the counter equal to zero, the packet is discarded. Otherwise the packet is forwarded normally. 6.6 Gateway Packet Filters For security reasons, some gateways filter packets based on port numbers. Because an original packet is encapsulated in an IPTP packet in our approach, the gateways will check the IPTP port number. Such gateways will fail to filter out packets that might otherwise be objectionable because the packet filters do not see within the IPTP packet. Similarly, a filter applied to IPTP will remove all encapsulated packets, regardless of how the local system administrator feels about them. If the gateway host filters packets of specified port numbers and IPTP port number itself is not included in the port number list for filtering, the IPTP packet will pass through, even if the original packet in the IPTP packet should be filtered. On the other hand, if the gateway host makes packets of specified port numbers pass through and IPTP port number is not included in the list for passing, the IPTP packet will be filtered. One way to solve this problem is to redesign the IPTP packet format. Expires 2 January 1994 [Page 27] Internet-Draft Packet Forwarding July 1993 "Packet Transmission" messages could reflect the packet type in a newly defined IP option field rather than be indicated in the port number field. 6.7 Handling IP options When a PFS encapsulates a packet, it should copy IP options of the packet to the encapsulated packet. When an MH decapsulates the packet, it should restore IP options of the packet to the original packet. 7 Acknowledgement The description of authentication is almost fully derived from Columbia University's draft "Protocols for Supporting Mobile IP Hosts"[3] and IBM's draft "Support for Mobility with Connectionless Network Layer Protocols(Transport Layer Transparency)"[4]. 8 Authors' Addresses Hiromi Wada Information Systems Research Laboratory Matsushita Electric Industrial Co., Ltd. 1006 Kadoma, Kadoma-shi, Osaka, 571 JAPAN Internet : hwada@isl.mei.co.jp Phone : +81-6-906-2431 Fax : +81-6-906-5547 Tatsuya Ohnishi Information Systems Research Laboratory Matsushita Electric Industrial Co., Ltd. 1006 Kadoma, Kadoma-shi, Osaka, 571 JAPAN Internet : ohnishi@isl.mei.co.jp Phone : +81-6-906-2431 Fax : +81-6-906-5547 Brian Marsh Matsushita Information Technology Laboratory 182 Nassau St, 3rd floor Princeton, NJ 08542 Internet : marsh@mitl.com Expires 2 January 1994 [Page 28] Internet-Draft Packet Forwarding July 1993 References 1. H.Wada, T.Yozawa, T.Ohnishi, and Y.Tanaka, "Mobile Computing Environment Based on Internet Packet Forwarding", 1993 Winter USENIX 2. R.Droms, "Dynamic Host Configuration Protocol", Internet Engineering Task Force, INTERNET-DRAFT, November 1992 3. J.Ioannidis, D.Duchamp, G.Q.Maguire Jr, and S.Deering, "Protocols for Supporting Mobile IP Hosts", Internet Engineering Task Force, INTERNET-DRAFT, June 1992 4. C.Perkins and Y.Rekhter, "Support for Mobility with Connectionless Network Layer Protocols(Transport Layer Transparency)", Internet Engineering Task Force, INTERNET-DRAFT, January 1993 5. F.Teraoka, "VIP:IP Extentions for Host Migration Transparency", Internet Engineering Task Force, INTERNET-DRAFT, Novenber 1992 Expires 2 January 1994 [Page 29] Internet-Draft Packet Forwarding July 1993 TABLE OF CONTENTS 1 Introduction 1 1.1 Goals 2 1.2 Basic Concept 2 1.3 Overview 3 2 Addressing 3 3 Packet Forwarding 4 3.1 Forwarding Mode 4 3.2 Autonomous Mode 5 3.2.1 SH Transmission 6 3.2.2 Autonomous Supporter Transmission 7 4 Location Information Management 8 4.1 MH Migration/PFS Notification 8 4.2 Autonomous Sender Notification 10 4.2.1 Packets to the Home Address 10 4.2.2 Packets from an AS 11 4.2.3 Packets from a Migrated MH 12 4.3 Packets to an Obsolete Temporary Address 13 5 Internet Packet Transmission Protocol(IPTP) 15 5.1 Message Type 15 5.2 Parameters 16 5.3 Packet Format 19 5.4 State Diagrams 21 5.5 Packet Transmission Parameters 25 6 Implementation Notes 25 6.1 Translation Tables 25 6.2 Avoiding Redundant "MH Location Information" Messages 26 6.3 PFS Packet Interception 26 6.4 Adaptive Mode Selection 27 6.5 Detection of Forwarding Loops 27 6.6 Gateway Packet Filters 27 6.7 Handling IP options 28 7 Acknowledgement 28 8 Authors' Addresses 28 Expires 2 January 1994 [Page i] Internet-Draft Packet Forwarding July 1993 FIGURES Figure 1. Forwarding Mode 5 Figure 2. Autonomous Mode 6 Figure 3. Forwarding mode by an autonomous supporter PFS 7 Figure 4. Location information distribution 9 Figure 5. Packets to the Home Address 11 Figure 6. Packets from an AS 12 Figure 7. Packets from a Migrated MH 13 Figure 8. Packets to an Obsolete Temporary Address 14 Figure 9. State diagram of an MH 21 Figure 10. State diagram of an SH 23 Figure 11. State diagram of a home PFS 23 Figure 12. State diagram of an Autonomous Supporter 24 Expires 2 January 1994 [Page ii]