[Battlemesh] Session about multi-homed IPv6 mesh networks and auto-configuration

Dave Taht dave.taht at gmail.com
Tue Apr 19 16:25:08 UTC 2016


On Tue, Apr 19, 2016 at 8:41 AM, Juliusz Chroboczek
<jch at pps.univ-paris-diderot.fr> wrote:
> [Adding Henning and Markus to CC.]
>
>> one problem hnetd does not handle at the moment is the concept of
>> having a metric ton of prefixes available to choose from and selecting
>> an appropriate subset to use and redistribute. Consider a network with
>> 1000 routers and 100 exit nodes - you might want 3-5 prefixes per
>> router to give you 3-5 possible exits, and rotate around them over
>> time. Otherwise you end up carrying a lot of routing traffic for ipv6
>> addresses that are mostly unused.
>
> Right.  The HNCP protocol supports doing that (the Delegated-Prefix TLV
> has a Preferred Time field, which makes it possible to gracefully
> deprecate a prefix), but neither of the implementations make use of the
> feature AFAIK.

That would be nice. A problem I have now is that a reboot of a comcast
router typically requires a reboot of the connected device, and even
then I rarely get the same /60 allocation back (I think this is in
part due to not keeping persistent state for the dhcp xid) - this
leads to all the delegated prefixes being unroutable to the internet.
Some devices are taking the delegated ra announcements and giving them
infinite lifetimes, others 10s of minutes, and it would be nice to be
able to retract or de-preference a formerly routable prefix as soon as
or nearly as soon as, a source specific default route for it
disappears.

sometimes I never get dhcp-pd to succeed again at all on it's request.
And although a /56 is available per customer, it's divvied into
separate /60 requests.

The ideal world would of course be one where everybody got a static
/48 to play with, but I think that would make the MPAA too eager to
shut people down... but boy, can dhcp-pd and dynamic addressing be
flaky and a pita for naming/finding services and servers on the
network.

> Is the amount of routing traffic really a problem in your network?  Can
> you provide some figures?

It's not the traffic, but finding stuff (and bufferbloat) that's my issue.

My network is not *that* big. :) Yurtlab has 5 uplinks, the new one
(SFlab), 3, although I hope to add a fallback to LTE to it soon. I am
merely pointing out that city-scale routing IPv6 does have some
scalability problems.

I do get concerned about it. Until recently I did not use
"redistribute local deny", and ending up with 4-6 ipv6 addresses
(privacy, dhcpv6, SLAAC) per node per network interface per prefix did
have worrisome scaling properties. When I first brought the SF network
up that was 12 nodes * 6 ips * 3 prefixes * 2 (or 3 or 4 depending on
the number of interfaces)....

It turns out that mentally I was using the p2p/32 IP announcements as
a means to have a network map, which worked fine with ipv4. So I keep
wanting to identify a single consistent ULA prefix as a means to
identify "routers" or "backbone"....

ip -6 route | grep fd99:

Can hncp "tag" a given prefix in some way to indicate how the
announcer would like it to be used?

fixing naming and service discovery would be nice. I got a kick out of
the guy trying crate.io for that rather than conventional methods.

Other open issues are that

A) I have several devices (on crappy usb wifi sticks) with a working
multicast path but apparently broken unicast one. I'd love to see ihu
go out unicast rather than multicast for a variety of reasons, not
just buggy drivers.

B) choosing a "good" node over bad. we all know packet loss ain't the
right thing...

C) stdizing on default metrics for different forms of network.

Example: I have a pi3 that has a 100Mbit interface for ethernet, and
another box with a gbit. Both announce the same metric...

D) Security

Did hnetd's security stuff get tested?

E) congestion awareness

/me hides



>> Hncp also wants to assign those real addresses to itself, and doesn't
>> cope with p2p assignment in the spec (tho julius extended it to /128s
>> I think)
>
> Right again, although shncpd doesn't yet perform address space
> optimisation (optional in the spec).  Henning has provided me with some
> patches to do that, but they need more work.  For once, please do hold
> your breath (or speak to Henning).

Heh. OK. Homenet never seemed to grok that we can do all of ipv6 out
of a single /64 for a huge network that all agrees to use /128s - and
the only thing that we lose is classic multicast. Wires are dead, why
re-create them? Much wifi turns off classic multicast (ap isolation,
etc), anyway...

>
>> I am actually not huge on global reachability for internal routers and
>> would prefer ULAs, maybe grabbing a real ipv6 address for long enough to
>> get an update, that's it.
>
> That's all supported by the protocol, but it's too complex for command-line
> options, so it'll only happen when I add a proper config file parser to
> shncpd.  It should be a simple matter of porting the parser from babeld,
> but I first want to make a stable version of shncpd and push it into Debian.

k. I did give shncpd a shot (filed a bug on it, even), but that was
during the babel channel double-free episode, I'll play with it some
more.

> -- Juliusz
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


More information about the Battlemesh mailing list