Subject: Re: [homenet] Host naming in Homenet

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Tue, 01 Sep 2015 09:06:42 +0200

Michael Thomas wrote:
>
>
> On 08/31/2015 04:42 AM, Ray Hunter (v6ops) wrote:
>>
>> 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.
>
> 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
I think you may be right, assuming we want to do DNS for Homenet properly.

i.e. we should be talking about updating multiple ISPs for reserve 
resolution (per delegated IPv6 prefix), and potentially multiple ISPs or 
independent DNS providers for forward resolution (per delegated name space).

And when we're talking about "updating" we also have at least two 
alternatives:
1) maintaining the RRs in the ISPs' or 3rd party DNS providers' DNS 
servers, or
2) ensuring proper delegation and glue records exist, pointing at 
Homenet's own DNS servers (whether they are located on or off Homenet).

Automating zone delegation and glue record insertion with zeroconf seems 
quite a hole in current standards.........
and that is also not covered in DNS-SD AFAICS.

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 1 Sep 2015 10:23:29 +0000

> Automating zone delegation and glue record insertion with zeroconf seems quite a hole in current standards.........

<individual hat firmly in place>
As a potential end user of homenet (i.e., within my personal home network), I very much do *not* want any of my IoT devices, printers, or scanners to be publicly discoverable via DNS. If and when I want anything discoverable via public DNS, I want to be very explicit about what that is. So any "automating zone delegation" solution needs to have as a requirement that it must not automatically cause anything to be externally discoverable that the end user does not explicitly identify.

The tremendous lack of security being built into printers, scanners, IoT devices, and other devices on the home network suggest that automatically exposing them to external discovery would likely have Very Bad Consequences for the majority of end users (who will be completely unaware that such automatic exposure was occurring).
Barbara

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Tue, 01 Sep 2015 12:57:03 +0200

> STARK, BARBARA H <mailto:[email-masked]>
> 1 Sep 2015 12:23
> As a potential end user of homenet (i.e., within my personal home 
> network), I very much do *not* want any of my IoT devices, printers, 
> or scanners to be publicly discoverable via DNS. If and when I want 
> anything discoverable via public DNS, I want to be very explicit about 
> what that is. So any "automating zone delegation" solution needs to 
> have as a requirement that it must not automatically cause anything to 
> be externally discoverable that the end user does not explicitly identify.
>
> The tremendous lack of security being built into printers, scanners, 
> IoT devices, and other devices on the home network suggest that 
> automatically exposing them to external discovery would likely have 
> Very Bad Consequences for the majority of end users (who will be 
> completely unaware that such automatic exposure was occurring).
> Barbara

I hear you.

But I think the discussion on automatic delegation of a DNS name space 
is separate from which content Homenet publishes in which zone.

I'm thinking of a delegation mechanism similar to how RFC3633 delegates 
address prefixes, that would allow a DNS service provider to delegate 
one or more subsets of their name space to a Homenet to use as it's 
parent name space.

The transport for this delegation mechanism might be DHCPv6, for the 
case where a DNS operator (the ISP) wants to delegate a reverse zone for 
PTR records for reverse resolution, but it might also be an API over 
HTTP for where there's a DNS provider who has no business relationship 
with the upstream ISP(s). Or both....

The name space delegation would support the use case where the DNS 
service provider supplies information for the Homenet on how to update 
the RR hosted on the DNS provider's DNS servers, as well as the use case 
where the Homenet itself provides the DNS servers, and the DNS service 
provider has to enter NS records and glue records in their own DNS servers.

Once those name space delegations are in place, it would be a separate 
discussion on how content is generated and updated e.g. printers using 
ULA addresses should not be pushed to a zone visible on the public Internet.

If we don't have a set of unique parents for the Homenet name space 
(either delegated or self-generated), we'll also run into security 
issues, as .home or .local themselves are not unique for devices that 
roam between multiple (disjoint) Homenets. In exactly the same way that 
ULA addresses also have to be (reasonably) unique across the set of 
Homenets.

So myprintservice.<obscure_nonce>.home. would be fine for me for the ULA 
space. The <obscure_nonce> portion of the name space would obviously not 
generally be displayed to end users.

And for GUA space it could be myservice.<obfuscated_cust_id>.myisp.com 
or myservice.<obfuscated_cust_id>.mydnsservice.org

---

From: Ray Bellis <[email-masked]>
Date: Tue, 1 Sep 2015 14:49:05 +0100

On 01/09/2015 01:06, Mark Andrews wrote:
> 
> 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.

No-hat:

I'm very much with MarkA on this one.

I want my devices to have a persistent name identifier, regardless of
which part of the topology they happen to be plugged into at the time.

I wouldn't mind if the "canonical" identifier happens to be topology
dependent, so long as there's some mechanism (e.g. CNAME) to
automatically map the persistent identifier to the topology-dependent one.

Ray

---

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Sep 2015 15:54:39 +0200

> automatically map the persistent identifier to the topology-dependent one.

Putting all hosts/services into a flat hierarchy (<xyz>.home) would be great...

but most likely we NEED an elected "master" server for this because
there is no concept of an "authoritative" router anymore.

and I think it would make sense (for this election) that not all
Homenet routers are "equal".

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 01 Sep 2015 16:56:54 +0200

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

Please, let's listen to this man.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 01 Sep 2015 17:12:40 +0200

> This and broken WiFi roaming were the only two things that made me want
> to go back to my old non-Homenet setup

I agree, these are the two remaining issues with the current Homenet stack.

If you still have some energy left for experimenting, and a spare router
lying around, I'd be curious to know whether you manage to set up
a wireless transit link (the killer feature of Homenet, IMHO, but not
necessarily easy to set up with the current OpenWRT implementation).

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Sep 2015 17:10:00 +0200

> Please, let's listen to this man.

I think we should resolve the DNS (-SD) problem inside the Homenet
first anyways...

IF homenet publishes something to the ISP it should go through a
Homenet DNS server.

the idea that every Homenet router (or even Host) talks directly
(through some transparent proxies?) with the ISP sounds scary.

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 01 Sep 2015 17:19:16 +0200

> 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! :-)

See Section 6.5 of hncp-08:

      An HNCP router SHOULD create a ULA prefix if there is no other IPv6
      prefix with a preferred time greater than 0 in the network.
      It MAY also do so, if there are other delegated IPv6 prefixes, but
      none of which is locally generated (i.e., without any Prefix
      Policy TLV) and has a preferred time greater than 0.  However, it
      MUST NOT do so otherwise.  In case multiple locally generated ULA
      prefixes are present, only the one published by the node with the
      highest node identifier is kept among those with a preferred time
      greater than 0 - if there is any.

If memory serves, by default the OpenWRT implementation will create a ULA
even if there are GUA prefixes.  If you reboot a router, the election of
the ULA might in principle cause transient ULAs to appear.

None of this is implemented in shncpd, by the way.

-- Juliusz

---

From: Ray Bellis <[email-masked]>
Date: Tue, 1 Sep 2015 16:31:07 +0100

> Please, let's listen to this man.

We've always stated from the outset that local naming services must
continue to operate uninterrupted in the absence of an upstream
connection to the internet.

Ray

---

From: Steven Barth <[email-masked]>
Date: Tue, 1 Sep 2015 18:20:25 +0200

> automatically map the persistent identifier to the topology-dependent one.

Please consider the following thoughts in no particular:

* In each "zone" collisions need to be handled gracefully.
** Also: there can be legitimate reasons for having devices with the same
	(per-link) name in different parts of your network and if you
	do service-discovery it can even be useful to know where the
	device you found is located / what it is connected to (e.g.
	printer.ethernet.office.home vs. printer.wifi.children.home)

* We currently have 2 sources of names from devices: MDNS and DHCP(v6),
	it is complicated to extend them from their natural per-link to a multi-
	link scope.
** MDNS does conflict resolution per link, extending it to multiple ones
	is problematic (c.f. draft-ietf-homenet-hybrid-proxy-zeroconf-00#appendix-C)
** Implementing multi-link hostname conflict resolution in DHCP(v6) servers sounds
	very painful (besides there are enough people already that don't even want
	to have stateful DHCPv6 by default).

* Having full-blown DNS-servers supporting zone transfers etc., on each and every
	router puts a huge additional burden on implementers, personally I don't
	see having a bind9 or similar on every router as very realistic or desirable.
	For some schemes a single one per network might but enough, but that would put
	the burden on the user to know, care and buy / install the "one".
	
* As noted by someone else in this thread, (most) users don't know about or actively
	use hostnames, so indiscriminately publishing all of them in a top-level zone
	and syncing them across the network might not be worth it.
** Many auto-generated hostnames are very opaque (e.g. foobar-a18cb3) and without
	additional service discovery information are relatively useless to a user,
	in presence of service discovery information though the names become less
	relevant.
** All that said, HNCP is already suitable to publish top-level hostnames under .home,
	for a selected set of devices.

Resolutions for some or all of these issues are of course welcome.

Cheers,

Steven

---

From: Ray Bellis <[email-masked]>
Date: Tue, 1 Sep 2015 17:26:01 +0100

> Resolutions for some or all of these issues are of course welcome.

Indeed, I know it's hard, but I believe more thought is required -
there's some very smart people working on this and it's possible that
there's a better solution that we didn't think of yet.

Also, consider that the name collision issue ideally needs to be
resolved for the externally published names.  We really don't want to
have topology dependent sub-domains appearing in the externally visible
zone.

Ray

---

From: Steven Barth <[email-masked]>
Date: Tue, 1 Sep 2015 18:37:04 +0200

> have topology dependent sub-domains appearing in the externally visible

That said I personally don't believe there should be any unconditional
publishing of internal names and service information to the outside / ISP.

The external naming can of course leverage the internal one, but it shouldn't
proxy any information outside that hasn't been explicitly acked by a human.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 1 Sep 2015 18:10:40 +0100

> On 1 Sep 2015, at 17:37, Steven Barth <[email-masked]> wrote:
> 
> 
> proxy any information outside that hasn't been explicitly acked by a human

Of course. 

Ray

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Sep 2015 09:28:46 +1000

> 	printer.ethernet.office.home vs. printer.wifi.children.home)

and people will then want search lists which will become unmanagable as
they want simple names.
 
> 	to have stateful DHCPv6 by default).

And the DNS has conflict resolution mechanisms that work over DNS
UPDATE that are mangaged by the client.  See prerequisites in UPDATE.
DHCP uses these mechanisms today to prevent DNS entries it manages
from overwriting "static" entries or entries from other DHCP servers.

> 	the burden on the user to know, care and buy / install the "one".

Zone transfers really take the abosolute minimum of code.  Go look
at the code that implements zone transfers and compare it to the
rest of a nameserver.  It really isn't hard to walk a database and
add the records to you find to a message and send it.  It also isn't
hard to read records from a message and add them to a database.

Named has additional code to allow a multiple version of a zone to
be being transfered simulaneously while updates are being processed.
It needs this code as some of the zones are gigabytes in size and
you really can't afford to abort these or fork the nameserver (BIND
4 and BIND 8 did this).

A simple implementation just aborts the zone transfer on update and
for the typical home zone it all fits in a single DNS/TCP messages
(<64k) there is nothing to abort.  The root zone fitted into a
single DNS/TCP message for decades.

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tore Anderson <[email-masked]>
Date: Sat, 5 Sep 2015 12:24:20 +0200

* Juliusz Chroboczek

> If memory serves, by default the OpenWRT implementation will create a
> ULA even if there are GUA prefixes.  If you reboot a router, the
> election of the ULA might in principle cause transient ULAs to appear.

Right. What I'm experiencing is however the existence of *two* ULAs,
one transient, and one permanent. See the screenshot below, taken after
disconnecting the ISP-facing "WAN" interface:

http://fud.no/openwrt-homenet-dual-ula.png

The fd30:35c6:9ee8::/48 prefix configured under «IPv6 ULA-Prefix» near
the bottom was automatically generated when OpenWrt was installed, and
all active interfaces on that router (even the "WAN" one) are numbered
with /64s from it at all times.

My other Homenet router also has a auto-generated «IPv6 ULA-Prefix»
setting which it numbers all of its interfaces from at all times. That
means that during normal operation, hosts on a link between the two
routers will have addresses from three prefixes: The ISP-delegated GUA,
router 1's ULA, and router 2's ULA. R1 doesn't configure its local
interfaces with addresses from R2's ULA or vice versa.

fd98:d432:6004::/48 is the transient ULA here. When this is present,
both R1 and R2 configure their local interfaces with it (so hosts
connected to the R1-R2 link will at this point have acquired addresses
from four distinct /64s: one ISP-delegated GUA, two permanent ULAs, and
one transient ULA).

What I am starting to suspect is that OpenWrt's «IPv6 ULA-Prefix»
setting is orthogonal to the Homenet handling of the interfaces, and
that in order to get the full/correct «Homenet experience» I should
disable this setting on all my routers. It could perhaps be considered
a bug that the «IPv6 ULA-Prefix» is used to number interfaces set to
Homenet/HNCP mode in the first place? I'd appreciate it if you could
confirm whether or not this is the case.

Also, to answer you other question - yes, I do have a spare router
lying around, and I do intend to try setting up wireless transit link.
I'll let you know how it went, but it'll take a while before I get
around to it, as I have to wait for a +3.3V UART to be delivered before
I can get OpenWrt installed on it.

Tore

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 09 Sep 2015 00:57:51 +0200

> setting is orthogonal to the Homenet handling of the interfaces,

Yes, that's my understanding too.

> I have to wait for a +3.3V UART to be delivered before I can get OpenWrt
> installed on it.

Then there's the bit when you try to get a reasonably reliable console by
holding the wires against the PCB... good luck.

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Wed, 9 Sep 2015 07:59:17 +0200

> confirm whether or not this is the case.

Do you by chance have "option ip6assign" still set in your hnet
configuration sections? If that is the case, these should be removed
then OpenWrt's ULA won't be assigned to those interfaces anymore.

Cheers,

Steven

---

From: Tore Anderson <[email-masked]>
Date: Wed, 9 Sep 2015 10:51:47 +0200

Hi Steven,

* Steven Barth <[email-masked]>

> then OpenWrt's ULA won't be assigned to those interfaces anymore.

I do. This is the stanza that is added to /etc/config/network when
creating a new interface using the «Automatic Homenet (HNCP)» protocol.

config interface 'vlan42'
	option proto 'hnet'
	option ifname 'eth0.42'
	option mode 'auto'
	option ip6assign '64'
	option ip4assign '24'

Note that this interface was created (using the LuCI web interface)
using the hnet protocol from the get-go; it's not a conversion of an
pre-existing interface using another protocol. I suppose the fact that
the ip6assign option is added should be considered a bug, then?

Anyway, I guess I should move this sub-thread over to the homewrt
mailing list...

Tore

---

From: Steven Barth <[email-masked]>
Date: Wed, 9 Sep 2015 11:20:09 +0200

> the ip6assign option is added should be considered a bug, then?

Good to know, I will prepare a fix for the webinterface.

Cheers,

Steven