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

From: [email-masked]
Date: Sun, 05 Jul 2015 04:24:13 -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-07.txt
	Pages           : 33
	Date            : 2015-07-05

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

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

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: Sun, 05 Jul 2015 13:31:20 +0200

Hello everyone,

this is HNCP revision 07 addressing comments mainly from Mikael, Juliusz and a few others
as well as some updates to use the latest version of DNCP. Even though the WGLC is still
running, we wanted to publish a new version before the IETF draft deadline for any further
reviewers.

There were mostly clarifications and additional explanations in this revision, though
we changed the HNCP Version TLV to use version 1 in this revision. This was mainly to
address behavior of the existing implementations.

Cheers,

Steven

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Jul 2015 07:57:34 +1200

Hi,

>    Stateless assignment based on Modified EUI64 interface identifiers
>    [RFC4291] SHOULD be used for address assignment whenever possible,

This is new and problematic. EUI64 is pretty much deprecated now, see
https://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-07
(in IETF Last Call) for background, and https://tools.ietf.org/html/rfc7217
https://tools.ietf.org/html/draft-ietf-6man-default-iids-04 for
the way forward.

>    otherwise (e.g., for IPv4) the following method MUST be used instead:
>    For any assigned prefix for which SLAAC cannot be used, the first
>    quarter of the addresses are reserved for routers HNCP based address
>    assignments, whereas the last three quarters are left to the DHCPv6

That would only be acceptable, I think, if you also specify that pseudo-random
allocation is used within the 1/4 and 3/4 of the addresses (referring
to IPv6 only).

   Brian

---

From: Dave Taht <[email-masked]>
Date: Sun, 5 Jul 2015 13:33:51 -0700

> https://tools.ietf.org/html/draft-ietf-6man-default-iids-04 for

Oy. One of the things I rely on is mark 1 eyeball when a device is
renumbered, or has multiple ipv6 addresses. Recognizing the std SLAAC
hex vomit pattern is VERY hard, but at least I can find things
again....

Lacking any decent naming support is a real PITA when your lower level
identifiers are random and changing all the time.

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Jul 2015 08:52:29 +1200

> identifiers are random and changing all the time.

Yep. That is of course the intended effect from a privacy point of view.
I expect that enterprise network managers will hate it too.

Please not shoot messenger.

   Brian

---

From: Dave Taht <[email-masked]>
Date: Sun, 5 Jul 2015 14:12:18 -0700

> I expect that enterprise network managers will hate it too.

Well, even in the home, I still regard there being a need for at least
SOME perimeter defense - at the moment I am leveraging the source
specific routing information to establish clear paths within my
network, and to then also block known to be problematic protocols
originating outside it - like CIFS, and port 80/443/661 from the
outside (way too many default passwords on way too many devices, like
cameras), and for that matter, port 53...

> Please not shoot messenger.

Heh. Well, is there any thinking over there about how to tie this into
mdns or dns, sanely?

having better source address selection policies on the hosts?

perimeter defense?

---

From: Steven Barth <[email-masked]>
Date: Mon, 06 Jul 2015 07:53:24 +0200

> cameras), and for that matter, port 53...

Well we are referencing normative language of RFC 7084 in HNCP, which means
that RFC 6092 is a SHOULD for us and with that basically stateful firewalling.

> Heh. Well, is there any thinking over there about how to tie this into

Well MDNS is the node's own responsibility mostly. Since that is not really
platform default everywhere we also specify naming based on hostnames
acquired via (stateful) DHCPv6/v4 which is turned on in addition to SLAAC
on routers that support it. Our reference implementation uses this - if ULAs
are present - only for ULA addresses. With only SLAAC you cannot really do
proper naming.

Cheers,

Steven