DHCWG I. Farrer Internet-Draft Deutsche Telekom AG Updates: 7598 (if approved) Q. Sun Intended status: Standards Track Y. Cui Expires: September 28, 2018 L. Sun Tsinghua University March 27, 2018 Softwire Provisioning using DHCPv4 Over DHCPv6 draft-ietf-dhc-dhcp4o6-saddr-opt-03 Abstract DHCPv4 over DHCPv6 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 needs to know the IPv6 address that the client will use as the source of IPv4-in-IPv6 softwire tunnel. This address, in conjunction with the client's IPv4 address and (in some deployments), the Port Set ID are used to create a binding table entry in the operator's softwire tunnel concentrator. This memo defines a DHCPv6 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 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. This document updates RFC7598, allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6 client's ORO request and appear directly within subsequent messages sent by the DHCPv6 server. 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 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 Farrer, et al. Expires September 28, 2018 [Page 1] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 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 28, 2018. Copyright Notice Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90) 4 5. DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . . 5 6. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option . . . . 7 6.2. DHCPv4 over DHCPv6 Softwire Source Address Option . . . . 7 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Client Initialization . . . . . . . . . . . . . . . . . . 8 7.2. Renewing or Rebinding the IPv4 Address Lease and Softwire Source Address . . . . . . . . . . . . . . . . . 9 7.2.1. Changing the Bound IPv6 Softwire Source Address . . . 10 7.3. Releasing the IPv4 Address Lease and Softwire Source Address . . . . . . . . . . . . . . . . . . . . . 10 7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . . . . 10 7.5. Client and Server Softwire Source Address Mismatch . . . 11 7.6. Use With Dynamic, Shared IPv4 Addresses . . . . . . . . . 11 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Changing the Bound IPv6 Source Address . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 Farrer, et al. Expires September 28, 2018 [Page 2] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 12.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 choice of address used as the client's softwire source address: it must use a pre-determined prefix which is usually 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 softwire source address. In this model, the IPv6 address is dynamically communicated back to the service provider allowing the corresponding softwire configuration to be created in the border router (BR). The DHCP 4o6 client and 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 actively renewing their IPv4 lease hold on to the address. This document describes a mechanism for dynamically provisioning softwires created using 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. 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, such as the 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 DHCP 4o6 with dynamic IPv4 address leasing include [RFC7597] and [RFC7596]. Farrer, et al. Expires September 28, 2018 [Page 3] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 3. 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]. 4. Solution Overview In order to provision a softwire, both IPv6 and IPv4 configuration needs to be passed to the client. To map this to the DHCP 4o6 configuration process, the IPv6 configuration is carried in DHCPv6 options carried inside the DHCPv6 message DHCPV4-RESPONSE (21) sent by the server. OPTION_S46_BR (90) is used to provision the remote IPv6 address for the softwire (see Section 4.1 below). OPTION_S46_BIND_IPV6_PREFIX (TBD1), is optionally sent by the DHCP 4o6 server 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. IPv4 configuration is carried in DHCPv4 messages (inside the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism described in [RFC7341]. In order for the client to communicate the softwire source address, a new DHCPv4 option OPTION_DHCP4O6_S46_SADDR (TBD2) is defined in this document. This is included in DHCPREQUEST messages sent by the client and is stored by the server for the lifetime of the IPv4 address lease. 4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90) Section 4.2 of [RFC7598] defines option OPTION_S46_BR(90) for 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 (94) or 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], removing this restriction for OPTION_S46_BR (90), allowing it to be enumerated in the client's ORO Farrer, et al. Expires September 28, 2018 [Page 4] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 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 successful DHCP 4o6 IPv4 allocation client/server message flow for the softwire source address function. The full process, including error handling is described in Section 7. In each step, the DHCPv6 portion of the message and any relevant option is shown above the arrow. The DHCP 4o6 content of the message and its relevant options are below the arrow. All the DHCPv4 messages are encapsulated in DHCPV4-QUERY (20) or DHCPV4-RESPONSE (21) messages. Where relevant, the necessary options and their contents are shown. Farrer, et al. Expires September 28, 2018 [Page 5] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 DHCP 4o6 DHCP 4o6 Client Server | | | DHCPv6 - DHCPV4-QUERY message containing | | OPTION_ORO(6) listing (90, TBD1) | Step 1 |----------------------------------------------------->| | DHCPv4 - DHCPDISCOVER message | | | | | | DHCPv6 - DHCPV4-RESPONSE message containing | | OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(TDB1) | | (bind-ipv6-prefix with service provider's | | preferred prefix) | Step 2 |<-----------------------------------------------------| | DHCPv4 - DHCPOFFER message | | | | | | DHCPv6 - DHCPV4-QUERY message | Step 3 |----------------------------------------------------->| | DHCPv4 - DHCPREQUEST message containing | | OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address | | with client's bound IPv6 softwire source address) | | | | | | DHCPv6 - DHCPV4-RESPONSE message | Step 4 |<-----------------------------------------------------| | DHCPv4 - DHCPACK message containing | | OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address | | with client's bound IPv6 softwire source address) | | | Figure 1: IPv6/IPv4 Binding Message Flow Step 1 The client 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) and 'TBD1' (OPTION_S46_BIND_IPV6_PREFIX). OPTION_DHCPV4_MSG contains a DHCPv4 DHCPDISCOVER message. Step 2 The server responds with a DHCPv6 'DHCPV4-RESPONSE (21)' message. This message contains OPTION_S46_BR (90) containing the IPv6 address of the BR for the client's softwire configuration. The message may also, optionally contain OPTION_S46_BIND_IPV6_PREFIX (TBD1). OPTION_DHCPV4_MSG contains a DHCPv4 DHCPOFFER message. Step 3 The client sends with a DHCPv6 'DHCPV4-QUERY(20)' message containing a DHCPv4 DHCPREQUEST message with Farrer, et al. Expires September 28, 2018 [Page 6] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 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(21)' message. OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message. OPTION_DHCP4O6_S46_SADDR with the client's softwire source address is 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 (TBD1) 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 128. o bind-ipv6-prefix: The IPv6 prefix indicating the preferred prefix for the client to bind the received IPv4 configuration to. The length is (bindprefix6-len + 7) / 8. The field is padded on the right with zero bits up to the next octet boundary when bind- ipv6-prefix is not evenly divisible by 8. OPTION_S46_BIND_IPV6_PREFIX is a singleton. Servers MUST 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 follows: Farrer, et al. Expires September 28, 2018 [Page 7] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 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 is associated (either being requested for binding or currently bound) with the client's IPv4 configuration. NB - The function of OPTION_DHCP4O6_S46_SADDR may seem similar to the DHCPv4 message's 'chaddr' field, or the Client Identifier (61) option in that it provides a 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 DHCPV4-RESPONSE message from the server containing OPTION_S46_BIND_IPV6_PREFIX. 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 learned a suitable IPv6 prefix to use for its local softwire endpoint using DHCPv6, RA/PIO 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 OPTION_S46_BIND_IPV6_PREFIX (TBD1). Farrer, et al. Expires September 28, 2018 [Page 8] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 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 DHCPV4-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 to bind IPv4 configuration to. If received, the client first checks the option according to Section 7.4. If valid, the client uses this prefix as the 'IPv6 binding prefix' and follows to the process described in Section 5.1 of [RFC7596] in order to select an active IPv6 prefix to construct the softwire. If no match is found, or the client doesn't receive OPTION_S46_BIND_IPV6_PREFIX the client MAY select any valid IPv6 prefix (of a suitable scope) to use as the tunnel source. Once the client has selected 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. 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. The client then constructs a DHCPV4-QUERY message containing a DHCPv4 DHCPREQUEST message. OPTION_DHCP4O6_S46_SADDR is 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 receives a DHCPv4 DHCPACK message from the 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 a discrepancy then the process described in Section 7.5 is followed. If the client receives a DHCPv4 DHCPNAK message from the server, then the configuration process has been unsuccessful. The client then restarts the process from Step 1 of Figure 1. 7.2. Renewing or Rebinding the IPv4 Address Lease and Softwire Source Address Whenever the client attempts to extend the lease time of the IPv4 address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its Farrer, et al. Expires September 28, 2018 [Page 9] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 softwire source address in the softwire-ipv6-src-address field MUST be included in the DHCPREQUEST message. 7.2.1. Changing the Bound IPv6 Softwire Source Address Across the lifetime of the 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 new address. This is done by sending a DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address. When the client receives a DHCPv4 DHCPACK message from the 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 a discrepancy then the process described in Section 7.5 is followed. If the client receives a DHCPv4 DHCPNAK message in repsonse from the server, then the change of the bound IPv6 Softwire source address has been unsuccessful. In this case, the client MUST stop using the new IPv6 source address. The client then restarts the process from Step 1 of Figure 1. 7.3. Releasing the IPv4 Address Lease and Softwire Source Address When the client no longer requires the IPv4 resource, it sends a DHCPv4 DHCPRELEASE message to the server. As the options field is unused in this message type, OPTION_DHCP4O6_S46_SADDR is not included. 7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior On receipt of the OPTION_S46_BIND_IPV6_PREFIX option, the client makes the following validation checks: o The received bindprefix6-len value is not larger than 128. o The received bindprefix6-len value is not larger than the number of bytes sent in the bind-ipv6-prefix field. (e.g. the bindprefix6-len is 128 but the 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 longest prefix match anyway. Farrer, et al. Expires September 28, 2018 [Page 10] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 The receiver MUST only use bits from the bind-ipv6-prefix field up to the value specified in the bindprefix6-len when performing the longest prefix match. bind-ipv6-prefix bits beyond this value MUST be ignored. 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 leasing address database, alongside the IPv4 address and client identifier. An OPTION_DHCP4O6_S46_SADDR containing the bound softwire source address MUST be sent in every DHCPACK message sent by the server. The binding entry between the client's IPv6 softwire source address and the leased IPv4 address is valid as long as the IPv4 lease remains valid. 8.1. Changing the Bound IPv6 Source Address In the event that the server receives a DHCPREQUEST message for an active IPv4 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 OPTION_DHCP4O6_S46_SADDR. The server MAY implement a policy enforcing a minimum time interval between a client updating its softwire source IPv6 address. If a Farrer, et al. Expires September 28, 2018 [Page 11] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 client attempts to update the softwire source IPv6 address before the minimum time has expired, the server can either silently drop the client's message or send back a DHCPACK message containing the exisiting IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. 9. Security Considerations Security considerations which are applicable to [RFC7341] are also applicable here. 10. IANA Considerations IANA is requested to assign the OPTION_DHCP4O6_S46_SADDR option code from the "BOOTP Vendor Extensions and DHCP Options" registry maintained at http://www.iana.org/assignments/bootp-dhcp-parameters. IANA is requested to assign the OPTION_S46_BIND_IPV6_PREFIX option code from the DHCPv6 "Option Codes" registry maintained at http://www.iana.org/assignments/dhcpv6-parameters. IANA is requested to update the entry for DHCPv6 Option S46_BR (90) in the table at https://www.iana.org/assignments/dhcpv6-parameters as follows: Old entry: | 90 | S46_BR | No | No | New entry: | 90 | S46_BR | Yes | No | IANA is also requested to make a new entry for OPTION_S46_BIND_IPV6_PREFIX TBD1) in the table at https://www.iana.org/assignments/dhcpv6-parameters: | TBD1 |OPTION_S46_BIND_IPV6_PREFIX| Yes | Yes | 11. Acknowledgements The authors would like to thank Ted Lemon, Lishan Li, Tatuya Jinmei, Jonas Gorski and Razvan Becheriu for their contributions and comments. Farrer, et al. Expires September 28, 2018 [Page 12] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 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 [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, . [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 Germany Email: ian.farrer@telekom.de Farrer, et al. Expires September 28, 2018 [Page 13] Internet-Draft Softwire Provising with DHCP 4o6 March 2018 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 Farrer, et al. Expires September 28, 2018 [Page 14]