idnits 2.17.1 draft-pauly-taps-guidelines-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 7, 2017) is 2634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network T. Pauly 3 Internet-Draft Apple Inc. 4 Intended status: Informational February 7, 2017 5 Expires: August 11, 2017 7 Software Guidelines for Protocol Evolution 8 draft-pauly-taps-guidelines-00 10 Abstract 12 This document outlines a set of recommendations and guidelines for 13 how networking software should be designed to enable the development, 14 testing, and deployment of new protocols and protocol features. The 15 focus is primarily on the API contract that a client-side networking 16 library should present to applications using networking features, and 17 how that library can be architected to maximize flexibility and 18 longevity. 20 Specific areas of protocol development that should be enabled 21 include: 23 o Making security and privacy easy to use 25 o Reducing latency with 0-RTT protocols 27 o Allowing wider use of multi-stream protocols 29 o Providing a simple interface for multi-path protocols 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 11, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 67 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2. Guideline Summary . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Derived Endpoint . . . . . . . . . . . . . . . . . . . . 5 72 3.3. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.4. Connection . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.5. Multi-stream . . . . . . . . . . . . . . . . . . . . . . 6 75 3.6. Multi-path . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.7. 0-RTT Protocol . . . . . . . . . . . . . . . . . . . . . 6 77 4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 4.1. Application interfaces should be derived from usage 79 patterns . . . . . . . . . . . . . . . . . . . . . . . . 6 80 4.2. Connection establishment should attempt a tree of options 7 81 4.2.1. Derived Endpoint Racing . . . . . . . . . . . . . . . 8 82 4.2.2. Path Racing . . . . . . . . . . . . . . . . . . . . . 9 83 4.2.3. Protocol Stack Racing . . . . . . . . . . . . . . . . 9 84 4.2.4. Impacts of Racing on APIs . . . . . . . . . . . . . . 9 85 4.3. Parameters should not be protocol-specific . . . . . . . 10 86 4.4. Dynamically evaluate network state and operating system 87 policy . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 5. Guideline Adoption . . . . . . . . . . . . . . . . . . . . . 12 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 94 9.2. Informative References . . . . . . . . . . . . . . . . . 13 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 Wide deployments of networking protocols often lag behind the 100 specifications of those protocols. This means that network users 101 worldwide often are not using the latest protocol developments, and 102 the design of protocols must take into account the fact that they 103 will likely not be adopted quickly. There are many reasons for this 104 delay, but one significant cause is the difficulty for client 105 applications to take advantage of new features due to inflexible 106 software implementations. This is evidenced by the fact that 107 protocols that require changing an API (Application Programming 108 Interface) contract with applications are often difficult to deploy 109 at large scale. As an example, consider that modifying congestion 110 control algorithms (which generally has no API impact) is a fairly 111 common occurrence on modern operating systems, while changes such as 112 IPv6 or TCP Fast-Open [RFC7413] that require API modification can 113 take years or decades to deploy. While there are certainly protocols 114 that are held back by ossified networks, ossified networking APIs 115 also contribute to the problem. 117 This document outlines a set of recommendations and guidelines for 118 how networking software should be designed to enable the development, 119 testing, and deployment of new protocols and protocol features. The 120 focus is primarily on the API contract that a client-side networking 121 library should present to applications using networking features, and 122 how that library can be architected to maximize flexibility and 123 longevity. 125 1.1. Problem Statement 127 A common term for inflexibility of networking protocols is 128 "ossification". Ossification can take many forms, but all of these 129 result in the inability to change from existing patterns of protocol 130 usage. This harms networks and clients by reducing their 131 functionality, security, and efficiency. In some cases, ossification 132 is imposed by "middleboxes" such as firewalls and NAT gateways. To 133 remedy these cases, there must either be change in the middleboxes, 134 or concessions made by new protocols to account for these 135 middleboxes. In other cases, however, the ossification is a side- 136 effect of software architecture. Protocol features that do not fit 137 the traditional POSIX Sockets model, for example, are difficult to 138 enable. 140 Of course, not all inflexibility is incorrect. Applications often 141 require a deterministic set of features, and changing the fundamental 142 assumptions of the protocols they use could lead to non-functional 143 networks. To account for this, it is helpful to distinguish between 144 the reasons for inflexibility: 146 o Specificity, or voluntary inflexibility. An application requires 147 a secure, reliable stream that connects to its web server. Based 148 on the available protocols, this means the application should use 149 HTTP over TLS over TCP. Using other protocols is not an option 150 here. 152 o Ossification, or involuntary inflexibility. An application cannot 153 use a fast-open protocol such as TCP Fast-Open because its API 154 does not allow sending data before a connection is established; or 155 an application was written with sockaddr-based APIs and throws an 156 error if it tries to interpret IPv6 addresses. 158 If the inflexibility of applications is limited to only what must be 159 specified, and no more, the protocol stack implementation will have 160 more freedom to adopt and offer new features. Achieving this goal 161 requires careful consideration of not only what a protocol does, and 162 how it is exposed to applications, but also how that exposure may 163 interact with other protocol features and potentially ossify 164 implementations. 166 Specific areas of protocol development that should be enabled 167 include: 169 o Making security and privacy easy to use 171 o Reducing latency with 0-RTT protocols 173 o Allowing wider use of multi-stream protocols 175 o Providing a simple interface for multi-path protocols 177 1.2. Requirements Language 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [RFC2119]. 183 2. Guideline Summary 185 Each of the guidelines described in this document is a direct 186 response to a form of software ossification. 188 1. Application interfaces should be derived from usage patterns 190 2. Connection establishment should attempt a tree of options 192 3. Parameters should not be protocol-specific 193 4. Dynamically evaluate network state and operating system policy 195 These guidelines are explored in more detail below. 197 3. Terminology 199 This document uses some specific terminology in the explanation of 200 the guidelines. 202 3.1. Endpoint 204 An identifier for a network service. Generally there is a concept of 205 both a local and remote endpoint. Endpoints are the targets of 206 network connections. If an endpoint of a given type cannot be 207 directly used, it should be resolved into one or more endpoints of 208 another type. Examples of endpoint types include: 210 o IP address + port 212 o Hostname + port 214 o Service name + type + domain 216 3.2. Derived Endpoint 218 A derived endpoint is an endpoint that is not the original target of 219 an API client, but an endpoint derived from that original endpoint. 220 Derivation may take the form of hostname resolution into addresses, 221 synthesis between address types, or changing to a different endpoint 222 entirely based on a configuration requirement. For example, if a 223 proxy server must be used for a connection, the endpoint that 224 represents the proxy is a derived endpoint. 226 3.3. Path 228 A view of network properties that can be used to communicate to an 229 endpoint from the current system. This is sometimes referred to as a 230 Provisioning Domain (PvD) [RFC7556]. One way to view a path is as a 231 route lookup with more data included than just the next hop. The 232 path may include properties of the addresses and routes being used, 233 the network interfaces being used, and other metadata about the 234 network learned from configuration or negotiation. 236 3.4. Connection 238 A flow of data between two endpoints, using one or more paths. An 239 connection is created with a set of parameters indicating client 240 preferences. 242 3.5. Multi-stream 244 Any case in which more than one logical stream of data, or responses 245 and replies, are multiplexed over a single network connection. 247 3.6. Multi-path 249 Any case in which a connection uses more than one path off of the 250 local device to split up or migrate its traffic. 252 3.7. 0-RTT Protocol 254 Any protocol that can send upper level protocol data without first 255 conduction a handshake or negotiation at its own layer. Examples 256 include TCP Fast-Open and TLS 1.3 [I-D.ietf-tls-tls13]. 258 4. Guidelines 260 4.1. Application interfaces should be derived from usage patterns 262 Many protocols share similar usage patterns. Some of these take the 263 form of connection lifetime: most protocols have a step of 264 establishing a connection, followed by a step in which communication 265 is established and data can be transferred, followed by a step in 266 which the connection is removed. For protocols like TCP and TLS 267 [RFC5246], the connection may be established through a handshake of 268 packets; for protocols like UDP, the connection may be implicit. 269 Other usage patterns include the model for data transfer: TCP, TLS, 270 and various proxying protocols provide a bi-directional stream of 271 bytes; UDP and DTLS [RFC6347] provide datagram transport; and HTTP/2 272 [RFC7540] and SCTP [RFC4960] can provide message or chunk-based 273 semantics. 275 Ossification is introduced to the stack when an application must use 276 different code for two protocols that both offer reliable, connected 277 stream abstractions. An application that was written using POSIX 278 Sockets to access TCP cannot easily switch to another stream 279 abstraction that is not provided beneath the sockets API. Unifying 280 APIs that have the same data transfer model is particularly important 281 for making it easy for applications to adopt security or privacy 282 protocols. 284 The recommendation to promote flexibility is to provide a set of 285 common, primitive APIs for interacting with networking connections 286 that may be used generically for all protocols. 288 Connection types: 290 o Connected (between local and remote endpoint) 292 o Responder (listens for connections, or single messages from remote 293 endpoints) 295 Data transfer modes: 297 o Streams provide the abstraction of a continuous flow of data in 298 each direction, without defined boundaries. Streams imply 299 reliability and consistent ordering within the stream 301 o Datagrams provide a model of individual data chunks sent in each 302 direction. Datagrams do not necessarily imply reliability or 303 ordering between one another. 305 o Messages provide a model of reliable data chunks that can be sent 306 in each direction, with a concept of replies and message metadata 307 (such as an identifier or header values). 309 4.2. Connection establishment should attempt a tree of options 311 Networking APIs should not assume that a connection attempt request 312 by an application should only correspond to a single set of 313 connection establishment attempts at the protocol level. If only one 314 option is allowed per attempt, the application must make a choice 315 about which protocol to use, which endpoint (such as IP address) to 316 target, and which network interface to use. An application does not 317 necessarily have all of the necessary information to make this choice 318 unless it has a high degree of knowledge about the network state 319 through the operating system's interfaces; and even if it can make a 320 nuanced decision, it will likely make some assumptions that are based 321 on the networks it was developed and tested in. To be specific, if 322 an application must choose between several IPv4 and IPv6 addresses, 323 and was developed in an IPv4-environment, it is likely that it will 324 tend towards choosing IPv4 or not working correctly with IPv6. 326 The idea of racing attempts for IPv4 and IPv6 addresses, known as 327 "Happy Eyeballs" [RFC6555], is the classic example of the multiple- 328 options approach. Since networks may be ossified around only 329 supporting IPv4, a Happy Eyeballs client will support attempting both 330 IPv4 and IPv6 addresses for a hostname in parallel, generally with 331 one attempt starting shortly after the first if the connection is not 332 immediately established. Happy Eyeballs allowed IPv6 to be more 333 widely and successfully used throughout the Internet, since clients 334 could adjust to ossified networks, but still prefer certain 335 protocols. 337 This approach should not be limited to racing IPv4 and IPv6 attempts. 338 Its fundamental premise applies to many scenarios, and allows clients 339 to elude ossification caused by networks. 341 There are several types of racing that can occur during connection 342 establishment: 344 o Derived Endpoints 346 o Path (Interface or Provisioning Domain (PvD)) 348 o Protocol stacks 350 Each of these kinds of racing represents a potential branching point 351 of a tree of options for a single connection establishment. They may 352 be used in combination. The recommended order of operations for 353 branching is to first branch for multiple paths, then branch for 354 protocol stack options, and finally branch one or more times for 355 derived endpoints. This order is based on the fact that protocol 356 options and endpoint derivation (resolution) is often specific to a 357 Path. 359 4.2.1. Derived Endpoint Racing 361 If an connection originally targets a single endpoint, there may be 362 multiple endpoints of a different type that can be derived from the 363 original. The connection library should order the derived endpoints 364 preference and expected performance. 366 DNS hostname-to-address resolution is the most common endpoint 367 derivation step. When trying to connect to a hostname endpoint on a 368 traditional IP network, the implementation should send DNS queries 369 for both A (IPv4) and AAAA (IPv6) records. Once the client has 370 received responses for both address families, it should order the 371 addresses in such a way that it will try both IPv4 and IPv6 if 372 possible. Each resolved address endpoint represents a new branch of 373 the tree, which can be attempted independently from other addresses. 374 The connection attempt over each address should start after some 375 delay, based on the expected Round Trip Time for the route to the 376 address. Once the connection establishment for one address has 377 completed, the other branches should be cancelled. 379 DNS-Based Service Discovery can also provide an endpoint derivation 380 step. When trying to connect to a named service, the client may 381 discover one or more hostname and port pairs on the local network 382 using multicast DNS. These hostnames should each be treated as a 383 branch which can be attempted independently from other hostnames. 385 Each of these hostnames may also resolve to one or more addresses, 386 thus creating two layers of branching. 388 4.2.2. Path Racing 390 If a client has multiple network interfaces available to it, such as 391 mobile client with both Wi-Fi and Cellular connectivity, it can 392 attempt a connection over either interface. This represents a branch 393 point in the connection establishment. Like with derived endpoints, 394 the interfaces should be ranked based on preference, policy, and 395 performance. Attempts should be started on one interface, and then 396 on other interfaces successively after delays based on expected RTT. 397 Once a connection has been established over one interface, attempts 398 on other interfaces should be cancelled. 400 This same approach applies to any situation in which the client is 401 aware of multiple links or view of the network. Multiple Paths, each 402 with a coherent set of addresses, routes, DNS server, and more, may 403 share a single interface; they may also represent virtual interface 404 services such as Virtual Private Networks (VPNs). 406 4.2.3. Protocol Stack Racing 408 Differences in possible protocol compositions and options can also 409 provide a branching point in connection establishment. This allows 410 clients to be resilient to situations in which a certain protocol is 411 not functioning on a network, or a server. 413 A common case in which this approach is used is for connections with 414 optional proxy server configurations. A single connection may be 415 allowed to use an HTTP-based proxy, a SOCKS-based proxy, or connect 416 directly. These options should be ranked and tried in succession. 418 This approach also allows a client to attempt different protocol 419 stacks that may enhance performance characteristics if possible on 420 the network. For example, a UDP-based protocol stack could be 421 attempted first, and if it fails to establish the connection, a TCP- 422 based protocol stack can be attempted. 424 4.2.4. Impacts of Racing on APIs 426 The fact that multiple underlying protocol negotations may be 427 attempted for a single logical connection leads to some restrictions 428 on what APIs can guarantee. 430 o For performance reasons, the call to start a connection should 431 block and wait until the connection is established, since this may 432 involve many more negotiations than one TCP handshake. 434 o Generally, writing or reading should be not be allowed until the 435 connection is ready (or connected), since reading or writing 436 across multiple protocol stack attempts breaks the abstraction of 437 a single flow of data. The exception to this is when the 438 application needs to write 0-RTT data. If some data is sent out 439 as 0-RTT data on one connection attempt, that data must be stored 440 to be possible re-written on other 0-RTT attempts, or on whichever 441 connection attempt ends up succeeding. 443 o Any APIs that expose properties about a connection should not 444 return information until the connection racing has completed, 445 since the information will differ between attempts. 447 4.3. Parameters should not be protocol-specific 449 Applications that rely on implementation details of a protocol can 450 contribute to network stack ossification. Programming interfaces 451 should not expose options that are specific to one protocol. 452 Instead, parameters should describe usage patterns and client 453 intentions. 455 APIs should be audited carefully to avoid introducing functions and 456 parameters that can limit future protocols developments. It should 457 generally be possible to allow clients to have the necessary control 458 over protocols to function well in a protocol-agnostic fashion. 460 For example, a protocol-specific parameter would enable the LEDBAT 461 congestion control algorithm on TCP [RFC6817]. This potentially 462 becomes meaningless if another protocol that doesn't use equivalent 463 congestion control should be used. Either the connection will not be 464 able to use anything other than TCP, or else the request of the 465 client will not be respected. If the API instead offers a parameter 466 to specify that delay is acceptable and the traffic is considered a 467 background transfer, LEDBAT can be inferred for TCP, and other 468 protocols could adjust their behavior as well. 470 Another example is the interface exposed for MPTCP [RFC6824] subflow 471 management. If a client directly calls a function to open a new 472 subflow on a specific interface, the API becomes highly specific to 473 MPTCP. The client will need to check to see if MPTCP was 474 successfully negotiated before trying to open a new subflow, or else 475 it will receive unexpected errors. If the interface instead offers a 476 parameter to list which interfaces and interface types are allowed or 477 prohibited, along with preferences for how to distribute data flows 478 when possible, the client does not need to be directly aware of the 479 multipath protocol. These preferences can even be used by non- 480 multipath protocols, such as when setting the order of the list of 481 paths to race. 483 An ideal security interface should work in a similar way. A client 484 should be able to provide its credentials and evaluate the 485 credentials of the remote peer, without relying on details of 486 specific implementation details of TLS. Security should be a 487 fundamental part of the networking model, and be provided beneath the 488 connection API. 490 This guideline is the basis for creating a common interface for any 491 data pipe over a network, whether that is TCP, UDP, TLS, or an 492 application-protocol (HTTP/2 or QUIC) stream. 494 4.4. Dynamically evaluate network state and operating system policy 496 Even if there are no other impediments to adopting new protocol or 497 protocol options, an implementation may ossify if it has no way to 498 determine when a different protocol or set of options should be used. 499 Without information about which endpoint is preferred, endpoint 500 racing degenerates to deterministically trying the same option first 501 every time; without knowing if use of multiple interfaces is allowed, 502 a client will always use its default interface; without information 503 about which protocols should be used to certain endpoints on certain 504 interfaces, there can be no meaningful racing of protocols. 506 In order to take advantage of flexibility, an implementation should 507 dynamically evaluate the combination of three elements: 509 o Client requirements and prohibitions 511 o Current properties of each path 513 o System policies for network usage 515 Policies should be evaluated for each endpoint that is being 516 evaluated in the connection establishment tree, since a client should 517 not assume that conditions are the same for all endpoints. Two 518 different hostnames may prefer different paths (an external or 519 private internal network, for example), and two different addresses 520 may use different routes, and thus different paths. Different routes 521 may also imply different historical RTT values, which can influence 522 the preference and timing for racing endpoints. 524 System policies may be specific to application or service properties. 525 On the system, one application may have more privileges or permission 526 than another, allowing it to use other interfaces. An application 527 may also be required to use a specific VPN or proxy for security 528 reasons. 530 A system may also have efficiency reasons to load balance eligible 531 processes across different paths, or prefer to reuse paths that are 532 currently active. Checking the policy with centralized system entity 533 allows the connections to choose paths that coordinate with other 534 connections on the system. 536 5. Guideline Adoption 538 The original POSIX Sockets API does not directly contradict any of 539 these guidelines: indeed, it represents the degenerate case of a 540 connection in which there are no derived endpoints (because 541 connections are made with an IP address and port), the default or 542 bound interface is always used, and there is only one protocol option 543 per data mode (TCP for streams, UDP for datagrams). 545 However, as the common interface of applications with the network 546 moves up to target resolvable endpoints, work on multi-interface 547 devices, with protocol stacks that require security and multi-path 548 and multi-stream support, the design must not be compromised in a way 549 that would lead to network ossification. 551 Any of these guidelines can be implemented independently to 552 incrementally enhance an existing API. A complete adoption will, 553 however, provide the most flexibility for clients to adopt new 554 protocols and protocol features. 556 6. Security Considerations 558 This memo has no direct security considerations. 560 7. IANA Considerations 562 This memo includes no request to IANA. 564 8. Acknowledgments 566 Thanks to Josh Graessley and Stuart Cheshire for their help in the 567 design of the original implementation of Happy Eyeballs for Apple 568 that began this work. 570 9. References 572 9.1. Normative References 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, 576 DOI 10.17487/RFC2119, March 1997, 577 . 579 9.2. Informative References 581 [I-D.ietf-tls-tls13] 582 Rescorla, E., "The Transport Layer Security (TLS) Protocol 583 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 584 October 2016. 586 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 587 RFC 4960, DOI 10.17487/RFC4960, September 2007, 588 . 590 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 591 (TLS) Protocol Version 1.2", RFC 5246, 592 DOI 10.17487/RFC5246, August 2008, 593 . 595 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 596 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 597 January 2012, . 599 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 600 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 601 2012, . 603 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 604 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 605 DOI 10.17487/RFC6817, December 2012, 606 . 608 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 609 "TCP Extensions for Multipath Operation with Multiple 610 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 611 . 613 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 614 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 615 . 617 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 618 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 619 DOI 10.17487/RFC7540, May 2015, 620 . 622 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 623 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 624 . 626 Author's Address 628 Tommy Pauly 629 Apple Inc. 630 1 Infinite Loop 631 Cupertino, California 95014 632 US 634 Email: tpauly@apple.com