Zeroconfig and Multicast DNS

[Pat Lashley]

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

But OS X also only supports Zeroconf on one interface at a time. We Can Do 
Better.

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



-Pat