draft-ietf-dhc-dhcpv4-over-dhcpv6-04.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">
<!ENTITY rfc4242 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4242.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-04" 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="2013"/>

  <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 as       
      well as new DHCPv6 options are defined for the purpose of conveying       
      DHCPv4 messages through IPv6 networks. 
      </t>
  </abstract>
</front>

<middle>
    <section title="Introduction">
      <t>As the migration towards IPv6 continues, IPv6-only networks 
      will become more prevalent. At the same time, IPv4 connectivity will continue 
      to be provided as a service over 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>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 infrastructure for DHCPv4, e.g. failover, DNS updates, leasequery, etc.
      Also, it has the added benefit of providing information about the IPv6 network 
      over which the request is sent, as a result of having passed through one or 
      more DHCPv6 relay agents.
      </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="4o6 DHCP Client:"> A DHCP client that supports both DHCPv6 protocol
        <xref target="RFC3315"/> as well as the DHCPv4 over DHCPv6 protocol described in 
		this document. Such a client is capable of requesting its IPv6 configuration
        using DHCPv6 and IPv4 configuration using DHCPv4 over DHCPv6.</t>

        <t hangText="4o6 DHCP Server:"> A DHCP server that is capable of processing DHCPv4
        packets encapsulated in the BOOTP Message option (defined below).
        </t>

        <t hangText="CPE:"> Customer Premises Equipment (also known as Customer Provided
        Equipment), which provides the access of devices connected to a Local Area Network
        (typically at the customer's site/home) to the Internet Service Provider's network.</t>

        <t hangText="DHCPv4 over DHCPv6:"> A protocol described in this document, which
        is used to carry DHCPv4 messages in the payload of DHCPv6 messages.</t>

      </list>
      </t>
    </section>

    <section title="Architecture Overview">
      <t>The architecture described in this document 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 it must configure IPv4 services 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 only to
      DHCPv4. As the DHCPv4 message is a special type of the BOOTP message, BOOTP
      messages can also be transported using the same mechanism.</t>

      <t>DHCP clients can 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 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 does not preclude any end-host, or other device requiring 
      IPv4 configuration, from implementing the mechanism 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 4o6 DHCP client implements a new DHCPv6 message called DHCPv4-query,
      which contains a new option called BOOTP Message option encapsulating a DHCPv4 
      request. The format of this option is described in <xref target="bootp-message-option"/>.
      </t>

      <t>The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents or
      directly to the 4o6 DHCP Server. The server replies with a DHCPv4-response message,
      which is a new DHCPv6 message carrying the DHCPv4 response encapsulated in 
      the BOOTP Message option.
      </t>

      <figure align="center" anchor="architecture-overview"
              title="Architecture Overview">
      <artwork><![CDATA[
           _____________             _____________
          /             \           /             \
          |             |           |             |
 +--------+-+  IPv6   +-+-----------+-+  IPv6   +-+--------+
 | 4o6 DHCP | network |    DHCPv6     | network | 4o6 DHCP |
 |  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 IPv6 configuration. The
    client requests the 4o6 Server Address option from the DHCPv6 server by sending the 
    option code in Option Request option described in <xref target="RFC3315"/>. If the 
    DHCPv6 server responses with the 4o6 Server Address option, it is an indication to 
    the client to use DHCPv4 over DHCPv6 to obtain IPv4 configuration.</t>

    <t>The 4o6 DHCP client obtains the address(es) of the 4o6 DHCP server(s) from the 
    4o6 Server Address option and uses them to communicate with the 4o6 DHCP servers as 
    described in <xref target="client-behavior"/>. If the 4o6 Server Address option 
    contains no addresses (is empty), the 4o6 DHCP client uses well known 
    All_DHCP_Relay_Agents_and_Servers multicast address to communicate with the 
    4o6 DHCP server(s).</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? -->

    <!-- Write some text what 4o6 DHCP client is supposed to do with the obtained configuration! -->
    
    </section>

    <section title="New DHCPv6 Messages">
      <t>There are two new DHCPv6 messages defined in this document which carry DHCPv4 
      messages between a client and a server using DHCPv6 protocol: DHCPv4-query and 
      DHCPv4-response. This section describes the structures of these messages.</t>

      <section title="Message Types">
	    <t>
        <list hangIndent="22" style="hanging">
          <t hangText="DHCPV4-QUERY (TBD):"> A 4o6 DHCP client sends a DHCPv4-query 
          message to a 4o6 DHCP server. The BOOTP Message Option carried by this message 
          contains a BOOTREQUEST message that the 4o6 DHCP client uses to request IPv4 
          configuration parameters from the server.</t>

          <t hangText="DHCPv4-RESPONSE (TBD):"> A 4o6 DHCP server sends a DHCPv4-response 
          message to a 4o6 DHCP client. It contains a BOOTP Message Option carrying 
          a BOOTREPLY message in response to a BOOTREQUEST received by the server
          in the BOOTP Message Option of the 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="boot-v6-msg-format"
                title="Architecture Overview">
          <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) which corresponds to the 
            DHCPv4-query or DHCPv4-response, respectively.</t>
            <t hangText="flags">Specifies flags that provide additional information 
            required by the server to process a DHCPv4 message encapsulated in the 
            DHCPv4-query message, or required by the client to process DHCPv4 message 
            encapsulated in the DHCPv4-response message.</t>
            <t hangText="options">The options carried by the message. The BOOTP Message
            Option described in <xref target="bootp-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 
            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|                 Reserved                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></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.</t>
            <t hangText="Reserved">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 4o6 Server
        MUST set all bits of this field to 0 and the 4o6 client MUST ignore the content
        in this field.</t>
      </section>
    </section>


    <section title="New DHCPv6 Options" anchor="new-v6-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 DHCPv4-query message it contains
                   a BOOTREQUEST message sent by a client. In a DHCPv4-response
                   message it contains a BOOTREPLY 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 the DHCPv6 server to the client requesting
        IPv6 configuration. It carries a list of IPv6 addresses of the 4o6 DHCP servers that
        4o6 DHCP client should contact to obtain IPv4 configuration. The carried addresses
        may include either multicast or unicast addresses. The 4o6 DHCP client sends its
        requests to all unique addresses carried in this option.</t>
        <t>It is allowed that this option carries no IPv6 addresses, which instructs the
        client to use All_DHCP_Relay_Agents_and_Servers multicast address as a default.</t>

        <t>The presence of this option in the DHCPv6 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 4o6 DHCP 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, the client in the RENEWING state uses a unicast address to contact 
      a DHCPv4 server to renew its lease. The 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 case the server is unable to determine whether the client sent 
      a message to a unicast or broadcast address and thus the server may be unable to 
      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 4o6 
      DHCP Server. There is no relation between the outer IPv6 address and the inner 
      DHCPv4 message. So the server is not able 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 the how the DHCPv4 packet would have been 
      sent; not how the DHCPv6 packet itself is sent.</t>
    </section>

    <section anchor="client-behavior" title="4o6 DHCP Client Behavior">

      <t>The DHCPv4-over-DHCPv6 function MUST be disabled by default. The client MUST
      obtain its IPv6 configuration before using DHCPv4 over DHCPv6. A client that
	  intends to use DHCPv4 over DHCPv6 MUST request the 4o6 Server Address option
	  using Option Request option (ORO) in every Solicit, Request, Renew and Information-request message.
      The 4o6 DHCP client MUST NOT request the 4o6 Server Address option in the
      DHCPv4-query message. </t>   

      <t>The DHCPv6 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
      DHCPv6 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 running, the 
      client MUST disable the DHCPv4-over-DHCPv6 function.</t>
      
      <t>In the case that the 4o6 DHCP client receives the 4o6 Server Address option but 
      there is any DHCPv4 client running 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 received 4o6 Server Address option contains no IP addresses, i.e. the
      option is empty, the 4o6 DHCP 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 4o6 DHCP client SHOULD send requests to each unique 
      address carried by the option.</t>
      
      <t>The 4o6 DHCP client MUST employ a source IPv6 address of a proper scope to send the 
      DHCPv4-query message. When the client sends a DHCPv4-query message to the multicast 
      address, it MUST use a link-local address as the source address as in RFC3315. 
      When the client sends a DHCPv4-query message using unicast, the source address 
      MUST be the global IPv6 address acquired in advance. </t>

      <t>A client supporting DHCPv4 over DHCPv6 SHOULD use Information Refresh Time
      Option <xref target="RFC4242"/> to refresh the status of DHCPv4-over-DHCPv6 function
      as well as other DHCPv6 configuration data. </t>
      
      <t>The client generates a DHCPv4 message and stores it verbatim in the BOOTP 
      Message option carried by the DHCPv4-query message. The client MUST put exactly 
      one BOOTP Message option into a single DHCPv4-query message.  
      </t>

      <t>The client MUST follow rules defined in <xref target="uni_flag"/> when setting 
      Unicast flag based on the DHCPv4 destination.</t>


<!-- The following paragraph does not seem to apply anymore as we may have multiple addresses
     of a different kind in a single option.

      <t>If the client has not received the 4o6 Server Addresses option from the 
	  DHCPv6 server, it transmits the DHCPv4-query message as specified in 
	  Section 13 of <xref target="RFC3315"/>. If the client received this option, it 
	  SHOULD send DHCPv4-query message to all unicast addresses listed in the option.</t> -->

      <t>On receiving a DHCPv4-response message, the client MUST look for the
      BOOTP Message option within this message. If this option is not found, the
      DHCPv4-response message is discarded. If the BOOTP 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 4o6 DHCP 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 4o6 DHCP 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. It can just forward this message as 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
            4o6 DHCP 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="4o6 DHCP Server Behavior">
      <t>When the server receives a DHCPv4-query message from a client, it searches for 
      the BOOTP 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 BOOTP 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 appropriate DHCPv4 response is generated, the 4o6 Server places it
      in the payload of a BOOTP 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>There are chances that a rogue DHCPv6 server may reply with a 4o6 Server Address
    Option containing duplicated IPv6 addresses, which can 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 those 
    duplicated IPv6 addresses. </t>
  </section>

  <section title="IANA Considerations">

    <t>IANA is requested to allocate three DHCPv6 option codes for use by 
    OPTION_BOOTP_MSG, OPTION_DHCP4_O_DHCP6_ENABLE and OPTION_DHCP4_O_DHCP6_SERVERS 
    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;
    &rfc4361;
    &rfc4242;
  </references>

  <references title="Informative References">
 
    &rfc5010;
    <?rfc include="reference.I-D.ietf-dhc-dhcpv6-unknown-msg" ?>
  </references>

</back>
</rfc>