(ngtrans) draft-durand-ngtrans-nat64-nat46-00.txt

[[e-mail]]

Alain,

Some comments on your nat64-nat46 draft:

NAT64
-----
Can we be confident that applications written by developers that don't know
about NAT64 will get some useful default behaviour? This is not a rhetorical
question - I genuinely would like to hear your thoughts about this.

The scalability solution doesn't prevent the NAT64 devices being single
points-of-failure.

NAT46
-----
The changed model of interworking deployment responsibility from the
providers of IPv6 services to the providers of IPv4 network connectivity is
interesting. I can't see too many IPv4 network operators deploying NAT46 for
their customers on the off-chance that there are some useful or interesting
IPv6 services that they might want to connect to. It is much more useful for
the providers of IPv6 services to be able to make their services accessible
to the global IPv4 community via NAT-PT. As I stated in my earlier mail
commenting on draft-durand-natpt-dns-alg-issues-00.txt, the problems with
NAT-PT as *implemented* are not as great as you imply. I agree the spec
could use some work.

General comments
----------------
I agree with you that there is a need for a scalable solution to the
translation interworking problem before serious deployment can happen.
However, I don't believe that NAT-PT is irredeemably broken and I think that
several of the ideas presented in this draft could easily be applied to
NAT-PT. There are already several quite mature implementations of NAT-PT and
improvement of the spec rather than re-invention is therefore extremely
desirable in my opinion. Let's fix the NAT-PT spec rather then generate yet
another mechanism.

 -- Mat.