Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: can't Dial("tcp6", IPv4-mapped-IPv6 address) #47763

Open
neild opened this issue Aug 17, 2021 · 0 comments
Open

net: can't Dial("tcp6", IPv4-mapped-IPv6 address) #47763

neild opened this issue Aug 17, 2021 · 0 comments

Comments

@neild
Copy link
Contributor

@neild neild commented Aug 17, 2021

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.

@mknyszek mknyszek added this to the Backlog milestone Aug 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants