Hi Phillip,
~Snip~
Most application protocols work just fine behind NAT.
I agree. I am playing games for a really long time and I rarely had ever
problems with NATs.
Obviously these companies don't shy away from solution that would be
classified as "architectural not nice".
Without knowing the NAT traversal details of the different games I play
I could imagine that they even carry their payloads on top of HTTP, if
nothing else works. Nasty!
FTP works with an ugly work-around. The main protocol that breaks down is SIP.
Not with the work that was done on NAT traversal.
I am mighty unimpressed by the fact that when I plug the VOIP connector made by
vendor X into the wirless/NAT box made by vendor X that I have to muck about
entering port forwarding controls by hand. And even less impressed by the fact
that a good 50% of the anti-NAT sentiment on this list comes >from employees of
vendor X.
STUN does not appear to me to be an architecturally principled approach, it is
a work around.
I wonder why you think so. What's the problem with STUN?
The way to fix this situation in my view is to make the NAT box SIP aware by
building a SIP proxy capability into the NAT box. The designers of NAT boxes go
to great efforts to try to work around applications. Leave approaches such as
STUN to the case where you are dealing with a legacy box.
I think that's a really horrible solution.
There are good protocols out there to provide legacy NAT traversal. If
NAT (and firewall vendors) would implement protocols that support NAT
traversal then the performance issues can also be taken care of.
Ciao
Hannes
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf