One document matched: draft-ietf-dhc-dhcpv4-over-dhcpv6-00.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-00" 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>
<t>Several approaches for provisioning such information have
already been proposed. This document describes alternative approach.
</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="BOOTREQUESTV6 (TBD):">A new type of DHCPv6 Client/Server message defined
in this document. A client sends a BOOTREQUESTV6 message to a server,
which contains a BOOTP Message Option. Each 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 new type of DHCPv6 Client/Server
message defined in this document. A server sends a BOOTREPLYV6 message
containing a BOOTP Message Option in response to a client's BOOTREQUESTV6 message.
Each BOOTP Message Option, wrapped in a BOOTREPLYV6 message, contains a
BOOTREPLY message. This contains the BOOTREQUEST response corresponding
to a client's 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>
<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"/>.
The client sends all DHCPv6 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).</t>
<t>The DHCPv6 packet can be transmitted either via Relay Agents or
directly to the server. The server is referred in this document as
a "Unified Server" for its capability of processing regular DHCPv6
traffic as well as DHCPv4 packets wrapped in the BOOTP Message
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. </t>
<figure align="center" anchor="architecture-overview"
title="Architecture Overview">
<artwork><![CDATA[
_____________ _____________
/ \ / \
| | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| DHCP | network | DHCP | network | Unified |
| Client +---------+ Relay Agent +---------+ Server |
| (on CPE) | | | | |
+--------+-+ +-+-----------+-+ +-+--------+
| | | |
\_____________/ \_____________/
]]></artwork>
</figure>
</section>
<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="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>When a client requires an IPv4 address and/or other IPv4 configuration
parameters, it MUST generate a DHCPv4 message to obtain them from a DHCP server.
This message is stored verbatim in the BOOTP Message Option carried by the
BOOTREQUESTV6 message. A Client MUST put exactly one BOOTP Message Option into a
single BOOTREQUESTV6 message. The Client sends out the BOOTREQUESTV6 message to the
Well-Known multicast address, i.e. All_DHCP_Relay_Agents_and_Servers on multicast
address defined in <xref target="RFC3315"/>. </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>
<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 20.1.1 of <xref target="RFC3315"/>.</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 a 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 unified 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 this document.</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 Unified Server,
or it can be a separate DHCPv4 server instance. Discussion regarding
communication between the Unified Server and a DHCPv4 server engine is
out of scope for this document.</t>
<t>When appropriate DHCPv4 respose is generated, Unified 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. This is
analogous to other types of DHCPv6 messages as described in
<xref target="RFC3315"/>. The server unicasts the Relay-reply
message directly to the IP address of the relay agent from which
the Relay-forward message was received.</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 one DHCPv6 option code to the
OPTION_BOOTP_MSG 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;
</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:58:49 |