Resumen

  • RFC 1553 podía reducir una cabecera IPX de 30 octetos a entre uno y siete, y una cabecera NCP/IPX de 36 a entre uno y ocho. Lo ausente quedaba en ranuras sincronizadas del compresor y el descompresor.
  • El contexto IPX general necesitaba Confirmed Initial y Confirm antes del tráfico comprimido. NCP tenía una excepción no confirmada porque su secuencia y retransmisión podían revelar la pérdida de contexto.
  • Omitir también el número de ranura solo era seguro si el descompresor recibía aviso de toda pérdida; tras un descarte debía rechazar ranuras implícitas hasta ver una explícita.

El paquete breve no era autosuficiente

El octeto visible contenía banderas. El resto de la cabecera estaba en otra parte: una entrada del emisor y otra del receptor. Si ambas no describían la misma conexión y generación, la trama corta no tenía un significado único.

RFC 1553, publicado como Standards Track en diciembre de 1993 y hoy marcado Historic, definió CIPX. La estrategia general llevaba los 30 octetos de IPX a uno–siete. Otra estrategia obligatoria trataba solicitudes y respuestas NCP 0x2222 y 0x3333, reduciendo 36 octetos NCP/IPX a uno–ocho. Los demás tipos NCP seguían pudiendo usar el método IPX.

Tras negociar CIPX, incluso una forma regular no comprimida llevaba sus banderas. El enlace había entrado en una conversación con estado, no en un catálogo de abreviaturas independientes.

Cada campo omitido citaba el pasado

El compresor comparaba la cabecera nueva con la guardada en una ranura y enviaba los cambios. El descompresor aplicaba esos cambios a su copia. Una trama de un octeto era correcta únicamente si todo lo omitido seguía siendo válido.

Por eso una captura aislada no podía probar la reconstrucción. Hacían falta la tabla, su generación y las transiciones aceptadas. Si se combinaban compresión de cabecera y de datos, también importaba el orden: primero cabecera y después datos al enviar; primero datos y después cabecera al recibir.

Ese orden separaba dos transformaciones que podían convivir sin compartir autoridad. Haber descomprimido bien los datos no certificaba la ranura; haber reconstruido una cabecera no certificaba la entrega de NCP. Un observador situado entre ambas operaciones veía un objeto distinto del que recibía la aplicación. Sin registrar el punto de captura, dos lecturas incompatibles podían ser técnicamente correctas y probatoriamente inútiles.

La forma regular tampoco sacaba el paquete de la conversación. Una vez negociado CIPX, incluso el IPX enviado sin reducción llevaba el octeto de banderas. Era una vía para devolver más información al cable dentro del mismo régimen, no la prueba de que todo estado previo había desaparecido.

Confirmar una ranura la convertía en autoridad

En IPX general, la pérdida del primer paquete podía ser invisible porque la cabecera ordinaria no aportaba una secuencia que identificara bien la retransmisión. RFC 1553 exigió un Confirmed Initial con número de ranura e ID de un octeto, seguido por Confirm, antes de usar esa asociación para paquetes comprimidos.

Al reutilizar una ranura para otra cabecera, el ID aumentaba. Ranura más ID nombraban una generación. La duración «razonablemente larga» de esa identidad dependía de velocidad, retardo y carga; el documento no convirtió un byte en eternidad.

La distinción entre lugar y generación impedía que una trama retrasada se apropiara de una asociación nueva solo porque ambas ocuparan la misma posición de la tabla. Un número de ranura decía dónde mirar; el ID decía qué época de ese lugar era válida. El espacio de un octeto acababa dando la vuelta, por lo que la seguridad temporal dependía de cuánto tardaban en desaparecer las tramas antiguas y de cuán deprisa se reasignaban las entradas.

El emisor no tenía que inmovilizar todo el tráfico mientras esperaba. Podía repetir la misma pareja ranura-ID con datos nuevos de la misma cabecera, o reasignar la posición a otra cabecera incrementando el ID. La libertad de avanzar estaba condicionada a que cada cambio de significado dejara una generación distinguible.

NCP permitía Unconfirmed Initial y compresión inmediata porque sus secuencias y retransmisiones podían descubrir el daño. Aun así, cualquier número que no fuera exactamente uno mayor obligaba a enviar un nuevo Initial. La excepción trasladaba la detección a otra señal, no la eliminaba.

Por eso no podía copiarse como una optimización genérica. El camino sin confirmación no era seguro por llamarse NCP, sino porque ese intercambio concreto exponía secuencia y repetición. En un tráfico sin las mismas propiedades, quitar el Confirm conservaría la velocidad pero perdería el mecanismo que acotaba el riesgo.

Ahorrar la ranura exigía observar cada pérdida

La compresión del número de ranura hacía que un paquete significara «usa la última ranura». Si se perdía el paquete que cambió esa última selección, los extremos podían continuar sobre historias distintas.

La opción venía desactivada. Solo podía habilitarse cuando la capa PPP notificaba al descompresor cada paquete erróneo o descartado. Después de una pérdida, el receptor debía descartar todo paquete sin ranura explícita hasta que uno la restableciera. La observabilidad entre capas formaba parte de la validez de la abreviatura.

La regla aceptaba una consecuencia incómoda: una trama posterior podía estar intacta y aun así debía desecharse. El problema ya no era su integridad individual, sino que la palabra «anterior» había dejado de designar una historia común. CIPX prefería una pérdida visible a una reconstrucción verosímil basada en el contexto equivocado.

Eso convertía la notificación del nivel PPP en parte del formato, no en una métrica para revisar al final del mes. Un contador agregado podía decir que hubo pérdidas; el descompresor necesitaba saber exactamente cuándo se rompió la secuencia que definía la última ranura. Si el aviso no llegaba, la opción más corta dejaba de cumplir su supuesto de diseño.

El desacuerdo tenía salida

Un valor reservado distinguía CIPX de una cabecera IPX normal cuyo checksum empezaba por 0xFFFF. Si un par se reiniciaba y volvía a IPX ordinario, el otro debía reconocerlo y renegociar. Los paquetes Reject señalaban tipos o funciones dependientes desconocidos. Una extensión incompatible fallaba de forma visible, y el formato regular ofrecía repliegue.

En PPP, la opción IPXCP pedía capacidad de recepción por dirección, así que la compresión bidireccional requería dos peticiones. IPX-WAN producía en cambio una configuración simétrica con el mismo número de ranuras y subconjunto aceptado. Ninguna negociación probaba por sí sola una confirmación, una tabla correcta o un resultado de aplicación.

Dos geometrías de negociación, dos clases de recibo

Decir simplemente «CIPX estaba negociado» ocultaba una diferencia operativa. En PPP, cada extremo solicitaba lo que quería ser capaz de recibir. La capacidad de A para enviar comprimido hacia B no autorizaba por sí sola la dirección inversa. Un inventario serio debía conservar las dos solicitudes, sus respuestas y la dirección efectiva de cada una.

IPX-WAN llegaba a otro tipo de resultado: ambos sentidos quedaban sujetos al mismo número de ranuras y a un subconjunto común de opciones. La simetría simplificaba la descripción final, pero no demostraba cómo se alcanzó ni qué ocurrió después. Un enlace podía compartir parámetros y, sin embargo, perder una Initial, divergir en una generación o no recuperar el servicio.

La admisión de una capacidad, el establecimiento de una ranura y el éxito de una operación pertenecían por tanto a registros distintos. Fundirlos en un indicador verde daba al acto de negociar una autoridad que el protocolo no le concedía.

El dos a uno era una hipótesis que enseñaba sus cuentas

El cálculo aproximado de dos a uno usaba 26 octetos de datos, 30 de cabecera original y dos de cabecera comprimida. Era un modelo, no una medición. La frase del RFC según la cual CIPX no alteraba significativamente la seguridad básica de IPX era una evaluación de 1993, no garantía universal sobre implementaciones actuales o entradas malformadas.

La aritmética era transparente: 26 más 30 daban 56; 26 más dos daban 28. Lo que no aparecía en esa división era la distribución real de tamaños, la frecuencia de Initial y Confirm, la reutilización de ranuras, los Reject, el empleo de la forma regular ni los descartes hasta recuperar una ranura explícita. Tampoco figuraban CPU, latencia, retransmisiones o resultados de aplicación.

Una tasa de compresión podía mejorar mientras el servicio empeoraba. Los paquetes más cortos seguían consumiendo enlace aunque fueran descartados por contexto incierto; una retransmisión de nivel superior podía devolver más tráfico del que el encabezado había ahorrado. Para convertir el modelo en evidencia operativa hacían falta un corpus, un intervalo, un punto de medición y una definición del resultado útil.

La misma disciplina debía aplicarse al párrafo de seguridad. Registrar que el memo no veía un cambio significativo en la seguridad básica de IPX no autorizaba una conclusión sobre cada implementación futura. Un alcance documental estrecho no se convierte por antigüedad en certificación universal.

Las fuentes congeladas no identifican ningún despliegue CIPX, base instalada, corpus de tráfico, prueba de interoperabilidad, incidente ni resultado de usuario. Fijan las reglas y el linaje documental; no muestran cuántas cabeceras de un octeto circularon ni si un producto se recuperó correctamente.

Una captura sin la tabla no podía cerrar el caso

Supongamos que una investigación conserva el paquete recibido y la cabecera completa que produjo el descompresor. Todavía falta la pregunta decisiva: ¿qué campos cruzaron el enlace y cuáles llegaron desde la memoria? Dos reconstrucciones idénticas pueden tener procedencias distintas; dos reconstrucciones diferentes pueden partir del mismo octeto visible si las tablas no coinciden.

La evidencia mínima debe unir la trama con el dueño y dirección de la negociación, las opciones aceptadas, el número de ranuras, el asignador, el ID de generación y la Initial completa. En el camino general añade el Confirm; en NCP, la secuencia y la repetición que justificaron no esperarlo. Luego incorpora los avisos de pérdida, el orden de aceptación y la decisión de usar o rechazar una ranura implícita.

Todavía no termina ahí. Longitud y checksum pueden venir de lugares distintos según las banderas; el encabezado reconstruido necesita una huella que permita compararlo; el acto del descompresor debe separarse de la recuperación del transporte y de la respuesta de la aplicación. Cada capa responde a una pregunta propia.

Guardar solo el producto final convierte inferencia en apariencia de recepción. Cuando el estado se ha sobrescrito, ninguna revisión posterior puede reconstruir qué generación dio autoridad al campo. El riesgo irreversible de la compresión no era perder un byte del cable, sino perder también el recibo del lugar al que se había trasladado su significado.

El recibo completo necesita dirección y dueño de la negociación, opciones, ranuras, asignador e ID, Initial completo, Confirm cuando corresponda, visibilidad de errores, secuencia aceptada, ranura explícita o implícita, procedencia de longitud y checksum, hash de la cabecera reconstruida, acción del descompresor, recuperación de transporte y resultado de aplicación. Los bytes desaparecieron del cable, no de la responsabilidad.

Fuentes