draft-ietf-dhc-dhcpv4-over-dhcpv6-04.txt   draft-ietf-dhc-dhcpv4-over-dhcpv6-05.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: July 20, 2014 M. Siodelski Expires: August 18, 2014 M. Siodelski
ISC ISC
S. Krishnan S. Krishnan
Ericsson Ericsson
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
January 16, 2014 February 14, 2014
DHCPv4 over DHCPv6 Transport DHCPv4 over DHCPv6 Transport
draft-ietf-dhc-dhcpv4-over-dhcpv6-04 draft-ietf-dhc-dhcpv4-over-dhcpv6-05
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 July 20, 2014. This Internet-Draft will expire on August 18, 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 26 skipping to change at page 2, line 26
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3
5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5 5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . 12
13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 12 13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 20 skipping to change at page 3, line 20
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
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
This document makes use of the following terms: This document makes use of the following terms:
DHCP 4o6 Client: A DHCP client supporting both the DHCPv6 protocol CPE: Customer Premises Equipment (also
[RFC3315] as well as the DHCPv4 over DHCPv6 known as Customer Provided
protocol described in this document. Such a Equipment), which provides access for
client is capable of requesting IPv6 devices connected to a Local Area
configuration using DHCPv6 and IPv4 configuration Network (typically at the customer's
using DHCPv4 over DHCPv6. site/home) to the Internet Service
Provider's network.
DHCP 4o6 Server: A DHCP server that is capable of processing DHCP 4o6 client (or client): A DHCP client supporting both the
DHCPv4 packets encapsulated in the DHCPv4 Message DHCPv6 protocol [RFC3315] as well as
option (defined below). the DHCPv4 over DHCPv6 protocol
described in this document. Such a
client is capable of requesting IPv6
configuration using DHCPv6 and IPv4
configuration using DHCPv4 over
DHCPv6.
CPE: Customer Premises Equipment (also known as DHCP 4o6 server (or server): A DHCP server that is capable of
Customer Provided Equipment), which provides processing DHCPv4 packets
access for devices connected to a Local Area encapsulated in the DHCPv4 Message
Network (typically at the customer's site/home) option (defined below).
to the Internet Service Provider's network.
DHCPv4 over DHCPv6: A protocol described in this document, used to DHCPv4 over DHCPv6: A protocol described in this
carry DHCPv4 messages in the payload of DHCPv6 document, used to carry DHCPv4
messages. messages in the payload of DHCPv6
messages.
4. Architecture Overview 4. Architecture Overview
The architecture described here addresses a typical use case, where a The architecture described here addresses a typical use case, where a
DHCP client's uplink supports IPv6 only and the Service Provider's DHCP client's uplink supports IPv6 only and the Service Provider's
network supports IPv6 and limited IPv4 services. In this scenario, network supports IPv6 and limited IPv4 services. In this scenario,
the client can only use the IPv6 network to access IPv4 services, so the client can only use the IPv6 network to access IPv4 services, so
IPv4 services must be configured using IPv6 as the underlying network IPv4 services must be configured using IPv6 as the underlying network
protocol. protocol.
skipping to change at page 4, line 26 skipping to change at page 4, line 32
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.
The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents
or directly to the DHCP 4o6 Server. The server replies with a or directly to the DHCP 4o6 server. The server replies with a
DHCPv4-response message, which is a new DHCPv6 message carrying the DHCPv4-response message, which is a new DHCPv6 message carrying the
DHCPv4 response encapsulated in the DHCPv4 Message option. DHCPv4 response encapsulated in the DHCPv4 Message option.
_____________ _____________ _____________ _____________
/ \ / \ / \ / \
| | | | | | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| DHCP 4o6 | network | DHCPv6 | network | DHCP 4o6 | | DHCP 4o6 | network | DHCPv6 | network | DHCP 4o6 |
| Client +---------+ Relay Agent +---------+ Server | | client +---------+ Relay Agent +---------+ Server |
| (on CPE) | | | | | | (on CPE) | | | | |
+--------+-+ +-+-----------+-+ +-+--------+ +--------+-+ +-+-----------+-+ +-+--------+
| | | | | | | |
\_____________/ \_____________/ \_____________/ \_____________/
Figure 1: Architecture Overview Figure 1: Architecture Overview
By default, the DHCPv4-over-DHCPv6 function MUST be disabled on the By default, the DHCPv4-over-DHCPv6 function MUST be disabled on the
client. Before the client can use DHCPv4 over DHCPv6, it MUST obtain client. Before the client can use DHCPv4 over DHCPv6, it MUST obtain
the necessary IPv6 configuration. The client requests the 4o6 Server the necessary IPv6 configuration. The client requests the 4o6 Server
Address option from the DHCPv6 server by sending the option code in Address option from the server by sending the option code in Option
Option Request option as described in [RFC3315]. If the DHCPv6 Request option as described in [RFC3315]. If the server responds
server responds with the 4o6 Server Address option, it is an with the 4o6 Server Address option, it is an indication to the client
indication to the client to attempt using DHCPv4 over DHCPv6 to to attempt using DHCPv4 over DHCPv6 to obtain IPv4 configuration.
obtain IPv4 configuration.
The DHCP 4o6 client obtains the address(es) of the DHCP 4o6 server(s) The client obtains the address(es) of the DHCP 4o6 server(s) from the
from the 4o6 Server Address option and uses them to communicate with 4o6 Server Address option and uses them to communicate with the DHCP
the DHCP 4o6 servers as described in Section 8. If the 4o6 Server 4o6 servers as described in Section 8. If the 4o6 Server Address
Address option contains no addresses (is empty), the DHCP 4o6 client option contains no addresses (is empty), the client uses the well-
uses the well-known All_DHCP_Relay_Agents_and_Servers multicast known All_DHCP_Relay_Agents_and_Servers multicast address to
address to communicate with the DHCP 4o6 server(s). communicate with the DHCP 4o6 server(s).
Before applying for an IPv4 address via a DHCPv4-query message, the Before applying for an IPv4 address via a DHCPv4-query message, the
DHCP 4o6 client must identify a suitable network interface for the client must identify a suitable network interface for the address.
address. Once the request is acknowledged by the DHCP 4o6 server, Once the request is acknowledged by the server, the client can
the client can configure the address and other relevant parameters on configure the address and other relevant parameters on this
this interface. The mechanism for determining a suitable interface interface. The mechanism for determining a suitable interface is out
is out of the scope of the document. of the scope of the document.
5. New DHCPv6 Messages 5. New DHCPv6 Messages
Two new DHCPv6 messages carry DHCPv4 messages between the client and Two new DHCPv6 messages carry DHCPv4 messages between the client and
the server using the DHCPv6 protocol: DHCPv4-query and the server using the DHCPv6 protocol: DHCPv4-query and
DHCPv4-response. This section describes the structures of these DHCPv4-response. This section describes the structures of these
messages. messages.
5.1. Message Types 5.1. Message Types
skipping to change at page 6, line 47 skipping to change at page 6, line 47
The "flags" field of the DHCPv4-query is used to carry additional The "flags" field of the DHCPv4-query is used to carry additional
information that may be used by the server to process the information that may be used by the server to process the
encapsulated DHCPv4 message. Currently only one bit of this field is encapsulated DHCPv4 message. Currently only one bit of this field is
used. Remaining bits are reserved for the future use. The "flags" used. Remaining bits are reserved for the future use. The "flags"
field has the following format: field has the following format:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Reserved | |U| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DHCPv4-query flags format Figure 3: DHCPv4-query flags format
U Unicast Flag. If set to 1, it indicates that the U Unicast Flag. If set to 1, it indicates that the
DHCPv4 message encapsulated within the DHCPv4-query DHCPv4 message encapsulated within the DHCPv4-query
message would be sent to a unicast address if it was message would be sent to a unicast address if it was
sent using IPv4. If this flag is set to 0, it sent using IPv4. If this flag is set to 0, it
indicates that the DHCPv4 message would be sent to indicates that the DHCPv4 message would be sent to
the broadcast address if it was sent using IPv4. the broadcast address if it was sent using IPv4. The
usage of the flag is described in detail in
Section 7.
Reserved Bits MUST be set to zero when sending and MUST be MBZ Bits MUST be set to zero when sending and MUST be
ignored when receiving. ignored when receiving.
5.4. DHCPv4-response Message Flags 5.4. DHCPv4-response Message Flags
This document introduces no flags to be carried in the "flags" field This document introduces no flags to be carried in the "flags" field
of the DHCPv4-response message. They are all reserved for the future of the DHCPv4-response message. They are all reserved for the future
use. The 4o6 Server MUST set all bits of this field to 0 and the 4o6 use. The DHCP 4o6 server MUST set all bits of this field to 0 and
client MUST ignore the content in this field. the DHCP 4o6 client MUST ignore the content in this field.
6. New DHCPv6 Options 6. New DHCPv6 Options
6.1. DHCPv4 Message Option Format 6.1. DHCPv4 Message Option Format
The DHCPv4 Message option carries a DHCPv4 message that is sent by The DHCPv4 Message option carries a DHCPv4 message that is sent by
the client or the server. Such messages exclude any IP or UDP the client or the server. Such messages exclude any IP or UDP
headers. headers.
The format of the DHCPv4 Message option is: The format of the DHCPv4 Message option is:
skipping to change at page 8, line 7 skipping to change at page 8, line 9
option-len Length of the DHCPv4 message. option-len Length of the DHCPv4 message.
DHCPv4-message The DHCPv4 message sent by the client or the server. DHCPv4-message The DHCPv4 message sent by the client or the server.
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 the DHCPv6 server to a The 4o6 Server Address option is sent by a server to a client
client requesting IPv6 configuration. It carries a list of DHCP 4o6 requesting IPv6 configuration using DHCPv6 [RFC3315]. It carries a
server's IPv6 addresses that the DHCP 4o6 client should contact to list of DHCP 4o6 server's IPv6 addresses that the client should
obtain IPv4 configuration. This list may include either multicast or contact to obtain IPv4 configuration. This list may include either
unicast addresses. The DHCP 4o6 client sends its requests to all multicast or unicast addresses. The client sends its requests to all
unique addresses carried in this option. 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 DHCPv6 server's response indicates The presence of this option in the server's response indicates to the
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.
The format of the 4o6 Server Address option is: The format of the 4o6 Server Address option is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DHCP4_O_DHCP6_SERVER | option-len | | OPTION_DHCP4_O_DHCP6_SERVER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. IPv6 Address(es) . . IPv6 Address(es) .
skipping to change at page 9, line 15 skipping to change at page 9, line 22
relay agent in the middle, a client in the RENEWING state may send a 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 DHCPREQUEST message to the unicast address of the relay agent. In
such a case, the server is unable to determine whether the client such a case, the server is unable to determine whether the client
sent the message to a unicast or broadcast address and thus the sent the message to a unicast or broadcast address and thus the
server may be unable to correctly determine the client's state. server may be unable to correctly determine the client's state.
[RFC5010] introduced the "Flags Suboption" that relay agents add to [RFC5010] introduced the "Flags Suboption" that relay agents add to
relayed messages to indicate whether broadcast or unicast was used by relayed messages to indicate whether broadcast or unicast was used by
the client. 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
4o6 DHCP 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]. 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.
Note: The "Unicast" flag reflects how the DHCPv4 packet would have Note: The "Unicast" flag reflects how the DHCPv4 packet would have
been sent; not how the DHCPv6 packet itself is sent. been sent; not how the DHCPv6 packet itself is sent.
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 before using client MUST obtain the necessary IPv6 configuration (stateless or
DHCPv4 over DHCPv6. A client intending to use DHCPv4 over DHCPv6 stateful) before using DHCPv4 over DHCPv6. The client intending to
MUST request the 4o6 Server Address option using Option Request use DHCPv4 over DHCPv6 MUST request the 4o6 Server Address option
option (ORO) in every Solicit, Request, Renew and Information-request using Option Request option (ORO) in every Solicit, Request, Renew,
message. Rebind and Information-request message.
The DHCPv6 server MAY include the 4o6 Server Address option in its The server MAY include the 4o6 Server Address option in its response
response to the client. If the client receives this option, it MUST to the client. If the client receives this option, it MUST enable
enable the DHCPv4-over-DHCPv6 function. The client MUST NOT enable the DHCPv4-over-DHCPv6 function. The client MUST NOT enable the
the DHCPv4-over-DHCPv6 function if the DHCPv6 server does not include DHCPv4-over-DHCPv6 function if the server does not include the 4o6
the 4o6 Server Address option in its response. If the client does Server Address option in its response. If the client does not
not receive this option and DHCPv4 over DHCPv6 is already enabled, receive this option and DHCPv4 over DHCPv6 is already enabled, the
the client MUST disable the DHCPv4-over-DHCPv6 function. client MUST disable the DHCPv4-over-DHCPv6 function.
If the DHCP 4o6 client receives the 4o6 Server Address option and If the client receives the 4o6 Server Address option and there is a
there is a DHCPv4 client active on the interface over which that DHCPv4 client active on the interface over which that DHCPv6 option
DHCPv6 option was received, it MUST stop the DHCPv4 client from was received, it MUST stop the DHCPv4 client from sending messages
sending messages using [RFC2131]. using [RFC2131].
If the 4o6 client receives a 4o6 Server Address option that contains If the client receives a 4o6 Server Address option that contains no
no IP addresses, i.e. the option is empty, the DHCP 4o6 client MUST IP addresses, i.e. the option is empty, the client MUST send its
send its requests to the All_DHCP_Relay_Agents_and_Servers multicast requests to the All_DHCP_Relay_Agents_and_Servers multicast address.
address. If there is a list of IP addresses in the option, the DHCP If there is a list of IP addresses in the option, the client SHOULD
4o6 client SHOULD send requests to each unique address carried by the send requests to each unique address carried by the option.
option.
The DHCP 4o6 client MUST employ an IPv6 address of an appropriate If the client obtained stateless IPv6 configuration by sending
scope to source the DHCPv4-query message from. When the client sends Information-request message to the server, the client MUST follow the
a DHCPv4-query message to the multicast address, it MUST use a link- rules in [RFC4242] to periodically refresh the DHCPv4-over-DHCPv6
configuration (i.e. list of DHCP 4o6 servers) as well as other
configuration data. The client which obtained stateful IPv6
configuration will refresh the status of DHCPv4-over-DHCPv6 function
when extending a lifetime of acquired IPv6 address (Renew and Rebind
messages).
The client MUST employ an IPv6 address of an appropriate scope to
source the DHCPv4-query message from. When the client sends a
DHCPv4-query message to the multicast address, it MUST use a link-
local address as the source address as described in [RFC3315]. When local address as the source address as described in [RFC3315]. When
the client sends a DHCPv4-query message using unicast, the source the client sends a DHCPv4-query message using unicast, the source
address MUST be the global IPv6 address, acquired in advance. address MUST be an address of appropriate scope, acquired in advance.
A client supporting DHCPv4 over DHCPv6 SHOULD use Information Refresh
Time Option [RFC4242] to refresh the status of DHCPv4-over-DHCPv6
function as well as other DHCPv6 configuration data.
The client generates a DHCPv4 message and stores it verbatim in the The client generates a DHCPv4 message and stores it verbatim in the
DHCPv4 Message option carried by the DHCPv4-query message. The DHCPv4 Message option carried by the DHCPv4-query message. The
client MUST put exactly one DHCPv4 Message option into a single client MUST put exactly one DHCPv4 Message option into a single
DHCPv4-query message. The client MUST NOT request the 4o6 Server DHCPv4-query message. The client MUST NOT request the 4o6 Server
Address option in the DHCPv4-query message. Address option in the DHCPv4-query message.
The client MUST follow rules defined in Section 7 when setting the The client MUST follow rules defined in Section 7 when setting the
Unicast flag based on the DHCPv4 destination. Unicast flag based on the DHCPv4 destination.
On receiving a DHCPv4-response message, the client MUST look for the On receiving a DHCPv4-response message, the client MUST look for the
DHCPv4 Message option within this message. If this option is not DHCPv4 Message option within this message. If this option is not
found, the DHCPv4-response message is discarded. If the DHCPv4 found, the DHCPv4-response message is discarded. If the DHCPv4
Message option is present, the client extracts the DHCPv4 message it Message option is present, the client extracts the DHCPv4 message it
contains and processes it as described in section 4.4 of [RFC2131]. contains and processes it as described in section 4.4 of [RFC2131].
When dealing with IPv4 configuration, the DHCP 4o6 client MUST follow When dealing with IPv4 configuration, the client MUST follow the
the normal DHCPv4 retransmission requirements and strategy as normal DHCPv4 retransmission requirements and strategy as specified
specified in section 4.1 of [RFC2131]. There are no explicit in section 4.1 of [RFC2131]. There are no explicit transmission
transmission parameters associated with a DHCPv4-query message, as parameters associated with a DHCPv4-query message, as this is
this is governed by the DHCPv4 [RFC2131] "state machine". governed by the DHCPv4 [RFC2131] "state machine".
The DHCP 4o6 client MUST implement [RFC4361] to ensure that the The client MUST implement [RFC4361] to ensure that the device
device correctly identifies itself. correctly identifies itself.
9. Relay Agent Behavior 9. Relay Agent Behavior
When a DHCPv6 relay agent receives a DHCPv4-query message, it may not When a DHCPv6 relay agent receives a DHCPv4-query message, it may not
recognize this message. The unknown message can be forwarded as recognize this message. The unknown message can be forwarded as
described in [I-D.ietf-dhc-dhcpv6-unknown-msg]. described in [I-D.ietf-dhc-dhcpv6-unknown-msg].
Additionally, the DHCPv6 relay agent MAY allow the configuration of a Additionally, the DHCPv6 relay agent MAY allow the configuration of a
dedicated DHCPv4 over DHCPv6 specific destination address(es), dedicated DHCPv4 over DHCPv6 specific destination address(es),
differing from the address(es) of the DHCPv6-only server(s). To differing from the address(es) of the DHCPv6-only server(s). To
skipping to change at page 11, line 47 skipping to change at page 12, line 5
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 and the contents of the "flags" field carried
in the DHCPv4-query message and uses them to generate the appropriate in the DHCPv4-query message and uses them to generate the appropriate
DHCPv4 response (server to client message). The response is DHCPv4 response (server to client message). The response is
generated as described in [RFC2131] with the exception that the generated as described in [RFC2131] with the exception that the
server SHOULD use the information carried in the "flags" field of the server SHOULD use the information carried in the "flags" field of the
DHCPv4-query message to find out whether the client's message would DHCPv4-query message to find out whether the client's message would
have been sent to the broadcast or unicast address if IPv4 has been have been sent to the broadcast or unicast address if IPv4 has been
used. This is useful for the server to determine the state of the used. This is useful for the server to determine the state of the
client. The use of the "flags" field is described in detail in client. The use of the "flags" field is described in detail in
Section 7. Since the client MUST use a client identifier to identify Section 7.
itself (as per [RFC4361]), the server MUST implement [RFC6842] and
use the client identifier in all DHCPv4 message exchanges with the
client.
When an appropriate DHCPv4 response is generated, the 4o6 Server When an appropriate DHCPv4 response is generated, the 4o6 Server
places it in the payload of a DHCPv4 Message option, which it puts places it in the payload of a DHCPv4 Message option, which it puts
into the DHCPv4-response message. 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,
skipping to change at page 12, line 26 skipping to change at page 12, line 30
11. Security Considerations 11. Security Considerations
In this specification, DHCPv4 messages are encapsulated in the newly In this specification, DHCPv4 messages are encapsulated in the newly
defined option and messages. This is similar to the handling of the defined option and messages. This is similar to the handling of the
current relay agent messages. In order to bypass firewalls or current relay agent messages. In order to bypass firewalls or
network authentication gateways, a malicious attacker may leverage network authentication gateways, a malicious attacker may leverage
this feature to convey other messages using DHCPv6, i.e. use DHCPv6 this feature to convey other messages using DHCPv6, i.e. use DHCPv6
as a form of encapsulation. However, the potential risk from this is as a form of encapsulation. However, the potential risk from this is
no more severe than that with the current DHCPv4 and DHCPv6 practice. no more severe than that with the current DHCPv4 and DHCPv6 practice.
It is possible for a rogue DHCPv6 server to reply with a 4o6 Server It is possible for a rogue server to reply with a 4o6 Server Address
Address Option containing duplicated IPv6 addresses, which could Option containing duplicated IPv6 addresses, which could cause an
cause an amplification attack. To avoid this, the client MUST check amplification attack. To avoid this, the client MUST check if there
if there are duplicate IPv6 addresses in a 4o6 Server Address Option are duplicate IPv6 addresses in a 4o6 Server Address Option when
when receiving one. The client MUST ignore those duplicated IPv6 receiving one. The client MUST ignore any but the first instance of
addresses. 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 and OPTION_DHCP4_O_DHCP6_SERVER from the "DHCP OPTION_DHCPV4_MSG, OPTION_DHCP4_O_DHCP6_SERVER from the "DHCP Option
Option Codes" table, and two DHCPv6 message type codes for the Codes" table, and two DHCPv6 message type codes for the DHCPV4-QUERY
DHCPV4-QUERY and DHCPV4-RESPONSE from the "DHCP Message Codes" table and DHCPV4-RESPONSE from the "DHCP Message Codes" table of the
of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Registry. Both
Registry. Both tables can be found at http://www.iana.org/ tables can be found at http://www.iana.org/assignments/
assignments/dhcpv6-parameters/dhcpv6-parameters.xml. 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 13, line 27 skipping to change at page 13, line 27
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for Time Option for Dynamic Host Configuration Protocol for
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.
[RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client
Identifier Option in DHCP Server Replies", RFC 6842,
January 2013.
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-04 (work in Messages", draft-ietf-dhc-dhcpv6-unknown-msg-05 (work in
progress), December 2013. progress), February 2014.
[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
 End of changes. 35 change blocks. 
113 lines changed or deleted 117 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/