idnits 2.17.1 draft-deng-mip4-host-configuration-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 683. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 96: '... home agent MUST use its home addres...' RFC 2119 keyword, line 156: '...PINFORM messages MUST be directed to t...' RFC 2119 keyword, line 211: '... SHOULD unicast the DHCPACK reply to...' RFC 2119 keyword, line 263: '...on 4.1), then it SHOULD display a mess...' RFC 2119 keyword, line 264: '...roblem, and then SHOULD begin network ...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 2, 2008) is 5776 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) == Unused Reference: 'RFC0951' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'RFC1700' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC1701' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC2003' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC2004' is defined on line 622, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1701 ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Deng 3 Internet-Draft China Mobile 4 Intended status: Standards Track July 2, 2008 5 Expires: January 3, 2009 7 DHCP Based Configuration of Mobile Node from Home Network 8 draft-deng-mip4-host-configuration-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 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 This Internet-Draft will expire on January 3, 2009. 35 Abstract 37 This document describes the mechanism for providing the host 38 configuration parameters needed for network service from home network 39 based on DHCPINFORM. DHCPINFORM message has been widely used by 40 client to obtain other configuration information and could be sent to 41 local broadcast address or server unicast address. Mobile IP 42 specification could support DHCPINFORM broadcast or unicast message 43 straightfully without any revision. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Home DHCP server's address unknown . . . . . . . . . . . . . . 4 49 2.1. MIP4 Co-CoA case . . . . . . . . . . . . . . . . . . . . . 4 50 2.2. MIP4 FA CoA Case . . . . . . . . . . . . . . . . . . . . . 8 51 3. Home DHCP server's address known . . . . . . . . . . . . . . . 13 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 53 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 17 54 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 55 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 56 8. Normative References . . . . . . . . . . . . . . . . . . . . . 20 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 58 Intellectual Property and Copyright Statements . . . . . . . . . . 22 60 1. Introduction 62 Mobile node could use DHCP mechanism to configure local information 63 when it attach to the foreign network. But it may have to get 64 configuration information from the home network as well. The common 65 mechanism to configure the mobile host is preferable in Mobile IP. 67 If a mobile node has obtained a network address through some other 68 means, it may use a DHCPINFORM request message to obtain other local 69 configuration parameters. This DHCPINFORM message could be sent to 70 local broadcast address or server unicast address(know it from out of 71 band delivery). DHCP Server receiving a DHCPINFORM message construct 72 a DHCPACK message with any local configuration parameters appropriate 73 for the mobile node. 75 This document has analysed the process about how Mobile IP 76 specification could straightfully support DHCPINFORM broadcast or 77 unicast message for host configuration without any revision. 79 2. Home DHCP server's address unknown 81 2.1. MIP4 Co-CoA case 83 If the 'D' bit was set in the mobile node's Registration Request 84 message, and code field of the received registration reply indicate 85 successly registered. This means that the mobile node is using a co- 86 located care-of address. 88 Section 5.3 of Reverse tunneling [RFC3024] recommend that a mobile 89 node using a co-located care-of address send the broadcast/multicast 90 packet are handled according to Sections 4.3 and 4.4 of the Mobile IP 91 specification [RFC3344]. 93 Section 4.3 of [RFC3344] doesn't specify how a mobile node send 94 datagrams to a broadcast address in detail. Section 4.4 of [RFC3344] 95 specify that a mobile node which tunnels a multicast datagram to its 96 home agent MUST use its home address as the IP source address of both 97 the (inner) broadcast datagram and the (outer) encapsulating 98 datagram. Anyway this tunnel is not topologically correct. 100 The mobile node simply tunnels appropriate broadcast DHCPINFORM 101 message to the home agent.The source address of this DHCPINFORM 102 message is the mobile node's home address. Home agent just work as a 103 simple DHCP relay agent as shown in figure 1. 105 +-----+ +-------+ 106 | HA/ | | Home | 107 |DHCP |----| DHCP | 108 |Relay| | Server| 109 +-----+ +-------+ 110 // 111 // Home Network 112 -------------//----------------------- 113 // Visiting Network 114 // 115 // +----+ 116 +----+ | | 117 | MN |----| AR | 118 +----+ | | 119 +----+ 121 Figure 1: Home network configuration in the case of Co-CoA 123 +----+ +-------+ +------+ 124 | | | HA | |DHCP | 125 | MN | | DHCP | |Server| 126 | | | relay | | | 127 +----+ +-------+ +------+ 128 | RRQ | | 129 |--------------------------->| | 130 | RRP | | 131 |<---------------------------| | 132 | 1 | | 133 |--------------------------->| | 134 | | 2 | 135 | |--------->| 136 | | | 137 | | 3 | 138 | |<---------| 139 | 4 | | 140 |<---------------------------| | 142 Figure 2: Message sequence for host configuration in Co-CoA 144 Figure 2 shows the message sequence for host configuration in Co-CoA. 146 (1) After the mobile node successfully registered to the home agent 147 based on Registration Request(RRQ) and Registration Response(RRP) 148 message, it sends a DHCPINFORM message to request specific 149 configuration parameters by including the 'parameter request list' 150 option from home network. The mobile node generates and records a 151 random transaction identifier and inserts that identifier into the 152 'xid' field. The mobile node places its own home address in the 153 'ciaddr' field. 155 The mobile node will send DHCPINFORM message to the limited (all 1s) 156 broadcast address. DHCPINFORM messages MUST be directed to the 'DHCP 157 server' UDP port. 159 The mobile node will encapsulate this DHCPINFORM broadcast message 160 with IP in IP tunnel and send to the home agent, DHCPINFORM Packet 161 format sent by the mobile node is shown below: 163 IP fields (encapsulating header): 164 Source Address = mobile node's home address 165 Destination Address = home agent's address 166 Protocol field: 4 (IP in IP) 167 IP fields (original header): 168 Source Address = mobile node's home address 169 Destination Address = broadcast address 170 UDP Src Port: bootpc(68), Dst Port: bootps(67) 171 Bootstrap Protocol: 172 field: 173 op = BOOTREQUEST 174 htype = Ethernet or (From "Assigned Numbers" RFC) 175 hlen = 6 or (Hardware address length in octets) 176 hops = 0 177 xid = selected by client 178 secs = 0 179 flags = 0 180 ciaddr = mobile node's home address 181 yiaddr = 0 182 siaddr = 0 183 giaddr = 0 184 chaddr = mobile node's MAC address 185 options: 186 option 53: DHCP Message Type = DHCPINFORM 187 option 61: Client Identifier = mobile node's MAC address 188 option 55: Parameter request List (Domain Name Server,... et al.) 190 (2) Since the home agent acts as the DHCP relay agent, after 191 receiving a unicast tunnel message, it detunneled the unicast 192 encapsulated header, and should look at the the 'giaddr' field of 193 DHCPINFORM message. If zero, it should plug its own IP address into 194 this field. It may also use the 'hops' field to optionally control 195 how far the packet is reforwarded. Hops should be incremented on 196 each forwarding. 198 DHCPINFORM Packet format forwarded by the home agent: 200 IP fields: 201 Source Address = home agent's address 202 Destination Address = DHCP server's address 203 UDP Src Port: bootps(67), Dst Port: bootps(67) 204 Bootstrap Protocol: 205 field: 206 giaddr = home agent's address 208 (3) DHCP server receiving a DHCPINFORM message construct a DHCPACK 209 message with any home configuration parameters appropriate for the 210 mobile node according to Section 3.4 of [RFC2131] . The DHCP server 211 SHOULD unicast the DHCPACK reply to the address given in the 'giaddr' 212 field of the DHCPINFORM message. 214 DHCPACK Packet format sent by the DHCP Server: 216 IP fields: 217 Source Address = DHCP server's address 218 Destination Address = home agent's address 219 (from 'giaddr' of DHCPINFORM) 220 UDP Src Port: bootps(67), Dst Port: bootps(67) 221 Bootstrap Protocol: 222 field: 223 op = BOOTREPLY 224 htype = Ethernet or (From "Assigned Numbers" RFC) 225 hlen = 6 or (Hardware address length in octets) 226 hops = 0 227 xid = same as "xid" field of DHCPINFORM message 228 secs = 0 229 flags = 0 230 ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM) 231 yiaddr = 0 232 siaddr = 0 233 giaddr = home agent's address (from 'giaddr' of DHCPINFORM) 234 chaddr = mobile node's MAC address (from 'chaddr' of DHCPINFORM) 235 options: 236 option 53: DHCP Message Type = DHCPACK 237 option 61: Server Identifier = DHCP server's MAC address 238 option 6: Domain Name Server 239 all other options: if needed 241 (4) The home agent intercepting a unicast DHCPACK message will 242 tunnels this datagram to the mobile node's currently registered 243 care-of address. 245 DHCPACK Packet format forwarded by the home agent: 247 IP fields (encapsulating header): 248 Source Address = home agent's address 249 Destination Address = mobile node's care-of-address 250 Protocol field: 4 (IP in IP) 251 IP fields (original header): 252 Source Address = DHCP server's address 253 Destination Address = mobile node's home address 254 UDP Src Port: bootps(67), Dst Port: bootpc(68) 255 Bootstrap Protocol 257 Once a DHCPACK message with an 'xid' field matching that in the 258 mobile node's DHCPINFORM message arrives from any server, the mobile 259 node's configuration process is finished. 261 If the mobile node does not receive a DHCPACK within a reasonable 262 period of time (60 seconds or 4 tries if using timeout suggested in 263 section 4.1), then it SHOULD display a message informing the user of 264 the problem, and then SHOULD begin network processing using suitable 265 defaults as per Appendix A of [RFC2131]. 267 2.2. MIP4 FA CoA Case 269 If the 'D' bit was not set in the mobile node's Registration Request 270 message, and code field of the received registration reply indicate 271 successly registered. This means that the mobile node is using a 272 foreign agent care-of address. 274 Reverse tunneling [RFC3024] in Mobile IP has mandate that a mobile 275 node using a foreign agent care-of address MUST use the encapsulating 276 delivery style. So the operation of DHCPINFORM broadcast message to 277 the home network in this case should follow the encapsulating 278 delivery style. 280 +-----+ +-------+ 281 | HA/ |____| Home | 282 |DHCP |----| DHCP | 283 |Relay| | Server| 284 +-----+ +-------+ 285 || 286 || Home Network 287 ----------------||-------------------- 288 || Visiting Network 289 || 290 +----+ 291 +----+______| | 292 | MN |------| FA | 293 +----+ | | 294 +----+ 296 Figure 3: Home network configuration in the case of FA-CoA 298 +----+ +-----+ +-------+ +------+ 299 | | | | | HA | |DHCP | 300 | MN | | FA | | DHCP | |Server| 301 | | | | | relay | | | 302 +----+ +-----+ +-------+ +------+ 303 | | | | 304 | RRQ | | 305 |---------------------------->| | 306 | RRP | | 307 |<----------------------------| | 308 | 1 | | | 309 |-------------->| | | 310 | | 2 | | 311 | |------------>| | 312 | | | 3 | 313 | | |--------->| 314 | | | 4 | 315 | | |<---------| 316 | | 5 | | 317 | |<------------| | 318 | 6 | | | 319 |<--------------| | | 321 Figure 4: Message sequence for host configuration in FA-CoA 323 Figure 4 shows the message sequence for host configuration in Co-CoA. 325 (1) After the mobile node successfully registered to the home agent 326 based on Registration Request(RRQ) and Registration Response(RRP) 327 messages, it sends a DHCPINFORM message to request specific 328 configuration parameters by including the 'parameter request list' 329 option from home network. The mobile node generates and records a 330 random transaction identifier and inserts that identifier into the 331 'xid' field. The mobile node places its own home address in the 332 'ciaddr' field. 334 The mobile node send DHCPINFORM the message to the limited (all 1s) 335 broadcast address. DHCPINFORM messages MUST be directed to the 'DHCP 336 server' UDP port. 338 The mobile node will encapsulate this DHCPINFORM broadcast message 339 with IP in IP tunnel and send to the foriegn agent, DHCPINFORM Packet 340 format sent by the mobile node is shown below: 342 IP fields (encapsulating header): 343 Source Address = mobile node's home address 344 Destination Address = foreign agent's address 345 Protocol field: 4 (IP in IP) 346 IP fields (original header): 347 Source Address = mobile node's home address 348 Destination Address = broadcast address 349 UDP Src Port: bootpc(68), Dst Port: bootps(67) 350 Bootstrap Protocol: 351 field: 352 op = BOOTREQUEST 353 htype = Ethernet or (From "Assigned Numbers" RFC) 354 hlen = 6 or (Hardware address length in octets) 355 hops = 0 356 xid = selected by client 357 secs = 0 358 flags = 0 359 ciaddr = mobile node's home address 360 yiaddr = 0 361 siaddr = 0 362 giaddr = 0 363 chaddr = mobile node's MAC address 364 options: 365 option 53: DHCP Message Type = DHCPINFORM 366 option 61: Client Identifier = mobile node's MAC address 367 option 55: Parameter request List (Domain Name Server,... et al.) 369 (2) Packet format forwarded by the foreign agent (Encapsulating 370 Delivery Style): 372 IP fields (encapsulating header): 373 Source Address = foreign agent's care-of-address 374 Destination Address = home agent's address 375 Protocol field: 4 (IP in IP) 376 IP fields (original header): 377 Source Address = mobile node's home address 378 Destination Address = broadcast address 379 UDP Src Port: bootpc(68), Dst Port: bootps(67) 380 Bootstrap Protocol 382 Since the home agent acts as the DHCP relay agent, after receiving a 383 unicast tunnel message, it detunneled the unicast encapsulated 384 header, and should look at the the 'giaddr' field of DHCPINFORM 385 message. If zero, it should plug its own IP address into this field. 386 It may also use the 'hops' field to optionally control how far the 387 packet is reforwarded. Hops should be incremented on each 388 forwarding. 390 (3) DHCPINFORM Packet format forwarded by the home agent: 392 IP fields: 393 Source Address = home agent's address 394 Destination Address = DHCP server's address 395 UDP Src Port: bootps(67), Dst Port: bootps(67) 396 Bootstrap Protocol: 397 field: 398 giaddr = home agent's address 400 (4) DHCP server receiving a DHCPINFORM message construct a DHCPACK 401 message with any home configuration parameters appropriate for the 402 mobile node according to Section 3.4 of [RFC2131] . The DHCP server 403 SHOULD unicast the DHCPACK reply to the address given in the 'giaddr' 404 field of the DHCPINFORM message. 406 DHCPACK Packet format sent by the DHCP Server: 408 IP fields: 409 Source Address = DHCP server's address 410 Destination Address = home agent's address 411 (from 'giaddr' of DHCPINFORM) 412 UDP Src Port: bootps(67), Dst Port: bootps(67) 413 Bootstrap Protocol: 414 field: 415 op = BOOTREPLY 416 htype = Ethernet or (From "Assigned Numbers" RFC) 417 hlen = 6 or (Hardware address length in octets) 418 hops = 0 419 xid = same as "xid" field of DHCPINFORM message 420 secs = 0 421 flags = 0 422 ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM) 423 yiaddr = 0 424 siaddr = 0 425 giaddr = home agent's address (from 'giaddr' of DHCPINFORM) 426 chaddr = mobile node's MAC address (from 'chaddr' of DHCPINFORM) 427 options: 428 option 53: DHCP Message Type = DHCPACK 429 option 61: Server Identifier = DHCP server's MAC address 430 option 6: Domain Name Server 431 all other options: if needed 433 (5) The home agent intercepting a unicast DHCPACK message will 434 tunnels this datagram to the foreign agent care-of address. 436 DHCPACK Packet format forwarded by the home agent: 438 IP fields (encapsulating header): 439 Source Address = home agent's address 440 Destination Address = foreign agent's care-of-address 441 Protocol field: 4 (IP in IP) 442 IP fields (original header): 443 Source Address = DHCP server's address 444 Destination Address = mobile node's home address 445 UDP Src Port: bootps(67), Dst Port: bootpc(68) 446 Bootstrap Protocol 448 (6) DHCPACK Packet format forwarded by the foreign agent: 450 IP fields (encapsulating header): 451 Source Address = foreign agent's address 452 Destination Address = mobile node's home address 453 Protocol field: 4 (IP in IP) 454 IP fields (original header): 455 Source Address = DHCP server's address 456 Destination Address = mobile node's home address 457 UDP Src Port: bootps(67), Dst Port: bootpc(68) 458 Bootstrap Protocol 460 Once a DHCPACK message with an 'xid' field matching that in the 461 mobile node's DHCPINFORM message arrives from any server, the mobile 462 node's configuration process is finished. 464 If the mobile node does not receive a DHCPACK within a reasonable 465 period of time (60 seconds or 4 tries if using timeout suggested in 466 section 4.1), then it SHOULD display a message informing the user of 467 the problem, and then SHOULD begin network processing using suitable 468 defaults as per Appendix A of [RFC2131]. 470 3. Home DHCP server's address known 472 If a mobile node has obtained a DHCP server address through some 473 other means (how to obtain is out scope of this document), after 474 registration process, it may send a DHCPINFORM unicast message to 475 obtain other local configuration parameters. 477 According to Section 1.7 of [RFC3344], in the reverse direction, 478 datagrams sent by the mobile node are generally delivered to their 479 destination using standard IP routing mechanisms, not necessarily 480 passing through the home agent. 482 +----+ +-----+ +-------+ +------+ 483 | | | | | | |DHCP | 484 | MN | | FA | | HA | |Server| 485 | | | | | | | | 486 +----+ +-----+ +-------+ +------+ 487 | | | | 488 | RRQ | | 489 |---------------------------->| | 490 | RRP | | 491 |<----------------------------| | 492 | 1 | | | 493 |--------------------------------------->| 494 | | | 2 | 495 | | |<---------| 496 | | 3 | | 497 |<----------------------------| | 498 | | 3 | | 499 | |<------------| | 500 | 4 | | | 501 |<--------------| | | 503 Figure 5: Message sequence for Known DHCP server's address 505 Figure 5 shows the message sequence for host configuration with known 506 DHCP server's address. 508 (1) After the mobile node successfully registered to the home agent 509 based on Registration Request(RRQ) and Registration Response(RRP) 510 message, it then unicasts the DHCPINFORM to the DHCP server based on 511 standard IP routing mechanisms whatever it is co-colated care-of 512 address or foreign agent care-of address. 514 DHCPINFORM Packet format sent by the mobile node is shown below: 516 IP fields: 517 Source Address = mobile node's home address 518 Destination Address = DHCP server's address 519 UDP Src Port: bootpc(68), Dst Port: bootps(67) 520 Bootstrap Protocol: 521 field: 522 op = BOOTREQUEST 523 htype = Ethernet or (From "Assigned Numbers" RFC) 524 hlen = 6 or (Hardware address length in octets) 525 hops = 0 526 xid = selected by client 527 secs = 0 528 flags = 0 529 ciaddr = mobile node's home address 530 yiaddr = 0 531 siaddr = 0 532 giaddr = 0 533 chaddr = mobile node's MAC address 534 options: 535 option 53: DHCP Message Type = DHCPINFORM 536 option 61: Client Identifier = mobile node's MAC address 537 option 55: Parameter request List (Domain Name Server,... et al.) 539 (2) DHCP server receiving a DHCPINFORM message construct a DHCPACK 540 message with any home configuration parameters appropriate for the 541 mobile node according to Section 3.4 of [RFC2131] . If the 'giaddr' 542 field is zero and the 'ciaddr' field is nonzero, then the DHCP server 543 SHOULD unicast the DHCPACK reply to the address given in the 'ciaddr' 544 field of the DHCPINFORM message. 546 DHCPACK Packet format sent by the DHCP Server: 548 IP fields: 549 Source Address = DHCP server's address 550 Destination Address = mobile node's home address 551 (from 'ciaddr' of DHCPINFORM) 552 UDP Src Port: bootps(67), Dst Port: bootpc(68) 553 Bootstrap Protocol: 554 field: 555 op = BOOTREPLY 556 htype = Ethernet or (From "Assigned Numbers" RFC) 557 hlen = 6 or (Hardware address length in octets) 558 hops = 0 559 xid = same as "xid" field of DHCPINFORM message 560 secs = 0 561 flags = 0 562 ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM) 563 yiaddr = 0 564 siaddr = 0 565 giaddr = 0 566 chaddr = mobile node's MAC address (from 'chaddr' of DHCPINFORM) 567 options: 568 option 53: DHCP Message Type = DHCPACK 569 option 61: Server Identifier = DHCP server's MAC address 570 option 6: Domain Name Server 571 all other options: if needed 573 (3,4) The home agent intercepting a unicast DHCPACK message will 574 tunnels this datagram to the mobile node's home address based on 575 standard mobile IP process. 577 According to Sections 5.5 and 5.6 of the Mobile IP specification 578 [RFC3344], the mobile node may create a tunnel to its home agent. 579 Then, datagrams destined for DHCP server will appear to emanate from 580 the home network. This kind of process could be refered to section 2 581 of this document. 583 4. Security Considerations 585 This document just analyse the process of DHCPINFORM support in 586 mobile IP environment, it operates in the security constraints and 587 requirements of [RFC2131] and [RFC3344]. 589 5. IANA Consideration 591 This document makes no requests to IANA. 593 6. Acknowledgments 595 The author thanks the discussion from Kent Leung, Alexandru Petrescu, 596 Charles E. Perkins, Jari Arkko, Vijay Devarapalli, Hans Sjostrand, 597 Peng Yang and et al. in the development of this document. 599 The efforts of McCann Peter and Henrik Levkowetz in reviewing this 600 document are gratefully acknowledged. 602 7. Conclusion 604 This document verified that mobile node could get home network 605 configuration based on DHCPINFORM without any revision of basic 606 mobile IP specification. 608 8. Normative References 610 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 611 September 1985. 613 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 614 October 1994. 616 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 617 Routing Encapsulation (GRE)", RFC 1701, October 1994. 619 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 620 October 1996. 622 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 623 October 1996. 625 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 626 RFC 2131, March 1997. 628 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 629 revised", RFC 3024, January 2001. 631 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 632 August 2002. 634 Author's Address 636 Hui Deng 637 China Mobile 638 53A,Xibianmennei Ave., 639 Xuanwu District, 640 Beijing 100053 641 China 643 Email: denghui02@gmail.com 645 Full Copyright Statement 647 Copyright (C) The IETF Trust (2008). 649 This document is subject to the rights, licenses and restrictions 650 contained in BCP 78, and except as set forth therein, the authors 651 retain all their rights. 653 This document and the information contained herein are provided on an 654 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 655 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 656 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 657 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 658 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 659 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 661 Intellectual Property 663 The IETF takes no position regarding the validity or scope of any 664 Intellectual Property Rights or other rights that might be claimed to 665 pertain to the implementation or use of the technology described in 666 this document or the extent to which any license under such rights 667 might or might not be available; nor does it represent that it has 668 made any independent effort to identify any such rights. Information 669 on the procedures with respect to rights in RFC documents can be 670 found in BCP 78 and BCP 79. 672 Copies of IPR disclosures made to the IETF Secretariat and any 673 assurances of licenses to be made available, or the result of an 674 attempt made to obtain a general license or permission for the use of 675 such proprietary rights by implementers or users of this 676 specification can be obtained from the IETF on-line IPR repository at 677 http://www.ietf.org/ipr. 679 The IETF invites any interested party to bring to its attention any 680 copyrights, patents or patent applications, or other proprietary 681 rights that may cover technology that may be required to implement 682 this standard. Please address the information to the IETF at 683 ietf-ipr@ietf.org.