Resumo

  • A RFC 8654 eleva de 4.096 para 65.535 octetos o tamanho máximo das mensagens BGP, exceto OPEN e KEEPALIVE, mas permite enviá-las somente a um par que anunciou a capacidade 6.
  • A capacidade é um compromisso de recepção por sessão, não autorização para toda a rede; suporte misto pode exigir descarte de atributos, retenção do UPDATE ou retirada de rota.

O envelope maior começa com uma promessa bilateral

A RFC 4271 define a base: uma mensagem BGP é processada apenas depois de recebida integralmente e o máximo é 4.096 octetos. A RFC 8654 aumenta o limite para acomodar novas famílias de endereços e recursos, exceto em OPEN e KEEPALIVE.

O controle não está no número, mas na negociação. Um equipamento capaz de receber mensagens estendidas SHOULD anunciar a capacidade pelo mecanismo da RFC 5492. A IANA a registra como código 6. O remetente MAY enviar uma mensagem estendida apenas quando recebeu essa capacidade do par naquela sessão.

O anúncio cria obrigação real: a implementação MUST receber até 65.535 octetos. Ao contrário, um equipamento capaz, mas configurado para não anunciar a capacidade, MUST NOT aceitar mensagem estendida. Capacidade técnica não substitui o limite configurado.

A RFC 8654 acrescenta um limite de saída distinto: uma mensagem NOTIFICATION enviada a um par que não anunciou a capacidade não deve exceder 4.096 octetos (MUST NOT).

A capacidade de uma borda não passa à próxima

Um UPDATE acima de 4.096 octetos pode entrar por um par compatível e precisar seguir para um vizinho sem a capacidade. A primeira sessão autorizou a recepção; nada decidiu sobre a segunda.

A RFC 8654 diz que o intermediário SHOULD tentar reduzir a saída removendo apenas atributos elegíveis ao “attribute discard” da RFC 7606. Eles não podem afetar seleção ou instalação de rota. Se o UPDATE continuar grande demais, fica proibido enviá-lo ao vizinho (MUST NOT). Se o NLRI já havia sido anunciado ao vizinho, deve ser retirado de serviço.

O beneficiário pode ser a aplicação que transporta mais atributos ou NLRI. O custo pode cair sobre o próximo par e os usuários de uma rota incapaz de atravessar a fronteira de 4.096 octetos. Capacidade de representação torna-se decisão de propagação e alcance.

Consistência interna vira responsabilidade de implantação

A RFC 8654 só garante visão coerente dentro do AS quando todos os falantes iBGP anunciam a capacidade. Sem isso, o operador deveria avaliar se deve anunciá-la a pares externos.

A sequência responsável é inventariar capacidade por sessão, testar recepção e análise no tamanho máximo, medir folga de memória, localizar bordas internas e externas e observar rotas descartadas e atributos removidos na implantação incremental. Só então se decide a exposição externa.

A extensão não resolve os problemas de segurança do BGP. Buffers maiores podem aumentar a exposição ao esgotamento intencional ou acidental de recursos. Receber a capacidade não prova legitimidade da rota nem segurança do conteúdo; prova apenas a capacidade declarada de recepção.

Evidências e limites

A RFC 8654 define tamanho, exceções, negociação e limites mistos. A RFC 4271 fornece o máximo original. A RFC 5492 define anúncio de capacidades, a RFC 7606 limita descarte de atributos e a IANA confirma o código 6.

As fontes não identificam redes que usam a função hoje, não quantificam custo universal nem garantem que o descarte sempre resolva o excesso. Poder, autorização, beneficiários, custo e contrafactual são inferências analíticas derivadas dos padrões.

Fontes