Before we jump into how the new EPRT message works,
let's make sure the FTP server supports it.
You may remember from the beginning of this course when I
explained how the feature exchange works.
You also may have noticed that EPRT and EPSV are both
listed as capabilities of the server, which implies IPv6 FTP support.
I wanted to cover this briefly so that when you
inevitably migrate your network to IPv6,
you'll want to ensure your FTP server is supported.
I didn't have to make any customizations to vsftpd configuration for this.
The utility supports IPv4 and IPv6 out of the box, which is awesome.
The FTP active mode download process overall remains unchanged.
I'm skipping some of the supplementary commands,
such as type, size, and MDTM, as there are no differences from IPv4 FTP.
The first interesting action occurs when the client
sends the EPRT command to the server.
I'll dig into this packet more, shortly.
In response, the client receives a 200 message from the server,
which is very similar to IPv4,
except encourages the client to consider using extended
passive mode rather the regular passive mode.
More on EPSV later.
The client now issues the RETR command to download R1.cfg.
Based on the EPRT message,
the server initiates a new TCP session to the client using the
client signal port and sourced from the TCP port 20.
This operation works just like IPv4 FTP.
The data is then transferred from server to client inside of this data channel.
Let's quickly run through the upload process too.
As always,
the client issues the EPRT command to tell the server what port to use.
In this case, port 33591 was selected.
Next,
the client issues the STOR command to indicate it
wants to upload the R3.cfg file.
The server responds by initiating a new TCP session to port 33591,
then indicating it is ready for data upload.
The client uses the new data channel to upload the file.
Like the active mode download with IPv6 FTP,
the only substantial difference is the EPRT command.
The EPRT command is worth examining in detail.
In the classic PORT message, six individual bytes were supplied.
The first 4 represented the IPv4 addressing as individual octets.
The last 2 represented the 16-bit TCP port number used for the data connection.
Fortunately, EPRT is a bit simpler.
The key pieces of information are just arranged into a single string
and commonly delimited with the pipe character.
EPRT can also handle IPv4 addresses,
making the PORT message obsolete should the FTP client decide
to use it regardless of address family.
The first digit is a 1 for IPv4, and a 2 for IPv6,
and is followed by the properly formatted IP address.
That is to say,
dotted-decimal format for IPv4 or colon-separated byte pairs in IPv6.
The IP address and port are included as ASCII text,
which is easy for humans to read. No complex math is required here.