Resumo

  • Cada datagrama IP é comprimido e descomprimido de forma independente e sem perda; o receptor precisa aceitar simultaneamente formas comprimidas e originais.
  • Se a carga comprimida somada ao cabeçalho IPComp de quatro octetos não for menor, o emissor deve enviar a forma original e não pode acrescentar o cabeçalho.
  • CPI é um índice direcional escolhido pelo descompressor e interpretado com o destino. Não é credencial, chave, identidade global do algoritmo nem prova de benefício.

O pacote sem marca podia estar certo

Configuração e captura costumam ser lidas como causa e efeito: a função foi negociada, então sua marca deveria aparecer. IPComp recusou essa equivalência. A associação ensinava o receptor a entender uma forma comprimida; cada entrada decidia se produzir essa forma fazia sentido.

Dados repetitivos encolhem. Um controle curto pode crescer. Conteúdo já comprimido pode apenas consumir processador. O acordo não conhece os bytes futuros, portanto não pode transformar uma capacidade em ordem permanente.

O número de protocolo 108 identifica um pacote que declara IPComp naquele ponto. A falta de 108 em um único pacote não demonstra ausência da associação. Pode ser exatamente a decisão exigida pela política de não expansão.

A estrutura precisava ser removida antes da cifra

O RFC 2393 introduziu o protocolo em 1998 perto do IPsec. Depois da criptografia, os dados parecem aleatórios e a redundância útil desaparece para camadas inferiores. Comprimir precisa vir antes de autenticar ou cifrar, e antes de fragmentar.

Na recepção, a ordem respeita as fronteiras inversas: reassemblagem e segurança IP terminam antes da descompressão. O compressor vê a carga original; o descompressor só atua depois que a proteção externa autentica e decifra.

O cabeçalho IPv4 externo não é comprimido. Em túnel, o cabeçalho IP interno faz parte da carga externa. No IPv6, opções que o caminho precisa examinar ficam visíveis; Fragment Header precede IPComp quando ambos existem.

O estado não atravessa datagramas. Cada pacote precisa conter um resultado que possa ser restaurado sozinho, porque o anterior pode chegar depois ou nunca. A arquitetura troca possíveis ganhos de dicionário por robustez diante do comportamento normal do IP.

A soma completa decidia

O RFC 3173 não compara somente as cargas. Soma quatro octetos de IPComp ao resultado. Se o total não for menor, a forma original vai ao fio sem cabeçalho adicional.

Isso evita descompressão inútil e evita que um pacote que cabia na MTU passe a fragmentar por causa da otimização. Comprimir não recebe licença para piorar o tamanho.

Há atalhos locais. Um limite pode dispensar pacotes pequenos. Falhas consecutivas podem suspender tentativas por algum tempo. Um teste de compressibilidade pode encerrar cedo. Os valores desses contadores não são parte do protocolo comum.

No caso de DEFLATE, o RFC 2394 recomenda não tentar buffers abaixo de 90 bytes, com base em testes informais. O número não é um limite universal. Outro transform, CPU, enlace ou tráfego pode exigir outra decisão.

Assim, um pacote original pode representar limite, pausa adaptativa, detecção de incompressibilidade ou comparação final sem economia. O resultado comprimido mostra redução de bytes, não prova menor latência nem ganho econômico. O IPComp garante reconstrução sem perda e não expansão no fio; não garante desempenho.

O CPI pertencia ao caminho de volta

Quando há ganho, Protocol ou Next Header vira 108. O cabeçalho curto guarda o Next Header original, Flags reservado e CPI. O receptor descomprime, remove IPComp e restaura a seleção original.

As faixas de CPI distinguem transforms conhecidos, valores negociados e uso privado. Mas o número é local: cada nó escolhe de forma independente o CPI que quer receber, e o emissor usa o valor do descompressor. CPI mais endereço de destino encontra as características do datagrama.

Reusar um CPI conhecido em várias sessões pode tornar ambíguos vida útil e contadores. Por isso o RFC 3173 prefere a faixa negociada quando unicidade é necessária. CPI localiza um contexto; não comprova quem tem direito a ele.

Sem algoritmo padrão

Uma IPCA contém CPI, modo, algoritmo e parâmetros. Pode cobrir todos os pacotes entre os nós ou sessões selecionadas. As direções podem escolher transforms diferentes.

Não há algoritmo padrão nem algoritmo obrigatório para toda implementação IPComp. Não se pode inferir DEFLATE apenas pelo nome do protocolo. A escolha comum deve ser explícita.

O RFC 3173 substituiu o documento original sobretudo para esclarecer IKE. No IKEv2, o pedido pode oferecer vários algoritmos e a resposta aceita no máximo um. É proibido usar um transform não proposto e aceito.

A associação virtual de compressão não vive fora da Child SA ESP/AH e desaparece com ela. Ainda assim, negociar compressão continua separado de negociar criptografia. Compartilhar ciclo de vida não transforma CPI em chave ou prova de integridade.

Economizar bytes alterava a inspeção

Sem IPsec, um dispositivo de borda pode perder campos usados para filtragem ou contabilidade. O Protocol original muda de posição e portas ficam comprimidas. Sem a associação, o intermediário não recupera esses campos como antes.

Isso não é sigilo. É falta de contexto de análise. Se todos os pacotes precisam ser filtrados ou contados, o RFC 3173 exige comunicação segura da associação ao filtro.

O registro operacional deve separar política configurada, acordo aceito, tentativa, forma emitida, busca de CPI e restauração. “Compressão ligada” não prova nenhuma etapa inteira.

O legado do IPComp foi subordinar a otimização ao objeto real. A especificação comum preparou a cooperação. O datagrama preservou a liberdade de concluir que, naquela vez, quatro octetos eram caros demais.

Fontes