Re: [homenet] Host naming in Homenet

[Mark Andrews]

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: ma...@isc.org

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reachability of distributed prefixes

[Brian E Carpenter]

On 01/09/2015 01:24, Gert Doering wrote:
> Hi,
> 
> On Sun, Aug 30, 2015 at 10:03:47PM -0700, joel jaeggli wrote:
 And that's a well-known issue that the IETF needs to finally tackle:
 source-address failover. 
>>
>> So long as you don't invoke the prospect of either extremely expnesive
>> overlay networks, or globably route scalability go right ahead those are
>> both in play already.
>>
>> Hosts in in absence of state as turns out are rather good at
>> instantaneous renumbering. e.g. as they roam  between networks it
>> remains a mystery to me that networks  containy hosts are less able to
>> cope. I may be in fact that that they are not less able to cope.
> 
> No, that wasn't what I was talking about.  Not "I get a new source address
> and need to cope it", but "I have two source addresses with global scope,
> tried one according to source-selection rules, it did not work, so I 
> should maybe try the other one now?"

Yes, you're correct that shim6 doesn't do that, and has other deployability
issues that I noted. But unless we want every application and/or transport
protocol to contain its own variant of happy eyeballs, this functionality
(suck-it-and-see-until-it-works) would need to be inserted as a shim in the
socket layer or somewhere around there.

I'm not convinced there's a protocol involved, though. It's more a matter
of "history", in the sense used in draft-baker-6man-multi-homed-host.

   Brian

> 
> No network dynamics of any kind involved, just "a normal homenet 
> multi-ISP scenario" (with some breakage "somewhere upstream", not 
> something the host can easily see) - I thought that this would have been 
> obvious from the thread and WG list context.
> 
> The advertised IETF solution for "(SoHo) multihoming" is "multiple global 
> IPv6 addresses", but this does not work yet as well as it could, partly 
> due to this missing piece.
> 
> Gert Doering
> -- NetMaster
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-09.txt

[Steven Barth]

Hi everyone,

this is HNCP revision 9. This version addresses the issues raised in the second
WGLC. Changes include final adaptions to the latest DNCP version (updated TLV
definitions, improved version handling), as well as clarifications to client
configuration and naming.


Cheers,

Steven




Am 31.08.2015 um 20:09 schrieb internet-dra...@ietf.org:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Home Networking Working Group of the IETF.
> 
> Title   : Home Networking Control Protocol
> Authors : Markus Stenberg
>   Steven Barth
>   Pierre Pfister
>   Filename: draft-ietf-homenet-hncp-09.txt
>   Pages   : 39
>   Date: 2015-08-31
> 
> Abstract:
>This document describes the Home Networking Control Protocol (HNCP),
>an extensible configuration protocol and a set of requirements for
>home network devices.  HNCP is described as a profile of and
>extension to the Distributed Node Consensus Protocol (DNCP).  HNCP
>enables discovery of network borders, automated configuration of
>addresses, name resolution, service discovery, and the use of any
>routing protocol which supports routing based on both source and
>destination address.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-homenet-hncp-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] I-D Action: draft-ietf-homenet-hncp-09.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Home Networking Working Group of the IETF.

Title   : Home Networking Control Protocol
Authors : Markus Stenberg
  Steven Barth
  Pierre Pfister
Filename: draft-ietf-homenet-hncp-09.txt
Pages   : 39
Date: 2015-08-31

Abstract:
   This document describes the Home Networking Control Protocol (HNCP),
   an extensible configuration protocol and a set of requirements for
   home network devices.  HNCP is described as a profile of and
   extension to the Distributed Node Consensus Protocol (DNCP).  HNCP
   enables discovery of network borders, automated configuration of
   addresses, name resolution, service discovery, and the use of any
   routing protocol which supports routing based on both source and
   destination address.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-homenet-hncp-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Michael Thomas]

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Michael Thomas]

On 08/31/2015 05:05 AM, Markus Stenberg wrote:

On 31.8.2015, at 14.42, Ray Hunter (v6ops)  wrote:

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_.


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


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reachability of distributed prefixes

[Gert Doering]

Hi,

On Sun, Aug 30, 2015 at 10:03:47PM -0700, joel jaeggli wrote:
> >> And that's a well-known issue that the IETF needs to finally tackle:
> >> source-address failover. 
> 
> So long as you don't invoke the prospect of either extremely expnesive
> overlay networks, or globably route scalability go right ahead those are
> both in play already.
> 
> Hosts in in absence of state as turns out are rather good at
> instantaneous renumbering. e.g. as they roam  between networks it
> remains a mystery to me that networks  containy hosts are less able to
> cope. I may be in fact that that they are not less able to cope.

No, that wasn't what I was talking about.  Not "I get a new source address
and need to cope it", but "I have two source addresses with global scope,
tried one according to source-selection rules, it did not work, so I 
should maybe try the other one now?"

No network dynamics of any kind involved, just "a normal homenet 
multi-ISP scenario" (with some breakage "somewhere upstream", not 
something the host can easily see) - I thought that this would have been 
obvious from the thread and WG list context.

The advertised IETF solution for "(SoHo) multihoming" is "multiple global 
IPv6 addresses", but this does not work yet as well as it could, partly 
due to this missing piece.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279


pgpx6teaSxGkl.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reachability of distributed prefixes

[Gert Doering]

Hi,

On Mon, Aug 31, 2015 at 01:16:28PM +1200, Brian E Carpenter wrote:
> > And that's a well-known issue that the IETF needs to finally tackle:
> > source-address failover. 
> 
> We did - it's called shim6. The trouble is that we can't deploy it
> because of stupid firewalls blocking the necessary extension headers.

And that it solves a different problem.

But otherwise, yes, shim6 would have been nice to see...

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279


pgpXzqbgvABJo.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Steven Barth]

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___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Markus Stenberg]

On 31.8.2015, at 14.42, Ray Hunter (v6ops)  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.
> 
> 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?

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Ray Hunter (v6ops)]

Erik Kline wrote:

On 26 August 2015 at 15:41, Juliusz Chroboczek
  wrote:

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/

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"?


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).


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  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


--
regards,
RayH

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Tore Anderson]

* Markus Stenberg 

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

> (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.)

Understood.

Thanks!

Tore

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Markus Stenberg]

On 31.8.2015, at 14.33, Markus Stenberg  wrote:
> 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.

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Markus Stenberg]

On 31.8.2015, at 14.17, Henning Rogge  wrote:
> On Mon, Aug 31, 2015 at 12:44 PM, Markus Stenberg
>  wrote:
>> 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.
> 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.

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)

> 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".

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Markus Stenberg]

On 31.8.2015, at 14.12, Tore Anderson  wrote:
> 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.)

Implementation.

> * Markus Stenberg 
> 
>> On 31.8.2015, at 13.16, Henning Rogge  wrote:
>>> Does homenet even need a “central" DNS server?
>> 
>> 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.

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Henning Rogge]

On Mon, Aug 31, 2015 at 12:44 PM, Markus Stenberg
 wrote:
> 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.

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Tore Anderson]

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 

> On 31.8.2015, at 13.16, Henning Rogge  wrote:
> > Does homenet even need a “central" DNS server?
> 
> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Markus Stenberg]

On 31.8.2015, at 13.37, Henning Rogge  wrote:
> On Mon, Aug 31, 2015 at 12:34 PM, Markus Stenberg
>  wrote:
>> On 31.8.2015, at 13.16, Henning Rogge  wrote:
>>> 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 to the relevant
>>> homenet router, it would not be necessary to pool all the information
>>> 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).
> 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?

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Henning Rogge]

On Mon, Aug 31, 2015 at 12:34 PM, Markus Stenberg
 wrote:
> On 31.8.2015, at 13.16, Henning Rogge  wrote:
>> 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 to the relevant
>> homenet router, it would not be necessary to pool all the information
>> 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).

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Markus Stenberg]

On 31.8.2015, at 13.16, Henning Rogge  wrote:
> On Mon, Aug 31, 2015 at 11:42 AM, Steven Barth  wrote:
>>> Now could we achieve this in a multi-link Homenet without any
>>> elections?
>> 
>> 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.
> Does homenet even need a “central" DNS server?

No. It is per link, not per home.

> 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 to the relevant
> homenet router, it would not be necessary to pool all the information
> 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.

> 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.

Yes.

-Markus
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Steven Barth]

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

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet