netdev - Re: TCP timewait recycle/reuse for IPv6?

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Mar 2008 11:15:27 -0700
From:	Rick Jones <rick.jones2@...com>
To:	Octavian Purdila <opurdila@...acom.com>
CC:	netdev@...r.kernel.org
Subject: Re: TCP timewait recycle/reuse for IPv6?

Octavian Purdila wrote:
> On Monday 17 March 2008, Rick Jones wrote:
> 
>>Octavian Purdila wrote:
>>
>>>Hi,
>>>
>>>Is there a way to prevent getting bind(in6addr_any) failures when we
>>>have lots of TIMEWAIT sockets hanging around? It looks like timewait
>>>reuse/recyle is not supported in the IPv6 stack.
>>
>>What is the definition/value of "lots" here?
>>
> 
> 
> At least 26000, maybe even more. I suspect that when I get the bind
> failures most of the ports in the ip_local_port_range pool are in
> TIMEWATstate.
> This happens because of the particular traffic I am using, which
> generates a few 1000s of connections per second. The connection
> lifetime is very short.

Does it _have_ to be from a single IP address?

> While running the same traffic with IPv4, the timewait recyle/reuse
> features kicks in and keeps the number of TIMEWAIT sockets to under a
> 1000.

ISTR some discussion on the list about that recyling/reuse feature 
perhaps going away.  While TCP theory suggests that one can transition 
from TIME_WAIT to ESTABLISHED, if tings like the ISN are selected "just 
so" it seems the desire to randomize things like ISN's makes the chances 
of success rather remote.

Anyhow, if we presume a 60 second TIME_WAIT, and explicit selection of 
port numbers from the range of 5000 to 65535, it should be possible to 
sustain a connection "churn" rate of ~1000 connections per second 
without attempting to re-use an endpoint still in TIME_WAIT.  Each 
additional "simulated client" IP address you can add to that mix will 
increase the rate by another 1000 connections per second.

Anything trying for such a churn-rate from a single IP address in that 
wonderfully vague "real life" is arguably broken :)

rick jones
--
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