RFC 6732
6to4 Provider Managed Tunnels
6to4 Provider Managed Tunnels 🧚
okay bestie, this is RFC 6732 🎀 and the whole thing is about 6to4 Provider Managed Tunnels (6to4-PMT for short) 💖 Here's the title block tea ☕
- Stream: Independent Submission 🌸
- Category: Informational (so it's not standards track, more on that below 👀)
- ISSN: 2070-1721
- Date: September 2012
- Authors: V. Kuarsingh, Ed. (Rogers Communications), Y. Lee (Comcast), and O. Vautrin (Juniper Networks) 🫶
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates ✨
Abstract 💅
6to4-PMT is a framework that helps manage 6to4 tunnels running in an anycast configuration 🦋 It's meant to be an option for operators who want a better 6to4 experience when the network is giving sub-optimal performance or is straight up breaking normal 6to4 operation 😭
So how does it work? 6to4-PMT gives you a stable provider prefix and a stable forwarding environment by using the 6to4 relays you already have, plus one extra trick: IPv6 Prefix Translation 🔥 This matters a LOT in NAT444 setups, where a customer endpoint might get a non-RFC1918 address. That breaks the return path for anycast 6to4 (not it 💀).
Also, the receipts: 6to4-PMT has been used successfully in a production network, it's implemented as open source code, and a major routing vendor has implemented it too 👑
Status of This Memo 📜
Okay, the status stuff: this document is not an Internet Standards Track specification. It's published for informational purposes 💜
It's a contribution to the RFC Series, independent of any other RFC stream ✨ The RFC Editor picked to publish it at their discretion and makes no statement about its value for implementation or deployment 🙈 Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741 💅
Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc6732 🌈
Copyright Notice 🌸
Copyright (c) 2012 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) as they're in effect on the date this document was published. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 🫶
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 ..........................9
4.5. Checksum Management ........................................9
4.6. Application Layer Gateways .................................9
4.7. Routing Requirements .......................................9
4.8. Relay Deployments .........................................10
5. Security Considerations ........................................10
6. Acknowledgements ...............................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................111. Introduction ✨
okay so, 6to4 [RFC3056] tunneling, along with the anycast operation in [RFC3068], is everywhere 🌍 It's built into modern Operating Systems and into off-the-shelf gateways sold through retail and Original Equipment Manufacturer (OEM) channels 💖 Anycast-based 6to4 [RFC3068] gives you tunneled IPv6 connectivity across IPv4 clouds with no explicit relay address config needed, which is so convenient 🎀
BUT here's the catch 🙈 the whole system uses anycast forwarding in both directions, so flow paths are hard to figure out, they tend to take separate paths in each direction, and they often shift with network conditions 🌀 The return path is usually out of the local operator's control, which can make IPv6 performance poor and can also become a breakage point 💀 A lot of the challenges with 6to4 are covered in [RFC6343] 📖
The really critical use case for problematic anycast 6to4 is when consumer endpoints sit downstream from a northbound Carrier-Grade NAT (CGN) [RFC6264] function and get non-RFC1918 IPv4 addresses, which aren't routed on interdomain links 😭
Operators who are actively deploying IPv6 networks while still running legacy IPv4 access environments may want to use the existing 6to4 behavior in customer site resident hardware and software 🦋 That's an interim option to reach the IPv6 Internet before they can offer full native IPv6 ✨ Operators may also need to deal with the brokenness of 6to4 that comes from behind a provider NAT function 🫠 This is where 6to4-PMT comes in 🧚 It lets an operator use IPv6 Prefix Translation for deterministic traffic flow and an unbroken path to and from the Internet for IPv6 traffic that started at these 6to4 customer endpoints 👑
6to4-PMT translates the prefix portion of the IPv6 address from the 6to4-generated prefix to a provider-assigned prefix that represents the source 💅 That translation gives a stable forward and return path for the 6to4 traffic, because the existing IPv6 routing and policy environment gets to control the traffic 🌈 6to4-PMT is mainly meant to be used in a stateless manner, so it keeps many of the elements inherent in normal 6to4 operation 🌸 Or, if the operator prefers, 6to4-PMT can run in a stateful translation mode instead 💜
2. Motivation 🦋
Lots of operators are trying to deploy IPv6 as soon as possible so their customers keep uninterrupted connectivity to all Internet applications and content during the IPv4 to IPv6 transition 🚀 But the IPv6 prep inside these organizations often runs into money problems and timing issues when it comes to deploying IPv6 to the network edge and the related transition technologies 😩 Many of the new IPv4 to IPv6 transition technologies need the organization's Customer Premises Equipment (CPE) replaced to support things like IPv6 Rapid Deployment (6RD) [RFC5969], Dual-Stack Lite [RFC6333], and native dual-stack 🔧
Operators have a bunch of home equipment replacement problems too ☹️ When the operator starts the replacement, it takes forever because of mass equipment refresh programs, or the consumer has to replace their own gear 🙃 Replacing consumer-owned and operated equipment is extra hard because lots of people just aren't aware of what IPv6 is 🫥 And it's important to know that 6to4 is built into much of the equipment in networks today that doesn't yet support 6RD and/or native IPv6, or never will 💀
Operators may still want to provide some form of IPv6 connectivity to customers, and they'd like to mitigate potential issues from IPv6-only deployments elsewhere on the Internet 🌐 Operators also need to deal with the fact that 6to4 is often on by default and can be subject to erroneous behavior 🤨 That unwanted behavior can come from using non-RFC1918 addresses on CPE equipment that sits behind large operator NATs, or from other conditions described in a general advisory in [RFC6343] 📜
6to4-PMT lets an operator tackle these challenges by building on the existing 6to4 deployment base while keeping operator control over access to the IPv6 Internet 👑 It's meant for when better options, like 6RD or native IPv6, aren't viable yet 🌸 One of the key goals of 6to4-PMT is to help reverse the negative impacts of 6to4 in CGN environments 🦋 6to4-PMT can also be used right away with default parameters, and those are often enough for it to run in a 6to4-PMT environment ✨ Once native IPv6 is available to the endpoint, 6to4-PMT isn't needed anymore and will stop being used, thanks to correct address selection behaviors in end hosts [RFC6724] 🫶
So, to recap bestie 🎀 6to4-PMT helps operators remove the impact of 6to4 in CGN environments, deals with the fact that 6to4 is often on by default, and lets IPv6-only endpoints be reached from IPv4-only addressed equipment 💖 It also gives relief from lots of challenges caused by mis-configurations in other networks that control return flows via foreign relays 🙌 And because 6to4-PMT is so simple, it can be implemented in a cost-effective way, so operators can focus their energy on deploying native IPv6 💅
3. 6to4 Provider Managed Tunnels 🌈
3.1. 6to4 Provider Managed Tunnel Model 🍓
The 6to4 managed tunnel model acts like a standard 6to4 service between the customer IPv6 host or gateway and the 6to4-PMT Relay (which lives inside the provider domain) 🧚 The 6to4-PMT Relay shares properties with 6RD [RFC5969] by decapsulating and forwarding encapsulated IPv6 flows inside an IPv4 packet to the IPv6 Internet 🦋 The model adds an extra function that translates the source 6to4 prefix to a provider-assigned prefix, which you won't find in 6RD [RFC5969] or traditional 6to4 operation ✨
The 6to4-PMT Relay is meant 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 ModelThis mode of operation is seen as beneficial compared to broken 6to4 paths, and also in environments where 6to4 technically works but is highly degraded 🌸🫶
3.2. Traffic Flow 🦋
okay so traffic in the 6to4-PMT model is meant to be steered by the operator's IPv6 peering ops 💅 Outgoing traffic gets handled by outgoing routing policy, and incoming traffic gets nudged by the prefix advertisements the operator hands out, using the normal interdomain routing stuff 🌸
the routing vibe is as predictable as native IPv6 traffic and legacy IPv4 traffic, which is lowkey iconic ✨ Figure 2 shows the routing topology that makes this relay setup work 🧚 The diagram calls PrefixA 2002::/16 and PrefixB 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 Propagation
Figure 2: 6to4-PMT Flow Modeltraffic between two 6to4-enabled devices would take the IPv4 path, following [RFC3056], unless the local host still prefers going through a relay 🫶 6to4-PMT is meant to be deployed alongside the 6to4 relay function so it's easier to roll out, which is so smart 🧠 The model can also let an operator forward both 6to4-PMT (translated) and normal 6to4 (untranslated) flows at the same time, based on configured policy 🎀
3.3. Prefix Translation 💖
IPv6 Prefix Translation is a key part of the whole system 👑 6to4-PMT is basically two concepts glued together: 6to4 [RFC3056] and IPv6 Prefix Translation 🌈 The translation bit has some similarities to ideas in [RFC6296] 🙈 6to4-PMT provides prefix translation based on specific rules configured on the translator, which maps the 6to4 2002::/16 prefix to an appropriate provider-assigned prefix 💅 In most cases a ::/32 prefix works best in 6to4-PMT, since it matches the common Regional Internet Registry (RIR) prefix assignments to operators 🍓
the provider can use whatever prefix mapping strategy they want, but honestly the simpler the better 🫠 Simple direct bitmapping works, or fancier translation if the operator wants more address compression. Fancier translation may need stateful translation, though ✨
Figure 3 shows a 6to4 Prefix with Subnet-ID "0000" mapped to a provider-assigned, globally unique prefix (2001:db8::/32) 🦋 With this simple form of translation, only one Subnet-ID per provider-assigned prefix is supported. When people characterize deployed OSs and gateways, Subnet-ID "0000" is the most common default, followed by Subnet-ID "0001" 💜 You can look up the Subnet-ID stuff in [RFC4291] 📖 It's worth noting that in normal 6to4 operation, the endpoint (network) gets access to 65,536 (16-bits) Subnet IDs 😭 In the 6to4-PMT case using the mapping in Figure 3, all but the one Subnet-ID used for 6to4-PMT still work under normal 6to4 operation 🌸
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 Mapping3.4. Translation State 🧚
it's preferred that the overall system uses deterministic prefix translation mappings so stateless operation can be implemented 🎀 That lets the provider put N relays in the network without having to manage translation state, which is giving efficiency 💅 Deterministic translation also lets a customer run inward services using the translated (provider prefix) address 🫶
if stateful operation is chosen, the operator would need to validate state and routing requirements specific to that kind of deployment 😬 The full set of considerations for that is not within the scope of this document, so it's a whole other story 📚
4. Deployment Considerations and Requirements ✨
4.1. Customer Opt-Out 🙈
a provider enabling this function should offer a way for customers to opt out, in case they want to keep normal 6to4 operation even if performance gets worse 💖 When the customer is behind a CGN device, they wouldn't be advised to opt out, and they can be helped with turning off 6to4 🫶
since 6to4-PMT is aimed at customers who are pretty unaware of IPv6 and IPv4 and usually run network gear on default settings, an opt-out strategy is recommended 🌈 It gives non-IPv6-savvy customers 6to4-PMT operation even when their equipment turns on 6to4 automatically, and it lets savvy customers easily configure their way around the 6to4-PMT function 💅
capable customers can also turn off anycast-based 6to4 entirely and use traditional 6to4 or other tunneling mechanisms if they want 🦋 This isn't the normal case though. Most endpoints with auto-6to4 functions will end up on 6to4-PMT operation because most users have no idea it exists 😭 6to4-PMT is meant to be an option for stable IPv6 connectivity for everyday consumers 🍓
4.2. Shared CGN Space Considerations 🌸
6to4-PMT operation can also help with a known 6to4 problem that happens when shared address space [RFC6598] or Global Unicast Addresses (GUA) are used behind a CGN and aren't routed on the Internet 💀 Non-RFC1918 but unrouted (on interdomain links) address space can make lots of deployed OSs and network equipment auto-enable 6to4 even without a valid return path (like behind a CGN function) 🙈 The operator's wish to use non-RFC1918 addresses, such as shared address space [RFC6598], is considered highly likely based on real-world deployments 🔥
in normal cases, these hosts would send 6to4 traffic to the IPv6 Internet via the anycast relay, which would actually give broken IPv6 connectivity 😭 The return path flow is built using an IPv4 address that isn't routed or assigned to the source network, so it just doesn't work 💀 6to4-PMT helps reverse this by translating the 6to4 prefix to a provider-assigned prefix, which masks this automatic and unwanted behavior 🫶
4.3. End-to-End Transparency 🦋
the 6to4-PMT mode of operation removes the traditional end-to-end transparency of 6to4 🥺 Remote hosts connect to a 6to4-PMT-serviced host using a translated IPv6 address instead of the original 6to4 address based on the 2002::/16 well-known prefix. This can be seen as a disadvantage of the 6to4-PMT system 💅 This lack of transparency should be contrasted with normal 6to4, which gives connectivity that's uncontrolled and often prone to high latency 😬 Still, the lack of transparency is a better deal when the alternatives are extreme poor performance, broken IPv6 connectivity, or no IPv6 connectivity at all 💖
4.4. Path MTU Discovery Considerations 🌈
the MTU will get a reduced value because of standard 6to4 tunneling 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 6to4-PMT operation, the PMT Service agent should be aware of the reduced 6to4 MTU and send ICMP messages using the translated address accordingly ✨
it's also possible to pre-constrain the MTU at the upstream router from the 6to4-PMT service agents, which then has the upstream router send the appropriate ICMP Packet Too Big Messages 🌸
4.5. Checksum Management 🧚
checksum management for 6to4-PMT can be done in one of two ways 💜 The first deployment model is based on the stateless 6to4-PMT operational mode. In this case, checksum modifications are made using the method described in [RFC3022], Section 4.2. The checksum is modified to match the parameters of the translated address of the source 6to4-PMT host 🔥 In the second deployment model, where stateful 6to4-PMT translation is used, the vendor can implement checksum-neutral mappings as defined in [RFC6296] 🦋
4.6. Application Layer Gateways 💅
vendors can choose to deploy Application Layer Gateways (ALGs) on their platforms that perform 6to4-PMT if they want to 🫶 No ALGs were deployed as part of the open source and vendor product deployments of 6to4-PMT. In the vendor deployment case, the same rules were used as with their NPTv6 [RFC6296] base code 🍓
4.7. Routing Requirements 👑
the provider would need to advertise the well-known IP address range used for normal anycast 6to4 [RFC3068] operation within the local IPv4 routing environment 📡 This advertisement attracts the 6to4 upstream traffic to a local relay. To keep control of this and make sure all northbound traffic lands on a provider-controlled relay, the operator may filter the anycast range so it isn't advertised from customer endpoints toward the local network (upstream propagation) 💖
the provider wouldn't be able to control route advertisements inside the customer domain, but that use case is out of scope for this document 🙈 In that case, the end network/customer probably understands 6to4 and maintains their own relay environment, so they wouldn't be subject to the operator's 6to4 and/or PMT operation 🌈
within their own network, the provider would also likely want to advertise the 2002::/16 range to help bridge traditional 6to4 traffic inside the network (native IPv6 to 6to4-PMT-based endpoint) ✨ It's also advised that the local 6to4-PMT operator not leak the well-known 6to4 anycast IPv4 prefix to neighboring Autonomous Systems, so PMT operation doesn't kick in for neighboring networks 🚫 Policy configuration on the local 6to4-PMT Relay can also disallow PMT operation if the local provider serves downstream customer networks 🎀
4.8. Relay Deployments 🧚♀️
the 6to4-PMT function can be deployed onto existing 6to4 relays (if you want) to help keep network complexity and cost down 💅 6to4-PMT has already been developed on Linux-based platforms as package add-ons to the traditional 6to4 code 🐧 The only extra considerations beyond normal 6to4 relay operation are routing the specific IPv6 provider prefix ranges used for 6to4-PMT operation toward peers and transit providers 🦋
5. Security Considerations 💀
🚨 Heads up, bestie: 6to4-PMT operation would be subject to the same security concerns as normal 6to4 operation, as described in [RFC6169]. 6to4-PMT is also not plainly perceptible by external hosts, and local entities appear as native IPv6 hosts to those external hosts 😭 Take this one seriously, periodt 💅
6. Acknowledgements ✨
okay bestie, the thank-you list is my favourite part because it's literally everyone who helped make this happen 🫶 Huge shoutout to Dan Wing, Wes George, Scott Beuker, JF Tremblay, John Brzozowski, Chris Metz, and Chris Donley for their text and for guiding us on 6to4 deployment stuff. 💖
And the coding and testing crew for 6to4-PMT deserves a whole parade 🎀: Marc Blanchet, John Cianfarani, Tom Jefferd, Nik Lavorato, Robert Hutcheon, and Ida Leung. Literally iconic. 👑
7. References 🦋
7.1. Normative References
These are the ones you need to read before you even think about implementing 🧚
- [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.
7.2. Informative References
These ones are the background reading, super helpful but not strictly required 📚
- [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
- [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
- [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
- [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "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.
- [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
- [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.
- [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
- [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
Authors' Addresses 💅
Here's where to find the authors, with their contact details exactly as they wrote them 💌
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
Olivier Vautrin
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, CA 94089
U.S.A.
EMail: olivier@juniper.net
URI: http://www.juniper.netAnd that's the whole thing, bestie! You made it through all three parts 🌈✨🎀 periodt.
📦 where this page comes from
- ietf: rfc6732 2012-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms