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.

Sign up for GitHub

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

Jump to bottom

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
Closed

net: Resolve{TCP,UDP,IP}Addr doesn't return error when net and address are in different family #14037

krhubert opened this issue Jan 20, 2016 · 9 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.8

Comments

@krhubert
Copy link

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
@krhubert krhubert mentioned this issue Jan 20, 2016
Closed
@bradfitz
Copy link
Contributor

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
Copy link
Contributor

mikioh 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
Copy link
Contributor

mikioh commented Jan 21, 2016

Also ResolveIPAddr has the same issue.

@krhubert
Copy link
Author

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

@deankarn
Copy link

deankarn 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 The path to resolution is known, but the work has not been done. label Oct 7, 2016
@rsc
Copy link
Contributor

rsc 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
Copy link
Contributor

mikioh commented Oct 27, 2016 •
edited
Loading

@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
Copy link
Contributor

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

@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
Copy link
Contributor

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

gopherbot pushed a commit that referenced this issue Dec 21, 2016
@cixtor
net: make InterfaceByIndex return a consistent name on solaris

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
Learn about vigilant mode
86f2c5f 
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.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.8
Development

No branches or pull requests
7 participants
@bradfitz @mikioh @rsc @quentinmit @krhubert @deankarn @gopherbot