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

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

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

[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

[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

[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

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