[Commotion-dev] Unifying Serval and Commotion Mesh

[Paul Gardner-Stephen]

Hi All,

>From a Serval perspective, we chose to stick with IPv4 for a few reasons:

1. IPv4 headers are smaller, which on limited bandwidth is always a
good thing, especially when you start passing around lots of addresses
to manage your topology.
2. At a global scale 64 bits of host address in IPv6 is actually a bit
marginal for avoiding collisions among randomly self-allocated
addresses.  This is more of a concern for networks consisting of very
mobile devices, such as phones.  Overall, it can probably be managed.
3. IPv6 adds overhead without actually solving some of the more
important problems, such as preventing address spoofing, really
avoiding address collisions, and allowing easy end-to-end encryption.
Our view is that a public-key based overlay is a better solution,
which is why we have created one.  We dealt with the long-address
problem by baking in address abbreviation, so that the shortest unique
prefix of each address is used, reducing overhead to sub-IPv4 levels
in many cases, and combined overlay+IPv4 overhead to less than IPv6
overhead.
4. IPv6 is not available on all devices we wish to support, e.g., some
Symbian phones, Windows Mobile phones, and very likely some Android
phones.  See http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems.
5. We are creating digital packet radio interfaces for long-range
meshing that will have insufficient bandwidth to support IPv6
overhead.

Of course, for Serval the equation is a little different, because
routing traditional TCP/IP traffic is not our highest priority.

I should add that some of our team is more sympathetic to IPv6 than I
am, and that we don't see a problem with making use of IPv6 when it is
available, but, personally, I am somewhat reluctant to rely on it, and
harbor concerns about the increased overhead, at least unless some
sort of address abbreviation is used in the routing protocols (which
maybe it already is by now).

Paul.

On Thu, Dec 20, 2012 at 2:54 AM, The Doctor <drwho at virtadpt.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/19/2012 10:49 AM, stephane at shimaore.net wrote:
>
>> IPv6 in a non-Internet connected network is probably a good
>> choice.
>
> I think that's what Resau Libre' does.
>
>> One thing to be careful about (for Internet-connected meshes), is
>> that IPv6 connectivity is far from ubiquituous: the node(s) on the
>> mesh that connect to the Internet might not be able to route IPv6,
>> for example because their ISPs don't support it yet -- this should
>> become less of an issue over time. Hopefully that's already taken
>> into account by the mesh routing protocol.
>
> It's something of a surprise to find an ISP that does support IPv6.
>
> That said, the solution I've seen deployed in the field is v6-in-v4
> tunneling at the gateways.  I haven't tried it myself but I'm told it
> works.
>
>> Maybe more awkwardly, IPv6 and IPv4 are actually more like two
>> separate technologies when it comes to connectivity: the same way
>> that at some point in time you could access the Internet over IPX
>> and over IPv4 (I'm showing my age..), nowadays you can access it
>> using IPv6 and IPv4, but
>
> Not really.  I went hunting for floppy disks at $work this morning for
> a spectrum analyzer.
>
>> Finally, I don't know about serval, but my experience with IPv6 and
>> IPv4 and VoIP is that most stacks do not handle both together well;
>> I'm not even talking about creepy situations where signaling might
>> use one and media the other. >:)
>
> Whoa.  Bizarre...
>
> - --
> The Doctor [412/724/301/703] [ZS|Media]
> Developer, Project Byzantium: http://project-byzantium.org/
>
> PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
> WWW: https://drwho.virtadpt.net/
>
> If it's not PGP signed, it didn't come from me.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlDR6kcACgkQO9j/K4B7F8E0kgCeLm8jLj1lJ+KZeCoWW/wPkD6h
> q3EAoPfaB2PoHY9NeskdXg2BDX9nes+F
> =niAv
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
>