Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!ukc!icdoc!inmos!europa!rob
From: rob@europa.inmos.co.uk (Robin Pickering)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Here's the Rub (with bridging FDDI or 802.5 to Ethernet)
Message-ID: <1679@brwa.inmos.co.uk>
Date: 17 Jul 89 12:35:59 GMT
References: <8907071816.AA20098@vax.ftp.com>
Sender: news@inmos.co.uk
Reply-To: rob@inmos.co.uk (Robin Pickering)
Organization: INMOS Limited, Bristol, UK.
Lines: 65

In article <8907071816.AA20098@vax.ftp.com> jbvb@VAX.FTP.COM (James Van Bokkelen) writes:
> [text about LSB reversal in FDDI deleted]
>
>2.	Failure to interoperate.
>
>
>The protocol is the TCP/IP ARP and the LANS are 802.3 and 802.5.
>The way the ARP protocol should work is, in simplified form, as follows.
>
>1.	An end-station wants to know the MAC address of a given server.
>The end-station only knows the servers internet address.  The end-station
>then sends an Address Resolution Protocol (ARP) request frame to the
>broadcast address.
>
>2.	This frame contains the originators MAC address and the
>destinations IP (Internet Protocol) address.  All participating stations
>hear the broadcast frame possibly by way of IP routers.

No way does an ARP request get forwarded by an IP router. ARP is for address
resolution between stations on the same physical network.

>
>3.	All receiving stations compare their IP address with the
>destination IP address given in the broadcast frame.  The station that
>recognises the "sought after" IP address as its own sends an ARP reply

And the sought after Hardware Address Type field as it's own [RFC826]

>frame directed to the MAC address of the original station.  The ARP reply
>frame contains the MAC address of sender, in this case a server, "in a
>field in the user data".

The ARP packet contains a field which defines the Hardware address space.
Implementations of ARP over 802.5 should not respond to requests for an address
of type Ethernet (802.3) unless the address which they return is of the type
used on Ethernet. The endian swapped 802.5 address clearly does
not correspond to this address type and hence should not be returned for 
a request of this type.

Why not have the ARP implementation return the Ethernet ordered address to 
requests which have the Ethernet address type and the 802.5 address to
requests which have the 802.5 address type (is there a type defined for
anything other than Ethernet?). In any case ARP over 802.5 should not:

    a) Use the hardware address type of Ethernet
    b) Respond to a request with address type of Ethernet, by returning
        an 802.5 style address.

> [Obvious results of the failure of ARP to comply with above deleted]
>
>3.	The Solution.
>
>There is only one real solution - that is - to use only one form, the
>Canonical form, where ever there may be mixture of two forms.

Or acknowledge that they are in fact two different address types and use
a different ARP Hardware Address Type field value.

 Rob Pickering, Communications Group, Inmos Limited.
--
JANET:             ROB@UK.CO.INMOS        | Snail: 1000 Aztec West
Internet:          rob%inmos-c@col.hp.com |        Almondsbury
Rest of World:     rob@inmos.co.uk        |        Bristol BS12 4SQ
Phone:             +44 454 611517         |        UK     
dumb UUCP:         ...ukc!inmos!rob or ...uunet!inmos-c!rob