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

libcurl does not recognize [::] as a valid IPv6 address #5344

Closed
volpav opened this issue May 6, 2020 · 7 comments
Closed

libcurl does not recognize [::] as a valid IPv6 address #5344

volpav opened this issue May 6, 2020 · 7 comments

Comments

@volpav
Copy link
Contributor

@volpav volpav commented May 6, 2020

I did this

  1. Started a local server, providing the IPv6 binding of [::]:12345
  2. Attempted to use libcurl to connect to the server

I expected the following

libcurl successfully connecting to the server.

instead, I got this

Received URL using bad/illegal format or missing URL (code 3) error from libcurl.

curl/libcurl version

7.69.1 (with IPv6 enabled)

operating system

Debian-based corporate build.

notes

Changing [::] to [::1] fixes the problem.

Looks like the bug was introduced in 4706603. To comment on this, [::] (and even ::) seems to be a valid IPv6 address according to https://en.wikipedia.org/wiki/0.0.0.0.

This works as expected in 7.66.0.

@jay
Copy link
Member

@jay jay commented May 6, 2020

It's a non-routable address used for binding, how is it a valid destination?

@bagder
Copy link
Member

@bagder bagder commented May 6, 2020

:: is indeed a valid IPv6 address (consisting of all zeroes), I just didn't think about that case when I added that extra check in the URL parser. Should we accept it?

@bagder bagder added the URL label May 6, 2020
@volpav
Copy link
Contributor Author

@volpav volpav commented May 6, 2020

For posterity, the [::] (0.0.0.0), even though not being a valid destination, essentially means to listen to all interfaces when you perform a binding.

While [::], theoretically-speakig, is not a valid destination (since it means "any destination"), it seem that there's a number of network stack implementations that would treat it as a loopback address. For Linux, this looks like a relevant piece of code for IPv4 (still trying to find the similar example for IPv6 although I would expect the behavior to be the same):

if (!fl4->daddr) {
  fl4->daddr = fl4->saddr;
  if (!fl4->daddr)
    fl4->daddr = fl4->saddr = htonl(INADDR_LOOPBACK);
  
  // ...
}

(source: net/ipv4/route.c)

@jay
Copy link
Member

@jay jay commented May 7, 2020

Should we accept it?

I vote no

@bagder
Copy link
Member

@bagder bagder commented May 7, 2020

I vote no

With what motivation? Why should our URL parser restrict what IP address the user can specify? It seems entirely arbitrary. We already accept 0.0.0.0 which also is a perfectly valid address. I think we should accept ::.

bagder added a commit that referenced this issue May 7, 2020
Reported-by: Pavel Volgarev
Fixes #5344
@emilengler
Copy link
Contributor

@emilengler emilengler commented May 7, 2020

I agree with @bagder.
I don't think it is our task to tamper that much with the IP and OSI-Level 3 protocols in general as this is a task of the operating system or other lower level software

@jay
Copy link
Member

@jay jay commented May 8, 2020

I changed my mind. Those are all good points.

@bagder bagder closed this in 7f1c098 May 8, 2020
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.

4 participants
You can’t perform that action at this time.