idnits 2.17.1 draft-ietf-homenet-hybrid-proxy-zeroconf-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 : ---------------------------------------------------------------------------- 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 (October 15, 2015) is 3115 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) -- Looks like a reference, but probably isn't: '1' on line 588 -- Looks like a reference, but probably isn't: '0' on line 472 -- Looks like a reference, but probably isn't: '2' on line 464 -- Looks like a reference, but probably isn't: '3' on line 470 -- Looks like a reference, but probably isn't: '4' on line 470 == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-00 == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-09 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet Working Group M. Stenberg 3 Internet-Draft Independent 4 Intended status: Standards Track October 15, 2015 5 Expires: April 17, 2016 7 Auto-Configuration of a Network of Hybrid Unicast/Multicast DNS-Based 8 Service Discovery Proxy Nodes 9 draft-ietf-homenet-hybrid-proxy-zeroconf-02 11 Abstract 13 This document describes how a proxy functioning between Unicast DNS- 14 Based Service Discovery and Multicast DNS can be automatically 15 configured using an arbitrary network-level state sharing mechanism. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 17, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 53 3. Hybrid proxy - what to configure . . . . . . . . . . . . . . 3 54 3.1. Conflict resolution within network . . . . . . . . . . . 4 55 3.2. Per-link DNS-SD forward zone names . . . . . . . . . . . 4 56 3.3. Reasonable defaults . . . . . . . . . . . . . . . . . . . 5 57 3.3.1. Network-wide unique link name (scheme 1) . . . . . . 5 58 3.3.2. Node name (scheme 2) . . . . . . . . . . . . . . . . 5 59 3.3.3. Link name (scheme 2) . . . . . . . . . . . . . . . . 5 60 4. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 6 62 4.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 7 63 4.3. Node Name TLV . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Desirable behavior . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. DNS search path in DHCP requests . . . . . . . . . . . . 8 66 5.2. Hybrid proxy . . . . . . . . . . . . . . . . . . . . . . 8 67 5.3. Hybrid proxy network zeroconf daemon . . . . . . . . . . 8 68 6. Limited zone stitching for host name resolution . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 9.1. Normative references . . . . . . . . . . . . . . . . . . 9 73 9.2. Informative references . . . . . . . . . . . . . . . . . 10 74 Appendix A. Example configuration . . . . . . . . . . . . . . . 10 75 A.1. Used topology . . . . . . . . . . . . . . . . . . . . . . 10 76 A.2. Zero-configuration steps . . . . . . . . . . . . . . . . 11 77 A.3. TLV state . . . . . . . . . . . . . . . . . . . . . . . . 11 78 A.4. DNS zone . . . . . . . . . . . . . . . . . . . . . . . . 12 79 A.5. Interaction with hosts . . . . . . . . . . . . . . . . . 13 80 Appendix B. Implementation . . . . . . . . . . . . . . . . . . . 13 81 Appendix C. Why not just proxy Multicast DNS? . . . . . . . . . 13 82 C.1. General problems . . . . . . . . . . . . . . . . . . . . 14 83 C.2. Stateless proxying problems . . . . . . . . . . . . . . . 14 84 C.3. Stateful proxying problems . . . . . . . . . . . . . . . 15 85 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 15 86 Appendix E. Changelog [RFC Editor: please remove] . . . . . . . 15 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 Section 3 ("Hybrid Proxy Operation") of [I-D.ietf-dnssd-hybrid] 92 describes how to translate queries from Unicast DNS-Based Service 93 Discovery described in [RFC6763] to Multicast DNS described in 94 [RFC6762], and how to filter the responses and translate them back to 95 unicast DNS. 97 This document describes what sort of configuration the participating 98 hybrid proxy servers require, as well as how it can be provided using 99 any network-wide state sharing mechanism such as link-state routing 100 protocol or Home Networking Control Protocol [I-D.ietf-homenet-hncp]. 101 The document also describes a naming scheme which does not even need 102 to be same across the whole covered network to work as long as the 103 specified conflict resolution works. The scheme can be used to 104 provision both forward and reverse DNS zones which employ hybrid 105 proxy for heavy lifting. 107 This document does not go into low level encoding details of the 108 Type-Length-Value (TLV) data that we want synchronized across a 109 network. Instead, we just specify what needs to be available, and 110 assume every node that needs it has it available. 112 We go through the mandatory specification of the language used in 113 Section 2, then describe what needs to be configured in hybrid 114 proxies and participating DNS servers across the network in 115 Section 3. How the data is exchanged using arbitrary TLVs is 116 described in Section 4. Finally, some overall notes on desired 117 behavior of different software components is mentioned in Section 5. 119 2. Requirements language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Hybrid proxy - what to configure 127 Beyond the low-level translation mechanism between unicast and 128 multicast service discovery, the hybrid proxy draft 129 [I-D.ietf-dnssd-hybrid] describes just that there have to be NS 130 records pointing to hybrid proxy responsible for each link within the 131 covered network. 133 In zero-configuration case, choosing the links to be covered is also 134 non-trivial choice; we can use the border discovery functionality (if 135 available) to determine internal and external links. Or we can use 136 some other protocol's presence (or lack of it) on a link to determine 137 internal links within the covered network, and some other signs 138 (depending on the deployment) such as DHCPv6 Prefix Delegation (as 139 described in [RFC3633]) to determine external links that should not 140 be covered. 142 For each covered link we want forward DNS zone delegation to an 143 appropriate node which is connected to a link, and running hybrid 144 proxy. Therefore the links' forward DNS zone names should be unique 145 across the network. We also want to populate reverse DNS zone 146 similarly for each IPv4 or IPv6 prefix in use. 148 There should be DNS-SD browse domain list provided for the network's 149 domain which contains each physical link only once, regardless of how 150 many nodes and hybrid proxy implementations are connected to it. 152 Yet another case to consider is the list of DNS-SD domains that we 153 want hosts to enumerate for browse domain lists. Typically, it 154 contains only the local network's domain, but there may be also other 155 networks we may want to pretend to be local but are in different 156 scope, or controlled by different organization. For example, a home 157 user might see both home domain's services (TBD-TLD), as well as 158 ISP's services under isp.example.com. 160 3.1. Conflict resolution within network 162 Any naming-related choice on node may have conflicts in the network 163 given that we require only distributed loosely synchronized database. 164 We assume only that the underlying protocol used for synchronization 165 has some concept of precedence between nodes originating conflicting 166 information, and in case of conflict, the higher precedence node MUST 167 keep the name they have chosen. The one(s) with lower precedence 168 MUST either try different one (that is not in use at all according to 169 the current link state information), or choose not to publish the 170 name altogether. 172 If a node needs to pick a different name, any algorithm works, 173 although simple algorithm choice is just like the one described in 174 Multicast DNS[RFC6762]: append -2, -3, and so forth, until there are 175 no conflicts in the network for the given name. 177 3.2. Per-link DNS-SD forward zone names 179 How to name the links of a whole network in automated fashion? Two 180 different approaches seem obvious: 182 1. Unique link name based - (unique-link).(domain). 184 2. Node and link name - (link).(unique-node).(domain). 186 The first choice is appealing as it can be much more friendly 187 (especially given manual configuration). For example, it could mean 188 just lan.example.com and wlan.example.com for a simple home network. 189 The second choice, on the other hand, has a nice property of being 190 local choice as long as node name can be made unique. 192 The type of naming scheme to use can be left as implementation 193 option. And the actual names themselves SHOULD be also overridable, 194 if the end-user wants to customize them in some way. 196 3.3. Reasonable defaults 198 Note that any manual configuration, which SHOULD be possible, MUST 199 override the defaults provided here or chosen by the creator of the 200 implementation. 202 3.3.1. Network-wide unique link name (scheme 1) 204 It is not obvious how to produce network-wide unique link names for 205 the (unique-link).(domain) scheme. One option would be to base it on 206 type of physical network layer, and then hope that the number of the 207 networks won't be significant enough to confuse (e.g. "lan", or 208 "wlan"). 210 The network-wide unique link names should be only used in small 211 networks. Given a larger network, after conflict resolution, 212 identifying which link is 'lan-42.example.com' may be challenging. 214 3.3.2. Node name (scheme 2) 216 Our recommendation is to use some short form which indicates the type 217 of node it is, for example, "openwrt.example.com". As the name is 218 visible to users, it should be kept as short as possible. In theory 219 even more exact model could be helpful, for example, "openwrt- 220 buffalo-wzr-600-dhr.example.com". In practice providing some other 221 records indicating exact node information (and access to management 222 UI) is more sensible. 224 3.3.3. Link name (scheme 2) 226 Recommendation for (link) portion of (link).(node).(domain) is to use 227 physical network layer type as base, or possibly even just interface 228 name on the node if it's descriptive enough. For example, 229 "eth0.openwrt.example.com" and "wlan0.openwrt.example.com" may be 230 good enough. 232 4. TLVs 234 To implement this specification fully, support for following three 235 different TLVs is needed. However, only the DNS Delegated Zone TLVs 236 MUST be supported, and the other two SHOULD be supported. 238 4.1. DNS Delegated Zone TLV 240 This TLV is effectively a combined NS and A/AAAA record for a zone. 241 It MUST be supported by implementations conforming to this 242 specification. Implementations SHOULD provide forward zone per link 243 (or optimizing a bit, zone per link with Multicast DNS traffic). 244 Implementations MAY provide reverse zone per prefix using this same 245 mechanism. If multiple nodes advertise same reverse zone, it should 246 be assumed that they all have access to the link with that prefix. 247 However, as noted in Section 5.3, mainly only the node with highest 248 precedence on the link should publish this TLV. 250 Contents: 252 o Address field is IPv6 address (e.g. 2001:db8::3) or IPv4 address 253 mapped to IPv6 address (e.g. ::FFFF:192.0.2.1) where the 254 authoritative DNS server for Zone can be found. If the address 255 field is all zeros, the Zone is under global DNS hierarchy and can 256 be found using normal recursive name lookup starting at the 257 authoritative root servers (This is mostly relevant with the S bit 258 below). 260 o S-bit indicates that this delegated zone consists of a full DNS-SD 261 domain, which should be used as base for DNS-SD domain enumeration 262 (that is, (field)._dns-sd._udp.(zone) exists). Forward zones MAY 263 have this set. Reverse zones MUST NOT have this set. This can be 264 used to provision DNS search path to hosts for non-local services 265 (such as those provided by ISP, or other manually configured 266 service providers). 268 o B-bit indicates that this delegated zone should be included in 269 network's DNS-SD browse list of domains at b._dns- 270 sd._udp.(domain). Local forward zones SHOULD have this set. 271 Reverse zones SHOULD NOT have this set. 273 o L-bit indicates that this delegated zone should be included in the 274 network's DNS-SD legacy browse list of domains at lb._dns- 275 sd._udp.(DOMAIN-NAME). Local forward zones SHOULD have this bit 276 set, reverse zones SHOULD NOT. 278 o Zone is the label sequence of the zone, encoded according to 279 section 3.1. ("Name space definitions") of [RFC1035]. Note that 280 name compression is not required here (and would not have any 281 point in any case), as we encode the zones one by one. The zone 282 MUST end with an empty label. 284 In case of a conflict (same zone being advertised by multiple parties 285 with different address or bits), conflict should be addressed 286 according to Section 3.1. 288 4.2. Domain Name TLV 290 This TLV is used to indicate the base (domain) to be used for the 291 network. If multiple nodes advertise different ones, the conflict 292 resolution rules in Section 3.1 should result in only the one with 293 highest precedence advertising one, eventually. In case of such 294 conflict, user SHOULD be notified somehow about this, if possible, 295 using the configuration interface or some other notification 296 mechanism for the nodes. Like the Zone field in Section 4.1, the 297 Domain Name TLV's contents consist of a single DNS label sequence. 299 This TLV SHOULD be supported if at all possible. It may be derived 300 using some future DHCPv6 option, or be set by manual configuration. 301 Even on nodes without manual configuration options, being able to 302 read the domain name provided by a different node could make the user 303 experience better due to consistent naming of zones across the 304 network. 306 By default, if no node advertises domain name TLV, hard-coded default 307 (TBD) should be used. 309 4.3. Node Name TLV 311 This TLV is used to advertise a node's name. After the conflict 312 resolution procedure described in Section 3.1 finishes, there should 313 be exactly zero to one nodes publishing each node name. The contents 314 of the TLV should be a single DNS label. 316 This TLV SHOULD be supported if at all possible. If not supported, 317 and another node chooses to use the (link).(node) naming scheme with 318 this node's name, the contents of the network's domain may look 319 misleading (but due to conflict resolution of per-link zones, still 320 functional). 322 If the node name has been configured manually, and there is a 323 conflict, user SHOULD be notified somehow about this, if possible, 324 using the configuration interface or some other notification 325 mechanism for the nodes. 327 5. Desirable behavior 328 5.1. DNS search path in DHCP requests 330 The nodes following this specification SHOULD provide the used 331 (domain) as one item in the search path to it's hosts, so that DNS-SD 332 browsing will work correctly. They also SHOULD include any DNS 333 Delegated Zone TLVs' zones, that have S bit set. 335 5.2. Hybrid proxy 337 The hybrid proxy implementation SHOULD support both forward zones, 338 and IPv4 and IPv6 reverse zones. It SHOULD also detect whether or 339 not there are any Multicast DNS entities on a link, and make that 340 information available to the network zeroconf daemon (if implemented 341 separately). This can be done by (for example) passively monitoring 342 traffic on all covered links, and doing infrequent service 343 enumerations on links that seem to be up, but without any Multicast 344 DNS traffic (if so desired). 346 Hybrid proxy nodes MAY also publish it's own name via Multicast DNS 347 (both forward A/AAAA records, as well as reverse PTR records) to 348 facilitate applications that trace network topology. 350 5.3. Hybrid proxy network zeroconf daemon 352 The daemon should avoid publishing TLVs about links that have no 353 Multicast DNS traffic to keep the DNS-SD browse domain list as 354 concise as possible. It also SHOULD NOT publish delegated zones for 355 links for which zones already exist by another node with higher 356 precedence. 358 The daemon (or other entity with access to the TLVs) SHOULD generate 359 zone information for DNS implementation that will be used to serve 360 the (domain) zone to hosts. Domain Name TLV described in Section 4.2 361 should be used as base for the zone, and then all DNS Delegated Zones 362 described in Section 4.1 should be used to produce the rest of the 363 entries in zone (see Appendix A.4 for example interpretation of the 364 TLVs in Appendix A.3. 366 6. Limited zone stitching for host name resolution 368 Section 4.1 of the hybrid proxy specification [I-D.ietf-dnssd-hybrid] 369 notes that the stitching of multiple .local zones into a single DNS- 370 SD zone is to be defined later. This specification does not even 371 attempt that, but for the purpose of host name resolution, it is 372 possible to use the set of DNS Delegated Zone TLVs with S-bit or 373 B-bit set to also provide host naming for the (domain). It is done 374 by simply rewriting A/AAAA queries for (name).(domain) to every 375 (name).(ddz-subdomain).(domain), and providing response to the host 376 when the first non-empty one is received, rewritten back to 377 (name).(domain). 379 While this scheme is not very scalable, as it multiplies the number 380 of queries by the number of links (given no response in cache), it 381 does work in small networks with relatively few sub-domains. 383 7. Security Considerations 385 There is a trade-off between security and zero-configuration in 386 general; if used network state synchronization protocol is not 387 authenticated (and in zero-configuration case, it most likely is 388 not), it is vulnerable to local spoofing attacks. We assume that 389 this scheme is used either within (lower layer) secured networks, or 390 with not-quite-zero-configuration initial set-up. 392 If some sort of dynamic inclusion of links to be covered using border 393 discovery or such is used, then effectively service discovery will 394 share fate with border discovery (and also security issues if any). 396 8. IANA Considerations 398 This document has no actions for IANA. 400 9. References 402 9.1. Normative references 404 [I-D.ietf-dnssd-hybrid] 405 Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service 406 Discovery", draft-ietf-dnssd-hybrid-00 (work in progress), 407 November 2014. 409 [RFC1035] Mockapetris, P., "Domain names - implementation and 410 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 411 November 1987, . 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 415 RFC2119, March 1997, 416 . 418 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 419 DOI 10.17487/RFC6762, February 2013, 420 . 422 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 423 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 424 . 426 9.2. Informative references 428 [I-D.ietf-homenet-hncp] 429 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 430 Control Protocol", draft-ietf-homenet-hncp-09 (work in 431 progress), August 2015. 433 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 434 Host Configuration Protocol (DHCP) version 6", RFC 3633, 435 DOI 10.17487/RFC3633, December 2003, 436 . 438 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 439 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 440 DOI 10.17487/RFC3646, December 2003, 441 . 443 9.3. URIs 445 [1] https://github.com/sbyx/hnetd/ 447 Appendix A. Example configuration 449 A.1. Used topology 451 Let's assume home network that looks like this: 453 |[0] 454 +-----+ 455 | CER | 456 +-----+ 457 [1]/ \[2] 458 / \ 459 +-----+ +-----+ 460 | IR1 |-| IR2 | 461 +-----+ +-----+ 462 |[3]| |[4]| 464 We're not really interested about links [0], [1] and [2], or the 465 links between IRs. Given the optimization described in Section 4.1, 466 they should not produce anything to network's Multicast DNS state 467 (and therefore to DNS either) as there isn't any Multicast DNS 468 traffic there. 470 The user-visible set of links are [3] and [4]; each consisting of a 471 LAN and WLAN link. We assume that ISP provides 2001:db8:1234::/48 472 prefix to be delegated in the home via [0]. 474 A.2. Zero-configuration steps 476 Given implementation that chooses to use the second naming scheme 477 (link).(node).(domain), and no configuration whatsoever, here's what 478 happens (the steps are interleaved in practice but illustrated here 479 in order): 481 1. Network-level state synchronization protocol runs, nodes get 482 effective precedences. For ease of illustration, CER winds up 483 with 2, IR1 with 3, and IR2 with 1. 485 2. Prefix delegation takes place. IR1 winds up with 486 2001:db8:1234:11::/64 for LAN and 2001:db8:1234:12::/64 for WLAN. 487 IR2 winds up with 2001:db8:1234:21::/64 for LAN and 488 2001:db8:1234:22::/64 for WLAN. 490 3. IR1 is assumed to be reachable at 2001:db8:1234:11::1 and IR2 at 491 2001:db8:1234:21::1. 493 4. Each node wants to be called 'node' due to lack of branding in 494 drafts. They announce that using the node name TLV defined in 495 Section 4.3. They also advertise their local zones, but as that 496 information may change, it's omitted here. 498 5. Conflict resolution ensues. As IR1 has precedence over the rest, 499 it becomes "node". CER and IR2 have to rename, and (depending on 500 timing) one of them becomes "node-2" and other one "node-3". Let 501 us assume IR2 is "node-2". During conflict resolution, each node 502 publishes TLVs for it's own set of delegated zones. 504 6. CER learns ISP-provided domain "isp.example.com" using DHCPv6 505 domain list option defined in [RFC3646]. The information is 506 passed along as S-bit enabled delegated zone TLV. 508 A.3. TLV state 510 Once there is no longer any conflict in the system, we wind up with 511 following TLVs (NN is used as abbreviation for Node Name, and DZ for 512 Delegated Zone TLVs): 514 (from CER) 515 DZ {s=1,zone="isp.example.com"} 517 (from IR1) 518 NN {name="node"} 520 DZ {address=2001:db8:1234:11::1, b=1, 521 zone="lan.node.example.com."} 522 DZ {address=2001:db8:1234:11::1, 523 zone="1.1.0.0.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa."} 525 DZ {address=2001:db8:1234:11::1, b=1, 526 zone="wlan.node.example.com."} 527 DZ {address=2001:db8:1234:11::1, 528 zone="2.1.0.0.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa."} 530 (from IR2) 531 NN {name="node-2"} 533 DZ {address=2001:db8:1234:21::1, b=1, 534 zone="lan.node-2.example.com."} 535 DZ {address=2001:db8:1234:21::1, 536 zone="1.2.0.0.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa."} 538 DZ {address=2001:db8:1234:21::1, b=1, 539 zone="wlan.node-2.example.com."} 540 DZ {address=2001:db8:1234:21::1, 541 zone="2.2.0.0.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa."} 543 A.4. DNS zone 545 In the end, we should wind up with following zone for (domain) which 546 is example.com in this case, available at all nodes, just based on 547 dumping the delegated zone TLVs as NS+AAAA records, and optionally 548 domain list browse entry for DNS-SD: 550 b._dns_sd._udp PTR lan.node 551 b._dns_sd._udp PTR wlan.node 553 b._dns_sd._udp PTR lan.node-2 554 b._dns_sd._udp PTR wlan.node-2 556 node AAAA 2001:db8:1234:11::1 557 node-2 AAAA 2001:db8:1234:21::1 559 node NS node 560 node-2 NS node-2 562 1.1.0.0.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa. NS node.example.com. 563 2.1.0.0.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa. NS node.example.com. 564 1.2.0.0.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa. NS node-2.example.com. 565 2.2.0.0.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa. NS node-2.example.com. 567 Internally, the node may interpret the TLVs as it chooses to, as long 568 as externally defined behavior follows semantics of what's given in 569 the above. 571 A.5. Interaction with hosts 573 So, what do the hosts receive from the nodes? Using e.g. DHCPv6 DNS 574 options defined in [RFC3646], DNS server address should be one (or 575 multiple) that point at DNS server that has the zone information 576 described in Appendix A.4. Domain list provided to hosts should 577 contain both "example.com" (the hybrid-enabled domain), as well as 578 the externally learned domain "isp.example.com". 580 When hosts start using DNS-SD, they should check both b._dns- 581 sd._udp.example.com, as well as b._dns-sd._udp.isp.example.com for 582 list of concrete domains to browse, and as a result services from two 583 different domains will seem to be available. 585 Appendix B. Implementation 587 There is an prototype implementation of this draft at hnetd github 588 repository [1] which contains variety of other homenet WG-related 589 things' implementation too. 591 Appendix C. Why not just proxy Multicast DNS? 593 Over the time number of people have asked me about how, why, and if 594 we should proxy (originally) link-local Multicast DNS over multiple 595 links. 597 At some point I meant to write a draft about this, but I think I'm 598 too lazy; so some notes left here for general amusement of people 599 (and to be removed if this ever moves beyond discussion piece). 601 C.1. General problems 603 There are two main reasons why Multicast DNS is not proxyable in the 604 general case. 606 First reason is the conflict resolution depends on the RRsets staying 607 constant. That is not possible across multiple links (due to e.g. 608 link-local addresses having to be filtered). Therefore, conflict 609 resolution breaks, or at least requires ugly hacks to work around. 611 A simple, but not really working workaround for this is to make sure 612 that in conflict resolution, propagated resources always loses. 613 Given that the proxy function only removes records, the result SHOULD 614 be consistently original set of records winning. Even with that, the 615 conflict resolution will effectively cease working, allowing for two 616 instances of same name to exist (as both think they 'own' the name 617 due to locally seen higher precedence). 619 Given some more extra logic, it is possible to make this work by 620 having proxies be aware of both the original record sets, and 621 effectively enforcing the correct conflict resolution results by (for 622 example) passing the unfiltered packets to the losing party just to 623 make sure they renumber, or by altering the RR sets so that they will 624 consistently win (by inserting some lower rrclass/rrtype records). 625 As the conflicts happen only in rrclass=1/rrtype=28, it is easy 626 enough to add e.g. extra TXT record (rrtype 16) to force precedence 627 even when removing the later rrtype 28 record. Obviously, this new 628 RRset must never wind up near the host with the higher precedence, or 629 it will cause spurious renaming loops. 631 Second reason is timing, which is relatively tight in the conflict 632 resolution phase, especially given lossy and/or high latency 633 networks. 635 C.2. Stateless proxying problems 637 In general, typical stateless proxy has to involve flooding, as 638 Multicast DNS assumes that most messages are received by every host. 639 And it won't scale very well, as a result. 641 The conflict resolution is also harder without state. It may result 642 in Multicast DNS responder being in constant probe-announce loop, 643 when it receives altered records, notes that it's the one that should 644 own the record. Given stateful proxying, this would be just a 645 transient problem but designing stateless proxy that won't cause this 646 is non-trivial exercise. 648 C.3. Stateful proxying problems 650 One option is to write proxy that learns state from one link, and 651 propagates it in some way to other links in the network. 653 A big problem with this case lies in the fact that due to conflict 654 resolution concerns above, it is easy to accidentally send packets 655 that will (possibly due to host mobility) wind up at the originator 656 of the service, who will then perform renaming. That can be 657 alleviated, though, given clever hacks with conflict resolution 658 order. 660 The stateful proxying may be also too slow to occur within the 661 timeframe allocated for announcing, leading to excessive later 662 renamings based on delayed finding of duplicate services with same 663 name 665 A work-around exists for this though; if the game doesn't work for 666 you, don't play it. One option would be simply not to propagate ANY 667 records for which conflict has seen even once. This would work, but 668 result in rather fragile, lossy service discovery infrastructure. 670 There are some other small nits too; for example, Passive Observation 671 Of Failure (POOF) will not work given stateful proxying. Therefore, 672 it leads to requiring somewhat shorter TTLs, perhaps. 674 Appendix D. Acknowledgements 676 Thanks to Stuart Cheshire for the original hybrid proxy draft and 677 interesting discussion in Orlando, where I was finally convinced that 678 stateful Multicast DNS proxying is a bad idea. 680 Also thanks to Mark Baugher, Ole Troan, Shwetha Bhandari and Gert 681 Doering for review comments. 683 Appendix E. Changelog [RFC Editor: please remove] 685 draft-ietf-homenet-hybrid-proxy-zeroconf-02: 687 o Added subsection on simple zone stitching for host naming 688 purposes. 690 draft-ietf-homenet-hybrid-proxy-zeroconf-01: 692 o Refreshed the draft while waiting on progress of draft-ietf-dnssd- 693 hybrid. 695 Author's Address 697 Markus Stenberg 698 Independent 699 Helsinki 00930 700 Finland 702 Email: markus.stenberg@iki.fi