Xref: utzoo comp.dcom.lans:8004 comp.sys.novell:1423 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!bonnie.concordia.ca!s3!cayer From: cayer@ireq.hydro.qc.ca (Cayer) Newsgroups: comp.dcom.lans,comp.sys.novell Subject: IPX Encapsulation over Ethernet Message-ID: <6843@s3.ireq.hydro.qc.ca> Date: 7 May 91 20:16:28 GMT Sender: usenet@s3.ireq.hydro.qc.ca Reply-To: cayer@ireq.hydro.qc.ca () Organization: IREQ, Hydro-Quebec, QC, Canada Lines: 44 Using my sniffer, I have noticed the following encapsulation of the IPX protocol over ethernet: destination source length ... 6 bytes 6 2 . MAC . layer ... checksum length transport type ... 2 2 1 1 . IPX . layer destination network node socket . 4 6 2 . . source network node socket . 4 6 2 . ... ... data . Upper ... layer The third field of the MAC layer is a length field and not a type field as in ethernet V.2. But, this is not IEEE 802.3 either since there is not an IEEE 802.2 layer above the MAC layer. The IPX packet is directly over the MAC layer. I think that this does not respect either ethernet nor IEEE 802.3 encoding. Can this cause problems inside a multi-protocols network (ipx, decnet, tcp/ip, ...) ? I have heard that other forms of encapsulation do exist. So, I would appreciate if someone could tell me what are those other encapsulations, and why/when to use them. Thanks. -- Andre Cayer cayer@ireq.hydro.qc.ca