idnits 2.17.1 draft-ietf-dnssd-mdns-relay-00.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? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 301: '...lete, the Discovery Relay MUST request...' RFC 2119 keyword, line 351: '... successful, it MUST send a response ...' RFC 2119 keyword, line 355: '... once; the Relay MUST NOT reject an mD...' RFC 2119 keyword, line 376: '...ssage, if known, MAY be encoded in a L...' RFC 2119 keyword, line 378: '... message MUST be encoded in an IP So...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 710 has weird spacing: '... name a mac...' == Line 713 has weird spacing: '...hr-name an op...' == Line 717 has weird spacing: '...lic-key a pub...' == Line 722 has weird spacing: '...ate-key the p...' == Line 724 has weird spacing: '...dresses a lis...' == (8 more instances...) -- The document date (May 10, 2018) is 2175 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) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-08 ** Downref: Normative reference to an Informational draft: draft-sctl-discovery-broker (ref. 'I-D.sctl-discovery-broker') == Outdated reference: A later version (-20) exists of draft-ietf-dnsop-session-signal-07 -- 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: 3 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 Nibbhaya Consulting 4 Intended status: Standards Track S. Cheshire 5 Expires: November 11, 2018 Apple Inc. 6 May 10, 2018 8 Multicast DNS Discovery Relay 9 draft-ietf-dnssd-mdns-relay-00 11 Abstract 13 This document extends the specification of the Discovery Proxy for 14 Multicast DNS-Based Service Discovery. It describes a lightweight 15 relay mechanism, a Discovery Relay, which, when present on a link, 16 allows Discovery Proxies not attached to that link to provide mDNS 17 proxy service on that link. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 11, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. Connections between Proxies and Relays (overview) . . . . 5 57 3.2. mDNS Messages On Multicast Links . . . . . . . . . . . . 6 58 4. Connections between Proxies and Relays (details) . . . . . . 6 59 5. Traffic from Relays to Clients . . . . . . . . . . . . . . . 8 60 6. Traffic from Clients to Relays . . . . . . . . . . . . . . . 9 61 7. Discovery Proxy Behavior . . . . . . . . . . . . . . . . . . 9 62 8. DSO TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 8.1. mDNS Link Request . . . . . . . . . . . . . . . . . . . . 11 64 8.2. mDNS Link Discontinue . . . . . . . . . . . . . . . . . . 11 65 8.3. Link Identifier . . . . . . . . . . . . . . . . . . . . . 11 66 8.4. mDNS Message . . . . . . . . . . . . . . . . . . . . . . 12 67 8.5. Layer Two Source Address . . . . . . . . . . . . . . . . 12 68 8.6. IP Source . . . . . . . . . . . . . . . . . . . . . . . . 12 69 8.7. Report Link Changes . . . . . . . . . . . . . . . . . . . 13 70 8.8. Stop Reporting Link Changes . . . . . . . . . . . . . . . 13 71 8.9. Link Available . . . . . . . . . . . . . . . . . . . . . 13 72 8.10. Link Unavailable . . . . . . . . . . . . . . . . . . . . 13 73 8.11. Link Prefix . . . . . . . . . . . . . . . . . . . . . . . 14 74 9. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Provisioned Objects . . . . . . . . . . . . . . . . . . . 15 76 9.1.1. Multicast Link . . . . . . . . . . . . . . . . . . . 15 77 9.1.2. Discovery Proxy . . . . . . . . . . . . . . . . . . . 16 78 9.1.3. Discovery Relay . . . . . . . . . . . . . . . . . . . 17 79 9.2. Configuration Files . . . . . . . . . . . . . . . . . . . 18 80 9.3. Discovery Proxy Configuration . . . . . . . . . . . . . . 20 81 9.4. Discovery Relay Configuration . . . . . . . . . . . . . . 20 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 84 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 87 13.2. Informative References . . . . . . . . . . . . . . . . . 24 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 90 1. Introduction 92 The Discovery Proxy for Multicast DNS-Based Service Discovery 93 [I-D.ietf-dnssd-hybrid] is a mechanism for discovering services on a 94 subnetted network through the use of Discovery Proxies, which issue 95 Multicast DNS (mDNS) requests [RFC6762] on various multicast links in 96 the network on behalf of a remote host performing DNS-Based Service 97 Discovery [RFC6763]. 99 In the original Discovery Proxy specification, it is imagined that 100 for every multicast link on which services will be discovered, a host 101 will be present running a full Discovery Proxy. This document 102 introduces a lightweight Discovery Relay that can be used to provide 103 discovery services on a multicast link without requiring a full 104 Discovery Proxy on every multicast link. 106 Since the primary purpose of a Discovery Relay is providing remote 107 virtual interface functionality to Discovery Proxies, this document 108 is written with that in mind. However, in principle, a Discovery 109 Relay could be used by any properly authorized client. In the 110 context of this specification, a Discovery Proxy is a client to the 111 Discovery Relay. This document uses the terms "Discovery Proxy" and 112 "Client" to mean the same thing; the term "Client" is used when we 113 are talking about the communication between the client and the Relay, 114 and the term "Discovery Proxy" when we are referring specifically to 115 something that is acting as a Discovery Proxy. 117 The Discovery Relay operates by listening for TCP connections from 118 Clients. When a Client connects, the connection is authenticated and 119 secured using TLS. The Client can then specify one or more multicast 120 links from which it wishes to receive mDNS traffic. The Client can 121 also send messages to be transmitted on its behalf on one or more of 122 those multicast links. DNS Stateful Operations (DSO) 123 [I-D.ietf-dnsop-session-signal] is used as a framework for conveying 124 interface and IP header information associated with each message. 126 The Discovery Relay functions essentially as a set of one or more 127 remote virtual interfaces for the Client, one on each multicast link 128 to which the Discovery Relay is connected. In a complex network, it 129 is possible that more than one Discovery Relay will be connected to 130 the same multicast link; in this case, the Client ideally should only 131 be using one such Relay Proxy per multicast link, since using more 132 than one will generate duplicate traffic. 134 How such duplication is detected and avoided is out of scope for this 135 document; in principle it could be detected using HNCP [RFC7788] or 136 configured using some sort of orchestration software in conjunction 137 with NETCONF [RFC6241] or CPE WAN Management Protocol [TR-069]. 139 2. Terminology 141 The following definitions may be of use: 143 Client A network service that uses a Discovery Relay to receive mDNS 144 multicast traffic and/or communicate with mDNS Agents. 146 mDNS Agent A host which sends and/or responds to mDNS queries. 148 Discovery Proxy A network service which receives well-formed 149 questions using the DNS protocol, performs multicast DNS queries 150 to answer those questions, and responds with those answers using 151 the DNS protocol. A Discovery Proxy that can communicate with 152 mDNS Agents using a Discovery Relay is also a Client. 154 Discovery Relay A network service which relays received mDNS 155 messages to a Client, and can transmit mDNS messages on behalf of 156 that Client. 158 multicast link A maximal set of network connection points, such that 159 any host connected to any connection point in the set may send a 160 packet with a link-local multicast destination address 161 (specifically the mDNS link-local multicast destination address 162 [RFC6762]) that will be received by all hosts connected to all 163 other connection points in the set. Note that it is becoming 164 increasingly common for a multicast link to be smaller than its 165 corresponding unicast link. For example it is becoming common to 166 have multiple Wi-Fi Access Points on a shared Ethernet backbone, 167 where the multiple Wi-Fi Access Points and their shared Ethernet 168 backbone form a single unicast link (a single IPv4 subnet, or 169 single IPv6 prefix) but not a single multicast link. Unicast 170 packets between two hosts on that IPv4 subnet or IPv6 prefix are 171 correctly delivered, but multicast packets are not forwarded 172 between the various Wi-Fi Access Points. Given the slowness of 173 Wi-Fi multicast, the decision to not forward multicast packets 174 between Wi-Fi Access Points is reasonable, and that further 175 supports the need for technologies like Discovery Proxy and 176 Discovery Relay to facilitate discovery on these networks. 178 whitelist A list of one or more IP addresses from which a Discovery 179 Relay may accept connections. 181 silently discard When a message that is not supported or not 182 permitted is received, and the required response to that message 183 is to "silently discard" it, that means that no response is sent 184 by the service that is discarding the message to the service that 185 sent it. The service receiving the message may log the event, and 186 may also count such events: "silently" does not preclude such 187 behavior. 189 3. Protocol Overview 191 This document describes a way for Discovery Proxies to communicate 192 with mDNS agents on remote multicast links to which they are not 193 directly connected, using a Discovery Relay. As such, there are two 194 parts to the protocol: connections between Discovery Proxies and 195 Discovery Relays, and communications between Discovery Relays and 196 mDNS agents. 198 3.1. Connections between Proxies and Relays (overview) 200 Discovery Relays listen for incoming connection requests. 201 Connections between Clients and Discovery Relays are established by 202 Clients. Connections are authenticated and encrypted using TLS, with 203 both client and server certificates. Connections are long-lived: a 204 Client is expected to send many queries over a single connection, and 205 Discovery Relays will forward all mDNS traffic from subscribed 206 interfaces over the connection. 208 The stream encapsulated in TLS will carry DNS frames as in the DNS 209 TCP protocol [RFC1035] Section 4.2.2. However, all messages will be 210 DSO messages [I-D.ietf-dnsop-session-signal]. There will be four 211 types of such messages between Discovery Relays and Clients: 213 o Control messages from Client to Relay 215 o Link status messages from Relay to Client 217 o mDNS messages from Client to Relay 219 o mDNS messages from Relay to Client 221 Clients can send four different control messages to Relays: the Link 222 Request, Link Discontinue, Report Link Changes and Stop Reporting 223 Link Changes messages. The first two are used by the Client to 224 indicate to the Discovery Relay that mDNS messages from one or more 225 specified multicast links are to be relayed to the Discovery Proxy, 226 and to subsequently stop such relaying. The second two are used by 227 the Client to request that the Relay report on the set of links that 228 can be requested, and to request that it discontinue such reporting. 230 Link Status messages from the Relay to the Client inform the client 231 that a link has become available, or that a formerly-available link 232 is no longer available. 234 mDNS messages from a Discovery Proxy to a Discovery Relay cause the 235 Discovery Relay to transmit the mDNS message on one or more multicast 236 links to which the Discovery Relay host is directly attached. 238 mDNS messages from a Discovery Relay to a Discovery Proxy are sent 239 whenever an mDNS message is received on a multicast link to which the 240 Discovery Relay has subscribed. 242 During periods with no traffic flowing, Clients are responsible for 243 generating any necessary keepalive traffic, as stated in the DSO 244 specification [I-D.ietf-dnsop-session-signal]. 246 3.2. mDNS Messages On Multicast Links 248 Discovery Relays listen for mDNS traffic on all configured multicast 249 links that have at least one active subscription from a Discovery 250 Proxy. When an mDNS message is received on a multicast link, it is 251 forwarded on every open Client connection that is subscribed to mDNS 252 traffic on that multicast link. In the event of congestion, where a 253 particular Client connection has no buffer space for an mDNS message 254 that would otherwise be forwarded to it, the mDNS message is not 255 forwarded to it. Normal mDNS retry behavior is used to recover from 256 this sort of packet loss. Discovery Relays are not expected to 257 buffer more than a few mDNS packets. Excess mDNS packets are 258 silently discarded. In practice this is not expected to be a issue. 259 Particularly on networks like Wi-Fi, multicast packets are 260 transmitted at rates ten or even a hundred times slower than unicast 261 packets. This means that even at peak multicast packets rates, it is 262 likely that a unicast TCP connection will able to carry those packets 263 with ease. 265 Clients send mDNS messages they wish to have sent on their behalf on 266 remote multicast link(s) on which the Client has an active 267 subscription. A Discovery Relay will not transmit mDNS packets on 268 any multicast link on which the Client does not have an active 269 subscription, since it makes no sense for a Client to ask to have a 270 query sent on its behalf if it's not able to receive the responses to 271 that query. 273 4. Connections between Proxies and Relays (details) 275 When a Discovery Relay starts, it opens a passive TCP listener to 276 receive incoming connection requests from Clients. This listener may 277 be bound to one or more source IP addresses, or to the wildcard 278 address, depending on the implementation. When a connection is 279 received, the relay must first validate that it is a connection to an 280 IP address to which connections are allowed. For example, it may be 281 that only connections to ULAs are allowed, or to the IP addresses 282 configured on certain interfaces. If the listener is bound to a 283 specific IP address, this check is unnecessary. 285 If the relay is using an IP address whitelist, the next step is for 286 the relay to verify that that the source IP address of the connection 287 is on its whitelist. If the connection is not permitted either 288 because of the source address or the destination address, the 289 Discovery Relay responds to the TLS Client Hello message from the 290 Client with a TLS user_canceled alert ([I-D.ietf-tls-tls13] 291 Section 6.1). 293 Otherwise, the Discovery Relay will attempt to complete a TLS 294 handshake with the Client. Clients are required to send the 295 post_handshake_auth extension ([I-D.ietf-tls-tls13] Section 4.2.5). 296 If a Discovery Relay receives a ClientHello message with no 297 post_handshake_auth extension, the Discovery Relay rejects the 298 connection with a certificate_required alert ([I-D.ietf-tls-tls13] 299 Section 6.2). 301 Once the TLS handshake is complete, the Discovery Relay MUST request 302 post-handshake authentication as described in ([I-D.ietf-tls-tls13] 303 Section 4.6.2). If the Client refuses to send a certificate, or the 304 key presented does not match the key associated with the IP address 305 from which the connection originated, or the CertificateVerify does 306 not validate, the connection is dropped with the TLS access_denied 307 alert ([I-D.ietf-tls-tls13] Section 6.2). 309 Once the connection is established and authenticated, it is treated 310 as a DNS TCP connection [RFC1035]. 312 Aliveness of connections between Clients and Relays is maintained as 313 described in Section 4 of [I-D.ietf-dnsop-session-signal]. Clients 314 must also honor the 'Retry Delay' TLV (section 5 of 315 [I-D.ietf-dnsop-session-signal]) if sent by the Discovery Relay. 317 Clients may establish more than one connection to a specific 318 Discovery Relay. This would happen in the case that a TCP connection 319 stalls, and the Client is able to reconnect before the previous 320 connection has timed out. It could also happen as a result of a 321 server restart. It is not likely that two active connections from 322 the same Client would be present at the same time, but it must be 323 possible for additional connections to be established. The Discovery 324 Relay may drop the old connection when the new one has been fully 325 established, including a successful TLS handshake. What it means for 326 two connections to be from the same Client is that the connections 327 both have source addresses that belong to the same Client, and that 328 they were authenticated using the same client certificate. 330 In order to know what links to request, the Client can be configured 331 with a list of links supported by the Relay. However, in some 332 networking contexts, dynamic changes in the availability of links are 333 likely; therefore Clients may also use the Report Link Changes TLV to 334 request that the Relay report on the availability of its links. In 335 some contexts, for example when debugging, a Client may operate with 336 no information about the set of links supported by a relay, simply 337 relying on the relay to provide one. 339 5. Traffic from Relays to Clients 341 The mere act of connecting to a Discovery Relay does not result in 342 any mDNS traffic being forwarded. In order to request that mDNS 343 traffic from a particular multicast link be forwarded on a particular 344 connection, the Client must send one or more DSO messages, each 345 containing a single mDNS Link Request TLV (Section 8.1) indicating 346 the multicast link from which traffic is requested. 348 When an mDNS Link Request message is received, the Discovery Relay 349 validates that it is connected to the specified multicast link, and 350 that forwarding is enabled for that link. If both checks are 351 successful, it MUST send a response with RCODE=0 (NOERROR). If the 352 Relay is not connected to the specified link, or forwarding from that 353 link to the Client is not enabled, it sends a response with RCODE=3 354 (NXDOMAIN/Name Error). It is not an error to request the same link 355 more than once; the Relay MUST NOT reject an mDNS Link Request on 356 that basis. If the relay cannot satisfy the request for some reason 357 other than that the link is invalid, for example resource exhaustion, 358 it sends a response with RCODE=2 (SERVFAIL). 360 If the requested link is valid, the Relay begins forwarding all mDNS 361 traffic from that link to the Client. Delivery is not guaranteed: if 362 there is no buffer space, packets will be dropped. It is expected 363 that regular mDNS retry processing will take care of retransmission 364 of lost packets. The amount of buffer space is implementation 365 dependent, but generally should not be more than the bandwidth delay 366 product of the TCP connection [RFC1323]. The Discovery Relay should 367 use the TCP_NOTSENT_LOWAT mechanism [NOTSENT][PRIO] or equivalent, to 368 avoid building up a backlog of data in excess of the amount necessary 369 to have in flight to fill the bandwidth delay product of the TCP 370 connection. 372 mDNS messages from Relays to Clients are framed within DSO messages. 373 Each DSO message can contain multiple TLVs, but only a single mDNS 374 message is conveyed per DSO message. Each forwarded mDNS message is 375 contained in an mDNS Message TLV (Section 8.4). The layer two source 376 address of the message, if known, MAY be encoded in a Layer Two 377 Source TLV (Section 8.5). The source IP address and port of the 378 message MUST be encoded in an IP Source TLV (Section 8.6). The 379 multicast link on which the message was received MUST be encoded in a 380 Link Identifier TLV (Section 8.3). The Client MUST silently ignore 381 unrecognized TLVs in mDNS messages, and MUST NOT discard mDNS 382 messages that include unrecognized TLVs. 384 A Client may discontinue listening for mDNS messages on a particular 385 multicast link by sending a DSO message containing an mDNS Link 386 Discontinue TLV (Section 8.2). Subsequent messages from that link 387 that had previously been queued may arrive after listening has been 388 discontinued. The Client should silently discard such messages. The 389 Discovery Relay MUST discontinue generating such messages as soon as 390 the request is received. The Discovery Relay does not respond to 391 this message other than to discontinue forwarding mDNS messages from 392 the specified links. 394 6. Traffic from Clients to Relays 396 Like mDNS traffic from relays, each mDNS message sent by a Client to 397 a Discovery Relay is encapsulated in an mDNS Message TLV 398 (Section 8.4) within a DSO message. Each message MUST contain one or 399 more Link Identifier TLVs (Section 8.3). The Discovery Relay will 400 transmit the message to the mDNS port and multicast address on each 401 link specified in the message using the specified IP address family. 403 Although the communication between Clients and Relays uses the DNS 404 stream protocol and DNS Stateless Operations, there is no case in 405 which a Client would legitimately send a DNS query (something other 406 than a DSO message) to a Relay. Therefore, if a Relay receives a 407 message other than a DSO message, it MUST respond with a REFUSED 408 result code. The reason not to simply drop the connection is that it 409 might result in a continual reconnection loop. 411 7. Discovery Proxy Behavior 413 Discovery Proxies treat multicast links for which Discovery Relay 414 service is being used as if they were virtual interfaces; in other 415 words, a Discovery Proxy serving multiple multicast links using 416 multiple Discovery Relays behaves the same as a Discovery Proxy 417 serving multiple multicast links using multiple physical network 418 interfaces. In this section we refer to multicast links served 419 directly by the Discovery Proxy as locally-connected links, and 420 multicast links served through the Discovery Relay as relay-connected 421 links. 423 What this means is that when a Discovery Proxy receives a DNSSD query 424 from a client via unicast, it will generate mDNS query messages on 425 the relevant multicast link(s) for which it is acting as a proxy. 427 For locally-connected link(s), those query messages will be sent 428 directly. For relay-connected link(s), the query messages will be 429 sent through the Discovery Relay that is being used to serve that 430 multicast link. 432 Responses from devices on locally-connected links are processed 433 normally. Responses from devices on relay-connected links are 434 received by the Discovery Relay, encapsulated, and forwarded to the 435 Discovery Proxy; the Discovery Proxy then processes these messages 436 using the link-identifying information included in the encapsulation. 438 Discovery Proxies do not generally respond to mDNS queries on relay- 439 connected links. The one exception is responding to the Domain 440 Enumeration queries used to bootstrap unicast service discovery 441 ("lb._dns-sd._udp.local", etc.) [RFC6763]. Apart from these Domain 442 Enumeration queries, if any other mDNS query is received from a 443 Discovery Relay, the Discovery Proxy silently discards it. 445 In principle it could be the case that some device is capable of 446 performing service discovery using Multicast DNS, but not using 447 traditional unicast DNS. Responding to mDNS queries received from 448 the Discovery Relay could address this use case. However, continued 449 reliance on multicast is counter to the goals of the current work in 450 service discovery, and to benefit from wide-area service discovery 451 such client devices should be updated to support service discovery 452 using unicast queries. 454 8. DSO TLVs 456 This document defines a modest number of new DSO TLVs. 458 8.1. mDNS Link Request 460 The mDNS Link Request TLV conveys a link identifier from which a 461 Client is requesting that a Discovery Relay forward mDNS traffic. 462 The link identifier comes from the provisioning configuration (see 463 Section 9). The DSO-TYPE for this TLV is TBD-R. DSO-LENGTH is 464 always 5. DSO-DATA is the 8-bit address family followed by the 465 32-bit link identifier, in network byte order, as described in 466 Section 9. An address family value of 1 indicates IPv4 and 2 467 indicates IPv6, as recorded in the IANA Registry of Address Family 468 Numbers [AdFam]. 470 The mDNS Link Request TLV can only be used as a primary TLV, and 471 requires an acknowledgement. 473 At most one mDNS Link Request TLV may appear in a DSO message. To 474 request multiple link subscriptions, multiple separate DSO messages 475 are sent, each containing a single mDNS Link Request TLV. 477 8.2. mDNS Link Discontinue 479 The mDNS Link Discontinue TLV is used by Clients to unsubscribe to 480 mDNS messages on the specified multicast link. DSO-TYPE is TBD-D. 481 DSO-LENGTH is always 5. DSO-DATA is the 8-bit address family 482 followed by the 32-bit link identifier, in network byte order, as 483 described in Section 9. 485 The mDNS Link Discontinue TLV can only be used as a primary TLV, and 486 is not acknowledged. 488 At most one mDNS Link Discontinue TLV may appear in a DSO message. 489 To unsubscribe from multiple links, multiple separate DSO messages 490 are sent, each containing a single mDNS Link Discontinue TLV. 492 8.3. Link Identifier 494 This option is used both in DSO messages from Discovery Relays to 495 Clients that contain received mDNS messages, and from Clients to 496 Discovery Relays that contain mDNS messages to be transmitted on the 497 multicast link. In the former case, it indicates the multicast link 498 on which the message was received; in the latter case, it indicates 499 the multicast link on which the message should be transmitted. DSO- 500 TYPE is TBD-L. DSO-LENGTH is always 5. DSO-DATA is the 8-bit 501 address family followed by the 32-bit link identifier, in network 502 byte order, as described in Section 9. 504 The Link Identifier TLV can only be used as an additional TLV. 506 8.4. mDNS Message 508 The mDNS Message TLV is used to encapsulate an mDNS message that a 509 Relay is forwarding from a multicast link to a Client, or that a 510 Client is sending to a Relay for transmission on a multicast link. 511 Only the application layer payload of the mDNS message is carried in 512 the DSO mDNS Message TLV, i.e., just the DNS message itself, 513 beginning with the DNS Message ID, not the IP or UDP headers. The 514 DSO-TYPE for this TLV is TBD-M. DSO-LENGTH is the length of the 515 encapsulated mDNS message. DSO-DATA is the content of the 516 encapsulated mDNS message. 518 The mDNS Message TLV can only be used as a primary TLV, and is not 519 acknowledged. 521 8.5. Layer Two Source Address 523 The Layer Two Source Address TLV is used to report the link-layer 524 address from which an mDNS message was received. This TLV is 525 optionally present in DSO messages from Discovery Relays to Clients 526 that contain mDNS messages when the source link-layer address is 527 known. The DSO-TYPE is TBD-2. DSO-LENGTH is variable, depending on 528 the length of link-layer addresses on the link from which the message 529 was received. DSO-DATA is the link-layer address as it was received 530 on the link. 532 The Layer Two Source Address TLV can only be used as an additional 533 TLV. 535 8.6. IP Source 537 The IP Source TLV is used to report the IP source address and port 538 from which an mDNS message was received. This TLV is present in DSO 539 messages from Discovery Relays to Clients that contain mDNS messages. 540 DSO-TYPE is TBD-A. DSO-LENGTH is either 6, for an IPv4 address, or 541 18, for an IPv6 address. DSO-DATA is the two-byte source port, 542 followed by the 4- or 16-byte IP Address, in network byte order. 544 The IP Source TLV can only be used as an additional TLV. 546 8.7. Report Link Changes 548 The Report Link Changes TLV requests that the Discovery Relay report 549 link changes. When the relay is reporting link changes and a new 550 link becomes available, it sends a Link Available message to the 551 Client. When a link becomes unavailable, it sends a Link Unavailable 552 message to the Client. If there are links available when the request 553 is received, then for each such link the relay immediately sends a 554 Link Available Message to the Client. DSO-TYPE is TBD-P. DSO-LENGTH 555 is 0. 557 The mDNS Report Link Changes TLV can only be used as a primary TLV, 558 and requires an acknowledgement. The acknowledgment does not contain 559 a Link Available TLV: it is just a response to the Report Link 560 Changes message. 562 8.8. Stop Reporting Link Changes 564 The Stop Reporting Link Changes TLV requests that the Discovery Relay 565 stop reporting on the availability of links supported by the relay. 566 This cancels the effect of a Report Link Changes TLV. DSO-TYPE is 567 TBD-S. DSO-LENGTH is 0. 569 The mDNS Stop Reporting Link Changes TLV can only be used as a 570 primary TLV, and is not acknowledged. 572 8.9. Link Available 574 The Link Available TLV is used by Discovery Relays to indicate to 575 clients that a new link has become available. The format is the same 576 as the Link Identifier TLV. DSO-TYPE is TBD-V. The Link Available 577 TLV may be accompanied by one or more Link Prefix TLVs which indicate 578 IP prefixes the Relay knows to be present on the link. 580 The mDNS Link Available TLV can only be used as a primary TLV, and is 581 not acknowledged. 583 8.10. Link Unavailable 585 The Link Unavailable TLV is used by Discovery Relays to indicate to 586 clients that an existing link has become unavailable. The format is 587 the same as the Link Identifier TLV. DSO-TYPE is TBD-U. 589 The mDNS Link Unavailable TLV can only be used as a primary TLV, and 590 is not acknowledged. 592 8.11. Link Prefix 594 The Link Prefix TLV represents an IP address or prefix configured on 595 a link. The length is 17 for an IPv6 address or prefix, and 5 for an 596 IPv4 address or prefix. The TLV consists of a prefix length, between 597 0 and 32 for IPv4 or between 0 and 128 for IPv6, represented as a 598 single byte. This is followed by the IP address, either four or 599 sixteen bytes. DSO-TYPE is TBD-K. 601 The Link Prefix TLV can only be used as a secondary TLV. 603 9. Provisioning 605 In order for a Discovery Proxy to use Discovery Relays, it must be 606 configured with sufficient information to identify multicast links on 607 which service discovery is to be supported and connect to discovery 608 relays supporting those multicast links, if it is not running on a 609 host that is directly connected to those multicast links. 611 A Discovery Relay must be configured both with a set of multicast 612 links to which the host on which it is running is connected, on which 613 mDNS relay service is to be provided, and also with a list of one or 614 more Clients authorized to use it. 616 On a network supporting DNS Service Discovery using Discovery Relays, 617 more than one different Discovery Relay implementation is likely be 618 present. While it may be that only a single Discovery Proxy is 619 present, that implementation will need to be able to be configured to 620 interoperate with all of the Discovery Relays that are present. 621 Consequently, it is necessary that a standard set of configuration 622 parameters be defined for both Discovery Proxies and Discovery 623 Relays. 625 DNS Service Discovery generally operates within a constrained set of 626 links, not across the entire internet. This section assumes that 627 what will be configured will be a limited set of links operated by a 628 single entity or small set of cooperating entities, among which 629 services present on each link should be available to users on that 630 link and every other link. This could be, for example, a home 631 network, a small office network, or even a network covering an entire 632 building or small set of buildings. The set of Discovery Proxies and 633 Discovery Relays within such a network will be referred to in this 634 section as a 'Discovery Domain'. 636 Depending on the context, several different candidates for 637 configuration of Discovery Proxies and Discovery relays may be 638 applicable. The simplest such mechanism is a manual configuration 639 file, but regardless of provisioning mechanism, certain configuration 640 information needs to be communicated to the devices, as outlined 641 below. 643 9.1. Provisioned Objects 645 Three types of objects must be described in order for Discovery 646 Proxies and Discovery Relays to be provisioned: Discovery Proxies, 647 Multicast Links, and Discovery Relays. "Human-readable" below means 648 actual words or proper names that will make sense to an untrained 649 human being. "Machine-readable" means a name that will be used by 650 machines to identify the entity to which the name refers. Each 651 entity must have a machine-readable name and may have a human- 652 readable name. No two entities can have the same human-readable 653 name. Similarly, no two entities can have the same machine-readable 654 name. 656 9.1.1. Multicast Link 658 The description of a multicast link consists of: 660 link-identifier A 32-bit identifier that uniquely identifies that 661 link within the Discovery Domain. Each link MUST have exactly one 662 such identifier. Link Identifiers do not have any special 663 semantics, and are not intended to be human-readable. 665 ldh-name A fully-qualified domain name for the multicast link that 666 is used to form an LDH domain name as described in section 5.3 of 667 the Discovery Proxy specification [I-D.ietf-dnssd-hybrid]. This 668 name is used to identify the link during provisioning, and must be 669 present. 671 hr-name A human-readable user-friendly fully-qualified domain name 672 for the multicast link. This name MUST be unique within the 673 Discovery Domain. Each multicast link MUST have exactly one such 674 name. The hr-name MAY be the same as the ldh-name. (The hr-name 675 is allowed to contain spaces, punctuation and rich text, but it is 676 not required to do so.) 678 The ldh-name and hr-name can be used to form the LDH and human- 679 readable domain names as described in [I-D.ietf-dnssd-hybrid], 680 section 5.3. 682 Note that the ldh-name and hr-name can be used in two different ways. 684 On a small home network with little or no human administrative 685 configuration, link names may be directly visible to the user. For 686 example, a search in 'home.arpa' on a small home network may discover 687 services on both ethernet.home.arpa and wi-fi.home.arpa. In the case 688 of a home user who has one Ethernet-connected printer and one Wi-Fi- 689 connected printer, discovering that they have one printer on 690 ethernet.home.arpa and another on wi-fi.home.arpa is understandable 691 and meaningful. 693 On a large corporate network with hundreds of Wi-Fi Access Points, 694 the individual link names of the hundreds of multicast links are less 695 likely to be useful to end users. In these cases, Discovery Broker 696 functionality [I-D.sctl-discovery-broker] is used to translate the 697 many link names to something more meaningful to users. For example, 698 in a building with 50 Wi-Fi Access Points, each with their own link 699 names, services on all the different physical links may be presented 700 to the user as appearing in 'headquarters.example.com'. In this 701 case, the individual link names can be thought of similar to MAC 702 addresses or IPv6 addresses. They are used internally by the 703 software as unique identifiers, but generally are not exposed to end 704 users. 706 9.1.2. Discovery Proxy 708 The description of a Discovery Proxy consists of: 710 name a machine-readable name used to reference this Discovery Proxy 711 in provisioning. 713 hr-name an optional human-readable name which can appear in 714 provisioning, monitoring and debugging systems. Must be unique 715 within a Discovery Domain. 717 public-key a public key that identifies the Discovery Proxy. This 718 key can be shared across services on the Discovery Proxy Host. 719 The public key is used both to uniquely identify the Discovery 720 Proxy and to authenticate connections from it. 722 private-key the private key corresponding to the public key. 724 source-ip-addresses a list of IP addresses that may be used by the 725 Discovery Proxy when connecting to Discovery Relays. These 726 addresses should be addresses that are configured on the Discovery 727 Proxy Host. They should not be temporary addresses. All such 728 addresses must be reachable within the Discovery Domain. 730 public-ip-addresses a list of IP addresses that may be used to 731 submit DNS queries to the Discovery Proxy. This is not used for 732 interoperation with Discovery Relays, but is mentioned here for 733 completeness: this list of addresses may differ from the 'source- 734 ip-addresses' list. If any of these addresses are reachable from 735 outside of the Discovery Domain, services in that domain will be 736 discoverable outside of the domain. 738 multicast links a list of multicast links on which this Discovery 739 Proxy is expected to provide service 741 The private key should never be distributed to other hosts; all of 742 the other information describing a Discovery Proxy can be safely 743 shared with Discovery Relays. 745 In some configurations it may make sense for the Discovery Relay not 746 to have a list of links, but simply to support the set of all links 747 available on relays to which the Proxy is configured to communicate. 749 9.1.3. Discovery Relay 751 The description of a Discovery Relay consists of: 753 name a required machine-readable identifier used to reference the 754 relay 756 hr-name an optional human-readable name which can appear in 757 provisioning, monitoring and debugging systems. Must be unique 758 within a Discovery Domain. 760 public-key a public key that identifies the Discovery Relay. This 761 key can be shared across services on the Discovery Relay Host. 762 Indeed, if a Discovery Proxy and Discovery Relay are running on 763 the same host, the same key may be used for both. The public key 764 uniquely identifies the Discovery Relay and is used by the 765 Discovery Proxy to verify that it is talking to the intended 766 Discovery Relay after a TLS connection has been established. 768 private-key the private key corresponding to the public key. 770 connect-tuples a list of IP address/port tuples that may be used to 771 connect to the Discovery Relay. The relay may be configured to 772 listen on all addresses on a single port, but this is not 773 required, so the port as well as the address must be specified. 775 multicast links a list of multicast links to which this relay is 776 physically connected. 778 The private key should never be distributed to other hosts; all of 779 the other information describing a Discovery Relay can be safely 780 shared with Discovery Proxies. 782 In some cases a Relay may not be configured with a static list of 783 links, but may simply discover links by monitoring the set of 784 available interfaces on the host on which the Relay is running. In 785 that case, the relay could be configured to identify links based on 786 the names of network interfaces, or based on the set of available 787 prefixes seen on those interfaces. This sort of configuration is out 788 of scope for this discussion and is left as an exercise for the 789 reader. 791 9.2. Configuration Files 793 For this discussion, we assume the simplest possible means of 794 configuring Discovery Proxies and Discovery Relays: the configuration 795 file. Any environment where changes will happen on a regular basis 796 will either require some automatic means of generating these 797 configuration files as the network topology changes, or will need to 798 use a more automatic method for configuration, such as HNCP 799 [RFC7788]. 801 There are many different ways to organize configuration files. This 802 discussion assumes that multicast links, relays and proxies will be 803 specified as objects, as described above, perhaps in a master file, 804 and then the specific configuration of each proxy or relay will 805 reference the set of objects in the master file, referencing objects 806 by name. This approach is not required, but is simply shown as an 807 example. In addition, the private keys for each proxy or relay must 808 appear only in that proxy or relay's configuration file. 810 The master file contains a list of Discovery Relays, Discovery 811 Proxies and Multicast Links. Each object has a name and all the 812 other data associated with it. We do not formally specify the format 813 of the file, but it might look something like this: 815 Relay upstairs 816 public-key xxx 817 connect-tuple 192.0.2.1 1917 818 connect-tuple fd00::1 1917 819 link upstairs-wifi 820 link upstairs-wired 821 Relay downstairs 822 public-key yyy 823 connect-tuple 192.51.100.1 2088 824 connect-tuple fd00::2 2088 825 link downstairs-wifi 826 link downstairs-wired 827 Proxy main 828 public-key zzz 829 address 203.1.113.1 830 Link upstairs-wifi 831 id 1 832 name Upstairs Wifi 833 Link upstairs-wired 834 id 2 835 hr-name Upstairs Wired 836 Link downstairs-wifi 837 id 3 838 name Downstairs Wifi 839 Link downstairs-wired 840 id 4 841 hr-name Downstairs Wired 843 9.3. Discovery Proxy Configuration 845 The Discovery Proxy configuration contains enough information to 846 identify which Discovery Proxy is being configured, enumerate the 847 list of multicast links it is intended to serve, and provide keying 848 information it can use to authenticate to Discovery Relays. It may 849 also contain custom information about the port and/or IP address(es) 850 on which it will respond to DNS queries. 852 An example configuration, following the convention used in this 853 section, might look something like this: 855 Proxy main 856 private-key zzz 857 subscribe upstairs-wifi 858 subscribe downstairs-wifi 859 subscribe upstairs-wired 860 subscribe downstairs-wired 862 When combined with the master file, this configuration is sufficient 863 for the Discovery Proxy to identify and connect to the relay proxies 864 that serve the links it is configured to support. 866 9.4. Discovery Relay Configuration 868 The discovery relay configuration just needs to tell the discovery 869 relay what name to use to find its configuration in the master file, 870 and what the private key is corresponding to its public key in the 871 master file. For example: 873 Relay Downstairs 874 private-key yyy 876 10. Security Considerations 878 Part of the purpose of the Multicast DNS Discovery Relay protocol is 879 to place a simple relay, analogous to a BOOTP relay, into routers and 880 similar devices that may not be updated frequently. The BOOTP 881 [RFC0951] protocol has been around since 1985, and continues to be 882 useful today. The BOOTP protocol uses no encryption, and in many 883 enterprise networks this is considered acceptable. In contrast, the 884 relay protocol requires TLS 1.3. A concern is that after 20 or 30 885 years TLS 1.3, or some of the encryption algorithms it uses, may 886 become obsolete, rendering devices that require it unusable. Our 887 assessment is that TLS 1.3 probably will be around for many years to 888 come. TLS 1.0 [RFC2246] was used for about a decade, and similarly 889 TLS 1.2 [RFC5246] was also used for about a decade. We expect TLS 890 1.3 [I-D.ietf-tls-tls13] to have at least that lifespan. In 891 addition, recent IETF efforts are pushing for better software update 892 practices for devices like routers, for other security reasons, 893 making less likely that in ten years time it will be less common to 894 be using routers that haven't had a software update for ten years. 895 However, authors of encryption specifications and libraries should be 896 aware of the potential backwards compatibility issues if an 897 encryption algorithm becomes deprecated. This specification 898 RECOMMENDS that if an encryption algorithm becomes deprecated, then 899 rather than remove that encryption algorithm entirely, encryption 900 libraries should disable that encryption algorithm by default, but 901 leave the code present with an option for client software to enable 902 it in special cases, such as a Multicast DNS Discovery Relay client 903 talking to an ancient Multicast DNS Discovery Relay server. Using no 904 encryption like BOOTP would eliminate this backwards compatibility 905 concern, but we feel that in such a future hypothetical scenario, 906 using even a weak encryption algorithm still makes passive 907 eavesdropping and tampering harder, and is preferable to using no 908 encryption at all. 910 11. IANA Considerations 912 The IANA is kindly requested to update the DSO Type Codes Registry 913 [I-D.ietf-dnsop-session-signal] by allocating codes for each of the 914 TBD type codes listed in the following table, and by updating this 915 document, here and in Section 8. Each type code should list this 916 document as its reference document. 918 +--------+----------+-----------------------------+ 919 | Opcode | Status | Name | 920 +--------+----------+-----------------------------+ 921 | TBD-R | Standard | mDNS Link Request | 922 | TBD-D | Standard | mDNS Discontinue | 923 | TBD-L | Standard | Link Identifier | 924 | TBD-M | Standard | mDNS Messsage | 925 | TBD-2 | Standard | Layer Two Source Address | 926 | TBD-A | Standard | IP Source | 927 | TBD-P | Standard | Report Link Changes | 928 | TBD-S | Standard | Stop Reporting Link Changes | 929 | TBD-V | Standard | Link Available | 930 | TBD-U | Standard | Link Unavailable | 931 | TBD-K | Standard | Link Prefix | 932 +--------+----------+-----------------------------+ 934 DSO Type Codes to be allocated 936 12. Acknowledgments 937 13. References 939 13.1. Normative References 941 [RFC1035] Mockapetris, P., "Domain names - implementation and 942 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 943 November 1987, . 945 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 946 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 947 1992, . 949 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 950 and A. Bierman, Ed., "Network Configuration Protocol 951 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 952 . 954 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 955 DOI 10.17487/RFC6762, February 2013, . 958 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 959 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 960 . 962 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 963 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 964 2016, . 966 [I-D.ietf-dnssd-hybrid] 967 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 968 Service Discovery", draft-ietf-dnssd-hybrid-08 (work in 969 progress), March 2018. 971 [I-D.sctl-discovery-broker] 972 Cheshire, S. and T. Lemon, "Service Discovery Broker", 973 draft-sctl-discovery-broker-00 (work in progress), July 974 2017. 976 [I-D.ietf-dnsop-session-signal] 977 Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 978 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 979 draft-ietf-dnsop-session-signal-07 (work in progress), 980 March 2018. 982 [I-D.ietf-tls-tls13] 983 Rescorla, E., "The Transport Layer Security (TLS) Protocol 984 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 985 March 2018. 987 13.2. Informative References 989 [RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, 990 DOI 10.17487/RFC0951, September 1985, . 993 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 994 RFC 2246, DOI 10.17487/RFC2246, January 1999, 995 . 997 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 998 (TLS) Protocol Version 1.2", RFC 5246, 999 DOI 10.17487/RFC5246, August 2008, . 1002 [TR-069] Broadband Forum, "CPE WAN Management Protocol", November 1003 2013, . 1006 [NOTSENT] "TCP_NOTSENT_LOWAT socket option", July 2013, 1007 . 1009 [PRIO] "Prioritization Only Works When There's Pending Data to 1010 Prioritize", January 2014, . 1014 [AdFam] "IANA Address Family Numbers Registry", 1015 . 1018 Authors' Addresses 1020 Ted Lemon 1021 Nibbhaya Consulting 1022 P.O. Box 958 1023 Brattleboro, Vermont 05301 1024 United States of America 1026 Email: mellon@fugue.com 1027 Stuart Cheshire 1028 Apple Inc. 1029 1 Infinite Loop 1030 Cupertino, California 95014 1031 USA 1033 Phone: +1 408 974 3207 1034 Email: cheshire@apple.com