[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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


   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

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",
   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

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

   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

   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

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

   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

8.  IANA Considerations


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

   Email: mark@townsley.net

Townsley & Cassen         Expires May 17, 2012                  [Page 7]

Internet-Draft               6rd Sunsetting                November 2011

   Alexandre Cassen
   Free Telecom

   Email: acassen@freebox.fr

Townsley & Cassen         Expires May 17, 2012                  [Page 8]