2.22. IPComp

2.22. IPComp

L'uso della compressione IP [IP-COMP] può essere negoziato nella creazione di una Child SA. La compressione IP aggiunge un header extra e un CPI per pacchetto; l'«associazione di compressione» virtuale non ha vita al di fuori della SA ESP o AH che la contiene e scompare con essa, senza menzione esplicita in Delete.

La negoziazione IPComp è separata dai parametri crittografici. Un nodo che richiede una Child SA PUÒ annunciare uno o più algoritmi tramite Notify IPCOMP_SUPPORTED, solo in messaggi con payload SA che negozia Child SA. La risposta PUÒ accettare un algoritmo con una IPCOMP_SUPPORTED. Questi payload NON DEVONO comparire senza payload SA.

I dati associati: due ottetti CPI IPComp, un ottetto Transform ID, attributi opzionali. Più IPCOMP_SUPPORTED nella proposta; al massimo una nell'accettazione.

Name	Number	Defined In
IPCOMP_OUI	1	(UNSPECIFIED)
IPCOMP_DEFLATE	2	RFC 2394
IPCOMP_LZS	3	RFC 2395
IPCOMP_LZJH	4	RFC 3051

Valori aggiornati in [IKEV2IANA].

Le implementazioni di questa specifica NON DEVONO accettare algoritmi IPComp non proposti, non più di uno, né comprimere con algoritmo diverso da quello proposto e accettato.

Effetto collaterale: non si possono proporre più suite crittografiche con IPComp solo su alcune.

In alcuni casi ROHC è più appropriato. [ROHCV2] definisce ROHC con IKEv2 e IPsec.