idnits 2.17.1 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07.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 date (October 14, 2011) is 4578 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 October 14, 2011 5 Expires: April 16, 2012 7 Considerations for Transitioning Content to IPv6 8 draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07 10 Abstract 12 This document describes considerations for the transition of end user 13 content on the Internet to IPv6. While this is tailored to address 14 end user content, which is typically web-based, many aspects of this 15 document may be more broadly applicable to the transition to IPv6 of 16 other applications and services. This document explores the 17 challenges involved in the transition to IPv6, potential transition 18 techniques, possible transition phases, and other considerations. 19 The audience for this document is the Internet community generally, 20 particularly IPv6 implementers. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 16, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Challenges When Transitioning Content to IPv6 . . . . . . . . 4 58 2.1. IPv6-Related Impairment . . . . . . . . . . . . . . . . . 5 59 2.2. Operational Maturity Concerns . . . . . . . . . . . . . . 5 60 2.3. Volume-Based Concerns . . . . . . . . . . . . . . . . . . 5 61 3. IPv6 Adoption Implications . . . . . . . . . . . . . . . . . . 6 62 4. Potential Transition Techniques . . . . . . . . . . . . . . . 6 63 4.1. Solve Current End User IPv6 Impairments . . . . . . . . . 7 64 4.2. Use IPv6 Transition Names . . . . . . . . . . . . . . . . 8 65 4.3. Implement DNS Resolver Whitelisting . . . . . . . . . . . 8 66 4.3.1. How DNS Resolver Whitelisting Works . . . . . . . . . 10 67 4.3.2. Similarities to Content Delivery Networks and 68 Global Server Load Balancing . . . . . . . . . . . . . 14 69 4.3.3. Similarities to DNS Load Balancing . . . . . . . . . . 14 70 4.3.4. Similarities to Split DNS . . . . . . . . . . . . . . 14 71 4.3.5. Related Considerations . . . . . . . . . . . . . . . . 15 72 4.4. Implement DNS Blacklisting . . . . . . . . . . . . . . . . 16 73 4.5. Transition Directly to Native Dual Stack . . . . . . . . . 17 74 5. Potential Implementation Phases . . . . . . . . . . . . . . . 18 75 5.1. No Access to IPv6 Content . . . . . . . . . . . . . . . . 18 76 5.2. Using IPv6 Transition Names . . . . . . . . . . . . . . . 18 77 5.3. Deploying DNS Resolver Whitelisting Using Manual 78 Processes . . . . . . . . . . . . . . . . . . . . . . . . 18 79 5.4. Deploying DNS Resolver Whitelisting Using Automated 80 Processes . . . . . . . . . . . . . . . . . . . . . . . . 18 81 5.5. Turning Off DNS Resolver Whitelisting . . . . . . . . . . 18 82 5.6. Deploying DNS Blacklisting . . . . . . . . . . . . . . . . 19 83 5.7. Fully Dual-Stack Content . . . . . . . . . . . . . . . . . 19 84 6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 19 85 6.1. Security Considerations . . . . . . . . . . . . . . . . . 19 86 6.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 20 87 6.3. Considerations with Poor IPv4 and Good IPv6 Transport . . 21 88 6.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 21 89 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 94 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 26 95 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 29 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 1. Introduction 100 This document describes considerations for the transition of end user 101 content on the Internet to IPv6. While this is tailored to address 102 end user content, which is typically web-based, many aspects of this 103 document may be more broadly applicable to the transition to IPv6 of 104 other applications and services. The issues explored herein will be 105 of particular interest to major web content sites (sometimes 106 described hereinafter as "high-traffic domains"), which have specific 107 and unique concerns relating to maintaining a high-quality user 108 experience for all of their users during their transition to IPv6. 109 This document explores the challenges involved in the transition to 110 IPv6, potential transition techniques, possible transition phases, 111 and other considerations. Some sections of this document also 112 include information about the potential implications of various 113 transition techniques or phased approaches to the transition to IPv6. 115 2. Challenges When Transitioning Content to IPv6 117 The goal in transitioning content to IPv6 is to make that content 118 natively dual-stack enabled, which provides native access to all end 119 users via both IPv4 and IPv6. However, there are technical and 120 operational challenges in being able to transition smoothly for all 121 end users, which has led to the development of a variety of 122 transition techniques. A first step in understanding various 123 transition techniques is to first outline the challenges involved in 124 moving content to IPv6. 126 Implementers of these various transition techniques are attempting to 127 protect users of their services from having a negative experience 128 (poor performance) when they receive DNS responses containing AAAA 129 resource records or when attempting to use IPv6 transport. There are 130 two main concerns which pertain to this practice; one of which is 131 IPv6-related impairment and the other which is the maturity or 132 stability of IPv6 transport (and associated network operations) for 133 high-traffic domains. Both can negatively affect the experience of 134 end users. 136 Not all domains may face the same challenges in transitioning content 137 to IPv6, since the user base of each domain, traffic sources, traffic 138 volumes, and other factors obviously will vary between domains. As a 139 result, while some domains have used an IPv6 transition technique, 140 others have run brief IPv6 experiments and then decided to simply 141 turn on IPv6 for the domain without further delay and without using 142 any specialized IPv6 transition techniques [Heise]. Each domain 143 should therefore consider its specific situation when formulating a 144 plan to move to IPv6; there is not one approach that will work for 145 every domain. 147 2.1. IPv6-Related Impairment 149 Some implementers have observed that when they added AAAA resource 150 records to their authoritative DNS servers in order to support IPv6 151 access to their content that a small fraction of end users had slow 152 or otherwise impaired access to a given web site with both AAAA and A 153 resource records. The fraction of users with such impaired access 154 has been estimated to be as high as 0.078% of total Internet users 155 [IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness], 156 though more recent measurements indicate this is declining 157 [Impairment-Tracker]. 159 While it is outside the scope of this document to explore the various 160 reasons why a particular user's system (host) may have impaired IPv6 161 access, for the users who experience this impairment it has a very 162 real performance impact. It would impact access to all or most dual 163 stack services to which the user attempts to connect. This negative 164 end user experience can range from somewhat slower than usual access 165 (as compared to native IPv4-based access), to extremely slow access, 166 to no access to the domain's resources whatsoever. In essence, 167 whether the end user even has an IPv6 address or not, merely by 168 receiving a AAAA record response the user either cannot access a 169 Fully Qualified Domain Name (FQDN, representing a service or resource 170 sought) or it is so slow that the user gives up and assumes the 171 destination is unreachable. 173 2.2. Operational Maturity Concerns 175 Some implementers have discovered that network operations, operations 176 support and business support systems, and other operational processes 177 and procedures are less mature for IPv6 as compared to IPv4, since 178 IPv6 has not heretofore been pervasively deployed. This operational 179 immaturity may be observed not just within the network of a given 180 domain but also in any directly or indirectly interconnected 181 networks. As a result, many domains consider it prudent to undertake 182 any network changes which will cause traffic to shift to IPv6 183 gradually in order to provide time and experience for IPv6 operations 184 and network practices mature. 186 2.3. Volume-Based Concerns 188 While Section 2.2 pertains to risks due to immaturity in operations, 189 a related concern is that some technical issues may not become 190 apparent until some moderate to high volume of traffic is sent via 191 IPv6 to and from a domain. As above, this may be the case not just 192 within the network of that domain but also for any directly or 193 indirectly interconnected networks. Furthermore, compared to domains 194 with small to moderate traffic volumes, whether by the count of end 195 users or count of bytes transferred, high-traffic domains receive 196 such a level of usage that it is prudent to undertake any network 197 changes gradually and in a manner which minimizes the risk of 198 disruption. One can imagine that for one of the top ten sites 199 globally, for example, the idea of suddenly turning on a significant 200 amount of IPv6 traffic is quite daunting and would carry a relatively 201 high risk of network and/or other disruptions. 203 3. IPv6 Adoption Implications 205 It is important that the challenges in transitioning content to IPv6 206 noted in Section 2 are addressed, especially for high-traffic 207 domains. Some high-traffic domains may find the prospect of 208 transitioning to IPv6 extremely daunting without having some ability 209 to address these challenges and to incrementally control their 210 transition to IPv6. Lacking such controls, some domains may choose 211 to substantially delay their transition to IPv6. A substantial delay 212 in content moving to IPv6 could certainly mean there are somewhat 213 fewer motivating factors for network operators to deploy IPv6 to end 214 user hosts (though they have many significant motivating factors that 215 are largely independent of content). At the same time, unless 216 network operators transition to IPv6, there are of course fewer 217 motivations for domain owners to transition content to IPv6. Without 218 progress in each part of the Internet ecosystem, networks and/or 219 content sites may delay, postpone, or cease adoption of IPv6, or to 220 actively seek alternatives to it. Such alternatives may include the 221 use of multi-layer or large scale network address translation (NAT) 222 techniques, which is not preferred relative to native dual stack. 224 Obviously, transitioning content to IPv6 is important to IPv6 225 adoption overall. While challenges do exist, such a transition is 226 not an impossible task for a domain to undertake. A range of 227 potential transition techniques, as noted below in Section 4, can 228 help meet these challenges and enable a domain to successfully 229 transition content and other services to IPv6. 231 4. Potential Transition Techniques 233 Domains have a wide range of potential techniques at their disposal 234 that may be used to facilitate the transition to IPv6. This section 235 includes many of the key techniques that could be used by a domain 236 but it is by no means an exhaustive or exclusive list. Only a 237 specific domain can judge whether or not a given (or any) transition 238 technique applies to their domain and meets their needs. A domain 239 may also decide to pursue several of these techniques in parallel. 240 Thus, the usefulness of each technique and the associated pros and 241 cons will vary from domain to domain. 243 4.1. Solve Current End User IPv6 Impairments 245 Domains can endeavor to fix the underlying technical problems 246 experienced by their end users during the transition to IPv6, as 247 noted in Section 2.1. One challenge with this option is that a 248 domain may have little or no control over the network connectivity, 249 operating system, client software (such as a web browser), and/or 250 other capabilities of the end users of that domain. In most cases a 251 domain is only in a position to influence and guide their end users. 252 While this is not the same sort of direct control which may exist in 253 an enterprise network for example, major domains are likely to be 254 trusted by their end users and may therefore be able to influence and 255 guide these users in solving any IPv6-related impairments. 257 Another challenge is that end user impairments are something that one 258 domain on their own cannot solve. This means that domains may find 259 it more effective to coordinate with many others in the Internet 260 community to solve what is really a collective problem that affects 261 the entire Internet. Of course, it can sometimes be difficult to 262 motivate members of the Internet community to work collectively 263 towards such a goal, sharing the labor, time, and costs related to 264 such an effort. However, World IPv6 Day [W6D] shows that such 265 community efforts are possible and despite any potential challenges, 266 the Internet community continues to work together in order to solve 267 end user IPv6 impairments. 269 One potential tactic may be to identify which users have such 270 impairments and then to communicate this information to affected 271 users. Such end user communication is likely to be most helpful if 272 the end user is not only alerted to a potential problem but is given 273 careful and detailed advice on how to resolve this on their own, or 274 is guided to where they can seek help in doing so. Another potential 275 tactic is for a domain to collect, track over time, and periodically 276 share with the Internet community the rate of impairment observed for 277 a domain. In any such end user IPv6-related analysis and 278 communication, Section 6.2 is worth taking into account. 280 However, while these tactics can help reduce IPv6-related impairments 281 Section 2.1, they do not address either operational maturity concerns 282 noted in Section 2.2 or volume-based concerns noted in Section 2.3, 283 which should be considered and addressed separately. 285 4.2. Use IPv6 Transition Names 287 Another potential transition technique is for a domain to gain 288 experience using a special Fully-Qualified Domain Name (FQDN). This 289 has become typical for domains beginning the transition to IPv6, 290 whereby a name such as ipv6.example.com or www.ipv6.example.com is 291 used. An end user would have to know to use this special transition 292 name; it is not the same name used for regular traffic. 294 This special transition name directs traffic to a host or hosts which 295 have been enabled for native IPv6 access. In some cases this name 296 may point to hosts which are separate from those used for IPv4 297 traffic (via www.example.com), while in other cases it may point to 298 the same hosts used for IPv4 traffic. A subsequent phase, if 299 separate hosts are used to support special transition names, is to 300 move to the same hosts used for regular traffic in order to utilize 301 and exercise production infrastructure more fully. Regardless of 302 whether or not dedicated hosts are used, the use of the special name 303 is a way to incrementally control traffic as a tool for a domain to 304 gain IPv6 experience and increase IPv6 use on a relatively controlled 305 basis. Any lessons learned can then inform plans for a full 306 transition to IPv6. This also provides an opportunity for a domain 307 to develop any necessary training for staff, to develop IPv6-related 308 testing procedures for their production network and lab, to deploy 309 IPv6 functionality into their production network, and to develop and 310 deploy IPv6-related network and service monitors. It is also an 311 opportunity to add a relatively small amount of IPv6 traffic to 312 ensure that network gear, network interconnects, and IPv6 routing in 313 general is working as expected. 315 While using a special transition name is a good initial step to 316 functionally test and prepare a domain for IPv6, including developing 317 and maturing IPv6 operations, as noted in Section 2.2, the utility of 318 the tactic is limited since users must know the transition name, the 319 traffic volume will be low, and the traffic is unlikely to be 320 representative of the general population of end users (they are 321 likely to be self-selecting early adopters and more technically 322 advanced than average), among other reasons. As a result, any 323 concerns and risks related to traffic volume as noted Section 2.3 324 should still be considered and addressed separately. 326 4.3. Implement DNS Resolver Whitelisting 328 Another potential technique, especially when a high traffic domain is 329 ready to move beyond an IPv6 transition name, as described in 330 Section 4.2, is to selectively return AAAA resource records (RRs), 331 which contain IPv6 addresses. This selective response of DNS records 332 is performed by an authoritative DNS servers for a domain in response 333 to DNS queries sent by DNS recursive resolvers [RFC1035]. This is 334 commonly referred to in the Internet community as "DNS Resolver 335 Whitelisting", and will be referred to as such hereafter, though in 336 essence it is simply a technique enabling the selective return of DNS 337 records based upon various technical factors. An end user is seeking 338 a resource by name, and this selective response mechanism enables 339 what is perceived to be the most reliable and best performing IP 340 address family to be used (IPv4 or IPv6). As a technique, it shares 341 similarities with Content Delivery Networks, Global Server Load 342 Balancing, DNS Load Balancing, and Split DNS, as described below in 343 Section 4.3.2, Section 4.3.3, Section 4.3.4. A few high-traffic 344 domains have either implemented DNS Resolver Whitelisting (one of 345 many transition techniques they have used or are using) or are 346 considering doing so [NW-Article-DNS-WL] [WL-Ops]. 348 This is a transition technique used by domains as a method for 349 incrementally transitioning inbound traffic to a domain to IPv6. If 350 an incremental technique like this is not users, a domain might 351 return AAAA resource records to any relevant DNS query, meaning the 352 domain could go quickly from no IPv6 traffic to potentially a 353 significant amount as soon as the AAAA resource records are 354 published. When DNS Resolver Whitelisting is implemented, a domain's 355 authoritative DNS will selectively return a AAAA resource record to 356 DNS recursive resolvers on a whitelist maintained by the domain, 357 while returning no AAAA resource records to DNS recursive resolvers 358 which are not on that whitelist. This tactic will not have a direct 359 impact on reducing IPv6-related impairments Section 2.1, though it 360 can help a domain address operational maturity concerns Section 2.2 361 and concerns and risks related to traffic volume Section 2.3. 363 There are of course challenges and concerns relating to DNS Resolver 364 Whitelisting. Some of the concerns with a whitelist of DNS recursive 365 resolvers may be held by parties other than the implementing domain, 366 such as network operators or end users that may not have had their 367 DNS recursive resolvers added to a whitelist. Additionally, the IP 368 address of a DNS recursive resolver is not a precise indicator of the 369 IPv6 preparedness, or lack of IPv6-related impairment, of end user 370 hosts which query (use) a particular DNS recursive resolver. While 371 the IP addresses of DNS recursive resolvers on networks known to have 372 deployed IPv6 may be an imperfect proxy for judging IPv6 373 preparedness, or lack of IPv6-related impairment, it is one of the 374 better available methods at the current time. In addition, given the 375 current state of global IPv6 deployment, this transition tactic 376 allows content providers to selectively expose the availability of 377 their IPv6 services. While opinions in the Internet community 378 concerning DNS Resolver Whitelisting are understandably quite varied, 379 there is clear consensus that DNS Resolver Whitelisting can be a 380 useful tactic a domain may choose to use as they transition their 381 services to IPv6. In particular, some high-traffic domains view DNS 382 Resolver Whitelisting as one of the few practical and low-risk 383 approaches enabling them to transition to IPv6, without which their 384 transition may not take place for some time. However, there is also 385 consensus that this practice is workable on a manual basis (see 386 below) only in the short-term and that it will not scale over the 387 long-term. Thus, some domains may find DNS Resolver Whitelisting a 388 beneficial temporary tactic in their transition to IPv6. 390 At the current time, generally speaking, a domain that implements DNS 391 Resolver Whitelisting does so manually. This means that a domain 392 manually maintains a list of networks that are permitted to receive 393 IPv6 records (via their DNS resolver IP addresses) and that these 394 networks typically submit applications, or follow some other process 395 established by the domain, in order to be added to the DNS Whitelist. 396 However, implementers foresee that a subsequent phase of DNS Resolver 397 Whitelisting is likely to emerge in the future, possibly in the near 398 future. In this new phase a domain would return IPv6 and/or IPv4 399 records dynamically based on automatically detected technical 400 capabilities, location, or other factors. It would then function 401 much like (or indeed as part of) global server load balancing, a 402 common practice already in use today, as described in Section 4.3.2. 403 Furthermore, in this future phase, networks would be added to and 404 removed from a DNS Whitelist automatically, and possibly on a near- 405 real-time basis. This means, crucially, that networks would no 406 longer need to apply to be added to a whitelist, which may alleviate 407 many of the key concerns that network operators may have with this 408 technique when it is implemented on a manual basis. 410 4.3.1. How DNS Resolver Whitelisting Works 412 Using a "whitelist" in a generic sense means that no traffic (or 413 traffic of a certain type) is permitted to the destination host 414 unless the originating host's IP address is contained in the 415 whitelist. In contrast, using a "blacklist" means that all traffic 416 is permitted to the destination host unless the originating host's IP 417 address is contained in the blacklist. In the case of DNS Resolver 418 Whitelisting, the resource that an end user seeks is a name, not an 419 IP address or IP address family. Thus, an end user is seeking a name 420 such as www.example.com, without regard to the underlying IP address 421 family (IPv4 or IPv6) which may be used to access that resource. 423 DNS Resolver Whitelisting is implemented in authoritative DNS 424 servers, not in DNS recursive resolvers. These authoritative DNS 425 servers selectively return AAAA resource records using the IP address 426 of the DNS recursive resolver that has sent it a query. Thus, for a 427 given operator of a website, such as www.example.com, the domain 428 operator implements whitelisting on the authoritative DNS servers for 429 the domain example.com. The whitelist is populated with the IPv4 430 and/or IPv6 addresses or prefix ranges of DNS recursive resolvers on 431 the Internet, which have been authorized to receive AAAA resource 432 record responses. These DNS recursive resolvers are operated by 433 third parties, such as Internet Service Providers (ISPs), 434 universities, governments, businesses, and individual end users. If 435 a DNS recursive resolver IS NOT matched in the whitelist, then AAAA 436 resource records WILL NOT be sent in response to a query for a 437 hostname in the example.com domain (and an A record would be sent). 438 However, if a DNS recursive resolver IS matched in the whitelist, 439 then AAAA resource records WILL be sent. As a result, while Section 440 2.2 of [RFC4213] notes that a stub resolver can make a choice between 441 whether to use a AAAA record or A record response, with DNS Resolver 442 Whitelisting the authoritative DNS server can also decide whether to 443 return a AAAA record, an A record, or both record types. 445 When implemented on a manual basis, DNS Resolver Whitelisting 446 generally means that a very small fraction of the DNS recursive 447 resolvers on the Internet (those in the whitelist) will receive AAAA 448 responses. The large majority of DNS recursive resolvers on the 449 Internet will therefore receive only A resource records containing 450 IPv4 addresses. When implemented manually, domains may find the 451 practice imposes some incremental operational burdens insofar as it 452 can consume staff time to maintain a whitelist (such as additions and 453 deletions to the list), respond to and review applications to be 454 added to a whitelist, maintain good performance levels on 455 authoritative DNS servers as the whitelist grows, create new network 456 monitors to check the health of a whitelist function, perform new 457 types of troubleshooting related to whitelisting, etc. In addition, 458 manually-based whitelisting imposes some incremental burdens on 459 operators of DNS recursive resolvers (such as network operators), 460 since they will need to apply to be whitelisted with any implementing 461 domains, and will subsequently need processes and systems to track 462 the status of whitelisting applications, respond to requests for 463 additional information pertaining to these applications, and track 464 any de-whitelisting actions. 466 When implemented on an automated basis in the future, DNS recursive 467 resolvers listed in the whitelist could expand and contract 468 dynamically, and possibly in near-real-time, based on a wide range of 469 factors. As a result, it is likely that the number of DNS recursive 470 resolvers on the whitelist will be substantially larger than when 471 such a list is maintained manually, and it is likely the the 472 whitelist will grow at a rapid rate. This automation can eliminate 473 most of the significant incremental operational burdens on both 474 implementing domains as well as operators of DNS recursive resolvers, 475 which is clearly a factor that is motivating implementers to work to 476 automate this function. 478 Section 4.3.1.1 and Figure 1 have more details on DNS Resolver 479 Whitelisting generally. In addition, the potential deployment models 480 of DNS Resolver Whitelisting (manual and automated) are described in 481 Section 5. It is also important to note that DNS Resolver 482 Whitelisting also works independently of whether an authoritative DNS 483 server, DNS recursive resolver, or end user host uses IPv4 transport, 484 IPv6, or both. So, for example, whitelisting may not result in the 485 return of AAAA responses even in those cases where the DNS recursive 486 resolver has queried the authoritative server over IPv6 transport. 487 This may also be the case in some situations when the end user host's 488 original query to its DNS recursive resolver was over IPv6 transport, 489 if that DNS recursive resolver is not on a given whitelist. One 490 important reason for this is that even though the DNS recursive 491 resolver may have no IPv6-related impairments, this is not a reliable 492 predictor of whether the same is true of the end user host. This 493 also means that a DNS whitelist can contain both IPv4 and IPv6 494 addresses. 496 4.3.1.1. Description of the Operation of DNS Resolver Whitelisting 498 Specific implementations will vary from domain to domain, based on a 499 range of factors such as the technical capabilities of a given 500 domain. As such, any examples listed herein should be considered 501 general examples and are not intended to be exhaustive. 503 The system logic of DNS Resolver Whitelisting is as follows: 505 1. The authoritative DNS server for example.com receives DNS queries 506 for the A (IPv4) and/or AAAA (IPv6) address resource records for 507 the Fully Qualified Domain Name (FQDN) www.example.com, for which 508 AAAA (IPv6) resource records exist. 510 2. The authoritative DNS server checks the IP address (IPv4, IPv6, 511 or both) of the DNS recursive resolver sending the AAAA (IPv6) 512 query against the whitelist that is the DNS Whitelist. 514 3. If the DNS recursive resolver's IP address IS matched in the 515 whitelist, then the response to that specific DNS recursive 516 resolver can contain AAAA (IPv6) address resource records. 518 4. If the DNS recursive resolver's IP address IS NOT matched in the 519 whitelist, then the response to that specific DNS recursive 520 resolver cannot contain AAAA (IPv6) address resource records. In 521 this case, the server will likely return a response with the 522 response code (RCODE) being set to 0 (No Error) with an empty 523 answer section for the AAAA record query. 525 +--------------------------------------------------------------------+ 526 | Caching Server 1 - IS NOT ON the DNS Whitelist | 527 | Caching Server 2 - IS ON the DNS Whitelist | 528 | Note: Transport between each host can be IPv4 or IPv6. | 529 +--------------------------------------------------------------------+ 530 +----------+ +---------------+ +---------------+ 531 | Stub | | DNS Caching | | DNS | 532 | Resolver | | Server 1 | | Server | 533 +----------+ +---------------+ +---------------+ 534 | DNS Query: | | 535 | example.com A, AAAA | | 536 |---------------------->| | 537 | | | 538 | | DNS Query: | 539 | | example.com A, AAAA | 540 | |------------------------>| 541 | | | 542 | | | NOT on Whitelist 543 | | DNS Response: | 544 | | example.com A | 545 | |<------------------------| 546 | | | 547 | DNS Response: | | 548 | example.com A | | 549 |<----------------------| | 551 +----------+ +---------------+ +---------------+ 552 | Stub | | DNS Caching | | DNS | 553 | Resolver | | Server 2 | | Server | 554 +----------+ +---------------+ +---------------+ 555 | DNS Query: | | 556 | example.com A, AAAA | | 557 |---------------------->| | 558 | | | 559 | | DNS Query: | 560 | | example.com A, AAAA | 561 | |------------------------>| 562 | | | 563 | | | IS on Whitelist 564 | | DNS Response: | 565 | | example.com A, AAAA | 566 | |<------------------------| 567 | | | 568 | DNS Response: | | 569 | example.com A, AAAA | | 570 |<----------------------| | 572 Figure 1: DNS Resolver Whitelisting Diagram 574 4.3.2. Similarities to Content Delivery Networks and Global Server Load 575 Balancing 577 DNS Resolver Whitelisting is functionally similar to Content Delivery 578 Networks (CDNs) and Global Server Load Balancing (GSLB). When using 579 a CDN or GSLB, a geographically-aware authoritative DNS server 580 function is usually part of that overall system. As a result, the 581 use of a CDN or GSLB with an authoritative DNS server function 582 enables the IP address resource records returned to a resolver in 583 response to a query to vary based on the estimated geographic 584 location of the resolver [Wild-Resolvers] or a range of other 585 technical factors. This CDN or GSLB DNS function is performed in 586 order to attempt to direct hosts to connect to the nearest hosts (as 587 measured in round trip time), to the host that has the best 588 connectivity to an end user, to route around failures, to avoid sites 589 where maintenance work has taken down hosts, and/or to the host that 590 will otherwise provide the best service experience for an end user at 591 a given point in time. As a result, one can see a direct similarity 592 to DNS Resolver Whitelisting insofar as different IP address resource 593 records are selectively returned to resolvers based on the IP address 594 of each resolver and/or other imputed factors related to that IP 595 address. 597 4.3.3. Similarities to DNS Load Balancing 599 DNS Resolver Whitelisting has some similarities to DNS load 600 balancing. There are of course many ways that DNS load balancing can 601 be performed. In one example, multiple IP address resource records 602 (A and/or AAAA) can be added to the DNS for a given FQDN. This 603 approach is referred to as DNS round robin [RFC1794]. DNS round 604 robin may also be employed where SRV resource records are used 605 [RFC2782]. In another example, one or more of the IP address 606 resource records in the DNS will direct traffic to a load balancer. 607 That load balancer, in turn, may be application-aware, and pass the 608 traffic on to one or more hosts connected to the load balancer which 609 have different IP addresses. In cases where private IPv4 addresses 610 are used [RFC1918], as well as when public IP addresses are used, 611 those end hosts may not necessarily be directly reachable without 612 passing through the load balancer first. So, similar to DNS Resolver 613 Whitelisting, a load balancer will control what server host an end 614 user's host communicates with when using a FQDN. 616 4.3.4. Similarities to Split DNS 618 DNS Resolver Whitelisting has some similarities to so-called split 619 DNS, briefly described in Section 3.8 of [RFC2775]. When split DNS 620 is used, the authoritative DNS server selectively returns different 621 responses depending upon what host has sent the query. While 623 [RFC2775] notes the typical use of split DNS is to provide one answer 624 to hosts on an Intranet (internal network) and a different answer to 625 hosts on the Internet (external or public network), the basic idea is 626 that different answers are provided to hosts on different networks. 627 This is similar to the way that DNS Resolver Whitelisting works, 628 whereby hosts on different networks which use different DNS recursive 629 resolvers, receive different answers if one DNS recursive resolver is 630 on the whitelist and the other is not. However, Internet 631 transparency and Internet fragmentation concerns regarding split DNS 632 are detailed in Section 2.1 of [RFC2956] and Section 2.7 notes 633 concerns regarding split DNS and that it "makes the use of Fully 634 Qualified Domain Names (FQDNs) as endpoint identifiers more complex". 635 Section 3.5 of [RFC2956] further recommends that maintaining a stable 636 approach to DNS operations is key during transitions, such as the one 637 to IPv6 that is underway now, stating that "Operational stability of 638 DNS is paramount, especially during a transition of the network 639 layer, and both IPv6 and some network address translation techniques 640 place a heavier burden on DNS." 642 4.3.5. Related Considerations 644 While techniques such as GLSB and DNS load balancing, which share 645 much in common with DNS Resolver Whitelisting and are widespread, 646 some in the community have raised a range of concerns about the 647 practice. Some concerns are specific DNS Resolver Whitelisting 648 [WL-Concerns]. Other concerns are not as specific and pertain to the 649 general practice of implementing content location or other network 650 policy controls in the "middle" of the network in a so-called 651 "middlebox" function. Whether such DNS-related functions are really 652 part of a middlebox is debatable. Nevertheless, implementers should 653 at least be aware of some of the risks of middleboxes, as noted in 654 [RFC3724]. A related document, [RFC1958] explains that the state, 655 policies, and other functions needed in the middle of the network 656 should be minimized as a design goal. In addition, Section 2.16 of 657 [RFC3234] makes specific statements concerning modified DNS servers. 658 [RFC3234] also outlines more general concerns in Section 1.2 about 659 the introduction of new failure modes when configuration is no longer 660 limited to two ends of a session, so that diagnosis of failures and 661 misconfigurations could become more complex. Two additional sources 662 worth considering are [Tussle] and [Rethinking], in which the authors 663 note concerns regarding the introduction of new control points (such 664 as in middleboxes), including in the DNS. 666 However, some state, policies, and other functions have always been 667 necessary to enable effective, reliable, and high-quality end-to-end 668 communications on the Internet. In addition, techniques such as 669 Global Server Load Balancing, Content Delivery Networking, DNS Load 670 Balancing and Split DNS are not only widely deployed but are almost 671 uniformly viewed as essential to the functioning of the Internet and 672 highly beneficial to the quality of the end user experience on the 673 Internet. These techniques have had and continue to have a 674 beneficial effect on the experience of a wide range of Internet 675 applications and protocols. So while there are valid concerns about 676 implementing policy controls in the "middle" of the network, or 677 anywhere away from edge hosts, the definition of what constitutes the 678 middle and edge of the network is debatable in this case. This is 679 particularly so given that GSLBs and CDNs facilitate connections from 680 end host and the optimal content hosts, and could therefore be 681 considered a modest and in many cases essential network policy 682 extension of a network's edge, especially in the case of high-traffic 683 domains. 685 There may be additional implications for end users that have 686 configured their hosts to use a third party as their DNS recursive 687 resolver, rather than the one(s) provided by their network operator. 688 In such cases, it will be more challenging for a domain using 689 whitelisting to determine the level of IPv6-related impairment when 690 such third-party DNS recursive resolvers are used, given the wide 691 variety of end user access networks which may be used and that this 692 mix may change in unpredictable ways over time. 694 4.4. Implement DNS Blacklisting 696 With DNS Resolver Whitelisting, DNS recursive resolvers can receive 697 AAAA resource records only if they are on the whitelist. DNS 698 Blacklisting is by contrast the the opposite of that, whereby all DNS 699 recursive resolvers can receive AAAA resource records unless they are 700 on the blacklist. Some implementers of DNS Resolver Whitelisting may 701 choose to subsequently transition to DNS Blacklisting. It is unclear 702 when and if it may be appropriate for a domain to change from 703 whitelisting to blacklisting. Nor is it clear how implementers will 704 judge the network conditions to have changed sufficiently to justify 705 disabling such controls. 707 When a domain uses blacklisting, they are enabling all DNS recursive 708 resolvers to receive AAAA record responses except for what is 709 presumed to be a relatively small number that are on the blacklist. 710 Over time it is likely that the blacklist will become smaller as the 711 networks associated with the blacklisted DNS recursive resolvers are 712 able to meaningfully reduce IPv6-related impairments to some 713 acceptable level, though it is possible that some networks may never 714 achieve that. DNS Blacklisting is also likely less labor intensive 715 for a domain than performing DNS Resolver Whitelisting on a manual 716 basis. This is simply because the domain would presumably be focused 717 on a smaller number of DNS recursive resolvers with well known IPv6- 718 related problems. 720 It is also worth noting that the email industry has a long experience 721 with blacklists and, very generally speaking, blacklists tend to be 722 effective and well received when it is easy to discover if an IP 723 address is on a blacklist, if there is a transparent and easily 724 understood process for requesting removal from a blacklist, and if 725 the decision-making criteria for placing a server on a blacklist is 726 transparently disclosed and perceived as fair. However, in contrast 727 to an email blacklist where a blacklisted host cannot send email to a 728 domain at all, with DNS Resolver Whitelisting communications will 729 still occur over IPv4 transport. 731 4.5. Transition Directly to Native Dual Stack 733 As an alternative to adopting any of the aforementioned transition 734 techniques, domains can choose to transition to native dual stack 735 directly by adding native IPv6 capabilities to their network and 736 hosts and by publishing AAAA resource records in the DNS for named 737 resources within their domain. Of course, a domain can still control 738 this transition gradually, on a name-by-name basis, by adding native 739 IPv6 to one name at a time, such as mail.example.com first and 740 www.example.com later. So even a "direct" transition can be 741 performed gradually. 743 It is then up to end users with IPv6-related impairments to discover 744 and fix any applicable impairments. However, the concerns and risks 745 related to traffic volume Section 2.3 should still be considered and 746 managed, since those are not directly related to such impairments. 747 Not all content providers (or other domains) may face the challenges 748 detailed herein or face them to the same degree, since the user base 749 of each domain, traffic sources, traffic volumes, and other factors 750 obviously varies between domains. 752 For example, while some content providers have implemented DNS 753 Resolver Whitelisting (one transition technique), others have run 754 IPv6 experiments whereby they added AAAA resource records and 755 observed and measured errors, and then decided not to implement DNS 756 Resolver Whitelisting [Heise]. A more widespread such experiment was 757 World IPv6 Day [W6D], sponsored by the Internet Society, on June 8, 758 2011. This was a unique opportunity for hundreds of domains to add 759 AAAA resource records to the DNS without using DNS Resolver 760 Whitelisting, all at the same time. Some of the participating 761 domains chose to leave AAAA resource records in place following the 762 experiment based on their experiences. 764 Content providers can run their own independent experiments in the 765 future, adding AAAA resource records for a brief period of time 766 (minutes, hours, or days), and then analyzing any impacts or effects 767 on traffic and the experience of end users. They can also simply 768 turn on IPv6 for their domain, which may be easier when the 769 transition does not involve a high-traffic domain. 771 5. Potential Implementation Phases 773 These usefulness of each technique in Section 4, and the associated 774 pros and cons associated with each technique, is relative to each 775 potential implementer and will therefore vary from one implementer to 776 another. As a result, it is not possible to say that the potential 777 phases below make sense for every implementer. This also means that 778 the duration of each phase will vary between implementers, and even 779 that different implementers may skip some of these phases entirely. 780 Finally, the techniques listed in Section 4 are by no means 781 exclusive. 783 5.1. No Access to IPv6 Content 785 In this phase, a site is accessible only via IPv4 transport. As of 786 the time of this document, the majority of content on the Internet is 787 in this state and is not accessible natively over IPv6. 789 5.2. Using IPv6 Transition Names 791 One possible first step for a domain is to gain experience using a 792 specialized new FQDN, such as ipv6.example.com or 793 www.ipv6.example.com, as explained in Section 4.2. 795 5.3. Deploying DNS Resolver Whitelisting Using Manual Processes 797 As noted in Section 4.3, a domain could begin using DNS Resolver 798 Whitelisting as a way to incrementally enable IPv6 access to content. 799 This tactic may be especially interesting to high-traffic domains. 801 5.4. Deploying DNS Resolver Whitelisting Using Automated Processes 803 For a domain that decides to undertake DNS Resolver Whitelisting on a 804 manual basis, the domain may subsequently move to perform DNS 805 Resolver Whitelisting on an automated basis. This is explained in 806 Section 4.3, and can significantly ease any operational burdens 807 relating to a manually-maintained whitelist. 809 5.5. Turning Off DNS Resolver Whitelisting 811 Domains that choose to implement DNS Resolver Whitelisting generally 812 consider it to be a temporary measure. It is unclear how 813 implementers will judge when the network conditions will have changed 814 sufficiently to justify turning off DNS Resolver Whitelisting and/or 815 what the process and timing will be for discontinuing this practice, 816 though the extent of IPv6 deployment to end users in networks, the 817 state of IPv6-related impairment, and the maturity of IPv6 operations 818 are all clearly factors. However, implementers may wish to take into 819 consideration that, as a practical matter, it will be impossible to 820 get to a point where there are no longer any IPv6-related 821 impairments; some reasonably small number of hosts will inevitably be 822 left behind as end users elect not to upgrade them or as some hosts 823 are incapable of being upgraded. 825 5.6. Deploying DNS Blacklisting 827 Regardless of whether a domain has first implemented DNS Resolver 828 Whitelisting or has never done so, DNS Blacklisting as described in 829 Section 4.4 may become interesting. This may be at the point in time 830 when domains wish to make their content widely available over IPv6 831 but still wish to protect end users of a few networks with well known 832 IPv6 limitations from having a bad end user experience. 834 5.7. Fully Dual-Stack Content 836 A domain can arrive at this phase either following the use of a 837 previous IPv6 transition technique, or they may go directly to this 838 point as noted in Section 4.5. In this phase the site's content has 839 been made natively accessible via both IPv4 and IPv6 for all end 840 users on the Internet, or at least without the use of any other IPv6 841 transition technique. 843 6. Other Considerations 845 6.1. Security Considerations 847 If DNS Resolver Whitelisting is adopted, as noted in Section 4.3, 848 then organizations which apply DNS Resolver Whitelisting policies in 849 their authoritative servers should have procedures and systems which 850 do not allow unauthorized parties to modify the whitelist or 851 blacklist, just as all configuration settings for name servers should 852 be protected by appropriate procedures and systems. Such 853 unauthorized additions or removals from the whitelist can be 854 damaging, causing content providers and/or network operators to incur 855 support costs resulting from end user and/or customer contacts, as 856 well as causing potential dramatic and disruptive swings in traffic 857 from IPv6 to IPv4 or vice versa. 859 DNS security extensions defined in [RFC4033], [RFC4034], and 860 [RFC4035] use cryptographic digital signatures to provide origin 861 authentication and integrity assurance for DNS data. This is done by 862 creating signatures for DNS data on a Security-Aware Authoritative 863 Name Server that can be used by Security-Aware Resolvers to verify 864 the answers. Since DNS Resolver Whitelisting is implemented on an 865 authoritative DNS server, which provides different answers depending 866 upon which DNS resolver has sent a query, the DNSSEC chain of trust 867 is not altered. So even though an authoritative DNS server will 868 selectively return AAAA resource records and/or A resource records, 869 these resource records can certainly still be signed. As a result, 870 there should not be any negative impact on DNSSEC for those domains 871 that have implemented both DNSSEC on their Security-Aware 872 Authoritative Name Servers and also implemented DNS Resolver 873 Whitelisting. As for any party implementing DNSSEC of course, such 874 domains should ensure that resource records are being appropriately 875 and reliably signed. 877 However, network operators that run DNS recursive resolvers should be 878 careful not to modify the responses received from authoritative DNS 879 servers. It is possible that some networks may attempt to do so in 880 order to prevent AAAA record responses from going to end user hosts, 881 due to some IPv6-related impairment or other lack of IPv6 readiness 882 with that network. But when a network operates a Security-Aware 883 Resolver, modifying or suppressing AAAA resource records for a 884 DNSSEC-signed domain could break the chain of trust established with 885 DNSSEC. 887 6.2. Privacy Considerations 889 As noted in Section 4.1, there is a benefit in sharing IPv6-related 890 impairment statistics within the Internet community over time. Any 891 such statistics probably should be high-level statistics, such as 892 "the domain example.com has observed an average daily impairment rate 893 of 0.05% in September 2011, down from 0.15% in January 2011". In 894 contrast, sharing a list of names and/or email addresses of the end 895 users of a domain with impairments is probably not well advised from 896 a privacy standpoint. Thus, sharing only summary data can help 897 protect end user privacy and any information which may be proprietary 898 to a domain. 900 In addition, there are often methods to detect IPv6-related 901 impairments for a specific end user, such as running an IPv6 test 902 when an end user visits the website of a particular domain. Should a 903 domain then choose to automatically communicate the facts of an 904 impairment to an affected user, there are likely no direct privacy 905 considerations. However, if the domain then decided to share 906 information concerning that particular end user with that user's 907 network operator or another third party, then the domain may wish to 908 consider advising the end user of this or otherwise seeking to obtain 909 the end user's consent to share such information. 911 Appropriate guidelines for any information sharing likely varies by 912 country and/or legal jurisdiction. Domains should consider any 913 potential privacy issues when considering what information can be 914 shared. If a domain does publish or share detailed impairment 915 statistics, they would be well advised to avoid identifying 916 individual hosts or users. 918 6.3. Considerations with Poor IPv4 and Good IPv6 Transport 920 There are situations where the differing quality of the IPv4 and IPv6 921 connectivity of an end user could cause complications in accessing 922 content when a domain is using an IPv6 transition technique. While 923 today most end users' IPv4 connectivity is typically superior to IPv6 924 connectivity (if such connectivity exists at all), there could be 925 implications when the reverse is true and and end user has markedly 926 superior IPv6 connectivity as compared to IPv4. This is not a 927 theoretical situation; it has been observed by at least one major 928 content provider. 930 For example, in one possible scenario, a user is issued IPv6 931 addresses by their ISP and has a home network and devices or 932 operating systems which fully support native IPv6. As a result this 933 theoretical user has very good IPv6 connectivity. However, this end 934 user's ISP has exhausted their available pool of unique IPv4 address, 935 and uses NAT in order to share IPv4 addresses among end users. So 936 for IPv4 content, the end user must send their IPv4 traffic through 937 some additional network element (e.g. large scale NAT, proxy server, 938 tunnel server). Use of this additional network element might cause 939 an end user to experience sub-optimal IPv4 connectivity when certain 940 protocols or applications are used. This user then has good IPv6 941 connectivity but impaired IPv4 connectivity. As a result, the user's 942 poor IPv4 connectivity situation could potentially be exacerbated 943 when accessing a domain which is using a transition technique that 944 causes this user to only be able to access content over IPv4 945 transport for whatever reason. 947 Should this sort of situation become widespread in the future, a 948 domain may wish to take it into account when deciding how and when to 949 transition content to IPv6. 951 6.4. IANA Considerations 953 There are no IANA considerations in this document. 955 7. Contributors 957 The following people made significant textual contributions to this 958 document and/or played an important role in the development and 959 evolution of this document: 961 - John Brzozowski 963 - Chris Griffiths 965 - Tom Klieber 967 - Yiu Lee 969 - Rich Woundy 971 8. Acknowledgements 973 The author and contributors also wish to acknowledge the assistance 974 of the following individuals or groups. Some of these people 975 provided helpful and important guidance in the development of this 976 document and/or in the development of the concepts covered in this 977 document. Other people assisted by performing a detailed review of 978 this document, and then providing feedback and constructive criticism 979 for revisions to this document, or engaged in a healthy debate over 980 the subject of the document. All of this was helpful and therefore 981 the following individuals merit acknowledgement: 983 - Bernard Aboba 985 - Jari Arkko 987 - Fred Baker 989 - Ron Bonica 991 - Frank Bulk 993 - Brian Carpenter 995 - Lorenzo Colitti 997 - Alissa Cooper 999 - Dave Crocker 1001 - Ralph Droms 1003 - Wesley Eddy 1004 - J.D. Falk 1006 - Adrian Farrel 1008 - Stephen Farrell 1010 - Tony Finch 1012 - Karsten Fleischhauer 1014 - Igor Gashinsky 1016 - Wesley George 1018 - Philip Homburg 1020 - Jerry Huang 1022 - Ray Hunter 1024 - Joel Jaeggli 1026 - Erik Kline 1028 - Suresh Krishnan 1030 - Victor Kuarsingh 1032 - Donn Lee 1034 - John Leslie 1036 - John Mann 1038 - Danny McPherson 1040 - Milo Medin 1042 - Martin Millnert 1044 - Russ Mundy 1046 - Thomas Narten 1048 - Pekka Savola 1050 - Robert Sparks 1051 - Barbara Stark 1053 - Joe Touch 1055 - Hannes Tschofenig 1057 - Tina Tsou 1059 - Members of the Broadband Internet Technical Advisory Group (BITAG) 1061 9. References 1063 9.1. Normative References 1065 [RFC1035] Mockapetris, P., "Domain names - implementation and 1066 specification", STD 13, RFC 1035, November 1987. 1068 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 1069 April 1995. 1071 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1072 E. Lear, "Address Allocation for Private Internets", 1073 BCP 5, RFC 1918, February 1996. 1075 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 1076 RFC 1958, June 1996. 1078 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1079 February 2000. 1081 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1082 specifying the location of services (DNS SRV)", RFC 2782, 1083 February 2000. 1085 [RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", 1086 RFC 2956, October 2000. 1088 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1089 Issues", RFC 3234, February 2002. 1091 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 1092 and the Future of End-to-End: Reflections on the Evolution 1093 of the Internet Architecture", RFC 3724, March 2004. 1095 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1096 Rose, "DNS Security Introduction and Requirements", 1097 RFC 4033, March 2005. 1099 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1100 Rose, "Resource Records for the DNS Security Extensions", 1101 RFC 4034, March 2005. 1103 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1104 Rose, "Protocol Modifications for the DNS Security 1105 Extensions", RFC 4035, March 2005. 1107 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1108 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1110 9.2. Informative References 1112 [Heise] Heise.de, "The Big IPv6 Experiment", Heise.de 1113 Website http://www.h-online.com, January 2011, . 1117 [IETF-77-DNSOP] 1118 Gashinsky, I., "IPv6 & recursive resolvers: How do we make 1119 the transition less painful?", IETF 77 DNS Operations 1120 Working Group, March 2010, 1121 . 1123 [IPv6-Brokenness] 1124 Anderson, T., "Measuring and Combating IPv6 Brokenness", 1125 Reseaux IP Europeens (RIPE) 61st Meeting, November 2010, 1126 . 1128 [IPv6-Growth] 1129 Colitti, L., Gunderson, S., Kline, E., and T. Refice, 1130 "Evaluating IPv6 adoption in the Internet", Passive and 1131 Active Management (PAM) Conference 2010, April 2010, 1132 . 1134 [Impairment-Tracker] 1135 Anderson, T., "IPv6 dual-stack client loss in Norway", 1136 Website , May 2011, . 1138 [NW-Article-DNS-WL] 1139 Marsan, C., "Google, Microsoft, Netflix in talks to create 1140 shared list of IPv6 users", Network World , March 2010, . 1144 [NW-Article-DNSOP] 1145 Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", 1146 Network World , March 2010, . 1149 [Rethinking] 1150 Blumenthal, M. and D. Clark, "Rethinking the design of the 1151 Internet: The end to end arguments vs. the brave new 1152 world", ACM Transactions on Internet Technology Volume 1, 1153 Number 1, Pages 70-109, August 2001, . 1157 [Tussle] Braden, R., Clark, D., Sollins, K., and J. Wroclawski, 1158 "Tussle in Cyberspace: Defining Tomorrow's Internet", 1159 Proceedings of ACM Sigcomm 2002, August 2002, . 1163 [W6D] The Internet Society, "World IPv6 Day - June 8, 2011", 1164 Internet Society Website http://www.isoc.org, 1165 January 2011, . 1167 [WL-Concerns] 1168 Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y., 1169 Livingood, J., and R. Woundy, "IPv6 DNS Resolver 1170 Whitelisting - Could It Hinder IPv6 Adoption?", 1171 ISOC Internet Society IPv6 Deployment Workshop, 1172 April 2010, . 1175 [WL-Ops] Kline, E., "IPv6 Whitelist Operations", Google Google IPv6 1176 Implementors Conference, June 2010, . 1180 [Wild-Resolvers] 1181 Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig, 1182 "Comparing DNS Resolvers in the Wild", ACM Sigcomm 1183 Internet Measurement Conference 2010, November 2010, 1184 . 1186 Appendix A. Document Change Log 1188 [RFC Editor: This section is to be removed before publication] 1190 -07: Significant re-write based on feedback from Jari Arkko, Joel 1191 Jaeggli, Fred Baker, Igor Gashinsky, Donn Lee, Lorenzo Colitti, and 1192 Erik Kline. 1194 -06: Removed the Open Issue #8 concerning the document name, at the 1195 direction of Joel Jaeggli. Removed Open Issue #2 from J.D. Falk and 1196 removed Open Issue #3 from Ray Hunter, as confirmed on the v6ops WG 1197 mailing list. Revised the Abstract and Intro as recommended by Tony 1198 Finch. Per Dave Crocker, updated the diagram following remedial 1199 ASCII art assistance, added a reference regarding IPv4-brokenness 1200 statistics. Removed Open Issue #1, after validating proper reference 1201 placement and removing NAT444 reference. Updates per Ralph Droms' 1202 review for the IESG. Closed Open Issue #4, Per Joe Touch, moved 1203 section 8 to just after section 3 - and also moved up section 6 and 1204 merged it. Closed Open Issue #5, per Dave Crocker and John Leslie, 1205 simplifying the document more, consolidating sections, etc. Closed 1206 Open Issue #6. Closed Open Issue #7, per Jari Arkko, ensuring all 1207 motivations are accounted for, etc. Closed Open Issue #9, per 1208 Stephen Farrell, re. World IPv6 Day (retained reference but re- 1209 worded those sections). Removed the happy-eyeballs reference since 1210 this was an informative reference and the draft could be delayed due 1211 to that dependency. ALL OPEN ITEMS ARE NOW CLOSED. 1213 -05: Additional changes requested by Stephen Farrell intended to 1214 close his Discuss on the I-D. These changes were in Sections 6.2 and 1215 8.3. Also shortened non-RFC references at Stephen's request. 1217 -04: Made changes based on feedback received during IESG review. 1218 This does NOT include updated from the more general IETF last call - 1219 that will be in a -05 version of the document. Per Ralph Droms, 1220 change the title of 6.2 from "Likely Deployment Scenarios" to 1221 "General Implementation Variations", as well as changes to improve 1222 the understanding of sentences in Sections 2, 3, 4, and 8.2. Per 1223 Adrian Farrel, made a minor change to Section 3. Per Robert Sparks, 1224 to make clear in Section 2 that whitelisting is done on authoritative 1225 servers and not DNS recursive resolvers, and to improve Section 8.3 1226 and add a reference to I-D.ietf-v6ops-happy-eyeballs. Per Wesley 1227 Eddy, updated Section 7.3.2 to address operational concerns and re- 1228 titled Section 8 from "Solutions" to "General Implementation 1229 Variations". Per Stephen Farrell, added text to Section 8.1 and 1230 Section 6.2, with a reference to 8.1 in the Introduction, to say that 1231 universal deployment is considered harmful. Added text to Section 2 1232 per the v6ops list discussion to indicate that whitelisting is 1233 independent of the IP address family of the end user host or 1234 resolver. There was also discussion with the IESG to change the name 1235 of the draft to IPv6 DNS Resolver Whitelisting or IPv6 AAAA DNS 1236 Resolver Whitelisting (as suggested originally by John Mann) but 1237 there was not a strong consensus to do so. Added a new section 7.7, 1238 at the suggestion of Philip Homburg. Per Joe Touch, added a new 1239 Section 8.4 on blacklisting as an alternative, mentioned blacklisting 1240 in Section 2, added a new Section 7.8 on the use of 3rd party 1241 resolvers, and updated section 6.2 to change Internet Draft documents 1242 to RFCs. Minor changes from Barbara Stark. Changes to the Privacy 1243 Considerations section based on feedback from Alissa Cooper. Changed 1244 "highly-trafficked" domains to "high-traffic" domains. Per Bernard 1245 Aboba, added text noting that a whitelist may be manually or 1246 automatically updated, contrasting whitelisting with blacklisting, 1247 reorganized Section 3, added a note on multiple clearinghouses being 1248 possible. Per Pekka Savola, added a note regarding multiple 1249 clearinghouses to the Ad Hoc section, corrected grammar in Section 1250 7.5, reworded Section 7.3.7, corrected the year in a RIPE reference 1251 citation. Also incorporated general feedback from the Broadband 1252 Internet Technical Advisory Group. Per Jari Arkko, simplified the 1253 introduction to the Implications section, played down possible 1254 impacts on RFC 4213, added caveats to Section 8.3.2 on the utility of 1255 transition names, re-wrote Section 9. Updated the Abstract and 1256 Introduction, per errors noted by Tony Finch. Updated the Security 1257 Considerations based on feedback from Russ Mundy. Per Ray Hunter, 1258 added some text to the De-Whitelisting implications section regarding 1259 effects on networks of switching from IPv6 to IPv4. Updated 7.3.1 1260 per additional feedback from Karsten Fleischhauer. Per Dave Crocker, 1261 added a complete description of the practice to the Abstract, added a 1262 note to the Introduction that the operational impacts are 1263 particularly acute at scale, added text to Intro to make clear this 1264 practice affects all protocols and not just HTTP, added a new query/ 1265 response diagram, added text to the Abstract and Introduction noting 1266 that this is an IPv6 transition mechanism, and too many other changes 1267 to list. 1269 -03: Several changes suggested by Joel Jaeggli at the end of WGLC. 1270 This involved swapping the order of Section 6.1 and 6.2, among other 1271 changes to make the document more readable, understandable, and 1272 tonally balanced. As suggested by Karsten Fleischhauer, added a 1273 reference to RFC 4213 in Section 7.1, as well as other suggestions to 1274 that section. As suggested by Tina Tsou, made some changes to the 1275 DNSSEC section regarding signing. As suggested by Suresh Krishnan, 1276 made several changes to improve various sections of the document, 1277 such as adding an alternative concerning the use of ipv6.domain, 1278 improving the system logic section, and shortening the reference 1279 titles. As suggested by Thomas Narten, added some text regarding the 1280 imperfection of making judgements as to end user host impairments 1281 based upon the DNS recursive resolver's IP and/or network. Finally, 1282 made sure that variations in the use of 'records' and 'resource 1283 records' was updated to 'resource records' for uniformity and to 1284 avoid confusion. 1286 -02: Called for and closed out feedback on dnsop and v6ops mailing 1287 lists. Closed out open feedback items from IETF 79. Cleared I-D 1288 nits issues, added a section on whether or not this is recommended, 1289 made language less company-specific based on feedback from Martin 1290 Millnert, Wes George, and Victor Kuarsingh. Also mentioned World 1291 IPv6 Day per Wes George's suggestion. Added references to the ISOC 1292 World IPv6 Day and the Heise.de test at the suggestion of Jerry 1293 Huang, as well as an additional implication in 7.3.7. Made any 1294 speculation on IPv4 impairment noted explicitly as such, per feedback 1295 from Martin Millnert. Added a reference to DNS SRV in the load 1296 balancing section. Added various other references. Numerous changes 1297 suggested by John Brzozowski in several sections, to clean up the 1298 document. Moved up the section on why whitelisting is performed to 1299 make the document flow more logically. Added a note in the ad hoc 1300 deployment scenario explaining that a deployment may be temporary, 1301 and including more of the perceived benefits of this tactic. Added a 1302 Privacy Considerations section to address end-user detection and 1303 communication. 1305 -01: Incorporated feedback received from Brian Carpenter (from 10/19/ 1306 2010), Frank Bulk (from 11/8/2010), and Erik Kline (from 10/1/2010). 1307 Also added an informative reference at the suggestion of Wes George 1308 (from from 10/22/2010). Closed out numerous editorial notes, and 1309 made a variety of other changes. 1311 -00: First version published as a v6ops WG draft. The preceding 1312 individual draft was 1313 draft-livingood-dns-whitelisting-implications-01. IMPORTANT TO NOTE 1314 that no changes have been made yet based on WG and list feedback. 1315 These are in queue for a -01 update. 1317 Appendix B. Open Issues 1319 [RFC Editor: This section is to be removed before publication] 1321 Check references to ensure all of them are still necessary 1323 Author's Address 1325 Jason Livingood 1326 Comcast Cable Communications 1327 One Comcast Center 1328 1701 John F. Kennedy Boulevard 1329 Philadelphia, PA 19103 1330 US 1332 Email: jason_livingood@cable.comcast.com 1333 URI: http://www.comcast.com