A única diferença é que PORT/PASV está limitado a IPv4 , enquanto EPRT/EPSV funciona com qualquer protocolo de rede (embora somente IPv6 seja usado na prática). / p>
Os comandos padrão PORT (ativo) e PASV (passivo) no endereço de troca do protocolo de controle FTP & informações de porta como seis decimais de 1 byte , a partir das quais a outra extremidade precisa reconstruir um endereço IP de quatro bytes e um número de porta TCP de dois bytes.
PORT <address[4]>,<port[2]>
PORT 132,235,1,2,24,131
Mas outros protocolos começaram a aparecer. O IPv4 estava prestes a ser substituído por "IPng", que tinha várias propostas concorrentes de substituição (OSI CLNP, TUBA, SIP, SIPP, CATNIP - em vários vezes no histórico), alguns com tamanhos de endereço de host mais curtos, maiores e até variáveis , até que o IPv6 com endereços de 16 bytes finalmente seja definido.
Apenas o envio de mais bytes não teria funcionado - não se poderia esperar que servidores e clientes conhecessem o protocolo correto baseado apenas no tamanho do endereço. (Por exemplo, e se você tiver um protocolo com endereço de 16 bytes + porta de 4 bytes, outro com endereço de 12 bytes + porta de 12 bytes?)
Além disso - embora isso tenha sido menos importante há 20 anos - atualmente existem milhões de dispositivos NAT na Internet, que inspecionam e manipulam as conexões de controle FTP para que o host "externo" só veja endereços IPv4 globais, mesmo que o host "interno" tenha enviado um local RFC1918. Mesmo sem NAT, os firewalls com monitoração de estado geralmente observam os comandos de controle para permitir automaticamente uma conexão de dados sem regras manuais.
Isso basicamente significa que o simples envio de mais números com PORT ou PASV é garantido para muitas pessoas. Talvez alguns firewalls silenciosamente interpretassem incorretamente alguns bytes de endereço como a porta e descartassem silenciosamente o restante; outros podem soltar a conexão ou simplesmente travar.
Para evitar vários problemas como o descrito acima, novos comandos tiveram que ser introduzidos para suporte multiprotocolo em FTP.
Em 1993, RFC 1639 (originalmente RFC 1545 ) introduziu os comandos "endereço longo" LPRT e LPSV , que eram como PORT & PASV , mas com um comprimento de endereço variável ; Eles incluíram o identificador de tipo de protocolo também. (Não alterou a sintaxe embora - endereço IPv6: a porta seria simplesmente enviada como 21 números em vez de seis).
LPRT <protocol>,<addr-length>,<address...>,<port-length>,<port...>
LPRT 4,4,132,235,1,2,2,24,131
LPRT 6,16,16,128,0,0,0,0,0,0,0,8,8,0,32,12,65,122,2,20,162
No entanto, isso ainda não corrigiu alguns dos problemas, como pedir a um servidor para usar um protocolo diferente do que para a conexão de controle. O RFC também ficou rapidamente desatualizado; quando o IPv6 foi lançado apenas um ano depois, não pôde ser usado com a LPRT porque não havia identificador de protocolo LPRT atribuído a ele (apenas para as várias propostas iniciais).
Para corrigir isso, RFC 2428 em 1998, adicionou EPRT e EPSV , também conhecido como "extended port" e "extended passive" , que também tinha um método para negociar um protocolo que ambas as extremidades suportam. Os comandos "extended" também enviam endereços em formato legível - para IPv6, o que significa usar hex & notação de dois pontos, em vez de uma série de números decimais separados.
EPRT x<protocol>x<address>x<port>x
EPRT |1|132.235.1.2|6275|
EPRT |2|1080::8:800:200C:417A|5282|
Em conclusão, o suporte ao IPv6 é a única diferença.