View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004687 | unreal | ircd | public | 2016-05-22 21:27 | 2023-03-19 11:40 |
| Reporter | syzop | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Product Version | 4.0.3.1 | ||||
| Summary | 0004687: Linking to server by hostname: try IPv4 address first and then IPv6 | ||||
| Description | Ideally, when connecting to a server by hostname with both an IPv4 and IPv6 record then UnrealIRCd should try IPv6 first and then IPv4. Right now it tries IPv6 and then if that fails, it gives up. To workaround it currently you have to force IPv4 either by specifying an IPv4 link::bind-ip or setting an IP explicitly in link::outgoing::hostname. Of course this "only" matters if the IRCd is IPv6-capable (like many) but the host is not truely connected to an IPv6 network (very common as well) and the remote host has an IPv6 address (right now.. not so common). | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Here's a ugly diff to illustrate how this could the ipv4 fallback could be tackled: if the server cannot be reached over v6 it attempts to resolve and reconnect via v4. This would solve the issue for 99% of the ipv4-only servers. |
|
|
I don't want to touch 5.x for this, as most people did not have an issue with this. Presumably they are used to using an IP address in link::outgoing::hostname and can live with this effect. For 6.x (too late in the development process, after the freeze) I looked at Happy Eyeballs v2 https://datatracker.ietf.org/doc/html/rfc8305 as I would want to "do things good, once and for all". We could do it as they propose there or with a slight variation like this: - Start an IPv6 lookup - If we have an IPv6 record, start connecting there - Upon IPv6 DNS lookup response (both found and not found) or after a DNS lookup timeout: do the IPv4 lookup - If we have an IPv4 record, and the IPv6 is not connected yet, start connecting too - Then whichever connection is established wins and the other one is cancelled. And with "established" I mean SYN-ACK, with zero IRC protocol messages have been sent yet. Of course, that would require a more major overhaul of things, so.. I don't know how realistic it is to do without risking bugs or breakage (multiple objects referring to the same link block, ref counts, and so on). We can try, though. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-05-22 21:27 | syzop | New Issue | |
| 2016-05-22 21:29 | syzop | Description Updated | |
| 2016-05-22 21:29 | syzop | Status | new => confirmed |
| 2021-06-26 19:49 | syzop | Relationship added | has duplicate 0005921 |
| 2021-06-27 18:52 | Polsaker | Note Added: 0022047 | |
| 2021-06-27 18:52 | Polsaker | File Added: ipv6-fix.diff | |
| 2021-11-28 10:49 | syzop | Note Added: 0022210 | |
| 2023-03-19 11:40 | syzop | Relationship added | related to 0006249 |
