idnits 2.17.00 (12 Aug 2021) /tmp/idnits54762/draft-ietf-dnssd-mdns-relay-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 784 has weird spacing: '... name a mac...' == Line 787 has weird spacing: '...hr-name an op...' == Line 791 has weird spacing: '...ificate a cer...' == Line 797 has weird spacing: '...ate-key the p...' == Line 800 has weird spacing: '...dresses a lis...' == (8 more instances...) -- The document date (February 22, 2021) is 446 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-sctl-advertising-proxy-00 == Outdated reference: draft-ietf-mboned-ieee802-mcast-problems has been published as RFC 9119 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft S. Cheshire 4 Intended status: Standards Track Apple Inc. 5 Expires: August 26, 2021 February 22, 2021 7 Multicast DNS Discovery Relay 8 draft-ietf-dnssd-mdns-relay-04 10 Abstract 12 This document complements the specification of the Discovery Proxy 13 for Multicast DNS-Based Service Discovery. It describes a 14 lightweight relay mechanism, a Discovery Relay, which, when present 15 on a link, allows remote clients, not attached to that link, to 16 perform mDNS discovery operations on that link. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 26, 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. Connections between Clients and Relays (overview) . . . . 6 56 3.2. mDNS Messages On Multicast Links . . . . . . . . . . . . 7 57 4. Connections between Clients and Relays (details) . . . . . . 8 58 5. Traffic from Relays to Clients . . . . . . . . . . . . . . . 10 59 6. Traffic from Clients to Relays . . . . . . . . . . . . . . . 12 60 7. Discovery Proxy Behavior . . . . . . . . . . . . . . . . . . 13 61 8. DSO TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 8.1. mDNS Link Data Request . . . . . . . . . . . . . . . . . 14 63 8.2. mDNS Link Data Discontinue . . . . . . . . . . . . . . . 14 64 8.3. Link Identifier . . . . . . . . . . . . . . . . . . . . . 15 65 8.4. Encapsulated mDNS Message . . . . . . . . . . . . . . . . 15 66 8.5. IP Source . . . . . . . . . . . . . . . . . . . . . . . . 15 67 8.6. Link State Request . . . . . . . . . . . . . . . . . . . 16 68 8.7. Link State Discontinue . . . . . . . . . . . . . . . . . 16 69 8.8. Link Available . . . . . . . . . . . . . . . . . . . . . 16 70 8.9. Link Unavailable . . . . . . . . . . . . . . . . . . . . 16 71 8.10. Link Prefix . . . . . . . . . . . . . . . . . . . . . . . 17 72 9. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 18 73 9.1. Provisioned Objects . . . . . . . . . . . . . . . . . . . 19 74 9.1.1. Multicast Link . . . . . . . . . . . . . . . . . . . 20 75 9.1.2. Discovery Proxy . . . . . . . . . . . . . . . . . . . 21 76 9.1.3. Discovery Relay . . . . . . . . . . . . . . . . . . . 22 77 9.2. Configuration Files . . . . . . . . . . . . . . . . . . . 23 78 9.3. Discovery Proxy Private Configuration . . . . . . . . . . 25 79 9.4. Discovery Relay Private Configuration . . . . . . . . . . 25 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 82 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 84 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 85 13.2. Informative References . . . . . . . . . . . . . . . . . 29 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 88 1. Introduction 90 This document defines a Discovery Relay. A Discovery Relay is a 91 companion technology that works in conjunction with Discovery 92 Proxies, and other clients. 94 The Discovery Proxy for Multicast DNS-Based Service Discovery 95 [RFC8766] is a mechanism for discovering services on a subnetted 96 network through the use of Discovery Proxies. Discovery Proxies 97 issue Multicast DNS (mDNS) requests [RFC6762] on various multicast 98 links in the network on behalf of a remote host performing DNS-Based 99 Service Discovery [RFC6763]. 101 In the original Discovery Proxy specification, it was imagined that 102 for every multicast link on which services will be discovered, a host 103 will be present running a full Discovery Proxy. This document 104 introduces a lightweight Discovery Relay that can be used in 105 conjunction with a central Discovery Proxy to provide discovery 106 services on a multicast link without requiring a full Discovery Proxy 107 on every multicast link. 109 The primary purpose of a Discovery Relay is providing remote virtual 110 interface functionality to Discovery Proxies, and this document is 111 written with that usage in mind. However, in principle, a Discovery 112 Relay could be used by any properly authorized client. In the 113 context of this specification, a Discovery Proxy is a client to the 114 Discovery Relay. This document uses the terms "Discovery Proxy" and 115 "Client" somewhat interchangably; the term "Client" is used when we 116 are talking about the communication between the Client and the Relay, 117 and the term "Discovery Proxy" when we are referring specifically to 118 a Discovery Relay Client that also happens to be a Discovery Proxy. 119 One example of another kind of device that can be a client of a 120 Discovery Relay is an Advertising Proxy [AdProx]. 122 The Discovery Relay operates by listening for TCP connections from 123 Clients. When a Client connects, the connection is authenticated and 124 secured using TLS. The Client can then specify one or more multicast 125 links from which it wishes to receive mDNS traffic. The Client can 126 also send messages to be transmitted on its behalf on one or more of 127 those multicast links. DNS Stateful Operations (DSO) [RFC8490] is 128 used as a framework for conveying interface and IP header information 129 associated with each message. DSO formats its messages using type- 130 length-value (TLV) data structures. This document defines additional 131 DSO TLV types, used to implement the Discovery Relay functionality. 133 The Discovery Relay functions essentially as a set of one or more 134 remote virtual interfaces for the Client, one on each multicast link 135 to which the Discovery Relay is connected. In a complex network, it 136 is possible that more than one Discovery Relay will be connected to 137 the same multicast link; in this case, the Client ideally should only 138 be using one such Relay Proxy per multicast link, since using more 139 than one will generate duplicate traffic. 141 How such duplication is detected and avoided is out of scope for this 142 document; in principle it could be detected using HNCP [RFC7788] or 143 configured using some sort of orchestration software in conjunction 144 with NETCONF [RFC6241] or CPE WAN Management Protocol [TR-069]. 146 Use of a Discovery Relay can be considered similar to using Virtual 147 LAN (VLAN) trunk ports to give a Discovery Proxy device a virtual 148 presence on multiple links or broadcast domains. The difference is 149 that while a VLAN trunk port operates at the link layer and delivers 150 all link-layer traffic to the Discovery Proxy device, a Discovery 151 Relay operates further up the network stack and selectively delivers 152 only relevant Multicast DNS traffic. Also, VLAN trunk ports are 153 generally only available within a single administrative domain and 154 require link-layer configuration and connectivity, whereas the 155 Discovery Relay protocol, which runs over TCP, can be used between 156 any two devices with IP connectivity to each other. 158 2. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in 163 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. These words may also appear in this 165 document in lower case as plain English words, absent their normative 166 meanings. 168 The following definitions may be of use: 170 Client A network service that uses a Discovery Relay to send and 171 receive mDNS multicast traffic on a remote link, to enable it to 172 communicate with mDNS Agents on that remote link. 174 mDNS Agent A host which sends and/or responds to mDNS queries 175 directly on its local link(s). Examples include network cameras, 176 networked printers, networked home electronics, etc. 178 Discovery Proxy A network service which receives well-formed 179 questions using the DNS protocol, performs multicast DNS queries 180 to find answers to those questions, and responds with those 181 answers using the DNS protocol. A Discovery Proxy that can 182 communicate with remote mDNS Agents, using the services of a 183 Discovery Relay, is a Client of the Discovery Relay. 185 Discovery Relay A network service which relays mDNS messages 186 received on a local link to a Client, and on behalf of that Client 187 can transmit mDNS messages on a local link. 189 multicast link A maximal set of network connection points, such that 190 any host connected to any connection point in the set may send a 191 packet with a link-local multicast destination address 192 (specifically the mDNS link-local multicast destination address 193 [RFC6762]) that will be received by all hosts connected to all 194 other connection points in the set. Note that it is becoming 195 increasingly common for a multicast link to be smaller than its 196 corresponding unicast link. For example it is becoming common to 197 have multiple Wi-Fi access points on a shared Ethernet backbone, 198 where the multiple Wi-Fi access points and their shared Ethernet 199 backbone form a single unicast link (a single IPv4 subnet, or 200 single IPv6 prefix) but not a single multicast link. Unicast 201 packets sent directly between two hosts on that IPv4 subnet or 202 IPv6 prefix, without passing through an intervening IP-layer 203 router, are correctly delivered, but multicast packets are not 204 forwarded between the various Wi-Fi access points. Given the 205 slowness of Wi-Fi multicast 206 [I-D.ietf-mboned-ieee802-mcast-problems], having a packet that may 207 be of interest to only one or two end systems transmitted to 208 hundreds of devices, across multiple Wi-Fi access points, is 209 especially wasteful. Hence the common configuration decision to 210 not forward multicast packets between Wi-Fi access points is very 211 reasonable. This further motivates the need for technologies like 212 Discovery Proxy and Discovery Relay to facilitate discovery on 213 these networks. 215 allow-list A list of one or more IP addresses from which a Discovery 216 Relay may accept connections. 218 silently discard When a message that is not supported or not 219 permitted is received, and the required response to that message 220 is to "silently discard" it, that means that no response is sent 221 by the service that is discarding the message to the service that 222 sent it. The service receiving the message may log the event, and 223 may also count such events: "silently" does not preclude such 224 behavior. 226 Take care when reading this document not to confuse the terms 227 "Discovery Proxy" and "Discovery Relay". A Discovery Proxy [RFC8766] 228 provides Multicast DNS discovery service to remote clients. A 229 Discovery Relay is a simple software entity that provides virtual 230 link connectivity to one or more Discovery Proxies or other Discovery 231 Relay clients. 233 3. Protocol Overview 235 This document describes a way for a Client to communicate with mDNS 236 agents on remote multicast links to which the client is not directly 237 connected, using a Discovery Relay. As such, there are two parts to 238 the protocol: connections between Clients and Discovery Relays, and 239 communications between Discovery Relays and mDNS agents. 241 3.1. Connections between Clients and Relays (overview) 243 Discovery Relays listen for incoming connection requests. 244 Connections between Clients and Discovery Relays are established by 245 Clients. Connections are authenticated and encrypted using TLS, with 246 both client and server certificates. Connections are long-lived: a 247 Client is expected to send many queries over a single connection, and 248 Discovery Relays will forward all mDNS traffic from subscribed 249 interfaces over the connection. 251 The stream encapsulated in TLS will carry DNS frames as in the DNS 252 TCP protocol [RFC1035] Section 4.2.2. However, all messages will be 253 DSO messages [RFC8490]. There will be four types of such messages 254 between Discovery Relays and Clients: 256 o Control messages from Client to Relay 258 o Link status messages from Relay to Client 260 o Encapsulated mDNS messages from Client to Relay 262 o Encapsulated mDNS messages from Relay to Client 264 Clients can send four different control messages to Relays: Link 265 State Request, Link State Discontinue, Link Data Request and Link 266 Data Discontinue. The first two are used by the Client to request 267 that the Relay report on the set of links that can be requested, and 268 to request that it discontinue such reporting. The second two are 269 used by the Client to indicate to the Discovery Relay that mDNS 270 messages from one or more specified multicast links are to be relayed 271 to the Client, and to subsequently stop such relaying. 273 Link Status messages from a Discovery Relay to the Client inform the 274 Client that a link has become available, or that a formerly-available 275 link is no longer available. 277 Encapsulated mDNS messages from a Discovery Relay to a Client are 278 sent whenever an mDNS message is received on a multicast link to 279 which the Discovery Relay has subscribed. 281 Encapsulated mDNS messages from a Client to a Discovery Relay cause 282 the Discovery Relay to transmit the mDNS message on the specified 283 multicast link to which the Discovery Relay host is directly 284 attached. 286 During periods with no traffic flowing, Clients are responsible for 287 generating any necessary keepalive traffic, as stated in the DSO 288 specification [RFC8490]. 290 3.2. mDNS Messages On Multicast Links 292 Discovery Relays listen for mDNS traffic on all configured multicast 293 links that have at least one active subscription from a Client. When 294 an mDNS message is received on a multicast link, it is forwarded on 295 every open Client connection that is subscribed to mDNS traffic on 296 that multicast link. In the event of congestion, where a particular 297 Client connection has no buffer space for an mDNS message that would 298 otherwise be forwarded to it, the mDNS message is not forwarded to 299 it. Normal mDNS retry behavior is used to recover from this sort of 300 packet loss. Discovery Relays are not expected to buffer more than a 301 few mDNS packets. Excess mDNS packets are silently discarded. In 302 practice this is not expected to be a issue. Particularly on 303 networks like Wi-Fi, multicast packets are transmitted at rates ten 304 or even a hundred times slower than unicast packets. This means that 305 even at peak multicast packets rates, it is likely that a unicast TCP 306 connection will able to carry those packets with ease. 308 Clients send encapsulated mDNS messages they wish to have sent on 309 their behalf on remote multicast link(s) on which the Client has an 310 active subscription. A Discovery Relay will not transmit mDNS 311 packets on any multicast link on which the Client does not have an 312 active subscription, since it makes no sense for a Client to ask to 313 have a query sent on its behalf if it's not able to receive the 314 responses to that query. 316 4. Connections between Clients and Relays (details) 318 When a Discovery Relay starts, it opens a passive TCP listener to 319 receive incoming connection requests from Clients. This listener may 320 be bound to one or more source IP addresses, or to the wildcard 321 address, depending on the implementation. When a connection is 322 received, the relay must first validate that it is a connection to an 323 IP address to which connections are allowed. For example, it may be 324 that only connections to ULAs are allowed, or to the IP addresses 325 configured on certain interfaces. If the listener is bound to a 326 specific IP address, this check is unnecessary. 328 If the relay is using an IP address allow-list, the next step is for 329 the relay to verify that that the source IP address of the connection 330 is on its allow-list. If the connection is not permitted either 331 because of the source address or the destination address, the 332 Discovery Relay closes the connection. If possible, before closing 333 the connection, the Discovery Relay first sends a TLS user_canceled 334 alert ([RFC8446] Section 6.1). Discovery Relays SHOULD refuse to 335 accept TCP connections to invalid destination addresses, rather than 336 accepting and then closing the connection, if this is possible. 338 Otherwise, the Discovery Relay will attempt to complete a TLS 339 handshake with the Client. Clients are required to send the 340 post_handshake_auth extension ([RFC8446] Section 4.2.5). If a 341 Discovery Relay receives a ClientHello message with no 342 post_handshake_auth extension, the Discovery Relay rejects the 343 connection with a certificate_required alert ([RFC8446] Section 6.2). 345 Once the TLS handshake is complete, the Discovery Relay MUST request 346 post-handshake authentication ([RFC8446] Section 4.6.2). If the 347 Client refuses to send a certificate, or the key presented does not 348 match the key associated with the IP address from which the 349 connection originated, or the CertificateVerify does not validate, 350 the connection is dropped with the TLS access_denied alert ([RFC8446] 351 Section 6.2). 353 Clients MUST validate server certificates. If the client is 354 configured with a server IP address and certificate, it can validate 355 the server by comparing the certificate offered by the server to the 356 certificate that was provided: they should be the same. If the 357 certificate includes a Distinguished Name that is a fully-qualified 358 domain name, the client SHOULD present that domain name to the server 359 in an SNI request. 361 Rather than being configured with an IP address and a certificate, 362 the client may be configured with the server's FQDN. In this case, 363 the client uses the server's FQDN as a Authentication Domain Name 365 [RFC8310] Section 7.1, and uses the authentication method described 366 in [RFC8310] section 8.1, if the certificate is signed by a root 367 authority the client trusts, or the method described in section 8.2 368 of the same document if not. If neither method is available, then a 369 locally-configured copy of the server certificate can be used, as in 370 the previous paragraph. 372 Once the connection is established and authenticated, it is treated 373 as a DNS TCP connection [RFC7766]. 375 Aliveness of connections between Clients and Relays is maintained as 376 described in Section 4 of the DSO specification [RFC8490]. Clients 377 must also honor the 'Retry Delay' TLV (section 5 of [RFC8490]) if 378 sent by the Discovery Relay. 380 Clients SHOULD avoid establishing more than one connection to a 381 specific Discovery Relay. However, there may be situations where 382 multiple connections to the same Discovery Relay are unavoidable, so 383 Discovery Relays MUST be willing to accept multiple connections from 384 the same Client. 386 In order to know what links to request, the Client can be configured 387 with a list of links supported by the Relay. However, in some 388 networking contexts, dynamic changes in the availability of links are 389 likely; therefore Clients may also use the Report Link Changes TLV to 390 request that the Relay report on the availability of its links. In 391 some contexts, for example when debugging, a Client may operate with 392 no information about the set of links supported by a relay, simply 393 relying on the relay to provide one. 395 5. Traffic from Relays to Clients 397 The mere act of connecting to a Discovery Relay does not result in 398 any mDNS traffic being forwarded. In order to request that mDNS 399 traffic from a particular multicast link be forwarded on a particular 400 connection, the Client must send one or more DSO messages, each 401 containing a single mDNS Link Data Request TLV (Section 8.1) 402 indicating the multicast link from which traffic is requested. 404 When an mDNS Link Data Request message is received, the Discovery 405 Relay validates that it recognizes the link identifier, and that 406 forwarding is enabled for that link. If both checks are successful, 407 it MUST send a response with RCODE=0 (NOERROR). If the link 408 identifier is not recognized, it sends a response with RCODE=3 409 (NXDOMAIN/Name Error). If forwarding from that link to the Client is 410 not enabled, it sends a response with RCODE=5 (REFUSED). If the 411 relay cannot satisfy the request for some other reason, for example 412 resource exhaustion, it sends a response with RCODE=2 (SERVFAIL). 414 If the requested link is valid, the Relay begins forwarding all mDNS 415 messages from that link to the Client. Delivery is not guaranteed: 416 if there is no buffer space, packets will be dropped. It is expected 417 that regular mDNS retry processing will take care of retransmission 418 of lost packets. The amount of buffer space is implementation 419 dependent, but generally should not be more than the bandwidth delay 420 product of the TCP connection [RFC7323]. The Discovery Relay should 421 use the TCP_NOTSENT_LOWAT mechanism [NOTSENT][PRIO] or equivalent, to 422 avoid building up a backlog of data in excess of the amount necessary 423 to have in flight to fill the bandwidth delay product of the TCP 424 connection. 426 Encapsulated mDNS messages from Relays to Clients are framed within 427 DSO messages. Each DSO message can contain multiple TLVs, but only a 428 single encapsulated mDNS message is conveyed per DSO message. Each 429 forwarded mDNS message is sent in an Encapsulated mDNS Message TLV 430 (Section 8.4). The source IP address and port of the message MUST be 431 encoded in an IP Source TLV (Section 8.5). The multicast link on 432 which the message was received MUST be encoded in a Link Identifier 433 TLV (Section 8.3). As described in the DSO specification [RFC8490], 434 a Client MUST silently ignore unrecognized Additional TLVs in mDNS 435 messages, and MUST NOT discard mDNS messages that include 436 unrecognized Additional TLVs. 438 A Client may discontinue listening for mDNS messages on a particular 439 multicast link by sending a DSO message containing an mDNS Link Data 440 Discontinue TLV (Section 8.2). The Discovery Relay MUST discontinue 441 forwarding mDNS messages when the Link Data Discontinue request is 442 received. However, messages from that link that had previously been 443 queued may arrive after the Client has discontinued its listening. 444 The Client should silently discard such messages. The Discovery 445 Relay does not respond to the Link Data Discontinue message other 446 than to discontinue forwarding mDNS messages from the specified 447 links. 449 6. Traffic from Clients to Relays 451 Like mDNS traffic from relays, each mDNS message sent by a Client to 452 a Discovery Relay is communicated in an Encapsulated mDNS Message TLV 453 (Section 8.4) within a DSO message. Each message MUST contain 454 exactly one Link Identifier TLV (Section 8.3). The Discovery Relay 455 will transmit the mDNS message to the mDNS port and multicast address 456 on the link specified in the message using the specified IP address 457 family. 459 Although the communication between Clients and Relays uses the DNS 460 stream protocol and DNS Stateless Operations, there is no case in 461 which a Client would legitimately send a DNS query (or anything else 462 other than a DSO message) to a Relay. Therefore, if a Relay receives 463 any message other than a DSO message, it MUST immediately abort that 464 DSO session with a TCP reset (RST). 466 When defining this behavior, the working group considered making it 467 possible to specify more than one link identifier in an mDNSMessage 468 TLV. A superficial evaluation of this suggested that this might be a 469 useful optimization, since when a query is issued, it will often be 470 issued to all links. However, on many link types, like Wi-Fi, 471 multicast traffic is expensive 472 [I-D.ietf-mboned-ieee802-mcast-problems] and should be generated 473 frugally, so providing convenient ways to generate additional 474 multicast traffic was determined to be an unwise optimization. In 475 addition, because of the way mDNS handles retries, it will almost 476 never be the case that the exact same message will be sent on more 477 than one link. Therefore, the complexity that this optimization adds 478 is not justified by the potential benefit, and this idea has been 479 abandoned. 481 7. Discovery Proxy Behavior 483 Discovery Proxies treat multicast links for which Discovery Relay 484 service is being used as if they were virtual interfaces; in other 485 words, a Discovery Proxy serving multiple remote multicast links 486 using multiple remote Discovery Relays behaves the same as a 487 Discovery Proxy serving multiple local multicast links using multiple 488 local physical network interfaces. In this section we refer to 489 multicast links served directly by the Discovery Proxy as locally- 490 connected links, and multicast links served through the Discovery 491 Relay as relay-connected links. A relay-connected link can be 492 thought of as similar to a link that a Discovery Proxy connects to 493 using a USB Ethernet interface, just with a very long USB cable (that 494 runs over TCP). 496 When a Discovery Proxy receives a DNS query from a DNS client via 497 unicast, it will generate corresponding mDNS query messages on the 498 relevant multicast link(s) for which it is acting as a proxy. For 499 locally-connected link(s), those query messages will be sent 500 directly. For relay-connected link(s), the query messages will be 501 sent through the Discovery Relay that is being used to serve that 502 multicast link. 504 Responses from devices on locally-connected links are processed 505 normally. Responses from devices on relay-connected links are 506 received by the Discovery Relay, encapsulated, and forwarded to the 507 Client; the Client then processes these messages using the link- 508 identifying information included in the encapsulation. 510 In principle it could be the case that some device is capable of 511 performing service discovery using Multicast DNS, but not using 512 traditional unicast DNS. Responding to mDNS queries received from 513 the Discovery Relay could address this use case. However, continued 514 reliance on multicast is counter to the goals of the current work in 515 service discovery, and to benefit from wide-area service discovery 516 such client devices should be updated to support service discovery 517 using unicast queries. 519 8. DSO TLVs 521 This document defines a modest number of new DSO TLVs. 523 8.1. mDNS Link Data Request 525 The mDNS Link Data Request TLV conveys a link identifier from which a 526 Client is requesting that a Discovery Relay forward mDNS traffic. 527 The link identifier comes from the provisioning configuration (see 528 Section 9). The DSO-TYPE for this TLV is TBD-R. DSO-LENGTH is 529 always 5. DSO-DATA is the 8-bit address family followed by the link 530 identifier, a 32-bit unsigned integer in network (big endian) byte 531 order, as described in Section 9. An address family value of 1 532 indicates IPv4 and 2 indicates IPv6, as recorded in the IANA Registry 533 of Address Family Numbers [AdFam]. 535 The mDNS Link Data Request TLV can only be used as a primary TLV, and 536 requires an acknowledgement. 538 At most one mDNS Link Data Request TLV may appear in a DSO message. 539 To request multiple link subscriptions, multiple separate DSO 540 messages are sent, each containing a single mDNS Link Data Request 541 TLV. 543 A Client MUST NOT request a link if it already has an active 544 subscription to that link on the same DSO connection. If a Discovery 545 Relay receives a duplicate link subscription request, it MUST 546 immediately abort that DSO session with a TCP reset (RST). 548 8.2. mDNS Link Data Discontinue 550 The mDNS Link Data Discontinue TLV is used by Clients to unsubscribe 551 to mDNS messages on the specified multicast link. DSO-TYPE is TBD-D. 552 DSO-LENGTH is always 5. DSO-DATA is the 8-bit address family 553 followed by the 32-bit link identifier, a 32-bit unsigned integer in 554 network (big endian) byte order, as described in Section 9. 556 The mDNS Link Data Discontinue TLV can only be used as a DSO 557 unidirectional message TLV, and is not acknowledged. 559 At most one mDNS Link Data Discontinue TLV may appear in a DSO 560 message. To unsubscribe from multiple links, multiple separate DSO 561 messages are sent, each containing a single mDNS Link Data 562 Discontinue TLV. 564 8.3. Link Identifier 566 This option is used both in DSO messages from Discovery Relays to 567 Clients that contain received mDNS messages, and from Clients to 568 Discovery Relays that contain mDNS messages to be transmitted on the 569 multicast link. In the former case, it indicates the multicast link 570 on which the message was received; in the latter case, it indicates 571 the multicast link on which the message should be transmitted. DSO- 572 TYPE is TBD-L. DSO-LENGTH is always 5. DSO-DATA is the 8-bit 573 address family followed by the link identifier, a 32-bit unsigned 574 integer in network (big endian) byte order, as described in 575 Section 9. 577 The Link Identifier TLV can only be used as an additional TLV. The 578 Link Identifier TLV can only appear at most once in a Discovery Relay 579 DSO message. 581 8.4. Encapsulated mDNS Message 583 The Encapsulated mDNS Message TLV is used to communicate an mDNS 584 message that a Relay is forwarding from a multicast link to a Client, 585 or that a Client is sending to a Relay for transmission on a 586 multicast link. Only the application-layer payload of the mDNS 587 message is carried in the DSO "Encapsulated mDNS Message" TLV, i.e., 588 just the DNS message itself, beginning with the DNS Message ID, not 589 the IP or UDP headers. The DSO-TYPE for this TLV is TBD-M. DSO- 590 LENGTH is the length of the encapsulated mDNS message. DSO-DATA is 591 the content of the encapsulated mDNS message. 593 The Encapsulated mDNS Message TLV can only be used as a DSO 594 unidirectional message TLV, and is not acknowledged. 596 8.5. IP Source 598 The IP Source TLV is used to report the IP source address and port 599 from which an mDNS message was received. This TLV is present in DSO 600 messages from Discovery Relays to Clients that contain encapsulated 601 mDNS messages. DSO-TYPE is TBD-S. DSO-LENGTH is either 6, for an 602 IPv4 address, or 18, for an IPv6 address. DSO-DATA is the two-byte 603 source port, followed by the 4- or 16-byte IP Address. Both port and 604 address are in the canonical byte order (i.e., the same 605 representation as used in the UDP and IP packet headers, with no byte 606 swapping). 608 The IP Source TLV can only be used as an additional TLV. The IP 609 Source TLV can only appear at most once in a Discovery Relay DSO 610 message. 612 8.6. Link State Request 614 The Link State Request TLV requests that the Discovery Relay report 615 link changes. When the relay is reporting link changes and a new 616 link becomes available, it sends a Link Available message to the 617 Client. When a link becomes unavailable, it sends a Link Unavailable 618 message to the Client. If there are links available when the request 619 is received, then for each such link the relay immediately sends a 620 Link Available Message to the Client. DSO-TYPE is TBD-P. DSO-LENGTH 621 is 0. 623 The mDNS Link State Request TLV can only be used as a primary TLV, 624 and requires an acknowledgement. The acknowledgment does not contain 625 a Link Available TLV: it is just a response to the Link State Request 626 message. 628 8.7. Link State Discontinue 630 The Link State Discontinue TLV requests that the Discovery Relay stop 631 reporting on the availability of links supported by the relay. This 632 cancels the effect of a Link State Request TLV. DSO-TYPE is TBD-Q. 633 DSO-LENGTH is 0. 635 The mDNS Link State Discontinue TLV can only be used as a DSO 636 unidirectional message TLV, and is not acknowledged. 638 8.8. Link Available 640 The Link Available TLV is used by Discovery Relays to indicate to 641 Clients that a new link has become available. The format is the same 642 as the Link Identifier TLV. DSO-TYPE is TBD-V. The Link Available 643 TLV may be accompanied by one or more Link Prefix TLVs which indicate 644 IP prefixes the Relay knows to be present on the link. 646 The mDNS Link Available TLV can only be used as a DSO unidirectional 647 message TLV, and is not acknowledged. 649 8.9. Link Unavailable 651 The Link Unavailable TLV is used by Discovery Relays to indicate to 652 Clients that an existing link has become unavailable. The format is 653 the same as the Link Identifier TLV. DSO-TYPE is TBD-U. 655 The mDNS Link Unavailable TLV can only be used as a DSO 656 unidirectional message TLV, and is not acknowledged. 658 8.10. Link Prefix 660 The Link Prefix TLV represents an IP address or prefix configured on 661 a link. The length is 17 for an IPv6 address or prefix, and 5 for an 662 IPv4 address or prefix. The TLV consists of a prefix length, between 663 0 and 32 for IPv4 or between 0 and 128 for IPv6, represented as a 664 single byte. This is followed by the IP address, either four or 665 sixteen bytes. DSO-TYPE is TBD-K. 667 The Link Prefix TLV can only be used as a secondary TLV. 669 9. Provisioning 671 In order for a Discovery Proxy to use Discovery Relays, it must be 672 configured with sufficient information to identify multicast links on 673 which service discovery is to be supported and, if it is not running 674 on a host that is directly connected to those multicast links, 675 connect to Discovery Relays supporting those multicast links. 677 A Discovery Relay must be configured both with a set of multicast 678 links to which the host on which it is running is connected, on which 679 mDNS relay service is to be provided, and also with a list of one or 680 more Clients authorized to use it. 682 On a network supporting DNS Service Discovery using Discovery Relays, 683 more than one different Discovery Relay implementation may be 684 present. While it may be that only a single Discovery Proxy is 685 present, that implementation will need to be able to be configured to 686 interoperate with all of the Discovery Relays that are present. 687 Consequently, it is necessary that a standard set of configuration 688 parameters be defined for both Discovery Proxies and Discovery 689 Relays. 691 DNS Service Discovery generally operates within a constrained set of 692 links, not across the entire internet. This section assumes that 693 what will be configured will be a limited set of links operated by a 694 single entity or small set of cooperating entities, among which 695 services present on each link should be available to users on that 696 link and every other link. This could be, for example, a home 697 network, a small office network, or even a network covering an entire 698 building or small set of buildings. The set of Discovery Proxies and 699 Discovery Relays within such a network will be referred to in this 700 section as a 'Discovery Domain'. 702 Depending on the context, several different candidates for 703 configuration of Discovery Proxies and Discovery Relays may be 704 applicable. The simplest such mechanism is a manual configuration 705 file, but regardless of provisioning mechanism, certain configuration 706 information needs to be communicated to the devices, as outlined 707 below. 709 In the example we provide here, we only refer to configuring of IP 710 addresses, private keys and certificates. It is also possible to use 711 FQDNs to identify servers; this then allows for the use of DANE 712 ([RFC8310] Section 8.2) or PKIX authentication [RFC6125]. Which 713 method is used is to some extent up to the implementation, but at a 714 minimum, it should be possible to associate an IP address with a 715 self-signed certificate, and it should be possible to validate both 716 self-signed and PKIX-authenticated certificates, with PKIX, DANE or a 717 pre-configured trust anchor. 719 9.1. Provisioned Objects 721 Three types of objects must be described in order for Discovery 722 Proxies and Discovery Relays to be provisioned: Discovery Proxies, 723 Multicast Links, and Discovery Relays. "Human-readable" below means 724 actual words or proper names that will make sense to an untrained 725 human being. "Machine-readable" means a name that will be used by 726 machines to identify the entity to which the name refers. Each 727 entity must have a machine-readable name and may have a human- 728 readable name. No two entities can have the same human-readable 729 name. Similarly, no two entities can have the same machine-readable 730 name. 732 9.1.1. Multicast Link 734 The description of a multicast link consists of: 736 link-identifier A 32-bit identifier that uniquely identifies that 737 link within the Discovery Domain. Each link MUST have exactly one 738 such identifier. Link Identifiers do not have any special 739 semantics, and are not intended to be human-readable. 741 ldh-name A fully-qualified domain name for the multicast link that 742 is used to form an LDH domain name as described in section 5.3 of 743 the Discovery Proxy specification [RFC8766]. This name is used to 744 identify the link during provisioning, and must be present. 746 hr-name A human-readable user-friendly fully-qualified domain name 747 for the multicast link. This name MUST be unique within the 748 Discovery Domain. Each multicast link MUST have exactly one such 749 name. The hr-name MAY be the same as the ldh-name. (The hr-name 750 is allowed to contain spaces, punctuation and rich text, but it is 751 not required to do so.) 753 The ldh-name and hr-name can be used to form the LDH and human- 754 readable domain names as described in [RFC8766], section 5.3. 756 Note that the ldh-name and hr-name can be used in two different ways. 758 On a small home network with little or no human administrative 759 configuration, link names may be directly visible to the user. For 760 example, a search in 'home.arpa' on a small home network may discover 761 services on both ethernet.home.arpa and wi-fi.home.arpa. In the case 762 of a home user who has one Ethernet-connected printer and one Wi-Fi- 763 connected printer, discovering that they have one printer on 764 ethernet.home.arpa and another on wi-fi.home.arpa is understandable 765 and meaningful. 767 On a large corporate network with hundreds of Wi-Fi access points, 768 the individual link names of the hundreds of multicast links are less 769 likely to be useful to end users. In these cases, Discovery Broker 770 functionality [I-D.sctl-discovery-broker] may be used to translate 771 the many link names to something more meaningful to users. For 772 example, in a building with 50 Wi-Fi access points, each with their 773 own link names, services on all the different physical links may be 774 presented to the user as appearing in 'headquarters.example.com'. In 775 this case, the individual link names can be thought of similar to MAC 776 addresses or IPv6 addresses. They are used internally by the 777 software as unique identifiers, but generally are not exposed to end 778 users. 780 9.1.2. Discovery Proxy 782 The description of a Discovery Proxy consists of: 784 name a machine-readable name used to reference this Discovery Proxy 785 in provisioning. 787 hr-name an optional human-readable name which can appear in 788 provisioning, monitoring and debugging systems. Must be unique 789 within a Discovery Domain. 791 certificate a certificate that identifies the Discovery Proxy. This 792 certificate can be shared across services on the Discovery Proxy 793 Host. The public key in the certificate is used both to uniquely 794 identify the Discovery Proxy and to authenticate connections from 795 it. The certificate should be signed by its own private key. 797 private-key the private key corresponding to the public key in the 798 certificate. 800 source-ip-addresses a list of IP addresses that may be used by the 801 Discovery Proxy when connecting to Discovery Relays. These 802 addresses should be addresses that are configured on the Discovery 803 Proxy Host. They should not be temporary addresses. All such 804 addresses must be reachable within the Discovery Domain. 806 public-ip-addresses a list of IP addresses that a Discovery Proxy 807 listens on to receive requests from clients. This is not used for 808 interoperation with Discovery Relays, but is mentioned here for 809 completeness: the list of addresses listened on for incoming 810 client requests may differ from the 'source-ip-addresses' list of 811 addresses used for issuing outbound connection requests to 812 Discovery Relays. If any of these addresses are reachable from 813 outside of the Discovery Domain, services in that domain will be 814 discoverable outside of the domain. 816 multicast links a list of multicast links on which this Discovery 817 Proxy is expected to provide service 819 The private key should never be distributed to other hosts; all of 820 the other information describing a Discovery Proxy can be safely 821 shared with Discovery Relays. 823 In some configurations it may make sense for the Discovery Relay not 824 to have a list of links, but simply to support the set of all links 825 available on relays to which the Discovery Proxy is configured to 826 communicate. 828 9.1.3. Discovery Relay 830 The description of a Discovery Relay consists of: 832 name a required machine-readable identifier used to reference the 833 relay 835 hr-name an optional human-readable name which can appear in 836 provisioning, monitoring and debugging systems. Must be unique 837 within a Discovery Domain. 839 certificate a certificate that identifies the Discovery Relay. This 840 certificate can be shared across services on the Discovery Relay 841 Host. Indeed, if a Discovery Proxy and Discovery Relay are 842 running on the same host, the same certificate can be used for 843 both. The public key in the certificate uniquely identifies the 844 Discovery Relay and is used by a Discovery Relay Client (e.g., a 845 Discovery Proxy) to verify that it is talking to the intended 846 Discovery Relay after a TLS connection has been established. The 847 certificate must either be signed by its own key, or have a 848 signature chain that can be validated using PKIX authentication 849 [RFC6125]. 851 private-key the private key corresponding to the public key in the 852 certificate. 854 listen-tuple a list of IP address/port tuples that may be used to 855 connect to the Discovery Relay. The relay may be configured to 856 listen on all addresses on a single port, but this is not 857 required, so the port as well as the address must be specified. 859 multicast links a list of multicast links to which this relay is 860 physically connected. 862 The private key should never be distributed to other hosts; all of 863 the other information describing a Discovery Relay can be safely 864 shared with Discovery Proxies. 866 In some cases a Relay may not be configured with a static list of 867 links, but may simply discover links by monitoring the set of 868 available interfaces on the host on which the Relay is running. In 869 that case, the relay could be configured to identify links based on 870 the names of network interfaces, or based on the set of available 871 prefixes seen on those interfaces. The details of this sort of 872 configuration are not specified in this document. 874 9.2. Configuration Files 876 For this discussion, we assume the simplest possible means of 877 configuring Discovery Proxies and Discovery Relays: the configuration 878 file. Any environment where changes will happen on a regular basis 879 will either require some automatic means of generating these 880 configuration files as the network topology changes, or will need to 881 use a more automatic method for configuration, such as HNCP 882 [RFC7788]. 884 There are many different ways to organize configuration files. This 885 discussion assumes that multicast links, relays and proxies will be 886 specified as objects, as described above, perhaps in a master file, 887 and then the specific configuration of each proxy or relay will 888 reference the set of objects in the master file, referencing objects 889 by name. This approach is not required, but is simply shown as an 890 example. In addition, the private keys for each proxy or relay must 891 appear only in that proxy or relay's configuration file. 893 The master file contains a list of Discovery Relays, Discovery 894 Proxies and Multicast Links. Each object has a name and all the 895 other data associated with it. We do not formally specify the format 896 of the file, but it might look something like this: 898 Relay upstairs 899 certificate xxx 900 listen-tuple 192.0.2.1 1917 901 listen-tuple fd00::1 1917 902 link upstairs-wifi 903 link upstairs-wired 904 client-allow-list main 906 Relay downstairs 907 certificate yyy 908 listen-tuple 192.51.100.1 2088 909 listen-tuple fd00::2 2088 910 link downstairs-wifi 911 link downstairs-wired 912 client-allow-list main 914 Proxy main 915 certificate zzz 916 address 203.1.113.1 918 Link upstairs-wifi 919 id 1 920 hr-name Upstairs Wifi 922 Link upstairs-wired 923 id 2 924 hr-name Upstairs Wired 926 Link downstairs-wifi 927 id 3 928 hr-name Downstairs Wifi 930 Link downstairs-wired 931 id 4 932 hr-name Downstairs Wired 934 9.3. Discovery Proxy Private Configuration 936 The Discovery Proxy configuration contains enough information to 937 identify which Discovery Proxy is being configured, enumerate the 938 list of multicast links it is intended to serve, and provide keying 939 information it can use to authenticate to Discovery Relays. It may 940 also contain custom information about the port and/or IP address(es) 941 on which it will respond to DNS queries. 943 An example configuration, following the convention used in this 944 section, might look something like this: 946 Proxy main 947 private-key zzz 948 subscribe upstairs-wifi 949 subscribe downstairs-wifi 950 subscribe upstairs-wired 951 subscribe downstairs-wired 953 When combined with the master file, this configuration is sufficient 954 for the Discovery Proxy to identify and connect to the Discovery 955 Relays that serve the links it is configured to support. 957 9.4. Discovery Relay Private Configuration 959 The Discovery Relay configuration just needs to tell the Discovery 960 Relay what name to use to find its configuration in the master file, 961 and what the private key is corresponding to its certificate (public 962 key) in the master file. For example: 964 Relay Downstairs 965 private-key yyy 967 10. Security Considerations 969 Part of the purpose of the Multicast DNS Discovery Relay protocol is 970 to place a simple relay, analogous to a BOOTP relay, into routers and 971 similar devices that may not be updated frequently. The BOOTP 972 [RFC0951] protocol has been around since 1985, and continues to be 973 useful today. The BOOTP protocol uses no encryption, and in many 974 enterprise networks this is considered acceptable. In contrast, the 975 Discovery Relay protocol requires TLS 1.3. A concern is that after 976 20 or 30 years, TLS 1.3, or some of the encryption algorithms it 977 uses, may become obsolete, rendering devices that require it 978 unusable. Our assessment is that TLS 1.3 probably will be around for 979 many years to come. TLS 1.0 [RFC2246] was used for about a decade, 980 and similarly TLS 1.2 [RFC5246] was also used for about a decade. We 981 expect TLS 1.3 [RFC8446] to have at least that lifespan. In 982 addition, recent IETF efforts are pushing for better software update 983 practices for devices like routers, for other security reasons, 984 making it likely that in ten years time it will be less common to be 985 using routers that haven't had a software update for ten years. 986 However, authors of encryption specifications and libraries should be 987 aware of the potential backwards compatibility issues if an 988 encryption algorithm becomes deprecated. This specification 989 RECOMMENDS that if an encryption algorithm becomes deprecated, then 990 rather than remove that encryption algorithm entirely, encryption 991 libraries should disable that encryption algorithm by default, but 992 leave the code present with an option for client software to enable 993 it in special cases, such as a recent Client talking to an ancient 994 Discovery Relay. Using no encryption, like BOOTP, would eliminate 995 this backwards compatibility concern, but we feel that in such a 996 future hypothetical scenario, using even a weak encryption algorithm 997 still makes passive eavesdropping and tampering harder, and is 998 preferable to using no encryption at all. 1000 11. IANA Considerations 1002 The IANA is kindly requested to update the DSO Type Codes Registry 1003 [RFC8490] by allocating codes for each of the TBD type codes listed 1004 in the following table, and by updating this document, here and in 1005 Section 8. Each type code should list this document as its reference 1006 document. 1008 +----------+----------+---------------------------+ 1009 | DSO-TYPE | Status | Name | 1010 +----------+----------+---------------------------+ 1011 | TBD-R | Standard | Link Data Request | 1012 | TBD-D | Standard | Link Data Discontinue | 1013 | TBD-L | Standard | Link Identifier | 1014 | TBD-M | Standard | Encapsulated mDNS Message | 1015 | TBD-S | Standard | IP Source | 1016 | TBD-P | Standard | Link State Request | 1017 | TBD-Q | Standard | Link State Discontinue | 1018 | TBD-V | Standard | Link Available | 1019 | TBD-U | Standard | Link Unavailable | 1020 | TBD-K | Standard | Link Prefix | 1021 +----------+----------+---------------------------+ 1023 DSO Type Codes to be allocated 1025 12. Acknowledgments 1027 Thanks to Derek Atkins for the secdir early review. 1029 13. References 1031 13.1. Normative References 1033 [RFC1035] Mockapetris, P., "Domain names - implementation and 1034 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1035 November 1987, . 1037 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1038 Requirement Levels", BCP 14, RFC 2119, 1039 DOI 10.17487/RFC2119, March 1997, 1040 . 1042 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1043 Verification of Domain-Based Application Service Identity 1044 within Internet Public Key Infrastructure Using X.509 1045 (PKIX) Certificates in the Context of Transport Layer 1046 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1047 2011, . 1049 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1050 and A. Bierman, Ed., "Network Configuration Protocol 1051 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1052 . 1054 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1055 DOI 10.17487/RFC6762, February 2013, 1056 . 1058 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1059 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1060 . 1062 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 1063 Scheffenegger, Ed., "TCP Extensions for High Performance", 1064 RFC 7323, DOI 10.17487/RFC7323, September 2014, 1065 . 1067 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1068 D. Wessels, "DNS Transport over TCP - Implementation 1069 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1070 . 1072 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1073 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1074 2016, . 1076 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1077 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1078 May 2017, . 1080 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1081 for DNS over TLS and DNS over DTLS", RFC 8310, 1082 DOI 10.17487/RFC8310, March 2018, 1083 . 1085 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1086 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1087 . 1089 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1090 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 1091 RFC 8490, DOI 10.17487/RFC8490, March 2019, 1092 . 1094 [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 1095 Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 1096 2020, . 1098 13.2. Informative References 1100 [AdFam] "IANA Address Family Numbers Registry", 1101 . 1104 [AdProx] Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD 1105 Service Registration Protocol", draft-sctl-advertising- 1106 proxy-00 (work in progress), July 2020. 1108 [I-D.ietf-mboned-ieee802-mcast-problems] 1109 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 1110 Zuniga, "Multicast Considerations over IEEE 802 Wireless 1111 Media", draft-ietf-mboned-ieee802-mcast-problems-12 (work 1112 in progress), October 2020. 1114 [I-D.sctl-discovery-broker] 1115 Cheshire, S. and T. Lemon, "Service Discovery Broker", 1116 draft-sctl-discovery-broker-00 (work in progress), July 1117 2017. 1119 [NOTSENT] Dumazet, E., "TCP_NOTSENT_LOWAT socket option", July 2013, 1120 . 1122 [PRIO] Chan, W., "Prioritization Only Works When There's Pending 1123 Data to Prioritize", January 2014, 1124 . 1127 [RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, 1128 DOI 10.17487/RFC0951, September 1985, 1129 . 1131 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1132 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1133 . 1135 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1136 (TLS) Protocol Version 1.2", RFC 5246, 1137 DOI 10.17487/RFC5246, August 2008, 1138 . 1140 [TR-069] Broadband Forum, "CPE WAN Management Protocol", November 1141 2013, . 1144 Authors' Addresses 1146 Ted Lemon 1147 Apple Inc. 1148 One Apple Park Way 1149 Cupertino, California 95014 1150 United States of America 1152 Phone: +1 (408) 996-1010 1153 Email: elemon@apple.com 1155 Stuart Cheshire 1156 Apple Inc. 1157 One Apple Park Way 1158 Cupertino, California 95014 1159 United States of America 1161 Phone: +1 (408) 996-1010 1162 Email: cheshire@apple.com