2.22. IPComp
2.22. IPComp
可在建立 Child SA 时协商使用 IP 压缩 (IP Compression) [IP-COMP]. 虽然 IP 压缩在每个分组中增加额外首部与压缩参数索引 (compression parameter index, CPI), 虚拟的 "压缩关联 (compression association)" 仅存在于包含它的 ESP 或 AH SA 之内. 对应 ESP 或 AH SA 消失时压缩关联即消失, 不会在任意 Delete 载荷中显式提及.
IP 压缩的协商与 Child SA 相关密码参数的协商相互独立. 请求 Child SA 的节点可以通过一个或多个类型为 IPCOMP_SUPPORTED 的 Notify 载荷通告其支持的一种或多种压缩算法. 该 Notify 消息只能包含在协商 Child SA 且含 SA 载荷的消息中, 表示发送方愿意在此 SA 上使用 IPComp. 响应可以通过单个类型为 IPCOMP_SUPPORTED 的 Notify 载荷表示接受一种压缩算法. 这些载荷不得出现在不含 SA 载荷的消息中.
与此 Notify 消息关联的数据包括两八位组 IPComp CPI, 后跟一字节 Transform ID, 可选地再跟由该 Transform ID 定义长度与格式的属性. 提议 SA 的消息可含多个 IPCOMP_SUPPORTED 通知以表示多种支持的算法. 接受 SA 的消息最多可含一个.
Transform ID 列表如下. 下表数值仅截至 RFC 4306 发布时有效. 此后可能已增加或将在本文档发布后增加. 读者应查阅 [IKEV2IANA] 获取最新值.
| Name | Number | Defined In |
|---|---|---|
| IPCOMP_OUI | 1 | (UNSPECIFIED) |
| IPCOMP_DEFLATE | 2 | RFC 2394 |
| IPCOMP_LZS | 3 | RFC 2395 |
| IPCOMP_LZJH | 4 | RFC 3051 |
虽已讨论过允许接受多种压缩算法以及 Child SA 两个方向使用不同算法, 但本规范的实现不得接受未被提议的 IPComp 算法, 不得接受多于一种, 且不得使用除 Child SA 建立时所提议并接受以外的算法进行压缩.
将 IPComp 协商与密码参数协商分离的副作用是无法同时提议多种密码套件且仅对其中部分提议 IP 压缩.
某些情况下, Robust Header Compression (ROHC, 健壮头压缩) 可能比 IP 压缩更合适. [ROHCV2] 定义了 ROHC 与 IKEv2 及 IPsec 的用法.