idnits 2.17.1 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 25, 2011) is 4838 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations J. Livingood 3 Internet-Draft Comcast 4 Intended status: Informational January 25, 2011 5 Expires: July 29, 2011 7 IPv6 AAAA DNS Whitelisting Implications 8 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-01 10 Abstract 12 The objective of this document is to describe what whitelisting of 13 DNS AAAA resource records is, or DNS whitelisting for short, as well 14 as what the implications of this emerging practice are and what 15 alternatives may exist. The audience for this document is the 16 Internet community generally, including the IETF and IPv6 17 implementers. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 29, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 5 67 3. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 7 68 4. Similarities to Other DNS Operations . . . . . . . . . . . . . 9 69 4.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 9 70 4.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 10 71 5. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 11 72 5.1. Deploying DNS Whitelisting Universally . . . . . . . . . . 11 73 5.2. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 12 74 6. What Problems Are DNS Whitelisting Implementers Trying To 75 Solve? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 13 77 7.1. Architectural Implications . . . . . . . . . . . . . . . . 13 78 7.2. Public IPv6 Address Reachability Implications . . . . . . 14 79 7.3. Operational Implications . . . . . . . . . . . . . . . . . 15 80 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 15 81 7.3.2. Authoritative DNS Server Operational Implications . . 16 82 7.3.3. DNS Recursive Resolver Server Operational 83 Implications . . . . . . . . . . . . . . . . . . . . . 16 84 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 17 85 7.3.5. Implications of Operational Momentum . . . . . . . . . 17 86 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 18 87 7.3.7. Additional Implications If Deployed On An Ad Hoc 88 Basis . . . . . . . . . . . . . . . . . . . . . . . . 18 89 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 18 90 7.5. Technology Policy Implications . . . . . . . . . . . . . . 19 91 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 20 92 8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 21 94 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 21 95 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 21 96 8.3.1. Solving Current End User IPv6 Impairments . . . . . . 21 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 98 9.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 22 99 9.2. Authoritative DNS Response Consistency Considerations . . 23 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 101 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 104 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 105 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 106 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 26 107 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 26 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 110 1. Introduction 112 This document describes the emerging practice of whitelisting of DNS 113 AAAA resource records (RRs), or DNS whitelisting for short. It also 114 explores the implications of this emerging practice are and what 115 alternatives may exist. 117 The practice of DNS whitelisting appears to have first been used by 118 major web content sites, such as Google's various websites. These 119 web site operators, or domain operators, observed that when they 120 added AAAA RRs to their authoritative DNS servers that a small 121 fraction of end users had slow or otherwise impaired access to a 122 given web site with both AAAA and A RRs. The fraction of users with 123 such impaired access has been estimated to be roughly 0.078% of total 124 Internet users [IETF 77 DNSOP WG Presentation] [Network World Article 125 on IETF 77 DNSOP WG Presentation]. Thus, in an example Internet 126 Service Provider (ISP) network of 10 million users, approximately 127 7,800 of those users may experience such impaired access. 129 As a result of this impairment affecting end users of a given domain, 130 a few large domains have begun to either implement DNS whitelisting 131 or strongly consider the implementation of DNS whitelisting [Network 132 World Article on DNS Whitelisting] [IPv6 Whitelist Operations]. When 133 implemented, DNS whitelisting in practice means that a domain's 134 authoritative DNS will return a AAAA RR to DNS recursive resolvers 135 [RFC1035] on the whitelist, while returning no AAAA RRs to DNS 136 resolvers which are not on the whitelist. It is important to note 137 that these web site operators are motivated to maintain a high- 138 quality user experience for all of their users, and that they are 139 attempting to shield users with impaired access from the symptoms of 140 these impairments that would negatively affect their access to 141 certain websites and related Internet resources. 143 However, critics of this emerging practice of DNS whitelisting have 144 articulated several concerns. Among these are that this is a very 145 different behavior from the current practice concerning the 146 publishing of IPv4 address records, that it may create a two-tiered 147 Internet, that policies concerning whitelisting and de-whitelisting 148 are opaque, that DNS whitelisting reduces interest in the deployment 149 of IPv6, that new operational and management burdens are created, and 150 that the costs and negative implications of DNS whitelisting outweigh 151 the perceived benefits as compared to fixing underlying impairments. 153 This document explores the reasons and motivations for DNS 154 whitelisting. It also explores the concerns regarding this emerging 155 practice. As a result, readers can hopefully better understand what 156 DNS whitelisting is, why some parties are implementing it, and why 157 other parties are critical of the practice. 159 2. How DNS Whitelisting Works 161 DNS whitelisting is implemented in authoritative DNS servers, where 162 those servers implement IP address-based restrictions on AAAA query 163 responses, which contain IPv6 addresses. In practice DNS 164 whitelisting has been primarily implemented by web server operators. 165 For a given operator of the website www.example.com, that operator 166 essentially applies an access control list (ACL) on their 167 authoritative DNS servers, which are authoritative for the domain 168 example.com. The ACL is then configured with the IPv4 and/or IPv6 169 addresses of DNS recursive resolvers on the Internet, which have been 170 authorized to be added to the ACL and to therefore receive AAAA RR 171 responses. These DNS recursive resolvers are operated by other 172 parties, such as ISPs, universities, governments, businesses, 173 individual end users, etc. If a DNS recursive resolver IS NOT on the 174 ACL, then NO AAAA RRs with IPv6 addresses will be sent in response to 175 a query for a given hostname in the example.com domain. However, if 176 a DNS recursive resolver IS on the ACL, then AAAA RRs with IPv6 177 addresses will be sent in response to a query for a given hostname in 178 the example.com domain. While these are not network-layer access 179 controls, they are nonetheless access controls that are a factor for 180 both end users and are directly related to the transition of one 181 network address family to another (IPv4 to IPv6). 183 In practice this generally means that a very small fraction of the 184 DNS recursive resolvers on the Internet can receive AAAA responses 185 with IPv6 addresses, which means that the large majority of DNS 186 resolvers on the Internet will receive only A RRs with IPv4 187 addresses. Thus, quite simply, the authoritative server hands out 188 different answers depending upon who is asking; with IPv4 and IPv6 189 records for some on the authorized whitelist, and only IPv4 records 190 for everyone else. See Figure 1 and Figure 2 for two different 191 visual descriptions of how this works in practice. 193 Finally, DNS whitelisting can be deployed in two primary ways: 194 universally on a global basis, or on an ad hoc basis. These two 195 potential deployment models are described in Section 5. 197 1: The authoritative DNS server for example.com receives a DNS 198 query for www.example.com, for which both A (IPv4) and AAAA 199 (IPv6) address records exist. 200 2: The authoritative DNS server examines the IP address of the DNS 201 recursive resolver sending the query. 202 3: The authoritative DNS server checks this IP address against the 203 access control list (ACL) that is the DNS whitelist. 204 4: If the DNS recursive resolver's IP address IS listed in the ACL, 205 then the response to that specific DNS recursive resolver can 206 contain both A (IPv4) and AAAA (IPv6) address records. 207 5: If the DNS recursive resolver's IP address IS NOT listed in the 208 ACL, then the response to that specific DNS recursive resolver 209 can contain only A (IPv4) address records and therefore cannot 210 contain AAAA (IPv6) address records. 212 Figure 1: DNS Whitelisting - System Logic 214 --------------------------------------------------------------------- 215 A query is sent from a DNS recursive resolver that IS NOT on the DNS 216 whitelist: 218 Request Request 219 www.example.com www.example.com 220 AAAA +-------------+ AAAA +-----------------+ 221 ++--++ ---------> | RESOLVER | ---------> | www.example.com | 222 || || A | **IS NOT** | A | IN A exists | 223 +-++--++-+ ---------> | ON | ---------> | IN AAAA exists | 224 +--------+ A | example.com | A | | 225 Host <--------- | WHITELIST | <--------- | | 226 Computer A Record +-------------+ A Record +-----------------+ 227 Response DNS Recursive Response example.com 228 (only IPv4) Resolver (only IPv4) Authoritative 229 #1 Server 230 --------------------------------------------------------------------- 231 A query is sent from a DNS recursive resolver that IS on the DNS 232 whitelist: 234 Request Request 235 www.example.com www.example.com 236 AAAA +-------------+ AAAA +-----------------+ 237 ++--++ ---------> | RESOLVER | ---------> | www.example.com | 238 || || A | **IS** | A | IN A exists | 239 +-++--++-+ ---------> | ON | ---------> | IN AAAA exists | 240 +--------+ AAAA | example.com | AAAA | | 241 Host <--------- | WHITELIST | <--------- | | 242 Computer A | | A | | 243 <--------- | | <--------- | | 244 A and AAAA +-------------+ A and AAAA +-----------------+ 245 Record DNS Recursive Record example.com 246 Responses Resolver Responses Authoritative 247 (IPv4+IPv6) #2 (IPv4+IPv6) Server 248 --------------------------------------------------------------------- 250 Figure 2: DNS Whitelisting - Functional Diagram 252 3. Concerns Regarding DNS Whitelisting 254 There are a number of potential implications relating to DNS 255 whitelisting, which have raised various concerns in some parts of the 256 Internet community. Many of those potential implications are 257 described in Section 7. 259 Some parties in the Internet community, including ISPs like Comcast, 260 are concerned that this emerging practice of DNS whitelisting for 261 IPv6 address records could represent a departure from the generally 262 accepted practices regarding IPv4 address records in the DNS on the 263 Internet [IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?]. 264 These parties explain their belief that for A records, containing 265 IPv4 addresses, once an authoritative server operator adds the A 266 record to the DNS, then any DNS recursive resolver on the Internet 267 can receive that A record in response to a query. By extension, this 268 means that any of the hosts connected to any of these DNS recursive 269 resolvers can receive the IPv4 address records for a given FQDN. 270 This enables new server hosts which are connected to the Internet, 271 and for which a fully qualified domain name (FQDN) such as 272 www.example.com has been added to the DNS with an IPv4 address 273 record, to be almost immediately reachable by any host on the 274 Internet. In this case, these new servers hosts become more and more 275 widely accessible as new networks and new end user hosts connect to 276 the Internet over time [EDITORIAL: consider reference to network 277 effects]. It also means that the new server hosts do not need to 278 know about these new networks and new end user hosts in order to make 279 their content and applications available to them, in essence that 280 each end in this end-to-end model is responsible for connecting to 281 the Internet and once they have done so they can connect to each 282 other without additional impediments or middle networks or 283 intervening networks or servers knowing about these end points and 284 whether one is allowed to contact the other. 286 In contrast, these parties are concerned that DNS whitelisting may 287 fundamentally change this model. As a result, in this altered end- 288 to-end model, one end (where the end user is located) cannot readily 289 connect to the other end (where the content is located), without 290 parts of the middle used by one end being known by the other end and 291 approved for access to that end. Thus, as new networks connect to 292 the Internet over time, those networks need to contact any and all 293 domains which have implemented DNS whitelisting in order to apply to 294 be added to their DNS whitelist, in the hopes of making the content 295 and applications residing on named server hosts in those domains 296 accessible by the end user hosts on that new network. Furthermore, 297 this same need to contact all domains implementing DNS whitelisting 298 also applies to all existing networks connected to the Internet. 300 Therefore, these concerned parties explain, whereas in the current 301 IPv4 Internet when a new server host is added to the Internet it is 302 widely available to all end user hosts and networks, when DNS 303 whitelisting of IPv6 records is used then these new server hosts are 304 not accessible to any end user hosts or networks until such time as 305 the operator of the authoritative DNS servers for those new server 306 hosts expressly authorizes access to those new server hosts by adding 307 DNS recursive resolvers around the Internet to the ACL. This could 308 represent a significant change in reachability of content and 309 applications by end users and networks as these end user hosts and 310 networks transition to IPv6. Therefore, a concern expressed is that 311 if much of the content that end users are most interested in is not 312 accessible as a result, then end users and/or networks may resist 313 adoption of IPv6 or actively seek alternatives to it, such as using 314 multi-layer network address translation (NAT) techniques like NAT444 315 [I-D.shirasaki-nat444] on a long-term basis. There is also concern 316 that this practice also could disrupt the continued increase in 317 Internet adoption by end users if they cannot simply access new 318 content and applications but must instead contact the operator of 319 their DNS recursive resolver, such as their ISP or another third 320 party, to have their DNS recursive resolver authorized for access to 321 the content or applications that interests them. Meanwhile, these 322 parties say, over 99.9% of all other end users that are also using 323 that same network or DNS recursive resolver are unable to access the 324 IPv6-based content, despite their experience being a positive one. 326 While in Section 1 the level of IPv6-related impairment has been 327 estimated to be as high as 0.078% of Internet users, which is a 328 primary motivation cited for the practice of DNS whitelisting, it is 329 not clear if the level of IPv4-related impairment is more or less 330 that this percentage (which in any case is likely to have declined 331 since its original citation). Indeed, as at least one document 332 reviewer has pointed out, it may simply be that websites are only 333 measuring IPv6 impairments and not IPv4 impairments, whether because 334 IPv6 is new or whether those websites are simply unable to or are 335 otherwise not in a position to be able to measure IPv4 impairment 336 (since this could result in no Internet access whatsoever). As a 337 result, it is worth considering that IPv4-related impairment could 338 exceed that of IPv6-related impairment and that such IPv4-related 339 impairment may have simply been accepted as "background noise" on the 340 Internet for a variety of reasons. 342 4. Similarities to Other DNS Operations 344 Some aspects of DNS whitelisting may be considered similar in some 345 ways to other common DNS operational techniques, which is explored 346 briefly below. 348 4.1. Similarities to Split DNS 350 DNS whitelisting has some similarities to so-called split DNS, which 351 is briefly described in Section 3.8 of [RFC2775]. When split DNS is 352 used, the authoritative DNS server returns different responses 353 depending upon what host has sent the query. While [RFC2775] notes 354 the typical use of split DNS is to provide one answer to hosts on an 355 Intranet and a different answer to hosts on the Internet, the essence 356 is that different answers are provided to hosts on different 357 networks. This is basically the way that DNS whitelisting works, in 358 so far as hosts of different networks, which use different DNS 359 recursive resolvers, receive different answers if one DNS recursive 360 resolver is on the whitelist and the other is not. Thus, in a way, 361 DNS whitelisting could in some ways be considered split DNS on the 362 public Internet, though with some differences. 364 In [RFC2956], Internet transparency and Internet fragmentation 365 concerns regarding split DNS are detailed in Section 2.1. [RFC2956] 366 further notes in Section 2.7, concerns regarding split DNS and that 367 it "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint 368 identifiers more complex." Section 3.5 of [RFC2956] further 369 recommends that maintaining a stable approach to DNS operations is 370 key during transitions such as the one to IPv6 that is underway now, 371 stating that "Operational stability of DNS is paramount, especially 372 during a transition of the network layer, and both IPv6 and some 373 network address translation techniques place a heavier burden on 374 DNS." 376 4.2. Similarities to DNS Load Balancing 378 DNS whitelisting also has some similarities to DNS load balancing. 379 There are many ways that DNS load balancing can be performed, and of 380 course this can mean many things to different people. In one 381 example, multiple IP address resource records (A or AAAA) can be 382 added to the DNS to resolve a given FQDN, which is referred to as DNS 383 round robin [REFERENCE AVAILABLE?]. In another example, one or more 384 of the IP address resource records in the DNS will direct traffic to 385 a load balancer [REFERENCE AVAILABLE?]. That load balancer, in turn, 386 may be application-aware, and pass the traffic on to one or more 387 hosts connected to the load balancer which have different IP 388 addresses. In cases where private IPv4 addresses are used [RFC1918], 389 as well as when public IP addresses are used, those end hosts may not 390 be directly reachable without passing through the load balancer first 391 . As such, while the IP address resource records have been added to 392 the DNS, the end hosts are not necessarily directly reachable, which 393 is in a small way similar to one aspect of DNS whitelisting. In 394 addition, a geographically-aware authoritative DNS server may be 395 used, as is common with Content Delivery Networks (CDNs), whereby the 396 IP address resource records returned to a resolver in response to a 397 query will vary based on the estimated geographic location of the 398 resolver [REFERENCE AVAILABLE?]. CDNs perform this function in order 399 to attempt to direct hosts to connect to the nearest content cache. 400 As a result, one can see some similarities with DNS whitelisting 401 insofar as different IP address resource records are returned to 402 resolvers based on the IP address of each resolver (or other imputed 403 factors related to that IP address). However, what is different of 404 course, if that in this case the resolvers are not necessarily 405 blocked from receiving DNS responses containing an entire class of 406 addresses; this load balancing function strives to perform a content 407 location-improvement function and not an access control function. 409 5. Likely Deployment Scenarios 411 In considering how DNS whitelisting may emerge more widely, there are 412 two likely deployment scenarios, which are explored below. 414 In either of these likely deployment scenarios below, it is possible 415 that reputable third parties could create and maintain these DNS 416 whitelists, in much the same way that blacklists are used for 417 reducing email spam. In this email example, a mail operator 418 subscribes to one or more of these lists and as such the operational 419 processes for additions and deletions to the list are managed by a 420 third party. Thus, a similar model could emerge for DNS 421 whitelisting, whether deployment occurs universally or on an ad hoc 422 basis. 424 5.1. Deploying DNS Whitelisting Universally 426 The least likely deployment scenario is one where DNS whitelisting 427 becomes a standardized process across all authoritative DNS servers, 428 across the entire Internet. While this scenario is the least likely, 429 due to some parties not sharing the concerns that have so far 430 motivated the use of DNS whitelisting, it is nonetheless conceivable 431 that it could be one of the ways in which DNS whitelisting may be 432 deployed. 434 In order for this deployment scenario to occur, it is likely that DNS 435 whitelisting functionality would need to be built into all 436 authoritative DNS server software, and that all operators of 437 authoritative DNS servers would have to upgrade their software and 438 enable this functionality. Furthermore, it is likely that new 439 Internet Draft documents would need to be developed which describe 440 how to properly configure, deploy, and maintain DNS whitelisting. As 441 a result, it is unlikely that DNS whitelisting would, at least in the 442 next several years, become universally deployed. Furthermore, these 443 DNS whitelists are likely to vary on a domain-by-domain basis, 444 depending upon a variety of factors. Such factors may include the 445 motivation of each domain owner, the location of the DNS recursive 446 resolvers in relation to the source content, as well as various other 447 parameters that may be transitory in nature, or unique to a specific 448 end user host type. Thus, it is probably unlikely that a single 449 clearinghouse for managing whitelisting is possible; it will more 450 likely be unique to the source content owners and/or domains which 451 implement DNS whitelists. 453 While this scenario may be unlikely, it may carry some benefits. 454 First, parties performing troubleshooting would not have to determine 455 whether or not DNS whitelisting was being used, as it always would be 456 in use. In addition, if universally deployed, it is possible that 457 the criteria for being added to or removed from a DNS whitelist could 458 be standardized across the entire Internet. Nevertheless, even if 459 uniform DNS whitelisting policies were not standardized, is also 460 possible that a central registry of these policies could be developed 461 and deployed in order to make it easier to discover them, a key part 462 of achieving transparency regarding DNS whitelisting. 464 5.2. Deploying DNS Whitelisting On An Ad Hoc Basis 466 This is the most likely deployment scenario for DNS whitelisting, as 467 it seems today, is where some interested parties engage in DNS 468 whitelisting but many or most others do not do so. What can make 469 this scenario challenging from the standpoint of a DNS recursive 470 resolver operator is determining which domains implement DNS 471 whitelisting, particularly since a domain may not do so as they 472 initially transition to IPv6, and may instead do so later. Thus, a 473 DNS recursive resolver operator may initially believe that they can 474 receive AAAA responses with IPv6 addresses as a domain adopts IPv6, 475 but then notices via end user reports that they no longer receive 476 AAAA responses due to that site adopting DNS whitelisting. 478 Thus, in contrast to universal deployment of DNS whitelisting, 479 deployment on an ad hoc basis is likely to be significantly more 480 challenging from an operational, monitoring, and troubleshooting 481 standpoint. In this scenario, a DNS recursive resolver operator will 482 have no way to systematically determine whether DNS whitelisting is 483 or is not implemented for a domain, since the absence of AAAA records 484 with IPv6 addresses may simply be indicative that the domain has not 485 yet added IPv6 addressing for the domain, not that they have done so 486 but have restricted query access via DNS whitelisting. As a result, 487 discovering which domains implement DNS whitelisting, in order to 488 differentiate them from those that do not, is likely to be 489 challenging. 491 On the other hand, one benefit of DNS whitelisting being deployed on 492 an ad hoc basis is that only the domains that are interested in doing 493 so would have to upgrade their authoritative DNS servers in order to 494 implement the ACLs necessary to perform DNS whitelisting. 496 6. What Problems Are DNS Whitelisting Implementers Trying To Solve? 498 As noted in Section 1, domains which implement DNS whitelisting are 499 attempting to protect a few users of their domain, which happen to 500 have impaired IPv6 access, from having a negative end user 501 experience. While it is outside the scope of this document to 502 explore the various reasons why a particular user may experience 503 impaired IPv6 access, for the users which experience this it is a 504 very real effect and would of course affect access to all or most 505 IPv4 and IPv6 dual stack servers. This negative end user experience 506 can range from someone slower than usual (as compared to native IPv4- 507 based access), to extremely slow, to no access to the domain 508 whatsoever. 510 Thus, parties which implement DNS whitelisting are attempting to 511 provide a good experience to these end users. While one can debate 512 whether DNS whitelisting is the optimal solution, it is quite clear 513 that DNS whitelisting implementers are extremely interested in the 514 performance of their services for end users as a primary motivation. 516 In addition, Google has noted that they have received requests to not 517 send DNS responses with AAAA resource records to particular 518 resolvers. In these cases, the operators of those recursive 519 resolvers have expressed a concern that their IPv6 network 520 infrastructure is not yet ready to handle the traffic volume which 521 may be associated with the hosts in their network connecting to 522 Google websites, such as YouTube. In this case, this is clearly a 523 temporary concern relating to the deployment of IP network 524 infrastructure on the part of networks with end user hosts, rather 525 than a long-term concern. These end user networks may also have 526 other tools at their disposal in order to address this, including 527 applying rules to network equipment such as routers and firewalls 528 (this will necessarily vary by the type of network, as well as the 529 technologies used and the design of a given network). 531 7. Implications of DNS Whitelisting 533 There are many potential implications of DNS whitelisting. In the 534 sections below, the key potential implications are listed in some 535 detail. 537 7.1. Architectural Implications 539 DNS whitelisting could be perceived as somewhat modifying the end-to- 540 end model and/or the general notion of the architecture that prevails 541 on the Internet today. This is because this approach moves 542 additional access control information and policies into the middle of 543 the DNS resolution path on the IPv6-addressed Internet, which did not 544 exist before on the IPv4-addressed Internet. This could raise some 545 risks noted in [RFC3724], which in explaining the history of the end- 546 to-end principle [RFC1958] explains that one of the goals is to 547 minimize the state, policies, and other functions needed in the 548 middle of the network in order to enable end-to-end communications on 549 the Internet. In this case, the middle network should be understood 550 to mean anything other than the end hosts involved in communicating 551 with one another. Obviously some state, policies, and other 552 functions have always been necessary to enable such end-to-end 553 communication, but the goal of the approach has been to minimize this 554 to the greatest extent possible. 556 It is also possible that DNS whitelisting could place at risk some of 557 the benefits of the end-to-end principle, as listed in Section 4.1 of 558 [RFC3724], such as protection of innovation. Further, while 559 [RFC3234] details issues and concerns regarding so-called 560 middleboxes, there may be parallels to DNS whitelisting, especially 561 concerning modified DNS servers noted in Section 2.16 of [RFC3234], 562 and more general concerns noted in Section 1.2 of [RFC3234] about the 563 introduction of new failure modes, that configuration is no longer 564 limited to two ends of a session, and that diagnosis of failures and 565 misconfigurations is more complex. 567 In [Tussle in Cyberspace], the authors note concerns regarding the 568 introduction of new control points, as well as "kludges" to the DNS, 569 as risks to the goal of network transparency in the end-to-end model. 570 Some parties concerned with the emerging use of DNS whitelisting have 571 shared similar concerns, which may make [Tussle in Cyberspace] an 572 interesting and relevant document. In addition, [Rethinking the 573 design of the Internet] reviews similar issues that may be of 574 interest to readers of this document. 576 In order to explore and better understand these high-level 577 architectural implications and concerns in more detail, the following 578 sections explore more specific potential implications. 580 7.2. Public IPv6 Address Reachability Implications 582 The predominant experience of end user hosts and servers on the IPv4- 583 addressed Internet today is that, very generally speaking, when a new 584 server with a public IPv4 address is added, that it is then globally 585 accessible by IPv4-addressed hosts. Of course, this is a 586 generalization and in Section 4 there are examples of common cases 587 where this may not necessarily be the case. In any case, for the 588 purposes of this document, that concept of accessibility can be 589 considered "pervasive reachability". It has so far been assumed that 590 the same expectations of pervasive reachability would exist in the 591 IPv6-addressed Internet. However, if DNS whitelisting is deployed, 592 this will not be the case since only end user hosts using DNS 593 recursive resolvers which have been added to the ACL of a given 594 domain using DNS whitelisting would be able to reach new servers in 595 that given domain via IPv6 addresses. Thus, the expectation of any 596 end user host being able to connect to any server (essentially both 597 hosts, just at either end of the network), defined here as "pervasive 598 reachability", will change to "restricted reachability" with IPv6. 600 In addition, establishing DNS whitelisting as an accepted practice in 601 the early phases of mass IPv6 deployment could well establish DNS 602 whitelisting as an integral part of how IPv6 is deployed globally. 603 As a result, it is then possible that DNS whitelisting could live on 604 for decades on the Internet as a key foundational element of the 605 Internet of the future that we will all live with for a long time. 607 However, it is a critical to understand that the concept of 608 reachability described above depends upon a knowledge or awareness of 609 an address in the DNS. Thus, in order to establish reachability to 610 an end point, a host is dependent upon looking up an IP address in 611 the DNS when a FQDN is used. Thus, when DNS whitelisting is used, it 612 is quite likely the case that a end user host could ping a example 613 server host, even though the FQDN associated with that server host is 614 restricted via a DNS whitelist. But since most Internet applications 615 and hosts such as web servers depend upon the DNS, and as end users 616 connect to FQDNs such as www.example.com and do not remember or wish 617 to type in an IP address, the notion of reachability described here 618 should be understood to include knowledge how to associate a name 619 with a network address. 621 7.3. Operational Implications 623 This section explores some of the operationally related implications 624 which may occur as a result of, related to, or necessary when 625 engaging in the practice of DNS whitelisting. 627 7.3.1. De-Whitelisting May Occur 629 If it is possible for a DNS recursive resolver to be added to a 630 whitelist, then it is also possible for that resolver to be removed 631 from the whitelist, also known as de-whitelisting. Since de- 632 whitelisting can occur, whether through a decision by the 633 authoritative server operator or the domain owner, or even due to a 634 technical error, an operator of a DNS recursive resolver will have 635 new operational and monitoring requirements and/or needs as noted in 636 Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5. 638 7.3.2. Authoritative DNS Server Operational Implications 640 Operators of authoritative servers may need to maintain an ACL a 641 server-wide basis affecting all domains, on a domain-by-domain basis, 642 as well as on a combination of the two. As a result, operational 643 practices and software capabilities may need to be developed in order 644 to support such functionality. In addition, processes may need to be 645 put in place to protect against inadvertently adding or removing IP 646 addresses, as well as systems and/or processes to respond to such 647 incidents if and when they occur. For example, a system may be 648 needed to record DNS whitelisting requests, report on their status 649 along a workflow, add IP addresses when whitelisting has been 650 approved, remove IP addresses when they have been de-whitelisted, log 651 the personnel involved and timing of changes, schedule changes to 652 occur in the future, and to roll back any inadvertent changes. 654 Such operators may also need implement new forms of monitoring in 655 order to apply change control, as noted briefly in Section 7.3.4. 657 7.3.3. DNS Recursive Resolver Server Operational Implications 659 Operators of DNS recursive resolvers, which may include ISPs, 660 enterprises, universities, governments, individual end users, and 661 many other parties, are likely to need to implement new forms of 662 monitoring, as noted briefly in Section 7.3.4. But more critically, 663 such operators may need to add people, processes, and systems in 664 order to manage countless DNS whitelisting applications, for all 665 domains that the end users of such servers are interested in now or 666 in which they may be interested in the future. As such anticipation 667 of interesting domains is likely infeasible, it is more likely that 668 such operators may either choose to only apply to be whitelisted for 669 a domain based upon one or more end user requests, or that they will 670 attempt to do so for all domains. 672 When such operators apply for DNS whitelisting for all domains, that 673 may mean doing so for all registered domains. Thus, some system 674 would have to be developed to discover whether each domain has been 675 whitelisted or not, which is touched on in Section 5 and may vary 676 depending upon whether DNS whitelisting is universally deployed or is 677 deployed on an ad hoc basis. 679 Furthermore, these operators will need to develop processes and 680 systems to track the status of all DNS whitelisting applications, 681 respond to requests for additional information related to these 682 applications, determine when and if applications have been denied, 683 manage appeals, and track any de-whitelisting actions. Given the 684 incredible number of domains in existence, the ease with which a new 685 domain can be added, and the continued strong growth in the numbers 686 of new domains, readers should not underestimate the potential 687 significance in personnel and expense that this could represent for 688 such operators. In addition, it is likely that systems and personnel 689 may also be needed to handle new end user requests for domains for 690 which to apply for DNS whitelisting, and/or inquiries into the status 691 of a whitelisting application, reports of de-whitelisting incidents, 692 general inquiries related to DNS whitelisting, and requests for DNS 693 whitelisting-related troubleshooting by these end users. 695 7.3.4. Monitoring Implications 697 Once a DNS recursive resolver has been whitelisted for a particular 698 domain, then the operator of that DNS recursive resolver may need to 699 implement monitoring in order to detect the possible loss of 700 whitelisting status in the future. This DNS recursive resolver 701 operator could configure a monitor to check for a AAAA response in 702 the whitelisted domain, as a check to validate continued status on 703 the DNS whitelist. The monitor could then trigger an alert if at 704 some point the AAAA responses were no longer received, so that 705 operations personnel could begin troubleshooting, as outlined in 706 Section 7.3.6. 708 Also, authoritative DNS server operators are likely to need to 709 implement new forms of monitoring. In this case, they may desire to 710 monitor for significant changes in the size of the whitelist within a 711 certain period of time, which might be indicative of a technical 712 error such as the entire ACL being removed. These operators may also 713 wish to monitor their workflow process for reviewing and acting upon 714 DNS whitelisting applications and appeals, potentially measuring and 715 reporting on service level commitments regarding the time an 716 application or appeal can remain at each step of the process, 717 regardless of whether or not such information is shared with parties 718 other than that authoritative DNS server operator. 720 These are but a few examples of the types of monitoring that may be 721 called for as a result of DNS whitelisting, among what are likely 722 many other types and variations. 724 7.3.5. Implications of Operational Momentum 726 It seems plausible that once DNS whitelisting is implemented it will 727 be very difficult to deprecate such technical and operational 728 practices. This assumption is based in an understanding of human 729 nature, not to mention physics. For example, as Sir Issac Newton 730 noted, "Every object in a state of uniform motion tends to remain in 731 that state of motion unless an external force is applied to it" 732 [Newton's Laws of Motion]. Thus, once DNS whitelisting is 733 implemented it is quite likely that it would take considerable effort 734 to deprecate the practice and remove it everywhere on the Internet - 735 it will otherwise simply remain in place in perpetuity. To better 736 illustrate this point, one could consider in one example (of many) 737 that here are likely many email servers continuing to attempt to 738 query or otherwise check anti-spam DNS blocklists which have long ago 739 ceased to exist. 741 7.3.6. Troubleshooting Implications 743 The implications of DNS whitelisted present many challenges, which 744 have been detailed in Section 7. These challenges may negatively 745 affect the end users' ability to troubleshoot, as well as that of DNS 746 recursive resolver operators, ISPs, content providers, domain owners 747 (where they may be different from the operator of the authoritative 748 DNS server for their domain), and other third parties. This may make 749 the process of determining why a server is not reachable 750 significantly more complex. 752 7.3.7. Additional Implications If Deployed On An Ad Hoc Basis 754 Additional implications, should this be deployed on an ad hoc basis, 755 could include scalability problems relating to operational processes, 756 monitoring, and ACL updates. In particular, it seems quite likely 757 that as the number of domains that are whitelisted increases, as well 758 as the number of IPv6-capable networks requesting to be whitelisted, 759 that there is an increased likelihood of configuration and other 760 operational errors, especially with respect to the ACLs themselves. 761 It is also unclear when and if it would be appropriate to change from 762 whitelisting to blacklisting, and whether/how this could feasibly be 763 coordinated across the Internet, which may be proposed when a 764 majority of networks (or allocated IPv6 address blocks) have been 765 whitelisted. Finally, some parties implementing DNS whitelisting 766 consider this to be a temporary measure. As such, it is not clear 767 how these parties will judge the network conditions to have changed 768 sufficiently to justify disabling DNS whitelisting and/or what the 769 process and timing will be in order to turn off and stop this 770 practice. 772 7.4. Homogeneity May Be Encouraged 774 A broad trend which has existed on the Internet appears to be a move 775 towards increasing levels of heterogeneity. One manifestation of 776 this is in an increasing number, variety, and customization of end 777 user hosts, including home network, operating systems, client 778 software, home network devices, and personal computing devices. This 779 trend appears to have had a positive effect on the development and 780 growth of the Internet. A key facet of this that has evolved is the 781 ability of the end user to connect any technically compliant device 782 or use any technically compatible software to connect to the 783 Internet. Not only does this trend towards greater heterogeneity 784 reduce the control which is exerted in the middle of the network, 785 described in positive terms in [Tussle in Cyberspace], [Rethinking 786 the design of the Internet], and [RFC3724], but it can also help to 787 enable greater and more rapid innovation at the edges. 789 An unfortunate implication of the adoption of DNS whitelisting may be 790 the encouragement of a reversal of this trend, which would be a move 791 back towards greater levels of homogeneity. In this case, a domain 792 owner which has implemented DNS whitelisting may prefer greater 793 levels of control be exerted over end user hosts (which broadly 794 includes all types of end user software and hardware) in order to 795 attempt to enforce technical standards relating to establishing 796 certain IPv6 capabilities or the enforcing the elimination of or 797 restriction of certain end user hosts. While the domain operator is 798 attempting to protect, maintain, and/or optimize the end user 799 experience for their domain, the collective result of many domains 800 implementing DNS whitelisting, or even a few major domains (meaning 801 domains which are a major destination of Internet traffic) 802 implementing DNS whitelisting, may be to encourage a return to more 803 homogenous and/or controlled end user hosts. Unfortunately, this 804 could have unintended side effects on and counter-productive 805 implications for future innovation at the edges of the network. 807 7.5. Technology Policy Implications 809 A key technology policy implication concerns the policies relating to 810 the process of reviewing an application for DNS whitelisting, and the 811 decision-making process regarding whitelisting for a domain. 812 Important questions may include whether these policies have been 813 fully and transparently disclosed, are non-discriminatory, and are 814 not anti-competitive. A related implication is whether and what the 815 process for appeals is, when a domain decides not to add a DNS 816 recursive resolver to the whitelist. Key questions here may include 817 whether appeals are allowed, what the process is, what the expected 818 turn around time is, and whether the appeal will be handled by an 819 independent third party or other entity/group. 821 A further implications arises when de-whitelisting occurs. Questions 822 that may naturally be raised in such a case include whether the 823 criteria for de-whitelisting have been fully and transparently 824 disclosed, are non-discriminatory, and are not anti-competitive. 825 Additionally, the question of whether or not there was a cure period 826 available prior to de-whitelisting, during which troubleshooting 827 activities, complaint response work, and corrective actions may be 828 attempted, and whether this cure period was a reasonable amount of 829 time. 831 It is also conceivable that whitelisting and de-whitelisting 832 decisions could be quite sensitive to concerned parties beyond the 833 operator of the domain which has implemented DNS whitelisting and the 834 operator of the DNS recursive resolver, including end users, 835 application developers, content providers, advertisers, public policy 836 groups, governments, and other entities, which may also seek to 837 become involved in or express opinions concerning whitelisting and/or 838 de-whitelisting decisions. Lastly, it is conceivable that any of 839 these interested parties or other related stakeholders may seek 840 redress outside of the process a domain has establishing for DNS 841 whitelisting and de-whitelisting. 843 A final concern is that decisions relating to whitelisting and de- 844 whitelisting may occur as an expression of other commercial, 845 governmental, and/or cultural conflicts, given the new control point 846 which has be established with DNS whitelisting. For example, in one 847 imagined scenario, a domain could withhold adding a network to their 848 DNS whitelisting unless that network agreed to some sort of financial 849 payment, legal agreement, agreement to sever a relationship with a 850 competitor of the domain, etc. In another example, a music-oriented 851 domain may be engaged in some sort of dispute with an academic 852 network concerning copyright infringement concerns within that 853 network, and may choose to de-whitelist that network as a negotiating 854 technique in some sort of commercial discussion. In a final example, 855 a major email domain may choose to de-whitelist a network due to that 856 network sending some large volume of spam, which would have the 857 effect of preventing other, end users on that network from using 858 other, non-email-related applications within that domain. Thus, it 859 seems possible that DNS whitelisting and de-whitelisting could become 860 a vehicle for adjudicating other disputes, and that this may well 861 have intended and unintended consequences for end users which are 862 affected by such decisions and are unlikely to be able to express a 863 strong voice in such decisions. 865 7.6. IPv6 Adoption Implications 867 As noted in Section 3, the implications of DNS whitelisting may drive 868 end users and/or networks to delay, postpone, or cancel adoption of 869 IPv6, or to actively seek alternatives to it. Such alternatives may 870 include the use of multi-layer network address translation (NAT) 871 techniques like NAT444 [I-D.shirasaki-nat444], which these parties 872 may decide to pursue on a long-term basis to avoid the perceived 873 costs and aggravations related to DNS whitelisting. This could of 874 course come at the very time that the Internet community is trying to 875 get these very same parties interested in IPv6 and motivated to begin 876 the transition to IPv6. As a result, parties that are likely to be 877 concerned over the negative implications of DNS whitelisting could 878 logically be concerned of the negative effects that this practice 879 could have on the adoption of IPv6 if it became widespread or was 880 adopted by majors Internet domains or other major parties in the 881 Internet ecosystem. 883 8. Solutions 885 This section outline several possible solutions when considering DNS 886 whitelisting and associated IPv6-related issues. 888 8.1. Implement DNS Whitelisting Universally 890 One obvious solution is to implement DNS whitelisted universally, and 891 to do so using some sort of centralized registry of DNS whitelisting 892 policies, contracts, processes, or other information. This potential 893 solution seems unlikely at the current time. 895 8.2. Implement DNS Whitelisting On An Ad Hoc Basis 897 If DNS whitelisting was to be adopted, it is likely to be adopted on 898 this ad hoc, or domain-by-domain basis. Therefore, only those 899 domains interested in DNS whitelisting would need to adopt the 900 practice, though as noted herein discovering that they a given domain 901 has done so may be problematic. Also in this scenario, ad hoc use by 902 a particular domain may also be a temporary measure that has been 903 adopted to ease the transition of the domain to IPv6 over some short- 904 term timeframe. 906 8.3. Do Not Implement DNS Whitelisting 908 As an alternative to adopting DNS whitelisting, the Internet 909 community can instead choose to take no action whatsoever, 910 perpetuating the current predominant authoritative DNS operational 911 model on the Internet, and leave it up to end users with IPv6-related 912 impairments to discover and fix those impairments. 914 8.3.1. Solving Current End User IPv6 Impairments 916 A further extension of not implementing DNS whitelisting, is to also 917 endeavor to actually fix the underlying technical problems that have 918 prompted the consideration of DNS whitelisting in the first place, as 919 an alternative to trying to apply temporary workarounds to avoid the 920 symptoms of underlying end user IPv6 impairments. A first step is 921 obviously to identify which users have such impairments, which would 922 appear to be possible, and then to communicate this information to 923 end users. Such end user communication is likely to be most helpful 924 if the end user is not only alerted to a potential problem but is 925 given careful and detailed advice on how to resolve this on their 926 own, or where they can seek help in doing so. 928 One challenge with this option is the potential difficulty of 929 motivating members of the Internet community to work collectively 930 towards this goal, sharing the labor, time, and costs related to such 931 an effort. Of course, since just such a community effort is now 932 underway for IPv6, it is possible that this would call for only a 933 moderate amount of additional work. 935 Despite any potential challenges, many in the Internet community are 936 already working towards this goal and/or have expressed a preference 937 for this approach. 939 9. Security Considerations 941 There are no particular security considerations if DNS whitelisting 942 is not adopted, as this is how the public Internet works today with A 943 records. 945 However, if DNS whitelisting is adopted, organizations which apply 946 DNS whitelisting policies in their authoritative servers should have 947 procedures and systems which do not allow unauthorized parties to 948 either remove whitelisted DNS resolvers from the whitelist or add 949 non-whitelisted DNS resolvers to the whitelist. Should such 950 unauthorized additions or removals from the whitelist can be quite 951 damaging, and result in content providers and/or ISPs to incur 952 substantial support costs resulting from end user and/or customer 953 contacts. As such, great care must be taken to control access to the 954 whitelist for an authoritative server. 956 In addition, two other key security-related issues should be taken 957 into consideration: 959 9.1. DNSSEC Considerations 961 DNS security extensions defined in [RFC4033], [RFC4034], and 962 [RFC4035] use cryptographic digital signatures to provide origin 963 authentication and integrity assurance for DNS data. This is done by 964 creating signatures for DNS data on a Security-Aware Authoritative 965 Name Server that can be used by Security-Aware Resolvers to verify 966 the answers. Since DNS whitelisting is implemented on an 967 authoritative server, which provides different answers depending upon 968 which resolver server has sent a query, the DNSSEC chain of trust is 969 not altered. Therefore there are no DNSSEC implications per se. 970 However, any implementer of DNS whitelisting should be quite careful 971 if they implement both DNSSEC signing of their domain and also DNS 972 whitelisting of that same domain. Specifically, those domains should 973 ensure that records are being appropriately and reliably signed, 974 which may well prove operationally and/or technically challenging. 976 9.2. Authoritative DNS Response Consistency Considerations 978 In addition to the considerations raised in Section 9.1, it is 979 conceivable that security concerns may arise when end users or other 980 parties notice that the responses sent from an authoritative DNS 981 server appear to vary from one network or one DNS recursive resolver 982 to another. This may give rise to concerns that, since the 983 authoritative responses vary that there is some sort of security 984 issue and/or some or none of the responses can be trusted. While 985 this may seem a somewhat obscure concern, domains nonetheless may 986 wish to consider this when contemplating whether or not to pursue DNS 987 whitelisting. 989 10. IANA Considerations 991 There are no IANA considerations in this document. 993 11. Contributors 995 The following people made significant textual contributions to this 996 document and/or played an important role in the development and 997 evolution of this document: 999 - John Brzozowski 1001 - Chris Griffiths 1003 - Tom Klieber 1005 - Yiu Lee 1007 - Rich Woundy 1009 12. Acknowledgements 1011 The author and contributors also wish to acknowledge the assistance 1012 of the following individuals. Some of these people provided helpful 1013 and important guidance in the development of this document and/or in 1014 the development of the concepts covered in this document. Other 1015 people assisted by performing a detailed review of this document, and 1016 then providing feedback and constructive criticism for revisions to 1017 this document. All of this was helpful and therefore the following 1018 individuals merit acknowledgement: 1020 - Bernard Aboba 1022 - Frank Bulk 1024 - Brian Carpenter 1026 - Wesley George 1028 - Erik Kline 1030 - Danny McPherson 1032 - Hannes Tschofenig 1034 13. References 1036 13.1. Normative References 1038 [RFC1035] Mockapetris, P., "Domain names - implementation and 1039 specification", STD 13, RFC 1035, November 1987. 1041 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1042 E. Lear, "Address Allocation for Private Internets", 1043 BCP 5, RFC 1918, February 1996. 1045 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 1046 RFC 1958, June 1996. 1048 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1049 February 2000. 1051 [RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", 1052 RFC 2956, October 2000. 1054 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1055 Issues", RFC 3234, February 2002. 1057 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 1058 and the Future of End-to-End: Reflections on the Evolution 1059 of the Internet Architecture", RFC 3724, March 2004. 1061 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1062 Rose, "DNS Security Introduction and Requirements", 1063 RFC 4033, March 2005. 1065 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1066 Rose, "Resource Records for the DNS Security Extensions", 1067 RFC 4034, March 2005. 1069 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1070 Rose, "Protocol Modifications for the DNS Security 1071 Extensions", RFC 4035, March 2005. 1073 13.2. Informative References 1075 [I-D.shirasaki-nat444] 1076 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 1077 and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work 1078 in progress), January 2011. 1080 [IETF 77 DNSOP WG Presentation] 1081 Gashinsky, I., "IPv6 & recursive resolvers: How do we make 1082 the transition less painful?", IETF 77 DNS Operations 1083 Working Group, March 2010, 1084 . 1086 [IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?] 1087 Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y., 1088 Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting - 1089 Could It Hinder IPv6 Adoption?", ISOC Internet Society 1090 IPv6 Deployment Workshop, April 2010, . 1094 [IPv6 Whitelist Operations] 1095 Kline, E., "IPv6 Whitelist Operations", Google Google IPv6 1096 Implementors Conference, June 2010, . 1100 [Network World Article on DNS Whitelisting] 1101 Marsan, C., "Google, Microsoft, Netflix in talks to create 1102 shared list of IPv6 users", Network World , March 2010, . 1106 [Network World Article on IETF 77 DNSOP WG Presentation] 1107 Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", 1108 Network World , March 2010, . 1111 [Newton's Laws of Motion] 1112 Newton, I., "Mathematical Principles of Natural Philosophy 1113 (Philosophiae Naturalis Principia Mathematica)", 1114 Principia Mathematical Principles of Natural Philosophy 1115 (Philosophiae Naturalis Principia Mathematica), July 1687, 1116 . 1118 [Rethinking the design of the Internet] 1119 Blumenthal, M. and D. Clark, "Rethinking the design of the 1120 Internet: The end to end arguments vs. the brave new 1121 world", ACM Transactions on Internet Technology Volume 1, 1122 Number 1, Pages 70-109, August 2001, . 1126 [Tussle in Cyberspace] 1127 Braden, R., Clark, D., Sollins, K., and J. Wroclawski, 1128 "Tussle in Cyberspace: Defining Tomorrow's Internet", 1129 Proceedings of ACM Sigcomm 2002, August 2002, . 1133 Appendix A. Document Change Log 1135 [RFC Editor: This section is to be removed before publication] 1137 -01: Incorporated feedback received from Brian Carpenter (from 10/19/ 1138 2010), Frank Bulk (from 11/8/2010), and Erik Kline (from 10/1/2010). 1139 Also added an informative reference at the suggestion of Wes George 1140 (from from 10/22/2010). Closed out numerous editorial notes, and 1141 made a variety of other changes. 1143 -00: First version published as a v6ops WG draft. The preceding 1144 individual draft was 1145 draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE 1146 that no changes have been made yet based on WG and list feedback. 1147 These are in queue for a -01 update. 1149 Appendix B. Open Issues 1151 [RFC Editor: This section is to be removed before publication] 1153 1. Close the issues below and any feedback from the v6ops and dnsop 1154 mailing lists in a -02 update, then request WGLC 1156 2. Perform an second review of notes from IETF 79 to ensure that all 1157 feedback received then has been fully taken into account! 1159 3. Add any good references throughout the document - posed in 1160 question to v6ops 1162 4. Ensure references are in the proper section (normative/ 1163 informative) 1165 5. Include a number of references from RFC3724? 1167 6. Add brokenness reference to 1168 http://ripe61.ripe.net/presentations/162-ripe61.pdf 1170 7. Should I include a full list or other details of the root causes 1171 of IPv6 brokenness? - posed in question to v6ops 1173 Author's Address 1175 Jason Livingood 1176 Comcast Cable Communications 1177 One Comcast Center 1178 1701 John F. Kennedy Boulevard 1179 Philadelphia, PA 19103 1180 US 1182 Email: jason_livingood@cable.comcast.com 1183 URI: http://www.comcast.com