[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:40:21 -0800
Cc: ippcp <ippcp@external.cisco.com>, ipsec@lists.tislabs.com
In-Reply-To: <26431.943403028@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:23 AM 11/24/99 +0900, itojun@iijlab.net wrote:

>	So, the negotiated CPI and a CPI on the packet will be different
>	in this case.  Am I right?
>		negotiated CPI: 16-bit value in "negotiated" range (256-61439)
>		algorithm to be used: well-known algorithm X
>		CPI on packet: X

No, the negotiated CPI is the CPI used on the packet header:

    Compression Parameter Index (CPI)
        [...]
                                                                         The outbound IPComp
        header MUST use the CPI value chosen by the decompressing node.

That CPI MAY negotiated to be in the well-known range if, for example, 
the host supports just a single algorithm. Another scenario -- 
the host sends two IPComp proposals, each with a single transport
and the CPI equals that transform-ID.

>	I may need a more explicit wording here.

I'll try and add some clarifications to version -02 of the draft.

avram

References:

Re: IPComp rfc2393bis-00

From: itojun@iijlab.net

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