RFC 9844

Entering IPv6 Zone Identifiers in User Interfaces

📅 published August 2025, from ietf

RFC 9844: Entering IPv6 Zone Identifiers in User Interfaces 🎀✨

Okay bestie, let's get into it! 💖 This one is from the IETF, and it's a Standards Track doc, which means it's the real deal. 💅

Here's the title-block tea 🫖:

  • Authors: B. Carpenter (Univ. of Auckland) and R. Hinden (Check Point Software) 🧚
  • Category: Standards Track 🔥
  • Date: August 2025 🌸
  • Obsoletes: RFC 6874 💀 (it's getting replaced, periodt)
  • Updates: RFCs 4007, 7622, and 8089 🦋
  • ISSN: 2070-1721 ⭐

The whole vibe is about how you type an IPv6 zone identifier into a user interface, so you can paste a full link-local address into a tool and have it actually work. 🫶

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. 💅

Info about the current status of this document, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc9844. 🌈

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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since 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
2.  Use Cases
3.  Relationship to Other Documents
4.  Requirements Language
5.  Specification
6.  Security Considerations
7.  IANA Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌸

Okay so, a bunch of software tools need you to type in an IPv6 address through a user interface (UI). 💻 The standard text format for an IPv6 address comes from [RFC4291] and [RFC5952]. 🧚 Then the IPv6 Scoped Address Architecture spec, [RFC4007], extends that text format for addresses with limited scope, like link-local unicast addresses and multicast addresses with less than global scope. 🦋 It lets you stick a zone identifier onto the end of the address. Also, [RFC5952] doesn't mention this extension at all, which is kind of a plot twist 🙈.

Zone identifiers are super useful for the stuff people do with literal addresses, like fault diagnosis or device configuration (where the device might be physical or virtual). 🔥 Sometimes it's essential to say which interface you want to use to send to a link-local address. 💅 Here's the thing though: a zone identifier only has purely local meaning inside the node where it's defined. It's usually the same as an IPv6 interface name. 🫖 It's completely meaningless for any other node 💀. As of writing, zone identifiers only mean something when attached to link-local unicast and scoped multicast addresses, but other uses might be defined in the future. ✨

Some examples of a link-local unicast address with a zone identifier are "fe80::1234%eth0" on a Linux host and "fe80::4321%7" on a Microsoft Windows host. 🎀

Those addresses are directly supported by socket API calls, including "getaddrinfo()" [RFC3493]. 🧚

Devices whose network stack doesn't support the human-readable zone identifier model described in [RFC4007] are out of scope for this document. 🙅‍♀️

2. Use Cases 💖

Here are some examples of when you'd want to enter an address with a zone identifier into a UI:

  1. A software tool might be used for simple debugging on link-local addresses, on a host with more than one active link interface. 🔍 For example, you can check an interface and whether a device exists with "ping fe80::1234%eth0". If that works, you learn the other device is reachable through the interface named "eth0". 🦋
  2. A software tool sometimes has to configure or reconfigure a device that only has a link-local address, again on a host with more than one active link interface. 🏠 For example, a typical home router might be set up at a well-known private address [RFC1918] like "192.168.178.1", but not at "fe80::1%eth0", if the tool doesn't support zone identifiers. 😭 More generally, link-local addresses need to be entered in network management UIs for formats like YANG [RFC6991]. 🫶
  3. With a monitoring tool like a network sniffer, you might need to specify a given link-local address on a given interface you care about. 👀 (For example, at the time of writing, Wireshark can capture from multiple interfaces, but it doesn't seem to support zone identifiers in a display filter. 💀)
  4. The Microsoft Web Services for Devices (WSD) virtual printer port mechanism can show you an IPv6 link-local address like "fe80::823b:f9ff:fe7b:d9dc%10", where the zone identifier is there but the software doesn't recognize it. 🖨️😭
  5. The National Marine Electronics Association (NMEA) defined the "OneNet Marine IPv6 Ethernet Networking Standard" [ONE-NET], which uses IPv6 link-local addresses exclusively. 🌊 Proposed improvements include a web page for device configuration using link-local addresses. 🧚

These kinds of needs have already led to hacks that work around the current limitations, like the one described in [LL-HACK]. That hack is no longer maintained and has been archived. 💀

For all of these use cases, it's highly desirable that you can cut and paste a complete IPv6 link-local address from one UI (like the output of a system command) into another. 💖 Those addresses can be super long hex strings, like "fe80::8d0f:7f26:f5c8:780b%enx525400d5e0fb", so anything except cut-and-paste is highly error prone. 🙈

3. Relationship to Other Documents 🦋

The use cases above are for relatively simple actions on end systems. 💅 The zone identifiers you can use are limited by the host operating system, since [RFC4007] only says they're text strings and doesn't specify a maximum length or syntax. 🫖 As [RFC4007] explains, each zone identifier corresponds to a numerical zone index that qualifies a link-local address. ✨

Some operating systems and network APIs support a default zone identifier, as recommended by [RFC4007]. Others, including Linux, don't. For those, a solution is especially important, since a link-local address without a zone index can't be used in the Linux socket API. 🐧💀

The model in [RFC4007] assumes the human-readable zone identifier gets mapped by the operating system into a numeric interface index. 🔢 Usually the socket API does this mapping, for example via "getaddrinfo()". 🧚 That mapping between the human-readable string and the number is a host-specific function, and it varies between operating systems. 🌈 This document only cares about the human-readable string that usually shows up in an OS's user interface. 💜 Still, on most operating systems you can use the underlying interface number, written as a decimal integer, as an equivalent to the human-readable string. 🔢 Section 11.2 of [RFC4007] recommends this, but it isn't required. 🙃 This possibility doesn't change the UI requirement given in this document. 🎀

As IPv6 deployment gets more widespread, not having a way to handle complete link-local addresses in all tools is becoming a real problem for more and more ops and support folks. 😭 It'll become critical as IPv6-only or IPv6-mostly networks [RFC8925] [IPv6-MOSTLY] show up, with nodes that don't have native IPv4 support. 🌐 The NMEA use case above is an immediate requirement, which is the main reason for documenting this now. 🔥

This document completely obsoletes [RFC6874]. Web browser implementers determined that supporting it is impracticable [LINK-LOCAL-URI], so this document replaces it with a generic UI requirement. 💅 Obsoleting [RFC6874] also reverts the change it made to the URI syntax defined by [RFC3986], so [RFC3986] is no longer updated by [RFC6874]. 🦋 As far as is known, this change won't have a significant impact on non-browser deployments of URIs. ✨

This document also updates [RFC7622] and [RFC8089] by deleting their references to [RFC6874]. 🫶

It also updates [RFC4007] by adding a new requirement that user interfaces support the zone identifier as described in Section 5. 💖

4. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀✨

To be continued in Part 2… 🦋 Stay tuned bestie, the spec gets even juicier from Section 5 onward! 💅

5. Specification ✨

Okay bestie, this is where the UI rules come in 💅. Any UI that lets someone enter an IPv6 address that is not a global unicast address MUST give them a way to enter a link-local address or a scoped multicast address and to pick a zone identifier, as [RFC4007] describes. That zone identifier is usually an interface identifier from the operating system 🦋.

In this case, the UI SHOULD support the complete format from [RFC4007], like fe80::1%eth0 🌸.

If that's impossible for practical reasons, the UI MAY support a different delimiter instead of %. The hyphen (-) is suggested, like fe80::1-eth0 🍓.

If that's also impossible for practical reasons, the UI MAY do any of these instead: two separate input fields (like fe80::1 in one box and eth0 in another), a selection from a list of active zone identifiers, or a separate command-line parameter for the zone identifier 🧚.

Then the program stores the address and the zone identifier, and converts the zone identifier to an interface index, usually through the socket API ✨. If the zone identifier is faulty, that shows up when you try to convert it, and it should be reported to the user as an error 🙈. The resulting interface index gets used for any later socket calls that use that link-local address 💜.

Heads up: the POSIX socket function inet_pton() [POSIX] can't convert a string like fe80::1%eth0 into binary. It must be converted either with getaddrinfo(), or by splitting the string into two parts and calling inet_pton() and then if_nametoindex() one after the other, so you end up with the interface index you need 😭.

Here's the big tea ☕. The zone identifier is treated separately from the IPv6 address itself. But that alone doesn't fix the trouble of treating the zone identifier as part of the HTTP origin model [RFC6454]. So this approach doesn't solve how browsers should support link-local addresses either. That's discussed more in [LINK-LOCAL-URI]. Because of all this, the recommendations and normative statements in this document do not apply to URIs fetched by web browsers 💀.

6. Security Considerations 🔥

Pay attention, this part is serious. As [RFC4007] explains, zone identifiers only have local significance and must not be sent on the wire 🚫. Look especially at the final security consideration in [RFC4007], which says software should not trust packets that contain textual non-global addresses as data. So software that gets a zone identifier through a UI should not pass it along any further 🔐.

There's no formal length limit on the zone identifier string in [RFC4007]. So a UI implementation should apply a sensible length limit when someone types one in, to lower the risk of a buffer overrun 😱. Usually that limit should match the host operating system's limit on interface names 🌈.

[RFC4007] doesn't specify or restrict which characters can show up in a zone identifier. So every implementation that processes zone identifiers needs to do checks that fit the environment it's running in 👑. For example, a UI implementation should not allow ASCII NUL characters in a zone identifier string, because that could cause inconsistencies in later string processing 🙈.

7. IANA Considerations 🦋

This document has no IANA actions. Nothing to see here for the registry people 💅.

8. References 📚

8.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/info/rfc2119>.

[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/info/rfc4007>.

[RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
           Architecture", RFC 4291, DOI 10.17487/RFC4291, February
           2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
           Address Text Representation", RFC 5952,
           DOI 10.17487/RFC5952, August 2010,
           <https://www.rfc-editor.org/info/rfc5952>.

[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/info/rfc8174>.

8.2. Informative References

[IPv6-MOSTLY]
           Buraglio, N., Caletka, O., and J. Linkova, "IPv6-Mostly
           Networks: Deployment and Operations Considerations", Work
           in Progress, Internet-Draft, draft-ietf-v6ops-6mops-01, 3
           March 2025, <https://datatracker.ietf.org/doc/html/draft-
           ietf-v6ops-6mops-01>.

[LINK-LOCAL-URI]
           Schinazi, D., "Best Practices for Link-Local Connectivity
           in URI-Based Protocols", Work in Progress, Internet-Draft,
           draft-schinazi-httpbis-link-local-uri-bcp-03, 22 February
           2024, <https://datatracker.ietf.org/doc/html/draft-
           schinazi-httpbis-link-local-uri-bcp-03>.

[LL-HACK]  Jin, P., "Snippets: IPv6 link-local connect hack", 2021,
           <https://web.archive.org/web/20210725030713/
           https://website.peterjin.org/wiki/
           Snippets:IPv6_link_local_connect_hack>.

[ONE-NET]  NMEA, "OneNet Marine IPv6 Ethernet Networking Standard",
           2025, <https://www.nmea.org/nmea-onenet.html>.

[POSIX]    IEEE, "IEEE/Open Group Standard for Information
           Technology--Portable Operating System Interface
           (POSIX(TM)) Base Specifications, Issue 8", IEEE
           Std 1003.1-2024, DOI 10.1109/IEEESTD.2024.10555529, June
           2024, <https://doi.org/10.1109/IEEESTD.2024.10555529>.

[RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
           J., and E. Lear, "Address Allocation for Private
           Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
           February 1996, <https://www.rfc-editor.org/info/rfc1918>.

[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/info/rfc3493>.

[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/info/rfc3986>.

[RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
           DOI 10.17487/RFC6454, December 2011,
           <https://www.rfc-editor.org/info/rfc6454>.

[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/info/rfc6874>.

[RFC6874bis]
           Carpenter, B., Cheshire, S., and R. 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>.

[RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
           RFC 6991, DOI 10.17487/RFC6991, July 2013,
           <https://www.rfc-editor.org/info/rfc6991>.

[RFC7622]  Saint-Andre, P., "Extensible Messaging and Presence
           Protocol (XMPP): Address Format", RFC 7622,
           DOI 10.17487/RFC7622, September 2015,
           <https://www.rfc-editor.org/info/rfc7622>.

[RFC8089]  Kerwin, M., "The "file" URI Scheme", RFC 8089,
           DOI 10.17487/RFC8089, February 2017,
           <https://www.rfc-editor.org/info/rfc8089>.

[RFC8925]  Colitti, L., Linkova, J., Richardson, M., and T.
           Mrugalski, "IPv6-Only Preferred Option for DHCPv4",
           RFC 8925, DOI 10.17487/RFC8925, October 2020,
           <https://www.rfc-editor.org/info/rfc8925>.

Acknowledgements 🫶

This document owes a lot to the earlier discussions that led to [RFC6874], and to the expired Internet-Draft [RFC6874bis] 💖.

Huge thanks to everyone who left useful comments: Erik Auerswald, Nick Buraglio, Martin J. Dürst, Toerless Eckert, David Farmer, Brian Haberman, Nate Karstens, Tero Kivinen, Erik Kline, Jen Linkova, Eduard Metz, Gyan Mishra, David Schinazi, Jürgen Schönwälder, Michael Sweet, Martin Thomson, Ole Troan, Éric Vyncke, Magnus Westerlund, and the other participants in the 6MAN WG 👑✨.

Authors' Addresses 💌

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


Robert M. Hinden
Check Point Software
959 Skyway Road
San Carlos, CA 94070
United States of America
Email: bob.hinden@gmail.com
📦 where this page comes from