Go version

all versions since go1.18

Output of go env in your module/workspace:

see above

What did you do?

Create an IPv4 UDP socket listening on 0.0.0.0. Call WriteMsgUDPAddrPort with an IPv4-mapped IPv6 destination address.

What did you see happen?

write udp4 0.0.0.0:48509->[::ffff:192.168.0.162]:20221: address ::ffff:192.168.0.162: non-IPv4 address

What did you expect to see?

The write succeeds, just like WriteMsgUDP.

Back when Go 1.18 was just out, I opened #52264 for sending to IPv4 addresses on IPv6 sockets.

This issue is about the other way around: sending to IPv4-mapped IPv6 addresses on IPv4 sockets. It's less common, as IPv4 UDP sockets are less used compared to dual-stack IPv6 sockets. But it's just as painful, as APIs like net.DefaultResolver.LookupNetIP happily return IPv4-mapped IPv6 addresses.

I'm sending a CL to address it.

Comment From: gabyhelp

Related Issues

• net: WriteMsgUDPAddrPort should accept IPv4 destination addresses on IPv6 UDP sockets #52264 (closed)
• net: fix WriteMsgUDPAddrPort addr handling #52265 (closed)
• proposal: net: UDPAddr/TCPAddr AddrPort should map 4in6 addresses to IPv4 netip.Addrs #53607
• net: WriteMsgUDPAddrPort should accept IPv4 destination addresses on IPv6 UDP sockets [1.18 backport] #54074 (closed)
• net: net.ListenUDP() only binds to IPv4 when 127.0.0.1 is not present #61310
• net: Resolve{TCP,UDP,IP}Addr returns IPv4 address on host without IPv4 connectivity #28666
• net: Resolve*([::]) gives IPv4 zero, not IPv6 #20911 (closed)

Related Code Changes

• net: fix WriteMsgUDPAddrPort addr handling
• [release-branch.go1.18] net: fix WriteMsgUDPAddrPort addr handling

Related Discussions

• Re: [go-nuts] Problem with Net UDP (ipv6) client socket

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

Comment From: mknyszek

CC @neild

Comment From: gopherbot

Change https://go.dev/cl/689976 mentions this issue: net: fix WriteMsgUDPAddrPort addr handling on IPv4 sockets

Comment From: database64128

@gopherbot please open backport issues.

In favor of backport:

1. The fix is simple and does not affect the path where it previously worked.

2. 52264 had a backport. Backporting this would ensure consistent behavior across both address families.

3. Having a failure mode like this makes WriteMsgUDPAddrPort harder to use right. The problem was discovered by a user under an unusual configuration. Having it backported would eliminate such edge cases that tend to be overlooked.

In opposition:

1. Because #52264 was fixed, this issue can be worked around by unmapping the destination address before calling WriteMsgUDPAddrPort.

Comment From: gopherbot

Backport issue(s) opened: #74817 (for 1.23), #74818 (for 1.24).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

Comment From: dr2chase

@gopherbot, please backport to 1.25

Comment From: gopherbot

Backport issue(s) opened: #74999 (for 1.25).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

Comment From: gopherbot

Change https://go.dev/cl/695875 mentions this issue: [release-branch.go1.25] net: fix WriteMsgUDPAddrPort addr handling on IPv4 sockets

Comment From: gopherbot

Change https://go.dev/cl/695656 mentions this issue: [release-branch.go1.24] net: fix WriteMsgUDPAddrPort addr handling on IPv4 sockets