Entering IPv6 Zone Identifiers in User Interfaces
Internet-Draft draft-ietf-6man-zone-ui-02
Brian Carpenter
School of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
brian.e.carpenter@gmail.com
Robert M. Hinden
Check Point Software
959 Skyway Road
San Carlos, CA 94070
USA
bob.hinden@gmail.com
Internet
6MAN
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
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/.
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 [RFC4291] and [RFC5952]. The IPv6 Scoped Address Architecture specification [RFC4007] 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, for purposes described in that specification. Note that RFC 5952 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, 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. Today, 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 Windows host.
Such addresses are directly supported by socket API calls including "getaddrinfo()" [RFC3493].
Devices whose network stack does not support the RFC 4007 model of a human-readable zone identifier are out of scope for this document.
Some examples of use cases for entering such an address in 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 today be checked via "ping fe80::1234%eth0". If this succeeds, the user learns that the remote device is reachable via the interface named "eth0".
2. A software tool must sometimes be used to configure or reconfigure a device which only has a link-local address, again in a host with more than one active link interface. For example, a typical home router may today be configured via "192.168.178.1" but not via "fe80::1%eth0", if the tool in use does not support the input of zone identifiers.
3. Using a monitoring tool such as Wireshark, the user may need to specify a given link-local address on a given interface whose traffic is of interest. (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 recently defined the "OneNet Marine IPv6 Ethernet Networking Standard" [ONE-NET], which uses IPv6 link local addresses exclusively. Desired 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., [LL-HACK].
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.
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 RFC 4007 only specifies that they are coded in ASCII, without specifying a maximum length.
It should be noted that whereas some operating systems and network APIs support a default zone identifier as recommended by RFC 4007, 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 RFC 4007 model 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 Section 11.2 of RFC 4007, but not required. This possibility does not affect the UI requirement given below.
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 [RFC8925] [I-D.link-v6ops-6mops], 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 obsoletes [RFC6874], which implementors of web browsers have determined is impracticable to support [I-D.schinazi-httpbis-link-local-uri-bcp], and replaces it by a generic UI requirement described below. Note that obsoleting RFC 6874 reverts the update that it made to the URI syntax defined by [RFC3986].
Open Issue
This document effectively extends RFC 4007. Should this be recorded as a formal update to RFC 4007?
Normative Terminology
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 [BCP14] 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 SHOULD provide a means for entering a link-local address or a scoped multicast address and selecting a zone identifer as specified by [RFC4007] (typically, an interface identifier as defined by the operating system).
Ideally, the UI will support the complete format specified by RFC 4007 (e.g., "fe80::1%eth0").
If this is impossible for practical reasons, the UI could 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 could support two separate input fields (e.g., "fe80::1" in one box, "eth0" in another), or selection from a list of active zone identifiers.
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 either be converted 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 [RFC6454]. Therefore, this approach does not resolve the issue of how browsers should support link-local addresses, discussed further in [I-D.schinazi-httpbis-link-local-uri-bcp]. Because of this, the recommendations and normative statements in this document do not apply to web browsers.
Security Considerations
As explained in [RFC4007], zone identifiers are of local significance and must not be sent on the wire. In particular, see the final security consideration of RFC 4007, which indicates that software should not trust packets that contain textual non-global addresses as data. Software that obtains a zone identifier through a UI should therefore not transmit it further.
There is no formal limit on the length of the zone identifier string in RFC 4007. A UI implementation should apply a reasonable length limit when inputting a zone identifier, in order to minimize the risk of a buffer overrun. For example, a limit to 16 ASCII characters would correspond to the existing limit on Linux interface names.
RFC 4007 does not specify the character set allowed in a zone identifier. An implementation should not allow ASCII NULL characters in a zone identifier string as this could cause inconsistencies in subsequent string processing.
IANA Considerations
This document makes no request of IANA.
References
Normative References
Informative References
[ONE-NET]

The OneNet Standard for IP Networking of Marine Electronic Devices
NMEA
2023
[LL-HACK]

Snippets: IPv6 link-local connect hack
Peter Jin
2021
[RFC4291]
[RFC5952]
[RFC4007]
[RFC3493]
[RFC8925]
[I-D.link-v6ops-6mops]
[RFC6874]
[I-D.schinazi-httpbis-link-local-uri-bcp]
[RFC3986]
[RFC6454]
[I-D.ietf-6man-rfc6874bis]
Change log
- draft-carpenter-6man-zone-ui-00, 2024-01-15:
  - Initial version
- draft-carpenter-6man-zone-ui-01, 2024-02-17:
  - Weakened use of normative keywords to allow flexibility
- draft-carpenter-6man-zone-ui-02, 2024-02-21:
  - Note that RFC 6874 was found unimplementable.
  - Note that HTTP "origin" issues are not resolved.
  - Cite new httpbis draft.
  - Open issue: Updates: 4007 ?
- draft-carpenter-6man-zone-ui-03, 2024-03-01:
  - Small clarifications.
  - Updated some references.
- draft-carpenter-6man-zone-ui-04, 2024-04-01:
  - Mentioned scoped multicast addresses.
  - Mentioned inet_pton() issue.
  - Added reference.
- draft-ietf-6man-zone-ui-00, 2024-06-28:
  - Adopted by WG.
  - Clarified inapplicability to browsers.
- draft-ietf-6man-zone-ui-01, 2024-08-05:
  - Clarified extensions of RFC 4007.
  - Clarified relationship with RFC 5952
- draft-ietf-6man-zone-ui-02, 2024-09-05:
  - Clarified non-impact on URI syntax.
Acknowledgements
This document owes a lot to the previous discussions that led to RFC 6874 and to the abandoned draft [I-D.ietf-6man-rfc6874bis].
Useful comments were received from Nick Buraglio, Martin J. Dürst, Toerless Eckert, David Farmer, Brian Haberman, Nate Karstens, Jen Linkova, Eduard Metz, Gyan Mishra, Ole Troan, David Schinazi, Michael Sweet, Martin Thomson, Éric Vyncke, and other participants in the 6MAN WG.