Internet Engineering Task Force S.Thuel / L.Salgarelli / R.Ramjee / INTERNET-DRAFT K.Varadhan / T.LaPorta draft-thuel-mobileip-tt-00.txt Bell Labs - Lucent Technologies Date: 19 June 2000 Expires: 19 December 2000 Dynamic Home Addressing in Mobile IP using Transient Tunnels Status of this memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. 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 Dynamic home addressing has lately become a popular and viable approach for configuring mobile IP hosts. This draft introduces a method for these hosts to dynamically acquire a home address through DHCP when powering up in a foreign network, referred to as the Transient Tunneling (TT) procedure. Our procedure solves the problem that mobile hosts cannot rely on conventional broadcasting Thuel et al. Expires 12/00 [Page 1] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 procedures to properly discover an addressing server in their home network. While leveraging the growing DHCP code-base, our procedure requires no changes to protocol standards and only minor changes to server implementations. In addition, its impact on host power-up latency is acceptable in conventional wide-area networks scenarios. Alternative solutions are discussed along with other issues related to dynamic addressing on mobile hosts such as wireless bandwidth usage. Table Of Contents: 1 Introduction 3 2 Mobility and DHCP: The Broadcasting Problem 4 3 Transient Tunneling Solution 6 4 Implementation Issues 9 4.1 Registration Latency ..................................... 9 4.2 Mobile Client ............................................ 10 4.3 Home Agent ............................................... 10 4.4 DHCP Server .............................................. 10 4.5 Private Addressing Support ............................... 11 4.6 Network Administration ................................... 11 5 Alternative Solutions 12 6 Other Issues 16 6.1 Efficient Wireless Bandwidth Usage ....................... 16 6.2 External Foreign Agents .................................. 18 7 Security considerations 18 8 Acknowledgements 19 Thuel et al. Expires 12/00 [Page 2] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 1 Introduction While the Mobile IP (M-IP) protocol [1] relies on the ability to configure the home and care-of addresses (COAs) of mobile hosts for mobility management, it does not dictate how they are to be obtained. Traditionally, mobile hosts have had a fixed home address that is statically configured. Recently, the trend has shifted to a dynamic home addressing model, where a configuration protocol enables these hosts to dynamically acquire and install a home address on power-up. Dynamic home addressing enables efficient management of addresses, which is critical in supporting wide-area wireless data users with millions of devices using a limited IPv4 address space. It also provides ease of configurability by replacing the burdensome task of manually configuring hosts with a more effective mechanism for address allocation. There are similar arguments to support the dynamic allocation of co-located care-of addresses (CCOAs), which are required every time the host experiences a handoff. (Unless otherwise stated, we assume that the CCOA option of M-IP is used instead of external Foreign Agents, or FAs. Since the CCOA option is the the more general of the two options, most of the discussion will apply to the external FA option as well. Differences regarding the use of FAs are discussed in Section 6.) DHCP is the current dynamic addressing and configuration protocol in widespread use on the Internet [2]. It not only enables hosts to acquire addresses but also other configuration options associated with the access network (e.g., netmask for subnet, domain name servers, directory servers, email servers, etc. [3]). As emerging and future client applications increasingly rely on network services, the ability to dynamically configure these services through options becomes important. This protocol is a popular tool for today's service providers to manage their addressing needs. It is likewise a natural candidate to support dynamic addressing on mobile hosts. However, since it was designed for fixed hosts, its use on mobile hosts presents a number of challenges. Many of DHCP's limitations in supporting host mobility have been well documented in the literature [4, 5, 6, 7]. The main issues concern its configuration latency, effective use of wireless bandwidth, and security. These issues are well known and there is on-going work to address them. One problem, however, that has been overlooked is that procedures for dynamic home addressing Thuel et al. Expires 12/00 [Page 3] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 based on DHCP do not always work. Specifically, mobile hosts that power up in a foreign network cannot contact addressing servers in their home network through broadcasting. The thrust of this memo is to describe this broadcasting problem and to provide a solution referred to as the Transient Tunneling (TT) procedure. The solution comprises a two- stage addressing procedure for mobile hosts that power up in a foreign network. It introduces the notion of an addressing element referred to as a bootstrapping agent co-located with a M-IP Home Agent for the temporary creation of a tunnel over which standard DHCP transactions take place. We illustrate the set of transactions needed for a host power-up in its home or in a foreign network. We discuss implementation issues and argue that the impact of our procedure on host power-up latency is acceptable. Finally, we discuss alternative solutions and other related issues concerning Transient Tunneling such as wireless bandwidth usage and security. Although other solutions may result in lower power-up latency overheads, our procedure is simple to implement, avoids the problems that plague its alternatives, and exhibits acceptable performance. TT requires no changes to protocol standards and minor changes to server implementations. In addition, it leverages the growing DHCP code-base with its embedded support for important and often necessary host configuration options beyond addressing. Note that the procedure is not needed for hosts powering up in their home network. However, power-ups in a foreign network, where it is applicable, are expected to be the more frequent case (e.g., use of M-IP for corporate access). The procedure is defined for IPv4, where the management of a limited address space is important. Although there is no reason why it cannot be used in the context of IPv6 as well, dynamic home addressing is less of a concern. Details regarding the use of Transient Tunneling under IPv6 are not discussed in this memo. 2 Mobility and DHCP: The Broadcasting Problem Consider a model where mobile hosts rely on DHCP to dynamically configure both their home address and their co-located COA. This implies that clients running on the host must acquire and maintain leases on both addresses. Let us refer to the clients for the home address and for the COA as Hclient and Fclient, respectively. Assume a mobile host powers up in its home network with no knowledge of an unexpired home address lease. Since it needs to Thuel et al. Expires 12/00 [Page 4] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 MH HOME DHCP RELAY HOME DHCP SERVER | | | | DHCPDISCOVER (bcast) | DHCPDISCOVER (bcast/ucast) | |------------------------>|--------------------------->| | DHCPOFFER (bcast) | DHCPOFFER (ucast) | |<------------------------|<---------------------------| | DHCPREQUEST (bcast) | DHCPREQUEST (ucast/bcast) | |------------------------>|--------------------------->| | DHCPACK (bcast) | DHCPACK (ucast) | |<------------------------|<---------------------------| Figure 1: Procedures for Mobile Host Power-Up at its Home Network. acquire one, it initiates the execution of Hclient, which must go through a full initialization (rather than a speedier reboot). Figure 1 shows the standard addressing transactions. Hclient attempts to contact a server by broadcasting a DISCOVER message on its local subnet. This is actually a limited broadcast message since it is destined to address 255.255.255.255. The message is received by a server, or a relay on that subnet that is configured to forward the message to a server elsewhere on the home network (the scenario shown involves a relay). When the message reaches the server, it responds with an OFFER that it either broadcasts on its subnet or unicasts to the relay that had forwarded it. Whether through the relay or directly from the server, the mobile host receives the message as a limited broadcast. Hclient then broadcasts a REQUEST, reaching the server directly or via the relay, as before. The server responds with an ACK, confirming the granting of a lease. The ACK reaches the host once again as a limited broadcast and Hclient concludes its lease acquisition by installing acquired state on the host's interface. Though not shown in the figure, Hclient periodically enters the lease maintenance stage where it sends renewals to its home server. As per the standard, no M-IP registrations are needed while the host is in its home network. Now let us consider the case where a host powers up in a foreign network. Once again, assume, without loss of generality, that the host holds no unexpired home address leases. If Hclient attempts to send a limited broadcast message in the hope of contacting a server that can grant it a home address, it will fail. Any upstream broadcast messages will be received by a local server or Thuel et al. Expires 12/00 [Page 5] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 relay which may offer an address from its own lease pool, not that of the host's home network. Hclient needs a way to contact its remote home server, as standard broadcasting procedures will not enable a proper server discovery. In brief, standard DHCP broadcasting procedures do not work for dynamic home addressing on mobile hosts that power up in a foreign network. Note that the acquisition or renewal of a COA by Fclient works according to standard procedures because the appropriate DHCP servers are local and may be reached through broadcasting. 3 Transient Tunneling Solution While there are many possible ways to bridge the gap between a mobile host powering up in a foreign network and its remote home DHCP server, the notion of an addressing agent for home address allocation coupled with the assistance of M-IP is attractive and conducive to a viable solution. In this section, we describe our Transient Tunneling(TT) solution. The general idea is to use: a) M-IP as the signaling mechanism for reaching the home network and triggering the acquisition of a home address; b) an addressing agent in the home network to allocate a temporary home address for the host; and c) DHCP to allocate a permanent home address and any other configuration state for the host. Variations in the design of the addressing agent and its interaction with M-IP and DHCP leads to other possible solutions, as discussed in Section 5. Our approach is as follows. On power-up, we assume a host is capable of determining whether it is in its home or in a foreign network. This location inference may be based on knowledge of its NAI, similar in format to a user email address (as specified in [8], a wireless link-layer identifier such as the Mobile Identification Number (MIN) can be mapped to a NAI). For example, a M-IP client on the host may listen for periodic advertisements from a home or foreign agent containing the domain name which it can then compare against its own NAI. Let us examine the message flows associated with the power-up procedures for a host that is powering up in a foreign network using Transient Tunneling. As shown in Figure 2, the host first needs to acquire a co-located COA so it spawns a DHCP client (Fclient). Once it acquires the COA, it sends a unicast M-IP registration message to its Home Agent (HA), assumed to be known through static configuration or some other means such as dynamic home agent address resolution [1]. The registration message contains the host's COA Thuel et al. Expires 12/00 [Page 6] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 FOREIGN FOREIGN M-IP HOME DHCP DHCP HOME DHCP MH RELAY SERVER AGENT SERVER | | | | | / | DISCOVER | DISCOVER | | | | |---------->|----------->| | | Acquire | | . | . | | | COA | | . | . | | | | | ACK | ACK | | | \ |<----------|<-----------| | | / | | | | | M-IP | | M-IP REGISTRATION (wo/ home address) | | Client | |------------------------------------->| | Reg. | | M-IP REPLY (w/10.* home address) | | \ |<-------------------------------------| | / | | | | | | | DHCP DISCOVER | |DHCP DISCOVER | Acquire | |=====================================>|------------->| Public | | . | . | | | Home | | . | . | | | Address | | | DHCP ACK | DHCP ACK | | |<=====================================|<-------------| \ | | | | | / | M-IP DE-REGISTRATION (of 10.*) | | M-IP | |------------------------------------->| | Client | | | | M-IP REPLY | | De-reg. \ |<-------------------------------------| | / | | | | | M-IP | | M-IP REGISTRATION (of public address)| | Client | |------------------------------------->| | Reg. | | | | M-IP REPLY | | \ |<-------------------------------------| | Figure 2: Transient Tunneling procedure for a Mobile Host Power-Up in a Foreign Network. Thuel et al. Expires 12/00 [Page 7] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 and its NAI, but no home address. When the HA receives the registration message and notices that the home address is missing, it contacts a local addressing agent to acquire a home address on behalf of the host. We investigated several designs for the addressing agent, differing in implementation complexity. Due to its simplicity, we chose the design of a lightweight addressing agent referred to as a bootstrapping agent and placed it on the M-IP HA. This bootstrapping agent disburses temporary home addresses from a pool of private IP addresses in the class 10.*. Once a 10.* address is assigned, the HA uses it to set up a tunnel to the COA of the host. The HA unicasts a registration reply message containing the 10.* address back to the host. On receipt, the host sets up its end of the tunnel. Then Hclient is initialized on the host and launches a standard set of transactions needed to acquire a home address and other configuration options through the transient tunnel (highlighted with thicker arrows in the figure). All Hclient messages must be reverse tunneled through the HA to ensure that they are not received by any local DHCP servers or relays. Reverse tunneled messages are forwarded on the home subnet by the receiving HA, so that a home server or relay receives them. Similarly, replies sent by a home server or relay are tunneled to the remote host. Using this transient tunnel, Hclient successfully acquires an address (and other requested configuration state) from a home server without concerns about broadcasting. After this bootstrapping phase, the 10.* address should be released, and its associated tunnel is torn down and replaced with a tunnel terminating at the DHCP-granted home address. This entails sending a M-IP de-registration message from the host to the HA, followed by a registration containing the valid home address. Alternatively, the 10.* address could have a short lease (in the order of 10 seconds) and be allowed to time-out. Note that lease renewals may also be broadcast since they are reverse-tunneled to the home network. For this procedure to work, the broadcast bit options in DHCP and M-IP must be set. The broadcast "B" bit in the flags field of DHCP query messages must be set by the clients to ensure that the replies from the server or relay in the home network reach the client on the host while it is in the foreign network. Existing implementations of DHCP clients such as on Microsoft Windows and ISC's implementation for UNIX always set the broadcast bit by default. By setting this bit, the client informs the server or Thuel et al. Expires 12/00 [Page 8] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 relay to send any replies to the host as a broadcast using an IP broadcast address as the IP destination address and the link-layer broadcast address as the link-layer destination address. This ensures that the HA receives broadcast packets for subsequent forwarding to the host. The M-IP broadcast "B" bit in registration requests must also be set to ensure that the HA tunnels broadcast messages back to the host. A drawback in setting this bit is that the host may receive a flood of unwanted broadcast messages from its home network that are forwarded by its HA. This would result in a significant waste of wireless bandwidth. Strategies to address this issue are discussed in Section 6. To summarize, Transient Tunneling uses a bootstrapping addressing agent on the home agent to allocate private home addresses. This enables a temporary tunnel to be established to the host over which a standard, co-located DHCP client can acquire a lease from a pool of public (i.e., globally routable) home addresses. Once a home address is acquired, it is used to replace the temporary tunnel with a corresponding M-IP tunnel. 4 Implementation Issues 4.1 Registration Latency A key issue for the Transient Tunneling procedure to be effective is the latency that it introduces during a power-up in a foreign network. Five major terms contribute to this latency, namely: (1) the time required for the client to acquire a local IP address through DHCP; (2) the time to set up the transient-tunnel, by registering with the HA; (3) the time required to acquire a permanent home-address with DHCP through the transient-tunnel; (4) the time required to de-register the transient-tunnel; (5) the time to register with the HA using the newly acquired home-address. For term number 1, a typical DHCP procedure accounts for latencies in the order of 200ms (dominated by DHCP processing times at the server and the client). If we assume a round trip time (RTT) in the order of 100ms between the client and the home-network, term 2 should be in the order of 100ms (on a typical HA, processing time for a registration request is in the order of a few milliseconds). Thuel et al. Expires 12/00 [Page 9] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 Accounting for the RTT, term 3 should account for roughly 400ms, while terms 4 and 5 should be in the order of 100ms each. Therefore, the latency of typical power-ups in foreign-networks with transient tunneling should be in the order of 5 RTTs plus the latency of a local DHCP transaction (to acquire the COA), amounting to about 1 second. Considering that the TT procedure is carried out only during power-ups, and not during normal handoffs, this should be perfectly acceptable for a large spectrum of clients, from PDAs to laptop computers. 4.2 Mobile Client Current DHCP client implementations such as ISC's [9] allow a host with multiple network interfaces to dynamically configure each interface. Concurrently executing DHCP client state machines on the host acquire, install, and maintain configuration state for each interface without interfering with each other. However, the support of more than one DHCP client for a single interface requires that steps be taken to prevent or resolve any resource conflicts that may arise on the shared interface, such as during the installation of acquired configuration state. These potential conflicts raise implementation-dependent issues that must be addressed if mobile hosts are to dynamically configure their home and care-of address, typically on a single wireless interface. 4.3 Home Agent Since the mobile client uses the NAI to identify itself, the home-agent is required to be able to index all the Mobile IP requests using the NAI of the client, instead of its home-address. In any event, home-agents that conform to [10] are already required to support this modification of the basic operation as outlined in [1]. No other change to the home-agent is required to support the TT procedure. 4.4 DHCP Server The procedure described in this text has been specifically designed to work without requiring any change to current DHCP server implementations. Therefore, the TT procedure will be completely supported by existing DHCP server implementations conforming to [2]. Thuel et al. Expires 12/00 [Page 10] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 4.5 Private Addressing Support Transient Tunneling requires support for private addressing (10.*) only at the Mobile IP Home Agent and at the Foreign Agent (on the mobile host), which are the two ends of the transient tunnel. The temporary 10.* home address is never exposed to any correspondent host, so packets addressed to the mobile host with this private address could only originate at the Home Agent. The only packets that the Home Agent sends to the mobile host while the transient tunnel is set up are IP broadcast packets forwarded from the DHCP server. These packets are encapsulated with the mobile host's COA in the destination field of the outer IP header and contain the IP broadcast address in the destination field of the inner IP header. As a result, there is never a need for any routers between the Home Agent and the Foreign Agent nor in the Internet to support the routing of packets with private addresses. When the transient tunnel is set up, tunneled packets destined to the mobile host are routed based on its public COA. As soon as the transient tunnel is torn down, packets destined to the mobile host are sent to its public DHCP-acquired home address (and tunneled to the COA while in the host remains in a foreign network). If an external foreign agent is used rather than being on the mobile host, this agent must be able to forward packets destined to the private address for the mobile host, as discussed in Section 6.2. 4.6 Network Administration The transient tunneling procedure was designed to preserve DHCP as the sole entity controlling the management of public IP addresses within a network. The cost of achieving this is a configuration latency overhead due to extra control messages that must complete additional round trips. Although this configuration latency overhead should be an acceptable price to pay to maintain one administrative entity for IP address and configuration management, there may be cases where such a tradeoff may not be the preferred choice. For instance, some networks may need to serve many low-end, mobile IP hosts requiring only dynamic address assignment and no other configuration options. To configure these devices when they power up in a foreign network, it might be better to have the HA assign a public address in the initial registration message which the Thuel et al. Expires 12/00 [Page 11] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 host can keep without requiring the establishment of a transient tunnel. In this manner, the host configuration latency is kept to a single round trip. However, a number of challenges are introduced, including issues of renewing or releasing the address thus acquired and fragmentation of the IP address space between DHCP and the HA's. (These challenges are further elaborated in the following section.) In spite of its limitations, network administrators may opt to adopt this form of address assignment for such special hosts. If the temporary address assigned by the HA is drawn from a public address pool rather than from a pool of private addresses, the use of transient tunneling may be an optional choice made by the mobile host. A host with limited configuration needs may choose to keep the address offered by the HA as its permanent home address while other hosts may use the first offered address as a temporary one to setup the transient tunnel and acquire its permanent home address from DHCP. Support for this flexibility introduces challenges in the sizing of the address pools maintained by DHCP and by the HA that need to be further examined. 5 Alternative Solutions As stated earlier, there are several possible ways to design the addressing agent that is co-located with the Home Agent and for the mobile host to acquire other configuration parameters (i.e., options). Contrasting with the bootstrapping agent used in our transient tunneling procedure, we also examined the notions of an embedded agent and a proxy agent, leading to a set of four dynamic configuration solutions summarized in Table 1. Transient Tunneling corresponds to the first entry in the table while the other three solutions involve embedded and proxy agents, described as follows. As shown in Figure 3, in the embedded agent approach, the allocation of home addresses for hosts powering up away from home is completely up to an addressing agent embedded within a M-IP Home Agent (i.e., the embedded agent assumes the equivalent role of a DHCP server). The sophistication of this embedded agent may range from providing lightweight addressing support to a rich-featured DHCP-like server engine. In the case of a lightweight addressing agent, it differs from our bootstrapping agent because it manages a pool of addresses reserved from within the (limited) public address space of the Thuel et al. Expires 12/00 [Page 12] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 ---------------------- -------------------- ---------- | --> Embedded Agent | | --> Proxy Agent ----->| DHCP | | | | | | | | Server | | --> HA interface | | --> HA interface | ---------- ---------------------- -------------------- ^ ^ M-IP HOME ^ M-IP HOME | | AGENT | AGENT | | | / | | /--------------/ | | | v v v ( ~~~~~ ) ( ~~~~~ ) ( ) ( ) ( ACCESS ) ( ACCESS ) ( NETWORK ) ( NETWORK ) ( ) ( ) ~~~~~ ~~~~~ ^ ^ ^ | | | | | \ | MOBILE HOST | | MOBILE HOST ----------v-------------- ------v----|--------- | -> M-IP Client | | -- M-IP|Client | | | | | | v | | -> Addressing Client | | -> DHCP Client | ------------------------- --------------------- Figure 3: Architecture for an Embedded Agent (at left) versus a Proxy Agent (at right). Thuel et al. Expires 12/00 [Page 13] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 home network. A mobile host can acquire a home address from a HA equipped with this embedded agent, then acquire other configuration parameters from a DHCP server through a DHCPINFORM message. This is the third approach shown in Table 1. If, on the other hand, the HA has a rich-featured embedded agent, the mobile host may acquire all its configuration options through this agent, eliminating the need for DHCP services, as indicated in solution 4 of Table 1. Note that with embedded agents, the mobile host maintains all responsibility for processing equivalent to that of a typical DHCP client. SOURCE FOR SOURCE FOR HOME ADDRESS OTHER CONFIGURATION PARAMETERS -------------------------------------------------------------- 1) DHCP + HA_with_bootstrap DHCP (via DHCPREQUEST) 2) DHCP + HA_with_proxy DHCP (via DHCPREQUEST) 3) HA_with_embedded(light) DHCP (via DHCPINFORM) 4) HA_with_embedded(heavy) HA_with_embedded Table 1: Dynamic Configuration Solutions for a Mobile Host Power-Up in a Foreign Network. A major disadvantage of embedded agents is that they require substantial modifications to Home Agents, duplicating part or most of the functionality already provided by DHCP. In the case of a heavyweight embedded agent, the strong coupling between DHCP and M-IP also requires changes to the current M-IP specification to allow piggy-backing of configuration options in registration messages and creates the need for the M-IP Home Agent implementation to keep abreast of the changes in DHCP standards. Another challenging issue for any embedded agent is how to handle the configuration state it allocated to a mobile host after it returns to its home network. If the state is leased, the host client needs to indirectly trigger periodic renewals through Mobile IP registrations, although the standard specifies that no registrations should be sent while a host is at home. Procedures for address management for a scenario like this are described in [11]. If it is not leased, hard state created at the embedded agent must be explicitly removed when the mobile host no longer needs its home address (e.g., on shutdown). This suffers from typical rogue address problems. Finally, the lightweight embedded Thuel et al. Expires 12/00 [Page 14] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 agent suffers from limitations in the deployment of DHCPINFORM support in current DHCP server implementations. For example, both ISC's and Windows NT 4.0 DHCP servers do not support INFORM messages. In the proxy agent approach, the addressing agent acts like a surrogate DHCP client for the mobile host. It conducts a standard DHCP transaction in the home network to acquire a home address for the mobile (with no options) from a local server. Other configuration options are subsequently acquired through a DHCPREQUEST, as indicated in the second approach of Table 1. The proxy agent acquires an address on behalf of the mobile host by behaving like a co-located DHCP client and relay; appearing like a relay to servers residing on the home network while performing client processing. If the mobile host wishes to use its MAC address as its client identifier, then it must send this address in its registration request. The DHCP server uses the client identifier to create a lease entry in its database. Future lease renewals that are sent directly by the mobile host must use the same client identifier to ensure that the server finds the proper lease binding to renew for the host. With the DHCP client identifier option, the mobile host may opt to use its NAI as its client identifier. In this case, there is no need to extend the registration message to include the host's MAC address. Referring to Figure 3, the mobile host indirectly triggers proxy processing by sending a registration message on power-up. This message might be extended to contain its MAC (e.g., Ethernet) address, as discussed. On receipt of the registration message, the HA contacts the proxy agent with the proper client identifier for the mobile host. The proxy agent runs a client state machine modified to send and receive DHCP messages to and from servers as if they were passing through a relay. After the proxy acquires a home address, it halts the client state machine (i.e., aborts lease maintenance procedures) and forwards the address to the HA. The HA, in turn, creates a tunneling entry for the mobile using its known COA and acquired address, then forwards the home address to the host in its registration reply message. When the host receives the reply, it installs the home address on its interface, and sets up the tunnel endpoint managed by its co-located FA. With the tunnel in place, the host spawns a DHCP client and immediately renews its home address lease requesting (through a DHCPREQUEST) any other configuration options of interest. From then onwards, client messages go directly to the server without HA intervention. Thuel et al. Expires 12/00 [Page 15] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 In this manner, the proxy agent only manages home address acquisition while the client on the host carries out transactions for lease maintenance and the acquisition of configuration options. Unlike embedded agents, proxy agents rely on the use of DHCP for home addressing. They provide a loose coupling between M-IP and DHCP by strictly limiting the role of a HA to be that of a mediator between the host and the proxy for home address acquisition. Therefore, they are much less complex than embedded agents. In general, their shortcomings lie in having to implement the proxy, building an interface between the proxy and the HA, modifying the HA to perform its mediating role, and committing to future HA updates to reflect changes in the evolution of DHCP. Also, M-IP registration messages may have to be modified to include the MAC address of the client. Although the effort to implement proxy agents is not unreasonable, it is substantially greater than that required for bootstrapping agents. The solutions with proxy and embedded agents do have a performance advantage over transient tunneling with a bootstrapping agent; the configuration latency is lower. While all solutions include the overhead for the acquisition of a COA, solutions 2 and 3 have an additional overhead of approximately 2 RTTs (1 RTT for a M-IP registration and 1 RTT for a DHCP REQUEST or INFORM transaction). Solution 4, where the embedded agent returns the allocated home address and all other configuration parameters in one M-IP registration request, has an overhead of only 1 RTT. This contrasts with the 5 RTT overhead of transient tunneling, as described in Section 4.1. Given that this configuration latency overhead only affects mobile host power-ups, where latencies in the order of a couple of seconds are acceptable, we argue that the implementation simplicity of transient tunneling makes a more favorable tradeoff. 6 Other Issues 6.1 Efficient Wireless Bandwidth Usage Mobile hosts usually connect to an IP access network through a wireless air link, where bandwidth tends to be limited and costly due to physical and regulatory constraints. As a result, Thuel et al. Expires 12/00 [Page 16] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 practical mobility solutions should be concerned with the effective use of air bandwidth. Typical approaches to address this concern are packet compression techniques and the reduction of over-the-air traffic. We focus on the latter approach. Traffic over-the-air may be reduced through the prevention of bandwidth waste. One way to prevent bandwidth waste in the Transient Tunneling procedure is to stop unwanted broadcast packets originating in the home network from being tunneled to the mobile host by its HA. Recall from Section 3 that a broadcasting bit needs to be set in the HA so that DHCP packets broadcast by a server or relay in the home network reach the host in a foreign network. Unfortunately, all broadcast packets will be forwarded when the transient tunnel is present, not just the few desired DHCP packets. This introduces a costly traffic burden, especially over low bit-rate wireless links. We now outline approaches to eliminates this undesirable broadcast traffic overhead. In the ``co-located relay'' approach, the DHCP client is modified to mimic the operation of a joint client and relay. By sending messages to the server as if they were passing through a relay, the server is tricked into responding with IP unicast messages, thus eliminating the need for the HA to forward any broadcast packets downstream. The co-located relay would use the private home address of the host acquired through TT procedures as its IP address and advertise it to the server in DHCP requests (in the 'giaddr' field). It should be noted that address assignment rules used by the DHCP server to decide which address to assign to an incoming request are not standardized. Server implementations often select an address on the subnet where the relay resides, if the request was relayed, or on the subnet associated with the server's interface on which the request was received. This may yield to an undesirable address assignment for TT, entailing possible implementation-dependent changes to the server's subnet selection rules. Unicast server replies would likewise be processed through this virtual relay to eliminate relay state and hand it off to the client for normal processing. This approach hinges on the fact that TT assigns a private home address that can be used to simulate DHCP relay functionality for acquiring the home address. A shortcoming of this approach is that it requires a server to be on the same subnet as the HA, because a relayed DHCP request cannot go through more than one relay on its way to a server. Thuel et al. Expires 12/00 [Page 17] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 Another approach to eliminate the broadcast traffic overhead is to have ``cooperative clients'', that is, clients that explicitly request that the server responds with a unicast by clearing the broadcast bit in its requests. The standard specifies that in this case the server unicasts its replies to the client's hardware address, with the offered IP address in the destination field of the IP header. In a similar vein, the DHCP servers may be changed instead of the clients, to respond to select clients with hardware unicast datagrams, regardless of the setting of the broadcast bit in the client request. These select clients should be hosts roaming in a foreign network, as inferred by a ``mobility-aware DHCP server'' through some mechanism not described in this memo. As in the case of cooperative clients, this approach hinges on the HA's ability to forward hardware unicast datagrams from the server to the client. Further study is needed to determine if and how the HA will intercept such replies and forward them to the client, though the addition of intelligence to the HA seems inevitable. 6.2 External Foreign Agents An underlying goal for our work was to enable mobile hosts to dynamically configure both their home address and their co-located care-of address. Regardless of whether or not co-location is used makes no difference to TT, with the exception of an issue regarding FA support for private home addressing. In particular, the use of private home addressing with M-IP, as required by our procedure, raises potential host address collisions at the foreign agent. Since by definition private addresses are not globally unique, it is possible than an overlap occurs between the private addresses of hosts belonging to different HAs but served by the same FA. To resolve such addressing conflicts and ensure proper routing to the hosts, the FA must use additional host configuration state such as the HA address. This address conflict resolution is an open issue currently being addressed [12, 13]. It is important to note that the Home Agent is the only source of packets destined to the private address of the mobile host. Moreover, all such packets are unicast encapsulations of IP broadcast packets sent by the home DHCP server. 7 Security considerations The transient-tunneling procedure described in this memo is subject to the same security considerations that apply to RFC2002, RFC2344 and RFC2131 [1, 21, 2]. Thuel et al. Expires 12/00 [Page 18] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 8 Acknowledgements We would like to express our gratitude to Tom Hiller and Pete McCann, from Lucent Technologies, for their insightful comments and suggestions. Appendix A - Patent Issues This is to inform you that Lucent Technologies has applied for and/or has patent(s) that relates to the attached submission. This submission is being made pursuant to the provisions of IETF IPR Policy, RFC 2026, Sections 10.3.1 and 10.3.2. Lucent Technologies Inc. will offer patent licenses for submissions made by it which are adopted as a standard by your organization as follows: If part(s) of a submission by Lucent is included in a standard and Lucent has patents and/or pending applications that are essential to implementation of the included part(s) in said standard, Lucent is prepared to grant - on the basis of reciprocity (grantback) - a license on such included part(s) on reasonable, non-discriminatory terms and conditions. References [1] Charles Perkins. IP Mobility Support. RFC 2002, IETF, October 1996. [2] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, IETF, March 1997. [3] S. Alexander and R. Droms. DHCP Options and BOOTP vendor Extensions. RFC 2132, IETF, March 1997. [4] Charles Perkins and Kevin Luo. Using DHCP with Computers that Move. Wireless Networks Journal, vol.1:pp.341--353, 1995. [5] Jon-Olov Vatn and Gerald Maguire Jr. The effect of using co-located care-of addresses on macro handover latency. In Proceedings of Nordic Teletraffic Seminar, August 1998. Thuel et al. Expires 12/00 [Page 19] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 [6] Jon-Olov Vatn. Long random wait-times for getting a care-of address are a danger to Mobile Multimedia. In Proceedings of IEEE Intl. Workshop on Mobile Multimedia Communications, pages 142--144, November 1999. [7] A. McAuley, S. Das, S. Baba, and Y. Shobatake. Dynamic Registration and Configuration Protocol (DRCP). Work in progress - Internet Draft, IETF, October 1999. draft-itsumo-drcp-00.txt. [8] Aravamundhan, O'Brien, and Patil. NAI Resolution for Wireless Networks. Work in progress - Internet Draft, IETF, October 1999. draft-aravamundhan-mobileip-nai-wn-00.txt. [9] Internet Software Consortium. http://www.isc.org. [10] Pat Calhoun and Charles Perkins. Mobile IP Network Access Identifier Extension for IPv4. RFC 2794, IETF, March 2000. [11] P. McCann and K. Leung. Mobile IP Session Identifier Extension. Work in progress - Internet Draft, IETF, March 2000. draft-mccann-mobileip-sessionid-00.txt. [12] C. Perkins, G. Montenegro, and P. Calhoun. Private Addresses in Mobile IP. Work in progress - Internet Draft, IETF, June 1999. draft-ietf-mobileip-privaddr-00.txt. [13] W. Teo and Y. Li. Mobile IP extension for Private Internet Support. Work in progress - Internet Draft, IETF, February 1999. draft-teoyli-mobileip-mvpn-02.txt. [14] J. Bound, M. Carney, and C. Perkins. Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Work in progress - Internet Draft, IETF, May 2000. draft-ietf-dhc-dhcpv6-15.txt. [15] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. RFC 2462, IETF, December 1998. [16] C. Perkins and J. Bound. Extensions for the Dynamic Host Configuration Protocol for IPv6. Work in progress - Internet Draft, IETF, February 1999. draft-ietf-dhc-v6exts-11.txt. [17] R. Droms and W. Arbaugh. Authentication for DHCP Messages. Work in progress - Internet Draft, IETF, October 1999. draft-ietf-dhc-authentication-12.txt. Thuel et al. Expires 12/00 [Page 20] INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 [18] M. Stapp and Y. Rekhter. Interaction between DHCP and DNS. Work in progress - Internet Draft, IETF, October 1999. draft-ietf-dhc-dhcp-dns-11.txt. [19] D. Johnson and C. Perkins. Mobility Support in IPv6. Work in progress - Internet Draft, IETF, April 2000. draft-ietf-mobileip-ipv6-12.txt. [20] B. Patel, B. Adoba, S. Kelly, and V. Gupta. DHCP Configuration of IPSEC Tunnel Mode. Work in progress - Internet Draft, IETF, April 2000. draft-ietf-ipsec-dhcp-05.txt. [21] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, IETF, May 1998. [22] Charles Perkins and David Johnson. Route Optimization in Mobile IP. Work in progress - Internet Draft, IETF, February 1999. draft-ietf-mobileip-optim-08.txt. [23] G. Waters. The Subnet Selection Option for DHCP. Work in progress - Internet Draft, IETF, June 1999. draft-ietf-dhc-subnet-option-03.txt. Authors' Addresses S. Thuel, L. Salgarelli, R. Ramjee, K. Varadhan, T. La Porta Bell Laboratories - Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733, USA Voice: +1-732-949-8897 Fax: +1-732-949-7397 e-mail: {thuel,lsalgarelli,ramjee,kvaradhan,tlp}@bell-labs.com Thuel et al. Expires 12/00 [Page 21]