Hi,
>>> Sun, 06 Feb 2000 17:42:14 +0900 の刻に「shin」、すなわち
>>> Yoshinobu Inoue <[EMAIL PROTECTED]> 氏曰く
shin> Wmmm, I actually enabled it, but it is causing problems, so
shin> should EPSV only allowed for IPv6 at least for several
shin> starting 4.x releases?
I'm sorry. My previous message confused you.
shin> (About EPRT, initiating client retry PORT command next if EPRT
shin> failes, so trying EPRT first will be OK.)
No. In this senario, if server knows EPRT, EPRT request will be
accepted, and will not fail. But, existing NAT box doesn't handle
EPRT request. So, NAT box cannot treat data connetion as if it treat
for PORT. Then, data connection request from server will not reach to
client.
shin> As RFC2428(FTP Extensions for IPv6 and NATs), EPSV can be used
shin> for IPv4 and IPv6 and it has performance benefit for firewall
shin> and NAT, because it doesn't include an IP address in its
shin> command, so firewall and NAT doesn't need to translate them.
No problem will occur with EPSV on even if IPv4. If server doesn't
know EPRT, client will try PASV next.
shin> And there is also a chicken and egg issue, because if usual
shin> ftp clients don't try EPSV first, then usuall firewall and NAT
shin> don't notice the necessity of supporting EPSV.
I agree. I think EPSV is OK in any case. We should be careful to
only EPRT on IPv4. Using EPRT on IPv4 is a chicken and egg issue.
shin> But now passive is used by default, and not many firewall and
shin> NAT support it yet, so many user will be upset that they can't
shin> connect to some of ftp servers.
It's firewall and NAT frendry. :-)
shin> So if no other better suggestion, I think I'll get permission
shin> to fix 4.0 ftp client to try EPSV only for IPv6.
EPSV is NAT frendly. I think disabling EPRT on IPv4 is better for a
while.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
