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

Re: Proposal for IP Peer protocol

To: John Shriver <jas@shiva.com>
Subject: Re: Proposal for IP Peer protocol
From: Gabriel Montenegro <gab@Eng.Sun.Com>
Date: Wed, 9 Jun 1999 09:59:23 -0700 (PDT)
Cc: Stephen.Waters@cabletron.com, pkoning@xedia.com, ipsec@lists.tislabs.com, ippcp@external.cisco.com
In-Reply-To: "Your message with ID" <199906091612.MAA17182@brill.shiva.com>
Reply-To: Gabriel Montenegro <gab@Eng.Sun.Com>
Sender: owner-ipsec@lists.tislabs.com

> The Van Jacobsen header compression relies on two things that PPP
> provides and IPsec "tunnels" don't provide:
> 
> 1. Freedom from reordering of packets.  (The anti-replay field is not
> normally used to prevent reordering.)
> 
> 2. The receiver gets information about lost (bad CRC) frames.  (This
> is more of a hint, but still important.)
> 
> Thus, the VJ compression relies very strongly on these characteristics
> of PPP.  By the time you provide the same QoS in IPsec, you will be
> close to re-inventing TCP.

use header compression as per ftp://ftp.isi.edu/in-notes/rfc2507.txt
(see section 7.10 - Encapsulating Security Payload Header)

References:

Re: Proposal for IP Peer protocol

From: John Shriver <jas@shiva.com>

Prev by Date: Re: Proposal for IP Peer protocol
Next by Date: Re: Proposal for IP Peer protocol
Prev by thread: Re: Proposal for IP Peer protocol
Next by thread: RE: Proposal for IP Peer protocol
Index(es):
- Main
- Thread