Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!att!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM (James B. Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Token Ring ARPs
Message-ID: <9104082122.AA11401@ftp.com>
Date: 8 Apr 91 21:22:31 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 32


    But what about other applications, say for  network management, which
    also send MAC addresses in data? A router presents the same problem as
    a brigde in this case.

If an arbitrary protocol obtains a MAC address in a local LAN context, and
can restrain itself from using the MAC address outside that LAN's context,
there is no problem.  Bit order doesn't matter if you treat the address as
opaque.  Because not all MAC addresses conform to IEEE 48 bit formats, you
need to know the LAN's physical layer to parse them anyway.  Canonical bit
order on all 802.2 LANs would make the parser a little simpler...

    ... It makes a lot of sense to start now in making
    sure we do not propagate the mistake made in 1042. Of course, then 1042
    implementations would most likely eventually have to be changed... so 
    why not now?

As of the moment, neither of the two widely distributed 802.5 driver specs
(IBM's ASI and 3Com/Microsoft NDIS between them represent 95% of the IBM PC
802.5 interfaces, and probably 90% of the total 802.5 installed base) even
have hooks in them to indicate which bit order the MAC address is presented
in.  Many of the ASI drivers are at least partly in ROM.  So, first you need
to upgrade the specs, then all software drivers that were shipped with the
boards, and maybe the ROMs.  It'll be a while.
    
    Dose 1042 actual say to use wire order? I couldn't find it.

It doesn't say.  However, IBM chose the order returned by their TOKREUI
program, and everyone else followed suit.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901