Internet DRAFT - draft-townsley-v6ops-6rd-sunsetting
draft-townsley-v6ops-6rd-sunsetting
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]
