Resumen

  • RFC 1474 daba a cada enlace PPP y tipo MAC su propia fila. La aceptación local describía procesamiento propio; la aceptación remota era la creencia que el nodo local mantenía sobre su vecino.
  • En RFC 1220, no anunciar tipos permitía suponer compatibilidad general aunque el receptor descartara lo que no entendía. Incluso un rechazo podía coexistir con el envío del tráfico hacia quien había dicho que lo desecharía.

RFC 1474 apareció en junio de 1993 como el MIB del Bridge Network Control Protocol de PPP. Sus tablas separaban configuración, estado y medios admitidos. Esa estructura no pretendía reconstruir una entrega completa; daba al operador puntos concretos desde los que actuar.

Su precisión más valiosa estaba en el origen de cada afirmación. Dos valores idénticos podían tener testigos distintos.

Aceptar aquí y aceptar allí no eran el mismo dato

El índice de pppBridgeMediaTable combinaba ifIndex con pppBridgeMediaMacType. La fila se limitaba a un formato de trama en un enlace. Nada permitía extenderla automáticamente a otro medio, interfaz o vecino.

pppBridgeMediaLocalStatus=accept declaraba que la entidad local recibiría y procesaría correctamente los paquetes del tipo indicado. Con dont-accept, aquellos paquetes no serían procesados de manera adecuada. La máquina informaba de sí misma.

pppBridgeMediaRemoteStatus tenía una semántica distinta: indicaba si la entidad local creía que la remota aceptaría el mismo tipo. El sujeto descrito era el vecino, pero el sujeto que conocía era el nodo local.

El matiz determina el uso del dato. La capacidad propia puede comprobarse contra configuración y ejecución local. La remota se construye con mensajes, omisiones, valores por defecto y la generación vigente de negociación.

El silencio no equivalía a una prueba

El antecedente era RFC 1220. MAC Type Selection permitía anunciar qué tráfico estaba preparado un sistema para recibir y atender. Para declarar varios tipos debían aparecer varias opciones en Configure-Request.

Si no había anuncio, el vecino podía asumir soporte para todos los tipos. Al mismo tiempo, el receptor podía descartar los que no entendiera. La regla daba una conducta al emisor cuando faltaba información; no añadía una implementación al receptor.

Un anuncio explícito advertía que los tipos no enumerados serían desechados. Y Configure-Reject tampoco cerraba el circuito: RFC 1220 contemplaba que el tráfico correspondiente siguiera reenviándose por el enlace aunque el receptor hubiera indicado que lo descartaría.

Por eso, un estado remoto sin transcript pierde su sentido. Hay que saber si nació de un anuncio, una ausencia interpretada, un rechazo o una memoria de otra sesión.

La revisión posterior mantuvo el carácter consultivo

RFC 1638, sucesor de 1994, recomendó con fuerza negociar MAC-Support. El anuncio permitía evitar tráfico incompatible y ahorrar ancho de banda. Aun así, el documento calificó la opción como meramente consultiva.

También añadió una prohibición para tipos MAC superiores a 4: no transmitirlos sin haber recibido del par una opción que indicara voluntad de aceptarlos. El cambio muestra cómo la ampliación del espacio de tipos exigió una frontera más estricta. No demuestra la recepción de una trama concreta.

Compatibilidad con sistemas antiguos, uso eficiente del enlace y protección de extensiones eran problemas diferentes. Una regla de negociación podía mejorar la decisión local sin convertirse en observación remota.

Admitir el formato no resolvía el destino

Un puente podía entender un tipo MAC y no saber todavía por qué puerto reenviar una dirección específica. RFC 1493 trató esa cuestión en otra tabla: una base con información aprendida o configurada para direcciones MAC unicast y decisiones de reenvío o filtrado.

La tabla de RFC 1474 hablaba de familia de trama y enlace. La FDB hablaba de una dirección concreta. Ninguna era un acuse del host de destino.

La cadena completa tendría que unir política local, reinicio aplicable, intercambio BNCP, fundamento de la creencia remota, trama enviada, tratamiento por el par, decisión de reenvío y evidencia final. RFC 1661 añadió un umbral: PPP solo transportaba los paquetes del protocolo después de que su NCP alcanzara Opened. El estado habilitaba el tráfico; no registraba que hubiera ocurrido.

Toda creencia necesita procedencia

RFC 1474 separó la tabla escribible y advirtió del riesgo de controlar PPP mediante el MIB. Restringir vistas protegía quién podía modificar o leer el dato. No convertía una inferencia en hecho del otro extremo.

En automatización actual, “soporte remoto” debería incluir interfaz, tipo MAC, generación de configuración, reinicio, estado NCP, opciones, regla por omisión, respuesta y hora de cálculo. De lo contrario, una conclusión local se propaga hasta presentarse como entrega confirmada.

Inferir no es un defecto: ningún sistema distribuido opera sin un modelo de sus pares. El defecto consiste en ocultar al autor de la inferencia.

RFC 1474 dejó ese autor dentro de la definición.

Fuentes