"NI1D @FN42eq" <koning@koning.enet.dec.com> Tue, 11 September 1990 21:50 UTC

Received: from merit.edu by NRI.NRI.Reston.VA.US id aa12676; 11 Sep 90 17:50 EDT
Received: Tue, 11 Sep 90 16:49:37 EST from decpa.pa.dec.com by merit.edu (5.59/1.6)
Received: by decpa.pa.dec.com; id AA18196; Tue, 11 Sep 90 14:47:26 -0700
Message-Id: <9009112147.AA18196@decpa.pa.dec.com>
Received: from koning.enet; by decwrl.enet; Tue, 11 Sep 90 14:47:37 PDT
Date: Tue, 11 Sep 90 14:47:37 PDT
From: "NI1D @FN42eq" <koning@koning.enet.dec.com>
To: fddi@merit.edu
Status: O

OUI 00-00-00, EARP, bridges
Dave Piscitello raised the question of whether we can expect problems
from using a Protocol_ID of 00-00-00-Ethertype (for some currently
unused Ethertype) for EARP.
The answer is NO, provided the rules in RFC 1122 are followed.  That RFC
states that nodes may use 802.3 frames per RFC 1042 (i.e., frames on 
the orange hose with Protocol_ID 00-00-00-Ethertype) provided that they
ALSO accept and respond to "traditional" Ethernet frames (i.e., frames
per the blue book with just Ethertype).
It was based on that rule that we defined FDDI-Ethernet bridge translation.
Basically, the intent is that a SNAP frame with Protocol_ID of
00-00-00-Ethertype is synonymous with an Ethernet format frame to Ethertype.
So frames to Ethertype coming in on the Ethernet are translated to frames
to 00-00-00-Ethertype on the FDDI, and vice versa.  The case where a node
is sending 00-00-00-Ethertype on 802.3, and the frame then travels onto
FDDI and back onto Ethernet, will result in an Ethernet format frame to
Ethertype.  But by RFC 1122, those two are equivalent and the Ethernet
format frame must be accepted.
The question around Appletalk AARP that was referred to has nothing to
do with its ARP-ness.  It has to do with the fact that AARP does not use
the RFC 1122 rules.  Instead it uses the type of envelope (802.3 vs. Ethernet)
to distinguish AARP V1 from AARP V2, if I remember correctly.  We're working
on ways to deal with this.  In any event, we know why it happened, and know
that it is very easy to avoid when you're designing a new protocol such 
as EARP.
  •   NI1D @FN42eq