Configurei um roteador simples que deve fornecer conectividade IPv6 para máquinas que estão na LAN por trás dele. O roteador possui 2 interfaces de rede (eth0, eth1), as máquinas possuem 1 (eth0).
Na eth0 do roteador é o acesso apenas à rede local, na eth1 é o acesso à internet. Eu configurei todos os parâmetros do kernel, tudo funciona bem.
O IP do roteador é fd00::1
, instalei o dhcpd no roteador e configurei o intervalo fd00::100 - fd00::fffe
.
Quando eu inicio alguma máquina nesta rede, ela recebe IP do dhcpd, por exemplo fd00::fffa
, mas não consegue acessar a internet por motivos óbvios - está faltando a rota.
Quando adiciono a rota manualmente sudo route -6 add 2000::/3 gw fd00::1
a máquina começa a ter acesso à internet até que eu a reinicie.
Posso adicionar essa rota manualmente ao script de inicialização de cada máquina, mas prefiro configurá-la automaticamente para que, quando eu inicializar uma máquina nesta rede, ela tenha acesso à Internet IPv6 sem necessidade de mais nada.
Baseado em algumas sugestões instalei também o radvd no roteador e inseri esta opção:
route 2000::/3 {};
Provavelmente está errado, mas não consegui encontrar nenhuma documentação ou exemplo. Não funciona. Usar radvd em vez de dhcpd para atribuir endereços IPv6 não funciona, se eu desabilitar máquinas dhcpd configurar automaticamente alguns endereços IPv6 aleatórios e nem mesmo se verem, eles também não poderão executar ping no roteador.
Como configuro minha LAN para configurar automaticamente o IPv6 para todas as máquinas nela?
Nota: não preciso nem quero que cada máquina tenha IPv6 público, NAT está bem.
Responder1
Identifico imediatamente dois problemas com sua configuração. Os endereços RFC 4193 não são roteáveis globalmente. Isso significa que esses endereços não poderão se comunicar com o mundo exterior.
Claro que você pode usar o NAT, mas o NAT é conhecido por causar vários problemas. NAT é uma solução alternativa destinada a resolver temporariamente a escassez de endereços IP. O IPv6 resolve esse problema. Todos os outros problemas que as pessoas tentaram resolver usando NAT têm uma solução melhor que não envolve NAT.
Além disso, seu prefixo claramente não foi gerado de acordo com as especificações da RFC 4193. Citação relevante:
IDs globais atribuídos localmente DEVEM ser gerados com um algoritmo pseudo-aleatório
Se esses dois problemas na configuração da rede impedem os clientes de se comunicarem externamente, você só descobrirá testando. Existem softwares que tentam detectar configurações IPv6 abaixo do ideal e evitar completamente o uso de IPv6, se algum for detectado. É bastante plausível que algum software cliente se recuse a usar a conexão IPv6 em sua configuração.
Dito isto, não é impossível fazer com que os clientes se comuniquem externamente usando endereços RFC 4193. Aqui está um radvd.conf
arquivo que usei brevemente no passado. Com esta configuração, alguns clientes tentaram se comunicar externamente usando seus endereços RFC 4193 atribuídos.
interface wlan0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix fdbd:5df9:dca3::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
Esta configuração, entretanto, não funciona com todos os clientes. Testei novamente com um cliente rodando Android. O telefone configurou um endereço IPv6, mas não tentou usar IPv6 para comunicação externa.
Em seguida, mudei o prefixo para 2001:db8:dca3::/64
, momento em que o telefone começou a enviar pacotes IPv6 para o gateway. Portanto, o Android é um exemplo de plataforma que se recusa a usar endereços RFC 4193 dessa forma.