Network Working Group H. Deng Internet-Draft China Mobile Intended status: Standards TrackJuly 2, 2008P. Yang Expires:January 3,August 27, 2009 Hitachi (China) R&D Corp February 23, 2009 DHCP Based Configuration of Mobile Node from Home Networkdraft-deng-mip4-host-configuration-00draft-deng-mip4-host-configuration-01 Status of this MemoBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or sheThis Internet-Draft isaware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF inaccordancefull conformance withSection 6the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire onJanuary 3,August 27, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes the mechanism for providing the host configuration parameters needed for network service from home network based on DHCPINFORM. DHCPINFORM message has been widely used by client to obtain other configuration information and could be sent to local broadcast address or server unicast address. Mobile IP specification could support DHCPINFORM broadcast or unicast message straightfully without any revision. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Home DHCP server's address unknown with DHCP relay on HA . . . 4 2.1. MIP4 Co-CoA case . . . . . . . . . . . . . . . . . . . . . 42.1.2.2. MIP4 FA CoA Case . . . . . . . . . . . . . . . . . . . . . 8 3. Home DHCP server's address unknown without DHCP relay on home agent . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. MIP4 Co-CoA case . . . . . . . . . . . . . . . . . . . . .4 2.2.13 3.2. MIP4 FA CoA Case . . . . . . . . . . . . . . . . . . . . .8 3.17 4. Home DHCP server's address known . . . . . . . . . . . . . . .13 4.22 5. Security Considerations . . . . . . . . . . . . . . . . . . .16 5.24 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . .17 6.25 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .18 7.26 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .19 8.27 9. Normative References . . . . . . . . . . . . . . . . . . . . .20 Author's Address . . . . . . . . . . .28 Authors' Addresses . . . . . . . . . . . . . .21 Intellectual Property and Copyright Statements. . . . . . . . . .2229 1. Introduction Mobile node could use DHCP mechanism to configure local information when it attach to the foreign network. But it may have to get configuration information from the home network as well. The common mechanism to configure the mobile host is preferable in Mobile IP. If a mobile node has obtained a network address through some other means, it may use a DHCPINFORM request message to obtain other local configuration parameters. This DHCPINFORM message could be sent to local broadcast address or server unicast address(know it from out of band delivery). DHCP Server receiving a DHCPINFORM message construct a DHCPACK message with any local configuration parameters appropriate for the mobile node. This document has analysed the process about how Mobile IP specification could straightfully support DHCPINFORM broadcast or unicast message for host configuration without any revision. 2. Home DHCP server's address unknown with DHCP relay on HA 2.1. MIP4 Co-CoA case If the 'D' bit was set in the mobile node's Registration Request message, and code field of the received registration reply indicate successly registered. This means that the mobile node is using a co- located care-of address. Section 5.3 of Reverse tunneling [RFC3024] recommend that a mobile node using a co-located care-of address send the broadcast/multicast packet are handled according to Sections 4.3 and 4.4 of the Mobile IP specification [RFC3344]. Section 4.3 of [RFC3344] doesn't specify how a mobile node send datagrams to a broadcast address in detail. Section 4.4 of [RFC3344] specify that a mobile node which tunnels a multicast datagram to its home agent MUST use its home address as the IP source address of both the (inner) broadcast datagram and the (outer) encapsulating datagram. Anyway this tunnel is not topologically correct. The mobile node simply tunnels appropriate broadcast DHCPINFORM message to the home agent.The source address of this DHCPINFORM message is the mobile node's home address. Home agent just work as a simple DHCP relay agent as shown in figure 1. +-----+ +-------+ | HA/ | | Home | |DHCP |----| DHCP | |Relay| | Server| +-----+ +-------+ // // Home Network -------------//----------------------- // Visiting Network // // +----+ +----+ | | | MN |----| AR | +----+ | | +----+ Figure 1: Home network configuration in the case of Co-CoA +----+ +-------+ +------+ | | | HA | |DHCP | | MN | | DHCP | |Server| | | | relay | | | +----+ +-------+ +------+ | RRQ | | |--------------------------->| | | RRP | | |<---------------------------| | | 1 | | |--------------------------->| | | | 2 | | |--------->| | | | | | 3 | | |<---------| | 4 | | |<---------------------------| | Figure 2: Message sequence for host configuration in Co-CoA Figure 2 shows the message sequence for host configuration in Co-CoA. (1) After the mobile node successfully registered to the home agent based on Registration Request(RRQ) and Registration Response(RRP) message, it sends a DHCPINFORM message to request specific configuration parameters by including the 'parameter request list' option from home network. The mobile node generates and records a random transaction identifier and inserts that identifier into the 'xid' field. The mobile node places its own home address in the 'ciaddr' field. The mobile node will send DHCPINFORM message to the limited (all 1s) broadcast address. DHCPINFORM messages MUST be directed to the 'DHCP server' UDP port. The mobile node will encapsulate this DHCPINFORM broadcast message with IP in IP tunnel and send to the home agent, DHCPINFORM Packet format sent by the mobile node is shown below: IP fields (encapsulating header): Source Address = mobile node's home address Destination Address = home agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = broadcast address UDP Src Port: bootpc(68), Dst Port: bootps(67) Bootstrap Protocol: field: op = BOOTREQUEST htype = Ethernet or (From "Assigned Numbers" RFC) hlen = 6 or (Hardware address length in octets) hops = 0 xid = selected by client secs = 0 flags = 0 ciaddr = mobile node's home address yiaddr = 0 siaddr = 0 giaddr = 0 chaddr = mobile node's MAC address options: option 53: DHCP Message Type = DHCPINFORM option 61: Client Identifier = mobile node's MAC address option 55: Parameter request List (Domain Name Server,... et al.) (2) Since the home agent acts as the DHCP relay agent, after receiving a unicast tunnel message, it detunneled the unicast encapsulated header, and should look at the the 'giaddr' field of DHCPINFORM message. If zero, it should plug its own IP address into this field. It may also use the 'hops' field to optionally control how far the packet is reforwarded. Hops should be incremented on each forwarding. DHCPINFORM Packet format forwarded by the home agent: IP fields: Source Address = home agent's address Destination Address = DHCP server's address UDP Src Port: bootps(67), Dst Port: bootps(67) Bootstrap Protocol: field: giaddr = home agent's address (3) DHCP server receiving a DHCPINFORM message construct a DHCPACK message with any home configuration parameters appropriate for the mobile node according to Section 3.4 of [RFC2131] . The DHCP server SHOULD unicast the DHCPACK reply to the address given in the'giaddr''ciaddr' field (mobile node's home address) of the DHCPINFORM message. DHCPACK Packet format sent by the DHCP Server: IP fields: Source Address = DHCP server's address Destination Address = homeagent'saddress of mobile node (from'giaddr''ciaddr' of DHCPINFORM) UDP Src Port: bootps(67), Dst Port:bootps(67)bootps(68) Bootstrap Protocol: field: op = BOOTREPLY htype = Ethernet or (From "Assigned Numbers" RFC) hlen = 6 or (Hardware address length in octets) hops = 0 xid = same as "xid" field of DHCPINFORM message secs = 0 flags = 0 ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM) yiaddr = 0 siaddr = 0 giaddr = home agent's address (from 'giaddr' of DHCPINFORM) chaddr = mobile node's MAC address (from 'chaddr' of DHCPINFORM) options: option 53: DHCP Message Type = DHCPACK option 61: Server Identifier = DHCP server's MAC address option 6: Domain Name Server all other options: if needed (4) The home agent intercepting a unicast DHCPACK message will tunnels this datagram to the mobile node's currently registered care-of address. DHCPACK Packet format forwarded by the home agent: IP fields (encapsulating header): Source Address = home agent's address Destination Address = mobile node's care-of-address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = DHCP server's address Destination Address = mobile node's home address UDP Src Port: bootps(67), Dst Port: bootpc(68) Bootstrap Protocol Once a DHCPACK message with an 'xid' field matching that in the mobile node's DHCPINFORM message arrives from any server, the mobile node's configuration process is finished. If the mobile node does not receive a DHCPACK within a reasonable period of time (60 seconds or 4 tries if using timeout suggested in section 4.1), then it SHOULD display a message informing the user of the problem, and then SHOULD begin network processing using suitable defaults as per Appendix A of [RFC2131]. 2.2. MIP4 FA CoA Case If the 'D' bit was not set in the mobile node's Registration Request message, and code field of the received registration reply indicate successly registered. This means that the mobile node is using a foreign agent care-of address. Reverse tunneling [RFC3024] in Mobile IP has mandate that a mobile node using a foreign agent care-of address MUST use the encapsulating delivery style. So the operation of DHCPINFORM broadcast message to the home network in this case should follow the encapsulating delivery style. +-----+ +-------+ | HA/ |____| Home | |DHCP |----| DHCP | |Relay| | Server| +-----+ +-------+ || || Home Network ----------------||-------------------- || Visiting Network || +----+ +----+______| | | MN |------| FA | +----+ | | +----+ Figure 3: Home network configuration in the case of FA-CoA +----+ +-----+ +-------+ +------+ | | | | | HA | |DHCP | | MN | | FA | | DHCP | |Server| | | | | | relay | | | +----+ +-----+ +-------+ +------+ | | | | | RRQ | | |---------------------------->| | | RRP | | |<----------------------------| | | 1 | | | |-------------->| | | | | 2 | | | |------------>| | | | | 3 | | | |--------->| | | | 4 | | | |<---------| | | 5 | | | |<------------| | | 6 | | | |<--------------| | | Figure 4: Message sequence for host configuration in FA-CoA Figure 4 shows the message sequence for host configuration in Co-CoA. (1) After the mobile node successfully registered to the home agent based on Registration Request(RRQ) and Registration Response(RRP) messages, it sends a DHCPINFORM message to request specific configuration parameters by including the 'parameter request list' option from home network. The mobile node generates and records a random transaction identifier and inserts that identifier into the 'xid' field. The mobile node places its own home address in the 'ciaddr' field. The mobile node send DHCPINFORM the message to the limited (all 1s) broadcast address. DHCPINFORM messages MUST be directed to the 'DHCP server' UDP port. The mobile node will encapsulate this DHCPINFORM broadcast message with IP in IP tunnel and send to the foriegn agent, DHCPINFORM Packet format sent by the mobile node is shown below: IP fields (encapsulating header): Source Address = mobile node's home address Destination Address = foreign agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = broadcast address UDP Src Port: bootpc(68), Dst Port: bootps(67) Bootstrap Protocol: field: op = BOOTREQUEST htype = Ethernet or (From "Assigned Numbers" RFC) hlen = 6 or (Hardware address length in octets) hops = 0 xid = selected by client secs = 0 flags = 0 ciaddr = mobile node's home address yiaddr = 0 siaddr = 0 giaddr = 0 chaddr = mobile node's MAC address options: option 53: DHCP Message Type = DHCPINFORM option 61: Client Identifier = mobile node's MAC address option 55: Parameter request List (Domain Name Server,... et al.) (2) Packet format forwarded by the foreign agent (Encapsulating Delivery Style): IP fields (encapsulating header): Source Address = foreign agent's care-of-address Destination Address = home agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = broadcast address UDP Src Port: bootpc(68), Dst Port: bootps(67) Bootstrap Protocol Since the home agent acts as the DHCP relay agent, after receiving a unicast tunnel message, it detunneled the unicast encapsulated header, and should look at the the 'giaddr' field of DHCPINFORM message. If zero, it should plug its own IP address into this field. It may also use the 'hops' field to optionally control how far the packet is reforwarded. Hops should be incremented on each forwarding. (3) DHCPINFORM Packet format forwarded by the home agent: IP fields: Source Address = home agent's address Destination Address = DHCP server's address UDP Src Port: bootps(67), Dst Port: bootps(67) Bootstrap Protocol: field: giaddr = home agent's address (4) DHCP server receiving a DHCPINFORM message construct a DHCPACK message with any home configuration parameters appropriate for the mobile node according to Section 3.4 of [RFC2131] . The DHCP server SHOULD unicast the DHCPACK reply to the address given in the'giaddr''ciaddr' field (mobile node's home address) of the DHCPINFORM message. DHCPACK Packet format sent by the DHCP Server: IP fields: Source Address = DHCP server's address Destination Address = homeagent'saddress of mobile node (from'giaddr''ciaddr' of DHCPINFORM) UDP Src Port: bootps(67), Dst Port:bootps(67)bootps(68) Bootstrap Protocol: field: op = BOOTREPLY htype = Ethernet or (From "Assigned Numbers" RFC) hlen = 6 or (Hardware address length in octets) hops = 0 xid = same as "xid" field of DHCPINFORM message secs = 0 flags = 0 ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM) yiaddr = 0 siaddr = 0 giaddr = home agent's address (from 'giaddr' of DHCPINFORM) chaddr = mobile node's MAC address (from 'chaddr' of DHCPINFORM) options: option 53: DHCP Message Type = DHCPACK option 61: Server Identifier = DHCP server's MAC address option 6: Domain Name Server all other options: if needed (5) The home agent intercepting a unicast DHCPACK message will tunnels this datagram to the foreign agent care-of address. DHCPACK Packet format forwarded by the home agent: IP fields (encapsulating header): Source Address = home agent's address Destination Address = foreign agent's care-of-address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = DHCP server's address Destination Address = mobile node's home address UDP Src Port: bootps(67), Dst Port: bootpc(68) Bootstrap Protocol (6) DHCPACK Packet format forwarded by the foreign agent: IP fields (encapsulating header): Source Address = foreign agent's address Destination Address = mobile node's home address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = DHCP server's address Destination Address = mobile node's home address UDP Src Port: bootps(67), Dst Port: bootpc(68) Bootstrap Protocol Once a DHCPACK message with an 'xid' field matching that in the mobile node's DHCPINFORM message arrives from any server, the mobile node's configuration process is finished. If the mobile node does not receive a DHCPACK within a reasonable period of time (60 seconds or 4 tries if using timeout suggested in section 4.1), then it SHOULD display a message informing the user of the problem, and then SHOULD begin network processing using suitable defaults as per Appendix A of [RFC2131]. 3. Home DHCP server's addressknownunknown without DHCP relay on home agent This part is related to the cases as below: o DHCP relay function is not supported by HA. o DHCP relay function in HA will not be used for MN to get local information. For both cases above, there shall have DHCP server or another DHCP relay on the same subnet as the home link of HA. 3.1. MIP4 Co-CoA case If the 'D' bit was set in the mobile node's Registration Request message, and code field of the received registration reply indicate successly registered. This means that the mobile node is using a co- located care-of address. Section 5.3 of Reverse tunneling [RFC3024] recommend that a mobile nodehas obtainedusing aDHCP serverco-located care-of addressthrough some other means (howsend the broadcast/multicast packet are handled according toobtainSections 4.3 and 4.4 of the Mobile IP specification [RFC3344]. The mobile node simply tunnels appropriate broadcast DHCPINFORM message to the home agent.The source address of this DHCPINFORM message isout scopethe mobile node's home address. Home agent simply forwards the broadcast DHCPINFORM to the home network. The home DHCP server can get this broadcast packet either directly or by the help of another DHCP relay node. The topoloy is shown in figure 1. +-----+ +-------+ | HA | | Home | | |====| DHCP | | | | Server| | | | /relay| +-----+ +-------+ // // Home Network -------------//----------------------- // Visiting Network // // +----+ +----+ | | | MN |----| AR | +----+ | | +----+ Figure 5: Home network configuration in the case of Co-CoA +----+ +-------+ +------+ | | | HA | |home | | MN | | | |DHCP | | | | | |Server| | | | | |/relay| +----+ +-------+ +------+ | RRQ | | |--------------------------->| | | RRP | | |<---------------------------| | | 1 | | |===========================>| | | | 2 | | |--------->| | | | | | 3 | | |<---------| | 4 | | |<===========================| | Figure 6: Message sequence for host configuration in Co-CoA Figure 2 shows the message sequence for host configuration in Co-CoA. (1) After the mobile node successfully registered to the home agent based on Registration Request(RRQ) and Registration Response(RRP) message, it sends a DHCPINFORM message to request specific configuration parameters by including the 'parameter request list' option from home network. The mobile node generates and records a random transaction identifier and inserts that identifier into the 'xid' field. The mobile node places its own home address in the 'ciaddr' field. The mobile node will send DHCPINFORM message to the limited (all 1s) broadcast address. DHCPINFORM messages MUST be directed to the 'DHCP server' UDP port. The mobile node will encapsulate thisdocument),DHCPINFORM broadcast message with IP in IP tunnel and send to the home agent, DHCPINFORM Packet format sent by the mobile node is shown below: IP fields (encapsulating header): Source Address = mobile node's home address Destination Address = home agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = broadcast address UDP Src Port: bootpc(68), Dst Port: bootps(67) Bootstrap Protocol: field: op = BOOTREQUEST htype = Ethernet or (From "Assigned Numbers" RFC) hlen = 6 or (Hardware address length in octets) hops = 0 xid = selected by client secs = 0 flags = 0 ciaddr = mobile node's home address yiaddr = 0 siaddr = 0 giaddr = 0 chaddr = mobile node's MAC address options: option 53: DHCP Message Type = DHCPINFORM option 61: Client Identifier = mobile node's MAC address option 55: Parameter request List (Domain Name Server,... et al.) (2) Since the home agent does not acts as the DHCP relay agent, afterregistration process,receiving a unicast tunnel message, it detunnels the unicast encapsulated header, and simply forwards the inner broadcast packet onto the home network. (3) DHCP server maysend areceive the broadcast DHCPINFORM message. Another DHCP relay agent in home network may also help to relay the DHCPINFORMunicastmessage toobtain other localDHCP server as defined in [RFC2131]. then, DHCP server constructs a DHCPACK message with any home configurationparameters. Accordingparameters appropriate for the mobile node according to Section1.73.4 of[RFC3344],[RFC2131] . The DHCP server SHOULD unicast the DHCPACK reply to the address given in thereverse direction, datagrams'ciaddr' field (mobile nodes' home address) of the DHCPINFORM message. DHCPACK Packet format sent by the DHCP Server: IP fields: Source Address = DHCP server's address Destination Address = mobilenode are generally deliverednodes's home address UDP Src Port: bootps(67), Dst Port: bootps(68) Bootstrap Protocol: field: op = BOOTREPLY htype = Ethernet or (From "Assigned Numbers" RFC) hlen = 6 or (Hardware address length in octets) hops = 0 xid = same as "xid" field of DHCPINFORM message secs = 0 flags = 0 ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM) yiaddr = 0 siaddr = 0 giaddr = 0 or the other DHCP relay agent's address invloved chaddr = mobile node's MAC address (from 'chaddr' of DHCPINFORM) options: option 53: DHCP Message Type = DHCPACK option 61: Server Identifier = DHCP server's MAC address option 6: Domain Name Server all other options: if needed (4) The home agent intercepting this DHCPACK message will tunnels it totheir destination using standardthe mobile node's currently registered care-of address. DHCPACK Packet format forwarded by the home agent: IProuting mechanisms,fields (encapsulating header): Source Address = home agent's address Destination Address = mobile node's care-of-address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = DHCP server's address Destination Address = mobile node's home address UDP Src Port: bootps(67), Dst Port: bootpc(68) Bootstrap Protocol Once a DHCPACK message with an 'xid' field matching that in the mobile node's DHCPINFORM message arrives from any server, the mobile node's configuration process is finished. If the mobile node does notnecessarily passing throughreceive a DHCPACK within a reasonable period of time (60 seconds or 4 tries if using timeout suggested in section 4.1), then it SHOULD display a message informing the user of the problem, and then SHOULD begin network processing using suitable defaults as per Appendix A of [RFC2131]. 3.2. MIP4 FA CoA Case If the 'D' bit was not set in the mobile node's Registration Request message, and code field of the received registration reply indicate successly registered. This means that the mobile node is using a foreign agent care-of address. Reverse tunneling [RFC3024] in Mobile IP has mandate that a mobile node using a foreign agent care-of address MUST use the encapsulating delivery style. So the operation of DHCPINFORM broadcast message to the homeagent.network in this case should follow the encapsulating delivery style. +-----+ +-------+ | HA | | Home | | |====| DHCP | | | | Server| | | |/relay | +-----+ +-------+ || || Home Network ----------------||-------------------- || Visiting Network || +----+ +----+______| | | MN |------| FA | +----+ | | +----+ Figure 7: Home network configuration in the case of FA-CoA +----+ +-----+ +-------+ +------+ | | | | | HA | |DHCP | | MN | | FA | |HA| |Server| | | | | | | |/relay| | | | | | | | | +----+ +-----+ +-------+ +------+ | | | | | RRQ | | |---------------------------->| | | RRP | | |<----------------------------| | | 1 | | ||--------------------------------------->||==============>| | | | | 2 | | ||<---------||============>| | | | | 3 | ||<----------------------------|| |--------->| | |3| 4 | ||<------------|| |<---------| |4| 5 | | | |<============| | | 6 | ||<--------------|| |<==============| | | Figure5:8: Message sequence forKnown DHCP server's addresshost configuration in FA-CoA Figure54 shows the message sequence for host configuration in Co-CoA. (1) After the mobile node successfully registered to the home agent based on Registration Request(RRQ) and Registration Response(RRP) messages, it sends a DHCPINFORM message to request specific configuration parameters by including the 'parameter request list' option from home network. The mobile node generates and records a random transaction identifier and inserts that identifier into the 'xid' field. The mobile node places its own home address in the 'ciaddr' field. The mobile node send DHCPINFORM the message to the limited (all 1s) broadcast address. DHCPINFORM messages MUST be directed to the 'DHCP server' UDP port. The mobile node will encapsulate this DHCPINFORM broadcast message withknownIP in IP tunnel and send to the foriegn agent, DHCPINFORM Packet format sent by the mobile node is shown below: IP fields (encapsulating header): Source Address = mobile node's home address Destination Address = foreign agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = broadcast address UDP Src Port: bootpc(68), Dst Port: bootps(67) Bootstrap Protocol: field: op = BOOTREQUEST htype = Ethernet or (From "Assigned Numbers" RFC) hlen = 6 or (Hardware address length in octets) hops = 0 xid = selected by client secs = 0 flags = 0 ciaddr = mobile node's home address yiaddr = 0 siaddr = 0 giaddr = 0 chaddr = mobile node's MAC address options: option 53: DHCP Message Type = DHCPINFORM option 61: Client Identifier = mobile node's MAC address option 55: Parameter request List (Domain Name Server,... et al.) (2) Packet format forwarded by the foreign agent (Encapsulating Delivery Style): IP fields (encapsulating header): Source Address = foreign agent's care-of-address Destination Address = home agent's address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = mobile node's home address Destination Address = broadcast address UDP Src Port: bootpc(68), Dst Port: bootps(67) Bootstrap Protocol (3) Since the home agent does not act as the DHCP relay agent, after receiving a unicast tunnel message, it detunneled the unicast encapsulated header, and simply forwards the inner broadcast packet onto the home network. (3) DHCP server may receive the broadcast DHCPINFORM message. Another DHCP relay agent in home network may also help to relay the DHCPINFORM message to DHCP server as defined in [RFC2131]. then, DHCP server constructs a DHCPACK message with any home configuration parameters appropriate for the mobile node according to Section 3.4 of [RFC2131] . The DHCP server SHOULD unicast the DHCPACK reply to the address given in the 'ciaddr' field (mobile node's home address) of the DHCPINFORM message. DHCPACK Packet format sent by the DHCP Server: IP fields: Source Address = DHCP server's address Destination Address = mobile node's home address UDP Src Port: bootps(67), Dst Port: bootps(68) Bootstrap Protocol: field: op = BOOTREPLY htype = Ethernet or (From "Assigned Numbers" RFC) hlen = 6 or (Hardware address length in octets) hops = 0 xid = same as "xid" field of DHCPINFORM message secs = 0 flags = 0 ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM) yiaddr = 0 siaddr = 0 giaddr = 0 or the other DHCP relay agent's address invloved chaddr = mobile node's MAC address (from 'chaddr' of DHCPINFORM) options: option 53: DHCP Message Type = DHCPACK option 61: Server Identifier = DHCP server's MAC address option 6: Domain Name Server all other options: if needed (5) The home agent intercepting a unicast DHCPACK message will tunnels this datagram to the foreign agent care-of address. DHCPACK Packet format forwarded by the home agent: IP fields (encapsulating header): Source Address = home agent's address Destination Address = foreign agent's care-of-address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = DHCP server's address Destination Address = mobile node's home address UDP Src Port: bootps(67), Dst Port: bootpc(68) Bootstrap Protocol (6) DHCPACK Packet format forwarded by the foreign agent: IP fields (encapsulating header): Source Address = foreign agent's address Destination Address = mobile node's home address Protocol field: 4 (IP in IP) IP fields (original header): Source Address = DHCP server's address Destination Address = mobile node's home address UDP Src Port: bootps(67), Dst Port: bootpc(68) Bootstrap Protocol According to [RFC3024], encapsulating delivery style is required for reverse tunneling of broadcast/multicast. However, once the encapsulated delivery style is negotiated, it applies to all reverse tunneling, including unicast. But, it's obvious that the overhead of DHCPACK message will be increase as shown in message (6) above. [Chakrabarti08] has discussed this issue in detail. Once a DHCPACK message with an 'xid' field matching that in the mobile node's DHCPINFORM message arrives from any server, the mobile node's configuration process is finished. If the mobile node does not receive a DHCPACK within a reasonable period of time (60 seconds or 4 tries if using timeout suggested in section 4.1), then it SHOULD display a message informing the user of the problem, and then SHOULD begin network processing using suitable defaults as per Appendix A of [RFC2131]. 4. Home DHCP server's address known If a mobile node has obtained a DHCP server address through some other means (how to obtain is out scope of this document), after registration process, it may send a DHCPINFORM unicast message to obtain other local configuration parameters. According to Section 1.7 of [RFC3344], in the reverse direction, datagrams sent by the mobile node are generally delivered to their destination using standard IP routing mechanisms, not necessarily passing through the home agent. The whole procedure is as below: (1) After the mobile node successfully registered to the home agent based on Registration Request(RRQ) and Registration Response(RRP) message, it then unicasts the DHCPINFORM to the DHCP server based on MIPv4 standard IP routingmechanisms whatever it is co-colated care-of address or foreign agent care-of address.mechanisms. DHCPINFORM Packet format sent by the mobile node is shownbelow:below (this packet may be encapsulated inside tunnels if needed): IP fields: Source Address = mobile node's home address Destination Address = DHCP server's address UDP Src Port: bootpc(68), Dst Port: bootps(67) Bootstrap Protocol: field: op = BOOTREQUEST htype = Ethernet or (From "Assigned Numbers" RFC) hlen = 6 or (Hardware address length in octets) hops = 0 xid = selected by client secs = 0 flags = 0 ciaddr = mobile node's home address yiaddr = 0 siaddr = 0 giaddr = 0 chaddr = mobile node's MAC address options: option 53: DHCP Message Type = DHCPINFORM option 61: Client Identifier = mobile node's MAC address option 55: Parameter request List (Domain Name Server,... et al.) (2) DHCP server receiving a DHCPINFORM message construct a DHCPACK message with any home configuration parameters appropriate for the mobile node according to Section 3.4 of [RFC2131] . If the 'giaddr' field is zero and the 'ciaddr' field is nonzero, then the DHCP server SHOULD unicast the DHCPACK reply to the address given in the 'ciaddr' field of the DHCPINFORM message. DHCPACK Packet format sent by the DHCP Server: IP fields: Source Address = DHCP server's address Destination Address = mobile node's home address (from 'ciaddr' of DHCPINFORM) UDP Src Port: bootps(67), Dst Port: bootpc(68) Bootstrap Protocol: field: op = BOOTREPLY htype = Ethernet or (From "Assigned Numbers" RFC) hlen = 6 or (Hardware address length in octets) hops = 0 xid = same as "xid" field of DHCPINFORM message secs = 0 flags = 0 ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM) yiaddr = 0 siaddr = 0 giaddr = 0 chaddr = mobile node's MAC address (from 'chaddr' of DHCPINFORM) options: option 53: DHCP Message Type = DHCPACK option 61: Server Identifier = DHCP server's MAC address option 6: Domain Name Server all other options: if needed(3,4)(3) The home agent intercepting a unicast DHCPACK message will tunnels this datagram to the mobile node's home address based on standard mobile IP process.According to Sections 5.5 and 5.6 of the Mobile IP specification [RFC3344], the mobile node may create a tunnel to its home agent. Then, datagrams destined for DHCP server will appear to emanate from the home network. This kind of process could be refered to section 2 of this document. 4.5. Security Considerations This document just analyse the process of DHCPINFORM support in mobile IP environment, it operates in the security constraints and requirements of [RFC2131] and [RFC3344].5.6. IANA Consideration This document makes no requests to IANA.6.7. Acknowledgments The author thanks the discussion from Kent Leung, Alexandru Petrescu, Charles E. Perkins, Jari Arkko, Vijay Devarapalli, Hans Sjostrand,Peng Yang andet al. in the development of this document. The efforts of McCann Peter and Henrik Levkowetz in reviewing this document are gratefully acknowledged.7.8. Conclusion This document verified that mobile node could get home network configuration based on DHCPINFORM without any revision of basic mobile IP specification.8.9. Normative References [Chakrabarti08] Chakrabarti, Y., "IPv4 Mobility Extension for Multicast and Broadcast Packets", draft-chakrabarti-mip4-mcbc-03.txt (work in progress), October 2008. [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.Author's AddressAuthors' Addresses Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui02@gmail.comFull Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.Peng Yang Hitachi (China) R&D Corp N-301, building C, Raycom Infotech Park Haidian District, Beijing 100190 China Email: peng.yang.chn@gmail.com