Skip to main content

Entering IPv6 Zone Identifiers in User Interfaces
draft-ietf-6man-zone-ui-03

Document Type Active Internet-Draft (6man WG)
Authors Brian E. Carpenter , Bob Hinden
Last updated 2024-10-12 (Latest revision 2024-09-08)
Replaces draft-carpenter-6man-zone-ui
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state Waiting for WG Chair Go-Ahead
Document shepherd Jen Linkova
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to furry13@gmail.com
draft-ietf-6man-zone-ui-03
6MAN                                                        B. Carpenter
Internet-Draft                                         Univ. of Auckland
Obsoletes: 6874 (if approved)                                  R. Hinden
Updates: 7622, 8089 (if approved)                   Check Point Software
Intended status: Standards Track                        8 September 2024
Expires: 12 March 2025

           Entering IPv6 Zone Identifiers in User Interfaces
                       draft-ietf-6man-zone-ui-03

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 and
   updates RFC 7622 and RFC 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

   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 12 March 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Carpenter & Hinden        Expires 12 March 2025                 [Page 1]
Internet-Draft            IPv6 Zone IDs in UIs            September 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
     1.1.  Open Issue  . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Normative Terminology . . . . . . . . . . . . . . . . . . . .   5
   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Change log . . . . . . . . . . . . . . . . . . . . .   9
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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 unicast addresses and multicast addresses with
   less than global scope, such that a zone identifier may be
   concatenated to an address, for purposes described in that
   specification.  Note that RFC 5952 does not mention this extension.

   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 unicast and
   scoped multicast addresses, but it is possible that other uses might
   be defined in the future.

Carpenter & Hinden        Expires 12 March 2025                 [Page 2]
Internet-Draft            IPv6 Zone IDs in UIs            September 2024

   Examples of a link-local unicast address qualified by a zone
   identifier are "fe80::1234%eth0" on a Linux host, or "fe80::4321%7"
   on a Windows host.

   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 on a given interface whose
       traffic is of interest.  (At the time of writing, Wireshark
       supports capture from multiple interfaces, but does not appear to
       support the zone identifier in a display filter.)

   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 the "OneNet Marine IPv6 Ethernet Networking Standard"
       [ONE-NET], which uses IPv6 link local addresses exclusively.
       Desired improvements to the standard include a web page for
       device configuration using link-local addresses.

   Such requirements have already spawned hacks to work around current
   limitations, e.g., [LL-HACK].

Carpenter & Hinden        Expires 12 March 2025                 [Page 3]
Internet-Draft            IPv6 Zone IDs in UIs            September 2024

   For all such use cases, it is highly desirable that a complete IPv6
   link-local address can be cut and pasted from one UI (such as the
   output from a system command) to another.  Since such addresses may
   include quite long hexadecimal strings, for example
   "fe80::8d0f:7f26:f5c8:780b%enx525400d5e0fb", any solution except cut-
   and-paste is highly error prone.

   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, including Linux, do not, and for them a solution is
   particularly important, since a link-local address without a zone
   index cannot be used in the Linux socket API.

   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 more widespread, the lack of a solution
   for handling complete link-local addresses in all tools is becoming
   an acute problem for increasing numbers of operational and support
   personnel.  It will become critical as IPv6-only or IPv6-mostly
   networks [RFC8925] [I-D.link-v6ops-6mops], with nodes lacking native
   IPv4 support, appear.  For example, the NMEA use case mentioned above
   is an immediate requirement.  This is the principal reason for
   documenting this requirement now.

Carpenter & Hinden        Expires 12 March 2025                 [Page 4]
Internet-Draft            IPv6 Zone IDs in UIs            September 2024

   This document obsoletes [RFC6874], which implementors of web browsers
   have determined is impracticable to support
   [I-D.schinazi-httpbis-link-local-uri-bcp], and replaces it by a
   generic UI requirement described below.  Note that obsoleting RFC
   6874 reverts the change that it made to the URI syntax defined by
   [RFC3986], so RFC 3986 is no longer updated by RFC 6874.  This
   document also updates [RFC7622] and [RFC8089] by deleting their
   references to RFC 6874.

1.1.  Open Issue

   This section is to be removed before publishing as an RFC.

   This document effectively extends RFC 4007.  Should this be recorded
   as a formal update to RFC 4007?

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
   [BCP14] 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 *SHOULD* provide a means for entering a link-local
   address or a scoped multicast address and selecting a zone identifer
   as specified by [RFC4007] (typically, an interface identifier as
   defined by the operating system).

   Ideally, the UI will support the complete format specified by RFC
   4007 (e.g., "fe80::1%eth0").

   If this is impossible for practical reasons, the UI could support an
   alternative delimiter in place of "%".  The hyphen ("-") is suggested
   (e.g., "fe80::1-eth0").

   If this too is impossible for practical reasons, the UI could support
   two separate input fields (e.g., "fe80::1" in one box, "eth0" in
   another), or selection from a list of active zone identifiers.

Carpenter & Hinden        Expires 12 March 2025                 [Page 5]
Internet-Draft            IPv6 Zone IDs in UIs            September 2024

   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.

   Note that an address string such as "fe80::1%eth0" cannot be
   converted to binary by the POSIX socket API function "inet_pton()".
   It must either be converted using "getaddrinfo()", or by splitting it
   into two strings and using "inet_pton()" and "if_nametoindex()"
   successively, in order to obtain the required interface index value.

   In this model, the zone identifier is considered independently of the
   IPv6 address itself.  However, this does not in itself resolve the
   difficulties in considering the zone identifier as part of the HTTP
   origin model [RFC6454].  Therefore, this approach does not resolve
   the issue of how browsers should support link-local addresses,
   discussed further in [I-D.schinazi-httpbis-link-local-uri-bcp].
   Because of this, the recommendations and normative statements in this
   document do not apply to web browsers.

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, which indicates that software
   should not trust packets that contain textual non-global addresses as
   data.  Software that obtains a zone identifier through a UI should
   therefore not transmit it further.

   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.

   RFC 4007 does not specify the character set allowed in a zone
   identifier.  An implementation should not allow 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

Carpenter & Hinden        Expires 12 March 2025                 [Page 6]
Internet-Draft            IPv6 Zone IDs in UIs            September 2024

6.1.  Normative References

   [BCP14]    Best Current Practice 14,
              <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,
              DOI 10.17487/RFC2119, March 1997,
              <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
              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>.

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>.

   [I-D.link-v6ops-6mops]
              Linkova, J. and N. Buraglio, "IPv6-Mostly Networks:
              Deployment and Operations Considerations", Work in
              Progress, Internet-Draft, draft-link-v6ops-6mops-01, 7
              July 2024, <https://datatracker.ietf.org/doc/html/draft-
              link-v6ops-6mops-01>.

Carpenter & Hinden        Expires 12 March 2025                 [Page 7]
Internet-Draft            IPv6 Zone IDs in UIs            September 2024

   [I-D.schinazi-httpbis-link-local-uri-bcp]
              Schinazi, D., "Best Practices for Link-Local Connectivity
              in URI-Based Protocols", Work in Progress, Internet-Draft,
              draft-schinazi-httpbis-link-local-uri-bcp-03, 22 February
              2024, <https://datatracker.ietf.org/doc/html/draft-
              schinazi-httpbis-link-local-uri-bcp-03>.

   [LL-HACK]  Jin, P., "Snippets: IPv6 link-local connect hack", 2021,
              <http://web.archive.org/web/20210725030713/
              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>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
              DOI 10.17487/RFC6454, December 2011,
              <https://www.rfc-editor.org/info/rfc6454>.

   [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>.

   [RFC7622]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Address Format", RFC 7622,
              DOI 10.17487/RFC7622, September 2015,
              <https://www.rfc-editor.org/info/rfc7622>.

   [RFC8089]  Kerwin, M., "The "file" URI Scheme", RFC 8089,
              DOI 10.17487/RFC8089, February 2017,
              <https://www.rfc-editor.org/info/rfc8089>.

   [RFC8925]  Colitti, L., Linkova, J., Richardson, M., and T.
              Mrugalski, "IPv6-Only Preferred Option for DHCPv4",
              RFC 8925, DOI 10.17487/RFC8925, October 2020,
              <https://www.rfc-editor.org/info/rfc8925>.

Carpenter & Hinden        Expires 12 March 2025                 [Page 8]
Internet-Draft            IPv6 Zone IDs in UIs            September 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

   *  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

Carpenter & Hinden        Expires 12 March 2025                 [Page 9]
Internet-Draft            IPv6 Zone IDs in UIs            September 2024

   *  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.

Appendix B.  Acknowledgements

   This document owes a lot to the previous discussions that led to RFC
   6874 and to the abandoned draft [I-D.ietf-6man-rfc6874bis].

   Useful comments were received from Nick Buraglio, Martin J.  Dürst,
   Toerless Eckert, David Farmer, Brian Haberman, Nate Karstens, Jen
   Linkova, Eduard Metz, Gyan Mishra, Ole Troan, David Schinazi, Michael
   Sweet, Martin Thomson, Éric Vyncke, and other participants in the
   6MAN WG.

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 12 March 2025                [Page 10]