John Beck wrote:
Yes, or more generally any two machines that want to talk to each other
without any Network for doing so beyond a direct link. And, as we just
discussed in your office, since the Network is getting to be everywhere
these days (even on airplanes), such circumstances are getting rarer. Thus
the question is whether they are still sufficiently common to be worth the
trouble of adding this feature, or if this solution is some years too late
for its intended purpose. My sense is that it is still worthwhile, but I
don't have enough data to prove it. Does anyone else have data or even a
sense of whether Erik's thesis or mine is more accurate?
It might not yet be uncommon, but even if it isn't, the failure
scenarios due to multihoming trouble me.
Suspect disbelief and let's say that all TCP implementations learn how
to handle IPv4 LLA the same way as IPv6 LLA (record the interface index
so that the SYN|ACK and the rest of the connection use the same
interface on which the SYN arrived).
Further assume that all multihomed nodes on the planet that don't do
this magically disappear.
Now we have the case that a host which supports LLA arrives on a network
segment and tries to communicate. Assume there isn't a DHCP server on
that link.
What happens?
The host can find services using Bonjour. Suppose it discovers a useful
service which happens to run on a multihomed node.
If this service is just a vanilla TCP service, then things will work per
the above "suspend disbelief". But if the TCP service records the
IP+port and later tries to initiate a connection in the reverse
direction, or is some UDP application, then it likely to fail since we
didn't get all the applications in the universe updated to track the
linkid/scope_id.
The problem is that we can't even predict what types of things will
fail. A regular DNS lookup (which uses UDP) could fail, but if the LLA
client was smart enough to use TCP for DNS it would work!
So while IPv4 LLA might help in cases where there is no DHCP server, it
couldn't actually provide a reliable service.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
