[Olsr-users] AHCP
Henning Rogge
(spam-protected)
Fri Feb 27 08:11:03 CET 2009
Am Thursday 26 February 2009 22:53:48 schrieb Robert Keyes:
> 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!
IPv6... if we run out of address space there, we will think about the problem
again.
> 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.
We will just switch to IPv6 for OLSR networks. It's not that difficult to
route IPv4 traffic through IPv6 mesh clouds.
> What about 802.11s? How is arp going to work with that?
802.11s runs on layer 2 with MAC addresses, it does not even know about IP I
think.
Henning
*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN)
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: (spam-protected)
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.
Joachim Ender (Stellv.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20090227/234fcbef/attachment.sig>
More information about the Olsr-users
mailing list