draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11.txt   rfc6589.txt 
IPv6 Operations J. Livingood Internet Engineering Task Force (IETF) J. Livingood
Internet-Draft Comcast Request for Comments: 6589 Comcast
Intended status: Informational February 27, 2012 Category: Informational April 2012
Expires: August 30, 2012 ISSN: 2070-1721
Considerations for Transitioning Content to IPv6 Considerations for Transitioning Content to IPv6
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11
Abstract Abstract
This document describes considerations for the transition of end user This document describes considerations for the transition of end-user
content on the Internet to IPv6. While this is tailored to address content on the Internet to IPv6. While this is tailored to address
end user content, which is typically web-based, many aspects of this end-user content, which is typically web-based, many aspects of this
document may be more broadly applicable to the transition to IPv6 of document may be more broadly applicable to the transition to IPv6 of
other applications and services. This document explores the other applications and services. This document explores the
challenges involved in the transition to IPv6, potential migration challenges involved in the transition to IPv6, potential migration
tactics, possible migration phases, and other considerations. The tactics, possible migration phases, and other considerations. The
audience for this document is the Internet community generally, audience for this document is the Internet community generally,
particularly IPv6 implementers. particularly IPv6 implementers.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on August 30, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6589.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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. Challenges When Transitioning Content to IPv6 . . . . . . . . 4 2. Challenges When Transitioning Content to IPv6 ...................4
2.1. IPv6-Related Impairment . . . . . . . . . . . . . . . . . 5 2.1. IPv6-Related Impairment ....................................5
2.2. Operational Maturity Concerns . . . . . . . . . . . . . . 5 2.2. Operational Maturity Concerns ..............................5
2.3. Volume-Based Concerns . . . . . . . . . . . . . . . . . . 5 2.3. Volume-Based Concerns ......................................5
3. IPv6 Adoption Implications . . . . . . . . . . . . . . . . . . 6 3. IPv6 Adoption Implications ......................................6
4. Potential Migration Tactics . . . . . . . . . . . . . . . . . 6 4. Potential Migration Tactics .....................................6
4.1. Solve Current End User IPv6 Impairments . . . . . . . . . 7 4.1. Solving Current End-User IPv6 Impairments ..................7
4.2. Use IPv6-Specicic Names . . . . . . . . . . . . . . . . . 7 4.2. Using IPv6-Specific Names ..................................8
4.3. Implement DNS Resolver Whitelisting . . . . . . . . . . . 8 4.3. Implementing DNS Resolver Whitelisting .....................8
4.3.1. How DNS Resolver Whitelisting Works . . . . . . . . . 10 4.3.1. How DNS Resolver Whitelisting Works ................11
4.3.2. Similarities to Content Delivery Networks and 4.3.2. Similarities to Content Delivery Networks
Global Server Load Balancing . . . . . . . . . . . . . 15 and Global Server Load Balancing ...................15
4.3.3. Similarities to DNS Load Balancing . . . . . . . . . . 15 4.3.3. Similarities to DNS Load Balancing .................15
4.3.4. Similarities to Split DNS . . . . . . . . . . . . . . 15 4.3.4. Similarities to Split DNS ..........................15
4.3.5. Related Considerations . . . . . . . . . . . . . . . . 16 4.3.5. Related Considerations .............................16
4.4. Implement DNS Blacklisting . . . . . . . . . . . . . . . . 17 4.4. Implementing DNS Blacklisting .............................17
4.5. Transition Directly to Native Dual Stack . . . . . . . . . 18 4.5. Transitioning Directly to Native Dual Stack ...............18
5. Potential Implementation Phases . . . . . . . . . . . . . . . 19 5. Potential Implementation Phases ................................19
5.1. No Access to IPv6 Content . . . . . . . . . . . . . . . . 19 5.1. No Access to IPv6 Content .................................19
5.2. Using IPv6-Specific Names . . . . . . . . . . . . . . . . 19 5.2. Using IPv6-Specific Names .................................19
5.3. Deploying DNS Resolver Whitelisting Using Manual 5.3. Deploying DNS Resolver Whitelisting Using Manual
Processes . . . . . . . . . . . . . . . . . . . . . . . . 19 Processes .................................................19
5.4. Deploying DNS Resolver Whitelisting Using Automated 5.4. Deploying DNS Resolver Whitelisting Using
Processes . . . . . . . . . . . . . . . . . . . . . . . . 19 Automated Processes .......................................19
5.5. Turning Off DNS Resolver Whitelisting . . . . . . . . . . 19 5.5. Turning Off DNS Resolver Whitelisting .....................20
5.6. Deploying DNS Blacklisting . . . . . . . . . . . . . . . . 20 5.6. Deploying DNS Blacklisting ................................20
5.7. Fully Dual-Stack Content . . . . . . . . . . . . . . . . . 20 5.7. Fully Dual-Stack Content ..................................20
6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Other Considerations ...........................................20
6.1. Security Considerations . . . . . . . . . . . . . . . . . 20 6.1. Security Considerations ...................................20
6.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 21 6.2. Privacy Considerations ....................................21
6.3. Considerations with Poor IPv4 and Good IPv6 Transport . . 22 6.3. Considerations with Poor IPv4 and Good IPv6 Transport .....22
6.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 23 7. Contributors ...................................................23
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements ...............................................23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 9. References .....................................................24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References ......................................24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9.2. Informative References ....................................25
9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 28
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This document describes considerations for the transition of end user This document describes considerations for the transition of end-user
content on the Internet to IPv6. While this is tailored to address content on the Internet to IPv6. While this is tailored to address
end user content, which is typically web-based, many aspects of this end-user content, which is typically web-based, many aspects of this
document may be more broadly applicable to the transition to IPv6 of document may be more broadly applicable to the transition to IPv6 of
other applications and services. The issues explored herein will be other applications and services. The issues explored herein will be
of particular interest to major web content sites (sometimes of particular interest to major web content sites (sometimes
described hereinafter as "high-service-level domains"), which have described hereinafter as "high-service-level domains"), which have
specific and unique concerns relating to maintaining a high-quality specific and unique concerns related to maintaining a high-quality
user experience for all of their users during their transition to user experience for all of their users during their transition to
IPv6. This document explores the challenges involved in the IPv6. This document explores the challenges involved in the
transition to IPv6, potential migration tactics, possible migration transition to IPv6, potential migration tactics, possible migration
phases, and other considerations. Some sections of this document phases, and other considerations. Some sections of this document
also include information about the potential implications of various also include information about the potential implications of various
migration tactics or phased approaches to the transition to IPv6. migration tactics or phased approaches to the transition to IPv6.
2. Challenges When Transitioning Content to IPv6 2. Challenges When Transitioning Content to IPv6
The goal in transitioning content to IPv6 is to make that content The goal in transitioning content to IPv6 is to make that content
skipping to change at page 4, line 36 skipping to change at page 4, line 36
users via both IPv4 and IPv6. However, there are technical and users via both IPv4 and IPv6. However, there are technical and
operational challenges in being able to transition smoothly for all operational challenges in being able to transition smoothly for all
end users, which has led to the development of a variety of migration end users, which has led to the development of a variety of migration
tactics. A first step in understanding various migration tactics is tactics. A first step in understanding various migration tactics is
to first outline the challenges involved in moving content to IPv6. to first outline the challenges involved in moving content to IPv6.
Implementers of these various migration tactics are attempting to Implementers of these various migration tactics are attempting to
protect users of their services from having a negative experience protect users of their services from having a negative experience
(poor performance) when they receive DNS responses containing AAAA (poor performance) when they receive DNS responses containing AAAA
resource records or when attempting to use IPv6 transport. There are resource records or when attempting to use IPv6 transport. There are
two main concerns which pertain to this practice; one of which is two main concerns that pertain to this practice: one is IPv6-related
IPv6-related impairment and the other which is the maturity or impairment, and the other is the maturity or stability of IPv6
stability of IPv6 transport (and associated network operations) for transport (and associated network operations) for high-service-level
high-service-level domains. Both can negatively affect the domains. Both can negatively affect the experience of end users.
experience of end users.
Not all domains may face the same challenges in transitioning content Not all domains may face the same challenges in transitioning content
to IPv6, since the user base of each domain, traffic sources, traffic to IPv6, since the user base of each domain, traffic sources, traffic
volumes, and other factors obviously will vary between domains. As a volumes, and other factors obviously will vary between domains. As a
result, while some domains have used an IPv6 migration tactic, others result, while some domains have used an IPv6 migration tactic, others
have run brief IPv6 experiments and then decided to simply turn on have run brief IPv6 experiments and then decided to simply turn on
IPv6 for the domain without further delay and without using any IPv6 for the domain without further delay and without using any
specialized IPv6 migration tactics [Heise]. Each domain should specialized IPv6 migration tactics [Heise]. Each domain should
therefore consider its specific situation when formulating a plan to therefore consider its specific situation when formulating a plan to
move to IPv6; there is not one approach that will work for every move to IPv6; there is not one approach that will work for every
domain. domain.
2.1. IPv6-Related Impairment 2.1. IPv6-Related Impairment
Some implementers have observed that when they added AAAA resource Some implementers have observed that when they added AAAA resource
records to their authoritative DNS servers in order to support IPv6 records to their authoritative DNS servers in order to support IPv6
access to their content that a small fraction of end users had slow access to their content, a small fraction of end users had slow or
or otherwise impaired access to a given web site with both AAAA and A otherwise impaired access to a given website with both AAAA and A
resource records. The fraction of users with such impaired access resource records. The fraction of users with such impaired access
has been estimated to be as high as 0.078% of total Internet users has been estimated to be as high as 0.078% of total Internet users
[IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness]. [IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness].
While it is outside the scope of this document to explore the various 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 reasons why a particular user's system (host) may have impaired IPv6
access, and the potential solutions [I-D.ietf-v6ops-happy-eyeballs] access, and the potential solutions [RFC6555] [RFC6343], for the
[RFC6343], for the users who experience this impairment it has a very users who experience this impairment, it has a very real performance
real performance impact. It would impact access to all or most dual impact. It would impact access to all or most dual-stack services to
stack services to which the user attempts to connect. This negative which the user attempts to connect. This negative end-user
end user experience can range from somewhat slower than usual access experience can range from access that is somewhat slower than usual
(as compared to native IPv4-based access), to extremely slow access, (as compared to native IPv4-based access), to extremely slow access,
to no access to the domain's resources whatsoever. In essence, to no access to the domain's resources whatsoever. In essence,
whether the end user even has an IPv6 address or not, merely by whether the end user even has an IPv6 address or not, merely by
receiving a AAAA record response the user either cannot access a receiving a AAAA record response, the user either cannot access a
Fully Qualified Domain Name (FQDN, representing a service or resource Fully Qualified Domain Name (FQDN, representing a service or resource
sought) or it is so slow that the user gives up and assumes the sought) or it is so slow that the user gives up and assumes the
destination is unreachable. destination is unreachable.
2.2. Operational Maturity Concerns 2.2. Operational Maturity Concerns
Some implementers have discovered that network operations, operations Some implementers have discovered that network operations, operations
support and business support systems, and other operational processes support and business support systems, and other operational processes
and procedures are less mature for IPv6 as compared to IPv4, since and procedures are less mature for IPv6 as compared to IPv4, since
IPv6 has not heretofore been pervasively deployed. This operational IPv6 has not heretofore been pervasively deployed. This operational
immaturity may be observed not just within the network of a given immaturity may be observed not just within the network of a given
domain but also in any directly or indirectly interconnected domain but also in any directly or indirectly interconnected
networks. As a result, many domains consider it prudent to undertake networks. As a result, many domains consider it prudent to undertake
any network changes which will cause traffic to shift to IPv6 any network changes that will cause traffic to shift to IPv6
gradually in order to provide time and experience for IPv6 operations gradually, in order to provide time and experience for IPv6
and network practices mature. operations and network practices to mature.
2.3. Volume-Based Concerns 2.3. Volume-Based Concerns
While Section 2.2 pertains to risks due to immaturity in operations, While Section 2.2 pertains to risks due to immaturity in operations,
a related concern is that some technical issues may not become a related concern is that some technical issues may not become
apparent until some moderate to high volume of traffic is sent via 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 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 within the network of that domain but also for any directly or
indirectly interconnected networks. Furthermore, compared to domains indirectly interconnected networks. Furthermore, compared to domains
with small to moderate traffic volumes, whether by the count of end with small to moderate traffic volumes, whether by the count of end
users or count of bytes transferred, high-traffic domains receive users or count of bytes transferred, high-traffic domains receive
such a level of usage that it is prudent to undertake any network such a level of usage that it is prudent to undertake any network
changes gradually and in a manner which minimizes the risk of changes gradually and in a manner that minimizes the risk of
disruption. One can imagine that for one of the top ten sites disruption. One can imagine that for one of the top ten sites
globally, for example, the idea of suddenly turning on a significant globally, for example, the idea of suddenly turning on a significant
amount of IPv6 traffic is quite daunting and would carry a relatively amount of IPv6 traffic is quite daunting and would carry a relatively
high risk of network and/or other disruptions. high risk of network and/or other disruptions.
3. IPv6 Adoption Implications 3. IPv6 Adoption Implications
It is important that the challenges in transitioning content to IPv6 It is important that the challenges in transitioning content to IPv6
noted in Section 2 are addressed, especially for high-service-level as noted in Section 2 are addressed, especially for high-service-
domains. Some high-service-level domains may find the prospect of level domains. Some high-service-level domains may find the prospect
transitioning to IPv6 extremely daunting without having some ability of transitioning to IPv6 extremely daunting without having some
to address these challenges and to incrementally control their ability to address these challenges and to incrementally control
transition to IPv6. Lacking such controls, some domains may choose their transition to IPv6. Lacking such controls, some domains may
to substantially delay their transition to IPv6. A substantial delay choose to substantially delay their transition to IPv6. A
in content moving to IPv6 could certainly mean there are somewhat substantial delay in moving content to IPv6 could certainly mean
fewer motivating factors for network operators to deploy IPv6 to end there are somewhat fewer motivating factors for network operators to
user hosts (though they have many significant motivating factors that deploy IPv6 to end-user hosts (though they have many significant
are largely independent of content). At the same time, unless motivating factors that are largely independent of content). At the
network operators transition to IPv6, there are of course fewer same time, unless network operators transition to IPv6, there are of
motivations for domain owners to transition content to IPv6. Without course fewer motivations for domain owners to transition content to
progress in each part of the Internet ecosystem, networks and/or IPv6. Without progress in each part of the Internet ecosystem,
content sites may delay, postpone, or cease adoption of IPv6, or to networks and/or content sites may delay, postpone, or cease adoption
actively seek alternatives to it. Such alternatives may include the of IPv6, or to actively seek alternatives to it. Such alternatives
use of multi-layer or large scale network address translation (NAT), may include the use of multi-layer or large-scale network address
which is not preferred relative to native dual stack. translation (NAT), which is not preferred relative to native dual
stack.
Obviously, transitioning content to IPv6 is important to IPv6 Obviously, transitioning content to IPv6 is important to IPv6
adoption overall. While challenges do exist, such a transition is adoption overall. While challenges do exist, such a transition is
not an impossible task for a domain to undertake. A range of not an impossible task for a domain to undertake. A range of
potential migration tactics, as noted below in Section 4, can help potential migration tactics, as noted below in Section 4, can help
meet these challenges and enable a domain to successfully transition meet these challenges and enable a domain to successfully transition
content and other services to IPv6. content and other services to IPv6.
4. Potential Migration Tactics 4. Potential Migration Tactics
Domains have a wide range of potential tactics at their disposal that Domains have a wide range of potential tactics at their disposal that
may be used to facilitate the migration to IPv6. This section may be used to facilitate the migration to IPv6. This section
includes many of the key tactics that could be used by a domain but includes many of the key tactics that could be used by a domain but
it is by no means an exhaustive or exclusive list. Only a specific by no means provides an exhaustive or exclusive list. Only a
domain can judge whether or not a given (or any) migration tactic specific domain can judge whether or not a given (or any) migration
applies to their domain and meets their needs. A domain may also tactic applies to it and meets its needs. A domain may also decide
decide to pursue several of these tactics in parallel. Thus, the to pursue several of these tactics in parallel. Thus, the usefulness
usefulness of each tactic and the associated pros and cons will vary of each tactic and the associated pros and cons will vary from domain
from domain to domain. to domain.
4.1. Solve Current End User IPv6 Impairments 4.1. Solving Current End-User IPv6 Impairments
Domains can endeavor to fix the underlying technical problems Domains can endeavor to fix the underlying technical problems
experienced by their end users during the transition to IPv6, as experienced by their end users during the transition to IPv6, as
noted in Section 2.1. One challenge with this option is that a noted in Section 2.1. One challenge with this option is that a
domain may have little or no control over the network connectivity, domain may have little or no control over the network connectivity,
operating system, client software (such as a web browser), and/or operating system, client software (such as a web browser), and/or
other capabilities of the end users of that domain. In most cases a 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. domain is only in a position to influence and guide its end users.
While this is not the same sort of direct control which may exist in While this is not the same sort of direct control that may exist, for
an enterprise network for example, major domains are likely to be example, in an enterprise network, major domains are likely to be
trusted by their end users and may therefore be able to influence and trusted by their end users and may therefore be able to influence and
guide these users in solving any IPv6-related impairments. guide these users in solving any IPv6-related impairments.
Another challenge is that end user impairments are something that one Another challenge is that end-user impairments are something that one
domain on their own cannot solve. This means that domains may find domain on its own cannot solve. This means that domains may find it
it more effective to coordinate with many others in the Internet more effective to coordinate with many others in the Internet
community to solve what is really a collective problem that affects community to solve what is really a collective problem that affects
the entire Internet. Of course, it can sometimes be difficult to the entire Internet. Of course, it can sometimes be difficult to
motivate members of the Internet community to work collectively motivate members of the Internet community to work collectively
towards such a goal, sharing the labor, time, and costs related to towards such a goal, sharing the labor, time, and costs related to
such an effort. However, World IPv6 Day [W6D] shows that such such an effort. However, World IPv6 Day [W6D] shows that such
community efforts are possible and despite any potential challenges, community efforts are possible, and despite any potential challenges,
the Internet community continues to work together in order to solve the Internet community continues to work together in order to solve
end user IPv6 impairments. end-user IPv6 impairments.
One potential tactic may be to identify which users have such One potential tactic may be to identify which users have such
impairments and then to communicate this information to affected impairments and then to communicate this information to affected
users. Such end user communication is likely to be most helpful if 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 the end users are not only alerted to a potential problem but are
careful and detailed advice on how to resolve this on their own, or given careful and detailed advice on how to resolve this on their
is guided to where they can seek help in doing so. Another potential own, or are guided to where they can seek help in doing so. Another
tactic is for a domain to collect, track over time, and periodically potential tactic is for a domain to collect, track over time, and
share with the Internet community the rate of impairment observed for periodically share with the Internet community the rate of impairment
a domain. In any such end user IPv6-related analysis and observed for that domain. In any such end-user IPv6-related analysis
communication, Section 6.2 is worth taking into account. and communication, Section 6.2 is worth taking into account.
However, while these tactics can help reduce IPv6-related impairments However, while these tactics can help reduce IPv6-related impairments
Section 2.1, they do not address either operational maturity concerns (Section 2.1), they do not address either operational maturity
noted in Section 2.2 or volume-based concerns noted in Section 2.3, concerns (noted in Section 2.2) or volume-based concerns (noted in
which should be considered and addressed separately. Section 2.3), which should be considered and addressed separately.
4.2. Use IPv6-Specicic Names 4.2. Using IPv6-Specific Names
Another potential migration tactic is for a domain to gain experience Another potential migration tactic is for a domain to gain experience
using a special Fully-Qualified Domain Name (FQDN). This has become using a special FQDN. This has become typical for domains beginning
typical for domains beginning the transition to IPv6, whereby an the transition to IPv6, whereby an address-family-specific name such
address-family-specific name such as ipv6.example.com or as ipv6.example.com or www.ipv6.example.com is used. An end user
www.ipv6.example.com is used. An end user would have to know to use would have to know to use this special IPv6-specific name; it is not
this special IPv6-specific name; it is not the same name used for the same name used for regular traffic.
regular traffic.
This special IPv6-specific name directs traffic to a host or hosts This special IPv6-specific name directs traffic to a host or hosts
which have been enabled for native IPv6 access. In some cases this that have been enabled for native IPv6 access. In some cases, this
name may point to hosts which are separate from those used for IPv4 name may point to hosts that are separate from those used for IPv4
traffic (via www.example.com), while in other cases it may point to traffic (via www.example.com), while in other cases it may point to
the same hosts used for IPv4 traffic. A subsequent phase, if the same hosts used for IPv4 traffic. A subsequent phase, if
separate hosts are used to support special IPv6-specific names, is to separate hosts are used to support special IPv6-specific names, is to
move to the same hosts used for regular traffic in order to utilize move to the same hosts used for regular traffic in order to utilize
and exercise production infrastructure more fully. Regardless of and exercise production infrastructure more fully. Regardless of
whether or not dedicated hosts are used, the use of the special name 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 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 gain IPv6 experience and increase IPv6 use on a relatively controlled
basis. Any lessons learned can then inform plans for a full basis. Any lessons learned can then inform plans for a full
transition to IPv6. This also provides an opportunity for a domain transition to IPv6. This also provides an opportunity for a domain
to develop any necessary training for staff, to develop IPv6-related to develop any necessary training for staff, to develop IPv6-related
testing procedures for their production network and lab, to deploy testing procedures for its production network and lab, to deploy IPv6
IPv6 functionality into their production network, and to develop and functionality into its production network, and to develop and deploy
deploy IPv6-related network and service monitors. It is also an IPv6-related network and service monitors. It is also an opportunity
opportunity to add a relatively small amount of IPv6 traffic to to add a relatively small amount of IPv6 traffic to ensure that
ensure that network gear, network interconnects, and IPv6 routing in network gear, network interconnects, and IPv6 routing in general are
general is working as expected. working as expected.
While using a special IPv6-specific name is a good initial step to While using a special IPv6-specific name is a good initial step to
functionally test and prepare a domain for IPv6, including developing functionally test and prepare a domain for IPv6 -- including
and maturing IPv6 operations, as noted in Section 2.2, the utility of developing and maturing IPv6 operations, as noted in Section 2.2 --
the tactic is limited since users must know the IPv6-specific name, the utility of the tactic is limited, since users must know the IPv6-
the traffic volume will be low, and the traffic is unlikely to be specific name, the traffic volume will be low, and the traffic is
representative of the general population of end users (they are unlikely to be representative of the general population of end users
likely to be self-selecting early adopters and more technically (they are likely to be self-selecting early adopters and more
advanced than average), among other reasons. As a result, any technically advanced than average), among other reasons. As a
concerns and risks related to traffic volume as noted Section 2.3 result, any concerns and risks related to traffic volume, as noted in
should still be considered and addressed separately. Section 2.3, should still be considered and addressed separately.
4.3. Implement DNS Resolver Whitelisting 4.3. Implementing DNS Resolver Whitelisting
Another potential tactic, especially when a high-service-level domain Another potential tactic -- especially when a high-service-level
is ready to move beyond an IPv6-specific name, as described in domain is ready to move beyond an IPv6-specific name, as described in
Section 4.2, is to selectively return AAAA resource records (RRs), Section 4.2 -- is to selectively return AAAA resource records (RRs),
which contain IPv6 addresses. This selective response of DNS records which contain IPv6 addresses. This selective response of DNS records
is performed by an authoritative DNS servers for a domain in response is performed by an authoritative DNS server for a domain in response
to DNS queries sent by DNS recursive resolvers [RFC1035]. This is to DNS queries sent by DNS recursive resolvers [RFC1035]. This is
commonly referred to in the Internet community as "DNS Resolver commonly referred to in the Internet community as "DNS Resolver
Whitelisting", and will be referred to as such hereafter, though in Whitelisting", and will be referred to as such hereafter, though in
essence it is simply a tactic enabling the selective return of DNS essence it is simply a tactic enabling the selective return of DNS
records based upon various technical factors. An end user is seeking records based upon various technical factors. An end user is seeking
a resource by name, and this selective response mechanism enables a resource by name, and this selective response mechanism enables
what is perceived to be the most reliable and best performing IP what is perceived to be the most reliable and best performing IP
address family to be used (IPv4 or IPv6). It shares similarities address family to be used (IPv4 or IPv6). It shares similarities
with Content Delivery Networks, Global Server Load Balancing, DNS with Content Delivery Networks (CDNs), Global Server Load Balancing
Load Balancing, and Split DNS, as described below in Section 4.3.2, (GSLB), DNS Load Balancing, and Split DNS, as described below in
Section 4.3.3, Section 4.3.4. A few high-service-level domains have Sections 4.3.2, 4.3.3, and 4.3.4. A few high-service-level domains
either implemented DNS Resolver Whitelisting (one of many migration have either implemented DNS Resolver Whitelisting (one of many
tactics they have used or are using) or are considering doing so migration tactics they have used or are using) or are considering
[NW-Article-DNS-WL] [WL-Ops]. doing so [NW-Article-DNS-WL] [WL-Ops].
This is a migration tactic used by domains as a method for This is a migration tactic used by domains as a method for
incrementally transitioning inbound traffic to a domain to IPv6. If incrementally transitioning inbound traffic to a domain to IPv6. If
an incremental tactic like this is not used, a domain might return an incremental tactic like this is not used, a domain might return
AAAA resource records to any relevant DNS query, meaning the domain AAAA resource records to any relevant DNS query, meaning the domain
could go quickly from no IPv6 traffic to potentially a significant could go quickly from no IPv6 traffic to a potentially significant
amount as soon as the AAAA resource records are published. When DNS amount as soon as the AAAA resource records are published. When DNS
Resolver Whitelisting is implemented, a domain's authoritative DNS Resolver Whitelisting is implemented, a domain's authoritative DNS
will selectively return a AAAA resource record to DNS recursive will selectively return a AAAA resource record to DNS recursive
resolvers on a whitelist maintained by the domain, while returning no resolvers on a whitelist maintained by the domain, while returning no
AAAA resource records to DNS recursive resolvers which are not on AAAA resource records to DNS recursive resolvers that are not on that
that whitelist. This tactic will not have a direct impact on whitelist. This tactic will not have a direct impact on reducing
reducing IPv6-related impairments Section 2.1, though it can help a IPv6-related impairments (Section 2.1), though it can help a domain
domain address operational maturity concerns Section 2.2 and concerns address operational maturity concerns (Section 2.2) as well as
and risks related to traffic volume Section 2.3. While DNS Resolver concerns and risks related to traffic volume (Section 2.3). While
Whitelisting does not solve IPv6-related impairments, it can help a DNS Resolver Whitelisting does not solve IPv6-related impairments, it
domain to avoid users that have them. As a result, the tactic can help a domain to avoid users that have them. As a result, the
removes their impact in all but the few networks that are tactic removes their impact in all but the few networks that are
whitelisted. DNS Resolver Whitelisting also allows a website whitelisted. DNS Resolver Whitelisting also allows website operators
operator to protect non-IPv6 networks (i.e. networks that do not to protect non-IPv6 networks (i.e., networks that do not support IPv6
support IPv6 and/or do not have plans to do so in the future) from and/or do not have plans to do so in the future) from IPv6-related
IPv6-related impairments in their networks. Finally, domains using impairments in their networks. Finally, domains using this tactic
this tactic should understand that the onus is on them to ensure that should understand that the onus is on them to ensure that the servers
the servers being whitelisted represent a network that has proven to being whitelisted represent a network that has proven to their
their satisfaction that they are IPv6-ready and this will not create satisfaction that they are IPv6-ready and that this will not create a
a poor end user experience for users of the whitelisted server. poor end-user experience for users of the whitelisted server.
There are of course challenges and concerns relating to DNS Resolver There are of course challenges and concerns related to DNS Resolver
Whitelisting. Some of the concerns with a whitelist of DNS recursive Whitelisting. Some of the concerns with a whitelist of DNS recursive
resolvers may be held by parties other than the implementing domain, resolvers may be held by parties other than the implementing domain,
such as network operators or end users that may not have had their such as network operators or end users that may not have had their
DNS recursive resolvers added to a whitelist. Additionally, the IP DNS recursive resolvers added to a whitelist. Additionally, the IP
address of a DNS recursive resolver is not a precise indicator of the address of a DNS recursive resolver is not a precise indicator of the
IPv6 preparedness, or lack of IPv6-related impairment, of end user IPv6 preparedness, or lack of IPv6-related impairment, of end-user
hosts which query (use) a particular DNS recursive resolver. While hosts that query (use) a particular DNS recursive resolver. While
the IP addresses of DNS recursive resolvers on networks known to have the IP addresses of DNS recursive resolvers on networks known to have
deployed IPv6 may be an imperfect proxy for judging IPv6 deployed IPv6 may be an imperfect proxy for judging IPv6
preparedness, or lack of IPv6-related impairment, it is one of the preparedness, or lack of IPv6-related impairment, this method is one
better available methods at the current time. For example, of the better available methods at the current time. For example,
implementers have found that it is possible to measure the level of implementers have found that it is possible to measure the level of
IPv6 preparedness of the end users behind any given DNS recursive IPv6 preparedness of the end users behind any given DNS recursive
resolver by conducting ongoing measurement of the IPv6 preparedness resolver by conducting ongoing measurement of the IPv6 preparedness
of end users querying for one-time-use hostnames and then correlating of end users querying for one-time-use hostnames and then correlating
the domain's authoritative DNS server logs with their web server the domain's authoritative DNS server logs with their web server
logs. This can help implementers form a good picture of which DNS logs. This can help implementers form a good picture of which DNS
recursive resolvers have working IPv6 users behind them and which do recursive resolvers have working IPv6 users behind them and which do
not, what the latency impact of turning on IPv6 for any given DNS not, what the latency impact of turning on IPv6 for any given DNS
recursive resolver is, etc. In addition, given the current state of recursive resolver is, etc. In addition, given the current state of
global IPv6 deployment, this migration tactic allows content global IPv6 deployment, this migration tactic allows content
providers to selectively expose the availability of their IPv6 providers to selectively expose the availability of their IPv6
services. While opinions in the Internet community concerning DNS services. While opinions in the Internet community concerning DNS
Resolver Whitelisting are understandably quite varied, there is clear Resolver Whitelisting are understandably quite varied, there is clear
consensus that DNS Resolver Whitelisting can be a useful tactic for consensus that DNS Resolver Whitelisting can be a useful tactic for
use during the transition of a domain to IPv6. In particular, some use during the transition of a domain to IPv6. In particular, some
high-service-level domains view DNS Resolver Whitelisting as one of high-service-level domains view DNS Resolver Whitelisting as one of
the few practical and low-risk approaches enabling them to transition the few practical and low-risk approaches enabling them to transition
to IPv6, without which their transition may not take place for some to IPv6, without which their transition may not take place for some
time. However, there is also consensus that this practice is time. However, there is also consensus that this practice is
workable on a manual basis (see below) only in the short-term and 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 that it will not scale over the long term. Thus, some domains may
find DNS Resolver Whitelisting a beneficial temporary tactic in their find DNS Resolver Whitelisting a beneficial temporary tactic in their
transition to IPv6. transition to IPv6.
At the current time, generally speaking, a domain that implements DNS At the current time, generally speaking, a domain that implements DNS
Resolver Whitelisting does so manually. This means that a domain Resolver Whitelisting does so manually. This means that a domain
manually maintains a list of networks that are permitted to receive manually maintains a list of networks that are permitted to receive
IPv6 records (via their DNS resolver IP addresses) and that these IPv6 records (via their DNS resolver IP addresses) and that these
networks typically submit applications, or follow some other process networks typically submit applications, or follow some other process
established by the domain, in order to be added to the DNS Whitelist. established by the domain, in order to be added to the DNS Whitelist.
However, implementers foresee that a subsequent phase of DNS Resolver However, implementers foresee that a subsequent phase of DNS Resolver
Whitelisting is likely to emerge in the future, possibly in the near 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 future. In this new phase, a domain would return IPv6 and/or IPv4
records dynamically based on automatically detected technical records dynamically based on automatically detected technical
capabilities, location, or other factors. It would then function capabilities, location, or other factors. It would then function
much like (or indeed as part of) global server load balancing, a much like (or indeed as part of) GSLB, a common practice already in
common practice already in use today, as described in Section 4.3.2. use today, as described in Section 4.3.2. Furthermore, in this
Furthermore, in this future phase, networks would be added to and future phase, networks would be added to and removed from a DNS
removed from a DNS Whitelist automatically, and possibly on a near- Whitelist automatically, and possibly on a near-real-time basis.
real-time basis. This means, crucially, that networks would no This means, crucially, that networks would no longer need to apply to
longer need to apply to be added to a whitelist, which may alleviate be added to a whitelist, which may alleviate many of the key concerns
many of the key concerns that network operators may have with this that network operators may have with this tactic when it is
tactic when it is implemented on a manual basis. implemented on a manual basis.
4.3.1. How DNS Resolver Whitelisting Works 4.3.1. How DNS Resolver Whitelisting Works
Using a "whitelist" in a generic sense means that no traffic (or Using a "whitelist" in a generic sense means that no traffic (or
traffic of a certain type) is permitted to the destination host traffic of a certain type) is permitted to the destination host
unless the originating host's IP address is contained in the unless the originating host's IP address is contained in the
whitelist. In contrast, using a "blacklist" means that all traffic whitelist. In contrast, using a "blacklist" means that all traffic
is permitted to the destination host unless the originating host's IP is permitted to the destination host unless the originating host's IP
address is contained in the blacklist. In the case of DNS Resolver 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 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 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 such as www.example.com, without regard to the underlying IP address
family (IPv4 or IPv6) which may be used to access that resource. family (IPv4 or IPv6) that may be used to access that resource.
DNS Resolver Whitelisting is implemented in authoritative DNS DNS Resolver Whitelisting is implemented in authoritative DNS
servers, not in DNS recursive resolvers. These authoritative DNS servers, not in DNS recursive resolvers. These authoritative DNS
servers selectively return AAAA resource records using the IP address servers selectively return AAAA resource records using the IP address
of the DNS recursive resolver that has sent it a query. Thus, for a of the DNS recursive resolver that has sent them a query. Thus, for
given operator of a website, such as www.example.com, the domain a given operator of a website, such as www.example.com, the domain
operator implements whitelisting on the authoritative DNS servers for operator implements whitelisting on the authoritative DNS servers for
the domain example.com. The whitelist is populated with the IPv4 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 AAAA resource the Internet, which have been authorized to receive AAAA resource
record responses. These DNS recursive resolvers are operated by record responses. These DNS recursive resolvers are 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 whitelist, 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 (and an A record would be sent). hostname in the example.com domain (and an A record would be sent).
However, if a DNS recursive resolver is matched in the whitelist, However, if a DNS recursive resolver is matched in the whitelist,
then AAAA resource records WILL be sent. As a result, while Section then AAAA resource records WILL be sent. As a result, while
2.2 of [RFC4213] notes that a stub resolver can make a choice between Section 2.2 of [RFC4213] notes that a stub resolver can make a choice
whether to use a AAAA record or A record response, with DNS Resolver between whether to use a AAAA record or A record response, with DNS
Whitelisting the authoritative DNS server can also decide whether to Resolver Whitelisting the authoritative DNS server can also decide
return a AAAA record, an A record, or both record types. whether to return a AAAA record, an A record, or both record types.
When implemented on a manual basis, DNS Resolver Whitelisting When implemented on a manual basis, DNS Resolver Whitelisting
generally means that a very small fraction of the DNS recursive generally means that a very small fraction of the DNS recursive
resolvers on the Internet (those in the whitelist) will receive AAAA resolvers on the Internet (those in the whitelist) will receive AAAA
responses. The large majority of DNS recursive resolvers on the responses. The large majority of DNS recursive resolvers on the
Internet will therefore receive only A resource records containing Internet will therefore receive only A resource records containing
IPv4 addresses. When implemented manually, domains may find the IPv4 addresses. Domains may find the practice imposes some
practice imposes some incremental operational burdens insofar as it incremental operational burdens insofar as it can consume staff time
can consume staff time to maintain a whitelist (such as additions and to maintain a whitelist (such as additions and deletions to the
deletions to the list), respond to and review applications to be list), respond to and review applications to be added to a whitelist,
added to a whitelist, maintain good performance levels on maintain good performance levels on authoritative DNS servers as the
authoritative DNS servers as the whitelist grows, create new network whitelist grows, create new network monitors to check the health of a
monitors to check the health of a whitelist function, perform new whitelist function, perform new types of troubleshooting related to
types of troubleshooting related to whitelisting, etc. In addition, whitelisting, etc. In addition, manually based whitelisting imposes
manually-based whitelisting imposes some incremental burdens on some incremental burdens on operators of DNS recursive resolvers
operators of DNS recursive resolvers (such as network operators), (such as network operators), since they will need to apply to be
since they will need to apply to be whitelisted with any implementing whitelisted with any implementing domains, and will subsequently need
domains, and will subsequently need processes and systems to track processes and systems to track the status of whitelisting
the status of whitelisting applications, respond to requests for applications, respond to requests for additional information
additional information pertaining to these applications, and track pertaining to these applications, and track any de-whitelisting
any de-whitelisting actions. actions.
When implemented on an automated basis in the future, DNS recursive When implemented on an automated basis in the future, DNS recursive
resolvers listed in the whitelist could expand and contract resolvers listed in the whitelist could expand and contract
dynamically, and possibly in near-real-time, based on a wide range of dynamically, and possibly in near-real time, based on a wide range of
factors. As a result, it is likely that the number of DNS recursive factors. As a result, it is likely that the number of DNS recursive
resolvers on the whitelist will be substantially larger than when resolvers on the whitelist will be substantially larger than when
such a list is maintained manually, and it is likely the the such a list is maintained manually, and it is also likely that the
whitelist will grow at a rapid rate. This automation can eliminate whitelist will grow at a rapid rate. This automation can eliminate
most of the significant incremental operational burdens on both most of the significant incremental operational burdens on
implementing domains as well as operators of DNS recursive resolvers, implementing domains as well as operators of DNS recursive resolvers,
which is clearly a factor that is motivating implementers to work to which is clearly a factor that is motivating implementers to work to
automate this function. automate this function.
Section 4.3.1.1 and Figure 1 have more details on DNS Resolver Section 4.3.1.1 and Figure 1 provide more details on DNS Resolver
Whitelisting generally. In addition, the potential deployment models Whitelisting in general. In addition, the potential deployment
of DNS Resolver Whitelisting (manual and automated) are described in models of DNS Resolver Whitelisting (manual and automated) are
Section 5. It is also important to note that DNS Resolver described in Section 5. It is also important to note that DNS
Whitelisting also works independently of whether an authoritative DNS Resolver Whitelisting also works independently of whether an
server, DNS recursive resolver, or end user host uses IPv4 transport, authoritative DNS server, DNS recursive resolver, or end-user host
IPv6, or both. So, for example, whitelisting may not result in the uses IPv4 transport, IPv6, or both. So, for example, whitelisting
return of AAAA responses even in those cases where the DNS recursive may not result in the return of AAAA responses even in those cases
resolver has queried the authoritative server over IPv6 transport. where the DNS recursive resolver has queried the authoritative server
This may also be the case in some situations when the end user host's over an IPv6 transport. This may also be the case in some situations
original query to its DNS recursive resolver was over IPv6 transport, when the end-user host's original query to its DNS recursive resolver
if that DNS recursive resolver is not on a given whitelist. One was over IPv6 transport, if that DNS recursive resolver is not on a
important reason for this is that even though the DNS recursive given whitelist. One important reason for this is that even though
resolver may have no IPv6-related impairments, this is not a reliable the DNS recursive resolver may have no IPv6-related impairments, this
predictor of whether the same is true of the end user host. This is not a reliable predictor of whether the same is true of the end-
also means that a DNS whitelist can contain both IPv4 and IPv6 user host. This also means that a DNS Whitelist can contain both
addresses. IPv4 and IPv6 addresses.
4.3.1.1. Description of the Operation of DNS Resolver Whitelisting 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.
The system logic of DNS Resolver Whitelisting is as follows: The system logic of DNS Resolver 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 FQDN www.example.com, for which AAAA (IPv6) resource records
AAAA (IPv6) resource records exist. 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 whitelist that is the DNS Whitelist. query against the whitelist (i.e., the DNS Whitelist).
3. If the DNS recursive resolver's IP address IS matched in the 3. If the DNS recursive resolver's IP address IS matched in the
whitelist, then the response to that specific DNS recursive whitelist, then the response to that specific DNS recursive
resolver can 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
whitelist, then the response to that specific DNS recursive whitelist, then the response to that specific DNS recursive
resolver cannot contain AAAA (IPv6) address resource records. In resolver cannot contain AAAA (IPv6) address resource records. In
this case, the server will likely return a response with the this case, the server will likely return a response with the
response code (RCODE) being set to 0 (No Error) with an empty response code (RCODE) being set to 0 (No Error) with an empty
skipping to change at page 15, line 8 skipping to change at page 15, line 8
| | | | | |
| DNS Response: | | | DNS Response: | |
| example.com A, AAAA | | | example.com A, AAAA | |
|<----------------------| | |<----------------------| |
Figure 1: DNS Resolver Whitelisting Diagram Figure 1: DNS Resolver Whitelisting Diagram
4.3.2. Similarities to Content Delivery Networks and Global Server Load 4.3.2. Similarities to Content Delivery Networks and Global Server Load
Balancing Balancing
DNS Resolver Whitelisting is functionally similar to Content Delivery DNS Resolver Whitelisting is functionally similar to CDNs and GSLB.
Networks (CDNs) and Global Server Load Balancing (GSLB). When using When using a CDN or GSLB, a geographically aware authoritative DNS
a CDN or GSLB, a geographically-aware authoritative DNS server server function is usually part of that overall system. As a result,
function is usually part of that overall system. As a result, the the use of a CDN or GSLB with an authoritative DNS server function
use of a CDN or GSLB with an authoritative DNS server function
enables the IP address resource records returned to a resolver in enables the IP address resource records returned to a resolver in
response to a query to vary based on the estimated geographic response to a query to vary, based on the estimated geographic
location of the resolver [Wild-Resolvers] or a range of other location of the resolver [Wild-Resolvers] or a range of other
technical factors. This CDN or GSLB DNS function is performed in technical factors. This CDN or GSLB DNS function is performed in
order to attempt to direct hosts to connect to the nearest hosts (as order to attempt to direct hosts to a) connect either to the nearest
measured in round trip time), to the host that has the best host (as measured in round-trip time) or to the host that has the
connectivity to an end user, to route around failures, to avoid sites best connectivity to an end user, b) route around failures, c) avoid
where maintenance work has taken down hosts, and/or to the host that sites where maintenance work has taken down hosts, and/or d) connect
will otherwise provide the best service experience for an end user at to the host that will otherwise provide the best service experience
a given point in time. As a result, one can see a direct similarity for an end user at a given point in time. As a result, one can see a
to DNS Resolver Whitelisting insofar as different IP address resource direct similarity to DNS Resolver Whitelisting insofar as different
records are selectively returned to resolvers based on the IP address IP address resource records are selectively returned to resolvers
of each resolver and/or other imputed factors related to that IP based on the IP address of each resolver and/or other imputed factors
address. related to that IP address.
4.3.3. Similarities to DNS Load Balancing 4.3.3. Similarities to DNS Load Balancing
DNS Resolver Whitelisting has some similarities to DNS load DNS Resolver Whitelisting has some similarities to DNS Load
balancing. There are of course many ways that DNS load balancing can Balancing. There are of course many ways that DNS Load Balancing can
be performed. In one example, multiple IP address resource records 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 (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 approach is referred to as DNS round robin [RFC1794]. DNS round
robin may also be employed where SRV resource records are used robin may also be employed where SRV resource records are used
[RFC2782]. In another example, one or more of the IP address [RFC2782]. In another example, one or more of the IP address
resource records in the DNS will direct traffic to a load balancer. resource records in the DNS will direct traffic to a load balancer.
That load balancer, in turn, may be application-aware, and pass the 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 traffic on to one or more hosts that are connected to the load
have different IP addresses. In cases where private IPv4 addresses balancer and that have different IP addresses. In cases where
are used [RFC1918], as well as when public IP addresses are used, private IPv4 addresses are used [RFC1918], as well as when public IP
those end hosts may not necessarily be directly reachable without addresses are used, those end hosts may not necessarily be directly
passing through the load balancer first. So, similar to DNS Resolver reachable without passing through the load balancer first. So,
Whitelisting, a load balancer will control what server host an end similar to DNS Resolver Whitelisting, a load balancer will control
user's host communicates with when using a FQDN. what server host an end-user's host communicates with when using
an FQDN.
4.3.4. Similarities to Split DNS 4.3.4. Similarities to Split DNS
DNS Resolver Whitelisting has some similarities to so-called split DNS Resolver Whitelisting has some similarities to so-called Split
DNS, briefly described in Section 3.8 of [RFC2775]. When split DNS DNS, briefly described in Section 3.8 of [RFC2775]. When Split DNS
is used, the authoritative DNS server selectively returns different is used, the authoritative DNS server selectively returns different
responses depending upon what host has sent the query. While responses, depending upon what host has sent the query. While
[RFC2775] notes the typical use of split DNS is to provide one answer [RFC2775] notes that the typical use of Split DNS is to provide one
to hosts on an Intranet (internal network) and a different answer to answer to hosts on an Intranet (internal network) and a different
hosts on the Internet (external or public network), the basic idea is answer to hosts on the Internet (external or public network), the
that different answers are provided to hosts on different networks. basic idea is that different answers are provided to hosts on
This is similar to the way that DNS Resolver Whitelisting works, different networks. This is similar to the way that DNS Resolver
whereby hosts on different networks which use different DNS recursive Whitelisting works, whereby hosts on different networks that use
resolvers, receive different answers if one DNS recursive resolver is different DNS recursive resolvers receive different answers if one
on the whitelist and the other is not. However, Internet DNS recursive resolver is on the whitelist and the other is not.
transparency and Internet fragmentation concerns regarding split DNS However, Internet transparency and Internet fragmentation concerns
are detailed in Section 2.1 of [RFC2956] and Section 2.7 notes regarding Split DNS are detailed in Section 2.1 of [RFC2956].
concerns regarding split DNS and that it "makes the use of Fully Section 2.7 of [RFC2956] notes concerns regarding Split DNS,
Qualified Domain Names (FQDNs) as endpoint identifiers more complex". including the concern that the deployment of Split DNS "makes the use
Section 3.5 of [RFC2956] further recommends that maintaining a stable of Fully Qualified Domain Names (FQDNs) as endpoint identifiers more
approach to DNS operations is key during transitions, such as the one complex". Section 3.5 of [RFC2956] further recommends that
to IPv6 that is underway now, stating that "Operational stability of maintaining a stable approach to DNS operations is key during
DNS is paramount, especially during a transition of the network transitions, such as the one to IPv6 that is underway now, and states
layer, and both IPv6 and some network address translation techniques that "Operational stability of DNS is paramount, especially during a
place a heavier burden on DNS." transition of the network layer, and both IPv6 and some network
address translation techniques place a heavier burden on DNS".
4.3.5. Related Considerations 4.3.5. Related Considerations
While techniques such as GLSB and DNS load balancing, which share While techniques such as GSLB and DNS Load Balancing -- which share
much in common with DNS Resolver Whitelisting and are widespread, much in common with DNS Resolver Whitelisting -- are widespread, some
some in the community have raised a range of concerns about the in the community have raised a range of concerns about all of these
practice. Some concerns are specific DNS Resolver Whitelisting practices. Some concerns are specific to DNS Resolver Whitelisting
[WL-Concerns]. Other concerns are not as specific and pertain to the [WL-Concerns]. Other concerns are not as specific and pertain to the
general practice of implementing content location or other network general practice of implementing content location or other network
policy controls in the "middle" of the network in a so-called policy controls in the "middle" of the network, in a so-called
"middlebox" function. Whether such DNS-related functions are really "middlebox" function. Whether such DNS-related functions are really
part of a middlebox is debatable. Nevertheless, implementers should part of a middlebox is debatable. Nevertheless, implementers should
at least be aware of some of the risks of middleboxes, as noted in at least be aware of some of the risks of middleboxes, as noted in
[RFC3724]. A related document, [RFC1958] explains that the state, [RFC3724]. A related document, [RFC1958], explains that configured
policies, and other functions needed in the middle of the network state, policies, and other functions needed in the middle of the
should be minimized as a design goal. In addition, Section 2.16 of network should be minimized as a design goal. In addition,
[RFC3234] makes specific statements concerning modified DNS servers. Section 2.16 of [RFC3234] makes specific statements concerning
[RFC3234] also outlines more general concerns in Section 1.2 about modified DNS servers. Section 1.2 of [RFC3234] also outlines more
the introduction of new failure modes when configuration is no longer general concerns about the introduction of new failure modes when
limited to two ends of a session, so that diagnosis of failures and configuration is no longer limited to two ends of a session, so that
misconfigurations could become more complex. Two additional sources diagnosis of failures and misconfigurations could become more
worth considering are [Tussle] and [Rethinking], in which the authors complex. Two additional sources worth considering are [Tussle] and
note concerns regarding the introduction of new control points (such [Rethinking], in which the authors note concerns regarding the
as in middleboxes), including in the DNS. introduction of new control points (e.g., in middleboxes or in
the DNS).
However, some state, policies, and other functions have always been However, state, policies, and other functions have always been
necessary to enable effective, reliable, and high-quality end-to-end necessary to enable effective, reliable, and high-quality end-to-end
communications on the Internet. In addition, techniques such as communications on the Internet. In addition, the use of GSLB, CDNs,
Global Server Load Balancing, Content Delivery Networking, DNS Load DNS Load Balancing, and Split DNS are not only widely deployed but
Balancing and Split DNS are not only widely deployed but are almost are almost uniformly viewed as essential to the functioning of the
uniformly viewed as essential to the functioning of the Internet and Internet and highly beneficial to the quality of the end-user
highly beneficial to the quality of the end user experience on the experience on the Internet. These techniques have had, and continue
Internet. These techniques have had and continue to have a to have, a beneficial effect on the experience of a wide range of
beneficial effect on the experience of a wide range of Internet Internet applications and protocols. So, while there are valid
applications and protocols. So while there are valid concerns about concerns about implementing policy controls in the "middle" of the
implementing policy controls in the "middle" of the network, or network, or anywhere away from edge hosts, the definition of what
anywhere away from edge hosts, the definition of what constitutes the constitutes the middle and edge of the network is debatable in this
middle and edge of the network is debatable in this case. This is case. This is particularly so given that GSLBs and CDNs facilitate
particularly so given that GSLBs and CDNs facilitate connections from connections from end hosts and the optimal content hosts, and could
end host and the optimal content hosts, and could therefore be therefore be considered a modest and, in many cases, essential
considered a modest and in many cases essential network policy network policy extension of a network's edge, especially in the case
extension of a network's edge, especially in the case of high- of high-service-level domains.
service-level domains.
There may be additional implications for end users that have There may be additional implications for end users that have
configured their hosts to use a third party as their DNS recursive configured their hosts to use a third party as their DNS recursive
resolver, rather than the one(s) provided by their network operator. resolver, rather than the one(s) provided by their network operator.
In such cases, it will be more challenging for a domain using In such cases, it will be more challenging for a domain using
whitelisting to determine the level of IPv6-related impairment when whitelisting to determine the level of IPv6-related impairment when
such third-party DNS recursive resolvers are used, given the wide such third-party DNS recursive resolvers are used, given the wide
variety of end user access networks which may be used and that this variety of end-user access networks that may be used and given that
mix may change in unpredictable ways over time. this mix may change in unpredictable ways over time.
4.4. Implement DNS Blacklisting 4.4. Implementing DNS Blacklisting
With DNS Resolver Whitelisting, DNS recursive resolvers can receive With DNS Resolver Whitelisting, DNS recursive resolvers can receive
AAAA resource records only if they are on the whitelist. DNS AAAA resource records only if they are on the whitelist. DNS
Blacklisting is by contrast the the opposite of that, whereby all DNS Blacklisting is by contrast the opposite of that, whereby all DNS
recursive resolvers can receive AAAA resource records unless they are recursive resolvers can receive AAAA resource records unless they are
on the blacklist. Some implementers of DNS Resolver Whitelisting may on the blacklist. Some implementers of DNS Resolver Whitelisting may
choose to subsequently transition to DNS Blacklisting. It is unclear choose to subsequently transition to DNS Blacklisting. It is not
when and if it may be appropriate for a domain to change from clear when and if it may be appropriate for a domain to change from
whitelisting to blacklisting. Nor is it clear how implementers will whitelisting to blacklisting, nor is it clear how implementers will
judge the network conditions to have changed sufficiently to justify judge that network conditions have changed sufficiently to justify
disabling such controls. disabling such controls.
When a domain uses blacklisting, they are enabling all DNS recursive When a domain uses blacklisting, it is enabling all DNS recursive
resolvers to receive AAAA record responses except for what is resolvers to receive AAAA record responses, except for what is
presumed to be a relatively small number that are on the blacklist. presumed to be a relatively small number that are on the blacklist.
Over time it is likely that the blacklist will become smaller as the Over time, it is likely that the blacklist will become smaller as the
networks associated with the blacklisted DNS recursive resolvers are networks associated with the blacklisted DNS recursive resolvers are
able to meaningfully reduce IPv6-related impairments to some able to meaningfully reduce IPv6-related impairments to some
acceptable level, though it is possible that some networks may never acceptable level, though it is possible that some networks may never
achieve that. DNS Blacklisting is also likely less labor intensive achieve that. DNS Blacklisting is also likely less labor intensive
for a domain than performing DNS Resolver Whitelisting on a manual for a domain than performing DNS Resolver Whitelisting on a manual
basis. This is simply because the domain would presumably be focused basis. This is simply because the domain would presumably be focused
on a smaller number of DNS recursive resolvers with well known IPv6- on a smaller number of DNS recursive resolvers with well-known
related problems. IPv6-related problems.
It is also worth noting that the email industry has a long experience It is also worth noting that the email industry has a long experience
with blacklists and, very generally speaking, blacklists tend to be with blacklists and, very generally speaking, blacklists tend to be
effective and well received when it is easy to discover if an IP effective and well received when it is easy to discover if an IP
address is on a blacklist, if there is a transparent and easily address is on a blacklist, if there is a transparent and easily
understood process for requesting removal from a blacklist, and if understood process for requesting removal from a blacklist, and if
the decision-making criteria for placing a server on a blacklist is the decision-making criteria for placing a server on a blacklist are
transparently disclosed and perceived as fair. However, in contrast transparently disclosed and perceived as fair. However, in contrast
to an email blacklist where a blacklisted host cannot send email to a to an email blacklist where a blacklisted host cannot send email to a
domain at all, with DNS Resolver Whitelisting communications will domain at all, with DNS Resolver Whitelisting, communications will
still occur over IPv4 transport. still occur over IPv4 transport.
4.5. Transition Directly to Native Dual Stack 4.5. Transitioning Directly to Native Dual Stack
As an alternative to adopting any of the aforementioned migration As an alternative to adopting any of the aforementioned migration
tactics, domains can choose to transition to native dual stack tactics, domains can choose to transition to native dual stack
directly by adding native IPv6 capabilities to their network and directly by adding native IPv6 capabilities to their network and
hosts and by publishing AAAA resource records in the DNS for named hosts and by publishing AAAA resource records in the DNS for their
resources within their domain. Of course, a domain can still control named resources. Of course, a domain can still control this
this transition gradually, on a name-by-name basis, by adding native transition gradually, on a name-by-name basis, by adding native IPv6
IPv6 to one name at a time, such as mail.example.com first and to one name at a time, such as mail.example.com first and
www.example.com later. So even a "direct" transition can be www.example.com later. So, even a "direct" transition can be
performed gradually. performed gradually.
It is then up to end users with IPv6-related impairments to discover It is then up to end users with IPv6-related impairments to discover
and fix any applicable impairments. However, the concerns and risks and fix any applicable impairments. However, the concerns and risks
related to traffic volume Section 2.3 should still be considered and related to traffic volume (Section 2.3) should still be considered
managed, since those are not directly related to such impairments. and managed, since those are not directly related to such
Not all content providers (or other domains) may face the challenges impairments. Not all content providers (or other domains) may face
detailed herein or face them to the same degree, since the user base the challenges detailed herein or face them to the same degree, since
of each domain, traffic sources, traffic volumes, and other factors the user base of each domain, traffic sources, traffic volumes, and
obviously varies between domains. other factors obviously vary between domains.
For example, while some content providers have implemented DNS For example, while some content providers have implemented DNS
Resolver Whitelisting (one migration tactic), others have run IPv6 Resolver Whitelisting (one migration tactic), others have run IPv6
experiments whereby they added AAAA resource records and observed and experiments whereby they added AAAA resource records and observed and
measured errors, and then decided not to implement DNS Resolver measured errors, and then decided not to implement DNS Resolver
Whitelisting [Heise]. A more widespread such experiment was World Whitelisting [Heise]. A more widespread example of such an
IPv6 Day [W6D], sponsored by the Internet Society, on June 8, 2011. experiment was World IPv6 Day [W6D], sponsored by the Internet
This was a unique opportunity for hundreds of domains to add AAAA Society, on June 8, 2011. This was a unique opportunity for hundreds
resource records to the DNS without using DNS Resolver Whitelisting, of domains to add AAAA resource records to the DNS without using DNS
all at the same time. Some of the participating domains chose to Resolver Whitelisting, all at the same time. Some of the
leave AAAA resource records in place following the experiment based participating domains chose to leave AAAA resource records in place
on their experiences. following the experiment based on their experiences.
Content providers can run their own independent experiments in the Content providers can run their own independent experiments in the
future, adding AAAA resource records for a brief period of time future, adding AAAA resource records for a brief period of time
(minutes, hours, or days), and then analyzing any impacts or effects (minutes, hours, or days), and then analyzing any impacts or effects
on traffic and the experience of end users. They can also simply on traffic and the experience of end users. They can also simply
turn on IPv6 for their domain, which may be easier when the turn on IPv6 for their domain, which may be easier when the
transition does not involve a high-service-level domain. transition does not involve a high-service-level domain.
5. Potential Implementation Phases 5. Potential Implementation Phases
These usefulness of each tactic in Section 4, and the associated pros The usefulness of each tactic in Section 4, and the associated pros
and cons associated with each tactic, is relative to each potential and cons associated with each tactic, are relative to each potential
implementer and will therefore vary from one implementer to another. implementer and will therefore vary from one implementer to another.
As a result, it is not possible to say that the potential phases As a result, it is not possible to say that the potential phases
below make sense for every implementer. This also means that the below make sense for every implementer. This also means that the
duration of each phase will vary between implementers, and even that duration of each phase will vary between implementers, and even that
different implementers may skip some of these phases entirely. different implementers may skip some of these phases entirely.
Finally, the tactics listed in Section 4 are by no means exclusive. Finally, the tactics listed in Section 4 are by no means exclusive.
5.1. No Access to IPv6 Content 5.1. No Access to IPv6 Content
In this phase, a site is accessible only via IPv4 transport. As of In this phase, a site is accessible only via IPv4 transport. At the
the time of this document, the majority of content on the Internet is time of this writing, the majority of content on the Internet is in
in this state and is not accessible natively over IPv6. this state and is not accessible natively over IPv6.
5.2. Using IPv6-Specific Names 5.2. Using IPv6-Specific Names
One possible first step for a domain is to gain experience using a One possible first step for a domain is to gain experience using a
specialized new FQDN, such as ipv6.example.com or specialized new FQDN, such as ipv6.example.com or
www.ipv6.example.com, as explained in Section 4.2. www.ipv6.example.com, as explained in Section 4.2.
5.3. Deploying DNS Resolver Whitelisting Using Manual Processes 5.3. Deploying DNS Resolver Whitelisting Using Manual Processes
As noted in Section 4.3, a domain could begin using DNS Resolver As noted in Section 4.3, a domain could begin using DNS Resolver
Whitelisting as a way to incrementally enable IPv6 access to content. Whitelisting as a way to incrementally enable IPv6 access to content.
This tactic may be especially interesting to high-service-level This tactic may be especially interesting to high-service-level
domains. domains.
5.4. Deploying DNS Resolver Whitelisting Using Automated Processes 5.4. Deploying DNS Resolver Whitelisting Using Automated Processes
For a domain that decides to undertake DNS Resolver Whitelisting on a For a domain that decides to undertake DNS Resolver Whitelisting on a
manual basis, the domain may subsequently move to perform DNS manual basis, the domain may subsequently move to perform DNS
Resolver Whitelisting on an automated basis. This is explained in Resolver Whitelisting on an automated basis. This is explained in
Section 4.3, and can significantly ease any operational burdens Section 4.3, and can significantly ease any operational burdens
relating to a manually-maintained whitelist. related to a manually maintained whitelist.
5.5. Turning Off DNS Resolver Whitelisting 5.5. Turning Off DNS Resolver Whitelisting
Domains that choose to implement DNS Resolver Whitelisting generally Domains that choose to implement DNS Resolver Whitelisting generally
consider it to be a temporary measure. Many implementers have consider it to be a temporary measure. Many implementers have
announced that they plan to permanently turn off DNS Resolver announced that they plan to permanently turn off DNS Resolver
Whitelisting beginning on the date of the World IPv6 Launch, on June Whitelisting beginning on the date of the World IPv6 Launch, on
6, 2012 [World IPv6 Launch]. For any implementers that do not turn June 6, 2012 [World-IPv6-Launch]. For any implementers that do not
off DNS Resolver Whitelisting at that time, it may be unclear how turn off DNS Resolver Whitelisting at that time, it may be unclear
each and every one will judge when the network conditions to have how each and every one will judge the point in time that network
changed sufficiently to justify turning off DNS Resolver conditions have changed sufficiently to justify turning off DNS
Whitelisting. That being said, it is clear that the extent of IPv6 Resolver Whitelisting. That being said, it is clear that the extent
deployment to end users in networks, the state of IPv6-related of IPv6 deployment to end users in networks, the state of IPv6-
impairment, and the maturity of IPv6 operations are all important related impairment, and the maturity of IPv6 operations are all
factors. Any such implementers may wish to take into consideration important factors. Any such implementers may wish to take into
that, as a practical matter, it will be impossible to get to a point consideration that, as a practical matter, it will be impossible to
where there are no longer any IPv6-related impairments; some get to a point where there are no longer any IPv6-related
reasonably small number of hosts will inevitably be left behind as impairments; some reasonably small number of hosts will inevitably be
end users elect not to upgrade them or as some hosts are incapable of left behind as end users elect not to upgrade them or because some
being upgraded. hosts are incapable of being upgraded.
5.6. Deploying DNS Blacklisting 5.6. Deploying DNS Blacklisting
Regardless of whether a domain has first implemented DNS Resolver Regardless of whether a domain has first implemented DNS Resolver
Whitelisting or has never done so, DNS Blacklisting as described in 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 Section 4.4, may be of interest. This may be at the point in time
when domains wish to make their content widely available over IPv6 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 but still wish to protect end users of a few networks with well-known
IPv6 limitations from having a bad end user experience. IPv6 limitations from having a bad end-user experience.
5.7. Fully Dual-Stack Content 5.7. Fully Dual-Stack Content
A domain can arrive at this phase either following the use of a A domain can arrive at this phase by either following the use of a
previous IPv6 migration tactic, or they may go directly to this point previous IPv6 migration tactic or going directly to this point, as
as noted in Section 4.5. In this phase the site's content has been 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 made natively accessible via both IPv4 and IPv6 for all end users on
the Internet, or at least without the use of any other IPv6 migration the Internet, or at least without the use of any other IPv6 migration
tactic. tactic.
6. Other Considerations 6. Other Considerations
6.1. Security Considerations 6.1. Security Considerations
If DNS Resolver Whitelisting is adopted, as noted in Section 4.3, If DNS Resolver Whitelisting is adopted, as noted in Section 4.3,
then organizations which apply DNS Resolver Whitelisting policies in then organizations that apply DNS Resolver Whitelisting policies in
their authoritative servers should have procedures and systems which their authoritative servers should have procedures and systems that
do not allow unauthorized parties to modify the whitelist or do not allow unauthorized parties to modify the whitelist (or
blacklist, just as all configuration settings for name servers should blacklist), just as all configuration settings for name servers
be protected by appropriate procedures and systems. Such should be protected by appropriate procedures and systems. Such
unauthorized additions or removals from the whitelist can be unauthorized additions or removals from the whitelist (or blacklist)
damaging, causing content providers and/or network operators to incur can be damaging, causing content providers and/or network operators
support costs resulting from end user and/or customer contacts, as to incur support costs resulting from end-user and/or customer
well as causing potential dramatic and disruptive swings in traffic contacts, as well as causing potential dramatic and disruptive swings
from IPv6 to IPv4 or vice versa. in traffic from IPv6 to IPv4 or vice versa.
DNS security extensions defined in [RFC4033], [RFC4034], and DNS Security Extensions (DNSSEC) as defined in [RFC4033], [RFC4034],
[RFC4035] use cryptographic digital signatures to provide origin and [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 Resolver 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. So even though an authoritative DNS server will is not altered. So, even though an authoritative DNS server will
selectively return AAAA resource records or a non-existence response, selectively return AAAA resource records or a non-existence response,
both types of response will be signed and will validate. In both types of responses will be signed and will validate. In
practical terms this means that two separate views or zones are used, practical terms, this means that two separate views or zones are
each of which is signed, so that whether or not particular resource used, each of which is signed, so that whether or not particular
records exist, the existence or non-existence of the record can still resource records exist, the existence or non-existence of the record
be validated using DNSSEC. As a result, there should not be any can still be validated using DNSSEC. As a result, there should not
negative impact on DNSSEC for those domains that have implemented be any negative impact on DNSSEC for those domains that have
both DNSSEC on their Security-Aware Authoritative Name Servers and implemented DNSSEC on their Security-Aware Authoritative Name Servers
also implemented DNS Resolver Whitelisting. As for any party and also implemented DNS Resolver Whitelisting. As for any party
implementing DNSSEC of course, such domains should ensure that implementing DNSSEC, such domains should of course ensure that
resource records are being appropriately and reliably signed and resource records are being appropriately and reliably signed and are
consistent with the response being returned. consistent with the response being returned.
However, network operators that run DNS recursive resolvers should be However, network operators that run DNS recursive resolvers should be
careful not to modify the responses received from authoritative DNS careful not to modify the responses received from authoritative DNS
servers. It is possible that some networks may attempt to do so in servers. It is possible that some networks may attempt to do so in
order to prevent AAAA record responses from going to end user hosts, order to prevent AAAA record responses from going to end-user hosts,
due to some IPv6-related impairment or other lack of IPv6 readiness due to some IPv6-related impairment or other lack of IPv6 readiness
with that network. But when a network operates a Security-Aware within that network. But when a network operates a Security-Aware
Resolver, modifying or suppressing AAAA resource records for a Resolver, modifying or suppressing AAAA resource records for a
DNSSEC-signed domain could break the chain of trust established with DNSSEC-signed domain could break the chain of trust established with
DNSSEC. DNSSEC.
6.2. Privacy Considerations 6.2. Privacy Considerations
As noted in Section 4.1, there is a benefit in sharing IPv6-related As noted in Section 4.1, there is a benefit in sharing IPv6-related
impairment statistics within the Internet community over time. Any impairment statistics within the Internet community over time. Any
statistics that are shared or disclosed publicly should be aggregate statistics that are shared or disclosed publicly should be aggregate
statistics, such as "the domain example.com has observed an average statistics, such as "the domain example.com has observed an average
daily impairment rate of 0.05% in September 2011, down from 0.15% in daily impairment rate of 0.05% in September 2011, down from 0.15% in
January 2011". They should not include information that can directly January 2011". They should not include information that can directly
or indirectly identify individuals, such as names or email addresses. or indirectly identify individuals, such as names or email addresses.
Sharing only aggregate data can help protect end user privacy and any Sharing only aggregate data can help protect end-user privacy and any
information which may be proprietary to a domain. information that may be proprietary to a domain.
In addition, there are often methods to detect IPv6-related In addition, there are often methods to detect IPv6-related
impairments for a specific end user, such as running an IPv6 test 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 when an end user visits the website of a particular domain. Should a
domain then choose to automatically communicate the facts of an domain then choose to automatically communicate the facts of an
impairment to an affected user, there are likely no direct privacy impairment to an affected user, there are likely no direct privacy
considerations. However, if the domain then decided to share considerations. However, if the domain then decides to share
information concerning that particular end user with that user's information concerning that particular end user with that user's
network operator or another third party, then the domain may wish to network operator or another third party, then the domain may wish to
consider advising the end user of this and seeking to obtain the end consider advising the end user of this and seeking to obtain the end-
user's consent to share such information. user's consent to share such information.
Appropriate guidelines for any information sharing likely varies by Appropriate guidelines for any information-sharing likely varies by
country and/or legal jurisdiction. Domains should consider any country and/or legal jurisdiction. Domains should consider any
potential privacy issues when considering what information can be potential privacy issues when considering what information can be
shared. If a domain does publish or share detailed impairment shared. If a domain does publish or share detailed impairment
statistics, they would be well advised to avoid identifying statistics, it would be well advised to avoid identifying individual
individual hosts or users. hosts or users.
Finally, if a domain chooses to contact end userd directly concerning Finally, if a domain chooses to contact end users directly concerning
their IPv6 impairments, that domain should ensure that such their IPv6 impairments, that domain should ensure that such
communication is permissible under any applicable privacy policies of communication is permissible under any applicable privacy policies of
the domain or its websites. the domain or its websites.
6.3. Considerations with Poor IPv4 and Good IPv6 Transport 6.3. Considerations with Poor IPv4 and Good IPv6 Transport
There are situations where the differing quality of the IPv4 and IPv6 There are situations where the differing quality of the IPv4 and IPv6
connectivity of an end user could cause complications in accessing connectivity of an end user could cause complications in accessing
content when a domain is using an IPv6 migration tactic. While today content when a domain is using an IPv6 migration tactic. While today
most end users' IPv4 connectivity is typically superior to IPv6 most end users' IPv4 connectivity is typically superior to IPv6
connectivity (if such connectivity exists at all), there could be connectivity (if such connectivity exists at all), there could be
implications when the reverse is true and and end user has markedly implications when the reverse is true and an end user has markedly
superior IPv6 connectivity as compared to IPv4. This is not a superior IPv6 connectivity as compared to IPv4. This is not a
theoretical situation; it has been observed by at least one major theoretical situation; it has been observed by at least one major
content provider. content provider.
For example, in one possible scenario, a user is issued IPv6 For example, in one possible scenario, a user is issued IPv6
addresses by their ISP and has a home network and devices or addresses by their ISP and has a home network and devices or
operating systems which fully support native IPv6. As a result this operating systems that fully support native IPv6. As a result, this
theoretical user has very good IPv6 connectivity. However, this end theoretical user has very good IPv6 connectivity. However, this end-
user's ISP has exhausted their available pool of unique IPv4 address, user's ISP has exhausted their available pool of unique IPv4
and uses NAT in order to share IPv4 addresses among end users. So addresses, and uses NAT in order to share IPv4 addresses among end
for IPv4 content, the end user must send their IPv4 traffic through users. So, for IPv4 content, the end user must send their IPv4
some additional network element (e.g. large scale NAT, proxy server, traffic through some additional network element (e.g., large-scale
tunnel server). Use of this additional network element might cause NAT, proxy server, tunnel server). Use of this additional network
an end user to experience sub-optimal IPv4 connectivity when certain element might cause an end user to experience sub-optimal IPv4
protocols or applications are used. This user then has good IPv6 connectivity when certain protocols or applications are used. This
connectivity but impaired IPv4 connectivity. As a result, the user's user then has good IPv6 connectivity but impaired IPv4 connectivity.
poor IPv4 connectivity situation could potentially be exacerbated As a result, the user's poor IPv4 connectivity situation could
when accessing a domain which is using a migration tactic that causes potentially be exacerbated when accessing a domain that is using a
this user to only be able to access content over IPv4 transport for migration tactic that causes this user to only be able to access
whatever reason. content over IPv4 transport for whatever reason.
Should this sort of situation become widespread in the future, a 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 domain may wish to take it into account when deciding how and when to
transition content to IPv6. transition content to IPv6.
6.4. IANA Considerations
There are no IANA considerations in this document.
7. 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
- Yiu Lee
- Tom Klieber - Rich Woundy
- Yiu Lee
- Rich Woundy
8. 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
- Mark Andrews
- Mark Andrews - Jari Arkko
- Fred Baker
- Jari Arkko - Ron Bonica
- Frank Bulk
- Fred Baker - Brian Carpenter
- Lorenzo Colitti
- Ron Bonica - Alissa Cooper
- Frank Bulk - Dave Crocker
- Ralph Droms
- Brian Carpenter - Wesley Eddy
- J.D. Falk
- Lorenzo Colitti - Adrian Farrel
- Stephen Farrell
- Alissa Cooper - Tony Finch
- Karsten Fleischhauer
- Dave Crocker - Igor Gashinsky
- Wesley George
- Ralph Droms - Philip Homburg
- Jerry Huang
- Wesley Eddy - Ray Hunter
- Joel Jaeggli
- J.D. Falk - Erik Kline
- Suresh Krishnan
- Adrian Farrel - Victor Kuarsingh
- Marc Lampo
- Stephen Farrell - Donn Lee
- John Leslie
- Tony Finch - John Mann
- Danny McPherson
- Karsten Fleischhauer - Milo Medin
- Martin Millnert
- Igor Gashinsky - Russ Mundy
- Thomas Narten
- Wesley George - Pekka Savola
- Robert Sparks
- Philip Homburg - Barbara Stark
- Joe Touch
- Jerry Huang - Hannes Tschofenig
- Tina Tsou
- Ray Hunter - Members of the Broadband Internet Technical Advisory Group
(BITAG)
- Joel Jaeggli
- Erik Kline
- Suresh Krishnan
- Victor Kuarsingh
- Marc Lampo
- Donn Lee
- John Leslie
- John Mann
- Danny McPherson
- Milo Medin
- Martin Millnert
- Russ Mundy
- Thomas Narten
- Pekka Savola
- Robert Sparks
- Barbara Stark
- Joe Touch
- Hannes Tschofenig
- Tina Tsou
- Members of the Broadband Internet Technical Advisory Group (BITAG)
9. References 9. References
9.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., de Groot, G.,
E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", [RFC1958] Carpenter, B., Ed., "Architectural Principles of the
RFC 1958, June 1996. Internet", RFC 1958, June 1996.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000. February 2000.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", [RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop",
RFC 2956, October 2000. RFC 2956, October 2000.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002. Issues", RFC 3234, February 2002.
[RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of
and the Future of End-to-End: Reflections on the Evolution the Middle and the Future of End-to-End: Reflections on
of the Internet Architecture", RFC 3724, March 2004. the Evolution of the Internet Architecture", RFC 3724,
March 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
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.
9.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,
www.h-online.com/features/ <http://www.h-online.com/features/
The-big-IPv6-experiment-1165042.html>. The-big-IPv6-experiment-1165042.html>.
[I-D.ietf-v6ops-happy-eyeballs]
Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-07
(work in progress), December 2011.
[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,
<http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>. <http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>.
[IPv6-Brokenness] [IPv6-Brokenness]
Anderson, T., "Measuring and Combating IPv6 Brokenness", Anderson, T., "Measuring and Combating IPv6 Brokenness",
Reseaux IP Europeens (RIPE) 61st Meeting, November 2010, Reseaux IP Europeens (RIPE) 61st Meeting, November 2010,
<http://ripe61.ripe.net/presentations/162-ripe61.pdf>. <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[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", Proceedings of
Active Management (PAM) Conference 2010, April 2010, the 11th International Conference on Passive and Active
<http://www.google.com/research/pubs/archive/36240.pdf>. Measurement (PAM 2010), Springer, Lecture Notes in
Computer Science, 2010, Volume 6032, Passive and Active
Measurement, Pages 141-150.
[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,
ttp://www.networkworld.com/news/2010/ <http://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>.
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
RFC 6343, August 2011. RFC 6343, August 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
[Rethinking] [Rethinking]
Blumenthal, M. and D. Clark, "Rethinking the design of the Blumenthal, M. and D. Clark, "Rethinking the Design of the
Internet: The end to end arguments vs. the brave new Internet: The End-to-End Arguments vs. the Brave New
world", ACM Transactions on Internet Technology Volume 1, World", ACM Transactions on Internet Technology, Volume 1,
Number 1, Pages 70-109, August 2001, <http:// Number 1, Pages 70-109, August 2001,
dspace.mit.edu/bitstream/handle/1721.1/1519/ <http://groups.csail.mit.edu/ana/Publications/PubPDFs/
TPRC_Clark_Blumenthal.pdf>. Rethinking the design of the internet2001.pdf>.
[Tussle] Braden, R., Clark, D., Sollins, K., and J. Wroclawski, [Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden,
"Tussle in Cyberspace: Defining Tomorrow's Internet", "Tussle in Cyberspace: Defining Tomorrow's Internet",
Proceedings of ACM Sigcomm 2002, August 2002, <http:// Proceedings of ACM Sigcomm 2002, August 2002,
groups.csail.mit.edu/ana/Publications/PubPDFs/ <http://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 Resolver Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting -
Whitelisting - Could It Hinder IPv6 Adoption?", Could It Hinder IPv6 Adoption?", ISOC (Internet Society)
ISOC Internet Society IPv6 Deployment Workshop, IPv6 Deployment Workshop, April 2010,
April 2010, <http://www.comcast6.net/ <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 IPv6
Implementors Conference, June 2010, <http:// Implementors Conference, June 2010,
sites.google.com/site/ipv6implementors/2010/agenda/ <http://sites.google.com/site/ipv6implementors/2010/
IPv6_Whitelist_Operations.pdf>. agenda/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>.
[World IPv6 Launch] [World-IPv6-Launch]
The Internet Society, "World IPv6 Launch Website", 2012, The Internet Society, "World IPv6 Launch Website",
<http://www.worldipv6launch.org/>. June 2012, <http://www.worldipv6launch.org/>.
Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication]
-11: Minor update to one item to resolve a question from IETF Last
Call (same one as -09 and -10)
-10: Minor update to one sentence to resolve a question from IETF
Last Call
-09: Minor updates to resolve questions in IETF Last Call
-08: Minor updates from v6ops WGLC
-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
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
mailing list. Revised the Abstract and Intro as recommended by Tony
Finch. Per Dave Crocker, updated the diagram following remedial
ASCII art assistance, added a reference regarding IPv4-brokenness
statistics. Removed Open Issue #1, after validating proper reference
placement and removing NAT444 reference. Updates per Ralph Droms'
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
merged it. Closed Open Issue #5, per Dave Crocker and John Leslie,
simplifying the document more, consolidating sections, etc. Closed
Open Issue #6. Closed Open Issue #7, per Jari Arkko, ensuring all
motivations are accounted for, etc. Closed Open Issue #9, per
Stephen Farrell, re. World IPv6 Day (retained reference but re-
worded those sections). Removed the happy-eyeballs reference since
this was an informative reference and the draft could be delayed due
to that dependency. ALL OPEN ITEMS ARE NOW CLOSED.
-05: Additional changes requested by Stephen Farrell intended to
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.
-04: Made changes based on feedback received during IESG review.
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,
change the title of 6.2 from "Likely Deployment Scenarios" to
"General Implementation Variations", as well as changes to improve
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,
to make clear in Section 2 that whitelisting is done on authoritative
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
Eddy, updated Section 7.3.2 to address operational concerns and re-
titled Section 8 from "Solutions" to "General Implementation
Variations". Per Stephen Farrell, added text to Section 8.1 and
Section 6.2, with a reference to 8.1 in the Introduction, to say that
universal deployment is considered harmful. Added text to Section 2
per the v6ops list discussion to indicate that whitelisting is
independent of the IP address family of the end user host or
resolver. There was also discussion with the IESG to change the name
of the draft to IPv6 DNS Resolver Whitelisting or IPv6 AAAA DNS
Resolver Whitelisting (as suggested originally by John Mann) but
there was not a strong consensus to do so. Added a new section 7.7,
at the suggestion of Philip Homburg. Per Joe Touch, added a new
Section 8.4 on blacklisting as an alternative, mentioned blacklisting
in Section 2, added a new Section 7.8 on the use of 3rd party
resolvers, and updated section 6.2 to change Internet Draft documents
to RFCs. Minor changes from Barbara Stark. Changes to the Privacy
Considerations section based on feedback from Alissa Cooper. Changed
"highly-trafficked" domains to "high-traffic" domains. Per Bernard
Aboba, added text noting that a whitelist may be manually or
automatically updated, contrasting whitelisting with blacklisting,
reorganized Section 3, added a note on multiple clearinghouses being
possible. Per Pekka Savola, added a note regarding multiple
clearinghouses to the Ad Hoc section, corrected grammar in Section
7.5, reworded Section 7.3.7, corrected the year in a RIPE reference
citation. Also incorporated general feedback from the Broadband
Internet Technical Advisory Group. Per Jari Arkko, simplified the
introduction to the Implications section, played down possible
impacts on RFC 4213, added caveats to Section 8.3.2 on the utility of
transition names, re-wrote Section 9. Updated the Abstract and
Introduction, per errors noted by Tony Finch. Updated the Security
Considerations based on feedback from Russ Mundy. Per Ray Hunter,
added some text to the De-Whitelisting implications section regarding
effects on networks of switching from IPv6 to IPv4. Updated 7.3.1
per additional feedback from Karsten Fleischhauer. Per Dave Crocker,
added a complete description of the practice to the Abstract, added a
note to the Introduction that the operational impacts are
particularly acute at scale, added text to Intro to make clear this
practice affects all protocols and not just HTTP, added a new query/
response diagram, added text to the Abstract and Introduction noting
that this is an IPv6 transition mechanism, and too many other changes
to list.
-03: Several changes suggested by Joel Jaeggli at the end of WGLC.
This involved swapping the order of Section 6.1 and 6.2, among other
changes to make the document more readable, understandable, and
tonally balanced. As suggested by Karsten Fleischhauer, added a
reference to RFC 4213 in Section 7.1, as well as other suggestions to
that section. As suggested by Tina Tsou, made some changes to the
DNSSEC section regarding signing. As suggested by Suresh Krishnan,
made several changes to improve various sections of the document,
such as adding an alternative concerning the use of ipv6.domain,
improving the system logic section, and shortening the reference
titles. As suggested by Thomas Narten, added some text regarding the
imperfection of making judgements as to end user host impairments
based upon the DNS recursive resolver's IP and/or network. Finally,
made sure that variations in the use of 'records' and 'resource
records' was updated to 'resource records' for uniformity and to
avoid confusion.
-02: Called for and closed out feedback on dnsop and v6ops mailing
lists. Closed out open feedback items from IETF 79. Cleared I-D
nits issues, added a section on whether or not this is recommended,
made language less company-specific based on feedback from Martin
Millnert, Wes George, and Victor Kuarsingh. Also mentioned World
IPv6 Day per Wes George's suggestion. Added references to the ISOC
World IPv6 Day and the Heise.de test at the suggestion of Jerry
Huang, as well as an additional implication in 7.3.7. Made any
speculation on IPv4 impairment noted explicitly as such, per feedback
from Martin Millnert. Added a reference to DNS SRV in the load
balancing section. Added various other references. Numerous changes
suggested by John Brzozowski in several sections, to clean up the
document. Moved up the section on why whitelisting is performed to
make the document flow more logically. Added a note in the ad hoc
deployment scenario explaining that a deployment may be temporary,
and including more of the perceived benefits of this tactic. Added a
Privacy Considerations section to address end-user detection and
communication.
-01: Incorporated feedback received from Brian Carpenter (from 10/19/
2010), Frank Bulk (from 11/8/2010), and Erik Kline (from 10/1/2010).
Also added an informative reference at the suggestion of Wes George
(from from 10/22/2010). Closed out numerous editorial notes, and
made a variety of other changes.
-00: First version published as a v6ops WG draft. The preceding
individual draft was
draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE
that no changes have been made yet based on WG and list feedback.
These are in queue for a -01 update.
Appendix B. Open Issues
[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
URI: http://www.comcast.com URI: http://www.comcast.com
 End of changes. 123 change blocks. 
712 lines changed or deleted 514 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/