Subject: Re: (ngtrans) NAT-PT -05 INput

From: Ken Powell <[email-masked]>
Date: Thu, 8 Apr 1999 13:30:25 -0400

-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Monday, April 05, 1999 9:34 AM
	To:	[email-masked]
	Cc:	Jim Bound; [email-masked]
	Subject:	Re: (ngtrans) NAT-PT -05 INput

	<... snip>
	> > 6.  In section 5.4 FTP ALG
	> > 
	> > You need to address the EPRT and EPASV commands being replaced
in IPv6
	> > FTP with prt and passv as they are different.
	> > 
	> 
	> Suresh, can you comment on this?
	> 

	Sure, RFC 2428 talks about EPRT and EPSV extensions. 
	EPRT,  which has the following format requires protocol Number
translation
	(AF #1 to AF #2, or vice versa) and Address translation (from V4
address 
	in ASCII to V6 address in ::: notation or vice versa). Nothing 
	substantially different from PORT and PASV commands. <tcp-port>  
	translation is also required in the case of NAPT-PT.
	   EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>

	EPSV doesnt seem to require any NAT translations.

[Ken] The FTP-ALG part of the NAT-PT spec
states that PORT and PASV commands may carry
an IPv6 address. They cannot. Were you assuming
LPRT and LPSV (RFC 1639) for IPv6?

It is true that EPSV does not carry an IP
address and supports both IPv4 and IPv6
connections. However, installed IPv4-only
FTP servers are not likely to support EPSV
or EPRT for a long time. Therefore, would
it be appropriate for NAT-PT to provide the
following translations?

    IPv4 only                IPv6 only
  PORT w/IPv4 addr <----> EPRT w/IPv6 addr
  PASV w/IPv4 addr <----> EPSV w/no addr

Are LPRT and LPSV obsolete now? If not, then
do they also need to be addressed by this section
of the NAT-PT spec?

Ken

---

From: [email-masked] (Pyda Srisuresh)
Date: Fri, 9 Apr 1999 07:30:54 -0700 (PDT)

> LPRT and LPSV (RFC 1639) for IPv6?
No. Apparantly, we missed to mention EPRT and 
EPSV commands at the time of writing the draft.
We will post a new ID with the correction.

>   PASV w/IPv4 addr <----> EPSV w/no addr
You bring up a good point. However, I dont believe, 
the FTP-ALG should operate as you suggest above for 
the following reasons.

  1. The EPSV command has an option (ALL) to turn off 
     all other forms of data commands (including EPRT). 
     The FTP-ALG cannot translate this to a V4 node 
     whose FTP appl. understands only PORT and PASV. 

   2. RFC 2428 mandates that all FTP transfers where 
      the control and data connection(s) are being 
      established between the same two machines, the 
      EPSV command MUST be used.

      So, if a v6 node sends a "PASV ALL" to the NAT-PT
      translted V6 node; and the v4 node (being translted 
      as a V6 node by NAT-PT) issues a -ve response to 
      this, the FTP file transfer might simply fail.

   3. Lastly, I dont believe, the FTP-ALG should make 
     the assumption that V4 FTP-applications donot 
     support EPRT and EPSV at all.

So, I believe, the FTP-ALG operation ought to 
work as followds:

   1. If a V4 host originates the FTP session and
      uses PORT and PASV commands, the FTP-ALG will do 
      the translations as you suggest (PORT to EPRT and
      PASV to EPSV).
      
   2. However, if a V6 host originates the FTP session, 
      the FTP-ALG will leave the command strings "EPRT" 
      and "EPSV" unaltered. I.e., the V4 hosts will be
      required to have their FTP application upgraded
      to support (EPRT and EPSV) in order to allow 
      access to V4 and V6 hosts, alike.

> Are LPRT and LPSV obsolete now? If not, then

I believe so.

> Ken

regards,
suresh

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 10 Apr 1999 00:48:39 +0900

>      access to V4 and V6 hosts, alike.

	Maybe I missed the point, but (2) is not a happy solution for
	IPv6-only site (which is a most important customer for IPv6-to-IPv4
	translation technologies).  It is possible to translate EPSV/EPRT
	with application level gateway.  We do this in our TCP relaying
	translator (in our current code ALG returns an error by itself,
	for EPSV ALL from IPv6 client).
	Without it you can't access most of the popular FTP sites like
	www.cdrom.com, from IPv6-only network with NAT-PT+ALG.

itojun

---

From: [email-masked] (Pyda Srisuresh)
Date: Sat, 10 Apr 1999 14:02:46 -0700 (PDT)

> 	www.cdrom.com, from IPv6-only network with NAT-PT+ALG.

I see your point. But, I was wary about returning an error code
(whether it is done by the ALG or the V4 node itself) because 
RFC 2428 mandates that all FTP transfers where the control and 
data connection(s) are being established between the same two 
machines, the EPSV command MUST be used.

So, if a v6 node sends a "EPSV ALL" to the NAT-PT translated V6 
node; and the v4 node (being translted as a V6 node by NAT-PT) 
issues a -ve response to this, I would think that many RFC 2428 
compliant FTP applications might simply fail, because EPSV 
support is mandatory.

If my fears are unwarranted, it certainly is reasonable to do the 
reverse translation (EPSV to PASV).

cheers,
suresh