[mesh-dev] Tackling the 10.0.0.0/8 problem

[Chris Stillson]

I see the problem now.

No way to tell if 10.0.0.4 (for example) is inside or outside.

Every wireless router I have seen allows you to configure the subnet. Using
/8 seems to be pretty uncommon (no one has 2^24 devices on one router...)
so if we pick something high up, like 10.200/16 we should be ok. that gives
us 2^16 -2 addresses to use. And we might have to tell some people how to
set up subnets on their routers.

c

Chris

On Sun, Feb 8, 2015 at 8:37 PM, Chris Stillson <stillson at gmail.com> wrote:

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