draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt   draft-ietf-dhc-dhcpv4-over-dhcpv6-02.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: January 16, 2014 M. Siodelski Expires: April 21, 2014 M. Siodelski
ISC ISC
S. Krishnan S. Krishnan
Ericsson Ericsson
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
July 15, 2013 October 18, 2013
DHCPv4 over DHCPv6 Transport DHCPv4 over DHCPv6 Transport
draft-ietf-dhc-dhcpv4-over-dhcpv6-01 draft-ietf-dhc-dhcpv4-over-dhcpv6-02
Abstract Abstract
This document describes a mechanism for obtaining IPv4 address and IPv4 connectivity is still needed as networks migrate towards IPv6.
other parameters in IPv6 networks by carrying DHCPv4 messages over Users require IPv4 configuration even if the uplink to their service
DHCPv6 transport. provider supports IPv6 only. This document describes a mechanism for
obtaining IPv4 configuration information dynamically in IPv6 networks
by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6
messages as well as a new DHCPv6 option are defined for the purpose
of conveying DHCPv4 messages through IPv6 networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 16, 2014. This Internet-Draft will expire on April 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 3 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3
5. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5
6. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 5
6.1. BOOTP Message Option Format . . . . . . . . . . . . . . . 5 5.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 5
6.2. DHCPv4-over-DHCPv6 Enable Option Format . . . . . . . . . 5 5.3. Boot-request-v6 Message Flags . . . . . . . . . . . . . . 6
6.3. 4o6 Servers Address Option Format . . . . . . . . . . . . 6 5.4. Boot-reply-v6 Message Flags . . . . . . . . . . . . . . . 6
7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 6. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 6
8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 8 6.1. BOOTP Message Option Format . . . . . . . . . . . . . . . 6
9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. DHCPv4-over-DHCPv6 Enable Option Format . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6.3. 4o6 Servers Address Option Format . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Use of the Boot-request-v6 Unicast Flag . . . . . . . . . . . 8
12. Contributors List . . . . . . . . . . . . . . . . . . . . . . 9 8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 9
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 9 10. 4o6 Server Behavior . . . . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 11
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
14.1. Normative References . . . . . . . . . . . . . . . . . . 12
14.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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. However, IPv4 connectivity will continue to become more prevalent. At the same time, IPv4 connectivity will
be provided as a service over these IPv6 only networks. In addition continue to be provided as a service over IPv6-only networks. In
to providing IPv4 addresses for clients of this service, other IPv4 addition to providing IPv4 addresses for clients of this service,
configuration parameters may also need to be provided, (e.g. other IPv4 configuration parameters may also need to be provided
addresses of IPv4-only services). (e.g. addresses of IPv4-only services).
By conveying DHCPv4 messages over DHCPv6 transport, this mechanism By conveying DHCPv4 messages over DHCPv6 transport, this document
can achieve dynamic provisioning of IPv4 address and other describes a mechanism for the dynamic provisioning of IPv4 addresses
configuration parameters. In addition, it is able to leverage and other configuration parameters. The mechanism leverages existing
existing infrastructure for DHCPv4, e.g. failover, DNS updates, infrastructure for DHCPv4, e.g. failover, DNS updates, leasequery,
leasequery, etc. This mechanism is suitable for stateful allocation etc. This mechanism is suitable for stateful allocation and
and management of IPv4 addresses and configuration parameters across management of IPv4 addresses (dynamic leasing) and other IPv4
IPv6 networks. configuration parameters across IPv6-only networks.
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 client: The 'DHCP client' in this document consists of
both DHCPv4 and DHCPv6 client engines. The
client is able to request IPv6 information
through DHCPv6, as well as to request IPv4
information using DHCPv4-over-DHCPv6 transport.
4o6 Server: A DHCP server capable of processing DHCPv4
packets wrapped in the BOOTP Message Option
(defined below).
DHCPv4-over-DHCPv6: A protocol described in this document, which is DHCPv4-over-DHCPv6: A protocol described in this document, which is
used to carry DHCPv4 messages encapsulated in used to carry DHCPv4 messages encapsulated in
DHCPv6 messages. DHCPv6 messages.
4. New DHCPv6 Messages DHCP client: The 'DHCP client' in this document consists of
both DHCPv4 and DHCPv6 client engines. The
The following new DHCPv6 Client/Server messages are defined by this client is able to request IPv6 configuration
document. These are formatted as specified in Section 6 of information through DHCPv6, as well as to
[RFC3315]. request IPv4 configuration information using
DHCPv4-over-DHCPv6 transport.
BOOTREQUESTV6 (TBD): A client sends a BOOTREQUESTV6 message to a
server, which contains a BOOTP Message Option.
The BOOTP Message Option contains a BOOTREQUEST
message that the client uses to request IPv4
configuration parameters from the server.
BOOTREPLYV6 (TBD): A server sends a BOOTREPLYV6 message containing 4o6 Server: A DHCP server capable of processing DHCPv4
a BOOTP Message Option in response to a packets wrapped in the DHCPv6 option: BOOTP
client's BOOTREQUESTV6 message. The BOOTP Message Option (defined below).
Message Option contains a BOOTREPLY message in
response to a BOOTREQUEST received by the
server in the BOOTP Message Option of a
BOOTREQUESTV6 message.
5. Architecture Overview 4. Architecture Overview
The architecture described in this document addresses a typical use The architecture described in this document addresses a typical use
case, whereby a DHCP client's uplink supports IPv6 only and the case, where a DHCP client's uplink supports IPv6 only and the Service
Service Provider's network supports IPv6 and limited IPv4 services. Provider's network supports IPv6 and limited IPv4 services. In this
In this scenario, the client can only use the IPv6 network to access scenario, the client can only use the IPv6 network to access IPv4
IPv4 services and so it must configure IPv4 services using IPv6 as services and so it must configure IPv4 services using IPv6 as the
the underlying transport protocol. underlying transport 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 DHCPv4 client and DHCPv4 server, the mechanism communication between DHCPv4 client and DHCPv4 server, the mechanism
it describes does not restrict the transported types of messages to that it describes does not restrict the transported messages types
DHCPv4. BOOTP messages can be transported using the same mechanism. only to DHCPv4. BOOTP messages can be transported using the same
mechanism.
DHCP clients can be running on CPE devices, end hosts or any other DHCP clients can be running on CPE devices, end hosts or any other
device which supports the DHCP client function. At the time of device which supports the DHCP client function. At the time of
writing, DHCP clients on CPE devices are relatively easier to modify writing, DHCP clients on CPE devices are easier to modify compared to
compared to those implemented on end hosts. As a result, this those implemented on end hosts. As a result, this document uses the
document uses the CPE as an example for describing the mechanism. CPE as an example for describing the mechanism. This does not
This doesn't preclude end hosts from implementing the mechanism in preclude any end-host, or other device requiring IPv4 configuration,
the future. from implementing the mechanism in the future.
This mechanism works by carrying encapsulated DHCPv4 messages over 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 client implements a new DHCPv6 message called BOOTREQUESTV6, The DHCP client implements a new DHCPv6 message called Boot-
which contains a new option called BOOTP Message Option. The format request-v6, which contains a new option called BOOTP Message Option.
of the option is described in Section 6.1. The format of this option is described in Section 6.1.
The DHCPv6 packet can be transmitted either via Relay Agents or The DHCPv6 packet can be transmitted either via Relay Agents or
directly to the 4o6 Server. The server replies with a relevant directly to the 4o6 Server. The server replies with a DHCPv6
DHCPv6 packet carrying DHCPv4 response wrapped with the BOOTP Message response, which is a new DHCPv6 message called Boot-reply-v6. This
message carries DHCPv4 response wrapped with the BOOTP Message
Option. Option.
_____________ _____________ _____________ _____________
/ \ / \ / \ / \
| | | | | | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| DHCP | network | DHCP | network | 4o6 | | DHCP | network | DHCP | network | 4o6 |
| Client +---------+ Relay Agent +---------+ Server | | Client +---------+ Relay Agent +---------+ Server |
| (on CPE) | | | | | | (on CPE) | | | | |
+--------+-+ +-+-----------+-+ +-+--------+ +--------+-+ +-+-----------+-+ +-+--------+
| | | | | | | |
\_____________/ \_____________/ \_____________/ \_____________/
Figure 1: Architecture Overview Figure 1: Architecture Overview
The DHCPv4-over-DHCPv6 is by default disabled on the client. Before By default, the DHCPv4-over-DHCPv6 is disabled on the client. Before
client can use this protocol it MUST obtain configuration using a client can use this protocol it MUST obtain the necessary IPv6
DHCPv6 as described in [RFC3315]. During this configuration, server configuration. If the client is configured to use DHCPv6 to obtain
MAY include DHCPv4-over-DHCPv6 Enable Option in its Reply message to its IPv6 configuration, the DHCPv6 server MAY include the DHCPv4
indicate that client SHOULD use DHCPv4-over-DHCPv6 protocol to obtain -over-DHCPv6 Enable Option in its Reply message to indicate that
client SHOULD use the DHCPv4-over-DHCPv6 protocol to obtain
additional configuration. The format of the DHCPv4-over-DHCPv6 additional configuration. The format of the DHCPv4-over-DHCPv6
Enable Option is described in Section 6.2 Enable Option is described in Section 6.2.
Typically, client communicates with the 4o6 Servers using well known
All_DHCP_Relay_Agents_and_Servers multicast address. If DHCPv6 Typically, a client communicates with the 4o6 Servers using well
server is configured to do so, it MAY send unicast addresses of the known All_DHCP_Relay_Agents_and_Servers multicast address. If a
4o6 Servers to the client during client's configuration using DHCPv6. DHCPv6 server is configured to do so, it MAY send unicast addresses
The unicast addresses are carried in the 4o6 Server Addresses Option of the 4o6 Servers to the client during the client's configuration
encapsulated in the Reply message. The 4o6 Server Addresses Option's using DHCPv6. The unicast addresses are carried in the 4o6 Server
format is defined in Section 6.3. Addresses Option encapsulated in the Reply message. The 4o6 Server
Addresses Option's format is defined in Section 6.3.
5. New DHCPv6 Messages
There are two new DHCPv6 messages defined in this document which
carry DHCPv4 messages between a client and a server using DHCPv6
protocol: Boot-request-v6 and Boot-reply-v6. This section describes
structures of these messages.
5.1. Message Types
The following new message types are defined in this document:
BOOTREQUESTV6 (TBD): Identifies a Boot-request-v6 message. A client
sends this message to a server. The BOOTP
Message Option carried by this message contains
a BOOTREQUEST message that the client uses to
request IPv4 configuration parameters from the
server.
BOOTREPLYV6 (TBD): Identifies a Boot-reply-v6 message. A server
sends this message to a client. It contains a
BOOTP Message Option carrying a BOOTREPLY
message in response to a BOOTREQUEST received
by the server in the BOOTP Message Option of
the Boot-request-v6 message.
5.2. Message Formats
Both DHCPv6 messages defined in this document share the following
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Architecture Overview
msg-type Identifies message type. It can be either
BOOTREQUESTV6 (TBD) or BOOTREPLYV6 (TBD) which
corresponds to the Boot-request-v6 or Boot-reply-v6
respectively.
flags Specifies flags which provide additional information
required by the server to process a DHCPv4 message
wrapped in Boot-request-v6 Message, or required by
the client to process DHCPv4 message wrapped in Boot-
reply-v6 Message.
options Options carried by the message and described in
Section 6.
5.3. Boot-request-v6 Message Flags
The "flags" field of the Boot-request-v6 is used to carry additional
information which may be used by the server to process the
encapsulated DHCPv4 message. Currently only one bit of this field is
used. Remaining bits are reserved for the future use. Currently the
"flags" field has the following format:
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 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Boot-request-v6 flags format
U Unicast Flag. If it is set to 1, it indicates that
the DHCPv4 message encapsulated with the Boot-
request-v6 message would be sent to a unicast address
if it was sent using IPv4. If this flag is set to 0
it indicates that the DHCPv4 message would be sent to
broadcast address if it was sent using IPv4.
Reserved Bits reserved for future use. A client which doesn't
implement future extensions using these bits MUST set
them to 0.
5.4. Boot-reply-v6 Message Flags
This document introduces no flags to be carried in the "flags" field
of the Boot-reply-v6 message. They are all reserved for the future
use. Server MUST set all bits of this field to 0.
6. DHCPv6 Options 6. DHCPv6 Options
6.1. BOOTP Message Option Format 6.1. BOOTP Message Option Format
The BOOTP Message option carries a BOOTP message that is sent by the The BOOTP Message option carries a BOOTP message that is sent by the
client or the server. Such BOOTP messages exclude any IP or UDP client or the server. Such BOOTP messages exclude any IP or UDP
headers. headers.
The format of the BOOTP Message Option is: The format of the BOOTP Message 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_BOOTP_MSG | option-len | | OPTION_BOOTP_MSG | option-len |
skipping to change at page 5, line 33 skipping to change at page 7, line 21
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_BOOTP_MSG | option-len | | OPTION_BOOTP_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. BOOTP-message . . BOOTP-message .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: BOOTP Message Option Format Figure 4: BOOTP Message Option Format
option-code OPTION_BOOTP_MSG (TBD) option-code OPTION_BOOTP_MSG (TBD)
option-len Length of BOOTP message option-len Length of BOOTP message
BOOTP-message The BOOTP message sent by the client or the server. BOOTP-message The BOOTP message sent by the client or the server.
In a BOOTREQUESTV6 message it contains a BOOTREQUEST In a Boot-request-v6 message it contains a
message sent by client. In a BOOTREPLYV6 message it BOOTREQUEST message sent by a client. In a Boot-
contains a BOOTREPLY message sent by a server in reply-v6 message it contains a BOOTREPLY message sent
response to a client. by a server in response to a client.
6.2. DHCPv4-over-DHCPv6 Enable Option Format 6.2. DHCPv4-over-DHCPv6 Enable Option Format
The DHCPv4-over-DHCPv6 Enable Option indicates that the client SHOULD The DHCPv4-over-DHCPv6 Enable Option indicates that the client SHOULD
enable the DHCPv4-over-DHCPv6 function. enable the DHCPv4-over-DHCPv6 function.
The format of the DHCPv4-over-DHCPv6 Enable Option is: The format of the DHCPv4-over-DHCPv6 Enable 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_ENABLE | option-len | | OPTION_DHCP4_O_DHCP6_ENABLE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DHCPv4-over-DHCPv6 Enable Option Format Figure 5: DHCPv4-over-DHCPv6 Enable Option Format
option-code OPTION_DHCP4_O_DHCP6_ENABLE (TBD) option-code OPTION_DHCP4_O_DHCP6_ENABLE (TBD)
option-len 0 option-len 0
6.3. 4o6 Servers Address Option Format 6.3. 4o6 Servers Address Option Format
The 4o6 Servers Address Option carries unicast IPv6 addresses of the The 4o6 Servers Address Option carries unicast IPv6 addresses of the
4o6 Servers. 4o6 Servers.
The format of the 4o6 Servers Address Option is: The format of the 4o6 Servers Address Option is:
0 1 2 3 0 1 2 3
skipping to change at page 6, line 35 skipping to change at page 8, line 24
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_SERVERS | option-len | | OPTION_DHCP4_O_DHCP6_SERVERS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. IPv6 Address(es) . . IPv6 Address(es) .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: 4o6 Servers Address Option Format Figure 6: 4o6 Servers Address Option Format
option-code OPTION_DHCP4_O_DHCP6_SERVERS (TBD) option-code OPTION_DHCP4_O_DHCP6_SERVERS (TBD)
option-len Length of the IPv6 address(es), i.e. integer times option-len Length of the IPv6 address(es), i.e. integer times
of 16. of 16.
IPv6 Address The IPv6 address(es) of the 4o6 Server(s). IPv6 Address The IPv6 address(es) of the 4o6 Server(s).
7. Client Behavior 7. Use of the Boot-request-v6 Unicast Flag
The DHCP client SHOULD request the DHCPv4-over-DHCPv6 Enable Option A DHCPv4 client conforming to the [RFC2131] may send its DHCPREQUEST
and the 4o6 Server Addresses Option in the Option Request Option message to either broadcast or unicast address depending on its
(ORO) to launch the DHCPv4-over-DHCPv6 function. state. For example, the client in the RENEWING state will use a
unicast address to contact a server and renew its lease. The client
in the REBINDING state MUST use a broadcast address. If there is 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
such case the server can't find out whether client sent a message to
a unicast or broadcast address and thus it can't determine the
client's state. [RFC5010] introduced the "Flags Suboption" which
relay agents add to relayed messages to indicate whether broadcast or
unicast was used by the client.
Client MUST NOT initiate communication with 4o6 Servers before it The DHCPv4-over-DHCPv6 protocol uses IPv6 to deliver DHCPv4 messages
obtains configuration using DHCPv6 as described in [RFC3315]. If to the server. There is no relation between the outer IPv6 address
client supports DHCPv4-over-DHCPv6 function it SHOULD request the and the inner DHCPv4 message. So the server is not able to know
DHCPv4-over-DHCPv6 Enable Option and 4o6 Server Addresses Option in whether the DHCPv4 messages should have been sent using broadcast or
the Option Request Option (ORO). DHCPv6 server MAY include these unicast in IPv4 by checking the IPv6 address. This is similar to the
options in Reply message sent to the client. The client determines case [RFC5010] handled.
how to launch the DHCPv4-over-DHCPv6 function using the presence /
absence of these two options: In order to allow the server to determine the client's state, the
"Unicast" flag is carried in the Boot-request-v6 message. Client
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
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
be sent to a broadcast or unicast address MUST be made based on the
[RFC2131] and its extensions.
8. Client Behavior
The DHCP client by default doesn't use DHCPv4-over-DHCPv6 protocol to
obtain its DHCPv4 configuration. Client MUST obtain its IPv6
configuration before it MAY use DHCPv4-over-DHCPv6 to obtain DHCPv4
configuration. If IPv6 configuration is obtained using DHCPv6 as
described in [RFC3315], client SHOULD request the DHCPv4-over-DHCPv6
Enable Option and the 4o6 Server Addresses Option in the Option
Request Option (ORO) to check if it SHOULD use DHCPv4-over-DHCPv6.
The DHCPv6 server MAY include these options in the Reply message sent
to the client. The client determines how to launch the DHCPv4-over-
DHCPv6 function based on the presence / absence of these two options:
o If the client doesn't receive the DHCPv4-over-DHCPv6 Enable o If the client doesn't receive the DHCPv4-over-DHCPv6 Enable
Option, it SHOULD NOT enable the DHCPv4 over DHCPv6 function. Option, it SHOULD NOT enable the DHCPv4 over DHCPv6 function.
o If the client receives the DHCPv4-over-DHCPv6 Enable Option but no o If the client receives the DHCPv4-over-DHCPv6 Enable Option but no
4o6 Servers Address Option, it SHOULD enable the DHCPv4-over- 4o6 Servers Address Option, it SHOULD enable the DHCPv4-over-
DHCPv6 function, but use IPv6 multicast to communicate with the DHCPv6 function, but use IPv6 All_DHCP_Relay_Agents_and_Servers
servers or relays as described above. multicast address to communicate with the servers or relays as
described above.
o If the client receives both options, it SHOULD enable the DHCPv4 o If the client receives both options, it SHOULD enable the DHCPv4
-over-DHCPv6 function, and send requests to all unicast addresses -over-DHCPv6 function, and send requests to all unicast addresses
conveyed by the 4o6 Server Addresses Option. conveyed by the 4o6 Server Addresses Option.
If client is instructed by the DHCPv6 server to use DHCPv4-over- If the client is instructed by the DHCPv6 server to use DHCPv4-over-
DHCPv6 function it MUST generate a DHCPv4 message to obtain DHCPv6 function it SHOULD generate a DHCPv4 message to obtain
configuration from the 4o6 Server. This message is stored verbatim configuration from the 4o6 Server. This message is stored verbatim
in the BOOTP Message Option carried by the BOOTREQUESTV6 message. in the BOOTP Message Option carried by the Boot-request-v6 message.
Client MUST put exactly one BOOTP Message Option into a single The client MUST put exactly one BOOTP Message Option into a single
BOOTREQUESTV6 message. Boot-request-v6 message.
If client did not receive a 4o6 Server Addresses Option from the A client MUST set the Unicast flag as specified in Section 7.
DHCPv6 server, it transmits the BOOTREQUESTV6 message as specified in
Section 13 of [RFC3315]. If client received this option it MUST send
BOOTREQUESTV6 message to all unicast addresses listed in the received
option.
When a client receives a BOOTREPLYV6 message, it MUST look for the If the client has not received a 4o6 Server Addresses Option from the
DHCPv6 server, it transmits the Boot-request-v6 message as specified
in Section 13 of [RFC3315]. If the client received this option, it
MUST send Boot-request-v6 message to all unicast addresses listed in
the received option.
When a client receives a Boot-reply-v6 message, it MUST look for the
BOOTP Message Option within this message. If this option is not BOOTP Message Option within this message. If this option is not
found, the BOOTREPLYV6 message is discarded. If the BOOTP Message found, the Boot-reply-v6 message is discarded. If the BOOTP Message
Option is found, the client extracts the DHCPv4 message it contains Option is found, the client extracts the DHCPv4 message it contains
and processes it as described in section 4.4 of [RFC2131]. and processes it as described in section 4.4 of [RFC2131].
DHCP clients are responsible for the retransmission of messages. DHCP clients are responsible for the retransmission of messages.
When requesting IPv4 information, the client SHOULD follow the normal When requesting IPv4 configuration, the client SHOULD follow the
DHCPv4 retransmission requirements and strategy as specified in normal DHCPv4 retransmission requirements and strategy as specified
section 4.1 of [RFC2131]. As a result there are no explicit in section 4.1 of [RFC2131]. As a result there are no explicit
transmission parameters associated with a BOOTPREQUESTV6 message. transmission parameters associated with a Boot-request-v6 message.
As the DHCPv4 and DHCPv6 clients are running on the same host, the As the DHCPv4 and DHCPv6 clients are running on the same host, the
client MUST implement [RFC4361] to ensure that the device correctly client MUST implement [RFC4361] to ensure that the device correctly
identifies itself. identifies itself.
The IPv4 address allocated from the server MAY be assigned to a 9. Relay Agent Behavior
different interface from the IPv6 interface requesting the
information. Future documents depending on this memo MUST specify
which IPv6 interface is to be used by the client for that purpose.
8. Relay Agent Behavior
When a DHCPv6 relay agent receives a BOOTREQUESTV6 message, it MUST When a DHCPv6 relay agent receives a Boot-request-v6 message, it MUST
handle the message as described in section 4 of handle the message as described in section 4 of
[I-D.ietf-dhc-dhcpv6-unknown-msg]. [I-D.ietf-dhc-dhcpv6-unknown-msg].
A DHCPv6 relay agent MUST implement the Relay behaviour described in A DHCPv6 relay agent MUST implement the Relay behaviour described in
section 20.1.1 of [RFC3315]. section 20.1.1 of [RFC3315].
Additionally, the DHCPv6 relay agent MAY allow the configuration of Additionally, the DHCPv6 relay agent MAY allow the configuration of
dedicated DHCPv4 over DHCPv6 specific destination addresses, dedicated DHCPv4-over-DHCPv6 specific destination addresses,
differing from the addresses of the DHCPv6 only server(s). To differing from the addresses of the DHCPv6 only server(s). To
implement this function, the relay checks the received DHCPv6 message implement this function, the relay checks the received DHCPv6 message
type and forwards according to the following logic: type and forwards according to the following logic:
1. If the message type is BOOTREQUESTV6, then the DHCPv6 request is 1. If the message type is Boot-request-v6, then the DHCPv6 request
relayed to the configured DHCPv4 aware 4o6 Server's address(es). is relayed to the configured DHCPv4 aware 4o6 Server's
address(es).
2. For any other DHCPv6 message type, forward according to section 2. For any other DHCPv6 message type, forward according to section
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.
9. Server Behavior 10. 4o6 Server Behavior
When server receives a BOOTREQUESTV6 message from a client, it When the server receives a Boot-request-v6 message from a client, it
searches for a BOOTP Message Option. If this option is missing, the searches for a BOOTP Message Option. If this option is missing, the
server discards the packet. The server MAY notify an administrator server discards the packet. 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 BOOTP Message Option, it extracts the If the server finds a valid BOOTP Message Option, it extracts the
original DHCPv4 message sent by the client. This message is passed original DHCPv4 message sent by the client. This message is passed
to the DHCPv4 server engine, which generates a response to the client to the DHCPv4 server engine, which generates a response to the client
as specified in [RFC2131]. This engine can be implemented as a as specified in [RFC2131]. This engine can be implemented as a
built-in DHCPv4 server function of the 4o6 Server, or it can be a built-in DHCPv4 server function of the 4o6 Server, or it can be a
separate DHCPv4 server instance. Discussion regarding communication separate DHCPv4 server instance. Discussion regarding communication
between the 4o6 Server and a DHCPv4 server engine is out of scope for between the 4o6 Server and a DHCPv4 server engine is out of scope for
this document. this document.
When appropriate DHCPv4 response is generated, 4o6 Server places it When appropriate DHCPv4 response is generated, 4o6 Server places it
in the payload of a BOOTP Message Option, which it puts into the in the payload of a BOOTP Message Option, which it puts into the
BOOTREPLYV6 message. Boot-reply-v6 message.
If the BOOTREQUESTV6 message was received directly by the server, the If the Boot-request-v6 message was received directly by the server,
BOOTREPLYV6 message MUST be unicast from the interface on which the the Boot-reply-v6 message MUST be unicast from the interface on which
original message was received. the original message was received.
If the BOOTREQUESTV6 message was received in a Relay-forward message, If the Boot-request-v6 message was received in a Relay-forward
the server creates a Relay-reply message with the BOOTREPLYV6 message message, the server creates a Relay-reply message with the Boot-
in the payload of a Relay Message Option, and responds as described reply-v6 message in the payload of a Relay Message Option, and
in section 20.3 of [RFC3315]. responds as described in section 20.3 of [RFC3315].
10. 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 handling the current defined option and messages. This is similar to the handling of the
relay agent messages. In order to bypass firewalls or network current relay agent messages. In order to bypass firewalls or
authentication gateways, a malicious attacker may leverage this network authentication gateways, a malicious attacker may leverage
feature to convey other messages using DHCPv6, i.e. use DHCPv6 as a this feature to convey other messages using DHCPv6, i.e. use DHCPv6
form of encapsulation. However, the potential risk from this is no as a form of encapsulation. However, the potential risk from this is
greater than that with current DHCPv4 and DHCPv6 practice. not seen to be greater than that with current DHCPv4 and DHCPv6
practice.
11. IANA Considerations 12. IANA Considerations
IANA is kindly requested to allocate three DHCPv6 option codes to the IANA is requested to allocate three DHCPv6 option codes for use by
OPTION_BOOTP_MSG, OPTION_DHCP4_O_DHCP6_ENABLE and OPTION_BOOTP_MSG, OPTION_DHCP4_O_DHCP6_ENABLE and
OPTION_DHCP4_O_DHCP6_SERVERS, and two DHCPv6 message type codes to OPTION_DHCP4_O_DHCP6_SERVERS, and two DHCPv6 message type codes for
the BOOTREQUESTV6 and BOOTREPLYV6. the BOOTREQUESTV6 and BOOTREPLYV6.
12. 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.
13. References 14. References
13.1. Normative References 14.1. Normative 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-01 (work in Messages", draft-ietf-dhc-dhcpv6-unknown-msg-02 (work in
progress), June 2013. progress), September 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[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.
13.2. Informative References 14.2. Informative References
[I-D.ietf-dhc-dhcpv4-over-ipv6] [I-D.ietf-dhc-dhcpv4-over-ipv6]
Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
Transport", draft-ietf-dhc-dhcpv4-over-ipv6-06 (work in Transport", draft-ietf-dhc-dhcpv4-over-ipv6-07 (work in
progress), March 2013. progress), September 2013.
Authors' Addresses [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
Qi Sun Qi Sun
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, 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
Yong Cui Yong Cui
 End of changes. 59 change blocks. 
175 lines changed or deleted 290 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/