Best Practices for Link-Local Connectivity in URI-Based Protocols
draft-schinazi-httpbis-link-local-uri-bcp-03

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]