Como organização, acabamos de solicitar nossa primeira alocação de IPv6. Atualmente, somos uma organização totalmente IPv4 com uma alocação global de endereços IPv4 configurada em nosso roteador de borda e usada (predominantemente) para o NAT por meio de um firewall de borda para servidores da Web hospedados internamente com endereços IPv4 privados.
Eu aprecio que uma maneira de disponibilizar nossos serviços de face externa para a Internet IPv6 seria implementar pilha dupla de IPv6 em toda a rede interna e atribuir diretamente endereços IPv6 acessíveis globalmente (além de seus endereços IPv4 existentes) a esses servidores .
No entanto, mesmo depois de ler muitas postagens e artigos sobre tecnologias de transição IPv6 e os prós e contras de NAT em um mundo IPv6, ainda não tenho certeza se poderíamos essencialmente replicar nossa configuração existente, mas com endereços IPv6, Ou seja, poderíamos configurar uma interface IPv6 roteável globalmente em nosso roteador de borda com uma interface IPv6 'externa' associada em nosso firewall e simplesmente 1: 1 NAT globalmente voltado para endereços IPv6 em um endereço IPv4?
Isso se baseia obviamente no princípio de que temos um acordo de emparelhamento de BGP IPv6 com nosso ISP e que nossas necessidades de endereçamento interno são atendidas pela RFC1918, mas gostaríamos de tornar os serviços externos selecionados acessíveis para IPv6.
Como dito no primeiro comentário, eu também sugiro que você mude para o dual-stack, já que, no longo prazo, é mais barato do que implementar soluções NAT. (Você terá que fazer isso de qualquer maneira, então porque não agora?)
Mas ainda assim, para o seu problema, existem duas possíveis soluções / workarounds:
Essa forma de disponibilizar os serviços IPv4 no IPv6 é bastante comum. Você precisa de um firewall que possa fazer mapeamentos estáticos de NAT64. Eu fiz isso usando caixas Juniper SSG.
No entanto, eu vi alguns problemas com a fragmentação. Como um cabeçalho IPv6 é maior que um cabeçalho IPv4, a conversão tornará o pacote um pouco maior. Isso pode fazer com que o pacote IPv6 seja fragmentado e eu vi dispositivos que ignoram todo o tráfego fragmentado. Para evitar problemas com usuários que têm esse tipo de dispositivo quebrado, é melhor reduzir um pouco o MTU no lado do IPv4 (1480 ou 1400 são valores comuns) para que, mesmo após a conversão, o pacote seja menor que 1500 bytes.
Sim.
Você precisará de uma implementação de NAT64 com estado. Normalmente, eles são usados para fornecer aos clientes IPv6 locais acesso a recursos na Internet IPv4 pública, mas nada impede que você use o inverso. Os firewalls podem ser usados para limitar quais hosts podem ser acessados através do gateway NAT64.
Em geral, eu diria que não.
O principal problema com essa abordagem é que você perderá informações sobre o endereço IP de origem do tráfego. Simplesmente não há maneira de empinar um IP de origem de 128 bits em um campo de 32 bits. Por isso, será difícil rastrear e denunciar abuso.
Existem serveral. Vou apresentá-los no que considero ser ordem decrescente de preferência.
A primeira opção é implantar a pilha dupla nesses segmentos da sua rede entre os servidores e a borda da rede. Essa é uma boa prática para quando você começar a implantar o IPv6 em toda a sua rede.
A segunda opção é implantar túneis que vão da sua borda da rede para os servidores em questão. Os túneis podem trazer o tráfego ipv6 pela rede IPv4 para os servidores, que podem então processá-lo nativamente.
A terceira opção é um proxy reverso. Como funciona no nível do aplicativo, ele pode codificar as informações do endereço IP externo em um cabeçalho de nível de aplicativo. Alterações no lado do aplicativo podem ser necessárias para aproveitar essas informações, mas muitos aplicativos já o suportarão, já que as configurações de proxy reverso são bastante comuns em grandes implantações por outros motivos.
Sim, Mem está totalmente certo. Dual Stack e apenas no lado público da rede é um primeiro passo obrigatório ... que é o verdadeiro assalto. Isso não quer dizer que ESTÁ TAMBÉM pronto para abandonar o IPv4.
Os dispositivos NAT farão o que sempre fizeram. O IPv6 oferece espaço de endereçamento privado, mas não há como garantir que ele seja globalmente único ... então ainda precisamos NAT para garantir isso. A maioria das pessoas ainda está usando o NAT e perpetuamente, independentemente do ímpeto por trás do NAT décadas atrás. Não há necessidade crítica de impingir IPv6 em qualquer coisa dentro de sua rede que esteja sob um NAT / SNAT usando NAT444 / CGNAT
Este é um estudo de 2013 feito sobre o IPv6 no nível do governo. Faz eco da linha do tempo e da orientação de quão longe está o mundo da dominação do IPv6 e do abandono do IPv4, além de toda a exigência intermediária de dual-stack que terá que durar toda a duração da transição.
Ao procurar por dispositivos para fazer isso, procure NAT por NAT444 / CG-NAT ... Isso não é o mesmo que NAT64, NAT44, etc.
O IPv4 estará aqui até o ano 2148. Artigo abaixo link
Sim, claro que você pode. Na verdade, essa é a coisa mais sensata a se fazer.
Não acredite em pessoas que dizem "Oh .... você terá que mudar toda a sua rede para Ipv6 eventualmente, então não demore"
Absolute nonsense.
Eu já passei por isso no nível de nível de operadora.
O IPv4 chegou para ficar. Funciona muito bem para a grande maioria das organizações, por causa do RFC1918.
Se você é uma organização com menos de 17 milhões de dispositivos que exigem endereços IP sob seu controle legal direto. Então o IPv6 será pouco mais que um speedbump e certamente não afetará seus servidores / desktops. Aqui está como você faz isso:
Assumindo que você entende o design de rede clássico.
Seus roteadores de borda são MPLS / IPv6 / IPv4
Seus Core Rouers são MPLS / IPv6 / IPv4
Seus roteadores da Distro são MPLS / IPv6 / IPv4
Suas interfaces externas do Loadbalancer / Firewalls são IPv6 / IPv4 e plugam upstream na Distro. A F5 suporta isso com muita honestidade sem esforço e o LTM como um firewall de entrada (muito mais rápido do que os firewalls da juni / cisco), por isso não precisamos usar o ACLS nos roteadores da Distro
As interfaces internas do Loadbalancer / Firewall são todas puramente IPv4 e conectam-se à sua espinha / folha ou aos roteadores e switches de serviço / acesso da camada 2, que também permanecem IPv4 se estiverem na camada 3.
Então você mantém o NAT. Você mantém uma fronteira IP NAT / privateIP rígida com dispositivos como o F5 BIGIP e os Firewalls que manipulam facilmente o IPv6 para o IPv4 NAT. Eles conectam sua camada de distribuição pública com sua camada privada de serviço / acesso.
Agora tudo o que você escolhe para manter o NAT (que provavelmente já é) permanece IPv4 e todo o software host do crap IPv6 pode ser excluído impunemente porque apenas o seu equipamento de rede high end executado na rede pública da rede yoru tem que se preocupar sobre o IPv6
Sério, seja sábio. O IPv6 não está ultrapassando o IPv4 em nossas vidas de qualquer forma que signifique algo. Com essa taxa atual de adoção, ele não estará pronto para as tabelas BGP IPv4 em termos de tamanho por mais de 200 anos.