Resumo

  • RFC 1997 exige que um receptor consciente de communities não anuncie uma rota NO_EXPORT além da fronteira de confederação; o valor não autentica emissor nem prefixo.
  • A marca vive em atributo optional transitive modificável pela política local. RFC 8642 registrou diferenças de plataforma capazes de apagar ou preservar valores conhecidos.
  • A prova acompanha a rota enviada, recebida, transformada e anunciada em cada borda, sem substituir filtros de prefixo e relacionamento.

Uma rede anuncia um more-specific numa interconexão privada para uso interno do vizinho, sem desejar propagação global. Ela adiciona NO_EXPORT. Esse ato comprova a intenção no seu próprio Adj-RIB-Out; ainda não comprova o comportamento do outro AS.

RFC 1997 criou COMMUNITIES para agrupar destinos e simplificar políticas. O atributo é optional, transitive e composto por valores de quatro octetos. Transitividade do atributo não autoriza exportar uma rota marcada: NO_EXPORT impõe a fronteira de uma confederação, considerando um AS isolado como sua própria confederação.

NO_ADVERTISE proíbe anúncio a qualquer outro peer BGP. NO_EXPORT_SUBCONFED inclui outros member ASes da mesma confederação entre os peers proibidos. IANA registra os valores; o RFC define o comportamento. A linguagem comum evita que o emissor conheça a sintaxe do fabricante remoto.

Mas RFC 1997 também permite que o receptor adicione ou modifique communities segundo a política local. Não existe alavanca remota. O valor é uma entrada para um sistema autônomo.

RFC 8642 documentou a consequência: comandos semelhantes de set community removiam todos os valores em alguns produtos, preservavam certos well-known em outros e podiam não remover os existentes. Uma policy que acrescenta uma etiqueta comercial pode apagar NO_EXPORT sem que a revisão de texto perceba.

Configuração salva não é prova. Famílias de endereços podem seguir cadeias diferentes; a versão ativa pode não ser a esperada; uma regra posterior pode sobrescrever a anterior. O veredito está na rota resultante.

RFC 7454 recomenda retirar communities do espaço próprio que o vizinho não está autorizado a acionar, conservar em geral os demais valores e não remover NO_EXPORT sem motivo. Preservar tudo permite abuso de ações privadas; apagar tudo destrói sinais legítimos. Cada relacionamento precisa de uma fronteira explícita de confiança.

O valor não carrega assinatura. Não prova quem o colocou, se o origin está autorizado ou se o contrato comercial reconhece a solicitação. RPKI origin validation e escopo de propagação são controles distintos.

RFC 7908 define route leak como propagação além do escopo pretendido, normalmente distribuído em políticas de provider, customer e peer. Muitas fugas não contêm NO_EXPORT. Prefix filters, AS-path policy e regras por classe de vizinho continuam indispensáveis.

RFC 9234 introduz um contraste: BGP Roles podem ser confirmados por ambos os lados no OPEN, e Only to Customer transporta estado da relação. Isso permite prevenir ou detectar classes de fuga cuja política unilateral não era verificável com o vizinho.

Ainda assim, o strict mode pode derrubar uma sessão após atualização, e um AS no caminho pode remover OTC deliberadamente. O mecanismo torna a relação mais legível; não cria autoridade central ou proteção criptográfica universal.

A verificação começa no emissor: NLRI, address family, peer e atributos após export policy. No receptor, separe a rota bruta da forma pós-importação. Depois examine cada Adj-RIB-Out que poderia cruzar o limite.

A ausência num único route collector não prova contenção global. Use prefixo canário, peers conhecidos e múltiplas observações. Anuncie com e sem NO_EXPORT, confirme uso no escopo permitido, ausência fora dele e limpeza após withdraw.

Automação deve comparar resultados de rota, não só arquivos. Faça falhar uma release que perca valor protegido, acompanhe exceções com dono e prazo e mantenha ação local de contenção. Quem emite o UPDATE precisa conseguir filtrar ou retirar a rota sem esperar o originador.

O princípio de especificação mínima de Heng Lu explica a divisão. O padrão comum fornece vocabulário pequeno; decisões futuras ficam com quem suporta o risco. Pela primazia do código em execução, RFC e commit representam intenção, enquanto o UPDATE efetivo representa o sistema.

NO_EXPORT funciona quando continua modesto: coordena escopo sem transferir controle. Seu nome não imobiliza a rota. A fronteira só existe quando cada ponto autônomo a implementa e demonstra.

Sources