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 On 23/05/2013 15:51, RFC Errata System wrote: > 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 <msw...@apple.com> > > 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 > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
