<div dir="ltr">Hello,<div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Thu, May 2, 2013 at 5:47 AM, Hans-Christoph Steiner <span dir="ltr"><<a href="mailto:hans@guardianproject.info" target="_blank">hans@guardianproject.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
One idea that we discussed at the last dev sprint last Thursday/Friday is<br>
nailing down a default mesh profile that we can set everywhere. The core idea<br>
is that people can use this as the easiest way to get started, and also, it<br>
can serve as the mesh config for impromptu meshing.<br>
<br>
Currently, we have been using this:<br>
<br>
SSID: <a href="http://commotionwireless.net" target="_blank">commotionwireless.net</a><br>
BSSID: 02:CA:FF:EE:BA:BE<br>
Channel: 5<br>
IP range: <a href="http://5.0.0.0/255.0.0.0" target="_blank">5.0.0.0/255.0.0.0</a><br>
<br>
There are two issues that we need to address in order to nail down this<br>
default profile: a valid IP range, and perhaps a unique BSSID.<br>
<br>
<a href="http://5.0.0.0/255.0.0.0" target="_blank">5.0.0.0/255.0.0.0</a> is an officially allocated block of IPs that is actually<br>
deployed in some places. We should use an IP block that is officially<br>
allocated for uses like Commotion intends. We discussed this, and it seems<br>
like the best bet is to use one of the RFC1918 private network ranges (10/8,<br>
172.16/12, and 192.168/16). 172.16.0.0-172.31.255.255 seems to be the least<br>
used of the three. It privdes 1,048,576 unique IP addresses, so plenty.<br>
<br>
We might want to consider using <a href="http://100.64.0.0/10" target="_blank">100.64.0.0/10</a>, which is reserved for "carrier<br>
grade NAT", i.e. a large scale NATed network that is attached to the internet.<br>
<a href="https://en.wikipedia.org/wiki/Private_network#Dedicated_space_for_Carrier_Grade_NAT_deployments" target="_blank">https://en.wikipedia.org/wiki/Private_network#Dedicated_space_for_Carrier_Grade_NAT_deployments</a><br>
<br>
The rules for using it are in RFC 6598:<br>
<a href="https://tools.ietf.org/html/rfc6598" target="_blank">https://tools.ietf.org/html/rfc6598</a></blockquote><div><br></div></div><div>With Serval we decided to go with <a href="http://28.0.0.0/254.0.0.0" target="_blank">28.0.0.0/254.0.0.0</a> 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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div class="im">
<div> </div><div style>As for IPv6, I am not convinced that it is necessary or that good an idea. </div><div style>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.</div>
<div style><br></div><div style>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.</div><div style>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.</div>
<div style>IPv6 is only necessary in that role when networks get very large (>~5,800 nodes if you use <a href="http://28.0.0.0/7">28.0.0.0/7</a>). In the meantime, the larger IPv6 headers will consume precious bandwidth.</div>
<div style><br></div><div style>So IPv6 can make sense if you want to future-proof yourself for what I would call "intermediate sized" mesh networks. </div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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). </div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As for the BSSID, I think we should probably use a unique BSSID to prevent<br>
collisions with other mesh networks. 02:ca:ff:ee:ba:be is used by a number of<br>
other meshes. It really could be any valid adhoc BSSID like 02:02:02:02:02:02<br></blockquote><div><br></div></div><div>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.</div>
<div><br></div><div>So in short, my vote is don't change the BSSID, and feel free to use the <a href="http://28.0.0.0/7" target="_blank">28.0.0.0/7</a> address range as well if you like.</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div>
Paul.</div></font></span><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
.hc<br>
_______________________________________________<br>
Commotion-dev mailing list<br>
<a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">Commotion-dev@lists.chambana.net</a><br>
<a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>
</blockquote></div></div><br></div></div>
</div><br></div>