Subject: FTP broken for API level protocol translators??

From: Peter Tattam <[email-masked]>
Date: Sat, 26 Jun 1999 19:29:07 +1000 (EST)

Although FTP can get through IPv4 NAT's using passive mode, I believe there may
be a stumbling block for IPv6 NATs as the FTP commands are different.

	IPv6 FTP server -> translator -> IPv4 FTP client.

Anyone got any ideas on how this could be dealt with without rewriting the FTP
command TCP session.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Sat, 26 Jun 1999 22:17:05 +0900

>Anyone got any ideas on how this could be dealt with without rewriting the FTP

	Among the commands for requesting data connection, EPSV (RFC2428) is
	the only one which never transmit address in control TCP stream.
	So, only EPSV has a good chance to fit your requirement.

	However, most of IPv4 ftp client does not EPSV.
	For translator you may need to remap tcp port # anyway,
	so even if IPv4 client supports EPSV you may need a rewrite in
	control TCP stream.

	SUMMARY: you need to rewrite control TCP stream anyway.

itojun

---

From: Francis Dupont <[email-masked]>
Date: Sat, 26 Jun 1999 15:40:35 +0200

In your previous mail you wrote:

   
   
=> the best solution is to use the Simple PORT command in passive mode.
I think Craig (author of I-Ds about this) will answer soon.

[email-masked]

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 26 Jun 1999 12:31:21 -0700 (PDT)

<draft-ietf-nagtrans-natpt-06.txt>, section 6 covers this.
Note, It may be a day or two before this draft is announced.

cheers,
suresh

---

From: Peter Tattam <[email-masked]>
Date: Sun, 27 Jun 1999 15:10:13 +1000 (EST)

Hmm.  Looks like intercepting the command stream is the only way.  Guess I'll
have to monitor send() call for the "PASV" command and take action there,
presumably converting it to an EPSV.  Then I would need to translate the
response code back into the translated IPv4 address. 

I think this could be done if one assumed that the command/response calls were
atomic.  There are complications on the recv() call as it could potentially be
called with MSG_PEEK and the call may only return a partial result.  The send()
call would typically be atomic so not too much of a problem.

Is this a reasonable assessment?

Also, is there any way that existing FTP servers could be modified to cope with
translation without having to rewrite the command stream.  At this stage, this
could be beneficial as the number of deployed IPv6 FTP servers would be
relatively small making the process easy.  The process would have been trivial
had the designers of FTP stuck with a symbolic method of passing the listened
to address....  i.e.

	227 Entering Passive Mode (203.5.119.51,4586)

Instead of 

	227 Entering Passive Mode (203,5,119,51,17,234)

as it would have allowed us to replace the symbolic IPv4 address with a IPv6
address.  Then the client would use inet_ntoa to translate it into machine
form which would have been easy for an API level translator to translate from
an Ipv6 symbolic address to an IPv4 symbolic address.

But alas, the deployment of IPv4 FTP clients is far too widespread to change
things there.

I have an idea....

One possibility that I can think of is that somehow the IPv6 FTP can determine
that there is an API translator behind the the FTP session.

This information could be conveyed via some out of band mechanism - perhaps a
TCP option that gets passed with the command connection that says what the
internally translated IPv4 address is.  

Another possibility is that an ICMPv6 probe or IPv6 option could be sent to the
peer which would return whether this particular connection was being used by a
non IPv6 aware client.

In fact, this technique may have wider application than FTP, and could indeed
be used for any protocol that passes IP address information as part of the
session. It could also untangle the mess that translators make in this process.

My money is on the TCP option.  The information could be passed at connection
startup and then obtained via the getsockopt() or ioctl() calls.

Peter

---

From: Craig Metz <[email-masked]>
Date: Sun, 27 Jun 1999 01:22:13 -0400

In message <[email-masked]>, yo
>that there is an API translator behind the the FTP session.

  In the general case, this is not possible. Consider a path with multiple
protocol translations back and forth, and maybe some NATs in the IPv4 path.
Sick, twisted, yet something that very weill might happen. So there's no way
for the ends to know completely what protocol(s) might be running in the
middle, and not a whole lot of way generally for them to tell what protocol(s)
are available at the other end.

  One possibly more practical solution is to try to get some of the major FTP
daemons supporting EPSV. A large portion of the anonymous FTP servers in the
world run a small number of different daemons (wu, proftpd, etc.), so you
could reach a fairly reasonable deployment critical mass fast. This wouldn't
mean you wouldn't have to make your protocol translator do the old search and
replace, but, together with the EPSV ALL, you can at least be able to quickly
determine for most connections that you don't actually have to do any replaces
(and then your implementation can fast-path the connection(s) for the rest of
their lifetime).

									-Craig