[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