Entering IPv6 Zone Identifiers in User Interfaces
draft-carpenter-6man-zone-ui-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Brian E. Carpenter , Bob Hinden | ||
| Last updated | 2024-01-15 | ||
| Replaced by | draft-ietf-6man-zone-ui | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-carpenter-6man-zone-ui-00
6MAN B. Carpenter
Internet-Draft Univ. of Auckland
Obsoletes: 6874 (if approved) R. Hinden
Intended status: Standards Track Check Point Software
Expires: 18 July 2024 15 January 2024
Entering IPv6 Zone Identifiers in User Interfaces
draft-carpenter-6man-zone-ui-00
Abstract
This document describes how the zone identifier of an IPv6 scoped
address, defined in the IPv6 Scoped Address Architecture (RFC 4007),
should be entered into a user interface. It obsoletes RFC 6874.
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
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 July 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Carpenter & Hinden Expires 18 July 2024 [Page 1]
Internet-Draft IPv6 Zone IDs in UIs January 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Normative Terminology . . . . . . . . . . . . . . . . . . . . 4
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 7
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
A number of software tools require or permit the user to enter an
IPv6 address via a user interface (UI). The standard literal text
format for an IPv6 address is defined by [RFC4291] and [RFC5952].
The IPv6 Scoped Address Architecture specification [RFC4007] extends
the text representation of limited-scope IPv6 addresses, in
particular link-local addresses, such that a zone identifier may be
concatenated to an address, for purposes described in that
specification. Zone identifiers are especially useful in contexts in
which literal addresses are typically used, for example during fault
diagnosis or device configuration, when it may be essential to
specify which interface is used for sending to a link-local address.
It should be noted that zone identifiers have purely local meaning
within the node in which they are defined, usually being the same as
IPv6 interface names. They are completely meaningless for any other
node. Today, they are meaningful only when attached to link-local
addresses, but it is possible that other uses might be defined in the
future.
Examples of a link-local address qualified by a zone identifier are
"fe80::1234%eth0" on a Linux host, or "fe80::4321%7" on a Windows
host.
Carpenter & Hinden Expires 18 July 2024 [Page 2]
Internet-Draft IPv6 Zone IDs in UIs January 2024
Such addresses are directly supported by socket API calls including
"getaddrinfo()" [RFC3493].
Devices whose network stack does not support the RFC 4007 model of a
human-readable zone identifier are out of scope for this document.
Some examples of use cases for entering such an address in a UI are
as follows:
1. A software tool may be used for simple debugging actions
involving link-local addresses on a host with more than one
active link interface. For example, the functioning of an
interface and the existence of a device may today be checked via
"ping fe80::1234%eth0". If this succeeds, the user learns that
the remote device is reachable via the interface named "eth0".
2. 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 more than one active link interface. For example,
a typical home router may today be configured via "192.168.178.1"
but not via "fe80::1%eth0", if the tool in use does not support
the input of zone identifiers.
3. Using a monitoring tool such as Wireshark, the user may need to
specify a given link-local address whose traffic is of interest.
4. The Microsoft Web Services for Devices (WSD) virtual printer port
mechanism can present the user with an IPv6 link-local address
such as "fe80::823b:f9ff:fe7b:d9dc%10" in which the zone
identifier is present, but is not recognized by appropriate
software.
5. The National Marine Electronics Association (NMEA) has recently
defined its "OneNet Marine IPv6 Ethernet Networking Standard"
[ONE-NET], which includes a specific requirement for device
configuration using link-local addresses. Such requirements have
already spawned a hack to work around the current limitation
[LL-HACK].
For all such use cases, it is highly desirable that a complete IPv6
link-local address can be cut and pasted from one UI (such as the
output from a system command) to another. Since such addresses may
include quite long hexadecimal strings, any solution except cut-and-
paste is highly error prone.
Carpenter & Hinden Expires 18 July 2024 [Page 3]
Internet-Draft IPv6 Zone IDs in UIs January 2024
The use cases listed above apply to relatively simple actions on end
systems. The zone identifiers that can be used are limited by the
host operating system, since RFC 4007 only specifies that they are
coded in ASCII, without specifying a maximum length.
It should be noted that whereas some operating systems and network
APIs support a default zone identifier as recommended by RFC 4007,
others do not, and for them a solution is particularly important.
The RFC 4007 model assumes that the human-readable zone identifier is
mapped by the operating system into a numeric interface index.
Typically this mapping is performed by the socket API, e.g. by
"getaddrinfo()". The mapping between the human-readable zone
identifier string and the numeric value is a host-specific function
that varies between operating systems. The present document is
concerned only with the human-readable string that is typically
displayed in an operating system's user interface. However, in most
operating systems it is possible to use the underlying interface
number, represented as a decimal integer, as an equivalent to the
human-readable string. This is recommended by Section 11.2 of RFC
4007, but not required. This possibility does not affect the UI
requirement given below.
As IPv6 deployment becomes widespread, the lack of a solution for
handling complete link-local addresses in all tools is becoming an
acute problem for increasing numbers of operational and support
personnel. It will become critical as IPv6-only networks, with no
native IPv4 support, appear. For example, the NMEA use case
mentioned above is an immediate requirement. This is the principal
reason for documenting this requirement now.
This document obsoletes [RFC6874] and replaces it by a generic UI
requirement described below.
2. Normative Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Specification
A user interface (UI) that allows or requires the user to enter an
IPv6 address *MUST* provide a means for entering a link-local address
qualified with a zone identifer as specified by [RFC4007] (typically,
an interface identifier as defined by the operating system).
Carpenter & Hinden Expires 18 July 2024 [Page 4]
Internet-Draft IPv6 Zone IDs in UIs January 2024
This UI *SHOULD* support the complete format specified by RFC 4007
(e.g., "fe80::1%eth0").
If this is impossible for practical reasons, the UI *MAY* support an
alternative delimiter in place of "%". The hyphen ("-") is
*RECOMMENDED* (e.g., "fe80::1-eth0").
If this too is impossible for practical reasons, the UI *MAY* support
two separate input fields (e.g., "fe80::1" in one box, "eth0" in
another).
The program providing the UI will then store the address and the zone
identifier, converting the latter to an interface index (typically
via the socket API). A faulty zone identifier will be detected when
attempting to convert it and this should be reported to the user as
an error. The resulting interface index will be used for any
subsequent socket calls using the link-local address.
4. Security Considerations
As explained in [RFC4007], zone identifiers are of local significance
and must not be sent on the wire. In particular, see the final
security consideration of RFC 4007.
Unfortunately there is no formal limit on the length of the zone
identifier string in RFC 4007. A UI implementation *SHOULD* apply a
reasonable length limit when inputting a zone identifier, in order to
minimize the risk of a buffer overrun. For example, a limit to 16
ASCII characters would correspond to the existing limit on Linux
interface names.
An implementation *SHOULD NOT* include ASCII NULL characters in a
zone identifier string as this could cause inconsistencies in
subsequent string processing.
5. IANA Considerations
This document makes no request of IANA.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Carpenter & Hinden Expires 18 July 2024 [Page 5]
Internet-Draft IPv6 Zone IDs in UIs January 2024
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/info/rfc4007>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[I-D.ietf-6man-rfc6874bis]
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>.
[LL-HACK] Jin, P., "Snippets: IPv6 link-local connect hack", 2021,
<https://website.peterjin.org/wiki/
Snippets:IPv6_link_local_connect_hack>.
[ONE-NET] NMEA, "The OneNet Standard for IP Networking of Marine
Electronic Devices", 2023,
<https://www.nmea.org/nmea-onenet.html>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/info/rfc3493>.
[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing
IPv6 Zone Identifiers in Address Literals and Uniform
Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,
February 2013, <https://www.rfc-editor.org/info/rfc6874>.
Carpenter & Hinden Expires 18 July 2024 [Page 6]
Internet-Draft IPv6 Zone IDs in UIs January 2024
Appendix A. Change log
This section is to be removed before publishing as an RFC.
* draft-carpenter-6man-zone-ui-00, 2024-01-15:
- Initial version
Appendix B. Acknowledgements
This document owes a lot to the previous discussions that led to RFC
6874 and to the unapproved draft [I-D.ietf-6man-rfc6874bis].
Useful comments were received from TBD.
Authors' Addresses
Brian Carpenter
School of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Robert M. Hinden
Check Point Software
959 Skyway Road
San Carlos, CA 94070
United States of America
Email: bob.hinden@gmail.com
Carpenter & Hinden Expires 18 July 2024 [Page 7]