idnits 2.17.1 draft-glass-mobileip-agent-dhcp-proxy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2.0 Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7.0 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [10], [11], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 103: '...ome ip address, it MUST contain an NAI...' RFC 2119 keyword, line 123: '...home agent MUST get an address to pass...' RFC 2119 keyword, line 162: '... IPv6 link, the home agent MAY use the...' RFC 2119 keyword, line 181: '...unacceptable, the appropriate error code as defined in [1] or [3] MUST...' RFC 2119 keyword, line 191: '...identifier option (type 61) as defined in [4] MUST be included,...' (102 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (2 March 2000) is 8820 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1008 looks like a reference -- Missing reference section? '2' on line 1010 looks like a reference -- Missing reference section? '3' on line 1013 looks like a reference -- Missing reference section? '10' on line 1030 looks like a reference -- Missing reference section? '11' on line 1033 looks like a reference -- Missing reference section? '4' on line 1016 looks like a reference -- Missing reference section? '5' on line 1019 looks like a reference -- Missing reference section? '7' on line 1025 looks like a reference -- Missing reference section? '6' on line 1022 looks like a reference -- Missing reference section? '9' on line 1028 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Glass 2 INTERNET DRAFT Sun Microsystems 3 Mobile IP Working Group 2 March 2000 5 Mobile IP Agents as DHCP Proxies 7 draft-glass-mobileip-agent-dhcp-proxy-01.txt 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 This document is a submission to the Mobile IP Working Group of the 15 Internet Engineering Task Force (IETF). Comments should be submitted 16 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Distribution of this memo is unlimited. 35 Abstract 37 Since the inclusion of the Network Access Identifier (NAIs) into 38 the mobile IP fabric, home agents have had a way to identify mobile 39 nodes which do not have home IP addresses. After authenticating the 40 registration request from such a mobile node, the home agent is then 41 expected to assign a home addresses to the mobile node in the 42 registration reply to be used on a semi-permanent basis. 43 Unfortunately, no specific mechanism has yet been proposed. Ideally, 44 as DHCP centralizes address management, if there was a way for a home 45 agent to contact a DHCP server to allocate an address for the mobile 46 node, it would preserve DHCP as the central address maintainer. The 47 technology does exist for a Home Agent to use DHCP controlled 48 addresses, namely for the Home Agent to behave as a DHCP proxy agent 49 acting on behalf of the mobile node. 51 This document specifies the procedure a Home Agent should follow 52 when contacting a DHCP server to obtain one or more home addresses for 53 mobile nodes that require them. Moreover, it does so in the spirit of 54 the design goals of [1], and [2] (section 1.6). It also specifies the 55 responsibilities of the home agent with regard to defending this 56 address, and maintaining it as appropriate. Obviously, simply 57 supporting home address assignment of any kind at the home agent 58 requires changes to the home agent, and so the most desireable 59 implementation solution is to not require changes to any other mobile 60 IP entity. This document enhances the behaviour of the home agent in 61 a way so that no enhancements to the behaviour of a mobile node which 62 is compliant with [1] and [3] is required. A clearer picture is also 63 presented as to what needs to be addressed when a mobile node is not 64 assigned a home address before it roams away from its home link, and 65 the complications that can result in various mobile IP situations 66 while the mobile node is attached to foreign links. 68 As always, optimizations and enhancements to such a mechanism can 69 be made, in this case proposing changes to both home agent and mobile 70 node. These changes are specified as optional extension support, and 71 are not required for compliance to this draft by a home agent 72 implementation; the exchange of extensions is defined in such a way 73 that if one side does not understand them, interoperability is still 74 acheived. 76 1. Introduction 78 Mobile IP was designed to give nodes the ability to leave the 79 confines of their home subnet, allowing them to not only to keep their 80 current connections active, but to also start and accept new 81 connections while visiting foreign links through an agent on their 82 home subnet, known as the home agent. Recent enhancements [3] to 83 mobile IP have even allowed nodes which do not yet have an IP address 84 to connect to their home subnets, and receive an address through their 85 home agent. No mechanism describing how the home agent is to obtain 86 such addresses has been proposed, however. 88 The ideal method would be to have the mobile node receive an 89 address from the same address pool as it would if it were at home, 90 most likely the DHCP address pool on it's home network. Obtaining an 91 address directly is difficult since the only concept of a home 92 network to DHCP is the network on which the node is currenly residing. 93 Special enhancements to DHCP would have to be devised to get the DHCP 94 messages to, and from the home subnet, and it is likely such 95 enhancements would imitate functionality already designed for mobile 96 ip. Moreover, a solution independant of the mobile ip services being 97 offered on the visited link (such as reverse tunnelling and 98 broadcast/multicast support) is desireable. 100 The mechanism used to authenticate a mobile node's request for a 101 home address already exists in the NAI extension of the mobile IP 102 registration process [3]. When the home agent receives a registration 103 request containing a zero home ip address, it MUST contain an NAI 104 extension which it uses to locate the shared secret between the mobile 105 node and itself, verifying the MN-HA authenticator contained in the 106 registration request (if a MN-AAA authenticator appears instead, 107 authentication is done using that at the AAA server). The HA then 108 finds an address to assign to the mobile node. The home agent, by 109 definition, has an interface on the mobile node's home link. Using 110 this interface and the mobile node's NAI, it can generate the 111 necessary DHCP messages as a DHCP proxy in an attempt to obtain an 112 address which it can assign to the mobile node. 114 2.0 Overview 116 A mobile node which is away from home without a home address 117 follows the proceedures detailed in [3], specifically sending a 118 registration request containing a zero home address to it's home 119 agent, includes an NAI extention, and appends a MN-HA identifier as 120 detailed in [1] to authenticate itself to the home agent (or a MN-AAA 121 authenticator to identify itself to the home AAA server if that method 122 of authentication is used). Upon receiving such a registration, the 123 home agent MUST get an address to pass back to the mobile node in the 124 home address field of the registration reply. 126 The home agent can now play a role similar to that of a DHCP proxy 127 agent generating DHCP messages as described in [2] on behalf of the 128 mobile node, as detailed below, in hopes of ultmately obtaining a 129 suitable address for use as the mobile node's home address. 131 It is important to understand the exact role the home agent is 132 playing in this scenario. The home agent is not playing the roll of a 133 DHCP relay as it is not relaying any DHCP messages on behalf of the 134 mobile node. From one perspective it is behaving as a DHCP proxy, 135 generating DHCP mssages on behalf of a mobile node. From another 136 perspective, it is simply obtaining an address it will be using on one 137 of its own interfaces, namely an interface attached to the mobile 138 node's home link. In this regard, the home agent is nothing more than 139 a DHCP client. Should the mobile node return home, it will likely 140 want to assume ownership of this IP address, so in this light we will 141 consider the home agent as performing the job of a DHCP proxy, then 142 using the address it assignes to the mobile node in accordance with 143 [1], and will refer to it as a DHCP Proxy for consistency. 145 2.1 Mobile IPv4 with DHCP, and Mobile IPv6 with DHCPv6 147 As the relationship of the mobile node and the home agent doesn't 148 change in regard to the home agent obtaining an address for a mobile 149 node in mobile IPv6, it would be nice if it were possible to use the 150 same mechanism in mobile IPv6 for a node to obtain a DHCPv6 address in 151 the analogous way. In this case, mobile IP registration requests 152 should be sent as in [10] with the NAI extension appearing after the 153 registration request, and before the MN-HA or MN-AAA authenticator as 154 described in [3]. The home agent would then generate DHCP messages as 155 described in [11], obtaining an IPv6 address for use as the mobile 156 node's home address. This document attempts to treat the IPv4 and 157 IPv6 cases together, providing a mechanism to be used in either 158 situation. As the majority of documents referenced here are works in 159 progress, however, this document may need to be updated upon their 160 completion. 162 Note: alternatively, on an IPv6 link, the home agent MAY use the 163 address autoconfigure mechanism present in IPv6. See appendix A. 165 3.0 Operation of a Home Agent as a DHCPv4 Proxy Agent 167 This section describes the proceedure a home agent should follow 168 upon receiving an authenticated registration request from a mobile 169 node requiring a home address in order to behave as a DHCP proxy 170 agent, and the responsibilities imposed on the home agent as a result. 172 3.1 The Initial Registration Request 174 1. The HA receives an authenticated registration request as defined 175 in [1] for a mobile node which it is willing to service, and for which 176 it does not have a current binding, and for which a home address needs 177 to be assigned. This appears in the form of a mobile IP registration 178 request containing a zero mobile node home address, an NAI extension, 179 and MN-HA authenticator as described in [3] (or MN-AAA authenticator 180 if that security model is in use). If the regisration request is 181 unacceptable, the appropriate error code as defined in [1] or [3] MUST 182 be returned to the source address of the registration request as 183 defined in [1]. 185 2. If the registration request has been authenticated as coming 186 from the mobile node identified by the NAI contained in the 187 registration request, the Home Agent builds a DHCPDISCOVER as defined 188 in [2] exactly as it would to obtain a[nother] IP address for one of 189 its links defined as being on the mobile node's home link (htype, 190 hlen, chaddr, etc), with the following difference. The client 191 identifier option (type 61) as defined in [4] MUST be included, 192 wherein the type field MUST be set to 0, and the identifier MUST be 193 set to the NAI as sent by the mobile node in the NAI extension. As 194 the Client ID option (type 51) allows for up to one octet for length, 195 a client id of up to 255 characters allows more than enough space for 196 the up-to 128 character NAI [5]. Furthermore, an IP Address Lease 197 Time option (type 51) MAY be included where the lifetime requested 198 SHOULD be the shorter value of the of either the lifetime appearing in 199 the registration request, or the lifetime the home agent is willing to 200 grant in a registration reply to this mobile node [1]. In addition, 201 sname, giaddr, and yiaddr MUST be NULL, and hops is set to 0. 203 The home agent MAY also include the DHCP Mobile IP Home Agent 204 option [4]. If the home agent includes this extension, it MUST set 205 the home agent address to the address apearing in the home agent field 206 of the registration request, or the address belonging to the home 207 agent on the link that will be servicing the mobile node. 209 Note: this DHCP message may go through a DHCP relay agent. The home 210 agent behaves no differently than as described above. 212 3. The home agent MUST wait an acceptable amount of time for a 213 DHCPOFFER from the DHCP server. It is recommended that the Home Agent 214 wait no less than DHCPDISCOVER_TIMEOUT seconds for such a reply [2]. 215 If no reply is received within that time period, and the home agent 216 has no other pool from which it can assign addresses to the mobile 217 node, it MUST return error 130, "Insufficient Resources". If the 218 DHCPOFFER is received, it is processed, specifically for an acceptable 219 home IP address, and lifetime. If the data in any field of the 220 DHCPOFFER, specifically IP address or lifetime, are unacceptable, the 221 home agent SHOULD attempt to negotiate these with the DHCP server. 223 If the DHCPOFFER includes the Mobile IP Home Agent option (code 224 68), the home agent SHOULD compare the address contained in this 225 option with its own, specifically the address identified as the home 226 agent address in the registration request, or the address on the link 227 that will be servicing the mobile node. If the address is NOT the 228 same as the address being identified as the home agent address, the 229 home agent MUST generate a registration reply with error 136 "Unknown 230 Home Agent Address". As with home agent discovery [1], this should 231 prompt the mobile node to choose a different home agent with which to 232 register. (Think: the home agent SHOULD also put the address of the 233 home agent returned in the DHCP Home Agent Option in the home agent 234 field of the registration reply. Furthermore, should this home agent 235 not reply to further home agent discovery packets from this mobile 236 node for the duration of the lifetime appearing in the registration 237 request?). 239 Upon receiving an acceptable DHCPOFFER, the home agent MUST 240 transmit a DHCPREQUEST for the IP address being offered to the unicast 241 address of the DHCP server as described by [2], and wait an acceptable 242 amount of time for a DHCPACK. It is recommended that the home agent 243 wait at least DHCPREQUEST_TIMEOUT seconds for the DHCPACK from the 244 DHCP server. If no reply is received to the DHCPREQUEST, the home 245 agent MUST either generate another DHCPREQUEST for an address apearing 246 in another received DHCPOFFER from a DHCP Server, or the home agent 247 MAY transmit another DHCPDISCOVER as in (1) above, or, if no other 248 address assignment mechanism is available, or desireable, the home 249 agent MUST send a registration response to the source of the 250 registration request with error 130, "Insufficient Resources", making 251 sure to include the mobile node's NAI as it appeared in the 252 registration request, and the HA-MN authenticator, and HA-FA 253 authenticator if required by [1]. (Think: what about simply returning 254 a zero home address, at which time the foriegn agent SHOULD return 255 "Missing Home Address" to the mobile node?) 257 4. Upon recieving a DHCPACK with a suitable IP address and lifetime 258 for the mobile node, the home agent MUST query the network for the 259 address, as in the usual duplicate IP address detection mechanisms as 260 is described in [1] [2]. If the address is in use, the home agent 261 SHOULD transmit another DHCPREQUEST for an address appearing in 262 another DHCPOFFER from a DHCP Server, or transmit another DHCPDISCOVER 263 message, or if no other address assignment mechanism is available or 264 desireable, the home agent MUST send a registration response to the 265 source of the registration request with error 130, "Insufficient 266 Resources", making sure to include the mobile node's NAI as it 267 appeared in the registration request, and the HA-MN authenticator, and 268 HA-FA authenticator if required by [1]. (Think: what about simply 269 returning a zero home address, at which time the foriegn agent SHOULD 270 return "Missing Home Address" to the mobile node?) 272 If a DHCPNAK is received instead, the home agent MUST do one of the 273 following: either renegotiate with the DHCP server, send out another 274 DHCPREQUEST for an address appearing in another DHCPOFFER from a DHCP 275 Server, send out another DHCPDISCOVER as described in (1) above, or if 276 no other address assignment mechanism is available, or desireable, the 277 home agent MUST send a registration response to the source of the 278 registration request with error 130, "Insufficient Resources", making 279 sure to include the mobile node's NAI as it appeared in the 280 registration request, and the HA-MN authenticator, and HA-FA 281 authenticator if required by [1]. (Think: what about simply returning 282 a zero home address, at which time the foriegn agent SHOULD return 283 "Missing Home Address" to the mobile node?) 285 (Think: other possible responses to the DHCPREQUEST?) 287 5. If the address in the DHCPACK is deemed suitable for use as an 288 IP address for this interface, and as a home ip address for the mobile 289 node, the home agent puts this address into the home address field of 290 the registration reply. The home agent MUST also fill in the lifetime 291 of the registration reply with the shortest value of either the 292 lifetime appearing in the registration request, the lifetime normally 293 granted by the home agent, or the lease time granted by the DHCP 294 server. The home agent MUST also remember that this address was 295 assigned to the mobile node identifying itself by this NAI, and the 296 address of the DHCP server that assigned this address, and SHOULD 297 remember the lifetime granted by the DHCP server for future reference 299 The home agent MUST also include the NAI option as per [3], and 300 append the usual HA-MN authenticator, and if required HA-FA 301 authenticator as described in [1], or the HA-AAA authenticator if that 302 security mechanism is in use. The home agent MUST also claim, and 303 defend the address as described in [1] [3]. 305 If no suitable address can be obtained from a DHCP agent, and no 306 other method of obtaining an address is available, the home agent MUST 307 send a registration reply to the mobile node with error 130, "Insufficient 308 Resources", making sure to include the mobile node's NAI as it 309 appeared in the registration request, and the HA-MN authenticator, and 310 HA-FA authenticator if required by [1]. (Think: what about simply 311 returning a zero home address, at which time the foriegn agent SHOULD 312 return "Missing Home Address" to the mobile node?) 314 3.2 Re-registration Requests 316 This sections details the behaviour of a home agent upon receiving 317 a registration request from a mobile node for which it already has a 318 binding. 320 1. The mobile node sends a registration request to a home agent 321 with which it already has a binding. It MUST include either the IP 322 Address assigned to it by the home agent, or it MUST include the 0 323 address in the home address field of the registration request, and the 324 NAI that it originally used to obtain the binding and address. 326 2. The home agent receives and authenticates the registration 327 request. It MUST then check to see if it already has a binding, and 328 is providing home agent services for this mobile node. This 329 determination can be based on NAI, or a non-zero home address. Before 330 sending a registration reply to the mobile node's care-of address, the 331 home agent MUST use the NAI, or non-zero home address to check if this 332 mobile node was assigned a DHCP administered home address, and, if the 333 home address appearing in the current registration request is 334 non-zero, make sure the mobile node is using the same home address it 335 was assigned in the previous registration using this NAI (if present). 336 If the registration request contains the zero address, the home agent 337 MUST associate the address which was assigned to the mobile node's NAI 338 by DHCP. 340 3. If the address the mobile node is using was assigned by DHCP, 341 and the home agent is either unaware of the DHCP lease time, or is 342 aware that [half of] the DHCP lease will expire before this 343 registration request (if approved) would expire, the home agent MUST 344 build a DHCPREQUEST message exactly as it would for any DHCP address 345 it were renewing as in [2] with the same exceptions as described in 346 section 3.1 above. The message is unicast to the DHCP server that 347 assigned the mobile node's current home address, the IP address being 348 renewed (appearing in the yiaddr and ciaddr fields) MUST be set to the 349 mobile node's home address, and the Client ID option (type 51) MUST be 350 included with the type field set to 0, and the client-id set to the 351 mobile node's NAI appearing in the registration request. The home 352 agent MAY include a requested IP Address option (code 50) with the 353 address set to the home address it is using. The home agent SHOULD 354 include the IP Address Lease Time option, where the lifetime is the 355 shorter of either the lifetime appearing in the registration request, 356 or the lifetime the home agent is willing to grant is placed in the IP 357 Address Lease Time option. The home agent MAY also include the Mobile 358 IP Home Agent option (type 68) with the address set to the home agent 359 address appearing in the registration request, or the address of the 360 home agent on the interface that will be servicing the mobile node. 362 4. The home agent waits a configured amount of time for the 363 DHCPACK. It is recommended that the home agent wait at least 364 DHCPREQUEST_TIMEOUT seconds for the reply from the DHCP server. If a 365 DHCPACK is received within this time, the home agent checks the IP 366 address, and lifetime. If they are acceptable, meaning the IP address 367 is identical to what the mobile node is using as appears in the home 368 address field of the registration request, the home agent generates a 369 registration reply to be sent to the care-of address appearing in the 370 registration request, includes the IP address returned by the DHCP 371 server, and the shorter lifetime of either that appearing in the 372 reregistration request, what it is configured to approve, or that of 373 the address lease granted by the DHCP server and appearing in the 374 DHCPACK. 376 Note: due to the nature of mobile IP, an IP address returned by the 377 DHCP server that is different from that which is already granted is 378 not acceptable. Should it be impossible, for some unknown reason, for 379 the home agent to get the address currently being used by the mobile 380 node as its home address, the home agent MUST reply with error 130, 381 "Insufficient Resources". 383 3.3 De-registration Requests 385 Upon returning home the mobile node will deregister with the home 386 agent as described in [1]. The mobile node generates a registration 387 request with a lifetime of 0, and MUST use either the address assigned 388 to it in the most recent registration reply from this home agent, or 389 the 0 address and the NAI it used in its most recent registration 390 request. The home agent MUST authenticate the [de]registration 391 request, and if a non-zero address appears as the mobile node's home 392 address MAY verify the mobile node is using the address it was 393 assigned, and if not deny the registration request with error 129, 394 "Administratively Prohibited". If the [de]registration request is 395 acceptable, the home agent behaves as descrbed in [1] pertaining to 396 deregistering mobile nodes. 398 The home agent MUST NOT transmit a DHCP release message for the 399 mobile node's home address; the mobile node may still need it. 401 Once the mobile node has been successfully deregistered, the 402 responsibility for renewing, and defending this address belongs to it. 403 It SHOULD immediately send out a DHCPDISCOVER message as described by 404 [2] even though it knows the lease is otherwise good for the unused 405 balance of the previous mobile ip binding. The mobile node MUST 406 include the Client ID option (type 51) with the type set to 0, and the 407 client-id set to the NAI which was originally used to obtain the lease 408 via the home agent, the IP address being renewed (appearing in the 409 yiaddr and ciaddr fields) MUST be set to the mobile node's home 410 address, and the Client ID option (type 51) MUST be included with the 411 type field set to 0, and the client-id set to the mobile node's NAI 412 appearing in the registration request. The mobile node MAY include a 413 requested IP Address option (code 50) with the address set to the home 414 address it is using. The mobile node MAY also include the IP Address 415 Lease Time option (code 51), and any other option it wishes, including 416 the Mobile IP Home Agent option (set to it's previous HA, or to the 417 zero address) for future reference. 419 In response to this DHCPDISCOVER message, the mobile node SHOULD 420 receive one, or it MAY receive more, DHCPOFFER messages. The mobile 421 node SHOULD parse these messages looking for the address it is using 422 as its home address, then identify and remember the DHCP server 423 assigning this address. 425 At this time the mobile node generates a DHCPREQUEST for the 426 address received in the DHCPOFFER, and awaits the DHCPACK from the 427 DHCP server. It processes the DHCPACK as it would normally when 428 booting on this link and obtaining an address through DHCP. The 429 mobile node SHOULD also cache the DHCPACK received from the DHCP 430 server for future reference as recommended in [2]. 432 Note: A DHCPDISCOVER message is generated upon returning to the 433 home link, and NOT a DHCPREQUEST for two reasons. Firstly, the mobile 434 node is not likely to know the unicast address of the DHCP server 435 assigning its home address. Secondly, some parameters in the 436 DHCPDISCOVER may be different such as htype, chaddr, and hlen 437 (e.g. bridged networks of different hardware-level topology if the 438 home link of the home agent's is only part of the same 'virtual' link 439 as the mobile node); these MUST now be set to those that are 440 appropriate for the mobile nodes home interface. 442 ------------ Think: for minimal mobile node implementations ------------- 444 These thoughts apply if the working group feels there is interest 445 in having a home agent continue to maintain the least for a minimal 446 mobile node even after it has roamed [back] to its home link. 448 If the mobile node wishes the home agent to continue to renew its 449 address lease, it MUST deregister using the DHCP aquired address as 450 its home address, and 0 as the care-of address, setting the lifetime 451 to 0. As this is not a legal deregistration request as described by 452 [1], the home agent can assume the mobile node is aware of it's DHCP 453 aquired address, and is asking the home agent to continue renewing its 454 address lease. If a home agent receives such a deregistration request, 455 it MUST check that the mobile node issuing the deregistration request 456 did indeed obtain its home address through DHCP, matching the address 457 with the NAI. The home agent, upon approving the deregistration, 458 renews the mobile node's home address with the DHCP server using the 459 NAI in the Client ID option, and MAY include the IP Address Lease Time 460 option (code 51). If the renewal is not successful, the home agent 461 MUST send a registration reply to the mobile node with error 130, 462 "Insufficient Resources".. Alternatively, if the home agent does not 463 support lease maintenence while the mobile node is deregistered, it 464 MUST return error XX, "DHCP lease maintenance not allowed." In this 465 scenario, if the mobile node wishes to continue to use the address 466 assigned to it, it MUST send out DHCPDISCOVER message as described 467 above, and attempt to renew the lease immediately upon successfully 468 deregistering. 470 If the renewal is successful, the home agent sends a successful 471 registration reply to the mobile node, setting the lifetime to the 472 value it wishes the mobile node to contact it in precisely the same 473 way as described here so the home agent can renew the DHCP lease for 474 the mobile node. Note: the lifetime included in the registration 475 reply MAY be the lifetime returned by the DHCP Server, or it MAY be 476 some other value. The mobile node should use the same registration 477 renewal algorithm it uses to renew its mobile IP binding while away 478 from home. The mobile node MUST also claim the address on the link, 479 and defend it as it would any other address it is using. 480 ------------- Fin: for minimal mobile node implementations ------------- 482 3.4 Address Responsibilities 484 The home agent, in negotiating for a home address for the mobile 485 node while it is away from its home link, has effectively been given 486 an [additional] IP address for one of its interfaces. It is also 487 acting on behalf of the mobile node that it is providing home agent 488 services for. As a result, the home agent MUST defend this address as 489 it would any other home address registered by a mobile node [1]. 490 Furthermore, the home agent MUST remember this address, that the 491 address was obtained through DHCP, the address of the DHCP server that 492 granted it, and the mobile node's NAI. The home agent MAY cache the 493 DHCPACK for future reference. 495 The mobile node uses this address as it would any address assigned 496 to it (by the home agent) including the exceptions described by [1] in 497 relation to what it MUST and MUST NOT do while on the foreign subnet. 498 When using this address on its home subnet, it MUST defend this 499 address itself as it would any address it is using. 501 4.0 New DHCP-Specific Mobile IP Options 503 For optimizations, and enhancements, this document defines the 504 following OPTIONAL extensions. In each case, what is required for the 505 home agent and mobile node to support is detailed. The extensions for 506 the mobile node to use are in the range 128-255, which as specified by 507 [1] are ignored (by the home agent) upon receipt if not understood. 508 In this way, a home agent which does not understand these extensions 509 will ignore them, the registration request will NOT be silently 510 discarded, and the mobile node's registration will be processed. 511 Conversely, the home agent reply extensions are in the range 0-127. 512 In this way, if a mobile node receives a registration reply which 513 contains an extension giving it some special information which it does 514 NOT understand it will silently discard the entire registration reply, 515 and attempt to reregister (with a different home agent). 517 A home agent MUST NOT insert any DHCP-related mobile IP extensions 518 in a registration reply to a mobile node from which it did not receive 519 a DHCP-related mobile IP extension. As these are optional extensions, 520 and support is not required to be compliant with this specification, 521 the appropriate assumptions which can be made by either side is 522 specified depending on the level of support provided by each end. In 523 addition, allowable responses by home agents and mobile nodes when 524 using these extensions is detailed in the appropriate sections. 526 All DHCP options conform to the requirements laid out in [7]. 528 4.1 Mobile IP DHCP-Request Extension 530 A mobile node wishing to obtain a DHCP address lease SHOULD include 531 the following extension in its registration request. This extension 532 MUST appear before the MN-HA or MN-AAA authenticator, and SHOULD 533 appear after the NAI extension. The "Mobile IP DHCP Address" 534 extension is defined as follows: 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | type | Length |C|A|L|S| reserved ... | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Type 200(TBA) "Mobile IP DHCP Address" extension 543 Length The number of bytes of the whole extension (MUST 544 be word aligned). Currently 4 (may be extended) 545 C 0 or 1 Set to 1 if the mobile node wishes to cache 546 the DHCP ACK returned by the DHCP Server. 547 A 0 or 1 Set to 1 if the mobile node wishes to get the 548 address of the DHCP Server. 549 L 0 or 1 Set to 1 if the mobile node wishes to get the 550 DHCP lease lifetime of the address. 551 S 0 or 1 Set to 1 if the mobile node wishes to get the 552 subnet mask of its home link. 554 Note: it is not necessary for any of the bits to be set. The 555 presence of the "Mobile IP DHCP Address" extension is sufficient to 556 imply the mobile node wishes to be assigned a DHCP administered 557 address. If the mobile node doesn't care to be informed of any of 558 this information, it MAY opt to leave each of the A, L, and S bits 559 unset. 561 If a home agent receives a registration request containing a Mobile 562 IP DHCP Address Request extension, it SHOULD first attempt to obtain 563 an address through DHCP. If it is able to obtain the address through 564 DHCP, it MUST include this extension in the reply before the HA-MN or 565 HA-AAA authenticator, and after the NAI extension. The home agent 566 SHOULD also set the bits corresponding to the information it is 567 returning to the mobile node. If the home agent is unable to obtain 568 an address through DHCP, it MAY try another mechanism to obtain an 569 address, in which case it MUST NOT include the "Mobile IP DHCP 570 Address" extension in the registration reply, or MAY include one 571 indicating none of the information was assigned by DHCP. If the home 572 agent can not obtain a home address for the mobile node through any 573 means available to it, the home agent MUST return error 130, 574 "Insufficient Resources". 576 Mobile nodes which include this extension in their registration 577 requests SHOULD NOT expect notification from the home agent that the 578 address they are getting is DHCP administered. The mobile node MUST 579 assume in the absense of DHCP related extensions that any home address 580 it receives in the registration reply will be maintained by the home 581 agent. 583 If a mobile node includes this extension with the A bit set to 1, 584 it MUST be prepared to perform its own lease maintenance (see section 585 4.2) as a home agent returning this extension, and a Mobile IP DHCP 586 Server IP Address extension (defined below) will not be maintaining a 587 DHCP lease for the mobile node. 589 4.2 Mobile Node's Maintaining Their Own DHCP Leases 591 It would be useful for a mobile node to manage it's own DHCP 592 administered address from the foreign domain. Without using an 593 additional extension, this can only happen in situations where a 594 reverse tunnel exists, either through a foreign agent, or with a 595 colocated care-of address. Moreover, it can only happen in topologies 596 where broadcast/multicast support is provided on the home agent, and 597 the foreign agent if one is being used. DHCPDISCOVER messages must be 598 reverse tunneled as described by [6] for broadcast/multicast messages. 599 Lease renewal requires DHCPREQUEST messages be unicast to the DHCP 600 server, and therefore requires knowledge of the DHCP Server IP 601 address, either through configuration, or the DHCPDISCOVER mechanism. 602 In this way a mobile node can have DHCP messages delivered to (and 603 from) the home domain, and can immediately continue to maintain its 604 DHCP lease, possibly without the need to broadcase a DHCPDISCOVER 605 message, upon returning to the home link. 607 4.2.1 Mobile IP DHCP ACK Extension 609 In some situations, the entire DHCPACK should be returned to the 610 mobile node. This MUST only be done when a mobile node includes a 611 mobile IP DHCP-Request extension in its registration request. This is 612 designed to pass the entire DHCPACK to the mobile node so it can parse 613 the information returned from the DHCP server as if it were on its 614 home subnet without the need for broadcast/multicast support. The 615 "Mobile IP DHCP ACK" extension is defined as follows: 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | type | Length | DHCP ACK ... 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Type (TBA) "DHCP ACK" Extension 624 Length The length of the ACK in octets 625 DHCP Server IP Address The DHPC ACK sent by the DHCP Server 627 The DHCP ACK MUST appear in the DHCP ACK Extension exactly as it 628 was sent by the DHCP Server assigning the IP address being assigned to 629 the mobile node. 631 4.2.2 Mobile IP DHCP Server IP Address Extension 633 In order to maintain their own leases, the mobile node must 634 minimally know the IP address of the DHCP server. The "Mobile IP DHCP 635 Server Address" extension is defined as follows: 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | type | IP version no.| DHCP Server IP Address ... 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Type (TBA) "DHCP Server IP Address" extension 644 IP version number 4 or 6 The IP version of the address 645 DHCP Server IP Address The IP address of the DHCP server 647 If the DHCP server address is an IPv4 address, the IP version 648 number MUST be set to 4, and there MUST be 4 octets of address in the 649 DHCP Server IP Address portion of the extension. If the DHCP server 650 address is an IPv6 address, the IP version number MUST be set to 6, 651 and there MUST be 16 octets of address in the DHCP Server IP Address 652 portion of the extension. In either case, this extension is always 653 word-aligned. 655 At any time the mobile node may include a "Mobile IP DHCP Server IP 656 Address" extension in any registration request to attempt to obtain 657 the unicast address of the DHCP Server which assigned its address. If 658 this is done when the mobile node is roamed, it MUST maintain its own 659 DHCP lease upon obtaining the DHCP Server address, or altenately may 660 opt to send the extension only upon returning to the home link in its 661 dereigstration request. This MAY allow the MN to skip the 662 DHCPDISCOVER it otherwise needs to send to find its DHCP Server's 663 unicast address, and therefore can now send a DHCPREQUEST directly to 664 the DHCP Server. 666 This extension SHOULD NOT be included if the DHCP-ACK extension is 667 included in the registration reply. 669 Note: This mechanism makes it possible for a mobile node to obtain 670 an IPv6 address via DHCPv6 from its home link by using a mobile IPv4 671 registration request. It may then use the usual mobile IPv6 672 mechanisms to inform correspondent nodes of its location, etc. [10] 674 4.2.3 Mobile IP DHCP Lease Lifetime Extension 676 Knowing the lifetime granted by the DHCP server may also be useful 677 for mobile nodes maintaining their own leases who do not wish to renew 678 on every mobile IP reregistration. If a mobile node were to have to 679 do this, it may opt instead to have the home agent renew its DHCP 680 lease. It also allows mobile nodes to determine if immediate lease 681 renewal is necessary upon returning to their home network. The "Mobile 682 IP DHCP Lease Lifetime" extension is defined as follows: 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Type | Length | Lifetime ... 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 (lifetime continued) | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 Type (TBA) "Mobile IP DHCP Lease Lifetime" extension 693 Length 4 (Same as IP address lease time option (51)[4]) 694 Lifetime The lifetime of the lease for the address 695 appearing in the home address field of this 696 registration reply. This value MUST be copied 697 from the DHCPACK message as sent by the DHCP 698 Server. 700 If the mobile node is renewing its own DHCP leases, it MAY renew 701 the lease any time it wishes. If it has no knowledge of it DHCP lease 702 lifetime, the mobile node SHOULD attempt renew its DHCP lease 703 immediately prior to renewing its mobile IP registaration. 705 This extension SHOULD NOT be included if the DHCP-ACK extension is 706 included in the registration reply. 708 4.2.4 Mobile IP Home Subnet Prefix Length Extension 710 A home subnet prefix is useful to the mobile node to do move 711 detection to the home subnet. Without it, the mobile node must hear 712 becons specifically from its home agent to know that it is home. 713 Though requestable by the mobile node itself (through DHCPINFORM, see 714 below), a home subnet mask extension is useful enough that it is 715 defined here so the information can be delivered to the mobile node in 716 the initial registration reply. The "Mobile IP Home Subnet Prefix 717 Length" extension is defined as follows: 719 0 1 720 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Type | Prefix | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 Type 1(TBA) "Mobile IP Home Subnet Prefix Length" extension 726 Prefix The number of bits of prefix as indicated 727 by either the subnet mask option in the DHCPACK 728 (converted to "bits of subnet"), or the prefix- 729 len returned for an IPv6 link, and which MUST be 730 applicable to the home address returned in the 731 mobile IP registration reply. 733 This extension SHOULD NOT be included if the DHCP-ACK extension is 734 included in the registration reply. 736 Note: the DHCP server will return the prefix of the address being 737 leased in dotted-decimal notation for IPv4 addresses. The home agent 738 MUST convert this into the above format by counting the number of 739 leading bits in the subnet mask option of the DHCPACK. This "dualism" 740 of dotted-decimal mask and prefix-length already exists in mobile IP 741 as "Prefix Length" extensions in mobility agent becons and will not 742 cause confusion if treated in the analogous fashion. If for some 743 reason the DHCP server returns a subnet mask which, in its 744 dotted-decimal format is not convertable to the above format, the 745 "Mobile IP Home Subnet Prefix Length" extension MUST NOT be included 746 in registration replies returned to the mobile node. 748 4.3 Requesting Other DHCP Information by use of DHCPINFORM 750 Once the mobile node has the IP address of its DHCP Server, the 751 mobile node MAY build a DHCPINFORM message, and unicast it to its DHCP 752 Server as defined in [2]. Such a message can request any information 753 listed in [2], or [4]. If, for example, the home agent did not 754 include a "Mobile IP Home Link Prefix Length" extension, the mobile 755 node may itself request to be informed of the prefix lengh (subnet 756 mask) associated with its address. 758 It is not known how DHCP Servers will respond to a DHCPINFORM 759 message from a node looking for the lifetime of it's lease. It is 760 advised that a mobile node that does not receive a Mobile IP DHCP 761 Lease Lifetime extension renew their leases upon each successful 762 mobile IP registration renewal. 764 4.4 Using Home Agents that don't Support Mobile IP DHCP Extensions 766 It is recommended that if a mobile node does not receive any DHCP 767 extensions from the home agent, particularly in response to a 768 registration request containing a "Mobile IP DHCP Address" extension, 769 assume its address was obtained in some generic way by the home agent, 770 and is maintained by the home agent (either through DHCP, or some 771 other means). 773 The method described below is not recommended as it is not known 774 how all DHCP server implementations will react to DHCPDISCOVER 775 messages coming from a non-zero IP source address. Moreover, it means 776 the home agent is unaware that the mobile node is maintaining its own 777 lease for this address, and may already be maintaining the lease on 778 the mobile node's behalf. In general this shouldn't be a problem, but 779 it means more work for mobile node, home agent, DHCP server, and more 780 bandwidth utilization on the home link, and all links comprising the 781 forward and reverse tunnels. 783 If a mobile node is registered with a home agent which does not 784 support these extensions, it MAY transmit a DHCPDISCOVER message 785 containing the NAI it used to register with the home agent in the 786 client ID option (see section 3 above) back to its home link using the 787 mechanisms to reverse tunnel broadcast datagrams as described by [6]. 788 This means the DHCP assigned address will be the source address of the 789 DHCPDISCOVER message eminating from the home agent, and NOT the usual 790 0 address. In response, the mobile node may then receive multiple 791 DHPCOFFERS, from which it chooses the server offering the lease to the 792 address it is now using as the destination of subsequent DHCPREQUESTs 793 used in lease maintenence. 795 If no such DHCP Server can be identified, the mobile node MUST 796 assume the address will be maintained by the home agent. 798 5.0 Other Considerations 800 This section covers considerations relating to the interaction of 801 mobile IP, and DHCP. 803 5.1 Additional Error Codes 805 As this document primarily concentrates on the use of DHCP in a 806 mobile IP environment, there are no additional error codes defined for 807 basic operation. 809 ------------ Think: for minimal mobile node implementations ------------- 811 There are, however, additional error codes defined for lease 812 maintenence in section 3.3. 814 ------------ Fin: for minimal mobile node implementations ------------- 816 5.2 Returning Information from Other DHCP-Specific Options/Codes 818 Without supporting optional DHCP extensions in mobile IP, there is 819 no way to proxy information other than the home address, and perhaps a 820 hint as to the DHCP lease time, to a MN. Therefore, there is little 821 to be gained from the home agent including any other options in the 822 DHCPDISCOVER or DHCPREQUEST other than those mentioned in section 3: 823 Client ID option (code 61), IP address Lease Time option (code 51), 824 Requested IP Address option (code 50), and possibly Mobile IP Home 825 Agent option (code 68). Using the method outlined in section 4.4, 826 however, a mobile node can use a DHCPINFORM message to obtain any 827 information about its home subnet it desires, and through mobile IP, 828 by a mechanism as if it were at home. As a result, there is only a 829 limited need for DHCP extensions to mobile IP to help optimize the use 830 of DHCP by the mobile node and home agent. 832 6.0 Caveats and Cautions 834 The use of DHCP with mobile IP, while allowing address management 835 to be centralized, comes with some caveats, and cautions which site 836 administrators should be aware of. 838 6.1 Home Address Availability 840 There is no guarantee that DHCP administered addresses will be 841 available to a node, even in non-mobile IP situations. A way around 842 this, however, which is not available to non-mobile IP aware nodes is 843 for a mobile node to be configured with multiple home agents on 844 different links, or multiple link prefixes in the home domain for home 845 agent discovery. In this way, if one home agent is unable to obtain 846 an address lease for the mobile node, the mobile node may send a 847 registration request to a home agent on a different link (using the 848 same NAI) in hopes of obtaining a home address there. Moreover, a 849 mobile node may obtain home addresses on different links using the 850 same NAI, or it may obtain more than one home address on any link by 851 using multiple NAIs. 853 6.2 Home Address Consistency 855 As with any address assignment mechanism, there is a chance a 856 mobile node will not be able to obtain the same IP address it had been 857 using in the past. This refers, of course, to an IP addresses for 858 which the mobile node's binding is no longer valid, or certainly for 859 which the DHCP lease has expired. The mobile node should take care to 860 never allow a binding to expire for an IP address it may be dependant 861 on. This applies not only to IP addresses obtained through DHCP, but 862 any address allocated by the home agent. Although a DHCP server 863 SHOULD return the IP address used in a previous binding by the same 864 node [2], there is no guarantee the address will be available. This 865 is exactly the same as in the case where the home agent is itself 866 handing out addresses from its own pool. Should the home agent be 867 itself administering addresses, and such an address is implicity 868 returned to the address pool because a mobile node allowed its 869 registration to expire, there is no guarantee that address will be 870 available to the same mobile node in a subsequent session unless the 871 home agent is reserving one IP address per potential mobile node, and 872 is therefore reserving specific IP addresses for individual mobile 873 nodes. The idea of providing IP addresses from an address pool, 874 however, is to reuse addresses, if not allow the number of addresses 875 needed to be minimized, so such a home agent configuration seems to 876 defy the intent of dynamic IP address configuration. In the case of 877 PPP assigned addresses, common practice seems to be to permanently 878 assign one IP address per dial-in line, but this situation is not 879 analogous as only one host can be connected to a dial-in line at a 880 time, and thereby there is no risk of multiple nodes needing this 881 address simultaneously, nor needing to obtain the same address across 882 different PPP sessions. 884 6.3 Multiple DHCP Addresses 886 If for some reason the mobile node wishes to obtain additional 887 addresses on the home link, while it seems possible for it to reverse 888 tunnel DHCPDISCOVER messages as described in [1] and [6] to its home 889 link, DHCPOFFERS arriving at the interface of the home agent on the 890 mobile node's home link will not contain enough information for the 891 home agent to know where to deliver them. While it may be possible 892 for home agents to examine the contents of the decapsulated reverse 893 tunnel traffic, and note that it is sending a DHCPDISCOVER on behalf 894 of the mobile node, this is not recommended, and can lead to problems 895 when more than one mobile node is doing so simultaneously. 897 Instead, mobile node's requiring multiple addresses MUST have one 898 NAI per required address on each of the required links. Therefore, if 899 a mobile node has two interfaces each requiring a different address on 900 the same home link, it MUST have two NAIs, but if these interfaces are 901 on separate home links, only one NAI is required. 903 If a mobile node has simultaneous DHCP leases, the way DHCP does 904 lease renewal requires each lease to be renewed independantly. This 905 is the case if the mobile node is maintaining its own leases, or if 906 the home agent is doing lease renewal on behalf of the mobile node. 908 6.4 Selecting an NAI 910 Of concern are allowable characters that can be placed both in 911 NAIs, and the Client ID option. [4] specifies the Client ID option, 912 and [5] specifies the character set and format restrictions for the 913 NAI. At this time, there do not appear to be any conflicts with the 914 requirements laid out in [5] on NAI character restrictions, and those 915 restrictions placed on the Client ID option in [2]. System 916 Administrators are advised, however, to limit their assigned NAIs to 917 the intersection of the requirements as they may change over time. 919 6.5 DHCPINFORM Caveat 921 It is not known how DHCP Servers will respond to a DHCPINFORM 922 message from a node looking for the lifetime of it's address lease. 923 It is advised that a mobile node that does not receive a Mobile IP 924 DHCP Lease Lifetime extension not attempt to query a DHCP Server for 925 this information, and instead allow the home agent to renew its lease 926 while it is away from its home link. 928 7.0 Security Considerations 930 The Mobile IP protocol requires the use of MN-HA or MN-AAA 931 authenticators to provide authentication of the MN to the HA/home 932 subnet. Whenever a registration request is received by a home agent 933 it MUST be authenticated as having been sent by the MN identified by 934 either the home address, or if the home address is set to the 0 935 address, the NAI option appended to the registration request, but 936 appearing before, and thereby protected by, the MN-HA or MN-AAA 937 authenticator. As a result, the DHCP address being requested by home 938 agents on behalf of mobile nodes they are servicing are being assigned 939 to machines which have been authenticated as belonging to the home 940 domain, and more specifically, are part of the subnet the assigned 941 address belongs to. Moreover, as there is a one-to-one mapping 942 between NAI and Client ID, only one address per NAI will be assigned 943 per link, thereby preventing a situation where subnet addresses would 944 be more exhausted than if the mobile nodes were making the DHCP 945 requests on their own. 947 8.0 Compliance Statements 949 8.1 Mobile IP Compliance Statement 951 Whereas this document follows mobile node and home agent 952 proceedures and requirements described in the mobile IP document 953 draft-ietf-mobileip-rfc2002-bis-LATEST.txt, which, upon obtaining RFC 954 status, will obsolete [1], mobile nodes complying with [1] (and [2], 955 and [3]) should function properly when interacting with home agents 956 complying with [1] (and [2], and [3]) and this specification. 958 8.2 DHCP Compliance Statement 960 Whereas this document details RFC2131, which obsoletes RFC1541, all 961 that is required is for a home agent and the DHCP server to follow 962 DHCP Client and Proxy requirements in RFC1541. 964 Appendix A: Use of IPv6 Address Autoconfigure 966 In IPv6, the address autoconfigure mechanism can be used by a node 967 booting on a link to obtain a link-local IPv6 address. On IPv6 links 968 where DHCP is not available, or where it is more desirable to use 969 address autoconfigure, the mobile node MUST still include an NAI 970 option in its binding update message with a Home Address options 971 indicating a zero IPv6 address, and SHOULD include a sub-option type 972 containing the interface-identifier the mobile node wishes the home 973 agent to use to obtain an IPv6 address. The home agent may then take 974 this and use it to generate the corressponding IPv6 address as it 975 would with any interface identifier, making sure to perform neighbor 976 solicitation to detect address conflicts, and returning the address in 977 a Home Address Option contained in a Binding Acknowledgement message. 978 If there is a conflict with the autoconfigured address, or if the 979 sub-option type is not included in the Binding Update message, the 980 Home Agent may generate a random number to server the same purpose, 981 again making sure the address is not in use on the mobile node's home 982 link. 984 Acknowledgements 986 The author wishes to greatfully acknowledge the help provided by 987 David Miner, Carl Smith, and Michael Carney, all of Sun Microsystems. 988 Their knowledge of DHCP far surpasses mine, and were able to help 989 fill in many of the DHCP implementation details I was not clear on. 991 Working Group Address and Author's Name and Address 993 Comments should be sent to the mobileip mailing list: 995 mobile-ip@sunroof.eng.sun.com 997 or to the author: 999 Steven M. Glass Steven.Glass@sun.com 1000 Sun Microsystems 1001 1 Network Drive 1002 Burlington, MA. 01803 1003 Office: 1.888.555.9SUN 1004 Fax: 1.781.442.1677 1006 References 1008 [1] RFC2002, "IP Mobility Support", C. Perkins, October 1996 1010 [2] RFC2131, "Dynamic Host Configuration Protocol", R. Droms, 1011 March 1997 1013 [3] RFC2794, "Mobile IP Network Access Identifier Extension for 1014 IPv4", P. Calhoun and C. Perkins. March 2000. 1016 [4] RFC2132, "DHCP Options and BOOTP Vendor Extensions", Alexander & 1017 Droms, March 1997. 1019 [5] RFC2486, "The Network Access Identifier", B. Aboba, M. Beadles, 1020 January 1999. 1022 [6] RFC2344, "Reverse Tunneling for Mobile IP", G. Montenegro, 1023 May 1998 1025 [7] RFC2489 "Procedure for Defining New DHCP Options", Droms, 1026 January 1999 1028 [9] Glass, S. "Mobile IP Registration Revocation", Work In Progress. 1030 [10] D. Johnson and C. Perkins, "Mobility Support in IPv6", Work In 1031 Progress. 1033 [11] J. Bound, M. Carney, and C. Perkins, "Dynamic Host 1034 Configuration Protocol for IPv6 (DHCPv6)", Work In Progress. 1036 Full Copyright Statement 1038 "Copyright (C) The Internet Society (2000). All Rights Reserved. 1040 This document and translations of it may be copied and furnished 1041 to others, and derivative works that comment on or otherwise 1042 explain it or assist in its implementation may be prepared, copied, 1043 published and distributed, in whole or in part, without 1044 restriction of any kind, provided that the above copyright notice 1045 and this paragraph are included on all such copies and derivative 1046 works. However, this document itself may not be modified in any 1047 way, such as by removing the copyright notice or references to the 1048 Internet Society or other Internet organizations, except as needed 1049 for the purpose of developing Internet standards in which case the 1050 procedures for copyrights defined in the Internet Standards 1051 process must be followed, or as required to translate it into 1052 languages other than English. 1054 The limited permissions granted above are perpetual and will not 1055 be revoked by the Internet Society or its successors or assigns. 1057 This document and the information contained herein is provided on 1058 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1059 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1060 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1061 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1062 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1064 Chair's Address 1066 The Working Group can also be contacted via its current chairs: 1068 Basavaraj Patil Phil Roberts 1069 Nokia Corporation Motorola 1070 M/S M8-540 1071 6000 Connection Drive 1501 West Shure Drive 1072 Irving, TX 75039 Arlington Heights, IL 60004 1073 USA USA 1074 Phone: +1 972-894-6709 Phone: +1 847-632-3148 1075 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com 1076 Fax : +1 972-894-5349