One document matched: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- References are listed here so that they can be called via Entity attributes later -->
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC1958 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1958.xml">
<!ENTITY RFC2775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2775.xml">
<!ENTITY RFC2956 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2956.xml">
<!ENTITY RFC3234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3234.xml">
<!ENTITY RFC3724 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3724.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- PROCESSING INSTRUCTIONS - GENERAL -->
<!-- EACH ONE STARTS WITH '?' BELOW -->
<!-- give errors on I-D nits and perform DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc strict='yes' ?>
<?rfc toc='yes'?>
<!-- generate a ToC -->
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth='4'?>
<!-- END GENERAL PROCESSING -->
<!-- PROCESSING INSTRUCTIONS - CONTROL OF REFERENCES -->
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs='yes'?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space -->
<?rfc sortrefs='yes' ?>
<!-- do not start each main section on a new page -->
<?rfc compact='yes' ?>
<!-- keep one blank line between list items -->
<?rfc subcompact='no' ?>
<!-- END REFERENCE PROCESSING -->
<rfc ipr='pre5378Trust200902' docName='draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01' category='info'>
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3978, noModification3978, noDerivatives3978
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- FRONT SECTION -->
<front>
<title abbrev='IPv6 AAAA DNS Whitelisting Implications'>
IPv6 AAAA DNS Whitelisting Implications
</title>
<!-- add role='editor' attribute to author tag below for the editors if appropriate -->
<author initials='J.' surname='Livingood' fullname='Jason Livingood'>
<organization abbrev='Comcast'>
Comcast Cable Communications
</organization>
<address>
<postal>
<street>One Comcast Center</street>
<street>1701 John F. Kennedy Boulevard</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>US</country>
</postal>
<email>jason_livingood@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
<!-- author role='editor' is an optional value here -->
</author>
<date day='25' month='January' year='2011'/>
<!-- META-DATA DECLARATIONS -->
<area>Operations and Management Area</area>
<!-- WG name at the upperleft corner of the doc; 'Internet Engineering Task Force' is fine for individual submissions. -->
<workgroup>IPv6 Operations</workgroup>
<abstract>
<t>The objective of this document is to describe what whitelisting of DNS AAAA resource records is, or DNS whitelisting for short, as well as what the implications of this emerging practice are and what alternatives may exist. The audience for this document is the Internet community generally, including the IETF and IPv6 implementers.</t>
</abstract>
<!-- END META-DATA DECLARATIONS -->
</front>
<!-- END FRONT SECTION -->
<!-- MIDDLE SECTION -->
<middle>
<section anchor='intro' title='Introduction' anchor='Introduction' toc='include'>
<t>This document describes the emerging practice of whitelisting of DNS AAAA resource records (RRs), or DNS whitelisting for short. It also explores the implications of this emerging practice are and what alternatives may exist.</t>
<t>The practice of DNS whitelisting appears to have first been used by major web content sites, such as Google's various websites. These web site operators, or domain operators, observed that when they added AAAA RRs to their authoritative DNS servers that a small fraction of end users had slow or otherwise impaired access to a given web site with both AAAA and A RRs. The fraction of users with such impaired access has been estimated to be roughly 0.078% of total Internet users <xref target='IETF 77 DNSOP WG Presentation'/> <xref target='Network World Article on IETF 77 DNSOP WG Presentation'/>. Thus, in an example Internet Service Provider (ISP) network of 10 million users, approximately 7,800 of those users may experience such impaired access.</t>
<t>As a result of this impairment affecting end users of a given domain, a few large domains have begun to either implement DNS whitelisting or strongly consider the implementation of DNS whitelisting <xref target='Network World Article on DNS Whitelisting'/> <xref target='IPv6 Whitelist Operations'/>. When implemented, DNS whitelisting in practice means that a domain's authoritative DNS will return a AAAA RR to DNS recursive resolvers <xref target='RFC1035'/> on the whitelist, while returning no AAAA RRs to DNS resolvers which are not on the whitelist. It is important to note that these web site operators are motivated to maintain a high-quality user experience for all of their users, and that they are attempting to shield users with impaired access from the symptoms of these impairments that would negatively affect their access to certain websites and related Internet resources.</t>
<t>However, critics of this emerging practice of DNS whitelisting have articulated several concerns. Among these are that this is a very different behavior from the current practice concerning the publishing of IPv4 address records, that it may create a two-tiered Internet, that policies concerning whitelisting and de-whitelisting are opaque, that DNS whitelisting reduces interest in the deployment of IPv6, that new operational and management burdens are created, and that the costs and negative implications of DNS whitelisting outweigh the perceived benefits as compared to fixing underlying impairments.</t>
<t>This document explores the reasons and motivations for DNS whitelisting. It also explores the concerns regarding this emerging practice. As a result, readers can hopefully better understand what DNS whitelisting is, why some parties are implementing it, and why other parties are critical of the practice.</t>
</section>
<section title='How DNS Whitelisting Works' anchor='How DNS Whitelisting Works' toc='include'>
<t>DNS whitelisting is implemented in authoritative DNS servers, where those servers implement IP address-based restrictions on AAAA query responses, which contain IPv6 addresses. In practice DNS whitelisting has been primarily implemented by web server operators. For a given operator of the website www.example.com, that operator essentially applies an access control list (ACL) on their authoritative DNS servers, which are authoritative for the domain example.com. The ACL is then configured with the IPv4 and/or IPv6 addresses of DNS recursive resolvers on the Internet, which have been authorized to be added to the ACL and to therefore receive AAAA RR responses. These DNS recursive resolvers are operated by other parties, such as ISPs, universities, governments, businesses, individual end users, etc. If a DNS recursive resolver IS NOT on the ACL, then NO AAAA RRs with IPv6 addresses will be sent in response to a query for a given hostname in the example.com domain. However, if a DNS recursive resolver IS on the ACL, then AAAA RRs with IPv6 addresses will be sent in response to a query for a given hostname in the example.com domain. While these are not network-layer access controls, they are nonetheless access controls that are a factor for both end users and are directly related to the transition of one network address family to another (IPv4 to IPv6).</t>
<t>In practice this generally means that a very small fraction of the DNS recursive resolvers on the Internet can receive AAAA responses with IPv6 addresses, which means that the large majority of DNS resolvers on the Internet will receive only A RRs with IPv4 addresses. Thus, quite simply, the authoritative server hands out different answers depending upon who is asking; with IPv4 and IPv6 records for some on the authorized whitelist, and only IPv4 records for everyone else. See <xref target='DNS Whitelisting - System Logic'/> and <xref target='DNS Whitelisting - Functional Diagram'/> for two different visual descriptions of how this works in practice.</t>
<t>Finally, DNS whitelisting can be deployed in two primary ways: universally on a global basis, or on an ad hoc basis. These two potential deployment models are described in <xref target='Likely Deployment Scenarios'/>.</t>
<figure anchor='DNS Whitelisting - System Logic' title='DNS Whitelisting - System Logic'>
<artwork><![CDATA[
1: The authoritative DNS server for example.com receives a DNS
query for www.example.com, for which both A (IPv4) and AAAA
(IPv6) address records exist.
2: The authoritative DNS server examines the IP address of the DNS
recursive resolver sending the query.
3: The authoritative DNS server checks this IP address against the
access control list (ACL) that is the DNS whitelist.
4: If the DNS recursive resolver's IP address IS listed in the ACL,
then the response to that specific DNS recursive resolver can
contain both A (IPv4) and AAAA (IPv6) address records.
5: If the DNS recursive resolver's IP address IS NOT listed in the
ACL, then the response to that specific DNS recursive resolver
can contain only A (IPv4) address records and therefore cannot
contain AAAA (IPv6) address records.
]]></artwork>
</figure>
<figure anchor='DNS Whitelisting - Functional Diagram' title='DNS Whitelisting - Functional Diagram'>
<artwork><![CDATA[
---------------------------------------------------------------------
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:
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
---------------------------------------------------------------------
]]></artwork>
</figure>
</section>
<section title='Concerns Regarding DNS Whitelisting' anchor='Concerns Regarding DNS Whitelisting' toc='include'>
<t>There are a number of potential implications relating to DNS whitelisting, which have raised various concerns in some parts of the Internet community. Many of those potential implications are described in <xref target='Implications of DNS Whitelisting'/>.</t>
<t>Some parties in the Internet community, including ISPs like Comcast, are concerned that this emerging practice of DNS whitelisting for IPv6 address records could represent a departure from the generally accepted practices regarding IPv4 address records in the DNS on the Internet <xref target="IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?"/>. These parties explain their belief that for A records, containing IPv4 addresses, once an authoritative server operator adds the A record to the DNS, then any DNS recursive resolver on the Internet can receive that A record in response to a query. By extension, this means that any of the hosts connected to any of these DNS recursive resolvers can receive the IPv4 address records for a given FQDN. This enables new server hosts which are connected to the Internet, and for which a fully qualified domain name (FQDN) such as www.example.com has been added to the DNS with an IPv4 address record, to be almost immediately reachable by any host on the Internet. In this case, these new servers hosts become more and more widely accessible as new networks and new end user hosts connect to the Internet over time [EDITORIAL: consider reference to network effects]. It also means that the new server hosts do not need to know about these new networks and new end user hosts in order to make their content and applications available to them, in essence that each end in this end-to-end model is responsible for connecting to the Internet and once they have done so they can connect to each other without additional impediments or middle networks or intervening networks or servers knowing about these end points and whether one is allowed to contact the other.</t>
<t>In contrast, these parties are concerned that DNS whitelisting may fundamentally change this model. As a result, in this altered end-to-end model, one end (where the end user is located) cannot readily connect to the other end (where the content is located), without parts of the middle used by one end being known by the other end and approved for access to that end. <!-- See <xref target='An Altered End-to-End Model'/> for a visual comparison of these two models. --> Thus, as new networks connect to the Internet over time, those networks need to contact any and all domains which have implemented DNS whitelisting in order to apply to be added to their DNS whitelist, in the hopes of making the content and applications residing on named server hosts in those domains accessible by the end user hosts on that new network. Furthermore, this same need to contact all domains implementing DNS whitelisting also applies to all existing networks connected to the Internet.</t>
<t>Therefore, these concerned parties explain, whereas in the current IPv4 Internet when a new server host is added to the Internet it is widely available to all end user hosts and networks, when DNS whitelisting of IPv6 records is used then these new server hosts are not accessible to any end user hosts or networks until such time as the operator of the authoritative DNS servers for those new server hosts expressly authorizes access to those new server hosts by adding DNS recursive resolvers around the Internet to the ACL. This could represent a significant change in reachability of content and applications by end users and networks as these end user hosts and networks transition to IPv6. Therefore, a concern expressed is that if much of the content that end users are most interested 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 <xref target='I-D.shirasaki-nat444'/> on a long-term basis. There is also concern that this practice also could disrupt the continued increase in Internet adoption by end users if they cannot simply access new content and applications but must instead contact the operator of their DNS recursive resolver, such as their ISP or another third party, to have their DNS recursive resolver authorized for access to the content or applications that interests them. <!-- Next sentence added by Tom. Review later to ensure it is in the right place in the document -->Meanwhile, these parties say, over 99.9% of all other end users that are also using that same network or DNS recursive resolver are unable to access the IPv6-based content, despite their experience being a positive one.</t>
<!--
<figure anchor='An Altered End-to-End Model' title='An Altered End-to-End Model'>
<artwork><![CDATA[
-------------------------------------------------------------------------------
End-to-end model for the IPv4 Internet
-------------------------------------------------------------------------------
End-to-end model for the IPv6 Internet, if DNS whitelisting is used
-------------------------------------------------------------------------------
]]></artwork>
</figure>
-->
<t>While in <xref target ='Introduction'/> the level of IPv6-related impairment has been estimated to be as high as 0.078% of Internet users, which is a primary motivation cited for the practice of DNS whitelisting, it is not clear if the level of IPv4-related impairment is more or less 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 to or are otherwise not in a position to be able to measure IPv4 impairment (since this could result in no Internet access whatsoever). As a result, it is worth considering that IPv4-related impairment could exceed that of IPv6-related impairment and that such IPv4-related impairment may have simply been accepted as "background noise" on the Internet for a variety of reasons.</t>
</section>
<section title='Similarities to Other DNS Operations' anchor='Similarities to Other DNS Operations' toc='include'>
<t>Some aspects of DNS whitelisting may be considered similar in some ways to other common DNS operational techniques, which is explored briefly below.</t>
<section title='Similarities to Split DNS' anchor='Similarities to Split DNS' toc='include'>
<t>DNS whitelisting has some similarities to so-called split DNS, which is briefly described in Section 3.8 of <xref target='RFC2775'/>. When split DNS is used, the authoritative DNS server returns different responses depending upon what host has sent the query. While <xref target='RFC2775'/> notes the typical use of split DNS is to provide one answer to hosts on an Intranet and a different answer to hosts on the Internet, the essence is that different answers are provided to hosts on different networks. This is basically the way that DNS whitelisting works, in so far as hosts of 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. Thus, in a way, DNS whitelisting could in some ways be considered split DNS on the public Internet, though with some differences.</t>
<t>In <xref target='RFC2956'/>, Internet transparency and Internet fragmentation concerns regarding split DNS are detailed in Section 2.1. <xref target='RFC2956'/> further notes in Section 2.7, concerns regarding split DNS and that it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint identifiers more complex." Section 3.5 of <xref target='RFC2956'/> further recommends that maintaining a stable approach to DNS operations is key during transitions such as the one to IPv6 that is underway now, stating that "Operational stability of DNS is paramount, especially during a transition of the network layer, and both IPv6 and some network address translation techniques place a heavier burden on DNS."</t>
</section>
<section title='Similarities to DNS Load Balancing' anchor='Similarities to DNS Load Balancing' toc='include'>
<t>DNS whitelisting also has some similarities to DNS load balancing. There are many ways that DNS load balancing can be performed, and of course this can mean many things to different people. In one example, multiple IP address resource records (A or AAAA) can be added to the DNS to resolve a given FQDN, which is referred to as DNS round robin [REFERENCE AVAILABLE?]. In another example, one or more of the IP address resource records in the DNS will direct traffic to a load balancer [REFERENCE AVAILABLE?]. That load balancer, in turn, may be application-aware, and pass the traffic on to one or more hosts connected to the load balancer which have different IP addresses. In cases where private IPv4 addresses are used <xref target='RFC1918'/>, as well as 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 added to the DNS, the end hosts are not necessarily directly reachable, which is in a small way similar to one aspect of DNS whitelisting. In addition, a geographically-aware authoritative DNS server may be used, as is common with Content Delivery Networks (CDNs), whereby the IP address resource records returned to a resolver in response to a query will vary based on the estimated geographic location of the resolver [REFERENCE AVAILABLE?]. CDNs perform this function in order to attempt to direct hosts to connect to the nearest content cache. As a result, one can see some similarities with DNS whitelisting insofar as different IP address resource records are returned to resolvers based on the IP address of each resolver (or other imputed factors related to that IP address). However, what is different of course, if that in this case the resolvers are not necessarily blocked from receiving DNS responses containing an entire class of addresses; this load balancing function strives to perform a content location-improvement function and not an access control function.</t>
</section>
</section>
<section title='Likely Deployment Scenarios' anchor='Likely Deployment Scenarios' toc='include'>
<t>In considering how DNS whitelisting may emerge more widely, there are two likely deployment scenarios, which are explored below.</t>
<t>In either of these likely deployment scenarios below, it is possible that reputable third parties could create and maintain these DNS whitelists, in much the same way that blacklists are used for reducing email spam. In this email example, a mail operator subscribes to one or more of these lists and as such the operational processes for additions and deletions to the list are managed by a third party. Thus, a similar model could emerge for DNS whitelisting, whether deployment occurs universally or on an ad hoc basis.</t>
<section title='Deploying DNS Whitelisting Universally' anchor='Deploying DNS Whitelisting Universally' toc='include'>
<t>The least likely deployment scenario is one where DNS whitelisting becomes a standardized process across all authoritative DNS servers, across the entire Internet. While this scenario is the least likely, due to some parties not sharing the concerns that have so far motivated the use of DNS whitelisting, it is nonetheless conceivable that it could be one of the ways in which DNS whitelisting may be deployed.</t>
<t>In order for this deployment scenario to occur, it is likely that DNS whitelisting functionality would need to be built into all authoritative DNS server software, and that all operators of authoritative DNS servers would have to upgrade their software and enable this functionality. Furthermore, it is likely that new Internet Draft documents would need to be developed which describe how to properly configure, deploy, and maintain DNS whitelisting. As a 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, depending upon a variety of factors. Such factors may include the motivation of each domain owner, the location of the DNS recursive resolvers in relation to the source content, as well as various other parameters that may be transitory in nature, or unique to a specific end user host type. Thus, it is probably unlikely that a single clearinghouse for managing whitelisting is possible; it will more likely be unique to the source content owners and/or domains which implement DNS whitelists.</t>
<t>While this scenario may be unlikely, it may carry some benefits. First, parties performing troubleshooting would not have to determine whether or not DNS whitelisting was being used, as it always would be in use. In addition, if universally deployed, it is possible that the criteria for being added to or removed from a DNS whitelist could be standardized across the entire Internet. Nevertheless, even if uniform DNS whitelisting policies were not standardized, is also possible that a central registry of these policies could be developed and deployed in order to make it easier to discover them, a key part of achieving transparency regarding DNS whitelisting.</t>
</section>
<section title='Deploying DNS Whitelisting On An Ad Hoc Basis' anchor='Deploying DNS Whitelisting On An Ad Hoc Basis' toc='include'>
<t>This is the most likely deployment scenario for DNS whitelisting, as it seems today, is where some interested parties engage in DNS whitelisting but many or most others do not do so. What can make this scenario challenging from the standpoint of a DNS recursive resolver operator is determining which domains implement DNS whitelisting, particularly since a domain may not do so as they initially transition to IPv6, and may instead do so later. Thus, a DNS recursive resolver operator may initially believe that they can receive AAAA responses with IPv6 addresses as a domain adopts IPv6, but then notices via end user reports that they no longer receive AAAA responses due to that site adopting DNS whitelisting.</t>
<t>Thus, in contrast to universal deployment of DNS whitelisting, deployment on an ad hoc basis is likely 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 is not implemented for a domain, since the absence of AAAA records with IPv6 addresses may simply be indicative that the domain has not yet added IPv6 addressing for the domain, not that they have done so but have restricted query access via DNS whitelisting. As a result, discovering which domains implement DNS whitelisting, in order to differentiate them from those that do not, is likely to be challenging.</t>
<t>On the other hand, one benefit of DNS whitelisting being deployed on an ad hoc basis is that only the domains that are interested in doing so would have to upgrade their authoritative DNS servers in order to implement the ACLs necessary to perform DNS whitelisting.</t>
</section>
</section>
<section title='What Problems Are DNS Whitelisting Implementers Trying To Solve?' anchor='What Problems Are DNS Whitelisting Implementers Trying To Solve?' toc='include'>
<t>As noted in <xref target='Introduction'/>, domains which implement DNS whitelisting are attempting to protect a few users of their domain, which happen to have impaired IPv6 access, from having a negative end user experience. While it is outside the scope of this document to explore the various reasons why a particular user may experience impaired IPv6 access, for the users which experience this it is a very real effect and would of course affect access to all or most IPv4 and IPv6 dual stack servers. 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.</t>
<t>Thus, parties which implement DNS whitelisting are attempting to provide a good experience to these end users. While one can debate whether DNS whitelisting is the optimal solution, it is quite clear that DNS whitelisting implementers are extremely interested in the performance of their services for end users as a primary motivation.</t>
<t>In addition, Google has noted that they have received requests to not send DNS responses with AAAA resource records to particular resolvers. In these cases, the operators of those recursive resolvers have expressed a concern that their IPv6 network infrastructure is not yet ready to handle the traffic volume which may be associated with the hosts in their network connecting to Google websites, such as YouTube. In this case, this is clearly a temporary concern relating to the deployment of IP network infrastructure on the part of networks with end user hosts, rather than a long-term concern. These end user networks may also have other tools at their disposal in order to address this, including applying rules to network equipment such as routers and firewalls (this will necessarily vary by the type of network, as well as the technologies used and the design of a given network).</t>
</section>
<!-- IMPLICATIONS START HERE -->
<section title='Implications of DNS Whitelisting' anchor='Implications of DNS Whitelisting' toc='include'>
<t>There are many potential implications of DNS whitelisting. In the sections below, the key potential implications are listed in some detail.</t>
<section title='Architectural Implications' anchor='Architectural Implications' toc='include'>
<t>DNS whitelisting could be perceived as somewhat modifying the end-to-end model and/or the general notion of the architecture that prevails on the Internet today. This is because this approach moves additional access control information and policies into the middle of the DNS resolution path on the IPv6-addressed Internet, which did not exist before on the IPv4-addressed Internet. This could raise some risks noted in <xref target='RFC3724'/>, which in explaining the history of the end-to-end principle <xref target='RFC1958'/> explains that one of the goals is to minimize the state, policies, and other functions needed in the middle of the network in order to enable end-to-end communications on the Internet. In this case, the middle network should be understood to mean anything other than the end hosts involved in communicating with one another. Obviously some state, policies, and other functions have always been necessary to enable such end-to-end communication, but the goal of the approach has been to minimize this to the greatest extent possible.</t>
<t>It is also possible that DNS whitelisting could place at risk some of the benefits of the end-to-end principle, as listed in Section 4.1 of <xref target='RFC3724'/>, such as protection of innovation. Further, while <xref target='RFC3234'/> details issues and concerns regarding so-called middleboxes, there may be parallels to DNS whitelisting, especially concerning modified DNS servers noted in Section 2.16 of <xref target='RFC3234'/>, and more general concerns noted in Section 1.2 of <xref target='RFC3234'/> about the introduction of new failure modes, that configuration is no longer limited to two ends of a session, and that diagnosis of failures and misconfigurations is more complex.</t>
<t>In <xref target='Tussle in Cyberspace'/>, the authors note concerns regarding the introduction of new control points, as well as "kludges" to the DNS, as risks to the goal of network transparency in the end-to-end model. Some parties concerned with the emerging use of DNS whitelisting have shared similar concerns, which may make <xref target='Tussle in Cyberspace'/> an interesting and relevant document. In addition, <xref target='Rethinking the design of the Internet'/> reviews similar issues that may be of interest to readers of this document.</t>
<t>In order to explore and better understand these high-level architectural implications and concerns in more detail, the following sections explore more specific potential implications.</t>
</section>
<section title='Public IPv6 Address Reachability Implications' anchor='Public IPv6 Address Reachability Implications' toc='include'>
<t>The predominant experience of end user hosts and servers on the IPv4-addressed Internet today is that, very generally speaking, when a new server with a public IPv4 address is added, that it is then globally accessible by IPv4-addressed hosts. Of course, this is a generalization and in <xref target='Similarities to Other DNS Operations'/> there are examples of common cases where this may not necessarily be the case. In any case, for the purposes of this document, that concept of accessibility 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, this will not be the case since only end user hosts using DNS recursive resolvers which have been added to the ACL of a given domain using DNS whitelisting would be able to reach new servers in that given domain via IPv6 addresses. Thus, the expectation of any end user host being able to connect to any server (essentially both hosts, just at either end of the network), defined here as "pervasive reachability", will change to "restricted reachability" with IPv6. </t>
<t>In addition, establishing DNS whitelisting as an accepted practice in the early phases of mass IPv6 deployment could well establish DNS whitelisting as an integral part of how IPv6 is deployed globally. As a result, it is then possible that DNS whitelisting could live on for decades on the Internet as a key foundational element of the Internet of the future that we will all live with for a long time.</t>
<t>However, it is a critical to understand that the concept of reachability described above depends upon a knowledge or awareness of an address in the DNS. Thus, in order to establish reachability to an end point, a host is dependent upon looking up an IP address in the DNS when a FQDN is used. Thus, when DNS whitelisting is used, it is quite likely the case that a end user host could ping a example server host, even though the FQDN associated with that server host is restricted via a DNS whitelist. But since most Internet applications and hosts such as web servers depend upon the DNS, and as end users connect to FQDNs such as www.example.com and do not remember or wish to type in an IP address, the notion of reachability described here should be understood to include knowledge how to associate a name with a network address.</t>
</section>
<section title='Operational Implications' anchor='Operational Implications' toc='include'>
<t>This section explores some of the operationally related implications which may occur as a result of, related to, or necessary when engaging in the practice of DNS whitelisting.</t>
<section title='De-Whitelisting May Occur' anchor='De-Whitelisting May Occur' toc='include'>
<t>If it is possible for a DNS recursive resolver to be added to a whitelist, then it is also possible for that resolver to be removed from the whitelist, also known as de-whitelisting. Since de-whitelisting can occur, whether through a decision by the authoritative server operator or the domain owner, or even due to a technical error, an operator of a DNS recursive resolver will have new operational and monitoring requirements and/or needs as noted in <xref target='DNS Recursive Resolver Server Operational Implications'/>, <xref target='Monitoring Implications'/>, <xref target='Troubleshooting Implications'/>, and <xref target='Technology Policy Implications'/>.</t>
</section>
<section title='Authoritative DNS Server Operational Implications' anchor='Authoritative DNS Server Operational Implications' toc='include'>
<t>Operators of authoritative servers may need to maintain an ACL a server-wide basis affecting all domains, on a domain-by-domain basis, as well as on a combination 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 may need to be put in place to protect against inadvertently adding or removing IP addresses, as well as systems and/or processes to respond to such incidents if and when they occur. For example, a 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 de-whitelisted, log the personnel involved and timing of changes, schedule changes to occur in the future, and to roll back any inadvertent changes.</t>
<t>Such operators may also need implement new forms of monitoring in order to apply change control, as noted briefly in <xref target='Monitoring Implications'/>.</t>
</section>
<section title='DNS Recursive Resolver Server Operational Implications' anchor='DNS Recursive Resolver Server Operational Implications' toc='include'>
<t>Operators of DNS recursive resolvers, which may include ISPs, enterprises, universities, governments, individual end users, and many other parties, are likely to need to implement new forms of monitoring, as noted briefly in <xref target='Monitoring Implications'/>. But more critically, such operators may need to add people, processes, and systems in order to manage countless DNS whitelisting applications, for all domains that the end users of such servers are interested in now or in which they may be interested in the future. As such anticipation of interesting domains is likely infeasible, it is more likely that such 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 to do so for all domains.</t>
<t>When such 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 to discover whether each domain has been whitelisted or not, which is touched on in <xref target='Likely Deployment Scenarios'/> and may vary depending upon whether DNS whitelisting is universally deployed or is deployed on an ad hoc basis.</t>
<t>Furthermore, these operators will need to develop processes and systems to track the status of all DNS whitelisting applications, respond to requests for additional information related to these applications, determine when and if applications have been denied, manage appeals, and track any de-whitelisting actions. Given the incredible number of domains in existence, the ease with which a new domain can be added, and the continued strong growth in the numbers of new domains, readers should not underestimate the potential significance in personnel and expense that this could represent for such operators. In addition, it is likely that systems and personnel may also be needed to handle new end user requests for domains for which to apply for DNS whitelisting, and/or inquiries into 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.</t>
</section>
<section title='Monitoring Implications' anchor='Monitoring Implications' toc='include'>
<t>Once a DNS recursive resolver has been whitelisted for a particular domain, then the operator of that DNS recursive resolver may need to implement monitoring in order to detect the possible loss of whitelisting status in the future. This DNS recursive resolver operator could configure a monitor to check for a AAAA response in the whitelisted domain, as a check to validate continued status on the DNS whitelist. The monitor could then trigger an alert if at some point the AAAA responses were no longer received, so that operations personnel could begin troubleshooting, as outlined in <xref target='Troubleshooting Implications'/>. </t>
<t>Also, authoritative DNS server operators are likely to need to implement new forms of monitoring. In this case, they may desire to monitor for significant changes in the size of the whitelist within a certain period of time, which might be indicative of a technical error such as the entire ACL being removed. These operators may also wish to monitor their workflow process for reviewing and acting upon DNS whitelisting applications and appeals, potentially measuring and reporting on service level commitments regarding the time an application or appeal can remain at each step of the process, regardless of whether or not such information is shared with parties other than that authoritative DNS server operator.</t>
<t>These are but a few examples of the types of monitoring that may be called for as a result of DNS whitelisting, among what are likely many other types and variations.</t>
</section>
<section title='Implications of Operational Momentum' anchor='Implications of Operational Momentum' toc='include'>
<t>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 of human nature, not to mention physics. For example, as Sir Issac Newton noted, "Every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it" <xref target="Newton's Laws of Motion"/>. Thus, once DNS whitelisting is implemented it is quite likely that it would take considerable effort to deprecate the practice and remove it everywhere on the Internet - it will otherwise simply remain in place in perpetuity. To better illustrate this point, one could consider in one example (of many) that here are likely many email servers continuing to attempt to query or otherwise check anti-spam DNS blocklists which have long ago ceased to exist.</t>
</section>
<section title='Troubleshooting Implications' anchor='Troubleshooting Implications' toc='include'>
<t>The implications of DNS whitelisted present many challenges, which have been detailed in <xref target='Implications of DNS Whitelisting'/>. These challenges may negatively affect the end users' ability to troubleshoot, as well as that of DNS recursive resolver operators, ISPs, content providers, domain owners (where they may be different from the operator of the authoritative DNS server for their domain), and other third parties. This may make the process of determining why a server is not reachable significantly more complex.</t>
</section>
<section title='Additional Implications If Deployed On An Ad Hoc Basis' anchor='Additional Implications If Deployed On An Ad Hoc Basis' toc='include'>
<t>Additional implications, should this be deployed on an ad hoc basis, could include scalability problems relating to operational processes, monitoring, and ACL updates. In particular, it seems quite likely that as the number of domains that are whitelisted increases, as well as the number of IPv6-capable networks requesting to be whitelisted, that there is an increased likelihood of configuration and other operational errors, especially with respect to the ACLs themselves. It is also unclear when and if it would be appropriate to change from whitelisting to blacklisting, and whether/how this could feasibly be coordinated across the Internet, which may be proposed when a majority 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 is not clear how these parties will judge the network conditions to have changed sufficiently to justify disabling DNS whitelisting and/or what the process and timing will be in order to turn off and stop this practice.</t>
</section>
</section>
<section title='Homogeneity May Be Encouraged' anchor='Homogeneity May Be Encouraged' toc='include'>
<t>A broad trend which has existed on the Internet appears to be a move towards increasing levels of heterogeneity. One manifestation of this is in an increasing number, variety, and customization of end user hosts, including home network, operating systems, client software, home network devices, and personal computing devices. This trend appears to have had a positive effect on the development and growth of the Internet. A key facet of this that has evolved is the ability of the end user to connect any technically compliant device or use any technically compatible software to connect to the Internet. Not only does this trend towards greater heterogeneity reduce the control which is exerted in the middle of the network, described in positive terms in <xref target='Tussle in Cyberspace'/>, <xref target='Rethinking the design of the Internet'/>, and <xref target='RFC3724'/>, but it can also help to enable greater and more rapid innovation at the edges.</t>
<t>An unfortunate implication of the adoption 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, 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 to enforce technical standards relating to establishing certain IPv6 capabilities or the enforcing the elimination of or restriction of certain end user hosts. While 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, or even a few major domains (meaning domains which are a major destination of Internet traffic) implementing DNS whitelisting, may be to encourage a return to more homogenous and/or controlled end user hosts. Unfortunately, this could have unintended side effects on and counter-productive implications for future innovation at the edges of the network.</t>
</section>
<section title='Technology Policy Implications' anchor='Technology Policy Implications' toc='include'>
<t>A key technology policy implication concerns the policies relating to the process of reviewing an application for DNS whitelisting, and the decision-making process regarding whitelisting for a domain. Important questions may include whether these policies have been fully and transparently disclosed, are non-discriminatory, and are not anti-competitive. A related implication is whether and what the process for appeals is, when a domain decides not to add 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, and whether the appeal will be handled by an independent third party or other entity/group.</t>
<t>A further implications arises when de-whitelisting occurs. Questions that may naturally be raised in such a case include whether the criteria for de-whitelisting have been fully and transparently disclosed, are non-discriminatory, and are not anti-competitive. Additionally, the question of whether or not there was a cure period available prior to de-whitelisting, during which troubleshooting activities, complaint response work, and corrective actions may be attempted, and whether this cure period was a reasonable amount of time.</t>
<t>It is also conceivable that whitelisting and 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, application developers, content providers, advertisers, public policy groups, governments, and other entities, which may also seek to become involved in or express opinions concerning whitelisting and/or de-whitelisting decisions. Lastly, it is conceivable that any of these interested parties or other related stakeholders may seek redress outside of the process a domain has establishing for DNS whitelisting and de-whitelisting.</t>
<t>A final concern is that decisions relating to whitelisting and de-whitelisting may occur as an expression of other commercial, governmental, and/or cultural conflicts, given the new control point which has be 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 domain, etc. In another example, a music-oriented domain may be engaged in some sort of dispute with an academic network concerning copyright infringement concerns within that network, and may choose to de-whitelist that network as a negotiating technique in some sort of 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 spam, which 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 to express a strong voice in such decisions.</t>
</section>
<section title='IPv6 Adoption Implications' anchor='IPv6 Adoption Implications' toc='include'>
<t>As noted in <xref target='Concerns Regarding DNS Whitelisting'/>, the implications of 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 use of multi-layer network address translation (NAT) techniques like NAT444 <xref target='I-D.shirasaki-nat444'/>, which these parties may decide to pursue on a long-term basis to avoid the perceived costs and aggravations 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 and motivated to begin the transition to IPv6. As a result, parties that are likely to be concerned over the negative implications of DNS whitelisting 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 ecosystem.</t>
</section>
</section>
<section title='Solutions' anchor='Solutions' toc='include'>
<t>This section outline several possible solutions when considering DNS whitelisting and associated IPv6-related issues.</t>
<section title='Implement DNS Whitelisting Universally' anchor='Implement DNS Whitelisting Universally' toc='include'>
<t>One obvious solution 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. This potential solution seems unlikely at the current time.</t>
</section>
<section title='Implement DNS Whitelisting On An Ad Hoc Basis' anchor='Implement DNS Whitelisting On An Ad Hoc Basis' toc='include'>
<t>If DNS whitelisting was to be adopted, it is likely to be adopted on this 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 they a given domain has done so may be problematic. Also in this scenario, ad hoc use by a particular domain may also be a temporary measure that has been adopted to ease the transition of the domain to IPv6 over some short-term timeframe.</t>
</section>
<section title='Do Not Implement DNS Whitelisting' anchor='Do Not Implement DNS Whitelisting' toc='include'>
<t>As an alternative to adopting DNS whitelisting, the Internet community can instead choose to take no action whatsoever, perpetuating the current predominant authoritative DNS operational model on the Internet, and leave it up to end users with IPv6-related impairments to discover and fix those impairments.</t>
<section title='Solving Current End User IPv6 Impairments' toc='include'>
<t>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.</t>
<t>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.</t>
<t>Despite any potential challenges, many in the Internet community are already working towards this goal and/or have expressed a preference for this approach.</t>
</section>
</section>
</section>
<section title='Security Considerations' anchor='Security Considerations' toc='include'>
<t>There are no particular security considerations if DNS whitelisting is not adopted, as this is how the public Internet works today with A records.</t>
<t>However, if DNS whitelisting is adopted, 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. 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.</t>
<t>In addition, two other key security-related issues should be taken into consideration:</t>
<section title='DNSSEC Considerations' anchor='DNSSEC Considerations' toc='include'>
<t>DNS security extensions defined in <xref target='RFC4033'/>, <xref target='RFC4034'/>, and <xref target='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. Therefore there are no DNSSEC implications per se. However, any implementer of DNS whitelisting should be quite careful if they implement both DNSSEC signing of their domain and also DNS whitelisting of that same domain. Specifically, those domains should ensure that records are being appropriately and reliably signed, which may well prove operationally and/or technically challenging.</t>
</section>
<section title='Authoritative DNS Response Consistency Considerations' anchor='Authoritative DNS Response Consistency Considerations' toc='include'>
<t>In addition to the considerations raised in <xref target='DNSSEC Considerations'/>, 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.</t>
</section>
</section>
<section title='IANA Considerations' anchor='IANA Considerations' toc='include'>
<t>There are no IANA considerations in this document.</t>
</section>
<section title='Contributors' toc='include'>
<t>The following people made significant textual contributions to this document and/or played an important role in the development and evolution of this document:</t>
<t>- John Brzozowski</t>
<t>- Chris Griffiths</t>
<t>- Tom Klieber</t>
<t>- Yiu Lee</t>
<t>- Rich Woundy</t>
</section>
<section title='Acknowledgements' toc='include'>
<t>The author and contributors also wish to acknowledge the assistance of the following individuals. 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:</t>
<t>- Bernard Aboba</t>
<t>- Frank Bulk</t>
<t>- Brian Carpenter</t>
<t>- Wesley George</t>
<t>- Erik Kline</t>
<t>- Danny McPherson</t>
<t>- Hannes Tschofenig</t>
</section>
<!-- appendix -->
</middle>
<!-- END MIDDLE SECTION -->
<!-- BACK SECTION -->
<back>
<references title='Normative References'>
&RFC1035;
&RFC1918;
&RFC1958;
&RFC2775;
&RFC2956;
&RFC3234;
&RFC3724;
&RFC4033;
&RFC4034;
&RFC4035;
</references>
<references title='Informative References'>
<reference anchor="IPv6 Whitelist Operations" target="http://sites.google.com/site/ipv6implementors/2010/agenda/IPv6_Whitelist_Operations.pdf">
<front>
<title>IPv6 Whitelist Operations</title>
<author initials='E.' surname='Kline' fullname='Erik Kline'>
<organization abbrev='Google'>Google</organization>
</author>
<date month="June" day="11" year="2010"/>
</front>
<seriesInfo name="Google" value="Google IPv6 Implementors Conference"/>
</reference>
<reference anchor="IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?" target="http://www.comcast6.net/IPv6_DNS_Whitelisting_Concerns_20100416.pdf">
<front>
<title>IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?</title>
<author initials='J.' surname='Brzozowski' fullname='John Brzozowski'>
<organization abbrev='Comcast'>Comcast</organization>
</author>
<author initials='C.' surname='Griffiths' fullname='Chris Griffiths'>
<organization abbrev='Comcast'>Comcast</organization>
</author>
<author initials='T.' surname='Klieber' fullname='Tom Klieber'>
<organization abbrev='Comcast'>Comcast</organization>
</author>
<author initials='Y.' surname='Lee' fullname='Yiu Lee'>
<organization abbrev='Comcast'>Comcast</organization>
</author>
<author initials='J.' surname='Livingood' fullname='Jason Livingood'>
<organization abbrev='Comcast'>Comcast</organization>
</author>
<author initials='R.' surname='Woundy' fullname='Rich Woundy'>
<organization abbrev='Comcast'>Comcast</organization>
</author>
<date month="April" day="22" year="2010"/>
</front>
<seriesInfo name="ISOC" value="Internet Society IPv6 Deployment Workshop"/>
</reference>
<reference anchor="IETF 77 DNSOP WG Presentation" target="http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf">
<front>
<title>IPv6 & recursive resolvers: How do we make the transition less painful?</title>
<author initials='I.' surname='Gashinsky' fullname='Igor Gashinsky'>
<organization abbrev='Yahoo'>Yahoo</organization>
</author>
<date month="March" day="24" year="2010"/>
</front>
<seriesInfo name="IETF 77" value="DNS Operations Working Group"/>
</reference>
<reference anchor="Network World Article on IETF 77 DNSOP WG Presentation" target="http://www.networkworld.com/news/2010/032610-yahoo-dns.html">
<front>
<title>Yahoo proposes 'really ugly hack' to DNS</title>
<author initials='C.' surname='Marsan' fullname='Carolyn Duffy Marsen'>
<organization abbrev='Network World'>Network World</organization>
</author>
<date month="March" day="26" year="2010"/>
</front>
<seriesInfo name="Network World" value=""/>
</reference>
<reference anchor="Network World Article on DNS Whitelisting" target="http://www.networkworld.com/news/2010/032610-dns-ipv6-whitelist.html">
<front>
<title>Google, Microsoft, Netflix in talks to create shared list of IPv6 users</title>
<author initials='C.' surname='Marsan' fullname='Carolyn Duffy Marsen'>
<organization abbrev='Network World'>Network World</organization>
</author>
<date month="March" day="26" year="2010"/>
</front>
<seriesInfo name="Network World" value=""/>
</reference>
<?rfc include="reference.I-D.shirasaki-nat444.xml"?>
<reference anchor="Tussle in Cyberspace" target="http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf">
<front>
<title>Tussle in Cyberspace: Defining Tomorrow's Internet</title>
<author initials='R.' surname='Braden' fullname='Robert Braden'>
<organization abbrev='USC ISI'>USC Information Sciences Institute</organization>
</author>
<author initials='D.' surname='Clark' fullname='David D. Clark'>
<organization abbrev='MIT'>MIT Lab for Computer Science</organization>
</author>
<author initials='K.' surname='Sollins' fullname='Karen R. Sollins'>
<organization abbrev='MIT'>MIT Lab for Computer Science</organization>
</author>
<author initials='J.' surname='Wroclawski' fullname='John Wroclawski'>
<organization abbrev='MIT'>MIT Lab for Computer Science</organization>
</author>
<date month="August" year="2002"/>
</front>
<seriesInfo name="Proceedings of ACM Sigcomm" value="2002"/>
</reference>
<reference anchor="Rethinking the design of the Internet" target="http://dspace.mit.edu/bitstream/handle/1721.1/1519/TPRC_Clark_Blumenthal.pdf">
<front>
<title>Rethinking the design of the Internet: The end to end arguments vs. the brave new world</title>
<author initials='M.' surname='Blumenthal' fullname='Marjory S. Blumenthal'>
<organization abbrev='CST'>Computer Science & Telecommunications Board</organization>
</author>
<author initials='D.' surname='Clark' fullname='David D. Clark'>
<organization abbrev='MIT'>MIT Lab for Computer Science</organization>
</author>
<date month="August" year="2001"/>
</front>
<seriesInfo name="ACM Transactions on Internet Technology" value="Volume 1, Number 1, Pages 70-109"/>
</reference>
<reference anchor="Newton's Laws of Motion" target="http://en.wikipedia.org/wiki/Newton's_laws_of_motion">
<front>
<title>Mathematical Principles of Natural Philosophy (Philosophiae Naturalis Principia Mathematica)</title>
<author initials='I.' surname='Newton' fullname='Sir Issac Newton'>
</author>
<date month="July" day="5" year="1687"/>
</front>
<seriesInfo name="Principia" value="Mathematical Principles of Natural Philosophy (Philosophiae Naturalis Principia Mathematica)"/>
</reference>
</references>
<section title='Document Change Log'>
<t>[RFC Editor: This section is to be removed before publication]</t>
<t>-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.</t>
<t>-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.</t>
</section>
<section title='Open Issues'>
<t>[RFC Editor: This section is to be removed before publication]</t>
<t>
<list style='numbers'>
<t>Close the issues below and any feedback from the v6ops and dnsop mailing lists in a -02 update, then request WGLC</t>
<t>Perform an second review of notes from IETF 79 to ensure that all feedback received then has been fully taken into account!</t>
<t>Add any good references throughout the document - posed in question to v6ops</t>
<t>Ensure references are in the proper section (normative/informative)</t>
<t>Include a number of references from RFC3724?</t>
<t>Add brokenness reference to http://ripe61.ripe.net/presentations/162-ripe61.pdf</t>
<t>Should I include a full list or other details of the root causes of IPv6 brokenness? - posed in question to v6ops</t>
</list>
</t>
</section>
</back>
<!-- END BACK SECTION -->
</rfc>
<!-- FOR REFERENCE -->
<!-- less than is < -->
<!-- ampersand is & -->
<!-- apostrophe is &apos -->
<!-- quotation is " -->
| PAFTECH AB 2003-2026 | 2026-04-24 10:25:05 |