Responses to comments sent on ml for the draft-aoun-natpt-deprecate draft

[Cedric Aoun <cedric.aoun@nortelnetworks.com>]

Hi,
Thanks for all your comments on the draft.
Sorry for not responding before I was ooo and came back today.

Going through all the email threads I can see that several people are keen
on preserving a protocol translator for scenarios where application proxies
are not applicable/possible. As we state in the introduction of the draft,
the draft does not condemn all protocol translators but is explicitly
targeted at the NAT-PT specification. I do recognize that application
proxies could have a certain hidden complexity especially when the
application has both a control plane and data plane (case of FTP, VoIP, RTSP
Video over IP etc ...), but this complexity may not necessarily result in
lower performance than adopting a generic protocol translator communicating
with application proxies or with the application client themselves (ref NSIS
or MIDCOM models), or indeed any greater/different complexity in either the
application or the translator/proxy.

As we stated in the draft all forms of IPv4<->IPv6 translators, induce a
loss of information during the protocol translation, and break applications
embedding IP addresses and port. If ALGs are used for these applications end
to end security can't be used and a hop by hop security model needs to be
used - in that case it is possible that we are better off with making the
applications aware of proxies.

If a protocol translator is really inevitable - and we still need to prove
that it is REALLY required as the authors believe that we have not yet seen
appealing reasons on the ml- then a simple translator using an updated SIIT
specification could be used with the option of using Middlebox communication
protocols to avoid autonomous allocation of binds. If folks on the mailing
list agree that a new translator specification (without the DNS-ALG part) is
needed with the interaction with Middlebox communication protocols or with
reflector protocols such as STUN then the WG should decide to work on an
alternative translator solution. The latter is definitely not mutually
exclusive with the current NAT-PT specification deprecation draft.


Regards
Cedric Aoun