Zeroconfig and Multicast DNS

[Chuck Swiger]

On Aug 24, 2006, at 6:29 PM, Pat Lashley wrote:
>> 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.
>
> But OS X also only supports Zeroconf on one interface at a time. We  
> Can Do Better.

I believe Apple creates /32 host-specific routes for Zeroconf traffic  
on the other interfaces, if seen.  That may actually just be the  
normal ARP-handling code in operation rather than Zeroconf, per se,  
although Apple's implementation of ARP is Zeroconf-compliant in terms  
of timing, setting "sender IP address" (aka arphdr->ar_spa) field to  
all zeroes to avoid polluting other systems' ARP caches, announcing &  
defending LLA IP reservations, etc.

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.

>>> 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.
>
> No, that covers merging two previously disjoint networks; I don't  
> think that it is intended to handle the case of a multi-homed host  
> that is connected to both of them while keeping them separate.

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.

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.

-- 
-Chuck

#!/usr/bin/env python
"""This program computes the probability that two (or more) hosts  
will have an
address collision.  Set ip_range to 365 and this computes the  
'birthday paradox'."""

ip_range = 65024
#ip_range = 365
prob = 0.0
number_of_hosts = 1

def unique(n):
     """Given n distinct hosts with randomly distributed addresses  
within the ip_range,
     return the probability that all will be assigned a unique  
address."""
     if n == 1:
         return 1.0
     else:
         return unique(n - 1) * (ip_range - (n - 1)) / ip_range

while (prob < .5):
     prob = 1.0 - unique(number_of_hosts)
     print "Number of hosts: %d" % number_of_hosts
     print "Probability of IP collision: %0.4f" % prob
     number_of_hosts += 1