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

Don't default to IPv4 if the host has no IPv4 interface #66

Open
ckonstanski opened this issue Sep 22, 2020 · 4 comments
Open

Don't default to IPv4 if the host has no IPv4 interface #66

ckonstanski opened this issue Sep 22, 2020 · 4 comments
Assignees

Comments

@ckonstanski
Copy link

If usocket is used on an IPv6-only host, and if the endpoint it is trying to reach resolves to both an IPv4 and IPv6 DNS address, usocket will always try the IPv4 address. A smarter decision needs to be made. Perhaps look at the routing table?

Is there a way to tell usocket to use IPv6 only?

@binghe binghe self-assigned this Sep 26, 2020
@binghe
Copy link
Member

binghe commented Sep 26, 2020

Hi,

this is a reasonable requirement (although I've never seen any IPv6-only host). Looking at the routing table is not feasible, as there's no portable API to do that (or root privilege is required). I think it's fine to add a special variable, say *ipv6-only-p* indicating all USOCKET functions will work in IPv6-only mode whenever this variable is non-NIL.

--Chun

@ckonstanski
Copy link
Author

This solution would work fine and be much appreciated. For context: I work at a major telecom and we're standing up 75k new ipv6-only hosts in the next three years for one project alone. The lack of ipv4 has been painful on many fronts.

@binghe
Copy link
Member

binghe commented Sep 28, 2020

Hi, with 1b712f6 I believe the obvious issues when calling GET-HOST-BY-NAME and GET-RANDOM-HOST-BY-NAME have been resolved:

CL-USER 11 > (usocket:get-host-by-name "localhost")
#(127 0 0 1)

CL-USER 10 > (let ((usocket:*ipv6-only-p* t)) (usocket:get-host-by-name "localhost"))
#(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1)

I didn't touch any backend-specific code. I don't know if this is already enough, but if you can have a test on latest usocket code that will be more helpful and I will work with you closely fixing whatever more related issues quickly.

--Chun

@ckonstanski
Copy link
Author

Thanks for adding this. I'm still waiting for it to land in quicklisp. Once it does, I'll let you know how it goes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants