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