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@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@lists.sudoroom.org
https://lists.sudoroom.org/listinfo/mesh-dev