Internet Engineering Task Force S.Thuel / L.Salgarelli / R.Ramjee / INTERNET-DRAFT T.LaPorta draft-thuel-mobileip-tt-01.txt Bell Labs - Lucent Technologies Date: Feb. 23, 2001 Expires: Aug. 23, 2001 Dynamic Home Addressing in Mobile IP using Transient Tunnels Status of this memo This document is an individual contribution for consideration 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 A mechanism is described to enable mobile nodes to be dynamically configured by DHCP servers in their home networks even when they are located in a foreign network. The mechanism, referred to as Transient Tunneling, uses Mobile IP home agents to provide secure remote access to a mobile node's home network in such a way that the mobile node appears to be virtually present in the home Thuel et al. Expires 8/01 [Page 1] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 network. This virtual presence allows the remote mobile node to discover and communicate with a home DHCP server as if it were any other trusted client on the local LAN, which DHCP is designed to serve. Transient Tunneling achieves this by using the home agent to set up a temporary IP tunnel to carry DHCP messages between a client on the remote mobile node and a server in the home network. The tunnel is transient because it is only used for the brief period of time needed for the remote mobile node to complete its dynamic configuration. Key benefits of Transient Tunneling are its implementation simplicity, full compliance with current Mobile IP and DHCP standards, and the ability for mobile nodes to get access to all their DHCP-managed configuration options beyond basic IP addressing. The purpose of this document is to specify operational details for the mechanism and describe the minimal functional enhancements needed at mobile nodes. Transient Tunneling does not require any additional functional enhancements to home agents beyond what is already required to conform to current Mobile IP standards [1, 2], but it does suggest specifications for providing the home-address allocation function that has not yet been specified in [2]. In addition, Transient Tunneling is contrasted with comparable solutions such as the recently proposed DHCP proxy mechanism [3]. Thuel et al. Expires 8/01 [Page 2] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 Contents 1 Introduction 4 1.1 Requirements and Design Goals ............................ 5 1.2 Configuration Process Overview ........................... 6 2 Transient Tunneling 7 2.1 Overview ................................................. 7 2.2 Operation ................................................ 8 2.2.1 Configuring Remote Mobile Nodes.................... 8 2.2.2 Remotely Configured Mobile Nodes returning Home.... 13 2.3 Functional Requirements .................................. 13 2.3.1 Mobile Nodes....................................... 13 2.3.2 Home Agents........................................ 15 2.3.3 Foreign Agents..................................... 16 2.4 Benefits ................................................. 16 2.5 Caveats .................................................. 17 2.5.1 Configuration Latency.............................. 17 2.5.2 Home Agent Forwarding of Broadcast Traffic......... 17 3 Other Remote Configuration Solutions 18 4 Other Issues 21 4.1 Support for Minimal-Configuration Mobile Nodes ........... 21 4.2 Support for IPv6 ......................................... 21 5 Security Considerations 22 6 Compliance Statements 22 6.1 Mobile IP Compliance Statement ........................... 22 6.2 DHCP Compliance Statement ................................ 23 7 Acknowledgments 23 8 Full Copyright Statement 24 9 Chair's Address 25 Thuel et al. Expires 8/01 [Page 3] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 1 Introduction Mobile nodes which do not have an IP address need some support to be configured dynamically. For management efficiency, it is desirable that IP addresses dynamically allocated to mobile nodes come from the same address pool used to configure fixed (i.e., non-mobile) nodes. Fixed nodes are typically configured with DHCP [4], a client-server protocol that can allocate a large variety of configuration options besides IP addresses (e.g., home subnet mask, DNS servers, etc.). These so-called 'DHCP options' [5] may be quite valuable or even necessary to some types of mobile nodes. DHCP was designed to serve the configuration needs of trusted clients on a local LAN; it assumes that client requests are sent by locally connected nodes. As a result, configuring mobile nodes that are at home is no different from configuring any fixed node. This is, however, not the case for mobile nodes that need to be configured when they are away from their home networks. These mobile nodes need a way to remotely access a DHCP server in their home networks to get an address (and possibly other configuration parameters) from the same address pool as if the node were at home. The most straightforward approach is to make the DHCP servers believe that a remote mobile node is a trusted client on the same LAN. In other words, the remote mobile node must appear to be virtually present on its home LAN although it is in a physically distant network. Moreover, remote server accesses must be made secure to prevent mis-use or abuse by unauthorized mobile nodes. Mobile IP already provides support for secure remote access to the home network and enables the desired virtual presence. Recent extensions to Mobile IP even allow mobile nodes to dynamically obtain a home address from a home agent as part of their registration process. In particular, the NAI extension of the Mobile IP registration process [2] provides a mechanism for a mobile node which does not have a home address to request and obtain one from its home agent. What has yet to be defined is how the home agent dynamically allocates these addresses. And, in a broader sense, it is also unclear how the home agent would allocate other configuration parameters needed by the remote mobile nodes besides home addresses. Equipping the home agent to perform address allocation from its own address pool would duplicate functionality already provided by DHCP. DHCP has the added benefit of supporting access to Thuel et al. Expires 8/01 [Page 4] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 additional configuration parameters that remote mobile nodes may need. The desirability of preserving DHCP as the central address maintainer calls for a different role for the home agent. Rather than managing addressing or configuration state in isolation from DHCP, the home agent should mediate a mobile node's access to DHCP. Transient Tunneling is a lightweight approach for the home agent to perform this mediation role. The home agent is used to temporarily establish an IP tunnel to carry messages between a home DHCP server and a remote client executing on the mobile node. It is important to observe that the home agent does not intervene in the DHCP transactions between the server and the client but simply provides a conduit for those transactions to take place. Therefore, Transient Tunneling optimizes for implementation simplicity and on enabling mobile nodes unlimited access to all the DHCP-managed configuration options beyond basic IP addressing (without requiring any DHCP-specific extensions to Mobile IP for mobile nodes to request and acquire optional configuration state). This document specifies the operational details for the Transient Tunneling mechanism and describes the minimal functional enhancements needed at the mobile nodes. Specifications are also suggested for how to provide the functional enhancements to home agents required, but not yet specified, by the NAI extension of the Mobile IP standard. The use of this home agent enhancement by Transient Tunneling is described in detail. In addition, other remote dynamic configuration solutions for mobile nodes are discussed and a detailed comparison with the related DHCP proxy mechanism is provided. 1.1 Requirements and Design Goals To better understand the needs and constraints in deploying dynamic configuration support, it is important to recognize that mobile nodes have different configuration requirements and capabilities. More specifically, mobile nodes may differ in terms of the configuration parameters they need. While some are ``minimal-configuration'' nodes requiring only an IP address, more sophisticated nodes may need a few to many additional configuration options (e.g., subnet mask, DNS servers, etc.). In addition, mobile nodes differ in their availability of local resources for the support of client processing activities. If ``resource-limited'' nodes are to be dynamically configured, Thuel et al. Expires 8/01 [Page 5] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 provisions may have to be built into the configuration support mechanisms to allow network-based nodes to undertake most of the burden of acquiring and maintaining leased configuration state while minimizing the processing requirements imposed on the mobile nodes. Due to its node-centric design, transient tunneling is inherently biased towards serving the configuration needs of mobile nodes that are not resource-limited. In addition, its ability to enable access to all configuration options besides IP addresses is most valuable to high-end mobile nodes with complex configuration needs (i.e., not minimal-configuration nodes). Although Transient Tunneling supports minimal-configuration nodes the potential of having unlimited access to optional configuration state is not realized in this case. The Transient Tunneling mechanism was designed to meet the following design goals: o to preserve the use of DHCP for home address allocation, o to enable mobile nodes to have unlimited access to all DHCP configuration options (besides addressing), o to preserve compliance with Mobile IP and DHCP standards, o to suggest specification details on how to equip home agents with the dynamic address allocation support already required, but not yet specified, by the NAI extension of the Mobile IP standard, o and to minimize functional enhancements to mobile nodes. 1.2 Configuration Process Overview In general, the procedures for configuring a remote mobile node with DHCP and for defending its leased configuration state may be grouped into four stages: 1. Remote Configuration: procedures for a remote mobile node to get a leased home address and optionally other configuration parameters (e.g., DHCP server address, lease lifetime, home Thuel et al. Expires 8/01 [Page 6] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 netmask, DNS server, etc.) from a DHCP server in its home network 2. Remote Lease Renewals: procedures to renew the DHCP lease for the mobile node while it roams within or across foreign networks 3. Home De-registration: procedures for the mobile node to release Home Agent support upon entering its home network 4. Home-based Lease Renewals: procedures for the mobile node to renew its DHCP lease while it roams within its home network Note that the first two stages comprise procedures that take place while the mobile node is attached to a foreign network while the latter two stages occur when the mobile node enters and roams in its home network. These stages will be used in the following section as a template for describing the operational details of the transient tunneling mechanism. 2 Transient Tunneling 2.1 Overview The main idea behind Transient Tunneling is to keep the DHCP client on the mobile node and use Mobile IP to set up a temporary IP tunnel between the mobile node and the home agent, just to carry the node's DHCP messages to and from the home network. The role of the home agent is then to enable a mobile node to communicate with a DHCP server in its home network. The tunnel is transient because it is kept in place for the exclusive purpose of carrying DHCP messages between the mobile node and a remote home server and only for the time required for the node to successfully acquire a permanent home address (and any other desired configuration parameters) from the server. It works as follows. The mobile node sends a registration request to its home agent (HA). Once the home agent has authenticated the mobile node and determines it needs a home address, it assigns a temporary home address to the mobile node from an address pool of its own and sets up a tunneling entry for the node with this address and the care-of address specified in the registration message. The home agent then returns the assigned address to the Thuel et al. Expires 8/01 [Page 7] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 mobile node in its registration reply. When the foreign agent (FA) serving the mobile node sees the reply, it sets up its end of the tunnel and forwards the temporary address to the mobile node (if the foreign agent is co-located with the mobile node, this forwarding is trivial; otherwise the forwarding is done according to standard procedures specified in [1, 2]). The mobile node then installs the temporary home address on one of its interfaces. With the tunnel in place, the DHCP client on the mobile node starts to send and receive messages to/from its home network which may reach a DHCP server as if the mobile node were locally connected. After the mobile node successfully acquires an address from DHCP (along with any other desired configuration parameters), it may use it as its permanent home address. But first it sends a de-registration message to its home agent to tear down the temporary tunnel and release its temporary address and then it sends a registration message with its permanent home address. Once configured, no more transient tunneling support is needed for the mobile node. Following standard procedures, the mobile node periodically sends DHCP lease renewal messages to defend its home address and Mobile IP registration messages to renew the lifetime of its address binding. Note that the requirement that the home agent maintain an address pool does not conflict with the goal of using DHCP for address allocation because permanent home addresses are still allocated from DHCP's public address pool. Addresses allocated by the home agent are used by mobile nodes for a very brief period of time and are only used to send or receive DHCP messages to/from their home networks. Also note that the home agent address pool can consist of either private addresses (e.g., of type 10.* or 192.168.* [6]) or public addresses. If the public IP address space is tight, the use of a private address pool at the home agent is suggested. The following sections describe this procedure in detail and define the functional requirements imposed on the home agent and the mobile node. No changes are required to current DHCP server implementations. 2.2 Operation 2.2.1 Configuring Remote Mobile Nodes Figure 1 gives an overview of the procedures by which the Transient Tunneling mechanism enables remote dynamic configuration Thuel et al. Expires 8/01 [Page 8] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 and remote lease renewals for mobile nodes. The procedures shown are for the case where the mobile node uses a co-located foreign agent. Minor differences regarding the use of an external foreign agent are discussed in Section 2.3.3. Each message is labeled with a number, corresponding to a detailed description below. Note that messages (1)-(10) correspond to a remote configuration while messages (11)-(12) describe a remote lease renewal. 1. The mobile node sends a Mobile IP registration request to the HA containing a null in the mobile node home address field, an NAI extension, and a MN-HA and/or MN-AAA authentication extension, depending on which security model is in use [7]. In addition, the mobile node must set the the broadcast ``B'' bit and the ``T'' bit in the registration request as specified in [1] and [8]. The setting of the ``B'' bit is needed to ensure that the HA forwards broadcast messages back to the mobile node, thus allowing future DHCP server replies to reach it. When the HA receives the registration request, it authenticates the mobile node and checks to see if it has a current binding for it. If it does not, the zero home address indicates to the HA that an address needs to be assigned. If the registration request was found to be unacceptable, an appropriate error code MUST be returned to the mobile node's care-of address, as specified in [1, 2]. 2. The home agent allocates a temporary home address for the mobile node from an address pool of its own (containing private or public IP addresses). If the home agent is unable to allocate an address, it MUST return error 99 "Missing Home Address" as described in [2]. If successful, the home agent creates an association of the allocated address with the NAI of the mobile node. It also adds a tunneling entry, binding the temporary home address it allocated to the mobile node with the care-of address specified in the registration message. The home agent then sends the allocated address in a registration reply, with the lifetime field set according to conventional configuration policies. In order to prevent rogue address problems, a home agent MAY reclaim allocated addresses from mobile nodes that fail to send a registration renewal prior to their granted lifetimes. Upon receiving the reply, the foreign agent on the mobile node uses the allocated address to set up its end of the tunnel Thuel et al. Expires 8/01 [Page 9] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 MOBILE HOME AGENT WITH HOME NODE TEMP ADDRESS POOL DHCP SERVER | | | / | | | Initial | |(1) REGISTRATION (w/NAI) | | Mobile | |-------------------------->| | IP | | REPLY (w/temp address) (2)| | Regis. \ |<--------------------------| | / |(3) DHCPDISCOVER | | | |==========================>|------------------------>| Get | | | DHCPOFFER (4)| DHCP | |<==========================|<------------------------| Address | |(5) DHCPREQUEST | | Lease | |==========================>|------------------------>| | | | DHCPACK (6)| \ |<==========================|<------------------------| / |(7) DE-REGISTRATION (temp address) | Mobile | |-------------------------->| | IP | | REPLY (8)| | De-Reg. \ |<--------------------------| | / |(9) REGISTRATION (home address) | Mobile | |-------------------------->| | IP | | REPLY (10)| | Reg. \ |<--------------------------| | . . . . . . . . . / | | | Mobile | |(11) REGISTRATION | | IP | |-------------------------->| | Regis. | | REPLY (12)| | Renewal \ |<--------------------------| | Figure 1: Transient Tunneling Procedures for Remote Configuration and Lease Renewals Thuel et al. Expires 8/01 [Page 10] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 (i.e., creates a binding entry of the node's care-of address to the allocated address). The mobile node then installs the allocated address on one of its interfaces. At this point, the mobile node is connected to its home network. 3-6. The mobile node executes standard DHCP client procedures to acquire a DHCP lease, as defined in [4]. Note that DHCP messages travel over the transient tunnel set up between the mobile node and the home agent, indicated with a double line in the Figure. Standard DHCP procedures entail the sending of a DHCPDISCOVER (3), receiving a DHCPOFFER (4), sending a DHCPREQUEST (5) for the offered lease and receiving a DHCPACK (6). There is no difference between these messages and those generated by any standard DHCP client, with the following exceptions. Rather than reaching a DHCP server in the home network directly, messages to the server are reverse-tunneled from the foreign agent to the home agent while messages to the client are tunneled in the other direction. In order to accomplish this, the broadcast "B" bit in the flags field of DHCP query messages as specified in [4] MUST be set by the client to ensure that the replies from the server or relay in the home network reach the client. 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 relay to send any replies as broadcasts 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 home agent receives these broadcast replies for subsequent forwarding to the mobile node. If the mobile node is unable to obtain a DHCP lease for whatever reason it MUST de-register with its home agent. 7. If the mobile node successfully obtains a DHCP lease, it sends a de-registration message to its home agent. This de-registration message MUST contain the address allocated by the home agent in the home address field of the message, and the same NAI and care-of address that the mobile node used in its initial registration. When the home agent receives the de-registration, it first checks the NAI to see if it had assigned an address to this Thuel et al. Expires 8/01 [Page 11] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 mobile node. It then compares the home address in the message with the address it had allocated to the mobile node. If they match (as MUST be the case for de-registrations of temporary home addresses), the home agent deletes the corresponding NAI to IP address binding entry, thus reclaiming the address for future reuse. If they don't match, the home agent MUST assume that the home address was allocated by some external means. In either case, standard de-registration procedures follow, entailing the deletion of the existing tunneling entry for the mobile node (indexed by the NAI or the home address). 8. The home agent then sends a reply to the mobile node, unicast to its care-of address. When the foreign agent gets the reply, it deletes its tunneling entry for the mobile node. If the foreign agent is external to the mobile node, the reply is forwarded to the mobile node, which may then remove the temporary home address from the interface on which it was installed and replace it with the permanent home address it obtained from DHCP. [Note that it is possible to eliminate the de-registration of the temporary home address (messages 7 and 8) if the home agent gives it a short expiration time and the address is left to time-out.] 9. The mobile node sends a new registration message to its home agent with its permanent home address in the home address field, and its NAI and care-of address in their corresponding fields. Upon receiving the message, the home agent performs a standard registration, creating a new tunneling entry for the mobile node that binds the node's permanent home address to its care-of address. 10. The home agent sends a registration reply to the mobile node's care-of address. When the foreign agent gets the reply it sets up its corresponding tunneling entry and forwards the reply to the mobile node. At this point, the mobile node is connected to its home network with its permanent home address and is able to send and receive IP packets to/from corresponding hosts. 11-12. Prior to the expiration of the mobile node's renewal lifetime, it sends a registration message to the home agent. Thuel et al. Expires 8/01 [Page 12] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 The home agent performs standard re-registration procedures then sends a reply to the mobile node, which in turn extends its renewal lifetime and waits until the next renewal cycle. 2.2.2 Remotely Configured Mobile Nodes returning Home When a mobile node configured remotely with Transient Tunneling enters its home network, it follows standard Mobile IP de-registration and DHCP lease renewal procedures. Thus, it behaves no differently from any node that was locally configured with DHCP. 1-2. The mobile node sends a standard de-registration message to its home agent. The Home Agent performs standard de-registration processing (i.e., it does not perform any additional work associated with transient tunneling) and sends a standard reply to the mobile node. Once receiving the reply, the mobile node likewise processes it in a standard manner. 3-4. Periodically, the mobile node sends a standard DHCP lease renewal message to its server to prevent lease expiration. 2.3 Functional Requirements 2.3.1 Mobile Nodes Prior to invoking any configuration procedures, a mobile node MUST be able to determine whether it is in its home or in a foreign network. This location inference may be based on knowledge of its NAI (a wireless link-layer identifier such as the Mobile Identification Number or MIN can be mapped to a NAI). For example, the node's Mobile IP client may listen for periodic advertisements from a home or foreign agent containing the domain name which it can then compare against its own NAI. Note that this requirement applies to any dynamic configuration procedure, not just transient tunneling. The mobile node is required to be aware that configuration with transient tunneling involves two stages, namely, a temporary home address configuration followed by a permanent configuration using Thuel et al. Expires 8/01 [Page 13] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 MOBILE HOME AGENT HOME NODE DHCP SERVER | | | / | | | Mobile | |(1) DE-REGISTRATION | | IP | |-------------------------->| | De-reg. | | REPLY (2)| | \ |<--------------------------| | . . . . . . . . . / | | | DHCP | | (3) DHCPREQUEST | | Lease | |---------------------------------------------------->| Renewal | | | DHCPACK (4)| | |<----------------------------------------------------| \ | | | Figure 2: Transient Tunneling Procedures for De-Registration and Lease Renewals while at Home Thuel et al. Expires 8/01 [Page 14] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 DHCP. As a result, the mobile node SHOULD NOT use the temporary home address as its permanent address (exceptions may be allowed for serving minimal-configuration mobile nodes, as discussed in Section 4.1). This functionality can be provided with a minimal addition of control software, entailing no changes to DHCP nor Mobile IP client software. It is also important to be aware that some DHCP client implementations may assume that only one IP address is to be configured on a given host interface. This is a problem for mobile nodes that need to get two addresses from DHCP (e.g., a home address and a care-of address) and install them on the same interface (e.g., a wireless interface). Unpredictable results would occur if the client state machine for each leased address assumes it has full control of the interface's configuration state. Consequently, 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. 2.3.2 Home Agents Transient Tunneling requires home agent functionality to be augmented with very lightweight addressing capabilities. Specifically, addressing support referred to as a bootstrapping agent needs to be added in order to assign the temporary home addresses needed by registering mobile nodes to set up their transient tunnels. The address pool managed by a bootstrapping agent may consist of public or private addresses with the distinct properties that these addresses are: a) allocated during a Home Agent's processing of a registration request from a mobile node; b) used for very brief periods of time (i.e., only while a mobile node's transient tunnel is up); and c) reclaimed during a Home Agent's processing of a corresponding de-registration request (or timed-out, in the event that a de-registration request doesn't arrive within a reasonable time). Home agents that conform to [2] are already required to support dynamic home addressing, even though the details of the addressing mechanism are still undefined. 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 Thuel et al. Expires 8/01 [Page 15] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 event, home agents that conform to [2] are already required to support this modification of the basic operation as outlined in [1]. 2.3.3 Foreign Agents Transient tunneling requires foreign agents to support reverse IP tunneling as specified in [8] so that DHCP client messages generated by the mobile node are forwarded to the home agent. The use of an external or a co-located foreign agent is of no relevance to transient tunneling, with one exception. If an external foreign agent is used and temporary addresses allocated by the home agent are drawn from a private address pool, address collisions may occur at the foreign agent for mobile nodes being served by different home agents but the same foreign agent. To resolve such addressing conflicts and ensure proper routing to the nodes, the foreign agent must use additional state such as the node's NAI. This address conflict resolution is an open issue to be addressed by the IETF. It is useful to note that the home agent is the only source of packets destined to the temporary home address of the mobile host. Moreover, all such packets are unicast encapsulations of IP broadcast packets sent by the home DHCP server. 2.4 Benefits While leveraging the use of widely deployed DHCP as the central address maintainer and of Mobile IP's support for secure remote access to home networks, Transient Tunneling enables the dynamic configuration of remote mobile nodes without requiring any changes to either the Mobile IP nor DHCP sets of protocol standards and only minor implementation enhancements to mobile nodes, as discussed in Section 2.3.1. The implementation enhancements to home agents needed by Transient Tunneling are already required by current extensions to the Mobile IP standard [2]. The most salient benefits of Transient Tunneling are its implementation simplicity and its ability to enable mobile nodes to have unlimited, remote access to all the DHCP-managed configuration options beyond basic IP addressing (without requiring any DHCP-specific extensions to Mobile IP for mobile nodes to request and acquire optional configuration state). Thuel et al. Expires 8/01 [Page 16] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 2.5 Caveats 2.5.1 Configuration Latency The main shortcoming of Transient Tunneling is that the DHCP client messages must travel from/to the mobile node to/from a possibly distant home network, resulting in undesirable configuration delays. In particular, the configuration latency experienced by a mobile node is on the order of 5 round-trip times (RTTs), namely: (a) 1 RTT to set up the transient tunnel by registering with the home agent; (b) 2 RTTs to acquire a permanent home address with DHCP through the transient tunnel; (c) 1 RTT to de-register the transient-tunnel (although this de-registration is not strictly necessary if the temporary address is allowed to time-out); and (d) 1 RTT to register with the home agent using the permanent home address. In networking scenarios where the RTTs to the home network are very high, mobile nodes using transient tunneling can experience large configuration latencies. To put this in perspective, with current typical Internet RTTs in the 100-300 msec. range, this would result in a configuration latency of about 0.5 to 1.5 seconds (ignoring DHCP processing overheads). This concern is offset by the fact that this latency typically impacts mobile nodes during power-ups, where delays on the order of seconds are tolerable for a large spectrum of mobile devices and not during normal handoffs which are substantially more delay-sensitive. 2.5.2 Home Agent Forwarding of Broadcast Traffic Recall from Section 2 that Transient Tunneling (TT) requires a broadcasting bit to be set in registration requests to enable the HA to forward broadcast packets back to the mobile node. This was required to ensure that DHCP reply packets broadcast by a server or relay in the home network reach the node in a foreign network. Unfortunately, this would cause all broadcast packets to be forwarded, not just the few desired DHCP packets. This introduces a costly traffic burden, especially over low bit-rate wireless links. We now describe a solution to eliminate this undesirable overhead. The problem can be solved with the notion of a ``co-located relay'', that is, a DHCP client that is modified to mimic the operation of a joint client and relay. By sending messages to the Thuel et al. Expires 8/01 [Page 17] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 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 temporary home address of the mobile node 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 temporary home address that can be used to simulate DHCP relay functionality for acquiring the permanent 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. Note that the use of a co-located relay does not change the TT procedures outlined in Figures 1 and 2. 3 Other Remote Configuration Solutions It is possible to enable the remote configuration of mobile nodes with other secure remote access protocols besides Mobile IP. For instance, a conventional VPN IPSec tunnel could provide a mobile node with secure remote access to its home network [11]. This VPN tunnel could serve as the Transient Tunnel for DHCP transactions (provided the mobile node is fixed during the DHCP transaction interval, since VPNs do not have mobility support). However, since mobile nodes already need Mobile IP support for mobility management, it is more efficient to leverage its use rather than require support for another remote access protocol. There are two types of Mobile IP-based remote configuration solutions: those which use DHCP and those which do not. An example of a non-DHCP solution is to equip the Home Agent with an address pool of its own. Although this may seem straightforward Thuel et al. Expires 8/01 [Page 18] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 and could result in performance advantages, as discussed earlier, it has several shortcomings. First, this solution introduces address space management inefficiencies, as the network address pool has to be partitioned between DHCP servers and Home Agents and sized appropriately in each case to avoid depletion. Second, at least a subset of the functionality already provided by DHCP would be duplicated in the Home Agent. The extent of the duplication is bound to increase if mobile nodes start requiring more than just an IP address for their configuration, adding more complexity to Home Agents. Finally, and most importantly, mobile nodes need to periodically defend the address that was allocated by a Home Agent to efficiently support dynamic address reclamation and re-use. This requires changes to the Mobile IP standard so that mobile nodes can periodically communicate with their home agent even when they are in their home networks, since current standards specify that no registrations should be sent when a node is at home. Transient Tunneling is an example of a DHCP-based solution. The recently proposed DHCP proxy mechanism is another example. Under their similarities in goals lie important differences worth discussing in depth. The key idea behind the DHCP proxy mechanism is to place surrogate or proxy DHCP clients on the Home Agent to perform all client transactions on behalf of any mobile node lacking a home address when it attempts to register. A proxy provides the following services: a) generates client messages on behalf of a mobile node, to communicate with a local DHCP server in order to acquire a home address (this is triggered by the arrival of a proper registration request with a NAI but without a home address); b) forwards the DHCP-acquired address back to the remote mobile node in a registration reply message; and c) defends the DHCP-acquired address for the mobile node while it roams within foreign networks, and relinquishes control of this responsibility if the mobile node enters its home network and assumes this control. There are several key distinctions between Transient Tunneling and DHCP proxies. While Transient Tunneling is node-centric, DHCP proxy is agent-centric, regarding its placement of DHCP client functionality. Modifying home agents to provide proxy services is a non-trivial effort, mainly because placing a mediating DHCP agent between the mobile node and the DHCP server introduces a number of exceptional conditions that need to be managed. In addition, care must be taken to ensure that the scalability of Thuel et al. Expires 8/01 [Page 19] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 home agents is not compromised as they undertake the responsibility of providing proxy services to a potentially large number of mobile nodes. Second, the only way that DHCP proxies can return configuration state back to the mobile node is through a registration reply message. This limits the configuration state that can be sent back to the mobile node to an IP address, in order to remain compliant with current Mobile IP standards. Optional configuration parameters may be requested by and be forwarded to the mobile node only through DHCP-specific extensions to Mobile IP. Finally, in DHCP proxies, the defense of leased addresses (i.e., DHCP lease renewals) gets triggered by the arrival of Mobile IP registration renewals. Triggering a lease renewal upon every registration renewal would add delay to the registration process, resulting in increased handoff latencies that would be harmful to time-sensitive applications such as those involving voice-streaming sessions. Since registration renewals are typically on the order of minutes while lease renewals are on the orders of hours or days, it is possible to put some intelligence in the proxies to avoid unnecessary lease renewals, especially during handoffs. This would solve the problem at the expense of additional home agent complexity. On the flip side, DHCP proxies do have a performance advantage over Transient Tunneling. Since proxies carry out client-server DHCP transactions locally in the home network, they eliminate the round trip latency overheads between a distant client and server (accounting for 2 RTTs in the Transient Tunneling mechanism). In addition, the 2 RTT overhead of setting up and tearing down a transient tunnel is also eliminated, resulting in a minimal configuration latency on the order of 1 RTT. In summary, DHCP proxies entail significant enhancements to home agents, but make it easy for mobile nodes to quickly get a home address from DHCP by keeping transactions localized to the home network. Extensions to the Mobile IP standard are required to enable DHCP proxies to acquire any additional (i.e., optional) configuration parameters and forward them to the mobile node within a registration reply message. Conversely, transient tunneling requires minimal enhancements to mobile nodes and minimal enhancements to home agents already required by recent extensions to the Mobile IP standard, while placing no restrictions on the configuration parameters that can be accessed. However, it yields higher configuration latencies due to the exchange of DHCP messages between a distant client and server and Thuel et al. Expires 8/01 [Page 20] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 the transient tunnel setup/teardown procedures. Nonetheless, it is argued that this configuration latency is acceptable in typical networking scenarios, as it entails a power-up overhead where delays on the order of seconds are tolerable. 4 Other Issues 4.1 Support for Minimal-Configuration Mobile Nodes In the case of networks that only serve low-end mobile nodes with minimal configuration needs, (i.e., an IP address and no configuration options), the configuration latency overheads for Transient Tunneling may be unjustified. However, special provisions can be made to configure these nodes in a single RTT. DHCP proxies could be used to configure these minimal-configuration mobile nodes, since these are the types of nodes which this mechanism is best suited to serve. This would preserve DHCP as the central address maintainer, at the cost of enhancing home agents with proxy functionality. Notwithstanding the many shortcomings of equipping a home agent with its own address pool, as discussed in Section 3, this non-DHCP solution might be acceptable if judiciously used in certain scenarios (e.g., plentiful IP address space, unlikely need to support active handoffs into the home network). Transient Tunneling can co-exist with either of these configuration mechanisms, and the selection of a configuration strategy can be tailored to the performance and configuration needs of the mobile nodes served in a particular network scenario. 4.2 Support for IPv6 The Transient Tunneling mechanism was designed with the assumption that mobile nodes use IPv4 addresses, where the efficient management of a scarce address space favors the use of a centralized address management solution like DHCP. In IPv6, address space limitation concerns disappear and Stateless Address Autoconfiguration procedures allow IP nodes to autoconfigure themselves without the need for external address allocation support [9]. Since Stateless Address Autoconfiguration only allows nodes to get an address on the network to which they are attached (i.e., a link-local address), it does not help in configuring mobile nodes that are in need of a home address while Thuel et al. Expires 8/01 [Page 21] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 they are in a foreign network. However, the availability of a plentiful address space makes it possible, and perhaps likely, to statically configure mobile nodes with a permanent home address. Under these circumstances, there would be no need for Transient Tunneling support, nor any other dynamic configuration mechanism for that matter, to acquire a home address. However, the need for nodes to acquire optional configuration state also arises in IPv6 and such state cannot be obtained through autoconfiguration procedures regardless of mobility. Indeed, the dynamic addressing and configuration support provided by the DHCPv6 protocol [10] is argued to be a valuable stateful counterpart to IPv6 address autoconfiguration procedures, enabling nodes to dynamically obtain an IPv6 address when autoconfiguration support is unavailable and to obtain configuration options which cannot be obtained through autoconfiguration. Like DHCPv4, the server discovery support in DHCPv6 assumes that clients are locally connected to the servers. A remote access mechanism is still needed for mobile nodes to discover a home DHCP server when they are attached to a foreign network. If a remote mobile node has a permanent home IPv6 address but is in need of configuration options, it may simply register and use its Mobile IP tunnel to discover and communicate with a DHCP server in its home network to request the desired options. On the other hand, if the remote mobile node lacks a permanent home address and possibly some configuration options, Transient Tunneling may be used by the mobile node to discover and communicate with a home DHCP server. Detailed IPv6 interworking specifications for Transient Tunneling are not defined in this document. 5 Security Considerations The transient tunneling procedure described in this memo is subject to the same security considerations that apply to RFC2002, RFC3024, RFC2794, and RFC2131 [1, 8, 2, 4]. 6 Compliance Statements 6.1 Mobile IP Compliance Statement Since no changes are made to home agents beyond what is already required by the standards, the Transient Tunneling mechanism described in this document is fully compliant with Mobile IP standards [1, 2]. Likewise, no changes are required to foreign Thuel et al. Expires 8/01 [Page 22] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 agents, beyond those which are specified in standard [8]. Finally, enhancements required to mobile nodes do not modify the behavior of a Mobile IP client. Stated otherwise, a mobile IP client with Transient Tunneling support is fully compatible with standard home and foreign agents. 6.2 DHCP Compliance Statement Transient Tunneling requires no changes to current DHCP server implementations. Therefore, the procedure will be completely supported by existing DHCP server implementations conforming to [4]. 7 Acknowledgments We would like to express our gratitude to Tom Hiller and Pete McCann 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] Pat Calhoun and Charles Perkins. Mobile IP Network Access Identifier Extension for IPv4. RFC 2794, IETF, March 2000. Thuel et al. Expires 8/01 [Page 23] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 [3] Steven Glass. Mobile IP Agents as DHCP Proxies. Work in progress - Internet Draft, IETF, June 2000. draft-glass-mobileip-agent-dhcp-proxy-00.txt. [4] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, IETF, March 1997. [5] S. Alexander and R. Droms. DHCP Options and BOOTP vendor Extensions. RFC 2132, IETF, March 1997. [6] Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. de Groot, and E. Lear. Address Allocation for Private Internets. RFC 1918, IETF, February 1996. [7] Charles Perkins and Pat Calhoun. Mobile IPv4 Challenge/Response Extensions. RFC 3012, IETF, November 2000. [8] G. Montenegro. Reverse Tunneling for Mobile IP, revised. RFC 3024, IETF, January 2001. [9] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. RFC 2462, IETF, December 1998. [10] J. Bound, M. Carney, C. Perkins, and R. Droms. Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Work in progress - Internet Draft, IETF, November 2000. draft-ietf-dhc-dhcpv6-16.txt. [11] B. Patel, B. Adoba, S. Kelly, and V. Gupta. DHCP Configuration of IPSEC Tunnel Mode. Work in progress - Internet Draft, IETF, December 2000. draft-ietf-ipsec-dhcp-09.txt. Authors' Addresses S. Thuel, L. Salgarelli, R. Ramjee, 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,tlp}@lucent.com Thuel et al. Expires 8/01 [Page 24] INTERNET-DRAFT draft-thuel-mobileip-tt-01.txt Feb. 23, 2001 8 Full Copyright Statement "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9 Chair's Address The Working Group can be contacted via its current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola M/S M8-540 6000 Connection Drive 1501 West Shure Drive Irving, TX 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 EMail: Basavaraj.Patil@nokia.com EMail: phil.roberts@motorola.com Fax : +1 972-894-5349 Thuel et al. Expires 8/01 [Page 25]