Hi,
This is what I get on the first packet (the others are similar)
IP Payload Compression
Next Header: IPv6 hop-by-hop option (0x00)
Flags: 0x46
CPI: Unknown (0x01cc)
Data (574 bytes)
So, there's IPv6 in the game??
Why is flags != 0? According to the RFC it has to be 0.
Why is the CPI changing with every packet?
I guess this is some sort of Cisco proprietary tunnel protocol
using IPcomp.
Thanx,
Jaap
On Sat, 24 Dec 2005, J. Holmes wrote:
> Jaap,
>
> Thanks for the reply. I've attached the IPCOMP trace. The IP addresses
> 10.1.1.9 and 20.1.1.9 are the IP addresses of the units that do IPCOMP
> compression. The ftp client and server IP addresses are 10.1.1.2/24 and
> 20.1.1.8/24 if I remember correctly.
>
> Now I understand that there's got to be some way to inform pkts that have
> been compressed, that they need to go to the remote IPCOMP unit to be
> decompressed before going off to their destination.
>
> How this is done when you have only the destination IP address as the
> remote IPCOMP unit, I have no clue.
>
> On 12/24/05, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
> >
> > On Sat, 24 Dec 2005, J. Holmes wrote:
> >
> > > Hi all -
> > >
> > > Firstly, this isn't an Ethereal question per se. Its an
> > observation
> > > I made
> > > when using Ethereal. However, I'm certain that there are some networking
> > > protocol gurus (Guy and co.) that can explain some of these questions.
> > >
> > > I have a simple setup with two boxes that do IPCOMP
> > > compression connected as in th ASCII diagram below :
> > >
> > > LAN a -- CPR --- router --(simulated WAN)--- router -- hub -- CPR --
> > LAN b
> > >
> > > I did an FTP transfer from a PC in LAN a to a PC in Lan b. Now when I
> > sniffed the
> > > IPCOMP pkts using Ethereal, I found that the source and destination IP
> > addresses
> > > had changed to the local and remote IPCOMP compression units' IP
> > addresses
> > > respectively.
> > >
> > > I'm confused.
> > >
> > > 1. How does the remote IPCOMP compression unit know whom to send
> > > the pkts to ? (Given that the dest. IP address is the remote IPCOMP
> > > decompressor, and not the original destination -- the FTP
> > > server/client).
> > > 2. The RFC doesn't indicate that the source or destination IP address
> > should
> > > be changed. What am I not understanding here ?
> >
> > Both are strange indeed. Maybe you can post a small sample trace for
> > everyone to look at.
> >
> > > 3. The header for the IPCOMP includes the protocol field from the IP
> > header.
> > > Why would you have the protocol field from the IP header. This part
> > of
> > > the IP header is left intact, and not compressed. Isn't this
> > redundant ?
> >
> > If you look closely you find that in the IP header TCP (6) is replaced by
> > IPComp (108). The RFC says that the transform looks like this:
> >
> > IPv4-Header Payload -->
> >
> > IPv4-Header IPComp-Header Compressed(Payload) -->
> >
> > IPv4-Header Payload
> >
> >
> > Now in order get to the Compressed(Payload) the outer header (in this case
> > IPv4) needs to indicate the next level protocol, which is IPComp. The
> > IPComp header need to indicate what protocol the payload is carrying so
> > it can put that into the reconstructed IPv4 Header
> >
> > > Many thanks for any replies.
> >
> > Hope it helps
> > Jaap
> >