--- 1/draft-ietf-taps-transports-12.txt 2016-12-05 08:13:27.722264959 -0800 +++ 2/draft-ietf-taps-transports-13.txt 2016-12-05 08:13:27.822267424 -0800 @@ -1,55 +1,55 @@ Network Working Group G. Fairhurst, Ed. Internet-Draft University of Aberdeen Intended status: Informational B. Trammell, Ed. -Expires: April 28, 2017 M. Kuehlewind, Ed. +Expires: June 8, 2017 M. Kuehlewind, Ed. ETH Zurich - October 25, 2016 + December 05, 2016 Services provided by IETF transport protocols and congestion control mechanisms - draft-ietf-taps-transports-12 + draft-ietf-taps-transports-13 Abstract - This document describes, surveys, classifies and compares the - protocol mechanisms provided by existing IETF protocols, as - background for determining a common set of transport services. It - examines the Transmission Control Protocol (TCP), Multipath TCP, the - Stream Control Transmission Protocol (SCTP), the User Datagram - Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol - (DCCP), the Internet Control Message Protocol (ICMP), the Realtime - Transport Protocol (RTP), File Delivery over Unidirectional - Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), - and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security - (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol - (HTTP), when HTTP is used as a pseudotransport. This survey provides + This document describes, surveys, and classifies the protocol + mechanisms provided by existing IETF protocols, as background for + determining a common set of transport services. It examines the + Transmission Control Protocol (TCP), Multipath TCP, the Stream + Control Transmission Protocol (SCTP), the User Datagram Protocol + (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the + Internet Control Message Protocol (ICMP), the Realtime Transport + Protocol (RTP), File Delivery over Unidirectional Transport/ + Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), and NACK- + Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), + Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), + when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 28, 2017. + This Internet-Draft will expire on June 8, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -66,21 +66,21 @@ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Existing Transport Protocols . . . . . . . . . . . . . . . . 6 3.1. Transport Control Protocol (TCP) . . . . . . . . . . . . 6 3.1.1. Protocol Description . . . . . . . . . . . . . . . . 6 3.1.2. Interface description . . . . . . . . . . . . . . . . 8 3.1.3. Transport Features . . . . . . . . . . . . . . . . . 8 3.2. Multipath TCP (MPTCP) . . . . . . . . . . . . . . . . . . 9 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 3.2.2. Interface Description . . . . . . . . . . . . . . . . 10 3.2.3. Transport features . . . . . . . . . . . . . . . . . 10 - 3.3. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 10 + 3.3. User Datagram Protocol (UDP) . . . . . . . . . . . . . . 11 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 3.3.2. Interface Description . . . . . . . . . . . . . . . . 12 3.3.3. Transport Features . . . . . . . . . . . . . . . . . 12 3.4. Lightweight User Datagram Protocol (UDP-Lite) . . . . . . 13 3.4.1. Protocol Description . . . . . . . . . . . . . . . . 13 3.4.2. Interface Description . . . . . . . . . . . . . . . . 13 3.4.3. Transport Features . . . . . . . . . . . . . . . . . 14 3.5. Stream Control Transmission Protocol (SCTP) . . . . . . . 14 3.5.1. Protocol Description . . . . . . . . . . . . . . . . 14 3.5.2. Interface Description . . . . . . . . . . . . . . . . 16 @@ -100,37 +100,37 @@ 3.8.3. Transport Features . . . . . . . . . . . . . . . . . 27 3.9. Hypertext Transport Protocol (HTTP) over TCP as a pseudotransport . . . . . . . . . . . . . . . . . . . . . 27 3.9.1. Protocol Description . . . . . . . . . . . . . . . . 28 3.9.2. Interface Description . . . . . . . . . . . . . . . . 29 3.9.3. Transport features . . . . . . . . . . . . . . . . . 29 3.10. File Delivery over Unidirectional Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC) . . . . . . 30 3.10.1. Protocol Description . . . . . . . . . . . . . . . . 31 3.10.2. Interface Description . . . . . . . . . . . . . . . 32 - 3.10.3. Transport Features . . . . . . . . . . . . . . . . . 33 + 3.10.3. Transport Features . . . . . . . . . . . . . . . . . 32 3.11. NACK-Oriented Reliable Multicast (NORM) . . . . . . . . . 33 - 3.11.1. Protocol Description . . . . . . . . . . . . . . . . 34 + 3.11.1. Protocol Description . . . . . . . . . . . . . . . . 33 3.11.2. Interface Description . . . . . . . . . . . . . . . 35 3.11.3. Transport Features . . . . . . . . . . . . . . . . . 35 - 3.12. Internet Control Message Protocol (ICMP) . . . . . . . . 36 + 3.12. Internet Control Message Protocol (ICMP) . . . . . . . . 35 3.12.1. Protocol Description . . . . . . . . . . . . . . . . 36 3.12.2. Interface Description . . . . . . . . . . . . . . . 37 3.12.3. Transport Features . . . . . . . . . . . . . . . . . 37 4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 37 5. Transport Features . . . . . . . . . . . . . . . . . . . . . 38 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 10. Informative References . . . . . . . . . . . . . . . . . . . 42 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction Internet applications make use of the Services provided by a Transport protocol, such as TCP (a reliable, in-order stream protocol) or UDP (an unreliable datagram protocol). We use the term "Transport Service" to mean the end-to-end service provided to an application by the transport layer. That service can only be provided correctly if information about the intended usage is supplied from the application. The application may determine this @@ -140,23 +140,24 @@ Transport Services are reliable delivery, ordered delivery, content privacy to in-path devices, and integrity protection. The IETF has defined a wide variety of transport protocols beyond TCP and UDP, including SCTP, DCCP, MPTCP, and UDP-Lite. Transport services may be provided directly by these transport protocols, or layered on top of them using protocols such as WebSockets (which runs over TCP), RTP (over TCP or UDP) or WebRTC data channels (which run over SCTP over DTLS over UDP or TCP). Services built on top of UDP or UDP-Lite typically also need to specify additional mechanisms, - including a congestion control mechanism (such as NewReno, TFRC or - LEDBAT). This extends the set of available Transport Services beyond - those provided to applications by TCP and UDP. + including a congestion control mechanism (such as NewReno [RFC6582], + TFRC [RFC5348] or LEDBAT [RFC6817]). This extends the set of + available Transport Services beyond those provided to applications by + TCP and UDP. The transport protocols described in this document provide a basis for the definition of transport services provided by common protocols, as background for the TAPS working group. The protocols listed here were chosen to help expose as many potential transport services as possible, and are not meant to be a comprehensive survey or classification of all transport protocols. 1.1. Overview of Transport Features @@ -323,25 +324,28 @@ transport service not to delay data. By default, TCP segment partitioning uses Nagle's algorithm [RFC0896] to buffer data at the sender into large segments, potentially incurring sender-side buffering delay; this algorithm can be disabled by the sender to transmit more immediately, e.g., to reduce latency for interactive sessions. TCP provides an "urgent data" function for limited out-of-order delivery of the data. This function is deprecated [RFC6093]. + A RESET control message may be used to close a TCP session [RFC0793]. + A mandatory checksum provides a basic integrity check against misdelivery and data corruption over the entire packet. Applications that require end to end integrity of data are recommended to include a stronger integrity check of their payload data. The TCP checksum - does not support partial payload protection (as in DCCP/UDP-Lite). + [RFC1071] [RFC2460] does not support partial payload protection (as + in DCCP/UDP-Lite). TCP supports only unicast connections. 3.1.2. Interface description A User/TCP Interface is defined in [RFC0793] providing six user commands: Open, Send, Receive, Close, Status. This interface does not describe configuration of TCP options or parameters beside use of the PUSH and URGENT flags. @@ -487,22 +492,22 @@ independent messages, ordinarily called datagrams. It provides detection of payload errors and misdelivery of packets to an unintended endpoint, either of which result in discard of received datagrams, with no indication to the user of the service. It is possible to create IPv4 UDP datagrams with no checksum, and while this is generally discouraged [RFC1122] [I-D.ietf-tsvwg-rfc5405bis], certain special cases permit this use. These datagrams rely on the IPv4 header checksum to protect from misdelivery to an unintended endpoint. IPv6 does not permit UDP - datagrams with no checksum, although in certain cases this rule may - be relaxed [RFC6935]. + datagrams with no checksum, although in certain cases [RFC6936] this + rule may be relaxed [RFC6935]. UDP does not provide reliability and does not provide retransmission. Messages may be re-ordered, lost, or duplicated in transit. Note that due to the relatively weak form of checksum used by UDP, applications that require end to end integrity of data are recommended to include a stronger integrity check of their payload data. Because UDP provides no flow control, a receiving application that is unable to run sufficiently fast, or frequently, may miss messages. @@ -511,21 +516,20 @@ messages from other protocols (e.g., TCP) when sharing the same network path. On transmission, UDP encapsulates each datagram into a single IP packet or several IP packet fragments. This allows a datagram to be larger than the effective path MTU. Fragments are reassembled before delivery to the UDP receiver, making this transparent to the user of the transport service. When the jumbograms are supported, larger messages may be sent without performing fragmentation. - Applications that need to provide fragmentation UDP on its own does not provide support for segmentation, receiver flow control, congestion control, PathMTU discovery/PLPMTUD, or ECN. Applications that require these features need to provide them on their own, or by using a protocol over UDP that provides them [I-D.ietf-tsvwg-rfc5405bis]. 3.3.2. Interface Description [RFC0768] describes basic requirements for an API for UDP. Guidance on use of common APIs is provided in [I-D.ietf-tsvwg-rfc5405bis]. @@ -737,21 +740,22 @@ services provided by SCTP, such as un-ordered delivery or partial reliability. Therefore, the use of DTLS over SCTP has been specified in [RFC6083] to overcome these limitations. When using DTLS over SCTP, the application can use almost all services provided by SCTP. [I-D.ietf-tsvwg-natsupp] defines methods for endpoints and middleboxes to provide NAT traversal for SCTP over IPv4. For legacy NAT traversal, [RFC6951] defines the UDP encapsulation of SCTP- packets. Alternatively, SCTP packets can be encapsulated in DTLS packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The - latter encapsulation is used within the WebRTC context. + latter encapsulation is used within the WebRTC + [I-D.ietf-rtcweb-transports] context. SCTP has a well-defined API, described in the next subsection. 3.5.2. Interface Description [RFC4960] defines an abstract API for the base protocol. This API describes the following functions callable by the upper layer of SCTP: Initialize, Associate, Send, Receive, Receive Unsent Message, Receive Unacknowledged Message, Shutdown, Abort, SetPrimary, Status, Change Heartbeat, Request Heartbeat, Get SRTT Report, Set Failure @@ -801,23 +805,22 @@ are only accepted in an authenticated way, and get the list of chunks which are accepted by the local and remote end point in an authenticated way. o the SCTP Dynamic Address Reconfiguration extension defined in [RFC5061]. It allows to manually add and delete local addresses for SCTP associations and the enabling of automatic address addition and deletion. Furthermore the peer can be given a hint for choosing its primary path. - For the following SCTP protocol extensions the BSD Sockets API - extension is defined in the document specifying the protocol - extensions: + A BSD Sockets API extension has been defined in the documents that + specify the following SCTP protocol extensions: o the SCTP Stream Reconfiguration extension defined in [RFC6525]. The API allows to trigger the reset operation for incoming and outgoing streams and the whole association. It provides also a way to notify the association about the corresponding events. Furthermore the application can increase the number of streams. o the UDP Encapsulation of SCTP packets extension defined in [RFC6951]. The API allows the management of the remote UDP encapsulation port. @@ -1028,26 +1031,26 @@ 3.7. Transport Layer Security (TLS) and Datagram TLS (DTLS) as a pseudotransport Transport Layer Security (TLS) [RFC5246] and Datagram TLS (DTLS) [RFC6347] are IETF protocols that provide several security-related features to applications. TLS is designed to run on top of a reliable streaming transport protocol (usually TCP), while DTLS is designed to run on top of a best-effort datagram protocol (UDP or DCCP [RFC5238]). At the time of writing, the current version of TLS - is 1.2, defined in [RFC5246]; work on TLS version 1.3 is nearing - completion. DTLS provides nearly identical functionality to - applications; it is defined in [RFC6347] and its current version is - also 1.2. The TLS protocol evolved from the Secure Sockets Layer - (SSL) protocols developed in the mid-1990s to support protection of - HTTP traffic. + is 1.2, defined in [RFC5246]; work on TLS version 1.3 + [I-D.ietf-tls-tls13] nearing completion. DTLS provides nearly + identical functionality to applications; it is defined in [RFC6347] + and its current version is also 1.2. The TLS protocol evolved from + the Secure Sockets Layer (SSL) [RFC6101] protocols developed in the + mid-1990s to support protection of HTTP traffic. While older versions of TLS and DTLS are still in use, they provide weaker security guarantees. [RFC7457] outlines important attacks on TLS and DTLS. [RFC7525] is a Best Current Practices (BCP) document that describes secure configurations for TLS and DTLS to counter these attacks. The recommendations are applicable for the vast majority of use cases. 3.7.1. Protocol Description @@ -1102,23 +1105,21 @@ Section 4.1.2.6 of [RFC6347]. DTLS forbids the use of stream ciphers, which are essentially incompatible when operating on independent encrypted records. 3.7.2. Interface Description TLS is commonly invoked using an API provided by packages such as OpenSSL, wolfSSL, or GnuTLS. Using such APIs entails the manipulation of several important abstractions, which fall into the following categories: long-term keys and algorithms, session state, - and communications/connections. There may also be special APIs - required to deal with time and/or random numbers, both of which are - needed by a variety of encryption algorithms and protocols. + and communications/connections. Considerable care is required in the use of TLS APIs to ensure creation of a secure application. The programmer should have at least a basic understanding of encryption and digital signature algorithms and their strengths, public key infrastructure (including X.509 certificates and certificate revocation), and the sockets API. See [RFC7525] and [RFC7457], as mentioned above. As an example, in the case of OpenSSL, the primary abstractions are the library itself and method (protocol), session, context, cipher @@ -1295,30 +1297,30 @@ Representational State Transfer (REST) [REST] is another example of how applications can use HTTP as transport protocol. REST is an architecture style that may be used to build applications using HTTP as a communication protocol. 3.9.1. Protocol Description Hypertext Transfer Protocol (HTTP) is a request/response protocol. A client sends a request containing a request method, URI and protocol - version followed by a MIME-like message (see [RFC7231] for the - differences between an HTTP object and a MIME message), containing - information about the client and request modifiers. The message can - also contain a message body carrying application data. The server - responds with a status or error code followed by a MIME-like message - containing information about the server and information about the - data. This may include a message body. It is possible to specify a - data format for the message body using MIME media types [RFC2045]. - The protocol has additional features, some relevant to pseudo- - transport are described below. + version followed message whose design is inspired by MIME (see + [RFC7231] for the differences between an HTTP object and a MIME + message), containing information about the client and request + modifiers. The message can also contain a message body carrying + application data. The server responds with a status or error code + followed by a message containing information about the server and + information about the data. This may include a message body. It is + possible to specify a data format for the message body using MIME + media types [RFC2045]. The protocol has additional features, some + relevant to pseudo-transport are described below. Content negotiation, specified in [RFC7231], is a mechanism provided by HTTP to allow selection of a representation for a requested resource. The client and server negotiate acceptable data formats, character sets, data encoding (e.g., data can be transferred compressed using gzip). HTTP can accommodate exchange of messages as well as data streaming (using chunked transfer encoding [RFC7230]). It is also possible to request a part of a resource using an object range request [RFC7233]. The protocol provides powerful cache control signaling defined in [RFC7234]. @@ -1331,22 +1333,22 @@ connections can multiplex many request/response pairs in parallel on a single transport connection. Both are important to reduce latency for HTTP's primary use case. HTTP can be combined with security mechanisms, such as TLS (denoted by HTTPS). This adds protocol properties provided by such a mechanism (e.g., authentication, encryption). The TLS Application- Layer Protocol Negotiation (ALPN) extension [RFC7301] can be used to negotiate the HTTP version within the TLS handshake, eliminating the latency incurred by additional round-trip exchanges. Arbitrary - cookie strings, included as part of the MIME headers, are often used - as bearer tokens in HTTP. + cookie strings, included as part of the request headers, are often + used as bearer tokens in HTTP. 3.9.2. Interface Description There are many HTTP libraries available exposing different APIs. The APIs provide a way to specify a request by providing a URI, a method, request modifiers and optionally a request body. For the response, callbacks can be registered that will be invoked when the response is received. If HTTPS is used, the API exposes a registration of callbacks for a server that requests client authentication and when certificate verification is needed. @@ -1503,28 +1505,23 @@ based rate control mechanism and a single channel is sufficient. [RFC6584] provides per-packet authentication, integrity, and anti- replay protection in the context of the ALC and NORM protocols. Several mechanisms are proposed that seamlessly integrate into these protocols using the ALC and NORM header extension mechanisms. 3.10.2. Interface Description The FLUTE/ALC specification does not describe a specific application - programming interface (API) to control protocol operation. - - Open source reference implementations of FLUTE/ALC are available at - http://planete-bcast.inrialpes.fr/ (no longer maintained) and - http://mad.cs.tut.fi/ (no longer maintained), and these - implementations specify and document their own APIs. Commercial - versions are also available, some derived from the above - implementations, with their own API. + programming interface (API) to control protocol operation. Although + open source and commercial implementations have specified APIs, there + is no IETF- specified API for FLUTE/ALC. 3.10.3. Transport Features The transport features provided by FLUTE/ALC are: o unicast, multicast, anycast or IPv4 broadcast transmission, o object-oriented delivery of discrete data or files and associated metadata, @@ -1654,21 +1651,21 @@ o data bundling (using Nagle's algorithm), o flow control (timer-based and/or ack-based), o congestion control (also supporting fixed rate reliable or unreliable delivery). 3.12. Internet Control Message Protocol (ICMP) The Internet Control Message Protocol (ICMP) [RFC0792] for IPv4 and - ICMP for IPv6 [RFC4433] are IETF standards track protocols. It is a + ICMP for IPv6 [RFC4443] are IETF standards track protocols. It is a connection-less unidirectional protocol that delivers individual messages, without error correction, congestion control, or flow control. Messages may be sent as unicast, IPv4 broadcast or multicast datagrams (IPv4 and IPv6), in addition to anycast datagrams. While ICMP is not typically described as a transport protocol, it does position itself over the network layer, and the operation of other transport protocols can be closely linked to the functions provided by ICMP. @@ -1692,21 +1689,21 @@ [I-D.ietf-tsvwg-rfc5405bis]. 3.12.1. Protocol Description ICMP is a connection-less unidirectional protocol, It delivers independent messages, called datagrams. Each message is required to carry a checksum as an integrity check and to protect from mis- delivery to an unintended endpoint. ICMP messages typically relay diagnostic information from an endpoint - [RFC1122] or network device [RFC1716] addressed to the sender of a + [RFC1122] or network device [RFC1812] addressed to the sender of a flow. This usually contains the network protocol header of a packet that encountered a reported issue. Some formats of messages can also carry other payload data. Each message carries an integrity check calculated in the same way as for UDP, this checksum is not optional. The RFC series defines additional IPv6 message formats to support a range of uses. In the case of IPv6 the protocol incorporates neighbor discovery [RFC2461] [RFC3971] (provided by ARP for IPv4) and the Multicast Listener Discovery (MLD) [RFC2710] group management functions (provided by IGMP for IPv4). @@ -1794,30 +1791,30 @@ 5. Transport Features The transport protocol features described in this document can be used as a basis for defining common transport features, listed below with the protocols supporting them: o Control Functions * Addressing + + unicast (TCP, MPTCP, UDP, UDP-Lite, SCTP, DCCP, TLS, RTP, HTTP, ICMP) - + multicast (UDP, UDP-Lite, RTP, FLUTE/ALC, NORM). Note that, - as TLS and DTLS are unicast-only, there is no widely + + multicast (UDP, UDP-Lite, RTP, ICMP, FLUTE/ALC, NORM). Note + that, as TLS and DTLS are unicast-only, there is no widely deployed mechanism for supporting the features in the Security section below when using multicast addressing. + IPv4 broadcast (UDP, UDP-Lite, ICMP) - + anycast (UDP, UDP-Lite). Connection-oriented protocols such as TCP and DCCP have also been deployed using anycast addressing, with the risk that routing changes may cause connection failure. * Association type + connection-oriented (TCP, MPTCP, DCCP, SCTP, TLS, RTP, HTTP, NORM) @@ -1995,32 +1992,36 @@ . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, DOI 10.17487/RFC0896, January 1984, . + [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the + Internet checksum", RFC 1071, DOI 10.17487/RFC1071, + September 1988, . + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . - [RFC1716] Almquist, P. and F. Kastenholz, "Towards Requirements for - IP Routers", RFC 1716, DOI 10.17487/RFC1716, November - 1994, . + [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", + RFC 1812, DOI 10.17487/RFC1812, June 1995, + . [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, . [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, . @@ -2131,24 +2132,25 @@ Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2006, . [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, . - [RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 - Dynamic Home Agent (HA) Assignment", RFC 4433, - DOI 10.17487/RFC4433, March 2006, - . + [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet + Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6) Specification", RFC 4443, + DOI 10.17487/RFC4443, March 2006, + . [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, DOI 10.17487/RFC4654, August 2006, . [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, . @@ -2247,20 +2249,25 @@ [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/RFC6083, January 2011, . [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, . + [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure + Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, + DOI 10.17487/RFC6101, August 2011, + . + [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled @@ -2272,36 +2279,46 @@ Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, . [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, . + [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The + NewReno Modification to TCP's Fast Recovery Algorithm", + RFC 6582, DOI 10.17487/RFC6582, April 2012, + . + [RFC6584] Roca, V., "Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6584, DOI 10.17487/RFC6584, April 2012, . [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, . [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2012, . + [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, + "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, + DOI 10.17487/RFC6817, December 2012, + . + [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and @@ -2393,22 +2410,22 @@ (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [I-D.ietf-tsvwg-rfc5405bis] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage - Guidelines", draft-ietf-tsvwg-rfc5405bis-19 (work in - progress), October 2016. + Guidelines", draft-ietf-tsvwg-rfc5405bis-16 (work in + progress), July 2016. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-09 (work in progress), January 2015. [I-D.ietf-tsvwg-sctp-ndata] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", draft-ietf-tsvwg- @@ -2418,20 +2435,29 @@ Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", draft-ietf-tsvwg-natsupp-09 (work in progress), May 2016. [I-D.ietf-tcpm-cubic] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", draft-ietf-tcpm-cubic-02 (work in progress), August 2016. + [I-D.ietf-rtcweb-transports] + Alvestrand, H., "Transports for WebRTC", draft-ietf- + rtcweb-transports-15 (work in progress), August 2016. + + [I-D.ietf-tls-tls13] + Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", draft-ietf-tls-tls13-14 (work in progress), + July 2016. + [XHR] van Kesteren, A., Aubourg, J., Song, J., and H. Steen, "XMLHttpRequest working draft (http://www.w3.org/TR/XMLHttpRequest/)", 2000. [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures, Ph. D. (UC Irvine), Chapter 5: Representational State Transfer", 2000. [POSIX] 1-2008, IEEE., "IEEE Standard for Information Technology -- Portable Operating System Interface (POSIX) Base