jbvb@VAX.FTP.COM (James Van Bokkelen) (07/08/89)
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.
rob@europa.inmos.co.uk (Robin Pickering) (07/17/89)
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
jas@proteon.com ("John A. Shriver") (07/20/89)
The ARP problem is not that simple. There is only one ARP hardware type for 802.2, corresponding to all encapsulations noted in RFC 1042. There is nothing in the ARP packet that says whether the MAC Address is 802.3 or 802.5. Again, Roger Pfister's "49th bit". Moreover, even if you fix the MAC address as protocol data problem in ARP, just what are you going to do about Novell NetWare IPX, and all the other protocols people have written that are placing 802.5-order MAC addresses as data in higher layer protocols? It's too late. The existing 802.5 implementations just are not normalizing MAC addresses to 802.3 bit order in the MAC/Data-Link interface. Indeed, the peice of paper you get from IEEE assigning you a MAC address distinctly gives you the numeric value for your address block in the two different bit orders. To fix 802.5 would take the biggest flag day the networking world has ever seen, since it would be a flag day for almost every protocol running over 802.5. By comparison, the Arpanet's NCP->TCP flag day was trivial. Maybe, just maybe, FDDI will get saved. However, it would probably require revising the MAC part, which is already approved. (Eg. not politically popular.)
jbvb@VAX.FTP.COM (James Van Bokkelen) (07/20/89)
Date: 17 Jul 89 12:35:59 GMT From: Robin Pickering <mcvax!ukc!icdoc!inmos!europa!rob@uunet.uu.net> >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. We're talking about RFC 1042 encapsulation, using 802.2 headers on the Ethernet here, not RFC 826. All RFC 1042 networks use the same ARP hardware type, 6, so no distinction can be made. 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?). .... The reason that both 802.3 and 802.5 are using RFC 1042 format packets in this example is so that the bridge can exist at all. The bridge can't be intelligent enough to understand RFC 894 encapsulation on the ether side and convert it to RFC 1042 on the TR side and remain a bridge. It is presently postulated that at some time in the future most or all Ethernet TCP/IPs will have a configuration option to add support for RFC 1042 on 802.3, but the thing that Roger has discovered is that it won't buy us as much as had been hoped. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901