----- Original Message -----
> From: Ole Troan <otr...@employees.org>
> To: Michael Sweet <msw...@apple.com>
> Cc: Ray Hunter <v6...@globis.net>; "ipv6@ietf.org" <ipv6@ietf.org>; t.petch 
> <ie...@btconnect.com>; Christian Huitema <huit...@microsoft.com>
> Sent: Thursday, 30 May 2013 5:40 AM
> Subject: Re: [Technical Errata Reported] RFC6874 (3630)
> 
> Michael,
> 
> let me try a restart.
> 
> you need to use link-local addresses for the HTTP connection between a client 
> and a printer.
> 
> a link-local address has link-local scope. it is ambiguous outside of the 
> given 
> link (zone).
> see RFC4007.
> 
> an application using link-local addresses must be bound to the interface in 
> the 
> chosen link-local zone.
> 

I too have been struggling to understand the problem. If an application has 
chosen to use a link-local destination address as a destination for a query, it 
has also chosen to use and specify an outbound interface, and needs to remember 
this interface information if it is expecting a response. All responses to this 
query will arrive on the same interface the query it was sent on. It is 
impossible for them not to, because of the link scope of link-local addresses. 
If it receives responses on a different interface, even if they look like they 
match the original query (e.g., via an application level transaction id), they 
are invalid.


> now the question becomes, what do you do with the embedded URIs containing 
> link-local addresses?
> the referral clearly has no value outside of the given link-local zone.
> 
> could you not infer the link-local zone of the referral from the transport 
> session?
> given a link-local transport connection using a link-local zone, would it 
> ever 
> make
> sense that the referrals using link-locals would belong to a different zone?
> 
> if not, then the client can just ensure to use the same zone for referrals 
> that 
> it does the transport
> it received the HTML over.
> 
> cheers,
> Ole
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to