[mesh-dev] Address assignment and roaming

[max b]

Awesome - thanks a bunch for doing this!

Let's move forwards with the 100.64.0.0/10 subnet. I'll setup an exit
server and start configuring nodes to use that address space. I'll probably
leave the 10./8 server up for a while so that I have a live testbed to do
captive portalish work on.


See you tonight (a little late probably....)!

On Mon, Feb 16, 2015 at 3:20 PM, Marc Juul <juul at labitat.dk> wrote:

> # 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-00
>
> 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 at lists.sudoroom.org
> https://lists.sudoroom.org/listinfo/mesh-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh-dev/attachments/20150217/aa736e55/attachment.html>