Subject: [homenet] Naming and Service Discovery

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2013 12:05:24 -0300

Folks,

Just to kick some discussion:

Regarding naming and service discovery, it seems that there are folks
that are in the camp of "let's make mDNS work on multiple segments",
while others seem to be in the camp of "this should be done with DNS".

May I introduce a third option? mDNS for the local net, DNS to glue the
multiple segments. That way, there's no additional code needed on the
clients, no extensions needed for DNS, and just some software on the
boxes linking the different network segments.

I could draft something along these lines, if there's interest.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 26 Feb 2013 15:30:46 +0000

So far the problem I have seen with authoritative DNS is one still needs
to know what to ask for, the benefit of service discovery is what is
available is being announced.

Unless I missed something I do not beleive the latter has been part of the
discussions specific to authoritative DNS.

John
=========================================
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
e) [email-masked]
o) 609-377-6594
w) www.comcast6.net
=========================================

-----Original Message-----
From: Fernando Gont <[email-masked]>
Date: Tuesday, February 26, 2013 7:05 AM
To: "[email-masked]" <[email-masked]>
Subject: [homenet] Naming and Service Discovery

>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2013 12:41:45 -0300

> available is being announced.

You could have some kind of magic name that identifies services, and has
PTR records with host names in it. If that's not enough, you could have
a magic "all current services" magic name, which would contain PTR
records (or something similar to data) pointing to the previous records
I mentioned.

-- After all, you typically want the list of services/services when you
want to do something (browse the net, play some music, etc.). That is,
that of having to ask shouldn't be a problem -- and, actually, may
probably scale easier/better than broadcasting stuff.

Cheers,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Feb 2013 11:29:55 -0500

> boxes linking the different network segments.

I think that's what the mdns guys are talking about doing.   I think it's a bad idea.   It doesn't solve the multihoming problem; it's hard to figure out what problem it _does_ solve that can't be solved better using existing technology.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Feb 2013 08:55:15 -0800

> I think that's what the mdns guys are talking about doing.   I think it's a bad idea.   It doesn't solve the multihoming problem; it's hard to figure out what problem it _does_ solve that can't be…

Anything that keeps with the absurdity of "refrigerator.local" being
ambiguous because I'm halfway between mine and my neighbor's
house connecting back and forth on our wifi's is a bad situation. We
should stop the care and feeding that bad solution right now.

Mike

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2013 13:55:45 -0300

On 02/26/2013 01:29 PM, Ted Lemon wrote:
>
>> May I introduce a third option? mDNS for the local net, DNS to glue
>> the multiple segments. That way, there's no additional code needed
>> on the clients, no extensions needed for DNS, and just some
>> software on the boxes linking the different network segments.
> 
> I think that's what the mdns guys are talking about doing.

My understanding was that they were going to extend mDNS to work on
multiple segments, rather than gluing mDNS "islands" with DNS... but I
have not really followed the discussions in the mdnsext.

> I think
> it's a bad idea.   It doesn't solve the multihoming problem; it's
> hard to figure out what problem it _does_ solve that can't be solved
> better using existing technology.

Is there a requirements list for what naming/service discovery should
achive? i.e., are those requirements documented? -- because that would
be step #1 here. (yes, there are general requirements in the homenet
charter, but was wondering if something had been written for naming and
service discovery).

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Feb 2013 17:09:38 +0000

On 26/02/2013 16:55, Michael Thomas wrote:
>> I think that's what the mdns guys are talking about doing.   I think
>> it's a bad idea.   It doesn't solve the multihoming problem; it's hard
>> to figure out what problem it _does_ solve that can't be solved better
>> using existing technology.
>>
> 

Yes. It beats me why we don't just do a gap analysis for making
real DNS work in the home.

   Brian

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 26 Feb 2013 17:22:41 +0000

-----Original Message-----
From: Fernando Gont <[email-masked]>
Date: Tuesday, February 26, 2013 8:55 AM
To: Ted Lemon <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [homenet] Naming and Service Discovery

>have not really followed the discussions in the mdnsext.
[jjmb] I thought this was one of the goals as well.

>charter, but was wondering if something had been written for naming and
[jjmb] there may be words, hard to say of if they are accurate.  I confess
I have not read them closely lately.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Feb 2013 13:32:48 -0500

On Feb 26, 2013, at 11:55 AM, Fernando Gont <[email-masked]> wrote:
> achive?

http://tools.ietf.org/html/draft-ietf-homenet-arch-07#section-3.7

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Feb 2013 14:35:44 -0500

>>>>> "Fernando" == Fernando Gont <[email-masked]> writes:
    Fernando> Regarding naming and service discovery, it seems that
    Fernando> there are folks that are in the camp of "let's make mDNS
    Fernando> work on multiple segments", while others seem to be in the
    Fernando> camp of "this should be done with DNS".

    Fernando> May I introduce a third option? mDNS for the local net,
    Fernando> DNS to glue the multiple segments. That way, there's no
    Fernando> additional code needed on the clients, no extensions
    Fernando> needed for DNS, and just some software on the boxes
    Fernando> linking the different network segments.

You are saying that we would reduce the problem of getting something
like dynamic DNS update working on every printer and TV appliance, into
the problem of getting dynamic DNS working on at least one router that
listens on every subnet on which mDNS is enabled.

I think that this would please the campus people well, as it would give
them the control that I think that they need, while not risking flooding
mDNS in places unseen.

I think that this will also please the router and switch vendors,
because on many campuses (campii?) LANs are defined by VLAN-type
technology, and having more smarts in switches sells more switches :-)

I think that this will please the home user because mostly nothing
changes. 

I think that this will please homenet because we have already much
discussion about the desire for stable forward DNS names, and the need
for ISPs to delegate things, and this works very well into that
architecture.

It might also please the IESG, because it makes mdnsext likely
unnecessary: your proposed document is a BCP, no new protocols required.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Feb 2013 14:46:59 -0500

> listens on every subnet on which mDNS is enabled.

Ah, I read this wrong.   This does actually make a certain amount of sense.   Beware though that it is not as simple a problem as you might first imagine, because mDNS deals poorly with name clashes, and name clashes when switching subnets are par for the course, because the name in the old location persists for longer than the time it takes to switch networks.

---

From: Ole Troan <[email-masked]>
Date: Tue, 26 Feb 2013 21:16:15 +0100

> have not really followed the discussions in the mdnsext.

see:
http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Feb 2013 19:08:23 -0500

> http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01

Wow, that's all IPR'd up...

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Feb 2013 23:53:35 -0500

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:

    >> You are saying that we would reduce the problem of getting
    >> something like dynamic DNS update working on every printer and TV
    >> appliance, into the problem of getting dynamic DNS working on at
    >> least one router that listens on every subnet on which mDNS is
    >> enabled.

    Ted> Ah, I read this wrong.  This does actually make a certain
    Ted> amount of sense.  Beware though that it is not as simple a
    Ted> problem as you might first imagine, because mDNS deals poorly
    Ted> with name clashes, and name clashes when switching subnets are
    Ted> par for the course, because the name in the old location
    Ted> persists for longer than the time it takes to switch networks.

So, my take on this is that you mean, mdnsext might actually have some work to do.
    - improve name clashes due to subnet switching.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ray Hunter <[email-masked]>
Date: Wed, 27 Feb 2013 08:35:09 +0100

Ole Troan wrote:
>From the quoted draft: "for the purposes of this document, assume that
each link has its own unique Unicast DNS domain name",
which I don't think is acceptable in Homenet. I don't want my phone's
name to change when I walk out to the shed.

---

From: Ole Troan <[email-masked]>
Date: Wed, 27 Feb 2013 08:51:12 +0100

> name to change when I walk out to the shed.

in a service discovery world, would you even care about what the phone's name is?
does a name really have any meaning without a service associated with it?

let us assume that we don't want anyone to remember these names. the UI will present a list 
of available services, given where you are.

in that sense I really don't care what the domain name for my local link or site is either.
internally I don't use them, for access into my home when I'm outside I need to type in the externally visible
domain into my service discovery domain registry once.

cheers,
Ole

---

From: Ray Hunter <[email-masked]>
Date: Wed, 27 Feb 2013 09:46:09 +0100

> Ole Troan <mailto:[email-masked]>
> 27 February 2013 08:51
>
>
Theoretically fine, but in combination with autoconfig of links, the
domain names are also likely to be meaningless and changing, which means
service discovery becomes a "must" for all homenet nodes. And there's
the possibility of difficult to debug name clashes as "myphone" or
"mygamestation" moves between links. 
> does a name really have any meaning without a service associated with it?
URLs have meaning (rfc1738). It's going to be tough to know when your
browser (connecting from off-net) can cache
http://myphone.building1.isp1.com or not. Cookie handling too (keyed on
URL, which is hard linked to hostname, which will change when the phone
moves to http://myphone.building2.isp1.com).

Or is there some magic to handle this that scales to the whole Internet?

At least if just the IPv6 address changed we'd only have to deal with
caching hostname -> IPv6 addresses lookups.
> of available services, given where you are.
Right, but the FQDN changes every time a device moves, not just the
address, which either means large amounts of service discovery traffic
(like Appletalk ZIP/NBP + "the Finder" which had huge scaling issues),
or large amounts of update traffic plus potential caching issues of
anything linked to URL (and in turn to hostname).

> cheers,
> Ole
> Ray Hunter <mailto:[email-masked]>
> 27 February 2013 08:35
> ------------------------------------------------------------------------

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Feb 2013 09:26:19 -0500

>    - improve name clashes due to subnet switching.

Oh no, I think name clashes are already too good.   I want mdnsext to get rid of them! :)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Feb 2013 09:35:38 -0500

> of available services, given where you are.

Why would we assume that?   Devices have names.   My phone has a name, my laptop has a name.   How else would I know which device I was talking to?   I don't want my phone to just be "iPhone" in the discovery list.   And if it has a name, I want it to have the same name everywhere.   Adding an extra layer of indirection doesn't make that problem any easier.

This is a really important problem, and what you are proposing is moving in exactly the wrong direction: a multiply-indirected naming hierarchy that will almost certainly display artifacts that will confuse the heck out of users, because at the bottom of the hierarchy names aren't consistent.   We've seen examples of this in the past--I'm sure that Stuart and Dave can tell you war stories.

Keeping names consistent across subnets is possible.   It can definitely be done with DHCP, and there are RFCs documenting how it's done.   If it can be done with DHCP, it can be done with whatever protocol we settle on, whether it's DHCP, mDNS, DNS+CGA+TSIG, or some other thing.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Feb 2013 10:10:27 -0500

On Feb 27, 2013, at 9:55 AM, Michael Thomas <[email-masked]> wrote:
> if I really want to replenish its digital toothpaste, I'd almost
> certainly surf to https://mikestoothbrush.mtcc.com to make certain I'm
> not being tricked into resupplying ot.1027.holidayinn.com's toothbrush.

Where can I get one of these internet-retoothpasteable toothbrushes?

---

From: Mattia Rossi <[email-masked]>
Date: Wed, 27 Feb 2013 17:22:00 +0100

> This is a really important problem, and what you are proposing is moving in exactly the wrong direction: a multiply-indirected naming hierarchy that will almost certainly display artifacts that wil…
I believe this is what Wide Area Bonjour does these days: If you use 
mDNS on one Network/Domain, you'll end up as mydevice.networkone.net, 
and if you move to another Network/Domain you'll end up as 
mydevice.networktwo.net
Still, someone from a third WAB network knows, that it's the same device 
(if the device name is unique enough - but in homenet that shouldn't be 
a problem). WAB works using a unicast DNS server, Long Lived Queries and 
Dynamic Updates per network segment.
I don't think that's the way to go in the homenet though.  WAB is 
intended to cross the boundaries of the home network, while we're 
talking what to do within the boundaries.  If we could cross subnets 
without DNS and without confusing domain names it would be better I think.
But as we might want to allow people who want a domain structure to set 
it up, it might be a good idea to recommend the inclusion of a DNS 
server capable of dynamic DNS updates in each homenet router...
Can be switched off by default... Might be something for a future draft 
"naming of devices in the homenet". Is anyone already working on 
something like that?

---

From: Michael Thomas <[email-masked]>
Date: Wed, 27 Feb 2013 06:40:17 -0800

> Why would we assume that?   Devices have names.   My phone has a name, my laptop has a name.   How else would I know which device I was talking to?   I don't want my phone to just be "iPhone" in th…

Indeed. I wonder how people would feel about fungible services like,
oh say, "toothbrush".

Mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Feb 2013 11:49:19 -0500

On Feb 27, 2013, at 11:22 AM, Mattia Rossi <[email-masked]> wrote:
> I believe this is what Wide Area Bonjour does these days: If you use mDNS on one Network/Domain, you'll end up asmydevice.networkone.net, and if you move to another Network/Domain you'll end up as mydevice.networktwo.net

This is certainly less bad than what CeroWRT does with mDNS across multiple subnets within the homenet now.

> Still, someone from a third WAB network knows, that it's the same device (if the device name is unique enough - but in homenet that shouldn't be a problem).

How do they know this?   And if they can know this, why not just use the same name in both places?   Would it be easy for me to create an attack based on the tendency for people to make assumptions like this, if such a tendency in fact exists?

> WAB works using a unicast DNS server, Long Lived Queries and Dynamic Updates per network segment.  I don't think that's the way to go in the homenet though.  WAB is intended to cross the boundaries of the home network, while we're talking what to do within the boundaries.

Yup.

> If we could cross subnets without DNS and without confusing domain names it would be better I think.
> But as we might want to allow people who want a domain structure to set it up, it might be a good idea to recommend the inclusion of a DNS server capable of dynamic DNS updates in each homenet router...
> Can be switched off by default...

If it's switched off by default, it won't work, so there's no point in specifying it.   I think what CeroWRT (and perhaps OpenWRT) do here is actually exactly right: it's on by default, but just uses a restricted domain.   If you want global naming, you can set it up.   I think more work on making this easy for a non-geek end-user to set up is worth doing, but I think it's actually a much better basis for naming on a homenet than mdns.

> Might be something for a future draft "naming of devices in the homenet". Is anyone already working on something like that?

We have Stuart's draft, which actually makes me even less enthusiastic about mDNS in this context, since apparently Apple's patented the use of mDNS to solve this problem. 

Lee Howard's written a draft that thoroughly analyzes the state of the art for dealing with the rDNS side of this, and I wrote a draft talking about how to make rDNS work with DHCP+PD.   I don't think anyone has talked about how to handle the forward zone, other than what you've seen here from Dave Täht and Simon Kelley, which I think is a very good start and ought to be written up.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 27 Feb 2013 06:55:25 -0800

> moves to http://myphone.building2.isp1.com).

Allow me to poke at that assumption: why should we expect that
the name (assuming there's only one, which is a bad assumption IMO),
changes instead of the address record(s)? If I travel around with my
toothbrush, shouldn't I expect it to remain named "mikestoothbrush.mtcc.com"?
Perhaps it may update a local dns to "mikestoothbrush.1027.holidayinn.com"
too, but if I really want to replenish its digital toothpaste, I'd almost
certainly surf to https://mikestoothbrush.mtcc.com to make certain I'm
not being tricked into resupplying ot.1027.holidayinn.com's toothbrush.

Mike

---

From: Ray Hunter <[email-masked]>
Date: Wed, 27 Feb 2013 21:21:18 +0100

Michael Thomas wrote:
>> [Ole] does a name really have any meaning without a service
>> associated with it?
>>
>> [Ray] URLs have meaning (rfc1738). It's going to be tough to know
>> when your
> [Mike] Allow me to poke at that assumption: why should we expect that

[Ray] Mike, your quoting in the above message was rather strange, so
I've tried to re clarify who wrote what.
[Ray] http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01 is
proposing that both the domain name and the IPv6 address change as nodes
move across subnets within homenet AFAICS.
[Ray] Changing domain names (and thus URL) when a device moves within
homenet is bad IMHO.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 27 Feb 2013 12:31:20 -0800

> [Ray] Changing domain names (and thus URL) when a device moves within

Let me understand: mdnsext-hybrid says that my domain name
changes as I move across subnets, and you think that's bad. If
so, I agree. At least to the extent that I don't really care very
much what a local (m)DNS wants to name my device so long as
the device updates its address records for my names as I move.

.local and its kin are a horrible hack that don't meet the requirements
of a mobile world.

Mike