Resumen

  • La compresión de IPComp es sin pérdida, independiente por datagrama y compatible con pérdida o reordenamiento; el receptor debe admitir simultáneamente paquetes comprimidos y originales.
  • La política de no expansión obliga a omitir IPComp cuando la carga comprimida más sus cuatro octetos no reduce el tamaño original. Un paquete sin protocolo 108 puede ser el resultado correcto de una asociación activa.
  • CPI es una referencia local y direccional elegida por quien descomprime. No autentica, no cifra y no demuestra por sí sola qué algoritmo fue aceptado o si la optimización produjo beneficio neto.

El éxito también podía no dejar marca

En muchas negociaciones, aceptar una función parece implicar que su marca aparecerá siempre. IPComp diseñó otra relación. La asociación prepara al receptor para una forma comprimida; el emisor decide con los bytes concretos si vale la pena producirla.

Una secuencia repetitiva puede reducirse con facilidad. Un datagrama corto puede crecer por el coste fijo. Un vídeo, archivo o cuerpo ya comprimido puede resistir un segundo intento. Ninguna bandera de configuración puede anticipar todos esos casos. Por eso el contrato común no obliga al resultado: obliga a que el receptor entienda ambas formas.

La captura que muestra 108 demuestra una declaración IPComp en ese punto. La captura que no lo muestra no revela si faltó negociación. La omisión puede ser una decisión normativa, y ese detalle cambia cómo se investigan alarmas y métricas.

Antes de cifrar; antes de fragmentar

RFC 2393 publicó IPComp en 1998 con una motivación directa: cifrar primero elimina gran parte de la estructura que un compresor podría aprovechar. Cuando se desean ambos procesos, la compresión debe ejecutarse antes del cifrado.

El orden de salida es compresión, procesamiento de seguridad IP y fragmentación. El orden de entrada se invierte en las fronteras pertinentes: primero reensamblado y autenticación o descifrado, después descompresión. La capa de compresión no sustituye la seguridad; trabaja con la carga antes de que la seguridad la vuelva opaca.

En IPv4, la cabecera exterior y sus opciones quedan fuera. En modo túnel, la cabecera IP interior forma parte de la carga exterior y puede comprimirse. En IPv6 se preservan las cabeceras que deben examinar nodos del camino. Si aparecen Fragment Header e IPComp, el primero va antes.

La reconstrucción es autónoma para cada datagrama. No existe un diccionario de flujo que convierta la pérdida del paquete anterior en incapacidad para leer el siguiente. Esa decisión reconoce que IP puede perder y reordenar sin pedir permiso a la compresión.

No expandir era más importante que comprimir

RFC 3173 calcula el resultado con toda la sobrecarga. La carga transformada debe ser menor incluso después de sumar la cabecera IPComp de cuatro octetos. Si no lo es, se transmite la forma original y no se añade cabecera.

La norma evita trabajo inútil en el receptor y evita provocar fragmentación cuando una carga que cabía en la MTU crece por culpa de su supuesto ahorro. La optimización no recibe un privilegio para empeorar el objeto que quería mejorar.

Hay decisiones anteriores al intento completo. Los paquetes pequeños pueden quedar debajo de un umbral local. Varios fracasos consecutivos pueden activar un intervalo sin intentos. Una prueba de compresibilidad puede detener el algoritmo antes de terminar. RFC 3173 deja esos contadores y límites a la implementación.

Para DEFLATE, RFC 2394 recomienda no intentar buffers menores de 90 bytes según pruebas informales. No convierte 90 en una ley universal. Es una decisión orientativa para ese transform, no una señal de protocolo ni una prueba de que todos los paquetes mayores ahorrarán bytes.

De ahí surge un problema de evidencia. Un original puede significar umbral, pausa adaptativa, detección temprana o comparación final desfavorable. Un paquete comprimido solo prueba que el resultado cruzó la condición de tamaño. No prueba ahorro de latencia, reducción de congestión ni una relación favorable entre CPU y enlace.

Un índice elegido por quien recibe

Cuando sí hay ahorro, Protocol o Next Header adopta el valor 108. La cabecera IPComp guarda el Next Header anterior, un octeto Flags reservado y el CPI de 16 bits. Tras descomprimir, el receptor elimina esa cabecera y devuelve el selector original para continuar el procesamiento normal.

Las zonas de CPI separan algoritmos conocidos, valores negociados y uso privado. Pero el dato decisivo es direccional: cada nodo elige el CPI que espera recibir, y el emisor utiliza la selección del descompresor. CPI más destino encuentra las características necesarias.

Por ello el número no es una identidad mundial. Repetir un CPI conocido entre varias sesiones puede volver ambiguos atributos como vida útil o contadores adaptativos. RFC 3173 recomienda valores negociados cuando hace falta distinguir asociaciones. El campo localiza contexto; no firma su procedencia.

Negociar compresión no era negociar criptografía

Una IPCA reúne modo, algoritmo, parámetros y CPI. Puede abarcar todos los paquetes entre dos nodos o una selección de sesiones. Cada dirección se acuerda por separado y puede elegir un algoritmo diferente.

No hay algoritmo predeterminado ni transform obligatorio para todas las implementaciones. La palabra IPComp no autoriza a suponer DEFLATE. Debe existir una selección común explícita.

La revisión de 2001 aclaró especialmente IKE. IKEv2 permite ofrecer varios algoritmos, pero acepta como máximo uno. Está prohibido comprimir con uno que no haya sido propuesto y aceptado. La asociación virtual vive dentro de la Child SA ESP o AH correspondiente y desaparece con ella, sin borrado independiente.

La vida compartida no mezcla las funciones. IKEv2 mantiene separada la negociación de IPComp de los parámetros criptográficos. CPI no es una clave y una aceptación de compresión no acredita integridad.

Menos bytes podían significar menos visibilidad

IPComp sin IPsec puede ocultar la posición habitual de campos que un dispositivo fronterizo usa para filtrar o contabilizar. El Protocol original se mueve a la cabecera IPComp; puertos y otras cabeceras de transporte quedan comprimidos. Un filtro sin la asociación no dispone del contexto para recuperarlos.

Eso no es confidencialidad. Es una pérdida de capacidad de análisis para un tercero. Si todos los paquetes deben ser filtrados o contabilizados, la asociación relevante debe comunicarse de forma segura al dispositivo que aplica esa política.

La observación útil separa configuración, aceptación, intento, forma emitida, búsqueda de CPI y reconstrucción. Reducirlas a «compresión habilitada» borra la decisión más interesante del protocolo: una capacidad común podía ejecutarse cero veces en una serie y seguir funcionando exactamente como fue diseñada.

IPComp dejó una regla sobria para la historia de Internet. El estándar fija el mínimo necesario para cooperar. El código local conserva las decisiones futuras, y los bytes reales pueden negar que una optimización merezca aparecer.

Fuentes