Subject: [homenet] HNCPD usability issues

From: Dave Taht <[email-masked]>
Date: Sat, 21 Feb 2015 11:23:42 -0800

retitling this because I really, really, really, would like more
people using hncpd
and providing feedback on that, rather than arguing over specification
documents.

On Fri, Feb 20, 2015 at 2:14 PM, Markus Stenberg <[email-masked]> wrote:
>> On 20.2.2015, at 22.01, Dave Taht <[email-masked]> wrote:
>> On Fri, Feb 20, 2015 at 11:34 AM, Steven Barth <[email-masked]> wrote:
>>>
>>> Am 19. Februar 2015 20:05:56 MEZ, schrieb Ted Lemon <[email-masked]>:
>>>> Hm, I will have to try it out.   Is it in a distribution?
>>>
>>> ohybridproxy in openwrt. It's mainly useful with hnetd (hncp) though.
>>>
>>> Manual configuration without hncp is a bit awkward since you need to name each link manually and on every router configure the resolver (e.g. dnsmasq). I guess we might want to provide a little example for 2 links at some point.
>> I would like to deploy hncp in my upcoming make-wifi-fast testbed.
>> However the biggest headache is ensuring that all the routers
>> inbetween have hncp burned into them, and are only acting as relays as
>> I generally only obtain a few (/60) real IPv6 prefixes per GW and they
>> only need to be on the APs.
>>
>> GW1 - routerA - routerB - routerC - routerD - AP1
>>                                         |
>> GW2 - routerE - routerF - routerG - routerH - AP2
>>                           |
>>                         AP3
>>
>> GW3 ...
>>
>> (the actual topology of the testbed is way more complex than this
>> (covering ethernet, wifi, and moca) and I am not going into it here)
>>
>> 1) is there a way to configure hncpd as purely a relay, and NOT do any
>> address assignment at all on routers B,C,D,F,G,H?
>
> In theory (=spec), but not in current implementation (I _think_).

Yes, the spec seemed right, but after playing with the code, got
stuck, so I thought I would ask. If you can point me at any specific
area of the code to try to make relaying work, I can dig into it; I am
about a month away from deployment. (and have other things I would
rather do than improve hnetd, like make-wifi-fast)

I think having hncp relaying support universally is needed, and for
devices that are homenet participating but not necessarily full blown
devices - should be configured as a "relay only" by default.

the local multicast proxying problem is partially why pim-sm and
related protocols did not deploy to a huge extent, IGMP notoriously
buggy, etc, etc. See for example, the sad, underused state of pimd.

> You do not really need non-linklocal addresses for HNCP, or routing protocol, so as long as there are no hosts on the link..

That to me, was a truly major point of both hncp and routing protocol.

I have seen plenty of people gripe elsewhere about assigning *any*
public ipv6 addresses to a home router, preferring that dnsmasq´s
dhcpv6 server work without one, for example.

>(traceroute is a bitch though given just linklocals)

I don´t care about traceroute.

>
> As workaround in current implementation, if you set it to assign e.g. /80 per link used for your intermediate links, you would have almost all of address space left; however, in your case, I am not sure you can even afford to split one /64 for that purpose.

Nope, 22+ APs, most with 2 or more subnets, and a couple /60s to play
with. Have no idea with the topology above how IPv6 prefix exaustion
will be handled either.

But - more importantly - I am not interested in exposing intermediate
routers to the wild and wooly internet with public ipv6s. Got enough
firewalling problems as it is.

I realize that my use cases are a bit different than standard
homenet´s, but I am very interested in exercising the protocol to a
fuller extent than it has before.

>> 2) have you tested that it is indeed possible to get the separate ipv6
>> prefixes from GW1,GW2,GW3 to AP1,AP2, AP3?
>
> Yes.
>
>> 3) Can ULA and "Real" address assignment be distinguished along the
>> way? I have no problem assigning ULAs to the routers, but dont want to
>> use up real addresses on them.
>
> In theory (=spec), not in current implementation (ULA is actively discouraged in current impl, I cannot remember if there was option to override).

What I had done with ahcpd was: it calls a script to configure every
received address,
filter out anything but ulas, and just configure those. Easy, couple
lines of code.

>
>> 4) What happens when someone pulls the plug on GW1, it reboots, and
>> gets a new Ipv6 subnet (I have seen comcast do this to me
>> every time that happens with the code I have in place now - no
>> retraction, and I go through hell manually eliminating every former
>> prefix from the network. Yes. I have upses. And cerowrt, at least,
>> stays up for 90+ days without a problem. But it happens and sucks when
>> it does)
>
> Renumbering should just work as usual. I.e. rest of nodes should learn of the new prefix, and old one should disappear.

I hope so. Arbitrary renumber is really the biggest PITA I presently
have with comcast.

Well, with the exception of naming - ipv6 mapping - which I have just
totally given up on at present. Try to get a printer to reliably work
with a dynamic public ipv6 address... with mdns... it is less painful
to merely shoot nails into your head.

> -Markus

-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

---

From: Ted Lemon <[email-masked]>
Date: Sat, 21 Feb 2015 18:51:13 -0500

Is there an hncpd howto somewhere?

---

From: Dave Taht <[email-masked]>
Date: Sat, 21 Feb 2015 17:03:11 -0800

> Is there an hncpd howto somewhere?

http://www.homewrt.org/doku.php?id=overview

I am not sure if the howto is entirely up to date - for example I hope
they switched to using the standard openwrt ip6assign instead ip6_plen
in the /etc/config/network file.

I note that until last week I had not touched openwrt in 8 months, and
have not yet tried the latest hnetd - what I had tried to do a month
or two back with hnetd was on debian. I filed a couple bugs and then
had to do something else.

https://github.com/sbyx/hnetd/issues

one that was a PITA, now closed:

https://github.com/sbyx/hnetd/issues/21

This dhcpv6 bug with the cablemodem made PD impossible to use - the
"fix" filters it out, but the modem still gets wedged in this state,
and the issue remains unresolved upstream at comcast so far as I know.

https://github.com/sbyx/odhcp6c/issues/27

As for my relay issue in the previous mail, I think the sanest/fastest
thing for me (as opposed to the hnetd folk) to do is write a generic
udp relay program for ipv6,  (there are many for ipv4, none I have yet
found decrement the TTL. Sigh), rather than try to understand the
codebase.

-- 
Dave Täht

http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

---

From: Dave Taht <[email-masked]>
Date: Sat, 21 Feb 2015 18:52:59 -0800

and while I am at it, reviewing the draft shows that:

"  HNCP requires allocation of UDP port numbers HNCP-UDP-PORT and HNCP-
   DTLS-PORT, as well as an IPv6 link-local multicast address All-
   Homenet-Routers."

have these been applied for?

There is no scarcity on ipv6 multicast addresses at least.

In looking at the code base I see it is using

#define HNCP_PORT 8808
#define HNCP_MCAST_GROUP "ff02::8808"

no definition for a DTLS port and 8808 does not show as allocated by IANA.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 21 Feb 2015 21:56:26 -0500

Getting an early allocation for two UDP ports is probably not going to happen.   A link-local multicast address early allocation isn't out of the question, but it would be easier to just publish the document.

---

From: Steven Barth <[email-masked]>
Date: Sun, 22 Feb 2015 09:17:46 +0100

>> Is there an hncpd howto somewhere?
Please see http://www.homewrt.org/doku.php?id=run-conf
It is still up-to-date. The webinterface these days has some support for 
HNCP
configuration as well. Just make sure to not use the names "lan" oder 
"wan" for any hnet.

In the end its just as easy as installing the hnet-full package and 
adding a config section
config interface homenet1
     option ifname eth1
     option proto hncp

for each of your interfaces.

> in the /etc/config/network file.
Not yet.

> found decrement the TTL. Sigh), rather than try to understand the
As noted before option disable_pa 1 in the relevant interface 
config-section should actually just disable assigning prefixes to that 
interface. Alternatively as noted you can just change the prefix length 
to /80 or so. At some point we added support for assigning only a /128 
to lo but I haven't actually tested it in a while and I don't think its 
in our unittests.

Cheers,

Steven

---

From: Steven Barth <[email-masked]>
Date: Sun, 22 Feb 2015 09:18:42 +0100

> config interface homenet1
option proto hnet

sorry, typo ;)

---

From: Dave Taht <[email-masked]>
Date: Sun, 22 Feb 2015 00:38:24 -0800

On Sun, Feb 22, 2015 at 12:17 AM, Steven Barth <[email-masked]> wrote:
> configuration as well. Just make sure to not use the names "lan" oder "wan"
> for any hnet.
>
> In the end its just as easy as installing the hnet-full package and adding a
> config section

It is only a sed script away.

> As noted before option disable_pa 1 in the relevant interface config-section
> should actually just disable assigning prefixes to that interface.
> Alternatively as noted you can just change the prefix length to /80 or so.
> At some point we added support for assigning only a /128 to lo but I haven't
> actually tested it in a while and I don't think its in our unittests.

OK, I think. So if I have a stanza like this?

config interface 'lan'
        option ifname 'eth0.1'
        option force_link '1'
        option proto 'static'
        option ipaddr '172.21.80.1'
        option netmask '255.255.255.0'
        option ip6assign '64'

config interface 'homenet1'
        option ifname 'eth0.1'
        option proto ´hnet'
        option disable_pa 1

that interface would act as a relay, and not assign a /64 to the lan interface?

I note the last time I tried to install hnet-full it bricked the
router, killing dnsmasq entirely, killing dhcp, etc, so I was leery of
experimenting again... but I am willing to try again, being a glutton
for pain at 1AM.

moving on to more complexity, so getting that first 64 would look like?

config interface 'lan'
        option ifname 'eth0.1'
        option force_link '1'
        option proto 'static'
        option ipaddr '172.21.80.1'
        option netmask '255.255.255.0'

config interface 'homenet1'
        option ifname 'eth0.1'
        option proto 'hnet'
        option disable_pa 0
        option p6_plen 64

?

Then getting a dynamic ipv4?

Moving into more functionality, I see the documentation recommends
against using the hnet protocol on predefined interfaces like lan
entirely... if I wanted ipv4 address assignment (and I dont - without
dns to ip mapping actually working finding a box again is impossible),
what happens to these two stanzas?

How does the firewall pick it all up?

And then, there is the final caution to the winds, go pure hnetd
option. This is my freshly built, openwrt chaos calmer based config
file. It is an interior gw router (no nat):

http://snapon.lab.bufferbloat.net/~d/network

What changes are needed to drink the koolaid?

my ip route source specific stuff is working good (actual egress
gateway is like 5 hops away)

default from :: via fe80::28c6:8eff:febb:9ff0 dev eth1  proto babel  metric 1024
default from 2001:558:6045:e9:251a:738a:ac86:eaf6 via
fe80::28c6:8eff:febb:9ff0 dev eth1  proto babel  metric 1024
default from 2601:9:4e00:4cb0::/60 via fe80::28c6:8eff:febb:9ff0 dev
eth1  proto babel  metric 1024
2601:9:4e00:4cb1::/64 via fe80::28c6:8eff:febb:9ff0 dev eth1  proto
babel  metric 1024
2601:9:4e00:4cb2::/64 via fe80::28c6:8eff:febb:9ff0 dev eth1  proto
babel  metric 1024
2601:9:4e00:4cb3::/64 via fe80::28c6:8eff:febb:9ff0 dev eth1  proto
babel  metric 1024
2601:9:4e00:4cb4::/64 via fe80::28c6:8eff:febb:9ff0 dev eth1  proto
babel  metric 1024
2601:9:4e00:4cb7::2 via fe80::eea8:6bff:fefe:9a2 dev eth0.1  proto
babel  metric 1024 # manually assigned ip on my desktop
2601:9:4e00:4cb0::/60 via fe80::28c6:8eff:febb:9ff0 dev eth1  proto
babel  metric 1024

-- 
Dave Täht

---

From: Steven Barth <[email-masked]>
Date: Sun, 22 Feb 2015 09:55:05 +0100

> that interface would act as a relay, and not assign a /64 to the lan interface?
As noted please avoid assigning the names "lan" or "wan" to interfaces 
running hnet on, but besides that it's worth a try. I'm sort of on 
holiday for a few days, so I can try it out some time late next week.

> experimenting again... but I am willing to try again, being a glutton
Was this with CeroWrt? I'd recommend starting with a vanilla OpenWrt.

> Then getting a dynamic ipv4?
Just removing disable_pa and (i)p6_plen will resort to defaults, i.e. 1 
/64 per link for IPv6 and 1 /24 for IPv4.

> what happens to these two stanzas?
The only reason to not use "wan" or "lan" is that OpenWrt's firewall has 
some special semantics for interface named after firewall zones. So you 
can just rename the sections and it will work. Or as you noted 
previously you can add an additional static-configuration section for 
the same interface (you just shouldn't name it "lan" or "wan").

> How does the firewall pick it all up?
hnetd tells the firewall which firewall zone ("lan" or "wan") an 
interface should be assigned to. The zones depend on border discovery 
(manual or automatic).

> What changes are needed to drink the koolaid?
For each interfaces you want hnet to run on add a config section.
config interface homnet1
     option ifname foo1
     option proto hnet

If the original interface-name was "lan" or "wan" you should rename them 
to something different (but do not need to change anything else).

---

From: Steven Barth <[email-masked]>
Date: Sun, 22 Feb 2015 09:57:09 +0100

>
> If the original interface-name was "lan" or "wan" you should rename 
> them to something different (but do not need to change anything else).
>
Additional note:
Do NOT run DHCP or DHCPv6 manually (either server or client) on 
interfaces you run hnet on as this will cause confusion or worse. hnet 
takes care of anything DHCP(v6).

---

From: Dave Taht <[email-masked]>
Date: Sun, 22 Feb 2015 00:59:55 -0800

A sample, correct, homenet enabled openwrt network file would be good
to show somewhere. I remain a bit confused about interfaces (which are
a hint to the firewall) and ifnames. It sounds like deleting the
lan/wan entries entirely is what you want?

And how do you retain static ipv4 assignment but just get ipv6 dynamically?

On Sun, Feb 22, 2015 at 12:57 AM, Steven Barth <[email-masked]> wrote:
> Do NOT run DHCP or DHCPv6 manually (either server or client) on interfaces
> you run hnet on as this will cause confusion or worse. hnet takes care of
> anything DHCP(v6).

-- 
Dave Täht

---

From: Steven Barth <[email-masked]>
Date: Sun, 22 Feb 2015 10:19:57 +0100

>lan/wan entries entirely is what you want?

Sort of.
A default network-config-file is not trivial since the config file contains the swich config, interface names etc.and this is pretty much different from device to device.

---

From: Dave Taht <[email-masked]>
Date: Sun, 22 Feb 2015 01:29:49 -0800

> A default network-config-file is not trivial since the config file contains the swich config, interface names etc.and this is pretty much different from device to device.

I will certainly argue that given the adoption and testing rate of
hnetd so far (roughly 0), that anything you can do to make it easier
on those interested in evaluating the work, would be nice. An example
for some of the more common platforms such as the wzr, tp-link, etc
would be good.

Getting the process down to:

get the firmware
flash the firmware via the web gui

opkg install hnet-full
cd /etc/config; wget somewhere/wndr3800/network
reboot; exit # bang you are now homenet enabled

might do wonders. It certainly would in my case. I have tried 5 times
now, multiple different ways, to get it to just work, over the last 6
months, now on both openwrt and debian. Admittedly in the former case,
with my pre-concieved notions as to how things already work for me on
both exterior and interior gateways.

-- 
Dave Täht