draft-ietf-dnsop-serve-stale-09.txt   draft-ietf-dnsop-serve-stale-10.txt 
DNSOP Working Group D. Lawrence DNSOP Working Group D. Lawrence
Internet-Draft Oracle Internet-Draft Oracle
Updates: 1034, 1035, 2181 (if approved) W. Kumari Updates: 1034, 1035, 2181 (if approved) W. Kumari
Intended status: Standards Track P. Sood Intended status: Standards Track P. Sood
Expires: April 26, 2020 Google Expires: June 11, 2020 Google
October 24, 2019 December 09, 2019
Serving Stale Data to Improve DNS Resiliency Serving Stale Data to Improve DNS Resiliency
draft-ietf-dnsop-serve-stale-09 draft-ietf-dnsop-serve-stale-10
Abstract Abstract
This draft defines a method (serve-stale) for recursive resolvers to This draft defines a method (serve-stale) for recursive resolvers to
use stale DNS data to avoid outages when authoritative nameservers use stale DNS data to avoid outages when authoritative nameservers
cannot be reached to refresh expired data. One of the motivations cannot be reached to refresh expired data. One of the motivations
for serve-stale is to make the DNS more resilient to DoS attacks, and for serve-stale is to make the DNS more resilient to DoS attacks, and
thereby make them less attractive as an attack vector. This document thereby make them less attractive as an attack vector. This document
updates the definitions of TTL from RFC 1034 and RFC 1035 so that updates the definitions of TTL from RFC 1034 and RFC 1035 so that
data can be kept in the cache beyond the TTL expiry, updates RFC 2181 data can be kept in the cache beyond the TTL expiry, updates RFC 2181
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 26, 2020. This Internet-Draft will expire on June 11, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 15 skipping to change at page 3, line 15
suggests a cap of 7 days. suggests a cap of 7 days.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
For a comprehensive treatment of DNS terms, please see [RFC8499]. For a glossary of DNS terms, please see [RFC8499].
3. Background 3. Background
There are a number of reasons why an authoritative server may become There are a number of reasons why an authoritative server may become
unreachable, including Denial of Service (DoS) attacks, network unreachable, including Denial of Service (DoS) attacks, network
issues, and so on. If a recursive server is unable to contact the issues, and so on. If a recursive server is unable to contact the
authoritative servers for a query but still has relevant data that authoritative servers for a query but still has relevant data that
has aged past its TTL, that information can still be useful for has aged past its TTL, that information can still be useful for
generating an answer under the metaphorical assumption that "stale generating an answer under the metaphorical assumption that "stale
bread is better than no bread." bread is better than no bread."
skipping to change at page 3, line 46 skipping to change at page 3, line 46
[RFC2119] which softened the interpretation of "may" and "should". [RFC2119] which softened the interpretation of "may" and "should".
[RFC2181] aimed to provide "the precise definition of the Time to [RFC2181] aimed to provide "the precise definition of the Time to
Live", but in Section 8 was mostly concerned with the numeric range Live", but in Section 8 was mostly concerned with the numeric range
of values rather than data expiration behavior. It does, however, of values rather than data expiration behavior. It does, however,
close that section by noting, "The TTL specifies a maximum time to close that section by noting, "The TTL specifies a maximum time to
live, not a mandatory time to live." This wording again does not live, not a mandatory time to live." This wording again does not
contain BCP 14 [RFC2119] key words, but does convey the natural contain BCP 14 [RFC2119] key words, but does convey the natural
language connotation that data becomes unusable past TTL expiry. language connotation that data becomes unusable past TTL expiry.
Several recursive resolver operators, including Akamai, currently use As of the time of this writing, several large-scale operators use
stale data for answers in some way. A number of recursive resolver stale data for answers in some way. A number of recursive resolver
packages (including BIND, Knot, OpenDNS, Unbound) provide options to packages, including BIND, Knot, OpenDNS, and Unbound, provide options
use stale data. Apple MacOS can also use stale data as part of the to use stale data. Apple MacOS can also use stale data as part of
Happy Eyeballs algorithms in mDNSResponder. The collective the Happy Eyeballs algorithms in mDNSResponder. The collective
operational experience is that using stale data can provide operational experience is that using stale data can provide
significant benefit with minimal downside. significant benefit with minimal downside.
4. Standards Action 4. Standards Action
The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is
amended to read: amended to read:
TTL a 32-bit unsigned integer number of seconds that specifies the TTL a 32-bit unsigned integer number of seconds that specifies the
duration that the resource record MAY be cached before the source duration that the resource record MAY be cached before the source
of the information MUST again be consulted. Zero values are of the information MUST again be consulted. Zero values are
interpreted to mean that the RR can only be used for the interpreted to mean that the RR can only be used for the
transaction in progress, and should not be cached. Values SHOULD transaction in progress, and should not be cached. Values SHOULD
be capped on the orders of days to weeks, with a recommended cap be capped on the orders of days to weeks, with a recommended cap
of 604,800 seconds (seven days). If the data is unable to be of 604,800 seconds (seven days). If the data is unable to be
authoritatively refreshed when the TTL expires, the record MAY be authoritatively refreshed when the TTL expires, the record MAY be
used as though it is unexpired. See the Section 5 and Section 6 used as though it is unexpired. See [RFC Editor: replace by RFC
sections for details. number] Section 5 and Section 6 for details.
Interpreting values which have the high-order bit set as being Interpreting values which have the high-order bit set as being
positive, rather than 0, is a change from [RFC2181], the rationale positive, rather than 0, is a change from [RFC2181], the rationale
for which is explained in Section 6. Suggesting a cap of seven days, for which is explained in Section 6. Suggesting a cap of seven days,
rather than the 68 years allowed by [RFC2181], reflects the current rather than the 68 years allowed by [RFC2181], reflects the current
practice of major modern DNS resolvers. practice of major modern DNS resolvers.
When returning a response containing stale records, a recursive When returning a response containing stale records, a recursive
resolver MUST set the TTL of each expired record in the message to a resolver MUST set the TTL of each expired record in the message to a
value greater than 0, with a RECOMMENDED value of 30 seconds. See value greater than 0, with a RECOMMENDED value of 30 seconds. See
Section 6 for explanation. Section 6 for explanation.
Answers from authoritative servers that have a DNS Response Code of Answers from authoritative servers that have a DNS Response Code of
either 0 (NoError) or 3 (NXDomain) and the Authoritative Answers (AA) either 0 (NoError) or 3 (NXDomain) and the Authoritative Answers (AA)
bit set MUST be considered to have refreshed the data at the bit set MUST be considered to have refreshed the data at the
resolver. Answers from authoritative servers that have any other resolver. Answers from authoritative servers that have any other
response code SHOULD be considered a failure to refresh the data and response code SHOULD be considered a failure to refresh the data and
therefor leave any previous state intact. See Section 6 for a therefore leave any previous state intact. See Section 6 for a
discussion. discussion.
5. Example Method 5. Example Method
There is more than one way a recursive resolver could responsibly There is more than one way a recursive resolver could responsibly
implement this resiliency feature while still respecting the intent implement this resiliency feature while still respecting the intent
of the TTL as a signal for when data is to be refreshed. of the TTL as a signal for when data is to be refreshed.
In this example method four notable timers drive considerations for In this example method four notable timers drive considerations for
the use of stale data: the use of stale data:
skipping to change at page 5, line 22 skipping to change at page 5, line 22
o A failure recheck timer, which limits the frequency at which a o A failure recheck timer, which limits the frequency at which a
failed lookup will be attempted again. failed lookup will be attempted again.
o A maximum stale timer, which caps the amount of time that records o A maximum stale timer, which caps the amount of time that records
will be kept past their expiration. will be kept past their expiration.
Most recursive resolvers already have the query resolution timer, and Most recursive resolvers already have the query resolution timer, and
effectively some kind of failure recheck timer. The client response effectively some kind of failure recheck timer. The client response
timer and maximum stale timer are new concepts for this mechanism. timer and maximum stale timer are new concepts for this mechanism.
When a request is received by a recursive resolver, it should start When a recursive resolver receives a request, it should start the
the client response timer. This timer is used to avoid client client response timer. This timer is used to avoid client timeouts.
timeouts. It should be configurable, with a recommended value of 1.8 It should be configurable, with a recommended value of 1.8 seconds as
seconds as being just under a common timeout value of 2 seconds while being just under a common timeout value of 2 seconds while still
still giving the resolver a fair shot at resolving the name. giving the resolver a fair shot at resolving the name.
The resolver then checks its cache for any unexpired records that The resolver then checks its cache for any unexpired records that
satisfy the request and returns them if available. If it finds no satisfy the request and returns them if available. If it finds no
relevant unexpired data and the Recursion Desired flag is not set in relevant unexpired data and the Recursion Desired flag is not set in
the request, it should immediately return the response without the request, it should immediately return the response without
consulting the cache for expired records. Typically this response consulting the cache for expired records. Typically this response
would be a referral to authoritative nameservers covering the zone, would be a referral to authoritative nameservers covering the zone,
but the specifics are implementation-dependent. but the specifics are implementation-dependent.
If iterative lookups will be done, then the failure recheck timer is If iterative lookups will be done, then the failure recheck timer is
skipping to change at page 6, line 12 skipping to change at page 6, line 12
client response timer has elapsed, the resolver should then check its client response timer has elapsed, the resolver should then check its
cache to see whether there is expired data that would satisfy the cache to see whether there is expired data that would satisfy the
request. If so, it adds that data to the response message with a TTL request. If so, it adds that data to the response message with a TTL
greater than 0 (as specified in Section 4). The response is then greater than 0 (as specified in Section 4). The response is then
sent to the client while the resolver continues its attempt to sent to the client while the resolver continues its attempt to
refresh the data. refresh the data.
When no authorities are able to be reached during a resolution When no authorities are able to be reached during a resolution
attempt, the resolver should attempt to refresh the delegation and attempt, the resolver should attempt to refresh the delegation and
restart the iterative lookup process with the remaining time on the restart the iterative lookup process with the remaining time on the
query resolution timer. This resumption should be done only once query resolution timer. This resumption should be done only once per
during one resolution effort. resolution effort.
Outside the resolution process, the maximum stale timer is used for Outside the resolution process, the maximum stale timer is used for
cache management and is independent of the query resolution process. cache management and is independent of the query resolution process.
This timer is conceptually different from the maximum cache TTL that This timer is conceptually different from the maximum cache TTL that
exists in many resolvers, the latter being a clamp on the value of exists in many resolvers, the latter being a clamp on the value of
TTLs as received from authoritative servers and recommended to be TTLs as received from authoritative servers and recommended to be
seven days in the TTL definition in Section 4. The maximum stale seven days in the TTL definition in Section 4. The maximum stale
timer should be configurable, and defines the length of time after a timer should be configurable, and defines the length of time after a
record expires that it should be retained in the cache. The record expires that it should be retained in the cache. The
suggested value is between 1 and 3 days. suggested value is between 1 and 3 days.
skipping to change at page 7, line 10 skipping to change at page 7, line 10
removal of stale records over non-expired records during cache removal of stale records over non-expired records during cache
exhaustion. Implementations may also wish to consider whether to exhaustion. Implementations may also wish to consider whether to
track the names in requests for their last time of use or their track the names in requests for their last time of use or their
popularity, using that as an additional factor when considering cache popularity, using that as an additional factor when considering cache
eviction. A feature to manually flush only stale records could also eviction. A feature to manually flush only stale records could also
be useful. be useful.
The client response timer is another variable which deserves The client response timer is another variable which deserves
consideration. If this value is too short, there exists the risk consideration. If this value is too short, there exists the risk
that stale answers may be used even when the authoritative server is that stale answers may be used even when the authoritative server is
actually reachable but slow; this may result in sub-optimal answers actually reachable but slow; this may result in undesirable answers
being returned. Conversely, waiting too long will negatively impact being returned. Conversely, waiting too long will negatively impact
user experience. user experience.
The balance for the failure recheck timer is responsiveness in The balance for the failure recheck timer is responsiveness in
detecting the renewed availability of authorities versus the extra detecting the renewed availability of authorities versus the extra
resource use for resolution. If this variable is set too large, resource use for resolution. If this variable is set too large,
stale answers may continue to be returned even after the stale answers may continue to be returned even after the
authoritative server is reachable; per [RFC2308], Section 7, this authoritative server is reachable; per [RFC2308], Section 7, this
should be no more than five minutes. If this variable is too small, should be no more than five minutes. If this variable is too small,
authoritative servers may be rapidly hit with a significant amount of authoritative servers may be targeted with a significant amount of
traffic when they become reachable again. excess traffic.
Regarding the TTL to set on stale records in the response, Regarding the TTL to set on stale records in the response,
historically TTLs of zero seconds have been problematic for some historically TTLs of zero seconds have been problematic for some
implementations, and negative values can't effectively be implementations, and negative values can't effectively be
communicated to existing software. Other very short TTLs could lead communicated to existing software. Other very short TTLs could lead
to congestive collapse as TTL-respecting clients rapidly try to to congestive collapse as TTL-respecting clients rapidly try to
refresh. The recommended value of 30 seconds not only sidesteps refresh. The recommended value of 30 seconds not only sidesteps
those potential problems with no practical negative consequences, it those potential problems with no practical negative consequences, it
also rate limits further queries from any client that honors the TTL, also rate limits further queries from any client that honors the TTL,
such as a forwarding resolver. such as a forwarding resolver.
As for the change to treat a TTL with the high-order bit set as As for the change to treat a TTL with the high-order bit set as
positive and then clamping it, as opposed to [RFC2181] treating it as positive and then clamping it, as opposed to [RFC2181] treating it as
zero, the rationale here is basically one of engineering simplicity zero, the rationale here is basically one of engineering simplicity
versus an inconsequential operational history. Negative TTLs had no versus an inconsequential operational history. Negative TTLs had no
rational intentional meaning that wouldn't have been satisfied by rational intentional meaning that wouldn't have been satisfied by
just sending 0 instead, and similarly there was realistically no just sending 0 instead, and similarly there was realistically no
practical purpose for sending TTLs of 2^25 seconds (1 year) or more. practical purpose for sending TTLs of 2^25 seconds (1 year) or more.
There's also no record of TTLs in the wild having the most There's also no record of TTLs in the wild having the most
significant bit set in DNS-OARC's "Day in the Life" samples. With no significant bit set in DNS-OARC's "Day in the Life" samples [DITL].
apparent reason for operators to use them intentionally, that leaves With no apparent reason for operators to use them intentionally, that
either errors or non-standard experiments as explanations as to why leaves either errors or non-standard experiments as explanations as
such TTLs might be encountered, with neither providing an obviously to why such TTLs might be encountered, with neither providing an
compelling reason as to why having the leading bit set should be obviously compelling reason as to why having the leading bit set
treated differently from having any of the next eleven bits set and should be treated differently from having any of the next eleven bits
then capped per Section 4. set and then capped per Section 4.
Another implementation consideration is the use of stale nameserver Another implementation consideration is the use of stale nameserver
addresses for lookups. This is mentioned explicitly because, in some addresses for lookups. This is mentioned explicitly because, in some
resolvers, getting the addresses for nameservers is a separate path resolvers, getting the addresses for nameservers is a separate path
from a normal cache lookup. If authoritative server addresses are from a normal cache lookup. If authoritative server addresses are
not able to be refreshed, resolution can possibly still be successful not able to be refreshed, resolution can possibly still be successful
if the authoritative servers themselves are up. For instance, if the authoritative servers themselves are up. For instance,
consider an attack on a top-level domain that takes its nameservers consider an attack on a top-level domain that takes its nameservers
offline; serve-stale resolvers that had expired glue addresses for offline; serve-stale resolvers that had expired glue addresses for
subdomains within that TLD would still be able to resolve names subdomains within that TLD would still be able to resolve names
skipping to change at page 9, line 34 skipping to change at page 9, line 34
name can cause surprising results. This was observed with an initial name can cause surprising results. This was observed with an initial
implementation in BIND when a hostname changed from having an IPv4 implementation in BIND when a hostname changed from having an IPv4
Address (A) record to a CNAME. The version of BIND being used did Address (A) record to a CNAME. The version of BIND being used did
not evict other types in the cache when a CNAME was received, which not evict other types in the cache when a CNAME was received, which
in normal operations is not a significant issue. However, after both in normal operations is not a significant issue. However, after both
records expired and the authorities became unavailable, the fallback records expired and the authorities became unavailable, the fallback
to stale answers returned the older A instead of the newer CNAME. to stale answers returned the older A instead of the newer CNAME.
8. Implementation Status 8. Implementation Status
[RFC Editor: per RFC 6982 this section should be removed prior to
publication.]
The algorithm described in Section 5 was originally implemented as a The algorithm described in Section 5 was originally implemented as a
patch to BIND 9.7.0. It has been in production on Akamai's patch to BIND 9.7.0. It has been in use on Akamai's production
production network since 2011, and effectively smoothed over network since 2011, and effectively smoothed over transient failures
transient failures and longer outages that would have resulted in and longer outages that would have resulted in major incidents. The
major incidents. The patch was contributed to Internet Systems patch was contributed to Internet Systems Consortium and the
Consortium and the functionality is now available in BIND 9.12 via functionality is now available in BIND 9.12 and later via the options
the options stale-answer-enable, stale-answer-ttl, and max-stale-ttl. stale-answer-enable, stale-answer-ttl, and max-stale-ttl.
Unbound has a similar feature for serving stale answers, but will Unbound has a similar feature for serving stale answers, and will
respond with stale data immediately if it has recently tried and respond with stale data immediately if it has recently tried and
failed to refresh the answer by pre-fetching. failed to refresh the answer by pre-fetching.
Knot Resolver has a demo module here: https://knot- Knot Resolver has a demo module here: https://knot-
resolver.readthedocs.io/en/stable/modules.html#serve-stale resolver.readthedocs.io/en/stable/modules.html#serve-stale
Details of Apple's implementation are not currently known.
Apple's system resolvers are also known to use stale answers, but the
details are not readily available.
In the research paper "When the Dike Breaks: Dissecting DNS Defenses In the research paper "When the Dike Breaks: Dissecting DNS Defenses
During DDoS" [DikeBreaks], the authors detected some use of stale During DDoS" [DikeBreaks], the authors detected some use of stale
answers by resolvers when authorities came under attack. Their answers by resolvers when authorities came under attack. Their
research results suggest that more widespread adoption of the research results suggest that more widespread adoption of the
technique would significantly improve resiliency for the large number technique would significantly improve resiliency for the large number
of requests that fail or experience abnormally long resolution times of requests that fail or experience abnormally long resolution times
during an attack. during an attack.
9. EDNS Option 9. EDNS Option
skipping to change at page 11, line 26 skipping to change at page 11, line 24
12. NAT Considerations 12. NAT Considerations
The method described here is not affected by the use of NAT devices. The method described here is not affected by the use of NAT devices.
13. IANA Considerations 13. IANA Considerations
There are no IANA considerations. There are no IANA considerations.
14. Acknowledgements 14. Acknowledgements
The authors wish to thank Robert Edmonds, Tony Finch, Bob Harold, The authors wish to thank Brian Carpenter, Robert Edmonds, Tony
Tatuya Jinmei, Matti Klock, Jason Moreau, Giovane Moura, Jean Roy, Finch, Bob Harold, Tatuya Jinmei, Matti Klock, Jason Moreau, Giovane
Mukund Sivaraman, Davey Song, Paul Vixie, Ralf Weber and Paul Wouters Moura, Jean Roy, Mukund Sivaraman, Davey Song, Paul Vixie, Ralf Weber
for their review and feedback. and Paul Wouters for their review and feedback. Paul Hoffman
deserves special thanks for submitting a number of Pull Requests.
Paul Hoffman deserves special thanks for submitting a number of Pull Thank you also to the following members of the IESG for their final
Requests. review: Roman Danyliw, Benjamin Kaduk, Suresh Krishnan, Mirja
Kuehlewind, and Adam Roach.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
skipping to change at page 12, line 35 skipping to change at page 12, line 35
content/uploads/2018/02/ndss2018_06A- content/uploads/2018/02/ndss2018_06A-
4_Borgolte_paper.pdf>. 4_Borgolte_paper.pdf>.
[DikeBreaks] [DikeBreaks]
Moura, G., Heidemann, J., Mueller, M., Schmidt, R., and M. Moura, G., Heidemann, J., Mueller, M., Schmidt, R., and M.
Davids, "When the Dike Breaks: Dissecting DNS Defenses Davids, "When the Dike Breaks: Dissecting DNS Defenses
During DDos", ACM 2018 Internet Measurement Conference, During DDos", ACM 2018 Internet Measurement Conference,
DOI 10.1145/3278532.3278534, October 2018, DOI 10.1145/3278532.3278534, October 2018,
<https://www.isi.edu/~johnh/PAPERS/Moura18b.pdf>. <https://www.isi.edu/~johnh/PAPERS/Moura18b.pdf>.
[DITL] "DITL Traces and Analysis | DNS-OARC", n.d.,
<https://www.dns-oarc.net/oarc/data/ditl>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>. <https://www.rfc-editor.org/info/rfc6672>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
Authors' Addresses Authors' Addresses
 End of changes. 20 change blocks. 
46 lines changed or deleted 50 lines changed or added

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