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.
As ours should be. The only part of that that should be affected by whether or not LLA is enabled is the announcing and defending portion.
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. 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.
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. I suspect that the decision was made fairly early to only support it on one interface at a time. That certainly made it easier to concentrate on getting the more common one-interface scenario to work correctly. But they, and others working on Zeroconf, have pretty well identified the one-interface issues and come up with solutions; so we don't have to duplicate that research. Which means that we're free to look at the implications for multi-homed machines.
I would agree that our first implementation should focus on the single-interface situation; but we should keep the multi-homed machines in mind while designing it. It's OK if we say "you can enable it on more than one interface; but we're not going to guarantee that you won't run into problems."
>> 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.
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.)
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.
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.
I think that you;ll find that the minimum number to produce a 50% probability will require that both networks have the same number of hosts (or differ by only one); and that as the populations become unbalanced, the total required rises fairly rapidly. (E.g., if N is 1, M must be 32512 for a total of 32513.)
-Pat _______________________________________________
freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
