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. (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.)
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.
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs