DHCWG                                                          I. Farrer
Internet-Draft                                       Deutsche Telekom AG
Updates: RFC7598 7598 (if approved)                                       Q. Sun
Intended status: Standards Track                                  Y. Cui
Expires: September 10, 2017 June 15, 2018                                            L. Sun
                                                     Tsinghua University
                                                           March 9,
                                                       December 12, 2017

                DHCPv4 over DHCPv6 Source Address Option


   DHCPv4 over DHCPv6 [RFC7341] describes is a mechanism for dynamically configuring IPv4
   over an IPv6-only network.  For DHCPv4 over DHCPv6 to function with
   some IPv4-over-IPv6 softwire mechanisms and deployment scenarios, the
   operator must learn needs to know the /128 IPv6 address that the client will use
   as the source of IPv4-in-IPv6 softwire tunnel.  This address, in
   conjunction with the clients IPv4 address and (in some deployments),
   the Port Set ID
   allocated to the DHCP 4o6 client are used to create a binding table entry in the
   operator's softwire tunnel concentrator.  This memo defines two a DHCPv6 options
   option to convey IPv6 parameters for establishing the softwire tunnel
   and a DHCPv4 option (to be used only with DHCP 4o6) to communicate
   the source tunnel IPv6 address between the DHCP 4o6 client and
   server.  It also describes a method
   for configuring the client with the IPv6 address of the border router
   so that the softwire can be established.  It is designed to work in conjunction with the IPv4 address
   allocation process.  This document updates "DHCPv6 Options for
   Configuration of Softwire Address and Port-Mapped Clients" to allow
   the DHCPv6 option OPTION_S46_BR(90) to appear outside of DHCPv6
   softwire container options.

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/. https://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 10, 2017. June 15, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (https://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   3
   2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3   4
   4.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   3   4
     4.1.  Provisioning  Updating RFC7598 to Permit the BR Address Reuse of OPTION_S46_BR(90)   4
   5.  DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . .   5
   6.  DHCP Options  . . . .   4
   5.  IPv6/IPv4 Binding Message Flow . . . . . . . . . . . . . . .   4
   6. . . . . .   6
     6.1.  DHCPv6 Options Softwire Source Binding Prefix Hint Option . . . .   6
     6.2.  DHCPv4 over DHCPv6 Softwire Source Address Option . . . .   7
   7.  Client Behavior . . . . . . . . . . . . . . . .   6
     6.1.  DHCPv4 over DHCPv6 . . . . . . .   7
     7.1.  Client Initialization . . . . . . . . . . . . . . . . . .   8
     7.2.  Renewing or Rebinding the IPv4 Address Lease and
           Softwire Source Address Hint Option . . . . . .   6
       6.1.1.  Client Option Validation Behavior . . . . . . . . . .   6
     6.2.  DHCPv4 over DHCPv6 .   9
       7.2.1.  Changing the Bound IPv6 Softwire Source Address Option . . .   9
     7.3.  Releasing the IPv4 Address Lease and Softwire
           Source Address  . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . .   9
     7.4.  OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . .   7
   8.  IANA Considerations . .   9
     7.5.  Client and Server Softwire Source Address Mismatch  . . .  10
     7.6.  Use With Dynamic, Shared IPv4 Addresses . . . . . . . . .  10
   8.  Server Behavior . . . . . . .   7
   9.  Acknowledgements . . . . . . . . . . . . . . . .  10
     8.1.  Changing the Bound IPv6 Source Address  . . . . . .   8
   10. References . . .  10
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   10. IANA Considerations . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References  11
   11. Acknowledgements  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses . . . . .  11
   12. References  . . . . . . . . . . . . . . . . . .   9 . . . . . . .  11
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     12.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Deterministic IPv4-over-IPv6 transition technologies require that
   elements are pre-configured with binding rules for routing traffic to
   clients.  This places a constraint on the location choice of address used as
   the client's
   tunnel endpoint: The tunnel endpoint has to be softwire source address: it must use a pre-determined
   prefix which is usually be configured on the home gateway device.
   [RFC7597] describes a DHCPv6 based mechanism for provisioning such
   deterministic softwires.

   A dynamic provisioning model, such as using DHCPv4 over DHCPv6
   [RFC7341] (DHCP 4o6) allows much more flexibility in the location of
   the IPv4-
   over-IPv6 tunnel endpoint, as IPv4-over-IPv6 softwire source address.  In this model, the IPv6
   address is dynamically
   signalled communicated back to the service provider so that
   allowing the corresponding
   tunnel softwire configuration to be created in
   the border router (BR) can be created. (BR).

   The DHCP 4o6 client and tunnel softwire client could be run on end devices
   attached to any routable IPv6 prefix allocated to an end-user,
   located anywhere within an arbitrary home network topology.  Dynamic
   allocation also helps to optimize IPv4 resource usage as only clients
   which are currently active are allocated actively renewing their IPv4 addresses. lease hold on to the address.

   This document describes a mechanism for dynamically provisioning
   softwires created using DHCPv4 over DHCPv6 (DHCP 4o6), DHCP 4o6, including provisioning the client
   with the address of the softwire border router (BR) and informing the
   service provider of client's binding between the dynamically
   allocated IPv4 address and Port Set ID and the IPv6 address that the
   softwire Initiator will use for accessing IPv4-over-IPv6 services.

   It is used with

   The mechanism operates alongside the DHCP 4o6 message flows to
   communicate the binding information over the IPv6-only network.  The
   DHCP 4o6 server provides a single point in the network which holds
   the current client binding information.  The service provider can
   then use this binding information to provision other functional elements in their
   network accordingly, e.g. using the client's binding information to
   synchronise the binding table in
   elements, such as the border router. BR(s).

2.  Applicability

   The mechanism described in this document is only suitable for use for
   provisioning softwire clients via DHCP 4o6.  The options described
   here are only applicable within the DHCP 4o6 message exchange
   process.  Current softwire technologies suitable for extending to
   incorporate DHCPv4 over DHCPv6 DHCP 4o6 with dynamic IPv4 address leasing include
   [RFC7597] and [RFC7596].

3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

4.  Solution Overview

   The solution in this document is intended for the dynamic
   establishment of IPv4-over-IPv6 softwires.  DHCP 4o6 [RFC7341]
   supports dynamically allocating (shared) IPv4 address.  For a

   In order to be successfully created, the provision a softwire, both IPv6 and IPv4 address has configuration
   needs to be
   linked passed to the client's IPv6 tunnel source address.  Within client.  To map this
   process, to the DHCP 4o6 client uses a
   configuration process, the IPv6 configuration is carried in DHCPv6 option
   options carried inside the DHCPv6 message DHCPV4-RESPONSE(21) sent by
   the server.  OPTION_S46_BR(90) is used to signal its
   tunnel source provision the remote IPv6
   address to for the softwire (see Section 4.1 below).
   OPTION_S46_BIND_IPV6_PREFIX(TBD1), is optionally sent by the DHCP 4o6
   server so that the
   operator's provisioning system can create the binding and configure
   the tunnel concentrator accordingly.

   Two new DHCPv6 options are defined in this memo:
   intended to be used alongside the normal DHCPv4 IPv4 address
   allocation message flow in the context of DHCP 4o6.  If a DHCP 4o6
   client supports this mechanism, it MUST include the code of
   OPTION_DHCP4O6_SADDR_HINT in the Option Request Option (ORO)
   [RFC3315] when requesting IPv4 configuration through DHCP 4o6.

   The communication of parameters between the client and server is a
   two-way process: OPTION_DHCP4O6_SADDR_HINT is optionally used by the
   DHCP 4o6 server to indicate to to indicate to the client a preferred IPv6 prefix for binding
   the received IPv4 configuration and sourcing tunnel traffic.  This
   may be necessary if there are multiple IPv6 prefixes in use in the
   customer network (e.g.  ULAs), or if the specific IPv4-over-IPv6
   transition mechanism requires the use of a particular prefix for any
   reason.  When the client has selected an IPv6 address to bind the

   IPv4 configuration to, it passes the address back to is carried in DHCPv4 messages (inside the DHCP 4o6
   option OPTION_DHCPV4_MSG(87)) using OPTION_DHCP4O6_SADDR.

4.1.  Provisioning the BR Address

   To configure mechanism described in

   In order for the client to communicate the softwire source address, a softwire,
   new DHCPv4 option OPTION_DHCP4O6_S46_SADDR(TBD2) is defined in this
   document.  This is included in DHCPREQUEST messages sent by the initiator also requires
   client and is stored by the IPv6 address server for the lifetime of the BR. IPv4
   address lease.

4.1.  Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90)

   Section 4.2 of [RFC7598] defines option 90
   (OPTION_S46_BR) OPTION_S46_BR(90) for this purpose,
   communicating remote softwire border relay(BR)'s' IPv6 address(es) to
   a client, but mandates that the option can only be used when
   encapsulated within one of the softwire container options: OPTION_S46_CONT_MAPE, OPTION_S46_CONT_MAPT
   OPTION_S46_CONT_MAPE(94) or
   OPTION_S46_CONT_LW. OPTION_S46_CONT_LW(96).  From Section 3
   of [RFC7598]:

      "Softwire46 DHCPv6 clients that receive provisioning options that
      are not encapsulated in container options MUST silently ignore
      these options."

   This document updates [RFC7598] to remove [RFC7598], removing this restriction for DHCPv6
   option 90 (OPTION_S46_BR)
   OPTION_S46_BR(90), allowing it to appear directly within the
   list of options be enumerated in the client's ORO
   request and appear directly within subsequent messages sent by the
   DHCPv6 server.

5.  DHCP 4o6 IPv6/IPv4 Binding Message Flow

   The following diagram shows the relevant extensions to the DHCP 4o6
   IPv4 allocation client/server message flow and how for the options defined in this document are used. softwire source
   address function.

   In each step, the
   relevant DHCPv4 DHCPv6 portion of the message and any relevant
   option is given shown above the arrow and arrow.  The DHCP 4o6 content of the message
   and its relevant options are below the arrow.  All the DHCPv4
   messages here are encapsulated in DHCPv4-query DHCPV4-QUERY(20) or DHCPv4-response messages, and those DHCPV4-RESPONSE(21)
   messages.  Where relevant, the necessary options and their contents
   are included in the 'options' field of the DHCPv4-query or
   DHCPv4-response message. shown.

        DHCP 4o6                                              DHCP 4o6
         Client                                                Server
           |                DHCPDISCOVER (DHCPv4)                                                      |
           |       DHCPv6 - DHCPV4-QUERY message containing       |
           |           OPTION_ORO(6) listing (90, TBD1)           |
    Step 1 |----------------------------------------------------->|
           |               ORO with OPTION_S46_BR,            DHCPv4 - DHCPDISCOVER message             |
           |          OPTION_DHCP4O6_SADDR_HINT(DHCPv6)                                                      |
           |                                                      |
           |                 DHCPOFFER (DHCPv4)     DHCPv6 - DHCPV4-RESPONSE message containing      |
    Step 2 |<-----------------------------------------------------|
           |    (cipv6-prefix-hint     (bind-ipv6-prefix with service provider's        |
           |                  preferred prefix) (DHCPv6)              |                   |
    Step 2 |<-----------------------------------------------------|
           |              DHCPv4 - DHCPOFFER message              |                 DHCPREQUEST (DHCPv4)
    Step 3 |----------------------------------------------------->|                                                      |                  OPTION_S46_BR,
           |                                                      |    OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with
           |             DHCPv6 - DHCPV4-QUERY message            |     client's
    Step 3 |----------------------------------------------------->|
           |       DHCPv4 -  DHCPREQUEST message containing       |
           |  OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address |
           |with client's bound /128 IPv6 address) (DHCPv6) softwire source address)|
           |                                                      |
           |                                                      |                   DHCPACK (DHCPv4)
           |           DHCPv6 - DHCPV4-RESPONSE message           |
    Step 4 |<-----------------------------------------------------|
           |                    OPTION_S46_BR,                    |          DHCPv4 - DHCPACK message containing         |    OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with
           |  OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address |
           |with client's bound /128 IPv6 prefix) (DHCPv6)       | softwire source address)|
           |                                                      |

                      IPv6/IPv4 Binding Message Flow


   Step 1  The client attempting dynamic softwire configuration includes constructs a DHCPv6 'DHCPV4-QUERY(20)' message.
           This message contains two options: DHCPv6 OPTION_ORO(6) and
           OPTION_DHCPV4_MSG(87).  OPTION_ORO lists '90' (OPTION_S46_BR)
           contains a DHCP4 DHCPDISCOVER message.

   Step 2  The server responds with a DHCPv6 'DHCPV4-RESPONSE(20)'
           message.  This message contains OPTION_S46_BR(90) containing
   option code IPv6 address of the BR for OPTION_BR_PREFIX, OPTION_DHCP4O6_SADDR_HINT in the
   DHCPv6 ORO in all DHCPv4-query messages it sends.

   When client's softwire
           configuration.  The message may also, optionally contain
           contains a DHCP 4o6 Server replies DHCP4 DHCPOFFER message.

   Step 3  The client sends with a DHCPOFFER message, it SHOULD
   include OPTION_S46_BR.  It MAY also include
           containing a DHCP4 DHCPREQUEST message with
           OPTION_DHCP4O6_S46_SADDR(TBD2) with the IPv6 address which
           the client will use as its softwire source address.

   Step 4  The server sends a DHCPv6 'DHCPV4-RESPONSE(20)' message.
           OPTION_DHCPV4_MSG contains a DHCP4 DHCPACK message.
           OPTION_DHCP4O6_S46_SADDR with the client's softwire source
           address is used included.

6.  DHCP Options

6.1.  DHCPv6 Softwire Source Binding Prefix Hint Option

   The format of DHCPv6 Source Binding Prefix hint option is as follows:

      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_S46_BIND_IPV6_PREFIX  |         option-length         |
     |bindprefix6-len|                                               |
     +-+-+-+-+-+-+-+-+             bind-ipv6-prefix                  .
     .                            (variable length)                  .

                   Format of OPTION_S46_BIND_IPV6_PREFIX

   o  option-code: OPTION_S46_BIND_IPV6_PREFIX (TBA1)
   o  option-length: 1 + length of bind-ipv6-prefix, specified in bytes.
   o  bindprefix6-len: 8-bit field expressing the bit mask length of the
      IPv6 prefix specified in bind-ipv6-prefix.  Valid values are 0 to indicate a
   o  bind-ipv6-prefix: The IPv6 prefix indicating the preferred prefix that
      for the client should use to bind the received IPv4 configuration to.  If
   this option  The
      length is received, the client (bindprefix6-len + 7) / 8.  The field is padded on the
      right with zero bits up to the nearest octet boundary when bind-
      ipv6-prefix is not evenly divisible by 8.

   OPTION_S46_BIND_IPV6_PREFIX is a singleton.  Servers MUST perform NOT send
   more than one instance of the OPTION_S46_BIND_IPV6_PREFIX option.

6.2.  DHCPv4 over DHCPv6 Softwire Source Address Option

   The format of DHCPv4 over DHCPv6 softwire source address option is as

              0                             1
              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
             |   option-code (TBD)   |     option-length     |
             +           softwire-ipv6-src-address           +
             .                  (128 bits)                   .

                    Format of OPTION_DHCP4O6_S46_SADDR

   o  option-code: OPTION_DHCP4O6_S46_SADDR (TBD2)
   o  option-length: 16.
   o  softwire-ipv6-src-address: 16 bytes long; The IPv6 address that
      the client has bound the allocated IPv4 configuration to.

   NB - The function of OPTION_DHCP4O6_S46_SADDR may seem similar to the
   DHCPv4 message 'chaddr' field, or the Client Identifier (61) option
   in that it provides a longest lower-layer address which is unique that the
   server can use for identifying the client.  However, as both of these
   are required to remain constant throughout the address lease
   lifetime, they cannot be used with the mechanism described in this
   document.  This is because the client may only be able to construct
   the IPv6 address to use as the source address after it has received
   the first DHCP-RESPONSE message from the server containing

7.  Client Behavior

   A client requiring dynamic softwire configuration first enables DHCP
   4o6 configuration using the method described in Section 5.  of
   [RFC7341].  If OPTION_DHCP4_O_DHCP6_SERVER is received in the
   corresponding REPLY message, the client MAY continue with the
   configuration process described below.

   It is also a prerequisite that the client has already obtained a
   suitable IPv6 prefix
   match between cipv6-prefix-hint to use for its local softwire endpoint using
   DHCPv6, SLAAC or another mechanism.

7.1.  Client Initialization

   When constructing the initial DHCP 4o6 DHCPDISCOVER message, the
   client includes a DHCPv6 OPTION_ORO(6) within the options field of
   the DHCP-QUERY message.  OPTION_ORO contains the option codes for
   OPTION_S46_BR (90) and all prefixes/addresses in OPTION_S46_BIND_IPV6_PREFIX (TBD1).

   On receipt of the DHCP 4o6 server's reply (a DHCPV4-RESPONSE
   containing a DHCPOFFER message), the client checks the contents of
   the DHCPv4-RESPONSE for the presence of a valid OPTION_S46_BR option.
   If this option is not present, or does not contain at least one valid
   IPv6 address for a BR, then the client MUST discard the message, as
   without the address of the BR the client cannot configure the
   softwire and so has no interface to request IPv4 configuration for.

   The DHCP-RESPONSE message may also include
   OPTION_S46_BIND_IPV6_PREFIX, which is used by the operator to
   indicate a preferred prefix that the client should use on to bind IPv4
   configuration to.  If received, the client first checks the device. option
   according to Section 7.4.  If a match is found, valid, the selected client uses this prefix MUST then be
   used as
   the 'IPv6 binding prefix' and follows to bind the received IPv4 configuration process described in
   Section 5.1 of [RFC7596] in order to and source select an active IPv6 prefix to
   construct the tunnel
   from. softwire.  If no match is found, or the client doesn't
   OPTION_DHCP4O6_SADDR_HINT OPTION_S46_BIND_IPV6_PREFIX the client MAY select any valid
   address prefix (of a suitable scope) to use as the tunnel source.

   Once the client has selected which prefix it will use, a suitable prefix, it MAY use either an
   existing IPv6 address that is already configured on an interface, or
   create a new address specifically for use as the softwire source
   address (e.g. using an Interface Identifier constructed as per
   Section 6 6. of [RFC7597]).  If a new address is being created, the
   client MUST complete configuration of the new address, performing
   duplicate address detection (if required) before
   proceeding to Step 3.

   OPTION_DHCP4O6_SADDR proceeding.

   The client then constructs a DHCPV4-QUERY message containing a DHCPv4
   DHCPREQUEST message.  OPTION_DHCP4O6_S46_SADDR is used by included in the
   options field of the DHCPREQUEST message with the IPv6 address of its
   softwire source address in the softwire-ipv6-src-address field.

   When the client to inform receives a DHCPv4 DHCPACK message from the server, it
   checks the DHCP 4o6
   Server which IPv6 address in OPTION_DHCP4O6_S46_SADDR against its
   active softwire source address.  If they match, the IPv4 configuration allocation
   process has been bound to.
   The concluded.  If there is a discrepancy then the process
   described in Section 7.5 is followed.

7.2.  Renewing or Rebinding the IPv4 Address Lease and Softwire Source

   Whenever the client MUST put attempts to extend the lease time of the IPv4
   address, OPTION_DHCP4O6_S46_SADDR with the selected IPv6 address of its
   softwire source address into
   this option and include it in the DHCPv4-response message when it
   sends softwire-ipv6-src-address field MUST
   be included in the DHCPREQUEST message.

6.  DHCPv6 Options

6.1.  DHCPv4 over DHCPv6

7.2.1.  Changing the Bound IPv6 Softwire Source Address Hint Option

         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_DHCP4O6_SADDR_HINT   |         option-length         |
        |cipv6-hintlen  |                                               |
        +-+-+-+-+-+-+-+-+          cipv6-prefix-hint                    .
        .                          (variable length)                    .

   o  option-code: OPTION_DHCP4O6_SADDR_HINT (TBA1)
   o  option-length: 1 + length

   Across the lifetime of cipv6-prefix-hint, specified in
   o  cipv6-hintlen: 8-bit field expressing the bit mask length leased IPv4 address, it is possible that
   the client's IPv6 will change.  E.g. if there is a flash IPv6 re-
   numbering event.

   In this situation, the client MUST inform the server of the
      IPv6 prefix specified in cipv6-prefix-hint.  Valid values are 0 to
   o  cipv6-prefix-hint: The IPv6 prefix indicating new
   address.  This is done by sending a DHCPREQUEST message containing
   OPTION_DHCP4O6_S46_SADDR with the preferred prefix
      for new IPv6 source address.

   When the client to bind receives a DHCPv4 DHCPACK message from the received IPv4 configuration to.  The
      length server, it
   checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its
   active softwire source address.  If they match, the allocation
   process has concluded.  If there is (cipv6-hintlen + 7) / 8.  The field a discrepancy then the process
   described in Section 7.5 is padded on followed.

7.3.  Releasing the
      right with zero bits up IPv4 Address Lease and Softwire Source Address

   When the client no longer requires the IPv4 resource, it sends a
   DHCPv4 DHCPRELEASE message to the nearest octet boundary when cipv6-
      prefix-hint server.  As the options field is not evenly divisible by 8.

   unused in this message type, OPTION_DHCP4O6_S46_SADDR is a singleton.  Servers MUST NOT send more
   than one instance of the OPTION_DHCP4O6_SADDR_HINT option.

6.1.1.  Client Option not

7.4.  OPTION_S46_BIND_IPV6_PREFIX Validation Behavior

   On receipt of the OPTION_DHCP4O6_SADDR_HINT OPTION_S46_BIND_IPV6_PREFIX option, the client
   makes the following validation checks:

   o  The received cipv6-hintlen bindprefix6-len value is not larger than 128.
   o  The received cipv6-hintlen bindprefix6-len value is not larger than the number
      of bytes sent in the cipv6-prefix-hint bind-ipv6-prefix field. (e.g. the cipv6-hintlen
      bindprefix6-len is 128 but the cipv6-prefix-hint bind-ipv6-prefix has only 8 bytes).

   For either of these cases the receiver MAY either discard the option
   and proceed to attempt configuration as if the option had not been
   received, or attempt to use the received values for the long longest
   prefix match anyway.

   The receiver MUST only use bits the cipv6-prefix-hint bind-ipv6-prefix field up to the
   value specified
   value specified in the bindprefix6-len when performing the longest
   prefix match. bind-ipv6-prefix bits beyond this value MUST be

7.5.  Client and Server Softwire Source Address Mismatch

   If the client receives a DHCPACK message with an
   OPTION_DHCP4O6_S46_SADDR containing an IPv6 address which differs
   from its active softwire source address, the client MAY either:

   o  Wait for a randomised time interval and then resend a DHCPREQUEST
      message with the correct softwire source address, OR
   o  Send a DHCPRELEASE message and re-start the process described in
      Section 7.

7.6.  Use With Dynamic, Shared IPv4 Addresses

   [RFC7618]describes a mechanism for using DHCPv4 to distribute
   dynamic, shared IPv4 addresses to clients.  The mechanism described
   in this document is compatible with IPv4 address sharing, and can be
   enabled by following the process described in Section 6 of [RFC7618].

8.  Server Behavior

   Beyond the normal DHCP 4o6 functionality defined in [RFC7341], the
   server MUST also store the IPv6 softwire source address of the client
   in the cipv6-hintlen when performing leasing address database, alongside the longest
   prefix match.  cipv6-prefix-hint bits beyond this value IPv4 address and
   client identifier.  An OPTION_DHCP4O6_S46_SADDR containing the bound
   softwire source address MUST be

6.2.  DHCPv4 over DHCPv6 Source Address Option sent in every DHCPACK message sent by
   the server.

   The format of DHCPv4 over DHCPv6 Source binding entry between the client's IPv6 softwire source address
   and the leased IPv4 address option is defined valid as

         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_DHCP4O6_SADDR      |         option-length         |
        |                                                               |
        +                        cipv6-src-address                      +
        .                           (128 bits)                          .

   o  option-code: OPTION_DHCP4O6_SADDR (TBA2)
   o  option-length: 16.
   o  cipv6-src-address: 16 bytes long; The long as the IPv4 lease
   remains valid.

8.1.  Changing the Bound IPv6 address that Source Address

   In the client
      has bound event that the allocated server receives a DHCPREQUEST message for an
   active IPv4 configuration to.

7. lease containing a OPTION_DHCP4O6_S46_SADDR with an IPv6
   address which differs from the address which is currently stored, the
   server updates the stored softwire source address with the new
   address supplied by the client, and sends a DHCPACK message
   containing the updated softwire source address in

9.  Security Considerations

   Security considerations which are applicable to [RFC7341] are also
   applicable here.


10.  IANA Considerations

   IANA is requested to allocate a new DHCPv6 option code for
   OPTION_S46_BIND_IPV6_PREFIX from the DHCPv6 Option Codes registry and
   a new DHCPv4 option code for

   Vendor Extensions and DHCP Options registry.

11.  Acknowledgements

   The authors would like to thank Ted Lemon, Lishan Li and Li, Tatuya Jinmei
   and Jonas Gorski for their contributions and comments.


12.  References


12.1.  Normative References

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

   [RFC7341]  Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
              Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
              RFC 7341, DOI 10.17487/RFC7341, August 2014,


12.2.  Informative References

              Farrer, I. and Q. Sun, "Multiple BR Tunnel Endpoint
              Addresses", draft-farrer-softwire-br-multiendpoints-01
              (work in progress), July 2015.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,

   [RFC3315]  Droms, R., Ed., 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, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC7596]  Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
              Farrer, "Lightweight 4over6: An Extension to the Dual-
              Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
              July 2015, <http://www.rfc-editor.org/info/rfc7596>. <https://www.rfc-editor.org/info/rfc7596>.

   [RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
              Port with Encapsulation (MAP-E)", RFC 7597,
              DOI 10.17487/RFC7597, July 2015,

   [RFC7598]  Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
              W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
              Configuration of Softwire Address and Port-Mapped
              Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015,

   [RFC7618]  Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M.
              Boucadair, "Dynamic Allocation of Shared IPv4 Addresses",
              RFC 7618, DOI 10.17487/RFC7618, August 2015,

Authors' Addresses

   Ian Farrer
   Deutsche Telekom AG
   CTO-ATI, Landgrabenweg 151
   Bonn, NRW  53227

   Email: ian.farrer@telekom.de

   Qi Sun
   Tsinghua University
   Beijing  100084
   P.R. China

   Phone: +86-10-6278-5822
   Email: sunqi.csnet.thu@gmail.com

   Yong Cui
   Tsinghua University
   Beijing  100084
   P.R. China

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

   Linhui Sun
   Tsinghua University
   Beijing  100084
   P.R. China

   Phone: +86-10-6278-5822
   Email: lh.sunlinh@gmail.com