Diff: rfc9664.original.xml

	rfc9664.original.xml	rfc9664.xml
	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>

	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<rfc category="std" submissionType="IETF" docName="draft-ietf-dnssd-update-lease
	-08" ipr="trust200902"
	xmlns:xi="http://www.w3.org/2001/XInclude" version="3"
	scripts="Common,Latin" sortRefs="false" consensus="true"
	symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
	<front>
	<title abbrev='Dynamic DNS Update Leases'>
	An EDNS(0) option to negotiate Leases on DNS Updates
	</title>


	<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>	<!DOCTYPE rfc [
		<!ENTITY nbsp " ">
		<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
		]>

		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="I
		ETF" docName="draft-ietf-dnssd-update-lease-latest" number="9664" updates="" obs
		oletes="" ipr="trust200902" version="3" sortRefs="false" consensus="true" symRef
		s="true" tocDepth="3" tocInclude="true" xml:lang="en">

		<front>
		<title abbrev='DNS Update Lease'>An EDNS(0) Option to Negotiate Leases on DN
		S Updates</title>
		<seriesInfo name="RFC" value="9664"/>
		<author initials='S.' surname='Cheshire' fullname='Stuart Cheshire'>
	<organization>Apple Inc.</organization>	<organization>Apple Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street>One Apple Park Way</street>	<street>One Apple Park Way</street>
	<city>Cupertino</city>	<city>Cupertino</city>

	<region>California</region>	<region>CA</region>
	<code>95014</code>	<code>95014</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<phone>+1 408 974 3207</phone>	<phone>+1 408 974 3207</phone>
	<email>cheshire@apple.com</email>	<email>cheshire@apple.com</email>
	</address>	</address>
	</author>	</author>


	<author initials="T" surname="Lemon" fullname="Ted Lemon">	<author initials="T." surname="Lemon" fullname="Ted Lemon">
	<organization>Apple Inc</organization>	<organization>Apple Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street>P.O. Box 958</street>	<street>P.O. Box 958</street>
	<city>Brattleboro</city>	<city>Brattleboro</city>

	<region>Vermont</region>	<region>VT</region>
	<country>United States of America</country>	<country>United States of America</country>
	<code>05302</code>	<code>05302</code>
	</postal>	</postal>
	<email>mellon@fugue.com</email>	<email>mellon@fugue.com</email>
	</address>	</address>
	</author>	</author>


	<date>2023-07-07</date>	<date month="October" year="2024"/>
	<area>Internet</area>	<area>INT</area>
	<workgroup>Internet Engineering Task Force</workgroup>	<workgroup>dnssd</workgroup>
	<keyword>DNS Update</keyword>	<keyword>DNS Update</keyword>
	<abstract>	<abstract>

	<t>This document describes an EDNS(0) option that can be used by DNS Updat	<t>This document describes an EDNS(0) option that can be used between DNS
	e requestors and	Update Requesters and authoritative DNS servers to include a lifetime (lea
	DNS servers to include a lease lifetime in a DNS Update or response, allow	se duration) in a DNS
	ing a server to garbage collect stale	Update or DNS Update Response, allowing a server to garbage collect stale
	resource records that have been added by DNS Updates</t>	Resource Records
		that have been added by DNS Updates if they are not renewed.</t>
	</abstract>	</abstract>

	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	The latest revision of this draft can be found at <eref target="https://
	dnssd-wg.github.io/draft-ietf-dnssd-update-lease/draft-ietf-dnssd-update-lease.h
	tml"/>.
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	DNSSD Working Group mailing list (<eref target="mailto:dnssd@ietf.org"/>
	),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/dnssd/"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/dnssd/"
	/>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease"
	/>.</t>
	</note>
	</front>	</front>

	<middle>	<middle>

	<section>	<section>
	<name>Introduction</name>	<name>Introduction</name>

	<t>Dynamic DNS Update <xref target="RFC2136"/> allows for a mapping from a	<t>Dynamic Update in the Domain Name System (DNS Update) <xref
	persistent	target="RFC2136"/> allows for a mapping from a persistent hostname to an
	hostname to a dynamic IP address. This capability is particularly	IP address that changes over time. This capability is particularly
	beneficial to mobile hosts, whose IP address may frequently change	beneficial to mobile hosts, whose IP addresses may frequently change
	with location. However, the mobile nature of such hosts often means	with location. However, the mobile nature of such hosts often means that
	that dynamically updated resource records are not properly	Resource Records (RRs) added using DNS Update are not properly
	deleted. Consider, for instance, a mobile user who publishes address	deleted. For instance, consider a mobile user who publishes address RRs
	records via dynamic update. If this user moves	via DNS Update. If this user moves their laptop out of range of the
	their laptop out of range of the Wi-Fi access point,	Wi-Fi access point, the address RR containing stale information may
	the address record containing stale information	remain on the authoritative DNS server indefinitely. Thus, an extension
	may remain on the server indefinitely.	to DNS Update is required to tell the server to automatically delete RRs
	An extension to Dynamic Update is	after a period of time if they are not refreshed.</t>
	thus required to tell the server to automatically delete resource
	records if they are not refreshed after a period of time.</t>
	</section>	</section>

	<section>	<section>


	<name>Conventions and Terminology Used in this Document</name>	<name>Conventions and Terminology Used in This Document</name>
	<t>	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOU	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	LD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"MAY", and "OPTIONAL" in this document are to be interpreted as described	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	in BCP 14 <xref target="RFC2119"/>	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	<xref target="RFC8174"/> when, and only when, they appear in all capital	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	s, as shown here.	be interpreted as
	</t>	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>

	<section>	<section>

	<name>Abbreviations</name>	<name>Terminology</name>
	<dl>	<dl>

	<dt>DNS-SD</dt><dd>DNS-based service discovery <xref target="RFC6763"/>	<dt>DNS-SD:</dt><dd>DNS-based Service Discovery <xref target="RFC6763"/
	</dd>	></dd>
	<dt>EDNS(0)</dt><dd>Extension Mechanisms for DNS, version 0 <xref targe	<dt>EDNS(0):</dt><dd>Extension Mechanisms for DNS <xref target="RFC6891
	t="RFC6891"/></dd>	"/></dd>
		<dt>Update Lease option:</dt><dd>Update Lease EDNS(0) option</dd>
		<dt>Lease:</dt><dd>An agreement by an authoritative DNS server to conti
		nue to publish a record from the time of registration
		until the lease duration has elapsed and then stop publishing it</dd>
		<dt>Lease Duration:</dt><dd>The time between the start and end of a lea
		se</dd>
		<dt>Lease Update Request:</dt><dd>DNS Update Request containing an Upd
		ate Lease option</dd>
		<dt>Lease Update Response:</dt><dd>DNS Update Response containing an U
		pdate Lease option</dd>
		<dt>RR:</dt><dd>Resource Record</dd>
		<dt>Registration Request:</dt><dd>A Lease Update Request that is constr
		ucted with the purpose of adding new
		information that is not thought to already be present on the authoritat
		ive DNS server</dd>
		<dt>Registration:</dt><dd>The result of a successful Registration Reque
		st</dd>
		<dt>Refresh Request:</dt><dd>A Lease Update Request that extends the le
		ase duration on an existing Registration</dd>
		<dt>Refresh:</dt><dd>The result of a successful Refresh Request</dd>
	</dl>	</dl>
	</section>	</section>
	</section>	</section>

	<section>	<section>
	<name>Mechanisms</name>	<name>Mechanisms</name>

	<t>The EDNS(0) Update Lease option is included in a standard DNS Update me ssage <xref	<t>The Update Lease option is included in a standard DNS Update Request <x ref
	target="RFC2136"/> within an EDNS(0) OPT pseudo-RR <xref target="RFC6891"/ >.</t>	target="RFC2136"/> within an EDNS(0) OPT pseudo-RR <xref target="RFC6891"/ >.</t>
	</section>	</section>

	<section anchor="update">	<section anchor="update">

	<name>Update Message Format</name>	<name>Lease Update Request and Response Format</name>
	<t>	<t>

	Dynamic DNS Update Leases Requests and Responses are formatted as standard	Lease Update Requests and Responses are formatted as standard DNS
	DNS Dynamic	Update messages <xref target="RFC2136"/>. Such messages <bcp14>MUST</bcp14
	Update messages <xref target="RFC2136"/>. This update MUST include the EDN	> include the EDNS(0) OPT RR
	S(0) OPT RR, as	<xref target="RFC6891"/>. This OPT RR <bcp14>MUST</bcp14> include an EDNS
	described in <xref target="RFC6891"/>. This OPT RR MUST include an EDNS(0	(0) Option as shown
	) Option as shown
	below.</t>	below.</t>

	<t>The Update Lease EDNS(0) option is formatted as follows:</t>	<t>The Update Lease EDNS(0) option is formatted as follows:</t>


	<figure align="center" anchor="lease_opt" suppress-title="true"><artwork align="	<table anchor="lease_opt">
	center"><![CDATA[	<name></name>
	Field Name Field Type Description	<thead>
	OPTION-CODE u_int16_t UPDATE-LEASE (2)	<tr>
	OPTION-LENGTH u_int16_t 4 or 8	<th>Field Name</th>
	LEASE u_int32_t desired lease (request) or	<th>Field Type</th>
	granted lease (response), in seconds	<th>Description</th>
	KEY-LEASE u_int32_t optional desired (or granted)	</tr>
	lease for KEY records, in seconds	</thead>
	]]></artwork></figure>	<tbody>
		<tr>
		<td>OPTION-CODE</td>
		<td>u_int16_t</td>


	<t>Update Requests contain, in the LEASE field of the OPT RDATA, an	<td>UPDATE-LEASE (2)</td>
	unsigned 32-bit integer indicating the lease lifetime, in seconds, desired	</tr>
	by the requestor, represented in network (big-endian) byte order.	<tr>
	In Update Responses, this field contains the actual	<td>OPTION-LENGTH</td>
	lease granted by the server. The lease granted by the	<td>u_int16_t</td>
		<td>4 (LEASE) or 8 (LEASE + KEY-LEASE)</td>
		</tr>
		<tr>
		<td>LEASE</td>
		<td>u_int32_t</td>
		<td>desired lease duration (Lease Update Request) or granted lease duratio
		n (Lease Update response), in seconds</td>
		</tr>
		<tr>
		<td>KEY-LEASE</td>
		<td>u_int32_t</td>
		<td>optional desired (or granted) lease duration for KEY RRs, in seconds</
		td>
		</tr>
		</tbody>
		</table>

		<t>Lease Update Requests contain, in the LEASE field of the OPT RDATA, an
		unsigned 32-bit integer indicating the lease duration in seconds, desired
		by the Requester, represented in network (big-endian) byte order.
		In Lease Update Responses, this field contains the actual
		lease duration granted by the authoritative DNS server. The lease duration
		s granted by the
	server may be less than, greater than, or equal to the value	server may be less than, greater than, or equal to the value

	requested by the requestor.</t>	requested by the Requester.</t>


	<t>There are two variants of the EDNS(0) UPDATE-LEASE option,	<t>There are two variants of the Update Lease option:
	the basic (4-byte) variant and the extended (8-byte) variant.</t>	The 4-byte variant and the 8-byte variant.</t>


	<t>In the basic (4-byte) variant, the LEASE indicated in the	<t>In the 4-byte variant, the LEASE indicated in the
	Update Lease option applies to all resource records in the Update section.	Update Lease option applies to all RRs in the Update section.</t>
	</t>


	<t>In the extended (8-byte) variant, the Update Lease communicates two lea	<t>In the 8-byte variant, the Update Lease communicates two lease duration
	se lifetimes.	s.
	The LEASE indicated in the Update Lease option applies to all resource rec	The LEASE indicated in the Update Lease option applies to all RRs in the
	ords in the	Update section <em>except</em> for KEY RRs. The KEY-LEASE indicated in th
	Update section except for KEY records. The KEY-LEASE indicated in the U	e Update Lease
	pdate Lease	option applies to KEY RRs in the Update section.</t>
	option applies to KEY records in the Update section.</t>


	<t>The reason the KEY record can be given a special lease time is that thi	<t>More information about how the two variants are used is given in
	s record is used	<xref target="server-behavior" format="default"/>.</t>
	in the DNS-SD Service Registration Protocol <xref target="I-D.ietf-dnssd-s
	rp"/> to reserve
	a name (or names) when the service is not present.</t>


	<t>In the case of a KEY record and some other record, obviously the KEY LE	<t>
	ASE applies to	KEY RRs are given a special lease duration because these RRs are used
	the key, and the LEASE applies to the other record. If more than one recor	in the DNS-SD Service Registration Protocol <xref target="RFC9665"/> to r
	d that is not	eserve
	a KEY record is added by the update, the LEASE (not the KEY LEASE) is appl	a name (or names) when the service is not present.
	ied to all such	</t>
	records. Records that are removed are permanently removed.</t>
		<t>In the case of a KEY RR and some other RR, obviously the KEY lease dura
		tion applies to
		the KEY RR, and the lease duration applies to the other RR. If more than o
		ne RR that is not
		a KEY RR is added by the Lease Update Request, the lease duration (not the
		KEY lease duration) is applied to all such
		RRs. RRs that are removed are permanently removed.</t>

	<section anchor="update-refresh">	<section anchor="update-refresh">

	<name>Types of DNS Update Request messages</name>	<name>Types of Lease Update Requests</name>
	<t>This document describes two types of updates: Registrations and Refres	<t>This document describes two types of Lease Update Requests: Registrati
	hes. A	ons and
	Registration is a DNS Update Request that is intended to add information	Refreshes. A Registration Request is a Lease Update Request that is inten
	not already	ded to
	present on the DNS server. A Refresh is intended simply to renew the leas	add information not already present on the authoritative DNS server. A Re
	e on a previous	fresh Request is
	Registration without changing anything. Both messages are DNS Update mess	intended simply to renew the lease on a previous Registration without
	ages, so the	changing anything. Registrations and Refreshes are both Lease Update Requ
	term "DNS Update message" is to specify behavior that is the same for bot	ests, so the term
	h types of	"Lease Update Request" is to specify behavior that is the same for both
	DNS Update message.</t>	types of DNS Update.</t>


	<t>In some cases it may be necessary to add new information without remov	<t>In some cases, it may be necessary to add new information without
	ing old information.	removing old information. For the purpose of this document, such
	For the purpose of this document, such messages are referred to as Regist	Lease Update Requests are Registrations, although in effect, they
	rations, although	may also refresh whatever information is unchanged from a previous
	in effect they may also refresh whatever information is unchanged from a	registration.</t>
	previous registration.</t>
	</section>	</section>


	<section anchor="requestor">	<section anchor="requester">
	<name>Requestor Behavior</name>	<name>Requester Behavior</name>
	<t>DNS Update requestors MUST send an Update Lease option with any DNS Up	<t>DNS Update Requesters <bcp14>MUST</bcp14> send an Update Lease
	date that is	option with any DNS Update that updates RRs that are not intended to be p
	not intended to be present indefinitely. The Update Lease option SHOULD s	resent
	pecify a time	indefinitely. The Update Lease option <bcp14>SHOULD</bcp14> specify a
	interval that is no shorter than 1800 seconds (30 minutes). Requestors MA	lease duration that is no shorter than 1800 seconds (30
	Y specify a	minutes). Requesters <bcp14>MAY</bcp14> specify a shorter lease duration
	shorter lease if they anticipate that the records being updated will chan	if
	ge sooner than	they anticipate that the RRs being updated will change more frequently th
	30 minutes. Requestors that expect the updated records to be relatively	an
	static SHOULD	every 30 minutes. Requesters that expect the updated RRs to be
	request appropriately longer leases.</t>	relatively static <bcp14>SHOULD</bcp14> request appropriately longer
		lease durations.</t>


	<t>If the DNS response received by the requestor does not include an Upda	<t>If the DNS Response received by the Requester does not include an
	te Lease option,	Update Lease option, this is an indication that the authoritative DNS ser
	this is an indication that the DNS server does not support the Update Lea	ver does
	se option. The	not support the Update Lease option. In this case, the Requester
	requestor SHOULD in this case continue sending Refresh messages (see belo	<bcp14>SHOULD</bcp14> continue sending Refresh Requests (see below) as
	w) as if the	if the server had returned an identical Update Lease option in its
	server had returned an identical update lease option in its response.</t>	Response.</t>


	<t>If the DNS response does include an Update Lease option, the requestor	<t>If the DNS Response does include an Update Lease option, the
	MUST use the	Requester <bcp14>MUST</bcp14> use the durations returned in this
	interval(s) returned in this option when determining when to send Refresh	option when determining when to send Refresh Requests. This is true
	messages. This	both if the durations returned by the server are shorter and if they
	is true both if the interval(s) returned by the server are shorter and if	are longer.</t>
	they are
	longer.</t>


	<t>When sending a Registration, the requestor MUST delay the initial tran	<t>When sending a Registration Request, the Requester <bcp14>MUST</bcp14>
	smission by a	delay the initial transmission by a random amount of time across the
	random amount of time across the range of 0-3000 milliseconds, with a gra	range of 0-3000 milliseconds, with a granularity of no more than 10
	nularity of no	milliseconds. This prevents synchronization of multiple devices of the
	more than 10 milliseconds. This prevents synchronization of multiple devi	same type at a site upon recovery from a power failure. This
	ces of the same	requirement applies only to the initial Registration Request on startup;
	type at a site upon recovery from a power failure. This requirement appli	since
	es only to the	Refresh Requests include a random factor as well, any synchronization tha
	initial Registration on startup: since Refreshes include a random factor	t
	as well, any	occurs after such an event should quickly randomize.</t>
	synchronization that occurs after such an event should quickly randomize.
	</t>


	<t>Note: the requirement for 10ms granularity is a scheduling requirement	<aside>
	intended to	<t>The 10 ms granularity is a scheduling requirement intended to
	result in an even spread of requests, so that every request doesn't come	result in an even spread of Requests so that every Request doesn't come
	an exact number	an exact number
	of seconds after startup. This requirement should not be construed as req	of seconds after startup. This requirement should not be construed as r
	uiring anything	equiring anything
	of the link layer on which the packet is transmitted: the link layer may	of the link layer on which the packet is transmitted: the link layer ma
	well impose its	y well impose its
	own constraints on the timing at which a message is sent, and this docume	own constraints on the timing at which a message is sent, and this docu
	nt does not	ment does not
	claim to override such constraints.</t>	claim to override such constraints.</t>
		</aside>

		<aside>
		<t>The use of a 3000 ms (3-second) random delay as opposed to some
		other random delay is to allow for enough time to meaningfully spread t
		he load when
		many devices renew at once, without delaying so long that the delay in
		discovery of
		devices becomes obvious to an end user. A 3-second random delay means t
		hat if there are,
		for example, 100 devices, and the random number generator spread is eve
		n, we would have
		one renewal every 30 ms. In practice, on relatively constrained device
		s acting as Service Registration Protocol (SRP)
		servers, we are seeing the processing time for an SRP registration taki
		ng on the order
		of 7 ms, so this seems reasonable.</t>
		</aside>


	<t>Note: the reason for the 3000ms (three second) random interval as oppo
	sed to some
	other random interval is to allow for enough time to meaningfully spread
	the load when
	many devices renew at once, without delaying so long that the delay in di
	scovery of
	devices becomes obvious to an end user. A 3-second random delay means tha
	t if there are
	for example 100 devices, and the random number generator spread is even,
	we would have
	one renewal every 30ms. In practice, on relatively constrained devices a
	cting as SRP
	servers, we are seeing the processing time for an SRP registration taking
	on the order
	of 7ms, so this seems reasonable.</t>
	</section>	</section>


	<section>	<section anchor="server-behavior">
	<name>Server Behavior</name>	<name>Server Behavior</name>

	<t>DNS Servers implementing the Update Lease option MUST include an Updat
	e Lease option	<t>Authoritative DNS servers implementing the Update Lease option
	in response to any successful DNS Update (RCODE=0) that includes an Updat	<bcp14>MUST</bcp14> include an Update Lease option in response to any
	e Lease option.	successful DNS Update (RCODE=0) that includes an Update Lease option.
	Servers MAY return different lease interval(s) than specified by the requ	Servers <bcp14>MAY</bcp14> return lease durations different from those
	estor, granting	specified by the Requester,
	relatively longer or shorter leases to reduce network traffic due to Refr	granting longer leases to reduce network traffic due to Refreshes
	eshes, or	or shorter leases to reduce the lifetime of stale data.</t>
	reduce stale data, respectively.</t>
	<t>Note that both the 4-byte and 8-byte variant are valid on both client	<t>Although both the 4-byte and 8-byte variants are valid on
	s and servers, but	both requesters and servers, older (pre-standard) requesters and servers
	clients and servers may exist that do not support the newer 8-byte varian	may exist
	t. Therefore,	that support only the 4-byte variant. Therefore, requesters and servers
	clients and servers that do support this variant must account for the pos	that (as required by this specification) support both variants
	sibility that	must account for the possibility that the peer with which they are commu
	the server with which they are communicating does not.</t>	nicating
	<t>A client that receives a 4-byte variant from a server when it sent an	may be an older implementation that supports only the 4-byte variant.</t
	8-byte variant	>
	MUST treat the 4-byte variant as specifying both the lease time and the k
	ey lease time.	<t>A server that receives an 8-byte variant from a requester
	A server that supports the 8-byte variant MUST treat the 4-byte variant a	<bcp14>MUST</bcp14> respond with an 8-byte variant giving the granted lea
	s specifying	se times.</t>
	both the lease time and the key lease time. When a server receives a 4-by
	te variant, it	<t>A server that receives a 4-byte variant from a requester
	MUST respond with a 4-byte variant. In this case the key and the other re	<bcp14>MUST</bcp14> treat the 4-byte variant as
	cords expire at	specifying both the lease duration and the KEY lease duration
	the same time.</t>	and <bcp14>MUST</bcp14> respond with a 4-byte variant.
		In this case, the key and the other RRs expire at the same time.</t>

		<t>A requester that receives a 4-byte variant from a server when it sent
		an 8-byte variant in its request <bcp14>MUST</bcp14> treat the 4-byte var
		iant as
		specifying both the lease duration and the KEY lease duration.</t>

	</section>	</section>
	</section>	</section>

	<section anchor="refresh">	<section anchor="refresh">

	<name>Refresh Messages</name>	<name>Refresh Requests</name>


	<t>A Refresh message is a DNS Update message that is sent to the server af	<t>A Refresh Request is a DNS Update Request that is sent to the server af
	ter an initial	ter an initial
	DNS Update has been sent, in order to prevent the update's records from be	DNS Update has been sent in order to prevent the update's RRs from being g
	ing garbage	arbage
	collected.</t>	collected.</t>

	<section>	<section>

	<name>Refresh Message Format</name>	<name>Refresh Request Format</name>


	<t>Refresh messages are formatted like Dynamic Update Leases Requests an	<t>Refresh Requests are formatted like Update Lease Requests
	d Responses (see	and Update Lease Responses (see <xref target="update" format="default"/>
	<xref target="update"/> "Update Message Format"). The Refresh message is	). The Refresh Request is constructed
	constructed with the assumption that the result of the previous Registra	with the assumption that the previous Registration or
	tion or Refresh is	Refresh is still in effect. In the case that
	still in effect. The Refresh message will, in the case that the records	the RRs added in a previous update were for some reason garbage
	added in a	collected (e.g., because of a server reboot that resulted in loss of sta
	previous update were for some reason garbage collected, result in those	te),
	records being	the Refresh Request will result in those RRs being added again.</t>
	added again.</t>


	<t>The Refresh message SHOULD NOT include any update prerequisites that w	<t>The Refresh Request <bcp14>SHOULD NOT</bcp14> include any DNS Update
	ould fail if	prerequisites that will fail if the Requester's previous Registration
	the requestor's previous Registration or Refresh is still in effect. It a	or Refresh is still in effect. It also <bcp14>SHOULD NOT</bcp14>
	lso SHOULD NOT	include prerequisites that would fail if the RRs affected by the
	include prerequisites that would fail if the records affected by the prev	previous Registration or Refresh are no longer present; that is, the
	ious Registration or	Refresh Request should also work as a Registration Request. There may be
	Refresh are no longer present--that is, the Refresh should also work as a	cases where
	Registration.	this is not possible; in which case, the response from the server can
	There may be cases where this is not possible, in which case the response	be used to determine how to proceed when the Refresh Request fails.</t>
	from
	the server can be used to determine how to proceed when the Refresh fails
	.</t>


	<t>An update message that changes the server state resulting from a previ	<t>A Lease Update Request that changes the authoritative DNS server state
	ous Refresh or	resulting from a previous Refresh or
	Registration is a Registration, not a Refresh.</t>	Registration is a Registration Request, not a Refresh Request.</t>


	<t>The Update Lease option in a Refresh message contains the desired new	<t>The Update Lease option in a Refresh Request contains the desired new
	lease for	lease duration for
	Requests, and the actual granted lease for Responses. The LEASE interval	Requests, and the actual granted lease for Responses. The lease duration
	indicated in the	provided in LEASE in the
	Update Lease option applies to all resource records in the Update section	Update Lease option applies to all RRs in the Update section of the Refre
	of the Refresh	sh
	request, except that if a KEY-LEASE interval is included as well, that in	Request, except that when the 8-byte Update Lease variant is sent, the du
	terval applies	ration specified in KEY-LEASE applies
	to any KEY records included in the Update section.</t>	to any KEY RRs included in the Update section.</t>
	</section>	</section>

	<section>	<section>

	<name>Requestor Behavior</name>	<name>Requester Behavior</name>


	<t>A requestor that intends that its records from a previous update, whet	<t>A Requester that intends for its RRs from a previous Registration or R
	her a Registration	efresh to remain active <bcp14>MUST</bcp14>
	or a Refresh, remain active, MUST send a Refresh message before the lease	send a Refresh Request before the lease expires; otherwise, the RRs
	elapses, or else the records
	will be removed by the server.</t>	will be removed by the server.</t>


	<t>In order to prevent records expiring, requestors MUST refresh resource	<t>In order to prevent Registrations expiring, Requesters
	records before they	<bcp14>MUST</bcp14> refresh them. When
	expire. At the time of registration, the client computes an interval that	a Lease Update Request succeeds, the requester computes a time limit that
	is 80% of the lease	is 80%
	time plus a random offset between 0 and 5% of the lease time. The random	of the lease duration plus a random offset between 0% and 5% of the lease
	offset is to prevent	duration. The random offset is to prevent refreshes from being
	refreshes from being synchronized. When this interval has expired, the cl	synchronized. When this time limit has expired, the requester
	ient MUST refresh the	<bcp14>MUST</bcp14> send a Refresh Request if the data in the initial
	message if the data in the initial Registration should continue to be adv	Registration should continue to be advertised.</t>
	ertised.</t>


	<t>For Refresh messages, the server is expected to return an Update Lease	<t>For Refresh Requests, the server is expected to return an Update
	option, if	Lease option, if supported, just as with the initial Registration Request
	supported, just as with the initial Registration. As with the Registratio	. As
	n, the	with the Registration Request, the Requester <bcp14>MUST</bcp14> use the
	requestor MUST use the interval(s) specified by the server when determini	durations returned by the server in the Lease Update Response when determ
	ng when to send	ining when to send the
	the next Refresh message.</t>	next Refresh Request.</t>


	<t>When sending Refresh messages, the requestor MUST include an Update Le	<t>When sending Refresh Requests, the Requester <bcp14>MUST</bcp14> inclu
	ase option, as	de an Update Lease option, as
	it did for the initial Registration. The Update Lease option MAY either s	it did in the initial Registration Request.
	pecify the same
	intervals as in the initial Registration, or MAY use the values returned	The Update Lease option <bcp14>MAY</bcp14> either specify the same
	by the server	durations as in the initial Registration Request or use the values return
	in the previous Update Response, whether it was a response to a Registrat	ed by the server
	ion a	in the previous Lease Update Response.
	Refresh. As with responses to Registrations, the requestor MUST use the i	As with responses to Registration Requests, the Requester <bcp14>MUST</bc
	ntervals	p14> use the lease durations
	returned by the server in the response when determining when to send the next Refresh	returned by the server in the response when determining when to send the next Refresh

	message.</t>	Request.</t>

		<t>If the Requester sends a Refresh Request message and
		does not receive a response from the authoritative DNS server,
		then the Requester should implement a reasonable retry strategy
		to attempt to refresh the record registrations before they expire.
		Given that 15% - 20% of the lease lifetime still remains,
		these retransmissions do not need to be overly aggressive.
		For example, the Requester could retry nine more times,
		spaced uniformly at equal intervals from the time of the first
		failed Refresh attempt until the expiration time of the records.
		After the expiration time of the records, the Refresh Request
		effectively turns into a new Registration Request, and further
		retransmissions after this proceed
		as described in <xref target="retransmission"/>.</t>

	<section>	<section>

	<name>Coalescing Refresh Messages</name>	<name>Coalescing Refresh Requests</name>
	<t>If the requestor has performed multiple successful Registrations wi	<t>If the Requester has performed multiple Registrations with a single
	th a single server,	server for different RRs,
	the requestor MAY include Refreshes for all such Registrations to that	the Requester <bcp14>MAY</bcp14> send a Refresh Request containing RRs
	server in a single	from all such Registrations to that server in a single
	message. This effectively places all records for a requestor on the sa	Refresh Request. This effectively places all RRs for a Requester on th
	me expiration	e same expiration
	schedule, reducing network traffic due to Refreshes.</t>	schedule, reducing network traffic due to Refreshes.</t>


	<t>In doing so, the requestor includes in the Refresh message all exist ing updates to	<t>In doing so, the Requester includes in the Refresh Request all exist ing RRs previously successfylly registered on
	the server, including those not yet close to expiration, so long as at least one	the server, including those not yet close to expiration, so long as at least one

	resource record in the message has elapsed at least 75% of its original	RR updated in the Refresh Request has elapsed at least 75% of its origi
	lease. If the	nal lease duration. If the
	requestor uses UDP, the requestor MUST NOT coalesce Refresh messages if	Requester uses UDP, the Requester <bcp14>MUST NOT</bcp14> coalesce Refr
	doing so would	esh Requests if doing so would
	cause truncation of the message; in this case, the requestor should eit	cause truncation of the Request; in this case, the Requester either sen
	her send multiple	ds multiple
	messages or should use TCP to send the entire update at once.</t>	Requests or uses TCP to send the complete Refresh Request at once.</t>


	<t>Requestors SHOULD NOT send a Refresh messages when all of the record	<t>Requesters <bcp14>SHOULD NOT</bcp14> send a Refresh Request when all
	s in the	of the RRs in the
	Refresh have more than 50% of their lease interval remaining before exp	Refresh Request would have more than 50% of their lease duration remain
	iry. However,	ing before expiry. However,
	there may be cases where the requestor needs to send an early Refresh,	there may be cases where the Requester needs to send an early Refresh R
	and it MAY do	equest, and it <bcp14>MAY</bcp14> do
	so. For example, a power-constrained (sleepy) device may need to send a	so. For example, a power-constrained (sleepy) device may need to send a
	n update when the radio	Refresh Request when the radio
	is powered so as to avoid having to power it up later.</t>	is powered so as to avoid having to power it up later.</t>


	<t>Another case where this may be needed is if the lease interval regis	<t>Another case where this may be needed is when the lease duration reg
	tered with the	istered with the
	server is no longer appropriate and the Requestor wishes to negotiate a	server is no longer appropriate and the Requester wishes to negotiate a
	different	different
	lease interval. However, in this case, if the server does not honor the	lease duration. However, in this case, if the server does not honor the
	requested	requested
	interval in its response, the requestor MUST NOT retry this negotiation	lease duration in its response, the Requester <bcp14>MUST NOT</bcp14> r
	.</t>	etry this negotiation.</t>
	</section>	</section>
	</section>	</section>

	<section>	<section>
	<name>Server Behavior</name>	<name>Server Behavior</name>

	<t>Upon receiving a valid Refresh Request, the server MUST send an ackno	<t>Upon receiving a valid Refresh Request, the server <bcp14>MUST</bcp14
	wledgment. This	> send an acknowledgment. This
	acknowledgment is identical to the Update Response format described in <	acknowledgment is a Lease Update Response as described in <xref
	xref	target="update"/> and contains the new lease duration of the Registratio
	target="update"/> "Update Message Format", and contains the new lease of	n
	the resource	being Refreshed. The server <bcp14>MUST NOT</bcp14> increment the seria
	records being Refreshed. The server MUST NOT increment the serial numbe	l number of a zone
	r of a zone	as the result of a Refresh Request if the operation does not result in a
	as the result of a Refresh.</t>	ny change to the zone contents.</t>


	<t>However, the server's state may not match what the client expects. In	<t>However, the server's state may not match what the requester expects.
	this case, a	In this case, a
	Refresh may actually appear to be a Registration, from the server's persp	Refresh Request may actually appear to be a Registration Request, from th
	ective. If the	e server's perspective. If the
	Refresh changes the contents of the zone, the server MUST update the zone	Refresh Request changes the contents of the zone, the server <bcp14>MUST<
	serial	/bcp14> update the zone serial
	number.</t>	number.</t>
	</section>	</section>
	</section>	</section>


	<section>	<section anchor="retransmission">
	<name>Retransmission Strategy</name>	<name>Retransmission Strategy</name>
	<t>The DNS protocol, including DNS updates, can operate over UDP or TCP. W hen using UDP, reliable	<t>The DNS protocol, including DNS updates, can operate over UDP or TCP. W hen using UDP, reliable
	transmission must be guaranteed by retransmitting if a DNS UDP message is not acknowledged in a	transmission must be guaranteed by retransmitting if a DNS UDP message is not acknowledged in a

	reasonable interval. <xref target="RFC1035" section="4.2.1" sectionFormat=	reasonable amount of time.
	"of"/> provides some	Section <xref target="RFC1035" section="4.2.1" sectionFormat="bare"/>
	guidance on this topic, as does <xref target="RFC1536" section="1" section	of the DNS specification <xref target="RFC1035"/>
	Format="of"/>.	provides some guidance on this topic, as does
	<xref target="RFC8085" section="3.1.3" sectionFormat="of"/> also provides	Section <xref target="RFC1536" section="1" sectionFormat="bare"/>
	useful guidance that	of the IETF's guide to common DNS implementation errors <xref target="RFC1
	is particularly relevant to DNS.</t>	536"/>.
		Section <xref target="RFC8085" section="3.1.3" sectionFormat="bare"/>
		of the UDP Usage Guidelines <xref target="RFC8085"/>
		also provides useful guidance that is particularly relevant to DNS.</t>
	</section>	</section>

	<section>	<section>
	<name>Garbage Collection</name>	<name>Garbage Collection</name>


	<t>If the Update Lease of a resource record elapses without being refreshe	<t>If the lease duration of an RR elapses without being refreshed, the aut
	d, the server	horitative DNS server
	MUST NOT return the expired record in answers to queries. The server MAY d	<bcp14>MUST NOT</bcp14> return that RR in answers to queries. The server <
	elete the record	bcp14>MAY</bcp14> delete that RR
	from its database. The lease interval(s) returned by the server to the req	from its database. The lease durations returned by the server to the Reque
	uestor are used	ster are used
	in determining when the lease on a resource record has expired.</t>	in determining when the lease on an RR has expired.</t>


	<t>For all resource records other than a KEY record included in a DNS Upda	<t>For all RRs other than a KEY RR included in a Lease Update Request, the
	te request, the	lease duration is the LEASE value in the Update Lease option. For KEY RRs,
	Update Lease is the LEASE value in the Update Lease option. For KEY record	if the
	s, if the	optional KEY-LEASE value was included, this duration is used rather than t
	optional KEY-LEASE value was included, this interval is used rather than t	he duration
	he interval	specified in the LEASE. If the KEY-LEASE was not specified, the duration s
	specified in LEASE. If KEY-LEASE was not specified, the interval specified	pecified in the LEASE is
	in LEASE is	used for all RRs in the Lease Update Request.
	used.
	</t>	</t>
	</section>	</section>


	<section title="Security Considerations">	<section>
	<t><xref target="RFC2136" section="8" sectionFormat="of"/> describes probl	<name>Security Considerations</name>
	ems that can occur
		<t>Section <xref target="RFC2136" section="8" sectionFormat="bare"/> of
		the DNS Update specification <xref target="RFC2136"/> describes problems t
		hat can occur
	around DNS updates. Servers implementing this specification should follow these recommendations.</t>	around DNS updates. Servers implementing this specification should follow these recommendations.</t>


	<t>Several additional issues can arise when relying on the Update Lease op	<t>Several additional issues can arise when relying on the Update Lease op
	tion. First, a	tion.</t>
	too-long lease time is not much different than no lease time: the records
	associated with	<t>First, a
	this lease time will effectively never be cleaned up. Servers implementing	too-long lease duration is not much different from no lease duration: the
	Update Lease	RRs associated with
		such a Registration will effectively never be cleaned up. Servers implemen
		ting Update Lease
	should have a default upper bound on the maximum acceptable value both for the LEASE and	should have a default upper bound on the maximum acceptable value both for the LEASE and

	KEY-LEASE values sent by the client. Servers MAY provide a way for the ope	KEY-LEASE values sent by the requester.
	rator to change	Default values for these limits of 24 hours and 7 days, respectively,
	this upper limit. Default values for these limits of 24 hours and 7 days,	are <bcp14>RECOMMENDED</bcp14>.
	respectively,	Servers <bcp14>MAY</bcp14> provide a way for the operator to change this u
	are RECOMMENDED.</t>	pper limit.</t>

	<t>The second issue is that a too-short lease can result in increased serv er load as	<t>The second issue is that a too-short lease can result in increased serv er load as

	requestors rapidly renew the lease. A delay in renewing could result in th	Requesters rapidly renew such Registrations. A delay in renewing could res
	e data being	ult in the registered RRs being
	removed prematurely. Servers implementing Update Lease MUST have a defaul	removed prematurely. Servers implementing Update Lease <bcp14>MUST</bcp14
	t minimum lease	> have a default minimum lease
	interval that avoids this issue. We RECOMMEND a minimum of 30 seconds for	duration that avoids this issue. A minimum of 30 seconds for both the LEA
	both the LEASE	SE
	and KEY-LEASE intervals. However, in most cases, much longer lease times (	and KEY-LEASE durations is <bcp14>RECOMMENDED</bcp14>.
	for example, an hour)	However, in most cases, much longer lease durations (for example, an hour)
	are RECOMMENDED.</t>	<bcp14>SHOULD</bcp14> be used.
		Servers <bcp14>MAY</bcp14> provide a way for the operator to change this l
		ower limit.</t>


	<t>There may be some cost associated with renewing leases. A malicious (or	<t>There may be some cost associated with renewing leases. A malicious
	buggy) client	(or buggy) requester could renew at a high rate in order to overload the
	could renew at a high rate in order to overload the server more than it wo	server more than it would be overloaded by query traffic. This risk is
	uld be	present for an authoritative server handling normal (no-lease) DNS Updates
	overloaded by query traffic. This risk is present for regular DNS update a	as well.
	s well. The	Servers should follow established
	server MUST enforce a minimum interval between updates. After a Refresh or	industry best practices to guard against flooding attacks,
	Registration	both for malicious flooding of DNS messages over UDP
	has been successfully processed and acknowledged, another Update of either	and for similar flooding attacks using TCP
	type from the	<xref target="SYN" format="default"/> <xref target="RFC4953" format="defau
	client during that interval MUST be silently ignored by the server.</t>	lt"/>.</t>


	<t>Some authentication strategy should be used when accepting DNS updates.	<t>Some authentication strategy should be used when accepting DNS
	Shared secret	updates. Shared secret <xref target="RFC8945"/> or public key signing
	<xref target="RFC8945"/> or public key signing (e.g. SIG(0) <xref target="	(e.g., SIG(0) <xref target="RFC2931"/>) should be required. Keys should
	RFC2931"/>) should be required. Keys should have limited	have limited authority: compromise of a key should not result in
	authority: compromise of a key should not result in compromise of the enti	compromise of the entire contents of one or more zones managed by the
	re contents of one	server. Key management strategy is out of scope for this document.
	or more zones managed by the server. Key management strategy is out of sco	Service Registration Protocol <xref target="RFC9665"/>
	pe for this document.	uses DNS Update Leases with "First Come, First Served Naming" rather
	An example of a key management strategy can be found in <xref target="I-D.	than an explicit trust establishment process to confer update
	ietf-dnssd-srp"/>,	permission to a set of RRs.</t>
	which uses "first come, first-served naming" rather than an explicit trust
	establishment process,
	to confer update permission to a set of records.</t>
	</section>	</section>

	<section>	<section>
	<name>IANA Considerations</name>	<name>IANA Considerations</name>


	<t>The EDNS(0) OPTION CODE 2 has already been assigned for this DNS extens	<t>IANA has updated the "DNS EDNS0 Option Codes (OPT)" registry <xref targ
	ion. This	et="EDNS0Reg"/> as regards value 2 as follows:</t>
	document appears in the DNS EDNS0 Option Codes (OPT) registry <xref target
	="EDNS0Codes"/> with the name 'UL' and the status 'On-hold,' and a
	document reference to an older version of this document. When this documen
	t has been
	approved, the IANA is asked to update the registry as follows:</t>
	<sourcecode>
	OLD:
	Value: 2
	Name: UL
	Status: On-hold
	Reference: http://files.dns-sd.org/draft-sekar-dns-ul.txt


	NEW:	<dl newline="false" spacing="compact">
	Value: 2	<dt>Value:</dt> <dd>2</dd>
	Name: Update Lease	<dt>Name:</dt> <dd>Update Lease</dd>
	Status: Standard	<dt>Status:</dt> <dd>Standard</dd>
	Reference: [this document]	<dt>Reference:</dt> <dd>RFC 9664</dd>
	</sourcecode>	</dl>
	</section>


	<section>
	<name>Acknowledgments</name>
	<t>Thanks to Marc Krochmal and Kiren Sekar for their work in 2006 on the p
	recursor to this
	document. Thanks also to Roger Pantos and Chris Sharp for their contribut
	ions. Thanks to
	Chris Box, Esko Dijk, Jonathan Hui, Peter van Dijk, Abtin Keshvarzian, Nat
	han Dyck, Steve
	Hanna, Gabriel Montenegro, Kangping Dong, and Tim Wicinski for their worki
	ng group reviews of this document.
	Thanks to David Dong, Olafur Gudmundsson, Brian Trammel, and Shivan Sahib
	for their directorate
	reviews and IANA reviews.</t>
	</section>	</section>


	</middle>	</middle>

	<back>	<back>

	<!-- This needLines directive is to keep the Authors' Addresses heading from bei
	ng split from the list -->
	<!-- <displayreference target="I-D.sctl-service-registration" to="RegProt"/>
	-->
	<!-- <displayreference target="I-D.ietf-dnssd-hybrid" to="I-D.ietf-dnssd-hyb
	rid"/> appears to not work in xml2rfc 2.6.2 -->
	<references title="Normative References">
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.1035.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.2119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.2136.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.6891.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8174.xml"/>
	</references>


	<references title="Informative References">	<references>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<name>References</name>
	.1536.xml"/>	<references>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<name>Normative References</name>
	.2931.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.103
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	5.xml"/>
	.6763.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	9.xml"/>
	.8085.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.213
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	6.xml"/>
	.8945.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.689
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-	1.xml"/>
	D.ietf-dnssd-srp.xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
	<reference anchor="EDNS0Codes" target="https://www.iana.org/assignments/dn	4.xml"/>
	s-parameters/dns-parameters.xml">	</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.153
		6.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.293
		1.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.495
		3.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.676
		3.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.808
		5.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.894
		5.xml"/>

		<!-- [I-D.ietf-dnssd-srp] companion document RFC 9665-->
		<reference anchor="RFC9665" target="https://www.rfc-editor.org/info/rfc966
		5">
		<front>
		<title>Service Registration Protocol for DNS-Based Service Discovery</t
		itle>
		<author fullname="Ted Lemon" initials="T." surname="Lemon">
		<organization>Apple Inc.</organization>
		</author>
		<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
		<organization>Apple Inc.</organization>
		</author>
		<date month="October" year="2024"/>
		</front>
		<seriesInfo name="RFC" value="9665"/>
		<seriesInfo name="DOI" value="10.17487/RFC9665"/>
		</reference>

		<reference anchor="EDNS0Reg" target="https://www.iana.org/assignments/dns-
		parameters">
	<front>	<front>
	<title>DNS EDNS0 Option Codes (OPT)</title>	<title>DNS EDNS0 Option Codes (OPT)</title>

	<author/>	<author>
	<date month="April" year="2023"/>	<organization>IANA</organization>
		</author>
	</front>	</front>
	</reference>	</reference>


		<reference anchor="SYN"
		target="https://www.cisco.com/web/about/ac123/ac147/archived_i
		ssues/ipj_9-4/ipj_9-4.pdf">
		<front>
		<title>Defenses Against TCP SYN Flooding Attacks</title>

		<author initials="W." surname="Eddy" fullname="Wesley Eddy">
		<organization>Verizon Federal Network Systems</organization>
		<address>
		<email>weddy@grc.nasa.gov</email>
		</address>
		</author>
		<date year="2006" month="December"/>
		<keyword>TCP</keyword>
		</front>
		<refcontent>The Internet Protocol Journal</refcontent>
		<refcontent>Cisco Systems</refcontent>
		<refcontent>Volume 9</refcontent>
		<refcontent>Number 4</refcontent>
		</reference>

		</references>
	</references>	</references>


		<section numbered="false">
		<name>Acknowledgments</name>
		<t>Thanks to <contact fullname="Marc Krochmal"/> and <contact
		fullname="Kiren Sekar"/> for their work in 2006 on the precursor to this
		document. Thanks also to <contact fullname="Roger Pantos"/> and
		<contact fullname="Chris Sharp"/> for their contributions. Thanks to
		<contact fullname="Chris Box"/>, <contact fullname="Esko Dijk"/>,
		<contact fullname="Jonathan Hui"/>, <contact fullname="Peter van
		Dijk"/>, <contact fullname="Abtin Keshvarzian"/>, <contact
		fullname="Nathan Dyck"/>, <contact fullname="Steve Hanna"/>, <contact
		fullname="Gabriel Montenegro"/>, <contact fullname="Kangping Dong"/>,
		and <contact fullname="Tim Wicinski"/> for their working group reviews
		of this document. Thanks to <contact fullname="David Dong"/>, <contact
		fullname="Olafur Gudmundsson"/>, <contact fullname="Brian Trammel"/>,
		and <contact fullname="Shivan Sahib"/> for their directorate reviews and
		IANA reviews.</t>
		</section>

	</back>	</back>


	</rfc>	</rfc>

End of changes. 74 change blocks.
	491 lines changed or deleted	581 lines changed or added
This html diff was produced by rfcdiff 1.48.