< draft-deng-mip4-host-configuration-00.txt   draft-deng-mip4-host-configuration-01.txt >
Network Working Group H. Deng Network Working Group H. Deng
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Standards Track July 2, 2008 Intended status: Standards Track P. Yang
Expires: January 3, 2009 Expires: August 27, 2009 Hitachi (China) R&D Corp
February 23, 2009
DHCP Based Configuration of Mobile Node from Home Network DHCP Based Configuration of Mobile Node from Home Network
draft-deng-mip4-host-configuration-00 draft-deng-mip4-host-configuration-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 3, 2009. This Internet-Draft will expire on 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 Abstract
This document describes the mechanism for providing the host This document describes the mechanism for providing the host
configuration parameters needed for network service from home network configuration parameters needed for network service from home network
based on DHCPINFORM. DHCPINFORM message has been widely used by based on DHCPINFORM. DHCPINFORM message has been widely used by
client to obtain other configuration information and could be sent to client to obtain other configuration information and could be sent to
local broadcast address or server unicast address. Mobile IP local broadcast address or server unicast address. Mobile IP
specification could support DHCPINFORM broadcast or unicast message specification could support DHCPINFORM broadcast or unicast message
straightfully without any revision. straightfully without any revision.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Home DHCP server's address unknown . . . . . . . . . . . . . . 4 2. Home DHCP server's address unknown with DHCP relay on HA . . . 4
2.1. MIP4 Co-CoA case . . . . . . . . . . . . . . . . . . . . . 4 2.1. MIP4 Co-CoA case . . . . . . . . . . . . . . . . . . . . . 4
2.2. MIP4 FA CoA Case . . . . . . . . . . . . . . . . . . . . . 8 2.2. MIP4 FA CoA Case . . . . . . . . . . . . . . . . . . . . . 8
3. Home DHCP server's address known . . . . . . . . . . . . . . . 13 3. Home DHCP server's address unknown without DHCP relay on
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 home agent . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 17 3.1. MIP4 Co-CoA case . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 3.2. MIP4 FA CoA Case . . . . . . . . . . . . . . . . . . . . . 17
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Home DHCP server's address known . . . . . . . . . . . . . . . 22
8. Normative References . . . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 22 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Normative References . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Mobile node could use DHCP mechanism to configure local information Mobile node could use DHCP mechanism to configure local information
when it attach to the foreign network. But it may have to get when it attach to the foreign network. But it may have to get
configuration information from the home network as well. The common configuration information from the home network as well. The common
mechanism to configure the mobile host is preferable in Mobile IP. mechanism to configure the mobile host is preferable in Mobile IP.
If a mobile node has obtained a network address through some other If a mobile node has obtained a network address through some other
means, it may use a DHCPINFORM request message to obtain other local means, it may use a DHCPINFORM request message to obtain other local
configuration parameters. This DHCPINFORM message could be sent to configuration parameters. This DHCPINFORM message could be sent to
local broadcast address or server unicast address(know it from out of local broadcast address or server unicast address(know it from out of
band delivery). DHCP Server receiving a DHCPINFORM message construct band delivery). DHCP Server receiving a DHCPINFORM message construct
a DHCPACK message with any local configuration parameters appropriate a DHCPACK message with any local configuration parameters appropriate
for the mobile node. for the mobile node.
This document has analysed the process about how Mobile IP This document has analysed the process about how Mobile IP
specification could straightfully support DHCPINFORM broadcast or specification could straightfully support DHCPINFORM broadcast or
unicast message for host configuration without any revision. unicast message for host configuration without any revision.
2. Home DHCP server's address unknown 2. Home DHCP server's address unknown with DHCP relay on HA
2.1. MIP4 Co-CoA case 2.1. MIP4 Co-CoA case
If the 'D' bit was set in the mobile node's Registration Request If the 'D' bit was set in the mobile node's Registration Request
message, and code field of the received registration reply indicate message, and code field of the received registration reply indicate
successly registered. This means that the mobile node is using a co- successly registered. This means that the mobile node is using a co-
located care-of address. located care-of address.
Section 5.3 of Reverse tunneling [RFC3024] recommend that a mobile Section 5.3 of Reverse tunneling [RFC3024] recommend that a mobile
node using a co-located care-of address send the broadcast/multicast node using a co-located care-of address send the broadcast/multicast
skipping to change at page 7, line 4 skipping to change at page 7, line 4
Source Address = home agent's address Source Address = home agent's address
Destination Address = DHCP server's address Destination Address = DHCP server's address
UDP Src Port: bootps(67), Dst Port: bootps(67) UDP Src Port: bootps(67), Dst Port: bootps(67)
Bootstrap Protocol: Bootstrap Protocol:
field: field:
giaddr = home agent's address giaddr = home agent's address
(3) DHCP server receiving a DHCPINFORM message construct a DHCPACK (3) DHCP server receiving a DHCPINFORM message construct a DHCPACK
message with any home configuration parameters appropriate for the message with any home configuration parameters appropriate for the
mobile node according to Section 3.4 of [RFC2131] . The DHCP server mobile node according to Section 3.4 of [RFC2131] . The DHCP server
SHOULD unicast the DHCPACK reply to the address given in the 'giaddr' SHOULD unicast the DHCPACK reply to the address given in the 'ciaddr'
field of the DHCPINFORM message. field (mobile node's home address) of the DHCPINFORM message.
DHCPACK Packet format sent by the DHCP Server: DHCPACK Packet format sent by the DHCP Server:
IP fields: IP fields:
Source Address = DHCP server's address Source Address = DHCP server's address
Destination Address = home agent's address Destination Address = home address of mobile node
(from 'giaddr' of DHCPINFORM) (from 'ciaddr' of DHCPINFORM)
UDP Src Port: bootps(67), Dst Port: bootps(67) UDP Src Port: bootps(67), Dst Port: bootps(68)
Bootstrap Protocol: Bootstrap Protocol:
field: field:
op = BOOTREPLY op = BOOTREPLY
htype = Ethernet or (From "Assigned Numbers" RFC) htype = Ethernet or (From "Assigned Numbers" RFC)
hlen = 6 or (Hardware address length in octets) hlen = 6 or (Hardware address length in octets)
hops = 0 hops = 0
xid = same as "xid" field of DHCPINFORM message xid = same as "xid" field of DHCPINFORM message
secs = 0 secs = 0
flags = 0 flags = 0
ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM) ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM)
skipping to change at page 11, line 18 skipping to change at page 11, line 18
Source Address = home agent's address Source Address = home agent's address
Destination Address = DHCP server's address Destination Address = DHCP server's address
UDP Src Port: bootps(67), Dst Port: bootps(67) UDP Src Port: bootps(67), Dst Port: bootps(67)
Bootstrap Protocol: Bootstrap Protocol:
field: field:
giaddr = home agent's address giaddr = home agent's address
(4) DHCP server receiving a DHCPINFORM message construct a DHCPACK (4) DHCP server receiving a DHCPINFORM message construct a DHCPACK
message with any home configuration parameters appropriate for the message with any home configuration parameters appropriate for the
mobile node according to Section 3.4 of [RFC2131] . The DHCP server mobile node according to Section 3.4 of [RFC2131] . The DHCP server
SHOULD unicast the DHCPACK reply to the address given in the 'giaddr' SHOULD unicast the DHCPACK reply to the address given in the 'ciaddr'
field of the DHCPINFORM message. field (mobile node's home address) of the DHCPINFORM message.
DHCPACK Packet format sent by the DHCP Server: DHCPACK Packet format sent by the DHCP Server:
IP fields: IP fields:
Source Address = DHCP server's address Source Address = DHCP server's address
Destination Address = home agent's address Destination Address = home address of mobile node
(from 'giaddr' of DHCPINFORM) (from 'ciaddr' of DHCPINFORM)
UDP Src Port: bootps(67), Dst Port: bootps(67) UDP Src Port: bootps(67), Dst Port: bootps(68)
Bootstrap Protocol: Bootstrap Protocol:
field: field:
op = BOOTREPLY op = BOOTREPLY
htype = Ethernet or (From "Assigned Numbers" RFC) htype = Ethernet or (From "Assigned Numbers" RFC)
hlen = 6 or (Hardware address length in octets) hlen = 6 or (Hardware address length in octets)
hops = 0 hops = 0
xid = same as "xid" field of DHCPINFORM message xid = same as "xid" field of DHCPINFORM message
secs = 0 secs = 0
flags = 0 flags = 0
ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM) ciaddr = mobile node's home address (from 'ciaddr' of DHCPINFORM)
skipping to change at page 13, line 5 skipping to change at page 13, line 5
Once a DHCPACK message with an 'xid' field matching that in the Once a DHCPACK message with an 'xid' field matching that in the
mobile node's DHCPINFORM message arrives from any server, the mobile mobile node's DHCPINFORM message arrives from any server, the mobile
node's configuration process is finished. node's configuration process is finished.
If the mobile node does not receive a DHCPACK within a reasonable 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 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 section 4.1), then it SHOULD display a message informing the user of
the problem, and then SHOULD begin network processing using suitable the problem, and then SHOULD begin network processing using suitable
defaults as per Appendix A of [RFC2131]. defaults as per Appendix A of [RFC2131].
3. Home DHCP server's address known 3. Home DHCP server's address unknown without DHCP relay on home agent
If a mobile node has obtained a DHCP server address through some This part is related to the cases as below:
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, o DHCP relay function is not supported by HA.
datagrams sent by the mobile node are generally delivered to their
destination using standard IP routing mechanisms, not necessarily o DHCP relay function in HA will not be used for MN to get local
passing through the home agent. 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
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].
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 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 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 does not acts as the DHCP relay agent, after
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 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 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 = mobile nodes'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
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].
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 home 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
+----+ +-----+ +-------+ +------+ +----+ +-----+ +-------+ +------+
| | | | | | |DHCP | | | | | | HA | |DHCP |
| MN | | FA | | HA | |Server| | MN | | FA | | | |Server|
| | | | | | |/relay|
| | | | | | | | | | | | | | | |
+----+ +-----+ +-------+ +------+ +----+ +-----+ +-------+ +------+
| | | | | | | |
| RRQ | | | RRQ | |
|---------------------------->| | |---------------------------->| |
| RRP | | | RRP | |
|<----------------------------| | |<----------------------------| |
| 1 | | | | 1 | | |
|--------------------------------------->| |==============>| | |
| | | 2 | | | 2 | |
| |============>| |
| | | 3 |
| | |--------->|
| | | 4 |
| | |<---------| | | |<---------|
| | 3 | | | | 5 | |
|<----------------------------| | | |<============| |
| | 3 | | | 6 | | |
| |<------------| | |<==============| | |
| 4 | | |
|<--------------| | |
Figure 5: Message sequence for Known DHCP server's address Figure 8: Message sequence for host configuration in FA-CoA
Figure 5 shows the message sequence for host configuration with known Figure 4 shows the message sequence for host configuration in Co-CoA.
DHCP server's address.
(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
(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 (1) After the mobile node successfully registered to the home agent
based on Registration Request(RRQ) and Registration Response(RRP) based on Registration Request(RRQ) and Registration Response(RRP)
message, it then unicasts the DHCPINFORM to the DHCP server based on message, it then unicasts the DHCPINFORM to the DHCP server based on
standard IP routing mechanisms whatever it is co-colated care-of MIPv4 standard IP routing mechanisms.
address or foreign agent care-of address.
DHCPINFORM Packet format sent by the mobile node is shown below: DHCPINFORM Packet format sent by the mobile node is shown below (this
packet may be encapsulated inside tunnels if needed):
IP fields: IP fields:
Source Address = mobile node's home address Source Address = mobile node's home address
Destination Address = DHCP server's address Destination Address = DHCP server's address
UDP Src Port: bootpc(68), Dst Port: bootps(67) UDP Src Port: bootpc(68), Dst Port: bootps(67)
Bootstrap Protocol: Bootstrap Protocol:
field: field:
op = BOOTREQUEST op = BOOTREQUEST
htype = Ethernet or (From "Assigned Numbers" RFC) htype = Ethernet or (From "Assigned Numbers" RFC)
hlen = 6 or (Hardware address length in octets) hlen = 6 or (Hardware address length in octets)
skipping to change at page 15, line 30 skipping to change at page 23, line 35
yiaddr = 0 yiaddr = 0
siaddr = 0 siaddr = 0
giaddr = 0 giaddr = 0
chaddr = mobile node's MAC address (from 'chaddr' of DHCPINFORM) chaddr = mobile node's MAC address (from 'chaddr' of DHCPINFORM)
options: options:
option 53: DHCP Message Type = DHCPACK option 53: DHCP Message Type = DHCPACK
option 61: Server Identifier = DHCP server's MAC address option 61: Server Identifier = DHCP server's MAC address
option 6: Domain Name Server option 6: Domain Name Server
all other options: if needed all other options: if needed
(3,4) The home agent intercepting a unicast DHCPACK message will (3) The home agent intercepting a unicast DHCPACK message will
tunnels this datagram to the mobile node's home address based on tunnels this datagram to the mobile node's home address based on
standard mobile IP process. standard mobile IP process.
According to Sections 5.5 and 5.6 of the Mobile IP specification 5. Security Considerations
[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. Security Considerations
This document just analyse the process of DHCPINFORM support in This document just analyse the process of DHCPINFORM support in
mobile IP environment, it operates in the security constraints and mobile IP environment, it operates in the security constraints and
requirements of [RFC2131] and [RFC3344]. requirements of [RFC2131] and [RFC3344].
5. IANA Consideration 6. IANA Consideration
This document makes no requests to IANA. This document makes no requests to IANA.
6. Acknowledgments 7. Acknowledgments
The author thanks the discussion from Kent Leung, Alexandru Petrescu, The author thanks the discussion from Kent Leung, Alexandru Petrescu,
Charles E. Perkins, Jari Arkko, Vijay Devarapalli, Hans Sjostrand, Charles E. Perkins, Jari Arkko, Vijay Devarapalli, Hans Sjostrand, et
Peng Yang and et al. in the development of this document. al. in the development of this document.
The efforts of McCann Peter and Henrik Levkowetz in reviewing this The efforts of McCann Peter and Henrik Levkowetz in reviewing this
document are gratefully acknowledged. document are gratefully acknowledged.
7. Conclusion 8. Conclusion
This document verified that mobile node could get home network This document verified that mobile node could get home network
configuration based on DHCPINFORM without any revision of basic configuration based on DHCPINFORM without any revision of basic
mobile IP specification. mobile IP specification.
8. Normative References 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, [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985. September 1985.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994. October 1994.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994. Routing Encapsulation (GRE)", RFC 1701, October 1994.
skipping to change at page 21, line 5 skipping to change at page 29, line 5
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001. revised", RFC 3024, January 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
Author's Address Authors' Addresses
Hui Deng Hui Deng
China Mobile China Mobile
53A,Xibianmennei Ave., 53A,Xibianmennei Ave.,
Xuanwu District, Xuanwu District,
Beijing 100053 Beijing 100053
China China
Email: denghui02@gmail.com Email: denghui02@gmail.com
Full Copyright Statement Peng Yang
Hitachi (China) R&D Corp
Copyright (C) The IETF Trust (2008). N-301, building C, Raycom Infotech Park
Haidian District,
This document is subject to the rights, licenses and restrictions Beijing 100190
contained in BCP 78, and except as set forth therein, the authors China
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 Email: peng.yang.chn@gmail.com
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.
 End of changes. 31 change blocks. 
101 lines changed or deleted 449 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/