Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!proteon.com!jas
From: jas@proteon.com ("John A. Shriver")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Here's the Rub (with bridging FDDI or 802.5 to Ethernet)
Message-ID: <8907201450.AA11993@monk.proteon.com>
Date: 20 Jul 89 14:50:40 GMT
References: <1679@brwa.inmos.co.uk>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 24

The ARP problem is not that simple.  There is only one ARP hardware
type for 802.2, corresponding to all encapsulations noted in RFC 1042.
There is nothing in the ARP packet that says whether the MAC Address
is 802.3 or 802.5.  Again, Roger Pfister's "49th bit".

Moreover, even if you fix the MAC address as protocol data problem in
ARP, just what are you going to do about Novell NetWare IPX, and all
the other protocols people have written that are placing 802.5-order
MAC addresses as data in higher layer protocols?

It's too late.  The existing 802.5 implementations just are not
normalizing MAC addresses to 802.3 bit order in the MAC/Data-Link
interface.  Indeed, the peice of paper you get from IEEE assigning you
a MAC address distinctly gives you the numeric value for your address
block in the two different bit orders.

To fix 802.5 would take the biggest flag day the networking world has
ever seen, since it would be a flag day for almost every protocol
running over 802.5.  By comparison, the Arpanet's NCP->TCP flag day
was trivial.

Maybe, just maybe, FDDI will get saved.  However, it would probably
require revising the MAC part, which is already approved.  (Eg. not
politically popular.)