Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!RT-JQJ.STANFORD.EDU!jqj
From: jqj@RT-JQJ.STANFORD.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Zero manufacturer code in SNAP?
Message-ID: <9007201558.AA17891@rt-jqj.Stanford.EDU>
Date: 20 Jul 90 15:58:11 GMT
References: <9272@goofy.Apple.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 52


Transparent bridging of common protocols between FDDI and Ethernet is
currently impossible due to a conflict between various "standards" (notably
RFC1103 and draft successor, IEEE 802.d, and AppleTalk Phase II).

We were the people whom John Veizades refers to that verified that AppleTalk
II doesn't work across DEC FDDI-Ethernet "transparent" bridges.  At least one
other transparent FDDI to Ethernet bridge vendor currently has the same
implementation.

John suggests that bridges should have a small table indexed by EtherType
indicating whether packets should be translated from RFC1042-style 802.2/SNAP
to Ethernet format when going from FDDI to Ethernet.  Unfortunately, this does
not solve the problem.  Suppose my FDDI to Ethernet bridge knows that AARP
packets should go out on the coax as 802.3 so that AppleTalk II nodes can
understand them.  That means that my bridge is not transparent to AppleTalk I.
So it's not an feasible solution.

I believe that if Apple wants to play in the heterogenous bridging world,
they need to modify AppleTalk II specs in one of the following ways:

1/ an AT II node on 802.3+Ethernet media must listen to *both* RFC1042-style
   802.2/SNAP/AARP *and* to Ethernet/AARP packets sent to the Appletalk
   multicast address.  This corresponds to the requirement for IP hosts that
   appears in RFC1122 and states that any 802.3/802.2/IP speaker must also
   understand Ethernet encapsulation.
 OR
2/ the AT II spec must be modified so that AARP generates and expects the
   Apple OUI the same way AT II/DDP does.

Both proposals break currently fielded AppleTalk II implementations, so I
can see that Apple may be reluctant to adopt them.  But I think that at this
point it is unlikely that the IP-on-FDDI working group will radically change
their encapsulation requirements just to satisfy Apple, and I see no way for
bridge manufacturers to satisfy everyone's requirements simultaneously.

The alternative is a modification of both the definition of "transparent"
bridging and the IP-in-FDDI spec.

To reiterate, John is correct that, by the current de facto standard,
"transparent" 802.3->FDDI->802.3 bridges are not transparent to 802.3 packets
in RFC1042 format.  This is not a problem for IP, because of the specific
requirement that all receivers of RFC1042 format on an 802.3 medium also
understand Ethernet encapsulation.


JQ Johnson                              voice: 415-723-3078
Manager, Special Projects               Internet: jqj@jessica.stanford.edu
Networking and Communications Systems
Pine Hall Rm 125-A 
Stanford University
Stanford, CA 94305-4122