2.22. IPComp

2.22. IPComp

[IP-COMP] 中定义的 IP 压缩 (IP Compression) 的使用, 可以作为建立 Child SA 的一部分协商。虽然 IP 压缩在每个数据包中涉及一个额外的头部和一个压缩参数索引 (CPI), 但这个虚拟的 "压缩关联" 在包含它的 ESP 或 AH SA 之外没有生命。当相应的 ESP 或 AH SA 消失时, 压缩关联也随之消失。它没有明确在任何 Delete 载荷中提到。

IP 压缩的协商独立于与 Child SA 相关的密码学参数的协商。请求 Child SA 的节点可以 (MAY) 通过一个或多个类型为 IPCOMP_SUPPORTED 的 Notify 载荷, 通告它对一个或多个压缩算法的支持。这个 Notify 消息只能包含在包含协商 Child SA 的 SA 载荷的消息中, 并且表示其发送方愿意在此 SA 上使用 IPComp。响应可以 (MAY) 通过一个类型为 IPCOMP_SUPPORTED 的 Notify 载荷, 指示对单个压缩算法的接受。这些载荷必须 (MUST NOT) 出现在不包含 SA 载荷的消息中。

与此 Notify 消息关联的数据包括一个两八字节的 IPComp CPI, 后跟一个一字节的变换 ID, 并可选择后跟由该变换 ID 定义其长度和格式的属性。提议 SA 的消息可以包含多个 IPCOMP_SUPPORTED 通知, 以指示多个受支持的算法。接受 SA 的消息最多只能包含一个。

变换 ID 列在下面。下表中数值仅相对于 RFC 4306 的发布日期为当前值。此后可能已添加或将在本文档发布后添加其他值。读者应参考 [IKEV2IANA] 获取最新值。

名称 编号 定义于

IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 IPCOMP_LZJH 4 RFC 3051

尽管已有关于允许多个压缩算法被接受, 以及为 Child SA 的两个方向提供不同压缩算法的讨论, 但本规范的实现必须 (MUST NOT) 接受未被提议的 IPComp 算法, 必须 (MUST NOT) 接受多于一个, 并且必须 (MUST NOT) 使用除在 Child SA 建立中提议并被接受的算法之外的算法进行压缩。

将 IPComp 的协商与密码学参数分离的一个副作用是, 不可能提议多个密码学套件, 并且提议其中某些带 IP 压缩而另一些不带。

在某些情况下, 健壮头压缩 (ROHC) 可能比 IP 压缩更合适。 [ROHCV2] 定义了 ROHC 与 IKEv2 和 IPsec 的使用。