GitLab

* fix nat64 well-known prefix check

* don't use pointer

* make NAT64WellKnownPrefix private

It turns out we *were* relying on this. Furthermore, this is generally more
useful (especially given ip6zones).

- Add `FromIPAndZone` function (complementing the `FromIP` function).
- Handle zones when parsing `net.Addr`s.
- In `DialArgs`, return an error if an `ip6zone` is prefixed to an `ip4`
  or to another `ip6zone`.

Note: I was not able to add a listen test (in TestListenAddrs) for
`/zone/.../ip6/...` since there is no link-local address which is
guaranteed to exist on all systems.

1. Ensure we check the entire addr, not just a prefix.
2. Make the LinkLocal test skip zones.
3. Consider link-local multicast to be link-local.
4. Defer to *go* to determine if something is, in fact, a loopback/link-local address.

* fe80::1 is not a loopback address
* ::ffff:127.* probably is (IPv4-mapped IPv6)

Helps readers understand what they're looking at.

Decapsulate currently allocates a lot and this appears to have been causing some
issues (hard to tell, pprof is misbehaving).

Note: I removed the TODO as this function now *only* checks if we're dealing
with a loopback address. Not sure what `OverIPLoopback` was supposed to mean.

Note 2: Decapsulate actually checked if the IP6 loopback addresses
appeared *anywhere* in the multiadder. However, as we weren't doing this for
IP4, I decided to simplify this and only check prefixes.

Currently IsIPLoopback returns true for any multiaddr starting ip4/127, but only returns true on ip6 addresses that exactly equal ip6/::1. So /ip6/::1/tcp/4001 for example does not return true. Instead we should check whether ip6/::1 is contained in the multiaddr, and to do that I simply decapsulated and checked to see if the result is different. It seems this was not caught by tests as none are present specifically for this function.

License: MIT
Signed-off-by: Hector Sanjuan <code@hector.link>