Date: Thu, 24 Aug 2006 14:58:17 -0700 From: Chuck Swiger <cswiger@mac.com> To: Pat Lashley <patl+freebsd@volant.org> Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS Message-ID: <22D92E8D-DE18-4883-8E77-5567AF63DFE0@mac.com> In-Reply-To: <B69C016E0D5F0C26B40BE4C0@garrett.local> References: <20060823221835.GA28978@lor.one-eyed-alien.net> <23D2619F6BACE4E728178EE5@garrett.local> <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
On Aug 24, 2006, at 9:20 AM, Pat Lashley wrote:
>> 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.
>
> Actually, it is quite possible for multiple interfaces to be on the
> same LLA link/subnet; so we can't make any assumptions either way.
> We -do- need to be able to handle the case where they are on
> different links. That really isn't an 'unless', it's a 'when'.
Yes, the common case would be a machine like a laptop which has both
an ethernet and an 802.11 wireless connectivity. If the 802.11
basestation is configured as a bridge to the wired LAN, these two
interfaces are really on the same link.
This implies that any multihomed system must ensure that if it
configures more than one interface for LLA's, the addresses it uses
are unique.
> We also need to be able to handle the case where they are on
> physically different links; but the host is acting as a bridge
> between them to make one logical link sharing a single LLA subnet.
> (We don't need to explicitly handle the case where the bridging is
> being handled externally because that should be virtually
> indistinguishable from a single physical link.)
Yes, it is reasonable for a device which can bridge two different
physical networks to share a single LLA subnet, but the LLA should be
assigned to the virtual bridged interface, not to the underlying
physical interfaces.
> I think this all means that for a multi-homed host, we should not
> automatically add a route for the 169.254/16 network. Instead, we
> should just add specific /32s as discovered; and use ARP when we
> need to find a new 169.254.x.y -> MAC translation.
MacOS X has the notion of interface priorities; from RFC-3927:
Mac OS X ensures that the connected interface with the highest
priority is associated with the Link-Local subnet. Packets
addressed
to a Link-Local address are never sent to the default gateway, if
one
is present. Link-local addresses are always resolved on the local
segment.
Mac OS X implements media sense where the hardware and driver
support
it. When the network media indicates that it has been connected,
the
autoconfiguration process begins again, and attempts to re-use the
previously assigned Link-Local address. When the network media
indicates that it has been disconnected, the system waits four
seconds before de-configuring the Link-Local address and subnet. If
the connection is restored before that time, the autoconfiguration
process begins again. If the connection is not restored before that
time, the system chooses another interface to autoconfigure.
> There still remains the possibility of multiple distinct hosts
> having the same LLA IP address on separate local links; each
> attached to a separate interface. In practice that situation should
> be sufficiently rare that we can afford to ignore it until someone
> comes up with some clever way to handle it. (Or we all move to IPv6
> and it becomes moot.)
See section 4 of RFC-3927.
--
-Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22D92E8D-DE18-4883-8E77-5567AF63DFE0>