net/netip: ParseAddr should reject invalid zone

[qinlonglong123]

Proposal Details

I have the following use case:

package main

import (
    "fmt"
    "net/netip"
)

func main() {
    addr, err := netip.ParseAddr("2006:abcd::1%%")
    fmt.Printf("addr = %s,zone = %s,err = %v\n", addr.String(), addr.Zone(), err)
}

https://go.dev/play/p/soSl7hzPhJx
output:

addr = 2006:abcd::1%%,zone = %,err = <nil>

When running with Go 1.23, it considers the last % as the IPv6 zone ID. However, when parsing the same address in other languages, it considers the parameter as an invalid IP, for example:

1.C Language

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <netdb.h>
#include <arpa/inet.h>

const char* parse_ipv6_with_zone_id(const char *input) {
    struct addrinfo hints, *res;
    int status;

    memset(&hints, 0, sizeof(hints));
    hints.ai_family = AF_INET6;
    hints.ai_socktype = SOCK_STREAM;

    status = getaddrinfo(input, NULL, &hints, &res);

    if (status != 0) {
        return "Invalid";
    }

    freeaddrinfo(res);
    return "Valid";
}

int main() {
    const char *input1 = "2006:abcd::1%%";

    printf("Address 1: %s - %s\n", input1, parse_ipv6_with_zone_id(input1));

    return 0;
}

gcc version

gcc version 10.3.1 (GCC)

and output:

Address 1: 2006:abcd::1%% - Invalid

2. java

import java.net.Inet6Address;
import java.net.InetAddress;
import java.net.URI;
import java.net.URISyntaxException;

public class IPv6ZoneIDParser {
 public static void main(String[] args) {
        final String ipv6WithZone = "2006:abcd::1%%";
        try {
            InetAddress inetAddress = InetAddress.getByName(ipv6WithZone);
            if (inetAddress instanceof Inet6Address) {
                System.out.println(ipv6WithZone + " It is an IPv6 address.");
            }

        } catch (java.net.UnknownHostException e) {
            System.out.println(ipv6WithZone + " It is a invalid ip address.");
        }
    }
}

java -version
openjdk version "1.8.0_392"

output:
2006:abcd::1%% It is a invalid ip address.

3. python

import ipaddress

def is_valid_ip(ip):
    try:
        ipaddress.ip_address(ip)
        return True
    except ValueError:
        return False

print(is_valid_ip("2006:abcd::1%%"))

python version
Python 3.9.11 (main, Jul 18 2024, 15:21:06)

output:
False

why Go language behaves differently when parsing IPv6 zone IDs compared to other languages as shown above? Thank you.

[gabyhelp]

Related Issues

• net/ip: ParsePrefix with IPv6 zone should return an error #51899 (closed)
• net: Unable to reliably distinguish IPv4-mapped-IPv6 addresses from regular IPv4 addresses #37921
• net/netip: Document of `AddrFromSlice` doesn't mention that passing IPv4 `net.IP` made with `net.ParseIP` to `AddrFromSlice` creates IPv4 mapped IPv6 `netip.Addr` #54826
• net/netip: ParseAddr gives different values with same input #50111 (closed)
• net: `ParseIP` returns nil instead of IP to a seemingly valid IPv6 #69752 (closed)
• net: ipv6 address parsing allows extra 0 #57760 (closed)
• net: LookupNetIP returns IPv4 in IPv6 instead of IPv4 #53554 (closed)
• netip.ParsePrefix must not silently accept ip4in6 address #53135 (closed)
• net/netip: ParsePrefix documentation typo "2001::db8::/32" #50950 (closed)

Related Code Changes

• net/netip: return an error from ParsePrefix with IPv6 zone input

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

I think this should be a bug not a proposal.
RFC6874 https://datatracker.ietf.org/doc/html/rfc6874 has

ZoneID = 1*( unreserved / pct-encoded )
IPv6addrz = IPv6address "%25" ZoneID

referring to RFC3986 https://datatracker.ietf.org/doc/html/rfc3986#section-2.3

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

a lone % should be considered invalid.

[gopherbot]

Change https://go.dev/cl/642896 mentions this issue: net/netip: reject invalid zone identifiers in ParseAddr

[ianlancetaylor]

Note that as far as I can see the C program does not accept any zone ID at all.

[qinlonglong123]

Note that as far as I can see the C program does not accept any zone ID at all.

Sorry, the above C program cannot be used as one of the validation programs, because even a normal IPv6 address with a zone ID cannot be resolved.Thank you for your correction.

[seankhliao]

From CL 642896, windows contains a builtin "Loopback Pseudo-Interface 1" (contains spaces)
and linux accepts interface names like # or &.
I'm not sure what sort of validation (if any) we can do on the zone.

[seankhliao]

The python docs point to RFC 4007.
Section 11.2 includes the following: https://datatracker.ietf.org/doc/html/rfc4007.html#section-11.2

  An implementation MAY support other kinds of non-null strings as
   <zone_id>.  However, the strings must not conflict with the delimiter
   character.  The precise format and semantics of additional strings is
   implementation dependent.

That points to % being the only disallowed character, which somewhat conflicts with RFC6874's pct-encoded.
Given that we don't know if ParseAddr is going to operate on an encoded or decoded form, perhaps we just shouldn't try to validate it (keep things as is).

[qinlonglong123]

The python docs point to RFC 4007. Section 11.2 includes the following: https://datatracker.ietf.org/doc/html/rfc4007.html#section-11.2

  An implementation MAY support other kinds of non-null strings as
   <zone_id>.  However, the strings must not conflict with the delimiter
   character.  The precise format and semantics of additional strings is
   implementation dependent.

That points to % being the only disallowed character, which somewhat conflicts with RFC6874's pct-encoded. Given that we don't know if ParseAddr is going to operate on an encoded or decoded form, perhaps we just shouldn't try to validate it (keep things as is).

I personally believe that the pct-encoding in RFC6874 refers to the special characters in the URI's host, which should be represented in pct-encoded form. If we only consider the ParseAddr function, it should not take encoding into account. Because url.Parse already decodes pct-encoded characters.

[seankhliao]

Looks like python only checks for % https://github.com/python/cpython/blob/e3b3e01d6a6f43c15890d14f139f38155601643a/Lib/ipaddress.py#L1911

I don't think java is a good reference, it rejects any scope / zone that isn't a numeric: https://codapi.org/embed/?sandbox=java&code=data%3A%3Bbase64%2ClZHBSsNAEIbveYohICQIoXrIoaGHioK5SLGIoHiYbrbtaDK77E5jg%2BTdJbbUNMSDc1h295%2F959sZqqxxAu9YY8Jakpy1pPOicNr7LKAR9U%2Fx6TEfvVw2LLi%2F2ytthQxnQWB3q5IUqBK9h3xRpy%2BGdX67QOe1g68AjgleUEhBbaiAComjpTjizesboNv4uMs8xpoYSzjIQLZOn0m2nSvMILyeTNIprlQxnV5daJ6E2emduKbn0kXvi0C9%2FayvJBstN80DVjrqF4uzMytaQ0Rndl6QlTZr6Lc5HhB0sWy86CoxO0msI5aSzwrBJYSQC5AH5J8OAh7JwgFEG5yOLSgUtYXodzr8weaT742X03xAD4H%2BAQPENZZUANlRojY4rO03

I still think we can choose to not validate it at all.