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., the hack described in [LL-HACK], which is no | |||
been archived). | longer maintained and has 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 | NUL 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, "OneNet Marine IPv6 Ethernet Networking Standard", | |||
Electronic Devices", 2023, | 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 360 ¶ | |||
[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. 53 change blocks. | ||||
253 lines changed or deleted | 129 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |