The myth of NAT traversal, was: Re: IPv4 to IPv6 transition

On 13-jul-2007, at 22:11, Hannes Tschofenig wrote:

> As Phillip stated, I don't see the problem with future  
> applications. Compare this with the security aspects that are taken  
> care of much more than before when developing new applications NAT  
> traversal is just another thing to think about as a protocol designer.
There is no magical "NAT traversal" switch that you can flip and your  
protocol will work through NAT with no problems 100% of the time.  
Just like there is no such switch for security.
Yes, there were (are?) protocols that were more NAT-unfriendly than  
they needed to be, case in point FTP. I don't think the IETF creates  
protocols that fail when used through a NAT when it's just as easy to  
make the protocol work though the NAT as is the case with FTP.
However, the reason why MOST protocols/applications have trouble with  
NAT is because they need to receive incoming sessions. Short of  
rewriting the protocol to work over UDP or through a third-party  
server, pretty much the only way to "traverse" NAT in these cases is  
to go up to the NAT device, and ask it to open up a TCP port, pretty  
please with a cherry on top?
This works well if:

- the NAT device is a fairly modern one created for a market where  
this functionality is considered important (i.e., home users)
- the application or the OS implements the necessary open sesame logic
- there is a well-reachable server providing referrals
- there is only a single NAT between the outside and the host trying  
to receive incoming TCP sessions
(There could be a firewall in the way, too, but that's not relevant  
for this discussion.)
The first three are likely to get better in the future, but more than  
one NAT is extremely likely to become more common as we run out of  
IPv4 addresses. Note though that even with the above in place there  
are still problems caused by NAT that can only be solved by  
additional application logic or application layer gateways in the  
NAT. (The case where multi-party referrals by IP address happen. Yes,  
by FQDN would be better but not every host has a working DNS name.)
So whichever way you slice it, the best case scenario for NAT is that  
it doesn't get in the way. The worst case is that it absolutely,  
positively breaks your application despite huge amounts of NAT  
workaround logic and a lot time spent debugging the problem. As with  
most things in life, some people are lucky enough to live in a best  
case world, others are prone to be bitten by the worst case more than  
their fair share.
What I consider the most important problem with NATs is that they  
don't fail gracefully. When a NAT gets in the way, the application  
generally doesn't get to do what it wants to do, but without any  
feedback as to why. This means the user doesn't know what the problem  
is and doesn't have any clue about solving it. It's like a world  
where rather than giving you warnings or tickets, police officers  
sneak up on you from behind and knock you unconscious without you  
knowing why if you break a traffic rule. It's painful and you don't  
understand why it happens. Come to think of it, not unlike trying to  
send files or videoconference using instant messaging with a NAT at  
both ends.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf