["J. Holmes" <iamholmes@xxxxxxxxx>]

Jaap,

        The cisco pkts in the trace I sent would be from the Cisco switch 
that is part of the setup. The units that do the IPCOMP compression / 
decompression are not Cisco units.

Clearly there is no IPv6 here. So my guess is that either :
1. These IPCOMP boxes don't strictly follow the IETF's standard which is
    why its messing up the Ethereal's IPCOMP dissector.
2. There might be an error in the dissector itself. If I'm reading the RFC
    correctly, for IPv4 pkts, it should the IPCOMP header should includes
    the "protocol" field from the IP header. The IPv6 next-hop is only for
    IPv6 networks.

Finally, I still cannot for the life of me figure out how pkts can reach 
their destination, when the destination IP address is the remote IPCOMP
unit. Can someone please explain this one ?
        
Thanks !

JH

On 12/25/05, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:

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
> >

_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users