Re: [mesh-dev] Address assignment and roaming

# 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 _______________________________________________ mesh-dev mailing list mesh-dev(a)lists.sudoroom.org https://lists.sudoroom.org/listinfo/mesh-dev