Resumo

  • O Internet-Draft ativo do INTAREA, de Remco van Mook, propõe 192.0.0.11/32 como gateway sentinela. Um host compatível não envia ARP; usa o MAC do roteador padrão IPv6 selecionado.
  • O pacote continua sendo IPv4 nativo, sem túnel ou tradução. Para voltar, porém, a rede precisa anunciar o /32 IPv4 do host por um próximo salto IPv6 GUA ou ULA roteável.
  • A economia combina planos de controle antes separados. DHCP, RA, NUD, encaminhamento IPv4, rota de retorno e suporte aos legados precisam de recibos próprios.

Um valor de controle dentro da tabela

192.0.0.11 parece o endereço de uma interface, mas não exerce essa função. O host não deve consultá-lo por ARP, testá-lo como equipamento nem redistribuí-lo como rota real. Ao encontrá-lo como gateway padrão, a pilha consulta a lista de roteadores IPv6 da mesma interface e obtém do Neighbor Cache o MAC do escolhido.

A aplicação ainda abre um socket IPv4. O datagrama permanece IPv4 na rede. Não há NAT64 nem cabeçalho de encapsulamento. A proposta altera somente a pergunta de camada 2 no primeiro salto. Em vez de descobrir outra adjacência, reaproveita uma já mantida por IPv6.

O texto tornou-se documento do grupo de trabalho INTAREA em agosto de 2026. Ele relata verificação sem mudanças de aplicação ou DHCPv4 em Windows 11, macOS, Android, iOS, Linux, FreeBSD e ChromeOS. A formulação importa: é um resultado informado pelo draft, não uma certificação independente. O documento ainda pode mudar, e o sentinela não deve ser descrito como padrão universal implantado.

A dependência começa antes do primeiro pacote

Receber o lease comprova apenas que o parâmetro chegou. Sem Router Advertisement não existe roteador IPv6 do qual emprestar um vizinho. Antes da primeira RA, a espera deve ser limitada. Depois, o RFC 4191 ordena os candidatos por preference; a alcançabilidade e regras da implementação resolvem o restante.

O Neighbor Cache também não é uma verdade eterna. Os estados reachable, stale, delay e probe do RFC 4861 permitem uso em condições diferentes. Um MAC armazenado pode apontar para um roteador que deixou de encaminhar IPv4. Um roteador saudável também fica inacessível se o estado RA ou ND desaparece. São testes independentes.

Na ida, um endereço IPv6 link-local do roteador pode bastar. Na volta, ele não identifica um próximo salto entre roteadores. O operador precisa anunciar o IPv4 /32 do host com um próximo salto IPv6 GUA ou ULA alcançável. O RFC 8950 define a NLRI IPv4 com next hop IPv6 em BGP; o draft v4-via-v6 complementa o encaminhamento no núcleo.

Um ping que sai não encerra a prova. O conjunto inclui o lease aceito, a RA correta, o MAC aprendido, o encaminhamento IPv4 no equipamento escolhido e a rota /32 que traz a resposta.

Por que a máscara não pode ser maior

Se o host receber um prefixo IPv4 mais amplo, passará a considerar outros endereços on-link e voltará a fazer ARP. O /32 protege a ausência de sub-rede. Pelo mesmo motivo, o sentinela nunca deve aparecer como origem ou destino de tráfego encaminhado.

O draft cita Hetzner, OVH e Scaleway como exemplos de redes de hospedagem que usam endereços individuais e gateway off-link, hoje com ajustes específicos de sistema operacional. Isso demonstra uma demanda antiga, não que essas empresas já tenham adotado 192.0.0.11. A afirmação pertence ao draft.

O RFC 8925 cobre outra escolha: clientes capazes podem preferir uma operação IPv6-only. O sentinela mantém IPv4 nativo para dispositivos dual-stack em um acesso orientado a IPv6. Os dois recursos podem coexistir, mas a presença de um não valida o outro.

O fallback cria uma segunda população

Um sistema antigo enviará ARP para o sentinela. A recomendação é que o roteador responda com o próprio MAC. Isso permite que máquinas atualizadas e antigas compartilhem o enlace, mas cria dois serviços distintos.

O sucesso do legado comprova a resposta ARP, não a seleção via IPv6. O sucesso do host atualizado não garante o fallback. Métricas agregadas podem esconder metade da falha. É preciso separar sondas e contadores.

Na reunião IETF 126, Lorenzo Colitti perguntou sobre acompanhar mudanças de roteamento IPv6 e alertou que uma implementação ruim poderia derrubar IPv4. Van Mook confirmou a obrigação de acompanhar. Tobias Fiebig considerou a ideia elegante em comparação com DHCPv4-over-DHCPv6. A elegância retira mensagens do fio, mas não retira estados do contrato operacional.

Código executável, maturidade delimitada

O repositório v4-with-v6-nh contém um daemon Linux que detecta o sentinela, usa os dados do RFC 4191, instala uma rota IPv4 por um próximo salto IPv6, acompanha trocas e remove a rota quando a condição some. O Linux representa esse tipo de rota desde o kernel 5.2.

As ressalvas evitam confundir protótipo com produto. O daemon não consegue enfileirar cada pacote até a primeira RA; a integração systemd-networkd é um patch; a sintaxe do FreeBSD foi validada, mas não testada; configurações comerciais não passaram por hardware real; não existe release etiquetado.

Os melhores testes provocam transições: vencimento do DHCP, atraso da RA, retirada do roteador preferido, NUD envelhecido, perda do retorno /32, empate de preferência e mistura entre hosts modernos e antigos.

A superfície de confiança muda de lugar

Eliminar ARP reduz falsificação e ruído nos hosts compatíveis. A confiança passa para RA e ND. Um anúncio incorreto pode escolher o MAC que receberá IPv4; uma falha ND pode interromper as duas famílias ao mesmo tempo.

RA Guard, portas confiáveis, inspeção de vizinhos e preference explícita tornam-se controles de disponibilidade IPv4. A falha mais perigosa é silenciosa: distribuir o sentinela onde só metade do método existe. Validadores DHCP também podem rejeitar o gateway off-link antes disso. “Configuração aceita” e “tráfego encaminhado” não cabem no mesmo indicador.

Fontes