draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06.txt   draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07.txt 
IPv6 Operations J. Livingood IPv6 Operations J. Livingood
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational June 8, 2011 Intended status: Informational October 14, 2011
Expires: December 10, 2011 Expires: April 16, 2012
IPv6 AAAA DNS Whitelisting Implications Considerations for Transitioning Content to IPv6
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
Abstract Abstract
This document describes the practice and implications of whitelisting This document describes considerations for the transition of end user
DNS recursive resolvers in order to limit AAAA resource record content on the Internet to IPv6. While this is tailored to address
responses (which contain IPv6 addresses) sent by authoritative DNS end user content, which is typically web-based, many aspects of this
servers. This is an IPv6 transition mechanism used by domains as a document may be more broadly applicable to the transition to IPv6 of
method for incrementally transitioning inbound traffic to a domain other applications and services. This document explores the
from IPv4 to IPv6 transport. The audience for this document is the challenges involved in the transition to IPv6, potential transition
Internet community generally, particularly IPv6 implementers. techniques, possible transition phases, and other considerations.
The audience for this document is the Internet community generally,
particularly IPv6 implementers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 10, 2011. This Internet-Draft will expire on April 16, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5 2. Challenges When Transitioning Content to IPv6 . . . . . . . . 4
2.1. Description of the Operation of DNS Whitelisting . . . . . 6 2.1. IPv6-Related Impairment . . . . . . . . . . . . . . . . . 5
2.2. Comparison with Blacklisting . . . . . . . . . . . . . . . 9 2.2. Operational Maturity Concerns . . . . . . . . . . . . . . 5
3. Similarities to Other DNS Operations . . . . . . . . . . . . . 9 2.3. Volume-Based Concerns . . . . . . . . . . . . . . . . . . 5
3.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 9 3. IPv6 Adoption Implications . . . . . . . . . . . . . . . . . . 6
3.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 10 4. Potential Transition Techniques . . . . . . . . . . . . . . . 6
4. What Problems Are Implementers Trying To Solve? . . . . . . . 10 4.1. Solve Current End User IPv6 Impairments . . . . . . . . . 7
4.1. Volume-Based Concerns . . . . . . . . . . . . . . . . . . 11 4.2. Use IPv6 Transition Names . . . . . . . . . . . . . . . . 8
4.2. IPv6-Related Impairment . . . . . . . . . . . . . . . . . 11 4.3. Implement DNS Resolver Whitelisting . . . . . . . . . . . 8
4.3. Free Versus Subscription Services . . . . . . . . . . . . 13 4.3.1. How DNS Resolver Whitelisting Works . . . . . . . . . 10
5. General Implementation Variations . . . . . . . . . . . . . . 13 4.3.2. Similarities to Content Delivery Networks and
5.1. Implement DNS Whitelisting Universally . . . . . . . . . . 13 Global Server Load Balancing . . . . . . . . . . . . . 14
5.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 14 4.3.3. Similarities to DNS Load Balancing . . . . . . . . . . 14
5.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 14 4.3.4. Similarities to Split DNS . . . . . . . . . . . . . . 14
5.3.1. Solve Current End User IPv6 Impairments . . . . . . . 14 4.3.5. Related Considerations . . . . . . . . . . . . . . . . 15
5.3.2. Gain Experience Using IPv6 Transition Names . . . . . 15 4.4. Implement DNS Blacklisting . . . . . . . . . . . . . . . . 16
5.3.3. Implement DNS Blacklisting . . . . . . . . . . . . . . 15 4.5. Transition Directly to Native Dual Stack . . . . . . . . . 17
6. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 16 5. Potential Implementation Phases . . . . . . . . . . . . . . . 18
7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 17 5.1. No Access to IPv6 Content . . . . . . . . . . . . . . . . 18
7.1. Architectural Implications . . . . . . . . . . . . . . . . 17 5.2. Using IPv6 Transition Names . . . . . . . . . . . . . . . 18
7.2. Public IPv6 Address Reachability Implications . . . . . . 18 5.3. Deploying DNS Resolver Whitelisting Using Manual
7.3. Operational Implications . . . . . . . . . . . . . . . . . 19 Processes . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 19 5.4. Deploying DNS Resolver Whitelisting Using Automated
7.3.2. Authoritative DNS Server Operational Implications . . 19 Processes . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3.3. DNS Recursive Resolver Server Operational 5.5. Turning Off DNS Resolver Whitelisting . . . . . . . . . . 18
Implications . . . . . . . . . . . . . . . . . . . . . 20 5.6. Deploying DNS Blacklisting . . . . . . . . . . . . . . . . 19
7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 21 5.7. Fully Dual-Stack Content . . . . . . . . . . . . . . . . . 19
7.3.5. Implications of Operational Momentum . . . . . . . . . 22 6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 22 6.1. Security Considerations . . . . . . . . . . . . . . . . . 19
7.3.7. Additional Implications If Deployed On An Ad Hoc 6.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 20
Basis . . . . . . . . . . . . . . . . . . . . . . . . 22 6.3. Considerations with Poor IPv4 and Good IPv6 Transport . . 21
7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 23 6.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 21
7.5. Technology Policy Implications . . . . . . . . . . . . . . 23 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
7.7. Implications with Poor IPv4 and Good IPv6 Transport . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.8. Implications for Users of Third-Party DNS Recursive 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Resolvers . . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . . 25
8. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 26 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 29
9.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Authoritative DNS Response Consistency Considerations . . 27
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
14.1. Normative References . . . . . . . . . . . . . . . . . . . 30
14.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 33
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
This document describes the practice and implications of whitelisting This document describes considerations for the transition of end user
DNS recursive resolvers in order to limit AAAA resource record (RR) content on the Internet to IPv6. While this is tailored to address
responses (which contain IPv6 addresses) sent by authoritative DNS end user content, which is typically web-based, many aspects of this
servers. This is referred to hereafter as DNS Whitelisting. This is document may be more broadly applicable to the transition to IPv6 of
an IPv6 transition mechanism used by domains as a method for other applications and services. The issues explored herein will be
incrementally transitioning inbound traffic to a domain from IPv4 to of particular interest to major web content sites (sometimes
IPv6 transport. When implemented, a domain's authoritative DNS will described hereinafter as "high-traffic domains"), which have specific
return a AAAA resource record to DNS recursive resolvers [RFC1035] on and unique concerns relating to maintaining a high-quality user
the whitelist, while returning no AAAA resource records to DNS experience for all of their users during their transition to IPv6.
recursive resolvers which are not on the whitelist. The practice This document explores the challenges involved in the transition to
appears to have first been used by major web content sites (sometimes IPv6, potential transition techniques, possible transition phases,
described hereafter as "high-traffic domains"), which have specific and other considerations. Some sections of this document also
concerns relating to maintaining a high-quality user experience for include information about the potential implications of various
all of their users during their transition to IPv6. transition techniques or phased approaches to the transition to IPv6.
Critics of the practice of DNS Whitelisting have articulated several 2. Challenges When Transitioning Content to IPv6
concerns. Among these are that:
o DNS Whitelisting is a very different behavior from the current The goal in transitioning content to IPv6 is to make that content
practice concerning the publishing of IPv4 address resource natively dual-stack enabled, which provides native access to all end
records, users via both IPv4 and IPv6. However, there are technical and
operational challenges in being able to transition smoothly for all
end users, which has led to the development of a variety of
transition techniques. A first step in understanding various
transition techniques is to first outline the challenges involved in
moving content to IPv6.
o that it may create a two-tiered Internet, Implementers of these various transition techniques are attempting to
protect users of their services from having a negative experience
(poor performance) when they receive DNS responses containing AAAA
resource records or when attempting to use IPv6 transport. There are
two main concerns which pertain to this practice; one of which is
IPv6-related impairment and the other which is the maturity or
stability of IPv6 transport (and associated network operations) for
high-traffic domains. Both can negatively affect the experience of
end users.
o that policies and decision-making for whitelisting and de- Not all domains may face the same challenges in transitioning content
whitelisting are opaque or likely to cause conflict, to IPv6, since the user base of each domain, traffic sources, traffic
volumes, and other factors obviously will vary between domains. As a
result, while some domains have used an IPv6 transition technique,
others have run brief IPv6 experiments and then decided to simply
turn on IPv6 for the domain without further delay and without using
any specialized IPv6 transition techniques [Heise]. Each domain
should therefore consider its specific situation when formulating a
plan to move to IPv6; there is not one approach that will work for
every domain.
o that DNS Whitelisting reduces interest in the deployment of IPv6, 2.1. IPv6-Related Impairment
o that new operational and management burdens are created, Some implementers have observed that when they added AAAA resource
records to their authoritative DNS servers in order to support IPv6
access to their content that a small fraction of end users had slow
or otherwise impaired access to a given web site with both AAAA and A
resource records. The fraction of users with such impaired access
has been estimated to be as high as 0.078% of total Internet users
[IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness],
though more recent measurements indicate this is declining
[Impairment-Tracker].
o that the practice does not scale, While it is outside the scope of this document to explore the various
reasons why a particular user's system (host) may have impaired IPv6
access, for the users who experience this impairment it has a very
real performance impact. It would impact access to all or most dual
stack services to which the user attempts to connect. This negative
end user experience can range from somewhat slower than usual access
(as compared to native IPv4-based access), to extremely slow access,
to no access to the domain's resources whatsoever. In essence,
whether the end user even has an IPv6 address or not, merely by
receiving a AAAA record response the user either cannot access a
Fully Qualified Domain Name (FQDN, representing a service or resource
sought) or it is so slow that the user gives up and assumes the
destination is unreachable.
o that it violates a basic premise of cross-Internet 2.2. Operational Maturity Concerns
interoperability by requiring prior arrangements,
o and that the costs and negative implications of DNS Whitelisting Some implementers have discovered that network operations, operations
outweigh the perceived benefits. support and business support systems, and other operational processes
and procedures are less mature for IPv6 as compared to IPv4, since
IPv6 has not heretofore been pervasively deployed. This operational
immaturity may be observed not just within the network of a given
domain but also in any directly or indirectly interconnected
networks. As a result, many domains consider it prudent to undertake
any network changes which will cause traffic to shift to IPv6
gradually in order to provide time and experience for IPv6 operations
and network practices mature.
This document explores the reasons and motivations for DNS 2.3. Volume-Based Concerns
Whitelisting Section 4. It also explores the concerns regarding this
practice, and whether and when the practice is recommended Section 8.
Readers will hopefully better understand what DNS Whitelisting is,
why some domains are implementing it, and what the implications are.
2. How DNS Whitelisting Works While Section 2.2 pertains to risks due to immaturity in operations,
a related concern is that some technical issues may not become
apparent until some moderate to high volume of traffic is sent via
IPv6 to and from a domain. As above, this may be the case not just
within the network of that domain but also for any directly or
indirectly interconnected networks. Furthermore, compared to domains
with small to moderate traffic volumes, whether by the count of end
users or count of bytes transferred, high-traffic domains receive
such a level of usage that it is prudent to undertake any network
changes gradually and in a manner which minimizes the risk of
disruption. One can imagine that for one of the top ten sites
globally, for example, the idea of suddenly turning on a significant
amount of IPv6 traffic is quite daunting and would carry a relatively
high risk of network and/or other disruptions.
Generally, using a whitelist means no traffic (or traffic of a 3. IPv6 Adoption Implications
certain type) is permitted to the destination host unless the
originating host's IP address is contained in the whitelist. In
contrast, using a blacklist means that all traffic is permitted to
the destination host unless the originating host's IP address is
contained in the blacklist.
DNS Whitelisting is implemented in authoritative DNS servers, not in It is important that the challenges in transitioning content to IPv6
DNS recursive resolvers. These authoritative DNS servers implement noted in Section 2 are addressed, especially for high-traffic
IP address-based restrictions on AAAA query responses. So far, DNS domains. Some high-traffic domains may find the prospect of
Whitelisting has been primarily implemented by web site operators transitioning to IPv6 extremely daunting without having some ability
deploying IPv6-enabled services, though this practice could affect to address these challenges and to incrementally control their
all protocols and services within a domain. For a given operator of transition to IPv6. Lacking such controls, some domains may choose
a website, such as www.example.com, the domain operator essentially to substantially delay their transition to IPv6. A substantial delay
applies an access control list (ACL) on the authoritative DNS servers in content moving to IPv6 could certainly mean there are somewhat
for the domain example.com. The ACL is populated with the IPv4 fewer motivating factors for network operators to deploy IPv6 to end
user hosts (though they have many significant motivating factors that
are largely independent of content). At the same time, unless
network operators transition to IPv6, there are of course fewer
motivations for domain owners to transition content to IPv6. Without
progress in each part of the Internet ecosystem, networks and/or
content sites may delay, postpone, or cease adoption of IPv6, or to
actively seek alternatives to it. Such alternatives may include the
use of multi-layer or large scale network address translation (NAT)
techniques, which is not preferred relative to native dual stack.
Obviously, transitioning content to IPv6 is important to IPv6
adoption overall. While challenges do exist, such a transition is
not an impossible task for a domain to undertake. A range of
potential transition techniques, as noted below in Section 4, can
help meet these challenges and enable a domain to successfully
transition content and other services to IPv6.
4. Potential Transition Techniques
Domains have a wide range of potential techniques at their disposal
that may be used to facilitate the transition to IPv6. This section
includes many of the key techniques that could be used by a domain
but it is by no means an exhaustive or exclusive list. Only a
specific domain can judge whether or not a given (or any) transition
technique applies to their domain and meets their needs. A domain
may also decide to pursue several of these techniques in parallel.
Thus, the usefulness of each technique and the associated pros and
cons will vary from domain to domain.
4.1. Solve Current End User IPv6 Impairments
Domains can endeavor to fix the underlying technical problems
experienced by their end users during the transition to IPv6, as
noted in Section 2.1. One challenge with this option is that a
domain may have little or no control over the network connectivity,
operating system, client software (such as a web browser), and/or
other capabilities of the end users of that domain. In most cases a
domain is only in a position to influence and guide their end users.
While this is not the same sort of direct control which may exist in
an enterprise network for example, major domains are likely to be
trusted by their end users and may therefore be able to influence and
guide these users in solving any IPv6-related impairments.
Another challenge is that end user impairments are something that one
domain on their own cannot solve. This means that domains may find
it more effective to coordinate with many others in the Internet
community to solve what is really a collective problem that affects
the entire Internet. Of course, it can sometimes be difficult to
motivate members of the Internet community to work collectively
towards such a goal, sharing the labor, time, and costs related to
such an effort. However, World IPv6 Day [W6D] shows that such
community efforts are possible and despite any potential challenges,
the Internet community continues to work together in order to solve
end user IPv6 impairments.
One potential tactic may be to identify which users have such
impairments and then to communicate this information to affected
users. Such end user communication is likely to be most helpful if
the end user is not only alerted to a potential problem but is given
careful and detailed advice on how to resolve this on their own, or
is guided to where they can seek help in doing so. Another potential
tactic is for a domain to collect, track over time, and periodically
share with the Internet community the rate of impairment observed for
a domain. In any such end user IPv6-related analysis and
communication, Section 6.2 is worth taking into account.
However, while these tactics can help reduce IPv6-related impairments
Section 2.1, they do not address either operational maturity concerns
noted in Section 2.2 or volume-based concerns noted in Section 2.3,
which should be considered and addressed separately.
4.2. Use IPv6 Transition Names
Another potential transition technique is for a domain to gain
experience using a special Fully-Qualified Domain Name (FQDN). This
has become typical for domains beginning the transition to IPv6,
whereby a name such as ipv6.example.com or www.ipv6.example.com is
used. An end user would have to know to use this special transition
name; it is not the same name used for regular traffic.
This special transition name directs traffic to a host or hosts which
have been enabled for native IPv6 access. In some cases this name
may point to hosts which are separate from those used for IPv4
traffic (via www.example.com), while in other cases it may point to
the same hosts used for IPv4 traffic. A subsequent phase, if
separate hosts are used to support special transition names, is to
move to the same hosts used for regular traffic in order to utilize
and exercise production infrastructure more fully. Regardless of
whether or not dedicated hosts are used, the use of the special name
is a way to incrementally control traffic as a tool for a domain to
gain IPv6 experience and increase IPv6 use on a relatively controlled
basis. Any lessons learned can then inform plans for a full
transition to IPv6. This also provides an opportunity for a domain
to develop any necessary training for staff, to develop IPv6-related
testing procedures for their production network and lab, to deploy
IPv6 functionality into their production network, and to develop and
deploy IPv6-related network and service monitors. It is also an
opportunity to add a relatively small amount of IPv6 traffic to
ensure that network gear, network interconnects, and IPv6 routing in
general is working as expected.
While using a special transition name is a good initial step to
functionally test and prepare a domain for IPv6, including developing
and maturing IPv6 operations, as noted in Section 2.2, the utility of
the tactic is limited since users must know the transition name, the
traffic volume will be low, and the traffic is unlikely to be
representative of the general population of end users (they are
likely to be self-selecting early adopters and more technically
advanced than average), among other reasons. As a result, any
concerns and risks related to traffic volume as noted Section 2.3
should still be considered and addressed separately.
4.3. Implement DNS Resolver Whitelisting
Another potential technique, especially when a high traffic domain is
ready to move beyond an IPv6 transition name, as described in
Section 4.2, is to selectively return AAAA resource records (RRs),
which contain IPv6 addresses. This selective response of DNS records
is performed by an authoritative DNS servers for a domain in response
to DNS queries sent by DNS recursive resolvers [RFC1035]. This is
commonly referred to in the Internet community as "DNS Resolver
Whitelisting", and will be referred to as such hereafter, though in
essence it is simply a technique enabling the selective return of DNS
records based upon various technical factors. An end user is seeking
a resource by name, and this selective response mechanism enables
what is perceived to be the most reliable and best performing IP
address family to be used (IPv4 or IPv6). As a technique, it shares
similarities with Content Delivery Networks, Global Server Load
Balancing, DNS Load Balancing, and Split DNS, as described below in
Section 4.3.2, Section 4.3.3, Section 4.3.4. A few high-traffic
domains have either implemented DNS Resolver Whitelisting (one of
many transition techniques they have used or are using) or are
considering doing so [NW-Article-DNS-WL] [WL-Ops].
This is a transition technique used by domains as a method for
incrementally transitioning inbound traffic to a domain to IPv6. If
an incremental technique like this is not users, a domain might
return AAAA resource records to any relevant DNS query, meaning the
domain could go quickly from no IPv6 traffic to potentially a
significant amount as soon as the AAAA resource records are
published. When DNS Resolver Whitelisting is implemented, a domain's
authoritative DNS will selectively return a AAAA resource record to
DNS recursive resolvers on a whitelist maintained by the domain,
while returning no AAAA resource records to DNS recursive resolvers
which are not on that whitelist. This tactic will not have a direct
impact on reducing IPv6-related impairments Section 2.1, though it
can help a domain address operational maturity concerns Section 2.2
and concerns and risks related to traffic volume Section 2.3.
There are of course challenges and concerns relating to DNS Resolver
Whitelisting. Some of the concerns with a whitelist of DNS recursive
resolvers may be held by parties other than the implementing domain,
such as network operators or end users that may not have had their
DNS recursive resolvers added to a whitelist. Additionally, the IP
address of a DNS recursive resolver is not a precise indicator of the
IPv6 preparedness, or lack of IPv6-related impairment, of end user
hosts which query (use) a particular DNS recursive resolver. While
the IP addresses of DNS recursive resolvers on networks known to have
deployed IPv6 may be an imperfect proxy for judging IPv6
preparedness, or lack of IPv6-related impairment, it is one of the
better available methods at the current time. In addition, given the
current state of global IPv6 deployment, this transition tactic
allows content providers to selectively expose the availability of
their IPv6 services. While opinions in the Internet community
concerning DNS Resolver Whitelisting are understandably quite varied,
there is clear consensus that DNS Resolver Whitelisting can be a
useful tactic a domain may choose to use as they transition their
services to IPv6. In particular, some high-traffic domains view DNS
Resolver Whitelisting as one of the few practical and low-risk
approaches enabling them to transition to IPv6, without which their
transition may not take place for some time. However, there is also
consensus that this practice is workable on a manual basis (see
below) only in the short-term and that it will not scale over the
long-term. Thus, some domains may find DNS Resolver Whitelisting a
beneficial temporary tactic in their transition to IPv6.
At the current time, generally speaking, a domain that implements DNS
Resolver Whitelisting does so manually. This means that a 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, or follow some other process
established by the domain, in order to be added to the DNS Whitelist.
However, implementers foresee that a subsequent phase of DNS Resolver
Whitelisting is likely to 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 indeed as part of) global server load balancing, a
common practice already in use today, as described in Section 4.3.2.
Furthermore, in this future phase, networks would be added to and
removed from a DNS Whitelist automatically, and possibly on a near-
real-time basis. This means, crucially, that networks would no
longer need to apply to be added to a whitelist, which may alleviate
many of the key concerns that network operators may have with this
technique when it is implemented on a manual basis.
4.3.1. How DNS Resolver Whitelisting Works
Using a "whitelist" in a generic sense means that no traffic (or
traffic of a certain type) is permitted to the destination host
unless the originating host's IP address is contained in the
whitelist. In contrast, using a "blacklist" means that all traffic
is permitted to the destination host unless the originating host's IP
address is contained in the blacklist. In the case of DNS Resolver
Whitelisting, the resource that an end user seeks is a name, not an
IP address or IP address family. Thus, an end user is seeking a name
such as www.example.com, without regard to the underlying IP address
family (IPv4 or IPv6) which may be used to access that resource.
DNS Resolver Whitelisting is implemented in authoritative DNS
servers, not in DNS recursive resolvers. These authoritative DNS
servers selectively return AAAA resource records using the IP address
of the DNS recursive resolver that has sent it a query. Thus, for a
given operator of a website, such as www.example.com, the domain
operator implements whitelisting on the authoritative DNS servers for
the domain example.com. The whitelist is populated with the IPv4
and/or IPv6 addresses or prefix ranges of DNS recursive resolvers on and/or IPv6 addresses or prefix ranges of DNS recursive resolvers on
the Internet, which have been authorized to receive (or access) AAAA the Internet, which have been authorized to receive AAAA resource
resource record responses. These DNS recursive resolvers are record responses. These DNS recursive resolvers are operated by
operated by third parties, such as Internet Service Providers (ISPs), third parties, such as Internet Service Providers (ISPs),
universities, governments, businesses, and individual end users. If universities, governments, businesses, and individual end users. If
a DNS recursive resolver IS NOT matched in the ACL, then AAAA 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 resource records WILL NOT be sent in response to a query for a
hostname in the example.com domain. However, if a DNS recursive hostname in the example.com domain (and an A record would be sent).
resolver IS matched in the ACL, then AAAA resource records WILL be However, if a DNS recursive resolver IS matched in the whitelist,
sent in response to a query for a given hostname in the example.com then AAAA resource records WILL be sent. As a result, while Section
domain. While these are not network-layer access controls (as many 2.2 of [RFC4213] notes that a stub resolver can make a choice between
ACLs are) they are nonetheless access controls that are a factor for whether to use a AAAA record or A record response, with DNS Resolver
end users and other organizations such as network operators, Whitelisting the authoritative DNS server can also decide whether to
especially as networks and hosts transition from one network address return a AAAA record, an A record, or both record types.
family to another (IPv4 to IPv6). Thus, if a DNS recursive resolver
is on the ACL (whitelist) then they have access to AAAA resource
records for the domain.
In practice, DNS Whitelisting generally means that a very small When implemented on a manual basis, DNS Resolver Whitelisting
fraction of the DNS recursive resolvers on the Internet (those in the generally means that a very small fraction of the DNS recursive
whitelist or ACL) will receive AAAA responses. The large majority of resolvers on the Internet (those in the whitelist) will receive AAAA
DNS recursive resolvers on the Internet will therefore receive only A responses. The large majority of DNS recursive resolvers on the
resource records containing IPv4 addresses. Thus, quite simply, the Internet will therefore receive only A resource records containing
authoritative server hands out different answers depending upon who IPv4 addresses. When implemented manually, domains may find the
is asking; with IPv4 and IPv6 resource records for all those the practice imposes some incremental operational burdens insofar as it
authorized whitelist, and only IPv4 resource records for everyone can consume staff time to maintain a whitelist (such as additions and
else. See Section 2.1 and Figure 1 for more details. 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. In addition,
manually-based whitelisting imposes some incremental burdens on
operators of DNS recursive resolvers (such as network operators),
since they will need to apply to be whitelisted with any implementing
domains, and will subsequently need processes and systems to track
the status of whitelisting applications, respond to requests for
additional information pertaining to these applications, and track
any de-whitelisting actions.
DNS Whitelisting also works independently of whether an authoritative When implemented on an automated basis in the future, DNS recursive
DNS server, DNS recursive resolver, or end user host uses IPv4 resolvers listed in the whitelist could expand and contract
transport, IPv6, or both. So, for example, whitelisting may prevent dynamically, and possibly in near-real-time, based on a wide range of
sending AAAA responses even in those cases where the DNS recursive factors. As a result, it is likely that the number of DNS recursive
resolver has queried the authoritative server over IPv6 transport, or resolvers on the whitelist will be substantially larger than when
where the end user host's original query to the DNS recursive such a list is maintained manually, and it is likely the the
resolver was over IPv6 transport. One important reason for this is whitelist will grow at a rapid rate. This automation can eliminate
that even though the DNS recursive resolver may have no IPv6-related most of the significant incremental operational burdens on both
impairments, this is not a reliable predictor of whether the same is implementing domains as well as operators of DNS recursive resolvers,
true of the end user host. This also means that a DNS whitelist can which is clearly a factor that is motivating implementers to work to
contain both IPv4 and IPv6 addresses. automate this function.
Finally, DNS Whitelisting could possibly be deployed in two ways: Section 4.3.1.1 and Figure 1 have more details on DNS Resolver
universally on a global basis (though that would be considered Whitelisting generally. In addition, the potential deployment models
harmful and is just covered to explain why this is the case), or, of DNS Resolver Whitelisting (manual and automated) are described in
more realistically, on an ad hoc basis. Deployment on a universal Section 5. It is also important to note that DNS Resolver
deployment basis means that DNS Whitelisting is implemented on all Whitelisting also works independently of whether an authoritative DNS
authoritative DNS servers, across the entire Internet. In contrast, server, DNS recursive resolver, or end user host uses IPv4 transport,
deployment on an ad hoc basis means that only some authoritative DNS IPv6, or both. So, for example, whitelisting may not result in the
servers, and perhaps even only a few, implement DNS Whitelisting. return of AAAA responses even in those cases where the DNS recursive
These two potential deployment models are described in Section 5. resolver has queried the authoritative server over IPv6 transport.
This may also be the case 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 for this 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 Specific implementations will vary from domain to domain, based on a
range of factors such as the technical capabilities of a given range of factors such as the technical capabilities of a given
domain. As such, any examples listed herein should be considered domain. As such, any examples listed herein should be considered
general examples and are not intended to be exhaustive. general examples and are not intended to be exhaustive.
2.1. Description of the Operation of DNS Whitelisting The system logic of DNS Resolver Whitelisting is as follows:
The system logic of DNS Whitelisting is as follows:
1. The authoritative DNS server for example.com receives DNS queries 1. The authoritative DNS server for example.com receives DNS queries
for the A (IPv4) and/or AAAA (IPv6) address resource records for for the A (IPv4) and/or AAAA (IPv6) address resource records for
the Fully Qualified Domain Name (FQDN) www.example.com, for which the Fully Qualified Domain Name (FQDN) www.example.com, for which
AAAA (IPv6) resource records exist. AAAA (IPv6) resource records exist.
2. The authoritative DNS server checks the IP address (IPv4, IPv6, 2. The authoritative DNS server checks the IP address (IPv4, IPv6,
or both) of the DNS recursive resolver sending the AAAA (IPv6) or both) of the DNS recursive resolver sending the AAAA (IPv6)
query against the access control list (ACL) that is the DNS query against the whitelist that is the DNS Whitelist.
Whitelist.
3. If the DNS recursive resolver's IP address IS matched in the ACL, 3. If the DNS recursive resolver's IP address IS matched in the
then the response to that specific DNS recursive resolver can whitelist, then the response to that specific DNS recursive
contain AAAA (IPv6) address resource records. resolver can contain AAAA (IPv6) address resource records.
4. If the DNS recursive resolver's IP address IS NOT matched in the 4. If the DNS recursive resolver's IP address IS NOT matched in the
ACL, then the response to that specific DNS recursive resolver whitelist, then the response to that specific DNS recursive
cannot contain AAAA (IPv6) address resource records. In this resolver cannot contain AAAA (IPv6) address resource records. In
case, the server will likely return a response with the response this case, the server will likely return a response with the
code (RCODE) being set to 0 (No Error) with an empty answer response code (RCODE) being set to 0 (No Error) with an empty
section for the AAAA record query. answer section for the AAAA record query.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Caching Server 1 - IS NOT ON the DNS Whitelist | | Caching Server 1 - IS NOT ON the DNS Whitelist |
| Caching Server 2 - IS ON the DNS Whitelist | | Caching Server 2 - IS ON the DNS Whitelist |
| Note: Transport between each host can be IPv4 or IPv6. | | Note: Transport between each host can be IPv4 or IPv6. |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
+----------+ +---------------+ +---------------+ +----------+ +---------------+ +---------------+
| Stub | | DNS Caching | | DNS | | Stub | | DNS Caching | | DNS |
| Resolver | | Server 1 | | Server | | Resolver | | Server 1 | | Server |
+----------+ +---------------+ +---------------+ +----------+ +---------------+ +---------------+
skipping to change at page 8, line 52 skipping to change at page 13, line 52
| | | | | |
| | | IS on Whitelist | | | IS on Whitelist
| | DNS Response: | | | DNS Response: |
| | example.com A, AAAA | | | example.com A, AAAA |
| |<------------------------| | |<------------------------|
| | | | | |
| DNS Response: | | | DNS Response: | |
| example.com A, AAAA | | | example.com A, AAAA | |
|<----------------------| | |<----------------------| |
Figure 1: DNS Whitelisting Diagram Figure 1: DNS Resolver Whitelisting Diagram
2.2. Comparison with Blacklisting
With DNS Whitelisting, DNS recursive resolvers can receive AAAA
resource records only if they are on the whitelist. In contrast,
blacklisting would be the opposite whereby all DNS recursive
resolvers can receive AAAA resource records unless they are on the
blacklist. So a whitelist contains a list of hosts allowed
something, whereby a blacklist contains a list of hosts disallowed
something. While the distinction between the concepts of
whitelisting and blacklisting is important, this is noted
specifically since some implementers of DNS Whitelisting may choose
to transition to DNS Blacklisting before returning to a state without
address-family-related ACLs in their authoritative DNS servers. It
is unclear when and if it would be appropriate to change from
whitelisting to blacklisting. Nor is it clear how implementers will
judge the network conditions to have changed sufficiently to justify
disabling such controls.
3. Similarities to Other DNS Operations
Some aspects of DNS Whitelisting may be considered similar to other
common DNS operational techniques which are explored below.
3.1. Similarities to Split DNS
DNS Whitelisting has some similarities to so-called split DNS,
briefly described in Section 3.8 of [RFC2775]. When split DNS is
used, the authoritative DNS server returns different responses
depending upon what host has sent the query. While [RFC2775] notes
the typical use of split DNS is to provide one answer to hosts on an
Intranet and a different answer to hosts on the Internet, the essence
is that different answers are provided to hosts on different
networks. This is basically the way that DNS Whitelisting works,
whereby hosts on different networks which use different DNS recursive
resolvers, receive different answers if one DNS recursive resolver is
on the whitelist and the other is not.
In [RFC2956], Internet transparency and Internet fragmentation
concerns regarding split DNS are detailed in Section 2.1. [RFC2956]
further notes in Section 2.7, concerns regarding split DNS and that
it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint
identifiers more complex." Section 3.5 of [RFC2956] further
recommends that maintaining a stable approach to DNS operations is
key during transitions such as the one to IPv6 that is underway now,
stating 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."
3.2. Similarities to DNS Load Balancing
DNS Whitelisting also has some similarities to DNS load balancing.
There are of course many ways that DNS load balancing can be
performed. In one example, multiple IP address resource records (A
and/or AAAA) can be added to the DNS for a given FQDN. This approach
is referred to as DNS round robin [RFC1794]. DNS round robin may
also be employed where SRV resource records are used [RFC2782].
In another example, one or more of the IP address resource records in 4.3.2. Similarities to Content Delivery Networks and Global Server Load
the DNS will direct traffic to a load balancer. That load balancer, Balancing
in turn, may be application-aware, and pass the traffic on to one or
more hosts connected to the load balancer which 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 passing through the load
balancer first.
Additionally, a geographically-aware authoritative DNS server may be DNS Resolver Whitelisting is functionally similar to Content Delivery
used, as is common with Content Delivery Networks (CDNs) or Global Networks (CDNs) and Global Server Load Balancing (GSLB). When using
Load Balancing (GLB, also referred to as Global Server Load a CDN or GSLB, a geographically-aware authoritative DNS server
Balancing, or GSLB), whereby the IP address resource records returned function is usually part of that overall system. As a result, the
to a resolver in response to a query will vary based on the estimated use of a CDN or GSLB with an authoritative DNS server function
geographic location of the resolver [Wild-Resolvers]. CDNs perform enables the IP address resource records returned to a resolver in
this function in order to attempt to direct hosts to connect to the response to a query to vary based on the estimated geographic
nearest content cache. As a result, one can see some similarities location of the resolver [Wild-Resolvers] or a range of other
with DNS Whitelisting insofar as different IP address resource technical factors. This CDN or GSLB DNS function is performed in
order to attempt to direct hosts to connect to the nearest hosts (as
measured in round trip time), to the host that has the best
connectivity to an end user, to route around failures, to avoid sites
where maintenance work has taken down hosts, and/or to the host that
will otherwise provide the best service experience for an end user at
a given point in time. As a result, one can see a direct similarity
to DNS Resolver Whitelisting insofar as different IP address resource
records are selectively returned to resolvers based on the IP address records are selectively returned to resolvers based on the IP address
of each resolver (or other imputed factors related to that IP of each resolver and/or other imputed factors related to that IP
address). However, what is different is that in this case the address.
resolvers are not deliberately blocked from receiving DNS responses
containing an entire class of addresses; this load balancing function
strives to perform a content location-improvement function and not an
access control function.
4. What Problems Are Implementers Trying To Solve?
Implementers are attempting to protect users of their domain from
having a negative experience (poor performance) when they receive DNS
response containing AAAA resource records or when attempting to use
IPv6 transport. There are two concerns which relate to this
practice; one of which relates to IPv6-related impairment and the
other which relates to the maturity or stability of IPv6 transport
for high-traffic domains. Both can negatively affect the experience
of end users.
Not all domains may face these challenges, though some clearly do,
since the user base of each domain, traffic sources, traffic volumes,
and other factors obviously varies between domains. For example,
while some domains have implemented DNS Whitelisting, others have run
IPv6 experiments whereby they added AAAA resource records and
observed and measured errors, and then decided not to implement DNS
Whitelisting [Heise]. A more widespread such experiment was World
IPv6 Day [W6D], sponsored by the Internet Society, on June 8, 2011.
This was a unique opportunity for hundreds of domains to add AAAA
resource records to the DNS without using DNS Whitelisting, all at
the same time. Domains can run their own independent experiments in
the future, adding AAAA resource records for a period of time, and
then analyzing any impacts or effects on traffic and the experience
of end users.
4.1. Volume-Based Concerns
Some implementers are trying to gradually add IPv6 traffic to their
domain since they may find that network operations, tools, processes
and procedures are less mature for IPv6 as compared to IPv4.
Compared to domains with small to moderate traffic volumes, whether
by the count of end users or count of bytes transferred, high-traffic
domains receive such a level of usage that it is prudent to undertake
any network changes gradually or in a manner which minimizes any risk
of disruption.
For example, one can imagine for one of the top ten sites globally
that the idea of suddenly turning on a significant amount of IPv6
traffic is quite daunting. DNS Whitelisting may therefore offer such
high-traffic domains one potential method for incrementally enabling
IPv6. Thus, some implementers with high-traffic domains plan to use
DNS Whitelisting as a necessary, though temporary, risk reduction
tactic intended to ease their transition to IPv6 and minimize any
perceived risk in such a transition.
4.2. IPv6-Related Impairment
Some implementers have observed that when they added AAAA resource
records to their authoritative DNS servers in order to support IPv6
access to their content that a small fraction of end users had slow
or otherwise impaired access to a given web site with both AAAA and A
resource records. The fraction of users with such impaired access
has been estimated to be as high as 0.078% of total Internet users
[IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness],
though more recent measurements indicate this is declining
[Impairment-Tracker]. In these situations, DNS recursive resolvers
are added to the DNS Whitelist only when the measured level of
impairment of the hosts using that resolver declines to some level
acceptable by the domain.
It is not clear if the level of IPv4-related impairment is more or
less that IPv6-related impairment. As one document reviewer has
pointed out, it may simply be that websites are only measuring IPv6
impairments and not IPv4 impairments, whether because IPv6 is new or
whether those websites are simply unable to or are otherwise not in a
position to be able to measure IPv4 impairment (since this could
result in no Internet access whatsoever).
As a result of this impairment affecting end users of a given domain,
a few high-traffic domains have either implemented DNS Whitelisting
or are considering doing so [NW-Article-DNS-WL] [WL-Ops]. While it
is outside the scope of this document to explore the various reasons
why a particular user's system (host) may have impaired IPv6 access,
for the users who experience this impairment it has a very real
performance impact. It would affect access to all or most dual stack
services to which the user attempts to connect. This negative end
user experience can range from somewhat slower than usual access (as
compared to native IPv4-based access), to extremely slow access, to
no access to the domain whatsoever. In essence, whether the end user
even has an IPv6 address or not, merely by receiving a AAAA record
response the user either cannot access a FQDN or it is so slow that
the user gives up and assumes the destination is unreachable.
In addition, at least one high-traffic domain has noted that they
have received requests to not send DNS responses with AAAA resource
records to particular DNS recursive resolvers. In this case, a DNS
recursive resolver operator expressed a short-term concern that their
IPv6 network infrastructure was not yet ready to handle the large
traffic volume that may be associated with the hosts in their network
connecting to the websites of these domains. These end user networks
may also have other tools at their disposal in order to address this
concern, including applying rules to network equipment such as
routers and firewalls (this will necessarily vary by the type of
network, as well as the technologies used and the design of a given
network), as well as configuration of their DNS recursive resolvers
(though modifying or suppressing AAAA resource records in a DNSSEC-
signed domain on a Security-Aware Resolver will be problematic
Section 9.1).
It is worth noting that the IP address of a DNS recursive resolver is
not a precise indicator of the IPv6 preparedness, or lack of IPv6-
related impairment, of end user hosts which query (use) a particular
DNS recursive resolver. While the DNS recursive resolver may be an
imperfect proxy for judging IPv6 preparedness, it is at least one of
the best available methods at the current time.
4.3. Free Versus Subscription Services
It is also worth noting the differences between domains containing
primarily subscription-based services compared to those containing
primarily free services. In the case of free services, such as
search engines, end users have no direct billing relationship with
the domain and can switch sites simply by changing the address they
enter into their browser (ignoring other value added services which
may tie a user's preference to a given domain or otherwise create
switching costs). As a result, such domains may be more sensitive to
IPv6 transition issues since their users can quickly switch to
another domain that is not using IPv6.
5. General Implementation Variations
In considering how DNS Whitelisting may emerge more widely, there are
two deployment scenarios explored below, one of which, the ad-hoc
case Section 5.2, is realistic and is happening now. The other,
universal deployment Section 5.1, is only described for the sake of
completeness, to highlight its difficulties, and to explain why it
would be considered harmful. Other possible alternative or
supplementary approaches are also outlined.
In evaluating implementing DNS Whitelisting universally and on an ad
hoc basis, it is possible that reputable third parties could create
and maintain DNS whitelists, in much the same way that blacklists are
distributed and used for reducing email spam. In the email context,
a mail operator subscribes to one or more of these lists and as such
the operational processes for additions and deletions to the list are
managed by a third party. A similar model could emerge for DNS
Whitelisting.
In either of those scenarios a DNS recursive resolver operator will
have to determine whether or not DNS Whitelisting has been
implemented for a domain, since the absence of AAAA resource records
may simply be indicative that the domain has not yet added IPv6
addressing for the domain, rather than that they have done so but are
using DNS Whitelisting. This will be challenging at scale.
5.1. Implement DNS Whitelisting Universally
One approach is to implement DNS Whitelisting universally, which
could also involve using some sort of centralized registry of DNS
Whitelisting policies, contracts, processes, or other information.
For this deployment scenario to occur, DNS Whitelisting functionality
would need to be built into all authoritative DNS server software,
and all operators of authoritative DNS servers would have to upgrade
their software in order to enable this functionality. New IETF
Request for Comment (RFC) documents may need to be completed to
describe how to properly configure, deploy, and maintain DNS
Whitelisting across the entire Internet. As a result, it is highly
unlikely that DNS Whitelisting will become universally deployed.
Such an approach is considered harmful and problematic, and almost
certain not to happen.
5.2. Implement DNS Whitelisting On An Ad Hoc Basis
DNS Whitelisting is now being adopted on an ad hoc, or domain-by-
domain basis. Therefore, only those domains interested in DNS
Whitelisting would need to adopt the practice. Also in this
scenario, ad hoc use by a particular domain is likely to be a
temporary measure that has been adopted to ease the transition of the
domain to IPv6. A domain, particularly a high-traffic domain, may
choose to do so in order to ease their transition to IPv6 through a
selective deployment so as to minimize any risks or disruptions in
such a transition.
One benefit of DNS Whitelisting being deployed on an ad hoc basis is
that only the domains that are interested in doing so would have to
upgrade their authoritative DNS servers (or take other steps) in
order to implement DNS Whitelisting. Some domains that plan to or
already have implemented this and are manually updating their
whitelist, while others such as CDNs have discussed the possibility
of an automated method for doing so.
5.3. Do Not Implement DNS Whitelisting
As an alternative to adopting DNS Whitelisting, domains can choose
not to implement DNS Whitelisting, continuing the current predominant
authoritative DNS operational model on the Internet. It is then up
to end users with IPv6-related impairments to discover and fix those
impairments, though clearly other parties including end user host
operating system developers can play a critical role. However, the
concerns and risks related to traffic volume Section 4.1 should still
be considered since those are not directly related to such
impairments.
5.3.1. Solve Current End User IPv6 Impairments
A further extension of not implementing DNS Whitelisting, is to also
endeavor fix the underlying technical problems experienced by end
users during the transition to IPv6. A first step is to identify
which users have such impairments and then to communicate this
information to affected users. Such end user communication is likely
to be most helpful if the end user is not only alerted to a potential
problem but is given careful and detailed advice on how to resolve
this on their own, or where they can seek help in doing so.
Section 10 may also be relevant in this case.
One challenge with this option is the potential difficulty of
motivating members of the Internet community to work collectively
towards this goal, sharing the labor, time, and costs related to such
an effort. However, World IPv6 Day [W6D] shows that such community
efforts are possible and despite any potential challenges, the
Internet community continues to work to solve end user IPv6
impairments.
However, as noted above, the concerns and risks related to traffic
volume Section 4.1 should still be considered since those are not
directly related to such impairments.
5.3.2. Gain Experience Using IPv6 Transition Names
Another alternative is for domains to gain experience using an FQDN
which has become common for domains beginning the transition to IPv6;
ipv6.example.com and www.ipv6.example.com. This can be a way for a
domain to gain IPv6 experience and increase IPv6 use on a relatively
controlled basis, and to inform any plans for DNS Whitelisting with
experience.
While this is a good first step to functionally test and prepare a
domain for IPv6, the utility of the tactic is limited since users
must know the transition name, the traffic volume will be low, and
the traffic is unlikely to be representative of the general
population of end users, among other reasons. Thus, as noted above,
the concerns and risks related to traffic volume Section 4.1 should
still be considered.
5.3.3. Implement DNS Blacklisting
Some domains may wish to be more permissive than if they adopted DNS
Whitelisting, but still have some level of control over returning
AAAA record responses. In this case an alternative may be to employ
DNS Blacklisting, which would enable all DNS recursive resolvers to
receive AAAA record responses except for the relatively small number
that are listed in the blacklist. This could, for example, enable an
implementer to only prevent such responses where there has been a
relatively high level of IPv6-related impairments, until such time as
these impairments can be fixed or otherwise meaningfully reduced to
an acceptable level.
This approach is likely to be significantly less labor intensive for
an authoritative DNS server operator, as they would presumably focus
on a smaller number of DNS recursive resolvers than if they
implemented whitelisting. Thus, these authoritative DNS server
operators would only need to communicate with a few DNS recursive
resolver operators rather than potentially all such operators. This
should result in lower labor, systems, and process requirements.
This is not to say that there will be no time required to work with
those parties affected by a blacklist, simply that there are likely
to be fewer such interactions and that each such interaction could be
shorter in duration.
The email industry has a long experience with blacklists and, very
generally speaking, blacklists tend to be effective and well received
when it is easy to discover if a server is on a blacklist, if there
is a transparent and easily understood process for requesting removal
from a blacklist, and if the decision-making criteria for placing a
server on a blacklist is transparently disclosed and perceived as
fair.
As noted in Section 7.3.7, it is also possible that a domain may
choose to first implement DNS Whitelisting and then migrate to DNS
Blacklisting.
6. Concerns Regarding DNS Whitelisting
There is concern that the practice of DNS Whitelisting for IPv6
address resource records represents a departure from the generally
accepted practices regarding IPv4 address resource records in the DNS
on the Internet [WL-Concerns]. Generally, once an authoritative
server operator adds an A record (IPv4) to the DNS, then any DNS
recursive resolver on the Internet can receive that A record in
response to a query. This enables new server hosts that are
connected to the Internet, and for which a FQDN such as
www.example.com has been added to the DNS with an IPv4 address
record, to be almost immediately reachable by any host on the
Internet. Each end in this end-to-end model is responsible for
connecting to the Internet and once they have done so they can
connect to each other without additional impediments, middle
networks, intervening networks, or servers either knowing about all
end points or whether one is allowed to discover and contact the
other. The end result is that new server hosts become more and more
widely accessible as new networks and new hosts connect to the
Internet over time, capitalizing on and increasing so-called "network
effects" (also called network externalities).
In contrast, DNS Whitelisting may fundamentally change this model.
In the altered DNS Whitelisting end-to-end model, one end (where the
end user is located) cannot readily discover the other end (where the
content is located), without parts of the middle (authoritative DNS
servers) making a new type of access control decision in the DNS. So
in the current IPv4-based Internet when a new server host is added to
the Internet it is generally widely available to all end user hosts
via a FQDN. When DNS Whitelisting of IPv6 resource records is used,
these new server hosts are not accessible via a FQDN by any end user
hosts until such time as the operator of the authoritative DNS
servers adds DNS recursive resolvers around the Internet to the DNS
Whitelist.
7. Implications of DNS Whitelisting
The key DNS Whitelisting implications are detailed below.
7.1. Architectural Implications
DNS Whitelisting modifies the end-to-end model and the general notion
of spontaneous interoperability of the architecture that prevails on
the Internet today. This is because this approach moves additional
access control information and policies into the middle of the DNS
resolution path of the IPv6-addressed Internet, which generally did
not exist before on the IPv4-addressed Internet, and it requires some
type of prior registration with authoritative servers. This poses
some risks noted in [RFC3724]. In explaining the history of the end-
to-end principle, [RFC1958] states that one of the goals is to
minimize the state, policies, and other functions needed in the
middle of the network in order to enable end-to-end communications on
the Internet. In this case, the middle network should be understood
to mean anything other than the end hosts involved in communicating
with one another. Some state, policies, and other functions have
always been necessary to enable such end-to-end communication, but
the goal of the approach has been to minimize this to the greatest
extent possible.
It is also possible that DNS Whitelisting could place at risk some of
the observed benefits of the end-to-end principle, as listed in
Section 4.1 of [RFC3724], such as protection of innovation.
[RFC3234] details issues and concerns regarding so-called
middleboxes, so there may also be parallel concerns with the DNS
Whitelisting approach, especially concerning modified DNS servers
noted in Section 2.16 of [RFC3234], as well as more general concerns
noted in Section 1.2 of [RFC3234] about the introduction of new
failure modes. In particular, there may be concerns that
configuration is no longer limited to two ends of a session, and that
diagnosis of failures and misconfigurations becomes more complex.
Two additional sources worth considering as far as implications for
the end-to-end model are concerned are [Tussle] and [Rethinking]. In
[Tussle], the authors note concerns regarding the introduction of new
control points, as well as "kludges" to the DNS, as risks to the goal
of network transparency in the end-to-end model. Given the emerging
use of DNS Whitelisting [Tussle] is an interesting and relevant
document. In addition, [Rethinking] reviews similar issues that are
of interest to readers of this document.
Also, it is somewhat possible that DNS Whitelisting could affect some
of the architectural assumptions which underlie parts of Section 2 of
[RFC4213] which outlines the dual stack approach to the IPv6
transition. DNS Whitelisting could modify the behavior of the DNS,
as described in Section 2.2 of [RFC4213] and could require different
sets of DNS servers to be used for hosts that are (using terms from
that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes.
As such, broad use of DNS Whitelisting may necessitate the review
and/or revision (though revision is unlikely to be necessary) of
standards documents which describe dual-stack and IPv6 operating
modes, dual-stack architecture generally, and IPv6 transition
methods, including but not limited to [RFC4213].
7.2. Public IPv6 Address Reachability Implications
It is a critical to understand that the concept of reachability
described here depends upon a knowledge of an address in the DNS.
Thus, in order to establish reachability to an end point, a host is
dependent upon looking up an IP address in the DNS when a FQDN is
used. When DNS Whitelisting is used, it is quite likely that an
IPv6-enabled end user host could connect to an example server host
using the IPv6 address, even though the FQDN associated with that
server host is restricted via a DNS whitelist. Since most Internet
applications and hosts such as web servers depend upon the DNS, and
as end users connect to FQDNs such as www.example.com and do not
remember or wish to type in an IP address, the notion of reachability
described here should be understood to include knowledge of how to
associate a name with a network address.
The predominant experience of end user hosts and servers on the IPv4-
addressed Internet today is that when a new server with a public IPv4
address is added to the DNS, that a FQDN is immediately useful for
reaching it. This is a generalization and in Section 3 there are
examples of common cases where this may not necessarily be the case.
For the purposes of this argument, that concept of accessibility is
described as "pervasive reachability". It has so far been assumed
that the same expectations of pervasive reachability would exist in
the IPv6-addressed Internet. However, if DNS Whitelisting is
deployed, this will not be the case since only end user hosts using
DNS recursive resolvers that are included in the ACL of a given
domain using DNS Whitelisting would be able to reach new servers in
that given domain via IPv6 addresses. The expectation of any end
user host being able to connect to any server (essentially both
hosts, just at either end of the network), defined here as "pervasive
reachability", will change to "restricted reachability" with IPv6.
Establishing DNS Whitelisting as an accepted practice in the early
phases of mass IPv6 deployment could establish it as an integral part
of how IPv6 DNS resource records are deployed globally. This risks
DNS Whitelisting living on for many years as a key foundational
element of domain name management on the Internet.
7.3. Operational Implications
This section explores some of the operational implications which may
occur as a result of, are related to, or become necessary when
engaging in the practice of DNS Whitelisting.
7.3.1. De-Whitelisting May Occur
It is possible for a DNS recursive resolver added to a whitelist to
then be removed from the whitelist, also known as de-whitelisting.
Since de-whitelisting can occur, through a decision by the
authoritative server operator, the domain owner, or even due to a
technical error, an operator of a DNS recursive resolver will have
new operational and monitoring requirements and/or needs as noted in
Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5. One
particular risk is that, especially when a high-traffic domain de-
whitelists a large network, this may cause a sudden and dramatic
change to networks since a large volume of traffic will then switch
from IPv6 to IPv4. This can have dramatic effects on those being de-
whitelisted as well as on other interconnected networks. In some
cases, IPv4 network links may rapidly become congested and users of
affected networks will experience network access impairments well
beyond the domain which performed the de-whitelisting. Thus, once
"operational stability" has been achieved between a whitelisting and
whitelisted party, then de-whitelisting should generally not occur
except in cases of operational emergencies, and there should be
opportunities for joint troubleshooting or at least for advance
warning to affected parties.
7.3.2. Authoritative DNS Server Operational Implications
DNS Whitelisting serves as a critical infrastructure service; to be
useful it needs careful and extensive administration, monitoring and
operation. Each new and essential mechanism creates substantial
follow-on support costs.
Operators of authoritative servers (which are frequently
authoritative for multiple domain names) will need to maintain an ACL
on a server-wide basis affecting all domains, or on a domain-by-
domain basis. As a result, operational practices and software
capabilities may need to be developed in order to support such
functionality. In addition, processes may need to be put in place to
protect against inadvertently adding or removing IP addresses, as
well as systems and/or processes to respond to such incidents if and
when they occur. For example, a system may be needed to record DNS
Whitelisting requests, report on their status along a workflow, add
IP addresses when whitelisting has been approved, remove IP addresses
when they have been de-whitelisted, log the personnel involved and
timing of changes, schedule changes to occur in the future, and to
roll back any inadvertent changes.
Operators may also need implement new forms of monitoring in order to
apply change control, as noted briefly in Section 7.3.4.
It is important for operators of authoritative servers to recognize
that the operational burden is likely to increase dramatically over
time, as more and more networks transition to IPv6. As a result, the
volume of new DNS Whitelisting requests will increase over time,
potentially at an extraordinary growth rate, which will place an
increasing burden on personnel, systems, and/or processes. Operators
should also consider that any supporting systems, including the
authoritative servers themselves, may experience reduced performance
when a DNS whitelist becomes quite large.
7.3.3. DNS Recursive Resolver Server Operational Implications
For operators of DNS recursive resolvers, coping with DNS
Whitelisting becomes expensive in time and personnel as the practice
scales up. These operators include ISPs, enterprises, universities,
governments; a wide range of organization types with a range of DNS-
related expertise. They will need to implement new forms of
monitoring, as noted briefly in Section 7.3.4. But more critically,
such operators will need to add people, processes, and systems in
order to manage large numbers of DNS Whitelisting applications.
Since there is no common method for determining whether or not a
domain is engaged in DNS Whitelisting, operators will have to apply
to be whitelisted for a domain based upon one or more end user
requests, which means systems, processes, and personnel for handling
and responding to those requests will also be necessary.
When operators apply for DNS Whitelisting for all domains, that may 4.3.3. Similarities to DNS Load Balancing
mean doing so for all registered domains. Thus, some system would
have to be developed to discover whether each domain has been
whitelisted or not, which is touched on in Section 5 and may vary
depending upon whether DNS Whitelisting is universally deployed or is
deployed on an ad hoc basis.
These operators (of DNS recursive resolvers) will need to develop DNS Resolver Whitelisting has some similarities to DNS load
processes and systems to track the status of all DNS Whitelisting balancing. There are of course many ways that DNS load balancing can
applications, respond to requests for additional information related be performed. In one example, multiple IP address resource records
to these applications, determine when and if applications have been (A and/or AAAA) can be added to the DNS for a given FQDN. This
denied, manage appeals, and track any de-whitelisting actions. approach is referred to as DNS round robin [RFC1794]. DNS round
robin may also be employed where SRV resource records are used
[RFC2782]. In another example, one or more of the IP address
resource records in the DNS will direct traffic to a load balancer.
That load balancer, in turn, may be application-aware, and pass the
traffic on to one or more hosts connected to the load balancer which
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
passing through the load balancer first. So, similar to DNS Resolver
Whitelisting, a load balancer will control what server host an end
user's host communicates with when using a FQDN.
Given the large number of domains in existence, the ease with which a 4.3.4. Similarities to Split DNS
new domain can be added, and the continued strong growth in the
numbers of new domains, readers should not underestimate the
potential significance in personnel and expense that this could
represent for such operators. In addition, it is likely that systems
and personnel may also be needed to handle new end user requests for
domains for which to apply for DNS Whitelisting, and/or inquiries
into the status of a whitelisting application, reports of de-
whitelisting incidents, general inquiries related to DNS
Whitelisting, and requests for DNS Whitelisting-related
troubleshooting by these end users.
7.3.4. Monitoring Implications DNS Resolver Whitelisting has some similarities to so-called split
DNS, briefly described in Section 3.8 of [RFC2775]. When split DNS
is used, the authoritative DNS server selectively returns different
responses depending upon what host has sent the query. While
Once a DNS recursive resolver has been whitelisted for a particular [RFC2775] notes the typical use of split DNS is to provide one answer
domain, then the operator of that DNS recursive resolver may need to to hosts on an Intranet (internal network) and a different answer to
implement monitoring in order to detect the possible loss of DNS hosts on the Internet (external or public network), the basic idea is
Whitelisting in the future. This DNS recursive resolver operator that different answers are provided to hosts on different networks.
could configure a monitor to check for a AAAA response in the This is similar to the way that DNS Resolver Whitelisting works,
whitelisted domain, as a check to validate continued status on the whereby hosts on different networks which use different DNS recursive
DNS whitelist. The monitor could then trigger an alert if at some resolvers, receive different answers if one DNS recursive resolver is
point the AAAA responses were no longer received, so that operations on the whitelist and the other is not. However, Internet
personnel could begin troubleshooting, as outlined in Section 7.3.6. transparency and Internet fragmentation concerns regarding split DNS
are detailed in Section 2.1 of [RFC2956] and Section 2.7 notes
concerns regarding split DNS and that it "makes the use of Fully
Qualified Domain Names (FQDNs) as endpoint identifiers more complex".
Section 3.5 of [RFC2956] further recommends that maintaining a stable
approach to DNS operations is key during transitions, such as the one
to IPv6 that is underway now, stating 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."
Also, authoritative DNS server operators are likely to need to 4.3.5. Related Considerations
implement new forms of monitoring. In this case, they may desire to
monitor for significant changes in the size of the whitelist within a
certain period of time, which might be indicative of a technical
error such as the entire ACL being removed. Authoritative DNS server
operators may also wish to monitor their workflow process for
reviewing and acting upon DNS Whitelisting applications and appeals,
potentially measuring and reporting on service level commitments
regarding the time an application or appeal can remain at each step
of the process, regardless of whether or not such information is
shared with parties other than that authoritative DNS server
operator.
7.3.5. Implications of Operational Momentum While techniques such as GLSB and DNS load balancing, which share
much in common with DNS Resolver Whitelisting and are widespread,
some in the community have raised a range of concerns about the
practice. Some concerns are specific DNS Resolver Whitelisting
[WL-Concerns]. Other concerns are not as specific and pertain to the
general practice of implementing content location or other network
policy controls in the "middle" of the network in a so-called
"middlebox" function. Whether such DNS-related functions are really
part of a middlebox is debatable. Nevertheless, implementers should
at least be aware of some of the risks of middleboxes, as noted in
[RFC3724]. A related document, [RFC1958] explains that the state,
policies, and other functions needed in the middle of the network
should be minimized as a design goal. In addition, Section 2.16 of
[RFC3234] makes specific statements concerning modified DNS servers.
[RFC3234] also outlines more general concerns in Section 1.2 about
the introduction of new failure modes when configuration is no longer
limited to two ends of a session, so that diagnosis of failures and
misconfigurations could become more complex. Two additional sources
worth considering are [Tussle] and [Rethinking], in which the authors
note concerns regarding the introduction of new control points (such
as in middleboxes), including in the DNS.
It seems plausible that once DNS Whitelisting is implemented it will However, some state, policies, and other functions have always been
be very difficult to deprecate such technical and operational necessary to enable effective, reliable, and high-quality end-to-end
practices. This assumption is based on an understanding of human communications on the Internet. In addition, techniques such as
nature, not to mention physics. For example, as Sir Isaac Newton Global Server Load Balancing, Content Delivery Networking, DNS Load
noted, "Every object in a state of uniform motion tends to remain in Balancing and Split DNS are not only widely deployed but are almost
that state of motion unless an external force is applied to it" uniformly viewed as essential to the functioning of the Internet and
[Motion]. Thus, once DNS Whitelisting is implemented it is quite highly beneficial to the quality of the end user experience on the
likely that it would take considerable effort to deprecate the Internet. These techniques have had and continue to have a
practice and remove it everywhere on the Internet; it may otherwise beneficial effect on the experience of a wide range of Internet
simply remain in place in perpetuity. To illustrate this point, one applications and protocols. So while there are valid concerns about
could consider for example that there are many email servers implementing policy controls in the "middle" of the network, or
continuing to attempt to query anti-spam DNS blocklists which have anywhere away from edge hosts, the definition of what constitutes the
long ago ceased to exist. middle and edge of the network is debatable in this case. This is
particularly so given that GSLBs and CDNs facilitate connections from
end host and the optimal content hosts, and could therefore be
considered a modest and in many cases essential network policy
extension of a network's edge, especially in the case of high-traffic
domains.
7.3.6. Troubleshooting Implications There may be additional implications for end users that have
configured their hosts to use a third party as their DNS recursive
resolver, rather than the one(s) provided by their network operator.
In such cases, it will be more challenging for a domain using
whitelisting to determine the level of IPv6-related impairment when
such third-party DNS recursive resolvers are used, given the wide
variety of end user access networks which may be used and that this
mix may change in unpredictable ways over time.
The implications of DNS whitelisted present many challenges, as 4.4. Implement DNS Blacklisting
detailed throughout Section 7. These challenges may negatively
affect the end users' ability to troubleshoot, as well as that of DNS
recursive resolver operators, ISPs, content providers, domain owners
(where they may be different from the operator of the authoritative
DNS server for their domain), and other third parties. This may make
the process of determining why a server is not reachable via a FQDN
significantly more complex and time-consuming.
7.3.7. Additional Implications If Deployed On An Ad Hoc Basis With DNS Resolver Whitelisting, DNS recursive resolvers can receive
AAAA resource records only if they are on the whitelist. DNS
Blacklisting is by contrast the the opposite of that, whereby all DNS
recursive resolvers can receive AAAA resource records unless they are
on the blacklist. Some implementers of DNS Resolver Whitelisting may
choose to subsequently transition to DNS Blacklisting. It is unclear
when and if it may be appropriate for a domain to change from
whitelisting to blacklisting. Nor is it clear how implementers will
judge the network conditions to have changed sufficiently to justify
disabling such controls.
As more domains choose to implement DNS Whitelisting, and more When a domain uses blacklisting, they are enabling all DNS recursive
networks become IPv6-capable and request to be whitelisted, scaling resolvers to receive AAAA record responses except for what is
up operational processes, monitoring, and ACL updates will become presumed to be a relatively small number that are on the blacklist.
more difficult. The increased rate of change and increased size of Over time it is likely that the blacklist will become smaller as the
whitelists will increase the likelihood of configuration and other networks associated with the blacklisted DNS recursive resolvers are
operational errors. able to meaningfully reduce IPv6-related impairments to some
acceptable level, though it is possible that some networks may never
achieve that. DNS Blacklisting is also likely less labor intensive
for a domain than performing DNS Resolver Whitelisting on a manual
basis. This is simply because the domain would presumably be focused
on a smaller number of DNS recursive resolvers with well known IPv6-
related problems.
It is unclear when and if it would be appropriate to change from It is also worth noting that the email industry has a long experience
whitelisting to blacklisting. It also seems unlikely for such a with blacklists and, very generally speaking, blacklists tend to be
change from whitelisting to blacklisting to be coordinated across the effective and well received when it is easy to discover if an IP
Internet, so such a change to blacklisting will likely occur on an address is on a blacklist, if there is a transparent and easily
ad-hoc basis as well (if at all). understood process for requesting removal from a blacklist, and if
the decision-making criteria for placing a server on a blacklist is
transparently disclosed and perceived as fair. However, in contrast
to an email blacklist where a blacklisted host cannot send email to a
domain at all, with DNS Resolver Whitelisting communications will
still occur over IPv4 transport.
Finally, some implementers consider DNS Whitelisting to be a 4.5. Transition Directly to Native Dual Stack
temporary measure. As such, it is not clear how these implementers
will judge the network conditions to have changed sufficiently to
justify disabling DNS Whitelisting (or blacklisting, or other AAAA
resource record access controls) and/or what the process and timing
will be in order to discontinue this practice.
7.4. Homogeneity May Be Encouraged As an alternative to adopting any of the aforementioned transition
techniques, domains can choose to transition to native dual stack
directly by adding native IPv6 capabilities to their network and
hosts and by publishing AAAA resource records in the DNS for named
resources within their domain. Of course, a domain can still control
this transition gradually, on a name-by-name basis, by adding native
IPv6 to one name at a time, such as mail.example.com first and
www.example.com later. So even a "direct" transition can be
performed gradually.
A broad trend on the Internet is a move toward more heterogeneity. It is then up to end users with IPv6-related impairments to discover
One manifestation of this is in an increasing number, variety, and and fix any applicable impairments. However, the concerns and risks
customization of end user hosts, including home networks, operating related to traffic volume Section 2.3 should still be considered and
systems, client software, home network devices, and personal managed, since those are not directly related to such impairments.
computing devices. This trend appears to have had a positive effect Not all content providers (or other domains) may face the challenges
on the development and growth of the Internet and has enabled end detailed herein or face them to the same degree, since the user base
users to connect any technically compliant device or use any of each domain, traffic sources, traffic volumes, and other factors
technically compatible software to connect to the Internet. Not only obviously varies between domains.
does this trend towards greater heterogeneity reduce the control
which is exerted in the middle of the network, described positively
in [Tussle], [Rethinking], and [RFC3724], but it also appears to help
to enable greater and more rapid innovation at the edge of the
network.
Some forms of so-called "network neutrality" principles around the For example, while some content providers have implemented DNS
world include the notion that any IP-capable device should be able to Resolver Whitelisting (one transition technique), others have run
connect to a network, encouraging heterogeneity. These principles IPv6 experiments whereby they added AAAA resource records and
are often explicitly encouraged by application providers, though some observed and measured errors, and then decided not to implement DNS
of these same providers may be using DNS Whitelisting. This is Resolver Whitelisting [Heise]. A more widespread such experiment was
ironic, as one implication of the adoption of DNS Whitelisting is World IPv6 Day [W6D], sponsored by the Internet Society, on June 8,
that it could encourage a move back towards homogeneity resulting 2011. This was a unique opportunity for hundreds of domains to add
from greater control over devices in order to attempt to enforce AAAA resource records to the DNS without using DNS Resolver
technical requirements intended to reduce IPv6-related impairments. Whitelisting, all at the same time. Some of the participating
This return to an environment of more homogenous and/or controlled domains chose to leave AAAA resource records in place following the
end user hosts could have unintended side effects on and counter- experiment based on their experiences.
productive implications for future innovation at the edge of the
network.
7.5. Technology Policy Implications Content providers can run their own independent experiments in the
future, adding AAAA resource records for a brief period of time
(minutes, hours, or days), and then analyzing any impacts or effects
on traffic and the experience of end users. They can also simply
turn on IPv6 for their domain, which may be easier when the
transition does not involve a high-traffic domain.
A key technology policy implication concerns the policies and 5. Potential Implementation Phases
processes related to reviewing and making decisions on DNS
Whitelisting applications for a domain, as well as making any
possible de-whitelisting decisons. Important questions may include
whether these policies have been fully and transparently disclosed,
are non-discriminatory, and are not anti-competitive. Key questions
here may include whether appeals are allowed, what the process is,
what the expected turn around time is, and whether the appeal will be
handled by an independent third party.
It is also conceivable that whitelisting and de-whitelisting These usefulness of each technique in Section 4, and the associated
decisions could be quite sensitive to concerned parties beyond the pros and cons associated with each technique, is relative to each
operator of the domain operator and the operator of the DNS recursive potential implementer and will therefore vary from one implementer to
resolver, including end users, application developers, content another. As a result, it is not possible to say that the potential
providers, advertisers, public policy groups, governments, and other phases below make sense for every implementer. This also means that
entities. These concerned parties may seek to become involved in or the duration of each phase will vary between implementers, and even
express opinions concerning whitelisting and/or de-whitelisting that different implementers may skip some of these phases entirely.
decisions. Finally, the techniques listed in Section 4 are by no means
exclusive.
A final concern is that decisions relating to whitelisting and de- 5.1. No Access to IPv6 Content
whitelisting may occur as an expression of other commercial,
governmental, and/or cultural conflicts, given the new control point
which has been established with DNS Whitelisting. For example, in
one imagined scenario, a domain could withhold adding a network to
their DNS Whitelisting unless that network agreed to some sort of
financial payment, legal agreement, agreement to sever a relationship
with a competitor of the domain, etc. In another example, a music-
oriented domain may be engaged in some sort of dispute with an
academic network concerning copyright infringement concerns within
that network, and may choose to de-whitelist that network as a
negotiating technique in some sort of commercial discussion. In a
final example, a major email domain may choose to de-whitelist a
network due to that network sending some large volume of spam. Thus,
it seems possible that whitelisting and de-whitelisting could become
a vehicle for adjudicating other disputes, and that this may well
have consequences for end users which are affected by such decisions
and are unable to express a strong voice in such decisions.
7.6. IPv6 Adoption Implications In this phase, a site is accessible only via IPv4 transport. As of
the time of this document, the majority of content on the Internet is
in this state and is not accessible natively over IPv6.
As noted in Section 6, the implications of DNS Whitelisting may drive 5.2. Using IPv6 Transition Names
end users and/or networks to delay, postpone, or cancel adoption of
IPv6, or to actively seek alternatives to it. Such alternatives may
include the use of multi-layer or large scale network address
translation (NAT) techniques, which these parties may decide to
pursue on a long-term basis to avoid the perceived costs and
aggravations related to DNS Whitelisting. This could of course come
at the very time that the Internet community is trying to get these
very same parties interested in IPv6 and motivated to begin the
transition to IPv6. As a result, parties that are likely to be
concerned over the negative implications of DNS Whitelisting could
logically be concerned of the negative effects that this practice
could have on the adoption of IPv6 if it became widespread.
At the same time, as noted in Section 4, some high-traffic domains One possible first step for a domain is to gain experience using a
may find the prospect of transitioning to IPv6 daunting without specialized new FQDN, such as ipv6.example.com or
having some short-term ability to incrementally control the amount www.ipv6.example.com, as explained in Section 4.2.
and source of IPv6 traffic to their domains. Lacking such controls,
some domains may choose to substantially delay their transition to
IPv6.
7.7. Implications with Poor IPv4 and Good IPv6 Transport 5.3. Deploying DNS Resolver Whitelisting Using Manual Processes
It is possible that there could be situations where the differing As noted in Section 4.3, a domain could begin using DNS Resolver
quality of the IPv4 and IPv6 connectivity of an end user could cause Whitelisting as a way to incrementally enable IPv6 access to content.
complications in accessing content which is in a whitelisted domain, This tactic may be especially interesting to high-traffic domains.
when the end user's DNS recursive resolver is not on that whitelist.
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 and end user has
markedly superior IPv6 connectivity as compared to IPv4. This is
admittedly theoretical but could become a factor as the transition to
IPv6 continues and IPv4 address availability within networks becomes
strained.
For example, in one possible scenario, a user is issued IPv6 5.4. Deploying DNS Resolver Whitelisting Using Automated Processes
addresses by their ISP and has a home network and devices or
operating systems which fully support IPv6. As a result this
theoretical user has very good IPv6 connectivity. However, this end
user's ISP may have exhausted their available pool of unique IPv4
address, and so that ISP uses NAT in order to reuse IPv4 addresses.
So for IPv4 content, the end user must send their IPv4 traffic
through some additional network element (e.g. NAT, proxy, tunnel
server). Use of this additional network element may cause the 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. Furthermore, this end
user's DNS recursive resolver is not whitelisted by the authoritative
server for a domain that the user is trying to access, meaning the
end user only gets A record responses for their impaired IPv4
transport rather than also AAAA record responses for their stable and
well-performing IPv6 transport. Thus, the user's poor IPv4
connectivity situation is potentially exacerbated by not having
access to a given domain's IPv6 content since they must use the
address family with relatively poor performance.
7.8. Implications for Users of Third-Party DNS Recursive Resolvers For a domain that decides to undertake DNS Resolver Whitelisting on a
manual basis, the domain may subsequently move to perform DNS
Resolver Whitelisting on an automated basis. This is explained in
Section 4.3, and can significantly ease any operational burdens
relating to a manually-maintained whitelist.
In most cases it is assumed that end users will make use of DNS 5.5. Turning Off DNS Resolver Whitelisting
recursive resolvers which are operated by their access network
provider, whether that is an ISP, campus network, enterprise network,
or some other type of network. However there are also cases where an
end user has changed their DNS server IP addresses in their device's
operating system to those of a third party which operates DNS
recursive resolvers independently of end user access networks.
In these cases, an authoritative DNS server may receive a query from Domains that choose to implement DNS Resolver Whitelisting generally
a DNS recursive resolver in one network, though the end user sending consider it to be a temporary measure. It is unclear how
the original query is in an entirely different network. It may implementers will judge when the network conditions will have changed
therefore be more challenging for a DNS Whitelist implementer to sufficiently to justify turning off DNS Resolver Whitelisting and/or
determine the level of IPv6-related impairment when such third-party what the process and timing will be for discontinuing this practice,
DNS recursive resolvers are used, given the wide variety of end user though the extent of IPv6 deployment to end users in networks, the
access networks which may be used and that this mix may change in state of IPv6-related impairment, and the maturity of IPv6 operations
unpredictable ways over time. are all clearly factors. However, implementers may wish to take into
consideration 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 as end users elect not to upgrade them or as some hosts
are incapable of being upgraded.
There may also be cases where end users' assigned DNS recursive 5.6. Deploying DNS Blacklisting
resolvers have not been whitelisted for a particular domain, but
where the end user tries to switch to a third-party DNS recursive
resolver that has been whitelisted. While in most cases the end user
will be able to switch to use that third-party's DNS servers, some
specialized access networks, such as in hotels and conference
centers, may prevent using third-party DNS servers. In these cases,
end users may be frustrated at their inability to access certain
content over IPv6, resulting in complaints to both a particular
domain as well as the access network operator.
8. Is DNS Whitelisting a Recommended Practice? 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 become interesting. This may be at the point in time
when domains wish to make their content widely available over IPv6
but still wish to protect end users of a few networks with well known
IPv6 limitations from having a bad end user experience.
Opinions in the Internet community concerning whether or not DNS 5.7. Fully Dual-Stack Content
Whitelisting is a recommended practice are understandably quite
varied. However, there is clear consensus that DNS Whitelisting can
be a useful tactic a domain may choose to use as they transition to
IPv6. In particular, some high-traffic domains view DNS Whitelisting
as one of the few practical and low-risk approaches enabling them to
transition to IPv6, without which their transition may not take place
for some time. However, there is also consensus is that this
practice is workable only in the short-term and that it will not
scale over the long-term. Thus, some domains may find DNS
Whitelisting a beneficial temporary tactic in their transition to
IPv6. Such temporary use during the transition to IPv6 is broadly
accepted within the community, so long as it does not become a long-
term practice.
9. Security Considerations A domain can arrive at this phase either following the use of a
previous IPv6 transition technique, or they may go directly to this
point 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
transition technique.
If DNS Whitelisting is adopted, then organizations which apply DNS 6. Other Considerations
Whitelisting policies in their authoritative servers should have
procedures and systems which do not allow unauthorized parties to
either remove whitelisted DNS recursive resolvers from the whitelist
or add non-whitelisted DNS recursive resolvers to the whitelist, just
as all configuration settings for name servers should be protected by
appropriate procedures and systems. Should such unauthorized
additions or removals from the whitelist can be quite damaging, and
result in content providers and/or ISPs to incur substantial support
costs resulting from end user and/or customer contacts. As such,
great care must be taken to control access to the whitelist for an
authoritative server.
In addition, two other key security-related issues should be taken 6.1. Security Considerations
into consideration:
9.1. DNSSEC Considerations If DNS Resolver Whitelisting is adopted, as noted in Section 4.3,
then organizations which apply DNS Resolver Whitelisting policies in
their authoritative servers should have procedures and systems which
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 can be
damaging, causing content providers and/or network operators to incur
support costs resulting from end user and/or customer contacts, as
well as causing potential dramatic and disruptive swings in traffic
from IPv6 to IPv4 or vice versa.
DNS security extensions defined in [RFC4033], [RFC4034], and DNS security extensions defined in [RFC4033], [RFC4034], and
[RFC4035] use cryptographic digital signatures to provide origin [RFC4035] use cryptographic digital signatures to provide origin
authentication and integrity assurance for DNS data. This is done by authentication and integrity assurance for DNS data. This is done by
creating signatures for DNS data on a Security-Aware Authoritative creating signatures for DNS data on a Security-Aware Authoritative
Name Server that can be used by Security-Aware Resolvers to verify Name Server that can be used by Security-Aware Resolvers to verify
the answers. Since DNS Whitelisting is implemented on an the answers. Since DNS Resolver Whitelisting is implemented on an
authoritative DNS server, which provides different answers depending authoritative DNS server, which provides different answers depending
upon which DNS resolver has sent a query, the DNSSEC chain of trust upon which DNS resolver has sent a query, the DNSSEC chain of trust
is not altered. Even though the authoritative DNS server will not is not altered. So even though an authoritative DNS server will
always return a AAAA resource record when one exists, respective A selectively return AAAA resource records and/or A resource records,
resource records and AAAA resource records can and should both be these resource records can certainly still be signed. As a result,
signed. Therefore there are no DNSSEC implications per se. However, there should not be any negative impact on DNSSEC for those domains
any implementer of DNS Whitelisting should be careful if they that have implemented both DNSSEC on their Security-Aware
implement both DNSSEC signing of their domain and also DNS Authoritative Name Servers and also implemented DNS Resolver
Whitelisting of that same domain. Specifically, those domains should Whitelisting. As for any party implementing DNSSEC of course, such
ensure that resource records are being appropriately and reliably domains should ensure that resource records are being appropriately
signed, which may present modest incremental operational and/or and reliably signed.
technical challenges.
However, as noted in fourth paragraph of Section 4.2, end user However, network operators that run DNS recursive resolvers should be
networks may also choose to implement tools at their disposal in careful not to modify the responses received from authoritative DNS
order to address IPv6-related impairments. One of those tools could servers. It is possible that some networks may attempt to do so in
involve unspecified changes to the configuration of their DNS order to prevent AAAA record responses from going to end user hosts,
recursive resolvers. If those are Security-Aware Resolvers, due to some IPv6-related impairment or other lack of IPv6 readiness
modifying or suppressing AAAA resource records for a DNSSEC-signed with that network. But when a network operates a Security-Aware
domain will be problematic and could break the chain of trust Resolver, modifying or suppressing AAAA resource records for a
established with DNSSEC. DNSSEC-signed domain could break the chain of trust established with
DNSSEC.
9.2. Authoritative DNS Response Consistency Considerations 6.2. Privacy Considerations
In addition to the considerations raised in Section 9.1, it is As noted in Section 4.1, there is a benefit in sharing IPv6-related
conceivable that security concerns may arise when end users or other impairment statistics within the Internet community over time. Any
parties notice that the responses sent from an authoritative DNS such statistics probably should be high-level statistics, such as
server appear to vary from one network or one DNS recursive resolver "the domain example.com has observed an average daily impairment rate
to another. This may give rise to concerns that, since the of 0.05% in September 2011, down from 0.15% in January 2011". In
authoritative responses vary that there is some sort of security contrast, sharing a list of names and/or email addresses of the end
issue and/or some or none of the responses can be trusted. While users of a domain with impairments is probably not well advised from
this may seem a somewhat obscure concern, domains nonetheless may a privacy standpoint. Thus, sharing only summary data can help
wish to consider this when contemplating whether or not to pursue DNS protect end user privacy and any information which may be proprietary
Whitelisting. to a domain.
10. Privacy Considerations In addition, 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 decided 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 or otherwise seeking to obtain
the end user's consent to share such information.
As noted in Section 5.3.1, there may be methods to detect IPv6- Appropriate guidelines for any information sharing likely varies by
related impairments for a particular end user. For example, this may country and/or legal jurisdiction. Domains should consider any
be possible when an end user visits the website of a particular potential privacy issues when considering what information can be
domain. In that example, there are likely no privacy considerations shared. If a domain does publish or share detailed impairment
in automatically communicating to that end user that the domain has statistics, they would be well advised to avoid identifying
detected a particular impairment. However, if that domain decided to individual hosts or users.
share information concerning that particular end user with their
network operator or another party, then the visited domain may wish
to in some manner advise the end user of this or otherwise seek to
obtain the user's consent to such information sharing. This may be
achieved in a wide variety of ways, from presenting a message asking
the user for consent (which will of course help them solve a
technical problem of which they are likely unaware) to adding this to
a domain's website terms of use / service. Such information sharing
and communication of such sharing to end users may well vary by
geographic area and/or legal jurisdiction. Thus, a domain should
consider any potential privacy issues these sorts of scenarios.
To the extent that domains or network operators decide to publish 6.3. Considerations with Poor IPv4 and Good IPv6 Transport
impairment statistics, they should not identify individual hosts,
host identifiers, or users.
11. IANA Considerations There are situations where the differing quality of the IPv4 and IPv6
connectivity of an end user could cause complications in accessing
content when a domain is using an IPv6 transition technique. 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 and end user has markedly
superior IPv6 connectivity as 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 which fully support native IPv6. As a result this
theoretical user has very good IPv6 connectivity. However, this end
user's ISP has exhausted their available pool of unique IPv4 address,
and uses NAT in order 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). Use of 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 situation could potentially be exacerbated
when accessing a domain which is using a transition technique that
causes this user to only be able to 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.
6.4. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
12. Contributors 7. Contributors
The following people made significant textual contributions to this The following people made significant textual contributions to this
document and/or played an important role in the development and document and/or played an important role in the development and
evolution of this document: evolution of this document:
- John Brzozowski - John Brzozowski
- Chris Griffiths - Chris Griffiths
- Tom Klieber - Tom Klieber
- Yiu Lee - Yiu Lee
- Rich Woundy - Rich Woundy
13. Acknowledgements 8. Acknowledgements
The author and contributors also wish to acknowledge the assistance The author and contributors also wish to acknowledge the assistance
of the following individuals or groups. Some of these people of the following individuals or groups. Some of these people
provided helpful and important guidance in the development of this provided helpful and important guidance in the development of this
document and/or in the development of the concepts covered in this document and/or in the development of the concepts covered in this
document. Other people assisted by performing a detailed review of document. Other people assisted by performing a detailed review of
this document, and then providing feedback and constructive criticism this document, and then providing feedback and constructive criticism
for revisions to this document, or engaged in a healthy debate over for revisions to this document, or engaged in a healthy debate over
the subject of the document. All of this was helpful and therefore the subject of the document. All of this was helpful and therefore
the following individuals merit acknowledgement: the following individuals merit acknowledgement:
- Bernard Aboba - Bernard Aboba
- Jari Arkko - Jari Arkko
- Fred Baker
- Ron Bonica
- Frank Bulk - Frank Bulk
- Brian Carpenter - Brian Carpenter
- Lorenzo Colitti - Lorenzo Colitti
- Alissa Cooper - Alissa Cooper
- Dave Crocker - Dave Crocker
skipping to change at page 29, line 45 skipping to change at page 23, line 14
- J.D. Falk - J.D. Falk
- Adrian Farrel - Adrian Farrel
- Stephen Farrell - Stephen Farrell
- Tony Finch - Tony Finch
- Karsten Fleischhauer - Karsten Fleischhauer
- Igor Gashinsky
- Wesley George - Wesley George
- Philip Homburg - Philip Homburg
- Jerry Huang - Jerry Huang
- Ray Hunter - Ray Hunter
- Joel Jaeggli - Joel Jaeggli
- Erik Kline - Erik Kline
- Suresh Krishnan - Suresh Krishnan
- Victor Kuarsingh - Victor Kuarsingh
- Donn Lee
- John Leslie - John Leslie
- John Mann - John Mann
- Danny McPherson - Danny McPherson
- Milo Medin - Milo Medin
- Martin Millnert - Martin Millnert
skipping to change at page 30, line 40 skipping to change at page 24, line 14
- Barbara Stark - Barbara Stark
- Joe Touch - Joe Touch
- Hannes Tschofenig - Hannes Tschofenig
- Tina Tsou - Tina Tsou
- Members of the Broadband Internet Technical Advisory Group (BITAG) - Members of the Broadband Internet Technical Advisory Group (BITAG)
14. References 9. References
14.1. Normative References 9.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
April 1995. April 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
skipping to change at page 31, line 42 skipping to change at page 25, line 16
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
14.2. Informative References 9.2. Informative References
[Heise] Heise.de, "The Big IPv6 Experiment", Heise.de [Heise] Heise.de, "The Big IPv6 Experiment", Heise.de
Website http://www.h-online.com, January 2011, <http:// Website http://www.h-online.com, January 2011, <http://
www.h-online.com/features/ www.h-online.com/features/
The-big-IPv6-experiment-1165042.html>. The-big-IPv6-experiment-1165042.html>.
[IETF-77-DNSOP] [IETF-77-DNSOP]
Gashinsky, I., "IPv6 & recursive resolvers: How do we make Gashinsky, I., "IPv6 & recursive resolvers: How do we make
the transition less painful?", IETF 77 DNS Operations the transition less painful?", IETF 77 DNS Operations
Working Group, March 2010, Working Group, March 2010,
skipping to change at page 32, line 22 skipping to change at page 25, line 44
[IPv6-Growth] [IPv6-Growth]
Colitti, L., Gunderson, S., Kline, E., and T. Refice, Colitti, L., Gunderson, S., Kline, E., and T. Refice,
"Evaluating IPv6 adoption in the Internet", Passive and "Evaluating IPv6 adoption in the Internet", Passive and
Active Management (PAM) Conference 2010, April 2010, Active Management (PAM) Conference 2010, April 2010,
<http://www.google.com/research/pubs/archive/36240.pdf>. <http://www.google.com/research/pubs/archive/36240.pdf>.
[Impairment-Tracker] [Impairment-Tracker]
Anderson, T., "IPv6 dual-stack client loss in Norway", Anderson, T., "IPv6 dual-stack client loss in Norway",
Website , May 2011, <http://www.fud.no/ipv6/>. Website , May 2011, <http://www.fud.no/ipv6/>.
[Motion] Newton, I., "Mathematical Principles of Natural Philosophy
(Philosophiae Naturalis Principia Mathematica)",
Principia Mathematical Principles of Natural Philosophy
(Philosophiae Naturalis Principia Mathematica), July 1687,
<http://en.wikipedia.org/wiki/Newton's_laws_of_motion>.
[NW-Article-DNS-WL] [NW-Article-DNS-WL]
Marsan, C., "Google, Microsoft, Netflix in talks to create Marsan, C., "Google, Microsoft, Netflix in talks to create
shared list of IPv6 users", Network World , March 2010, <h shared list of IPv6 users", Network World , March 2010, <h
ttp://www.networkworld.com/news/2010/ ttp://www.networkworld.com/news/2010/
032610-dns-ipv6-whitelist.html>. 032610-dns-ipv6-whitelist.html>.
[NW-Article-DNSOP] [NW-Article-DNSOP]
Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", Marsan, C., "Yahoo proposes 'really ugly hack' to DNS",
Network World , March 2010, <http://www.networkworld.com/ Network World , March 2010, <http://www.networkworld.com/
news/2010/032610-yahoo-dns.html>. news/2010/032610-yahoo-dns.html>.
skipping to change at page 33, line 11 skipping to change at page 26, line 26
Proceedings of ACM Sigcomm 2002, August 2002, <http:// Proceedings of ACM Sigcomm 2002, August 2002, <http://
groups.csail.mit.edu/ana/Publications/PubPDFs/ groups.csail.mit.edu/ana/Publications/PubPDFs/
Tussle2002.pdf>. Tussle2002.pdf>.
[W6D] The Internet Society, "World IPv6 Day - June 8, 2011", [W6D] The Internet Society, "World IPv6 Day - June 8, 2011",
Internet Society Website http://www.isoc.org, Internet Society Website http://www.isoc.org,
January 2011, <http://isoc.org/wp/worldipv6day/>. January 2011, <http://isoc.org/wp/worldipv6day/>.
[WL-Concerns] [WL-Concerns]
Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y., Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y.,
Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting - Livingood, J., and R. Woundy, "IPv6 DNS Resolver
Could It Hinder IPv6 Adoption?", ISOC Internet Society Whitelisting - Could It Hinder IPv6 Adoption?",
IPv6 Deployment Workshop, April 2010, <http:// ISOC Internet Society IPv6 Deployment Workshop,
www.comcast6.net/ April 2010, <http://www.comcast6.net/
IPv6_DNS_Whitelisting_Concerns_20100416.pdf>. IPv6_DNS_Whitelisting_Concerns_20100416.pdf>.
[WL-Ops] Kline, E., "IPv6 Whitelist Operations", Google Google IPv6 [WL-Ops] Kline, E., "IPv6 Whitelist Operations", Google Google IPv6
Implementors Conference, June 2010, <http:// Implementors Conference, June 2010, <http://
sites.google.com/site/ipv6implementors/2010/agenda/ sites.google.com/site/ipv6implementors/2010/agenda/
IPv6_Whitelist_Operations.pdf>. IPv6_Whitelist_Operations.pdf>.
[Wild-Resolvers] [Wild-Resolvers]
Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig, Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig,
"Comparing DNS Resolvers in the Wild", ACM Sigcomm "Comparing DNS Resolvers in the Wild", ACM Sigcomm
Internet Measurement Conference 2010, November 2010, Internet Measurement Conference 2010, November 2010,
<http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>. <http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.
Appendix A. Document Change Log Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
-07: Significant re-write based on feedback from Jari Arkko, Joel
Jaeggli, Fred Baker, Igor Gashinsky, Donn Lee, Lorenzo Colitti, and
Erik Kline.
-06: Removed the Open Issue #8 concerning the document name, at the -06: Removed the Open Issue #8 concerning the document name, at the
direction of Joel Jaeggli. Removed Open Issue #2 from J.D. Falk and direction of Joel Jaeggli. Removed Open Issue #2 from J.D. Falk and
removed Open Issue #3 from Ray Hunter, as confirmed on the v6ops WG removed Open Issue #3 from Ray Hunter, as confirmed on the v6ops WG
mailing list. Revised the Abstract and Intro as recommended by Tony mailing list. Revised the Abstract and Intro as recommended by Tony
Finch. Per Dave Crocker, updated the diagram following remedial Finch. Per Dave Crocker, updated the diagram following remedial
ASCII art assistance, added a reference regarding IPv4-brokenness ASCII art assistance, added a reference regarding IPv4-brokenness
statistics. Removed Open Issue #1, after validating proper reference statistics. Removed Open Issue #1, after validating proper reference
placement and removing NAT444 reference. Updates per Ralph Droms' placement and removing NAT444 reference. Updates per Ralph Droms'
review for the IESG. Closed Open Issue #4, Per Joe Touch, moved review for the IESG. Closed Open Issue #4, Per Joe Touch, moved
section 8 to just after section 3 - and also moved up section 6 and section 8 to just after section 3 - and also moved up section 6 and
skipping to change at page 34, line 7 skipping to change at page 27, line 28
motivations are accounted for, etc. Closed Open Issue #9, per motivations are accounted for, etc. Closed Open Issue #9, per
Stephen Farrell, re. World IPv6 Day (retained reference but re- Stephen Farrell, re. World IPv6 Day (retained reference but re-
worded those sections). Removed the happy-eyeballs reference since worded those sections). Removed the happy-eyeballs reference since
this was an informative reference and the draft could be delayed due this was an informative reference and the draft could be delayed due
to that dependency. ALL OPEN ITEMS ARE NOW CLOSED. to that dependency. ALL OPEN ITEMS ARE NOW CLOSED.
-05: Additional changes requested by Stephen Farrell intended to -05: Additional changes requested by Stephen Farrell intended to
close his Discuss on the I-D. These changes were in Sections 6.2 and close his Discuss on the I-D. These changes were in Sections 6.2 and
8.3. Also shortened non-RFC references at Stephen's request. 8.3. Also shortened non-RFC references at Stephen's request.
-04: Made changed based on feedback received during IESG review. -04: Made changes based on feedback received during IESG review.
This does NOT include updated from the more general IETF last call - This does NOT include updated from the more general IETF last call -
that will be in a -05 version of the document. Per Ralph Droms, that will be in a -05 version of the document. Per Ralph Droms,
change the title of 6.2 from "Likely Deployment Scenarios" to change the title of 6.2 from "Likely Deployment Scenarios" to
"General Implementation Variations", as well as changes to improve "General Implementation Variations", as well as changes to improve
the understanding of sentences in Sections 2, 3, 4, and 8.2. Per the understanding of sentences in Sections 2, 3, 4, and 8.2. Per
Adrian Farrel, made a minor change to Section 3. Per Robert Sparks, Adrian Farrel, made a minor change to Section 3. Per Robert Sparks,
to make clear in Section 2 that whitelisting is done on authoritative to make clear in Section 2 that whitelisting is done on authoritative
servers and not DNS recursive resolvers, and to improve Section 8.3 servers and not DNS recursive resolvers, and to improve Section 8.3
and add a reference to I-D.ietf-v6ops-happy-eyeballs. Per Wesley and add a reference to I-D.ietf-v6ops-happy-eyeballs. Per Wesley
Eddy, updated Section 7.3.2 to address operational concerns and re- Eddy, updated Section 7.3.2 to address operational concerns and re-
skipping to change at page 36, line 15 skipping to change at page 29, line 35
-00: First version published as a v6ops WG draft. The preceding -00: First version published as a v6ops WG draft. The preceding
individual draft was individual draft was
draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE
that no changes have been made yet based on WG and list feedback. that no changes have been made yet based on WG and list feedback.
These are in queue for a -01 update. These are in queue for a -01 update.
Appendix B. Open Issues Appendix B. Open Issues
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
Check references to ensure all of them are still necessary
Author's Address Author's Address
Jason Livingood Jason Livingood
Comcast Cable Communications Comcast Cable Communications
One Comcast Center One Comcast Center
1701 John F. Kennedy Boulevard 1701 John F. Kennedy Boulevard
Philadelphia, PA 19103 Philadelphia, PA 19103
US US
Email: jason_livingood@cable.comcast.com Email: jason_livingood@cable.comcast.com
 End of changes. 93 change blocks. 
1062 lines changed or deleted 792 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/