rfc9844.original.xml   rfc9844.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc>
<?rfc toc="yes"?> <!DOCTYPE rfc [
<!-- You want a table of contents --> <!ENTITY nbsp "&#160;">
<?rfc symrefs="yes"?> <!ENTITY zwsp "&#8203;">
<!-- Use symbolic labels for references --> <!ENTITY nbhy "&#8209;">
<?rfc sortrefs="yes"?> <!ENTITY wj "&#8288;">
<!-- This sorts the references --> ]>
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc compact="yes"?> tf-6man-zone-ui-10" number="9844" consensus="true" ipr="trust200902" obsoletes="
<!-- This defines the specific filename and version number of your draft (and in 6874" updates="4007, 7622, 8089" submissionType="IETF" xml:lang="en" tocInclude=
serts the appropriate IETF boilerplate --> "true" symRefs="true" sortRefs="true" version="3">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-6man-zone-ui-10" ipr="trust200902" obsoletes="6874" updates ="4007, 7622, 808
9" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs
="true" version="3">
<!-- xml2rfc v2v3 conversion 2.44.0 -->
<front> <front>
<title abbrev="IPv6 Zone IDs in UIs">Entering IPv6 Zone Identifiers in User Interfaces</title> <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"/> <seriesInfo name="RFC" value="9844"/>
<author initials="B." surname="Carpenter" fullname="Brian Carpenter"> <author initials="B." surname="Carpenter" fullname="Brian Carpenter">
<organization abbrev="Univ. of Auckland"/> <organization abbrev="Univ. of Auckland"/>
<address> <address>
<postal> <postal>
<postalLine>School of Computer Science</postalLine> <street>School of Computer Science</street>
<postalLine>University of Auckland</postalLine> <street>University of Auckland</street>
<postalLine>PB 92019</postalLine> <street>PB 92019</street>
<postalLine>Auckland 1142</postalLine> <city>Auckland 1142</city>
<postalLine>New Zealand</postalLine> <country>New Zealand</country>
</postal> </postal>
<email>brian.e.carpenter@gmail.com</email> <email>brian.e.carpenter@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Robert M. Hinden" initials="R" surname="Hinden"> <author fullname="Robert M. Hinden" initials="R" surname="Hinden">
<organization>Check Point Software</organization> <organization>Check Point Software</organization>
<address> <address>
<postal> <postal>
<postalLine>959 Skyway Road</postalLine> <street>959 Skyway Road</street>
<postalLine>San Carlos, CA 94070</postalLine> <city>San Carlos</city><region>CA</region><code>94070</code>
<postalLine>USA</postalLine> <country>United States of America</country>
</postal> </postal>
<phone/>
<email>bob.hinden@gmail.com</email> <email>bob.hinden@gmail.com</email>
</address> </address>
</author> </author>
<date month="August" year="2025"/>
<area>Internet</area> <area>INT</area>
<workgroup>6MAN</workgroup> <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>
<abstract> <abstract>
<t>This document describes how the zone identifier of an IPv6 scoped addre ss, defined <t>This document describes how the zone identifier of an IPv6 scoped addre ss, defined
in the IPv6 Scoped Address Architecture (RFC 4007), should be in the IPv6 Scoped Address Architecture specification (RFC 4007), should be
entered into a user interface. It obsoletes RFC 6874 and updates RFC 4007, RFC 7 entered into a user interface. This document obsoletes RFC 6874 and updates RFCs
622 and RFC 8089. 4007, 7622, and 8089.</t>
</t>
</abstract> </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/ip
v6/">https://mailarchive.ietf.org/arch/browse/ipv6/</eref>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true"> <section anchor="intro" numbered="true">
<name>Introduction</name> <name>Introduction</name>
<t>A number of software tools require or permit the user to <t>A number of software tools require or permit the user to
enter an IPv6 address via a user interface (UI). The standard enter an IPv6 address via a user interface (UI). The standard
literal text format for an IPv6 address is defined by <xref target="RFC429 1"/> literal text format for an IPv6 address is defined by <xref target="RFC429 1"/>
and <xref target="RFC5952"/>. and <xref target="RFC5952"/>.
The IPv6 Scoped Address Architecture specification <xref target="RFC4007"/ > The IPv6 Scoped Address Architecture specification <xref target="RFC4007"/ >
extends the text representation of limited-scope IPv6 addresses, extends the text representation of limited-scope IPv6 addresses,
in particular link-local unicast addresses and multicast addresses with in particular link-local unicast addresses and multicast addresses with
less than global scope, such that a zone identifier less than global scope, such that a zone identifier
may be concatenated to an address. Note that RFC 5952 does not mention thi s extension.</t> may be concatenated to an address. Note that <xref target="RFC5952"/> does not mention this extension.</t>
<t>Zone identifiers are especially <t>Zone identifiers are especially
useful in contexts in which literal addresses are typically used, useful in contexts in which literal addresses are typically used,
for example during fault diagnosis or device configuration for example, during fault diagnosis or device configuration
(where a device may be physical or virtual), (where a device may be physical or virtual)
when it may be essential to when it may be essential to
specify which interface is used for sending to a link-local address. specify which interface is used for sending to a link-local address.
It should be noted that zone identifiers have purely local meaning It should be noted that zone identifiers have purely local meaning
within the node in which they are defined, usually being the same as within the node in which they are defined, usually being the same as
IPv6 interface names. They are completely meaningless IPv6 interface names. They are completely meaningless
for any other node. At the time of writing, they are meaningful only when attached 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 to link-local unicast and scoped multicast addresses, but it is
possible that other uses might be defined in the future. </t> possible that other uses might be defined in the future. </t>
<t>Examples of a link-local unicast address qualified by a zone <t>Examples of a link-local unicast address qualified by a zone
identifier are "fe80::1234%eth0" on a Linux host, or identifier are "fe80::1234%eth0" on a Linux host or
"fe80::4321%7" on a Microsoft Windows host.</t> "fe80::4321%7" on a Microsoft Windows host.</t>
<t>Such addresses are directly supported by socket API calls <t>Such addresses are directly supported by socket API calls
including "getaddrinfo()" <xref target="RFC3493"/>.</t> including "getaddrinfo()" <xref target="RFC3493"/>.</t>
<t>Devices whose network stack does not support <t>Devices whose network stack does not support
the RFC 4007 model of a human-readable zone identifier the model of a human-readable zone identifier described in <xref target="R FC4007"/>
are out of scope for this document.</t> are out of scope for this document.</t>
</section> </section>
<section anchor="uses" numbered="true"> <section anchor="uses" numbered="true">
<name>Use Cases</name> <name>Use Cases</name>
<t>Some examples of use cases for entering an address <t>Some examples of use cases for entering an address
that includes a zone identifier that includes a zone identifier
into a UI are as follows:</t> into a UI are as follows:</t>
<ol><li>A software tool may be used for simple debugging actions <ol><li>A software tool may be used for simple debugging actions
involving link-local addresses on a host with more than one active involving link-local addresses on a host with more than one active
link interface. For example, the functioning of an interface link interface. For example, the functioning of an interface
and the existence of a device may be checked and the existence of a device may be checked
via "ping fe80::1234%eth0". If this succeeds, the user learns via "ping fe80::1234%eth0". If this succeeds, the user learns
that the other device is reachable via the interface named "eth0".</li> 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 <li>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 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 more than one active link interface. For example, a typical home router
may be configured via a well-known private address <xref target="RFC1918"/> 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 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 address es not support the input of zone identifiers. More generally, link-local address es
need to be entered in network management UIs for use in formats need to be entered in network management UIs for use in formats
such as YANG <xref target="RFC6991"/>.</li> such as YANG <xref target="RFC6991"/>.</li>
<li>Using a monitoring tool such as a network sniffer, the user may need to s pecify <li>Using a monitoring tool such as a network sniffer, the user may need to s pecify
a given link-local address on a given interface whose traffic is of interest. 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 multipl e (For example, at the time of writing, Wireshark supports capture from multipl e
interfaces, but does not appear to support the zone interfaces but does not appear to support the zone
identifier in a display filter.)</li> identifier in a display filter.)</li>
<li>The Microsoft Web Services for Devices (WSD) virtual printer <li>The Microsoft Web Services for Devices (WSD) virtual printer
port mechanism can present the user with an IPv6 link-local address such as 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, "fe80::823b:f9ff:fe7b:d9dc%10" in which the zone identifier is present
but is not recognized by appropriate software.</li> but is not recognized by appropriate software.</li>
<li>The National Marine Electronics Association (NMEA) has defined <li>The National Marine Electronics Association (NMEA) has defined
the "OneNet Marine IPv6 Ethernet Networking Standard" <xref target="ONE-NET"/ >, the "OneNet Marine IPv6 Ethernet Networking Standard" <xref target="ONE-NET"/ >,
which uses IPv6 link-local addresses exclusively. Proposed improvements to which uses IPv6 link-local addresses exclusively. Proposed improvements to
the standard include a web page for device configuration using link-local the standard include a web page for device configuration using link-local
addresses.</li> addresses.</li>
</ol> </ol>
<t>Such requirements have already spawned <t>Such requirements have already spawned
hacks to work around current limitations (e.g., <xref target="LL-HACK"/>, hacks to work around current limitations (e.g., the hack described in <xref targ et="LL-HACK"/>,
which is no longer maintained and has been archived).</t> 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-loca l <t>For all such use cases, it is highly desirable that a complete IPv6 link-loca l
address can be cut and pasted from one UI (such as the output address can be cut and pasted from one UI (such as the output
from a system command) to another. Since such from a system command) to another. Since such
addresses may include quite long hexadecimal strings, addresses may include quite long hexadecimal strings,
for example "fe80::8d0f:7f26:f5c8:780b%enx525400d5e0fb", any solution except for example, "fe80::8d0f:7f26:f5c8:780b%enx525400d5e0fb", any solution except
cut-and-paste is highly error prone.</t> cut-and-paste is highly error prone.</t>
</section> </section>
<section anchor="rfcrel" numbered="true"> <section anchor="rfcrel" numbered="true">
<name>Relationship to Other Documents</name> <name>Relationship to Other Documents</name>
<t>The use cases listed above apply to relatively simple actions <t>The use cases listed above apply to relatively simple actions
on end systems. The zone identifiers that can be used are limited on end systems. The zone identifiers that can be used are limited
by the host operating system, since <xref target="RFC4007"/> only specifies by the host operating system, since <xref target="RFC4007"/> only specifies
that they are text strings, without specifying a maximum length or syntax. that they are text strings, without specifying a maximum length or syntax.
As RFC 4007 explains, each zone identifier corresponds to a As <xref target="RFC4007"/> explains, each zone identifier corresponds to a
numerical zone index that qualifies a link-local address.</t> numerical zone index that qualifies a link-local address.</t>
<t>It should be noted that whereas some operating systems and network APIs <t>It should be noted that whereas some operating systems and network APIs
support a default zone identifier as recommended by RFC 4007, support a default zone identifier as recommended by <xref target="RFC4007"/>,
others, including Linux, do not, and for them a solution is others, including Linux, do not, and for them a solution is
particularly important, since a link-local address without particularly important, since a link-local address without
a zone index cannot be used in the Linux socket API.</t> a zone index cannot be used in the Linux socket API.</t>
<t>The RFC 4007 model assumes that the human-readable zone identifier <t>The model in <xref target="RFC4007"/> assumes that the human-readable zone id entifier
is mapped by the operating system into a numeric interface index. is mapped by the operating system into a numeric interface index.
Typically, this mapping is performed by the socket API, e.g. by Typically, this mapping is performed by the socket API, e.g., by
"getaddrinfo()". The mapping between the human-readable zone identifier "getaddrinfo()". The mapping between the human-readable zone identifier
string and the numeric string and the numeric
value is a host-specific function that varies between operating systems. The value is a host-specific function that varies between operating systems. The
present document is concerned only with the human-readable string that is present document is concerned only with the human-readable string that is
typically displayed in an operating system's user interface. However, in typically displayed in an operating system's user interface. However, in
most operating systems it is possible to use the underlying interface number, 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. 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 is recommended by <xref target="RFC4007" section="11.2"/>, but it is not re quired.
This possibility does not affect the UI requirement given in this document.</t> 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 <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 handling complete link-local addresses in all tools is becoming an acute
problem for increasing numbers of operational and support personnel. problem for increasing numbers of operational and support personnel.
It will become critical as IPv6-only or IPv6-mostly networks It will become critical as IPv6-only or IPv6-mostly networks
<xref target="RFC8925"/> <xref target="I-D.ietf-v6ops-6mops"/>, with nodes lacki ng native <xref target="RFC8925"/> <xref target="I-D.ietf-v6ops-6mops"/>, with nodes lacki ng native
IPv4 support, appear. For example, the NMEA use case mentioned above is IPv4 support, appear. For example, the NMEA use case mentioned above is
an immediate requirement. This is the principal reason for documenting an immediate requirement. This is the principal reason for documenting
this requirement now.</t> this requirement now.</t>
<t>This document completely obsoletes <xref target="RFC6874"/>, which implemento rs <t>This document completely obsoletes <xref target="RFC6874"/>, which implemento rs
of web browsers have determined is impracticable to support of web browsers have determined is impracticable to support
<xref target="I-D.schinazi-httpbis-link-local-uri-bcp"/>, and replaces it <xref target="I-D.schinazi-httpbis-link-local-uri-bcp"/>, and replaces it
by a generic UI requirement. Note that obsoleting with a generic UI requirement. Note that obsoleting
RFC 6874 reverts the change that it made to the URI syntax defined by <xref target="RFC6874"/> reverts the change that it made to the URI syntax defin
<xref target="RFC3986"/>, so RFC 3986 is no longer updated by RFC 6874. ed by
<xref target="RFC3986"/>, so <xref target="RFC3986"/> is no longer updated by <x
ref target="RFC6874"/>.
As far as is known, this change will have no significant impact on As far as is known, this change will have no significant impact on
non-browser deployments of URIs.</t> non-browser deployments of URIs.</t>
<t>This document also updates <xref target="RFC7622"/> and <xref target="RFC8089 "/> <t>This document also updates <xref target="RFC7622"/> and <xref target="RFC8089 "/>
by deleting their references to RFC 6874.</t> by deleting their references to <xref target="RFC6874"/>.</t>
<t>It also updates <xref target="RFC4007"/> by adding a new requirement that <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> user interfaces support the zone identifier as described in <xref target="spec"/ >.</t>
</section> </section>
<section anchor="norm" numbered="true"> <section anchor="norm" numbered="true">
<name>Normative Terminology</name> <name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", <t>
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
14>", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
are to be interpreted as described in <xref target="BCP14"/> be interpreted as
when, and only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="spec" numbered="true"> <section anchor="spec" numbered="true">
<name>Specification</name> <name>Specification</name>
<t>A user interface (UI) that allows or requires the user to enter an <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> provi de a means IPv6 address other than a global unicast address <bcp14>MUST</bcp14> provi de a means
for entering a link-local address or a scoped multicast address and for entering a link-local address or a scoped multicast address and
selecting a zone identifier as specified by <xref target="RFC4007"/> (typi cally, an selecting a zone identifier as specified by <xref target="RFC4007"/> (typi cally, an
interface identifier as defined by the operating system).</t> interface identifier as defined by the operating system).</t>
<t>In this case, the UI <bcp14>SHOULD</bcp14> support the complete <t>In this case, the UI <bcp14>SHOULD</bcp14> support the complete
format specified by RFC 4007 (e.g., "fe80::1%eth0").</t> format specified by <xref target="RFC4007"/> (e.g., "fe80::1%eth0").</t>
<t>If this is impossible for practical reasons, the UI <bcp14>MAY</bcp14> <t>If this is impossible for practical reasons, the UI <bcp14>MAY</bcp14>
support an alternative delimiter in place of "%". support an alternative delimiter in place of "%".
The hyphen ("-") is suggested (e.g., "fe80::1-eth0").</t> The hyphen ("-") is suggested (e.g., "fe80::1-eth0").</t>
<t>If this too is impossible for practical reasons, the UI <t>If this too is impossible for practical reasons, the UI
<bcp14>MAY</bcp14> provide two separate input fields (e.g., "fe80::1" in <bcp14>MAY</bcp14> provide two separate input fields (e.g., "fe80::1" in
one box, "eth0" in another), selection from a list of one box and "eth0" in another), selection from a list of
active zone identifiers, active zone identifiers,
or a separate command line parameter for the zone identifier.</t> or a separate command-line parameter for the zone identifier.</t>
<t>The program providing the UI will then store the address <t>The program providing the UI will then store the address
and the zone identifier, converting the latter and the zone identifier, converting the latter
to an interface index (typically via the socket API). to an interface index (typically via the socket API).
A faulty zone identifier will be detected when attempting to convert A faulty zone identifier will be detected when attempting to convert
it and this should be reported to the user as an error. The it, and this should be reported to the user as an error. The
resulting interface index will be used resulting interface index will be used
for any subsequent socket calls using the link-local address. </t> for any subsequent socket calls using the link-local address. </t>
<t>Note that an address string such as "fe80::1%eth0" cannot be <t>Note that an address string such as "fe80::1%eth0" cannot be
converted to binary by the POSIX socket API function "inet_pton()" converted to binary by the POSIX socket API function "inet_pton()"
<xref target="POSIX"/>. <xref target="POSIX"/>.
It must either be converted using "getaddrinfo()", or It must be converted either by using "getaddrinfo()" or
by splitting it into two strings and using "inet_pton()" by splitting it into two strings and using "inet_pton()"
and "if_nametoindex()" successively, in order to obtain and "if_nametoindex()" successively, in order to obtain
the required interface index value.</t> the required interface index value.</t>
<t> In this model, the zone identifier is considered independently of <t> In this model, the zone identifier is considered independently of
the IPv6 address itself. However, this does not in itself resolve the IPv6 address itself. However, this does not in itself resolve
the difficulties in considering the zone identifier as part of the the difficulties in considering the zone identifier as part of the
HTTP origin model <xref target="RFC6454"/>. Therefore, this approach HTTP origin model <xref target="RFC6454"/>. Therefore, this approach
does not resolve the issue of how browsers should support link-local does not resolve the issue of how browsers should support link-local
addresses, discussed further in addresses, which is discussed further in
<xref target="I-D.schinazi-httpbis-link-local-uri-bcp"/>. <xref target="I-D.schinazi-httpbis-link-local-uri-bcp"/>.
Because of this, the recommendations and normative statements in this Because of this, the recommendations and normative statements in this
document do not apply to URIs fetched by web browsers.</t> document do not apply to URIs fetched by web browsers.</t>
</section> </section>
<section anchor="security" numbered="true"> <section anchor="security" numbered="true">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>As explained in <xref target="RFC4007"/>, zone identifiers <t>As explained in <xref target="RFC4007"/>, zone identifiers
are of local significance only and must not be sent on the wire. are of local significance only and must not be sent on the wire.
In particular, see the final security consideration In particular, see the final security consideration
of RFC 4007, which indicates that software of <xref target="RFC4007"/>, which indicates that software
should not trust packets that contain textual non-global should not trust packets that contain textual non-global
addresses as data. Software that obtains addresses as data. Therefore, software that obtains
a zone identifier through a zone identifier through
a UI should, therefore, not transmit it further. a UI should not transmit it further.
</t> </t>
<t>There is no formal limit on the length of the zone identifier <t>There is no formal limit on the length of the zone identifier
string in RFC 4007. A UI implementation should apply an appropriate string in <xref target="RFC4007"/>. A UI implementation should apply an ap propriate
length limit when inputting a zone identifier, in order length limit when inputting a zone identifier, in order
to minimize the risk of a buffer overrun. Typically, this limit 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> would be the same as the host operating system's limit on interface names. </t>
<t>RFC 4007 does not specify or restrict the character set allowed in a zo ne <t><xref target="RFC4007"/> does not specify or restrict the character set allowed in a zone
identifier. Therefore, each implementation processing zone identifiers nee ds identifier. Therefore, each implementation processing zone identifiers nee ds
to make checks appropriate for the environment it is used in. For example, 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 ident ifier a UI implementation should not allow ASCII NUL characters in a zone identi fier
string as this could cause inconsistencies in subsequent string processing .</t> string as this could cause inconsistencies in subsequent string processing .</t>
</section> </section>
<!-- security -->
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no request of IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.schinazi-httpbis-link-local-uri-bcp" to="LINK-LOCA
L-URI"/>
<displayreference target="I-D.ietf-6man-rfc6874bis" to="RFC6874bis"/>
<displayreference target="I-D.ietf-v6ops-6mops" to="IPv6-MOSTLY"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4007.xml"/> 007.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4291.xml"/> 291.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.5952.xml"/> 952.xml"/>
<referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/b <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
cp14"> 119.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
.2119.xml"/> 174.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC
.8174.xml"/>
</referencegroup>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
FC.1918.xml"/> 918.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
FC.3493.xml"/> 493.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
FC.3986.xml"/> 986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.6874.xml"/> 874.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.6454.xml"/> 454.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8925.xml"/> 925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.7622.xml"/> 622.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8089.xml"/> 089.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.6991.xml"/> 991.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.ietf-6man-rfc6874bis.xml"/> <!-- [I-D.ietf-6man-rfc6874bis]
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe draft-ietf-6man-rfc6874bis-09
rence.I-D.ietf-v6ops-6mops.xml"/> IESG State: Expired (IESG: Dead) as of 07/09/25
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe Long Way because of author initials
rence.I-D.schinazi-httpbis-link-local-uri-bcp.xml"/> -->
<reference anchor="I-D.ietf-6man-rfc6874bis" target="https://datatracker.ietf.or
g/doc/html/draft-ietf-6man-rfc6874bis-09">
<front>
<title>
Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Iden
tifiers
</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://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://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.htm l"> <reference anchor="ONE-NET" target="https://www.nmea.org/nmea-onenet.htm l">
<front> <front>
<title>The OneNet Standard for IP Networking of Marine Electronic De vices</title> <title>OneNet Marine IPv6 Ethernet Networking Standard</title>
<author fullname="NMEA"/> <author fullname="NMEA"/>
<date year="2023"/> <date year="2025"/>
</front> </front>
</reference> </reference>
<reference anchor="LL-HACK" target="http://web.archive.org/web/202107250 30713/https://website.peterjin.org/wiki/Snippets:IPv6_link_local_connect_hack"> <reference anchor="LL-HACK" target="https://web.archive.org/web/20210725 030713/https://website.peterjin.org/wiki/Snippets:IPv6_link_local_connect_hack">
<front> <front>
<title>Snippets: IPv6 link-local connect hack</title> <title>Snippets: IPv6 link-local connect hack</title>
<author fullname="Peter Jin"/> <author fullname="Peter Jin"/>
<date year="2021"/> <date year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="POSIX" target="https://doi.org/10.1109/IEEESTD.2024.1 0555529"> <reference anchor="POSIX" target="https://doi.org/10.1109/IEEESTD.2024.1 0555529">
<front> <front>
<title>IEEE/Open Group Standard for Information Technology--Portable Operating System Interface (POSIX™) Base Specifications, Issue 8</title> <title>IEEE/Open Group Standard for Information Technology--Portable Operating System Interface (POSIX™) Base Specifications, Issue 8</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date year="2024" month="June"/> <date year="2024" month="June"/>
</front> </front>
<seriesInfo name="IEEE Std" value="1003.1-2024"/> <seriesInfo name="IEEE Std" value="1003.1-2024"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8423794"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2024.10555529"/>
</reference> </reference>
</references> </references>
</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> <section anchor="ack" numbered="false">
<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.</l
i>
<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 i
nstead 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">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t> <t>This document owes a lot to the previous discussions that led to <xref
This document owes a lot to the previous discussions that led to RFC 6874 target="RFC6874"/> and to the expired Internet-Draft <xref
and to the abandoned draft <xref target="I-D.ietf-6man-rfc6874bis"/>.</t> target="I-D.ietf-6man-rfc6874bis"/>.</t>
<t>Useful comments were received from
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,
Ole Troan,
David Schinazi,
Jürgen Schönwälder,
Michael Sweet,
Martin Thomson,
Éric Vyncke,
Magnus Westerlund,
and other participants in the 6MAN WG.
</t> <t>Useful comments were received from <contact fullname="Erik
Auerswald"/>, <contact fullname="Nick Buraglio"/>, <contact
fullname="Martin J. 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 Vynck
e"/>, <contact fullname="Magnus
Westerlund"/>, and other participants in the 6MAN WG.</t>
</section> </section>
<!-- ack -->
</back> </back>
</rfc> </rfc>
 End of changes. 55 change blocks. 
282 lines changed or deleted 169 lines changed or added

This html diff was produced by rfcdiff 1.48.