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

From: [email-masked]
Date: Wed, 17 Jun 2015 09:37:47 -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-06.txt
	Pages           : 31
	Date            : 2015-06-17

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

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

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: Markus Stenberg <[email-masked]>
Date: Wed, 17 Jun 2015 19:40:27 +0300

> https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-06

We updated the HNCP draft based on WG chairs' comments (and some 
others). No operational changes. We consider it ready for WGLC, although 
it still could use either direct editing or further review by more people.

Updated DNCP draft will follow later this week, based on feedback from 
Thomas Clausen and some internal review.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 26 Jun 2015 17:41:11 +0200

Markus,

I still don't understand the intent of the "ad hoc" interface type.

If the ad-hoc interface is designed for non-transitive links, then the 
draft should say so (in which case I'll be glad to provide you with 
suitable prose).  However, in this case it should also identify the bits 
of DNCP which are not applicable to non-transitive interfaces (Section 
6.1.5, obviously, but I don't understand DNCP well enough to say if there 
are others).

Section 4 speaks of "ad-hoc mode" -- does that mean 802.11 IBSS?  If it 
is, then you should use the proper terminology, but I think that support 
for non-transitive links should not be restricted to 802.11 (even if the 
implementation is limited to it).

And sorry if I sound like a broken record, but I would like the ability to 
set up a router-router link with less than a full /64 allocated to it, at 
least in the ad-hoc case.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 26 Jun 2015 17:48:37 +0200

Trying to wrap my head around Section 5, so please bear with me.

If there's an IPv6-only non-Homenet router that doesn't provide PD (either 
because it only does DHCPv6 address assignment, or because it only 
advertises RA), then the link will be considered internal.  Is that correct?

If a router speaks DHCPv4 or DHCPv6-PD with a user-class of "HOMENET" but 
doesn't speak HNCP, nothing will break, right?  (Perhaps a second 
User-Class like "HOMENET-COMPATIBLE" should be defined for this case, as 
this may simplify debugging.)

Thanks,

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 26 Jun 2015 17:59:27 +0200

> this may simplify debugging.)

I'm an idiot.  Please ignore this paragraph.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Fri, 26 Jun 2015 09:19:01 -0700

On Fri, Jun 26, 2015 at 8:41 AM, Juliusz Chroboczek
<[email-masked]> wrote:
> If the ad-hoc interface is designed for non-transitive links, then the draft
> should say so (in which case I'll be glad to provide you with suitable
> prose).  However, in this case it should also identify the bits of DNCP
> which are not applicable to non-transitive interfaces (Section 6.1.5,
> obviously, but I don't understand DNCP well enough to say if there are
> others).
>
> Section 4 speaks of "ad-hoc mode" -- does that mean 802.11 IBSS?  If it is,
> then you should use the proper terminology, but I think that support for
> non-transitive links should not be restricted to 802.11 (even if the

+10 on /128 support.

I have way more p2p links than available 64s.

> -- Juliusz
>
>
> _______________________________________________
> 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: Sat, 27 Jun 2015 08:34:20 +1200

> <[email-masked]> wrote:

...
> I have way more p2p links than available 64s.

If you mean RFC6164, that would be a /127 prefix. But in any case /64 is not
sacred in IPv6. https://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix-03
was just approved by the IESG and is in the RFC Editor queue.
Any prefix length must be possible, even if /64 is preferred.

Which is actually what the draft says, in slightly strange syntax:

"  If the considered delegated prefix is an IPv6 prefix, and whenever
   there is at least one available prefix of length 64, a prefix of
   length 64 MUST be selected unless configured otherwise by an
   administrator.  In case no prefix of length 64 would be available, a
   longer prefix MAY be selected."

I'm not sure about the words "by an administrator". With my autonomic
networking hat on, I feel that configuration might arise with no human
intervention. But in any case, even given that homenet wants to prefer
/64, any length must be allowed.

    Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 27 Jun 2015 01:49:21 +0200

> If you mean RFC6164, that would be a /127 prefix.

I think Dave meant no on-link information, which unless I'm mistaken is 
equivalent to putting a /128 on the interface.  With explicitly scoped 
link-local addresses, on-link information becomes a mere optimisation 
(although an important one in the multihomed host case, where redirects 
cannot cause you to switch interfaces).

>    longer prefix MAY be selected."

Well spotted, thanks.  Markus, would you be open to relaxing the MUST, and 
adding a guideline about which of the available /64s is suitable for 
carving up?

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Sat, 27 Jun 2015 14:25:30 -0400

>>> least in the ad-hoc case.

Not sure who said this part.

My question is: for a router/router link, even if it's really ethernet rather
than PPP, why wouldn't one use *just* link-local addresses?  While I have
encountered a few OSPFv3 implementations that wouldn't run over link-local
addresses, the vendors admitted that it was a bug. (That equipment got
obsoleted due to 512K limit on v4 routing slots before that got fixed though)

If there something in HNCP that would require router/router links to be
numbered?   Or is it a case of, one just doesn't *know* that there will never
be end-hosts on the link.   If one requires manual intervention to allocate
a prefix longer than /64 to a link, then one could also just say it was a
router-only link.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Jun 2015 08:15:49 +1200

On 28/06/2015 06:25, Michael Richardson wrote:
> than PPP, why wouldn't one use *just* link-local addresses?  

As long as you don't break the rules by using those addresses in ICMP replies.

   Brian

> While I have

---

From: Pierre Pfister <[email-masked]>
Date: Sat, 27 Jun 2015 23:48:43 +0200

Hello Juliusz and Brian,

I agree with you both. The text is actually how it is because of strong opinions I received from others.
IMO, 64 should be preferred as long as it does not harm the network 
(or in cases where it is obviously not necessary, such as point-to-point links).

Relaxing the « administrator » may be confusing, as Brian said.
So I guess the MUST could become a SHOULD, which imply it requires implementers to fully understand the drawbacks
of using non-64 prefix lengths. For instance, /127 could be automatically used (no need for administrator) if a link
is auto-detected as point-to-point.

- Pierre

> I think Dave meant no on-link information, which unless I'm mistaken is equivalent to putting a /128 on the interface.  With explicitly scoped link-local addresses, on-link information becomes a mere optimisation (although an important one in the multihomed host case, where redirects cannot cause you to switch interfaces).
> 
> Well spotted, thanks.  Markus, would you be open to relaxing the MUST, and adding a guideline about which of the available /64s is suitable for carving up?
> 
> -- Juliusz
>

---

From: Gert Doering <[email-masked]>
Date: Sun, 28 Jun 2015 10:58:13 +0200

Hi,

> is auto-detected as point-to-point.

A MUST is perfectly right here.  You can't have implementation A decide
"let's use a /64 here" while implementation B goes for "/127"...

The sentence is also clearly allowing alternatives: if I tell my router
"hey, I want to use /127s on point-to-point links", this is "unless configured 
otherwise by an administrator", so the MUST is not getting in the way then.

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

SpaceNet AG                        Vorstand: 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

---

From: Pierre Pfister <[email-masked]>
Date: Sun, 28 Jun 2015 15:09:18 +0200

Hello,

> Le 28 juin 2015 à 10:58, Gert Doering <[email-masked]> a écrit :
> 
> Hi,
> 
> "let's use a /64 here" while implementation B goes for "/127"…

You actually can have implementations with different prefix length. 
This is handled by the prefix assignment algorithm.
You may have multiple routers with multiple prefix lengths, but one single
prefix is ultimately chosen and used by all routers connected to the link.

- Pierre

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 28 Jun 2015 16:22:37 +0200

Concerning the /128-on-loopback issue...

The HNCP draft is not quite clear about the semantics of the NODE-ADDRESS 
TLV (Section 6.3 of -06).  Is that for on-link addresses only?

In other words, is it legal for a router to grab an address from a prefix 
assigned by some other router (not necessarily a neighbour), advertise it 
over NODE-ADDRESS, assign it to one if its interfaces, and advertise the 
/128 over Babel?

If it's legal and doesn't cause any issues I don't see, then that pretty 
much solves this particular problem.

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Jun 2015 08:00:19 +1200

> This is handled by the prefix assignment algorithm.

Yes, you need that ability in the protocol, but it won't work in practice
to pick an oddball like /80 unless all the host stacks on the link can
handle a shorter IID like 48 (whether it's a LAN or a pt2pt). RFC 7421.

> prefix is ultimately chosen and used by all routers connected to the link.

So will it work if one router on a pt2pt expects to use a /127 and the other
one can only support /64?

    Brian

> .

---

From: Pierre Pfister <[email-masked]>
Date: Sun, 28 Jun 2015 22:49:13 +0200

Hello Juliusz,

No, as it is specified for now, a router cannot assign an address on an end-point 
unless that en-point is in a ‘Common Link’ which includes the end-point identifier.
"An assigned address MUST be in the first quarter of an assigned
      prefix currently applied on a Common Link which includes the
      interface specified by the endpoint identifier."

The address assignment process does not require this limitation though. I guess we could consider removing that.

But if what you are trying to do is assign sparse /128 to different links or loopbacks, there exists a perfectly valid way to do so.
A router can assign a /128 prefix for private use (just like it would do a PD, i.e., by advertising an ASSIGNED-PREFIX TLV with an End-Point ID equal to 0, 
or even another End-Point ID that is not used by any real interfaces), and use the address (And advertise it through the RP, 
just like it would do with any other assigned prefix).

- Pierre

> Le 28 juin 2015 à 16:22, Juliusz Chroboczek <[email-masked]> a écrit :
> 
> The HNCP draft is not quite clear about the semantics of the NODE-ADDRESS TLV (Section 6.3 of -06).  Is that for on-link addresses only?
> 
> In other words, is it legal for a router to grab an address from a prefix assigned by some other router (not necessarily a neighbour), advertise it over NODE-ADDRESS, assign it to one if its interfaces, and advertise the /128 over Babel?
> 
> If it's legal and doesn't cause any issues I don't see, then that pretty much solves this particular problem.
> 
> -- Juliusz
>

---

From: Pierre Pfister <[email-masked]>
Date: Sun, 28 Jun 2015 23:09:58 +0200

> Le 28 juin 2015 à 22:00, Brian E Carpenter <[email-masked]> a écrit :
> 

Which is why /64 SHOULD be preferred.
We also have this:
"In any case, a router MUST support a mechanism suitable to distribute
   addresses from the considered prefix to clients on the link.
   Otherwise it MUST NOT create or adopt it, i.e. a router assigning an
   IPv4 prefix MUST support the L-capability and a router assigning an
   IPv6 prefix not suitable for Stateless Address Autoconfiguration MUST
   support the H-capability as defined in Section 10 <https://tools.ietf.org/html/draft-ietf-homenet-hncp-06#section-10>.
"

So a router will not advertise a /80 on a typical link unless it implements stageful DHCPv6.

> one can only support /64?

The current document does not specify how to configure a pt2pt link.
This could be specified later really easily, in a backward compatible way.
Also, in general, why and how would a router assign a /64 to a pt2pt link ?
I mean, considering pt2pt link, we can assume both ends of the link know the nature of the link…
and are therefore able to not do weird things such as assigning a /64 on a pt2pt link.

- Pierre

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 29 Jun 2015 12:40:41 +0300

On 26.6.2015 18.41, Juliusz Chroboczek wrote:
> 6.1.5, obviously, but I don't understand DNCP well enough to say if
> there are others).

Clarifications on the text are obviously welcome and even needed :)

Due to renumbering of sections, this is bit awkward, but _as far as I 
know_, the only part that requires transitive interfaces _in DNCP_ is 
the support for dense broadcast links.

6.1.5 in dncp-06 is 'neighbor removal', and it makes no transitivity 
assumption. For each individual node, an endpoint is a local construct 
(e.g. 'this meshy eth0 interface I want to multicast+unicast on') and 
the peers that are present on it (nodes N_1.. N_n that happen to have 
been recently reachable / we have received keep-alives from / we know to 
be there by other means).

> implementation is limited to it).

Even implementation isn't limited to it.

> And sorry if I sound like a broken record, but I would like the ability
> to set up a router-router link with less than a full /64 allocated to
> it, at least in the ad-hoc case.

I am not sure about the draft text about what it should say, as non-/64 
seems to be a political hot potato (there are drafts on this too), but 
at least the implementation isn't limited to this (given configuration) 
and the draft allows for it as well (given configuration). The default 
of /64 seems still sane to me though, given no configuration.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 29 Jun 2015 11:57:53 +0200

> _as far as I know_, the only part that requires transitive interfaces 
> _in DNCP_ is the support for dense broadcast links.

After staring at the draft for two days, I agree.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Mon, 29 Jun 2015 09:06:30 -0700

> seems to be a political hot potato (there are drafts on this too), but at
> least the implementation isn't limited to this (given configuration) and the
> draft allows for it as well (given configuration). The default of /64 seems
> still sane to me though, given no configuration.

Regardless of whatever politics of artificial scarcity aligned to
wasting 64 bits,
128s are inevitable.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jun 2015 08:46:04 +1200

> Regardless of whatever politics of artificial scarcity aligned to

Yes. My point is only that the *protocol* should allow any length, in accordance
with the IPv6 architecture. The default settings should correspond to reality.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Jul 2015 11:32:49 +1200

See below...

> Also, in general, why and how would a router assign a /64 to a pt2pt link ?

I believe that RFC 7421 was needed because, in ISP land, people were
often assigning a /64 because they thought they had to, since all
the IID mechanisms assumed /64. So there was no reason for it, it was
just human behaviour.

> and are therefore able to not do weird things such as assigning a /64 on a pt2pt link.

I hope you are right. "Don't be weird" is a good motto, but "SHOULD conform
to RFC 7421" might be better in an RFC ;-).
(But then: do you want the SOHO network to automatically reserve a /64
out of which you take all the /127s for pt2pt links?)

   Brian

    Brian