Provisioning IPv4 Configuration Over IPv6 Only Networks
draft-ietf-dhc-v4configuration-00

Abstract

As IPv6 becomes more widely adopted, some service providers are taking the approach of deploying IPv6 only networks, without dual-stack functionality for IPv4. However, access to IPv4 based services is still an ongoing requirement and approaches such as IPv4-in-IPv6 softwire tunnels are being developed to meet this need.

In order to provision end-user's hosts with the necessary IPv4 configuration, a number of different mechanisms have been proposed. This memo discusses the benefits and drawbacks of each, with the aim of recommending a single approach as the basis for future work.

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

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 November 14, 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 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
• 1.1. Overview of IPv4 Parameter Configuration Approaches
• 1.2. DHCPv4o6 Based Provisioning - Functional Overview
• 1.3. DHCPv6 Based Provisioning - Functional Overview
• 1.4. DHCPv4oSW Based Provisioning - Functional Overview
• 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview
• 2. Requirements for the Solution Evaluation
• 3. Comparison of the Four Approaches
• 3.1. Pros and Cons of the Different Approaches
• 3.1.1. DHCPv4o6 Based Provisioning
• 3.1.2. DHCPv6 Based Provisioning
• 3.2. DHCPv4oSW Based Provisioning
• 3.2.1. Pros
• 3.2.2. Cons
• 3.3. DHCPv4oDHCPv6 Based Provisioning
• 3.3.1. Pros
• 3.3.2. Cons
• 4. Conclusion
• 5. IANA Considerations
• 6. Security Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

A service provider with an IPv6-only network must also be able to provide customers with access to the Internet and other services over IPv4. Softwire based IPv4-in-IPv6 tunneling mechanisms are an obvious example of this, such as the ones described in:

• [I-D.ietf-softwire-lw4over6]
• [I-D.ietf-softwire-map]
• [I-D.ietf-softwire-unified-cpe]

A general trend here is to relocate NAT44 functionality and IPv4 address sharing from the centralized tunnel concentrator to the CPE in order to achieve better scalability. This results in the need to provision a number of configuration parameters to the CPE, such as the external public IPv4 address and a restricted port-range to use for NAT.

In order to configure customer's devices for softwire functionality, a dynamic provisioning mechanism is necessary. In IPv4 only networks, DHCPv4 has often been used to provide configuration, but in an IPv6 only network, DHCPv4 messages cannot be transported natively.

Although softwire mechanisms are currently the only use-case for dhcp based configuration of IPv4 parameters in IPv6 only networks, a suitable approach must not be limited to only supporting softwire configuration.

This document compares four different approaches which have been proposed for resolving this problem.

1.1. Overview of IPv4 Parameter Configuration Approaches

In order to resolve the problem described above, the following approaches for transporting IPv4 configuration parameters have been suggested:

1. Adapt DHCPv4 format messages to be transported over IPv6 as described in [I-D.ietf-dhc-dhcpv4-over-ipv6]. For brevity, this is referred to as DHCPv4o6.
2. Extend DHCPv6 with new options for IPv4 configuration, such as [I-D.ietf-softwire-map-dhcp] describes.
3. Use DHCPv6 as above for external IPv4 address and source port configuration. Use DHCPv4 over IPv4 messages within an IPv6 softwire for configuring additional parameters. This is referred to as DHCPv4oSW.
4. Use DHCPv4 format messages, transporting them within a new DHCPv6 message type as described in [I-D.scskf-dhc-dhcpv4-over-dhcpv6]. This is referred to as DHCPv4oDHCPv6.

At the time of writing, working examples of the first two approaches have been developed and successfully tested in several different operators networks. The third and fourth methods are still theoretical.

The following sections provide more detail for each approach.

1.2. DHCPv4o6 Based Provisioning - Functional Overview

In order to receive IPv4 configuration parameters, IPv4-only clients initiate and exchange DHCPv4 messages with the DHCPv4 server. In order adapt this to an IPv6-only network, an existing DHCPv4 client implements a 'Client Relay' (CRA) function, which takes DHCPv4 messages and puts them into UDPv6 and IPv6.

As the mechanism involves unicast based communications, the IPv6 address of the server must be provisioned to the client. This option is described in [I-D.mrugalski-softwire-dhcpv4-over-v6-option].

The DHCPv4o6 server must either provide an IPv6 interface to the client, or an intermediary 'Transport Relay Agent' device can act as the gateway between the IPv4 and IPv6 domains.

For the dynamic allocation of IPv4 addresses, the DHCPv4o6 server needs to be extended to support the new functionality, such as storing the IPv6 address of DHCPv4o6 clients. The CRA6ADDR option must also be implemented.

This approach currently uses functional elements for ingress and egress of the IPv6-only transport domain--the CRA on the host and the TRA or TSV on the server. As a result, this approach has sometimes been referred to as a tunneling approach. However, relay agent encapsulation is not a tunnel, since it carries only DHCP traffic; it would be more accurate to describe it as an encapsulation.

It is worth noting that there is no technical reason for using relay encapsulation for DHCPv4o6; this approach was taken because the authors of the draft originally imagined that it might be used to provide configuration information for an unmodified DHCPv4 client. However, this turns out not to be a viable approach: in order for this to work, there would have to be IPv4 routing on the local link to which the client is connected. In that case, there's no need for DHCPv4o6.

Given that this is the case, there is no technical reason why DHCPv4o6 can't simply use the IPv6 transport directly, without any relay encapsulation. This would greatly simplify the specification and the implementation, and would still address the requirements stated in this document.

[I-D.ietf-dhc-dhcpv4-over-ipv6] decribes this solution in detail.

The protocol stack is as follows:

DHCPv4/UDPv6/IPv6

1.3. DHCPv6 Based Provisioning - Functional Overview

In this approach, DHCPv6 would be extended with new DHCPv6 options for configuring all IPv4 based services and functions. Any DHCPv4 options needed by IPv4 clients connected to the IPV6 network are updated as new DHCPv6 native options carrying IPv4 configuration parameters.

At the time of writing, it is not known how many such options would need to be ported from DHCPv4 to DHCPv6.

An example of this approach is described in [I-D.ietf-softwire-map-dhcp], where a DHCPv6 message is used to convey the parameters necessary for IPv4 in IPv6 softwire configuration.

The protocol stack is as follows:

DHCPv6/UDPv6/IPv6

1.4. DHCPv4oSW Based Provisioning - Functional Overview

In this approach, the configuration of IPv4 address and source ports (if required) is carried out using DHCPv6 as described in section 1.3 above. Any additional IPv4 configuration parameters which are required are then provisioned using a DHCPv4 messages transported within IPv6 in the configured softwire in the same manner as any other IPv4 based traffic.

On receipt at the tunnel concentrator (e.g. MAP Border Router or a Lightweight 4over6 lwAFTR), the DHCPv4 message removed from the softwire and forwarded to the DHCPv4 server in the same way as any other IPv4 packet is handled.

As the client is already configured with its external IPv4 address and source ports (using DHCPv6), the messages exchanged between the DHCPv4 client and server would be strictly DHCPINFORM/DHCPACK messages, for the configuration of additional IPv4 parameters. Broadcast based DHCPDISCOVER messages can not be transported as they are not compatible with the softwire architecture.

For this approach to function, a mechanism for the DHCPv4 client to learn the IPv4 address of the DHCPv4 server is needed. This could be done by defining a well-known IPv4 address for the DHCPv4 server, implementing a DHCPv4 relay function within the tunnel concentrator or other configuration methods.

From a transport perspective, the key difference between this method and DHCPv4o6 (described above) is that here, the DHCPv4 message is put into UDPv4 and IPv4 and then put into the IPv6 softwire, instead of directly placing the DHCPv4 message into UDPv6 and IPv6.

Currently, this approach is only theoretical and does not have a corresponding Internet Draft providing more detail.

The protocol stack that would be used for obtaining additional IPv4 configuraion is as follows:

DHCPv4/UDPv4/IPv4/IPv6

1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview

[I-D.scskf-dhc-dhcpv4-over-dhcpv6] describes the transport of DHCPv4 messages within two new DHCPv6 messages types: BOOTREQUESTV6 and BOOTREPLYV6. These messages types must be implemented in both the DHCPv4oDHCPv6 client and server.

In this approach, the configuration of stateless IPv4 addresses and source ports (if required) is carried out using DHCPv6 as described in section 1.3 above. Dynamic IPv4 addressing, and/or any additional IPv4 configuration, is provided using DHCPv4 messages carried (without IPv4/UDPv4 headers) within a new OPTION_BOOTP_MSG DHCPv6 option.

OPTION_BOOTP_MSG enables the client and server to send BOOTP/DHCPv4 messages verbatim across the IPv6 network. When a DHCPv4oDHCPv6 server receives a DHCPv6 request containing OPTION_BOOT_MSG within a BOOTREQUESTV6 message, it passes it to the DHCPv4 server engine. Likewise, the DHCPv4 server place its DHCPv4 response in the payload of OPTION_BOOTP_MSG and puts this into a BOOTPRPLYV6 message.

As the DHCPv4 messages are carried within DHCPv6 multicast messages, using the All_DHCP_Relay_Agents_and_Servers, they can be relayed in exactly the same way as any other DHCPv6 multicasted message. Optionally, DHCPv6 relays could be updated so that they forward the BOOTREQUESTV6 message to a different destination address, allowing for the separation of DHCPv4 and DHCPv4 provisioning infrastructure.

The protocol stack used for obtaining dynamic v4 addressing or additional IPv4 configuraion is as follows:

DHCPv4/DHCPv6/UDPv6/IPv6

2. Requirements for the Solution Evaluation

The following requirements have been defined for the evalution of the different approaches:

1. Minimize the amount of work necessary to implement the solution through re-use of existing standards and implementations as much as possible.
2. Provide a method of supporting all existing DHCPv4 options so that they can be utilised without the need for further standardation.
3. Allow for the dynamic leasing of IPv4 addresses to clients. This allows for more efficient use of limited IPv4 resources.
4. Enable the separation of IPv4 and IPv6 host configuration.
5. Avoid leaving legacy IPv4 options in DHCPv6.
6. Provide a flexible architecture to give operators the option of only deploying the functional elements necessary for their specific requirements.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

3. Comparison of the Four Approaches

The table below shows a comparison of the different approaches against the solution requirements described above.