draft-ietf-dhc-dhcpv4-over-dhcpv6-06.txt   draft-ietf-dhc-dhcpv4-over-dhcpv6-07.txt 
DHC Working Group Q. Sun DHC Working Group Q. Sun
Internet-Draft Y. Cui Internet-Draft Y. Cui
Intended status: Standards Track Tsinghua University Intended status: Standards Track Tsinghua University
Expires: August 23, 2014 M. Siodelski Expires: October 17, 2014 M. Siodelski
ISC ISC
S. Krishnan S. Krishnan
Ericsson Ericsson
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
February 19, 2014 April 15, 2014
DHCPv4 over DHCPv6 Transport DHCPv4 over DHCPv6 Transport
draft-ietf-dhc-dhcpv4-over-dhcpv6-06 draft-ietf-dhc-dhcpv4-over-dhcpv6-07
Abstract Abstract
IPv4 connectivity is still needed as networks migrate towards IPv6. IPv4 connectivity is still needed as networks migrate towards IPv6.
Users require IPv4 configuration even if the uplink to their service Users require IPv4 configuration even if the uplink to their service
provider supports IPv6 only. This document describes a mechanism for provider supports IPv6 only. This document describes a mechanism for
obtaining IPv4 configuration information dynamically in IPv6 networks obtaining IPv4 configuration information dynamically in IPv6 networks
by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6
messages and two new DHCPv6 options are defined for this purpose. messages and two new DHCPv6 options are defined for this purpose.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 23, 2014. This Internet-Draft will expire on October 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 5 5.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 5
5.3. DHCPv4-query Message Flags . . . . . . . . . . . . . . . 6 5.3. DHCPv4-query Message Flags . . . . . . . . . . . . . . . 6
5.4. DHCPv4-response Message Flags . . . . . . . . . . . . . . 7 5.4. DHCPv4-response Message Flags . . . . . . . . . . . . . . 7
6. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 7 6. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 7
6.1. DHCPv4 Message Option Format . . . . . . . . . . . . . . 7 6.1. DHCPv4 Message Option Format . . . . . . . . . . . . . . 7
6.2. 4o6 Server Address Option Format . . . . . . . . . . . . 8 6.2. 4o6 Server Address Option Format . . . . . . . . . . . . 8
7. Use of the DHCPv4-query Unicast Flag . . . . . . . . . . . . 9 7. Use of the DHCPv4-query Unicast Flag . . . . . . . . . . . . 9
8. DHCP 4o6 Client Behavior . . . . . . . . . . . . . . . . . . 9 8. DHCP 4o6 Client Behavior . . . . . . . . . . . . . . . . . . 9
9. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 11 9. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 11
10. DHCP 4o6 Server Behavior . . . . . . . . . . . . . . . . . . 11 10. DHCP 4o6 Server Behavior . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 13 13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
14.1. Normative References . . . . . . . . . . . . . . . . . . 13 14.1. Normative References . . . . . . . . . . . . . . . . . . 13
14.2. Informative References . . . . . . . . . . . . . . . . . 13 14.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
As the migration towards IPv6 continues, IPv6-only networks will As the migration towards IPv6 continues, IPv6-only networks will
become more prevalent. In such networks, IPv4 connectivity will become more prevalent. In such networks, IPv4 connectivity will
continue to be provided as a service over IPv6-only networks. In continue to be provided as a service over IPv6-only networks. In
addition to provisioning IPv4 addresses for clients of this service, addition to provisioning IPv4 addresses for clients of this service,
other IPv4 configuration parameters may also be needed (e.g. other IPv4 configuration parameters may also be needed (e.g.
addresses of IPv4-only services). addresses of IPv4-only services).
skipping to change at page 4, line 15 skipping to change at page 4, line 15
protocol. protocol.
Although the purpose of this document is to address the problem of Although the purpose of this document is to address the problem of
communication between the DHCPv4 client and the DHCPv4 server, the communication between the DHCPv4 client and the DHCPv4 server, the
mechanism that it describes does not restrict the transported mechanism that it describes does not restrict the transported
messages types to DHCPv4 only. As the DHCPv4 message is a special messages types to DHCPv4 only. As the DHCPv4 message is a special
type of BOOTP message, BOOTP messages can also be transported using type of BOOTP message, BOOTP messages can also be transported using
the same mechanism. the same mechanism.
DHCP clients may be running on CPE devices, end hosts or any other DHCP clients may be running on CPE devices, end hosts or any other
device that supports the DHCP client function. At the time of device that supports the DHCP client function. This document uses
writing, DHCP clients on CPE devices are comparatively easier to the CPE as an example for describing the mechanism. This does not
modify than those implemented on end hosts. As a result, this preclude any end-host, or other device requiring IPv4 configuration,
document uses the CPE as an example for describing the mechanism. from implementing DHCPv4 over DHCPv6 in the future.
This does not preclude any end-host, or other device requiring IPv4
configuration, from implementing DHCPv4 over DHCPv6 in the future.
This mechanism works by carrying DHCPv4 messages encapsulated within This mechanism works by carrying DHCPv4 messages encapsulated within
DHCPv6 messages. Figure 1, below, illustrates one possible DHCPv6 messages. Figure 1, below, illustrates one possible
deployment architecture. deployment architecture.
The DHCP 4o6 client implements a new DHCPv6 message called The DHCP 4o6 client implements a new DHCPv6 message called
DHCPv4-query, which contains a new option called the DHCPv4 Message DHCPv4-query, which contains a new option called the DHCPv4 Message
option encapsulating a DHCPv4 message sent by the client. The format option encapsulating a DHCPv4 message sent by the client. The format
of this option is described in Section 6.1. of this option is described in Section 6.1.
skipping to change at page 9, line 11 skipping to change at page 9, line 11
IPv6 Address Zero or more IPv6 addresses of the DHCP 4o6 IPv6 Address Zero or more IPv6 addresses of the DHCP 4o6
Server(s). Server(s).
7. Use of the DHCPv4-query Unicast Flag 7. Use of the DHCPv4-query Unicast Flag
A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST
message to either a broadcast or unicast address depending on its message to either a broadcast or unicast address depending on its
state. For example, a client in the RENEWING state uses a unicast state. For example, a client in the RENEWING state uses a unicast
address to contact the DHCPv4 server to renew its lease. A client in address to contact the DHCPv4 server to renew its lease. A client in
the REBINDING state uses a broadcast address. If there is a DHCPv4 the REBINDING state uses a broadcast address.
relay agent in the middle, a client in the RENEWING state may send a
DHCPREQUEST message to the unicast address of the relay agent. In
such a case, the server is unable to determine whether the client
sent the message to a unicast or broadcast address and thus the
server may be unable to correctly determine the client's state.
[RFC5010] introduced the "Flags Suboption" that relay agents add to
relayed messages to indicate whether broadcast or unicast was used by
the client.
In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the
DHCP 4o6 server. There is no relation between the outer IPv6 address DHCP 4o6 server. There is no relation between the outer IPv6 address
and the inner DHCPv4 message. As a result, the server is unable to and the inner DHCPv4 message. As a result, the server is unable to
determine whether the received DHCPv4 messages should have been sent determine whether the received DHCPv4 messages should have been sent
using broadcast or unicast in IPv4 by checking the IPv6 address. using broadcast or unicast in IPv4 by checking the IPv6 address.
This is similar to the case addressed by [RFC5010].
In order to allow the server to determine the client's state, the In order to allow the server to determine the client's state, the
"Unicast" flag is carried in the DHCPv4-query message. The client "Unicast" flag is carried in the DHCPv4-query message. The client
MUST set this flag to 1 when the DHCPv4 message would have been sent MUST set this flag to 1 when the DHCPv4 message would have been sent
to the unicast address if using DHCPv4 over IPv4. This flag MUST be to the unicast address if using DHCPv4 over IPv4. This flag MUST be
set to 0 if the DHCPv4 client would have sent the message to the set to 0 if the DHCPv4 client would have sent the message to the
broadcast address in IPv4. The choice whether a given message should broadcast address in IPv4. The choice whether a given message should
be sent to a broadcast or unicast address is made based on the be sent to a broadcast or unicast address is made based on the
[RFC2131] and its extensions. [RFC2131] and its extensions.
skipping to change at page 9, line 50 skipping to change at page 9, line 41
8. DHCP 4o6 Client Behavior 8. DHCP 4o6 Client Behavior
The DHCPv4-over-DHCPv6 function MUST be disabled by default. The The DHCPv4-over-DHCPv6 function MUST be disabled by default. The
client MUST obtain the necessary IPv6 configuration (stateless or client MUST obtain the necessary IPv6 configuration (stateless or
stateful) before using DHCPv4 over DHCPv6. The client intending to stateful) before using DHCPv4 over DHCPv6. The client intending to
use DHCPv4 over DHCPv6 MUST request the 4o6 Server Address option use DHCPv4 over DHCPv6 MUST request the 4o6 Server Address option
using Option Request option (ORO) in every Solicit, Request, Renew, using Option Request option (ORO) in every Solicit, Request, Renew,
Rebind and Information-request message. Rebind and Information-request message.
The server MAY include the 4o6 Server Address option in its response The server MAY include the 4o6 Server Address option in its response
to the client. If the client receives this option, it MUST enable to the client. If the client receives this option, it enables the
the DHCPv4-over-DHCPv6 function. The client MUST NOT enable the DHCPv4-over-DHCPv6 function. The client MUST NOT enable the DHCPv4
DHCPv4-over-DHCPv6 function if the server does not include the 4o6 -over-DHCPv6 function if the server does not include the 4o6 Server
Server Address option in its response. If the client does not Address option in its response. If the DHCPv6 configuration that
receive this option and DHCPv4 over DHCPv6 is already enabled, the contained the 4o6 Server Address option subsequently expires, the
client MUST disable the DHCPv4-over-DHCPv6 function. client MUST disable the DHCPv4-over-DHCPv6 function. If, when the
DHCPv6 configuration that contained the 4o6 Server Address option is
renewed, the renewed configuration does not contain a 4o6 Server
Address option, the client MUST disable the DHCPv4-over-DHCPv6
function.
It is possible in a multi-homed configuration for there to be more
than one DHCPv6 configuration active at the same time that contains a
4o6 Server Address option. In this case, the configurations are
treated as being independent, so that when any such configuration is
active, a DHCPv4-over-DHCPv6 function may be enabled for that
configuration.
An implementation may also treat such configurations as being
exclusive, such that only one is kept active at a time. In this
case, the client keeps the same configuration active continuously as
long as it is valid. If that configuration becomes invalid but one
or more other configurations remain valid, the client activates one
of the remaining valid configurations.
Which strategy to follow is dependent on the implementation: keeping
multiple configurations active at the same time may provide useful
redundancy in some applications, but may be needlessly complex in
other cases.
If the client receives the 4o6 Server Address option and there is a If the client receives the 4o6 Server Address option and there is a
DHCPv4 client active on the interface over which that DHCPv6 option DHCPv4 client active on the interface over which that DHCPv6 option
was received, it MUST stop the DHCPv4 client from sending messages was received, it MUST stop the DHCPv4 client from sending messages
using [RFC2131]. using [RFC2131].
If the client receives a 4o6 Server Address option that contains no If the client receives a 4o6 Server Address option that contains no
IP addresses, i.e. the option is empty, the client MUST send its IP addresses, i.e. the option is empty, the client MUST send its
requests to the All_DHCP_Relay_Agents_and_Servers multicast address. requests to the All_DHCP_Relay_Agents_and_Servers multicast address.
If there is a list of IP addresses in the option, the client SHOULD If there is a list of IP addresses in the option, the client SHOULD
skipping to change at page 13, line 49 skipping to change at page 14, line 21
IPv6 (DHCPv6)", RFC 4242, November 2005. IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006. Version Four (DHCPv4)", RFC 4361, February 2006.
14.2. Informative References 14.2. Informative References
[I-D.ietf-dhc-dhcpv6-unknown-msg] [I-D.ietf-dhc-dhcpv6-unknown-msg]
Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
Messages", draft-ietf-dhc-dhcpv6-unknown-msg-05 (work in Messages", draft-ietf-dhc-dhcpv6-unknown-msg-08 (work in
progress), February 2014. progress), March 2014.
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
"Link Selection sub-option for the Relay Agent Information "Link Selection sub-option for the Relay Agent Information
Option for DHCPv4", RFC 3527, April 2003. Option for DHCPv4", RFC 3527, April 2003.
[RFC5010] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host
Configuration Protocol Version 4 (DHCPv4) Relay Agent
Flags Suboption", RFC 5010, September 2007.
Authors' Addresses Authors' Addresses
Qi Sun Qi Sun
Tsinghua University Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: sunqi@csnet1.cs.tsinghua.edu.cn Email: sunqi@csnet1.cs.tsinghua.edu.cn
 End of changes. 12 change blocks. 
35 lines changed or deleted 43 lines changed or added

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