Resumen

  • RFC 1220 impedía intercambiar tráfico LAN antes de que el Bridge Network Control Protocol alcanzara Open. Ese estado habilitaba una clase de paquetes; no acreditaba que alguno llegara a su destino.
  • El servicio todavía dependía de un MRU suficiente, conservación de orden en enlaces paralelos, compatibilidad MAC, compresión por dirección, política LAN-ID, spanning tree y tratamiento del FCS.
  • El CRC del enlace PPP y el FCS de la LAN eran independientes. Superar la verificación del salto serie no demostraba que se hubiera preservado la trama LAN original ni que se hubiera emitido en la red remota.

Un estado de control abrió la puerta

RFC 1220, Point-to-Point Protocol Extensions for Bridging, apareció en abril de 1991 bajo la edición de F. Baker. El RFC Editor y el IETF Datatracker la registran como Proposed Standard del flujo IETF y hoy la señalan como obsoleta por RFC 1638. La ficha demuestra qué documento existió y cuál es su situación; no demuestra que una red lo desplegara.

La propuesta llevaba tramas de LAN entre puentes remotos mediante líneas punto a punto. Partía de la disciplina PPP de RFC 1171 y suponía que ambos equipos habían acordado usarla. También contemplaba que pudieran querer emplear el enlace para bridging. Una suposición del modelo no equivale a una captura de negociación ni a una orden de operación.

BNCP era el segundo umbral. Debía esperar a que LCP entrara en la fase de configuración de protocolos de red. Solo después de que BNCP abriera se permitía el tráfico LAN. Así, la trama de datos no podía adelantarse al intercambio que configuraba y habilitaba los extremos.

Open respondía a una pregunta precisa: ¿autoriza ahora la máquina de estados este tipo de tráfico? No respondía qué trama cruzó, si la tabla de reenvío eligió una salida, si el puerto remoto estaba activo, si el destino recibió datos ni si una aplicación funcionó.

No rechazar un BPDU era una señal acotada

Para transparent bridging, RFC 1220 suponía permiso en el enlace cuando el vecino recibía BPDUs IEEE 802.1 sin responder con Protocol-Reject de PPP. La ausencia de una negativa tenía, por tanto, significado dentro de ese protocolo.

No era una autorización humana universal. No identificaba al administrador, no mostraba la configuración de ambos extremos y no probaba convergencia del árbol. Además, un operador podía separar dos dominios de spanning tree. Para hacerlo debía configurar ambos lados para no intercambiar BPDUs; si aun así llegaba uno, el puente lo descartaba en silencio.

Desde fuera, la misma falta de respuesta podía ser aceptación, separación intencionada o un fallo unidireccional. El documento recomendaba detección de bucle con Magic Number y vigilancia de calidad porque el tráfico normal del spanning tree avanzaba casi siempre desde la raíz hacia las hojas. El silencio de vuelta no certificaba la vuelta.

Negociar no eliminaba el desacuerdo

BNCP incluía opciones de tipos MAC, compresión tinygram, identificación de LAN y números de anillo/puente. El anuncio MAC enumeraba lo que el receptor estaba dispuesto a atender. Si anunciaba algunos tipos, los no enumerados se descartaban. Si no anunciaba ninguno, el otro extremo podía asumir compatibilidad amplia, aunque el receptor todavía descartaría lo desconocido.

El rechazo de un anuncio revelaba una grieta todavía mayor: el emisor podía seguir enviando tráfico de un tipo que el receptor ya había indicado que abandonaría. El protocolo registraba el desacuerdo, pero no convertía automáticamente esa información en un bloqueo seguro.

La compresión era direccional. Un extremo podía aceptar descompresión y el otro no; sin negociación no había compresión. Una etiqueta global de “compresión activa” ocultaría qué sentido era válido.

LAN Identification era consultivo y venía deshabilitado. Habilitado, decía que quizá había LAN etiquetadas detrás del peer y que este estaba preparado para servirlas. Deshabilitado, anunciaba que las descartaría. El valor guiaba el envío; no probaba pertenencia organizativa, control de acceso ni emisión por una interfaz concreta.

Un enlace abierto podía no admitir una trama válida

RFC 1220 exigía que el MRU negociado fuera suficiente para los tipos MAC aceptados. No había fragmentación ni reensamblado. Incluso Ethernet podía sobrepasar el MRU PPP predeterminado de 1.500 octetos. Por eso BNCP podía estar Open y, a la vez, una trama permitida por la LAN no caber en el transporte.

Varias líneas paralelas añadían la cuestión del orden. El transmisor debía saber si el protocolo puenteado exigía la secuencia original y, si no podía demostrar lo contrario, debía preservarla. Distribuir una conversación para aprovechar más capacidad podía romper una propiedad que el protocolo de LAN daba por sentada.

Los dos checksums mostraban otra separación. El CRC de PPP protegía la trama en el enlace punto a punto. El FCS LAN opcional correspondía a la trama originaria. Si no venía incluido, el puente podía provocar el cálculo de uno nuevo al emitir. Integridad en el salto, preservación de la trama original y entrega final eran afirmaciones diferentes.

Los bits describían una intención de formato

Las banderas de RFC 1220 señalaban FCS presente, LAN ID, relleno cero comprimido y padding de línea. El tipo MAC permitía interpretar los octetos. Nada de ello enseñaba la entrada aprendida en la tabla, el estado del puerto de spanning tree o la recepción por el host final.

Las fuentes tampoco incluyen configuración, captura de BNCP, tabla de forwarding, traza de paquetes ni registro de aplicación. La sección de seguridad dice que esos asuntos no se discuten. No hay base para inferir autenticación, autoridad, confidencialidad, despliegue o resultado.

El mérito de Open era ser una señal limitada y comprensible. La confusión empezaba cuando el panel la convertía en “LAN extendida operativa”.

Fuentes