draft-ietf-dhc-dhcpv4-over-dhcpv6-05.txt   draft-ietf-dhc-dhcpv4-over-dhcpv6-06.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 18, 2014 M. Siodelski Expires: August 23, 2014 M. Siodelski
ISC ISC
S. Krishnan S. Krishnan
Ericsson Ericsson
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
February 14, 2014 February 19, 2014
DHCPv4 over DHCPv6 Transport DHCPv4 over DHCPv6 Transport
draft-ietf-dhc-dhcpv4-over-dhcpv6-05 draft-ietf-dhc-dhcpv4-over-dhcpv6-06
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 18, 2014. This Internet-Draft will expire on August 23, 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 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 8, line 12 skipping to change at page 8, line 12
In a DHCPv4-query message it contains a DHCPv4 In a DHCPv4-query message it contains a DHCPv4
message sent by a client. In a DHCPv4-response message sent by a client. In a DHCPv4-response
message it contains a DHCPv4 message sent by a server message it contains a DHCPv4 message sent by a server
in response to a client. in response to a client.
6.2. 4o6 Server Address Option Format 6.2. 4o6 Server Address Option Format
The 4o6 Server Address option is sent by a server to a client The 4o6 Server Address option is sent by a server to a client
requesting IPv6 configuration using DHCPv6 [RFC3315]. It carries a requesting IPv6 configuration using DHCPv6 [RFC3315]. It carries a
list of DHCP 4o6 server's IPv6 addresses that the client should list of DHCP 4o6 server's IPv6 addresses that the client should
contact to obtain IPv4 configuration. This list may include either contact to obtain IPv4 configuration. This list may include
multicast or unicast addresses. The client sends its requests to all multicast and unicast addresses. The client sends its requests to
unique addresses carried in this option. all unique addresses carried in this option.
This option may also carry no IPv6 addresses, which instructs the This option may also carry no IPv6 addresses, which instructs the
client to use the All_DHCP_Relay_Agents_and_Servers multicast address client to use the All_DHCP_Relay_Agents_and_Servers multicast address
as the destination address. as the destination address.
The presence of this option in the server's response indicates to the The presence of this option in the server's response indicates to the
client that it should use DHCPv4 over DHCPv6 to obtain IPv4 client that it should use DHCPv4 over DHCPv6 to obtain IPv4
configuration. If the option is absent, the client MUST NOT enable configuration. If the option is absent, the client MUST NOT enable
DHCPv4-over-DHCPv6 function. DHCPv4-over-DHCPv6 function.
skipping to change at page 11, line 44 skipping to change at page 11, line 44
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 the
packet without this option. The server MAY notify an administrator packet without this option. The server MAY notify an administrator
about the receipt of a malformed packet. The mechanism for this about the receipt of a malformed packet. The mechanism for this
notification is out of scope for this document. 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 and the contents of the "flags" field carried original DHCPv4 message. Since the DHCPv4 message is encapsulated in
in the DHCPv4-query message and uses them to generate the appropriate the DHCPv6 message, it lacks the information which is typically used
DHCPv4 response (server to client message). The response is by the DHCPv4 server, implementing [RFC2131], to make address
generated as described in [RFC2131] with the exception that the allocation decisions, e.g. giaddr for relayed messages and IPv4
server SHOULD use the information carried in the "flags" field of the address of the interface which the server using to communicate with
DHCPv4-query message to find out whether the client's message would directly connected client. Therefore, the DHCP 4o6 server allocates
have been sent to the broadcast or unicast address if IPv4 has been addresses according to the local address assignment policies
used. This is useful for the server to determine the state of the determined by the server administrator. For example, if the
client. The use of the "flags" field is described in detail in DHCPv4-query message has been sent via a relay, the server MAY use
Section 7. 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
message has been sent from a directly connected client, the server
MAY use IPv6 source address of the message to determine the
appropriate IPv4 subnet to use for DHCPv4 address assignment.
When an appropriate DHCPv4 response is generated, the 4o6 Server The server may also act as a DHCPv4 relay agent and forward the
places it in the payload of a DHCPv4 Message option, which it puts DHCPv4 packet to a "normal" DHCPv4 server. In this case, the server
into the DHCPv4-response message. would need to set the giaddr to one of its own addresses and add
Relay Agent Information option (82), including a Link Selection
suboption [RFC3527] with the IPv4 subnet to assign a DHCPv4 address
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
create a response (server to client DHCPv4 message). The use of this
field is described in detail in Section 7.
When an appropriate DHCPv4 response is created, the server places it
in the payload of a DHCPv4 Message option, which it puts into the
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
DHCPv4-response message MUST be unicast from the interface on which DHCPv4-response message MUST be unicast from the interface on which
the original message was received. the original message was received.
If the DHCPv4-query message was received in a Relay-forward message, If the DHCPv4-query message was received in a Relay-forward message,
the server creates a Relay-reply message with the DHCPv4-response the server creates a Relay-reply message with the DHCPv4-response
message in the payload of a Relay Message option, and responds as message in the payload of a Relay Message option, and responds as
described in section 20.3 of [RFC3315]. described in section 20.3 of [RFC3315].
skipping to change at page 13, line 34 skipping to change at page 14, line 5
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-05 (work in
progress), February 2014. progress), February 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.
[RFC5010] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host [RFC5010] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host
Configuration Protocol Version 4 (DHCPv4) Relay Agent Configuration Protocol Version 4 (DHCPv4) Relay Agent
Flags Suboption", RFC 5010, September 2007. 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
 End of changes. 10 change blocks. 
23 lines changed or deleted 46 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/