idnits 2.17.1 draft-sctl-dnssd-mdns-relay-02.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-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 272: '...lete, the Discovery Relay MUST request...' RFC 2119 keyword, line 334: '...ssage, if known, MAY be encoded in a L...' RFC 2119 keyword, line 336: '... message MUST be encoded in a IP Sou...' RFC 2119 keyword, line 337: '...age was received MUST be encoded in a ...' RFC 2119 keyword, line 338: '...4). The Discovery Proxy MUST silently...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 520 has weird spacing: '... name a mac...' == Line 523 has weird spacing: '...hr-name an op...' == Line 527 has weird spacing: '...lic-key a pub...' == Line 532 has weird spacing: '...ate-key the p...' == Line 534 has weird spacing: '...dresses a lis...' == (8 more instances...) -- The document date (November 12, 2017) is 2328 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 (-20) exists of draft-ietf-dnsop-session-signal-04 == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-07 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Cheshire 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track T. Lemon 5 Expires: May 16, 2018 Barefoot Consulting 6 November 12, 2017 8 Multicast DNS Discovery Relay 9 draft-sctl-dnssd-mdns-relay-02 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 allows Discovery Proxies to 16 provide service on multicast links to which they are not directly 17 attached. 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 https://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 May 16, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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 (https://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 Proxies . . . . . . . . . . . . . . . 7 60 6. Traffic from Proxies to Relays . . . . . . . . . . . . . . . 8 61 7. Discovery Proxy Behavior . . . . . . . . . . . . . . . . . . 9 62 8. DSO TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 8.1. mDNS Link Request . . . . . . . . . . . . . . . . . . . . 10 64 8.2. mDNS Discontinue . . . . . . . . . . . . . . . . . . . . 10 65 8.3. mDNS Message . . . . . . . . . . . . . . . . . . . . . . 10 66 8.4. Link Identifier . . . . . . . . . . . . . . . . . . . . . 10 67 8.5. Layer Two Source Address . . . . . . . . . . . . . . . . 11 68 8.6. IP Source . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9.1. Provisioned Objects . . . . . . . . . . . . . . . . . . . 12 71 9.1.1. Discovery Proxy . . . . . . . . . . . . . . . . . . . 12 72 9.1.2. Multicast Link . . . . . . . . . . . . . . . . . . . 13 73 9.1.3. Discovery Relay . . . . . . . . . . . . . . . . . . . 13 74 9.2. Configuration Files . . . . . . . . . . . . . . . . . . . 14 75 9.3. Discovery Proxy Configuration . . . . . . . . . . . . . . 15 76 9.4. Discovery Relay Configuration . . . . . . . . . . . . . . 15 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 13.2. Informative References . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 The Discovery Proxy for Multicast DNS-Based Service Discovery 88 [I-D.ietf-dnssd-hybrid] is a mechanism for discovering services on a 89 subnetted network through the use of Discovery Proxies, which issue 90 Multicast DNS (mDNS) requests [RFC6762] on various multicast links in 91 the network on behalf of a remote host performing DNS-Based Service 92 Discovery [RFC6763]. 94 In the original Discovery Proxy specification, it is assumed that for 95 every multicast link on which services will be discovered, a host 96 will be present running a full Discovery Proxy. This document 97 introduces a lightweight Discovery Relay which can be used to provide 98 discovery services on a multicast link without requiring a full 99 Discovery Proxy on every multicast link. 101 The Discovery Relay operates by listening for TCP connections from 102 Discovery Proxies. When a Discovery Proxy connects, the connection 103 is authenticated and secured using TLS. The Discovery Proxy can then 104 specify one or more multicast links from which it wishes to receive 105 mDNS traffic. The Discovery Proxy can also send messages to be 106 transmitted on its behalf on one or more of those multicast links. 107 DNS Stateful Operations (DSO) [I-D.ietf-dnsop-session-signal] is used 108 as a framework for conveying interface and IP header information 109 associated with each message. 111 The Discovery Relay functions essentially as a set of one or more 112 remote virtual interfaces for the Discovery proxy, one on each 113 multicast link to which the Discovery Relay is connected. In a 114 complex network, it is possible that more than one Discovery Relay 115 will be connected to the same multicast link; in this case, the 116 Discovery Proxy ideally should only be using one such Relay Proxy per 117 multicast link, since using more than one will generate duplicate 118 traffic. 120 How such duplication is detected and avoided is out of scope for this 121 document: in principle it could be detected using HNCP [RFC7788] or 122 configured using some sort of orchestration software in conjunction 123 with NETCONF [RFC6241] or CPE WAN Management Protocol [TR-069]. 125 2. Terminology 127 The following definitions may be of use: 129 mDNS Agent A host which sends and/or responds to mDNS queries. 131 Discovery Proxy A network service which receives well-formed 132 questions using the DNS protocol, performs multicast DNS queries 133 to answer those questions, and responds with those answers using 134 the DNS protocol. 136 Discovery Relay A network service which relays received mDNS 137 messages to a Discovery Proxy, and can transmit mDNS messages on 138 behalf of that Discovery Proxy. 140 multicast link A maximal set of network connection points, such that 141 any host connected to any connection point in the set may send a 142 packet with a link-local multicast destination address 143 (specifically the mDNS link-local multicast destination address 144 [RFC6762]) that will be received by all hosts connected to all 145 other connection points in the set. Note that it is becoming 146 increasingly common for a multicast link to be smaller than its 147 corresponding unicast link. For example it is becoming common to 148 have multiple Wi-Fi Access Points on a shared Ethernet backbone, 149 where the multiple Wi-Fi Access Points and their shared Ethernet 150 backbone form a single unicast link (a single IPv4 subnet, or 151 single IPv6 prefix) but not a single multicast link. Unicast 152 packets between two hosts on that IPv4 subnet or IPv6 prefix are 153 correctly delivered, but multicast packets are not forwarded 154 between the various Wi-Fi Access Points. Given the slowness of 155 Wi-Fi multicast, the decision to not forward multicast packets 156 between Wi-Fi Access Points is reasonable, and that further 157 supports the need for technologies like Discovery Proxy and 158 Discovery Relay to facilitate discovery on these networks. 160 whitelist A list of one or more IP addresses from which a Discovery 161 Relay may accept connections. 163 silently discard When a message that is not supported or not 164 permitted is received, and the required response to that message 165 is to "silently discard" it, that means that no response is sent 166 by the service that is discarding the message to the service that 167 sent it. The service receiving the message may log the event, and 168 may also count such events: "silently" does not preclude such 169 behavior. 171 3. Protocol Overview 173 This document describes a way for Discovery Proxies to communicate 174 with mDNS agents on remote multicast links to which they are not 175 directly connected, using a Discovery Relay. As such, there are two 176 parts to the protocol: connections between Discovery Proxies and 177 Discovery Relays, and communications between Discovery Relays and 178 mDNS agents. 180 3.1. Connections between Proxies and Relays (overview) 182 Discovery Relays listen for incoming connection requests. 183 Connections between Discovery Proxies and Discovery Relays are 184 established by Discovery Proxies. Connections are authenticated and 185 encrypted using TLS, with both client and server certificates. 186 Connections are long-lived: a Discovery Proxy is expected to send 187 many queries over a single connection, and Discovery Relays will 188 forward all mDNS traffic from subscribed interfaces over the 189 connection. 191 The stream encapsulated in TLS will carry DNS frames as in the DNS 192 TCP protocol [RFC1035] Section 4.2.2. However, all messages will be 193 DSO messages [I-D.ietf-dnsop-session-signal]. There will be three 194 types of such messages: 196 o Control messages from Discovery Proxy to Discovery Relay 198 o mDNS messages from Discovery Relay to Discovery Proxy 200 o mDNS messages from Discovery Proxy to Discovery Relay 202 Subscribe messages from the Discovery Proxy to the Discovery Relay 203 indicate to the Discovery Relay that mDNS messages from one or more 204 specified multicast links are to be relayed to the Discovery Proxy. 206 mDNS messages from a Discovery Proxy to a Discovery Relay cause the 207 Discovery Relay to transmit the mDNS message on one or more multicast 208 links to which the Discovery Relay host is directly attached. 210 mDNS messages from a Discovery Relay to a Discovery Proxy are sent 211 whenever an mDNS message is received on a multicast link to which the 212 Discovery Relay has subscribed. 214 Discovery Relays are responsible for keeping connections alive when 215 no traffic has been sent during a keepalive period (See 216 [I-D.ietf-dnsop-session-signal] Section 4). 218 3.2. mDNS Messages On Multicast Links 220 Discovery Relays listen for mDNS traffic on all configured multicast 221 links that have at least one active subscription from a Discovery 222 Proxy. When an mDNS message is received on a multicast link, it is 223 forwarded on every open Discovery Proxy connection that is subscribed 224 to mDNS traffic on that multicast link. In the event of congestion, 225 where a particular Discovery Proxy connection has no buffer space for 226 an mDNS message that would otherwise be forwarded to it, the mDNS 227 message is not forwarded to it. Normal mDNS retry behavior is used 228 to recover from this sort of packet loss. Discovery Relays are not 229 expected to buffer more than a few mDNS packets. Excess mDNS packets 230 are silently discarded. In reality this is expected to be a 231 nonissue. Particularly on networks like Wi-Fi, multicast packets are 232 transmitted at rates ten or even a hundred times slower than unicast 233 packets. This means that even at peak multicast packets rates, it is 234 likely that a unicast TCP connection will able to carry those packets 235 with ease. 237 Discovery Proxies send mDNS messages they wish to have sent on their 238 behalf on remote multicast link(s) on which the Discovery Proxy has 239 an active subscription. A Discovery Relay will not transmit mDNS 240 packets on any multicast link on which the remote Discovery Proxy 241 does not have an active subscription, since it makes no sense for a 242 Discovery Proxy to ask to have a query sent on its behalf if it's not 243 able to receive the responses to that query. 245 4. Connections between Proxies and Relays (details) 247 When a Discovery Relay starts, it opens a passive TCP listener to 248 receive incoming connection requests from Discovery Proxies. This 249 listener may be bound to one or more source IP addresses, or to the 250 wildcard address, depending on the implementation. When a connection 251 is received, the relay must first validate that it is a connection to 252 an IP address to which connections are allowed. For example, it may 253 be that only connections to ULAs are allowed, or to the IP addresses 254 configured on certain interfaces. If the listener is bound to a 255 specific IP address, this check is unnecessary. 257 The relay must then validate that the source IP address of the 258 connection is on its whitelist. If the connection is not permitted 259 either because of the source address or the destination address, the 260 Discovery Relay responds to the TLS Client Hello message from the 261 Discovery Proxy with a TLS user_canceled alert ([I-D.ietf-tls-tls13] 262 Section 6.1). 264 Otherwise, the Discovery Relay will attempt to complete a TLS 265 handshake with the Discovery Proxy. Discovery Proxies are required 266 to send the post_handshake_auth extension ([I-D.ietf-tls-tls13] 267 Section 4.2.5). If a relay proxy receives a ClientHello message with 268 no post_handshake_auth extension, the Discovery Relay rejects the 269 connection with a certificate_required alert ([I-D.ietf-tls-tls13] 270 Section 6.2). 272 Once the TLS handshake is complete, the Discovery Relay MUST request 273 post-handshake authentication as described in ([I-D.ietf-tls-tls13] 274 Section 4.6.2). If the Discovery Proxy refuses to send a 275 certificate, or the key presented does not match the key associated 276 with the IP address from which the connection originated, or the 277 CertificateVerify does not validate, the connection is dropped with 278 the TLS access_denied alert ([I-D.ietf-tls-tls13] Section 6.2). 280 Once the connection is established and authenticated, it is treated 281 as a DNS TCP connection [RFC1035]. 283 Aliveness of connections between Discovery Proxies and Relays is 284 maintained as described in Section 4 of 285 [I-D.ietf-dnsop-session-signal]. Discovery Proxies must also honor 286 the 'Retry Delay' TLV (section 5 of [I-D.ietf-dnsop-session-signal]) 287 if sent by the Discovery Relay. 289 Discovery Proxies may establish more than one connection to a 290 specific Discovery Relay. This would happen in the case that a TCP 291 connection stalls, and the Discovery Proxy is able to reconnect 292 before the previous connection has timed out. It could also happen 293 as a result of a server restart. It is not likely that two active 294 connections from the same Discovery Proxy would be present at the 295 same time, but it must be possible for additional connections to be 296 established. The Discovery Relay may drop the old connection when 297 the new one has been fully established, including a successful TLS 298 handshake. What it means for two connections to be from the same 299 Discovery Proxy is that the connections both have source addresses 300 that belong to the same proxy, and that they were authenticated using 301 the same client certificate. 303 5. Traffic from Relays to Proxies 305 The mere act of connecting to a Discovery Relay does not result in 306 any mDNS traffic being forwarded. In order to request that mDNS 307 traffic from a particular multicast link be forwarded on a particular 308 connection, the Discovery Proxy must send one or more DSO messages 309 containing mDNS a Link Request TLV (Section 8.1) indicating the 310 multicast link from which traffic is requested. 312 When such a message is received, the Discovery Relay validates that 313 the specified multicast link is available for forwarding, and that 314 forwarding is enabled for that multicast link. For each such message 315 the Discovery Relay validates the multicast link specified and 316 includes in a single response RCODE 0 if the multicast link specified 317 is valid, or RCODE 11 (DSOFAIL) otherwise. For each valid multicast 318 link, it begins forwarding all mDNS traffic from that link to the 319 Discovery Proxy. Delivery is not guaranteed: if there is no buffer 320 space, packets will be dropped. It is expected that regular mDNS 321 retry processing will take care of retransmission of lost packets. 322 The amount of buffer space is implementation dependent, but generally 323 should not be more than the bandwidth delay product of the TCP 324 connection [RFC1323]. The Discovery Relay should use the 325 TCP_NOTSENT_LOWAT mechanism [NOTSENT][PRIO] or equivalent, to avoid 326 building up a backlog of data in excess of the amount necessary to 327 have in flight to fill the bandwidth delay product of the TCP 328 connection. 330 mDNS messages from Relays to Proxies are framed within DSO messages. 331 Each DSO message can contain multiple TLVs, but only a single mDNS 332 message is conveyed per DSO message. Each forwarded mDNS message is 333 contained in an mDNS Message TLV (Section 8.3). The layer two source 334 address of the message, if known, MAY be encoded in a Layer Two 335 Source TLV (Section 8.5). The source IP address and port of the 336 message MUST be encoded in a IP Source (Section 8.6). The multicast 337 link on which the message was received MUST be encoded in a Link 338 Identifier TLV (Section 8.4). The Discovery Proxy MUST silently 339 ignore unrecognized TLVs in mDNS messages, and MUST NOT discard mDNS 340 messages that include unrecognized TLVs. 342 A Discovery Proxy may discontinue listening for mDNS messages on a 343 particular multicast link by sending a DSO message containing an mDNS 344 Link Discontinue TLV (Section 8.2). Subsequent messages from that 345 link that had previously been queued may arrive after listening has 346 been discontinued. The Discovery Proxy should silently ignore such 347 messages. The Discovery Relay MUST discontinue generating such 348 messages as soon as the request is received. The Discovery Relay 349 does not respond to this message other than to discontinue forwarding 350 mDNS messages from the specified links. 352 6. Traffic from Proxies to Relays 354 Like mDNS traffic from relays, each mDNS message sent by a Discovery 355 Proxy to a Discovery Relay is encapsulated in an mDNS Message TLV 356 (Section 8.3) within a DSO message. Each message MUST contain one or 357 more Link Identifier TLVs (Section 8.4). The Discovery Relay will 358 transmit the message to the mDNS port and multicast address on each 359 link specified in the message using the specified IP address family. 361 7. Discovery Proxy Behavior 363 Discovery Proxies treat multicast links for which Discovery Relay 364 service is being used as if they were virtual interfaces; in other 365 words, a Discovery Proxy serving multiple multicast links using 366 multiple Discovery Relays behaves the same as a Discovery Proxy 367 serving multiple multicast links using multiple physical network 368 interfaces. In this section we refer to multicast links served 369 directly by the Discovery Proxy as locally-connected links, and 370 multicast links served through the Discovery Relay as relay-connected 371 links. 373 What this means is that when a Discovery Proxy receives a DNSSD query 374 from a client, it will generate mDNS messages on the relevant 375 multicast link for which it is acting as a proxy. For locally- 376 connected links, those messages will be sent directly. For relay- 377 connected links, the messages will be sent through the Discovery 378 Relay that is being used to serve that multicast link. 380 Responses from devices on locally-connected links are processed 381 normally. Responses from devices on relay-connected links are 382 received by the Discovery Relay, encapsulated, and forwarded to the 383 Discovery Proxy; the discovery proxy then processes these messages 384 using the link-identifying information included in encapsulation. 386 Discovery Proxies do not respond to mDNS queries on relay-connected 387 links. If an mDNS query is received from a Discovery Relay, the 388 Discovery Proxy silently discards it. 390 In principle it could be the case that some device is capable of 391 performing service discovery using mDNS, but not using the DNS 392 protocol. Responding to mDNS queries received from the Discovery 393 Relay could address this use case. However, it is believed that no 394 such devices exist, and therefore the preferred behavior is that all 395 queries be resolved with unicast rather than multicast. 397 8. DSO TLVs 399 This document defines a modest number of new DSO TLVs. 401 8.1. mDNS Link Request 403 The mDNS Link Request TLV conveys a link identifier from which a 404 Discovery Proxy is requesting that a Discovery Relay forward mDNS 405 traffic. The link identifier comes from the provisioning 406 configuration (see Section 9). The SSOP-TYPE for this TLV is TBD-R. 407 The SSOP-LENGTH is always 5. The SSOP-DATA is the 8-bit address 408 family followed by the 32-bit link identifier, in network byte order. 409 An address family value of 1 indicates IPv4 and 2 indicates IPv6, as 410 recorded in the IANA Registry of Address Family Numbers [AdFam]. 412 8.2. mDNS Discontinue 414 This option is used by Discovery Proxies to unsubscribe to mDNS 415 messages on the specified multicast link. More than one may be 416 present in a single DSO message. SSOP-TYPE is TBD-D. SSOP-LENGTH is 417 5. SSOP-DATA is the 8-bit address family followed by the 32-bit link 418 identifier, in network byte order, as described in Section 9. 420 8.3. mDNS Message 422 The mDNS Message TLV is used to encapsulate an mDNS message that is 423 being forwarded from a multicast link to a Discovery Proxy, or is 424 being sent from a Discovery Proxy for transmission on a multicast 425 link. Only the application layer payload of the mDNS message is 426 carried in the DSO mDNS Message TLV, i.e., just the DNS message 427 itself, beginning with the DNS Message ID, not the IP or UDP headers. 428 The SSOP-TYPE for this TLV is TBD-M. SSOP-LENGTH is the length of 429 the encapsulated mDNS message. SSOP-DATA is the content of the 430 encapsulated mDNS message. 432 8.4. Link Identifier 434 This option is used both in DSO messages from Discovery Relays to 435 Discovery Proxies that contain received mDNS messages, and from 436 Discovery Proxies to Discovery Relays that contain mDNS messages to 437 be transmitted on the multicast link. In the former case, it 438 indicates the multicast link on which the message was received; in 439 the latter case, it indicates the multicast link on which the message 440 should be transmitted. SSOP-TYPE is TBD-L. SSOP-LENGTH is 5. SSOP- 441 DATA is the 8-bit address family followed by the 32-bit link 442 identifier, in network byte order, as described in Section 9. 444 8.5. Layer Two Source Address 446 The Layer Two Source Address TLV is used to report the link-layer 447 address from which an mDNS message was received. This TLV is 448 optionally present in DSO messages from Discovery Relays to Discovery 449 Proxies that contain mDNS messages when the source link-layer address 450 is known. The SSOP-TYPE is TBD-2. SSOP-LENGTH is variable, 451 depending on the length of link-layer addresses on the link from 452 which the message was received. SSOP-data is the link-layer address 453 as it was received on the link. 455 8.6. IP Source 457 The IP Source TLV is used to report the IP source address and port 458 from which an mDNS message was received. This TLV is present in DSO 459 messages from Discovery Relays to Discovery Proxies that contain mDNS 460 messages. SSOP-TYPE is TBD-A. SSOP-LENGTH is either 6, for an IPv4 461 address, or 18, for an IPv6 address. SSOP-DATA is the source port, 462 followed by the IP Address, in network byte order. 464 9. Provisioning 466 In order for a Discovery Proxy to use Discovery Relays, it must be 467 configured with sufficient information to identify multicast links on 468 which service discovery is to be supported and connect to discovery 469 relays supporting those multicast links, if it is not running on a 470 host that is directly connected to those multicast links. 472 A Discovery Relay must be configured both with a set of multicast 473 links to which the host on which it is running is connected, on which 474 mDNS relay service is to be provided, and also with a list of one or 475 more Discovery Proxies authorized to use it. 477 On a network supporting DNS Service Discovery using Discovery Relays, 478 more than one different Discovery Relay implementation is likely be 479 present. While it may be that only a single Discovery Proxy is 480 present, that implementation will need to be able to be configured to 481 interoperate with all of the Discovery Relays that are present. 482 Consequently, it is necessary that a standard set of configuration 483 parameters be defined for both Discovery Proxies and Discovery 484 Relays. 486 DNS Service Discovery generally operates within a constrained set of 487 links, not across the entire internet. This section assumes that 488 what will be configured will be a limited set of links operated by a 489 single entity or small set of cooperating entities, among which 490 services present on each link should be available to users on that 491 link and every other link. This could be, for example, a home 492 network, a small office network, or even a network covering an entire 493 building or small set of buildings. The set of Discovery Proxies and 494 Discovery Relays within such a network will be referred to in this 495 section as a 'Discovery Domain'. 497 Depending on the context, several different candidates for 498 configuration of Discovery Proxies and Discovery relays may be 499 applicable. The simplest such mechanism is a configuration file, but 500 regardless of provisioning mechanism, certain configuration 501 information needs to be communicated to the devices, as outlined 502 below. 504 9.1. Provisioned Objects 506 Three types of objects must be described in order for Discovery 507 Proxies and Discovery Relays to be provisioned: Discovery Proxies, 508 Multicast Links, and Discovery Relays. "Human-readable" below means 509 actual words or proper names that will make sense to an untrained 510 human being. "Machine-readable" means a name that will be used by 511 machines to identify the entity to which the name refers. Each 512 entity must have a machine-readable name and may have a human- 513 readable name. Every name must be unique: no two entities can have 514 the same human-readable name nor machine-readable name. 516 9.1.1. Discovery Proxy 518 The description of a Discovery Proxy consists of: 520 name a machine-readable name used to reference this discovery proxy 521 in provisioning. 523 hr-name an optional human-readable name which can appear in 524 provisioning, monitoring and debugging systems. Must be unique 525 within a Discovery Domain. 527 public-key a public key that identifies the Discovery Proxy. This 528 key can be shared across services on the Discovery Proxy Host. 529 The public key is used both to uniquely identify the Discovery 530 Proxy and to authenticate connections from it. 532 private-key the private key corresponding to the public key. 534 source-ip-addresses a list of IP addresses that may be used by the 535 Discovery Proxy when connecting to Discovery Relays. These 536 addresses should be addresses that are configured on the Discovery 537 Proxy Host. They should not be temporary addresses. All such 538 addresses must be reachable within the Discovery Domain. 540 public-ip-addresses a list of IP addresses that may be used to 541 submit DNS queries to the Discovery Proxy. This is not used for 542 interoperation with Discovery Relays, but is mentioned here for 543 completeness: this list of addresses may differ from the 'source- 544 ip-addresses' list. If any of these addresses are reachable from 545 outside of the Discovery Domain, services in that domain will be 546 discoverable outside of the domain. 548 multicast links a list of multicast links on which this Discovery 549 Proxy is expected to provide service 551 The private key should never be distributed to other hosts; all of 552 the other information describing a Discovery Proxy can be safely 553 shared with Discovery Relays. 555 9.1.2. Multicast Link 557 The description of a multicast link consists of: 559 link-identifier An 32-bit identifier that uniquely identifies that 560 link within the Discovery Domain. Each link MUST have exactly one 561 such identifier. Link Identifiers do not have any special 562 semantics, and are not intended to be human-readable. 564 ldh-name A fully-qualified domain name for the multicast link that 565 is used to form an LDH domain name as described in 566 [I-D.ietf-dnssd-hybrid], section 5.3. This name is used to 567 identify the link during provisioning, and must be present. 569 hr-name A human-readable user-friendly fully-qualified domain name 570 for the multicast link. This name MUST be unique within the 571 Discovery Domain. Each multicast link MUST have exactly one such 572 name. 574 The 'ldh-name' and 'hr-name' names can be used to form the LDH and 575 human-readable domain names as described in [I-D.ietf-dnssd-hybrid], 576 section 5.3. 578 9.1.3. Discovery Relay 580 The description of a Discovery Relay consists of: 582 name a required machine-readable identifier used to reference the 583 relay 585 hr-name an optional human-readable name which can appear in 586 provisioning, monitoring and debugging systems. Must be unique 587 within a Discovery Domain. 589 public-key a public key that identifies the Discovery Relay. This 590 key can be shared across services on the Discovery Relay Host. 591 Indeed, if a Discovery Proxy and Discovery Relay are running on 592 the same host, the same key may be used for both. The public key 593 uniquely identifies the Discovery Relay and is used by the 594 Discovery Proxy to verify that it is talking to the intended 595 Discovery Relay after a TLS connection has been established. 597 private-key the private key corresponding to the public key. 599 connect-tuples a list of IP address/port tuples that may be used to 600 connect to the Discovery Relay. The relay may be configured to 601 listen on all addresses on a single port, but this is not 602 required, so the port as well as the address must be specified. 604 multicast links a list of multicast links to which this relay is 605 physically connected. 607 The private key should never be distributed to other hosts; all of 608 the other information describing a Discovery Relay can be safely 609 shared with Discovery Proxies. 611 9.2. Configuration Files 613 For this discussion, we assume the simplest possible means of 614 configuring Discovery Proxies and Discovery Relays: the configuration 615 file. Any environment where changes will happen on a regular basis 616 will either require some automatic means of generating these 617 configuration files as the network topology changes, or will need to 618 use a more automatic method for configuration, such as HNCP. 620 There are many different ways to organize configuration files. This 621 discussion assumes that multicast links, relays and proxies will be 622 specified as objects, as described above, perhaps in a master file, 623 and then the specific configuration of each proxy or relay will 624 reference the set of objects in the master file, referencing objects 625 by name. This approach is not required, but is simply shown as an 626 example. In addition, the private keys for each relay and proxy must 627 appear only in that relay or proxy's configuration file. 629 The master file contains a list of Discovery Relays, Discovery 630 Proxies and Multicast Links. Each object has a name and all the 631 other data associated with it. We do not formally specify the format 632 of the file, but it might look something like this: 634 Relay upstairs 635 public-key xxx 636 connect-tuple 192.0.2.1 1917 637 connect-tuple fd00::1 1917 638 link upstairs-wifi 639 link upstairs-wired 640 Relay downstairs 641 public-key xxx 642 connect-tuple 192.51.100.1 2088 643 connect-tuple fd00::2 2088 644 link downstairs-wifi 645 link downstairs-wired 646 Proxy main 647 public-key xxx 648 address 203.1.113.1 649 Link upstairs-wifi 650 id 1 651 name "Upstairs Wifi" 652 Link upstairs-wired 653 id 2 654 hr-name "Upstairs Wired" 655 Link downstairs-wifi 656 id 3 657 name "Downstairs Wifi" 658 Link downstairs-wired 659 id 4 660 hr-name "Downstairs Wired" 662 9.3. Discovery Proxy Configuration 664 The Discovery Proxy configuration contains enough information to 665 identify which Discovery Proxy is being configured, enumerate the 666 list of multicast links it is intended to serve, and provide keying 667 information it can use to authenticate to Discovery Relays. It may 668 also contain custom information about the port and/or IP address(es) 669 on which it will respond to DNS queries. 671 An example configuration, following the convention used in this 672 section, might look something like this: 674 Proxy 675 [placeholder, to be completed later] 677 9.4. Discovery Relay Configuration 678 10. Security Considerations 680 11. IANA Considerations 682 The IANA is kindly requested to update the DSO Type Codes Registry 683 [I-D.ietf-dnsop-session-signal] by allocating codes for each of the 684 TBD type codes listed in the following table, and by updating this 685 document, here and in Section 8. Each type code should list this 686 document as its reference document. 688 +--------+----------+--------------------------+ 689 | Opcode | Status | Name | 690 +--------+----------+--------------------------+ 691 | TBD-R | Standard | mDNS Link Request | 692 | TBD-D | Standard | mDNS Discontinue | 693 | TBD-M | Standard | mDNS Messsage | 694 | TBD-2 | Standard | Layer Two Source Address | 695 | TBD-A | Standard | IP Source | 696 | TBD-L | Standard | Link Identifier | 697 +--------+----------+--------------------------+ 699 DSO Type Codes to be allocated 701 12. Acknowledgments 702 13. References 704 13.1. Normative References 706 [I-D.ietf-dnsop-session-signal] 707 Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 708 Mankin, A., and T. Pusateri, "DNS Stateful Operations", 709 draft-ietf-dnsop-session-signal-04 (work in progress), 710 September 2017. 712 [I-D.ietf-dnssd-hybrid] 713 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 714 Service Discovery", draft-ietf-dnssd-hybrid-07 (work in 715 progress), September 2017. 717 [I-D.ietf-tls-tls13] 718 Rescorla, E., "The Transport Layer Security (TLS) Protocol 719 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 720 July 2017. 722 [RFC1035] Mockapetris, P., "Domain names - implementation and 723 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 724 November 1987, . 726 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 727 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 728 1992, . 730 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 731 and A. Bierman, Ed., "Network Configuration Protocol 732 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 733 . 735 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 736 DOI 10.17487/RFC6762, February 2013, 737 . 739 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 740 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 741 . 743 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 744 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 745 2016, . 747 13.2. Informative References 749 [AdFam] "IANA Address Family Numbers Registry", 750 . 753 [NOTSENT] "TCP_NOTSENT_LOWAT socket option", July 2013, 754 . 756 [PRIO] "Prioritization Only Works When There's Pending Data to 757 Prioritize", January 2014, . 761 [TR-069] Broadband Forum, "CPE WAN Management Protocol", November 762 2013, . 765 Authors' Addresses 767 Stuart Cheshire 768 Apple Inc. 769 1 Infinite Loop 770 Cupertino, California 95014 771 USA 773 Phone: +1 408 974 3207 774 Email: cheshire@apple.com 776 Ted Lemon 777 Barefoot Consulting 778 Brattleboro, Vermont 05301 779 United States of America 781 Email: mellon@fugue.com