idnits 2.17.1 draft-sctl-advertising-proxy-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (13 July 2020) is 1384 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) ** Downref: Normative reference to an Informational RFC: RFC 6760 ** Downref: Normative reference to an Informational draft: draft-sctl-service-registration (ref. 'SRP') == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-11 == Outdated reference: A later version (-04) exists of draft-ietf-dnssd-mdns-relay-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSSD S. Cheshire 3 Internet-Draft T. Lemon 4 Intended status: Standards Track Apple Inc. 5 Expires: 14 January 2021 13 July 2020 7 Advertising Proxy for DNS-SD Service Registration Protocol 8 draft-sctl-advertising-proxy-00 10 Abstract 12 An Advertising Proxy allows a device that accepts service registra- 13 tions using Service Registration Protocol (SRP) to make those regis- 14 trations visible to legacy clients that only implement Multicast DNS. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 14 January 2021. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 1. Introduction 49 DNS-Based Service Discovery [RFC6763] [ROADMAP] was designed to 50 facilitate Zero Configuration IP Networking [RFC6760] [ZC]. 51 When used with Multicast DNS [RFC6762] with ".local" domain names 52 [RFC6761] this works well on a single link (a single broadcast 53 domain). 55 There is also a desire to have DNS-Based Service Discovery work 56 between multiple links that aren't part of the same broadcast domain 57 [RFC7558]. Even within a single Wi-Fi broadcast domain it is 58 beneficial to reduce multicast traffic, because, in comparison to 59 Wi-Fi unicast traffic, Wi-Fi multicast is inefficient, slow, and 60 unreliable [MCAST]. 62 There are three variant ways that this move to greater use of unicast 63 is achieved. 65 One variant is pure end-to-end unicast, with services using unicast 66 Service Registration Protocol [SRP] to register with a service 67 registry, and clients using unicast DNS Push Notifications [RFC8765] 68 over DNS Stateful Operations [RFC8490] to communicate with the 69 service registry to discover and track changes to those registered 70 services. 72 A second variant is a hybrid approach that facilitates legacy devices 73 that only implement link-local Multicast DNS (like your ten-year-old 74 network laser printer) having their services discovered by remote 75 clients, using a unicast DNS Push Notifications session to a 76 Discovery Proxy [RFC8766]. 78 The third variant, documented here, is a logical complement to the 79 second variant. It enables legacy clients (that only implement link- 80 local Multicast DNS) to discover services registered (using unicast) 81 with a service registry. The service registry accepts service 82 registrations using unicast Service Registration Protocol [SRP], and 83 makes those service registrations visible, both to remote clients 84 using unicast DNS Push Notifications [RFC8765] and, using the 85 Advertising Proxy mechanism documented here, to local clients using 86 Multicast DNS [RFC6762]. 88 1.1. Conventions and Terminology Used in This Document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in 93 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 2. Advertising Proxy 98 An Advertising Proxy can be a component of any DNS authoritative 99 server, though it logically makes most sense as a component of a 100 service registry (a DNS authoritative server that implements Service 101 Registration Protocol [SRP]). A client can send registration 102 requests for any valid DNS records to a service registry, though in 103 practice the most common use is to register the PTR, SRV and TXT 104 records that describe a DNS-SD service [RFC6763]. 106 When a service registry accepts a registration request for DNS 107 records, a service registry that implements an Advertising Proxy also 108 advertises equivalent records using Multicast DNS on one or more 109 configured local multicast-capable interfaces. An Advertising Proxy 110 could also advertise on one or more configured remote multicast- 111 capable interfaces using a Multicast DNS Relay [RELAY]. For the 112 purposes of this document, a local multicast-capable interface 113 directly attached to the host and a remote multicast-capable 114 interface connected via a relay are considered to be equivalent. 116 2.1. Name Conflicts 118 In the event that an SRP client attempts to register a record with a 119 name that was already created in that registry by a different SRP 120 client, or is otherwise disallowed by policy, a name conflict is 121 reported and the new client is required to choose a new name. 123 Similarly, Multicast DNS implements first-come-first-served name 124 allocation. When a registered record is advertised using Multicast 125 DNS it may suffer a name conflict if a different Multicast DNS record 126 with that name already exists on that link. In the case of network 127 failures, Multicast DNS can also signal name conflicts at a later 128 time during the life of a record registration. For example, if the 129 network link is partitioned at the time of record registration, the 130 name conflict may not be discovered until later when the partition is 131 healed. 133 Specifically, a name conflict can occur: 135 1. During the SRP validation process, because 136 another SRP client has already registered the same name. 138 2. Immediately while the Advertising Proxy is registering the name. 140 3. After the name has been successfully registered, 141 but before the response has been sent to the client. 143 4. After the initial response has been sent to the client. 145 In the first three cases, the client can be notified of the conflict 146 at the time of registration, and is expected to choose a new name. 147 In the last case, SRP clients must be coded defensively to handle the 148 case where an apparently successful record registration is later 149 determined to be in conflict, just as existing Multicast DNS clients 150 have to be coded defensively to handle late conflicts gracefully. 151 With a sleepy SRP client there may be no way to notify it of the 152 conflict until it next re-registers. In this case, the service 153 registry with Advertising Proxy capability is responsible for 154 selecting a new name. The service registry sends the client the name 155 it chose when it next renews. 157 The registration process has several steps. First the hostname 158 claimed by the SRP client must be registered. Once this has 159 succeeded, the Advertising Proxy can register all of the service 160 instances that point to that hostname. When all of these 161 registrations have succeeded, the service registry can finally send 162 its response to the SRP client. If any of them fail, they must all 163 be removed and the client notified of the failure. If the failure is 164 a result of a name conflict, the response code should be YXDOMAIN. 165 Other SRP failures are documented in the SRP specification. Any 166 other failure returns SERVFAIL. 168 2.2. Data Translation 170 As with a Discovery Proxy [RFC8766] some translation needs to be 171 performed before the Advertising Proxy makes the registered unicast 172 data visible using Multicast DNS. Specifically, the unicast DNS 173 domain name suffix configured for Advertising Proxy use is stripped 174 off and replaced with the top-level label "local". 176 2.3. No Text-Encoding Translation 178 As with a Discovery Proxy [RFC8766], an Advertising Proxy does no 179 translation between text encodings [RFC6055]. Specifically, an 180 Advertising Proxy does no translation between Punycode encoding 181 [RFC3492] and UTF-8 encoding [RFC3629], either in the owner name of 182 DNS records or anywhere in the RDATA of DNS records (such as the 183 RDATA of PTR records, SRV records, NS records, or other record types 184 like TXT, where it is ambiguous whether the RDATA may contain DNS 185 names). All bytes are treated as-is with no attempt at text-encoding 186 translation. A server implementing DNS-based Service Discovery 187 [RFC6763] will use UTF-8 encoding for its unicast DNS-based record 188 registrations, which the Advertising Proxy passes through without any 189 text-encoding translation to the Multicast DNS subsystem. Queries 190 from peers on the configured multicast-capable interface are answered 191 directly from the advertised data without any text-encoding 192 translation. 194 2.4. No Address Suppression 196 Unlike a Discovery Proxy [RFC8766], an Advertising Proxy does not 197 need to selectively suppress link-local [RFC3927] [RFC4862] or other 198 addresses. Since the clients of the service registry are registering 199 their records in a unicast DNS namespace, there is a presumption they 200 they will only register addresses with sufficient scope to be usable 201 by the anticipated clients. No further filtering or suppression by 202 the service registry is required. 204 2.5. No Support for Reconfirm 206 For network efficiency, Multicast DNS [RFC6762] uses fairly long 207 record lifetimes (typically 75 minutes). When a client is unable to 208 reach a service that it discovered, Multicast DNS provides a 209 "reconfirm" mechanism that enables the client to signal to the 210 Multicast DNS subsystem that its cached data may be suspect, which 211 causes the Multicast DNS subsystem to reissue queries, and remove the 212 stale records if the queries are not answered. 214 Similarly, when using unicast service discovery with a Discovery 215 Proxy [RFC8766], the DNS Push Notifications [RFC8765] protocol 216 provides the RECONFIRM mechanism to signal that the Discovery Proxy 217 should perform a local Multicast DNS reconfirm operation to re-verify 218 the validity of the records. 220 When an Advertising Proxy is used, to support legacy clients that 221 only implement Multicast DNS, reconfirm operations have no effect. 222 If a device uses unicast Service Registration Protocol [SRP] to 223 register its services with a service registry with Advertising Proxy 224 capability, and the device then gets disconnected from the network, 225 the Advertising Proxy will continue to advertise those records until 226 the registrations expire. If a client discovers the service instance 227 using Multicast DNS and is unable to reach it, and uses a Multicast 228 DNS reconfirm operation to re-verify the validity of the records, 229 then the Advertising Proxy will continue to answer on behalf of the 230 departed device until the record registrations expire. The 231 Advertising Proxy has no reliable way to determine whether the 232 additional Multicast DNS queries are due to a reconfirm operation, or 233 due to other routine causes, like a client being rebooted, or 234 disconnecting and then reconnecting to the network. The service 235 registry has no reliable automatic way to determine whether a device 236 that registered records has failed or disconnected from the network. 237 Particularly with sleepy battery powered devices, the service 238 registry does not know what active duty cycle any given service is 239 expected to provide. 241 Consequently, reconfirm operations are not supported with an 242 Advertising Proxy. In cases where use of the reconfirm mechanism is 243 important, clients should be upgraded to use the unicast DNS Push 244 Notifications [RFC8765] protocol's RECONFIRM message. This RECONFIRM 245 message provides an unambiguous signal to the service registry that 246 it may be retaining stale records. (A future update to the Service 247 Registration Protocol document [SRP] will consider ways that this 248 unambiguous signal can be used to trigger expedited removal of stale 249 data.) 251 3. Security Considerations 253 An Advertising Proxy may made data visible to eavesdroppers on the 254 configured multicast-capable link(s). 256 4. IANA Considerations 258 This document has no IANA actions. 260 5. References 262 5.1. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 270 to Replace the AppleTalk Name Binding Protocol (NBP)", 271 RFC 6760, DOI 10.17487/RFC6760, February 2013, 272 . 274 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 275 RFC 6761, DOI 10.17487/RFC6761, February 2013, 276 . 278 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 279 DOI 10.17487/RFC6762, February 2013, 280 . 282 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 283 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 284 . 286 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 287 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 288 May 2017, . 290 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 291 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 292 RFC 8490, DOI 10.17487/RFC8490, March 2019, 293 . 295 [RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 296 RFC 8765, DOI 10.17487/RFC8765, June 2020, 297 . 299 [SRP] Cheshire, S. and T. Lemon, "Service Registration Protocol 300 for DNS-Based Service Discovery", Work in Progress, 301 Internet-Draft, draft-sctl-service-registration-02, 15 302 July 2018, . 305 5.2. Informative References 307 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 308 for Internationalized Domain Names in Applications 309 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 310 . 312 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 313 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 314 2003, . 316 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 317 Configuration of IPv4 Link-Local Addresses", RFC 3927, 318 DOI 10.17487/RFC3927, May 2005, 319 . 321 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 322 Address Autoconfiguration", RFC 4862, 323 DOI 10.17487/RFC4862, September 2007, 324 . 326 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 327 Encodings for Internationalized Domain Names", RFC 6055, 328 DOI 10.17487/RFC6055, February 2011, 329 . 331 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 332 "Requirements for Scalable DNS-Based Service Discovery 333 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 334 DOI 10.17487/RFC7558, July 2015, 335 . 337 [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 338 Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 339 2020, . 341 [MCAST] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 342 Zuniga, "Multicast Considerations over IEEE 802 Wireless 343 Media", Work in Progress, Internet-Draft, draft-ietf- 344 mboned-ieee802-mcast-problems-11, 11 December 2019, 345 . 348 [RELAY] Lemon, T. and S. Cheshire, "Multicast DNS Discovery 349 Relay", Work in Progress, Internet-Draft, draft-ietf- 350 dnssd-mdns-relay-02, 11 March 2019, 351 . 354 [ROADMAP] Cheshire, S., "Service Discovery Road Map", Work in 355 Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03, 356 23 October 2018, . 359 [ZC] Cheshire, S. and D. H. Steinberg, "Zero Configuration 360 Networking: The Definitive Guide", O'Reilly Media, Inc., 361 ISBN 0-596-10100-7, December 2005. 363 Authors' Addresses 365 Stuart Cheshire 366 Apple Inc. 367 One Apple Park Way 368 Cupertino, California 95014 369 United States of America 371 Phone: +1 (408) 996-1010 372 Email: cheshire@apple.com 374 Ted Lemon 375 Apple Inc. 376 One Apple Park Way 377 Cupertino, California 95014 378 United States of America 380 Phone: +1 (408) 996-1010 381 Email: elemon@apple.com