Re: [ftpext] draft-ietf-ftpext2-ftp64-00 translation scenario
liu dapeng <maxpassion@gmail.com> Mon, 04 July 2011 05:04 UTC
Return-Path: <maxpassion@gmail.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3479121F855F for <ftpext@ietfa.amsl.com>; Sun, 3 Jul 2011 22:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcGsp7ovdJXI for <ftpext@ietfa.amsl.com>; Sun, 3 Jul 2011 22:04:56 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 878BF21F8560 for <ftpext@ietf.org>; Sun, 3 Jul 2011 22:04:56 -0700 (PDT)
Received: by iye7 with SMTP id 7so5185250iye.31 for <ftpext@ietf.org>; Sun, 03 Jul 2011 22:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FxyqPcz/0gs8ySG7IQ9fH7UQhCSpQ63x+g7+BHa8GCI=; b=BFG6+z+QbfjCqJms+kHvdvROhhc7PvjdOtSdCdQUG4VCYgvyIfsU6Z1gUIfslxZmVm 6s8h+n3VyiU2QFW+ZJVupiLidLk7YuHMwN1EQFcXEqQatyWv9hgnIh91Kdzf5cvYHTrH bssQpz6umdcto9VvkmxG3n8eTcK6ujV4jo+gc=
MIME-Version: 1.0
Received: by 10.42.19.2 with SMTP id z2mr1187673ica.498.1309755895831; Sun, 03 Jul 2011 22:04:55 -0700 (PDT)
Received: by 10.231.115.8 with HTTP; Sun, 3 Jul 2011 22:04:55 -0700 (PDT)
In-Reply-To: <F15941D3C8A2D54D92B341C20CACDF2311976FED2A@exchange>
References: <Acu2ZZ/c55xqKk71TX2R++NZHeH5cw==> <F15941D3C8A2D54D92B341C20CACDF2311976FED2A@exchange>
Date: Mon, 04 Jul 2011 13:04:55 +0800
Message-ID: <CAKcc6Afnkc18QvPBHhb5nfNq-hot=FDtnxjWm5j7Aj4XLAh0nw@mail.gmail.com>
From: liu dapeng <maxpassion@gmail.com>
To: Robert Oslin <rto@globalscape.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "ftpext@ietf.org" <ftpext@ietf.org>
Subject: Re: [ftpext] draft-ietf-ftpext2-ftp64-00 translation scenario
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jul 2011 05:04:57 -0000
Hi Robert, Thanks for the comments. 2011/1/18, Robert Oslin <rto@globalscape.com>: > This draft makes the case for how an IPv6 FTP client should behave when > processing an IPv4 FTP Server PASV/PORT reply when going from an IPv6 > network through a translation device. > > In general I'm in favor of "client intelligence"*, and I don't see that it > explicitly violates RFC959 in terms of handling the PASV response, although > it does so implicitly since the client should be using the IP and port > provided in the server reply. > > My point of contention is this: Why an RFC at all? Unless I'm mistaken, > translation, such as NAT-PT, BIS, BIA, etc. has been moved to experimental > status, as translation should be considered a "last resort" when other IPv6 > transition options are unavailable (dual stack, tunneling, etc.). ==> Actually, in Behave working group, NAT64 (RFC6146 ) is intend to be standard track. Besides, in IPv4/IPv6 transition period, there would be IPv6 client access IPv4 server scenario, that is why IETF specifies NAT64. > ~~~ > > *Clients should do this today in an IPv4 world if for example a PASV reply > contains network address prefix, e.g. 192.168.0.0/16, which can happen if > using encrypted communications and going though NAT and the server hasn't > configured the "external" facing IP (And since the session is encrypted, NAT > can't see the address to change it). The client should identify this (and > similar) wrong IPs and reuse the control connection's IP. ==> That is a valide scenario, I will include this in the updated version. Thanks! Best regards, Dapeng Liu > Robert Oslin > Director of Product Management > Tel: 1 (210) 293-7902 > Fax: 1 (210) 690-8824 > Send me large files securely > > www.globalscape.com > > (NYSE Amex:GSB) > *This communication, including attachments, is for the exclusive use of the > addressee and may contain proprietary, confidential or privileged > information. If you are not the intended recipient, any use, copying, > disclosure, dissemination or distribution is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately by return > email and delete this communication and destroy all copies. > > > _______________________________________________ > ftpext mailing list > ftpext@ietf.org > https://www.ietf.org/mailman/listinfo/ftpext > -- ------ Best Regards, Dapeng Liu