Mikael, On 2013-05-23, at 2:26 AM, Mikael Abrahamsson <swm...@swm.pp.se> wrote: > On Thu, 23 May 2013, Michael Sweet wrote: > >> Brian, >> >> What you're apparently missing is that the client is using the zoneid to >> choose a network interface to route packets to that link local address. If >> the server returns a uri in its response that uses the same link local >> address but without the client's zoneid, then the client will be unable to >> use said uri because it won't know which interface to use. Yes the server >> doesn't care but the client depends on it (for link local anyways). > > How would the server know the clients zoneid? It derives this from the > initial request?
Yes, in the Host header. For example, the following illustrates a typical IPP request using the previously recommended IPvFuture format (which CUPS implements and uses): POST /ipp/print HTTP/1.1 Host: [v1.fe80::1234+en0]:631 Content-Type: application/ipp Transfer-Coding: chunked ... IPP request ... The printer then validates the Host header and responds with URIs containing the same Host value in any reported IPv6 link-local URIs. The key issue is one of context - the client *may* be able to query the interface used for a particular socket connection but it probably can't (easily) cache and map this information in the URIs that are embedded in the content returned by the printer, particularly when the client may have to process said content from a variety of sources - IPP is also supported over a USB transport, HTML can be read from disk, etc. Clients are usually unable to connect to a given IPv6 link local address without the zoneid information to tell them which network interface to use. And typically the only reason clients use an IPv6 link local address is because it was handed to them by a discovery protocol like WS-Discovery... Requiring the client to rewrite all URIs is a tremendous burden and is error-prone. Requiring the server to use the Host header is cheap in comparison. Having the server validate and use the Host value also helps interoperability since existing clients may not support the new IPv6addrz format - for example, CUPS doesn't support it since it validates URIs and Host values using the ABNF in RFC 3986/STD 66. The Host header mechanism has been standard practice outside the IETF for several years now. It is part of IPP Everywhere (Printer Working Group), Wi-Fi Direct Print Services (Wi-Fi Alliance), IPP USB (USB Implementers Forum), and AirPrint (Apple). It solves the problem of client-side routing of IPv6 link local addresses that are used in URIs embedded in content returned by printers and other embedded devices. _________________________________________________________ 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 --------------------------------------------------------------------