Resumen

  • En los campos heredados TCP_SPACE y NON_TCP_SPACE de RFC 2509, cero era el identificador de contexto máximo; el CID 0 seguía siendo un contexto disponible.
  • La subopción 3 de tres octetos permitía a RFC 3544 fijar explícitamente en cero los contextos TCP o no TCP, y desactivar así esa clase.

La confusión nace del nombre. TCP_SPACE y NON_TCP_SPACE no contaban contextos: indicaban el valor máximo de sus identificadores. Con un máximo igual a cero, el espacio aún incluía el CID 0. Eso podía servir para una configuración mínima, pero los campos por sí solos no expresaban «no comprimas esta familia de paquetes».

Publicada en julio de 2003 como Proposed Standard, RFC 3544 revisó la opción de negociación PPP de RFC 2509 sin cambiar el significado heredado. Su subopción 3 añadió la distinción que faltaba: tipo 3, longitud 3 octetos y un parámetro de un octeto. El valor 1 significa cero contextos TCP; el 2, cero contextos no TCP. La subopción sustituye el valor correspondiente de TCP_SPACE o NON_TCP_SPACE. Si aparecen ambas variantes, la compresión queda desactivada para todos los paquetes.

Es una reparación compatible mediante una excepción explícita, no una reinterpretación de cero. Los campos antiguos conservan su sentido y una señal adicional transporta la intención que no podían codificar. Cambiar el significado de los bits habría obligado a pares antiguos y nuevos a discrepar sobre el mismo valor.

La configuración pasa por dos NCP

PPP negocia parámetros del enlace mediante protocolos de control de red. RFC 3544 define el mismo formato de opción para IPCP en IPv4 e IPV6CP en IPv6. Cada negociación configura los paquetes cuya cabecera de red exterior corresponde a esa versión. Que se negocie compresión IPv4 y que se negocie compresión IPv6 son resultados distintos del plano de control, no un interruptor único.

Hay otra sutileza: IPv4 e IPv6 comparten el espacio de identificadores de contexto aunque negocien sus valores por separado. Si los límites difieren, el compresor debe asignar desde un conjunto común y el descompresor debe consultar el estado del contexto para interpretar el paquete. TCP y el grupo no-TCP/UDP/RTP, en cambio, no comparten ese espacio. Son restricciones que define el protocolo, no una prueba de que un par concreto las configurara o utilizara.

RFC 3544 también añadió la subopción RTP mejorada de tipo 2, que se negocia en lugar de la subopción RTP 1, no junto con ella. Con los nueve valores del campo de protocolo PPP, esas opciones indican al receptor cómo clasificar una trama y qué formatos negociados puede usar. El campo de protocolo sirve para demultiplexar; la subopción expresa intención de configuración.

La opción negociada no prueba el recorrido

Tras una negociación satisfactoria, la opción habilita determinados identificadores de protocolo. Eso no demuestra que una implementación enviara tramas comprimidas, que el extremo remoto las decodificara, que se entregara el datagrama o que este fuera más pequeño. Son observaciones distintas en puntos diferentes del trayecto. El intercambio de configuración acredita parámetros acordados, no la recepción de tráfico.

El propio RFC advierte de una ambigüedad próxima: RFC 1332 no dice si la opción describe la capacidad del emisor o la del receptor. RFC 3544 dice que, siguiendo la práctica vigente, supone que una Config-Req describe el descompresor del par que la envía. Es una suposición declarada, no una aclaración normativa de RFC 1332. Afirmar más borraría la cautela del texto.

El plano de datos añade otra condición. IPHC emplea codificación diferencial para TCP y RTP; los paquetes dependen entonces del contexto en ambos extremos. PPP no reordena paquetes, por lo que las protecciones contra ese fenómeno se desactivan por defecto. Si se usa Multilink PPP multiclas o algún mecanismo que sí reordena, los paquetes que comparten contexto deben conservar el orden. Negociar un formato no elimina esa restricción de transporte.

La lección histórica es acotada: a veces la evolución de un protocolo requiere una segunda señal porque el valor intuitivo ya tiene un significado válido. RFC 3544 mantuvo estable el campo, añadió una excepción expresa y dejó la capacidad, el envío, la decodificación, la entrega y el rendimiento como hechos separados que deben verificarse.

Fuentes