Internet DRAFT - draft-schinazi-httpbis-link-local-uri-bcp
draft-schinazi-httpbis-link-local-uri-bcp
HTTP D. Schinazi
Internet-Draft Google LLC
Obsoletes: 6874 (if approved) 22 February 2024
Intended status: Best Current Practice
Expires: 25 August 2024
Best Practices for Link-Local Connectivity in URI-Based Protocols
draft-schinazi-httpbis-link-local-uri-bcp-03
Abstract
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.
About This Document
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Schinazi Expires 25 August 2024 [Page 1]
Internet-Draft Link-Local URI Connectivity February 2024
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 25 August 2024.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
2. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Limitations of Link-Local IPv4 Addresses . . . . . . . . 3
2.2. Limitations of Link-Local IPv6 Addresses . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. URIs, URLs, and A Tale of Two Specifications . . . . . . 4
3.2. IPv6 Link-Local Addresses in URLs . . . . . . . . . . . . 5
3.3. Further Attempts . . . . . . . . . . . . . . . . . . . . 6
4. Handling IPv6 Link-Local Addresses in Web Browsers . . . . . 6
5. Goal Definition . . . . . . . . . . . . . . . . . . . . . . . 7
6. Recommendations for Link-Local Connectivity . . . . . . . . . 8
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
Schinazi Expires 25 August 2024 [Page 2]
Internet-Draft Link-Local URI Connectivity February 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.
2.1. Limitations of Link-Local IPv4 Addresses
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.
Schinazi Expires 25 August 2024 [Page 3]
Internet-Draft Link-Local URI Connectivity February 2024
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.
2.2. Limitations of Link-Local IPv6 Addresses
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.
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.
Schinazi Expires 25 August 2024 [Page 4]
Internet-Draft Link-Local URI Connectivity February 2024
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.
3.2. IPv6 Link-Local Addresses in URLs
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]).
Schinazi Expires 25 August 2024 [Page 5]
Internet-Draft Link-Local URI Connectivity February 2024
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.
4. Handling IPv6 Link-Local Addresses in Web Browsers
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.
Schinazi Expires 25 August 2024 [Page 6]
Internet-Draft Link-Local URI Connectivity February 2024
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.
Schinazi Expires 25 August 2024 [Page 7]
Internet-Draft Link-Local URI Connectivity February 2024
6. Recommendations for Link-Local Connectivity
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.
Schinazi Expires 25 August 2024 [Page 8]
Internet-Draft Link-Local URI Connectivity February 2024
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/rfc/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/rfc/rfc6763>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
10.2. Informative References
[CORS] "CORS protocol", WHATWG Living Standard,
<https://fetch.spec.whatwg.org/#http-cors-protocol>.
Schinazi Expires 25 August 2024 [Page 9]
Internet-Draft Link-Local URI Connectivity February 2024
[CUPS] Sweet, M., "An IPvFuture Syntax for IPv6 Link-Local
Addresses", Work in Progress, Internet-Draft, draft-sweet-
uri-zoneid-01, 22 November 2013,
<https://datatracker.ietf.org/doc/html/draft-sweet-uri-
zoneid-01>.
[DNSSD-SRP]
Lemon, T. and S. Cheshire, "Service Registration Protocol
for DNS-Based Service Discovery", Work in Progress,
Internet-Draft, draft-ietf-dnssd-srp-24, 29 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-
srp-24>.
[DRAFT-6874BIS]
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, 2 July
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
6man-rfc6874bis-09>.
[DRAFT-ZONE-UI]
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, 17
February 2024, <https://datatracker.ietf.org/doc/html/
draft-carpenter-6man-zone-ui-01>.
[RFC1630] 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, June 1994,
<https://www.rfc-editor.org/rfc/rfc1630>.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
December 1994, <https://www.rfc-editor.org/rfc/rfc1738>.
[RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for
Literal IPv6 Addresses in URL's", RFC 2732,
DOI 10.17487/RFC2732, December 1999,
<https://www.rfc-editor.org/rfc/rfc2732>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/rfc/rfc3493>.
Schinazi Expires 25 August 2024 [Page 10]
Internet-Draft Link-Local URI Connectivity February 2024
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/rfc/rfc3596>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005,
<https://www.rfc-editor.org/rfc/rfc3927>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/rfc/rfc4007>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/rfc/rfc6454>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/rfc/rfc6797>.
[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing
IPv6 Zone Identifiers in Address Literals and Uniform
Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,
February 2013, <https://www.rfc-editor.org/rfc/rfc6874>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>.
Schinazi Expires 25 August 2024 [Page 11]
Internet-Draft Link-Local URI Connectivity February 2024
[URI-ZONE-EARLY]
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, 24 October
2005, <https://datatracker.ietf.org/doc/html/draft-fenner-
literal-zone-02>.
[URL-HISTORY]
Ruby, S. and L. Masinter, "URL Problem Statement and
Directions", Work in Progress, Internet-Draft, draft-ruby-
url-problem-01, 11 January 2015,
<https://datatracker.ietf.org/doc/html/draft-ruby-url-
problem-01>.
[URL-LS] "URL-LS", WHATWG Living Standard,
<https://url.spec.whatwg.org/>.
[URL-ZONE-TRACKER1]
"Support IPv6 link-local addresses?",
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=27234>.
[URL-ZONE-TRACKER2]
"Support IPv6 zone identifiers",
<https://github.com/whatwg/url/issues/392>.
Acknowledgments
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
Email: dschinazi.ietf@gmail.com
Schinazi Expires 25 August 2024 [Page 12]
