Let's explore how FTP passive mode works over IPv6,
again skipping the introductory commands.
The client sends the EPSV message, which isn't interesting by itself.
In reply, the server allocates a port from its passive mode port range,
selecting 42579.
If you recall from the dedicated passive mode module,
we configured a port range of 42500 to 42599,
and this applies to both passive and extended passive clients.
I'll drill into the EPSV response more later.
Upon receiving the EPSV response,
the client initiates a session to the server on port
42579 sourced from an ephemeral port.
Once the session is up, the client downloads R1.cfg using the RETR command.
The file is transferred in this new data channel
sourced from port 42579 as expected.
Not much new here.
For completeness, let's quickly skim the passive mode upload.
The client sends the EPSV message, which triggers a response from the server,
allocating port 42543 for the FTP data session.
The client then builds a new TCP session for the
impending file upload using this port,
again sourced from a random high-numbered port.
The client issues the STOR command with R3.cfg as an argument,
indicating it wants to upload the specified file.
Once granted permission by the server,
the client uploads the file and the transfer completes successfully.
The process is identical to IPv4 FTP, notwithstanding the EPSV command.
Let's drill into the extended passive reply a bit more.
If you recall from the FTP passive mode module,
the PASV message is rather boring.
The message was a signal from client to server,
which requests that the server dynamically select a TCP port
upon which to listen for a data connection.
The EPSV message does the same thing,
except it triggers a different response on the server.
The reply from the server is a little different than the
classic PASV response in a few ways.
The message always begins with three delimiters,
normally pipe characters, per RFC2428,
followed by the ASCII text of the port number.
It ends with a trailing delimiter.
More importantly, the message does not contain an IPv6 address.
EPSV operation assumes that the IPv6 address on the server
to which the control session was established will also be
used for the data transport,
and thus explicit addressing is omitted from the EPSV response.
Wireshark shows it here for completeness,
but because it is incased in square brackets means that
this was an inference by Wireshark, not data carried in the packet.
The RFC does mention the EPSV response could carry IP addresses in future, but at present they are not included.