draft-ietf-quic-applicability-12.txt   draft-ietf-quic-applicability-13.txt 
Network Working Group M. Kuehlewind Network Working Group M. Kuehlewind
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational B. Trammell Intended status: Informational B. Trammell
Expires: 1 January 2022 Google Expires: 6 March 2022 Google
30 June 2021 2 September 2021
Applicability of the QUIC Transport Protocol Applicability of the QUIC Transport Protocol
draft-ietf-quic-applicability-12 draft-ietf-quic-applicability-13
Abstract Abstract
This document discusses the applicability of the QUIC transport This document discusses the applicability of the QUIC transport
protocol, focusing on caveats impacting application protocol protocol, focusing on caveats impacting application protocol
development and deployment over QUIC. Its intended audience is development and deployment over QUIC. Its intended audience is
designers of application protocol mappings to QUIC, and implementors designers of application protocol mappings to QUIC, and implementors
of these application protocols. of these application protocols.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 1 January 2022. This Internet-Draft will expire on 6 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 22 skipping to change at page 2, line 22
4. Use of Streams . . . . . . . . . . . . . . . . . . . . . . . 7 4. Use of Streams . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Stream versus Flow Multiplexing . . . . . . . . . . . . . 8 4.1. Stream versus Flow Multiplexing . . . . . . . . . . . . . 8
4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . 9 4.2. Prioritization . . . . . . . . . . . . . . . . . . . . . 9
4.3. Ordered and Reliable Delivery . . . . . . . . . . . . . . 9 4.3. Ordered and Reliable Delivery . . . . . . . . . . . . . . 9
4.4. Flow Control Deadlocks . . . . . . . . . . . . . . . . . 10 4.4. Flow Control Deadlocks . . . . . . . . . . . . . . . . . 10
4.5. Stream Limit Commitments . . . . . . . . . . . . . . . . 11 4.5. Stream Limit Commitments . . . . . . . . . . . . . . . . 11
5. Packetization and Latency . . . . . . . . . . . . . . . . . . 12 5. Packetization and Latency . . . . . . . . . . . . . . . . . . 12
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 13 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgment Efficiency . . . . . . . . . . . . . . . . . . 14 7. Acknowledgment Efficiency . . . . . . . . . . . . . . . . . . 14
8. Port Selection and Application Endpoint Discovery . . . . . . 14 8. Port Selection and Application Endpoint Discovery . . . . . . 14
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 15 8.1. Source Port Selection . . . . . . . . . . . . . . . . . . 15
9. Connection Migration . . . . . . . . . . . . . . . . . . . . 16
10. Connection Termination . . . . . . . . . . . . . . . . . . . 16 10. Connection Termination . . . . . . . . . . . . . . . . . . . 16
11. Information Exposure and the Connection ID . . . . . . . . . 17 11. Information Exposure and the Connection ID . . . . . . . . . 17
11.1. Server-Generated Connection ID . . . . . . . . . . . . . 17 11.1. Server-Generated Connection ID . . . . . . . . . . . . . 18
11.2. Mitigating Timing Linkability with Connection ID 11.2. Mitigating Timing Linkability with Connection ID
Migration . . . . . . . . . . . . . . . . . . . . . . . 18 Migration . . . . . . . . . . . . . . . . . . . . . . . 18
11.3. Using Server Retry for Redirection . . . . . . . . . . . 18 11.3. Using Server Retry for Redirection . . . . . . . . . . . 19
12. Quality of Service (QoS) and DSCP . . . . . . . . . . . . . . 19 12. Quality of Service (QoS) and DSCP . . . . . . . . . . . . . . 19
13. Use of Versions and Cryptographic Handshake . . . . . . . . . 19 13. Use of Versions and Cryptographic Handshake . . . . . . . . . 20
14. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 20 14. Enabling New Versions . . . . . . . . . . . . . . . . . . . . 20
15. Unreliable Datagram Service over QUIC . . . . . . . . . . . . 21 15. Unreliable Datagram Service over QUIC . . . . . . . . . . . . 21
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
17. Security Considerations . . . . . . . . . . . . . . . . . . . 21 17. Security Considerations . . . . . . . . . . . . . . . . . . . 22
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
20.1. Normative References . . . . . . . . . . . . . . . . . . 22 20.1. Normative References . . . . . . . . . . . . . . . . . . 23
20.2. Informative References . . . . . . . . . . . . . . . . . 23 20.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
QUIC [QUIC] is a new transport protocol providing a number of QUIC [QUIC] is a new transport protocol providing a number of
advanced features. While initially designed for the HTTP use case, advanced features. While initially designed for the HTTP use case,
it provides capabilities that can be used with a much wider variety it provides capabilities that can be used with a much wider variety
of applications. QUIC is encapsulated in UDP. QUIC version 1 of applications. QUIC is encapsulated in UDP. QUIC version 1
integrates TLS 1.3 [TLS13] to encrypt all payload data and most integrates TLS 1.3 [TLS13] to encrypt all payload data and most
control information. The version of HTTP that uses QUIC is known as control information. The version of HTTP that uses QUIC is known as
HTTP/3 [QUIC-HTTP]. HTTP/3 [QUIC-HTTP].
skipping to change at page 15, line 20 skipping to change at page 15, line 20
As QUIC version 1 deferred defining a complete version negotiation As QUIC version 1 deferred defining a complete version negotiation
mechanism, HTTP/3 requires QUIC version 1 and defines the ALPN token mechanism, HTTP/3 requires QUIC version 1 and defines the ALPN token
("h3") to only apply to that version. So far no single approach has ("h3") to only apply to that version. So far no single approach has
been selected for managing the use of different QUIC versions, been selected for managing the use of different QUIC versions,
neither in HTTP/3 nor in general. Application protocols that use neither in HTTP/3 nor in general. Application protocols that use
QUIC need to consider how the protocol will manage different QUIC QUIC need to consider how the protocol will manage different QUIC
versions. Decisions for those protocols might be informed by choices versions. Decisions for those protocols might be informed by choices
made by other protocols, like HTTP/3. made by other protocols, like HTTP/3.
8.1. Source Port Selection
Some UDP protocols are vulnerable to reflection attacks, where an
attacker is able to direct traffic to a third party as a denial of
service. For example, these source ports are associated with
applications known to be vulnerable to reflection attacks, often due
to server misconfiguration:
* port 53 - DNS [RFC1034]
* port 123 - NTP [RFC5905]
* port 1900 - SSDP [SSDP]
* port 5353 - mDNS [RFC6762]
* port 11211 - memcached
Services might block source ports associated with protocols known to
be vulnerable to reflection attacks, to avoid the overhead of
processing large numbers of packets. However, this practice has
negative effects on clients: not only does it require establishment
of a new connection, but in some instances, might cause the client to
avoid using QUIC for that service for a period of time, downgrading
to a non-UDP protocol (see Section 2).
As a result, client implementations are encouraged to avoid using
source ports associated with protocols known to be vulnerable to
reflection attacks. Note that the list above is not exhaustive;
other source ports might be considered reflection vectors as well.
9. Connection Migration 9. Connection Migration
QUIC supports connection migration by the client. If an IP address QUIC supports connection migration by the client. If an IP address
changes, a QUIC endpoint can still associate packets with an existing changes, a QUIC endpoint can still associate packets with an existing
transport connection using the Destination Connection ID field (see transport connection using the Destination Connection ID field (see
also Section 11) in the QUIC header. This supports cases where also Section 11) in the QUIC header. This supports cases where
address information changes, such as NAT rebinding, intentional address information changes, such as NAT rebinding, intentional
change of the local interface, or based on an indication in the change of the local interface, or based on an indication in the
handshake of the server for a preferred address to be used. handshake of the server for a preferred address to be used.
Use of a non-zero-length connection ID for the server is strongly Use of a non-zero-length connection ID for the server is strongly
recommended if any clients are behind a NAT or could be. A non-zero- recommended if any clients are behind a NAT or could be. A non-zero-
length connection ID is also strongly recommended when migration is length connection ID is also strongly recommended when active
supported. migration is supported. If a connection is intentionally migrated to
new path, a new connection ID is used to minimize linkability by
network observers. The other QUIC endpoint uses the connection ID to
link different addresses to the same connection and entity if a non-
zero-length connection ID is provided.
The base specification of QUIC version 1 only supports the use of a The base specification of QUIC version 1 only supports the use of a
single network path at a time, which enables failover use cases. single network path at a time, which enables failover use cases.
Path validation is required so that endpoints validate paths before Path validation is required so that endpoints validate paths before
use to avoid address spoofing attacks. Path validation takes at use to avoid address spoofing attacks. Path validation takes at
least one RTT and congestion control will also be reset after path least one RTT and congestion control will also be reset after path
migration. Therefore, migration usually has a performance impact. migration. Therefore, migration usually has a performance impact.
QUIC probing packets, which can be sent on multiple paths at once, QUIC probing packets, which can be sent on multiple paths at once,
are used to perform address validation as well as measure path are used to perform address validation as well as measure path
skipping to change at page 19, line 10 skipping to change at page 19, line 41
Section 4 of [RFC5077] describes an example approach for constructing Section 4 of [RFC5077] describes an example approach for constructing
TLS resumption tickets that can be also applied for validation TLS resumption tickets that can be also applied for validation
tokens, however, the use of more modern cryptographic algorithms is tokens, however, the use of more modern cryptographic algorithms is
highly recommended. highly recommended.
12. Quality of Service (QoS) and DSCP 12. Quality of Service (QoS) and DSCP
QUIC, as defined in [RFC9000], has a single congestion controller and QUIC, as defined in [RFC9000], has a single congestion controller and
recovery handler. This design assumes that all packets of a QUIC recovery handler. This design assumes that all packets of a QUIC
connection, or at least with the same 5-tuple {dest addr, source connection, or at least with the same 5-tuple {dest addr, source
addr, protocol, dest port, source port} that same the same DiffServ addr, protocol, dest port, source port}, that have the same DiffServ
Code Point (DSCP) [RFC2475], will receive similar network treatment Code Point (DSCP) [RFC2475] will receive similar network treatment
since feedback about loss or delay of each packet is used as input to since feedback about loss or delay of each packet is used as input to
the congestion controller. Therefore, packets belonging to the same the congestion controller. Therefore, packets belonging to the same
connection should use a single DSCP. Section 5.1 of [RFC7657] connection should use a single DSCP. Section 5.1 of [RFC7657]
provides a discussion of DiffServ interactions with datagram provides a discussion of DiffServ interactions with datagram
transport protocols [RFC7657] (in this respect the interactions with transport protocols [RFC7657] (in this respect the interactions with
QUIC resemble those of SCTP). QUIC resemble those of SCTP).
When multiplexing multiple flows over a single QUIC connection, the When multiplexing multiple flows over a single QUIC connection, the
selected DSCP value should be the one associated with the highest selected DSCP value should be the one associated with the highest
priority requested for all multiplexed flows. priority requested for all multiplexed flows.
skipping to change at page 21, line 42 skipping to change at page 22, line 28
TCP register UDP ports analogous to their existing TCP registrations. TCP register UDP ports analogous to their existing TCP registrations.
17. Security Considerations 17. Security Considerations
See the security considerations in [QUIC] and [QUIC-TLS]; the See the security considerations in [QUIC] and [QUIC-TLS]; the
security considerations for the underlying transport protocol are security considerations for the underlying transport protocol are
relevant for applications using QUIC, as well. Considerations on relevant for applications using QUIC, as well. Considerations on
linkability, replay attacks, and randomness discussed in [QUIC-TLS] linkability, replay attacks, and randomness discussed in [QUIC-TLS]
should be taken into account when deploying and using QUIC. should be taken into account when deploying and using QUIC.
Further, migration to an new address exposes a linkage between client
addresses to the server and may expose this linkage also to the path
if the connection ID cannot be changed or flows can otherwise be
correlated. When migration is supported, this needs to be considered
with respective to user privacy.
Application developers should note that any fallback they use when Application developers should note that any fallback they use when
QUIC cannot be used due to network blocking of UDP should guarantee QUIC cannot be used due to network blocking of UDP should guarantee
the same security properties as QUIC; if this is not possible, the the same security properties as QUIC; if this is not possible, the
connection should fail to allow the application to explicitly handle connection should fail to allow the application to explicitly handle
fallback to a less-secure alternative. See Section 2. fallback to a less-secure alternative. See Section 2.
Further, [QUIC-HTTP] provides security considerations specific to Further, [QUIC-HTTP] provides security considerations specific to
HTTP. However, discussions such as on cross-protocol attacks, HTTP. However, discussions such as on cross-protocol attacks,
traffic analysis and padding, or migration might be relevant for traffic analysis and padding, or migration might be relevant for
other applications using QUIC as well. other applications using QUIC as well.
18. Contributors 18. Contributors
The following people have contributed text to this document: The following people have contributed significant text to and/or
feedback on this document:
* Gorry Fairhurst
* Ian Swett
* Igor Lubashev * Igor Lubashev
* Lucas Pardue
* Mike Bishop * Mike Bishop
* Mark Nottingham
* Martin Duke
* Martin Thomson * Martin Thomson
* Lucas Pardue * Sean Turner
* Gorry Fairhurst * Tommy Pauly
19. Acknowledgments 19. Acknowledgments
Thanks also to Martin Duke, Sean Turner, and Ian Swett for their This work was partially supported by the European Commission under
reviews.
This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat
for Education, Research, and Innovation under contract no. 15.0268. for Education, Research, and Innovation under contract no. 15.0268.
This support does not imply endorsement. This support does not imply endorsement.
20. References 20. References
20.1. Normative References 20.1. Normative References
[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
skipping to change at page 23, line 43 skipping to change at page 24, line 43
2010. 2010.
[HTTP-REPLAY] [HTTP-REPLAY]
Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/rfc/rfc8470>. 2018, <https://www.rfc-editor.org/rfc/rfc8470>.
[I-D.draft-ietf-httpbis-priority] [I-D.draft-ietf-httpbis-priority]
Oku, K. and L. Pardue, "Extensible Prioritization Scheme Oku, K. and L. Pardue, "Extensible Prioritization Scheme
for HTTP", Work in Progress, Internet-Draft, draft-ietf- for HTTP", Work in Progress, Internet-Draft, draft-ietf-
httpbis-priority-03, 11 January 2021, httpbis-priority-04, 11 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
priority-03>. priority-04>.
[I-D.draft-ietf-quic-version-negotiation] [I-D.draft-ietf-quic-version-negotiation]
Schinazi, D. and E. Rescorla, "Compatible Version Schinazi, D. and E. Rescorla, "Compatible Version
Negotiation for QUIC", Work in Progress, Internet-Draft, Negotiation for QUIC", Work in Progress, Internet-Draft,
draft-ietf-quic-version-negotiation-04, 26 May 2021, draft-ietf-quic-version-negotiation-04, 26 May 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
version-negotiation-04>. version-negotiation-04>.
[I-D.ietf-quic-datagram] [I-D.ietf-quic-datagram]
Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
Datagram Extension to QUIC", Work in Progress, Internet- Datagram Extension to QUIC", Work in Progress, Internet-
Draft, draft-ietf-quic-datagram-02, 16 February 2021, Draft, draft-ietf-quic-datagram-03, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
datagram-02>. datagram-03>.
[I-D.ietf-quic-manageability] [I-D.ietf-quic-manageability]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", Work in Progress, Internet-Draft, Transport Protocol", Work in Progress, Internet-Draft,
draft-ietf-quic-manageability-11, 21 April 2021, draft-ietf-quic-manageability-13, 2 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
manageability-11>. manageability-13>.
[I-D.ietf-taps-arch] [I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
Perkins, C., Tiesel, P. S., and C. A. Wood, "An Perkins, C., Tiesel, P. S., and C. A. Wood, "An
Architecture for Transport Services", Work in Progress, Architecture for Transport Services", Work in Progress,
Internet-Draft, draft-ietf-taps-arch-10, 30 April 2021, Internet-Draft, draft-ietf-taps-arch-11, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-taps- <https://datatracker.ietf.org/doc/html/draft-ietf-taps-
arch-10>. arch-11>.
[PaaschNanog] [PaaschNanog]
Paasch, C., "Network Support for TCP Fast Open (NANOG 67 Paasch, C., "Network Support for TCP Fast Open (NANOG 67
presentation)", 13 June 2016, presentation)", 13 June 2016,
<https://www.nanog.org/sites/default/files/ <https://www.nanog.org/sites/default/files/
Paasch_Network_Support.pdf>. Paasch_Network_Support.pdf>.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., "Hypertext Transfer Protocol Version 3 Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021, quic-http-34, 2 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>. http-34>.
[QUIC-LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC [QUIC-LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC
Connection IDs", Work in Progress, Internet-Draft, draft- Connection IDs", Work in Progress, Internet-Draft, draft-
ietf-quic-load-balancers-06, 4 February 2021, ietf-quic-load-balancers-07, 9 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
load-balancers-06>. load-balancers-07>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/rfc/rfc1034>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/rfc/rfc2475>. <https://www.rfc-editor.org/rfc/rfc2475>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/rfc/rfc5077>. January 2008, <https://www.rfc-editor.org/rfc/rfc5077>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, DOI 10.17487/RFC5382, October 2008, RFC 5382, DOI 10.17487/RFC5382, October 2008,
<https://www.rfc-editor.org/rfc/rfc5382>. <https://www.rfc-editor.org/rfc/rfc5382>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/rfc/rfc5905>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/rfc/rfc6762>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>. July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/rfc/rfc7413>. <https://www.rfc-editor.org/rfc/rfc7413>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
skipping to change at page 25, line 37 skipping to change at page 27, line 5
<https://www.rfc-editor.org/rfc/rfc7657>. <https://www.rfc-editor.org/rfc/rfc7657>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/rfc/rfc7838>. April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/rfc/rfc8085>. March 2017, <https://www.rfc-editor.org/rfc/rfc8085>.
[SSDP] Donoho, A., Roe, B., Bodlaender, M., Gildred, J., Messer,
A., Kim, Y., Fairman, B., and J. Tourzan, "UPnP Device
Architecture 2.0", 17 April 2020,
<https://openconnectivity.org/upnp-specs/UPnP-arch-
DeviceArchitecture-v2.0-20200417.pdf>.
[Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96 [Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96
QUIC BoF presentation)", 20 July 2016, QUIC BoF presentation)", 20 July 2016,
<https://www.ietf.org/proceedings/96/slides/slides-96- <https://www.ietf.org/proceedings/96/slides/slides-96-
quic-3.pdf>. quic-3.pdf>.
[Trammell16] [Trammell16]
Trammell, B. and M. Kuehlewind, "Internet Path Trammell, B. and M. Kuehlewind, "Internet Path
Transparency Measurements using RIPE Atlas (RIPE72 MAT Transparency Measurements using RIPE Atlas (RIPE72 MAT
presentation)", 25 May 2016, <https://ripe72.ripe.net/wp- presentation)", 25 May 2016, <https://ripe72.ripe.net/wp-
content/uploads/presentations/86-atlas-udpdiff.pdf>. content/uploads/presentations/86-atlas-udpdiff.pdf>.
 End of changes. 32 change blocks. 
36 lines changed or deleted 104 lines changed or added

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