Dynamic Allocation of Shared IPv4 Addresses using DHCPv4 over DHCPv6
draft-farrer-dhc-shared-address-lease-00

Abstract

This memo describes an update to [RFC2131], which enables the dynamic leasing of shared IPv4 addresses and layer 4 source ports to DHCPv4 over DHCPv6 clients [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. Shared addressing allows a single IPv4 address to be allocated to multiple, active clients simulataneously. Clients sharing the same address are then differentiated by unique L4 source ports.

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 December 27, 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
• 2. Functional Overview
• 3. Client-server Interaction
• 3.1. Allocating a Shared, Dynamic IPv4 Address
• 3.2. Reusing a Previously Allocated Shared, Dynamic IPv4 address
• 4. Client Usage of a Shared Address
• 5. Additional Changes to [RFC2131] Behaviour
• 6. DHCPv4 Port Parameters Option
• 7. Specfic Behaviour for Softwire Clients
• 8. DHCPv4 over DHCPv6 Source Address Option
• 9. Security Considerations
• 10. IANA Considerations
• 11. Acknowledgements
• 12. References
• 12.1. Normative References
• 12.2. Informative References
• Author's Address

1. Introduction

[I-D.ietf-dhc-dhcpv4-over-dhcpv6] introduces a "Unified Server" - a DHCP server capable of servicing both DHCPv6 [RFC3315] and DHCPv4 over DHCPv6 requests. This enables the provisioning of DHCPv4 based configuration to IPv6 connected clients over IPv6 only transport networks.

One of the benefits of the DHCPv4 over DHCPv6 based approach is that it allows the dynamic leasing of IPv4 addresses to clients, based on existing mechanisms for address lease management available in DHCPv4 servers. This can make much more efficient use of remaining public IPv4 addresses than static pre-allocation based approaches as only IPv4 clients which are currently active need to be allocated addresses.

Shortages of available public IPv4 addresses mean that it is not always possible for operators to allocate a full IPv4 address to every active customer simultaneously. This problem may be particularly acute whilst the operator is in the migration phase from a native IPv4 network to a native IPv6 network with IPv4 provided as an overlay service. Such migrations are likely to increase the requirement on public IPv4 addresses so that both existing and transition networks can be provided for.

IPv4 address sharing provides a way of easing this problem. A shared IP address is a single IPv4 address which is allocated to a number of clients simultaneously. The clients differentiate themselves through the use of layer 4 source ports, which are unique for each client sharing a single IPv4 address, known as a Port Set ID (PSID).

The client will generally utilize these restricted source ports by implementing a NAPT44 function, translating traffic from the original source address and unrestricted port range to the allocated shared IPv4 address and unique restricted port range.

This technique is also referred to as "extended" or "A+P" addressing [RFC6346].

Due to the nature of address sharing in this manner, it is only suitable for some very specific architectures, such as those described in [I-D.ietf-softwire-map] and [I-D.ietf-softwire-lw4over6]. Use of shared addressing in other, more traditional deployment architectures must be avoided due to the fundamental incompatibilities of assigning a the same /32 IPv4 address to multiple clients such as when they are attached to the same layer 2 segment. Some rules for the use of the allocated shared dynamic address are provided in Section 4 below.

[RFC2131] describes DHCPv4, providing a method for dynamically allocating IPv4 addresses to clients based on three different mechanisms:

• Automatic Address Allocation
• Dynamic Address Allocation
• Manual Address Allocation

This memo describes how the dynamic allocation mechanism can be adapted for allocating shared IPv4 addresses for use by DHCPv4 over DHCPv6 clients and Unified Servers. The approach is referred to as "shared, dynamic" addressing throughout this memo.

2. Functional Overview

From a functional perspective, shared, dynamic allocation by the unified server is quite similar to the normal DHCPv4 server dynamic allocation process. The underlying difference is that the unified server MAY allocate the same IPv4 address to more than one DHCPv4 over DHCPv6 client simultaneously, providing that each address allocation also includes a range of layer 4 source ports unique to that address (i.e. each PSID may only be allocated once per /32 address).

To enable this, the DHCPv4 over DHCPv6 client needs to be extended to implement OPTION_PORTPARAMSV4 (described below). This is used to indicate to the Unified server that it is capable of supporting shared, dynamic addressing and also for conveying the allocated PSID.

The server must be extended to implement OPTION_PORTPARAMSV4 so that clients able to support shared, dynamic address leasing can be identified and so that shared, dynamic addresses can be allocated and their leases maintained. The server must also manage unique client leases based on the address and PSID tuple, instead of just IPv4 address.

3. Client-server Interaction

The following sections describe the changes to the client and server necessary to implement dynamic, shared address allocation.

3.1. Allocating a Shared, Dynamic IPv4 Address

Section 3.1 of [RFC2131] describes the client-server interaction for allocating an IPv4 address. The process described below detail the required changes for the dynamic, shared addressing mechanism.

The following message flow is transported within the DHCPv6 OPTION_BOOTP_MSG message.

1. The client constructs its DHCPv4 DHCPDISCOVER message (transported within the DHCPv6 BOOTPRELAYV6 message). The DHCPDISCOVER message MUST include the following options:
   • A client Identifier (constructed as per [RFC4361]
   • OPTION_PORTPARAMSV4 (described below)

   The client MAY insert a non-zero value in the PSID-Len field within OPTION_PORTPARAMSV4 to indicate the preferred size of the restricted port range allocation to the unified server.

2. Each Unified server which receives the DHCPDISCOVER message containing OPTION_PORTPARAMSV4 within the BOOTPRELAYV6 message may respond with a DHCPOFFER message which contains an available IPv4 address in the 'yiaddr' field. The response MUST also include OPTION_PORTPARAMSV4 containing a restricted port-range. If the received OPTION_PORTPARAMSV4 field contains a non-zero PSID-Len field, the Unified server MAY allocate a port set of the requested size to the client (depending on policy).
3. The client evaluates all received DHCPOFFER messages and selects one based on the configuration parameters received (e.g. the size of the offered port set). The client then sends a DHCPREQUEST containing a server identifier and the corresponding OPTION_PORTPARAMSV4 received in the DHCPOFFER message.
4. The server identified in the DHCPREQUEST message (via the siaddr field) creates a binding for the client. The binding includes the client identifier, the IPv4 address and the PSID. These parameters are used by both the server and the client to identify the lease referred to in any future DHCP messages. The server responds with a DHCPACK message containing the configuration parameters for the requesting client.
5. The client receives the DHCPACK message with the configuration parameters. The client MUST NOT perform a final check on the address, such as ARPing for a duplicate allocated address.
6. If the client chooses to relinquish its lease by sending a DHCPRELEASE message, the client MUST include the original client identifier, the leased network address and the allocated restricted source ports included in OPTION_PORTPARAMSV4.

3.2. Reusing a Previously Allocated Shared, Dynamic IPv4 address

If the client remembers the previously allocated address and restricted port range, then the process described in section 3.2 of [RFC2131] must be followed. OPTION_PORTPARAMSV4 MUST be included in the message flow, with the client's requested port set being included in the DHCPDISCOVER message.

4. Client Usage of a Shared Address

As a single IPv4 address is being shared between a number of different clients, the allocated shared address is only suitable for certain functions. The client MUST implement a function to ensure that only the allocated layer 4 ports of the shared IPv4 address are used for sourcing new connections.

The client MUST apply the following rules for any traffic to or from the shared /32 IPv4 address:

• Only port-aware protocols MUST be used.
• All connections originating from the shared IPv4 address MUST use a source port taken from the allocated restricted port range.
• The client MUST NOT accept inbound connections with destination ports outside of the allocated restricted port range.

In order to prevent addressing conflicts which could arise from the allocation of the same IPv4 addreses, the client MUST NOT configure the received restricted IPv4 address on-link.

In the event that the DHCPv4 over DHCPv6 configuration mechanism fails for any reason, the client MUST NOT configure an IPv4 link-local address [RFC3927](taken from the 169.254.0.0/16 range).

The mechanism by which a client implements these rules is outside of the scope of this document.

5. Additional Changes to [RFC2131] Behaviour

The following change to the behaviour described in [RFC2131] is also necessary in order to implement dynamic shared address allocation.

Section 2.2

The client MUST NOT probe a newly received IPv4 address (e.g. with ARP) to see if it is in use by another host.

6. DHCPv4 Port Parameters Option

The Port Paramaters Option for DHCPv4 specifies the restricted set of layer 4 source ports that are necessary to dynamically allocate a shared address. The option uses the same fields as the MAP Port Parameters Option described in Section 4.4 of [I-D.ietf-softwire-map-dhcp], implemented as a DHCPv4 option. This is to maintain compatibility with existing implementations.

The construction and usage of OPTION_PORTPARAMSV4 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-code   |  Length       |    offset     |   PSID-Len    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              PSID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      

     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_DHCPV4_O_DHCPV6_SADDR  |          Length               |
    +-------------------------------+-------------------------------+
    .            cipv6-prefix-hint (variable length)                .
    +---------------------------------------------------------------+
    | cipv6-hintlen |          cipv6-bound-prefix                   .
    +---------------+          (variable length)    +---------------+
    .                                               |cipv6-boundlen |
    +---------------------------------------------------------------+