Resumen

  • RFC 8654 eleva de 4.096 a 65.535 octetos el máximo de los mensajes BGP salvo OPEN y KEEPALIVE, pero solo permite enviarlos a un par que haya anunciado la capacidad 6.
  • La capacidad es un compromiso de recepción por sesión, no un permiso global: el soporte mixto puede forzar descarte de atributos, retención del UPDATE o retirada de una ruta.

El sobre mayor comienza con una promesa bilateral

RFC 4271 fija el punto de partida: un mensaje BGP se procesa solo después de recibirse completo y su máximo es 4.096 octetos. RFC 8654 eleva ese límite para responder al crecimiento de familias de direcciones y funciones, excepto en OPEN y KEEPALIVE.

El control no reside en el número, sino en la negociación. Un equipo capaz de recibir mensajes extendidos SHOULD anunciar esa capacidad mediante RFC 5492. IANA la registra con el código 6. El emisor MAY transmitir un mensaje extendido únicamente si recibió esa capacidad del par de esa sesión.

Anunciarla impone una obligación real: la implementación MUST aceptar mensajes de hasta 65.535 octetos. A la inversa, un equipo que pueda procesarlos pero esté configurado para no anunciar la capacidad MUST NOT aceptar uno. La capacidad del software no sustituye el límite configurado.

RFC 8654 añade un límite de salida independiente: un mensaje NOTIFICATION enviado a un par que no anunció la capacidad no DEBE superar los 4.096 octetos (MUST NOT).

Una frontera capaz no convierte en capaz a la siguiente

Un UPDATE de más de 4.096 octetos puede llegar desde un par compatible y luego necesitar propagarse hacia un vecino sin la capacidad. La primera sesión autorizó la recepción; no decidió nada sobre la segunda.

RFC 8654 indica que el intermediario SHOULD intentar reducir el mensaje retirando solo atributos elegibles para «attribute discard» según RFC 7606. Esos atributos no pueden afectar la selección ni instalación de la ruta. Si el UPDATE sigue siendo demasiado grande, queda prohibido enviarlo a ese vecino (MUST NOT). Si el NLRI ya había sido anunciado a ese vecino, debe retirarse del servicio.

El beneficiario puede ser una aplicación que necesita transportar más atributos o NLRI. El coste puede recaer en el vecino siguiente y en los usuarios de una ruta que ya no atraviesa el límite de 4.096 octetos. La capacidad de representación se transforma en una decisión de propagación y alcance.

La coherencia interna es una decisión de despliegue

RFC 8654 solo garantiza una visión coherente dentro de un sistema autónomo si todos sus hablantes iBGP anuncian la capacidad. Si no ocurre, el operador debería valorar si debe anunciarla a pares externos.

La secuencia responsable es inventariar capacidades por sesión, probar recepción y análisis al tamaño máximo, medir margen de memoria, localizar todas las fronteras y observar rutas eliminadas o atributos descartados durante el despliegue incremental. Después puede decidirse la exposición externa.

La extensión no corrige la seguridad subyacente de BGP. Los búferes mayores pueden aumentar la exposición al agotamiento de recursos intencionado o accidental. Recibir la capacidad no demuestra legitimidad de ruta ni seguridad del contenido; solo acredita capacidad declarada para recibir.

Evidencia y límites

RFC 8654 define tamaño, excepciones, negociación y límites mixtos. RFC 4271 aporta el máximo original. RFC 5492 define el anuncio de capacidades, RFC 7606 limita el descarte de atributos e IANA confirma el código 6.

Las fuentes no identifican redes que lo habiliten hoy, no cuantifican un coste universal ni garantizan que el descarte siempre reduzca el UPDATE. Poder, autorización, beneficiarios, coste y contrafactual son inferencias analíticas apoyadas en las normas.

Fuentes