CL 32100 added a restriction to IP address resolution requiring that IP addresses acquired for IPv6 networks not be IPv4-mapped-IPv6 addresses.

For example, the following fails:

_, err := net.Dial("tcp6", "[::ffff:8.8.8.8]:53")
// Error: dial tcp6: address ::ffff:8.8.8.8: no suitable address found

CL 32100 states that this behavior is intentional, but perhaps worth reconsideration:

Perhaps a bit surprisingly,
...
ResolveTCPAddr("tcp6", "[::ffff:127.0.0.1]:http") fails,
...
If anyone can make a strong argument for changing the filtering
of IPv4-inside-IPv6 addresses, the fix can be applied to all
the code paths in a separate CL.

A rationale for this behavior is provided by this comment by @mikioh:

The failure on tcp6 for [::ffff:127.0.0.1]:http is fine and intentional because it's an IPv4-mapped IPv6 address that is used in protocol stack internally for convenience and should never appear on the wire. What I feel a difficulty is an IPv4-embedded IPv6 address for IP translators defined in https://tools.ietf.org/html/rfc6052.

I'm opening this issue to reconsider this behavior.

I'm not certain that the fact that IPv4-mapped IPv6 addresses are not expected to appear on the wire is sufficient justification for excluding them from address resolution when the user explicitly tries to dial one. A protocol stack which uses these addresses internally (but not on the wire) may still expect to receive them from the user. In addition, even if the address is not usable by the IPv6 stack, I think that providing the address to the OS and permitting it to return an error is less surprising than dropping the address entirely.