IPv6 Operations                                             J. Livingood
Internet-Draft                                                   Comcast
Intended status: Informational                              June 8,                          October 14, 2011
Expires: December 10, 2011 April 16, 2012

            Considerations for Transitioning Content to IPv6 AAAA DNS Whitelisting Implications
         draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06
         draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07

Abstract

   This document describes considerations for the practice and implications transition of whitelisting
   DNS recursive resolvers in order end user
   content on the Internet to limit AAAA resource record
   responses (which contain IPv6 addresses) sent by authoritative DNS
   servers.  This IPv6.  While this is an IPv6 transition mechanism used by domains as a
   method for incrementally transitioning inbound traffic tailored to a domain
   from IPv4 address
   end user content, which is typically web-based, many aspects of this
   document may be more broadly applicable to the transition to IPv6 transport. of
   other applications and services.  This document explores the
   challenges involved in the transition to IPv6, potential transition
   techniques, possible transition phases, and other considerations.
   The audience for this document is the Internet community generally,
   particularly IPv6 implementers.

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
   Task Force (IETF).  Note that other groups may also distribute
   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 10, 2011. April 16, 2012.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  How DNS Whitelisting Works  Challenges When Transitioning Content to IPv6  . . . . . . . .  4
     2.1.  IPv6-Related Impairment  . . . . . . . . . .  5
     2.1.  Description of the Operation of DNS Whitelisting . . . . .  6
     2.2.  Comparison with Blacklisting . .  5
     2.2.  Operational Maturity Concerns  . . . . . . . . . . . . .  9
   3.  Similarities to Other DNS Operations .  5
     2.3.  Volume-Based Concerns  . . . . . . . . . . . .  9
     3.1.  Similarities to Split DNS . . . . . .  5
   3.  IPv6 Adoption Implications . . . . . . . . . .  9
     3.2.  Similarities to DNS Load Balancing . . . . . . . .  6
   4.  Potential Transition Techniques  . . . . . 10
   4.  What Problems Are Implementers Trying To Solve? . . . . . . . 10
     4.1.  Volume-Based Concerns . . .  6
     4.1.  Solve Current End User IPv6 Impairments  . . . . . . . . .  7
     4.2.  Use IPv6 Transition Names  . . . . . . 11
     4.2.  IPv6-Related Impairment . . . . . . . . . .  8
     4.3.  Implement DNS Resolver Whitelisting  . . . . . . . 11
     4.3.  Free Versus Subscription Services . . . .  8
       4.3.1.  How DNS Resolver Whitelisting Works  . . . . . . . . 13
   5.  General Implementation Variations . 10
       4.3.2.  Similarities to Content Delivery Networks and
               Global Server Load Balancing . . . . . . . . . . . . . 13
     5.1.  Implement 14
       4.3.3.  Similarities to DNS Whitelisting Universally Load Balancing . . . . . . . . . . 13
     5.2.  Implement 14
       4.3.4.  Similarities to Split DNS Whitelisting On An Ad Hoc Basis  . . . . . . 14
     5.3.  Do Not Implement DNS Whitelisting . . . . . . . . 14
       4.3.5.  Related Considerations . . . . 14
       5.3.1.  Solve Current End User IPv6 Impairments . . . . . . . 14
       5.3.2.  Gain Experience Using IPv6 Transition Names . . . . . 15
       5.3.3.
     4.4.  Implement DNS Blacklisting . . . . . . . . . . . . . . 15
   6.  Concerns Regarding DNS Whitelisting  . . . . 16
     4.5.  Transition Directly to Native Dual Stack . . . . . . . . . 16
   7.  Implications of DNS Whitelisting 17
   5.  Potential Implementation Phases  . . . . . . . . . . . . . . . 17
     7.1.  Architectural Implications 18
     5.1.  No Access to IPv6 Content  . . . . . . . . . . . . . . . . 17
     7.2.  Public 18
     5.2.  Using IPv6 Address Reachability Implications Transition Names  . . . . . . 18
     7.3.  Operational Implications . . . . . . . . . 18
     5.3.  Deploying DNS Resolver Whitelisting Using Manual
           Processes  . . . . . . . . 19
       7.3.1.  De-Whitelisting May Occur . . . . . . . . . . . . . . 19
       7.3.2.  Authoritative DNS Server Operational Implications . . 19
       7.3.3. 18
     5.4.  Deploying DNS Recursive Resolver Server Operational
               Implications . . . Whitelisting Using Automated
           Processes  . . . . . . . . . . . . . . . . . . 20
       7.3.4.  Monitoring Implications . . . . . . 18
     5.5.  Turning Off DNS Resolver Whitelisting  . . . . . . . . . 21
       7.3.5.  Implications of Operational Momentum . 18
     5.6.  Deploying DNS Blacklisting . . . . . . . . 22
       7.3.6.  Troubleshooting Implications . . . . . . . . 19
     5.7.  Fully Dual-Stack Content . . . . . 22
       7.3.7.  Additional Implications If Deployed On An Ad Hoc
               Basis . . . . . . . . . . . . 19
   6.  Other Considerations . . . . . . . . . . . . 22
     7.4.  Homogeneity May Be Encouraged . . . . . . . . . 19
     6.1.  Security Considerations  . . . . . 23
     7.5.  Technology Policy Implications . . . . . . . . . . . . 19
     6.2.  Privacy Considerations . . 23
     7.6.  IPv6 Adoption Implications . . . . . . . . . . . . . . . . 24
     7.7.  Implications 20
     6.3.  Considerations with Poor IPv4 and Good IPv6 Transport  . . . 25
     7.8.  Implications for Users of Third-Party DNS Recursive
           Resolvers  . . . . . . . . . . . . . . . . . . . . . . . . 25
   8.  Is DNS Whitelisting a Recommended Practice?  . . . . . . . . . 26
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
     9.1.  DNSSEC Considerations  . . . . . . . . . . . . . . . . . . 27
     9.2.  Authoritative DNS Response Consistency Considerations  . . 27

   10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28
   11. 21
     6.4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
   12. 21
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
   13. 21
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
   14. 22
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     14.1. 24
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 30
     14.2. 24
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 31 25
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 33 26
   Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 36 29
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 29

1.  Introduction

   This document describes considerations for the practice and implications transition of whitelisting
   DNS recursive resolvers in order to limit AAAA resource record (RR)
   responses (which contain IPv6 addresses) sent by authoritative DNS
   servers.  This is referred end user
   content on the Internet to hereafter as DNS Whitelisting.  This IPv6.  While this is
   an IPv6 transition mechanism used by domains as a method for
   incrementally transitioning inbound traffic to a domain from IPv4 tailored to
   IPv6 transport.  When implemented, a domain's authoritative DNS will
   return a AAAA resource record address
   end user content, which is typically web-based, many aspects of this
   document may be more broadly applicable to DNS recursive resolvers [RFC1035] on the whitelist, while returning no AAAA resource records transition to DNS
   recursive resolvers which are not on the whitelist. IPv6 of
   other applications and services.  The practice
   appears issues explored herein will be
   of particular interest to have first been used by major web content sites (sometimes
   described hereafter hereinafter as "high-traffic domains"), which have specific
   and unique concerns relating to maintaining a high-quality user
   experience for all of their users during their transition to IPv6.

   Critics of
   This document explores the practice of DNS Whitelisting have articulated several
   concerns.  Among these are that:

   o  DNS Whitelisting is a very different behavior from challenges involved in the current
      practice concerning transition to
   IPv6, potential transition techniques, possible transition phases,
   and other considerations.  Some sections of this document also
   include information about the publishing potential implications of IPv4 address resource
      records,

   o  that it may create a two-tiered Internet,

   o  that policies and decision-making for whitelisting and de-
      whitelisting are opaque various
   transition techniques or likely phased approaches to cause conflict,

   o  that DNS Whitelisting reduces interest in the deployment of IPv6,

   o transition to IPv6.

2.  Challenges When Transitioning Content to IPv6

   The goal in transitioning content to IPv6 is to make that new operational content
   natively dual-stack enabled, which provides native access to all end
   users via both IPv4 and management burdens IPv6.  However, there are created,

   o  that the practice does not scale,

   o  that it violates a basic premise of cross-Internet
      interoperability by requiring prior arrangements,

   o  and that the costs technical and negative implications of DNS Whitelisting
      outweigh
   operational challenges in being able to transition smoothly for all
   end users, which has led to the perceived benefits.

   This document explores development of a variety of
   transition techniques.  A first step in understanding various
   transition techniques is to first outline the reasons and motivations for challenges involved in
   moving content to IPv6.

   Implementers of these various transition techniques are attempting to
   protect users of their services from having a negative experience
   (poor performance) when they receive DNS
   Whitelisting Section 4.  It also explores the responses containing AAAA
   resource records or when attempting to use IPv6 transport.  There are
   two main concerns regarding which pertain to this
   practice, and whether practice; one of which is
   IPv6-related impairment and when the practice other which is recommended Section 8.
   Readers will hopefully better understand what DNS Whitelisting is,
   why some domains are implementing it, and what the implications are.

2.  How DNS Whitelisting Works

   Generally, using a whitelist means no traffic (or traffic maturity or
   stability of a
   certain type) is permitted to IPv6 transport (and associated network operations) for
   high-traffic domains.  Both can negatively affect the destination host unless experience of
   end users.

   Not all domains may face the
   originating host's IP address is contained same challenges in transitioning content
   to IPv6, since the whitelist.  In
   contrast, using a blacklist means that all user base of each domain, traffic is permitted sources, traffic
   volumes, and other factors obviously will vary between domains.  As a
   result, while some domains have used an IPv6 transition technique,
   others have run brief IPv6 experiments and then decided to
   the destination host unless the originating host's IP address is
   contained in the blacklist.

   DNS Whitelisting is implemented in authoritative DNS servers, not in
   DNS recursive resolvers.  These authoritative DNS servers implement
   IP address-based restrictions on AAAA query responses.  So far, DNS
   Whitelisting has been primarily implemented by web site operators
   deploying IPv6-enabled services, though this practice could affect
   all protocols and services within a domain.  For a given operator of
   a website, such as www.example.com, the domain operator essentially
   applies an access control list (ACL) on the authoritative DNS servers
   for simply
   turn on IPv6 for the domain example.com.  The ACL is populated with the IPv4
   and/or IPv6 addresses or prefix ranges of DNS recursive resolvers on
   the Internet, which have been authorized to receive (or access) AAAA
   resource record responses.  These DNS recursive resolvers are
   operated by third parties, such as Internet Service Providers (ISPs),
   universities, governments, businesses, without further delay and individual end users.  If without using
   any specialized IPv6 transition techniques [Heise].  Each domain
   should therefore consider its specific situation when formulating a DNS recursive resolver IS NOT matched in the ACL, then AAAA
   resource records WILL NOT be sent in response
   plan to a query move to IPv6; there is not one approach that will work for a
   hostname in the example.com
   every domain.  However, if a DNS recursive
   resolver IS matched in the ACL, then

2.1.  IPv6-Related Impairment

   Some implementers have observed that when they added AAAA resource
   records WILL be
   sent in response to a query for a given hostname their authoritative DNS servers in the example.com
   domain.  While these are not network-layer access controls (as many
   ACLs are) they are nonetheless order to support IPv6
   access controls to their content that are a factor for small fraction of end users had slow
   or otherwise impaired access to a given web site with both AAAA and other organizations A
   resource records.  The fraction of users with such impaired access
   has been estimated to be as network operators,
   especially high as networks and hosts transition from one network address
   family to another (IPv4 to IPv6).  Thus, if a DNS recursive resolver 0.078% of total Internet users
   [IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness],
   though more recent measurements indicate this is on declining
   [Impairment-Tracker].

   While it is outside the ACL (whitelist) then they have access scope of this document to AAAA resource
   records explore the various
   reasons why a particular user's system (host) may have impaired IPv6
   access, for the domain.

   In practice, DNS Whitelisting generally means that users who experience this impairment it has a very small
   fraction of
   real performance impact.  It would impact access to all or most dual
   stack services to which the DNS recursive resolvers on user attempts to connect.  This negative
   end user experience can range from somewhat slower than usual access
   (as compared to native IPv4-based access), to extremely slow access,
   to no access to the Internet (those in domain's resources whatsoever.  In essence,
   whether the
   whitelist end user even has an IPv6 address or ACL) will receive not, merely by
   receiving a AAAA responses.  The large majority of
   DNS recursive resolvers on record response the Internet will therefore receive only A user either cannot access a
   Fully Qualified Domain Name (FQDN, representing a service or resource records containing IPv4 addresses.  Thus, quite simply, the
   authoritative server hands out different answers depending upon who
   sought) or it is asking; with IPv4 so slow that the user gives up and IPv6 resource records for all those assumes the
   authorized whitelist,
   destination is unreachable.

2.2.  Operational Maturity Concerns

   Some implementers have discovered that network operations, operations
   support and only IPv4 resource records for everyone
   else.  See Section 2.1 business support systems, and Figure 1 for more details.

   DNS Whitelisting also works independently of whether an authoritative
   DNS server, DNS recursive resolver, or end user host uses IPv4
   transport, IPv6, or both.  So, other operational processes
   and procedures are less mature for example, whitelisting may prevent
   sending AAAA responses even in those cases where the DNS recursive
   resolver has queried the authoritative server over IPv6 transport, or
   where the end user host's original query as compared to the DNS recursive
   resolver was over IPv4, since
   IPv6 transport.  One important reason for this is
   that even though the DNS recursive resolver has not heretofore been pervasively deployed.  This operational
   immaturity may have no IPv6-related
   impairments, this is be observed not a reliable predictor of whether just within the same is
   true network of the end user host.  This a given
   domain but also means that in any directly or indirectly interconnected
   networks.  As a DNS whitelist can
   contain both IPv4 result, many domains consider it prudent to undertake
   any network changes which will cause traffic to shift to IPv6
   gradually in order to provide time and experience for IPv6 addresses.

   Finally, DNS Whitelisting could possibly be deployed operations
   and network practices mature.

2.3.  Volume-Based Concerns

   While Section 2.2 pertains to risks due to immaturity in two ways:
   universally on operations,
   a global basis (though related concern is that would be considered
   harmful and some technical issues may not become
   apparent until some moderate to high volume of traffic is just covered sent via
   IPv6 to explain why and from a domain.  As above, this is may be the case), or,
   more realistically, on an ad hoc basis.  Deployment on a universal
   deployment basis means that DNS Whitelisting is implemented on all
   authoritative DNS servers, across case not just
   within the entire Internet.  In contrast,
   deployment on an ad hoc basis means network of that only some authoritative DNS
   servers, and perhaps even only a few, implement DNS Whitelisting.
   These two potential deployment models are described in Section 5.

   Specific implementations will vary from domain but also for any directly or
   indirectly interconnected networks.  Furthermore, compared to domain, based on a
   range of factors such as domains
   with small to moderate traffic volumes, whether by the technical capabilities count of end
   users or count of bytes transferred, high-traffic domains receive
   such a given
   domain.  As such, level of usage that it is prudent to undertake any examples listed herein should be considered
   general examples network
   changes gradually and are not intended to be exhaustive.

2.1.  Description of in a manner which minimizes the Operation of DNS Whitelisting

   The system logic risk of DNS Whitelisting is as follows:

   1.  The authoritative DNS server for example.com receives DNS queries
       for the A (IPv4) and/or AAAA (IPv6) address resource records
   disruption.  One can imagine that for one of the Fully Qualified Domain Name (FQDN) www.example.com, top ten sites
   globally, for which
       AAAA (IPv6) resource records exist.

   2.  The authoritative DNS server checks example, the IP address (IPv4, IPv6,
       or both) idea of the DNS recursive resolver sending the AAAA (IPv6)
       query against the access control list (ACL) that suddenly turning on a significant
   amount of IPv6 traffic is the DNS
       Whitelist. quite daunting and would carry a relatively
   high risk of network and/or other disruptions.

3.  If  IPv6 Adoption Implications

   It is important that the DNS recursive resolver's IP address IS matched challenges in the ACL,
       then the response transitioning content to that specific DNS recursive resolver can
       contain AAAA (IPv6) address resource records.

   4.  If IPv6
   noted in Section 2 are addressed, especially for high-traffic
   domains.  Some high-traffic domains may find the DNS recursive resolver's IP prospect of
   transitioning to IPv6 extremely daunting without having some ability
   to address IS NOT matched these challenges and to incrementally control their
   transition to IPv6.  Lacking such controls, some domains may choose
   to substantially delay their transition to IPv6.  A substantial delay
   in the
       ACL, then the response content moving to IPv6 could certainly mean there are somewhat
   fewer motivating factors for network operators to deploy IPv6 to end
   user hosts (though they have many significant motivating factors that specific DNS recursive resolver
       cannot contain AAAA (IPv6) address resource records.  In this
       case, the server will likely return a response with
   are largely independent of content).  At the response
       code (RCODE) being set same time, unless
   network operators transition to 0 (No Error) with an empty answer
       section IPv6, there are of course fewer
   motivations for domain owners to transition content to IPv6.  Without
   progress in each part of the AAAA record query.

 +--------------------------------------------------------------------+
 | Caching Server 1 - IS NOT ON the DNS Whitelist                     |
 | Caching Server 2 - IS ON Internet ecosystem, networks and/or
   content sites may delay, postpone, or cease adoption of IPv6, or to
   actively seek alternatives to it.  Such alternatives may include the DNS Whitelist                         |
 | Note: Transport between each host can be IPv4
   use of multi-layer or IPv6.             |
 +--------------------------------------------------------------------+
 +----------+          +---------------+         +---------------+
 |   Stub   |          |  DNS Caching  |         |      DNS      |
 | Resolver |          |   Server 1    |         |     Server    |
 +----------+          +---------------+         +---------------+
    | DNS Query:            |                         |
    | example.com A, AAAA   |                         |
    |---------------------->|                         |
    |                       |                         |
    |                       | DNS Query:              |
    |                       | example.com A, AAAA     |
    |                       |------------------------>|
    |                       |                         |
    |                       |                         | NOT on Whitelist
    |                       |           DNS Response: |
    |                       |           example.com A |
    |                       |<------------------------|
    |                       |                         |
    |         DNS Response: |                         |
    |         example.com A |                         |
    |<----------------------|                         |

 +----------+          +---------------+         +---------------+
 |   Stub   |          |  DNS Caching  |         |      DNS      |
 | Resolver |          |   Server 2    |         |     Server    |
 +----------+          +---------------+         +---------------+
    | DNS Query:            |                         |
    | example.com A, AAAA   |                         |
    |---------------------->|                         |
    |                       |                         |
    |                       | DNS Query:              |
    |                       | example.com A, AAAA     |
    |                       |------------------------>|
    |                       |                         |
    |                       |                         | IS on Whitelist
    |                       |           DNS Response: |
    |                       |     example.com A, AAAA |
    |                       |<------------------------|
    |                       |                         |
    |         DNS Response: |                         |
    |   example.com A, AAAA |                         |
    |<----------------------|                         |

                    Figure 1: DNS Whitelisting Diagram

2.2.  Comparison with Blacklisting

   With DNS Whitelisting, DNS recursive resolvers can receive AAAA
   resource records only if they are on the whitelist.  In contrast,
   blacklisting would be the opposite whereby all DNS recursive
   resolvers can receive AAAA resource records unless they are on the
   blacklist.  So a whitelist contains a list of hosts allowed
   something, whereby a blacklist contains a list of hosts disallowed
   something.  While the distinction between the concepts of
   whitelisting and blacklisting is important, this is noted
   specifically since some implementers of DNS Whitelisting may choose
   to transition to DNS Blacklisting before returning to a state without
   address-family-related ACLs in their authoritative DNS servers.  It
   is unclear when and if it would be appropriate to change from
   whitelisting to blacklisting.  Nor is it clear how implementers will
   judge the network conditions to have changed sufficiently to justify
   disabling such controls.

3.  Similarities to Other DNS Operations

   Some aspects of DNS Whitelisting may be considered similar to other
   common DNS operational techniques which are explored below.

3.1.  Similarities to Split DNS

   DNS Whitelisting has some similarities to so-called split DNS,
   briefly described in Section 3.8 of [RFC2775].  When split DNS is
   used, the authoritative DNS server returns different responses
   depending upon what host has sent the query.  While [RFC2775] notes
   the typical use of split DNS is to provide one answer to hosts on an
   Intranet and a different answer to hosts on the Internet, the essence
   is that different answers are provided to hosts on different
   networks.  This is basically the way that DNS Whitelisting works,
   whereby hosts on different networks which use different DNS recursive
   resolvers, receive different answers if one DNS recursive resolver is
   on the whitelist and the other is not.

   In [RFC2956], Internet transparency and Internet fragmentation
   concerns regarding split DNS are detailed in Section 2.1.  [RFC2956]
   further notes in Section 2.7, concerns regarding split DNS and that
   it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint
   identifiers more complex."  Section 3.5 of [RFC2956] further
   recommends that maintaining a stable approach to DNS operations is
   key during transitions such as the one to IPv6 that is underway now,
   stating that "Operational stability of DNS is paramount, especially
   during a transition of the network layer, and both IPv6 and some
   network address translation techniques place a heavier burden on
   DNS."

3.2.  Similarities to DNS Load Balancing

   DNS Whitelisting also has some similarities to DNS load balancing.
   There are of course many ways that DNS load balancing can be
   performed.  In one example, multiple IP address resource records (A
   and/or AAAA) can be added to the DNS for a given FQDN.  This approach
   is referred to as DNS round robin [RFC1794].  DNS round robin may
   also be employed where SRV resource records are used [RFC2782].

   In another example, one or more of the IP address resource records in
   the DNS will direct traffic to a load balancer.  That load balancer,
   in turn, may be application-aware, and pass the traffic on to one or
   more hosts connected to the load balancer which have different IP
   addresses.  In cases where private IPv4 addresses are used [RFC1918],
   as well as when public IP addresses are used, those end hosts may not
   necessarily be directly reachable without passing through the load
   balancer first.

   Additionally, a geographically-aware authoritative DNS server may be
   used, as is common with Content Delivery Networks (CDNs) or Global
   Load Balancing (GLB, also referred to as Global Server Load
   Balancing, or GSLB), whereby the IP address resource records returned
   to a resolver in response to a query will vary based on the estimated
   geographic location of the resolver [Wild-Resolvers].  CDNs perform
   this function in order to attempt to direct hosts to connect to the
   nearest content cache.  As a result, one can see some similarities
   with DNS Whitelisting insofar as different IP address resource
   records are selectively returned to resolvers based on the IP address
   of each resolver (or other imputed factors related to that IP
   address).  However, what is different is that in this case the
   resolvers are not deliberately blocked from receiving DNS responses
   containing an entire class of addresses; this load balancing function
   strives to perform a content location-improvement function and not an
   access control function.

4.  What Problems Are Implementers Trying To Solve?

   Implementers are attempting to protect users of their domain from
   having a negative experience (poor performance) when they receive DNS
   response containing AAAA resource records or when attempting to use
   IPv6 transport.  There are two concerns which relate to this
   practice; one of which relates to IPv6-related impairment and the
   other which relates to the maturity or stability of IPv6 transport
   for high-traffic domains.  Both can negatively affect the experience
   of end users.

   Not all domains may face these challenges, though some clearly do,
   since the user base of each domain, traffic sources, traffic volumes,
   and other factors obviously varies between domains.  For example,
   while some domains have implemented DNS Whitelisting, others have run
   IPv6 experiments whereby they added AAAA resource records and
   observed and measured errors, and then decided not to implement DNS
   Whitelisting [Heise].  A more widespread such experiment was World
   IPv6 Day [W6D], sponsored by the Internet Society, on June 8, 2011.
   This was a unique opportunity for hundreds of domains to add AAAA
   resource records to the DNS without using DNS Whitelisting, all at
   the same time.  Domains can run their own independent experiments in
   the future, adding AAAA resource records for a period of time, and
   then analyzing any impacts or effects on traffic and the experience
   of end users.

4.1.  Volume-Based Concerns

   Some implementers are trying to gradually add IPv6 traffic to their
   domain since they may find that network operations, tools, processes
   and procedures are less mature for IPv6 as compared to IPv4.
   Compared to domains with small to moderate traffic volumes, whether
   by the count of end users or count of bytes transferred, high-traffic
   domains receive such a level of usage that it is prudent to undertake
   any network changes gradually or in a manner which minimizes any risk
   of disruption.

   For example, one can imagine for one of the top ten sites globally
   that the idea of suddenly turning on a significant amount of IPv6
   traffic is quite daunting.  DNS Whitelisting may therefore offer such
   high-traffic domains one potential method for incrementally enabling
   IPv6.  Thus, some implementers with high-traffic domains plan to use
   DNS Whitelisting as a necessary, though temporary, risk reduction
   tactic intended to ease their transition to IPv6 and minimize any
   perceived risk in such a transition.

4.2.  IPv6-Related Impairment

   Some implementers have observed that when they added AAAA resource
   records to their authoritative DNS servers in order to support IPv6
   access to their content that a small fraction of end users had slow
   or otherwise impaired access to a given web site with both AAAA and A
   resource records.  The fraction of users with such impaired access
   has been estimated to be as high as 0.078% of total Internet users
   [IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness],
   though more recent measurements indicate this is declining
   [Impairment-Tracker].  In these situations, DNS recursive resolvers
   are added to the DNS Whitelist only when the measured level of
   impairment of the hosts using that resolver declines to some level
   acceptable by the domain.

   It is not clear if the level of IPv4-related impairment is more or
   less that IPv6-related impairment.  As one document reviewer has
   pointed out, it may simply be that websites are only measuring IPv6
   impairments and not IPv4 impairments, whether because IPv6 is new or
   whether those websites are simply unable to or are otherwise not in a
   position to be able to measure IPv4 impairment (since this could
   result in no Internet access whatsoever).

   As a result of this impairment affecting end users of a given domain,
   a few high-traffic domains have either implemented DNS Whitelisting
   or are considering doing so [NW-Article-DNS-WL] [WL-Ops].  While it
   is outside the scope of this document to explore the various reasons
   why a particular user's system (host) may have impaired IPv6 access,
   for the users who experience this impairment it has a very real
   performance impact.  It would affect access to all or most dual stack
   services to which the user attempts to connect.  This negative end
   user experience can range from somewhat slower than usual access (as
   compared to native IPv4-based access), to extremely slow access, to
   no access to the domain whatsoever.  In essence, whether the end user
   even has an IPv6 address or not, merely by receiving a AAAA record
   response the user either cannot access a FQDN or it is so slow that
   the user gives up and assumes the destination is unreachable.

   In addition, at least one high-traffic domain has noted that they
   have received requests to not send DNS responses with AAAA resource
   records to particular DNS recursive resolvers.  In this case, a DNS
   recursive resolver operator expressed a short-term concern that their
   IPv6 network infrastructure was not yet ready to handle the large
   traffic volume that may be associated with the hosts in their network
   connecting to the websites of these domains.  These end user networks
   may also have other tools at their disposal in order to address this
   concern, including applying rules to network equipment such as
   routers and firewalls (this will necessarily vary by the type of
   network, as well as the technologies used and the design of a given
   network), as well as configuration of their DNS recursive resolvers
   (though modifying or suppressing AAAA resource records in a DNSSEC-
   signed domain on a Security-Aware Resolver will be problematic
   Section 9.1).

   It is worth noting that the IP address of a DNS recursive resolver is
   not a precise indicator of the IPv6 preparedness, or lack of IPv6-
   related impairment, of end user hosts which query (use) a particular
   DNS recursive resolver.  While the DNS recursive resolver may be an
   imperfect proxy for judging IPv6 preparedness, it is at least one of
   the best available methods at the current time.

4.3.  Free Versus Subscription Services

   It is also worth noting the differences between domains containing
   primarily subscription-based services compared to those containing
   primarily free services.  In the case of free services, such as
   search engines, end users have no direct billing relationship with
   the domain and can switch sites simply by changing the address they
   enter into their browser (ignoring other value added services which
   may tie a user's preference to a given domain or otherwise create
   switching costs).  As a result, such domains may be more sensitive to
   IPv6 transition issues since their users can quickly switch to
   another domain that is not using IPv6.

5.  General Implementation Variations

   In considering how DNS Whitelisting may emerge more widely, there are
   two deployment scenarios explored below, one of which, the ad-hoc
   case Section 5.2, is realistic and is happening now.  The other,
   universal deployment Section 5.1, is only described for the sake of
   completeness, to highlight its difficulties, and to explain why it
   would be considered harmful.  Other possible alternative or
   supplementary approaches are also outlined.

   In evaluating implementing DNS Whitelisting universally and on an ad
   hoc basis, it is possible that reputable third parties could create
   and maintain DNS whitelists, in much the same way that blacklists are
   distributed and used for reducing email spam.  In the email context,
   a mail operator subscribes to one or more of these lists and as such
   the operational processes for additions and deletions to the list are
   managed by a third party.  A similar model could emerge for DNS
   Whitelisting.

   In either of those scenarios a DNS recursive resolver operator will
   have large scale network address translation (NAT)
   techniques, which is not preferred relative to determine whether or native dual stack.

   Obviously, transitioning content to IPv6 is important to IPv6
   adoption overall.  While challenges do exist, such a transition is
   not DNS Whitelisting has been
   implemented an impossible task for a domain, since the absence of AAAA resource records
   may simply be indicative that the domain has not yet added IPv6
   addressing for the domain, rather than that they have done so but are
   using DNS Whitelisting.  This will be challenging at scale.

5.1.  Implement DNS Whitelisting Universally

   One approach is to implement DNS Whitelisting universally, which
   could also involve using some sort of centralized registry undertake.  A range of DNS
   Whitelisting policies, contracts, processes, or other information.
   For this deployment scenario to occur, DNS Whitelisting functionality
   would need
   potential transition techniques, as noted below in Section 4, can
   help meet these challenges and enable a domain to be built into all authoritative DNS server software, successfully
   transition content and all operators of authoritative DNS servers would have other services to upgrade IPv6.

4.  Potential Transition Techniques

   Domains have a wide range of potential techniques at their software in order to enable this functionality.  New IETF
   Request for Comment (RFC) documents disposal
   that may need to be completed used to
   describe how facilitate the transition to properly configure, deploy, and maintain DNS
   Whitelisting across IPv6.  This section
   includes many of the entire Internet.  As key techniques that could be used by a result, domain
   but it is highly
   unlikely that DNS Whitelisting will become universally deployed.

   Such an approach is considered harmful and problematic, and almost
   certain not to happen.

5.2.  Implement DNS Whitelisting On An Ad Hoc Basis

   DNS Whitelisting is now being adopted on by no means an ad hoc, exhaustive or domain-by-
   domain basis.  Therefore, only those domains interested in DNS
   Whitelisting would need to adopt the practice.  Also in this
   scenario, ad hoc use by exclusive list.  Only a particular
   specific domain is likely to be can judge whether or not a
   temporary measure that has been adopted to ease the given (or any) transition of the
   domain
   technique applies to IPv6. their domain and meets their needs.  A domain, particularly a high-traffic domain, domain
   may
   choose also decide to do so pursue several of these techniques in order parallel.
   Thus, the usefulness of each technique and the associated pros and
   cons will vary from domain to ease domain.

4.1.  Solve Current End User IPv6 Impairments

   Domains can endeavor to fix the underlying technical problems
   experienced by their end users during the transition to IPv6 through a
   selective deployment so IPv6, as to minimize any risks or disruptions
   noted in
   such a transition. Section 2.1.  One benefit of DNS Whitelisting being deployed on an ad hoc basis challenge with this option is that only the domains that are interested in doing so would a
   domain may have to
   upgrade their authoritative DNS servers (or take little or no control over the network connectivity,
   operating system, client software (such as a web browser), and/or
   other steps) in
   order to implement DNS Whitelisting.  Some domains capabilities of the end users of that plan domain.  In most cases a
   domain is only in a position to or
   already have implemented this influence and are manually updating guide their
   whitelist, while others such as CDNs have discussed end users.
   While this is not the possibility same sort of direct control which may exist in
   an automated method enterprise network for doing so.

5.3.  Do Not Implement DNS Whitelisting

   As an alternative example, major domains are likely to adopting DNS Whitelisting, be
   trusted by their end users and may therefore be able to influence and
   guide these users in solving any IPv6-related impairments.

   Another challenge is that end user impairments are something that one
   domain on their own cannot solve.  This means that domains can choose
   not may find
   it more effective to implement DNS Whitelisting, continuing coordinate with many others in the current predominant
   authoritative DNS operational model on Internet
   community to solve what is really a collective problem that affects
   the entire Internet.  It is then up  Of course, it can sometimes be difficult to end users with IPv6-related impairments
   motivate members of the Internet community to discover and fix those
   impairments, though clearly other parties including end user host
   operating system developers can play work collectively
   towards such a critical role.  However, goal, sharing the
   concerns labor, time, and risks related to traffic volume Section 4.1 should still
   be considered since those are not directly costs related to
   such
   impairments.

5.3.1.  Solve Current End User an effort.  However, World IPv6 Impairments

   A further extension of not implementing DNS Whitelisting, is to also
   endeavor fix the underlying technical problems experienced by end
   users during Day [W6D] shows that such
   community efforts are possible and despite any potential challenges,
   the transition Internet community continues to IPv6.  A first step is work together in order to solve
   end user IPv6 impairments.

   One potential tactic may be to identify which users have such
   impairments and then to communicate this information to affected
   users.  Such end user communication is likely to be most helpful if
   the end user is not only alerted to a potential problem but is given
   careful and detailed advice on how to resolve this on their own, or
   is guided to where they can seek help in doing so.
   Section 10 may also be relevant in this case.

   One challenge with this option is the  Another potential difficulty of
   motivating members of the Internet community
   tactic is for a domain to work collectively
   towards this goal, sharing the labor, collect, track over time, and costs related to such
   an effort.  However, World IPv6 Day [W6D] shows that such community
   efforts are possible and despite any potential challenges, periodically
   share with the Internet community continues to work to solve the rate of impairment observed for
   a domain.  In any such end user IPv6
   impairments. IPv6-related analysis and
   communication, Section 6.2 is worth taking into account.

   However, as while these tactics can help reduce IPv6-related impairments
   Section 2.1, they do not address either operational maturity concerns
   noted above, the in Section 2.2 or volume-based concerns and risks related to traffic
   volume noted in Section 4.1 2.3,
   which should still be considered since those are not
   directly related to such impairments.

5.3.2.  Gain Experience Using and addressed separately.

4.2.  Use IPv6 Transition Names

   Another alternative potential transition technique is for domains a domain to gain
   experience using an FQDN
   which a special Fully-Qualified Domain Name (FQDN).  This
   has become common typical for domains beginning the transition to IPv6; IPv6,
   whereby a name such as ipv6.example.com and www.ipv6.example.com. or www.ipv6.example.com is
   used.  An end user would have to know to use this special transition
   name; it is not the same name used for regular traffic.

   This can be special transition name directs traffic to a host or hosts which
   have been enabled for native IPv6 access.  In some cases this name
   may point to hosts which are separate from those used for IPv4
   traffic (via www.example.com), while in other cases it may point to
   the same hosts used for IPv4 traffic.  A subsequent phase, if
   separate hosts are used to support special transition names, is to
   move to the same hosts used for regular traffic in order to utilize
   and exercise production infrastructure more fully.  Regardless of
   whether or not dedicated hosts are used, the use of the special name
   is a way to incrementally control traffic as a tool for a domain to
   gain IPv6 experience and increase IPv6 use on a relatively controlled basis, and to
   basis.  Any lessons learned can then inform any plans for DNS Whitelisting with
   experience. a full
   transition to IPv6.  This also provides an opportunity for a domain
   to develop any necessary training for staff, to develop IPv6-related
   testing procedures for their production network and lab, to deploy
   IPv6 functionality into their production network, and to develop and
   deploy IPv6-related network and service monitors.  It is also an
   opportunity to add a relatively small amount of IPv6 traffic to
   ensure that network gear, network interconnects, and IPv6 routing in
   general is working as expected.

   While this using a special transition name is a good first initial step to
   functionally test and prepare a domain for IPv6, including developing
   and maturing IPv6 operations, as noted in Section 2.2, the utility of
   the tactic is limited since users must know the transition name, the
   traffic volume will be low, and the traffic is unlikely to be
   representative of the general population of end users, users (they are
   likely to be self-selecting early adopters and more technically
   advanced than average), among other reasons.  Thus, as noted above,
   the  As a result, any
   concerns and risks related to traffic volume as noted Section 4.1 2.3
   should still be considered.

5.3.3. considered and addressed separately.

4.3.  Implement DNS Blacklisting

   Some domains may wish to be more permissive than if they adopted DNS
   Whitelisting, but still have some level of control over returning
   AAAA record responses.  In this case an alternative may be to employ
   DNS Blacklisting, which would enable all DNS recursive resolvers to
   receive AAAA record responses except for the relatively small number
   that are listed in the blacklist.  This could, for example, enable an
   implementer to only prevent such responses where there has been Resolver Whitelisting

   Another potential technique, especially when a
   relatively high level of IPv6-related impairments, until such time as
   these impairments can be fixed or otherwise meaningfully reduced to
   an acceptable level.

   This approach traffic domain is likely
   ready to be significantly less labor intensive for move beyond an authoritative DNS server operator, IPv6 transition name, as they would presumably focus
   on a smaller number described in
   Section 4.2, is to selectively return AAAA resource records (RRs),
   which contain IPv6 addresses.  This selective response of DNS recursive resolvers than if they
   implemented whitelisting.  Thus, these records
   is performed by an authoritative DNS server
   operators would only need to communicate with servers for a few DNS recursive
   resolver operators rather than potentially all such operators.  This
   should result domain in lower labor, systems, and process requirements.
   This is not to say that there will be no time required response
   to work with
   those parties affected DNS queries sent by a blacklist, simply that there are likely DNS recursive resolvers [RFC1035].  This is
   commonly referred to be fewer such interactions in the Internet community as "DNS Resolver
   Whitelisting", and that each such interaction could will be
   shorter in duration.

   The email industry has a long experience with blacklists and, very
   generally speaking, blacklists tend referred to be effective and well received
   when as such hereafter, though in
   essence it is easy to discover if a server is on simply a blacklist, if there technique enabling the selective return of DNS
   records based upon various technical factors.  An end user is seeking
   a transparent and easily understood process for requesting removal
   from a blacklist, resource by name, and if this selective response mechanism enables
   what is perceived to be the decision-making criteria for placing a
   server on most reliable and best performing IP
   address family to be used (IPv4 or IPv6).  As a blacklist is transparently disclosed technique, it shares
   similarities with Content Delivery Networks, Global Server Load
   Balancing, DNS Load Balancing, and perceived Split DNS, as
   fair.

   As noted described below in
   Section 7.3.7, it 4.3.2, Section 4.3.3, Section 4.3.4.  A few high-traffic
   domains have either implemented DNS Resolver Whitelisting (one of
   many transition techniques they have used or are using) or are
   considering doing so [NW-Article-DNS-WL] [WL-Ops].

   This is also possible that a transition technique used by domains as a method for
   incrementally transitioning inbound traffic to a domain may
   choose to first implement DNS Whitelisting and then migrate IPv6.  If
   an incremental technique like this is not users, a domain might
   return AAAA resource records to any relevant DNS
   Blacklisting.

6.  Concerns Regarding DNS Whitelisting

   There is concern that query, meaning the practice of DNS Whitelisting for
   domain could go quickly from no IPv6
   address resource records represents traffic to potentially a departure from the generally
   accepted practices regarding IPv4 address
   significant amount as soon as the AAAA resource records in the are
   published.  When DNS
   on the Internet [WL-Concerns].  Generally, once an Resolver Whitelisting is implemented, a domain's
   authoritative
   server operator adds an A DNS will selectively return a AAAA resource record (IPv4) to the DNS, then any
   DNS recursive resolver resolvers on the Internet can receive that A record in
   response to a query.  This enables new server hosts that are
   connected to whitelist maintained by the Internet, and for which a FQDN such as
   www.example.com has been added domain,
   while returning no AAAA resource records to the DNS with an IPv4 address
   record, to be almost immediately reachable by any host recursive resolvers
   which are not on the
   Internet.  Each end in this end-to-end model is responsible for
   connecting to the Internet and once they that whitelist.  This tactic will not have done so they a direct
   impact on reducing IPv6-related impairments Section 2.1, though it
   can
   connect to each other without additional impediments, middle
   networks, intervening networks, or servers either knowing about all
   end points or whether one is allowed to discover and contact the
   other.  The end result is that new server hosts become more help a domain address operational maturity concerns Section 2.2
   and more
   widely accessible as new networks concerns and new hosts connect risks related to the
   Internet over time, capitalizing on traffic volume Section 2.3.

   There are of course challenges and increasing so-called "network
   effects" (also called network externalities).

   In contrast, concerns relating to DNS Whitelisting may fundamentally change this model.
   In Resolver
   Whitelisting.  Some of the altered concerns with a whitelist of DNS Whitelisting end-to-end model, one end (where the
   end user is located) cannot readily discover the recursive
   resolvers may be held by parties other end (where the
   content is located), without parts of than the middle (authoritative implementing domain,
   such as network operators or end users that may not have had their
   DNS
   servers) making a new type of access control decision in the DNS.  So
   in the current IPv4-based Internet when a new server host is recursive resolvers added to a whitelist.  Additionally, the Internet it is generally widely available to all end user hosts
   via IP
   address of a FQDN.  When DNS Whitelisting of IPv6 resource records recursive resolver is used,
   these new server hosts are not accessible via a FQDN by any precise indicator of the
   IPv6 preparedness, or lack of IPv6-related impairment, of end user
   hosts until such time as which query (use) a particular DNS recursive resolver.  While
   the operator IP addresses of the authoritative DNS
   servers adds DNS recursive resolvers around on networks known to have
   deployed IPv6 may be an imperfect proxy for judging IPv6
   preparedness, or lack of IPv6-related impairment, it is one of the Internet
   better available methods at the current time.  In addition, given the
   current state of global IPv6 deployment, this transition tactic
   allows content providers to selectively expose the DNS
   Whitelist.

7.  Implications availability of
   their IPv6 services.  While opinions in the Internet community
   concerning DNS Resolver Whitelisting

   The key are understandably quite varied,
   there is clear consensus that DNS Resolver Whitelisting implications are detailed below.

7.1.  Architectural Implications can be a
   useful tactic a domain may choose to use as they transition their
   services to IPv6.  In particular, some high-traffic domains view DNS
   Resolver Whitelisting modifies the end-to-end model and the general notion
   of spontaneous interoperability as one of the architecture that prevails on
   the Internet today.  This is because this approach moves additional
   access control information few practical and policies into the middle of the DNS
   resolution path of the IPv6-addressed Internet, low-risk
   approaches enabling them to transition to IPv6, without which generally did their
   transition may not exist before take place for some time.  However, there is also
   consensus that this practice is workable on a manual basis (see
   below) only in the IPv4-addressed Internet, short-term and that it requires some
   type of prior registration with authoritative servers.  This poses will not scale over the
   long-term.  Thus, some risks noted domains may find DNS Resolver Whitelisting a
   beneficial temporary tactic in [RFC3724].  In explaining the history of their transition to IPv6.

   At the end-
   to-end principle, [RFC1958] states current time, generally speaking, a domain that one implements DNS
   Resolver Whitelisting does so manually.  This means that a domain
   manually maintains a list of the goals is networks that are permitted to
   minimize the state, policies, receive
   IPv6 records (via their DNS resolver IP addresses) and that these
   networks typically submit applications, or follow some other functions needed in the
   middle of process
   established by the network domain, in order to enable end-to-end communications on
   the Internet.  In this case, the middle network should be understood
   to mean anything other than the end hosts involved in communicating
   with one another.  Some state, policies, and other functions have
   always been necessary to enable such end-to-end communication, but
   the goal of the approach has been to minimize this added to the greatest
   extent possible.

   It is also possible DNS Whitelist.
   However, implementers foresee that a subsequent phase of DNS Resolver
   Whitelisting could place at risk some of
   the observed benefits of the end-to-end principle, as listed is likely to emerge in
   Section 4.1 of [RFC3724], such as protection of innovation.
   [RFC3234] details issues and concerns regarding so-called
   middleboxes, so there may also be parallel concerns with the DNS
   Whitelisting approach, especially concerning modified DNS servers
   noted future, possibly in Section 2.16 of [RFC3234], the near
   future.  In this new phase a domain would return IPv6 and/or IPv4
   records dynamically based on automatically detected technical
   capabilities, location, or other factors.  It would then function
   much like (or indeed as well part of) global server load balancing, a
   common practice already in use today, as more general concerns
   noted described in Section 1.2 of [RFC3234] about the introduction of new
   failure modes.  In particular, there may 4.3.2.
   Furthermore, in this future phase, networks would be concerns added to and
   removed from a DNS Whitelist automatically, and possibly on a near-
   real-time basis.  This means, crucially, that
   configuration is networks would no
   longer limited need to two ends apply to be added to a whitelist, which may alleviate
   many of the key concerns that network operators may have with this
   technique when it is implemented on a session, and manual basis.

4.3.1.  How DNS Resolver Whitelisting Works

   Using a "whitelist" in a generic sense means that
   diagnosis no traffic (or
   traffic of failures and misconfigurations becomes more complex.

   Two additional sources worth considering as far as implications for a certain type) is permitted to the end-to-end model are concerned are [Tussle] and [Rethinking].  In
   [Tussle], destination host
   unless the authors note concerns regarding originating host's IP address is contained in the introduction of new
   control points, as well as "kludges"
   whitelist.  In contrast, using a "blacklist" means that all traffic
   is permitted to the DNS, as risks to destination host unless the goal
   of network transparency originating host's IP
   address is contained in the end-to-end model.  Given blacklist.  In the emerging
   use case of DNS Whitelisting [Tussle] Resolver
   Whitelisting, the resource that an end user seeks is a name, not an interesting and relevant
   document.  In addition, [Rethinking] reviews similar issues that are
   of interest to readers of this document.

   Also, it
   IP address or IP address family.  Thus, an end user is somewhat possible seeking a name
   such as www.example.com, without regard to the underlying IP address
   family (IPv4 or IPv6) which may be used to access that resource.

   DNS Resolver Whitelisting could affect some
   of is implemented in authoritative DNS
   servers, not in DNS recursive resolvers.  These authoritative DNS
   servers selectively return AAAA resource records using the architectural assumptions which underlie parts IP address
   of Section 2 the DNS recursive resolver that has sent it a query.  Thus, for a
   given operator of
   [RFC4213] which outlines a website, such as www.example.com, the dual stack approach to domain
   operator implements whitelisting on the IPv6
   transition. authoritative DNS Whitelisting could modify servers for
   the behavior of domain example.com.  The whitelist is populated with the DNS,
   as described in Section 2.2 of [RFC4213] and could require different
   sets IPv4
   and/or IPv6 addresses or prefix ranges of DNS servers recursive resolvers on
   the Internet, which have been authorized to be used for hosts that receive AAAA resource
   record responses.  These DNS recursive resolvers are (using terms from
   that document) IPv6/IPv4 nodes, IPv4-only nodes, operated by
   third parties, such as Internet Service Providers (ISPs),
   universities, governments, businesses, and IPv6-only nodes.
   As such, broad use of individual end users.  If
   a DNS Whitelisting may necessitate recursive resolver IS NOT matched in the review
   and/or revision (though revision is unlikely to whitelist, then AAAA
   resource records WILL NOT be necessary) of
   standards documents which describe dual-stack and IPv6 operating
   modes, dual-stack architecture generally, and IPv6 transition
   methods, including but not limited sent in response to [RFC4213].

7.2.  Public IPv6 Address Reachability Implications

   It is a critical to understand that the concept of reachability
   described here depends upon query for a knowledge of an address
   hostname in the DNS.
   Thus, in order to establish reachability to example.com domain (and an end point, A record would be sent).
   However, if a host is
   dependent upon looking up an IP address DNS recursive resolver IS matched in the whitelist,
   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
   whether to use a AAAA record or A record response, with DNS Resolver
   Whitelisting the authoritative DNS when server can also decide whether to
   return a FQDN is
   used. AAAA record, an A record, or both record types.

   When implemented on a manual basis, DNS Resolver Whitelisting is used, it is quite likely
   generally means that an
   IPv6-enabled end user host could connect to an example server host
   using a very small fraction of the IPv6 address, even though DNS recursive
   resolvers on the FQDN associated with that
   server host is restricted via a Internet (those in the whitelist) will receive AAAA
   responses.  The large majority of DNS whitelist.  Since most recursive resolvers on the
   Internet
   applications and hosts such as web servers depend upon will therefore receive only A resource records containing
   IPv4 addresses.  When implemented manually, domains may find the DNS, and
   practice imposes some incremental operational burdens insofar as end users connect it
   can consume staff time to FQDNs such maintain a whitelist (such as www.example.com additions and do not
   remember or wish
   deletions to type in an IP address, the notion of reachability
   described here should be understood list), respond to include knowledge of how and review applications to be
   added to
   associate a name with a network address.

   The predominant experience of end user hosts and servers whitelist, maintain good performance levels on
   authoritative DNS servers as the IPv4-
   addressed Internet today is that when a whitelist grows, create new server with a public IPv4
   address is added network
   monitors to check the DNS, that a FQDN is immediately useful for
   reaching it.  This is a generalization and in Section 3 there are
   examples health of common cases where this may not necessarily be the case.
   For the purposes a whitelist function, perform new
   types of this argument, that concept troubleshooting related to whitelisting, etc.  In addition,
   manually-based whitelisting imposes some incremental burdens on
   operators of accessibility is
   described DNS recursive resolvers (such as "pervasive reachability".  It has so far been assumed
   that network operators),
   since they will need to apply to be whitelisted with any implementing
   domains, and will subsequently need processes and systems to track
   the same expectations status of pervasive reachability would exist whitelisting applications, respond to requests for
   additional information pertaining to these applications, and track
   any de-whitelisting actions.

   When implemented on an automated basis in the IPv6-addressed Internet.  However, if DNS Whitelisting is
   deployed, this will not be the case since only end user hosts using future, DNS recursive
   resolvers that are included listed in the ACL whitelist could expand and contract
   dynamically, and possibly in near-real-time, based on a wide range of
   factors.  As a given
   domain using DNS Whitelisting would be able to reach new servers in result, it is likely that given domain via IPv6 addresses.  The expectation the number of any end
   user host being able to connect to any server (essentially both
   hosts, just DNS recursive
   resolvers on the whitelist will be substantially larger than when
   such a list is maintained manually, and it is likely the the
   whitelist will grow at either end a rapid rate.  This automation can eliminate
   most of the network), defined here significant incremental operational burdens on both
   implementing domains as "pervasive
   reachability", will change well as operators of DNS recursive resolvers,
   which is clearly a factor that is motivating implementers to "restricted reachability" with IPv6.

   Establishing work to
   automate this function.

   Section 4.3.1.1 and Figure 1 have more details on DNS Resolver
   Whitelisting as an accepted practice in generally.  In addition, the early
   phases of mass IPv6 potential deployment could establish it as an integral part models
   of how IPv6 DNS resource records Resolver Whitelisting (manual and automated) are deployed globally.  This risks described in
   Section 5.  It is also important to note that DNS Resolver
   Whitelisting living on for many years as a key foundational
   element of domain name management on the Internet.

7.3.  Operational Implications

   This section explores some also works independently of the operational implications which whether an authoritative DNS
   server, DNS recursive resolver, or end user host uses IPv4 transport,
   IPv6, or both.  So, for example, whitelisting may
   occur as a not result of, are related to, or become necessary when
   engaging in the practice
   return of DNS Whitelisting.

7.3.1.  De-Whitelisting May Occur

   It is possible for a AAAA responses even in those cases where the DNS recursive
   resolver added to a whitelist to
   then be removed from the whitelist, also known as de-whitelisting.
   Since de-whitelisting can occur, through a decision by has queried the authoritative server operator, over IPv6 transport.
   This may also be the domain owner, or even due case in some situations when the end user host's
   original query to a
   technical error, an operator of a its DNS recursive resolver was over IPv6 transport,
   if that DNS recursive resolver will have
   new operational and monitoring requirements and/or needs as noted in
   Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.  One
   particular risk is that, especially when a high-traffic domain de-
   whitelists not on a large network, given whitelist.  One
   important reason for this is that even though the DNS recursive
   resolver may cause a sudden and dramatic
   change to networks since a large volume of traffic will then switch
   from IPv6 to IPv4.  This can have dramatic effects on those being de-
   whitelisted as well as on other interconnected networks.  In some
   cases, IPv4 network links may rapidly become congested and users no IPv6-related impairments, this is not a reliable
   predictor of
   affected networks will experience network access impairments well
   beyond the domain which performed whether the de-whitelisting.  Thus, once
   "operational stability" has been achieved between a whitelisting and
   whitelisted party, then de-whitelisting should generally not occur
   except in cases same is true of operational emergencies, and there should be
   opportunities for joint troubleshooting or at least for advance
   warning to affected parties.

7.3.2.  Authoritative DNS Server Operational Implications

   DNS Whitelisting serves as a critical infrastructure service; to be
   useful it needs careful and extensive administration, monitoring and
   operation.  Each new the end user host.  This
   also means that a DNS whitelist can contain both IPv4 and essential mechanism creates substantial
   follow-on support costs.

   Operators IPv6
   addresses.

4.3.1.1.  Description of authoritative servers (which are frequently
   authoritative for multiple domain names) the Operation of DNS Resolver Whitelisting

   Specific implementations will need vary from domain to maintain an ACL domain, based on a server-wide basis affecting all domains, or on
   range of factors such as the technical capabilities of a domain-by-
   domain basis. given
   domain.  As a result, operational practices and software
   capabilities may need to such, any examples listed herein should be developed in order to support such
   functionality.  In addition, processes may need considered
   general examples and are not intended to be put in place to
   protect against inadvertently adding or removing IP addresses, as
   well as systems and/or processes to respond to such incidents if and
   when they occur.  For example, a exhaustive.

   The system may be needed to record logic of DNS Resolver Whitelisting requests, report on their status along a workflow, add
   IP addresses when whitelisting has been approved, remove IP addresses
   when they have been de-whitelisted, log is as follows:

   1.  The authoritative DNS server for example.com receives DNS queries
       for the personnel involved and
   timing of changes, schedule changes to occur in A (IPv4) and/or AAAA (IPv6) address resource records for
       the future, and to
   roll back any inadvertent changes.

   Operators may also need implement new forms Fully Qualified Domain Name (FQDN) www.example.com, for which
       AAAA (IPv6) resource records exist.

   2.  The authoritative DNS server checks the IP address (IPv4, IPv6,
       or both) of monitoring the DNS recursive resolver sending the AAAA (IPv6)
       query against the whitelist that is the DNS Whitelist.

   3.  If the DNS recursive resolver's IP address IS matched in order the
       whitelist, then the response to
   apply change control, as noted briefly that specific DNS recursive
       resolver can contain AAAA (IPv6) address resource records.

   4.  If the DNS recursive resolver's IP address IS NOT matched in Section 7.3.4.

   It is important for operators of authoritative servers the
       whitelist, then the response to recognize that specific DNS recursive
       resolver cannot contain AAAA (IPv6) address resource records.  In
       this case, the operational burden is server will likely to increase dramatically over
   time, as more and more networks transition to IPv6.  As return a result, response with the
   volume of new DNS Whitelisting requests will increase over time,
   potentially at an extraordinary growth rate, which will place
       response code (RCODE) being set to 0 (No Error) with an
   increasing burden on personnel, systems, and/or processes.  Operators
   should also consider that any supporting systems, including empty
       answer section for the AAAA record query.

 +--------------------------------------------------------------------+
 | Caching Server 1 - IS NOT ON the
   authoritative servers themselves, may experience reduced performance
   when a DNS whitelist becomes quite large.

7.3.3. Whitelist                     |
 | Caching Server 2 - IS ON the DNS Whitelist                         |
 | Note: Transport between each host can be IPv4 or IPv6.             |
 +--------------------------------------------------------------------+
 +----------+          +---------------+         +---------------+
 |   Stub   |          |  DNS Caching  |         |      DNS      |
 | Resolver |          |   Server 1    |         |     Server    |
 +----------+          +---------------+         +---------------+
    | DNS Query:            |                         |
    | example.com A, AAAA   |                         |
    |---------------------->|                         |
    |                       |                         |
    |                       | DNS Query:              |
    |                       | example.com A, AAAA     |
    |                       |------------------------>|
    |                       |                         |
    |                       |                         | NOT on Whitelist
    |                       |           DNS Response: |
    |                       |           example.com A |
    |                       |<------------------------|
    |                       |                         |
    |         DNS Response: |                         |
    |         example.com A |                         |
    |<----------------------|                         |

 +----------+          +---------------+         +---------------+
 |   Stub   |          |  DNS Caching  |         |      DNS Recursive      |
 | Resolver |          |   Server Operational Implications

   For operators of DNS recursive resolvers, coping with 2    |         |     Server    |
 +----------+          +---------------+         +---------------+
    | DNS
   Whitelisting becomes expensive in time and personnel as the practice
   scales up.  These operators include ISPs, enterprises, universities,
   governments; a wide range of organization types with a range of DNS-
   related expertise.  They will need to implement new forms of
   monitoring, as noted briefly in Section 7.3.4.  But more critically,
   such operators will need to add people, processes, and systems in
   order to manage large numbers of Query:            |                         |
    | example.com A, AAAA   |                         |
    |---------------------->|                         |
    |                       |                         |
    |                       | DNS Whitelisting applications.
   Since there is no common method for determining whether or not a
   domain is engaged in Query:              |
    |                       | example.com A, AAAA     |
    |                       |------------------------>|
    |                       |                         |
    |                       |                         | IS on Whitelist
    |                       |           DNS Whitelisting, operators will have to apply
   to be whitelisted for a domain based upon one or more end user
   requests, which means systems, processes, and personnel for handling
   and responding to those requests will also be necessary.

   When operators apply for Response: |
    |                       |     example.com A, AAAA |
    |                       |<------------------------|
    |                       |                         |
    |         DNS Whitelisting for all domains, that may
   mean doing so for all registered domains.  Thus, some system would
   have to be developed to discover whether each domain has been
   whitelisted or not, which is touched on in Section 5 and may vary
   depending upon whether Response: |                         |
    |   example.com A, AAAA |                         |
    |<----------------------|                         |

                Figure 1: DNS Resolver Whitelisting is universally deployed or is
   deployed on an ad hoc basis.

   These operators (of DNS recursive resolvers) will need to develop
   processes and systems to track the status of all Diagram

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

   DNS Resolver Whitelisting
   applications, respond to requests for additional information related is functionally similar to these applications, determine when and if applications have been
   denied, manage appeals, Content Delivery
   Networks (CDNs) and track any de-whitelisting actions.

   Given the large number Global Server Load Balancing (GSLB).  When using
   a CDN or GSLB, a geographically-aware authoritative DNS server
   function is usually part of domains in existence, the ease with which that overall system.  As a
   new domain can be added, and the continued strong growth in result, the
   numbers
   use of new domains, readers should not underestimate a CDN or GSLB with an authoritative DNS server function
   enables the
   potential significance IP address resource records returned to a resolver in personnel and expense that this could
   represent for such operators.  In addition, it is likely that systems
   and personnel may also be needed
   response to handle new end user requests for
   domains for which a query to apply for DNS Whitelisting, and/or inquiries
   into vary based on the status of a whitelisting application, reports estimated geographic
   location of de-
   whitelisting incidents, general inquiries related to DNS
   Whitelisting, and requests for DNS Whitelisting-related
   troubleshooting by these end users.

7.3.4.  Monitoring Implications

   Once a DNS recursive the resolver has been whitelisted for [Wild-Resolvers] or a particular
   domain, then the operator range of that other
   technical factors.  This CDN or GSLB DNS recursive resolver may need to
   implement monitoring function is performed in
   order to detect the possible loss of DNS
   Whitelisting in the future.  This DNS recursive resolver operator
   could configure a monitor attempt to check for a AAAA response in the
   whitelisted domain, as a check direct hosts to validate continued status on the
   DNS whitelist.  The monitor could then trigger an alert if at some
   point the AAAA responses were no longer received, so that operations
   personnel could begin troubleshooting, as outlined in Section 7.3.6.

   Also, authoritative DNS server operators are likely connect to the nearest hosts (as
   measured in round trip time), to need the host that has the best
   connectivity to
   implement new forms of monitoring.  In this case, they may desire an end user, to route around failures, to avoid sites
   where maintenance work has taken down hosts, and/or to
   monitor for significant changes in the size of host that
   will otherwise provide the whitelist within best service experience for an end user at
   a
   certain period of time, which might be indicative of given point in time.  As a technical
   error such as the entire ACL being removed.  Authoritative DNS server
   operators may also wish result, one can see a direct similarity
   to monitor their workflow process for
   reviewing and acting upon DNS Resolver Whitelisting applications and appeals,
   potentially measuring and reporting insofar as different IP address resource
   records are selectively returned to resolvers based on service level commitments
   regarding the time an application or appeal can remain at each step
   of the process, regardless IP address
   of whether or not such information is
   shared with parties each resolver and/or other than imputed factors related to that authoritative IP
   address.

4.3.3.  Similarities to DNS server
   operator.

7.3.5.  Implications Load Balancing

   DNS Resolver Whitelisting has some similarities to DNS load
   balancing.  There are of Operational Momentum

   It seems plausible course many ways that once DNS Whitelisting is implemented it will load balancing can
   be very difficult performed.  In one example, multiple IP address resource records
   (A and/or AAAA) can be added to deprecate such technical and operational
   practices. the DNS for a given FQDN.  This assumption
   approach is based on an understanding of human
   nature, not referred to mention physics.  For example, as Sir Isaac Newton
   noted, "Every object in a state of uniform motion tends to remain in
   that state DNS round robin [RFC1794].  DNS round
   robin may also be employed where SRV resource records are used
   [RFC2782].  In another example, one or more of motion unless an external force is applied to it"
   [Motion].  Thus, once the IP address
   resource records in the DNS Whitelisting is implemented it is quite
   likely that it would take considerable effort will direct traffic to deprecate the
   practice a load balancer.
   That load balancer, in turn, may be application-aware, and remove it everywhere on pass the Internet; it may otherwise
   simply remain in place in perpetuity.  To illustrate this point, one
   could consider for example that there are many email servers
   continuing
   traffic on to attempt one or more hosts connected to query anti-spam DNS blocklists the load balancer which
   have
   long ago ceased to exist.

7.3.6.  Troubleshooting Implications

   The implications of DNS whitelisted present many challenges, as
   detailed throughout Section 7.  These challenges may negatively
   affect the end users' ability to troubleshoot, different IP addresses.  In cases where private IPv4 addresses
   are used [RFC1918], as well as that of DNS
   recursive resolver operators, ISPs, content providers, domain owners
   (where they when public IP addresses are used,
   those end hosts may not necessarily be different from the operator of directly reachable without
   passing through the authoritative load balancer first.  So, similar to DNS server for their domain), and other third parties.  This may make
   the process of determining why Resolver
   Whitelisting, a load balancer will control what server is not reachable via host an end
   user's host communicates with when using a FQDN
   significantly more complex and time-consuming.

7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis

   As more domains choose FQDN.

4.3.4.  Similarities to implement Split DNS Whitelisting, and more
   networks become IPv6-capable and request

   DNS Resolver Whitelisting has some similarities to be whitelisted, scaling
   up operational processes, monitoring, and ACL updates will become
   more difficult.  The increased rate of change and increased size so-called split
   DNS, briefly described in Section 3.8 of
   whitelists will increase [RFC2775].  When split DNS
   is used, the authoritative DNS server selectively returns different
   responses depending upon what host has sent the query.  While

   [RFC2775] notes the likelihood typical use of configuration and other
   operational errors.

   It split DNS is unclear when and if it would be appropriate to change from
   whitelisting provide one answer
   to blacklisting.  It also seems unlikely for such hosts on an Intranet (internal network) and a
   change from whitelisting to blacklisting different answer to be coordinated across
   hosts on the
   Internet, so such a change Internet (external or public network), the basic idea is
   that different answers are provided to blacklisting will likely occur hosts on an
   ad-hoc basis as well (if at all).

   Finally, some implementers consider DNS Whitelisting to be a
   temporary measure.  As such, it different networks.
   This is not clear how these implementers
   will judge the network conditions to have changed sufficiently similar to
   justify disabling the way that DNS Resolver Whitelisting (or blacklisting, or other AAAA
   resource record access controls) and/or what works,
   whereby hosts on different networks which use different DNS recursive
   resolvers, receive different answers if one DNS recursive resolver is
   on the process whitelist and timing
   will be the other is not.  However, Internet
   transparency and Internet fragmentation concerns regarding split DNS
   are detailed in order Section 2.1 of [RFC2956] and Section 2.7 notes
   concerns regarding split DNS and that it "makes the use of Fully
   Qualified Domain Names (FQDNs) as endpoint identifiers more complex".
   Section 3.5 of [RFC2956] further recommends that maintaining a stable
   approach to discontinue this practice.

7.4.  Homogeneity May Be Encouraged

   A broad trend on DNS operations is key during transitions, such as the Internet one
   to IPv6 that is a move toward more heterogeneity.
   One manifestation underway now, stating that "Operational stability of this
   DNS is in an increasing number, variety, and
   customization paramount, especially during a transition of end user hosts, including home networks, operating
   systems, client software, home the network devices,
   layer, and personal
   computing devices.  This trend appears to have had both IPv6 and some network address translation techniques
   place a positive effect heavier burden on the development DNS."

4.3.5.  Related Considerations

   While techniques such as GLSB and DNS load balancing, which share
   much in common with DNS Resolver Whitelisting and growth are widespread,
   some in the community have raised a range of concerns about the Internet
   practice.  Some concerns are specific DNS Resolver Whitelisting
   [WL-Concerns].  Other concerns are not as specific and has enabled end
   users to connect any technically compliant device or use any
   technically compatible software to connect pertain to the Internet.  Not only
   does this trend towards greater heterogeneity reduce the control
   which is exerted
   general practice of implementing content location or other network
   policy controls in the middle "middle" of the network, described positively network in [Tussle], [Rethinking], and [RFC3724], but it also appears to help
   to enable greater and more rapid innovation a so-called
   "middlebox" function.  Whether such DNS-related functions are really
   part of a middlebox is debatable.  Nevertheless, implementers should
   at the edge least be aware of some of the
   network.

   Some forms risks of so-called "network neutrality" principles around middleboxes, as noted in
   [RFC3724].  A related document, [RFC1958] explains that the
   world include state,
   policies, and other functions needed in the notion that any IP-capable device middle of the network
   should be able to
   connect to minimized as a network, encouraging heterogeneity.  These principles
   are often explicitly encouraged by application providers, though some design goal.  In addition, Section 2.16 of these same providers may be using
   [RFC3234] makes specific statements concerning modified DNS Whitelisting.  This is
   ironic, as one implication of servers.
   [RFC3234] also outlines more general concerns in Section 1.2 about
   the adoption introduction of DNS Whitelisting new failure modes when configuration is
   that it could encourage a move back towards homogeneity resulting
   from greater control over devices in order to attempt to enforce
   technical requirements intended to reduce IPv6-related impairments.
   This return no longer
   limited to an environment two ends of more homogenous and/or controlled
   end user hosts could have unintended side effects on and counter-
   productive implications for future innovation at the edge a session, so that diagnosis of failures and
   misconfigurations could become more complex.  Two additional sources
   worth considering are [Tussle] and [Rethinking], in which the
   network.

7.5.  Technology Policy Implications

   A key technology policy implication authors
   note concerns regarding the policies introduction of new control points (such
   as in middleboxes), including in the DNS.

   However, some state, policies, and
   processes related other functions have always been
   necessary to reviewing enable effective, reliable, and making decisions high-quality end-to-end
   communications on DNS
   Whitelisting applications for a domain, as well the Internet.  In addition, techniques such as making any
   possible de-whitelisting decisons.  Important questions may include
   whether these policies have been fully and transparently disclosed,
   are non-discriminatory,
   Global Server Load Balancing, Content Delivery Networking, DNS Load
   Balancing and Split DNS are not anti-competitive.  Key questions
   here may include whether appeals only widely deployed but are allowed, what the process is,
   what the expected turn around time is, and whether the appeal will be
   handled by an independent third party.

   It is also conceivable that whitelisting and de-whitelisting
   decisions could be quite sensitive almost
   uniformly viewed as essential to concerned parties beyond the
   operator functioning of the domain operator Internet and
   highly beneficial to the operator quality of the DNS recursive
   resolver, including end users, application developers, content
   providers, advertisers, public policy groups, governments, and other
   entities. user experience on the
   Internet.  These concerned parties may seek techniques have had and continue to become involved have a
   beneficial effect on the experience of a wide range of Internet
   applications and protocols.  So while there are valid concerns about
   implementing policy controls in the "middle" of the network, or
   express opinions concerning whitelisting and/or de-whitelisting
   decisions.

   A final concern is that decisions relating to whitelisting
   anywhere away from edge hosts, the definition of what constitutes the
   middle and de-
   whitelisting may occur as an expression edge of other commercial,
   governmental, and/or cultural conflicts, given the new control point
   which has been established with DNS Whitelisting.  For example, network is debatable in
   one imagined scenario, a domain this case.  This is
   particularly so given that GSLBs and CDNs facilitate connections from
   end host and the optimal content hosts, and could withhold adding therefore be
   considered a modest and in many cases essential network to
   their DNS Whitelisting unless that network agreed to some sort policy
   extension of
   financial payment, legal agreement, agreement to sever a relationship
   with a competitor of network's edge, especially in the domain, etc.  In another example, a music-
   oriented domain case of high-traffic
   domains.

   There may be engaged in some sort of dispute with an
   academic network concerning copyright infringement concerns within additional implications for end users that network, and may choose have
   configured their hosts to de-whitelist that network as use a
   negotiating technique in some sort of commercial discussion. third party as their DNS recursive
   resolver, rather than the one(s) provided by their network operator.
   In such cases, it will be more challenging for a
   final example, a major email domain may choose to de-whitelist a
   network due using
   whitelisting to that network sending some large volume determine the level of spam.  Thus,
   it seems possible that whitelisting and de-whitelisting could become
   a vehicle for adjudicating other disputes, IPv6-related impairment when
   such third-party DNS recursive resolvers are used, given the wide
   variety of end user access networks which may be used and that this
   mix may well
   have consequences for end users which change in unpredictable ways over time.

4.4.  Implement DNS Blacklisting

   With DNS Resolver Whitelisting, DNS recursive resolvers can receive
   AAAA resource records only if they are affected on the whitelist.  DNS
   Blacklisting is by such decisions
   and contrast the the opposite of that, whereby all DNS
   recursive resolvers can receive AAAA resource records unless they are unable to express a strong voice in such decisions.

7.6.  IPv6 Adoption Implications

   As noted in Section 6,
   on the implications blacklist.  Some implementers of DNS Resolver Whitelisting may drive
   end users and/or networks
   choose to delay, postpone, or cancel adoption of
   IPv6, or subsequently transition to DNS Blacklisting.  It is unclear
   when and if it may be appropriate for a domain to actively seek alternatives change from
   whitelisting to it.  Such alternatives may
   include blacklisting.  Nor is it clear how implementers will
   judge the use of multi-layer or large scale network address
   translation (NAT) techniques, which these parties may decide conditions to
   pursue on have changed sufficiently to justify
   disabling such controls.

   When a long-term basis domain uses blacklisting, they are enabling all DNS recursive
   resolvers to avoid the perceived costs and
   aggravations related receive AAAA record responses except for what is
   presumed to DNS Whitelisting.  This could of course come
   at be a relatively small number that are on the very blacklist.
   Over time it is likely that the Internet community is trying to get these
   very same parties interested in IPv6 and motivated to begin blacklist will become smaller as the
   transition
   networks associated with the blacklisted DNS recursive resolvers are
   able to IPv6.  As a result, parties meaningfully reduce IPv6-related impairments to some
   acceptable level, though it is possible that are some networks may never
   achieve that.  DNS Blacklisting is also likely to be
   concerned over the negative implications of less labor intensive
   for a domain than performing DNS Resolver Whitelisting could
   logically on a manual
   basis.  This is simply because the domain would presumably be concerned focused
   on a smaller number of the negative effects DNS recursive resolvers with well known IPv6-
   related problems.

   It is also worth noting that this practice
   could have on the adoption of IPv6 email industry has a long experience
   with blacklists and, very generally speaking, blacklists tend to be
   effective and well received when it is easy to discover if an IP
   address is on a blacklist, if there is a transparent and easily
   understood process for requesting removal from a blacklist, and if it became widespread.

   At
   the same time, decision-making criteria for placing a server on a blacklist is
   transparently disclosed and perceived as noted fair.  However, in Section 4, some high-traffic domains
   may find the prospect of transitioning contrast
   to IPv6 daunting without
   having some short-term ability an email blacklist where a blacklisted host cannot send email to incrementally control the amount
   and source of IPv6 traffic a
   domain at all, with DNS Resolver Whitelisting communications will
   still occur over IPv4 transport.

4.5.  Transition Directly to their domains.  Lacking such controls,
   some Native Dual Stack

   As an alternative to adopting any of the aforementioned transition
   techniques, domains may can choose to substantially delay their transition to
   IPv6.

7.7.  Implications with Poor IPv4 and Good native dual stack
   directly by adding native IPv6 Transport

   It is possible that there could be situations where the differing
   quality of the IPv4 capabilities to their network and IPv6 connectivity of an end user could cause
   complications in accessing content which is
   hosts and by publishing AAAA resource records in a whitelisted domain,
   when the end user's DNS recursive resolver is not for named
   resources within their domain.  Of course, a domain can still control
   this transition gradually, on that whitelist.
   While today most end users' IPv4 connectivity is typically superior
   to a name-by-name basis, by adding native
   IPv6 connectivity (if such connectivity exists to one name at all), there
   could a time, such as mail.example.com first and
   www.example.com later.  So even a "direct" transition can be implications when the reverse
   performed gradually.

   It is true then up to end users with IPv6-related impairments to discover
   and fix any applicable impairments.  However, the concerns and end user has
   markedly superior IPv6 connectivity as compared risks
   related to traffic volume Section 2.3 should still be considered and
   managed, since those are not directly related to IPv4.  This is
   admittedly theoretical but could become a factor as such impairments.
   Not all content providers (or other domains) may face the transition challenges
   detailed herein or face them to
   IPv6 continues the same degree, since the user base
   of each domain, traffic sources, traffic volumes, and IPv4 address availability within networks becomes
   strained. other factors
   obviously varies between domains.

   For example, in one possible scenario, a user is issued while some content providers have implemented DNS
   Resolver Whitelisting (one transition technique), others have run
   IPv6
   addresses by their ISP experiments whereby they added AAAA resource records and has a home network
   observed and devices or
   operating systems which fully support IPv6.  As a result this
   theoretical user has very good IPv6 connectivity.  However, this end
   user's ISP may have exhausted their available pool of unique IPv4
   address, measured errors, and so that ISP uses NAT in order then decided not to reuse IPv4 addresses.
   So for IPv4 content, implement DNS
   Resolver Whitelisting [Heise].  A more widespread such experiment was
   World IPv6 Day [W6D], sponsored by the end user must send their IPv4 traffic
   through some additional network element (e.g.  NAT, proxy, tunnel
   server).  Use Internet Society, on June 8,
   2011.  This was a unique opportunity for hundreds of this additional network element may cause the end
   user domains to experience sub-optimal IPv4 connectivity when certain
   protocols or applications are used.  This user then has good IPv6
   connectivity but impaired IPv4 connectivity.  Furthermore, this end
   user's add
   AAAA resource records to the DNS recursive resolver is not whitelisted by without using DNS Resolver
   Whitelisting, all at the authoritative
   server for a domain that same time.  Some of the user is trying participating
   domains chose to access, meaning leave AAAA resource records in place following the
   end user only gets A record responses for
   experiment based on their impaired IPv4
   transport rather than also AAAA record responses for experiences.

   Content providers can run their stable and
   well-performing IPv6 transport.  Thus, the user's poor IPv4
   connectivity situation is potentially exacerbated by not having
   access to a given domain's IPv6 content since they must use own independent experiments in the
   address family with relatively poor performance.

7.8.  Implications
   future, adding AAAA resource records for Users of Third-Party DNS Recursive Resolvers

   In most cases it is assumed that end users will make use a brief period of DNS
   recursive resolvers which are operated by their access network
   provider, whether that is an ISP, campus network, enterprise network, time
   (minutes, hours, or some other type days), and then analyzing any impacts or effects
   on traffic and the experience of network.  However there are also cases where an end user has changed their DNS server IP addresses in users.  They can also simply
   turn on IPv6 for their device's
   operating system to those of a third party domain, which operates DNS
   recursive resolvers independently of end user access networks.

   In these cases, an authoritative DNS server may receive a query from be easier when the
   transition does not involve a DNS recursive resolver high-traffic domain.

5.  Potential Implementation Phases

   These usefulness of each technique in Section 4, and the associated
   pros and cons associated with each technique, is relative to each
   potential implementer and will therefore vary from one network, though implementer to
   another.  As a result, it is not possible to say that the end user sending potential
   phases below make sense for every implementer.  This also means that
   the original query is in an entirely duration of each phase will vary between implementers, and even
   that different network.  It implementers may
   therefore be more challenging for a DNS Whitelist implementer to
   determine the level skip some of IPv6-related impairment when such third-party
   DNS recursive resolvers these phases entirely.
   Finally, the techniques listed in Section 4 are used, given by no means
   exclusive.

5.1.  No Access to IPv6 Content

   In this phase, a site is accessible only via IPv4 transport.  As of
   the wide variety time of end user
   access networks which may be used and that this mix may change document, the majority of content on the Internet is
   in
   unpredictable ways over time.

   There may also be cases where end users' assigned DNS recursive
   resolvers have this state and is not been whitelisted accessible natively over IPv6.

5.2.  Using IPv6 Transition Names

   One possible first step for a particular domain, but
   where the end user tries to switch domain is to gain experience using a third-party DNS recursive
   resolver that has been whitelisted.  While in most cases the end user
   will be able to switch to use that third-party's DNS servers, some
   specialized access networks, new FQDN, such as ipv6.example.com or
   www.ipv6.example.com, as explained in hotels and conference
   centers, may prevent Section 4.2.

5.3.  Deploying DNS Resolver Whitelisting Using Manual Processes

   As noted in Section 4.3, a domain could begin using third-party DNS servers.  In these cases,
   end users may be frustrated at their inability Resolver
   Whitelisting as a way to incrementally enable IPv6 access certain
   content over IPv6, resulting in complaints to both content.
   This tactic may be especially interesting to high-traffic domains.

5.4.  Deploying DNS Resolver Whitelisting Using Automated Processes

   For a particular domain as well as that decides to undertake DNS Resolver Whitelisting on a
   manual basis, the access network operator.

8.  Is domain may subsequently move to perform DNS
   Resolver Whitelisting on an automated basis.  This is explained in
   Section 4.3, and can significantly ease any operational burdens
   relating to a Recommended Practice?

   Opinions in the Internet community concerning whether or not manually-maintained whitelist.

5.5.  Turning Off DNS Resolver Whitelisting is a recommended practice are understandably quite
   varied.  However, there is clear consensus

   Domains that choose to implement DNS Resolver Whitelisting can generally
   consider it to be a useful tactic a domain may choose to use as they transition temporary measure.  It is unclear how
   implementers will judge when the network conditions will have changed
   sufficiently to
   IPv6.  In particular, some high-traffic domains view justify turning off DNS Resolver Whitelisting
   as one of and/or
   what the few practical process and low-risk approaches enabling them to
   transition to IPv6, without which their transition may not take place timing will be for some time.  However, there is also consensus is that discontinuing this
   practice is workable only practice,
   though the extent of IPv6 deployment to end users in networks, the short-term
   state of IPv6-related impairment, and that the maturity of IPv6 operations
   are all clearly factors.  However, implementers may wish to take into
   consideration that, as a practical matter, it will be impossible to
   get to a point where there are no longer any IPv6-related
   impairments; some reasonably small number of hosts will inevitably be
   left behind as end users elect not
   scale over the long-term.  Thus, to upgrade them or as some domains may find hosts
   are incapable of being upgraded.

5.6.  Deploying DNS Blacklisting

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

5.7.  Fully Dual-Stack Content

   A domain can arrive at this phase either following the use of a beneficial temporary tactic in their
   previous IPv6 transition technique, or they may go directly to
   IPv6.  Such temporary use during this
   point as noted in Section 4.5.  In this phase the transition to site's content has
   been made natively accessible via both IPv4 and IPv6 is broadly
   accepted within for all end
   users on the community, so long as it does not become a long-
   term practice.

9. Internet, or at least without the use of any other IPv6
   transition technique.

6.  Other Considerations

6.1.  Security Considerations

   If DNS Resolver Whitelisting is adopted, as noted in Section 4.3,
   then organizations which apply DNS Resolver Whitelisting policies in
   their authoritative servers should have procedures and systems which
   do not allow unauthorized parties to
   either remove whitelisted DNS recursive resolvers from modify the whitelist or add non-whitelisted DNS recursive resolvers to the whitelist,
   blacklist, just as all configuration settings for name servers should
   be protected by appropriate procedures and systems.  Should such  Such
   unauthorized additions or removals from the whitelist can be quite
   damaging, and
   result in causing content providers and/or ISPs network operators to incur substantial
   support costs resulting from end user and/or customer contacts.  As such,
   great care must be taken to control access contacts, as
   well as causing potential dramatic and disruptive swings in traffic
   from IPv6 to the whitelist for an
   authoritative server.

   In addition, two other key security-related issues should be taken
   into consideration:

9.1.  DNSSEC Considerations IPv4 or vice versa.

   DNS security extensions defined in [RFC4033], [RFC4034], and
   [RFC4035] use cryptographic digital signatures to provide origin
   authentication and integrity assurance for DNS data.  This is done by
   creating signatures for DNS data on a Security-Aware Authoritative
   Name Server that can be used by Security-Aware Resolvers to verify
   the answers.  Since DNS Resolver Whitelisting is implemented on an
   authoritative DNS server, which provides different answers depending
   upon which DNS resolver has sent a query, the DNSSEC chain of trust
   is not altered.  Even  So even though the an authoritative DNS server will not
   always
   selectively return a AAAA resource record when one exists, respective records and/or A resource records and AAAA records,
   these resource records can and should both certainly still be signed.  Therefore  As a result,
   there are no DNSSEC implications per se.  However,
   any implementer of DNS Whitelisting should not be careful if they
   implement any negative impact on DNSSEC for those domains
   that have implemented both DNSSEC signing of on their domain Security-Aware
   Authoritative Name Servers and also implemented DNS
   Whitelisting Resolver
   Whitelisting.  As for any party implementing DNSSEC of that same domain.  Specifically, those course, such
   domains should ensure that resource records are being appropriately
   and reliably
   signed, which may present modest incremental operational and/or
   technical challenges. signed.

   However, as noted in fourth paragraph of Section 4.2, end user network operators that run DNS recursive resolvers should be
   careful not to modify the responses received from authoritative DNS
   servers.  It is possible that some networks may also choose attempt to implement tools at their disposal do so in
   order to address IPv6-related impairments.  One of those tools could
   involve unspecified changes prevent AAAA record responses from going to the configuration end user hosts,
   due to some IPv6-related impairment or other lack of their DNS
   recursive resolvers.  If those are IPv6 readiness
   with that network.  But when a network operates a Security-Aware Resolvers,
   Resolver, modifying or suppressing AAAA resource records for a
   DNSSEC-signed domain will be problematic and could break the chain of trust established with
   DNSSEC.

9.2.  Authoritative DNS Response Consistency

6.2.  Privacy Considerations

   In addition to the considerations raised

   As noted in Section 9.1, it 4.1, there is
   conceivable that security concerns may arise when end users or other
   parties notice that a benefit in sharing IPv6-related
   impairment statistics within the responses sent from Internet community over time.  Any
   such statistics probably should be high-level statistics, such as
   "the domain example.com has observed an authoritative DNS
   server appear to vary average daily impairment rate
   of 0.05% in September 2011, down from one network or one DNS recursive resolver
   to another.  This may give rise to concerns that, since the
   authoritative responses vary that there is some sort 0.15% in January 2011".  In
   contrast, sharing a list of security
   issue names and/or some or none email addresses of the responses end
   users of a domain with impairments is probably not well advised from
   a privacy standpoint.  Thus, sharing only summary data can be trusted.  While
   this help
   protect end user privacy and any information which may seem be proprietary
   to a somewhat obscure concern, domains nonetheless domain.

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

   Appropriate guidelines for any information sharing likely varies by
   country and/or legal jurisdiction.  Domains should consider any
   potential privacy issues when contemplating whether considering what information can be
   shared.  If a domain does publish or not share detailed impairment
   statistics, they would be well advised to pursue DNS
   Whitelisting.

10.  Privacy avoid identifying
   individual hosts or users.

6.3.  Considerations

   As noted with Poor IPv4 and Good IPv6 Transport

   There are situations where the differing quality of the IPv4 and IPv6
   connectivity of an end user could cause complications in Section 5.3.1, there may be methods to detect IPv6-
   related impairments for accessing
   content when a particular domain is using an IPv6 transition technique.  While
   today most end user.  For example, this may users' IPv4 connectivity is typically superior to IPv6
   connectivity (if such connectivity exists at all), there could be possible
   implications when an the reverse is true and and end user visits the website of has markedly
   superior IPv6 connectivity as compared to IPv4.  This is not a particular
   domain.  In that
   theoretical situation; it has been observed by at least one major
   content provider.

   For example, there are likely no privacy considerations in automatically communicating to that end one possible scenario, a user that the domain is issued IPv6
   addresses by their ISP and has
   detected a particular impairment. home network and devices or
   operating systems which fully support native IPv6.  As a result this
   theoretical user has very good IPv6 connectivity.  However, if that domain decided this end
   user's ISP has exhausted their available pool of unique IPv4 address,
   and uses NAT in order to share information concerning that particular IPv4 addresses among end user with their
   network operator or another party, then the visited domain may wish
   to in some manner advise users.  So
   for IPv4 content, the end user must send their IPv4 traffic through
   some additional network element (e.g. large scale NAT, proxy server,
   tunnel server).  Use of this or otherwise seek additional network element might cause
   an end user to
   obtain experience sub-optimal IPv4 connectivity when certain
   protocols or applications are used.  This user then has good IPv6
   connectivity but impaired IPv4 connectivity.  As a result, the user's consent to such information sharing.  This may
   poor IPv4 connectivity situation could potentially be
   achieved in exacerbated
   when accessing a wide variety of ways, from presenting domain which is using a message asking
   the transition technique that
   causes this user to only be able to access content over IPv4
   transport for consent (which will whatever reason.

   Should this sort of course help them solve situation become widespread in the future, a
   technical problem of which they are likely unaware) to adding this
   domain may wish to
   a domain's website terms of use / service.  Such information sharing take it into account when deciding how and communication of such sharing when to end users may well vary by
   geographic area and/or legal jurisdiction.  Thus, a domain should
   consider any potential privacy issues these sorts of scenarios.

   To the extent that domains or network operators decide
   transition content to publish
   impairment statistics, they should not identify individual hosts,
   host identifiers, or users.

11. IPv6.

6.4.  IANA Considerations

   There are no IANA considerations in this document.

12.

7.  Contributors

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

   - John Brzozowski

   - Chris Griffiths

   - Tom Klieber

   - Yiu Lee

   - Rich Woundy

13.

8.  Acknowledgements

   The author and contributors also wish to acknowledge the assistance
   of the following individuals or groups.  Some of these people
   provided helpful and important guidance in the development of this
   document and/or in the development of the concepts covered in this
   document.  Other people assisted by performing a detailed review of
   this document, and then providing feedback and constructive criticism
   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 following individuals merit acknowledgement:

   - Bernard Aboba

   - Jari Arkko

   - Fred Baker

   - Ron Bonica

   - Frank Bulk

   - Brian Carpenter

   - Lorenzo Colitti

   - Alissa Cooper

   - Dave Crocker

   - Ralph Droms

   - Wesley Eddy
   - J.D. Falk

   - Adrian Farrel

   - Stephen Farrell

   - Tony Finch

   - Karsten Fleischhauer

   - Igor Gashinsky

   - Wesley George

   - Philip Homburg

   - Jerry Huang

   - Ray Hunter

   - Joel Jaeggli

   - Erik Kline

   - Suresh Krishnan

   - Victor Kuarsingh

   - 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)

14.

9.  References

14.1.

9.1.  Normative References

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

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

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

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

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

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

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

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

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

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

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

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

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

14.2.

9.2.  Informative References

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

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

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

   [IPv6-Growth]
              Colitti, L., Gunderson, S., Kline, E., and T. Refice,
              "Evaluating IPv6 adoption in the Internet", Passive and
              Active Management (PAM) Conference 2010, April 2010,
              <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/>.

   [Motion]   Newton, I., "Mathematical Principles of Natural Philosophy
              (Philosophiae Naturalis Principia Mathematica)",
              Principia Mathematical Principles of Natural Philosophy
              (Philosophiae Naturalis Principia Mathematica), July 1687,
              <http://en.wikipedia.org/wiki/Newton's_laws_of_motion>.

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

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

   [Rethinking]
              Blumenthal, M. and D. Clark, "Rethinking the design of the
              Internet: The end to end arguments vs. the brave new
              world", ACM Transactions on Internet Technology Volume 1,
              Number 1, Pages 70-109, August 2001, <http://
              dspace.mit.edu/bitstream/handle/1721.1/1519/
              TPRC_Clark_Blumenthal.pdf>.

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

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

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

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

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

Appendix A.  Document Change Log

   [RFC Editor: This section is to be removed before publication]

   -07: Significant re-write based on feedback from Jari Arkko, Joel
   Jaeggli, Fred Baker, Igor Gashinsky, Donn Lee, Lorenzo Colitti, and
   Erik Kline.

   -06: Removed the Open Issue #8 concerning the document name, at the
   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 changed 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

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

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