| Internet-Draft | Link-Local URI Connectivity | October 2024 |
| Schinazi | Expires 20 April 2025 | [Page] |
Link-local IP connectivity allows hosts on the same network to communicate with each other without the need for centralized IP addressing infrastructure. The IP prefixes 169.254.0.0/16 and fe80::/10 were reserved for this purpose. However, both IP versions have limitations that make link-local addresses unideal for usage with URI-based protocols. This document provides guidance for how best to enable link-local connectivity in such protocols. This document also obsoletes RFC 6874, a previous attempt at solving this issue.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://DavidSchinazi.github.io/draft-schinazi-httpbis-link-local-uri-bcp/draft-schinazi-httpbis-link-local-uri-bcp.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-schinazi-httpbis-link-local-uri-bcp/.¶
Discussion of this document takes place on the HTTP Working Group mailing list (mailto:ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/.¶
Source for this draft and an issue tracker can be found at https://github.com/DavidSchinazi/draft-schinazi-httpbis-link-local-uri-bcp.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
To simplify configuration of new hardware, manufacturers often print configuration URLs on labels to allow the user to reach the configuration page by copying the URL into their browser. This is often simplified further by encoding the URL in a QR code and asking the user to scan it with a smartphone.¶
While the majority of IP networking uses globally routable addresses, those rely on addressing infrastructure that isn't always available. For example, two hosts connected via a direct peer-to-peer link may not have access to an entity assigning IP addresses through DHCP or IPv6 router advertisements. Connectivity is often desirable in such scenarios, and can be accomplished using link-local addresses. This feature was added in IPv6 [RFC4007] and retroactively backported to IPv4 [RFC3927]. However, these addresses have limitations that make them unsuitable for use in URLs, as described in Section 2.¶
This document obsoletes [RFC6874], a previous attempt at solving this problem that failed, as described in Section 3.2. This document provides recommendations that solve this problem in Section 6.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Since there is clear value in being able to configure new devices in the absence of IP addressing infrastructure, there is interest in supporting link-local connectivity via URLs. However, link-local addresses have limitations in this regard.¶
In order to simplify implementations (and as recommended in [RFC3927]), most implementations disable IPv4 link-local addresses any time globally routeable addresses are available. This can lead to instability of link-local addresses. Additionally, these addresses are generated randomly with fewer than 16 bits of entropy, making conflicts statistically likely.¶
Both of these limitations make it impossible for a device to print a configuration URL on its packaging that uses a static IPv4 link-local address.¶
In IPv6, link-local addresses are generated randomly with 64 bits of entropy, making conflicts statistically unlikely. Additionally, in IPv6 the use of multiple addresses per interface is encouraged. This allows link-local addresses to remain even when globally routable addresses change.¶
However, IPv6 introduced the concept of a scope zone (Section 5 of [RFC4007]) and requires that every host include a zone identifier when sending to any IPv6 link-local address. While [RFC4007] defined a "default" zone, that is not widely supported: most operating systems still require the scope identifier when making a socket operation on IPv6 link-local addresses. This means that IPv6 link-local addresses have to be accompanied by a zone identifier from the moment that the address enters the process.¶
Unfortunately, IPv6 address support was added to URLs [RFC2732] prior to the creation of IPv6 scoped addresses, leaving the URL format for IPv6 addresses incapable of representing zone identifiers. This effectively prevented the use of link-local IPv6 addresses in URLs.¶
Before diving into potential solutions to these limitations, readers will benefit from the following relevant historical context.¶
URIs and URLs were created early in the development of the World-Wide Web and were brought to the IETF in 1994 (see [RFC1630] and [RFC1738]). Over the years, the IETF maintained and evolved these specifications. In particular, support for IPv6 addresses was added in 1999 (see [RFC2732]). The IETF published an updated URI specification in 2005 ([RFC3986]).¶
In 2004, a group of browser vendors created the WHATWG, an effort to evolve Web-related specifications outside of the W3C or IETF. The WHATWG eventually forked the URL specification from IETF by creating the WHATWG URL Living Standard ([URL-LS]). From that point onwards, even though development of URIs and URLs continued at the IETF, this work often didn't lead to corresponding implementation changes in Web browsers.¶
Almost two decades later, the situation hasn't changed. The IETF still maintains URL/URI specifications that are authoritative in all contexts except the Web, while the WHATWG maintains a URL specification that is authoritative for Web browsers. Note that the use of the word "authoritative" here is somewhat of a misnomer: neither of these standards bodies have any actual authority to enforce that their specifications be followed, and instead rely on implementers choosing to follow the specification.¶
As the Web gained in popularity, an increasing number of networked devices such as routers or printers started to incorporate Web servers as their primary means of configuration. Many of these devices function properly without centralized IP addressing infrastructure, so there was interest in communicating with them using IPv6 link-local addresses.¶
In 2004 and 2005, an effort was started to allow representing zone identifiers in URIs [URI-ZONE-EARLY]. That proposal leveraged the "IPvFuture" feature of the URI specification (see Section 3.2.2 of [RFC3986]), and example of the syntax is "[v1.fe80::a+en1]". That document was never published but its format ended up being used by CUPS in 2005 ([CUPS]).¶
Over the course of 2012 and 2013, a revival of this effort led to the creation and publication of [RFC6874], an update to the IETF URL specification that defines how to represent IP zone identifiers in URLs. This version used the IPv6address syntax in URIs, an example of it being "[fe80::a%25en1]".¶
The majority of Web browsers did not implement either of these changes. The main concern from browsers what that such a change would require modifying many different components of the browser, with the associated security risks and maintenance costs. Almost all browsers came to the conclusion that such a change was not worth the effort. Further examples of what made [RFC6874] complex to implement are listed in Section 4. After browsers decided not to implement it, the WHAT URL Living Standard was updated to mark the zone identifier as "intentionally omitted" (see [URL-ZONE-TRACKER1]). The WHATWG subsequently rejected a request to add zone identifiers to their URL specification (see [URL-ZONE-TRACKER2]).¶
After it was clear that most browsers were not going to implement [RFC6874], another attempt was made to modify the URI RFC: [DRAFT-6874BIS]. While this attempted to address some of the difficulties in implementing [RFC6874], it did not address the fact that browsers were not willing to start such a complex implementation effort given the small usage it was expected to receive. That document failed to achieve consensus and was not published.¶
Later, an attempt was made to address the generic question of how users can input IPv6 link-local addresses into software interfaces [DRAFT-ZONE-UI]. In this model, the zone identifier is considered independently of the IPv6 address itself. In the case of Web browsers, the zone identifier would not be considered part of a URI. However, this does not in itself resolve all the difficulties in considering the zone identifier as part of the Web security model, as described in the next section.¶
Browsers operate differently from simple command-line tools such as ping, ssh or netcat. Those tools generally take a destination as input from the command-line, resolve that destination string into an IP address (or list of addresses) via a function such as getaddrinfo ([RFC3493]), and then immediately perform socket operations using that address. Supporting zone identifiers in these scenarios is pretty simple because the result of resolution is only used in socket operations.¶
One might assume that Web browsers operate similarly, but that would be incorrect. Browsers follow the Web security model, which is based around the concept of an Origin ([RFC6454]). The origin is propagated throughout the browser software: it is involved in whether to use a resource in the HTTP cache ([RFC9111]), it is checked when deciding to allow sharing information ([CORS]), it is used to save security policies ([RFC6797]), and in many other cases beyond making socket operations. Additionally, all the portions of the origin are sent to the server in HTTP ([RFC9110]).¶
In contrast, the zone identifier is only valid and meaningful in a given node. As specified in [RFC4007], the zone identifier from a given node cannot be used by other node and it cannot be sent over the wire. This makes it fundamentally incompatible with the concept of Origins.¶
The solution in [RFC6874] requires the browser to treat the zone identifier as part of the origin in some contexts (such as when determining uniqueness of a name), but not in others (such as when sending the Host header on the wire). This significantly increases implementation complexity and security risks.¶
Conversely, the proposal in [DRAFT-6874BIS] sends the zone identifier over the wire, and suggests that the recipient not make use of it. This creates new implementation complexity, now on the HTTP server. It also doesn't address the multitude of implementation changes required to incorporate the changes in URL parsing.¶
In all cases, implementation matters are further complicated by the fact that the percent character ("%") is used in URLs for percent-encoding. While each proposal offered a different resolution to this encoding issues, all of them have significant downsides ranging from poor usability to ambiguous inputs.¶
Regardless of which specific mechanism is used to encode zone identifiers in URIs, the complexity of Web browsers and widespread use of Origins make it impossible to implement zone identifiers without large engineering efforts.¶
Separately, the proposal in [DRAFT-ZONE-UI] would require querying the user from many distinct browser components to determine the correct zone identifier to use. That is particularly difficult to implement in multi-process browser architectures. It would also confuse the user when they receive a popup for a link-local address that appeared in HTML.¶
However, the top-level goal of all these efforts is to allow link-local communication via URLs. That does not require encoding IPv6 link-local addresses in URIs. All that is is needed is for the URI to contain information that resolves to the correct link-local address.¶
The deployment of IPv6 happened in part because it did not require users be aware of IPv6 addresses, nor remember them, nor type them into browser address bars. It happened transparently to the user, thanks to the DNS: once it was possible to query IPv6 addresses from the DNS (see [RFC3596]), users could browse the Web over IPv6 without having to ever see an IPv6 address. Surfacing IPv6 link-local addresses to users is not required.¶
The concept of address resolution also applies to local connectivity in the absence of centralized IP addressing infrastructure, because DNS hostnames can resolve to link-local addresses. In the absence of centralized DNS infrastructure, mDNS (see [RFC6762]) can be used to resolve link-local addresses from instance names.¶
Devices that are reachable over IP link-local connectivity and that host servers of URI-based protocols SHOULD create an mDNS local instance name for themselves and SHOULD respond to mDNS queries for that instance name. Device manufacturers SHOULD pick instance names to maximize the probability of the name being unique. For example, this can be accomplished by including the brand, model and serial number of the device in the name. Another option is to use a name derived from the device's MAC address.¶
If the instance name is defined to be unique (for example by including a unique serial number), it can then be encoded in an URL that can be printed on the device packaging, either as text or in the form of a QR code.¶
If the name is not unique, devices can rely on mDNS conflict resolution (Section 9 of [RFC6762]) to ensure unique names, and then browse for the relevant service (Section 4 of [RFC6763]). However, this has two limitations. First, Web browsers don't currently perform this browsing. Second, conflict resolution requires the conflicting devices to be in the same multicast domain, which isn't guaranteed. For example, the browser could be able to discover two devices both named "example.local" where one is on Wi-Fi and the other on Ethernet, but those two devices won't detect the name conflict if the Wi-Fi and Ethernet networks are not bridged.¶
Following these recommendations solves the goals described in Section 5 without requiring any changes in Web browser software.¶
DNS Service Discovery relies on either link-local multicast (in the case of mDNS) or on service registration infrastructure (such as [DNSSD-SRP]). If a network blocks link-local multicast and does not offer service registration infrastructure as an alternative, then DNS service discovery cannot function. Because of this, the recommendations in this document won't work on such networks.¶
Many aspects of the Web security model rely on using a name as a root of security. This has the following consequences:¶
name unicity matters, as conflicts can lead the two devices sharing a name to incorrectly share a security boundary.¶
HTTPS/WebPKI security currently relies on globally-registered names, and is therefore not available for link-local connectivity. Such link-local communication is therefore inherently not authenticated. Future work might define mechanisms to trust local anchors, which would enable such security.¶
Fundamentally, mDNS has similar security properties as the underlying link-local address it resolves to.¶
This document has no IANA actions.¶
Some of the historical context in this document came from prior research documented in [URL-HISTORY]. The author would like to thank Brian E. Carpenter, Stuart Cheshire, and Bob Hinden for their prior work in this space. Additionally, the author thanks Brian E. Carpenter, Eric Rescorla and Michael Sweet for their review and comments.¶