[mesh-dev] Tackling the 10.0.0.0/8 problem

[Mitar]

Hi!

So one thing which is maybe a bit more in the future is that you would
like to peer with other networks. Often this is done through VPNs:

https://dn42.net/Home
https://wiki.freifunk.net/IC-VPN

So and the idea is that you can access each others servers and services
in the network. If you have overlapping IP ranges then that is not
possible. If you use NAT, it is much harder. How I see it, we are trying
to build alternative Internet so we should try to achieve end-to-end
connectivity between our networks. In IPv4 this means that we have to be
mindful about other subnets.

The whole Guifi.net (27k nodes) is using only:

10.138.0.0/15; 10.228.0.0/16; 109.69.8.0/21; 5.10.200.0/21

See the imperfect list of what other networks are using here:

http://interop.wlan-si.net/wiki/IPAddressing/List


Mitar

> I don't see why it would be a problem. Won't NAT just deal with it?
> 
> c
> 
> Chris
> 
> On Sun, Feb 8, 2015 at 8:36 PM, Mitar <mitar at tnode.com> wrote:
> 
>> Hi!
>>
>> How much space do you need? Why not just choose one /16 subnet somewhere
>> higher than 10.0.0.0? And then you can take another one /16 when you run
>> out of it?
>>
>> Whole Germany manages to the whole /8. :-)
>>
>> http://wiki.freifunk.net/IP-Netze
>>
>>
>> Mitar
>>
>>> One big issue that we will have to deal with before really launching is
>> the
>>> fact that several home routers use 10.0.0.0
>>>
>>> I honestly don't know if any of them use 10.0.0.0/8 or if they're all
>>> 10.0.0.0/24 but either way it's a problem.
>>>
>>> There are two possible solutions.
>>>
>>> = We don't use 10.x.x.x for the mesh =
>>>
>>> There _are_ alternatives but one of them look great. Here are some I've
>>> looked at.
>>>
>>> == 44.0.0.0/8 ==
>>>
>>> This is the HAM or AMPRnet subnet. It looks like it's very scarcely used,
>>> if it's really used at all. It's for HAM packet radio and
>> experimentation.
>>> One the one hand I don't want to piss of the HAMs, but on the other hand
>>> their entire subnet is in violation of net neutrality since they don't
>>> allow commercial traffic on their subnet. This is definitely the easy
>>> solution.
>>>
>>> Here's an overview of their allocations:
>>>
>>>   https://portal.ampr.org/networks.php
>>>
>>> I'm sure if we did a ping scan of the address space we'd see only very
>> few
>>> hosts. Anyone wanna take a stab at that?
>>>
>>> == 238.0.0.0/8 ==
>>>
>>> Using multicast address space as unicast unfortunately does not work.
>>>
>>> == 240.0.0.0/8 ==
>>>
>>> All of 240.0.0.0 and above is designated as "future use". However, an
>> IETF
>>> proposal to take it into use was rejected, apparently partially because
>>> many IP stacks just outright reject or ignore any packets from this
>> address
>>> space. We'd need an overview of which systems are affected, but I don't
>>> really think this is a viable option.
>>>
>>> = We use 10.x.x.x for the mesh =
>>>
>>> If we are to use 10.x.x.x for the mesh then we will have to do something
>>> clever/ugly.
>>>
>>> A solution would contain the following parts:
>>>
>>> * The DHCP client would have to remap 10/8 DHCP responses on eth0 to a
>>> different subnet (this could be 240/8) such that the interface takes on
>> an
>>> address different from the one provided by the DHCP server.
>>> * ARP spoofing would have to be enabled on eth0 such that the node will
>>> respond to ARP requests for the address it was assigned via DHCP.
>>> * All incoming traffic on eth0 with a destination of 10/8 would have to
>> be
>>> remapped to 240/8 before routing happens
>>> * All outgoing traffic on eth0 with a destination of 240/8 would have to
>> be
>>> remapped to 10/8 after routing happens
>>>
>>> To accomplish the DHCP fakery, a modification to the openwrt dhcp client
>>> would have to be written. I don't foresee that being very difficult.
>>> Depending on the ARP spoofing difficulty, it could be as simple as adding
>>> support for a hook script that runs on dhcp lease acceptance.
>>>
>>> I'm not sure how best to do the ARP spoofing. There may be mechanisms
>> built
>>> into the Linux kernel. It may be that we can actually just assign the
>>> 10.x.x.x address gotten from the dhcp server to eth0 in addition to the
>>> 240.x.x.x address and just ensure that no mention of the 10.x.x.x address
>>> appears in the routing table and that the kernel is configure to _not_
>>> respond to ARP requests on interfaces other than the interface they are
>>> inquiring about (the default is to always answer).
>>>
>>> It seems that the address remapping might already be possible. I haven't
>>> yet tested if it works as expected, but the following commands seem to be
>>> what we'd need:
>>>
>>> iptables -t nat -A PREROUTING -i eth0 -s 10.0.0.0/8 -j NETMAP --to
>>> 239.0.0.0/8
>>> iptables -t nat -A POSTROUTING -o eth0 -d 239.0.0.0/8 -j NETMAP --to
>>> 10.0.0.0/8
>>>
>>> I'll try to set up a little experiment later tonight to see if this
>>> remapping works as expected. Honestly though, using 44.0.0.0/8 seems
>> really
>>> attractive to me at this point.
>>>
>>>
>>>
>>> _______________________________________________
>>> mesh-dev mailing list
>>> mesh-dev at lists.sudoroom.org
>>> https://lists.sudoroom.org/listinfo/mesh-dev
>>>
>>
>> --
>> http://mitar.tnode.com/
>> https://twitter.com/mitar_m
>> _______________________________________________
>> mesh-dev mailing list
>> mesh-dev at lists.sudoroom.org
>> https://lists.sudoroom.org/listinfo/mesh-dev
>>
> 
> 
> 
> _______________________________________________
> mesh-dev mailing list
> mesh-dev at lists.sudoroom.org
> https://lists.sudoroom.org/listinfo/mesh-dev
> 

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m