idnits 2.17.1 draft-lynn-dnsext-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 (March 14, 2011) is 4793 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 294, but not defined == Unused Reference: 'RFC5226' is defined on line 398, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-10 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-14 == Outdated reference: A later version (-03) exists of draft-cheshire-dnsext-special-names-01 Summary: 1 error (**), 0 flaws (~~), 6 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: September 15, 2011 Pacific Gas & Electric 6 March 14, 2011 8 Extended Multicast DNS 9 draft-lynn-dnsext-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 September 15, 2011. 39 Copyright Notice 41 Copyright (c) 2011 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 . . . . . . . . . . . . . . 5 64 9. Conflict Resolution . . . . . . . . . . . . . . . . . . . . . 5 65 10. Resource Record TTL Values and Cache Coherency . . . . . . . . 5 66 11. Source Address Check . . . . . . . . . . . . . . . . . . . . . 5 67 12. Special Characteristics of Extended Multicast DNS Domains . . 6 68 13. Enabling and Disabling Multicast DNS . . . . . . . . . . . . . 6 69 14. Considerations for Multiple Interfaces . . . . . . . . . . . . 6 70 15. Considerations for Multiple Responders on the Same Machine . . 6 71 16. Multicast DNS Character Set . . . . . . . . . . . . . . . . . 6 72 17. Multicast DNS Message Size . . . . . . . . . . . . . . . . . . 6 73 18. Multicast DNS Message Format . . . . . . . . . . . . . . . . . 6 74 19. Summary of Differences Between Multicast DNS and Unicast 75 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 20. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 6 77 21. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 23. Domain Name Reservation Considerations . . . . . . . . . . . . 8 80 24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 81 25. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 25.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 25.2. Informative References . . . . . . . . . . . . . . . . . 10 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 by section 101 below. It is important to note that xmDNS is not intended to replace 102 DNS-SD [I-D.cheshire-dnsext-dns-sd], but rather to fill a gap between 103 the link-local scope of mDNS and the highly scalable DNS-SD. In 104 particular, the design target anticipates multi-subnet residential 105 LANs such as ethernet to wireless mesh. 107 2. Conventions and Terminology Used in this Document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in "Key words for use in 112 RFCs to Indicate Requirement Levels" [RFC2119]. 114 When this document uses the term "Multicast DNS", it should be taken 115 to mean: "Clients performing DNS-like queries for DNS-like resource 116 records by sending DNS-like UDP query and response packets on the 117 local link over IP Multicast to UDP port 5353." 119 This document uses the term "Extended Multicast DNS" to indicate the 120 distribution of mDNS queries and responses to all links that comprise 121 the site-local area network. Exceptions to normal mDNS operation are 122 specified in subsequent sections. 124 This document uses the term "host name" in the strict sense to mean a 125 fully-qualified domain name that has an IPv4 or IPv6 address record. 126 It does not use the term "host name" in the commonly used but 127 incorrect sense to mean just the first DNS label of a host's fully 128 qualified domain name. 130 A DNS (or mDNS) packet contains an IP TTL in the IP header, which is 131 effectively a hop-count limit for the packet, to guard against 132 routing loops. Each Resource Record also contains a TTL, which is 133 the number of seconds for which the Resource Record may be cached. 134 This document uses the term "IP TTL" to refer to the IP header TTL 135 (hop limit), and the term "RR TTL" or just "TTL" to refer to the 136 Resource Record TTL (cache lifetime). 138 3. Extended Multicast DNS Names 140 Extended Multicast DNS specifies that the DNS top-level domain 141 ".site." is a special domain with special semantics, namely that any 142 fully-qualified domain name ending in ".site." is site-local, and 143 names within this domain are meaningful only on the site-local area 144 network where they originate. This is analogous to Unique Local IPv6 145 Unicast Address [RFC4291] prefixes, which are site-local and 146 meaningful only on the site where they are defined. 148 Any DNS query for a name ending with ".site." MUST be sent to the 149 xmDNS multicast address (239.255.TBD.TBD or its IPv6 equivalent 150 FF05::FB). Future versions of this document may specify a method for 151 creating zones under the ".site." top-level domain and mapping these 152 to alternate IPv6 multicast addresses but this is currently out of 153 scope. 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 individually. 160 4. Reverse Address Mapping 162 [RFC4193] recommends that queries for D.F.IPV6.ARPA be handled 163 locally. [I-D.ietf-dnsop-default-local-zones] extends the 164 recommendation to cover other well known IN-ADDR.ARPA and IP6.ARPA 165 zones for which queries should not 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 IPv6 170 xmDNS link-local multicast address FF05::FB or the IPv4 xmDNS 171 multicast address 239.255.TBD.TBD. 173 [Other prefixes TBD] 175 5. Querying 177 In cases where the desired scope of a query is the local link, 178 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 [RFC4193] source address. 184 Extended Multicast DNS queries MUST NOT be sent with a Global IPv6 185 Unicast [RFC4291] source address. The Source Address Check rules in 186 Section 11 will not be able to determine whether the query was from 187 an 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 Responses MUST return all available AAAA 195 records. 197 7. Traffic Reduction 199 [TBD] 201 8. Probing and Announcing on Startup 203 [TBD] 205 9. Conflict Resolution 207 [TBD] 209 10. Resource Record TTL Values and Cache Coherency 211 [TBD] 213 11. Source Address Check 215 Source address check must ensure that queries originate from on-site 216 prefixes. All other queries must be silently dropped. 218 12. Special Characteristics of Extended Multicast DNS Domains 220 [TBD] 222 13. Enabling and Disabling Multicast DNS 224 [TBD] 226 14. Considerations for Multiple Interfaces 228 [TBD] 230 15. Considerations for Multiple Responders on the Same Machine 232 [TBD] 234 16. Multicast DNS Character Set 236 [Same as mDNS] 238 17. Multicast DNS Message Size 240 [Same as mDNS] 242 18. Multicast DNS Message Format 244 [Same as mDNS] 246 19. Summary of Differences Between Multicast DNS and Unicast DNS 248 [Same as mDNS] 250 20. IPv6 Considerations 252 An IPv4-only host and an IPv6-only host behave as "ships that pass in 253 the night". Even if they are on the same Ethernet, neither is aware 254 of the other's traffic. For this reason, each physical link may have 255 *two* unrelated ".site." zones, one for IPv4 and one for IPv6. Since 256 for practical purposes, a group of IPv4-only hosts and a group of 257 IPv6-only hosts on the same Ethernet act as if they were on two 258 entirely separate Ethernet segments, it is unsurprising that their 259 use of the ".site." zone should occur exactly as it would if they 260 really were on two entirely separate Ethernet segments. 262 A dual-stack (v4/v6) host can participate in both ".site." zones, and 263 should register its name(s) and perform its lookups both using IPv4 264 and IPv6. This enables it to reach, and be reached by, both IPv4- 265 only and IPv6-only hosts. In effect this acts like a multi- homed 266 host, with one connection to the logical "IPv4 Ethernet segment", and 267 a connection to the logical "IPv6 Ethernet segment". When such a 268 host generates NSEC records, if it is using the same host name for 269 its IPv4 addresses and its IPv6 addresses on that network interface, 270 its NSEC records should indicate that the host name has both A and 271 AAAA records. 273 21. Security Considerations 275 [TBD] 277 22. IANA Considerations 279 IANA has allocated the IPv6 multicast address set FF0X::FB for 280 Multicast DNS [mcast6]. The use of FF02::FB (Link-Local Scope) is 281 described in [I-D.cheshire-dnsext-multicastdns] and the use of 282 address FF05::FB (Site-Local Scope) is defined in this document. 284 When this document is published, IANA should designate a list of 285 domains which are deemed to have only site-local significance, as 286 described in Section 12 of this document ("Special Characteristics of 287 Extended Multicast DNS Domains") [I-D.cheshire-dnsext-special-names]. 289 Specifically, the designated site-local domains are: 291 site. 292 d.f.ip6.arpa. 294 [TBD] This proposal will also likely request an IPv4 multicast 295 address in the site-local range (239.255.0.0/16) [RFC2365] in order 296 to differentiate xmDNS queries from normal mDNS queries, and to allow 297 for modified xmDNS source address check rules. 299 23. Domain Name Reservation Considerations 301 The two domains listed in Section 22 above and any names falling 302 within those domains (e.g. "MyServer.site.", "b.a.9.8.7.6.5.0.0. 303 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.d.f.ip6.arpa.", 304 "www._http._tcp.site.") are special DNS names 305 [I-D.cheshire-dnsext-special-names] in the following ways: 307 1. Users may use these names as they would other DNS names, entering 308 them anywhere that they would otherwise enter a conventional DNS 309 name, or a dotted decimal IPv4 address, or a literal IPv6 310 address. 312 Since there is no central authority responsible for assigning 313 dot-site names, and all devices on the site-local network are 314 equally entitled to claim any dot-site name, users SHOULD be 315 aware of this and SHOULD exercise appropriate caution. In an 316 untrusted or unfamiliar network environment, users SHOULD be 317 aware that using a name like "www.site" may not actually connect 318 them to the web site they expected, and could easily connect them 319 to a different web page, or even a fake or spoof of their 320 intended web site, designed to trick them into revealing 321 confidential information. As always with networking, end-to-end 322 cryptographic security can be a useful tool. For example, when 323 connecting with ssh, the ssh host key verification process will 324 inform the user if it detects that the identity of the entity 325 they are communicating with has changed since the last time they 326 connected to that name. 328 2. Application software may use these names as they would other 329 similar DNS names, and is not required to recognize the names and 330 treat them specially. Due to the relative ease of spoofing dot- 331 site names, end-to-end cryptographic security remains important 332 when communicating across a local network, just as it is when 333 communicating across the global Internet. 335 3. Name resolution APIs and libraries SHOULD recognize these names 336 as special and SHOULD NOT send queries for these names to their 337 configured (unicast) caching DNS server(s). This is to avoid 338 unnecessary load on the root name servers and other name servers, 339 caused by queries for which those name servers do not have useful 340 non-negative answers to give, and will not ever have useful 341 nonnegative answers to give. 343 4. Caching DNS servers SHOULD recognize these names as special and 344 SHOULD NOT attempt to look up NS records for them, or otherwise 345 query authoritative DNS servers in an attempt to resolve these 346 names. Instead, caching DNS servers SHOULD generate immediate 347 NXDOMAIN responses for all such queries they may receive (from 348 misbehaving name resolver libraries). This is to avoid 349 unnecessary load on the root name servers and other name servers. 351 5. Authoritative DNS servers SHOULD NOT by default be configurable 352 tp answer queries for these names, and, like caching DNS servers, 353 SHOULD generate immediate NXDOMAIN responses for all such queries 354 they may receive. DNS server software MAY provide a 355 configuration option to override this default, for testing 356 purposes or other specialized uses. 358 6. DNS server operators SHOULD NOT attempt to configure 359 authoritative DNS servers to act as authoritative for any of 360 these names. Configuring an authoritative DNS server to act as 361 authoritative for any of these names may not, in many cases, 362 yield the expected result, since name resolver libraries and 363 caching DNS servers SHOULD NOT send queries for those names (see 364 3 and 4 above), so such queries SHOULD be suppressed before they 365 even reach the authoritative DNS server in question, and 366 consequently it will not even get an opportunity to answer them. 368 7. DNS Registrars MUST NOT allow any of these names to be registered 369 in the normal way to any person or entity. These names are 370 reserved protocol identifiers with special meaning and fall 371 outside the set of names available for allocation by registrars. 372 Attempting to allocate one of these names as if it were a normal 373 DNS domain name will probably not work as desired, for reasons 3, 374 4, and 6 above. 376 24. Acknowledgments 378 We wish to thank the authors of [I-D.cheshire-dnsext-multicastdns] on 379 whose work this document is heavily based. Reviews and comments were 380 provided by Tom Herbst and Ralph Droms. 382 25. References 384 25.1. Normative References 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 390 RFC 2365, July 1998. 392 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 393 Addresses", RFC 4193, October 2005. 395 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 396 Architecture", RFC 4291, February 2006. 398 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 399 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 400 May 2008. 402 [mcast6] "IPv6 Multicast Address Space Registry", 403 . 406 25.2. Informative References 408 [I-D.cheshire-dnsext-dns-sd] 409 Cheshire, S. and M. Krochmal, "DNS-Based Service 410 Discovery", draft-cheshire-dnsext-dns-sd-10 (work in 411 progress), February 2011. 413 [I-D.cheshire-dnsext-multicastdns] 414 Cheshire, S. and M. Krochmal, "Multicast DNS", 415 draft-cheshire-dnsext-multicastdns-14 (work in progress), 416 February 2011. 418 [I-D.cheshire-dnsext-special-names] 419 Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 420 draft-cheshire-dnsext-special-names-01 (work in progress), 421 January 2011. 423 [I-D.ietf-dnsop-default-local-zones] 424 Andrews, M., "Locally-served DNS Zones", 425 draft-ietf-dnsop-default-local-zones-15 (work in 426 progress), March 2011. 428 Authors' Addresses 430 Kerry Lynn 431 Consultant 433 Phone: +1 978-460-4253 434 Email: kerlyn@ieee.org 436 Don Sturek 437 Pacific Gas & Electric 438 77 Beale Street 439 San Francisco, CA 440 USA 442 Phone: +1 619-504-3615 443 Email: d.sturek@att.net