One document matched: draft-ietf-dhc-dhcpv4-over-dhcpv6-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc autobreaks="no"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2131 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc4361 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4361.xml">
]>
<rfc category="std" docName="draft-ietf-dhc-dhcpv4-over-dhcpv6-01" ipr="trust200902">
<front>
<title abbrev="DHCPv4 over DHCPv6">DHCPv4 over DHCPv6 Transport</title>
<author fullname="Qi Sun" initials="Q." surname="Sun">
<organization>Tsinghua University</organization>
<address>
<postal>
<street>Department of Computer Science, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6278-5822</phone>
<email>sunqi@csnet1.cs.tsinghua.edu.cn</email>
</address>
</author>
<author fullname="Yong Cui" initials="Y." surname="Cui">
<organization>Tsinghua University</organization>
<address>
<postal>
<street>Department of Computer Science, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6260-3059</phone>
<email>yong@csnet1.cs.tsinghua.edu.cn</email>
</address>
</author>
<author fullname="Marcin Siodelski" initials="M." surname="Siodelski">
<organization abbrev="ISC"></organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>USA</country>
</postal>
<phone>+1 650 423 1431</phone>
<email>msiodelski@gmail.com</email>
</address>
</author>
<author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
<organization>Ericsson</organization>
<address>
<email>suresh.krishnan@ericsson.com</email>
</address>
</author>
<author fullname="Ian Farrer" initials="I." surname="Farrer">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>GTN-FM4,Landgrabenweg 151</street>
<city>Bonn</city>
<region>NRW</region>
<code>53227</code>
<country>Germany</country>
</postal>
<email>ian.farrer@telekom.de</email>
</address>
</author>
<date year="2013"/>
<workgroup>DHC Working Group</workgroup>
<abstract>
<t>This document describes a mechanism for obtaining IPv4 address
and other parameters in IPv6 networks by carrying DHCPv4 messages
over DHCPv6 transport.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As the migration towards IPv6 continues, IPv6 only networks
will become more prevalent. However, IPv4 connectivity will continue
to be provided as a service over these IPv6 only networks. In addition
to providing IPv4 addresses for clients of this service, other
IPv4 configuration parameters may also need to be provided, (e.g.
addresses of IPv4-only services).</t>
<t>By conveying DHCPv4 messages over DHCPv6 transport, this mechanism
can achieve dynamic provisioning of IPv4 address and other configuration parameters.
In addition, it is able to leverage existing infrastructure for DHCPv4,
e.g. failover, DNS updates, leasequery, etc. This mechanism is suitable
for stateful allocation and management of IPv4 addresses and configuration
parameters across IPv6 networks. </t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:
<list hangIndent="22" style="hanging">
<t hangText="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.</t>
<t hangText="4o6 Server:">A DHCP server capable of processing DHCPv4 packets
wrapped in the BOOTP Message Option (defined below).
</t>
<t hangText="DHCPv4-over-DHCPv6:">A protocol described in this document, which
is used to carry DHCPv4 messages encapsulated in DHCPv6 messages.</t>
</list>
</t>
</section>
<section title="New DHCPv6 Messages">
<t>The following new DHCPv6 Client/Server messages are defined by this document.
These are formatted as specified in Section 6 of <xref target="RFC3315"/>.
<list hangIndent="22" style="hanging">
<t hangText="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.</t>
<t hangText="BOOTREPLYV6 (TBD):">A server sends a BOOTREPLYV6 message
containing a BOOTP Message Option in response to a client's BOOTREQUESTV6 message.
The BOOTP Message Option contains a BOOTREPLY message in response to a BOOTREQUEST
received by the server in the BOOTP Message Option of a BOOTREQUESTV6 message.
</t>
</list>
</t>
</section>
<section title="Architecture Overview">
<t>The architecture described in this document addresses a typical
use case, whereby a DHCP client's uplink supports IPv6 only and the
Service Provider's network supports IPv6 and limited IPv4 services.
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 the
underlying transport protocol.</t>
<t>Although the purpose of this document is to address the problem of
communication between DHCPv4 client and DHCPv4 server, the mechanism
it describes does not restrict the transported types of messages to
DHCPv4. BOOTP messages can be transported using the same mechanism.</t>
<t>DHCP clients can be running on CPE devices, end hosts or any other device
which supports the DHCP client function. At the time of writing, DHCP
clients on CPE devices are relatively easier to modify compared to those
implemented on end hosts. As a result, this document uses the CPE as an
example for describing the mechanism. This doesn't preclude end hosts
from implementing the mechanism in the future.
</t>
<t>This mechanism works by carrying encapsulated DHCPv4 messages over
DHCPv6 messages. <xref target="architecture-overview"/>, below,
illustrates one possible deployment architecture.</t>
<!-- Removed pieces of text talking about multicast addresses because
extended dicussion regarding multi and unicast is further in this
section-->
<t>The DHCP client implements a new DHCPv6 message called BOOTREQUESTV6,
which contains a new option called BOOTP Message Option. The format
of the option is described in <xref target="bootp-message-option"/>.
</t>
<t>The DHCPv6 packet can be transmitted either via Relay Agents or
directly to the 4o6 Server. The server replies with a relevant
DHCPv6 packet carrying DHCPv4 response wrapped with the BOOTP Message Option.
</t>
<figure align="center" anchor="architecture-overview"
title="Architecture Overview">
<artwork><![CDATA[
_____________ _____________
/ \ / \
| | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| DHCP | network | DHCP | network | 4o6 |
| Client +---------+ Relay Agent +---------+ Server |
| (on CPE) | | | | |
+--------+-+ +-+-----------+-+ +-+--------+
| | | |
\_____________/ \_____________/
]]></artwork>
</figure>
<t>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 <xref target="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
<xref target="dhcp4o6-enable-option"/></t>
<t>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 <xref target="dhcp4o6-server-addr-option"/>.</t>
</section>
<section title="DHCPv6 Options">
<section title="BOOTP Message Option Format" anchor="bootp-message-option">
<t>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 headers. </t>
<t>The format of the BOOTP Message Option is: </t>
<figure align="center" anchor="option-bootp-msg"
title="BOOTP Message Option Format">
<artwork><![CDATA[
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_BOOTP_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. BOOTP-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list hangIndent="16" style="hanging">
<t hangText="option-code">OPTION_BOOTP_MSG (TBD)</t>
<t hangText="option-len">Length of BOOTP message</t>
<t hangText="BOOTP-message">The BOOTP message sent by the client
or the server. In a BOOTREQUESTV6 message it contains
a BOOTREQUEST message sent by client. In a BOOTREPLYV6
message it contains a BOOTREPLY message sent by a
server in response to a client.</t>
</list>
</t>
</section>
<section title="DHCPv4-over-DHCPv6 Enable Option Format"
anchor="dhcp4o6-enable-option">
<t>The DHCPv4-over-DHCPv6 Enable Option indicates that the client
SHOULD enable the DHCPv4-over-DHCPv6 function.</t>
<t>The format of the DHCPv4-over-DHCPv6 Enable Option is: </t>
<figure align="center" anchor="option-dhcp4o6-enable"
title="DHCPv4-over-DHCPv6 Enable Option Format">
<artwork><![CDATA[
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_ENABLE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list hangIndent="16" style="hanging">
<t hangText="option-code">OPTION_DHCP4_O_DHCP6_ENABLE (TBD)</t>
<t hangText="option-len"> 0</t>
</list>
</t>
</section>
<section title="4o6 Servers Address Option Format"
anchor="dhcp4o6-server-addr-option">
<t>The 4o6 Servers Address Option carries unicast IPv6 addresses of the
4o6 Servers.</t>
<t>The format of the 4o6 Servers Address Option is: </t>
<figure align="center" anchor="option-4o6-servers"
title="4o6 Servers Address Option Format">
<artwork><![CDATA[
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) .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list hangIndent="16" style="hanging">
<t hangText="option-code">OPTION_DHCP4_O_DHCP6_SERVERS (TBD)</t>
<t hangText="option-len">Length of the IPv6 address(es), i.e.
integer times of 16.</t>
<t hangText="IPv6 Address">The IPv6 address(es) of the 4o6 Server(s).</t>
</list>
</t>
</section>
</section>
<!--
<section title="Method 1: DHCPv4 over DHCPv6">
<section title="Method Overview">
<t>In this method, DHCP client will put DHCPv4 message into a
DHCPv6 option, i.e. the DHCPv4 Message Option. The DHCP packets
will be sent out as a DHCPv6 message.</t>
</section>
-->
<section title="Client Behavior">
<t>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.</t>
<t>Client MUST NOT initiate communication with 4o6 Servers before it obtains configuration
using DHCPv6 as described in <xref target="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: </t>
<t>
<list style="symbols">
<t>If the client doesn't receive the DHCPv4-over-DHCPv6 Enable Option, it SHOULD NOT
enable the DHCPv4 over DHCPv6 function. </t>
<t>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.</t>
<t>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. </t>
</list>
</t>
<t>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.</t>
<!-- Here starts the tricky part. Since we allow the use of unicast to multiple servers
we have to deal with sending multiple packets, each going to a different server. That will
complicate an implementation and also this text. This part will need to be extended.-->
<t>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
<xref target="RFC3315"/>. If client received this option it MUST send BOOTREQUESTV6
message to all unicast addresses listed in the received option.</t>
<t>When a client receives a BOOTREPLYV6 message, it MUST look for the
BOOTP Message Option within this message. If this option is not found, the
BOOTREPLYV6 message is discarded. If the BOOTP Message Option is found,
the client extracts the DHCPv4 message it contains and processes it as
described in section 4.4 of <xref target="RFC2131"/>.
</t>
<!-- We should not reference to the RFC2131 because we are now communicating with
the unified server -->
<t>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
<xref target="RFC2131"/>. As a result there are no explicit transmission
parameters associated with a BOOTPREQUESTV6 message.</t>
<t>As the DHCPv4 and DHCPv6 clients are running on the same host, the client
MUST implement <xref target="RFC4361"/> to ensure that the device correctly
identifies itself.</t>
<t>The IPv4 address allocated from the server MAY be assigned to a 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.</t>
</section>
<section title="Relay Agent Behavior">
<t>When a DHCPv6 relay agent receives a BOOTREQUESTV6 message, it MUST
handle the message as described in section 4 of
<xref target="I-D.ietf-dhc-dhcpv6-unknown-msg"/>.</t>
<t>A DHCPv6 relay agent MUST implement the Relay behaviour described in section
20.1.1 of <xref target="RFC3315"/>.</t>
<t>Additionally, the DHCPv6 relay agent MAY allow the configuration of dedicated
DHCPv4 over DHCPv6 specific destination addresses, differing from the
addresses of the DHCPv6 only server(s). To implement this function, the relay
checks the received DHCPv6 message type and forwards according to the following
logic:</t>
<t>
<list style="numbers">
<t>If the message type is BOOTREQUESTV6, then the DHCPv6 request is relayed to
the configured DHCPv4 aware 4o6 Server's address(es).</t>
<t>For any other DHCPv6 message type, forward according to section
20 of <xref target="RFC3315"/>.</t>
</list>
</t>
<t>The above logic only allows for separate relay destinations configured on
the relay agent closest to the client (single relay hop). Multiple relaying hops
are not considered in the case of separate relay destinations.</t>
<!--
<t>The DHCP relay agent will receive the DHCPv6 message containing
DHCPv4 Message Option from the multicast interface. It then handles the
message as a normal DHCPv6 relay agent as in Section 20.1 of
<xref target="RFC3315"/>.
In this method, DHCP client and server are capable of communicating with
each other directly, which does not necessitate any changes in
DHCPv6 relay agent behavior.</t>
-->
</section>
<section title="Server Behavior">
<t>When server receives a BOOTREQUESTV6 message from a
client, it searches for a BOOTP Message Option. If this option
is missing, the server discards the packet. The server MAY notify
an administrator about the receipt of a malformed packet. The
mechanism for this notification is out of scope for this document</t>
<t>If the server finds a valid BOOTP Message Option, it extracts the
original DHCPv4 message sent by the client. This message is
passed to the DHCPv4 server engine, which generates a response to
the client as specified in <xref target="RFC2131"/>. This engine can
be implemented as a built-in DHCPv4 server function of the 4o6 Server,
or it can be a separate DHCPv4 server instance. Discussion regarding
communication between the 4o6 Server and a DHCPv4 server engine is
out of scope for this document.</t>
<t>When appropriate DHCPv4 response is generated, 4o6 Server places it
in the payload of a BOOTP Message Option, which it puts into the BOOTREPLYV6
message.</t>
<t>If the BOOTREQUESTV6 message was received directly by the server,
the BOOTREPLYV6 message MUST be unicast from the interface on which
the original message was received.
</t>
<t>If the BOOTREQUESTV6 message was received in a Relay-forward
message, the server creates a Relay-reply message with the
BOOTREPLYV6 message in the payload of a Relay Message Option, and responds
as described in section 20.3 of <xref target="RFC3315"/>. </t>
</section>
<section title="Security Considerations">
<t>In this specification, DHCPv4 messages are encapsulated in the newly
defined option and messages. This is similar to handling the current
relay agent messages. In order to bypass firewalls or network
authentication gateways, a malicious attacker may leverage this
feature to convey other messages using DHCPv6, i.e. use DHCPv6
as a form of encapsulation. However, the potential risk from this is no greater
than that with current DHCPv4 and DHCPv6 practice.</t>
</section>
<section title="IANA Considerations">
<t>IANA is kindly requested to allocate three DHCPv6 option codes to the
OPTION_BOOTP_MSG, OPTION_DHCP4_O_DHCP6_ENABLE and OPTION_DHCP4_O_DHCP6_SERVERS,
and two DHCPv6 message type codes to the BOOTREQUESTV6 and BOOTREPLYV6. </t>
</section>
<section title="Contributors List">
<t>Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski,
Yuchi Chen and Cong Liu, for their great contributions to the draft.</t>
</section>
<!--
</section>
<section title="Method 2: DHCPv4 over IPv6">
<section title="Client Behavior">
<t>In this case, the client is enabled to send and receive
DHCPv4 messages through IPv6 sessions. The IPv6 UDP packet that
has a DHCPv4 message as its payload is called DHCPv4 over IPv6
packet. The client should use the port 546 as the destination
port, and the port 547 as the source port of each DHCPv4 over
IPv6 packet. </t>
</section>
<section title="Relay Agent Behavior">
<t>The relay agent should also send and receive DHCPv4 messages
through IPv6 on the interface facing to the client. It should
listen for DHCPv4 over IPv6 packets on port 546, and send
DHCPv4 over IPv6 packets on port 547.</t>
<t>When the relay agent receives a BOOTPREQUEST message (i.e.,
DHCPDISCOVER, DHCPREQUEST, etc.), it constructs a new relay
agent-forward message. It then copies the source IPv6 address
from the header of the received DHCPv4 over IPv6 packet to the
peer-address field of the relay agent-forward message. The
relay agent copies the received BOOTPREQUEST message (excluding
any IP or UDP headers) into the DHCPv4 Message option in the
new message. It then forwards such a relay agent-forward
message to the server.</t>
<t>When the relay agent received a relay agent-relay message
that includes the DHCPv4 Message option from the server, it
should extract the DHCPv4 message from the DHCPv4 Message
option of the message, and relay agent it to the address
contained in the peer-address field of the relay agent-reply
message.</t>
</section>
</section>
<section title="Server Behavior">
<t>When a DHCPv6 server receives a valid DHCPv6 message, it checks
for the presence of a DHCPv4 Message Option. If it is not present,
the server handles the DHCPv6 packet as is defined in <xref target="RFC3315"/>.
If it is present, the server processes the payload of the option as a DHCPv4
message. The DHCPv4 message is handled by the DHCPv6 server itself
(most likely scenario) or forwarded to another DHCPv4 server.</t>
<t>When sending out a DHCPv4 reply message, the DHCPv6 server MUST include
a DHCPv4 Message Option in an encapsulating DHCPv6 message that contains
the DHCPv4 message as the option payload.
</t>
<t>DHCPv4 messages with the same transaction ID SHOULD NOT be
transported inside DHCPv6 messages with different transaction
IDs.</t>
</section>
-->
<!--
<section title="Lifetime Considerations">
<t>When there is a binding table of IPv4 and IPv6 addresses related
to the DHCP server, a binding record may become invalid if the IPv6
address expires. The IPv4 address should be renewed when a client's
IPv6 address expires in this situation.
</t>
</section>
-->
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2131;
&rfc3315;
&rfc4361;
<?rfc include="reference.I-D.ietf-dhc-dhcpv6-unknown-msg" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-dhc-dhcpv4-over-ipv6" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:29:20 |