From: Pekka Savola <pekkas(_at_)netcore(_dot_)fi>
To: Harald Tveit Alvestrand <harald(_at_)alvestrand(_dot_)no>
Well.... my house was behind 2 levels of NAT until last week.
Once i got rid of one level (the one I don't control), some of my
operational problems with keeping SSH sessions up simply went away.
And SSH is a client-server protocol.
Don't underestimate the capability of badly implemented and/or configured
NATs to make things go boom in the night.
FWIW, I don't think this is something that can be fixed whatever
guidance the IETF would give. NATs will always need to keep some
state for all the protocols, including TCP, and that state must be
removed after a timeout.
Who said anything about necessary state and reasonable timeouts? I've
seen more than one brand of consumer-grade box with NAT features that
could not be turned off, and that even in their most permissive settings
kill ssh sessions after an hour or two whether the ssh sessions had
been active or not.
Then there are notions of "DMZs," "game playing mode," and "VPN
support." What you might guess from feature-list bullet items
probably sound reasonable, but you'd probably guess wrong about
what the bullet items really mean in products delivered to users.
Harald misstated his injunction. You should never underestimate the
capabilities of people to build things that make you say "no one would
do that!" and then defend their braindamage as valuable features.
Perhaps more NAT RFCs would help; they couldn't hurt much. They'd be
a lot of work and would certainly be ignored by many people who consider
themselves designers. I can't personally get enthused about telling
people things that are obvious and that will be ignored, like much of
what would go in new NAT RFCs.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf