rfc9844.original   rfc9844.txt 
6MAN B. Carpenter Internet Engineering Task Force (IETF) B. Carpenter
Internet-Draft Univ. of Auckland Request for Comments: 9844 Univ. of Auckland
Obsoletes: 6874 (if approved) R. Hinden Obsoletes: 6874 R. Hinden
Updates: 4007, 7622, 8089 (if approved) Check Point Software Updates: 4007, 7622, 8089 Check Point Software
Intended status: Standards Track 19 May 2025 Category: Standards Track August 2025
Expires: 20 November 2025 ISSN: 2070-1721
Entering IPv6 Zone Identifiers in User Interfaces Entering IPv6 Zone Identifiers in User Interfaces
draft-ietf-6man-zone-ui-10
Abstract Abstract
This document describes how the zone identifier of an IPv6 scoped This document describes how the zone identifier of an IPv6 scoped
address, defined in the IPv6 Scoped Address Architecture (RFC 4007), address, defined in the IPv6 Scoped Address Architecture
should be entered into a user interface. It obsoletes RFC 6874 and specification (RFC 4007), should be entered into a user interface.
updates RFC 4007, RFC 7622 and RFC 8089. This document obsoletes RFC 6874 and updates RFCs 4007, 7622, and
8089.
Discussion Venue
This note is to be removed before publishing as an RFC.
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/
(https://mailarchive.ietf.org/arch/browse/ipv6/).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 20 November 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9844.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases
3. Relationship to Other Documents . . . . . . . . . . . . . . . 4 3. Relationship to Other Documents
4. Normative Terminology . . . . . . . . . . . . . . . . . . . . 5 4. Requirements Language
5. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Specification
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 7 8.2. Informative References
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgements
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
A number of software tools require or permit the user to enter an A number of software tools require or permit the user to enter an
IPv6 address via a user interface (UI). The standard literal text IPv6 address via a user interface (UI). The standard literal text
format for an IPv6 address is defined by [RFC4291] and [RFC5952]. format for an IPv6 address is defined by [RFC4291] and [RFC5952].
The IPv6 Scoped Address Architecture specification [RFC4007] extends The IPv6 Scoped Address Architecture specification [RFC4007] extends
the text representation of limited-scope IPv6 addresses, in the text representation of limited-scope IPv6 addresses, in
particular link-local unicast addresses and multicast addresses with particular link-local unicast addresses and multicast addresses with
less than global scope, such that a zone identifier may be less than global scope, such that a zone identifier may be
concatenated to an address. Note that RFC 5952 does not mention this concatenated to an address. Note that [RFC5952] does not mention
extension. this extension.
Zone identifiers are especially useful in contexts in which literal Zone identifiers are especially useful in contexts in which literal
addresses are typically used, for example during fault diagnosis or addresses are typically used, for example, during fault diagnosis or
device configuration (where a device may be physical or virtual), device configuration (where a device may be physical or virtual) when
when it may be essential to specify which interface is used for it may be essential to specify which interface is used for sending to
sending to a link-local address. It should be noted that zone a link-local address. It should be noted that zone identifiers have
identifiers have purely local meaning within the node in which they purely local meaning within the node in which they are defined,
are defined, usually being the same as IPv6 interface names. They usually being the same as IPv6 interface names. They are completely
are completely meaningless for any other node. At the time of meaningless for any other node. At the time of writing, they are
writing, they are meaningful only when attached to link-local unicast meaningful only when attached to link-local unicast and scoped
and scoped multicast addresses, but it is possible that other uses multicast addresses, but it is possible that other uses might be
might be defined in the future. defined in the future.
Examples of a link-local unicast address qualified by a zone Examples of a link-local unicast address qualified by a zone
identifier are "fe80::1234%eth0" on a Linux host, or "fe80::4321%7" identifier are "fe80::1234%eth0" on a Linux host or "fe80::4321%7" on
on a Microsoft Windows host. a Microsoft Windows host.
Such addresses are directly supported by socket API calls including Such addresses are directly supported by socket API calls including
"getaddrinfo()" [RFC3493]. "getaddrinfo()" [RFC3493].
Devices whose network stack does not support the RFC 4007 model of a Devices whose network stack does not support the model of a human-
human-readable zone identifier are out of scope for this document. readable zone identifier described in [RFC4007] are out of scope for
this document.
2. Use Cases 2. Use Cases
Some examples of use cases for entering an address that includes a Some examples of use cases for entering an address that includes a
zone identifier into a UI are as follows: zone identifier into a UI are as follows:
1. A software tool may be used for simple debugging actions 1. A software tool may be used for simple debugging actions
involving link-local addresses on a host with more than one involving link-local addresses on a host with more than one
active link interface. For example, the functioning of an active link interface. For example, the functioning of an
interface and the existence of a device may be checked via "ping interface and the existence of a device may be checked via "ping
fe80::1234%eth0". If this succeeds, the user learns that the fe80::1234%eth0". If this succeeds, the user learns that the
other device is reachable via the interface named "eth0". other device is reachable via the interface named "eth0".
2. A software tool must sometimes be used to configure or 2. A software tool must sometimes be used to configure or
reconfigure a device which only has a link-local address, again reconfigure a device that only has a link-local address, again in
in a host with more than one active link interface. For example, a host with more than one active link interface. For example, a
a typical home router may be configured via a well-known private typical home router may be configured via a well-known private
address [RFC1918] such as "192.168.178.1" but not via address [RFC1918] such as "192.168.178.1" but not via
"fe80::1%eth0", if the tool in use does not support the input of "fe80::1%eth0", if the tool in use does not support the input of
zone identifiers. More generally, link-local addresses need to zone identifiers. More generally, link-local addresses need to
be entered in network management UIs for use in formats such as be entered in network management UIs for use in formats such as
YANG [RFC6991]. YANG [RFC6991].
3. Using a monitoring tool such as a network sniffer, the user may 3. Using a monitoring tool such as a network sniffer, the user may
need to specify a given link-local address on a given interface need to specify a given link-local address on a given interface
whose traffic is of interest. (For example, at the time of whose traffic is of interest. (For example, at the time of
writing, Wireshark supports capture from multiple interfaces, but writing, Wireshark supports capture from multiple interfaces but
does not appear to support the zone identifier in a display does not appear to support the zone identifier in a display
filter.) filter.)
4. The Microsoft Web Services for Devices (WSD) virtual printer port 4. The Microsoft Web Services for Devices (WSD) virtual printer port
mechanism can present the user with an IPv6 link-local address mechanism can present the user with an IPv6 link-local address
such as "fe80::823b:f9ff:fe7b:d9dc%10" in which the zone such as "fe80::823b:f9ff:fe7b:d9dc%10" in which the zone
identifier is present, but is not recognized by appropriate identifier is present but is not recognized by appropriate
software. software.
5. The National Marine Electronics Association (NMEA) has defined 5. The National Marine Electronics Association (NMEA) has defined
the "OneNet Marine IPv6 Ethernet Networking Standard" [ONE-NET], the "OneNet Marine IPv6 Ethernet Networking Standard" [ONE-NET],
which uses IPv6 link-local addresses exclusively. Proposed which uses IPv6 link-local addresses exclusively. Proposed
improvements to the standard include a web page for device improvements to the standard include a web page for device
configuration using link-local addresses. configuration using link-local addresses.
Such requirements have already spawned hacks to work around current Such requirements have already spawned hacks to work around current
limitations (e.g., [LL-HACK], which is no longer maintained and has limitations (e.g., [LL-HACK], which is no longer maintained and has
been archived). been archived).
For all such use cases, it is highly desirable that a complete IPv6 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 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 output from a system command) to another. Since such addresses may
include quite long hexadecimal strings, for example include quite long hexadecimal strings, for example,
"fe80::8d0f:7f26:f5c8:780b%enx525400d5e0fb", any solution except cut- "fe80::8d0f:7f26:f5c8:780b%enx525400d5e0fb", any solution except cut-
and-paste is highly error prone. and-paste is highly error prone.
3. Relationship to Other Documents 3. Relationship to Other Documents
The use cases listed above apply to relatively simple actions on end The use cases listed above apply to relatively simple actions on end
systems. The zone identifiers that can be used are limited by the systems. The zone identifiers that can be used are limited by the
host operating system, since [RFC4007] only specifies that they are host operating system, since [RFC4007] only specifies that they are
text strings, without specifying a maximum length or syntax. As RFC text strings, without specifying a maximum length or syntax. As
4007 explains, each zone identifier corresponds to a numerical zone [RFC4007] explains, each zone identifier corresponds to a numerical
index that qualifies a link-local address. zone index that qualifies a link-local address.
It should be noted that whereas some operating systems and network It should be noted that whereas some operating systems and network
APIs support a default zone identifier as recommended by RFC 4007, APIs support a default zone identifier as recommended by [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 a zone particularly important, since a link-local address without a zone
index cannot be used in the Linux socket API. index cannot be used in the Linux socket API.
The RFC 4007 model assumes that the human-readable zone identifier is The model in [RFC4007] assumes that the human-readable zone
mapped by the operating system into a numeric interface index. identifier is mapped by the operating system into a numeric interface
Typically, this mapping is performed by the socket API, e.g. by index. Typically, this mapping is performed by the socket API, e.g.,
"getaddrinfo()". The mapping between the human-readable zone by "getaddrinfo()". The mapping between the human-readable zone
identifier string and the numeric value is a host-specific function identifier string and the numeric value is a host-specific function
that varies between operating systems. The present document is that varies between operating systems. The present document is
concerned only with the human-readable string that is typically concerned only with the human-readable string that is typically
displayed in an operating system's user interface. However, in most displayed in an operating system's user interface. However, in most
operating systems it is possible to use the underlying interface operating systems, it is possible to use the underlying interface
number, represented as a decimal integer, as an equivalent to the number, represented as a decimal integer, as an equivalent to the
human-readable string. This is recommended by Section 11.2 of RFC human-readable string. This is recommended by Section 11.2 of
4007, but not required. This possibility does not affect the UI [RFC4007], but it is not required. This possibility does not affect
requirement given in this document. the UI requirement given in this document.
As IPv6 deployment becomes more widespread, the lack of a solution As IPv6 deployment becomes more widespread, the lack of a solution
for handling complete link-local addresses in all tools is becoming for handling complete link-local addresses in all tools is becoming
an acute problem for increasing numbers of operational and support an acute problem for increasing numbers of operational and support
personnel. It will become critical as IPv6-only or IPv6-mostly personnel. It will become critical as IPv6-only or IPv6-mostly
networks [RFC8925] [I-D.ietf-v6ops-6mops], with nodes lacking native networks [RFC8925] [IPv6-MOSTLY], with nodes lacking native IPv4
IPv4 support, appear. For example, the NMEA use case mentioned above support, appear. For example, the NMEA use case mentioned above is
is an immediate requirement. This is the principal reason for an immediate requirement. This is the principal reason for
documenting this requirement now. documenting this requirement now.
This document completely obsoletes [RFC6874], which implementors of This document completely obsoletes [RFC6874], which implementors of
web browsers have determined is impracticable to support web browsers have determined is impracticable to support
[I-D.schinazi-httpbis-link-local-uri-bcp], and replaces it by a [LINK-LOCAL-URI], and replaces it with a generic UI requirement.
generic UI requirement. Note that obsoleting RFC 6874 reverts the Note that obsoleting [RFC6874] reverts the change that it made to the
change that it made to the URI syntax defined by [RFC3986], so RFC URI syntax defined by [RFC3986], so [RFC3986] is no longer updated by
3986 is no longer updated by RFC 6874. As far as is known, this [RFC6874]. As far as is known, this change will have no significant
change will have no significant impact on non-browser deployments of impact on non-browser deployments of URIs.
URIs.
This document also updates [RFC7622] and [RFC8089] by deleting their This document also updates [RFC7622] and [RFC8089] by deleting their
references to RFC 6874. references to [RFC6874].
It also updates [RFC4007] by adding a new requirement that user It also updates [RFC4007] by adding a new requirement that user
interfaces support the zone identifier as described in Section 5. interfaces support the zone identifier as described in Section 5.
4. Normative Terminology 4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[BCP14] when, and only when, they appear in all capitals, as shown BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
here. capitals, as shown here.
5. Specification 5. Specification
A user interface (UI) that allows or requires the user to enter an A user interface (UI) that allows or requires the user to enter an
IPv6 address other than a global unicast address MUST provide a means IPv6 address other than a global unicast address MUST provide 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 [RFC4007] (typically, an selecting a zone identifier as specified by [RFC4007] (typically, an
interface identifier as defined by the operating system). interface identifier as defined by the operating system).
In this case, the UI SHOULD support the complete format specified by In this case, the UI SHOULD support the complete format specified by
RFC 4007 (e.g., "fe80::1%eth0"). [RFC4007] (e.g., "fe80::1%eth0").
If this is impossible for practical reasons, the UI MAY support an If this is impossible for practical reasons, the UI MAY support an
alternative delimiter in place of "%". The hyphen ("-") is suggested alternative delimiter in place of "%". The hyphen ("-") is suggested
(e.g., "fe80::1-eth0"). (e.g., "fe80::1-eth0").
If this too is impossible for practical reasons, the UI MAY provide If this too is impossible for practical reasons, the UI MAY provide
two separate input fields (e.g., "fe80::1" in one box, "eth0" in two separate input fields (e.g., "fe80::1" in one box and "eth0" in
another), selection from a list of active zone identifiers, or a another), selection from a list of active zone identifiers, or a
separate command line parameter for the zone identifier. separate command-line parameter for the zone identifier.
The program providing the UI will then store the address and the zone The program providing the UI will then store the address and the zone
identifier, converting the latter to an interface index (typically identifier, converting the latter to an interface index (typically
via the socket API). A faulty zone identifier will be detected when 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 attempting to convert it, and this should be reported to the user as
an error. The resulting interface index will be used for any an error. The resulting interface index will be used for any
subsequent socket calls using the link-local address. subsequent socket calls using the link-local address.
Note that an address string such as "fe80::1%eth0" cannot be 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()"
[POSIX]. It must either be converted using "getaddrinfo()", or by [POSIX]. It must be converted either by using "getaddrinfo()" or by
splitting it into two strings and using "inet_pton()" and splitting it into two strings and using "inet_pton()" and
"if_nametoindex()" successively, in order to obtain the required "if_nametoindex()" successively, in order to obtain the required
interface index value. interface index value.
In this model, the zone identifier is considered independently of the 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 HTTP difficulties in considering the zone identifier as part of the HTTP
origin model [RFC6454]. Therefore, this approach does not resolve origin model [RFC6454]. Therefore, this approach does not resolve
the issue of how browsers should support link-local addresses, the issue of how browsers should support link-local addresses, which
discussed further in [I-D.schinazi-httpbis-link-local-uri-bcp]. is discussed further in [LINK-LOCAL-URI]. Because of this, the
Because of this, the recommendations and normative statements in this recommendations and normative statements in this document do not
document do not apply to URIs fetched by web browsers. apply to URIs fetched by web browsers.
6. Security Considerations 6. Security Considerations
As explained in [RFC4007], zone identifiers are of local significance As explained in [RFC4007], zone identifiers are of local significance
only and must not be sent on the wire. In particular, see the final only and must not be sent on the wire. In particular, see the final
security consideration of RFC 4007, which indicates that software security consideration of [RFC4007], which indicates that software
should not trust packets that contain textual non-global addresses as should not trust packets that contain textual non-global addresses as
data. Software that obtains a zone identifier through a UI should, data. Therefore, software that obtains a zone identifier through a
therefore, not transmit it further. UI should not transmit it further.
There is no formal limit on the length of the zone identifier string There is no formal limit on the length of the zone identifier string
in RFC 4007. A UI implementation should apply an appropriate length in [RFC4007]. A UI implementation should apply an appropriate length
limit when inputting a zone identifier, in order to minimize the risk 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 of a buffer overrun. Typically, this limit would be the same as the
host operating system's limit on interface names. host operating system's limit on interface names.
RFC 4007 does not specify or restrict the character set allowed in a [RFC4007] does not specify or restrict the character set allowed in a
zone identifier. Therefore, each implementation processing zone zone identifier. Therefore, each implementation processing zone
identifiers needs to make checks appropriate for the environment it identifiers needs to make checks appropriate for the environment it
is used in. For example, a UI implementation should not allow ASCII is used in. For example, a UI implementation should not allow ASCII
NULL characters in a zone identifier string as this could cause NULL characters in a zone identifier string as this could cause
inconsistencies in subsequent string processing. inconsistencies in subsequent string processing.
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document has no IANA actions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[BCP14] Best Current Practice 14, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
<https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
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>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005, DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/info/rfc4007>. <https://www.rfc-editor.org/info/rfc4007>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
8.2. Informative References [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>.
[I-D.ietf-6man-rfc6874bis] 8.2. Informative References
Carpenter, B. E., Cheshire, S., and R. M. 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>.
[I-D.ietf-v6ops-6mops] [IPv6-MOSTLY]
Buraglio, N., Caletka, O., and J. Linkova, "IPv6-Mostly Buraglio, N., Caletka, O., and J. Linkova, "IPv6-Mostly
Networks: Deployment and Operations Considerations", Work Networks: Deployment and Operations Considerations", Work
in Progress, Internet-Draft, draft-ietf-v6ops-6mops-01, 3 in Progress, Internet-Draft, draft-ietf-v6ops-6mops-01, 3
March 2025, <https://datatracker.ietf.org/doc/html/draft- March 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-v6ops-6mops-01>. ietf-v6ops-6mops-01>.
[I-D.schinazi-httpbis-link-local-uri-bcp] [LINK-LOCAL-URI]
Schinazi, D., "Best Practices for Link-Local Connectivity Schinazi, D., "Best Practices for Link-Local Connectivity
in URI-Based Protocols", Work in Progress, Internet-Draft, in URI-Based Protocols", Work in Progress, Internet-Draft,
draft-schinazi-httpbis-link-local-uri-bcp-03, 22 February draft-schinazi-httpbis-link-local-uri-bcp-03, 22 February
2024, <https://datatracker.ietf.org/doc/html/draft- 2024, <https://datatracker.ietf.org/doc/html/draft-
schinazi-httpbis-link-local-uri-bcp-03>. schinazi-httpbis-link-local-uri-bcp-03>.
[LL-HACK] Jin, P., "Snippets: IPv6 link-local connect hack", 2021, [LL-HACK] Jin, P., "Snippets: IPv6 link-local connect hack", 2021,
<http://web.archive.org/web/20210725030713/ <https://web.archive.org/web/20210725030713/
https://website.peterjin.org/wiki/ https://website.peterjin.org/wiki/
Snippets:IPv6_link_local_connect_hack>. Snippets:IPv6_link_local_connect_hack>.
[ONE-NET] NMEA, "The OneNet Standard for IP Networking of Marine [ONE-NET] NMEA, "The OneNet Standard for IP Networking of Marine
Electronic Devices", 2023, Electronic Devices", 2025,
<https://www.nmea.org/nmea-onenet.html>. <https://www.nmea.org/nmea-onenet.html>.
[POSIX] IEEE, "IEEE/Open Group Standard for Information [POSIX] IEEE, "IEEE/Open Group Standard for Information
Technology--Portable Operating System Interface (POSIX™) Technology--Portable Operating System Interface (POSIX™)
Base Specifications, Issue 8", IEEE Std 1003.1-2024, Base Specifications, Issue 8", IEEE Std 1003.1-2024,
DOI 10.1109/IEEESTD.2018.8423794, June 2024, DOI 10.1109/IEEESTD.2024.10555529, June 2024,
<https://doi.org/10.1109/IEEESTD.2024.10555529>. <https://doi.org/10.1109/IEEESTD.2024.10555529>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>. February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003, RFC 3493, DOI 10.17487/RFC3493, February 2003,
skipping to change at page 9, line 14 skipping to change at line 361
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>. <https://www.rfc-editor.org/info/rfc6454>.
[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing
IPv6 Zone Identifiers in Address Literals and Uniform IPv6 Zone Identifiers in Address Literals and Uniform
Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,
February 2013, <https://www.rfc-editor.org/info/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", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7622] Saint-Andre, P., "Extensible Messaging and Presence [RFC7622] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", RFC 7622, Protocol (XMPP): Address Format", RFC 7622,
DOI 10.17487/RFC7622, September 2015, DOI 10.17487/RFC7622, September 2015,
<https://www.rfc-editor.org/info/rfc7622>. <https://www.rfc-editor.org/info/rfc7622>.
[RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089, [RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089,
DOI 10.17487/RFC8089, February 2017, DOI 10.17487/RFC8089, February 2017,
<https://www.rfc-editor.org/info/rfc8089>. <https://www.rfc-editor.org/info/rfc8089>.
[RFC8925] Colitti, L., Linkova, J., Richardson, M., and T. [RFC8925] Colitti, L., Linkova, J., Richardson, M., and T.
Mrugalski, "IPv6-Only Preferred Option for DHCPv4", Mrugalski, "IPv6-Only Preferred Option for DHCPv4",
RFC 8925, DOI 10.17487/RFC8925, October 2020, RFC 8925, DOI 10.17487/RFC8925, October 2020,
<https://www.rfc-editor.org/info/rfc8925>. <https://www.rfc-editor.org/info/rfc8925>.
Appendix A. Change log Acknowledgements
This section is to be removed before publishing as an RFC.
* 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.
* draft-ietf-6man-zone-ui-03, 2024-09-09:
- Update RFC 7622 and RFC 8089 to remove citations of RFC 6874.
- Explicit mention of cancelled update to RFC 3986.
* draft-ietf-6man-zone-ui-04, 2024-10-14:
- Avoid specific example of length limit.
- Added optional command line parameter.
- Split Introduction into three sections.
- Added formal update to RFC 4007.
- Added three normative keywords.
- Minor text improvements.
* draft-ietf-6man-zone-ui-05, 2024-12-10:
- Corrected BCP14 tags.
* draft-ietf-6man-zone-ui-06, 2025-01-17:
- Removed erroneous reference to ASCII.
- Zone ID REQUIRED if o/s provides no default.
- Noted that the cited hack is no longer maintained.
* draft-ietf-6man-zone-ui-07, 2025-01-24:
- Noted that non-browser use of URIs is not affected.
* draft-ietf-6man-zone-ui-08, 2025-02-26:
- Reworded example of RFC1918 address.
- Refined scope of statement about web browsers.
- Noted that implementations should make character set checks.
* draft-ietf-6man-zone-ui-09, 2025-05-17:
- Adjusted formal requirement to be more precise (qualified MUST
instead of SHOULD).
- Added reference.
* draft-ietf-6man-zone-ui-10, 2025-05-19:
- Editorial comments from IESG members
Appendix B. Acknowledgements
This document owes a lot to the previous discussions that led to RFC This document owes a lot to the previous discussions that led to
6874 and to the abandoned draft [I-D.ietf-6man-rfc6874bis]. [RFC6874] and to the expired Internet-Draft [RFC6874bis].
Useful comments were received from Erik Auerswald, Nick Buraglio, Useful comments were received from Erik Auerswald, Nick Buraglio,
Martin J. Dürst, Toerless Eckert, David Farmer, Brian Haberman, Nate Martin J. Dürst, Toerless Eckert, David Farmer, Brian Haberman, Nate
Karstens, Tero Kivinen, Erik Kline, Jen Linkova, Eduard Metz, Gyan Karstens, Tero Kivinen, Erik Kline, Jen Linkova, Eduard Metz, Gyan
Mishra, Ole Troan, David Schinazi, Jürgen Schönwälder, Michael Sweet, Mishra, David Schinazi, Jürgen Schönwälder, Michael Sweet, Martin
Martin Thomson, Éric Vyncke, Magnus Westerlund, and other Thomson, Ole Troan, Éric Vyncke, Magnus Westerlund, and other
participants in the 6MAN WG. participants in the 6MAN WG.
Authors' Addresses Authors' Addresses
Brian Carpenter Brian Carpenter
School of Computer Science School of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland 1142 Auckland 1142
New Zealand New Zealand
 End of changes. 51 change blocks. 
248 lines changed or deleted 125 lines changed or added

This html diff was produced by rfcdiff 1.48.