idnits 2.17.00 (12 Aug 2021) /tmp/idnits52014/draft-ietf-magma-snoop-08.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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations for IGMPv3 are accounted for in' ) ** 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 an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([IGMPv3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 699: '...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 674 has weird spacing: '...rrected a ref...' == Line 934 has weird spacing: '...imed to perta...' -- 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 (July 2003) is 6884 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2735' is mentioned on line 480, but not defined == Unused Reference: 'IANA' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'RFC2375' is defined on line 861, but no explicit reference was found in the text == Outdated reference: draft-vida-mld-v2 has been published as RFC 3810 ** Obsolete normative reference: RFC 2461 (ref. 'NDP') (Obsoleted by RFC 4861) == Outdated reference: draft-ietf-magma-igmp-proxy has been published as RFC 4605 Summary: 9 errors (**), 0 flaws (~~), 9 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: December 2003 K. Kimball 5 Category: Informational Hewlett-Packard 6 F. Solensky 7 July 2003 9 Considerations for IGMP and MLD Snooping Switches 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [RFC2026]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This memo describes the recommendations for IGMP- and MLD-snooping 41 switches. These are based on best current practices for IGMPv2, 42 with further considerations for IGMPv3- and MLDv2-snooping. 43 Additional areas of relevance, such as link layer topology changes 44 and Ethernet-specific encapsulation issues, are also considered. 46 Interoperability issues that arise between different versions of 47 IGMP are not the focus of this document. Interested readers are 48 directed to [IGMPv3] for a thorough description of problem areas. 50 1. Introduction 52 When processing a packet whose destination MAC address is a 53 multicast address, the switch will forward a copy of the packet 54 into each of the remaining network interfaces that are in the 55 forwarding state in accordance with [BRIDGE]. The spanning tree 56 algorithm ensures that the application of this rule at every switch 57 in the network will make the packet accessible to all nodes 58 connected to the network. 60 This approach works well for broadcast packets that are intended to 61 be seen or processed by all connected nodes. In the case of 62 multicast packets, however, this approach could lead to less 63 efficient use of network bandwidth, particularly when the packet is 64 intended for only a small number of nodes. Packets will be flooded 65 into network segments where no node has any interest in receiving 66 the packet. While nodes will rarely incur any processing overhead 67 to filter packets addressed to unrequested group addresses, they 68 are unable to transmit new packets onto the shared media for the 69 period of time that the multicast packet is flooded. In general, 70 significant bandwidth can be wasted by flooding. 72 In recent years, a number of commercial vendors have introduced 73 products described as "IGMP snooping switches" to the market. 74 These devices do not adhere to the conceptual model that provides 75 the strict separation of functionality between different 76 communications layers in the ISO model, and instead utilize 77 information in the upper level protocol headers as factors to be 78 considered in processing at the lower levels. This is analogous to 79 the manner in which a router can act as a firewall by looking into 80 the transport protocol's header before allowing a packet to be 81 forwarded to its destination address. 83 In the case of multicast traffic, an IGMP snooping switch provides 84 the benefit of conserving bandwidth on those segments of the 85 network where no node has expressed interest in receiving packets 86 addressed to the group address. This is in contrast to normal 87 switch behavior where multicast traffic is typically forwarded on 88 all interfaces. 90 Many switch datasheets state support for IGMP snooping, but no 91 recommendations for this exist today. It is the authors' hope that 92 the information presented in this draft will supply this 93 foundation. 95 The recommendations presented here are based on the following 96 information sources: The IGMP specifications [RFC1112], [RFC2236] 97 and [IGMPv3], vendor-supplied technical documents [CISCO], bug 98 reports [MSOFT], discussions with people involved in the design of 99 IGMP snooping switches, MAGMA mailing list discussions, and on 100 replies by switch vendors to an implementation questionnaire. 102 The suggestions in this document are based on IGMP, which applies 103 only to IPv4. For IPv6, Multicast Listener Discovery [MLD] must be 104 used instead. Because MLD is based on IGMP, we do not repeat the 105 entire description and recommendations for MLD snooping switches. 106 Instead, we point out the few cases where there are differences 107 from IGMP. 109 Note that the IGMP snooping function should apply only to IPv4 110 multicasts. Other multicast packets, such as IPv6, might be 111 suppressed by IGMP snooping if additional care is not taken in the 112 implementation. It is desired not to restrict the flow of non-IPv4 113 multicasts other than to the degree which would happen as a result 114 of regular bridging functions. Likewise, MLD snooping switches are 115 discouraged from using topological information learned from IPv6 116 traffic to alter the forwarding of IPv4 multicast packets. 118 2. IGMP Snooping Recommendations 120 The following sections list the recommendations for an IGMP 121 snooping switch. The recommendation is stated and is supplemented 122 by a description of a possible implementation approach. All 123 implementation discussions are examples only and there may well be 124 other ways to achieve the same functionality. 126 2.1. Forwarding rules 128 The IGMP snooping functionality is separated into a control section 129 (IGMP forwarding) and a data section (Data forwarding). 131 2.1.1. IGMP Forwarding Rules 133 1) A snooping switch should forward IGMP Membership Reports only 134 to those ports where multicast routers are attached. 135 Alternatively stated: a snooping switch should not forward IGMP 136 Membership Reports to ports on which only hosts are attached. 137 An administrative control may be provided to override this 138 restriction, allowing the report messages to be flooded to 139 other ports. 141 This is the main IGMP snooping functionality for the control 142 path. 144 Sending membership reports to other hosts can result, for 145 IGMPv1 and IGMPv2, in unintentionally preventing a host from 146 joining a specific multicast group. 148 When an IGMPv1 or IGMPv2 host receives a membership report for 149 a group address that it is intending to join, the host will 150 suppress its own membership report for the same group. This 151 join or message suppression is a requirement for IGMPv1 and 152 IGMPv2 hosts. However, if a switch does not receive a 153 membership report from the host it will not forward multicast 154 data to it. 156 This is not a problem in an IGMPv3-only network because there 157 is no suppression of IGMP Membership reports. 159 The administrative control allows IGMP Membership Report 160 messages to be processed by network monitoring equipment such 161 as packet analyzers or port replicators. 163 The switch supporting IGMP snooping must maintain a list of 164 multicast routers and the ports on which they are attached. 165 This list can be constructed in any combination of the 166 following ways: 168 a) This list should be built by the snooping switch sending 169 Multicast Router Solicitation messages as described in IGMP 170 Multicast Router Discovery [MRDISC]. It may also snoop 171 Multicast Router Advertisement messages sent by and to 172 other nodes. 174 b) The arrival port for IGMP Queries (sent by multicast 175 routers) where the source address is not 0.0.0.0. 177 The 0.0.0.0 address represents a special case where the 178 switch is proxying IGMP Queries for faster network 179 convergence, but is not itself the Querier. The switch 180 does not use its own IP address (even if it has one), 181 because this would cause the Queries to be seen as coming 182 from a newly elected Querier. The 0.0.0.0 address is used 183 to indicate that the Query packets are NOT from a multicast 184 router. 186 c) Ports explicitly configured by management to be IGMP- 187 forwarding ports, in addition to or instead of any of the 188 above methods to detect router ports. 190 2) IGMP snooping switches may also implement "proxy-reporting" in 191 which reports received from downstream hosts are summarized and 192 used to build internal membership states as described in 193 [PROXY]. The IGMP proxy-reporting switch would then report its 194 own state in response to upstream queriers. If the switch does 195 not already have an IP address assigned to it, the source 196 address for these reports should be set to all-zeros. 198 An IGMP proxy-reporting switch may act as Querier for the 199 downstream hosts while proxy reporting to the 'real' upstream 200 queriers. 202 It should be noted that there may be multiple IGMP proxy- 203 reporting switches in the network all using the 0.0.0.0 source 204 IP address. In this case the switches can be uniquely 205 identified through their link layer source MAC address. 207 IGMP membership reports must not be rejected by an IGMP 208 snooping switch because of a source IP address of 0.0.0.0. 210 3) The switch that supports IGMP snooping must flood all 211 unrecognized IGMP messages to all other ports and must not 212 attempt to make use of any information beyond the end of the 213 network layer header. 215 In addition, earlier versions of IGMP should interpret IGMP 216 fields as defined for their versions and must not alter these 217 fields when forwarding the message. When generating new 218 messages, a given IGMP version should set fields to the 219 appropriate values for its own version. If any fields are 220 reserved or otherwise undefined for a given IGMP version, the 221 fields should be ignored when parsing the message and must be 222 set to zeroes when new messages are generated by 223 implementations of that IGMP version. An exception may occur 224 if the switch is performing a spoofing function, and is aware 225 of the settings for new or reserved fields that would be 226 required to correctly spoof for a different IGMP version. 228 The reason to worry about these trivialities is that IGMPv3 229 overloads the old IGMP query message using the same type number 230 (0x11) but with an extended header. Therefore there is a risk 231 that IGMPv3 queries may be interpreted as older version queries 232 by, for example, IGMPv2 snooping switches. This has already 233 been reported [IETF56] and is discussed in section 2.2. 235 4) An IGMP snooping switch should be aware of link layer topology 236 changes caused by Spanning Tree operation. When a port is 237 enabled or disabled by Spanning Tree, a General Query may be 238 sent on all active non-router ports in order to reduce network 239 convergence time. Non-Querier switches should be aware of 240 whether the Querier is in IGMPv3 mode. If so, the switch should 241 not spoof any General Queries unless it is able to send an 242 IGMPv3 Query that adheres to the most recent information sent 243 by the true Querier. In no case should a switch introduce a 244 spoofed IGMPv2 Query into an IGMPv3 network, as this may create 245 excessive network disruption. 247 If the switch is not the Querier, it should use the 'all-zeros' 248 IP Source Address in these proxy queries (even though some 249 hosts may elect to not process queries with a 0.0.0.0 IP Source 250 Address). When such proxy queries are received, they must not 251 be included in the Querier election process. 253 5) An IGMP snooping switch must not make use of information in 254 IGMP packets where the IP or IGMP headers have checksum or 255 integrity errors. The switch should not flood such packets but 256 if it does, it should also take some note of the event (i.e., 257 increment a counter). These errors and their processing are 258 further discussed in [IGMPv3], [MLD] and [MLDv2]. 260 6) The snooping switch must not rely exclusively on the appearance 261 of IGMP Group Leave announcements to determine when entries 262 should be removed from the forwarding table. It should 263 implement a membership timeout mechanism such as the router- 264 side functionality of the IGMP protocol as described in the 265 IGMP and MLD specifications (See Normative Reference section 266 for IGMPv1-3 and MLDv1-2) on all its non-router ports. This 267 timeout value should be configurable. 269 2.1.2. Data Forwarding Rules 271 1) Packets with a destination IP address outside 224.0.0.X which 272 are not IGMP should be forwarded according to group-based port 273 membership tables and must also be forwarded on router ports. 275 This is the main IGMP snooping functionality for the data path. 277 One approach that an implementation could take would be to 278 maintain separate membership and multicast router tables in 279 software and then "merge" these tables into a forwarding cache. 281 2) Packets with a destination IP (DIP) address in the 224.0.0.X 282 range which are not IGMP must be forwarded on all ports. 284 This recommendation is based on fact that many host systems do 285 not send Join IP multicast addresses in this range before 286 sending or listening to IP multicast packets. Furthermore, 287 since the 224.0.0.X address range is defined as link-local (not 288 to be routed) it seems unnecessary to keep state for each 289 address in this range. Additionally, some routers operate in 290 the 224.0.0.X address range without issuing IGMP Joins, and 291 these applications would break if the switch were to prune them 292 due to not having seen a Join Group message from the router. 294 3) If a switch receives a non-IGMP IPv4 multicast packet without 295 having first processed Membership Reports for the group 296 address, it may forward the packet on all ports but it must 297 forward the packet on router ports. A switch may forward an 298 unregistered packet only on router ports, but the switch must 299 have a configuration option that suppresses this restrictive 300 operation and forces flooding of unregistered packets on 301 selected ports. 303 In an environment where IGMPv3 hosts are mixed with snooping 304 switches that do not yet support IGMPv3, the switch's failure 305 to flood unregistered streams could prevent v3 hosts from 306 receiving their traffic. Alternatively, in environments where 307 the snooping switch supports all of the IGMP versions that are 308 present, flooding unregistered streams may cause IGMP hosts to 309 be overwhelmed by multicast traffic, even to the point of not 310 receiving Queries and failing to issue new membership reports 311 for their own groups. 313 It is encouraged that snooping switches at least recognize and 314 process IGMPv3 Join Reports, even if this processing is limited 315 to the behavior for IGMPv2 Joins, i.e., is done without 316 considering any additional "include source" or "exclude source" 317 filtering. When IGMPv3 Joins are not recognized, a snooping 318 switch may incorrectly prune off the unregistered data streams 319 for the groups (as noted above); alternatively, it may fail to 320 add in forwarding to any new IGMPv3 hosts if the group has 321 previously been joined as IGMPv2 (because the data stream is 322 seen as already having been registered). 324 4) All non-IPv4 multicast packets should continue to be flooded 325 out all remaining ports in the forwarding state as per normal 326 IEEE bridging operations. 328 This recommendation is a result of the fact that groups made up 329 of IPv4 hosts and IPv6 hosts are completely separate and 330 distinct groups. As a result, information gleaned from the 331 topology between members of an IPv4 group would not be 332 applicable when forming the topology between members of an IPv6 333 group. 335 5) IGMP snooping switches may maintain forwarding tables based on 336 either MAC addresses or IP addresses. If a switch supports 337 both types of forwarding tables then the default behavior 338 should be to use IP addresses. IP address based forwarding is 339 preferred because the mapping between IP multicast addresses 340 and link-layer multicast addresses is ambiguous. In the case 341 of Ethernet, there is a multiplicity of 1 Ethernet address to 342 32 IP addresses [RFC1112]. 344 6) Switches which rely on information in the IP header should 345 verify that the IP header checksum is correct. If the checksum 346 fails, the information in the packet must not be incorporated 347 into the forwarding table. Further, the packet should be 348 discarded. 350 7) When IGMPv3 "include source" and "exclude source" membership 351 reports are received on shared segments, the switch needs to 352 forward the superset of all received membership reports onto 353 the shared segment. Forwarding of traffic from a particular 354 source S to a group G must happen if at least one host on the 355 shared segment reports an IGMPv3 membership of the type 356 INCLUDE(G, Slist1) or EXCLUDE(G, Slist2) where S is an element 357 of Slist1 and not an element of Slist2. 359 The practical implementation of the (G,S1,S2,...) based data 360 forwarding tables are not within the scope of this document. 361 However, one possibility is to maintain two (G,S) forwarding 362 lists: one for the INCLUDE filter where a match of a specific 363 (G,S) is a requirement before forwarding will happen, and one 364 for the EXCLUDE filter where a match of a specific (G,S) will 365 result in no forwarding. 367 2.2. IGMP snooping-related problems 369 A special problem arises in networks consisting of IGMPv3 routers 370 as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 371 snooping switch as recently reported [IETF56]. The router will 372 continue to maintain IGMPv3 even in the presence of IGMPv2 hosts, 373 and thus the network will not converge on IGMPv2. But it is likely 374 that the IGMPv2 snooping switch will not recognize or process the 375 IGMPv3 membership reports. Groups for these unrecognized reports 376 will then either be flooded (with all of the problems that may 377 create for hosts in a network with a heavy multicast load) or 378 pruned by the snooping switch. 380 Therefore, it is recommended that in such a network, the multicast 381 router be configured to use IGMPv2. If this is not possible, and if 382 the snooping switch cannot recognize and process the IGMPv3 383 membership reports, it is instead recommended that the switch's 384 IGMP snooping functionality be disabled, as there is no clear 385 solution to this problem. 387 3. IPv6 Considerations 389 In order to avoid confusion, the previous discussions have been 390 based on the IGMP protocol which only applies to IPv4 multicast. 391 In the case of IPv6 most of the above discussions are still valid 392 with a few exceptions which we will describe here. 394 The control and data forwarding rules in the IGMP section can, with 395 a few considerations, also be applied to MLD. This means that the 396 basic functionality of intercepting MLD packets, and building 397 membership lists and multicast router lists, is the same as for 398 IGMP. 400 In IPv6, the data forwarding rules are more straight forward 401 because MLD is mandated for addresses with scope 2 (link-scope) or 402 greater. The only exception is the address FF02::1 which is the 403 all hosts link-scope address for which MLD messages are never sent. 404 Packets with the all hosts link-scope address should be forwarded 405 on all ports. 407 MLD messages are also not sent to packets in the address range 408 FF00::/15 (which encompasses both the reserved FF00::/16 and node- 409 local FF01::/16 IPv6 address spaces). These addresses should never 410 appear in packets on the link. 412 Equivalent to the IPv4 behaviors regarding the null IP Source 413 address, MLD membership reports must not be rejected by an MLD 414 snooping switch because of an unspecified IP source address (::). 415 Additionally, if a non-Querier switch spoofs any General Queries 416 (as addressed in Section 2.1 above, for Spanning Tree topology 417 changes), the switch should use the null IP source address (::) 418 when sending said queries. When such proxy queries are received, 419 they must not be included in the Querier election process. 421 The three major differences between IPv4 and IPv6 in relation to 422 multicast are: 424 - The IPv6 protocol for multicast group maintenance is called 425 Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message 426 types instead of IGMP message types. 428 - The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128 429 bit DIP address are used to form the 48 bit DMAC addresses for 430 multicast groups, while [IPV6-TOKEN] describes the mapping for 431 token ring DMAC addresses by using three low-order bits. The 432 specification [IPV6-1394] makes use of a 6 bit channel number. 434 - Multicast router discovery is accomplished using Neighbor 435 Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message 436 types. 438 The IPv6 packet header does not include a checksum field. 439 Nevertheless, the switch should detect other packet integrity 440 issues. When the snooping switch detects such an error, it must 441 not include information from the corresponding packet in the MLD 442 forwarding table. The forwarding code should instead drop the 443 packet and take further reasonable actions as advocated above. 445 The fact that MLDv2 is using ICMPv6 adds new requirements to a 446 snooping switch because ICMPv6 has multiple uses aside from MLD. 447 This means that it is no longer sufficient to detect that the next- 448 header field of the IP header is ICMPv6 in order to identify 449 packets relevant for MLD snooping. A software-based implemention 450 which treats all ICMPv6 packets as candidates for MLD snooping 451 could easily fill its receive queue and bog down the CPU with 452 irrelevant packets. This would prevent the snooping functionality 453 from performing its intended purpose and the non-MLD packets 454 destined for other hosts could be lost. 456 A solution is either to require that the snooping switch looks 457 further into the packets, or to be able to detect a multicast DMAC 458 address in conjunction with ICMPv6. The first solution is 459 desirable when a configuration option allows the administrator to 460 specify which ICMPv6 message types should trigger a CPU redirect 461 and which should not. The reason is that a hardcoding of message 462 types is inflexible for the introduction of new message types. The 463 second solution introduces the risk that new protocols which use 464 ICMPv6 and multicast DMAC addresses could be incorrectly identified 465 as MLD. It is suggested that solution one is preferred when the 466 configuration option is provided. If this is not the case, then 467 the implementor should seriously consider making it available since 468 Neighbor Discovery messages would be among those that fall into 469 this false positive case and are vital for the operational 470 integrity of IPv6 networks. 472 The mapping from IP multicast addresses to multicast DMAC addresses 473 introduces a potentially enormous overlap. The structure of an 474 IPv6 multicast address is shown in the figure below. As a result, 475 there are 2 ** (112 - (32 - 8)), or more than 7.9e28 unique DIP 476 addresses which map into a single DMAC address in Ethernet and 477 FDDI. This should be compared to 2**5 in the case of IPv4. 479 Initial allocation of IPv6 multicast addresses as described in 480 [RFC2735], however, cover only the lower 24 bits of group ID. 481 While this reduces the problem of address ambiguity to group IDs 482 with different flag and scope values for now, it should be noted 483 that the allocation policy may change in the future. Because of 484 the potential overlap it is recommended that IPv6 address based 485 forwarding is preferred to MAC address based forwarding. 487 | 8 | 4 | 4 | 112 bits | 488 +--------+----+----+---------------------------------------+ 489 |11111111|flgs|scop| group ID | 490 +--------+----+----+---------------------------------------+ 492 4. IGMP Questionnaire 494 As part of this work the following questions were asked both on the 495 MAGMA discussion list and sent to known switch vendors implementing 496 IGMP snooping. The individual contributions have been anonymized 497 upon request and do not necessarily apply to all of the vendors' 498 products. 500 The questions were: 502 Q1 Does your switches perform IGMP Join aggregation? In other 503 words, are IGMP joins intercepted, absorbed by the 504 hardware/software so that only one Join is forwarded to the 505 querier? 507 Q2 Is multicast forwarding based on MAC addresses? Would 508 datagrams addressed to multicast IP addresses 224.1.2.3 and 509 239.129.2.3 be forwarded on the same ports-groups? 511 Q3 Is it possible to forward multicast datagrams based on IP 512 addresses (not routed)? In other words, could 224.1.2.3 and 513 239.129.2.3 be forwarded on different port-groups with 514 unaltered TTL? 516 Q4 Are multicast datagrams within the range 224.0.0.1 to 517 224.0.0.255 forwarded on all ports whether or not IGMP Joins 518 have been sent? 520 Q5 Are multicast frames within the MAC address range 521 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports 522 whether or not IGMP joins have been sent? 524 Q6 Does your switch support forwarding to ports on which IP 525 multicast routers are attached in addition to the ports where 526 IGMP Joins have been received? 528 Q7 Is your IGMP snooping functionality fully implemented in 529 hardware? 531 Q8 Is your IGMP snooping functionality partly software 532 implemented? 534 Q9 Can topology changes (for example spanning tree configuration 535 changes) be detected by the IGMP snooping functionality so that 536 for example new queries can be sent or tables can be updated to 537 ensure robustness? 539 The answers were: 541 ---------------------------+-----------------------+ 542 | Switch Vendor | 543 ---------------------------+---+---+---+---+---+---+ 544 | 1 | 2 | 3 | 4 | 5 | 6 | 545 ---------------------------+---+---+---+---+---+---+ 546 Q1 Join aggregation | x | x | x | | x | x | 547 Q2 Layer-2 forwarding | x | x | x | x |(1)| | 548 Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x | 549 Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x | 550 Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x | 551 Q6 Mcast router list | x | x | x | x | x | x | 552 Q7 Hardware implemented | | | | | | | 553 Q8 Software assisted | x | x | x | x | x | x | 554 Q9 Topology change aware | x | x | x | x | |(2)| 555 ---------------------------+---+---+---+---+---+---+ 556 x Means that the answer was Yes. 557 (1) In some products (typically high-end) Yes; in others No. 558 (2) Not at the time that the questionnaire was received 559 but expected in the near future. 561 Revision History 563 [To RFC Editor: This section is to be removed at publication time] 564 This section, while incomplete, is provided as a convenience to the 565 working group members. It will be removed when the document is 566 released in its final form. 568 draft-ietf-magma-snoop-08.txt: June 2003 570 The changes in this version are the result of the WG chair 571 review following the second WG last call. The last call itself 572 did not result in further comments. 574 Substantial comments 576 Requirements have now been replaced with Recommendations 577 throughout the draft, which is more appropriate for an 578 Informational draft. 580 Clarifications regarding the overloading of the IGMP 581 query message in section 2.1.1. 583 Clarification regarding the data forwarding in the case 584 of INCLUDE/EXCLUDE filters. 586 More detail added on the special case of Source IP 587 address 0.0.0.0. 589 Editorial Changes 591 Moved Data Forwarding recommendation up as first bullet 592 as it really is the main recommendation. 594 Added a more suitable reference for the Thaler briefing 595 at the 56'th IETF meeting. Hopefully it will become a 596 valid link sometime soon. 598 Moved reference to RFC2375 to the Informative section. 600 draft-ietf-magma-snoop-07.txt: May 2003 602 The current version reflects comments made at the 56'th IETF 603 meeting and from the previous WG last call. The majority of 604 changes appear in sections 2.1 and 2.2, and even the changes 605 here are in reality not substantial. 607 Substantial comments 609 Section 2.1.1.(4): Changed wording for IGMP forwarding 610 section on when spoofing of General Queries should occur. 611 Added description of how to avoid IGMP version 612 incompatibility problems when doing said spoofing. 614 Section 2.1.2.(3): Clarification of incompatibility 615 problems in mixed IGMPv2 and IGMPv3 networks. Added 616 recommendation for switches to implement some level of 617 IGMPv3 Join recognition to reduce these problems. 619 Section 2.2: Advice following the briefing [IETF56], that 620 in some cases disabling IGMP snooping functionality is 621 the only 'solution' 623 Section 6, IPv6 Considerations: added descriptions of 624 behavior involving the IPv6 version of the null IP Source 625 Address (to parallel the IPv4 behaviors). 627 Added reference to [IGMPv3] in stead of [PROXY] for group 628 membership maintenance and timeout. 630 Editorial Changes 632 Really minor stuff such as change of authors email 633 address, addition of references, draft name increment and 634 date changes. 636 draft-ietf-magma-snoop-06.txt: March 2003 638 Changes in response to comments made during WG last call and 639 assessment by the WG chairs: 641 Substantial comments 643 Clarification in IGMP forwarding section on the 644 acceptance of membership reports with source IP address 645 0.0.0.0 as being a switch recommendation. 647 Section 2.1.1.(4): Allow the router port to be excluded 648 from the General Query messages 650 Section 2.1.1.(6): Replace description of timing out 651 older entries with a reference to IGMP/MLD Proxying. 653 Section 2.1.2.(3): Replaced description of timeout 654 mechanism with a reference to IGMP/MLD. 656 Section 2.1.2.(4) Expanded rationale to discourage 657 leaking info between IPv4 and IPv6 groups. 659 Section 3: more strongly encourage the use of a 660 configuration option for selection of ICMPv6 message 661 types. 663 Editorial comments. 665 Hyphenation problem resolved for groff by setting then ms 666 HY register to zero, disabling all forms for the entire 667 document 668 (".hy 0" and ".nr" worked only as far as the following 669 ms macro). 671 Sections moved around - again - to comply with 672 rfc2223bis-03 draft. Added copyright notice after memo 673 status. Removed table of contents as the draft is fairly 674 short. Corrected a reference typo. 676 Section 2.1.2.(3): Requirement and rationale broken into 677 separate paragraphs. 679 Added references to other IPv6 encapsulation documents, 681 Corrected estimates for MAC address collisions for 682 Ethernet and FDDI: both specification take the low-order 683 four (not six) bytes from the IPv6 group addresses. 685 draft-ietf-magma-snoop-05.txt: January 2003 687 Changes in wording of IGMP forwarding rule 6) and Data 688 forwarding rule 7). Corrections in the references section. 690 Apart from above, no substantial changes has occured in the 691 document. Several editorial changes, however, have been made 692 to comply with the rfc editors requirements: 694 References splitted in normative and informative sections, 695 other related references added. 697 Abstract shortened. 699 Changed all occurances of MUST, MAY etc. to lowercase to 700 reflect that this is not a standards track document. 702 Sections moved around so they appear in the required order. 704 draft-ietf-magma-snoop-04.txt: November 2002 706 Editorial changes only. 708 draft-ietf-magma-snoop-03.txt: October 2002 710 IGMP Forwarding rules: 711 Add references to and become consistant with the current 712 IGMP proxy draft, 714 Unrecognized IGMP packets should not be ignored because 715 "mbz" fields are not zero since packets from future 716 versions are expected to maintain consistency. 718 Corrections related to IGMP Querier election process. 720 Add clarification to how lists of router ports may be 721 assembled. 723 Data Forwarding rules: 724 Added discussion of the problems for different IGMP 725 environments in choosing whether to flood or to prune 726 unregistered multicasts. 728 Added refinements for how to handle NON-IPv4 multicasts, 729 to keep IGMP-snooping functionality from interfering with 730 IPv6 and other multicast traffic. Any filtering for non- 731 IPv4 multicasts should be based on bridge behavior and 732 not IGMP snooping behavior. 734 IGMP snooping related problems: 735 Fixed description of interoperability issues in 736 environments with v3 routers and hosts, and v2 snooping 737 switches. 739 Added discussion of the IGMPv3 "include source" and 740 "exclude source" options, and the inability to support 741 them on shared segments. 743 IPv6 Considerations: 744 Clarifications regarding address ranges FF00::, FF01:: 745 and all hosts FF02::1 in relation to data forwarding. 747 draft-ietf-magma-snoop-02.txt: June 2002 749 Status section removes document history; moved into this 750 section instead. 752 Introduction restores text from the -00 revision that 753 describes snooping and its goals 754 IGMP flooding rules eased, allowing management option to 755 broaden beyond "routers only". 757 Removed a should/MAY inconsistancy between IPv4 Forwarding and 758 IPv6 processing of checksums. 760 IGMP Forwarding Rules: clarify text describing processing of 761 non-zero reserved fields. 763 Data Forwarding Rules, item 3 is changed from "MUST forward to 764 all ports" to "MAY"; item 4 default changes from "MUST" to 765 "should use network addresses". 767 Added two sets of additional responses to the questionnaire 768 and text indicating that responses don't cover all products. 770 Removed (commented out) description of IPR issues: IESG is 771 aware of them. 773 draft-ietf-magma-snoop-01.txt: January 2002 775 Extensive restructuring of the original text. 777 draft-ietf-idmr-snoop-01.txt: 2001 779 Added several descriptions of cases where IGMP snooping 780 implementations face problems. Also added several network 781 topology figures. 783 draft-ietf-idmr-snoop-00.txt: 2001 785 Initial snooping draft. An overview of IGMP snooping and the 786 problems to be solved. 788 5. References 790 5.1. Normative References 792 [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" 794 [IGMPv3] Cain, B., "Internet Group Management Protocol, 795 Version 3", RFC3376, October 2002. 797 [IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6 798 Packets over IEEE 1394 Networks", RFC3146, 799 October 2001. 801 [IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over 802 Ethernet Networks", RFC2464, December 1998. 804 [IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over 805 FDDI Networks", RFC2467, December 1998. 807 [IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., 808 "Transmission of IPv6 Packets over Token Ring 809 Networks", RFC2470, December 1998. 811 [MLD] Deering, S., Fenner, B. and Haberman, B. 812 "Multicast Listener Discovery (MLD) for IPv6", 813 RFC2710, October 1999. 815 [MLDv2] Vida, R. and Costa, L., "Multicast Listener 816 Discovery Version 2 (MLDv2) for IPv6", draft- 817 vida-mld-v2-06.txt, November 2002. 819 [MRDISC] Biswas, S., Cain, B. and Haberman, B., "Multicast 820 Router Discovery", draft-ietf-idmr-igmp- 821 mrdisc-10.txt, January 2003. 823 [NDP] Narten, T., Nordmark, E. and Simpson, W., 824 "Neighbor Discovery for IP Version 6 {IPv6)", 825 RFC2461, December 1998. 827 [PROXY] Fenner, B. et al, "IGMP/MLD-based Multicast 828 Forwarding (IGMP/MLD Proxying)", draft-ietf- 829 magma-igmp-proxy-02.txt, November 2002. 831 [RFC1112] Deering, S., "Host Extensions for IP 832 Multicasting", RFC1112, August 1989. 834 [RFC2026] Bradner, S. "The Internet Standards Process -- 835 Revision 3", RFC2026, October 1996. 837 [RFC2236] Fenner, W., "Internet Group Management Protocol, 838 Version 2", RFC2236, November 1997. 840 5.2. Informative References 842 [IANA] Internet Assigned Numbers Authority, "Internet 843 Multicast Addresses", 844 http://www.iana.org/assignments/multicast- 845 addresses 847 [CISCO] Cisco Tech Notes, "Multicast In a Campus Network: 848 CGMP and IGMP snooping", 849 http://www.cisco.com/warp/public/473/22.html 851 [MSOFT] Microsoft support article Q223136, "Some LAN 852 Switches with IGMP Snooping Stop Forwarding 853 Multicast Packets on RRAS Startup", 854 http://support.microsoft.com/support/articles/Q223/1/36.ASP 856 [IETF56] Briefing by Dave Thaler, Microsoft, presented to 857 the MAGMA WG at the 56'th IETF meeting in San 858 Francisco, 859 http://www.ietf.org/proceedings/03mar/index.html 861 [RFC2375] Hinden, R. "IPv6 Multicast Address Assignments", 862 RFC2375, July 1998. 864 6. Security Considerations 866 Security considerations for IGMPv3 are accounted for in 867 [IGMPv3]. The introduction of IGMP snooping switches adds the 868 following considerations with regard to IP multicast. 870 - The exclude source failure, which could cause traffic from 871 sources that are 'black listed' to reach hosts that have 872 requested otherwise. This can also occur in certain 873 network topologies without IGMP snooping. 875 - It is possible to generate packets which make the switch 876 wrongly believe that there is a multicast router on the 877 segment on which the source is attached. This will 878 potentially lead to excessive flooding on that segment. 879 The authentication methods discussed in [IGMPv3] will also 880 provide protection in this case. 882 - IGMP snooping switches which rely on the IP header of a 883 packet for their operation and which do not validate the 884 header checksum potentially will forward packets on the 885 wrong ports. Even though the IP headers are protected by 886 the Ethernet checksum this is a potential vulnerability. 888 - In IGMP, there is no mechanism for denying recipients 889 access to groups (i.e. no "exclude receiver" 890 functionality). Hence, apart from IP-level security 891 configuration outside the scope of IGMP, any multicast 892 stream may be received by any host without restriction. 894 Generally, IGMP snooping must be considered insecure due to 895 the issues above. However, none of the these issues are any 896 worse for IGMP snooping than for IGMP implementations in 897 general. 899 7. Acknowledgements 901 We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben 902 Carter, Paul Congdon, Toerless Eckert, Bill Fenner, Brian 903 Haberman, Edward Hilquist, Hugh Holbrook, Kevin Humphries, 904 Pekka Savola, Suzuki Shinsuke, Jaff Thomas, and Rolland Vida 905 for comments and suggestions on this document. 907 Furthermore, the following companies are acknowledged for 908 their contributions: 3Com, Alcatel, Cisco Systems, Enterasys 909 Networks, Hewlett-Packard, Vitesse Semiconductor Corporation. 910 The ordering of these names do not necessarily correspond to 911 the column numbers in the response table. 913 8. Authors' Addresses 915 Morten Jagd Christensen 916 Thrane & Thrane 917 Lundtoftegaardsvej 93 D 918 2800 Lyngby 919 email: mjc@tt.dk 921 Karen Kimball 922 Hewlett-Packard 923 8000 Foothills Blvd. 924 Roseville, CA 95747 925 email: karen.kimball@hp.com 927 Frank Solensky 928 email: solenskyf@acm.org 930 9. IETF IPR Statement 932 "The IETF takes no position regarding the validity or scope of 933 any intellectual property or other rights that might be 934 claimed to pertain to the implementation or use of the 935 technology described in this document or the extent to which 936 any license under such rights might or might not be available; 937 neither does it represent that it has made any effort to 938 identify any such rights. Information on the IETF's 939 procedures with respect to rights in standards-track and 940 standards-related documentation can be found in [RFC-2026]. 941 Copies of claims of rights made available for publication and 942 any assurances of licenses to be made available, or the result 943 of an attempt made to obtain a general license or permission 944 for the use of such proprietary rights by implementors or 945 users of this specification can be obtained from the IETF 946 Secretariat." 948 10. Full Copyright Statement 950 Copyright (C) The Internet Society (2003). All Rights 951 Reserved. 953 This document and translations of it may be copied and 954 furnished to others, and derivative works that comment on or 955 otherwise explain it or assist in its implementation may be 956 prepared, copied, published and distributed, in whole or in 957 part, without restriction of any kind, provided that the above 958 copyright notice and this paragraph are included on all such 959 copies and derivative works. However, this document itself 960 may not be modified in any way, such as by removing the 961 copyright notice or references to the Internet Society or 962 other Internet organizations, except as needed for the purpose 963 of developing Internet standards in which case the procedures 964 for copyrights defined in the Internet Standards process must 965 be followed, or as required to translate it into languages 966 other than English. 968 The limited permissions granted above are perpetual and will 969 not be revoked by the Internet Society or its successors or 970 assigns. 972 This document and the information contained herein is provided 973 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 974 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 975 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 976 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 977 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 978 PARTICULAR PURPOSE. 980 Acknowledgement: 982 Funding for the RFC Editor function is currently provided by 983 the Internet Society.