art@opal.acc.com (Art Berggreen) (04/06/91)
The research community has been pushing for all MAC addresses carried as data in communication protocols to always be in cannonical format. This is at odds with older implementations for the Token Ring which were based on RFC1042 (use of SNAP). I'm curious as to if and when this might have an effect on products in the marketplace. I believe there is a large installed base that uses the RFC1042 style ARPs where the MAC addresses are in wire order. Are there any products out there that use cannonical order? Are there any coming? Does anyone have any other information? Art
romkey@ASYLUM.SF.CA.US (John Romkey) (04/07/91)
There are apparently a number of vendors in the field with token ring products that comply with RFC 1042. Many router vendors and PC vendors, for instance. Interop has a respectable number of hosts on token ring at the show every year, also. I think you're asking for a lot of trouble if you try to change this now. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice/fax: 415 594-1141
jbvb@FTP.COM (James B. Van Bokkelen) (04/08/91)
The research community has been pushing for all MAC addresses carried
as data in communication protocols to always be in cannonical format.
I don't think this is the "research community". Instead, I think it is
primarily commercial companies which "believe" in multi-media "bridges"
instead of "routers".
I'm curious as to if and when this might have an effect on products in
the marketplace. I believe there is a large installed base that uses
the RFC1042 style ARPs where the MAC addresses are in wire order.
The proposal I've seen makes it necessary to supply all new 802.5 IP
software with a "new/old bit order" configuration switch, and upgrade
all existing IP hosts on your ring before it can be set to "new" on any
of them. A truly Herculean support hassle, given how much 802.5 is out
there working the old way (IBM, FTP Software, Proteon, cisco, Wellfleet,
3Com, Woolongong etc.).
Are there any products out there that use cannonical order?
No; I've seen a couple of beta test releases that have reached the field
in ignorance of the true state of the world, but it gets fixed quite quickly
once the vendor understands about the installed base.
Are there any coming? Does anyone have any other information?
I don't know of any, barring accidents of the sort I mention above.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901greene@coral.com (Jeremy Greene) (04/09/91)
) I don't think this is the "research community". Instead, I think it is ) primarily commercial companies which "believe" in multi-media "bridges" ) instead of "routers". I agree that, because of ARP, bridges highlight the multi-media problem. 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. 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? Dose 1042 actual say to use wire order? I couldn't find it. JAG
ELINSKY@YKTVMZ.BITNET ("Jay Elinsky") (04/09/91)
> Are there any products out there that use cannonical order? > > No; I've seen a couple of beta test releases that have reached the field > in ignorance of the true state of the world, but it gets fixed quite quickly > once the vendor understands about the installed base. Actually, Version 2 of IBM's VM and MVS TCP/IP products have the "new/old bit order configuration switch". It's the "CANONICAL/NONCANONICAL" parameter of the LINK statement for network type IBMTR. The VM manual mentions it for IBMTR links on LCS devices only, but it applies to ILANS devices also. The default is NONCANONICAL, of course. Jay Elinsky IBM T.J. Watson Research Center Yorktown Heights, NY
jbvb@FTP.COM (James B. Van Bokkelen) (04/09/91)
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-0901greene@coral.com (Jeremy Greene) (04/09/91)
) 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... ) You were talking about sending mac addresses accross multi-media. I was pointing out that the problem is with ANY mac address in data, not just macs in ARP responses. For macs in data other than ARPs, multi-media routers cause the same problem that bridges do. You brought up another valid issue: how does an application which runs on various media know what the address format is. The right answer is that it always expects it in one format. I'm not sure what you mean by opaque, the point is that the application wants to see the data. ) 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. Is it really that bad? You mean there are 802.5 cards/drivers which actually return a canonical format address? I find that hard to believe. It would certainly be nice to have the driver hook, but I think the client of the driver could know the format based on the interface type. JAG
jbvb@FTP.COM (James B. Van Bokkelen) (04/11/91)
You brought up another valid issue: how does an application which
runs on various media know what the address format is. The right
answer is that it always expects it in one format. I'm not sure
what you mean by opaque, the point is that the application wants
to see the data.
By 'opaque' I mean "uninterpretable, monolithic". The less applications
have to know about the detailed format of addresses (IP or MAC), the better.
Arbitrary MAC addresses can't be parsed without the context of what sort
of LAN they originated on, so applications that need to know e.g. whether
a specific packet was broadcast or multicast have to have tables of LAN
address formats in any case.
....
It would certainly be nice to have the driver hook, but I think the
client of the driver could know the format based on the interface type.
If you're going to be passing MAC addresses around at all, even if you
don't parse them, you *really* need to be uniform across all protocols.
Otherwise you'll be in real trouble if a node supports two protocol
stacks, one which canonicalizes the bit order and the other which doesn't,
and you only have a management tool for one stack. Thus, everyone I've
discussed the issues with to date assumes that the ASI or NDIS drivers
would have to canonicalize the bit order presented at their API in order
to implement this change.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901kzm@hls.com (Keith McCloghrie) (04/11/91)
Jeremy, > I agree that, because of ARP, bridges highlight the multi-media problem. > But what about other applications, say for network management, which > also send MAC addresses in data? The IETF 802.5 MIB (which has been submitted for publication as an RFC) specifies the use of the (802.1a) canonical ordering for MAC addresses when accessed by SNMP, rather than 802.5 transmission ordering. Keith.