[OLSR-users] duplicate IP behaviour

Sun Feb 19 06:17:18 CET 2006

Hi all,

I strongly believe that OLSR with some sort of autoconf capability would be
a very powerful routing protocol.  A DHCP-based implementation would be good
for IPv4 networks, and I'd be keen to see Andreas develop some code along
these lines.

I recently re-acquainted myself with IPv6's ability to self-assign and
renumber addresses.  IPv6 looks to be a very powerful and versatile way to
run a decentralised, autoconfiguring, ad-hoc network.

The beauty of IPv6 is that you can renumber whole subnets easily - good for
situations where two mesh clouds merge and node addresses (which had been
self-assigned in isolation) in the clouds overlap each other - you can
renumber the whole cloud with no problems.

With a self-configuring IPv6 system, people who own OLSR nodes wouldn't
necessarily have to know anything about how IPv6 works.  The routers can
generate their own addresses and hand out addresses to new routers
automatically.  IPv6 is used for routing purposes, and the addressing system
can be fully controlled (down to the level of individual host addresses) or
partially controlled (down to regional subnet level) by a central network
administration.

The problem arises when you want to allow IPv4-only nodes access to the
network.  But this isn't really as bad a problem as you might think.  The
Freifunk Firmware uses DHCP and NAT to allow non-routing nodes access.
These non-routing nodes can't be seen by the rest of the network because
they are hidden behind their local router's NAT - the DHCP subnet isn't
usually HNA-advertised.  A similar thing could be achieved with IPv6 - non
routing nodes could be given an IPv4 address via DHCP running on the closest
router.  That router then does IPv4-to-IPv6 translation so those non-routing
nodes can access the rest of the network.  Something like DNS and/or the
Nameservice plugin could be used so that the non-routing nodes don't need to
speak IPv6 - they just identify nodes on the network by name and they rely
on their local router to resolve the name to an IPv6 address.

Cheers,

Dan

-------------
View my blog:
http://freenetjazz.blogspot.com  

> -----Original Message-----
> From: (spam-protected) 
> [mailto:(spam-protected)] On Behalf Of Andreas Tønnesen
> Sent: Monday, 13 February 2006 8:58 PM
> To: OLSR discussion and development
> Subject: Re: [OLSR-users] duplicate IP behaviour
> 
> Sven-Ola,
> 
> I agree that it might not be a good thing to terminate upon 
> duplicate detection as default. Let's rather consider hving 
> this termination/execution idea available as an explicit 
> option and keep the currnt behvior as default.
> 
> Now regarding autoconfig, I have actually been playing with 
> the idea of implementing a solution based on dhcp where one 
> or more central boxes act as DHCP servers while olsrd 
> forwards requests/responses. This would include a client that 
> auto-detects olsr networks/mode(LQ/RFC) and possibly other 
> settings as well(?) This will break with the distributed idea 
> of ad-hoc networks, but I think it would work fine in your 
> standard community network... well - I'll get working on it 
> one of those 25 hours days ;-)
> 
> > Andeas,
> >
> > please do *not* exit olsrd without further necessity. It's 
> too easy to 
> > bring a complete mesh down simply by configuring an ip twice. The 
> > zeroconf people may consider ipv6 with an address based on the MAC 
> > instead.
> >
> > My two cents: zeroconf/dhcp/rendevezous and others are 
> unsuitable for 
> > a bigger mesh, because you give away the (small) 
> opportunity for some 
> > management here. People need to talk to each other - which 
> is hard a 
> > total anon environment. OK - that's layer 8, not covered by ISO/OSI 
> > nor olsrd
> > ;-)
> >
> > LG
> > Sven-Ola
> >
> > "Andreas "Tønnesen"" <(spam-protected)> schrieb im Newsbeitrag 
> > news:(spam-protected)
> >>
> >> As long as two nodes share the same _main_ address, then the nodes 
> >> should just discard the packets originating from eachother. You 
> >> should see a message like "Not processing message originating from 
> >> us!"
> >> As for messages beeing forwarded via other nodes I'll look that up 
> >> later (when I get back home).
> >> I agree that the best solution might be that olsrd exits when 
> >> encountering a IP duplicate.. but I'm not 100% sure(perhaps this 
> >> should be yet another configurable option). But multiple 
> nodes using 
> >> the same main address will have a very bad impact on the 
> network. So 
> >> I guess what I'm saying is that we should enforce some sort of DAD 
> >> which tries to make the network kind of "self healing" bu 
> terminating 
> >> the conflicting clients.
> >> But I can't remember having implemented a termination if 
> this occurs...
> >> Well - I'll have a look at it later on.
> >>
> >> - Andreas
> >>
> >>> Hi,
> >>>
> >>> When testing what would happen if two OLSR nodes have the 
> same IP, 
> >>> we found out that both just keep on running, but they loose their 
> >>> peer connections. This was tested on version 0.4.9 on OpenWRT 
> >>> (Linksys WRT54G, IPv4).
> >>>
> >>> I tested this a long time ago and i'm quite sure the result back 
> >>> then was that the first node detecting a simular IP would 
> just crash 
> >>> with a clear OLSR error message about what went wrong.
> >>>
> >>> Has this behaviour been changed recently, or is this a 
> bug that got 
> >>> into the software during recent routing-algorithm changes?
> >>>
> >>> For our un-administered network setup, an OLSR crash that we can 
> >>> detect would be ideal, so we can just choose another IP 
> and restart 
> >>> OLSR. If someone knows about another trick to detect duplicate IP 
> >>> numbers, i'm also very interested.
> >>>
> >>> Thank you for your help,
> >>>
> >>> Jaap
> >>>
> >>> _______________________________________________
> >>> olsr-users mailing list
> >>> (spam-protected)
> >>> https://www.olsr.org/mailman/listinfo/olsr-users
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> olsr-users mailing list
> >> (spam-protected)
> >> https://www.olsr.org/mailman/listinfo/olsr-users
> >
> >
> > _______________________________________________
> > olsr-users mailing list
> > (spam-protected)
> > https://www.olsr.org/mailman/listinfo/olsr-users
> >
> 
> 
> 
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users
> 