Entering IPv6 Zone Identifiers in User Interfaces
obsoletes
- rfc-6874 — Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
updates
Extracted elements (17)
Cut-and-paste is the preferred mechanism for transferring complete IPv6 link-local addresses between UIs because such addresses (e.g., 'fe80::8d0f:7f26:f5c8:780b%enx525400d5e0fb') are long hexadecimal strings where manual re-entry is highly error prone.
RFC 6874 attempted to encode zone identifiers in URIs (using percent-encoding), but browser implementors found this impracticable. RFC 9844 replaces that URI-specific approach with a generic UI requirement, making zone identifier support achievable for all non-browser tools without requiring URI syntax changes.
Zone identifiers have purely local meaning within the node that defines them and are completely meaningless to any other node. They are currently meaningful only for link-local unicast and scoped multicast addresses, though future uses may be defined.
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 using getaddrinfo(), or by splitting into two strings and applying inet_pton() and if_nametoindex() successively.
Linux does not support a default zone identifier as RFC 4007 recommends, making zone identifier support in UIs especially critical on that platform because a link-local address without a zone index cannot be used in the Linux socket API.
RFC 7622 (XMPP Address Format) and RFC 8089 (the 'file' URI scheme) are updated by this document solely to delete their references to the now-obsoleted RFC 6874.
This document obsoletes RFC 6874, which browser implementors determined was impracticable to support. Obsoleting RFC 6874 reverts its change to the URI syntax defined by RFC 3986, so RFC 3986 is no longer updated by RFC 6874.
A UI that allows or requires entry of an IPv6 address other than a global unicast address MUST provide a means for entering a link-local address or scoped multicast address and selecting a zone identifier as specified by RFC 4007.
If both '%' and an alternative delimiter are impractical, the UI MAY provide two separate input fields, selection from a list of active zone identifiers, or a separate command-line parameter for the zone identifier.
If using '%' is impossible for practical reasons, the UI MAY support an alternative delimiter in place of '%'; the hyphen '-' is suggested (e.g., 'fe80::1-eth0').
The recommendations and normative statements in this document do NOT apply to URIs fetched by web browsers, because the zone identifier approach does not resolve how browsers should handle the HTTP origin model for link-local addresses.
The UI SHOULD support the complete format specified by RFC 4007, e.g., 'fe80::1%eth0', using '%' as the delimiter between the IPv6 address and zone identifier.
A zone identifier is a text string, defined in RFC 4007, that qualifies a limited-scope IPv6 address (especially link-local unicast) by identifying the network interface. It is concatenated to the address using '%' as delimiter, e.g., 'fe80::1234%eth0' (Linux) or 'fe80::4321%7' (Windows).
The zone identifier string is converted to a numeric interface index by the host operating system, typically via the socket API function getaddrinfo(). Alternatively, the underlying interface number as a decimal integer may be used directly.
RFC 4007 does not restrict the character set for zone identifiers. UI implementations should validate zone identifiers for their environment; for example, ASCII NUL characters should not be allowed as they could cause inconsistencies in string processing.
RFC 4007 imposes no formal limit on zone identifier string length. A UI implementation should apply an appropriate length limit (typically the OS limit on interface names) when inputting a zone identifier to minimize the risk of a buffer overrun.
Zone identifiers are of local significance only and MUST NOT be sent on the wire. Software that obtains a zone identifier through a UI should not transmit it further, as RFC 4007 indicates software should not trust packets containing textual non-global addresses as data.