[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rfc2393bis
Rafal,
You may set your SPI to be one of the well-known CPI values, if it is
legitimate to express your example as two proposals --
Proposal #1 PROTO=PROTO_IPCOMP, SPI size=2 (octets), SPI=IPCOMP_DEFLATE
transform #1, transform_id IPCOMP_DEFLATE
Proposal #2 PROTO=PROTO_IPCOMP, SPI size=2 (octets), SPI=IPCOMP_LZS
transform #1, transform_id IPCOMP_LZS,
I couldn't locate where rfc2408 prohibits the above, but I might have
simply missed something.
In any case, when the original proposal contains more than one
compression transform, the SPI (CPI) has to be in the negotiated range,
and, in that scenario, the extra step of converting the CPI to the actual
algorithm-id is required. The responder may still use the well-known
value as its CPI.
avram
At 02:42 PM 9/23/99 -0400, Rafal Boni wrote:
>Abraham Shacham wrote:
>> 3.2 CPI in SPI field of a proposal; two-octet field as SHOULD,
>> and a MAY for 4-octet field; the location of the 16-bit CPI in
>> a 4-octet field; plus, a MUST for the receiver to process both
>> field sizes.
>
>If as the initiator, I'm proposing (for example),
> Proposal #1 PROTO=PROTO_IPCOMP, SPI size=2 (octets), SPI=??
> transform #1, transform_id IPCOMP_DEFLATE
> transform #2, transform_id IPCOMP_LZS,
>
>what do I send in the SPI field? I thought the point here was to
>send the "well known" CPI for one of the transforms I propose (which
>would work if there were only one transform), but since I'm proposing
>one or the other, am I basically restricted to using the 256-61439
>range of CPIs in this case?
>
>Thanks!
>--rafal
References: