🚀 go-pugleaf

seifert@netcom.com (Rich Seifert) writes:
+---------------
| The problem is related to bridges. RFC 1042-knowledgeable bridges will
| decapsulate an 00-00-00 OUI encapsulated 802.2 SNAP header when
| bridging from an 802-compatible network to any CSMA/CD network.
| If the end station on the CSMA/CD network understand native-mode
| Ethernet, this is fine (this IS part of the host requirements for
| IP stations). However, AppleTalk Phase 2 devices do NOT understand
| raw Ethernet. The bridge which was just doing its job makes Appletalk
| stop working.
+---------------

So far so good...

+---------------
| Yes, yes,I know this is Apple's problem, and they should solve it, or
| have never done it; we've been through all this in the standards
| committee. Bottom line: This is the way AppleTalk is, no one should
| be using an OUI that isn't specifically assigned to them...
+---------------

*BZZZZT!*
Here is where you make the criticial mistake in the explanation. The
problem is *not* that Apple used OUI=0. That's quite all right, since
they are using their *assigned* EtherType with it. So on every medium
*except* Ethernet, AppleTalk Phase 2 is as fully compliant as, say, IP.

The *real* problem is that Apple broke with the (unwritten) convention
that says, "If you use SNAP/OUI=0/EtherType on 802.2 links, you should
use D/I/X Bluebook encapsulation on Ethernet, *NOT* 802.3/802.2". Another
way of expressing that unwritten convention is, "SNAP/OUI=0/EtherType is
intended for people who use 'EtherType' on Ethernet, and need a way to
use it on other media."

This is the convention that permits trivial bridging, and it is *this* --
not the use of SNAP/OUI=0 on 802.[456]/FDDI -- that is causing the grief
for bridge manufacturers.

So. We've all yelled at Apple now, for several years. They're not changing,
the bridge manufacturers aren't changing. We're stuck with special-casing
*one* EtherType in the bridging algorithm.

But note that you don't have to do something "completely different" for
Apple, you just have to do the same thing you would do to bridge a normal
802.2 non-SNAP/OUI=0 packet. That is, use 802.3 encapsulation. So the
algorithm in the bridge in the 802.4/802.5/FDDI to Ethernet direction is:

	if (pkt->DSAP == 0xAA &&
	    pkt->SSAP == 0xAA &&
	    pkt->OUI == 0 &&
	    pkt->etype != 0x809b	/* AppleTalk */
	    ) {
		...convert to "Ethernet" encapsulation...
	} else {
		...convert to "802.3" encapsulation...
	}

Is that so bad? One more term (pkt->etype != 0x809b) in the test?
[Or am I missing something?]


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043