Re: [mesh-dev] Tackling the 10.0.0.0/8 problem

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(a)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

>> 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

>> 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

>> 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

> be >> remapped to 10/8 after routing happens >> >> To accomplish the DHCP fakery, a modification to the openwrt dhcp

>> 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

>> 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

>> 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

>> yet tested if it works as expected, but the following commands seem to

_______________________________________________ mesh-dev mailing list mesh-dev(a)lists.sudoroom.org https://lists.sudoroom.org/listinfo/mesh-dev