Subject: [homenet] HNCP: Few proposed changes for next draft version

From: Steven Barth <[email-masked]>
Date: Mon, 02 Jun 2014 20:44:24 +0200

Hello everyone,

I prepared the first few changes for the upcoming HNCP draft version 01. 
Most of this is derived from features we already added to our reference 
implementation.

1. Backwards-compatibility with RFC 7084 routers.

Diff: 
https://github.com/fingon/ietf-drafts/commit/c193f27f036175ac5a006fe3df1a1ea8f908975d

2. HNCP-routers should make interface categories (auto, internal, 
external) configurable and MAY offer additional categories (guest, ad-hoc).

Diff: 
https://github.com/fingon/ietf-drafts/commit/47fdf57a1759fad6e8c6c29d741e95039aca671e

3. Some house-keeping (updating references, fixing idnits warnings)

Diff: 
https://github.com/fingon/ietf-drafts/commit/a2e2aa1f43e91e808af56f31e5ad514568fc8a6a

Feedback is welcome.

Regards,

Steven

---

From: Dave Taht <[email-masked]>
Date: Mon, 2 Jun 2014 12:11:46 -0700

> Most of this is derived from features we already added to our reference

I confess to being more interested in a status update on the implementation. ?

> 2. HNCP-routers should make interface categories (auto, internal, external)
> configurable and MAY offer additional categories (guest, ad-hoc).
>
> Diff:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 2 Jun 2014 22:36:07 +0300

> I confess to being more interested in a status update on the implementation. ?

I guess we’ll present on the topic in Toronto along the draft update(s), but highlights since London so far:

- arbitrary prefix length handling in prefix assignment

- ad-hoc/guest mode for interfaces (as specified by Steven’s diff to the -00 draft)

- support for giving PDs to downstream non-HNCP routers 

- implemented (and also somewhat tested) 6rd, dslite, map, lw4o6 transition mechanisms

- SA-aware PCP proxy/server (v4 NAT + v6 FW pinholes) on top of miniupnpd + new proxy

and of course

- a lot of bugfixes / performance optimizations (notably, Pierre’s PA code has btries and much better alg both in terms of pseudorandom allocation, as well as handling the ‘fragmentation’ of prefix space with different sized allocations)

We’re working on:

- improving configuration/management  (more knobs that you can turn if you feel like, and similarly better view of what’s going on; some of this is already done, but more work is pending)

- security

And at some point it would be nice to have also:

- multicast (sitelocal)

- UPnP (IGD perhaps via proxy, rest via multicast and/or proxy)

However, this brings to my mind a thing I’ve been meaning to ask the list for a while now.

What is the take on hncp-00 draft format? Should the strictly optional things (such as SD TLVs) be moved elsewhere?
If so, how about the somewhat more required parts such as PA or border discovery?

Cheers,

-Markus

---

From: Dave Taht <[email-masked]>
Date: Mon, 2 Jun 2014 13:05:40 -0700

> - arbitrary prefix length handling in prefix assignment

selfishly I'm interested right now in hauling a few prefixes an my
edge gateway 6 hops to my
lab. Stable enough to try that? The documentation was rather lacking
the last time I pulled the git
tree so it was kind of a mystery to configure in that case...

(for those that aren't tracking the work, the git tree can be had via a

git clone [email-masked]:sbyx/hnetd.git

)

/me pulls git tree

Wow, ton of updates! cool!

> - SA-aware PCP proxy/server (v4 NAT + v6 FW pinholes) on top of miniupnpd + new proxy

Saw the ipv6 pcp stuff land the other day. Cool. I guess.

> - a lot of bugfixes / performance optimizations (notably, Pierre’s PA code has btries and much better alg both in terms of pseudorandom allocation, as well as handling the ‘fragmentation’ of prefix…

In my case I only have a couple comcast /60s (multiple gateways), and
50 interfaces to configure,
so it's a bit much for a home scenario, but a good test of how to
break the code...

at the moment, though, I'd settle for getting one /61 to the lab somehow.

-- 
Dave Täht

---

From: Pierre Pfister <[email-masked]>
Date: Mon, 2 Jun 2014 22:20:15 +0200

Hi Dave,

You’ll find some more documentation here:
http://www.homewrt.org/doku.php

If explanation is missing, please tell. I’ll complete the doc.

The current version is working (quite stable for basic features, more buggy for newer ones), 
but we are actively debugging and now looking for feedback/testers !

It would be very helpful if you could install it on your devices and provide us some feedback.
Of course, if you have any question, we’ll be there to help/debug.

Cheers,

Pierre

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Jun 2014 20:10:16 -0400

Markus Stenberg <[email-masked]> wrote:
`   > - implemented (and also somewhat tested) 6rd, dslite, map, lw4o6
    > transition mechanisms

I assume that this is all WAN/uplink interface things.
(vs ways to get IPv6 through IPv4 only internal routers...)

    > What is the take on hncp-00 draft format? Should the strictly optional

Are you asking specifically about the TLV format, rather than
contents/semantics?

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

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 3 Jun 2014 06:58:15 +0300

On 3.6.2014, at 3.10, Michael Richardson <[email-masked]> wrote:
> (vs ways to get IPv6 through IPv4 only internal routers…)

Yes.. Internal connectivity is assumed to be dual stack, IPv4 NAT-less (among HNCP-enabled routers; obviously the prefix itself is RFC1918 and NATted for upstream access) and legacy RFC7084 inner routers will have nested IPv4 NAT and get IPv6 PD. from HNCP-enabled routers

We also test IPv6-only case to be thorough in our automated system test suite, but practically I think that’s some time off; in Finland, there’s only one ISP who even offers residential users IPv6 ;-)

> Are you asking specifically about the TLV format, rather than

Well, bit of both; how limited should the draft be in scope? As it is, it contains quite a lot of stuff and odds are not many will actually implement all of those extra bits in any case. The original reasoning was mostly to keep # of drafts low, but (based on feedback) at expense of some lack of coherence.

Cheers,

-Markus

---

From: Ray Hunter <[email-masked]>
Date: Tue, 03 Jun 2014 09:05:43 +0200

Steven Barth wrote:
> Hello everyone,
>
> I prepared the first few changes for the upcoming HNCP draft version 
> 01. Most of this is derived from features we already added to our 
> reference implementation.
>
>
Looks like a can of worms to me.

How do you intend to do this?

Are there Homenet topology limitations?

How will the user know not to plug the LAN interface of a 7084 router 
into a WAN interface?

7084 (6204bis) was intended to be a dead end once Homenet completed AFAICS.

> https://github.com/fingon/ietf-drafts/commit/47fdf57a1759fad6e8c6c29d741e95039aca671e 
Agreed. Sensible.
> https://github.com/fingon/ietf-drafts/commit/a2e2aa1f43e91e808af56f31e5ad514568fc8a6a 
Agreed.

-- 
Regards,
RayH

---

From: Steven Barth <[email-masked]>
Date: Tue, 03 Jun 2014 09:15:19 +0200

> 7084 (6204bis) was intended to be a dead end once Homenet completed 
Well maybe it was worded a bit ambiguously. The main idea behind this 
was that an HNCP router should provide "basic connectivity" in the form 
of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do 
anything fancy and just work as legacy devices believing the homenet is 
their ISP.

This should not mean you should be able to "tunnel" through 7084 routers 
or so.

Does that sound sane? And maybe what would be a better wording for this 
idea?

---

From: Ray Hunter <[email-masked]>
Date: Tue, 03 Jun 2014 09:40:55 +0200

> Steven Barth <mailto:[email-masked]>
> 3 June 2014 09:15
>
> was that an HNCP router should provide "basic connectivity" in the 
> form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should 
> not do anything fancy and just work as legacy devices believing the 
> homenet is their ISP.
>
> This should not mean you should be able to "tunnel" through 7084 
> routers or so.
>
> Does that sound sane? And maybe what would be a better wording for 
> this idea?

It is a sane idea, and I applaud any manufacturer that can prevent that 
a lot of 7084 routers are destined for the landfill sooner than they 
should be.

But it's still a can of worms and you should think very carefully 
whether you want this as a SHOULD in HNCP. I humbly suggest MAY at most.

e.g. What about the topology:

Homenet router ----- Homenet Router
     |                    |
     |                    |
L2 switch e.g. Powerline Ethernet
           |
           |
      7084 router

Which Homenet router acts as the Service Provider Router of 7084?

That's even before considering the question, what do you do when the 
7084 router is inserted between two Homenet routers?

In fairness I should declare that I was extremely skeptical about 
publishing 7084, and whether it would be harmful for Homenet.

-- 
Regards,
RayH

---

From: Steven Barth <[email-masked]>
Date: Tue, 03 Jun 2014 09:54:11 +0200

Am 03.06.2014 09:40, schrieb Ray Hunter:
> It is a sane idea, and I applaud any manufacturer that can prevent 
> that a lot of 7084 routers are destined for the landfill sooner than 
> they should be.
I guess this would not only apply to 7084 routers but "current 
IPv6-capable homerouters" in general in the end.

> whether you want this as a SHOULD in HNCP. I humbly suggest MAY at most.
I guess I'm fine with that.

> Which Homenet router acts as the Service Provider Router of 7084?
The behavior is essentially the same as with clients right now. One 
homenet router per link is elected as DHCP / DHCPv6-server. The only 
addition here is that this elected router now acts as PD-server as well.

> 7084 router is inserted between two Homenet routers?
This should be same as the current situation: If you are lucky that 7084 
router gives you PD then you have essentially two separate homenets, if 
not that homenet router behind the legacy one gets no 
(IPv6)-connectivity and probably nasty IPv4 double-NATs.  There is not 
much you can do though except teach that router to speak homenet.

> publishing 7084, and whether it would be harmful for Homenet.
Well I guess it doesn't really do much in favor of homenet by 
proclaiming: there is only the ISP on one side and clients on the other 
side you need to care about. Well at least it defines some sane 
requirements (and some less sane ones) regarding these 2 issues.

---

From: Ray Hunter <[email-masked]>
Date: Tue, 03 Jun 2014 10:08:44 +0200

> 3 June 2014 09:54
>>> Well maybe it was worded a bit ambiguously. The main idea behind 
>>> this was that an HNCP router should provide "basic connectivity" in 
>>> the form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers 
>>> should not do anything fancy and just work as legacy devices 
>>> believing the homenet is their ISP.
>>>
> This should be same as the current situation: If you are lucky that 
> 7084 router gives you PD then you have essentially two separate 
> homenets, if not that homenet router behind the legacy one gets no 

Homenet router --->PD--7084 router --> PD---- Homenet Router
     |                       |                         |
     |                       v PD                      |
     |                       |                         |
      ---L2 switch e.g. Powerline Ethernet ------------
             |
             |
      7084 router

PD loops? End users are creative.
> proclaiming: there is only the ISP on one side and clients on the 
> other side you need to care about. Well at least it defines some sane 
It was decided that any updates to 6204 for the WAN interface would be 
out of scope for 7084 and that these would instead be deferred into Homenet.

-- 
Regards,
RayH

---

From: Pierre Pfister <[email-masked]>
Date: Tue, 3 Jun 2014 10:34:24 +0200

Hello Ray,

Le 3 juin 2014 à 10:08, Ray Hunter <[email-masked]> a écrit :

>>>> Well maybe it was worded a bit ambiguously. The main idea behind this was that an HNCP router should provide "basic connectivity" in the form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do anything fancy and just work as legacy devices believing the homenet is their ISP.
>>>> 
>>>> This should not mean you should be able to "tunnel" through 7084 routers or so.
>>>> 
>>>> Does that sound sane? And maybe what would be a better wording for this idea?
>>> 
>>> It is a sane idea, and I applaud any manufacturer that can prevent that a lot of 7084 routers are destined for the landfill sooner than they should be.
>> I guess this would not only apply to 7084 routers but "current IPv6-capable homerouters" in general in the end.
>> 
>>> 
>>> But it's still a can of worms and you should think very carefully whether you want this as a SHOULD in HNCP. I humbly suggest MAY at most.
>> The behavior is essentially the same as with clients right now. One homenet router per link is elected as DHCP / DHCPv6-server. The only addition here is that this elected router now acts as PD-server as well.
>> 
>>> 
>>> That's even before considering the question, what do you do when the 7084 router is inserted between two Homenet routers?
>> This should be same as the current situation: If you are lucky that 7084 router gives you PD then you have essentially two separate homenets, if not that homenet router behind the legacy one gets no (IPv6)-connectivity and probably nasty IPv4 double-NATs.  There is not much you can do though except teach that router to speak homenet.
> 
> 
> 

Sure they are ! The details about DHCP server selection or prefix delegation are in the prefix assignment draft (http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-01), which is part of our implementation.

The proposed solution to this kind of situations is « If a delegated prefix is included in another delegated prefix, it is ignored. ».
Basically, the homenet router on the right will not take into account the delegated prefix it got from the middle 7084 router because it is a sub-prefix from the left homenet router’s delegated prefix.

I think this logic solves most of these problematic topologies. It won’t prevent network split if homenet routers are not layer-2-connected thought. 

In general, I think supporting prefix delegation is important. Even if HNCP is widely deployed, some network devices will make the choice of simplicity by only using DHCPv6-PD (without sub-delegation).

Cheers,

Pierre

>>> 
>>> 
>>> In fairness I should declare that I was extremely skeptical about publishing 7084, and whether it would be harmful for Homenet.
>>> 
>> Well I guess it doesn't really do much in favor of homenet by proclaiming: there is only the ISP on one side and clients on the other side you need to care about. Well at least it defines some sane requirements (and some less sane ones) regarding these 2 issues.
> It was decided that any updates to 6204 for the WAN interface would be out of scope for 7084 and that these would instead be deferred into Homenet.
> 
> -- 
> Regards,
> RayH
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Jun 2014 09:31:35 -0400

> How will the user know not to plug the LAN interface of a 7084 router

Or, more to the point, how can we detect this event and do something
sensible.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Jun 2014 09:34:14 -0400

Steven Barth <[email-masked]> wrote:
    > Well maybe it was worded a bit ambiguously. The main idea behind this was
    > that an HNCP router should provide "basic connectivity" in the form of
    > DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do
    > anything fancy
    > and just work as legacy devices believing the homenet is their ISP.

If the person connects things in the wrong order, should we be documenting
the heuristics that would permit the HNCP router to detect this situation?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Jun 2014 08:02:52 +1200

> the heuristics that would permit the HNCP router to detect this situation?

Let's get real. Users *will* mix and match RFC7084, RFC6204 and neither-of-
the-above IPv6 routers with HNCP-capable routers. If we can't deal with
routers that are blind to HNCP in a reasonable way, those users will
be unhappy. Indeed, the first stage is for HNCP routers to discover
the existence of HNCP-blind routers.

    Brian

---

From: Timothy Winters <[email-masked]>
Date: Tue, 3 Jun 2014 17:02:02 -0400

> the existence of HNCP-blind routers.
The following draft can from the homenet design team (http://tools.ietf.org/html/draft-winters-homenet-sper-interaction-01) tries to cover the border scenarios for 6204, 7084 and other routers (SPERs) when interacting with the Homenet.   It doesn't cover the case for routers inside a homenet but as Steven pointed out that can be two separate border router.

~Tim

---

From: Ray Hunter <[email-masked]>
Date: Wed, 04 Jun 2014 00:02:51 +0200

> Timothy Winters <mailto:[email-masked]>
> 3 June 2014 23:02
> On Jun 3, 2014, at 4:02 PM, Brian E Carpenter<[email-masked]>  wrote:
>
>>> Steven Barth<[email-masked]>  wrote:

I don't read anything in 7084 about providing PD on the LAN interfaces. 
In fact it states that it must act as "a requesting router" not a 
"delegating router"

So I don't see how the scenario of a 7084 compliant router acting as a 
border router or ISP router is going to pan out: a 7084 router only 
assigns one /64 per LAN interface (requirement L-2)

> Brian E Carpenter <mailto:[email-masked]>
> 3 June 2014 22:02
>
That's a tautology. 7084 and 6204 were explicitly designed with an 
architecture of a single router and flat user LANs. If these existing 
standards supported cascaded routers in any way, we probably wouldn't 
need Homenet.

They also cannot be assumed to deal with anything other than a default 
route (requirement W-3), SADR, or multiple upstream neighbours AFAICS 
(all requirements for PD in WPD-1 - WPD-5 talk about a (single) prefix 
(L-13) and single PD request (W-4), or that they have a facility to 
disable BCP 38 filtering (S-2).

So IHMO they're going to be limited at most to leaf nodes at the edge of 
the Homenet. And even then they're probably going to break naming.

Anything else will be a guess, as your HNCP discovery traffic will be 
blocked and you can't detect if this is a single 7084 router blocking 
HNCP, or two 7084 routers cascaded in series, or an entire homenet 
sandwiched between them.
> Michael Richardson <mailto:[email-masked]>
> 3 June 2014 15:34
> this was
> Ray Hunter <mailto:[email-masked]>
> 3 June 2014 09:05
>
>
> Steven Barth wrote:
>> Hello everyone,
>>
> ------------------------------------------------------------------------

-- 
Regards,
RayH