It is quite easy to see how an application that is designed to tolerate
renumbering is able to cope with it given appropriate O/S and protocol level
support. I suspect what is happening there is that SSH loses the connection and
then transparently attempts to reconnect before telling the user that it has
failed and dropping the entire connection state.
But most IP applications are not designed to maintain connections for days, SSH
is a rarity in that respect.
Renumbering your network every day is probably quite practical. Trying to
change an address after it has been constant for a year or more is a recipe for
pain and anguish. The more infrequent an event is, the less pleasant it
I don't like the suggestion of using different addresses for local and Internet
traffic for the same reason. Once you start to have more than one way for two
things to communicate there is going to be more scope for error.
Changing the IP address on the host end every day or introducing split
addresses seems to be a much more disruptive change to the network than NAT.
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of David Morris
Sent: Wed 11/26/2008 5:59 PM
Cc: IETF Discussion
Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact
On Thu, 27 Nov 2008, Mark Andrews wrote:
If your OS requires a reboot when you renumber get a real OS.
If your apps require that they restart when you renumber get
your apps fixed.
I fail to understand how an app such as ssh can maintain a secure
connection in the face of renumbering. Yet many of my ssh sessions are
active for days or weeks quite happily and their existance represents my
mid term memory about what I'm working on.
Creating a new connection represents a restart from my perspective. Some
amount of my activity is lost and if I don't directly control when the
renumbering happens, it can be at a very in-opportune time in terms of my
Ietf mailing list
Ietf mailing list