rfc8767xml2.original.xml		rfc8767.xml
	<?xml version="1.0" encoding="us-ascii"?>		<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->		nsus="true" docName="draft-ietf-dnsop-serve-stale-10" indexInclude="true" ipr="t
			rust200902" number="8767" prepTime="2020-03-31T14:58:06" scripts="Common,Latin"
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [		sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="tr
	<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere		ue" updates="1034, 1035, 2181" xml:lang="en">
	nce.RFC.1035.xml">		<link href="https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale-10"
	<!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere		rel="prev"/>
	nce.RFC.2181.xml">		<link href="https://dx.doi.org/10.17487/rfc8767" rel="alternate"/>
	<!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere		<link href="urn:issn:2070-1721" rel="alternate"/>
	nce.RFC.1034.xml">
	<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.2119.xml">
	<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.8174.xml">
	<!ENTITY RFC2308 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.2308.xml">
	<!ENTITY RFC8499 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.8499.xml">
	<!ENTITY RFC6672 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.6672.xml">
	]>
	<?rfc toc="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<rfc ipr="trust200902" docName="draft-ietf-dnsop-serve-stale-10" category="std"
	updates="1034, 1035, 2181">
	<front>		<front>
	<title abbrev="DNS Serve Stale">Serving Stale Data to Improve DNS Resiliency		<title abbrev="DNS Serve-Stale">Serving Stale Data to Improve DNS Resiliency
	</title>		</title>
			<seriesInfo name="RFC" value="8767" stream="IETF"/>
	<author initials="D.C." surname="Lawrence" fullname="David C Lawrence">		<author initials="D." surname="Lawrence" fullname="David C Lawrence">
	<organization>Oracle</organization>		<organization showOnFrontPage="true">Oracle</organization>
	<address>		<address>
	<email>tale@dd.org</email>		<email>tale@dd.org</email>
	</address>		</address>
	</author>		</author>
	<author initials="W." surname="Kumari" fullname="Warren &quot;Ace&quot; Kuma ri">		<author initials="W." surname="Kumari" fullname="Warren &quot;Ace&quot; Kuma ri">
	<organization>Google</organization>		<organization showOnFrontPage="true">Google</organization>
	<address>		<address>
	<postal>		<postal>
	<street>1600 Amphitheatre Parkway</street>		<street>1600 Amphitheatre Parkway</street>
	<city>Mountain View</city>		<city>Mountain View</city>
	<code>CA 94043</code>		<region>CA</region>
	<country>USA</country>		<code>94043</code>
			<country>United States of America</country>
	</postal>		</postal>
	<email>warren@kumari.net</email>		<email>warren@kumari.net</email>
	</address>		</address>
	</author>		</author>
	<author initials="P." surname="Sood" fullname="Puneet Sood">		<author initials="P." surname="Sood" fullname="Puneet Sood">
	<organization>Google</organization>		<organization showOnFrontPage="true">Google</organization>
	<address>		<address>
	<email>puneets@google.com</email>		<email>puneets@google.com</email>
	</address>		</address>
	</author>		</author>
			<date month="03" year="2020"/>
	<date year="2019" month="December" day="09"/>		<keyword>DNS</keyword>
			<keyword>DDoS</keyword>
	<area>Internet</area>		<keyword>Resiliency</keyword>
	<workgroup>DNSOP Working Group</workgroup>		<keyword>Denial-of-Service</keyword>
	<keyword>Internet-Draft</keyword>		<keyword>Expired</keyword>
			<abstract pn="section-abstract">
	<abstract>		<t pn="section-abstract-1">This document defines a method (serve-stale) fo
			r recursive resolvers to
	<t>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,		for serve-stale is to make the DNS more resilient to DoS attacks
	and thereby make them less attractive as an attack vector.		and thereby make them less attractive as an attack vector.
	This document updates the definitions of TTL from RFC 1034		This document updates the definitions of TTL from RFCs 1034
	and RFC 1035 so that data can be kept in the cache beyond		and 1035 so that data can be kept in the cache beyond
	the TTL expiry, updates RFC 2181 by interpreting		the TTL expiry; it also updates RFC 2181 by interpreting
	values with the high order bit set as being positive, rather		values with the high-order bit set as being positive, rather
	than 0, and suggests a cap of 7 days.</t>		than 0, and suggests a cap of 7 days.</t>
	</abstract>		</abstract>
			<boilerplate>
			<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
			"exclude" pn="section-boilerplate.1">
			<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
			>
			<t pn="section-boilerplate.1-1">
			This is an Internet Standards Track document.
			</t>
			<t pn="section-boilerplate.1-2">
			This document is a product of the Internet Engineering Task Force
			(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by
			the Internet Engineering Steering Group (IESG). Further
			information on Internet Standards is available in Section 2 of
			RFC 7841.
			</t>
			<t pn="section-boilerplate.1-3">
			Information about the current status of this document, any
			errata, and how to provide feedback on it may be obtained at
			<eref target="https://www.rfc-editor.org/info/rfc8767" brackets="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" pn="section-boilerplate.2">
			<name slugifiedName="name-copyright-notice">Copyright Notice</name>
			<t pn="section-boilerplate.2-1">
			Copyright (c) 2020 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			</t>
			<t pn="section-boilerplate.2-2">
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(<eref target="https://trustee.ietf.org/license-info" brackets="none
			"/>) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document. Code Components extracted from this
			document must include Simplified BSD License text as described in
			Section 4.e of the Trust Legal Provisions and are provided without
			warranty as described in the Simplified BSD License.
			</t>
			</section>
			</boilerplate>
			<toc>
			<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.1-1">
			<li pn="section-toc.1-1.1">
			<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
			="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
			n</xref></t>
			</li>
			<li pn="section-toc.1-1.2">
			<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
			="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-terminology">Terminology<
			/xref></t>
			</li>
			<li pn="section-toc.1-1.3">
			<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent
			="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-background">Background</x
			ref></t>
			</li>
			<li pn="section-toc.1-1.4">
			<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
			="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-standards-action">Standar
			ds Action</xref></t>
			</li>
			<li pn="section-toc.1-1.5">
			<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent
			="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-example-method">Example M
			ethod</xref></t>
			</li>
			<li pn="section-toc.1-1.6">
			<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
			="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-implementation-considerat
			io">Implementation Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.7">
			<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
			="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-implementation-caveats">I
			mplementation Caveats</xref></t>
			</li>
			<li pn="section-toc.1-1.8">
			<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
			="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-implementation-status">Im
			plementation Status</xref></t>
			</li>
			<li pn="section-toc.1-1.9">
			<t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent
			="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedCon
			tent="" format="title" sectionFormat="of" target="name-edns-option">EDNS Option<
			/xref></t>
			</li>
			<li pn="section-toc.1-1.10">
			<t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedConten
			t="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedC
			ontent="" format="title" sectionFormat="of" target="name-security-considerations
			">Security Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.11">
			<t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedConten
			t="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedC
			ontent="" format="title" sectionFormat="of" target="name-privacy-considerations"
			>Privacy Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.12">
			<t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedConten
			t="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedC
			ontent="" format="title" sectionFormat="of" target="name-nat-considerations">NAT
			Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.13">
			<t keepWithNext="true" pn="section-toc.1-1.13.1"><xref derivedConten
			t="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedC
			ontent="" format="title" sectionFormat="of" target="name-iana-considerations">IA
			NA Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.14">
			<t keepWithNext="true" pn="section-toc.1-1.14.1"><xref derivedConten
			t="14" format="counter" sectionFormat="of" target="section-14"/>. <xref derivedC
			ontent="" format="title" sectionFormat="of" target="name-references">References<
			/xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.14.2">
			<li pn="section-toc.1-1.14.2.1">
			<t keepWithNext="true" pn="section-toc.1-1.14.2.1.1"><xref deriv
			edContent="14.1" format="counter" sectionFormat="of" target="section-14.1"/>.  <
			xref derivedContent="" format="title" sectionFormat="of" target="name-normative-
			references">Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.14.2.2">
			<t keepWithNext="true" pn="section-toc.1-1.14.2.2.1"><xref deriv
			edContent="14.2" format="counter" sectionFormat="of" target="section-14.2"/>.  <
			xref derivedContent="" format="title" sectionFormat="of" target="name-informativ
			e-references">Informative References</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.15">
			<t keepWithNext="true" pn="section-toc.1-1.15.1"><xref derivedConten
			t="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derived
			Content="" format="title" sectionFormat="of" target="name-acknowledgements">Ackn
			owledgements</xref></t>
			</li>
			<li pn="section-toc.1-1.16">
			<t keepWithNext="true" pn="section-toc.1-1.16.1"><xref derivedConten
			t="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derived
			Content="" format="title" sectionFormat="of" target="name-authors-addresses">Aut
			hors' Addresses</xref></t>
			</li>
			</ul>
			</section>
			</toc>
	</front>		</front>
	<middle>		<middle>
			<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
	<section anchor="introduction" title="Introduction">		lse" pn="section-1">
			<name slugifiedName="name-introduction">Introduction</name>
	<t>Traditionally the Time To Live (TTL) of a DNS resource record has been		<t pn="section-1-1">Traditionally, the Time To Live (TTL) of a DNS Resourc
			e Record (RR) has been
	understood to represent the maximum number of seconds that a record		understood to represent the maximum number of seconds that a record
	can be used before it must be discarded, based on its description and		can be used before it must be discarded, based on its description and
	usage in <xref target="RFC1035"/> and clarifications in <xref target="RFC2181"/>		usage in <xref target="RFC1035" format="default" sectionFormat="of" derivedConte
	.</t>		nt="RFC1035"/> and clarifications in <xref target="RFC2181" format="default" sec
			tionFormat="of" derivedContent="RFC2181"/>.</t>
	<t>This document expands the definition of the TTL		<t pn="section-1-2">This document expands the definition of the TTL
	to explicitly allow for expired data to be used in the exceptional		to explicitly allow for expired data to be used in the exceptional
	circumstance that a recursive resolver is unable to refresh the		circumstance that a recursive resolver is unable to refresh the
	information. It is predicated on the observation that authoritative		information. It is predicated on the observation that authoritative
	answer unavailability can cause outages even when the underlying data		answer unavailability can cause outages even when the underlying data
	those servers would return is typically unchanged.</t>		those servers would return is typically unchanged.</t>
			<t pn="section-1-3">We describe a method below for this use of stale data,
	<t>We describe a method below for this use of stale data, balancing the		balancing the
	competing needs of resiliency and freshness.</t>		competing needs of resiliency and freshness.</t>
			<t pn="section-1-4">This document updates the definitions of TTL from <xre
	<t>This document updates the definitions of TTL from <xref target="RFC1034"/>		f target="RFC1034" format="default" sectionFormat="of" derivedContent="RFC1034"/
	and <xref target="RFC1035"/> so that data can be kept in the cache beyond		>
	the TTL expiry, and also updates <xref target="RFC2181"/> by interpreting		and <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="R
	values with the high order bit set as being positive, rather		FC1035"/> so that data can be kept in the cache beyond
			the TTL expiry; it also updates <xref target="RFC2181" format="default" sectionF
			ormat="of" derivedContent="RFC2181"/> by interpreting
			values with the high-order bit set as being positive, rather
	than 0, and also suggests a cap of 7 days.</t>		than 0, and also suggests a cap of 7 days.</t>
			</section>
	</section>		<section anchor="terminology" numbered="true" toc="include" removeInRFC="fal
	<section anchor="terminology" title="Terminology">		se" pn="section-2">
			<name slugifiedName="name-terminology">Terminology</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		<t pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT<
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		/bcp14>",
	"OPTIONAL" in this document are to be interpreted as described in		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	ey appear in all		"<bcp14>SHOULD NOT</bcp14>",
	capitals, as shown here.</t>		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	<t>For a glossary of DNS terms, please see <xref target="RFC8499"/>.</t>		are to be interpreted as described in BCP 14
			<xref target="RFC2119" format="default" sectionFormat="of" derivedContent
	</section>		="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedC
	<section anchor="background" title="Background">		ontent="RFC8174"/> when, and only
			when, they appear in all capitals, as shown here.</t>
	<t>There are a number of reasons why an authoritative server may become		<t pn="section-2-2">For a glossary of DNS terms, please see <xref target="
	unreachable, including Denial of Service (DoS) attacks, network		RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</t>
			</section>
			<section anchor="background" numbered="true" toc="include" removeInRFC="fals
			e" pn="section-3">
			<name slugifiedName="name-background">Background</name>
			<t pn="section-3-1">There are a number of reasons why an authoritative ser
			ver may become
			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 has		authoritative servers for a query but still has relevant data that has
	aged past its TTL, that information can still be useful for generating		aged past its TTL, that information can still be useful for generating
	an answer under the metaphorical assumption that "stale bread is		an answer under the metaphorical assumption that "stale bread is
	better than no bread."</t>		better than no bread."</t>
			<t pn="section-3-2"><xref target="RFC1035" sectionFormat="comma" section="
	<t><xref target="RFC1035"/> Section 3.2.1 says that the TTL "specifies the time		3.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc1035#section-
			3.2.1" derivedContent="RFC1035"/>
			says that the TTL "specifies the time
	interval that the resource record may be cached before the source of		interval that the resource record may be cached before the source of
	the information should again be consulted", and Section 4.1.3 further		the information should again be consulted." <xref target="RFC1035" sectionFormat
	says the TTL, "specifies the time interval (in seconds) that the		="comma" section="4.1.3" format="default" derivedLink="https://rfc-editor.org/rf
			c/rfc1035#section-4.1.3" derivedContent="RFC1035"/> further
			says that the TTL "specifies the time interval (in seconds) that the
	resource record may be cached before it should be discarded."</t>		resource record may be cached before it should be discarded."</t>
			<t pn="section-3-3">A natural English interpretation of these remarks woul
	<t>A natural English interpretation of these remarks would seem to be		d seem to be
	clear enough that records past their TTL expiration must not be used.		clear enough that records past their TTL expiration must not be used.
	However, <xref target="RFC1035"/> predates the more rigorous terminology of		However, <xref target="RFC1035" format="default" sectionFormat="of" derivedConte
	<xref target="RFC2119"/> which softened the interpretation of "may" and "should"		nt="RFC1035"/> predates the more rigorous terminology of
	.</t>		<xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC21
			19"/>, which softened the interpretation of "may" and "should".</t>
	<t><xref target="RFC2181"/> aimed to provide "the precise definition of the Time		<t pn="section-3-4"><xref target="RFC2181" format="default" sectionFormat=
	to		"of" derivedContent="RFC2181"/> aimed to provide "the
	Live", but in Section 8 was mostly concerned with the numeric range of		precise definition of the Time to
			Live," but <xref target="RFC2181" sectionFormat="of" section="8" format="default
			" derivedLink="https://rfc-editor.org/rfc/rfc2181#section-8" derivedContent="RFC
			2181"/>
			was mostly concerned with the numeric range of
	values rather than data expiration behavior. It does, however, close		values rather than data expiration behavior. It does, however, close
	that section by noting, "The TTL specifies a maximum time to live, not		that section by noting, "The TTL specifies a maximum time to live, not
	a mandatory time to live." This wording again does not contain BCP 14		a mandatory time to live." This wording again does not contain BCP 14
	<xref target="RFC2119"/> key words, but does convey the natural language		key words <xref target="RFC2119" format="default" sectionFormat="of" derivedCont ent="RFC2119"/>, but it does convey the natural language
	connotation that data becomes unusable past TTL expiry.</t>		connotation that data becomes unusable past TTL expiry.</t>
			<t pn="section-3-5">As of the time of this writing, several large-scale op
	<t>As of the time of this writing, several large-scale operators use stale		erators use stale
	data for answers in some way. A number of recursive resolver packages,		data for answers in some way.
	including BIND, Knot, OpenDNS, and Unbound, provide options to use stale data.		A number of recursive resolver packages,
	Apple MacOS can also use stale data as part of the Happy Eyeballs algorithms in		including BIND, Knot Resolver, OpenDNS, and Unbound, provide options to use stal
			e data.
			Apple macOS can also use stale data as part of the Happy Eyeballs algorithms in
	mDNSResponder. The collective operational experience is that using stale data		mDNSResponder. The collective operational experience is that using stale data
	can provide significant benefit with minimal downside.</t>		can provide significant benefit with minimal downside.</t>
			</section>
	</section>		<section anchor="standards-action" numbered="true" toc="include" removeInRFC
	<section anchor="standards-action" title="Standards Action">		="false" pn="section-4">
			<name slugifiedName="name-standards-action">Standards Action</name>
	<t>The definition of TTL in <xref target="RFC1035"/> Sections 3.2.1 and 4.1.3 is		<t pn="section-4-1">The definition of TTL in Sections <xref target="RFC103
			5" section="3.2.1" sectionFormat="bare" format="default" derivedLink="https://rf
			c-editor.org/rfc/rfc1035#section-3.2.1" derivedContent="RFC1035"/> and <xref tar
			get="RFC1035" section="4.1.3" sectionFormat="bare" format="default" derivedLink=
			"https://rfc-editor.org/rfc/rfc1035#section-4.1.3" derivedContent="RFC1035"/> of
			<xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1
			035"/> is
	amended to read:</t>		amended to read:</t>
			<dl newline="false" spacing="normal" indent="5" pn="section-4-2">
	<t><list style="hanging">		<dt pn="section-4-2.1">TTL</dt>
	<t hangText='TTL'>		<dd pn="section-4-2.2">
	a 32-bit unsigned integer number of seconds that specifies the		a 32-bit unsigned integer number of seconds that specifies the
	duration that the resource record MAY be cached before the source of		duration that the resource record <bcp14>MAY</bcp14> be cached before the source
	the information MUST again be consulted. Zero values are interpreted		of
			the information <bcp14>MUST</bcp14> again be consulted. Zero values are interpr
			eted
	to mean that the RR can only be used for the transaction in progress,		to mean that the RR can only be used for the transaction in progress,
	and should not be cached. Values SHOULD be capped on the orders of		and should not be cached. Values <bcp14>SHOULD</bcp14> be capped on the order o
	days to weeks, with a recommended cap of 604,800 seconds (seven days). If the		f
			days to weeks, with a recommended cap of 604,800 seconds (7 days). If the
	data is unable to be authoritatively refreshed when the TTL expires,		data is unable to be authoritatively refreshed when the TTL expires,
	the record MAY be used as though it is unexpired. See [RFC Editor:		the record <bcp14>MAY</bcp14> be used as though it is unexpired. See Sections <x
	replace by RFC number] <xref target="example-method"/>		ref target="example-method" format="counter" sectionFormat="of" derivedContent="
	and <xref target="implementation-considerations"/> for details.</t>		5"/>
	</list></t>		and <xref target="implementation-considerations" format="counter" sectionFormat=
			"of" derivedContent="6"/> of
	<t>Interpreting values which have the high-order bit set as being		[RFC8767] for details.</dd>
	positive, rather than 0, is a change from <xref target="RFC2181"/>, the rational		</dl>
	e		<t pn="section-4-3">Interpreting values that have the high-order bit set a
	for which is explained in <xref target="implementation-considerations"/>.		s being
	Suggesting a cap of seven days, rather than the 68 years allowed by		positive, rather than 0, is a change from <xref target="RFC2181" format="default
	<xref target="RFC2181"/>, reflects the current practice of major modern DNS		" sectionFormat="of" derivedContent="RFC2181"/>, the rationale
			for which is explained in <xref target="implementation-considerations" format="d
			efault" sectionFormat="of" derivedContent="Section 6"/>.
			Suggesting a cap of 7 days, rather than the 68 years allowed by the full
			31 bits of
			<xref target="RFC2181" sectionFormat="of" section="8" format="default" derivedLi
			nk="https://rfc-editor.org/rfc/rfc2181#section-8" derivedContent="RFC2181"/>, re
			flects the current practice of major modern DNS
	resolvers.</t>		resolvers.</t>
			<t pn="section-4-4">When returning a response containing stale records, a
	<t>When returning a response containing stale records, a recursive		recursive
	resolver MUST set the TTL of each expired record in the message to a		resolver <bcp14>MUST</bcp14> set the TTL of each expired record in the message t
	value greater than 0, with a RECOMMENDED value of 30 seconds. See		o a
	<xref target="implementation-considerations"/> for explanation.</t>		value greater than 0, with a <bcp14>RECOMMENDED</bcp14> value of 30 seconds. See
			<xref target="implementation-considerations" format="default" sectionFormat="of"
	<t>Answers from authoritative servers that have a DNS Response Code of		derivedContent="Section 6"/> for explanation.</t>
	either 0 (NoError) or 3 (NXDomain) and the Authoritative Answers (AA)		<t pn="section-4-5">Answers from authoritative servers that have a DNS res
	bit set MUST be considered to have refreshed the data at the resolver.		ponse code of
			either 0 (NoError) or 3 (NXDomain) and the Authoritative Answer (AA)
			bit set <bcp14>MUST</bcp14> be considered to have refreshed the data at the reso
			lver.
	Answers from authoritative servers that have any other response code		Answers from authoritative servers that have any other response code
	SHOULD be considered a failure to refresh the data and therefore leave		<bcp14>SHOULD</bcp14> be considered a failure to refresh the data and therefore
	any previous state intact. See <xref target="implementation-considerations"/> fo		leave
	r		any previous state intact. See <xref target="implementation-considerations" form
			at="default" sectionFormat="of" derivedContent="Section 6"/> for
	a discussion.</t>		a discussion.</t>
			</section>
	</section>		<section anchor="example-method" numbered="true" toc="include" removeInRFC="
	<section anchor="example-method" title="Example Method">		false" pn="section-5">
			<name slugifiedName="name-example-method">Example Method</name>
	<t>There is more than one way a recursive resolver could		<t pn="section-5-1">There is more than one way a recursive resolver could
	responsibly implement this resiliency feature while still respecting		responsibly implement this resiliency feature while still respecting
	the intent of the TTL as a signal for when data is to be refreshed.</t>		the intent of the TTL as a signal for when data is to be refreshed.</t>
			<t pn="section-5-2">In this example method, four notable timers drive cons
	<t>In this example method four notable timers drive considerations for		iderations for
	the use of stale data:</t>		the use of stale data:</t>
			<ul spacing="normal" bare="false" empty="false" pn="section-5-3">
	<t><list style="symbols">		<li pn="section-5-3.1">A client response timer, which is the maximum amo
	<t>A client response timer, which is the maximum amount of time a		unt of time a
	recursive resolver should allow between the receipt of a resolution		recursive resolver should allow between the receipt of a resolution
	request and sending its response.</t>		request and sending its response.</li>
	<t>A query resolution timer, which caps the total amount of time a		<li pn="section-5-3.2">A query resolution timer, which caps the total am
	recursive resolver spends processing the query.</t>		ount of time a
	<t>A failure recheck timer, which limits the frequency at which a		recursive resolver spends processing the query.</li>
	failed lookup will be attempted again.</t>		<li pn="section-5-3.3">A failure recheck timer, which limits the frequen
	<t>A maximum stale timer, which caps the amount of time		cy at which a
	that records will be kept past their expiration.</t>		failed lookup will be attempted again.</li>
	</list></t>		<li pn="section-5-3.4">A maximum stale timer, which caps the amount of t
			ime
	<t>Most recursive resolvers already have the query resolution timer, and		that records will be kept past their expiration.</li>
	effectively some kind of failure recheck timer. The client		</ul>
			<t pn="section-5-4">Most recursive resolvers already have the query resolu
			tion timer and,
			effectively, some kind of failure recheck timer. The client
	response timer and maximum stale timer are new concepts for this		response timer and maximum stale timer are new concepts for this
	mechanism.</t>		mechanism.</t>
			<t pn="section-5-5">When a recursive resolver receives a request, it shoul
	<t>When a recursive resolver receives a request, it should start		d start
	the client response timer. This timer is used to avoid client		the client response timer. This timer is used to avoid client
	timeouts. It should be configurable, with a recommended value of 1.8		timeouts. It should be configurable, with a recommended value of 1.8
	seconds as being just under a common timeout value of 2 seconds while		seconds as being just under a common timeout value of 2 seconds while
	still giving the resolver a fair shot at resolving the name.</t>		still giving the resolver a fair shot at resolving the name.</t>
			<t pn="section-5-6">The resolver then checks its cache for any unexpired r
	<t>The resolver then checks its cache for any unexpired records that		ecords that
	satisfy the request and returns them if available. If it		satisfy the request and returns them if available. If it
	finds no relevant unexpired data and the Recursion Desired flag is not		finds no relevant unexpired data and the Recursion Desired flag is not
	set in the request, it should immediately return the response without		set in 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.</t>		but the specifics are implementation dependent.</t>
			<t pn="section-5-7">If iterative lookups will be done, then the failure re
	<t>If iterative lookups will be done, then the failure recheck timer is		check timer is
	consulted. Attempts to refresh from non-responsive or otherwise		consulted. Attempts to refresh from non-responsive or otherwise
	failing authoritative nameservers are recommended to be done no more		failing authoritative nameservers are recommended to be done no more
	frequently than every 30 seconds. If this request was received within		frequently than every 30 seconds. If this request was received within
	this period, the cache may be immediately consulted for stale data to		this period, the cache may be immediately consulted for stale data to
	satisfy the request.</t>		satisfy the request.</t>
			<t pn="section-5-8">Outside the period of the failure recheck timer, the r
	<t>Outside the period of the failure recheck timer, the resolver		esolver
	should start the query resolution timer and begin the iterative		should start the query resolution timer and begin the iterative
	resolution process. This timer bounds the work done by the resolver		resolution process. This timer bounds the work done by the resolver
	when contacting external authorities, and is commonly around 10 to 30		when contacting external authorities and is commonly around 10 to 30
	seconds. If this timer expires on an attempted lookup that is still		seconds. If this timer expires on an attempted lookup that is still
	being processed, the resolution effort is abandoned.</t>		being processed, the resolution effort is abandoned.</t>
			<t pn="section-5-9">If the answer has not been completely determined by th
	<t>If the answer has not been completely determined by the time the		e time the
	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 <xref target="standards-action"/>). The respons e is then sent to		greater than 0 (as specified in <xref target="standards-action" format="default" sectionFormat="of" derivedContent="Section 4"/>). The response is then sent to
	the client while the resolver continues its attempt to refresh the		the client while the resolver continues its attempt to refresh the
	data.</t>		data.</t>
			<t pn="section-5-10">When no authorities are able to be reached during a r
	<t>When no authorities are able to be reached during a resolution		esolution
	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 resolution effort.</t>		per resolution effort.</t>
			<t pn="section-5-11">Outside the resolution process, the maximum stale tim
	<t>Outside the resolution process, the maximum stale timer is used for		er is used for
	cache management and is independent of the query resolution		cache management and is independent of the query resolution
	process. This timer is conceptually different from the maximum cache		process. This timer is conceptually different from the maximum cache
	TTL that exists in many resolvers, the latter being a clamp on the		TTL that exists in many resolvers, the latter being a clamp on the
	value of TTLs as received from authoritative servers and recommended		value of TTLs as received from authoritative servers and recommended
	to be seven days in the TTL definition in <xref target="standards-action"/>.		to be 7 days in the TTL definition in <xref target="standards-action" format="de fault" sectionFormat="of" derivedContent="Section 4"/>.
	The maximum stale timer		The maximum stale timer
	should be configurable, and defines the length of time after a record		should be configurable. It defines the length of time after a record
	expires that it should be retained in the cache. The suggested value		expires that it should be retained in the cache. The suggested value
	is between 1 and 3 days.</t>		is between 1 and 3 days.</t>
			</section>
	</section>		<section anchor="implementation-considerations" numbered="true" toc="include
	<section anchor="implementation-considerations" title="Implementation Considerat		" removeInRFC="false" pn="section-6">
	ions">		<name slugifiedName="name-implementation-consideratio">Implementation Cons
			iderations</name>
	<t>This document mainly describes the issues behind serving stale data		<t pn="section-6-1">This document mainly describes the issues behind servi
			ng stale data
	and intentionally does not provide a formal algorithm. The concept is		and intentionally does not provide a formal algorithm. The concept is
	not overly complex, and the details are best left to resolver authors		not overly complex, and the details are best left to resolver authors
	to implement in their codebases. The processing of serve-stale is a		to implement in their codebases. The processing of serve-stale is a
	local operation, and consistent variables between deployments are not		local operation, and consistent variables between deployments are not
	needed for interoperability. However, we would like to highlight the		needed for interoperability. However, we would like to highlight the
	impact of various implementation choices, starting with the timers		impact of various implementation choices, starting with the timers
	involved.</t>		involved.</t>
			<t pn="section-6-2">The most obvious of these is the maximum stale timer.
	<t>The most obvious of these is the maximum stale timer. If this variable		If this variable
	is too large it could cause excessive cache memory usage, but if it is		is too large, it could cause excessive cache memory usage, but if it is
	too small, the serve-stale technique becomes less effective, as the		too small, the serve-stale technique becomes less effective, as the
	record may not be in the cache to be used if needed. Shorter values,		record may not be in the cache to be used if needed. Shorter values,
	even less than a day, can effectively handle the vast majority of		even less than a day, can effectively handle the vast majority of
	outages. Longer values, as much as a week, give time for monitoring		outages. Longer values, as much as a week, give time for monitoring
	systems to notice a resolution problem and for human intervention to		systems to notice a resolution problem and for human intervention to
	fix it; operational experience has been that sometimes the right		fix it; operational experience has been that sometimes the right
	people can be hard to track down and unfortunately slow to remedy the		people can be hard to track down and unfortunately slow to remedy the
	situation.</t>		situation.</t>
			<t pn="section-6-3">Increased memory consumption could be mitigated by pri
	<t>Increased memory consumption could be mitigated by prioritizing		oritizing
	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. Eviction strategies could consider additional factors,
	track the names in requests for their last time of use or their		including the last time of use or the popularity of a record, to
	popularity, using that as an additional factor when considering cache		retain active but stale records. A feature to manually flush
	eviction. A feature to manually flush only stale records could also		only stale records could also be useful.</t>
	be useful.</t>		<t pn="section-6-4">The client response timer is another variable that des
			erves
	<t>The client response timer is another variable which deserves
	consideration. If this value is too short, there exists the risk that		consideration. If this value is too short, there exists the risk that
	stale answers may be used even when the authoritative server is		stale answers may be used even when the authoritative server is
	actually reachable but slow; this may result in undesirable 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.</t>		user experience.</t>
			<t pn="section-6-5">The balance for the failure recheck timer is responsiv
	<t>The balance for the failure recheck timer is responsiveness in		eness 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, stale		resource use for resolution. If this variable is set too large, stale
	answers may continue to be returned even after the authoritative		answers may continue to be returned even after the authoritative
	server is reachable; per <xref target="RFC2308"/>, Section 7, this should be no		server is reachable; per <xref target="RFC2308" sectionFormat="comma" section="7
	more than five minutes. If this variable is too small, authoritative		" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2308#section-7" de
			rivedContent="RFC2308"/>, this should be no
			more than 5 minutes. If this variable is too small, authoritative
	servers may be targeted with a significant amount of excess traffic.</t>		servers may be targeted with a significant amount of excess traffic.</t>
			<t pn="section-6-6">Regarding the TTL to set on stale records in the respo
	<t>Regarding the TTL to set on stale records in the response,		nse,
	historically TTLs of zero seconds have been problematic for some		historically TTLs of 0 seconds have been problematic for some
	implementations, and negative values can't effectively be communicated		implementations, and negative values can't effectively be communicated
	to existing software. Other very short TTLs could lead to congestive		to existing software. Other very short TTLs could lead to congestive
	collapse as TTL-respecting clients rapidly try to refresh. The		collapse as TTL-respecting clients rapidly try to refresh. The
	recommended value of 30 seconds not only sidesteps those potential problems		recommended value of 30 seconds not only sidesteps those potential problems
	with no practical negative consequences, it also rate limits		with no practical negative consequences, it also rate-limits
	further queries from any client that honors the TTL, such as a		further queries from any client that honors the TTL, such as a
	forwarding resolver.</t>		forwarding resolver.</t>
			<t pn="section-6-7">As for the change to treat a TTL with the high-order b
	<t>As for the change to treat a TTL with the high-order bit set as		it set as
	positive and then clamping it, as opposed to <xref target="RFC2181"/> treating i		positive and then clamping it, as opposed to <xref target="RFC2181" format="defa
	t		ult" sectionFormat="of" derivedContent="RFC2181"/> treating it
	as zero, the rationale here is basically one of engineering simplicity		as 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 just		rational intentional meaning that wouldn't have been satisfied by just
	sending 0 instead, and similarly there was realistically no practical		sending 0 instead, and similarly there was realistically no practical
	purpose for sending TTLs of 2^25 seconds (1 year) or more. There's		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 significant bit set		also no record of TTLs in the wild having the most significant bit set
	in DNS-OARC's "Day in the Life" samples <xref target="DITL"/>. With no apparent		in the DNS Operations, Analysis, and Research Center's (DNS-OARC's) "Day in the Life" samples <xref target="DITL" format="default" sectionFormat="of" derivedCon tent="DITL"/>. With no apparent
	reason for		reason for
	operators to use them intentionally, that leaves either errors or		operators to use them intentionally, that leaves either errors or
	non-standard experiments as explanations as to why such TTLs might be		non-standard experiments as explanations as to why such TTLs might be
	encountered, with neither providing an obviously compelling reason as		encountered, with neither providing an obviously compelling reason as
	to why having the leading bit set should be treated differently from		to why having the leading bit set should be treated differently from
	having any of the next eleven bits set and then capped per		having any of the next eleven bits set and then capped per
	<xref target="standards-action"/>.</t>		<xref target="standards-action" format="default" sectionFormat="of" derivedConte
			nt="Section 4"/>.</t>
	<t>Another implementation consideration is the use of		<t pn="section-6-8">Another implementation consideration is the use of
	stale nameserver addresses for lookups. This is mentioned explicitly		stale nameserver addresses for lookups. This is mentioned explicitly
	because, in some resolvers, getting the addresses for nameservers is		because, in some resolvers, getting the addresses for nameservers is
	a separate path from a normal cache lookup. If authoritative server		a separate path from a normal cache lookup. If authoritative server
	addresses are not able to be refreshed, resolution can possibly still		addresses are not able to be refreshed, resolution can possibly still
	be successful if the authoritative servers themselves are up. For		be successful if the authoritative servers themselves are up. For
	instance, consider an attack on a top-level domain that takes its		instance, consider an attack on a top-level domain that takes its
	nameservers offline; serve-stale resolvers that had expired glue		nameservers offline; serve-stale resolvers that had expired glue
	addresses for subdomains within that TLD would still be able to		addresses for subdomains within that top-level domain would still be able to
	resolve names within those subdomains, even those it had not		resolve names within those subdomains, even those it had not
	previously looked up.</t>		previously looked up.</t>
			<t pn="section-6-9">The directive in <xref target="standards-action" forma
	<t>The directive in <xref target="standards-action"/> that only NoError and NXDo		t="default" sectionFormat="of" derivedContent="Section 4"/> that only NoError an
	main		d NXDomain
	responses should invalidate any previously associated answer stems		responses should invalidate any previously associated answer stems
	from the fact that no other RCODEs that a resolver normally		from the fact that no other RCODEs that a resolver normally
	encounters make any assertions regarding the name in the question or		encounters make any assertions regarding the name in the question or
	any data associated with it. This comports with existing resolver		any data associated with it. This comports with existing resolver
	behavior where a failed lookup (say, during pre-fetching) doesn't		behavior where a failed lookup (say, during prefetching) doesn't
	impact the existing cache state. Some authoritative server operators		impact the existing cache state. Some authoritative server operators
	have said that they would prefer stale answers to be used in the event		have said that they would prefer stale answers to be used in the event
	that their servers are responding with errors like ServFail instead of		that their servers are responding with errors like ServFail instead of
	giving true authoritative answers. Implementers MAY decide to return		giving true authoritative answers. Implementers <bcp14>MAY</bcp14> decide to re turn
	stale answers in this situation.</t>		stale answers in this situation.</t>
			<t pn="section-6-10">Since the goal of serve-stale is to provide resilienc
	<t>Since the goal of serve-stale is to provide resiliency for all obvious		y for all obvious
	errors to refresh data, these other RCODEs are treated as though they		errors to refresh data, these other RCODEs are treated as though they
	are equivalent to not getting an authoritative response. Although		are equivalent to not getting an authoritative response. Although
	NXDomain for a previously existing name might well be an error, it is		NXDomain for a previously existing name might well be an error, it is
	not handled that way because there is no effective way to distinguish		not handled that way because there is no effective way to distinguish
	operator intent for legitimate cases versus error cases.</t>		operator intent for legitimate cases versus error cases.</t>
			<t pn="section-6-11">During discussion in the IETF, it was suggested that,
	<t>During discussion in the IETF, it was suggested that,		if all authorities return responses with an RCODE of Refused,
	if all authorities return responses with RCODE of Refused,
	it may be an explicit signal to take down the zone from		it may be an explicit signal to take down the zone from
	servers that still have the zone's delegation pointed to them.		servers that still have the zone's delegation pointed to them.
	Refused, however, is also		Refused, however, is also
	overloaded to mean multiple possible failures which could represent		overloaded to mean multiple possible failures that could represent
	transient configuration failures. Operational experience has shown		transient configuration failures. Operational experience has shown
	that purposely returning Refused is a poor way to achieve an		that purposely returning Refused is a poor way to achieve an
	explicit takedown of a zone compared to either updating the delegation		explicit takedown of a zone compared to either updating the delegation
	or returning NXDomain with a suitable SOA for extended negative		or returning NXDomain with a suitable SOA for extended negative
	caching. Implementers MAY nonetheless consider whether to		caching. Implementers <bcp14>MAY</bcp14> nonetheless consider whether to
	treat all authorities returning Refused as preempting the use of stale		treat all authorities returning Refused as preempting the use of stale
	data.</t>		data.</t>
			</section>
	</section>		<section anchor="implementation-caveats" numbered="true" toc="include" remov
	<section anchor="implementation-caveats" title="Implementation Caveats">		eInRFC="false" pn="section-7">
			<name slugifiedName="name-implementation-caveats">Implementation Caveats</
	<t>Stale data is used only when refreshing has failed in order to adhere		name>
	to the original intent of the design of the DNS and the behaviour		<t pn="section-7-1">Stale data is used only when refreshing has failed in
			order to adhere
			to the original intent of the design of the DNS and the behavior
	expected by operators. If stale data were to always be used		expected by operators. If stale data were to always be used
	immediately and then a cache refresh attempted after the client		immediately and then a cache refresh attempted after the client
	response has been sent, the resolver would frequently be sending data		response has been sent, the resolver would frequently be sending data
	that it would have had no trouble refreshing. Because modern resolvers use		that it would have had no trouble refreshing. Because modern resolvers use
	techniques like pre-fetching and request coalescing for efficiency, it		techniques like prefetching and request coalescing for efficiency, it
	is not necessary that every client request needs to trigger a new		is not necessary that every client request needs to trigger a new
	lookup flow in the presence of stale data, but rather that a		lookup flow in the presence of stale data, but rather that a
	good-faith effort has been recently made to refresh the stale data		good-faith effort has been recently made to refresh the stale data
	before it is delivered to any client.</t>		before it is delivered to any client.</t>
			<t pn="section-7-2">It is important to continue the resolution attempt aft
	<t>It is important to continue the resolution attempt after the stale		er the stale
	response has been sent, until the query resolution timeout, because		response has been sent, until the query resolution timeout, because
	some pathological resolutions can take many seconds to succeed as they		some pathological resolutions can take many seconds to succeed as they
	cope with unavailable servers, bad networks, and other problems.		cope with unavailable servers, bad networks, and other problems.
	Stopping the resolution attempt when the response with expired data		Stopping the resolution attempt when the response with expired data
	has been sent would mean that answers in these pathological cases		has been sent would mean that answers in these pathological cases
	would never be refreshed.</t>		would never be refreshed.</t>
			<t pn="section-7-3">The continuing prohibition against using data with a 0
	<t>The continuing prohibition against using data with a 0 second TTL		-second TTL
	beyond the current transaction explicitly extends to it being unusable		beyond the current transaction explicitly extends to it being unusable
	even for stale fallback, as it is not to be cached at all.</t>		even for stale fallback, as it is not to be cached at all.</t>
			<t pn="section-7-4">Be aware that Canonical Name (CNAME) and DNAME records
	<t>Be aware that Canonical Name (CNAME) and DNAME <xref target="RFC6672"/> recor		<xref target="RFC6672" format="default" sectionFormat="of" derivedContent="RFC6
	ds		672"/> mingled in the expired
	mingled in the expired
	cache with other records at the same owner name can cause surprising		cache with other records at the same owner name can cause surprising
	results. This was observed with an initial implementation in BIND		results. This was observed with an initial implementation in BIND
	when a hostname changed from having an IPv4 Address (A) record to a		when a hostname changed from having an IPv4 Address (A) record to a
	CNAME. The version of BIND being used did not evict other types in		CNAME. The version of BIND being used did not evict other types in
	the cache when a CNAME was received, which in normal operations is not		the cache when a CNAME was received, which in normal operations is not
	a significant issue. However, after both records expired and the		a significant issue. However, after both records expired and the
	authorities became unavailable, the fallback to stale answers returned		authorities became unavailable, the fallback to stale answers returned
	the older A instead of the newer CNAME.</t>		the older A instead of the newer CNAME.</t>
			</section>
	</section>		<section anchor="implementation-status" numbered="true" toc="include" remove
	<section anchor="implementation-status" title="Implementation Status">		InRFC="false" pn="section-8">
			<name slugifiedName="name-implementation-status">Implementation Status</na
	<t>The algorithm described in <xref target="example-method"/> was		me>
			<t pn="section-8-1">The algorithm described in <xref target="example-metho
			d" format="default" sectionFormat="of" derivedContent="Section 5"/> was
	originally implemented as a patch to BIND 9.7.0. It has been in use		originally implemented as a patch to BIND 9.7.0. It has been in use
	on Akamai's production network since 2011, and effectively		on Akamai's production network since 2011; it effectively
	smoothed over transient failures and longer outages that would have		smoothed over transient failures and longer outages that would have
	resulted in major incidents. The patch was contributed to Internet		resulted in major incidents. The patch was contributed to the Internet
	Systems Consortium and the functionality is now available in BIND 9.12		Systems Consortium, and the functionality is now available in BIND 9.12
	and later via the options stale-answer-enable, stale-answer-ttl, and		and later via the options stale-answer-enable, stale-answer-ttl, and
	max-stale-ttl.</t>		max-stale-ttl.</t>
			<t pn="section-8-2">Unbound has a similar feature for serving stale answer
	<t>Unbound has a similar feature for serving stale answers, and will		s 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.</t>		failed to refresh the answer by prefetching. Starting from
			version 1.10.0, Unbound can also be configured to follow the
	<t>Knot Resolver has a demo module here:		algorithm described in <xref target="example-method" format="default" sectionFor
	https://knot-resolver.readthedocs.io/en/stable/modules.html#serve-stale</t>		mat="of" derivedContent="Section 5"/>. Both behaviors can be
			configured and fine-tuned with the available serve-expired-*
	<t>Apple's system resolvers are also known to use stale answers, but the		options.</t>
			<t pn="section-8-3">Knot Resolver has a demo module here:
			<eref target="https://knot-resolver.readthedocs.io/en/stable/modules-serve_stale
			.html" brackets="angle"/>.</t>
			<t pn="section-8-4">Apple's system resolvers are also known to use stale a
			nswers, but the
	details are not readily available.</t>		details are not readily available.</t>
			<t pn="section-8-5">In the research paper "When the Dike Breaks: Dissectin
	<t>In the research paper "When the Dike Breaks: Dissecting DNS Defenses		g DNS Defenses
	During DDoS" <xref target="DikeBreaks"/>, the authors detected some use of		During DDoS" <xref target="DikeBreaks" format="default" sectionFormat="of" deriv
			edContent="DikeBreaks"/>, the authors detected some use of
	stale answers by resolvers when authorities came under attack. Their		stale answers by resolvers when authorities came under attack. Their
	research results suggest that more widespread adoption of the technique		research results suggest that more widespread adoption of the technique
	would significantly improve resiliency for the large number of requests		would significantly improve resiliency for the large number of requests
	that fail or experience abnormally long resolution times during an attack.</t>		that fail or experience abnormally long resolution times during an attack.</t>
			</section>
	</section>		<section anchor="edns-option" numbered="true" toc="include" removeInRFC="fal
	<section anchor="edns-option" title="EDNS Option">		se" pn="section-9">
			<name slugifiedName="name-edns-option">EDNS Option</name>
	<t>During the discussion of serve-stale in the IETF,		<t pn="section-9-1">During the discussion of serve-stale in the IETF,
	it was suggested that an EDNS option should be available to either		it was suggested that an EDNS option <xref target="RFC6891" format="default" sec
	explicitly opt-in to getting data that is possibly stale, or at least		tionFormat="of" derivedContent="RFC6891"/> should be
	as a debugging tool to indicate when stale data has been used for a		available. One proposal was to use it to opt in to getting data that is
	response.</t>		possibly stale, and another was to signal when stale data has been used for a re
			sponse.</t>
	<t>The opt-in use case was rejected as the technique was meant to be		<t pn="section-9-2">The opt-in use case was rejected, as the technique was
			meant to be
	immediately useful in improving DNS resiliency for all clients.</t>		immediately useful in improving DNS resiliency for all clients.</t>
			<t pn="section-9-3">The reporting case was ultimately also rejected becaus
	<t>The reporting case was ultimately also rejected because		e
	even the simpler version of a proposed		even the simpler version of a proposed
	option was still too much bother to implement for too little perceived		option was still too much bother to implement for too little perceived
	value.</t>		value.</t>
			</section>
	</section>		<section anchor="security-considerations" numbered="true" toc="include" remo
	<section anchor="security-considerations" title="Security Considerations">		veInRFC="false" pn="section-10">
			<name slugifiedName="name-security-considerations">Security Considerations
	<t>The most obvious security issue is the increased likelihood of DNSSEC		</name>
			<t pn="section-10-1">The most obvious security issue is the increased like
			lihood of DNSSEC
	validation failures when using stale data because signatures could be		validation failures when using stale data because signatures could be
	returned outside their validity period. Stale negative records can increase		returned outside their validity period. Stale negative records can increase
	the time window where newly published TLSA or DS RRs may not be used due		the time window where newly published TLSA or DS RRs may not be used due
	to cached NSEC or NSEC3 records. These scenarios would only be an issue		to cached NSEC or NSEC3 records. These scenarios would only be an issue if
	if the authoritative servers are unreachable, the only time the		the authoritative servers are unreachable (the only time the techniques in
	techniques in this document are used, and thus does not introduce		this document are used), and thus serve-stale does not introduce a new
	a new failure in place of what would have otherwise been success.</t>		failure in place of what would have otherwise been success.</t>
			<t pn="section-10-2">Additionally, bad actors have been known to use DNS c
	<t>Additionally, bad actors have been known to use DNS caches to keep		aches to keep
	records alive even after their authorities have gone away. The serve stale		records alive even after their authorities have gone away. The serve-stale
	feature potentially makes the attack easier, although without introducing		feature potentially makes the attack easier, although without introducing
	a new risk. In addition, attackers could combine this with a DDoS attack on		a new risk. In addition, attackers could combine this with a DDoS attack on
	authoritative servers with the explicit intent of having stale information		authoritative servers with the explicit intent of having stale information
	cached for longer. But if attackers have this capacity, they probably could		cached for a longer period of time. But if attackers have this capacity, they pr obably could
	do much worse than prolonging the life of old data.</t>		do much worse than prolonging the life of old data.</t>
			<t pn="section-10-3">In <xref target="CloudStrife" format="default" sectio
	<t>In <xref target="CloudStrife"/>, it was demonstrated how stale DNS data, name		nFormat="of" derivedContent="CloudStrife"/>, it was demonstrated how stale DNS d
	ly		ata, namely
	hostnames pointing to addresses that are no longer in use by the owner		hostnames pointing to addresses that are no longer in use by the owner
	of the name, can be used to co-opt security such as to get		of the name, can be used to co-opt security -- for example, to get
	domain-validated certificates fraudulently issued to an attacker.		domain-validated certificates fraudulently issued to an attacker.
	While this document does not create a new vulnerability in this area, it		While this document does not create a new vulnerability in this area, it
	does potentially enlarge the window in which such an attack could be		does potentially enlarge the window in which such an attack could be
	made. A proposed mitigation is that certificate authorities should fully		made. A proposed mitigation is that certificate authorities should fully
	look up each name starting at the DNS root for every name lookup.		look up each name starting at the DNS root for every name lookup.
	Alternatively, CAs should use a resolver that is not serving stale data.</t>		Alternatively, certificate authorities should use a resolver that is not serving
			stale data.</t>
	</section>		</section>
	<section anchor="privacy-considerations" title="Privacy Considerations">		<section anchor="privacy-considerations" numbered="true" toc="include" remov
			eInRFC="false" pn="section-11">
	<t>This document does not add any practical new privacy issues.</t>		<name slugifiedName="name-privacy-considerations">Privacy Considerations</
			name>
	</section>		<t pn="section-11-1">This document does not add any practical new privacy
	<section anchor="nat-considerations" title="NAT Considerations">		issues.</t>
			</section>
	<t>The method described here is not affected by the use of NAT devices.</t>		<section anchor="nat-considerations" numbered="true" toc="include" removeInR
			FC="false" pn="section-12">
	</section>		<name slugifiedName="name-nat-considerations">NAT Considerations</name>
	<section anchor="iana-considerations" title="IANA Considerations">		<t pn="section-12-1">The method described here is not affected by the use
			of NAT devices.</t>
	<t>There are no IANA considerations.</t>		</section>
			<section anchor="iana-considerations" numbered="true" toc="include" removeIn
	</section>		RFC="false" pn="section-13">
	<section anchor="acknowledgements" title="Acknowledgements">		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
			<t pn="section-13-1">This document has no IANA actions.</t>
	<t>The authors wish to thank Brian Carpenter, Robert Edmonds, Tony Finch,		</section>
	Bob Harold, Tatuya Jinmei, Matti Klock, Jason Moreau, Giovane Moura,
	Jean Roy, Mukund Sivaraman, Davey Song, Paul Vixie, Ralf Weber and
	Paul Wouters for their review and feedback. Paul Hoffman deserves
	special thanks for submitting a number of Pull Requests.</t>
	<t>Thank you also to the following members of the IESG for their final
	review: Roman Danyliw, Benjamin Kaduk, Suresh Krishnan, Mirja
	Kuehlewind, and Adam Roach.</t>
	</section>
	</middle>		</middle>
	<back>		<back>
			<references pn="section-14">
	<references title='Normative References'>		<name slugifiedName="name-references">References</name>
			<references pn="section-14.1">
	&RFC1035;		<name slugifiedName="name-normative-references">Normative References</na
	&RFC2181;		me>
	&RFC1034;		<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1
	&RFC2119;		034" quoteTitle="true" derivedAnchor="RFC1034">
	&RFC8174;		<front>
	&RFC2308;		<title>Domain names - concepts and facilities</title>
			<author initials="P.V." surname="Mockapetris" fullname="P.V. Mockape
	</references>		tris">
			<organization showOnFrontPage="true"/>
	<references title='Informative References'>		</author>
			<date year="1987" month="November"/>
	<reference anchor="DikeBreaks" target="https://www.isi.edu/~johnh/PAPERS/Moura18		<abstract>
	b.pdf">		<t>This RFC is the revised basic definition of The Domain Name Sys
	<front>		tem. It obsoletes RFC-882. This memo describes the domain style names and thei
	<title>When the Dike Breaks: Dissecting DNS Defenses During DDos</title>		r used for host address look up and electronic mail forwarding. It discusses th
	<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Moura">		e clients and servers in the domain name system and the protocol used between th
	<organization></organization>		em.</t>
	</author>		</abstract>
	<author initials="J." surname="Heidemann" fullname="John Heidemann">		</front>
	<organization></organization>		<seriesInfo name="STD" value="13"/>
	</author>		<seriesInfo name="RFC" value="1034"/>
	<author initials="M." surname="Mueller" fullname="Moritz Mueller">		<seriesInfo name="DOI" value="10.17487/RFC1034"/>
	<organization></organization>		</reference>
	</author>		<reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1
	<author initials="R.d.O." surname="Schmidt" fullname="Ricardo de O. Schmidt"		035" quoteTitle="true" derivedAnchor="RFC1035">
	>		<front>
	<organization></organization>		<title>Domain names - implementation and specification</title>
	</author>		<author initials="P.V." surname="Mockapetris" fullname="P.V. Mockape
	<author initials="M." surname="Davids" fullname="Marco Davids">		tris">
	<organization></organization>		<organization showOnFrontPage="true"/>
	</author>		</author>
	<date year="2018" month="October" day="31"/>		<date year="1987" month="November"/>
	</front>		<abstract>
	<seriesInfo name="ACM" value="2018 Internet Measurement Conference"/>		<t>This RFC is the revised specification of the protocol and forma
	<seriesInfo name="DOI" value="10.1145/3278532.3278534"/>		t used in the implementation of the Domain Name System. It obsoletes RFC-883. T
	</reference>		his memo documents the details of the domain name client - server communication.
	<reference anchor="CloudStrife" target="https://www.ndss-symposium.org/wp-conten		</t>
	t/uploads/2018/02/ndss2018_06A-4_Borgolte_paper.pdf">		</abstract>
	<front>		</front>
	<title>Cloud Strife: Mitigating the Security Risks of Domain-Validated Certi		<seriesInfo name="STD" value="13"/>
	ficates</title>		<seriesInfo name="RFC" value="1035"/>
	<author initials="K." surname="Borgolte" fullname="Kevin Borgolte">		<seriesInfo name="DOI" value="10.17487/RFC1035"/>
	<organization></organization>		</reference>
	</author>		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<author initials="T." surname="Fiebig" fullname="Tobias Fiebig">		119" quoteTitle="true" derivedAnchor="RFC2119">
	<organization></organization>		<front>
	</author>		<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	<author initials="S." surname="Hao" fullname="Shuang Hao">		le>
	<organization></organization>		<author initials="S." surname="Bradner" fullname="S. Bradner">
	</author>		<organization showOnFrontPage="true"/>
	<author initials="C." surname="Kruegel" fullname="Christopher Kruegel">		</author>
	<organization></organization>		<date year="1997" month="March"/>
	</author>		<abstract>
	<author initials="G." surname="Vigna" fullname="Giovanni Vigna">		<t>In many standards track documents several words are used to sig
	<organization></organization>		nify the requirements in the specification. These words are often capitalized.
	</author>		This document defines these words as they should be interpreted in IETF document
	<date year="2018" month="July" day="16"/>		s. This document specifies an Internet Best Current Practices for the Internet
	</front>		Community, and requests discussion and suggestions for improvements.</t>
	<seriesInfo name="ACM" value="2018 Applied Networking Research Workshop"/>		</abstract>
	<seriesInfo name="DOI" value="10.1145/3232755.3232859"/>		</front>
	</reference>		<seriesInfo name="BCP" value="14"/>
	<reference anchor="DITL" target="https://www.dns-oarc.net/oarc/data/ditl">		<seriesInfo name="RFC" value="2119"/>
	<front>		<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	<title>DITL Traces and Analysis | DNS-OARC</title>		</reference>
	<author >		<reference anchor="RFC2181" target="https://www.rfc-editor.org/info/rfc2
	<organization></organization>		181" quoteTitle="true" derivedAnchor="RFC2181">
	</author>		<front>
	<date year="n.d."/>		<title>Clarifications to the DNS Specification</title>
	</front>		<author initials="R." surname="Elz" fullname="R. Elz">
	</reference>		<organization showOnFrontPage="true"/>
	&RFC8499;		</author>
	&RFC6672;		<author initials="R." surname="Bush" fullname="R. Bush">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="1997" month="July"/>
			<abstract>
			<t>This document considers some areas that have been identified as
			problems with the specification of the Domain Name System, and proposes remedie
			s for the defects identified. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="2181"/>
			<seriesInfo name="DOI" value="10.17487/RFC2181"/>
			</reference>
			<reference anchor="RFC2308" target="https://www.rfc-editor.org/info/rfc2
			308" quoteTitle="true" derivedAnchor="RFC2308">
			<front>
			<title>Negative Caching of DNS Queries (DNS NCACHE)</title>
			<author initials="M." surname="Andrews" fullname="M. Andrews">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="1998" month="March"/>
			<abstract>
			<t>RFC1034 provided a description of how to cache negative respons
			es. It however had a fundamental flaw in that it did not allow a name server to
			hand out those cached responses to other resolvers, thereby greatly reducing th
			e effect of the caching. This document addresses issues raise in the light of e
			xperience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="2308"/>
			<seriesInfo name="DOI" value="10.17487/RFC2308"/>
			</reference>
			<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
			174" quoteTitle="true" derivedAnchor="RFC8174">
			<front>
			<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
			tle>
			<author initials="B." surname="Leiba" fullname="B. Leiba">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="May"/>
			<abstract>
			<t>RFC 2119 specifies common key words that may be used in protoco
			l specifications. This document aims to reduce the ambiguity by clarifying tha
			t only UPPERCASE usage of the key words have the defined special meanings.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="8174"/>
			<seriesInfo name="DOI" value="10.17487/RFC8174"/>
			</reference>
			</references>
			<references pn="section-14.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<reference anchor="CloudStrife" target="https://www.ndss-symposium.org/w
			p-content/uploads/2018/02/ndss2018_06A-4_Borgolte_paper.pdf" quoteTitle="true" d
			erivedAnchor="CloudStrife">
			<front>
			<title>Cloud Strife: Mitigating the Security Risks of Domain-Validat
			ed Certificates</title>
			<seriesInfo name="DOI" value="10.1145/3232755.3232859"/>
			<seriesInfo name="ACM" value="2018 Applied Networking Research Works
			hop"/>
			<author initials="K." surname="Borgolte" fullname="Kevin Borgolte">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="T." surname="Fiebig" fullname="Tobias Fiebig">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Hao" fullname="Shuang Hao">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C." surname="Kruegel" fullname="Christopher Kruege
			l">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Vigna" fullname="Giovanni Vigna">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2018" month="July"/>
			</front>
			</reference>
			<reference anchor="DikeBreaks" target="https://www.isi.edu/~johnh/PAPERS
			/Moura18b.pdf" quoteTitle="true" derivedAnchor="DikeBreaks">
			<front>
			<title>When the Dike Breaks: Dissecting DNS Defenses During DDoS</ti
			tle>
			<seriesInfo name="DOI" value="10.1145/3278532.3278534"/>
			<seriesInfo name="ACM" value="2018 Internet Measurement Conference"/
			>
			<author initials="G.C.M." surname="Moura" fullname="Giovane C. M. Mo
			ura">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Heidemann" fullname="John Heidemann">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M." surname="Müller" fullname="Moritz Müller">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R. de O." surname="Schmidt" fullname="Ricardo de O
			. Schmidt">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M." surname="Davids" fullname="Marco Davids">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2018" month="October"/>
			</front>
			</reference>
			<reference anchor="DITL" target="https://www.dns-oarc.net/oarc/data/ditl
			" quoteTitle="true" derivedAnchor="DITL">
			<front>
			<title>DITL Traces and Analysis</title>
			<author>
			<organization showOnFrontPage="true">DNS-OARC</organization>
			</author>
			<date month="January" year="2018"/>
			</front>
			</reference>
			<reference anchor="RFC6672" target="https://www.rfc-editor.org/info/rfc6
			672" quoteTitle="true" derivedAnchor="RFC6672">
			<front>
			<title>DNAME Redirection in the DNS</title>
			<author initials="S." surname="Rose" fullname="S. Rose">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="W." surname="Wijngaards" fullname="W. Wijngaards">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2012" month="June"/>
			<abstract>
			<t>The DNAME record provides redirection for a subtree of the doma
			in name tree in the DNS. That is, all names that end with a particular suffix a
			re redirected to another part of the DNS. This document obsoletes the original
			specification in RFC 2672 as well as updates the document on representing IPv6 a
			ddresses in DNS (RFC 3363). [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6672"/>
			<seriesInfo name="DOI" value="10.17487/RFC6672"/>
			</reference>
			<reference anchor="RFC6891" target="https://www.rfc-editor.org/info/rfc6
			891" quoteTitle="true" derivedAnchor="RFC6891">
			<front>
			<title>Extension Mechanisms for DNS (EDNS(0))</title>
			<author initials="J." surname="Damas" fullname="J. Damas">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M." surname="Graff" fullname="M. Graff">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="P." surname="Vixie" fullname="P. Vixie">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2013" month="April"/>
			<abstract>
			<t>The Domain Name System's wire protocol includes a number of fix
			ed fields whose range has been or soon will be exhausted and does not allow requ
			estors to advertise their capabilities to responders. This document describes b
			ackward-compatible mechanisms for allowing the protocol to grow.</t>
			<t>This document updates the Extension Mechanisms for DNS (EDNS(0)
			) specification (and obsoletes RFC 2671) based on feedback from deployment exper
			ience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in
			the Domain Name System") and adds considerations on the use of extended labels
			in the DNS.</t>
			</abstract>
			</front>
			<seriesInfo name="STD" value="75"/>
			<seriesInfo name="RFC" value="6891"/>
			<seriesInfo name="DOI" value="10.17487/RFC6891"/>
			</reference>
			<reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8
			499" quoteTitle="true" derivedAnchor="RFC8499">
			<front>
			<title>DNS Terminology</title>
			<author initials="P." surname="Hoffman" fullname="P. Hoffman">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A." surname="Sullivan" fullname="A. Sullivan">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="K." surname="Fujiwara" fullname="K. Fujiwara">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2019" month="January"/>
			<abstract>
			<t>The Domain Name System (DNS) is defined in literally dozens of
			different RFCs. The terminology used by implementers and developers of DNS prot
			ocols, and by operators of DNS systems, has sometimes changed in the decades sin
			ce the DNS was first defined. This document gives current definitions for many
			of the terms used in the DNS in a single document.</t>
			<t>This document obsoletes RFC 7719 and updates RFC 2308.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="219"/>
			<seriesInfo name="RFC" value="8499"/>
			<seriesInfo name="DOI" value="10.17487/RFC8499"/>
			</reference>
			</references>
	</references>		</references>
			<section anchor="acknowledgements" numbered="false" toc="include" removeInRF
			C="false" pn="section-appendix.a">
			<name slugifiedName="name-acknowledgements">Acknowledgements</name>
			<t pn="section-appendix.a-1">The authors wish to thank <contact fullname="
			Brian Carpenter"/>,
			<contact fullname="Vladimir Cunat"/>, <contact fullname="Robert Edmonds"/>
			, <contact fullname="Tony Finch"/>,
			<contact fullname="Bob Harold"/>, <contact fullname="Tatuya Jinmei"/>, <contact
			fullname="Matti Klock"/>, <contact fullname="Jason Moreau"/>, <contact fullname=
			"Giovane Moura"/>,
			<contact fullname="Jean Roy"/>, <contact fullname="Mukund Sivaraman"/>, <contact
			fullname="Davey Song"/>, <contact fullname="Paul Vixie"/>, <contact fullname="R
			alf Weber"/>, and
			<contact fullname="Paul Wouters"/> for their review and feedback. <contact full
			name="Paul Hoffman"/> deserves
			special thanks for submitting a number of Pull Requests.</t>
			<t pn="section-appendix.a-2">Thank you also to the following members of th
			e IESG for their final
			review: <contact fullname="Roman Danyliw"/>, <contact fullname="Benjamin Kaduk"
			/>, <contact fullname="Suresh Krishnan"/>, <contact fullname="Mirja Kühlewind"/>
			, and <contact fullname="Adam Roach"/>.</t>
			</section>
			<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.b">
			<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
			<author initials="D." surname="Lawrence" fullname="David C Lawrence">
			<organization showOnFrontPage="true">Oracle</organization>
			<address>
			<email>tale@dd.org</email>
			</address>
			</author>
			<author initials="W." surname="Kumari" fullname="Warren &quot;Ace&quot; Ku
			mari">
			<organization showOnFrontPage="true">Google</organization>
			<address>
			<postal>
			<street>1600 Amphitheatre Parkway</street>
			<city>Mountain View</city>
			<region>CA</region>
			<code>94043</code>
			<country>United States of America</country>
			</postal>
			<email>warren@kumari.net</email>
			</address>
			</author>
			<author initials="P." surname="Sood" fullname="Puneet Sood">
			<organization showOnFrontPage="true">Google</organization>
			<address>
			<email>puneets@google.com</email>
			</address>
			</author>
			</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAErV7l0AA7V8W3cbR5Lme/6KXPrB0hwAIiXZltQP0xApt9UWRa1It3d3
	ZrdPApUA0ixUYSqrCKF7PL9s3vaPbXwRkVlVJOhxP6zPkUkCWXmJ6xeXrOl0
	atrQlv6NvfbNXajW9rp1pbcXrnW2re377a6p7+jvj9f2s4+hDL5aHoxbLBp/
	94Y/xoNeHjNFvazclmYrGrdqp8G3q2lRxXo3jRg1jRg1PTs1hWtplH1+evZ6
	evZ8evramLBr3ti26WL7/PT09elz4xrv3tj3Veubyrdmv+b1rj7Zn+vmFlv9
	U1N3O3O77wdNL7CuWbr2jY1tYbodFopv7Nnpi5cT/P+biX1+9urMmGVd0Bxv
	bBenLi5DMLvwxlg7pVMv+Wc8bBu/ivJ73bT8h3Fdu6kbHkn/rA0VzX4xO5/Z
	D27fEHE8fyxUuHB3obDn46/qhla9atyylL/91oWSTk6U+WNRzOhrM57955n9
	sdu6Jgxm/tk1NKM9mS/9yfBbnvxPdb3WySNt2xMxzr49PbXz7W4T2o139KH9
	5JrbvTvwqGVoD2/sZd1VrQuV/Uvwe/m8Lmit87l9/fL05Qv9iAY1NPqn6/lw
	+3ve0B9veSsz8Gt8iE8ze13XxeAIn7qKttZ/en/rOvGOh8U/rvmb2bLekqhU
	q7rZujbceXDiItz6tyQst/ENP9m6Zo1Db9p2F988e7bf72chhpkvumf/8Uu9
	qTbPPs0/vft8/YyO3LizV4vZrljJo6IMJz9viLpEKp7b6uT0R4x+2UL2IPkX
	fuWr6KO96Br+7KKOJzxNLyX4b6o/08n/FOo7V3lLQnM5s7yHR0b+mTZrf/Ch
	IGJU1SODLusmtH+zl50vS988MuhzWLqmqG3h7RWxYrnZhqJ9bELXLGsR3shf
	ibaSsr4i3Z2+OBPR8k0gi0CsSOecn1/KqKyP9tK72DV+66vWntfVyvd6QHy7
	eg/NnJ2dvfzm2Yvn37365sXzmfx8SUPOy7orrtsmrPzjfK2KGKekqrs6hm4L
	7Xm2302XNW2gap91u7J2RXyGTT07ff4Mo/H7X0+/nU9f/vUtDa/L1v9153a+
	eSAEvAGrO7CXoQ1rx8yHYFz7JXG9PRBl42209cpe1CSx1fQvrgwgGCm+b9qw
	IsKTCfo9cvGjJwts06YeGXRTL4KL9vvgF2H9yJjrTedomz+4+pEB55smxLbe
	bXxjf2w6v/blb8pqFcgorCt3XxpOv5uefftfSsN8tyO/UdiPvt2r6SZf4knK
	NmzL46beHRcJEoZvvpnh56tvXsOiXLy/+fC4MJCrmdY0LezPM/zyjPbqnhXE
	zxFjMYu9IRNMuuuqws4rVx5iiPbfodfTq/nn8xNjptOpdQuyoG5J1uxmQ9+z
	WyMdWoUKj9qtJ34W9snAuz21ZJtsA+mIZJ/ot1iXd76J5FhMF72N4mDJfhTq
	ZN1dTW6i7lq3pln3MD0iKKFlG8es4CWaSL6tqurWLjCzW26IrDQD+SZaZ2P9
	l11o6CPMPLNXZGNILiGt25omosnqKhrsb7BhG7A1u3Vk6Nji0c62dcM7Z3/f
	4uuL+tq6tnXL2zgxoBkNbfzikJ/b2tLHiDGgF3btQFx9yN6R3aybmZKxXnZs
	EtQ/87pM1cBbxK5viEWrpt7az9+fs/vmVfWPb8gj00OuFRoSTUCQW79rydvw
	bEvQhj481FVh8AHmY/IcJnlZzAY0YOkcASZr13gouLlzZQdWkLfk2TZhvSEH
	VZC6LEJL1GtxuoWHKMPy4LwT2zgQhVaj7ZxOWLJityaetpCVpdvhXN/Rlg9x
	ZkS+yAoX5O/MVzCZTV10SxCApK1xBdPCleWBt3ATtvS/2n4AaZ/QaZ5iNsfs
	gox1zRIsW9Iu7YY35yvTVbRlUvRapYTOF5mhEAn3JWy7ra267YLORZORbyNq
	RSGs08mMEpdEt6CfK0gGkWBLOA0fFyHCsfhiYhcOQ+qKviYW+7hswg5HACFI
	8km4wZy///2/EdnBw19/ZRItS0IMbCWZ9XkIGPPrrzNzT2SIh042ORSZJOdE
	F0MnpUFlIFRDtCMC1nvWyaFygBzpUCox/svS74TkZhkaWo7Ug5zVgBz3VBqa
	01VuQTo00EGaqwcodTWz9n2LkUT7gn0B0wgr1guoIY/SRYZaT/Ie97QIrXBH
	SMgtSBnJ3YAdSwdDkgyGvyODsU+AhVleHiCZOChJYw2jI9bD7uuuLGirbddU
	rPiHHe0JMtZVS5LbtS+I4j975R+RKBu5hU+EbMEQ3sFKrRlWggCURDB1kASw
	tzvWJksArmCdbnIEwZxnepEhjQ+Y/HvsQhakl7/+yrZhJFn/iH2wDwwEpnMl
	zZE2MhTJ/3/Wgpf8DZPxlb3xzTZUdVmvD6AZznQgpjZE35PLn65vTiby0368
	4t8/v/vvP73//O4Cv1//MP/wIf8iIwz9cfXTB/0ev/VPnl9dXr77eCEP06f2
	3keX8/95wvs2J1efbt5ffZx/OBHyDllJUZwqW6YZaYCLWcKggObt+Sd79jKT
	+ew1kVn+eHX2HTGY5VuIVFckrfInEZAkabcjKIGFSY7JWu1If8o4wRIELPaV
	haMi4n1PkuvsuqxjdM2BARuZTtrSlgbvSgKqUBNPy/4zln35+jVbn6/sW/Jf
	awo16aAgOZ0HZ3IDw0meOEI895sDu7yR8xbVI3N7ICKQUniyyuy6YTgmtO9l
	2RUcPvgquBLzcSxOlucJed2n2e2SHjF+MhSFkLypg6mt2JjVyETpoiMDBVBM
	rpmV89gWIyu3s//WeaLPoiPJbUNZsjdpfOkJB6o+sWbRx4bsT2F3jlwBbD5p
	0ES+G9g/Vj6ZSAzuqit5obWvfMN42oBmydhBa9g9+dbtsEcyT8TL2G13vaE8
	EbOzIDqS+ESz8G3Lz9FMVS2fzwjCjUzCtWfnal/Mns/ObCSVksmS8p/EnV+S
	J1K705LDNSyzpN/9yPu+Vvgq9iQ7SAzUYfWKrcuQIiSWsMJujWAbz5LsdIT4
	C1GnvNGXs7PZC7vqGjYUumEvZD6yWZs3+4TmVWf+NO/c/K6dw17J9obOHbSc
	Ewwlt0HTv6vWZSBPlxXaDVxwxPxbR6henQ3p1FYsgFmW0FRf1d16I/uSrUSR
	IXo6NL0dllkZaCjihbuemR/qPbm8ZkKa2jMX3jW7DIGvYV2T1kZWcbWZ4AY/
	pSZmvwkUg8R6RdGiZ0x75FAnRKgTZsyJkOZkZtIs7A8cEZ8BFnJlFKvbE0xE
	cyxDPApSwCyKBgDliOXQNGJY4voruyeF29YR6IV4uEQkXfTehcwOxVpL8h/k
	rXEgdT/iT0QHWEsHRFz4DUXzhL8ZjBQ1rMcmkXFJJtEbZkfUPZCHI5KTapKg
	3ah69ALnMnZs5SS2ZI9Gjxh8V9HyNZmQ4bezE2vZx8NZwdqJ9GMrzF02Toh+
	2RGYkSPIPk5oxc/Q+DsvyDiJJYGPdUcWiZAHQqQBrmJyiPGFQSQsCpPIMtd7
	fWLqPCYW8db5d2yZDCXTIoJgvBLFnlPSDZql3sGK1Y0goihpUKzHxpStGoPa
	SIsTZw8zOx95jgegckfGHrhuYnrX8Pb9x4uJ/ZFONbFXO1+R5xJT8VO1gGOa
	ZNGrd4KUiOx9sMnhoEEY7u2lW15ds1EWgDMaBKe5c02byPADOdeDfXfwBO1K
	Yny5htPYbHEis6VdUBy/q2GzZ2AvTFlZegn/hDCMp0Fh5AeApoNa3S7iYP3S
	HGekU8SwrjgmqKD3FWlQKwpAihy2NGFBjj3SSHbQ1y1EDmZknsKnB8EB+Myh
	xQN/ENUhgJxiccmhUMBNp9KoyRVvaEqKLN6Q6L94PgWo6yrskcFL69fEtkfC
	qJGZNkXXDMTymDshUPWPuhPGew+dCXHkf/mmtmoegFkGCAxR0ta7wU4+f2ap
	YHiVQiNB+7QBMjbRiW0IzKY1bVwzAeov1EbLzmnxv8i6iir5G0JqffADfAx9
	MwU7ttruvQfKYT5L9LlVLigO/vb05eTV6Wkm8JPIoQ+efzoDAmISQ4xHuAdB
	zBDu0Pk0VoNZTXFTNgTQPOHMkCFMDgcusvMKrayhMeWMhMnbf/0XJBTeUeCO
	HB9F26UjjpEtxcciH//6v0kE/Re3JVWcSmCVo5eAD4GZma3IYULCRWAiySuY
	UZBfCiVigfeDCCTxWNwZmXqf45Dp8TjE3I9DbIpDAgceHAqmOCt7uomIrGq1
	50ySrElPIeYmGZSA+r88zcxcS5zDviBxuGfoeF9Y9ttX9kDwIUpED+U4mNHe
	iKmwPQIByKw2CD92nI1ixSHP9AtteFvTNiqAf5Nzc4h5IQgSGMuWGjZt0SfX
	1JsrBS2TIeLOc4k6gtZJqmhlwP2cf1DB0kCUXBKnRpAHFFduSbdcO2CJasQg
	/BKGY+YXWR1YBs3vEyPmVSX5CXJ76qWY3ccjA0X8yOqlWqAQ57wu2Cj5wNw6
	tU8+1u+apm6ekobbF/Tn/5C8+FOrWUM7H62QFn8ynz81SUyZhmrMsHmxxLx+
	r7qcHGCn1ZtScGD2Dx6oIljImx9wvPBmYLj6XZBbJ/3rmvsZH91Iyouy1Saw
	y1mcA6AgoS+CoiQ/LZthEkqxGb+LX4SqAMW7GIVhX9l3YkLsJZuQFJeGKNCX
	BaeuGG8cz1wtYbKNHjgsyCTmbQjmGaRqVh4Ay0PTS6+hHJ6USphJoLlqB0k4
	Tv6yG3cS7bGdTbZZjHLmJFszWVZNY8o5rcjpwbGIKSdM1iAHj5OMycRE4uzX
	/awUee5/IsS1lER25jDPNemN1zAh6raocfJhgAKdOUK/FMJxcpGiT/JdlQrh
	0oddK7lZHt4xJGk8hdWEN9lhkleDNUHMnHY0k31K7N0/N94oWUkN94gk5e/b
	KKFFxFdNvSRDk4pXvIwumQSaHt745e14xTJsg1rUFR+Bc3etfusMHia1KOv6
	ttuRoZIo31E0TuG61xhXF0r0FeYcP9j4SGYUI6bZOY03CBj7OIcWuqS46Wj1
	xZUAcofeOz5GaiS0/GolKJYUg4H7bUDmaXWcWAn7soyZsYwxw4+cnPFY5fcS
	4e3amDOrZuvhfkPcJq90VINZ0O44GlPZmgyCd1qpaVkjjkr+TIMx2Ypkc4u+
	FKUnwbd110aJGvu0AG15FdYEZTmBdQSvZe90NntlElrLKdBfENFLooccPz2k
	tKel+iefZ5THZseI2VmHuyTCmRBsklkjW8vSgs/TKFTOZhIP5Ada0JTZF1kF
	JRUs4dqhx3RZ7iCEJpKAxdVBl+51WRBDlApYIKWXXH3pJScXWkNRSIEYt8+h
	9UsMvQb5VGYyUeOCjC++XpVuDe4gsIZbDNVw/SG/A5G+CORcGNxydl+JJFwH
	k4i+RqODRJ7+6PcODQHJpYHkEHgqs09iAJ6vfIOAGJLzWMWSWEw/0op/I7c0
	MQjjOaiR6Gip4cnYExYetov+hH8AKdna0+RibXqDUGBOYSsbqmM6iqBuGBrN
	xUTFoR9nuFDRyskvIoptBBzsAx0dMzM4fPSsTtbNmiCeDhuEBMA5G7WjLROW
	/DRyCocRjpNQhmkugrbnDCzruySCKPrmAYiq62Iy4KUm9YbykI/NjB4E+219
	TKyJ2lek9AjDOY3FSyTX/oizGCqkGZqg37C0LPcLv1ahzuw1g4HqtsbmijMe
	4i6QDhfqLg7jTTDe0Iw3WOa/oCMFTlN5F1IGPUQ1QigWcprfnp2CcS9OzUOW
	yBY0ULRc3By4O/WDkgOPgpWMFn7kKL4YUEsOSc6mbni8W9CG6DSFSDw7RMmL
	IwcvATYfC4rCvKV4kLObHA71mSuuvx0z/DyRL8ndjjYygDS9dYRxNCJVRA2U
	RoioGpMp2hyXVHFqzfn2YpWQj9Aw1my1XJHyI6kYO7JWKSZS14LUyzgmsk9Q
	3dHUigacMWWBppKo+PXXp+qY87wC9JAb56aGoX8UcDsiCKQnVIir4SWUyfcr
	vZJaEz9d1UPpkipRn4NI7RqFNIuN0KFOfpwjx1cm1pd+7XKBnT7PCnffVCbh
	65PISNFLSCuZTtZBc1xRZ6J89HGqwQwqBNA9Vh3AGLOTKGos2fcMykP1nozg
	9xAkJWQCeJ/sW0WSIZVFUV5yr8lRJCt1/xwm25Ex6lHs1bGXK8KK29Na8QPD
	LfHSyACKzPovAfVZkrotEEPGmHKO0nEtSrTeob1hu0sEzvCG5mJElK36b4Sq
	AjOyTzEiTn2qJMEC7G+Q9HxEKWYMho4Q2zwG8LB+anniA/pqTWKUw45VyyhM
	20WSaRQbOISNqKmk/FB2WKqiWvRO2NGEmKMqycy+6Gvg70cwAW2Fg0jwficB
	xJztpBSb5QRSQEVVJHA4Jp3Pg1w0ixbHtKkFJxcqUoqaE/xIReek+Ewz4CxT
	wBsYDuzDPhib/jLJYE8TeWwkFvDxpV+piidcy8IQwe4+NhfShYZTFGi4ibLq
	IL7jNNqou8uZskYVNWfkZRscQkcO3O9cE8DsnuqkU2V9wJqyR0BQ9HEoiuBM
	Ms8nbSnExlyW23v1AiV6Z5G3CetNSf+kDEmHQRWatolVkRUZ4z5yPnVYwjuz
	QcORstmSFIAJ1R1oVCiyR63M1gtJseQq5L2ofiDps+zN07kNJyVqKexAajk/
	on02aAyKDAbVBPktqlvc0aTVu5UkhA3miCQUpZiCIR9aQkxVIMuUC1HcL5cj
	zYlkl+Evc3VWU+qjlpVh49LKCkuI+tckK9BDyQRPDFsHXoE9poP6TDjBP4xt
	6atC3d4dAmrOkKLLqF4ZbS+iuT/U1bqfGvvcdoj+EXsiaT9BXKbIY8UZ1gop
	cCSH4oEEbMsoGwXFpR/5PYgtUX8r3UD05KYji6p1bFE+uOlV+EL0/cNjFaXU
	7aYFF6ItdiLcbyB25JZqJJW0DWhD9pAhR4PGRFSSeP0OJZW2qwQ0RyR2WB0J
	SAuQiYE8haYZ3ldLNH0QE1QaGGSre1wmi7eVlmEBZzsSdiCDv4EuNG19J80e
	o5wy2wuOQe5HoQobxBX5LxsSzdReNlKfyJLDtb09ivTS+MEWssdvBH348ClE
	Zh+iQC1lImBlSs6yaC2Uc2v6jdnVuw6Ney3aKTWv5NrU81mk5kUKGND3aRMc
	530MznEXlnqKec4zcjNqJU55VXZ0BgYYYzotNf8Wa5PbStQcHAe+sIOV5HmT
	1mvyqZDoTeLD7EmGRgJOWy1EhJ5NFAErEBBBi7eaKeB9psqvxmOsr+NGvaNd
	Qig9LhWQ5CYh6cUhgfyDbAhzAo2V7A+QSYmBfXVaVUMOSQTAPJyjWt5EEmwy
	zy5I/A97V7N1pTC6YizJRkEMNHqVm4GaKXGlx8/nyuBjwbbtY2h0+KFejFhl
	2fb5m8qjijNqbkTWdICgsedO6EvxW+P6FhbIovRZJ1vy0KhzBIY6TDLsEy3P
	D3mTQH4G6UIy4ZVAmwfMMn13VebRHxAop/61F6evUJBKHR3fTWRjPRSqatMn
	6lfgP8VwXeuHkebwGAO/cmwnWcykKT51i7hRHb1PrYpDg/1b0XfE2M/EfOnK
	SDiSA74WsHWsdmGcV5qYDe4RNJooYlRLC/wNdeeUv+OEK9tntfa086WkItAM
	N3b+GpMnaUyFTTrA1+3IczFK3W67Slpqpek3SDkR/Tx7Ai1EzCtReIQDrLmy
	RTEeJZrHxDxyIfIOnSMlx8awYzRy2pc51KqgzWYXCuRu0OCSIzKBseZoErRP
	7bBDF2NGdoY8I2e90Z+7qxlsksFUIkXDLKzqVMF0vY6yIZVkPPwx4mmY+wa1
	JUnYG20a40gImiThBQUrahyl/FVXdTPoKYvJq6Owu1eJ6KtqaI9Jaq8FYvai
	ntujITWjDtgHledcc04guJLgSEohjCvqHY2RtNmwwYrXkGGGRkG87pWibcpI
	ECZWYazl9gMFKxR0iNOJEDb0hR+MmhZGG5mczIAhyhDpBrr9mGjPArRx6Hcw
	edwgVuCuiuwPGQhDdnstkNxIEFCAXLhJ9aBTXJVrSSq1tZNYSXZL+v9Rf+N4
	0ZWQcjniUDrMrmtAPNEsnTEp5PP/8/ybvm3ijAvpXKCFFRLZbfzX5HsgR5yq
	ZgyaAlXVenIUuFuQk+uMu0etOsJrwuf5Hs3X0Z5cuEOa4kNY+RMiAZQeXdW4
	iUMxqbU/q7S73c41UkZBTy1H/n2LlXY1SbJ9GJ9p3ymXXAlUSzHaow5N528M
	AFUKhdWnaWgTh7Vw/hudKJuDKAOffsuhy4LQSsW3H1EI1rJHpStJUMgBf5Ui
	EY36fFmKGvFxHMdzmH9ARxgi/J5UpfcTLPjIGaXcBCARqbLRp7l2LTmPijyk
	RYWBRGyBhBUrXVY06b2hg5vjSQEzV3B0PxgbYqIUU0mVVZFOn/4G7kNbkBc7
	oWn6lLwFcBGG+WJwQYOwCodZk9wkN8inkDPLgGE8+TDpDtBExyXBgQXcuVZT
	+Y4EikN0iZxkP4wTjmEv0y+gAe84e6fF6skwfuGetTpKBT1leyE6cLBodA6r
	R7Ge1IwIk93pitib/Z6kFVYAIGvSI/f+IhWEiPa0m4LVaIRDhkOkv3W3kqw0
	Q+rUqxVJIAGUYTQ6uJUmjRBFzuWukX8ZEzt2C1knavVBnrr5cJHyvam/WymW
	umE0uMgP8VWUPNlEUJZ8HFq1qhSuabsE0RQ8oz0RabSpj7Yo7YWPpLdkZ+xj
	tRGFlSB1oeTqbEZjobrTC5t22KqBYkCM9TKw/mkWnmNZk9ODK+mmd+hP1haS
	z+dXF+8GN6g0lyNySMKeTUiUi3NYktbBRVGYn2YExEC8ZDg5NONexoZbSrRb
	M++QzVFok7LB8hDc0YxvRka5PJIaghGO8GWGcSH/SUS2QENOIsl05dslsXD9
	lBNh5NBSGkewuU4vesZNLkhJQJmPRjnZoBt2i9GFwqY+xIOK1I6Li3YcTR25
	tXXHlWp9ODR2XInj7tScQlKHwHkp3LH4ng6dfC4MWiovN939jesGhtE2FkFz
	YOGXnNquNXi4FwCmCzHD7MF1kHtl3q5rTQI8uI+Z8ozDRhwIM+mZOhijxxnU
	BeQeluS/RgLJt3DUmfRdjCA3XrNgCf0EUgO96wnTlyzvg+ssuWGFQvZS5jFJ
	u/QCyUCHsmiwLIsn3Xu1FZUwZKLJMywrCSmVhr1cmXHq8gXgkarlOIBH0IYL
	WaQLcZPBQupJYk/k1wQ8t9DxJXKmKbDk5eUj4ore4u87rZKMvX938z1vEgis
	z1RjjxODmn85KiumAnxvalj4mBPg9We/ggTTo22K20AK9YipaQrQGhaC81Op
	ci7Of9TDlu7oaFcLRn0dh8WhXQ1KFFpk285MWr+/AYDcCDIpnKyunRauuT14
	i24BJM/UzeWIP3WbLvVGoV4tNdwqzDFGriLwNtJjCMoez+PxjS1RZ8WzuaFB
	ro2vRPmRetzVsF8iAWR4gmc9NZmQIB9Tj3uxmHwwi067CRW68Q2/ZHF7shlO
	LqR1s4CnuLoL0pN2fTXX9olWor4Uo3G5ih49ZjEIjSIPx9nZ47k5DqmOStWQ
	Co4vlaI2mPY/bH9LpcmHBROSFUcgwVz3rQCp0JYv1yWTgpnBGPUPodKLjaB5
	AZ00WrylbVKglWOhBEuRm1rnmy9oHU0VEHVBXQOOkT5LQJRdg9aL+y3uveQG
	XblH0Uv9gBl2OmS469QVJbs4aEjLKZ377Vo5jQwxvleJFZc06NzgApx4Fr1l
	K9UuGcjaKGiGrG7dLUo/oCed7K1aNe1F7tFYh5s4qVKgnmrof7UYKG0hS3Ie
	PvKFW5ZBZHPYU8BYGekbIoEEFsWNR6ldci4kp0hlIrmgy8F8WK+5mlf5vVEw
	sEIqXE2haPny4dXfrh00bJPwmnVdF1OSGrhdaXDIBEbRk6m4dclx9mXtQRWu
	v5IW2KKRWqnu9pkM5OL5+8CAx4kH67N644JzKqX3UiCq8pgQEFQL5dGScupY
	myQPZTh2QfCBm2acr+lHcwZL7DmXjPMVkVqCheSVyR0vSQPEzOSL32UOGXDH
	ukj3QDVXVqcIlNNGM9LqercbdcmNz54T0KPmsFErhxmRQYW6vy0ygjaAGqNT
	szvVLrEK4na/11erpGCQNsZswkJq1twuGtPlIFF7sbgph8bNIHptm7VY+/yH
	N1QGt//FLjOhQ6s1+XQBTGpkfU/UiizugkIszkSJ0EGBBHPqhRyxy3SIt+Rr
	9q7RtwOcO7LpfPqPwDlPzj/OL99Jx/sFftVLxd9++91zClE0mWq2tJty+AIC
	5oA2OvC5U1+6JF+1zz1iCfJrXqLgwRsBIrnMJkQpMKE+kINvIBd53UBODgPe
	BM543Qv5cQvv/ccLaaFyhBJiK+vI+wEkts4JCPv+091LO5d40T6ZP03JI77Q
	wITQGj8EWG9jYf7Ejcj5Dbk/xPUgPXV72HFdyvS1T90RTzpqisud3FUK+XMW
	L6YGynE2nFsAhlVrMQkLWjvTO6mEuhUz9MbQ+q0f6uhEY0IRIlbtUSCQSgt8
	nrqEE50Pgg9N4iDMFKId8dzksNsuigbltoPRRfojt4tAKJO887DRX4yOg/Yu
	uU7IXHk9+252Kh2/2QqgykQWjnYwv3WEg77mhnJ9WUkyR0ReOIbnp2dnYpgG
	6XoTtzW4Wkh9s8eIGUzigVLqzOm9FoN+MjhUFWk5plzloQUD+n6iSpicBIIB
	+0I06RT45pfIXWs9Gk0j5C5Ct814ZNVVSwGlqESx0Oz7dt6kFUSfs+fcH1Jy
	P9pdcAJ/9N6lvOFOeD71lQjG6MO2LaXJfOu+6Avx6CNit97lZLK7lP3NVdH0
	1p6+U0UFS4iNIp66MVXwAXQaYiTpVdio8kgbahNEylM7/z2XrNkPrmH3UIR2
	jAupuAokIEn2XfgtGl2LTpPyb0x6Q9MtjZ7mcgK68SER9TLOQv3MV88iQ+pn
	8mycbdpt+dUgLjZygZVkT5oKhr39SGEgdU1LIFoaXmvNVNKeYzPsvMH+sZEA
	8Jg7t/U6CntIeUsVvx/sH3wrnOnfCnd9glR3fktdukinHT5WCqO+kPTnKLma
	jMdi0GY2fkNU4PLY1qeOes4Sij6ExuQTqD9I4asoF9cg9yhF7fhNCq4QMc63
	oBMSVXc+MKBiSPjdkPcyFJzR5j6a4TVnaS0QnAwps/WwuGzdIqXIpCZ9D2jl
	9oecB5VbUKD31U7u/Cq5OejoQ/j7uZVBRG+ORvRYguet7/c69rYgR49mADVo
	/DSw8KXcSd8Vi1btPk3sYBOQKeGCReSaFhRnQRvRyjzH/6GSFwYJwwf6nA1z
	vqTrMoRVgKW7gTABkKm3/EXkzMUxe+WNA17B88KPgip9ZQdNJgxPcn4kMaU1
	0nzhAohc8oK6AyQTthqrccky7SiBaE0IeynVSek28RGJpZrrg0Z5w9zj/AcK
	5NyUtFDwMGyaY6lEE0AgQ8sd7YIapB1TrpCnt/k97Ca8118W00hGEKkiEnI/
	EEK2Mmxq6ZknQl2/OzeaYh7mQYSp92/B53wXZ4FaHpjaiUxuTqj7dtrAfVmh
	wI6kVX+mr3DN1eLcMiPFTt6nSd10pP5VQY5O8sCEP4g1OwpYA1+xvPlwPYek
	Xlzbz5/jsCdNYFvH4b9i4490UgzGzxf9RZIbDhEi+Rq0+6W3gqRr5tgTCGl+
	s1LC5ZHhW3PY5WKK3O4+iJqPvoNIUl7i7LvY93MGfe8awTu+j5UaWnDNne9v
	Exf3YyTS3wjRIEnqPSiiFf1b2yRW4/anYRPEyEVBj5h6HKHcer8zGewj3L3X
	hhKakdnnSdfIazl+scRNajnUqDZBh9xcUMrr+vSqndSTSBoC419N5qarQpkw
	/IIeJg16nGaEpXJ/10QnkVs+3DFZbxeh8kJ/Dd0u+ncHWvS6H+Vwbh3I6bs+
	j6SxRrLg+c0HRgVPio3AjjP7Vtox+31pZhQ1EbdzS25Y4zIDIma34Cot7sIW
	akAIykZtzKERmDaXacOKpYGwu75RAzjh738fvKcUnl29CnBQhZdHwrxtSMPG
	732ccOxGyDiFV1EStWL/B8VO8UmMVRJAVruuFz44EjQpgKCZJnb4yj7OhkzJ
	YPaWK/V5iKsyUo2b3uX3li4H7y2laM91AGTi8qGqmoHJNJ6Zn/XyxFDn+je7
	cNlBUkr2riur3DScFRVveuacFT80FFdfCZSQ9gO2VMjCymt7+Bi5MJrNJLJK
	3FCY3EXqw8wVbKLo4IwjnVJ3Tx6PeIMEmO12cn2fY+DckqyxODtCCm0kAce5
	NR6ntWYzL/nakURBE3s+zyuAg4MKYYIJoNjDhnT2UZ+acOeWx1zUUbqTCGlF
	s+8f2qMLlSeRFnie9+P85rjbkzvYfXjZl2CQQVvlnO0g84y5CkTxOvf7+cf5
	scn1JWok0zxifJubn5wvYSkpGpHbHinqVcicWluhp7eExINDXrvZcZZ9Yj/X
	BDxb+67YIs02sTc1EeJ7cn6biXlbL+wPjlSb3MENGciDs38O1daHib0kUQr2
	x7JGEujP3LBxSRDZdZP8zmZ+W/PE/BnJsM81sfSyu0XQdk1kbSg2Jpt44fBm
	ousabwz65Ag6/SV8CaSVn125sj/7hVx9M/zVz2Rp05vXxMCjdkZ84o5o74uF
	oHke/EO9WqE/Ojes8g0oeTlZdZtL9STt+laNHoB/InmmSE1QOOMz0O1Qd4LD
	NIe/qnGfHc9uPZ7Mr0N6/+76T4M9rpBKMLLTN5bogF1dkLCVYT+xb331i9uS
	mv7oio4Ied1xJPkjuY9NBQJdhuYXZ378v/+5KT2UWtzyvHBbmopUbSbvRsXR
	zf8DFAIysqJeAAA=
	</rfc>		</rfc>
End of changes. 86 change blocks.
	624 lines changed or deleted		843 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/