DHC Working Group                                                 Q. Sun
Internet-Draft                                                    Y. Cui
Intended status: Standards Track                     Tsinghua University
Expires: April 21, May 26, 2014                                       M. Siodelski
                                                             S. Krishnan
                                                               I. Farrer
                                                     Deutsche Telekom AG
                                                        October 18,
                                                       November 22, 2013

                      DHCPv4 over DHCPv6 Transport


   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 a new DHCPv6 option options are defined for the purpose of
   conveying DHCPv4 messages through IPv6 networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 21, May 26, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   3
   5.  New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Message Types . . . . . . . . . . . . . . . . . . . . . .   5
     5.2.  Message Formats . . . . . . . . . . . . . . . . . . . . .   5
     5.3.  Boot-request-v6 Message Flags . . . . . . . . . . . . . .   6
     5.4.  Boot-reply-v6 Message Flags . . . . . . . . . . . . . . .   6
   6.  New DHCPv6 Options  . . . . . . . . . . . . . . . . . . . . . . .   6   7
     6.1.  BOOTP Message Option Format . . . . . . . . . . . . . . .   6   7
     6.2.  DHCPv4-over-DHCPv6 Enable Option Format . . . . . . . . .   7
     6.3.  4o6 Servers Server Address Option Format  . . . . . . . . . . . .   8
   7.  Use of the Boot-request-v6 Unicast Flag . . . . . . . . . . .   8
   8.  4o6 DHCP Client Behavior  . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Relay Agent Behavior  . . . . . . . . . . . . . . . . . . . .  10
   10. 4o6 DHCP Server Behavior  . . . . . . . . . . . . . . . . . . . . .  11
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11  12
   13. Contributors List . . . . . . . . . . . . . . . . . . . . . .  11  12
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     14.2.  Informative References . . . . . . . . . . . . . . . . .  12  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12  13

1.  Introduction

   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).

   By conveying DHCPv4 messages over DHCPv6 transport, this

   This document describes a transport mechanism to carry DHCPv4
   messages using DHCPv6 protocol, for the dynamic provisioning of IPv4
   addresses and other DHCPv4 specific configuration parameters.  The mechanism parameters across
   IPv6-only networks.  It leverages the existing infrastructure for
   DHCPv4, e.g. failover, DNS updates, leasequery, etc.  This mechanism is suitable for stateful allocation and
   management of IPv4 addresses (dynamic leasing) and other IPv4
   configuration parameters across IPv6-only networks.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  Terminology

   This document makes use of the following terms:


   4o6 DHCP Client:      A protocol described in this document, DHCP client which is
                         used to carry supports both DHCPv6
                         protocol [RFC3315] as well as the DHCPv4 messages encapsulated in over
                         DHCPv6 messages.

   DHCP client:          The 'DHCP client' protocol described in this document consists of
                         both DHCPv4 and DHCPv6 client engines.  The document.
                         Such a client is able capable to request its IPv6
                         information through DHCPv6, as well as to
                         request using DHCPv6 and IPv4
                         configuration information using
                         DHCPv4-over-DHCPv6 transport. DHCPv4 over DHCPv6.

   4o6 DHCP Server:      A DHCP server that is capable of processing
                         DHCPv4 packets wrapped encapsulated in the DHCPv6 option: BOOTP
                         Message Option option (defined below).

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

   DHCPv4 over DHCPv6:   A protocol described in this document, which is
                         used to carry DHCPv4 messages in the payload of
                         DHCPv6 messages.

4.  Architecture Overview

   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 and so
   services.  So it must configure IPv4 services using IPv6 as the
   underlying transport network protocol.

   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.

   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 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.

   This mechanism works by carrying DHCPv4 messages encapsulated within
   DHCPv6 messages.  Figure 1, below, illustrates one possible
   deployment architecture.

   The 4o6 DHCP client implements a new DHCPv6 message called Boot-
   request-v6, which contains a new option called BOOTP Message Option. option.
   The format of this option is described in Section 6.1.

   The DHCPv6 packet message can be transmitted either via DHCPv6 Relay Agents
   or directly to the 4o6 DHCP Server.  The server replies with a DHCPv6
   response, Boot-
   reply-v6 message, which is a new DHCPv6 message called Boot-reply-v6. type.  This message
   carries the DHCPv4 response wrapped with encapsulated in the BOOTP Message
   Option. option.

                  _____________             _____________
                 /             \           /             \
                 |             |           |             |
        +--------+-+  IPv6   +-+-----------+-+  IPv6   +-+--------+
        | 4o6 DHCP | network |     DHCP    DHCPv6     | network | 4o6 DHCP |
        |  Client  +---------+  Relay Agent  +---------+  Server  |
        | (on CPE) |         |               |         |          |
        +--------+-+         +-+-----------+-+         +-+--------+
                 |             |           |             |
                 \_____________/           \_____________/

                      Figure 1: Architecture Overview

   By default, the DHCPv4-over-DHCPv6 is function MUST be disabled on the
   client.  Before
   a the client can use this protocol DHCPv4 over DHCPv6, it MUST obtain
   the necessary IPv6 configuration.  If the client is configured to use DHCPv6 to obtain
   its IPv6 configuration, the DHCPv6 server MAY include  It requests the DHCPv4
   -over-DHCPv6 DHCPv4-over-DHCPv6 Enable Option in its Reply message to indicate that
   client SHOULD use
   option by sending its code in Option Request Option (ORO) described
   in [RFC3315].  The DHCPv6 server includes the DHCPv4-over-DHCPv6 protocol
   Enable option in response to obtain
   additional a client's request to instruct the
   client to use DHCPv4 over DHCPv6 for IPv4 configuration.  The format
   of the DHCPv4-over-DHCPv6 Enable Option option is described in Section 6.2.

   Typically, a 4o6 DHCP client communicates with the 4o6 Servers DHCP servers
   using well
   known well-known All_DHCP_Relay_Agents_and_Servers multicast address.  If

   Client SHOULD request the 4o6 Server Address Option from a DHCPv6
   server is and the server may be configured to do so, it MAY send unicast addresses
   of the 4o6 Servers respond to the client during the client's configuration
   using DHCPv6.  The with
   one such option that contains one or more unicast addresses are carried in of the
   4o6 DHCP Servers.  The server includes 4o6 Server
   Addresses Address Option encapsulated in the
   Advertise and Reply message. messages.  The 4o6 Server
   Addresses Option's format of the option is defined in
   Section 6.3.

5.  New DHCPv6 Messages

   There are two new DHCPv6 messages defined in this document which
   carry DHCPv4 messages between a client and a server using DHCPv6
   protocol: Boot-request-v6 and Boot-reply-v6.  This section describes
   the structures of these messages.

5.1.  Message Types

   The following new message types are defined in this document:

   BOOTREQUESTV6 (TBD):  Identifies a Boot-request-v6 message.  A 4o6
                         DHCP client sends this 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.

   BOOTREPLYV6 (TBD):    Identifies a Boot-reply-v6 message.  A 4o6 DHCP
                         server sends this 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 Boot-request-v6 message.

5.2.  Message Formats

   Both DHCPv6 messages defined in this document share the following

     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)                          .
     |                                                               |

                      Figure 2: Architecture Overview

   msg-type        Identifies message type.  It can be either
                   BOOTREQUESTV6 (TBD) or BOOTREPLYV6 (TBD) which
                   corresponds to the Boot-request-v6 or Boot-reply-v6 Boot-reply-v6,

   flags           Specifies flags which provide additional information
                   required by the server to process a DHCPv4 message
                   encapsulated in Boot-request-v6 Message, message, or required
                   by the client to process DHCPv4 message wrapped encapsulated
                   in Boot-
                   reply-v6 Message. Boot-reply-v6 message.

   options         The options         Options carried by the message and message.  The BOOTP
                   Message Option described in Section 6. 6.1 MUST be
                   carried by the message.

5.3.  Boot-request-v6 Message Flags

   The "flags" field of the Boot-request-v6 is used to carry additional
   information which 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.  Currently the  The "flags"
   field has the following format:

             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 4
             |U|                 Reserved                    |

                  Figure 3: Boot-request-v6 flags format

   U               Unicast Flag.  If it is set to 1, it indicates that the
                   DHCPv4 message encapsulated with the Boot-
                   request-v6 Boot-request-v6
                   message would be sent to a unicast address if it was
                   sent using IPv4.  If this flag is set to 0 0, it
                   indicates that the DHCPv4 message would be sent to
                   broadcast address if it was sent using IPv4.

   Reserved        Bits reserved for future use.  A client which that doesn't
                   implement future extensions using these bits MUST set
                   them to 0.

5.4.  Boot-reply-v6 Message Flags

   This document introduces no flags to be carried in the "flags" field
   of the Boot-reply-v6 message.  They are all reserved for the future
   use.  The 4o6 Server MUST set all bits of this field to 0. 0 and the 4o6
   client MUST ignore the content in this field.

6.  New DHCPv6 Options

6.1.  BOOTP Message Option Format

   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

   The format of the BOOTP Message Option is:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |        OPTION_BOOTP_MSG       |           option-len          |
     |                                                               |
     .                         BOOTP-message                         .
     .                                                               .
     .                                                               .

                   Figure 4: BOOTP Message Option Format

   option-code     OPTION_BOOTP_MSG (TBD) (TBD).

   option-len      Length of BOOTP message message.

   BOOTP-message   The BOOTP message sent by the client or the server.
                   In a Boot-request-v6 message it contains a
                   BOOTREQUEST message sent by a client.  In a Boot-
                   reply-v6 message it contains a BOOTREPLY message sent
                   by a server in response to a client.

6.2.  DHCPv4-over-DHCPv6 Enable Option Format

   The DHCPv4-over-DHCPv6 Enable Option indicates option is sent by the DHCPv6-only
   server to signal that the client SHOULD
   enable use DHCPv4 over DHCPv6 to
   obtain IPv4 configuration.  The server includes this option if it is
   requested by the DHCPv4-over-DHCPv6 function. client.

   The format of the DHCPv4-over-DHCPv6 Enable Option option is:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |  OPTION_DHCP4_O_DHCP6_ENABLE  |           option-len          |
             Figure 5: DHCPv4-over-DHCPv6 Enable Option Format

   option-code     OPTION_DHCP4_O_DHCP6_ENABLE (TBD) (TBD).

   option-len      0

6.3.  4o6 Servers Server Address Option Format

   The 4o6 Servers Server Address Option option carries one or more unicast IPv6
   addresses of the 4o6 Servers. DHCP Server(s).  The DHCPv6-only server includes
   this option if it is requested by the client.

   The format of the 4o6 Servers Server Address Option option is:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     | OPTION_DHCP4_O_DHCP6_SERVERS OPTION_DHCP4_O_DHCP6_SERVER   |           option-len          |
     |                                                               |
     .                        IPv6 Address(es)                       .
     .                                                               .
     .                                                               .

                Figure 6: 4o6 Servers Address Option Format


   option-len      Length of the IPv6 address(es), address(es) carried by the option,
                   i.e.  integer times multiple of 16. 16 octets.

   IPv6 Address    The    One or more IPv6 address(es) addresses of the 4o6 DHCP Server(s).

7.  Use of the Boot-request-v6 Unicast Flag

   A DHCPv4 client conforming to the [RFC2131] may send its DHCPREQUEST
   message to either broadcast or unicast address depending on its
   state.  For example, the client in the RENEWING state will use uses a unicast
   address to contact a DHCPv4 server and to renew its lease.  The client in
   the REBINDING state MUST use 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 can't find out whether the client sent a message
   to a unicast or broadcast address and thus it can't determine the
   client's state.  [RFC5010] introduced the "Flags Suboption" which
   relay agents add to relayed messages to indicate whether broadcast or
   unicast was used by the client.

   The DHCPv4-over-DHCPv6 protocol uses

   In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the server.
   4o6 DHCP Server.  There is no relation between the outer IPv6 address
   and the inner DHCPv4 message.  So the server is not able to know
   whether the DHCPv4 messages should have been sent using broadcast or
   unicast in IPv4 by checking the IPv6 address.  This is similar to the
   case [RFC5010] handled. addressed by the [RFC5010].

   In order to allow the server to determine the client's state, the
   "Unicast" flag is carried in the Boot-request-v6 message.  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 MUST be made based on the
   [RFC2131] and its extensions.

8.  4o6 DHCP Client Behavior

   The DHCP client by default doesn't use DHCPv4-over-DHCPv6 protocol to
   obtain its DHCPv4 configuration.  Client function MUST be disabled by default.  The
   client MUST obtain its IPv6 configuration before it MAY use DHCPv4-over-DHCPv6 using DHCPv4 over
   DHCPv6.  The client that intends to obtain use DHCPv4
   configuration.  If IPv6 configuration is obtained using over DHCPv6 as
   described in [RFC3315], client SHOULD MUST
   request the DHCPv4-over-DHCPv6 Enable Option and SHOULD request the
   4o6 Server Addresses Address Option in the Option Request Option (ORO) to check if it SHOULD use DHCPv4-over-DHCPv6. in every
   Solicit, Request, Renew and Information-request messages.  The 4o6
   DHCP client MUST NOT request the DHCPv4-over-DHCPv6 Enable Option nor
   the 4o6 Server Address Option in the Boot-request-v6 message.

   The DHCPv6 server MAY include these options in the Reply message sent responses to the
   client.  The client determines how to launch enable the DHCPv4-over-
   DHCPv6 DHCPv4-over-DHCPv6
   function based on the presence / absence of these the two options:

   o  If the client doesn't receive the DHCPv4-over-DHCPv6 Enable
      option, it SHOULD MUST NOT enable the DHCPv4-over-DHCPv6 function.  In
      the case where the DHCPv4 over DHCPv6 service is running, the
      client MUST disable the function.

   o  If the client receives the DHCPv4-over-DHCPv6 Enable Option but no
      4o6 Servers Address Option, it SHOULD enable the DHCPv4-over-
      DHCPv6 function, but function and use IPv6 All_DHCP_Relay_Agents_and_Servers
      multicast address to communicate with the servers or relays as
      described above. and relays.

   o  If the client receives both options, it SHOULD enable the DHCPv4
      -over-DHCPv6 function, function and send requests to all the unicast addresses
      conveyed by address(es)
      in the 4o6 Server Addresses Address Option.

   o  If the client is instructed by only receives 4o6 Server Address Option, the client
      MUST ignore the 4o6 Server Address Option and MUST NOT enable the
      DHCPv4-over-DHCPv6 function.

   The client supporting DHCPv4 over DHCPv6 SHOULD use Information
   Refresh Time Option [RFC4242] to refresh the status of DHCPv4-over-
   DHCPv6 service as well as other DHCPv6 configuration data.

   The client signaled by the server to use DHCPv4-over- DHCPv4 over DHCPv6 function it SHOULD generate a
   cease to send DHCPv4 message messages using DHCP protocol described in
   [RFC2131] and use the DHCPv4 over DHCPv6 to obtain request IPv4
   configuration from the 4o6 DHCP Server.  This  The DHCPv4 message is stored
   verbatim in the BOOTP Message Option option carried by the Boot-request-v6
   message.  The client MUST put exactly one BOOTP Message Option option into a
   single Boot-request-v6 message.

   A client

   Client MUST set the Unicast flag as specified follow rules defined in Section 7. 7 when setting Unicast

   If the client has not received a the 4o6 Server Addresses Option option from
   the DHCPv6 server, it transmits the Boot-request-v6 message as
   specified in Section 13 of [RFC3315].  If the client received this
   option, it
   MUST SHOULD send Boot-request-v6 message to all unicast
   addresses listed in the received option.

   When a client receives

   On receiving a Boot-reply-v6 message, it the client MUST look for the
   BOOTP Message Option option within this message.  If this option is not
   found, the Boot-reply-v6 message is discarded.  If the BOOTP Message
   Option is found, presents, the client extracts the DHCPv4 message it contains
   and processes it as described in section 4.4 of [RFC2131].

   DHCP clients are responsible for the retransmission of messages.

   When requesting dealing with IPv4 configuration, the 4o6 DHCP client SHOULD
   follow the normal DHCPv4 retransmission requirements and strategy as
   specified in section 4.1 of [RFC2131].  As a result there  There are no explicit
   transmission parameters associated with a Boot-request-v6 message.

   As the DHCPv4 and DHCPv6 clients are running on the same host, the

   The 4o6 DHCP client MUST implement [RFC4361] to ensure that the
   device correctly identifies itself.

9.  Relay Agent Behavior

   When a DHCPv6 relay agent receives a Boot-request-v6 message, it MUST
   handle the may
   not recognize this message.  It can just forward this message as described in section 4 of

   A DHCPv6 relay agent MUST implement the Relay behaviour described in
   section 20.1.1 of [RFC3315]. in

   Additionally, the DHCPv6 relay agent MAY allow the configuration of a
   dedicated DHCPv4-over-DHCPv6 DHCPv4 over DHCPv6 specific destination addresses, address(es),
   differing from the addresses address(es) of the DHCPv6 only DHCPv6-only server(s).  To
   implement this function, the relay checks the received DHCPv6 message
   type and forwards according to the following logic:

   1.  If the message type is Boot-request-v6, then BOOTREQUESTV6, the DHCPv6 request packet is relayed to
       the configured DHCPv4 aware 4o6 DHCP Server's
       address(es). address(es) in the form of
       normal DHCPv6 packet (i.e. DHCPv6/UDP/IPv6).

   2.  For any other DHCPv6 message type, forward according to section
       20 of [RFC3315].

   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.

10.  4o6 DHCP Server Behavior

   When the server receives a Boot-request-v6 message from a client, it
   searches for a the BOOTP Message Option.  If this option is missing, the  The server discards the packet.
   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

   If the server finds a valid BOOTP Message Option, option, it extracts the
   original DHCPv4 message sent by and the client.  This contents of the "flags" field carried
   in the Boot-request-v6 message is passed and uses them to generate the
   appropriate DHCPv4 server engine, which generates a response (server to the client message).  The response
   is generated as specified described in [RFC2131].  This engine can be implemented as a
   built-in DHCPv4 [RFC2131] with the exception that the
   server function SHOULD use the information carried in the "flags" field of the 4o6 Server,
   Boot-request-v6 message to find out whether the client's message
   would have been sent to the broadcast or it can be a
   separate unicast address if DHCPv4 server instance.  Discussion regarding communication
   protocol was used.  This is useful for the 4o6 Server and a DHCPv4 server engine is out to determine the
   state of scope for
   this document. the client.  The use of the "flags" field is described in
   detail in Section 7.

   When appropriate DHCPv4 response is generated, the 4o6 Server places
   it in the payload of a BOOTP Message Option, which it puts into the
   Boot-reply-v6 message.

   If the Boot-request-v6 message was received directly by the server,
   the Boot-reply-v6 message MUST be unicast from the interface on which
   the original message was received.

   If the Boot-request-v6 message was received in a Relay-forward
   message, the server creates a Relay-reply message with the Boot-
   reply-v6 message in the payload of a Relay Message Option, option, and
   responds as described in section 20.3 of [RFC3315].

11.  Security Considerations
   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
   not seen to be greater
   no more severe than that with the current DHCPv4 and DHCPv6 practice.

   There are chances that a rogue DHCPv6 server may reply with a 4o6
   Server Address Option containing duplicated unicast IPv6 addresses,
   which can cause an amplification attack.  To avoid this, the client
   MUST check if there are repeated IPv6 addresses in a 4o6 Server
   Address Option when receiving one.  The client MUST ignore those
   duplicated unicast IPv6 addresses.

12.  IANA Considerations

   IANA is requested to allocate three DHCPv6 option codes for use by
   OPTION_DHCP4_O_DHCP6_SERVERS, and two DHCPv6 message type codes for

13.  Contributors List

   Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen
   and Cong Liu, for their great contributions to the draft.

14.  References

14.1.  Normative References

              Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
              Messages", draft-ietf-dhc-dhcpv6-unknown-msg-02 (work in
              progress), September 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4242]  Venaas, S., Chown, T., and B. Volz, "Information Refresh
              Time Option for Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 4242, November 2005.

   [RFC4361]  Lemon, T. and B. Sommerfeld, "Node-specific Client
              Identifiers for Dynamic Host Configuration Protocol
              Version Four (DHCPv4)", RFC 4361, February 2006.

14.2.  Informative References


              Cui, Y., Wu, P., Wu, J., Sun, Q., and T. Lemon, "DHCPv4 over IPv6
              Transport", draft-ietf-dhc-dhcpv4-over-ipv6-07 "Handling Unknown DHCPv6
              Messages", draft-ietf-dhc-dhcpv6-unknown-msg-03 (work in
              progress), September November 2013.

   [RFC5010]  Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host
              Configuration Protocol Version 4 (DHCPv4) Relay Agent
              Flags Suboption", RFC 5010, September 2007.

Authors' Addresses

   Qi Sun
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084

   Phone: +86-10-6278-5822
   Email: sunqi@csnet1.cs.tsinghua.edu.cn

   Yong Cui
   Tsinghua University
   Department of Computer Science,
   Tsinghua University
   Beijing  100084

   Phone: +86-10-6260-3059
   Email: yong@csnet1.cs.tsinghua.edu.cn

   Marcin Siodelski
   950 Charter Street
   Redwood City, CA  94063

   Phone: +1 650 423 1431
   Email: msiodelski@gmail.com

   Suresh Krishnan

   Email: suresh.krishnan@ericsson.com
   Ian Farrer
   Deutsche Telekom AG
   GTN-FM4,Landgrabenweg 151
   Bonn, NRW  53227

   Email: ian.farrer@telekom.de