Zeroconfig and Multicast DNS

[Pat Lashley]

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

Yes, I know, there are 4 Macs in my household. (And an equal number of FreeBSD 
machines.) I've been using the MBP to send these emails. And, for the record, 
neither our MacMini nor the PowerMac G4 came with WiFi installed.  Apple may 
have made WiFi standard for new systems; but a lot of their old ones are still 
Ethernet-only.

They may all come with both 10/100(/1000)base-T and WiFi now; but few of them 
actually -use- both interfaces at once; and even fewer on a single local link. 
So I stand by my claim that their primary customer base doesn't normally deal 
with multi-homing; especially not in a Zeroconf context.


And yes, I do like the standard FireWire; but I don't see how it relates to the 
discussion at hand unless you want to talk about using it as a network link. 
Something that is easy enough to do; but that I suspect happens rarely in 
situations where more than two hosts are involved.


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

But that doesn't mean that we necessarily -want- to have to deal with all of 
that.

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

So do FreeBSD users who install KDE and/or GNOME. Admittedly, not as many, nor 
as compelling. Yet.

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

That only applies if both interfaces are on the same link.

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

But that same discussion in Section 3 appears to contradict that 'pick one' 
requirement. I also note that Section 2.6.1 says '...should send packets...', 
not '...SHOULD send packets...'; which implies that it isn't even a strong 
recommendation.

I believe the intent of section 2.6.1 is to indicate that all of the LLA 
communications relevant to a given interface needs to go through that interface 
rather than applying the normal routing rules that were designed for more 
static and unique IP addresses.

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

But in that case you are more likely to be merging those local links into a 
single larger one. I'm not saying that situation will never occur; just that I 
believe it will be much less common.

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

Actually, I just thought of a simple (but not necessarily pretty) way to do it. 
The multi-homed host could perform NAT on the incoming packets in the 
169.254/16 network, using separate NAT pools on each interface.  The 
applications, and the bulk of the system code would only see the translated 
addresses, which would be routed to the right interfaces and then translated 
back to the correct LLA address.

You could translate 169.254.x.y into 127.i.x.y, where 'i' identifies the 
interface; then you wouldn't even need to keep NAT tables. (To maintain RFC 
compliance with respect to the 127/8 network, you'd need to implement it using 
(additional) loopback interfaces; but that's a quibble.) And you'd need to 
ensure that 'i' didn't put you into a range that's already in use by some other 
RFC or de-facto standard. (So it shouldn't be 0, or 127.)

Of course, that only handles the basic address collision issue.  Service 
discovery in that case is still a mess.  (The whole concept of handling service 
discovery across a NAT boundary is making me queasy.)



-Pat
P.S.        No, that proposal is not entirely serious...