wdiff rfc8764xml2.original.xml rfc8764.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2782 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">

<!ENTITY RFC2136 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml">
<!ENTITY RFC4787 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC4953 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4953.xml">
<!ENTITY RFC5382 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5382.xml">
<!ENTITY RFC6281 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6281.xml">
<!ENTITY RFC6762 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml">
<!ENTITY RFC6763 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml">
<!ENTITY RFC6886 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6886.xml">
<!ENTITY RFC6887 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6887.xml">
<!ENTITY RFC6891 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml">
<!ENTITY RFC7857 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7857.xml">
]>

<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8764"
     docName="draft-sekar-dns-llq-06" category="info"
     submissionType="independent" ipr="trust200902"> ipr="trust200902" obsoletes="" updates=""
     xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
     version="3">

  <front>

	<title>Apple's
    <title abbrev="Apple's DNS LLQ">Apple's DNS Long-Lived Queries protocol</title>
    Protocol</title>
    <seriesInfo name="RFC" value="8764"/>
    <author initials="S." surname="Cheshire" fullname="Stuart Cheshire">
      <organization>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'> initials="M." surname="Krochmal" fullname="Marc Krochmal">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino</city>
				<region>California</region>
          <region>CA</region>
          <code>95014</code>
				<country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 (408) 996-1010</phone>
        <email>marc@apple.com</email>
      </address>
    </author>
    <date year="2019" month="August" day="22"/> year="2020" month="June"/>

<keyword>Async, Asynchronous, Change Notification, Push Notification</keyword>

     <abstract>
       <t>
	  Apple's DNS Long-Lived Queries protocol (LLQ) is a protocol mechanism
	   for extending the DNS protocol to support change notification,
	    thus allowing clients to learn about changes to DNS data
	     without polling the server.  From 2005 onwards, LLQ was
	      implemented in Apple products including Mac OS X, Bonjour for
	       Windows, and AirPort wireless base stations.  In 2019, 2020, the LLQ
	        protocol was superseded by the IETF Standards Track RFC xxxx
   [[RFC Editor note: Please replace xxxx with RFC number]] 8765,
		"DNS
		 Push Notifications", which builds on experience gained with
		  the LLQ protocol to create a superior replacement.
       </t>
       <t>
    The existing LLQ protocol deployed and used from 2005 to 2019 2020 is
    documented here to give
    background regarding the operational experience that informed
    the development of DNS Push Notifications, and to help facilitate
    a smooth transition from LLQ to DNS Push Notifications.
       </t>
     </abstract>
  </front>
   <middle>
<?rfc needLines="40" ?>
     <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
       <name>Introduction</name>
       <t>
    In dynamic environments, DNS DNS-based Service Discovery <xref target="RFC6763"/> target="RFC6763"
    format="default"/> 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, or (b)
    learn when
    an existing service instance disappears from the network, and (c) allows
    clients
    to monitor status changes to a service. service instance (e.g., printer ink
    levels).
    Multicast DNS <xref target="RFC6762"/> target="RFC6762" format="default"/> supports this
    natively. When a host device on the network publishes or deletes Multicast DNS
    records, these changes are multicast to other hosts on the network.
   These
    Those hosts deliver the change notifications to interested clients
    (applications
    running on the that host). Hosts also send occasional queries to the
   network
    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>
   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 server, because
   a low polling rate could leave the client with stale information information,
   while a high polling rate would have an adverse impact on the network
   and server.
       </t>
       <t>
   The mechanism defined in this document is now being replaced by
  <xref target="Push">DNS DNS Push Notifications</xref>
   Notifications <xref target="RFC8765" format="default"></xref> as explained below
   in <xref target="trans"/>. target="trans" format="default"/>.
       </t>
<?rfc needLines="40" ?>
       <t>
       </t>
       <section anchor="trans" title="Transition numbered="true" toc="default">
	  <name>Transition to DNS Push Notifications"> Notifications</name>
	   <t>
    The LLQ protocol enjoyed over a decade of useful operation,
    enabling timely live updates for the service discovery user interface in
    Apple's <xref target="RFC6281">Back Back to My Mac</xref> Mac <xref target="RFC6281" format="default"></xref>
    service.
	   </t>
	    <t>
    However, some problems were discovered, as described in <xref target="problems"/>.
    target="problems" format="default"/>.
    This operational
    experience with LLQ informed the design of its IETF Standards
    Track successor, <xref target="Push">DNS DNS Push Notifications</xref>. Notifications <xref target="RFC8765"
    format="default"></xref>.
    Since no further work is being done on the LLQ protocol, this LLQ
    specification will not be updated to remedy these problems.
	    </t>
	     <t>
    All existing LLQ implementations are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to migrate
    to using DNS Push Notifications instead.
	     </t>
	      <t>
   For existing
    Existing LLQ servers, they servers are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to implement and
    support
    DNS Push Notifications, Notifications so that clients can begin migrating to the
    newer protocol.
	      </t>
	       <t>
   For existing
    Existing LLQ clients, they clients are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to query for the
   <spanx style="verb">_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</spanx>
    <tt>_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</tt> SRV record first, and
    then only if DNS Push fails, then Notifications fail, fall back to query for
   <spanx style="verb">_dns&nbhy;llq._udp.&lt;zone&gt;</spanx>
    <tt>_dns&nbhy;llq._udp.&lt;zone&gt;</tt> instead.  Use of the
    <tt>_dns&nbhy;llq._udp.&lt;zone&gt;</tt> SRV record is described in <xref
    target="address-port"/>.
	       </t>
	        <t>
    This will cause clients to prefer the newer protocol when possible.  It is RECOMMENDED
    <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 SHOULD NOT <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, updated and even a server that speaks
    only LLQ today, today may be updated to support DNS Push Notifications tomorrow.
		</t>
		 <t>
    New client and server implementations are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to
    support only
    DNS Push Notifications.
		 </t>

       </section>
     </section>
     <section title="Conventions numbered="true" toc="default">
       <name>Conventions and Terminology Used in this Document">
		<t>The This Document</name>

        <t>
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
		"MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
     to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
     <xref target="RFC8174"/> when, and only when, they appear in all
     capitals, as shown here.</t>
<?rfc needLines="40" ?> here.
	</t>

     </section>
     <section title="Mechanisms"> numbered="true" toc="default">
       <name>Mechanisms</name>
       <t>
    DNS Long-Lived Queries (DNS&nbhy;LLQ) is (LLQ) are implemented using the standard
    DNS message format <xref target="RFC1035"/> target="RFC1035" format="default"/> in
    conjunction with an EDNS(0) OPT
    pseudo&nbhy;RR <xref target="RFC6891"/> target="RFC6891" format="default"/> with a new OPT
    OPTION&nbhy;CODE
    and RDATA OPTION&nbhy;DATA format specified here.  Encoding the LLQ request in
    an OPT RR pseudo&nbhy;RR
    allows for implementation of LLQ with minimal modification to a name
    server's front-end. 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">EDNS(0) specification</xref> target="RFC6891" format="default"></xref> will
    silently ignore the unrecognized option and answer the request as a normal
    DNS query, query without establishing any long-lived state, 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&nbhy;RR, pseudo&nbhy;RR or it may
    return a nonzero RCODE.  However, in practice practice, this issue is mostly
    theoretical, since having a zone's _dns&nbhy;llq._udp.&lt;zone&gt; SRV
    record target a host that does not implement LLQ is a configuration error.
       </t>
       <t>
    Note that this protocol is designed for data set sizes of a few dozen
    resource records at most, most and change rates no more than one once every ten 10
    seconds on average. Data sets in response to queries that frequently
    exceed a single IP packet, or that experience a rapid change rate, may
    have
    undesirable performance implications.
       </t>
<?rfc needLines="20" ?>
		<t>
		</t>

       <section title="Assigned Numbers"> numbered="true" toc="default">
	  <name>Assigned Numbers</name>
	   <t>
	      This section describes constants uses used in this document.
	   </t>
<figure><artwork>
EDNS(0) Option Code

<ul empty="true">

   <li>
     <t>EDNS(0) OPTION&nbhy;CODE (recorded with IANA):
     LLQ 1

LLQ-PORT IANA):</t>

     <ul empty="true">
      <li>
         <dl indent="18">
         <dt>LLQ
         </dt>
         <dd>1
         </dd>
	 </dl>
      </li>
     </ul>
   </li>

   <li>
LLQ&nbhy;PORT 5352 (recorded with IANA)
   </li>

   <li><t>LLQ Opcodes (specific to this LLQ EDNS(0) Option):</t>

   <ul empty="true">
      <li>
         <dl indent="18" spacing="compact">
         <dt>LLQ&nbhy;SETUP
         </dt>
         <dd>1
         </dd>

         <dt>LLQ&nbhy;REFRESH
         </dt>
         <dd>2
         </dd>

         <dt>LLQ&nbhy;EVENT
         </dt>
         <dd>3
         </dd>
	 </dl>
      </li>
   </ul>
   </li>

   <li>
<t>LLQ Error Codes (specific to this LLQ EDNS(0) Option): Option):</t>

      <ul empty="true">
         <li>
<dl indent="18" spacing="compact">
<dt>
NO-ERROR    0
</dt>
<dd>0
</dd>

<dt>
SERV-FULL   1
</dt>
<dd>1
</dd>

<dt>
STATIC      2
</dt>
<dd>2
</dd>

<dt>
FORMAT-ERR  3
</dt>
<dd>3
</dd>

<dt>
NO-SUCH-LLQ 4
</dt>
<dd>4
</dd>

<dt>
BAD-VERS    5
</dt>
<dd>5
</dd>

<dt>
UNKNOWN-ERR 6

LLQ Opcodes (specific to this LLQ EDNS(0) Option):
     LLQ-SETUP    1
     LLQ-REFRESH  2
     LLQ-EVENT    3
</artwork></figure>
<?rfc needLines="40" ?>
</dt>
<dd>6
</dd>
</dl>
         </li>
      </ul>
   </li>
</ul>

       </section>

<section title="Opt-RR Format"> numbered="true" toc="default">
   <name>Opt-RR Format</name>
    <t>
    As required by the EDNS(0) specification <xref target="RFC6891">EDNS(0) specification</xref>, target="RFC6891"
    format="default"></xref>,
    all OPT&nbhy;RRs OPT pseudo&nbhy;RRs used in LLQs are formatted as follows:
    </t>

<figure><artwork>
Field Name        Field Type     Description
---------------------------------------------------------------------
NAME              domain name    empty (root domain)
TYPE              u_int16_t      OPT
CLASS             u_int16_t      0*
TTL               u_int32_t

<table anchor="OPT-RRs">
  <name>OPT-RRs Used in LLQs</name>
  <thead>
    <tr>
      <th>Field Name</th>
      <th>Field Type</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>NAME</td>
      <td>domain name</td>
      <td>MUST be 0
RDLEN             u_int16_t      describes RDATA
RDATA             octet stream   (see below)
</artwork></figure> (root domain)</td>
    </tr>
    <tr>
      <td>TYPE</td>
      <td>u_int16_t</td>
      <td>OPT (41)</td>
    </tr>
    <tr>
      <td>CLASS</td>
      <td>u_int16_t</td>
      <td>0*</td>
    </tr>
    <tr>
      <td>TTL</td>
      <td>u_int32_t</td>
      <td>0</td>
    </tr>
    <tr>
      <td>RDLEN</td>
      <td>u_int16_t</td>
      <td>length of all RDATA</td>
    </tr>
    <tr>
      <td>RDATA</td>
      <td>octet stream</td>
      <td>(see below)</td>
    </tr>
  </tbody>
</table>

 <t>
    * The CLASS field indicates, as per the EDNS(0) specification <xref target="RFC6891">EDNS(0) specification</xref>,
    target="RFC6891" format="default"></xref>, the sender's UDP payload
    size. However, clients and servers need are not be required to determine their
    reassembly buffer size, path MTU, etc. etc., to support LLQ. Thus, the sender
    of
    an LLQ Request or Response MAY <bcp14>MAY</bcp14> set the CLASS field to 0.
    The recipient MUST <bcp14>MUST</bcp14> ignore the class field if it is set to
    0.
 </t>

<?rfc needLines="20" ?>
  <t>
    The RDATA Format: of an EDNS(0) OPT pseudo&nbhy;RR consists of zero or more
    options
    of the form { OPTION&nbhy;CODE, OPTION&nbhy;LENGTH, OPTION&nbhy;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&nbhy;RR may contain zero or more LLQ OPTIONS in
    addition
    to zero or more other EDNS(0) options.
  </t>

<figure><artwork>
Field Name        Field Type     Description
---------------------------------------------------------------------
OPTION-CODE       u_int16_t      LLQ
OPTION-LENGTH     u_int16_t      Length

<table anchor="LLQ-OPT-FORMAT">
  <name>LLQ OPTION</name>
  <thead>
    <tr>
      <th>Field Name</th>
      <th>Field Type</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>OPTION-CODE</td>
      <td>u_int16_t</td>
      <td>LLQ (1)</td>
    </tr>
    <tr>
      <td>OPTION-LENGTH</td>
      <td>u_int16_t</td>
      <td>Length of following fields, as
                                 appropriate
VERSION           u_int16_t      Version fields (18)</td>
    </tr>
    <tr>
      <td>LLQ-VERSION</td>
      <td>u_int16_t</td>
      <td>Version of LLQ protocol implemented
LLQ-OPCODE        u_int16_t      Identifies LLQ operation
ERROR-CODE        u_int16_t      Identifies LLQ errors
LLQ-ID            u_int64_t      Identifier for an LLQ
LEASE-LIFE        u_int32_t      Requested implemented</td>
    </tr>
    <tr>
      <td>LLQ-OPCODE</td>
      <td>u_int16_t</td>
      <td>Identifies LLQ operation</td>
    </tr>
    <tr>
      <td>LLQ-ERROR</td>
      <td>u_int16_t</td>
      <td>Identifies LLQ errors</td>
    </tr>
    <tr>
      <td>LLQ-ID</td>
      <td>u_int64_t</td>
      <td>Identifier for an LLQ</td>
    </tr>
    <tr>
      <td>LLQ-LEASE</td>
      <td>u_int32_t</td>
      <td>Requested or granted life of LLQ, in
                                 seconds
</artwork></figure>

			<t>
   This data format, consisting of (OPTION&nbhy;CODE, OPTION&nbhy;LENGTH,
   LLQ&nbhy;Metadata) tuples, may be repeated an arbitrary number of times in
   the RDATA section, with the RDLEN field set accordingly.
			</t> seconds</td>
    </tr>

  </tbody>
</table>

        <t>
   The size and meaning of the OPTION&nbhy;CODE and OPTION&nbhy;LENGTH fields
   are as described in the EDNS(0) specification <xref target="RFC6891">EDNS(0) specification</xref>. target="RFC6891"
   format="default"></xref>.  The remainder of the fields comprise the OPTION-DATA
   OPTION&nbhy;DATA of the EDNS(0) option. LLQ OPTION.  Since for LLQ the OPTION-DATA
   OPTION&nbhy;DATA is a
   fixed size, in LLQ EDNS(0) options LLQ OPTIONS the OPTION&nbhy;LENGTH field always has
   the value 18.
        </t>
<?rfc needLines="40" ?>
		</section>
	</section>

	<section title="LLQ Address
        <t>
   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="default" anchor="address-port">
      <name>LLQ Address and Port Identification"> Identification</name>
      <t>
   The client
   requires a mechanism to determine to which server it should send LLQ
   operations.
      </t>
      <t>
   Additionally, some firewalls block direct communication with a name server
   on port 53 to avoid spoof responses. However, this direct communication is
   necessary for LLQs. Thus, servers MAY <bcp14>MAY</bcp14> listen for LLQs on a
   different port (typically 5352). Clients Clients, therefore, also therefore need a
   mechanism to determine to which port to send LLQ operations.
      </t>
<?rfc needLines="20" ?>

      <t>
   The client determines the server responsible for a given LLQ much as a
   client determines to which server to send a DNS dynamic update. The client
   begins by sending a standard DNS query for the name of the LLQ, with type
   SOA. The  If the record exists, then the server MUST <bcp14>MUST</bcp14> answer with
   that SOA record in the Answer section, if the section.  If a record exists. The of type SOA with the
   LLQ name does not exist, then the server SHOULD <bcp14>SHOULD</bcp14> include an
   SOA record for that name's zone in the Authority section, if the
   LLQ name (type SOA) does not exist. section.  For example, a
   query for
   "_ftp._tcp.example.com." may "_ftp._tcp.example.com" with type SOA, when there is no SOA
   record with that name, might return an SOA record named "example.com." "example.com" in
   the Authority section if there is no section.  If the named SOA record named
   "_ftp._tcp.example.com." If, in this case, the server does not exist and the
   server fails to include the enclosing SOA record in the Authority section,
   the client strips the leading label from the name and tries again,
   repeating until an answer is received.
      </t>
      <t>
   This iterative zone apex discovery algorithm is described in more detail in
   the <xref target="Push">DNS DNS Push Notifications specification</xref>. specification <xref target="RFC8765"
   format="default"></xref>.
      </t>
      <t>
   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;,
   e.g.,&nbsp;_dns&nbhy;llq._udp.example.com. name, "_dns&nbhy;llq._udp.&lt;zone&gt;",
   e.g.,&nbsp;"_dns&nbhy;llq._udp.example.com".
      </t>
      <t>
   A
   An authoritative server for a zone implementing LLQ MUST <bcp14>MUST</bcp14>
   answer with an SRV record <xref target="RFC2782"/> target="RFC2782" format="default"/>
   for this name. The SRV RDATA is as follows:
      </t>
<figure><artwork>
PRIORITY   typically 0
WEIGHT     typically 0
PORT       typically

<table anchor="SRV-RDATA">
  <name>SRV RDATA</name>
  <tbody>
    <tr>
      <td>PRIORITY</td>
      <td>typically 0</td>

    </tr>
    <tr>
      <td>WEIGHT</td>
      <td>typically 0</td>

    </tr>
    <tr>
      <td>PORT</td>
      <td>typically 53 or 5352
TARGET     name 5352</td>

    </tr>
    <tr>
      <td>TARGET</td>
      <td>name of server providing LLQs for the requested zone
</artwork></figure> zone</td>

    </tr>
  </tbody>
</table>

      <t>
   The server SHOULD <bcp14>SHOULD</bcp14> include its the address record(s) for the
   target host in the Additional
   section of the response.
      </t>
      <t>
   If the server does not include its the target host's address record record(s) in the
   Additional
   section, the client SHOULD <bcp14>SHOULD</bcp14> query explicitly for the address record
   record(s)
   with the name of the SRV target.
      </t>
      <t>
   The client MUST <bcp14>MUST</bcp14> send all LLQ requests, refreshes, and
   acknowledgments to the name server specified in the SRV target, at the
   address contained in the address record for that target. Note that the
   queries described in this section (including those for SOA and SRV records) MAY
   <bcp14>MAY</bcp14> be sent to an intermediate DNS recursive resolver --
   they
   need not be sent directly to the name server.
      </t>
      <t>
   If, on issuing the SRV query, the client receives an NXDOMAIN a negative
   response indicating that the SRV record does not exist, the client
   SHOULD
   <bcp14>SHOULD</bcp14> conclude that the server zone does not support an LLQ in the
   requested zone. LLQ.
   The client then SHOULD NOT <bcp14>SHOULD NOT</bcp14> send an LLQ request for
   the desired name, instead utilizing the behavior for LLQ-unaware
   servers described in Section 5 "LLQ Setup".
			</t>
<?rfc needLines="20" ?>
			<t> <xref target="llq-setup"/>, "<xref target="llq-setup"
   format="title"/>".
      </t>

      <t>
   Servers should send all messages to the source address and port of
   the LLQ setup message received from the client.
      </t>
<?rfc needLines="40" ?>
    </section>
    <section title="LLQ Setup"> numbered="true" toc="default" anchor="llq-setup">
      <name>LLQ Setup</name>
      <t>
   An LLQ is initiated by a client, client and is completed via a four-way
   handshake. This handshake provides resilience to packet loss,
   demonstrates client reachability, and reduces denial of service denial-of-service
   attack opportunities (see Section 8 "Security Considerations"). <xref target="security-considerations"/>, "<xref
   target="security-considerations" format="title"/>").
      </t>
      <section title="Setup numbered="true" toc="default"
	       anchor="setup-message-retransmission">
        <name>Setup Message Retransmission"> Retransmission</name>
        <t>
   LLQ Setup Requests and Responses sent by the client SHOULD <bcp14>SHOULD</bcp14>
   be
   retransmitted if no acknowledgments are received. The client SHOULD
   re&nbhy;try
   <bcp14>SHOULD</bcp14>
   retry up to two more times (for a total of 3 attempts) before
   considering the server down or unreachable. The client MUST <bcp14>MUST</bcp14>
   wait at
   least 2 seconds before the first retransmission and 4 seconds between
   the first and second retransmissions. The client SHOULD <bcp14>SHOULD</bcp14>
   listen for a
   response for at least 8 seconds after the 3rd attempt before
   considering the server down or unreachable. Upon determining a
   server to be down, a client MAY <bcp14>MAY</bcp14> periodically attempt to
   re-initiate
   an LLQ setup, setup at a rate of not more than once per hour.
        </t>
        <t>
   Servers MUST NOT re-transmit <bcp14>MUST NOT</bcp14> retransmit acknowledgments that do not
   generate
   responses from the client. Retransmission in setup is client-driven, client driven,
   freeing servers from maintaining timers for incomplete LLQ setups. If
   servers receive duplicate messages from clients (perhaps due to the
   loss of the server's responses mid-flight), the server MUST re&nbhy;send <bcp14>MUST</bcp14>
   resend
   its reply (possibly modifying the LEASE&nbhy;LIFE LLQ&nbhy;LEASE as described in Section
   5.2.4 "ACK + Answers"). <xref
   target="ack-answers"/>, "<xref
   target="ack-answers" format="title"/>").
        </t>
        <t>
   Servers MUST NOT <bcp14>MUST NOT</bcp14> garbage collect LLQs that fail to complete
   the four-
   way four-way handshake until the initially granted LEASE&nbhy;LIFE LLQ&nbhy;LEASE has
   elapsed.
        </t>
      </section>

      <section title="LLQ numbered="true" toc="default" anchor="four-way-handshake">
        <name>LLQ Setup Four-Way Handshake">
<figure><artwork>
The Handshake</name>
<t>The four phases of the handshake include:

1)
</t>

<ul empty="true">
<li>
<dl indent="24">
<dt>1)  Setup Request        client
</dt>
<dd>client to server, identifies LLQ(s) requested

2)
</dd>
<dt>2)  Setup Challenge      server
</dt>
<dd>server to client, provides error(s)
unique identifiers for successful requested LLQs, and unique identifiers
error(s) for
                        the successful requests

3) unsuccessful requested LLQs.
</dd>
<dt>3)  Challenge Response   client
</dt>
<dd>client to server, echoes identifier(s), demonstrating client's
reachability and willingness to participate

4)
</dd>
<dt>4)  ACK + Answers        server
</dt>
<dd>server to client, confirms setup and provides initial answers
</artwork></figure>
</dd>
</dl>
</li>
</ul>

        <section title="Setup Request"> numbered="true" toc="default" anchor="setup-request">
          <name>Setup Request</name>
          <t>
   A request for an LLQ is formatted like a standard DNS query, query but with
   an OPT RR pseudo&nbhy;RR containing LLQ metadata in its Additional
   section. LLQ
   setup requests
   Setup Requests are identified by the LLQ&nbhy;SETUP opcode and a
   zero&nbhy;valued LLQ&nbhy;ID.
          </t>
          <t>
   The request MAY <bcp14>MAY</bcp14> contain multiple questions to set up
   multiple LLQs.
   A request Setup Request consisting of multiple questions MUST <bcp14>MUST</bcp14>
   contain multiple LLQ
   metadata sections,
   OPTIONS, one per question, with metadata sections the LLQ OPTIONS in the
   same order as the questions they correspond to (i.e., the first
   metadata section
   LLQ OPTION corresponds to the first question, the second
   metadata section
   LLQ OPTION corresponds to the second question, etc.) etc.). If
   requesting multiple LLQs, clients SHOULD <bcp14>SHOULD</bcp14> request the same LEASE&nbhy;LIFE
   LLQ&nbhy;LEASE
   for each LLQ. Requests over UDP MUST NOT <bcp14>MUST NOT</bcp14> contain multiple
   questions
   if doing so would cause the message to not fit in exceed a single IP packet.
          </t>
          <t>
   A client MUST NOT <bcp14>MUST NOT</bcp14> request multiple identical LLQs (i.e.,
   containing
   the same qname/type/class) from the same source IP address and port.
   This requirement is to avoid unnecessary load on servers.

   In the case of multiple independent client implementations that
   may run on the same device without knowledge of each other,
   it is allowable if they by chance send LLQ requests for the same
   qname/type/class. These independent implementations on the same
   client will be using different source ports. Likewise,
   to the server,
   multiple independent clients behind the same NAT gateway
   will appear as if they were
   multiple independent clients using different ports on the same host. host,
   and this is also allowable.

          </t>
          <t>
   The query MUST NOT <bcp14>MUST NOT</bcp14> be for record type ANY (255), class ANY
   (255), or
   class NONE (0).
          </t>

				<t>
   Setup

<table anchor="OPT-RR-LLQ">
  <name>Setup Request OPT&nbhy;RR LLQ Metadata Format:
				</t>

<figure><artwork>
Field Name        Field Type     Description
---------------------------------------------------------------------
OPTION-CODE       u_int16_t      LLQ (1)
OPTION-LENGTH     u_int16_t      Length OPTION Format</name>
  <thead>
    <tr>
      <th>Field Name</th>
      <th>Field Type</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>OPTION-CODE</td>
      <td>u_int16_t</td>
      <td>LLQ (1)</td>
    </tr>
    <tr>
      <td>OPTION-LENGTH</td>
      <td>u_int16_t</td>
      <td>Length of following fields (18)
VERSION           u_int16_t      Version (18)</td>
    </tr>
    <tr>
      <td>LLQ-VERSION</td>
      <td>u_int16_t</td>
      <td>Version of LLQ protocol implemented by requester (1)
LLQ-OPCODE        u_int16_t      LLQ-SETUP (1)
ERROR-CODE        u_int16_t      NOERROR (0)
LLQ-ID            u_int64_t      0
LEASE-LIFE        u_int32_t      Desired (1)</td>
    </tr>
    <tr>
      <td>LLQ-OPCODE</td>
      <td>u_int16_t</td>
      <td>LLQ-SETUP (1)</td>
    </tr>
    <tr>
      <td>LLQ-ERROR</td>
      <td>u_int16_t</td>
      <td>NO-ERROR (0)</td>
    </tr>
    <tr>
      <td>LLQ-ID</td>
      <td>u_int64_t</td>
      <td>0</td>
    </tr>
    <tr>
      <td>LLQ-LEASE</td>
      <td>u_int32_t</td>
      <td>Desired life of LLQ request

These fields MUST request</td>
    </tr>
  </tbody>
</table>
<t>The Setup Request LLQ OPTION <bcp14>MUST</bcp14> be repeated once for each
additional query in the
Question section.
</artwork></figure>
<?rfc needLines="40" ?>
</t>

        </section>
        <section title="Setup Challenge"> numbered="true" toc="default" anchor="setup-challenge">
          <name>Setup Challenge</name>
          <t>
   Upon receiving an LLQ Setup Request, a server implementing LLQs will
   send a Setup Challenge to the requester (client). An LLQ Setup
   Challenge is a DNS Response, response, with the DNS message ID matching that of
   the request, Setup Request, and with all questions contained in the request Setup Request
   present
   in the Question section of the response. Additionally, the
   challenge contains a single OPT&nbhy;RR OPT pseudo&nbhy;RR with an LLQ metadata section OPTION for
   each LLQ request, indicating the success or failure of each request.
   Metadata sections MUST
   The LLQ OPTIONS <bcp14>MUST</bcp14> be in the same order as the questions
   they
   correspond to. Note that in a request Setup Request containing multiple
   questions
   questions, some LLQs may succeed, succeed while others may fail.
          </t>

				<t>
   Setup

<table anchor="CHALLENGE-OPT-RR-DATA">
  <name>Setup Challenge OPT&nbhy;RR RDATA Format:
				</t>

<figure><artwork>
Field Name        Field Type     Description
---------------------------------------------------------------------
OPTION-CODE       u_int16_t      LLQ (1)
OPTION-LENGTH     u_int16_t      Length LLQ OPTION Format</name>
  <thead>
    <tr>
      <th>Field Name</th>
      <th>Field Type</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>OPTION-CODE</td>
      <td>u_int16_t</td>
      <td>LLQ (1)</td>
    </tr>
    <tr>
      <td>OPTION-LENGTH</td>
      <td>u_int16_t</td>
      <td>Length of following fields (18)
VERSION           u_int16_t      Version (18)</td>
    </tr>
    <tr>
      <td>LLQ-VERSION</td>
      <td>u_int16_t</td>
      <td>Version of LLQ protocol implemented in server (1)
LLQ-OPCODE        u_int16_t      LLQ-SETUP (1)
ERROR-CODE        u_int16_t      [As Appropriate]
LLQ-ID            u_int64_t      [As Appropriate]
LEASE-LIFE        u_int32_t      [As Appropriate]
</artwork></figure> (1)</td>
    </tr>
    <tr>
      <td>LLQ-OPCODE</td>
      <td>u_int16_t</td>
      <td>LLQ-SETUP (1)</td>
    </tr>
    <tr>
      <td>LLQ-ERROR</td>
      <td>u_int16_t</td>
      <td>[As Appropriate]</td>
    </tr>
    <tr>
      <td>LLQ-ID</td>
      <td>u_int64_t</td>
      <td>[As Appropriate]</td>
    </tr>
    <tr>
      <td>LLQ-LEASE</td>
      <td>u_int32_t</td>
      <td>[As Appropriate]</td>
    </tr>
  </tbody>
</table>

          <t>
   These fields MUST
   The Setup Challenge LLQ OPTION <bcp14>MUST</bcp14> be repeated once for
   each query in the Questions
   section of the Setup Request. Challenge.
   Further details for LLQ&nbhy;ERROR, LLQ&nbhy;ID and LLQ&nbhy;LEASE are
   given below.
          </t>

<?rfc needLines="40" ?>

          <t>
   LLQ Metadata field descriptions:
   LLQ&nbhy;ERROR:
          </t>

<figure><artwork>
ERROR-CODE:     Possible values include:

   NO-ERROR:    The

<ul empty="true">
<li>
 <dl indent="18">
         <dt>NO-ERROR:
         </dt>
         <dd>The LLQ Setup Request was successful.

   FORMAT-ERR:  The
         </dd>
<dt>FORMAT-ERR:
</dt>
<dd>The LLQ was improperly formatted.  Note that if the rest of the DNS
message is properly formatted, the DNS header error code MUST NOT <bcp14>MUST
NOT</bcp14> include a format error code, as this would cause confusion since to do so would cause ambiguity
between the case where a client sends a valid LLQ Setup Request to a server
that does not understand the LLQ format, and the case where a client
                that sends a malformed LLQs.

   SERV-FULL:   The
LLQ Setup Request to a server that does understand LLQ.
</dd>

<dt>SERV-FULL:
</dt>
<dd>The server cannot grant the LLQ request because it is
                overloaded, overloaded or the
request exceeds the server's rate limit (see Section 8 "Security Considerations"). <xref
target="security-considerations"/>, <xref target="security-considerations"
format="title"/>).  Upon
returning this error, the server MUST <bcp14>MUST</bcp14> include in the LEASE-LIFE LLQ-LEASE
field a time interval, in seconds, after which the client may re-try retry the LLQ
Setup.

   STATIC:      The
</dd>

<dt>STATIC:
</dt>
<dd>The data for this name and type is not expected to change frequently, and
the server therefore server, therefore, does not support the requested LLQ.  The client MUST NOT poll
                for this name
<bcp14>MUST</bcp14> honor the resource record TTLs returned and type,
<bcp14>MUST NOT</bcp14> poll sooner than indicated by those TTLs,
nor should it re-try retry the LLQ
                Setup, Setup for this name and should instead honor the normal resource
                record TTLs returned.

   BAD-VERS:    The type.
</dd>

<dt>BAD-VERS:
</dt>
<dd>The protocol version specified in the client's
                request Setup Request is not
supported by
the server.

   UNKNOWN-ERR: The
</dd>

<dt>UNKNOWN-ERR:
</dt>
<dd>The LLQ was not granted for an unknown some other reason
</artwork></figure>

<?rfc needLines="40" ?>
				<t>
   LLQ&nbhy;ID: On not covered by the preceding
error code values.
</dd>

 </dl>

</li>
</ul>

<dl indent="18">
<dt>LLQ&nbhy;ID:
</dt>
<dd>On success, a random number generated by the server that is unique on the
server for the
requested name/type/class. The LLQ&nbhy;ID SHOULD <bcp14>SHOULD</bcp14> be an
unpredictable random number. A possible method of allocating LLQ&nbhy;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.
				</t>

				<t>
</dd>

<dt>
</dt>
<dd>
On error, the LLQ&nbhy;ID is set to 0.
				</t>

				<t>
   LEASE&nbhy;LIFE: On
</dd>

<dt>LLQ&nbhy;LEASE:
</dt>

<dd>On success, the actual life of the LLQ, in 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
   MAY <bcp14>MAY</bcp14> discard the LLQ
after this LEASE&nbhy;LIFE LLQ&nbhy;LEASE expires unless the LLQ has been renewed by the
client (see Section 7 "LLQ Lease-Life Expiration"). <xref target="LLQ-LLE"/>, "<xref target="LLQ-LLE"
format="title"/>").  The server MUST NOT <bcp14>MUST NOT</bcp14> generate events (see Section 6 "Event Responses")
<xref target="event-responses"/>, "<xref target="event-responses"
format="title"/>") for expired LLQs.
				</t>

				<t>
</dd>

<dt></dt>
<dd>
 On SERV&nbhy;FULL error, LEASE&nbhy;LIFE MUST LLQ&nbhy;LEASE <bcp14>MUST</bcp14> be set to a time
 interval, in seconds, after which the client may re&nbhy;try retry the LLQ Setup.
				</t>

				<t>
</dd>
<dt>
</dt>
<dd>
On other errors, the LEASE&nbhy;LIFE MUST LLQ&nbhy;LEASE <bcp14>MUST</bcp14> be set to 0.
				</t>
<?rfc needLines="40" ?>
</dd>

</dl>

</section>
        <section title="Challenge Response"> numbered="true" toc="default" anchor="challenge-response">
          <name>Challenge Response</name>
          <t>

   Upon issuing a Setup Request, a client listens for a Setup Challenge
   (5.2.2), re-transmitting
   (<xref target="setup-challenge"/>) retransmitting the request Setup Request as
   necessary (5.1).
   (<xref target="setup-message-retransmission"/>). After
   receiving a successful Setup Challenge, the client SHOULD <bcp14>SHOULD</bcp14>
   send a Challenge
   Response to the server. This Challenge Response is a DNS request
   with questions from as in the request Setup Request and challenge, Setup Challenge, and a single OPT&nbhy;RR
   OPT pseudo&nbhy;RR in
   the Additional section, with the OPT&nbhy;RR RDATA identical LLQ OPTIONS corresponding to the
   OPT&nbhy;RR RDATA
   LLQ OPTIONS contained in the Setup Challenge (i.e., echoing, for
   each set of fields, LLQ OPTION, the random LLQ&nbhy;ID and the granted lease life). LLQ&nbhy;LEASE). If
   the challenge response Challenge Response contains multiple questions, the first
   question MUST <bcp14>MUST</bcp14> correspond to the first OPT&nbhy;RR RDATA tuple, LLQ OPTION, etc.
          </t>
          <t>
   If the Setup Request for a particular LLQ fails with a STATIC error, the
   client MUST NOT <bcp14>MUST NOT</bcp14>
   poll the server. server for that LLQ. The client SHOULD <bcp14>SHOULD</bcp14> honor the
   resource record TTLs
   contained in the response.
          </t>
          <t>
   If the a Setup Request fails with a SERV&nbhy;FULL error, the client MAY
   re&nbhy;try
   <bcp14>MAY</bcp14>
   retry the LLQ Setup Request (5.2.1) (<xref target="setup-request"/>) after the time
   indicated in the
   LEASE&nbhy;LIFE
   LLQ&nbhy;LEASE field.
          </t>

          <t>
   If the Setup Request fails with an error other than STATIC or
   SERV&nbhy;FULL, or the server is determined not to support LLQ
   (i.e., the client receives a DNS response with a nonzero RCODE,
   or a DNS response containing no LLQ option), the
   client MAY <bcp14>MAY</bcp14> poll the server periodically with standard DNS
   queries,
   inferring Add and Remove events Events (see Section 6 <xref target="event-responses"/>,
   "Event Responses")
   by comparing answers to these queries. The client
   SHOULD NOT
   <bcp14>SHOULD NOT</bcp14> poll more than once every 15 minutes for a given
   query.
   The client MUST NOT <bcp14>MUST NOT</bcp14> poll if it receives a STATIC error code
   in the
   acknowledgment.
          </t>
<?rfc needLines="40" ?>
        </section>
        <section title="ACK numbered="true" toc="default" anchor="ack-answers">
          <name>ACK + Answers"> Answers</name>
          <t>

   Upon receiving a correct Challenge Response, a server MUST <bcp14>MUST</bcp14>
   return an
   acknowledgment, completing the LLQ setup, and provide all current
   answers to the question(s).
          </t>
          <t>
   To acknowledge a successful Challenge Response, i.e., a Challenge
   Response in which the LLQ&nbhy;ID and LEASE&nbhy;LIFE LLQ&nbhy;LEASE echoed by the client
   match the values issued by the server, the server MUST <bcp14>MUST</bcp14> send
   a DNS
   response containing all available answers to the question(s)
   contained in the original Setup Request, along with all additional
   resource records appropriate for those answers in the Additional
   section. The Additional section also contains an OPT&nbhy;RR LLQ OPTIONS formatted as
   follows:
          </t>

			<t>
   Successful

<table anchor="SUCCESSFUL-ACK-ANSWERS-OPT-RR-RDATA">
  <name>Successful ACK + Answers OPT&nbhy;RR RDATA Format:
			</t>

<figure><artwork>
Field Name        Field Type     Description
---------------------------------------------------------------------
OPTION-CODE       u_int16_t      LLQ
OPTION-LENGTH     u_int16_t      Length LLQ OPTION Format</name>
  <thead>
    <tr>
      <th>Field Name</th>
      <th>Field Type</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>OPTION-CODE</td>
      <td>u_int16_t</td>
      <td>LLQ (1)</td>
    </tr>
    <tr>
      <td>OPTION-LENGTH</td>
      <td>u_int16_t</td>
      <td>Length of following fields, as
                                 appropriate
VERSION           u_int16_t      Version fields (18)</td>
    </tr>
    <tr>
      <td>LLQ-VERSION</td>
      <td>u_int16_t</td>
      <td>Version of LLQ protocol implemented in server
LLQ-OPCODE        u_int16_t      LLQ-SETUP (1)
ERROR-CODE        u_int16_t      NO-ERROR
LLQ-ID            u_int64_t      Originally (1)</td>
    </tr>
    <tr>
      <td>LLQ-OPCODE</td>
      <td>u_int16_t</td>
      <td>LLQ-SETUP (1)</td>
    </tr>
    <tr>
      <td>LLQ-ERROR</td>
      <td>u_int16_t</td>
      <td>NO-ERROR (0)</td>
    </tr>
    <tr>
      <td>LLQ-ID</td>
      <td>u_int64_t</td>
      <td>Originally granted ID, echoed in client's Response
LEASE-LIFE        u_int32_t      Remaining Response</td>
    </tr>
    <tr>
      <td>LLQ-LEASE</td>
      <td>u_int32_t</td>
      <td>Remaining life of LLQ, in seconds
</artwork></figure> seconds</td>
    </tr>
  </tbody>
</table>

          <t>
   If there is a significant delay in receiving a Challenge Response, or
   multiple Challenge Responses are issued (possibly because they were lost
   en route to the client, causing the client to re&nbhy;send resend the Challenge
   Response), the server MAY <bcp14>MAY</bcp14> decrement the LEASE&nbhy;LIFE LLQ&nbhy;LEASE by
   the time
   elapsed since the Setup Challenge was initially issued.
          </t>
          <t>
   If the setup is completed over UDP and all initially available
   answers to the question(s), additional records, and the OPT&nbhy;RR OPT pseudo&nbhy;RR
   do not
   fit in a single IP packet, some or all additional records (excluding the
   OPT&nbhy;RR) MUST
   OPT pseudo&nbhy;RR) <bcp14>MUST</bcp14> be omitted. If, after omission of
   all additional
   records, the answers still do not fit in a single message, answers
   MUST
   <bcp14>MUST</bcp14> be removed until the message fits in a single IP
   packet. These
   answers not delivered in the ACK + Answers MUST <bcp14>MUST</bcp14> be delivered
   without undue delay to the client via Add Events (Section 6 "Event Responses"). (<xref
   target="event-responses"/>, "<xref
   target="event-responses" format="title"/>").
          </t>
        </section>
      </section>
      <section title="Resource numbered="true" toc="default" anchor="resource-record-ttls">
        <name>Resource Record TTLs"> TTLs</name>
        <t>
   The TTLs of resource records contained in answers to successful LLQs
   SHOULD
   <bcp14>SHOULD</bcp14> be ignored by the client. The client MAY
   <bcp14>MAY</bcp14> cache LLQ answers until the client receives a gratuitous
   announcement (see Section 6
   "Event Responses") <xref target="event-responses"/>, "<xref
   target="event-responses" format="title"/>")
   indicating that the answer to the LLQ has changed.  The client SHOULD NOT
   <bcp14>SHOULD NOT</bcp14> cache answers after the LLQs LEASE&nbhy;LIFE LLQ&nbhy;LEASE
   expires without being refreshed (see Section 7 <xref target="LLQ-LLE"/>, "LLQ
   Lease-Life Expiration").  If an LLQ request fails, the client SHOULD NOT <bcp14>SHOULD
   NOT</bcp14> cache answers for a period longer than the client's polling
   interval.
        </t>
        <t>
   Note that resource records intended specifically to be transmitted
   via LLQs (e.g., DNS DNS-based Service Discovery resource records) may have
   unusually short TTLs. This is because it is assumed that the records
   may change frequently, and that a client's cache coherence will be
   maintained via the LLQ and gratuitous responses. Short TTLs prevent
   stale information from residing in intermediate DNS recursive resolvers
   that are
   not LLQ-aware. LLQ aware.
        </t>
        <t>
   TTLs of resource records included in the Additional section of an
   LLQ response (which do not directly answer the LLQ) SHOULD <bcp14>SHOULD</bcp14>
   be honored
   by the client.
        </t>
<?rfc needLines="40" ?>
      </section>
    </section>
    <section title="Event Responses"> numbered="true" toc="default" anchor="event-responses">
      <name>Event Responses</name>
      <t>
   When a change ("event") occurs to a name server's zone, the server
   MUST
   <bcp14>MUST</bcp14> check if the new or deleted resource records answer any
   LLQs.
   If so, the changes MUST <bcp14>MUST</bcp14> be communicated to the LLQ
   requesters in
   the form of a gratuitous DNS response sent to the client, with the
   relevant question(s) being answered in the Question section, and the corresponding answers to
   these questions
   in the Answer section. The response also includes
   an OPT RR pseudo&nbhy;RR in the Additional section. This OPT RR pseudo&nbhy;RR
   contains, in its
   RDATA, an entry LLQ OPTION for each LLQ being answered in the message. Entries Each LLQ
   OPTION
   must include the LLQ&nbhy;ID. This reduces the potential for spoof events
   being sent to a client.
      </t>

			<t>
   Event

<table anchor="EVENT-RESPONSE-OPT-RR-RDATA">
  <name>Event Response OPT&nbhy;RR RDATA Format:
			</t>

<figure><artwork>
Field Name        Field Type     Description
---------------------------------------------------------------------
OPTION-CODE       u_int16_t      LLQ (1)
OPTION-LENGTH     u_int16_t      Length LLQ OPTION Format</name>
  <thead>
    <tr>
      <th>Field Name</th>
      <th>Field Type</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>OPTION-CODE</td>
      <td>u_int16_t</td>
      <td>LLQ (1)</td>
    </tr>
    <tr>
      <td>OPTION-LENGTH</td>
      <td>u_int16_t</td>
      <td>Length of following fields (18)
VERSION           u_int16_t      Version (18)</td>
    </tr>
    <tr>
      <td>LLQ-VERSION</td>
      <td>u_int16_t</td>
      <td>Version of LLQ protocol implemented in server (1)
LLQ-OPCODE        u_int16_t      LLQ-EVENT (3)
ERROR-CODE        u_int16_t      0
LLQ-ID            u_int64_t      [As Appropriate]
LEASE-LIFE        u_int32_t      0
</artwork></figure> (1)</td>
    </tr>
    <tr>
      <td>LLQ-OPCODE</td>
      <td>u_int16_t</td>
      <td>LLQ-EVENT (3)</td>
    </tr>
    <tr>
      <td>LLQ-ERROR</td>
      <td>u_int16_t</td>
      <td>NO-ERROR (0)</td>
    </tr>
    <tr>
      <td>LLQ-ID</td>
      <td>u_int64_t</td>
      <td>[As Appropriate]</td>
    </tr>
    <tr>
      <td>LLQ-LEASE</td>
      <td>u_int32_t</td>
      <td>0</td>
    </tr>

  </tbody>
</table>

      <t>
   Gratuitous responses for a single LLQ MAY <bcp14>MAY</bcp14> be batched, batched such
   that
   multiple changes are communicated in a single message.
   Responses MUST NOT <bcp14>MUST NOT</bcp14> be batched if this would cause a message
   that
   would otherwise fit in a single IP packet to be truncated. While
   responses MAY <bcp14>MAY</bcp14> be deferred to provide opportunities for
   batching,
   responses SHOULD NOT <bcp14>SHOULD NOT</bcp14> be delayed, for purposes of batching,
   for more
   than 30 seconds, as this would cause an unacceptable latency for the
   client.
      </t>
      <t>
   After sending a gratuitous response, the server MUST <bcp14>MUST</bcp14> listen
   for an
   acknowledgment from the client. If the client does not respond, the
   server MUST re&nbhy;send <bcp14>MUST</bcp14> resend the response. The server MUST re&nbhy;send 2
   <bcp14>MUST</bcp14> resend two times
   (for a total of 3 transmissions), after which the server MUST
   <bcp14>MUST</bcp14>
   consider the client to be unreachable and delete its LLQ. The server
   MUST
   <bcp14>MUST</bcp14> listen for 2 seconds before re&nbhy;sending resending the response, 4
   more
   seconds before re&nbhy;sending resending again, and must wait an additional 8
   seconds after the 3rd transmission before terminating the LLQ.
      </t>
      <t>
   The DNS message header of the response SHOULD <bcp14>SHOULD</bcp14> include an
   unpredictable
   random number in the DNS message ID field, which is to be echoed in
   the client's acknowledgement. acknowledgment.
      </t>
      <section title="Add Events"> numbered="true" toc="default">
        <name>Add Events</name>
        <t>
   Add events Events occur when a new resource record appears, usually as the
   result of a dynamic update <xref target="RFC2136"/>, target="RFC2136" format="default"/>, that
   answers an LLQ. This
   record must be sent in the Answer section of the event to the client.
   Records that normally accompany this record in responses MAY <bcp14>MAY</bcp14>
   be
   included in the Additional section, section as per truncation restrictions
   described above.
        </t>
      </section>
      <section title="Remove Events"> numbered="true" toc="default">
        <name>Remove Events</name>
        <t>
   Remove events Events occur when a resource record previously sent to a
   client, either in an initial response, response or in an Add Event, becomes
   invalid (normally as a result of being removed via a dynamic update).
   The deleted resource record is sent in the Answer section of the
   event to the client. The resource record TTL is set to -1,
   indicating that the record has been removed.
        </t>
      </section>
      <section title="Gratuitous numbered="true" toc="default">
        <name>Gratuitous Response Acknowledgments"> Acknowledgments</name>
        <t>
   Upon receiving a gratuitous response ("event"), the client MUST
   <bcp14>MUST</bcp14> send
   an acknowledgment to the server. This acknowledgment is a DNS
   response echoing the OPT&nbhy;RR OPT pseudo&nbhy;RR contained in the event, with the
   message
   ID of the gratuitous response echoed in the message header. The
   acknowledgment MUST <bcp14>MUST</bcp14> be sent to the source IP address and
   port from
   which the event originated.
        </t>
<?rfc needLines="40" ?>
      </section>
    </section>
    <section title="LLQ numbered="true" toc="default" anchor="LLQ-LLE">
      <name>LLQ Lease-Life Expiration">
		<t>
		</t> Expiration</name>

      <section title="Refresh Request"> numbered="true" toc="default">
        <name>Refresh Request</name>
        <t>
   If the client desires to maintain the LLQ beyond the duration specified in
   the LEASE&nbhy;LIFE LLQ&nbhy;LEASE field of the Ack ACK + Answers
   (5.2), (<xref
   target="ack-answers"/>), the client MUST <bcp14>MUST</bcp14> send a
   Refresh Request. A Refresh Request is identical to an LLQ Challenge
   Response (5.3), (<xref target="challenge-response"/>) but with the LLQ&nbhy;OPCODE
   set to
   LLQ&nbhy;REFRESH. Unlike a Challenge Response, a Refresh Request returns no
   answers.
        </t>

        <t>
   The client SHOULD <bcp14>SHOULD</bcp14> refresh an LLQ when 80% of its lease life
   LLQ&nbhy;LEASE has
   elapsed.
        </t>
        <t>
   As a means of reducing network traffic, when constructing refresh
   messages the client SHOULD <bcp14>SHOULD</bcp14> include all LLQs established with
   a given
   server, even those not yet close to expiration. However, at least
   one LLQ MUST <bcp14>MUST</bcp14> have elapsed at least 80% of its original LEASE&nbhy;LIFE.
   LLQ&nbhy;LEASE.
   The client MUST NOT <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
   fits in a single IP packet.  (These LLQs SHOULD <bcp14>SHOULD</bcp14> be refreshed
   in a
   separate message when 80% of one or more of their lease lives have
   elapsed.)  When refreshing multiple LLQs simultaneously, the message
   contains multiple questions, questions and a single OPT&nbhy;RR OPT pseudo&nbhy;RR with multiple
   LLQ
   metadata sections,
   OPTIONS, one per question, with the metadata sections LLQ OPTIONS in
   the same order as the questions they correspond to.
        </t>
        <t>
   The client SHOULD <bcp14>SHOULD</bcp14> specify the original lease life LLQ&nbhy;LEASE
   granted in the LLQ
   response as the desired LEASE&nbhy;LIFE LLQ&nbhy;LEASE in the refresh request. Refresh Request. If
   refreshing multiple LLQs simultaneously, the client SHOULD <bcp14>SHOULD</bcp14>
   request
   the same lease life LLQ&nbhy;LEASE for all LLQs being refreshed (with the exception
   of termination requests, requests; see below).
        </t>
        <t>
   To terminate an LLQ prior
   to its scheduled expiration (for instance, when the client terminates
   a DNS DNS-based Service Discovery browse operation, operation or when a client is about to go
   to sleep or shut down) down), the client specifies a lease life an LLQ&nbhy;LEASE value of 0.
        </t>
        <t>
   The client MUST <bcp14>MUST</bcp14> listen for an acknowledgment from the
   server. The
   client MAY re&nbhy;try <bcp14>MAY</bcp14> retry up to two more times (for a total of 3
   attempts)
   before considering the server down or unreachable. The client MUST
   NOT re&nbhy;try <bcp14>MUST
   NOT</bcp14> retry a first time before 90% of the lease life LLQ&nbhy;LEASE has expired, expired
   and
   MUST NOT re&nbhy;try
   <bcp14>MUST NOT</bcp14> retry again before 95% of the lease life LLQ&nbhy;LEASE has
   expired. If
   the server is determined to be down, the client MAY <bcp14>MAY</bcp14>
   periodically
   attempt to re-establish the LLQ via an LLQ Setup Request message.
   The client MUST NOT <bcp14>MUST NOT</bcp14> attempt the LLQ Setup Request more than
   once per
   hour.
        </t>
      </section>
      <section title="LLQ numbered="true" toc="default">
        <name>LLQ Refresh Acknowledgment"> Acknowledgment</name>

        <t>
   Upon receiving an LLQ Refresh message, a server MUST <bcp14>MUST</bcp14> send an
   acknowledgment of the Refresh. This acknowledgment is formatted like
   the Setup ACK "ACK + Answers" message described in 5.2.3, <xref target="ack-answers"/>, but
   with the following variations:
        </t>
<ul>
<li>
   <t>
   The LLQ&nbhy;OPCODE
   It contains no answers.
        </t>
</li>
<li>
   <t>
   The LLQ&nbhy;OPCODE is set to LLQ&nbhy;REFRESH.
        </t>
</li>
<li>
   <t>
   NO&nbhy;SUCH&nbhy;LLQ MUST <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
   LLQ&nbhy;ID in the request).
        </t>
</li>
<li>
        <t>
   The LLQ&nbhy;ID in the acknowledgment is set to the LLQ&nbhy;ID in the
   request.
        </t>
<?rfc needLines="40" ?>
</li>
</ul>

  </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default" anchor="security-considerations">
      <name>Security Considerations</name>
      <t>
   Without care taken in the design of
   In datagram-based protocols such as this,
   (i.e., protocols running over UDP, or directly over IP, or similar), servers
   may be susceptible to denial of service (DOS) denial-of-service (DoS) attacks, and clients
   may be subjected to packet storms. Mechanisms have been added to the
   protocol Carefully designed mechanisms are needed
   to limit potential for these attacks.
      </t>
      <t>
   Note: This section contains no new protocol elements -- it serves
   only to explain the rationale behind protocol elements described
   above,
   above as they relate to security.
      </t>
      <section title="Server DOS"> numbered="true" toc="default" anchor="server-dos">
        <name>Server DoS</name>
        <t>
   LLQs require that servers be stateful, maintaining entries for each LLQ
   over a potentially long period of time. If unbounded in quantity, these
   entries may overload the server. By returning SERV&nbhy;FULL in Setup
   Challenges, the sever server may limit the maximum number of LLQs it
   maintains. Additionally, the server may return SERV&nbhy;FULL to limit the
   number of LLQs requested for a single name and type, or by a single
   client. This throttling may be in the form of a hard limit, or, preferably,
   by token-bucket rate limiting. Such rate limiting should occur rarely in
   normal use and is intended to prevent
   DOS DoS attacks -- thus thus, it is not built
   into the protocol explicitly, explicitly but is instead implemented at the discretion
   of an administrator via the SERV&nbhy;FULL error and the LEASE&nbhy;LIFE LLQ&nbhy;LEASE
   field to indicate a retry time to the client.
        </t>
      </section>
      <section title="Client numbered="true" toc="default">
        <name>Client Packet Storms"> Storms</name>
        <t>
   In addition to protecting the server from DOS DoS attacks, the LLQ protocol
   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
   upon setup, demonstrating reachability and willingness of the client
   to participate, and by requiring that gratuitous responses be ACK'd
   by the client.
        </t>
        <t>
   Additionally, rate-limiting rate limiting by LLQ client address, as described in
   (8.1)
   <xref target="server-dos"/>, serves to limit the number of packets that can
   be delivered to
   an unsuspecting client.
        </t>
      </section>
      <section title="Spoofing"> numbered="true" toc="default">
        <name>Spoofing</name>
        <t>
   A large random ID greatly reduces the risk of an off-path attacker
   sending spoof packets to the client (containing spoof events)
   or to the server (containing phony requests or refreshes).
        </t>
      </section>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
  The EDNS(0) OPTION CODE 1 has already been assigned for this DNS extension.
  IANA is requested to update has updated the record in the DNS EDNS(0) "DNS EDNS0 Option Codes (OPT)" registry
  from "On-hold" to "Optional", "Optional" and to has set the reference to indicate the RFC number under which this document is
  published. document.
      </t>

      <t>
  TCP and UDP ports 5352 have already been assigned for LLQ.  IANA is
  requested to add has
  added a reference to indicate the RFC number under which
  this document is published.
		</t>
		<t>
  No additional IANA services are required by this document.
      </t>
    </section>

	<section title="Acknowledgments">
		<t>
   The concepts described in this document were originally explored, developed
   and implemented with help from Chris Sharp and Roger Pantos.
		</t>
		<t>In 2005 and 2006 Kiren Sekar made significant contributions to the
		first two drafts 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 2005.</t>
	</section>

  </middle>
  <back>

<references title='Normative References'>
&RFC1035;
&RFC2119;
&RFC2782;
&RFC6891;
&RFC8174;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<reference anchor='Push'> anchor='RFC8765' target="https://www.rfc-editor.org/info/rfc8765">
        <front>
        <title>DNS Push Notifications [[RFC Editor note: Please update reference "Push" to refer to assigned RFC number for that document]]</title>
	</title>
        <author initials='T' surname='Pusateri' fullname='Tom Pusateri'>
                <organization />
        </author>
        <author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
                <organization />
        </author>
        <date month='September' day='18' year='2018' month='June' year='2020' />

	<abstract><t>The Domain Name System (DNS) was designed to return
	matching records efficiently for queries for data that are relatively
	static.  When those records change frequently, DNS is still efficient at
	returning the updated results when polled, as long as the polling rate
	is not too high.  But there exists no mechanism for a client to be
	asynchronously notified when these changes occur.  This document defines
	a mechanism for a client to be notified of such changes to DNS records,
	called DNS Push Notifications.</t></abstract>
        </front>
        <seriesInfo name='Internet-Draft' value='draft-ietf-dnssd-push-15' />
	<format type='TXT'
			target='http://www.ietf.org/internet-drafts/draft-ietf-dnssd-push-15.txt' name='RFC' value='8765' />
        <seriesInfo name="DOI" value="10.17487/RFC8765"/>
</reference>

      </references>

<references title='Informative References'>
&RFC2136;
&RFC4787;
&RFC4953;
&RFC5382;
&RFC6281;
&RFC6762;
&RFC6763;
&RFC6886;
&RFC6887;
&RFC7857;
      <references>
        <name>Informative References</name>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4787.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4953.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5382.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6281.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6886.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6887.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7857.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8490.xml"/>

        <reference anchor='SYN'> anchor="SYN"
		   target="https://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/ipj_9-4.pdf">
          <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'> initials="W." surname="Eddy" fullname="Wesley Eddy">
              <organization>Verizon Federal Network Systems</organization>
              <address>
                <email>weddy@grc.nasa.gov</email>
              </address>
            </author>
            <date year='2006' month='December' /> year="2006" month="December"/>
            <keyword>TCP</keyword>
          </front>
  <seriesInfo name="The Internet Protocol Journal," value='Cisco Systems' />
  <seriesInfo name='Volume' value='9' />
  <seriesInfo name='Number' value='4' />
  <format type='PDF' octets='882020' target="http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/ipj_9-4.pdf" />
  <format type='HTML' octets='65566' target="http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/syn_flooding_attacks.html" />
</reference>

<reference anchor='RFC8490' target='https://www.rfc-editor.org/info/rfc8490'>
<front>
<title>DNS Stateful Operations</title>
<author initials='R' surname='Bellis' fullname='Ray Bellis'>
    <organization />
</author>

<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
    <organization />
</author>

<author initials='J' surname='Dickinson' fullname='John Dickinson'>
    <organization />
</author>

<author initials='S' surname='Dickinson' fullname='Sara Dickinson'>
    <organization />
</author>

<author initials='T' surname='Lemon' fullname='Ted Lemon'>
    <organization />
</author>

<author initials='T' surname='Pusateri' fullname='Tom Pusateri'>
    <organization />
</author>

<date month='October' day='23' year='2018' />

<abstract><t>This document defines a new DNS OPCODE for DNS Stateful Operations (DSO).  DSO messages communicate operations within persistent stateful sessions, using type-length-value (TLV) syntax.  Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations.  This document updates RFC 1035 by adding a new DNS header opcode which has different message semantics, and a new result code.  This document updates RFC 7766 by redefining a session, providing new guidance on connection re-use, and providing a new mechanism for handling session idle timeouts.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8490'/>
<seriesInfo name='DOI' value='10.17487/RFC8490'/>

        </reference>

      </references>

<?rfc needLines="40" ?>
    </references>
    <section anchor="problems" title="Problems numbered="true" toc="default">
      <name>Problems with the LLQ Protocol"> Protocol</name>
      <t>
	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>
	LLQ's IETF Standards Track successor,
		<xref target="Push">DNS "DNS Push Notifications</xref>, Notifications"
	<xref target="RFC8765" format="default"></xref>, does not
	suffer from these problems, so all existing LLQ
	implementations are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to migrate to
	using DNS Push Notifications, and all new implementations are RECOMMENDED
	<bcp14>RECOMMENDED</bcp14> to implement DNS Push Notifications
	instead of LLQ.
      </t>
      <t>
	Known problems with LLQ are documented here for as a cautionary tale
	about the challenges of building an application protocol directly
	using datagrams (like IP or UDP) without the record. benefit of a
	mature and thoroughly reviewed
	intervening transport layer (such as TCP or QUIC).
      </t>
      <t>
	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>
		This
	<xref target="setup-message-retransmission"/> of this LLQ
	specification states: states, "Servers MUST NOT <bcp14>MUST
	NOT</bcp14> garbage collect LLQs that fail to complete the
	four-way handshake until the initially granted LEASE-LIFE LLQ-LEASE has
	elapsed." This is probably a mistake, 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"></xref>,
	is built using DNS Stateful
	Operations <xref target="RFC8490"/>, target="RFC8490" format="default"/>, which
	uses TLS over TCP,
		and 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"/> target="SYN"
	format="default"/> <xref target="RFC4953"/> target="RFC4953" format="default"/>.
      </t>
      <t>
	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"></xref>
	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>
	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"></xref>
	corrects this error by having only one single consistent way to
	deliver results.
      </t>
      <t>
	LLQ is built using UDP, and because the UDP protocol has no
	standardized way of indicating the start and end of a session,
	firewalls and NAT gateways tend to be fairly agressive aggressive about
	recycling UDP mappings that they believe to be disused <xref target="RFC4787"/>
	target="RFC4787" format="default"/> <xref target="RFC5382"/> target="RFC5382"
	format="default"/> <xref target="RFC7857"/>. target="RFC7857" format="default"/>.
	Using a high keepalive traffic rate to maintain firewall or
	NAT mapping state could remedy this, 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
		<xref target="RFC6886">NAT the NAT
	Port Mapping Protocol (NAT-PMP)</xref> and/or (NAT-PMP) <xref target="RFC6887">Port target="RFC6886"
	format="default"></xref> and/or Port Control Protocol (PCP)</xref> (PCP)
	<xref target="RFC6887" format="default"></xref> to establish
	longer port mapping lifetimes.  This solves the problem, problem but
	adds extra complexity, 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="default">
      <name>Acknowledgments</name>
      <t>
   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><contact fullname="Kiren Sekar"/> made significant 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>Thanks to Independent Stream Editor <contact fullname="Adrian Farrel"/> for his support and
assistance in the publication of this RFC.
</t>

    </section>
  </back>
</rfc>