Althea Development Update #79: Things Android won't let you do

Android devices as IPv6 mesh network participants

Recently we've been working on a phone client for Althea. Our first design was to have every phone as a Babel node, advertising it's own routes and generally functioning independently.

It turns out Android will let you do this, but only in a very specific way that's not useful to us. Hopefully someone else finds the knowledge useful.

The restrictions

1. Android does not allow you to assign or modify network addresses unless you are inside a vpn tunnel. So you are at the mercy of whatever routes it decides to install into the routing table for a local network
2. Android does not support DHCPv6 in an attempt to force ISPs to assign IPv6 address blocks to customers rather than using nat6 or some other horrible solution, this means that even though we control the router we still can't insert routes, just addresses via SLACC.
3. Android only allows sufficient routing to contact immediate neighbour devices (such as to authenticate with a captive portal) until it has successfully completed a DNS lookup and https handshake with a Google server.

The tl;dr of this is that you can have an IPv4 lan with Android but not an IPv6 one, IPv6 routing can either reach Google or doesn't work at all.

As you can imagine this was a rather frustrating setback, requiring us to drop about a week of proof of concept work. Including a fully functional Babel light client. Which as far as I know is the only somewhat functional implementation of the Babel spec on Android.

Ok, so what's the workaround?

There are three possible paths forward for Althea.

• no boostrapping network, this would be like Airport WiFi, a little screen then internet. Everyone else on the network can dump your traffic and most importantly it's really easy to spoof anyone else and stick them with the bill. So that's a no go.
• Bootstrapping network with IPv6 link local addresses. This is possible but only with some sort of address translation layer that's like NAT for IPv6 but even worse and more complicated. No thank you.
• Bootstrapping network over IPv4. This is the one I ended up going with.

IPv4 light clients

This is the new design I've come up with to overcome Android's short comings, have phone clients act as a sort of light client to the host router.

The host router can then share it's IPv4 addressing to the exit and through the exit to the outside world.

This design is somewhere between the captive portal you would find at a Starbucks and the fully secure solution you find in the routers.

By using a WireGuard tunnel to the host router we get security from evesdroppers on the WiFi network, packet spoofing, and a very simple addition to our billing rules.

On the other hand the host router can still see the users packets, even if they are encrypted with HTTPS they will at least know what domains the user is visiting.

This IPv4 light client solution proposing is an improvement on the security properties of normal captive portals. But it's also a step backwards from the security promises that can be made by Althea routers.

We've decided to move forward with light clients and this security model for the time being.

Achieving the same privacy guarantees routers provide on Android would require a rewrite of WireGuard Android to produce nested tunnel packets natively. A task I estimate would take several months of work.

This way we can get a proof of concept out the door more quickly and easily and iterate from there.