V6ops WG V. Kuarsingh, Ed.
Internet-Draft Rogers Communications
Intended status: Informational Y. Lee
Expires: August 5, 2011 Comcast
O. Vautrin
Juniper Networks
February 1, 2011
6to4 Provider Managed Tunnels
draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-01
Abstract
6to4 Provider Managed Tunnels (6to4-PMT) provides a framework which
can help manage 6to4 [RFC3056] tunnels operating an an anycast
[RFC3068] configuration. The 6to4-PMT framework is intended to serve
as an option to service providers to help improve the experience of
6to4 operation when conditions of the network may provide sub-optimal
performance or break normal 6to4 operation. 6to4-PMT provides a
stable provider prefix and forwarding environment by utilizing
existing 6to4 Relays with an added function of IPv6 Prefix
Translation. This operation may be particularly important in NAT444
infrastructures where a customer endpoint may be assigned a non-
RFC1918 address subject to a northbound Large Scale NAT
[draft-nishitani-cgn-05] translator breaking the normal IPv4 return
path.
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 5, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Kuarsingh, et al. Expires August 5, 2011 [Page 1]
Internet-Draft 6to4 Provider Managed Tunnels February 2011
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. 6to4 Provider Managed Tunnels . . . . . . . . . . . . . . . . 4
3.1. 6to4 Provider Managed Tunnel Model . . . . . . . . . . . . 4
3.2. Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Prefix Translation . . . . . . . . . . . . . . . . . . . . 5
3.4. Translation State . . . . . . . . . . . . . . . . . . . . 6
4. Deployment Issues and Requirements . . . . . . . . . . . . . . 7
4.1. Customer Opt-out . . . . . . . . . . . . . . . . . . . . . 7
4.2. ISP Shared Space Interaction . . . . . . . . . . . . . . . 7
4.3. End to End Transparency . . . . . . . . . . . . . . . . . 8
4.4. Routing Requirements . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Kuarsingh, et al. Expires August 5, 2011 [Page 2]
Internet-Draft 6to4 Provider Managed Tunnels February 2011
1. Introduction
6to4 [RFC3056] tunneling along with anycast operation [RFC3068] is
widely deployed in modern host Operating Systems and off the shelf
gateways sold throughout the retail and OEM channels. RFC3068 based
6to4 allows for tunneled IPv6 connectivity through IPv4 clouds, but
due to the anycast nature of the ingress and egress flows, flows
paths are difficult to determine and often change based on network
conditions. The return path is uncontrolled by the local provider
and can contribute to poor performance for IPv6, and can also act as
a breakage point (i.e. mis-behaving relay/system). Additionally,
consumer endpoints which are subject to northbound NAT44 operation,
such as with NAT444, may be subject to broken IPv6 connectivity if
non-RFC1918 addresses are used on the CPE.
Providers which are actively deploying IPv6 networks and operate
legacy IPv4 access environments may want to utilize the existing 6to4
behavior in deployed hardware and software as an interim option to
reach the IPv6 internet in advance of being able to offer native
IPv6. 6to4-PMT offers a provider the opportunity to utilize IPv6
Prefix Translation to provide deterministic and an unbroken path to
and from the Internet for IPv6 based traffic.
6to4-PMT translates the prefix portion of the address from the 6to4
address to a provider assigned prefix which is used to represent the
source. This translation will then provide a stable forward and
return path for the 6to4 traffic by allowing the existing IPv6
routing and policy environment to control the traffic. 6to4-PMT is
primarily intended to be used in a stateless manner to maintain many
of the elements inherent in normal 6to4 operation. Alternatively,
6to4-PMT can be used in a stateful translation mode should the
operator choose this option.
2. Motivation
Providers endeavor to deploy IPv6 as soon as possible, so as to
ensure uninterrupted connectivity to all Internet applications and
content through the transition process. The IPv6 preparations within
these organizations are often faced with both financial challenges
and timing issues related to deploying IPv6 to the network edge and
related transition technologies. Many of the new technologies
addressing IPv4 to IPv6 transition will require the replacement of
the customer CPE to support technologies like 6RD [RFC5969] which
also require the replacement or upgrade of the customer endpoint
device..
Provider initiated replacement of this equipment will take time due
Kuarsingh, et al. Expires August 5, 2011 [Page 3]
Internet-Draft 6to4 Provider Managed Tunnels February 2011
to the nature of such mass equipment refresh programs. Additionally,
many providers also do not supply CPE related equipment and general
lack of awareness in the consumer space may delay the upgrade of many
in-home gateway and operating environments. Providers may still be
motivated to provide a form of IPv6 connectivity to customers to
mitigate potential issues related to IPv6-only deployments elsewhere
on the Internet. Providers may also need to mitigate issues of
default 6to4 operation in these existing home devices. After IPv4
run out, IPv6 content and addressed endpoints may grow rapidly in
number and in some cases, IPv4 may not be a connection option for
some web based content providers or the remote hosts (IPv6 Only).
6to4-PMT allows a provider to help mitigate such challenges by
leveraging a protocol which is already found on many CPE home
gateways, while maintaining operator control of access to the IPv6
Internet. It is intended for use when better options, such as 6RD or
native IPv6, are not yet viable. The 6to4-PMT operation can also be
used immediately with existing OS and gateway functionality (in the
wild) without the initial replacement of consumer equipment. The
default 6to4 operation on most consumer grade OSs and gateways will
allow for IPv6 connectivity over the IPv4 access network. Once
native IPv6 is available to the endpoint, the 6to4-PMT operation is
no longer needed. If 6to4-PMT operation was used to mitigate default
6to4 operation in a NAT444 environment, then native IPv6 addresses
will take precedence based on IPv6 address selection [RFC3484].
3. 6to4 Provider Managed Tunnels
3.1. 6to4 Provider Managed Tunnel Model
The 6to4 managed tunnel model behaves like a standard 6to4 service
between the customer IPv6 host or gateway and the 6ot4-PMT Relay
(within the provider domain). The 6to4-PMT Relay shares properties
with 6RD [RFC5969] by decapsulating and forwarding embedded IPv6
flows, within an IPv4 packet, to the IPv6 Internet. The model
provides an additional function which translates the source 6to4
prefix to a provider assigned prefix which is not found in 6RD
[RFC5969] or traditional 6to4 operation.
The 6to4-PMT Relay is intended to provide a stateless (or stateful)
mapping of the 6to4 prefix to a provider supplied prefix by mapping
the embedded IPv4 address in the 6to4 prefix to the provider prefix.
Kuarsingh, et al. Expires August 5, 2011 [Page 4]
Internet-Draft 6to4 Provider Managed Tunnels February 2011
| 6to4-PMT Operation |
+-----+ 6to4 Tunnel +--------+ +------+ IPv6 +----+
| CPE |-------------|6to4 BR |--| PT66 |--------- |Host|
+-----+ IPv4 +--------+ +------+ Provider +----+
Network Prefix
Unified or Separate
Functions/Platforms
Figure 1: 6to4-PMT Functional Model
This mode of operation is seen as beneficial when compared to broken
6to4 paths and or environments where 6to4 operation may be functional
but highly degraded.
3.2. Traffic Flow
Traffic in the 6to4-PMT model is intended to be controlled by the
operators IPv6 peering operations. Egress traffic is managed through
outgoing routing policy, and incoming traffic is influenced by the
operator assigned prefix advertisements.
The routing model is as predictable as native IPv6 traffic and legacy
IPv4 based traffic. Figure 1 provides a view of the routing topology
needed to support this relay environment. The diagram references
PrefixA as 2002::/16 and PrefixB as the example 2001:db8::/32.
| 6to4 IPv4 Path | Native IPv6 Path |
----------- ----------- -------------
/ IPv4 Net \ / IPv6 Net \ / IPv6 Internet \
+------+ +--------+ +-------+ +---------+
| CPE | PrefixA |6to4-PMT| PrefixB |Peering| |IPv6 HOST|
+------+ +--------+ +-------+ +---------+
\ / \ / \ /
---------- ------------ --------------
IPv4 6to4 IPv6 Provider IPv6 Prefix
Anycast Prefix Advertisement
Figure 2: 6to4-PMT Flow Model
Traffic between two 6to4 enabled devices would use the IPv4 path for
communication according to RFC3056.
3.3. Prefix Translation
The IPv6 Prefix Translation is a key part of the system as a whole.
The 6to4-PMT framework is a combination of two concepts: 6to4
Kuarsingh, et al. Expires August 5, 2011 [Page 5]
Internet-Draft 6to4 Provider Managed Tunnels February 2011
[RFC3056] and IPv6 Prefix Translation. IPv6 Prefix Translation has
some similarities to concepts discussed in [draft-mrw-nat66]. The
only change in this particular case is that the provider would build
specific rules on the translator to map the 6to4 prefix to an
appropriate provider assigned prefix.
The provider can use any prefix mapping strategy they so choose, but
the simpler the better. Simple direct bit mapping can be used such
as in Figure 2, or more advanced forms of translation can used to
achieve higher address compression.
Figure 2 shows a 6to4 Prefix with a Subnet-ID of "0000" mapped to a
provider globally unique prefix (2001:db8::/32). With this simple
form of translation, there is support for only one Subnet-ID per
provider assigned prefix. In characterization of deployed OSs and
gateways, a subnet-id of "0000" is the most common default case.
Pre-Relayed Packet [Provider Access Network Side]
0 16 32 48 64 80 96 112 128 Bits
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
2002 : 0C98 : 2C01 : 0000 : xxxx : xxxx : xxxx : xxxx
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| | | | | |
---- ---- | | | |
| | | | | |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
2001 : 0db8 : 0c98 : 2c01 : xxxx : xxxx : xxxx : xxxx
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
Post-Relayed Packet [Internet Side]
Figure 3: 6to4-PMT Prefix Mapping
Additional prefix compression techniques can be used such as those
described in [draft-tremblay-pt66ac]. These techniques would allow
for a more flexible implementation potentially supporting more
Subnet-IDs per provider prefix.
3.4. Translation State
It is preferred that the overall system use deterministic prefix
translation mappings such that stateless operation can be
implemented. This allows the provider to place N number of relays
within the network without the need to manage translation state.
If stateful is chosen, the operation would need to validate state and
routing requirements particular to that type of deployment full
Kuarsingh, et al. Expires August 5, 2011 [Page 6]
Internet-Draft 6to4 Provider Managed Tunnels February 2011
deployment considerations for this type of deployment are not within
this scope of this document.
4. Deployment Issues and Requirements
4.1. Customer Opt-out
A provider enabling this function should provide a method to allow
customers to opt-out of such a service should the customer choose to
maintain normal 6to4 operation irrespective of degraded performance.
Since the 6to4-PMT system is targeted at customers who are relatively
unaware of IPv6 and IPv4, and normally run network equipment with a
default configuration, an opt-out strategy is recommended. This
method provides the 6to4-PMT operation for non-IPv6 savvy customers
whose equipment may turn on 6to4 automatically.
Customers who are aware of IPv6 operation can request an opt-out, or
more appropriately use an automated mechanism to opt-out of the 6to4-
PMT operation. One automated opt-out strategy can include the use of
Subnet-Id triggers (well known IDs which are determined by policy in
the relay to not be translated). Other policy based strategies can
be employed by the provider to enable opt-out.
Capable customers can also disable anycast based 6to4 entirely and
use traditional 6to4 or other tunneling mechanisms if they are so
capable. This is not considered the normal case, and most endpoints
with auto-6to4 operation will be subject to 6to4-PMT operation
operation since most users are unaware of it's existence. 6to4-PMT is
targeted as an option for stable IPv6 connectivity for average
consumers.
4.2. ISP Shared Space Interaction
6to4-PMT operation can also be used to mitigate a known problem with
6to4 when ISP Shared Space
[draft-weil-shared-transition-space-request-01] or public but non-
routed IPv4 space is used. Public but un-routed address space would
cause many deployed OSs and network equipment to potentially auto-
enable 6to4 operation even without a valid return path. This use
case is considered highly likely based on points made in
[draft-weil-shared-transition-space-request] and in reports such as
[wide-tr-kato-as112-rep-01]
Such hosts, in normal cases, would send 6to4 traffic to the IPv6
Internet via the IPv4 anycast relay, which would in fact provide
broken IPv6 connectivity since the return path is based on an address
Kuarsingh, et al. Expires August 5, 2011 [Page 7]
Internet-Draft 6to4 Provider Managed Tunnels February 2011
that is not routed or assigned to the source Network. The use of
6to4-PMT would help reverse these effects by translating the 6to4
prefix to a provided assigned prefix, masking this automatic and
undesired behavior. It is conceivable that 6to4-PMT can also used to
help provide 6to4 operation with the use of ISP Shared Space.
4.3. End to End Transparency
6to4-PMT mode operation removes the traditional end to end
transparency of 6to4. Remote hosts would connect to a translated
IPv6 address versus the original 6to4 based prefix. This can be seen
as a disadvantage to the 6to4-PMT system. This lack of transparency
should also be contrasted with the normal operating state of 6to4
which provides uncontrolled and often high latency prone
connectivity. The lack of transparency is however a better form of
operation when extreme poor performance or broken connectivity is
considered as the alternative.
4.4. Routing Requirements
The provider would need to advertise the anycast IP range within the
IPv4 routing environment (service customers of interest) to attract
the 6to4 upstream traffic. To control this environment and make sure
all northbound traffic lands on a provider BR, the operator may
filter the anycast range form being advertised form customer
endpoints.
The provider would not be able to control route advertisements inside
the customer domain, but this use case is out of scope. It is likely
in this case the end network/customer understands IPv6 operation and
is maintaining their own environment.
The provider would also likely want to advertise the 2002::/16 range
within their own network to help bridge within their own network
(Native IPv6 to 6to4-IPv6 based endpoint).
5. IANA Considerations
No IANA considerations are defined at this time.
6. Security Considerations
6to4-PMT operation would be subject to the same security concerns as
normal 6to4 operation and with the operation of tunnels.
Considerations may also include operation modes related to Prefix
Translation. Additional considerations may be found after real
Kuarsingh, et al. Expires August 5, 2011 [Page 8]
Internet-Draft 6to4 Provider Managed Tunnels February 2011
deployment data is gathered or further analysis is made.
7. Acknowledgements
Thanks to the following people for their textual contributions and/or
guidance on 6to4 deployment considerations: Dan Wing, Scott Beuker,
JF Tremblay, John Brzozowski and Chris Donley
8. References
8.1. Normative References
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
8.2. Informative References
[I-D.mrw-nat66]
Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", draft-mrw-nat66-07 (work in progress),
January 2011.
[I-D.tremblay-pt66ac]
Tremblay, J. and S. Beuker, "Addressing bit compression
for stateless IPv6 prefix translation",
draft-tremblay-pt66ac-00 (work in progress),
November 2010.
[I-D.weil-shared-transition-space-request]
Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA Reserved IPv4 Prefix for Shared
Transition Space",
draft-weil-shared-transition-space-request-01 (work in
progress), November 2010.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
Kuarsingh, et al. Expires August 5, 2011 [Page 9]
Internet-Draft 6to4 Provider Managed Tunnels February 2011
Authors' Addresses
Victor Kuarsingh (editor)
Rogers Communications
8200 Dixie Road
Brampton, Ontario L6T 0C1
Canada
Email: victor.kuarsingh@rci.rogers.com
URI: http://www.rogers.com
Yiu L. Lee
Comcast
One Comcast Center
Philadelphia, PA 19103
U.S.A.
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Olivier Vautrin
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, CA 94089
U.S.A.
Email: olivier@juniper.net
URI: http://www.juniper.net
Kuarsingh, et al. Expires August 5, 2011 [Page 10]