Subject: [homenet] Host naming in Homenet

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 26 Aug 2015 13:29:48 +0200

Hi,

How does a host announce its name and address to the Homenet?  Just mDNS?
Or are we planning a protocol to store the mapping within DNS?

(I'm assuming no stateful DHCPv6, of course.)

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Wed, 26 Aug 2015 13:47:07 +0200

Hi Juliusz,

> (I'm assuming no stateful DHCPv6, of course.)

Since we mainly have to live with what is there today (and in the IETF), the
obvious solutions are MDNS and stateful DHCPv6. Neither is 100% ubiquitous and
implemented everywhere but combined they cover a variety of popular operating
systems.

Please correct me if I am wrong, but other alternatives would usually require
host changes which is out of scope here.

Cheers,

Steven

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 26 Aug 2015 14:37:35 +0200

> obvious solutions are MDNS

Ok.

> and stateful DHCPv6.

Over my dead body.

> Please correct me if I am wrong, but other alternatives would usually
> require host changes which is out of scope here.

While we cannot mandate host changes, we can recommend host changes that
improve functionality.  Is there a suitable IETF Standards Track protocol
that does that?

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Wed, 26 Aug 2015 15:01:21 +0200

RFC 1001? Is that standards track?
Nevertheless  HNCP is hopefully soon :p

To be more serious, I guess we might as well simply recommend MDNS since that is a standard and already deployed. DHCPv6 is probably more lightweight though (and even to me naming seems to be one of the few relevant usecases in a home scenario).

Am 26. August 2015 14:37:35 MESZ, schrieb Juliusz Chroboczek <[email-masked]>:
>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 26 Aug 2015 15:17:40 +0200

> I guess we might as well simply recommend MDNS

Fair enough, assuming there is mDNS proxying in the Homenet.  (Or should
we be speaking on ff05::fb and counting on Pierre to do some magic?)

> DHCPv6 [...] relevant usecases [...]

And here I thought you were a friend.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 26 Aug 2015 17:20:35 +0300

> On 26.8.2015, at 16.17, Juliusz Chroboczek <[email-masked]> wrote:

It is not really an option - it requires serious host changes.

Of course, if you’re completely crazy you could do some sort of linklocal -> sitelocal -> linklocal translation, but I would rather not go there especially as you would want to eliminate e.g. linklocal addresses from A/AAAA records => conflict resolution breaks => oops.

The options in increasing level of evil from my point of view are:

- DHCPv6 (ha ha! but at least it is simple in this case)
- hybrid proxy (rather complex but works)
- mdns-to-mdns proxying (complex, fragile, easy to break)

Cheers,

-Markus

---

From: Erik Kline <[email-masked]>
Date: Wed, 26 Aug 2015 14:58:18 -0700

Juliusz,

Can we just go with whichever recommendations come out of dnssd?

    https://datatracker.ietf.org/wg/dnssd/charter/
    https://datatracker.ietf.org/wg/dnssd/documents/

Or you want something to use in advance of their work?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Aug 2015 00:22:15 +0200

> - DHCPv6 (ha ha! but at least it is simple in this case)

I've received a few queries about this by private mail, some of which
indicate there is some confusion, so please let me clarify.

DHCPv6 has two modes of operation.  Stateless DHCPv6 is a fine protocol
for propagating static configuration to hosts, and must be used in
combination with SLAAC.  Stateful DHCPv6 is a misguided attempt at
carrying over the limitations of IPv4 into the IPv6 world.

Shncpd will speak stateless DHCPv6 as soon as I feel like having another
hacking spree.  Shncpd will never learn stateful DHCPv6, et vos larmes n'y
pourront rien changer.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Aug 2015 00:41:08 +0200

>     https://datatracker.ietf.org/wg/dnssd/documents/

Could you perhaps point me at a specific paragraph of a specific draft and
tell me "Do implement this, we're betting the company on this protocol"?

-- Juliusz

---

From: james woodyatt <[email-masked]>
Date: Wed, 26 Aug 2015 15:51:00 -0700

On Aug 26, 2015, at 15:22, Juliusz Chroboczek <[email-masked]> wrote:
> combination with SLAAC.  

I think you meant to say that both variants of DHCPv6 are abominations against the nature of home networks, and neither of them are appropriate except as a last resort protocol. If you didn’t mean to say that, then please review this email thread and reconsider (insert smiley here):

  <http://www.ietf.org/mail-archive/web/dhcwg/current/msg10818.html <http://www.ietf.org/mail-archive/web/dhcwg/current/msg10818.html>>

—james

---

From: Erik Kline <[email-masked]>
Date: Wed, 26 Aug 2015 16:16:07 -0700

> tell me "Do implement this, we're betting the company on this protocol"?

No, I cannot...not at this time.  But solving the homenet case is a
requirement, and documented in https://tools.ietf.org/html/rfc7558
(section 3, use case "C", I believe).

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Aug 2015 15:13:37 +0200

> how DNS can be bootstrapped and parent domains delegated to a Homenet
> Border Router.

I think we're speaking about different things.  You're speaking about
exporting the naming of the Homenet into the ISP (the single ISP, sigh)
and from there into the global DNS, while we're speaking about having
naming *within* the Homenet.

In short -- the ability within the Homenet to do

    scp backup-20150827.tar mylaptop.home:backup/

and having it work no matter which link the laptop happens to be connected
to.

I definitely want to be able to have host naming within the Homenet.  On
the other hand, I'm not sure if I want my Homenet to be exported to the
global DNS, and if I were to do so, I certainly wouldn't want a protocol
that forces me to do that through my ISP (the single ISP, sigh).

-- Juliusz

---

From: Ray Hunter <[email-masked]>
Date: Thu, 27 Aug 2015 14:38:34 +0200

Markus Stenberg wrote:
>> On 26.8.2015, at 16.17, Juliusz Chroboczek<[email-masked]>  wrote:
> Of course, if you’re completely crazy you could do some sort of linklocal ->  sitelocal ->  linklocal translation, but I would rather not go there especially as you would want to eliminate e.g. linklocal addresses from A/AAAA records =conflict resolution breaks =>  oops.
>
IMHO This is a very worthwhile discussion that we've glossed over for a 
long time.

I've seen several drafts over the course of the Homenet WG.

e.g. 
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-03 
discusses how DNS can be bootstrapped and parent domains delegated to a 
Homenet Border Router.

So that seems to be one portion of the overall jigsaw.

And 
https://tools.ietf.org/id/draft-jeong-homenet-device-name-autoconf-03.txt talks 
about each device auto-naming then the router performing discovery using 
NI [RFC4620] coupled with dynamic update [RFC2136] to seed LLN devices 
into the (global) DNS.

We also have https://datatracker.ietf.org/doc/rfc7558/?include_text=1 
that details requirements for extending mDNS e.g. linking mDNS 
sub-domains of the parent namespace to physical interfaces.

Meanwhile windows in the enterprise generally uses a delegated portion 
of the overall DNS namespace such as win.company.com and it's own update 
mechanisms internally.

So what are the expectations/requirements for naming in Homenet, and 
particularly host - router interaction?

How will name registration work?
Are we looking at a single flat name space?
How will name conflicts be resolved?
Are we looking at a name space that is link dependent?
Are we looking at a name space that includes delegations via subdomains 
for special devices or technologies?
Are we looking at supporting nodes that roam from link to link often 
within the Homenet?
What about devices that couple and uncouple from the Homenet? (mobile 
phones with wifi and 3G)
Is this going to turn into (another) DNS/mDNS war, or is there a model 
in which the two can peacefully co-exist?
e.g. query mDNS first? query both simultaneously?
e.g. seed mDNS into a DNS delegated domain?
e.g. translate mDNS queries into DNS and perhaps vice versa?

How will resolution work?
Will the end host be responsible for performing multiple resolution? Or 
the Homenet router?
Are we looking at electing a single authoritative DNS server for all of 
Homenet? With standby?
Or one DNS server per Homenet Border Router?
Or is every Homenet device a DNS/name server and we deploy a (large) 
search list.

Perhaps most importantly: What mechanisms do common host operating 
systems support today?

Regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Thu, 27 Aug 2015 16:29:14 +0200

> naming *within* the Homenet.
I'm speaking about naming for all potential flows: within homenet, from 
the Internet into homenet, out of homenet into the Internet, with 
devices moving across the border or remaining static. I've seen enough 
instances in corporate networks to know that all of these are relevant 
(e.g. when a sleeping device is taken home and then wakes up).
>      scp backup-20150827.tar mylaptop.home:backup/
And what happens if you have a regular back up process e.g. rsync that 
you want to work no matter where the (server) device is?
> and having it work no matter which link the laptop happens to be connected
I'd add whether it was connected to Homenet or the Internet.
> global DNS, and if I were to do so,
So maybe we need two (disjoint) name spaces. (Separate from the 
discussion about which protocol is used to resolve them)
>   I certainly wouldn't want a protocol
We've talked about the "single ISP issue" before offline. The draft 
mentioned defines the the relationship between one ISP and one homenet. 
There's nothing in the draft that forces use of this mechanism for all 
names used in the Homenet. There's nothing in that draft that says this 
is the only name space on the Homenet. I also don't think it's realistic 
to assume that a second ISP will host namespace with addresses from 
another ISP. e.g. device1.ips1.net is also resolvable via DNS servers of 
isp2.net.

On the other hand the draft does not (yet) specify how to handle the 
case of a Homenet connected to multiple ISPs. I don't think that's 
particularly problematic, and this is what we should be discussing now.

E.g. If there's a host called "device1", two Homenet border routers 
could independently register device1's IPv6 address derived from the 
prefix associated with their ISP(s) in the relevant ISP's name space. 
i.e. device1.isp1.net creates an AAAA record and PTRv6 for device1 
associated with the GUA prefix delegated from IPS1, and device1.isp2.net 
creates an AAAA record and PTRv6 record for device1 associated with the 
GUA prefix delegated from ISP2; and then having a DNS domain search list 
communicated to all end hosts via DHCPv6 or containing both isp1.net and 
isp2.net, so when an app resolves the name "device1" via DNS it receives 
both AAAA records (from different servers).

There's also nothing yet to say that "device1" could not also resolve to 
a site local IPv6 address via mDNS.

So in short: I'm thinking Homenet might need multiple name spaces, 
multiple name registration and resolution protocols, multiple servers; 
each tightly bound to the relevant (delegated) address scope and 
(delegated) top level domain.

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Aug 2015 17:10:45 +0200

I've changed the subject, since we're drifting away from the initial
concern, which was how to get a name within the Homenet for unmodified
hosts that got their address over SLAAC.  Exporting these names to the Big
Bad Internet is a laudable endeavour, but it's condemned to failure if we
cannot even get them names within the Homenet.

> I'd add whether it was connected to Homenet or the Internet.

I distinctly remember complaining that Daniel's protocol didn't allow for
announcing my laptop when it's not in the Homenet, and hearing that this
is out of scope.  Here's the thread:

  http://www.ietf.org/mail-archive/web/homenet/current/msg03724.html

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 27 Aug 2015 18:33:47 +0300

On 27.8.2015, at 15.38, Ray Hunter <[email-masked]> wrote:
> IMHO This is a very worthwhile discussion that we've glossed over for a long time.
> 
> e.g. https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-03 discusses how DNS can be bootstrapped and parent domains delegated to a Homenet Border Router.
> 
> And https://tools.ietf.org/id/draft-jeong-homenet-device-name-autoconf-03.txt talks about each device auto-naming then the router performing discovery using NI [RFC4620] coupled with dynamic update [RFC2136] to seed LLN devices into the (global) DNS.

Requires host changes. Out of scope.

> We also have https://datatracker.ietf.org/doc/rfc7558/?include_text=1 that details requirements for extending mDNS e.g. linking mDNS sub-domains of the parent namespace to physical interfaces.
> 
> Meanwhile windows in the enterprise generally uses a delegated portion of the overall DNS namespace such as win.company.com and it's own update mechanisms internally.
> 
> So what are the expectations/requirements for naming in Homenet, and particularly host - router interaction?
> 

Ideally, zeroconf. So registration is a strong word here.

> Are we looking at a single flat name space?

Probably not, at least if mdns is leveraged - it’s conflict resolution is strictly per-link, and as we have multiple links, we either implement clumsy conflict resolution scheme within mdns -> dns conversion step (not recommend) or provide zone per link.

> How will name conflicts be resolved?

See above.

> Are we looking at a name space that is link dependent?

Depends. I can see two different namespaces in general:

[1] manually configured, to be updated to local master, and then to ISP (Miguel’s stuff, i.o.w.); this could be flat
[2] zeroconf, based on mDNS, that is zone-per-link, and the associated zeroconf paths; clearly not flat

> Are we looking at a name space that includes delegations via subdomains for special devices or technologies?

Not sure what you mean by this.

> Are we looking at supporting nodes that roam from link to link often within the Homenet?

Possibly. The manual (dns-update) based mechanism could ensure that laptop.fingon.iki.fi points to my laptop _wherever it is_, inside or outside home. It is also known as laptop.lan.home by default, by simple mDNS -> DNS conversion and local hnetd action. 

(I haven’t done the [1] part, so that part of the example is fictional in my laptop case.)

> What about devices that couple and uncouple from the Homenet? (mobile phones with wifi and 3G)

See above.

> Is this going to turn into (another) DNS/mDNS war, or is there a model in which the two can peacefully co-exist?

They coexist in my mind, see above.

> e.g. query mDNS first? query both simultaneously?

mDNS is not really useful in and of itself in homenet, as it is per-link. mDNS proxied to DNS (hello, hybrid proxy), on the other hand, is the bee’s knees :-)

> e.g. seed mDNS into a DNS delegated domain?

Seed mDNS hybrid proxy NS entries to DNS; I am not convinced of zeroconf DNS zone population via mDNS for various reasons.

> e.g. translate mDNS queries into DNS and perhaps vice versa?

Yes. 

> How will resolution work?

draft-ietf-dnssd-hybrid, draft-stenberg-hybrid-proxy-zeroconf, HNCP.

> Will the end host be responsible for performing multiple resolution? Or the Homenet router?

Host.

> Are we looking at electing a single authoritative DNS server for all of Homenet? With standby?

No, see HNCP. We could do that for the manually configured part, see above.

> Or one DNS server per Homenet Border Router?

No.

> Or is every Homenet device a DNS/name server and we deploy a (large) search list.

Yes.

> Perhaps most importantly: What mechanisms do common host operating systems support today?

The operating systems I care about support mDNS, DNS and DNS-SD. 

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 27 Aug 2015 18:35:01 +0300

>  http://www.ietf.org/mail-archive/web/homenet/current/msg03724.html

For that, all you need is (appropriately authenticated) DNS-Update to point at your home’s DNS server(s) and Bob’s your uncle.

-Markus

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Aug 2015 09:04:28 -0700

> naming *within* the Homenet.

No, it doesn't mean that. You don't need to be an ISP to run a DNS
server. Even an authoritative one. There are a world of choices here.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Aug 2015 09:11:40 -0700

> Requires host changes. Out of scope.

This is *complete* bs. *None* of this -- MDNS included -- is well 
supported (please spare me the bleating about
Apple, blah blah blah, it sucks too). Any real solution will require 
host changes. Period.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Aug 2015 09:49:58 -0700

On 08/27/2015 09:18 AM, Markus Stenberg wrote:
>
> Well, feel free to come up with your magic pixie dust solution, as you seem to keen to pipe up every time on the topic, I have been waiting for it years (literally).
>
>

This has nothing to do with me, your ongoing ad hominems aside.

*None* of them deal with host naming well. They will require far, far 
better UI and structural support at the very least.
As should be expected for any new piece of major functionality. This is 
distinctly different that, say, routing which traditionally
does not put requirements on the host. Naming has always had implications.

So saying host changes are "out of scope" is dismissive and counter factual.

Mike

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Aug 2015 18:54:13 +0200

Thanks for the explanation, Markus.

What does that mean for shncpd?  I do nothing, and wait for the pixie dust
to settle?

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Thu, 27 Aug 2015 19:23:38 +0200

> What does that mean for shncpd?  I do nothing, and wait for the pixie dust

If you feel motivated you could implement all the SHOULDs of HNCP naming and sd:

1. find (or implement) a DNS cache and populate it using the HNCP DNS and naming TLVs,
	and the recursive DNSs from the ISPs, then announce said cache to your clients
	using RAs and DHCPv4/v6
2. find or implement an MDNS hybrid proxy and hook it up to your HNCP implementation
3. implement stateful DHCPv6 and populate your DNS cache with the acquired hostnames

Consider 2 and 3 bonuses :P

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Aug 2015 17:58:38 -0700

On 08/27/2015 01:43 PM, Markus Stenberg wrote:

>
> UI isn’t what we define here. ’structural support’ = ?. How does that map to an IETF standard? And is it something we should standardize here, and if not, where should it be?
>
>

You dismissed any solution that requires any host changes as "out of 
scope". I call bs: host naming is traditionally within
the purview of hosts, and it shouldn't be surprising that host software 
will need to change to support homenet naming.
That's to be expected. It's a Good Thing.

The current state of naming on the usual suspect OS's is infantile. That 
I can apt-get avahi, or type Bonjour into a search
window and wonder what I'm supposed to do with it proves exactly 
nothing. Things are going to need to be a lot more
integrated into host software before any of this is useful or ordinary. 
So your proposition that we can't change anything on
hosts is preposterous on its face.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Aug 2015 23:54:17 -0700

On 08/27/2015 11:46 PM, Markus Stenberg wrote:
> You still have just said existing solutions suck. Still no new 
> solution. Waiting with bated breath for the ‘homenet’ solution, -Markus 

And still Marcus cannot separate out this from anything except about me. 
The classic -- and unprofessional -- use of ad hominem.

Mike

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 28 Aug 2015 10:49:31 +0300

On 28.8.2015, at 10.02, Henning Rogge <[email-masked]> wrote:
> So what IS the proposed solution for a decentralized HNCP configured
> homenet to share local "configured" DNS names with the rest of the
> homenet?

For sharing in general, there are two methods (as far as HNCP goes);

- publish a DNS Delegated Zone TLV that points to a (local or remote) DNS server that responds for that zone. 

- publish Node Name TLVs for individual nodes (won’t scale forever, but possibly enough).

If the node that has configured state _is not_ running HNCP, then options boil down to:

- DHCPv6, mDNS assuming first-hop router cares and does DHCPv6/mDNS (shncpd, cough)
- DNS-update aimed at the right place (+ injection of DNS Delegated Zone TLV per zone somewhere in the HNCP cloud)

Cheers,

-Markus

---

From: Henning Rogge <[email-masked]>
Date: Fri, 28 Aug 2015 10:09:03 +0200

> - publish a DNS Delegated Zone TLV that points to a (local or remote) DNS server that responds for that zone.

central server sounds bad for "distributed network".

> - publish Node Name TLVs for individual nodes (won’t scale forever, but possibly enough).

That could work... still, if every DNCP node publishes a DNS name for
the node (and maybe another one for a few locally attached non-DNCP
hosts) this would increase the size of the DNCP database a little bit.
Wasn't there a size limit for the database (or was it per node?)?

> - DNS-update aimed at the right place (+ injection of DNS Delegated Zone TLV per zone somewhere in the HNCP cloud)

Yes, this would be more complex.

But pushing the local router as a nameservice would be enough to
inject the knowledge of the HNCP cloud to the attached hosts.

Henning Rogge

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 28 Aug 2015 11:41:48 +0300

On 28.8.2015, at 11.09, Henning Rogge <[email-masked]> wrote:
> central server sounds bad for “distributed network".

There isn’t uniqueness constraint on those TLVs, so you could have multiple. That would work already OOTB.

You could relatively easily define primary server auto-election mechanism and then e.g. do AXFRs between them.

> Wasn’t there a size limit for the database (or was it per node?)?

Per node, so not probably that big issue. Especially as you can create infinite number of fake nodes anyway if you feel like it (c.f. the older DNCP drafts’ fragmentation scheme that was removed due to lack of implementation / correctness validation).

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 28 Aug 2015 12:54:04 +0200

>   DNS server that responds for that zone.

Markus,

Let's please not put per-host state into HNCP, it's not dealing very well
with churn (remember Jin Kaiwen's results?).  Let's use HNCP for
bootstrapping the routers, let's leave routing to the routing protocol,
and naming to the naming protocols.  You know, nails and hammers.

Let's also try to avoid having any more elections (per-link or global).
If a protocol doesn't cannot deal with multiple servers, it should provide
its own election mechanism.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Fri, 28 Aug 2015 12:56:24 +0200

> its own election mechanism.

If you don't like the idea using the NODE NAME TLV to announce DNS
information of the local hosts, how would you do it without a central
server configured by a network admin?

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 28 Aug 2015 12:57:06 +0200

> This is *complete* bs.

While I would have expressed it in somewhat milder terms, I tend to agree
with Michael.  If HNCP gets massively deployed together with a naming
protocol that is easy to implement, the host implementations will come in
due time.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 28 Aug 2015 13:29:21 +0200

> server configured by a network admin?

 * mDNS plus mDNS proxying; or

 * mDNS over ff05::fb; or

 * announce a bunch of dynamic DNS servers (inside or outside the Homenet)
   over HNCP, use some ad-hoc registration protocol.  This relies on hosts
   consulting all of the advertised servers when search for an RR.

Henning, the flooding part of HNCP is just a multicasting protocol with
some rather unusual characteristics -- marvelously efficient when there is
no churn, bad in the presence of churn.  Let's use its strengths and avoid
its weaknesses, not the opposite.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Fri, 28 Aug 2015 13:42:20 +0200

>  * mDNS plus mDNS proxying; or

you mean a bi-directional proxy between mdns on the host-interface and
some distributed DNS services in the home network?

>  * mDNS over ff05::fb; or

Would not work without a multicast routing protocol.

>    consulting all of the advertised servers when search for an RR.

which still doesn't solve the problem how the hostnames configured on
a homenet router gets into one (or multiple) of these DNS servers.

> its weaknesses, not the opposite.

Just to be sure, do you see that the hostname of a router or a host
would change that often?

Henning Rogge

---

From: Steven Barth <[email-masked]>
Date: Fri, 28 Aug 2015 13:42:44 +0200

Juliusz,

> protocol that is easy to implement, the host implementations will come in

The homenet architecture and / or charter say that for this WG host changes are
to be minimized and in some areas completely out of scope.

Furthermore, as Markus noted, the IETF has MDNS and stateful DHCPv6 (or rather
RFC 4704) in standards track and these protocols are widely supported by all kinds
of clients already.

Bottom line: I'm not sure what problem you and Michael are claiming needs to be
solved here or could be addressed by HNCP, us or the working group in some way.

---

From: Steven Barth <[email-masked]>
Date: Fri, 28 Aug 2015 14:16:58 +0200

> server configured by a network admin?

What we currently have defined and implemented is this:

   Each HNCP router SHOULD provide and announce an auto-generated or
   user-configured name for each internal Common Link (Section 6.1) for
   which it is the designated DHCPv4, stateful DHCPv6 server, MDNS
   proxy, or for which it provides forward or reverse DNS services on
   behalf of connected devices.

This means that we don't use a central server, but each HNCP router
(or well one per link) SHOULD offer name resolution for that link and
announce a name (e.g. lan1.router1.home) using an HNCP TLV. Under that
zone it places hostnames acquired via DHCPv4, DHCPv6 (or other methods).
If it runs an MDNS hybrid proxy (dns->mdns querier) it also announces the
zone as DNS-SD browsable using a flag in the TLV. The hybrid proxy itself
issues an MDNS-request for each DNS-request it receives for the specific
link and collects and aggregates all MDNS-replies and sends them back to
the originator of the DNS-request.

   Each HNCP router SHOULD provide a recursive name resolution server
   which honors the announcements made in Delegated Zone TLVs
   (Section 10.5), Domain Name TLVs (Section 10.6) and Node Name TLVs
   (Section 10.7)

Now this finally ensures that if you - as a client - are connected to an
HNCP router you can resolve all client hostnames (laptop.lan1.router1.home),
HNCP hostnames (router1.home), and enumerate all DNS-SD domains announced
by any HNCP routers. DNS-SD clients already send requests to all DNS-SD
browsable domains (i.e. all hybrid proxies in your homenet) on their own.
If you client speaks DNS-SD, like most Linux, Android & Apple devices do
(and Windows with additional software), you can thereby enumerate
MDNS-capable devices and services on links which announce a hybrid proxy.
So this is all zero-conf basically but your implementation should let you
fine-tune it, e.g. change link and router names to something more elegant
so your hostnames are like printer.lan.office.home, or tv.wifi.bedroom.home)
and should let you add manual hostnames (using Node Name TLVs)
like nas.home.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 28 Aug 2015 16:03:24 +0200

> I'm not sure what problem you and Michael are claiming needs to be

All I'm saying, Steven, is that "no host changes" is no excuse -- if we
deply easy to implement protocols that provide desirable functionality,
the host changes will follow.

Perhaps mDNS proxying solves all the naming issues with no host changes
required -- if so, that's excellent.  Should we find that it doesn't,
however, we should not avoid doing the right thing just because somebody
confused "no host changes must be required" with "no host changes will be
done".

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 28 Aug 2015 14:32:21 +0000

> All I'm saying, Steven, is that "no host changes" is no excuse -- if we deply
> easy to implement protocols that provide desirable functionality, the host
> changes will follow.
> 
> required -- if so, that's excellent.  Should we find that it doesn't, however,
> we should not avoid doing the right thing just because somebody confused
> "no host changes must be required" with "no host changes will be done".

I agree. To me, "no host changes must be required" says that everything hosts can do today, they will still be able to do inside a homenet, without changing. But there is nothing that should prevent homenet from putting in capabilities that will provide a better experience for hosts that do change. Just so long as what's there doesn't break. It's a backward compatibility requirement.

For capabilities aimed at "better without breaking", I personally would prefer ones that don't require user involvement to make them work and that don't create new avenues for threats to privacy and security. 
Barbara

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Aug 2015 08:30:17 -0700

> RFC 4704) in standards track and these protocols are widely supported by all kinds

So is plain old DNS. That doesn't mean that the effects on host software 
will or should be zero.
We should not artificially constrain ourselves with sledge hammer 
requirements like "no host changes"
when there will manifestly be host changes to incorporate the brand new 
world of in-home naming.

Mike

---

From: Steven Barth <[email-masked]>
Date: Fri, 28 Aug 2015 17:56:40 +0200

> So is plain old DNS.
Then tell me how clients register their names using "plain old DNS" and how that is already widely deployed in client OSs.

> when there will manifestly be host changes to incorporate the brand new world of in-home naming.
There is nothing brand new here, it worked on single links for years. In my non-HNCP network I can type: http://printer.lan or even just http://printer to reach my HP printer, because it told my router that its hostname is "printer" when it got the DHCP lease and my router populates the name into the DNS cache that all clients are using. Similarly I can use http://printer.local and my PC finds the printer purely using MDNS without any router intervention or I can even enumerate it on the local link using DNS-SD without knowing its hostname and without router intervention.

If I were to hookup my printer to an HNCP network that implements all the SHOULDs from the naming and service discovery section, I can also enumerate it using DNS-SD when it is on a different link than I am (without knowing its name or location) and I could also call it directly by its name using "plain old DNS" if I know where it is, e.g. printer.lan.office.home (if the router is named "office" and the link  "lan").

That is purely using existing technologies without any host changes and on top of that completely zero-conf for the DNS-SD part. If I want meaningful plain old DNS names of course I have to tell the router that it is called "office" and its ethernet ports are called "lan" and that the printer is just "printer", but that issue you will probably always have with pure DNS.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Aug 2015 09:13:25 -0700

> There is nothing brand new here, it worked on single links for years. In my non-HNCP network I can type: http://printer.lan or even just http://printer to reach my HP printer, because it told my ro…

You're making my point rather elegantly: you know this. The unwashed 
masses? Not so much.

I just noticed that my latest version of Android has a new feature to 
wirelessly cast my screen onto a nearby screen.
Currently even with brand new TV's at both home and work, it finds 
nothing. I actually have no idea whether this is a
config thing, lack of appropriate software, or maybe a combination of 
both. *I* can (and may) research why that is.
The rest of humanity? "It doesn't work".

Part of this is immaturity of protocols, part of it is lack of support 
altogether, and in all cases, it's a general inadequacy
of how well this is integrated together in the OS and UI's. Which is to 
say, that hosts are most definitely going to have
to update software to get the rest of humanity using these new devices.

Which is why I object to saying that there's a sledge hammer requirement 
that we cannot place a requirement on
new host software for naming. And that's true regardless of what 
protocol technologies we end up specifying --
even the ones I don't favor. This isn't about me, it's about needlessly 
constraining the problem space.

Mike

PS: for anybody who brings up "BUT APPLE ALREADY!!!" you make my point. 
The rest don't and would need to change,
      and hopefully not to their proprietary world.

---

From: Steven Barth <[email-masked]>
Date: Fri, 28 Aug 2015 18:51:21 +0200

> I agree. To me, "no host changes must be required" says that everything hosts can do today, they will still be able to do inside a homenet, without changing. But there is nothing that should preven…
That's exactly the point. If my PC can discover my printer, media device etc. today if it is on the same link and we are introducing home networks with multiple links, I want this discovery to seamlessly work across links without needing to update my PC's operating system.

Sure, nobody does hinder anyone from doing new cool and shiny stuff and inventing protocols which require host changes, but it doesn't absolve us from fixing the existing stuff. In the end it just means, we now have increased complexity because we have to both support the new and shiny and the old and boring and expected-to-still-work stuff.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 29 Aug 2015 18:54:35 +0200

> That's exactly the point. If my PC can discover my printer, media device
> etc. today if it is on the same link and we are introducing home
> networks with multiple links, I want this discovery to seamlessly work
> across links without needing to update my PC's operating system.

You're absolutely right, as usual.  Except for the bit about updating your OS.

Now could we achieve this in a multi-link Homenet without any elections?
Without running more stuff on the (buggy) routers?  Please?  Pretty please?

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Mon, 31 Aug 2015 11:42:08 +0200

>Now could we achieve this in a multi-link Homenet without any

The primary purpose of the election is to avoid having multiple different zones and names for the same link. It's not so much an issue of running multiple mdns proxies but mainly to avoid duplication.

That's why the first tie breaker in the election favors routers that also offer other services as to centralize mdns and dhcp-fueled naming on a link.

Cheers,

Steven

---

From: Henning Rogge <[email-masked]>
Date: Mon, 31 Aug 2015 12:16:40 +0200

> That's why the first tie breaker in the election favors routers that also offer other services as to centralize mdns and dhcp-fueled naming on a link.

Does homenet even need a "central" DNS server?

Typical configuration of a cheap router would be to run dnsmasq for
local DHCP and as a DNS cache. If each of these DNS caches could
forward DNS queries for *.<homenet-router-id>.homenet to the relevant
homenet router, it would not be necessary to pool all the information
in an elected DNS "master".

HNCP already knows the IP addresses and node-id's of all other homenet
routers, so the information which DNS server is to be asked is already
known. Each of the local DNS caches could use both the
(DHCP-delivered) hostnames and the MDNS ".local" zone to populate its
local DNS information.

Henning Rogge

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 31 Aug 2015 13:34:00 +0300

On 31.8.2015, at 13.16, Henning Rogge <[email-masked]> wrote:
> Does homenet even need a “central" DNS server?

No. It is per link, not per home.

> in an elected DNS “master".

For naming this works as is fine in our current implementation too; all you get is some duplicates (foo.link1.rid1.home and foo.link2.rid2.home may both exist, even if link1.rid1 is same link as link2.rid2).

It isn’t even a problem; both forward and reverse stuff works out of the box this way (given hnetd, cough).

For service discovery, shitload of duplicates (both on query path, and shown to the user) are a problem.

Yes.

-Markus

---

From: Henning Rogge <[email-masked]>
Date: Mon, 31 Aug 2015 12:37:31 +0200

> For naming this works as is fine in our current implementation too; all you get is some duplicates (foo.link1.rid1.home and foo.link2.rid2.home may both exist, even if link1.rid1 is same link as li…

You mean that a Homenet user use a switch to connect two Homenet
routers AND a Host ?

Or maybe a Host with two interfaces connected to two Homenet routers?

Henning

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 31 Aug 2015 13:44:24 +0300

> Or maybe a Host with two interfaces connected to two Homenet routers?

Let’s assume a shared link with 2 homenet routers (rid1, rid2) and 1 host (foo).

Given no election, use of e.g. mDNS to determine hosts/services would result in the host showing under both rid1.home and rid2.home. That isn’t a problem in naming case (you have IP => name, and name => IP resolving), but for service discovery it kind of sucks.

-Markus

---

From: Tore Anderson <[email-masked]>
Date: Mon, 31 Aug 2015 13:12:29 +0200

Hi,

Jumping in here with the perpective of a «dumb user» who spent the
weekend playing with the Homenet implementation in OpenWrt 15.05...

(Note that I don't know whether my comments pertain to the Homenet
standards themselves or are specific to the OpenWrt implementation.)

* Markus Stenberg <[email-masked]>

> No. It is per link, not per home.

After converting my main router to Homenet mode (leaving the other one
as a dumb layer-2 bridge) I was initially happy to see that URIs such as
http://scanner worked and that I could do "ssh myserver" and so on.
This was of course because the DNS search path had been set up as
"lan.mainrouter.home", and "server.lan.mainrouter.home" resolved fine.
If I connected via Wifi, I could no longer use unqualified names to
reach the server living on the wired LAN segment, but the fully
qualified one would still work.

However as soon as I converted my downstairs router to Homenet mode as
well and connected my laptop to the downstairs wireless network, I
could no longer use names to access the server (short or fully
qualified). It appears the DNS server in each router only knows about
its immediate neighbours. That was a rather big bummer, to be honest.

This and broken WiFi roaming were the only two things that made me want
to go back to my old non-Homenet setup (or more likely somewhere in
between, with only 1 Homenet-enabled router). Otherwise I was very
pleased with how nice everything worked.

Tore

---

From: Henning Rogge <[email-masked]>
Date: Mon, 31 Aug 2015 13:17:10 +0200

> Given no election, use of e.g. mDNS to determine hosts/services would result in the host showing under both rid1.home and rid2.home. That isn’t a problem in naming case (you have IP => name, and na…

Okay, I see the problem with the hierarchical namespace when two when
we have this "host switched to multiple HNCP routers" situation.

It would be great if we would get one common (m)DNS name for the host,
even if it got multiple IP addresses.

Would it be a solution to use a DNS "second level" name for each
ethernet segment with hosts attached but NOT include the routers into
the DNS name? If you connect two homenet routers to the same ethernet
segment, they should know because they see each others HNCP packets
(unless its a LEAF interface... which contradicts the switched
situation a little bit). Both sides could agree on a common "Link
segment" name and announce the host with "host1.link-segment.home".

Henning Rogge

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 31 Aug 2015 14:22:51 +0300

> standards themselves or are specific to the OpenWrt implementation.)

Implementation.

> its immediate neighbours. That was a rather big bummer, to be honest.

That is not the case.

Instead, it sounds like potentially issue with IPv4 + dnsmasq (e.g. option that prevents RFC1918 replies from being forwarded), I hope you are not using legacy IP :)
(We intentionally touch as few defaults as possible, and that protection is on by default IIRC)

Another caveat is that DHCP-derived names within dnsmasq are not currently distributed outside (local) dnsmasq but instead just provided locally, possibly with some weird domain that other routers do not know about. (dnsmasq extensibility leaves something to be desired.)

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 31 Aug 2015 14:33:59 +0300

> even if it got multiple IP addresses.

I agree, and I would add that it stayed constant when the host moves..

(this brings us firmly to dns-update / node name TLV territory though I think)

> segment” name and announce the host with "host1.link-segment.home".

Sure, you can define link segment name election mechanism and use per-link names (they are even mentioned as an option in draft-ietf-homenet-stenberg-hybrid-proxy-zeroconf; see also why doing that zeroconf might be bad idea), but I am not sure it is any cleaner than just electing single router to be responsible for it and using per-link+router names. That draft is intentionally NOT referred to in HNCP itself due to hybrid proxy dependency.

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 31 Aug 2015 14:36:44 +0300

> Sure, you can define link segment name election mechanism and use per-link names (they are even mentioned as an option in draft-ietf-homenet-stenberg-hybrid-proxy-zeroconf; see also why doing that…

Oho, still had my name there. This is the link, for the record. Seems like it is about to expire too, should probably nop-republish it (for Nth time; I think substantial changes to the draft were 2-3 years ago).

https://www.ietf.org/id/draft-ietf-homenet-hybrid-proxy-zeroconf-00.txt

-Markus

---

From: Tore Anderson <[email-masked]>
Date: Mon, 31 Aug 2015 13:39:06 +0200

> Instead, it sounds like potentially issue with IPv4 + dnsmasq (e.g.
> option that prevents RFC1918 replies from being forwarded), I hope
> you are not using legacy IP :)

I left everything at defaults, so my links were indeed numbered using
IPv4 (RFC1918, 10/8), as well as IPv6 ULA from a prefix automatically
set up by OpenWrt when the router was installed (pre-Homenet
conversion) and of course IPv6 GUA (from ISP/DHCPv6-PD). I'll try to
remove the option you mention and see if that's better, thanks for the
tip!

BTW - this reminded me that I also noticed that after rebooting a
router, another ULA prefix (*not* the one configured in OpenWrt on
either router) also showed up and links were numbered using it, but it
vanished again after a while. No idea where it came from. To be
investigated! :-)

> Another caveat is that DHCP-derived names within dnsmasq are not
> currently distributed outside (local) dnsmasq but instead just
> provided locally, possibly with some weird domain that other routers
> do not know about. (dnsmasq extensibility leaves something to be
> desired.)

Understood.

Thanks!

Tore

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Mon, 31 Aug 2015 13:42:57 +0200

> (section 3, use case "C", I believe).
I am familiar with Appletalk Phase 2, so the concepts in DNS-SD come as 
no surprise.

However, AFAICS after reading the DNS_SD documents including 
https://tools.ietf.org/html/rfc7558, I think I detect one hole for Homenet.

Although there's a requirement for topology independent zones and 
autoconfig, it's a bit opaque to me:

1) if overlapping zones/namespaces are allowed (multiple ISPs with 
potentially multiple parent delegated name spaces).
That was not allowed in Appletalk Phase 2, and the zones were configured 
manually by an administrator.

2) How the parent namespace(s) are delegated (using zeroconf).

We already have https://tools.ietf.org/html/rfc3633 for explicitly 
delegating address prefixes.

But there doesn't seem yet to be any appetite for a standard mechanism 
for delegating namespaces (e.g. via DHCPv6).

Juliusz (and others) have objected to 
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options 
because it appears to be tied to the ISP. Yet for reverse resolution, 
the ISP is an essential party, because they have been delegated the DNS 
zone for their entire allocated address space. And Homenet uses 
delegated prefixes from within this overall allocation.

Also DND SD (RFC 6763) states "Address-based Domain Enumeration queries 
are performed using names under the IPv6 reverse-mapping tree" which is 
under the direct control of the individual upstream ISPs.

So, what are people expecting to happen here?
ISP's to cooperate with independent name services when sending a DHCPv6 
delegation of a namespace e.g. a party like DYNDNS? So the Homenet 
learns everything via one neatly packaged DHCPv6 exchange with each 
upstream provider?
Multiple upstream DNS services that need to be updated?
Overlapping namespaces?
Multiple namespace delegation via multiple mechanisms? e.g. Homenet 
learns the reverse tree from the upstream ISP (via DHCPv6), and forward 
delegation (glue records) are entered via the domain registrar via http 
or something else?

In IPv4 I have my own private company domain bootstrapped by my own 
(manually added AAAA glue records) from my own Domain Registrar (100% 
independent of my ISP). And the ISP adds dummy static reverse records 
and A records, so triple resolution works.

Is this what we want for IPv6, or do we have to deal with seeding 
information into multiple upstream DNS's?

Permitting inbound services and restoring the end to end architecture of 
the Internet is a big part of Homenet IMVHO

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 31 Aug 2015 15:05:39 +0300

On 31.8.2015, at 14.42, Ray Hunter (v6ops) <[email-masked]> wrote:
> Also DND SD (RFC 6763) states "Address-based Domain Enumeration queries are performed using names under the IPv6 reverse-mapping tree" which is under the direct control of the individual upstream ISPs.
> 
> ISP's to cooperate with independent name services when sending a DHCPv6 delegation of a namespace e.g. a party like DYNDNS? So the Homenet learns everything via one neatly packaged DHCPv6 exchange with each upstream provider?
> Multiple namespace delegation via multiple mechanisms? e.g. Homenet learns the reverse tree from the upstream ISP (via DHCPv6), and forward delegation (glue records) are entered via the domain registrar via http or something else?

I am not very fond of idea of having to push anything to ISP for my _home_ network to work _within home_.

Looking at IPv4, my 10.* address resolution is not provided by the ISP; sure, with IPv6 that is possible, but I don’t think it should be mandatory.

That implies DNS server in the home. Whether that is synchornized with ISP side (e.g. hidden master, ISP server actually just having NS records pointing towards home) is a matter for discussion and how that synchronization is established.

> Is this what we want for IPv6, or do we have to deal with seeding information into multiple upstream DNS’s?

How does this work when ISP connection is down?

> Permitting inbound services and restoring the end to end architecture of the Internet is a big part of Homenet IMVHO

Would be nice to have of course.

-Markus

---

From: Steven Barth <[email-masked]>
Date: Mon, 31 Aug 2015 14:09:51 +0200

In general  I think making unqualified names  work is problematic. We'd need to add one search path entry per link which doesn't scale. Plus duplicates are not really handled deterministically.

Cheers,

Steven

---

From: Michael Thomas <[email-masked]>
Date: Mon, 31 Aug 2015 09:39:17 -0700

On 08/31/2015 05:05 AM, Markus Stenberg wrote:
>> upstream ISP (via DHCPv6), and forward delegation (glue records) are entered via the domain registrar via http or something else?

Can we pretty please banish the use of "ISP" when we're talking about an 
upstream
DNS provider? If we provide support for populating an upstream DNS, we 
really ought
to be able to do that regardless of the server's relationship (or not) 
with my bit provider.
I really don't want to be linked at the hip with my ISP for just about 
anything except bits...

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 31 Aug 2015 09:51:55 -0700

On 08/31/2015 04:42 AM, Ray Hunter (v6ops) wrote:
> the ISP is an essential party, because they have been delegated the 
> DNS zone for their entire allocated address space. And Homenet uses 

What that tells me, on the other hand, is that these are two separate 
problems that
just need to get solved. And, in fact, the forward and reverse maps may 
not same auth/authz
requirements for their respective CRUD operations.

Mike

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Sep 2015 10:06:25 +1000

Why is topology being forced into the naming?  DNS is independent
of topology.  We have *a* home.  I really don't care what link my
printer is connected too.  It is not something I want to see in its
name unless I put it there.

Have ".home" be the default suffix with a low preference.  Allow
any router to set the home's suffix with a higher preference and
have that override all the default ".home" suffixes.

All the routers should be serving this zone and transfering it from
each other.  EDNS EXPIRE is used to prevent zones failing to expire.
There just needs to be *a* server that processes the updates from
which the others can transfer the zone.  That server needs to be
elected and if it goes away another server needs to be elected.

Before the elected server starts accepting updates it polls all the
other servers and tranfers the zone with the largest serial it can
see.  This minimises the amount of lost updates.  The server will
do a SOA update (increase the serial) and adds its name to the mname
field when doing so.  Once this is complete creating stable reference
zone for future IXFRs.

IXFR responses for transfers from before and including the highest
serial discovered after the election are sent AXFR style.  This
re-syncronises all copies of the zone.

If a server comes up that thinks it is the master and sees that
that is is not listed in the mname field held by any of the slaves
it triggers a election.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]