I mentioned "in the old days" because most clients I'm aware of, would try multiple addresses -- however, with the introduction of IPv6 and the fact that there will USUALLY be multiple IP addresses (CGA, link-local, tunnels, etc.). Clients should be following the latest versions of the address-selection algorithms (both source and destination) discussed in RFCs 3484, 5221, and others. These algorithms can be bypassed or otherwise affected by local policy files as well, which can complicate developer/operational assumptions.
Randy
On May 14, 2012, at 10:42 AM, Michael Sweet wrote:
> Randy,
>> On May 11, 2012, at 10:47 AM, Randy Turner wrote:
>>>> Yes, I understand your consumer dynamic scenario…In the "old" days, admins would configure a service name (like "printer,apple.com") to return multiple IP addresses, and socket API recommendations say you're supposed to walk the list of returned addresses until you successfully connect to one. So there would be a slight delay if you were home and wanted to access imac27.mike.members.icloud.com (unless the home IP address was the first address returned).
>> That's the issue - the DNS server supporting imac27.mike.members.icloud.com doesn't report what the *local* address is since it is usually in the private space (192.168. or 10.) which isn't something you want to publish (since it is likely you'd resolve and connect to that address but be talking to the wrong machine...)
>> We have specific ways of dealing with this for Bonjour-registered services - resolve the service instance name using mDNS (.local) first, then start a resolve on the BTMM domain 1 second later - so that we prefer local services over BTMM, but the same trick can't be safely used for hostnames in general and doesn't address things beyond the simple local/cloud naming issues.
>>> It gets even more complicated if your DNS setup is dual-stack in which case you're returning both A and AAAA records, in which case local resolver policy may force a delay if clients try to resolve IPv6 before IPv4 or vice-versa.
>> IPv4/IPv6 is only one dimension. Even your traditional multiple-addresses-per-hostname configuration suffers from the "what address should I use" problem. Some implementations try one address at a time in the order they are returned, others try *all* of the addresses simultaneously (parallel threads) which is just nasty IMHO and breaks a lot of load balancers.
>> By having the Printer return the host and port that the Client provided we eliminate the guessing by the Client and allow it to do some simple caching (i.e. this is the address that works for "foo.example.com", at least until my network environment changes) so that things work well.
>> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20120514/a462bd1d/attachment-0001.html>