P. Estrela Internet Draft A. Grilo T. Vazao M. Nunes Document: draft-estrela-timip-01.txt INESC Expires: July 2003 January 2003 Terminal Independent Mobile IP (TIMIP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract All IP mobility protocols currently proposed on the IETF assume that the mobile nodes always have a mobility-aware IP stack, which is still a scenario that can seldom be found nowadays. Most terminals, including the laptops and PDAs which most would benefit of the mobility support, still use legacy IP stacks, limiting their use to layer-2 mobility within a single IP subnet. This document presents Terminal Independent Mobile IP (TIMIP), which supports IP micro-mobility of all possible existing legacy IP terminals, while fully interoperating with Mobile IP to provide macromobility across IP subnets for all terminals. Table of Contents 1. Changes/Additions from version 00...............................2 2. Introduction....................................................2 3. Applicability...................................................3 4. Terminology.....................................................3 5. Architecture....................................................4 Estrela Page [1] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) 6. Registration....................................................5 7. Power-up........................................................6 8. Micromobility...................................................8 9. Macromobility..................................................10 9.1. Macromobility for LMNs......................................10 9.2. Macromobility for MIP terminals.............................11 10. Message Formats...............................................12 11. Generic Detection Algorithm...................................13 12. DHCP support for automatic registration.......................13 13. References....................................................14 14. Author's Addresses............................................14 1. Changes/Additions from version 00 - Precise definition of message formats used in TIMIP signaling. - TIMIP now supports DHCP protocol for automatic registrations. - Definition of a Generic Handoff detection procedure for use when layer-2 does not offer sufficient information about the movement of the Legacy Terminals. - A exponential backoff timeout refresh behavior was added to reduce the number of refreshes on the wireless medium. - Several important clarifications and improvements throughout the whole document, and other minor corrections. 2. Introduction All IP mobility protocols currently proposed on the IETF assume that the mobile nodes always have a mobility-aware IP stack, which is still a scenario that can seldom be found nowadays. Most terminals, including the laptops and PDAs which most would benefit of the mobility support, still use legacy IP stacks, limiting their use to layer-2 mobility within a single IP subnet. Currently, there exists evidence that the need of special mobile stacks for the terminals may be holding the generalization of this service, because of the effort needed to change the already existing IP terminals for the new technology. Particularly, this need has already been identified regarding the IP mobility deployment in wireless technologies (see section 4, “Registration requests generated on behalf of a mobile node” of [8]). TIMIP [1] is a micromobility architecture that allows Mobile Nodes with legacy IP stacks to roam within an IP domain, thus enabling the IP mobility of all existing IP terminals, by explicitly not requiring any processing related to the mobility service on the mobile terminals. Between TIMIP domains, the movement of the terminals is supported with custom macromobility mechanisms based on and fully compatible with standard Mobile IP [2]. Estrela [Page 2] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) The main features of TIMIP are listed below, which includes both novel and similar features of other micromobility architectures, namely CIP [3] and HAWAII [4]: - TIMIP does not require changes to the IP protocol stack of mobile nodes, for both micromobility or macromobility support, thus supporting any existing IP terminal. - TIMIP specifically promotes the use of data link layer information for terminal power-up and movement detection on the network side, for detection performance. When the layer-2 does not offer sufficient information, a generic handoff detection algorithm is used. - Refreshing of routing paths is performed by data packets sent by the mobile terminals, with refreshing being employed only when no traffic is detected at the routers for a certain time interval (similar to CIP). - Routing reconfiguration during handoff within a TIMIP domain only needs to change the routing tables of the Access Routers located in the shortest path between the Access Points involved (similar to HAWAII). - Routing of data packets within a TIMIP domain does not need to reach the Access Network Gateway, involving only the Access Routers located in the shortest path between the sender and the receiver (similar to HAWAII). 3. Applicability TIMIP is applicable within LANs, and possibly larger networks up to IP domains, that form one subnet only. To provide mobility between subnets (macromobility), Mobile IP compatible mechanisms should be present on the Access Network Gateway of each TIMIP domain. It is expected that the data link layer of the Access Points is able to perform terminal power-up and movement detection, and able to notify the TIMIP layer. If this facility is not available, a simple handoff detection algorithm is used. It is also assumed that the Access Routers of the TIMIP domain form a logical tree, with the Access Network Gateway located at the top. 4. Terminology Access Network An IP network that includes one or more Access Routers, and an Access Network Gateway. Access Network Gateway (ANG) An Access Router that separates the Access Network from a third party network. Access Point (AP) Estrela [Page 3] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) An Access Router that offers layer-2 connectivity to Mobile Nodes. This layer-2 can be based on any possible technology, and is depicted in this document, without loss of generality, as a wireless link, as this kind of access is the most interesting one for the use of mobility mechanisms. Access Router (AR) An IP router residing in an Access Network and connected to one or more access routers. An AR offers connectivity to Mobile Nodes by means of IP routing. The router may include intelligence beyond simple forwarding service offered by ordinary IP routers. Some Access Routers can be Access Points, and one of them is the ANG. Legacy Mobile Node (LMN) A Mobile Node whose IP layer is not aware of mobility. The precise requirements of the LMNs are the ones necessary for Internet Hosts, described in [9]. Mobile Node (MN) An IP end-node capable of changing its point of attachment to the network. Subnet A range of IP addresses sharing a common prefix. 5. Architecture A TIMIP domain is an IP subnet organized as a logical tree of Access Routers (ARs) whose root router is the Access Network Gateway (ANG). The Access Routers can also be layer-2 Access Points (APs), which interface directly with the MNs through the wireless medium (WM). The architectural diagram of TIMIP is depicted in Figure 1. Estrela [Page 4] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) | +-+ +-----+ +-----+ [] <--> | | -------| AR5 |-------------------| | MN +-+ /+-----+ /| ANG |- AP/AR1 / / | | / / +-----+ +-+ / / | |---- / +-+ / AP/AR2 / / +-+ +-----+ / | |--------| AR6 |---------- +-+ /+-----+ AP/AR3 / / +-+ / | |---- +-+ AP/AR4 Figure 1: Architectural Diagram of a TIMIP domain. As a Legacy Mobile Node (LMN) has a legacy IP stack and cannot issue any signaling during handoff, handoff detection by the AR relies on notification from layer-2, or from a Generic Detection Algorithm. This notification triggers routing reconfiguration of the TIMIP domain, leading to routing table updating at the ARs. 6. Registration In order to allow attachment of an LMN to a TIMIP domain, the LMN must be previously registered at the ANG. This is accomplished offline through management procedures, or automatically using the DHCP protocol (see section 11). For each LMN recognized in a TIMIP domain, registration information consists on the following: - MAC address of the LMN; - IP Address of the LMN; - MIP capability; - IP address of the MIP Home Agent; - Authentication Key; - Authentication option. Estrela [Page 5] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) The MIP capability parameter specifies if MIP is required, either implemented at the ANG on behalf of legacy terminal (surrogate MIP) or implemented at the terminal itself. If the terminal has a legacy IP protocol stack, the next two parameters specify respectively the IP address of its Home Agent and the authentication key to be used between the terminal and the ANG when the authentication option is turned on. It should be noted that TIMIP authentication is mandatory for macromobility scenarios for both MIP and legacy terminals. The IP address of the Home Agent is not used when the terminal implements MIP, as the terminal itself is responsible for registering with the Home Agent, bypassing the ANG. Once this data is configured at the ANG, it is forwarded to the APs (except the authentication key) so that they are able to know the IP address of newly associated terminals based on their MAC address provided by layer-2 as explained below. 7. Power-up When a terminal firstly appears in a TIMIP domain, a routing path is created along the hierarchy of ARs. Consider the scenario in Figure 1. When the MN attaches itself to AR1, the creation of the routing path takes the following steps: 1. The MT performs a layer-2 association with an AP that belongs to the local TIMIP domain. 2. At the AP, the IP layer is notified about the presence of the MT in its wireless interface, by means of a primitive containing the detected MAC address of the terminal, triggering the routing reconfiguration procedure. This primitive can be generated exclusively by the Layer-2 itself, or by a Generic Detection Algorithm to be described later. When this happens, the MAC address is matched against the terminal registration information broadcasted by the ANG and the respective IP address is found. As the New AP has currently no routing table entry for the MT, the routing table is updated with the addition of this new entry. 3. The New AP sends a TIMIP RoutingUpdate message up to the AR at hierarchical level 2. This AR acknowledges with a RoutingUpdateAck message, and updates its routing table accordingly with the addition of a new entry relative to the MT. This entry points to the source of the RoutingUpdate message – the AP1 - in order to specify the path through which the terminal can be reached. Estrela [Page 6] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) 4. Exchange of RoutingUpdate/RoutingUpdateAck messages climbs up the hierarchy levels. At each level, the routing table is updated with the creation of a new entry relative to the MT. This entry always points to the source of the RoutingUpdate message in order to specify the path through which the MT can be reached, by means of the next node information for each terminal. 5. Exchange of RoutingUpdate/RoutingUpdateAck messages reaches the ANG, completing the creation of the new routing path. The MT is now reachable through the routing path established by the above procedures. The ARs that do not belong to this path have no routing entry for the MT. At these ARs, all packets destined to the MT are forwarded up the hierarchy of routers by default. All packets that arrive at an AR whose routing table has an entry to the destination, are forwarded down the hierarchy of routers until they reach the radio interface in which the MT is located. As thus, for packets destined to a terminal located in the same TIMIP domain as the source (intra-domain traffic), only in the worst case reach the ANG. The RoutingUpdate messages are coupled with their respective RoutingUpdateAck to ensure that the network is able to have the correct localization information of the LMNs, even when these signalization messages are lost. As thus, when a node does not receive the acknowledge message of an update within a certain amount of time (default 1 second), it automatically resends its update message to the peer. These messages include a timestamp generated at the New AP on the moment of detection (primitive reception). As in TIMIP all APs are synchronized by means of the Network Time Protocol (NTP) [5], this guarantees consistency even when the MT moves faster than the route reconfiguration, because It should also be noted that the routing path is soft-state and after its establishment, it is refreshed by the data packets sent by the LMN, being sufficient to be received for routing through the interface that the terminal is registered. Using this facility, the state maintaining of active terminals does not add any overhead. Nevertheless, as the packets are routed within the TIMIP domain, some of the ARs may not be refreshed. When this occurs, the routing entry for the MT becomes invalid after a predefined timeout, that is subject to a backoff procedure. The AR where the timer expired starts to send ICMP EchoRequest messages to the terminal, filling the source address field of the IP header with the IP address of the ANG. This forces the MT to reply with EchoReply messages destined to the ANG, which will refresh all the routing path within the TIMIP domain. If this Reply message is properly received with the current timeout, then its value is doubled, up to a predefined maximum; on the other hard, if no reply is received, then the value is divided by two up to a predefined minimum, that forces the routing entry for the LMN to be removed. Estrela [Page 7] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) This basic TIMIP configuration is adequate to have micromobility in wireless access networks where security is not an issue. Nevertheless, just like in other unprotected IP networks, it allows MTs to power-on with false MAC and IP addresses. In order to avoid this, a minimal security functionality must be implemented at the MT itself. However, this can be done in the application layer with no need to change the IP protocol stack. When the authentication option is used, it is assumed that the MT runs a special security application that uses a database of authentication keys for the different TIMIP domains in which the MT is allowed to power-up. This database is indexed by the IP addresses of the ANGs that are the root of the respective networks. The authentication takes place in step 2 of the power-on procedure, immediately after layer-2 notifies the IP layer of the AP about the association of the MT. The AP sends an SignatureRequest message to a well known UDP port in the MT. This message carries , where rand is a random value and the timestamp is an NTP formatted 64-bit value. The same message is sent to the ANG. Both the MT and the ANG answer the AP with a SignatureReply message containing the same fields present in the SignatureRequest message, plus its 128-bit MD5 message digest [6] calculated with the authentication key of the MT for this network. The latter is only known by the MT (based on the authentication key database and the IP address of the ANG) and the ANG (based on the registration information). The AP compares the signatures of the two SignatureReply messages, and proceeds with the routing reconfiguration procedures only in case there is a match. 8. Micromobility An example of handoff between two APs that belong to the same access subnetwork is depicted in Figure 2. Estrela [Page 8] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) | +-+ +-----+ +-----+ [] <--> | | -------| AR5 |-------------------| | MN +-+ /+-----+ /| ANG |- AP/AR1 / / | | | / / +-----+ | +-+ / / | | |---- / (handoff)V +-+ / AP/AR2 / / +-+ +-----+ / | |--------| AR6 |---------- +-+ /+-----+ AP/AR3 / / +-+ / | |---- +-+ AP/AR4 Figure 2: Handoff between APs. For the Handoff procedure, the first four steps are the exact same as the Power-up case. The remaining steps are the following: 5. Exchange of RoutingUpdate/RoutingUpdateAck messages climbs up the hierarchy levels, until the crossover AR (the AR that belongs simultaneously to the old path and to the new path) is reached (in the example above, node AR5). Now that the new routing path is completely created, the old path must be deleted. This procedure starts when the crossover AR sends a RoutingUpdate message addressed to the MT through the old routing path. The AR that receives the message realizes that the MT is no longer accessible through it, updates its routing path by deleting the entry that corresponds to the MT and replies with a RoutingUpdateAck message. 6. Exchange of RoutingUpdate/RoutingUpdateAck messages goes down the AR tree following the old path, until the Old AP is reached. At each level, the node receives the update from its root peer, and the each routing table is updated by deleting the entry relative to the MT. In a normal shared media LAN, when a terminal has a packet destined to an address within the same IP subnet (which is known through the analysis of the IP address prefix), it tries to obtain the MAC address of the destination through an ARP request and send the packet directly to it. In TIMIP, as the APs are also ARs, if the destination is associated to a different AP, the ARP request will never be answered. Estrela [Page 9] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) In order to prevent this situation, the terminal is forced by configuration (either manually or automatically by DHCP) to send all packets to the IP Gateway of the local subnetwork through it’s current AP. This is accomplished by setting the subnetwork mask configuration to a special value of all bits at “one” (255.255.255.255), and the default GW the current ANG of this AN. When the terminal sends an ARP request to obtain the MAC address of the Gateway, the local AP answers with its own MAC address, performing a proxy ARP mechanism on behalf of the ANG (as described on standard MIP procedures [2]), which is sufficient to receive the packets generated on the terminal for subsequent routing with the rules depicted above. 9. Macromobility TIMIP relies on MIP to support macromobility. The ANG is the HA for MNs whose home network is its TIMIP domain. As LMNs do not implement MIP, the ANG implements all the needed functionality on their behalf. On the other hand, when a foreign MN supports MIP, the ANG acts as a Foreign Agent for the local TIMIP domain. 9.1. Macromobility for LMNs When a MT enters a TIMIP domain different from its current location, the terminal is locally authenticated and a routing path is created between the terminal and the ANG. Packets are then sent/received to/from the outside through the ANG. If the home network of the MT is a different MIP domain, its HA must be notified so that packets can be correctly routed through an IP tunnel established from the HA to the FA located at the ANG. After consulting the registration information of the MT (namely the IP address of the HA and the MIP capability), the ANG realizes that it is a foreign MT and that it does not implement MIP. Consequently, the ANG must act as a surrogate MIP element on behalf of the MT, generating all MIP signaling as the MT would (see section 4 of [8]). Firstly it has to notify the HA about the MT’s new location and CoAddr by means of a MIP Registration Request message, which requires authentication using the authentication key between the MT and the HA. As the ANG does not know this key, it is the MT that must sign the message. The ANG sends the MT an AuthenticationRequest message containing authenticated by the ANG with MD5(K1, AuthenticationRequest), where K1 is the authentication key between the MT and ANG for this TIMIP domain. The MT finds K1 in the key database based on the IP address of the ANG and obtains the authentication key of his home network (K2) in the key database, based on the IP address of the HA. Estrela [Page 10] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) It then answers with an AuthenticationReply message containing . This message is also authenticated by the terminal with MD5(K1, AuthenticationReply). The ANG can now send a correctly authenticated MIP Registration Request message to the HA adding the message digest provided by the MT as a Mobile-Home Authentication Extension field. The HA answers with an authenticated MIP Registration Reply message, which has a message digest MD5(K2, MIP Registration Reply) appended as a Mobile-Home Authentication Extension field. In order to verify the identity of the HA, the ANG must again rely on the MT. It sends an AuthenticationRequest message to the MT, containing , authenticated with MD5(K1, Authentication Request). The terminal answers with an AuthenticationReply message containing . If the MD5 digest of the MIP Registration Reply provided by the MT matches that present in the Mobile-Home Authentication Extension of the Registration Reply message sent by the HA, the ANG can resume communication with the HA. After the communication with the HA is established, the ANG de- encapsulates the tunneled IP packets that come from the HA addressed to the MT and forwards them normally to the MT according to the routing path established in the AR tree. Packets generated by the MT are routed normally according to the same procedures described above for micromobility. In this situation, the subsequent handoff between APs within the foreign TIMIP domain are dealt with TIMIP micromobility procedures only. As already seen, all traffic that crosses the boundary of the TIMIP domain must pass through the ANG, which is the IP Gateway to the core network. Nevertheless, whenever an MT moves to a different domain, the IP address of the ANG changes. In order to keep consistency, the MT would have to change its IP Gateway configuration at each handoff between TIMIP domains, as otherwise the ARP requests to obtain the MAC address of the IP Gateway would not be answered by the APs. To address this situation, the MTs are configured with a well-known ANG IP address recognized by all APs of all TIMIP domains. The latter broadcast gratuitous ARP messages associating their own MAC addresses with the well-known ANG IP address each time a terminal performs an association, and performing proxy ARP for this well- known ANG IP address as described before. 9.2. Macromobility for MIP terminals Estrela [Page 11] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) When the MT supports MIP but belongs to a different domain, the ANG plays the role of FA. The MT powers-on in the same way as legacy MTs in the TIMIP domain. Once this is completed, the MIP signaling starts. The ANG broadcasts RFC 1256 [7] Router Advertisement messages periodically, specifying its IP address as the MIP CoAddr. In order to haste the process, the MT can request the advertisement by broadcasting a Router Solicitation message, which is then forwarded by the AP to the ANG. After the MT receives a Router Advertisement message, it notifies its HA about the CoAddr through the ANG. The HA is then able to forward the incoming packets to the CoAddr through an IP tunnel. The ANG de-encapsulates the IP packets and forwards them normally to the MT according to the routing path established in the AR tree. Packets generated by the MT are also routed normally within the TIMIP domain. Handoff between APs within the foreign TIMIP domain are dealt with TIMIP micromobility procedures only (see above) as the FA is always the same (i.e. the ANG). It should be noted that in this case it is the MT itself that authenticates the MIP messages when communicating with the HA. 10. Message Formats In this section, we discuss the message formats for the TIMIP messages sent between the ARs of the AN. These messages are sent on standard ICMP protocol, extending it to special usage by the ARs, with a private ICMP_Type that is exclusive for the use of the TIMI Protocol. Currently, there is only two message types defined – RoutingUpdate and RoutingUpdateAck – to be used according the procedures outlined on the previous sections. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMP_type | ICMP_code | ICMP_CheckSum + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Legacy Terminal Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ICMP_Type Exclusive value for the TIMIP protocol on each AN (official value T.B.D.) ICMP_Code 1 (Routing Update), 2 (Routing Update Ack) LT Address IP of the Legacy Terminal that this update Estrela [Page 12] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) refers to. TimeStamp Timestamp of Detection of the LT on the AP formatted in Network Time Protocol [5]. 11. Generic Detection Algorithm The primary means of detection of the movements of the terminals is by means of layer-2 information, that can easily be derived from the specific mechanisms of most wireless technologies. However, when TIMIP is to be used in technologies unable to derive such information, a Generic detection procedure is used, that is similar to the well known “MAC learning” algorithm. In this method, the AP continuously receives all messages transmitted to the wireless medium, either by promiscuous scanning or other means, receiving the layer-2 MAC frames with the MAC sender information. The AP maintains a cache of known MAC stations present in the area, which is enough to detect the arrival of a new station. Consequently, when a LMN connects to an AP, the first packet it sends will be interpreted by the AP as an arrival, triggering the primitive that launches the micro-mobility routing procedures. 12. DHCP support for automatic registration When a LMN is roaming inside an AN, each AP already knows the specific details about this terminal, in particular its MAC and IP addresses. These details can be entered offline trough management procedures, or automatically if the LMN supports the DHCP auto- configuration protocol [10]. For this feature, the ANG implements a DHCP server that manages the entire IP address pool of this AN, and the remaining ARs implement DHCP relay agents functionality (thus, there exists only one DHCP server per AN). When the terminal enters the TIMIP domain for the first time (see Figure 1), the TIMIP power-up procedure is delayed until the DHCP procedure is completed. This procedure uses the standard DHCP messages (discover, offer, request and ack) through the relay agents as defined in [10], resulting on the automatic assignment of an IP address to the LMN. However, the DHCP operation also provides the automatic registration of the terminal on the network. As the LMN identifies itself with his own MAC address, the ANG is able to add a new registration entry to the TIMIP database containing the MAC and IP addresses, and to broadcast this information to all ARs on the network. Estrela [Page 13] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) This way, after the DHCP, the TIMIP power-up operation is able to be performed as defined above, because all APs will have the necessary information regarding the terminal. It should be noted that the DHCP operation only happens when the terminal firstly enters a IP domain, so that subsequent handoffs between APs within the TIMIP domain are dealt with TIMIP micromobility procedures only (see Figure 2). 13. References 1 Grilo A., Estrela P., Nunes M., Terminal Independent Mobility for IP (TIMIP)”, IEEE Communications, Vol. 39 Nº12, December 2001. 2 Perkins C. (Editor), "IP Mobility Support for IPv4" (Proposed Standard), RFC 3320, IETF, January 2002. 3 A. Campbell et al, “Design, Implementation and Evaluation of Cellular IP”, IEEE Personal Communications, Vol. 7 Nº4, August 2000. 4 R. Ramjee et al, “IP-Based Access Network Infrastructure for Next-Generation Wireless Data Networks”, IEEE Personal Communications, Vol. 7 Nº4, August 2000. 5 Mills D. “Network Time Protocol (Version 3), Specification, Implementation and Analysis”, RFC 1305, IETF, March 1992. 6 Rivest R., “The MD5 Message-Digest Algorithm”, RFC 1321, IETF, April 1992. 7 Deering S. (Editor), “ICMP Router Discovery Messages”, RFC 1256, IETF, September 1991. 8 E. Gustafsson, ed., “Requirements on Mobile IP from a Cellular Perspective”, Internet draft, draft-ietf-mobileip-cellular- requirements-02, work in progress, June 1999. 9 R. Braden, Ed., “Requirements for Internet Hosts -- Communication Layers”, RFC 1122, October 1989 10 R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 1997. 14. Author's Addresses All comments are welcome, and should be directed to the authors of the present draft: Pedro Estrela INESC Rua Alves Redol, N.9 Phone: +351-213100324 Estrela [Page 14] Internet-draft Terminal Independent January 2003 Mobility for IP (TIMIP) 1000-029 Lisboa, Portugal Email: pedro.estrela@inesc.pt António Grilo INESC Rua Alves Redol, N.9 Phone: +351-213100226 1000-029 Lisboa, Portugal Email: antonio.grilo@inov.pt Teresa Vazao INESC Rua Alves Redol, N.9 Phone: +351-213100286 1000-029 Lisboa, Portugal Email: teresa.vazao@inesc.pt Mário Nunes INESC Rua Alves Redol, N.9 Phone: +351-213100256 1000-029 Lisboa, Portugal Email: mario.nunes@inesc.pt Estrela [Page 15]