idnits 2.17.1 draft-ietf-dnssd-mdns-relay-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-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 304: '... alert ([I-D.ietf-tls-tls13] Section 6.1). Discovery Relays SHOULD...' RFC 2119 keyword, line 317: '...lete, the Discovery Relay MUST request...' RFC 2119 keyword, line 325: '... Clients MUST validate server certif...' RFC 2119 keyword, line 330: '...name, the client SHOULD present that d...' RFC 2119 keyword, line 351: '... Clients SHOULD avoid establishing m...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 753 has weird spacing: '... name a mac...' == Line 756 has weird spacing: '...hr-name an op...' == Line 760 has weird spacing: '...ificate a cer...' == Line 766 has weird spacing: '...ate-key the p...' == Line 769 has weird spacing: '...dresses a lis...' == (8 more instances...) -- The document date (March 11, 2019) is 1873 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 (-10) exists of draft-ietf-dnssd-hybrid-08 ** Downref: Normative reference to an Informational draft: draft-sctl-discovery-broker (ref. 'I-D.sctl-discovery-broker') ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-04 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Nibbhaya Consulting 4 Intended status: Standards Track S. Cheshire 5 Expires: September 12, 2019 Apple Inc. 6 March 11, 2019 8 Multicast DNS Discovery Relay 9 draft-ietf-dnssd-mdns-relay-02 11 Abstract 13 This document complements the specification of the Discovery Proxy 14 for Multicast DNS-Based Service Discovery. It describes a 15 lightweight relay mechanism, a Discovery Relay, which, when present 16 on a link, allows remote clients, not attached to that link, to 17 perform mDNS discovery operations on that link. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at 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 12, 2019. 36 Copyright Notice 38 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Connections between Clients and Relays (overview) . . . . 6 57 3.2. mDNS Messages On Multicast Links . . . . . . . . . . . . 7 58 4. Connections between Clients and Relays (details) . . . . . . 8 59 5. Traffic from Relays to Clients . . . . . . . . . . . . . . . 10 60 6. Traffic from Clients to Relays . . . . . . . . . . . . . . . 12 61 7. Discovery Proxy Behavior . . . . . . . . . . . . . . . . . . 13 62 8. DSO TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 8.1. mDNS Link Data Request . . . . . . . . . . . . . . . . . 14 64 8.2. mDNS Link Data Discontinue . . . . . . . . . . . . . . . 14 65 8.3. Link Identifier . . . . . . . . . . . . . . . . . . . . . 15 66 8.4. Encapsulated mDNS Message . . . . . . . . . . . . . . . . 15 67 8.5. IP Source . . . . . . . . . . . . . . . . . . . . . . . . 15 68 8.6. Link State Request . . . . . . . . . . . . . . . . . . . 15 69 8.7. Link State Discontinue . . . . . . . . . . . . . . . . . 16 70 8.8. Link Available . . . . . . . . . . . . . . . . . . . . . 16 71 8.9. Link Unavailable . . . . . . . . . . . . . . . . . . . . 16 72 8.10. Link Prefix . . . . . . . . . . . . . . . . . . . . . . . 16 73 9. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 18 74 9.1. Provisioned Objects . . . . . . . . . . . . . . . . . . . 19 75 9.1.1. Multicast Link . . . . . . . . . . . . . . . . . . . 19 76 9.1.2. Discovery Proxy . . . . . . . . . . . . . . . . . . . 20 77 9.1.3. Discovery Relay . . . . . . . . . . . . . . . . . . . 21 78 9.2. Configuration Files . . . . . . . . . . . . . . . . . . . 22 79 9.3. Discovery Proxy Private Configuration . . . . . . . . . . 24 80 9.4. Discovery Relay Private Configuration . . . . . . . . . . 24 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 83 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 86 13.2. Informative References . . . . . . . . . . . . . . . . . 28 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 89 1. Introduction 91 The Discovery Proxy for Multicast DNS-Based Service Discovery 92 [I-D.ietf-dnssd-hybrid] is a mechanism for discovering services on a 93 subnetted network through the use of Discovery Proxies, which issue 94 Multicast DNS (mDNS) requests [RFC6762] on various multicast links in 95 the network on behalf of a remote host performing DNS-Based Service 96 Discovery [RFC6763]. 98 In the original Discovery Proxy specification, it is imagined that 99 for every multicast link on which services will be discovered, a host 100 will be present running a full Discovery Proxy. This document 101 introduces a lightweight Discovery Relay that can be used to provide 102 discovery services on a multicast link without requiring a full 103 Discovery Proxy on every multicast link. 105 Since the primary purpose of a Discovery Relay is providing remote 106 virtual interface functionality to Discovery Proxies, this document 107 is written with that usage in mind. However, in principle, a 108 Discovery Relay could be used by any properly authorized client. In 109 the context of this specification, a Discovery Proxy is a client to 110 the Discovery Relay. This document uses the terms "Discovery Proxy" 111 and "Client" somewhat interchangably; the term "Client" is used when 112 we are talking about the communication between the Client and the 113 Relay, and the term "Discovery Proxy" when we are referring 114 specifically to a Discovery Relay Client that also happens to be 115 acting as a Discovery Proxy. 117 The Discovery Relay operates by listening for TCP connections from 118 Clients. When a Client connects, the connection is authenticated and 119 secured using TLS. The Client can then specify one or more multicast 120 links from which it wishes to receive mDNS traffic. The Client can 121 also send messages to be transmitted on its behalf on one or more of 122 those multicast links. DNS Stateful Operations (DSO) 123 [I-D.ietf-dnsop-session-signal] is used as a framework for conveying 124 interface and IP header information associated with each message. 125 DSO formats its messages using type-length-value (TLV) data 126 structures. This document defines additional DSO TLV types, used to 127 implement the Discovery Relay functionality. 129 The Discovery Relay functions essentially as a set of one or more 130 remote virtual interfaces for the Client, one on each multicast link 131 to which the Discovery Relay is connected. In a complex network, it 132 is possible that more than one Discovery Relay will be connected to 133 the same multicast link; in this case, the Client ideally should only 134 be using one such Relay Proxy per multicast link, since using more 135 than one will generate duplicate traffic. 137 How such duplication is detected and avoided is out of scope for this 138 document; in principle it could be detected using HNCP [RFC7788] or 139 configured using some sort of orchestration software in conjunction 140 with NETCONF [RFC6241] or CPE WAN Management Protocol [TR-069]. 142 2. Terminology 144 The following definitions may be of use: 146 Client A network service that uses a Discovery Relay to send and 147 receive mDNS multicast traffic on a remote link, to enable it to 148 communicate with mDNS Agents on that remote link. 150 mDNS Agent A host which sends and/or responds to mDNS queries 151 directly on its local link(s). Examples include network cameras, 152 networked printers, networked home electronics, etc. 154 Discovery Proxy A network service which receives well-formed 155 questions using the DNS protocol, performs multicast DNS queries 156 to answer those questions, and responds with those answers using 157 the DNS protocol. A Discovery Proxy that can communicate with 158 remote mDNS Agents, using the services of a Discovery Relay, is a 159 Client of the Discovery Relay. 161 Discovery Relay A network service which relays mDNS messages 162 received on a local link to a Client, and on behalf of that Client 163 can transmit mDNS messages on a local link. 165 multicast link A maximal set of network connection points, such that 166 any host connected to any connection point in the set may send a 167 packet with a link-local multicast destination address 168 (specifically the mDNS link-local multicast destination address 169 [RFC6762]) that will be received by all hosts connected to all 170 other connection points in the set. Note that it is becoming 171 increasingly common for a multicast link to be smaller than its 172 corresponding unicast link. For example it is becoming common to 173 have multiple Wi-Fi access points on a shared Ethernet backbone, 174 where the multiple Wi-Fi access points and their shared Ethernet 175 backbone form a single unicast link (a single IPv4 subnet, or 176 single IPv6 prefix) but not a single multicast link. Unicast 177 packets sent directly between two hosts on that IPv4 subnet or 178 IPv6 prefix, without passing through an intervening IP-layer 179 router, are correctly delivered, but multicast packets are not 180 forwarded between the various Wi-Fi access points. Given the 181 slowness of Wi-Fi multicast 182 [I-D.ietf-mboned-ieee802-mcast-problems], having a packet that may 183 be of interest to only one or two end systems transmitted to 184 hundreds of devices, across multiple Wi-Fi access points, is 185 especially wasteful. Hence the common configuration decision to 186 not forward multicast packets between Wi-Fi access points is very 187 reasonable. This further motivates the need for technologies like 188 Discovery Proxy and Discovery Relay to facilitate discovery on 189 these networks. 191 whitelist A list of one or more IP addresses from which a Discovery 192 Relay may accept connections. 194 silently discard When a message that is not supported or not 195 permitted is received, and the required response to that message 196 is to "silently discard" it, that means that no response is sent 197 by the service that is discarding the message to the service that 198 sent it. The service receiving the message may log the event, and 199 may also count such events: "silently" does not preclude such 200 behavior. 202 3. Protocol Overview 204 This document describes a way for Clients to communicate with mDNS 205 agents on remote multicast links to which they are not directly 206 connected, using a Discovery Relay. As such, there are two parts to 207 the protocol: connections between Clients and Discovery Relays, and 208 communications between Discovery Relays and mDNS agents. 210 3.1. Connections between Clients and Relays (overview) 212 Discovery Relays listen for incoming connection requests. 213 Connections between Clients and Discovery Relays are established by 214 Clients. Connections are authenticated and encrypted using TLS, with 215 both client and server certificates. Connections are long-lived: a 216 Client is expected to send many queries over a single connection, and 217 Discovery Relays will forward all mDNS traffic from subscribed 218 interfaces over the connection. 220 The stream encapsulated in TLS will carry DNS frames as in the DNS 221 TCP protocol [RFC1035] Section 4.2.2. However, all messages will be 222 DSO messages [I-D.ietf-dnsop-session-signal]. There will be four 223 types of such messages between Discovery Relays and Clients: 225 o Control messages from Client to Relay 227 o Link status messages from Relay to Client 229 o Encapsulated mDNS query messages from Client to Relay 231 o Encapsulated mDNS response messages from Relay to Client 233 Clients can send four different control messages to Relays: Link 234 State Request, Link State Discontinue, Link Data Request and Link 235 Data Discontinue. The first two are used by the Client to request 236 that the Relay report on the set of links that can be requested, and 237 to request that it discontinue such reporting. The second two are 238 used by the Client to indicate to the Discovery Relay that mDNS 239 messages from one or more specified multicast links are to be relayed 240 to the Client, and to subsequently stop such relaying. 242 Link Status messages from a Discovery Relay to the Client inform the 243 Client that a link has become available, or that a formerly-available 244 link is no longer available. 246 Encapsulated mDNS response messages from a Discovery Relay to a 247 Client are sent whenever an mDNS response message is received on a 248 multicast link to which the Discovery Relay has subscribed. 250 Encapsulated query mDNS messages from a Client to a Discovery Relay 251 cause the Discovery Relay to transmit the mDNS query message on the 252 specified multicast link to which the Discovery Relay host is 253 directly attached. 255 During periods with no traffic flowing, Clients are responsible for 256 generating any necessary keepalive traffic, as stated in the DSO 257 specification [I-D.ietf-dnsop-session-signal]. 259 3.2. mDNS Messages On Multicast Links 261 Discovery Relays listen for mDNS traffic on all configured multicast 262 links that have at least one active subscription from a Client. When 263 an mDNS response message is received on a multicast link, it is 264 forwarded on every open Client connection that is subscribed to mDNS 265 traffic on that multicast link. In the event of congestion, where a 266 particular Client connection has no buffer space for an mDNS message 267 that would otherwise be forwarded to it, the mDNS message is not 268 forwarded to it. Normal mDNS retry behavior is used to recover from 269 this sort of packet loss. Discovery Relays are not expected to 270 buffer more than a few mDNS packets. Excess mDNS packets are 271 silently discarded. In practice this is not expected to be a issue. 272 Particularly on networks like Wi-Fi, multicast packets are 273 transmitted at rates ten or even a hundred times slower than unicast 274 packets. This means that even at peak multicast packets rates, it is 275 likely that a unicast TCP connection will able to carry those packets 276 with ease. 278 Clients send encapsulated mDNS query messages they wish to have sent 279 on their behalf on remote multicast link(s) on which the Client has 280 an active subscription. A Discovery Relay will not transmit mDNS 281 query packets on any multicast link on which the Client does not have 282 an active subscription, since it makes no sense for a Client to ask 283 to have a query sent on its behalf if it's not able to receive the 284 responses to that query. 286 4. Connections between Clients and Relays (details) 288 When a Discovery Relay starts, it opens a passive TCP listener to 289 receive incoming connection requests from Clients. This listener may 290 be bound to one or more source IP addresses, or to the wildcard 291 address, depending on the implementation. When a connection is 292 received, the relay must first validate that it is a connection to an 293 IP address to which connections are allowed. For example, it may be 294 that only connections to ULAs are allowed, or to the IP addresses 295 configured on certain interfaces. If the listener is bound to a 296 specific IP address, this check is unnecessary. 298 If the relay is using an IP address whitelist, the next step is for 299 the relay to verify that that the source IP address of the connection 300 is on its whitelist. If the connection is not permitted either 301 because of the source address or the destination address, the 302 Discovery Relay closes the connection. If possible, before closing 303 the connection, the Discovery Relay first sends a TLS user_canceled 304 alert ([I-D.ietf-tls-tls13] Section 6.1). Discovery Relays SHOULD 305 refuse to accept TCP connections to invalid destination addresses, 306 rather than accepting and then closing the connection, if this is 307 possible. 309 Otherwise, the Discovery Relay will attempt to complete a TLS 310 handshake with the Client. Clients are required to send the 311 post_handshake_auth extension ([I-D.ietf-tls-tls13] Section 4.2.5). 312 If a Discovery Relay receives a ClientHello message with no 313 post_handshake_auth extension, the Discovery Relay rejects the 314 connection with a certificate_required alert ([I-D.ietf-tls-tls13] 315 Section 6.2). 317 Once the TLS handshake is complete, the Discovery Relay MUST request 318 post-handshake authentication as described in ([I-D.ietf-tls-tls13] 319 Section 4.6.2). If the Client refuses to send a certificate, or the 320 key presented does not match the key associated with the IP address 321 from which the connection originated, or the CertificateVerify does 322 not validate, the connection is dropped with the TLS access_denied 323 alert ([I-D.ietf-tls-tls13] Section 6.2). 325 Clients MUST validate server certificates. If the client is 326 configured with a server IP address and certificate, it can validate 327 the server by comparing the certificate offered by the server to the 328 certificate that was provided: they should be the same. If the 329 certificate includes a Distinguished Name that is a fully-qualified 330 domain name, the client SHOULD present that domain name to the server 331 in an SNI request. 333 Rather than being configured with an IP address and a certificate, 334 the client may be configured with the server's FQDN. In this case, 335 the client uses the server's FQDN as a Authentication Domain Name 336 [RFC8310] Section 7.1, and uses the authentication method described 337 in [RFC8310] section 8.1, if the certificate is signed by a root 338 authority the client trusts, or the method described in section 8.2 339 of the same document if not. If neither method is available, then a 340 locally-configured copy of the server certificate can be used, as in 341 the previous paragraph. 343 Once the connection is established and authenticated, it is treated 344 as a DNS TCP connection [RFC7766]. 346 Aliveness of connections between Clients and Relays is maintained as 347 described in Section 4 of [I-D.ietf-dnsop-session-signal]. Clients 348 must also honor the 'Retry Delay' TLV (section 5 of 349 [I-D.ietf-dnsop-session-signal]) if sent by the Discovery Relay. 351 Clients SHOULD avoid establishing more than one connection to a 352 specific Discovery Relay. However, there may be situations where 353 multiple connections to the same Discovery Relay are unavoidable, so 354 Discovery Relays MUST be willing to accept multiple connections from 355 the same Client. 357 In order to know what links to request, the Client can be configured 358 with a list of links supported by the Relay. However, in some 359 networking contexts, dynamic changes in the availability of links are 360 likely; therefore Clients may also use the Report Link Changes TLV to 361 request that the Relay report on the availability of its links. In 362 some contexts, for example when debugging, a Client may operate with 363 no information about the set of links supported by a relay, simply 364 relying on the relay to provide one. 366 5. Traffic from Relays to Clients 368 The mere act of connecting to a Discovery Relay does not result in 369 any mDNS traffic being forwarded. In order to request that mDNS 370 traffic from a particular multicast link be forwarded on a particular 371 connection, the Client must send one or more DSO messages, each 372 containing a single mDNS Link Data Request TLV (Section 8.1) 373 indicating the multicast link from which traffic is requested. 375 When an mDNS Link Data Request message is received, the Discovery 376 Relay validates that it recognizes the link identifier, and that 377 forwarding is enabled for that link. If both checks are successful, 378 it MUST send a response with RCODE=0 (NOERROR). If the link 379 identifier is not recognized, it sends a response with RCODE=3 380 (NXDOMAIN/Name Error). If forwarding from that link to the Client is 381 not enabled, it sends a response with RCODE=5 (REFUSED). If the 382 relay cannot satisfy the request for some other reason, for example 383 resource exhaustion, it sends a response with RCODE=2 (SERVFAIL). It 384 is not an error to request a recognized link identifier which is not 385 yet available; the Discovery Relay accepts the request, and begins 386 forwarding packets when the link becomes available. 388 If the requested link is valid, the Relay begins forwarding all mDNS 389 response messages from that link to the Client. Delivery is not 390 guaranteed: if there is no buffer space, packets will be dropped. It 391 is expected that regular mDNS retry processing will take care of 392 retransmission of lost packets. The amount of buffer space is 393 implementation dependent, but generally should not be more than the 394 bandwidth delay product of the TCP connection [RFC1323]. The 395 Discovery Relay should use the TCP_NOTSENT_LOWAT mechanism 396 [NOTSENT][PRIO] or equivalent, to avoid building up a backlog of data 397 in excess of the amount necessary to have in flight to fill the 398 bandwidth delay product of the TCP connection. 400 Encapsulated mDNS response messages from Relays to Clients are framed 401 within DSO messages. Each DSO message can contain multiple TLVs, but 402 only a single encapsulated mDNS message is conveyed per DSO message. 403 Each forwarded mDNS response message is sent in an Encapsulated mDNS 404 Message TLV (Section 8.4). The source IP address and port of the 405 message MUST be encoded in an IP Source TLV (Section 8.5). The 406 multicast link on which the message was received MUST be encoded in a 407 Link Identifier TLV (Section 8.3). As described in the DSO 408 specification [I-D.ietf-dnsop-session-signal], a Client MUST silently 409 ignore unrecognized Additional TLVs in mDNS messages, and MUST NOT 410 discard mDNS messages that include unrecognized Additional TLVs. 412 A Client may discontinue listening for mDNS messages on a particular 413 multicast link by sending a DSO message containing an mDNS Link Data 414 Discontinue TLV (Section 8.2). Subsequent messages from that link 415 that had previously been queued may arrive after listening has been 416 discontinued. The Client should silently discard such messages. The 417 Discovery Relay MUST discontinue generating such messages as soon as 418 the request is received. The Discovery Relay does not respond to 419 this message other than to discontinue forwarding mDNS messages from 420 the specified links. 422 6. Traffic from Clients to Relays 424 Like mDNS traffic from relays, each mDNS query message sent by a 425 Client to a Discovery Relay is communicated in an Encapsulated mDNS 426 Message TLV (Section 8.4) within a DSO message. Each message MUST 427 contain exactly one Link Identifier TLV (Section 8.3). The Discovery 428 Relay will transmit the mDNS query message to the mDNS port and 429 multicast address on the link specified in the message using the 430 specified IP address family. 432 Although the communication between Clients and Relays uses the DNS 433 stream protocol and DNS Stateless Operations, there is no case in 434 which a Client would legitimately send a DNS query (something other 435 than a DSO message) to a Relay. Therefore, if a Relay receives a 436 message other than a DSO message, it MUST respond with a REFUSED 437 result code. The reason not to simply drop the connection is that it 438 might result in a continual reconnection loop. 440 When defining this behavior, the working group considered making it 441 possible to specify more than one link identifier in an mDNSMessage 442 TLV. A superficial evaluation of this suggests that this would be a 443 useful optimization, since when a query is issued, it will often be 444 issued to all links. However, because of the way mDNS handles 445 retries, it will almost never be the case that the exact same message 446 will be sent on more than one link. Therefore, the complexity that 447 this optimization adds is in no way justified by the potential 448 benefit, and this idea has been abandoned. 450 7. Discovery Proxy Behavior 452 Discovery Proxies treat multicast links for which Discovery Relay 453 service is being used as if they were virtual interfaces; in other 454 words, a Discovery Proxy serving multiple remote multicast links 455 using multiple Discovery Relays behaves the same as a Discovery Proxy 456 serving multiple local multicast links using multiple physical 457 network interfaces. In this section we refer to multicast links 458 served directly by the Discovery Proxy as locally-connected links, 459 and multicast links served through the Discovery Relay as relay- 460 connected links. 462 When a Discovery Proxy receives a DNSSD query from a Client via 463 unicast, it will generate mDNS query messages on the relevant 464 multicast link(s) for which it is acting as a proxy. For locally- 465 connected link(s), those query messages will be sent directly. For 466 relay-connected link(s), the query messages will be sent through the 467 Discovery Relay that is being used to serve that multicast link. 469 Responses from devices on locally-connected links are processed 470 normally. Responses from devices on relay-connected links are 471 received by the Discovery Relay, encapsulated, and forwarded to the 472 Client; the Client then processes these messages using the link- 473 identifying information included in the encapsulation. 475 Discovery Proxies do not generally respond to mDNS queries on relay- 476 connected links. The one exception is responding to the Domain 477 Enumeration queries used to bootstrap unicast service discovery 478 ("lb._dns-sd._udp.local", etc.) [RFC6763]. Apart from these Domain 479 Enumeration queries, if any other mDNS query is received from a 480 Discovery Relay, the Discovery Proxy silently discards it. 482 In principle it could be the case that some device is capable of 483 performing service discovery using Multicast DNS, but not using 484 traditional unicast DNS. Responding to mDNS queries received from 485 the Discovery Relay could address this use case. However, continued 486 reliance on multicast is counter to the goals of the current work in 487 service discovery, and to benefit from wide-area service discovery 488 such client devices should be updated to support service discovery 489 using unicast queries. 491 8. DSO TLVs 493 This document defines a modest number of new DSO TLVs. 495 8.1. mDNS Link Data Request 497 The mDNS Link Data Request TLV conveys a link identifier from which a 498 Client is requesting that a Discovery Relay forward mDNS traffic. 499 The link identifier comes from the provisioning configuration (see 500 Section 9). The DSO-TYPE for this TLV is TBD-R. DSO-LENGTH is 501 always 5. DSO-DATA is the 8-bit address family followed by the link 502 identifier, a 32-bit unsigned integer in network (big endian) byte 503 order, as described in Section 9. An address family value of 1 504 indicates IPv4 and 2 indicates IPv6, as recorded in the IANA Registry 505 of Address Family Numbers [AdFam]. 507 The mDNS Link Data Request TLV can only be used as a primary TLV, and 508 requires an acknowledgement. 510 At most one mDNS Link Data Request TLV may appear in a DSO message. 511 To request multiple link subscriptions, multiple separate DSO 512 messages are sent, each containing a single mDNS Link Data Request 513 TLV. 515 A Client MUST NOT request a link if it already has an active 516 subscription to that link on the same DSO connection. If a Discovery 517 Relay receives a duplicate link subscription request, it SHOULD 518 immediately abort that DSO session. 520 8.2. mDNS Link Data Discontinue 522 The mDNS Link Data Discontinue TLV is used by Clients to unsubscribe 523 to mDNS messages on the specified multicast link. DSO-TYPE is TBD-D. 524 DSO-LENGTH is always 5. DSO-DATA is the 8-bit address family 525 followed by the 32-bit link identifier, a 32-bit unsigned integer in 526 network (big endian) byte order, as described in Section 9. 528 The mDNS Link Data Discontinue TLV can only be used as a primary TLV, 529 and is not acknowledged. 531 At most one mDNS Link Data Discontinue TLV may appear in a DSO 532 message. To unsubscribe from multiple links, multiple separate DSO 533 messages are sent, each containing a single mDNS Link Data 534 Discontinue TLV. 536 8.3. Link Identifier 538 This option is used both in DSO messages from Discovery Relays to 539 Clients that contain received mDNS messages, and from Clients to 540 Discovery Relays that contain mDNS messages to be transmitted on the 541 multicast link. In the former case, it indicates the multicast link 542 on which the message was received; in the latter case, it indicates 543 the multicast link on which the message should be transmitted. DSO- 544 TYPE is TBD-L. DSO-LENGTH is always 5. DSO-DATA is the 8-bit 545 address family followed by the link identifier, a 32-bit unsigned 546 integer in network (big endian) byte order, as described in 547 Section 9. 549 The Link Identifier TLV can only be used as an additional TLV. 551 8.4. Encapsulated mDNS Message 553 The Encapsulated mDNS Message TLV is used to communicate an mDNS 554 message that a Relay is forwarding from a multicast link to a Client, 555 or that a Client is sending to a Relay for transmission on a 556 multicast link. Only the application-layer payload of the mDNS 557 message is carried in the DSO "Encapsulated mDNS Message" TLV, i.e., 558 just the DNS message itself, beginning with the DNS Message ID, not 559 the IP or UDP headers. The DSO-TYPE for this TLV is TBD-M. DSO- 560 LENGTH is the length of the encapsulated mDNS message. DSO-DATA is 561 the content of the encapsulated mDNS message. 563 The Encapsulated mDNS Message TLV can only be used as a primary TLV, 564 and is not acknowledged. 566 8.5. IP Source 568 The IP Source TLV is used to report the IP source address and port 569 from which an mDNS message was received. This TLV is present in DSO 570 messages from Discovery Relays to Clients that contain encapsulated 571 mDNS messages. DSO-TYPE is TBD-S. DSO-LENGTH is either 6, for an 572 IPv4 address, or 18, for an IPv6 address. DSO-DATA is the two-byte 573 source port, followed by the 4- or 16-byte IP Address, both in the 574 canonical byte order (i.e., the same representation as used in the 575 UDP and IP packet headers, with no byte swapping). 577 The IP Source TLV can only be used as an additional TLV. 579 8.6. Link State Request 581 The Link State Request TLV requests that the Discovery Relay report 582 link changes. When the relay is reporting link changes and a new 583 link becomes available, it sends a Link Available message to the 584 Client. When a link becomes unavailable, it sends a Link Unavailable 585 message to the Client. If there are links available when the request 586 is received, then for each such link the relay immediately sends a 587 Link Available Message to the Client. DSO-TYPE is TBD-P. DSO-LENGTH 588 is 0. 590 The mDNS Link State Request TLV can only be used as a primary TLV, 591 and requires an acknowledgement. The acknowledgment does not contain 592 a Link Available TLV: it is just a response to the Link State Request 593 message. 595 8.7. Link State Discontinue 597 The Link State Discontinue TLV requests that the Discovery Relay stop 598 reporting on the availability of links supported by the relay. This 599 cancels the effect of a Link State Request TLV. DSO-TYPE is TBD-Q. 600 DSO-LENGTH is 0. 602 The mDNS Link State Discontinue TLV can only be used as a primary 603 TLV, and is not acknowledged. 605 8.8. Link Available 607 The Link Available TLV is used by Discovery Relays to indicate to 608 Clients that a new link has become available. The format is the same 609 as the Link Identifier TLV. DSO-TYPE is TBD-V. The Link Available 610 TLV may be accompanied by one or more Link Prefix TLVs which indicate 611 IP prefixes the Relay knows to be present on the link. 613 The mDNS Link Available TLV can only be used as a primary TLV, and is 614 not acknowledged. 616 8.9. Link Unavailable 618 The Link Unavailable TLV is used by Discovery Relays to indicate to 619 Clients that an existing link has become unavailable. The format is 620 the same as the Link Identifier TLV. DSO-TYPE is TBD-U. 622 The mDNS Link Unavailable TLV can only be used as a primary TLV, and 623 is not acknowledged. 625 8.10. Link Prefix 627 The Link Prefix TLV represents an IP address or prefix configured on 628 a link. The length is 17 for an IPv6 address or prefix, and 5 for an 629 IPv4 address or prefix. The TLV consists of a prefix length, between 630 0 and 32 for IPv4 or between 0 and 128 for IPv6, represented as a 631 single byte. This is followed by the IP address, either four or 632 sixteen bytes. DSO-TYPE is TBD-K. 634 The Link Prefix TLV can only be used as a secondary TLV. 636 9. Provisioning 638 In order for a Discovery Proxy to use Discovery Relays, it must be 639 configured with sufficient information to identify multicast links on 640 which service discovery is to be supported and, if it is not running 641 on a host that is directly connected to those multicast links, 642 connect to Discovery Relays supporting those multicast links. 644 A Discovery Relay must be configured both with a set of multicast 645 links to which the host on which it is running is connected, on which 646 mDNS relay service is to be provided, and also with a list of one or 647 more Clients authorized to use it. 649 On a network supporting DNS Service Discovery using Discovery Relays, 650 more than one different Discovery Relay implementation may be 651 present. While it may be that only a single Discovery Proxy is 652 present, that implementation will need to be able to be configured to 653 interoperate with all of the Discovery Relays that are present. 654 Consequently, it is necessary that a standard set of configuration 655 parameters be defined for both Discovery Proxies and Discovery 656 Relays. 658 DNS Service Discovery generally operates within a constrained set of 659 links, not across the entire internet. This section assumes that 660 what will be configured will be a limited set of links operated by a 661 single entity or small set of cooperating entities, among which 662 services present on each link should be available to users on that 663 link and every other link. This could be, for example, a home 664 network, a small office network, or even a network covering an entire 665 building or small set of buildings. The set of Discovery Proxies and 666 Discovery Relays within such a network will be referred to in this 667 section as a 'Discovery Domain'. 669 Depending on the context, several different candidates for 670 configuration of Discovery Proxies and Discovery Relays may be 671 applicable. The simplest such mechanism is a manual configuration 672 file, but regardless of provisioning mechanism, certain configuration 673 information needs to be communicated to the devices, as outlined 674 below. 676 In the example we provide here, we only refer to configuring of IP 677 addresses, private keys and certificates. It is also possible to use 678 FQDNs to identify servers; this then allows for the use of DANE 679 ([RFC8310] Section 8.2) or PKIX authentication [RFC6125]. Which 680 method is used is to some extent up to the implementation, but at a 681 minimum, it should be possible to associate an IP address with a 682 self-signed certificate, and it should be possible to validate both 683 self-signed and PKIX-authenticated certificates, with PKIX, DANE or a 684 pre-configured trust anchor. 686 9.1. Provisioned Objects 688 Three types of objects must be described in order for Discovery 689 Proxies and Discovery Relays to be provisioned: Discovery Proxies, 690 Multicast Links, and Discovery Relays. "Human-readable" below means 691 actual words or proper names that will make sense to an untrained 692 human being. "Machine-readable" means a name that will be used by 693 machines to identify the entity to which the name refers. Each 694 entity must have a machine-readable name and may have a human- 695 readable name. No two entities can have the same human-readable 696 name. Similarly, no two entities can have the same machine-readable 697 name. 699 9.1.1. Multicast Link 701 The description of a multicast link consists of: 703 link-identifier A 32-bit identifier that uniquely identifies that 704 link within the Discovery Domain. Each link MUST have exactly one 705 such identifier. Link Identifiers do not have any special 706 semantics, and are not intended to be human-readable. 708 ldh-name A fully-qualified domain name for the multicast link that 709 is used to form an LDH domain name as described in section 5.3 of 710 the Discovery Proxy specification [I-D.ietf-dnssd-hybrid]. This 711 name is used to identify the link during provisioning, and must be 712 present. 714 hr-name A human-readable user-friendly fully-qualified domain name 715 for the multicast link. This name MUST be unique within the 716 Discovery Domain. Each multicast link MUST have exactly one such 717 name. The hr-name MAY be the same as the ldh-name. (The hr-name 718 is allowed to contain spaces, punctuation and rich text, but it is 719 not required to do so.) 721 The ldh-name and hr-name can be used to form the LDH and human- 722 readable domain names as described in [I-D.ietf-dnssd-hybrid], 723 section 5.3. 725 Note that the ldh-name and hr-name can be used in two different ways. 727 On a small home network with little or no human administrative 728 configuration, link names may be directly visible to the user. For 729 example, a search in 'home.arpa' on a small home network may discover 730 services on both ethernet.home.arpa and wi-fi.home.arpa. In the case 731 of a home user who has one Ethernet-connected printer and one Wi-Fi- 732 connected printer, discovering that they have one printer on 733 ethernet.home.arpa and another on wi-fi.home.arpa is understandable 734 and meaningful. 736 On a large corporate network with hundreds of Wi-Fi access points, 737 the individual link names of the hundreds of multicast links are less 738 likely to be useful to end users. In these cases, Discovery Broker 739 functionality [I-D.sctl-discovery-broker] is used to translate the 740 many link names to something more meaningful to users. For example, 741 in a building with 50 Wi-Fi access points, each with their own link 742 names, services on all the different physical links may be presented 743 to the user as appearing in 'headquarters.example.com'. In this 744 case, the individual link names can be thought of similar to MAC 745 addresses or IPv6 addresses. They are used internally by the 746 software as unique identifiers, but generally are not exposed to end 747 users. 749 9.1.2. Discovery Proxy 751 The description of a Discovery Proxy consists of: 753 name a machine-readable name used to reference this Discovery Proxy 754 in provisioning. 756 hr-name an optional human-readable name which can appear in 757 provisioning, monitoring and debugging systems. Must be unique 758 within a Discovery Domain. 760 certificate a certificate that identifies the Discovery Proxy. This 761 certificate can be shared across services on the Discovery Proxy 762 Host. The public key in the certificate is used both to uniquely 763 identify the Discovery Proxy and to authenticate connections from 764 it. The certificate should be signed by its own private key. 766 private-key the private key corresponding to the public key in the 767 certificate. 769 source-ip-addresses a list of IP addresses that may be used by the 770 Discovery Proxy when connecting to Discovery Relays. These 771 addresses should be addresses that are configured on the Discovery 772 Proxy Host. They should not be temporary addresses. All such 773 addresses must be reachable within the Discovery Domain. 775 public-ip-addresses a list of IP addresses that a Discovery Proxy 776 listens on to receive requests from clients. This is not used for 777 interoperation with Discovery Relays, but is mentioned here for 778 completeness: the list of addresses listened on for incoming 779 client requests may differ from the 'source-ip-addresses' list of 780 addresses used for issuing outbound connection requests to 781 Discovery Relays. If any of these addresses are reachable from 782 outside of the Discovery Domain, services in that domain will be 783 discoverable outside of the domain. 785 multicast links a list of multicast links on which this Discovery 786 Proxy is expected to provide service 788 The private key should never be distributed to other hosts; all of 789 the other information describing a Discovery Proxy can be safely 790 shared with Discovery Relays. 792 In some configurations it may make sense for the Discovery Relay not 793 to have a list of links, but simply to support the set of all links 794 available on relays to which the Discovery Proxy is configured to 795 communicate. 797 9.1.3. Discovery Relay 799 The description of a Discovery Relay consists of: 801 name a required machine-readable identifier used to reference the 802 relay 804 hr-name an optional human-readable name which can appear in 805 provisioning, monitoring and debugging systems. Must be unique 806 within a Discovery Domain. 808 certificate a certificate that identifies the Discovery Relay. This 809 certificate can be shared across services on the Discovery Relay 810 Host. Indeed, if a Discovery Proxy and Discovery Relay are 811 running on the same host, the same certificate can be used for 812 both. The public key in the certificate uniquely identifies the 813 Discovery Relay and is used by the Discovery Proxy to verify that 814 it is talking to the intended Discovery Relay after a TLS 815 connection has been established. The certificate must either be 816 signed by its own key, or have a signature chain that can be 817 validated using PKIX authentication [RFC6125]. 819 private-key the private key corresponding to the public key in the 820 certificate. 822 listen-tuple a list of IP address/port tuples that may be used to 823 connect to the Discovery Relay. The relay may be configured to 824 listen on all addresses on a single port, but this is not 825 required, so the port as well as the address must be specified. 827 multicast links a list of multicast links to which this relay is 828 physically connected. 830 The private key should never be distributed to other hosts; all of 831 the other information describing a Discovery Relay can be safely 832 shared with Discovery Proxies. 834 In some cases a Relay may not be configured with a static list of 835 links, but may simply discover links by monitoring the set of 836 available interfaces on the host on which the Relay is running. In 837 that case, the relay could be configured to identify links based on 838 the names of network interfaces, or based on the set of available 839 prefixes seen on those interfaces. The details of this sort of 840 configuration are not specified in this document. 842 9.2. Configuration Files 844 For this discussion, we assume the simplest possible means of 845 configuring Discovery Proxies and Discovery Relays: the configuration 846 file. Any environment where changes will happen on a regular basis 847 will either require some automatic means of generating these 848 configuration files as the network topology changes, or will need to 849 use a more automatic method for configuration, such as HNCP 850 [RFC7788]. 852 There are many different ways to organize configuration files. This 853 discussion assumes that multicast links, relays and proxies will be 854 specified as objects, as described above, perhaps in a master file, 855 and then the specific configuration of each proxy or relay will 856 reference the set of objects in the master file, referencing objects 857 by name. This approach is not required, but is simply shown as an 858 example. In addition, the private keys for each proxy or relay must 859 appear only in that proxy or relay's configuration file. 861 The master file contains a list of Discovery Relays, Discovery 862 Proxies and Multicast Links. Each object has a name and all the 863 other data associated with it. We do not formally specify the format 864 of the file, but it might look something like this: 866 Relay upstairs 867 certificate xxx 868 listen-tuple 192.0.2.1 1917 869 listen-tuple fd00::1 1917 870 link upstairs-wifi 871 link upstairs-wired 872 client-whitelist main 874 Relay downstairs 875 certificate yyy 876 listen-tuple 192.51.100.1 2088 877 listen-tuple fd00::2 2088 878 link downstairs-wifi 879 link downstairs-wired 880 client-whitelist main 882 Proxy main 883 certificate zzz 884 address 203.1.113.1 886 Link upstairs-wifi 887 id 1 888 name Upstairs Wifi 890 Link upstairs-wired 891 id 2 892 hr-name Upstairs Wired 894 Link downstairs-wifi 895 id 3 896 name Downstairs Wifi 898 Link downstairs-wired 899 id 4 900 hr-name Downstairs Wired 902 9.3. Discovery Proxy Private Configuration 904 The Discovery Proxy configuration contains enough information to 905 identify which Discovery Proxy is being configured, enumerate the 906 list of multicast links it is intended to serve, and provide keying 907 information it can use to authenticate to Discovery Relays. It may 908 also contain custom information about the port and/or IP address(es) 909 on which it will respond to DNS queries. 911 An example configuration, following the convention used in this 912 section, might look something like this: 914 Proxy main 915 private-key zzz 916 subscribe upstairs-wifi 917 subscribe downstairs-wifi 918 subscribe upstairs-wired 919 subscribe downstairs-wired 921 When combined with the master file, this configuration is sufficient 922 for the Discovery Proxy to identify and connect to the Discovery 923 Relays that serve the links it is configured to support. 925 9.4. Discovery Relay Private Configuration 927 The Discovery Relay configuration just needs to tell the Discovery 928 Relay what name to use to find its configuration in the master file, 929 and what the private key is corresponding to its certificate (public 930 key) in the master file. For example: 932 Relay Downstairs 933 private-key yyy 935 10. Security Considerations 937 Part of the purpose of the Multicast DNS Discovery Relay protocol is 938 to place a simple relay, analogous to a BOOTP relay, into routers and 939 similar devices that may not be updated frequently. The BOOTP 940 [RFC0951] protocol has been around since 1985, and continues to be 941 useful today. The BOOTP protocol uses no encryption, and in many 942 enterprise networks this is considered acceptable. In contrast, the 943 Discovery Relay protocol requires TLS 1.3. A concern is that after 944 20 or 30 years, TLS 1.3, or some of the encryption algorithms it 945 uses, may become obsolete, rendering devices that require it 946 unusable. Our assessment is that TLS 1.3 probably will be around for 947 many years to come. TLS 1.0 [RFC2246] was used for about a decade, 948 and similarly TLS 1.2 [RFC5246] was also used for about a decade. We 949 expect TLS 1.3 [I-D.ietf-tls-tls13] to have at least that lifespan. 950 In addition, recent IETF efforts are pushing for better software 951 update practices for devices like routers, for other security 952 reasons, making it likely that in ten years time it will be less 953 common to be using routers that haven't had a software update for ten 954 years. However, authors of encryption specifications and libraries 955 should be aware of the potential backwards compatibility issues if an 956 encryption algorithm becomes deprecated. This specification 957 RECOMMENDS that if an encryption algorithm becomes deprecated, then 958 rather than remove that encryption algorithm entirely, encryption 959 libraries should disable that encryption algorithm by default, but 960 leave the code present with an option for client software to enable 961 it in special cases, such as a recent Client talking to an ancient 962 Discovery Relay. Using no encryption, like BOOTP, would eliminate 963 this backwards compatibility concern, but we feel that in such a 964 future hypothetical scenario, using even a weak encryption algorithm 965 still makes passive eavesdropping and tampering harder, and is 966 preferable to using no encryption at all. 968 11. IANA Considerations 970 The IANA is kindly requested to update the DSO Type Codes Registry 971 [I-D.ietf-dnsop-session-signal] by allocating codes for each of the 972 TBD type codes listed in the following table, and by updating this 973 document, here and in Section 8. Each type code should list this 974 document as its reference document. 976 +--------+----------+---------------------------+ 977 | Opcode | Status | Name | 978 +--------+----------+---------------------------+ 979 | TBD-R | Standard | Link Data Request | 980 | TBD-D | Standard | Link Data Discontinue | 981 | TBD-L | Standard | Link Identifier | 982 | TBD-M | Standard | Encapsulated mDNS Message | 983 | TBD-S | Standard | IP Source | 984 | TBD-P | Standard | Link State Request | 985 | TBD-Q | Standard | Link State Discontinue | 986 | TBD-V | Standard | Link Available | 987 | TBD-U | Standard | Link Unavailable | 988 | TBD-K | Standard | Link Prefix | 989 +--------+----------+---------------------------+ 991 DSO Type Codes to be allocated 993 12. Acknowledgments 995 To be completed... 997 13. References 999 13.1. Normative References 1001 [I-D.ietf-dnsop-session-signal] 1002 Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1003 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 1004 draft-ietf-dnsop-session-signal-20 (work in progress), 1005 December 2018. 1007 [I-D.ietf-dnssd-hybrid] 1008 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 1009 Service Discovery", draft-ietf-dnssd-hybrid-08 (work in 1010 progress), March 2018. 1012 [I-D.ietf-tls-tls13] 1013 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1014 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 1015 March 2018. 1017 [I-D.sctl-discovery-broker] 1018 Cheshire, S. and T. Lemon, "Service Discovery Broker", 1019 draft-sctl-discovery-broker-00 (work in progress), July 1020 2017. 1022 [RFC1035] Mockapetris, P., "Domain names - implementation and 1023 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1024 November 1987, . 1026 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 1027 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 1028 1992, . 1030 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1031 Verification of Domain-Based Application Service Identity 1032 within Internet Public Key Infrastructure Using X.509 1033 (PKIX) Certificates in the Context of Transport Layer 1034 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1035 2011, . 1037 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1038 and A. Bierman, Ed., "Network Configuration Protocol 1039 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1040 . 1042 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1043 DOI 10.17487/RFC6762, February 2013, 1044 . 1046 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1047 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1048 . 1050 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1051 D. Wessels, "DNS Transport over TCP - Implementation 1052 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1053 . 1055 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1056 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1057 2016, . 1059 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1060 for DNS over TLS and DNS over DTLS", RFC 8310, 1061 DOI 10.17487/RFC8310, March 2018, 1062 . 1064 13.2. Informative References 1066 [AdFam] "IANA Address Family Numbers Registry", 1067 . 1070 [I-D.ietf-mboned-ieee802-mcast-problems] 1071 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 1072 Zuniga, "Multicast Considerations over IEEE 802 Wireless 1073 Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work 1074 in progress), November 2018. 1076 [NOTSENT] Dumazet, E., "TCP_NOTSENT_LOWAT socket option", July 2013, 1077 . 1079 [PRIO] Chan, W., "Prioritization Only Works When There's Pending 1080 Data to Prioritize", January 2014, 1081 . 1084 [RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, 1085 DOI 10.17487/RFC0951, September 1985, 1086 . 1088 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1089 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1090 . 1092 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1093 (TLS) Protocol Version 1.2", RFC 5246, 1094 DOI 10.17487/RFC5246, August 2008, 1095 . 1097 [TR-069] Broadband Forum, "CPE WAN Management Protocol", November 1098 2013, . 1101 Authors' Addresses 1103 Ted Lemon 1104 Nibbhaya Consulting 1105 P.O. Box 958 1106 Brattleboro, Vermont 05301 1107 United States of America 1109 Email: mellon@fugue.com 1111 Stuart Cheshire 1112 Apple Inc. 1113 One Apple Park Way 1114 Cupertino, California 95014 1115 USA 1117 Phone: +1 (408) 996-1010 1118 Email: cheshire@apple.com