v6ops V. Kuarsingh, Ed. Internet-Draft Rogers Communications Intended status: Informational Y. Lee Expires: March 30, 2012 Comcast O. Vautrin Juniper Networks September 27, 2011 6to4 Provider Managed Tunnels draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-04 Abstract 6to4 Provider Managed Tunnels (6to4-PMT) provide a framework which can help manage 6to4 [RFC3056] tunnels operating in an anycast [RFC3068] configuration. The 6to4-PMT framework is intended to serve as an option to operators 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 thus breaking the return path for anycast [RFC3068] based 6to4 operation. 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 March 30, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Kuarsingh, et al. Expires March 30, 2012 [Page 1] Internet-Draft 6to4 Provider Managed Tunnels September 2011 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 . . . . . . . . . . . . . . . . 5 3.1. 6to4 Provider Managed Tunnel Model . . . . . . . . . . . . 5 3.2. Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Prefix Translation . . . . . . . . . . . . . . . . . . . . 6 3.4. Translation State . . . . . . . . . . . . . . . . . . . . 7 4. Deployment Considerations and Requirements . . . . . . . . . . 7 4.1. Customer Opt-out . . . . . . . . . . . . . . . . . . . . . 7 4.2. Shared CGN Space Considerations . . . . . . . . . . . . . 8 4.3. End to End Transparency . . . . . . . . . . . . . . . . . 8 4.4. Path MTU Discovery Considerations . . . . . . . . . . . . 8 4.5. Routing Requirements . . . . . . . . . . . . . . . . . . . 9 4.6. Relay Deployments . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Kuarsingh, et al. Expires March 30, 2012 [Page 2] Internet-Draft 6to4 Provider Managed Tunnels September 2011 1. Introduction 6to4 [RFC3056] tunnelling along with the anycast operation described in [RFC3068] is widely deployed in modern Operating Systems and off the shelf gateways sold throughout the retail and OEM channels. Anycast [RFC3068] based 6to4 allows for tunnelled IPv6 connectivity through IPv4 clouds without explicit configuration of a relay address. Since the overall system utilizes anycast forwarding in both directions, flow paths are difficult to determine, tend to follow separate paths in either direction, and often change based on network conditions. The return path is normally uncontrolled by the local operator and can contribute to poor performance for IPv6, and can also act as a breakage point. Many of the challenges with 6to4 are described in [RFC6343]. A specific critical use case for problematic anycast 6to4 operation is related to conditions where the consumer endpoints are downstream from a northbound CGN [RFC6264] function when assigned non-RFC1918 IPv4 addresses, which are not routed on interdomain links. Operators which are actively deploying IPv6 networks and operate legacy IPv4 access environments may want to utilize the existing 6to4 behaviour in customer site resident hardware and software as an interim option to reach the IPv6 Internet in advance of being able to offer full native IPv6. Operators may also need to address the brokenness related to 6to4 operation originating from behind a provider NAT function. 6to4-PMT offers an operator the opportunity to utilize IPv6 Prefix Translation to enable deterministic traffic flow and an unbroken path to and from the Internet for IPv6 based traffic sourced originally from these 6to4 customer endpoints. 6to4-PMT translates the prefix portion of the IPv6 address from the 6to4 generated prefix 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 Many operators endeavour to deploy IPv6 as soon as possible so as to ensure uninterrupted connectivity to all Internet applications and content through the IPv4 to IPv6 transition process. The IPv6 preparations within these organizations are often faced with both financial challenges and timing issues related to deploying IPv6 to Kuarsingh, et al. Expires March 30, 2012 [Page 3] Internet-Draft 6to4 Provider Managed Tunnels September 2011 the network edge and related transition technologies. Many of the new technologies available for IPv4 to IPv6 transition will require the replacement of the customer CPE to support technologies like 6RD [RFC5969], Dual-Stack Lite [RFC6333] and Native Dual Stack. Operators face a number of challenges related to home equipment replacement. Operator initiated replacement of this equipment will take time due to the nature of mass equipment refresh programs or may require the consumer to replace their own gear. Replacing consumer owned and operated equipment, compounded by the fact that there is also a general unawareness of what IPv6 is, also adds to the challenges faced by operators. It is also important to note that 6to4 is found in much of the equipment found in networks today which do not as of yet, or will not, support 6RD and/or Native IPv6. Operators may still be motivated to provide a form of IPv6 connectivity to customers and would want to mitigate potential issues related to IPv6-only deployments elsewhere on the Internet. Operators also need to mitigate issues related to the fact that 6to4 operation often is on by default and may be subject to erroneous behaviour. The undesired behaviour may be related to the use of non- RFC1918 addresses on CPE equipment which operate behind large NATs, or other conditions as described in a general advisory as laid out in [RFC6343]. 6to4-PMT allows an operator to help mitigate such challenges by leveraging the existing 6to4 deployment base, 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. One of key objectives of 6to4-PMT is to also help reverse the negative impacts of 6to4 in CGN environments. The 6to4-PMT operation can also be used immediately with the default parameters which are often enough to allow it to operate in a 6to4-PMT environment. Once native IPv6 is available to the endpoint, the 6to4-PMT operation is no longer needed and will cease to be used based on correct address selection behaviours in end hosts [RFC3484]. 6to4-PMT thus helps operators remove the impact of 6to4 in CGN environments, deals with the fact that 6to4 is often on by default, allows access to IPv6-only endpoints from IPv4-only addressed equipment and provides relief from many challenges related to mis- configuations in other networks which control return flows via foreign relays. Due to the simple nature of 6to4-PMT, it can also be implemented in a cost effective and simple manner allowing operators to concentrate their energy on deploying Native IPv6. Kuarsingh, et al. Expires March 30, 2012 [Page 4] Internet-Draft 6to4 Provider Managed Tunnels September 2011 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 encapsulated 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. | 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 operator's IPv6 peering operations. Egress traffic is managed through outgoing routing policy, and incoming traffic is influenced by the operator assigned prefix advertisements using normal interdormain routing functions. The routing model is as predictable as native IPv6 traffic and legacy IPv4 based traffic. Figure 2 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. Kuarsingh, et al. Expires March 30, 2012 [Page 5] Internet-Draft 6to4 Provider Managed Tunnels September 2011 | 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 Propagation Figure 2: 6to4-PMT Flow Model Traffic between two 6to4 enabled devices would use the IPv4 path for communication according to RFC3056 unless the local host still prefers traffic via a relay. 6to4-PMT is intended to be deployed in conjunction with the 6to4 relay function in an attempt to help simplify it's deployment. The model can also provide the ability for an operator to forward both 6to4-PMT (translated) and normal 6to4 flows (untranslated) simultaneously based on configured policy. 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 [RFC3056] and IPv6 Prefix Translation. IPv6 Prefix Translation has some similarities to concepts discussed in [RFC6296]. 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 3, or more advanced forms of translation can be used to achieve higher address compression. More advanced forms of translation may force the use of stateful translation. Figure 3 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 followed by Subnet ID "0001". Use of Subnet ID can be referenced in [RFC4291]. It should be noted that in normal 6to4 operation the endpoint (network) has access to 65,536 (16-bits) Subnet IDs. In the PMT case as shown above, all but the one Subnet ID used for PMT would still operate under normal 6to4 operation. Kuarsingh, et al. Expires March 30, 2012 [Page 6] Internet-Draft 6to4 Provider Managed Tunnels September 2011 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 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. Deterministic translation also allows a customer to use inward services using the translated (provider prefix) address. If stateful operation is chosen, the operator would need to validate state and routing requirements particular to that type of deployment. The full body of considerations for this type of deployment are not within this scope of this document. 4. Deployment Considerations 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. In cases where the customer is behind a CGN device, the customer would not be advised to opt-out and can also be assisted to turn off 6to4. 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 and allows savvy Kuarsingh, et al. Expires March 30, 2012 [Page 7] Internet-Draft 6to4 Provider Managed Tunnels September 2011 customers to easily configure their way around the 6to4-PMT function. Capable customers can also disable anycast based 6to4 entirely and use traditional 6to4 or other tunnelling mechanisms if they are so inclined. This is not considered the normal case, and most endpoints with auto-6to4 operation will be subject to 6to4-PMT 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. Shared CGN Space Considerations 6to4-PMT operation can also be used to mitigate a known problem with 6to4 when Shared CGN Space [I-D.weil-shared-transition-space-request] or Global Unicast Addresses (GUA) that are used behind a CGN and not routed on the Internet. 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 (such as behind a CGN function). The Operators' desire to use GUA or Shared CGN Space is considered highly likely based on points made in [I-D.bdgks-arin-shared-transition-space]. 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 flow is built using an address 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 behaviour. 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 address based on the 2002::/16 prefix. This can be seen as a disadvantage of 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, broken IPv6 connectivity, or no IPv6 connectivity is considered as the alternative. 4.4. Path MTU Discovery Considerations The MTU will be subject to a reduced value due to standard 6to4 tunnelling operation. Under normal 6to4 operation, the 6to4 service agent would send an ICMP Packet Too Big Message as part of Path MTU Discovery as described in [RFC4443] and [RFC1981] respectively. In Kuarsingh, et al. Expires March 30, 2012 [Page 8] Internet-Draft 6to4 Provider Managed Tunnels September 2011 PMT operation, the PMT Service agent should be aware of the reduced 6to4 MTU and send ICMP messages using the translated address accordingly. It is also possible to pre-constrain the MTU at the upstream router from the 6to4-PMT service agents which would then have the upstream router send the appropriate ICMP Packet Too Big Messages. 4.5. Routing Requirements The provider would need to advertise the anycast IP range used for normal 6to4/RFC3068 operation within the IPv4 routing environment (devices to be serviced) 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 from being advertised from customer endpoints toward the network (upstream propagation). The provider would not be able to control route advertisements inside the customer domain, but this use case is out of this document's scope. It is likely in this case the end network/customer understands 6to4 and is maintaining their own relay environment and therefore would not be subject to the operators 6to4 and/or PMT operation. The provider would also likely want to advertise the 2002::/16 range within their own network to help bridge traditional 6to4 traffic within their own network (Native IPv6 to 6to4-PMT based endpoint). 4.6. Relay Deployments The 6to4-PMT function can be deployed onto existing 6to4 relays (if desired) to help minimize network complexity. 6ot4-PMT has already been developed on Linux based platforms which are package add-ons to the traditional 6to4 code. The only additional considerations beyond normal 6to4 relay operation would include the need to route specific IPv6 provide prefix ranges towards peers and the Internet. 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. 6to4-PMT is Kuarsingh, et al. Expires March 30, 2012 [Page 9] Internet-Draft 6to4 Provider Managed Tunnels September 2011 also not plainly perceptible by external hosts and entities appear as Native IPv6 hosts. 7. Acknowledgements Thanks to the following people for their textual contributions and/or guidance on 6to4 deployment considerations: Dan Wing, Wes George, Scott Beuker, JF Tremblay, John Brzozowski, Chris Metz and Chris Donley Additional thanks to the following for assisting with the coding and testing of 6to4-PMT: Marc Blanchet, John Cianfarani, Tom Jefferd and Nik Lavorato 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.bdgks-arin-shared-transition-space] Barber, S., Delong, O., Grundemann, C., Kuarsingh, V., and B. Schliesser, "ARIN Draft Policy 2011-5: Shared Transition Space", draft-bdgks-arin-shared-transition-space-03 (work in progress), September 2011. [I-D.weil-shared-transition-space-request] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA Reserved IPv4 Prefix for Shared CGN Space", draft-weil-shared-transition-space-request-06 (work in progress), September 2011. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Kuarsingh, et al. Expires March 30, 2012 [Page 10] Internet-Draft 6to4 Provider Managed Tunnels September 2011 Architecture", RFC 4291, February 2006. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011. [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011. Authors' Addresses Victor Kuarsingh (editor) Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada Email: victor.kuarsingh@gmail.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 Kuarsingh, et al. Expires March 30, 2012 [Page 11] Internet-Draft 6to4 Provider Managed Tunnels September 2011 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 March 30, 2012 [Page 12]