Erik Nordmark writes: > 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,
This is one of the very rare cases where NATs are actually helpful. Due to widespread use of them, applications that record the address and try to use it for a reverse connection are already pretty much broken. > 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. True, but I don't think it's that dire in practice. The number of UDP applications that matter much is relatively limited, and if we (as part of making LLA "work" on Solaris) were to enhance our DNS server implementation so that it did the right ancillary data magic to preserve the interface, that'd go a long way to making such a thing viable. For what it's worth, similar magic is needed to train UDP applications in proper source address selection -- something they generally don't do well (or at all) today. > 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. I mostly agree. I think that as a long-term solution for transient clients, it's a brutal hack that will likely have unexpected (and probably unpredictable) rough spots. DHCP with address pooling is the right answer. However, for those cases where DHCP fails, I think it may still hold some value, at least as a way of ensuring that network devices are always manageable remotely, no matter what happens. I suspect the only question is whether we care enough about that usage case to support it, and for that I'm on the fence. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
