Date: Wed, 23 Aug 2006 15:54:59 -0400 From: Pat Lashley <patl@volant.org> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: freebsd-net@freebsd.org, Doug Barton <dougb@freebsd.org>, Fredrik Lindberg <fli+freebsd-net@shapeshifter.se> Subject: Re: Zeroconfig and Multicast DNS Message-ID: <23D2619F6BACE4E728178EE5@garrett.local> In-Reply-To: <20060823221835.GA28978@lor.one-eyed-alien.net> References: <DD49A62B2AB4E38804FB10B6@garrett.local> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <C408C9E0406302DF5EE12E67@garrett.local> <20060823212110.GD27961@lor.one-eyed-alien.net> <D6D2605619AD2B0F140F5802@garrett.local> <20060823221835.GA28978@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> DHCP+static is rather weird, but common enough that we do support it. I > suspect LLA with other address types is also of use at least some > of the time so we should ideally support it. Actually if we don't mind > always configuring a LLA I think we might support be OK right now as > long as the LLA daemon leaves non-LLA addresses alone. The LLA daemon really needs to restrict itself to the LL IP range anyway to be compliant. > The one thing > I'd be worried about is how the socket code handles connect() requests. > My hope would be that it would pick the address that goes with the > router to be used and thus the LLA would never be the source of a packet > going to a non-LLA address in normal circumstances. The RFC is pretty explicit about the need to prefer non-LLA addresses. We may need to put some explicit checks in the connect() code to enforce that preference in the aliased case. The trick, of course, is to recognize those cases where the LLA address must be used anyway. 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. -Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23D2619F6BACE4E728178EE5>