[Commotion-dev] Fwd: nailing down the default mesh network

Wed May 1 22:04:50 UTC 2013

Hello,

On Thu, May 2, 2013 at 5:47 AM, Hans-Christoph Steiner <
hans at guardianproject.info> wrote:

>
> One idea that we discussed at the last dev sprint last Thursday/Friday is
> nailing down a default mesh profile that we can set everywhere.  The core
> idea
> is that people can use this as the easiest way to get started, and also, it
> can serve as the mesh config for impromptu meshing.
>
> Currently, we have been using this:
>
> SSID: commotionwireless.net
> BSSID: 02:CA:FF:EE:BA:BE
> Channel: 5
> IP range: 5.0.0.0/255.0.0.0
>
> There are two issues that we need to address in order to nail down this
> default profile: a valid IP range, and perhaps a unique BSSID.
>
> 5.0.0.0/255.0.0.0 is an officially allocated block of IPs that is actually
> deployed in some places.  We should use an IP block that is officially
> allocated for uses like Commotion intends.  We discussed this, and it seems
> like the best bet is to use one of the RFC1918 private network ranges
> (10/8,
> 172.16/12, and 192.168/16).  172.16.0.0-172.31.255.255 seems to be the
> least
> used of the three.  It privdes 1,048,576 unique IP addresses, so plenty.
>
> We might want to consider using 100.64.0.0/10, which is reserved for
> "carrier
> grade NAT", i.e. a large scale NATed network that is attached to the
> internet.
>
> https://en.wikipedia.org/wiki/Private_network#Dedicated_space_for_Carrier_Grade_NAT_deployments
>
> The rules for using it are in RFC 6598:
> https://tools.ietf.org/html/rfc6598

With Serval we decided to go with 28.0.0.0/254.0.0.0 to give ~32 million
addresses.  This range is US DoD internal use, and as far as we are aware
is not connected to the internet.  Also, as connections to the net from a
mesh are almost always using NAT, the likelihood of issues is further
reduced.  In fact, since a mesh is effectively a separate network from the
internet that happens to have gateways to the internet you are free to use
whatever range you like.  However, as you have indirectly noted using
address ranges that people might try to connect to on the internet causes
complications for most clients.

We went for such a large range because it allows for random self-allocation
of addresses even for relatively large networks.  The Birthday Paradox
implies that you need >=n^2 addresses to allow n nodes to randomly self
allocate addresses while keeping the probability of an address collision
<<0.5.  This makes it feasible to remove one typically annoying and error
prone step of mesh deployment, i.e., address allocation and management.

Having 2^25 addresses allows for 2^(12.5) nodes = ~5,800 nodes without
worrying about the Birthday Paradox.  Probably an overkill for now, but not
if you support mobile nodes, where address collisions are almost certain to
occur.  This is also why we adopted our overlay addressing scheme with 256
bit addresses so that at the end of the day, it wouldn't matter what
address people self-allocated.  But for Commotion one of the primary goals
is internet connectivity, and so using the Serval overlay addressing scheme
as primary transport would require some work around creating an MDP
transported transparent proxy -- not impossible, but probably not something
that needs to happen until you start getting larger deployments with many
mobile devices.

As for IPv6, I am not convinced that it is necessary or that good an idea.
Before explaining my position it is important to confess that I am in many
ways an IPv6 skeptic, several of the reasons for which will become apparent
below.  But generally I take the view that if IPv6 really is that good,
then we would have more widely adopted it in the 18 years (!) since it was
released. Instead, all it does is offer more addresses in a generally
backward-incompatible way, and several peripheral features that were
already solved in IPv4, admittedly with less elegance.  But I digress.

Compiling in IPv6 to a kernel adds some extra flash and RAM use that might
be an issue on smaller devices, but that is a diminishing concern.
The bigger issue is requiring every device that connects to support IPv6.
 This can be managed by allowing clients to connect with IPv4, and thus
just using the IPv6 for mesh traffic between nodes.
IPv6 is only necessary in that role when networks get very large (>~5,800
nodes if you use 28.0.0.0/7). In the meantime, the larger IPv6 headers will
consume precious bandwidth.

So IPv6 can make sense if you want to future-proof yourself for what I
would call "intermediate sized" mesh networks.

But once you start thinking about global-scale mobility and >=1 node per
person, the Birthday Paradox starts to be an issue for IPv6, because there
are only 64-bits of host address, which means only 2^32 nodes can safely
randomly self-allocate addresses.  MAC-based address allocation is not
safe, because MAC addresses just aren't unique.

Finally, from Serval's perspective using IPv6 didn't answer the important
question of security, and how to get automatic and fully-distributed
end-to-end encryption between nodes.  This is why we made the overlay
addressing scheme using 256-bit ECC public keys as network addresses.  That
way we get enough addresses for 2^128 nodes (almost enough for every atom
in the planet to randomly self-allocate an address).

We then combined that with address abbreviation to have typical address
lengths in packets of <32bits.  This is important for using low-bandwidth
links like packet radio where links might be between 1kbit - 128kbit, and
where IPv6 headers can consume a significant fraction of that.  Using a
user-land overlay also makes it much easier to use serial packet radios,
because we don't need to expose it as a system network interface, and worry
about things like ARP and goodness knows what consuming the precious little
bandwidth.

Of course the applications of each project differ slightly, and this will
have significant impact on what is most suitable in each case, but
hopefully having an understanding of the decisions we made will be of some
use as Commotion works through these same issues.

As for the BSSID, I think we should probably use a unique BSSID to prevent
> collisions with other mesh networks.  02:ca:ff:ee:ba:be is used by a
> number of
> other meshes.  It really could be any valid adhoc BSSID like
> 02:02:02:02:02:02
>

I don't see a problem with sharing BSSID with other meshes, or IP ranges
for that matter,  since mesh networks tend to benefit from interconnection.
 Keeping them artificially separate seems to offer no real advantages that
I can think of.  On the other hand, allowing interconnection, even if only
at the 1-hop level, gives the potential for information and software
sharing in the field.  This would allow users on one mesh to decide to
"switch camps" much more easily than if they are isolated from access to
the other mesh, and thus unable to obtain the software necessary.  This
thinking has Rhizome distribution of software images in mind, that can be
easily presented for download via an HTTP interface.

So in short, my vote is don't change the BSSID, and feel free to use the
28.0.0.0/7 address range as well if you like.

Paul.

> .hc
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130502/6e39d8d9/attachment-0001.html>