netdev - Need a special way tune TCP IPv6->IPv4 fallback timeout

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikP7AFMnQ4BdnE2272zNupv_ysb3BDWTqy=9s34@mail.gmail.com>
Date:	Thu, 24 Mar 2011 17:23:15 +0100
From:	Guillaume Leclanche <guillaume@...lanche.net>
To:	netdev@...r.kernel.org
Subject: Need a special way tune TCP IPv6->IPv4 fallback timeout

Hi,

(this is a copy of text I've put in
https://bugzilla.kernel.org/show_bug.cgi?id=23242 for anyone who would
like to do something with bugzilla).

When applications call the connect() API, if AAAA record is returned
and correct routing is present, the system will start a TCP connection
over IPv6.
However, if the host is finally unreachable, the system waits until
the IPv6 TCP connection attempt fails, that is roughly 3 min (5
retries, backoff, well, you know that). Then it falls back to IPv4.

Afaik, the only way to tune this timeout of 3 mins in the kernel is
the tcp_syn_retries sysctl (RTO tuning not available in Linux TCP). By
setting the value to 2, you can reduce the delay to ~10s which is more
acceptable, and still 3 SYN are sent.

In order not to modify uselessly the TCP parameters for standard
IPv4-only connections at the same time, it would be necessary to have
a *separate* parameter-set to decrease the v6->v4 fallback delay.

No idea how feasible this is, nor if it has already been discussed
here in the past.

// Not subscribed, please CC me.

Best regards,
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html