idnits 2.17.00 (12 Aug 2021) /tmp/idnits47260/draft-ietf-magma-snoop-11.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. 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.) == There are 6 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 774: '...ll occurances of MUST, MAY etc. to low...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 749 has weird spacing: '...rrected a ref...' -- 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.) -- The document date (May 2004) is 6579 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PROXY' is mentioned on line 700, but not defined == Unused Reference: 'IANA' is defined on line 926, but no explicit reference was found in the text == Outdated reference: draft-vida-mld-v2 has been published as RFC 3810 == Outdated reference: draft-ietf-magma-mrdisc has been published as RFC 4286 ** Obsolete normative reference: RFC 2461 (ref. 'NDP') (Obsoleted by RFC 4861) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Christensen 3 Internet Draft Thrane & Thrane 4 Expiration Date: November 2004 K. Kimball 5 Category: Informational Hewlett-Packard 6 F. Solensky 7 West Ridge Networks 8 May 2004 10 Considerations for IGMP and MLD Snooping Switches 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [RFC2026]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This memo describes the recommendations for IGMP- and MLD-snooping 42 switches. These are based on best current practices for IGMPv2, 43 with further considerations for IGMPv3- and MLDv2-snooping. 44 Additional areas of relevance, such as link layer topology changes 45 and Ethernet-specific encapsulation issues, are also considered. 47 MLD Snooping Switches 49 1. Introduction 51 The IEEE bridge standard [BRIDGE] specifies how LAN packets are 52 'bridged', or as is more commonly used today, switched between LAN 53 segments. The operation of a switch with respect to multicast 54 packets can be summarized as follows. When processing a packet 55 whose destination MAC address is a multicast address, the switch 56 will forward a copy of the packet into each of the remaining 57 network interfaces that are in the forwarding state in accordance 58 with [BRIDGE]. The spanning tree algorithm ensures that the 59 application of this rule at every switch in the network will make 60 the packet accessible to all nodes connected to the network. 62 This behaviour works well for broadcast packets that are intended 63 to be seen or processed by all connected nodes. In the case of 64 multicast packets, however, this approach could lead to less 65 efficient use of network bandwidth, particularly when the packet is 66 intended for only a small number of nodes. Packets will be flooded 67 into network segments where no node has any interest in receiving 68 the packet. While nodes will rarely incur any processing overhead 69 to filter packets addressed to unrequested group addresses, they 70 are unable to transmit new packets onto the shared media for the 71 period of time that the multicast packet is flooded. In general, 72 significant bandwidth can be wasted by flooding. 74 In recent years, a number of commercial vendors have introduced 75 products described as "IGMP snooping switches" to the market. 76 These devices do not adhere to the conceptual model that provides 77 the strict separation of functionality between different 78 communications layers in the ISO model, and instead utilize 79 information in the upper level protocol headers as factors to be 80 considered in processing at the lower levels. This is analogous to 81 the manner in which a router can act as a firewall by looking into 82 the transport protocol's header before allowing a packet to be 83 forwarded to its destination address. 85 In the case of IP multicast traffic, an IGMP snooping switch 86 provides the benefit of conserving bandwidth on those segments of 87 the network where no node has expressed interest in receiving 88 packets addressed to the group address. This is in contrast to 89 normal switch behavior where multicast traffic is typically 90 forwarded on all interfaces. 92 Many switch datasheets state support for IGMP snooping, but no 93 recommendations for this exist today. It is the authors' hope that 94 the information presented in this draft will supply this 95 foundation. 97 MLD Snooping Switches 99 The recommendations presented here are based on the following 100 information sources: The IGMP specifications [RFC1112], [RFC2236] 101 and [IGMPv3], vendor-supplied technical documents [CISCO], bug 102 reports [MSOFT], discussions with people involved in the design of 103 IGMP snooping switches, MAGMA mailing list discussions, and on 104 replies by switch vendors to an implementation questionnaire. 106 Interoperability issues that arise between different versions of 107 IGMP are not the focus of this document. Interested readers are 108 directed to [IGMPv3] for a thorough description of problem areas. 110 The suggestions in this document are based on IGMP, which applies 111 only to IPv4. For IPv6, Multicast Listener Discovery [MLD] must be 112 used instead. Because MLD is based on IGMP, we do not repeat the 113 entire description and recommendations for MLD snooping switches. 114 Instead, we point out the few cases where there are differences 115 from IGMP. 117 Note that the IGMP snooping function should apply only to IPv4 118 multicasts. Other multicast packets, such as IPv6, might be 119 suppressed by IGMP snooping if additional care is not taken in the 120 implementation as mentioned in the recommendations section. It is 121 desired not to restrict the flow of non-IPv4 multicasts other than 122 to the degree which would happen as a result of regular bridging 123 functions. Likewise, MLD snooping switches are discouraged from 124 using topological information learned from IPv6 traffic to alter 125 the forwarding of IPv4 multicast packets. 127 2. IGMP Snooping Recommendations 129 The following sections list the recommendations for an IGMP 130 snooping switch. The recommendation is stated and is supplemented 131 by a description of a possible implementation approach. All 132 implementation discussions are examples only and there may well be 133 other ways to achieve the same functionality. 135 2.1. Forwarding rules 137 The IGMP snooping functionality is separated into a control section 138 (IGMP forwarding) and a data section (Data forwarding). 140 2.1.1. IGMP Forwarding Rules 142 1) A snooping switch should forward IGMP Membership Reports only 143 to those ports where multicast routers are attached. 145 MLD Snooping Switches 147 Alternatively stated: a snooping switch should not forward IGMP 148 Membership Reports to ports on which only hosts are attached. 149 An administrative control may be provided to override this 150 restriction, allowing the report messages to be flooded to 151 other ports. 153 This is the main IGMP snooping functionality for the control 154 path. 156 Sending membership reports to other hosts can result, for 157 IGMPv1 and IGMPv2, in unintentionally preventing a host from 158 joining a specific multicast group. 160 When an IGMPv1 or IGMPv2 host receives a membership report for 161 a group address that it is intending to join, the host will 162 suppress its own membership report for the same group. This 163 join or message suppression is a requirement for IGMPv1 and 164 IGMPv2 hosts. However, if a switch does not receive a 165 membership report from the host it will not forward multicast 166 data to it. 168 This is not a problem in an IGMPv3-only network because there 169 is no suppression of IGMP Membership reports. 171 The administrative control allows IGMP Membership Report 172 messages to be processed by network monitoring equipment such 173 as packet analyzers or port replicators. 175 The switch supporting IGMP snooping must maintain a list of 176 multicast routers and the ports on which they are attached. 177 This list can be constructed in any combination of the 178 following ways: 180 a) This list should be built by the snooping switch sending 181 Multicast Router Solicitation messages as described in IGMP 182 Multicast Router Discovery [MRDISC]. It may also snoop 183 Multicast Router Advertisement messages sent by and to 184 other nodes. 186 b) The arrival port for IGMP Queries (sent by multicast 187 routers) where the source address is not 0.0.0.0. 189 The 0.0.0.0 address represents a special case where the 190 switch is proxying IGMP Queries for faster network 191 convergence, but is not itself the Querier. The switch 192 does not use its own IP address (even if it has one), 193 because this would cause the Queries to be seen as coming 194 from a newly elected Querier. The 0.0.0.0 address is used 195 MLD Snooping Switches 197 to indicate that the Query packets are NOT from a multicast 198 router. 200 c) Ports explicitly configured by management to be IGMP- 201 forwarding ports, in addition to or instead of any of the 202 above methods to detect router ports. 204 2) IGMP networks may include devices which implement "proxy- 205 reporting", in which reports received from downstream hosts are 206 summarized and used to build internal membership states. Such 207 proxy-reporting devices may use the all-zeros address when 208 forwarding any summarized reports upstream. For this reason, 209 IGMP membership reports received by the snooping switch must 210 not be rejected because of a source IP address of 0.0.0.0. 212 3) The switch that supports IGMP snooping must flood all 213 unrecognized IGMP messages to all other ports and must not 214 attempt to make use of any information beyond the end of the 215 network layer header. 217 In addition, earlier versions of IGMP should interpret IGMP 218 fields as defined for their versions and must not alter these 219 fields when forwarding the message. When generating new 220 messages, a given IGMP version should set fields to the 221 appropriate values for its own version. If any fields are 222 reserved or otherwise undefined for a given IGMP version, the 223 fields should be ignored when parsing the message and must be 224 set to zeroes when new messages are generated by 225 implementations of that IGMP version. An exception may occur 226 if the switch is performing a spoofing function, and is aware 227 of the settings for new or reserved fields that would be 228 required to correctly spoof for a different IGMP version. 230 The reason to worry about these trivialities is that IGMPv3 231 overloads the old IGMP query message using the same type number 232 (0x11) but with an extended header. Therefore there is a risk 233 that IGMPv3 queries may be interpreted as older version queries 234 by, for example, IGMPv2 snooping switches. This has already 235 been reported [IETF56] and is discussed in section 2.2. 237 4) An IGMP snooping switch should be aware of link layer topology 238 changes caused by Spanning Tree operation. When a port is 239 enabled or disabled by Spanning Tree, a General Query may be 240 sent on all active non-router ports in order to reduce network 241 convergence time. Non-Querier switches should be aware of 242 whether the Querier is in IGMPv3 mode. If so, the switch should 243 not spoof any General Queries unless it is able to send an 244 MLD Snooping Switches 246 IGMPv3 Query that adheres to the most recent information sent 247 by the true Querier. In no case should a switch introduce a 248 spoofed IGMPv2 Query into an IGMPv3 network, as this may create 249 excessive network disruption. 251 If the switch is not the Querier, it should use the 'all-zeros' 252 IP Source Address in these proxy queries (even though some 253 hosts may elect to not process queries with a 0.0.0.0 IP Source 254 Address). When such proxy queries are received, they must not 255 be included in the Querier election process. 257 5) An IGMP snooping switch must not make use of information in 258 IGMP packets where the IP or IGMP headers have checksum or 259 integrity errors. The switch should not flood such packets but 260 if it does, it should also take some note of the event (i.e., 261 increment a counter). These errors and their processing are 262 further discussed in [IGMPv3], [MLD] and [MLDv2]. 264 6) The snooping switch must not rely exclusively on the appearance 265 of IGMP Group Leave announcements to determine when entries 266 should be removed from the forwarding table. It should 267 implement a membership timeout mechanism such as the router- 268 side functionality of the IGMP protocol as described in the 269 IGMP and MLD specifications (See Normative Reference section 270 for IGMPv1-3 and MLDv1-2) on all its non-router ports. This 271 timeout value should be configurable. 273 2.1.2. Data Forwarding Rules 275 1) Packets with a destination IP address outside 224.0.0.X which 276 are not IGMP should be forwarded according to group-based port 277 membership tables and must also be forwarded on router ports. 279 This is the main IGMP snooping functionality for the data path. 281 One approach that an implementation could take would be to 282 maintain separate membership and multicast router tables in 283 software and then "merge" these tables into a forwarding cache. 285 2) Packets with a destination IP (DIP) address in the 224.0.0.X 286 range which are not IGMP must be forwarded on all ports. 288 This recommendation is based on fact that many host systems do 289 not send Join IP multicast addresses in this range before 290 sending or listening to IP multicast packets. Furthermore, 291 since the 224.0.0.X address range is defined as link-local (not 292 to be routed) it seems unnecessary to keep state for each 293 MLD Snooping Switches 295 address in this range. Additionally, some routers operate in 296 the 224.0.0.X address range without issuing IGMP Joins, and 297 these applications would break if the switch were to prune them 298 due to not having seen a Join Group message from the router. 300 3) An unregistered packet is defined as an IPv4 multicast packet 301 with a destination address which does not match any of the 302 groups announced in earlier IGMP Membership Reports. 304 If a switch receives an unregistered packet, it must forward 305 that packet on all ports to which an IGMP router is attached. 306 A switch may default to forwarding unregistered packets on all 307 ports. Switches that do not forward unregistered packets to 308 all ports must include a configuration option to force the 309 flooding of unregistered packets on specified ports. 311 In an environment where IGMPv3 hosts are mixed with snooping 312 switches that do not yet support IGMPv3, the switch's failure 313 to flood unregistered streams could prevent v3 hosts from 314 receiving their traffic. Alternatively, in environments where 315 the snooping switch supports all of the IGMP versions that are 316 present, flooding unregistered streams may cause IGMP hosts to 317 be overwhelmed by multicast traffic, even to the point of not 318 receiving Queries and failing to issue new membership reports 319 for their own groups. 321 It is encouraged that snooping switches at least recognize and 322 process IGMPv3 Join Reports, even if this processing is limited 323 to the behavior for IGMPv2 Joins, i.e., is done without 324 considering any additional "include source" or "exclude source" 325 filtering. When IGMPv3 Joins are not recognized, a snooping 326 switch may incorrectly prune off the unregistered data streams 327 for the groups (as noted above); alternatively, it may fail to 328 add in forwarding to any new IGMPv3 hosts if the group has 329 previously been joined as IGMPv2 (because the data stream is 330 seen as already having been registered). 332 4) All non-IPv4 multicast packets should continue to be flooded 333 out all remaining ports in the forwarding state as per normal 334 IEEE bridging operations. 336 This recommendation is a result of the fact that groups made up 337 of IPv4 hosts and IPv6 hosts are completely separate and 338 distinct groups. As a result, information gleaned from the 339 topology between members of an IPv4 group would not be 340 applicable when forming the topology between members of an IPv6 341 group. 343 MLD Snooping Switches 345 5) IGMP snooping switches may maintain forwarding tables based on 346 either MAC addresses or IP addresses. If a switch supports 347 both types of forwarding tables then the default behavior 348 should be to use IP addresses. IP address based forwarding is 349 preferred because the mapping between IP multicast addresses 350 and link-layer multicast addresses is ambiguous. In the case 351 of Ethernet, there is a multiplicity of 1 Ethernet address to 352 32 IP addresses [RFC1112]. 354 6) Switches which rely on information in the IP header should 355 verify that the IP header checksum is correct. If the checksum 356 fails, the information in the packet must not be incorporated 357 into the forwarding table. Further, the packet should be 358 discarded. 360 7) When IGMPv3 "include source" and "exclude source" membership 361 reports are received on shared segments, the switch needs to 362 forward the superset of all received membership reports onto 363 the shared segment. Forwarding of traffic from a particular 364 source S to a group G must happen if at least one host on the 365 shared segment reports an IGMPv3 membership of the type 366 INCLUDE(G, Slist1) or EXCLUDE(G, Slist2) where S is an element 367 of Slist1 and not an element of Slist2. 369 The practical implementation of the (G,S1,S2,...) based data 370 forwarding tables are not within the scope of this document. 371 However, one possibility is to maintain two (G,S) forwarding 372 lists: one for the INCLUDE filter where a match of a specific 373 (G,S) is a requirement before forwarding will happen, and one 374 for the EXCLUDE filter where a match of a specific (G,S) will 375 result in no forwarding. 377 2.2. IGMP snooping-related problems 379 A special problem arises in networks consisting of IGMPv3 routers 380 as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 381 snooping switch as recently reported [IETF56]. The router will 382 continue to maintain IGMPv3 even in the presence of IGMPv2 hosts, 383 and thus the network will not converge on IGMPv2. But it is likely 384 that the IGMPv2 snooping switch will not recognize or process the 385 IGMPv3 membership reports. Groups for these unrecognized reports 386 will then either be flooded (with all of the problems that may 387 create for hosts in a network with a heavy multicast load) or 388 pruned by the snooping switch. 390 Therefore, it is recommended that in such a network, the multicast 391 MLD Snooping Switches 393 router be configured to use IGMPv2. If this is not possible, and if 394 the snooping switch cannot recognize and process the IGMPv3 395 membership reports, it is instead recommended that the switch's 396 IGMP snooping functionality be disabled, as there is no clear 397 solution to this problem. 399 3. IPv6 Considerations 401 In order to avoid confusion, the previous discussions have been 402 based on the IGMP protocol which only applies to IPv4 multicast. 403 In the case of IPv6 most of the above discussions are still valid 404 with a few exceptions which we will describe here. 406 The control and data forwarding rules in the IGMP section can, with 407 a few considerations, also be applied to MLD. This means that the 408 basic functionality of intercepting MLD packets, and building 409 membership lists and multicast router lists, is the same as for 410 IGMP. 412 In IPv6, the data forwarding rules are more straight forward 413 because MLD is mandated for addresses with scope 2 (link-scope) or 414 greater. The only exception is the address FF02::1 which is the 415 all hosts link-scope address for which MLD messages are never sent. 416 Packets with the all hosts link-scope address should be forwarded 417 on all ports. 419 MLD messages are also not sent regarding groups with addresses in 420 the range FF00::/15 (which encompasses both the reserved FF00::/16 421 and node-local FF01::/16 IPv6 address spaces). These addresses 422 should never appear in packets on the link. 424 Equivalent to the IPv4 behaviors regarding the null IP Source 425 address, MLD membership reports must not be rejected by an MLD 426 snooping switch because of an unspecified IP source address (::). 427 Additionally, if a non-Querier switch spoofs any General Queries 428 (as addressed in Section 2.1 above, for Spanning Tree topology 429 changes), the switch should use the null IP source address (::) 430 when sending said queries. When such proxy queries are received, 431 they must not be included in the Querier election process. 433 The three major differences between IPv4 and IPv6 in relation to 434 multicast are: 436 - The IPv6 protocol for multicast group maintenance is called 437 Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message 438 types instead of IGMP message types. 440 MLD Snooping Switches 442 - The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128 443 bit DIP address are used to form the 48 bit DMAC addresses for 444 multicast groups, while [IPV6-TOKEN] describes the mapping for 445 token ring DMAC addresses by using three low-order bits. The 446 specification [IPV6-1394] makes use of a 6 bit channel number. 448 - Multicast router discovery is accomplished using Neighbor 449 Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message 450 types. 452 The IPv6 packet header does not include a checksum field. 453 Nevertheless, the switch should detect other packet integrity 454 issues such as address version and payload length consistencies if 455 possible. When the snooping switch detects such an error, it must 456 not include information from the corresponding packet in the MLD 457 forwarding table. The forwarding code should instead drop the 458 packet and take further reasonable actions as advocated above. 460 The fact that MLDv2 is using ICMPv6 adds new requirements to a 461 snooping switch because ICMPv6 has multiple uses aside from MLD. 462 This means that it is no longer sufficient to detect that the next- 463 header field of the IP header is ICMPv6 in order to identify 464 packets relevant for MLD snooping. A software-based implemention 465 which treats all ICMPv6 packets as candidates for MLD snooping 466 could easily fill its receive queue and bog down the CPU with 467 irrelevant packets. This would prevent the snooping functionality 468 from performing its intended purpose and the non-MLD packets 469 destined for other hosts could be lost. 471 A solution is either to require that the snooping switch looks 472 further into the packets, or to be able to detect a multicast DMAC 473 address in conjunction with ICMPv6. The first solution is 474 desirable when a configuration option allows the administrator to 475 specify which ICMPv6 message types should trigger a CPU redirect 476 and which should not. The reason is that a hardcoding of message 477 types is inflexible for the introduction of new message types. The 478 second solution introduces the risk that new protocols which use 479 ICMPv6 and multicast DMAC addresses could be incorrectly identified 480 as MLD. It is suggested that solution one is preferred when the 481 configuration option is provided. If this is not the case, then 482 the implementor should seriously consider making it available since 483 Neighbor Discovery messages would be among those that fall into 484 this false positive case and are vital for the operational 485 integrity of IPv6 networks. 487 The mapping from IP multicast addresses to multicast DMAC addresses 488 introduces a potentially enormous overlap. The structure of an 489 IPv6 multicast address is shown in the figure below. As a result, 490 MLD Snooping Switches 492 there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses 493 which map into a single DMAC address in Ethernet and FDDI. This 494 should be compared to 2**5 in the case of IPv4. 496 Initial allocation of IPv6 multicast addresses as described in 497 [RFC3307], however, cover only the lower 32 bits of group ID. 498 While this reduces the problem of address ambiguity to group IDs 499 with different flag and scope values for now, it should be noted 500 that the allocation policy may change in the future. Because of 501 the potential overlap it is recommended that IPv6 address based 502 forwarding is preferred to MAC address based forwarding. 504 | 8 | 4 | 4 | 112 bits | 505 +--------+----+----+---------------------------------------+ 506 |11111111|flgs|scop| group ID | 507 +--------+----+----+---------------------------------------+ 509 4. IGMP Questionnaire 511 As part of this work the following questions were asked both on the 512 MAGMA discussion list and sent to known switch vendors implementing 513 IGMP snooping. The individual contributions have been anonymized 514 upon request and do not necessarily apply to all of the vendors' 515 products. 517 The questions were: 519 Q1 Does your switches perform IGMP Join aggregation? In other 520 words, are IGMP joins intercepted, absorbed by the 521 hardware/software so that only one Join is forwarded to the 522 querier? 524 Q2 Is multicast forwarding based on MAC addresses? Would 525 datagrams addressed to multicast IP addresses 224.1.2.3 and 526 239.129.2.3 be forwarded on the same ports-groups? 528 Q3 Is it possible to forward multicast datagrams based on IP 529 addresses (not routed)? In other words, could 224.1.2.3 and 530 239.129.2.3 be forwarded on different port-groups with 531 unaltered TTL? 533 Q4 Are multicast datagrams within the range 224.0.0.1 to 534 224.0.0.255 forwarded on all ports whether or not IGMP Joins 535 have been sent? 537 Q5 Are multicast frames within the MAC address range 538 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports 539 MLD Snooping Switches 541 whether or not IGMP joins have been sent? 543 Q6 Does your switch support forwarding to ports on which IP 544 multicast routers are attached in addition to the ports where 545 IGMP Joins have been received? 547 Q7 Is your IGMP snooping functionality fully implemented in 548 hardware? 550 Q8 Is your IGMP snooping functionality partly software 551 implemented? 553 Q9 Can topology changes (for example spanning tree configuration 554 changes) be detected by the IGMP snooping functionality so that 555 for example new queries can be sent or tables can be updated to 556 ensure robustness? 558 The answers were: 560 ---------------------------+-----------------------+ 561 | Switch Vendor | 562 ---------------------------+---+---+---+---+---+---+ 563 | 1 | 2 | 3 | 4 | 5 | 6 | 564 ---------------------------+---+---+---+---+---+---+ 565 Q1 Join aggregation | x | x | x | | x | x | 566 Q2 Layer-2 forwarding | x | x | x | x |(1)| | 567 Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x | 568 Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x | 569 Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x | 570 Q6 Mcast router list | x | x | x | x | x | x | 571 Q7 Hardware implemented | | | | | | | 572 Q8 Software assisted | x | x | x | x | x | x | 573 Q9 Topology change aware | x | x | x | x | |(2)| 574 ---------------------------+---+---+---+---+---+---+ 575 x Means that the answer was Yes. 576 (1) In some products (typically high-end) Yes; in others No. 577 (2) Not at the time that the questionnaire was received 578 but expected in the near future. 580 Revision History 582 [To RFC Editor: This section is to be removed at publication time] 584 This section, while incomplete, is provided as a convenience to the 585 working group members. It will be removed when the document is 586 MLD Snooping Switches 588 released in its final form. 590 draft-ietf-magma-snoop-11.txt: April 2004 592 Editorial changes only: 594 Remove reference to IGMP/MLD Proxy (draft-ietf-magma- 595 proxy-06.txt) to avoid perception of content dependency. 597 Updated references to reflect current revisions, author 598 address. 600 draft-ietf-magma-snoop-10.txt: October 2003 602 The changes in this version are the result of the IESG review. 604 Substantial comments 606 The security considerations section was found a little 607 too brief. It has now been extended. 609 Editorial Changes 611 Removed reference RFC2375, using RFC3307 instead. New 612 author address information. 614 draft-ietf-magma-snoop-09.txt: August 2003 616 The changes in this version are the result of the AD review 617 following the WG chair review. 619 Substantial comments 621 There were no substantial technical comments, but a list 622 of suggested wordings and clarifications to improve the 623 readability and RFC conformance of the draft. 625 Reference in Abstract removed. Improved wording in 626 Introduction. 628 Improved wording in recommendations section, clarified 629 integrity checking for IPv6, removed security issues 630 which were really IGMP/MLD security issues. 632 Editorial Changes 634 Author information changes, TOC added, fixed a wrong 635 indentation following section 5. 637 MLD Snooping Switches 639 draft-ietf-magma-snoop-08.txt: June 2003 641 The changes in this version are the result of the WG chair 642 review following the second WG last call. The last call itself 643 did not result in further comments. 645 Substantial comments 647 Requirements have now been replaced with Recommendations 648 throughout the draft, which is more appropriate for an 649 Informational draft. 651 Clarifications regarding the overloading of the IGMP 652 query message in section 2.1.1. 654 Clarification regarding the data forwarding in the case 655 of INCLUDE/EXCLUDE filters. 657 More detail added on the special case of Source IP 658 address 0.0.0.0. 660 Editorial Changes 662 Moved Data Forwarding recommendation up as first bullet 663 as it really is the main recommendation. 665 Added a more suitable reference for the Thaler briefing 666 at the 56'th IETF meeting. Hopefully it will become a 667 valid link sometime soon. 669 Moved reference to RFC2375 to the Informative section. 671 draft-ietf-magma-snoop-07.txt: May 2003 673 The current version reflects comments made at the 56'th IETF 674 meeting and from the previous WG last call. The majority of 675 changes appear in sections 2.1 and 2.2, and even the changes 676 here are in reality not substantial. 678 Substantial comments 680 Section 2.1.1.(4): Changed wording for IGMP forwarding 681 section on when spoofing of General Queries should occur. 682 Added description of how to avoid IGMP version 683 incompatibility problems when doing said spoofing. 685 Section 2.1.2.(3): Clarification of incompatibility 686 problems in mixed IGMPv2 and IGMPv3 networks. Added 687 MLD Snooping Switches 689 recommendation for switches to implement some level of 690 IGMPv3 Join recognition to reduce these problems. 692 Section 2.2: Advice following the briefing [IETF56], that 693 in some cases disabling IGMP snooping functionality is 694 the only 'solution' 696 Section 6, IPv6 Considerations: added descriptions of 697 behavior involving the IPv6 version of the null IP Source 698 Address (to parallel the IPv4 behaviors). 700 Added reference to [IGMPv3] in stead of [PROXY] for group 701 membership maintenance and timeout. 703 Editorial Changes 705 Really minor stuff such as change of authors email 706 address, addition of references, draft name increment and 707 date changes. 709 draft-ietf-magma-snoop-06.txt: March 2003 711 Changes in response to comments made during WG last call and 712 assessment by the WG chairs: 714 Substantial comments 716 Clarification in IGMP forwarding section on the 717 acceptance of membership reports with source IP address 718 0.0.0.0 as being a switch recommendation. 720 Section 2.1.1.(4): Allow the router port to be excluded 721 from the General Query messages 723 Section 2.1.1.(6): Replace description of timing out 724 older entries with a reference to IGMP/MLD Proxying. 726 Section 2.1.2.(3): Replaced description of timeout 727 mechanism with a reference to IGMP/MLD. 729 Section 2.1.2.(4) Expanded rationale to discourage 730 leaking info between IPv4 and IPv6 groups. 732 Section 3: more strongly encourage the use of a 733 configuration option for selection of ICMPv6 message 734 types. 736 Editorial comments. 738 MLD Snooping Switches 740 Hyphenation problem resolved for groff by setting then ms 741 HY register to zero, disabling all forms for the entire 742 document 743 (".hy 0" and ".nr" worked only as far as the following 744 ms macro). 746 Sections moved around - again - to comply with 747 rfc2223bis-03 draft. Added copyright notice after memo 748 status. Removed table of contents as the draft is fairly 749 short. Corrected a reference typo. 751 Section 2.1.2.(3): Requirement and rationale broken into 752 separate paragraphs. 754 Added references to other IPv6 encapsulation documents, 756 Corrected estimates for MAC address collisions for 757 Ethernet and FDDI: both specification take the low-order 758 four (not six) bytes from the IPv6 group addresses. 760 draft-ietf-magma-snoop-05.txt: January 2003 762 Changes in wording of IGMP forwarding rule 6) and Data 763 forwarding rule 7). Corrections in the references section. 765 Apart from above, no substantial changes has occured in the 766 document. Several editorial changes, however, have been made 767 to comply with the rfc editors requirements: 769 References splitted in normative and informative sections, 770 other related references added. 772 Abstract shortened. 774 Changed all occurances of MUST, MAY etc. to lowercase to 775 reflect that this is not a standards track document. 777 Sections moved around so they appear in the required order. 779 draft-ietf-magma-snoop-04.txt: November 2002 781 Editorial changes only. 783 draft-ietf-magma-snoop-03.txt: October 2002 785 IGMP Forwarding rules: 786 Add references to and become consistant with the current 787 IGMP proxy draft, 788 MLD Snooping Switches 790 Unrecognized IGMP packets should not be ignored because 791 "mbz" fields are not zero since packets from future 792 versions are expected to maintain consistency. 794 Corrections related to IGMP Querier election process. 796 Add clarification to how lists of router ports may be 797 assembled. 799 Data Forwarding rules: 800 Added discussion of the problems for different IGMP 801 environments in choosing whether to flood or to prune 802 unregistered multicasts. 804 Added refinements for how to handle NON-IPv4 multicasts, 805 to keep IGMP-snooping functionality from interfering with 806 IPv6 and other multicast traffic. Any filtering for non- 807 IPv4 multicasts should be based on bridge behavior and 808 not IGMP snooping behavior. 810 IGMP snooping related problems: 811 Fixed description of interoperability issues in 812 environments with v3 routers and hosts, and v2 snooping 813 switches. 815 Added discussion of the IGMPv3 "include source" and 816 "exclude source" options, and the inability to support 817 them on shared segments. 819 IPv6 Considerations: 820 Clarifications regarding address ranges FF00::, FF01:: 821 and all hosts FF02::1 in relation to data forwarding. 823 draft-ietf-magma-snoop-02.txt: June 2002 825 Status section removes document history; moved into this 826 section instead. 828 Introduction restores text from the -00 revision that 829 describes snooping and its goals 831 IGMP flooding rules eased, allowing management option to 832 broaden beyond "routers only". 834 Removed a should/MAY inconsistancy between IPv4 Forwarding and 835 IPv6 processing of checksums. 837 MLD Snooping Switches 839 IGMP Forwarding Rules: clarify text describing processing of 840 non-zero reserved fields. 842 Data Forwarding Rules, item 3 is changed from "MUST forward to 843 all ports" to "MAY"; item 4 default changes from "MUST" to 844 "should use network addresses". 846 Added two sets of additional responses to the questionnaire 847 and text indicating that responses don't cover all products. 849 Removed (commented out) description of IPR issues: IESG is 850 aware of them. 852 draft-ietf-magma-snoop-01.txt: January 2002 854 Extensive restructuring of the original text. 856 draft-ietf-idmr-snoop-01.txt: 2001 858 Added several descriptions of cases where IGMP snooping 859 implementations face problems. Also added several network 860 topology figures. 862 draft-ietf-idmr-snoop-00.txt: 2001 864 Initial snooping draft. An overview of IGMP snooping and the 865 problems to be solved. 867 5. References 869 5.1. Normative References 871 [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" 873 [IGMPv3] Cain, B., "Internet Group Management Protocol, Version 874 3", RFC3376, October 2002. 876 [IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6 877 Packets over IEEE 1394 Networks", RFC3146, October 878 2001. 880 [IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over 881 Ethernet Networks", RFC2464, December 1998. 883 MLD Snooping Switches 885 [IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 886 Networks", RFC2467, December 1998. 888 [IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., "Transmission 889 of IPv6 Packets over Token Ring Networks", RFC2470, 890 December 1998. 892 [MLD] Deering, S., Fenner, B. and Haberman, B. "Multicast 893 Listener Discovery (MLD) for IPv6", RFC2710, October 894 1999. 896 [MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery 897 Version 2 (MLDv2) for IPv6", draft-vida-mld-v2-08.txt, 898 December 2003. 900 [MRDISC] Biswas, S., Cain, B. and Haberman, B., "Multicast 901 Router Discovery", draft-ietf-magma-mrdisc-00.txt, 902 February 2004. 904 [NDP] Narten, T., Nordmark, E. and Simpson, W., "Neighbor 905 Discovery for IP Version 6 {IPv6)", RFC2461, December 906 1998. 908 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 909 RFC1112, August 1989. 911 [RFC2026] Bradner, S. "The Internet Standards Process -- 912 Revision 3", RFC2026, October 1996. 914 [RFC2236] Fenner, W., "Internet Group Management Protocol, 915 Version 2", RFC2236, November 1997. 917 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 918 Multicast Addresses", RFC3307, August 2002. 920 5.2. Informative References 922 [CISCO] 923 Cisco Tech Notes, "Multicast In a Campus Network: CGMP and 924 IGMP snooping", http://www.cisco.com/warp/public/473/22.html 926 [IANA] Internet Assigned Numbers Authority, "Internet 927 Multicast Addresses", 928 http://www.iana.org/assignments/multicast-addresses 929 MLD Snooping Switches 931 [IETF56] Briefing by Dave Thaler, Microsoft, presented to the 932 MAGMA WG at the 56'th IETF meeting in San Francisco, 933 http://www.ietf.org/proceedings/03mar/index.html 935 [MSOFT] Microsoft support article Q223136, "Some LAN Switches 936 with IGMP Snooping Stop Forwarding Multicast Packets 937 on RRAS Startup", 939 http://support.microsoft.com/support/articles/Q223/1/36.ASP 941 6. Security Considerations 943 Under normal network operation, the snooping switch is expected to 944 improve overall network performance by limiting the scope of 945 multicast flooding to a smaller portion of the local network. In 946 the event of forged IGMP messages, the benefits of using a snooping 947 switch might be reduced or eliminated. 949 Security considerations for IGMPv3 at the network layer of the 950 protocol stack are described in [IGMPv3]. The introduction of IGMP 951 snooping functionality does not alter the handling of multicast 952 packets by the router as it does not make use of link layer 953 information. 955 There are, however, changes in the way that the IGMP snooping 956 switch handles multicast packets within the local network. In 957 particular: 959 - A Query message with a forged source address which is less than 960 that of the current Querier could cause snooping switches to 961 forward subsequent Membership reports to the wrong network 962 interface. It is for this reason that IGMP Membership Reports 963 should be sent to all multicast routers as well as the current 964 Querier. 966 - It is possible for a host on the local network to generate 967 Current-State Report Messages that would cause the switch to 968 incorrectly believe that there is a multicast listener on the 969 same network segment as the originator of the forged message. 970 This will cause unrequested multicast packets to be forwarded 971 into the network segments between the source and the router. 972 If the router requires that all Multicast Report messages be 973 authenticated as described in section 9.4 of [IGMPv3], it will 974 discard the forged Report message from the host inside the 975 network in the same way that it would discard one which 976 originates from a remote location. It is worth noting that if 977 MLD Snooping Switches 979 the router accepts unauthenticated Report messages by virtue of 980 them having arrived over a network interface associated with 981 the internal network, investigating the affected network 982 segments will quickly narrow the search for the source of the 983 forged messages. 985 - As noted in [IGMPv3], there is little motivation for an 986 attacker to forge a Membership report message since joining a 987 group is generally an unprivileged operation. The sender of 988 the forged Membership report will be the only recipient of the 989 multicast traffic to that group. This is in contrast to a 990 shared LAN segment (HUB) or network without snooping switches, 991 where all other hosts on the same segment would be unable to 992 transmit when the network segment is flooding the unwanted 993 traffic. 995 The worst case result for each attack would remove the performance 996 improvements that the snooping functionality would otherwise 997 provide. It would, however, be no worse than that experienced on a 998 network with switches that do not perform multicast snooping. 1000 7. Acknowledgements 1002 We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter, 1003 Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward 1004 Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka 1005 Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret 1006 Wasserman for comments and suggestions on this document. 1008 Furthermore, the following companies are acknowledged for their 1009 contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, 1010 Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane 1011 The ordering of these names do not necessarily correspond to the 1012 column numbers in the response table. 1014 MLD Snooping Switches 1016 8. Authors' Addresses 1018 Morten Jagd Christensen 1019 Thrane & Thrane 1020 Lundtoftegaardsvej 93 D 1021 2800 Lyngby 1022 DENMARK 1023 email: mjc@tt.dk 1025 Karen Kimball 1026 Hewlett-Packard 1027 8000 Foothills Blvd. 1028 Roseville, CA 95747 1029 USA 1030 email: karen.kimball@hp.com 1032 Frank Solensky 1033 West Ridge Networks 1034 25 Porter Rd. 1035 Littleton, MA 01460 1036 USA 1037 email: fsolensky@WestRidgeNetworks.com 1039 9. IETF IPR Statement 1041 "The IETF takes no position regarding the validity or scope of any 1042 intellectual property or other rights that might be claimed to 1043 pertain to the implementation or use of the technology described in 1044 this document or the extent to which any license under such rights 1045 might or might not be available; neither does it represent that it 1046 has made any effort to identify any such rights. Information on 1047 the IETF's procedures with respect to rights in standards-track and 1048 standards-related documentation can be found in [RFC-2026]. Copies 1049 of claims of rights made available for publication and any 1050 assurances of licenses to be made available, or the result of an 1051 attempt made to obtain a general license or permission for the use 1052 of such proprietary rights by implementors or users of this 1053 specification can be obtained from the IETF Secretariat." 1055 10. Full Copyright Statement 1057 Copyright (C) The Internet Society (2003). All Rights Reserved. 1059 This document and translations of it may be copied and furnished to 1060 others, and derivative works that comment on or otherwise explain 1061 it or assist in its implementation may be prepared, copied, 1062 MLD Snooping Switches 1064 published and distributed, in whole or in part, without restriction 1065 of any kind, provided that the above copyright notice and this 1066 paragraph are included on all such copies and derivative works. 1067 However, this document itself may not be modified in any way, such 1068 as by removing the copyright notice or references to the Internet 1069 Society or other Internet organizations, except as needed for the 1070 purpose of developing Internet standards in which case the 1071 procedures for copyrights defined in the Internet Standards process 1072 must be followed, or as required to translate it into languages 1073 other than English. 1075 The limited permissions granted above are perpetual and will not be 1076 revoked by the Internet Society or its successors or assigns. 1078 This document and the information contained herein is provided on 1079 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1080 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1081 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1082 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1083 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1085 Acknowledgement: 1087 Funding for the RFC Editor function is currently provided by the 1088 Internet Society. 1090 MLD Snooping Switches 1092 Table of Contents 1094 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1095 2. IGMP Snooping Recommendations . . . . . . . . . . . . . . . 3 1096 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3 1097 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 3 1098 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 6 1099 2.2. IGMP snooping-related problems . . . . . . . . . . . . . . 8 1100 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9 1101 4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11 1102 4. Revision History . . . . . . . . . . . . . . . . . . . . . . 12 1103 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 1104 5.1. Normative References . . . . . . . . . . . . . . . . . . . 18 1105 5.2. Informative References . . . . . . . . . . . . . . . . . . 19 1106 6. Security Considerations . . . . . . . . . . . . . . . . . . 20 1107 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 1108 8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 21 1109 9. IETF IPR Statement . . . . . . . . . . . . . . . . . . . . . 22 1110 10. Full Copyright Statement . . . . . . . . . . . . . . . . . 22 1112 [To RFC Editor: The TOC page is to be moved to page 2 at 1113 publication time ] 1115 [To RFC Editor: Page renumbering in TOC and in document will be 1116 necessary ]