RFC 6782
Wireline Incremental IPv6
Wireline Incremental IPv6 💖
okay bestie, this is RFC 6782 🎀, and it's titled Wireline Incremental IPv6. Here are the basics:
- Authors: V. Kuarsingh, Ed. (Rogers Communications) and L. Howard (Time Warner Cable) 🧚
- Category: Informational
- ISSN: 2070-1721
- Date: November 2012
- Obsoletes and updates: the title block doesn't list any RFCs that this one obsoletes or updates 🦋
Abstract ✨
operators all over the world are at different stages of getting ready for IPv6 or actually deploying it 🌍. They're dealing with tricky stuff around IPv6 introduction and IPv4 run-out 😭. They need to keep IPv6 connectivity going while also supporting IPv4 for legacy devices, even though the supply of IPv4 addresses is basically stuck 💀. The IPv6 transition will move most networks from IPv4-only to an IPv6-dominant setup, and how long that takes depends on the operator 🌸. This doc gives wireline providers a framework for bringing in IPv6 while still meeting legacy IPv4 needs, using well-defined transition technologies that you can actually buy off the shelf 💅.
Status of This Memo 📚
this document is not an Internet Standards Track specification. It's published just for informational purposes 🎀.
this document is a product of the Internet Engineering Task Force (IETF) 🫶. It represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑. Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🙈.
info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc6782 🔥.
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 were in effect on the date of publication 📜. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⚖️.
Table of Contents 🗂️
1. Introduction ....................................................4
2. Operator Assumptions ............................................4
3. Reasons and Considerations for a Phased Approach ................5
3.1. Relevance of IPv6 and IPv4 .................................6
3.2. IPv4 Resource Challenges ...................................6
3.3. IPv6 Introduction and Operational Maturity .................7
3.4. Service Management .........................................8
3.5. Suboptimal Operation of Transition Technologies ............8
3.6. Future IPv6 Network ........................................9
4. IPv6 Transition Technology Analysis .............................9
4.1. Automatic Tunneling Using 6to4 and Teredo .................10
4.2. Carrier-Grade NAT (NAT444) ................................10
4.3. 6rd .......................................................11
4.4. Native Dual Stack .........................................11
4.5. DS-Lite ...................................................12
4.6. NAT64 .....................................................12
5. IPv6 Transition Phases .........................................13
5.1. Phase 0 - Foundation ......................................13
5.1.1. Phase 0 - Foundation: Training .....................13
5.1.2. Phase 0 - Foundation: System Capabilities ..........14
5.1.3. Phase 0 - Foundation: Routing ......................14
5.1.4. Phase 0 - Foundation: Network Policy and Security ..15
5.1.5. Phase 0 - Foundation: Transition Architecture ......15
5.1.6. Phase 0 - Foundation: Tools and Management .........16
5.2. Phase 1 - Tunneled IPv6 ...................................16
5.2.1. 6rd Deployment Considerations ......................17
5.3. Phase 2 - Native Dual Stack ...............................19
5.3.1. Native Dual Stack Deployment Considerations ........20
5.4. Intermediate Phase for CGN ................................20
5.4.1. CGN Deployment Considerations ......................22
5.5. Phase 3 - IPv6-Only .......................................23
5.5.1. DS-Lite ............................................23
5.5.2. DS-Lite Deployment Considerations ..................24
5.5.3. NAT64 Deployment Considerations ....................25
6. Security Considerations ........................................26
7. Acknowledgements ...............................................26
8. References .....................................................26
8.1. Normative References ......................................26
8.2. Informative References ....................................261. Introduction 🦋
okay so this doc is here to help wireline operators plan their IPv6 rollouts while still keeping IPv6-incapable consumer devices and apps working 🫶. It figures out which technologies can be used step by step to go from IPv4-only to an IPv6-dominant setup that supports Dual Stack operation 💜. The end goal for most operators is IPv6-only, but how they get there depends a lot on how much legacy gear is sitting in end networks and how they manage the long tail of IPv4-only content 🙈. No single plan will fit every operator, but the options here give you a baseline that many plans can build on ✨.
this document is aimed at wireline environments that use cable, DSL, and/or fiber as the access method to the end consumer 🧚. It tries to follow the principles in [RFC6180], which gives guidance on using IPv6 transition mechanisms 📖. The main focus is on the technologies that enable and mature IPv6 inside the operator's network, though it also gives a quick look at keeping IPv4 connectivity going 🌈. The transition technologies covered are the ones that are readily available in off-the-shelf Customer Premises Equipment (CPE) devices and commercially available network equipment 💅.
2. Operator Assumptions 🎀
for the purposes of this document, the authors assume the following 🤍:
- The operator is considering deploying IPv6 or is in the process of deploying IPv6.
- The operator has a legacy IPv4 subscriber base that will continue to exist for a period of time.
- The operator will want to minimize the level of disruption to the existing and new subscribers.
- The operator may also want to minimize the number of technologies and functions that are needed to mediate any given set of subscribers' flows (overall preference for native IP flows).
- The operator is able to run Dual Stack in its own core network and is able to transition its own services to support IPv6.
based on these assumptions, an operator will want to use technologies that minimize the need to tunnel, translate, or mediate flows 🔥. That helps optimize traffic flow and lowers the cost impacts of transition technologies 💰. transition technology selections should be made to mediate the non-dominant IP family flows, and to let native routing (IPv4 and/or IPv6) forward the dominant traffic whenever possible ✨. That way the operator keeps costs down by keeping the transition technology deployment size small 🍓.
an operator may also choose to lean into more IPv6-focused models, where transition technologies are used to enable IPv6 at the base layer as soon as possible 🚀. Some operators may want to push IPv6 early in the deployment so IPv6 traffic performs optimally from the start 👑. That desire has to be weighed against the cost and support impacts of such a choice, and against the quality of experience offered to subscribers 🙏.
3. Reasons and Considerations for a Phased Approach 🧚
when operators face the challenges from the introduction, they may want to consider a phased approach when adding IPv6 to an existing subscriber base 💖. A phased approach lets the operator add IPv6 without ignoring legacy IPv4 connection requirements 🫶. Some of the main challenges the operator will run into include the following 😭:
- IPv4 exhaustion may happen long before all traffic can be delivered over IPv6, which makes IPv4 address sharing necessary 💀.
- IPv6 will pose operational challenges, since some of the software is pretty new and hasn't had much run time in large production environments, and organizations aren't used to supporting IPv6 as a service 🙈.
- Connectivity modes will move from IPv4-only to Dual Stack in the home, which changes functional behaviors in the consumer network and raises support requirements for the operator 🏠.
- IPv6 support on CPEs is a newer thing, but there's a strong push from operators and the industry as a whole to enable IPv6 on devices 🌸. As demand grows, IPv6 enablement won't be optional anymore and will be necessary on CPEs 🔥. Documents like [RFC6540] are useful tools in the short term for helping vendors and implementors understand what "IPv6 support" means 📖.
these challenges will play out over a period of time, which means the operator's plans have to keep up with the ever-changing requirements of the network and subscriber demand 🦋. Phases are presented in this document, but not every operator needs to enable each discrete phase 🌈. Characteristics of individual networks may let certain operators skip or jump to various phases ✨.
3.1. Relevance of IPv6 and IPv4 💅
the delivery of high-quality unencumbered Internet service should be the primary goal for operators 👑. With IPv4 about to run out, IPv6 will offer the highest quality of experience in the long term 🚀. Even if the operator is focused on IPv6 delivery, it should be aware that both IPv4 and IPv6 will play a role in the Internet experience during the transition 🫶. The Internet is made up of many interconnecting systems, networks, hardware, software, and content sources, and all of them will support IPv6 at different rates 🌍.
Lots of subscribers use older operating systems and hardware that only support IPv4 🥹. Internet subscribers don't buy IPv4 or IPv6 connections. They buy Internet connections, and those demand support for both IPv4 and IPv6 for as long as the subscriber's home network needs it 💜. The operator may be able to lean on one protocol or the other to help bridge connectivity on the operator's network, but the home network will most likely need both IPv4 and IPv6 for some time 🎀.
3.2. IPv4 Resource Challenges ✨
okay so connecting to IPv4-only endpoints and content is gonna stay super common 😭, which means IPv4 resource problems are a big deal for operators 💅. There are no new IPv4 addresses to hand out for extra devices, so keeping up with IPv4 demand in some networks is going to require address sharing 🫶.
Networks are growing at different speeds 🌈. Emerging markets are growing, and so are established networks because of all the internet services and devices everywhere. IPv4 address limits will probably hit many operators (maybe most of them) at some point, and that makes IPv6 even more worth it 💜. IPv4 address exhaustion is something to think about when picking technologies that depend on IPv4 to deliver IPv6 services, like 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures) [RFC5969] 🦋. And if an operator goes with native Dual Stack, IPv4 address exhaustion is still a concern 🙈.
Some operators might be able to get back a few IPv4 addresses through efficiency tweaks in the network 🍓. Still, that won't do much long-term and won't cover the longer-term connectivity needs 💀. Secondary markets for IPv4 addresses have also started popping up, but nobody really gets how that'll fit with overall demand for Internet growth 🤷♀️. Address transfers are also subject to market prices and transfer rules set by the Regional Registries 💅.
So the lack of new global IPv4 address allocations is going to force operators to support some kind of IPv4 address sharing, and it may change which transition options they have once they run out of new IPv4 addresses to assign 😭🎀.
3.3. IPv6 Introduction and Operational Maturity ✨
bestie, bringing in IPv6 means new operational practices 🧚. The IPv4 setup we have today was built over many years and got mature through experience 🌸. Lots of those experiences carry over from IPv4 to IPv6, but there will still be new experience and practices that are specific to IPv6 💖.
Engineering and operations teams need to build up their IPv6 experience 🫶. Being new at it can lead to early deployment instability, so operators should think about that when they pick technologies for the first transition phase ✨. Operators may not want to put their mature IPv4 service on a "new IPv6" path right away while it's going through growing pains 😬. Dual Stack Lite (DS-Lite) [RFC6333] and NAT64 [RFC6146] are both technologies that need IPv6 in order to support connectivity to IPv4 endpoints or content over an IPv6-only access network 🦋.
Some of these transition technologies are brand new and still need to be refined with running code 🔥. Deployment experience is needed to uncover bugs and make software stable in production environments 💅. A lot of the supporting systems are also still in development and have newly built IPv6 features, including vendor implementations of DHCPv6, management tools, monitoring systems, diagnostic systems, and logging, plus other pieces too 🌈.
Even though the basic technology to enable and run IPv6 exists in most environments, organizational experience is still low 😭. Until each key technical person in an operator's organization can identify IPv6, understand why it matters to the IP service offering, know how it works, and know how to troubleshoot it, the deployment has to mature and may be subject to events that affect subscribers 🙈. This shouldn't make operators put off IPv6 deployment ✨. It should push them to deploy IPv6 sooner, so they get the experience they really need before IPv6 becomes the only way to connect new hosts to the network 👑.
It's also worth knowing that while many transition technologies are new, and some code for access environments is new too, there's a big chunk of the networking fabric that has had IPv6 available for a long time and has had lots of production exposure 💜. Operators can use that to their advantage by enabling IPv6 in the core network first and then working outward toward the subscriber edge 🧚🎀.
3.4. Service Management ✨
Most networks manage their services by gleaning and monitoring the IPv4 addresses assigned to endpoints 🍓. Operators will need to update those management tools, troubleshooting methods, and storage facilities (like databases) to handle not only new address types with 128-bit IPv6 addresses [RFC2460] but also often both IPv4 and IPv6 at the same time 😭. Looking at address types, and recording delegated prefixes alongside single address assignments, will probably require more development work 💅.
With any Dual Stack service (native, 6rd-based, DS-Lite, NAT64, or some other service), two address families may need to be managed at once so the full Internet experience can be delivered 🌈. That means IPv6 management isn't just a simple add-in. It needs to be properly integrated into the service management infrastructure 🫶. In the early transition phases, it's pretty likely that many systems will get missed, and IPv6 services will go unmonitored, so problems will go undetected 💀.
These issues are worth considering when picking technologies that use IPv6 as the base protocol to deliver IPv4 connectivity 🦋. If the IPv6 service is unstable in that case, the IPv4 services would be affected too 😬🔥.
3.5. Suboptimal Operation of Transition Technologies ✨
Native delivery of IPv4 and IPv6 is a solid foundation for delivering Internet services to subscribers 👑. Native IP paths are well understood, and networks are often optimized to send that traffic efficiently 💅. Transition technologies, though, may change the normal path of traffic or lower the path MTU, which removes many network efficiencies that were built for native IP flows 😭. Tunneling and translation devices may not sit on the most optimal path in line with the natural traffic flow (based on route computation), so they may increase latency 🙈. These paths can also add extra points of failure 💀.
Generally, the operator will want to deliver native IPv6 as soon as possible and only use transition technologies when they're required 🧚. Transition technologies can be used to keep providing access to IPv4 through tunneling and/or translation, or they can be used to deliver IPv6 connectivity 🦋. Operators should think about how Internet or internal services get delivered, since supplying connections through a transition technology will reduce overall performance for the subscriber 🌸.
When choosing between transition technologies, operators should weigh the benefits and drawbacks of each option ✨. Some, like Carrier-Grade NAT (CGN)/NAT444, use lots of existing addressing and management practices 🫶. Others, like DS-Lite and NAT64, remove the IPv4 addressing requirement from the subscriber premises device, but they need IPv6 to be operational and well supported 🌈.
3.6. Future IPv6 Network ✨
An operator should also keep in mind that longer-term plans may include IPv6-only operation across all or much of the network 🔮. IPv6-only operation may be backed up by technologies like NAT64 for long-tail IPv4 content reach 🦋. Some folks might think this long-term view is far off, but it should still be considered when planning networks, addressing, and services 💅. Running two IP stacks will eventually get burdensome, and simplification will be desirable 😭. Operators should plan for that state and avoid making IPv6 inherently dependent on IPv4, because that would unnecessarily constrain the network 🙈👑.
Operators should also look at other design considerations and guidelines for running an IPv6 network 🧚. Guidance on designing an IPv6 network can be found in [IPv6-DESIGN] and [IPv6-ICP-ASP-GUIDANCE] 📚💖.
4. IPv6 Transition Technology Analysis 🌸
Operators should understand the main transition technologies for IPv6 deployment and IPv4 run-out 🔥. This document gives a quick rundown of some of the mainstream, commercially available options ✨. The analysis focuses on how well these technologies apply to delivering residential services, and it's less focused on commercial access, wireless, or infrastructure support 💅.
This document focuses on the technologies that are commercially available and in deployment 🫶.
4.1. Automatic Tunneling Using 6to4 and Teredo 🦋
Even when operators aren't actively deploying IPv6, automatic mechanisms already exist on subscriber operating systems and CPE hardware 👀. These include 6to4 [RFC3056], which is most commonly used with anycast relays [RFC3068]. Teredo [RFC4380] is also used widely by lots of Internet hosts 🌈.
Documents like [RFC6343] have been written to help operators understand problems they've seen with 6to4 deployments, and they give guidelines on how to improve performance 🧚. An operator may want to provide local relays for 6to4 and/or Teredo to help improve the protocol's performance for ambient traffic using these IPv6 connectivity methods 💜. Experiences like the ones described in [COMCAST-IPv6-EXPERIENCES] show that local relays have proved beneficial to 6to4 protocol performance 🎀.
Operators should also be aware of breakage cases for 6to4 if non-[RFC1918] addresses are used within CGN/NAT444 zones 😭. Lots of off-the-shelf CPEs and operating systems may turn on 6to4 without a valid return path to the originating (local) host 🙈. This can happen if any space other than [RFC1918] is used, including Shared Address Space [RFC6598] or space registered to another organization (squat space) 💀. The operator can use 6to4 Provider Managed Tunnels (6to4-PMT) [RFC6732], or try to block 6to4 operation entirely by blocking the anycast ranges associated with [RFC3068] 🛑✨.
4.2. Carrier-Grade NAT (NAT444) 🔥
Carrier-Grade NAT (CGN), specifically as deployed in a NAT444 scenario [CGN-REQS], may prove beneficial for operators who offer Dual Stack services to subscriber endpoints once they've used up their pools of IPv4 addresses 👑. CGNs, and address sharing overall, are known to cause certain challenges for the IPv4 service [RFC6269] [NAT444-IMPACTS], but they may be necessary, depending on how an operator has chosen to handle IPv6 transition and legacy IPv4 connectivity requirements 💅.
In a network where IPv4 address availability is low, CGN/NAT444 may keep providing access to IPv4 endpoints 🫶. Some advantages of CGN/NAT444 include similarities in provisioning and activation models 🌈. IPv4 hosts in a CGN/NAT444 deployment will likely inherit the same addressing and management procedures as legacy IPv4 globally addressed hosts (i.e., DHCPv4, DNS (v4), TFTP, TR-069, etc.) 🧚💖
4.3. 6rd ✨
okay so 6rd [RFC5969] is giving "we can offer IPv6 to subscribers even when the access network can't do native IPv6 yet" 🫶 it sends IPv6 through the IPv4 path that already exists. 6rd can be replaced by native IPv6 once the access edge gets upgraded and subscriber premises equipment gets swapped out 💅 and fr, 6rd can be stacked on top of a CGN/NAT444 deployment, but then all traffic is subject to some kind of transition technology 🙈
6rd is also kinda advantageous early in the transition, while IPv6 traffic is still low 🌸 the operator gets to learn IPv6 in the core and level up its peering setup so it matches the IPv4 service. 6rd scales by adding relays to the operator's network 🧚 and another perk is that the operator doesn't need a DHCPv6 address assignment infrastructure, and doesn't need to support IPv6 routing to the CPE for a delegated prefix. why? because the prefix is derived from the IPv4 address and other configuration parameters. no extra infrastructure, bestie 😭✨
Client support is required for 6rd operation, and it may not be on deployed hardware yet 💀 6rd deployments may mean the subscriber or operator has to replace the CPE. 6rd also needs parameter configuration, which the operator can deliver through DHCPv4, provision manually on the CPE, or provision automatically some other way. manual provisioning would likely limit how far it can scale 🥲
4.4. Native Dual Stack 👑
Native Dual Stack is literally called the "gold standard" of IPv6 and IPv4 delivery 🏆 it's a service delivery method that's already used in lots of existing IPv6 deployments. the catch is that Native Dual Stack does require native IPv6 to be delivered through the access network to the subscriber premises. it's a really desirable option in many cases, and it can be used right away if the access network and subscriber premises equipment support native IPv6 🎀
okay but here's the tea 🫠 an operator who runs out of IPv4 addresses to assign to subscribers won't be able to provide traditional native Dual Stack connectivity for new subscribers. in Dual Stack deployments where there aren't enough IPv4 addresses, CGN/NAT444 can be used on the IPv4 path 🦋
Delivering native Dual Stack would require the operator's core and access networks to support IPv6. other systems, like DHCP, DNS, and diagnostic/management facilities, also need to be upgraded to support IPv6. that upgrade can often be non-trivial and costly 💸 bestie, that's a lot of moving pieces 😩
4.5. DS-Lite 🧚♀️
DS-Lite [RFC6333] is based on a native IPv6 connection model where IPv4 services are supported 💜 it provides tunneled connectivity for IPv4 over the IPv6 path between the subscriber's network device and a provider-managed gateway, which is the Address Family Transition Router (AFTR) ✨
DS-Lite can only be used where there's a native IPv6 connection between the AFTR and the CPE. so during early transition, when the core or access network doesn't have IPv6 support yet, it might not be viable at all 🙈 a big chunk of content and services may still be IPv4-only during that early period. operators can be sensitive to this, and may not want the newer IPv6 path to be the only bridge to IPv4 at that time, because of the potential impact 😬 it also helps if most of the operator's internal services and a solid amount of external content are already available over IPv6 before deploying DS-Lite. more services on IPv6 means less demand on the AFTRs, which is lowkey iconic 👑
By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444, DS-Lite can keep legacy IPv4 services running even after IPv4 address run-out 🌈 there are some functional considerations to think about with DS-Lite, like the ones described in [NAT444-IMPACTS] and [DSLITE-DEPLOYMENT], so go read those 📚
DS-Lite needs client support on the CPE to function. whether you can use DS-Lite depends on the operator providing DS-Lite-capable CPEs, or on retail availability of the supported client for subscriber-acquired endpoints 🛍️
4.6. NAT64 🌸
NAT64 [RFC6146] lets IPv6-only connected clients and hosts reach IPv4 servers without any tunneling, which is so clean ✨ the host and home network do need to support IPv6-only modes of operation though. real talk, home networks don't usually have equipment that's 100% IPv6-capable 😅 and common home networks aren't expected to be ready for IPv6-only operation for a number of years. IPv6-only networking can still be deployed by early adopters or in highly controlled networks [RFC6586] 🤓
NAT64 gets more viable in wireline networks as consumer equipment is replaced by IPv6-capable versions 🔥 there are also incentives for operators to move to IPv6-only operation when it's feasible, including the simplicity of a single-stack access network 💖
5. IPv6 Transition Phases 🦋
okay so the phases in this document aren't a rigid set of steps, no cap 🙅♀️ they're a guideline that operators should analyze while planning their IPv6 transition. operators may skip steps based on what their specific networks can do (residential/corporate, fixed/mobile), their business development plans (which can affect how fast they migrate toward full IPv6), or a combo of both 🎀
the phases assume IPv6 traffic volume may start out low, and operator staff will get experience with IPv6 over time. as IPv6 traffic grows, IPv4 traffic will decline (as a percentage relative to IPv6), until IPv6 is the dominant address family 📈 operators may want to keep the flow for the dominant traffic class (IPv4 vs. IPv6) native, to help manage costs related to transition technologies 💅 and the cost of stacking multiple technologies in succession to optimize each stage should be compared against the cost of changing and upgrading subscriber connections. that's the real math, bestie 🧮
more guidance on using IPv6 transition mechanisms is in [RFC6180] 📖 and guidance on incremental CGN for IPv6 transition is in [RFC6264] 🫶
5.1. Phase 0 - Foundation 🏗️
5.1.1. Phase 0 - Foundation: Training 🎓
Training is one of the most important steps in getting an organization ready to support IPv6 💖 most people have little experience with IPv6, and lots of them don't even have a solid grounding in IPv4 😭 IPv6 rollout will likely bring lots of challenges, thanks to immature code on hardware and the evolution of many applications and systems to support IPv6. to deal with these challenges, whether they're coming or already here, organizations must train their staff on IPv6 🫠
training should also happen within reasonable timelines from the actual deployment. the operator needs to plan ahead as it trains the different parts of its organization ⏰ new technology and engineering staff often get little training because of their depth of knowledge, but they must at least get chances to read documentation, architectural white papers, and RFCs 📚 operations personnel who support the network and other systems need training closer to deployment, so they can use what they learned right away before forgetting it 🧠
subscriber support staff need much more basic training, but at large scale, since many organizations have massive call centers for their subscriber base 📞 marketing and sales staff need tailored training too, so they understand IPv6 and can build it into product development and the sales process 💼
5.1.2. Phase 0 - Foundation: System Capabilities 🔍
assessing the hardware and operating capabilities of the deployed equipment (and software) is a huge part of any IPv6 network architecture and implementation 🧰 this assessment needs to happen no matter how the operator plans to transition its network. the capabilities of the install base will still shape which technologies and modes of operation can be supported, and therefore which technologies can be considered for the transition 🦋 if some systems don't meet the needs of the operator's IPv6 deployment or transition plan, the operator may need to plan for replacing and/or upgrading them 🔧
5.1.3. Phase 0 - Foundation: Routing 🗺️
the network infrastructure needs to be in place to support IPv6 🛣️ that includes the routed infrastructure, plus addressing principles, routing principles, peering policy, and related network functions. IPv6 is pretty different from IPv4 in several ways, including how many addresses it makes available, so careful attention to a scalable and manageable architecture is needed 🌈
one big change is the notion of a delegated prefix, which breaks from the common single-address thing in IPv4-only deployments 🎀 deploying prefixes per CPE can load the routing tables, and may require a routing protocol or route gleaning to manage connectivity to the subscriber's network 📡 delegating prefixes matters a lot in access networks where downstream subscribers often move between access nodes, since that raises concerns about frequent renumbering and/or managing movement of routed prefixes within the network (common in cable-based networks) 😵💫
5.1.4. Phase 0 - Foundation: Network Policy and Security 🔐
many, but not all, security policies will map easily from IPv4 to IPv6 💅 some new policies may be required for issues specific to IPv6 operation. this document doesn't dig into those specific issues, but it does raise awareness that they need to be taken into consideration and addressed when delivering IPv6 services 🚨 other IETF documents, like [RFC4942], [RFC6092], and [RFC6169], are excellent resources 📚🫶
5.1.5. Phase 0 - Foundation: Transition Architecture 🗺️
Okay bestie, operators should plan their transition architecture in advance (but leave some room to be flexible!) so they can build out and scale their networks without chaos 💅. If they're juggling multiple technologies, like CGN/NAT444, DS-Lite, NAT64, and 6rd, it helps to figure out where the network-resident gear will live. Ideally, pick spots that can handle all the functional roles, like the NAT44 translator, AFTR, NAT64 gateway, and 6rd relays 🏢. These functions aren't inherently connected, but extra management, diagnostic, and monitoring tools can ride along with the transition hardware. That way, nobody has to spread them across an excessive or messy number of locations 🧹.
This approach can be a total lifesaver if traffic patterns shift super fast later on, because operators may have to evolve their transition infrastructure quicker than they originally expected 🏃♀️. One classic example is going from a CGN/NAT44 model (Dual Stack) to DS-Lite. Both traffic sets need a translation function (NAT44), so synchronized pool management, routing, and management system placement can make that move way faster 🚀. (The tech needed to re-provision the subscriber is its own separate vibe, tho 🙈.)
Operators should tell their vendors which technologies they plan to support during the transition 📣. That way, the equipment is actually ready for those modes of operation. This matters for both network gear and subscriber premises equipment 🏠.
Operators should also map out their overall strategy for meeting the target needs of an IPv6-only deployment 🌈. As traffic moves to IPv6, the perks of having a single stack on the access network might eventually be worth removing IPv4 for simplicity 🧼. Planning for that eventual model, no matter how far off it is, helps operators embrace the end state when the time comes 🦋.
5.1.6. Phase 0 - Foundation: Tools and Management 🛠️
Operators should thoroughly analyze all their provisioning and management systems to develop requirements for each phase 🔍. This includes stuff related to the 128-bit IPv6 address, the notation of an assigned IPv6 prefix (Prefix Delegation), and the ability to detect either or both address families when figuring out whether a subscriber has full Internet service 🌐.
If an operator stores usage information, it needs to be aggregated to include both IPv4 and IPv6 info, since both address families are assigned to the same subscriber 📊. Tools that verify connectivity may need to query both the IPv4 and IPv6 addresses too 🔎.
5.2. Phase 1 - Tunneled IPv6 🚇
Tunneled access to IPv6 counts as an early-stage transition option 🌱. Lots of network operators can deploy native IPv6 from the access edge to the peering edge pretty quickly, but they might not be able to offer native IPv6 to the subscriber edge device yet 😬. During that stretch, tunneled access to IPv6 is a viable alternative to native IPv6 💜. It's also possible that operators are rolling out native IPv6 to the subscriber edge, but it may take a long time because of logistics and other factors 🐢. Even while carefully rolling out native IPv6, operators can deploy relays for automatic tunneling technologies like 6to4 and Teredo 🧚. Where native IPv6 to the access edge is a longer-term project, operators can consider 6rd [RFC5969] to offer in-home IPv6 access 🏡. Just note that 6to4 and Teredo have different address selection [RFC6724] behaviors than 6rd 👀. More guidance on deploying and supporting 6to4 is in [RFC6343] 📖.
Operators can deploy 6rd relays into the network and scale them as needed to meet early subscriber needs for IPv6 📈. Since 6rd requires upgrading or replacing CPE devices, operators may want to make sure the CPE supports not just 6rd but also native Dual Stack and other tunneling technologies, like DS-Lite, if possible [IPv6-CE-RTR-REQS] 🎀. 6rd clients are showing up in some retail channel products and in the original equipment manufacturer (OEM) market 🛍️. Retail availability matters a lot, since not all operators control or influence what equipment gets deployed in the consumer home network 🤷♀️. Operators can support 6rd access with unmanaged devices using DHCPv4 Option 212 (OPTION_6RD) [RFC5969] 🧠.
+--------+ -----
| | / \
Encap IPv6 Flow | 6rd | | IPv6 |
- - -> | Relay | <- > | Net |
+---------+ / | | \ /
| | / +--------+ -----
| 6rd + <----- -----
| | / \
| Client | IPv4 Flow | IPv4 |
| + < - - - - - - - - - - - - - - -> | Net |
| | \ /
+---------+ -----
Figure 1: 6rd Basic Model6rd used as an initial transition technology also comes with a bonus: a deterministic IPv6 prefix based on the IPv4 address that was assigned 🎁. Lots of operational tools already exist (or have been built) to figure out which IPv4 address, often a dynamic one, was assigned to a subscriber CPE 🔍. So a simple tool or method can be built to work out the IPv6 prefix from the assigned IPv4 address ✨.
An operator may choose not to offer internal services over IPv6 when tunneled access to IPv6 is in use 🙅♀️. That's because some services generate a ton of traffic, like video content such as IPTV 📺. By limiting how much traffic gets delivered over the 6rd connection (if that's possible), the operator can avoid costly and complex scaling of the relay infrastructure 💸.
5.2.1. 6rd Deployment Considerations 🧩
Deploying 6rd can seriously speed up an operator's ability to support IPv6 to the subscriber network if native IPv6 connectivity can't be supplied 🏎️. The speed at which 6rd can be deployed is highlighted in [RFC5569] ⚡.
The first core consideration is deployment models 🧭. 6rd requires the CPE (6rd client) to send traffic to a 6rd relay 📮. These relays can share a common anycast address or use unique addresses. With an anycast model, the operator can deploy all the 6rd relays using the same IPv4 interior service address 📍. As load increases on the deployed relays, the operator can add more relays to the network 📶. The one drawback is that it may be hard to manage traffic volume across the extra relays, since all 6rd traffic will find the nearest relay (in terms of IGP cost) 😵💫. Using multiple relay addresses can give more control, but it's more complex to provision 🧶. Subsets of CPEs across the network will require and contain different relay information 🗂️. An alternative is a hybrid model that uses multiple anycast service IP addresses for clusters of 6rd relays, if the operator expects massive scaling 🚀. So the operator has multiple ways to scale the service 💜.
+--------+
| |
IPv4 Addr.X | 6rd |
- - - > | Relay |
+-----------+ / | |
| Client A | <- - - +--------+
+-----------+
Separate IPv4 Service Addresses
+-----------+
| Client B | < - - +--------+
+-----------+ \ | |
- - - > | 6rd |
IPv4 Addr.Y | Relay |
| |
+--------+
Figure 2: 6rd Multiple IPv4 Service Address Model +--------+
| |
IPv4 Addr.X | 6rd |
- - - > | Relay |
+-----------+ / | |
| Client A |- - - - +--------+
+-----------+
Common (Anycast) IPv4 Service Addresses
+-----------+
| Client B | - - - +--------+
+-----------+ \ | |
- - - > | 6rd |
IPv4 Addr.X | Relay |
| |
+--------+
Figure 3: 6rd Anycast IPv4 Service Address ModelProvisioning of the 6rd endpoints depends on which deployment model is chosen (anycast vs. specific service IP addresses) 🎯. Using multiple IP addresses may need more planning and management, since subscriber equipment will have different sets of data to be provisioned into the devices 📋. The operator may use DHCPv4, manual provisioning, or other mechanisms to hand parameters to subscriber equipment 🛠️.
If the operator manages the CPE, support staff will need tools that can report the status of the 6rd tunnel 🕵️♀️. Usage info can be collected on the operator edge, but if source/destination flow details are needed, the data must be collected after the 6rd relay (the IPv6 side of the connection) 📡.
6rd [RFC5969], like any tunneling option, comes with a reduced MTU, so operators need to plan for managing this kind of environment 📏.
+---------+ IPv4 Encapsulation +------------+
| +- - - - - - - - - - - + |
| 6rd +----------------------+ 6rd +------------
| | IPv6 Packet | Relay | IPv6 Packet
| Client +----------------------+ +------------
| +- - - - - - - - - - - + | ^
+---------+ ^ +------------+ |
| |
| |
IPv4 (Tools/Mgmt) IPv6 Flow Analysis
Figure 4: 6rd Tools and Flow Management5.3. Phase 2 - Native Dual Stack ✨
Okay so, this phase can come right after "tunneled IPv6" or be the very first step, bestie 🦋. Either way, the operator may deploy native IPv6 all the way down to the CPEs. Then the subscriber's home network can reach both IPv6 and IPv4 natively, with no translation or tunneling needed 💖.
It can roll out across the network while tunneled IPv6 keeps running, if anyone's still using it 🌈. As areas start supporting native IPv6, subscriber home equipment will generally prefer the IPv6 addresses derived from the delegated IPv6 prefix over tunneling options defined in [RFC6724], like 6to4 and Teredo 👑. Moving to native Dual Stack from 6rd needs specific care, so check [6rd-SUNSETTING] first 🫶.
Native Dual Stack is the best option at this point in the transition, so it should be sought as soon as possible 🔥. During this phase, the operator can confidently move both internal and external services to IPv6 💅. Since there are no translation devices in this mode, it carries both protocols (IPv6 and IPv4) efficiently across the network. Iconic 😭.
5.3.1. Native Dual Stack Deployment Considerations
Native Dual Stack is a very desirable option for the IPv6 transition, if it's feasible for you 🎀. The operator must enable IPv6 on the network core and peering edge before turning on native IPv6 services. Provisioning and support systems like DHCPv6 and DNS, plus the other functions that support the subscriber's IPv6 Internet connection, also need to be in place 🧚.
The operator must treat IPv6 connectivity with the same operational importance as IPv4. Honestly, a poor IPv6 service can be worse than no IPv6 service at all, because it hurts the subscriber's Internet experience 💀. That can make users or support staff turn IPv6 off, which keeps the subscriber from enjoying IPv6 once the network performance gets better 😤. New code and IPv6 features may be a little unstable at first, so the operator will need to monitor, troubleshoot, and fix issues promptly 🔧.
Prefix assignment and routing are new for common residential services 🌸. Prefix assignment is straightforward (DHCPv6 using Identity Associations for Prefix Delegation (IA_PDs)), but installing and propagating routing information for the prefix is often poorly understood, especially when the access layer is unstable 🙈. The operator should develop processes for renumbering subscribers who move to new access nodes 🦋.
Operators need to keep track of the dynamically assigned IPv4 address along with the IPv6 address and prefix 📝. Any other dynamic elements, like auto-generated host names, need to be considered and planned for ✨.
5.4. Intermediate Phase for CGN 🌷
Acquiring more IPv4 addresses is already challenging, if not impossible 😩. So address sharing may be required on the IPv4 path of a Dual Stack deployment. The operator may prefer to move straight to a transition technology like DS-Lite [RFC6333], or it may use Dual Stack with CGN/NAT444 to keep IPv4 connections working 💜.
CGN/NAT444 needs IPv4 addressing between the subscriber premises equipment and the operator's translator. This can come from shared addresses [RFC6598], private addresses [RFC1918], or another address space 🍓. CGN/NAT444 is only recommended to be used alongside IPv6 in a Dual Stack deployment, not on its own 🫶. Figure 5 gives a side-by-side look at a traditional IPv4 path versus one that uses CGN/NAT444 👀.
+--------+ -----
| | / \
IPv4 Flow | CGN | | |
- - -> + + < -> | |
+---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 |
|---------+ | Net |
| |
+---------+ IPv4 Flow | |
| CPE | <- - - - - - - - - - - - - - - > | |
|---------+ \ /
-----
Figure 5: Overlay CGN DeploymentIn the case of native Dual Stack, CGN/NAT444 can help extend connectivity for the IPv4 path while the IPv6 path stays native 🌈. For endpoints running an IPv6+CGN/NAT444 model, the native IPv6 path gives higher-quality connectivity and helps hosts operate well over the network ✨. At the same time, the CGN path may offer less than optimal performance 😬. These points are also true for DS-Lite 💅.
+--------+ -----
| | / \
IPv4 Flow | CGN | | IPv4 |
- - -> + + < -> | Net |
+---------+ / | | \ /
| | <- - - / +--------+ -------
| Dual |
| Stack | -----
| CPE | IPv6 Flow / IPv6 \
| | <- - - - - - - - - - - - - - - > | Net |
|---------+ \ /
-----
Figure 6: Dual Stack with CGNCGN/NAT444 deployments can use a few address options, including [RFC1918] or Shared Address Space [RFC6598] 🎀. Operators can also use part of their own Regional Internet Registry (RIR) assigned address space for CGN zone addressing, if [RFC1918] addresses cause technical challenges in their networks 🌸. It is not recommended that operators use 'squat space', since it may cause extra headaches with filtering and policy control [RFC6598] 🙅♀️.
5.4.1. CGN Deployment Considerations
CGN is often seen as undesirable by operators, but it's required in many cases 😮💨. An operator who needs CGN capabilities should think through the impact on the network 🧐. CGN is often deployed on top of running IPv4 services, and it should not negatively impact the already working native IPv4 service 🫶. CGNs will be needed on a small scale at first, then grow to meet demand based on the traffic and connection dynamics of subscribers, content, and network peers 📈.
The operator may want to deploy CGNs more centrally at first and then scale the system as needed 🦋. This approach can help conserve system costs by limiting the deployed base and scaling it based on actual traffic demand 💰. The operator should use a deployment model and architecture that let the system scale as needed ✨.
+--------+ -----
| | / \
| CGN | | |
- - -> + + < -> | |
+---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 |
| | ^ | |
|---------+ | | Net |
+--------+ Centralized | |
+---------+ | | CGN | |
| | | CGN | | |
| CPE | <- > + + <- - - - - - - > | |
|---------+ | | \ /
+--------+ -----
^
|
Distributed CGN
Figure 7: CGN Deployment: Centralized vs. DistributedThe operator may be required to log translation information [CGN-REQS] 📒. That logging may need serious investment in external systems that ingest, aggregate, and report the data [DETERMINISTIC-CGN] 💸.
Since CGN has noticeable impacts on certain applications [NAT444-IMPACTS], operators may deploy CGN only for subscribers who are less affected by it (if that's possible) 🙏.
5.5. Phase 3 - IPv6-Only 👑
Once native IPv6 is widely deployed and well supported by tools, staff, and processes, an operator may consider supporting only IPv6 for all or some subscriber endpoints 🚀. During this final phase, IPv4 connectivity may or may not need to be supported, depending on network conditions, subscriber demand, and legacy device requirements 🤷♀️. If legacy IPv4 connectivity is still needed (for example, for older nodes), DS-Lite [RFC6333] may be used to tunnel the traffic 🛤️. If IPv4 connectivity isn't required but access to legacy IPv4 content is, then NAT64 [RFC6144] [RFC6146] can be used 🦋.
5.5.1. DS-Lite 🌈
DS-Lite keeps IPv4 subscribers connected by using address sharing for IPv4 Internet connectivity, but with only a single layer of translation, unlike CGN/NAT444 💖. This mode also removes the need to give subscriber endpoints their own IPv4 address, which can simplify connectivity for the customer (single address family) and supports IPv6-only addressing to the CPE 🧚.
The operator can also move Dual Stack endpoints to DS-Lite after the fact, which helps optimize the IPv4 address-sharing deployment by removing the IPv4 address assignment and routing component 🔧. To minimize traffic that needs translation, the operator should have already moved most content to IPv6 before the IPv6-only phase is implemented 🫶.
+--------+ -----
| | / \
Encap IPv4 Flow | AFTR | | IPv4 |
-------+ +---+ Net |
+---------+ / | | \ /
| | / +--------+ -----
| DS-Lite +------- -----
| | / \
| Client | IPv6 Flow | IPv6 |
| +-------------------------------| Net |
| | \ /
+---------+ -----
Figure 8: DS-Lite Basic ModelIf the operator had already decided to enable a CGN/NAT444 deployment, it may be able to co-locate the AFTR and CGN/NAT444 processing functions in a common network location, which simplifies capacity management and flow engineering 🏠. This case may be evident in a later transition stage, when an operator chooses to optimize its network and IPv6-only operation is feasible 🌟.
5.5.2. DS-Lite Deployment Considerations ✨
Okay bestie, the same deployment vibes you'd get from native IPv6 rollouts also apply to DS-Lite and NAT64 💖. Here's the tea: IPv4 is now gonna depend on how good your IPv6 service is, so the IPv6 network and services have to be running really well 🔥 or the end subscriber's experience is gonna be 😭. You'll need tools and processes to manage that encapsulated IPv4 service 🛠️. If you need flow analysis for IPv4 traffic, you can turn it on beyond the AFTR (after decapsulation), or use DS-Lite-aware gear that processes traffic midstream 🦋.
+---------+ IPv6 Encapsulation +------------+
| + - - - - - - - - - - -+ |
| AFTR +----------------------+ AFTR +------------
| | IPv4 Packet | | IPv4 Packet
| Client +----------------------+ +------------
| + - - - - - - - - - - -+ | ^
+---------+ ^ ^ +------------+ |
| | |
| | |
IPv6 (Tools/Mgmt) | IPv4 Packet Flow Analysis
|
Midstream IPv4 Packet Flow Analysis (Encapsulation Aware)
Figure 9: DS-Lite Tools and Flow AnalysisDS-Lite [RFC6333] also needs client support on the subscriber premises device 🎀. The operator has to clearly tell vendors which technologies get used at which points, how they interact with each other at the CPE, and how they'll be provisioned 📝. For example, an operator might use 6rd at the start of the transition, then move to native Dual Stack, followed by DS-Lite 🌈.
DS-Lite [RFC6333], like any tunneling option, comes with a reduced MTU, so operators need to plan for managing that kind of environment 🧚. More considerations for DS-Lite deployments are in [DSLITE-DEPLOYMENT] 💜.
5.5.3. NAT64 Deployment Considerations 🌸
The deployment of NAT64 assumes the network gives a network endpoint an IPv6 address that gets translated to an IPv4 address, so it can reach IPv4 Internet services and content 🌐. Experiments like the one in [RFC6586] show issues with IPv6-only deployments caused by legacy IPv4 APIs and IPv4 literals 🙈. Many of these issues will be resolved once this undesirable legacy behavior is eventually removed ✨. Operational deployment models, considerations, and experiences for NAT64 are documented in [NAT64-EXPERIENCE] 📚.
+--------+ -----
| | / \
IPv6 Flow | NAT64 | | IPv4 |
-------+ DNS64 +---+ Net |
+---------+ / | | \ /
| | / +--------+ -----
| IPv6 +------- -----
| | / \
| Only | IPv6 Flow | IPv6 |
| +-------------------------------| Net |
| | \ /
+---------+ -----
Figure 10: NAT64/DNS64 Basic ModelTo work around some NAT64 limits with legacy IPv4 applications, the operator may choose to implement 464XLAT [464XLAT] if possible 💅. As IPv6 support on subscriber equipment and content grows, NAT64 gets more efficient, because less traffic needs translating 📈. NAT64 deployments would see an overall decline in translator usage as more traffic gets promoted to IPv6-to-IPv6 native communication 🫶. NAT64 may play an important part in an operator's late-stage transition, since it removes the need to support IPv4 on the access network and gives a solid go-forward networking model 🏁.
Just so you know, like with any technology that uses address sharing, the IPv4 public pool sizes (IPv4 transport addresses per [RFC6146]) can limit IPv4 server connectivity for the subscriber base 👀. Operators should be aware that some IPv4 growth in the near term is possible, so IPv4 translation pools need to be monitored 📊.
6. Security Considerations 🔐
🚨 This part is serious, so pay attention!! Operators need to review the documentation for the technologies they pick for IPv6 transition. In those reviews, figure out which security considerations apply to your chosen technologies. For example, read [RFC6169] to understand the security considerations for tunneling technologies.
7. Acknowledgements 🫶
Special thanks to Wes George, Chris Donley, Christian Jacquenet, and John Brzozowski for their extensive review and comments 👑.
Thanks to the following people for their textual contributions, guidance, and comments: Jason Weil, Gang Chen, Nik Lavorato, John Cianfarani, Chris Donley, Tina TSOU, Fred Baker, and Randy Bush 💖.
8. References 📚
8.1. Normative References
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment", RFC 6180,
May 2011.8.2. Informative References
[464XLAT] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", Work
in Progress, September 2012.
[6rd-SUNSETTING]
Townsley, W. and A. Cassen, "6rd Sunsetting", Work
in Progress, November 2011.
[CGN-REQS]
Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common requirements for Carrier Grade
NATs (CGNs)", Work in Progress, August 2012.
[COMCAST-IPv6-EXPERIENCES]
Brzozowski, J. and C. Griffiths, "Comcast IPv6 Trial/
Deployment Experiences", Work in Progress, October 2011.
[DETERMINISTIC-CGN]
Donley, C., Grundemann, C., Sarawat, V., and K.
Sundaresan, "Deterministic Address Mapping to Reduce
Logging in Carrier Grade NAT Deployments", Work
in Progress, July 2012.
[DSLITE-DEPLOYMENT]
Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.
Boucadair, "Deployment Considerations for Dual-Stack
Lite", Work in Progress, August 2012.
[IPv6-CE-RTR-REQS]
Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", Work
in Progress, October 2012.
[IPv6-DESIGN]
Matthews, P., "Design Guidelines for IPv6 Networks", Work
in Progress, October 2012.
[IPv6-ICP-ASP-GUIDANCE]
Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content and Application Service Providers", Work
in Progress, September 2012.
[NAT444-IMPACTS]
Donley, C., Ed., Howard, L., Kuarsingh, V., Berg, J., and
J. Doshi, "Assessing the Impact of Carrier-Grade NAT on
Network Applications", Work in Progress, October 2012.
[NAT64-EXPERIENCE]
Chen, G., Cao, Z., Byrne, C., Xie, C., and D. Binet,
"NAT64 Operational Experiences", Work in Progress,
August 2012.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[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.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
Co-existence Security Considerations", RFC 4942,
September 2007.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092,
January 2011.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[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.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
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.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,
"IPv6 Support Required for All IP-Capable Nodes", BCP 177,
RFC 6540, April 2012.
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", RFC 6586, April 2012.
[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., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6732] Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider
Managed Tunnels", RFC 6732, September 2012.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
Lee Howard
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
US
EMail: lee.howard@twcable.com
URI: http://www.timewarnercable.com📦 where this page comes from
- ietf: rfc6782 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms