idnits 2.17.1 draft-bhandari-dnssd-mdns-gateway-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 20, 2013) is 3841 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 497, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-sekar-dns-llq-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnssd S. Bhandari 3 Internet-Draft B. Fajalia 4 Intended status: Informational R. Schmieder 5 Expires: April 23, 2014 S. Orr 6 A. Dutta 7 Cisco 8 October 20, 2013 10 Extending multicast DNS across local links in Campus and Enterprise 11 networks 12 draft-bhandari-dnssd-mdns-gateway-00 14 Abstract 16 This document describes the requirements for extending multicast DNS 17 in enterprise networks. It provides an overview of a solution to 18 extend multicast DNS services across links that have been implemented 19 in routers, switches and wireless LAN controllers. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 23, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions and Terminology Used in this Document . . . . . . 4 64 3. Solution overview . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Service Cache . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Service Filters . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Service Announcement . . . . . . . . . . . . . . . . . . . 6 68 3.4. Service Query . . . . . . . . . . . . . . . . . . . . . . 7 69 3.5. Service Probing . . . . . . . . . . . . . . . . . . . . . 7 70 3.6. Service update, Service withdrawal . . . . . . . . . . . . 7 71 3.7. Service Refresh . . . . . . . . . . . . . . . . . . . . . 7 72 3.8. mDNS Gateway for Wireless Network . . . . . . . . . . . . 8 73 3.8.1. Advertising services on wireless networks . . . . . . 8 74 3.8.2. Device Tracking . . . . . . . . . . . . . . . . . . . 8 75 3.8.3. Mobility Considerations . . . . . . . . . . . . . . . 9 76 3.8.4. mDNS traffic optimization . . . . . . . . . . . . . . 9 77 4. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 82 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 Service discovery using multicast DNS (mDNS) as defined in [RFC6762] 88 is limited in scope to L3 boundaries due to the use of link-local 89 scoped multicast addresses. Networks are partitioned into multiple 90 segments by means of virtual local area networks (VLANs) or subnet 91 creation for various reasons. The need for network wide, seamless 92 service discovery demands the extension of the discovery protocol 93 beyond the L3 boundary. There are also challenges in wireless 94 networks (802.11, 802.15.4 etc) where a large number multicast 95 messages can impact wireless performance. 97 Enabling Service Discovery across L3 boundaries can be accomplished 98 in one of the following ways using existing, unmodified protocols: 100 1. Unicast DNS-SD only: Use of DNS servers and allowing clients to 101 use dynamic DNS updates and Long Lived Queries (LLQs) to announce 102 and learn services dynamically [I-D.sekar-dns-llq] 104 2. mDNS only: Defining a mDNS gateway entity at the L3 boundaries 105 extending service advertisements/discovery across the links it is 106 attached to 108 3. Combination of unicast DNS and mDNS - Hybrid proxy approach as 109 described in [I-D.cheshire-mdnsext-hybrid] 111 4. mDNS utilizing extended scope multicast - Modifying mDNS to use a 112 wider scope multicast address for message exchange 114 As a first step, this draft lists out the approach to use a mDNS 115 gateway on a network element (2) to extend the service advertisement/ 116 discovery across network segments attached to the element. While 117 this approach does not preclude (1) or (3), it allows the extension 118 of service discovery in a limited number of segments with minimal 119 provisioning. Approach (4) is not explored further as it would add 120 to the flood of service discovery messages in the scope defined by 121 the multicast address and it would also require changes on mDNS 122 clients, which is undesirable. 124 1.1. Requirements 126 This section describes requirements for extending multicast DNS in an 127 enterprise environment: 129 1. Extend service discovery across L3 boundaries 131 2. Defining and enforcing a policy to selectively filter services 132 that are to be extended based on service type, service instance, 133 location of the provider/user, role of the device or user 134 accessing/offering the service. 136 3. Defining and enforcing a policy to selectively filter queries 137 and announcements from specific clients or over specific network 138 links 140 4. Filtering of link-local-only information - Services that resolve 141 to IPv4 and IPv6 link-local addresses only must not be extended 142 beyond the local link. Suppression of resource records that 143 contain link-local-only addresses from propagation beyond the 144 local link 146 5. Optimization of mDNS queries/advertisements in wireless networks 148 6. Effectively handle roaming of mobile devices (changes in the 149 Point of Attachment). Especially if those devices advertise 150 services 152 7. Limit the services in response to queries with a subset of the 153 services by geographic proximity 155 8. Handle conflict resolution of service instances and host names 156 across the links where the service is extended 158 9. Protection of resources (memory and CPU) of the network element 159 that participates in extending multicast DNS 161 10. Audit, logging of services that are denied based on policy 163 2. Conventions and Terminology Used in this Document 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in "Key words for use in 168 RFCs to Indicate Requirement Levels" [RFC2119]. 170 This document uses the multicast DNS and DNS terminology conventions 171 from [RFC6762] and [RFC6763]. It uses the same convention for 172 services on the same link as defined in 173 [I-D.cheshire-mdnsext-hybrid], repeated here for quick reference: 175 Multicast DNS works between a hosts on the same link. A set of hosts 176 is considered to be "on the same link", if: 178 when any host A from that set sends a packet to any other host B in 179 that set, using unicast, multicast, or broadcast, the entire link- 180 layer packet payload arrives unmodified, and 182 a broadcast sent over that link by any host from that set of hosts 183 can be received by every other host in that set 185 The link-layer *header* may be modified, such as in Token Ring Source 186 Routing [802.5], but not the link-layer *payload*. In particular, if 187 any device forwarding a packet modifies any part of the IP header or 188 IP payload then the packet is no longer considered to be on the same 189 link. This means that the packet may pass through devices such as 190 repeaters, bridges, hubs or switches and still be considered to be on 191 the same link for the purpose of this document, but not through a 192 device such as an IP router that decrements the TTL or otherwise 193 modifies the IP header. 195 o mDNS gateway - An application that listens to services and extends 196 the services across links 198 3. Solution overview 200 The solution introduces the mDNS gateway function which is co-located 201 on the network element that connects to multiple links, typically an 202 IP router. The mDNS gateway function will be responsible for: 204 o Caching - Learn and cache services. Maintain services in the 205 cache according to service announcements, service removals and the 206 TTL of the records. 208 o Respond to queries - Advertise in response to queries with 209 services in the cache that are not in the same link-local domain 210 where the query is received. 212 o Service filtering - Filter services to be added to the cache and 213 to be included in the advertisements as per configured policies. 215 o Service redistribution - forwarding of unsolicited service 216 announcements across links based on configuration 218 o Active query - Service queries sent by the mDNS gateway itself to 219 learn about services or keep services 'fresh' in the cache. Can 220 be sent on one or more of the links the gateway is attached to. 222 3.1. Service Cache 224 The mDNS gateway maintains a database of DNS Resource Records (RR) 225 required to advertise and resolve services. At a minimum, the cache 226 will contain PTR, SRV,TXT and A/AAAA RRs for each service with NSEC 227 RR support for optimization. In addition, the link on which the 228 service and host originate is also maintained in the cache. Records 229 in the cache are refreshed based on TTL expiry. 231 3.2. Service Filters 233 A service filtering policy is configured with an action to permit or 234 deny services into the cache or to filter services included in the 235 response/advertisement messages based on matching criteria. The 236 matching criteria can be defined based on: 238 o Service type 240 o Service instance names 242 o Link on which the message is received 244 o Type of message - query or advertisement 246 o Location of the host querying or advertising a service 248 A Service filtering policy is applied for incoming and outgoing 249 messages. A unique filtering policy can be applied Globally or per 250 link. 252 When a mDNS message is received by the mDNS gateway matching an 253 action set for the link, the policy match is then executed. The 254 incoming advertisement is processed against the mDNS gateway inbound 255 filtering policy applied on the link where the advertisement is 256 received. If the action is 'permit' the service is added to the 257 cache. If a response or advertisement is to be sent out, the 258 outbound filtering policy applied applied on the interface is 259 processed and if the resulting action is 'deny' then the service and 260 its corresponding RRs are not included in the message sent out. 262 3.3. Service Announcement 264 The mDNS gateway listens for all service announcements. When a 265 service announcement is received, the announcement and all the 266 additional RRs learnt are added to the cache or ignored based on the 267 result of the configured inbound filter policy. 269 The RRs containing link-local information e.g. A or AAAA RRs that 270 contain link-local scoped IPv4 or IPv6 addresses are not stored in 271 the cache. 273 When the mDNS gateway learns a service it can also forward the 274 advertisement on other attached links. 276 3.4. Service Query 278 The mDNS gateway processes all queries against the configured 279 filtering policy. If the response to the query is permitted then it 280 constructs the answers and additional records required to resolve the 281 service from its cache for the services that are permitted. Services 282 that reside on the same link where the query is received are not 283 included as the owner of the service will also see the query and 284 would send the response directly. Only services learnt from 285 different links are considered in the response. 287 Any query received for additional RRs to resolve the service e.g. 288 query for SRV, A, AAAA etc are responded to in the same way. If the 289 records do not exist in the cache due to expiry or purging of cache 290 for any other reason, mDNS gateway sends out an explicit query to 291 fetch the records on the link where the service resides. 293 3.5. Service Probing 295 According to [RFC6762] before registering a service, RR probing is 296 performed to ensure unique names. As the mDNS gateway maintains a 297 cache of all the RRs that are extended across the links it responds 298 to probe records like any other query. This will help in detecting 299 and resolving name space conflicts across links where service 300 discovery has been extended. 302 3.6. Service update, Service withdrawal 304 When the mDNS gateway receives a service update or withdrawal it 305 updates or removes the service and all corresponding records from its 306 cache. It forwards the withdraw messages to other attached links. 308 3.7. Service Refresh 310 The RRs describing the service and resolving it have a TTL that 311 defines the validity of the RR. The mDNS gateway can continuously 312 refresh each of the RRs in the cache as per the TTL rules. For the 313 purpose of optimization, the mDNS gateway can rely on the host 314 interested in the RRs to trigger a refresh by setting the TTLs in the 315 response to the time remaining since the record was learnt by the 316 mDNS gateway. If a client is interested in the RR then it would 317 trigger a refresh when a fraction of the TTL is reached. While 318 responding to queries from hosts, the mDNS gateway inturn sends out 319 queries to refresh the records that are about to expire on the source 320 link where the records were learnt. 322 3.8. mDNS Gateway for Wireless Network 324 Deploying the mDNS gateway in wireless networks has a few additional 325 requirements w.r.t to multicast radio optimization and mobility 326 aspects. This section describes some additional capabilities added 327 to the mDNS gateway to satisfy these requirements. 329 3.8.1. Advertising services on wireless networks 331 In order to conserve wireless bandwidth, the mDNS gateway sends 332 service advertisements as L2 unicast messages to wireless devices . 334 In a wireless network, the mDNS gateway co-located on the network 335 element that is providing the wireless service can act as a passive 336 device and respond only if wireless clients send a mDNS query. When 337 bridging is turned off the mDNS gateway and the Layer 2 optimazation 338 is enabled, the mDNS gateway will need to send the query responseas 339 layer 2 unicast messages even when the provider is on the same link 340 as the requestor. Bridging of mDNS messages can be turned off based 341 on configuration. This is useful in the following scenario: 343 1. Save computation resources on the device which are used to 344 replicate the multicast packet as a L2 unicast for all wireless 345 clients. 347 2. If the wireless client is in power saving mode, sending a mDNS 348 advertisement as a L2 unicast would forcefully awake the client 349 and it would result into more power consumption by the wireless 350 client. 352 mDNS functionality is not impacted by acting as a passive gateway 353 because the client would always send the mDNS query when inquiring 354 for a service. 356 3.8.2. Device Tracking 358 Wireless clients are mobile in nature. The mDNS gateway should learn 359 the service instance only from the authenticated wireless client. 360 The mDNS gateway should tag each service instance from a wireless 361 client with the client's MAC address. This MAC address should be 362 used for device tracking. If the wireless client leaves the network, 363 the mDNS gateway should not wait until the TTL expires but it should 364 actively clean up the service instance provided by that wireless 365 client. This is done to protect the mDNS gateway cache resources as 366 well as to keep other clients from hearing about services that are no 367 longer connected to the network.. 369 3.8.3. Mobility Considerations 371 Wireless deployments supports seamless mobility. In such a scenario, 372 the mDNS gateway needs to be aware of the client location. If the 373 location changes, the mDNS gateway needs to update its mDNS cache. 374 The mDNS gateway should tag each service instance with the device 375 location. The device location can be derived based on the Access 376 Point (AP) to which the wireless client is attached. If the client, 377 which is providing any service, changes its location, this change 378 needs to be reflected in the mDNS gateway. If the client roams from 379 one mDNS gateway to another mDNS gateway, then the old gateway should 380 provide the service instance information pertaining to the roamed 381 client to the new gateway and then it must clear the mDNS cache for 382 that particular client. If the mDNS gateway is not acting as a 383 passive gateway, it may choose to update the network about the new 384 service instance it has learnt. 386 3.8.4. mDNS traffic optimization 388 All mDNS packets are sent to the multicast link-local IP address. 389 When the mDNS gateway starts forwarding the mDNS advertisements 390 across L3 boundaries then the number of such advertisement on any 391 network would increase. Wireless networks should be optimized for 392 the increase in mulitcast traffic that will be generated by extending 393 the service advertisement domain. If there are many mDNS packets 394 going on air then it would impact other data traffic. Hence mDNS 395 traffic optimization is required. One method of optimization the 396 mDNS gateway could implement is sending the query reponse back as a 397 L2 unicast to the requesting client. 399 When services are advertised, each record has an associated TTL 400 value. When the TTL expires, the gateway needs to send a query (at 401 85%, 90% and 95% of the TTL) for that record to confirm its validity. 402 If the TTL value of each record is different, then mDNS gateway needs 403 to send a query for individual records. To minimize the mDNS 404 traffic, queries for multiple RRs for that service record set can be 405 initiated towards the source of the service. Such a query can be 406 sent with the QU bit set as described in [RFC6762] to solicit a 407 unicast response. 409 The mDNS gateway for wireless networks should act as a passive 410 gateway as explained in Section 3.8.1. When it is acting as a 411 passive gateway and bridging of mDNS packets is turned off it has to 412 respond to queries on the link even when the provider of the service 413 resides on the same link. 415 4. Challenges 417 This section lists out limitations and challenges faced as part of 418 the the solution described in this draft. 420 1. Name conflict resolution across links: Name conflict resolution 421 depends on probing followed by service registration. This is 422 done by the host which is providing the service. Name conflict 423 resolution across links depends on the mDNS gateway cache to have 424 a conclusive list of names already present to be able to 425 authoritatively respond to probe requests. However, this may not 426 always be posible due to timing issues when the cache gets 427 updated, records having expired from the cache etc. 429 2. Multi-homed hosts: There is also the case of a multihomed host 430 connected via multiple links to the same mDNS gateway that may 431 end up wrongly assuming conflict and getting into a continuous 432 renaming loop. 434 3. Multiple mDNS gateways on the link: If there are multiple mDNS 435 gateways enabled on the same link queries may get duplicate 436 responses. 438 4. Loops in the network: If there is a loop in the network with 439 multiple mDNS gateways enabled in such a topology it may end up 440 continuously cycling the service around the loop and keeping the 441 RRs alive forever. 443 5. Refreshing resource records: Balancing an excessive number of 444 queries to maintain the records in the cache vs. having the cache 445 up-to-date with all the known record names requires optimizations 446 that may lead to corner cases where wrong results or conflicts 447 arise. 449 5. Future work 451 The solution documented here is limited to extending services across 452 links attached to a single network element or mDNS gateway. For a 453 broader application, the service discovery solution described in 454 [I-D.cheshire-mdnsext-hybrid] should be realized with any 455 provisioning as needed. 457 Similar to auto provisioning and realization of the hybrid proxy 458 approach for homenet as described in 459 [I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf] a solution needs to 460 be built for enterprise and campus networks extending what has been 461 described in this draft. 463 There are other considerations such as including the location 464 information so that services can be ordered based on proximity of the 465 service. 467 6. IANA Considerations 469 This document makes no request of IANA. 471 Note to RFC Editor: this section may be removed on publication as an 472 RFC. 474 7. Security Considerations 476 N/A 478 8. Acknowledgements 480 9. Normative References 482 [I-D.cheshire-mdnsext-hybrid] 483 Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service 484 Discovery", draft-cheshire-mdnsext-hybrid-02 (work in 485 progress), July 2013. 487 [I-D.sekar-dns-llq] 488 Sekar, K., "DNS Long-Lived Queries", 489 draft-sekar-dns-llq-01 (work in progress), August 2006. 491 [I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf] 492 Stenberg, M., "Hybrid Unicast/Multicast DNS-Based Service 493 Discovery Auto-Configuration Using OSPFv3", 494 draft-stenberg-homenet-dnssdext-hybrid-proxy-ospf-00 (work 495 in progress), June 2013. 497 [RFC1035] Mockapetris, P., "Domain names - implementation and 498 specification", STD 13, RFC 1035, November 1987. 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, March 1997. 503 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 504 February 2013. 506 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 507 Discovery", RFC 6763, February 2013. 509 Authors' Addresses 511 Shwetha Bhandari 512 Cisco Systems, Inc. 513 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 514 Bangalore, KARNATAKA 560 087 515 India 517 Email: shwethab@cisco.com 519 Bhavik Fajalia 520 Cisco Systems, Inc. 521 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 522 Bangalore, KARNATAKA 560 087 523 India 525 Email: bfajalia@cisco.com 527 Ralph Schmieder 528 Cisco Systems, Inc. 529 City Plaza - 4th Floor 530 Stuttgart, BADEN-WURTTEMBERG 70178 531 Germany 533 Email: rschmied@cisco.com 535 Stephen Orr 536 Cisco Systems, Inc. 537 1 Paragon Drive 538 Montvale, NJ 07645 539 USA 541 Email: sorr@cisco.com 542 Amit Dutta 543 Cisco Systems, Inc. 544 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 545 Bangalore, KARNATAKA 560 087 546 India 548 Email: amdutta@cisco.com