IPv4-mapped IPv6 address cannot be used as route gateway

[3u13r]

Netlink still makes use of Golang's net package, instead of the newer netip package to represent prefixes and addresses. In multiple instances netlink checks if a user-given address is a IPv4 or an IPv6 address via nl.GetIPFamily(). This function calls ip.To4() and if this returns anything other than nil we identify ip to be a IPv4 address. The problem is that the function contract is not that .To4 returns not-nil for IPv4 addresses but it returns non-nil if the address can be represented as IPv4. The second definition includes IPv4-mapped IPv6 addresses, while the first does not.

Example:
I want to create the following route entry:

2300:5800:ab00::2 via ::ffff:100.95.128.2 dev br3 proto bgp onlink 

With ip one can do this by calling:

ip route add 2300:5800:ab00::2 via ::ffff:100.95.128.2 dev br3 proto bgp onlink

One would assume that the following Go code works:

nlh.RouteAdd(
			&netlink.Route{
				LinkIndex: remoteBridge.Attrs().Index,	// some index
				Dst:       route.Dst,					// 2300:5800:ab00::2/128
				Gw:        hostAddress.AsSlice(),		//::ffff:100.95.128.2
				Flags:     int(unix.RTNH_F_ONLINK),		// onlink
				Protocol:  186,							// bgp
			},
		)

But it returns gateway, source, and destination ip are not the same IP family since it translates the Gw to an IPv4 first. Moreover, there's no way to override this interpretation with e.g., another Family field.

Note that this behavior exists in multiple places around the code and not only in nl.GetIPFamily(). For example, in neighHandle() there's an direct call to .To4 to again decide if an address is a IPv4 or IPv6.

related issue: #908

Interestingly, changing Gw with a Via struct also doesn't work:

nlh.RouteAdd(
			&netlink.Route{
				LinkIndex: remoteBridge.Attrs().Index,	// some index
				Dst:       route.Dst,					// 2300:5800:ab00::2/128
				Via: &netlink.Via{
					AddrFamily: netlink.FAMILY_V6,
					Addr:       hostAddress.AsSlice(), //::ffff:100.95.128.2
				},	
				Flags:     int(unix.RTNH_F_ONLINK),		// onlink
				Protocol:  186,							// bgp
			},
		)

As this returns invalid argument. Though I haven't debugged the reason for this one yet.

[ShimmerGlass]

Can confirm, this is an issue for us as well.
I hackily made it work by modifying the following function:

// GetIPFamily returns the family type of a net.IP.
func GetIPFamily(ip net.IP) int {
	if len(ip) <= net.IPv4len {
		return FAMILY_V4
	}
	// if ip.To4() != nil {
	// 	return FAMILY_V4
	// }
	return FAMILY_V6
}

and "converting" the v4 gw to v6 using:

gw = net.IP{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff, 0xff, gw4[0], gw4[1], gw4[2], gw4[3]}

&netlink.Route{
    Gw: gw,
    ...
}

For neighHandle() i bypassed the To4() call:

// ipData := neigh.IP.To4()
// if ipData == nil {
// 	ipData = neigh.IP.To16()
// }

dstData := nl.NewRtAttr(NDA_DST, neigh.IP)

This is obviously not a real fix as, IIRC, the net package really likes to represent v4 addrs as v6, hence why we have to .To4() all the time.

I'm unsure what a correct fix would be here using the net package. I agree with @3u13r moving to netip would be a correct but public-api breaking solution.

I'm curious as well as to why using Via doen't work, though from what I can tell this limitation is on the kernel side, not this library.

[ShimmerGlass]

I created a draft/PoC PR to see what a move to net/netip move could look like: #1148