IPv6 Operations                                             J. Livingood
Internet-Draft                                                   Comcast
Intended status: Informational                              May 30,                              June 8, 2011
Expires: December 1, 10, 2011

                IPv6 AAAA DNS Whitelisting Implications
         draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05
         draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06

Abstract

   The objective of this

   This document is to describe describes the practice and implications of whitelisting of
   DNS recursive resolvers in order to limit AAAA resource records responses, which record
   responses (which contain IPv6 addresses, hereafter
   referred to as addresses) sent by authoritative DNS Whitelisting, as well as the implications of this
   emerging practice and what alternatives or variations may exist.
   servers.  This practice is a type of an IPv6 transition mechanism used by domains, domains as a
   method for incrementally transitioning inbound traffic to a domain
   from IPv4 to IPv6 transport.  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 1, 10, 2011.

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 . . . . . . . . . . . . . . . . . .  5
     2.1.  Description of the Operation of DNS Whitelisting . . . . .  6
     2.2.  Comparison with Blacklisting . . . . . . . . . . . . . . .  8  9
   3.  What Problems Are Implementers Trying To Solve?  Similarities to Other DNS Operations . . . . . . .  8
     3.1.  IPv6-Related Impairment . . . . . .  9
     3.1.  Similarities to Split DNS  . . . . . . . . . . . . . . . .  9
     3.2.  Similarities to DNS Load Balancing . . . . . . . . . . . . 10
   4.  What Problems Are Implementers Trying To Solve?  . . . . . . . 10
     4.1.  Volume-Based Concerns  . . . . . . . . . . . . . . . . . . 10
     3.3.  Free Versus Subscription Services 11
     4.2.  IPv6-Related Impairment  . . . . . . . . . . . . . 10
   4.  Concerns Regarding DNS Whitelisting . . . . 11
     4.3.  Free Versus Subscription Services  . . . . . . . . . . . . 10 13
   5.  Similarities to Other DNS Operations  General Implementation Variations  . . . . . . . . . . . . . . 13
     5.1.  Similarities to Split  Implement DNS Whitelisting Universally . . . . . . . . . . 13
     5.2.  Implement DNS Whitelisting On An Ad Hoc Basis  . . . . . . 13
     5.2.  Similarities to 14
     5.3.  Do Not Implement DNS Load Balancing Whitelisting  . . . . . . . . . . . . 13
   6.  Possible Deployment Scenarios 14
       5.3.1.  Solve Current End User IPv6 Impairments  . . . . . . . 14
       5.3.2.  Gain Experience Using IPv6 Transition Names  . . . . . 15
       5.3.3.  Implement DNS Blacklisting . . . . . . . . 14
     6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 15
     6.2.  Deploying
   6.  Concerns Regarding DNS Whitelisting Universally  . . . . . . . . . . 15 . . . 16
   7.  Implications of DNS Whitelisting . . . . . . . . . . . . . . . 16 17
     7.1.  Architectural Implications . . . . . . . . . . . . . . . . 16 17
     7.2.  Public IPv6 Address Reachability Implications  . . . . . . 17 18
     7.3.  Operational Implications . . . . . . . . . . . . . . . . . 18 19
       7.3.1.  De-Whitelisting May Occur  . . . . . . . . . . . . . . 18 19
       7.3.2.  Authoritative DNS Server Operational Implications  . . 18 19
       7.3.3.  DNS Recursive Resolver Server Operational
               Implications . . . . . . . . . . . . . . . . . . . . . 19 20
       7.3.4.  Monitoring Implications  . . . . . . . . . . . . . . . 20 21
       7.3.5.  Implications of Operational Momentum . . . . . . . . . 20 22
       7.3.6.  Troubleshooting Implications . . . . . . . . . . . . . 21 22
       7.3.7.  Additional Implications If Deployed On An Ad Hoc
               Basis  . . . . . . . . . . . . . . . . . . . . . . . . 21 22
     7.4.  Homogeneity May Be Encouraged  . . . . . . . . . . . . . . 22 23
     7.5.  Technology Policy Implications . . . . . . . . . . . . . . 22 23
     7.6.  IPv6 Adoption Implications . . . . . . . . . . . . . . . . 23 24
     7.7.  Implications with Poor IPv4 and Good IPv6 Transport  . . . 24 25
     7.8.  Implications for Users of Third-Party DNS Recursive
           Resolvers  . . . . . . . . . . . . . . . . . . . . . . . . 25
   8.  General Implementation Variations  . . . . . . . . . . . . . . 25
     8.1.  Implement DNS Whitelisting Universally . . . . . . . . . . 26
     8.2.  Implement DNS Whitelisting On An Ad Hoc Basis  . . . . . . 26
     8.3.  Do Not Implement DNS Whitelisting  . . . . . . . . . . . . 26
       8.3.1.  Solve Current End User IPv6 Impairments  . . . . . . . 26
       8.3.2.  Gain Experience Using IPv6 Transition Names  . . . . . 27
       8.3.3.  Implement DNS Blacklisting . . . . . . . . . . . . . . 27
   9.  Is DNS Whitelisting a Recommended Practice?  . . . . . . . . . 28
   10. 26
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
     10.1. 26
     9.1.  DNSSEC Considerations  . . . . . . . . . . . . . . . . . . 29
     10.2. 27
     9.2.  Authoritative DNS Response Consistency Considerations  . . 29
   11. 27

   10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 30
   12. 28
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   13. 28
   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
   14. 28
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
   15. 29
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     15.1. 30
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     15.2. 30
     14.2. Informative References . . . . . . . . . . . . . . . . . . 33 31
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 35 33
   Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 37 36
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 36

1.  Introduction

   This document describes the emerging practice and implications of whitelisting of
   DNS recursive resolvers in order to limit AAAA resource record (RR)
   responses, which
   responses (which contain IPv6 addresses, hereafter addresses) sent by authoritative DNS
   servers.  This is referred to hereafter as DNS Whitelisting.  The document explores the implications of this
   emerging practice are and what alternatives may exist.  This is
   an IPv6 transition mechanism used by domains as a method for
   incrementally transitioning inbound traffic to a domain from IPv4 to
   IPv6 transport.  When implemented, DNS Whitelisting in practice means that a domain's authoritative DNS will
   return a AAAA resource record to DNS recursive resolvers [RFC1035] on
   the whitelist, while returning no AAAA resource records to DNS
   recursive resolvers which are not on the whitelist.
   This practice is a type of IPv6 transition mechanism used by domains,
   as a method for incrementally transitioning inbound traffic to a
   domain from IPv4 to IPv6 transport.  The practice
   appears to have first been used by major web content sites (sometimes
   described
   herein hereafter as "high-traffic domains"), which have specific
   concerns relating to maintain maintaining a high-quality user experience for
   all of their users during their transition to IPv6.

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

   o  DNS Whitelisting is a very different behavior from the current
      practice concerning the publishing 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 or likely to cause conflict,

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

   o  that new operational and management burdens 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 and negative implications of DNS Whitelisting
      outweigh the perceived benefits.

   This document explores the reasons and motivations for DNS
   Whitelisting Section 3. 4.  It also explores the concerns regarding this
   practice, and whether and when the practice is recommended Section 9. 8.
   Readers will hopefully better understand what DNS Whitelisting is,
   why some parties domains are implementing it, and what criticisms of the
   practice exist. implications are.

2.  How DNS Whitelisting Works

   At a high level,

   Generally, using a whitelist means no traffic (or traffic of a
   certain type) is permitted to the destination host unless the
   originating host's IP address is contained in the whitelist.  In
   contrast, using a blacklist means that all traffic is permitted to
   the destination host unless the originating host's IP address is
   contained in the blacklist.

   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 server site operators
   deploying IPv6-enabled services, though this practice would could affect
   any
   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 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 ISPs, Internet Service Providers (ISPs),
   universities, governments, businesses, and individual end users.  If
   a DNS recursive resolver IS NOT matched in the ACL, then AAAA
   resource records will WILL NOT be sent in response to a query for a
   hostname in the example.com domain.  However, if a DNS recursive
   resolver IS matched in the ACL, then AAAA resource records
   will WILL be
   sent in response to a query for a given hostname in the example.com
   domain.  While these are not network-layer access controls (as many
   ACLs are) they are nonetheless access controls that are a factor for
   end users and other parties like organizations such as network operators,
   especially as networks and hosts transition from one network address
   family to another (IPv4 to IPv6).  Thus, if a DNS recursive resolver
   is on the ACL (whitelist) then they have access to AAAA resource
   records for the domain.

   In practice, DNS Whitelisting generally means that a very small
   fraction of the DNS recursive resolvers on the Internet (those in the
   whitelist or ACL) will receive AAAA responses.  The large majority of
   DNS recursive resolvers on the Internet will therefore receive only A
   resource records containing IPv4 addresses.  Thus, quite simply, the
   authoritative server hands out different answers depending upon who
   is asking; with IPv4 and IPv6 resource records for all those the
   authorized whitelist, and only IPv4 resource records for everyone
   else.  See Section 2.1 and Figure 1 for a description of how this
   works. 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, 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 to the DNS recursive
   resolver was over IPv6 transport.  One important reason for this is
   that even though the DNS recursive resolver may have no IPv6-related
   impairments, this is not a reliable predictor of whether the same is
   true of the end user host.  This also means that a DNS whitelist can
   contain both IPv4 and IPv6 addresses.

   Finally, DNS Whitelisting could possibly be deployed in two ways:
   universally on a global basis, basis (though that would be considered
   harmful and is just covered to explain why this is 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 the entire Internet.  In contrast,
   deployment on an ad hoc basis means that only some authoritative DNS
   servers, and perhaps even only a few, implement DNS Whitelisting.
   These two potential deployment models are described in Section 6. 5.

   Specific implementations will vary from domain to domain, based on a
   range of factors such as the technical capabilities of a given
   domain.  As such, any examples listed herein should be considered
   general examples and are not intended to be exhaustive.

2.1.  Description of the Operation of DNS Whitelisting

   The system logic 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 for
       the FQDN 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 the DNS recursive resolver sending the AAAA (IPv6)
       query against the access control list (ACL) that is the DNS
       whitelist.
       Whitelist.

   3.  If the DNS recursive resolver's IP address IS matched in the ACL,
       then the response to 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 the
       ACL, then the response to that specific DNS recursive resolver
       cannot contain AAAA (IPv6) address resource records.  In this
       case, the server should will likely return a response with the response
       code (RCODE) being set to 0 (No Error) with an empty answer
       section for the AAAA record query.

   ---------------------------------------------------------------------
   A query is sent from a DNS recursive resolver that

 +--------------------------------------------------------------------+
 | Caching Server 1 - IS NOT on ON the DNS
   whitelist:

               Request                      Request
           www.example.com                  www.example.com
                 AAAA    +-------------+     AAAA    +-----------------+
     ++--++   ---------> Whitelist                     |
 | Caching Server 2 - IS ON the DNS Whitelist                         |  RESOLVER
 |  ---------> Note: Transport between each host can be IPv4 or IPv6.             | www.example.com
 +--------------------------------------------------------------------+
 +----------+          +---------------+         +---------------+
 |
     ||  ||       A   Stub   | **IS NOT**          |      A  DNS Caching  | IN A exists         |
   +-++--++-+ --------->      DNS      |     ON
 |  ---------> Resolver |          |   Server 1    |         |     Server    |
 +----------+          +---------------+         +---------------+
    | DNS Query:            | IN AAAA exists                         |
   +--------+     A
    | example.com A, AAAA   |      A                         |
    |---------------------->|                         |
    |
      Host    <---------                       |  WHITELIST                         |  <---------
    |                       |
    Computer   A Record  +-------------+  A Record   +-----------------+
               Response DNS Recursive   Response Query:              |
    |                       | example.com
              (only IPv4)   Resolver     (only IPv4)    Authoritative
                              #1                           Server
   ---------------------------------------------------------------------
   A query is sent from a DNS recursive resolver that IS on the DNS
   Whitelist:

               Request                      Request
           www.example.com                  www.example.com A, AAAA     +-------------+     AAAA    +-----------------+
     ++--++   --------->     |  RESOLVER
    |  --------->                       |------------------------>|
    | www.example.com                       |
     ||  ||       A                         |   **IS**
    |      A                       | IN A exists                         |
   +-++--++-+ ---------> NOT on Whitelist
    |     ON                       |  --------->           DNS Response: | IN AAAA exists
    |
   +--------+   AAAA                       |           example.com A |     AAAA
    |                       |<------------------------|
    |
      Host    <---------                       |  WHITELIST                         |  <---------
    |         DNS Response: |
    Computer      A                         |
    |         example.com A |                         |
              <---------
    |<----------------------|                         |

 +----------+          +---------------+         +---------------+
 |  <---------   Stub   |          |
              A and AAAA +-------------+ A and AAAA  +-----------------+
               Record     DNS Recursive   Record        example.com
              Responses     Resolver     Responses      Authoritative
              (IPv4+IPv6)      #2        (IPv4+IPv6)       Server
   ---------------------------------------------------------------------

              Figure 1:  DNS Whitelisting - Functional Diagram

  ---------------------------------------------------------------------
  Resolver 1 - IS NOT ON the Caching  |         |      DNS Whitelist      |
 | Resolver |          |   Server 2 - IS ON the    |         |     Server    |
 +----------+          +---------------+         +---------------+
    | DNS Whitelist
  ---------------------------------------------------------------------
  Host 1                      Resolver 1          Authoritative Server
  Query A and AAAA    -----> Query A and AAAA    ----> Receive A and
  for www.example.com        for www.example.com       AAAA queries

  A (IPv4)   <------------- A (IPv4) <--------------- NOT on Whitelist
  response                  response                return only A (IPv4)
  ---------------------------------------------------------------------
  Host 2                       Resolver 2          Authoritative Server
  Query A and AAAA    -----> Query A and Query:            |                         |
    | example.com A, AAAA    ----> Receive A and
  for www.example.com        for www.example.com   |                         |
    |---------------------->|                         |
    |                       |                         |
    |                       | DNS Query:              |
    |                       | example.com A, AAAA queries

  A (IPv4)   <------------- A (IPv4) and <------------     |
    |                       |------------------------>|
    |                       |                         |
    |                       |                         | IS on Whitelist
    |                       |           DNS Response: |
    |                       |     example.com A, AAAA (IPv6)               AAAA (IPv6)                return A (IPv4)
  responses                 responses                  and |
    |                       |<------------------------|
    |                       |                         |
    |         DNS Response: |                         |
    |   example.com A, AAAA (IPv6)
  --------------------------------------------------------------------- |                         |
    |<----------------------|                         |

                    Figure 2: 1: DNS Whitelisting - Request/Response 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 are 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 AAAA resource record access such controls.

3.  What Problems Are Implementers Trying To Solve?

   Implementers are attempting  Similarities to protect users Other DNS Operations

   Some aspects of their domain from
   having a negative experience (poor performance) when they receive DNS
   response containing AAAA resource records or when attempting Whitelisting may be considered similar to use
   IPv6 transport.  Therefore there are two concerns other
   common DNS operational techniques which relate are explored below.

3.1.  Similarities to
   this practice; one Split DNS

   DNS Whitelisting has some similarities to so-called split DNS,
   briefly described in Section 3.8 of which relates [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 IPv6-related impairment provide one answer to hosts on an
   Intranet and
   the other which relates a different answer to hosts on the maturity or stability of IPv6
   transport for high-traffic domains.

   Finally, some domains, have run IPv6 experiments Internet, the essence
   is that different answers are provided to hosts on different
   networks.  This is basically the way that DNS Whitelisting works,
   whereby they added
   AAAA resource records hosts on different networks which use different DNS recursive
   resolvers, receive different answers if one DNS recursive resolver is
   on the whitelist and observed the other is not.

   In [RFC2956], Internet transparency and measured errors [Heise], which
   should be important reading for any domain contemplating either 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 DNS Whitelisting or simply adding IPv6 addressing to their
   site.

3.1.  IPv6-Related Impairment

   Some implementers have observed Fully Qualified Domain Names (FQDNs) as endpoint
   identifiers more complex."  Section 3.5 of [RFC2956] further
   recommends that when they added AAAA resource
   records maintaining a stable approach to their authoritative DNS servers in order operations is
   key during transitions such as the one to support IPv6
   access to their content that a small fraction is underway now,
   stating that "Operational stability of end users had slow
   or otherwise impaired access to DNS is paramount, especially
   during a given web site with transition of the network layer, and both AAAA IPv6 and A
   resource records.  The fraction of users with such impaired access
   has been estimated some
   network address translation techniques place a heavier burden on
   DNS."

3.2.  Similarities to be as high as 0.078% of total Internet users
   [IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness].
   In these situations, DNS recursive resolvers are added to the Load Balancing

   DNS
   Whitelist only when the measured level of impairment Whitelisting also has some similarities to DNS load balancing.
   There are of the hosts
   using course many ways that resolver declines DNS load balancing can be
   performed.  In one example, multiple IP address resource records (A
   and/or AAAA) can be added to some level acceptable by the
   implementer.

   As a result of this impairment affecting end users of DNS for a given domain,
   a few high-traffic domains have either implemented FQDN.  This approach
   is referred to as DNS Whitelisting
   or round robin [RFC1794].  DNS round robin may
   also be employed where SRV resource records are considering doing so [NW-Article-DNS-WL] [WL-Ops].  While it
   is outside the scope used [RFC2782].

   In another example, one or more of this document to explore the various reasons
   why IP address resource records in
   the DNS will direct traffic to a particular user's system (host) load balancer.  That load balancer,
   in turn, may have impaired IPv6 access,
   for be application-aware, and pass the users who experience this impairment it has a very real
   performance impact.  It would affect access traffic on to all one or most dual stack
   services to which the user attempts to connect.  This negative end
   user experience can range from somewhat slower than usual (as
   compared to native IPv4-based access), to extremely slow, to no
   access
   more hosts connected to the domain whatsoever. load balancer which have different IP
   addresses.  In essence, whether the cases where private IPv4 addresses are used [RFC1918],
   as well as when public IP addresses are used, those end user
   even has an IPv6 address or hosts may not (they probably only have an IPv4
   address), merely by receiving a AAAA record response
   necessarily be directly reachable without passing through the user either
   cannot access load
   balancer first.

   Additionally, 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 geographically-aware authoritative DNS responses server may be
   used, as is common with AAAA 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 particular resolvers.  In this case, DNS recursive
   resolvers operators have expressed a short-term concern that their
   IPv6 network infrastructure is not yet ready to handle the large
   traffic volume that may be associated with the hosts resolver in their network
   connecting response to a query will vary based on the websites estimated
   geographic location of these domains.  These end user networks
   may also have other tools at their disposal the resolver [Wild-Resolvers].  CDNs perform
   this function in order to address this
   concern, including applying rules attempt to direct hosts to connect 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
   nearest content cache.  As a given
   network), as well as configuration of their result, one can see some similarities
   with DNS recursive resolvers
   (though modifying or suppressing AAAA Whitelisting insofar as different IP address resource
   records in a DNSSEC-
   signed domain on a Security-Aware Resolver will be problematic
   Section 10.1).

3.2.  Volume-Based Concerns

   Some implementers are trying to gradually add IPv6 traffic selectively returned to their
   domain since they may find that network operations, tools, processes
   and procedures are less mature for IPv6 as compared to IPv4.  While
   for domains with small resolvers based on the IP address
   of each resolver (or other imputed factors related to moderate traffic volumes, whether by that IP
   address).  However, what is different is that in this case the
   count
   resolvers are not deliberately blocked from receiving DNS responses
   containing an entire class of end 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 or count of bytes transferred, high-traffic
   domains receive such their domain from
   having a level of usage that it is prudent to undertake
   any network changes gradually negative experience (poor performance) when they receive DNS
   response containing AAAA resource records or in a manner when attempting to use
   IPv6 transport.  There are two concerns which minimizes any risk
   of disruption.  For example, one can imagine for relate to this
   practice; one of which relates to IPv6-related impairment and the top ten
   sites globally that
   other which relates to the idea of suddenly turning on a significant
   amount maturity or stability of IPv6 traffic might be quite daunting.  DNS Whitelisting may
   therefore offer such transport
   for high-traffic domains.  Both can negatively affect the experience
   of end users.

   Not all domains one potential method for
   incrementally enabling IPv6.  Thus, may face these challenges, though some implementers with high- 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 plan to use have implemented DNS Whitelisting as a necessary, though
   temporary, risk reduction tactic intended to ease their transition to Whitelisting, others have run
   IPv6 experiments whereby they added AAAA resource records and minimize any perceived risk in
   observed and measured errors, and then decided not to implement DNS
   Whitelisting [Heise].  A more widespread such a transition.

3.3.  Free Versus Subscription Services

   It is also worth noting experiment was World
   IPv6 Day [W6D], sponsored by the differences between Internet Society, on June 8, 2011.
   This was a unique opportunity for hundreds of domains containing
   primarily subscription-based services compared to those containing
   primarily free services.  In add AAAA
   resource records to the case of free services, such as
   search engines, end users have no direct billing relationship with DNS without using DNS Whitelisting, all at
   the domain and same time.  Domains can switch sites simply by changing the address they
   enter into run their browser (ignoring other value added services which
   may tie a user's preference to own independent experiments in
   the future, adding AAAA resource records for a given domain period of time, and
   then analyzing any impacts or otherwise create
   switching costs).  As a result, such domains explain that they
   believe they are more sensitive to effects on traffic and the quality experience
   of the services within end users.

4.1.  Volume-Based Concerns

   Some implementers are trying to gradually add IPv6 traffic to their
   domain since if the user has issues when they turn on IPv6,
   then that user could switch to another domain may find that is not using IPv6.

4.  Concerns Regarding DNS Whitelisting

   The implications relating to DNS Whitelisting are further enumerated
   here network operations, tools, processes
   and in Section 7.

   Some parties in the Internet community, including ISPs, procedures are concerned
   that the practice of DNS Whitelisting less mature for IPv6 address resource
   records represents a departure from the generally accepted practices
   regarding IPv4 address resource records in the DNS on the Internet
   [WL-Concerns].  These parties explain their belief that once an
   authoritative server operator adds an A record (IPv4) as compared to IPv4.
   Compared to domains with small to moderate traffic volumes, whether
   by the DNS,
   then any DNS recursive resolver on the Internet can count of end users or count of bytes transferred, high-traffic
   domains receive such a level of usage that A
   record in response it is prudent to undertake
   any network changes gradually or in a query.  By extension, this means that manner which minimizes any risk
   of disruption.

   For example, one can imagine for one of the hosts connected to any top ten sites globally
   that the idea of these suddenly turning on a significant amount of IPv6
   traffic is quite daunting.  DNS recursive resolvers can
   receive the IPv4 address resource records 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 given FQDN.  This
   enables new server hosts which are connected necessary, though temporary, risk reduction
   tactic intended to the Internet, ease their transition to IPv6 and for
   which a fully qualified domain name (FQDN) minimize any
   perceived risk in such as www.example.com
   has been a transition.

4.2.  IPv6-Related Impairment

   Some implementers have observed that when they added AAAA resource
   records to the their authoritative DNS with an IPv4 address record, to be almost
   immediately reachable by any host on the Internet.  In this case,
   these new servers hosts become more and more widely accessible as new
   networks and new end user hosts connect to the Internet over time,
   capitalizing on and increasing so-called "network effects" (also
   called network externalities).  It also means that the new server
   hosts do not need to know about these new networks and new end user
   hosts in order to make support IPv6
   access to their content and applications available to
   them, in essence that each a small fraction of end in this end-to-end model is
   responsible for connecting to the Internet and once they have done so
   they can connect to each other without additional impediments or
   middle networks or intervening networks users had slow
   or servers knowing about
   these end points otherwise impaired access to a given web site with both AAAA and whether one is allowed A
   resource records.  The fraction of users with such impaired access
   has been estimated to contact the other.

   In contrast, the concern is that DNS Whitelisting may fundamentally
   change 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 model. is declining
   [Impairment-Tracker].  In the altered these situations, DNS Whitelisting end-to-end model,
   one end (where the end user is located) cannot readily connect recursive resolvers
   are added to the
   other end (where DNS Whitelist only when the content is located), without parts measured level of
   impairment of the middle
   (DNS recursive resolvers) used by one end (the client, or end user
   hosts) being known to an intermediary (authoritative nameservers) and
   approved for access hosts using that resolver declines to some level
   acceptable by the resource at domain.

   It is not clear if the end. level of IPv4-related impairment is more or
   less that IPv6-related impairment.  As new networks
   connect to the Internet over time, 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 networks need websites are simply unable to contact any
   and all domains which have implemented DNS Whitelisting or are otherwise not in order to
   apply a
   position to be added able to their DNS whitelist, measure IPv4 impairment (since this could
   result in the hopes no Internet access whatsoever).

   As a result of making the
   content and applications residing on named server hosts in those
   domains accessible by the end user hosts on that new network.
   Furthermore, this same need to contact all impairment affecting end users of a given domain,
   a few high-traffic domains implementing have either implemented DNS Whitelisting also applies to all pre-existing (but not whitelisted)
   networks connected to
   or are considering doing so [NW-Article-DNS-WL] [WL-Ops].  While it
   is outside the Internet.

   In scope of this document to explore the current IPv4 Internet when various reasons
   why a new server host is added to particular user's system (host) may have impaired IPv6 access,
   for the
   Internet users who experience this impairment it is generally widely available has a very real
   performance impact.  It would affect access to all end or most dual stack
   services to which the user hosts; when
   DNS Whitelisting of IPv6 resource records is used, these new server
   hosts are not accessible via a FQDN by any attempts to connect.  This negative end
   user hosts until such
   time as the operator of the authoritative DNS servers for those new
   server hosts expressly authorizes experience can range from somewhat slower than usual access (as
   compared to those new server hosts by
   adding DNS recursive resolvers around the Internet native IPv4-based access), to the ACL.  This
   has the potential extremely slow access, to be a significant change in reachability of
   content and applications by end users and networks as these end user
   hosts and networks transition
   no access to IPv6, resulting in more (but
   different) breakage.  A concern expressed is that if much of the
   content that end users are most interested in is not accessible as a
   result, then domain whatsoever.  In essence, whether the end users and/or networks may resist adoption of user
   even has an IPv6 or
   actively seek alternatives to it, such as using multi-layer network address translation (NAT) techniques like NAT444
   [I-D.shirasaki-nat444] on or not, merely by receiving a long-term basis.  There is also concern
   that this practice could disrupt AAAA record
   response the continued increase in Internet
   adoption by end users if they user either cannot simply access new content a FQDN or it is so slow that
   the user gives up and
   applications but must instead contact assumes the operator of their destination is unreachable.

   In addition, at least one high-traffic domain has noted that they
   have received requests to not send DNS
   recursive resolver, such as their ISP or another third party, responses with AAAA resource
   records to have
   their particular DNS recursive resolvers.  In this case, a DNS
   recursive resolver authorized for access operator expressed a short-term concern that their
   IPv6 network infrastructure was not yet ready to handle the content or
   applications large
   traffic volume that interests them.  Meanwhile, these parties say, over
   99.9% of may be associated with the other end users that are also using that same hosts in their network or
   DNS recursive resolver are unable
   connecting to access the IPv6-based content,
   despite their experience being a positive one.

   While in Section 1 the level of IPv6-related impairment has been
   estimated to be as high as 0.078% of Internet users, which is a
   primary motivation cited for the practice of DNS Whitelisting, it is
   not clear if the level websites of IPv4-related impairment is more or less
   that this percentage (which in any case is likely to these domains.  These end user networks
   may also have declined
   since its original citation).  Indeed, as other tools at least 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 their disposal in a position to be able order to measure IPv4 impairment
   (since address this could result in no Internet access whatsoever).  As a
   result, it is worth considering that IPv4-related impairment could
   exceed that of IPv6-related impairment and that
   concern, including applying rules to network equipment such IPv4-related
   impairment may have simply been accepted as "background noise" on the
   Internet for a variety of reasons.  Of course, this comparison of
   routers and firewalls (this will necessarily vary by the
   level type of worldwide IPv6 impairments to IPv4 impairments is
   speculation,
   network, as well as the author is not aware technologies used and the design of any good measurement a given
   network), as well as configuration of
   IPv4-related impairments which are comparable their DNS recursive resolvers
   (though modifying or suppressing AAAA resource records in nature to the IPv6-
   related impairment measurements which have recently been conducted
   around the world.

   An additional concern 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 impairments, 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.

5.  Similarities to Other DNS Operations

   Some aspects

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 DNS Whitelisting 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 considered similar more sensitive to other
   common DNS operational techniques which are explored below.

5.1.  Similarities
   IPv6 transition issues since their users can quickly switch to Split DNS
   another domain that is not using IPv6.

5.  General Implementation Variations

   In considering how DNS Whitelisting has some similarities to so-called split DNS,
   briefly described in Section 3.8 may emerge more widely, there are
   two deployment scenarios explored below, one of [RFC2775].  When split DNS is
   used, the authoritative DNS server returns different responses
   depending upon what host has sent which, the query.  While [RFC2775] notes ad-hoc
   case Section 5.2, is realistic and is happening now.  The other,
   universal deployment Section 5.1, is only described for the typical use sake of split DNS is to provide one answer
   completeness, to hosts on an
   Intranet highlight its difficulties, and a different answer to hosts on the Internet, the essence
   is that different answers explain why it
   would be considered harmful.  Other possible alternative or
   supplementary approaches are provided to hosts on different
   networks.  This is basically the way that also outlined.

   In evaluating implementing DNS Whitelisting works,
   whereby hosts universally and on different networks which use different DNS recursive
   resolvers, receive different answers if one DNS recursive resolver is
   on the whitelist and the other an ad
   hoc basis, it is not.

   In [RFC2956], Internet transparency possible that reputable third parties could create
   and Internet fragmentation
   concerns regarding split maintain DNS are detailed in Section 2.1.  [RFC2956]
   further notes whitelists, in Section 2.7, concerns regarding split DNS and that
   it "makes much the use of Fully Qualified Domain Names (FQDNs) as endpoint
   identifiers more complex."  Section 3.5 of [RFC2956] further
   recommends same way that maintaining blacklists are
   distributed and used for reducing email spam.  In the email context,
   a stable approach mail operator subscribes to DNS operations is
   key during transitions such one or more of these lists and as such
   the one operational processes for additions and deletions to IPv6 that is underway now,
   stating that "Operational stability of DNS is paramount, especially
   during the list are
   managed by a transition third party.  A similar model could emerge for DNS
   Whitelisting.

   In either of the network layer, and both IPv6 and some
   network address translation techniques place those scenarios a heavier burden on
   DNS."

5.2.  Similarities to DNS Load Balancing recursive resolver operator will
   have to determine whether or not DNS Whitelisting also has some similarities to DNS load balancing.
   There are been
   implemented for a domain, since the absence of course many ways that DNS load balancing can be
   performed.  In one example, multiple IP address AAAA resource records (A
   and/or AAAA) can
   may simply be indicative that the domain has not yet added to IPv6
   addressing for the domain, rather than that they have done so but are
   using DNS for a given FQDN. Whitelisting.  This will be challenging at scale.

5.1.  Implement DNS Whitelisting Universally

   One approach is referred to as DNS round robin [RFC1794]. implement DNS round robin may Whitelisting universally, which
   could also be employed where SRV resource records are used [RFC2782].

   In another example, one or more involve using some sort of centralized registry of the IP address resource records in
   the DNS will direct traffic
   Whitelisting policies, contracts, processes, or other information.
   For this deployment scenario to occur, DNS Whitelisting functionality
   would need to a load balancer.  That load balancer,
   in turn, may be application-aware, built into all authoritative DNS server software,
   and pass the traffic on all operators of authoritative DNS servers would have to one or
   more hosts connected upgrade
   their software in order 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 enable this functionality.  New IETF
   Request for Comment (RFC) documents may not need to be directly reachable without passing through the load balancer first
   .  As such, while the IP address resource records have been added completed to
   describe how to properly configure, deploy, and maintain DNS
   Whitelisting across the DNS, the end hosts are not necessarily directly reachable, which
   is in entire Internet.  As a small way similar result, it is highly
   unlikely that DNS Whitelisting will become universally deployed.

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

5.2.  Implement DNS Whitelisting.

   Additionally, a geographically-aware authoritative Whitelisting On An Ad Hoc Basis

   DNS server may be
   used, as Whitelisting is common with Content Delivery Networks (CDNs) now being adopted on an ad hoc, or Global
   Load Balancing (GLB, also referred domain-by-
   domain basis.  Therefore, only those domains interested in DNS
   Whitelisting would need to as Global Server Load
   Balancing, or GSLB), whereby adopt the IP address resource records returned
   to a resolver practice.  Also in response this
   scenario, ad hoc use by a particular domain is likely to be a query will vary based on
   temporary measure that has been adopted to ease the estimated
   geographic location transition of the resolver [Wild-Resolvers].  CDNs perform
   this function
   domain to IPv6.  A domain, particularly a high-traffic domain, may
   choose to do so in order to attempt to direct hosts ease their transition to connect IPv6 through a
   selective deployment so as to the
   nearest content cache.  As minimize any risks or disruptions in
   such a result, one can see some similarities
   with transition.

   One benefit of DNS Whitelisting insofar as different IP address resource
   records are selectively returned to resolvers based being deployed on an ad hoc basis is
   that only the IP address
   of each resolver domains that are interested in doing so would have to
   upgrade their authoritative DNS servers (or take other imputed factors related steps) in
   order to implement DNS Whitelisting.  Some domains that IP
   address).  However, what is different is that in plan to or
   already have implemented this case the
   resolvers and are not deliberately blocked from receiving manually updating their
   whitelist, while others such as CDNs have discussed the possibility
   of an automated method for doing so.

5.3.  Do Not Implement DNS responses
   containing Whitelisting

   As an entire class of addresses; this load balancing function
   strives alternative to perform a content location-improvement function and adopting DNS Whitelisting, domains can choose
   not an
   access control function.

6.  Possible Deployment Scenarios

   In considering how to implement DNS Whitelisting may emerge more widely, there are
   two deployment scenarios explored below, one of which, Whitelisting, continuing the ad-hoc
   case, current predominant
   authoritative DNS operational model on the Internet.  It is realistic then up
   to end users with IPv6-related impairments to discover and may happen.  The other, universal deployment,
   is only described for fix those
   impairments, though clearly other parties including end user host
   operating system developers can play a critical role.  However, the sake of completeness, to highlight its
   difficulties,
   concerns and risks related to explain why it would traffic volume Section 4.1 should still
   be considered harmful.

   In either since those are not directly related to such
   impairments.

5.3.1.  Solve Current End User IPv6 Impairments

   A further extension of these deployment scenarios, it is possible that
   reputable third parties could create and maintain not implementing DNS whitelists, in
   much Whitelisting, is to also
   endeavor fix the same way that blacklists are distributed and used for
   reducing email spam.  In underlying technical problems experienced by end
   users during the email context, a mail operator
   subscribes transition to one or more of these lists and as IPv6.  A first step is to identify
   which users have such the operational
   processes for additions impairments and deletions then to communicate this
   information to affected users.  Such end user communication is likely
   to be most helpful if the list are managed by end user is not only alerted to a
   third party.  A similar model could emerge for DNS Whitelisting,
   whether deployment occurs universally or potential
   problem but is given careful and detailed advice on an ad hoc basis.

   An additional factor in either scenario is that a DNS recursive
   resolver operator will have to determine whether or not DNS
   Whitelisting has been implemented for a domain, since the absence of
   AAAA resource records may simply be indicative that the domain has
   not yet added IPv6 addressing for the domain, rather than that they
   have done so but are using DNS Whitelisting.  This will be
   challenging at scale.

6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis

   The most likely deployment scenario is where some authoritative DNS
   server operators implement DNS Whitelisting but many or most others
   do not do so.  What can make this scenario challenging from the
   standpoint of a DNS recursive resolver operator is determining which
   domains implement DNS Whitelisting, particularly since a domain may
   not do so as they initially transition to IPv6, and may instead do so
   later.  Thus, a DNS recursive resolver operator may initially believe
   that they can receive AAAA responses as a domain adopts IPv6, but
   then notice via end user reports that they no longer receive AAAA
   responses due to that domain adopting DNS Whitelisting.  Of course, a
   domain's IPv6 transition may be effectively invisible to DNS
   recursive resolver operators due to the effect of DNS Whitelisting.

   One benefit of DNS Whitelisting being deployed on an ad hoc basis is
   that only the domains that are interested in doing so would have to
   upgrade their authoritative DNS servers in order to implement the
   ACLs necessary to perform DNS Whitelisting.  Some domains have
   proposed or are implementing this and are manually updating their
   whitelist, while other such as CDNs have discussed the possibility of
   an automated method for doing so.

   In this potential deployment scenario, it is also possible that a
   given domain will implement DNS Whitelisting temporarily.  A domain,
   particularly a high-traffic domain, may choose to do so in order to
   ease their transition to IPv6 through a selective deployment and
   minimize any perceived risk in such a transition.  In addition, it is
   possible that one or more DNS Whitelist clearinghouses may emerge,
   providing implementers with a way to subscribe to a whitelist in a
   manner similar to that used on email servers for blacklists.

6.2.  Deploying DNS Whitelisting Universally

   This deployment scenario is one where DNS Whitelisting is implemented
   on all authoritative DNS servers, across the entire Internet, which
   is highly unlikely and unrealistic.  While this scenario seems far
   less likely than ad hoc deployment due to many parties not sharing
   the concerns that have so far motivated the use of DNS Whitelisting,
   it is nonetheless conceivable that it could be one of the ways in
   which DNS Whitelisting is deployed, though such a universal
   deployment could be considered harmful and problematic.

   For this deployment scenario to occur, DNS Whitelisting functionality
   would need to be built into all authoritative DNS server software,
   and that all operators of authoritative DNS servers would have to
   upgrade their software in order to enable this functionality.  New
   IETF Request for Comment (RFC) documents would need to be completed
   to describe how to properly configure, deploy, and maintain DNS
   Whitelisting across the entire Internet.  As a result, it is highly
   unlikely that DNS Whitelisting will become universally deployed.

7.  Implications of DNS Whitelisting

   There are many implications of DNS Whitelisting.  The key
   implications are detailed below.

7.1.  Architectural Implications

   DNS Whitelisting modifies the end-to-end model and the general notion
   of spontaneous interoperability of the architecture that prevails on
   the Internet today.  This is because this approach moves additional
   access control information and policies into the middle of the DNS
   resolution path of the IPv6-addressed Internet, which generally did
   not exist before on the IPv4-addressed Internet, and it requires some
   type of prior registration with authoritative servers.  This poses
   some risks noted in [RFC3724].  In explaining the history of the end-
   to-end principle [RFC1958] states that one of the goals is to
   minimize the state, policies, and other functions needed in the
   middle of the network in order to enable end-to-end communications on
   the Internet.  In this case, the middle network should be understood
   to mean anything other than the end hosts involved in communicating
   with one another.  Some state, policies, and other functions have
   always been necessary to enable such end-to-end communication, but
   the goal of the approach has been to minimize this to the greatest
   extent possible.

   It is also possible that DNS Whitelisting could place at risk some of
   the observed benefits of the end-to-end principle, as listed in
   Section 4.1 of [RFC3724], such as protection of innovation.
   [RFC3234] details issues and concerns regarding so-called
   middleboxes, so there may also be parallel concerns with the DNS
   Whitelisting approach, especially concerning modified DNS servers
   noted in Section 2.16 of [RFC3234], as well as more general concerns
   noted in Section 1.2 of [RFC3234] about the introduction of new
   failure modes.  In particular, there may be concerns that
   configuration is no longer limited to two ends of a session, and that
   diagnosis of failures and misconfigurations becomes more complex.

   Two additional sources worth considering as far as implications for
   the end-to-end model are concerned are [Tussle] and [Rethinking].  In
   [Tussle], the authors note concerns regarding the introduction of new
   control points, as well as "kludges" to the DNS, as risks to the goal
   of network transparency in the end-to-end model.  Some parties
   concerned with the emerging use of DNS Whitelisting have shared
   similar concerns, which may make [Tussle] an interesting and relevant
   document.  In addition, [Rethinking] reviews similar issues that may
   be of interest to readers of this document.

   Also, it is somewhat possible that DNS Whitelisting could affect some
   of the architectural assumptions which underlie parts of Section 2 of
   [RFC4213] which outlines the dual stack approach to the IPv6
   transition.  DNS Whitelisting could modify the behavior of the DNS,
   as described in Section 2.2 of [RFC4213] and could require different
   sets of DNS servers to be used for hosts that are (using terms from
   that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes.
   As such, broad use of DNS Whitelisting may necessitate the review
   and/or revision (though revision is unlikely to be neccessary) of
   standards documents which describe dual-stack and IPv6 operating
   modes, dual-stack architecture generally, and IPv6 transition
   methods, including but not limited to [RFC4213].

7.2.  Public IPv6 Address Reachability Implications

   It is a critical to understand that the concept of reachability
   described here depends upon a knowledge of an address in the DNS.
   Thus, in order to establish reachability to an end point, a host is
   dependent upon looking up an IP address in the DNS when a FQDN is
   used.  When DNS Whitelisting is used, it is quite likely that an
   IPv6-enabled end user host could connect to an example server host
   using the IPv6 address, even though the FQDN associated with that
   server host is restricted via a DNS whitelist.  Since most Internet
   applications and hosts such as web servers depend upon the DNS, and
   as end users connect to FQDNs such as www.example.com and do not
   remember or wish to type in an IP address, the notion of reachability
   described here should be understood to include knowledge of how to
   associate a name with a network address.

   The predominant experience of end user hosts and servers on the IPv4-
   addressed Internet today is that when a new server with a public IPv4
   address is added how to the DNS, that a FQDN is immediately useful for
   reaching it.  This is a generalization and resolve
   this on their own, or where they can seek help in doing so.
   Section 5 there are
   examples of common cases where this 10 may not necessarily also be the relevant in this case.
   For the purposes of

   One challenge with this argument, that concept of accessibility option is
   described as "pervasive reachability".  It has so far been assumed
   that the same expectations potential difficulty of
   motivating members of pervasive reachability would exist in the IPv6-addressed Internet.  However, if DNS Whitelisting is
   deployed, Internet community to work collectively
   towards this will not be goal, sharing the case since only labor, time, and costs related to such
   an effort.  However, World IPv6 Day [W6D] shows that such community
   efforts are possible and despite any potential challenges, the
   Internet community continues to work to solve end user hosts using
   DNS recursive resolvers that IPv6
   impairments.

   However, as noted above, the concerns and risks related to traffic
   volume Section 4.1 should still be considered since those are included in not
   directly related to such impairments.

5.3.2.  Gain Experience Using IPv6 Transition Names

   Another alternative is for domains to gain experience using an FQDN
   which has become common for domains beginning the ACL of transition to IPv6;
   ipv6.example.com and www.ipv6.example.com.  This can be a way for a given
   domain using to gain IPv6 experience and increase IPv6 use on a relatively
   controlled basis, and to inform any plans for DNS Whitelisting would be able to reach new servers in
   that given with
   experience.

   While this is a good first step to functionally test and prepare a
   domain via IPv6 addresses.  The expectation for IPv6, the utility of any end
   user host being able to connect the tactic is limited since users
   must know the transition name, the traffic volume will be low, and
   the traffic is unlikely to any server (essentially both
   hosts, just at either end be representative of the network), defined here general
   population of end users, among other reasons.  Thus, as "pervasive
   reachability", will change noted above,
   the concerns and risks related to "restricted reachability" with IPv6.

   Establishing traffic volume Section 4.1 should
   still be considered.

5.3.3.  Implement DNS Whitelisting as an accepted practice in the early
   phases Blacklisting

   Some domains may wish to be more permissive than if they adopted DNS
   Whitelisting, but still have some level of mass IPv6 deployment could establish it as control over returning
   AAAA record responses.  In this case an integral part
   of how IPv6 alternative may be to employ
   DNS resource records are deployed globally.  This risks Blacklisting, which would enable all DNS Whitelisting living on recursive resolvers to
   receive AAAA record responses except for decades as a key foundational element
   of domain name management on the Internet.

7.3.  Operational Implications

   This section explores some of the operational implications which may
   occur as a result of, relatively small number
   that are related to, or become necessary when
   engaging listed in the practice of DNS Whitelisting.

7.3.1.  De-Whitelisting May Occur

   It is possible blacklist.  This could, for example, enable an
   implementer to only prevent such responses where there has been a DNS recursive resolver added
   relatively high level of IPv6-related impairments, until such time as
   these impairments can be fixed or otherwise meaningfully reduced to a whitelist
   an acceptable level.

   This approach is likely to
   then be removed from the whitelist, also known as de-whitelisting.
   Since de-whitelisting can occur, through a decision by the significantly less labor intensive for
   an authoritative DNS server operator, the domain owner, or even due to as they would presumably focus
   on a
   technical error, an operator smaller number of DNS recursive resolvers than if they
   implemented whitelisting.  Thus, these authoritative DNS server
   operators would only need to communicate with a few DNS recursive
   resolver will have
   new operational and monitoring requirements and/or needs as noted operators rather than potentially all such operators.  This
   should result in
   Section 7.3.3, Section 7.3.4, Section 7.3.6, lower labor, systems, and Section 7.5.  One
   particular risk process requirements.
   This is that, especially when a high-traffic domain de-
   whitelists a large network, this may cause a sudden and dramatic
   change not to networks since a large volume of traffic say that there will then switch
   from IPv6 be no time required to IPv4.  This can have dramatic effects on work with
   those being de-
   whitelisted as well as on other interconnected networks.  In some
   cases, IPv4 network links may rapidly become congested and users of parties affected networks will experience network access impairments well
   beyond the domain which performed the de-whitelisting.  Thus, once
   "operational stability" has been achieved between by a whitelisting and
   whitelisted party, then de-whitelisting should generally not occur
   except in cases of operational emergencies, and blacklist, simply that 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 are likely
   to be fewer such interactions and that each such interaction could be
   shorter in duration.

   The email industry has a critical infrastructure service; long experience with blacklists and, very
   generally speaking, blacklists tend to be
   useful it needs careful effective and extensive administration, monitoring well received
   when it is easy to discover if a server is on a blacklist, if there
   is a transparent and
   operation.  Each new easily understood process for requesting removal
   from a blacklist, and essential mechanism creates substantial
   follow-on support costs.

   Operators of authoritative servers (which are frequently
   authoritative if the decision-making criteria for multiple domain names) will need to maintain an ACL
   on placing a server-wide basis affecting all domains, or
   server on a domain-by-
   domain basis. blacklist is transparently disclosed and perceived as
   fair.

   As noted in Section 7.3.7, it is also possible that a result, operational practices and software
   capabilities domain may need to be developed in order
   choose to support such
   functionality.  In addition, processes may need first implement DNS Whitelisting and then migrate to be put DNS
   Blacklisting.

6.  Concerns Regarding DNS Whitelisting

   There is concern that the practice of DNS Whitelisting for IPv6
   address resource records represents a departure from the generally
   accepted practices regarding IPv4 address resource records in place to
   protect against inadvertently adding or removing IP addresses, as
   well as systems and/or processes to respond the DNS
   on the Internet [WL-Concerns].  Generally, once an authoritative
   server operator adds an A record (IPv4) to such incidents if and
   when they occur.  For example, a system may be needed the DNS, then any DNS
   recursive resolver on the Internet can receive that A record in
   response to record DNS
   Whitelisting requests, report on their status along a workflow, add
   IP addresses when whitelisting has been approved, remove IP addresses
   when they have been de-whitelisted, log query.  This enables new server hosts that are
   connected to the personnel involved Internet, and
   timing of changes, schedule changes for which a FQDN such as
   www.example.com has been added to occur in the future, and DNS with an IPv4 address
   record, to
   roll back be almost immediately reachable by any inadvertent changes.

   Operators may also need implement new forms of monitoring in order to
   apply change control, as noted briefly host on the
   Internet.  Each end in Section 7.3.4.

   It this end-to-end model is important responsible for operators of authoritative servers
   connecting to recognize
   that the operational burden Internet and once they have done so they can
   connect to each other without additional impediments, middle
   networks, intervening networks, or servers either knowing about all
   end points or whether one is likely allowed to increase dramatically over
   time, as discover and contact the
   other.  The end result is that new server hosts become more and more
   widely accessible as new networks transition and new hosts connect to the
   Internet over time, capitalizing on and increasing so-called "network
   effects" (also called network externalities).

   In contrast, DNS Whitelisting may fundamentally change this model.
   In the altered DNS Whitelisting end-to-end model, one end (where the
   end user is located) cannot readily discover the other end (where the
   content is located), without parts of the middle (authoritative DNS
   servers) making a new type of access control decision in the DNS.  So
   in the current IPv4-based Internet when a new server host is added to IPv6.  As a result,
   the
   volume of new Internet it is generally widely available to all end user hosts
   via a FQDN.  When DNS Whitelisting requests will increase over time,
   potentially at an extraordinary growth rate, which will place an
   increasing burden on personnel, systems, and/or processes.  Operators
   should also consider that of IPv6 resource records is used,
   these new server hosts are not accessible via a FQDN by any supporting systems, including end user
   hosts until such time as the operator of the authoritative DNS
   servers themselves, may experience reduced performance
   when a adds DNS whitelist becomes quite large.

7.3.3. recursive resolvers around the Internet to the DNS Recursive Resolver Server Operational
   Whitelist.

7.  Implications

   For operators of DNS recursive resolvers, coping with Whitelisting

   The key DNS Whitelisting becomes expensive in time implications are detailed below.

7.1.  Architectural Implications

   DNS Whitelisting modifies the end-to-end model and personnel as the practice
   scales up.  These operators include ISPs, enterprises, universities,
   governments; a wide range general notion
   of organization types with a range spontaneous interoperability of DNS-
   related expertise.  They will need to implement new forms the architecture that prevails on
   the Internet today.  This is because this approach moves additional
   access control information and policies into the middle of
   monitoring, as the DNS
   resolution path of the IPv6-addressed Internet, which generally did
   not exist before on the IPv4-addressed Internet, and it requires some
   type of prior registration with authoritative servers.  This poses
   some risks noted briefly in Section 7.3.4.  But more critically,
   such operators will need to add people, processes, [RFC3724].  In explaining the history of the end-
   to-end principle, [RFC1958] states that one of the goals is to
   minimize the state, policies, and systems other functions needed in
   order to manage large numbers the
   middle of DNS Whitelisting applications.
   Since there is no common method for determining whether or not a
   domain is engaged the network in DNS Whitelisting, operators will have to apply order to enable end-to-end communications on
   the Internet.  In this case, the middle network should be whitelisted for a domain based upon one or more end user
   requests, which means systems, processes, and personnel for handling
   and responding understood
   to those requests will also be necessary.

   When operators apply for DNS Whitelisting for all domains, that may mean doing so for all registered domains.  Thus, some system would anything other than the end hosts involved in communicating
   with one another.  Some state, policies, and other functions have
   always been necessary to be developed to discover whether each domain enable such end-to-end communication, but
   the goal of the approach has been
   whitelisted or not, which is touched on in Section 6 and may vary
   depending upon whether DNS Whitelisting is universally deployed or is
   deployed on an ad hoc basis.

   These operators (of DNS recursive resolvers) will need to develop
   processes and systems minimize this to track the status of all greatest
   extent possible.

   It is also possible that DNS Whitelisting
   applications, respond to requests for additional information related
   to these applications, determine when and if applications have been
   denied, manage appeals, could place at risk some of
   the observed benefits of the end-to-end principle, as listed in
   Section 4.1 of [RFC3724], such as protection of innovation.
   [RFC3234] details issues and track any de-whitelisting actions.

   Given concerns regarding so-called
   middleboxes, so there may also be parallel concerns with the large number DNS
   Whitelisting approach, especially concerning modified DNS servers
   noted in Section 2.16 of domains [RFC3234], as well as more general concerns
   noted in existence, Section 1.2 of [RFC3234] about the ease with which a introduction of new domain can
   failure modes.  In particular, there may be added, concerns that
   configuration is no longer limited to two ends of a session, and that
   diagnosis of failures and misconfigurations becomes more complex.

   Two additional sources worth considering as far as implications for
   the continued strong growth in end-to-end model are concerned are [Tussle] and [Rethinking].  In
   [Tussle], the
   numbers authors note concerns regarding the introduction of new domains, readers should not underestimate
   control points, as well as "kludges" to the
   potential significance DNS, as risks to the goal
   of network transparency in personnel the end-to-end model.  Given the emerging
   use of DNS Whitelisting [Tussle] is an interesting and expense that this could
   represent for such operators. relevant
   document.  In addition, [Rethinking] reviews similar issues that are
   of interest to readers of this document.

   Also, it is likely somewhat possible that systems
   and personnel may also be needed to handle new end user requests for
   domains for which to apply for DNS Whitelisting, and/or inquiries
   into Whitelisting could affect some
   of the status architectural assumptions which underlie parts of a whitelisting application, reports Section 2 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 resolver has been whitelisted for a particular
   domain, then
   [RFC4213] which outlines the dual stack approach to the operator IPv6
   transition.  DNS Whitelisting could modify the behavior of the DNS,
   as described in Section 2.2 of [RFC4213] and could require different
   sets of DNS servers to be used for hosts that are (using terms from
   that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes.
   As such, broad use of DNS recursive resolver Whitelisting may need necessitate the review
   and/or revision (though revision is unlikely to
   implement monitoring in order be necessary) of
   standards documents which describe dual-stack and IPv6 operating
   modes, dual-stack architecture generally, and IPv6 transition
   methods, including but not limited to detect [RFC4213].

7.2.  Public IPv6 Address Reachability Implications

   It is a critical to understand that the possible loss concept of DNS
   Whitelisting reachability
   described here depends upon a knowledge of an address in the future.  This DNS recursive resolver operator
   could configure a monitor DNS.
   Thus, in order to check for establish reachability to an end point, a AAAA response host is
   dependent upon looking up an IP address in the
   whitelisted domain, as DNS when a check to validate continued status on the FQDN is
   used.  When DNS whitelist.  The monitor Whitelisting is used, it is quite likely that an
   IPv6-enabled end user host could then trigger connect to an alert if at some
   point example server host
   using the AAAA responses were no longer received, so IPv6 address, even though the FQDN associated with that operations
   personnel could begin troubleshooting, as outlined in Section 7.3.6.

   Also, authoritative DNS
   server operators are likely to need host is restricted via a DNS whitelist.  Since most Internet
   applications and hosts such as web servers depend upon the DNS, and
   as end users connect to
   implement new forms of monitoring.  In this case, they may desire FQDNs such as www.example.com and do not
   remember or wish to
   monitor for significant changes type in an IP address, the size of the whitelist within a
   certain period notion of time, which might reachability
   described here should be indicative understood to include knowledge of how to
   associate a technical
   error such as name with a network address.

   The predominant experience of end user hosts and servers on the entire ACL being removed.  Authoritative DNS IPv4-
   addressed Internet today is that when a new server
   operators may also wish with a public IPv4
   address is added to monitor their workflow process the DNS, that a FQDN is immediately useful for
   reviewing and acting upon DNS Whitelisting applications and appeals,
   potentially measuring
   reaching it.  This is a generalization and reporting on service level commitments
   regarding the time an application or appeal can remain at each step in Section 3 there are
   examples of common cases where this may not necessarily be the process, regardless case.
   For the purposes of whether or not such information is
   shared with parties other than this argument, that authoritative DNS server
   operator.

7.3.5.  Implications concept of Operational Momentum accessibility is
   described as "pervasive reachability".  It seems plausible has so far been assumed
   that once the same expectations of pervasive reachability would exist in
   the IPv6-addressed Internet.  However, if DNS Whitelisting is implemented it
   deployed, this will
   be very difficult to deprecate such technical and operational
   practices.  This assumption is based on an understanding of human
   nature, not to mention physics.  For example, as Sir Isaac Newton
   noted, "Every object be the case since only end user hosts using
   DNS recursive resolvers that are included in a state the ACL of uniform motion tends a given
   domain using DNS Whitelisting would be able to remain reach new servers in
   that state given domain via IPv6 addresses.  The expectation of motion unless an external force is applied any end
   user host being able to it"
   [Motion].  Thus, once DNS Whitelisting is implemented it is quite
   likely that it would take considerable effort connect to deprecate any server (essentially both
   hosts, just at either end of the network), defined here as "pervasive
   reachability", will change to "restricted reachability" with IPv6.

   Establishing DNS Whitelisting as an accepted practice and remove it everywhere on the Internet; it may otherwise
   simply remain in place in perpetuity.  To illustrate this point, one the early
   phases of mass IPv6 deployment could consider for example that there are many email servers
   continuing to attempt to query anti-spam DNS blocklists which have
   long ago ceased to exist.

7.3.6.  Troubleshooting Implications

   The implications establish it as an integral part
   of how IPv6 DNS whitelisted present resource records are deployed globally.  This risks
   DNS Whitelisting living on for many challenges, years as
   detailed throughout Section 7.  These challenges may negatively
   affect a key foundational
   element of domain name management on the end users' ability to troubleshoot, as well Internet.

7.3.  Operational Implications

   This section explores some of the operational implications which may
   occur as that a result of, are related to, or become necessary when
   engaging in the practice of DNS Whitelisting.

7.3.1.  De-Whitelisting May Occur

   It is possible for a DNS recursive resolver operators, ISPs, content providers, domain owners
   (where they may added to a whitelist to
   then be different removed from the operator of whitelist, also known as de-whitelisting.
   Since de-whitelisting can occur, through a decision by the
   authoritative
   DNS server for their domain), and other third parties.  This may make operator, the process of determining why domain owner, or even due to a server is not reachable via
   technical error, an operator of a FQDN
   significantly more complex and time-consuming.

7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis

   As more domains choose to implement DNS Whitelisting, and more
   networks become IPv6-capable and request to be whitelisted, scaling
   up operational processes, monitoring, and ACL updates recursive resolver will become
   more difficult.  The increased rate of change have
   new operational and increased size of
   whitelists will increase the likelihood of configuration monitoring requirements and/or needs as noted in
   Section 7.3.3, Section 7.3.4, Section 7.3.6, and other
   operational errors.

   It Section 7.5.  One
   particular risk is unclear that, especially when and if it would be appropriate to change from
   whitelisting to blacklisting.  It is clear that trying to coordinate a high-traffic domain de-
   whitelists a large network, this across the Internet is likely be be impossible, so such may cause a sudden and dramatic
   change to blacklisting would happen on a domain-by-domain basis (if at all).

   Finally, some implementers consider DNS Whitelisting to be networks since a
   temporary measure.  As such, it is not clear how these implementers large volume of traffic will judge the network conditions then switch
   from IPv6 to IPv4.  This can have changed sufficiently to
   justify disabling DNS Whitelisting (or Blacklisting, or dramatic effects on those being de-
   whitelisted as well as on other AAAA
   resource record access controls) and/or what the process interconnected networks.  In some
   cases, IPv4 network links may rapidly become congested and timing users of
   affected networks will be in order to discontinue this practice.

   One further implication is that an end user with only an IPv4
   address, using a DNS resolver experience network access impairments well
   beyond the domain which performed the de-whitelisting.  Thus, once
   "operational stability" has not been achieved between a whitelisting and
   whitelisted by any
   domains, would party, then de-whitelisting should generally not occur
   except in cases of operational emergencies, and there should be able
   opportunities for joint troubleshooting or at least for advance
   warning to get any AAAA resource records.  In such affected parties.

7.3.2.  Authoritative DNS Server Operational Implications

   DNS Whitelisting serves as a case, this could give that end user the incorrect impression that
   there is no IPv6-based content on the Internet since they are unable critical infrastructure service; to discover any IPv6 addresses via the DNS.

7.4.  Homogeneity May Be Encouraged

   A broad trend on the Internet is a move toward more heterogeneity.
   One manifestation of this is in an increasing number, variety, be
   useful it needs careful and
   customization of end user hosts, including home networks, operating
   systems, client software, home network devices, extensive administration, monitoring and personal
   computing devices.  This trend appears to have had a positive effect
   on the development
   operation.  Each new and growth essential mechanism creates substantial
   follow-on support costs.

   Operators of the Internet.  This trend has
   enabled end user authoritative servers (which are frequently
   authoritative for multiple domain names) will need to connect any technically compliant device or use
   any technically compatible maintain an ACL
   on a server-wide basis affecting all domains, or on a domain-by-
   domain basis.  As a result, operational practices and software
   capabilities may need to connect to the Internet.  Not
   only does this trend towards greater heterogeneity reduce the control
   which is exerted in the middle of the network, described positively be developed in [Tussle], [Rethinking], and [RFC3724], but it also appears order to help support such
   functionality.  In addition, processes may need to enable greater and more rapid innovation at the edges.

   Some forms of so-called "network neutrality" principles around the
   world include the notion that any IP-capable device should be able put in place to
   connect
   protect against inadvertently adding or removing IP addresses, as
   well as systems and/or processes to a network, which seems respond to encourage heterogeneity.  These
   principles are often explicitly encouraged by application providers
   given the reasons noted above, though some of these same providers such incidents if and
   when they occur.  For example, a system may also be implementing needed to record DNS Whitelisting.  This is ironic, as one
   implication of
   Whitelisting requests, report on their status along a workflow, add
   IP addresses when whitelisting has been approved, remove IP addresses
   when they have been de-whitelisted, log the adoption personnel involved and
   timing of DNS Whitelisting is that changes, schedule changes to occur in encourages
   a move the future, and to
   roll back towards homogeneity.  This is because some implementers
   have expressed a preference for greater levels any inadvertent changes.

   Operators may also need implement new forms of control by networks
   over end user hosts monitoring in order to attempt to enforce technical
   requirements intended
   apply change control, as noted briefly in Section 7.3.4.

   It is important for operators of authoritative servers to reduce IPv6-related impairments.  This
   return recognize
   that the operational burden is likely to an environment of increase dramatically over
   time, as more homogenous and/or controlled end
   user hosts could have unintended side effects on and counter-
   productive implications for future innovation at the edges of the
   network.

7.5.  Technology Policy Implications

   A key technology policy implication concerns the policies relating more networks transition to IPv6.  As a result, the process
   volume of reviewing an application for new DNS Whitelisting, and Whitelisting requests will increase over time,
   potentially at an extraordinary growth rate, which will place an
   increasing burden on personnel, systems, and/or processes.  Operators
   should also consider that any supporting systems, including the
   decision-making process regarding whitelisting for a domain.
   Important questions
   authoritative servers themselves, may include whether these policies have been
   fully and transparently disclosed, are non-discriminatory, and are
   not anti-competitive.  A related implication is whether and what the
   process for appeals is, experience reduced performance
   when a domain decides against adding a DNS whitelist becomes quite large.

7.3.3.  DNS Recursive Resolver Server Operational Implications

   For operators of DNS recursive resolver to the whitelist.  Key questions here may include
   whether appeals are allowed, what the process is, what the expected
   turn around resolvers, coping with DNS
   Whitelisting becomes expensive in time is, and whether personnel as the appeal 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 be handled by an
   independent third party or other entity/group.

   Further implications arise when de-whitelisting occurs.  Questions
   that may naturally be raised need to implement new forms of
   monitoring, as noted briefly in Section 7.3.4.  But more critically,
   such a case include whether the
   criteria for de-whitelisting have been fully and transparently
   disclosed, are non-discriminatory, operators will need to add people, processes, and are not anti-competitive.
   Additionally, the question systems in
   order to manage large numbers of DNS Whitelisting applications.
   Since there is no common method for determining whether or not there was a cure period
   available prior
   domain is engaged in DNS Whitelisting, operators will have to apply
   to de-whitelisting, during which troubleshooting
   activities, complaint response work, and corrective actions may be
   attempted, and whether this cure period was whitelisted for a reasonable amount of
   time.

   It is also conceivable that whitelisting and de-whitelisting
   decisions could be quite sensitive to concerned parties beyond the
   operator of the domain based upon one or more end user
   requests, which has implemented DNS Whitelisting means systems, processes, and the
   operator of the DNS recursive resolver, including end users,
   application developers, content providers, advertisers, public policy
   groups, governments, personnel for handling
   and other entities, which may also seek responding to
   become involved in or express opinions concerning whitelisting and/or
   de-whitelisting decisions.  Lastly, it is conceivable that any of
   these interested parties or other related stakeholders may seek
   redress outside of the process a domain has establishing those requests will also be necessary.

   When operators apply for DNS Whitelisting and de-whitelisting.

   A final concern is for all domains, that decisions relating to whitelisting and de-
   whitelisting may occur as an expression of other commercial,
   governmental, and/or cultural conflicts, given the new control point
   which
   mean doing so for all registered domains.  Thus, some system would
   have to be developed to discover whether each domain has been established with
   whitelisted or not, which is touched on in Section 5 and may vary
   depending upon whether DNS Whitelisting.  For example, in
   one imagined scenario, a domain could withhold adding a network Whitelisting is universally deployed or is
   deployed on an ad hoc basis.

   These operators (of DNS recursive resolvers) will need to
   their develop
   processes and systems to track the status of all DNS Whitelisting unless that network agreed
   applications, respond to some sort of
   financial payment, legal agreement, agreement requests for additional information related
   to sever a relationship
   with a competitor these applications, determine when and if applications have been
   denied, manage appeals, and track any de-whitelisting actions.

   Given the large number of domains in existence, the domain, etc.  In another example, ease with which a music-
   oriented
   new domain may can be engaged added, and the continued strong growth in some sort the
   numbers of dispute with an
   academic network concerning copyright infringement concerns within new domains, readers should not underestimate the
   potential significance in personnel and expense that network, this could
   represent for such operators.  In addition, it is likely that systems
   and personnel may choose also be needed to de-whitelist that network as a
   negotiating technique in some sort handle new end user requests for
   domains for which to apply for DNS Whitelisting, and/or inquiries
   into the status of commercial discussion.  In a
   final example, a major email domain may choose whitelisting application, reports of de-
   whitelisting incidents, general inquiries related to de-whitelist DNS
   Whitelisting, and requests for DNS Whitelisting-related
   troubleshooting by these end users.

7.3.4.  Monitoring Implications

   Once a
   network due to that network sending some large volume DNS recursive resolver has been whitelisted for a particular
   domain, then the operator of spam.  Thus,
   it seems that DNS recursive resolver may need to
   implement monitoring in order to detect the possible that loss of DNS
   Whitelisting and de-whitelisting in the future.  This DNS recursive resolver operator
   could
   become configure a vehicle for adjudicating other disputes, and that this may
   well have intended and unintended consequences for end users which
   are affected by such decisions and are unlikely to be able monitor to express check for a strong voice AAAA response in such decisions.

7.6.  IPv6 Adoption Implications

   As noted the
   whitelisted domain, as a check 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 4, the implications of 7.3.6.

   Also, authoritative DNS Whitelisting may drive
   end users and/or networks to delay, postpone, or cancel adoption of
   IPv6, or server operators are likely to actively seek alternatives need to it.  Such alternatives
   implement new forms of monitoring.  In this case, they may
   include desire to
   monitor for significant changes in the use size of multi-layer network address translation (NAT)
   techniques like NAT444 [I-D.shirasaki-nat444], the whitelist within a
   certain period of time, which these parties
   may decide to pursue on might be indicative of a long-term basis to avoid technical
   error such as the perceived
   costs and aggravations related entire ACL being removed.  Authoritative DNS server
   operators may also wish to monitor their workflow process for
   reviewing and acting upon DNS Whitelisting.  This could of
   course come at Whitelisting applications and appeals,
   potentially measuring and reporting on service level commitments
   regarding the very time that an application or appeal can remain at each step
   of the Internet community process, regardless of whether or not such information is trying to
   get these very same parties interested in IPv6 and motivated to begin
   the transition to IPv6.  As a result,
   shared with parties other than that are likely to be
   concerned over the negative implications authoritative DNS server
   operator.

7.3.5.  Implications of Operational Momentum

   It seems plausible that once DNS Whitelisting could
   logically is implemented it will
   be concerned of the negative effects that this practice
   could have very difficult to deprecate such technical and operational
   practices.  This assumption is based on the adoption an understanding of IPv6 if it became widespread or was
   adopted by majors Internet domains or other major parties in the
   Internet ecosystem.

   At the same time, human
   nature, not to mention physics.  For example, as noted Sir Isaac Newton
   noted, "Every object in Section 3, some high-traffic domains
   may find the prospect a state of transitioning to IPv6 daunting without
   having some short-term ability uniform motion tends to incrementally control the amount
   and source remain in
   that state of IPv6 traffic to their domains.  Lacking such controls,
   some domains may choose to substantially delay their transition motion unless an external force is applied to
   IPv6.

7.7.  Implications with Poor IPv4 and Good IPv6 Transport

   It it"
   [Motion].  Thus, once DNS Whitelisting is possible implemented it is quite
   likely that there could be situations where the differing
   quality of it would take considerable effort to deprecate the IPv4
   practice and IPv6 connectivity of an end user could cause
   complications remove it everywhere on the Internet; it may otherwise
   simply remain in accessing content place in perpetuity.  To illustrate this point, one
   could consider for example that there are many email servers
   continuing to attempt to query anti-spam DNS blocklists which is in a have
   long ago ceased to exist.

7.3.6.  Troubleshooting Implications

   The implications of DNS whitelisted domain,
   when present many challenges, as
   detailed throughout Section 7.  These challenges may negatively
   affect the end user's users' ability to troubleshoot, as well as that of DNS
   recursive resolver is not on that whitelist.
   While today most end users' IPv4 connectivity is typically superior
   to IPv6 connectivity (if such connectivity exists at all), there
   could operators, ISPs, content providers, domain owners
   (where they may be implications when different from the reverse is true and operator of the authoritative
   DNS server for their domain), and end user has
   markedly superior IPv6 connectivity as compared to IPv4. other third parties.  This may make
   the process of determining why a server is
   admittedly theoretical but could become not reachable via a factor as the transition FQDN
   significantly more complex and time-consuming.

7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis

   As more domains choose to
   IPv6 continues implement DNS Whitelisting, and IPv4 address availability within more
   networks becomes
   strained.

   For example, in one possible scenario, a user is issued IPv6
   addresses by their ISP become IPv6-capable and has a home network request to be whitelisted, scaling
   up operational processes, monitoring, 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 ACL updates will become
   more difficult.  The increased rate of change and increased size of
   whitelists will increase the likelihood of unique IPv4
   address, configuration and so that ISP uses NAT in order other
   operational errors.

   It is unclear when and if it would be appropriate to reuse IPv4 addresses.
   So change from
   whitelisting to blacklisting.  It also seems unlikely for IPv4 content, the end user must send their IPv4 traffic
   through some additional network element (e.g.  NAT, proxy, tunnel
   server).  Use of this additional network element may cause such a
   change from whitelisting to blacklisting to be coordinated across the end
   user
   Internet, so such a change 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 blacklisting will likely occur on an
   ad-hoc basis as well (if at all).

   Finally, some implementers consider DNS recursive resolver Whitelisting to be a
   temporary measure.  As such, it is not whitelisted by the authoritative
   server for a domain that clear how these implementers
   will judge the user is trying network conditions to access, meaning the
   end user only gets A record responses for their impaired IPv4
   transport rather than also have changed sufficiently to
   justify disabling DNS Whitelisting (or blacklisting, or other AAAA
   resource record responses for their stable access controls) and/or what the process and
   well-performing IPv6 transport.  Thus, timing
   will be in order to discontinue this practice.

7.4.  Homogeneity May Be Encouraged

   A broad trend on the user's poor IPv4
   connectivity situation Internet is potentially exacerbated by not having
   access a move toward more heterogeneity.
   One manifestation of this is in an increasing number, variety, and
   customization of end user hosts, including home networks, operating
   systems, client software, home network devices, and personal
   computing devices.  This trend appears to have had a given domain's IPv6 content since they must use positive effect
   on the
   address family with relatively poor performance.

7.8.  Implications for Users development and growth of Third-Party DNS Recursive Resolvers

   In most cases it is assumed that the Internet and has enabled end
   users will make to connect any technically compliant device or use of DNS
   recursive resolvers any
   technically compatible software to connect to the Internet.  Not only
   does this trend towards greater heterogeneity reduce the control
   which are operated by their network provider,
   whether that is an ISP, campus network, enterprise exerted in the middle of the network, or some
   other type described positively
   in [Tussle], [Rethinking], and [RFC3724], but it also appears to help
   to enable greater and more rapid innovation at the edge of access the
   network.  However there

   Some forms of so-called "network neutrality" principles around the
   world include the notion that any IP-capable device should be able to
   connect to a network, encouraging heterogeneity.  These principles
   are also cases where an
   end user has changed their often explicitly encouraged by application providers, though some
   of these same providers may be using DNS server IP addresses in their device's
   operating system to those Whitelisting.  This is
   ironic, as one implication of the adoption of another party which operates DNS
   recursive resolvers independently Whitelisting 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 to an environment of more homogenous and/or controlled
   end user access networks.  In
   these cases, an authoritative hosts could have unintended side effects on and counter-
   productive implications for future innovation at the edge of the
   network.

7.5.  Technology Policy Implications

   A key technology policy implication concerns the policies and
   processes related to reviewing and making decisions on DNS server may receive a query from
   Whitelisting applications for a
   DNS recursive resolver in one network, though domain, as well as making any
   possible de-whitelisting decisons.  Important questions may include
   whether these policies have been fully and transparently disclosed,
   are non-discriminatory, and are not anti-competitive.  Key questions
   here may include whether appeals are allowed, what the end user sending process is,
   what the original query to expected turn around time is, and whether the DNS recursive resolver is in appeal will be
   handled by an entirely
   different network. independent third party.

   It may therefore is also conceivable that whitelisting and de-whitelisting
   decisions could be more challenging for a DNS
   whitelist implementer quite sensitive to determine concerned parties beyond the level
   operator of IPv6-related
   impairment when such third-party DNS recursive resolvers are used,
   given the wide variety domain operator and the operator of the DNS recursive
   resolver, including end user access networks which may be used users, application developers, content
   providers, advertisers, public policy groups, governments, and that this mix other
   entities.  These concerned parties may change seek to become involved in unpredictable ways over time.

   There or
   express opinions concerning whitelisting and/or de-whitelisting
   decisions.

   A final concern is that decisions relating to whitelisting and de-
   whitelisting may also be cases where end users are using a network where occur as an expression of other commercial,
   governmental, and/or cultural conflicts, given the
   assigned DNS recursive resolver new control point
   which has not been whitelisted by a
   particular authoritative DNS server, but where the end user knows
   that a particular third-party established with DNS recursive resolver has been
   whitelisted.  While Whitelisting.  For example, in most cases the end user will be able to switch
   one imagined scenario, a domain could withhold adding a network to use
   their DNS Whitelisting unless that third-party's servers, network agreed to some access networks may prevent
   switching sort of
   financial payment, legal agreement, agreement to any DNS recursive resolvers other than those authorized
   by or residing within sever a given access network.  While the blocking relationship
   with a competitor of
   third-party DNS recursive resolvers the domain, etc.  In another example, a music-
   oriented domain may be observed engaged in many types some sort of
   networks such as ISPs, campus networks, dispute with an
   academic network concerning copyright infringement concerns within
   that network, and enterprise networks, this may most often be observed in the specialized networks setup choose to de-whitelist that network as a
   negotiating technique in
   hotels, conference centers, coffee shops, and similar access
   networks. some sort of commercial discussion.  In these cases, a
   final example, a major email domain may choose to de-whitelist a
   network due to that network sending some large volume of spam.  Thus,
   it seems possible that whitelisting and de-whitelisting could become
   a vehicle for adjudicating other disputes, and that this may well
   have consequences for end users may be frustrated at their
   inability which are affected by such decisions
   and are unable to access content over IPv6 as express a result strong voice in such decisions.

7.6.  IPv6 Adoption Implications

   As noted in Section 6, the implications of their access
   network preventing them from using a whitelisted third-party DNS
   recursive resolver.  This Whitelisting may also result in complaints drive
   end users and/or networks to both the
   operator delay, postpone, or cancel adoption of the authoritative DNS server which has implemented
   whitelisting as well as
   IPv6, or to actively seek alternatives to it.  Such alternatives may
   include the access use of multi-layer or large scale network operator.

8.  General Implementation Variations

   This section outlines several possible approaches address
   translation (NAT) techniques, which these parties may be
   followed when considering DNS Whitelisting decide to
   pursue on a long-term basis to avoid the perceived costs and associated IPv6-
   aggravations related issues.

8.1.  Implement DNS Whitelisting Universally

   One seemingly obvious approach is to implement DNS whitelisted
   universally, and to do so using some sort of centralized registry Whitelisting.  This could of
   DNS Whitelisting policies, contracts, processes, or other
   information.  Such an approach course come
   at the very time that the Internet community is considered harmful and problematic,
   and almost certain not trying to happen.

8.2.  Implement DNS Whitelisting On An Ad Hoc Basis

   DNS Whitelisting is now being adopted on an ad hoc, or domain-by-
   domain basis.  Therefore, only those domains get these
   very same parties interested in IPv6 and motivated to begin the
   transition to IPv6.  As a result, parties that are likely to be
   concerned over the negative implications of DNS Whitelisting would need to adopt could
   logically be concerned of the practice, though negative effects that this practice
   could have on the adoption of IPv6 if it became widespread.

   At the same time, as noted herein
   discovering that a given domain has done so may be problematic.  Also in this scenario, ad hoc use by a particular domain Section 4, some high-traffic domains
   may be a
   temporary measure that has been adopted to ease find the transition prospect of the
   domain transitioning to IPv6 over daunting without
   having some short-term timeframe.

8.3.  Do Not Implement DNS Whitelisting

   As an alternative ability to adopting DNS Whitelisting, incrementally control the Internet
   community generally can amount
   and source of IPv6 traffic to their domains.  Lacking such controls,
   some domains may choose not to implement DNS Whitelisting,
   perpetuating the current predominant authoritative DNS operational
   model on the Internet.  As a result is is then up substantially delay their transition to end users
   IPv6.

7.7.  Implications with
   IPv6-related impairments to discover Poor IPv4 and fix those impairments,
   though clearly other parties including end user host operating system
   developers can play a critical role [I-D.ietf-v6ops-happy-eyeballs].

8.3.1.  Solve Current End User Good IPv6 Impairments

   A further extension of not implementing DNS Whitelisting, Transport

   It is to also
   endeavor to actually fix the underlying technical problems possible that have
   prompted there could be situations where the consideration differing
   quality of DNS Whitelisting in the first place, as
   an alternative to trying to apply temporary workarounds to avoid the
   symptoms IPv4 and IPv6 connectivity of underlying an end user IPv6 impairments.  A first step is
   obviously to identify which users have such impairments, could cause
   complications in accessing content which would
   appear to be possible, and then to communicate this information to is in a whitelisted domain,
   when the end users.  Such user's DNS recursive resolver is not on that whitelist.
   While today most end user communication users' IPv4 connectivity is likely typically superior
   to IPv6 connectivity (if such connectivity exists at all), there
   could be most helpful
   if implications when the reverse is true and and end user has
   markedly superior IPv6 connectivity as compared to IPv4.  This is not only alerted
   admittedly theoretical but could become a factor as the transition to
   IPv6 continues and IPv4 address availability within networks becomes
   strained.

   For example, in one possible scenario, a potential problem but user is
   given careful and detailed advice on how to resolve this on issued IPv6
   addresses by their
   own, ISP and has a home network and devices or where they can seek help in doing so.  Section 11 may also be
   relevant in
   operating systems which fully support IPv6.  As a result this case.

   One challenge with
   theoretical user has very good IPv6 connectivity.  However, this option is the potential difficulty of
   motivating members end
   user's ISP may have exhausted their available pool of the Internet community to work collectively
   towards this goal, sharing the labor, time, unique IPv4
   address, and costs related to such
   an effort.  Of course, since just such a community effort is now
   underway for IPv6, it is possible so that this would call ISP uses NAT in order to reuse IPv4 addresses.
   So for only a
   moderate amount IPv4 content, the end user must send their IPv4 traffic
   through some additional network element (e.g.  NAT, proxy, tunnel
   server).  Use of this additional work [W6D].

   Despite any potential challenges, many in network element may cause the Internet community are
   already working towards this goal and/or have expressed a general
   preference for this approach.

8.3.2.  Gain Experience Using IPv6 Transition Names

   Another alternative is for domains end
   user to gain experience using an FQDN
   which sub-optimal IPv4 connectivity when certain
   protocols or applications are used.  This user then has become common for domains beginning good IPv6
   connectivity but impaired IPv4 connectivity.  Furthermore, this end
   user's DNS recursive resolver is not whitelisted by the transition to IPv6;
   ipv6.example.com and www.ipv6.example.com.  This can be a way authoritative
   server for a domain that the user is trying to gain IPv6 experience access, meaning the
   end user only gets A record responses for their impaired IPv4
   transport rather than also AAAA record responses for their stable and increase
   well-performing IPv6 use on a relatively
   controlled basis, and to inform any plans for DNS Whitelisting with
   experience.  While this transport.  Thus, the user's poor IPv4
   connectivity situation is a good first step potentially exacerbated by not having
   access to functionally test and
   prepare a domain for IPv6, given domain's IPv6 content since they must use the utility
   address family with relatively poor performance.

7.8.  Implications for Users of the tactic Third-Party DNS Recursive Resolvers

   In most cases it is limited since assumed that end users must know the transition name, the traffic volume will be low,
   and the traffic is unlikely to be representative of the general
   population make use of end users, among other reasons.

8.3.3.  Implement DNS Blacklisting

   Some domains may wish to be more permissive than if they adopted DNS
   Whitelisting Section 8.2, but not still have
   recursive resolvers which are operated by their access network
   provider, whether that is an ISP, campus network, enterprise network,
   or some level other type of control
   over returning AAAA record responses Section 8.3.  An alternative network.  However there are also cases where an
   end user has changed their DNS server IP addresses in
   this case may be their device's
   operating system to employ DNS blacklisting, which would enable all those of a third party which operates DNS
   recursive resolvers to independently of end user access networks.

   In these cases, an authoritative DNS server may receive AAAA record responses except for
   the relatively small number that are listed a query from
   a DNS recursive resolver in one network, though the blacklist.  This
   could enable end user sending
   the original query is in an entirely different network.  It may
   therefore be more challenging for a DNS Whitelist implementer to only prevent such responses where
   there has been a relatively high
   determine the level of IPv6-related impairments,
   until impairment when such time as these impairments can be fixed or otherwise
   meaningfully reduced to an acceptable level.

   This approach is likely to be significantly less labor intensive for
   an authoritative third-party
   DNS server operator, as they would presumably focus
   on a smaller number recursive resolvers are used, given the wide variety of end user
   access networks which may be used and that this mix may change in
   unpredictable ways over time.

   There may also be cases where end users' assigned DNS recursive
   resolvers than if they
   implemented whitelisting.  Thus, these authoritative DNS server
   operators would only need have not been whitelisted for a particular domain, but
   where the end user tries to switch to communicate with a few third-party DNS recursive
   resolver operators rather than potentially all such operators.  This
   should result in lower labor, systems, and process requirements,
   which should be beneficial to all parties.  This is not to say that
   there has been whitelisted.  While in most cases the end user
   will be no time required able to work with those operators affected
   by a blacklist, simply that there are likely switch to be fewer use that third-party's DNS servers, some
   specialized access networks, such
   interactions as in hotels and that each such interaction conference
   centers, may be shorter in
   duration.

   Of course one downside of this approach prevent using third-party DNS servers.  In these cases,
   end users may be that the perception of
   being blocked (blacklisted) is sometimes worse that not being
   permitted frustrated at their inability to have access (whitelisted).  However, the email industry
   has a long experience with blacklists and, very generally speaking,
   blacklists tend to be effective and well received when it is easy certain
   content over IPv6, resulting in complaints to
   discover if a server is on a blacklist, if there is a transparent and
   easily understood process for requesting removal from a blacklist,
   and if the decision-making criteria for placing a server on both a
   blacklist is transparently disclosed and perceived particular
   domain as fair.

9. well as the access network operator.

8.  Is DNS Whitelisting a Recommended Practice?

   Opinions in the Internet community concerning whether or not DNS
   Whitelisting is a recommended practice are understandably quite
   varied.  However, there is clear consensus that DNS Whitelisting is
   at best can
   be a useful tactic a domain may choose to use as they transition to
   IPv6.  In particular, some high-traffic domains view DNS Whitelisting
   as one of the few practical and low-risk approaches enabling them to
   transition to IPv6, without which their transition may not take place
   for some time.  However, there is also consensus is that this
   practice is acceptable workable only in the short-term and that it will not
   scale over the long-term.  Thus, some domains may find DNS
   Whitelisting a beneficial temporary tactic in their transition to
   IPv6.  Such temporary use during the transition to IPv6 is broadly
   accepted within the community, so long as it does not become a long-
   term practice.

   World IPv6 Day, sponsored by the Internet Society [W6D], is scheduled
   to occur on June 8, 2011.  This will be an opportunity for domains to
   add AAAA resource records to the DNS without using DNS Whitelisting.
   As a result, this is likely an excellent opportunity for domains to
   evaluate the utility or necessity of DNS Whitelisting, even in the
   short-term.  A major German news website, Heise Online, also ran a
   similar IPv6 experiment whereby they added AAAA resource records and
   observed and measured any errors [Heise], which is important reading
   for any domain contemplating either the use of DNS Whitelisting or
   simply adding IPv6 addressing to a beneficial temporary tactic in their site.

10. transition to
   IPv6.  Such temporary use during the transition to IPv6 is broadly
   accepted within the community, so long as it does not become a long-
   term practice.

9.  Security Considerations

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

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

10.1.

9.1.  DNSSEC Considerations

   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 Whitelisting is implemented on an
   authoritative DNS server, which provides different answers depending
   upon which DNS resolver server has sent a query, the DNSSEC chain of trust
   is not altered.  Even though the authoritative DNS server will not
   always return a AAAA resource record when one exists, respective A
   resource records and AAAA resource records can and should both be
   signed.  Therefore there are no DNSSEC implications per se.  However,
   any implementer of DNS Whitelisting should be careful if they
   implement both DNSSEC signing of their domain and also DNS
   Whitelisting of that same domain.  Specifically, those domains should
   ensure that resource records are being appropriately and reliably
   signed, which may present modest incremental operational and/or
   technical challenges.

   However, as noted in fourth paragraph of Section 3, 4.2, end user
   networks may also choose to implement tools at their disposal in
   order to address IPv6-related impairments.  One of those possible tools could
   involve unspecified changes to the configuration of their DNS
   recursive resolvers.  If it
   is a those are Security-Aware Resolver, Resolvers,
   modifying or suppressing AAAA resource records for a DNSSEC-signed
   domain will be problematic and could break the chain of trust
   established with DNSSEC.

10.2.

9.2.  Authoritative DNS Response Consistency Considerations

   In addition to the considerations raised in Section 10.1, 9.1, it is
   conceivable that security concerns may arise when end users or other
   parties notice that the responses sent from an authoritative DNS
   server appear to vary 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 of security
   issue and/or some or none of the responses can be trusted.  While
   this may seem a somewhat obscure concern, domains nonetheless may
   wish to consider this when contemplating whether or not to pursue DNS
   Whitelisting.

11.

10.  Privacy Considerations

   As noted in Section 8.3.1, 5.3.1, there may be methods to detect IPv6-
   related impairments for a particular end user.  For example, this may
   be possible when an end user visits the website of a particular
   domain.  In that example, there are likely no privacy considerations
   in automatically communicating to that end user that the domain has
   detected a particular impairment.  However, if that domain decided to
   share information concerning that particular end user with their
   network operator or another party, then the visited domain may wish
   to in some manner advise the end user of this or otherwise seek to
   obtain the user's consent to such information sharing.  This may be
   achieved in a wide variety of ways, from presenting a message asking
   the user for consent (which will of course help them solve a
   technical problem of which they are likely unaware) to adding this to
   a domain's website terms of use / service.  Such information sharing
   and communication of such sharing to end users may well vary by
   geographic area and/or legal jurisdiction.  Thus, a domain should
   consider any potential privacy issues these sorts of scenarios.

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

12.

11.  IANA Considerations

   There are no IANA considerations in this document.

13.

12.  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

14.

13.  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

   - 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

   - Wesley George

   - Philip Homburg

   - Jerry Huang

   - Ray Hunter
   - Joel Jaeggli

   - Erik Kline

   - Suresh Krishnan

   - Victor Kuarsingh

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

15.

14.  References

15.1.

14.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.

15.2.

14.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>.

   [I-D.ietf-v6ops-happy-eyeballs]
              Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending
              Towards Success with Dual-Stack Hosts",
              draft-ietf-v6ops-happy-eyeballs-02 (work in progress),
              May 2011.

   [I-D.shirasaki-nat444]
              Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
              and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work
              in progress), January 2011.

   [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>.

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

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

   [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 Whitelisting -
              Could It Hinder IPv6 Adoption?", ISOC Internet Society
              IPv6 Deployment Workshop, April 2010, <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 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]

   -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 is 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 removed before publication] 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 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
   "Possible Deployment Scenarios",
   "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. I-D.ietf-v6ops-happy-eyeballs.  Per Wesley
   Eddy, updated Section 7.3.2 to address operational concerns and re-titled 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 Ray Hunter,
   added some changes text to the
   DNSSEC De-Whitelisting implications section regarding signing.  As suggested by Suresh Krishnan,
   made several changes to improve various sections
   effects on networks of the document,
   such as adding an alternative concerning the use switching from IPv6 to IPv4.  Updated 7.3.1
   per additional feedback from Karsten Fleischhauer.  Per Dave Crocker,
   added a complete description of ipv6.domain,
   improving the system logic section, and shortening practice to the reference
   titles.  As suggested by Thomas Narten, Abstract, added some text regarding the
   imperfection of making judgements as a
   note to end user host impairments
   based upon the DNS recursive resolver's IP and/or network.  Finally,
   made sure Introduction that variations in the use of 'records' and 'resource
   records' was updated operational impacts are
   particularly acute at scale, added text to 'resource records' for uniformity and Intro to
   avoid confusion.

   -02: Called for and closed out feedback on dnsop make clear this
   practice affects all protocols and v6ops mailing
   lists.  Closed out open feedback items from IETF 79.  Cleared I-D
   nits issues, not just HTTP, 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 new query/
   response diagram, added text to the ISOC
   World IPv6 Day Abstract and the Heise.de test at the suggestion of Jerry
   Huang, as well as Introduction noting
   that this is 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 IPv6 transition mechanism, and too many other references.  Numerous changes
   to list.

   -03: Several changes suggested by John Brzozowski in several sections, to clean up Joel Jaeggli at the
   document.  Moved up end of WGLC.
   This involved swapping the section on why whitelisting is performed order of Section 6.1 and 6.2, among other
   changes 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), readable, understandable, and Erik Kline (from 10/1/2010).
   Also
   tonally balanced.  As suggested by Karsten Fleischhauer, 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
   reference to RFC 4213 in Section 7.1, as a v6ops WG draft.  The preceding
   individual draft was
   draft-livingood-dns-whitelisting-implications-01.  IMPORTANT TO NOTE well as other suggestions to
   that no changes have been section.  As suggested by Tina Tsou, 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 some changes to be removed before publication]

   1.  Ensure references are in the proper
   DNSSEC section (normative/
       informative)

   2.  JD Falk question - should I add a sub-section to 9 to explain how
       best regarding signing.  As suggested by Suresh Krishnan,
   made several changes to implement if you did it? (transparent/published policies,
       SLA on decision making,etc.)

   3.  Per Ray Hunter - "Which is why my original posting 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 that by Thomas Narten, added some text regarding the WG might wish to express a concern about anyone
   imperfection of making
       assumptions about any undocumented architectural links between judgements as to end user host impairments
   based upon the DNS and transport, and also suggest recursive resolver's IP and/or network.  Finally,
   made sure that operators variations in the use of aaaa
       whitelists (party X) should disclose their aaaa methodology and
       data, 'records' and that they should not share whitelist data with other
       aaaa operators in an uncontrolled manner, so that at least Party
       Y could see what 'resource
   records' was happening updated to 'resource records' for uniformity and why, to
   avoid confusion.

   -02: Called for and also have closed out feedback on dnsop and v6ops mailing
   lists.  Closed out open feedback items from IETF 79.  Cleared I-D
   nits issues, added a chance of
       correcting it."

   4.  Per Joe Touch, consider moving section 8 to just after section 3.
       (only do so after -04)

   5.  Per Dave Crocker, on whether or not this is a bit long-winded recommended,
   made language less company-specific based on feedback from Martin
   Millnert, Wes George, and should be edited
       down - in particular removing mentions 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 'parties' 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 various
       parts ("I suggest merely noting that there are concerns and then
       listing and discussing the concerns, rather than adding text load
   balancing section.  Added various other references.  Numerous changes
   suggested by John Brzozowski in several sections, to
       attribute clean up the concerns to others, even if
   document.  Moved up the conclusion of your
       text section on why whitelisting is that performed to
   make the document flow more logically.  Added a particular concern is not valid.") (and ""These
       parties explain their belief" is an example of personalization
       that is not needed.  This isn't about note in the believers.  It is about
       possible problems.").  John Leslie concurs - feels it should be
       simplified.

   6.  Per Pekka Savola and Stephen Farrell, should universal ad hoc
   deployment scenario explaining that a deployment may be removed completely (consider after -04).

   7.  Per Jari Arkko, review temporary,
   and including more of the document again after -04 perceived benefits of this tactic.  Added a
   Privacy Considerations section to ensure the
       right tone address end-user detection and that all motivations are properly accounted for.

   8.  Per Dave Crocker - do we need to change the name
   communication.

   -01: Incorporated feedback received from
       whitelisting to Brian Carpenter (from 10/19/
   2010), Frank Bulk (from 11/8/2010), and Erik Kline (from 10/1/2010).
   Also added an alternate term?  Dave suggests "IPv6 Resolver
       Whitelisting" or "IPv6 DNS Response Preference List" or "DNS
       Response Content Preference List".  Tony Finch suggests: So I
       suggest retitling informative reference at the document "IPv6 DNS resolver whitelisting" suggestion of Wes George
   (from from 10/22/2010).  Closed out numerous editorial notes, and revising the terminology throughout to match.  Mark Andrews
       also suggests "DNS resolver whitelisting
   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 AAAA resolution".
       John Leslie suggests "AAAA-blocking".

   9.  Per Stephen Farrell, consider removing W6D references. a -01 update.

Appendix B.  Open Issues

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

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