draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07.txt   draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt 
IPv6 Operations J. Livingood IPv6 Operations J. Livingood
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Informational October 14, 2011 Intended status: Informational November 22, 2011
Expires: April 16, 2012 Expires: May 25, 2012
Considerations for Transitioning Content to IPv6 Considerations for Transitioning Content to IPv6
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08
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 transition challenges involved in the transition to IPv6, potential migration
techniques, possible transition phases, and other considerations. tactics, possible migration phases, and other considerations. The
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 This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2012. This Internet-Draft will expire on May 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 Transition Techniques . . . . . . . . . . . . . . . 6 4. Potential Migration Tactics . . . . . . . . . . . . . . . . . 6
4.1. Solve Current End User IPv6 Impairments . . . . . . . . . 7 4.1. Solve Current End User IPv6 Impairments . . . . . . . . . 7
4.2. Use IPv6 Transition Names . . . . . . . . . . . . . . . . 8 4.2. Use IPv6-Specicic Names . . . . . . . . . . . . . . . . . 7
4.3. Implement DNS Resolver Whitelisting . . . . . . . . . . . 8 4.3. Implement DNS Resolver Whitelisting . . . . . . . . . . . 8
4.3.1. How DNS Resolver Whitelisting Works . . . . . . . . . 10 4.3.1. How DNS Resolver Whitelisting Works . . . . . . . . . 10
4.3.2. Similarities to Content Delivery Networks and 4.3.2. Similarities to Content Delivery Networks and
Global Server Load Balancing . . . . . . . . . . . . . 14 Global Server Load Balancing . . . . . . . . . . . . . 15
4.3.3. Similarities to DNS Load Balancing . . . . . . . . . . 14 4.3.3. Similarities to DNS Load Balancing . . . . . . . . . . 15
4.3.4. Similarities to Split DNS . . . . . . . . . . . . . . 14 4.3.4. Similarities to Split DNS . . . . . . . . . . . . . . 15
4.3.5. Related Considerations . . . . . . . . . . . . . . . . 15 4.3.5. Related Considerations . . . . . . . . . . . . . . . . 16
4.4. Implement DNS Blacklisting . . . . . . . . . . . . . . . . 16 4.4. Implement DNS Blacklisting . . . . . . . . . . . . . . . . 17
4.5. Transition Directly to Native Dual Stack . . . . . . . . . 17 4.5. Transition Directly to Native Dual Stack . . . . . . . . . 18
5. Potential Implementation Phases . . . . . . . . . . . . . . . 18 5. Potential Implementation Phases . . . . . . . . . . . . . . . 19
5.1. No Access to IPv6 Content . . . . . . . . . . . . . . . . 18 5.1. No Access to IPv6 Content . . . . . . . . . . . . . . . . 19
5.2. Using IPv6 Transition Names . . . . . . . . . . . . . . . 18 5.2. Using IPv6-Specific Names . . . . . . . . . . . . . . . . 19
5.3. Deploying DNS Resolver Whitelisting Using Manual 5.3. Deploying DNS Resolver Whitelisting Using Manual
Processes . . . . . . . . . . . . . . . . . . . . . . . . 18 Processes . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4. Deploying DNS Resolver Whitelisting Using Automated 5.4. Deploying DNS Resolver Whitelisting Using Automated
Processes . . . . . . . . . . . . . . . . . . . . . . . . 18 Processes . . . . . . . . . . . . . . . . . . . . . . . . 19
5.5. Turning Off DNS Resolver Whitelisting . . . . . . . . . . 18 5.5. Turning Off DNS Resolver Whitelisting . . . . . . . . . . 19
5.6. Deploying DNS Blacklisting . . . . . . . . . . . . . . . . 19 5.6. Deploying DNS Blacklisting . . . . . . . . . . . . . . . . 20
5.7. Fully Dual-Stack Content . . . . . . . . . . . . . . . . . 19 5.7. Fully Dual-Stack Content . . . . . . . . . . . . . . . . . 20
6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.1. Security Considerations . . . . . . . . . . . . . . . . . 19 6.1. Security Considerations . . . . . . . . . . . . . . . . . 20
6.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 20 6.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 21
6.3. Considerations with Poor IPv4 and Good IPv6 Transport . . 21 6.3. Considerations with Poor IPv4 and Good IPv6 Transport . . 22
6.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 21 6.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 23
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . 26 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 28
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 29 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 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-traffic domains"), which have specific described hereinafter as "high-service-level domains"), which have
and unique concerns relating to maintaining a high-quality user specific and unique concerns relating to maintaining a high-quality
experience for all of their users during their transition to IPv6. user experience for all of their users during their transition to
This document explores the challenges involved in the transition to IPv6. This document explores the challenges involved in the
IPv6, potential transition techniques, possible transition phases, transition to IPv6, potential migration tactics, possible migration
and other considerations. Some sections of this document also phases, and other considerations. Some sections of this document
include information about the potential implications of various also include information about the potential implications of various
transition techniques 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
natively dual-stack enabled, which provides native access to all end natively dual-stack enabled, which provides native access to all end
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 end users, which has led to the development of a variety of migration
transition techniques. A first step in understanding various tactics. A first step in understanding various migration tactics is
transition techniques is to first outline the challenges involved in to first outline the challenges involved in moving content to IPv6.
moving content to IPv6.
Implementers of these various transition techniques 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 which pertain to this practice; one of which is
IPv6-related impairment and the other which is the maturity or IPv6-related impairment and the other which is the maturity or
stability of IPv6 transport (and associated network operations) for stability of IPv6 transport (and associated network operations) for
high-traffic domains. Both can negatively affect the experience of high-service-level domains. Both can negatively affect the
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 transition technique, result, while some domains have used an IPv6 migration tactic, others
others have run brief IPv6 experiments and then decided to simply have run brief IPv6 experiments and then decided to simply turn on
turn on IPv6 for the domain without further delay and without using IPv6 for the domain without further delay and without using any
any specialized IPv6 transition techniques [Heise]. Each domain specialized IPv6 migration tactics [Heise]. Each domain should
should therefore consider its specific situation when formulating a therefore consider its specific situation when formulating a plan to
plan to move to IPv6; there is not one approach that will work for move to IPv6; there is not one approach that will work for every
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 that a small fraction of end users had slow
or otherwise impaired access to a given web site with both AAAA and A or otherwise impaired access to a given web site 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].
though more recent measurements indicate this is declining
[Impairment-Tracker].
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, for the users who experience this impairment it has a very access, and the potential solutions [I-D.ietf-v6ops-happy-eyeballs]
[RFC6343], for the users who experience this impairment it has a very
real performance impact. It would impact access to all or most dual real performance impact. It would impact access to all or most dual
stack services to which the user attempts to connect. This negative stack services to which the user attempts to connect. This negative
end user experience can range from somewhat slower than usual access end user experience can range from somewhat slower than usual access
(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.
skipping to change at page 6, line 17 skipping to change at page 6, line 14
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 which 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-traffic noted in Section 2 are addressed, especially for high-service-level
domains. Some high-traffic domains may find the prospect of domains. Some high-service-level domains may find the prospect of
transitioning to IPv6 extremely daunting without having some ability transitioning to IPv6 extremely daunting without having some ability
to address these challenges and to incrementally control their to address these challenges and to incrementally control their
transition to IPv6. Lacking such controls, some domains may choose transition to IPv6. Lacking such controls, some domains may choose
to substantially delay their transition to IPv6. A substantial delay to substantially delay their transition to IPv6. A substantial delay
in content moving to IPv6 could certainly mean there are somewhat in content moving to IPv6 could certainly mean there are somewhat
fewer motivating factors for network operators to deploy IPv6 to end fewer motivating factors for network operators to deploy IPv6 to end
user hosts (though they have many significant motivating factors that user hosts (though they have many significant motivating factors that
are largely independent of content). At the same time, unless are largely independent of content). At the same time, unless
network operators transition to IPv6, there are of course fewer network operators transition to IPv6, there are of course fewer
motivations for domain owners to transition content to IPv6. Without motivations for domain owners to transition content to IPv6. Without
progress in each part of the Internet ecosystem, networks and/or progress in each part of the Internet ecosystem, networks and/or
content sites may delay, postpone, or cease adoption of IPv6, or to content sites may delay, postpone, or cease adoption of IPv6, or to
actively seek alternatives to it. Such alternatives may include the actively seek alternatives to it. Such alternatives may include the
use of multi-layer or large scale network address translation (NAT) use of multi-layer or large scale network address translation (NAT),
techniques, which is not preferred relative to native dual stack. 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 transition techniques, as noted below in Section 4, can potential migration tactics, as noted below in Section 4, can help
help meet these challenges and enable a domain to successfully meet these challenges and enable a domain to successfully transition
transition content and other services to IPv6. content and other services to IPv6.
4. Potential Transition Techniques 4. Potential Migration Tactics
Domains have a wide range of potential techniques at their disposal Domains have a wide range of potential tactics at their disposal that
that may be used to facilitate the transition to IPv6. This section may be used to facilitate the migration to IPv6. This section
includes many of the key techniques that could be used by a domain includes many of the key tactics that could be used by a domain but
but it is by no means an exhaustive or exclusive list. Only a it is by no means an exhaustive or exclusive list. Only a specific
specific domain can judge whether or not a given (or any) transition domain can judge whether or not a given (or any) migration tactic
technique applies to their domain and meets their needs. A domain applies to their domain and meets their needs. A domain may also
may also decide to pursue several of these techniques in parallel. decide to pursue several of these tactics in parallel. Thus, the
Thus, the usefulness of each technique and the associated pros and usefulness of each tactic and the associated pros and cons will vary
cons will vary from domain to domain. from domain to domain.
4.1. Solve Current End User IPv6 Impairments 4.1. Solve 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 their end users.
skipping to change at page 8, line 5 skipping to change at page 7, line 47
tactic is for a domain to collect, track over time, and periodically tactic is for a domain to collect, track over time, and periodically
share with the Internet community the rate of impairment observed for share with the Internet community the rate of impairment observed for
a domain. In any such end user IPv6-related analysis and a domain. In any such end user IPv6-related analysis and
communication, Section 6.2 is worth taking into account. 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 concerns
noted in Section 2.2 or volume-based concerns noted in Section 2.3, noted in Section 2.2 or volume-based concerns noted in Section 2.3,
which should be considered and addressed separately. which should be considered and addressed separately.
4.2. Use IPv6 Transition Names 4.2. Use IPv6-Specicic Names
Another potential transition technique is for a domain to gain Another potential migration tactic is for a domain to gain experience
experience using a special Fully-Qualified Domain Name (FQDN). This using a special Fully-Qualified Domain Name (FQDN). This has become
has become typical for domains beginning the transition to IPv6, typical for domains beginning the transition to IPv6, whereby an
whereby a name such as ipv6.example.com or www.ipv6.example.com is address-family-specific name such as ipv6.example.com or
used. An end user would have to know to use this special transition www.ipv6.example.com is used. An end user would have to know to use
name; it is not the same name used for regular traffic. this special IPv6-specific name; it is not the same name used for
regular traffic.
This special transition name directs traffic to a host or hosts which This special IPv6-specific name directs traffic to a host or hosts
have been enabled for native IPv6 access. In some cases this name which have been enabled for native IPv6 access. In some cases this
may point to hosts which are separate from those used for IPv4 name may point to hosts which are separate from those used for IPv4
traffic (via www.example.com), while in other cases it may point to 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 transition 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 their production network and lab, to deploy
IPv6 functionality into their production network, and to develop and IPv6 functionality into their production network, and to develop and
deploy IPv6-related network and service monitors. It is also an deploy IPv6-related network and service monitors. It is also an
opportunity to add a relatively small amount of IPv6 traffic to opportunity to add a relatively small amount of IPv6 traffic to
ensure that network gear, network interconnects, and IPv6 routing in ensure that network gear, network interconnects, and IPv6 routing in
general is working as expected. general is working as expected.
While using a special transition 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 developing
and maturing IPv6 operations, as noted in Section 2.2, the utility of and maturing IPv6 operations, as noted in Section 2.2, the utility of
the tactic is limited since users must know the transition name, the the tactic is limited since users must know the IPv6-specific name,
traffic volume will be low, and the traffic is unlikely to be the traffic volume will be low, and the traffic is unlikely to be
representative of the general population of end users (they are representative of the general population of end users (they are
likely to be self-selecting early adopters and more technically likely to be self-selecting early adopters and more technically
advanced than average), among other reasons. As a result, any advanced than average), among other reasons. As a result, any
concerns and risks related to traffic volume as noted Section 2.3 concerns and risks related to traffic volume as noted Section 2.3
should still be considered and addressed separately. should still be considered and addressed separately.
4.3. Implement DNS Resolver Whitelisting 4.3. Implement DNS Resolver Whitelisting
Another potential technique, especially when a high traffic domain is Another potential tactic, especially when a high-service-level domain
ready to move beyond an IPv6 transition name, as described in 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 servers 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 technique 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). As a technique, it shares address family to be used (IPv4 or IPv6). It shares similarities
similarities with Content Delivery Networks, Global Server Load with Content Delivery Networks, Global Server Load Balancing, DNS
Balancing, DNS Load Balancing, and Split DNS, as described below in Load Balancing, and Split DNS, as described below in Section 4.3.2,
Section 4.3.2, Section 4.3.3, Section 4.3.4. A few high-traffic Section 4.3.3, Section 4.3.4. A few high-service-level domains have
domains have either implemented DNS Resolver Whitelisting (one of either implemented DNS Resolver Whitelisting (one of many migration
many transition techniques they have used or are using) or are tactics they have used or are using) or are considering doing so
considering doing so [NW-Article-DNS-WL] [WL-Ops]. [NW-Article-DNS-WL] [WL-Ops].
This is a transition technique 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 technique like this is not users, a domain might an incremental tactic like this is not used, a domain might return
return AAAA resource records to any relevant DNS query, meaning the AAAA resource records to any relevant DNS query, meaning the domain
domain could go quickly from no IPv6 traffic to potentially a could go quickly from no IPv6 traffic to potentially a significant
significant amount as soon as the AAAA resource records are amount as soon as the AAAA resource records are published. When DNS
published. When DNS Resolver Whitelisting is implemented, a domain's Resolver Whitelisting is implemented, a domain's authoritative DNS
authoritative DNS will selectively return a AAAA resource record to will selectively return a AAAA resource record to DNS recursive
DNS recursive resolvers on a whitelist maintained by the domain, resolvers on a whitelist maintained by the domain, while returning no
while returning no AAAA resource records to DNS recursive resolvers AAAA resource records to DNS recursive resolvers which are not on
which are not on that whitelist. This tactic will not have a direct that whitelist. This tactic will not have a direct impact on
impact on reducing IPv6-related impairments Section 2.1, though it reducing IPv6-related impairments Section 2.1, though it can help a
can help a domain address operational maturity concerns Section 2.2 domain address operational maturity concerns Section 2.2 and concerns
and concerns and risks related to traffic volume Section 2.3. and risks related to traffic volume Section 2.3. While DNS Resolver
Whitelisting does not solve IPv6-related impairments, it can help a
domain to avoid users that have them. As a result, the tactic
removes their impact in all but the few networks that are
whitelisted. DNS Resolver Whitelisting also allows a website
operator to protect non-IPv6 networks (i.e. networks that do not
support IPv6 and/or do not have plans to do so in the future) from
IPv6-related impairments in their networks. Finally, domains using
this tactic should understand that the onus is on them to ensure that
the servers being whitelisted represent a network that has proven to
their satisfaction that they are IPv6-ready and this will not create
a 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 relating 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 which 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, it is one of the
better available methods at the current time. In addition, given the better available methods at the current time. For example,
current state of global IPv6 deployment, this transition tactic implementers have found that it is possible to measure the level of
allows content providers to selectively expose the availability of IPv6 preparedness of the end users behind any given DNS recursive
their IPv6 services. While opinions in the Internet community resolver by conducting ongoing measurement of the IPv6 preparedness
concerning DNS Resolver Whitelisting are understandably quite varied, of end users querying for one-time-use hostnames and then correlating
there is clear consensus that DNS Resolver Whitelisting can be a the domain's authoritative DNS server logs with their web server
useful tactic a domain may choose to use as they transition their logs. This can help implementers form a good picture of which DNS
services to IPv6. In particular, some high-traffic domains view DNS recursive resolvers have working IPv6 users behind them and which do
Resolver Whitelisting as one of the few practical and low-risk not, what the latency impact of turning on IPv6 for any given DNS
approaches enabling them to transition to IPv6, without which their recursive resolver is, etc. In addition, given the current state of
transition may not take place for some time. However, there is also global IPv6 deployment, this migration tactic allows content
consensus that this practice is workable on a manual basis (see providers to selectively expose the availability of their IPv6
below) only in the short-term and that it will not scale over the services. While opinions in the Internet community concerning DNS
long-term. Thus, some domains may find DNS Resolver Whitelisting a Resolver Whitelisting are understandably quite varied, there is clear
beneficial temporary tactic in their transition to IPv6. consensus that DNS Resolver Whitelisting can be a useful tactic a
domain may choose to use as they transition their services to IPv6.
In particular, some high-service-level domains view DNS Resolver
Whitelisting as one of the few practical and low-risk approaches
enabling them to transition to IPv6, without which their transition
may not take place for some time. However, there is also consensus
that this practice is workable on a manual basis (see below) only in
the short-term and that it will not scale over the long-term. Thus,
some domains may find DNS Resolver Whitelisting a beneficial
temporary tactic in their transition to IPv6.
At the current time, generally speaking, a domain that implements DNS 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) global server load balancing, a
common practice already in use today, as described in Section 4.3.2. common practice already in use today, as described in Section 4.3.2.
Furthermore, in this future phase, networks would be added to and Furthermore, in this future phase, networks would be added to and
removed from a DNS Whitelist automatically, and possibly on a near- removed from a DNS Whitelist automatically, and possibly on a near-
real-time basis. This means, crucially, that networks would no real-time basis. This means, crucially, that networks would no
longer need to apply to be added to a whitelist, which may alleviate longer need to apply to be added to a whitelist, which may alleviate
many of the key concerns that network operators may have with this many of the key concerns that network operators may have with this
technique when it is implemented on a manual basis. tactic when it is 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
skipping to change at page 11, line 10 skipping to change at page 11, line 25
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 it a query. Thus, for a
given operator of a website, such as www.example.com, the domain 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 Section
2.2 of [RFC4213] notes that a stub resolver can make a choice between 2.2 of [RFC4213] notes that a stub resolver can make a choice between
whether to use a AAAA record or A record response, with DNS Resolver whether to use a AAAA record or A record response, with DNS Resolver
Whitelisting the authoritative DNS server can also decide whether to Whitelisting the authoritative DNS server can also decide whether to
return a AAAA record, an A record, or both record types. 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
skipping to change at page 16, line 15 skipping to change at page 17, line 15
highly beneficial to the quality of the end user experience on the highly beneficial to the quality of the end user experience on the
Internet. These techniques have had and continue to have a Internet. These techniques have had and continue to have a
beneficial effect on the experience of a wide range of Internet beneficial effect on the experience of a wide range of Internet
applications and protocols. So while there are valid concerns about applications and protocols. So while there are valid concerns about
implementing policy controls in the "middle" of the network, or implementing policy controls in the "middle" of the network, or
anywhere away from edge hosts, the definition of what constitutes the anywhere away from edge hosts, the definition of what constitutes the
middle and edge of the network is debatable in this case. This is middle and edge of the network is debatable in this case. This is
particularly so given that GSLBs and CDNs facilitate connections from particularly so given that GSLBs and CDNs facilitate connections from
end host and the optimal content hosts, and could therefore be end host and the optimal content hosts, and could therefore be
considered a modest and in many cases essential network policy considered a modest and in many cases essential network policy
extension of a network's edge, especially in the case of high-traffic extension of a network's edge, especially in the case of high-
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 which may be used and that this
mix may change in unpredictable ways over time. mix may change in unpredictable ways over time.
skipping to change at page 17, line 18 skipping to change at page 18, line 18
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 is
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. Transition Directly to Native Dual Stack
As an alternative to adopting any of the aforementioned transition As an alternative to adopting any of the aforementioned migration
techniques, 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 named
resources within their domain. Of course, a domain can still control resources within their domain. Of course, a domain can still control
this transition gradually, on a name-by-name basis, by adding native this transition gradually, on a name-by-name basis, by adding native
IPv6 to one name at a time, such as mail.example.com first and IPv6 to one name at a time, such as mail.example.com first and
www.example.com later. So even a "direct" transition can be 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 and
managed, since those are not directly related to such impairments. managed, since those are not directly related to such impairments.
Not all content providers (or other domains) may face the challenges Not all content providers (or other domains) may face the challenges
detailed herein or face them to the same degree, since the user base detailed herein or face them to the same degree, since the user base
of each domain, traffic sources, traffic volumes, and other factors of each domain, traffic sources, traffic volumes, and other factors
obviously varies between domains. obviously varies between domains.
For example, while some content providers have implemented DNS For example, while some content providers have implemented DNS
Resolver Whitelisting (one transition technique), others have run Resolver Whitelisting (one migration tactic), others have run IPv6
IPv6 experiments whereby they added AAAA resource records and experiments whereby they added AAAA resource records and observed and
observed and measured errors, and then decided not to implement DNS measured errors, and then decided not to implement DNS Resolver
Resolver Whitelisting [Heise]. A more widespread such experiment was Whitelisting [Heise]. A more widespread such experiment was World
World IPv6 Day [W6D], sponsored by the Internet Society, on June 8, IPv6 Day [W6D], sponsored by the Internet Society, on June 8, 2011.
2011. This was a unique opportunity for hundreds of domains to add This was a unique opportunity for hundreds of domains to add AAAA
AAAA resource records to the DNS without using DNS Resolver resource records to the DNS without using DNS Resolver Whitelisting,
Whitelisting, all at the same time. Some of the participating all at the same time. Some of the participating domains chose to
domains chose to leave AAAA resource records in place following the leave AAAA resource records in place following the experiment based
experiment based on their experiences. 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-traffic domain. transition does not involve a high-service-level domain.
5. Potential Implementation Phases 5. Potential Implementation Phases
These usefulness of each technique in Section 4, and the associated These usefulness of each tactic in Section 4, and the associated pros
pros and cons associated with each technique, is relative to each and cons associated with each tactic, is relative to each potential
potential implementer and will therefore vary from one implementer to implementer and will therefore vary from one implementer to another.
another. As a result, it is not possible to say that the potential As a result, it is not possible to say that the potential phases
phases below make sense for every implementer. This also means that below make sense for every implementer. This also means that the
the duration of each phase will vary between implementers, and even duration of each phase will vary between implementers, and even that
that different implementers may skip some of these phases entirely. different implementers may skip some of these phases entirely.
Finally, the techniques listed in Section 4 are by no means Finally, the tactics listed in Section 4 are by no means exclusive.
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. As of
the time of this document, the majority of content on the Internet is the time of this document, the majority of content on the Internet is
in this state and is not accessible natively over IPv6. in this state and is not accessible natively over IPv6.
5.2. Using IPv6 Transition 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-traffic domains. This tactic may be especially interesting to high-service-level
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. relating to a manually-maintained whitelist.
5.5. Turning Off DNS Resolver Whitelisting 5.5. Turning Off DNS Resolver Whitelisting
skipping to change at page 19, line 26 skipping to change at page 20, line 26
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 become interesting. 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 either following the use of a
previous IPv6 transition technique, or they may go directly to this previous IPv6 migration tactic, or they may go directly to this point
point as noted in Section 4.5. In this phase the site's content has as noted in Section 4.5. In this phase the site's content has been
been made natively accessible via both IPv4 and IPv6 for all end made natively accessible via both IPv4 and IPv6 for all end users on
users on the Internet, or at least without the use of any other IPv6 the Internet, or at least without the use of any other IPv6 migration
transition technique. 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 which apply DNS Resolver Whitelisting policies in
their authoritative servers should have procedures and systems which their authoritative servers should have procedures and systems which
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 should
skipping to change at page 20, line 33 skipping to change at page 21, line 33
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 with 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
such statistics probably should be high-level statistics, such as statistics that are shared or disclosed publicly should be aggregate
"the domain example.com has observed an average daily impairment rate statistics, such as "the domain example.com has observed an average
of 0.05% in September 2011, down from 0.15% in January 2011". In daily impairment rate of 0.05% in September 2011, down from 0.15% in
contrast, sharing a list of names and/or email addresses of the end January 2011". They should not include information that can directly
users of a domain with impairments is probably not well advised from or indirectly identify individuals, such as names or email addresses.
a privacy standpoint. Thus, sharing only summary data can help Sharing only aggregate data can help protect end user privacy and any
protect end user privacy and any information which may be proprietary information which may be proprietary to a domain.
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 decided 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 or otherwise seeking to obtain consider advising the end user of this and seeking to obtain the end
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, they would be well advised to avoid identifying
individual hosts or users. individual hosts or users.
Finally, if a domain chooses to contact end userd directly concerning
their IPv6 impairments, that domain should ensure that such
communication is permissable under any applicable privacy policies of
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 transition technique. While content when a domain is using an IPv6 migration tactic. While today
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 and 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 which 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 address,
and uses NAT in order to share IPv4 addresses among end users. So and uses NAT in order to share IPv4 addresses among end users. So
for IPv4 content, the end user must send their IPv4 traffic through for IPv4 content, the end user must send their IPv4 traffic through
some additional network element (e.g. large scale NAT, proxy server, some additional network element (e.g. large scale NAT, proxy server,
tunnel server). Use of this additional network element might cause tunnel server). Use of this additional network element might cause
an end user to experience sub-optimal IPv4 connectivity when certain an end user to experience sub-optimal IPv4 connectivity when certain
protocols or applications are used. This user then has good IPv6 protocols or applications are used. This user then has good IPv6
connectivity but impaired IPv4 connectivity. As a result, the user's connectivity but impaired IPv4 connectivity. As a result, the user's
poor IPv4 connectivity situation could potentially be exacerbated poor IPv4 connectivity situation could potentially be exacerbated
when accessing a domain which is using a transition technique that when accessing a domain which is using a migration tactic that causes
causes this user to only be able to access content over IPv4 this user to only be able to access content over IPv4 transport for
transport for whatever reason. 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 6.4. IANA Considerations
There are no IANA considerations in this document. There are no IANA considerations in this document.
7. Contributors 7. Contributors
skipping to change at page 25, line 23 skipping to change at page 26, line 31
[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, <http://
www.h-online.com/features/ 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-05
(work in progress), October 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", Passive and
Active Management (PAM) Conference 2010, April 2010, Active Management (PAM) Conference 2010, April 2010,
<http://www.google.com/research/pubs/archive/36240.pdf>. <http://www.google.com/research/pubs/archive/36240.pdf>.
[Impairment-Tracker]
Anderson, T., "IPv6 dual-stack client loss in Norway",
Website , May 2011, <http://www.fud.no/ipv6/>.
[NW-Article-DNS-WL] [NW-Article-DNS-WL]
Marsan, C., "Google, Microsoft, Netflix in talks to create Marsan, C., "Google, Microsoft, Netflix in talks to create
shared list of IPv6 users", Network World , March 2010, <h shared list of IPv6 users", Network World , March 2010, <h
ttp://www.networkworld.com/news/2010/ ttp://www.networkworld.com/news/2010/
032610-dns-ipv6-whitelist.html>. 032610-dns-ipv6-whitelist.html>.
[NW-Article-DNSOP] [NW-Article-DNSOP]
Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", Marsan, C., "Yahoo proposes 'really ugly hack' to DNS",
Network World , March 2010, <http://www.networkworld.com/ Network World , March 2010, <http://www.networkworld.com/
news/2010/032610-yahoo-dns.html>. news/2010/032610-yahoo-dns.html>.
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
RFC 6343, August 2011.
[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, <http://
dspace.mit.edu/bitstream/handle/1721.1/1519/ dspace.mit.edu/bitstream/handle/1721.1/1519/
TPRC_Clark_Blumenthal.pdf>. TPRC_Clark_Blumenthal.pdf>.
[Tussle] Braden, R., Clark, D., Sollins, K., and J. Wroclawski, [Tussle] Braden, R., Clark, D., Sollins, K., and J. Wroclawski,
"Tussle in Cyberspace: Defining Tomorrow's Internet", "Tussle in Cyberspace: Defining Tomorrow's Internet",
skipping to change at page 26, line 47 skipping to change at page 28, line 11
[Wild-Resolvers] [Wild-Resolvers]
Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig, Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig,
"Comparing DNS Resolvers in the Wild", ACM Sigcomm "Comparing DNS Resolvers in the Wild", ACM Sigcomm
Internet Measurement Conference 2010, November 2010, Internet Measurement Conference 2010, November 2010,
<http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>. <http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.
Appendix A. Document Change Log Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication] [RFC Editor: This section is to be removed before publication]
-08: Minor updates from v6ops WGLC
-07: Significant re-write based on feedback from Jari Arkko, Joel -07: Significant re-write based on feedback from Jari Arkko, Joel
Jaeggli, Fred Baker, Igor Gashinsky, Donn Lee, Lorenzo Colitti, and Jaeggli, Fred Baker, Igor Gashinsky, Donn Lee, Lorenzo Colitti, and
Erik Kline. Erik Kline.
-06: Removed the Open Issue #8 concerning the document name, at the -06: Removed the Open Issue #8 concerning the document name, at the
direction of Joel Jaeggli. Removed Open Issue #2 from J.D. Falk and direction of Joel Jaeggli. Removed Open Issue #2 from J.D. Falk and
removed Open Issue #3 from Ray Hunter, as confirmed on the v6ops WG removed Open Issue #3 from Ray Hunter, as confirmed on the v6ops WG
mailing list. Revised the Abstract and Intro as recommended by Tony mailing list. Revised the Abstract and Intro as recommended by Tony
Finch. Per Dave Crocker, updated the diagram following remedial Finch. Per Dave Crocker, updated the diagram following remedial
ASCII art assistance, added a reference regarding IPv4-brokenness ASCII art assistance, added a reference regarding IPv4-brokenness
 End of changes. 53 change blocks. 
184 lines changed or deleted 213 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/