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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]