DHC WG                                                         I. Farrer
Internet-Draft                                       Deutsche Telekom AG
Updates: 2131 (if approved)                                June 25, 2013
Intended status: Standards Track
Expires: December 27, 2013

  Dynamic Allocation of Shared IPv4 Addresses using DHCPv4 over DHCPv6


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

Farrer                  Expires December 27, 2013               [Page 1]

Internet-Draft    DHCPv4oDHCPv6 Shared Address Leasing         June 2013

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

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

   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

Farrer                  Expires December 27, 2013               [Page 2]

Internet-Draft    DHCPv4oDHCPv6 Shared Address Leasing         June 2013

   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

   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

   o  Automatic Address Allocation
   o  Dynamic Address Allocation
   o  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

Farrer                  Expires December 27, 2013               [Page 3]

Internet-Draft    DHCPv4oDHCPv6 Shared Address Leasing         June 2013

   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

   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

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

Farrer                  Expires December 27, 2013               [Page 4]

Internet-Draft    DHCPv4oDHCPv6 Shared Address Leasing         June 2013

       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:

   o  Only port-aware protocols MUST be used.
   o  All connections originating from the shared IPv4 address MUST use
      a source port taken from the allocated restricted port range.

Farrer                  Expires December 27, 2013               [Page 5]

Internet-Draft    DHCPv4oDHCPv6 Shared Address Leasing         June 2013

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

                  Figure 1: DHCPv4 Port Parameters Option

   o  option-code: OPTION_PORTPARAMSV4 (TBA)
   o  option-length: 3
   o  offset: (PSID offset) 8 bits long field that specifies the numeric
      value for the MAP algorithm's excluded port range/offset bits
      (A-bits), as per section 5.1.1 in [I-D.ietf-softwire-map].

Farrer                  Expires December 27, 2013               [Page 6]

Internet-Draft    DHCPv4oDHCPv6 Shared Address Leasing         June 2013

      Allowed values are between 0 and 16, with the default value being
      6 for a MAP client.  This parameter is unused by a Lightweight
      4over6 client and should be set to 0.
   o  PSID-len: Bit length value of the number of significant bits in
      the PSID field. (also known as 'k').  When set to 0, the PSID
      field is to be ignored.  After the first 'a' bits, there are k
      bits in the port number representing valid of PSID.  Subsequently,
      the address sharing ratio would be 2^k.
   o  PSID: Explicit 16-bit (unsigned word) PSID value.  The PSID value
      algorithmically identifies a set of ports assigned to a CE.  The
      first k-bits on the left of this 2-octets field is the PSID value.
      The remaining (16-k) bits on the right are padding zeros.

   [I-D.ietf-softwire-map] (Section 5.1) provides a full description of
   how the PSID is interpreted by the client.

   When receiveing the Port Parameters option with an explicit PSID, the
   client MUST use apply this PSID to the interface being configured by
   DHCPv4 over DHCPv6.

7.  Specfic Behaviour for Softwire Clients

   [DISCUSSION NOTE: Should the following section be moved into a
   separte draft as it is more softwire specific?]

   Current mechanisms suitable for extending to incorporate dynamic,
   shared IPv4 addressing include [I-D.ietf-softwire-map] and
   [I-D.ietf-softwire-lw4over6].  For these mechanisms to function, the
   operator needs information about the clients allocated IPv4 address,
   PSID and also the /128 IPv6 prefix which the client will use as the
   IPv4 in IPv6 tunnel endpoint.  This binding information is used by
   other functional elements in the operator's network (e.g. a softwire
   tunnel concentrator) for correctly routing traffic to and from

   For the shared, dynamic address allocation model, a two-way
   communication model is necessary so that the Unified Server can
   indicate to the client the preferred prefix to use for binding the
   received IPv4 configuration and sourcing tunnel traffic.

   As the Unified server is managing the leasing of DHCPv4 to clients,
   it holds the most accurate IPv4 lease information available in the
   network.  It follows that the unified server should also hold
   information about the /128 IPv6 prefixes in use by active clients as
   tunnel endpoints, so that the unified server contains a single
   comprehensive dynamic IPv4/IPv6 binding table.

Farrer                  Expires December 27, 2013               [Page 7]

Internet-Draft    DHCPv4oDHCPv6 Shared Address Leasing         June 2013

   To achieve this, the client also needs to inform the Unified server
   of the /128 prefix that it has bound the IPv4 configuration to.

   To provide this function, the DHCPV4oDHCPv6 client MAY implement
   OPTION_DHCPV4_O_DHCPV6_SADDR (defined below).  This option is
   included by the client within OPTION_BOOTP_MSG messages and is used
   alongside the DHCPv4 request process.

   The option comprises of two IPv6 prefixes (with associated prefix
   length fields):

   cipv6-prefix-hint  Sent by the server to indicate to the client the
                      preferred prefix to bind IPv4 configuration to.
                      If this field contains a prefix, the client MUST
                      perform a longest prefix match betweeen cipv6
                      -prefix-hint and all prefixes configured on the
                      device.  The selected prefix MUST then be used to
                      bind the received IPv4 configuration to.  If this
                      field is left blank, then the client MAY select
                      any valid IPv6 prefix.
   cipv6-bound-prefix Used by the client to inform the Unified Server of
                      the IPv6 prefix that it has bound the IPv4
                      configuration to.  This SHOULD be a /128 prefix
                      configured on the client.

   If used, this option MUST be present within all future
   OPTION_BOOT_MSG transactions between the client and the server.

   The message flow for this process (aligned to the DHCPv4 address
   allocation process) is as follows:

   |    DHCPv4 | cipv6-prefix- | cipv6-hin | cipv6-bound- | cipv6-boun |
   |   Message |      hint     |    tlen   |    prefix    |    dlen    |
   | DHCPDISCO |     blank     |   blank   |    blank     |   blank    |
   |       VER |               |           |              |            |
   | --------- | ------------- | --------- |  ---------   | ---------- |
   | DHCPOFFER |   Preferred   | Preferred |    blank     |   blank    |
   |           |     prefix    |   prefix  |              |            |
   |           |               |   Length  |              |            |
   | --------- | ------------- | --------- |  ---------   | ---------- |
   | DHCPREQUE |   Preferred   | Preferred | Bound prefix |   Bound    |
   |        ST |     prefix    |   prefix  |              |   prefix   |
   |           |               |   length  |              |   Length   |
   | --------- | ------------- | --------- |  ---------   | ---------- |
   |   DHCPACK |   Preferred   | Preferred | Bound prefix |   Bound    |
   |           |     prefix    |   prefix  |              |   prefix   |

Farrer                  Expires December 27, 2013               [Page 8]

Internet-Draft    DHCPv4oDHCPv6 Shared Address Leasing         June 2013

   |           |               |   length  |              |   Length   |

                  Table 1: IPv6/IPv4 Binding Message Flow

8.  DHCPv4 over DHCPv6 Source Address Option

   The DHCPv4 over DHCPv6 Source address option is used by the Unified
   server to indicate an IPv6 prefix to use for DHCPv4 over DHCPv6
   functions.  It is also used by the client to inform the unified
   server of the prefix it has selected for binding DHCPv4 over DHCPv6
   functions to.

        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 |

   o  option-code: OPTION_DHCPV4_O_DHCPV6_SADDR (TBA2)
   o  option-length: 2 + length of cipv6-prefix-hint + length of cipv6
      -bound-prefix, specified in bytes
   o  cipv6-prefix-hint:
   o  cipv6-hintlen: 8 bit field expressing the bit mask length of the
      IPv6 prefix specified in cipv6-prefix-hint
   o  cipv6-bound-prefix: The IPv6 prefix that the client is using to
      bind the allocated DHCPv4 configuration to
   o  cipv6-boundlen: 8 bit field expressing the bit mask length of the
      IPv6 prefix specified in cipv6-bound-prefix.  Default: 128

9.  Security Considerations


10.  IANA Considerations

   IANA is kindly requested to allocate the following DHCPv4 option
   code: TBD for OPTION_PORTPARAMSV4 and the DHCPv6 option code:

Farrer                  Expires December 27, 2013               [Page 9]

Internet-Draft    DHCPv4oDHCPv6 Shared Address Leasing         June 2013

11.  Acknowledgements

   Thanks to Qi Sun and Olaf Bonness for thier reviews.

12.  References

12.1.  Normative References

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

12.2.  Informative References

              Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
              Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
              dhcpv4-over-dhcpv6-00 (work in progress), April 2013.

              Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
              Farrer, "Lightweight 4over6: An Extension to the DS-Lite
              Architecture", draft-ietf-softwire-lw4over6-00 (work in
              progress), April 2013.

              Mrugalski, T., Troan, O., Dec, W., Bao, C.,
              leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options
              for Mapping of Address and Port", draft-ietf-softwire-map-
              dhcp-03 (work in progress), February 2013.

              Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, "Mapping of Address and Port
              with Encapsulation (MAP)", draft-ietf-softwire-map-07
              (work in progress), May 2013.

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

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927, May

Farrer                  Expires December 27, 2013              [Page 10]

Internet-Draft    DHCPv4oDHCPv6 Shared Address Leasing         June 2013

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

   [RFC6148]  Kurapati, P., Desetti, R., and B. Joshi, "DHCPv4 Lease
              Query by Relay Agent Remote ID", RFC 6148, February 2011.

   [RFC6346]  Bush, R., "The Address plus Port (A+P) Approach to the
              IPv4 Address Shortage", RFC 6346, August 2011.

Author's Address

   Ian Farrer
   Deutsche Telekom AG

   Email: ian.farrer@telekom.de

Farrer                  Expires December 27, 2013              [Page 11]