Address assignment and roaming - mesh-dev

16 Feb 2015

# IPv4

We have two ways of proceeding here. We could assign a single unique IPv4
address to each node and use NAT to make the connected clients share this
IP, or we could assign a unique IPv4 subnet to each node.

I think we should go with a unique subnet. The main reason we should avoid
NAT is that NAT would make it impossible for us to implement any form of
layer 3 roaming in the future (which we currently have not even really
discussed, but it would be pretty great if it could be made to work).

I suggest we use the 100.64.0.0/10 subnet (reserved for ISP-level NAT) and
assign each node a /26 subnet. I pushed some small changes to makenode and
meshnode-database last night to make this possible.

The reason for a /26 subnet is two-fold:

* It presents a hard limit of 61 clients associated with an access point at
any given time, which is probably a good thing (this does not prevent us
from assigning larger subnets to some nodes if it becomes a problem).
* It allows us to deploy more than 60,000 nodes without the complications
to our firewall/routing rules of having multiple separate IPv4 subnets in
use.

Finally, while it's somewhat easier for humans to deal with /24 subnets, it
really isn't that bad to deal with /26 subnets. E.g: for the four /26
subnets in 10.0.0.0/24:

* Network addresses: 10.0.0.0, 10.0.0.64, 10.0.0.128, 10.0.0.192
* Gateway addresses: 10.0.0.1, 10.0.0.65, 10.0.0.129, 10.0.0.193
* Broadcast addresses: 10.0.0.63, 10.0.0.127, 10.0.0.191, 10.0.0.255

See? They're all friendly familiar numbers off by one.

# IPv6

For IPv4 we cannot hope to get an Internet routable subnet large enough for
the mesh, but for IPv6 we should be able to get ARIN to assign us a /32. We
should think of internet-routable IPv6 addresses as the way we will
interconnect with other community networks, and in general we should
severely frown upon inter/intra-mesh IPv4 traffic (perhaps going so far as
not reflecting mDNS/DNS-SD for A records). We should begin working on the
ARIN application.

Once we get the /32 from ARIN, we will need to assign each node a /64 (IPv6
seriously frowns upon subnets smaller than /64 since it breaks many IPv6
features). Unfortunately the assignment of subnets to nodes cannot be done
in some simple automated/decentralized manner, so we'll likely have to use
makenode + the meshnode-database for these assignments as well. I can see
you're disappointed, but you're still comforted by the fact that at least
the clients connected to nodes can self-assign IP addresses within the /64,
so we don't have to worry about that. Well I don't feel good about telling
you this, but most operating systems unfortunately use the EUI-64
MAC-address-based method of self-assigning IP addresses, which would mean
that every client of the mesh is trackable to their physical MAC address,
and thus their device, as they move about the mesh. This is even worse than
the situation with batman-adv, since the incriminating IPv6 source
addresses will happily leave the mesh and traverse the greater internet.
Now you might think "but isn't there an alternate self-assignment paradigm
that uses randomized addresses". Yes. Yes there is, but unfortunately the
stubborn assholes at IETF decided to shoot down proposals to deprecate this
insane IP-assignment system:

https://tools.ietf.org/html/draft-gont-6man-deprecate-eui64-based-addresses…

and even more stubborn people in charge of OS X, Linux, Android, etc. have
in their infinite wisdom decided to stick to the standard and keep the
MAC-based assignment the default. This of course means that most users have
never bothered to deviate from this setting. In this theatre of insanity,
the only operating systems which decided to switch the default to
randomized addresses is Windows Vista and newer!!!

So... I believe we must use DHCPv6 in order to protect users from their
owen devices.

However, since it's likely to take some time for us to get the IPv6 /32, I
don't think we can avoid using something else in the mean-time, so we could
save time in the short term by just letting all of the nodes and clients
self-assign in the same /64 and throw caution to the wind (for testing
purposes).

I have begun writing an IPv6 version of the subnet calculation library we
use in makenode, such that we can use if for IPv6 subnet assignment in the
near future:

  https://github.com/sudomesh/subnet

It is close to complete.

# Roaming

Based on this thread where Mitar is talking to Juliusz:

http://lists.alioth.debian.org/pipermail/babel-users/2012-April/000953.html

It sounds like it would be doable to implement layer 3 roaming using babel
route redistribution. I'm not suggesting we do this now, but it'd be
interesting to work on this later.

-- 
marc/juul