Internet Engineering Task Force S. Glass INTERNET DRAFT Sun Microsystems Mobile IP Working Group 7 June 2000 Mobile IP Agents as DHCP Proxies draft-glass-mobileip-agent-dhcp-proxy-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is a submission to 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. 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. Distribution of this memo is unlimited. Abstract Since the inclusion of the Network Access Identifier (NAIs) into the mobile ip fabric, home agents have had a way to identify mobile nodes which do not have home IP addresses. After authenticating the registration request from such a mobile node, the home agent is then expected to assign a home addresses to the mobile node in the registration reply to be used on a semi-permanent basis. Unfortunately, no specific mechanism has yet been proposed. Ideally, as DHCP centralizes address management, a home agent should contact a DHCP server to allocate an address for the mobile node, thereby preserving DHCP as the central address maintainer. The technology does exist for a Home Agent to use DHCP controlled addresses, namely for the Home Agent to behave as a DHCP proxy agent. This document specifies the procedure for a Home Agent to follow when contacting a DHCP server to obtain home addresses for mobile nodes that require them. It does so in the spirit of the design goals of [1], and [2] (section 1.6). Moreover, it specifies the responsibilities of the home agent with regard to defending this S. Glass Expires 7 December, 2000 [page i] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 address, and maintaining it as appropriate. Obviously, support must be added to the home agent to provide for this functionality, so the most desireable case is to limit changes to just the home agent. This document enhances the behaviour of the home agent in a way so that no enhancements to the behaviour of a mobile node which is compliant with [1] and [3] is required. As a result, a clearer picture is also obtained as to what needs to be addressed when a mobile node is not assigned a home address before it roams, and the complications that can result in various mobile ip situations. As always, optimizations and enhancements can be made, in this case proposing changes to both home agent and mobile node. These changes are specified as optional extension support. The exchange of extensions is defined in such a way that if one side understands these extensions, and the other side does not, interoperability is still acheived. 1. Introduction Mobile IP was designed to give nodes the ability to leave the confines of their home subnet, allowing them to not only initiate new connections from their roamed location, but to keep their current connections active while receiving new connection requests through an agent on their home subnet, known as the home agent. Recent enhancements to mobile ip have even allowed nodes which do not yet have an IP address to connect to their home subnets, and receive an address through their home agent. No mechanism describing how the home agent is to obtain such addresses has been officially proposed, however, which may default home agents into have their own address-pools from which they can hand out addresses. The ideal method would be to have the mobile node receive an address from the same address pool as it would if it were at home, most likely the DHCP address pool on it's home network. Obtaining an address directly would be difficult since any concept of a home network to DHCP is the network on which the node is currenly residing. Special enhancements to DHCP would have to be devised to get the DHCP messages to, and from the home subnet, and it is likely such enhancements would immitate functionality already designed for mobile ip. The mechanism used to get a mobile node's request for a home address already exists in the NAI extension of the mobile ip registration process [3]. When the home agent receives a registration request containing a zero home ip address, and an NAI extension, it uses the NAI to associate the shared secret between the mobile node and itself, and uses the MN-HA authenticator to identify the registration as comming from the mobile node (if a MN-AAA authenticator appears instead, authentication is done using that at the AAA server). The HA then finds an address to assign to the mobile node. The home agent, by definition, has an interface on the mobile node's home link. Using this interface and the mobile node's NAI, it can generate the necessary DHCP messages as a DHCP proxy in an attempt to obtain an address which it can assign to the mobile node. S. Glass Expires 7 December, 2000 [page 1] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 2. Overview A mobile node which is away from home without a home address follows the proceedures detailed in [3], specifically sending a registration request containing a zero home address to it's home agent, includes an NAI extention, and appends a MN-HA identifier as detailed in [1] to authenticate itself to the home agent (or a MN-AAA authenticator to identify itself to the home AAA server if that method of authentication is used). Upon receiving such a registration, the home agent must get an address to pass back to the mobile node in the home address field of the registration reply. The home agent can now play a role similar to that of a DHCP proxy agent generating DHCP messages as described in [2] on behalf of the mobile node, as detailed below, in hopes of ultmately obtaining a suitable address for use as the mobile node's home address. It is important to understand the exact role the home agent is playing in this scenario. The home agent is not playing the roll of a DHCP relay, as it is not relaying any DHCP messages on behalf of the mobile node. From one perspective it is behaving as a DHCP proxy, generating DHCP mssages on behalf of a mobile node. In another perspective, it is simply obtaining an address it will be using on one of its own interfaces, namely an interface attached to the mobile node's home link. In this regard, the home agent is purely DHCP client. Should the mobile node return home, it will likely want to assume ownership of this IP address, so in this light we will consider the home agent as performing the job of a DHCP proxy, and will refer to it as such for consistency. 2.1 Mobile IPv4 with DHCP, and Mobile IPv6 with DHCPv6 As the relationship of the mobile node and the home agent doesn't change in regard to the home agent obtaining an address for a mobile node in mobile IPv6, it would be nice if it were possible to use the same mechanism in mobile IPv6 for a node to obtain a DHCPv6 address in the analogous way. In this case, mobile ip registration requests should be sent as in [10] with the NAI extension appearing after the registration request, and before the MN-HA or MN-AAA authenticator as described in [3]. The home agent would then generate DHCP messages as described in [11], obtaining an IPv6 address for use as the mobile node's home address. This document attempts to treat the IPv4 and IPv6 cases together, providing a mechanism to be used in either situation. As the majority of documents referenced here are works in progress, however, this document may need to be updated upon their completion. 3. Operation of a Home Agent as a DHCP Proxy Agent This section describes the proceedure a home agent should follow upon receiving an authenticated registration request from a mobile node requiring a home address in order to behave as a DHCP proxy agent, and the responsibilities imposed on the home agent as a result. S. Glass Expires 7 December, 2000 [page 2] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 3.1 The Initial Registration Request 1. The HA receives an authenticated registration request as defined in [1] for a mobile node which it is willing to service, and for which it does not have a current binding, and for which a home address needs to be assigned. This appears in the form of a mobile ip registration request containing a zero mobile node home address, an NAI extension, and MN-HA authenticator as described in [3] (or MN-AAA authenticator if that security model is in use). If the regisration request is unacceptable, the appropriate error code as defined in [1] or [3] MUST be returned to the mobile node's care-of address. 2. If the registration request has been authenticated as coming from the mobile node identified by the NAI contained in the registration request, the Home Agent builds a DHCPDISCOVER as defined in [2] exactly as it would to obtain a[nother] IP address for one of its links defined as being on the mobile node's home link (htype, hlen, chaddr, etc), with the following difference. The client identifier option (type 61) as defined in [4] MUST be included, wherein the type field MUST be set to 0, and the identifier MUST be set to the NAI as sent by the mobile node in the NAI extension. As the Client ID option (type 51) allows for up to one octet for length, a client id of up to 255 characters allows more than enough space for the up-to 128 character NAI [5]. Furthermore, an IP Address Lease Time option (type 51) SHOULD be included. The lifetime requested in the IP Address Lease Time option of the DHCP request SHOULD be the shorter value of the of either the lifetime appearing in the registration request, or the lifetime the home agent is willing to grant in a registration reply to this mobile node [1]. In addition, sname, giaddr, and yiaddr MUST be NULL, and hops is set to 0. The home agent MAY also include the DHCP Mobile IP Home Agent option [4]. If the home agent includes this extension, it MUST set the home agent address to the address apearing in the home agent field of the registration request, or the address belonging to the home agent on the link that will be servicing the mobile node. Note: this DHCP message may go through a DHCP relay agent. The home agent behaves no differently than as described above. 3. The home agent waits a configured amount of time for a DHCPOFFER from the DHCP server. It is recommended that the Home Agent wait no less than DHCPDISCOVER_TIMEOUT seconds for such a reply [2]. If no reply is received within that time period, and the home agent has no other pool from which it can assign addresses to the mobile node, it MUST return error 99 "Missing Home Address" as described in [3]. If the DHCPOFFER is received, it is processed, specifically for an acceptable home IP address, and lifetime. If the data in any field of the DHCPOFFER, specifically these two, are unacceptable, the home agent SHOULD attempt to negotiate these with the DHCP server. S. Glass Expires 7 December, 2000 [page 3] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 If the DHCPOFFER includes the Mobile IP Home Agent option (type 68), the home agent SHOULD compare the address contained in this option with its own, specifically the address identified as the home agent address in the registration request, or the address on the link that will be servicing the mobile node. If the address is NOT the same as the address being identified as the home agent address, the home agent MUST generate a registration reply with error 136 "Unknown Home Agent Address". As with home agent discovery [1], this should prompt the mobile node to choose a different home agent with which to register. (Think: the home agent SHOULD also put the address of the home agent returned in the Home Agent Option in the home agent field of the registration reply). (Think: Furthermore, this home agent SHOULD not reply to further home agent discovery packets from this mobile node for the duration of the lifetime appearing in the registration request). Upon receiving an acceptable DHCPOFFER, the home agent MUST transmit a DHCPREQUEST for the IP address being offered to the unicast address of the DHCP server as described by [2], and awaits a configured amount of time for a DHCPACK. It is recommended that the home agent wait at least DHCPREQUEST_TIMEOUT seconds for the DHCPACK from the DHCP server. If no reply is received to the DHCPREQUEST, the home agent MUST generate another DHCPREQUEST for an address apearing in another DHCPOFFER from a DHCP Server, or MAY transmit another DHCPDISCOVER as in (1) above, or, if no other address assignment mechanism is available, the home agent MUST send a registration response to the mobile node with error 99 "Missing Home Address" as described in [3]. 4. Upon recieving a DHCPACK with a suitable IP address and lifetime for the mobile node, the home agent MUST query the network for the address, as in the usual duplicate IP address detection mechanisms as is described in [2]. If the address is in use, the home agent SHOULD transmit another DHCPREQUEST for an address appearing in another DHCPOFFER from a DHCP Server, or transmit another DHCPDISCOVER message. If a DHCPNAK is received instead, the home agent MUST do one of the following: either renegotiate with the DHCP server, send out another DHCPREQUEST for an address appearing in another DHCPOFFER from a DHCP Server, send out another DHCPDISCOVER as described in (1) above, or if no other address assignment mechanism is available, send a registration response to the mobile node with error 99 "Missing Home Address" [3]. Think: what about the other possible responses to the DHCPREQUEST? 5. If the address in the DHCPACK is deemed suitable for use as an IP address for this interface, and as a home ip address for the mobile node, the home agent puts this address into the home address field of the registration reply. The home agent MUST also fill in the lifetime of the registration reply with the shortest value of either the lifetime appearing in the registration request, the lifetime normally granted by the home agent, or the lifetime granted by the DHCP server. S. Glass Expires 7 December, 2000 [page 4] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 The home agent MUST also include the NAI option as per [3], and append the usual HA-MN authenticator as described in [1], or the HA-AAA authenticator if that security mechanism is in use. The home agent MUST also claim, and defend the address as described in [3]. If no suitable address can be obtained from a DHCP agent, and no other method of obtaining an address is available, the home agent MUST send a registration reply to the mobile node with error 99 "Missing Home Address" [3]. 3.2 Re-registration Requests This sections details the behaviour of a home agent upon receiving a registration request from a mobile node for which it already has a binding. 1. The mobile node sends a registration request to a home agent with which it already has a binding. It MUST include either the IP Address assigned to it by the home agent, or the 0 address in the home address field of the registration request, and it MUST include the NAI that it originally used to obtain the binding and address. 2. The home agent receives an authenticated registration request, it MUST check to see if already has a binding, and is providing home agent services for this mobile node. This determination can be based on NAI, or (non-zero) home address. Before sending a registration reply to the mobile node's care-of address, the home agent MUST use the NAI, or (non-zero) home address to check to see if this mobile node was assigned a DHCP administered home address, and, if the home address appearing in the current registration request is non-zero, make sure the mobile node is using the same home address it was assigned in the previous registration using the NAI. If the registration request contains the zero address, the home agent MUST associate the address which was assigned to the mobile node's NAI by DHCP. 3. If the address the mobile node is using was assigned by DHCP, the home agent builds a DHCPREQUEST message exactly as it would for any DHCP address it were renewing as in [2] with the same exceptions as described in section 3.1 above. The message is unicast to the DHCP server that assigned the mobile node's current home address, the IP address being renewed (appearing in the yiaddr and ciaddr fields) MUST be set to the mobile node's home address, and the Client ID option (type 51) MUST be included with the type field set to 0, and the client-id set to the mobile node's NAI appearing in the registration request. The home agent SHOULD include the IP Address Lease Time option, where the lifetime is the shorter of either the lifetime appearing in the registration request, or the lifetime the home agent is willing to grant is placed in the IP Address Lease Time option. The home agent MAY also include the Mobile IP Home Agent option (type 68) with the address set to the home agent address appearing in the registration request, or the address of the home agent on the interface that will be servicing the mobile node. S. Glass Expires 7 December, 2000 [page 5] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4. The home agent waits a configured amount of time for the DHCPACK. It is recommended that the home agent wait at least DHCPREQUEST_TIMEOUT seconds for the reply from the DHCP server. If a DHCPACK is received within this time, the home agent checks the IP address, and lifetime. If they are acceptable, meaing the IP address is identical to what the mobile node is using as appears in the home address field of the registration request, the home agent generates a registration reply to be sent to the care-of address appearing in the registrtion request, includes the IP address returned by the DHCP server, and the shorter lifetime of either that appearing in the reregistration request, what it is configured to approve, or that of the address lease granted by the DHCP server and appearing in the DHCPACK. Note: due to the nature of mobile ip, an IP address returned by the DHCP server that is different from that which is already granted is not acceptable. Should it be impossible, for some unknown reason, for the home agent to get the address currently being used by the mobile node as its home address, the home agent MUST reply with error 99, "Missing Home Address". 3.3 De-registration Requests Upon returning home the mobile node will deregister with the home agent as described in [1]. The moblile node generates a registration request with a lifetime of 0, and MUST use either the address assigned to it most recent registration reply from this home agent, or the 0 address and the NAI it used in its most recent registration request. The home agent MUST authenticate the [de]registration request, and if a non-zero address appears as the mobile node's home address MAY verify the mobile node is using the address it was assigned. If not, the home agent MAY return error 99, "Missing Home Address". Otherwise, the home agent behaves as descrbed in [1] pertaining to deregistering mobile nodes. The home agent MUST NOT transmit a DHCP release message for the mobile node's home address; the mobile node may still need it. Once the mobile node has been successfully deregistered, the responsibility for renewing, and defending this address belongs to it. It SHOULD immediately send out a DHCPDISCOVER message as described by [2] even though it knows the lease is otherwise good for the unused balance of the previous registration. The mobile node MUST include the Client ID option (type 51) with the type set to 0, and the client-id set to the NAI which was originally used to obtain the lease via the home agent, and MAY include a requested IP Address option (code 50) with the address set to the home address it is using. The mobile node MAY also include the IP Address Lease Time option (code 51), and any other option it wishes, including the Mobile IP Home Agent option for future reference. S. Glass Expires 7 December, 2000 [page 6] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 In response to this DHCPDISCOVER message, the mobile node should receive one or more DHCPOFFER messages. The mobile node SHOULD parse these messages looking for the address it is using as its home address, then identify and remember the DHCP server assigning this address. At this time the mobile node generates a DHCPREQUEST for the address received in the DHCPOFFER, and awaits the DHCPACK from the DHCP server. The mobile node SHOULD also cache the DHCPACK received from the DHCP server for future reference [2]. Note: A DHCPDISCOVER message is generated, and NOT a DHCPREQUEST for two reasons. Firstly, the mobile node is not likely to know the unicast address of the DHCP server assigning its home address. Secondly, some parameters in the DHCPDISCOVER may be different such as htype, chaddr, and hlen (e.g. bridged networks of different hardware-level topology). These MUST now be set to those that are appropriate for the mobile nodes home interface. ------------ Think: for minimal mobile node implementations ------------- If the mobile node wishes the home agent to continue to renew its address lease, it MUST deregister using the DHCP aquired address as its home address, and 0 as the care-of address, setting the lifetime to 0. As this is not a legal deregistration request as described by [1], the home agent can assume the mobile node is aware of it's DHCP aquired address, and is asking the home agent to continue renewing its address lease. If a home agent receives such a deregistration request, it MUST check that the mobile node issuing the deregistration request did indeed obtain its home address through DHCP, matching the address with the NAI. The home agent, upon approving the deregistration, renews the mobile node's home address with the DHCP server using the NAI in the Client ID option, and MAY include the IP Address Lease Time option (code 51). If the renewal is not successful, the home agent MUST send a registration reply to the mobile node with error 99, "Missing Home Address". Alternatively, if the home agent does not support lease maintenence while the mobile node is deregistered, it MUST return error XX, "DHCP lease maintenance not allowed." In this scenario, if the mobile node wishes to continue to use the address assigned to it, it MUST send out DHCPDISCOVER message as described above, and attempt to renew the lease immediately upon successfully deregistering. If the renewal is successful, the home agent sends a successful registration reply to the mobile node, setting the lifetime to the value it wishes the mobile node to contact it in precisely the same way as described here so the home agent can renew the DHCP lease for the mobile node. Note: the lifetime included in the registration reply MAY be the lifetime returned by the DHCP Server, or it MAY be some other value. The mobile node should use the same registration renewal algorithm it uses to renew its mobile ip binding while away from home. The mobile node MUST also claim the address on the link, and defend it as it would any other address it is using. ------------- Fin: for minimal mobile node implementations ------------- S. Glass Expires 7 December, 2000 [page 7] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 3.4 Address Responsibilities The home agent, in negotiating for a home address for the mobile node, has been given an (additional) IP address for one of its interfaces. It is also acting on behalf of the mobile node that it is providing home agent services for. As a result, the home agent MUST defend this address as it would any other home address registered by a mobile node [1]. Furthermore, the home agent MUST remember this address, that the address was obtained through DHCP, the address of the DHCP server that granted it, and the mobile node's NAI. The home agent MAY cache the DHCPACK for future reference. The mobile node uses this address as it would any address assigned to it (by the home agent) including the exceptions described by [1] in relation to what it MUST and MUST NOT do while on the foriegn subnet. When using this address on its home subnet, it MUST defend this address itself as it would any address it is using. 4.0 New DHCP-Specific Mobile IP Options For optimizations, and enhancements, this document defines the following OPTIONAL extensions. In each case, what is required for the home agent and mobile node to support is detailed. The extensions for the mobile node to use are in the range 128-255, which as specified by [1] are ignored (by the home agent) upon receipt if not understood. In this way, a home agent which does not understand these extensions will ignore them, the registration request will NOT be silently discarded, and the mobile node's registration will be processed. Conversely, the home agent reply extentions are in the range 0-127. In this way, if a mobile node receives a registration reply which contains an extension giving it some special information which it does NOT understand it will silently discard the entire registration reply, and attempt to reregister (with a different home agent). A home agent MUST NOT insert any DHCP-related mobile IP extensions in a registration reply to a mobile node from which it did not receive a DHCP-related mobile IP extension. As these are optional extensions, and support is not required to be compliant with this specification, the appropriate assumptions which can be made by either side is specified depending on the level of support provided by each end. In addition, allowable responses by home agents and mobile nodes when using these extensions is detailed in the appropriate sections. All DHCP options conform to the requirements laid out in [7]. S. Glass Expires 7 December, 2000 [page 8] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4.1 Mobile IP DHCP Address Extension A mobile node wishing to obtain a DHCP address lease SHOULD include the following extension in its registration request. This extension MUST appear before the MN-HA or MN-AAA authenticator, and SHOULD appear after the NAI extension. The "Mobile IP DHCP Address" extension is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 0 9 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | Length |A|L|S| reserved ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 200(TBA) "Mobile IP DHCP Address" extension Length The number of bytes of the whole extension (MUST be word aligned). Currently 4 (may be extended) A 0 or 1 Set to 1 if the mobile node wishes to get the address of the DHCP Server. L 0 or 1 Set to 1 if the mobile node wishes to get the DHCP lease lifetime of the address. S 0 or 1 Set to 1 if the mobile node wishes to get the subnet mask of its home link. Note: it is not necessary for any of the bits to be set. The presence of the "Mobile IP DHCP Address" extension is sufficient to imply the mobile node wishes to be assiged a DHCP administered address. If the mobile node doesn't care to be informed of any of this information, it MAY opt to leave each of the A, L, and S bits unset. If a home agent receives a registration request containing a Mobile IP DHCP Address Request extension, it SHOULD first attempt to obtain an address through DHCP. If it is able to obtain the address through DHCP, it MUST include this extension in the reply before the HA-MN or HA-AAA authenticator, and after the NAI extension. The home agent SHOULD also set the bits corresponding to the information it is returning to the mobile node. If the home agent is unable to obtain an address through DHCP, it MAY try another mechanism to obtain an address, in which case it MUST NOT include the "Mobile IP DHCP Address" extension in the registration reply. If the home agent can not obtain a home address for the mobile node through any means available to it, the home agent MUST return error 99 "Missing Home Address". Mobile nodes which include this extension in their registration requests SHOULD NOT expect notification from the home agent that the address they are getting is DHCP administered. The mobile node MUST assume in the absense of DHCP related extensions that any home address it receives in the registration reply is maintained by the home agent. If a mobile node includes this extension with the A bit set to 1, it MUST be prepared to perform its own lease maintenance (see section 4.2) as a home agent returning this extension, and a Mobile IP DHCP Server IP Address extension (defined below) will not be maintaining a DHCP lease for the mobile node. S. Glass Expires 7 December, 2000 [page 9] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4.2 Mobile Node's Maintaining Their Own DHCP Leases It would be useful for a mobile node to manage it's own DHCP administered address from the foreign domain. This can only happen in situations where a reverse tunnel exists, either through a foreign agent, or with a colocated care-of address. Lease renewal requires DHCPREQUEST messages be unicast to the DHCP server, and therefore requires knowledge of the DHCP Server IP addrss. In this way a mobile node can have DHCP messages delivered to (and from) the home domain, and can immediately continue to maintain its DHCP lease, possibly without the need to broadcase a DHCPDISCOVER message, upon returning to the home link. 4.2.1 Mobile IP DHCP Server IP Address Extension In order to maintain their own leases, the mobile node must minimally know the IP address of the DHCP server. The "Mobile IP DHCP Server Address" extension is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | IP version no.| DHCP Server IP Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 54(TBA) "DHCP Server IP Address" extension IP version number 4 or 6 The IP version of the address DHCP Server IP Address The IP address of the DHCP server If the DHCP server address is an IPv4 address, the IP version number MUST be set to 4, and there MUST be 4 octets of address in the DHCP Server IP Address portion of the extension. If the DHCP server address is an IPv6 address, the IP version number MUST be set to 6, and there MUST be 16 octets of address in the DHCP Server IP Address portion of the extension. In either case, the extension is word-aligned. Note: This mechanism makes it possible for a mobile node to obtain an IPv6 address via DHCPv6 from its home link by using a mobile IPv4 registration request. It may then use the usual mobile IPv6 mechanisms to inform correspondent nodes of its location, etc. [10] S. Glass Expires 7 December, 2000 [page 10] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4.2.2 Mobile IP DHCP Lease Lifetime Extension Knowing the lifetime granted by the DHCP server may also be useful for mobile nodes maintaining their own leases who do not wish to renew on every mobile ip reregistration. If a mobile node were to have to do this, it may opt instead to have the home agent renew its DHCP lease. It also allows mobile nodes to determine if immediate lease renewal is necessary upon returning to their home network. The "Mobile IP DHCP Lease Lifetime" extension is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Lifetime ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (lifetime continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 51(TBA) "Mobile IP DHCP Lease Lifetime" extension Length 4 (Same as IP address lease time option (51)[4]) Lifetime The lifetime of the lease for the address appearing in the home address field of this registration reply. This value MUST be copied from the DHCPACK message as sent by the DHCP Server. If the mobile node is renewing its own DHCP leases, it MAY renew the lease any time it wishes. If it has no knowledge of it DHCP lease lifetime, the mobile node SHOULD attempt renew its DHCP lease immediately prior to renewing its mobile ip registaration. S. Glass Expires 7 December, 2000 [page 11] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4.3 Mobile IP Home Subnet Prefix Length Extension A home subnet prefix is useful to the mobile node to do move detection to the home subnet. Without it, the mobile node must hear becons specifically from its home agent to know that it is home. Though requestable by the mobile node itself (through DHCPINFORM, see below), a home subnet mask extension is useful enough that it is defined here so the information can be delivered to the mobile node in the initial registration reply. The "Mobile IP Home Subnet Prefix Length" extension is defined as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1(TBA) "Mobile IP Home Subnet Prefix Length" extension Prefix The number of bits of prefix as indicated by either the subnet mask option in the DHCPACK (converted to "bits of subnet"), or the prefix- len returned for an IPv6 link, and which MUST be applicable to the home address returned in the mobile ip registration reply. Note: the DHCP server will return the prefix of the address being leased in dotted-decimal notation for IPv4 addresses. The home agent MUST convert this into the above format by counting the number of leading bits in the subnet mask option of the DHCPACK. This "dualism" of dotted-decimal mask and prefix-length already exists in mobile IP as "Prefix Length" extensions in mobility agent becons and will not cause confusion if treated in the analogous fashion. If for some reason the DHCP server returns a subnet mask which, in its dotted-decimal format is not convertable to the above format, the "Mobile IP Home Subnet Prefix Length" extension MUST NOT be included in registration replies returned to the mobile node. 4.4 Requesting Other DHCP Information by use of DHCPINFORM Once the mobile node has the IP address of its DHCP Server, the mobile node MAY build a DHCPINFORM message, and unicast it to its DHCP Server as defined in [2]. Such a message can request any information listed in [2], or [4]. If, for example, the home agent did not include a "Mobile IP Home Link Prefix Length" extension, the mobile node may itself request to be informed of the prefix lengh (subnet mask) associated with its address. It is not known how DHCP Servers will respond to a DHCPINFORM message from a node looking for the lifetime of it's lease. It is advised that a mobile node that does not receive a Mobile IP DHCP Lease Lifetime extension renew their leases upon each successful mobile IP registration renewal. S. Glass Expires 7 December, 2000 [page 12] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4.5 Using Home Agents that don't Support Mobile IP DHCP Extensions It is recommended that if a mobile node does not recieve any DHCP extensions from the home agent, particularly in response to a registration request containing a "Mobile IP DHCP Address" extension, assume its address was obtained in some generic way by the home agent, and is maintained by the home agent (either through DHCP, or some other means). The method described below is not recommended as it is not known how all DHCP server implementations will react to DHCPDISCOVER messages coming from a non-zero IP source address. Moreover, it means the home agent is unaware that the mobile node is maintaining its own lease for this address, and may already be maintaining the lease on the mobile node's behalf. In general this shouldn't be a problem, but it means more work for mobile node, home agent, DHCP server, and more bandwidth utilization on the home link, and all links comprising the forward and reverse tunnels. If a mobile node is registered with a home agent which does not support these extensions, it MAY transmit a DHCPDISCOVER message containing the NAI it used to register with the home agent in the client ID option (see section 3 above) back to its home link using the mechanisms to reverse tunnel broadcast datagrams as described by [6]. This means the DHCP assigned address will be the source address of the DHCPDISCOVER message eminating from the home agent, and NOT the usual 0 address. In response, the mobile node may then receive multiple DHPCOFFERS, from which it chooses the server offering the lease to the address it is now using as the destination of subsequent DHCPREQUESTs used in lease maintenence. If no such DHCP Server can be identified, the mobile node MUST assume the address will be maintained by the home agent. 5.0 Other Considerations This section covers considerations relating to the interaction of mobile ip, and DHCP. 5.1 Additional Error Codes As this document primarily concentrates on the use of DHCP in a mobile IP environment, there are no additional error codes defined for basic operation. ------------ Think: for minimal mobile node implementations ------------- There are, however, additional error codes defined for lease maintenence in section 3.3. ------------ Fin: for minimal mobile node implementations ------------- S. Glass Expires 7 December, 2000 [page 13] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 5.2 Returning Information from Other DHCP-Specific Options/Codes Without supporting optional DHCP extensions in mobile IP, there is no way to proxy information other than the home address, and perhaps a hint as to the DHCP lease time, to a MN. Therefore, there is little to be gained from the home agent including any other options in the DHCPDISCOVER or DHCPREQUEST other than those mentioned in section 3: Client ID option (code 61), IP address Lease Time option (code 51), Requested IP Address option (code 50), and possibly Mobile IP Home Agent option (code 68). Using the method outlined in section 4.4, however, a mobile node can use a DHCPINFORM message to obtain any information about its home subnet it desires, and through mobile IP, by a mechanism as if it were at home. As a result, there is only a limited need for DHCP extensions to mobile IP to help optimize the use of DHCP by the mobile node and home agent. 6.0 Caveats and Cautions The use of DHCP with mobile ip, while allowing address management to be centralized, comes with some caveats, and cautions which site administrators should be aware of. 6.1 Home Address Availability There is no guarantee that DHCP administered addresses will be available to a node, even in non-mobile ip situations. A way around this, however, which is not available to non-mobile IP aware nodes is for a mobile node to be configured with multiple home agents on different links, or multiple link prefixes in the home domain for home agent discovery. In this way, if one home agent is unable to obtain an address lease for the mobile node, the mobile node may send a registration request to a home agent on a different link (using the same NAI) in hopes of obtaining a home address there. Moreover, a mobile node may obtain home addresses on different links using the same NAI. 6.2 Home Address Consistency As with any address assignment mechanism, there is a chance a mobile node will not be able to obtain the same IP address it had been using in the past. This refers, of course, to an IP addresses for which the mobile node's binding is no longer valid, or certainly for which the DHCP lease has expired. The mobile node should take care to never allow a binding to expire for an IP address it may be dependant on. This applies not only to IP addresses obtained through DHCP, but any address allocated by the home agent. Although a DHCP server SHOULD return the IP address used in a previous binding by the same node [2], there is no guarantee the address will be available. This is exactly the same as in the case where the home agent is itself handing out addresses from its own pool. Should the home agent be itself administering addresses, and such an address is implicity returned to the address pool because a mobile node allowed its registration to expire, there is no guarantee that address will be available to the same mobile node in a subsequent session unless the S. Glass Expires 7 December, 2000 [page 14] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 home agent is reserving one IP address per potential mobile node, and is therefore reserving specific IP addresses for individual mobile nodes. The idea of providing IP addresses from an address pool, however, is to reuse addresses, if not allow the number of addresses needed to be minimized, so such a home agent configuration seems to defy the intent of dynamic IP address configuration. In the case of PPP assigned addresses, common practice seems to be to permanently assign one IP address per dial-in line, but this situation is not analogous as only one host can be connected to a dial-in line at a time, and thereby there is no risk of multiple nodes needing this address simultaneously, nor needing to obtain the same address across different PPP sessions. 6.3 Multiple DHCP Addresses If for some reason the mobile node wishes to obtain additional addresses on the home link, while it seems possible for it to reverse tunnel DHCPDISCOVER messages as described in [1] and [6] to its home link, DHCPOFFERS arriving at the interface of the home agent on the mobile node's home link will not contain enough information for the home agent to know where to deliver them. While it may be possible for home agents to examine the contents of the decapsulated reverse tunnel traffic, and note that it is sending a DHCPDISCOVER on behalf of the mobile node, this is not recommended, and can lead to problems when more than one mobile node is doing so simultaneously. Instead, mobile node's requiring multiple addresses MUST have one NAI per required address on each of the required links. Therefore, if a mobile node has two interfaces each requiring a different address on the same home link, it MUST have two NAIs, but if these interfaces are on separate home links, only one NAI is required. If a mobile node has simultaneous DHCP leases, the way DHCP does lease renewal requires each lease to be renewed independantly. This is the case if the mobile node is maintaining its own leases, or if the home agent is doing lease renewal on behalf of the mobile node. 6.4 Selecting an NAI Of concern are allowable characters that can be placed both in NAIs, and the Client ID option. [4] specifies the Client ID option, and [5] specifies the character set and format restrictions for the NAI. At this time, there do not appear to be any conflicts with the requirements laid out in [5] on NAI character restrictions, and those restrictions placed on the Client ID option in [2]. System Administrators are advised, however, to limit their assigned NAIs to the intersection of the requirements as they may change over time. S. Glass Expires 7 December, 2000 [page 15] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 6.5 DHCPINFORM Caveat It is not known how DHCP Servers will respond to a DHCPINFORM message from a node looking for the lifetime of it's address lease. It is advised that a mobile node that does not receive a Mobile IP DHCP Lease Lifetime extension not attempt to query the DHCP Server for this information, and allow the home agent to renew its lease. 7.0 Security Considerations The Mobile IP protocol requires the use of MN-HA or MN-AAA authenticators to provide authentication of the MN to the HA/home subnet. Whenever a registration request is received by a home agent it MUST be authenticated as having been sent by the MN identified by either the home address, or if the home address is set to the 0 address, the NAI option appended to the registration request, but appearing before, and thereby protected by, the MN-HA or MN-AAA authenticator. As a result, the DHCP address being requested by home agents on behalf of mobile nodes they are servicing are being assigned to machines which have been authenticated as belonging to the home domain, and more specifically, are part of the subnet the assigned address belongs to. Moreover, as there is a one-to-one mapping between NAI and Client ID, only one address per NAI will be assigned per link, thereby preventing a situation where subnet addresses would be more exhausted than if the mobile nodes were making the DHCP requests on their own. 8.0 Compliance Statements 8.1 Mobile IP Compliance Statement Whereas this document follows mobile node and home agent proceedures and requirements described in the mobile IP document draft-ietf-mobileip-rfc2002-bis-LATEST.txt, which, upon obtaining RFC status, will obsolete [1], mobile nodes complying with [1] (and [2], and [3]) should function properly when interacting with home agents complying with [1] (and [2], and [3]) and this specification. 8.2 DHCP Compliance Statement Whereas this document details RFC2131, which obsoletes RFC1541, all that is required is for a home agent and the DHCP server to follow DHCP Client and Proxy requirements in RFC1541. 9.0 Acknoledgements The author wishes to greatfully acknowledge the help provided by David Miner, Carl Smith, and Michael Carney, all of Sun Microsystems. Their knowledge of DHCP far surpasses mine, and were able to help fill in many of the DHCP implementation details I was not clear on. S. Glass Expires 7 December, 2000 [page 16] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 10.0 Author's Name and Address Comments should be sent to the mobileip mailing list: mobile-ip@standards.nortelnetworks.com or to the author: Steven M. Glass Steven.Glass@sun.com Sun Microsystems 1 Network Drive Burlington, MA. 01803 Office: 1.888.555.9SUN Fax: 1.781.442.1677 11.0 References [1] RFC2002, "IP Mobility Support", C. Perkins, October 1996 [2] RFC2131, "Dynamic Host Configuration Protocol", R. Droms, March 1997 [3] RFC2794, "Mobile IP Network Access Identifier Extension for IPv4", P. Calhoun and C. Perkins. March 2000. [4] RFC2132, "DHCP Options and BOOTP Vendor Extensions", Alexander & Droms, March 1997. [5] RFC2486, "The Network Access Identifier", B. Aboba, M. Beadles, January 1999. [6] RFC2344, "Reverse Tunneling for Mobile IP", G. Montenegro, May 1998 [7] RFC2489 "Procedure for Defining New DHCP Options", Droms, January 1999 [9] Glass, S. "Mobile IP Registration Revocation", Work In Progress. [10] D. Johnson and C. Perkins, "Mobility Support in IPv6", Work In Progress. [11] J. Bound, M. Carney, and C. Perkins, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work In Progress. S. Glass Expires 7 December, 2000 [page 17] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 12.0 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. 13.0 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: Raj.Patil@nokia.com EMail: QA3445@email.mot.com Fax : +1 972-894-5349 S. Glass Expires 7 December, 2000 [page 18]