Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!think!nike!ucbcad!ucbvax!LLL-MFE.ARPA!Provan From: Provan@LLL-MFE.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: How to IP & ARP on 802 nets Message-ID: <8609060458.AA27670@ucbvax.Berkeley.EDU> Date: Thu, 4-Sep-86 02:45:00 EDT Article-I.D.: ucbvax.8609060458.AA27670 Posted: Thu Sep 4 02:45:00 1986 Date-Received: Sat, 6-Sep-86 05:37:45 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 54 Approved: tcp-ip@sri-nic.arpa I have two problems with this scheme. Unfortunately, both are caused by the SNAP, which seems to be the part closest to being fully blessed. The first problem is the 24 bit "organization" code. A 24 bit field seems excessively clumsy. (In the immortal words of 1822, it's "not particularly convenient for anyone.") Not too serious, but it fits well with my solution. The second problem is that this plan works great with 802.2 type 1 headers, but 802.2 type 2 messages add an additional byte to the normal 802.2 header. If the SNAP scheme is unchanged in this situation, we find ourselves with the new ethernet type field shifted back to an odd byte and our IP packet gets out of alignment. Does anyone know what happens to the SNAP in type 2? I don't know if it's feasible to send IP packets over type 2 802.2, but if it is we need to worry about this. I have a solution that solves both of these problems. Instead of a 24 bit organization code, break it into an eight bit unused pad field followed by a 16 bit organization code. (Happily, this field is then aligned to an even byte.) In type 2 802.2 packets, this unused eight bits becomes the second byte of the 802.2 control field, but the other four bytes of the SNAP (two for the organization code and two for the new ethernet type field) remain the same. So the 802.2 header would be the same size (eight bytes) for both type 1 and type 2 packets, rather than have the three byte header for type 1 and the four byte header for type 2 in the currently published protocol. Of course, this assumes we have anything to say about this. Since this doesn't appear to be the case, i guess it's too late to avoid these problems. Looking back on this note, i realize that someone without familiarity with 802.2 might be confused. I think i can lessen the confusion by explaining that 802.2 packets, including these three or four (or eight) byte headers, ride inside 802.3 packets, which have the familiar 14 byte ethernet header, with the ethernet type field replaced by the famous 802.3 length field. While i have the floor, at the TCP workshop, i think i heard twice that 802.3 lengths less than 60 are illegal, and, therefore, fall under the famous ethernet footnote, which says that any illegal lengths can be interpreted however the implementation wants (thus allowing previous ethernet implementations to continue to operate on the same network as 802.3 impelmentations). If i heard correctly, i'd like to point out that this is not correct. Lengths less than 60 are legal in 802.3. In fact, it's the need to express a packet smaller than 60 bytes in a hardware environment which doesn't allow transmission of packets less 60 bytes in length that is the justification for the length field in the first place. (A packet can be padded out to 60 bytes while the true length of the packet is preserved via the length field.) don provan provan@lll-mfe.arpa