idnits 2.17.1 draft-lynn-homenet-site-mdns-01.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 date (September 25, 2012) is 4230 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 338, but not defined == Unused Reference: 'RFC5226' is defined on line 442, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Lynn 3 Internet-Draft Consultant 4 Intended status: Experimental D. Sturek 5 Expires: March 29, 2013 Grid2Home 6 September 25, 2012 8 Extended Multicast DNS 9 draft-lynn-homenet-site-mdns-01 11 Abstract 13 Multicast DNS (mDNS) provides the ability to perform DNS-like 14 operations on the local link in the absence of any conventional 15 unicast DNS server. Extended mDNS (xmDNS) extends the specification 16 of mDNS to site-local scope in order to support multi-hop LANs that 17 forward multicast packets but do not provide a unicast DNS service. 19 Like mDNS, xmDNS designates a portion of the DNS namespace to apply 20 to the site-local network and specifies rules for its use. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 29, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions and Terminology Used in this Document . . . . . . 3 58 3. Extended Multicast DNS Names . . . . . . . . . . . . . . . . . 4 59 4. Reverse Address Mapping . . . . . . . . . . . . . . . . . . . 4 60 5. Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. Responding . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7. Traffic Reduction . . . . . . . . . . . . . . . . . . . . . . 5 63 8. Probing and Announcing on Startup . . . . . . . . . . . . . . 6 64 9. Conflict Resolution . . . . . . . . . . . . . . . . . . . . . 6 65 10. Resource Record TTL Values and Cache Coherency . . . . . . . . 6 66 11. Source Address Check . . . . . . . . . . . . . . . . . . . . . 6 67 12. Special Characteristics of Extended Multicast DNS Domains . . 6 68 13. Enabling and Disabling Multicast DNS . . . . . . . . . . . . . 7 69 14. Considerations for Multiple Interfaces . . . . . . . . . . . . 7 70 15. Considerations for Multiple Responders on the Same Machine . . 7 71 16. Multicast DNS Character Set . . . . . . . . . . . . . . . . . 7 72 17. Multicast DNS Message Size . . . . . . . . . . . . . . . . . . 7 73 18. Multicast DNS Message Format . . . . . . . . . . . . . . . . . 7 74 19. Summary of Differences Between Multicast DNS and Unicast 75 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 20. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 21. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 23. Domain Name Reservation Considerations . . . . . . . . . . . . 8 80 24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 81 25. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 25.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 25.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 Multicast DNS (mDNS) provides the ability to perform DNS-like 89 operations on the local link in the absence of any conventional 90 unicast DNS server. Extended mDNS (xmDNS) extends the specification 91 of mDNS to site-local scope in order to support multi-hop LANs that 92 forward multicast packets but do not provide a unicast DNS service. 94 Like mDNS, xmDNS designates a portion of the DNS namespace to apply 95 to the site-local network and specifies rules for its use. 97 Extended mDNS implementations MUST support all of the features of 98 Multicast DNS [I-D.cheshire-dnsext-multicastdns] in addition to the 99 changes specified in this document. The organization of this 100 document is identical to mDNS, with changes specified section by 101 section below. It is important to note that xmDNS is not intended to 102 replace wide-area DNS-Based Service Discovery (DNS-SD) 103 [I-D.cheshire-dnsext-dns-sd], but rather to fill a gap between the 104 link-local scope of mDNS and the highly scalable DNS-SD. In 105 particular, the design target anticipates multi-hop residential LANs 106 such as ethernet to wireless mesh. 108 2. Conventions and Terminology Used in this Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in "Key words for use in 113 RFCs to Indicate Requirement Levels" [RFC2119]. 115 When this document uses the term "Multicast DNS", it should be taken 116 to mean: "Clients performing DNS-like queries for DNS-like resource 117 records by sending DNS-like UDP query and response packets on the 118 local link over IP Multicast to UDP port 5353." 120 This document uses the term "Extended Multicast DNS" to indicate the 121 distribution of mDNS queries and responses to all links that comprise 122 the site-local area network. Exceptions to normal mDNS operation are 123 specified in subsequent sections. 125 This document uses the term "host name" in the strict sense to mean a 126 fully-qualified domain name that has an IPv4 or IPv6 address record. 127 It does not use the term "host name" in the commonly used but 128 incorrect sense to mean just the first DNS label of a host's fully 129 qualified domain name. 131 A DNS (or mDNS) packet contains an IP TTL in the IP header, which is 132 effectively a hop-count limit for the packet, to guard against 133 routing loops. Each Resource Record also contains a TTL, which is 134 the number of seconds for which the Resource Record may be cached. 135 This document uses the term "IP TTL" to refer to the IP header TTL 136 (hop limit), and the term "RR TTL" or just "TTL" to refer to the 137 Resource Record TTL (cache lifetime). 139 3. Extended Multicast DNS Names 141 Extended Multicast DNS specifies that the DNS top-level domain 142 ".site." is a special domain with special semantics, namely that any 143 fully-qualified domain name ending in ".site." is site-local, and 144 names within this domain are meaningful only on the site-local area 145 network where they originate. This is analogous to Unique Local IPv6 146 Unicast Address [RFC4193] prefixes, which are site-local and 147 meaningful only on the site where they are defined. 149 Any DNS query for a name ending with ".site." MUST be sent to the 150 xmDNS multicast address (FF05::FB or its IPv4 equivalent 151 239.255.255.TBD). Future versions of this document may specify a 152 method for creating zones under the ".site." top-level domain and 153 mapping these to alternative IPv6 multicast addresses. 155 Note that the ".site." and ".local." domains are functionally 156 disjoint, both from a name space and address space perspective. 157 Hosts wishing to register or discover names in both domains must do 158 so separately. 160 4. Reverse Address Mapping 162 [RFC4193] recommends that queries for D.F.IPV6.ARPA be handled 163 locally. [RFC6303] extends the recommendation to cover other well 164 known IN-ADDR.ARPA and IP6.ARPA zones for which queries should not 165 appear on the public Internet. 167 In the absence of a unicast DNS server in the LAN, any DNS query for 168 a name within the reverse mapping domain ("d.f.ip6.arpa.") for Unique 169 Local IPv6 Unicast addresses [RFC4193] SHOULD be sent to the xmDNS 170 multicast address (FF05::FB or its IPv4 equivalent 239.255.255.TBD). 172 [TBD: See RFC 6303 for an expanded list of domains] 174 5. Querying 176 In cases where the desired scope of a query is the local link, 177 Extended Multicast DNS queries MAY be sent with a link-local 179 [RFC4291] source address to FF05::FB. 181 Otherwise, Extended Multicast DNS queries SHOULD be sent with a 182 Unique Local IPv6 Unicast (ULA) [RFC4193] source address. 184 Extended Multicast DNS queries SHOULD NOT be sent with a Global IPv6 185 Unicast [RFC4291] source address. The Source Address Check rules in 186 Section 11 may not be able to determine whether the query was from an 187 on-site host. 189 6. Responding 191 All Extended Multicast DNS responses (including responses sent via 192 unicast) SHOULD be sent with IP TTL set to 255. 194 Extended Multicast DNS Responders MUST return all available AAAA 195 records with scope equal to or greater than the scope of the source 196 address of the query. Extended Multicast DNS Responders SHOULD NOT 197 include link-local AAAA records unless the source of the query is on 198 the local link. 200 7. Traffic Reduction 202 Provisions of Multicast DNS Traffic Reduction, namely, Known Answer 203 Suppression, Multi-Packet Known Answer Suppression, Duplicate 204 Question Suppression, and Duplicate Answer Suppression SHALL be 205 supported in Extended Multicast DNS with the following exceptions: 207 An Extended Multicast DNS Responder seeing a Multicast DNS Query 208 with the TC (truncated) bit set SHALL defer its response for 1 209 second and then respond within a randomly selected time interval 210 between 0 and 200 ms. 212 If the xmDNS Responder receives additional Known-Answer packets 213 with the TC bit set, it SHOULD extend the delay as necessary to 214 ensure a pause of 1 second (plus a random delay between 0 and 200 215 ms) after the last such packet before it sends its answer. 217 In multi-hop LAN deployments where a single Multicast DNS Query is 218 propagated for longer than 1 second, the xmDNS Responder SHOULD 219 extend the time it defers its response to at least 1 second longer 220 than the maximum propagation time of a single Multicast DNS Query. 222 8. Probing and Announcing on Startup 224 Provisions of Multicast DNS Probing and Announcing SHALL be supported 225 in Extended Multicast DNS. 227 9. Conflict Resolution 229 Provisions of Multicast DNS Conflict Resolution SHALL be supported in 230 Extended Multicast DNS. When creating address records (i.e. host 231 names) or resource records where uniqueness (or maintenance of some 232 other defined constraint) is desired, xmDNS Responders SHOULD append 233 some relatively unique string (i.e. low order bits of an EUI-64) to 234 the name in order to minimize name conflict resolution traffic. 236 10. Resource Record TTL Values and Cache Coherency 238 Provisions of Resource Record TTL Values and Cache Coherency, namely, 239 Goodbye Packets, Announcements to Flush Outdated Cache Entries, Cache 240 Flush on Topology Change, Cache Flush on Failure indication and 241 Passive Observation of Failure SHALL be supported in Extended 242 Multicast DNS with the following exceptions: 244 Let TimeActive be the time duration that a single multicast request 245 or response is active in a multi-hop LAN deployment instance (in 246 seconds, rounded up to the next integer value). 248 Queriers of Extended Multicast DNS receiving a response with TTL of 249 zero SHOULD set the TTL to 1 plus TimeActive and delete the record 1 250 second plus TimeActive later. 252 For Announcements to Flush Outdated Cache Entries, all timing values 253 stated as "one second" SHOULD be read as "one second plus TimeActive" 254 to address the propagation of multicast packets in a multi-hop LAN 255 instance. 257 11. Source Address Check 259 Source address check must ensure that queries originate from on-site 260 prefixes. All other queries must be silently dropped. 262 12. Special Characteristics of Extended Multicast DNS Domains 264 [TBD] 266 13. Enabling and Disabling Multicast DNS 268 [TBD] 270 14. Considerations for Multiple Interfaces 272 [TBD] 274 15. Considerations for Multiple Responders on the Same Machine 276 [TBD] 278 16. Multicast DNS Character Set 280 [Same as mDNS] 282 17. Multicast DNS Message Size 284 [Same as mDNS] 286 18. Multicast DNS Message Format 288 [Same as mDNS] 290 19. Summary of Differences Between Multicast DNS and Unicast DNS 292 [Same as mDNS] 294 20. IPv6 Considerations 296 An IPv4-only host and an IPv6-only host behave as "ships that pass in 297 the night". Even if they are on the same Ethernet, neither is aware 298 of the other's traffic. For this reason, each physical link may have 299 *two* unrelated ".site." zones, one for IPv4 and one for IPv6. Since 300 for practical purposes, a group of IPv4-only hosts and a group of 301 IPv6-only hosts on the same Ethernet act as if they were on two 302 entirely separate Ethernet segments, it is unsurprising that their 303 use of the ".site." zone should occur exactly as it would if they 304 really were on two entirely separate Ethernet segments. 306 A dual-stack (v4/v6) host can participate in both ".site." zones, and 307 should register its name(s) and perform its lookups using both IPv4 308 and IPv6. This enables it to reach, and be reached by, both IPv4- 309 only and IPv6-only hosts. In effect this acts like a multi-homed 310 host, with one connection to the logical "IPv4 Ethernet segment", and 311 a connection to the logical "IPv6 Ethernet segment". When such a 312 host generates NSEC records, if it is using the same host name for 313 its IPv4 addresses and its IPv6 addresses on that network interface, 314 its NSEC records should indicate that the host name has both A and 315 AAAA records. 317 21. Security Considerations 319 [TBD] 321 22. IANA Considerations 323 IANA has allocated the IPv6 multicast address set FF0X::FB for 324 Multicast DNS [mcast6]. The use of FF02::FB (Link-Local Scope) is 325 described in [I-D.cheshire-dnsext-multicastdns] and the use of 326 address FF05::FB (Site-Local Scope) is defined in this document. 328 When this document is published, IANA should designate a list of 329 domains which are deemed to have only site-local significance, as 330 described in Section 12 of this document ("Special Characteristics of 331 Extended Multicast DNS Domains") [I-D.cheshire-dnsext-special-names]. 333 Specifically, the designated site-local domains are: 335 site. 336 d.f.ip6.arpa. 338 [TBD] This document also requests an IPv4 Scope Relative multicast 339 address in the Local Scope range (239.255.255.0/24) [RFC2365] in 340 order to differentiate xmDNS queries from normal mDNS queries and to 341 facilitate modified xmDNS source address check rules. 343 23. Domain Name Reservation Considerations 345 The two domains listed in Section 22 above and any names falling 346 within those domains (e.g. "MyServer.someZone.site.", 347 "b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0. 348 d.f.ip6.arpa.", "www._http._tcp.site.") are special DNS names 349 [I-D.cheshire-dnsext-special-names] in the following ways: 351 1. Users may use these names as they would other DNS names, entering 352 them anywhere that they would otherwise enter a conventional DNS 353 name, or a dotted decimal IPv4 address, or a literal IPv6 354 address. 356 Since there is no central authority responsible for assigning 357 dot-site names, and all devices on the site-local network are 358 equally entitled to claim any dot-site name, users SHOULD be 359 aware of this and SHOULD exercise appropriate caution. In an 360 untrusted or unfamiliar network environment, users SHOULD be 361 aware that using a name like "www.site" may not actually connect 362 them to the web site they expected, and could easily connect them 363 to a different web page, or even a fake or spoof of their 364 intended web site, designed to trick them into revealing 365 confidential information. As always with networking, end-to-end 366 cryptographic security can be a useful tool. For example, when 367 connecting with ssh, the ssh host key verification process will 368 inform the user if it detects that the identity of the entity 369 they are communicating with has changed since the last time they 370 connected to that name. 372 2. Application software may use these names as they would other 373 similar DNS names, and is not required to recognize the names and 374 treat them specially. Due to the relative ease of spoofing dot- 375 site names, end-to-end cryptographic security remains important 376 when communicating across a local network, just as it is when 377 communicating across the global Internet. 379 3. Name resolution APIs and libraries SHOULD recognize these names 380 as special and SHOULD NOT send queries for these names to their 381 configured (unicast) caching DNS server(s). This is to avoid 382 unnecessary load on the root name servers and other name servers, 383 caused by queries for which those name servers do not have useful 384 non-negative answers to give, and will not ever have useful 385 nonnegative answers to give. 387 4. Caching DNS servers SHOULD recognize these names as special and 388 SHOULD NOT attempt to look up NS records for them, or otherwise 389 query authoritative DNS servers in an attempt to resolve these 390 names. Instead, caching DNS servers SHOULD generate immediate 391 NXDOMAIN responses for all such queries they may receive (from 392 misbehaving name resolver libraries). This is to avoid 393 unnecessary load on the root name servers and other name servers. 395 5. Authoritative DNS servers SHOULD NOT by default be configurable 396 to answer queries for these names, and, like caching DNS servers, 397 SHOULD generate immediate NXDOMAIN responses for all such queries 398 they may receive. DNS server software MAY provide a 399 configuration option to override this default, for testing 400 purposes or other specialized uses. 402 6. DNS server operators SHOULD NOT attempt to configure 403 authoritative DNS servers to act as authoritative for any of 404 these names. Configuring an authoritative DNS server to act as 405 authoritative for any of these names may not, in many cases, 406 yield the expected result, since name resolver libraries and 407 caching DNS servers SHOULD NOT send queries for those names (see 408 3 and 4 above), so such queries SHOULD be suppressed before they 409 even reach the authoritative DNS server in question, and 410 consequently it will not even get an opportunity to answer them. 412 7. DNS Registrars MUST NOT allow any of these names to be registered 413 in the normal way to any person or entity. These names are 414 reserved protocol identifiers with special meaning and fall 415 outside the set of names available for allocation by registrars. 416 Attempting to allocate one of these names as if it were a normal 417 DNS domain name will probably not work as desired, for reasons 3, 418 4, and 6 above. 420 24. Acknowledgments 422 We wish to thank the authors of [I-D.cheshire-dnsext-multicastdns] on 423 whose work this document is heavily based. Reviews and comments were 424 provided by Tom Herbst and Ralph Droms. 426 25. References 428 25.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, March 1997. 433 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 434 RFC 2365, July 1998. 436 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 437 Addresses", RFC 4193, October 2005. 439 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 440 Architecture", RFC 4291, February 2006. 442 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 443 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 444 May 2008. 446 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 447 RFC 6303, July 2011. 449 [mcast6] "IPv6 Multicast Address Space Registry", 450 . 453 25.2. Informative References 455 [I-D.cheshire-dnsext-dns-sd] 456 Cheshire, S. and M. Krochmal, "DNS-Based Service 457 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 458 progress), December 2011. 460 [I-D.cheshire-dnsext-multicastdns] 461 Cheshire, S. and M. Krochmal, "Multicast DNS", 462 draft-cheshire-dnsext-multicastdns-15 (work in progress), 463 December 2011. 465 [I-D.cheshire-dnsext-special-names] 466 Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 467 draft-cheshire-dnsext-special-names-03 (work in progress), 468 September 2012. 470 Authors' Addresses 472 Kerry Lynn 473 Consultant 475 Phone: +1 978 460 4253 476 Email: kerlyn@ieee.org 478 Don Sturek 479 Grid2Home 480 404 Camino Del Rio South, Suite 600 481 San Diego, CA 482 USA 484 Phone: +1 619 504 3615 485 Email: d.sturek@att.net