Network address translation: diferenças entre revisões

Conteúdo apagado Conteúdo adicionado
m Página marcada que carece de mais fontes
Linha 19:
 
== Limitações ==
Os hosts por trás dos roteadores com o NAT habilitado não possuem conectividade fim-a-fim e não podem participar em alguns protocolos da Internet. Por reconhecer apenas os protocolos [[TCP]] e [[Protocolo UDP|UDP]], não é possível estabelecer uma conexão que não utilize um desses protocolos. Serviços que exigem o início de conexões [[Transmission Control Protocol|TCP]] do lado externo da rede, ou protocolos stateless, como aqueles que utilizam o [[User Datagram Protocol|UDP]], podem ser comprometidos. A menos que o roteador com NAT faça um esforço específico para suportar tais protocolos, os pacotes recebidos não podem alcançar seu destino. Alguns protocolos podem acomodar uma instância de NAT entre hosts participantesparticiaaa

pantes (o "modo passivo" do [[File Transfer Protocol|FTP]], por exemplo), às vezes com a ajuda de um ''application-level gateway'', mas falham quando ambos os sistemas estão separados da Internet pelo NAT. O uso de NAT também complica os protocolos de tunelamento, como o [[IPsec]] porque o NAT modifica valores nos cabeçalhos que interferem nas verificações de integridade feitas pelo [[IPsec]] e por outros protocolos de tunelamento.
 
A conectividade fim-a-fim tem sido um princípio fundamental da Internet, apoiado, por exemplo, pelo ''Internet Architecture Board''. Os documentos arquiteturais atuais da Internet observam que o NAT é uma violação do princípio fim-a-fim, mas esse NAT tem um papel válido no design cuidadoso.<ref>R. Bush; and D. Meyer; RFC 3439, [http://www.ietf.org/rfc/rfc3439.txt ''Some Internet Architectural Guidelines and Philosophy''], December 2002</ref> Há consideravelmente mais preocupação com o uso do NAT no IPv6, e muitos arquitetos do IPv6 acreditam que o IPv6 foi projetado para remover a necessidade do NAT.<ref>G. Van de Velde ''et al.''; RFC 4864, [http://tools.ietf.org/rfc/rfc4864.txt ''Local Network Protection for IPv6''], May 2007</ref>