Resumen

  • En RFC 1993, el final de la trama comprimida no tenía por qué ser el final del paquete PPP original.
  • El emisor enviaba incluso una salida expandida, porque omitirla habría separado las historias que mantenían ambos extremos.
  • Descomprimir con éxito no acredita entrega completa, identidad del par, seguridad ni ejecución de la aplicación.

Una frontera dentro de otra

La trama es lo que la línea transporta; el paquete original es lo que el receptor debe reconstruir. FZA no obliga a que sus límites coincidan. Los datos comprimidos pueden incluir uno o más paquetes PPP encapsulados. Si la representación de uno solo supera la MRU del enlace remoto, continúa en la trama siguiente. El flujo contiene su propia señal de fin de paquete original.

Así aparecen tres finales distintos: el de una trama física, el de un paquete original y el de una historia de compresión. El primero puede ocurrir antes que el segundo; el tercero puede seguir vivo después de ambos. Un analizador que use el final de trama como sustituto del final de paquete contará objetos equivocados.

Los valores PPP 0x00FD y 0x00FB distinguen Compressed Datagram y Link Compressed Datagram. 0x00FB sitúa la compresión fuera de PPP Multilink para mantener contextos por enlace físico. El registro IANA certifica la asignación de esos números y de la opción FZA 19. No certifica un despliegue actual, el estado del historial ni quién está al otro extremo.

Pagar bytes para no perder el idioma común

No toda entrada se reduce. RFC 1993 indica que FZA puede expandir como máximo dos a uno y que los datos ya comprimidos suelen crecer alrededor de 1,01 a uno. Aun así, la salida expandida se transmite.

La aparente ineficiencia evita un fallo mayor. La historia de compresión es un estado compartido: emisor y receptor deben incorporar la misma secuencia, en el mismo orden. Si el emisor saltara una salida que no ahorra espacio, su historia cambiaría sin que el receptor pudiera acompañarla. Las referencias posteriores apuntarían a contenidos diferentes. Los bytes adicionales compran continuidad semántica para el resto del flujo.

Cuando esa salida no cabe en la MRU, se reparte entre tramas. La señal interna de final conserva el paquete original aunque el contenedor cambie. RFC 1993 no ofrece aquí un bypass de datos nativos; preservar la historia tiene prioridad sobre el beneficio instantáneo de un paquete.

El relleno que se explica a sí mismo

Una secuencia comprimida que llega al final de una trama necesita separar datos y relleno. Por eso RFC 1993 exige negociar Self-Describing-Padding, definido en RFC 1570, durante el establecimiento LCP. Cada octeto de relleno lleva su posición; en una cola de tres octetos aparecen 1, 2 y 3, y el último valor indica cuántos retirar. Si el último octeto real pudiera confundirse con esa longitud, el emisor añade relleno.

El procedimiento elimina una ambigüedad de cola. No prueba autenticidad ni integridad de extremo a extremo. Un índice incorrecto puede justificar descartar la trama en silencio, pero uno correcto solo dice que el sufijo se pudo interpretar. No dice quién lo produjo ni qué ocurrió después.

Una dependencia situada debajo

RFC 1993 espera una entrega fiable y en secuencia. FZA consume esa propiedad; no la genera. RFC 1663 explica el daño que una pérdida causa en un diccionario continuo y describe una transmisión fiable de PPP negociada por separado. Sirve para localizar la dependencia, no para atribuir su mecanismo a RFC 1993.

Por eso las pruebas forman una escalera. El protocolo exterior prueba la clase de encapsulación. El relleno válido prueba que la cola puede retirarse. La descompresión prueba que el decodificador procesó lo recibido. Hace falta evidencia del enlace para acreditar que llegaron todas las tramas necesarias y en orden; evidencia de PPP para acreditar la entrega del paquete reconstruido; y pruebas distintas para identidad, autorización, confidencialidad, protección frente a repetición y resultado de negocio.

RFC 1993 no analiza seguridad. Que hoy no haya erratas registradas tampoco prueba ausencia de defectos o interoperabilidad real. El documento es Informational. Su valor histórico está en mostrar con nitidez que una transformación con estado desplaza la frontera de observación: el sobre físico deja de describir por sí solo el objeto lógico.

El enfoque público de Heng Lu refuerza esta lectura: se debe observar el código en funcionamiento y limitar cada recibo a lo que ve. Un final de trama no puede hablar por el final del paquete; el decodificador no puede hablar por la fiabilidad que presupone; el paquete reconstruido no puede hablar por la aplicación.

Fuentes

Las mecánicas proceden de los RFC y del registro. Los ensayos de Heng Lu declaran el método analítico, no documentan FZA.