Again, there needs to be an expectations reset here.
The pro-NAT faction are not 'asking' for anything. They are serving notice that
this is the approach that they intend to take.
You are saying, 'you can beg for your NAT but I am not giving it to you, now go
away'. They are saying, 'I do not recognize your asserted veto power'.
Not many folk realize that when the comment was made about rough consensus and
running code was made it was not a compliment, it was an observation that the
IETF process is frequently pre-empted by unilateral decisions. Rough consensus
does not have to mean a majority. In the past it has frequently meant a cabal
that had a consensus amongst themselves and just decided they were going to do
something.
If your idea of a representative 'application' program is SSH you are certainly
not an application programmer. SSH is a tool that is almost exclusively used by
network and system admins and programmers. Being robust in the face of network
instability is a major functional requirement when you are debugging a network.
Application programmers in general have zero interest in the design, coding and
testing effort necessary to work in a network with arbitrary administrative
renumbering. End users are going to demand a reliable network rather than allow
their network to be subjected to unnecessary instability because some IETF
faction thinks that keeping the network address constant from end to end is
more important.
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org on behalf of Tony Hain
Sent: Wed 11/26/2008 6:16 PM
To: 'David Morris'
Cc: 'IETF Discussion'
Subject: RE: [BEHAVE] Lack of need for 66nat : Long term impactto
applicationdevelopers
David Morris wrote:
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.
That is probably because you appear to have failed to read the top half of
that post. An external ssh session will break during renumbering, no matter
what nat capability might exist, so the only thing worth discussing is an
internal one. Deploying a ULA prefix alongside whatever external one might
exist will allow the internal ssh to persist forever while the external
prefix is changed on a minute by minute basis.
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.
Clearly none of those are external, or there is no actual renumbering going
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
productivity.
No argument about the impact, but you have not demonstrated a need for 66nat
beyond wanting it so that nothing changes except the size of the address.
This will not be true on a number of fronts, so perpetuating an
architectural impediment in a futile attempt to avoid reality is not a
reasonable argument.
Vendors will build what you say you want to buy, so don't box yourself in by
insisting on perpetuating the past without trying to move beyond it first...
Tony
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf