Thanks for creating this @mdlayher, and I'm glad you found an actual reference to prefixes with zones.

As a kind of user story, here's what led me to bothered by the current behaviour:

I'm writing a library to help people extract the correct client IP from X-Forwarded-For and other headers (because right now it's being done wrong way too often). One of the strategies for doing that is to configure a list of trusted IP ranges containing the IPs inhabited by the trusted reverse proxies. The IPs in the XFF headers are searched from the rightmost, looking for the first one that isn't contained by a trusted prefix. (This is similar to what Nginx's X-Real-IP module does.)

It's written using net types rather than netip. I was considering switching to the latter when @mdlayher randomly told me about the prefix behaviour difference. I realized that if I naively switched from net.IPNet to netip.Prefix I would introduce a bug: users would be able to "successfully" configure prefixes with zones -- whereas before those prefixes would produce errors -- and then the prefixes would silently fail to contain any IPs with zones.

I ended up adding an explicit check for zones and returning an error, to help my future self from introducing the bug.

So the current behaviour adds some burden for those of us writing libraries that use netip.Prefix and then exposing a different interface to it. We don't know beforehand what our users might throw at us. We either need to add explicit zone checks (like I did) or add a documentation caveat about zones causing silent failures (like netip.Prefix.Contains does).

I know that the current behaviour is working as documented, but (as I said in the blog post) I think a lot of people simply won't see the documentation. Because:

1. The "Prefixes strip zones" warning is only on Prefix.Contains and not on Prefix or ParsePrefix. Kind of easy to miss.
2. The API is very simple and most of us have a reasonably good idea of what it means for a prefix/CIDR/range to "contain" and IP. So we just won't look at the doc.
3. If we've used net.CIDR, then we're even less likely to think we need to read the doc for the analogous facilities in netip. And then we'll introduce quiet bugs.

(FWIW, I prefer @mdlayher's "parse prefix zones for any type of IPv6 address prefix" option.)

I'm torn on this. My main worry is that using zones for anything higher level than very low-level networking configuration (e.g. IPv6 autoconfiguration, DHCPv6, dynamic routing protocols) is almost certainly a mistake on the part of the person using zones. In the original IPv6 designs, zones were going to be a much more generally useful thing, but these days their only use is to disambiguate link-local communication, and in turn link-local communication should only be used as a stepping stone towards configuring globally-scoped IPv6.

So, when we designed netaddr, we tried to find a legitimate use for scoped prefixes, and concluded that the only beneficiaries would be malicious inputs trying to confuse code that wasn't written with scope-awareness. That's how we ended up with the scope stripping behavior for prefixes. We had to keep zones for single IPs, since that is definitely both necessary and useful for things like CoreRAD, which have to wrestle with link-local communication. (Unfortunately, IMO, because I'd have loved to lose zones entirely)

The thing I'm torn on is whether the use cases in this bug are a legitimately useful/necessary use of zones in prefixes, or if we're arguing about supporting a hypothetical edge case for completeness, at the cost of making mainstream uses of the package harder.

In particular, I would like us to not consider the existence of an RFC as proof that something is necessary or useful. Especially in IPv6, which has gone through decades of redesign and refinement, there are a lot of RFCs out there that encourage what we now know to be bad ideas. So, an RFC alone should not be our guide as to how APIs should behave, because if we did that, we'd end up with a lot of really whacky behavior all over the place.

Currently, our only example of wanting to use zones in prefixes is a library for use in HTTP, where I would argue zones should never be appearing in the first place. What's the failure mode of the current behavior? IIUC, it causes false negatives, that is, source IPs that should be trusted end up not being trusted, because of the zone mismatch. Is that correct? If that's the extent of the impact, then my preference would be to treat this as a documentation issue, and make it more explicit that netip Prefixes cannot have zone specifiers.

If there is a compelling reason to force all users of netip.Prefix to care about zone specifiers, then I think I would reluctantly advocate for consistency and allowing them for all prefixes, rather than hardcoding an exception for fe80::/10. "Zones suck and you have to always deal with them" is an easier thing to explain in documentation, and to discover in tests, than "zones will sometimes cause you got shoot yourself in the foot, but only in edge cases you may not think about as a beginner user of netip".

On top of all the above, we'll have to consider the Go 1 compatibility promise: now that a release exists in which Prefixes strip zones, I don't think we can silently change the behavior of existing prefix constructors. So, if we do want to support that, do we end up having to create WithZone constructor equivalents for all the current ways in which you can obtain a Prefix? That would mean duplicating or backwards-compatibly augmenting the semantics of the following API surface:

• Addr.Prefix(bits)
• MustParsePrefix(s)
• ParsePrefix(s)
• Prefix.Masked()
• Prefix.Overlaps(other)

Another variation on not supporting zones that I would prefer to the current beahviour: Have ParsePrefix return an error if there's a zone present.

This is the same as the net.ParseCIDR behaviour, but may still be unpalatable as it's a behaviour change for ParsePrefix.

Silently dropping zones seems like the worst of all worlds: Incorrect and surprising.

While having ParsePrefix return an error if a zone is present is a behavior change, the current behavior is documented as parsing RFC 4291 notation and RFC 4291 does not (unless I'm missing something) allow for zones in prefixes. Therefore I think it's reasonable to say that accepting prefixes with zones is simply a bug, and ParsePrefix should return an error for this condition just as ParseCIDR does.

https://www.rfc-editor.org/rfc/rfc4291.html#section-2.3

Interesting, I suppose I had never bothered to check the docs for ParseCIDR since I've been pretty intimately familiar with its use. You're correct: section 2.3 here makes no mention of IPv6 zones at all and simiply says:

... An IPv6 address prefix is represented by the notation:

      ipv6-address/prefix-length

   where

      ipv6-address    is an IPv6 address in any of the notations listed
                      in [Section 2.2](https://www.rfc-editor.org/rfc/rfc4291.html#section-2.2).

      prefix-length   is a decimal value specifying how many of the
                      leftmost contiguous bits of the address comprise
                      the prefix.

Since updating netip.ParsePrefix makes the behavior consistent with net.ParseCIDR, I'm good with making that change. I will send a CL.

Change https://go.dev/cl/396299 mentions this issue: net/netip: return an error from ParsePrefix with IPv6 zone input