#774: updated URI syntax for IPv6 link-local zone identifiers

Opened Sep 12, 2022

Wotcher TAG!

I'm requesting a TAG review of "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers" (draft-ietf-6man-rfc6874bis).

Explainer

From the abstract:

This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax and Internationalized Resource Identifier specifications (RFC 3986, RFC 3987) accordingly, and obsoletes RFC 6874.

This IETF draft proposes updating URI/IRI IP-literal syntax as follows:

 IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"

 ZoneID = 1*( unreserved )

 IPv6addrz = IPv6address "%" ZoneID

in order to help ensure adoption within browsers and other tools. One goal is to ease use of IPv6 link-local address literals in browsers when/where on-link device configuration is being performed.

This is a clarification and, importantly, simplification of RFC 6874.

Specification

The latest version of this draft can be found at https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis.

Tests

None of the kind TAG might expect. With respect to implementation, at a minimum, a patch to wget to support this change exists.

User research

Section 2 and Section 4 of draft -02 capture observations of IP address literal parsers and use (or lack thereof) currently. This forms part of the motivation for this document.

Security and Privacy self-review

Section 5 of draft -02 covers security and privacy considerations.

Primary contacts

Brian E Carpenter (becarpenter)
Jen Linkova (furry13)
Erik Kline (ekline)

Organization

This document is a product of the IETF IPv6 Maintenance working group (6man).

Key pieces of review

This document updates the IP-literal ABNF specification of URIs/IRIs. As such, any feedback on the correctness or additional thoughts on the document in general would be very much appreciated.

External trackers

The document status tracker here

Further details:

I have reviewed the TAG's Web Platform Design Principles
Relevant time constraints or deadlines: before the end of September, 2022
The group where the work on this specification is currently being done: IETF 6man working group

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify becarpenter, furry13, ekline

Discussions

2022-10-10

Minutes

bumped

2022-10-17

Minutes

Yves: looks okay, but need to understand more

2022-10-24

Minutes

Yves: no progress. I want to look at the impact of the new syntax on the existing parser and things that can be treated as ? identifiers or not

Hadley: before plenary?

Yves: I won't be in plenary

Hadley: Dan said 6 days ago that we'd hope to get back to them soon. Can Dan carry it on while you're gone?

Yves: I can comment to say it looks good but need to work on a few things.

2022-11-14

Minutes

Yves: they replied but I don't think the refutation they gave is necessarily good.

Dan: Martin Thompson said he'd given feedback. Would be good to respond as Yves said, and to acknolwedge Martin's message which seems to suggest lack of implementer support. "Considering the lack of implementer support mentioned, it doesn't seem likely we can review this positively"

2022-11-28

Minutes

Dan: mixed messages..

Yves: it's right that malformed url or wrongly decoded url will be rejected, but this is not the proper way to do processing and escaping. It's relying on the fact there won't be bugs in parsing of things that have an escape char that is not an escape char. To me it's bad design. For the attacks, it's like many other things that can be attacked using local addresses. The IETF people against it need to fight. We expressed our concerns. I asked to have more discussion with the people in charge of revising the URL RFC, I think that's the proper place to discuss that. We can close with concerns and say we want to have that resolved in IETF.

Dan: I could ping mnot and ask him to weigh in on the issue, but perhaps we shouldn't do that

Yves: we can ask mark and martin if that would be a good course of action for them as well. Discuss closing at plenary.

2022-12-19

Minutes

Yves: goal was to close with concerns or unsatisfied. The IETF group in charge of URLs should discuss it.

Dan: I don't think we're satisfied

Yves: we voiced our concerns and we would like those to be discussed in an ietf group

Dan: I also dont' think we can say unsatisfied... ambivalent or out of scope?

Yves: ambivalent would be better, but clearly we need more stakeholder support as well. Browsers indicated they didn't want to implement it.

Dan: so it should be unsatisfied.

Yves: this still shouldn't be a blocker - ietf might find a way that will work.

<blockquote> Hi folks - We've expressed some concerns about the current proposal especially around the use of '%' as a delimiter. Also it seems there is lack of implementer support, which is a concern to us. Hence we're going to close this one with an "unsatisfied" label. Our suggestion is that discussion should continue at the IETF, with the group in charge of RFC3986. We look forward to hearing from you again when these issues have been resolved. </blockquote>

Dan: cloeses and leaves comment