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