Subject: [Technical Errata Reported] RFC6874 (3630)

From: RFC Errata System <[email-masked]>
Date: Wed, 22 May 2013 20:51:51 -0700 (PDT)

The following errata report has been submitted for RFC6874,
"Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6874&eid=3630

--------------------------------------
Type: Technical
Reported by: Michael Sweet <[email-masked]>

Section: 3

Original Text
-------------
   Such bare "%" signs are for user interface convenience, and need to
   be turned into properly encoded characters (where "%25" encodes "%")
   before the URI is used in any protocol or HTML document.  However,
   URIs including a ZoneID have no meaning outside the originating node.
   It would therefore be highly desirable for a browser to remove the
   ZoneID from a URI before including that URI in an HTTP request.

Corrected Text
--------------
   Such bare "%" signs are for user interface convenience, and need to
   be turned into properly encoded characters (where "%25" encodes "%")
   before the URI is used in any protocol or HTML document.  HTTP Clients
   MUST include a ZoneID in any URIs provided in an HTTP request since
   HTTP Servers will need it when generating URIs, otherwise the IPv6
   address will not be routable.

Notes
-----
The original advice ignores a very real issue: HTTP Servers that generate URIs from the client's Host: need to include the Client's zoneid in order for the link local address to be usable/routable.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6874 (draft-ietf-6man-uri-zoneid-06)
--------------------------------------
Title               : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
Publication Date    : February 2013
Author(s)           : B. Carpenter, S. Cheshire, R. Hinden
Category            : PROPOSED STANDARD
Source              : IPv6 Maintenance
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 May 2013 17:26:52 +1200

As far as I can tell this is completely incorrect and the RFC is
completely correct. It's so wrong that I can't even see how to
explain it. By definition, a ZoneID has no meaning outside the
host; its only effect is to direct the packet to the desired
interface on that host. It has absolutely nothing to do
with routing on the network.

Regards
   Brian Carpenter

---

From: Michael Sweet <[email-masked]>
Date: Thu, 23 May 2013 02:10:05 -0400

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).

This issue is specifically why we (the Printer Working Group) require IPP Clients to include the zoneid in the HTTP Host header and require IPP Servers to use the Host value in any generated URIs.

Sent from my iPad

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 May 2013 08:26:29 +0200 (CEST)

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?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Thu, 23 May 2013 06:47:14 +0000

Michael, you are asking that the consensus of the WG be reversed. The errata process is not the way to handle this. You have to go through the motions: write a draft, submit it, get consensus...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Wednesday, May 22, 2013 11:10 PM
To: Brian E Carpenter
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; RFC Errata System
Subject: Re: [Technical Errata Reported] RFC6874 (3630)

Brian,

Sent from my iPad

On 2013-05-23, at 1:26 AM, Brian E Carpenter <[email-masked]> wrote:

> completely correct. It's so wrong that I can't even see how to explain 
> it. By definition, a ZoneID has no meaning outside the host; its only 
> effect is to direct the packet to the desired interface on that host. 
> It has absolutely nothing to do with routing on the network.
> 
> Regards
>   Brian Carpenter
> 
> 
>> use "Reply All" to discuss whether it should be verified or rejected. 
>> When a decision is reached, the verifying party (IESG) can log in to 
>> change the status and edit the report, if necessary.
>> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 May 2013 13:42:13 +0000

I happen to agree that a change like this would be a good change, but I also agree that it needs to be done as a consensus document, not as an erratum.   This is true not only for process reasons, but because I think the change as proposed was too broad.   Is there a working group alive where this could get done?

---

From: Michael Sweet <[email-masked]>
Date: Thu, 23 May 2013 09:39:06 -0400

Mikael,

On 2013-05-23, at 2:26 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 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

---

From: Brian Haberman <[email-masked]>
Date: Thu, 23 May 2013 10:04:40 -0400

> I happen to agree that a change like this would be a good change, but I also agree that it needs to be done as a consensus document, not as an erratum.   This is true not only for process reasons,…

6MAN.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 23 May 2013 10:43:20 -0400

Michael,
      I rejected the errata since they were both changing the consensus 
of a WG.  That level of change is not how the errata system is to be 
used.  Your approach of writing a new draft proposing these changes is 
the correct approach to changing that consensus.

Regards,
Brian

On 5/23/13 10:25 AM, Michael Sweet wrote:
> Christian,
>
> I'm happy to write up a new draft proposing my changes and go through that process. I'm not happy that my errata have been summarily rejected in less than 24 hours with no time for review.
>
> Consider: hundreds of millions of printers, computers, and mobile devices have been certified and shipped with IPv6 link local support using the IPvFuture format over the last 8 years.  It took those 8 years for the IETF to agree on a new format with serious compatibility and interoperability issues with the base IETF standard (STD 66 aka RFC 3986), and my errata against the published RFC have been rejected after less than 24 hours of discussion.
>
> How do we notify users of RFC 6874 that there are proposed changes, if not in pending errata?
>
> How long will it take to get a new draft approved that fixes the problems in RFC 6874? I certainly hope the answer is not 8 years...
>
>
> On 2013-05-23, at 2:47 AM, Christian Huitema <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 May 2013 15:23:46 +0000

> 6MAN.

Really?   I would have assumed that this would be an http document, but if it can be done in 6man, that would be cool.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 23 May 2013 11:26:04 -0400

> Really?   I would have assumed that this would be an http document, but if it can be done in 6man, that would be cool.

RFC 6874 was published by 6MAN.  There was input from the Apps area as 
well (where the HTTPbis WG resides).

---

From: Ole Troan <[email-masked]>
Date: Thu, 23 May 2013 17:42:14 +0200

>> I happen to agree that a change like this would be a good change, but I also agree that it needs to be done as a consensus document, not as an erratum.   This is true not only for process reasons,…

I'm fine with 6man owning given that we produced RFC6874.
if the intention here is to use zoneids in referrals (or even link-locals) then there has to be involvement from the apps area.

cheers,
Ole

---

From: Brian Haberman <[email-masked]>
Date: Thu, 23 May 2013 11:47:16 -0400

> if the intention here is to use zoneids in referrals (or even link-locals) then there has to be involvement from the apps area.

If the work shows up in 6MAN, we will solicit advice/review from Apps 
and Security.  The ADs from those areas have already agreed to help.

Regards,
Brian

---

From: Michael Sweet <[email-masked]>
Date: Thu, 23 May 2013 10:25:37 -0400

Christian,

---

From: t.petch <[email-masked]>
Date: Fri, 24 May 2013 09:00:15 +0100

Michael

I would have been happy to see your erratum rejected in 24 minutes,
because it is an abuse of process.  It's a bit like submitting an I-D in
Swahili, nothing wrong with Swahili but quite wrong for the context.

Erratum are for errors, where the text did not mean what the WG had
agreed on, where the grammar is wrong, not English, where the text is
being misinterpreted.

Changes to the function require an I-D.  Having had that pointed out to
you, and you might well have not realised the meaning of an erratum in
the context of the IETF, other SDO may work differently, yet you persist
in submitting errata; I hope that future ones are rejected as quickly.

When I-Ds are urgently required, then they can become RFC in six months,
but that only happens when the correct processes are followed.

Tom Petch

----- Original Message -----
From: "Michael Sweet" <[email-masked]>
To: "Christian Huitema" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; "RFC Errata System" <[email-masked]>
 Thursday, May 23, 2013 3:25 PM

> Christian,
>
> I'm happy to write up a new draft proposing my changes and go through
that process. I'm not happy that my errata have been summarily rejected
in less than 24 hours with no time for review.
>
> Consider: hundreds of millions of printers, computers, and mobile
devices have been certified and shipped with IPv6 link local support
using the IPvFuture format over the last 8 years.  It took those 8 years
for the IETF to agree on a new format with serious compatibility and
interoperability issues with the base IETF standard (STD 66 aka RFC
3986), and my errata against the published RFC have been rejected after
less than 24 hours of discussion.
> How long will it take to get a new draft approved that fixes the
problems in RFC 6874? I certainly hope the answer is not 8 years...
> > Michael, you are asking that the consensus of the WG be reversed.
The errata process is not the way to handle this. You have to go through
the motions: write a draft, submit it, get consensus...
> > 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).
> >
> > This issue is specifically why we (the Printer Working Group)
require IPP Clients to include the zoneid in the HTTP Host header and
require IPP Servers to use the Host value in any generated URIs.
> >> completely correct. It's so wrong that I can't even see how to
explain
> >>> The original advice ignores a very real issue: HTTP Servers that
generate URIs from the client's Host: need to include the Client's
zoneid in order for the link local address to be usable/routable.
> >>> Instructions:
rejected.
> >>> Title               : Representing IPv6 Zone Identifiers in
Address Literals and Uniform Resource Identifiers

---

From: Michael Sweet <[email-masked]>
Date: Fri, 24 May 2013 08:10:36 -0400

Tom,

> in submitting errata; I hope that future ones are rejected as quickly.

First, I *have* submitted errata before, both technical and editorial, for basically all of the IPP specifications, and most have been accepted as posted.  In some cases the technical errata clearly change the meaning of the original text because the original text was plainly wrong.  This is ALLOWED by the currently published process on the RFC Editor's page (which also notes it is a "slippery slope"...):

    http://www.rfc-editor.org/draft-rfc-editor-errata-process-02.txt

I don't say this as an excuse, merely as explanation, and I don't know whether IPP's special status (PWG maintained) or my status (IPP Designated Expert) within the IETF has anything to do with the latitude that has been granted WRT my errata.

As for discussing errata in the relevant IETF WG prior to submission, I was not aware of any formal process in this regards and apologize if I have upset you by starting with the errata reports.  The process described in the above link implies that reporters start on the web portal to initiate such a discussion with the relevant working group, and the standards development process documents that are readily accessible from the IETF web page say nothing about errata or the errata process:

    http://www.ietf.org/about/process-docs.html
    http://tools.ietf.org/html/rfc2026

I can also report that the RFC pages do not provide links to the relevant working group or mailing lists, and that the mailing list links on the main IETF page all take you to the message archives and not to the list subscription page (which I had to search for with Google...)

So again I apologize if I did not follow the process, but honestly I thought I *was*.

(For reference, the PWG process for errata has direct reporting to the relevant workgroup, and that workgroup is identified in every document we produce...)

> but that only happens when the correct processes are followed.

I'm glad to hear that is possible.  Aside from IPP Everywhere, the in-review Wi-Fi Direct Services Print specification is also affected and in fact depends on IPv6 Link Local addressing.

---

From: t.petch <[email-masked]>
Date: Fri, 24 May 2013 16:31:24 +0100

---- Original Message -----
From: "Michael Sweet" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Christian Huitema" <[email-masked]>; <[email-masked]>
Sent: Friday, May 24, 2013 1:10 PM
> First, I *have* submitted errata before, both technical and editorial,
for basically all of the IPP specifications, and most have been accepted
as posted.  In some cases the technical errata clearly change the
meaning of the original text because the original text was plainly
wrong.  This is ALLOWED by the currently published process on the RFC
Editor's page (which also notes it is a "slippery slope"...):
> I don't say this as an excuse, merely as explanation, and I don't know
whether IPP's special status (PWG maintained) or my status (IPP
Designated Expert) within the IETF has anything to do with the latitude
that has been granted WRT my errata.
>
> As for discussing errata in the relevant IETF WG prior to submission,
I was not aware of any formal process in this regards and apologize if I
have upset you by starting with the errata reports.  The process
described in the above link implies that reporters start on the web
portal to initiate such a discussion with the relevant working group,
and the standards development process documents that are readily
accessible from the IETF web page say nothing about errata or the errata
process:
> I can also report that the RFC pages do not provide links to the
relevant working group or mailing lists, and that the mailing list links
on the main IETF page all take you to the message archives and not to
the list subscription page (which I had to search for with Google...)

Michael

No problem; my defensiveness is because I see the Area Director as the
critical resource in the IETF, and raising an erratum tweaks their tail
in a way that an e-mail to a WG list does not.  Some with an issue to
raise find and start with the main IETF list, where do I go with ...,
and someone will always point them to the right area or WG.

There is nothing wrong with raising an erratum as a first step when it
falls within the IETF's use thereof; it is fine to raise an error if it
really is an error.  In this case, you are referencing an RFC which,
like most such, was extensively discussed on a number of lists, so a lot
of people put a lot of effort into producing what you now see, so to say
it is wrong, well, that may not be the best way to get support for
amending it.

However, if you start with the RFC, by looking at the RFC-Editor pages,
then the summary screen for RFC6874 tells you that the source is 6man,
and clicking on that anchor takes you to a wiki for a Working Group,
6man in fact, which has a list of current work, archives and a charter,
which contains details of how to join the mailing list for 6man.

I did not know this until five minutes ago, but I expected that there
would be a way to make the connection and indeed, there is.

Could it be clearer?  Can't think of anything offhand.

Meanwhile, I don't understand the errata:-(  yes I get the gist, but do
not see the protocol sequence that causes you grief.  Perhaps spelling
it out in a longer e-mail to the 6man list would be a good step forward.
At the back of my mind is the inkling that this may fly in the face of
the IPv6 architecture, that ZoneIDs were carefully defined to have a
limited scope and that what you want to do is in violation of that.
Time will tell.

Tom Petch

PS I have always loved the term RFC; this is not a standard that the
IETF has produced, carved in tablets of stone, but the best that the
IETF has managed to produce so far and would LOVE to hear from anyone
with a better idea, it is a Request For Comments:-)

> (For reference, the PWG process for errata has direct reporting to the
relevant workgroup, and that workgroup is identified in every document
we produce...)
> I'm glad to hear that is possible.  Aside from IPP Everywhere, the
in-review Wi-Fi Direct Services Print specification is also affected and
in fact depends on IPv6 Link Local addressing.
> >> How do we notify users of RFC 6874 that there are proposed changes,
if
> > not in pending errata?
> >> On 2013-05-23, at 2:47 AM, Christian Huitema
<[email-masked]>
> > wrote:
> >>> From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of Michael Sweet
> >>>>> When a decision is reached, the verifying party (IESG) can log
in
> > to
> >>> Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6

---

From: Christian Huitema <[email-masked]>
Date: Fri, 24 May 2013 17:45:23 +0000

Can we move from the process discussion to the technical discussion?

Michael raised an interesting issue, and we have to analyze it. The consensus of the working group so far is that interface identifiers are private to the host, that any leakage outside the host should be prevented, and that a way to prevent that leakage is to ask proxies to erase them whenever they have an opportunity. Michael points that some servers take an opposite approach, want to record the interface from which the host called them, and want to ensure that further calls in the same session use exactly the same interface. That seems that a fairly legitimate debate, and I can see two alternatives -- one would be to reaffirm the old guidance and provides alternative to ensure session continuity, and the other would be to reverse the guidance and accept that the layer violation performed by servers is just fine.

-- Christian Huitema

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 24 May 2013 13:58:26 -0400

Michael,

Can I echo what Tom and Christian have said - that you join the 6man working
group and start by clearly and concisely stating the problem that this RFC
poses
for your application and how you suggest we fix it?

When you speak of "hundreds of millions of printers..." it gives the
impression that
the RFC makes illegal something that printers have been doing for some
time.  If
so, can you also provide relevant references to the deployed functionality
that you
believe this RFC makes illegal?

-K-

On Fri, May 24, 2013 at 1:45 PM, Christian Huitema <[email-masked]>wrote:

> Michael raised an interesting issue, and we have to analyze it. The
> consensus of the working group so far is that interface identifiers are
> private to the host, that any leakage outside the host should be prevented,
> and that a way to prevent that leakage is to ask proxies to erase them
> whenever they have an opportunity. Michael points that some servers take an
> opposite approach, want to record the interface from which the host called
> them, and want to ensure that further calls in the same session use exactly
> the same interface. That seems that a fairly legitimate debate, and I can
> see two alternatives -- one would be to reaffirm the old guidance and
> provides alternative to ensure session continuity, and the other would be
> to reverse the guidance and accept that the layer violation performed by
> servers is just fine.
>
> -- Christian Huitema
>
>
>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 24 May 2013 14:27:56 -0400

Christian,

> Michael raised an interesting issue, and we have to analyze it. The consensus of the working group so far is that interface identifiers are private to the host, that any leakage outside the host sh…

(the following is printer-centric, but the same applies to network video cameras and other embedded network devices)

Some background: HTTP and IPP services in printers include absolute URIs in the content they return. For IPP this can be http/https URLs to the printer's web page, ICC profiles, and other resources, along with the ipp/ipps URIs that the printer supports. For HTTP the most common are https URLs for "secure" areas of the printer's web interface.  Because a printer is often known by multiple names and addresses ("printer.local.", "printer.example.com.", 192.168.0.100, fe80::1234, etc.), the implementation guidance (and in IPP Everywhere, this is a conformance requirement) is that the server use the HTTP Host header provided in the request in the host/address field of its responses, subject to the usual security considerations (SHOULD validate Host value, etc.)  This allows the client to use the name or address it can resolve/connect to and makes sure that the printer-generated absolute URIs lead back to same printer.

All of this falls apart with link-local addresses and RFC 6874.  Because the client is required to remove the zoneid from the outgoing request, the URIs it gets back from the server are no longer "reachable".

What I propose is that we change the wording to allow the zoneid in the Host header but not in the Request-URI.  HTTP proxies would be required to strip any zoneid information in the Host header.  HTTP servers would be required to ignore any zoneid information for purposes of address validation but include it for any absolute URIs to the server they generate.

Thoughts?

---

From: Christian Huitema <[email-masked]>
Date: Fri, 24 May 2013 18:41:33 +0000

> All of this falls apart with link-local addresses and RFC 6874.  Because the client is required to remove the zoneid from the outgoing request, the URIs it gets back from the server are no longer "…

Do you have this problem only with link local addresses, or with some other addresses as well?

-- Christian Huitema

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 24 May 2013 14:51:47 -0400

On Fri, May 24, 2013 at 2:27 PM, Michael Sweet <[email-masked]> wrote:

> (the following is printer-centric, but the same applies to network video
> cameras and other embedded network devices)
>
> Some background: HTTP and IPP services in printers include absolute URIs
> in the content they return. For IPP this can be http/https URLs to the
> printer's web page, ICC profiles, and other resources, along with the
> ipp/ipps URIs that the printer supports. For HTTP the most common are https
> URLs for "secure" areas of the printer's web interface.  Because a printer
> is often known by multiple names and addresses ("printer.local.", "
> printer.example.com.", 192.168.0.100, fe80::1234, etc.), the
> implementation guidance (and in IPP Everywhere, this is a conformance
> requirement) is that the server use the HTTP Host header provided in the
> request in the host/address field of its responses, subject to the usual
> security considerations (SHOULD validate Host value, etc.)  This allows the
> client to use the name or address it can resolve/connect to and makes sure
> that the printer-generated absolute URIs lead back to same printer.
>
> All of this falls apart with link-local addresses and RFC 6874.  Because
> the client is required to remove the zoneid from the outgoing request, the
> URIs it gets back from the server are no longer "reachable".
>
> Just so we're clear, I assume this does NOT work today with link-local
IPv6 addresses (because no print client yet
constructs a Host URI with link-local address and zoneID according to RFC
6874)?  And you're saying that RFC 6874
does not improve on the current situation?

-K-

What I propose is that we change the wording to allow the zoneid in the
> Host header but not in the Request-URI.  HTTP proxies would be required to
> strip any zoneid information in the Host header.  HTTP servers would be
> required to ignore any zoneid information for purposes of address
> validation but include it for any absolute URIs to the server they generate.
>
> Thoughts?
>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 24 May 2013 15:08:59 -0400

Christian,

On 2013-05-24, at 2:41 PM, Christian Huitema <[email-masked]> wrote:
> ...

As far as losing address information, so far it has only been an issue for link-local addresses.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 24 May 2013 15:27:48 -0400

Kerry,

On 2013-05-24, at 2:51 PM, Kerry Lynn <[email-masked]> wrote:
> ...
> Just so we're clear, I assume this does NOT work today with link-local IPv6 addresses (because no print client yet
> constructs a Host URI with link-local address and zoneID according to RFC 6874)?  And you're saying that RFC 6874

Correct on both counts.

What we have been advising printer vendors to do for the last 8 years is to support the IPvFuture address syntax, based on some discussions I had 8 years ago with one of the HTTP WG members at the time (and I apologize for not having more details, I lost my email archives recently and haven't been able to recover the files yet...) The "recommended" syntax at the time was:

    scheme://[v1.fe80::xxxx:...:xxxx+zoneid]:port/path

Support for that format got added to CUPS back in 2005, with most current printers supporting it as well.  By printer support, I mean they use the address as-is when returning URIs, they don't actually care about the zoneid...

I've been doing some testing locally and it seems that some OS libraries/frameworks work with the new address format, some with the old IPvFuture format, but so far none work with both.

Another data point: none of the web browsers I've tested allow link-local IPv6 addresses, period. Some don't understand the IPvFuture or RFC 6874 formats, some decide you meant to search for the IPv6 address (which produces some interesting search results...)

I still need to do more testing with printers to see what they do with RFC 6874 URIs once the print client (CUPS) is updated.  I suspect it will be a mixed result...

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 24 May 2013 15:44:50 -0400

On Fri, May 24, 2013 at 3:27 PM, Michael Sweet <[email-masked]> wrote:

> What we have been advising printer vendors to do for the last 8 years is
> to support the IPvFuture address syntax, based on some discussions I had 8
> years ago with one of the HTTP WG members at the time (and I apologize for
> not having more details, I lost my email archives recently and haven't been
> able to recover the files yet...) The "recommended" syntax at the time was:
>
> So it appears the current 'host' production used by print drivers is not
currently specified
by any RFC; why not just continue to use the same format irrespective of
RFC 6874?

> Support for that format got added to CUPS back in 2005, with most current
> printers supporting it as well.  By printer support, I mean they use the
> address as-is when returning URIs, they don't actually care about the
> zoneid...
>
> I've been doing some testing locally and it seems that some OS
> libraries/frameworks work with the new address format, some with the old
> IPvFuture format, but so far none work with both.
>
> Another data point: none of the web browsers I've tested allow link-local
> IPv6 addresses, period. Some don't understand the IPvFuture or RFC 6874
> formats, some decide you meant to search for the IPv6 address (which
> produces some interesting search results...)
>
> It's the browser case that RFC 6874 was primarily meant to deal with.

-K-

I still need to do more testing with printers to see what they do with RFC
> 6874 URIs once the print client (CUPS) is updated.  I suspect it will be a
> mixed result...
>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 24 May 2013 16:32:49 -0400

Kerry,

On 2013-05-24, at 3:44 PM, Kerry Lynn <[email-masked]> wrote:
> So it appears the current 'host' production used by print drivers is not currently specified
> by any RFC; why not just continue to use the same format irrespective of RFC 6874?

Mainly because I expect that future (browser and print) software will use the RFC 6874 format, and we don't want to have one format for IPP printers and another for everything else...

> It's the browser case that RFC 6874 was primarily meant to deal with.

The issue is that a) we need the printer to report admin and supply level page URLs the browser can use and b) printer web pages usually contain absolute URLs, so regardless of the client involved we'd need the printer to preserve the full address for the client.

---

From: Ole Troan <[email-masked]>
Date: Fri, 24 May 2013 22:33:22 +0200

Michael,

> All of this falls apart with link-local addresses and RFC 6874.  Because the client is required to remove the zoneid from the outgoing request, the URIs it gets back from the server are no longer "…

how is this different from any other application using link-local addresses?
the application has to be 'bound' to the given zone. if a host receives an RA from a router, it learns the link-local address of the router,
but it locally ties that link-local address to the zone it belongs to.

given that you cannot use link-locals in referrals outside of the correct zone, why doesn't this also work for your application?

client connects to http:://[fe80::1%Ethernet0/0]
the client has to assume that all embedded URIs with link-local addresses belong to the same zone that it connected to.
after all they cannot belong to any other zone...  the server obviously has to make sure it never gives out these URIs
to a client connecting using non-link-local addresses multiple hops away.

> What I propose is that we change the wording to allow the zoneid in the Host header but not in the Request-URI.  HTTP proxies would be required to strip any zoneid information in the Host header.…

to reword. you need something for which the client gives the server some opaque information that it can use to identify interface when it gets the embedded URIs in the reply back?
again I don't understand why the client doesn't know the interface to use already.

cheers,
Ole

---

From: Michael Sweet <[email-masked]>
Date: Tue, 28 May 2013 09:50:28 -0400

Ole,

> how is this different from any other application using link-local addresses?

In this case, the server is returning absolute URIs (for printers, typically URIs with http, https, ipp, or ipps schemes on a variety of ports) that the client can later use for accessing the corresponding resources.

> to a client connecting using non-link-local addresses multiple hops away.

OK, so the problem is that absolute URIs are embedded in the content returned by the server. Forcing the client to rewrite all of the URIs in the returned content is a tremendous burden on the client, while the server is generating these absolute URIs on-the-fly to satisfy the client's request and could include the zoneid information essentially "for free" with minor changes to its input validation (to allow addresses with zoneid information).

Put another way, would you rather write the client code that "fixes" every embedded URI in an IPP response, HTML document, CSS file, XML file, XSLT file, PDF file, etc., or would you prefer writing the server code that just embeds the client-provided address in the URIs it returns?

> again I don't understand why the client doesn't know the interface to use already.

The client software /may/ know the interface in use because it has an absolute URI containing this information.  I say may because in many cases this information is abstracted away in some toolkit so all the client software may see is a printer name, e.g., "Acme Laser Printer down the Hall".

Moreover, the returned IPP response, HTML document, etc. may be used by code that no longer has access to the original address information - it has lost the original context and thus a link local address without zoneid information is basically inaccessible short of iterating over all the client's interfaces (assuming your OS of choice even allows ordinary users/applications to do that...)

For example, CUPS supports PPD keywords that specify the absolute URI of the printer's administration and supply report web pages. This information is collected when the queue is setup, and if the printer is setup using a numeric IPv6 link local address we need to store the client's interface name (zoneid) with the URI so it can be accessed in the future.  We made an implementation choice 8 years ago (in cooperation with the printer vendors) to support this configuration by passing the client's zoneid in the request so that the printer could return the same address+zoneid in any URIs, and that has served us well for the (small number of) users that want/need this capability.  Each client has its own PPD file using its own zoneid information...

---

From: Michael Sweet <[email-masked]>
Date: Tue, 28 May 2013 09:51:54 -0400

Kerry,

On 2013-05-24, at 1:58 PM, Kerry Lynn <[email-masked]> wrote:
> group and start by clearly and concisely stating the problem that this RFC poses

Yes, I did get a useful pointer to the mailing list subscription page last week and am now a member of the ipv6 list.

> When you speak of "hundreds of millions of printers..." it gives the impression that
> the RFC makes illegal something that printers have been doing for some time.  If
> so, can you also provide relevant references to the deployed functionality that you

I am putting together a full proposal and draft to do just that...

---

From: Ray Hunter <[email-masked]>
Date: Tue, 28 May 2013 21:34:21 +0200

Warning: post contains dumb questions.

> All of this falls apart with link-local addresses and RFC 6874.  Because the client is required to remove the zoneid from the outgoing request, the URIs it gets back from the server are no longer "…
Trying to understand what's going on here and what the root problem is.

I have some dumb questions:

Is the zoneid in the URI the interface on the client or the server node?

What does other party learn from this information, since zoneid is
currently defined as being local to the node and has no significance
outside the context of the node?

If the other party learns nothing, and the originating node just needs
to hear an echo of it's own information for it's own use, what's wrong
with using a cookie (server originated), or a hidden variable (client
originated), to transport this interface information along with the
request/reply?

What if both the server AND the client have multiple interfaces: how do
they both know which local interface on their own node is mutually
connected and to be used for communication? There's only one single
zoneid in the URI, so presumably one of the nodes is lacking some
information.

Shouldn't both nodes be using ND to learn this information?
If there's nothing in the cache, try all interfaces?

regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 May 2013 08:38:26 +1200

I'm increasingly baffled by the use case. If the host is
in a context where it can reach a server *and* has more than
one interface (such that a ZoneID is needed at all), it
shouldn't be using a link local address anyway - it
should have configured a global scope address (possibly
under a ULA prefix). Discussion of this use case surely
belongs in MIF or HOMENET.

    Brian

---

From: Michael Sweet <[email-masked]>
Date: Tue, 28 May 2013 19:27:56 -0400

Ray,

> Warning: post contains dumb questions.

No such thing! :)

> Is the zoneid in the URI the interface on the client or the server node?

It is the interface on the client.

> outside the context of the node?

The only thing it learns is "this is the address the client is using to talk to me".

> originated), to transport this interface information along with the

Well, for starters none of that is standardized, whereas "Host" is a required HTTP request header that printers (and web servers) already support.

Also, passing the information back from the server in a cookie doesn't address the client-sde URI rewriting problem: it is much simpler (and less error prone) for the server to use the client-supplied address for the URIs in its response than for the client to parse and rewrite all of the URIs in the server's response.

> zoneid in the URI, so presumably one of the nodes is lacking some

The server knows its own link-local addresses and doesn't need the zoneid information.

For the use case under discussion, the client only knows its zoneid information because the user/administrator has supplied it along with the printer's link-local address.

> If there's nothing in the cache, try all interfaces?

It would be awesome if printers supported Neighbor Discovery, but of the four printers in my home office only three support IPv6 and only one supports ND.  One of the IPv6 printers is 3 years old, the other three are less than a year old...

On the client side you'll find a similar story - sporadic support, and in many cases the ND information isn't wired into the resolver libraries, making it impossible to use a bare IPv6 link-local address without the zoneid added at the end...

---

From: Michael Sweet <[email-masked]>
Date: Tue, 28 May 2013 19:57:13 -0400

Brian,

> belongs in MIF or HOMENET.

Most hosts (and probably all of the ones we care about) have multiple network interfaces, if only the loopback interface plus some sort of external network interface, forcing the use of the zoneid.  Also, the most common place you would need to use a link-local address for access is the place where global scope addresses are basically never used - the home.

So I agree that the MIF or HOMENET working groups might have something to say here, but RFC 6874 was published by *this* group and IPv6 link local addresses have broader context than either of the other groups.

---

From: Tim Chown <[email-masked]>
Date: Wed, 29 May 2013 07:18:50 +0100

> So I agree that the MIF or HOMENET working groups might have something to say here, but RFC 6874 was published by *this* group and IPv6 link local addresses have broader context than either of the…

Indeed, the single subnet view may be the case today for IPv4 homenets, but not necessarily so in an IPv6 homenet future.  See http://tools.ietf.org/html/draft-ietf-homenet-arch-08.  So any design should take that into account. 

One interesting question for homenet is how zeroconf naming and service discovery protocols are extended to work in routed homenets.  Protocols such as PCP will also need to work in such environments should devices wish to open firewall holes. If there are other cases where link-local protocols need to work across multi-subnet zeroconf environments, where those environments are typically single subnets today, those would be good to tease out.  

Tim

---

From: Ray Hunter <[email-masked]>
Date: Wed, 29 May 2013 08:52:36 +0200

> Michael Sweet <mailto:[email-masked]>
> 29 May 2013 01:27
> Ray,
>
ACK.

So the server's CGI script echoes the HTTP request header field "Host"
set by the client browser back to the client in the URI
so that when the link to the next request is clicked at the client's
browser (or interpreted by another app on the client), it knows which
local interface to use to reach the server again?

Where's the standard that says ZoneID MUST be included in the Host
header? I presume this is rfc2616#page-128.

And the value of "Host" is always set to the host portion of the
original URI [which will currently include a ZoneID on current
implementations]?

Do you think that 6874 mandates that the ZoneID MUST be stripped from
the "Host" HTTP request header, as Host is sub-string of a URI?
> The only thing it learns is "this is the address the client is using to talk to me".
ACK.
> Also, passing the information back from the server in a cookie doesn't address the client-sde URI rewriting problem: it is much simpler (and less error prone) for the server to use the client-suppl…
ACK.
> The server knows its own link-local addresses and doesn't need the zoneid information.
I don't understand this logic. I'm presuming the outbound interface for
replies is being selected by mirroring the inbound addresses of the
request [quoting RFC6724: "In many cases, this is trivially dealt with
by an application using the source address of a received packet as the
response destination and the destination address of the received packet
as the response source."]

However I thought one of the use cases was the printer sending
unsolicited information such as "out of paper".

How would the server then select its correct local outbound interface,
if it had multiple?
Does the client supply a "callback address/port" that the printer
stores/caches?

>  For the use case under discussion, the client only knows its zoneid information because the user/administrator has supplied it along with the printer's link-local address.
Right. That was going to be my next question.

How does the very first URI learn the correct ZoneID in the first place?
Manually.

> It would be awesome if printers supported Neighbor Discovery, but of the four printers in my home office only three support IPv6 and only one supports ND.  One of the IPv6 printers is 3 years old,…
Understood.

---

From: Ole Troan <[email-masked]>
Date: Wed, 29 May 2013 13:47:19 +0200

Michael,

> On the client side you'll find a similar story - sporadic support, and in many cases the ND information isn't wired into the resolver libraries, making it impossible to use a bare IPv6 link-local a…

confused. a host cannot support IPv6 if it doesn't support ND. could you please clarify?

cheers,
Ole

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 29 May 2013 14:46:06 +0200

Hi Ole,

> confused. a host cannot support IPv6 if it doesn't support ND. could

I'm not sure that your statement is fully correct.
Though I'm convinced that ND provides many useful
features, in specific environments and rare cases
the use of ND may be problematic (due to security
or "performance" reasons).
The IPv6 spec luckily doesn't require that a node MUST
use ND. If you create static permanent Neighbor Cache
entries and switch off NUD, there is no need to perform
ND (sacrificing flexibility and some robustness).

Regards,
 Roland

---

From: Ole Troan <[email-masked]>
Date: Wed, 29 May 2013 14:49:44 +0200

> ND (sacrificing flexibility and some robustness).

I presume you are not suggesting that to install my new printer I need to:
 - manually pick and configure any addresses on the printer that isn't link-local
 - manually install a default route on the printer
 - configure the neighbor cache on the printer for _all_ directly connected hosts and routers
 - configure the neighbor cache on all the other hosts and routers.

in the department of splitting hairs, I think we're done here. ;-)

cheers,
Ole

---

From: Brian Haberman <[email-masked]>
Date: Wed, 29 May 2013 09:00:23 -0400

Hi Roland,
> ND (sacrificing flexibility and some robustness).

I am not sure which IPv6 spec you are talking about.  The Node 
Requirements RFC, especially section 5.2, is the definitive guide to 
what is (and isn't) required...

https://tools.ietf.org/html/rfc6434#section-5.2

Regards,
Brian

---

From: Michael Sweet <[email-masked]>
Date: Wed, 29 May 2013 09:17:26 -0400

Ray,

> header? I presume this is rfc2616#page-128.

RFC 2616 just says to use the host and port from the original URI.  It doesn't say anything about IPv6 link-local addresses and preceded RFC 3986's IPvFuture format. And section 3.2.2 just says that IP addresses SHOULD be avoided whenever possible with a reference to RFC 1900.

> original URI [which will currently include a ZoneID on current

Correct.

> the "Host" HTTP request header, as Host is sub-string of a URI?

Yes, from section 4 of RFC 6874:

   An HTTP client, proxy, or other intermediary MUST remove any ZoneID
   attached to an outgoing URI, as it has only local significance at the
   sending host.

Since the Host value is extracted from the outgoing URI, my assumption would be that this prohibition applies to the Host value as well, which should probably be spelled out in the future (perhaps with examples).

(this is text I plan on updating in my draft...)

> unsolicited information such as "out of paper".

In the case of IPP, the connection is always initiated by the client, and the server only responds to requests sent by the client.  There is an asynchronous event notification extension for IPP (RFC 3995 combined with RFC 3996), but that is effectively a long-duration pull operation (the client sends a Get-Notifications request to the printer, and the printer will continue sending events in the same response as needed) and not a push operation back to the client.

> Does the client supply a "callback address/port" that the printer

As indicated above, the printer never contacts the client, it is always the client contacting the printer.

> How does the very first URI learn the correct ZoneID in the first place?

The manually-entered URI case is actually the edge case of an edge case, i.e., that 1-in-a-million user that just tries things to see if they will work...

The more typical case is where the client uses a discovery protocol that either does not support name-based resolution or makes it optional.  The specific protocols I personally have to deal with are WS-Discovery, UPNP, and (coming soon) Wi-Fi Direct Services.  The first two generally use IPv4, but for Wi-Fi Direct the preference will be IPv6.

Once a client discovers the printer they may only have an IPv6 link local address for it, and that's what gets put in the URI for the printer. Conceptually one could do some clever name mapping on the host ("mac-xxxxxxxxxxxx.something.") so that the URIs would not need to contain link-local addresses at all, but given that I can't expect every OS to adopt such a strategy I need to be able to target a printer using a URI containing an IPv6 link-local address, have it return resource URIs that the client can use, have a functional web interface, etc.

---

From: Michael Sweet <[email-masked]>
Date: Wed, 29 May 2013 09:24:26 -0400

Ole,

> confused. a host cannot support IPv6 if it doesn't support ND. could you please clarify?

Well, when I looked at the ND table on my Mac ("ndp -aln") I daw one of my IPv6 printers but not the other two.  Yet I had used them all recently over IPv6, specifically to investigate whether ND might be a solution to the problem.

Moreover, running "ping6" with a link-local address but no zoneid fails, even for the printer that was listed...

Perhaps these are implementation issues in OS X, and I intend to continue testing on Linux and Windows and with some standalone ND tools, but thus far it doesn't look like ND will solve our particular problems, nor does it address how we might deal with embedded URIs in IPP responses and web pages without major changes...

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 29 May 2013 16:55:17 +0200

Hi Ole,

>  - configure the neighbor cache on all the other hosts and routers.

No, I'm obviously _not_ suggesting this
and you don't want this in ordinary environments.
But in theory, IPv6 works w/o ND, which was my point.
(e.g., consider using devices with unidirectional channels only).

> in the department of splitting hairs, I think we're done here. ;-)

Yep.

Regards,
 Roland

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 29 May 2013 16:59:56 +0200

Hi Brian,

> https://tools.ietf.org/html/rfc6434#section-5.2

I was referring to RFC 2460. RFC 6434 states
ND SHOULD be supported, which makes perfectly sense.
In very rare cases you may not be able to use ND
(e.g., if you have a unidirectional medium etc.).

Regards,
 Roland

---

From: Brian Haberman <[email-masked]>
Date: Wed, 29 May 2013 11:01:29 -0400

> (e.g., if you have a unidirectional medium etc.).

But there are MUSTs sprinkled in that section as well...

Regards,
Brian

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 29 May 2013 17:21:21 +0200

Hi Brian,

> But there are MUSTs sprinkled in that section as well...

The way I read it was:
"Neighbor Discovery SHOULD be supported."
...
"Some detailed analysis of Neighbor Discovery follows:"
....MUST....MUST...MUST... and so on
[i.e., in case you support ND then you MUST support the following
features of ND...]

Furthermore, I guess that "support" != "use", i.e., it's
also ok if my host supports ND, but if I'm not using
it for some exceptions that's ok, too.

Regards,
 Roland

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 May 2013 12:58:18 -0400

>>>>> "Ray" == Ray Hunter <[email-masked]> writes:
    Ray> Warning: post contains dumb questions.

good.  That usually mean that the document says something dumb.

    >>> Michael raised an interesting issue, and we have to analyze
    >>> it. The consensus of the working group so far is that interface
    >>> identifiers are private to the host, that any leakage outside
    >>> the host should be prevented, and that a way to prevent that
    >>> leakage is to ask proxies to erase them whenever they have an
    >>> opportunity. Michael points that some servers take an opposite

I have a stupid question.
What does it mean to have an interface identifier go through an HTTP proxy?

Given that a proxy works by having the client send the entire URL on the
GET line, it means that my web browser would send something like:

   GET http://[fe80::a%25en1]/printers/laserwrite
   Host: [fe80::a%25en1]

to the proxy.  Now, where is %en1 going to be interpreted?
On the proxy?  How can the client have any idea what to send.
It can't mean anything on the client, because the entire URL
goes to the proxy.

Okay, so may this is a "transparent" proxy. (I.e. something that
violates end to end!)   That means that the host made a request to
fe80::a on interface en1, and it turned out that to get there, some
device intercepted packets which were not supposed to leave the local
link, and well, I guess did something else to the data.

My take is that in this situation this device is doing something outside
of our entire architecture, and therefore that device is really the end
point, and it had better rewrite URLs appropriately.

    >> Some background: HTTP and IPP services in printers include
    >> absolute URIs in the content they return. For IPP this can be
    >> http/https URLs to the printer's web page, ICC profiles, and
    >> other resources, along with the ipp/ipps URIs that the printer
    >> supports. For HTTP the most common are https URLs for "secure"
    >> areas of the printer's web interface.  Because a printer is often
    >> known by multiple names and addresses ("printer.local.",
    >> "printer.example.com.", 192.168.0.100, fe80::1234, etc.), the

We have an existing problem in CUPS at least, that the certificates
generated for the https do not have all the valid names, nor can they.

    >> All of this falls apart with link-local addresses and RFC 6874.
    >> Because the client is required to remove the zoneid from the
    >> outgoing request, the URIs it gets back from the server are no
    >> longer "reachable". 

I think that part of the bug is the return of absolute URLs.  I question
whether that is truly necessary.. Why aren't relative URLs (rooted at /)
useable?

    Ray> If the other party learns nothing, and the originating node just needs
    Ray> to hear an echo of it's own information for it's own use, what's wrong
    Ray> with using a cookie (server originated), or a hidden variable (client
    Ray> originated), to transport this interface information along with the
    Ray> request/reply?

That's new behaviour at a high-level.
Even so, I don't know how that could be done without some javascript or
something to do translation, which completely runs afoul of RESTful
interfaces, I think.

    Ray> What if both the server AND the client have multiple interfaces: how do
    Ray> they both know which local interface on their own node is mutually
    Ray> connected and to be used for communication? There's only one single
    Ray> zoneid in the URI, so presumably one of the nodes is lacking some
    Ray> information.

The server never needs to specify it's link local address.

    >> What I propose is that we change the wording to allow the zoneid
    >> in the Host header but not in the Request-URI.  HTTP proxies
    >> would be required to strip any zoneid information in the Host
    >> header.  HTTP servers would be required to ignore any zoneid
    >> information for purposes of address validation but include it for
    >> any absolute URIs to the server they generate. 

This seems nonsensical to me.
If the zoneid is not in the Request-URI, then how can the proxy do
anything with it?  What address is in the Host: header that has a
meaningful zoneid?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 May 2013 13:09:15 -0400

>> The server knows its own link-local addresses and doesn't need

    Ray> I don't understand this logic. I'm presuming the outbound interface for
    Ray> replies is being selected by mirroring the inbound addresses of the
    Ray> request [quoting RFC6724: "In many cases, this is trivially
    Ray> dealt with

yeah, that's just TCP.

    Ray> However I thought one of the use cases was the printer sending
    Ray> unsolicited information such as "out of paper".

I don't know how this works in an unsolicited way.
I thought that with the ways we have tried to standardize (IPP, XMPP,
SIP, forgive me... I don't know which won) the client pretty much always
has to subscribe, or it's a broadcast/multicast.

    >> For the use case under discussion, the client only knows its
    >> zoneid information because the user/administrator has supplied it
    >> along with the printer's link-local address. 
    Ray> Right. That was going to be my next question.

    Ray> How does the very first URI learn the correct ZoneID in the first place?
    Ray> Manually.

In a Bonjour/mDNS scenario, the client sees the link-local address on interface
with zoneID FOO, and records that.  The client learns it's correct ZoneID.
(At no point does it matter what the server's zoneid for the interface
is)

---

From: Michael Sweet <[email-masked]>
Date: Wed, 29 May 2013 13:58:43 -0400

Michael,

> It can't mean anything on the client, because the entire URL

You might be able to stretch things to allow a proxy for a locally-discovered device like a printer, e.g,, some sort of security policy at an organization.  But in that case while the proxy might forward the link-local URI as-is, it would also need to ignore the zoneid  and use ND or an "all interfaces" approach to forward the request to the device.

> generated for the https do not have all the valid names, nor can they.

Well, there *are* multi-domain certificates, but most people stick with self-signed or organization-signed certs.  Longer term I want to add full SNI support - this mostly works for OS X already (we'll search for a matching cert in the system keychain) but needs more work on Linux.
 
> whether that is truly necessary.. Why aren't relative URLs (rooted at /)

Because we have four URI schemes/protocols - http, https, ipp, and ipps - and multiple port numbers to deal with for printers.  And right now there is no way to do a relative URI that just changes the scheme and/or port.

> anything with it?  What address is in the Host: header that has a

The reason for having proxies strip the zoneid is because the zoneid is only useful to the client - not to the proxy and not to the server.  But I wasn't really considering the use of a proxy for local network access (above).

The Host header contains the client's zoneid information and gets used in any URIs returned by the server (so that the client is able to access the server via those URIs without having to figure out what zoneid to use...)

---

From: Michael Sweet <[email-masked]>
Date: Wed, 29 May 2013 14:13:08 -0400

Michael,

> (At no point does it matter what the server's zoneid for the interface

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.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 29 May 2013 21:10:05 +0200

> 29 May 2013 20:13
> 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?

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?

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)?

Thanks,
RayH

---

From: Ole Troan <[email-masked]>
Date: Wed, 29 May 2013 21:40:17 +0200

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.

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

---

From: Michael Sweet <[email-masked]>
Date: Wed, 29 May 2013 16:16:22 -0400

Ray,

> 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.

> 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.

> 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.

---

From: Michael Sweet <[email-masked]>
Date: Wed, 29 May 2013 16:47:37 -0400

Ole,

> now the question becomes, what do you do with the embedded URIs containing link-local addresses?

For a web page, the user would click on links/buttons that open other pages on the printer.

For an IPP response, the client would fetch localization data, ICC profiles, etc. or open web pages in a browser (printer administration and supply pages).

> the referral clearly has no value outside of the given link-local zone.

Agreed.

> sense that the referrals using link-locals would belong to a different zone?

No.

The issue is one of preserving that context, in every application or in every data store.  If the context (zoneid) is part of the URIs, then the URIs will continue to work as long as the two devices remain in the same link-local zone, without changes to the software.

If the context is not included in the URIs, then *every* client application has to be updated to add that context back to the URIs for every kind of content that might be returned. *Or* every operating system needs to be updated to support handling link-local addresses without a zoneid so that applications do not require changes.

> 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.

That implies adding extra code to every network application that wants to support link-local addressing, which is what I want to avoid (makes for a bad user experience when some things work and others do not because software hasn't been updated...)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 May 2013 09:46:04 +1200

> So I agree that the MIF or HOMENET working groups might have something to say here, but RFC 6874 was published by *this* group and IPv6 link local addresses have broader context than either of the…

Yes, but the limitation of the meaning of the Zone ID to a single
host isn't new; RFC 6874 simply reiterates it. The problem is that
the whole notion of scope is defective as currently defined (hence
http://tools.ietf.org/html/draft-carpenter-referral-ps, which we plan
to come back to when time permits). Today, the only clean fix is
to use a global-scope address, which means a ULA for disconnected
networks.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 May 2013 14:56:09 -0700 (PDT)

----- Original Message -----
> From: Ole Troan <[email-masked]>
> To: Michael Sweet <[email-masked]>
> Cc: Ray Hunter <[email-masked]>; "[email-masked]" <[email-masked]>; t.petch <[email-masked]>; Christian Huitema <[email-masked]>
> Sent: Thursday, 30 May 2013 5:40 AM

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.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 May 2013 21:13:25 -0400

>>>>> "Ole" == Ole Troan <[email-masked]> writes:
    Ole> could you not infer the link-local zone of the referral from
    Ole> the transport session? 
    Ole> given a link-local transport connection using a link-local
    Ole> zone, would it ever make 
    Ole> sense that the referrals using link-locals would belong to a
    Ole> different zone? 

Or to put it another way, if the URI you started with was bound to a
particular zoneID, then any link locals you see in the HTML (or JSON or
...) that you get from that direction, are also bound to that zoneID.

This is a bit like what MIF's RFC 6731 does for DNS.
(as much as I hate that solution)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 May 2013 21:15:51 -0400

>>>>> "Michael" == Michael Sweet <[email-masked]> writes:
    >> (At no point does it matter what the server's zoneid for the interface

    Michael> One important point here: we don't send IPv6 link local
    Michael> addresses in this case, we send the .local hostname that
    Michael> the printer is using.  This avoids the whole issue of IPv6
    Michael> link-local addresses in URIs, we just have to deal with

Yes, I see your point that in the mDNS case, likely we have a name.
But not always.  Sometimes, one starts with a name, it gets translated
to an address, then gets passed elsewhere in some way, and only the
address is left.  When the name got turned into an address, it got a
zoneID (in the struct addrinfo) assigned.  

If you then pass that somewhere else, or into the kernel, maybe it goes
through some network policy code (e.g. IPsec SPD... into a key daemon),
the name is long lost.

And of course, we have the human debugging situation, which is the most
likely use.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 May 2013 21:18:33 -0400

>>>>> "Mark" == Mark Smith <[email-masked]> writes:
    Mark> I too have been struggling to understand the problem. If an
    Mark> application has chosen to use a link-local destination address
    Mark> as a destination for a query, it has also chosen to use and

The application passed a "struct sockaddr" that it got from
getaddrinfo() to connect(2).  TCP took care of the rest.  The
application didn't "choose" anything.  It just ran the normal protocol
machinery.