Go version

go1.22-20240109-RC01 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/usr/local/google/home/furry/.cache/go-build'
GOENV='/usr/local/google/home/furry/.config/go/env'
GOEXE=''
GOEXPERIMENT='fieldtrack,boringcrypto'
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/usr/local/google/home/furry/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/usr/local/google/home/furry/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/google-golang'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/lib/google-golang/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22-20240109-RC01 cl/597041403 +dcbe772469 X:fieldtrack,boringcrypto'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='0'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3244063302=/tmp/go-build -gno-record-gcc-switches'

What did you do?

https://go.dev/play/p/FwpGyqH1hio

package main

import (
"fmt"
"net/netip"
)

func main() {

// An IPv4-mapped IPv6 Address (RFC4291).
ipv4Mapped := "::ffff:192.0.2.1"

// An IPv6 address synthesized from a "Well-Known Prefix" (64:ff9b::/96, RFC6052)
nat64WKP := "64:ff9b::192.0.2.1"

// An IPv6 address synthesized from a Local-Use IPv4/IPv6 Translation Prefix
// (64:ff9b:1::/48, RFC8215) and 192.0.2.1
rfc8215WKP := "64:ff9b:1::192.0.2.1"

// Printing the addresses in their canonical text representation,
// rfc5952#section-5
fmt.Printf("IPv4-mapped address: %s\n", netip.MustParseAddr(ipv4Mapped).String())
fmt.Printf("NAT64 address: %s\n", netip.MustParseAddr(nat64WKP).String())
fmt.Printf("RFC8215 address: %s\n", netip.MustParseAddr(rfc8215WKP).String())

}

What did you see happen?

The output:

IPv4-mapped address: ::ffff:192.0.2.1
NAT64 address: 64:ff9b::c000:201
RFC8215 address: 64:ff9b:1::c000:201

Only the first address is printed in mixed notation (https://datatracker.ietf.org/doc/html/rfc5952#section-5). That indicates that Is4In6() only recognizes ::ffff:0:0/96 as a well-known prefix, used for embedding IPv4 addresses into IPv6 ones.

Both 64:ff9b::/96 (RFC6052) and 64:ff9b:1::/48 (RFC8215) prefixes are not recognized as used for having IPv4 addresses embedded in the lower 32 bits.

As both prefixes are well-known and reserved by IANA (https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml), I believe Is4In6() shall be updated (happy to write that code, indeed).

P.S. I'd also argue that for backwards compatibility it would be beneficial to recognize ::/96 as a Well-Known Prefix, despite its deprecation, as there are still systems around which might be using it.

What did you expect to see?

All 3 addresses shall be represented using mixed notation, as per https://datatracker.ietf.org/doc/html/rfc5952#section-5

"mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix.
Such prefixes are defined in [RFC4291] and [RFC2765] at the time of this writing."