Resumo

  • A RFC 9805 permite que os protocolos da lista legada exaustiva continuem usando IPv6 Router Alert, mas determina que futuros protocolos novos não adotem a opção ao serem padronizados.
  • A IANA fechou o cadastro de valores. Essa medida impede novas alocações; não altera equipamentos, não filtra pacotes existentes e não comprova que o plano de controle está protegido.

Uma decisão de arquitetura pode valer apenas para quem ainda não chegou. É exatamente esse o alcance da RFC 9805, publicada na trilha de padrões do IETF em junho de 2025.

O texto separa futuro e legado. Protocolos que já usam IPv6 Router Alert podem continuar, inclusive em versões posteriores. Protocolos novos padronizados no futuro não devem usar a opção. O apêndice A contém a relação completa das exceções; não é uma autorização aberta para inventar outras.

Na camada administrativa, a mudança já ocorreu. O cadastro de parâmetros IPv6 da IANA identifica o tipo 0x05 como Router Alert não recomendado para novos protocolos. O cadastro dos valores Router Alert está fechado, e os códigos anteriormente destinados à experimentação foram reservados.

Fechar um cadastro não fecha uma fila de pacotes. O número da opção continua existindo. Os usos legados permanecem reconhecidos. As configurações dos roteadores não são reescritas pela IANA. O efeito real depende de uma decisão local: analisar, limitar, ignorar ou descartar o tráfego.

A história começa com uma economia de processamento. A RFC 2711, de 1999, tratou de datagramas de controle endereçados a um destino, mas relevantes para roteadores intermediários. Vasculhar as camadas superiores de todo pacote seria lento. Router Alert passou a carregar, no cabeçalho Hop-by-Hop do IPv6, a indicação de que aquele datagrama merecia exame adicional. Sem a opção, o tráfego comum poderia seguir sem essa inspeção.

O pedido de atenção não autentica quem o faz. A própria RFC 2711 registrou que o uso gratuito causaria problemas de desempenho e que uma inundação de falsos datagramas marcados seria ainda mais grave. Por isso, reconheceu a autoridade do roteador de trânsito para limitar a taxa ou aplicar outros controles.

A RFC 6398 mostrou que não há um mecanismo universal e conveniente para separar Router Alert desejado de indesejado. Ao contrário de um par de controle previamente conhecido, o datagrama pode trazer qualquer origem e destino. A solicitação de processamento pode alcançar roteadores centrais, não apenas uma borda onde a contraparte é conhecida.

Essa dificuldade atinge uma parte mais sensível do equipamento. A RFC 6192 descreve o plano de encaminhamento, muitas vezes implementado em ASICs para altas taxas, e o plano de controle, que executa funções mais amplas em processadores de uso geral. O segundo é mais vulnerável à exaustão por pacotes e ainda é responsável por programar o primeiro.

Logo, convém classificar e limitar tráfego indesejado o mais perto possível do hardware de encaminhamento. Mas a RFC 9805 observa que uma ACL é mais eficiente quando compara informação em posições fixas. Procurar Router Alert dentro do cabeçalho Hop-by-Hop exige trabalho adicional. O operador pode aceitar uma regra mais complexa, configurar o equipamento para ignorar a opção, ou descartar e limitar severamente Hop-by-Hop na borda. A proteção mais rígida pode interromper uma função legítima; a exceção mais larga pode ampliar a exposição.

O mérito da RFC 9805 é não prometer um classificador perfeito. Ela reduz o problema pelo lado institucional: nenhuma nova especificação poderá aumentar o conjunto de tráfego que os operadores precisam tratar como exceção legítima.

O conjunto antigo é conhecido. A RFC afirma que apenas MLDv2 e MRD, entre os usos listados, têm implantação ampla. Outros são limitados, experimentais ou não têm implementação IPv6 conhecida; a dependência de Router Alert em MPLS Ping já foi desaconselhada.

Criar versões de MLDv2 e MRD que não dependam da opção ficou para trabalho futuro. Portanto, o congelamento não contém um plano de migração pronto. Ainda serão necessários projeto, código, adoção, compatibilidade e evidência de que a descoberta multicast continua funcionando.

A RFC 9673 compõe o contexto. Ela procurou evitar que o processamento comum de opções Hop-by-Hop levasse pacotes ao plano de controle. Router Alert manteve uma exceção porque pedir exame mais atento é a sua função. A RFC 9805 não remove essa exceção; impede que surjam novos dependentes dela.

Um relatório de controle precisa distinguir sete recibos:

  1. a RFC prova a proibição para novos padrões;
  2. a IANA prova o encerramento das alocações;
  3. a especificação legada prova que um fluxo pertence à exceção;
  4. a versão e a configuração provam a intenção do equipamento;
  5. capturas e contadores provam quais pacotes chegaram e como foram classificados;
  6. filas, descartes e uso de CPU provam a consequência para o plano de controle;
  7. a substituição implantada e o desaparecimento observado do tráfego provam a aposentadoria da dependência.

Nenhum recibo anterior substitui o posterior. Também não basta proteger o processador e deixar de verificar se MLDv2 ou MRD ainda entrega a função esperada.

O princípio de especificação inicial mínima, decisão futura localizada e adoção voluntária explica a arquitetura dessa transição. A regra compartilhada é curta: fechar o conjunto. As futuras alternativas e as políticas dos equipamentos continuam locais, adaptáveis a cada ambiente.

A primazia do código em execução define a prova de avanço. Anotação não é filtro; documento não é implantação. Menos tráfego marcado, exceções menores, estabilidade sob carga e continuidade do serviço constituem evidência.

As camadas de realidade impedem a conclusão fácil. O cadastro está fechado de verdade. Novos usos padronizados estão proibidos de verdade. O estado de cada rede continua pertencendo a outra camada. A precisão não diminui a RFC; mostra onde sua autoridade produz um efeito durável.

Fontes