[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Placement of IPCOMP header in IPSEC Tunnel mode
I believe the new draft removes this confusion. See section 2.1.
http://search.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-01.txt
Regards,
-Bob
----------------------------------
Bob Monsour
Hi/fn, Inc.
750 University Avenue
Los Gatos, CA 95032
bmonsour@hifn.com
408-399-3539 tel
408-399-3501 fax
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Strahm, Bill
> Sent: Wednesday, November 17, 1999 1:32 PM
> To: ipsec@lists.tislabs.com
> Subject: Placement of IPCOMP header in IPSEC Tunnel mode
>
>
> I am confused about the placement of the IPComp header when
> used in Tunnel
> mode.
>
> >From RFC 2393 Section 2.1
> In IP version 4 [RFC-0791], the compression is applied to the upper
> layer protocol (ULP) payload of the IP datagram. No portion of the
> IP header or the IP header options is compressed.
>
> Now in Tunnel mode I am building an IP packet that looks like this
>
> IP(outer)- IPSEC transform - IP(inner) - data
>
> I am convinced that the correct placement of a tunnel mode compression
> header is
>
> IP(outer) - IPSEC transform - IPCOMP - IP(inner) - data
>
> However from section 2.1 I can see a reading that says I am
> not to compress
> the IP header or options, so a packet would be built like this
>
> IP(outer) - IPSEC transform - IP(inner) - IPCOMP - data
>
> If this later packet is correct I would have a hard time
> determining if I
> should unapply compression at the gateway or the end host.
>
> Can I get some clarification on this point please ?
>
> Bill
>
> ______________________________________________
> Bill Strahm Programming today is a race between
> bill.strahm@ software engineers striving to build
> intel.com bigger and better idiot-proof programs,
> (503) 264-4632 and the Universe trying to produce
> bigger and better idiots. So far, the
> Universe is winning.--Rich Cook
> I am not speaking for Intel. And Intel rarely speaks for me
>
>