henning,
good stuff...
people would do well to read this -
also, all attempts to fix NATs so as to ameliorate these problems
have _exactly_ the same deployment complexity as IPv6 - there's a
quote somewhere from yakov rehkter to this effect (can't find it
exactly, but he was coming the ther way saying why dont we use NATs
instead of v6 - same difference)
by the way, at least one router vendor has now lost a large contract
to a competitor becuase it couldn't provide v6 routing (forwardig,
yes, routing, no).... so perhaps we'll see the situation change quite
fast now:-)
In message <3901CB56(_dot_)61EC7B8A(_at_)cs(_dot_)columbia(_dot_)edu>, Henning
Schulzrinne typed:
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
cheers
jon