Resumo

  • Um /64 quase vazio em um enlace Ethernet pode obrigar o roteador a criar entradas INCOMPLETE e enviar Neighbor Solicitations para destinos inexistentes; o /127 elimina esse conjunto local de alvos não atribuídos.
  • A solução só vale dentro do perfil do RFC 6164: dois roteadores, nenhum host, operação ponto a ponto, suporte nos dois extremos e anycast Subnet-Router desativado.

Ausência também consome memória

Em uma planilha, endereços não usados parecem gratuitos. No plano de encaminhamento, eles podem virar pedidos de resolução. Se um pacote chega para um endereço on-link sem vizinho, o roteador pode abrir uma entrada INCOMPLETE, emitir uma Neighbor Solicitation, iniciar temporizadores e aguardar uma resposta que nunca virá.

Num /64 atribuído a dois roteadores Ethernet, a área vazia é enorme. O RFC 6164 calcula 2^64 - 3 valores não atribuídos depois de separar os dois extremos e o Subnet-Router anycast. Um atacante não precisa controlar nenhum deles. Basta variar o destino para converter espaço nominal em trabalho real.

Limitar a taxa de solicitações reduz CPU. Limpar o cache preserva parte da capacidade. Mas o documento alerta que, se o enlace cair e as entradas legítimas expirarem durante a pressão, sessões como BGP podem não voltar: os roteadores competem para resolver um ao outro no mesmo mecanismo inundado por fantasmas.

O /127 muda a geometria. Seus dois valores podem pertencer aos dois extremos, sem um campo local de endereços vazios. A economia de prefixos é um benefício, mas não é a razão mais forte. O ganho é parar de expor um universo de destinos on-link que produzem estado sem produzir vizinhos.

O risco antigo não era imaginário

O RFC 3627 havia chegado à conclusão oposta em 2003. A arquitetura IPv6 definia o identificador de interface todo zero como endereço anycast Subnet-Router. Num /127, esse valor também é uma das duas opções de unicast.

Seu exemplo dá o endereço terminado em um ao primeiro roteador. Esse equipamento também pode reivindicar o valor zero como anycast. Quando o segundo roteador tenta usar zero como unicast, Duplicate Address Detection pode encontrar a reivindicação e impedir a configuração. Uma função coletiva ocupou a identidade que o desenho reservava ao par.

O texto admite que o anycast tinha utilidade duvidosa entre apenas dois roteadores. Admite ainda que o problema talvez não aparecesse muito porque a função não era amplamente implementada. Mas a diversidade de implementação impede que o operador confie no silêncio. Uma troca de plataforma pode ativar a semântica que o equipamento anterior ignorava.

Por isso o conselho antigo preferia /64 e, onde isso fosse impraticável, alternativas como /126. O diagnóstico era coerente com a especificação e com a incerteza daquele momento. O próprio RFC 6164 depois o chama de correto.

A regra nova retirou a causa antiga

Em 2011, o RFC 6164 não declarou /127 seguro por definição. Ele criou um domínio: enlace inter-roteadores com exatamente dois roteadores e nenhum host, configurado para uso ponto a ponto. Ethernet pode entrar, desde que opere assim. Enlace entre roteador e host, rede mista e escopo link-local ficam de fora.

Dentro desse domínio, os roteadores devem suportar a atribuição de /127 e devem desativar Subnet-Router anycast para o prefixo. A segunda obrigação remove a colisão. O valor zero deixa de ser simultaneamente a identidade do par e uma chamada coletiva.

A disciplina continua no /64 do qual os enlaces são retirados. Valores com os 64 bits inferiores em zero não devem ser escolhidos como unicast. Os 128 valores superiores, reservados pelo RFC 2526 para outros anycasts de sub-rede, também devem ser evitados. A exceção é local, não uma anistia para todo o plano de endereçamento.

Essa estrutura explica por que o prefixo sozinho não é recibo. Ele não mostra quantos participantes o serviço Ethernet aceita, se um túnel é compartilhável, se um host apareceu nem se os dois equipamentos desligaram a semântica anycast. A máscara é parte do contrato, não sua testemunha.

O pacote que volta

Há ainda o problema do ping-pong. Em alguns meios ponto a ponto sem Neighbor Discovery, um prefixo menor que /127 cobre destinos não usados. Um pacote para um desses destinos pode ser enviado ao outro extremo, que o devolve pela mesma rota, criando um ciclo.

O RFC 4443 exige que um roteador não reencaminhe para o mesmo enlace ponto a ponto um pacote recebido ali e destinado a outro valor do prefixo local. Em vez disso, deve considerar uma mensagem ICMPv6 de destino inalcançável. O RFC 6164 observa que essa verificação está no caminho de encaminhamento e pode ter custo. O /127 remove o endereço excedente, oferecendo defesa estrutural inclusive contra comportamento antigo.

O ordenamento de riscos mudou. Primeiro, o anycast obrigatório parecia tornar /127 perigoso. Depois, a experiência mostrou que era possível desativá-lo num perfil específico e que o espaço não usado de prefixos maiores tinha impacto operacional e de segurança. Running code não votou contra um papel; revelou qual combinação de regras falhava menos.

O status Historic preserva a explicação

Em 2012, o RFC 6547 moveu o RFC 3627 para Historic. Também explicou que o RFC 6164, Standards Track, deve orientar o leitor onde houver conflito. A relação evita que uma busca encontre a advertência antiga sem perceber a mudança.

Historic não significa fraude retroativa. O caso de DAD continua válido sob as premissas antigas. A observação sobre implementações continua útil. O erratum verificado, que corrige o nome de uma referência de ICMPv3 para ICMPv6, continua fazendo parte da qualidade do registro.

O arquivo oferece causalidade: por que o segundo MUST do RFC 6164 existe, quais alternativas foram consideradas e que incerteza cercava a implantação. O status oferece direção presente. Misturar essas funções produziria dois erros: apagar evidência quando uma regra muda ou manter uma regra apenas porque o número antigo ainda é citável.

Do plano ao enlace observado

Uma adoção responsável precisa demonstrar o conjunto inteiro. Há somente dois roteadores? O meio impede ou apenas desencoraja um terceiro participante? Ambos os extremos suportam /127 e desligam anycast? O pool pai evita valores reservados? Neighbor Discovery, ICMPv6 e BGP se recuperam após falha e pressão?

Cada resposta vem de uma fonte diferente. O contrato do serviço descreve o alcance prometido. A observação de camada dois mostra participantes atuais. A matriz de versão mostra capacidade. O teste de falha mostra comportamento. Um pacote de teste mostra apenas aquele resultado.

Nem mesmo uma sessão BGP estável transforma o estado atual em garantia. Troca de equipamento, atualização de software ou conversão do serviço podem manter os mesmos endereços e perder a premissa de dois participantes. A validação precisa acompanhar mudanças que não geram renumeração.

A reversão que vale conservar

O mérito institucional desse episódio está no recorte. A IETF não trocou um mandamento universal por outro. O RFC 6164 descreveu um conjunto menor, ligou a permissão à supressão de anycast, colocou ataques concretos na balança e deixou regras de reserva ao redor. O RFC 6547 então atualizou o caminho de autoridade.

Isso permite revisão sem amnésia. O RFC 3627 continua explicando a colisão. O RFC 6164 governa o perfil posterior. O enlace em execução decide, por evidência local, se pertence a esse perfil.

O espaço vazio só deixou de trabalhar para o atacante quando a topologia e as implementações aceitaram juntas uma regra mais estreita.

Fontes