Re: [BEHAVE] FW: New Version Notification for draft-tsou-behave-ftp46-00.txt

[Simon Perreault <[e-mail]>]

On 2012-06-19 10:57, Dan Wing wrote:
>> Deployment base doesn't matter in our case. As soon as an ISP puts
>> subscribers behind a NAT64, their FTP servers will go from IPv4 to
>> IPv6.
>> And given that current FTP server software generally includes IPv6
>> support, they will just continue using the same software. Just the act
>> of turning on a NAT64 will create IPv6-only FTP servers.
>
> Your I-D provides no guidance on how the incoming TCP/21 connection
> is expected to work with the NAT64.

This paragraph was intended to provide such guidance:

    When the FTP server is behind NAT, it can publish its service address
    via a redirect server located in the internet, or via modified DDNS
    system, or other possible methods.  It is out of the scope of this
    memo.

It goes without saying that this will be much improved in the next 
revision. :)

>>> So, are you saying the IPv4 host will have to listen on port 21?
>>
>> The FTP server is IPv6, not IPv4.
>
> Sorry for my confusion.
>
> Pretend I asked,
>
>    So, are you saying the IPv6 host will have to listen on port 21?

That's what I did in my answer below. :)

>>> Are you saying the ISP -- as part of their ALG -- will have to listen
>> on
>>> port 21, or will have to listen on some alternate port?
>>
>> No.
>>
>> We assume that not all subscribers can get port 21. They will need to
>> use another port. They can use PCP or whatever else to open a port on
>> the NAT64. Users are already trained to open a port in their home NAT,
>> with UPnP-enabled FTP server software or statically-configured port
>> redirection.
>>
>> Furthermore, this is a generic problem that happens whenever you mix
>> well-known port numbers with NAT. It is not specific to our draft, FTP,
>> or even to NAT64. So we do not try to address it in our draft.

>>> By extending RFC6384, is there an expectation that every FTP64 ALG
>>> also implement the FTP46 ALG?
>>
>> No.
>
> I'm puzzled by the extension (I presume, "Update:" in the header), then.
> But that's a small nit in the scheme of things.

Maybe my understanding of what "Update:" means is broken. Let's look at 
RFC2223...

       To be used as a reference from a new item that cannot be used
       alone (i.e., one that supplements a previous document), to refer
       to the previous document.  The newer publication is a part that
       will supplement or be added on to the existing document; e.g., an
       addendum, or separate, extra information that is to be added to
       the original document.

Well, that's exactly what we mean!

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca