doc: Add RFC documents

1 files changed, 1075 insertions, 0 deletions

diff --git a/doc/rfc/rfc8764.txt b/doc/rfc/rfc8764.txt
new file mode 100644
index 0000000..c6ca430
--- /dev/null
+++ b/doc/rfc/rfc8764.txt
@@ -0,0 +1,1075 @@
+
+
+
+
+Independent Submission                                       S. Cheshire
+Request for Comments: 8764                                   M. Krochmal
+Category: Informational                                       Apple Inc.
+ISSN: 2070-1721                                                June 2020
+
+
+                Apple's DNS Long-Lived Queries Protocol
+
+Abstract
+
+   Apple's DNS Long-Lived Queries (LLQ) is a 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 2020,
+   the LLQ protocol was superseded by the IETF Standards Track RFC 8765,
+   "DNS Push Notifications", which builds on experience gained with the
+   LLQ protocol to create a superior replacement.
+
+   The existing LLQ protocol deployed and used from 2005 to 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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not candidates for any level of Internet Standard;
+   see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8764.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Transition to DNS Push Notifications
+   2.  Conventions and Terminology Used in This Document
+   3.  Mechanisms
+     3.1.  Assigned Numbers
+     3.2.  Opt-RR Format
+   4.  LLQ Address and Port Identification
+   5.  LLQ Setup
+     5.1.  Setup Message Retransmission
+     5.2.  LLQ Setup Four-Way Handshake
+       5.2.1.  Setup Request
+       5.2.2.  Setup Challenge
+       5.2.3.  Challenge Response
+       5.2.4.  ACK + Answers
+     5.3.  Resource Record TTLs
+   6.  Event Responses
+     6.1.  Add Events
+     6.2.  Remove Events
+     6.3.  Gratuitous Response Acknowledgments
+   7.  LLQ Lease-Life Expiration
+     7.1.  Refresh Request
+     7.2.  LLQ Refresh Acknowledgment
+   8.  Security Considerations
+     8.1.  Server DoS
+     8.2.  Client Packet Storms
+     8.3.  Spoofing
+   9.  IANA Considerations
+   10. References
+     10.1.  Normative References
+     10.2.  Informative References
+   Appendix A.  Problems with the LLQ Protocol
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   In dynamic environments, DNS-based Service Discovery [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 [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.
+
+   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.
+
+   The mechanism defined in this document is now being replaced by DNS
+   Push Notifications [RFC8765] as explained in Section 1.1.
+
+
+1.1.  Transition to DNS Push Notifications
+
+   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 [RFC6281] service.
+
+   However, some problems were discovered, as described in Appendix A.
+   This operational experience with LLQ informed the design of its IETF
+   Standards Track successor, DNS Push Notifications [RFC8765].  Since
+   no further work is being done on the LLQ protocol, this LLQ
+   specification will not be updated to remedy these problems.
+
+   All existing LLQ implementations are RECOMMENDED to migrate to using
+   DNS Push Notifications instead.
+
+   Existing LLQ servers are RECOMMENDED to implement and support DNS
+   Push Notifications so that clients can begin migrating to the newer
+   protocol.
+
+   Existing LLQ clients are RECOMMENDED to query for the
+   "_dns-push-tls._tcp.<zone>" SRV record first, and then only if DNS
+   Push Notifications fail, fall back to query for
+   "_dns-llq._udp.<zone>" instead.  Use of the "_dns-llq._udp.<zone>"
+   SRV record is described in Section 4.
+
+   This will cause clients to prefer the newer protocol when possible.
+   It is RECOMMENDED 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 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.
+
+   New client and server implementations are RECOMMENDED to support only
+   DNS Push Notifications.
+
+2.  Conventions and Terminology Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Mechanisms
+
+   DNS Long-Lived Queries (LLQ) are implemented using the standard DNS
+   message format [RFC1035] in conjunction with an EDNS(0) OPT pseudo-RR
+   [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 [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.<zone> SRV record target a host that
+   does not implement LLQ is a configuration error.
+
+   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.
+
+3.1.  Assigned Numbers
+
+   This section describes constants used in this document.
+
+      EDNS(0) OPTION-CODE (recorded with IANA):
+
+         LLQ               1
+
+      LLQ-PORT 5352 (recorded with IANA)
+
+      LLQ Opcodes (specific to this LLQ EDNS(0) Option):
+
+         LLQ-SETUP         1
+         LLQ-REFRESH       2
+         LLQ-EVENT         3
+
+      LLQ Error Codes (specific to this LLQ EDNS(0) Option):
+
+         NO-ERROR          0
+         SERV-FULL         1
+         STATIC            2
+         FORMAT-ERR        3
+         NO-SUCH-LLQ       4
+         BAD-VERS          5
+         UNKNOWN-ERR       6
+
+3.2.  Opt-RR Format
+
+   As required by the EDNS(0) specification [RFC6891], all OPT
+   pseudo-RRs used in LLQs are formatted as follows:
+
+          +------------+--------------+-------------------------+
+          | Field Name | Field Type   | Description             |
+          +============+==============+=========================+
+          | NAME       | domain name  | MUST be 0 (root domain) |
+          +------------+--------------+-------------------------+
+          | TYPE       | u_int16_t    | OPT (41)                |
+          +------------+--------------+-------------------------+
+          | CLASS      | u_int16_t    | 0*                      |
+          +------------+--------------+-------------------------+
+          | TTL        | u_int32_t    | 0                       |
+          +------------+--------------+-------------------------+
+          | RDLEN      | u_int16_t    | length of all RDATA     |
+          +------------+--------------+-------------------------+
+          | RDATA      | octet stream | (see below)             |
+          +------------+--------------+-------------------------+
+
+                       Table 1: OPT-RRs Used in LLQs
+
+   * The CLASS field indicates, as per the EDNS(0) specification
+   [RFC6891], the sender'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 MAY set the CLASS field to 0.  The recipient MUST ignore
+   the class field if it is set to 0.
+
+   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.
+
+   +---------------+------------+-------------------------------------+
+   | Field Name    | Field Type | Description                         |
+   +===============+============+=====================================+
+   | OPTION-CODE   | u_int16_t  | LLQ (1)                             |
+   +---------------+------------+-------------------------------------+
+   | OPTION-LENGTH | u_int16_t  | Length of following fields (18)     |
+   +---------------+------------+-------------------------------------+
+   | LLQ-VERSION   | u_int16_t  | Version of LLQ protocol implemented |
+   +---------------+------------+-------------------------------------+
+   | LLQ-OPCODE    | u_int16_t  | Identifies LLQ operation            |
+   +---------------+------------+-------------------------------------+
+   | LLQ-ERROR     | u_int16_t  | Identifies LLQ errors               |
+   +---------------+------------+-------------------------------------+
+   | LLQ-ID        | u_int64_t  | Identifier for an LLQ               |
+   +---------------+------------+-------------------------------------+
+   | LLQ-LEASE     | u_int32_t  | Requested or granted life of LLQ,   |
+   |               |            | in seconds                          |
+   +---------------+------------+-------------------------------------+
+
+                           Table 2: LLQ OPTION
+
+   The size and meaning of the OPTION-CODE and OPTION-LENGTH fields are
+   as described in the EDNS(0) specification [RFC6891].  The remainder
+   of the fields 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.
+
+   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).
+
+4.  LLQ Address and Port Identification
+
+   The client requires a mechanism to determine to which server it
+   should send LLQ operations.
+
+   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 listen for
+   LLQs on a different port (typically 5352).  Clients, therefore, also
+   need a mechanism to determine to which port to send LLQ operations.
+
+   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.  If the record exists, then the server MUST
+   answer with that SOA record in the Answer section.  If a record of
+   type SOA with the LLQ name does not exist, then the server SHOULD
+   include an SOA record for that name's zone in the Authority section.
+   For example, a query for "_ftp._tcp.example.com" with type SOA, when
+   there is no SOA record with that name, might return an SOA record
+   named "example.com" in the Authority section.  If the named SOA
+   record 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.
+
+   This iterative zone apex discovery algorithm is described in more
+   detail in the DNS Push Notifications specification [RFC8765].
+
+   Upon learning the zone apex (SOA), the client then constructs and
+   sends an SRV query for the name, "_dns-llq._udp.<zone>",
+   e.g., "_dns-llq._udp.example.com".
+
+   An authoritative server for a zone implementing LLQ MUST answer with
+   an SRV record [RFC2782] for this name.  The SRV RDATA is as follows:
+
+    +----------+------------------------------------------------------+
+    | PRIORITY | typically 0                                          |
+    +----------+------------------------------------------------------+
+    | WEIGHT   | typically 0                                          |
+    +----------+------------------------------------------------------+
+    | PORT     | typically 53 or 5352                                 |
+    +----------+------------------------------------------------------+
+    | TARGET   | name of server providing LLQs for the requested zone |
+    +----------+------------------------------------------------------+
+
+                             Table 3: SRV RDATA
+
+   The server SHOULD include the address record(s) for the target host
+   in the Additional section of the response.
+
+   If the server does not include the target host's address record(s) in
+   the Additional section, the client SHOULD query explicitly for the
+   address record(s) with the name of the SRV target.
+
+   The client MUST 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 be sent to an intermediate DNS recursive resolver --
+   they need not be sent directly to the name server.
+
+   If, on issuing the SRV query, the client receives a negative response
+   indicating that the SRV record does not exist, the client SHOULD
+   conclude that the zone does not support LLQ.  The client then SHOULD
+   NOT send an LLQ request for the desired name, instead utilizing the
+   behavior for LLQ-unaware servers described in Section 5, "LLQ Setup".
+
+   Servers should send all messages to the source address and port of
+   the LLQ setup message received from the client.
+
+5.  LLQ Setup
+
+   An LLQ is initiated by a client and is completed via a four-way
+   handshake.  This handshake provides resilience to packet loss,
+   demonstrates client reachability, and reduces denial-of-service
+   attack opportunities (see Section 8, "Security Considerations").
+
+5.1.  Setup Message Retransmission
+
+   LLQ Setup Requests and Responses sent by the client SHOULD be
+   retransmitted if no acknowledgments are received.  The client SHOULD
+   retry up to two more times (for a total of 3 attempts) before
+   considering the server down or unreachable.  The client MUST wait at
+   least 2 seconds before the first retransmission and 4 seconds between
+   the first and second retransmissions.  The client SHOULD 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 periodically attempt to re-initiate
+   an LLQ setup at a rate of not more than once per hour.
+
+   Servers MUST NOT retransmit acknowledgments that do not generate
+   responses from the client.  Retransmission in setup is 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
+   resend its reply (possibly modifying the LLQ-LEASE as described in
+   Section 5.2.4, "ACK + Answers").
+
+   Servers MUST NOT garbage collect LLQs that fail to complete the four-
+   way handshake until the initially granted LLQ-LEASE has elapsed.
+
+5.2.  LLQ Setup Four-Way Handshake
+
+   The four phases of the handshake include:
+
+      1) Setup Request        client to server, identifies LLQ(s)
+                              requested
+
+      2) Setup Challenge      server to client, provides unique
+                              identifiers for successful requested LLQs,
+                              and error(s) for unsuccessful requested
+                              LLQs.
+
+      3) Challenge Response   client to server, echoes identifier(s),
+                              demonstrating client's reachability and
+                              willingness to participate
+
+      4) ACK + Answers        server to client, confirms setup and
+                              provides initial answers
+
+5.2.1.  Setup Request
+
+   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.
+
+   The request MAY contain multiple questions to set up multiple LLQs.
+   A Setup Request consisting of multiple questions MUST 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 LLQ
+   OPTION corresponds to the first question, the second LLQ OPTION
+   corresponds to the second question, etc.).  If requesting multiple
+   LLQs, clients SHOULD request the same LLQ-LEASE for each LLQ.
+   Requests over UDP MUST NOT contain multiple questions if doing so
+   would cause the message to exceed a single IP packet.
+
+   A client MUST NOT 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, and this is also allowable.
+
+   The query MUST NOT be for record type ANY (255), class ANY (255), or
+   class NONE (0).
+
+     +---------------+------------+---------------------------------+
+     | Field Name    | Field Type | Description                     |
+     +===============+============+=================================+
+     | OPTION-CODE   | u_int16_t  | LLQ (1)                         |
+     +---------------+------------+---------------------------------+
+     | OPTION-LENGTH | u_int16_t  | Length of following fields (18) |
+     +---------------+------------+---------------------------------+
+     | LLQ-VERSION   | u_int16_t  | Version of LLQ protocol         |
+     |               |            | implemented by requester (1)    |
+     +---------------+------------+---------------------------------+
+     | LLQ-OPCODE    | u_int16_t  | LLQ-SETUP (1)                   |
+     +---------------+------------+---------------------------------+
+     | LLQ-ERROR     | u_int16_t  | NO-ERROR (0)                    |
+     +---------------+------------+---------------------------------+
+     | LLQ-ID        | u_int64_t  | 0                               |
+     +---------------+------------+---------------------------------+
+     | LLQ-LEASE     | u_int32_t  | Desired life of LLQ request     |
+     +---------------+------------+---------------------------------+
+
+                 Table 4: Setup Request LLQ OPTION Format
+
+   The Setup Request LLQ OPTION MUST be repeated once for each
+   additional query in the Question section.
+
+5.2.2.  Setup Challenge
+
+   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, with the DNS message ID matching that of
+   the Setup Request, and with all questions contained in the Setup
+   Request present in the Question section of the response.
+   Additionally, the challenge contains a single OPT pseudo-RR with an
+   LLQ OPTION for each LLQ request, indicating the success or failure of
+   each request.  The LLQ OPTIONS MUST be in the same order as the
+   questions they correspond to.  Note that in a Setup Request
+   containing multiple questions, some LLQs may succeed while others may
+   fail.
+
+     +---------------+------------+---------------------------------+
+     | Field Name    | Field Type | Description                     |
+     +===============+============+=================================+
+     | OPTION-CODE   | u_int16_t  | LLQ (1)                         |
+     +---------------+------------+---------------------------------+
+     | OPTION-LENGTH | u_int16_t  | Length of following fields (18) |
+     +---------------+------------+---------------------------------+
+     | LLQ-VERSION   | u_int16_t  | Version of LLQ protocol         |
+     |               |            | implemented in server (1)       |
+     +---------------+------------+---------------------------------+
+     | LLQ-OPCODE    | u_int16_t  | LLQ-SETUP (1)                   |
+     +---------------+------------+---------------------------------+
+     | LLQ-ERROR     | u_int16_t  | [As Appropriate]                |
+     +---------------+------------+---------------------------------+
+     | LLQ-ID        | u_int64_t  | [As Appropriate]                |
+     +---------------+------------+---------------------------------+
+     | LLQ-LEASE     | u_int32_t  | [As Appropriate]                |
+     +---------------+------------+---------------------------------+
+
+                Table 5: Setup Challenge LLQ OPTION Format
+
+   The Setup Challenge LLQ OPTION MUST be repeated once for each query
+   in the Questions section of the Setup Challenge.  Further details for
+   LLQ-ERROR, LLQ-ID and LLQ-LEASE are given below.
+
+   LLQ-ERROR:
+
+      NO-ERROR:         The LLQ Setup Request was successful.
+
+      FORMAT-ERR:       The LLQ was improperly formatted.  Note that if
+                        the rest of the DNS message is properly
+                        formatted, the DNS header error code MUST NOT
+                        include a format error code, 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 LLQ and the case
+                        where a client sends a malformed LLQ Setup
+                        Request to a server that does understand LLQ.
+
+      SERV-FULL:        The server cannot grant the LLQ request because
+                        it is overloaded or the request exceeds the
+                        server's rate limit (see Section 8, Security
+                        Considerations).  Upon returning this error, the
+                        server MUST include in the LLQ-LEASE field a
+                        time interval, in seconds, after which the
+                        client may retry the LLQ Setup.
+
+      STATIC:           The data for this name and type is not expected
+                        to change frequently, and the server, therefore,
+                        does not support the requested LLQ.  The client
+                        MUST honor the resource record TTLs returned and
+                        MUST NOT poll sooner than indicated by those
+                        TTLs, nor should it retry the LLQ Setup for this
+                        name and type.
+
+      BAD-VERS:         The protocol version specified in the client's
+                        Setup Request is not supported by the server.
+
+      UNKNOWN-ERR:      The LLQ was not granted for some other reason
+                        not covered by the preceding error code values.
+
+   LLQ-ID:           On success, a random number generated by the server
+                     that is unique on the server for the requested
+                     name/type/class.  The LLQ-ID SHOULD 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.
+
+                     On error, the LLQ-ID is set to 0.
+
+   LLQ-LEASE:        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
+                     discard the LLQ after this LLQ-LEASE expires unless
+                     the LLQ has been renewed by the client (see
+                     Section 7, "LLQ Lease-Life Expiration").  The
+                     server MUST NOT generate events (see Section 6,
+                     "Event Responses") for expired LLQs.
+
+                     On SERV-FULL error, LLQ-LEASE MUST be set to a time
+                     interval, in seconds, after which the client may
+                     retry the LLQ Setup.
+
+                     On other errors, the LLQ-LEASE MUST be set to 0.
+
+5.2.3.  Challenge Response
+
+   Upon issuing a Setup Request, a client listens for a Setup Challenge
+   (Section 5.2.2) retransmitting the Setup Request as necessary
+   (Section 5.1).  After receiving a successful Setup Challenge, the
+   client SHOULD send a Challenge Response to the server.  This
+   Challenge Response is a DNS request with questions as in the Setup
+   Request and Setup Challenge, and a single OPT pseudo-RR in the
+   Additional section, with the LLQ OPTIONS corresponding to the LLQ
+   OPTIONS contained in the Setup Challenge (i.e., echoing, for each LLQ
+   OPTION, the random LLQ-ID and the granted LLQ-LEASE).  If the
+   Challenge Response contains multiple questions, the first question
+   MUST correspond to the first LLQ OPTION, etc.
+
+   If the Setup Request for a particular LLQ fails with a STATIC error,
+   the client MUST NOT poll the server for that LLQ.  The client SHOULD
+   honor the resource record TTLs contained in the response.
+
+   If a Setup Request fails with a SERV-FULL error, the client MAY retry
+   the LLQ Setup Request (Section 5.2.1) after the time indicated in the
+   LLQ-LEASE field.
+
+   If the Setup Request fails with an error other than STATIC or
+   SERV-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 poll the server
+   periodically with standard DNS queries, inferring Add and Remove
+   Events (see Section 6, "Event Responses") by comparing answers to
+   these queries.  The client SHOULD NOT poll more than once every 15
+   minutes for a given query.  The client MUST NOT poll if it receives a
+   STATIC error code in the acknowledgment.
+
+5.2.4.  ACK + Answers
+
+   Upon receiving a correct Challenge Response, a server MUST return an
+   acknowledgment, completing the LLQ setup, and provide all current
+   answers to the question(s).
+
+   To acknowledge a successful Challenge Response, i.e., a Challenge
+   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 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 LLQ OPTIONS formatted as follows:
+
+     +---------------+------------+---------------------------------+
+     | Field Name    | Field Type | Description                     |
+     +===============+============+=================================+
+     | OPTION-CODE   | u_int16_t  | LLQ (1)                         |
+     +---------------+------------+---------------------------------+
+     | OPTION-LENGTH | u_int16_t  | Length of following fields (18) |
+     +---------------+------------+---------------------------------+
+     | LLQ-VERSION   | u_int16_t  | Version of LLQ protocol         |
+     |               |            | implemented in server (1)       |
+     +---------------+------------+---------------------------------+
+     | LLQ-OPCODE    | u_int16_t  | LLQ-SETUP (1)                   |
+     +---------------+------------+---------------------------------+
+     | LLQ-ERROR     | u_int16_t  | NO-ERROR (0)                    |
+     +---------------+------------+---------------------------------+
+     | LLQ-ID        | u_int64_t  | Originally granted ID, echoed   |
+     |               |            | in client's Response            |
+     +---------------+------------+---------------------------------+
+     | LLQ-LEASE     | u_int32_t  | Remaining life of LLQ, in       |
+     |               |            | seconds                         |
+     +---------------+------------+---------------------------------+
+
+           Table 6: Successful ACK + Answers LLQ OPTION Format
+
+   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 resend the
+   Challenge Response), the server MAY decrement the LLQ-LEASE by the
+   time elapsed since the Setup Challenge was initially issued.
+
+   If the setup is completed over UDP and all initially available
+   answers to the question(s), additional records, and the OPT pseudo-RR
+   do not fit in a single IP packet, some or all additional records
+   (excluding the OPT pseudo-RR) MUST be omitted.  If, after omission of
+   all additional records, the answers still do not fit in a single
+   message, answers MUST be removed until the message fits in a single
+   IP packet.  These answers not delivered in the ACK + Answers MUST be
+   delivered without undue delay to the client via Add Events
+   (Section 6, "Event Responses").
+
+5.3.  Resource Record TTLs
+
+   The TTLs of resource records contained in answers to successful LLQs
+   SHOULD be ignored by the client.  The client MAY cache LLQ answers
+   until the client receives a gratuitous announcement (see Section 6,
+   "Event Responses") indicating that the answer to the LLQ has changed.
+   The client SHOULD NOT cache answers after the LLQs LLQ-LEASE expires
+   without being refreshed (see Section 7, "LLQ Lease-Life Expiration").
+   If an LLQ request fails, the client SHOULD NOT cache answers for a
+   period longer than the client's polling interval.
+
+   Note that resource records intended specifically to be transmitted
+   via LLQs (e.g., 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.
+
+   TTLs of resource records included in the Additional section of an LLQ
+   response (which do not directly answer the LLQ) SHOULD be honored by
+   the client.
+
+6.  Event Responses
+
+   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.
+   If so, the changes MUST be communicated to the LLQ requesters in the
+   form of a gratuitous DNS response sent to the client, with the
+   relevant question(s) in the Question section, and the corresponding
+   answers in the Answer section.  The response also includes an OPT
+   pseudo-RR in the Additional section.  This OPT pseudo-RR contains, in
+   its 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.
+
+     +---------------+------------+---------------------------------+
+     | Field Name    | Field Type | Description                     |
+     +===============+============+=================================+
+     | OPTION-CODE   | u_int16_t  | LLQ (1)                         |
+     +---------------+------------+---------------------------------+
+     | OPTION-LENGTH | u_int16_t  | Length of following fields (18) |
+     +---------------+------------+---------------------------------+
+     | LLQ-VERSION   | u_int16_t  | Version of LLQ protocol         |
+     |               |            | implemented in server (1)       |
+     +---------------+------------+---------------------------------+
+     | LLQ-OPCODE    | u_int16_t  | LLQ-EVENT (3)                   |
+     +---------------+------------+---------------------------------+
+     | LLQ-ERROR     | u_int16_t  | NO-ERROR (0)                    |
+     +---------------+------------+---------------------------------+
+     | LLQ-ID        | u_int64_t  | [As Appropriate]                |
+     +---------------+------------+---------------------------------+
+     | LLQ-LEASE     | u_int32_t  | 0                               |
+     +---------------+------------+---------------------------------+
+
+                Table 7: Event Response LLQ OPTION Format
+
+   Gratuitous responses for a single LLQ MAY be batched such that
+   multiple changes are communicated in a single message.  Responses
+   MUST NOT be batched if this would cause a message that would
+   otherwise fit in a single IP packet to be truncated.  While responses
+   MAY be deferred to provide opportunities for batching, responses
+   SHOULD NOT be delayed, for purposes of batching, for more than 30
+   seconds, as this would cause an unacceptable latency for the client.
+
+   After sending a gratuitous response, the server MUST listen for an
+   acknowledgment from the client.  If the client does not respond, the
+   server MUST resend the response.  The server MUST resend two times
+   (for a total of 3 transmissions), after which the server MUST
+   consider the client to be unreachable and delete its LLQ.  The server
+   MUST listen for 2 seconds before resending the response, 4 more
+   seconds before resending again, and must wait an additional 8 seconds
+   after the 3rd transmission before terminating the LLQ.
+
+   The DNS message header of the response SHOULD include an
+   unpredictable random number in the DNS message ID field, which is to
+   be echoed in the client's acknowledgment.
+
+6.1.  Add Events
+
+   Add Events occur when a new resource record appears, usually as the
+   result of a dynamic update [RFC2136], 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 be
+   included in the Additional section as per truncation restrictions
+   described above.
+
+6.2.  Remove Events
+
+   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).
+   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.
+
+6.3.  Gratuitous Response Acknowledgments
+
+   Upon receiving a gratuitous response ("event"), the client MUST send
+   an acknowledgment to the server.  This acknowledgment is a DNS
+   response echoing the OPT pseudo-RR contained in the event, with the
+   message ID of the gratuitous response echoed in the message header.
+   The acknowledgment MUST be sent to the source IP address and port
+   from which the event originated.
+
+7.  LLQ Lease-Life Expiration
+
+7.1.  Refresh Request
+
+   If the client desires to maintain the LLQ beyond the duration
+   specified in the LLQ-LEASE field of the ACK + Answers
+   (Section 5.2.4), the client MUST send a Refresh Request.  A Refresh
+   Request is identical to an LLQ Challenge Response (Section 5.2.3) but
+   with the LLQ-OPCODE set to LLQ-REFRESH.  Unlike a Challenge Response,
+   a Refresh Request returns no answers.
+
+   The client SHOULD refresh an LLQ when 80% of its LLQ-LEASE has
+   elapsed.
+
+   As a means of reducing network traffic, when constructing refresh
+   messages the client SHOULD include all LLQs established with a given
+   server, even those not yet close to expiration.  However, at least
+   one LLQ MUST have elapsed at least 80% of its original LLQ-LEASE.
+   The client MUST NOT 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 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 and a single OPT pseudo-RR with
+   multiple LLQ OPTIONS, one per question, with the LLQ OPTIONS in the
+   same order as the questions they correspond to.
+
+   The client SHOULD specify the original LLQ-LEASE granted in the LLQ
+   response as the desired LLQ-LEASE in the Refresh Request.  If
+   refreshing multiple LLQs simultaneously, the client SHOULD request
+   the same LLQ-LEASE for all LLQs being refreshed (with the exception
+   of termination requests; see below).
+
+   To terminate an LLQ prior to its scheduled expiration (for instance,
+   when the client terminates a DNS-based Service Discovery browse
+   operation or when a client is about to go to sleep or shut down), the
+   client specifies an LLQ-LEASE value of 0.
+
+   The client MUST listen for an acknowledgment from the server.  The
+   client MAY retry up to two more times (for a total of 3 attempts)
+   before considering the server down or unreachable.  The client MUST
+   NOT retry a first time before 90% of the LLQ-LEASE has expired and
+   MUST NOT retry again before 95% of the LLQ-LEASE has expired.  If the
+   server is determined to be down, the client MAY periodically 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 hour.
+
+7.2.  LLQ Refresh Acknowledgment
+
+   Upon receiving an LLQ Refresh message, a server MUST send an
+   acknowledgment of the Refresh.  This acknowledgment is formatted like
+   the "ACK + Answers" message described in Section 5.2.4, but with the
+   following variations:
+
+   *  It contains no answers.
+
+   *  The LLQ-OPCODE is set to LLQ-REFRESH.
+
+   *  NO-SUCH-LLQ MUST be returned as an error code if the client
+      attempts to refresh an expired or non-existent LLQ (as determined
+      by the LLQ-ID in the request).
+
+   *  The LLQ-ID in the acknowledgment is set to the LLQ-ID in the
+      request.
+
+8.  Security Considerations
+
+   In datagram-based protocols (i.e., protocols running over UDP, or
+   directly over IP, or similar), servers 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.
+
+   Note: This section contains no new protocol elements -- it serves
+   only to explain the rationale behind protocol elements described
+   above as they relate to security.
+
+8.1.  Server DoS
+
+   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-FULL in Setup Challenges, the server may limit the maximum
+   number of LLQs it maintains.  Additionally, the server may return
+   SERV-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 attacks -- thus, it is not built into the protocol explicitly but
+   is instead implemented at the discretion of an administrator via the
+   SERV-FULL error and the LLQ-LEASE field to indicate a retry time to
+   the client.
+
+8.2.  Client Packet Storms
+
+   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 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.
+
+   Additionally, rate limiting by LLQ client address, as described in
+   Section 8.1, serves to limit the number of packets that can be
+   delivered to an unsuspecting client.
+
+8.3.  Spoofing
+
+   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).
+
+9.  IANA Considerations
+
+   The EDNS(0) OPTION CODE 1 has already been assigned for this DNS
+   extension.  IANA has updated the record in the "DNS EDNS0 Option
+   Codes (OPT)" registry from "On-hold" to "Optional" and has set the
+   reference to this document.
+
+   TCP and UDP ports 5352 have already been assigned for LLQ.  IANA has
+   added a reference to this document.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              DOI 10.17487/RFC2782, February 2000,
+              <https://www.rfc-editor.org/info/rfc2782>.
+
+   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
+              for DNS (EDNS(0))", STD 75, RFC 6891,
+              DOI 10.17487/RFC6891, April 2013,
+              <https://www.rfc-editor.org/info/rfc6891>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8765]  Pusateri, T. and S. Cheshire, "DNS Push Notifications",
+              RFC 8765, DOI 10.17487/RFC8765, June 2020,
+              <https://www.rfc-editor.org/info/rfc8765>.
+
+10.2.  Informative References
+
+   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, DOI 10.17487/RFC2136, April 1997,
+              <https://www.rfc-editor.org/info/rfc2136>.
+
+   [RFC4787]  Audet, F., Ed. and C. Jennings, "Network Address
+              Translation (NAT) Behavioral Requirements for Unicast
+              UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
+              2007, <https://www.rfc-editor.org/info/rfc4787>.
+
+   [RFC4953]  Touch, J., "Defending TCP Against Spoofing Attacks",
+              RFC 4953, DOI 10.17487/RFC4953, July 2007,
+              <https://www.rfc-editor.org/info/rfc4953>.
+
+   [RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
+              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
+              RFC 5382, DOI 10.17487/RFC5382, October 2008,
+              <https://www.rfc-editor.org/info/rfc5382>.
+
+   [RFC6281]  Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
+              "Understanding Apple's Back to My Mac (BTMM) Service",
+              RFC 6281, DOI 10.17487/RFC6281, June 2011,
+              <https://www.rfc-editor.org/info/rfc6281>.
+
+   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
+              DOI 10.17487/RFC6762, February 2013,
+              <https://www.rfc-editor.org/info/rfc6762>.
+
+   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
+              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
+              <https://www.rfc-editor.org/info/rfc6763>.
+
+   [RFC6886]  Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol
+              (NAT-PMP)", RFC 6886, DOI 10.17487/RFC6886, April 2013,
+              <https://www.rfc-editor.org/info/rfc6886>.
+
+   [RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
+              P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
+              DOI 10.17487/RFC6887, April 2013,
+              <https://www.rfc-editor.org/info/rfc6887>.
+
+   [RFC7857]  Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
+              S., and K. Naito, "Updates to Network Address Translation
+              (NAT) Behavioral Requirements", BCP 127, RFC 7857,
+              DOI 10.17487/RFC7857, April 2016,
+              <https://www.rfc-editor.org/info/rfc7857>.
+
+   [RFC8490]  Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
+              Lemon, T., and T. Pusateri, "DNS Stateful Operations",
+              RFC 8490, DOI 10.17487/RFC8490, March 2019,
+              <https://www.rfc-editor.org/info/rfc8490>.
+
+   [SYN]      Eddy, W., "Defenses Against TCP SYN Flooding Attacks",
+              Volume 9, Number 4, The Internet Protocol Journal, Cisco
+              Systems, December 2006,
+              <https://www.cisco.com/web/about/ac123/ac147/
+              archived_issues/ipj_9-4/ipj_9-4.pdf>.
+
+Appendix A.  Problems with the LLQ Protocol
+
+   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.
+
+   LLQ's IETF Standards Track successor, "DNS Push Notifications"
+   [RFC8765], does not suffer from these problems, so all existing LLQ
+   implementations are RECOMMENDED to migrate to using DNS Push
+   Notifications, and all new implementations are RECOMMENDED to
+   implement DNS Push Notifications instead of LLQ.
+
+   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).
+
+   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.
+
+   Section 5.1 of this LLQ specification states, "Servers MUST NOT
+   garbage collect LLQs 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
+   [RFC8765], is built using DNS Stateful Operations [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 [SYN] [RFC4953].
+
+   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 [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.
+
+   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 [RFC8765]
+   corrects this error by having only one single consistent way to
+   deliver results.
+
+   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 [RFC4787] [RFC5382] [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) [RFC6886] and/or Port Control
+   Protocol (PCP) [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.
+
+Acknowledgments
+
+   The concepts described in this document were originally explored,
+   developed, and implemented with help from Chris Sharp and Roger
+   Pantos.
+
+   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.
+
+   Thanks to Independent Stream Editor Adrian Farrel for his support and
+   assistance in the publication of this RFC.
+
+Authors' Addresses
+
+   Stuart Cheshire
+   Apple Inc.
+   One Apple Park Way
+   Cupertino, CA 95014
+   United States of America
+
+   Phone: +1 (408) 996-1010
+   Email: cheshire@apple.com
+
+
+   Marc Krochmal
+   Apple Inc.
+   One Apple Park Way
+   Cupertino, CA 95014
+   United States of America
+
+   Phone: +1 (408) 996-1010
+   Email: marc@apple.com