]> Google LLC

1600 Amphitheatre Parkway Mountain View CA 94043 United States of America dschinazi.ietf@gmail.com

Web and Internet Transport HTTP IPv6 deployment URI URL mDNS 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 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 .

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 and retroactively backported to IPv4 . However, these addresses have limitations that make them unsuitable for use in URLs, as described in . This document obsoletes , a previous attempt at solving this problem that failed, as described in . This document provides recommendations that solve this problem in .

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 when, and only when, they appear in all capitals, as shown here.

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.

Limitations of Link-Local IPv4 Addresses In order to simplify implementations (and as recommended in ), 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.

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 () and requires that every host include a zone identifier when sending to any IPv6 link-local address. While 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 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.

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

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 and ). Over the years, the IETF maintained and evolved these specifications. In particular, support for IPv6 addresses was added in 1999 (see ). The IETF published an updated URI specification in 2005 (). 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 (). 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.

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. Over the course of 2012 and 2013, this led to the creation and publication of , an update to the IETF URL specification that defines how to represent IP zone identifiers in URLs. The majority of Web browsers did not implement this change. 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 complex to implement are listed in . After browsers decided not to implement it, the WHAT URL Living Standard was updated to mark the zone identifier as "intentionally omitted" (see ). The WHATWG subsequently rejected a request to add zone identifiers to their URL specification (see ).

Further Attempts After it was clear that most browser were not going to implement , another attempt was made to modify the URI RFC: . While this attempted to address some of the difficulties in implementing , 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 . 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.

Handling IPv6 Link-Local Addresses in Web Browsers Browsers operate differently from simple command-line tools such as ping, ssh or netcat. These 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 (), 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 (). The origin is propagated throughout the browser software: it is involved in whether to use a resource in the HTTP cache (), it is checked when deciding to allow sharing information (), it is used to save security policies (), and in many other cases beyond making socket operations. Additionally, all the portions of the origin are sent to the server in HTTP (). In contrast, the zone identifier is only valid and meaningful in a given node. As specified in , 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 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 on the wire). This significantly increases implementation complexity and security risks. Conversely, the proposal in 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. 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. Seperately, the proposal in 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.

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

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 ) 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. 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. Otherwise, devices can rely on mDNS conflict resolution () to ensure unique names, and then browse for the relevant service (). Following these recommendations solves the goals described in without requiring any changes in Web browser software.

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 relies on globally-registered names, and is therefore not available for link-local connectivity. Such link-local communication is therefore inherently not authenticated.

Fundamentally, mDNS has similar security properties as the underlying link-local address it resolves to.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. Informative References This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK] To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK] This document describes how the zone identifier of an IPv6 scoped address, defined as in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly. This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. [STANDARDS-TRACK] This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Apple Inc. Check Point Software This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax and Internationalized Resource Identifier specifications (RFC 3986, RFC 3987) accordingly, and obsoletes RFC 6874. Check Point Software 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. Discussion Venue This note is to be removed before publishing as an RFC. Discussion of this document takes place on the 6MAN mailing list (ipv6@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ipv6/ (https://mailarchive.ietf.org/arch/browse/ipv6/). The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community. This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK] IBM Adobe This document lays out the problem space of possibly conflicting standards between multiple organizations for URLs and things like them, and proposes some actions to resolve the conflicts. From a user or developer point of view, it makes no sense for there to be a proliferation of definitions of URL nor for there to be a proliferation of incompatible implementations. This shouldn't be a competitive feature. Therefore there is a need for the organizations involved to update and reconcile the various Internet Drafts, Recommendations, and Standards in this area.

Acknowledgments Some of the historical context in this document came from prior research documented in . The author would like to thank , , and for their prior work in this space. Additionally, the author thanks for their review and comments.