Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!VAX.FTP.COM!jbvb From: jbvb@VAX.FTP.COM (James Van Bokkelen) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Here's the Rub (with bridging FDDI or 802.5 to Ethernet) Message-ID: <8907071816.AA20098@vax.ftp.com> Date: 7 Jul 89 18:16:13 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 246 BICC Data Networks Ref: 661-065-1 Page: 1 of 5 the makers of ISOLAN _____________________________________________________________________________ Bit Ordering of MAC Addresses when travelling in User Data on FDDI This paper is to be presented to ANSI X3T9.5 (FDDI) SMT Working group and to IEEE 802.1 MAC Bridging subgroup. Author: Roger Pfister 16 May 1989 BICC Data Networks The System Centre Brindley Way HEMEL HEMPSTEAD, Herts HP3 9XJ UK FAX +(44) 442 54701 TEL +(44) 442 231000 References [1] "Bit Ordering in MSB and LSB LANs" R. Pfister FDDI SMT 240. Oct 88 [2] IEEE 802.1 part A, Architecture and Overview [3] "A standard for the Transmission of IP Datagrams over IEEE 802 Networks", J. Postel and J. Reynolds RFC 1042 Feb 88. Page 2 of 5 1. What is the problem? IEEE administers the assignment of what has become known as the "48 bit IEEE globally assigned unique MAC address". 802.3, 802.4, 802.5 and FDDI support this addressing scheme. Because of a twist of history two of the LANs, 802.3 and 802.4, use LSB first transmission and two 802.5 and FDDI use MSB first transmission. One important point to arise from the difference in transmission standard is that a bridge from 802.3 to 802.5 or 802.3 to FDDI has to reverse the bit order of the destination and source MAC addresses at the start of the MAC frame. This is because the different LAN types use the same bit order for the MAC address i.e. "group bit first" and yet use a different bit order for the user data i.e. LSB or MSB first. See ref[1] for a full description. As a side effect of the two LAN groups treating IEEE addresses in a different manner it has become common for 802.3 and 802.5 to specify their MAC addresses with different bit order. As an illustration - 10 00 05 00 00 57 is an example MAC address used in IBM Token Ring documentation - and 08-00-A0-00-00-EA is how the SAME address would be described in documentation for an 802.3 or 802.4 LAN. I have inserted hyphens to distinguish the two forms. The latter, with the hyphens, is in Canonical form, this is the "standard form" used by the IEEE when they administer addresses, it is described in ref[2], this notation is also sometimes called "illustrative hex". In future I shall use the terms "IBM form" and "canonical form" for the two types of encoding. The essence of the problem, dealt with in this paper, is that there exists no encoding of the hyphens, or lack of hyphens. In other words, just being given a 48 bit address is insufficient knowledge to be able to use that address, one also needs to know the bit order of that address. Most applications implicitly know the bit order. On an 802.3 LAN it is canonical form and in 802.5 it is "IBM form" and so implementers have not, until recently, experienced difficulties. However now that bridges between different MAC types are being built this problem has received more attention. I shall now give a real example where this difference causes existing protocols to fail when bridging between LANs of different types. The following example uses ARP frames encoded as described in ref[3], in this manner they are not limited to 802.3 networks. Page 3 of 5 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. 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 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". 4. The end-station receives the ARP reply and by using the MAC address returned in a field in the ARP reply, (i.e. in user data) it knows the MAC address of the server. 5. Future frames are sent to that MAC address By this simple protocol exchange a dynamic address map is constructed which maps IP addresses to MAC addresses for both stations involved. If the same exchange happens between an end-station on 802.3 and a server on 802.5 the following additional steps occur - 1b. The frame passes through a bridge, whether it is a source routing bridge or transparent bridge is immaterial. As the frame traverses the bridge it has the bit order of the destination and source MAC addresses, in the frame header, reversed. 3b. As frame passes through the bridge in the return direction it also has the bit order of the destination and source MAC addresses, in the frame header, reversed. If, as has become common, the two styles of LAN use different bit orders when reporting their MAC address via the field in user data then THIS PROTOCOL WILL FAIL. It will fail because the MAC address used in step 3b is taken directly from the user data field as received in step 3. This address has not been "bit reversed" as is automatically done for the MAC address in the MAC header. Page 4 of 5 How did this failure come to exist. The problem is that the promoters of MSB first have accidently created a new type of MAC address encoding and are using it where the original "Canonical form" should only be used. Existing protocols have no way of knowing which encoding is being used, Canonical form or IBM form. When the two forms are mixed then disaster ensues. It is important to realise that the problem is not with one particular protocol but with the fact that there are two forms of encoding lose in a code space that can only take one form of encoding. We appear to have invented the "49 bit address" but have no 49th bit to use. All protocols that want to manage lists of MAC addresses will be affected. 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. 4. Choices for FDDI Let us give examples, the MAC addresses in the MAC header in FDDI are in IBM form. As this domain has only one form and it is fixed by hardware, there is no problem here, it has to be the IBM form. What form of encoding should an FDDI node offer to the world via management? In my opinion, there is only one sensible answer, that is to use the CANONICAL form. This is important to FDDI because the large networks in which FDDI will be a key backbone component will contain different MAC types so it is essential to use a standard encoding for a MAC address, the standard is the canonical form. What address form should the FDDI use in the fields in the SMT frames? In this case, again, there must be only one type, i.e. the specific form that will be required by the standard. This could be either form and the FDDI committee will need to decide which it is going to be. There are good reasons for either choice. One can argue that it seems neater to use the IBM form in SMT frames because SMT is more low level and directly related to the MAC address bit order in the MAC header. On the other hand one can argue that, as the address we want the world (management) to know us by is to be canonical form then it is important to set "good practice" and have canonical form in SMT frames. My recommendation favours the latter argument. The FDDI committee should set good practice and use the canonical form where ever possible including in SMT frames. Page 5 of 5 5 Why not just keep copying 802.5 There is an argument that runs - "this is all very well to fuss about bit order but FDDI decided be the same as 802.5 so lets do what ever they do. If they use IBM MAC address form everywhere then we should do the same." The counter argument to this, is that, FDDI decided to go MSB first - that's fine. FDDI decided to use IBM form for the MAC address in the MAC header - that's fine. But I do not think FDDI made a policy decision to copy everything 802.5 does no matter what the implications. What are the implications of using IBM form in all places. In a pure world one could argue that there would then be two camps, the 802.3, 802.4 camp and the 802.5 and FDDI camp. This picture does not ring true. FDDI differs from 802.5 in its installed user base - virtually none. There are currently no true FDDI nodes, and there can't be until the SMT standard is finished. Some of the first FDDI products will be transparent bridges between FDDI and 802.3, this is completely unlike 802.5. These bridges will create an installed base that will require future FDDI nodes to use the canonical form, particularly with existing protocols such as ARP. This will mean that there will be FDDI end-stations that use canonical form as their standard MAC address encoding for management. This is very different when compared to 802.5. To have FDDI stations advertising both forms, for use in the management domain is definitely a folly. For these reasons FDDI should not copy 802.5 in this particular issue.