Resumen

  • RFC 5492 permite que un hablante BGP enumere capacidades opcionales en OPEN. Una capacidad se usa en la sesión solo si los dos pares la anunciaron. Una capacidad recibida y desconocida debe ignorarse; una capacidad exigida por el propósito local, pero ausente en el peer, puede motivar una terminación que nombre la causa.
  • El registro de John Scudder continúa con RFC 8810, que reorganiza un espacio privado de códigos que producía confusión, y RFC 9072, escrito con Enke Chen, que amplía de forma compatible el límite de 255 octetos de los parámetros OPEN. La extensibilidad necesita consentimiento visible, nombres únicos y un límite donde el parser antiguo deje de fingir comprensión.

TCP decía sí; el protocolo todavía no

Antes de anunciar una ruta, BGP intercambia mensajes OPEN. La conexión inferior puede estar sana y, sin embargo, la relación no servir para el cometido previsto. La razón puede ser tan concreta como una capacidad que una parte necesita y la otra no ha declarado.

El comportamiento base descrito por RFC 5492 terminaba el peering ante un Optional Parameter desconocido. Evitaba interpretar bytes sin contrato, pero complicaba introducir funciones: una novedad podía destruir incluso el intercambio básico que ambos routers aún comprendían.

Capability Advertisement separa el contenedor del contenido. El OPEN lleva un Capabilities Optional Parameter con una lista de extensiones. Un receptor puede entender el contenedor aunque desconozca una entrada. Lo nuevo queda inactivo para él sin adquirir autoridad y sin obligar a sacrificar el terreno común.

John Scudder y Ravi Chandra figuran como autores de RFC 5492. Scudder es autor de RFC 8810, sobre el registro de Capability Codes, y coautor con Enke Chen de RFC 9072, que extiende la longitud de Optional Parameters. El perfil de IETF Datatracker confirma esas publicaciones y la identidad pública.

La atribución termina ahí. Son RFC del proceso colectivo del IETF, con coautores, revisores, implementadores, IANA y operadores. El nombre de Scudder sustenta un análisis de participación documentada; no lo convierte en inventor único de BGP ni en responsable de una implementación o un resultado de producción.

Un registro mínimo con tres piezas

Cada capacidad contiene un Capability Code de un octeto, un Capability Length de un octeto y un Capability Value de longitud variable. El code identifica la capacidad; el length delimita el valor; la especificación del code define cómo interpretar ese valor.

La estructura compartida es estrecha a propósito. No intenta gobernar desde un único documento todas las extensiones futuras. Una capacidad que admita varios valores o instancias debe explicar sus propias reglas. Así, implementaciones independientes reconocen el marco sin que el marco se arrogue cada decisión técnica.

El registro tampoco prueba más de lo que contiene. Un code asignado preserva significado común, no autentica al vecino. Una longitud correcta impide que un campo invada al siguiente, no certifica la implementación. Un value bien formado puede seguir siendo incompatible con la configuración o el propósito del enlace.

RFC 5492 aconseja un solo Capabilities Optional Parameter que agrupe los TLV. Por compatibilidad, el receptor debe aceptar varios parámetros y tratar el conjunto combinado de la misma manera. Duplicados idénticos no agregan significado, pero deben ser tolerados. La interoperabilidad se mide por la semántica observable, no por una única serialización cómoda para un fabricante.

La extensión requiere dos declaraciones

Una capacidad puede usarse en un peering únicamente cuando ambos pares la han anunciado. Si falta en cualquiera de los OPEN, no puede usarse en esa sesión.

La regla es más precisa que preguntar si una versión de software “soporta” algo. Una función compilada puede estar deshabilitada, limitada a ciertas familias o excluida de un vecino. La evidencia relevante es lo que cada router en ejecución declaró al otro en esa apertura concreta.

Tampoco hay imposición unilateral. Un anuncio no convierte el silencio en aceptación. IANA puede registrar el número, el RFC puede definir la conducta, el proveedor puede incluirla y el operador puede configurarla; aun así, la sesión requiere que ambos extremos la pongan en el registro.

Hay que conservar dirección y value. Algunas capacidades no son simétricas. Un panel que fusiona las dos vistas en un simple “supported” borra quién afirmó qué y limita la investigación posterior.

Desconocido no significa obligatorio, y obligatorio no significa desconocido

Si un speaker recibe una capacidad que no reconoce o no implementa, debe ignorarla. No puede enviar Unsupported Capability ni terminar por ese solo hecho. Es la condición que permite introducir novedades sin convertir cada anuncio opcional en un arma contra vecinos antiguos.

El caso opuesto nace de un requisito local. Una sesión puede haber sido encargada para intercambiar una familia o prestar una función que depende de cierta capacidad. Si el peer no la anuncia, el speaker puede emitir Unsupported Capability y terminar. La NOTIFICATION debe incluir las capacidades cuya ausencia causó la decisión.

Definir algo como necesario pertenece al lado local. RFC 5492 desaconseja restablecer automáticamente un peering cerrado por esa causa. Repetir TCP y OPEN con el mismo software, la misma política y la misma ausencia no es recuperación; es un bucle que oculta la necesidad de una decisión.

Así se separan dos hechos. Una capacidad extra que no comprendo no debe romper el servicio común. Una capacidad sin la cual mi objetivo no existe puede impedir que el servicio comience. Registrar ambos como “mismatch” elimina la información que determina la acción correcta.

El fallback conserva una relación, no necesariamente su encargo

Un BGP antiguo puede desconocer incluso el Capabilities Optional Parameter y responder Unsupported Optional Parameter. RFC 5492 recomienda que el speaker moderno vuelva a intentar sin enviar ese contenedor.

La reconexión ofrece BGP básico a un peer legado. Puede ser una solución válida si eso era suficiente. No es prueba de que una sesión destinada a multiprotocolo u otra función haya cumplido su objetivo. Established puede describir el transporte del protocolo y ocultar la ausencia del producto operativo.

Por eso el registro debe enlazar el primer rechazo, el segundo OPEN reducido, las capacidades perdidas, las familias activas y las rutas realmente intercambiadas. Si solo se guarda el último estado verde, una degradación queda registrada como reparación.

Compatibilidad hacia atrás significa preservar el subconjunto comprensible cuando ese subconjunto sirve. No exige aceptar eternamente el mínimo de un vecino antiguo cuando el propósito cambió.

El código privado colisiona al salir del laboratorio

RFC 5492 reservó originalmente 128–255 para Private Use. RFC 8810 documenta que la experiencia volvió esa zona inútil y confusa para implementadores.

Dos productos pueden usar el mismo número para dos capacidades distintas en entornos separados. Cuando se interconectan, el número no transporta el contexto privado. Cada extremo reconoce un code y le atribuye otro significado. El campo que debía demostrar compatibilidad crea una coincidencia falsa.

RFC 8810 deja 1–63 bajo IETF Review, asigna 64–238 por First Come First Served, reserva 239–254 a Experimental Use y mantiene 255 como Reserved. Lo experimental se destina al desarrollo temprano, no a productos enviados ni al uso permanente.

Es una función registral limitada: impedir duplicidad semántica y ofrecer una referencia. El registro no obliga a habilitar la capacidad, no certifica software y no decide si el riesgo de despliegue es aceptable.

La transición reconoce su incertidumbre. Se investigaron usos privados conocidos y se registraron varios valores preestándar, pero el RFC no asegura haberlos hallado todos. Una colisión residual debe observarse y corregirse; no desaparece porque la tabla oficial se haya ordenado.

También se llenó el sobre usado para negociar

El campo Optional Parameters Length de OPEN era de un octeto: todo el espacio opcional quedaba limitado a 255 octetos. La colección de capacidades podía crecer hasta llenar el mismo lugar donde debía anunciar su crecimiento.

RFC 9072 conserva normalmente el formato base cuando el total no supera 255. Si lo supera, el tipo 255 actúa como marcador de formato extendido, seguido por una longitud total de dos octetos; las longitudes de parámetros individuales también pasan a dos octetos. Una implementación nueva debe aceptar el formato extendido incluso con contenido menor.

La compatibilidad con un peer antiguo es condicional. Mientras el nuevo OPEN quepa en la envoltura vieja, ambos pueden interoperar. Cuando realmente requiere más de 255 octetos, el nuevo speaker debe usar la forma ampliada. El antiguo interpreta 255 como un parámetro desconocido y se espera que cierre con Unsupported Optional Parameters.

Ese final evita una compatibilidad imaginaria. Truncar o ignorar parte del mensaje dejaría a los dos lados con conjuntos diferentes y una sesión engañosa. La compatibilidad preserva la parte que ambos entienden; no concede al parser viejo una capacidad inexistente.

RFC 9072 tampoco cambia la seguridad ni la confidencialidad inherentes a BGP. Más espacio para declaraciones no significa declaraciones autenticadas.

Lo mínimo compartido debe responder ante la red que funciona

El ensayo posterior de Lu Heng, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption, ofrece a Sofia Ren una lente útil. La capa común puede limitarse a un contenedor interpretable, códigos únicos, condición bilateral, fallos acotados y longitud ampliable. Cada capacidad define su significado y cada operador decide dónde exigirla.

Es una lectura editorial de 2026, no evidencia de la intención privada de Scudder, Chandra, Chen o el IETF. La autoridad técnica permanece en el texto publicado.

Running-Code Primacy añade la comprobación. El OPEN es más fuerte que un folleto porque registra lo que dos routers activos declararon. Sigue sin demostrar el resultado: hay que observar el estado negociado, los mensajes, las rutas, el error, la recuperación y el forwarding.

Capability Advertisement no necesita un soberano que apruebe cada extensión. Necesita nombres que no colisionen, dos declaraciones separadas y operadores que no confundan capacidad con garantía. Su disciplina consiste en dejar que lo nuevo entre voluntariamente y hacer visible el punto exacto donde el acuerdo ya no alcanza.

Fuentes