Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt

[Erik Nordmark <Erik.Nordmark@sun.com>]

I suspect the root of this argument is whether NAT as we know it
in IPv4 (with DNS-ALG, FTP-ALG, etc) is "good enough".
If so NAT-PT is what we need.

Or do we want to improve on that?
For instance, do we want improvements that allows one to take advantage
DNSSEC through the NAT? 

Until we agree of the right approach or approaches at that level
I think the detail discussion is rather pointless.

> 	SIIT/NAT64 is RSIP.  a proof - SIIT/NAT64 FTP client has to know
> 	about how to deal with PORT/PASV command, even though they run on
> 	IPv6-only stack.  If the IPv6-only node only implements EPSV/EPRT
> 	(with IPv6 address support only), it won't be able to use FTP over
> 	SIIT/NAT64.  SIIT/NAT64 imposes very strange requirement to the end
> 	devices.

FWIW RSIP has a lot of other implications as it comes to port number allocation
and SPI allocation in the stacks.

The assumptions behind SIIT is that the node is dual stack (the protocols
as well as the applications) but the node  doesn't have a permanent IPv4
address and the local network infrastructure does not support IPv4.
With those assumptions there aren't any strange requirements on the devices
(ignoring the AH suggestion in the RFC:-); the ftp implementation on a 
dual stack node already needs to support old stuff when communicating with
IPv4 addresses.

  Erik