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: Resolve{TCP,UDP,IP}Addr doesn't return error when net and address are in different family #14037

Closed
krhubert opened this issue Jan 20, 2016 · 9 comments

Comments

Projects
None yet
7 participants
@krhubert
Copy link

commented Jan 20, 2016

https://play.golang.org/p/1lf51v8MII

I think resolver should return error it this case, Someone is expecting to get ipv4:port when resolving tcp4 address.

ResolveUDPAddr has the same issue

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jan 20, 2016

Yes, that's surprising.

/cc @mikioh

@bradfitz bradfitz added this to the Go1.7 milestone Jan 20, 2016

@bradfitz bradfitz changed the title net.ResolveTCPAddr don't return error when net and address are in diffrent family net: ResolveTCPAddr doesn't return error when net and address are in different family Jan 20, 2016

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jan 20, 2016

Yup, I reserved this issue for people who want to figure out what's the best way to grab literal IPv4, IPv6 and Ipv6 translator addresses. ;) Please consider all possibilities. For example,

"tcp" [prefix:192.0.2.33]:80 -- IPv4 or IPv6?
"tcp" [prefix:c000:0221]:80 -- IPv4 or IPv6?
"tcp4" [prefix:192.0.2.33]:80 -- Should we return 192.168.0.2.33?
"tcp6" [prefix:192.0.2.33]:80

prefix -- IPv4-embedded IPv6 address prefix
@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jan 21, 2016

Also ResolveIPAddr has the same issue.

@krhubert

This comment has been minimized.

Copy link
Author

commented Jan 21, 2016

Also ResolveIPAddr has the same issue. => that's true.
Also ResolveUnixAddr return nil error when address is empty string.

@deankarn

This comment has been minimized.

Copy link

commented Feb 2, 2016

I think that ResolveUnixAddr is ok parsing blank as it's equivalent to 0.0.0.0 from what I understand

@rsc rsc modified the milestones: Go1.8, Go1.7 May 18, 2016

@quentinmit quentinmit added the NeedsFix label Oct 7, 2016

@rsc

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2016

The resolver code already has a filter it applies to the addresses it gets back from DNS. The literal IP path was bypassing that filter. The simplest and therefore most compelling fix is to apply the filter to the literal IPs too. That is, the code has already made a decision for the question @mikioh asked. Empirically, it is:

tcp  127.0.0.1:http            ok
tcp  [::ffff:127.0.0.1]:http   ok
tcp  [2001:db8::1]:http        ok

tcp4 127.0.0.1:http            ok
tcp4 [::ffff:127.0.0.1]:http   ok
tcp4 [2001:db8::1]:http        FAIL - no suitable address

tcp6 127.0.0.1:http            FAIL - no suitable address
tcp6 [::ffff:127.0.0.1]:http   FAIL - no suitable address
tcp6 [2001:db8::1]:http        ok

The failure of tcp6 for [::ffff:127.0.0.1]:http is maybe a little surprising, but it keeps the tcp4 and tcp6 successes disjoint, which seems correct. Since ::ffff:127.0.0.1 is just a funny way to spell an IPv4 address, semantically this seems right. It is at least in keeping with the rest of the package: remember, I didn't do anything except call the existing filtering routine.

Will send a CL.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2016

@rsc,

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.

@gopherbot

This comment has been minimized.

Copy link

commented Oct 27, 2016

CL https://golang.org/cl/32100 mentions this issue.

@gopherbot gopherbot closed this in 866e014 Nov 11, 2016

@mikioh mikioh changed the title net: ResolveTCPAddr doesn't return error when net and address are in different family net: Resolve{TCP,UDP,IP}Addr doesn't return error when net and address are in different family Dec 20, 2016

@gopherbot

This comment has been minimized.

Copy link

commented Dec 20, 2016

CL https://golang.org/cl/34670 mentions this issue.

gopherbot pushed a commit that referenced this issue Dec 21, 2016

Mikio Hara
net: make InterfaceByIndex return a consistent name on solaris
Also retightens test cases for Resolve{TCP,UDP,IP}Addr which are using
interface names for specifying IPv6 zone.

Updates #14037.
Fixes #18362.

Change-Id: I7444b6302e2847dfbdab8a0ad5b2e702bed1a3d6
Reviewed-on: https://go-review.googlesource.com/34670
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

@golang golang locked and limited conversation to collaborators Dec 20, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.