IPv6 Operations                                             J. Livingood
Internet-Draft                                                   Comcast
Intended status: Informational                         February 22,                              May 29, 2011
Expires: August 26, November 30, 2011

                IPv6 AAAA DNS Whitelisting Implications
         draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
         draft-ietf-v6ops-v6-aaaa-whitelisting-implications-04

Abstract

   The objective of this document is to describe what the practice of
   whitelisting of DNS recursive resolvers in order to limit AAAA
   resource records is, responses, which contain IPv6 addresses, hereafter
   referred to as DNS
   whitelisting, Whitelisting, as well as the implications of this
   emerging practice and what alternatives or variations may exist.
   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 audience for this document
   is the Internet community generally, including the IETF and 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 August 26, November 30, 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 . . . . . . . . . . . . . . . . . . . . . . . . .  5  4
   2.  How DNS Whitelisting Works . . . . . . . . . . . . . . . . . .  6  5
     2.1.  Description of the Operation of DNS Whitelisting . . . . .  7  6
     2.2.  Comparison with Blacklisting . . . . . . . . . . . . . . .  8
   3.  What Problems Are Implementers Trying To Solve?  . . . . . . .  8
     3.1.  IPv6-Related Impairment  . . . . . . . . . . . . . . . . .  9
     3.2.  Volume-Based Concerns  . . . . . . . . . . . . . . . . . . 10
     3.3.  Free Versus Subscription Services  . . . . . . . . . . . . 10
   4.  Concerns Regarding DNS Whitelisting  . . . . . . . . . . . . .  9 10
   5.  Similarities to Other DNS Operations . . . . . . . . . . . . . 12 13
     5.1.  Similarities to Split DNS  . . . . . . . . . . . . . . . . 12 13
     5.2.  Similarities to DNS Load Balancing . . . . . . . . . . . . 12 13
   6.  Likely  Possible Deployment Scenarios  . . . . . . . . . . . . . . . . . 13 14
     6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis  . . . . . . 13 14
     6.2.  Deploying DNS Whitelisting Universally . . . . . . . . . . 14 15
   7.  Implications of DNS Whitelisting . . . . . . . . . . . . . . . 15 16
     7.1.  Architectural Implications . . . . . . . . . . . . . . . . 15 16
     7.2.  Public IPv6 Address Reachability Implications  . . . . . . 16 17
     7.3.  Operational Implications . . . . . . . . . . . . . . . . . 17 18
       7.3.1.  De-Whitelisting May Occur  . . . . . . . . . . . . . . 17 18
       7.3.2.  Authoritative DNS Server Operational Implications  . . 17 18
       7.3.3.  DNS Recursive Resolver Server Operational
               Implications . . . . . . . . . . . . . . . . . . . . . 18 19
       7.3.4.  Monitoring Implications  . . . . . . . . . . . . . . . 19 20
       7.3.5.  Implications of Operational Momentum . . . . . . . . . 19 21
       7.3.6.  Troubleshooting Implications . . . . . . . . . . . . . 20 21
       7.3.7.  Additional Implications If Deployed On An Ad Hoc
               Basis  . . . . . . . . . . . . . . . . . . . . . . . . 20 21
     7.4.  Homogeneity May Be Encouraged  . . . . . . . . . . . . . . 20 22
     7.5.  Technology Policy Implications . . . . . . . . . . . . . . 21 22
     7.6.  IPv6 Adoption Implications . . . . . . . . . . . . . . . . 22
   8.  Solutions 24
     7.7.  Implications with Poor IPv4 and Good IPv6 Transport  . . . 24
     7.8.  Implications for Users of Third-Party DNS Recursive
           Resolvers  . . . . . . . . . . . . . . . . . . . . . . . . 25
   8.  General Implementation Variations  . . . . . . . . . . . . . . 23 26
     8.1.  Implement DNS Whitelisting Universally . . . . . . . . . . 23 26
     8.2.  Implement DNS Whitelisting On An Ad Hoc Basis  . . . . . . 23 26
     8.3.  Do Not Implement DNS Whitelisting  . . . . . . . . . . . . 23 26
       8.3.1.  Solving  Solve Current End User IPv6 Impairments  . . . . . . 24 . 26
       8.3.2.  Gain Experience Using IPv6 Transition Names  . . . . . 24 27
       8.3.3.  Implement DNS Blacklisting . . . . . . . . . . . . . . 27
   9.  Is DNS Whitelisting a Recommended Practice?  . . . . . . . . . 24 28
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 25 28
     10.1. DNSSEC Considerations  . . . . . . . . . . . . . . . . . . 25 29
     10.2. Authoritative DNS Response Consistency Considerations  . . 26 29
   11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 26 30
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27 30
   13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 30
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 31
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 32
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 32
     15.2. Informative References . . . . . . . . . . . . . . . . . . 29 33
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 31 35
   Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 32 37
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 39

1.  Introduction

   This document describes the emerging practice of whitelisting of DNS
   recursive resolvers in order to limit AAAA resource records (RRs), record (RR)
   responses, which contain IPv6 addresses, hereafter referred to as DNS whitelisting.
   Whitelisting.  The document explores the implications of this
   emerging practice are and what alternatives may exist.

   The practice of  When
   implemented, DNS whitelisting appears to have first been used by
   major web content sites (sometimes described herein as "highly-
   trafficked domains" or "major domains").  These web site operators,
   or domain operators, observed that when they added AAAA resource
   records to their authoritative DNS servers in order to support IPv6
   access to their content that a small fraction of end users had slow
   or otherwise impaired access to a given web site with both AAAA and A
   resource records.  The fraction of users with such impaired access
   has been estimated to be roughly 0.078% of total Internet users
   [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
   Brokenness].  Thus, in an example Internet Service Provider (ISP)
   network of 10 million users, approximately 7,800 of those users may
   experience such impaired access.

   As a result of this impairment affecting end users of a given domain,
   a few major domains have either implemented DNS whitelisting or are
   considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
   When implemented, DNS whitelisting 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 resolvers which are not on the whitelist.  It
   This practice is important to note that these major domains are motivated a type of IPv6 transition mechanism used by domains,
   as a
   desire 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 as "high-traffic domains"), which have specific concerns
   relating to maintain a high-quality user experience for all of their
   users.  By engaging in DNS whitelisting, they are attempting to
   shield
   users with impaired access from the symptoms of those
   impairments. during their transition to IPv6.

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

   o  DNS whitelisting 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 concerning and decision-making for whitelisting and de-whitelisting de-
      whitelisting are
      opaque, opaque or likely to cause conflict,

   o  that DNS whitelisting 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 Whitelisting
      outweigh the perceived benefits, compared to fixing underlying
      impairments. benefits.

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

2.  How DNS Whitelisting Works

   At a high level, using a whitelist means no traffic 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 Whitelisting is implemented in authoritative DNS servers. servers, not in
   DNS recursive resolvers.  These authoritative servers implement IP
   address-based restrictions on AAAA query responses.  So far, DNS whitelisting
   Whitelisting has been primarily implemented by web server operators
   deploying IPv6-enabled services. services, though this practice would affect
   any protocols and services within a domain.  For a given operator of
   a website, such as www.example.com, the 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 AAAA resource record
   responses.  These DNS recursive resolvers are operated by third
   parties, such as ISPs, universities, governments, businesses, and
   individual end users.  If a DNS recursive resolver IS NOT matched in
   the ACL, then AAAA resource records 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 be sent in response to a query for a given hostname in the
   example.com domain.  While these are not network-
   layer network-layer access
   controls they are nonetheless access controls that are a factor for
   end users and other parties like network operators, especially as
   networks and hosts transition from one network address family to
   another (IPv4 to IPv6).

   In practice, DNS whitelisting Whitelisting generally means that a very small
   fraction of the DNS recursive resolvers on the Internet (those in the
   whitelist ACL) will receive AAAA responses.  The large majority of
   DNS 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 some on 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.

   Finally,

   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 can be deployed in two primary ways:
   universally on a global basis, or on an ad hoc basis.  Deployment on
   a universal deployment basis means that DNS whitelisting 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. Whitelisting.  These two potential deployment models
   are described in Section 6.

2.1.  Description of the Operation of DNS Whitelisting

   The system logic of DNS whitelisting Whitelisting is as follows:

   1.  The authoritative DNS server for example.com receives DNS queries
       for the A (IPv4) and and/or AAAA (IPv6) address resource records for
       the FQDN www.example.com, for which AAAA (IPv6) resource records
       exist.

   2.  The authoritative DNS server examines checks the IP address (IPv4, IPv6,
       or both) of the DNS recursive resolver sending the AAAA (IPv6) query.

   3.  The authoritative DNS server checks this IP address
       query against the access control list (ACL) that is the DNS
       whitelist.

   4.

   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.

   5.

   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 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 IS NOT on the DNS
   whitelist:

               Request                      Request
           www.example.com                  www.example.com
                 AAAA    +-------------+     AAAA    +-----------------+
     ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
     ||  ||       A      | **IS NOT**  |      A      | IN A exists     |
   +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
   +--------+     A      | example.com |      A      |                 |
      Host    <--------- |  WHITELIST  |  <--------- |                 |
    Computer   A Record  +-------------+  A Record   +-----------------+
               Response   DNS Recursive   Response       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:
   Whitelist:

               Request                      Request
           www.example.com                  www.example.com
                AAAA     +-------------+     AAAA    +-----------------+
     ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
     ||  ||       A      |   **IS**    |      A      | IN A exists     |
   +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
   +--------+   AAAA     | example.com |     AAAA    |                 |
      Host    <--------- |  WHITELIST  |  <--------- |                 |
    Computer      A      |             |      A      |                 |
              <--------- |             |  <--------- |                 |
              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

3.  What Problems Are Implementers Trying To Solve?

   As noted in Section 1, domains which implement

  ---------------------------------------------------------------------
  Resolver 1 - IS NOT ON the DNS whitelisting are
   attempting to protect a few users of their domain, who have impaired
   IPv6 access, from having a negative experience (poor performance).
   While it is outside the scope of this document to explore the various
   reasons why a particular user's system (host) may have impaired IPv6
   access, for the users who experience this impairment it is a very
   real performance impact.  It would affect access to all or most dual
   stack services to which the user attempts to connect.  This negative
   end user experience can range from someone slower than usual (as
   compared to native IPv4-based access), to extremely slow, to no
   access to the domain whatsoever.

   While one can debate whether DNS whitelisting is the optimal solution
   to Whitelist
  Resolver 2 - IS ON the end user experience problem, it is quite clear that DNS
   whitelisting implementers are interested in maximizing the
   performance of their services Whitelist
  ---------------------------------------------------------------------
  Host 1                      Resolver 1          Authoritative Server
  Query A and AAAA    -----> Query A and AAAA    ----> Receive A and
  for end users as a primary motivation www.example.com        for implementation.

   At least one highly-trafficked domain has noted that they have
   received requests to not send DNS 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 AAAA    ----> Receive A and
  for www.example.com        for www.example.com       AAAA queries

  A (IPv4)   <------------- A (IPv4) and <------------ IS on Whitelist
  AAAA (IPv6)               AAAA (IPv6)                return A (IPv4)
  responses                 responses                  and AAAA (IPv6)
  ---------------------------------------------------------------------

           Figure 2: DNS Whitelisting - Request/Response Diagram

2.2.  Comparison with Blacklisting

   With DNS Whitelisting, DNS recursive resolvers can receive AAAA
   resource records to particular resolvers. only if they are on the whitelist.  In this case, contrast,
   blacklisting would be the operators of
   those opposite whereby all DNS recursive
   resolvers have expressed a concern that their IPv6
   network infrastructure is not yet ready to handle the large traffic
   volume which may be associated with the hosts in their network
   connecting to the websites of these domains.  This concern is clearly
   a temporary consideration relating to the deployment of IPv6 network
   infrastructure can receive AAAA resource records unless they are on the part
   blacklist.  So a whitelist contains a list of networks with end user hosts, rather
   than hosts allowed
   something, whereby a long-term concern.  These end user networks may also have
   other tools at their disposal in order to address this concern,
   including applying rules to network equipment such as routers and
   firewalls (this will necessarily vary by the type blacklist contains a list of network, as well
   as hosts disallowed
   something.  While the technologies used and distinction between the design of a given network), as well
   as configuration concepts of their recursive resolvers (though modifying or
   suppressing AAAA resource records in a DNSSEC-signed domain on a
   Security-Aware Resolver will be problematic Section 10.1).

   Some implementers with highly-trafficked domains have explained that
   DNS
   whitelisting and blacklisting are important, this is a necessary, though temporary, risk reduction
   tactic intended noted
   specifically since some implementers of DNS Whitelisting may choose
   to ease their transition to IPv6 and minimize any
   perceived risk in such a transition.  As a result, they perceive this
   as a tactic DNS Blacklisting before returning to enable them a state without
   address-family-related ACLs in their authoritative DNS servers.  It
   is unclear when and if it would be appropriate to incrementally enable IPv6 connectivity change from
   whitelisting to their domains during blacklisting.  Nor is it clear how implementers will
   judge the early phases of their transition network conditions to IPv6.

   Finally, some domains, have run IPv6 changed sufficiently to justify
   disabling AAAA resource record access controls.

3.  What Problems Are Implementers Trying To Solve?

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

   Finally, some domains, have run IPv6 experiments whereby they added
   AAAA resource records and observed and measured errors [Heise Online
   Experiment], which should be important reading for any domain
   contemplating either the use of DNS whitelisting Whitelisting or simply adding
   IPv6 addressing to their site.

4.  Concerns Regarding

3.1.  IPv6-Related Impairment

   Some implementers have observed that when they added AAAA resource
   records to their authoritative DNS Whitelisting

   There are servers in order to support IPv6
   access to their content that a number small fraction of potential implications relating end users had slow
   or otherwise impaired access to DNS
   whitelisting, which have a given web site with both AAAA and A
   resource records.  The fraction of users with such impaired access
   has been raised estimated to be as concerns by some parts high as 0.078% of the total Internet community.  Many of those potential implications users
   [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
   Brokenness].  In these situations, DNS recursive resolvers are further
   enumerated here and in Section 7.

   Some parties in added
   to the Internet community, including ISPs, are concerned
   that DNS Whitelist only when the practice measured level of impairment of DNS whitelisting for IPv6 address resource
   records represents a departure from
   the generally accepted practices
   regarding IPv4 address resource records in hosts using that resolver declines to some level acceptable by
   the implementer.

   As a result of this impairment affecting end users of a given domain,
   a few high-traffic domains have either implemented DNS on the Internet
   [Whitelisting Concerns].  These parties explain their belief that for
   A resource records, containing IPv4 addresses, once an authoritative
   server operator adds Whitelisting
   or are considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist
   Operations].  While it is outside the A record scope of this document to
   explore the DNS, then any DNS recursive
   resolver on the Internet can receive that A record in response to various reasons why a
   query.  By extension, particular user's system (host) may
   have impaired IPv6 access, for the users who experience this means that any of
   impairment it has a very real performance impact.  It would affect
   access to all or most dual stack services to which the hosts connected user attempts
   to
   any of these DNS recursive resolvers connect.  This negative end user experience can receive range from
   somewhat slower than usual (as compared to native IPv4-based access),
   to extremely slow, to no access to the IPv4 domain whatsoever.  In
   essence, whether the end user even has an IPv6 address
   resource records for or not (they
   probably only have an IPv4 address), merely by receiving a given FQDN.  This enables new server hosts
   which are connected to AAAA
   record response the Internet, and for which user either cannot access a fully qualified 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 name (FQDN) such as www.example.com has been added noted that they
   have received requests to the not send DNS responses with an IPv4 address record, AAAA resource
   records to be almost immediately reachable by
   any host on the Internet. particular resolvers.  In this case, these new servers hosts
   become more and more widely accessible as new networks and new end
   user hosts connect DNS recursive
   resolvers operators have expressed a short-term concern that their
   IPv6 network infrastructure is not yet ready to handle the Internet over time, capitalizing on and
   increasing so-called "network effects" (also called network
   externalities).  It also means large
   traffic volume that may be associated with the new server hosts do not need
   to know about these new networks and new end user hosts in order to
   make their content and applications available to them, in essence
   that each end in this end-to-end model is responsible for network
   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 or servers knowing about websites of these domains.  These end points and
   whether one is allowed to contact the other.

   In contrast, the concern is that DNS whitelisting user networks
   may fundamentally
   change also have other tools at their disposal in order to address this model.  In the altered DNS whitelisting end-to-end model,
   one end (where the end user is located) cannot readily connect
   concern, including applying rules to network equipment such as
   routers and firewalls (this will necessarily vary by the
   other end (where the content is located), without parts type of
   network, as well as the middle
   (recursive resolvers) technologies used by one end (the client, or end user hosts)
   being known to an intermediary (authoritative nameservers) and
   approved for access to the design of a given
   network), as well as configuration of their DNS recursive resolvers
   (though modifying or suppressing AAAA resource at the end.  As new networks
   connect to the Internet over time, those networks need to contact any
   and all domains which have implemented DNS whitelisting records in order to
   apply to a DNSSEC-
   signed domain on a Security-Aware Resolver will be added problematic
   Section 10.1).

3.2.  Volume-Based Concerns

   Some implementers are trying to gradually add IPv6 traffic to their DNS whitelist, in the hopes of making the
   content
   domain since they may find that network operations, tools, processes
   and applications residing on named server hosts in those procedures are less mature for IPv6 as compared to IPv4.  While
   for domains accessible with small to moderate traffic volumes, whether by the
   count of end user hosts on that new network.
   Furthermore, this same need to contact all users or count of bytes transferred, high-traffic
   domains implementing DNS
   whitelisting also applies to all pre-existing (but not whitelisted)
   networks connected to the Internet.

   In the current IPv4 Internet when receive such a new server host is added to the
   Internet it is generally widely available to all end user hosts and
   networks, when DNS whitelisting level of IPv6 resource records usage that it is used,
   these new server hosts are not accessible prudent to undertake
   any end user hosts network changes gradually or
   networks until such time as the operator in a manner which minimizes any risk
   of disruption.  For example, one can imagine for one of the authoritative top ten
   sites globally that the idea of suddenly turning on a significant
   amount of IPv6 traffic might be quite daunting.  DNS
   servers Whitelisting may
   therefore offer such high-traffic domains one potential method for those new server hosts expressly authorizes access
   incrementally enabling IPv6.  Thus, some implementers with high-
   traffic domains plan to
   those new server hosts by adding use DNS recursive resolvers around the
   Internet Whitelisting is a necessary, though
   temporary, risk reduction tactic intended to the ACL.  This has the potential ease their transition to be a significant
   change in reachability of content and applications by end users and
   networks as these end user hosts
   IPv6 and networks transition to IPv6,
   resulting in more (but different) breakage.  A concern expressed is
   that if much of the content that end users are most interested minimize any perceived risk in is
   not accessible as a result, then end users and/or networks may resist
   adoption of IPv6 or actively seek alternatives to it, such as using
   multi-layer network address translation (NAT) techniques like NAT444
   [I-D.shirasaki-nat444] on a long-term basis.  There transition.

3.3.  Free Versus Subscription Services

   It is also concern
   that this practice also could disrupt worth noting the continued increase in
   Internet adoption by end users if they cannot simply access new
   content and applications but must instead contact differences between domains containing
   primarily subscription-based services compared to those containing
   primarily free services.  In the operator case of
   their DNS recursive resolver, free services, such as their ISP or another third
   party, to
   search engines, end users have their DNS recursive resolver authorized for access to no direct billing relationship with
   the content or applications that interests them.  Meanwhile, these
   parties say, over 99.9% of domain and can switch sites simply by changing the address they
   enter into their browser (ignoring other end users that are also using
   that same network value added services which
   may tie a user?s preference to a given domain or DNS recursive resolver otherwise create
   switching costs).  As a result, such domains explain that they
   believe they are unable more sensitive to access the
   IPv6-based content, despite quality of the services within
   their experience being a positive one.

   While in Section 1 domain since if the level of IPv6-related impairment user has been
   estimated issues when they turn on IPv6,
   then that user could switch 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 of IPv4-related impairment is more or less another domain that this percentage (which in any case is likely to have declined
   since its original citation).  Indeed, as 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 using IPv6.

4.  Concerns Regarding DNS Whitelisting

   The implications relating to or DNS Whitelisting are
   otherwise not further enumerated
   here and in a position to be able to measure IPv4 impairment
   (since this could result Section 7.

   Some parties in no the Internet access whatsoever).  As a
   result, it is worth considering that IPv4-related impairment could
   exceed that of IPv6-related impairment and community, including ISPs, are concerned
   that such IPv4-related
   impairment may have simply been accepted as "background noise" on the
   Internet practice of DNS Whitelisting for IPv6 address resource
   records represents a variety of reasons.  Of course, this comparison of departure from the
   level of worldwide IPv6 impairments to generally accepted practices
   regarding IPv4 impairments is
   speculation, as the author is not aware of any good measurement of
   IPv4-related impairments which are comparable address resource records in nature to the IPv6-
   related impairment measurements which have recently been conducted
   around DNS on the world.

   An additional concern is Internet
   [Whitelisting Concerns].  These parties explain their belief that
   once an authoritative server operator adds an A record (IPv4) to the IP address of a
   DNS, then any DNS recursive resolver
   is not a precise indicator of on the IPv6 preparedness, or lack of IPv6-
   related impairments, of end user hosts which query (use) Internet can receive that
   A record in response to a particular
   recursive resolver.  While the recursive resolver may be an imperfect
   proxy for judging IPv6 preparedness, it is at least one query.  By extension, this means that any
   of the best
   available methods at the current time.

5.  Similarities hosts connected to Other DNS Operations

   Some aspects any of these DNS whitelisting may be considered similar to other
   common DNS operational techniques recursive resolvers can
   receive the IPv4 address resource records for a given FQDN.  This
   enables new server hosts which are explored below.

5.1.  Similarities connected to Split DNS

   DNS whitelisting the Internet, and for
   which a fully qualified domain name (FQDN) such as www.example.com
   has some similarities been added to so-called split DNS,
   briefly described in Section 3.8 of [RFC2775].  When split DNS is
   used, the authoritative DNS server returns different responses
   depending upon what with an IPv4 address record, to be almost
   immediately reachable by any host has sent the query.  While [RFC2775] notes on the typical use of split DNS is to provide one answer to Internet.  In this case,
   these new servers hosts on an
   Intranet become more and a different answer to more widely accessible as new
   networks and new end user hosts on the Internet, the essence
   is that different answers are provided connect to hosts on different
   networks.  This is basically the way Internet over time,
   capitalizing on and increasing so-called "network effects" (also
   called network externalities).  It also means that DNS whitelisting works,
   whereby the new server
   hosts on different networks, which use different DNS
   recursive resolvers, receive different answers if one DNS recursive
   resolver is on the whitelist and the other is not.

   In [RFC2956], Internet transparency do not need to know about these new networks and Internet fragmentation
   concerns regarding split DNS are detailed in Section 2.1.  [RFC2956]
   further notes new end user
   hosts in Section 2.7, concerns regarding split DNS and that
   it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint
   identifiers more complex."  Section 3.5 of [RFC2956] further
   recommends that maintaining a stable approach order to DNS operations is
   key during transitions such as the one make their content and applications available to IPv6 that is underway now,
   stating
   them, in essence that "Operational stability of DNS each end in this end-to-end model is paramount, especially
   during a transition of
   responsible for connecting to the network layer, and both IPv6 Internet and some
   network address translation techniques place a heavier burden on
   DNS."

5.2.  Similarities once they have done so
   they can connect to DNS Load Balancing

   DNS whitelisting also has some similarities each other without additional impediments or
   middle networks or intervening networks or servers knowing about
   these end points and whether one is allowed to DNS load balancing.
   There are of course many ways contact the other.

   In contrast, the concern is that DNS load balancing can be
   performed. Whitelisting may fundamentally
   change this model.  In one example, multiple IP address resource records (A
   and/or AAAA) can be added to the altered DNS for a given FQDN.  This approach Whitelisting end-to-end model,
   one end (where the end user is referred located) cannot readily connect to as DNS round robin [RFC1794].  DNS round robin may
   also be employed where SRV resource records are the
   other end (where the content is located), without parts of the middle
   (DNS recursive resolvers) used [RFC2782].

   In another example, by one end (the client, or more of end user
   hosts) being known to an intermediary (authoritative nameservers) and
   approved for access to the IP address resource records in at the DNS will direct traffic end.  As new networks
   connect to a load balancer.  That load balancer, the Internet over time, those networks need to contact any
   and all domains which have implemented DNS Whitelisting in turn, may order to
   apply to be application-aware, added to their DNS whitelist, in the hopes of making the
   content and pass applications residing on named server hosts in those
   domains accessible by the traffic end user hosts on that new network.
   Furthermore, this same need to one or
   more hosts contact all domains implementing DNS
   Whitelisting also applies to all pre-existing (but not whitelisted)
   networks connected to the load balancer which have different IP
   addresses. Internet.

   In cases where private the current IPv4 addresses are used [RFC1918],
   as well as Internet when public IP addresses are used, those end hosts may not
   be directly reachable without passing through the load balancer first
   .  As such, while the IP address resource records have been a new server host is added to the DNS, the
   Internet it is generally widely available to all end user hosts; when
   DNS Whitelisting of IPv6 resource records is used, these new server
   hosts are not necessarily directly reachable, which
   is in a small way similar to one aspect of DNS whitelisting.

   Additionally, accessible via a geographically-aware authoritative DNS server may be
   used, as is common with Content Delivery Networks (CDNs) or Global
   Load Balancing (GLB, also referred to FQDN by any end user hosts until such
   time as Global Server Load
   Balancing, or GSLB), whereby the IP address resource records returned
   to a resolver in response to a query will vary based on the estimated
   geographic location operator of the resolver [Resolvers in the Wild].  CDNs
   perform this function in order to attempt to direct authoritative DNS servers for those new
   server hosts expressly authorizes access to connect
   to the nearest content cache.  As a result, one can see some
   similarities with those new server hosts by
   adding DNS whitelisting insofar as different IP address
   resource records are selectively returned to recursive resolvers based on around the
   IP address of each resolver (or other imputed factors related Internet to that
   IP address).  However, what is different is that in this case the
   resolvers are not deliberately blocked from receiving DNS responses
   containing an entire class of addresses; this load balancing function
   strives ACL.  This
   has the potential to perform be a significant change in reachability of
   content location-improvement function and not an
   access control function.

6.  Likely Deployment Scenarios

   In considering how DNS whitelisting may emerge more widely, there are
   two likely deployment scenarios, which are explored below.

   In either of applications by end users and networks as these deployment scenarios, it is possible that
   reputable third parties could create end user
   hosts and maintain DNS whitelists, networks transition to IPv6, resulting in more (but
   different) breakage.  A concern expressed is that if much of the same way
   content that blacklists end users are used for reducing email spam.
   In the email context, a mail operator subscribes to one or more of
   these lists and most interested in is not accessible as such the operational processes for additions and
   deletions to the list are managed by a third party.  A similar model
   could emerge for DNS whitelisting, whether deployment occurs
   universally
   result, then end users and/or networks may resist adoption of IPv6 or
   actively seek alternatives to it, such as using multi-layer network
   address translation (NAT) techniques like NAT444
   [I-D.shirasaki-nat444] on an ad hoc a long-term basis.

6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis

   The seemingly most likely deployment scenario  There is where some
   authoritative DNS server operators implement DNS whitelisting but
   many or most others do not do so.  What can make also concern
   that this scenario
   challenging from practice could disrupt the standpoint continued increase in Internet
   adoption by end users if they cannot simply access new content and
   applications but must instead contact the operator of a their DNS
   recursive resolver operator
   is determining which domains implement DNS whitelisting, particularly
   since a domain may not do so resolver, such as they initially transition their ISP or another third party, to IPv6,
   and may instead do so later.  Thus, a have
   their DNS recursive resolver operator
   may initially believe authorized for access to the content or
   applications that they can receive AAAA responses as a
   domain adopts IPv6, but then notice via interests them.  Meanwhile, these parties say, over
   99.9% of the other end user reports users that they no
   longer receive AAAA responses due to are also using that domain adopting same network or
   DNS
   whitelisting.  Of course, a domain's IPv6 transition may be
   effectively invisible to recursive server operators due resolver are unable to access the effect
   of DNS whitelisting.

   In contrast to IPv6-based content,
   despite their experience being a universal deployment of DNS whitelisting positive one.

   While in Section 6.2, deployment on an ad hoc basis is likely 1 the level of IPv6-related impairment has been
   estimated to be
   significantly more challenging from an operational, monitoring, and
   troubleshooting standpoint.  In this scenario, a DNS recursive
   resolver operator will have no way to systematically determine
   whether DNS whitelisting is or as high as 0.078% of Internet users, which is not implemented for a domain, since
   primary motivation cited for the absence practice of AAAA resource records may simply be indicative that
   the domain has DNS Whitelisting, it is
   not yet added IPv6 addressing for clear if the domain, rather
   than level of IPv4-related impairment is more or less
   that they have done so but have restricted query access via DNS
   whitelisting.  As a result, discovering which domains implement DNS
   whitelisting, this percentage (which in order to differentiate them from those that do not, any case is likely to have declined
   since its original citation).  Indeed, as at least one document
   reviewer has pointed out, it may simply be challenging.

   One benefit of DNS whitelisting being deployed on an ad hoc basis is that websites are only the domains that
   measuring IPv6 impairments and not IPv4 impairments, whether because
   IPv6 is new or whether those websites are interested in doing so would have simply unable to
   upgrade their authoritative DNS servers or are
   otherwise not in order a position to implement the
   ACLs necessary be able to perform DNS whitelisting.

   In measure IPv4 impairment
   (since this potential deployment scenario, it is also possible that a
   given domain will implement DNS whitelisting temporarily.  A domain,
   particularly a highly-trafficked domain, may choose to do so could result in order
   to ease their transition to IPv6 through no Internet access whatsoever).  As a selective deployment
   result, it is worth considering that IPv4-related impairment could
   exceed that of IPv6-related impairment and
   minimize any perceived risk in that such a transition.

6.2.  Deploying DNS Whitelisting Universally

   The least likely deployment scenario is one where DNS whitelisting is
   implemented IPv4-related
   impairment may have simply been accepted as "background noise" on all authoritative DNS servers, across the entire
   Internet.  While
   Internet for a variety of reasons.  Of course, this scenario seems less likely than ad hoc
   deployment due comparison of the
   level of worldwide IPv6 impairments to some parties IPv4 impairments is
   speculation, as the author is not sharing aware of any good measurement of
   IPv4-related impairments which are comparable in nature to the concerns that IPv6-
   related impairment measurements which have so
   far motivated recently been conducted
   around the use world.

   An additional concern is that the IP address of a DNS whitelisting, it recursive
   resolver is nonetheless
   conceivable that it could be one not a precise indicator of the ways in IPv6 preparedness, or lack
   of IPv6-related impairments, of end user hosts which query (use) a
   particular DNS
   whitelisting is deployed.

   In order recursive resolver.  While the DNS recursive resolver
   may be an imperfect proxy for this deployment scenario to occur, judging IPv6 preparedness, it is likely that DNS
   whitelisting functionality would need at
   least one of the best available methods at the current time.

5.  Similarities to be built into all
   authoritative Other DNS server software, and that all operators Operations

   Some aspects of
   authoritative DNS servers would have to upgrade their software and
   enable this functionality.  It is likely that new Internet Draft
   documents would need to Whitelisting may be developed considered similar to other
   common DNS operational techniques which describe how are explored below.

5.1.  Similarities to properly
   configure, deploy, and maintain Split DNS whitelisting.  As a result, it is
   unlikely that

   DNS whitelisting would, at least Whitelisting has some similarities to so-called split DNS,
   briefly described in Section 3.8 of [RFC2775].  When split DNS is
   used, the next several
   years, become universally deployed.  Furthermore, these authoritative DNS
   whitelists are likely to vary on a domain-by-domain basis, server returns different responses
   depending upon a variety of factors.  Such factors may include what host has sent the motivation
   of each domain owner, query.  While [RFC2775] notes
   the location typical use of the split DNS recursive resolvers in
   relation is to the source content, as well as various other parameters
   that may be transitory in nature, or unique provide one answer to hosts on an
   Intranet and a specific end user
   host type.  It different answer to hosts on the Internet, the essence
   is probably unlikely that a single clearinghouse for
   managing whitelisting is possible; it will more likely be unique different answers are provided to hosts on different
   networks.  This is basically the source content owners and/or domains way that DNS Whitelisting works,
   whereby hosts on different networks which implement use different DNS
   whitelists.

   While this scenario may be unlikely, it may carry some benefits.
   First, parties performing troubleshooting would not have to determine
   whether or not recursive
   resolvers, receive different answers if one DNS whitelisting was being used, as it always would be
   in use.  In addition, if universally deployed, it recursive resolver is possible that
   on the criteria for being added to or removed from a DNS whitelist could
   be standardized across and the entire Internet.  Nevertheless, even if
   uniform DNS whitelisting policies were not standardized, other is also
   possible that a central registry of these policies could be developed not.

   In [RFC2956], Internet transparency and deployed Internet fragmentation
   concerns regarding split DNS are detailed in order to make it easier to discover them, a key part
   of achieving transparency Section 2.1.  [RFC2956]
   further notes in Section 2.7, concerns regarding split DNS whitelisting.

7.  Implications and that
   it "makes the use of DNS Whitelisting

   There are many potential implications Fully Qualified Domain Names (FQDNs) as endpoint
   identifiers more complex."  Section 3.5 of [RFC2956] further
   recommends that maintaining a stable approach to DNS whitelisting.  The operations is
   key
   potential implications are detailed below.

7.1.  Architectural Implications

   DNS whitelisting could be perceived during transitions such as modifying the end-to-end model
   and/or the general notion of the architecture one to IPv6 that prevails on the
   Internet today.  This is because this approach moves additional
   access control information and policies into the middle underway now,
   stating that "Operational stability of the DNS
   resolution path is paramount, especially
   during a transition of the IPv6-addressed Internet, which generally did
   not exist before network layer, and both IPv6 and some
   network address translation techniques place a heavier burden on the IPv4-addressed Internet.  This poses
   DNS."

5.2.  Similarities to DNS Load Balancing

   DNS Whitelisting also has some
   risks noted in [RFC3724].  In explaining the history similarities to DNS load balancing.
   There are of the end-to-
   end principle [RFC1958] states course many ways that one of the goals is DNS load balancing can be
   performed.  In one example, multiple IP address resource records (A
   and/or AAAA) can be added to minimize
   the state, policies, and other functions needed in the middle DNS for a given FQDN.  This approach
   is referred to as DNS round robin [RFC1794].  DNS round robin may
   also be employed where SRV resource records are used [RFC2782].

   In another example, one or more of the
   network IP address resource records in order
   the DNS will direct traffic to enable end-to-end communications a load balancer.  That load balancer,
   in turn, may be application-aware, and pass the traffic on to one or
   more hosts connected to the Internet. load balancer which have different IP
   addresses.  In this case, the middle network should cases where private IPv4 addresses are used [RFC1918],
   as well as when public IP addresses are used, those end hosts may not
   be understood directly reachable without passing through the load balancer first
   .  As such, while the IP address resource records have been added to mean
   anything other than
   the DNS, the end hosts involved are not necessarily directly reachable, which
   is in communicating with one
   another.  Some state, policies, and other functions have always been
   necessary a small way similar to enable such end-to-end communication, but the goal one aspect of DNS Whitelisting.

   Additionally, a geographically-aware authoritative DNS server may be
   used, as is common with Content Delivery Networks (CDNs) or Global
   Load Balancing (GLB, also referred to as Global Server Load
   Balancing, or GSLB), whereby the approach has been IP address resource records returned
   to minimize this a resolver in response to a query will vary based on the greatest extent
   possible.

   It is also possible that DNS whitelisting could place at risk some estimated
   geographic location of the observed benefits of resolver [Resolvers in the end-to-end principle, as listed Wild].  CDNs
   perform this function 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 order to attempt to direct hosts to connect
   to the nearest content cache.  As a result, one can see some
   similarities with DNS
   whitelisting approach, especially concerning modified DNS servers
   noted in Section 2.16 of [RFC3234], as well Whitelisting insofar as more general concerns
   noted in Section 1.2 of [RFC3234] about different IP address
   resource records are selectively returned to resolvers based on the introduction
   IP address of new
   failure modes.  In particular, there may be concerns each resolver (or other imputed factors related to that
   configuration
   IP address).  However, what is different is no longer limited to two ends of a session, and that
   diagnosis in this case the
   resolvers are not deliberately blocked from receiving DNS responses
   containing an entire class of failures addresses; this load balancing function
   strives to perform a content location-improvement function and misconfigurations becomes more complex.

   Two additional sources worth not an
   access control function.

6.  Possible Deployment Scenarios

   In considering as far as implications for
   the end-to-end model how DNS Whitelisting may emerge more widely, there are concerned
   two main deployment scenarios, which are [Tussle in Cyberspace] and
   [Rethinking the Internet]. explored below.

   In [Tussle either of these deployment scenarios, it is possible that
   reputable third parties could create and maintain DNS whitelists, in Cyberspace],
   much the authors
   note concerns regarding same way that blacklists are distributed and used for
   reducing email spam.  In the introduction email context, a mail operator
   subscribes to one or more of new control points, as
   well these lists and as "kludges" to such the DNS, as risks operational
   processes for additions and deletions to the goal of network
   transparency in the end-to-end model.  Some parties concerned with
   the emerging use of DNS whitelisting have shared list are managed by a
   third party.  A similar concerns,
   which may make [Tussle in Cyberspace] model could emerge for DNS Whitelisting,
   whether deployment occurs universally or on an interesting and relevant
   document.  In addition, [Rethinking the Internet] reviews similar
   issues that may be of interest to readers of this document.

   Also, it ad hoc basis.

   An additional factor in either scenario is possible that a DNS whitelisting could affect some of the
   architectural assumptions which underlie parts of Section 2 of
   [RFC4213] which outlines the dual stack approach recursive
   resolver operator will have to the IPv6
   transition. determine whether or not DNS whitelisting could modify the behavior of
   Whitelisting has been implemented for a domain, since the DNS,
   as described in Section 2.2 of [RFC4213] and could require different
   sets absence of DNS servers to
   AAAA resource records may simply be used for hosts that are (using terms from indicative 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 of standards documents which describe dual-stack and
   IPv6 operating modes, dual-stack architecture generally, and IPv6
   transition methods, including but domain has
   not limited to [RFC4213].

7.2.  Public yet added IPv6 Address Reachability Implications

   The predominant experience of end user hosts and servers on the IPv4-
   addressed Internet today is that when a new server with a public IPv4
   address is added to addressing for the DNS, domain, rather than that it is then globally accessible by
   IPv4-addressed hosts. 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 a generalization and in Section 5
   there are examples of common cases where this may some authoritative DNS
   server operators implement DNS Whitelisting but many or most others
   do not necessarily be
   the case.  For the purposes of this argument, that concept of
   accessibility do so.  What can be considered "pervasive reachability".  It has so
   far been assumed that the same expectations of pervasive reachability
   would exist in the IPv6-addressed Internet.  However, if DNS
   whitelisting is deployed, make this will not be scenario challenging from the case since only end
   user hosts using
   standpoint of a DNS recursive resolvers resolver operator is determining which are included in the
   ACL of
   domains implement DNS Whitelisting, particularly since a given domain using DNS whitelisting would be able may
   not do so as they initially transition to reach
   new servers in IPv6, and may instead do so
   later.  Thus, a DNS recursive resolver operator may initially believe
   that given they can receive AAAA responses as a domain adopts IPv6, but
   then notice via IPv6 addresses.  The expectation
   of any end user host being able reports that they no longer receive AAAA
   responses due to connect that domain adopting DNS Whitelisting.  Of course, a
   domain's IPv6 transition may be effectively invisible to any server (essentially
   both hosts, just at either end 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 network), defined here as
   "pervasive reachability", will change domains that are interested in doing so would have to "restricted reachability"
   with IPv6.

   Establishing
   upgrade their authoritative DNS whitelisting as an accepted practice servers in order to implement the early
   phases of mass IPv6 deployment could well establish it as an integral
   part of how IPv6
   ACLs necessary to perform DNS resource records Whitelisting.  Some domains have
   proposed or are deployed globally.  As a
   result, 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 then also possible that DNS whitelisting could live on for
   decades on the Internet as a key foundational element of
   given domain name
   management that we will all live with for a long time.

   It is implement DNS Whitelisting temporarily.  A domain,
   particularly a critical high-traffic domain, may choose to understand that the concept of reachability
   described above depends upon a knowledge or awareness of an address
   in the DNS.  Thus, do so in order to establish reachability
   ease their transition to an end
   point, IPv6 through a host is dependent upon looking up an IP address selective deployment and
   minimize any perceived risk in the DNS
   when such a FQDN is used.  When DNS whitelisting is used, transition.  In addition, it is quite
   likely the case
   possible that an IPv6-enabled end user host could ping one or
   connect to an example server host, even though the FQDN associated
   with that server host is restricted via a more DNS whitelist.  Since most
   Internet applications and hosts such as web Whitelist clearinghouses may emerge,
   providing implementers with a way to subscribe to a whitelist in a
   manner similar to that used on email servers depend upon for blacklists.

6.2.  Deploying DNS Whitelisting Universally

   The less likely deployment scenario is one where DNS Whitelisting is
   implemented on all authoritative DNS servers, across the
   DNS, and as end users connect entire
   Internet.  While this scenario seems less likely than ad hoc
   deployment due to FQDNs such as www.example.com and do some parties not remember or wish to type in an IP address, sharing the notion concerns that have so
   far motivated the use of
   reachability described here should DNS Whitelisting, it is nonetheless
   conceivable that it could be understood to include knowledge
   how to associate a name with a network address.

7.3.  Operational Implications

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

7.3.1.  De-Whitelisting May Occur

   It
   Whitelisting is possible for deployed, though such a DNS recursive resolver added universal deployment could be
   considered harmful and problematic.

   In order for this deployment scenario to a whitelist occur, it is likely that DNS
   Whitelisting functionality would need to
   then be removed from the whitelist, also known as de-whitelisting.
   Since de-whitelisting can occur, through a decision by the built into all
   authoritative DNS server operator, the domain owner, or even due to a
   technical error, an operator software, and that all operators of a
   authoritative DNS recursive resolver will servers would have
   new operational to upgrade their software and monitoring requirements and/or needs as noted in
   Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.

7.3.2.  Authoritative DNS Server Operational Implications

   Operators of authoritative servers may
   enable this functionality.  It is likely that new IETF Request for
   Comment (RFC) documents would need to be developed which describe how
   to properly configure, deploy, and maintain an ACL DNS Whitelisting.  As a
   server-wide basis affecting all domains,
   result, it is unlikely that DNS Whitelisting would, at least in the
   next several years, become universally deployed.  Furthermore, these
   DNS whitelists are likely to vary on a domain-by-domain basis,
   as well as on
   depending upon a combination variety of the two.  As a result, operational
   practices and software capabilities may need to be developed in order
   to support such functionality.  In addition, processes factors.  Such factors may need to be
   put include the
   motivation of each domain owner, the location of the DNS recursive
   resolvers in place relation to protect against inadvertently adding or removing IP
   addresses, the source content, as well as systems and/or processes to respond to such
   incidents if and when they occur.  For example, a system various other
   parameters that may be
   needed transitory in nature, or unique to record DNS whitelisting requests, report on their status
   along a workflow, add IP addresses when specific
   end user host type.  It is probably unlikely that a single
   clearinghouse for managing whitelisting has been
   approved, remove IP addresses when they have been de-whitelisted, log
   the personnel involved and timing of changes, schedule changes is possible; it will more
   likely be unique to
   occur in the future, and to roll back any inadvertent changes.

   Operators may also need source content owners and/or domains which
   implement new forms of monitoring in order to
   apply change control, as noted briefly in Section 7.3.4.

7.3.3. DNS Recursive Resolver Server Operational whitelists (so multiple clearinghouses are certainly
   possible).

7.  Implications

   Operators of DNS recursive resolvers, which may include ISPs,
   enterprises, universities, governments, individual end users, and
   many other parties, Whitelisting

   There are likely to need to implement new forms many implications of
   monitoring, as noted briefly in Section 7.3.4.  But more critically,
   such operators may need to add people, processes, DNS Whitelisting.  The key
   implications are detailed below.

7.1.  Architectural Implications

   DNS Whitelisting modifies the end-to-end model and systems in
   order to manage large numbers the general notion
   of DNS whitelisting applications as
   part spontaneous interoperability of their own IPv6 transition, for all domains the architecture that prevails on
   the end users Internet today.  This is because this approach moves additional
   access control information and policies into the middle of such servers are interested in now or in the DNS
   resolution path of the IPv6-addressed Internet, which they may be
   interested 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 future.  As anticipation history of interesting domains is
   likely infeasible, it is more likely the end-
   to-end principle [RFC1958] states that operators may either choose
   to only apply to be whitelisted for a domain based upon one or more
   end user requests, or that they will attempt of the goals is to do so for all domains
   that they can ascertain
   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 engaging in DNS whitelisting.

   When operators apply for DNS whitelisting for all domains, that may
   mean doing so for all registered domains.  Thus, some system would
   have to be developed understood
   to discover whether each domain has been
   whitelisted or not, which is touched on mean anything other than the end hosts involved 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 recursive resolvers) will need to develop
   processes communicating
   with one another.  Some state, policies, and systems other functions have
   always been necessary to track enable such end-to-end communication, but
   the status goal of all DNS whitelisting
   applications, respond the approach has been to requests for additional information related minimize this to these applications, determine when and if applications have been
   denied, manage appeals, and track any de-whitelisting actions.

   Given the large number greatest
   extent possible.

   It is also possible that DNS Whitelisting could place at risk some of domains in existence, the ease with which a
   new domain can be added, and the continued strong growth in
   the
   numbers observed benefits of new domains, readers should not underestimate the
   potential significance end-to-end principle, as listed in personnel and expense that this could
   represent for
   Section 4.1 of [RFC3724], such operators.  In addition, it is likely that systems as protection of innovation.
   [RFC3234] details issues and personnel concerns regarding so-called
   middleboxes, so there may also be needed to handle new end user requests for
   domains for which to apply for DNS whitelisting, and/or inquiries
   into parallel concerns with the status of a whitelisting application, reports of de-
   whitelisting incidents, general inquiries related to DNS
   whitelisting, and requests for DNS whitelisting-related
   troubleshooting by these end users.

7.3.4.  Monitoring Implications

   Once a
   Whitelisting approach, especially concerning modified DNS recursive resolver has been whitelisted for a particular
   domain, then servers
   noted in Section 2.16 of [RFC3234], as well as more general concerns
   noted in Section 1.2 of [RFC3234] about the operator introduction of that DNS recursive resolver new
   failure modes.  In particular, there may need to
   implement monitoring in order be concerns that
   configuration is no longer limited to detect the possible loss two ends of
   whitelisting status in the future.  This DNS recursive resolver
   operator could configure a monitor to check session, and that
   diagnosis of failures and misconfigurations becomes more complex.

   Two additional sources worth considering as far as implications for a AAAA response
   the end-to-end model are concerned are [Tussle in Cyberspace] and
   [Rethinking the whitelisted domain, as a check to validate continued status on Internet].  In [Tussle in Cyberspace], the DNS whitelist.  The monitor could then trigger an alert if at
   some point authors
   note concerns regarding the AAAA responses were no longer received, so that
   operations personnel could begin troubleshooting, introduction of new control points, as outlined in
   Section 7.3.6.

   Also, authoritative DNS server operators are likely
   well as "kludges" to need the DNS, as risks to
   implement new forms the goal of monitoring.  In this case, they may desire to
   monitor for significant changes network
   transparency in the size of end-to-end model.  Some parties concerned with
   the whitelist within a
   certain period emerging use of time, DNS Whitelisting have shared similar concerns,
   which might be indicative of a technical
   error such as the entire ACL being removed.  Authoritative nameserver
   operators may also wish to monitor their workflow process for
   reviewing and acting upon DNS whitelisting applications and appeals,
   potentially measuring make [Tussle in Cyberspace] an interesting and reporting on service level commitments
   regarding relevant
   document.  In addition, [Rethinking the time an application or appeal can remain at each step Internet] reviews similar
   issues that may be of the process, regardless interest to readers of whether or not such information this document.

   Also, it is
   shared with parties other than somewhat possible that authoritative DNS server
   operator.

7.3.5.  Implications Whitelisting could affect some
   of Operational Momentum

   It seems plausible that once DNS whitelisting is implemented it will
   be very difficult to deprecate such technical and operational
   practices.  This assumption is based in an understanding the architectural assumptions which underlie parts of human
   nature, not Section 2 of
   [RFC4213] which outlines the dual stack approach to mention physics.  For example, the IPv6
   transition.  DNS Whitelisting could modify the behavior of the DNS,
   as Sir Issac Newton
   noted, "Every object described in a state Section 2.2 of uniform motion tends [RFC4213] and could require different
   sets of DNS servers to remain in be used for hosts that state are (using terms from
   that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes.
   As such, broad use of motion unless an external force DNS Whitelisting may necessitate the review
   and/or revision (though revision is applied unlikely to it" [Laws be neccessary) of Motion].  Thus, once DNS whitelisting is implemented it
   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 quite
   likely a critical to understand that it would take considerable effort to deprecate the
   practice and remove it everywhere on the Internet - it will otherwise
   simply remain concept of reachability
   described here depends upon a knowledge of an address in place the DNS.
   Thus, in perpetuity.  To better illustrate this order to establish reachability to an end point, one 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 consider one connect to an example (of many) server host
   using the IPv6 address, even though the FQDN associated with that there are many
   email
   server host is restricted via a DNS whitelist.  Since most Internet
   applications and hosts such as web servers continuing to attempt depend upon the DNS, and
   as end users connect to query FQDNs such as www.example.com and do not
   remember or otherwise check anti-
   spam DNS blocklists which have long ago ceased wish to exist.

7.3.6.  Troubleshooting Implications

   The implications of DNS whitelisted present many challenges, which
   have been detailed type in Section 7.  These challenges may negatively
   affect an IP address, the end users' ability to troubleshoot, as well as that notion of DNS
   recursive resolver operators, ISPs, content providers, domain owners
   (where they may reachability
   described here should be different from the operator understood to include knowledge of the authoritative
   DNS server for their domain), how to
   associate a name with a network address.

   The predominant experience of end user hosts and other third parties.  This may make servers on the process of determining why IPv4-
   addressed Internet today is that when a new server is not reachable
   significantly more complex.

7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis

   Additional implications, should this be deployed on an ad hoc basis,
   could include scalability problems relating with a public IPv4
   address is added to operational processes,
   monitoring, and ACL updates.  In particular, it seems likely that as
   the number of domains that are using DNS whitelisting increases, as
   well as the number of IPv6-capable networks requesting to be
   whitelisted, DNS, that there a FQDN is an increased likelihood of configuration
   and other operational errors, especially with respect to the ACLs
   themselves.

   It immediately useful for
   reaching it.  This is unclear when and if it would be appropriate to change from
   whitelisting to blacklisting, a generalization and whether or how in Section 5 there are
   examples of common cases where this could feasibly
   be coordinated across the Internet, which may not necessarily be proposed or
   implemented on an ad hoc basis when a majority the case.
   For the purposes of networks (or
   allocated IPv6 address blocks) have been whitelisted.  Finally, some
   parties implementing DNS whitelisting consider this to be a temporary
   measure.  As such, it argument, that concept of accessibility is not clear how these parties will judge
   described as "pervasive reachability".  It has so far been assumed
   that the
   network conditions to have changed sufficiently to justify disabling
   DNS whitelisting and/or what same expectations of pervasive reachability would exist in
   the process and timing IPv6-addressed Internet.  However, if DNS Whitelisting is
   deployed, this will not be in order
   to discontinue this practice.

   One further potential implication is that an the case since only end user with only an
   IPv4 address, hosts using a
   DNS resolver which has not been whitelisted by
   any domains, recursive resolvers that are included in the ACL of a given
   domain using DNS Whitelisting would not be able to get any AAAA resource records.  In
   such a case, this could give reach new servers in
   that given domain via IPv6 addresses.  The expectation of any end
   user the incorrect impression
   that there is no IPv6-based content on the Internet since they are
   unable host being able to connect to discover any IPv6 addresses via the DNS.

7.4.  Homogeneity May Be Encouraged

   A broad trend which has existed on server (essentially both
   hosts, just at either end of the Internet appears network), defined here as "pervasive
   reachability", will change to be a move
   towards increasing levels of heterogeneity.  One manifestation of
   this is "restricted reachability" with IPv6.

   Establishing DNS Whitelisting as an accepted practice in the early
   phases of mass IPv6 deployment could establish it as an increasing number, variety, and customization integral part
   of end
   user hosts, including home network, operating systems, client
   software, home network devices, and personal computing devices. how IPv6 DNS resource records are deployed globally.  This
   trend appears to have had a positive effect risks
   DNS Whitelisting living on the development and
   growth of the Internet.  A for decades as a key facet of this that has evolved is the
   ability foundational element
   of the end user to connect any technically compliant device
   or use any technically compatible software to connect to domain name management on the Internet.  Not only does this trend towards greater heterogeneity
   reduce

7.3.  Operational Implications

   This section explores some of the control operational implications which is exerted may
   occur as a result of, are related to, or become necessary when
   engaging in the middle of the network,
   described in positive terms in [Tussle in Cyberspace], [Rethinking
   the Internet], and [RFC3724], but it can also help to enable greater
   and more rapid innovation at the edges.

   An unfortunate implication of the adoption practice of DNS whitelisting may be
   the encouragement of a reversal of this trend, which would be a move
   back towards greater levels of homogeneity.  In this case, Whitelisting.

7.3.1.  De-Whitelisting May Occur

   It is possible for a domain
   owner which has implemented DNS whitelisting may prefer greater
   levels of control be exerted over end user hosts (which broadly
   includes all types of end user software and hardware) in order to
   attempt recursive resolver added to enforce technical standards relating a whitelist to establishing
   certain IPv6 capabilities or
   then be removed from the enforcing whitelist, also known as de-whitelisting.
   Since de-whitelisting can occur, through a decision by the elimination of or
   restriction of certain end user hosts.  While
   authoritative server operator, the domain operator is
   attempting to protect, maintain, and/or optimize the end user
   experience for their domain, the collective result of many domains
   implementing DNS whitelisting, owner, or even due to a few major domains (meaning
   domains which are a major destination
   technical error, an operator of Internet traffic)
   implementing a DNS whitelisting, recursive resolver will have
   new operational and monitoring requirements and/or needs as noted in
   Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.  One
   particular risk is that, especially when a high-traffic domain de-
   whitelists a large network, this may be cause a sudden and dramatic
   change to encourage networks since a return large volume of traffic will then switch
   from IPv6 to more
   homogenous and/or controlled end user hosts. IPv4.  This could can have
   unintended side dramatic effects on those being de-
   whitelisted as well as on other interconnected networks.  In some
   cases, IPv4 network links may rapidly become congested and counter-productive implications for
   future innovation at the edges users of
   affected networks will experience network access impairments well
   beyond the network.

7.5.  Technology Policy Implications

   A key technology policy implication concerns the policies relating to domain which performed the process de-whitelisting.  Thus, once
   "operational stability" has been achieved between a whitelisting and
   whitelisted party, then de-whitelisting should generally not occur
   except in cases of reviewing an application for DNS whitelisting, operational emergencies, and the
   decision-making process regarding whitelisting there should be
   opportunities for joint troubleshooting or at least for advance
   warning to affected parties.

7.3.2.  Authoritative DNS Server Operational Implications

   DNS Whitelisting serves as a domain.
   Important questions may include whether these policies have been
   fully critical infrastructure service; to be
   useful it needs careful and transparently disclosed, are non-discriminatory, extensive administration, monitoring and are
   not anti-competitive.  A related implication is whether
   operation.  Each new and what the
   process essential mechanism creates substantial
   follow-on support costs.

   Operators of authoritative servers (which are frequently
   authoritative for appeals is, when a multiple domain decides not names) will need to add maintain an ACL
   on a DNS
   recursive resolver to the whitelist.  Key questions here may include
   whether appeals are allowed, what the process is, what the expected
   turn around time is, server-wide basis affecting all domains, or on a domain-by-
   domain basis.  As a result, operational practices and whether the appeal will software
   capabilities may need to be handled by an
   independent third party or other entity/group.

   A further implications arises when de-whitelisting occurs.  Questions
   that developed in order to support such
   functionality.  In addition, processes may naturally need to be raised put in place to
   protect against inadvertently adding or removing IP addresses, as
   well as systems and/or processes to respond to such incidents if and
   when they occur.  For example, a case include whether the
   criteria for de-whitelisting system may be needed to record DNS
   Whitelisting requests, report on their status along a workflow, add
   IP addresses when whitelisting has been approved, remove IP addresses
   when they have been fully and transparently
   disclosed, are non-discriminatory, and are not anti-competitive.
   Additionally, de-whitelisted, log the question personnel involved and
   timing of whether or not there was a cure period
   available prior changes, schedule changes to de-whitelisting, during which troubleshooting
   activities, complaint response work, occur in the future, and corrective actions to
   roll back any inadvertent changes.

   Operators may be
   attempted, and whether this cure period was a reasonable amount also need implement new forms of
   time. monitoring in order to
   apply change control, as noted briefly in Section 7.3.4.

   It is also conceivable that whitelisting and de-whitelisting
   decisions could be quite sensitive to concerned parties beyond the
   operator important for operators of authoritative servers to recognize
   that the domain which has implemented DNS whitelisting operational burden is likely to increase dramatically over
   time, as more and more networks transition to IPv6.  As a result, the
   operator
   volume of the new DNS recursive resolver, including end users,
   application developers, content providers, advertisers, public policy
   groups, governments, and other entities, Whitelisting requests will increase over time,
   potentially at an extraordinary growth rate, which may also seek to
   become involved in or express opinions concerning whitelisting will place an
   increasing burden on personnel, systems, and/or
   de-whitelisting decisions.  Lastly, it is conceivable processes.  Operators
   should also consider that any of
   these interested parties or other related stakeholders may seek
   redress outside of supporting systems, including the process
   authoritative servers themselves, may experience reduced performance
   when a domain has establishing for DNS
   whitelisting and de-whitelisting.

   A final concern is that decisions relating to whitelisting and de-
   whitelisting may occur as an expression whitelist becomes quite large.

7.3.3.  DNS Recursive Resolver Server Operational Implications

   For operators of other commercial,
   governmental, and/or cultural conflicts, given the new control point
   which has be established DNS recursive resolvers, coping with DNS whitelisting.  For example,
   Whitelisting becomes expensive in one
   imagined scenario, a domain could withhold adding time and personnel as the practice
   scales up.  These operators include ISPs, enterprises, universities,
   governments; a network to their
   DNS whitelisting unless that network agreed to some sort wide range of financial
   payment, legal agreement, agreement to sever a relationship organization types with a
   competitor of the domain, etc.  In another example, a music-oriented
   domain may be engaged in some sort range of dispute with an academic
   network concerning copyright infringement concerns within that
   network, and may choose DNS-
   related expertise.  They will need to de-whitelist that network implement new forms of
   monitoring, as a negotiating
   technique noted briefly in some sort Section 7.3.4.  But more critically,
   such operators will need to add people, processes, and systems in
   order to manage large numbers of commercial discussion.  In a final example, DNS Whitelisting applications.
   Since there is no common method for determining whether or not a major email
   domain may choose is engaged in DNS Whitelisting, operators will have to de-whitelist apply
   to be whitelisted for a network due domain based upon one or more end user
   requests, which means systems, processes, and personnel for handling
   and responding to those requests will also be necessary.

   When operators apply for DNS Whitelisting for all domains, that
   network sending may
   mean doing so for all registered domains.  Thus, some large volume of spam, which system would
   have the
   effect of preventing other, end users on that network from using
   other, non-email-related applications within that domain.  Thus, it
   seems possible that DNS whitelisting and de-whitelisting could become
   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 developed to express a
   strong voice in such decisions.

7.6.  IPv6 Adoption Implications

   As noted discover whether each domain has been
   whitelisted or not, which is touched on in Section 4, the implications of DNS whitelisting 6 and may drive
   end users and/or networks to delay, postpone, or cancel adoption of
   IPv6, 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 actively seek alternatives develop
   processes and systems to it.  Such alternatives may
   include track the use status of multi-layer network address translation (NAT)
   techniques like NAT444 [I-D.shirasaki-nat444], which these parties
   may decide to pursue on a long-term basis all DNS Whitelisting
   applications, respond to avoid the perceived
   costs and aggravations requests for additional information related
   to DNS whitelisting.  This could of
   course come at the very time that the Internet community is trying to
   get these very same parties interested in IPv6 applications, determine when and motivated to begin if applications have been
   denied, manage appeals, and track any de-whitelisting actions.

   Given the transition to IPv6.  As large number of domains in existence, the ease with which a result, parties that are likely to
   new domain can be
   concerned over added, and the negative implications of DNS whitelisting could
   logically be concerned of continued strong growth in the negative effects that this practice
   could have on the adoption
   numbers of IPv6 if it became widespread or was
   adopted by majors Internet domains or other major parties in the
   Internet ecosystem.

   At new domains, readers should not underestimate the same time, as noted
   potential significance in Section 3, some highly-trafficked
   domains personnel and expense that this could
   represent for such operators.  In addition, it is likely that systems
   and personnel may find the prospect of transitioning also be needed to IPv6 daunting
   without having some short-term ability handle new end user requests for
   domains for which to incrementally control apply for DNS Whitelisting, and/or inquiries
   into the
   amount and source status of IPv6 traffic a whitelisting application, reports of de-
   whitelisting incidents, general inquiries related to their domains.

8.  Solutions

   This section outlines several possible solutions when considering DNS
   whitelisting
   Whitelisting, and associated IPv6-related issues.

8.1.  Implement requests for DNS Whitelisting Universally

   One obvious solution is to implement Whitelisting-related
   troubleshooting by these end users.

7.3.4.  Monitoring Implications

   Once a DNS recursive resolver has been whitelisted universally, and
   to do so using some sort of centralized registry for a particular
   domain, then the operator of that DNS whitelisting
   policies, contracts, processes, or other information.  This potential
   solution seems unlikely at recursive resolver may need to
   implement monitoring in order to detect the current time.

8.2.  Implement possible loss of DNS
   Whitelisting On An Ad Hoc Basis

   If DNS whitelisting is to be adopted, it is likely to be adopted on
   this ad hoc, or domain-by-domain basis.  Therefore, only those
   domains interested in the future.  This DNS whitelisting would need recursive resolver operator
   could configure a monitor to adopt check for a AAAA response in the
   practice, though
   whitelisted domain, as noted herein discovering that they a given domain
   has done 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 may be problematic.  Also that operations
   personnel could begin troubleshooting, as outlined in Section 7.3.6.

   Also, authoritative DNS server operators are likely to need to
   implement new forms of monitoring.  In this scenario, ad hoc use by
   a particular domain case, they may be a temporary measure that has been adopted desire to ease
   monitor for significant changes in the transition size of the domain to IPv6 over some short-term
   timeframe.

8.3.  Do Not Implement whitelist within a
   certain period of time, which might be indicative of a technical
   error such as the entire ACL being removed.  Authoritative DNS Whitelisting

   As an alternative server
   operators may also wish to adopting monitor their workflow process for
   reviewing and acting upon DNS whitelisting, Whitelisting applications and appeals,
   potentially measuring and reporting on service level commitments
   regarding the Internet
   community generally time an application or appeal can choose to take no action whatsoever,
   perpetuating remain at each step
   of the current predominant process, regardless of whether or not such information is
   shared with parties other than that authoritative DNS operational
   model on the Internet, and leave server
   operator.

7.3.5.  Implications of Operational Momentum

   It seems plausible that once DNS Whitelisting is implemented it up to end users with IPv6-related
   impairments will
   be very difficult to discover deprecate such technical and fix those impairments.

8.3.1.  Solving Current End User IPv6 Impairments

   A further extension operational
   practices.  This assumption is based on an understanding of human
   nature, not implementing DNS whitelisting, is to also
   endeavor mention physics.  For example, as Sir Isaac Newton
   noted, "Every object in a state of uniform motion tends to actually fix the underlying technical problems remain in
   that have
   prompted the consideration state of DNS whitelisting in the first place, as motion unless an alternative to trying to apply temporary workarounds external force is applied to avoid the
   symptoms it" [Laws
   of underlying end user IPv6 impairments.  A first step Motion].  Thus, once DNS Whitelisting is
   obviously to identify which users have such impairments, which implemented it is quite
   likely that it would
   appear take considerable effort to be possible, deprecate the
   practice and then to communicate remove it everywhere on the Internet; it may otherwise
   simply remain in place in perpetuity.  To illustrate this information point, one
   could consider for example that there are many email servers
   continuing to
   end users.  Such end user communication is likely attempt to be most helpful
   if the end user is not only alerted query anti-spam DNS blocklists which have
   long ago ceased to a potential problem but is
   given careful and exist.

7.3.6.  Troubleshooting Implications

   The implications of DNS whitelisted present many challenges, as
   detailed advice on how throughout Section 7.  These challenges may negatively
   affect the end users' ability to resolve this on their
   own, or where troubleshoot, as well as that of DNS
   recursive resolver operators, ISPs, content providers, domain owners
   (where they can seek help in doing so.  Section 11 may also be
   relevant in this case.

   One challenge with this option is different from the potential difficulty of
   motivating members operator of the Internet community to work collectively
   towards this goal, sharing the labor, time, and costs related to such
   an effort.  Of course, since just such a community effort is now
   underway for IPv6, it is possible that this would call authoritative
   DNS server for only a
   moderate amount of additional work.

   Despite any potential challenges, many in their domain), and other third parties.  This may make
   the Internet community are
   already working towards this goal and/or have expressed process of determining why a general
   preference for this approach.

8.3.2.  Gain Experience Using IPv6 Transition Names

   Another alternative server is for domains to gain experience using an not reachable via a FQDN
   which has become common for
   significantly more complex and time-consuming.

7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis

   As more domains beginning the transition choose to IPv6;
   ipv6.example.com implement DNS Whitelisting, and www.ipv6.example.com.  This can be a way for a
   domain more
   networks become IPv6-capable and request to gain IPv6 experience be whitelisted, scaling
   up operational processes, monitoring, and ACL updates will become
   more difficult.  The increased rate of change and increased size of
   whitelists will increase IPv6 use on a relatively
   controlled basis, the likelihood of configuration and other
   operational errors.

   It is unclear when and if it would be appropriate to inform any plans for DNS whitelisting with
   experience.

9.  Is DNS Whitelisting a Recommended Practice?

   Opinions in the Internet community concerning whether or not DNS change from
   whitelisting is a recommended practice are understandably quite
   varied.  However, there to blacklisting.  It is clear consensus that DNS whitelisting trying to coordinate
   this across the Internet is
   at best likely be be impossible, so such a useful temporary measure which change
   to blacklisting would happen on a domain may choose domain-by-domain basis (if at all).

   Finally, some implementers consider DNS Whitelisting to
   pursue as they prepare for be a
   temporary measure.  As such, it is not clear how these implementers
   will judge the transition network conditions to IPv6.  In particular,
   some major domains view have changed sufficiently to
   justify disabling DNS whitelisting as one of Whitelisting (or Blacklisting, or other AAAA
   resource record access controls) and/or what the few practical process and low risk approaches enabling them to prepare for the transition timing
   will be in order to IPv6.  Thus, DNS whitelisting discontinue this practice.

   One further implication is not that an end user with only an IPv4
   address, using a recommended practice over
   the long-term.  In addition, DNS whitelisting should resolver which has not been whitelisted by any
   domains, would not be avoided
   wherever possible in able to get any AAAA resource records.  In such
   a case, this could give that end user the short-term and its use incorrect impression that
   there is generally
   discouraged.  Nevertheless, major domains may find DNS whitelisting a
   beneficial temporary tactic in their transition to IPv6.  Such
   temporary use during no IPv6-based content on the transition Internet since they are unable
   to discover any IPv6 is broadly accepted
   within addresses via the community, so long as it does not become a long-term
   practice.

   World IPv6 Day, sponsored by DNS.

7.4.  Homogeneity May Be Encouraged

   A broad trend on the Internet Society [World IPv6 Day], 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, move toward more heterogeneity.
   One manifestation of this is likely in an excellent opportunity
   for domains to evaluate the utility or necessity increasing number, variety, and
   customization 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 end user hosts, including home networks, operating
   systems, client software, home network devices, and measured any errors [Heise Online
   Experiment], which is important reading for any domain contemplating
   either personal
   computing devices.  This trend appears to have had a positive effect
   on the use development and growth of DNS whitelisting the Internet.  This trend has
   enabled end user to connect any technically compliant device or simply adding IPv6 addressing use
   any technically compatible software to their site.

10.  Security Considerations

   There are no particular security considerations if DNS whitelisting
   is not adopted, as connect to the Internet.  Not
   only does this is how trend towards greater heterogeneity reduce the public Internet works today with A
   resource records.

   However, if DNS whitelisting is adopted, organizations control
   which apply
   DNS whitelisting policies is exerted in their authoritative servers should have
   procedures the middle of the network, described positively
   in [Tussle in Cyberspace], [Rethinking the Internet], and systems which do not allow unauthorized parties [RFC3724],
   but it also appears to
   either remove whitelisted DNS resolvers from the whitelist or add
   non-whitelisted DNS resolvers help to enable greater and more rapid
   innovation at the whitelist.  Should such
   unauthorized additions or removals from edges.

   Some forms of so-called "network neutrality" principles around the whitelist can
   world include the notion that any IP-capable device should be quite
   damaging, and result in content providers and/or ISPs able to incur
   substantial support costs resulting from end user and/or customer
   contacts.  As such, great care must be taken
   connect to control access a network, which seems to the
   whitelist for an authoritative server.

   In addition, two other key security-related issues should encourage heterogeneity.  These
   principles are often explicitly encouraged by application providers
   given the reasons noted above, though some of these same providers
   may also be taken
   into consideration:

10.1.  DNSSEC Considerations

   DNS security extensions defined in [RFC4033], [RFC4034], and
   [RFC4035] use cryptographic digital signatures to provide origin
   authentication and integrity assurance for implementing DNS data. Whitelisting.  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 ironic, as one
   implication of the answers.  Since adoption of DNS whitelisting Whitelisting is implemented on an
   authoritative server, which provides different answers depending upon
   which resolver server has sent that in encourages
   a query, the DNSSEC chain of trust move back towards homogeneity.  This is
   not altered.  Even though the authoritative server will not always
   return because some implementers
   have expressed 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 preference for greater levels of that
   same domain.  Specifically, those domains should ensure that resource
   records are being appropriately and reliably signed, which may
   present incremental operational and/or technical challenges.

   However, as noted in Section 3, control by networks
   over end user networks may also choose to
   implement tools at their disposal hosts in order to address attempt to enforce technical
   requirements intended to reduce IPv6-related impairments.  One  This
   return to an environment of those possible tools could involve unspecified
   changes to the configuration of their recursive resolvers.  If it is
   a Security-Aware Resolver, modifying or suppressing AAAA resource
   records for a DNSSEC-signed domain will be problematic and more homogenous and/or controlled end
   user hosts could
   break have unintended side effects on and counter-
   productive implications for future innovation at the chain edges of trust established with DNSSEC.

10.2.  Authoritative DNS Response Consistency Considerations

   In addition to the considerations raised in Section 10.1, it is
   conceivable that security
   network.

7.5.  Technology Policy Implications

   A key technology policy implication 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 policies relating to concerns that, since
   the
   authoritative responses vary that there is some sort of security
   issue and/or some or none process of reviewing an application for DNS Whitelisting, and the responses can be trusted.  While
   this may seem
   decision-making process regarding whitelisting for a somewhat obscure concern, domains nonetheless domain.
   Important questions may
   wish to consider this when contemplating include whether or these policies have been
   fully and transparently disclosed, are non-discriminatory, and are
   not to pursue DNS
   whitelisting.

11.  Privacy Considerations

   As noted in Section 8.3.1, there may be methods to detect IPv6- anti-competitive.  A related impairments implication is whether and what the
   process for a particular end user.  For example, this may
   be possible appeals is, when an end user visits the website of a particular
   domain.  In that example, there are likely no privacy considerations
   in communicating to that end user that the domain has detected a
   particular impairment.  However, if that domain decided decides against adding a DNS
   recursive resolver to share
   information concerning that particular end user with their network
   operator or another party, then the visited domain whitelist.  Key questions here may wish to in
   some manner advise include
   whether appeals are allowed, what the end user of this process is, what the expected
   turn around time is, and whether the appeal will be handled by an
   independent third party or otherwise seek their
   consent to such information sharing.  This other entity/group.

   Further implications arise when de-whitelisting occurs.  Questions
   that may naturally be achieved raised in such a wide
   variety of ways, from presenting a message asking case include whether the user
   criteria for
   consent (which will de-whitelisting have been fully and transparently
   disclosed, are non-discriminatory, and are not anti-competitive.
   Additionally, the question of course help them solve whether or not there was a technical problem of
   which they are likely unaware) cure period
   available prior to adding de-whitelisting, during which troubleshooting
   activities, complaint response work, and corrective actions may be
   attempted, and whether this to cure period was a domain's website
   terms reasonable amount of use / service.  Such information sharing
   time.

   It is also conceivable that whitelisting and communication
   of such sharing de-whitelisting
   decisions could be quite sensitive to concerned parties beyond the
   operator of the domain which has implemented DNS Whitelisting and the
   operator of the DNS recursive resolver, including end users users,
   application developers, content providers, advertisers, public policy
   groups, governments, and other entities, which may well vary by geographic area also seek to
   become involved in or express opinions concerning whitelisting and/or
   legal jurisdiction.  Thus, a domain should consider
   de-whitelisting decisions.  Lastly, it is conceivable that any potential
   privacy issues of
   these sorts interested parties or other related stakeholders may seek
   redress outside of scenarios.

12.  IANA Considerations

   There are no IANA considerations in this document.

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

   The author process a domain has establishing for DNS
   Whitelisting and contributors also wish de-whitelisting.

   A final concern is that decisions relating to acknowledge the assistance
   of the following individuals.  Some of these people provided helpful whitelisting and important guidance in the development de-
   whitelisting may occur as an expression of this document other commercial,
   governmental, and/or in cultural conflicts, given the development new control point
   which has been established with DNS Whitelisting.  For example, in
   one imagined scenario, a domain could withhold adding a network to
   their DNS Whitelisting unless that network agreed to some sort of
   financial payment, legal agreement, agreement to sever a relationship
   with a competitor of the concepts covered in this document.  Other
   people assisted by performing domain, etc.  In another example, a detailed review music-
   oriented domain may be engaged in some sort of this document, and
   then providing feedback dispute with an
   academic network concerning copyright infringement concerns within
   that network, and constructive criticism for revisions may choose to
   this document.  All de-whitelist that network as a
   negotiating technique in some sort of this was helpful and therefore the following
   individuals merit acknowledgement:

   - Bernard Aboba

   - Frank Bulk

   - Brian Carpenter

   - Karsten Fleischhauer

   - Wesley George
   - Jerry Huang

   - Joel Jaeggli

   - Erik Kline

   - Suresh Krishnan

   - Victor Kuarsingh

   - Danny McPherson

   - Martin Millnert

   - Thomas Narten

   - Hannes Tschofenig

   - Tina Tsou

15.  References

15.1.  Normative References

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

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

   [RFC2956]  Kaat, M., "Overview commercial discussion.  In a
   final example, a major email domain may choose to de-whitelist a
   network due to that network sending some large volume of 1999 IAB Network Layer Workshop",
              RFC 2956, October 2000.

   [RFC3234]  Carpenter, B. spam.  Thus,
   it seems possible that DNS Whitelisting and S. Brim, "Middleboxes: Taxonomy de-whitelisting could
   become a vehicle for adjudicating other disputes, and
              Issues", RFC 3234, February 2002.

   [RFC3724]  Kempf, J., Austein, R., that this may
   well have intended and IAB, "The Rise of the Middle unintended consequences for end users which
   are affected by such decisions and are unlikely to be able to express
   a strong voice in such decisions.

7.6.  IPv6 Adoption Implications

   As noted in Section 4, the Future implications of End-to-End: Reflections on the Evolution DNS Whitelisting may drive
   end users and/or networks to delay, postpone, or cancel adoption of
   IPv6, or to actively seek alternatives to it.  Such alternatives may
   include the 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 use of multi-layer network address translation (NAT)
   techniques like NAT444 [I-D.shirasaki-nat444], which these parties
   may decide to pursue on a long-term basis to avoid the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., perceived
   costs and S.
              Rose, "Protocol Modifications for the aggravations related to 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.  Informative References

   [Evaluating Whitelisting.  This could of
   course come at the very time that the Internet community is trying to
   get these very same parties interested in IPv6 Adoption]
              Colitti, L., Gunderson, S., Kline, E., and T. Refice,
              "Evaluating IPv6 motivated to begin
   the transition to IPv6.  As a result, parties that are likely to be
   concerned over the negative implications of DNS Whitelisting could
   logically be concerned of the negative effects that this practice
   could have on the adoption of IPv6 if it became widespread or was
   adopted by majors Internet domains or other major parties in the Internet", Passive
   Internet ecosystem.

   At the same time, as noted in Section 3, some high-traffic domains
   may find the prospect of transitioning to IPv6 daunting without
   having some short-term ability to incrementally control the amount
   and
              Active Management (PAM) Conference 2010, April 2010,
              <http://www.google.com/research/pubs/archive/36240.pdf>.

   [Heise Online Experiment]
              Heise.de, "World source of IPv6 Day - June 8, 2011", Heise.de
              Website http://www.h-online.com, January 2011, <http://
              www.h-online.com/features/
              The-big-IPv6-experiment-1165042.html>.

   [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 traffic to their domains.  Lacking such controls,
   some domains may choose to substantially delay their 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 to
   IPv6.

7.7.  Implications with Poor IPv4 and Combating IPv6 Brokenness",
              Reseaux IP Europeens (RIPE) 61st Meeting, November 2011,
              <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.

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

   [Laws of Motion]
              Newton, I., "Mathematical Principles Transport

   It is possible that there could be situations where the differing
   quality of Natural Philosophy
              (Philosophiae Naturalis Principia Mathematica)",
              Principia Mathematical Principles the IPv4 and IPv6 connectivity 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 an end user could cause
   complications in talks accessing content which is in a whitelisted domain,
   when the end user's DNS recursive resolver is not on that whitelist.
   While today most end users' IPv4 connectivity is typically superior
   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., connectivity (if such connectivity exists at all), there
   could be implications when the reverse is true and L. Esibov, "A DNS RR for
              specifying and end user has
   markedly superior IPv6 connectivity as compared to IPv4.  This is
   admittedly theoretical but could become a factor as the transition to
   IPv6 continues and IPv4 address availability within networks becomes
   strained.

   For example, in one possible scenario, a user is issued IPv6
   addresses by their ISP and has a home network and devices or
   operating systems which fully support IPv6.  As a result this
   theoretical user has very good IPv6 connectivity.  However, this end
   user's ISP may have exhausted their available pool of unique IPv4
   address, and so that ISP uses NAT in order to reuse IPv4 addresses.
   So for IPv4 content, the end user must send their IPv4 traffic
   through some additional network element (e.g.  NAT, proxy, tunnel
   server).  Use of this additional network element may cause the end
   user to experience sub-optimal IPv4 connectivity when certain
   protocols or applications are used.  This user then has good IPv6
   connectivity but impaired IPv4 connectivity.  Furthermore, this end
   user's DNS recursive resolver is not whitelisted by the authoritative
   server for a domain that the user is trying to access, meaning the
   end user only gets A record responses for their impaired IPv4
   transport rather than also AAAA record responses for their stable and
   well-performing IPv6 transport.  Thus, the user's poor IPv4
   connectivity situation is potentially exacerbated by not having
   access to a given domain's IPv6 content since they must use the
   address family with relatively poor performance.

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

   In most cases it is assumed that end users will make use of DNS
   recursive resolvers which are operated by their network provider,
   whether that is an ISP, campus network, enterprise network, or some
   other type of access network.  However there are also cases where an
   end user has changed their DNS server IP addresses in their device's
   operating system to those of another party which operates DNS
   recursive resolvers independently of end user access networks.  In
   these cases, an authoritative DNS server may receive a query from a
   DNS recursive resolver in one network, though the end user sending
   the original query to the DNS recursive resolver is in an entirely
   different network.  It may therefore be more challenging for a DNS
   whitelist implementer to determine the level of IPv6-related
   impairment when such third-party DNS recursive resolvers are used,
   given the wide variety of end user access networks which may be used
   and that this mix may change in unpredictable ways over time.

   There may also be cases where end users are using a network where the
   assigned DNS recursive resolver has not been whitelisted by a
   particular authoritative DNS server, but where the end user knows
   that a particular third-party DNS recursive resolver has been
   whitelisted.  While in most cases the end user will be able to switch
   to use that third-party's servers, some access networks may prevent
   switching to any DNS recursive resolvers other than those authorized
   by or residing within a given access network.  While the blocking of
   third-party DNS recursive resolvers may be observed in many types of
   networks such as ISPs, campus networks, and enterprise networks, this
   may most often be observed in the specialized networks setup in
   hotels, conference centers, coffee shops, and similar access
   networks.  In these cases, end users may be frustrated at their
   inability to access content over IPv6 as a result of their access
   network preventing them from using a whitelisted third-party DNS
   recursive resolver.  This may also result in complaints to both the
   operator of the authoritative DNS server which has implemented
   whitelisting as well as to the access network operator.

8.  General Implementation Variations

   This section outlines several possible approaches which may be
   followed when considering DNS Whitelisting and associated IPv6-
   related issues.

8.1.  Implement DNS Whitelisting Universally

   One obvious approach is to implement DNS whitelisted universally, and
   to do so using some sort of centralized registry of DNS Whitelisting
   policies, contracts, processes, or other information.  Such an
   approach is also considered harmful and problematic, and almost
   certain not 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 interested in DNS
   Whitelisting would need to adopt the practice, though 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 may be a
   temporary measure that has been adopted to ease the transition of the
   domain to IPv6 over some short-term timeframe.

8.3.  Do Not Implement DNS Whitelisting

   As an alternative to adopting DNS Whitelisting, the Internet
   community generally can choose not to implement DNS Whitelisting,
   perpetuating the current predominant authoritative DNS operational
   model on the Internet.  As a result is is then up to end users with
   IPv6-related impairments to discover and fix those impairments,
   though clearly other parties including end user host operating system
   developers can play a critical role [I-D.ietf-v6ops-happy-eyeballs].

8.3.1.  Solve Current End User IPv6 Impairments

   A further extension of not implementing DNS Whitelisting, is to also
   endeavor to actually fix the underlying technical problems that have
   prompted the consideration of DNS Whitelisting in the first place, as
   an alternative to trying to apply temporary workarounds to avoid the
   symptoms of underlying end user IPv6 impairments.  A first step is
   obviously to identify which users have such impairments, which would
   appear to be possible, and then to communicate this information to
   end users.  Such end user communication is likely to be most helpful
   if the end user is not only alerted to a potential problem but is
   given careful and detailed advice on how to resolve this on their
   own, or where they can seek help in doing so.  Section 11 may also be
   relevant in this case.

   One challenge with this option is the potential difficulty of
   motivating members of the Internet community to work collectively
   towards this goal, sharing the labor, time, and costs related to such
   an effort.  Of course, since just such a community effort is now
   underway for IPv6, it is possible that this would call for only a
   moderate amount of additional work [World IPv6 Day].

   Despite any potential challenges, many in 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 to gain experience using an FQDN
   which has become common for domains beginning the transition to IPv6;
   ipv6.example.com and www.ipv6.example.com.  This can be a way for a
   domain to gain IPv6 experience and increase IPv6 use on a relatively
   controlled basis, and to inform any plans for DNS Whitelisting with
   experience.  While this is a good first step to functionally test and
   prepare a domain for IPv6, the utility of the tactic is limited since
   users must know the transition name, the traffic volume will be low,
   and the traffic is unlikely to be representative of the general
   population of end users, among other reasons.

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 some level of control
   over returning AAAA record responses Section 8.3.  An alternative in
   this case may be to employ DNS blacklisting, which would enable all
   DNS recursive resolvers to receive AAAA record responses except for
   the relatively small number that are listed in the blacklist.  This
   could enable an implementer to only prevent such responses where
   there has been a relatively high level of IPv6-related impairments,
   until such time as these impairments can be fixed or otherwise
   meaningfully reduced to an acceptable level.

   This approach is likely to be significantly less labor intensive for
   an authoritative DNS server operator, as they would presumably focus
   on a smaller number of DNS recursive resolvers than if they
   implemented whitelisting.  Thus, these authoritative DNS server
   operators would only need to communicate with a few DNS recursive
   resolver operators rather than potentially all such operators.  This
   should result in lower labor, systems, and process requirements,
   which should be beneficial to all parties.  This is not to say that
   there will be no time required to work with those operators affected
   by a blacklist, simply that there are likely to be fewer such
   interactions and that each such interaction may be shorter in
   duration.

   Of course one downside of this approach may be that the perception of
   being blocked (blacklisted) is sometimes worse that not being
   permitted 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 to
   discover if a server is on a blacklist, if there is a transparent and
   easily understood process for requesting removal from a blacklist,
   and if the decision-making criteria for placing a server on a
   blacklist is transparently disclosed and perceived as fair.

9.  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 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 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 [World IPv6 Day],
   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 Online
   Experiment], which is important reading for any domain contemplating
   either the use of DNS Whitelisting or simply adding IPv6 addressing
   to their site.

10.  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 resolvers from the whitelist or add
   non-whitelisted DNS 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.  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 server, which provides different answers depending upon
   which resolver server has sent a query, the DNSSEC chain of trust is
   not altered.  Even though the authoritative 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 incremental operational and/or technical challenges.

   However, as noted in Section 3, 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 Security-Aware Resolver, modifying or suppressing AAAA resource
   records for a DNSSEC-signed domain will be problematic and could
   break the chain of trust established with DNSSEC.

10.2.  Authoritative DNS Response Consistency Considerations

   In addition to the considerations raised in Section 10.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.  Privacy Considerations

   As noted in Section 8.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.  IANA Considerations

   There are no IANA considerations in this document.

13.  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.  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.  All of this was helpful and
   therefore the following individuals merit acknowledgement:

   - Bernard Aboba

   - Jari Arkko

   - Frank Bulk

   - Brian Carpenter

   - Dave Crocker

   - Ralph Droms

   - Wesley Eddy

   - 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

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

15.1.  Normative References

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

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

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

   [Evaluating IPv6 Adoption]
              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>.

   [Heise Online Experiment]
              Heise.de, "World IPv6 Day - June 8, 2011", 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 Whitelist Operations]
              Kline, E., "IPv6 Whitelist Operations", Google Google IPv6
              Implementors Conference, June 2010, <http://
              sites.google.com/site/ipv6implementors/2010/agenda/
              IPv6_Whitelist_Operations.pdf>.

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

   [Resolvers in the Wild]
              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>.

   [Rethinking the Internet]
              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 in Cyberspace]
              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>.

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

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

Appendix A.  Document Change Log

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

   -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", as well as changes to improve the
   understanding of sentences in Sections 2, 3, 4, and 8.2.  Per Adrian
   Farrel, made a minor change to Section 3.  Per Robert Sparks, to make
   clear in Section 2 that whitelisting is done on authoritative servers
   and not DNS recursive resolvers, and to improve Section 8.3 and add a
   reference to I-D.ietf?v6ops?happy?eyeballs.  Per Wesley Eddy, updated
   Section 7.3.2 to address operational concerns and re-titled Section 8
   from "Solutions" to "General Implementation Variations".  Per Stephen
   Farrell, added text to Section 8.1 and Section 6.2, with a reference
   to 8.1 in the Introduction, to say that universal deployment is
   considered harmful.  Added text to Section 2 per the v6ops list
   discussion to indicate that whitelisting is independent of the IP
   address family of the end user host or resolver.  There was also
   discussion with the IESG to change the name of the draft to IPv6 DNS
   Resolver Whitelisting or IPv6 AAAA DNS Resolver Whitelisting (as
   suggested originally by John Mann) but there was not a strong
   consensus to do so.  Added a new section 7.7, at the suggestion of
   Philip Homburg.  Per Joe Touch, added a new Section 8.4 on
   blacklisting as an alternative, mentioned blacklisting in Section 2,
   added a new Section 7.8 on the use of 3rd party resolvers, and
   updated section 6.2 to change Internet Draft documents to RFCs.
   Minor changes from Barbara Stark.  Changes to the Privacy
   Considerations section based on feedback from Alissa Cooper.  Changed
   "highly-trafficked" domains to "high-traffic" domains.  Per Bernard
   Aboba, added text noting that a whitelist may be manually or
   automatically updated, contrasting whitelisting with blacklisting,
   reorganized Section 3, added a note on multiple clearinghouses being
   possible.  Per Pekka Savola, added a note regarding multiple
   clearinghouses to the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [Resolvers Ad Hoc section, corrected grammar in Section
   7.5, reworded Section 7.3.7, corrected the Wild]
              Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig,
              "Comparing DNS Resolvers year in a RIPE reference
   citation.  Also incorporated general feedback from the Wild", ACM Sigcomm Broadband
   Internet Measurement Conference 2010, November 2010,
              <http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.

   [Rethinking Technical Advisory Group.  Per Jari Arkko, simplified the Internet]
              Blumenthal, M. and D. Clark, "Rethinking
   introduction to the design 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
              Internet: The end 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 end arguments vs. the brave new
              world", ACM Transactions De-Whitelisting implications section regarding
   effects 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 in Cyberspace]
              Braden, R., Clark, D., Sollins, K., and J. Wroclawski,
              "Tussle in Cyberspace: Defining Tomorrow's Internet",
              Proceedings networks of ACM Sigcomm 2002, August 2002, <http://
              groups.csail.mit.edu/ana/Publications/PubPDFs/
              Tussle2002.pdf>.

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

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

Appendix A.  Document Change Log

   [RFC Editor: This section 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 be removed before publication] list.

   -03: Several changes suggested by Joel Jaeggli at the end of WGLC.
   This involved swapping the order of Section 6.1 and 6.2, among other
   changes to make the document more readable, understandable, and
   tonally balanced.  As suggested by Karsten Fleischhauer, added a
   reference to RFC 4213 in Section 7.1, as well as other suggestions to
   that section.  As suggested by Tina Tsou, made some changes to the
   DNSSEC section regarding signing.  As suggested by Suresh Krishnan,
   made several changes to improve various sections of the document,
   such as adding an alternative concerning the use of ipv6.domain,
   improving the system logic section, and shortening the reference
   titles.  As suggested by Thomas Narten, added some text regarding the
   imperfection of making judgements as to end user host impairments
   based upon the DNS recursive resolver's IP and/or network.  Finally,
   made sure that variations in the use of 'records' and 'resource
   records' was updated to 'resource records' for uniformity and to
   avoid confusion.

   -02: Called for and closed out feedback on dnsop and v6ops mailing
   lists.  Closed out open feedback items from IETF 79.  Cleared I-D
   nits issues, added a section on whether or not this is recommended,
   made language less company-specific based on feedback from Martin
   Millnert, Wes George, and Victor Kuarsingh.  Also mentioned World
   IPv6 Day per Wes George's suggestion.  Added references to the ISOC
   World IPv6 Day and the Heise.de test at the suggestion of Jerry
   Huang, as well as an additional implication in 7.3.7.  Made any
   speculation on IPv4 impairment noted explicitly as such, per feedback
   from Martin Millnert.  Added a reference to DNS SRV in the load
   balancing section.  Added various other references.  Numerous changes
   suggested by John Brzozowski in several sections, to clean up the
   document.  Moved up the section on why whitelisting is performed to
   make the document flow more logically.  Added a note in the ad hoc
   deployment scenario explaining that a deployment may be temporary,
   and including more of the perceived benefits of this tactic.  Added a
   Privacy Considerations section to address end-user detection and
   communication.

   -01: Incorporated feedback received from Brian Carpenter (from 10/19/
   2010), Frank Bulk (from 11/8/2010), and Erik Kline (from 10/1/2010).
   Also added an informative reference at the suggestion of Wes George
   (from from 10/22/2010).  Closed out numerous editorial notes, and
   made a variety of other changes.

   -00: First version published as a v6ops WG draft.  The preceding
   individual draft was
   draft-livingood-dns-whitelisting-implications-01.  IMPORTANT TO NOTE
   that no changes have been made yet based on WG and list feedback.
   These are in queue for a -01 update.

Appendix B.  Open Issues

   [RFC Editor: This section is to be removed before publication]
   1.  RFC Editor: Please consider shortening the names of the non-RFC
       references.

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

   3.  JD Falk question - should I add a sub-section to 9 to explain how
       best to implement if you did it? (transparent/published policies,
       SLA on decision making,etc.)

   4.  Per Ray Hunter - "Which is why my original posting suggested that
       the WG might wish to express a concern about anyone making
       assumptions about any undocumented architectural links between
       DNS and transport, and also suggest that operators of aaaa
       whitelists (party X) should disclose their aaaa methodology and
       data, 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 was happening and why, and also have a chance of
       correcting it."

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

   6.  Per Dave Crocker, this is a bit long-winded and should be edited
       down - in particular removing mentions of 'parties' in various
       parts ("I suggest merely noting that there are concerns and then
       listing and discussing the concerns, rather than adding text to
       attribute the concerns to others, even if the conclusion of your
       text is that 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 the believers.  It is about
       possible problems.").  John Leslie concurs - feels it should be
       simplified.

   7.  Per Pekka Savola and Stephen Farrell, should universal deployment
       be removed completely (consider after -04).

   8.  Per Jari Arkko, review the document again after -04 to ensure the
       right tone and that all motivations are properly accounted for.

   9.  Per Dave Crocker - do we need to change the name from
       whitelisting to 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 the document "IPv6 DNS resolver whitelisting"
       and revising the terminology throughout to match.  Mark Andrews
       also suggests "DNS resolver whitelisting for AAAA resolution".
       John Leslie suggests "AAAA-blocking".

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