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
Attachment:
ipcomp
Description: Binary data