idnits 2.17.1 draft-sctl-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 : ---------------------------------------------------------------------------- ** 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 775: '...lete, the Discovery Relay MUST request...' RFC 2119 keyword, line 834: '... MAY be encoded in a Layer 2 Source ...' RFC 2119 keyword, line 835: '...s of the message MUST be encoded in a ...' RFC 2119 keyword, line 836: '...t of the message MUST be encoded in an...' RFC 2119 keyword, line 838: '... received MUST be encoded in a Link ...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2487 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) == Unused Reference: 'RFC6763' is defined on line 1050, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-dnsop-session-signal-02 == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-06 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: January 4, 2018 Nominum, Inc. 6 July 3, 2017 8 Multicast DNS Discovery Relay 9 draft-sctl-dnssd-mdns-relay-00 11 Abstract 13 This document extends the Discovery Proxy for Multicast DNS-Based 14 Service Discovery specification. It describes a lightweight relay 15 mechanism, a Discovery Relay, which allows Discovery Proxies to 16 provide service on links to which the hosts on which they are running 17 are not directly 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 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 January 4, 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 (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 Discovery and Discovery Relays . . . 5 57 3.2. mDNS Messages On Links . . . . . . . . . . . . . . . . . 6 58 4. Orchestration . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Orchestration System Functional Overview . . . . . . . . 7 60 4.2. Orchestration Primitives . . . . . . . . . . . . . . . . 7 61 4.2.1. Link Present . . . . . . . . . . . . . . . . . . . . 7 62 4.2.2. Link Remove . . . . . . . . . . . . . . . . . . . . . 8 63 4.2.3. Discovery Proxy Available . . . . . . . . . . . . . . 8 64 4.2.4. Discovery Proxy Resigning . . . . . . . . . . . . . . 8 65 4.2.5. Discovery Relay Available . . . . . . . . . . . . . . 9 66 4.2.6. Discovery Relay Resigning . . . . . . . . . . . . . . 9 67 4.3. Orchestration System Behavior . . . . . . . . . . . . . . 10 68 4.3.1. Link Present . . . . . . . . . . . . . . . . . . . . 10 69 4.3.2. Link Remove . . . . . . . . . . . . . . . . . . . . . 10 70 4.3.3. Discovery Proxy Available . . . . . . . . . . . . . . 10 71 4.3.4. Discovery Proxy Resigning . . . . . . . . . . . . . . 11 72 4.3.5. Discovery Relay Available . . . . . . . . . . . . . . 11 73 4.3.6. Discovery Relay Resigning . . . . . . . . . . . . . . 12 74 4.3.7. Node Available . . . . . . . . . . . . . . . . . . . 12 75 4.3.8. Node Resigning . . . . . . . . . . . . . . . . . . . 12 76 4.4. Discovery Proxy Performer Behavior . . . . . . . . . . . 12 77 4.4.1. Link Present . . . . . . . . . . . . . . . . . . . . 13 78 4.4.2. Link Removed . . . . . . . . . . . . . . . . . . . . 13 79 4.4.3. Discovery Proxy Available . . . . . . . . . . . . . . 13 80 4.4.4. Discovery Proxy Resigning . . . . . . . . . . . . . . 14 81 4.4.5. Discovery Relay Available . . . . . . . . . . . . . . 14 82 4.4.6. Discovery Relay Resigning . . . . . . . . . . . . . . 15 83 4.5. Discovery Relay Performer Behavior . . . . . . . . . . . 15 84 4.5.1. Link Present . . . . . . . . . . . . . . . . . . . . 15 85 4.5.2. Link Removed . . . . . . . . . . . . . . . . . . . . 15 86 4.5.3. Discovery Proxy Available . . . . . . . . . . . . . . 15 87 4.5.4. Discovery Proxy Resigning . . . . . . . . . . . . . . 16 88 4.5.5. Discovery Relay Available . . . . . . . . . . . . . . 16 89 4.5.6. Discovery Relay Resigning . . . . . . . . . . . . . . 16 90 5. Connections between Discovery Proxies and Discovery Relays . 16 91 6. Traffic from Relays to Proxies . . . . . . . . . . . . . . . 18 92 7. Traffic from Proxies to Relays . . . . . . . . . . . . . . . 19 93 8. Discovery Proxy Behavior . . . . . . . . . . . . . . . . . . 19 94 9. Session Signaling TLVs . . . . . . . . . . . . . . . . . . . 19 95 9.1. MDNS Link Request . . . . . . . . . . . . . . . . . . . . 19 96 9.2. MDNS Link Invalid . . . . . . . . . . . . . . . . . . . . 19 97 9.3. MDNS Link Subscribed . . . . . . . . . . . . . . . . . . 20 98 9.4. MDNS Message . . . . . . . . . . . . . . . . . . . . . . 20 99 9.5. Layer 2 Source Address . . . . . . . . . . . . . . . . . 20 100 9.6. IP Source Address . . . . . . . . . . . . . . . . . . . . 20 101 9.7. IP Source Port . . . . . . . . . . . . . . . . . . . . . 21 102 9.8. Link Identifier . . . . . . . . . . . . . . . . . . . . . 21 103 9.9. MDNS Discontinue . . . . . . . . . . . . . . . . . . . . 21 104 9.10. IP Address Family . . . . . . . . . . . . . . . . . . . . 21 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 107 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 108 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 109 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 110 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 111 14.2. Informative References . . . . . . . . . . . . . . . . . 23 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 114 1. Introduction 116 The Discovery Proxy for Multicast DNS-Based Service Discovery 117 [I-D.ietf-dnssd-hybrid] specification defines a mechanism for 118 discovering services on a subnetted network using Multicast DNS 119 (mDNS) [RFC6762], through the use of Discovery Proxies, which issue 120 mDNS requests on various links in the network on behalf of a host 121 attempting service discovery. 123 In the original Discovery Proxy specification, it is assumed that for 124 every link on which services will be discovered, a host will be 125 present running a full Discovery Proxy. This document introduces a 126 lightweight Discovery Relay which can be used to provide discovery 127 services on a link without requiring a full Discovery Proxy on every 128 link. 130 The Discovery Relay operates by listening for TCP connections from 131 Discovery Proxies. When a Discovery Proxy conneects, the connection 132 is authenticated and secured using TLS. The Discovery Proxy can then 133 send messages that will be relayed to specified links. The Discovery 134 Proxy may also specify one or more links from which it wishes to 135 receive mDNS traffic. DNS Session Signaling 136 [I-D.ietf-dnsop-session-signal] is used as a framework for conveying 137 interface and IP header information associated with each message. 139 The Discovery Relay functions essentially as a set of one or more 140 virtual interfaces for the Discovery proxy, one on each link to which 141 the Discovery Relay is connected. In a complex network, it is 142 possible that more than one Discovery Relay will be connected to the 143 same link; in this case, the Discovery Proxy ideally should only be 144 using one such Relay Proxy per link, since using more than one will 145 generate duplicate traffic. 147 How such duplication is detected and avoided is out of scope for this 148 document: in principle it could be detected using HNCP [RFC7788] or 149 configured using some sort of orchestration software in conjunction 150 with NETCONF [RFC6241] or CPE WAN Management Protocol [TR-069]. 152 2. Terminology 154 The following definitions may be of use: 156 mDNS Agent A host which sends and/or responds to mDNS queries. 158 Discovery Proxy A network service which receives well-formed 159 questions using the DNS protocol, performs multicast DNS queries 160 to answer those questions, and responds with those answers using 161 the DNS protocol. 163 Discovery Relay A network service which sends mDNS messages on 164 behalf of a Discovery Proxy and relays mDNS messages to a 165 Discovery Relay. 167 link A maximal set of network connection points such that any host 168 connected to any connection point may send a packet to a host 169 connected to any other connection point without the help of a 170 layer 3 router. 172 whitelist A list of one or more IP addresses from which a Discovery 173 Relay may accept connections. 175 silently discard When a message that is not supported or not 176 permitted is received, and the required response to that message 177 is to "silently discard" it, that means that no response is sent 178 by the service that is discarding the message to the service that 179 sent it. The service receiving the message may log the event, and 180 may also count such events: "silently" does not preclude such 181 behavior. 183 Director A central or coordinated controlling function in an 184 orchestrated network of Discovery Proxies and Discovery Relays 185 (Section 4.1). 187 Performer The interface through which the Director directs the 188 behavior of Discovery Proxies and Discovery Relays (Section 4.1). 190 3. Protocol Overview 192 This document describes a way for Discovery Proxies to communicate 193 with mDNS agents on networks to which they are not directly connected 194 using a Discovery Relay. As such, there are two parts to the 195 protocol: connections between Discovery Proxies and Discovery Relays, 196 and communications between Discovery Relays and mDNS agents. 198 3.1. Connections between Discovery and Discovery Relays 200 Discovery Relays listen for connections. Connections between 201 Discovery Proxies and Discovery Relays are established by Discovery 202 Proxies. Connections are authenticated and encrypted using TLS, with 203 both client and server certificates. Connections are long-lived: a 204 Discovery Proxy is expected to send many queries over the same 205 connection, and Discovery Relays will forward all mDNS traffic from 206 subscribed 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 DNS Session Signaling messages [I-D.ietf-dnsop-session-signal]. 211 There will be three types of such messages: 213 o Subscribe messages from Discovery Proxy to Discovery Relay 215 o mDNS messages from Discovery Proxy to Discovery Relay 217 o mDNS messages from Discovery Relay to Discovery Proxy 219 Subscribe messages from the Discovery Proxy to the Discovery Relay 220 indicate to the Discovery Relay that mDNS messages from one or more 221 specified links are to be relayed to the Discovery Proxy. 223 mDNS messages from a Discovery Proxy to a Discovery Relay cause the 224 Discovery Relay to re-transmit the mDNS message on one or more links 225 to which the Discovery Relay host is directly attached. 227 mDNS messages from a Discovery Relay to a Discovery Proxy are sent 228 whenever an mDNS message is received on a link to which the Discovery 229 Relay has subscribed. 231 Discovery Relays are responsible for keeping connections alive when 232 no traffic has been sent during a keepalive period 233 [I-D.ietf-dnsop-session-signal] Section 4. 235 3.2. mDNS Messages On Links 237 Discovery Relays listen for mDNS traffic on all configured links. 238 When a mDNS message is received on a link, it is forwarded on every 239 open Discovery Proxy connection that is subscribed to mDNS traffic on 240 that link. In the event of congestion, where a particular Discovery 241 Proxy connection has no buffer space for an mDNS message that would 242 otherwise be forwarded to it, the mDNS message is not forwarded to 243 it. Normal mDNS retry behavior is used to recover from this sort of 244 packet loss. Discovery Relays are not expected to buffer more than a 245 few mDNS packets. 247 Discovery Relays accept mDNS traffic from Discovery Proxies. Such 248 traffic is forwarded to zero or more more links to which the 249 Discovery Relay host is directly connected. 251 4. Orchestration 253 In order for one or more Discovery Proxies to make use of one or more 254 Discovery Relays to provide service discovery on one or more links, 255 the set of links on which service will be provided must be known, the 256 set of Discovery Relays for those links must be known, and the set of 257 Discovery Proxies allowed to connect to those Discovery Relays must 258 be known. We assume that this information is maintained in some sort 259 of orchestration system. 261 Although it is of course possible to configure such an environment 262 with a set of static configuration files, it is most useful to 263 consider such a network to be dynamic, with links potentially being 264 added and removed, Discovery Proxies being added and removed, and 265 Discovery Relays being added and removed. This document takes no 266 position on which specific orchestration system will be used, but 267 does specify the inputs and outputs of such a system that will be 268 required for successful operation. In the case of static 269 configuration, these inputs and outputs are also the same; the only 270 difference is that they do not change without human intervention. 272 It is not strictly necessary that all participants in the 273 orchestration process have complete information. It may be desirable 274 for example to have more than one Discovery Proxy managed by an 275 orchestration system, but to have different Discovery Proxies support 276 different links. The set of primitives described here can be used to 277 implement configurations where multiple Discovery Proxies are present 278 and supporting disjoint, overlapping or identical sets of links. 280 There is a special case of orchestration that may be desirable in 281 some settings: when a node may need to be capable of providing either 282 Discovery Proxy service or Discovery Relay service, and is configured 283 to provide Discovery Proxy service, it would be useful to have a way 284 to automatically configure the Discovery Relay to use the Discovery 285 Proxy just on that one node, without requiring a network-wide 286 orchestration system. In the case of a node that supports 287 orchestration through HNCP, however, this is unnecessary: HNCP will 288 work to provide orchestration even on a single node. 290 4.1. Orchestration System Functional Overview 292 Conceptually, the orchestration system has two parts: the part that 293 manages the network, and the part an instance of which is present on 294 each node in the network that is orchestrated by the system. In a 295 cooperative system such as HNCP [RFC7788], orchestration is done 296 cooperatively, and the two functions are present on every 297 participating node. In a managed system using NETCONF [RFC6241], a 298 central service pushes configuration information to managed nodes, 299 and pulls status information from managed nodes. For this 300 discussion, which of these models is used (or whether some other 301 model is used) is immaterial. The functional division is the same in 302 either case: conceptually there is one function that does the 303 orchestration called the Director, and there are one more more 304 functions to which the orchestration applies, called Performers. 306 The Director is receptive to primitives from Performers. Performers 307 apply primitives announced to them by the Director, and announce 308 primitives to the Director. The Director announces primitives to 309 Performers, based on its operating model and its configuration, based 310 either in changes to the network or to announcements from Performers. 312 It is permissible for nodes to provide both Discovery Proxy and 313 Discovery Relay service at the same time. In this case, there is a 314 further conceptual functional division: on such a node, there are two 315 Performers: the Discovery Proxy Performer and the Discovery Relay 316 Performer. These may be the same program, or they may be 317 functionally separate; which is the case is beyond the scope of this 318 document. The reason for making this distinction is to point out 319 that on a node providing both services, both Performers may receive 320 every announcement sent by the Director. And of course the Director 321 receives announcements sent by either Performer. 323 4.2. Orchestration Primitives 325 4.2.1. Link Present 327 The 'Link Present' primitive is used by the Director to communicate 328 the presence of a link to Performers. 'Link Present' primitives 329 include the following data: 331 link identifier One or more opaque 32-bit identifiers, each of which 332 identifies a link that is present on the orchestrated network. 333 Each identifier is unique among all link identifiers managed by 334 the Director. These link identifiers are used in the Discovery 335 Relay protocol to identify links on which mDNS requests will be 336 sent and received, and are consistent across all participants in 337 the orchestration system. 339 4.2.2. Link Remove 341 The 'Link Remove' primitive is used by the Director to communicate to 342 Performers that a link that was formerly present is no longer 343 present. The 'Link Remove' primitive includes the following data: 345 link identifier One or more opaque 32-bit identifiers, as described 346 in Section 4.2.1. 348 4.2.3. Discovery Proxy Available 350 The 'Discovery Proxy Available' primitive is used by Discovery Proxy 351 Performers to announce their availability to the Director, and by the 352 Director to announce to Discovery Relay Performers that Discovery 353 Proxies are present and enabled. This primitive is only used for 354 nodes that provide Discovery Proxy service and can use Discovery 355 Relays: a Discovery Proxy that does not support Discovery Proxy 356 service is never announced in this way. The 'Discovery Proxy 357 Available' primitive includes the following data: 359 node identifier The node identifier of the Discovery Proxy, unique 360 among all nodes managed by a Director. 362 IP addresses One or more IP addresses configured on the network 363 interfaces of the node making the announcement. This list must 364 include all IP addresses from which the Discovery Proxy might 365 connect to Discovery Relays, but need not include any other IP 366 addresses. 368 TLS Certificate A TLS PKI certificate or bare public key which will 369 be used by the Discovery Proxy to authenticate itself when 370 connecting to Discovery Relays. 372 4.2.4. Discovery Proxy Resigning 374 The 'Discovery Proxy Resigning' primitive is used by Discovery 375 Proxies to announce to the Director that they are no longer 376 available, and by the Director to announce to Discovery Relay 377 performers that a Discovery Proxy is no longer present or enabled. 379 The 'Discovery Proxy Resigning' primitive includes the following 380 data: 382 The node identifier of the Discovery Proxy, unique among all nodes 383 managed by a Director. 385 4.2.5. Discovery Relay Available 387 The 'Discovery Relay Available' primitive is used by Discovery Relay 388 Performers to inform the Director that they are available to provide 389 service. It is used by the Director to announce to Discovery Proxy 390 Performers that a Discovery Relay is available and enabled. The 391 'Discovery Relay Available' primitive includes the following data: 393 node identifier The node identifier of the Discovery Relay, unique 394 among all nodes managed by a Director. 396 IP addresses A list of IP addresses on which the Discovery Relay may 397 be contacted. 399 Port TCP Port on which the Discovery Relay will be listening for 400 connections. 402 Server Certificate A TLS PKI certificate or bare public key which 403 will be presented to Discovery Proxies when they initiate TLS 404 connections with the Discovery Relay. This is used both to 405 authenticate the Discovery Relay, and also to establish an 406 encrypted connection between the two services. 408 Links A list of links on which the Discovery Relay provides service. 409 Each link identifier corresponds to a link identified by a 410 previous 'Link Present' primitive sent by the Director, as 411 described in Section 4.2.1. 413 4.2.6. Discovery Relay Resigning 415 When a node providing Discovery Relay support can no longer continue 416 to do so, it announces to the Director that it is no longer available 417 using this primitive. The 'Discovery Relay Resigning' primitive 418 includes the following data: 420 node identifier The node identifier of the Discovery Relay, unique 421 among all nodes managed by a Director. 423 4.3. Orchestration System Behavior 425 4.3.1. Link Present 427 The Director detects new links, or is configured with new links by 428 the network operator. It is responsible for noticing that a link to 429 which more than one participating node is connected is the same link. 430 For example, see Section 6.1 of [RFC7788]. When a new link is 431 detected, the Director reports the presence of that link to all 432 enabled Discovery Proxy Performers, and to all Discovery Relay 433 Performers. If the Director becomes aware of more than one link at 434 the same time, or within an implementation-specific interval, it may 435 announce the presence of more than one link at a time using the 'Link 436 Present' primitive. 438 4.3.2. Link Remove 440 The Director detects the removal of links, either as a result of 441 routers that are connected to those links becoming unavailable, or as 442 a result of manual changes to the configuration by the network 443 operator. When a link that had previously been present is removed, 444 the Director announces the removal of this link to all enabled 445 Discovery Proxy performers and to all Discovery Relay performers. If 446 the removal of more than one link is detected at the same time or 447 within an implementation-specific interval, the removal of each such 448 link may be announced in a single 'Link Remove' primitive. 450 4.3.3. Discovery Proxy Available 452 When the Director receives a 'Discovery Proxy Available' primitive, 453 it records the information in its list of available Discovery Proxies 454 (henceforth "Discovery Proxy List"). If that node had previously 455 reported that Discovery Proxy service was available, the entry in 456 Discovery Proxy List for that node is replaced with an entry 457 generated from the new update; any information in the previous entry 458 that is not present in the update is discarded. 460 Whether or not the Director enables Discovery Proxy service on the 461 Discovery Proxy announced in a newly-received 'Discovery Proxy 462 Available' primitive is dependent on the operational model and 463 configuration of that particular orchestration system, which is out 464 of scope for this document. The same is true as to whether service 465 discovery is enabled on all known links, or not. We assume here that 466 Discovery Proxy service may be available but not enabled on some 467 nodes, whereas Discovery Relay service is generally available, since 468 it will only be used by enabled Discovery Proxies on interfaces on 469 which service discovery is enabled. 471 If the Director enables Discovery Proxy service on that node, the 472 Discovery Proxy is announced to all nodes currently providing 473 Discovery Relay service, using 'Discovery Proxy Available' 474 primitives. In addition, the set of all known Discovery Relays, and 475 the information provided by them to the orchestration system, is 476 announced to the node providing the Discovery Proxy service, using 477 one or more 'Discovery Relay Available' primitives. 479 When a 'Discovery Proxy Available' primitive is received from a 480 Discovery Proxy Performer for which service is already enabled, but 481 the update includes different information than was present in the 482 previous announcement, the Discovery Proxy service is re-announced to 483 every Discovery Relay Performer. 485 4.3.4. Discovery Proxy Resigning 487 When the Director receives a 'Discovery Proxy Resigning' primitive 488 from a Discovery Proxy Performer that had previously sent a 489 'Discovery Proxy available' primitive, the Director first determines 490 if Discovery Proxy service had been enabled on that node. If so, 491 'Discovery Proxy Resigning' notifications are sent to Discovery Relay 492 Performers. 494 The Director may, as a result of a node's resignation from providing 495 Discovery Proxy service, enable Discovery Proxy on some other node. 496 If so, it does so as described in Section 4.3.3. 498 In addition to any announcements sent as a result of a node's 499 resignation from providing Discovery Proxy service, the Director also 500 looks for an entry in the Discovery Proxy List for that node. If one 501 is present, it is removed. 503 4.3.5. Discovery Relay Available 505 When the Director receives a 'Discovery Relay Available' primitive, 506 it records the information in its list of available Discovery Relay 507 Performers (henceforth "Discovery Relay List"). If that list already 508 contains an entry for the Performer making the new report, the entry 509 from the list is discarded and a new one generated from the new 510 announcement. 512 Whether or not the Director enables service discovery through a 513 particular Discovery Relay is dependent on the operation of that 514 particular orchestration system, which is out of scope for this 515 document. It is assumed that a Director may or may not enable a 516 particular Discovery Relay. 518 If the Director enables service discovery through the relay that made 519 the announcement, the relay is announced to all enabled Discovery 520 Proxy Performers. In addition, if the relay had not previously been 521 enabled for service discovery, the Director sends a 'Discovery Proxy 522 Available' primitive to that Performer for each Discovery Proxy 523 Performer on the Discovery Proxy List. 525 4.3.6. Discovery Relay Resigning 527 When the Director receives a 'Discovery Relay Resigning' primitive, 528 it checks to see if the node making the announcement had previously 529 been listed as providing Discovery Relay service; if so, the entry 530 for that node is removed from the list. If Discovery Relay service 531 was enabled for that node, all nodes providing Discovery Proxy 532 service are notified that this node is no longer providing Discovery 533 Relay service, by sending a 'Discovery Relay Resigning' primitive to 534 each such node. 536 4.3.7. Node Available 538 The orchestration system may or may not track the coming and going of 539 nodes that provide service discovery. If it does, depending on the 540 operation of the system, it may be necessary to send some 541 notification to the node to trigger its announcement of service 542 discovery services. How this is done is out of scope for this 543 document. 545 4.3.8. Node Resigning 547 The orchestration system may or may not track the coming and going of 548 nodes that provide service discovery. If it does, then when the 549 departure of a node that has previously announced Discovery Relay 550 and/or Discovery Proxy service should result in the synthesis of 551 resignation events for those services on that node. The exact 552 operation of this mechanism is out of scope for this document. 554 4.4. Discovery Proxy Performer Behavior 556 Nodes may provide both Discovery Proxy and Discovery Relay service: 557 the two services share no ports and are mutually compatible. When a 558 node is providing both services, the behaviors described in this 559 section are specific to the operation of the Discovery Proxy service 560 on that node, not to the Discovery Relay service. 562 4.4.1. Link Present 564 When a node that is providing Discovery Proxy service receives a link 565 present notification, it checks to see if it currently has Discovery 566 Relay service configured for each such link. For any such link for 567 which it does not have Discovery Relay service configured, it 568 identifies the set of Relay Proxies that provide service on that 569 link. It then chooses a Discovery Relay node from this set using a 570 random number generator. If it already has a connection to the Relay 571 Proxy, it attempts to subscribe to mDNS messages from that link. If 572 it does not have a connection, it attempts to establish one. If that 573 succeeds, it attempts to subscribe to mDNS messages from that link. 574 If the outcome of each of these attempts to get Discovery Relay 575 service on the new link fails, it eliminates this Discovery Relay 576 from the set and repeats the process until the set is empty. 578 If no attempt to subscribe to mDNS messages on the link is 579 successful, then service discovery on that link is not possible. The 580 Discovery Proxy node maintains a list of links on which Discovery 581 Relay service is desired but not available; when an attempt to get 582 Discovery Relay service on a link fails, either because no node is 583 providing Discovery Relay service on that link, or because attempting 584 to get service on that link from all nodes claiming to provide it has 585 failed, the link is added to this list. 587 4.4.2. Link Removed 589 When a link is removed, the Discovery Relay checks its list of 590 connections to Discovery Relays for subscription for mDNS messages on 591 that link. If one is present, the Discovery Relay unsubscribes from 592 mDNS messages on that link. If there are no subscriptions present on 593 that connection, the Discovery Relay terminates the connection. If 594 the link is on the list of links for which Discovery Relay service is 595 desired but not available, the link is removed from that list. 597 4.4.3. Discovery Proxy Available 599 Discovery Proxy Performers send 'Discovery Proxy Available' 600 primitives to the Director whenever their configuration changes in a 601 way that affects the content of the primitive, and also whenever 602 their node becomes newly available to the Director. In addition to 603 notifying the Director when they first become connected to the 604 Director's orchestration system, they must also notify the Director 605 when they disconnect and reconnect. 607 When a node with Discovery Proxy service becomes available to the 608 orchestration system, it informs the orchestration system that it can 609 provide Discovery Proxy service. It also provides the orchestration 610 system with a list of IP addresses from which it may originate 611 connections to Discovery Relays, and provides a TLS PKI cert or 612 suitable bare public key which will be used for TLS Client 613 Authentication. 615 Whenever the set of IP addresses from which the Discovery Proxy may 616 initiate a connection to a Discovery Relay changes, the Discovery 617 Proxy sends a new 'Discovery Proxy Available' primitive with its 618 complete information, as above. It may be desirable for the 619 Discovery Proxy node to choose a specific IP address from which all 620 such connections will originate, so as to minimize the number of such 621 updates that may be required, but this behavior is optional. 623 It is not ordinarily the case that the key or certificate used for 624 authentication will change, but if it does, the Discovery Proxy node 625 sends a complete new 'Discovery Proxy Available' primitive, which 626 will contain the new key or certificate. 628 4.4.4. Discovery Proxy Resigning 630 When a node that had previously provided Discovery Proxy service is 631 no longer able to do so for any reason, it announces this to the 632 orchestration system using a 'Discovery Proxy Resigning' primitive. 634 4.4.5. Discovery Relay Available 636 When a node providing Discovery Proxy service receives a 'Discovery 637 Relay Available' notification, it adds that Discovery Relay to its 638 list of available Discovery Relays. If the Discovery Relay is 639 already on the list, the information the list entry is compared to 640 the new information provided in the 'Discovery Relay Available' 641 primitive. If a connection to that Discovery Relay is present, and 642 the destination IP address of that connection is no longer on the 643 list of IP addresses supported by the Discovery Relay, or the public 644 key of the Discovery Relay has changed, the connection is dropped and 645 the process described in Section 4.4.6 is followed. 647 Otherwise, if there is a connection to the Discovery Relay, the list 648 of links subscribed to on that connection is compared to the list of 649 served links listed in the 'Discovery Relay Available' primitive; any 650 links for which subscriptions exist that are not listed in the 651 'Discovery Relay Available' announcement are unsubscribed, and those 652 links added to the list of links on which Discovery Relay service is 653 not available. 655 At this point the process described in Section 4.4.1 is followed for 656 each link on the list of links for which Discovery Relay service is 657 not available. 659 4.4.6. Discovery Relay Resigning 661 Discovery Relay drops its connection to that Discovery Relay and puts 662 all links for which subscriptions existed on that connection onto the 663 list of links on which Discovery Relay service is not available. 664 Because it is possible that another Discovery Relay is available for 665 that link, the Discovery Proxy node again follows the process 666 described in Section 4.4.1. 668 4.5. Discovery Relay Performer Behavior 670 Nodes that support service discovery may support both Discovery Proxy 671 and Discovery Relay. Behaviors described here are specific to nodes 672 that are providing Discovery Relay service. A node that provides 673 both types of service will follow both the behavior described here 674 and the behavior described for Discovery Proxy nodes. 676 4.5.1. Link Present 678 When a Discovery Relay performer receives a link present 679 notification, it determines for each link announced whether it has an 680 interface that is directly connected to that link. If so, it 681 determines whether it has previously announced the availability of 682 service on that link. If not, it adds the link to the list of links 683 on which it provides Discovery Relay service (henceforth "Discovery 684 Relay link list"). 686 If as a result of a 'Link Present' announcement the Discovery Relay 687 link list has changed, the Discovery Relay performer sends a new 688 'Discovery Relay Available' primitive to the Director. 690 4.5.2. Link Removed 692 When the Discovery Relay Performer receives a 'Link Removed' 693 primitive, for each link mentioned in the primitive it checks to see 694 if it is currently providing service on that link. For each link 695 mentioned in the primitive for which it is providing service, it 696 deletes that link from its list of links on which it is providing 697 service. If any links were deleted from the list, the Discovery 698 Relay Performer sends a new 'Discovery Relay Available' message to 699 the Director. 701 4.5.3. Discovery Proxy Available 703 Directors send 'Discovery Proxy Available' primitives to Discovery 704 Relay Performers when new Discovery Proxy Performers announce their 705 availability, and also when Discovery Proxy Performers announce 706 changes to their configuration. When a Discovery Relay Performer 707 receives one of these primitives, it updates its Discovery Proxy IP 708 address whitelist with the set of IP addresses from the primitive, 709 and updates the Discovery Proxy authentication certificate as well. 710 If the Discovery Proxy is connected to the Discovery Relay and either 711 the certificate changed, or the source IP address of the connection 712 is no longer on the whitelist, the Discovery Relay drops the 713 connection. 715 4.5.4. Discovery Proxy Resigning 717 Directors send 'Discovery Proxy Resigning' messages to Discovery 718 Relay Performers when Discovery Proxy Performers indicate that they 719 are no longer available, or when they are disabled by the 720 orchestration system. When a Discovery Relay Performer receives this 721 primitive, it checks to see if any connections from that Discovery 722 Proxy are present. Any such connections are terminated. 724 4.5.5. Discovery Relay Available 726 Discovery Relay Performers send 'Discovery Relay Available' 727 primitives to the Director whenever their configuration changes in a 728 way that affects the content of the primitive, and also whenever 729 their node becomes newly available to the Director. In addition to 730 notifying the Director when they first become connected to the 731 Director's orchestration system, they must also notify the Director 732 when they disconnect and reconnect. 734 Discovery Relays listen for connections from Discovery Proxies. 735 Because no port is reserved for Discovery Relays, it is not useful to 736 announce the availability of the service until the service is 737 listening for connections, at which point it will know which port it 738 is listening on. Therefore, before sending a 'Discovery Relay 739 Available' primitive, a Discovery Relay Performer must have received 740 its listening port from the Discovery Relay service. 742 4.5.6. Discovery Relay Resigning 744 When a node providing Discovery Relay service must stop providing 745 that service, it sends a 'Discovery Relay Resigning' primitive to the 746 Director. 748 5. Connections between Discovery Proxies and Discovery Relays 750 When a Discovery Relay starts, it opens a passive TCP listener to 751 receive connections from Discovery Proxies. This listener may be 752 bound to one or more source IP addresses, or to the wildcard address, 753 depending on the TCP implementation. When a connection is received, 754 the relay must first validate that it is a connection to an IP 755 address to which connections are allowed. For example, it may be 756 that only connections to ULAs are allowed, or to the IP addresses 757 configured on certain interfaces. If the listener is bound to a 758 specific IP address, this check is unnecessary. 760 The relay must then validate that the source IP address of the 761 connection is on its whitelist. If the connection is not permitted 762 either because of the source address or the destination address, the 763 Discovery Relay responds to the TLS Client Hello message from the 764 Discovery Proxy with a TLS user_canceled alert ([I-D.ietf-tls-tls13] 765 Section 6.1). 767 Otherwise, the Discovery Relay will attempt to complete a TLS 768 handshake with the Discovery Proxy. Discovery Proxies are required 769 to send the post_handshake_auth extension ([I-D.ietf-tls-tls13] 770 Section 4.2.5). If a relay proxy receives a ClientHello message with 771 no post_handshake_auth extension, the Discovery Relay rejects the 772 connection with a certificate_required alert ([I-D.ietf-tls-tls13] 773 Section 6.2). 775 Once the TLS handshake is complete, the Discovery Relay MUST request 776 post-handshake authentication as described in ([I-D.ietf-tls-tls13] 777 Section 4.6.2). If the Discovery Proxy refuses to send a 778 certificate, or the key presented does not match the key associated 779 with the IP address from which the connection originated, or the 780 CertificateVerify does not validate, the connection is dropped with 781 the TLS access_denied alert ([I-D.ietf-tls-tls13] Section 6.2). 783 Once the connection is established and authenticated, it is treated 784 as a DNS TCP connection [RFC1035]. 786 Aliveness of connections between Discovery Proxies and Relays is 787 maintained as described in Section 4 of 788 [I-D.ietf-dnsop-session-signal]. Discovery Proxies must also honor 789 the 'Retry Delay' TLV (section 5 of [I-D.ietf-dnsop-session-signal]) 790 if sent by the Discovery Relay. 792 Discovery Proxies may establish more than one connection to a 793 specific Discovery Relay. This would happen in the case that a TCP 794 connection stalls, and the Discovery Proxy is able to reconnect 795 before the previous connection has timed out. It could also happen 796 as a result of a server restart. It is not likely that two active 797 connections from the same Discovery Proxy would be present at the 798 same time, but it must be possible for additional connections to be 799 established. The Discovery Relay may drop the old connection when 800 the new one has been fully established, including a successful TLS 801 handshake. What it means for two connections to be from the same 802 Discovery Proxy is that the connections both have source addresses 803 that belong to the same proxy, and that they were authenticated using 804 the same client certificate. 806 6. Traffic from Relays to Proxies 808 The mere act of connecting to a Discovery Relay does not result in 809 any mDNS traffic being forwarded. In order to request that mDNS 810 traffic from a particular link be forwarded on a particular 811 connection, the Discovery Proxy must send a session signaling message 812 containing one or more MDNS Link Request TLVs (Section 9.1) 813 indicating the link from which traffic is requested. 815 When such a message is received, the Discovery Relay validates that 816 each specified link is available for forwarding, and that forwarding 817 is enabled for that link. For each such message the Discovery Relay 818 validates each link specified and includes in a single response a 819 list of zero or more MDNS Link Invalid TLVs )Section 9.2) for links 820 that are not valid, and zero or more MDNS Link Subscribed TLVs 821 (Section 9.3) for links that are valid. For each valid link, it 822 begins forwarding all mDNS traffic from that link to the Discovery 823 Proxy. Delivery is not guaranteed: if there is no buffer space, 824 packets will be dropped. It is expected that regular mDNS retry 825 processing will take care of retransmission of lost packets. The 826 amount of buffer space is implementation dependent, but generally 827 should not be more than the bandwidth delay product of the TCP 828 connection [RFC1323]. 830 mDNS messages from Relays to Proxies are framed within DNS Session 831 Signaling messages. This allows multiple TLVs to be included. Each 832 forwarded mDNS message is contained in an MDNS Message TLV 833 Section 9.4. The layer 2 source address of the message, if known, 834 MAY be encoded in a Layer 2 Source TLV (Section 9.5). The source IP 835 address of the message MUST be encoded in a IP Source Address TLV 836 (Section 9.6). The source port of the message MUST be encoded in an 837 IP Source port TLV (Section 9.7). The link on which the message was 838 received MUST be encoded in a Link Identifier TLV (Section 9.8). The 839 Discovery Proxy MUST silently ignore unrecognized TLVs in mDNS 840 messages, and MUST NOT discard mDNS messages that include 841 unrecognized TLVs. 843 A Discovery Proxy may discontinue listening for mDNS messages on a 844 particular link by sending a session signaling message containing an 845 MDNS Link Discontinue TLV (Section 9.9). Subsequent messages from 846 that link that had previously been queued indicating may arrive. The 847 Discovery Proxy should silently ignore such messages. The Discovery 848 Relay MUST discontinue generating such messages as soon as the 849 request is received. The Discovery Relay does not respond to this 850 message other than to discontinue forwarding mDNS messages from the 851 specified links. 853 7. Traffic from Proxies to Relays 855 Like mDNS traffic from relays, each mDNS message sent by a Discovery 856 Proxie to a Discovery Relay is encapsulated in an MDNS Message TLV 857 (Section 9.4) within a session signaling message. Each message MUST 858 contain one or more Link Identifier TLVs (Section 9.8). The 859 Discovery Relay will transmit the message to the mDNS port and 860 multicast address on each link. The message MUST include one or more 861 IP family TLVs (Section 9.10). For each such TLVs that is included, 862 the message will be sent on each link using the specified IP family. 863 If no family codes are recognized, no packets will be transmitted. 865 8. Discovery Proxy Behavior 867 Discovery Proxies treat links for which Discovery Relay service is 868 being used as if they were virtual interfaces; in other words, a 869 Discovery Proxy serving multiple links using multiple Discovery 870 Relays behaves the same as a Discovery Proxy serving multiple links 871 using multiple physical network interfaces. 873 Discovery Proxies responding to mDNS messages for non-link-local IP 874 addresses where the unicast bit is set respond directly, rather than 875 through a proxy. Link-local responses are not supported for links to 876 which Discovery Proxies are not directly connected. 878 9. Session Signaling TLVs 880 This document defines a modest number of new DNS Session Signaling 881 TLVs. 883 9.1. MDNS Link Request 885 The MDNS Link Request TLV conveys a 32-bit link identifier from which 886 a Discovery Proxy is requesting that a Discovery Relay forward mDNS 887 traffic. The link identifier comes from the orchestration system 888 (see Section 4.2.1). The SSOP-TYPE for this TLV is TBD1. The SSOP- 889 LENGTH is always 4. The SSOP-DATA is the 32-bit identifier in 890 network byte order. 892 9.2. MDNS Link Invalid 894 The MDNS Link Invalid TLV is returned in response to a session 895 signaling message containing an MDNS Link Request, and returns the 896 32-bit identifier that was contained in that request. The link 897 identifier comes from an MDNS Link Request TLV in the message being 898 responded to. The TLV indicates that the specified link identifier 899 does not refer to a valid link, either because the link is not 900 supported by the Discovery Relay, or because the identifier is not 901 known. The SSOP-TYPE for this TLV is TBD2. The SSOP-LENGTH is 902 always 4. The SSOP-DATA is the 32-bit identifier in network byte 903 order. 905 9.3. MDNS Link Subscribed 907 The MDNS Link Subscribed TLV is returned in response to a session 908 signaling message containing an MDNS Link Request, and returns the 909 32-bit identifier from a MDNS Link Request TLV that was contained in 910 that request. It indicates that MDNS messages for the specified link 911 have been successfully subscribed. The SSOP-TYPE for this TLV is 912 TBD3. The SSOP-LENGTH is always 4. The SSOP-DATA is the 32-bit 913 identifier in network byte order. 915 9.4. MDNS Message 917 The MDNS Message TLV is used to encapsulate an mDNS message that is 918 being forwarded from a link to a Discovery Proxy, or is being 919 forwarded from a Discovery Proxy to a link. The SSOP-TYPE for this 920 TLV is TBD4. SSOP-LENGTH is the length of the application layer 921 payload of the MDNS message. SSOP-DATA is the application layer 922 payload of the message. 924 9.5. Layer 2 Source Address 926 The Layer 2 Source Address TLV is used to report the layer 2 address 927 from which an mDNS message was received. This TLV is optionally 928 present in session signaling messages from Discovery Relays to 929 Discovery Proxies that contain mDNS messages when the source link- 930 layer address is known. The SSOP-TYPE is TBD5. SSOP-LENGTH is 931 variable, depending on the length of link-layer addresses on the link 932 from which the message was received. SSOP-data is the link-layer 933 address as it was received on the link. 935 9.6. IP Source Address 937 The IP Source Address TLV is used to report the IP source address 938 from which an mDNS message was received. This TLV is present in 939 session signaling messages from Discovery Relays to Discovery Proxies 940 that contain mDNS messages. SSOP-TYPE is TBD6. SSOP-LENGTH is 941 either 4, for an IPv4 address, or 16, for an IPv6 address. SSOP-DATA 942 is the IP Address. 944 9.7. IP Source Port 946 The IP Source Port TLV is used to report the IP source port from 947 which an mDNS message was received. This TLV is present in session 948 signaling messages from Discovery Relays to Discovery Proxies. SSOP- 949 TYPE is TBD7. SSOP-LENGTH is 2. SSOP-DATA is the source port in 950 network byte order. 952 9.8. Link Identifier 954 This option is used both in session signaling messages from Discovery 955 Proxies to Discovery Relays that contain mDNS messages, and in 956 message from Discovery Relays to Discovery Proxies that contain mDNS 957 messages. In the former case, it indicates a link to which the 958 message should be forwarded; in the latter case, it indicates the 959 link on which the message was received. SSOP-TYPE is TBD8. SSOP- 960 LENGTH is 4. SSOP-DATA is a 32-bit link identifier as described in 961 Section 4.2.1. 963 9.9. MDNS Discontinue 965 This option is used by Discovery Proxies to unsubscribe to mDNS 966 messages on the specified link. More than one may be present in a 967 single session signaling message. SSOP-TYPE is TBD9. SSOP-LENGTH is 968 4. SSOP-DATA is a 32-bit link identifier as described in 969 Section 4.2.1. 971 9.10. IP Address Family 973 This option is used in mDNS messages sent by Discovery Proxies to 974 links to indicate to the Discovery Relay which IP address family or 975 families should be used when transmitting the message on the link. 976 More than one may be present in a single session signaling message. 977 SSOP-TYPE is TBD10. SSOP-LENGTH is 1. SSOP-DATA is a 8-bit IP 978 family identifier. A value of 1 indicates IPv4. A value of 2 979 indicates IPv6. Other values are reserved, and MUST be ignored if 980 not recognized. 982 10. Security Considerations 984 11. IANA Considerations 986 The IANA is kindly requested to update the DNS Session Signaling Type 987 Codes Registry [I-D.ietf-dnsop-session-signal] by allocating codes 988 for each of the TBD type codes listed in the following table, and by 989 updating this document, here and in Section 9. Each type code should 990 list this document as its reference document. 992 +--------+----------+--------------------------+ 993 | Opcode | Status | Name | 994 +--------+----------+--------------------------+ 995 | TBD1 | Standard | MDNS Link Request | 996 | TBD2 | Standard | MDNS Link Invalid | 997 | TBD3 | Standard | MDNS Link Subscribed | 998 | TBD4 | Standard | MDNS Messsage | 999 | TBD5 | Standard | Layer Two Source Address | 1000 | TBD6 | Standard | IP Source Address | 1001 | TBD7 | Standard | IP Destination Address | 1002 | TBD8 | Standard | Link Identifier | 1003 | TBD9 | Standard | MDNS Discontinue | 1004 | TBD10 | Standard | IP Address Family | 1005 +--------+----------+--------------------------+ 1007 DNS Session Signaling Type Codes to be allocated 1009 12. IANA Considerations 1011 13. Acknowledgments 1013 14. References 1015 14.1. Normative References 1017 [I-D.ietf-dnsop-session-signal] 1018 Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1019 Mankin, A., and T. Pusateri, "DNS Session Signaling", 1020 draft-ietf-dnsop-session-signal-02 (work in progress), 1021 March 2017. 1023 [I-D.ietf-dnssd-hybrid] 1024 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 1025 Service Discovery", draft-ietf-dnssd-hybrid-06 (work in 1026 progress), March 2017. 1028 [I-D.ietf-tls-tls13] 1029 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1030 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 1031 April 2017. 1033 [RFC1035] Mockapetris, P., "Domain names - implementation and 1034 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1035 November 1987, . 1037 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 1038 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 1039 1992, . 1041 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1042 and A. Bierman, Ed., "Network Configuration Protocol 1043 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1044 . 1046 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1047 DOI 10.17487/RFC6762, February 2013, 1048 . 1050 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1051 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1052 . 1054 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1055 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1056 2016, . 1058 14.2. Informative References 1060 [TR-069] Broadband Forum, "CPE WAN Management Protocol", November 1061 2013, . 1064 Authors' Addresses 1066 Stuart Cheshire 1067 Apple Inc. 1068 1 Infinite Loop 1069 Cupertino, California 95014 1070 USA 1072 Phone: +1 408 974 3207 1073 Email: cheshire@apple.com 1075 Ted Lemon 1076 Nominum, Inc. 1077 800 Bridge Parkway 1078 Redwood City, California 94065 1079 United States of America 1081 Phone: +1 650 381 6000 1082 Email: ted.lemon@nominum.com