Internet-Draft Link-Local URI Connectivity February 2024
Schinazi Expires 25 August 2024 [Page]
6874 (if approved)
Intended Status:
Best Current Practice
D. Schinazi
Google LLC

Best Practices for Link-Local Connectivity in URI-Based Protocols


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

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at Status information for this document may be found at

Discussion of this document takes place on the HTTP Working Group mailing list (, which is archived at

Source for this draft and an issue tracker can be found at

Status of This Memo

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

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 25 August 2024.

1. Introduction

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.

1.1. Conventions and Definitions

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.

2. Limitations

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.

3. Background

Before diving into potential solutions to these limitations, readers will benefit from the following relevant historical context.

3.1. URIs, URLs, and A Tale of Two Specifications

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

3.3. Further Attempts

After it was clear that most browser 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.

5. Goal Definition

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.

7. Deployment Considerations

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.

8. Security Considerations

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.

9. IANA Considerations

This document has no IANA actions.

10. References

10.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, , <>.
Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

10.2. Informative References

"CORS protocol", WHATWG Living Standard, <>.
Sweet, M., "An IPvFuture Syntax for IPv6 Link-Local Addresses", Work in Progress, Internet-Draft, draft-sweet-uri-zoneid-01, , <>.
Lemon, T. and S. Cheshire, "Service Registration Protocol for DNS-Based Service Discovery", Work in Progress, Internet-Draft, draft-ietf-dnssd-srp-24, , <>.
Carpenter, B. E., Cheshire, S., and R. M. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", Work in Progress, Internet-Draft, draft-ietf-6man-rfc6874bis-09, , <>.
Carpenter, B. E. and R. M. Hinden, "Entering IPv6 Zone Identifiers in User Interfaces", Work in Progress, Internet-Draft, draft-carpenter-6man-zone-ui-01, , <>.
Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, DOI 10.17487/RFC1630, , <>.
Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, , <>.
Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, DOI 10.17487/RFC2732, , <>.
Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, , <>.
Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, , <>.
Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, , <>.
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <>.
Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, , <>.
Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, , <>.
Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, , <>.
Carpenter, B., Cheshire, S., and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, , <>.
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <>.
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, , <>.
Fenner, B. and M. J. Dürst, "Formats for IPv6 Scope Zone Identifiers in Literal Address Formats", Work in Progress, Internet-Draft, draft-fenner-literal-zone-02, , <>.
Ruby, S. and L. Masinter, "URL Problem Statement and Directions", Work in Progress, Internet-Draft, draft-ruby-url-problem-01, , <>.
"URL-LS", WHATWG Living Standard, <>.
"Support IPv6 link-local addresses?", <>.
"Support IPv6 zone identifiers", <>.


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.

Author's Address

David Schinazi
Google LLC
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America