Usando a internet sem conexão IPv4

• Após uma queda de energia, apenas a conexão IPv4 do lado do ISP caiu, enquanto o IPv6 continuou funcionando; para restaurar o acesso a sites apenas IPv4, foi usado um VPS da Hetzner com IPv4/IPv6 e um túnel WireGuard
• A falha parecia estar na camada de CG-NAT, onde os pacotes IPv4 não estavam sendo convertidos corretamente e acabavam descartados; serviços com suporte a IPv6, como Google e Meta, continuaram acessíveis
• Ao colocar um servidor WireGuard no VPS e configurar o cliente para usar o endereço IPv6 do VPS como endpoint, foi possível enviar o tráfego IPv4 pelo VPS e recuperar a navegação web normal
• A VPN de trabalho e o Docker exigiram tratamento separado, então foram executados dentro de um namespace de rede baseado em vopono, além de um contorno com unshare e bind mount de /sys
• O sintoma de apenas alguns sites carregarem era causado por um MTU do WireGuard grande demais, e o problema foi resolvido imediatamente ao reduzi-lo para 1280, o MTU mínimo do IPv6

---

Falha em que só o IPv4 caiu após uma queda de energia

• Depois de uma queda de energia, o disjuntor foi religado, mas GitHub e vários sites não abriam, enquanto Google e Meta funcionavam normalmente
• Verificando ping -6 e traceroute na máquina local e na página de diagnóstico do roteador, ficou claro que o problema afetava apenas a conexão com servidores IPv4
• O ISP informou que talvez fosse necessária a visita de um técnico e que isso poderia levar vários dias após o fim de semana; como havia necessidade de acesso para o trabalho e para escrever um artigo, não dava para esperar
• Já existia um VPS da Hetzner com endereços IPv4 estático e IPv6, e como o site da Hetzner suporta IPv6, foi possível acessar o console e fazer a configuração

A dependência de IPv4 criada por NAT e CG-NAT

• Endereços IPv4 têm 32 bits e, excluindo blocos reservados, existem apenas cerca de 3,7 bilhões de endereços IPv4 públicos, o que impede atribuir um endereço direto a todos os dispositivos conectados à internet
• NAT permite que vários dispositivos compartilhem um único IP público
  • O roteador doméstico converte IPs locais, como 192.168.1.xxx, para o seu IPv4 público
  • O conntrack do Linux armazena um mapeamento entre o IP e a porta de origem originais e a porta convertida
  • Quando um pacote de resposta chega àquela porta, o conntrack restaura o destino para o IP e a porta internos originais
  • No Linux, é possível ver os mapeamentos salvos com conntrack -L do conntrack-tools
• O NAT também funciona como um firewall implícito, então serviços em dispositivos locais atrás do roteador são difíceis de acessar externamente sem port forwarding explícito
• Por causa da escassez de IPv4, o ISP também pode aplicar NAT internamente; isso é chamado de Carrier Grade NAT (CG-NAT)
  • Assim como o roteador doméstico faz NAT para vários dispositivos locais, o roteador do ISP faz NAT para vários roteadores domésticos
  • Dependendo da quantidade de endereços IPv4 do ISP e de sua política de alocação, isso pode se repetir em várias camadas, inclusive por região
• Nesta falha, tudo indicava que os pacotes IPv4 estavam sendo descartados porque em algum ponto da camada de CG-NAT eles não estavam sendo NATeados corretamente, interrompendo totalmente o tráfego IPv4
• Para formas de contornar NAT traversal, vale consultar How NAT Traversal Works, da Tailscale

Por que o IPv6 continuou funcionando

• Endereços IPv6 têm 128 bits e, mesmo considerando blocos reservados, oferecem cerca de 3.4E38 endereços
• É comum que roteadores domésticos recebam uma sub-rede /64, o que significa 1.84E19 endereços
• No IPv6, não é necessário usar NAT no roteador doméstico para que cada dispositivo tenha um endereço direto na internet
  • Isso reduz problemas de port forwarding
  • Em compensação, o roteador ou cada dispositivo precisa de regras de firewall adequadas para bloquear novas conexões externas arbitrárias
• Como o CG-NAT não era aplicado ao IPv6, essa falha não o afetou
• Ainda assim, há servidores web, como o GitHub, que continuam sem acesso por IPv6, então apenas a conectividade IPv6 não bastava para usar toda a internet diretamente

Criando um túnel IPv4 sobre IPv6 com WireGuard

• A solução foi instalar WireGuard no VPS e configurar um túnel no qual o cliente usa o endereço IPv6 do VPS como endpoint
• Depois que o túnel é estabelecido, o tráfego IPv4 passa pelo VPS e volta a funcionar normalmente
  • A latência aumenta por causa do roteamento via VPS
  • Na prática, o funcionamento se aproxima de um Dual-Stack Lite montado manualmente
• O servidor era um VPS da Hetzner com Arch Linux instalado anteriormente via vps2arch, usado sobre a imagem Debian mais recente da Hetzner
• A configuração do WireGuard foi baseada no exemplo caso específico de servidor VPN com WireGuard da ArchWiki, com adição de tráfego IPv6
• A configuração do servidor incluía
  • Address = 10.200.200.1/24, fd42:42:42::1/64, 2001:db8:abcd:1234::1/128
  • Encaminhamento de IPv4 com MASQUERADE do iptables
  • NAT de IPv6 ULA com SNAT --to-source do ip6tables
  • Ativação de forwarding IPv4/IPv6
  • Peers divididos em exemplos como foo, que usa diretamente IPv6 Global Unicast Address, e bar, que usa IPv6 ULA com NAT
• Diferentemente de arquivos de configuração em estilo .ini, o wg-quick permite declarar PostUp e PostDown várias vezes e executa cada comando em sequência
  • A implementação relacionada está em wg-quick linux.bash

NAT em IPv6, SNAT e configuração do cliente

• No IPv6, NAT não é estritamente necessário e, se o VPS tiver um bloco IPv6 /64, como na Hetzner, é possível atribuir diretamente um Global Unicast Address (GUA) a cada peer
• Para usar endereços diretos, basta trocar os Unique Local Address (ULA) do peer e da interface por endereços IPv6 públicos e remover a regra ip6tables MASQUERADE
  • Assim, cada peer pode ser endereçado diretamente pela internet com o IPv6 atribuído
  • Esse modelo é adequado quando se quer encaminhar serviços próprios de vários dispositivos
  • O firewall do VPS precisa tratar corretamente o tráfego de entrada
• Se houver certeza de que o IP do VPS é estático e não mudará, é possível usar SNAT em vez de MASQUERADE
  • MASQUERADE consulta o IP da interface em tempo de execução
  • SNAT define o endereço diretamente e é ligeiramente mais eficiente
• Na configuração do cliente, o endereço IPv6 do servidor deve ficar entre colchetes, como em Endpoint = [2001:db8:abcd:1234::1]:51820
• Com AllowedIPs = 0.0.0.0/0, ::/0, todo o tráfego IPv4/IPv6 passa pelo túnel
• Após ativar os dois lados, a navegação normal foi restaurada e também foi possível acessar o servidor diretamente por SSH usando os endereços IPv4 e IPv6 locais do túnel
• Também foi fácil instalar o cliente WireGuard na máquina Linux da esposa

Isolando a VPN de trabalho com namespaces de rede

• Tentar conectar a VPN de trabalho diretamente sobre a conexão WireGuard causava conflitos e não funcionava
• Foi usado o vopono para executar a VPN de trabalho e os aplicativos necessários dentro de um namespace de rede
• O ponto principal era fazer a regra de MASQUERADE encaminhar o tráfego não para a interface de rede física, mas para a interface WireGuard em uso (foo ou bar)
• O tráfego dentro do namespace não precisa lidar diretamente com as regras nftables do WireGuard no host, mas na prática continua sendo roteado pelo túnel WireGuard
• O wg-quick prefere nftables quando disponível, em vez de iptables, mas ainda evita conflito com as regras iptables padrão do Docker
• Exemplo de execução com o vopono

$ vopono -v exec --create-netns-only --provider None --protocol None -i bar bash
$ sudo ip netns exec vo_none_none bash
$ (inside netns) ./vpn.sh

• /etc/netns/vo_none_none/ é montado como /etc por ip netns exec, então é possível manter ali um resolv.conf específico desse namespace
• Se quiser priorizar resolução DNS IPv4, também é possível ajustar gai.conf da mesma forma
  • Essa configuração foi usada durante a depuração de problemas de tráfego IPv6 no túnel
  • O exemplo foi baseado em uma resposta no AskUbuntu
• Depois de conectar a VPN de trabalho, ao colocar o servidor DNS interno em /etc/netns/vo_none_none/resolv.conf, os aplicativos executados nesse namespace passaram a funcionar normalmente
• Também é possível iniciar aplicativos como Chrome dentro do namespace com privilégios de usuário comum

$ vopono -v exec -i bar --provider None --protocol None google-chrome-stable

Executando o Docker no mesmo namespace

• O Docker não funciona simplesmente se for executado dentro de um namespace de rede como um aplicativo qualquer
  • Isso acontece porque o socket do Docker ativado por systemd foi criado fora do namespace
  • A conectividade interna não fica disponível
• Mesmo parando o Docker externo e tentando recriar dockerd e o socket dentro do namespace, o problema não se resolve imediatamente
  • ip netns exec cria um mount namespace e remonta /sys
  • Por isso, /sys/fs/cgroup do host deixa de ficar visível
• Nesse caso, pode aparecer o seguinte erro

Error: OCI runtime error: runc: runc create failed: no cgroup mount found in mountinfo

• O contorno consiste em usar unshare para transformar /sys em um bind mount e desmontar a montagem interna de /sys criada por ip netns exec
  • O método foi baseado em um post no Unix StackExchange
  • Depois disso, o /sys dentro do mount namespace passa a ser um bind mount do /sys do host
• Exemplo de comandos

$ sudo systemctl stop docker && sudo systemctl stop docker.socket
$ sudo -E unshare -m sh -c 'mount --bind /sys /sys; exec ip netns exec vo_none_none sudo --user youruser --preserve-env bash'
$ sudo umount /sys
$ sudo dockerd --host=unix:///var/run/docker-netns.sock --data-root=/var/lib/docker-netns
$ DOCKER_OPTS="--dns=YOURDNSHERE" DOCKER_HOST=unix:///var/run/docker-netns.sock sudo --user youruser --preserve-env docker ...

• Ao executar dockerd e os comandos do Docker na mesma sessão, eles compartilham o mesmo namespace de rede e o mesmo mount namespace
• A configuração de DNS do Docker também pode ficar em /etc/netns/vo_none_none/docker/daemon.json
• Isso foi suficiente para trabalhos que exigiam contêineres auxiliares e contêineres conectados por rede Docker, mas configurações mais complexas com bridge e afins podem não funcionar da mesma forma

Depuração do problema de MTU no WireGuard

• Depois de reiniciar, a conexão WireGuard parecia continuar ativa, mas apenas algumas páginas carregavam e sites como GitHub não abriam
• ping, ping -6 e wg show pareciam normais, o que dificultou encontrar a causa
• Testes com pings de tamanhos diferentes mostraram que pacotes grandes falhavam

$ ping6 -s 1400 fd42:42:42::1
$ ping6 -s 1200 fd42:42:42::1
$ ping6 -s 800 fd42:42:42::1

• O tamanho 1400 falhava, enquanto 1200 e 800 funcionavam, confirmando que a causa era a configuração de MTU
• Ao reduzir o MTU da interface WireGuard local, a pilha IP do kernel deixa de criar pacotes maiores do que esse valor
  • Assim, o pacote UDP final, com o overhead extra da encapsulação do WireGuard, também não é descartado em enlaces do caminho com MTU menor
• Cada roteador no caminho tem seu próprio MTU, e pacotes maiores do que o menor MTU podem ser descartados
• O tráfego do túnel recebe cerca de 32 bytes de overhead da encapsulação do WireGuard, o que pode agravar o problema de MTU
• Mensagens de Path MTU Discovery podem ser enviadas por ICMP por roteadores intermediários, mas como muitos firewalls descartam ICMP, o ajuste automático pode falhar
• Como a especificação do IPv6 define 1280 como MTU mínimo, esse valor sempre deve funcionar em túneis WireGuard sobre IPv6

Opções operacionais que restaram após a recuperação

• O resultado da configuração incluiu
  • Um servidor VPN WireGuard em um VPS com IPv4 e IPv6
  • Suporte tanto a tráfego IPv6 direto quanto a tráfego IPv6 com NAT
  • Execução da VPN de trabalho dentro de um namespace de rede
  • Execução do Docker no mesmo namespace de rede usando o contorno com unshare
  • Depuração do problema de MTU no WireGuard
• Em trabalho remoto, problemas de conectividade com a internet são sempre um risco e, neste caso, as ferramentas do Linux permitiram contornar a situação sem esperar a restauração da configuração do ISP
• A Hetzner permite túneis WireGuard e uso geral legítimo, mas não permite port scanning, traffic spoofing ou mineração de criptomoedas
• VPNs como AirVPN, ProtonVPN e AzireVPN, que oferecem port forwarding, também podem ser uma alternativa para encaminhar portas de um home server sem depender do ISP
• Com um roteador OpenWRT, seria possível fazer mais depuração do lado do roteador e também configurar esse tipo de contorno diretamente no roteador com WireGuard, sem precisar ajustar cada dispositivo separadamente

[GN⁺]

Opiniões no Hacker News

• O título é um pouco enganoso. Mais precisamente, trata-se de acessar a internet IPv4 por meio de um túnel IPv6 via VPS, algo que normalmente também é chamado de 4in6.
  Ainda assim, é interessante. Do ponto de vista do ISP, a natureza dos chamados de suporte é bem diferente quando o IPv4 quebra e quando o IPv6 quebra. Uma falha de IPv4 geralmente é um estado claro de “fora do ar”, então os usuários ficam bastante insatisfeitos, mas é simples. Já falhas de IPv6 aparecem de formas estranhas, como falhas parciais, início lento por causa de fallback, ou situações em que o gateway acredita que há IPv6

  • Da última vez que o IPv4 caiu, percebi principalmente porque o Github não funcionava. Hoje em dia, a maioria dos sites voltados a consumidores funciona só com IPv6.
    Porém, pessoas que tinham apenas servidores DNS IPv4 configurados no roteador sofreram uma queda total. Se a Microsoft tivesse limpado alguns ativos incompetentes, acho que a maior preocupação teria sido lembrar o hostname mDNS atribuído ao roteador para fazer login e verificar se o IPv4 tinha voltado
  • A cauda longa do IPv4 certamente existe, mas, da última vez que o IPv4 caiu em casa, minha esposa nem percebeu. Isso porque Google, Facebook, Apple/iCloud e a maior parte da hospedagem na CloudFlare continuaram funcionando via IPv6
  • Minha experiência é a mesma. Problemas de IPv6 são frustrantemente difíceis de classificar e reproduzir, e há muitas situações do tipo “na minha máquina funciona”
  • A maioria dos ISPs ainda simplesmente bloqueia IPv6 por completo. Como pequenos operadores muitas vezes tentam IPv6 uma vez e depois esquecem coisas como atualizar registros AAAA, para o usuário parece que aquele serviço de nicho favorito funciona em outras redes, mas não no ISP pelo qual ele paga.
    É um problema estranho, e não sei se há uma boa solução além de torcer para que o IPv4 desapareça algum dia. O Happy Eyeballs deveria resolver isso, mas o problema muitas vezes aparece bem acima da camada de aplicação, e como aplicações podem fazer qualquer coisa, é difícil resolver com um protocolo genérico sem abstrações vazando. Pessoalmente, estou usando um meio-termo: mantenho IPv6 ativado na rede e desativo DNS IPv6 em todos os navegadores, mas é uma solução bem insatisfatória

• Se você quer experimentar IPv6, mas seu ISP não oferece, a Hurricane Electric fornece serviço de túnel há anos.
  https://tunnelbroker.net
  https://ipv6.he.net
  Também há scripts para subir um dispositivo tun no sistema ou no roteador e rotear o tráfego: https://fedoraproject.org/wiki/IPv6_tunnel_via_Hurricane_Ele..., https://brandonrozek.com/blog/obtaining-ipv6-address-hurrica..., https://wiki.dd-wrt.com/wiki/index.php/IPv6_setup_Hurricane_..., https://forum.mikrotik.com/t/auto-update-script-for-hurrican..., https://docs.rockylinux.org/guides/network/hurricane_electri...

  • Uma ressalva irritante desses túneis é que serviços de streaming os bloqueiam como se fossem VPNs usadas para contornar restrições regionais, então, se precisar, você terá que descobrir como desligar o túnel.
    Ainda assim, funciona bem. Mesmo que o roteador não ofereça suporte a túneis HE, com o poder do RA dá para atribuir endereços IPv6 a todos os dispositivos da rede. Qualquer dispositivo que anuncie um /64 vira um roteador IPv6. Claro, isso pressupõe que o roteador não filtre RA por motivos de segurança. É muito útil para hospedar serviços dentro da rede doméstica sem mexer em regras de port forwarding
  • A Hurricane Electric é excelente, mas, à medida que mais pessoas passam a usar o IPv6 fornecido pelo ISP, usuários “comuns” deixam os túneis, e serviços de rede começaram a marcar túneis he.net como abuso.
    Sites demais colocam barreiras ou simplesmente se recusam a funcionar, então tive que parar de usar IPv6 na maior parte da minha rede
  • Um ponto a saber é que, até onde sei, túneis HE só funcionam quando o ISP atribui a você um IPv4 público. Se você estiver atrás de CGNAT, infelizmente vai precisar de outra solução para levar IPv6 para casa
  • Sou um “cliente” satisfeito. Uso há cerca de 5 anos um túnel 6in4 gratuito com OpenBSD e não tive problemas dignos de nota.
    Configurei apenas com arquivos de interface de rede do OpenBSD, como /etc/hostname.gif0: tunnel, inet6 128 alias, !route -n add -inet6 default. Uso essa conexão para acessar um cluster de VPS na AWS configurado intencionalmente sem endereços IPv4 públicos. Por causa de gente como Jeff Bezos monetizando agressivamente o espaço de endereços IPv4, isso teria virado uma parte grande do custo mensal

• Se você precisa rapidamente de conectividade IPv4 em um ambiente realmente só com IPv6, pode usar um gateway DNS64+NAT64 público. A lista está em https://nat64.net/public-providers
  Para uso comum, basta trocar o servidor DNS. O DNS64 sintetiza registros DNS AAAA apontando para a caixa NAT64 para destinos que não têm registro AAAA: $ dig +short @2a00:1098:2c::1 AAAA github.com → 2a01:4f8:c2c:123f:64:5:141a:9cd7. Por causa do DNS64, o NAT64 faz a tradução de protocolo e o NAT do tráfego que chega até ele: $ curl --resolve github.com:443:[2a01:4f8:c2c:123f:64:5:141a:9cd7] [https://github.com/](<https://github.com/>;)

  • Vim aqui para dizer isso. Na Europa, pelo menos o próprio https://nat64.net/ é bem decente. Só tive boas experiências
  • Usar Cloudflare WARP deve ser muito mais rápido. Pelo WARP também é possível se conectar diretamente a endereços IPv4

• Então esse mítico usuário de internet somente IPv6 existe mesmo :) Excelente engenharia de rede
  No passado, precisei de algo parecido para o objetivo oposto, que era mais comum: fazer coisas relacionadas a IPv6 em uma conexão somente IPv4. Se você tem controle total de um servidor, uma solução mais limitada, mas rápida, é criar um proxy SOCKS5 com ssh -D 1080 -N myserver e configurá-lo no navegador. Imagino que também dê para configurar no sistema inteiro, mas fico me perguntando se isso não quebraria a conexão ssh original e derrubaria tudo

• Estou na mesma situação. Há duas semanas só ouço que “o chamado está aberto e um técnico vai verificar em breve”, então está sendo bem frustrante
  Talvez a prioridade seja baixa porque o IPv6 funciona, então eles não consideram uma falha total. Na Alemanha há uma lei que garante compensação ao consumidor nesses casos, e em breve vou verificar se isso também se aplica aqui. A solução deste post tem o problema de vários endpoints bloquearem faixas inteiras de IPs de data centers ou exigirem vários CAPTCHAs, e o mesmo acontece com provedores comuns de VPN. Como eu queria consertar a rede da casa inteira, precisei resolver isso no roteador, e ter um dispositivo não padrão como um Ubiquiti EdgeRouter ajudou a configurar o roteamento do Wireguard e as regras de NAT. Não sei como eu teria feito em equipamentos como uma FritzBox. A desvantagem é que o desempenho do roteador não dá conta de muitas conexões, então vou ter que mudar para IPSec com suporte a offloading por hardware

  • Na verdade, a FritzBox também tem uma GUI para configurar conexões VPN bem razoável. É um recurso pensado para conexões entre FritzBoxes, mas qualquer VPN compatível serve. Também dá para configurar rotas IPv4/IPv6 estáticas
    O maior problema provavelmente é descobrir qual configuração de criptografia IPsec o outro lado espera. Wireguard pode ser muito mais fácil, mas aí pode surgir o problema da aceleração por hardware. Se necessário, também é possível fazer backup do arquivo de configuração da FritzBox, editar o dump para configurar manualmente o endpoint VPN, recalcular o checksum e importar de volta. A AVM tem muitas configurações inacessíveis ao usuário que podem ser ajustadas assim, mas eles dificultam um pouco o acesso para evitar que alguém transforme o roteador em um tijolo por engano
  • Não sei como é na Alemanha, mas nos Países Baixos, se você usa internet fixa e móvel no mesmo ISP e a conexão fixa falha, pode pedir dados móveis gratuitos até o problema ser corrigido
    Pode ser uma opção que vale perguntar ao ISP

• Uma coisa de que gosto nas regras da App Store da Apple é a exigência de que todos os apps funcionem em redes somente IPv6. É uma regra que existe há anos
  Como desenvolvedor, é um pouco surpreendente quando você encontra isso pela primeira vez, mas, como usuário, fico feliz que exista

  • Se você usa o app, o Github também fica acessível por IPv6?
  • Mas isso não quer dizer que o servidor precise ter um endereço IPv6

• Se eu passasse pela mesma coisa, daria para criar um proxy ssh muito facilmente com ssh -D 8080 user@hostname
  Depois que a conexão for criada, basta configurar o navegador para usar localhost:8080 como proxy SOCKS

  • Eu estava prestes a dar o mesmo conselho. Para um problema temporário, é uma solução muito mais simples, e também pode servir como ferramenta permanente quando você precisar de um proxy
    Para usar esse recurso, AllowTcpForwarding precisa estar habilitado no sshd_config
  • Sempre faço isso quando uso Wi-Fi público. Sem pagar por VPN nem precisar confiar em uma VPN, encaminho tudo via SOCKS para o meu servidor da infomaniak

• Há pontos em que desligar o IPv4 emperra: a maioria dos mecanismos de busca alternativos parece não oferecer conectividade IPv6, e o Github, na última vez que conferi, não tinha IPv6 nenhum
  Não se deve esperar algo bom só por ser Microsoft; na verdade, é melhor esperar o pior. Recentemente, eles também quebraram o noscript/basic (x)html nas issues. Nem sei se ainda dá para criar uma conta usando um navegador noscript/basic (x)html, e-mail auto-hospedado e literais de IP(v6) como mailbox@[ipv6:...]. Steam e jogos também não verifiquei recentemente, mas muitos CDNs/servidores de jogos, ou uma parte considerável deles, provavelmente ainda são apenas IPv4. Muitos servidores de e-mail também bloqueiam servidores de e-mail auto-hospedados e frequentemente usam listas de bloqueio malfeitas e inadequadas criadas por empresas suspeitas da Suíça e de Andorra, como a Spamhaus. Além disso, muitas aplicações de rede não aproveitam as vantagens do IPv6. Por exemplo, aplicações cliente-servidor como a web deveriam usar um endereço IPv6 gerado aleatoriamente por sessão, desde que o ISP não forneça um prefixo pequeno demais. ISPs móveis IPv6 parecem entregar um endereço IPv6/128 arbitrário dentro do prefixo, mas deveriam fornecer um prefixo estável, talvez de uns 96 bits, para que aplicações no dispositivo possam escolher um endereço IPv6 “fixo” para chamadas diretas de voz/vídeo sem resolução centralizada de nomes online. Também é necessário um novo serviço de SO em nível de usuário para coordenar endereços IPv6 entre aplicações de usuário. Mas é preciso tomar cuidado com a complexidade idiota que alguns fornecedores e desenvolvedores vão tentar impor para prender usuários e desenvolvedores de apps

  • No meu mini homelab, o IPv6-only estava funcionando bem, até que alguma coisa passou a precisar do GitHub e quebrou tudo. Então configurei NAT64+NAT64
    Foi realmente lamentável ter que fazer isso só por causa do GitHub. Eu provavelmente precisaria disso algum dia por causa do servidor de e-mail, mas esse foi um motivo péssimo para precisar de NAT64 tão cedo. Vejo isso como uma das várias desvantagens de as pessoas usarem o GitHub como meio de distribuição de software
  • Alguns meses atrás, precisei brigar com a Spamhaus. Por algum motivo, o endereço IPv6 do meu VPS entrou na lista de bloqueio da Spamhaus
    Não faço a menor ideia do porquê. Essa máquina não roda nada capaz de enviar e-mail e, pelo que sei, a Digital Ocean também bloqueia SMTP, então era literalmente impossível essa máquina enviar e-mail. A Spamhaus não ajudou em nada a resolver, e a DO também não
  • Por causa do problema de muitos CDNs/servidores de jogos ainda serem apenas IPv4, criei um proxy DNS. Ele adiciona os registros AAAA corretos para esses domínios
    https://gitlab.com/miyurusankalpa/IPv6-dns-server
  • Posso confirmar que o Steam precisa de IPv4. O mesmo vale para alguns jogos que exigem autenticação para jogar
  • A menos que haja desconto por rodar IPv6-only, como em serviços de VPS, parece que ainda ninguém está considerando seriamente abandonar o IPv4
    Na prática, é bem provável que alguma forma de conectividade IPv4 continue existindo, só que há uma chance cada vez maior de ela acontecer via CGNAT. O Github irrita especialmente. Fizeram testes por algumas semanas e tudo parecia funcionar bem, mas voltaram a ser apenas IPv4. Servidores de e-mail, de qualquer forma, ainda vivem no mundo de 10–20 anos atrás. Até desativar suporte a SSL 3.0 ou TLS 1.0 em servidores de e-mail é difícil sem arriscar problemas de entregabilidade. O suporte e os filtros de spam do Microsoft Outlook parecem nem reconhecer servidores de e-mail capazes de IPv6. Isso apesar de, olhando os cabeçalhos, parecer que internamente eles já usam IPv6 há muito tempo. Eu gostaria que IPv6 fosse mais usado, mas o medo de que possa funcionar um pouco pior para uma pequena parcela de clientes parece congelar qualquer tentativa de realmente usar a tecnologia. O motivo de vermos comportamentos estranhos de IP em operadoras móveis provavelmente tem a ver com a forma como IP funciona em redes móveis. Se você está em uma ligação enquanto anda pela estrada ou sentado em um trem de alta velocidade, o celular faz handover o tempo todo, e o endereço IP precisa ter algum nível de estabilidade. Mesmo ao cruzar uma fronteira e mudar para uma rede estrangeira, toda a pilha precisa manter a conexão sem interrupções. Dentro das redes celulares há sistemas de roteamento especiais, alguns dos quais aproveitam muito bem recursos do IPv6, mas que dificultam fornecer ao celular um endereço unicast global estático “comum”. Eles tentam fazer parecer o mais normal possível, mas não é fácil alcançar esse tipo de estabilidade como em uma internet residencial cabeada

• No trabalho, operamos algumas VPNs IPv6-only para acesso à infraestrutura interna
  Até agora, o maior problema é que clientes Windows e macOS exigem um servidor DNS IPv6. Caso contrário, eles nem tentam resolver v6onlyhost.vpn.example.com. Como o cliente pode ou não estar em uma rede com IPv6, precisamos operar um servidor DNS dentro da VPN e empurrá-lo para o cliente; se, depois que a VPN cai, o app do Wireguard por algum motivo não conseguir restaurar o DNS original, todo tipo de problema pode acontecer

  • Mesmo usando uma rede apenas IPv4 do ISP, o macOS conseguia fazer conexão IPv6-only sem esse servidor DNS
    Já não lembro os detalhes, mas, ao investigar isso alguns anos atrás, o macOS funcionava bem desse jeito se tivesse apenas um endereço IPv6. Bastava colocar um endereço ULA no host. Claro, isso pressupõe que o usuário saiba fazer isso. Dependendo da aplicação de VPN, também dá para incluir um script que adiciona uma ULA ao entrar em uma rede IPv6-only. Porém, se uma ULA falsa ficar sobrando, isso pode causar problemas quando o usuário se mudar para uma rede com IPv6
  • Isso não é um problema do Windows. Também tive problemas parecidos em hotspots aleatórios, embora não em todos. Acredito que seja por causa de hotspots burros que não retornam registros AAAA quando o IPv6 está desativado

• Mesmo depois de tanto tempo, ainda não vejo um motivo convincente para passar dias arrancando os cabelos tentando migrar todas as minhas máquinas e meu homelab para IPv6
  Port forwarding e regras de firewall são mais intuitivos do que passar semanas resolvendo problemas, reconfigurando o firewall e renumerando endereços de rede. O que estou deixando passar?

  • O que você está deixando passar é que não é tão difícil quanto parece. Se você não tiver uma rede doméstica muito complexa, configurar IPv6 leva, no máximo, uma noite
    No caso da minha rede e do meu ISP, a Comcast, basta ativar IPv6 no roteador; ele recebe um prefixo do ISP, anuncia isso localmente, e então é só adicionar uma regra de firewall para o que você quiser tornar acessível a partir de fora
  • Você não está deixando passar nada. Em ambientes corporativos, os benefícios da adoção de IPv6 não superam as desvantagens
    Gerencio cerca de 3.500 dispositivos, 7 prédios, 2 WANs de 10 giga e 1 WAN de 4 giga, usando cerca de 26 endereços IPv4 públicos e NAT. Ainda não há um motivo forte para adotar IPv6. Uma configuração dual-stack só acrescenta tráfego e complexidade desnecessários, sem grande benefício. Ainda hoje é difícil receber um bloco de endereços IPv6 estático; solicitei duas vezes e fui recusado. Além de haver pouco ganho, conseguir um bloco em si ainda é difícil. Os requisitos de qualificação em https://www.arin.net/resources/guide/ipv6/first_request/ também são coisas como ter uma alocação IPv4, planejar multihoming IPv6 imediato, ter 13 sites finais dentro de 1 ano, usar 2.000 endereços IPv6 dentro de 1 ano, ou usar 200 sub-redes /64 dentro de 1 ano
  • Por enquanto, você não está deixando passar muita coisa. Algum dia, grandes empresas como Google e Cloudflare podem se cansar do custo dos endereços IPv4, que só aumenta, e passar a incentivar IPv6. Por exemplo, podem começar a restringir IPv4
    Já há sinais iniciais. A AWS antes cobrava apenas por endereços Elastic IP IPv4 não utilizados, mas agora cobra independentemente de estarem em uso ou não. Sinceramente, basta deixar isso preparado na próxima vez que você fizer upgrade do gateway ou roteador; no momento, você não está perdendo nada. Também é possível usar IPv4 e IPv6 ao mesmo tempo. Mesmo ativando no roteador, dispositivos que só usam IPv4 continuam funcionando normalmente. Um ponto de atenção é que a descoberta automática de IPv6 já foi bem bagunçada. Havia SLAAC, autoconfiguração de endereços IPv6 e DHCPv6, e originalmente a autoconfiguração nem sequer suportava receber servidores DNS. Agora isso está se consolidando em torno de SLAAC, mas os ISPs ainda vão usar DHCPv6 por muito tempo