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:

    SYNTAX      DisplayString
    MAX-ACCESS  read-only
    STATUS      current
            "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;
             "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
   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.


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.