Subject: [homenet] Wide Area DNS-Based Service Discovery walkthrough

From: Stuart Cheshire <[email-masked]>
Date: Wed, 13 Mar 2013 22:21:04 -0700

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 22:45:22 -0700

On 03/13/2013 10:21 PM, Stuart Cheshire wrote:
>
> This is all commonly done today

The problem here is that you actually believe this.

Mike

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 14 Mar 2013 07:55:44 +0100 (CET)

> The problem here is that you actually believe this.

I know plenty people who do this (airplay), and I know others who would do 
this if they could get it working easily (they have one vendor TV and a 
different vendor smartphone which doesn't support a common protocol for 
the smartphone to tell the TV to start playing whatever was being watched 
on the smartphone). Apple Airplay works ok, but I only get it working 
between Apple devices. I'm sure there are other vendor specific protocols 
that do similar things.

Let's put this into a different perspective:

If service discovery and resulting address independence doesn't work, then 
it's going to be a pain to renumber. With SD, I imagine that changing 
addresses in the home (with PD etc) wouldn't impact the user experience in 
a fatal way, thus removing some of the need for ULAs (which I think is an 
ugly hack considering current state of RA handling in devices where it's 
all-or-nothing for putting a default route towards the RA announcing 
device).

Things should be addressed by DNS or alike, and they should have unique 
names/identifiers. Never should an IPv4 or IPv6 address be used. SD needs 
to just work, and it needs to work in a routed home, and preferrably it 
should work from the Internet as well.

Vision statement: I want to be able to use IPSEC to talk to everything in 
my home from whereever I am, and the authorisation to talk to my home 
devices should come from common key/cert management.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Mar 2013 07:15:18 -0400

> The problem here is that you actually believe this.

Stuart's description certainly matches what I have observed.  What is
it you thought was false?  Note that he went out of his way to use
Apple examples, so the cross-vendor issues that plague this sort of
behaviour aren't an issue.  (I'd like that not to be true, of course,
but that's not directly relevant to SD issues.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2013 05:40:44 -0700

> but that's not directly relevant to SD issues.)

The assertion that it is "common". It isn't. It's a way to amaze
your friends. It's also irksome that "common" assumes a uniformity
of i's and airs as you mention. There is no inevitability to the status
quo, and we shouldn't proceed from that assumption. We should get
on with the job of defining requirements for the long run.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2013 05:55:43 -0700

On 03/13/2013 11:55 PM, Mikael Abrahamsson wrote:
>
> I know plenty people who do this (airplay), and I know others who would do this if they could get it working easily (they have one vendor TV and a different vendor smartphone which doesn't support a common protocol for the smartphone to tell the TV to start playing whatever was being watched on the smartphone). Apple Airplay works ok, but I only get it working between Apple devices. I'm sure there are other vendor specific protocols that do similar things.
>
> If service discovery and resulting address independence doesn't work, then it's going to be a pain to renumber. With SD, I imagine that changing addresses in the home (with PD etc) wouldn't impact the user experience in a fatal way, thus removing some of the need for ULAs (which I think is an ugly hack considering current state of RA handling in devices where it's all-or-nothing for putting a default route towards the RA announcing device).
>
> Things should be addressed by DNS or alike, and they should have unique names/identifiers. Never should an IPv4 or IPv6 address be used. SD needs to just work, and it needs to work in a routed home, and preferrably it should work from the Internet as well.
>
> Vision statement: I want to be able to use IPSEC to talk to everything in my home from whereever I am, and the authorisation to talk to my home devices should come from common key/cert management.
>

This nicely circles back to what I was originally asking for: requirements. The
problem with section 3.7.1 is that it immediately dives into a particular solution
space without an iota of discussion of what we require the solution to actually
provide. I for one am not comfortable without those requirements to say that
a particular solution is right, especially when coupled with extraordinary claims
that this is "common" when it is plainly not.

Mike

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Mar 2013 09:30:21 -0400

On Thu, Mar 14, 2013 at 05:40:44AM -0700, Michael Thomas wrote:
> 
> The assertion that it is "common". 

Ok.  Instead of getting into a fight about an empirical matter best
resolved by doing a study of human behaviour (a capability that is
mostly probably outside our collective expertise), can we just say
that SD is used by some significant number of people in some cases,
and that it is useful?

> There is no inevitability to the status

Is there something about service discovery that you think we should
not be doing?  It sure seems to me like it is a friendlier answer than
manual configuration.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Mar 2013 09:32:29 -0400

On Mar 14, 2013, at 8:40 AM, Michael Thomas <[email-masked]> wrote:
> of i's and airs as you mention.

Michael, with all due respect, you are out to lunch here.   It is how a lot of people connect their speakers to the device that they use to play recorded music.   It is how a lot of people watch TV.   It's true that this stuff is more commonly used in the younger generations, but its use is quite widespread, and will become more widespread over time.  So we have to talk about it in the architecture document, or the document will be irrelevant.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Mar 2013 09:38:53 -0400

On Mar 14, 2013, at 9:32 AM, Ted Lemon <[email-masked]> wrote:
> So we have to talk about it in the architecture document, or the document will be irrelevant.

I have been reminded to point out that all of the discussion I've been having here has been with my AD hat off.   The above could certainly be interpreted as an AD statement, but that is not how I intended it.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2013 06:41:07 -0700

> Michael, with all due respect, you are out to lunch here.   It is how a lot of people connect their speakers to the device that they use to play recorded music.   It is how a lot of people watch TV…

Recall that my initial point is that the arch document should provide more
background, motivation and most especially requirements. There is *none*
of that right now. My push back about "common" is against the notion that
this is all self-evident. It's not.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2013 06:45:32 -0700

> not be doing?  It sure seems to me like it is a friendlier answer than

All I want is the document to say why we want it and what we want
it to do. I keep getting told this is all self-evident which sets my bs
detector off.

Is this really too much to ask for?

Mike

---

From: Simon Kelley <[email-masked]>
Date: Thu, 14 Mar 2013 13:50:03 +0000

On 14/03/13 05:21, Stuart Cheshire wrote:
> 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:
>
<snip very illuminating details>
>
> 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.

I'm concerned that that basis of this whole discovery mechanism is the 
"domain name" DHCP option.

The service discovery mechanism has now migrated to the DNS, so all 
services are potentially discoverable from anywhere; that's good. But 
the concept of what's "local" is now hung exclusively on the value of 
DHCP option 15. DHCP option 15 most be one of the most overloaded and 
least well characterised of any DHCP options. Lots of homenet-type 
installations will have it set to ".lan" or something similar. Some will 
set it to ".local" only to discover that the .local TLD has been 
usurped. It's used frequently as substitute for the "domain name search 
list" option but concatentating more than one domain with spaces, for 
clients which don't support the later option. It's somewhat succeeded by 
the FQDN option, and therefore not supplied. DHCPv6 doesn't have, AFAIR 
an equivalent, only the FQDN option.

Now, we want to overload with yet another meaning. Is that wise? 
Wouldn't defining a new option be better?

Simon.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Mar 2013 10:09:20 -0400

> it to do. I keep getting told this is all self-evident which sets my bs

Ok.  The -07 draft covers this in 3.7.1 for service discovery.  Is the
problem that it doesn't say what kinds of "services" are to be
discovered?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 14 Mar 2013 10:32:39 -0400

On Thu, Mar 14, 2013 at 9:45 AM, Michael Thomas <[email-masked]> wrote:

> It's a working group document.  Feel free to contribute text as well as
criticism.

-K-

> Mike
>
> ______________________________**_________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>

---

From: Yusuke DOI <[email-masked]>
Date: Thu, 14 Mar 2013 10:36:36 -0400

Hi,

Let me jump-in from home appliance manufacturer perspective.

> this is all self-evident. It's not.

As Chris mentioned in his presentation, protocols and services become 
complex day-by-day, but users don't. We can memorize many IP address, 
domain names, or URLs to select/specify communcation endpoint. But we 
cannot expect our home customers to do so.

Applications in home networks (including M2M applications like SEP2 but 
not limited to) naturally have their goal to communicate, but does not 
have a priori knowledge of the surrowinding environment. Thus they need 
some binding mechanism between a goal and communication endpoints that 
serve for the goal. In general, this kind of mechanism is called 
'service discovery'.

Hoping it helps the discussion.

// Yusuke DOI <[email-masked]>

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 14 Mar 2013 15:24:07 -0700

> The problem here is that you actually believe this.

You're right. I'm living in a fantasy world, where Apple shipped DNS-Based Service Discovery in August 2002, then went on make mobile telephones, tablet computers, and television set-top boxes that use it, even opened a chain of retail stores selling said products, and the Apple stock price skyrocketed from $10/share to as high as $40 or maybe even $50/share. (I could claim in my delusional fantasy world that the stock price went even higher than $50/share, but even my imagination is not that outlandish.)

Of course the truth is that none of these products ever existed, and these days Apple is long forgotten, and most IETF attendees  have never even heard of it.

Right, Michael?

Stuart Cheshire

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 15 Mar 2013 14:48:44 +0000

On 3/14/13 9:50 AM, "Simon Kelley" <[email-masked]> wrote:

>Lots of homenet-type
>usurped. 

With the new gTLDs this is certainly a concern. Definitely don't use .home
since there are many applicants. However, .local is reserved by ICANN so
it cannot in my understanding become a new gTLD per the gTLD guidebook,
section 2.2.1.2.1 "Reserved Names" (page 60 of the guidebook @
http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf).
 This may not be the point you were making but I thought there may be
concern over namespace overlap. :-)

- Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 15 Mar 2013 17:00:55 +0000

>concern over namespace overlap. :-)

On a related note, for reference, please see the ICANN SSAC doc released
today -- SAC057: SSAC Advisory on Internal Name Certificates -- at
http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf.

Jason