Date: Thu, 24 Aug 2006 14:31:27 -0500 From: Brooks Davis <brooks@one-eyed-alien.net> To: Pat Lashley <patl+freebsd@volant.org> 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: <20060824193127.GA38855@lor.one-eyed-alien.net> In-Reply-To: <B69C016E0D5F0C26B40BE4C0@garrett.local> References: <44ED3BD1.3030206@shapeshifter.se> <AC5769F16F9730CABCCC4E61@garrett.local> <44EDA9A5.2050108@shapeshifter.se> <BE1059C6974AD43BC382E107@garrett.local> <44EDBDD0.4050000@shapeshifter.se> <7CC9AC69410B69EBD31122E4@garrett.local> <44EDDB8C.9090504@shapeshifter.se> <0EC404BA0CA363942D250766@garrett.local> <20060824182640.GA37561@lor.one-eyed-alien.net> <B69C016E0D5F0C26B40BE4C0@garrett.local>
next in thread | previous in thread | raw e-mail | index | archive | help
--UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 24, 2006 at 12:20:39PM -0400, Pat Lashley wrote: > >> > There is also an option to force it to assign > >> >(as an alias) a LLA address even if the interface is already is > >> >configured with another address. > >> > >> I think that I'd reverse the default on that. There should normally be= no > >> harm in having an LLA address, as long as we've got the non-LLA=20 > >preference > >> stuff working correctly. It is quite likely that the LLA address would > >> never actually be used; but so what? > > > >Unless we modify the IPv4 routing code to actually know that different > >interfaces with LLAs are on different subnets, we will need to insure > >that there is only one interface with an LLA on it at once. The > >modification probably makes sense, but I have no idea what it would > >entail. >=20 > Actually, it is quite possible for multiple interfaces to be on the same= =20 > LLA link/subnet; so we can't make any assumptions either way. We -do- ne= ed=20 > to be able to handle the case where they are on different links. That=20 > really isn't an 'unless', it's a 'when'. I can't see how it's worth worrying about the case they are on the same network. I'm pretty sure that if you act as though they are on separate networks things will work just as well weather they are or not. > We also need to be able to handle the case where they are on physically= =20 > different links; but the host is acting as a bridge between them to make= =20 > one logical link sharing a single LLA subnet. (We don't need to explicit= ly=20 > handle the case where the bridging is being handled externally because th= at=20 > should be virtually indistinguishable from a single physical link.) If there's a bridge (only considering if_bridge here) then the bridge interface should have the LLA. Configuring LLAs on the physical interfaces would be wrong and isn't worth supporting. > Our lla daemon should be tracking -all- LLA ARP requests/responses on the= =20 > interfaces on which it is active. So, over time, the system will normall= y=20 > collect a fairly complete set of IP address <-> MAC mappings for each=20 > interface. There's no reason why the lla daemon shouldn't add those=20 > mappings to the routing table as it discovers them. (And remove them if= =20 > they time out...) And that should make it easy to detect which interfaces= =20 > are on the same link. > > > So the issue mainly arises with the case where we want to open a connecti= on=20 > to a host/service for which we have a mapping to an LLA IP address; but n= o=20 > mapping to a MAC address. In that case, I think we need to send an ARP= =20 > request on each distinct local link for which we are using LLA. If there= =20 > are multiple interfaces connected to that link, we can choose one=20 > arbitrarily. >=20 > I think this all means that for a multi-homed host, we should not=20 > automatically add a route for the 169.254/16 network. Instead, we should= =20 > just add specific /32s as discovered; and use ARP when we need to find a= =20 > new 169.254.x.y -> MAC translation. > > > There still remains the possibility of multiple distinct hosts having the= =20 > same LLA IP address on separate local links; each attached to a separate= =20 > interface. In practice that situation should be sufficiently rare that we= =20 > can afford to ignore it until someone comes up with some clever way to=20 > handle it. (Or we all move to IPv6 and it becomes moot.) The right way to deal with this is almost certainly to adopt the KAME %interface decoration for link local addresses. LLAs are meaningless outside the context of an interface. Unless you only have one interface with an LLA, you must know which interface you are addressing to know where to send the packet. While you can hack around this in some cases by trying all of them and hoping there aren't any collisions, I think that's the wrong way to go. -- Brooks --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE7f6OXY6L6fI4GtQRAtbdAJ9jY+HfPBQM/1A/Mz4P82Ipui+9KgCg1u0O RCzusjwe/eHD6r1lVMnuRyk= =0zeh -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060824193127.GA38855>