Skip to main content

DHCPv4 over DHCPv6 Transport
draft-scskf-dhc-dhcpv4-over-dhcpv6-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Qi Sun , Yong Cui , Marcin Siodelski , Suresh Krishnan , Ian Farrer
Last updated 2013-03-22
Replaced by draft-ietf-dhc-dhcpv4-over-dhcpv6, RFC 7341
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-scskf-dhc-dhcpv4-over-dhcpv6-00
Network Working Group                                             Q. Sun
Internet-Draft                                                    Y. Cui
Intended status: Standards Track                     Tsinghua University
Expires: September 23, 2013                                 M. Siodelski
                                                                     ISC
                                                             S. Krishnan
                                                                Ericsson
                                                               I. Farrer
                                                     Deutsche Telekom AG
                                                          March 22, 2013

                      DHCPv4 over DHCPv6 Transport
                 draft-scskf-dhc-dhcpv4-over-dhcpv6-00

Abstract

   This document describes a mechanism for obtaining IPv4 parameters in
   IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport.

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 September 23, 2013.

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

Sun, et al.            Expires September 23, 2013               [Page 1]
Internet-Draft             DHCPv4 over DHCPv6                 March 2013

   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 . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   3
   5.  BOOTP Message Option Format . . . . . . . . . . . . . . . . .   4
   6.  Client Behavior . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Relay Agent Behavior  . . . . . . . . . . . . . . . . . . . .   5
   8.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . .   5
   9.  Contributors List . . . . . . . . . . . . . . . . . . . . . .   5
   10. IANA Consideration  . . . . . . . . . . . . . . . . . . . . .   6
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     11.2.  Informative References . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   As the migration to IPv6 continues to happen, IPv6 only networks will
   become more prevalent, and there will be a need to provide IPv4 as a
   service over these IPv6 only networks.  Along with the ability to
   provide IPv4 addressing, there might also be a need to provide other
   IPv4 configuration parameters such as addresses for reaching IPv4
   services.  There are several approaches possible to provision such
   information and this document describes one such approach.

2.  Requirements Language

   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 [RFC2119].

3.  Terminology

   This document makes use of the following terms

   o  BOOTREQUESTV6 (TBD): A new type of DHCPv6 Client/Server message
      defined in this document.  A client sends to a server a
      BOOTREQUESTV6 message, which contains a BOOTP Message Option.
      Each BOOTP Message Option contains a BOOTREQUEST message that
      client used to request IPv4 configuration parameters from the
      server.

Sun, et al.            Expires September 23, 2013               [Page 2]
Internet-Draft             DHCPv4 over DHCPv6                 March 2013

   o  BOOTREPLYV6 (TBD): A new type of DHCPv6 Client/Server message
      defined in this document.  A server sends a BOOTREPLYV6 message,
      which contains a BOOTP Message Option, in response to the
      BOOTREQUESTV6 message received from a client.  Each BOOTP Message
      Option, wrapped in a BOOTREPLYV6 message contains a BOOTREPLY
      message, which is the response to the corresponding BOOTREQUEST
      message in BOOTREQUESTV6 message received from the client.

4.  Architecture Overview

   The architecture described in this document addresses the typical use
   case, where the DHCP client's uplink supports IPv6 only and the
   Service Provider's network supports IPv6 and limited IPv4 services
   which need to be accessed by the client over IPv6 only network.
   Although, the purpose of this document is to address the problem of
   communication between DHCPv4 client and DHCPv4 server, the mechanisms
   it describes do not restrict the transported types of messages to
   DHCPv4.  The BOOTP messages can be transported as well.

   The DHCP clients can be running on CPE devices or end hosts, etc.  At
   the time this document is written, DHCP clients on CPE devices are
   relatively easier to be modified comparing to those on end hosts.  So
   this document takes the CPE as an example for describing the
   mechanism.  This doesn't preclude end hosts from implementing the
   mechanism in the future.

   This mechanism works by carrying encapsulated DHCPv4 messages over
   DHCPv6 messages.  One possible architecture detailing the usage of
   this mechanism is illustrated in the Figure 1.  In this architecture,
   the client is a DHCP client which can send and receive BOOTP message
   using a new type of DHCPv6 message with a new type of DHCPv6 option.
   The DHCPv6 message is called BOOTREQUESTV6 message.  The new option
   is called BOOTP Message Option.  The format of the option is
   described in Section 5.  The client sends all its DHCPv6 packets,
   including the DHCPv4 over DHCPv6 packets, to the well-known
   All_DHCP_Relay_Agents_and_Servers multicast address on the DHCPv6
   server port 547.

   The DHCPv6 packet can be transmitted either via Relay Agents or
   directly to the server.  The server is referred in this document as
   "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.  Client receives
   response on the port 546.

Sun, et al.            Expires September 23, 2013               [Page 3]
Internet-Draft             DHCPv4 over DHCPv6                 March 2013

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

                      Figure 1: Architecture Overview

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

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

       option-code    OPTION_BOOTP_MSG (TBD)

       option-len     Length of BOOTP-message

       BOOTP-message The BOOTP message sent by the client or the
                     server. In a BOOTREQUESTV6 message, contains a
                     BOOTREQUEST message sent by client. In a
                     BOOTREPLYV6 message, contains a BOOTREPLY message
                     sent by server in response to a client.

                  Figure 2: DHCPv4 Message Option Format

6.  Client Behavior

   When the client requires an IPv4 address and/or other IPv4

Sun, et al.            Expires September 23, 2013               [Page 4]
Internet-Draft             DHCPv4 over DHCPv6                 March 2013

   configuration parameters, it MUST generate a DHCPv4 message to obtain
   them from a server.  This message is stored verbatim in the BOOTP
   Message Option carried by BOOTREQUESTV6 message.  Client MUST put
   exactly one BOOTP Message Option in a single BOOTREQUESTV6 message.
   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 [RFC3315].

   When client receives a BOOTREPLYV6 message, it MUST look for the
   BOOTP Message Option in this message.  If this option is not found,
   the BOOTREPLYV6 message is discarded.  If BOOTP Message Option is
   found, client extracts the DHCPv4 message it contains and processes
   as described in section 4.4 of [RFC2131].

7.  Relay Agent Behavior

   If the relay agent receives a BOOTREQUESTV6 message, it MUST handle
   the message as described in section 20.1.1 of [RFC3315].

8.  Server Behavior

   If the server receives a BOOTREQUESTV6 message from a client, it
   searches for BOOTP Message Option.  If this option is missing, the
   server discards the packet.  Server MAY choose to notify an
   administrator about reception of malformed packet.  The exact way how
   server notifies an administrator is out of the scope of this document

   If server finds the valid BOOTP Message Option, it extracts the
   original DHCPv4 message sent by the client.  This message is in turn
   passed to the DHCPv4 server engine, which creates a response to the
   client's message as specified in [RFC2131].  Server stores the DHCPv4
   response message, produced by the engine, in a payload of BOOTP
   Message Option, which it stores in the BOOTREPLYV6 message.  If the
   BOOTREQUESTV6 message was received directly by the server the
   BOOTREPLYV6 message MUST be unicast through the interface on which
   the original message was received.

   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 analogously to other types
   of DHCPv6 messages as described in [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.

9.  Contributors List

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

Sun, et al.            Expires September 23, 2013               [Page 5]
Internet-Draft             DHCPv4 over DHCPv6                 March 2013

10.  IANA Consideration

   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.

11.  References

11.1.  Normative References

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

11.2.  Informative References

   [I-D.ietf-dhc-dhcpv4-over-ipv6]
              Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
              Transport", draft-ietf-dhc-dhcpv4-over-ipv6-06 (work in
              progress), March 2013.

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

Authors' Addresses

   Qi Sun
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

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

   Yong Cui
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

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

Sun, et al.            Expires September 23, 2013               [Page 6]
Internet-Draft             DHCPv4 over DHCPv6                 March 2013

   Marcin Siodelski
   950 Charter Street
   Redwood City, CA  94063
   USA

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

   Suresh Krishnan
   Ericsson

   Email: suresh.krishnan@ericsson.com

   Ian Farrer
   Deutsche Telekom AG
   GTN-FM4,Landgrabenweg 151
   Bonn, NRW  53227
   Germany

   Email: ian.farrer@telekom.de

Sun, et al.            Expires September 23, 2013               [Page 7]