Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site cheviot.uucp Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!seismo!mcvax!ukc!cheviot!robert From: robert@cheviot.uucp (Robert Stroud) Newsgroups: net.dcom,net.lan Subject: Re: TCP/IP and XNS compatibility ? Message-ID: <456@cheviot.uucp> Date: Thu, 10-Oct-85 11:10:11 EDT Article-I.D.: cheviot.456 Posted: Thu Oct 10 11:10:11 1985 Date-Received: Sat, 12-Oct-85 07:30:08 EDT References: <151@ecrcvax.UUCP> <340@tove.UUCP> Reply-To: robert@cheviot.UUCP (Robert Stroud) Organization: U. of Newcastle upon Tyne, U.K. Lines: 79 Xref: linus net.dcom:1174 net.lan:934 In article <340@tove.UUCP> mark@tove.UUCP (Mark Weiser) writes: >Maryland, Cornell, and Berkeley all have Dandelions, Vaxes, Suns, >etc. on the same ethernet cable talking mixtures of XNS and TCP/IP >betwixt themselves. All works well. The business about the >Dandelion's using a slightly different ethernet spec makes a (hardware >only) difference with which tranceivers will work with which ethernet >boards, but has nothing to do with the levels of protocol above >raw etherpackets. OK so far... > >(Well, is there is the funny business of TCP/IP using the XNS type >field as a length field, but this is gotten around by XNS reserving >all types which are valid TCP/IP lengths). > -mark >-- Oh dear! If this is true, things are worse than I thought!! But I think Mark is getting confused with the IEEE 802 world here. Let me explain my understanding of the situation: XNS, TCP/IP and other protocol families (DECNET?) are media independent. However, they need some kind of medium to transport their packets between machines, and clearly if two machines can't agree a common medium, they can't communicate, even if they both have TCP/IP implementations (or whatever). What we are concerned with here is the mechanism used by a media-specific protocol (e.g. Ethernet) to encapsulate higher level protocols, and whether this mechanism is sufficient to guarantee that the protocols will be kept distinct. The original Xerox Ethernet spec has the concept of a Type field. Each protocol which uses the Ethernet is supposed to have been allocated a globally unique Type value, and the Ethernet driver should keep packets with different Type fields distinct. The XNS version of IP uses a type field of 0x600 and the DoD version of IP uses 0x800. The more recent Ethernet 2 spec, also produced by Xerox, uses the same Type field mechanism and transmits the same bytes with the same meaning over the network. The differences concern hardware interfaces. Unfortunately, the IEEE 802 standards for LAN's are subtly different. The encapsulation mechanism (802.2) is defined in a media independent fashion, and there are a series of media specific standards - 802.3 is the one for Ethernet. 802.3 has no encapsulation mechanism because it is only designed to carry one protocol - 802.2. The Type field in the Xerox Ethernet spec is replaced by a Length field in 802.3. Although this difference should mean that Xerox Ethernets and 802 Ethernets are completely incompatible - distinct media - of course, in practice they have a great deal in common. However, in order for 802 packets to safely co-exist with Xerox packets on the same physical Ethernet, we need the equivalent of the Type field used to distinguish the XNS packets from the TCP/IP packets. Fortunately, if we arrange that no valid Xerox Type field can be a valid 802 Length field and vice-versa, we can achieve this. In practice this means that the values 0x000-0x5ff are reserved by Xerox as Type fields for 802, whilst 802 implementations ignore packets with a Length field of 0x600 and above. This is what I think Mark means - substitute "Xerox" for "XNS" and "802" for "TCP/IP" in what he writes above. But if I'm wrong, please tell me! It should be clear from what I have said that there is nothing to stop you using 802 rather than Xerox as the medium for XNS or TCP/IP, but don't expect an 802 TCP/IP implementation to be able to talk to a Xerox TCP/IP implementation. All the 4.2 BSD Ethernet drivers happen to use Xerox to encapsulate the IP packets, but they could just as easily use 802.2! Disclaimer: I'm not expressing any opinion about the relative merits of Xerox vs 802 - I'm just saying they're different! Comments which are more informative than "802 is brain-damaged" would be appreciated. Robert Stroud, Computing Laboratory, University of Newcsatle upon Tyne. ARPA robert%cheviot.newcastle@ucl-cs.ARPA UUCP ...!ukc!cheviot!robert JANET robert@newcastle.cheviot