[Olsr-users] AHCP

Robert Keyes (spam-protected)
Thu Feb 26 22:53:48 CET 2009


Well, it's certainly easy enough to use the MAC address to generate IP 
addresses and it will _probably_ work just fine. But it's not robust. 
Beyond that, there are certain problems with which highest-order octet to 
use. I am pretty sure that there is no one who has a spare 'class A' (a 
/8, in CIDR notation) in publicly-routed IP space which is completely 
spare and can be used for a mesh network. That leaves the possibilities of
either using 'private ip space', as specified in RFC 1918, or breaking 
routing rules and potentially causing a problem by taking a class A and 
using it as private IP space. The only RFC compliant space is 10.0.0.0/8. 
The problem is, this is used by other people in their own internal 
network, behind their NAT. This is why MIT chose to break the routing 
rules and use 5.0.0.0/8 and 6.0.0.0/8 for RoofNet. The problem is these IP 
blocks are owned by Symbolics and Honeywell-Bull, respectively, and if 
these companies ever decide to announce a route to these network 
addresses, or (more likely) the numbers become reassigned to other 
entities who route them, then trouble will arise. But hey? Why think about 
tomorrow or next year or next decade...it works now!

I would expect that after 2011, when we are projected to 'run out' of IPv4 
space, that there will be much reassignment, and reclaiming of large 
blocks of unrouted IP space such as 5 and 6 mentioned above and many 
others. But if you're okay with having to renumber down the road, then go 
ahead and use them.

But say that you want to be able to provide users of your mesh network 
with 'real' publicly routed IP addresses, and not an address behind a NAT. 
There's a bunch of protocols and applications that work better when they 
have a 'real' IP address. I can do this, because I have a class C - 
205.159.169.0/24. If I were to renumber the MAC addresses of the devices 
on my mesh, using an unassigned vendor prefix, I could then assign the 
least significant octet from 1-254 as needed, and align with the IP 
addresses, and thus avoid the use of ARP or hosts tables which is the 
reason for this whole MAC to IP mapping in the first place. Of course, I 
wonder if it wouldn't be more reasonable to continue to use ARP, but set 
the TTL to a high number, such as an hour, to keep the amount of ARP 
traffic on the mesh to a minimum, yet still have the flexibility that ARP 
provides. We could even use DHCP. It could be easy. Maybe ARP needs to 
come back.

What about 802.11s? How is arp going to work with that?




More information about the Olsr-users mailing list