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

From: [email-masked]
Date: Tue, 02 Jun 2015 02:47:16 -0700

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-05.txt
	Pages           : 30
	Date            : 2015-06-02

Abstract:
   This document describes the Home Networking Control Protocol (HNCP),
   an extensible configuration protocol and a set of requirements for
   home network devices on top of the Distributed Node Consensus
   Protocol (DNCP).  It enables automated configuration of addresses,
   naming, network borders and the seamless use of a routing protocol.

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

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

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/

---

From: Steven Barth <[email-masked]>
Date: Tue, 02 Jun 2015 11:52:37 +0200

Hello everyone,

as announced here is the latest version of HNCP. We would kindly like to
request a WGLC for this as well.
This one also already includes feedback for HNCP we got during the
DNCP-LC, so thanks again for this.

Draft URL: https://tools.ietf.org/html/draft-ietf-homenet-hncp-05

Notable changes since HNCP-04:

* Renamed "Adjacent Link" to "Common Link".
* Changed single IPv4 uplink election from MUST to MAY.
* Added explicit indication to distinguish (IPv4-)DPs for local
connectivity and ones with uplink connectivity allowing e.g. better
local-only IPv4-connectivity.

Cheers,

Steven, Markus & Pierre

On 02.06.2015 11:47, [email-masked] wrote:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 08 Jun 2015 14:53:28 +0200

> as announced here is the latest version of HNCP.

Thanks a lot.

As mentioned previously, we did set up a wired HNCP network here in Paris 
last month, and it works beautifully (at least on wired links).  I strongly 
support this work.

I rather like HNCP, which feels much less rigid than DNCP.  In particular, 
I'm glad to see that mDNS-proxying remains optional.

Questions and minor nits below, probably more to follow.

# Ad-hoc interfaces

You don't define ad-hoc interfaces.  From Section 4, it would seem that 
these are for non-transitive links with no prefix assignment (a la AHCP), 
but in that case some changes may be needed to DNCP, which I don't think 
will work on non-transitive links in its current shape.  In any case, the 
purpose of this feature needs to be made explained to the naive reader.

# Border discovery

What happens if there is a non-Homenet DHCP server on a link, but for some 
reason an address cannot be obtained from it (e.g. the server NAKs all 
DISCOVER/REQUEST messages)?  My reading is that the interface will be 
considered internal, and therefore not firewalled.  Is that the expected 
outcome?

# Policy needs review

There is a certain amount of policy in Section 6.4 and in Section 7 that 
needs careful review by a competent third party.  In particular, I'm not 
entirely comfortable with the IPv4 requirements in Section 6.4 (the IPv6 
requirements look fine to my amateurish eyes).

Section 7.1: I'm not familiar with DHCPv6, but is a preferred lifetime of 
1s a good idea?

Sections 7.2 and 7.4: why announce a route for each subnet?  We've got 
redirects for that.

# Reassembly

An HNCP node MUST be able to reassemble datagrams of 4000 octets.  IPv6 
allows a node to silently drop datagrams above 1500 octets.  Are there any 
widely-deployed stacks that limit reassembly to 1500 octets?  If so, 
I expect this to be the source of difficult to diagnose bugs.

---

From: Steven Barth <[email-masked]>
Date: Mon, 08 Jun 2015 15:43:06 +0200

Hi Juliusz,

> As mentioned previously, we did set up a wired HNCP network here in
> Paris last month, and it works beautifully (at least on wired links). 
> I strongly support this work.
thanks a lot for your (repeated) feedback and support.

>
> # Ad-hoc interfaces
>
> You don't define ad-hoc interfaces.  From Section 4, it would seem
> that these are for non-transitive links with no prefix assignment (a
> la AHCP), but in that case some changes may be needed to DNCP, which I
> don't think will work on non-transitive links in its current shape. 
> In any case, the purpose of this feature needs to be made explained to
> the naive reader.
In it's current form the adhoc-interface category in-fact results in an
assignment of a /64 per EACH adhoc-interface since the common-link is
defined to only consist of the single ad-hoc interface (including
potentially connected client-devices). An implementation can of course
provide configuration mechanisms to turn off address assignment on a
per-interface basis - independent of the interface being adhoc or not.

>
>
> # Border discovery
>
> What happens if there is a non-Homenet DHCP server on a link, but for
> some reason an address cannot be obtained from it (e.g. the server
> NAKs all DISCOVER/REQUEST messages)?  My reading is that the interface
> will be considered internal, and therefore not firewalled.  Is that
> the expected outcome?
Your reading is correct. However since homenet routers also reject (or
ignore) DHCP requests coming from other homenet routers, the situation
would be ambiguous if the outcome was different. Also please note that
the automatic border discovery is a best-effort heuristic to provide a
good (zeroconf) user experience as also explicitly noted in the security
considerations section. A router must in anyway provide means to set an
interface to a fixed category of internal or external.

>
> # Policy needs review
>
> There is a certain amount of policy in Section 6.4 and in Section 7
> that needs careful review by a competent third party.  In particular,
> I'm not entirely comfortable with the IPv4 requirements in Section 6.4
> (the IPv6 requirements look fine to my amateurish eyes).
The IPv4-policy is a bit complex, yes. The reasoning behind this is that
DHCP (and most client OS in general) do not really deal well with
multiple IPv4-addresses thats why we make sure that there is at most one
IPv4-prefix. There are other factors here, e.g. router's with global
IPv4 connectivity having preference other router's that can only provide
local IPv4 connectivity, etc.

>
> Section 7.1: I'm not familiar with DHCPv6, but is a preferred lifetime
> of 1s a good idea?
Noted, I will change this in the next revision, the intention here is to
keep fast renumbering working even with stateful DHCPv6. The given
procedure is probably debatable and inferior to others, i.e. one might
only hand out a lease for a ULA-based address and let global addresses
be numbered using RAs only.

> Sections 7.2 and 7.4: why announce a route for each subnet?  We've got
I think you misread that. The text says to announce one route per
"delegated prefix" not per "assigned prefix". This is e.g. to allow
differentiation of local and global connectivity. It is inherited from
RFC 7084 which more or less mandates that (for IPv6).

Cheers,

Steven

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 08 Jun 2015 16:28:44 +0200

>> la AHCP), but in that case some changes may be needed to DNCP,

> assignment of a /64 per EACH adhoc-interface

I see.

So is that meant to support non-transitive links, or something else?  If 
the former, I'll need to go through the DNCP draft and stare at the places 
that seem to assume transitivity until grokking comes.

In any case, you need to provide some rationale and implementation 
guidance for the ad-hoc interface type.

> "delegated prefix"

Right.  Am I the only person who got confused by that?

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 08 Jun 2015 17:39:26 +0300

Thanks for the review from me as well.

On 8.6.2015 17.28, Juliusz Chroboczek wrote:
>> In it's current form the adhoc-interface category in-fact results in
>> an assignment of a /64 per EACH adhoc-interface
> I see.
>
> the former, I'll need to go through the DNCP draft and stare at the
> places that seem to assume transitivity until grokking comes.

DNCP supports transitive links _and_ non-transitive links, but some 
corner cases (e.g. consistently unreliable non-transitive links) result 
in the well-known (and typically bad) naive non-mesh link-state routing 
protocol-like behavior (flapping neighbor status, and in this case, 
Trickle never settling down so bit more churn overall).

> guidance for the ad-hoc interface type.

I wonder how well the implementation and the spec are in sync these days 
- at least the implementation is very hairy in the various specialized 
HNCP modes.

>>> Sections 7.2 and 7.4: why announce a route for each subnet?  We've
>>> got redirects for that.
>

I would like to get 'proof of life' of other people actually reading the 
spec - anyone? ;)

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 09 Jun 2015 00:06:15 +0200

> DNCP supports [...] non-transitive links

The optional algorithm in Section 6.2 most certainly won't work on 
non-transitive links.  (It's optional, so no big deal, but if DNCP is 
documented to work on non-transitive links, then this should be mentioned 
somewhere.)

I'm not sure if there are any other issues with non-transitive links, and 
I'm too tired right now for further nit-picking.  I'll do my best tomorrow.

-- Juliusz