Parse IPv6 zone identifiers

Proposal

Extend the Ipv6Addr struct with support for zone identifiers (interface indexes and interface names) including string parsing.

Problem statement

Ipv6 addresses have zone identifiers (<address>%<zone_id>) for e.g. link-local and multicast addresses as per RFC4007. This is currently not supported by the core and std implementations of an Ipv6Addr.

Motivating examples or use cases

Use cases include addressing multicast IP addresses on specific interfaces for e.g. wake on LAN when the default route does not exit into the local network where devices are located or neighbor discovery over multicast on specific interfaces for dynamic routing protocols.

Other expected uses actively break when trying to parse a file that contains an Ipv6 address scoped using an interface name (e.g. hickory DNS and /etc/resolv.conf containing nameserver fe80::2a0:57ff:fe6f:42ee%wlp3s0).

Solution sketch

• move Ipv6 address zone identifier from SocketAddrV6 to Ipv6Addr
• add libc::if_nametoindex wrappers to platform specific APIs in std
• add the ability to extend the core::net::parser Ipv6 parser with custom zone identifier parsers
• extend the Ipv6 parser to resolve zone identifier by name in std

Alternatives

• only adding interface name resolution to SocketAddrV6 in std
  • cons: this will not work when parsing IP addresses, only socket addresses

Links and related work

https://datatracker.ietf.org/doc/html/rfc3513
https://datatracker.ietf.org/doc/html/rfc4007
https://datatracker.ietf.org/doc/html/rfc3493
https://github.com/rust-lang/rust/issues/65976

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

Start with the existing core and std implementations of Ipv6Addr and SocketAddrV6, then inspect the core::net::parser entry points and the proposed libc interface-name wrappers. A complete contribution requires an agreed API for numeric and named zones, parsing behavior, and std resolution; this proposal is still awaiting libs-api review.