Ray, On May 29, 2013, at 3:10 PM, Ray Hunter <v6...@globis.net> wrote: >> Michael Sweet <mailto:msw...@apple.com> >> 29 May 2013 20:13 >> Michael, >> >> >> One important point here: we don't send IPv6 link local addresses in >> this case, we send the .local hostname that the printer is using. This >> avoids the whole issue of IPv6 link-local addresses in URIs, we just >> have to deal with changing printer hostnames (due to name collisions) >> and the normal issues of changing networks on the client - home Wi-Fi >> vs. work network, etc. >> > .local is also strongly scoped to a link. So how does a using a .local > name help compared to using an IPv6 link local literal in a URI?
For one, it doesn't have an RFC telling implementers to not put the .local name in the Host: header or in URIs... :) But in all seriousness, clients are able to lookup the .local name using mDNS (through the system networking libraries), which gives them the proper IPv6 link-local address complete with the zoneid. The same is not generally true of IPv6 link-local addresses - there is no standard network API for getting the interface name/zoneid for a given link-local address, and things like getaddrinfo will not accept an IPv6 link-local address without its zoneid. > In the case of receiving a .local URI, don't you then have to run name > resolution using mDNS on all possible interfaces to work out which > outgoing interface to use? Absolutely, but that resolution is provided through a stable, well-known interface that is also used for looking up regular DNS names. An application doesn't need to know about the details of the lookup, it just does the host name lookup and the right things happen. > Point being that if a client can learn the outgoing interface because of > an incoming service advertisement from the printer, or failing that you > run multicast name discovery on all interfaces to discover which one has > the printer connected to it, why then in the case of an IPv6 literal > link local can't the client first look at the local Neighbor Discovery > cache for the literal IPv6 link local of the server to discover the > outgoing interface, or if that is absent attempt connecting to port 80 > via all interfaces and cache which one works (attempting to use fixed > links before wireless before 3gpp)? This approach makes the assumption that the printer supports ND and the OS allows applications to query the ND cache or provides a way to "resolve" (for lack of a better word) which interface should be used for a link-local address. From my own testing, I'm not certain that all IPv6 printers support ND - only one of my three IPv6 printers shows up in my system's ND cache - and no OS does interface lookup (or enumeration) when given an IPv6 link-local address, you have to specify it. I make no claim that my approach is perfect/ideal, merely that it works with current IPv6 implementations and has been deployed in CUPS and IPP printers since 2005 (just with the IPvFuture format). If the consensus is to *not* include the zoneid in outgoing URIs, I'd still like to update RFC 6874 to provide some more examples, a history of what has been done before, and conformance requirements to ensure that everything needed to transparently support link-local addresses is in place. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
