<?xml<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc>
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<?rfc symrefs="yes"?>
<!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate --> rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-6man-zone-ui-10" number="9844" consensus="true" ipr="trust200902" obsoletes="6874" updates ="4007, updates="4007, 7622, 8089" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.44.0 [rfced] This document updates RFC 7622, which has some errata.
Please review the errata reported for RFC 7622 and let us know if
you confirm our opinion that none of them are relevant to the content
of this document.
Link to errata for RFC 7622:
https://www.rfc-editor.org/errata/rfc7622
-->
<front>
<title abbrev="IPv6 Zone IDs in UIs">Entering IPv6 Zone Identifiers in User Interfaces</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-zone-ui-10"/> name="RFC" value="9844"/>
<author initials="B." surname="Carpenter" fullname="Brian Carpenter">
<organization abbrev="Univ. of Auckland"/>
<address>
<postal>
<postalLine>School
<street>School of Computer Science</postalLine>
<postalLine>University Science</street>
<street>University of Auckland</postalLine>
<postalLine>PB 92019</postalLine>
<postalLine>Auckland 1142</postalLine>
<postalLine>New Zealand</postalLine> Auckland</street>
<street>PB 92019</street>
<city>Auckland 1142</city>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
<author fullname="Robert M. Hinden" initials="R" surname="Hinden">
<organization>Check Point Software</organization>
<address>
<postal>
<postalLine>959
<street>959 Skyway Road</postalLine>
<postalLine>San Carlos, CA 94070</postalLine>
<postalLine>USA</postalLine> Road</street>
<city>San Carlos</city><region>CA</region><code>94070</code>
<country>United States of America</country>
</postal>
<phone/>
<email>bob.hinden@gmail.com</email>
</address>
</author>
<area>Internet</area>
<workgroup>6MAN</workgroup>
<date month="August" year="2025"/>
<area>INT</area>
<workgroup>6man</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on http://www.rfc-editor.org/rfcsearch.html.
<keyword>example</keyword> https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract>
<t>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. It This document obsoletes RFC 6874 and updates RFC RFCs 4007, RFC 7622 7622, and RFC 8089.
</t> 8089.</t>
</abstract>
<note removeInRFC="true">
<name>Discussion Venue</name>
<t>Discussion of this document takes place on the
6MAN mailing list (ipv6@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ipv6/">https://mailarchive.ietf.org/arch/browse/ipv6/</eref>.</t>
</note>
</front>
<middle>
<section anchor="intro" numbered="true">
<name>Introduction</name>
<t>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 <xref target="RFC4291"/>
and <xref target="RFC5952"/>.
The IPv6 Scoped Address Architecture specification <xref target="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. Note that RFC 5952 <xref target="RFC5952"/> does not mention this extension.</t>
<t>Zone identifiers are especially
useful in contexts in which literal addresses are typically used,
for example example, during fault diagnosis or device configuration
(where a device may be physical or virtual), 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. </t>
<t>Examples of a link-local unicast address qualified by a zone
identifier are "fe80::1234%eth0" on a Linux host, host or
"fe80::4321%7" on a Microsoft Windows host.</t>
<t>Such addresses are directly supported by socket API calls
including "getaddrinfo()" <xref target="RFC3493"/>.</t>
<t>Devices whose network stack does not support
the RFC 4007 model of a human-readable zone identifier described in <xref target="RFC4007"/>
are out of scope for this document.</t>
</section>
<section anchor="uses" numbered="true">
<name>Use Cases</name>
<t>Some examples of use cases for entering an address
that includes a zone identifier
into a UI are as follows:</t>
<ol><li>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".</li>
<li>A software tool must sometimes be used to configure or reconfigure a
device which 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 <xref target="RFC1918"/>
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 <xref target="RFC6991"/>.</li>
<li>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,
interfaces but does not appear to support the zone
identifier in a display filter.)</li>
<li>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, present
but is not recognized by appropriate software.</li>
<!-- [rfced] The title for [ONE-NET] in the text and the reference entry are
different. Which is correct? We see both forms used in the URL in the
reference entry. Let us know which form to use consistently in this
document.
Original:
5. The National Marine Electronics Association (NMEA) has defined
the "OneNet Marine IPv6 Ethernet Networking Standard" [ONE-NET],
which uses IPv6 link-local addresses exclusively.
...
[ONE-NET] NMEA, "The OneNet Standard for IP Networking of Marine
Electronic Devices", 2023,
<https://www.nmea.org/nmea-onenet.html>.
-->
<li>The National Marine Electronics Association (NMEA) has defined
the "OneNet Marine IPv6 Ethernet Networking Standard" <xref target="ONE-NET"/>,
which uses IPv6 link-local addresses exclusively. Proposed improvements to
the standard include a web page for device configuration using link-local
addresses.</li>
</ol>
<!-- [rfced] How may we update "e.g., [LL-HACK]"?
Original:
Such requirements have already spawned hacks to work around current
limitations (e.g., [LL-HACK], which is no longer maintained and has
been archived).
Perhaps:
Such requirements have already spawned hacks to work around current
limitations (e.g., the Snippets:IPv6 link local connect hack [LL-HACK],
which is no longer maintained and has been archived).
Or:
Such requirements have already spawned hacks to work around current
limitations (e.g., the hack described in [LL-HACK], which is no longer
maintained and has been archived).
-->
<t>Such requirements have already spawned
hacks to work around current limitations (e.g., <xref target="LL-HACK"/>,
which is no longer maintained and has been archived).</t>
<t>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 example, "fe80::8d0f:7f26:f5c8:780b%enx525400d5e0fb", any solution except
cut-and-paste is highly error prone.</t>
</section>
<section anchor="rfcrel" numbered="true">
<name>Relationship to Other Documents</name>
<t>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 <xref target="RFC4007"/> only specifies
that they are text strings, without specifying a maximum length or syntax.
As RFC 4007 <xref target="RFC4007"/> explains, each zone identifier corresponds to a
numerical zone index that qualifies a link-local address.</t>
<t>It should be noted that whereas some operating systems and network APIs
support a default zone identifier as recommended by RFC 4007, <xref target="RFC4007"/>,
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.</t>
<t>The RFC 4007 model in <xref target="RFC4007"/> 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. 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 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, <xref target="RFC4007" section="11.2"/>, but it is not required.
This possibility does not affect the UI requirement given in this document.</t>
<t>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
<xref target="RFC8925"/> <xref target="I-D.ietf-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.</t>
<t>This document completely obsoletes <xref target="RFC6874"/>, which implementors
of web browsers have determined is impracticable to support
<xref target="I-D.schinazi-httpbis-link-local-uri-bcp"/>, and replaces it
by
with a generic UI requirement. Note that obsoleting
RFC 6874
<xref target="RFC6874"/> reverts the change that it made to the URI syntax defined by
<xref target="RFC3986"/>, so RFC 3986 <xref target="RFC3986"/> is no longer updated by RFC 6874. <xref target="RFC6874"/>.
As far as is known, this change will have no significant impact on
non-browser deployments of URIs.</t>
<t>This document also updates <xref target="RFC7622"/> and <xref target="RFC8089"/>
by deleting their references to RFC 6874.</t> <xref target="RFC6874"/>.</t>
<t>It also updates <xref target="RFC4007"/> by adding a new requirement that
user interfaces support the zone identifier as described in <xref target="spec"/>.</t>
</section>
<section anchor="norm" numbered="true">
<name>Normative Terminology</name>
<t>The
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="BCP14"/> target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t> here.
</t>
</section>
<section anchor="spec" numbered="true">
<name>Specification</name>
<t>A user interface (UI) that allows or requires the user to enter an
IPv6 address other than a global unicast address <bcp14>MUST</bcp14> provide a means
for entering a link-local address or a scoped multicast address and
selecting a zone identifier as specified by <xref target="RFC4007"/> (typically, an
interface identifier as defined by the operating system).</t>
<t>In this case, the UI <bcp14>SHOULD</bcp14> support the complete
format specified by RFC 4007 <xref target="RFC4007"/> (e.g., "fe80::1%eth0").</t>
<t>If this is impossible for practical reasons, the UI <bcp14>MAY</bcp14>
support an alternative delimiter in place of "%".
The hyphen ("-") is suggested (e.g., "fe80::1-eth0").</t>
<t>If this too is impossible for practical reasons, the UI
<bcp14>MAY</bcp14> provide two separate input fields (e.g., "fe80::1" in
one box, box and "eth0" in another), selection from a list of
active zone identifiers,
or a separate command line command-line parameter for the zone identifier.</t>
<t>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
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. </t>
<t>Note that an address string such as "fe80::1%eth0" cannot be
converted to binary by the POSIX socket API function "inet_pton()"
<xref target="POSIX"/>.
It must either be converted either by using "getaddrinfo()", "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.</t>
<t> 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 <xref target="RFC6454"/>. Therefore, this approach
does not resolve the issue of how browsers should support link-local
addresses, which is discussed further in
<xref target="I-D.schinazi-httpbis-link-local-uri-bcp"/>.
Because of this, the recommendations and normative statements in this
document do not apply to URIs fetched by web browsers.</t>
</section>
<section anchor="security" numbered="true">
<name>Security Considerations</name>
<t>As explained in <xref target="RFC4007"/>, zone identifiers
are of local significance only and must not be sent on the wire.
In particular, see the final security consideration
of RFC 4007, <xref target="RFC4007"/>, which indicates that software
should not trust packets that contain textual non-global
addresses as data. Software Therefore, software that obtains
a zone identifier through
a UI should, therefore, should not transmit it further.
</t>
<t>There is no formal limit on the length of the zone identifier
string in RFC 4007. <xref target="RFC4007"/>. 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.</t>
<t>RFC 4007
<!-- [rfced] Please review "NULL characters" in the sentence below. Should
this instead be "NULs" (that is, referring to the specific ASCII control
code) or "null characters"?
Original:
For example, a UI implementation should not allow ASCII
NULL characters in a zone identifier string as this could cause
inconsistencies in subsequent string processing.
-->
<t><xref target="RFC4007"/> 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 NULL characters in a zone identifier
string as this could cause inconsistencies in subsequent string processing.</t>
</section>
<!-- security -->
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>This document makes has no request of IANA.</t> IANA actions.</t>
</section>
</middle>
<back>
<displayreference target="I-D.schinazi-httpbis-link-local-uri-bcp" to="LINK-LOCAL-URI"/>
<displayreference target="I-D.ietf-6man-rfc6874bis" to="RFC6874bis"/>
<displayreference target="I-D.ietf-v6ops-6mops" to="IPv6-MOSTLY"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4007.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4007.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml"/>
<referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/bcp14"> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
</referencegroup> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3493.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3493.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6874.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6874.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6454.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6454.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8925.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7622.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7622.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8089.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8089.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc6874bis.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
<!-- [I-D.ietf-6man-rfc6874bis]
draft-ietf-6man-rfc6874bis-09
IESG State: Expired (IESG: Dead) as of 07/09/25
Long Way because of author initials
-->
<reference anchor="I-D.ietf-6man-rfc6874bis" target="https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis-09">
<front>
<title>
Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
</title>
<author fullname="Brian E. Carpenter" initials="B." surname="Carpenter"/>
<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
<organization>Apple Inc.</organization>
</author>
<author fullname="Bob Hinden" initials="R." surname="Hinden">
<organization>Check Point Software</organization>
</author>
<date day="2" month="July" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-rfc6874bis-09"/>
</reference>
<!-- [I-D.ietf-v6ops-6mops]
draft-ietf-v6ops-6mops-01
IESG State: I-D Exists as of 07/09/25
-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-6mops.xml"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-6mops.xml"/>
<!-- [I-D.schinazi-httpbis-link-local-uri-bcp]
draft-schinazi-httpbis-link-local-uri-bcp-03
IESG State: I-D Expired as 07/09/25
-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.schinazi-httpbis-link-local-uri-bcp.xml"/> href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.schinazi-httpbis-link-local-uri-bcp.xml"/>
<reference anchor="ONE-NET" target="https://www.nmea.org/nmea-onenet.html">
<front>
<title>The OneNet Standard for IP Networking of Marine Electronic Devices</title>
<author fullname="NMEA"/>
<date year="2023"/> year="2025"/>
</front>
</reference>
<reference anchor="LL-HACK" target="http://web.archive.org/web/20210725030713/https://website.peterjin.org/wiki/Snippets:IPv6_link_local_connect_hack"> target="https://web.archive.org/web/20210725030713/https://website.peterjin.org/wiki/Snippets:IPv6_link_local_connect_hack">
<front>
<title>Snippets: IPv6 link-local connect hack</title>
<author fullname="Peter Jin"/>
<date year="2021"/>
</front>
</reference>
<reference anchor="POSIX" target="https://doi.org/10.1109/IEEESTD.2024.10555529">
<front>
<title>IEEE/Open Group Standard for Information Technology--Portable Operating System Interface (POSIX™) Base Specifications, Issue 8</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2024" month="June"/>
</front>
<seriesInfo name="IEEE Std" value="1003.1-2024"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/> value="10.1109/IEEESTD.2024.10555529"/>
</reference>
</references>
</references>
<section anchor="changes" numbered="true" removeInRFC="true">
<name>Change log</name>
<ul>
<li>
<t>draft-carpenter-6man-zone-ui-00, 2024-01-15:</t>
<ul>
<li>Initial version</li>
</ul>
</li>
<li>
<t>draft-carpenter-6man-zone-ui-01, 2024-02-17:</t>
<ul>
<li>Weakened use of normative keywords to allow flexibility</li>
</ul>
</li>
<li>
<t>draft-carpenter-6man-zone-ui-02, 2024-02-21:</t>
<ul>
<li>Note that RFC 6874 was found unimplementable.</li>
<li>Note that HTTP "origin" issues are not resolved.</li>
<li>Cite new httpbis draft.</li>
<li>Open issue: Updates: 4007 ?</li>
</ul>
</li>
<li>
<t>draft-carpenter-6man-zone-ui-03, 2024-03-01:</t>
<ul>
<li>Small clarifications.</li>
<li>Updated some references.</li>
</ul>
</li>
<li>
<t>draft-carpenter-6man-zone-ui-04, 2024-04-01:</t>
<ul>
<li>Mentioned scoped multicast addresses.</li>
<li>Mentioned inet_pton() issue.</li>
<li>Added reference.</li>
</ul>
</li>
<li>
<t>draft-ietf-6man-zone-ui-00, 2024-06-28:</t>
<ul>
<li>Adopted by WG.</li>
<li>Clarified inapplicability to browsers.</li>
</ul>
</li>
<li>
<t>draft-ietf-6man-zone-ui-01, 2024-08-05:</t>
<ul>
<li>Clarified extensions of RFC 4007.</li>
<li>Clarified relationship with RFC 5952</li>
</ul>
</li>
<li>
<t>draft-ietf-6man-zone-ui-02, 2024-09-05:</t>
<ul>
<li>Clarified non-impact on URI syntax.</li>
</ul>
</li>
<li>
<t>draft-ietf-6man-zone-ui-03, 2024-09-09:</t>
<ul>
<li>Update RFC 7622 and RFC 8089 to remove citations of RFC 6874.</li>
<li>Explicit mention of cancelled update to RFC 3986.</li>
</ul>
</li>
<li>
<t>draft-ietf-6man-zone-ui-04, 2024-10-14:</t>
<ul>
<li>Avoid specific example of length limit.</li>
<li>Added optional command line parameter.</li>
<li>Split Introduction into three sections.</li>
<li>Added formal update to RFC 4007.</li>
<li>Added three normative keywords.</li>
<li>Minor text improvements.</li>
</ul>
</li>
<li>
<t>draft-ietf-6man-zone-ui-05, 2024-12-10:</t>
<ul>
<li>Corrected BCP14 tags.</li>
</ul>
</li>
<li>
<t>draft-ietf-6man-zone-ui-06, 2025-01-17:</t>
<ul>
<li>Removed erroneous reference to ASCII.</li>
<li>Zone ID REQUIRED if o/s provides no default.</li>
<li>Noted that the cited hack is no longer maintained.</li>
</ul>
</li>
<li>
<t>draft-ietf-6man-zone-ui-07, 2025-01-24:</t>
<ul>
<li>Noted that non-browser use of URIs is not affected.</li>
</ul>
</li>
<li>
<t>draft-ietf-6man-zone-ui-08, 2025-02-26:</t>
<ul>
<li>Reworded example of RFC1918 address.</li>
<li>Refined scope of statement about web browsers.</li>
<li>Noted that implementations should make character set checks.</li>
</ul>
</li>
<li>
<t>draft-ietf-6man-zone-ui-09, 2025-05-17:</t>
<ul>
<li>Adjusted formal requirement to be more precise (qualified MUST instead of SHOULD).</li>
<li>Added reference.</li>
</ul>
</li>
<li>
<t>draft-ietf-6man-zone-ui-10, 2025-05-19:</t>
<ul>
<li>Editorial comments from IESG members</li>
</ul>
</li>
</ul>
</section>
<!-- changes -->
<section anchor="ack" numbered="true"> numbered="false">
<name>Acknowledgements</name>
<t>
This
<t>This document owes a lot to the previous discussions that led to RFC 6874 <xref target="RFC6874"/> and to the abandoned draft expired Internet-Draft <xref
target="I-D.ietf-6man-rfc6874bis"/>.</t>
<!-- [rfced] We reordered one name in the Acknowledgments section as it
seems that the intent was to list the names in alphabetical order by last
name. Let us know any concerns.
-->
<t>Useful comments were received from
Erik Auerswald,
Nick Buraglio,
Martin <contact fullname="Erik
Auerswald"/>, <contact fullname="Nick Buraglio"/>, <contact
fullname="Martin J. Dürst,
Toerless Eckert,
David Farmer,
Brian Haberman,
Nate Karstens,
Tero Kivinen,
Erik Kline,
Jen Linkova,
Eduard Metz,
Gyan Mishra,
Ole Troan,
David Schinazi,
Jürgen Schönwälder,
Michael Sweet,
Martin Thomson,
Éric Vyncke,
Magnus Westerlund, Dürst"/>, <contact fullname="Toerless Eckert"/>,
<contact fullname="David Farmer"/>, <contact fullname="Brian
Haberman"/>, <contact fullname="Nate Karstens"/>, <contact
fullname="Tero Kivinen"/>, <contact fullname="Erik Kline"/>, <contact
fullname="Jen Linkova"/>, <contact fullname="Eduard Metz"/>, <contact
fullname="Gyan Mishra"/>, <contact
fullname="David Schinazi"/>, <contact fullname="Jürgen Schönwälder"/>,
<contact fullname="Michael Sweet"/>, <contact fullname="Martin
Thomson"/>, <contact fullname="Ole Troan"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Magnus
Westerlund"/>, and other participants in the 6MAN WG.
</t> WG.</t>
</section>
<!-- ack [rfced] FYI - Per earlier discussion, the RPC will update metadata for
RFC 3986 and create an erratum report on RFC 6874 as described below
after publication of this document.
From email from Sandy Ginoza (RPC) on 20 May 2025 with subject line "Re:
Datatracker State Update Notice: <draft-ietf-6man-zone-ui-10.txt>":
This is the current metadata for RFC 3986 (STD 66): Obsoletes RFC 2732, RFC
2396, RFC 1808, Updates RFC 1738, Updated by RFC 6874, RFC 7320, RFC 8820
I believe the goal is for it to be updated as follows (remove mention of
6874): Obsoletes RFC 2732, RFC 2396, RFC 1808, Updates RFC 1738, Updated by
RFC 7320, RFC 8820
For the reader that may land on RFC 6874, add an erratum on RFC 6874 with the
content (or similar) below when draft-ietf-6man-zone-ui is published as an
RFC.
This was found unimplementable and no longer updates RFC 3986. Please see
YYYY [RFC 9844] for more info.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether "native" should be updated:
Original:
It will become critical as IPv6-only or IPv6-mostly
networks [RFC8925] [I-D.ietf-v6ops-6mops], with nodes lacking native
IPv4 support, appear.
-->
</back>
</rfc>