O IPv6 poderia ter uma vantagem sobre o IPv4?

Já escrevi sobre minhas aventuras no IPv6 antes. Basicamente, parecia que o IPv6 resolveu o problema de limitação de espaço de endereço com um espaço de endereço maior, enquanto o IPv4 usava apenas NAT, e isso significava que o IPv6 não agregava muito valor porque o IPv4 praticamente não tinha mais preocupações com espaço de endereço. Se algum dia preenchermos o espaço de endereço de 64 bits do NAT, poderíamos simplesmente adicionar outra camada de NAT e ter um espaço de endereço de 96 bits, e ad infinitum. Oh espere, nós já fizemos. CGNAT é exatamente isso.

Sim, o IPv6 tem outras sutilezas, como a configuração automática sem estado, que elimina a necessidade de DHCP, um espaço de endereço totalmente roteável, roteamento e multicast supostamente melhores, mas também tem muitas peculiaridades. Os endereços IPv6 são muito longos para um. Eles são impossíveis de memorizar enquanto eu me sinto confortável em escrever 192.168.1.23. Portanto, parecia que não valia a pena converter para o IPv6.

IPv4 acontece

Adoro o WireGuard como solução VPN e uso-o para me conectar à minha rede doméstica enquanto estou viajando. Na semana passada, tentei conectar minha casa pelo Airbnb no Havaí, mas não consegui acessar minha rede. Houve vários problemas com minha conexão VPN e todos eles tiveram uma única causa raiz.

O primeiro problema foi: tenho um servidor em casa que acessa APIs em um site remoto usando WireGuard. Quando quis acessar meu servidor, não consegui. Não recebi uma resposta de ping. Mas eu poderia acessá-lo sem problemas quando estivesse em casa.

O problema acabou sendo que tanto a rede WireGuard para aquele site remoto quanto minha VLAN em casa para minha própria conexão VPN usavam a mesma sub-rede: 192.168.2.0/24. Então, sempre que eu fazia ping em meu próprio servidor, ele recebia o pacote, mas o encaminhava para aquele site remoto pelo WireGuard, e o pacote simplesmente desaparecia. Minha sub-rede da rede doméstica conseguiu acessar o servidor sem problemas porque minha rede doméstica estava em uma sub-rede diferente.

Meu segundo problema foi que eu não conseguia nem acessar outros dispositivos na VLAN padrão da minha rede doméstica. Desta vez, o motivo foi que o Airbnb Wifi e a minha rede doméstica estavam na mesma e bem conhecida sub-rede de 192.168.1.0/24. Quando o endereço IP que você deseja acessar corresponde à sua sub-rede local, seus pacotes não são encaminhados para o gateway, eles são apenas pesquisados ​​usando o protocolo ARP e, se um dispositivo não for encontrado, você receberá um erro no cliente.

Ambos os problemas estavam acontecendo devido a sub-redes conflitantes, conforme visto na figura abaixo.

Você consegue ver o padrão? Aparentemente, o IPv4 não foi projetado para comunicação ponto a ponto entre sub-redes locais. Pesquisei o problema e os artigos e comentários do fórum diziam “basta alterar a configuração da sub-rede, mano”, o que não era de todo possível com o meu Airbnb Wifi, com o servidor remoto ou com a minha rede doméstica.

Alguns artigos sugeriram adicionar regras de firewall para traduzir uma sub-rede diferente para a sua, para que eu pudesse usar os endereços da sub-rede 10.0.0.0/16e eles seriam traduzidos para para 192.168.0.0/16. Se eu quisesse acessar 192.168.1.23eu teria que digitar 10.0.1.23 em vez de.

Quer dizer, provavelmente era algo que eu poderia fazer, mas estava longe do ideal. E se eu estiver desenvolvendo um software e precisar de endereços consistentes para me conectar? E se eu precisar usar DNS ou mDNS? Como vou lidar com todos esses conflitos?

É aí que o IPv6 realmente ganha vantagem.

IPv6 não tem sub-redes locais sobrepostas

Ou, mais precisamente: o IPv6 não possui sub-redes locais. Quero dizer que sim, mas geralmente eles não são usados ​​após a configuração inicial da rede do seu host (veja: minhas aventuras anteriores). Os endereços IPv6 são roteáveis ​​globalmente e, portanto, distintos uns dos outros, independentemente da sua configuração. A segunda metade do seu endereço IPv6 é gerada aleatoriamente, mas teoricamente, se cada cliente ISP na Terra atribuísse o mesmo número a um dispositivo IPv6 em sua rede para essa segunda metade, cada um ainda teria um endereço exclusivo.

Então, se o nosso Airbnb Wifi tivesse uma rede IPv6, minha sub-rede local não seria 192.168.1.0/24seria algo como 2600:1122:3344:5566/64. Minha casa teria uma sub-rede como 2605:7788:99AA:BBC0/60. O site remoto ao qual meu servidor se conecta teria outra coisa, 2603:DDEE:FF00:1122/64. O roteamento entre esses nós não teria conflitos. Meu WireGuard funcionaria perfeitamente.

Talvez seja por isso que o Tailscale usa IPv6 nos bastidores.

Qual é o problema?

Há uma coisa boa nas sub-redes locais: elas permanecem. O IPv6 não oferece tais garantias. Primeiro, devido à configuração automática, seu endereço IP está sujeito a alterações após a reinstalação do sistema operacional, ou mesmo uma inicialização dupla ou algo assim. Em uma rede IPv4, o DHCP forneceria o mesmo endereço porque o endereço MAC fornecido pelo adaptador de rede permaneceria o mesmo. Para obter isso no IPv6, talvez seja necessário usar DHCPv6 e persistir seu ID de interface. Então, lá se vai um benefício do IPv6.

Em segundo lugar, acontece que alguns ISPs alternam seus prefixos IPv6 com frequência, diariamente, para evitar que você hospede um blog ou o que quer que eu acho, Deus me livre. Como não há sub-rede local, isso significa que toda a configuração da sua rede muda sempre que o seu ISP decide que é hora de refazer a configuração. É como se o ISP visitasse sua casa, editasse seu 192.168.1.0/24 para 192.168.123.0/24 um dia, e tudo, toda conectividade interna da sua casa quebra por causa disso.

Isso significa que o uso de endereços roteáveis ​​globalmente na configuração da sua rede privada pode não ser sustentável. Você terá que recorrer a endereços privados, como endereços locais de link ou endereços locais exclusivos (ULAs, uma maneira elegante de dizer “endereços locais roteáveis”) em sua rede IPv6. Lá se vai outro benefício do IPv6.

Se você decidir usar endereços locais de link com fe80 prefixo, seu problema de roteamento que você teve em primeiro lugar volta para assombrá-lo exatamente como o fantasma amaldiçoado do IPv4 previu.

Considerações finais

Endereços roteáveis ​​globalmente para cada dispositivo IPv6 são ótimos, mas o design não fornece configurações de endereço persistentes entre provedores de serviços ou prefixos. Portanto, você simplesmente não deve configurar sua rede interna com base em seus endereços IPv6 globais. Idealmente, você deve ter uma estrutura baseada em ULA com um prefixo exclusivo se planejar se conectar remotamente à sua rede, porque os endereços locais de link terão o mesmo problema de sub-rede sobreposta que você teve com o IPv4.

Talvez a ARIN pudesse flexibilizar seus critérios para compras de prefixos de endereço IPv6 e tornar mais acessível a obtenção de um prefixo de endereço IPv6. /48 ou mais sob um determinado prefixo. Dessa forma, poderíamos ter nosso próprio bloco IPv6, que nunca muda, que podemos transferir para o próximo ISP ou para sua próxima rotação IPv6.

Independentemente da solução usada, já que não é mais possível memorizar endereços IP, você deve confiar nos nomes de host dos seus dispositivos e usar generosamente o mDNS. Na verdade, se você puder pagar por um servidor DNS real, adicione um controlador de domínio à mistura e talvez nem precise de uma VPN, como o IPv6 prometeu uma vez.

Fiquei animado ao descobrir que o IPv6 poderia finalmente ter uma grande vantagem sobre o IPv4 devido à forma como ele lidava com sub-redes locais, mas fiquei um pouco desapontado depois de saber que ele não poderia lidar com isso tão bem quanto eu desejava. Mas pelo menos nos oferece mais opções do que “apenas reconfigurar sua rede, mano”.