--- Henning Schulzrinne <schulzrinne(_at_)cs(_dot_)columbia(_dot_)edu> wrote:
It might be useful to point out more clearly the common characteristics
of protocols that are broken by NATs. These include, in particular,
protocols that use one connection to establish another data flow. Such
protocols include ftp, SIP and RTSP (the latter is not mentioned yet in
the draft, but NATs also interfere with its operation). Note that unless
we forego such control protocol designs altogether, NATs in principle
break these unless every host has an external DNS mapping.
We had originally considered having a section in the draft listing
common characteristics of all the applications that fail. Then we
decided against it, as such a section already exists in RFC 2663 and
"Traditional-NAT" draft. Instead, we chose to focus on gathering
the various protocols/applications that fail, why they fail and if
there are any work-arounds. Input on the IETF list, past few days,
has been great. The draft should look much better when the input is
all folded in.
For example, the problem you point out with applications with
inter-dependent control and data sessions can be found listed
as NAT limitation in section 8.2 of RFC 2663.
(Thus, in
reference to a recent message to just design NAT-friendly protocols,
this means in practice that such "out-of-band" designs could not be
supported by this NATy version of the Internet. In effect, this leads to
the abomination of carrying real-time data in HTTP connections.)
Agreed. The intent of NAT-friendly guidelines was merely to point
the gotchas that can be fixed - not to dissuade development of
protocols that cannot be NAT-friendly.
Other protocol designs are those that are symmetric rather than
client-server based. This affects all Internet telephony or event-based
protocols (IM and generalizations) unless they maintain an outbound
connection with a server acting as their representative to the globally
routed Internet. The latter obviously does not address the media stream
addressing problems.
I assume, you mean Peer-to-peer protocols/applications require
bi-directional flows at a minimum. Clearly, it is a problem doing
this across traditional NAT (i.e., Basic-NAT or NAPT) because
Traditional-NAT fundamentally is unidirectional and supports
out-bound flows only. Bidirectional-NAT might work with these
apps (with all the caveats that go with address translation).
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs
regards,
suresh
__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com