Entering IPv6 Zone Identifiers in User Interfaces

[martinthomson]

こんにちは TAG-さん!

I'm requesting a TAG review of Entering IPv6 Zone Identifiers in User Interfaces.

This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture (RFC 4007), should be entered into a user interface. It obsoletes RFC 6874.

• Explainer: https://datatracker.ietf.org/doc/html/draft-ietf-6man-zone-ui-02
• Specification URL: https://datatracker.ietf.org/doc/html/draft-ietf-6man-zone-ui-02
• Tests: n/a
• User research: none
• Security and Privacy self-review: see below
• GitHub repo: none
• Primary contacts:
  • Brian Carpenter (@becarpenter), Editor
  • Bob Hinden (@bobhinden), Editor
  • Erik Kline (@ekline), Responsible Area Director
• Organization(s)/project(s) driving the specification: see below
• Key pieces of multi-implementer support: see below
• External status/issue trackers for this specification:

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: According to editors, a last call is imminent in the next few weeks.
• The group where the work on this specification is currently being done: 6man IETF Working Group
• Major unresolved issues with or opposition to this specification: see below
• This work is being funded by: ?

You should also know that...

tl;dr: This reverts a proposed change to URL syntax that, while it was published in RFC 6874, never gained any real standing in Web standards. What was a concrete proposal for how to express zone identifiers in URLs would revert to a state of having absolutely no specification. Consequently, there would be no standardized way to identify the applicable zone when identifying a resource that as an IPv6 literal for a host. The document suggests a syntax for expressing IPv6 literals in some user interfaces, but it completely avoids those that involve URLs.

---

This is a bit of an irregular request, but it would be worthwhile getting the TAG's input on this subject. Given where things are, that might be as simple as "yeah OK", but the exercise of writing this out and discussing the situation seems worth doing.

RFC 6874 attempted to modify URL syntax in a way that was not strictly backward compatible. This was to introduce a feature of IPv6 addressing that is not widely used and is largely limited to private networks.

The zone identifier is a host-local identifier for a network interface that is sometimes necessary to disambiguate a non-global or non-unique IPv6 address. For instance, the address "fe80::1" is a "link-local" address that can be assigned to a different host on different network segments. A host that has multiple interfaces might participate in networks that use the same address. A zone identifier is appended to addresses to disambiguate them. Continuing the example, "fe80::1%wifi" or "fe80::1%9" might be used.

Zone identifiers only have local significance, so there is no consistent way to use them on the Web, but RFC 6874 nevertheless tried to change URI syntax to include a zone identifier. The idea was to let people type in a disambiguated address so that they were able to reach the intended host.

The problems with this approach took a long time to identify, but you can see some of that from the discussion on the WHATWG URL spec. Picking a few:

• One does not simply change URL syntax. Some effort was made to identify places where code was intolerant of the extra characters, but the way in which this potentially touches a whole.
• The rules for case-folding seem to be incompatible with RFC 3986.
• The effect of this on what we understand to form the Origin tuple is unclear.
• Who needs to receive this information and handle it is unclear if it is used outside of user interfaces. The identifiers for zones only make sense on a single computer, so content cannot use them in any coherent manner.

Of note is this draft that recommends the use of .local names instead. This resolves the interface issues by using a name, which could be unique. Unfortunately, that requires the use of mDNS, which is not supported enough to be consistently available.

All of which is to say that this has been a contentious problem to resolve. Some people (full disclosure: I'm one of them) think that maybe zone identifiers were a mistake. Others are frustrated that you can't type (or copy-paste) a qualified IPv6 address into a browser and have it work. (These are also mutually compatible positions.)

The proposal recognizes more formally the distinction between identifying a zone locally, which is largely a user interface choice, while specifying a convenient syntax. That syntax is available for use in any given context, but whether the syntax is adopted will need to depend on the context.

That is, the specification proposes a convenience for user interface, but does not seek to establish a new format that can be used in protocols. Personally, I have some concern that this distinction might be lost on some of the audience, which might result in undesirable results.

URLs are an important context where IPv6 literals are used. The document is silent when it comes to URLs, except to say that the URL syntax proposed in RFC 6874 is obsolete.

For a command-line tool that handles URLs, you might imagine something much more like wget --interface eth0 https://[fe80::1]/ than what was originally proposed with wget https://[fe80::1%eth0]/ (despite Brian having code that quite trivially makes that possible). Neither of those forms is explicitly considered. The idea is that any given interface (command-line or otherwise) would need to decide for itself how it wanted to operate.

Questions the TAG might consider answering:

• Is this a generally acceptable direction?
• Is the distinction between user interface and protocol format clear enough?
• Does the use case of "entering a scoped IPv6 literal into a browser" make sense?
• Does this use case warrant further work to support it on the Web platform?
• Does the mDNS approach make more sense?

[becarpenter]

N.B. The current draft is now https://datatracker.ietf.org/doc/html/draft-ietf-6man-zone-ui-03
Also note this phrase in the draft: the recommendations and normative statements in this document do not apply to web browsers. Most of the points Martin raises above are now explicitly outside the scope of the draft.

[jyasskin]

Keeping in mind that I know very little about the details of IPv6:

• It does seem unfortunate to lack a unified URL syntax to express this sort of IP address.
• That said, since these URLs can only be interchanged between programs within a single node, they're arguably not part of the Web's architecture, and so outside of the TAG's scope. (Right? IP addresses that can be interchanged within a local network would use a prefix other than fe80:?)
• Entering a local device address into a browser is a sensible use case. That doesn't prove that it's worth implementing given the complications, but I don't see a reason to question that some users would find value in doing that.
• It's not clear to me how many and what kind of users this affects. Is it mostly technical users interacting with specialized hardware? Novice users trying to configure their router? Only users with multiple network cards? (Seems like Linux's lack of a default zone eliminates that last one, but maybe this is a Linux bug rather than a URL bug.) I think we'd need to know more about who we're leaving behind in order to judge whether it's worth supporting on the web platform.
• Even if the TAG were convinced, to actually get it supported in browsers, the browser developers would need to be convinced to prioritize it. It seems like browsers have several possible paths to supporting this sort of IP address, even without changes to the URL standard. For example, they could provide a devtools interface to specify a default zone, or they could allow defining petname hosts that map to particular IP addresses.
• I don't think I know enough about the problems with deploying mDNS to be able to judge whether it makes more sense.

So, overall, I don't feel like the TAG should raise any objections to @becarpenter's draft. But I could easily be missing something.

[becarpenter]

@jyasskin, thanks. At the present time it seems clear that the very concept of a literal link-local address that specifies an interface number or name is problematic for the URL origin model - the @DavidSchinazi draft that @martinthomson mentioned explains it better than I can. That's why we tried to separate the operational problems we have in IPv6-land out from the whole question of URI syntax and what browsers should or should not do.

[michaelrsweet]

@martinthomson

Of note is this draft that recommends the use of .local names instead. This resolves the interface issues by using a name, which could be unique. Unfortunately, that requires the use of mDNS, which is not supported enough to be consistently available.

I'm not sure where this comes from - while we certainly had issues back in 2010 with ISP routers defaulting to blocking of multicast traffic, that hasn't been the case for a long time now.

Every major client OS (Android, ChromeOS, iOS, Linux, macOS, and Windows) supports mDNS out-of-the-box. Almost all network printers, TVs, and cameras support mDNS. My Ubiquity network gear, Lutron gateway, Nest thermostat and smoke detectors, NAS, VoIP phones, and new washer and dryer all support it as well.

So maybe we need to note that while some network equipment might not (yet) support mDNS, the vast majority of it does. Using mDNS hostnames is a viable alternative to using link-local addresses in URIs, and has been for a long time now...

[becarpenter]

@michaelrsweet, however I did see evidence that all is not well in the ecosystem around resolving names using mDNS when an interface name is involved. I've been told, for example, that Chrome simply does not contain code to pass the interface number along with a link-local address to socket calls, even though the resolver returns both components from mDNS. (Firefox gets that right, however). More at https://github.com/becarpenter/misc/blob/main/zelect/README.md

[jyasskin]

FWIW, "get Chrome to change its code" is a smaller lift than "figure out the right model for IPv6%zone origins [which I do suspect is possible if we need it], get consensus on the URL changes, and then also get Chrome to change its code." (Also, zelect is an excellent hack.)

[jyasskin]

Thank you for running this past us. We think you've made the right call in undoing the URI syntax changes from RFC 6874 and excluding web browsers from your UI recommendations.