RFC 1469

IP Multicast over Token-Ring Local Area Networks 🎀

okay bestie, the header is giving RFC 1469 vibes 💅 Written by Thomas J. Pusateri (the header just says T. Pusateri), a Consultant, dated June 1993, in the Network Working Group. It's an IAB standards track protocol. The header doesn't list anything it obsoletes or updates, so there's no drama there ✨

Status of this Memo

This RFC specifies an IAB standards track protocol for the Internet community, and it's looking for discussion and suggestions for improvements 🦋 For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." Distribution of this memo is unlimited, so share it with everyone 🌈

Abstract

This document specifies a way to send IP multicast datagrams over Token-Ring Local Area Networks 🧚 An interim solution has already emerged and is being used right now, but this document wants a more efficient way to do it, using an assigned Token-Ring functional address 💖

Introduction

okay so IP multicasting lets you send IP datagrams to a whole group of hosts at once 👑 The destination address in the IP datagram is a group IP address, as documented in STD 5, RFC 1112 [1]. These are also called Class D addresses, and they live in the range from 224.0.0.0 to 239.255.255.255 ✨ There's already a standard way to map IP multicast addresses to media types like ethernet and fddi, found in [1] and RFC 1188 [2]. This document is the one that tries to define the mapping from an IP multicast address to the matching Token-Ring MAC address 🫶

Background

The Token-Ring Network Architecture Reference [3] gives you several kinds of addressing 🌸 That includes individual (unicast) addresses and group (multicast) addresses. A special subtype of group address is called a functional address, and it's flagged by a bit in the destination MAC address. These were made for popular functions like ring monitoring, NETBIOS, Bridge, and Lan Manager frames 😭 There are only 31 functional addresses in total, so unrelated functions have to share the same one, which is a lot honestly 💀

It would be most desirable if Token-Ring could use the same mapping as ethernet and fddi for IP multicast to hardware multicast addressing 🍓 But current Token-Ring controller chips can't support that. To see why, we first have to look at the Destination MAC address format 🙈

Destination Address Format

The destination MAC address has six octets 🎀 In the diagram below, octets are sent from top to bottom (octet 0 to octet 5), and the bits inside each octet are sent from right to left (bit 0 to bit 7). This is the so-called "canonical" bit order for IEEE 802.2 addresses. Addresses handed to or received from token ring interfaces are usually laid out in memory with the bits of each octet in the opposite order from the diagram, meaning bit 0 sits in the high-order (leftmost) position within the octet 🦋

            7   6   5   4   3   2   1   0

          ---------------------------------
          |   |   |   |   |   |   |U/L|I/G|       octet 0
          ---------------------------------
          |   |   |   |   |   |   |   |   |       octet 1
          ---------------------------------
          |   |   |   |   |   |   |   |FAI|       octet 2
          ---------------------------------
          |   |   |   |   |   |   |   |   |       octet 3
          ---------------------------------
          |   |   |   |   |   |   |   |   |       octet 4
          ---------------------------------
          |   |   |   |   |   |   |   |   |       octet 5
          ---------------------------------

The low order bit of the high order octet is the I/G bit 💜 It tells you whether the address is an individual address (0) or a group address (1). It's basically the same idea as the multicast bit in the DIX Ethernet addressing format 🧚

Bit position 1 of the high order octet is the U/L bit ✨ It says whether the address is universally administered (0) or locally administered (1). Universally administered addresses are the ones assigned by a standards organization, like the IEEE 👑

If the I/G bit is set to 1 and the U/L bit is 0, the address must be a universally administered group address. If the I/G bit is 1 and the U/L bit is a 1, the address may be either a local administered group address or a functional address. This distinction is determined by the Functional Address Indicator (FAI) bit located in bit position 0 of octet 2. If the FAI bit is 0, the address is considered a functional address. And if the FAI bit is 1, this indicates a locally administered group address. 😭🫶

Different functional addresses come from setting one of the remaining 31 bits in the address field 🌈 Those bits are the 7 remaining bits in octet 2 plus the 8 bits in octets 3, 4, and 5. You can't make more functional addresses by setting more than one of these bits at a time, so keep it to one 💅

There are three methods for mapping between an IP multicast address and a hardware address 🍓 They are:

1. The all rings broadcast address
2. The assigned functional address
3. The existing IEEE assigned IP Multicast group addresses

To keep things interoperable, all systems supporting IP multicasting on each physical ring have to agree on the hardware address to use 🫶 That's why the method should be configurable on a given interface. Bridges may offer a way to translate between the different methods for each physical ring they bridge 🌸 Method (3) is recommended, but because of hardware limitations in Token-Ring controller chips, it may not be possible 🙈 In that case, Method (2) is preferred over Method (1). For backward compatibility, systems that support (2) MUST also support (1). And systems that support (3) MUST also support (2) and therefore (1). Without any configuration info, the default should be to use the assigned functional address (2) 🔥

IP Multicast Functional Address

Because Token-Ring functional addresses are in short supply, all IP multicast addresses get mapped to a single Token-Ring functional address 💖 In canonical form, that address is 03-00-00-20-00-00. In non-canonical form, it's C0-00-00-04-00-00. It's worth noting that with only 31 possible functional addresses, other protocols may also be assigned this functional address 😭 So just because a frame goes to the functional address 03-00-00-20-00-00 doesn't mean it's an IP multicast frame 🙅‍♀️

Acknowledgments

The author would like to thank John Moy, Fred Baker, Steve Deering, and Rob Enns for their review and constructive comments 🫶🌸

References

[1] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.

[2] Katz, D., "A Proposed Standard for the Transmission of IP Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET, October 1990.

[3] IBM Token-Ring Network, Architecture Reference, Publication SC30-3374-02, Third Edition, (September, 1989).

Security Considerations

Security issues are not discussed in this memo 💀 Yes, it's a whole lot of nothing on the security front, so keep that in mind when you're building on top of this 🙈

Author's Address

Thomas J. Pusateri, Consultant 💅

11820 Edgewater Ct., Raleigh, NC 27614 🎀

EMail: pusateri@cs.duke.edu ✨