RFC 4541

Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches

📅 published May 2006, from ietf

Part 1 of 4 💖

Title Block 🎀

okay bestie, first the paperwork so you know who's talking 🫶 This is RFC 4541, titled Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches. It was written by M. Christensen (Thrane & Thrane), K. Kimball (Hewlett-Packard), and F. Solensky (Calix). It's an Informational doc, dated May 2006 📅. The title block doesn't list anything it obsoletes or updates ✨

Status of This Memo 📜

This memo gives information to the Internet community. It is not a standard of any kind 🙈 Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2006) 💜

Abstract ✨

okay so this doc describes recommendations for IGMP and MLD snooping switches 🦋 It's based on best current practices for IGMPv2, with extra considerations for IGMPv3- and MLDv2-snooping. It also looks at other stuff that's relevant, like link layer topology changes and Ethernet-specific encapsulation issues 💅

1. Introduction 🧚

So the IEEE bridge standard [BRIDGE] explains how LAN packets get "bridged" (or, as people say more often now, switched) between LAN segments 🍓 Here's the switch behaviour with multicast packets, summed up: when a packet's destination MAC address is a multicast address, the switch forwards a copy of it out every other interface that's in the forwarding state, following [BRIDGE]. The spanning tree algorithm makes sure this rule, applied at every switch in the network, makes the packet reachable by every node on the network 🌈

This works great for broadcast packets, which are meant to be seen or processed by everyone 💖 With multicast, though, it can be wildly inefficient, especially when only a handful of nodes want the packet 😭 Packets get flooded into network segments where no node cares about them. Nodes rarely waste processing power filtering out packets addressed to group addresses they never asked for, but they can't transmit new packets onto the shared media while a multicast packet is being flooded 💀 Overall, a LOT of bandwidth can get wasted by flooding ngl 🌊

Lately a bunch of commercial vendors have launched products called "IGMP snooping switches" 🛍️ These devices don't stick to the ISO model's strict separation between communication layers. Instead, they use info from upper-level protocol headers when they're processing things at the lower levels 🧠 It's kind of like how a router can act as a firewall by peeking into the transport protocol's header before it forwards a packet to its destination address 🔥

For IP multicast traffic, an IGMP snooping switch saves bandwidth on the network segments where no node has said it wants packets sent to that group address 💜 Normal switches, by contrast, usually forward multicast traffic out every interface, so this is a whole glow-up 🦋

Lots of switch datasheets say they support IGMP snooping, but no recommendations for it existed yet 😤 The authors hope this document lays that foundation 🫶

The recommendations here are based on these sources: the IGMP specifications [RFC1112], [RFC2236] and [IGMPv3], vendor technical documents [CISCO], bug reports [MSOFT], conversations with people who designed IGMP snooping switches, MAGMA mailing list discussions, and replies from switch vendors to an implementation questionnaire 📚

Interoperability issues between different IGMP versions are not the focus of this doc. If you want a thorough rundown of the problem areas, go read [IGMPv3] 👀

The suggestions here are based on IGMP, which only applies to IPv4 🌸 For IPv6, Multicast Listener Discovery [MLD] must be used instead. Since MLD is based on IGMP, the doc doesn't repeat the whole description and recommendations for MLD snooping switches. Instead it points out the few places where MLD differs from IGMP 🧚

Note that the IGMP snooping function should apply only to IPv4 multicasts 💅 Other multicast packets, like IPv6, might get suppressed by IGMP snooping if the implementation doesn't take extra care, as the recommendations section mentions. It's desired not to restrict the flow of non-IPv4 multicasts beyond what would happen from regular bridging functions 🍓 Likewise, MLD snooping switches are discouraged from using topological information learned from IPv6 traffic to change how IPv4 multicast packets get forwarded ⭐

2. IGMP Snooping Recommendations 🎀

The following sections list the recommendations for an IGMP snooping switch 💖 Each recommendation is stated and then supplemented with a description of a possible implementation approach. All implementation discussions are examples only, and there may well be other ways to get the same functionality 🌈

2.1. Forwarding rules 🦋

The IGMP snooping functionality is split into a control section (IGMP forwarding) and a data section (Data forwarding) 🧠

iykyk, the rest of the forwarding rules are coming in the next part 💅✨

2.1.1. IGMP Forwarding Rules ✨

okay bestie, let's get into the IGMP forwarding rules 🧚

  1. A snooping switch should forward IGMP Membership Reports only to the ports where multicast routers are attached 🦋

Said the other way around: a snooping switch should not forward IGMP Membership Reports to ports that only have hosts attached. An administrative control may be provided to override this restriction, which lets the reports get flooded to other ports 💖

This is the main IGMP snooping functionality for the control path 👑

Sending membership reports to other hosts can, for IGMPv1 and IGMPv2, accidentally stop a host from joining a specific multicast group 😭

When an IGMPv1 or IGMPv2 host sees a membership report for a group address it wants to join, that host will suppress its own membership report for the same group. This join or message suppression is a requirement for IGMPv1 and IGMPv2 hosts. But if a switch doesn't get a membership report from the host, it won't forward multicast data to it 💀

This isn't a problem in an IGMPv3-only network, because there's no suppression of IGMP Membership reports 🌈

The administrative control lets IGMP Membership Report messages get processed by network monitoring gear like packet analyzers or port replicators 🔥

The switch supporting IGMP snooping must keep a list of multicast routers and the ports they're attached to. That list can be built using any combination of these methods:

a) This list should be built by the snooping switch sending Multicast Router Solicitation messages, as described in IGMP Multicast Router Discovery [MRDISC]. It may also snoop Multicast Router Advertisement messages sent by and to other nodes.

b) The arrival port for IGMP Queries (sent by multicast routers) where the source address is not 0.0.0.0.

The 0.0.0.0 address is a special case where the switch is proxying IGMP Queries for faster network convergence, but isn't itself the Querier. The switch doesn't use its own IP address (even if it has one), because that would make the Queries look like they're coming from a newly elected Querier. The 0.0.0.0 address is used to indicate that the Query packets are NOT from a multicast router 🧚

c) Ports explicitly configured by management to be IGMP-forwarding ports, in addition to or instead of any of the above methods to detect router ports ⭐

  1. IGMP networks may also include devices that do "proxy-reporting," where reports received from downstream hosts get summarized and used to build internal membership states. Those proxy-reporting devices may use the all-zeros IP Source-Address when forwarding any summarized reports upstream. For this reason, IGMP membership reports received by the snooping switch must not be rejected just because the source IP address is set to 0.0.0.0 🫶
  2. The switch that supports IGMP snooping must flood all unrecognized IGMP messages to all other ports, and must not try to use any information beyond the end of the network layer header 🌸

Also, earlier versions of IGMP should interpret IGMP fields as defined for their own versions, and must not change these fields when forwarding the message. When generating new messages, a given IGMP version should set fields to the right values for its own version. If any fields are reserved or otherwise undefined for a given IGMP version, those fields should be ignored when parsing the message, and must be set to zeroes when new messages are generated by implementations of that IGMP version. There's one exception: the switch may be performing a spoofing function and knows the settings for new or reserved fields that it would need to spoof correctly for a different IGMP version 🙈

Why do we care about these tiny details? Because IGMPv3 reuses the old IGMP query message with the same type number (0x11), but with an extended header. That means there's a risk that IGMPv3 queries get read as older-version queries by, for example, IGMPv2 snooping switches. This has already been reported [IETF56] and is discussed in section 2.2 🎀

  1. An IGMP snooping switch should be aware of link layer topology changes caused by Spanning Tree operation. When a port is enabled or disabled by Spanning Tree, a General Query may be sent on all active non-router ports to reduce network convergence time. Non-Querier switches should know whether the Querier is in IGMPv3 mode. If it is, the switch should not spoof any General Queries unless it can send an IGMPv3 Query that matches the most recent information sent by the true Querier. In no case should a switch put a spoofed IGMPv2 Query into an IGMPv3 network, since that may cause excessive network disruption 🔥

If the switch is not the Querier, it should use the 'all-zeros' IP Source Address in these proxy queries (even though some hosts may choose not to process queries with a 0.0.0.0 IP Source Address). When such proxy queries are received, they must not be included in the Querier election process 💅

  1. An IGMP snooping switch must not use information in IGMP packets where the IP or IGMP headers have checksum or integrity errors. The switch should not flood such packets, but if it does, it should also make a note of the event (i.e., increment a counter). These errors and how they're handled are discussed further in [IGMPv3], [MLD] and [MLDv2] 🤓
  2. The snooping switch must not rely exclusively on the appearance of IGMP Group Leave announcements to decide when entries should be removed from the forwarding table. It should implement a membership timeout mechanism, such as the router-side functionality of the IGMP protocol described in the IGMP and MLD specifications (see the Normative Reference section for IGMPv1-3 and MLDv1-2), on all its non-router ports. This timeout value should be configurable ⏰

2.1.2. Data Forwarding Rules 💜

  1. Packets with a destination IP address outside 224.0.0.X which are not IGMP should be forwarded according to group-based port membership tables, and must also be forwarded on router ports 🌊

This is the main IGMP snooping functionality for the data path. One approach an implementation could take is to keep separate membership and multicast router tables in software, then "merge" those tables into a forwarding cache 🧁

  1. Packets with a destination IP (DIP) address in the 224.0.0.X range which are not IGMP must be forwarded on all ports 🌈

This recommendation is based on the fact that many host systems don't send Join IP multicast addresses in this range before sending or listening to IP multicast packets. Also, since the 224.0.0.X address range is defined as link-local (not to be routed), it seems unnecessary to keep state for each address in this range. Some routers operate in the 224.0.0.X range without issuing IGMP Joins, and those applications would break if the switch pruned them for not having seen a Join Group message from the router 💀

  1. An unregistered packet is defined as an IPv4 multicast packet with a destination address that doesn't match any of the groups announced in earlier IGMP Membership Reports 👀

If a switch receives an unregistered packet, it must forward that packet on all ports to which an IGMP router is attached. A switch may default to forwarding unregistered packets on all ports. Switches that don't forward unregistered packets to all ports must include a configuration option to force the flooding of unregistered packets on specified ports 🦋

In an environment where IGMPv3 hosts are mixed with snooping switches that don't yet support IGMPv3, the switch's failure to flood unregistered streams could stop v3 hosts from receiving their traffic. On the other hand, in environments where the snooping switch supports all of the IGMP versions that are present, flooding unregistered streams may overwhelm IGMP hosts with multicast traffic, to the point where they don't receive Queries and fail to issue new membership reports for their own groups 😱

It's encouraged that snooping switches at least recognize and process IGMPv3 Join Reports, even if that processing is limited to the behavior for IGMPv2 Joins. In other words, it's done without considering any additional "include source" or "exclude source" filtering. When IGMPv3 Joins aren't recognized, a snooping switch may incorrectly prune off the unregistered data streams for the groups (as noted above). Alternatively, it may fail to add forwarding for new IGMPv3 hosts if the group has previously been joined as IGMPv2, because the data stream is seen as already registered 🫠

  1. All non-IPv4 multicast packets should continue to be flooded out to all remaining ports in the forwarding state, as per normal IEEE bridging operations 🌷

This recommendation exists because groups made up of IPv4 hosts and groups made up of IPv6 hosts are completely separate and distinct. So information learned from the topology between members of an IPv4 group wouldn't apply when forming the topology between members of an IPv6 group ✨

  1. IGMP snooping switches may maintain forwarding tables based on either MAC addresses or IP addresses. If a switch supports both types of forwarding tables, the default behavior should be to use IP addresses. IP address based forwarding is preferred because the mapping between IP multicast addresses and link-layer multicast addresses is ambiguous. In the case of Ethernet, there's a multiplicity of 1 Ethernet address to 32 IP addresses [RFC1112] 🍓
  2. Switches that rely on information in the IP header should verify that the IP header checksum is correct. If the checksum fails, the information in the packet must not be incorporated into the forwarding table. Further, the packet should be discarded 🧯
  3. When IGMPv3 "include source" and "exclude source" membership reports are received on shared segments, the switch needs to forward the superset of all received membership reports onto the shared segment. Forwarding of traffic from a particular source S to a group G must happen if at least one host on the shared segment reports an IGMPv3 membership of the type INCLUDE(G, Slist1) or EXCLUDE(G, Slist2), where S is an element of Slist1 and not an element of Slist2 🎀

How the (G,S1,S2,...) based data forwarding tables get implemented in practice is outside the scope of this document. One possibility is to keep two (G,S) forwarding lists: one for the INCLUDE filter, where a match on a specific (G,S) is required before forwarding happens, and one for the EXCLUDE filter, where a match on a specific (G,S) results in no forwarding 🌟

okay so there's a special problem that pops up in networks with IGMPv3 routers plus IGMPv2 and IGMPv3 hosts, all hooked up through an IGMPv2 snooping switch. This was recently reported in [IETF56] 😭. The router keeps running IGMPv3 even when IGMPv2 hosts are around, so the network never converges on IGMPv2. Meanwhile the IGMPv2 snooping switch will probably not recognize or process the IGMPv3 membership reports. The groups from those unrecognized reports either get flooded (which is a whole mess for hosts when there's a heavy multicast load) or get pruned by the switch. 💀

so, in a network like this, it is recommended that the multicast router be configured to use IGMPv2. If that's not possible, and the snooping switch can't recognize and process the IGMPv3 membership reports, then it is instead recommended that the switch's IGMP snooping functionality be disabled. Why? Because there's no clear solution to this problem, bestie 🫶

3. IPv6 Considerations ✨

okay, so to avoid any confusion, everything we've talked about so far has been based on IGMP, which only applies to IPv4 multicast. With IPv6, most of the above is still valid, with a few exceptions we'll walk through here 🦋

The control and data forwarding rules in the IGMP section can, with a few considerations, also be applied to MLD. So the basic stuff, like intercepting MLD packets and building membership lists and multicast router lists, works the same way it does for IGMP. It's giving consistency 💅

In IPv6, the data forwarding rules are more straight forward, because MLD is mandated for addresses with scope 2 (link-scope) or greater. The only exception is FF02::1, the all hosts link-scope address, which never gets MLD messages sent for it. Packets going to the all hosts link-scope address should be forwarded on all ports. ✨

MLD messages are also not sent for groups with addresses in the range FF00::/15. That range covers both the reserved FF00::/16 and the node-local FF01::/16 IPv6 address spaces. These addresses should never appear in packets on the link. 🙈

Equivalent to the IPv4 behaviors around the null IP Source address, MLD membership reports must not be rejected by an MLD snooping switch because of an unspecified IP source address (::). Also, if a non-Querier switch spoofs any General Queries (as addressed in Section 2.1 above, for Spanning Tree topology changes), the switch should use the null IP source address (::) when sending said queries. When such proxy queries are received, they must not be included in the Querier election process. 👑

The three major differences between IPv4 and IPv6 in relation to multicast are:

  • The IPv6 protocol for multicast group maintenance is called Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message types instead of IGMP message types. 🌈
  • The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 32 of the 128 bit DIP addresses are used to form the 48 bit DMAC addresses for multicast groups, while [IPV6-TOKEN] describes the mapping for token ring DMAC addresses by using three low-order bits. The specification [IPV6-1394] makes use of a 6 bit channel number. 🧚
  • Multicast router discovery is accomplished using the Multicast Router Discovery Protocol (MRDISC) defined in [MRDISC]. 🍓

The IPv6 packet header does not include a checksum field. Nevertheless, the switch should detect other packet integrity issues, such as address version and payload length consistencies, if possible. When the snooping switch detects such an error, it must not include information from the corresponding packet in the MLD forwarding table. The forwarding code should instead drop the packet and take further reasonable actions as advocated above. 😭

The fact that MLDv2 uses ICMPv6 adds new requirements for a snooping switch, because ICMPv6 has multiple uses aside from MLD. That means it's no longer enough to detect that the next-header field of the IP header is ICMPv6 in order to identify packets relevant for MLD snooping. A software-based implementation that treats all ICMPv6 packets as candidates for MLD snooping could easily fill its receive queue and bog down the CPU with irrelevant packets. That would stop the snooping functionality from doing its job, and the non-MLD packets destined for other hosts could get lost. not me getting lost in ICMPv6 🥲

There are two ways to fix this. One is to require that the snooping switch looks further into the packets. The other is to detect a multicast DMAC address in conjunction with ICMPv6. The first solution is desirable when a configuration option lets the administrator specify which ICMPv6 message types should trigger a CPU redirect and which should not. This matters because hardcoding message types is inflexible when new message types come along. The second solution has a risk, though: new protocols that use ICMPv6 and multicast DMAC addresses could be incorrectly identified as MLD. It is suggested that solution one is preferred when the configuration option is provided. If that's not the case, then the implementor should seriously consider making it available, since Neighbor Discovery messages would be among those that fall into this false positive case and are vital for the operational integrity of IPv6 networks. 🔥

The mapping from IP multicast addresses to multicast DMAC addresses introduces a potentially enormous overlap. The structure of an IPv6 multicast address is shown in the figure below. As a result, there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses, which map into a single DMAC address in Ethernet and FDDI. Compare that to 2**5 in the case of IPv4. Iconic levels of overlap 🤯

Initial allocation of IPv6 multicast addresses, as described in [RFC3307], covers only the lower 32 bits of group ID. This reduces the address ambiguity problem to group IDs with different flag and scope values, for now. It should be noted, though, that the allocation policy may change in the future. Because of the potential overlap, it is recommended that IPv6 address based forwarding is preferred to MAC address based forwarding. 🎀

      |   8    |  4 |  4 |             112 bits                  |
      +--------+----+----+---------------------------------------+
      |11111111|flgs|scop|             group ID                  |
      +--------+----+----+---------------------------------------+

4. IGMP Questionnaire ✨

okay so as part of this work, the following questions were asked on the MAGMA discussion list and sent to known switch vendors implementing IGMP snooping. The individual contributions have been anonymized upon request, and they do not necessarily apply to all of the vendors' products. 💖

The questions were:

      Q1  Do your switches perform IGMP Join aggregation?  In other
          words, are IGMP joins intercepted, absorbed by the
          hardware/software so that only one Join is forwarded to the
          querier?

      Q2  Is multicast forwarding based on MAC addresses?  Would
          datagrams addressed to multicast IP addresses 224.1.2.3 and
          239.129.2.3 be forwarded on the same ports-groups?

      Q3  Is it possible to forward multicast datagrams based on IP
          addresses (not routed)?  In other words, could 224.1.2.3 and
          239.129.2.3 be forwarded on different port-groups with
          unaltered TTL?

      Q4  Are multicast datagrams within the range 224.0.0.1 to
          224.0.0.255 forwarded on all ports whether or not IGMP Joins
          have been sent?

      Q5  Are multicast frames within the MAC address range
          01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports
          whether or not IGMP joins have been sent?

      Q6  Does your switch support forwarding to ports on which IP
          multicast routers are attached in addition to the ports where
          IGMP Joins have been received?

      Q7  Is your IGMP snooping functionality fully implemented in
          hardware?

      Q8  Is your IGMP snooping functionality partly software
          implemented?

      Q9  Can topology changes (for example spanning tree configuration
          changes) be detected by the IGMP snooping functionality so
          that for example new queries can be sent or tables can be
          updated to ensure robustness?

The answers were:

         ---------------------------+-----------------------+
                                    |     Switch Vendor     |
         ---------------------------+---+---+---+---+---+---+
                                    | 1 | 2 | 3 | 4 | 5 | 6 |
         ---------------------------+---+---+---+---+---+---+
         Q1 Join aggregation        | x | x | x |   | x | x |
         Q2 Layer-2 forwarding      | x | x | x | x |(1)|   |
         Q3 Layer-3 forwarding      |(1)|   |(1)|   |(1)| x |
         Q4 224.0.0.X aware         |(1)| x |(1)|(2)| x | x |
         Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x |
         Q6 Mcast router list       | x | x | x | x | x | x |
         Q7 Hardware implemented    |   |   |   |   |   |   |
         Q8 Software assisted       | x | x | x | x | x | x |
         Q9 Topology change aware   | x | x | x | x |   |(2)|
         ---------------------------+---+---+---+---+---+---+
                   x  Means that the answer was Yes.
     (1) In some products (typically high-end) Yes; in others No.
     (2) Not at the time that the questionnaire was received
         but expected in the near future.

5. References 📚

5.1. Normative References 🫶

  • [BRIDGE] IEEE Std. 802.1D-2004 IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges
  • [IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
  • [IPV6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, October 2001.
  • [IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
  • [IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.
  • [IPV6-TOKEN] Crawford, M., Narten, T., and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, December 1998.
  • [MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
  • [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
  • [MRDISC] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
  • [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
  • [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
  • [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.

5.2. Informative References 🧚

These are the extra reads if you want to go deeper, not required, but lowkey worth it 📚

6. Security Considerations 🔐

Okay bestie, this one is serious, so listen up 💅 Under normal network operation, the snooping switch is expected to improve overall network performance by limiting the scope of multicast flooding to a smaller portion of the local network ✨ But if someone sends forged IGMP messages, the benefits of using a snooping switch might be reduced or eliminated 💀

Security considerations for IGMPv3 at the network layer of the protocol stack are described in [IGMPv3]. The introduction of IGMP snooping doesn't change how the router handles multicast packets, because the router doesn't make use of link layer information 🎀

There are, however, changes in the way the IGMP snooping switch handles multicast packets inside the local network. In particular:

  • A Query message with a forged source address which is less than that of the current Querier could cause snooping switches to forward subsequent Membership reports to the wrong network interface. It is for this reason that IGMP Membership Reports should be sent to all multicast routers as well as the current Querier 🙈
  • It is possible for a host on the local network to generate Current-State Report Messages that would cause the switch to incorrectly believe that there is a multicast listener on the same network segment as the originator of the forged message. This will cause unrequested multicast packets to be forwarded into the network segments between the source and the router. If the router requires that all Multicast Report messages be authenticated as described in section 9.4 of [IGMPv3], it will discard the forged Report message from the host inside the network in the same way that it would discard one which originates from a remote location. It is worth noting that if the router accepts unauthenticated Report messages by virtue of them having arrived over a network interface associated with the internal network, investigating the affected network segments will quickly narrow the search for the source of the forged messages 🕵️‍♀️
  • As noted in [IGMPv3], there is little motivation for an attacker to forge a Membership report message since joining a group is generally an unprivileged operation. The sender of the forged Membership report will be the only recipient of the multicast traffic to that group. This is in contrast to a shared LAN segment (HUB) or network without snooping switches, where all other hosts on the same segment would be unable to transmit when the network segment is flooding the unwanted traffic 🫶

The worst case result for each attack would remove the performance improvements that the snooping functionality would otherwise provide. It would, however, be no worse than that experienced on a network with switches that do not perform multicast snooping 🌈

7. Acknowledgements 🫶

Huge thank-yous to everyone who gave comments and suggestions on this document, you're all iconic 👑 Martin Bak, Les Bell, Yiqun Cai, Ben Carter, Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret Wasserman.

Also shoutout to the companies who contributed: 3Com, Alcatel, Cisco Systems, Enterasys Networks, Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane. The ordering of these names do not necessarily correspond to the column numbers in the response table 🍓

Authors' Addresses 🖋️

Morten Jagd Christensen
Thrane & Thrane
Lundtoftegaardsvej 93 D
2800 Lyngby
DENMARK

EMail: mjc@tt.dk


Karen Kimball
Hewlett-Packard
8000 Foothills Blvd.
Roseville, CA 95747
USA

EMail: karen.kimball@hp.com


Frank Solensky
Calix
43 Nanog Park
Acton, MA 01720
USA

EMail: frank.solensky@calix.com

Here's the legal stuff, kept exactly as written so nothing gets lost 📜

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💜

The IETF doesn't take a side on whether any IPR claims are valid or how far they reach, and it hasn't done its own digging to find any such rights either 🧐 The procedures for rights in RFC documents live in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses, and the results of any attempt to get a general license for implementers or users can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that info to ietf-ipr@ietf.org.

Acknowledgement ✨

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🎀

📦 where this page comes from