Internet Engineering Task Force W. Townsley Internet-Draft Cisco Intended status: Informational A. Cassen Expires: May 17, 2012 Free Telecom November 14, 2011 6rd Sunsetting draft-townsley-v6ops-6rd-sunsetting-00 Abstract This document provides guidelines for transitioning an IPv6 deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment using Native IPv6. It is targeted at both 6rd operators and 6rd implementors." 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 May 17, 2012. Copyright Notice Copyright (c) 2011 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. Townsley & Cassen Expires May 17, 2012 [Page 1] Internet-Draft 6rd Sunsetting November 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Incremental Sunsetting With Renumbering . . . . . . . . . . . . 3 5. Incremental Sunsetting Without Renumbering . . . . . . . . . . 4 6. CE Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Townsley & Cassen Expires May 17, 2012 [Page 2] Internet-Draft 6rd Sunsetting November 2011 1. Introduction 6rd [RFC5969] specifies a protocol mechanism to deploy IPv6 to sites via a service provider's (SP's) IPv4 network. The 6rd mechanism uses an algorithmic mapping between IPv4 and IPv6 within the SP network. This mapping allows for automatic IPv6 prefix delegation as well as determination of IPv6 over IPv4 tunnel endpoints within the SP, providing for stateless operation. Unlike 6to4 [RFC3056], 6rd is designed to be configured and operated by an SP. It is expected than an SP providing 6rd configuration will do so with the same considerations as with native IPv6. This document describes two incremental 6rd "sunsetting" models, each with different tradeoffs. The best model for an SP will depend on the specific operational considerations for that SP. One model requires a 6rd user to be renumbered to a new IPv6 prefix when native configuration is applied. The other model allows an SP to move to native IPv6 in a "seamless" mode which does not require renumbering or multihoming with separate prefixes. The CE requirements identified in this document provide a basis for both modes. 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. Terminology This document uses terms as defined in section 3 of [RFC5969], in particular Customer Edge (CE) to refer to a router at the edge of a customer site, 6rd Border Relay (BR), 6rd domain, 6rd delegated prefix, CE LAN side, CE WAN side, etc. Please refer to the definitions in [RFC5969] for more information. 4. Incremental Sunsetting With Renumbering Perhaps the most obvious method for sunsetting 6rd is to bring up native IPv6 users in a separate prefix from that provided by 6rd, then disabling 6rd at the same time or later. The CE LAN side is then either being served by 6rd from one IPv6 prefix, native from another IPv6 Prefix, or both at any given time. Townsley & Cassen Expires May 17, 2012 [Page 3] Internet-Draft 6rd Sunsetting November 2011 Using this mode, end-user sites are renumbered when moving from 6rd to native IPv6. Recommendations for "Renumbering Without a Flag Day" described in [RFC4192] should be followed. When 6rd and native IPv6 are both active with different prefixes, the CE is effectively multihomed via two separate interfaces (one physical, one virtual). Paradoxically, traffic may decrease less than expected or even increase at the 6rd BRs as users are moved from 6rd to native IPv6. This is because the native IPv6 users are considered by the rest of the 6rd users to be outside of their 6rd domain, as such the BR will be required to be traversed for traffic that before was handled directly between 6rd CEs. Ideal BR placement may also change as new native IPv6 users are added and the footprint of the 6rd domain is altered. 5. Incremental Sunsetting Without Renumbering A perhaps less obvious sunsetting approach allows for incremental native deployment without requiring site renumbering and no increase of traffic at the Border Relays as native IPv6 is deployed. In this "seamless mode" the native link is configured by the ISP with the same IPv6 prefix as 6rd calculates from IPv4. The aim is to allow the network to use the native interface when it can and the 6rd interface when it cannot via simple forwarding metrics. As there is no new delegated prefix introduced, this mode avoids complications with multihoming and renumbering. Following is a set of basic steps an operator might employ: 1. 6rd Deployment. 2. CEs reachable by Native IPv6 are configured via DHCPv6-PD [RFC3633] with the same delegated prefix calculated and in use by 6rd. 3. CEs keep native and 6rd interfaces active, with a single (unchanged) prefix for the CE LAN side. There is no affect on the home site. 4. When native IPv6 becomes active on a given CE, an upstream default route is installed for IPv6 as it normally would, while assigning a metric that causes the native link to be preferred over 6rd. 6rd routes remain as long as 6rd is configured by the SP, allowing the more-specific route for inter-domain 6rd traffic to be selected over the native route (again, following normal IP forwarding rules). This allows CE to CE traffic to continue over 6rd, while "off-net" IPv6 traffic destined for outside the 6rd Townsley & Cassen Expires May 17, 2012 [Page 4] Internet-Draft 6rd Sunsetting November 2011 domain will be sent over the native link. 5. If the operator wishes to direct incoming traffic from outside the 6rd domain towards native CEs directly, this may be done by injecting an IPv6 prefix within the ISPs IGP, or by configuring static routes directly on the BR. The level of granularity here is up to the operator, anywhere from a single site for testing, up to a set of sites corresponding to a specific aggregation level, region, or block of addresses as long as all of the sites for which the prefix is being injected have native IPv6 enabled. This allows a progressive removal of traffic which must traverse the 6rd BR function commensurate with the deployment of native IPv6. 6. Once Native IPv6 is fully deployed, 6rd is disabled at the BRs. This should be done first at the BRs allowing all native traffic to and from outside the 6rd domain to switch to native, and then at the CEs to move all intradomain 6rd traffic to native. Again, this may be done incrementally, by first testing a handful of CEs without 6rd enabled, and then moving forward at a pace determined by the individual operator. 7. The final result will be a native IPv6 deployment with the same IPv4-based numbering plan that 6rd required. If the SP would like to obtain better aggregation or move to a different IPv6 prefix entirely (as may be required by some RIR policies), renumbering may then be safely performed now that 6rd is fully decommisioned. 6. CE Requirements The following CE requirements are sufficient for "Incremental Sunsetting Without Renumbering", and provide a basis for "Incremental Sunsetting With Renumbering." 1. A 6rd CE MUST continue to allow 6rd packets to be sent and received as long as 6rd configuration is provided by the ISP, even while links on the router are configured with native IPv6. 2. A 6rd CE MUST assign a forwarding metric such that native IPv6 egress is preferred for traffic outside the 6rd domain when 6rd and native IPv6 interfaces are active. 3. 6rd and native IPv6 MUST allow for an identical IPv6 delegated prefix. Specific CE requirements for renumbering of a residential site itself Townsley & Cassen Expires May 17, 2012 [Page 5] Internet-Draft 6rd Sunsetting November 2011 are out of scope of this document. 7. Security Considerations There are no specific additional security issues identified at this time. 8. IANA Considerations None. 9. Acknowledgements 10. References 10.1. Normative References [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [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. Townsley & Cassen Expires May 17, 2012 [Page 6] Internet-Draft 6rd Sunsetting November 2011 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. 10.2. Informative References [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. Authors' Addresses Mark Townsley Cisco Paris, France Phone: Email: mark@townsley.net Townsley & Cassen Expires May 17, 2012 [Page 7] Internet-Draft 6rd Sunsetting November 2011 Alexandre Cassen Free Telecom Paris, France Phone: Email: acassen@freebox.fr Townsley & Cassen Expires May 17, 2012 [Page 8]