--- Henning Schulzrinne <[EMAIL PROTECTED]> 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
