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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/