Resumo

  • Em 9 de setembro, na APNIC 62, Maria Matejka alertou para o tratamento excessivamente duro de rotas OTC inválidas no BIRD. A correção era esperada em 2.20.0 e 3.4.0; citar essas versões não comprova uma entrega.
  • O código examinado do BIRD 2.19.2 transforma certas violações OTC, conforme o papel da sessão, em retiradas. A mensagem pode sobreviver, mas o objeto de rota que um filtro comum poderia reter não chega a ser criado nesse caminho.
  • Uma cópia isolada para diagnóstico não pode devolver à rota o direito de participar da seleção ou de ser exportada. Erros de formato do atributo também não se confundem com uma decisão de vazamento baseada na relação BGP.

Quem mantém um servidor de rotas conhece a diferença entre impedir um anúncio indevido e responder à pergunta sobre seu desaparecimento. O primeiro resultado cabe em uma verificação de segurança. O segundo exige ligar o anúncio recebido, a relação com o vizinho e o motivo da recusa. Uma linha de log pode começar essa explicação sem conseguir terminá-la.

O alerta apresentado na APNIC 62 dá atualidade a essa diferença. Maria Matejka escreveu, nos slides de 9 de setembro, que o BIRD descarta rotas OTC inválidas de forma excessivamente dura, com uma correção prevista para 2.20.0 e 3.4.0. O contexto era a limitação da observação remota: serviços externos veem apenas parte das rotas, e não há garantia de que alguém avise sobre um problema.

Não se trata de anúncio de uma versão entregue, muito menos de uma política de implantação da APNIC. A questão é se o bloqueio consegue preservar uma explicação útil sem abrir outra passagem para a rota.

O que a proibição realmente proíbe

O RFC 9234, de maio de 2022, usa papéis BGP e OTC para limitar a propagação conforme a relação entre os vizinhos. Uma rota inelegível fica fora da instalação na Loc-RIB e da etapa seguinte de seleção. Não é um simples aviso que o operador pode retirar da tela.

Essa exclusão não determina que toda representação diagnóstica seja destruída. Uma cópia em quarentena pode ajudar a identificar o erro sem virar uma opção de encaminhamento. Mas é preciso manter a quarentena como tal: o texto não autoriza instalar uma rota inválida na tabela ativa e esperar que uma etiqueta impeça seu uso.

A separação precisa valer também na exportação. Uma ferramenta criada para explicar uma recusa não pode anunciar justamente o objeto recusado. E um OTC bem formado que revela vazamento por seu valor ou direção pertence a um caso diferente de um atributo com comprimento errado.

O pedido que os operadores já haviam feito

Em junho de 2025, André Grüneberg levou a necessidade ao debate público, a partir do contexto da BCIX. Queria exibir rotas rejeitadas por OTC em uma ferramenta de consulta, com seu estado identificado. A forma de armazenamento sugerida era um pedido aos desenvolvedores, não evidência de uma implantação ou de conformidade já demonstrada.

Na resposta posterior daquele mês, o correspondente disse não encontrar interação entre o caminho de retirada e a retenção de rotas filtradas. A conversa também reconheceu que tratar OTC apenas em filtros poderia perder a verificação de papéis na sessão.

Essa possibilidade não deve virar uma receita para resolver a tela. Melhorar a visibilidade ao custo de eliminar uma checagem da relação BGP altera a proteção. A pergunta de engenharia é outra: como guardar os elementos da decisão sem trocar a segurança pela capacidade de mostrar o erro?

O debate é histórico. Ele não revela a configuração atual da BCIX, nem fornece uma estatística de adoção em pontos de troca.

A fronteira aparece no código

A página oficial de downloads capturada em 14 de setembro listava, entre outras versões, 2.19.2 e 3.3.2 com data de 30 de julho. As duas versões previstas no slide não apareciam nessa captura. Isso delimita a evidência pública examinada; não descarta ramificações, outros pacotes ou correções privadas.

No arquivo de atributos do tag 2.19.2, os procedimentos de entrada OTC dependem de os papéis serem aplicáveis ao canal. Com o papel local de provedor ou servidor de rotas, uma rota recebida com OTC aciona uma retirada. Com o papel de par, a retirada também ocorre quando o ASN do atributo difere do ASN remoto.

A operação registra uma mensagem, marca a retirada e retorna. O mesmo arquivo contém uma verificação de formato separada: OTC precisa ter quatro octetos. Outro comprimento aciona uma retirada por erro do atributo, não pela decisão posterior sobre a relação.

O processamento de pacotes do mesmo tag mostra o que vem depois. Ao terminar o processamento dos atributos, a marca de retirada faz o ponteiro ficar nulo. A aplicação da rota nessa condição envia uma retirada à rotina de atualização. Só o caminho com ponteiro não nulo constrói o objeto temporário de rota.

Logo, não basta presumir que uma opção de retenção dos filtros guardará um objeto substituído antes por uma retirada. Essa é uma inferência de um percurso estático e específico de versão, não um teste em equipamento em produção ou uma conclusão sobre todas as versões do BIRD.

Também seria errado declarar a rota invisível em qualquer lugar. O código registra mensagens. Não foram testadas capturas de pacotes, tabelas de importação, fluxos BMP ou outras soluções diagnósticas. A distinção é mais limitada: uma mensagem preservada não equivale automaticamente a um registro consultável que reúna anúncio, atributo recebido, contexto e decisão.