________       __________  
             |        |     |          | 
             | DHCPv6 |     | DHCPv4o6 | 
             | Server |     |  Server  |
             |________|     |__________|
                 |         /           \
              1,2|     3,4/             \ 5
                 |       /               \
              ___|_____ /                 \ _________
             |         |                   |         |
             |  lw4o6  |<----------------->| lwAFTR  |     
             |  Client |     Data Plane    |         |
             |_________|                   |_________|
           

The numbers in each of the provisioning flows are described in more detail below.

Figure 1: Dynamic lw4o6 Provisioning Model

The Lightweight 4over6 provisioning process with DHCPv4o6 proceeds as follows:

1. lwB4 runs DHCPv6[RFC3315] to get the IPv6 address of the DHCP4o6 server
2. IPv4 address of lwB4 is provisioned by the DHCP4o6 server through DHCPv4 over DHCPv6[RFC7341]
3. lwB4 port set is allocated through DHCPv4 over DHCPv6 using Dynamic Allocation of Shared IPv4 Addresses[I-D.ietf-dhc-dynamic-shared-v4allocation]
4. IPv6 Tunnel source address of the lwB4 is sent to the DHCP4o6 server using DHCPv4 over DHCPv6 Source Address Option[I-D.fsc-softwire-dhcp4o6-saddr-opt]
5. lwAFTR binding table maintenance is achieved by using DHCP4o6 Bulk/Active Leasequery[I-D.cui-dhc-dhcp4o6-bulk-active-leasequery] (or other provisioning protocol)

4. Lightweight4over6 Dynamic Provisioning Process

This section describes the dynamic provisioning process of Lightweight 4over6 in more detail. For the remainder of this document, "lwB4" should be understood to mean a stateful lwB4 using DHCPv4 over DHCPv6 for dynamic IPv4 provisioning.

4.1. IP Addressing

Before begining the DHCPv4 over DHCPv6 to obtain IPv4 configuration, the lwB4 MUST be configured with an IPv6 address. There are no restrictions on how the IPv6 address is provisioned, (e.g. SLAAC, DHCPv6 or some other mechanisms). However, the prefix selected by the lwB4 MUST be routable to the lwAFTR (e.g. a link-local address must not be used). The operator can use the OPTION_DHCP4O6_SADDR_HINT option defined in [I-D.fsc-softwire-dhcp4o6-saddr-opt] to indicate to the client a suitable prefix to select the tunnel endpoint address from.

4.2. DHCPv6 Configuration

Before stateful lwB4 runs DHCPv4 over DHCPv6 to acquire IPv4 address and port set, lwB4 MUST run DHCPv6 to achieve the DHCP 4o6 server's IPv6 address. The DHCPv6 server provides the DHCP 4o6 server's IPv6 address by OPTION_DHCP4_O_DHCP6_SERVER as defined in [RFC7341].

4.3. DHCPv4 over DHCPv6 Function

Once the lwB4 has acquired the IPv6 address of the DHCP4o6 server, stateful configuration using DHCPv4 over DHCPv6 is performed to obtain an IPv4 address and port set. [I-D.ietf-dhc-dynamic-shared-v4allocation] describes how the PSID is conveyed in this mechanism. The lwB4 includes one of its IPv6 address as the IPv6 tunnel source address in this message flow with the DHCP 4o6 server, and receives the lwAFTR's tunnel address through DHCPv4 over DHCPv6, as described in section 4 of [I-D.fsc-softwire-dhcp4o6-saddr-opt].

4.4. lwAFTR Binding Table Maintenance

In figure 1 above, the lwAFTR is not co-located with the DHCP 4o6 server. With this architecture, the DHCP 4o6 server informs the lwAFTR about changes in IPv4 leases and the bound tunnel endpoint addresses using the DHCP4o6 Bulk and Active Leasequery process (described in [I-D.cui-dhc-dhcp4o6-bulk-active-leasequery]).

The lwAFTR functions as a requestor, requesting every active lwB4's IPv4 address + PSID, and bound tunnel endpoint IPv6 address. The lwAFTR can use DHCP4o6 Bulk Leasequery to initialize its binding table with current lwB4 binding information, or recover missing lease information from failure. The lwAFTR can use DHCP4o6 Active Leasequery to get real-time lwB4 binding information.

4.4.1. Co-located lwAFTR/DHCP4o6 Binding Table Maintenance

lwAFTR maintains its binding table as per section 6.1 of [I-D.ietf-softwire-lw4over6]. Unless the binding table is fixed and pre-determined, it is synchronized with DHCPv4 over DHCPv6 process. The following DHCPv4 over DHCPv6 messages trigger binding table modification:

• DHCPACK: Generated by DHCP 4o6 server, triggers lwAFTR to add a new entry or modify an existing entry.
• DHCPRELEASE: Generated by lwB4, triggers lwAFTR to delete an existing entry.

When lwAFTR receives a DHCPACK event, it looks up the binding table using the lwB4's IPv4 address and PSID as index. If there is an existing entry found, the lwAFTR updates the IPv6 address and lifetime fields of the entry; otherwise the lwAFTR creates a new entry accordingly. When lwAFTR receives a DHCPRELEASE event, it looks up the binding table using the lwB4's IPv6 address, IPv4 address and PSID as index. The lwAFTR deletes the entry either by removing it from the binding table or mark the lifetime field to an invalid value (e.g. 0).

When lwAFTR is co-located with the DHCP 4o6 server, it listens all DHCPv4 over DHCPv6 messages generated or received by the DHCP 4o6 server and updates the bindings through valid messages.

4.4.2. lwAFTR Binding Table Maintenance with NETCONF

NETCONF [RFC6241] can also be used for lwAFTR binding table maintenance. The data model for lw4o6 is defined in [I-D.sun-softwire-yang]. When NETCONF is used, the DHCP 4o6 server is integrated with NETCONF client and the lwAFTR is integrated with NETCONF server. When the address allocation state is changed due to the DHCPACK/DHCPRELEASE, the DHCP 4o6 server initiates NETCONF edit-config operations to the lwAFTR to send notifications of binding table modification.

5. Security Considerations

Security considerations in [I-D.ietf-softwire-lw4over6] and [RFC7341] should be considered.

The DHCP message triggered binding table maintenance may be used by an attacker to send fake DHCP messages to lwAFTR. The operator network should deploy [RFC2827] to prevent this kind of attack.

6. IANA Considerations

This document does not include an IANA request.

7. References

7.1. Normative References

[I-D.cui-dhc-dhcp4o6-bulk-active-leasequery]	Cui, Y., Liu, Z., Liu, C. and Y. Lee, "DHCP4o6 Bulk and Active Leasequery", Internet-Draft draft-cui-dhc-dhcp4o6-bulk-active-leasequery-01, March 2015.
[I-D.fsc-softwire-dhcp4o6-saddr-opt]	Farrer, I., Sun, Q. and Y. Cui, "DHCPv4 over DHCPv6 Source Address Option", Internet-Draft draft-fsc-softwire-dhcp4o6-saddr-opt-02, July 2015.
[I-D.ietf-dhc-dynamic-shared-v4allocation]	Cui, Y., Qiong, Q., Farrer, I., Lee, Y., Sun, Q. and M. Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", Internet-Draft draft-ietf-dhc-dynamic-shared-v4allocation-09, May 2015.
[I-D.ietf-softwire-lw4over6]	Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y. and I. Farrer, "Lightweight 4over6: An Extension to the DS-Lite Architecture", Internet-Draft draft-ietf-softwire-lw4over6-13, November 2014.
[RFC2827]	Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC7341]	Sun, Q., Cui, Y., Siodelski, M., Krishnan, S. and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, August 2014.

7.2. Informative References

[I-D.ietf-softwire-map-dhcp]	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", Internet-Draft draft-ietf-softwire-map-dhcp-12, March 2015.
[I-D.sun-softwire-yang]	Sun, Q., Wang, H., Cui, Y., Farrer, I., Boucadair, M. and R. Asati, "YANG Data Model for IPv4-in-IPv6 Softwire", Internet-Draft draft-sun-softwire-yang-03, April 2015.
[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.
[RFC6241]	Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6887]	Wing, D., Cheshire, S., Boucadair, M., Penno, R. and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.

Authors' Addresses