idnits 2.17.1 draft-sctl-dnssd-mdns-relay-03.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 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 an IP So...' RFC 2119 keyword, line 337: '...sage was received MUST be encoded in a...' RFC 2119 keyword, line 338: '...3). The Discovery Proxy MUST silently...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 538 has weird spacing: '... name a mac...' == Line 541 has weird spacing: '...hr-name an op...' == Line 545 has weird spacing: '...lic-key a pub...' == Line 550 has weird spacing: '...ate-key the p...' == Line 552 has weird spacing: '...dresses a lis...' == (8 more instances...) -- The document date (March 5, 2018) is 2234 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-06 == 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-26 ** Downref: Normative reference to an Informational draft: draft-sctl-discovery-broker (ref. 'I-D.sctl-discovery-broker') ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) Summary: 3 errors (**), 0 flaws (~~), 12 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: September 6, 2018 Nibbhaya Consulting 6 March 5, 2018 8 Multicast DNS Discovery Relay 9 draft-sctl-dnssd-mdns-relay-03 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 September 6, 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 (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 Link Discontinue . . . . . . . . . . . . . . . . . . 10 65 8.3. Link Identifier . . . . . . . . . . . . . . . . . . . . . 10 66 8.4. mDNS Message . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 13 72 9.1.2. Multicast Link . . . . . . . . . . . . . . . . . . . 13 73 9.1.3. Discovery Relay . . . . . . . . . . . . . . . . . . . 14 74 9.2. Configuration Files . . . . . . . . . . . . . . . . . . . 15 75 9.3. Discovery Proxy Configuration . . . . . . . . . . . . . . 16 76 9.4. Discovery Relay Configuration . . . . . . . . . . . . . . 17 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 82 13.2. Informative References . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 each containing a single mDNS Link Request TLV (Section 8.1) 310 indicating the 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.4). 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 an IP Source TLV (Section 8.6). The 337 multicast link on which the message was received MUST be encoded in a 338 Link Identifier TLV (Section 8.3). 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 discard 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.4) within a DSO message. Each message MUST contain one or 357 more Link Identifier TLVs (Section 8.3). 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 the 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 SSOP-LENGTH is always 5. SSOP-DATA is the 8-bit address family 408 followed by the 32-bit link identifier, in network byte order, as 409 described in Section 9. An address family value of 1 indicates IPv4 410 and 2 indicates IPv6, as recorded in the IANA Registry of Address 411 Family Numbers [AdFam]. 413 The mDNS Link Request TLV can only be used as a primary TLV, and 414 requires an acknowledgement. 416 8.2. mDNS Link Discontinue 418 The mDNS Link Discontinue TLV is used by Discovery Proxies to 419 unsubscribe to mDNS messages on the specified multicast link. More 420 than one may be present in a single DSO message. SSOP-TYPE is TBD-D. 421 SSOP-LENGTH is always 5. SSOP-DATA is the 8-bit address family 422 followed by the 32-bit link identifier, in network byte order, as 423 described in Section 9. 425 The mDNS Link Discontinue TLV can only be used as a primary TLV, and 426 is not acknowledged. 428 8.3. Link Identifier 430 This option is used both in DSO messages from Discovery Relays to 431 Discovery Proxies that contain received mDNS messages, and from 432 Discovery Proxies to Discovery Relays that contain mDNS messages to 433 be transmitted on the multicast link. In the former case, it 434 indicates the multicast link on which the message was received; in 435 the latter case, it indicates the multicast link on which the message 436 should be transmitted. SSOP-TYPE is TBD-L. SSOP-LENGTH is always 5. 437 SSOP-DATA is the 8-bit address family followed by the 32-bit link 438 identifier, in network byte order, as described in Section 9. 440 The Link Identifier TLV can only be used as an additional TLV. 442 8.4. mDNS Message 444 The mDNS Message TLV is used to encapsulate an mDNS message that is 445 being forwarded from a multicast link to a Discovery Proxy, or is 446 being sent from a Discovery Proxy for transmission on a multicast 447 link. Only the application layer payload of the mDNS message is 448 carried in the DSO mDNS Message TLV, i.e., just the DNS message 449 itself, beginning with the DNS Message ID, not the IP or UDP headers. 450 The SSOP-TYPE for this TLV is TBD-M. SSOP-LENGTH is the length of 451 the encapsulated mDNS message. SSOP-DATA is the content of the 452 encapsulated mDNS message. 454 The mDNS Message TLV can only be used as a primary TLV, and is not 455 acknowledged. 457 8.5. Layer Two Source Address 459 The Layer Two Source Address TLV is used to report the link-layer 460 address from which an mDNS message was received. This TLV is 461 optionally present in DSO messages from Discovery Relays to Discovery 462 Proxies that contain mDNS messages when the source link-layer address 463 is known. The SSOP-TYPE is TBD-2. SSOP-LENGTH is variable, 464 depending on the length of link-layer addresses on the link from 465 which the message was received. SSOP-data is the link-layer address 466 as it was received on the link. 468 The Layer Two Source Address TLV can only be used as an additional 469 TLV. 471 8.6. IP Source 473 The IP Source TLV is used to report the IP source address and port 474 from which an mDNS message was received. This TLV is present in DSO 475 messages from Discovery Relays to Discovery Proxies that contain mDNS 476 messages. SSOP-TYPE is TBD-A. SSOP-LENGTH is either 6, for an IPv4 477 address, or 18, for an IPv6 address. SSOP-DATA is the source port, 478 followed by the IP Address, in network byte order. 480 The IP Source TLV can only be used as an additional TLV. 482 9. Provisioning 484 In order for a Discovery Proxy to use Discovery Relays, it must be 485 configured with sufficient information to identify multicast links on 486 which service discovery is to be supported and connect to discovery 487 relays supporting those multicast links, if it is not running on a 488 host that is directly connected to those multicast links. 490 A Discovery Relay must be configured both with a set of multicast 491 links to which the host on which it is running is connected, on which 492 mDNS relay service is to be provided, and also with a list of one or 493 more Discovery Proxies authorized to use it. 495 On a network supporting DNS Service Discovery using Discovery Relays, 496 more than one different Discovery Relay implementation is likely be 497 present. While it may be that only a single Discovery Proxy is 498 present, that implementation will need to be able to be configured to 499 interoperate with all of the Discovery Relays that are present. 500 Consequently, it is necessary that a standard set of configuration 501 parameters be defined for both Discovery Proxies and Discovery 502 Relays. 504 DNS Service Discovery generally operates within a constrained set of 505 links, not across the entire internet. This section assumes that 506 what will be configured will be a limited set of links operated by a 507 single entity or small set of cooperating entities, among which 508 services present on each link should be available to users on that 509 link and every other link. This could be, for example, a home 510 network, a small office network, or even a network covering an entire 511 building or small set of buildings. The set of Discovery Proxies and 512 Discovery Relays within such a network will be referred to in this 513 section as a 'Discovery Domain'. 515 Depending on the context, several different candidates for 516 configuration of Discovery Proxies and Discovery relays may be 517 applicable. The simplest such mechanism is a configuration file, but 518 regardless of provisioning mechanism, certain configuration 519 information needs to be communicated to the devices, as outlined 520 below. 522 9.1. Provisioned Objects 524 Three types of objects must be described in order for Discovery 525 Proxies and Discovery Relays to be provisioned: Discovery Proxies, 526 Multicast Links, and Discovery Relays. "Human-readable" below means 527 actual words or proper names that will make sense to an untrained 528 human being. "Machine-readable" means a name that will be used by 529 machines to identify the entity to which the name refers. Each 530 entity must have a machine-readable name and may have a human- 531 readable name. Every name must be unique: no two entities can have 532 the same human-readable name nor machine-readable name. 534 9.1.1. Discovery Proxy 536 The description of a Discovery Proxy consists of: 538 name a machine-readable name used to reference this discovery proxy 539 in provisioning. 541 hr-name an optional human-readable name which can appear in 542 provisioning, monitoring and debugging systems. Must be unique 543 within a Discovery Domain. 545 public-key a public key that identifies the Discovery Proxy. This 546 key can be shared across services on the Discovery Proxy Host. 547 The public key is used both to uniquely identify the Discovery 548 Proxy and to authenticate connections from it. 550 private-key the private key corresponding to the public key. 552 source-ip-addresses a list of IP addresses that may be used by the 553 Discovery Proxy when connecting to Discovery Relays. These 554 addresses should be addresses that are configured on the Discovery 555 Proxy Host. They should not be temporary addresses. All such 556 addresses must be reachable within the Discovery Domain. 558 public-ip-addresses a list of IP addresses that may be used to 559 submit DNS queries to the Discovery Proxy. This is not used for 560 interoperation with Discovery Relays, but is mentioned here for 561 completeness: this list of addresses may differ from the 'source- 562 ip-addresses' list. If any of these addresses are reachable from 563 outside of the Discovery Domain, services in that domain will be 564 discoverable outside of the domain. 566 multicast links a list of multicast links on which this Discovery 567 Proxy is expected to provide service 569 The private key should never be distributed to other hosts; all of 570 the other information describing a Discovery Proxy can be safely 571 shared with Discovery Relays. 573 9.1.2. Multicast Link 575 The description of a multicast link consists of: 577 link-identifier An 32-bit identifier that uniquely identifies that 578 link within the Discovery Domain. Each link MUST have exactly one 579 such identifier. Link Identifiers do not have any special 580 semantics, and are not intended to be human-readable. 582 ldh-name A fully-qualified domain name for the multicast link that 583 is used to form an LDH domain name as described in 584 [I-D.ietf-dnssd-hybrid], section 5.3. This name is used to 585 identify the link during provisioning, and must be present. 587 hr-name A human-readable user-friendly fully-qualified domain name 588 for the multicast link. This name MUST be unique within the 589 Discovery Domain. Each multicast link MUST have exactly one such 590 name. The hr-name MAY be the same as the ldh-name. (The hr-name 591 is allowed to contain spaces, punctuation and rich text, but it is 592 not required to do so.) 594 The ldh-name and hr-name can be used to form the LDH and human- 595 readable domain names as described in [I-D.ietf-dnssd-hybrid], 596 section 5.3. 598 Note that the ldh-name and hr-name can be used in two different ways. 600 On a small home network with little or no human administrative 601 configuration, link names may be directly visible to the user. For 602 example, a search in 'home.arpa' on a small home network may discover 603 services on both ethernet.home.arpa and wi-fi.home.arpa. In the case 604 of a home user who has one Ethernet-connected printer and one Wi-Fi- 605 connected printer, discovering that they have one printer on 606 ethernet.home.arpa and another on wi-fi.home.arpa is understandable 607 and meaningful. 609 On a large corporate network with hundreds of Wi-Fi Access Points, 610 the individual link names of the hundreds of multicast links are less 611 likely to be useful to end users. In these cases, Discovery Broker 612 functionality [I-D.sctl-discovery-broker] is used to translate the 613 many link names to something more meaningful to users. For example, 614 in a building with 50 Wi-Fi Access Points, each with their own link 615 names, services on all the different physical links may be presented 616 to the user as appearing in 'headquarters.example.com'. In this 617 case, the individual link names can be thought of similar to MAC 618 addresses or IPv6 addresses. They are used internally by the 619 software as unique identifiers, but generally are not exposed to end 620 users. 622 9.1.3. Discovery Relay 624 The description of a Discovery Relay consists of: 626 name a required machine-readable identifier used to reference the 627 relay 629 hr-name an optional human-readable name which can appear in 630 provisioning, monitoring and debugging systems. Must be unique 631 within a Discovery Domain. 633 public-key a public key that identifies the Discovery Relay. This 634 key can be shared across services on the Discovery Relay Host. 635 Indeed, if a Discovery Proxy and Discovery Relay are running on 636 the same host, the same key may be used for both. The public key 637 uniquely identifies the Discovery Relay and is used by the 638 Discovery Proxy to verify that it is talking to the intended 639 Discovery Relay after a TLS connection has been established. 641 private-key the private key corresponding to the public key. 643 connect-tuples a list of IP address/port tuples that may be used to 644 connect to the Discovery Relay. The relay may be configured to 645 listen on all addresses on a single port, but this is not 646 required, so the port as well as the address must be specified. 648 multicast links a list of multicast links to which this relay is 649 physically connected. 651 The private key should never be distributed to other hosts; all of 652 the other information describing a Discovery Relay can be safely 653 shared with Discovery Proxies. 655 9.2. Configuration Files 657 For this discussion, we assume the simplest possible means of 658 configuring Discovery Proxies and Discovery Relays: the configuration 659 file. Any environment where changes will happen on a regular basis 660 will either require some automatic means of generating these 661 configuration files as the network topology changes, or will need to 662 use a more automatic method for configuration, such as HNCP. 664 There are many different ways to organize configuration files. This 665 discussion assumes that multicast links, relays and proxies will be 666 specified as objects, as described above, perhaps in a master file, 667 and then the specific configuration of each proxy or relay will 668 reference the set of objects in the master file, referencing objects 669 by name. This approach is not required, but is simply shown as an 670 example. In addition, the private keys for each relay and proxy must 671 appear only in that relay or proxy's configuration file. 673 The master file contains a list of Discovery Relays, Discovery 674 Proxies and Multicast Links. Each object has a name and all the 675 other data associated with it. We do not formally specify the format 676 of the file, but it might look something like this: 678 Relay upstairs 679 public-key xxx 680 connect-tuple 192.0.2.1 1917 681 connect-tuple fd00::1 1917 682 link upstairs-wifi 683 link upstairs-wired 684 Relay downstairs 685 public-key yyy 686 connect-tuple 192.51.100.1 2088 687 connect-tuple fd00::2 2088 688 link downstairs-wifi 689 link downstairs-wired 690 Proxy main 691 public-key zzz 692 address 203.1.113.1 693 Link upstairs-wifi 694 id 1 695 name "Upstairs Wifi" 696 Link upstairs-wired 697 id 2 698 hr-name "Upstairs Wired" 699 Link downstairs-wifi 700 id 3 701 name "Downstairs Wifi" 702 Link downstairs-wired 703 id 4 704 hr-name "Downstairs Wired" 706 9.3. Discovery Proxy Configuration 708 The Discovery Proxy configuration contains enough information to 709 identify which Discovery Proxy is being configured, enumerate the 710 list of multicast links it is intended to serve, and provide keying 711 information it can use to authenticate to Discovery Relays. It may 712 also contain custom information about the port and/or IP address(es) 713 on which it will respond to DNS queries. 715 An example configuration, following the convention used in this 716 section, might look something like this: 718 Proxy main 719 private-key zzz 720 subscribe upstairs-wifi 721 subscribe downstairs-wifi 722 subscribe upstairs-wired 723 subscribe downstairs-wired 725 When combined with the master file, this configuration is sufficient 726 for the Discovery Proxy to identify and connect to the relay proxies 727 that serve the links it is configured to support. 729 9.4. Discovery Relay Configuration 731 The discovery relay configuration just needs to tell the discovery 732 relay what name to use to find its configuration in the master file, 733 and what the private key is corresponding to its public key in the 734 master file. For example: 736 Relay Downstairs 737 private-key yyy 739 10. Security Considerations 741 11. IANA Considerations 743 The IANA is kindly requested to update the DSO Type Codes Registry 744 [I-D.ietf-dnsop-session-signal] by allocating codes for each of the 745 TBD type codes listed in the following table, and by updating this 746 document, here and in Section 8. Each type code should list this 747 document as its reference document. 749 +--------+----------+--------------------------+ 750 | Opcode | Status | Name | 751 +--------+----------+--------------------------+ 752 | TBD-R | Standard | mDNS Link Request | 753 | TBD-D | Standard | mDNS Discontinue | 754 | TBD-L | Standard | Link Identifier | 755 | TBD-M | Standard | mDNS Messsage | 756 | TBD-2 | Standard | Layer Two Source Address | 757 | TBD-A | Standard | IP Source | 758 +--------+----------+--------------------------+ 760 DSO Type Codes to be allocated 762 12. Acknowledgments 763 13. References 765 13.1. Normative References 767 [I-D.ietf-dnsop-session-signal] 768 Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 769 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 770 draft-ietf-dnsop-session-signal-06 (work in progress), 771 March 2018. 773 [I-D.ietf-dnssd-hybrid] 774 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 775 Service Discovery", draft-ietf-dnssd-hybrid-07 (work in 776 progress), September 2017. 778 [I-D.ietf-tls-tls13] 779 Rescorla, E., "The Transport Layer Security (TLS) Protocol 780 Version 1.3", draft-ietf-tls-tls13-26 (work in progress), 781 March 2018. 783 [I-D.sctl-discovery-broker] 784 Cheshire, S. and T. Lemon, "Service Discovery Broker", 785 draft-sctl-discovery-broker-00 (work in progress), July 786 2017. 788 [RFC1035] Mockapetris, P., "Domain names - implementation and 789 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 790 November 1987, . 792 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 793 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 794 1992, . 796 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 797 and A. Bierman, Ed., "Network Configuration Protocol 798 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 799 . 801 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 802 DOI 10.17487/RFC6762, February 2013, 803 . 805 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 806 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 807 . 809 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 810 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 811 2016, . 813 13.2. Informative References 815 [AdFam] "IANA Address Family Numbers Registry", 816 . 819 [NOTSENT] "TCP_NOTSENT_LOWAT socket option", July 2013, 820 . 822 [PRIO] "Prioritization Only Works When There's Pending Data to 823 Prioritize", January 2014, . 827 [TR-069] Broadband Forum, "CPE WAN Management Protocol", November 828 2013, . 831 Authors' Addresses 833 Stuart Cheshire 834 Apple Inc. 835 1 Infinite Loop 836 Cupertino, California 95014 837 USA 839 Phone: +1 408 974 3207 840 Email: cheshire@apple.com 842 Ted Lemon 843 Nibbhaya Consulting 844 P.O. Box 958 845 Brattleboro, Vermont 05301 846 United States of America 848 Email: mellon@fugue.com