Resumen

  • RFC 1473 puso la configuración y el estado operativo de IP sobre PPP en tablas distintas. Escribir open inyectaba un evento en la máquina de estados IPCP; no certificaba la llegada a Opened.
  • La preferencia de compresión surtía efecto en el siguiente reinicio. Hasta completar la negociación, método y slots eran valores indefinidos; después describían parámetros, no el paso de un paquete.

La RFC 1473, publicada en junio de 1993, eligió deliberadamente una MIB pequeña. Incluyó objetos esenciales para fallos o configuración, con utilidad demostrable, y excluyó material de depuración o datos derivables.

Esa selección convirtió la tabla en una lección sobre tiempo. Una orden aceptada, un protocolo abierto y un datagrama recibido pertenecen a momentos y responsables distintos.

El evento administrativo era solo el comienzo

pppIpConfigAdminStatus expresaba el estado deseado de inmediato. Al escribir open, el agente introducía un evento Open administrativo en la máquina de estados de IPCP. close introducía Close.

La respuesta favorable del agente acreditaba la entrada. No podía acreditar que la capa inferior estuviera lista, que el otro extremo contestara ni que aceptara las opciones. El sistema aún podía quedar lejos de Opened.

La posterior RFC 1661 mantuvo un NCP separado para cada protocolo de red. Cada uno podía abrirse o cerrarse por su cuenta. Una conexión PPP y un LCP sanos no daban por abierta la IP.

La nueva preferencia pertenecía a la próxima sesión

pppIpConfigCompression indicaba si el nodo local intentaría negociar ninguna compresión o compresión de cabeceras TCP/IP de Van Jacobson. Cambiar el objeto tendría efecto cuando el enlace se reiniciara la próxima vez.

Durante ese intervalo convivían dos verdades: la configuración guardada ya era nueva y la sesión activa podía seguir siendo vieja. Hacían falta la generación del ajuste, el reinicio concreto y el intercambio IPCP para unirlas.

La RFC 1332 definió la opción IP-Compression-Protocol. La compresión estaba desactivada por defecto. Además, cada extremo debía pedir por separado la capacidad de recibir paquetes comprimidos si se quería compresión bidireccional. La aceptación en una dirección no era una propiedad total del enlace.

Antes de Opened, leer no equivalía a observar

La tabla operativa exponía pppIpOperStatus, el protocolo de compresión en cada dirección y los Max-Slot-Id local y remoto. RFC 1473 condicionó esos cuatro parámetros: solo estaban disponibles una vez terminada la negociación y alcanzado Opened.

Mientras IPCP no estuviera Opened, su contenido era indefinido. El valor concreto dependía de la implementación.

Una cifra indefinida no es una medida aproximada. Puede coincidir con un valor anterior, con cero o con una inicialización interna, pero no afirma qué acordaron estos dos extremos. La MIB podía responder correctamente en el plano sintáctico y, a la vez, negarse a dar significado operativo.

Tras Opened seguía importando la dirección. local-to-remote describía lo usado al enviar desde el nodo local; remote-to-local, el sentido contrario. Si VJ no estaba en uso, el slot debía ser cero. Antes de Opened, ese mismo cero no probaba un acuerdo de “sin compresión”.

Opened habilitaba, pero no contaba un paquete

La RFC 1332 exigía que PPP alcanzara la fase de protocolo de red e IPCP llegara a Opened antes de comunicar paquetes IP. La RFC 1661 ordenó descartar los paquetes recibidos si el NCP correspondiente no estaba abierto.

Opened era una frontera de permiso. No era un contador, un paquete capturado, una prueba de descompresión, una ruta ni una respuesta de aplicación.

La RFC 1144 explicaba la ventaja de reducir cabeceras repetidas en enlaces lentos. Pero posibilidad, negociación, uso, reconstrucción y entrega seguían siendo escalones diferentes.

La historia no cabe en un estado verde

La tabla de configuración estaba separada para facilitar otra vista MIB. RFC 1473 advertía del riesgo de controlar PPP y proponía limitar escritura, proteger vistas o volverlas inaccesibles. La familia distribuía responsabilidades: RFC 1471 para LCP; RFC 1472 para autenticación.

Una auditoría útil conserva quién cambió la preferencia, qué leyó después, qué generación quedó almacenada, cuál fue el reinicio, qué propuso cada dirección, qué respondió el par, cuándo cambió Opened y qué tráfico apareció.

Si se guarda solo el último valor, una preferencia pendiente parece activa, una lectura indefinida parece telemetría y un estado parece entrega.

RFC 1473 hizo gestionable otra cosa: el intervalo en que el sistema todavía no sabe.

Fuentes