draft-ietf-dhc-dhcpv4-over-dhcpv6-07.txt   draft-ietf-dhc-dhcpv4-over-dhcpv6-08.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: October 17, 2014 M. Siodelski Expires: November 24, 2014 M. Siodelski
ISC ISC
S. Krishnan S. Krishnan
Ericsson Ericsson
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
April 15, 2014 May 23, 2014
DHCPv4 over DHCPv6 Transport DHCPv4 over DHCPv6 Transport
draft-ietf-dhc-dhcpv4-over-dhcpv6-07 draft-ietf-dhc-dhcpv4-over-dhcpv6-08
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 October 17, 2014. This Internet-Draft will expire on November 13, 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 51 skipping to change at page 2, line 51
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).
This document describes a transport mechanism to carry DHCPv4 This document describes a transport mechanism to carry DHCPv4
messages using the DHCPv6 protocol for the dynamic provisioning of messages using the DHCPv6 protocol for the dynamic provisioning of
IPv4 addresses and other DHCPv4 specific configuration parameters IPv4 addresses and other DHCPv4 specific configuration parameters
across IPv6-only networks. It leverages the existing DHCPv4 across IPv6-only networks. It leverages the existing DHCPv4
infrastructure, e.g. failover, DNS updates, DHCP leasequery, etc. infrastructure, e.g. failover, DNS updates, DHCP Leasequery, etc.
When IPv6 multicast is used to transport 4o6 messages, another When IPv6 multicast is used to transport 4o6 messages, another
benefit is that the operator can gain information about the benefit is that the operator can gain information about the
underlying IPv6 network the 4o6 client is connected to from the the underlying IPv6 network the 4o6 client is connected to from the the
DHCPv6 relay agents the request has passed through. DHCPv6 relay agents the request has passed through.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 12, line 8 skipping to change at page 12, line 8
20 of [RFC3315]. 20 of [RFC3315].
The above logic only allows for separate relay destinations The above logic only allows for separate relay destinations
configured on the relay agent closest to the client (single relay configured on the relay agent closest to the client (single relay
hop). Multiple relaying hops are not considered in the case of hop). Multiple relaying hops are not considered in the case of
separate relay destinations. separate relay destinations.
10. DHCP 4o6 Server Behavior 10. DHCP 4o6 Server Behavior
When the server receives a DHCPv4-query message from a client, it When the server receives a DHCPv4-query message from a client, it
searches for the DHCPv4 Message option. The server discards the searches for the DHCPv4 Message option. The server discards a packet
packet without this option. The server MAY notify an administrator without this option. In addition, the server MAY notify an
about the receipt of a malformed packet. The mechanism for this administrator about the receipt of this malformed packet. The
notification is out of scope for this document. mechanism for this notification is out of scope for this document.
If the server finds a valid DHCPv4 Message option, it extracts the If the server finds a valid DHCPv4 Message option, it extracts the
original DHCPv4 message. Since the DHCPv4 message is encapsulated in original DHCPv4 message. Since the DHCPv4 message is encapsulated in
the DHCPv6 message, it lacks the information which is typically used the DHCPv6 message, it lacks the information which is typically used
by the DHCPv4 server, implementing [RFC2131], to make address by the DHCPv4 server, implementing [RFC2131], to make address
allocation decisions, e.g. giaddr for relayed messages and IPv4 allocation decisions, e.g. giaddr for relayed messages and IPv4
address of the interface which the server using to communicate with address of the interface which the server using to communicate with
directly connected client. Therefore, the DHCP 4o6 server allocates directly connected client. Therefore, the DHCP 4o6 server allocates
addresses according to the local address assignment policies addresses according to the local address assignment policies
determined by the server administrator. For example, if the determined by the server administrator. For example, if the
DHCPv4-query message has been sent via a relay, the server MAY use DHCPv4-query message has been sent via a relay, the server MAY use
the link-address field of the Relay-forward message as a lookup for the link-address field of the Relay-forward message as a lookup for
the IPv4 subnet to assign DHCPv4 address from. If the DHCPv4-query the IPv4 subnet to assign DHCPv4 address from. If the DHCPv4-query
message has been sent from a directly connected client, the server message has been sent from a directly connected client, the server
MAY use IPv6 source address of the message to determine the MAY use IPv6 source address of the message to determine the
appropriate IPv4 subnet to use for DHCPv4 address assignment. appropriate IPv4 subnet to use for DHCPv4 address assignment.
The server may also act as a DHCPv4 relay agent and forward the Alternatively, the server may act as a DHCPv4 relay agent and forward
DHCPv4 packet to a "normal" DHCPv4 server. In this case, the server the DHCPv4 packet to a "normal" DHCPv4 server. The details of such a
would need to set the giaddr to one of its own addresses and add solution have not been considered by the working group; describing
Relay Agent Information option (82), including a Link Selection that solution is out of scope of this document and is left as future
suboption [RFC3527] with the IPv4 subnet to assign a DHCPv4 address work should the need for it arise.
from, as mentioned above. There are other complexities with this
solution as enough information needs to be retained (or included in a
Relay Agent Information option) to be able to return the response
back to the client; how this might be done is outside the scope of
this document.
The server SHOULD use "flags" field of the DHCPv4-query message to The server SHOULD use "flags" field of the DHCPv4-query message to
create a response (server to client DHCPv4 message). The use of this create a response (server to client DHCPv4 message). The use of this
field is described in detail in Section 7. field is described in detail in Section 7.
When an appropriate DHCPv4 response is created, the server places it When an appropriate DHCPv4 response is created, the server places it
in the payload of a DHCPv4 Message option, which it puts into the in the payload of a DHCPv4 Message option, which it puts into the
DHCPv4-response message. DHCPv4-response message.
If the DHCPv4-query message was received directly by the server, the If the DHCPv4-query message was received directly by the server, the
skipping to change at page 13, line 28 skipping to change at page 13, line 25
It is possible for a rogue server to reply with a 4o6 Server Address It is possible for a rogue server to reply with a 4o6 Server Address
Option containing duplicated IPv6 addresses, which could cause an Option containing duplicated IPv6 addresses, which could cause an
amplification attack. To avoid this, the client MUST check if there amplification attack. To avoid this, the client MUST check if there
are duplicate IPv6 addresses in a 4o6 Server Address Option when are duplicate IPv6 addresses in a 4o6 Server Address Option when
receiving one. The client MUST ignore any but the first instance of receiving one. The client MUST ignore any but the first instance of
each address. each address.
12. IANA Considerations 12. IANA Considerations
IANA is requested to allocate two DHCPv6 option codes for use by IANA is requested to allocate two DHCPv6 option codes for use by
OPTION_DHCPV4_MSG, OPTION_DHCP4_O_DHCP6_SERVER from the "DHCP Option OPTION_DHCPV4_MSG and OPTION_DHCP4_O_DHCP6_SERVER from the "Option
Codes" table, and two DHCPv6 message type codes for the DHCPV4-QUERY Codes" table, and two DHCPv6 message type codes for the DHCPV4-QUERY
and DHCPV4-RESPONSE from the "DHCP Message Codes" table of the and DHCPV4-RESPONSE from the "Message Types" table of the Dynamic
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Registry. Both Host Configuration Protocol for IPv6 (DHCPv6) Registry. Both tables
tables can be found at http://www.iana.org/assignments/ can be found at http://www.iana.org/assignments/dhcpv6-parameters/.
dhcpv6-parameters/dhcpv6-parameters.xml.
13. Contributors List 13. Contributors List
Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen
and Cong Liu, for their great contributions to the draft. and Cong Liu, for their great contributions to the draft.
14. References 14. References
14.1. Normative References 14.1. Normative References
skipping to change at page 14, line 24 skipping to change at page 14, line 16
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-08 (work in Messages", draft-ietf-dhc-dhcpv6-unknown-msg-08 (work in
progress), March 2014. progress), March 2014.
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
"Link Selection sub-option for the Relay Agent Information
Option for DHCPv4", RFC 3527, April 2003.
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. 10 change blocks. 
28 lines changed or deleted 18 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/