Xref: utzoo comp.dcom.lans:5463 comp.protocols.tcp-ip:12221
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!decwrl!ucbvax!agate!shelby!portia.stanford.edu!jessica.stanford.edu!morgan
From: morgan@jessica.stanford.edu (RL "Bob" Morgan)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: Zero manufacturer code in SNAP?
Message-ID: <1990Jul20.183149.15792@portia.Stanford.EDU>
Date: 20 Jul 90 18:31:49 GMT
References: <1990Jul17.010234.12077@portia.Stanford.EDU> <9272@goofy.Apple.COM>
Sender: news@portia.Stanford.EDU (USENET News System)
Distribution: na
Organization: Academic Information Resources
Lines: 97


Ah, well, now we're getting somewhere.

John and Alan write:

> The all-zeros "organizational unique identifier" (OUI) was not
> specifically intended to be used for translating Ethernet frames to
> 802.2/SNAP.  Its original intention was (and is) not completely clear;
> all that was generally agreed upon was:
> 
> (1) The low-order 16 bits of the SNAP protocol discriminator indicated an 
> Ethernet protocol type; and
> 
> (2) The format of the data part of the SNAP packet was the same as the 
> format of the data part of the Ethernet packet of this protocol type.
> 
> This "general agreement," as far as I know, was never written down.  
> AppleTalk Phase 2 and TCP/IP both adopted this convention.

Well, not exactly.  Normal AppleTalk Phase 2 (AT2) DDP datagrams are
encapsulated using an OUI of 080007, which I assume has been assigned
to Apple.  Only AT2 ARP frames use an OUI of zero.  (Both use the
Ethertype for the last two bytes.)  I'm sure there's a good
explanation for this, but I'll admit it puzzles me.

So, as we've observed, AT2 DDP frames travel across a pair of
Ethernet-to-FDDI bridges just fine, and are received properly by AT2
devices on the second Ethernet.  This works because the bridge sees
the non-zero OUI and simply leaves the frame untouched.

AT2 AARP frames fail, however.  Because the bridge assumes that any
zero-OUI frame on the FDDI was originally an Ethernet-format frame
that was translated to 802.2/SNAP, it retranslates such a frame back
to Ethernet format when it forwards it onto the Ethernet.  An AT2
station ignores an Ethernet-encapsulated AARP, since it's only looking
for 802.2/SNAP.

Now, as Vernon points out:

> It should be noted in passing that following is in the Host Requirements
> standard, RFC-1122:
> 
> ]      2.3.3  Ethernet and IEEE 802 Encapsulation
> ]      ...
> ]         Every Internet host connected to a 10Mbps Ethernet cable:
> ]
> ]         o    MUST be able to send and receive packets using RFC-894
> ]              encapsulation;
> ]
> ]         o    SHOULD be able to receive RFC-1042 packets, intermixed
> ]              with RFC-894 packets; and
> ]
> ]         o    MAY be able to send packets using RFC-1042 encapsulation.

This ensures that IP stations, even if they prefer RFC-1042 (SNAP with
zero OUI) format, will properly receive Ethernet format.  Of course,
as Vernon notes, it effectively prevents RFC-1042 from ever being the
preferred format.

John and Alan continue:

> Thus for a TCP/IP Ethernet node to communicate with a TCP/IP 802.2
> node (on token ring or FDDI, say), some type of packet translation
> must be performed, whereas for an AppleTalk Phase 2 Ethernet node to
> communicate with any other AppleTalk Phase 2 802.2 node (on Ethernet,
> token ring or FDDI) no such translation need occur (in fact, such
> translation MUST NOT occur).  This makes it somewhat difficult to
> build a bridge that "transparently" allows both forms of
> communication.  However all that really has to be done is for the
> bridge to contain a small table of Ethernet protocol types that either
> should, or shouldnUt be translated in this manner.  Obviously the
> smaller the table, and the less translation done, the better the
> overall performance.

The combination of AppleTalks Phase 1 and 2, however, presents a
sticky situation for a such a bridge, where even the translation-table
method won't work.  After translation into 802.2/SNAP, an AT1 AARP
frame is identical to an AT2 AARP frame (except for destination MAC
address).  If the bridge, while forwarding from the 802 medium to
Ethernet/802.3, translates a zero-OUI, Ethertype 80F3 frame to
Ethernet encapsulation, AT2 breaks.  If it leaves it unchanged, AT1
breaks.  The bridge could dig even further, of course, to determine
whether the destination MAC address is broadcast (AT1) or multicast
(AT2).

Apple could solve the problem by fiddling with AT2 to either:

1) make AT2 stations receive Ethernet-encapsulated AARPs, or

2) use the Apple OUI for AARPs as well as DDPs.

Or we could all resign ourselves to using routers to connect between
heterogeneous LANs, which is probably the moral of this whole story.

 - RL "Bob" Morgan
   Networking Systems
   Stanford