Obviamente, percebo a necessidade de acessar o IPv6 na Internet aberta, pois estamos ficando sem endereços, mas realmente não entendo por que é necessário usá-lo em uma rede interna. Como fiz zero com o IPv6, também me pergunto: os firewalls modernos não fazem NAT entre endereços IPv4 internos e endereços IPv6 externos?
Eu estava pensando desde que eu vi tantas pessoas lutando com perguntas sobre IPv6 aqui, e me pergunto por que se preocupar?
Respostas:
Não há NAT para IPv6 (como você pensa no NAT de qualquer maneira). O NAT era uma solução temporária $ EXPLETIVA para o IPv4 sem endereços (um problema que realmente não existia e foi resolvido antes que o NAT fosse necessário, mas a história é 20/20). Ele adiciona nada além de complexidade e faria pouco, exceto causar dores de cabeça no IPv6 (temos tantos endereços IPv6 que descaradamente os desperdiçamos). O NAT66 existe e visa reduzir o número de endereços IPv6 usados por cada host (é normal que os hosts IPv6 tenham vários endereços, o IPv6 é um pouco diferente do IPv4 de várias maneiras, esse é um).
A Internet deveria ser roteável de ponta a ponta, isso é parte do motivo pelo qual o IPv4 foi inventado e por que ganhou aceitação. Isso não quer dizer que todos os endereços na Internet deveriam estar acessíveis. NAT quebra ambos. Os firewalls adicionam camadas de segurança ao interromper a acessibilidade, mas normalmente isso ocorre às custas da roteabilidade.
Você deseja o IPv6 em suas redes, pois não há como especificar um ponto de extremidade IPv6 com um endereço IPv4. O contrário funciona, o que permite que redes somente IPv6 usando DNS64 e NAT64 acessem a Internet IPv4 ainda. Hoje é realmente possível abandonar o IPv4 todos juntos, embora seja um pouco complicado configurá-lo. Seria possível fazer proxy de endereços internos IPv4 para servidores IPv6. Adicionar e configurar um servidor proxy adiciona custos de configuração, hardware e manutenção à rede; geralmente muito mais do que simplesmente ativar o IPv6.
O NAT também causa seus próprios problemas. O roteador deve ser capaz de coordenar todas as conexões que passam por ele, mantendo o controle de terminais, portas, tempos limite e muito mais. Todo esse tráfego está sendo canalizado através desse único ponto normalmente. Embora seja possível construir roteadores NAT redundantes, a tecnologia é extremamente complexa e geralmente cara. Roteadores simples redundantes são fáceis e baratos (comparativamente). Além disso, para restabelecer parte da roteabilidade, é necessário estabelecer regras de encaminhamento e tradução no sistema NAT. Isso ainda quebra os protocolos que incorporam endereços IP, como SIP. UPNP, STUN e outros protocolos foram inventados para ajudar com esse problema também - mais complexidade, mais manutenção, mais coisas que poderiam dar errado .
A falta de endereços ipv4 internos (rfc1918) também pode ser uma razão muito válida para o ipv6.
A Comcast explicou na Nanog37 por que eles usavam o ipv6 para seus endereços de gerenciamento.
20 Million video customer
x 2.5 STB/customer
x 2 ip addresses/STB
--------------------
= 100 Millions IP addresses
E isso é apenas para vídeo , não para dados / modems.
Eles esgotaram os pools RFC1918 em 2005. Em seguida, eles usaram pools de endereços públicos (como nat não é uma opção para gerenciamento) e foram para o ipv6 para resolver suas necessidades .
Duas razões:
O IPv6 não suporta transmissão. É substituído por multicast. A transmissão permite que um nó envie tráfego para todos os nós em uma sub-rede. O gerenciamento de domínios de broadcast é um grande problema para manter grandes redes IPv4 em execução rápida e sem problemas. O multicasting exige que os nós que desejam receber o estilo "broadcast" realmente "inscrevam-se" para que a rede não seja inundada com tráfego que atinja todos os hosts.
O IPv6 suporta nativamente a criptografia no estilo IPsec.
O IPv6 oferece suporte à configuração automática. É possível que os hosts atrás de um roteador se configurem sem a necessidade de DHCP, embora você ainda precise de um servidor DHCP para distribuir opções de DHCP, como servidor DNS, servidor TFTP, etc.
Meu antigo emprego, em uma grande universidade, usaria uma alocação de IPv6 internamente. Eles receberam um IPv4 / 16 naquele dia e ainda hoje estão distribuindo endereços IPv4 para quase todos os clientes internos. As redes RFC1918 eram restritas à rede somente de telecomunicações e a certos usos especializados (os padrões PCI exigiam o uso de RFC1918 até outubro de 2010).
Por causa disso, eles planejavam ativamente usar o IPv6 internamente também. Ainda havia alguns problemas de hardware a serem resolvidos, os switches de borda não estavam suportando a v6 suficientemente bem, mas o núcleo estava pronto. A idéia era que a obtenção do suporte da v6 na extremidade visível do público (ok, a extremidade responsiva ao público ) da rede envolveria 70% do trabalho para implantá-lo a todos, além de fazer 30% a mais e ir de ponta a ponta. termine com isso.
Tendo vivido com uma alocação de IP pública por tanto tempo, nosso pessoal estava muito ciente do ditado: "só porque é público, não significa que seja alcançável". Como Chris S disse, roteável não implica alcançável.
É por isso que pelo menos uma classe de organização implantaria o IPv6 internamente: porque eles já estão usando o IPv4 não RFC1918 internamente.
O IPv6 oferece algumas melhorias em potencial no mundo real sobre o IPv4, como um mecanismo mais simples de autoconfiguração e descoberta automática, também é mais seguro no sentido de que é inviável o replicação de malware em uma rede através da varredura de portas em um intervalo de IP - - existem muitos IPs. Mas essas melhorias não são particularmente dramáticas e certamente não valem o custo de troca.
Mas observe que não é uma decisão de um ou outro , você pode executar os dois em paralelo e, se desenvolver software, provavelmente deve, como muitas pessoas mencionaram, para fins de teste. Não há uma maneira confiável de tornar um programa compatível com IPv6 sem ter uma infraestrutura IPv6 interna para testar. A maioria dos sistemas operacionais modernos configurará uma rede IPv6 interna automaticamente entre eles - é apenas uma questão de usá-la.
Há 10 anos, desenvolvi um pouco de software para um empregador que os clientes usam para buscar atualizações de programas. Ao criar o componente de rede, tive que decidir entre construir na compatibilidade com IPv6 ou apenas assumir que todos os endereços IP terão 4 bytes. Decidi seguir o caminho simples, economizando cerca de 4 horas de trabalho e tornei o aplicativo somente IPv4. Imaginei que seria substituído em alguns anos de qualquer maneira. Eles ainda o estão usando hoje e, portanto, estão bloqueados em alguns mercados menores.
Trabalhando para uma pequena empresa, só consigo pensar em razões para NÃO usar o IPv6.
Simplesmente não faz sentido que uma empresa como a nossa faça a alteração, pois seria necessário um gasto e esforço consideráveis com absolutamente nada a ganhar com isso.
Francamente, gosto do NAT e dos benefícios que obtemos ao lidar com endereços locais. Se algum dia for necessário (em vez de ser um nerd que quer fazer) para interagirmos com o IPv6 na Internet, faremos isso no gateway.
Não estou esperando que essa atual moda do IPv6 se torne uma necessidade para a grande maioria do mundo, pelo menos internamente, por uma década ou mais. Como espero me aposentar até lá, não há muito incentivo para eu pessoalmente perder tempo e esforço com isso.
Editar:
Estou recebendo votos negativos, mas não uma única visão lógica e sensata da oposição. Me faz pensar que são apenas um bando de nerds que querem seguir a tendência sem pensar nisso. Tem que haver uma RAZÃO para fazer uma mudança tão drástica em uma rede e eu não tenho uma. Além disso, eu suspeito fortemente que apenas poucos usuários de SF tenham um.
Estamos falando de duas coisas aqui - executando rede interna em IPv6 puro ou executando pilha dupla IPv4 / IPv6. Eu acho que é prematuro falar sobre a execução de IPv6 puro - em muitos sistemas operacionais é até impossível usar o IPv6 sem o IPv4. No entanto, você pode considerar a execução de pilha dupla pelos seguintes motivos (a) se desenvolver software (b) para preparar sua rede para uma migração inevitável para o IPv6. Se a sua situação é A, você deve agir agora; se for B, de acordo com a minha estimativa, você terá cerca de um a dois anos para pensar sobre isso (mas quanto mais cedo você começar, mais preparado estará).
Minha situação é A e estamos executando o dual-stack por 6 meses. Durante esse período, identificamos e resolvemos alguns problemas com o DNS público / privado, alocação de endereços, DHCP, roteamento, firewall e nem sequer conseguimos antecipar muitos desses problemas sem tentar. Agora, estamos totalmente prontos para o IPv6 e temos acesso público ao IPv6 via tunelamento. Pela minha experiência, posso dizer com confiança que o IPv6 é uma solução muito mais simples e mais elegante em comparação com o envelhecimento do IPv4, por isso ficarei muito feliz quando chegar a hora de mudar para o IPv6, mas antes que esse momento chegue - a pilha dupla é o caminho ir.
Além do espaço de endereço da cerveja, ausência de transmissão, IPSec e configuração automática mais simples, existem algumas vantagens "não tão conhecidas" do IPv6:
Maior espaço de endereço significa que o endereço tem mais bits que podem ser usados como armazenamento de dados. Por exemplo, a contagem de saltos entre dois nós pode ser uma função de seus endereços IPv6, por exemplo: o
endereço IPv6 pode estar em formato PREFIX:Country&Region:DC&Line:Rack&Unit:VM&IDpara que os nós mais próximos tenham mais bits de mais significativos. Este é apenas um exemplo, é claro que as métricas de "proximidade" podem ser armazenadas em algum tipo de banco de dados externo, como TXT|SRVregistros DNS .
Existem algumas técnicas para usar o espaço de endereço do IPv6 para fins criptográficos, como CGA (Cryptographically Generated Addresses ) e SEND (SEcure Neighbor Discovery)
Quando o IPv6 está ativado, todos os nós da rede têm endereço IPv6 local de link (se não estiver configurado de outra forma). Portanto, há uma chance de que você possa acessar até o nó configurado incorretamente.
Você pode obter os endereços MAC dos nós diretamente do endereço IPv6 local do link (se as extensões de privacidade IPv6 não estiverem configuradas)
Não há como você usar IPv4 em sub-redes com milhares de nós - sua rede estará sobrecarregada com tráfego de broadcast (por exemplo, ARP).
Você pode consultar o nó para obter informações adicionais usando informações do nó ; por exemplo, no BSD, você pode consultar o host para endereços de nó de informações do nó ICMPv6:
$ ping6 -a Aacgsl ::1
PING6(72=40+8+24 bytes) ::1 --> ::1
136 bytes from ::1:
fe80::beae:c5ff:fe43:44a(TTL=infty)
fe80::beae:c5ff:fe43:212(TTL=infty)
::1(TTL=infty)
fe80::1(TTL=infty)
2a02::9222(TTL=infty)
Posso pensar em dois motivos para usar o IPv6 para um host interno.
Você pode descobrir no futuro que esse host agora precisa estar disponível externamente, pelo menos em determinadas portas.
Você pode achar que esse host precisa se conectar a outro host que também escolheu o mesmo endereço interno. Por exemplo, você precisa se conectar ao 10.0.0.5 na empresa Acme e seu próprio endereço na empresa Emca também é 10.0.0.5. Lembro que isso aconteceu em um trabalho anterior, nós dois tínhamos usado os mesmos endereços internos.
Eu diria que no mundo moderno a maioria dos computadores não é 100% interna. A maioria dos desktops pode fazer algumas conexões limitadas com o mundo externo ou vice-versa.
A única boa razão para usar o IPv6 internamente é estar pronto quando o mundo mudar para o IPv6, e acho que esse é um motivo muito ruim, dada a taxa de adoção. Como a maioria dos IPs internos não pode ser alcançada externamente, não seria grande coisa traduzir o resto.
Minha empresa provavelmente nunca mudará para o IPv6 internamente. Exigiria uma mudança fundamental na política tão maciça que não posso honestamente conceber como isso poderia acontecer. Muitas pessoas teriam que ser mortas, e muitas escolhas inexplicáveis de contratação teriam que ser feitas. Da mesma forma, qualquer tentativa por unidades de negócios individuais para mudar para o IPv6 em suas LANs seria esmagado com preconceito pela rede corporativa senhores com base em preocupações de interoperabilidade e maintainablity (que permitem muita margem de manobra no local, mas não que muito.)
Basicamente, se a mudança para o IPv6 fosse indolor, teríamos feito isso anos atrás.
O IPv4 pretendia que todos os dispositivos estivessem diretamente na Internet ... até ficarmos sem espaço de endereço. Então, passamos os últimos 20 anos travando tudo. Agora, o IPv6 por design quer, mais uma vez, colocar todos os dispositivos diretamente na Internet ... o resultado será o mesmo. Concordo totalmente que o NAT é uma camada de segurança que não será abandonada sem uma substituição igualmente eficaz, ou melhor.
Infelizmente, há muitas informações ruins na grande maioria dessas respostas e comentários. É tão triste ver os cegos guiando os cegos nisso de maneira tão prolífica.
O NAT não está indo a lugar algum e as pessoas que dizem "Ah, esse NAT, que coisa terrível é isso ..." "Oh, NAT, não passava de uma solução" ... ad nasueum que, mude para um arquiteto de rede profissional real para obter conselhos, não para um guerreiro de poltrona de redes de fim de semana.
Você precisa carregar o saldo do tráfego para servidores internos da Internet? Bem, adivinhem, com o IPv6 você não pode fazê-lo da maneira que o faz .... a menos que você use o NAT!
Sim, é verdade. Alguns dirão, oh, você apenas usa o balanceamento de carga de retorno do servidor DSR / Direct. Mas eles esquecem de dizer que você precisa desistir 1) Inserção de cookie 2) Aceleração de aplicativo 3) Tradução de endereço de porta
Portanto, se você deseja executar seus servidores internos na porta 8080, mas externos na porta 80 ... Ah, que pena, isso não pode ser feito com o IPv6 .... a menos que você esteja usando um bom NAT antigo! Nem mesmo com o DSR.
Acrescente a isso a "vanglória" que as pessoas dizem "Ah, sim, todas as propostas de NAT do IPv6 falharam ... graças a Deus" (e o império morre ao som de aplausos) Você sabe o que isso significa? O NAT será terrível, se é que funciona com o IPv6, porque todos os fanáticos do IPv6 negam a necessidade de NAT / PAT intrinsecamente e as pessoas que o fazem o fazem com relutância. Tão triste, tão mal administrado
Então, o que você faz agora que a verdade o libertou e você pode superar as multidões de lemingues tentando usar táticas de intimidação para forçar sua conformidade?
Você compra ou continua a usar um Loadbalancer ou Firewall que atua como o codificador público / privado da sua rede. As interfaces do lado público hospedam os mesmos VIPs que você já possui, mas com um endereço IPv6 complementar, se necessário. Tudo ao norte da camada Loadbalancer / Firewall também é de pilha dupla IPv4 / IPv6. Nas interfaces internas do Loadbalancer / Firewall, todas elas são IPv4 e toda a sua rede interna é IPv4 e permanece assim pelo tempo que você desejar. É apenas o seu negócio. O Loadbalancer faz NAT / PAT entre fora e dentro ... porque já é e precisa para o balanceamento de carga completo e porque agora também resolve seu problema externo de IPv6.
Ah, e para a pessoa sarcástica que perguntou: "Qual finalidade de segurança única serve o NAT"
Segurança é sobre disponibilidade no nível mais fundamental. Pense nisso antes de descartá-lo.
Os balanceadores de carga fornecem essa disponibilidade / segurança e você precisa usar o NAT / PAT para fazer isso corretamente, independentemente da versão do IP que está usando.
Citação sobre falha no DSR: https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return
k thnx
Não é uma boa idéia usar o IPv6 em uma rede interna, pois muitos dispositivos herdados falhariam na comunicação. Copiadora / impressora multifuncional antiga, equipamento médico, máquinas de impressão antigas, servidores mais antigos e dispositivos de rede. O esquema IPv4 é muito mais fácil de gerenciar imo.
A resposta aceita é enganosa
Os conceitos de Chris S sobre NAT estão muito errados; um dos melhores recursos do NAT, além da expansão artificial do esquema IPv4, é a SEGURANÇA. NAT é a camada que oculta o IP real de um host que, se conectado diretamente à Internet, pode ser o alvo de todos os ataques imagináveis. Felizmente, falar em se livrar do NAT sem incentivar medidas extras de segurança é simplesmente uma ignorância sobre o assunto.