There's been some discussion about service discovery. Anyone who prints wirelessly from their iPhone or iPad without typing in an IP address is using service discovery. Anyone who’s watched video on a web page on their iPad, and then tapped the screen to transfer the video playback to their television, without typing in its IP address, is using service discovery. Anyone who’s streamed music from their iPhone to their wireless AirPlay speakers, or controlled their TiVo from its iPad app, or shown a slide show from their phone on a friend's television screen, or given a university lecture by beaming their presentation wirelessly from their laptop to the video projector, all without typing in any names or IP addresses, has been using service discovery.
This is all commonly done today, but generally only on the local link. We'd like similar ease of use in larger networks too. I recently submitted this draft: <http://www.ietf.org/id/draft-cheshire-mdnsext-hybrid-01.txt> This Hybrid Proxy proposal talks about how information gets into the DNS namespace, but how does that data get back out again? Some people have asked me for a more detailed description of exactly how clients perform the unicast queries. I thought I'd illustrate the process using a familiar example we've been using for many years here at IETF: Printing to the Terminal Room printer. Here’s a detailed step-by-step walkthrough of how we find the IETF Terminal Room printer, starting with DHCP, and ending with a TCP connection sending the data to the printer. When you print from your Mac or iPhone, and give no second thought to how it magically knew about the IETF Terminal Room printer, this is what it's doing under the covers. First, let’s see what my Mac learned from the local DHCP server: > % scutil > > list > ... > subKey [74] = > State:/Network/Service/21B5304C-C227-4932-BFCF-54B28F4CA1D2/DHCP > ... > > > show State:/Network/Service/21B5304C-C227-4932-BFCF-54B28F4CA1D2/DHCP > <dictionary> { > Option_15 : <data> 0x6d656574696e672e696574662e6f7267 > ... > } Option_15 is Domain Name. What domain name? > % echo 6d656574696e672e696574662e6f7267 0A | xxd -r -p > meeting.ietf.org Great. Does meeting.ietf.org recommend we look in any Wide Area Service Discovery domains? > % dig lb._dns-sd._udp.meeting.ietf.org. ptr > > ; <<>> DiG 9.6-ESV-R4-P3 <<>> lb._dns-sd._udp.meeting.ietf.org. ptr > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35624 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4 > > ;; QUESTION SECTION: > ;lb._dns-sd._udp.meeting.ietf.org. IN PTR > > ;; ANSWER SECTION: > lb._dns-sd._udp.meeting.ietf.org. 3600 IN PTR meeting.ietf.org. > > ... > > ;; Query time: 8 msec > ;; SERVER: 130.129.5.6#53(130.129.5.6) > ;; WHEN: Wed Mar 13 10:16:40 2013 > ;; MSG SIZE rcvd: 188 Note, I can ask *any* DNS server this question and I will get the same answer. Let’s ask Google DNS instead: > % dig @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr > > ; <<>> DiG 9.6-ESV-R4-P3 <<>> @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24571 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;lb._dns-sd._udp.meeting.ietf.org. IN PTR > > ;; ANSWER SECTION: > lb._dns-sd._udp.meeting.ietf.org. 1532 IN PTR meeting.ietf.org. > > ;; Query time: 21 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Wed Mar 13 10:18:27 2013 > ;; MSG SIZE rcvd: 64 I still get the same answer. The DNS server I ask doesn’t have to be “on” my “local” network (whatever that means). I’m in Florida. Google DNS is I-don’t-know-where, 13 hops away, but it still gives the right answer. > % traceroute -q 1 8.8.8.8 > traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets > 1 rtra (130.129.80.2) 1.369 ms > 2 75-112-170-148.net.bhntampa.com (75.112.170.148) 14.494 ms > 3 bun2.tamp20-car1.bhn.net (71.44.3.73) 19.558 ms > 4 hun0-0-0-0-tamp20-cbr1.bhn.net (72.31.117.156) 20.730 ms > 5 xe-8-2-0.bar1.tampa1.level3.net (4.53.172.9) 13.052 ms > 6 ae-5-5.ebr1.miami1.level3.net (4.69.148.213) 27.413 ms > 7 ae-1-51.edge1.miami2.level3.net (4.69.138.75) 15.552 ms > 8 google-inc.edge1.miami2.level3.net (4.59.240.26) 48.852 ms > 9 209.85.253.118 (209.85.253.118) 21.118 ms > 10 216.239.48.192 (216.239.48.192) 21.890 ms > 11 216.239.48.192 (216.239.48.192) 23.221 ms > 12 * > 13 google-public-dns-a.google.com (8.8.8.8) 32.961 ms (For the rest of this example I'll use Google DNS for all the queries.) In this case the PTR is self-referential — meeting.ietf.org is advising us to look in meeting.ietf.org, but it could easily be set up to direct us elsewhere. But in this case it’s suggesting we look for services in meeting.ietf.org, so let’s do that: A Mac with appropriate printer drivers installed will look for this service: > % dig +short @8.8.8.8 _pdl-datastream._tcp.meeting.ietf.org. ptr > term-printer._pdl-datastream._tcp.meeting.ietf.org. There’s one printing service available here, called “term-printer”. That’s what you see when you press the “+” button in the Print & Fax Preference Pane on Mac OS X. To actually use it, the client uses this: > % dig +short @8.8.8.8 term-printer._pdl-datastream._tcp.meeting.ietf.org. srv > 0 0 9100 term-printer.meeting.ietf.org. > > % dig +short @8.8.8.8 term-printer.meeting.ietf.org. AAAA > 2001:df8::48:200:74ff:fee0:6cf8 So, to use this printer, the Mac connects to [2001:df8::48:200:74ff:fee0:6cf8]:9100, and uses the installed printer driver, which speaks the appropriate vendor-specific printing protocol for that printer. If you’re using an iPhone then you don’t have vendor-specific printer drivers installed; instead it uses this generic IPP-based printing service: > % dig +short @8.8.8.8 _universal._sub._ipp._tcp.meeting.ietf.org. ptr > term-printer._ipp._tcp.meeting.ietf.org. There’s one IPP-based printing service available here, called “term-printer”. Same name as the pdl-datastream printing service, and same physical hardware, but different printing protocol. To actually use it, the client uses this: > % dig +short @8.8.8.8 term-printer._ipp._tcp.meeting.ietf.org. srv > 0 0 631 term-printer.meeting.ietf.org. > > % dig +short @8.8.8.8 term-printer.meeting.ietf.org. aaaa > 2001:df8::48:200:74ff:fee0:6cf8 Note: Same address as before, but different port number. To use this printer, the iPhone connects to [2001:df8::48:200:74ff:fee0:6cf8]:631, and uses IPP to print. And that, ladies and gentlemen, is how automatic Wide Area DNS-Based Service Discovery works. Here at IETF, the records are added to the DNS manually by our capable network volunteers. The idea of the Hybrid Proxy is to populate the DNS namespace automatically, making Wide Area DNS-Based Service Discovery available to a broader community of users. Stuart Cheshire
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
