-
Notifications
You must be signed in to change notification settings - Fork 16
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
please can you explain the connect timeout and fallback to IPv4 when IPv6 fails? #53
Comments
This is not really an rpki-client issue. In older version of rpki-client this is worse because of the lack of proper session keep-alive. There will be a new version in the coming days that fixes this. |
I'm seeing the same issue with IDNIC while using transit from AS1299. Personally it feels like the timeout for IPv6 (until the fallback to IPv happens) seems to be longer when using https rather when using rsync (even with rpki-client 7.3)…could that be? |
The http code uses getaddrinfo() and then connects to the IPs returned. I think this is a common idiom and the timeouts are all driven by libc and the kernel. openrsync uses the same method not sure about GNU rsync it kind of does the same but the code is complex with extra options on top. |
I don't think I can couch this as an obligation, but I observe its an implicit DOS on all your dual-stack clients: block V6 in novel ways, and your client hangs for an inordinate period of time. In the DNS, people do things in parallel in async ways to avoid this. in the web browser, the HE code does things in parallel to avoid this. It's a huge complexity and I can "get" you want to keep it simple. I just observe, its a royal pain. I think you could mitigate. I think you should code more defensively. (btw I have sought to communicate with IDNIC about their platform) If you want to go to WONTFIX I won't kick up a stink. i think this is a missed opportunity, but sure: all workarounds have cost. |
We don't think this needs fixing right now. Having a bad IPv6 CA repo will increase runtime but it is something that operators can fix by adjusting resolv.conf or reject routing IPv6 prefixes. Having workarounds for broken setups is out of scope for rpki-client. |
IDNIC is proving unreliable on IPv6:
It does appear to move on, but some guidance on how long it retries in 6 before moving to 4 would help
The text was updated successfully, but these errors were encountered: