6man Working Group Y. Lee Internet-Draft Comcast Intended status: Standards Track M. Boucadair Expires: April 8, 2011 France Telecom X. Xu Huawei October 5, 2010 IPv6 RA Option for DS-Lite AFTR Element draft-lee-6man-ra-dslite-01 Abstract This document specifies a new optional extension to IPv6 Router Advertisement messages to allow IPv6 routers to advertise DS-Lite AFTR addresses to IPv6 hosts (i.e., a default IPv6 route for DS-Lite traffic). The provisioning of the AFTR address is crucial to access IPv4 connectivity services in a DS-Lite context. Means to ensure reliable delivery of this information to connecting hosts is a must. Furthermore, this RA option can be used as a means to distribute DS- Lite serviced customers among a set of deployed AFTRs without requiring a central knowledge of the underlying topology and deployed AFTRs. 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 April 8, 2011. Lee, et al. Expires April 8, 2011 [Page 1] Internet-Draft RA for AFTR Element October 2010 Copyright Notice Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Coexistence of RA Option and DHCPv6 Option . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Neighbour Discovery Extension . . . . . . . . . . . . . . . . . 4 6.1. AFTR Element Option . . . . . . . . . . . . . . . . . . . . 4 6.1.1. Procedure in IPv6 Host with B4 Implementation . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Load Balancing Use Case . . . . . . . . . . . . . . . 7 Appendix B. Scope . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Lee, et al. Expires April 8, 2011 [Page 2] Internet-Draft RA for AFTR Element October 2010 1. Introduction Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite] provides a means to guarantee IPv4 service continuity during the transition period where global IPv4 addresses become a scarce resource. In the DS-Lite framework, the B4 element tunnels the IPv4-in-IPv6 datagrams towards one of the available AFTR entities deployed in the provider network. The B4 element can learn the AFTR address by DHCPv6 [I-D.ietf-softwire-ds-lite-tunnel-option] or RADIUS [I-D.maglione-softwire-dslite-radius-ext]. The provisioning of the AFTR information to connecting hosts embedding B4 is mandatory for the delivery of IPv4 connectivity services in the context of DS-Lite deployment. As an analogy with native IPv6 connectivity provisioning, the AFTR information (i.e., IP address or FQDN) can be seen as a default IPv6 route for DS-Lite IPv4-in-IPv6 traffic. Indeed, when no AFTR information is provisioned to a requesting host embedding a B4 element, no external IPv4 address would be assigned and the IPv4 traffic won't be delivered outside the local domain. In other terms, fail to provision an AFTR to B4 element will break IPv4 connectivity. Service providers need a reliable and flexible method to provision the AFTR address(es) to the B4 elements in customers' premises. This document describes a mechanism to use a new IPv6 RA Option to advertise the AFTR address to the IPv6 hosts. In the remaining part of the document, host is used for short to denote a host embedding B4 element. 2. Motivation A service provider may want to deploy DS-lite without using DHCP. Auto-configuration [RFC4861] allows an IPv6 host to learn the IPv6 prefix and IPv6 default gateway solely from the Router Advertisement (RA). In this document, we define a new AFTR RA option so that a B4 element can learn a set of AFTRs. 3. Coexistence of RA Option and DHCPv6 Option The RA AFTR option and the DHCP option can be used together. When the host receives a RA and the "O" flag is set in the RA, the host may send a DHCPv6 request for AFTR provisioning. If the DHCP server returns the DS-Lite tunnel option, the host may use the address in the option. If the RA does not contain the AFTR option, the RA may send the DHCP request to obtain the AFTR configuration from the DHCP Lee, et al. Expires April 8, 2011 [Page 3] Internet-Draft RA for AFTR Element October 2010 server regardless of whether the "O" flag is set in the RA or not. 4. Terminology This document uses terms defined in [I-D.ietf-softwire-dual-stack-lite]. In addition, we define the following new terms: o AFTR Option: IPv6 RA option to deliver AFTR information (e.g., IP address) to IPv6 hosts. o AFTR Element List: A data structure for managing AFTR Element Information in the IPv6 protocol stack in addition to the Neighbor Cache and Destination Cache for Neighbor Discovery. 5. Overview This document defines a new ND option called AFTR option that contains the list of addresses of AFTR element. This new option advertises a list of available AFTR elements. This option follows the procedures defined in [RFC4861]. This works the same way that the hosts learn routers and prefixes. The AFTR element is only useful for B4 elements, i.e.- ordinary IPv6 hosts must ignore this option. The IPv6 host with B4 element implemented can learn a list of AFTR elements thanks to this option. The AFTR option can be sent along with other options in the same RA message simultaneously. The router sending the AFTR option in RA must be configured with the AFTR information. The information is provisioned in the first-hop router of the B4 elements. The AFTR option can be used on any network that supports ND. 6. Neighbour Discovery Extension This AFTR configuration mechanism in this memo defines a new ND option in Neighbor Discovery: The AFTR Element option. 6.1. AFTR Element Option The AFTR Element Option contains one or more IPv6 addresses of the AFTR elements. All of the addresses share the same lifetime value. If a particular AFTR is configured to have different lifetime values, a new AFTR option can be used. Figure 1 shows the AFTR Element Option format. Lee, et al. Expires April 8, 2011 [Page 4] Internet-Draft RA for AFTR Element October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Addresses of IPv6 AFTR Elements : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Where o Type is the RA AFTR Option type o Length is a 8-bit unsigned integer. The length of the option is in unit of 8 octets. o Reserved is for future use. o Lifetime is a 16-bit unsigned integer. The lifetime associated with the AFTR elements in units of seconds. o Addresses of IPv6 AFTR Elements contain one or more 128-bit IPv6 addresses of the AFTR elements. The number of addresses is determined by the Length field. That is, the number if addresses is equal to (Length - 1) / 2. 6.1.1. Procedure in IPv6 Host with B4 Implementation When the host receives the option via RA, it checks whether the option is valid. o If the AFTR option is valid, the host should copy the option's value into the B4 configuration. o If the AFTR option is invalid, the host must discard the option. 7. IANA Considerations This document requests IANA to assign a new option code for: Lee, et al. Expires April 8, 2011 [Page 5] Internet-Draft RA for AFTR Element October 2010 o DS-Lite AFTR Address 8. Security Considerations This document does not introduce any new security in addition to what has been identified in [RFC4861] and [I-D.ietf-softwire-dual-stack-lite]. 9. Acknowledgements Many thanks to C. Jacquenet for his review and comments. 10. References 10.1. Normative References [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work in progress), August 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. 10.2. Informative References [I-D.ietf-softwire-ds-lite-tunnel-option] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", draft-ietf-softwire-ds-lite-tunnel-option-05 (work in progress), September 2010. [I-D.maglione-softwire-dslite-radius-ext] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- Stack Lite", draft-maglione-softwire-dslite-radius-ext-00 (work in progress), July 2010. Lee, et al. Expires April 8, 2011 [Page 6] Internet-Draft RA for AFTR Element October 2010 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. Appendix A. Load Balancing Use Case [[Note: The content of this section is still under discussion between authors.]] Load balancing and traffic dimensioning is one of the hot topic to be considered when deploying stateful devices such as AFTRs. Service providers need means to distribute their DS-Lite serviced customers among a set of AFTR devices without experiencing any congestion neither traffic loss due to the overloading of a given AFTR while free AFTR resources are available. This dimensioning task is not new per se. In particular, VoIP service providers rely on DNS to redirect customers traffic to a given SBC (or P-CSCF) node. Various solutions to balance customers among a set of AFTRs can be considered as follows: o DHCPv6 server returns an IPv6 address of an AFTR based on a identifier of the customer. o DHCPv6 server returns a generic FQDN of AFTR nodes. A DNS-based load balancing is implemented during the resolution of the FQDN. o DHCPv6 returns a geographical domain search name which will be used to redirect the client to a given AFTR. The DHCPv6 server needs to correlate the AFTR information with an identifier of the requesting customer. o The DHCPv6 relay agent can insert locally configured information when responding back to a connecting client. o Etc. As an alternative to these modes, RA can be used to implicitly redirect DS-Lite serviced customers to a given AFTR without requiring any use of a customer identifier. DHCPv6 servers are not modified. Access routers can be configured to insert an IP address when sending RAs to attached hosts. The configuration of the information to be inserted in RA messages can be achieved using already deployed tools. Lee, et al. Expires April 8, 2011 [Page 7] Internet-Draft RA for AFTR Element October 2010 Appendix B. Scope It was tempting to define a generic option which is an extension of [RFC4191] to indicate a route which is used by IPv4-in-IPv6 traffic. Since DS-Lite is the only technique which is required crossing a stateful device after the de-capsulation. We decided to limit the applicability scope of this option to DS-Lite. Authors' Addresses Yiu L. Lee Comcast Email: yiu_lee@cable.comcast.com URI: http://www.comcast.com Mohamed Boucadair France Telecom Email: mohamed.boucadair@orange-ftgroup.com URI: http://www.orange-ftgroup.com Xiaohu Xu Huawei Email: xuxh@huawei.com Lee, et al. Expires April 8, 2011 [Page 8]