> > > My question:  Should ssh be able to survive that?  My thought is that it
> > > can't, because my IP number necessarily changed.  Unless ssh is a lot
> > > brighter than I give it credit for...  (^&
> >
> > A TCP connection can't survive if the IP address changed. ssh isn't
> > designed to restart a tcp connection for the sme session.
> 
> I know that TCP can't handle it.  That's why this seems like a ``good
> thing'' for ssh to be able to recover from.  I'd hoped that it was a
> feature that was built into ssh.  Alas, from what you say, ssh doesn't
> provide recovery for this, either.  

part of the problem with applications tolerating NAT is that DNS names 
are sometimes ambiguous in practice - either because multiple hosts are 
associated with a DNS name, or because the DNS name is tied to the IP 
address that changed.  so attempting to 'recover' a connection by 
re-connecting to another IP address associated with the DNS name you 
used last time doesn't necessarily get you the same host you were 
talking to before.

admittedly this would often work for the specific example of ssh,
and ssh already has the mechanisms necessary to verify that it's
talking to the same host as before.

another part of the problem is that you want the recovery to happen
without losing any data.  when a NAT breaks a TCP connection then
the application has no idea how much of the data that has been sent
to its peer was actually received by that peer process, unless it was 
explicitly acknowledged by the peer application.  so recovery from 
broken connections not only requires explicit acks at the application 
level, it also requires that the sending application buffer all data 
that is sent to its peer until it gets explicit acks for that data. 
it also has to implement duplicate message suppression at a layer 
above TCP.

Keith