Softwire WG I. Farrer Internet-Draft Deutsche Telekom AG Intended status: Standards Track Q. Sun Expires: January 1, 2015 Y. Cui Tsinghua University June 30, 2014 DHCPv4 over DHCPv6 Source Address Option draft-fsc-softwire-dhcp4o6-saddr-opt-00 Abstract DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes a mechanism for dynamically configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 to function with some IPv4-over-IPv6 softwire mechanisms, the operator must obtain information about the IPv4 address and Port Set ID allocated to the DHCP 4o6 client, as well as the /128 IPv6 prefix that the client will use as the source of IPv4- in-IPv6 tunnel. This memo defines a DHCPv6 container option and two DHCPv6 sub-options, 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. 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 January 1, 2015. Copyright Notice Copyright (c) 2014 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 Farrer, et al. Expires January 1, 2015 [Page 1] Internet-Draft DHCP 4o6 SADDR option June 2014 (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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. IPv6/IPv4 Binding Message Flow . . . . . . . . . . . . . . . 4 5. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. DHCPv4 over DHCPv6 Source Address Hint Option . . . . . . 5 5.2. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . 6 5.3. DHCPv4 over DHCPv6 Softwire Container Option . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Deterministic IPv4-over-IPv6 transition technologies are prescriptive in the location of the tunnel endpoint within the home network. The tunnel endpoint should usually be configured on either the home gateway device, or sourced from a specific IPv6 tunnel prefix allocated to the home network (and in some cases, both). [I-D.ietf-softwire-map-dhcp] describes a DHCPv6 based mechanism for provisioning these deterministic softwires. This document describes a mechanism to inform the service provider of the binding between the dynamically allocated IPv4 address and Port Set ID (learnt through DHCPv4 over DHCPv6) and the IPv6 address that the Softwire Initiator will use for accessing IPv4-over-IPv6 services. It is used with DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] message flows to communicate the binding over the IPv6-only network. The service provider can then use this binding information to provision other functional elements in their network accordingly (such as the border router). The mechanism allows much more flexibility in the location of the IPv4-over-IPv6 tunnel endpoint, as the IPv6 address is dynamically Farrer, et al. Expires January 1, 2015 [Page 2] Internet-Draft DHCP 4o6 SADDR option June 2014 signalled back to the service provider. The DHCP 4o6 client and tunnel 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. This memo describes extensions to [I-D.ietf-softwire-map-dhcp] to enable the provisioning and tunnel management of softwire initiators configured through DHCPv4 over DHCPv6. Current mechanisms suitable for extending to incorporate DHCPv4 over DHCPv6 with dynamic IPv4 address leasing include [I-D.ietf-softwire-map] and [I-D.ietf-softwire-lw4over6]. 2. 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]. 3. Solution Overview The solution described in this document extends the Softwire46 container approach in [I-D.ietf-softwire-map-dhcp] by defining a new container type: OPTION_S46_CONT_DHCP4O6. The container is used to carry the sub-options necessary for softwire configuration. A client can indicate its support for dynamic softwire configuration by including the OPTION_S46_CONT_DHCP4O6 option code within the Option Request Option. Two new DHCPv6 sub-options are also described in this memo: OPTION_DHCP4O6_SADDR_HINT and OPTION_DHCP4O6_SADDR. They are intended to be used alongside the normal IPv4 address allocation message flow in the context of DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. It is a two-way communication process. The OPTION_DHCP4O6_SADDR_HINT is used by the DHCP 4o6 server to optionally 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, or if the specific IPv4-over-IPv6 transition mechanism requires the use of a particular prefix for any reason. When the client has selected the IPv6 address to bind the IPv4 configuration to, it passes the address back to the DHCP 4o6 server through OPTION_DHCP4O6_SADDR. A softwire client also requires an address or addresses for the Border Router (softwire tunnel concentrator). This is used as the destination address for the client IPv4-in-IPv6 encapsulated traffic. Farrer, et al. Expires January 1, 2015 [Page 3] Internet-Draft DHCP 4o6 SADDR option June 2014 Section 4.2 of [I-D.ietf-softwire-map-dhcp] describes the OPTION_S46_BR option. This option SHOULD be included as an encapsulated option within OPTION_S46_CONT_DHCP4O6. This mechanism MUST be used with DHCPv4 over DHCPv6. The DHCP client MUST request the 4o6 Server Address option first to get DHCPv4 over DHCPv6 enabled, as in [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. Then the OPTION_S46_CONT_DHCP4O6 MAY be included in DHCPv4-query and DHCPv4-response messages. 4. IPv6/IPv4 Binding Message Flow The following diagram shows the client/server message flow and how the container OPTION_S46_CONT_DHCP4O6 and its sub-options are used. In each step, the relevant DHCPv4 message is given above the arrow and the relevant options below the arrow. The DHCPv4 messages are encapsulated in DHCPv4-query or DHCPv4-response message, and those options are included in the 'options' filed of the DHCPv4-query or DHCPv4-response message. DHCP 4o6 DHCP 4o6 Client Server | DHCPDISCOVER | Step 1 |----------------------------------------------------->| | ORO with OPTION_S46_CONT_DHCP4O6 | | | | DHCPOFFER | Step 2 |<-----------------------------------------------------| | OPTION_S46_CONT_DHCP4O6 containing OPTION_S46_BR, | | OPTION_DHCP4O6_SADDR_HINT (cipv6-prefix-hint with | | service provider's preferred prefix) | | | | DHCPREQUEST | Step 3 |----------------------------------------------------->| | OPTION_S46_CONT_DHCP4O6 containing OPTION_S46_BR, | | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | | client's bound /128 IPv6 address) | | | | DHCPACK | Step 4 |<-----------------------------------------------------| | OPTION_S46_CONT_DHCP4O6 containing OPTION_S46_BR, | | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | | client's bound /128 IPv6 prefix) | | | IPv6/IPv4 Binding Message Flow Farrer, et al. Expires January 1, 2015 [Page 4] Internet-Draft DHCP 4o6 SADDR option June 2014 The DHCP 4o6 Server and Client MAY implement the OPTION_S46_CONT_DHCP4O6 option and its sub-options. A client that intends to dynamically configure softwires SHOULD include the code of OPTION_S46_CONT_DHCP4O6 in the ORO when it sends a DHCPDISCOVER message. If so, this container option MUST be present along with relevant sub-options in all future DHCPv4 over DHCPv6 transactions. The OPTION_S46_BR SHOULD be included in the container. When a DHCP 4o6 Server replies with a DHCPOFFER message, it SHOULD include the OPTION_S46_CONT_DHCP4O6 option with the OPTION_S46_BR, but it MAY include the OPTION_DHCP4O6_SADDR_HINT. The OPTION_DHCP4O6_SADDR_HINT is used by the server to indicate a preferred prefix that the client should use to bind IPv4 configuration to. If received this sub-option, the client MUST perform a longest prefix match between cipv6-prefix-hint and all prefixes configured on the device. The selected prefix MUST then be used to bind the received IPv4 configuration to. Otherwise, the client can select any valid /128 IPv6 prefix. The OPTION_DHCP4O6_SADDR is used by the client to inform the DHCP 4o6 Server of the IPv6 prefix that it has bound the IPv4 configuration to. The client MUST put the selected IPv6 address into this sub- option and include the OPTION_S46_CONT_DHCP4O6 in the DHCPv4-response message when it sends the DHCPREQUEST message. 5. DHCPv6 Options 5.1. DHCPv4 over DHCPv6 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-boundlen | | +-+-+-+-+-+-+-+-+ cipv6-bound-prefix . . (variable length) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o option-code: OPTION_DHCP4O6_SADDR_HINT (TBA1) o option-length: 2 + length of cipv6-prefix-hint, specified in bytes. o cipv6-hintlen: 8-bit field expressing the bit mask length of the IPv6 prefix specified in cipv6-prefix-hint. o cipv6-prefix-hint: The IPv6 prefix that the server uses to indicate the preferred prefix that the client should use to bind IPv4 configuration to. Farrer, et al. Expires January 1, 2015 [Page 5] Internet-Draft DHCP 4o6 SADDR option June 2014 5.2. DHCPv4 over DHCPv6 Source Address Option The format of DHCPv4 over DHCPv6 Source address option is defined 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_DHCP4O6_SADDR | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + cipv6-src-address + . (128 bits) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o option-code: OPTION_DHCP4O6_SADDR (TBA2) o option-length: 16. o cipv6-src-address: The IPv6 address that the client is using to bind the allocated IPv4 configuration to. 5.3. DHCPv4 over DHCPv6 Softwire Container Option The DHCP 4o6 Container option specifies the container used to group the relevant options and parameters for configuring the client. 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_CONT_DHCP4O6 | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | encapsulated-options (variable length) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o option-code: OPTION_S46_CONT_DHCP4O6 (TBA3) o option-length: 2 + length of encapsulated options (specified in bytes) o encapsulated-options: options for configuring the DHCP 4o6 Softwire client. 6. Security Considerations TBD Farrer, et al. Expires January 1, 2015 [Page 6] Internet-Draft DHCP 4o6 SADDR option June 2014 7. IANA Considerations IANA is requested to allocate the DHCPv6 option code: OPTION_DHCP4O6_SADDR_HINT, OPTION_DHCP4O6_SADDR and OPTION_S46_CONT_DHCP4O6. 8. Acknowledgements 9. References 9.1. Normative References [I-D.ietf-dhc-dhcpv4-over-dhcpv6] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- dhcpv4-over-dhcpv6-09 (work in progress), June 2014. [I-D.ietf-softwire-map-dhcp] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients", draft-ietf-softwire-map-dhcp-07 (work in progress), March 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [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", draft-ietf-softwire-lw4over6-10 (work in progress), June 2014. [I-D.ietf-softwire-map] 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-10 (work in progress), January 2014. [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. Farrer, et al. Expires January 1, 2015 [Page 7] Internet-Draft DHCP 4o6 SADDR option June 2014 Authors' Addresses Ian Farrer Deutsche Telekom AG CTO-ATI, Landgrabenweg 151 Bonn, NRW 53227 Germany Email: ian.farrer@telekom.de Qi Sun Tsinghua University Beijing 100084 P.R. China Phone: +86-10-6278-5822 Email: sunqi@csnet1.cs.tsinghua.edu.cn Yong Cui Tsinghua University Beijing 100084 P.R. China Phone: +86-10-6260-3059 Email: yong@csnet1.cs.tsinghua.edu.cn Farrer, et al. Expires January 1, 2015 [Page 8]