draft-ietf-dhc-dhcpv4-over-dhcpv6-00.txt   draft-ietf-dhc-dhcpv4-over-dhcpv6-01.txt 
DHC Working Group Q. Sun DHC Working Group Q. Sun
Internet-Draft Y. Cui Internet-Draft Y. Cui
Intended status: Standards Track Tsinghua University Intended status: Standards Track Tsinghua University
Expires: October 28, 2013 M. Siodelski Expires: January 16, 2014 M. Siodelski
ISC ISC
S. Krishnan S. Krishnan
Ericsson Ericsson
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
April 26, 2013 July 15, 2013
DHCPv4 over DHCPv6 Transport DHCPv4 over DHCPv6 Transport
draft-ietf-dhc-dhcpv4-over-dhcpv6-00 draft-ietf-dhc-dhcpv4-over-dhcpv6-01
Abstract Abstract
This document describes a mechanism for obtaining IPv4 address and This document describes a mechanism for obtaining IPv4 address and
other parameters in IPv6 networks by carrying DHCPv4 messages over other parameters in IPv6 networks by carrying DHCPv4 messages over
DHCPv6 transport. DHCPv6 transport.
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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 28, 2013. This Internet-Draft will expire on January 16, 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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 4. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 3
5. BOOTP Message Option Format . . . . . . . . . . . . . . . . . 4 5. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3
6. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 6. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 5
7. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 5 6.1. BOOTP Message Option Format . . . . . . . . . . . . . . . 5
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. DHCPv4-over-DHCPv6 Enable Option Format . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6.3. 4o6 Servers Address Option Format . . . . . . . . . . . . 6
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
11. Contributors List . . . . . . . . . . . . . . . . . . . . . . 7 8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 7 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 12. Contributors List . . . . . . . . . . . . . . . . . . . . . . 9
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
13.1. Normative References . . . . . . . . . . . . . . . . . . 9
13.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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. However, IPv4 connectivity will continue to
be provided as a service over these IPv6 only networks. In addition be provided as a service over these IPv6 only networks. In addition
to providing IPv4 addresses for clients of this service, other IPv4 to providing IPv4 addresses for clients of this service, other IPv4
configuration parameters may also need to be provided, (e.g. configuration parameters may also need to be provided, (e.g.
addresses of IPv4-only services). addresses of IPv4-only services).
By conveying DHCPv4 messages over DHCPv6 transport, this mechanism By conveying DHCPv4 messages over DHCPv6 transport, this mechanism
can achieve dynamic provisioning of IPv4 address and other can achieve dynamic provisioning of IPv4 address and other
configuration parameters. In addition, it is able to leverage configuration parameters. In addition, it is able to leverage
existing infrastructure for DHCPv4, e.g. failover, DNS updates, existing infrastructure for DHCPv4, e.g. failover, DNS updates,
leasequery, etc. This mechanism is suitable for stateful allocation leasequery, etc. This mechanism is suitable for stateful allocation
and management of IPv4 addresses and configuration parameters across and management of IPv4 addresses and configuration parameters across
IPv6 networks. IPv6 networks.
Several approaches for provisioning such information have already
been proposed. This document describes alternative approach.
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:
BOOTREQUESTV6 (TBD): A new type of DHCPv6 Client/Server message DHCP client: The 'DHCP client' in this document consists of
defined in this document. A client sends a both DHCPv4 and DHCPv6 client engines. The
BOOTREQUESTV6 message to a server, which client is able to request IPv6 information
contains a BOOTP Message Option. Each BOOTP through DHCPv6, as well as to request IPv4
Message Option contains a BOOTREQUEST message information using DHCPv4-over-DHCPv6 transport.
that the client uses to request IPv4
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
used to carry DHCPv4 messages encapsulated in
DHCPv6 messages.
4. New DHCPv6 Messages
The following new DHCPv6 Client/Server messages are defined by this
document. These are formatted as specified in Section 6 of
[RFC3315].
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. configuration parameters from the server.
BOOTREPLYV6 (TBD): A new type of DHCPv6 Client/Server message BOOTREPLYV6 (TBD): A server sends a BOOTREPLYV6 message containing
defined in this document. A server sends a a BOOTP Message Option in response to a
BOOTREPLYV6 message containing a BOOTP Message client's BOOTREQUESTV6 message. The BOOTP
Option in response to a client's BOOTREQUESTV6 Message Option contains a BOOTREPLY message in
message. Each BOOTP Message Option, wrapped in response to a BOOTREQUEST received by the
a BOOTREPLYV6 message, contains a BOOTREPLY server in the BOOTP Message Option of a
message. This contains the BOOTREQUEST
response corresponding to a client's
BOOTREQUESTV6 message. BOOTREQUESTV6 message.
4. Architecture Overview 5. 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, whereby a DHCP client's uplink supports IPv6 only and the
Service Provider's network supports IPv6 and limited IPv4 services. Service Provider's network supports IPv6 and limited IPv4 services.
In this scenario, the client can only use the IPv6 network to access In this scenario, the client can only use the IPv6 network to access
IPv4 services and so it must configure IPv4 services using IPv6 as IPv4 services and so it must configure IPv4 services using IPv6 as
the underlying transport protocol. the 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
skipping to change at page 4, line 7 skipping to change at page 4, line 24
document uses the CPE as an example for describing the mechanism. document uses the CPE as an example for describing the mechanism.
This doesn't preclude end hosts from implementing the mechanism in This doesn't preclude end hosts from implementing the mechanism in
the future. the future.
This mechanism works by carrying encapsulated DHCPv4 messages over This mechanism works by carrying encapsulated DHCPv4 messages over
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 BOOTREQUESTV6,
which contains a new option called BOOTP Message Option. The format which contains a new option called BOOTP Message Option. The format
of the option is described in Section 5. The client sends all DHCPv6 of the option is described in Section 6.1.
packets, including DHCPv4 over DHCPv6 packets, to the well-known
All_DHCP_Relay_Agents_and_Servers multicast address on the DHCPv6
server port (UDP port 547).
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 server. The server is referred in this document as a directly to the 4o6 Server. The server replies with a relevant
"Unified Server" for its capability of processing regular DHCPv6 DHCPv6 packet carrying DHCPv4 response wrapped with the BOOTP Message
traffic as well as DHCPv4 packets wrapped in the BOOTP Message Option.
Option. Server replies with a relevant DHCPv6 packet carrying DHCPv4
response wrapped with the BOOTP Message Option. Clients receive a
response on UDP port 546.
_____________ _____________ _____________ _____________
/ \ / \ / \ / \
| | | | | | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| DHCP | network | DHCP | network | Unified | | 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
5. BOOTP Message Option Format The DHCPv4-over-DHCPv6 is by default disabled on the client. Before
client can use this protocol it MUST obtain configuration using
DHCPv6 as described in [RFC3315]. During this configuration, server
MAY include DHCPv4-over-DHCPv6 Enable Option in its Reply message to
indicate that client SHOULD use DHCPv4-over-DHCPv6 protocol to obtain
additional configuration. The format of the DHCPv4-over-DHCPv6
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
server is configured to do so, it MAY send unicast addresses of the
4o6 Servers to the client during client's configuration using DHCPv6.
The unicast addresses are carried in the 4o6 Server Addresses Option
encapsulated in the Reply message. The 4o6 Server Addresses Option's
format is defined in Section 6.3.
6. DHCPv6 Options
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 25 skipping to change at page 5, line 45
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 BOOTREQUESTV6 message it contains a BOOTREQUEST
message sent by client. In a BOOTREPLYV6 message it message sent by client. In a BOOTREPLYV6 message it
contains a BOOTREPLY message sent by a server in contains a BOOTREPLY message sent by a server in
response to a client. response to a client.
6. Client Behavior 6.2. DHCPv4-over-DHCPv6 Enable Option Format
When a client requires an IPv4 address and/or other IPv4 The DHCPv4-over-DHCPv6 Enable Option indicates that the client SHOULD
configuration parameters, it MUST generate a DHCPv4 message to obtain enable the DHCPv4-over-DHCPv6 function.
them from a DHCP server. This message is stored verbatim in the
BOOTP Message Option carried by the BOOTREQUESTV6 message. A Client The format of the DHCPv4-over-DHCPv6 Enable Option is:
MUST put exactly one BOOTP Message Option into a single BOOTREQUESTV6
message. The Client sends out the BOOTREQUESTV6 message to the Well- 0 1 2 3
Known multicast address, i.e. All_DHCP_Relay_Agents_and_Servers on 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
multicast address defined in [RFC3315]. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DHCP4_O_DHCP6_ENABLE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DHCPv4-over-DHCPv6 Enable Option Format
option-code OPTION_DHCP4_O_DHCP6_ENABLE (TBD)
option-len 0
6.3. 4o6 Servers Address Option Format
The 4o6 Servers Address Option carries unicast IPv6 addresses of the
4o6 Servers.
The format of the 4o6 Servers Address Option is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DHCP4_O_DHCP6_SERVERS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IPv6 Address(es) .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: 4o6 Servers Address Option Format
option-code OPTION_DHCP4_O_DHCP6_SERVERS (TBD)
option-len Length of the IPv6 address(es), i.e. integer times
of 16.
IPv6 Address The IPv6 address(es) of the 4o6 Server(s).
7. Client Behavior
The DHCP client SHOULD request the DHCPv4-over-DHCPv6 Enable Option
and the 4o6 Server Addresses Option in the Option Request Option
(ORO) to launch the DHCPv4-over-DHCPv6 function.
Client MUST NOT initiate communication with 4o6 Servers before it
obtains configuration using DHCPv6 as described in [RFC3315]. If
client supports DHCPv4-over-DHCPv6 function it SHOULD request the
DHCPv4-over-DHCPv6 Enable Option and 4o6 Server Addresses Option in
the Option Request Option (ORO). DHCPv6 server MAY include these
options in Reply message sent to the client. The client determines
how to launch the DHCPv4-over-DHCPv6 function using the presence /
absence of these two options:
o If the client doesn't receive the DHCPv4-over-DHCPv6 Enable
Option, it SHOULD NOT enable the DHCPv4 over DHCPv6 function.
o If the client receives the DHCPv4-over-DHCPv6 Enable Option but no
4o6 Servers Address Option, it SHOULD enable the DHCPv4-over-
DHCPv6 function, but use IPv6 multicast to communicate with the
servers or relays as described above.
o If the client receives both options, it SHOULD enable the DHCPv4
-over-DHCPv6 function, and send requests to all unicast addresses
conveyed by the 4o6 Server Addresses Option.
If client is instructed by the DHCPv6 server to use DHCPv4-over-
DHCPv6 function it MUST generate a DHCPv4 message to obtain
configuration from the 4o6 Server. This message is stored verbatim
in the BOOTP Message Option carried by the BOOTREQUESTV6 message.
Client MUST put exactly one BOOTP Message Option into a single
BOOTREQUESTV6 message.
If client did not receive a 4o6 Server Addresses Option from the
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 When a client receives a BOOTREPLYV6 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 BOOTREPLYV6 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.
When requesting IPv4 information, the client SHOULD follow the normal
DHCPv4 retransmission requirements and strategy as specified in
section 4.1 of [RFC2131]. As a result there are no explicit
transmission parameters associated with a BOOTPREQUESTV6 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 The IPv4 address allocated from the server MAY be assigned to a
different interface from the IPv6 interface requesting the different interface from the IPv6 interface requesting the
information. Future documents depending on this memo MUST specify information. Future documents depending on this memo MUST specify
which IPv6 interface is to be used by the client for that purpose. which IPv6 interface is to be used by the client for that purpose.
7. Relay Agent Behavior 8. Relay Agent Behavior
When a DHCPv6 relay agent receives a BOOTREQUESTV6 message, it MUST When a DHCPv6 relay agent receives a BOOTREQUESTV6 message, it MUST
handle the message as described in section 20.1.1 of [RFC3315]. handle the message as described in section 4 of
[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 a 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 BOOTREQUESTV6, then the DHCPv6 request is
relayed to the configured DHCPv4 aware unified server's relayed to the configured DHCPv4 aware 4o6 Server's address(es).
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 this document. hop). Multiple relaying hops are not considered in the case of
separate relay destinations.
8. Server Behavior 9. Server Behavior
When server receives a BOOTREQUESTV6 message from a client, it When server receives a BOOTREQUESTV6 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 Unified 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 Unified Server and a DHCPv4 server engine is out of scope between the 4o6 Server and a DHCPv4 server engine is out of scope for
for this document. this document.
When appropriate DHCPv4 respose is generated, Unified Server places When appropriate DHCPv4 response is generated, 4o6 Server places it
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. BOOTREPLYV6 message.
If the BOOTREQUESTV6 message was received directly by the server, the If the BOOTREQUESTV6 message was received directly by the server, the
BOOTREPLYV6 message MUST be unicast from the interface on which the BOOTREPLYV6 message MUST be unicast from the interface on which the
original message was received. original message was received.
If the BOOTREQUESTV6 message was received in a Relay-forward message, If the BOOTREQUESTV6 message was received in a Relay-forward message,
the server creates a Relay-reply message with the BOOTREPLYV6 message the server creates a Relay-reply message with the BOOTREPLYV6 message
in the payload of a Relay Message Option. This is analogous to other in the payload of a Relay Message Option, and responds as described
types of DHCPv6 messages as described in [RFC3315]. The server in section 20.3 of [RFC3315].
unicasts the Relay-reply message directly to the IP address of the
relay agent from which the Relay-forward message was received.
9. Security Considerations 10. 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 handling the current
relay agent messages. In order to bypass firewalls or network relay agent messages. In order to bypass firewalls or network
authentication gateways, a malicious attacker may leverage this authentication gateways, a malicious attacker may leverage this
feature to convey other messages using DHCPv6, i.e. use DHCPv6 as a feature to convey other messages using DHCPv6, i.e. use DHCPv6 as a
form of encapsulation. However, the potential risk from this is no form of encapsulation. However, the potential risk from this is no
greater than that with current DHCPv4 and DHCPv6 practice. greater than that with current DHCPv4 and DHCPv6 practice.
10. IANA Considerations 11. IANA Considerations
IANA is kindly requested to allocate one DHCPv6 option code to the IANA is kindly requested to allocate three DHCPv6 option codes to the
OPTION_BOOTP_MSG and two DHCPv6 message type codes to the OPTION_BOOTP_MSG, OPTION_DHCP4_O_DHCP6_ENABLE and
BOOTREQUESTV6 and BOOTREPLYV6. OPTION_DHCP4_O_DHCP6_SERVERS, and two DHCPv6 message type codes to
the BOOTREQUESTV6 and BOOTREPLYV6.
11. Contributors List 12. 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.
12. References 13. References
12.1. Normative References 13.1. Normative References
[I-D.ietf-dhc-dhcpv6-unknown-msg]
Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
Messages", draft-ietf-dhc-dhcpv6-unknown-msg-01 (work in
progress), June 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.
12.2. Informative References 13.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-06 (work in
progress), March 2013. progress), March 2013.
Authors' Addresses Authors' Addresses
Qi Sun Qi Sun
Tsinghua University Tsinghua University
 End of changes. 35 change blocks. 
82 lines changed or deleted 196 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/