[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPComp rfc2393bis-00

To: itojun@iijlab.net
Subject: Re: IPComp rfc2393bis-00
From: Avram Shacham <shacham@cisco.com>
Date: Tue, 23 Nov 1999 16:55:06 -0800
Cc: ippcp <ippcp@external.cisco.com>, ipsec@lists.tislabs.com
In-Reply-To: <26542.943403433@coconut.itojun.org>
References: <shacham's message of Tue, 23 Nov 1999 16:12:53 PST. <199911240012.QAA06259@honeybee.cisco.com>
Sender: owner-ipsec@lists.tislabs.com

At 09:30 AM 11/24/99 +0900, itojun@iijlab.net wrote:

>>There is a second use - to save the CPU cycles of the 
>>CPI-to-algorithm conversion, even when the algorithm is negotiated
>>dynamically. That is the rationale for the note in the CPI definition:

>	BTW If you use this optimization, the negotiated IPComp association
>	will never get expired if it uses bytecount as expiration signal.

IPComp Association expiration -- by byte-count or time -- is not 
defined in rfc2393bis. If an implementation elects to negotiate byte-count
via IKE, it needs to visit the IPCA for each packet, and therefore 
a CPI in the upper range may be more adequate. 

otoh, the CPI definition also includes:

        The CPI in combination with the destination IP address uniquely
        identifies the compression algorithm characteristics for the
        datagram.

So, implementations may locate the IPCA by IP-addr+CPI, and
do more bookkeeping, such as expiration by byte-count.

avram

References:

Re: IPComp rfc2393bis-00

From: itojun@iijlab.net

Prev by Date: Re: Phase 1 Re-keying Implementation Identification
Next by Date: Re: Phase 1 Re-keying Implementation Identification
Prev by thread: Re: IPComp rfc2393bis-00
Next by thread: IPComp rfc2393bis-00
Index(es):
- Main
- Thread