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

Message-Id: <20080318012739.6a5c8602.billfink@mindspring.com>
Date:	Tue, 18 Mar 2008 01:27:39 -0400
From:	Bill Fink <billfink@...dspring.com>
To:	David Miller <davem@...emloft.net>
Cc:	opurdila@...acom.com, rick.jones2@...com, netdev@...r.kernel.org
Subject: Re: TCP timewait recycle/reuse for IPv6?

On Mon, 17 Mar 2008, David Miller wrote:

> From: Octavian Purdila <opurdila@...acom.com>
> Date: Mon, 17 Mar 2008 20:04:33 +0200
> 
> > 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.
> 
> Timewait recycling should not be enabled if any of your connections
> could even potentially be going through a firewall or NAT box.
> In such cases, the invariants which are necessary for timewait
> recycling to be valid are not present and thus you could risk
> connection or data corruption.
> 
> Timewait recycling depends upon end systems really being end
> systems on a connection level.  With NAT, that is no longer
> true, as the NAT box will reuse the same port for different
> end nodes in subsequent connections.

I have this hope that as IPv6/IPSEC becomes more commonplace, perhaps
it can help get back to the original TCP/IP direct end system to
end system model of communication, and reduce the current need for
such unfortunately necessary kludges as NAT boxes.

						-Bill
--
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