[mesh-dev] Tackling the 10.0.0.0/8 problem

Sun Feb 8 20:57:27 PST 2015

are we planning on apportioning ip-addresses at flash or when the end-user
sets up the device? Maybe we can find a way to remotely change them in case
of peering overlap?

c

Chris

On Sun, Feb 8, 2015 at 8:50 PM, Mitar <mitar at tnode.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh-dev/attachments/20150208/3574bb3a/attachment.html>