idnits 2.17.1 draft-ietf-v6ops-rfc6555bis-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6555, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 8, 2017) is 2574 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) == Missing Reference: 'Section 3' is mentioned on line 116, but not defined == Missing Reference: 'Section 4' is mentioned on line 153, but not defined == Missing Reference: 'Section 5' is mentioned on line 190, but not defined == Missing Reference: 'Section 6' is mentioned on line 158, but not defined ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network T. Pauly 3 Internet-Draft D. Schinazi 4 Obsoletes: 6555 (if approved) Apple Inc. 5 Intended status: Standards Track April 8, 2017 6 Expires: October 10, 2017 8 Happy Eyeballs Version 2: Better Connectivity Using Concurrency 9 draft-ietf-v6ops-rfc6555bis-00 11 Abstract 13 Many communication protocols operated over the modern Internet uses 14 host names. These often resolve to multiple IP addresses, each of 15 which may have different performance and connectivity 16 characteristics. Since specific addresses or address families (IPv4 17 or IPv6) may be blocked, broken, or sub-optimal on a network, clients 18 that attempt multiple connections in parallel have a higher chance of 19 establishing a connection sooner. This document specifies 20 requirements for algorithms that reduce this user-visible delay and 21 provides an example algorithm. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 10, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Hostname Resolution Query Handling . . . . . . . . . . . . . 3 61 3.1. Handling Multiple DNS Server Addresses . . . . . . . . . 4 62 4. Sorting Addresses . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Connection Attempts . . . . . . . . . . . . . . . . . . . . . 5 64 6. DNS Answer Changes during Happy Eyeballs Connection Setup . . 6 65 7. Summary of Configurable Values . . . . . . . . . . . . . . . 6 66 8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Path Maximum Transmission Unit Discovery . . . . . . . . 7 68 8.2. Application Layer . . . . . . . . . . . . . . . . . . . . 7 69 8.3. Hiding Operational Issues . . . . . . . . . . . . . . . . 8 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 12.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Appendix A. Differences from RFC6555 . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Many communication protocols operated over the modern Internet uses 82 host names. These often correspond to multiple IP addresses, whose 83 performance can vary. Since specific addresses or address families 84 (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, 85 clients that attempt multiple connections in parallel have a higher 86 chance of establishing a connection sooner. This document specifies 87 requirements for algorithms that reduce this user-visible delay and 88 provides an algorithm. 90 This documents expands on "Happy Eyeballs" [RFC6555], a technique of 91 reducing user-visible delays on dual-stack hosts. Now that this 92 approach has been deployed at scale and measured for several years, 93 the algorithm specification can be refined to improve its reliability 94 and generalization. This document recommends an algorithm of racing 95 resolved addresses that has several stages of ordering and racing to 96 avoid delays to the user whenever possible, while preferring the use 97 of IPv6. Specifically, it discusses how to handle DNS queries when 98 starting a connection on a dual-stack client, how to create an 99 ordered list of addresses to which to attempt connections, and how to 100 race the connection attempts. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 "Key words for use in RFCs to Indicate Requirement Levels" RFC 2119 108 [RFC2119]. 110 2. Overview 112 This document defines a method of connection establishment, defined 113 as "Happy Eyeballs Connection Setup". This approach has several 114 distinct phases: 116 1. Initiation of asynchronous DNS queries [Section 3] 118 2. Sorting of resolved addresses [Section 4] 120 3. Initiation of asynchronous connection attempts [Section 5] 122 4. Establishment of one connection, which cancels all other attempts 124 Note that this document assumes that the host address preference 125 policy favors IPv6 over IPv4. If the host is configured differently, 126 the recommendations in this document can be easily adapted. 128 3. Hostname Resolution Query Handling 130 When a client has both IPv4 and IPv6 connectivity, and is trying to 131 establish a connection with a named host, it needs to send out both 132 AAAA and A DNS queries. Both queries SHOULD be made as soon after 133 one another as possible, with the AAAA query made first, immediately 134 followed by the A query. 136 Implementations MUST NOT wait for both families of answers to return 137 before attempting connection establishment. If one query fails to 138 return, or takes significantly longer to return, waiting for the 139 second address family can significantly delay the connection 140 establishment of the first one. Therefore, the client MUST treat DNS 141 resolution as asynchronous. Note that if the platforms does not 142 offer an asynchronous DNS API, this behavior can be simulated by 143 making two separate synchronous queries on different threads, one per 144 address family. If the AAAA query returns first, the first IPv6 145 connection attempt MUST be immediately started. If the A query 146 returns first, the client SHOULD wait for a short time for the AAAA 147 response. This delay will be referred to as the "Resolution Delay". 148 The RECOMMENDED value for the Resolution Delay is 50 milliseconds. 149 If the AAAA response is received within the Resolution Delay period, 150 the client MUST immediately start the IPv6 connection attempt. If, 151 at the end of the Resolution Delay period, the AAAA response has not 152 been received but the A response has been received, the client SHOULD 153 proceed to Sorting Addresses [Section 4] and staggered connection 154 attempts [Section 5] using only the IPv4 addresses returned so far. 155 If the AAAA response arrives while these connection attempts are in 156 progress, but before any connection has been established, then the 157 newly received IPv6 addresses are incorporated into the list of 158 available candidate addresses [Section 6] and the process of 159 connection attempts will continue with the IPv6 addresses added, 160 until one connection is established. 162 3.1. Handling Multiple DNS Server Addresses 164 If multiple DNS server addresses are configured for the current 165 network, the client may have the option of sending its DNS queries 166 over IPv4 or IPv6. In keeping with the Happy Eyeballs approach, 167 queries SHOULD be sent over IPv6 first (note that this is not 168 referring to the sending of AAAA or A queries, but rather the address 169 of the DNS server itself). If DNS queries sent to the IPv6 address 170 do not receive responses, that address may be marked as penalized, 171 and queries can be sent to other DNS server addresses. 173 As native IPv6 deployments become more prevalent, and IPv4 addresses 174 are exhausted, it is expected that IPv6 connectivity will have 175 preferential treatment within networks. If a DNS server is 176 configured to be accessible over IPv6, IPv6 should be assumed to be 177 the preferred address family. 179 Client systems SHOULD NOT have an explicit limit to the number of DNS 180 servers that can be configured, either manually or by the network. 181 If such a limit is required by hardware limitations, it is 182 RECOMMENDED to use at least one address from each address family from 183 the available list. 185 4. Sorting Addresses 187 Before attempting to connect to any of the resolved addresses, the 188 client should define the order in which to start the attempts. Once 189 the order has been defined, the client can use a simple algorithm for 190 racing each option after a short delay [Section 5]. It is important 191 that the ordered list involves all addresses from both families, as 192 this allows the client to get the racing effect of Happy Eyeballs for 193 the entire list, not just the first IPv4 and first IPv6 addresses. 195 First, the client MUST sort the addresses using Destination Address 196 Selection ([RFC6724], Section 6). 198 If the client is stateful and has history of expected round-trip 199 times (RTT) for the routes to access each address, it SHOULD add a 200 Destination Address Selection rule between rules 8 and 9 that prefers 201 addresses with lower RTTs. If the client keeps track of which 202 addresses it has used in the past, it SHOULD add another destination 203 address selection rule between the RTT rule and rule 9, which prefers 204 used addresses over unused ones. This helps servers that use the 205 client's IP address for authentication, as is the case for TCP Fast 206 Open ([RFC7413]) and some HTTP cookies. This historical data MUST 207 NOT be used across networks, and SHOULD be flushed on network 208 changes. 210 Next, the client SHOULD modify the ordered list to interleave address 211 families. Whichever address family is first in the list should be 212 followed by an address of the other address family; that is, if the 213 first address in the sorted list is IPv6, then the first IPv4 address 214 should be moved up in the list to be second in the list. An 215 implementation MAY want to favor one address family more by allowing 216 multiple addresses of that family to be attempted before trying the 217 other family. The number of contiguous addresses of the first 218 address family will be referred to as the "First Address Family 219 Count", and can be a configurable value. 221 5. Connection Attempts 223 Once the list of addresses has been constructed, the client will 224 attempt to make connections. In order to avoid unreasonable network 225 load, connection attempts SHOULD NOT be made simultaneously. 226 Instead, one connection attempt to a single address is started first, 227 followed by the others in the list, one at a time. Starting a new 228 connection attempt does not affect previous attempts, as multiple 229 connection attempts may occur in parallel. Once one of the 230 connection attempts succeeds (generally when the TCP handshake 231 completes), all other connections attempts that have not yet 232 succeeded SHOULD be cancelled. Any address that was not yet 233 attempted as a connection SHOULD be ignored. 235 A simple implementation can have a fixed delay for how long to wait 236 before starting the next connection attempt. This delay is referred 237 to as the "Connection Attempt Delay". One recommended value for this 238 delay is 250 milliseconds. If the client has historical RTT data, it 239 can also use the expected RTT to choose a more nuanced delay value. 241 The recommended formula for calculating the delay after starting a 242 connection attempt is: MAX( 1.25 * RTT_MEAN + 4 * RTT_VARIANCE, 2 * 243 RTT_MEAN ), where the RTT values are based on the statistics for 244 previous address used. If the TCP implementation leverages 245 historical RTT data to compute SYN timeout, these algorithms should 246 match so that a new attempt will be started at the same time as the 247 previous is sending its second TCP SYN. While TCP implementations 248 often leverage an exponential backoff when they detect packet loss, 249 the "Connection Attempt Delay" SHOULD NOT such an aggressive backoff, 250 as it would harm user experience. 252 The Connection Attempt Delay MUST have a lower bound, especially if 253 it is computed using historical data. More specifically, a 254 subsequent connection MUST NOT be started within 10 milliseconds of 255 the previous attempt. The recommended minimum value is 100 256 milliseconds, which is referred to as the "Minimum Connection Attempt 257 Delay". This minimum value is required to avoid congestive collapse 258 in the presence of high packet loss rates. The Connection Attempt 259 Delay SHOULD have an upper bound, referred to as the "Maximum 260 Connection Attempt Delay". The current recommended value is 2 261 seconds. 263 6. DNS Answer Changes during Happy Eyeballs Connection Setup 265 If, during the course of connection establishment, the DNS answers 266 change either by adding resolved addresses (for example, due to DNS 267 push notifications [DNS-PUSH]), or removing previously resolved 268 addresses (for example, due to expiry of the TTL on that DNS record), 269 the client should react based on its current progress. 271 If an address is removed from the list that already had a connection 272 attempt started, the connection attempt SHOULD NOT be cancelled, but 273 rather be allowed to continue. If the removed address had not yet 274 had a connection attempt started, it SHOULD be removed from the list 275 of addresses to try. 277 If an address is added to the list, it should be sorted into the list 278 of addresses not yet attempted according to the rules above 279 (Section 4). 281 7. Summary of Configurable Values 283 The values that may be configured as defaults on a client for use in 284 Happy Eyeballs are as follows: 286 o Resolution Delay (Section 3): The time to wait for a AAAA response 287 after receiving an A response. RECOMMENDED at 50 milliseconds. 289 o First Address Family Count (Section 4): The number of addresses 290 belonging to the first address family (such as IPv6) that should 291 be attempted before attempting another address family. 292 RECOMMENDED as 1, or 2 to more aggressively favor one address 293 family. 295 o Connection Attempt Delay (Section 5): The time to wait between 296 connection attempts in the absence of RTT data. RECOMMENDED at 297 250 milliseconds. 299 o Minimum Connection Attempt Delay (Section 5): The minimum time to 300 wait between connection attempts. RECOMMENDED at 100 301 milliseconds. MUST NOT be less than 10 milliseconds. 303 o Maximum Connection Attempt Delay (Section 5): The maximum time to 304 wait between connection attempts. RECOMMENDED at 2 seconds. 306 As time advances, it is expected that the properties of networks will 307 evolve. For that reason, it is expected that these values will 308 change over time. Implementors should feel welcome to use different 309 values without changing this specification. In particular, IPv6 310 issues are expected to be less common, therefore the Resolution Delay 311 SHOULD be increased with time as client software is updated. 313 8. Limitations 315 Happy Eyeballs will handle initial connection failures at the TCP/IP 316 layer, however other failures or performance issues may still affect 317 the chosen connection. 319 8.1. Path Maximum Transmission Unit Discovery 321 Since Happy Eyeballs is only active during the initial handshake and 322 TCP does not pas the initial handshake, issues related to MTU can be 323 masked and go unnoticed during Happy Eyeballs. Solving this issue is 324 out of scope of this document. 326 8.2. Application Layer 328 If the DNS returns multiple application servers for a given service, 329 the application itself may not be operational and functional on all 330 of them. Common examples include Transport Layer Security (TLS) and 331 the Hypertext Transport Protocol (HTTP). 333 8.3. Hiding Operational Issues 335 It has been observed in practice that Happy Eyeballs can hide issues 336 in networks. For example, if a misconfiguration causes IPv6 to 337 consistently fail on a given network while IPv4 is still functional, 338 Happy Eyeballs may impair the operator's ability to notice the issue. 339 It is recommended that network operators deploy external means of 340 monitoring to ensure functionality of all address families. 342 9. Security Considerations 344 This memo has no direct security considerations. 346 10. IANA Considerations 348 This memo includes no request to IANA. 350 11. Acknowledgments 352 The authors thank Dan Wing, Andrew Yourtchenko, and everyone else who 353 worked on the original Happy Eyeballs design ([RFC6555]), Josh 354 Graessley, Stuart Cheshire, and the rest of team at Apple that helped 355 implement and instrument this algorithm, and Jason Fesler and Paul 356 Saab who helped measure and refine this algorithm. The authors would 357 also like to thank Nick Chettle, Paul Hoffman, Philip Homburg, Joe 358 Touch and James Woodyatt for their input and contributions. 360 12. References 362 12.1. Normative References 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, 366 DOI 10.17487/RFC2119, March 1997, 367 . 369 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 370 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 371 2012, . 373 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 374 "Default Address Selection for Internet Protocol Version 6 375 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 376 . 378 12.2. Informative References 380 [DNS-PUSH] 381 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 382 Work in Progress, draft-ietf-dnssd-push, March 2017. 384 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 385 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 386 . 388 Appendix A. Differences from RFC6555 390 "Happy Eyeballs: Success with Dual-Stack Hosts" [RFC6555] mostly 391 concentrates on how to stagger connections to a hostname that has an 392 AAAA and an A record. This document additionally discusses: 394 o how to perform DNS queries to obtain these addresses 396 o how to handle multiple addresses from each address family 398 o how to handle DNS updates while connections are being raced 400 o how to leverage historical information 402 Authors' Addresses 404 Tommy Pauly 405 Apple Inc. 406 1 Infinite Loop 407 Cupertino, California 95014 408 US 410 Email: tpauly@apple.com 412 David Schinazi 413 Apple Inc. 414 1 Infinite Loop 415 Cupertino, California 95014 416 US 418 Email: dschinazi@apple.com