rfc8764xml2.original.xml   rfc8764.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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="info" docN
ame="draft-sekar-dns-llq-06" indexInclude="true" ipr="trust200902" number="8764"
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ prepTime="2020-06-22T21:06:29" scripts="Common,Latin" sortRefs="true" submissio
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere nType="independent" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
nce.RFC.1035.xml"> <link href="https://datatracker.ietf.org/doc/draft-sekar-dns-llq-06" rel="prev
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere "/>
nce.RFC.2119.xml"> <link href="https://dx.doi.org/10.17487/rfc8764" rel="alternate"/>
<!ENTITY RFC2782 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <link href="urn:issn:2070-1721" rel="alternate"/>
nce.RFC.2782.xml"> <front>
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <title abbrev="Apple's DNS LLQ">Apple's DNS Long-Lived Queries Protocol</tit
nce.RFC.8174.xml"> le>
<seriesInfo name="RFC" value="8764" stream="independent"/>
<!ENTITY RFC2136 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <author initials="S." surname="Cheshire" fullname="Stuart Cheshire">
nce.RFC.2136.xml"> <organization showOnFrontPage="true">Apple Inc.</organization>
<!ENTITY RFC4787 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <address>
nce.RFC.4787.xml"> <postal>
<!ENTITY RFC4953 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <street>One Apple Park Way</street>
nce.RFC.4953.xml"> <city>Cupertino</city>
<!ENTITY RFC5382 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <region>CA</region>
nce.RFC.5382.xml"> <code>95014</code>
<!ENTITY RFC6281 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <country>United States of America</country>
nce.RFC.6281.xml"> </postal>
<!ENTITY RFC6762 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <phone>+1 (408) 996-1010</phone>
nce.RFC.6762.xml"> <email>cheshire@apple.com</email>
<!ENTITY RFC6763 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere </address>
nce.RFC.6763.xml"> </author>
<!ENTITY RFC6886 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <author initials="M." surname="Krochmal" fullname="Marc Krochmal">
nce.RFC.6886.xml"> <organization showOnFrontPage="true">Apple Inc.</organization>
<!ENTITY RFC6887 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <address>
nce.RFC.6887.xml"> <postal>
<!ENTITY RFC6891 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <street>One Apple Park Way</street>
nce.RFC.6891.xml"> <city>Cupertino</city>
<!ENTITY RFC7857 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <region>CA</region>
nce.RFC.7857.xml"> <code>95014</code>
]> <country>United States of America</country>
</postal>
<?rfc compact="yes"?> <phone>+1 (408) 996-1010</phone>
<?rfc subcompact="no"?> <email>marc@apple.com</email>
<?rfc toc="yes"?> </address>
<?rfc symrefs="yes"?> </author>
<?rfc sortrefs="yes"?> <date month="06" year="2020"/>
<keyword>Async</keyword>
<rfc docName="draft-sekar-dns-llq-06" category="info" submissionType="independen <keyword>Asynchronous</keyword>
t" ipr="trust200902"> <keyword>Change Notification</keyword>
<keyword>Push Notification</keyword>
<front> <abstract pn="section-abstract">
<t pn="section-abstract-1">
<title>Apple's DNS Long-Lived Queries protocol</title> Apple's DNS Long-Lived Queries (LLQ) is a mechanism
for extending the DNS protocol to support change notification,
<author initials="S." surname="Cheshire" fullname="Stuart Cheshire"> thus allowing clients to learn about changes to DNS data
<organization>Apple Inc.</organization> without polling the server. From 2005 onwards, LLQ was
<address> implemented in Apple products including Mac OS X, Bonjour for
<postal> Windows, and AirPort wireless base stations. In 2020, the LLQ
<street>One Apple Park Way</street> protocol was superseded by the IETF Standards Track RFC 8765,
<city>Cupertino</city> "DNS
<region>CA</region> Push Notifications", which builds on experience gained with
<code>95014</code> the LLQ protocol to create a superior replacement.
<country>United States of America</country> </t>
</postal> <t pn="section-abstract-2">
<phone>+1 (408) 996-1010</phone> The existing LLQ protocol deployed and used from 2005 to 2020 is
<email>cheshire@apple.com</email> documented here to give
</address> background regarding the operational experience that informed
</author> the development of DNS Push Notifications, and to help facilitate
a smooth transition from LLQ to DNS Push Notifications.
<author initials='M.' surname='Krochmal' fullname='Marc Krochmal'> </t>
<organization>Apple Inc.</organization> </abstract>
<address> <boilerplate>
<postal> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<street>One Apple Park Way</street> "exclude" pn="section-boilerplate.1">
<city>Cupertino</city> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
<region>California</region> >
<code>95014</code> <t pn="section-boilerplate.1-1">
<country>USA</country> This document is not an Internet Standards Track specification; it i
</postal> s
<email>marc@apple.com</email> published for informational purposes.
</address> </t>
</author> <t pn="section-boilerplate.1-2">
This is a contribution to the RFC Series, independently of any
<date year="2019" month="August" day="22"/> other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
<abstract> for implementation or deployment. Documents approved for
<t> publication by the RFC Editor are not candidates for any level of
Apple's DNS Long-Lived Queries protocol (LLQ) is Internet Standard; see Section 2 of RFC 7841.
a protocol for extending the DNS protocol to support </t>
change notification, thus allowing clients to learn about changes <t pn="section-boilerplate.1-3">
to Information about the current status of this document, any
DNS data without polling the server. errata, and how to provide feedback on it may be obtained at
From 2005 onwards, LLQ was implemented in Apple products <eref target="https://www.rfc-editor.org/info/rfc8764" brackets="non
including Mac OS X, Bonjour for Windows, and AirPort wireless base e"/>.
stations. In 2019, the LLQ protocol </t>
was superseded by the IETF Standards Track RFC xxxx </section>
[[RFC Editor note: Please replace xxxx with RFC number]] <section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
"DNS Push Notifications", ude" pn="section-boilerplate.2">
which builds on experience gained with the LLQ protocol to create <name slugifiedName="name-copyright-notice">Copyright Notice</name>
a superior replacement. <t pn="section-boilerplate.2-1">
</t> Copyright (c) 2020 IETF Trust and the persons identified as the
<t> document authors. All rights reserved.
The existing LLQ protocol deployed and used from 2005 to 2019 is documented h </t>
ere to give <t pn="section-boilerplate.2-2">
background regarding the operational experience that informed This document is subject to BCP 78 and the IETF Trust's Legal
the development of DNS Push Notifications, and to help facilitate Provisions Relating to IETF Documents
a smooth transition from LLQ to DNS Push Notifications. (<eref target="https://trustee.ietf.org/license-info" brackets="none
</t> "/>) in effect on the date of
</abstract> publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
</front> respect to this document.
</t>
<middle> </section>
<?rfc needLines="40" ?> </boilerplate>
<section anchor="introduction" title="Introduction"> <toc>
<t> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
In dynamic environments, DNS Service Discovery <xref target="RFC6763"/> benef n="section-toc.1">
its <name slugifiedName="name-table-of-contents">Table of Contents</name>
significantly from clients being able to learn about changes to <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
DNS information via a mechanism that is both more timely and more c.1-1">
efficient than simple polling. Such a mechanism enables "live <li pn="section-toc.1-1.1">
browses" that learn when a new instance of a service appears, or when <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
an existing service disappears from the network, and allows clients ="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedCon
to monitor changes to a service. Multicast DNS <xref target="RFC6762"/> suppo tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
rts this n</xref></t>
natively. When a host on the network publishes or deletes DNS <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
records, these changes are multicast to other hosts on the network. n-toc.1-1.1.2">
These hosts deliver the change notifications to interested clients (applicati <li pn="section-toc.1-1.1.2.1">
ons <t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derive
running on the host). Hosts also send occasional queries to the dContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xre
network in case gratuitous announcements are not received due to f derivedContent="" format="title" sectionFormat="of" target="name-transition-to
packet loss, and to detect records lost due to their publishers -dns-push-noti">Transition to DNS Push Notifications</xref></t>
crashing or having become disconnected from the network. </li>
</t> </ul>
</li>
<t> <li pn="section-toc.1-1.2">
This document defines an Apple extension to DNS that enables a client to <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
issue long-lived queries that allow a DNS server to notify clients ="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedCon
about changes to DNS data. This is a more scalable and practical tent="" format="title" sectionFormat="of" target="name-conventions-and-terminolo
solution than can be achieved by polling of the name server because gy">Conventions and Terminology Used in This Document</xref></t>
a low polling rate could leave the client with stale information </li>
while a high polling rate would have an adverse impact on the network <li pn="section-toc.1-1.3">
and server. <t pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter
</t> " sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-mechanisms">Mechanisms</xref></t>
<t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
The mechanism defined in this document is now being replaced by n-toc.1-1.3.2">
<xref target="Push">DNS Push Notifications</xref> as explained below <li pn="section-toc.1-1.3.2.1">
in <xref target="trans"/>. <t pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" forma
</t> t="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent=""
<?rfc needLines="40" ?> format="title" sectionFormat="of" target="name-assigned-numbers">Assigned Number
<t> s</xref></t>
</t> </li>
<section anchor="trans" title="Transition to DNS Push Notificatio <li pn="section-toc.1-1.3.2.2">
ns"> <t pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" forma
<t> t="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent=""
The LLQ protocol enjoyed over a decade of useful operation, format="title" sectionFormat="of" target="name-opt-rr-format">Opt-RR Format</xre
enabling timely live updates for the service discovery user interface in f></t>
Apple's <xref target="RFC6281">Back to My Mac</xref> service. </li>
</t> </ul>
</li>
<t> <li pn="section-toc.1-1.4">
However, some problems were discovered, as described in <xref target="problem <t pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter
s"/>. " sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="titl
This operational e" sectionFormat="of" target="name-llq-address-and-port-identi">LLQ Address and
experience with LLQ informed the design of its IETF Standards Port Identification</xref></t>
Track successor, <xref target="Push">DNS Push Notifications</xref>. </li>
Since no further work is being done on the LLQ protocol, this LLQ <li pn="section-toc.1-1.5">
specification will not be updated to remedy these problems. <t pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter
</t> " sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-llq-setup">LLQ Setup</xref></t>
<t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
All existing LLQ n-toc.1-1.5.2">
implementations are RECOMMENDED to migrate to using DNS Push Notifications in <li pn="section-toc.1-1.5.2.1">
stead. <t pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" forma
</t> t="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-setup-message-retransmissio">Setu
<t> p Message Retransmission</xref></t>
For existing LLQ servers, they are RECOMMENDED to implement and support </li>
DNS Push Notifications, so that clients can begin migrating to the <li pn="section-toc.1-1.5.2.2">
newer protocol. <t pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" forma
</t> t="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-llq-setup-four-way-handshak">LLQ
<t> Setup Four-Way Handshake</xref></t>
For existing LLQ clients, they are RECOMMENDED to query for the <ul bare="true" empty="true" indent="2" spacing="compact" pn="se
<spanx style="verb">_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</spanx> ction-toc.1-1.5.2.2.2">
SRV record first, and only if DNS Push fails, then fall back to query for <li pn="section-toc.1-1.5.2.2.2.1">
<spanx style="verb">_dns&nbhy;llq._udp.&lt;zone&gt;</spanx> instead. <t pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.
</t> 2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-setup-request">Setup
<t> Request</xref></t>
This will cause clients to prefer the newer protocol when possible. </li>
It is RECOMMENDED that clients always attempt <li pn="section-toc.1-1.5.2.2.2.2">
DNS Push Notifications first for every new request, and <t pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.
only if that fails, then back to using LLQ. 2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <xref derive
Clients SHOULD NOT record that a given server only speaks LLQ and dContent="" format="title" sectionFormat="of" target="name-setup-challenge">Setu
subsequently default to LLQ for that server, since server software p Challenge</xref></t>
gets updated, and even a server that speaks only LLQ today, </li>
may be updated to support DNS Push Notifications tomorrow. <li pn="section-toc.1-1.5.2.2.2.3">
</t> <t pn="section-toc.1-1.5.2.2.2.3.1"><xref derivedContent="5.
2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>.  <xref derive
<t> dContent="" format="title" sectionFormat="of" target="name-challenge-response">C
New client and server implementations are RECOMMENDED to support only hallenge Response</xref></t>
DNS Push Notifications. </li>
</t> <li pn="section-toc.1-1.5.2.2.2.4">
<t pn="section-toc.1-1.5.2.2.2.4.1"><xref derivedContent="5.
</section> 2.4" format="counter" sectionFormat="of" target="section-5.2.4"/>.  <xref derive
</section> dContent="" format="title" sectionFormat="of" target="name-ack-answers">ACK + An
swers</xref></t>
<section title="Conventions and Terminology Used in this Document"> </li>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL </ul>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", </li>
"MAY", and "OPTIONAL" in this document are to be interpreted as <li pn="section-toc.1-1.5.2.3">
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="R <t pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" forma
FC8174"/> t="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent=""
when, and only when, they appear in all capitals, as shown here.< format="title" sectionFormat="of" target="name-resource-record-ttls">Resource Re
/t> cord TTLs</xref></t>
<?rfc needLines="40" ?> </li>
</section> </ul>
</li>
<section title="Mechanisms"> <li pn="section-toc.1-1.6">
<t> <t pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter
DNS Long-Lived Queries (DNS&nbhy;LLQ) is implemented using the standard " sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="titl
DNS message format <xref target="RFC1035"/> in conjunction with an EDNS(0) OP e" sectionFormat="of" target="name-event-responses">Event Responses</xref></t>
T <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
pseudo&nbhy;RR <xref target="RFC6891"/> with a new OPT and RDATA format speci n-toc.1-1.6.2">
fied here. <li pn="section-toc.1-1.6.2.1">
Encoding the LLQ request in an OPT RR allows for implementation of <t pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" forma
LLQ with minimal modification to a name server's front-end. t="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent=""
If a DNS query containing an LLQ option is sent to a format="title" sectionFormat="of" target="name-add-events">Add Events</xref></t>
server that does not implement LLQ, a server that complies with </li>
the <xref target="RFC6891">EDNS(0) specification</xref> will silently ignore <li pn="section-toc.1-1.6.2.2">
the unrecognized option and answer the request as a normal DNS query, <t pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" forma
without establishing any long-lived state, t="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent=""
and without returning an LLQ option in its response. format="title" sectionFormat="of" target="name-remove-events">Remove Events</xre
If a DNS query containing an LLQ option is sent to a f></t>
server that does not implement EDNS(0) at all, </li>
the server may silently ignore the EDNS(0) OPT pseudo&nbhy;RR, <li pn="section-toc.1-1.6.2.3">
or it may return a nonzero RCODE. <t pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" forma
However, in practice this issue is mostly theoretical, t="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent=""
since having a zone's _dns&nbhy;llq._udp.&lt;zone&gt; SRV record format="title" sectionFormat="of" target="name-gratuitous-response-acknowl">Grat
target a host that does not implement LLQ is a configuration error. uitous Response Acknowledgments</xref></t>
</t> </li>
<t> </ul>
Note that this protocol is designed for data set sizes of a few dozen resourc </li>
e records at most, and <li pn="section-toc.1-1.7">
change rates no more than one every ten seconds on average. Data sets in resp <t pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter
onse to queries that " sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="titl
frequently exceed a single packet, or that experience a rapid change e" sectionFormat="of" target="name-llq-lease-life-expiration">LLQ Lease-Life Exp
rate, may have undesirable performance implications. iration</xref></t>
</t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
<?rfc needLines="20" ?> n-toc.1-1.7.2">
<t> <li pn="section-toc.1-1.7.2.1">
</t> <t pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" forma
<section title="Assigned Numbers"> t="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent=""
<t> format="title" sectionFormat="of" target="name-refresh-request">Refresh Request<
This section describes constants uses in this document. /xref></t>
</t> </li>
<figure><artwork> <li pn="section-toc.1-1.7.2.2">
EDNS(0) Option Code (recorded with IANA): <t pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" forma
LLQ 1 t="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-llq-refresh-acknowledgment">LLQ R
LLQ-PORT 5352 (recorded with IANA) efresh Acknowledgment</xref></t>
</li>
LLQ Error Codes (specific to this LLQ EDNS(0) Option): </ul>
NO-ERROR 0 </li>
SERV-FULL 1 <li pn="section-toc.1-1.8">
STATIC 2 <t pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter
FORMAT-ERR 3 " sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="titl
NO-SUCH-LLQ 4 e" sectionFormat="of" target="name-security-considerations">Security Considerati
BAD-VERS 5 ons</xref></t>
UNKNOWN-ERR 6 <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
LLQ Opcodes (specific to this LLQ EDNS(0) Option): <li pn="section-toc.1-1.8.2.1">
LLQ-SETUP 1 <t pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" forma
LLQ-REFRESH 2 t="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent=""
LLQ-EVENT 3 format="title" sectionFormat="of" target="name-server-dos">Server DoS</xref></t>
</artwork></figure> </li>
<?rfc needLines="40" ?> <li pn="section-toc.1-1.8.2.2">
</section> <t pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" forma
t="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent=""
<section title="Opt-RR Format"> format="title" sectionFormat="of" target="name-client-packet-storms">Client Pack
<t> et Storms</xref></t>
As required by the <xref target="RFC6891">EDNS(0) specification</xref>, </li>
all OPT&nbhy;RRs used in LLQs are formatted as follows: <li pn="section-toc.1-1.8.2.3">
</t> <t pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" forma
t="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent=""
<figure><artwork> format="title" sectionFormat="of" target="name-spoofing">Spoofing</xref></t>
Field Name Field Type Description </li>
NAME domain name empty (root domain) </ul>
TYPE u_int16_t OPT </li>
CLASS u_int16_t 0* <li pn="section-toc.1-1.9">
TTL u_int32_t 0 <t pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter
RDLEN u_int16_t describes RDATA " sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="titl
RDATA octet stream (see below) e" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xre
</artwork></figure> f></t>
</li>
<t> <li pn="section-toc.1-1.10">
* The CLASS field indicates, as per the <xref target="RFC6891">EDNS(0) specif <t pn="section-toc.1-1.10.1"><xref derivedContent="10" format="count
ication</xref>, the sender's UDP er" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="ti
payload size. However, clients and servers need not be required to tle" sectionFormat="of" target="name-references">References</xref></t>
determine their reassembly buffer size, path MTU, etc. to support <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
LLQ. Thus, the sender of an LLQ Request or Response MAY set the CLASS n-toc.1-1.10.2">
field to 0. The recipient MUST ignore the class field if it is set <li pn="section-toc.1-1.10.2.1">
to 0. <t pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" for
</t> mat="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent=
"" format="title" sectionFormat="of" target="name-normative-references">Normativ
<?rfc needLines="20" ?> e References</xref></t>
<t> </li>
RDATA Format: <li pn="section-toc.1-1.10.2.2">
</t> <t pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" for
mat="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent=
<figure><artwork> "" format="title" sectionFormat="of" target="name-informative-references">Inform
Field Name Field Type Description ative References</xref></t>
OPTION-CODE u_int16_t LLQ </li>
OPTION-LENGTH u_int16_t Length of following fields, as </ul>
appropriate </li>
VERSION u_int16_t Version of LLQ protocol implemented <li pn="section-toc.1-1.11">
LLQ-OPCODE u_int16_t Identifies LLQ operation <t pn="section-toc.1-1.11.1"><xref derivedContent="Appendix A" forma
ERROR-CODE u_int16_t Identifies LLQ errors t="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedCont
LLQ-ID u_int64_t Identifier for an LLQ ent="" format="title" sectionFormat="of" target="name-problems-with-the-llq-prot
LEASE-LIFE u_int32_t Requested or granted life of LLQ, in o">Problems with the LLQ Protocol</xref></t>
seconds </li>
</artwork></figure> <li pn="section-toc.1-1.12">
<t pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" s
<t> ectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="t
This data format, consisting of (OPTION&nbhy;CODE, OPTION&nbhy;LENGTH, itle" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t
LLQ&nbhy;Metadata) tuples, may be repeated an arbitrary number of times in >
the RDATA section, with the RDLEN field set accordingly. </li>
</t> <li pn="section-toc.1-1.13">
<t pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" s
<t> ectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="t
The size and meaning of the itle" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xre
OPTION&nbhy;CODE and OPTION&nbhy;LENGTH fields are as described in the f></t>
<xref target="RFC6891">EDNS(0) specification</xref>. </li>
The remainder of the fields comprise the OPTION-DATA of the </ul>
EDNS(0) option. </section>
Since for LLQ the OPTION-DATA is a fixed size, </toc>
in LLQ EDNS(0) options the OPTION&nbhy;LENGTH field always has the value 18. </front>
</t> <middle>
<?rfc needLines="40" ?> <section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
</section> lse" pn="section-1">
</section> <name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">
<section title="LLQ Address and Port Identification"> In dynamic environments, DNS-based Service Discovery <xref target="RFC6763"
<t> format="default" sectionFormat="of" derivedContent="RFC6763"/> benefits
significantly from clients being able to learn about changes to
DNS information via a mechanism that is both more timely and more
efficient than simple polling. Such a mechanism enables "live
browses" that (a) learn when a new instance of a service appears, (b)
learn when
an existing service instance disappears from the network, and (c) allows
clients
to monitor status changes to a service instance (e.g., printer ink
levels).
Multicast DNS <xref target="RFC6762" format="default" sectionFormat="of" der
ivedContent="RFC6762"/> supports this
natively. When a device on the network publishes or deletes Multicast DNS
records, these changes are multicast to other hosts on the network.
Those hosts deliver the change notifications to interested clients
(applications
running on that host). Hosts also send occasional queries to the
network, in case gratuitous announcements are not received due to
packet loss, and to detect records lost due to their publishers
crashing or having become disconnected from the network.
</t>
<t pn="section-1-2">
This document defines an Apple extension to unicast DNS that enables a
client to
issue long-lived queries that allow a unicast DNS server to notify clients
about changes to DNS data. This is a more scalable and practical
solution than can be achieved by polling of the name server, because
a low polling rate could leave the client with stale information,
while a high polling rate would have an adverse impact on the network
and server.
</t>
<t pn="section-1-3">
The mechanism defined in this document is now being replaced by DNS Push
Notifications <xref target="RFC8765" format="default" sectionFormat="of" deri
vedContent="RFC8765"/> as explained
in <xref target="trans" format="default" sectionFormat="of" derivedContent="S
ection 1.1"/>.
</t>
<t pn="section-1-4">
</t>
<section anchor="trans" numbered="true" toc="include" removeInRFC="false"
pn="section-1.1">
<name slugifiedName="name-transition-to-dns-push-noti">Transition to DNS
Push Notifications</name>
<t pn="section-1.1-1">
The LLQ protocol enjoyed over a decade of useful operation,
enabling timely live updates for the service discovery user interface in
Apple's Back to My Mac <xref target="RFC6281" format="default" sectionFormat
="of" derivedContent="RFC6281"/>
service.
</t>
<t pn="section-1.1-2">
However, some problems were discovered, as described in <xref target="proble
ms" format="default" sectionFormat="of" derivedContent="Appendix A"/>.
This operational
experience with LLQ informed the design of its IETF Standards
Track successor, DNS Push Notifications <xref target="RFC8765" format="defau
lt" sectionFormat="of" derivedContent="RFC8765"/>.
Since no further work is being done on the LLQ protocol, this LLQ
specification will not be updated to remedy these problems.
</t>
<t pn="section-1.1-3">
All existing LLQ implementations are <bcp14>RECOMMENDED</bcp14> to migrate
to using DNS Push Notifications instead.
</t>
<t pn="section-1.1-4">
Existing LLQ servers are <bcp14>RECOMMENDED</bcp14> to implement and
support
DNS Push Notifications so that clients can begin migrating to the
newer protocol.
</t>
<t pn="section-1.1-5">
Existing LLQ clients are <bcp14>RECOMMENDED</bcp14> to query for the
<tt>_dns‑push‑tls._tcp.&lt;zone&gt;</tt> SRV record first, and
then only if DNS Push Notifications fail, fall back to query for
<tt>_dns‑llq._udp.&lt;zone&gt;</tt> instead. Use of the
<tt>_dns‑llq._udp.&lt;zone&gt;</tt> SRV record is described in <xref target=
"address-port" format="default" sectionFormat="of" derivedContent="Section 4"/>.
</t>
<t pn="section-1.1-6">
This will cause clients to prefer the newer protocol when possible. It is
<bcp14>RECOMMENDED</bcp14> that clients always attempt DNS Push
Notifications first for every new request, and only if that fails, then
fall back to using LLQ. Clients <bcp14>SHOULD NOT</bcp14> record that a
given server only speaks LLQ and subsequently default to LLQ for that
server, since server software gets updated and even a server that speaks
only LLQ today may be updated to support DNS Push Notifications tomorrow.
</t>
<t pn="section-1.1-7">
New client and server implementations are <bcp14>RECOMMENDED</bcp14> to
support only
DNS Push Notifications.
</t>
</section>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<name slugifiedName="name-conventions-and-terminology">Conventions and Ter
minology Used in This Document</name>
<t pn="section-2-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14
>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP 14 <xref target="RFC2119" format="def
ault" sectionFormat="of" derivedContent="RFC2119"/>
<xref target="RFC8174" format="default" sectionFormat="of" derivedConten
t="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.
</t>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3">
<name slugifiedName="name-mechanisms">Mechanisms</name>
<t pn="section-3-1">
DNS Long-Lived Queries (LLQ) are implemented using the standard
DNS message format <xref target="RFC1035" format="default" sectionFormat="of
" derivedContent="RFC1035"/> in
conjunction with an EDNS(0) OPT
pseudo‑RR <xref target="RFC6891" format="default" sectionFormat="of" derived
Content="RFC6891"/> with a new
OPTION‑CODE
and OPTION‑DATA format specified here. Encoding the LLQ request in
an OPT pseudo‑RR
allows for implementation of LLQ with minimal modification to a name
server's front end. If a DNS query containing an LLQ option is sent to a
server that does not implement LLQ, a server that complies with the
EDNS(0) specification <xref target="RFC6891" format="default" sectionFormat=
"of" derivedContent="RFC6891"/> will
silently ignore the unrecognized option and answer the request as a normal
DNS query without establishing any long-lived state and without
returning an LLQ option in its response. If a DNS query containing an LLQ
option is sent to a server that does not implement EDNS(0) at all, the
server may silently ignore the EDNS(0) OPT pseudo‑RR or it may
return a nonzero RCODE. However, in practice, this issue is mostly
theoretical, since having a zone's _dns‑llq._udp.&lt;zone&gt; SRV
record target a host that does not implement LLQ is a configuration error.
</t>
<t pn="section-3-2">
Note that this protocol is designed for data set sizes of a few dozen
resource records at most and change rates no more than once every 10
seconds on average. Data sets that frequently
exceed a single IP packet, or that experience a rapid change rate, may
have
undesirable performance implications.
</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.1
">
<name slugifiedName="name-assigned-numbers">Assigned Numbers</name>
<t pn="section-3.1-1">
This section describes constants used in this document.
</t>
<ul empty="true" bare="false" spacing="normal" pn="section-3.1-2">
<li pn="section-3.1-2.1">
<t pn="section-3.1-2.1.1">EDNS(0) OPTION‑CODE (recorded with IANA):<
/t>
<ul empty="true" bare="false" spacing="normal" pn="section-3.1-2.1.2
">
<li pn="section-3.1-2.1.2.1">
<dl indent="18" newline="false" spacing="normal" pn="section-3.1
-2.1.2.1.1">
<dt pn="section-3.1-2.1.2.1.1.1">LLQ
</dt>
<dd pn="section-3.1-2.1.2.1.1.2">1
</dd>
</dl>
</li>
</ul>
</li>
<li pn="section-3.1-2.2">
LLQ‑PORT 5352 (recorded with IANA)
</li>
<li pn="section-3.1-2.3">
<t pn="section-3.1-2.3.1">LLQ Opcodes (specific to this LLQ EDNS(0)
Option):</t>
<ul empty="true" bare="false" spacing="normal" pn="section-3.1-2.3.2
">
<li pn="section-3.1-2.3.2.1">
<dl indent="18" spacing="compact" newline="false" pn="section-3.
1-2.3.2.1.1">
<dt pn="section-3.1-2.3.2.1.1.1">LLQ‑SETUP
</dt>
<dd pn="section-3.1-2.3.2.1.1.2">1
</dd>
<dt pn="section-3.1-2.3.2.1.1.3">LLQ‑REFRESH
</dt>
<dd pn="section-3.1-2.3.2.1.1.4">2
</dd>
<dt pn="section-3.1-2.3.2.1.1.5">LLQ‑EVENT
</dt>
<dd pn="section-3.1-2.3.2.1.1.6">3
</dd>
</dl>
</li>
</ul>
</li>
<li pn="section-3.1-2.4">
<t pn="section-3.1-2.4.1">LLQ Error Codes (specific to this LLQ EDNS
(0) Option):</t>
<ul empty="true" bare="false" spacing="normal" pn="section-3.1-2.4.2
">
<li pn="section-3.1-2.4.2.1">
<dl indent="18" spacing="compact" newline="false" pn="section-3.
1-2.4.2.1.1">
<dt pn="section-3.1-2.4.2.1.1.1">
NO-ERROR
</dt>
<dd pn="section-3.1-2.4.2.1.1.2">0
</dd>
<dt pn="section-3.1-2.4.2.1.1.3">
SERV-FULL
</dt>
<dd pn="section-3.1-2.4.2.1.1.4">1
</dd>
<dt pn="section-3.1-2.4.2.1.1.5">
STATIC
</dt>
<dd pn="section-3.1-2.4.2.1.1.6">2
</dd>
<dt pn="section-3.1-2.4.2.1.1.7">
FORMAT-ERR
</dt>
<dd pn="section-3.1-2.4.2.1.1.8">3
</dd>
<dt pn="section-3.1-2.4.2.1.1.9">
NO-SUCH-LLQ
</dt>
<dd pn="section-3.1-2.4.2.1.1.10">4
</dd>
<dt pn="section-3.1-2.4.2.1.1.11">
BAD-VERS
</dt>
<dd pn="section-3.1-2.4.2.1.1.12">5
</dd>
<dt pn="section-3.1-2.4.2.1.1.13">
UNKNOWN-ERR
</dt>
<dd pn="section-3.1-2.4.2.1.1.14">6
</dd>
</dl>
</li>
</ul>
</li>
</ul>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.2
">
<name slugifiedName="name-opt-rr-format">Opt-RR Format</name>
<t pn="section-3.2-1">
As required by the EDNS(0) specification <xref target="RFC6891" format="defa
ult" sectionFormat="of" derivedContent="RFC6891"/>,
all OPT pseudo‑RRs used in LLQs are formatted as follows:
</t>
<table anchor="OPT-RRs" align="center" pn="table-1">
<name slugifiedName="name-opt-rrs-used-in-llqs">OPT-RRs Used in LLQs</
name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Field Name</th>
<th align="left" colspan="1" rowspan="1">Field Type</th>
<th align="left" colspan="1" rowspan="1">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">NAME</td>
<td align="left" colspan="1" rowspan="1">domain name</td>
<td align="left" colspan="1" rowspan="1">MUST be 0 (root domain)</
td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">TYPE</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">OPT (41)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">CLASS</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">0*</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">TTL</td>
<td align="left" colspan="1" rowspan="1">u_int32_t</td>
<td align="left" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">RDLEN</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">length of all RDATA</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">RDATA</td>
<td align="left" colspan="1" rowspan="1">octet stream</td>
<td align="left" colspan="1" rowspan="1">(see below)</td>
</tr>
</tbody>
</table>
<t pn="section-3.2-3">
* The CLASS field indicates, as per the EDNS(0) specification <xref target="
RFC6891" format="default" sectionFormat="of" derivedContent="RFC6891"/>, the sen
der's UDP payload
size. However, clients and servers are not required to determine their
reassembly buffer size, path MTU, etc., to support LLQ. Thus, the sender
of
an LLQ Request or Response <bcp14>MAY</bcp14> set the CLASS field to 0.
The recipient <bcp14>MUST</bcp14> ignore the class field if it is set to
0.
</t>
<t pn="section-3.2-4">
The RDATA of an EDNS(0) OPT pseudo‑RR consists of zero or more
options
of the form { OPTION‑CODE, OPTION‑LENGTH, OPTION‑DATA }
packed together,
with the RDLEN field set accordingly to indicate the total size.
An LLQ OPTION is illustrated below.
An EDNS(0) OPT pseudo‑RR may contain zero or more LLQ OPTIONS in
addition
to zero or more other EDNS(0) options.
</t>
<table anchor="LLQ-OPT-FORMAT" align="center" pn="table-2">
<name slugifiedName="name-llq-option">LLQ OPTION</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Field Name</th>
<th align="left" colspan="1" rowspan="1">Field Type</th>
<th align="left" colspan="1" rowspan="1">Description</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">OPTION-CODE</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">LLQ (1)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">OPTION-LENGTH</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">Length of following field
s (18)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-VERSION</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">Version of LLQ protocol i
mplemented</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-OPCODE</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">Identifies LLQ operation<
/td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-ERROR</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">Identifies LLQ errors</td
>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-ID</td>
<td align="left" colspan="1" rowspan="1">u_int64_t</td>
<td align="left" colspan="1" rowspan="1">Identifier for an LLQ</td
>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-LEASE</td>
<td align="left" colspan="1" rowspan="1">u_int32_t</td>
<td align="left" colspan="1" rowspan="1">Requested or granted life
of LLQ, in seconds</td>
</tr>
</tbody>
</table>
<t pn="section-3.2-6">
The size and meaning of the OPTION‑CODE and OPTION‑LENGTH fields
are as described in the EDNS(0) specification <xref target="RFC6891" format="
default" sectionFormat="of" derivedContent="RFC6891"/>. The remainder of the fi
elds comprise the
OPTION‑DATA of the EDNS(0) LLQ OPTION. Since for LLQ the
OPTION‑DATA is a
fixed size, in EDNS(0) LLQ OPTIONS the OPTION‑LENGTH field always has
the value 18.
</t>
<t pn="section-3.2-7">
In keeping with Internet convention, all multi-byte numeric quantities
(u_int16_t, u_int32_t, and u_int64_t)
are represented in big endian byte order (most significant byte first).
</t>
</section>
</section>
<section numbered="true" toc="include" anchor="address-port" removeInRFC="fa
lse" pn="section-4">
<name slugifiedName="name-llq-address-and-port-identi">LLQ Address and Por
t Identification</name>
<t pn="section-4-1">
The client The client
requires a mechanism to determine to which server it should send LLQ operatio requires a mechanism to determine to which server it should send LLQ
ns. operations.
</t> </t>
<t> <t pn="section-4-2">
Additionally, some firewalls block direct communication with a Additionally, some firewalls block direct communication with a name server
name server on port 53 to avoid spoof responses. However, this on port 53 to avoid spoof responses. However, this direct communication is
direct communication is necessary for LLQs. Thus, servers MAY listen necessary for LLQs. Thus, servers <bcp14>MAY</bcp14> listen for LLQs on a
for LLQs on a different port (typically 5352). Clients also therefore need a different port (typically 5352). Clients, therefore, also need a
mechanism to determine to which port to send LLQ operations. mechanism to determine to which port to send LLQ operations.
</t> </t>
<?rfc needLines="20" ?> <t pn="section-4-3">
<t> The client determines the server responsible for a given LLQ much as a
The client determines the server responsible for a given LLQ much as client determines to which server to send a DNS dynamic update. The client
a client determines to which server to send a dynamic update. The begins by sending a standard DNS query for the name of the LLQ, with type
client begins by sending a standard DNS query for the name of the SOA. If the record exists, then the server <bcp14>MUST</bcp14> answer with
LLQ, with type SOA. The server MUST answer with that SOA record in that SOA record in the Answer section. If a record of type SOA with the
the Answer section, if the record exists. The server SHOULD include LLQ name does not exist, then the server <bcp14>SHOULD</bcp14> include an
an SOA record for that name's zone in the Authority section, if the SOA record for that name's zone in the Authority section. For example, a
LLQ name (type SOA) does not exist. For example, a query for query for "_ftp._tcp.example.com" with type SOA, when there is no SOA
"_ftp._tcp.example.com." may return an SOA record named "example.com." in the record with that name, might return an SOA record named "example.com" in
Authority section if there is no SOA record named the Authority section. If the named SOA record does not exist and the
"_ftp._tcp.example.com." If, in this case, the server does not include server fails to include the enclosing SOA record in the Authority section,
the SOA record in the Authority section, the client strips the the client strips the leading label from the name and tries again,
leading label from the name and tries again, repeating until an repeating until an answer is received.
answer is received. </t>
</t> <t pn="section-4-4">
<t> This iterative zone apex discovery algorithm is described in more detail in
This iterative zone apex discovery algorithm is described in more detail the DNS Push Notifications specification <xref target="RFC8765" format="defau
in the <xref target="Push">DNS Push Notifications specification</xref>. lt" sectionFormat="of" derivedContent="RFC8765"/>.
</t> </t>
<t> <t pn="section-4-5">
Upon learning the zone (SOA), the client then constructs and sends an Upon learning the zone apex (SOA), the client then constructs and sends an
SRV query for the name _dns&nbhy;llq._udp.&lt;zone&gt;, SRV query for the name, "_dns‑llq._udp.&lt;zone&gt;",
e.g.,&nbsp;_dns&nbhy;llq._udp.example.com. e.g., "_dns‑llq._udp.example.com".
</t> </t>
<t> <t pn="section-4-6">
A server implementing LLQ MUST answer with an SRV record <xref target="RFC278 An authoritative server for a zone implementing LLQ <bcp14>MUST</bcp14>
2"/> answer with an SRV record <xref target="RFC2782" format="default" sectionForm
at="of" derivedContent="RFC2782"/>
for this name. The SRV RDATA is as follows: for this name. The SRV RDATA is as follows:
</t> </t>
<figure><artwork> <table anchor="SRV-RDATA" align="center" pn="table-3">
PRIORITY typically 0 <name slugifiedName="name-srv-rdata">SRV RDATA</name>
WEIGHT typically 0 <tbody>
PORT typically 53 or 5352 <tr>
TARGET name of server providing LLQs for the requested zone <td align="left" colspan="1" rowspan="1">PRIORITY</td>
</artwork></figure> <td align="left" colspan="1" rowspan="1">typically 0</td>
<t> </tr>
The server SHOULD include its address record(s) in the Additional <tr>
<td align="left" colspan="1" rowspan="1">WEIGHT</td>
<td align="left" colspan="1" rowspan="1">typically 0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">PORT</td>
<td align="left" colspan="1" rowspan="1">typically 53 or 5352</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">TARGET</td>
<td align="left" colspan="1" rowspan="1">name of server providing LL
Qs for the requested zone</td>
</tr>
</tbody>
</table>
<t pn="section-4-8">
The server <bcp14>SHOULD</bcp14> include the address record(s) for the
target host in the Additional
section of the response. section of the response.
</t> </t>
<t> <t pn="section-4-9">
If the server does not include its address record in the Additional If the server does not include the target host's address record(s) in the
section, the client SHOULD query explicitly for the address record Additional
section, the client <bcp14>SHOULD</bcp14> query explicitly for the address
record(s)
with the name of the SRV target. with the name of the SRV target.
</t> </t>
<t> <t pn="section-4-10">
The client MUST send all LLQ requests, refreshes, and acknowledgments The client <bcp14>MUST</bcp14> send all LLQ requests, refreshes, and
to the name server specified in the SRV target, at the address acknowledgments to the name server specified in the SRV target, at the
contained in the address record for that target. Note that the address contained in the address record for that target. Note that the
queries described in this section (including those for SOA and SRV queries described in this section (including those for SOA and SRV records)
records) MAY be sent to an intermediate DNS recursive resolver -- they need n <bcp14>MAY</bcp14> be sent to an intermediate DNS recursive resolver --
ot be they
sent directly to the name server. need not be sent directly to the name server.
</t> </t>
<t> <t pn="section-4-11">
If, on issuing the SRV query, the client receives an NXDOMAIN If, on issuing the SRV query, the client receives a negative
response indicating that the SRV record does not exist, the client response indicating that the SRV record does not exist, the client
SHOULD conclude that the server does not support an LLQ in the <bcp14>SHOULD</bcp14> conclude that the zone does not support LLQ.
requested zone. The client then SHOULD NOT send an LLQ request for The client then <bcp14>SHOULD NOT</bcp14> send an LLQ request for
the desired name, instead utilizing the behavior for LLQ-unaware the desired name, instead utilizing the behavior for LLQ-unaware
servers described in Section 5 "LLQ Setup". servers described in <xref target="llq-setup" format="default" sectionFormat=
</t> "of" derivedContent="Section 5"/>, "<xref target="llq-setup" format="title" sect
<?rfc needLines="20" ?> ionFormat="of" derivedContent="LLQ Setup"/>".
<t> </t>
</t> <t pn="section-4-12">
<t>
Servers should send all messages to the source address and port of Servers should send all messages to the source address and port of
the LLQ setup message received from the client. the LLQ setup message received from the client.
</t> </t>
<?rfc needLines="40" ?> </section>
</section> <section numbered="true" toc="include" anchor="llq-setup" removeInRFC="false
" pn="section-5">
<section title="LLQ Setup"> <name slugifiedName="name-llq-setup">LLQ Setup</name>
<t> <t pn="section-5-1">
An LLQ is initiated by a client, and is completed via a four-way An LLQ is initiated by a client and is completed via a four-way
handshake. This handshake provides resilience to packet loss, handshake. This handshake provides resilience to packet loss,
demonstrates client reachability, and reduces denial of service demonstrates client reachability, and reduces denial-of-service
attack opportunities (see Section 8 "Security Considerations"). attack opportunities (see <xref target="security-considerations" format="defa
</t> ult" sectionFormat="of" derivedContent="Section 8"/>, "<xref target="security-co
<section title="Setup Message Retransmission"> nsiderations" format="title" sectionFormat="of" derivedContent="Security Conside
<t> rations"/>").
LLQ Setup Requests and Responses sent by the client SHOULD be </t>
retransmitted if no acknowledgments are received. The client SHOULD <section numbered="true" toc="include" anchor="setup-message-retransmissio
re&nbhy;try up to two more times (for a total of 3 attempts) before n" removeInRFC="false" pn="section-5.1">
considering the server down or unreachable. The client MUST wait at <name slugifiedName="name-setup-message-retransmissio">Setup Message Ret
ransmission</name>
<t pn="section-5.1-1">
LLQ Setup Requests and Responses sent by the client <bcp14>SHOULD</bcp14>
be
retransmitted if no acknowledgments are received. The client
<bcp14>SHOULD</bcp14>
retry up to two more times (for a total of 3 attempts) before
considering the server down or unreachable. The client <bcp14>MUST</bcp14>
wait at
least 2 seconds before the first retransmission and 4 seconds between least 2 seconds before the first retransmission and 4 seconds between
the first and second retransmissions. The client SHOULD listen for a the first and second retransmissions. The client <bcp14>SHOULD</bcp14>
listen for a
response for at least 8 seconds after the 3rd attempt before response for at least 8 seconds after the 3rd attempt before
considering the server down or unreachable. Upon determining a considering the server down or unreachable. Upon determining a
server to be down, a client MAY periodically attempt to re-initiate server to be down, a client <bcp14>MAY</bcp14> periodically attempt to
an LLQ setup, at a rate of not more than once per hour. re-initiate
</t> an LLQ setup at a rate of not more than once per hour.
</t>
<t> <t pn="section-5.1-2">
Servers MUST NOT re-transmit acknowledgments that do not generate Servers <bcp14>MUST NOT</bcp14> retransmit acknowledgments that do not
responses from the client. Retransmission in setup is client-driven, generate
responses from the client. Retransmission in setup is client driven,
freeing servers from maintaining timers for incomplete LLQ setups. If freeing servers from maintaining timers for incomplete LLQ setups. If
servers receive duplicate messages from clients (perhaps due to the servers receive duplicate messages from clients (perhaps due to the
loss of the server's responses mid-flight), the server MUST re&nbhy;send loss of the server's responses mid-flight), the server <bcp14>MUST</bcp14>
its reply (possibly modifying the LEASE&nbhy;LIFE as described in Section resend
5.2.4 "ACK + Answers"). its reply (possibly modifying the LLQ‑LEASE as described in <xref target="ack
</t> -answers" format="default" sectionFormat="of" derivedContent="Section 5.2.4"/>,
"<xref target="ack-answers" format="title" sectionFormat="of" derivedContent="AC
<t> K + Answers"/>").
Servers MUST NOT garbage collect LLQs that fail to complete the four- </t>
way handshake until the initially granted LEASE&nbhy;LIFE has elapsed. <t pn="section-5.1-3">
</t> Servers <bcp14>MUST NOT</bcp14> garbage collect LLQs that fail to complete
</section> the four-way handshake until the initially granted LLQ‑LEASE has
<section title="LLQ Setup Four-Way Handshake"> elapsed.
<figure><artwork> </t>
The four phases of the handshake include: </section>
<section numbered="true" toc="include" anchor="four-way-handshake" removeI
1) Setup Request client to server, identifies LLQ(s) requested nRFC="false" pn="section-5.2">
<name slugifiedName="name-llq-setup-four-way-handshak">LLQ Setup Four-Wa
2) Setup Challenge server to client, provides error(s) for y Handshake</name>
requested LLQs, and unique identifiers for <t pn="section-5.2-1">The four phases of the handshake include:
the successful requests </t>
<ul empty="true" bare="false" spacing="normal" pn="section-5.2-2">
3) Challenge Response client to server, echoes identifier(s), <li pn="section-5.2-2.1">
demonstrating client's reachability and <dl indent="24" newline="false" spacing="normal" pn="section-5.2-2.1
willingness to participate .1">
<dt pn="section-5.2-2.1.1.1">1) Setup Request
4) ACK + Answers server to client, confirms setup and </dt>
provides initial answers <dd pn="section-5.2-2.1.1.2">client to server, identifies LLQ(s) r
</artwork></figure> equested
<section title="Setup Request"> </dd>
<t> <dt pn="section-5.2-2.1.1.3">2) Setup Challenge
A request for an LLQ is formatted like a standard DNS query, but with </dt>
an OPT RR containing LLQ metadata in its Additional section. LLQ <dd pn="section-5.2-2.1.1.4">server to client, provides
setup requests are identified by the LLQ&nbhy;SETUP opcode and a unique identifiers for successful requested LLQs, and
zero&nbhy;valued LLQ&nbhy;ID. error(s) for unsuccessful requested LLQs.
</t> </dd>
<dt pn="section-5.2-2.1.1.5">3) Challenge Response
<t> </dt>
The request MAY contain multiple questions to set up multiple LLQs. <dd pn="section-5.2-2.1.1.6">client to server, echoes identifier(s
A request consisting of multiple questions MUST contain multiple LLQ ), demonstrating client's
metadata sections, one per question, with metadata sections in the reachability and willingness to participate
</dd>
<dt pn="section-5.2-2.1.1.7">4) ACK + Answers
</dt>
<dd pn="section-5.2-2.1.1.8">server to client, confirms setup and
provides initial answers
</dd>
</dl>
</li>
</ul>
<section numbered="true" toc="include" anchor="setup-request" removeInRF
C="false" pn="section-5.2.1">
<name slugifiedName="name-setup-request">Setup Request</name>
<t pn="section-5.2.1-1">
A request for an LLQ is formatted like a standard DNS query but with
an OPT pseudo‑RR containing LLQ metadata in its Additional
section. LLQ
Setup Requests are identified by the LLQ‑SETUP opcode and a
zero‑valued LLQ‑ID.
</t>
<t pn="section-5.2.1-2">
The request <bcp14>MAY</bcp14> contain multiple questions to set up
multiple LLQs.
A Setup Request consisting of multiple questions <bcp14>MUST</bcp14>
contain multiple LLQ
OPTIONS, one per question, with the LLQ OPTIONS in the
same order as the questions they correspond to (i.e., the first same order as the questions they correspond to (i.e., the first
metadata section corresponds to the first question, the second LLQ OPTION corresponds to the first question, the second
metadata section corresponds to the second question, etc.) If LLQ OPTION corresponds to the second question, etc.). If
requesting multiple LLQs, clients SHOULD request the same LEASE&nbhy;LIFE requesting multiple LLQs, clients <bcp14>SHOULD</bcp14> request the same
for each LLQ. Requests over UDP MUST NOT contain multiple questions LLQ‑LEASE
if doing so would cause the message to not fit in a single packet. for each LLQ. Requests over UDP <bcp14>MUST NOT</bcp14> contain multiple
</t> questions
if doing so would cause the message to exceed a single IP packet.
<t> </t>
A client MUST NOT request multiple identical LLQs (i.e., containing <t pn="section-5.2.1-3">
A client <bcp14>MUST NOT</bcp14> request multiple identical LLQs (i.e.,
containing
the same qname/type/class) from the same source IP address and port. the same qname/type/class) from the same source IP address and port.
This requirement is to avoid unnecessary load on servers. This requirement is to avoid unnecessary load on servers.
In the case of multiple independent client implementations that In the case of multiple independent client implementations that
may run on the same device without knowledge of each other, may run on the same device without knowledge of each other,
it is allowable if they by chance send LLQ requests for the same it is allowable if they by chance send LLQ requests for the same
qname/type/class. These independent implementations on the same qname/type/class. These independent implementations on the same
client will be using different source ports. Likewise, client will be using different source ports. Likewise,
to the server, to the server,
multiple independent clients behind the same NAT gateway multiple independent clients behind the same NAT gateway
will appear as if they were will appear as if they were
multiple independent clients using different ports on the same host. multiple independent clients using different ports on the same host,
and this is also allowable.
</t>
<t> </t>
The query MUST NOT be for record type ANY (255), class ANY (255), or <t pn="section-5.2.1-4">
The query <bcp14>MUST NOT</bcp14> be for record type ANY (255), class ANY
(255), or
class NONE (0). class NONE (0).
</t> </t>
<table anchor="OPT-RR-LLQ" align="center" pn="table-4">
<t> <name slugifiedName="name-setup-request-llq-option-fo">Setup Request
Setup Request OPT&nbhy;RR LLQ Metadata Format: LLQ OPTION Format</name>
</t> <thead>
<tr>
<figure><artwork> <th align="left" colspan="1" rowspan="1">Field Name</th>
Field Name Field Type Description <th align="left" colspan="1" rowspan="1">Field Type</th>
OPTION-CODE u_int16_t LLQ (1) <th align="left" colspan="1" rowspan="1">Description</th>
OPTION-LENGTH u_int16_t Length of following fields (18) </tr>
VERSION u_int16_t Version of LLQ protocol implemented </thead>
by requester (1) <tbody>
LLQ-OPCODE u_int16_t LLQ-SETUP (1) <tr>
ERROR-CODE u_int16_t NOERROR (0) <td align="left" colspan="1" rowspan="1">OPTION-CODE</td>
LLQ-ID u_int64_t 0 <td align="left" colspan="1" rowspan="1">u_int16_t</td>
LEASE-LIFE u_int32_t Desired life of LLQ request <td align="left" colspan="1" rowspan="1">LLQ (1)</td>
</tr>
These fields MUST be repeated once for each additional query in the <tr>
<td align="left" colspan="1" rowspan="1">OPTION-LENGTH</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">Length of following fie
lds (18)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-VERSION</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">Version of LLQ protocol
implemented by requester (1)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-OPCODE</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">LLQ-SETUP (1)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-ERROR</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">NO-ERROR (0)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-ID</td>
<td align="left" colspan="1" rowspan="1">u_int64_t</td>
<td align="left" colspan="1" rowspan="1">0</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-LEASE</td>
<td align="left" colspan="1" rowspan="1">u_int32_t</td>
<td align="left" colspan="1" rowspan="1">Desired life of LLQ req
uest</td>
</tr>
</tbody>
</table>
<t pn="section-5.2.1-6">The Setup Request LLQ OPTION <bcp14>MUST</bcp1
4> be repeated once for each
additional query in the
Question section. Question section.
</artwork></figure> </t>
<?rfc needLines="40" ?> </section>
</section> <section numbered="true" toc="include" anchor="setup-challenge" removeIn
RFC="false" pn="section-5.2.2">
<section title="Setup Challenge"> <name slugifiedName="name-setup-challenge">Setup Challenge</name>
<t> <t pn="section-5.2.2-1">
Upon receiving an LLQ Setup Request, a server implementing LLQs will Upon receiving an LLQ Setup Request, a server implementing LLQs will
send a Setup Challenge to the requester (client). An LLQ Setup send a Setup Challenge to the requester (client). An LLQ Setup
Challenge is a DNS Response, with the DNS message ID matching that of Challenge is a DNS response, with the DNS message ID matching that of
the request, and with all questions contained in the request present the Setup Request, and with all questions contained in the Setup Request
present
in the Question section of the response. Additionally, the in the Question section of the response. Additionally, the
challenge contains a single OPT&nbhy;RR with an LLQ metadata section for challenge contains a single OPT pseudo‑RR with an LLQ OPTION for
each LLQ request, indicating the success or failure of each request. each LLQ request, indicating the success or failure of each request.
Metadata sections MUST be in the same order as the questions they The LLQ OPTIONS <bcp14>MUST</bcp14> be in the same order as the questions
correspond to. Note that in a request containing multiple they
questions some LLQs may succeed, while others may fail. correspond to. Note that in a Setup Request containing multiple
</t> questions, some LLQs may succeed while others may fail.
</t>
<t> <table anchor="CHALLENGE-OPT-RR-DATA" align="center" pn="table-5">
Setup Challenge OPT&nbhy;RR RDATA Format: <name slugifiedName="name-setup-challenge-llq-option-">Setup Challen
</t> ge LLQ OPTION Format</name>
<thead>
<figure><artwork> <tr>
Field Name Field Type Description <th align="left" colspan="1" rowspan="1">Field Name</th>
OPTION-CODE u_int16_t LLQ (1) <th align="left" colspan="1" rowspan="1">Field Type</th>
OPTION-LENGTH u_int16_t Length of following fields (18) <th align="left" colspan="1" rowspan="1">Description</th>
VERSION u_int16_t Version of LLQ protocol implemented </tr>
in server (1) </thead>
LLQ-OPCODE u_int16_t LLQ-SETUP (1) <tbody>
ERROR-CODE u_int16_t [As Appropriate] <tr>
LLQ-ID u_int64_t [As Appropriate] <td align="left" colspan="1" rowspan="1">OPTION-CODE</td>
LEASE-LIFE u_int32_t [As Appropriate] <td align="left" colspan="1" rowspan="1">u_int16_t</td>
</artwork></figure> <td align="left" colspan="1" rowspan="1">LLQ (1)</td>
</tr>
<t> <tr>
These fields MUST be repeated once for each query in the Questions <td align="left" colspan="1" rowspan="1">OPTION-LENGTH</td>
section of the Setup Request. <td align="left" colspan="1" rowspan="1">u_int16_t</td>
</t> <td align="left" colspan="1" rowspan="1">Length of following fie
lds (18)</td>
<?rfc needLines="40" ?> </tr>
<t> <tr>
LLQ Metadata field descriptions: <td align="left" colspan="1" rowspan="1">LLQ-VERSION</td>
</t> <td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">Version of LLQ protocol
<figure><artwork> implemented in server (1)</td>
ERROR-CODE: Possible values include: </tr>
<tr>
NO-ERROR: The LLQ Setup Request was successful. <td align="left" colspan="1" rowspan="1">LLQ-OPCODE</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
FORMAT-ERR: The LLQ was improperly formatted. Note that if the <td align="left" colspan="1" rowspan="1">LLQ-SETUP (1)</td>
rest of the DNS message is properly formatted, the </tr>
DNS header error code MUST NOT include a format error <tr>
code, as this would cause confusion between a server <td align="left" colspan="1" rowspan="1">LLQ-ERROR</td>
that does not understand the LLQ format, and a client <td align="left" colspan="1" rowspan="1">u_int16_t</td>
that sends malformed LLQs. <td align="left" colspan="1" rowspan="1">[As Appropriate]</td>
</tr>
SERV-FULL: The server cannot grant the LLQ request because it is <tr>
overloaded, or the request exceeds the server's rate <td align="left" colspan="1" rowspan="1">LLQ-ID</td>
limit (see Section 8 "Security Considerations"). <td align="left" colspan="1" rowspan="1">u_int64_t</td>
Upon returning this error, the server MUST include <td align="left" colspan="1" rowspan="1">[As Appropriate]</td>
in the LEASE-LIFE field a time interval, in seconds, </tr>
after which the client may re-try the LLQ Setup. <tr>
<td align="left" colspan="1" rowspan="1">LLQ-LEASE</td>
STATIC: The data for this name and type is not expected to <td align="left" colspan="1" rowspan="1">u_int32_t</td>
change frequently, and the server therefore does not <td align="left" colspan="1" rowspan="1">[As Appropriate]</td>
support the requested LLQ. The client MUST NOT poll </tr>
for this name and type, nor should it re-try the LLQ </tbody>
Setup, and should instead honor the normal resource </table>
record TTLs returned. <t pn="section-5.2.2-3">
The Setup Challenge LLQ OPTION <bcp14>MUST</bcp14> be repeated once for
BAD-VERS: The protocol version specified in the client's each query in the Questions
request is not supported by the server. section of the Setup Challenge.
Further details for LLQ‑ERROR, LLQ‑ID and LLQ‑LEASE are
UNKNOWN-ERR: The LLQ was not granted for an unknown reason given below.
</artwork></figure> </t>
<t pn="section-5.2.2-4">
<?rfc needLines="40" ?> LLQ‑ERROR:
<t> </t>
LLQ&nbhy;ID: On success, a random number generated by the server that is <ul empty="true" bare="false" spacing="normal" pn="section-5.2.2-5">
unique for the requested name/type/class. The LLQ&nbhy;ID SHOULD be an <li pn="section-5.2.2-5.1">
unpredictable random number. A possible method of allocating LLQ&nbhy;IDs <dl indent="18" newline="false" spacing="normal" pn="section-5.2.2
with minimal bookkeeping would be to store the time, in seconds since -5.1.1">
the Epoch, in the high 32 bits of the field, and a cryptographically <dt pn="section-5.2.2-5.1.1.1">NO-ERROR:
generated 32-bit random integer in the low 32 bits. </dt>
</t> <dd pn="section-5.2.2-5.1.1.2">The LLQ Setup Request was success
ful.
<t> </dd>
On error, the LLQ&nbhy;ID is set to 0. <dt pn="section-5.2.2-5.1.1.3">FORMAT-ERR:
</t> </dt>
<dd pn="section-5.2.2-5.1.1.4">The LLQ was improperly formatted.
<t> Note that if the rest of the DNS
LEASE&nbhy;LIFE: On success, the actual life of the LLQ, in seconds. message is properly formatted, the DNS header error code <bcp14>MUST NOT</bcp14>
Value may be greater than, less than, or equal to the value requested include a format error code, since to do so would cause ambiguity
by the client, as per the server administrator's policy. The server between the case where a client sends a valid LLQ Setup Request to a server
MAY discard the LLQ after this LEASE&nbhy;LIFE expires unless the LLQ has that does not understand LLQ and the case where a client sends a malformed
been renewed by the client (see Section 7 "LLQ Lease-Life Expiration"). LLQ Setup Request to a server that does understand LLQ.
The server MUST NOT generate events (see Section 6 "Event Responses") </dd>
for expired LLQs. <dt pn="section-5.2.2-5.1.1.5">SERV-FULL:
</t> </dt>
<dd pn="section-5.2.2-5.1.1.6">The server cannot grant the LLQ r
<t> equest because it is overloaded or the
On SERV&nbhy;FULL error, LEASE&nbhy;LIFE MUST be set to a time interval, in request exceeds the server's rate limit (see <xref target="security-consideratio
seconds, after which the client may re&nbhy;try the LLQ Setup. ns" format="default" sectionFormat="of" derivedContent="Section 8"/>, <xref targ
</t> et="security-considerations" format="title" sectionFormat="of" derivedContent="S
ecurity Considerations"/>). Upon
<t> returning this error, the server <bcp14>MUST</bcp14> include in the LLQ-LEASE
On other errors, the LEASE&nbhy;LIFE MUST be set to 0. field a time interval, in seconds, after which the client may retry the LLQ
</t> Setup.
<?rfc needLines="40" ?> </dd>
</section> <dt pn="section-5.2.2-5.1.1.7">STATIC:
</dt>
<section title="Challenge Response"> <dd pn="section-5.2.2-5.1.1.8">The data for this name and type i
<t> s not expected to change frequently, and
the server, therefore, does not support the requested LLQ. The client
<bcp14>MUST</bcp14> honor the resource record TTLs returned and
<bcp14>MUST NOT</bcp14> poll sooner than indicated by those TTLs,
nor should it retry the LLQ Setup for this name and type.
</dd>
<dt pn="section-5.2.2-5.1.1.9">BAD-VERS:
</dt>
<dd pn="section-5.2.2-5.1.1.10">The protocol version specified i
n the client's Setup Request is not
supported by
the server.
</dd>
<dt pn="section-5.2.2-5.1.1.11">UNKNOWN-ERR:
</dt>
<dd pn="section-5.2.2-5.1.1.12">The LLQ was not granted for some
other reason not covered by the preceding
error code values.
</dd>
</dl>
</li>
</ul>
<dl indent="18" newline="false" spacing="normal" pn="section-5.2.2-6">
<dt pn="section-5.2.2-6.1">LLQ‑ID:
</dt>
<dd pn="section-5.2.2-6.2">On success, a random number generated by
the server that is unique on the
server for the
requested name/type/class. The LLQ‑ID <bcp14>SHOULD</bcp14> be an
unpredictable random number. A possible method of allocating LLQ‑IDs with
minimal bookkeeping would be to store the time, in seconds since the Epoch, in
the high 32 bits of the field, and a cryptographically generated 32-bit random
integer in the low 32 bits.
</dd>
<dt pn="section-5.2.2-6.3">
</dt>
<dd pn="section-5.2.2-6.4">
On error, the LLQ‑ID is set to 0.
</dd>
<dt pn="section-5.2.2-6.5">LLQ‑LEASE:
</dt>
<dd pn="section-5.2.2-6.6">On success, the actual life of the LLQ, i
n seconds. Value may be greater
than, less than, or equal to the value requested by the client, as per the
server administrator's policy. The server <bcp14>MAY</bcp14> discard the LLQ
after this LLQ‑LEASE expires unless the LLQ has been renewed by the
client (see <xref target="LLQ-LLE" format="default" sectionFormat="of" derivedCo
ntent="Section 7"/>, "<xref target="LLQ-LLE" format="title" sectionFormat="of" d
erivedContent="LLQ Lease-Life Expiration"/>"). The server <bcp14>MUST NOT</bcp1
4> generate events (see
<xref target="event-responses" format="default" sectionFormat="of" derivedConten
t="Section 6"/>, "<xref target="event-responses" format="title" sectionFormat="o
f" derivedContent="Event Responses"/>") for expired LLQs.
</dd>
<dt pn="section-5.2.2-6.7"/>
<dd pn="section-5.2.2-6.8">
On SERV‑FULL error, LLQ‑LEASE <bcp14>MUST</bcp14> be set to a time
interval, in seconds, after which the client may retry the LLQ Setup.
</dd>
<dt pn="section-5.2.2-6.9">
</dt>
<dd pn="section-5.2.2-6.10">
On other errors, the LLQ‑LEASE <bcp14>MUST</bcp14> be set to 0.
</dd>
</dl>
</section>
<section numbered="true" toc="include" anchor="challenge-response" remov
eInRFC="false" pn="section-5.2.3">
<name slugifiedName="name-challenge-response">Challenge Response</name
>
<t pn="section-5.2.3-1">
Upon issuing a Setup Request, a client listens for a Setup Challenge Upon issuing a Setup Request, a client listens for a Setup Challenge
(5.2.2), re-transmitting the request as necessary (5.1). After (<xref target="setup-challenge" format="default" sectionFormat="of" derivedCo
receiving a successful Challenge, the client SHOULD send a Challenge ntent="Section 5.2.2"/>) retransmitting the Setup Request as
necessary
(<xref target="setup-message-retransmission" format="default" sectionFormat="
of" derivedContent="Section 5.1"/>). After
receiving a successful Setup Challenge, the client <bcp14>SHOULD</bcp14>
send a Challenge
Response to the server. This Challenge Response is a DNS request Response to the server. This Challenge Response is a DNS request
with questions from the request and challenge, and a single OPT&nbhy;RR in with questions as in the Setup Request and Setup Challenge, and a single
the Additional section, with the OPT&nbhy;RR RDATA identical to the OPT pseudo‑RR in
OPT&nbhy;RR RDATA contained in the Setup Challenge (i.e., echoing, for the Additional section, with the LLQ OPTIONS corresponding to the
each set of fields, the random LLQ&nbhy;ID and the granted lease life). If LLQ OPTIONS contained in the Setup Challenge (i.e., echoing, for
the challenge response contains multiple questions, the first each LLQ OPTION, the random LLQ‑ID and the granted LLQ‑LEASE). If
question MUST correspond to the first OPT&nbhy;RR RDATA tuple, etc. the Challenge Response contains multiple questions, the first
</t> question <bcp14>MUST</bcp14> correspond to the first LLQ OPTION, etc.
</t>
<t> <t pn="section-5.2.3-2">
If the Setup Request fails with a STATIC error, the client MUST NOT If the Setup Request for a particular LLQ fails with a STATIC error, the
poll the server. The client SHOULD honor the resource record TTLs client <bcp14>MUST NOT</bcp14>
poll the server for that LLQ. The client <bcp14>SHOULD</bcp14> honor the
resource record TTLs
contained in the response. contained in the response.
</t> </t>
<t pn="section-5.2.3-3">
<t> If a Setup Request fails with a SERV‑FULL error, the client
If the Setup Request fails with a SERV&nbhy;FULL error, the client MAY <bcp14>MAY</bcp14>
re&nbhy;try the LLQ Setup Request (5.2.1) after the time indicated in the retry the LLQ Setup Request (<xref target="setup-request" format="default" se
LEASE&nbhy;LIFE field. ctionFormat="of" derivedContent="Section 5.2.1"/>) after the time
</t> indicated in the
LLQ‑LEASE field.
<t> </t>
<t pn="section-5.2.3-4">
If the Setup Request fails with an error other than STATIC or If the Setup Request fails with an error other than STATIC or
SERV&nbhy;FULL, or the server is determined not to support LLQ SERV‑FULL, or the server is determined not to support LLQ
(i.e., the client receives a DNS response with a nonzero RCODE, (i.e., the client receives a DNS response with a nonzero RCODE,
or a DNS response containing no LLQ option), the or a DNS response containing no LLQ option), the
client MAY poll the server periodically with standard DNS queries, client <bcp14>MAY</bcp14> poll the server periodically with standard DNS
inferring Add and Remove events (see Section 6 "Event Responses") queries,
inferring Add and Remove Events (see <xref target="event-responses" format="d
efault" sectionFormat="of" derivedContent="Section 6"/>,
"Event Responses")
by comparing answers to these queries. The client by comparing answers to these queries. The client
SHOULD NOT poll more than once every 15 minutes for a given query. <bcp14>SHOULD NOT</bcp14> poll more than once every 15 minutes for a given
The client MUST NOT poll if it receives a STATIC error code in the query.
The client <bcp14>MUST NOT</bcp14> poll if it receives a STATIC error code
in the
acknowledgment. acknowledgment.
</t> </t>
<?rfc needLines="40" ?> </section>
</section> <section numbered="true" toc="include" anchor="ack-answers" removeInRFC=
"false" pn="section-5.2.4">
<section title="ACK + Answers"> <name slugifiedName="name-ack-answers">ACK + Answers</name>
<t> <t pn="section-5.2.4-1">
Upon receiving a correct Challenge Response, a server MUST return an Upon receiving a correct Challenge Response, a server <bcp14>MUST</bcp14>
return an
acknowledgment, completing the LLQ setup, and provide all current acknowledgment, completing the LLQ setup, and provide all current
answers to the question(s). answers to the question(s).
</t> </t>
<t pn="section-5.2.4-2">
<t>
To acknowledge a successful Challenge Response, i.e., a Challenge To acknowledge a successful Challenge Response, i.e., a Challenge
Response in which the LLQ&nbhy;ID and LEASE&nbhy;LIFE echoed by the client Response in which the LLQ‑ID and LLQ‑LEASE echoed by the client
match the values issued by the server, the server MUST send a DNS match the values issued by the server, the server <bcp14>MUST</bcp14> send
a DNS
response containing all available answers to the question(s) response containing all available answers to the question(s)
contained in the original Setup Request, along with all additional contained in the original Setup Request, along with all additional
resource records appropriate for those answers in the Additional resource records appropriate for those answers in the Additional
section. The Additional section also contains an OPT&nbhy;RR formatted as section. The Additional section also contains LLQ OPTIONS formatted as
follows: follows:
</t> </t>
<table anchor="SUCCESSFUL-ACK-ANSWERS-OPT-RR-RDATA" align="center" pn=
<t> "table-6">
Successful ACK + Answers OPT&nbhy;RR RDATA Format: <name slugifiedName="name-successful-ack-answers-llq-">Successful AC
</t> K + Answers LLQ OPTION Format</name>
<thead>
<figure><artwork> <tr>
Field Name Field Type Description <th align="left" colspan="1" rowspan="1">Field Name</th>
OPTION-CODE u_int16_t LLQ <th align="left" colspan="1" rowspan="1">Field Type</th>
OPTION-LENGTH u_int16_t Length of following fields, as <th align="left" colspan="1" rowspan="1">Description</th>
appropriate </tr>
VERSION u_int16_t Version of LLQ protocol implemented </thead>
in server <tbody>
LLQ-OPCODE u_int16_t LLQ-SETUP (1) <tr>
ERROR-CODE u_int16_t NO-ERROR <td align="left" colspan="1" rowspan="1">OPTION-CODE</td>
LLQ-ID u_int64_t Originally granted ID, echoed in <td align="left" colspan="1" rowspan="1">u_int16_t</td>
client's Response <td align="left" colspan="1" rowspan="1">LLQ (1)</td>
LEASE-LIFE u_int32_t Remaining life of LLQ, in seconds </tr>
</artwork></figure> <tr>
<td align="left" colspan="1" rowspan="1">OPTION-LENGTH</td>
<t> <td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">Length of following fie
lds (18)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-VERSION</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">Version of LLQ protocol
implemented in server (1)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-OPCODE</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">LLQ-SETUP (1)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-ERROR</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">NO-ERROR (0)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-ID</td>
<td align="left" colspan="1" rowspan="1">u_int64_t</td>
<td align="left" colspan="1" rowspan="1">Originally granted ID,
echoed in client's Response</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-LEASE</td>
<td align="left" colspan="1" rowspan="1">u_int32_t</td>
<td align="left" colspan="1" rowspan="1">Remaining life of LLQ,
in seconds</td>
</tr>
</tbody>
</table>
<t pn="section-5.2.4-4">
If there is a significant delay in receiving a Challenge Response, or If there is a significant delay in receiving a Challenge Response, or
multiple Challenge Responses are issued (possibly because they were lost multiple Challenge Responses are issued (possibly because they were lost
en route to the client, causing the client to re&nbhy;send the Challenge en route to the client, causing the client to resend the Challenge
Response), the server MAY decrement the LEASE&nbhy;LIFE by the time Response), the server <bcp14>MAY</bcp14> decrement the LLQ‑LEASE by
the time
elapsed since the Setup Challenge was initially issued. elapsed since the Setup Challenge was initially issued.
</t> </t>
<t pn="section-5.2.4-5">
<t>
If the setup is completed over UDP and all initially available If the setup is completed over UDP and all initially available
answers to the question(s), additional records, and the OPT&nbhy;RR do not answers to the question(s), additional records, and the OPT pseudo‑RR
fit in a single packet, some or all additional records (excluding the do not
OPT&nbhy;RR) MUST be omitted. If, after omission of all additional fit in a single IP packet, some or all additional records (excluding the
OPT pseudo‑RR) <bcp14>MUST</bcp14> be omitted. If, after omission of
all additional
records, the answers still do not fit in a single message, answers records, the answers still do not fit in a single message, answers
MUST be removed until the message fits in a single packet. These <bcp14>MUST</bcp14> be removed until the message fits in a single IP
answers not delivered in the ACK + Answers MUST be delivered packet. These
without undue delay to the client via Add Events (Section 6 "Event Responses" answers not delivered in the ACK + Answers <bcp14>MUST</bcp14> be delivered
). without undue delay to the client via Add Events (<xref target="event-respons
</t> es" format="default" sectionFormat="of" derivedContent="Section 6"/>, "<xref tar
</section> get="event-responses" format="title" sectionFormat="of" derivedContent="Event Re
</section> sponses"/>").
<section title="Resource Record TTLs"> </t>
<t> </section>
</section>
<section numbered="true" toc="include" anchor="resource-record-ttls" remov
eInRFC="false" pn="section-5.3">
<name slugifiedName="name-resource-record-ttls">Resource Record TTLs</na
me>
<t pn="section-5.3-1">
The TTLs of resource records contained in answers to successful LLQs The TTLs of resource records contained in answers to successful LLQs
SHOULD be ignored by the client. The client MAY cache LLQ answers <bcp14>SHOULD</bcp14> be ignored by the client. The client
until the client receives a gratuitous announcement (see Section 6 <bcp14>MAY</bcp14> cache LLQ answers until the client receives a gratuitous
"Event Responses") indicating that the answer to the LLQ has changed. announcement (see <xref target="event-responses" format="default" sectionForm
The client SHOULD NOT cache answers after the LLQs LEASE&nbhy;LIFE expires at="of" derivedContent="Section 6"/>, "<xref target="event-responses" format="ti
without being refreshed (see Section 7 "LLQ Lease-Life Expiration"). tle" sectionFormat="of" derivedContent="Event Responses"/>")
If an LLQ request fails, the client SHOULD NOT cache answers for a indicating that the answer to the LLQ has changed. The client
period longer than the client's polling interval. <bcp14>SHOULD NOT</bcp14> cache answers after the LLQs LLQ‑LEASE
</t> expires without being refreshed (see <xref target="LLQ-LLE" format="default"
sectionFormat="of" derivedContent="Section 7"/>, "LLQ
<t> Lease-Life Expiration"). If an LLQ request fails, the client <bcp14>SHOULD N
OT</bcp14> cache answers for a period longer than the client's polling
interval.
</t>
<t pn="section-5.3-2">
Note that resource records intended specifically to be transmitted Note that resource records intended specifically to be transmitted
via LLQs (e.g., DNS Service Discovery resource records) may have via LLQs (e.g., DNS-based Service Discovery resource records) may have
unusually short TTLs. This is because it is assumed that the records unusually short TTLs. This is because it is assumed that the records
may change frequently, and that a client's cache coherence will be may change frequently, and that a client's cache coherence will be
maintained via the LLQ and gratuitous responses. Short TTLs prevent maintained via the LLQ and gratuitous responses. Short TTLs prevent
stale information from residing in intermediate DNS recursive resolvers that stale information from residing in intermediate DNS recursive resolvers
are that are
not LLQ-aware. not LLQ aware.
</t> </t>
<t pn="section-5.3-3">
<t>
TTLs of resource records included in the Additional section of an TTLs of resource records included in the Additional section of an
LLQ response (which do not directly answer the LLQ) SHOULD be honored LLQ response (which do not directly answer the LLQ) <bcp14>SHOULD</bcp14>
be honored
by the client. by the client.
</t> </t>
<?rfc needLines="40" ?> </section>
</section> </section>
</section> <section numbered="true" toc="include" anchor="event-responses" removeInRFC=
"false" pn="section-6">
<section title="Event Responses"> <name slugifiedName="name-event-responses">Event Responses</name>
<t> <t pn="section-6-1">
When a change ("event") occurs to a name server's zone, the server When a change ("event") occurs to a name server's zone, the server
MUST check if the new or deleted resource records answer any LLQs. <bcp14>MUST</bcp14> check if the new or deleted resource records answer any
If so, the changes MUST be communicated to the LLQ requesters in LLQs.
If so, the changes <bcp14>MUST</bcp14> be communicated to the LLQ
requesters in
the form of a gratuitous DNS response sent to the client, with the the form of a gratuitous DNS response sent to the client, with the
question(s) being answered in the Question section, and answers to relevant question(s) in the Question section, and the corresponding answers
these questions in the Answer section. The response also includes in the Answer section. The response also includes
an OPT RR in the Additional section. This OPT RR contains, in its an OPT pseudo‑RR in the Additional section. This OPT pseudo‑RR
RDATA, an entry for each LLQ being answered in the message. Entries contains, in its
must include the LLQ&nbhy;ID. This reduces the potential for spoof events RDATA, an LLQ OPTION for each LLQ being answered in the message. Each LLQ
OPTION
must include the LLQ‑ID. This reduces the potential for spoof events
being sent to a client. being sent to a client.
</t> </t>
<table anchor="EVENT-RESPONSE-OPT-RR-RDATA" align="center" pn="table-7">
<t> <name slugifiedName="name-event-response-llq-option-f">Event Response LL
Event Response OPT&nbhy;RR RDATA Format: Q OPTION Format</name>
</t> <thead>
<tr>
<figure><artwork> <th align="left" colspan="1" rowspan="1">Field Name</th>
Field Name Field Type Description <th align="left" colspan="1" rowspan="1">Field Type</th>
OPTION-CODE u_int16_t LLQ (1) <th align="left" colspan="1" rowspan="1">Description</th>
OPTION-LENGTH u_int16_t Length of following fields (18) </tr>
VERSION u_int16_t Version of LLQ protocol implemented </thead>
in server (1) <tbody>
LLQ-OPCODE u_int16_t LLQ-EVENT (3) <tr>
ERROR-CODE u_int16_t 0 <td align="left" colspan="1" rowspan="1">OPTION-CODE</td>
LLQ-ID u_int64_t [As Appropriate] <td align="left" colspan="1" rowspan="1">u_int16_t</td>
LEASE-LIFE u_int32_t 0 <td align="left" colspan="1" rowspan="1">LLQ (1)</td>
</artwork></figure> </tr>
<tr>
<t> <td align="left" colspan="1" rowspan="1">OPTION-LENGTH</td>
Gratuitous responses for a single LLQ MAY be batched, such that <td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">Length of following fields
(18)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-VERSION</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">Version of LLQ protocol imp
lemented in server (1)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-OPCODE</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">LLQ-EVENT (3)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-ERROR</td>
<td align="left" colspan="1" rowspan="1">u_int16_t</td>
<td align="left" colspan="1" rowspan="1">NO-ERROR (0)</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-ID</td>
<td align="left" colspan="1" rowspan="1">u_int64_t</td>
<td align="left" colspan="1" rowspan="1">[As Appropriate]</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">LLQ-LEASE</td>
<td align="left" colspan="1" rowspan="1">u_int32_t</td>
<td align="left" colspan="1" rowspan="1">0</td>
</tr>
</tbody>
</table>
<t pn="section-6-3">
Gratuitous responses for a single LLQ <bcp14>MAY</bcp14> be batched such
that
multiple changes are communicated in a single message. multiple changes are communicated in a single message.
Responses MUST NOT be batched if this would cause a message that Responses <bcp14>MUST NOT</bcp14> be batched if this would cause a message
would otherwise fit in a single packet to be truncated. While that
responses MAY be deferred to provide opportunities for batching, would otherwise fit in a single IP packet to be truncated. While
responses SHOULD NOT be delayed, for purposes of batching, for more responses <bcp14>MAY</bcp14> be deferred to provide opportunities for
batching,
responses <bcp14>SHOULD NOT</bcp14> be delayed, for purposes of batching,
for more
than 30 seconds, as this would cause an unacceptable latency for the than 30 seconds, as this would cause an unacceptable latency for the
client. client.
</t> </t>
<t pn="section-6-4">
<t> After sending a gratuitous response, the server <bcp14>MUST</bcp14> listen
After sending a gratuitous response, the server MUST listen for an for an
acknowledgment from the client. If the client does not respond, the acknowledgment from the client. If the client does not respond, the
server MUST re&nbhy;send the response. The server MUST re&nbhy;send 2 times server <bcp14>MUST</bcp14> resend the response. The server
(for a total of 3 transmissions), after which the server MUST <bcp14>MUST</bcp14> resend two times
(for a total of 3 transmissions), after which the server
<bcp14>MUST</bcp14>
consider the client to be unreachable and delete its LLQ. The server consider the client to be unreachable and delete its LLQ. The server
MUST listen for 2 seconds before re&nbhy;sending the response, 4 more <bcp14>MUST</bcp14> listen for 2 seconds before resending the response, 4
seconds before re&nbhy;sending again, and must wait an additional 8 more
seconds before resending again, and must wait an additional 8
seconds after the 3rd transmission before terminating the LLQ. seconds after the 3rd transmission before terminating the LLQ.
</t> </t>
<t pn="section-6-5">
<t> The DNS message header of the response <bcp14>SHOULD</bcp14> include an
The DNS message header of the response SHOULD include an unpredictable unpredictable
random number in the DNS message ID field, which is to be echoed in random number in the DNS message ID field, which is to be echoed in
the client's acknowledgement. the client's acknowledgment.
</t> </t>
<section title="Add Events"> <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1
<t> ">
Add events occur when a new resource record appears, usually as the <name slugifiedName="name-add-events">Add Events</name>
result of a dynamic update <xref target="RFC2136"/>, that answers an LLQ. Thi <t pn="section-6.1-1">
s Add Events occur when a new resource record appears, usually as the
result of a dynamic update <xref target="RFC2136" format="default" sectionFor
mat="of" derivedContent="RFC2136"/>, that
answers an LLQ. This
record must be sent in the Answer section of the event to the client. record must be sent in the Answer section of the event to the client.
Records that normally accompany this record in responses MAY be Records that normally accompany this record in responses <bcp14>MAY</bcp14>
included in the Additional section, as per truncation restrictions be
included in the Additional section as per truncation restrictions
described above. described above.
</t> </t>
</section> </section>
<section title="Remove Events"> <section numbered="true" toc="include" removeInRFC="false" pn="section-6.2
<t> ">
Remove events occur when a resource record previously sent to a <name slugifiedName="name-remove-events">Remove Events</name>
client, either in an initial response, or in an Add Event, becomes <t pn="section-6.2-1">
Remove Events occur when a resource record previously sent to a
client, either in an initial response or in an Add Event, becomes
invalid (normally as a result of being removed via a dynamic update). invalid (normally as a result of being removed via a dynamic update).
The deleted resource record is sent in the Answer section of the The deleted resource record is sent in the Answer section of the
event to the client. The resource record TTL is set to -1, event to the client. The resource record TTL is set to -1,
indicating that the record has been removed. indicating that the record has been removed.
</t> </t>
</section> </section>
<section title="Gratuitous Response Acknowledgments"> <section numbered="true" toc="include" removeInRFC="false" pn="section-6.3
<t> ">
Upon receiving a gratuitous response ("event"), the client MUST send <name slugifiedName="name-gratuitous-response-acknowl">Gratuitous Respon
se Acknowledgments</name>
<t pn="section-6.3-1">
Upon receiving a gratuitous response ("event"), the client
<bcp14>MUST</bcp14> send
an acknowledgment to the server. This acknowledgment is a DNS an acknowledgment to the server. This acknowledgment is a DNS
response echoing the OPT&nbhy;RR contained in the event, with the message response echoing the OPT pseudo‑RR contained in the event, with the
message
ID of the gratuitous response echoed in the message header. The ID of the gratuitous response echoed in the message header. The
acknowledgment MUST be sent to the source IP address and port from acknowledgment <bcp14>MUST</bcp14> be sent to the source IP address and
port from
which the event originated. which the event originated.
</t> </t>
<?rfc needLines="40" ?> </section>
</section> </section>
</section> <section numbered="true" toc="include" anchor="LLQ-LLE" removeInRFC="false"
pn="section-7">
<section title="LLQ Lease-Life Expiration"> <name slugifiedName="name-llq-lease-life-expiration">LLQ Lease-Life Expira
<t> tion</name>
</t> <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1
<section title="Refresh Request"> ">
<t> <name slugifiedName="name-refresh-request">Refresh Request</name>
If the client desires to maintain the LLQ beyond the duration <t pn="section-7.1-1">
specified in the LEASE&nbhy;LIFE field of the Ack + Answers If the client desires to maintain the LLQ beyond the duration specified in
(5.2), the client MUST send a Refresh Request. A Refresh Request is the LLQ‑LEASE field of the ACK + Answers (<xref target="ack-answers" format="
identical to an LLQ Challenge Response (5.3), but with the LLQ&nbhy;OPCODE default" sectionFormat="of" derivedContent="Section 5.2.4"/>), the client <bcp14
set to LLQ&nbhy;REFRESH. Unlike a Challenge Response, a Refresh Request >MUST</bcp14> send a
returns no answers. Refresh Request. A Refresh Request is identical to an LLQ Challenge
</t> Response (<xref target="challenge-response" format="default" sectionFormat="o
f" derivedContent="Section 5.2.3"/>) but with the LLQ‑OPCODE
<t> set to
The client SHOULD refresh an LLQ when 80% of its lease life has LLQ‑REFRESH. Unlike a Challenge Response, a Refresh Request returns no
answers.
</t>
<t pn="section-7.1-2">
The client <bcp14>SHOULD</bcp14> refresh an LLQ when 80% of its
LLQ‑LEASE has
elapsed. elapsed.
</t> </t>
<t pn="section-7.1-3">
<t>
As a means of reducing network traffic, when constructing refresh As a means of reducing network traffic, when constructing refresh
messages the client SHOULD include all LLQs established with a given messages the client <bcp14>SHOULD</bcp14> include all LLQs established with
a given
server, even those not yet close to expiration. However, at least server, even those not yet close to expiration. However, at least
one LLQ MUST have elapsed at least 80% of its original LEASE&nbhy;LIFE. one LLQ <bcp14>MUST</bcp14> have elapsed at least 80% of its original
The client MUST NOT include additional LLQs if doing so would cause LLQ‑LEASE.
the message to no longer fit in a single packet. In this case, the The client <bcp14>MUST NOT</bcp14> include additional LLQs if doing so
would cause
the message to no longer fit in a single IP packet. In this case, the
LLQs furthest from expiration should be omitted such that the message LLQs furthest from expiration should be omitted such that the message
fits in a single packet. (These LLQs SHOULD be refreshed in a fits in a single IP packet. (These LLQs <bcp14>SHOULD</bcp14> be refreshed
in a
separate message when 80% of one or more of their lease lives have separate message when 80% of one or more of their lease lives have
elapsed.) When refreshing multiple LLQs simultaneously, the message elapsed.) When refreshing multiple LLQs simultaneously, the message
contains multiple questions, and a single OPT&nbhy;RR with multiple LLQ contains multiple questions and a single OPT pseudo‑RR with multiple
metadata sections, one per question, with the metadata sections in LLQ
OPTIONS, one per question, with the LLQ OPTIONS in
the same order as the questions they correspond to. the same order as the questions they correspond to.
</t> </t>
<t pn="section-7.1-4">
<t> The client <bcp14>SHOULD</bcp14> specify the original LLQ‑LEASE
The client SHOULD specify the original lease life granted in the LLQ granted in the LLQ
response as the desired LEASE&nbhy;LIFE in the refresh request. If response as the desired LLQ‑LEASE in the Refresh Request. If
refreshing multiple LLQs simultaneously, the client SHOULD request refreshing multiple LLQs simultaneously, the client <bcp14>SHOULD</bcp14>
the same lease life for all LLQs being refreshed (with the exception request
of termination requests, see below). the same LLQ‑LEASE for all LLQs being refreshed (with the exception
</t> of termination requests; see below).
</t>
<t> <t pn="section-7.1-5">
To terminate an LLQ prior To terminate an LLQ prior
to its scheduled expiration (for instance, when the client terminates to its scheduled expiration (for instance, when the client terminates
a DNS Service Discovery browse operation, or a client is about to go a DNS-based Service Discovery browse operation or when a client is about to g
to sleep or shut down) the client specifies a lease life of 0. o
</t> to sleep or shut down), the client specifies an LLQ‑LEASE value of 0.
</t>
<t> <t pn="section-7.1-6">
The client MUST listen for an acknowledgment from the server. The The client <bcp14>MUST</bcp14> listen for an acknowledgment from the
client MAY re&nbhy;try up to two more times (for a total of 3 attempts) server. The
before considering the server down or unreachable. The client MUST client <bcp14>MAY</bcp14> retry up to two more times (for a total of 3
NOT re&nbhy;try a first time before 90% of the lease life has expired, and attempts)
MUST NOT re&nbhy;try again before 95% of the lease life has expired. If before considering the server down or unreachable. The client <bcp14>MUST NOT
the server is determined to be down, the client MAY periodically </bcp14> retry a first time before 90% of the LLQ‑LEASE has expired
and
<bcp14>MUST NOT</bcp14> retry again before 95% of the LLQ‑LEASE has
expired. If
the server is determined to be down, the client <bcp14>MAY</bcp14>
periodically
attempt to re-establish the LLQ via an LLQ Setup Request message. attempt to re-establish the LLQ via an LLQ Setup Request message.
The client MUST NOT attempt the LLQ Setup Request more than once per The client <bcp14>MUST NOT</bcp14> attempt the LLQ Setup Request more than
once per
hour. hour.
</t> </t>
</section> </section>
<section title="LLQ Refresh Acknowledgment"> <section numbered="true" toc="include" removeInRFC="false" pn="section-7.2
<t> ">
Upon receiving an LLQ Refresh message, a server MUST send an <name slugifiedName="name-llq-refresh-acknowledgment">LLQ Refresh Acknow
ledgment</name>
<t pn="section-7.2-1">
Upon receiving an LLQ Refresh message, a server <bcp14>MUST</bcp14> send an
acknowledgment of the Refresh. This acknowledgment is formatted like acknowledgment of the Refresh. This acknowledgment is formatted like
the Setup ACK described in 5.2.3, but with the following variations: the "ACK + Answers" message described in <xref target="ack-answers" format="d
</t> efault" sectionFormat="of" derivedContent="Section 5.2.4"/>, but
with the following variations:
<t> </t>
The LLQ&nbhy;OPCODE is set to LLQ&nbhy;REFRESH. <ul bare="false" empty="false" spacing="normal" pn="section-7.2-2">
</t> <li pn="section-7.2-2.1">
<t pn="section-7.2-2.1.1">
<t> It contains no answers.
NO&nbhy;SUCH&nbhy;LLQ MUST be returned as an error code if the client attempt </t>
s </li>
<li pn="section-7.2-2.2">
<t pn="section-7.2-2.2.1">
The LLQ‑OPCODE is set to LLQ‑REFRESH.
</t>
</li>
<li pn="section-7.2-2.3">
<t pn="section-7.2-2.3.1">
NO‑SUCH‑LLQ <bcp14>MUST</bcp14> be returned as an error code if
the client attempts
to refresh an expired or non-existent LLQ (as determined by the to refresh an expired or non-existent LLQ (as determined by the
LLQ&nbhy;ID in the request). LLQ‑ID in the request).
</t> </t>
</li>
<t> <li pn="section-7.2-2.4">
The LLQ&nbhy;ID in the acknowledgment is set to the LLQ&nbhy;ID in the reques <t pn="section-7.2-2.4.1">
t. The LLQ‑ID in the acknowledgment is set to the LLQ‑ID in the
</t> request.
<?rfc needLines="40" ?> </t>
</section> </li>
</section> </ul>
</section>
<section title="Security Considerations"> </section>
<t> <section numbered="true" toc="include" anchor="security-considerations" remo
Without care taken in the design of protocols such as this, servers veInRFC="false" pn="section-8">
may be susceptible to denial of service (DOS) attacks, and clients <name slugifiedName="name-security-considerations">Security Considerations
may be subjected to packet storms. Mechanisms have been added to the </name>
protocol to limit potential for these attacks. <t pn="section-8-1">
</t> In datagram-based protocols
(i.e., protocols running over UDP, or directly over IP, or similar), servers
<t> may be susceptible to denial-of-service (DoS) attacks, and clients
may be subjected to packet storms. Carefully designed mechanisms are needed
to limit potential for these attacks.
</t>
<t pn="section-8-2">
Note: This section contains no new protocol elements -- it serves Note: This section contains no new protocol elements -- it serves
only to explain the rationale behind protocol elements described only to explain the rationale behind protocol elements described
above, as they relate to security. above as they relate to security.
</t> </t>
<section title="Server DOS"> <section numbered="true" toc="include" anchor="server-dos" removeInRFC="fa
<t> lse" pn="section-8.1">
LLQs require that servers be stateful, maintaining entries for each <name slugifiedName="name-server-dos">Server DoS</name>
LLQ over a potentially long period of time. If unbounded in <t pn="section-8.1-1">
quantity, these entries may overload the server. By returning LLQs require that servers be stateful, maintaining entries for each LLQ
SERV&nbhy;FULL in Setup Challenges, the sever may limit the maximum over a potentially long period of time. If unbounded in quantity, these
number of LLQs it maintains. Additionally, the server may return entries may overload the server. By returning SERV‑FULL in Setup
SERV&nbhy;FULL to limit the number of LLQs requested for a single name and Challenges, the server may limit the maximum number of LLQs it
type, or by a single client. This throttling may be in the form of a maintains. Additionally, the server may return SERV‑FULL to limit the
hard limit, or, preferably, by token-bucket rate limiting. Such rate number of LLQs requested for a single name and type, or by a single
limiting should occur rarely in normal use and is intended to prevent client. This throttling may be in the form of a hard limit, or, preferably,
DOS attacks -- thus it is not built into the protocol explicitly, but by token-bucket rate limiting. Such rate limiting should occur rarely in
is instead implemented at the discretion of an administrator via the normal use and is intended to prevent DoS attacks -- thus, it is not built
SERV&nbhy;FULL error and the LEASE&nbhy;LIFE field to indicate a retry time t into the protocol explicitly but is instead implemented at the discretion
o of an administrator via the SERV‑FULL error and the LLQ‑LEASE
the client. field to indicate a retry time to the client.
</t> </t>
</section> </section>
<section title="Client Packet Storms"> <section numbered="true" toc="include" removeInRFC="false" pn="section-8.2
<t> ">
In addition to protecting the server from DOS attacks, the protocol <name slugifiedName="name-client-packet-storms">Client Packet Storms</na
me>
<t pn="section-8.2-1">
In addition to protecting the server from DoS attacks, the LLQ protocol
limits the ability of a malicious host to cause the server to flood a limits the ability of a malicious host to cause the server to flood a
client with packets. This is achieved via the four-way handshake client with packets. This is achieved via the four-way handshake
upon setup, demonstrating reachability and willingness of the client upon setup, demonstrating reachability and willingness of the client
to participate, and by requiring that gratuitous responses be ACK'd to participate, and by requiring that gratuitous responses be ACK'd
by the client. by the client.
</t> </t>
<t pn="section-8.2-2">
<t> Additionally, rate limiting by LLQ client address, as described in
Additionally, rate-limiting by LLQ client address, as described in <xref target="server-dos" format="default" sectionFormat="of" derivedContent=
(8.1) serves to limit the number of packets that can be delivered to "Section 8.1"/>, serves to limit the number of packets that can
be delivered to
an unsuspecting client. an unsuspecting client.
</t> </t>
</section> </section>
<section title="Spoofing"> <section numbered="true" toc="include" removeInRFC="false" pn="section-8.3
<t> ">
<name slugifiedName="name-spoofing">Spoofing</name>
<t pn="section-8.3-1">
A large random ID greatly reduces the risk of an off-path attacker A large random ID greatly reduces the risk of an off-path attacker
sending spoof packets to the client (containing spoof events) sending spoof packets to the client (containing spoof events)
or to the server (containing phony requests or refreshes). or to the server (containing phony requests or refreshes).
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-9">
<section title="IANA Considerations"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t> <t pn="section-9-1">
The EDNS(0) OPTION CODE 1 has already been assigned for this DNS The EDNS(0) OPTION CODE 1 has already been assigned for this DNS extension.
extension. IANA is requested to update the record in the DNS EDNS(0) IANA has updated the record in the "DNS EDNS0 Option Codes (OPT)" registry
Option Codes registry from "On-hold" to "Optional", and to set the from "On-hold" to "Optional" and has set the reference to this document.
reference to indicate the RFC number under which this document is </t>
published. <t pn="section-9-2">
</t> TCP and UDP ports 5352 have already been assigned for LLQ. IANA has
<t> added a reference to this document.
TCP and UDP ports 5352 have already been assigned for LLQ. IANA is </t>
requested to add a reference to indicate the RFC number under which </section>
this document is published. </middle>
</t> <back>
<t> <references pn="section-10">
No additional IANA services are required by this document. <name slugifiedName="name-references">References</name>
</t> <references pn="section-10.1">
</section> <name slugifiedName="name-normative-references">Normative References</na
me>
<section title="Acknowledgments"> <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1
<t> 035" quoteTitle="true" derivedAnchor="RFC1035">
The concepts described in this document were originally explored, developed <front>
and implemented with help from Chris Sharp and Roger Pantos. <title>Domain names - implementation and specification</title>
</t> <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockape
<t>In 2005 and 2006 Kiren Sekar made significant contributions to tris">
the <organization showOnFrontPage="true"/>
first two drafts of this document, and he wrote much of the code </author>
for the <date year="1987" month="November"/>
implementation of LLQ that shipped in Mac OS X 10.4 Tiger in 2005 <abstract>
.</t> <t>This RFC is the revised specification of the protocol and forma
</section> t used in the implementation of the Domain Name System. It obsoletes RFC-883. T
</middle> his memo documents the details of the domain name client - server communication.
</t>
<back> </abstract>
</front>
<references title='Normative References'> <seriesInfo name="STD" value="13"/>
&RFC1035; <seriesInfo name="RFC" value="1035"/>
&RFC2119; <seriesInfo name="DOI" value="10.17487/RFC1035"/>
&RFC2782; </reference>
&RFC6891; <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
&RFC8174; 119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<reference anchor='Push'> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
<front> le>
<title>DNS Push Notifications [[RFC Editor note: Please update reference <author initials="S." surname="Bradner" fullname="S. Bradner">
"Push" to refer to assigned RFC number for that document]]</title> <organization showOnFrontPage="true"/>
</author>
<author initials='T' surname='Pusateri' fullname='Tom Pusateri'> <date year="1997" month="March"/>
<organization /> <abstract>
</author> <t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'> This document defines these words as they should be interpreted in IETF document
<organization /> s. This document specifies an Internet Best Current Practices for the Internet
</author> Community, and requests discussion and suggestions for improvements.</t>
</abstract>
<date month='September' day='18' year='2018' /> </front>
<seriesInfo name="BCP" value="14"/>
<abstract><t>The Domain Name System (DNS) was designed to return <seriesInfo name="RFC" value="2119"/>
matching records efficiently for queries for data that are relatively <seriesInfo name="DOI" value="10.17487/RFC2119"/>
static. When those records change frequently, DNS is still efficient at </reference>
returning the updated results when polled, as long as the polling rate <reference anchor="RFC2782" target="https://www.rfc-editor.org/info/rfc2
is not too high. But there exists no mechanism for a client to be 782" quoteTitle="true" derivedAnchor="RFC2782">
asynchronously notified when these changes occur. This document defines <front>
a mechanism for a client to be notified of such changes to DNS records, <title>A DNS RR for specifying the location of services (DNS SRV)</t
called DNS Push Notifications.</t></abstract> itle>
<author initials="A." surname="Gulbrandsen" fullname="A. Gulbrandsen
</front> ">
<organization showOnFrontPage="true"/>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnssd-push-15' /> </author>
<format type='TXT' <author initials="P." surname="Vixie" fullname="P. Vixie">
target='http://www.ietf.org/internet-drafts/draft-ietf-dn <organization showOnFrontPage="true"/>
ssd-push-15.txt' /> </author>
</reference> <author initials="L." surname="Esibov" fullname="L. Esibov">
<organization showOnFrontPage="true"/>
</references> </author>
<date year="2000" month="February"/>
<references title='Informative References'> <abstract>
&RFC2136; <t>This document describes a DNS RR which specifies the location o
&RFC4787; f the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t>
&RFC4953; </abstract>
&RFC5382; </front>
&RFC6281; <seriesInfo name="RFC" value="2782"/>
&RFC6762; <seriesInfo name="DOI" value="10.17487/RFC2782"/>
&RFC6763; </reference>
&RFC6886; <reference anchor="RFC6891" target="https://www.rfc-editor.org/info/rfc6
&RFC6887; 891" quoteTitle="true" derivedAnchor="RFC6891">
&RFC7857; <front>
<title>Extension Mechanisms for DNS (EDNS(0))</title>
<reference anchor='SYN'> <author initials="J." surname="Damas" fullname="J. Damas">
<front> <organization showOnFrontPage="true"/>
<title>Defenses Against TCP SYN Flooding Attacks</title> </author>
<author initials='W.' surname='Eddy' fullname='Wesley Eddy'> <author initials="M." surname="Graff" fullname="M. Graff">
<organization>Verizon Federal Network Systems</organization> <organization showOnFrontPage="true"/>
<address> </author>
<email>weddy@grc.nasa.gov</email> <author initials="P." surname="Vixie" fullname="P. Vixie">
</address> <organization showOnFrontPage="true"/>
</author> </author>
<date year='2006' month='December' /> <date year="2013" month="April"/>
<keyword>TCP</keyword> <abstract>
</front> <t>The Domain Name System's wire protocol includes a number of fix
<seriesInfo name="The Internet Protocol Journal," value='Cisco Systems' /> ed fields whose range has been or soon will be exhausted and does not allow requ
<seriesInfo name='Volume' value='9' /> estors to advertise their capabilities to responders. This document describes b
<seriesInfo name='Number' value='4' /> ackward-compatible mechanisms for allowing the protocol to grow.</t>
<format type='PDF' octets='882020' target="http://www.cisco.com/web/about/ac12 <t>This document updates the Extension Mechanisms for DNS (EDNS(0)
3/ac147/archived_issues/ipj_9-4/ipj_9-4.pdf" /> ) specification (and obsoletes RFC 2671) based on feedback from deployment exper
<format type='HTML' octets='65566' target="http://www.cisco.com/web/about/ac12 ience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in
3/ac147/archived_issues/ipj_9-4/syn_flooding_attacks.html" /> the Domain Name System") and adds considerations on the use of extended labels
</reference> in the DNS.</t>
</abstract>
<reference anchor='RFC8490' target='https://www.rfc-editor.org/info/rfc8490'> </front>
<front> <seriesInfo name="STD" value="75"/>
<title>DNS Stateful Operations</title> <seriesInfo name="RFC" value="6891"/>
<author initials='R' surname='Bellis' fullname='Ray Bellis'> <seriesInfo name="DOI" value="10.17487/RFC6891"/>
<organization /> </reference>
</author> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'> <front>
<organization /> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
</author> tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<author initials='J' surname='Dickinson' fullname='John Dickinson'> <organization showOnFrontPage="true"/>
<organization /> </author>
</author> <date year="2017" month="May"/>
<abstract>
<author initials='S' surname='Dickinson' fullname='Sara Dickinson'> <t>RFC 2119 specifies common key words that may be used in protoco
<organization /> l specifications. This document aims to reduce the ambiguity by clarifying tha
</author> t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
<author initials='T' surname='Lemon' fullname='Ted Lemon'> </front>
<organization /> <seriesInfo name="BCP" value="14"/>
</author> <seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
<author initials='T' surname='Pusateri' fullname='Tom Pusateri'> </reference>
<organization /> <reference anchor="RFC8765" target="https://www.rfc-editor.org/info/rfc8
</author> 765" quoteTitle="true" derivedAnchor="RFC8765">
<front>
<date month='October' day='23' year='2018' /> <title>DNS Push Notifications</title>
<author initials="T" surname="Pusateri" fullname="Tom Pusateri">
<abstract><t>This document defines a new DNS OPCODE for DNS Stateful Operations <organization showOnFrontPage="true"/>
(DSO). DSO messages communicate operations within persistent stateful sessions, </author>
using type-length-value (TLV) syntax. Three TLVs are defined that manage sessi <author initials="S" surname="Cheshire" fullname="Stuart Cheshire">
on timeouts, termination, and encryption padding, and a framework is defined for <organization showOnFrontPage="true"/>
extensions to enable new stateful operations. This document updates RFC 1035 b </author>
y adding a new DNS header opcode which has different message semantics, and a ne <date month="June" year="2020"/>
w result code. This document updates RFC 7766 by redefining a session, providin </front>
g new guidance on connection re-use, and providing a new mechanism for handling <seriesInfo name="RFC" value="8765"/>
session idle timeouts.</t></abstract> <seriesInfo name="DOI" value="10.17487/RFC8765"/>
</front> </reference>
<seriesInfo name='BCP' value='14'/> </references>
<seriesInfo name='RFC' value='8490'/> <references pn="section-10.2">
<seriesInfo name='DOI' value='10.17487/RFC8490'/> <name slugifiedName="name-informative-references">Informative References
</reference> </name>
<reference anchor="RFC2136" target="https://www.rfc-editor.org/info/rfc2
</references> 136" quoteTitle="true" derivedAnchor="RFC2136">
<front>
<?rfc needLines="40" ?> <title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title
>
<section anchor="problems" title="Problems with the LLQ Protocol"> <author initials="P." surname="Vixie" fullname="P. Vixie" role="edit
<t> or">
In the course of using LLQ since 2005, some problems were discove <organization showOnFrontPage="true"/>
red. </author>
Since no further work is being done on the LLQ protocol, <author initials="S." surname="Thomson" fullname="S. Thomson">
this LLQ specification will not be updated to remedy these proble <organization showOnFrontPage="true"/>
ms. </author>
</t> <author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization showOnFrontPage="true"/>
<t> </author>
LLQ's IETF Standards Track successor, <author initials="J." surname="Bound" fullname="J. Bound">
<xref target="Push">DNS Push Notifications</xref>, <organization showOnFrontPage="true"/>
does not suffer from these problems, so </author>
all existing LLQ implementations are RECOMMENDED to migrate to us <date year="1997" month="April"/>
ing DNS Push Notifications, <abstract>
and all new implementations are RECOMMENDED to implement DNS Push <t>Using this specification of the UPDATE opcode, it is possible t
Notifications instead of LLQ. o add or delete RRs or RRsets from a specified zone. Prerequisites are specifie
</t> d separately from update operations, and can specify a dependency upon either th
e previous existence or nonexistence of an RRset, or the existence of a single R
<t> R. [STANDARDS-TRACK]</t>
Known problems with LLQ are documented here for the record. </abstract>
</t> </front>
<seriesInfo name="RFC" value="2136"/>
<t> <seriesInfo name="DOI" value="10.17487/RFC2136"/>
An LLQ "Setup Challenge" message from server to client is identic </reference>
al to <reference anchor="RFC4787" target="https://www.rfc-editor.org/info/rfc4
an LLQ "ACK + Answers" message from server to client 787" quoteTitle="true" derivedAnchor="RFC4787">
when there are no current answers for the query. <front>
If there is packet loss, retransmission, and duplication in the n <title>Network Address Translation (NAT) Behavioral Requirements for
etwork, Unicast UDP</title>
then a duplicated "Setup Challenge" message arriving late at the <author initials="F." surname="Audet" fullname="F. Audet" role="edit
client or">
would look like an "ACK + Answers" message with no answers, <organization showOnFrontPage="true"/>
causing the client to clear its cache of any </author>
records matching the query. <author initials="C." surname="Jennings" fullname="C. Jennings">
</t> <organization showOnFrontPage="true"/>
</author>
<t> <date year="2007" month="January"/>
This LLQ specification states: <abstract>
"Servers MUST NOT garbage collect LLQs that fail to complete the <t>This document defines basic terminology for describing differen
four-way t types of Network Address Translation (NAT) behavior when handling Unicast UDP
handshake until the initially granted LEASE-LIFE has elapsed." and also defines a set of requirements that would allow many applications, such
This is probably a mistake, since it exposes LLQ servers to an ea as multimedia communications or online gaming, to work consistently. Developing
sy NATs that meet this set of requirements will greatly increase the likelihood th
resource-exhaustion denial-of-service attack. at these applications will function properly. This document specifies an Intern
DNS Push Notifications is built using et Best Current Practices for the Internet Community, and requests discussion an
DNS Stateful Operations <xref target="RFC8490"/>, d suggestions for improvements.</t>
which uses TLS over TCP, </abstract>
and a benefit of building on TCP is that there are already establ </front>
ished <seriesInfo name="BCP" value="127"/>
industry best practices to guard against SYN flooding and <seriesInfo name="RFC" value="4787"/>
similar attacks <xref target="SYN"/> <xref target="RFC4953"/> <seriesInfo name="DOI" value="10.17487/RFC4787"/>
</t> </reference>
<reference anchor="RFC4953" target="https://www.rfc-editor.org/info/rfc4
<t> 953" quoteTitle="true" derivedAnchor="RFC4953">
LLQ is built using UDP, and because the UDP protocol has no <front>
standardized way of indicating the start and end of a <title>Defending TCP Against Spoofing Attacks</title>
session, firewalls and NAT gateways tend to be fairly agressive a <author initials="J." surname="Touch" fullname="J. Touch">
bout <organization showOnFrontPage="true"/>
recycling UDP mappings that they believe to be disused </author>
<xref target="RFC4787"/> <xref target="RFC5382"/> <xref target="R <date year="2007" month="July"/>
FC7857"/>. <abstract>
Using a high keepalive traffic rate to maintain firewall or NAT m <t>Recent analysis of potential attacks on core Internet infrastru
apping cture indicates an increased vulnerability of TCP connections to spurious resets
state could remedy this, but would largely defeat the purpose of (RSTs), sent with forged IP source addresses (spoofing). TCP has always been s
using LLQ in the first place, which is to provide efficient usceptible to such RST spoofing attacks, which were indirectly protected by chec
change notification without wasteful polling. king that the RST sequence number was inside the current receive window, as well
Because of this, existing LLQ clients use as via the obfuscation of TCP endpoint and port numbers. For pairs of well-kno
<xref target="RFC6886">NAT Port Mapping Protocol (NAT-PMP)</xref> wn endpoints often over predictable port pairs, such as BGP or between web serve
and/or rs and well-known large-scale caches, increases in the path bandwidth-delay prod
<xref target="RFC6887">Port Control Protocol (PCP)</xref> to uct of a connection have sufficiently increased the receive window space that of
establish longer port mapping lifetimes. f-path third parties can brute-force generate a viable RST sequence number. The
This solves the problem, but adds extra complexity, and doesn't w susceptibility to attack increases with the square of the bandwidth, and thus p
ork resents a significant vulnerability for recent high-speed networks. This docume
with firewalls and NAT gateways that don't support NAT-PMP or PCP nt addresses this vulnerability, discussing proposed solutions at the transport
. level and their inherent challenges, as well as existing network level solutions
By using TCP instead of UDP, the DNS Push Notifications and the feasibility of their deployment. This document focuses on vulnerabilit
protocol benefits from better longevity of sessions through ies due to spoofed TCP segments, and includes a discussion of related ICMP spoof
firewalls and NAT gateways that don't support NAT-PMP or PCP. ing attacks on TCP connections. This memo provides information for the Internet
</t> community.</t>
</abstract>
</section> </front>
<seriesInfo name="RFC" value="4953"/>
</back> <seriesInfo name="DOI" value="10.17487/RFC4953"/>
</reference>
<reference anchor="RFC5382" target="https://www.rfc-editor.org/info/rfc5
382" quoteTitle="true" derivedAnchor="RFC5382">
<front>
<title>NAT Behavioral Requirements for TCP</title>
<author initials="S." surname="Guha" fullname="S. Guha" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Biswas" fullname="K. Biswas">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Ford" fullname="B. Ford">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Sivakumar" fullname="S. Sivakumar">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Srisuresh" fullname="P. Srisuresh">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="October"/>
<abstract>
<t>This document defines a set of requirements for NATs that handl
e TCP that would allow many applications, such as peer-to-peer applications and
online games to work consistently. Developing NATs that meet this set of requir
ements will greatly increase the likelihood that these applications will functio
n properly. This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for improvements.<
/t>
</abstract>
</front>
<seriesInfo name="BCP" value="142"/>
<seriesInfo name="RFC" value="5382"/>
<seriesInfo name="DOI" value="10.17487/RFC5382"/>
</reference>
<reference anchor="RFC6281" target="https://www.rfc-editor.org/info/rfc6
281" quoteTitle="true" derivedAnchor="RFC6281">
<front>
<title>Understanding Apple's Back to My Mac (BTMM) Service</title>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization showOnFrontPage="true"/>
</author>
<author initials="Z." surname="Zhu" fullname="Z. Zhu">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Wakikawa" fullname="R. Wakikawa">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Zhang" fullname="L. Zhang">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="June"/>
<abstract>
<t>This document describes the implementation of Apple Inc.'s Back
to My Mac (BTMM) service. BTMM provides network connectivity between devices s
o that a user can perform file sharing and screen sharing among multiple compute
rs at home, at work, or on the road. The implementation of BTMM addresses the i
ssues of single sign-on authentication, secure data communication, service disco
very, and end-to-end connectivity in the face of Network Address Translators (NA
Ts) and mobility of devices. This document is not an Internet Standards Track
specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6281"/>
<seriesInfo name="DOI" value="10.17487/RFC6281"/>
</reference>
<reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc6
762" quoteTitle="true" derivedAnchor="RFC6762">
<front>
<title>Multicast DNS</title>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="February"/>
<abstract>
<t>As networked devices become smaller, more portable, and more ub
iquitous, the ability to operate with less configured infrastructure is increasi
ngly important. In particular, the ability to look up DNS resource record data
types (including, but not limited to, host names) in the absence of a convention
al managed DNS server is useful.</t>
<t>Multicast DNS (mDNS) provides the ability to perform DNS-like o
perations on the local link in the absence of any conventional Unicast DNS serve
r. In addition, Multicast DNS designates a portion of the DNS namespace to be f
ree for local use, without the need to pay any annual fee, and without the need
to set up delegations or otherwise configure a conventional DNS server to answer
for those names.</t>
<t>The primary benefits of Multicast DNS names are that (i) they r
equire little or no administration or configuration to set them up, (ii) they wo
rk when no infrastructure is present, and (iii) they work during infrastructure
failures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6762"/>
<seriesInfo name="DOI" value="10.17487/RFC6762"/>
</reference>
<reference anchor="RFC6763" target="https://www.rfc-editor.org/info/rfc6
763" quoteTitle="true" derivedAnchor="RFC6763">
<front>
<title>DNS-Based Service Discovery</title>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="February"/>
<abstract>
<t>This document specifies how DNS resource records are named and
structured to facilitate service discovery. Given a type of service that a clie
nt is looking for, and a domain in which the client is looking for that service,
this mechanism allows clients to discover a list of named instances of that des
ired service, using standard DNS queries. This mechanism is referred to as DNS-b
ased Service Discovery, or DNS-SD.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6763"/>
<seriesInfo name="DOI" value="10.17487/RFC6763"/>
</reference>
<reference anchor="RFC6886" target="https://www.rfc-editor.org/info/rfc6
886" quoteTitle="true" derivedAnchor="RFC6886">
<front>
<title>NAT Port Mapping Protocol (NAT-PMP)</title>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="April"/>
<abstract>
<t>This document describes a protocol for automating the process o
f creating Network Address Translation (NAT) port mappings. Included in the pro
tocol is a method for retrieving the external IPv4 address of a NAT gateway, thu
s allowing a client to make its external IPv4 address and port known to peers th
at may wish to communicate with it. From 2005 onwards, this protocol was impleme
nted in Apple products including Mac OS X, Bonjour for Windows, and AirPort wire
less base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded
by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on
NAT-PMP and uses a compatible packet format, but adds a number of significant en
hancements.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6886"/>
<seriesInfo name="DOI" value="10.17487/RFC6886"/>
</reference>
<reference anchor="RFC6887" target="https://www.rfc-editor.org/info/rfc6
887" quoteTitle="true" derivedAnchor="RFC6887">
<front>
<title>Port Control Protocol (PCP)</title>
<author initials="D." surname="Wing" fullname="D. Wing" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Penno" fullname="R. Penno">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Selkirk" fullname="P. Selkirk">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="April"/>
<abstract>
<t>The Port Control Protocol allows an IPv6 or IPv4 host to contro
l how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Ad
dress Translator (NAT) or simple firewall, and also allows a host to optimize it
s outgoing NAT keepalive messages.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6887"/>
<seriesInfo name="DOI" value="10.17487/RFC6887"/>
</reference>
<reference anchor="RFC7857" target="https://www.rfc-editor.org/info/rfc7
857" quoteTitle="true" derivedAnchor="RFC7857">
<front>
<title>Updates to Network Address Translation (NAT) Behavioral Requi
rements</title>
<author initials="R." surname="Penno" fullname="R. Penno">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Perreault" fullname="S. Perreault">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Sivakumar" fullname="S. Sivakumar">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Naito" fullname="K. Naito">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="April"/>
<abstract>
<t>This document clarifies and updates several requirements of RFC
s 4787, 5382, and 5508 based on operational and development experience. The focu
s of this document is Network Address Translation from IPv4 to IPv4 (NAT44).</t>
<t>This document updates RFCs 4787, 5382, and 5508.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="127"/>
<seriesInfo name="RFC" value="7857"/>
<seriesInfo name="DOI" value="10.17487/RFC7857"/>
</reference>
<reference anchor="RFC8490" target="https://www.rfc-editor.org/info/rfc8
490" quoteTitle="true" derivedAnchor="RFC8490">
<front>
<title>DNS Stateful Operations</title>
<author initials="R." surname="Bellis" fullname="R. Bellis">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Dickinson" fullname="J. Dickinson">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Dickinson" fullname="S. Dickinson">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Lemon" fullname="T. Lemon">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Pusateri" fullname="T. Pusateri">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="March"/>
<abstract>
<t>This document defines a new DNS OPCODE for DNS Stateful Operati
ons (DSO). DSO messages communicate operations within persistent stateful sessi
ons using Type Length Value (TLV) syntax. Three TLVs are defined that manage se
ssion timeouts, termination, and encryption padding, and a framework is defined
for extensions to enable new stateful operations. This document updates RFC 103
5 by adding a new DNS header OPCODE that has both different message semantics an
d a new result code. This document updates RFC 7766 by redefining a session, pr
oviding new guidance on connection reuse, and providing a new mechanism for hand
ling session idle timeouts.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8490"/>
<seriesInfo name="DOI" value="10.17487/RFC8490"/>
</reference>
<reference anchor="SYN" target="https://www.cisco.com/web/about/ac123/ac
147/archived_issues/ipj_9-4/ipj_9-4.pdf" quoteTitle="true" derivedAnchor="SYN">
<front>
<title>Defenses Against TCP SYN Flooding Attacks</title>
<seriesInfo name="Volume" value="9"/>
<seriesInfo name="Number" value="4"/>
<seriesInfo name="The Internet Protocol Journal," value="Cisco
Systems"/>
<author initials="W." surname="Eddy" fullname="Wesley Eddy">
<organization showOnFrontPage="true">Verizon Federal Network Syste
ms</organization>
<address>
<email>weddy@grc.nasa.gov</email>
</address>
</author>
<date year="2006" month="December"/>
<keyword>TCP</keyword>
</front>
</reference>
</references>
</references>
<section anchor="problems" numbered="true" toc="include" removeInRFC="false"
pn="section-appendix.a">
<name slugifiedName="name-problems-with-the-llq-proto">Problems with the L
LQ Protocol</name>
<t pn="section-appendix.a-1">
In the course of using LLQ since 2005, some problems were discovered.
Since no further work is being done on the LLQ protocol,
this LLQ specification will not be updated to remedy these problems.
</t>
<t pn="section-appendix.a-2">
LLQ's IETF Standards Track successor, "DNS Push Notifications"
<xref target="RFC8765" format="default" sectionFormat="of" derivedContent
="RFC8765"/>, does not
suffer from these problems, so all existing LLQ
implementations are <bcp14>RECOMMENDED</bcp14> to migrate to
using DNS Push Notifications, and all new implementations are
<bcp14>RECOMMENDED</bcp14> to implement DNS Push Notifications
instead of LLQ.
</t>
<t pn="section-appendix.a-3">
Known problems with LLQ are documented here as a cautionary tale
about the challenges of building an application protocol directly
using datagrams (like IP or UDP) without the benefit of a
mature and thoroughly reviewed
intervening transport layer (such as TCP or QUIC).
</t>
<t pn="section-appendix.a-4">
An LLQ "Setup Challenge" message from server to client is identical to
an LLQ "ACK + Answers" message from server to client
when there are no current answers for the query.
If there is packet loss, retransmission, and duplication in the
network,
then a duplicated "Setup Challenge" message arriving late at the
client
would look like an "ACK + Answers" message with no answers,
causing the client to clear its cache of any
records matching the query.
</t>
<t pn="section-appendix.a-5">
<xref target="setup-message-retransmission" format="default" sectionForma
t="of" derivedContent="Section 5.1"/> of this LLQ
specification states, "Servers <bcp14>MUST NOT</bcp14> garbage collect LL
Qs that fail to complete the
four-way handshake until the initially granted LLQ-LEASE has
elapsed." This is probably a mistake since it exposes LLQ
servers to an easy resource-exhaustion denial-of-service
attack.
LLQ's replacement,
DNS Push Notifications <xref target="RFC8765" format="default" sectionFor
mat="of" derivedContent="RFC8765"/>,
is built using DNS Stateful
Operations <xref target="RFC8490" format="default" sectionFormat="of" der
ivedContent="RFC8490"/>, which
uses TLS over TCP; a benefit of building on TCP is that there
are already established industry best practices to guard
against SYN flooding and similar attacks <xref target="SYN" format="defau
lt" sectionFormat="of" derivedContent="SYN"/> <xref target="RFC4953" format="def
ault" sectionFormat="of" derivedContent="RFC4953"/>.
</t>
<t pn="section-appendix.a-6">
The attempts here to pack multiple questions into a single UDP/IP
packet for efficiency are awkward and lead to error-prone programming
to deal with cases where some requests in a packet succeed and other
requests in the same packet fail. Fully specifying the correct
handling in all possible cases would be a lot of work to document, a
lot of work to implement, and even more work to thoroughly test. DNS
Push Notifications <xref target="RFC8765" format="default" sectionFormat=
"of" derivedContent="RFC8765"/>
avoids this problem by using an underlying stream protocol (TLS/TCP)
to deal with packing small multiple messages into larger IP packets
for efficiency.
</t>
<t pn="section-appendix.a-7">
In some cases, initial LLQ answers are delivered in the "ACK +
Answers" message, and in other cases, such as when all the initial
answers will not fit in a single IP packet, some of the initial
answers are delivered in a subsequent "Add Event" message.
Having two different ways to accomplish the same thing increases
the possibility for programming errors.
DNS Push Notifications <xref target="RFC8765" format="default" sectionFor
mat="of" derivedContent="RFC8765"/>
corrects this error by having only one single consistent way to
deliver results.
</t>
<t pn="section-appendix.a-8">
LLQ is built using UDP, and because UDP has no
standardized way of indicating the start and end of a session,
firewalls and NAT gateways tend to be fairly aggressive about
recycling UDP mappings that they believe to be disused <xref target="RFC4
787" format="default" sectionFormat="of" derivedContent="RFC4787"/> <xref target
="RFC5382" format="default" sectionFormat="of" derivedContent="RFC5382"/> <xref
target="RFC7857" format="default" sectionFormat="of" derivedContent="RFC7857"/>.
Using a high keepalive traffic rate to maintain firewall or
NAT mapping state could remedy this but would largely defeat
the purpose of using LLQ in the first place, which is to
provide efficient change notification without wasteful
polling. Because of this, existing LLQ clients use the NAT
Port Mapping Protocol (NAT-PMP) <xref target="RFC6886" format="default" s
ectionFormat="of" derivedContent="RFC6886"/> and/or Port Control Protocol (PCP)
<xref target="RFC6887" format="default" sectionFormat="of" derivedContent
="RFC6887"/> to establish
longer port mapping lifetimes. This solves the problem but
adds extra complexity and doesn't work with firewalls and NAT
gateways that don't support NAT-PMP or PCP. By using TCP
instead of UDP, the DNS Push Notifications protocol benefits
from better longevity of sessions through firewalls and NAT
gateways that don't support NAT-PMP or PCP.
</t>
</section>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.b">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t pn="section-appendix.b-1">
The concepts described in this document were originally explored,
developed,
and implemented with help from <contact fullname="Chris Sharp"/> and
<contact fullname="Roger Pantos"/>.
</t>
<t pn="section-appendix.b-2"><contact fullname="Kiren Sekar"/> made signif
icant contributions to
the first draft of this document and he wrote much of the code for the
implementation of LLQ that shipped in Mac OS X 10.4 Tiger in April
2005.</t>
<t pn="section-appendix.b-3">Thanks to Independent Stream Editor <contact
fullname="Adrian Farrel"/> for his support and
assistance in the publication of this RFC.
</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.c">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="S." surname="Cheshire" fullname="Stuart Cheshire">
<organization showOnFrontPage="true">Apple Inc.</organization>
<address>
<postal>
<street>One Apple Park Way</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>United States of America</country>
</postal>
<phone>+1 (408) 996-1010</phone>
<email>cheshire@apple.com</email>
</address>
</author>
<author initials="M." surname="Krochmal" fullname="Marc Krochmal">
<organization showOnFrontPage="true">Apple Inc.</organization>
<address>
<postal>
<street>One Apple Park Way</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>United States of America</country>
</postal>
<phone>+1 (408) 996-1010</phone>
<email>marc@apple.com</email>
</address>
</author>
</section>
</back>
</rfc> </rfc>
 End of changes. 72 change blocks. 
1149 lines changed or deleted 2292 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/