Zeroconfig and Multicast DNS

[Chuck Swiger]

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: rfc at stuartcheshire.org
[ ... ]

>> 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