| Network Working Group | Q. Sun |
| Internet-Draft | Y. Cui |
| Intended status: Standards Track | Tsinghua University |
| Expires: December 25, 2016 | M. Siodelski |
| ISC | |
| S. Krishnan | |
| Ericsson | |
| I. Farrer | |
| Deutsche Telekom AG | |
| 2013 |
DHCPv4 over DHCPv6 Transport
draft-scskf-dhc-dhcpv4-over-dhcpv6-00
This document describes a mechanism for obtaining IPv4 parameters in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport.
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 December 25, 2016.
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.
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.
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].
This document makes use of the following terms
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.
_____________ _____________
/ \ / \
| | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| DHCP | network | DHCP | network | Unified |
| Client +---------+ Relay Agent +---------+ Server |
| (on CPE) | | | | |
+--------+-+ +-+-----------+-+ +-+--------+
| | | |
\_____________/ \_____________/
Figure 1: Architecture Overview
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
When the client requires an IPv4 address and/or other IPv4 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].
If the relay agent receives a BOOTREQUESTV6 message, it MUST handle the message as described in section 20.1.1 of [RFC3315].
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.
Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen and Cong Liu, for their great contributions to the draft.
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.
| [RFC2131] | Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, 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, DOI 10.17487/RFC3315, July 2003. |
| [I-D.ietf-dhc-dhcpv4-over-ipv6] | Cui, Y., Wu, P., Wu, J., Lemon, T. and Q. Sun, "DHCPv4 over IPv6 Transport", Internet-Draft draft-ietf-dhc-dhcpv4-over-ipv6-09, April 2014. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |