School of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand brian.e.carpenter@gmail.com

Check Point Software

959 Skyway Road San Carlos CA 94070 United States of America bob.hinden@gmail.com

INT 6man This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture specification (RFC 4007), should be entered into a user interface. This document obsoletes RFC 6874 and updates RFCs 4007, 7622, and 8089.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 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 () 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

• .  Introduction
• .  Use Cases
• .  Relationship to Other Documents
• .  Requirements Language
• .  Specification
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction A number of software tools require or permit the user to enter an IPv6 address via a user interface (UI). The standard literal text format for an IPv6 address is defined by and . The IPv6 Scoped Address Architecture specification extends the text representation of limited-scope IPv6 addresses, in particular link-local unicast addresses and multicast addresses with less than global scope, such that a zone identifier may be concatenated to an address. Note that does not mention this extension. Zone identifiers are especially useful in contexts in which literal addresses are typically used, for example, during fault diagnosis or device configuration (where a device may be physical or virtual) when it may be essential to specify which interface is used for sending to a link-local address. It should be noted that zone identifiers have purely local meaning within the node in which they are defined, usually being the same as IPv6 interface names. They are completely meaningless for any other node. At the time of writing, they are meaningful only when attached to link-local unicast and scoped multicast addresses, but it is possible that other uses might be defined in the future. Examples of a link-local unicast address qualified by a zone identifier are "fe80::1234%eth0" on a Linux host or "fe80::4321%7" on a Microsoft Windows host. Such addresses are directly supported by socket API calls including "getaddrinfo()" . Devices whose network stack does not support the model of a human-readable zone identifier described in are out of scope for this document.

Use Cases Some examples of use cases for entering an address that includes a zone identifier into a UI are as follows:

1. A software tool may be used for simple debugging actions involving link-local addresses on a host with more than one active link interface. For example, the functioning of an interface and the existence of a device may be checked via "ping fe80::1234%eth0". If this succeeds, the user learns that the other device is reachable via the interface named "eth0".
2. A software tool must sometimes be used to configure or reconfigure a device that only has a link-local address, again in a host with more than one active link interface. For example, a typical home router may be configured via a well-known private address such as "192.168.178.1" but not via "fe80::1%eth0", if the tool in use does not support the input of zone identifiers. More generally, link-local addresses need to be entered in network management UIs for use in formats such as YANG .
3. Using a monitoring tool such as a network sniffer, the user may need to specify a given link-local address on a given interface whose traffic is of interest. (For example, at the time of writing, Wireshark supports capture from multiple interfaces but does not appear to support the zone identifier in a display filter.)
4. The Microsoft Web Services for Devices (WSD) virtual printer port mechanism can present the user with an IPv6 link-local address such as "fe80::823b:f9ff:fe7b:d9dc%10" in which the zone identifier is present but is not recognized by appropriate software.
5. The National Marine Electronics Association (NMEA) has defined the "OneNet Marine IPv6 Ethernet Networking Standard" , which uses IPv6 link-local addresses exclusively. Proposed improvements to the standard include a web page for device configuration using link-local addresses.

Such requirements have already spawned hacks to work around current limitations (e.g., the hack described in , which is no longer maintained and has been archived). For all such use cases, it is highly desirable that a complete IPv6 link-local address can be cut and pasted from one UI (such as the output from a system command) to another. Since such addresses may include quite long hexadecimal strings, for example, "fe80::8d0f:7f26:f5c8:780b%enx525400d5e0fb", any solution except cut-and-paste is highly error prone.

Relationship to Other Documents The use cases listed above apply to relatively simple actions on end systems. The zone identifiers that can be used are limited by the host operating system, since only specifies that they are text strings, without specifying a maximum length or syntax. As explains, each zone identifier corresponds to a numerical zone index that qualifies a link-local address. It should be noted that whereas some operating systems and network APIs support a default zone identifier as recommended by , others, including Linux, do not, and for them a solution is particularly important, since a link-local address without a zone index cannot be used in the Linux socket API. The model in assumes that the human-readable zone identifier is mapped by the operating system into a numeric interface index. Typically, this mapping is performed by the socket API, e.g., by "getaddrinfo()". The mapping between the human-readable zone identifier string and the numeric value is a host-specific function that varies between operating systems. The present document is concerned only with the human-readable string that is typically displayed in an operating system's user interface. However, in most operating systems, it is possible to use the underlying interface number, represented as a decimal integer, as an equivalent to the human-readable string. This is recommended by , but it is not required. This possibility does not affect the UI requirement given in this document. As IPv6 deployment becomes more widespread, the lack of a solution for handling complete link-local addresses in all tools is becoming an acute problem for increasing numbers of operational and support personnel. It will become critical as IPv6-only or IPv6-mostly networks , with nodes lacking native IPv4 support, appear. For example, the NMEA use case mentioned above is an immediate requirement. This is the principal reason for documenting this requirement now. This document completely obsoletes , which implementors of web browsers have determined is impracticable to support , and replaces it with a generic UI requirement. Note that obsoleting reverts the change that it made to the URI syntax defined by , so is no longer updated by . As far as is known, this change will have no significant impact on non-browser deployments of URIs. This document also updates and by deleting their references to . It also updates by adding a new requirement that user interfaces support the zone identifier as described in .

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

Specification A user interface (UI) that allows or requires the user to enter an IPv6 address other than a global unicast address MUST provide a means for entering a link-local address or a scoped multicast address and selecting a zone identifier as specified by (typically, an interface identifier as defined by the operating system). In this case, the UI SHOULD support the complete format specified by (e.g., "fe80::1%eth0"). If this is impossible for practical reasons, the UI MAY support an alternative delimiter in place of "%". The hyphen ("-") is suggested (e.g., "fe80::1-eth0"). If this too is impossible for practical reasons, the UI MAY provide two separate input fields (e.g., "fe80::1" in one box and "eth0" in another), selection from a list of active zone identifiers, or a separate command-line parameter for the zone identifier. The program providing the UI will then store the address and the zone identifier, converting the latter to an interface index (typically via the socket API). A faulty zone identifier will be detected when attempting to convert it, and this should be reported to the user as an error. The resulting interface index will be used for any subsequent socket calls using the link-local address. Note that an address string such as "fe80::1%eth0" cannot be converted to binary by the POSIX socket API function "inet_pton()" . It must be converted either by using "getaddrinfo()" or by splitting it into two strings and using "inet_pton()" and "if_nametoindex()" successively, in order to obtain the required interface index value. In this model, the zone identifier is considered independently of the IPv6 address itself. However, this does not in itself resolve the difficulties in considering the zone identifier as part of the HTTP origin model . Therefore, this approach does not resolve the issue of how browsers should support link-local addresses, which is discussed further in . Because of this, the recommendations and normative statements in this document do not apply to URIs fetched by web browsers.

Security Considerations As explained in , zone identifiers are of local significance only and must not be sent on the wire. In particular, see the final security consideration of , which indicates that software should not trust packets that contain textual non-global addresses as data. Therefore, software that obtains a zone identifier through a UI should not transmit it further. There is no formal limit on the length of the zone identifier string in . A UI implementation should apply an appropriate length limit when inputting a zone identifier, in order to minimize the risk of a buffer overrun. Typically, this limit would be the same as the host operating system's limit on interface names. does not specify or restrict the character set allowed in a zone identifier. Therefore, each implementation processing zone identifiers needs to make checks appropriate for the environment it is used in. For example, a UI implementation should not allow ASCII NUL characters in a zone identifier string as this could cause inconsistencies in subsequent string processing.

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. 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] This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] 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. Informative References Energy Sciences Network RIPE NCC Google This document discusses a deployment scenario called "an IPv6-Mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). Work in Progress Google LLC 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. Work in Progress IEEE This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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. 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] 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] 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. Apple Inc. Check Point Software Work in Progress This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. This document provides a more complete specification of the "file" Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738. It defines a common syntax that is intended to interoperate across the broad spectrum of existing usages. At the same time, it notes some other current practices around the use of file URIs. This document specifies a DHCPv4 option to indicate that a host supports an IPv6-only mode and is willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. It also updates RFC 2563 to specify DHCPv4 server behavior when the server receives a DHCPDISCOVER not containing the Auto-Configure option but containing the new option defined in this document.

Acknowledgements This document owes a lot to the previous discussions that led to and to the expired Internet-Draft . Useful comments were received from , , , , , , , , , , , , , , , , , , , and other participants in the 6MAN WG.

Authors' Addresses

School of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand brian.e.carpenter@gmail.com

Check Point Software

959 Skyway Road San Carlos CA 94070 United States of America bob.hinden@gmail.com