Zeroconfig and Multicast DNS

[Ian Smith]

I've been watching this thread with great interest, having recently been
introduced to the possibilities of OLSR (net/olsrd) for local (and
beyond) P2P wi-mesh networks, and wondering if/how zeroconf fits in.

Some refs: My discovery point, a great (online) book found from a review
by Geoff Huston in the Internet Protocol Journal Vol 9 No 2, p44: 

 Wireless Networking in the Developing World: http://wndw.net/
 OLSR.ORG: http://www.olsr.org/
 RFC: http://ietf.org/rfc/rfc3626.txt (basis, though olsrd extends this)

Host addresses in such a MANET appear to require manual allocation so
far, usually in RFC1918 ranges, but the notion of zeroconfig-joining
such a network seems perhaps worthy of exploration?

Am I way off base here, thinking some matchmaking might be useful?

Cheers, Ian

On Wed, 23 Aug 2006, Pat Lashley wrote:

[..]

 > Hmmm. Interesting routing problem. Basically, we need to prefer a route that 
 > doesn't use the LLA (unless the destination is in an LLA); but still handle the 
 > edge cases like having the default route be through an LLA-only-connected 
 > router. (Which MUST do NAT...)

 > We also need to keep an eye towards dynamic roaming. One scenario is a campus 
 > composed of multiple Link Local zones and WiFi. As you move around the campus 
 > with your (running) laptop, it will have to re-negotiate/defend its LLA; and 
 > may need to obtain a different one. The address of the default router is also 
 > likely to change as it moves from one zone to another.
 > Of course, in that scenario it doesn't matter whether you have any non-LLA IP 
 > addresses; since you won't be using them. BUT if you add in a mix of non-LLA 
 > addresses advertised as servers; the routing adjustments could become quite 
 > interesting...
 > 
 > Some of the problems raised by roaming scenaria need not be addressed 
 > immediately; but we do need to keep them in mind during the design phase to 
 > ensure that our solution to the basic LLA/mDNS issues doesn't make the roaming 
 > issues even harder to handle.