RFC 6589

Considerations for Transitioning Content to IPv6

📅 published April 2012, from ietf

RFC 6589: Considerations for Transitioning Content to IPv6 🎀

Category: Informational 📚 Published: April 2012 🗓️ Author: J. Livingood, Comcast 💖 ISSN: 2070-1721 🌸 Obsoletes / Updates: Nothing. The header doesn't list anything this one obsoletes or updates ✨

Part 1 of 7 🧚

Abstract

okay bestie, so this doc is all about how end-user content on the Internet (think websites 💅) should make the move to IPv6. It's written with web content in mind, but a lot of it could work for other apps and services too 🦋. It digs into the challenges of the IPv6 transition, possible migration tactics, possible phases for the rollout, and some other stuff to think about. The audience is the Internet community in general, and IPv6 implementers especially 🫶.

Status of This Memo

this is NOT an Internet Standards Track spec, it's published just for information purposes 📖

it's a product of the Internet Engineering Task Force (IETF) and it represents what the IETF community agreed on. it got public review and the Internet Engineering Steering Group (IESG) approved it for publication 💜. not every IESG-approved doc is up for any level of Internet Standard though, so check Section 2 of RFC 5741 if you want the details 🙈

for the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6589 🔗

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the day it was published. pls actually read those, bestie, because they spell out your rights and restrictions for this doc 🥹

if you pull Code Components out of this doc, they have to include the Simplified BSD License text the way Section 4.e of the Trust Legal Provisions describes, and they come with no warranty as laid out in the Simplified BSD License ⚖️

Table of Contents

1. Introduction ....................................................4
2. Challenges When Transitioning Content to IPv6 ...................4
   2.1. IPv6-Related Impairment ....................................5
   2.2. Operational Maturity Concerns ..............................5
   2.3. Volume-Based Concerns ......................................5
3. IPv6 Adoption Implications ......................................6
4. Potential Migration Tactics .....................................6
   4.1. Solving Current End-User IPv6 Impairments ..................7
   4.2. Using IPv6-Specific Names ..................................8
   4.3. Implementing DNS Resolver Whitelisting .....................8
        4.3.1. How DNS Resolver Whitelisting Works ................11
        4.3.2. Similarities to Content Delivery Networks
               and Global Server Load Balancing ...................15
        4.3.3. Similarities to DNS Load Balancing .................15
        4.3.4. Similarities to Split DNS ..........................15
        4.3.5. Related Considerations .............................16
   4.4. Implementing DNS Blacklisting .............................17
   4.5. Transitioning Directly to Native Dual Stack ...............18
5. Potential Implementation Phases ................................19
   5.1. No Access to IPv6 Content .................................19
   5.2. Using IPv6-Specific Names .................................19
   5.3. Deploying DNS Resolver Whitelisting Using Manual
        Processes .................................................19
   5.4. Deploying DNS Resolver Whitelisting Using
        Automated Processes .......................................19
   5.5. Turning Off DNS Resolver Whitelisting .....................20
   5.6. Deploying DNS Blacklisting ................................20
   5.7. Fully Dual-Stack Content ..................................20
6. Other Considerations ...........................................20
   6.1. Security Considerations ...................................20
   6.2. Privacy Considerations ....................................21
   6.3. Considerations with Poor IPv4 and Good IPv6 Transport .....22
7. Contributors ...................................................23
8. Acknowledgements ...............................................23
9. References .....................................................24
   9.1. Normative References ......................................24
   9.2. Informative References ....................................25

1. Introduction ✨

okay so this doc covers how end-user content on the Internet moves over to IPv6. It's tailored to end-user content, which is usually web-based, but a bunch of it could apply to other apps and services too 🌸. The stuff in here is especially relevant to big web content sites (we're calling them "high-service-level domains" 👑), since they have their own unique worries about keeping things smooth for all their users while they switch to IPv6 😭. The doc explores the challenges of the transition, possible migration tactics, possible phases, and other considerations. Some sections also talk about what the different tactics or phased approaches could mean for the transition 🦋.

2. Challenges When Transitioning Content to IPv6 💅

the goal is to make content natively dual-stack, which gives everyone native access over both IPv4 and IPv6 🌈. but the transition isn't always smooth for every user, technically or operationally, so people have come up with a bunch of migration tactics 🫶. step one in understanding those tactics is laying out the challenges of moving content to IPv6 ✨.

implementers of these tactics are trying to keep their users from having a bad time (aka poor performance) when they get DNS responses containing AAAA resource records, or when they try to use IPv6 transport 😩. there are two main concerns here: one is IPv6-related impairment, and the other is how mature or stable IPv6 transport (and the network operations around it) is for high-service-level domains. both can wreck the end-user experience 💀.

not every domain faces the same challenges, because the user base, traffic sources, traffic volumes, and other factors obviously vary from domain to domain 🍓. so while some domains used a migration tactic, others ran short IPv6 experiments and then just turned on IPv6 without waiting around or using any special migration tactics [Heise] 🔥. each domain should think about its own situation when making an IPv6 plan, because there's no one-size-fits-all approach 💖.

some implementers noticed that when they added AAAA resource records to their authoritative DNS servers so people could reach their content over IPv6, a small fraction of end users had slow or otherwise messed-up access to a site that had both AAAA and A resource records. that fraction has been estimated at as high as 0.078% of total Internet users [IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness] 😳.

it's outside the scope of this doc to get into all the reasons a particular user's system (host) might have impaired IPv6 access, or the possible fixes for that [RFC6555] [RFC6343]. but for the users who do have it, it's a very real performance hit 💔. it can affect access to all or most of the dual-stack services that user tries to reach. the experience can range from kinda slower than usual (compared to native IPv4 access), to extremely slow, to no access to the domain's resources at all 😭. basically, even if the user has an IPv6 address or not, just getting a AAAA record response can mean they either can't reach the Fully Qualified Domain Name (FQDN, the name for the service or resource they wanted) or it's so slow they give up and decide the destination is unreachable 💀✨.

2.2. Operational Maturity Concerns 🧚

some implementers found that network operations, operations support and business support systems, and other operational processes and procedures are less mature for IPv6 than for IPv4. that's because IPv6 hasn't been pervasively deployed until now 🦋. this operational immaturity can show up not just inside a given domain's network, but also in any networks it's directly or indirectly connected to 🌸. so lots of domains think it's smart to make any network change that shifts traffic to IPv6 gradually, to give IPv6 operations and network practices time and experience to mature 🫶.

2.3. Volume-Based Concerns 🔥

Section 2.2 is about the risks from operational immaturity, but there's a related worry too: some technical issues don't show up until a moderate to high volume of traffic goes over IPv6 to and from a domain 👀. same as before, this can happen not just inside that domain's network but also in any directly or indirectly connected networks 🌈. plus, compared to domains with small or moderate traffic (whether you count end users or bytes transferred), high-traffic domains get enough usage that it's wise to roll out network changes gradually and in a way that keeps the risk of disruption low 💅. imagine one of the top ten sites in the world suddenly flipping on a huge amount of IPv6 traffic. honestly? that's terrifying, and it would carry a pretty high risk of network and/or other disruptions 😭💜

3. IPv6 Adoption Implications ✨

Okay bestie, this part is about why moving content to IPv6 is such a big deal for the whole ecosystem 🌸. It is super important that the challenges from Section 2 actually get handled, especially for high-service-level domains 💅. Some of those domains might find the IPv6 transition extremely daunting unless they have some way to tackle those challenges and control the move step by step 😭. Without those controls, some domains might put off their IPv6 transition for a long time 🙈. Now, if content moves to IPv6 slowly, network operators have somewhat fewer reasons to deploy IPv6 to end-user hosts 🦋. They still have plenty of big reasons that have nothing to do with content 💜. Meanwhile, if network operators aren't moving to IPv6, domain owners have fewer reasons to move their content too, so it's kind of a loop 🔥. Without progress in every part of the Internet ecosystem, networks and/or content sites might delay, postpone, or even stop adopting IPv6, or go looking for alternatives 💀. Those alternatives could include multi-layer or large-scale network address translation (NAT), which is not preferred compared to native dual stack 🫶.

Obviously, moving content to IPv6 matters a lot for IPv6 adoption overall 👑. The challenges are real, but it's not an impossible task for a domain 💖. There's a whole range of possible migration tactics, covered in Section 4 below, that can help a domain meet these challenges and successfully move its content and other services to IPv6 ✨.

4. Potential Migration Tactics 🦋

Domains have a huge toolkit of tactics they can use to make the move to IPv6 💅. This section covers many of the key ones, but it is absolutely not a complete or exclusive list 🌈. Only a specific domain can decide whether a given tactic (or any tactic) applies to it and meets its needs 🎀. A domain can also run several of these tactics at the same time 🍓. So how useful each tactic is, and its pros and cons, will depend on the domain ✨.

4.1. Solving Current End-User IPv6 Impairments 🧚

Domains can try to fix the underlying technical problems their end users run into during the IPv6 transition, as covered in Section 2.1 🔧. One challenge is that a domain may have little or no control over its end users' network connectivity, operating system, client software (like a web browser), and/or other capabilities 😬. In most cases, a domain can only influence and guide its end users 🫣. That's not the same kind of direct control you'd have in, say, an enterprise network 💼. Still, major domains are usually trusted by their end users, so they may be able to influence and guide those users in solving any IPv6-related impairments 🫶.

Another challenge: one domain can't solve end-user impairments all on its own 🙅. So domains may find it works better to team up with lots of others in the Internet community to tackle what is really a collective problem that affects the whole Internet 🤝. Getting everyone to work together, sharing the labor, time, and costs, can be hard, ngl 😭. But World IPv6 Day [W6D] shows that community efforts are possible, and even with those challenges, the Internet community keeps working together to fix end-user IPv6 impairments 🌸.

One possible tactic is to figure out which users have these impairments and then tell those affected users 📣. This kind of end-user communication is most helpful when users are not just alerted to a potential problem, but also given careful, detailed advice on how to fix it themselves, or pointed to where they can get help 💜. Another possible tactic is for a domain to collect, track over time, and periodically share with the Internet community the rate of impairment it observes 📊. For any end-user IPv6-related analysis and communication like this, Section 6.2 is worth taking into account 👀.

However, these tactics can help reduce IPv6-related impairments (Section 2.1), but they don't address operational maturity concerns (Section 2.2) or volume-based concerns (Section 2.3) 🙃. Those should be considered and addressed separately 🫶.

4.2. Using IPv6-Specific Names 🎀

Another migration tactic is for a domain to gain experience using a special FQDN 🌷. This is super typical for domains starting the IPv6 transition, where an address-family-specific name like ipv6.example.com or www.ipv6.example.com gets used 💖. The catch is that an end user would have to know to use this special IPv6-specific name, since it isn't the same name used for regular traffic 🙈.

This special name points traffic to a host or hosts that have been enabled for native IPv6 access 🦋. In some cases, it points to hosts that are separate from the ones used for IPv4 traffic (via www.example.com), and in other cases it points to the very same hosts used for IPv4 traffic 🌈. If separate hosts are used for the special IPv6-specific names, a subsequent phase is to move to the same hosts used for regular traffic, so production infrastructure gets used and exercised more fully 💪. Either way, using the special name is a way to incrementally control traffic, so a domain can build IPv6 experience and grow IPv6 use on a fairly controlled basis 🧁. Any lessons learned can then inform plans for a full transition to IPv6 📝. It also gives a domain room to develop staff training 🎓, build IPv6-related testing procedures for its production network and lab 🧪, deploy IPv6 functionality into its production network 🚀, and develop and deploy IPv6-related network and service monitors 👀. It's also a chance to add a relatively small amount of IPv6 traffic to make sure network gear, network interconnects, and IPv6 routing in general are working as expected ✅.

While using a special IPv6-specific name is a good initial step to functionally test and prep a domain for IPv6 🫶, including developing and maturing IPv6 operations (Section 2.2), the tactic has limits 😅. Users have to know the IPv6-specific name, the traffic volume will be low, and the traffic is unlikely to be representative of the general population of end users (they're likely to be self-selecting early adopters and more technically advanced than average), among other reasons 💅. So any concerns and risks related to traffic volume (Section 2.3) should still be considered and addressed separately 💜.

4.3. Implementing DNS Resolver Whitelisting ✨

okay bestie, this next tactic is so cute 🎀. It's for when a high-service-level domain is ready to move past an IPv6-specific name (see Section 4.2 🦋). The move is to selectively return AAAA resource records (RRs), which contain IPv6 addresses 💅. An authoritative DNS server for a domain does this selective answering in response to queries from DNS recursive resolvers [RFC1035]. The Internet community calls it "DNS Resolver Whitelisting", and that's what we'll call it from here on 🌸. Honestly it's just a way of selectively returning DNS records based on various technical factors. An end user is looking up a resource by name, and this selective response lets the most reliable and best performing IP address family get used (IPv4 or IPv6) 🔥. It's giving cousin energy to Content Delivery Networks (CDNs), Global Server Load Balancing (GSLB), DNS Load Balancing, and Split DNS, which we'll get into in Sections 4.3.2, 4.3.3, and 4.3.4 💜. A few high-service-level domains have either implemented DNS Resolver Whitelisting (one of many migration tactics they have used or are using) or are considering it [NW-Article-DNS-WL] [WL-Ops] 👑.

This is a migration tactic domains use to move inbound traffic over to IPv6 bit by bit 🍓. Without an incremental approach like this, a domain could return AAAA resource records to every relevant DNS query. That means it could go from no IPv6 traffic to a potentially huge amount the second those AAAA records get published 💀. With DNS Resolver Whitelisting, the domain's authoritative DNS selectively returns a AAAA resource record to recursive resolvers on a whitelist the domain maintains, and returns no AAAA resource records to recursive resolvers that aren't on it 🧚. This tactic won't directly reduce IPv6-related impairments (Section 2.1), but it can help a domain with operational maturity concerns (Section 2.2) and with concerns and risks related to traffic volume (Section 2.3) 🫶. Whitelisting doesn't solve IPv6-related impairments, but it can help a domain avoid the users who have them, so the tactic removes their impact in all but the few whitelisted networks 🙈. It also lets website operators protect non-IPv6 networks (i.e., networks that do not support IPv6 and/or do not have plans to do so in the future) from IPv6-related impairments in their networks ✨. Finally, domains using this tactic should understand that the onus is on them to make sure the whitelisted servers represent a network that has proven to their satisfaction that they are IPv6-ready, and that this won't create a poor end-user experience for users of the whitelisted server 💅.

There are of course challenges and concerns with DNS Resolver Whitelisting 🥺. Some of the concerns about a whitelist of DNS recursive resolvers may come from parties other than the implementing domain, like network operators or end users whose DNS recursive resolvers never got added to a whitelist. Also, the IP address of a DNS recursive resolver isn't a precise indicator of IPv6 preparedness, or lack of IPv6-related impairment, for the end-user hosts that query (use) it 🤔. The IP addresses of DNS recursive resolvers on networks known to have deployed IPv6 may be an imperfect proxy for judging that, but this method is still one of the better available options right now 💖. For example, implementers have found they can measure the IPv6 preparedness of the end users behind any given DNS recursive resolver by ongoing measurement of end users querying one-time-use hostnames, then correlating the domain's authoritative DNS server logs with their web server logs 🧚‍♀️. That helps implementers get a good picture of which DNS recursive resolvers have working IPv6 users behind them and which don't, what the latency impact of turning on IPv6 for any given DNS recursive resolver is, and so on 📊. Also, given where global IPv6 deployment is right now, this tactic lets content providers selectively expose their IPv6 services 🌈. Opinions about DNS Resolver Whitelisting are understandably all over the place, but there's clear consensus that it can be a useful tactic during a domain's transition to IPv6 😭. Some high-service-level domains see it as one of the few practical and low-risk approaches that enable them to transition, and without it their transition may not happen for some time 🎀. There's also consensus that doing this on a manual basis (see below) is workable only in the short term and won't scale over the long term 🥀. So some domains may find DNS Resolver Whitelisting a beneficial temporary tactic in their transition to IPv6 🦋.

Right now, generally speaking, a domain that implements DNS Resolver Whitelisting does it manually 📝. That means the domain keeps its own list of networks that are allowed to receive IPv6 records (via their DNS resolver IP addresses), and those networks usually apply, or follow some other process the domain set up, to get added to the DNS Whitelist 📮. Implementers foresee that a later phase of DNS Resolver Whitelisting is likely to emerge, possibly soon 🔮. In that phase, a domain would return IPv6 and/or IPv4 records dynamically based on automatically detected technical capabilities, location, or other factors 🛰️. It would then work much like (or as part of) GSLB, a common practice already in use today, as described in Section 4.3.2 💜. In this future phase, networks would also be added to and removed from a DNS Whitelist automatically, possibly on a near-real-time basis ⚡. The crucial part is that networks wouldn't need to apply to get on a whitelist anymore, which may ease many of the key concerns network operators have with the manual version 🫶.

4.3.1. How DNS Resolver Whitelisting Works

Okay bestie, so a "whitelist" in the generic sense means no traffic (or a certain type of traffic) gets to the destination host unless the originating host's IP address is on the list 🔒. A "blacklist" is the opposite vibe: all traffic gets through unless the originating host's IP address is on the list 🚫. With DNS Resolver Whitelisting, the thing an end user is actually after is a name, not an IP address or IP address family 💖. So they're seeking something like www.example.com, and they don't care which IP address family (IPv4 or IPv6) gets used to reach it 🦋.

DNS Resolver Whitelisting is implemented in authoritative DNS servers, not in DNS recursive resolvers 🧚. These authoritative DNS servers selectively return AAAA resource records based on the IP address of the DNS recursive resolver that sent them a query ✨. So for a website operator like www.example.com, the domain operator sets up whitelisting on the authoritative DNS servers for the domain example.com 🎀. The whitelist is filled with the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive resolvers on the Internet that have been authorized to receive AAAA resource record responses 🌈. These resolvers are run by third parties, like Internet Service Providers (ISPs), universities, governments, businesses, and individual end users 🌸. If a DNS recursive resolver is not matched in the whitelist, then AAAA resource records WILL NOT be sent in response to a query for a hostname in the example.com domain (and an A record would be sent) 🙈. But if a DNS recursive resolver IS matched in the whitelist, then AAAA resource records WILL be sent 🔥. So, while Section 2.2 of [RFC4213] notes that a stub resolver can choose between using a AAAA record or A record response, with DNS Resolver Whitelisting the authoritative DNS server can also decide whether to return a AAAA record, an A record, or both record types 👑.

When this is done manually, DNS Resolver Whitelisting generally means that a very small fraction of the DNS recursive resolvers on the Internet (the ones in the whitelist) will receive AAAA responses 🥺. That means the large majority of DNS recursive resolvers on the Internet will receive only A resource records containing IPv4 addresses 😭. Domains may find the practice adds some incremental operational burdens, insofar as it can eat up staff time to maintain a whitelist (such as additions and deletions to the list), respond to and review applications to be added to a whitelist, maintain good performance levels on authoritative DNS servers as the whitelist grows, create new network monitors to check the health of a whitelist function, perform new types of troubleshooting related to whitelisting, etc. 💅 Manual whitelisting also adds some incremental burdens for operators of DNS recursive resolvers (such as network operators), since they will need to apply to be whitelisted with any implementing domains, and will then need processes and systems to track the status of those applications, respond to requests for additional information about them, and track any de-whitelisting actions 📋.

When this is implemented on an automated basis in the future, DNS recursive resolvers listed in the whitelist could expand and contract dynamically, and possibly in near-real time, based on a wide range of factors ⭐. So the number of DNS recursive resolvers on the whitelist will likely be substantially larger than when the list is maintained manually, and the whitelist will likely grow at a rapid rate 🚀. This automation can eliminate most of the significant incremental operational burdens on implementing domains and on operators of DNS recursive resolvers, which is clearly a big reason implementers are working to automate this function 🤩.

Section 4.3.1.1 and Figure 1 give more details on DNS Resolver Whitelisting in general 📚. The potential deployment models of DNS Resolver Whitelisting (manual and automated) are described in Section 5 🦋. It's also important to note that DNS Resolver Whitelisting works independently of whether an authoritative DNS server, DNS recursive resolver, or end-user host uses IPv4 transport, IPv6, or both 🌈. So, for example, whitelisting may not result in the return of AAAA responses even where the DNS recursive resolver has queried the authoritative server over an IPv6 transport 🙃. This may also happen in some situations when the end-user host's original query to its DNS recursive resolver was over IPv6 transport, if that DNS recursive resolver is not on a given whitelist 🫠. One important reason is that even though the DNS recursive resolver may have no IPv6-related impairments, this is not a reliable predictor of whether the same is true of the end-user host 🧐. This also means that a DNS Whitelist can contain both IPv4 and IPv6 addresses 🍓.

4.3.1.1. Description of the Operation of DNS Resolver Whitelisting

Specific implementations will vary from domain to domain, based on a range of factors such as the technical capabilities of a given domain 🎀. So any examples listed here should be considered general examples and are not intended to be exhaustive ✨.

The system logic of DNS Resolver Whitelisting goes like this 🧠:

  1. The authoritative DNS server for example.com receives DNS queries for the A (IPv4) and/or AAAA (IPv6) address resource records for the FQDN www.example.com, for which AAAA (IPv6) resource records exist.
  2. The authoritative DNS server checks the IP address (IPv4, IPv6, or both) of the DNS recursive resolver sending the AAAA (IPv6) query against the whitelist (i.e., the DNS Whitelist).
  3. If the DNS recursive resolver's IP address IS matched in the whitelist, then the response to that specific DNS recursive resolver can contain AAAA (IPv6) address resource records.
  4. If the DNS recursive resolver's IP address IS NOT matched in the whitelist, then the response to that specific DNS recursive resolver cannot contain AAAA (IPv6) address resource records. In this case, the server will likely return a response with the response code (RCODE) set to 0 (No Error) with an empty answer section for the AAAA record query 🥹.
+--------------------------------------------------------------------+
| Caching Server 1 - IS NOT ON the DNS Whitelist                     |
| Caching Server 2 - IS ON the DNS Whitelist                         |
| Note: Transport between each host can be IPv4 or IPv6.             |
+--------------------------------------------------------------------+
+----------+          +---------------+         +---------------+
|   Stub   |          |  DNS Caching  |         |      DNS      |
| Resolver |          |   Server 1    |         |     Server    |
+----------+          +---------------+         +---------------+
   | DNS Query:            |                         |
   | example.com A, AAAA   |                         |
   |---------------------->|                         |
   |                       |                         |
   |                       | DNS Query:              |
   |                       | example.com A, AAAA     |
   |                       |------------------------>|
   |                       |                         |
   |                       |                         | NOT on Whitelist
   |                       |           DNS Response: |
   |                       |           example.com A |
   |                       |<------------------------|
   |                       |                         |
   |         DNS Response: |                         |
   |         example.com A |                         |
   |<----------------------|                         |
+----------+          +---------------+         +---------------+
|   Stub   |          |  DNS Caching  |         |      DNS      |
| Resolver |          |   Server 2    |         |     Server    |
+----------+          +---------------+         +---------------+
   | DNS Query:            |                         |
   | example.com A, AAAA   |                         |
   |---------------------->|                         |
   |                       |                         |
   |                       | DNS Query:              |
   |                       | example.com A, AAAA     |
   |                       |------------------------>|
   |                       |                         |
   |                       |                         | IS on Whitelist
   |                       |           DNS Response: |
   |                       |     example.com A, AAAA |
   |                       |<------------------------|
   |                       |                         |
   |         DNS Response: |                         |
   |   example.com A, AAAA |                         |
   |<----------------------|                         |

Figure 1: DNS Resolver Whitelisting Diagram

4.3.2. Similarities to Content Delivery Networks and Global Server Load Balancing

DNS Resolver Whitelisting is functionally similar to CDNs and GSLB 🌐. When using a CDN or GSLB, a geographically aware authoritative DNS server function is usually part of that overall system 🗺️. So the use of a CDN or GSLB with an authoritative DNS server function lets the IP address resource records returned to a resolver in response to a query vary based on the estimated geographic location of the resolver [Wild-Resolvers] or a range of other technical factors 💫. This CDN or GSLB DNS function is performed to try to direct hosts to a) connect either to the nearest host (as measured in round-trip time) or to the host that has the best connectivity to an end user, b) route around failures, c) avoid sites where maintenance work has taken down hosts, and/or d) connect to the host that will otherwise give an end user the best service experience at a given point in time 🎯. That's why you can see a direct similarity to DNS Resolver Whitelisting, since different IP address resource records are selectively returned to resolvers based on the IP address of each resolver and/or other imputed factors related to that address 👯‍♀️.

4.3.3. Similarities to DNS Load Balancing ✨

okay so DNS Resolver Whitelisting has some similarities to DNS Load Balancing 🫶 and there are of course many ways DNS Load Balancing can be done. one example: you can add multiple IP address resource records (A and/or AAAA) to the DNS for a given FQDN. this is called DNS round robin [RFC1794] 🎀 DNS round robin may also be used where SRV resource records are used [RFC2782].

another example is where one or more of the IP address resource records in the DNS send traffic to a load balancer 💅 that load balancer might be application-aware and pass the traffic on to one or more hosts that are connected to it and that have different IP addresses. in cases where private IPv4 addresses are used [RFC1918], as well as when public IP addresses are used, those end hosts may not necessarily be directly reachable without going through the load balancer first. so, kinda like DNS Resolver Whitelisting, a load balancer controls which server host an end-user's host talks to when using an FQDN 👑

4.3.4. Similarities to Split DNS 🦋

DNS Resolver Whitelisting also has some similarities to so-called Split DNS, which is briefly described in Section 3.8 of [RFC2775]. with Split DNS, the authoritative DNS server selectively returns different responses depending on which host sent the query 🧚 [RFC2775] notes that the typical use of Split DNS is to give one answer to hosts on an Intranet (internal network) and a different answer to hosts on the Internet (external or public network). but the basic idea is that different answers go to hosts on different networks.

this is kind of how DNS Resolver Whitelisting works too 👀 hosts on different networks that use different DNS recursive resolvers get different answers if one resolver is on the whitelist and the other one isn't. BUT ngl there are Internet transparency and Internet fragmentation concerns about Split DNS, and those are detailed in Section 2.1 of [RFC2956] 😭 Section 2.7 of [RFC2956] also notes concerns about Split DNS, including the concern that the deployment of Split DNS "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint identifiers more complex". and Section 3.5 of [RFC2956] recommends that keeping a stable approach to DNS operations is key during transitions, like the one to IPv6 that is happening right now, and it says that "Operational stability of DNS is paramount, especially during a transition of the network layer, and both IPv6 and some network address translation techniques place a heavier burden on DNS" 🫠

okay this part is a little more serious, bestie 🥹 techniques like GSLB and DNS Load Balancing (which have a lot in common with DNS Resolver Whitelisting) are everywhere, but some people in the community have raised a bunch of concerns about all of these practices. some concerns are specific to DNS Resolver Whitelisting [WL-Concerns]. other concerns are more general and are about putting content location or other network policy controls in the "middle" of the network, in a so-called "middlebox" function. whether these DNS-related functions are really part of a middlebox is debatable 🤷‍♀️ still, implementers should at least be aware of some of the risks of middleboxes, as noted in [RFC3724].

a related document, [RFC1958], explains that configured state, policies, and other functions needed in the middle of the network should be minimized as a design goal 🧠 Section 2.16 of [RFC3234] makes specific statements about modified DNS servers. Section 1.2 of [RFC3234] also outlines more general concerns about new failure modes showing up when configuration is no longer limited to two ends of a session, so diagnosing failures and misconfigurations could get way more complex 🌀 two more sources worth checking out are [Tussle] and [Rethinking], where the authors note concerns about new control points (e.g., in middleboxes or in the DNS) 💜

BUT here's the plot twist 🎬 state, policies, and other functions have always been necessary to enable effective, reliable, and high-quality end-to-end communications on the Internet. and GSLB, CDNs, DNS Load Balancing, and Split DNS are not only widely deployed, they're almost uniformly seen as essential to how the Internet works and super beneficial to the quality of the end-user experience 🍓 these techniques have had, and still have, a good effect on a wide range of Internet applications and protocols ✨ so yes, there are valid concerns about putting policy controls in the "middle" of the network, or anywhere away from edge hosts, but what counts as the middle and edge of the network is debatable here. this is especially true because GSLBs and CDNs help connect end hosts with the optimal content hosts, so they could be considered a modest and, in many cases, essential network policy extension of a network's edge, especially for high-service-level domains 🔥

there may be extra implications for end users who have configured their hosts to use a third party as their DNS recursive resolver, instead of the one(s) provided by their network operator 👀 in those cases it will be harder for a domain using whitelisting to figure out the level of IPv6-related impairment, because there's a wide variety of end-user access networks that might be used, and this mix may change in unpredictable ways over time 🫣

4.4. Implementing DNS Blacklisting 🖤

so with DNS Resolver Whitelisting, DNS recursive resolvers can only receive AAAA resource records if they're on the whitelist. DNS Blacklisting is the opposite 🙃 all DNS recursive resolvers can receive AAAA resource records unless they're on the blacklist. some implementers of DNS Resolver Whitelisting might choose to switch over to DNS Blacklisting later on. it's not clear when, or if, it would be appropriate for a domain to change from whitelisting to blacklisting, and it's also not clear how implementers will decide that network conditions have changed enough to justify turning off those controls 🤔

when a domain uses blacklisting, it's letting all DNS recursive resolvers get AAAA record responses, except for what is presumed to be a relatively small number on the blacklist 💅 over time, the blacklist will likely get smaller as the networks tied to the blacklisted DNS recursive resolvers manage to meaningfully reduce IPv6-related impairments down to some acceptable level. though it's possible some networks may never get there 😔 DNS Blacklisting is also probably less labor intensive for a domain than doing DNS Resolver Whitelisting by hand, simply because the domain would presumably be focused on a smaller number of DNS recursive resolvers with well-known IPv6-related problems 🧹

also worth noting: the email industry has a long history with blacklists 📧 and very generally speaking, blacklists tend to work well and get a good reception when it's easy to find out if an IP address is on one, when there's a transparent and easy-to-understand process for asking to be removed, and when the decision-making criteria for blacklisting a server are openly disclosed and seen as fair ⚖️ BUT unlike an email blacklist, where a blacklisted host can't send email to a domain at all, with DNS Resolver Whitelisting, communications will still happen over IPv4 transport 💖

4.5. Transitioning Directly to Native Dual Stack 🚀

if you don't want any of the migration tactics we've been talking about, domains can go straight to native dual stack 🏃‍♀️✨ that means adding native IPv6 capabilities to their network and hosts, and publishing AAAA resource records in the DNS for their named resources. and a domain can still control this transition gradually, name by name, by adding native IPv6 to one name at a time, like mail.example.com first and www.example.com later 🌸 so even a "direct" transition can be done gradually, lowkey iconic.

then it's up to end users with IPv6-related impairments to find and fix any applicable impairments 🔧 BUT the concerns and risks related to traffic volume (Section 2.3) should still be considered and managed, because those aren't directly related to such impairments ⚠️ not every content provider (or other domain) may face the challenges detailed here, or face them to the same degree, since the user base of each domain, traffic sources, traffic volumes, and other factors obviously vary between domains 🙈

for example, some content providers have used DNS Resolver Whitelisting (one migration tactic), while others ran IPv6 experiments where they added AAAA resource records, observed and measured errors, and then decided not to use DNS Resolver Whitelisting [Heise] 🧪 a more widespread example was World IPv6 Day [W6D], sponsored by the Internet Society, on June 8, 2011 🎉 it was a unique moment where hundreds of domains added AAAA resource records to the DNS without using DNS Resolver Whitelisting, all at the same time. some of the participating domains chose to keep AAAA resource records in place after the experiment, based on what they saw 💜

content providers can run their own independent experiments in the future too 🧫 they can add AAAA resource records for a brief period (minutes, hours, or days), then analyze any impacts or effects on traffic and the experience of end users. they can also just turn on IPv6 for their domain, which may be easier when the transition doesn't involve a high-service-level domain 💅

5. Potential Implementation Phases 🪜

okay so the usefulness of each tactic in Section 4, plus the pros and cons of each one, are relative to each potential implementer and will vary from one implementer to another 🫶 so it's not possible to say the potential phases below make sense for every implementer. the duration of each phase will vary between implementers too, and different implementers may even skip some of these phases entirely 🙃 and finally, the tactics listed in Section 4 are by no means exclusive. mix and match, bestie 🍹

5.1. No Access to IPv6 Content 🙅‍♀️

in this phase, a site is only accessible via IPv4 transport. at the time of this writing, the majority of content on the Internet is in this state and is not accessible natively over IPv6 😭

5.2. Using IPv6-Specific Names 🧚‍♀️

one possible first step for a domain is to get some experience using a specialized new FQDN, like ipv6.example.com or www.ipv6.example.com, as explained in Section 4.2 🎀

5.3. Deploying DNS Resolver Whitelisting Using Manual Processes 🛠️

as noted in Section 4.3, a domain could start using DNS Resolver Whitelisting as a way to gradually turn on IPv6 access to content 🦋 this tactic may be especially interesting to high-service-level domains 👑

5.4. Deploying DNS Resolver Whitelisting Using Automated Processes ✨

Okay so if a domain starts out doing DNS Resolver Whitelisting on a manual basis 📝, it can totally level up later and move to automated 🤖. That's explained in Section 4.3, and honestly? It can make all the operational stress of a manually maintained whitelist way easier to handle 💅💖

5.5. Turning Off DNS Resolver Whitelisting 🦋

Bestie, domains that choose to do DNS Resolver Whitelisting usually see it as a temporary measure, not a forever thing 🥺 Lots of implementers have announced that they plan to permanently turn it off starting on the date of the World IPv6 Launch, June 6, 2012 [World-IPv6-Launch] 🌍🎀 But for any implementers that don't turn it off at that time, it's kinda unclear how each and every one will decide when network conditions have changed enough to justify switching it off 🤷‍♀️

That being said, it's giving that the extent of IPv6 deployment to end users in networks, the state of IPv6-related impairment, and the maturity of IPv6 operations are all super important factors 💜 Any implementers like that may wish to keep in mind that, as a practical matter, it will be impossible to get to a point where there are no longer any IPv6-related impairments 😭 Some reasonably small number of hosts will inevitably be left behind, either because end users choose not to upgrade them or because some hosts are incapable of being upgraded 💀

5.6. Deploying DNS Blacklisting 🙈

Regardless of whether a domain has first implemented DNS Resolver Whitelisting or has never done so, DNS Blacklisting, as described in Section 4.4, may be of interest 🧚 This may be the point in time when domains want to make their content widely available over IPv6, but still want to protect end users of a few networks with well-known IPv6 limitations from having a bad end-user experience 🫶

5.7. Fully Dual-Stack Content 🌈

A domain can arrive at this phase by either following a previous IPv6 migration tactic or going directly here, as noted in Section 4.5 👑 In this phase, the site's content has been made natively accessible via both IPv4 and IPv6 for all end users on the Internet, or at least without the use of any other IPv6 migration tactic ⭐

6. Other Considerations 💅

6.1. Security Considerations 🔥

Okay this section is SERIOUS bestie, so read it carefully 😤

If DNS Resolver Whitelisting is adopted, as noted in Section 4.3, then organizations that apply DNS Resolver Whitelisting policies in their authoritative servers should have procedures and systems that do not allow unauthorized parties to modify the whitelist (or blacklist), just as all configuration settings for name servers should be protected by appropriate procedures and systems 🔒 Such unauthorized additions or removals from the whitelist (or blacklist) can be damaging, causing content providers and/or network operators to incur support costs from end-user and/or customer contacts, and causing potentially dramatic and disruptive swings in traffic from IPv6 to IPv4 or vice versa 📉😱

DNS Security Extensions (DNSSEC) as defined in [RFC4033], [RFC4034], and [RFC4035] use cryptographic digital signatures to provide origin authentication and integrity assurance for DNS data 🔐 This is done by creating signatures for DNS data on a Security-Aware Authoritative Name Server, which can be used by Security-Aware Resolvers to verify the answers 🧾 Since DNS Resolver Whitelisting is implemented on an authoritative DNS server, which gives different answers depending upon which DNS resolver has sent a query, the DNSSEC chain of trust is not altered 🔗 So even though an authoritative DNS server will selectively return AAAA resource records or a non-existence response, both types of responses will be signed and will validate ✅ In practical terms, this means that two separate views or zones are used, each of which is signed, so that whether or not particular resource records exist, the existence or non-existence of the record can still be validated using DNSSEC 🤓 As a result, there should not be any negative impact on DNSSEC for those domains that have implemented DNSSEC on their Security-Aware Authoritative Name Servers and also implemented DNS Resolver Whitelisting 💖 As for any party implementing DNSSEC, such domains should of course ensure that resource records are being appropriately and reliably signed and are consistent with the response being returned 🫡

However, network operators that run DNS recursive resolvers should be careful not to modify the responses received from authoritative DNS servers 🚨 It's possible that some networks may attempt to do so in order to prevent AAAA record responses from going to end-user hosts, due to some IPv6-related impairment or other lack of IPv6 readiness within that network 🙃 But when a network operates a Security-Aware Resolver, modifying or suppressing AAAA resource records for a DNSSEC-signed domain could break the chain of trust established with DNSSEC 💀💀

6.2. Privacy Considerations 🎀

As noted in Section 4.1, there is a benefit in sharing IPv6-related impairment statistics within the Internet community over time 📊 Any statistics that are shared or disclosed publicly should be aggregate statistics, such as "the domain example.com has observed an average daily impairment rate of 0.05% in September 2011, down from 0.15% in January 2011" 🍓 They should not include information that can directly or indirectly identify individuals, such as names or email addresses 🙅‍♀️ Sharing only aggregate data can help protect end-user privacy and any information that may be proprietary to a domain 🔐

Also, there are often methods to detect IPv6-related impairments for a specific end user, such as running an IPv6 test when an end user visits the website of a particular domain 🕵️‍♀️ Should a domain then choose to automatically communicate the facts of an impairment to an affected user, there are likely no direct privacy considerations 👍 However, if the domain then decides to share information concerning that particular end user with that user's network operator or another third party, then the domain may wish to consider advising the end user of this and seeking to obtain the end-user's consent to share such information 🫶

Appropriate guidelines for any information-sharing likely vary by country and/or legal jurisdiction 🌏 Domains should consider any potential privacy issues when deciding what information can be shared 🧐 If a domain does publish or share detailed impairment statistics, it would be well advised to avoid identifying individual hosts or users 🙈

Finally, if a domain chooses to contact end users directly about their IPv6 impairments, that domain should make sure such communication is permissible under any applicable privacy policies of the domain or its websites 📬✨

6.3. Considerations with Poor IPv4 and Good IPv6 Transport 🌸

There are situations where the differing quality of an end user's IPv4 and IPv6 connectivity could cause complications in accessing content when a domain is using an IPv6 migration tactic 🤹‍♀️ While today most end users' IPv4 connectivity is typically superior to IPv6 connectivity (if such connectivity exists at all), there could be implications when the reverse is true and an end user has markedly superior IPv6 connectivity compared to IPv4 🔄 This is not a theoretical situation; it has been observed by at least one major content provider 👀

For example, in one possible scenario, a user is issued IPv6 addresses by their ISP and has a home network and devices or operating systems that fully support native IPv6 🏠 As a result, this theoretical user has very good IPv6 connectivity 🚀 However, this end user's ISP has exhausted its available pool of unique IPv4 addresses, and uses NAT to share IPv4 addresses among end users 😩 So, for IPv4 content, the end user must send their IPv4 traffic through some additional network element (e.g., large-scale NAT, proxy server, tunnel server) 🛤️ Using this additional network element might cause an end user to experience sub-optimal IPv4 connectivity when certain protocols or applications are used 🐢 This user then has good IPv6 connectivity but impaired IPv4 connectivity 🥲 As a result, the user's poor IPv4 connectivity could potentially be made worse when accessing a domain that uses a migration tactic that only lets this user access content over IPv4 transport, for whatever reason 💔

Should this sort of situation become widespread in the future, a domain may wish to take it into account when deciding how and when to transition content to IPv6 🔮

7. Contributors 🧚‍♀️

The following people made significant textual contributions to this document and/or played an important role in the development and evolution of this document:

  • John Brzozowski
  • Chris Griffiths
  • Tom Klieber
  • Yiu Lee
  • Rich Woundy

8. Acknowledgements 🫶

The author and contributors also wish to acknowledge the assistance of the following individuals or groups 💜 Some of these people provided helpful and important guidance in the development of this document and/or in the development of the concepts covered in it 🧠 Other people assisted by performing a detailed review of this document and then providing feedback and constructive criticism for revisions, or engaged in a healthy debate over the subject of the document 🔥 All of this was helpful, and therefore the following individuals merit acknowledgement 👑

  • Bernard Aboba
  • Mark Andrews
  • Jari Arkko
  • Fred Baker
  • Ron Bonica
  • Frank Bulk
  • Brian Carpenter
  • Lorenzo Colitti
  • Alissa Cooper
  • Dave Crocker
  • Ralph Droms
  • Wesley Eddy
  • J.D. Falk
  • Adrian Farrel
  • Stephen Farrell
  • Tony Finch
  • Karsten Fleischhauer
  • Igor Gashinsky
  • Wesley George
  • Philip Homburg
  • Jerry Huang
  • Ray Hunter
  • Joel Jaeggli
  • Erik Kline
  • Suresh Krishnan
  • Victor Kuarsingh
  • Marc Lampo
  • Donn Lee
  • John Leslie
  • John Mann
  • Danny McPherson
  • Milo Medin
  • Martin Millnert
  • Russ Mundy
  • Thomas Narten
  • Pekka Savola
  • Robert Sparks
  • Barbara Stark
  • Joe Touch
  • Hannes Tschofenig
  • Tina Tsou
  • Members of the Broadband Internet Technical Advisory Group (BITAG)

9. References 📚

9.1. Normative References 📚✨

Okay bestie, these are the must-read ones 💅 Every single one of these is basically load-bearing, so no skipping 🫶

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995.

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.

[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.

[RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", RFC 2956, October 2000.

[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.

[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.

9.2. Informative References 🌈🔍

Bonus reading time 🧚 These are the extra-spicy receipts behind the whole story 💜

[Heise] Heise.de, "The Big IPv6 Experiment", Heise.de Website http://www.h-online.com, January 2011, <http://www.h-online.com/features/The-big-IPv6-experiment-1165042.html>.

[IETF-77-DNSOP] Gashinsky, I., "IPv6 & recursive resolvers: How do we make the transition less painful?", IETF 77 DNS Operations Working Group, March 2010, <http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>.

[IPv6-Brokenness] Anderson, T., "Measuring and Combating IPv6 Brokenness", Reseaux IP Europeens (RIPE) 61st Meeting, November 2010, <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.

[IPv6-Growth] Colitti, L., Gunderson, S., Kline, E., and T. Refice, "Evaluating IPv6 adoption in the Internet", Proceedings of the 11th International Conference on Passive and Active Measurement (PAM 2010), Springer, Lecture Notes in Computer Science, 2010, Volume 6032, Passive and Active Measurement, Pages 141-150.

[NW-Article-DNS-WL] Marsan, C., "Google, Microsoft, Netflix in talks to create shared list of IPv6 users", Network World, March 2010, <http://www.networkworld.com/news/2010/032610-dns-ipv6-whitelist.html>.

[NW-Article-DNSOP] Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", Network World, March 2010, <http://www.networkworld.com/news/2010/032610-yahoo-dns.html>.

[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.

[Rethinking] Blumenthal, M. and D. Clark, "Rethinking the Design of the Internet: The End-to-End Arguments vs. the Brave New World", ACM Transactions on Internet Technology, Volume 1, Number 1, Pages 70-109, August 2001, <http://groups.csail.mit.edu/ana/Publications/PubPDFs/Rethinking the design of the internet2001.pdf>.

[Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", Proceedings of ACM Sigcomm 2002, August 2002, <http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf>.

[W6D] The Internet Society, "World IPv6 Day - June 8, 2011", Internet Society Website http://www.isoc.org, January 2011, <http://isoc.org/wp/worldipv6day/>.

[WL-Concerns] Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y., Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?", ISOC (Internet Society) IPv6 Deployment Workshop, April 2010, <http://www.comcast6.net/IPv6_DNS_Whitelisting_Concerns_20100416.pdf>.

[WL-Ops] Kline, E., "IPv6 Whitelist Operations", Google IPv6 Implementors Conference, June 2010, <http://sites.google.com/site/ipv6implementors/2010/agenda/IPv6_Whitelist_Operations.pdf>.

[Wild-Resolvers] Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig, "Comparing DNS Resolvers in the Wild", ACM Sigcomm Internet Measurement Conference 2010, November 2010, <http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.

[World-IPv6-Launch] The Internet Society, "World IPv6 Launch Website", June 2012, <http://www.worldipv6launch.org/>.

Author's Address 💌

Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US

EMail: jason_livingood@cable.comcast.com URI: http://www.comcast.com

📦 where this page comes from