Interface and Zone Names
Network interfaces are identified by a numeric interface index or an interface name. The definition of interface indexes and names goes back to the early days of SNMP, see for example RFC 1066 (published in 1988). In the late 1990s, a scoped address architecture was introduced by RFC 2373 (published in 1998), and with it came zone indexes and zone names, both were introduced in RFC 4007 (published in 2005).
Note that Interface indexes and zone indexes as well as interface names and zone names are related concepts but not necessarily the same. However, in today’s deployed Internet technology, interface indexes and interface names are commonly used as zone indexes and zone names since they work well of link-local scopes and other non-global scopes are not widely deployed.
Interface indexes and names
Historically, there was just an interface index, i.e., a number
identifying a network interface. The interface number goes back to the
early days of SNMP, see for example RFC
1066 (published in 1988). Six years
later, RFC 1573 introduced the
notion of an interface name. RFC
2863 (published in 2000) defines
ifName as follows:
ifName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The textual name of the interface. The value of this
object should be the name of the interface as assigned by
the local device and should be suitable for use in commands
entered at the device's `console'. This might be a text
name, such as `le0' or a simple port number, such as `1',
depending on the interface naming syntax of the device. If
several entries in the ifTable together represent a single
interface as named by the device, then each will have the
same value of ifName. Note that for an agent which responds
to SNMP queries concerning an interface on some other
(proxied) device, then the value of ifName for such an
interface is the proxied device's local name for it.
If there is no local name, or this object is otherwise not
applicable, then this object contains a zero-length string."
::= { ifXEntry 1 }
Note that a DisplayString is a string of ASCII characters with some
additional constraints. When the YANG module of network interfaces was
defined in 2014 (RFC 7223), there
were discussions around the corresponding YANG leaf
interfaces/interface/name and how to align it with the definition of
an ifName. The latest version of the interfaces YANG module defined
in RFC 8343 (2018) says:
leaf name {
type string;
description
"The name of the interface.
A device MAY restrict the allowed values for this leaf,
possibly depending on the type of the interface.
For system-controlled interfaces, this leaf is the
device-specific name of the interface.
[...]";
}
Note that a string here is a UTF-8 string, i.e., it allows for a much larger set of characters. Hence the warning that implementations may have further restrictions.
Zone indexes and names
Zone index and names were introduced in 2005 in RFC 4007. However, RFC 4007 is not very specific about the format of valid zone names. While interface names are discussed as possible zone names, there is no clear definition what constitutes a valid or an invalid zone index or name.
RFC 6021 (published in 2010) defined the zone index as part of the YANG definition of an ipv6-address. The description says:
The zone index is used to disambiguate identical address
values. For link-local addresses, the zone index will
typically be the interface index number or the name of an
interface. If the zone index is not present, the default
zone of the device will be used.
The pattern used for the zone index was [\p{N}\p{L}]+ where \p{L} matches a single code point in the category “letter” and \p{N} matches any kind of numeric character in any script. In hindsight, this may have been a bad choice, it is unclear whether numeric characters in any script are desirable and perhaps more problematic, this definition does not allow any punctuation characters.
The latest work on zone indexes and zone names appears to be draft-ietf-6man-rfc6874bis-05 (last updated in 2022). This specification (which has passed working group last call and is waiting for the IESG decision) says:
A zone identifier MUST contain only ASCII characters classified as
"unreserved" for use in URIs [RFC3986]. This excludes characters
such as "]" or even "%" that would complicate parsing. For the
avoidance of doubt, note that a zone identifier consisting of "25" or
starting with "25" is valid and is used in some operating systems. A
parser MUST NOT apply percent decoding to the IPv6 address literal in
a URI, including cases such as http://[fe80::abcd%25] and
http://[fe80::abcd%25xy].
If an operating system uses any other characters in zone or interface
identifiers that are not in the "unreserved" character set, they
cannot be used in a URI.
RFC 3986 defines unreserved ASCII characters as follows:
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
While this text is pretty specific, it also acknowledges that there may be zone (or interface) names that fall outside of the more restricted format. And while the format allows for the dash character, it does not allow for the forward slash character. Hence, Juniper style interface names (ge-0/0/0.0) or Cisco style interface names (Ethernet1/0/1) will not work as a zone name embedded in a URI.
Discussion
It is very difficult to retroactively define a format for something that was not fully specified when it was introduced. Both, the current YANG definition as well as the URI definition are rather restrictive. One option could be to align the YANG definition with the URI definition by restricting the characters to unreserved RFC 3986 characters, but to allow the forward slash since this character is widely used in the industry. This way, there is at least some commonality between IETF definitions and YANG zones would form a proper super-set of the zone names that can appear in URIs.