> -----Original Message----- > From: GangChen [mailto:phdgang@xxxxxxxxx] > Sent: Friday, September 30, 2011 2:53 AM > To: Dan Wing > Cc: Hui Deng; behave@xxxxxxxx; ietf@xxxxxxxx; softwires@xxxxxxxx; > Cameron Byrne > Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-v4v6-bih-06.txt> > (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard > > >> > >> Option 1: > >> > >> +---------------+ > >> |BIH(FTP sever) |----------NAT64-------FTP Client > >> +---------------+ > >> > >> > >> Option 2: > >> > >> +---------------+ > >> |BIH(FTP sever) |--------------FTP Client > >> +---------------+ > >> > >> In the case of Option 1, it can't work since NAT64 couldn't support > >> IPv4 initiated session > > > > I agree it would fail with a passive-mode transfer. But it should > > work with an active-mode transfer. > > > > In an active-mode transfer, IPv4 client needs initiate the TCP > connection to a port on the FTP sever in advance. Afterwards, FTP > server connects back to the client. > I'm not sure how could NAT64 support the first step (i.e. IPv4 > initiated TCP connection)? Static mapping in the NAT64, for the FTP control channel (port 21 or an alternate port). That could be done by the user's profile (draft-cheng-behave-nat-fwd-port-radius-ext), PCP, or a web portal that manages the NAT64's configuration. -d > Many thanks > > Gang _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf