The following reply was made to PR kern/35196; it has been noted by GNATS.

From: "Perry E. Metzger" <perry@piermont.com>
To: Quentin Garnier <cube@cubidou.net>
Cc: SODA Noriyuki <soda@sra.co.jp>, gnats-bugs@NetBSD.org
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 07 Dec 2006 09:29:33 -0500

 Quentin Garnier <cube@cubidou.net> writes:
 > On Thu, Dec 07, 2006 at 11:34:35AM +0900, SODA Noriyuki wrote:
 >> >>>>> On Thu,  7 Dec 2006 02:25:01 +0000 (UTC), perry@piermont.com said:
 >> 
 >> > The addresses bound to said interface will often go away, to be
 >> > replaced by new ones (or none at all). However, even after they go
 >> > away, TCP connections will continue to live for quite some time,
 >> > eventually timing out, going into time wait, etc.
 >> 
 >> > This is quite clearly silly.
 >> 
 >> It is not so silly, acutally.
 >> Think about unstable PPP link which nearly always assigns same IP
 >> address for each host.
 >
 > And not necessarily unstable;  not so long ago most ADSL ISPs in France
 > used to disconnect people after 24h.  It was a pain for Windows users,
 > that OS being one that does what Perry wants.
 
 Well, as I said, we could always make the behavior sysctl'able so you
 could pick based on your usage pattern.
 
 For my usage, I'm constantly opening up my laptop and acquiring a new
 address when I arrive somewhere. Generally, I then have all these
 connections that were active when I was at my last location some hours
 earlier that are now dead, and yet which now are around and sending
 out packets that can never be replied to.
 
 In addition to the possibility of a sysctl for the behavior, here is
 another idea: perhaps if you no longer have the origination address
 bound to any interface, you drop the packets you would otherwise send
 out from earlier connections rather than sending them out on an actual
 network. Then, if you get the address back, you can stop dropping
 them. This surely will cause no one any inconvenience, since those
 packets could never be replied to. It will not, however, be an optimal
 solution from my point of view...
 
 Perry