On Aug 25, 2006, at 12:24 PM, Pat Lashley wrote:
I would be entirely happy if FreeBSD could do better than MacOS
with regard to
this matter, but my observation suggests that the dudes working
on this at
Apple have a working implementation which is becoming widely used
in userland
applications for things like printer discovery on unconfigured
LANs, chat,
music sharing on the LAN (via iTunes), and for which the
potential problems
involved with things like multihomed machines are somewhat well
understood.
Apple's primary consumer base for Zeroconf systems doesn't normally
have to deal with multi-homed systems; so it probably isn't much of
a priority for them.
Um, Pat...?
All of the laptops Apple sells have ethernet & 802.11 wireless built
in and thus are multihomed from day one; all of the desktop & Mac
mini systems being sold are ethernet & wireless ready, and I gather
that many systems are purchased with the wireless option. Also note
that Apple is also shipping pretty much everything they sell with
Firewire, which only Sony seems to do on the PC side.
They also need to maintain a higher level of easy configurability
by non-technical users. FreeBSD's target user base leans towards
the more technical and the more server-oriented.
Absolutely. LLA & mDNS are targetted for ad-hoc networks which are
mostly or entirely unconfigured; FreeBSD's target user base tends to
do things like setup servers with fixed IPs and configure networks
via DHCP, setting up DNS zones, and so forth.
MacOS users have a much greater demand and use for LLA & mDNS than
FreeBSD users do; after all, Apple has userland apps which take
advantage of this functionality now.
I don't know any of the people working on Zeroconf at Apple; and
have no idea how well they have investigated the issues surrounding
multi-homed machines.
Read the first few lines of http://www.faqs.org/rfcs/rfc3927.html, or
look at the end:
Authors' Addresses
Stuart Cheshire
Apple Computer, Inc.
1 Infinite Loop
Cupertino
California 95014, USA
Phone: +1 408 974 3207
EMail: [EMAIL PROTECTED]
[ ... ]
That section covers the merging of two previously disjoint
networks, agreed;
for the case of connecting a multihomed host which is bridging
them, this
section is entirely relevant. Otherwise, LLA only deals with one
collision
domain (or link, etc) by definition, and one requirement which is
relevant to
a multihomed host is that it must ensure that the system assigns
a different
LLA to each interface.
Yes, as you say, it is relevant if the host is bridging, but not if
it is treating them as separate subnets. Which requires separate
LLA negotiations; but I don't see where section 4 requires them to
have separate IP addresses. (It's probably a good idea; but it
doesn't seem to be required by section 4.)
It's not required in section 4; see section 3, particularly 3.4.
Multi-homed hosts are covered in section 3. Which is basically a
discussion of some of the problems that are likely to be
encountered; without mandating (or forbidding) any particular
solution.
Section 3.4 does require separate LL Ip addresses IF the interfaces
are on the same link. But, as they point out, the easiest method of
avoiding auto-immune response is to run the algorithm separately
for each interface. In which case no special action need be taken
to determine whether they are on the same link, or to avoid
requesting the same address; the normal LLA negotiation will ensure
that one of them wins and the other picks another address.
This draft RFC doesn't actually specify that a system which has
multiple interfaces participating in LLA to each be assigned unique
IPs -- presumably because it recommends that hosts only use one
interface for LLA, for example see section 2.6.1:
A multi-homed host needs to select an outgoing interface whether or
not the destination is an IPv4 Link-Local address. Details of that
process are beyond the scope of this specification. After selecting
an interface, the multi-homed host should send packets involving
IPv4
Link-Local addresses as specified in this document, as if the
selected interface were the host's only interface. See Section 3
for
further discussion of multi-homed hosts.
The probability that you will have the same LLA appear on two
distinct subnets
is a variant of the "birthday paradox"; there's a 10% chance of a
collision
with ~120 hosts, and a 50% chance of a collision with 300,
assuming the code
copied below is right.
Not exactly. I think that that computes the probability that a
newly attached host will pick an initial IP address that is already
in use. To apply it to a pair of networks, you need to deal with
how many hosts are on each network and the fact that within each
network, the IPs are already guaranteed to be unique.
So, given two networks, one with N hosts, the other with M; for the
first host in N, the chance of collision is M / 65024; for the
second it is M / 65023; etc. (Each host in N reduces the available
address space from which the other N-hosts may be chosen; it does
not increase the number of hosts that they must be compared
against.) The total probability is the sum of the probabilities
for each of the N hosts.
Hmm, I think you've got a point-- certainly, having two networks
starting with hosts guaranteed unique IPs reduces the chances of
collisions when they merge, but you might very well be coalescing
many disjoint networks rather than just two-- consider bringing up a
new wireless basestation which links multiple smaller clouds of
wireless clients, for example.
Regardless of the actual probability, dealing with IP collisions when
using LLAs is a requirement, not something which can be passed off to
be solved later.
--
-Chuck
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
