Using SNAP to distinguish EARP from ARP

Lawrence J Lang <nvuxe!larryl@bellcore.bellcore.com> Mon, 10 September 1990 16:32 UTC

Received: from merit.edu by NRI.NRI.Reston.VA.US id aa24625; 10 Sep 90 12:32 EDT
Received: Mon, 10 Sep 90 11:29:23 EST from RUTGERS.EDU by merit.edu (5.59/1.6)
Received: from bellcore.UUCP by rutgers.edu (5.59/SMI4.0/RU1.4/3.08) with UUCP id AA17783; Mon, 10 Sep 90 11:59:49 EDT
Received: by bellcore.bellcore.com (5.61/1.34) id AA03304; Mon, 10 Sep 90 11:26:20 -0400
Message-Id: <9009101526.AA03304@bellcore.bellcore.com>
From: Lawrence J Lang <nvuxe!larryl@bellcore.bellcore.com>
To: fddi@merit.edu
Cc: nvuxe!D.Piscitello@bellcore.bellcore.com
Date: Mon, 10 Sep 1990 11:20:00 -0400
Subject: Using SNAP to distinguish EARP from ARP
Status: O

paul> As far as I can see, the only safe solution is to have EARP messages use
paul> a different Protocol_ID... 
paul> The reason for not using the ARP Hardware Type field (by itself) to
paul> identify EARP is that some implementations ignore that field.

Reverse ARP (RARP), as defined in RFC 903, ran into a comparable question.
RARP could have used the same SNAP that ARP uses (00-00-00-08-06),
and defined two new opcodes for 'request reverse' and 'reply reverse'.
Instead, a new SNAP is specified for RARP (00-00-00-80-35),
so that "existing ARP servers will not be confused by RARP packets."

Note that RARP also includes the original functionality of ARP:
rfc903> There are two opcodes: 3 ('request reverse') and 4 ('reply reverse').
rfc903> An opcode of 1 or 2 has the same meaning as in [RFC 826];
rfc903> packets with such opcodes may be passed on to regular ARP code.
rfc903> A packet with any other opcode is undefined.

Thus, historical precedent suggests a new SNAP should be specified for EARP.

			*	*	*

About using a SNAP of the form 00-00-00-EtherType (rather than some other OUI):

How will this effect an environment with FDDI/Ethernet bridges
that translate from this type of FDDI/LLC frame to an Ethernet/EtherType frame
(rather than an 802.3/LLC frame)?  For example, AppleTalk ARP is reputed
to break over FDDI/Ethernet bridges, because its SNAP (00-00-00-80-F3)
is based on the OUI 00-00-00, rather than, say, Apple's OUI.
If a Macintosh issues an AARP request in an 802.X/LLC or FDDI/LLC frame,
which is then bridged from FDDI to an Ethernet/EtherType frame,
any Macintoshes on the 802.3-Ethernet will not respond,
because they expect AARP in 802.3/LLC frames.

Does any comparable problem threaten EARP,
either by using the OUI 00-00-00, or by using some other OUI?

Larry Lang


larryl@sabre.bellcore.com	Bellcore
+1 908 758 2108          	331 Newman Springs Road
+1 908 747 3424 Fax      	Red Bank, NJ   07701