idnits 2.17.00 (12 Aug 2021) /tmp/idnits53496/draft-ietf-idmr-snoop-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 13 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 279: '... MUST NOT send Queries....' RFC 2119 keyword, line 404: '...ort for IGMP packet snooping MUST for-...' RFC 2119 keyword, line 405: '...GMP messages and MUST NOT attempt to m...' RFC 2119 keyword, line 407: '... Reserved fields are non-zero MUST NOT...' RFC 2119 keyword, line 412: '...the group address, it MUST forward the...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2236' is defined on line 488, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BRIDGE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CISCO' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' == Outdated reference: draft-ietf-idmr-igmp-v3 has been published as RFC 3376 == Outdated reference: A later version (-10) exists of draft-ietf-idmr-igmp-mrdisc-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'MSOFT' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDMR Working Group M. Christensen 3 Internet Draft Exbit Technology 4 February 2001 F. Solensky 5 Expiration Date: August 2001 Gotham Networks 7 IGMPv3 and IGMP Snooping switches 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [RFC2026]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo describes the interoperability problems and issues that can 33 arise when a mixed deployment of IGMPv3 and IGMPv2 capable hosts and 34 routers are interconnected by a switch with IGMP snooping 35 capabilities. It is intended as a accompanying document to the 36 IGMPv3 specification. 38 The memo contains a brief IGMP walk through followed by a description 39 of the IGMP snooping functionality. Specific examples are given 40 which are all based on Ethernet as the link layer protocol. Finally 41 recommendations are given for the behavior of IGMP snooping switches. 43 The purpose of this document is twofold: 45 - We want to summarize IGMP snooping induced problems so that IETF 46 can take appropriate actions when deciding on new protocols and 47 behaviors. 49 RFC DRAFT February 2001 51 - We also hope to bring the attention to switch vendors so that we 52 can minimize the interoperability problems in the future. 54 1. Introduction 56 In recent years, a number of commercial vendors have introduced prod- 57 ucts described as "IGMP snooping switches" to the market. These 58 devices do not adhere to the conceptual model that provides the 59 strict separation of functionality between different communications 60 layers in the ISO model and instead utilizes information in the upper 61 level protocol headers as factors to be considered in the processing 62 at the lower levels. This is analogous to the manner in which a 63 router can act as a firewall by looking into the transport protocol's 64 header before allowing a packet to be forwarded to its destination 65 address. 67 In the case of multicast traffic, an IGMP snooping switch provides 68 the benefit of conserving bandwidth on those segments of the network 69 where no node has expressed interest in receiving packets addressed 70 to the group address. 72 2. IGMP snooping overview 74 For a full description of IGMP we refer to [IGMPv3], however, IGMP 75 operation can be summarized in the following: 77 * Hosts send IGMP Membership Report messages to inform neighboring 78 routers that they wish to join a specific IP multicast group. 80 * IGMPv3 Membership Reports may be qualified with a list of allowed 81 or forbidden source addresses. 83 * Routers periodically send IGMP Group Query messages to Hosts in 84 order to maintain group membership state information. These 85 queries can be either general or group specific queries. 87 * Hosts respond to queries with membership Reports. 89 * Hosts running either IGMPv2 or IGMPv3 may also send a Leave Group 90 message to routers to withdraw from the group. 92 A traditional Ethernet network may be separated into different net- 93 work segments to prevent placing too many devices onto the same 94 shared media. These segments are connected by bridges and switches. 96 RFC DRAFT February 2001 98 When a packet with a broadcast or multicast destination address is 99 received, the switch will forward a copy into each of the remaining 100 network segments in accordance with [BRIDGE]. Eventually, the packet 101 is made accessible to all nodes connected to the network. 103 This approach works well for broadcast packets that are intended to 104 be seen or processed by all connected nodes. In the case of multi- 105 cast packets, however, this approach could lead to less efficient use 106 of network bandwidth, particularly when the packet is intended for 107 only a small number of nodes. Packets will be flooded into network 108 segments where no node has any interest in receiving the packet. 109 While nodes will rarely incur any processing overhead to filter pack- 110 ets addressed to unrequested group addresses, they are unable to 111 transmit new packets onto the shared media for the period of time 112 that the multicast packet is flooded. 114 The problem of wasting bandwidth is even worse when the LAN segment 115 is not shared, for example in Full Duplex links. Full Duplex is 116 standard today for most switches operating at 1Gbps or above. In this 117 case the bandwidth that is wasted is proportional to the number of 118 attached nodes. 120 Allowing switches to snoop IGMP packets is a creative effort to solve 121 this problem. The switch uses the information in the IGMP packets as 122 they are being flooded throughout the network to determine which seg- 123 ments should receive packets directed to the group address. 125 IGMP snooping is being implemented slightly different by different 126 switch vendors. We will not address specific implementations here as 127 documentation is not widely available. For details of one implementa- 128 tion we refer to [CISCO]. 130 In the following we will describe problems in relation to IGMP snoop- 131 ing with the following constraints, which we believe are the most 132 common cases. 134 1. Group membership is based on multicast MAC addresses only. 136 2. Forwarding is based on port masks for each supported multicast 137 group. 139 3. The switch is equipped with a CPU for maintaining group member- 140 ship information. 142 Constraint 3 above is not a strict requirement as IGMP snooping could 143 be accomplished entirely in hardware. However it becomes more diffi- 144 cult to support future modifications to the protocol. 146 RFC DRAFT February 2001 148 IGMP snooping switches build forwarding lists by listening for (and 149 in some cases intercepting) IGMP messages. Although the software 150 processing the IGMP messages may maintain state information based on 151 the full IP group addresses, the forwarding tables are typically 152 mapped to link layer addresses. An example of such a forwarding 153 table is shown in Figure 1. 155 Multicast MAC address | Member ports 156 ------------------------------------- 157 01-00-5e-00-00-01 | 2, 7 158 01-00-5e-01-02-03 | 1, 2, 3, 7 159 01-00-5e-23-e2-05 | 1, 4 160 ------------------------------------- 161 Figure 1. 163 Because only the least significant 23 bits of the IP address are 164 mapped to Ethernet addresses [RFC1112], there is a loss of informa- 165 tion when forwarding solely on the destination MAC address. This 166 means that for example 224.0.0.123 and 239.128.0.123 and similar IP 167 multicast addresses all map to MAC address 01-00-5e-00-00-7b (for 168 Ethernet). As a consequence, IGMP snooping switches may collapse IP 169 multicast group memberships into a single Ethernet multicast member- 170 ship group. 172 Finally, it should be mentioned that in addition to building and 173 maintaining lists of multicast group memberships the snooping switch 174 should also maintain a list of multicast routers. When forwarding 175 multicast packets they should be forwarded on ports which have 176 expressed joined using IGMP but also on ports on which multicast 177 routers are attached. 179 2.1. Problems in older networks 181 The drawback of using IGMP snooping switches to make the flooding of 182 multicast traffic more efficient is that the underlying link layer 183 topology is required to remain very stable. This is especially true 184 in IGMP versions 1 and 2 where group members do not transmit member- 185 ship report messages after having overheard a report from another 186 group member. 188 This problem can be demonstrated with an example. In the topology 189 illustrated in figure 2, a topology loop exists between four IGMP 190 snooping switches labeled A, B, C and D. 192 - The spanning tree algorithm would detect this loop and disable 193 one of the links; for example, the link connecting ports B3 and 195 RFC DRAFT February 2001 197 C1. 199 - Node N1 transmits a group membership report which will be flooded 200 throughout the network. 202 - When switch A hears the report, it determines that packets 203 addressed to the group should be forwarded to port A3. 205 - Router R hears the Join message and starts forwarding packets 206 with the multicast destination address into the network. Node N1 207 is now part of the group. 209 - The link between D2 and C2 is broken. The spanning tree algo- 210 rithm reactivates the blocked link B3-C1. 212 - If switch A relies solely on the exchange of IGMP messages to 213 alter its forwarding behavior, node N1 will be unable to receive 214 packets forwarded to the group address until router R sends out 215 another membership query request. 217 +------+ B2 218 B1 | |----- - - - +------+ 219 -----| SS B | | Node | 220 / | |----- / | N1 | 221 +--------+ A2 / +------+ B3 X C1 +------+ +--+---+ 222 A1 | |----- / -----| | | 223 --+----| Switch | | SS C |-----+---- 224 | | A |----- -----| | C3 225 +-+-+ +--------+ A3 \ +------+ D2 / C2 +------+ 226 | R | \ D1 | |----- 227 ++-++ -----| SS D | 228 | | | |---------+------ - - - 229 +------+ D3 | 230 +--+---+ 231 | Node | 232 | N2 | 233 +------+ 234 Figure 2 236 One possible approach to work around this limitation would be for the 237 switch to keep track of which nodes belong to the group, altering the 238 forwarding tables whenever a member becomes visible through a different 239 port. When switch A sees that node N1 has moved from port A3 to A2, the 240 group membership table would be updated. This does not work, however, 241 when more than one node joins the same group address when at least one 242 of them has not yet been upgraded to IGMPv3: if nodes N1 and N2 were to 243 join the group at approximately the same time, they would both start off 244 random timers for the transmission of their first membership report 245 RFC DRAFT February 2001 247 messages. If node N2 selects a longer interval than N1, it will hear 248 N1's report message and cancel the one it was about to send. Switch A, 249 therefore, never learns that node N2 has joined the group. When the 250 switch learns that N1 is now accessible through port A2, it has no way 251 of knowing that it should continue forwarding group packets to port A3 252 as well. 254 2.2. IGMPv2 snooping and 224.0.0.X 256 Special attention should be brought to the address range from 257 224.0.0.0 through 224.0.0.255 which is reserved for routing protocols 258 and other low-level topology discovery or maintenance protocols 259 [IANA]. Examples of reserved multicast addresses are: 261 224.0.0.2 All Routers on this Subnet 262 224.0.0.4 DVMRP 263 224.0.0.5 MOSPF 264 224.0.0.6 MOSPF 265 224.0.0.9 RIP2 Routers 266 224.0.0.13 PIM Routers 267 224.0.0.22 IGMPv3 Membership Reports 269 Multicast routers are discouraged from routing packets with a desti- 270 nation address falls within this range, regardless of the TTL value. 271 The router will be the originator or consumer of these messages so it 272 has less of a motivation to maintain forwarding path information for 273 these addresses. As a result, it becomes less critical for the 274 router to send out periodic Query messages for these groups. If the 275 router chooses not to the group would be unable to recover from 276 topology changes as described above. Note that the only difference 277 between the 'all hosts' address (224.0.0.1) and the remainder of this 278 range is that the router has no discretion in the former case: it 279 MUST NOT send Queries. 281 To avoid this situation, IGMP snooping switches should be less con- 282 servative when forwarding packets to these addresses and flood them 283 to all ports. 285 It is reported in [MSOFT] that a number of switches can be mis- con- 286 figured to perform IGMP snooping and forwarding for all IP multi- 287 cast groups. 289 Figure 3 illustrates one scenario where two routers R1 and R2 are 290 communicating using for example 224.0.0.6. The routers never send 291 IGMP joins for this address. The switch floods the (unknown) multi- 292 cast traffic on all ports. 294 RFC DRAFT February 2001 296 Now the server SVR is started and it sends an IGMP join for 297 224.0.0.6, which is snooped by the switch. It then generates a mem- 298 bership query on all ports to determine which ports have devices that 299 also belong to this group. 301 The routers R1 and R2 do not respond and the switch builds a forward- 302 ing port list with only SVR in it. Now R1 and R2 are not able to 303 communicate using this address. 305 +----+ +----------+ 306 | R1 |-----| | 307 +----+ | Snooping | +-----+ 308 | |----| SVR | 309 +----+ | switch | +-----+ 310 | R2 |-----| | 311 +----+ +----------+ 313 Figure 3. 315 There are two possible fixes to this problem: One is to require that 316 all routers (also being hosts) which use IP multicast responds to 317 IGMP queries in the range 224.0.0.X. This seems unnecessary as dis- 318 cussed above because of the inherent link local scope of these mes- 319 sages. 321 Another solution to this problem, which is also discussed above, is 322 that the switch is configured to forward all packets for a range of 323 IP multicast addresses to all ports (flooding). 325 It is suggested that all multicast packets in the range 224.0.0.1 326 through 224.0.0.255 are forwarded on all ports. 328 2.3. IGMPv2 and IGMPv3 coexistence 330 Consider the following sequence of communication (figure 4.): 332 - Router R sends IGMPv3 Query 334 - Host H1 sends IGMPv2 Report (since it has only implemented v2). 336 - switch S puts H1's port P1 in the flooding list. 338 - Host H2 sends IGMPv3 Report. 340 - Switch S fails to put H2's port P2 in the flooding list because 341 it doesn't support IGMPv3. 343 RFC DRAFT February 2001 345 - H2 never sees any traffic. 346 {{need to provide description of solution that allows this. Step 4 347 sounds wrong}} 349 2.4. Source Specific Joins 351 Even for IGMPv3 snooping capable switches there can be limitations 352 caused by link layer based forwarding. This is illustrated in figure 353 4. 355 Assume that host H1 sends a Join(S1, G) to R and that host H2 sends a 356 Join(S2, G) to R. 358 The switch adds both hosts to the forwarding list for group G. 360 Frames originating from sources S1 and S2 for the same multicast 361 address G are routed via R. These are sent from R with the router's 362 MAC address as source. 364 The switch is unable to distinguish the two different types of flow 365 and forwards both flows to both hosts. This effectively disables the 366 Join source functionality in this network configuration. 368 +----+ +----------+ 369 | H1 |-----| | 370 +----+ | Snooping | +---+ 371 | |----| R |---(S1, G) and (S2, G) 372 +----+ | switch | +---+ 373 | H2 |-----| | 374 +----+ +----------+ 376 Figure 4. 378 This is a problem without an obvious solution because of the differ- 379 ence between the link layer and the network layer information. 381 One approach would be for the switch to simply flood the packets to 382 both ports. This requires that the host implementations do not rely 383 on the router to perform all of the source address filtering for the 384 group address: they must still filter out packets that do not match 385 the source address criteria specified in the join messages. While 386 this might be seen as an inconvience, this is no different than the 387 case where the router is directly connected to both hosts on a shared 388 LAN and no snooping switch is present. 390 An alternative approach would be for the switch to further qualify 391 the search process by including source address when determining which 393 RFC DRAFT February 2001 395 ports should forward the packet. While this could work for very sim- 396 ple cases, it is unlikely that this approach could scale into more 397 complex topologies or provide satisfactory performance in even the 398 simple cases. 400 Similar problems occur with the attempt to exclude sources. 402 3. Snooping Requirements 404 The switch that provides support for IGMP packet snooping MUST for- 405 ward all unrecognized IGMP messages and MUST NOT attempt to make use 406 of any information beyond the end of the network layer header. In 407 particular, messages where any Reserved fields are non-zero MUST NOT 408 be snooped since this could indicate an incompatible change to the 409 message format. 411 If a switch receives a multicast packet without having first pro- 412 cessed Membership Reports for the group address, it MUST forward the 413 packet into all active network segments. In other words, the switch 414 must allow for the possibility that connected hosts and routers have 415 been upgraded to support future versions or extensions of IGMP that 416 the switch does not yet recognize. A switch MAY have a configuration 417 option that suppresses this operation, but default behavior MUST be 418 to allow flooding of unregistered packets. 420 In order to operate correctly, the switch supporting IGMP snooping 421 MUST also maintain a list of multicast routers. This list SHOULD be 422 built using IGMP Multicast Router Discovery [MRDISC] which is cur- 423 rently going through IETF Last Call. IGMP snooping switches MAY in 424 addition use information about which ports packets for the address 425 224.0.0.X range arrive, when 427 - The packets are IGMP Queries or 429 - The packets are anything but IGMP or 431 - The ports are manually configured as having multicast routers 432 attached 434 4. Security Considerations 436 Security considerations for IGMPv3 are accounted for in [IGMPv3]. 437 The introduction of IGMP snooping switches adds the following consid- 438 erations with regard to IP multicast. 440 RFC DRAFT February 2001 442 The exclude source failure which could cause traffic from sources 443 that are 'black listed' to reach hosts that have requested otherwise. 444 This can also occur in certain network topologies without IGMP snoop- 445 ing. 447 It is possible to generate packets which make the switch wrongly 448 believe that there is a multicast router on the segment on which the 449 sender is attached. This will potentially lead to excessive flooding 450 on that segment. The authentication methods discussed in [IGMPv3] 451 will also provide protection in this case. 453 Generally though, it is worth to stress that IP multicast must so far 454 be considered insecure until the work of for example the suggested 455 Multicast Security (MSEC) working group or similar is completed or at 456 lease has matured. 458 5. References 460 [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" 462 [CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP 463 and IGMP snooping" 465 [IANA] Internet Assigned Numbers Authority, "Internet Multicast 466 Addresses", http://www.isi.edu/in-notes/iana/assign- 467 ments/multicast-addresses 469 [IGMPv3] Cain, B., "Internet Group Management Protocol, Version 470 3", draft-ietf-idmr-igmp-v3-06.txt, November 2000 472 [MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft-ietf- 473 idmr-igmp-mrdisc-05.txt, October 2000. 475 [MSOFT] Microsoft support article Q223136, "Some LAN Switches 476 with IGMP Snooping Stop Forwarding Multicast Packets on 477 RRAS Startup", http://support.microsoft.com/sup- 478 port/kb/articles/Q223/1/36.ASP 480 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 481 1112, August 1989. 483 RFC DRAFT February 2001 485 [RFC2026] Bradner, S. "The Internet Standards Process -- Revision 486 3", RFC2026, October 1996. 488 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 489 2", RFC2236, November 1997. 491 6. Author's Addresses: 493 Morten Jagd Christensen 494 Exbit Technology 495 Hoerkaer 18 496 2730 Herlev 497 DENMARK 498 email: mjc@exbit.dk 500 Frank Solensky 501 Gotham Networks 502 15 Discovery Way 503 Acton, MA 01720 504 USA 505 email: fsolensky@GothamNetworks.com (effective 09 March 2001) 506 solensky@acm.org 508 RFC DRAFT February 2001 510 Table of Contents 512 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 513 2. IGMP snooping overview . . . . . . . . . . . . . . . . . . . . . 2 514 2.1. Problems in older networks . . . . . . . . . . . . . . . . . . 4 515 2.2. IGMPv2 snooping and 224.0.0.X . . . . . . . . . . . . . . . . . 6 516 2.3. IGMPv2 and IGMPv3 coexistence . . . . . . . . . . . . . . . . . 7 517 2.4. Source Specific Joins . . . . . . . . . . . . . . . . . . . . . 8 518 3. Snooping Requirements . . . . . . . . . . . . . . . . . . . . . . 9 519 4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 9 520 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 521 6. Author's Addresses: . . . . . . . . . . . . . . . . . . . . . . . 11