Softwire WG I. Farrer Internet-Draft Deutsche Telekom AG Updates: RFC7568 (if approved) Q. Sun Intended status: Standards Track Y. Cui Expires: December 31, 2016 Tsinghua University June 29, 2016 DHCPv4 over DHCPv6 Source Address Option draft-fsc-softwire-dhcp4o6-saddr-opt-05 Abstract DHCPv4 over DHCPv6 [RFC7341] 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 and deployment scenarios, the operator must learn the /128 IPv6 address that the client will use as the source of IPv4-in-IPv6 tunnel. This address, in conjunction with the IPv4 address and the Port Set ID allocated to the DHCP 4o6 client are used to create a binding table entry in the softwire tunnel concentrator. This memo defines two DHCPv6 options used 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. 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 31, 2016. Farrer, et al. Expires December 31, 2016 [Page 1] Internet-Draft DHCP 4o6 SADDR option June 2016 Copyright Notice Copyright (c) 2016 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 (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. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Provisioning the BR Address . . . . . . . . . . . . . . . 4 5. IPv6/IPv4 Binding Message Flow . . . . . . . . . . . . . . . 4 6. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. DHCPv4 over DHCPv6 Source Address Hint Option . . . . . . 6 6.2. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 of the client's tunnel endpoint: The tunnel endpoint has to be 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] allows much more flexibility in the location of the IPv4- over-IPv6 tunnel endpoint, as the IPv6 address is dynamically signalled back to the service provider so that the corresponding Farrer, et al. Expires December 31, 2016 [Page 2] Internet-Draft DHCP 4o6 SADDR option June 2016 tunnel configuration in the border router (BR) can be created. 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. Dynamic allocation also helps to optimize IPv4 resource usage as only clients which are currently active are allocated IPv4 addresses. This document describes a mechanism for provisioning dynamically created softwires using DHCPv4 over DHCPv4 (DHCP 4o6), including proivisioning 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 DHCP 4o6 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, e.g. using the client's binding information to synchronise the binding table in the border router. 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 mechanisms suitable for extending to incorporate DHCPv4 over DHCPv6 with dynamic IPv4 address leasing include [RFC7597] and [RFC7596]. 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 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 softwire to be successfully created, the IPv4 address has to be linked to the client's IPv6 tunnel source address. Within this process, the DHCP 4o6 client uses a DHCPv6 option to signal its tunnel source IPv6 address to the DHCP 4o6 server so that the operator's provisioning system can create the binding and configure the tunnel concentrator accordingly. Farrer, et al. Expires December 31, 2016 [Page 3] Internet-Draft DHCP 4o6 SADDR option June 2016 Two new DHCPv6 options are defined in this memo: OPTION_DHCP4O6_SADDR_HINT and OPTION_DHCP4O6_SADDR. They are intended to be used alongside the normal DHCPv4 IPv4 address allocation message flow in the context of DHCPv4 over DHCPv6 [RFC7341]. 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 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 the DHCP 4o6 server using OPTION_DHCP4O6_SADDR. 4.1. Provisioning the BR Address To configure a softwire, the initiator also requires the IPv6 address of the BR. Section 4.2 of [RFC7598] defines option 90 (OPTION_S46_BR) for this purpose, but mandates that the option can only be used when when encapsulated within one of the softwire container options: OPTION_S46_CONT_MAPE, OPTION_S46_CONT_MAPT or OPTION_S46_CONT_LW. 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 this restriction for DHCPv6 option 90 (OPTION_S46_BR) allowing it to appear directly within the list of options in the client's ORO request and directly within subsequent messages sent by the DHCPv6 server. 5. IPv6/IPv4 Binding Message Flow The following diagram shows the client/server message flow and how the options defined in this document 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 messages, and those options are included in the 'options' field of the DHCPv4-query or DHCPv4-response message. Farrer, et al. Expires December 31, 2016 [Page 4] Internet-Draft DHCP 4o6 SADDR option June 2016 DHCP 4o6 DHCP 4o6 Client Server | DHCPDISCOVER (DHCPv4) | Step 1 |----------------------------------------------------->| | ORO with OPTION_S46_BR, | | OPTION_DHCP4O6_SADDR_HINT(DHCPv6) | | | | DHCPOFFER (DHCPv4) | Step 2 |<-----------------------------------------------------| | OPTION_S46_BR, OPTION_DHCP4O6_SADDR_HINT | | (cipv6-prefix-hint with service provider's | | preferred prefix) (DHCPv6) | | | | DHCPREQUEST (DHCPv4) | Step 3 |----------------------------------------------------->| | OPTION_S46_BR, | | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | | client's bound /128 IPv6 address) (DHCPv6) | | | | DHCPACK (DHCPv4) | Step 4 |<-----------------------------------------------------| | OPTION_S46_BR, | | OPTION_DHCP4O6_SADDR (cipv6-bound-prefix with | | client's bound /128 IPv6 prefix) (DHCPv6) | | | IPv6/IPv4 Binding Message Flow A client attempting dynamic softwire configuration includes the option code for OPTION_BR_PREFIX, OPTION_DHCP4O6_SADDR_HINT in the DHCPv6 ORO in all DHCPv4-query messages it sends. When a DHCP 4o6 Server replies with a DHCPOFFER message, it SHOULD include OPTION_S46_BR. It MAY also include OPTION_DHCP4O6_SADDR_HINT, which is used to indicate a preferred prefix that the client should use to bind IPv4 configuration to. If this option is received, the client MUST perform a longest prefix match between cipv6-prefix-hint and all prefixes/addresses in use on the device. If a match is found, the selected prefix MUST then be used to bind the received IPv4 configuration to and source the tunnel from. If no match is found, or the client doesn't receive OPTION_DHCP4O6_SADDR_HINT the client MAY select any valid IPv6 address to use as the tunnel source. OPTION_DHCP4O6_SADDR is used by the client to inform the DHCP 4o6 Server which IPv6 address the IPv4 configuration has been bound to. The client MUST put the selected IPv6 address into this option and Farrer, et al. Expires December 31, 2016 [Page 5] Internet-Draft DHCP 4o6 SADDR option June 2016 include it in the DHCPv4-response message when it sends the DHCPREQUEST message. 6. DHCPv6 Options 6.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-hintlen | | +-+-+-+-+-+-+-+-+ cipv6-prefix-hint . . (variable length) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o option-code: OPTION_DHCP4O6_SADDR_HINT (TBA1) o option-length: 1 + 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 indicating the preferred prefix for the client to bind the received IPv4 configuration to. 6.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 has bound the allocated IPv4 configuration to. Farrer, et al. Expires December 31, 2016 [Page 6] Internet-Draft DHCP 4o6 SADDR option June 2016 7. Security Considerations TBD 8. IANA Considerations IANA is requested to allocate the DHCPv6 option codes: OPTION_DHCP4O6_SADDR_HINT and OPTION_DHCP4O6_SADDR. 9. Acknowledgements The authors would like to thank Ted Lemon and Lishan Li for their contributions. 10. References 10.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, . 10.2. Informative References [I-D.farrer-softwire-br-multiendpoints] 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, . [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, . Farrer, et al. Expires December 31, 2016 [Page 7] Internet-Draft DHCP 4o6 SADDR option June 2016 [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, . 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.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 Farrer, et al. Expires December 31, 2016 [Page 8]