RFC 6883
IPv6 Guidance for Internet Content Providers and Application Service Providers
Internet Engineering Task Force (IETF) 🎀
RFC 6883: IPv6 Guidance for Internet Content Providers and Application Service Providers ✨
Okay bestie, here's the deal with this one. It's written by B. Carpenter (Univ. of Auckland) and S. Jiang (Huawei Technologies Co., Ltd). It's an Informational RFC, so it's published for guidance and is not an Internet Standards Track spec 📖. It was published in March 2013 and has ISSN 2070-1721. The title block doesn't list any RFCs that it obsoletes or updates, so it's standing on its own 💅.
Abstract ✨
Okay so this doc gives guidance and suggestions for Internet Content Providers and Application Service Providers who want to offer their service to both IPv6 and IPv4 customers 🫶. Lots of the points also apply to hosting providers, or to any enterprise network getting ready for IPv6 users 🌸.
Status of This Memo 📜
Quick reminder: this document is not an Internet Standards Track specification. It's published for informational purposes 🦋.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the full picture 🤓.
Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc6883 🔗.
Copyright Notice ⚖️
Copyright (c) 2013 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 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 without warranty, as described in the Simplified BSD License 🙈.
Table of Contents 🗺️
1. Introduction ....................................................2
2. General Strategy ................................................3
3. Education and Skills ............................................5
4. Arranging IPv6 Connectivity .....................................6
5. IPv6 Infrastructure .............................................7
5.1. Address and Subnet Assignment ..............................7
5.2. Routing ....................................................8
5.3. DNS ........................................................9
6. Load Balancers .................................................10
7. Proxies ........................................................11
8. Servers ........................................................12
8.1. Network Stack .............................................12
8.2. Application Layer .........................................12
8.3. Logging ...................................................13
8.4. Geolocation ...............................................13
9. Coping with Transition Technologies ............................13
10. Content Delivery Networks .....................................15
11. Business Partners .............................................16
12. Possible Complexities .........................................16
13. Operations and Management .....................................17
14. Security Considerations .......................................18
15. Acknowledgements ..............................................20
16. References ....................................................20
16.1. Normative References .....................................20
16.2. Informative References ...................................221. Introduction 🌈
Okay so IPv6 [RFC2460] is rolling out right now, and users without direct IPv4 access are going to show up in bigger and bigger numbers over the next few years 📈. Any provider of content or application services on the Internet is going to need to set up IPv6 access, or risk losing a huge chunk of potential users 😭. For users who already have dual-stack connectivity, direct IPv6 access can give a more satisfying performance than going through NAT indirectly 💜.
Quick note: in this doc we often call the people using content or application services "customers" to make their role clear, but that doesn't mean the scope is limited to commercial sites 🛍️.
The time to act is now 🔥, while the number of IPv6-only customers is still small. That gives you time to get the right skills, software, and equipment, so you can scale up IPv6 service as demand grows. Another perk of supporting IPv6 customers early is that fewer customers will end up connecting later through IPv4 "extension" solutions like double NAT or NAT64 [RFC6146]. Those would otherwise make the user experience worse 😬.
That said, rolling out IPv6 shouldn't make things worse for IPv4 customers 🙅♀️. In some situations, technologies meant to help with the transition from IPv4 to IPv6 are known to hurt the user experience. A deployment strategy for IPv6 has to avoid those effects as much as possible 🧚.
The purpose of this document is to give guidance and suggestions for Internet Content Providers (ICPs) and Application Service Providers (ASPs) who want to offer their services to both IPv6 and IPv4 customers, but who currently only support IPv4 💖. To keep things simple, the body of the document mostly says "ICP", but the guidance applies to ASPs too. Any hosting provider whose customers include ICPs or ASPs is also affected 🌸. Lots of the points also apply to enterprise networks that don't call themselves ICPs. Any enterprise or department running at least one externally accessible server, like an HTTP server, might be affected too 👀. The doc describes specific managerial and technical approaches, but it's not a rule book 📕. Each operator needs to make its own plan, tailored to its own services and customers ✨.
2. General Strategy 🧠
The most important advice here is to actually have a general strategy 👑. Adding support for a second network-layer protocol is a brand-new experience for most modern organizations, and it can't be done casually on an unplanned basis 💀. Even if you can't write a precisely dated plan, the intended steps need to be defined well in advance 📅. There's no single blueprint for this. The rest of the document is meant to give you a set of topics to consider when defining your strategy 🗂️. You should also check out other documents about IPv6 deployment, like [IPv6-NETWORK-DESIGN] 📚.
When you're figuring out how urgent this strategy is, keep in mind that the central IPv4 registry (IANA) ran out of spare blocks of IPv4 addresses in February 2011 😳. The various regional registries are expected to use up their reserves over the next one to two years. After that, Internet Service Providers (ISPs) will run out on dates set by their own customer base. Nobody can give a precise date for when IPv6-only customers will show up in commercially significant numbers, but (especially for mobile users) it may be pretty soon ⏰. So getting complacent is not an option for any ICP that wants to grow its customer base in the coming years 🙃.
The most common strategy for an ICP is to provide dual-stack services, meaning both IPv4 and IPv6 on an equal basis, to cover both existing and future customers 🎀. This is the recommended strategy in [RFC6180] for straightforward situations 💅. Some ICPs who already have satisfying operational experience with IPv6 might consider an IPv6-only strategy, with IPv4 clients supported by translation or a proxy in front of their IPv6 content servers 🦋. However, this document is written for ICPs without IPv6 experience, who will probably prefer the dual-stack model because it builds on their existing IPv4 service 🫶.
Supporting IPv6 everywhere in an environment has a widespread impact, so it's important to pick a focused initial approach based on clear business needs and real technical dependencies 🎯.
Within the dual-stack model, two approaches could be adopted. They're sometimes called "outside in" and "inside out" 🔄:
- Outside in: Start by giving external users IPv6 public access to your services, for example by running a reverse proxy that handles IPv6 customers (see Section 7 for details). Then progressively enable IPv6 internally 🚪.
- Inside out: Start by enabling internal networking infrastructure, hosts, and applications to support IPv6. Then progressively reveal IPv6 access to external customers 🏠.
Which one you pick depends on the exact circumstances of the ICP 🤷♀️. "Outside in" has the perk of giving interested customers IPv6 access early, which gets you precious operational experience before you meticulously update every piece of equipment and software 💎. For example, if some back-office system that users never see only supports IPv4, it won't cause a delay 🙌. "Inside out" has the perk of completing the IPv6 implementation as one single project 📦. Any ICP could choose it, but it might be most appropriate for a small ICP without complex back-end systems 🌷.
One thing the strategy has to take into account: some customers will stay IPv4-only for many years, others will have both IPv4 and IPv6 access, and yet others will have only IPv6 🌍. On top of that, mobile customers may switch between IPv4 and IPv6 access as they travel, even within a single session 📱.
Services and applications must be able to handle this, just as easily as they handle a user whose IPv4 address changes today (see the discussion of cookies in Section 8.2) 🍪.
The end goal, though, is a network that doesn't need major changes when, at some point in the future, it becomes possible to move to IPv6-only, even if only for some parts of the network ✨. In other words, the IPv6 deployment should be designed to more or less assume IPv4 is already gone, so the network keeps working seamlessly when it really is no longer there 🦄.
Another important step is to find out from hardware and software suppliers their planned dates for providing sufficient IPv6 support, with performance equivalent to IPv4, in their products and services 📞. Relevant specifications such as [RFC6434] and [IPv6-CE-REQS] should be used 📑. Even if you can't get complete information, it's essential to figure out which components are on the critical path during each phase of deployment 🚦. That information makes it possible to draw up a logical sequence of events and spot any components that might cause holdups 🔍.
To be continued in Part 2 of 6 💖🎀
3. Education and Skills ✨
okay bestie, so some staff have actually run multiprotocol networks before, which was super common like twenty years ago before IPv4 took over everything 🌸 but IPv6 is brand new to them, and also to anyone who has only ever known TCP/IP 😭 having one "IPv6 expert" on the team is NOT enough, no cap. everybody who knows IPv4 needs to know IPv6 too, from the network architect all the way to the help desk responder 💅 so an early and essential part of the strategy has to be education, including practical training. that way all staff get a general understanding of IPv6, how it affects basic stuff like the DNS, and the relevant practical skills 🎀 and to take a trivial example, anyone used to dotted-decimal IPv4 addresses needs to get comfy with the colon-hexadecimal format IPv6 uses 🦋
there's an anecdote about one IPv6 deployment where prefixes with the letters A to F were avoided by design 💀 so the sysadmins wouldn't get confused by hexadecimal notation. not a desirable result, babe 🙈 and there's another one about a help desk responder telling a customer to "disable one-Pv6" to fix a problem 😭😭 the goal is to avoid having untrained staff who don't understand hexadecimal or who can't even spell "IPv6" 🥀
it's sooo useful to have a small lab network for training and self-training in IPv6 🧪 that way staff can experiment and make mistakes without messing up the operational IPv4 service 🫶 this lab should run both IPv4 and IPv6, so people can get experience with a dual-stack environment and new features like having multiple addresses per interface, and addresses with lifetimes and deprecation ✨
once staff are trained, they'll likely need to support IPv4, IPv6, and dual-stack customers 👑 rather than having separate internal escalation paths for IPv6, it generally makes sense for questions with an IPv6 element to follow the normal escalation paths. there should NOT be an "IPv6 Department" once training is done 🙅♀️
last thing about training: don't give it too soon, or it gets forgotten 💔 it needs to be done "just in time" so it actually "sticks" 🧚 so training, lab experience, and actual deployment should follow each other immediately. and if possible, training should even be combined with real operational experience 🌈
4. Arranging IPv6 Connectivity 🌍
okay so in theory there are two ways to get IPv6 connectivity to the Internet 🦋
- Native. here the ISP just provides IPv6 on exactly the same basis as IPv4 🌟 it shows up at the ICP's border router(s), which then have to be configured in dual-stack mode so they can forward IPv6 packets in both directions. this is by FAR the better method, periodt 👑 an ICP should contact all its ISPs to check when they'll provide native IPv6 support, whether it has any financial implications, and whether the same service level agreement will apply as for IPv4 💅 any ISP with no definite plan to offer native IPv6 service should be avoided 🙅♀️
- Managed Tunnel. it's possible to configure an IPv6-in-IPv4 tunnel to a remote ISP that offers this kind of service 🚇 a dual-stack router in the ICP's network will act as the tunnel endpoint, or this function could be included in the ICP's border router 🧩
a managed tunnel is a reasonable way to get IPv6 connectivity for initial testing and skills acquisition 🎀 BUT it brings an inevitable extra latency compared to native IPv6, so customers get a noticeably worse response time for complex web pages 😩 a tunnel can also become a performance bottleneck (especially if it's offered as a free service) or a target for malicious attack ⚠️
it's also likely to limit the IPv6 MTU size 📏 in normal circumstances native IPv6 gives an MTU size of at least 1500 bytes, but for a tunnel it will almost inevitably be less, possibly as low as 1280 bytes (the minimum MTU allowed for IPv6) 🥺 besides the loss of efficiency, there are cases where Path MTU Discovery fails and IPv6 fragmentation therefore fails too. in that case the lower tunnel MTU will actually cause connectivity failures for customers 💀
so for these reasons, ICPs are strongly recommended to get native IPv6 service before trying to offer a production-quality service to their customers 🫶 unfortunately, it's impossible to stop customers from using unmanaged tunnel solutions (see Section 9) 😤
some larger organizations might need multiple forms of IPv6 connectivity, both for their ICP data centers and for staff working elsewhere 🏢 it's important to get IPv6 connectivity for both, because testing and supporting an IPv6-enabled service is really challenging for staff without IPv6 connectivity 📡 this may involve short-term alternatives for operations and support staff, like a managed tunnel or an HTTP proxy server with IPv6 connectivity 🧃 and note that unmanaged tunnels (such as 6to4 and Teredo) are generally not useful for support staff, since recent client software will avoid them when accessing dual-stack sites 🙈
5. IPv6 Infrastructure 🏗️
5.1. Address and Subnet Assignment 📮
okay so an ICP first has to decide whether to apply for its own Provider Independent (PI) address prefix for IPv6 🔑 this option is available either from an ISP that acts as a Local Internet Registry or directly from the relevant Regional Internet Registry. the alternative is to get a Provider Aggregated (PA) prefix from an ISP. both solutions are viable in IPv6 ✨ but the scaling properties of the wide-area routing system (BGP-4) mean the number of PI prefixes should be limited, so only large content providers can justify getting a PI prefix and convincing their ISPs to route it 🌊 millions of enterprise networks, including smaller content providers, will use PA prefixes instead. in that case, switching ISPs would necessitate changing the corresponding PA prefix, using the procedure outlined in [RFC4192] 🔄
an ICP with connections via multiple ISPs but no PI prefix would therefore end up with multiple PA prefixes, one from each ISP 😵💫 that results in multiple IPv6 addresses for the ICP's servers or load balancers. if one address fails because of an ISP malfunction, sessions using that address get lost 💔 at the time of this writing, there's very limited operational experience with this approach [MULTIHOMING-WITHOUT-NAT] 🧐
an ICP may also choose to operate a Unique Local Address prefix [RFC4193] for internal traffic only, as described in [RFC4864] 🔒
depending on its projected future size, an ICP might choose to get /48 PI or PA prefixes (allowing 16 bits of subnet address) or longer PA prefixes, e.g., /56 (allowing 8 bits of subnet address) 📐 clearly, the choice of /48 is more future-proof, no contest 🏆 advice on numbering subnets can be found in [RFC5375]. an ICP with multiple locations will probably need a prefix per location 📍
an ICP whose service is hosted by a colocation provider, cloud provider, or the like will need to follow that provider's addressing policy ☁️
since IPv6 lets you run multiple prefixes at the same time, it's important to check that all the relevant tools, like address management packages, can deal with this 🧰 in particular, the possible need to allow for multiple PA prefixes with IPv6, and the possible need to renumber, mean that the common technique of manually assigned static addresses for servers, proxies, or load balancers, with statically defined DNS entries, could be problematic [RFC6866] 😬 an ICP of reasonable size might instead choose to operate DHCPv6 [RFC3315] with standard DNS, to support stateful assignment 🗂️ either way, a configuration management system is likely to be used to support stateful and/or on-demand address assignment ⚙️
theoretically, it would also be possible to run an ICP's IPv6 network using ONLY Stateless Address Autoconfiguration [RFC4862], with Dynamic DNS [RFC3007] publishing server addresses for external users 🤯
5.2. Routing 🛣️
in a dual-stack network, most IPv4 and IPv6 interior routing protocols operate quite independently and in parallel 🫧 the common routing protocols, such as OSPFv3 [RFC5340], IS-IS [RFC5308], and even the Routing Information Protocol Next Generation (RIPng) [RFC2080] [RFC2081], all support IPv6 ✅ it's worth noting that while OSPF and RIP differ significantly between IPv4 and IPv6, IS-IS has the advantage of handling both in a single instance of the protocol, with potential operational simplification in the long term 🌷 some versions of OSPFv3 may also have this advantage [RFC5838]. either way, for trained staff there should be no particular difficulty deploying IPv6 routing without disturbing IPv4 services 🥰 in some cases, firmware upgrades may be needed on some network devices 🔧
the performance impact of dual-stack routing needs to be evaluated 📊 in particular: what forwarding performance does the router vendor claim for IPv6? if it's significantly inferior to IPv4, will that be an operational problem? is extra memory or ternary content-addressable memory (TCAM) space needed to hold both IPv4 and IPv6 tables? to answer these questions, the ICP will need a projected model of the amount of IPv6 traffic expected initially and its likely rate of increase 📈
if a site has multiple PA prefixes as mentioned in Section 5.1, routing configuration gets complicated 🌀 in particular, source-based routing rules might be needed to make sure outgoing packets go to the appropriate border router and ISP link. normally, a packet sourced from an address assigned by ISP X should NOT be sent via ISP Y, to avoid ingress filtering by Y [RFC2827] [RFC3704] 🚫 more considerations can be found in [MULTIHOMING-WITHOUT-NAT]. and note that the prefix translation technique discussed in [RFC6296] does NOT describe a solution for enterprises that offer publicly available content servers 🙅♀️
each IPv6 subnet that supports end hosts normally has a /64 prefix, leaving another 64 bits for the interface identifiers of individual hosts 🧮 in contrast, a typical IPv4 subnet has no more than 8 bits for the host identifier, which limits the subnet to 256 or fewer hosts 🔢 a dual-stack design will typically use the same physical or VLAN subnet topology for IPv4 and IPv6, and therefore the same router topology. in other words, the IPv4 and IPv6 topologies are congruent 🪞 this means the limited subnet size of IPv4 (such as 256 hosts) will be imposed on IPv6 too, even though the IPv6 prefix would allow many more hosts 😭 it would be theoretically possible to avoid this limitation by implementing a different physical or VLAN subnet topology for IPv6. this is NOT advisable, though, because it would result in extremely complex fault diagnosis when something went wrong 🧯💜
5.3. DNS 💅
okay bestie, listen up 👂 the second a AAAA record for a well-known name goes live in the DNS, that server starts getting IPv6 traffic. no warning, no cap 😭 so an ICP has to test thoroughly that IPv6 actually works on its servers, load balancers, etc. before adding those AAAA records. there have been loads of cases where ICPs broke their sites for every IPv6 user mid roll-out by returning AAAA records for servers that weren't set up for IPv6 properly. big yikes 💀
once those tests pass, every externally visible host (or virtual host) with an A record for its IPv4 address needs a AAAA record [RFC3596] for its IPv6 address, plus a reverse entry (in ip6.arpa) if applicable 🦋 if CNAME records are in use, the AAAA record goes alongside the A record at the very end of the CNAME chain. you can't put the AAAA record on the same name as a CNAME record, per [RFC1912] 🙅♀️
one important detail: some clients (especially Windows XP) can only resolve DNS names over IPv4, even if they can use IPv6 for application traffic 🫠 also, a dual-stack resolver might try to resolve A record queries over IPv6, or AAAA record queries over IPv4. so it's advisable for all DNS servers to respond to queries over both IPv4 and IPv6 ✨
6. Load Balancers 🎀
most available load balancers now support IPv6 🌈 but it's important to get appropriate assurances from vendors about their IPv6 support, including performance (as discussed for routers in Section 5.2). the update needs to be planned with expected traffic growth in mind 📈 it's to be expected that IPv6 traffic will start out low, i.e., a small but growing percentage of total traffic.
for this reason, it might be acceptable to let IPv6 traffic bypass load balancing at first, by publishing a AAAA record for a specific server instead of the load balancer 🍓 however, load balancers often also provide server fail-over, so in that case it would be better to implement IPv6 load balancing right away 🔥
the same would apply to Transport Layer Security (TLS) or HTTP proxies used for load-balancing purposes 💜
7. Proxies 🧚
an HTTP proxy [RFC2616] can readily be configured to handle incoming connections over IPv6 and proxy them to a server over IPv4 ✨ so a single proxy can be the first step in an outside-in strategy, like this:
___________________________________________
( )
( IPv6 Clients in the Internet )
(___________________________________________)
|
-------------
| Ingress |
| router |
-------------
____________|_____________
|
-------------
| IPv6 stack|
|-----------|
| HTTP proxy|
|-----------|
| IPv4 stack|
-------------
____________|_____________
|
-------------
| IPv4 stack|
|-----------|
| HTTP |
| server |
-------------in this case, the AAAA record for the service would give the IPv6 address of the proxy 💖 this approach works for any HTTP or HTTPS applications that operate successfully via a proxy, as long as IPv6 load stays low 🌸 plus, many load-balancer products incorporate such a proxy, so this approach would be possible at high load too 💅
note that in any proxy scenario, an ICP needs to make sure that both IPv4 and IPv6 addresses are being properly passed to application servers in any relevant HTTP headers, and that those application servers are properly handling the IPv6 addresses 🚨
8. Servers 🖥️
8.1. Network Stack
the TCP/IP network stacks in popular operating systems have supported IPv6 for many years 🙌 in most cases, it's enough to enable IPv6 and possibly DHCPv6, and the rest follows. servers inside an ICP network won't need to support any transition technologies beyond a simple dual stack, with a possible exception for 6to4 mitigation noted below in Section 9 🫶
some operating systems have separate firewall rule sets for IPv4 and IPv6, so an ICP should also evaluate those rule sets and make sure appropriate firewall rules are configured for IPv6 🛡️ more details are discussed in Section 14.
8.2. Application Layer
basic HTTP servers have been able to handle an IPv6-enabled network stack for some years, so at the most you'll need to update to a more recent software version 🆙 the same goes for generic applications like email protocols. no general statement can be made about other applications, especially proprietary ones, so each ASP will need to make its own call 🤷♀️ since changes to the network layer that introduce IPv6 addresses can ripple through applications, testing of both client and server applications should be done in IPv4-only, IPv6-only, and dual-stack environments before dual-stacking a production environment 🧪
one important recommendation here: all applications should use domain names, which are IP-version-independent, rather than IP addresses 👑 applications based on middleware platforms with uniform IPv4 and IPv6 support, for example Java, may be able to support both naturally without additional work ☕ security certificates should also contain domain names rather than addresses 🔐
a specific issue for HTTP-based services is that IP address-based cookie authentication schemes will need to deal with dual-stack clients 🍪 servers might create a cookie for an IPv4 connection or an IPv6 connection, depending on the setup at the client site and on the whims of the client operating system 🙃 there's no guarantee a given client will consistently use the same address family, especially when accessing a collection of sites rather than a single site, such as when cookies are used for federated authentication. if the client is using privacy addresses [RFC4941], the IPv6 address (but usually not its /64 prefix) might change quite frequently 😵💫 any cookie mechanism based on 32-bit IPv4 addresses will need significant remodeling 🛠️
generic considerations on application transition are discussed in [RFC4038], but many of them won't apply to the dual-stack ICP scenario. an ICP that creates and maintains its own applications will need to review them for any dependency on IPv4 🔍
8.3. Logging
the introduction of IPv6 clients will generally also result in IPv6 addresses appearing in the "client ip" field of server logs 📜 it might be convenient to use the same log field to hold a client's IP address, whether it's IPv4 or IPv6. downstream systems that look at logs and client IP addresses may also need testing to make sure they can properly handle IPv6 addresses 🧐 this includes any of an ICP's databases recording client IP addresses, such as for recording IP addresses of online purchases and comment posters 🛒💬
it's worth noting that accurate traceback from logs to individual customers requires end-to-end address transparency 🕵️♀️ this is extra motivation for an ICP to support native IPv6 connectivity, because otherwise IPv6-only customers will inevitably connect via some form of translation mechanism, which interferes with traceback 🙅♀️
8.4. Geolocation
initially, ICPs may notice some weakness in geolocation for IPv6 clients 🗺️ as time goes on, it's to be assumed that geolocation methods and databases will be updated to fully support IPv6 prefixes. there's no reason they'll be more or less accurate in the long term than what's available for IPv4 ✅ however, we can expect many more clients to be mobile as time goes on, so geolocation based on IP addresses alone may become problematic in any case 📱 a more robust technique such as HTTP-Enabled Location Delivery (HELD) [RFC5985] could be considered 🦋
9. Coping with Transition Technologies 🦋
okay so, an ICP should get native IPv6 connectivity from its ISPs. That way it can skip most of the drama of the many IPv4-to-IPv6 transition technologies people have come up with. They're all second-best solutions, bestie 💅 However, some clients are definitely going to be using them anyway, so an ICP needs to know what operational issues that can cause and how to deal with them 🎀
Outside the ICP's control, clients might reach a content server through a network-layer translator from IPv6 to IPv4. ICPs offering a dual-stack service with both A and AAAA records, like this document recommends, should not normally receive IPv4 traffic from NAT64 translators [RFC6146]. Exceptionally though, that traffic could show up over IPv4 from an IPv6-only client whose DNS resolver didn't get the ICP's AAAA record for some reason. And honestly? That traffic looks exactly like regular IPv4-via-NAT traffic 🙈
Alternatively, dual-stack ICPs might exceptionally receive IPv6 traffic translated from an IPv4-only client that somehow failed to get the ICP's A record. An ICP could also receive IPv6 traffic with translated prefixes [RFC6296]. These two cases only become a problem if the ICP is offering any service that depends on the assumption of end-to-end IPv6 address transparency ✨
Finally, some traffic might reach an ICP after being translated twice on the way (for example, from IPv6 to IPv4 and back again). Again, the ICP won't be able to detect this 💀 Real-time geolocation is going to be super inaccurate for that traffic, since it will at best show the location of the second translator, which could be very far away from the customer 🌍
In other cases, also outside the ICP's control, IPv6 clients may reach the IPv6 Internet through some form of IPv6-in-IPv4 tunnel. A bunch of problems can pop up here, and the worst ones affect clients connected using the Anycast 6to4 solution [RFC3068]. Advice on how ICPs can mitigate these 6to4 problems is in Section 4.5. of [RFC6343]. For the benefit of all tunneled clients, it is essential to verify that Path MTU Discovery works correctly (i.e., the relevant ICMPv6 packets are not blocked), and that the server-side TCP implementation correctly supports the Maximum Segment Size (MSS) negotiation mechanism [RFC2923] for IPv6 traffic 🧚
Some ICPs have tried an interim fix for transition problems by limiting how visible their AAAA records are, so only users with validated IPv6 connectivity can see them [RFC6589]. This is known as "DNS whitelisting." At the time of writing, this solution seems to be on its way out, replaced by "DNS blacklisting" of customer sites that are known to have IPv6 connectivity problems. In the reverse direction, it's worth knowing that some ISPs with lots of clients who have broken IPv6 setups have started filtering AAAA record lookups from their clients. None of these solutions are appropriate in the long term 😭
Another approach some ICPs take is offering IPv6-only support through a specific DNS name, e.g., ipv6.example.com, if the primary service is www.example.com. In that case, ipv6.example.com would have an AAAA record only. This is useful for testing, but otherwise it's only of interest to hobbyist users who are willing to type in special URLs 🍓
There's not much an ICP can do about client-side or remote ISP deficiencies in IPv6 support. But it's hoped that the "Happy Eyeballs" approach [RFC6555] will improve clients' ability to deal with those problems 🫶
10. Content Delivery Networks 🌸
DNS-based techniques for diverting users to Content Delivery Network (CDN) points of presence (POPs) will work for IPv6, as long as AAAA records are provided as well as A records. In general, the CDN should follow the recommendations of this document, especially by operating a full dual-stack service at each POP. On top of that, each POP will need to handle IPv6 routing exactly like IPv4, for example by running BGP-4+ [RFC4760] 👑
Note that if an ICP supports IPv6 but its external CDN provider does not, its clients will keep using IPv4, and any IPv6-only clients will have to use some kind of transition solution. This isn't a great situation, since the ICP's work to support IPv6 will basically be wasted 😩
An ICP might end up in a complicated situation if its CDN provider supports IPv6 at some POPs but not others. IPv6-only clients could only be diverted to a POP that supports IPv6. There are also scenarios where a dual-stack client would be diverted to a mix of IPv4 and IPv6 POPs for different URLs, depending on the A and AAAA records provided and the availability of optimizations such as "Happy Eyeballs." Another side effect is that copies of the same content viewed at the same time over IPv4 and IPv6 may be different, because of latency in the underlying data synchronization process the CDN uses. This effect has actually been seen in the wild for a major social network that supports dual stack 👀 Still, these complications don't affect whether relying on a dual-stack CDN is viable.
The CDN itself has related complexity too: "As IPv6 rolls out, it's going to roll out in pockets, and that's going to make the routing around congestion points that much more important but also that much harder," stated John Summers of Akamai in 2010 [CDN-UPGRADE] 🌈
A converse situation that might come up is that an ICP hasn't started its IPv6 deployment yet, but finds that its CDN provider already supports IPv6. Then, assuming the CDN provider announces appropriate AAAA DNS Resource Records, dual-stack and IPv6-only customers will get IPv6 access, and the ICP's content may well be delivered to them over IPv6. Normally this shouldn't cause any problems, but it's a situation the ICP and its support staff need to be aware of. In particular, support staff should be given IPv6 connectivity so they can investigate any problems that might arise (see Section 4) 🧚
11. Business Partners 🎀
As noted earlier, it's in an ICP's or ASP's best interests for their users to have direct IPv6 connectivity, rather than indirect IPv4 connectivity via double NAT 🙌 If the ICP or ASP has a direct business relationship with some of their clients, or with the networks that connect them to their clients, they're advised to coordinate with those partners so they have a plan to enable IPv6. They should also verify and test that there is first-class IPv6 connectivity end-to-end between the networks concerned. This is especially true for implementations that need IPv6 support in specialized programs or systems before the IPv6 support on the ICP/ASP side can actually be useful 💖
12. Possible Complexities 💅
Some extra considerations come into play for certain complex or distributed sites and applications an ICP might be delivering. For example, an ICP may have a site spread across many hostnames (not all of which are under their control). Other ICPs may have their sites or applications distributed across multiple locations for availability, scale, or performance 🌸
Lots of modern websites and applications now use a collection of resources and applications, some run by the ICP and others by third parties. Most clients support sites that mix IPv4-only and dual-stack elements, but an ICP should track the IPv6 availability of embedded resources (like images). Otherwise, the site may only be partially functional or may have degraded performance for IPv6-only users 😭
DNS-based load-balancing techniques for diverting users to servers in multiple POPs will work for IPv6, as long as the load balancer supports IPv6 and AAAA records are provided. Depending on the load balancer's architecture, an ICP may need to run a full dual-stack service at each POP. With other architectures, it may be fine to start with IPv6 at only a subset of locations. Some architectures will make it preferable for IPv6 routing to mirror IPv4 routing (for example, running BGP-4+ [RFC4760] if appropriate), but this may not always be possible, since IPv6 and IPv4 connectivity can be independent ✨
Some complications can arise when a client supporting both IPv4 and IPv6 uses different POPs for each IP version (such as when IPv6 is only available in a subset of locations). There are also scenarios where a dual-stack client would be diverted to a mix of IPv4 and IPv6 POPs for different URLs, depending on the A and AAAA records provided and the availability of optimizations such as "Happy Eyeballs" [RFC6555]. Another side effect is that copies of the same content viewed at the same time over IPv4 and IPv6 may be different, because of latency in the underlying data synchronization process used at the application layer. This effect has actually been seen in the wild for a major social network that supports dual stack 🤯
Even with a single POP, unexpected behavior can happen if a client switches spontaneously between IPv4 and IPv6 as a performance optimization [RFC6555], or if its IPv6 address changes frequently for privacy reasons [RFC4941]. Those changes may affect cookies, geolocation, load balancing, and transactional integrity 🔥 Unexpected changes of client address also happen in an IPv4-only environment, but they may be more frequent with IPv6 🫠
13. Operations and Management ✨
okay so bestie, IPv6 is going to shake things up operationally at first 🫠 Staff have to update routers, touch configs, explain stuff to end users, and figure out brand new problems. It's giving "new season, same chaos" 💀 That's why education and training are a thing, which we covered back in Section 3. BUT here's the tea: for an enterprise network there's a ton of real-world experience, like on loads of university campuses, showing that dual-stack operation is no harder than IPv4-only once things are steady 🌸 Lowkey less scary than it sounds!
Whatever management, monitoring, and logging you do for IPv4 you also need for IPv6 💅 So every product and tool you use for that has to be updated to fully support IPv6 management data. Make sure your tools handle 128-bit addresses that get typed in and displayed in hexadecimal format [RFC5952] 🔥 Also, an IPv6 network can run with more than one IPv6 prefix, which means more than one address per host. Your tools have to treat that as a totally normal situation, not a weird edge case 🦋 That covers any address management tool you use (see Section 5.1) and the tools that build DHCP and DNS configs too. There's a big overlap here with the tools involved in site renumbering [RFC6879] 🧚
Early on, IPv6 will most likely be managed over IPv4 transport 🍓 That's actually a smart move, because it lets your network management systems check for dependencies between IPv4 and IPv6 management data. For example: will reports that mix IPv4 and IPv6 addresses actually display correctly? Test it! 🫶
In a second phase, you should manage the network over IPv6 transport ✨ Also, an ICP needs IPv6 connectivity for its operations and support staff, even when they're working remotely. As much as possible, avoid mutual dependency between IPv4 and IPv6, for both the management data and the transport 💜 If one fails, the other should not take it down with it. One precaution is making your network management systems dual-stacked, so you can use IPv4 connectivity to repair IPv6 configurations, and vice versa 👑
Dual stack is necessary, but it does come with management scaling and overhead considerations 😭 As mentioned earlier, the long-term goal is to move to single-stack IPv6, once the network and its customers can support it 🌈 That's another reason to avoid mutual dependency between the address families in the management system, especially. A hidden dependency on IPv4 that's been forgotten for years would be super inconvenient 🙈 Specifically, a management tool that manages IPv6 but itself only runs over IPv4 would be an absolute disaster on the day IPv4 gets switched off 💀
An ICP should make sure any end-to-end availability monitoring systems are updated to monitor dual-stacked servers over both IPv4 and IPv6 🔥 A tricky part here: monitoring systems that rely on DNS names may only end up monitoring one of IPv4 or IPv6. Then you lose visibility into connectivity failures on the other address family, and that's a total blind spot 👀
As mentioned above, an ICP also needs to provide IPv6 connectivity for its operations and support staff, even when they're working remotely 🫶
14. Security Considerations 🔐
Okay, this section is serious, so let's go 🫣 Many ICPs are still experimenting with and configuring IPv6, but there is mature malware out in the wild that will launch attacks over IPv6 💀 For example, if you add an AAAA DNS record for a hostname, malware using client OS libraries may automatically switch from attacking that hostname over IPv4 to attacking it over IPv6. So it's crucial that firewalls and other network security appliances protecting servers support IPv6 and have rules that are tested and configured 🛡️
Use your IPv4 security experience as a guide to the threats that may exist for IPv6 🦋 BUT don't assume those threats are equally likely, and don't assume they're the only threats that could exist in IPv6 either. Like, essentially every threat that exists for IPv4 exists, or will exist, for IPv6 too, to a greater or lesser extent 😭 It's essential to update firewalls, intrusion detection systems, denial-of-service precautions, and security auditing technology so they fully support IPv6. Also, turn on well-known security mechanisms like DNS Security and DHCPv6 Authentication, because otherwise IPv6 becomes an attractive target for attackers 🎯
When multiple PA prefixes are in use (see Section 5.1), your firewall rules must allow for all valid prefixes. They also must be set up to work as intended even when packets go out via one ISP and the return packets arrive via another 🌸
Performance and memory size of dual-stack firewalls must be considered too (as discussed for routers in Section 5.2) 💜
In dual-stack operation, there may be a risk of cross-contamination between the two protocols 🙀 For example, a successful IPv4-based denial-of-service attack might also drain resources the IPv6 service needs, or the other way around. This risk strengthens the argument that IPv6 security has to be up to the same level as IPv4 🔥 Risks can also show up with dual-stack Virtual Private Network (VPN) solutions [VPN-LEAKAGES] 🫠
A general overview of techniques for protecting an IPv6 network against external attacks is in [RFC4864] 📚 Assuming an ICP has native IPv6 connectivity, it's advisable to block incoming IPv6-in-IPv4 tunnel traffic using IPv4 protocol type 41. Outgoing traffic of this kind should be blocked too, except for the case noted in Section 4.5 of [RFC6343] 🚫 ICMPv6 traffic should only be blocked in accordance with [RFC4890]. In particular, Packet Too Big messages are essential for Path MTU Discovery, so they MUST NOT be blocked 🚨
Heads up bestie: those Packet Too Big messages are load-bearing for Path MTU Discovery, so never block them. That's a hard MUST NOT! 🚨
Brute-force scanning to discover whether hosts exist is much less likely to succeed for IPv6 than for IPv4 [RFC5157] 🙌 BUT, don't get too cocky, because various naming or addressing conventions can make IPv6 address space predictable or guessable 🙈 In the extreme case, IPv6 hosts might be configured with interface identifiers that are super easy to guess. For example, hosts or subnets manually numbered with consecutive interface identifiers starting from "1" would be way easier to guess. Such practices SHOULD be avoided 🙅♀️, and other useful precautions are discussed in [RFC6583] ✨ Also, attackers might find IPv6 addresses in logs, packet traces, DNS records (including reverse records), or elsewhere 👀
Protection against rogue Router Advertisements (RA Guard) should also be considered [RFC6105] 🚧
Transport Layer Security version 1.2 [RFC5246] and its predecessors work correctly with TCP over IPv6, which means HTTPS-based security solutions are immediately applicable 🔒 The same SHOULD apply to any other transport-layer or application-layer security techniques 💖
If an ASP uses IPsec [RFC4301] and the Internet Key Exchange (IKE) protocol [RFC5996] in any way to secure connections with clients, those are fully applicable to IPv6 too, but only if the software stack at each end has been appropriately updated 🧚
15. Acknowledgements 🎀
Huge thanks to Erik Kline, who made valuable contributions 🫶 Useful comments came in from Tore Anderson, Cameron Byrne, Tassos Chatzithomaoglou, Wesley George, Deng Hui, Joel Jaeggli, Roger Jorgensen, Victor Kuarsingh, Bing Liu, Trent Lloyd, John Mann, Michael Newbery, Erik Nygren, Arturo Servin, Mark Smith, and other participants in the V6OPS working group 🌈
Brian Carpenter was a visitor at the Computer Laboratory, Cambridge University during part of this work 🇬🇧✨
16. References 📚
16.1. Normative References
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
October 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011.16.2. Informative References ✨
okay bestie, this is the extra reading list 📚 these aren't required to follow the spec, but they're the sources the doc leans on, and they're so worth a peek 🫶
- [CDN-UPGRADE] Marsan, C., "Akamai: Why our IPv6 upgrade is harder than Google's", Network World, September 2010,
<http://www.networkworld.com/news/2010/091610-akamai-ipv6.html>. 🌐 - [IPv6-CE-REQS] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", Work in Progress, October 2012. 🎀
- [IPv6-NETWORK-DESIGN] Matthews, P., "Design Choices for IPv6 Networks", Work in Progress, February 2013. 🦋
- [MULTIHOMING-WITHOUT-NAT] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", Work in Progress, February 2012. 💜
- [RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996. 🍓
- [RFC2081] Malkin, G., "RIPng Protocol Applicability Statement", RFC 2081, January 1997. 🧚
- [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000. 🌸
- [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. ⭐
- [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. 💅
- [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. 🔥
- [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007. 🛡️
- [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 🙈
- [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008. 👑
- [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment Considerations", RFC 5375, December 2008. 🌈
- [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 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. 🦋
- [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011. 🌸
- [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011. 🎀
- [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011. 🍓
- [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012. 🧚
- [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012. 💀
- [RFC6589] Livingood, J., "Considerations for Transitioning Content to IPv6", RFC 6589, April 2012. 🫶
- [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", RFC 6866, February 2013. 💖
- [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013. 👑
- [VPN-LEAKAGES] Gont, F., "Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks", Work in Progress, December 2012. 🔥
Authors' Addresses 💜
okay and here's who wrote it, so you know exactly who to thank 🫶✨
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
EMail: brian.e.carpenter@gmail.com
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No. 156 Beiqing Road
Hai-Dian District, Beijing 100095
P.R. China
EMail: jiangsheng@huawei.com📦 where this page comes from
- ietf: rfc6883 2013-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms