The good news is that despite the new messages,
the basic FTP communications don't change.
Let's explore FTP active mode first.
For brevity, I'll cover both downloads and uploads here.
Let's start with a download script.
You'll notice that the script is identical to the IPv4
FTP active mode download script,
except the server's address is IPv6 rather than IPv4.
The script still downloads R1.cfg and prints the directory contents.
Let's run the script and examine the resulting debug output.
The FEAT process reveals that the server supports both extended port for
active mode and extended passive for passive mode.
This is required for FTP to work across IPv6 networks.
Skipping the intermediate steps, the client issues the EPRT command,
which unlike the classic port command,
doesn't require any complex math to read via debugging.
We can clearly see the client's IPv6 address and dynamic port number of 51925.
Next, the client issues the RETR command to download R1.cfg,
and then accepts the new TCP connection from the server for the data transfer.
This session is always sourced from TCP port 20, regardless of IP version.
The file is transferred successfully and the program exits.
Next, let's try and upload.
The script is identical to its IPv4 equivalent except,
again, that the server address is now shown using IPv6.
We still use the put command for uploads.
Let's run the script.
The client issues the EPRT command to tell the server to connect to
port 44545 when data needs to be transferred.
Then the client tells the server it wants to upload R3.cfg.
This triggers the server to initiate a new TCP
session to port 44545 for the upload.
The client uploads the data to the server successfully using IPv6 FTP.
I'm moving quickly since this is quite repetitive,
but I wanted to provide known good examples for those undergoing an IPv6 migration.