DHC WG I. Farrer Internet-Draft Deutsche Telekom AG Intended status: Standards Track Q. Sun Expires: August 16, 2014 Y. Cui Tsinghua University February 12, 2014 DHCPv4 over DHCPv6 Source Address Option draft-fsc-dhc-dhcp4o6-saddr-opt-00 Abstract DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes one possible mechanism for dynamically configuring IPv4 over an IPv6 only network. For DHCPv4 over DHCPv6 to function with some softwire mechanisms, the operator must obtain information about the DHCP 4o6 client's allocated IPv4 address and PSID, 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 option to convey this IPv6 prefix between the DHCP 4o6 client and server. It is designed to work in conjunction with the DHCPv4 IPv4 address allocation process message flow. 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]. 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 August 16, 2014. Farrer, et al. Expires August 16, 2014 [Page 1] Internet-Draft DHCP 4o6 SADDR option February 2014 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 (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. Applicabiliity . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes a mechanism for dynamically configuring IPv4 over an IPv6 only network by transporting the complete set of DHCPv4 messages within a specific pair of DHCPv6 messages. The IPv4 configuration provisioned to the DHCP 4o6 clients is then generally used for configuring IPv4 over IPv6 services. IPv4 addresses can be dynamically leased to DHCP 4o6 clients in the same manner as IPv4 addresses are leased to DHCPv4 clients in IPv4 networks. The main advantages to this approach is a greater efficiency in the use of limited IPv4 address resources over IPv6 networks. Currently defined IPv4 over IPv6 transition technologies are, by design, quite prescriptive in the location of the tunnel endpoint within the home network. The tunnel endpoint must usually be configured on either the home gateway device, or sourced from a very specific IPv6 tunnel prefix allocated to the home network (and in some cases, both). This is necessary to enable the end-to-end Farrer, et al. Expires August 16, 2014 [Page 2] Internet-Draft DHCP 4o6 SADDR option February 2014 provisioning chain between the IPv4-over-IPv6 client in the home network, the border router (the egress point from the IPv4 over IPv6 domain to the IPv4-only domain) and the provisioning systems responsible for configuring the functional elements. The dynamic leasing of IPv4 addresses to clients alters this end-to- end provisioning chain. It can no longer be assumed that a Softwire Initiator sourcing from a specific IPv6 prefix have to use a certain IPv6 address as the source for encapsulating its IPv4 packets. Therefore, a mechanism is necessary to inform the service provider of the binding between the allocated IPv4 address (learnt through DHCPv4) and the IPv6 address that the IPv4 over IPv6 client will use for accessing IPv4-over-IPv6 services. The service provider can then use this binding information to provision other functional elements it their network such as the border router accordingly. A second benefit of such a mechanism is that it allows much more flexibility in the location of the IPv4 over IPv6 tunnel endpoint as this will be dynamically signalled back to the service provider. The DHCP 4o6 client and tunnel client could be run on end devices attached to any valid IPv6 prefix allocated to an end-user, located anywhere within an arbitrary home network topology. As The DHCP 4o6 server manages the leasing of IPv4 addresses to the DHCP 4o6 clients, which runs on the Softwire Initiators, it holds the most accurate IPv4 lease information available across the IPv6 network between the server and the client. It follows that the DHCP 4o6 server should also hold information about the /128 IPv6 prefixes that active clients are using, so that the server contains a single, comprehensive and up to date dynamic IPv4/IPv6 binding table. This memo describes a DHCPv6 option so that the server can indicate to the client a preferred IPv6 prefix to use (if necessary) and for the client to signal back the /128 IPv6 prefix that they will bind the allocated IPv4 configuration to. The DHCP 4o6 server then stores this information alongside the IPv4 lease information. 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]. For these mechanisms to function, the operator needs the information about the DHCP 4o6 client's allocated IPv4 address, PSID and also the /128 IPv6 prefix that the client will use to source the IPv4-in-IPv6 tunnel endpoint. Farrer, et al. Expires August 16, 2014 [Page 3] Internet-Draft DHCP 4o6 SADDR option February 2014 2. Applicabiliity Although DHCPv4 over DHCPv6 is used as the configuration protocol throughout this document, the DHCPv6 option and provisioning process which is described here may also be used with other DHCP based IPv4 over IPv6 configuration mechanisms, such as DHCPv4 over IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6]. 3. Solution Overview The DHCPv6 option (OPTION_DHCPV4OV6_SADDR) described by this memo is intended to be used alongside the normal DHCPv4 IPv4 address allocation message flow as described in [RFC2131], in the context of DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] . It is a two- way communication process, allowing the service provider to (optionally) indicate to the client a preferred prefix alongside the DHCPOFFER message, which can be used for binding the received IPv4 configuration and sourcing tunnel traffic. When the client has selected the IPv6 prefix to bind the IPv4 configuration to, it passes this back to the DHCP 4o6 server along with the DHCPREQUEST message. 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. The following diagram shows the client/server message flow and how the different fields of OPTION_DHCPV4OV6_SADDR are used. In each step, the relevant DHCPv4 message is given above the arrow and the relevant paramaters used in OPTION_DHCPV4OV6_SADDR's fields below the arrow. Farrer, et al. Expires August 16, 2014 [Page 4] Internet-Draft DHCP 4o6 SADDR option February 2014 DHCP 4o6 DHCP 4o6 Client Server | DHCPDISCOVER | Step 1 |-------------------------------------------->| | OPTION_DHCPV4OV6_SADDR (blank fields) | | | | DHCPOFFER | Step 2 |<--------------------------------------------| | OPTION_DHCPV4OV6_SADDR (cipv6-prefix-hint | | with service provider's preferred prefix) | | | | DHCPREQUEST | Step 3 |-------------------------------------------->| | OPTION_DHCPV4OV6_SADDR (cipv6-bound-prefix | | with client's bound /128 IPv6 prefix) | | | | DHCPACK | Step 4 |<--------------------------------------------| | OPTION_DHCPV4OV6_SADDR (cipv6-bound-prefix | | with client's bound /128 IPv6 prefix) | | | IPv6/IPv4 Binding Message Flow The OPTION_DHCPV4OV6_SADDR (defined below) option is included by the DHCP 4o6 client within DHCPv4-query messages. The DHCP 4o6 server MAY reply with this option within DHCPv4-response messages. The DHCP 4o6 Server and Client MAY implement the OPTION_DHCPV4OV6_SADDR option. If used, this option MUST be present within all future DHCPv4 over DHCPv6 transactions. The option comprises of two prefixes (with associated prefix length fields): cipv6-prefix-hint Used by the server to indicate a preferred prefix that the client should use to bind IPv4 configuration to. If this field contains a prefix, 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. If this field is left blank, then the client can select any valid IPv6 prefix. cipv6-bound-prefix Used by the client to inform the DHCP 4o6 Server of the IPv6 prefix that it has bound the IPv4 Farrer, et al. Expires August 16, 2014 [Page 5] Internet-Draft DHCP 4o6 SADDR option February 2014 configuration to. This MUST be a /128 prefix configured on the client. 4. 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_DHCPV4OV6_SADDR | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cipv6-hintlen | | +-+-+-+-+-+-+-+-+ cipv6-prefix-hint . . (variable length) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |cipv6-boundlen | | +-+-+-+-+-+-+-+-+ cipv6-bound-prefix . . (variable length) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o option-code: OPTION_DHCPV4OV6_SADDR (TBA) o option-length: 2 + length of cipv6-prefix-hint + length of cipv6 -bound-prefix, 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. o cipv6-boundlen: 8-bit field expressing the bit mask length of the IPv6 prefix specified in cipv6-bound-prefix. Default: 128. o cipv6-bound-prefix: The IPv6 prefix that the client is using to bind the allocated IPv4 configuration to. 5. Security Considerations TBD 6. IANA Considerations IANA is requested to allocate the DHCPv6 option code: OPTION_DHCPV4OV6_SADDR. Farrer, et al. Expires August 16, 2014 [Page 6] Internet-Draft DHCP 4o6 SADDR option February 2014 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative 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-04 (work in progress), January 2014. [I-D.ietf-dhc-dhcpv4-over-ipv6] Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4 over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-08 (work in progress), October 2013. [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-06 (work in progress), February 2014. [I-D.ietf-softwire-map-dhcp] Mrugalski, T., Troan, O., 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-06 (work in progress), November 2013. [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 August 16, 2014 [Page 7] Internet-Draft DHCP 4o6 SADDR option February 2014 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006. [RFC6148] Kurapati, P., Desetti, R., and B. Joshi, "DHCPv4 Lease Query by Relay Agent Remote ID", RFC 6148, February 2011. [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011. 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 August 16, 2014 [Page 8]