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