Skip site navigation (1)Skip section navigation (2)
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>