idnits 2.17.1 draft-stenberg-homenet-dnssdext-hybrid-proxy-ospf-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 == Line 271 has weird spacing: '...Address field...' == Line 292 has weird spacing: '... Zone is th...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 26, 2013) is 3929 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '0' on line 538 -- Looks like a reference, but probably isn't: '1' on line 654 -- Looks like a reference, but probably isn't: '2' on line 677 -- Looks like a reference, but probably isn't: '3' on line 536 -- Looks like a reference, but probably isn't: '4' on line 536 == Outdated reference: A later version (-02) exists of draft-cheshire-mdnsext-hybrid-01 == Outdated reference: A later version (-15) exists of draft-ietf-ospf-ospfv3-autoconfig-02 == Outdated reference: A later version (-04) exists of draft-arkko-homenet-prefix-assignment-01 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Stenberg 3 Internet-Draft 4 Intended status: Standards Track June 26, 2013 5 Expires: December 28, 2013 7 Hybrid Unicast/Multicast DNS-Based Service Discovery Auto-Configuration 8 Using OSPFv3 9 draft-stenberg-homenet-dnssdext-hybrid-proxy-ospf-00 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 automatically configured routing protocol or some 16 other network-level state sharing mechanism. Zero-configuration 17 OSPFv3 is used to describe one concrete way to implement this scheme. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 28, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 55 3. Hybrid proxy - what to configure . . . . . . . . . . . . . . 3 56 3.1. Conflict resolution with OSPFv3 . . . . . . . . . . . . . 4 57 3.2. Per-link DNS-SD forward zone names . . . . . . . . . . . 4 58 3.3. Reasonable defaults . . . . . . . . . . . . . . . . . . . 5 59 3.3.1. Network-wide unique link name (scheme 1) . . . . . . 5 60 3.3.2. Router name (scheme 2) . . . . . . . . . . . . . . . 5 61 3.3.3. Link name (scheme 2) . . . . . . . . . . . . . . . . 5 62 4. OSPFv3 auto-configuration TLVs . . . . . . . . . . . . . . . 6 63 4.1. DNS Delegated Zone TLV . . . . . . . . . . . . . . . . . 6 64 4.2. Domain Name TLV . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Router Name TLV . . . . . . . . . . . . . . . . . . . . . 8 66 4.4. DNS Server TLV . . . . . . . . . . . . . . . . . . . . . 8 67 5. Desirable router behavior . . . . . . . . . . . . . . . . . . 9 68 5.1. DNS search path . . . . . . . . . . . . . . . . . . . . . 9 69 5.2. Hybrid proxy . . . . . . . . . . . . . . . . . . . . . . 9 70 5.3. OSPFv3 daemon . . . . . . . . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 8.1. Normative references . . . . . . . . . . . . . . . . . . 11 75 8.2. Informative references . . . . . . . . . . . . . . . . . 11 76 Appendix A. Example configuration . . . . . . . . . . . . . . . 12 77 A.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 12 78 A.2. OSPFv3-DNS interaction . . . . . . . . . . . . . . . . . 12 79 A.3. OSPFv3 state . . . . . . . . . . . . . . . . . . . . . . 13 80 A.4. DNS zone . . . . . . . . . . . . . . . . . . . . . . . . 14 81 A.5. Interaction with hosts . . . . . . . . . . . . . . . . . 14 82 Appendix B. Implementation . . . . . . . . . . . . . . . . . . . 15 83 Appendix C. Why not just proxy Multicast DNS? . . . . . . . . . 15 84 C.1. General problems . . . . . . . . . . . . . . . . . . . . 15 85 C.2. Stateless proxying problems . . . . . . . . . . . . . . . 16 86 C.3. Stateful proxying problems . . . . . . . . . . . . . . . 16 87 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 17 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Section 3 ("Hybrid Proxy Operation") of [I-D.cheshire-mdnsext-hybrid] 93 describes how to translate queries from Unicast DNS-Based Service 94 Discovery described in [RFC6763] to Multicast DNS described in 95 [RFC6762], and how to filter the responses and translate them back to 96 unicast DNS. 98 This document describes what sort of configuration the participating 99 DNS servers require, as well as how it can be provided using auto- 100 configured OSPFv3 described in [I-D.ietf-ospf-ospfv3-autoconfig] and 101 a naming scheme which does not even need to be same across the whole 102 covered network. The scheme can be used to provision both forward 103 and reverse DNS zones which employ hybrid proxy for heavy lifting. 105 While this document describes the data to be transferred in auto- 106 configured OSPFv3 TLVs, in principle same scheme could work across 107 other routing protocols, or even some non-routing protocol, as long 108 as the consistent state for it is available across the whole covered 109 network (by for example site-scoped multicast, or some other flooding 110 scheme). 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 in OSPFv3 is described in 116 Section 4. Finally, some overall notes on desired behavior of 117 different router components is mentioned in Section 5. 119 2. Requirements language 121 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 122 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 123 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.cheshire-mdnsext-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 The links to be covered is also non-trivial choice; we can use the 134 border discovery functionality (if available) to determine internal 135 and external links. Or we can use OSPFv3 presence (or lack of it) on 136 a link to determine internal links within the covered network, and 137 some other signs (depending on the deployment) such as DHCPv6 Prefix 138 Delegation (as described in [RFC3633] to determine external links 139 that should not be covered. 141 For each covered link we want forward DNS zone delegation to an 142 appropriate router which is connected to a link, and running hybrid 143 proxy. We also want to populate reverse DNS zone similarly per each 144 prefix in use. Links' forward DNS zone names should be unique. 146 There should be DNS-SD domain search list provided for the network's 147 domain which contains domain for each physical link only once, 148 regardless of how many routers and hybrid proxy implementations are 149 connected to it. 151 Yet another case to consider is the list of DNS-SD domains that we 152 want hosts to enumerate for domain lists. Typically, it contains 153 only that the network's domain, but there may be also other networks 154 we may want to pretend to be local but are in different scope, or 155 controlled by different organization. For example, a home user might 156 see both home domain's services (TBD-TLD), as well as ISP's services 157 under isp.example.com. 159 3.1. Conflict resolution with OSPFv3 161 Any naming-related choice on a router may have conflicts in the 162 network. 164 We use similar conflict resolution scheme as described in the prefix 165 assignment draft[I-D.arkko-homenet-prefix-assignment]. That is, if a 166 conflict is encountered, the router with highest router ID MUST keep 167 the name they have chosen. The one(s) with lower router ID MUST 168 either try different one (that is not in use at all according to the 169 current link state information), or choose not to publish the name 170 altogether. 172 If router 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. Router and link name - (link).(router).(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 router 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 In general network-wide unique link names should be only used in 211 small networks. Given larger network, after conflict resolution, 212 finding which network is 'lan-42.example.com' may be challenging. 214 3.3.2. Router name (scheme 2) 216 Recommendation is to use some short form which indicates the type of 217 router it is, for example, "openwrt.example.com". As the name is 218 visible to users, it should be kept as short as possible. If theory 219 even more exact model could be helpful, for example, "openwrt- 220 buffalo-wzr-600-dhr.example.com". In practise, though, providing 221 some other records indicating exact router information (and access to 222 management UI) might be more sensible. 224 If scheme 2 is used, and there is no desire to implement conflict 225 resolution related TLV described in Section 4.3, a safe default might 226 be to default to router ID; that is, use as router name value such as 227 r-(router ID as single 32-bit number). It is guaranteed to be unique 228 across the network, but not as user-friendly as the descriptive 229 router name promoted here. 231 3.3.3. Link name (scheme 2) 232 Recommendation for (link) portion of (link).(router).(domain) is to 233 use either physical network layer type as base, possibly even just 234 interface name on the router, if it's descriptive enough, for 235 example, eth0.router1.example.com and wlan0.router1.example.com may 236 be good enough. 238 4. OSPFv3 auto-configuration TLVs 240 To implement this specification fully, support for following three 241 different new OSPFv3 auto-configuration TLVs is needed. However, 242 only the DNS Delegated Zone TLVs MUST be supported, and the other two 243 SHOULD be supported. 245 4.1. DNS Delegated Zone TLV 247 This TLV is effectively a combined NS and A/AAAA record for a zone. 248 It MUST be supported by implementations conforming to this 249 specification. Implementations SHOULD provide forward zone per link 250 (or optimizing a bit, zone per link with Multicast DNS traffic). 251 Implementations MAY provide reverse zone per prefix using this same 252 mechanism. If multiple routers advertise same reverse zone, it 253 should be assumed that they all have access to the link with that 254 prefix. However, as noted in Section 5.3, mainly only the router 255 with highest router ID on the link should publish this TLV. 257 0 1 2 3 258 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | TBD-BY-IANA-1 | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 | Address | 264 | (16 bytes) | 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |Reserved |S|B| Zone (DNS label sequence - variable length) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 DNS Delegated Zone TLV 271 Address field is IPv6 address (e.g. 2001:db8::3) or IPv4 address 272 mapped to IPv6 address (e.g. ::FFFF:192.0.2.1) where the 273 authoritative DNS server for Zone can be found. If the address 274 field is all zeros, the Zone is under global DNS hierarchy and can 275 be found using normal recursive name lookup starting at the 276 authoritative root servers (This is mostly relevant with the S bit 277 below). 279 S indicates that this delegated zone consists of a full DNS-SD 280 domain, which should be used as base for DNS-SD domain enumeration 281 (that is, (field)._dns-sd._udp.(zone) exists). Forward zones MAY 282 have this set. Reverse zones MUST NOT have this set. This can be 283 used to provision DNS search path to hosts for non-local services 284 (such as those provided by ISP, or other manually configured 285 service providers). 287 B indicates that this delegated zone should be included in network's 288 DNS-SD list of domains recommended for browsing at b._dns- 289 sd._udp.(domain). Local forward zones SHOULD have this set. 290 Reverse zones SHOULD NOT have this set. 292 Zone is the label sequence of the zone, encoded according to section 293 3.1. ("Name space definitions") of [RFC1035]. Note that name 294 compression is not required here (and would not have any point in 295 any case), as we encode the zones one by one. The zone MUST end 296 with empty label. 298 4.2. Domain Name TLV 300 This TLV is used to indicate the base (domain) to be used for the 301 network. If multiple routers advertise different ones, the conflict 302 resolution rules in Section 3.1 should result in only the one with 303 highest router ID advertising one, eventually. In case of such 304 conflict, user SHOULD be notified somehow about this, if possible, 305 using the configuration interface or some other notification 306 mechanism for the routers. 308 This TLV SHOULD be supported if at all possible. It may be derived 309 using some future DHCPv6 option, or be set by manual configuration. 310 Even on routers without manual configuration options, being able to 311 read the domain name provided by a different router could make the 312 user experience better due to consistent naming of zones across the 313 network. 315 0 1 2 3 316 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | TBD-BY-IANA-2 | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |Domain (DNS label sequence - variable length) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Domain Name TLV 324 Like the Zone field in Section 4.1, the Domain Name TLV's contents 325 are encoded as label sequence. 327 By default, if no router advertises domain name TLV, hard-coded 328 default (TBD) should be used. 330 4.3. Router Name TLV 332 This TLV is used to advertise a router's name. After the conflict 333 resolution procedure described in Section 3.1 finishes, there should 334 be exactly zero to one routers publishing each router name. 336 This TLV SHOULD be supported if at all possible. If not supported, 337 and another router chooses to use the (link).(router) naming scheme 338 with this router's name, the contents of the network's domain may 339 look misleading (but due to conflict resolution of per-link zones, 340 still functional). 342 0 1 2 3 343 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | TBD-BY-IANA-3 | Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 |Name (not even null terminated - variable length) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Router Name TLV 351 If the router name has been configured manually, and there is a 352 conflict, user SHOULD be notified somehow about this, if possible, 353 using the configuration interface or some other notification 354 mechanism for the routers. 356 4.4. DNS Server TLV 358 This TLV is used to announce address of a fallback recursive DNS 359 server (provided by e.g. ISP). If the DNS server implementations 360 used in the network are not full recursive resolver implementations, 361 they may respond to network-specific queries within network, and 362 forward the rest to the provided DNS servers. Even recursive 363 resolver implementations may want to use these servers, if available, 364 for better caching and therefore more responsive user experience. 366 Typically, these addresses are gleaned from (for example) a DHCPv4/ 367 DHCPv6 exchange, or from Router Advertisements. 369 Any router on the home network can publish 0-N of these TLVs, and the 370 order in which they are used is not defined (we assume that the DNS 371 view of the world is consistent; this may not be true in all cases). 373 This TLV SHOULD be supported by routers, but the routers (and DNS 374 servers in the network) MUST be able to cope even in the absence of 375 the TLV. This can be handled by (for example) DNS servers providing 376 recursive resolving fallback functionality, or defaulting to some 377 known global recursive resolver. 379 0 1 2 3 380 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | TBD-BY-IANA-4 | Length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | 385 | Address | 386 | (16 bytes) | 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 DNS Server TLV 391 The address may be again either IPv4 or IPv6 address, with the IPv4 392 address encoded under the ::FFFF:/96 prefix. 394 It is important to note that if the network's domain forward or 395 reverse resolution will not work globally, using network-external DNS 396 server directly is not good. Therefore the network's local DNS 397 servers should be announced to hosts in e.g. DHCPv4/DHCPv6/RA, and 398 then only those DNS servers can use the contents of this TLV as fall- 399 back for non-local resolution if so desired. How these local DNS 400 server addresses are propagated within home network is outside the 401 scope of this document 403 5. Desirable router behavior 405 5.1. DNS search path 407 The routers following this specification SHOULD provide the used 408 (domain) as one item in the search path to it's hosts, so that DNS-SD 409 browsing will work correctly. They also SHOULD include any DNS 410 Delegated Zone TLVs' zones, that have S bit set. 412 5.2. Hybrid proxy 413 The hybrid proxy implementation SHOULD support both forward zones, 414 and IPv4 and IPv6 reverse zones. It SHOULD also detect whether or 415 not there are any Multicast DNS entities on a link, and make that 416 information available to OSPFv3 daemon. This can be done by (for 417 example) passively monitoring traffic on all covered links, and doing 418 infrequent service enumerations on links that seem to be up, but 419 without any Multicast DNS traffic (if so desired). 421 Hybrid proxy SHOULD also publish it's own name via Multicast DNS 422 (both forward A/AAAA records, as well as reverse PTR records) to 423 facilitate applications that trace network topology. 425 5.3. OSPFv3 daemon 427 OSPFv3 daemon should avoid publishing TLVs about links that have no 428 Multicast DNS traffic to keep the DNS-SD browse domain list as 429 concise as possible. It also SHOULD NOT publish delegated zones for 430 links that it does not have highest router ID that supports this 431 specification. (Support for this specification can be deduced by 432 e.g. presence of any TLVs from this draft advertised by a router.) 434 OSPFv3 daemon (or other entity with access to the TLVs) SHOULD 435 generate zone information for DNS implementation that will be used to 436 serve the (domain) zone to hosts. Domain Name TLV described in 437 Section 4.2 should be used as base for the zone, and then all DNS 438 Delegated Zones described in Section 4.1 should be used to produce 439 the rest of the entries in zone (see Appendix A.4 for example 440 interpretation of the TLVs in Appendix A.3. 442 6. Security Considerations 444 There is a trade-off between security and zero-configuration in 445 general; if used routing protocol is not authenticated (and in zero- 446 configuration case, it most likely is not), it is vulnerable to local 447 spoofing attacks. We assume that this scheme is used either within 448 (lower layer) secured networks, or with not-quite-zero-configuration 449 routing protocol set-up which has authentication. 451 If some sort of dynamic inclusion of links to be covered using border 452 discovery or such is used, then effectively service discovery will 453 share fate with border discovery (and also security issues if any). 455 7. IANA Considerations 457 This document makes two allocations out of the OSPFv3 Auto- 458 Configuration (AC) LSA TLV namespace 459 [I-D.ietf-ospf-ospfv3-autoconfig]: 461 o The DNS Delegated Zone TLV in Section 4.1 takes the value TBD-BY- 462 IANA-1 (suggested value is 4). 464 o The Domain Name TLV in Section 4.2 takes the value TBD-BY-IANA-2 465 (suggested value is 5). 467 o The Router Name TLV in Section 4.3 takes the value TBD-BY-IANA-3 468 (suggested value is 6). 470 o The DNS Server TLV in Section 4.4 takes the value TBD-BY-IANA-4 471 (suggested value is 7). 473 8. References 475 8.1. Normative references 477 [I-D.cheshire-mdnsext-hybrid] 478 Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service 479 Discovery", draft-cheshire-mdnsext-hybrid-01 (work in 480 progress), January 2013. 482 [I-D.ietf-ospf-ospfv3-autoconfig] 483 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 484 draft-ietf-ospf-ospfv3-autoconfig-02 (work in progress), 485 April 2013. 487 [RFC1035] Mockapetris, P., "Domain names - implementation and 488 specification", STD 13, RFC 1035, November 1987. 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, March 1997. 493 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 494 February 2013. 496 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 497 Discovery", RFC 6763, February 2013. 499 8.2. Informative references 501 [I-D.arkko-homenet-prefix-assignment] 502 Arkko, J. and A. Lindem, "Prefix Assignment in a Home 503 Network", draft-arkko-homenet-prefix-assignment-01 (work 504 in progress), October 2011. 506 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 507 Host Configuration Protocol (DHCP) version 6", RFC 3633, 508 December 2003. 510 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 511 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 512 December 2003. 514 Appendix A. Example configuration 516 A.1. Topology 518 Let's assume home network that looks like this: 520 |[0] 521 +-----+ 522 | CER | 523 +-----+ 524 [1]/ \[2] 525 / \ 526 +-----+ +-----+ 527 | IR1 |-| IR2 | 528 +-----+ +-----+ 529 |[3]| |[4]| 531 We're not really interested about links [0], [1] and [2], or the 532 links between IRs. Given the optimization described in Section 4.1, 533 they should not produce anything to OSPF state (and therefore to DNS 534 either) as there isn't any Multicast DNS traffic there. 536 The user-visible set of links are [3] and [4]; each consisting of a 537 LAN and WLAN link. We assume that ISP provides 2001:db8::/48 prefix 538 to be delegated in the home via [0]. 540 A.2. OSPFv3-DNS interaction 542 Given implementation that chooses to use the second naming scheme 543 (link).(router).(domain), and no configuration whatsoever, here's 544 what happens (the steps are interleaved in practise but illustrated 545 here in order): 547 1. OSPFv3 auto-configuration takes place, routers get their router 548 IDs. For ease of illustration, CER winds up with 2, IR1 with 3, 549 and IR2 with 1. 551 2. Prefix delegation takes place. IR1 winds up with 2001:db8:1:1::/ 552 64 for LAN and 2001:db8:1:2::/64 for WLAN. IR2 winds up with 553 2001:db8:2:1::/64 for LAN and 2001:db8:2:2::/64 for WLAN. 555 3. IR1 is assumed to be reachable at 2001:db8:1:1::1 and IR2 at 556 2001:db8:2:1::1. 558 4. Each router wants to be called 'router' due to lack of branding 559 in drafts. They announce that using the router name TLV defined 560 in Section 4.3. They also advertise their local zones, but as 561 that information may change, it's omitted here. 563 5. Conflict resolution ensues. As IR1 has highest router ID, it 564 becomes "router". CER and IR2 have to rename, and (depending on 565 timing) one of them becomes "router-2" and other one "router-3". 566 Let us assume IR2 is "router-2". During conflict resolution, 567 each router publishes TLVs for it's own set of delegated zones. 569 6. CER learns ISP-provided domain "isp.example.com" using DHCPv6 570 domain list option defined in [RFC3646]. The information is 571 passed along as S-bit enabled delegated zone TLV. 573 A.3. OSPFv3 state 575 Once there is no longer any conflict in the system, we wind up with 576 following TLVs within OSPFv3 (RN is used as abbreviation for Router 577 Name, and DZ for Delegated Zone TLVs): 579 (from CER) 580 DZ {s=1,zone="isp.example.com"} 582 (from IR1) 583 RN {name="router"} 585 DZ {address=2001:db8:1:1::1, b=1, 586 zone="lan.router.example.com."} 587 DZ {address=2001:db8:1:1::1, 588 zone="1.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa."} 590 DZ {address=2001:db8:1:1::1, b=1, 591 zone="wlan.router.example.com."} 592 DZ {address=2001:db8:1:1::1, 593 zone="2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa."} 595 (from IR2) 596 RN {name="router-2"} 598 DZ {address=2001:db8:2:1::1, b=1, 599 zone="lan.router-2.example.com."} 600 DZ {address=2001:db8:2:1::1, 601 zone="1.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa."} 603 DZ {address=2001:db8:2:1::1, b=1, 604 zone="wlan.router-2.example.com."} 605 DZ {address=2001:db8:2:1::1, 606 zone="2.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa."} 608 A.4. DNS zone 610 In the end, we should wind up with following zone for (domain) which 611 is example.com in this case, available at all routers, just based on 612 dumping the delegated zone TLVs as NS+AAAA records, and optionally 613 domain list browse entry for DNS-SD: 615 b._dns_sd._udp PTR lan.router 616 b._dns_sd._udp PTR wlan.router 618 b._dns_sd._udp PTR lan.router-2 619 b._dns_sd._udp PTR wlan.router-2 621 router AAAA 2001:db8:1:1::1 622 router-2 AAAA 2001:db8:2:1::1 624 router NS router 625 router-2 NS router-2 627 1.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. NS router.example.com. 628 2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. NS router.example.com. 629 1.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. NS router-2.example.com. 630 2.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. NS router-2.example.com. 632 Internally, the router may interpret the TLVs as it chooses to, as 633 long as externally defined behavior follows semantics of what's given 634 in the above. 636 A.5. Interaction with hosts 638 So, what do the hosts receive from the routers? Using e.g. DHCPv6 639 DNS options defined in [RFC3646], DNS server address should be one 640 (or multiple) that point at DNS server that has the zone information 641 described in Appendix A.4. Domain list provided to hosts should 642 contain both "example.com" (the hybrid-enabled domain), as well as 643 the externally learned domain "isp.example.com". 645 When hosts start using DNS-SD, they should check both b._dns- 646 sd._udp.example.com, as well as b._dns-sd._udp.isp.example.com for 647 list of concrete domains to browse, and as a result services from two 648 different domains will seem to be available. 650 Appendix B. Implementation 652 There is an prototype implementation of this draft (and transitively 653 also of [I-D.cheshire-mdnsext-hybrid]) at hnet-core github repository 654 [1] which contains variety of other homenet WG-related things' 655 implementation too. 657 hp.lua binary can be used to start hybrid proxy either as one-router 658 stand-alone implementation (that can be used to e.g. use statically 659 configured DNS zones), or as part of zeroconf OSPFv3 configured set 660 of proxies. 662 Sample usage case: 664 # sudo lua hp.lua eth0 eth1 665 .. no output .. 667 Given the command, hybrid proxy is started for interfaces eth0 and 668 eth1, and it will publish DNS zones l-eth0.r-router.home, 669 l-eth1.r-router.home (and home zone with relevant DNS-SD sub-zone, 670 and default forward behavior) in DNS port. It has -h option for 671 seeing various options that can be set, notable one being --ospf (use 672 OSPFv3 autoconfigured hnet infrastructure). 674 Disclaimer: The set-up of third-party libraries etc to get the 675 implementation running may be painful and is omitted here. Use of 676 ready UML NetKit-based test environment or building image for a real 677 router using hnet github repository [2] is recommended. 679 Appendix C. Why not just proxy Multicast DNS? 681 Over the time number of people have asked me about how, why, and if 682 we should proxy (originally) link-local Multicast DNS over multiple 683 links. 685 At some point I meant to write a draft about this, but I think I'm 686 too lazy; so some notes left here for general amusement of people 687 (and to be removed if this ever moves beyond discussion piece). 689 C.1. General problems 691 There are two main reasons why Multicast DNS is not proxyable in the 692 general case. 694 First reason is the conflict resolution depends on ordering which 695 depends on the RRsets staying constant. That is not possible across 696 multiple links (due to e.g. link-local addresses having to be 697 filtered). Therefore, conflict resolution breaks, or at least 698 requires ugly hacks to work around. 700 A workaround for this is to make sure that in conflict resolution, 701 propagated resources always loses. Due to conflict handling ordering 702 logic, and the arbitrary order in which the original records may be 703 in, this is non-trivial. 705 Second reason is timing, which is relatively tight in the conflict 706 resolution phase, especially given lossy and/or high latency 707 networks. 709 C.2. Stateless proxying problems 711 In general, typical stateless proxy has to involve flooding, as 712 Multicast DNS assumes that most messages are received by every host. 713 And it won't scale very well, as a result. 715 The conflict resolution is also harder without state. It may result 716 in Multicast DNS responder being in constant probe-announce loop, 717 when it receives altered records, notes that it's the one that should 718 own the record. Given stateful proxying, this would be just a 719 transient problem but designing stateless proxy that won't cause this 720 is non-trivial exercise. 722 C.3. Stateful proxying problems 724 One option is to write proxy that learns state from one link, and 725 propagates it in some way to other links in the network. 727 A big problem with this case lies in the fact that due to conflict 728 resolution concerns above, it is easy to accidentally send packets 729 that will (possibly due to host mobility) wind up at the originator 730 of the service, who will then perform renaming. That can be 731 alleviated, though, given clever hacks with conflict resolution 732 order. 734 The stateful proxying may be also too slow to occur within the 735 timeframe allocated for announcing, leading to excessive later 736 renamings based on delayed finding of duplicate services with same 737 name 739 A work-around exists for this though; if the game doesn't work for 740 you, don't play it. One option would be simply not to propagate ANY 741 records for which conflict has seen even once. This would work, but 742 result in rather fragile, lossy service discovery infrastructure. 744 There are some other small nits too; for example, Passive Observation 745 Of Failure (POOF) will not work given stateful proxying. Therefore, 746 it leads to requiring somewhat shorter TTLs, perhaps. 748 Appendix D. Acknowledgements 750 Thanks to Stuart Cheshire for the original hybrid proxy draft and 751 interesting discussion in Orlando, where I was finally convinced that 752 stateful Multicast DNS proxying is a bad idea. 754 Also thanks to Mark Baugher, Ole Troan and Shwetha Bhandari for 755 review comments. 757 Author's Address 759 Markus Stenberg 760 Helsinki 00930 761 Finland 763 Email: markus.stenberg@iki.fi