[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Deflate issue
I'll add whatever needed wording to the RFC. I'd like to know how many
vendors implemented this feature and have we seen successful
interoperability.
-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Slava Kavsan
Sent: Friday, January 14, 2000 10:32 AM
To: ipsec@lists.tislabs.com
Subject: Deflate issue
We discovered some Deflate implementation differences that control the
inclusion of the Deflate
header and Adler32 checksum. RFC2394 makes no mention of the Deflate
header or Adler32 checksum . These items are redundant in the case of
IPCOMP.
It doesn't make sense to spend the time to do it as it uses bandwidth
unnecessarily for the extra
(8?) bytes.
Unfortunately, the ability to NOT include the Deflate header and Adler32
checksum is an undocumented feature of the ZLIB implementation of
Deflate,
which is controlled by the -15 parameter to the deflateInit2_()
Sooooo... should the inclusion of the extra header and the checksum be
controlled by another IPCOMP attribute or should we simply all change
the way Deflate engine is initialized from:
if (Z_OK != deflateInit(&c_stream, Z_DEFAULT_COMPRESSION)) break;
to:
if (Z_OK != deflateInit2_(&c_stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED,
-11,
DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY, ZLIB_VERSION, sizeof(z_stream)))
break;
And similar for Inflate, from:
if (Z_OK != inflateInit(&d_stream)) break;
to:
if (Z_OK != inflateInit2_(&d_stream, -15, ZLIB_VERSION,
sizeof(z_stream))) break;
References: