One document matched: draft-ietf-dhc-dhcpv4-over-dhcpv6-05.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 rfc4242 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4242.xml">
<!ENTITY rfc4361 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4361.xml">
<!ENTITY rfc5010 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5010.xml">
]>
<rfc category="std" docName="draft-ietf-dhc-dhcpv4-over-dhcpv6-05" 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/>
<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/>
<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="2014"/>
<workgroup>DHC Working Group</workgroup>
<abstract>
<t>IPv4 connectivity is still needed as networks migrate towards IPv6.
Users require IPv4 configuration even if the uplink to their service
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
and two new DHCPv6 options are defined for this purpose.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As the migration towards IPv6 continues, IPv6-only networks
will become more prevalent. In such networks, IPv4 connectivity will
continue to be provided as a service over IPv6-only networks. In addition
to provisioning IPv4 addresses for clients of this service, other
IPv4 configuration parameters may also be needed (e.g. addresses of
IPv4-only services).</t>
<t>This document describes a transport mechanism to carry DHCPv4 messages
using the DHCPv6 protocol for the dynamic provisioning of IPv4 addresses
and other DHCPv4 specific configuration parameters across IPv6-only
networks. It leverages the existing DHCPv4 infrastructure, e.g. failover,
DNS updates, DHCP leasequery, etc.</t>
<t>When IPv6 multicast is used to transport 4o6 messages, another benefit
is that the operator can gain information about the underlying IPv6
network the 4o6 client is connected to from the the DHCPv6 relay
agents the request has passed through.</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="32" style="hanging">
<t hangText="CPE:"> Customer Premises Equipment (also known as Customer
Provided Equipment), which provides access for devices connected to a
Local Area Network (typically at the customer's site/home) to the
Internet Service Provider's network.</t>
<t hangText="DHCP 4o6 client (or client):"> A DHCP client supporting both the DHCPv6
protocol <xref target="RFC3315"/> as well as the DHCPv4 over DHCPv6
protocol described in this document. Such a client is capable of
requesting IPv6 configuration using DHCPv6 and IPv4 configuration using
DHCPv4 over DHCPv6.</t>
<t hangText="DHCP 4o6 server (or server):"> A DHCP server that is capable of
processing DHCPv4 packets encapsulated in the DHCPv4 Message option
(defined below).</t>
<t hangText="DHCPv4 over DHCPv6:"> A protocol described in this
document, used to carry DHCPv4 messages in the payload of DHCPv6
messages.</t>
</list>
</t>
</section>
<section title="Architecture Overview">
<t>The architecture described here addresses a typical
use case, where 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, so IPv4 services must be configured using IPv6 as the
underlying network protocol.</t>
<t>Although the purpose of this document is to address the problem of
communication between the DHCPv4 client and the DHCPv4 server, the
mechanism that it describes does not restrict the transported messages
types to DHCPv4 only. As the DHCPv4 message is a special type of BOOTP
message, BOOTP messages can also be transported using the same mechanism.
</t>
<t>DHCP clients may be running on CPE devices, end hosts or any other
device that supports the DHCP client function. At the time of writing,
DHCP clients on CPE devices are comparatively easier to modify than those
implemented on end hosts. As a result, this document uses the CPE as an
example for describing the mechanism. This does not preclude any end-host,
or other device requiring IPv4 configuration, from implementing DHCPv4
over DHCPv6 in the future.</t>
<t>This mechanism works by carrying DHCPv4 messages encapsulated within
DHCPv6 messages. <xref target="architecture-overview"/>, below,
illustrates one possible deployment architecture.</t>
<t>The DHCP 4o6 client implements a new DHCPv6 message called
DHCPv4-query, which contains a new option called the DHCPv4 Message option
encapsulating a DHCPv4 message sent by the client. The format of this
option is described in <xref target="dhcpv4-message-option"/>.
</t>
<t>The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents or
directly to the DHCP 4o6 server. The server replies with a DHCPv4-response
message, which is a new DHCPv6 message carrying the DHCPv4 response
encapsulated in the DHCPv4 Message option.
</t>
<figure align="center" anchor="architecture-overview"
title="Architecture Overview">
<artwork><![CDATA[
_____________ _____________
/ \ / \
| | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| DHCP 4o6 | network | DHCPv6 | network | DHCP 4o6 |
| client +---------+ Relay Agent +---------+ Server |
| (on CPE) | | | | |
+--------+-+ +-+-----------+-+ +-+--------+
| | | |
\_____________/ \_____________/
]]></artwork>
</figure>
<t>By default, the DHCPv4-over-DHCPv6 function MUST be disabled on the
client. Before the client can use DHCPv4 over DHCPv6, it MUST obtain the
necessary IPv6 configuration. The client requests the 4o6 Server Address
option from the server by sending the option code in Option Request
option as described in <xref target="RFC3315"/>. If the server
responds with the 4o6 Server Address option, it is an indication to
the client to attempt using DHCPv4 over DHCPv6 to obtain IPv4 configuration.
</t>
<t>The client obtains the address(es) of the DHCP 4o6 server(s)
from the 4o6 Server Address option and uses them to communicate with the
DHCP 4o6 servers as described in <xref target="client-behavior"/>. If the
4o6 Server Address option contains no addresses (is empty), the
client uses the well-known All_DHCP_Relay_Agents_and_Servers multicast
address to communicate with the DHCP 4o6 server(s).</t>
<t>Before applying for an IPv4 address via a DHCPv4-query message, the
client must identify a suitable network interface for the address.
Once the request is acknowledged by the server, the client can
configure the address and other relevant parameters on this interface. The
mechanism for determining a suitable interface is out of the scope of the
document.</t>
<!-- Should a clarification be added here that "The options related to DHCPv6 configuration
MUST NOT be included in the new DHCPv6 messages, including the 4o6 Server Address option"?
Or some place else? -->
</section>
<section title="New DHCPv6 Messages">
<t>Two new DHCPv6 messages carry DHCPv4 messages between the client and
the server using the DHCPv6 protocol: DHCPv4-query and DHCPv4-response.
This section describes the structures of these messages.</t>
<section title="Message Types">
<t>
<list hangIndent="24" style="hanging">
<t hangText="DHCPV4-QUERY (TBD):"> The DHCP 4o6 client sends a
DHCPv4-query message to a DHCP 4o6 server. The DHCPv4 Message option
carried by this message contains a DHCPv4 message that the DHCP
4o6 client uses to request IPv4 configuration parameters from the
server.</t>
<t hangText="DHCPv4-RESPONSE (TBD):">A DHCP 4o6 server sends a
DHCPv4-response message to a DHCP 4o6 client. It contains a DHCPv4
Message option carrying a DHCPv4 message in response to a
DHCPv4 message received by the server in the DHCPv4 Message option
of the DHCPv4-query message. </t>
</list>
</t>
</section>
<section title="Message Formats">
<t>Both DHCPv6 messages defined in this document share the following format:</t>
<figure align="center" anchor="new-msg-format"
title="The format of DHCPv4-query and DHCPv4-response messages">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list hangIndent="16" style="hanging">
<t hangText="msg-type">Identifies the message type. It can be either
DHCPV4-QUERY (TBD) or DHCPV4-RESPONSE (TBD) corresponding to the
contained DHCPv4-query or DHCPv4-response, respectively.</t>
<t hangText="flags">Specifies flags providing additional information
required by the server to process the DHCPv4 message encapsulated in
the DHCPv4-query message, or required by the client to process a
DHCPv4 message encapsulated in the DHCPv4-response message.</t>
<t hangText="options">Options carried by the message. The DHCPv4
Message Option (described in <xref target="dhcpv4-message-option"/>)
MUST be carried by the message. Only DHCPv6 options for IPv4
configuration may be included in this field. It MUST NOT contain
DHCPv6 options related solely to IPv6, or IPv6-only service
configuration.</t>
</list>
</t>
</section>
<section title="DHCPv4-query Message Flags">
<t>The "flags" field of the DHCPv4-query is used to carry additional
information that 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. The "flags"
field has the following format:</t>
<figure align="center" anchor="DHCPv4-query-flags"
title="DHCPv4-query flags format">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list hangIndent="16" style="hanging">
<t hangText="U">Unicast Flag. If set to 1, it indicates that the
DHCPv4 message encapsulated within the DHCPv4-query 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 the
broadcast address if it was sent using IPv4. The usage of the flag is
described in detail in <xref target="uni_flag"/>.</t>
<t hangText="MBZ">Bits MUST be set to zero when sending and
MUST be ignored when receiving.</t>
</list>
</t>
</section>
<section title="DHCPv4-response Message Flags">
<t>This document introduces no flags to be carried in the "flags" field
of the DHCPv4-response message. They are all reserved for the future
use. The DHCP 4o6 server MUST set all bits of this field to 0 and the DHCP 4o6
client MUST ignore the content in this field.</t>
</section>
</section>
<section title="New DHCPv6 Options" anchor="new-v6-options">
<section title="DHCPv4 Message Option Format" anchor="dhcpv4-message-option">
<t>The DHCPv4 Message option carries a DHCPv4 message that is sent
by the client or the server. Such messages exclude any IP or
UDP headers. </t>
<t>The format of the DHCPv4 Message option is: </t>
<figure align="center" anchor="option-dhcpv4-msg"
title="DHCPv4 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_DHCPV4_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCPv4-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list hangIndent="16" style="hanging">
<t hangText="option-code">OPTION_DHCPV4_MSG (TBD).</t>
<t hangText="option-len">Length of the DHCPv4 message.</t>
<t hangText="DHCPv4-message">The DHCPv4 message sent by the client
or the server. In a DHCPv4-query message it contains a DHCPv4
message sent by a client. In a DHCPv4-response message it contains a
DHCPv4 message sent by a server in response to a client.</t>
</list>
</t>
</section>
<section title="4o6 Server Address Option Format"
anchor="dhcp4o6-server-addr-option">
<t>The 4o6 Server Address option is sent by a server to a
client requesting IPv6 configuration using DHCPv6 <xref target="RFC3315"/>.
It carries a list of DHCP 4o6 server's IPv6 addresses that the client
should contact to obtain IPv4 configuration. This list may include either
multicast or unicast addresses. The client sends its requests
to all unique addresses carried in this option.</t>
<t>This option may also carry no IPv6 addresses, which instructs the
client to use the All_DHCP_Relay_Agents_and_Servers multicast address
as the destination address.</t>
<t>The presence of this option in the server's response indicates
to the client that it should use DHCPv4 over DHCPv6 to obtain IPv4
configuration. If the option is absent, the client MUST NOT enable
DHCPv4-over-DHCPv6 function.</t>
<t>The format of the 4o6 Server 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_SERVER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IPv6 Address(es) .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list hangIndent="16" style="hanging">
<t hangText="option-code">OPTION_DHCP4_O_DHCP6_SERVER (TBD).</t>
<t hangText="option-len">Length of the IPv6 address(es) carried by the
option, i.e. multiple of 16 octets. Minimal length of this option is
0.</t>
<t hangText="IPv6 Address">Zero or more IPv6 addresses of the DHCP 4o6
Server(s).</t>
</list>
</t>
</section>
</section>
<section anchor="uni_flag" title="Use of the DHCPv4-query Unicast Flag">
<t>A DHCPv4 client conforming to <xref target="RFC2131"/> may send its
DHCPREQUEST message to either a broadcast or unicast address depending on
its state. For example, a client in the RENEWING state uses a unicast
address to contact the DHCPv4 server to renew its lease. A client in the
REBINDING state uses a broadcast address. If there is a DHCPv4 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 a case, the
server is unable to determine whether the client sent the message to a
unicast or broadcast address and thus the server may be unable to
correctly determine the client's state. <xref target="RFC5010"/>
introduced the "Flags Suboption" that relay agents add to relayed messages
to indicate whether broadcast or unicast was used by the client.</t>
<t>In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the
DHCP 4o6 server. There is no relation between the outer IPv6 address and
the inner DHCPv4 message. As a result, the server is unable to determine
whether the received DHCPv4 messages should have been sent using broadcast
or unicast in IPv4 by checking the IPv6 address. This is similar to the
case addressed by <xref target="RFC5010"/>.</t>
<t>In order to allow the server to determine the client's state, the
"Unicast" flag is carried in the DHCPv4-query message. The client MUST set
this flag to 1 when the DHCPv4 message would have been sent 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 is made based on the <xref target="RFC2131"/> and its
extensions.</t>
<t>Note: The "Unicast" flag reflects how the DHCPv4 packet would have been
sent; not how the DHCPv6 packet itself is sent.</t>
</section>
<section anchor="client-behavior" title="DHCP 4o6 Client Behavior">
<t>The DHCPv4-over-DHCPv6 function MUST be disabled by default. The client
MUST obtain the necessary IPv6 configuration (stateless or stateful) before
using DHCPv4 over DHCPv6. The client intending to use DHCPv4 over DHCPv6 MUST
request the 4o6 Server Address option using Option Request option (ORO) in
every Solicit, Request, Renew, Rebind and Information-request message.</t>
<t>The server MAY include the 4o6 Server Address option in its
response to the client. If the client receives this option, it MUST enable
the DHCPv4-over-DHCPv6 function. The client MUST NOT enable the
DHCPv4-over-DHCPv6 function if the server does not include the 4o6
Server Address option in its response. If the client does not receive this
option and DHCPv4 over DHCPv6 is already enabled, the client MUST disable
the DHCPv4-over-DHCPv6 function.</t>
<t>If the client receives the 4o6 Server Address option and
there is a DHCPv4 client active on the interface over which that DHCPv6
option was received, it MUST stop the DHCPv4 client from sending messages
using <xref target="RFC2131"/>.</t>
<t>If the client receives a 4o6 Server Address option that contains no
IP addresses, i.e. the option is empty, the client MUST send its
requests to the All_DHCP_Relay_Agents_and_Servers multicast address. If
there is a list of IP addresses in the option, the client SHOULD
send requests to each unique address carried by the option.</t>
<t>If the client obtained stateless IPv6 configuration by sending
Information-request message to the server, the client MUST follow the rules
in <xref target="RFC4242"/> to periodically refresh the DHCPv4-over-DHCPv6
configuration (i.e. list of DHCP 4o6 servers) as well as other configuration
data. The client which obtained stateful IPv6 configuration will refresh the
status of DHCPv4-over-DHCPv6 function when extending a lifetime of acquired
IPv6 address (Renew and Rebind messages).</t>
<t>The client MUST employ an IPv6 address of an appropriate scope
to source the DHCPv4-query message from. When the client sends a
DHCPv4-query message to the multicast address, it MUST use a link-local
address as the source address as described in <xref target="RFC3315"/>.
When the client sends a DHCPv4-query message using unicast, the source
address MUST be an address of appropriate scope, acquired in advance.</t>
<t>The client generates a DHCPv4 message and stores it verbatim in the
DHCPv4 Message option carried by the DHCPv4-query message. The client MUST
put exactly one DHCPv4 Message option into a single DHCPv4-query message.
The client MUST NOT request the 4o6 Server Address option in the
DHCPv4-query message.
</t>
<t>The client MUST follow rules defined in <xref target="uni_flag"/> when
setting the Unicast flag based on the DHCPv4 destination.</t>
<t>On receiving a DHCPv4-response message, the client MUST look for the
DHCPv4 Message option within this message. If this option is not found, the
DHCPv4-response message is discarded. If the DHCPv4 Message option is
present, the client extracts the DHCPv4 message it contains and processes
it as described in section 4.4 of <xref target="RFC2131"/>.
</t>
<t>When dealing with IPv4 configuration, the client MUST follow
the normal DHCPv4 retransmission requirements and strategy as specified in
section 4.1 of <xref target="RFC2131"/>. There are no explicit
transmission parameters associated with a DHCPv4-query message, as this is
governed by the DHCPv4 <xref target="RFC2131"/> "state machine".</t>
<t>The client MUST implement <xref target="RFC4361"/> to ensure
that the device correctly identifies itself.</t>
</section>
<section title="Relay Agent Behavior">
<t>When a DHCPv6 relay agent receives a DHCPv4-query message, it may not
recognize this message. The unknown message can be forwarded as described
in <xref target="I-D.ietf-dhc-dhcpv6-unknown-msg"/>.</t>
<t>Additionally, the DHCPv6 relay agent MAY allow the configuration of a
dedicated DHCPv4 over DHCPv6 specific destination address(es), differing
from the address(es) 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 DHCPV4-QUERY, the packet is relayed to the
configured DHCP 4o6 Server's address(es) in the form of normal
DHCPv6 packet (i.e. DHCPv6/UDP/IPv6). </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>
</section>
<section title="DHCP 4o6 Server Behavior">
<t>When the server receives a DHCPv4-query message from a client, it
searches for the DHCPv4 Message option. The server discards the packet
without this option. 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 DHCPv4 Message option, it extracts the
original DHCPv4 message and the contents of the "flags" field carried in
the DHCPv4-query message and uses them to generate the appropriate DHCPv4
response (server to client message). The response is generated as
described in <xref target="RFC2131"/> with the exception that the server
SHOULD use the information carried in the "flags" field of the
DHCPv4-query message to find out whether the client's message would have
been sent to the broadcast or unicast address if IPv4 has been used. This
is useful for the server to determine the state of the client. The use of
the "flags" field is described in detail in <xref target="uni_flag"/>.
</t>
<t>When an appropriate DHCPv4 response is generated, the 4o6 Server places
it in the payload of a DHCPv4 Message option, which it puts into the
DHCPv4-response message.</t>
<t>If the DHCPv4-query message was received directly by the server,
the DHCPv4-response message MUST be unicast from the interface on which
the original message was received.
</t>
<t>If the DHCPv4-query message was received in a Relay-forward message,
the server creates a Relay-reply message with the DHCPv4-response 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 the handling of 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
more severe than that with the current DHCPv4 and DHCPv6 practice.</t>
<t>It is possible for a rogue server to reply with a 4o6 Server
Address Option containing duplicated IPv6 addresses, which could cause an
amplification attack. To avoid this, the client MUST check if there are
duplicate IPv6 addresses in a 4o6 Server Address Option when receiving one.
The client MUST ignore any but the first instance of each address.</t>
</section>
<section title="IANA Considerations">
<t>IANA is requested to allocate two DHCPv6 option codes for use by
OPTION_DHCPV4_MSG, OPTION_DHCP4_O_DHCP6_SERVER from the "DHCP Option Codes" table, and two
DHCPv6 message type codes for the DHCPV4-QUERY and DHCPV4-RESPONSE from the
"DHCP Message Codes" table of the Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Registry. Both tables can be found at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml.
</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>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2131;
&rfc3315;
&rfc4242;
&rfc4361;
</references>
<references title="Informative References">
&rfc5010;
<?rfc include="reference.I-D.ietf-dhc-dhcpv6-unknown-msg" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:14:32 |