idnits 2.17.1 draft-ietf-v6ops-happy-eyeballs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2011) is 4792 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-04) exists of draft-chen-mif-happy-eyeballs-extension-00 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops D. Wing 3 Internet-Draft A. Yourtchenko 4 Intended status: Standards Track Cisco 5 Expires: September 15, 2011 March 14, 2011 7 Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts 8 draft-ietf-v6ops-happy-eyeballs-01 10 Abstract 12 This document describes how a dual-stack client can determine the 13 functioning path to a dual-stack server. This provides a seamless 14 user experience during initial deployment of dual-stack networks and 15 during outages of IPv4 or outages of IPv6. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 15, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 53 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. URIs and hostnames . . . . . . . . . . . . . . . . . . . . 4 55 3.2. IPv6 connectivity . . . . . . . . . . . . . . . . . . . . 4 56 4. Client Recommendations . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Dualstack behavior . . . . . . . . . . . . . . . . . . . . 5 58 4.2. Implementation details . . . . . . . . . . . . . . . . . . 6 59 4.2.1. Applications that use address records . . . . . . . . 6 60 4.2.2. Applications that use the SRV records . . . . . . . . 8 61 5. Additional Considerations . . . . . . . . . . . . . . . . . . 9 62 5.1. Additional Network and Host Traffic . . . . . . . . . . . 9 63 5.2. Abandon Non-Winning Connections . . . . . . . . . . . . . 10 64 5.3. Flush or Expire Cache . . . . . . . . . . . . . . . . . . 10 65 5.4. Determining Address Type . . . . . . . . . . . . . . . . . 10 66 5.5. Debugging and Troubleshooting . . . . . . . . . . . . . . 10 67 5.6. DNS Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.7. Middlebox Issues . . . . . . . . . . . . . . . . . . . . . 11 69 5.8. Multiple Interfaces . . . . . . . . . . . . . . . . . . . 12 70 6. Content Provider Recommendations . . . . . . . . . . . . . . . 12 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 10.2. Informational References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 In order to use HTTP successfully over IPv6, it is necessary that the 82 user enjoys nearly identical performance as compared to IPv4. A 83 combination of today's applications, IPv6 tunneling and IPv6 service 84 providers, and some of today's content providers all cause the user 85 experience to suffer (Section 3). For IPv6, a content provider may 86 ensure a positive user experience by using a DNS white list of IPv6 87 service providers who peer directly with them, e.g. [whitelist]. 88 However, this is not scalable to all service providers worldwide, nor 89 is it scalable for other content providers to operate their own DNS 90 white list. 92 Instead, this document suggests a mechanism for applications to 93 quickly determine if IPv6 or IPv4 is the most optimal to connect to a 94 server. The suggestions in this document provide a user experience 95 which is superior to connecting to ordered IP addresses which is 96 helpful during the IPv6/IPv4 transition with dual stack hosts. 98 This problem is described also in [RFC1671]: "The dual-stack code 99 may get two addresses back from DNS; which does it use? During the 100 many years of transition the Internet will contain black holes. For 101 example, somewhere on the way from IPng host A to IPng host B there 102 will sometimes (unpredictably) be IPv4-only routers which discard 103 IPng packets. Also, the state of the DNS does not necessarily 104 correspond to reality. A host for which DNS claims to know an IPng 105 address may in fact not be running IPng at a particular moment; thus 106 an IPng packet to that host will be discarded on delivery. Knowing 107 that a host has both IPv4 and IPng addresses gives no information 108 about black holes. A solution to this must be proposed and it must 109 not depend on manually maintained information. (If this is not 110 solved, the dual stack approach is no better than the packet 111 translation approach.)" 113 Following the procedures in this document, once a certain address 114 family is successful, the application trends towards preferring that 115 address family. Thus, repeated use of the application DOES NOT cause 116 repeated probes over both address families. 118 While the application recommendations in this document are described 119 in the context of HTTP clients ("web browsers"), it is also useful 120 and applicable to other interactive applications. 122 Code which implements some of the ideas described in this document 123 has been made available [Perreault] [Andrews]. 125 2. Notational Conventions 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. Problem Statement 133 As discussed in more detail in Section 3.1, it is important that the 134 same URI and hostname be used for IPv4 and IPv6. Using separate 135 namespaces causes namespace fragmentation and reduces the ability for 136 users to share URIs and hostnames, and complicates printed material 137 that includes the URI or hostname. 139 As discussed in more detail in Section 3.2, IPv6 connectivity is 140 sometimes broken entirely or slower than native IPv4 connectivity. 142 3.1. URIs and hostnames 144 URIs are often used between users to exchange pointers to content -- 145 such as on social networks, email, instant messaging, or other 146 systems. Thus, production URIs and production hostnames containing 147 references to IPv4 or IPv6 will only function if the other party is 148 also using an application, OS, and a network that can access the URI 149 or the hostname. 151 3.2. IPv6 connectivity 153 When IPv6 connectivity is impaired, today's IPv6-capable web browsers 154 incur many seconds of delay before falling back to IPv4. This harms 155 the user's experience with IPv6, which will slow the acceptance of 156 IPv6, because IPv6 is frequently disabled in its entirety on the end 157 systems to improve the user experience. 159 Reasons for such failure include no connection to the IPv6 Internet, 160 broken 6to4 or Teredo tunnels, and broken IPv6 peering. 162 DNS Server Client Server 163 | | | 164 1. |<--www.example.com A?-----| | 165 2. |<--www.example.com AAAA?--| | 166 3. |---192.0.2.1------------->| | 167 4. |---2001:db8::1----------->| | 168 5. | | | 169 6. | |--TCP SYN, IPv6--->X | 170 7. | |--TCP SYN, IPv6--->X | 171 8. | |--TCP SYN, IPv6--->X | 172 9. | | | 173 10. | |--TCP SYN, IPv4------->| 174 11. | |<-TCP SYN+ACK, IPv4----| 175 12. | |--TCP ACK, IPv4------->| 177 Figure 1: Existing behavior message flow 179 The client obtains the IPv4 and IPv6 records for the server (1-4). 180 The client attempts to connect using IPv6 to the server, but the IPv6 181 path is broken (6-8), which consumes several seconds of time. 182 Eventually, the client attempts to connect using IPv4 (10) which 183 succeeds. 185 4. Client Recommendations 187 To provide fast connections for users, clients should make 188 connections quickly over various technologies, automatically tune 189 itself to avoid flooding the network with unnecessary connections 190 (i.e., for technologies that have not made successful connections), 191 and occasionally flush its self-tuning. 193 4.1. Dualstack behavior 195 If a TCP client supports IPv6 and IPv4 and is connected to IPv4 and 196 IPv6 networks, it can perform the procedures described in this 197 section. 199 DNS Server Client Server 200 | | | 201 1. |<--www.example.com A?-----| | 202 2. |<--www.example.com AAAA?--| | 203 3. |---192.0.2.1------------->| | 204 4. |---2001:db8::1----------->| | 205 5. | | | 206 6. | |==TCP SYN, IPv6===>X | 207 7. | |--TCP SYN, IPv4------->| 208 8. | |<-TCP SYN+ACK, IPv4----| 209 9. | |--TCP ACK, IPv4------->| 210 10. | |==TCP SYN, IPv6===>X | 212 Figure 2: Happy Eyeballs flow 1, IPv6 broken 214 In the diagram above, the client sends two TCP SYNs at the same time 215 over IPv6 (6) and IPv4 (7). In the diagram, the IPv6 path is broken 216 but has little impact to the user because there is no long delay 217 before using IPv4. The IPv6 path is retried until the application 218 gives up (10). 220 DNS Server Client Server 221 | | | 222 1. |<--www.example.com A?-----| | 223 2. |<--www.example.com AAAA?--| | 224 3. |---192.0.2.1------------->| | 225 4. |---2001:db8::1----------->| | 226 5. | | | 227 6. | |==TCP SYN, IPv6=======>| 228 7. | |--TCP SYN, IPv4------->| 229 8. | |<=TCP SYN+ACK, IPv6====| 230 9. | |<-TCP SYN+ACK, IPv4----| 231 10. | |==TCP ACK, IPv6=======>| 232 11. | |--TCP ACK, IPv4------->| 233 12. | |--TCP RST, IPv4------->| 235 Figure 3: Happy Eyeballs flow 2, IPv6 working 237 The diagram above shows a case where both IPv6 and IPv4 are working, 238 and IPv4 is abandoned (12). 240 4.2. Implementation details 242 4.2.1. Applications that use address records 244 This section details how to provide robust dual stack service for 245 both IPv6 and IPv4, so that the user perceives very fast application 246 response. 248 The TCP client application is configured with one application-wide 249 value of P. A positive value indicates a preference for IPv6 and a 250 negative value indicates a preference for IPv4. A value of 0 251 indicates equal weight, which means the A and AAAA queries and 252 associated connection attempts will be sent as quickly as possible. 253 The absolute value of P is the measure of a delay before initiating a 254 DNS lookup and a connection attempt on the other address family. 255 There are two P values maintained: one is application-wide and the 256 other is specific per each destination (hostname and port). 258 The algorithm attempts to delay the DNS query until it expects that 259 address family will be necessary; that is, if the preference is 260 towards IPv6, then AAAA will be queried immediately and the A query 261 will be delayed. 263 The TCP client application starts two concurrent execution flows 264 (they will be referred to as "threads" but this reference does not 265 imply the implementation detail of using the threading library, 266 merely the property of mutual concurrency) in order to minimize the 267 user-noticeable delay ("dead time") during the connection attempts: 269 thread 1: (IPv6) 271 * If P<0, wait for absolute value of p*10 milliseconds 273 * send DNS query for AAAA 275 * wait until DNS response is received 277 * Attempt to connect over IPv6 using TCP 279 thread 2: (IPv4) 281 * if P>0, wait for p*10 milliseconds 283 * send DNS query for A 285 * wait until DNS response is received 287 * Attempt to connect over IPv4 using TCP 289 The first thread that succeeds returns the completed connection to 290 the parent code and aborts the other thread (Section 5.2). 292 After a connection is successful, we want to adjust the application- 293 wide preference and the per-destination preference. The value of P 294 is incremented (decremented) each time an IPv6 (IPv4) connection wins 295 the race.. When a connection using the less-preferred address family 296 is successful, it indicates the wrong address family was used and the 297 value of P is halved: 299 o If P>0 (indicating IPv6 is preferred over IPv4) and the first 300 thread to finish was the IPv6 thread it indicates the IPv6 301 preference is correct and we need to re-enforce this by increasing 302 the application-wide P value by 1. However, if the first thread 303 to finish was the IPv4 thread it indicates an IPv6 connection 304 problem occurred and we need to aggressively prefer IPv4 more by 305 halving P and rounding towards 0. 307 o If P<0 (indicating IPv4 is preferred over IPv6) and the first 308 thread to finish was the IPv4 thread it indicates the preference 309 is correct and we need to re-enforce this gently by decreasing the 310 application-wide P value by 1. However, if the first thread to 311 finish was the IPv6 thread it indicates an IPv4 connection problem 312 and we need to aggressively avoid IPv4 by halving P and rounding 313 towards 0. 315 o If P=0 (indicating equal preference), P is incremented by one if 316 the first thread to complete was the IPv6 thread, or decremented 317 by one if the first thread to complete was the IPv4 thread. 319 After adjusting P, the resulting delay should never be larger than 4 320 seconds -- which is similar to the value used by many IPv6-capable 321 TCP client applications to switch to an alternate A or AAAA record. 323 Editor's Note 01: Proof of concept tests on fast networks show 324 that even smaller value (around 0.5 seconds) may be practical. 325 More extensive testing would be useful to find the best upper 326 boundary that still ensures a good user experience. 328 Editor's Note 02: A strict implementation of the above steps 329 results in "P" being adjusted if there are no AAAA records or are 330 no A records. This is undesirable. Thus, a future version of 331 this specification is expected to recommend that "P" only be 332 adjusted if there was both an A and AAAA record. 334 4.2.2. Applications that use the SRV records 336 For the purposes of this section, "client" is defined as the entity 337 initiating the connection. 339 For protocols which support DNS SRV [RFC2782], the client performs 340 the IN SRV query (e.g. IN SRV _xmpp-client._tcp.example.com) as 341 normal. The client MUST perform the following steps: 343 1. Sort all SRV records according to priority (lowest priority 344 first) 346 2. Process all of the SRV targets of the same priority with a weight 347 greater than 0: 349 A. Perform A/AAAA queries for each SRV target in parallel, as 350 described in Section 4.2.1 352 B. Connect to the IPv4/IPv6 addresses 354 C. If at least one connection succeeds, stop processing SRV 355 records 357 3. If there is no connection, process all of the SRV targets of the 358 same priority with a weight of 0, as per steps 2.1 through 2.3 359 above 361 4. Repeat steps 2.1 through 2.3 for the next priority, until a 362 connection is established or all SRV records have been exhausted 364 5. If there is still no connection, fallback to using the domain 365 (e.g. example.com), following steps 2.1 through 2.3 above 367 It is RECOMMENDED, but not required, for the client to cache the 368 winning connection's address information and reuse it on subsequent 369 connections. If a significant network event occurs (e.g. network 370 interface is activated/deactivated, IP address changes), the client 371 MUST forget the cached address information and perform all of the 372 steps from above. The definition of "significant network event" is 373 intentionally vague. 375 5. Additional Considerations 377 This section discusses considerations and requirements that are 378 common to new technology deployment. 380 5.1. Additional Network and Host Traffic 382 Additional network traffic and additional server load is created due 383 to these recommendations and mitigated by application-wide and per- 384 destination timer adjustments. The procedures described in this 385 document retain a quality user experience while transitioning from 386 IPv4-only to dual stack. The quality user experience benefits the 387 user but to the detriment of the network and server that are serving 388 the user. 390 5.2. Abandon Non-Winning Connections 392 It is RECOMMENDED that the non-winning connections be abandoned, even 393 though they could be used to download content. This is because some 394 web sites provide HTTP clients with cookies (after logging in) that 395 incorporate the client's IP address, or use IP addresses to identify 396 users. If some connections from the same HTTP client are arriving 397 from different IP addresses, such HTTP applications will break. It's 398 also important to abandon connections to avoid consuming server or 399 middlebox (e.g., NAT) resources (file descriptors, memory, TCP 400 control blocks) and avoid sending TCP or application-level keepalives 401 on otherwise unused connections. 403 5.3. Flush or Expire Cache 405 Because every network has different characteristics (e.g., working or 406 broken IPv6 connectivity) the IPv6/IPv4 preference value (P) SHOULD 407 be reset to its default whenever the host is connected to a new 408 network ([cx-osx], [cx-win]). However, in some instances the 409 application and the host are unaware the network connectivity has 410 changed so it is RECOMMENDED that per-destination values expire after 411 10 minutes of inactivity. 413 5.4. Determining Address Type 415 For some transitional technologies such as a dual-stack host, it is 416 easy for the application to recognize the native IPv6 address 417 (learned via a AAAA query) and the native IPv4 address (learned via 418 an A query). For other transitional technologies [RFC2766] it is 419 impossible for the host to differentiate a transitional technology 420 IPv6 address from a native IPv6 address (see Section 4.1 of 421 [RFC4966]). Replacement transitional technologies are attempting to 422 bridge this gap. It is necessary for applications to distinguish 423 between native and transitional addresses in order to provide the 424 most seamless user experience. 426 Application awareness of transitional technologies, if implemented, 427 SHOULD provide a facility to give the preference only to native IPv6 428 addresses. 430 5.5. Debugging and Troubleshooting 432 This mechanism is aimed at ensuring a reliable user experience 433 regardless of connectivity problems affecting any single transport. 434 However, this naturally means that applications employing these 435 techniques are by default less useful for diagnosing issues with any 436 particular transport. To assist in that regard, the applications 437 implementing the proposal in this document SHOULD also provide a 438 mechanism to revert the behavior to that of a default provided by the 439 operating system - the [RFC3484]. 441 [[[ To be discussed. 443 Some sites may wish to be informed when the the hosts adjust their 444 "P" value, in order to troubleshoot the underlying cause. To help 445 these sites, a strawman proposal is to send a syslog message or 446 other notification to an address that may be configured by a site 447 administrator in a centralized fashion. (The exact method TBD - 448 DHCP option, domain name, etc.) This syslog message should be 449 sent only first N times that the host expects to prefer IPv6 but 450 has to use IPv4. I.e. the first N times it decreases the value of 451 P. N - TBD. 453 ]]] 455 5.6. DNS Behavior 457 Unique to DNS AAAA queries are the problems described in [RFC4074] 458 which, if they still persist, require applications to perform an A 459 query before the AAAA query. 461 [[Editor's Note 03: It is believed these defective DNS servers 462 have long since been upgraded. If so, we can remove this 463 section.]] 465 5.7. Middlebox Issues 467 Some devices are known to exhibit what amounts to a bug, when the A 468 and AAAA requests are sent back-to-back over the same 4-tuple, and 469 drop one of the requests or replies [DNS-middlebox]. However, in 470 some cases fixing this behaviour may not be possible either due to 471 the architectural limitations or due to the administrative 472 constraints (location of the faulty device is unknown to the end 473 hosts or not controlled by the end hosts). The algorithm described 474 in this draft, in the case of this erroneous behaviour will 475 eventually pace the queries such that this issue is will be avoided. 476 The algorithm described in this draft also avoids calling the 477 operating system's getaddrinfo() with "any", which should prevent the 478 operating system from sending the A and AAAA queries on the same 479 port. 481 For the large part, these issues are believed to be fixed, in which 482 case the getaddrinfo() with AF_UNSPEC as the address family in its 483 hints. 485 5.8. Multiple Interfaces 487 Interaction of the suggestions in this document with multiple 488 interfaces, and interaction with the MIF working group, is for 489 further study ([I-D.chen-mif-happy-eyeballs-extension] is devoted to 490 this). 492 6. Content Provider Recommendations 494 Content providers SHOULD provide both AAAA and A records for servers 495 using the same DNS name for both IPv4 and IPv6. 497 7. Security Considerations 499 [[Placeholder.]] 501 See Section 5.2. 503 8. Acknowledgements 505 The mechanism described in this paper was inspired by Stuart 506 Cheshire's discussion at the IAB Plenary at IETF72, the author's 507 understanding of Safari's operation with SRV records, Interactive 508 Connectivity Establishment (ICE [RFC5245]), and the current IPv4/IPv6 509 behavior of SMTP mail transfer agents. 511 Thanks to Fred Baker, Jeff Kinzli, Christian Kuhtz, and Iljitsch van 512 Beijnum for fostering the creation of this document. 514 Thanks to Scott Brim, Rick Jones, Stig Venaas, Erik Kline, Bjoern 515 Zeeb, Matt Miller for providing feedback on the document. 517 Thanks to Javier Ubillos, Simon Perreault and Mark Andrews for the 518 active feedback and the experimental work on the independent 519 practical implementations that they created. 521 Also the authors would like to thank the following individuals who 522 participated in various email discussions on this topic: Mohacsi 523 Janos, Pekka Savola, Ted Lemon, Carlos Martinez-Cagnazzo, Simon 524 Perreault, Jack Bates, Jeroen Massar, Fred Baker, Javier Ubillos, 525 Teemu Savolainen, Scott Brim, Erik Kline, Cameron Byrne, Daniel 526 Roesen, Guillaume Leclanche, Cameron Byrne, Mark Smith, Gert Doering, 527 Martin Millnert, Tim Durack, Matthew Palmer. 529 9. IANA Considerations 531 This document has no IANA actions. 533 10. References 535 10.1. Normative References 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, March 1997. 540 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 541 specifying the location of services (DNS SRV)", RFC 2782, 542 February 2000. 544 [RFC3484] Draves, R., "Default Address Selection for Internet 545 Protocol version 6 (IPv6)", RFC 3484, February 2003. 547 10.2. Informational References 549 [Andrews] Andrews, M., "How to connect to a multi-homed server over 550 TCP", January 2011, . 553 [DNS-middlebox] 554 Various, "DNS middlebox behavior with multiple queries 555 over same source port", June 2009, 556 . 558 [I-D.chen-mif-happy-eyeballs-extension] 559 Chen, G., "Happy Eyeballs Extension for Multiple 560 Interfaces", draft-chen-mif-happy-eyeballs-extension-00 561 (work in progress), March 2011. 563 [Perreault] 564 Perreault, S., "Happy Eyeballs in Erlang", February 2011, 565 . 568 [RFC1671] Carpenter, B., "IPng White Paper on Transition and Other 569 Considerations", RFC 1671, August 1994. 571 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 572 Translation - Protocol Translation (NAT-PT)", RFC 2766, 573 February 2000. 575 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against 576 DNS Queries for IPv6 Addresses", RFC 4074, May 2005. 578 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 579 Address Translator - Protocol Translator (NAT-PT) to 580 Historic Status", RFC 4966, July 2007. 582 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 583 (ICE): A Protocol for Network Address Translator (NAT) 584 Traversal for Offer/Answer Protocols", RFC 5245, 585 April 2010. 587 [cx-osx] Adium, "AIHostReachabilityMonitor", June 2009, 588 . 590 [cx-win] Microsoft, "NetworkChange.NetworkAvailabilityChanged 591 Event", June 2009, . 596 [whitelist] 597 Google, "Google IPv6 DNS Whitelist", January 2009, 598 . 600 Authors' Addresses 602 Dan Wing 603 Cisco Systems, Inc. 604 170 West Tasman Drive 605 San Jose, CA 95134 606 USA 608 Email: dwing@cisco.com 610 Andrew Yourtchenko 611 Cisco Systems, Inc. 612 De Kleetlaan, 7 613 San Jose, Diegem B-1831 614 Belgium 616 Email: ayourtch@cisco.com