Executive Summary

Internet Protocol version 6 (IPv6) is the new form of addressing for the Internet. IPv6 is being deployed as a result of the exhaustion of the supply of the older form of addressing, Internet Protocol version 4 (IPv4). The Internet is now beginning a global transition from IPv4 to IPv6, although most websites and networks will run both address families in parallel for many years.

This document describes the emerging practice of Internet web sites (or, more broadly, "Internet domains"), such as example.com, selectively returning IPv6-related resources from Domain Name System (DNS) servers. As a result, the domain can enable or disable a network (and, as a consequence, that network's users) from accessing the domain's content over IPv6. This practice is known as "DNS Whitelisting" and is intended as a means to smooth the global transition from IPv4 to IPv6.

DNS Whitelisting was first used by major web content sites. These web site operators observed that when they added IPv6 records to their DNS servers in order to support IPv6 access to their content, a fraction of end users had slow or otherwise impaired access to this content [IPv6 Dual-Stack Client Loss in Norway].

Major domains are motivated by a desire to maintain a high-quality user experience for all of their users, as well as to shift traffic to IPv6 in a controlled manner. Thus, domains engaging in DNS Whitelisting are attempting to shield users with impaired access from the symptoms of those impairments until they can be remedied. Those domains are also interested in having a degree of control over their own migration to IPv6 that they would otherwise lack without DNS Whitelisting, so that IPv6 traffic can be added gradually as IPv6 operations and network practices mature.

At the same time, critics of the practice have articulated a range of technical and non- technical concerns and are focused on ensuring that DNS Whitelisting, when implemented, is done in a manner that is transparent, non-discriminatory, and not anti-competitive.

Generally speaking, a domain that implements DNS Whitelisting does so manually. This means that the domain manually maintains a list of networks that are permitted to receive IPv6 records (via their DNS resolver IP addresses) and that these networks typically submit applications in order to be added to the DNS Whitelist.

Domain operators foresee that a second phase of DNS Whitelisting may emerge in the future, possibly in the near future. In this new phase a domain would return IPv6 and/or IPv4 records dynamically based on automatically detected technical capabilities, location, or other factors. It would then function much like (or as part of) global server load balancing, a common suite of practices already in use today. Furthermore, in this second phase, networks might be added to and removed from a DNS Whitelist automatically, and possibly on a near-real-time basis. This means that networks may no longer need to apply to be added to a whitelist, which could alleviate some of the issues addressed herein.

Since this future phase has yet to emerge, this document and its suggestions apply only to the DNS Whitelisting practices currently known to the BITAG. The BITAG reserves its opinion on future alternative practices until they can be articulated and evaluated.

Although current implementations are not perceived to have this impact, the BITAG is interested in this issue on that grounds that, without careful and monitored deployment, some whitelisting services could in the future be viewed as anti- competitive, discriminatory or in violation of some other public policy objective. The practice may be viewed as controversial and the manner in which it is employed could result in concerns or complaints. As a result, it is important to inform the public and policymakers about why DNS Whitelisting is used and how it functions, to identify concerns surrounding its use, and to outline some potential implementation steps that domains could take to minimize the risk of complaints and controversy.

The BITAG has formulated a set of suggested practices regarding the implementation of DNS Whitelisting to help reduce such complaints, acknowledging that practices may vary as a domain moves from experimentation with whitelisting and IPv6 to a point of operational stability. The suggested (and voluntary) practices are as follows:

Limit the Duration of the Use of DNS Whitelisting - The BITAG suggests that domain operators use DNS Whitelisting as briefly as possible for those critical domains that will encounter significant end user IPv6-related impairments. The BITAG recognizes that the primary purpose for DNS Whitelisting is to permit IPv6 address service to networks that are essentially problem-free while preferring IPv4 for those that are not and that the duration of Whitelisting is tied to that assessment.

Transparently Publish Policies and Processes - The BITAG suggests that domains make their policies and processes easy to find and understand. The contact persons should be easy to find and reach as well.

Clearly Describe Decision-Making Criteria - The BITAG suggests that policies and procedures that a domain publishes include criteria used to make DNS Whitelisting and de-whitelisting decisions.

Use Primarily Quantitative Decision-Making Criteria - The BITAG suggests that domains use quantitative data (such as the number of IPv6-related impairments or the performance of IPv6 network routes) to make whitelisting and de-whitelisting decisions.

Set and Publish Service Level Goals for Decision-Making - The BITAG suggests that domains publish clearly detailed and timely service level goals for how long the DNS Whitelisting decision-making process will take.

Specify an Appeals Process - The BITAG suggests that domains may wish to consider specifying a process for networks to appeal both whitelisting and de-whitelisting decisions.

Maintain Updated Contacts for Whitelisted Domains - The BITAG suggests that domains establish a list of contacts for whitelisted organizations and adopt practices that assure that the list is current.

Set a Joint-Troubleshooting Interval Before De-Whitelisting Occurs - The BITAG suggests that domains set a reasonable period of time and process for a whitelisted party to resolve any problems that may arise that could lead to de-whitelisting. The BITAG recognizes that there may be emergency conditions that require immediate action.

Transparently Publish Whitelisted Parties - The BITAG suggests that domains identify the networks that are currently listed in their DNS whitelists.

Openly Share IPv6-Related Impairment Statistics - The BITAG suggests that domains share detailed statistics about IPv6 impairments with any party (campus network, enterprise, ISP, etc.) that may be affected by DNS Whitelisting. The BITAG recognizes that privacy concerns may limit the kinds of data that can be shared.

Detect and Notify End Users with IPv6-Related Impairments - The BITAG suggests that, where practical, domains take reasonable steps to detect IPv6-related impairments and take reasonable steps to communicate this in an easy-to-understand way to affected users.