View Issue Details

IDProjectCategoryView StatusLast Update
0004687unrealircdpublic2023-03-19 11:40
Reportersyzop Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
Product Version4.0.3.1 
Summary0004687: Linking to server by hostname: try IPv4 address first and then IPv6
DescriptionIdeally, 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).
TagsNo tags attached.
3rd party modules

Relationships

has duplicate 0005921 closedsyzop Unreal tries to link over IPv6 on systems where it's not available 
related to 0006249 acknowledgedsyzop url_unreal.c does no IPv6 lookup 

Activities

Polsaker

2021-06-27 18:52

reporter   ~0022047

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.
ipv6-fix.diff (2,336 bytes)

syzop

2021-11-28 10:49

administrator   ~0022210

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.

Issue History

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