idnits 2.17.1 draft-ietf-magma-snoop-10.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 24 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 23 instances of lines with control characters in the document. == 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 784: '...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 756 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 (October 2003) is 7498 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC-2026' is mentioned on line 1065, but not defined == Unused Reference: 'IANA' is defined on line 937, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-vida-mld-v2-06 ** Obsolete normative reference: RFC 2461 (ref. 'NDP') (Obsoleted by RFC 4861) == Outdated reference: A later version (-06) exists of draft-ietf-magma-igmp-proxy-02 Summary: 7 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: March 2004 K. Kimball 5 Category: Informational Hewlett-Packard 6 F. Solensky 7 West Ridge Networks 8 October 2003 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 (2003). 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 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 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 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 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 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 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 196 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 198 to indicate that the Query packets are NOT from a multicast 199 router. 201 c) Ports explicitly configured by management to be IGMP- 202 forwarding ports, in addition to or instead of any of the 203 above methods to detect router ports. 205 2) IGMP snooping switches may also implement "proxy-reporting" in 206 which reports received from downstream hosts are summarized and 207 used to build internal membership states as described in 208 [PROXY]. The IGMP proxy-reporting switch would then report its 209 own state in response to upstream queriers. If the switch does 210 not already have an IP address assigned to it, the source 211 address for these reports should be set to all-zeros. 213 An IGMP proxy-reporting switch may act as Querier for the 214 downstream hosts while proxy reporting to the 'real' upstream 215 queriers. 217 It should be noted that there may be multiple IGMP proxy- 218 reporting switches in the network all using the 0.0.0.0 source 219 IP address. In this case the switches can be uniquely 220 identified through their link layer source MAC address. 222 IGMP membership reports must not be rejected by an IGMP 223 snooping switch because of a source IP address of 0.0.0.0. 225 3) The switch that supports IGMP snooping must flood all 226 unrecognized IGMP messages to all other ports and must not 227 attempt to make use of any information beyond the end of the 228 network layer header. 230 In addition, earlier versions of IGMP should interpret IGMP 231 fields as defined for their versions and must not alter these 232 fields when forwarding the message. When generating new 233 messages, a given IGMP version should set fields to the 234 appropriate values for its own version. If any fields are 235 reserved or otherwise undefined for a given IGMP version, the 236 fields should be ignored when parsing the message and must be 237 set to zeroes when new messages are generated by 238 implementations of that IGMP version. An exception may occur 239 if the switch is performing a spoofing function, and is aware 240 of the settings for new or reserved fields that would be 241 required to correctly spoof for a different IGMP version. 243 The reason to worry about these trivialities is that IGMPv3 244 overloads the old IGMP query message using the same type number 245 (0x11) but with an extended header. Therefore there is a risk 247 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 249 that IGMPv3 queries may be interpreted as older version queries 250 by, for example, IGMPv2 snooping switches. This has already 251 been reported [IETF56] and is discussed in section 2.2. 253 4) An IGMP snooping switch should be aware of link layer topology 254 changes caused by Spanning Tree operation. When a port is 255 enabled or disabled by Spanning Tree, a General Query may be 256 sent on all active non-router ports in order to reduce network 257 convergence time. Non-Querier switches should be aware of 258 whether the Querier is in IGMPv3 mode. If so, the switch should 259 not spoof any General Queries unless it is able to send an 260 IGMPv3 Query that adheres to the most recent information sent 261 by the true Querier. In no case should a switch introduce a 262 spoofed IGMPv2 Query into an IGMPv3 network, as this may create 263 excessive network disruption. 265 If the switch is not the Querier, it should use the 'all-zeros' 266 IP Source Address in these proxy queries (even though some 267 hosts may elect to not process queries with a 0.0.0.0 IP Source 268 Address). When such proxy queries are received, they must not 269 be included in the Querier election process. 271 5) An IGMP snooping switch must not make use of information in 272 IGMP packets where the IP or IGMP headers have checksum or 273 integrity errors. The switch should not flood such packets but 274 if it does, it should also take some note of the event (i.e., 275 increment a counter). These errors and their processing are 276 further discussed in [IGMPv3], [MLD] and [MLDv2]. 278 6) The snooping switch must not rely exclusively on the appearance 279 of IGMP Group Leave announcements to determine when entries 280 should be removed from the forwarding table. It should 281 implement a membership timeout mechanism such as the router- 282 side functionality of the IGMP protocol as described in the 283 IGMP and MLD specifications (See Normative Reference section 284 for IGMPv1-3 and MLDv1-2) on all its non-router ports. This 285 timeout value should be configurable. 287 2.1.2. Data Forwarding Rules 289 1) Packets with a destination IP address outside 224.0.0.X which 290 are not IGMP should be forwarded according to group-based port 291 membership tables and must also be forwarded on router ports. 293 This is the main IGMP snooping functionality for the data path. 295 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 297 One approach that an implementation could take would be to 298 maintain separate membership and multicast router tables in 299 software and then "merge" these tables into a forwarding cache. 301 2) Packets with a destination IP (DIP) address in the 224.0.0.X 302 range which are not IGMP must be forwarded on all ports. 304 This recommendation is based on fact that many host systems do 305 not send Join IP multicast addresses in this range before 306 sending or listening to IP multicast packets. Furthermore, 307 since the 224.0.0.X address range is defined as link-local (not 308 to be routed) it seems unnecessary to keep state for each 309 address in this range. Additionally, some routers operate in 310 the 224.0.0.X address range without issuing IGMP Joins, and 311 these applications would break if the switch were to prune them 312 due to not having seen a Join Group message from the router. 314 3) An unregistered packet is defined as an IPv4 multicast packet 315 with a destination address which does not match any of the 316 groups announced in earlier IGMP Membership Reports. 318 If a switch receives an unregistered packet, it must forward 319 that packet on all ports to which an IGMP router is attached. 320 A switch may default to forwarding unregistered packets on all 321 ports. Switches that do not forward unregistered packets to 322 all ports must include a configuration option to force the 323 flooding of unregistered packets on specified ports. 325 In an environment where IGMPv3 hosts are mixed with snooping 326 switches that do not yet support IGMPv3, the switch's failure 327 to flood unregistered streams could prevent v3 hosts from 328 receiving their traffic. Alternatively, in environments where 329 the snooping switch supports all of the IGMP versions that are 330 present, flooding unregistered streams may cause IGMP hosts to 331 be overwhelmed by multicast traffic, even to the point of not 332 receiving Queries and failing to issue new membership reports 333 for their own groups. 335 It is encouraged that snooping switches at least recognize and 336 process IGMPv3 Join Reports, even if this processing is limited 337 to the behavior for IGMPv2 Joins, i.e., is done without 338 considering any additional "include source" or "exclude source" 339 filtering. When IGMPv3 Joins are not recognized, a snooping 340 switch may incorrectly prune off the unregistered data streams 341 for the groups (as noted above); alternatively, it may fail to 342 add in forwarding to any new IGMPv3 hosts if the group has 343 previously been joined as IGMPv2 (because the data stream is 344 seen as already having been registered). 346 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 348 4) All non-IPv4 multicast packets should continue to be flooded 349 out all remaining ports in the forwarding state as per normal 350 IEEE bridging operations. 352 This recommendation is a result of the fact that groups made up 353 of IPv4 hosts and IPv6 hosts are completely separate and 354 distinct groups. As a result, information gleaned from the 355 topology between members of an IPv4 group would not be 356 applicable when forming the topology between members of an IPv6 357 group. 359 5) IGMP snooping switches may maintain forwarding tables based on 360 either MAC addresses or IP addresses. If a switch supports 361 both types of forwarding tables then the default behavior 362 should be to use IP addresses. IP address based forwarding is 363 preferred because the mapping between IP multicast addresses 364 and link-layer multicast addresses is ambiguous. In the case 365 of Ethernet, there is a multiplicity of 1 Ethernet address to 366 32 IP addresses [RFC1112]. 368 6) Switches which rely on information in the IP header should 369 verify that the IP header checksum is correct. If the checksum 370 fails, the information in the packet must not be incorporated 371 into the forwarding table. Further, the packet should be 372 discarded. 374 7) When IGMPv3 "include source" and "exclude source" membership 375 reports are received on shared segments, the switch needs to 376 forward the superset of all received membership reports onto 377 the shared segment. Forwarding of traffic from a particular 378 source S to a group G must happen if at least one host on the 379 shared segment reports an IGMPv3 membership of the type 380 INCLUDE(G, Slist1) or EXCLUDE(G, Slist2) where S is an element 381 of Slist1 and not an element of Slist2. 383 The practical implementation of the (G,S1,S2,...) based data 384 forwarding tables are not within the scope of this document. 385 However, one possibility is to maintain two (G,S) forwarding 386 lists: one for the INCLUDE filter where a match of a specific 387 (G,S) is a requirement before forwarding will happen, and one 388 for the EXCLUDE filter where a match of a specific (G,S) will 389 result in no forwarding. 391 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 393 2.2. IGMP snooping-related problems 395 A special problem arises in networks consisting of IGMPv3 routers 396 as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 397 snooping switch as recently reported [IETF56]. The router will 398 continue to maintain IGMPv3 even in the presence of IGMPv2 hosts, 399 and thus the network will not converge on IGMPv2. But it is likely 400 that the IGMPv2 snooping switch will not recognize or process the 401 IGMPv3 membership reports. Groups for these unrecognized reports 402 will then either be flooded (with all of the problems that may 403 create for hosts in a network with a heavy multicast load) or 404 pruned by the snooping switch. 406 Therefore, it is recommended that in such a network, the multicast 407 router be configured to use IGMPv2. If this is not possible, and if 408 the snooping switch cannot recognize and process the IGMPv3 409 membership reports, it is instead recommended that the switch's 410 IGMP snooping functionality be disabled, as there is no clear 411 solution to this problem. 413 3. IPv6 Considerations 415 In order to avoid confusion, the previous discussions have been 416 based on the IGMP protocol which only applies to IPv4 multicast. 417 In the case of IPv6 most of the above discussions are still valid 418 with a few exceptions which we will describe here. 420 The control and data forwarding rules in the IGMP section can, with 421 a few considerations, also be applied to MLD. This means that the 422 basic functionality of intercepting MLD packets, and building 423 membership lists and multicast router lists, is the same as for 424 IGMP. 426 In IPv6, the data forwarding rules are more straight forward 427 because MLD is mandated for addresses with scope 2 (link-scope) or 428 greater. The only exception is the address FF02::1 which is the 429 all hosts link-scope address for which MLD messages are never sent. 430 Packets with the all hosts link-scope address should be forwarded 431 on all ports. 433 MLD messages are also not sent regarding groups with addresses in 434 the range FF00::/15 (which encompasses both the reserved FF00::/16 435 and node-local FF01::/16 IPv6 address spaces). These addresses 436 should never appear in packets on the link. 438 Equivalent to the IPv4 behaviors regarding the null IP Source 439 address, MLD membership reports must not be rejected by an MLD 441 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 443 snooping switch because of an unspecified IP source address (::). 444 Additionally, if a non-Querier switch spoofs any General Queries 445 (as addressed in Section 2.1 above, for Spanning Tree topology 446 changes), the switch should use the null IP source address (::) 447 when sending said queries. When such proxy queries are received, 448 they must not be included in the Querier election process. 450 The three major differences between IPv4 and IPv6 in relation to 451 multicast are: 453 - The IPv6 protocol for multicast group maintenance is called 454 Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message 455 types instead of IGMP message types. 457 - The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128 458 bit DIP address are used to form the 48 bit DMAC addresses for 459 multicast groups, while [IPV6-TOKEN] describes the mapping for 460 token ring DMAC addresses by using three low-order bits. The 461 specification [IPV6-1394] makes use of a 6 bit channel number. 463 - Multicast router discovery is accomplished using Neighbor 464 Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message 465 types. 467 The IPv6 packet header does not include a checksum field. 468 Nevertheless, the switch should detect other packet integrity 469 issues such as address version and payload length consistencies if 470 possible. When the snooping switch detects such an error, it must 471 not include information from the corresponding packet in the MLD 472 forwarding table. The forwarding code should instead drop the 473 packet and take further reasonable actions as advocated above. 475 The fact that MLDv2 is using ICMPv6 adds new requirements to a 476 snooping switch because ICMPv6 has multiple uses aside from MLD. 477 This means that it is no longer sufficient to detect that the next- 478 header field of the IP header is ICMPv6 in order to identify 479 packets relevant for MLD snooping. A software-based implemention 480 which treats all ICMPv6 packets as candidates for MLD snooping 481 could easily fill its receive queue and bog down the CPU with 482 irrelevant packets. This would prevent the snooping functionality 483 from performing its intended purpose and the non-MLD packets 484 destined for other hosts could be lost. 486 A solution is either to require that the snooping switch looks 487 further into the packets, or to be able to detect a multicast DMAC 488 address in conjunction with ICMPv6. The first solution is 489 desirable when a configuration option allows the administrator to 490 specify which ICMPv6 message types should trigger a CPU redirect 492 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 494 and which should not. The reason is that a hardcoding of message 495 types is inflexible for the introduction of new message types. The 496 second solution introduces the risk that new protocols which use 497 ICMPv6 and multicast DMAC addresses could be incorrectly identified 498 as MLD. It is suggested that solution one is preferred when the 499 configuration option is provided. If this is not the case, then 500 the implementor should seriously consider making it available since 501 Neighbor Discovery messages would be among those that fall into 502 this false positive case and are vital for the operational 503 integrity of IPv6 networks. 505 The mapping from IP multicast addresses to multicast DMAC addresses 506 introduces a potentially enormous overlap. The structure of an 507 IPv6 multicast address is shown in the figure below. As a result, 508 there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses 509 which map into a single DMAC address in Ethernet and FDDI. This 510 should be compared to 2**5 in the case of IPv4. 512 Initial allocation of IPv6 multicast addresses as described in 513 [RFC3307], however, cover only the lower 32 bits of group ID. 514 While this reduces the problem of address ambiguity to group IDs 515 with different flag and scope values for now, it should be noted 516 that the allocation policy may change in the future. Because of 517 the potential overlap it is recommended that IPv6 address based 518 forwarding is preferred to MAC address based forwarding. 520 | 8 | 4 | 4 | 112 bits | 521 +--------+----+----+---------------------------------------+ 522 |11111111|flgs|scop| group ID | 523 +--------+----+----+---------------------------------------+ 525 4. IGMP Questionnaire 527 As part of this work the following questions were asked both on the 528 MAGMA discussion list and sent to known switch vendors implementing 529 IGMP snooping. The individual contributions have been anonymized 530 upon request and do not necessarily apply to all of the vendors' 531 products. 533 The questions were: 535 Q1 Does your switches perform IGMP Join aggregation? In other 536 words, are IGMP joins intercepted, absorbed by the 537 hardware/software so that only one Join is forwarded to the 538 querier? 540 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 542 Q2 Is multicast forwarding based on MAC addresses? Would 543 datagrams addressed to multicast IP addresses 224.1.2.3 and 544 239.129.2.3 be forwarded on the same ports-groups? 546 Q3 Is it possible to forward multicast datagrams based on IP 547 addresses (not routed)? In other words, could 224.1.2.3 and 548 239.129.2.3 be forwarded on different port-groups with 549 unaltered TTL? 551 Q4 Are multicast datagrams within the range 224.0.0.1 to 552 224.0.0.255 forwarded on all ports whether or not IGMP Joins 553 have been sent? 555 Q5 Are multicast frames within the MAC address range 556 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports 557 whether or not IGMP joins have been sent? 559 Q6 Does your switch support forwarding to ports on which IP 560 multicast routers are attached in addition to the ports where 561 IGMP Joins have been received? 563 Q7 Is your IGMP snooping functionality fully implemented in 564 hardware? 566 Q8 Is your IGMP snooping functionality partly software 567 implemented? 569 Q9 Can topology changes (for example spanning tree configuration 570 changes) be detected by the IGMP snooping functionality so that 571 for example new queries can be sent or tables can be updated to 572 ensure robustness? 574 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 576 The answers were: 578 ---------------------------+-----------------------+ 579 | Switch Vendor | 580 ---------------------------+---+---+---+---+---+---+ 581 | 1 | 2 | 3 | 4 | 5 | 6 | 582 ---------------------------+---+---+---+---+---+---+ 583 Q1 Join aggregation | x | x | x | | x | x | 584 Q2 Layer-2 forwarding | x | x | x | x |(1)| | 585 Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x | 586 Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x | 587 Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x | 588 Q6 Mcast router list | x | x | x | x | x | x | 589 Q7 Hardware implemented | | | | | | | 590 Q8 Software assisted | x | x | x | x | x | x | 591 Q9 Topology change aware | x | x | x | x | |(2)| 592 ---------------------------+---+---+---+---+---+---+ 593 x Means that the answer was Yes. 594 (1) In some products (typically high-end) Yes; in others No. 595 (2) Not at the time that the questionnaire was received 596 but expected in the near future. 598 Revision History 600 [To RFC Editor: This section is to be removed at publication time] 602 This section, while incomplete, is provided as a convenience to the 603 working group members. It will be removed when the document is 604 released in its final form. 606 draft-ietf-magma-snoop-10.txt: October 2003 608 The changes in this version are the result of the IESG review. 610 Substantial comments 612 The security considerations section was found a little 613 too brief. It has now been extended. 615 Editorial Changes 617 Removed reference RFC2375, using RFC3307 instead. New 618 author address information. 620 draft-ietf-magma-snoop-09.txt: August 2003 622 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 624 The changes in this version are the result of the AD review 625 following the WG chair review. 627 Substantial comments 629 There were no substantial technical comments, but a list 630 of suggested wordings and clarifications to improve the 631 readability and RFC conformance of the draft. 633 Reference in Abstract removed. Improved wording in 634 Introduction. 636 Improved wording in recommendations section, clarified 637 integrity checking for IPv6, removed security issues 638 which were really IGMP/MLD security issues. 640 Editorial Changes 642 Author information changes, TOC added, fixed a wrong 643 indentation following section 5. 645 draft-ietf-magma-snoop-08.txt: June 2003 647 The changes in this version are the result of the WG chair 648 review following the second WG last call. The last call itself 649 did not result in further comments. 651 Substantial comments 653 Requirements have now been replaced with Recommendations 654 throughout the draft, which is more appropriate for an 655 Informational draft. 657 Clarifications regarding the overloading of the IGMP 658 query message in section 2.1.1. 660 Clarification regarding the data forwarding in the case 661 of INCLUDE/EXCLUDE filters. 663 More detail added on the special case of Source IP 664 address 0.0.0.0. 666 Editorial Changes 668 Moved Data Forwarding recommendation up as first bullet 669 as it really is the main recommendation. 671 Added a more suitable reference for the Thaler briefing 673 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 675 at the 56'th IETF meeting. Hopefully it will become a 676 valid link sometime soon. 678 Moved reference to RFC2375 to the Informative section. 680 draft-ietf-magma-snoop-07.txt: May 2003 682 The current version reflects comments made at the 56'th IETF 683 meeting and from the previous WG last call. The majority of 684 changes appear in sections 2.1 and 2.2, and even the changes 685 here are in reality not substantial. 687 Substantial comments 689 Section 2.1.1.(4): Changed wording for IGMP forwarding 690 section on when spoofing of General Queries should occur. 691 Added description of how to avoid IGMP version 692 incompatibility problems when doing said spoofing. 694 Section 2.1.2.(3): Clarification of incompatibility 695 problems in mixed IGMPv2 and IGMPv3 networks. Added 696 recommendation for switches to implement some level of 697 IGMPv3 Join recognition to reduce these problems. 699 Section 2.2: Advice following the briefing [IETF56], that 700 in some cases disabling IGMP snooping functionality is 701 the only 'solution' 703 Section 6, IPv6 Considerations: added descriptions of 704 behavior involving the IPv6 version of the null IP Source 705 Address (to parallel the IPv4 behaviors). 707 Added reference to [IGMPv3] in stead of [PROXY] for group 708 membership maintenance and timeout. 710 Editorial Changes 712 Really minor stuff such as change of authors email 713 address, addition of references, draft name increment and 714 date changes. 716 draft-ietf-magma-snoop-06.txt: March 2003 718 Changes in response to comments made during WG last call and 719 assessment by the WG chairs: 721 Substantial comments 723 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 725 Clarification in IGMP forwarding section on the 726 acceptance of membership reports with source IP address 727 0.0.0.0 as being a switch recommendation. 729 Section 2.1.1.(4): Allow the router port to be excluded 730 from the General Query messages 732 Section 2.1.1.(6): Replace description of timing out 733 older entries with a reference to IGMP/MLD Proxying. 735 Section 2.1.2.(3): Replaced description of timeout 736 mechanism with a reference to IGMP/MLD. 738 Section 2.1.2.(4) Expanded rationale to discourage 739 leaking info between IPv4 and IPv6 groups. 741 Section 3: more strongly encourage the use of a 742 configuration option for selection of ICMPv6 message 743 types. 745 Editorial comments. 747 Hyphenation problem resolved for groff by setting then ms 748 HY register to zero, disabling all forms for the entire 749 document 750 (".hy 0" and ".nr" worked only as far as the following 751 ms macro). 753 Sections moved around - again - to comply with 754 rfc2223bis-03 draft. Added copyright notice after memo 755 status. Removed table of contents as the draft is fairly 756 short. Corrected a reference typo. 758 Section 2.1.2.(3): Requirement and rationale broken into 759 separate paragraphs. 761 Added references to other IPv6 encapsulation documents, 763 Corrected estimates for MAC address collisions for 764 Ethernet and FDDI: both specification take the low-order 765 four (not six) bytes from the IPv6 group addresses. 767 draft-ietf-magma-snoop-05.txt: January 2003 769 Changes in wording of IGMP forwarding rule 6) and Data 770 forwarding rule 7). Corrections in the references section. 772 Apart from above, no substantial changes has occured in the 774 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 776 document. Several editorial changes, however, have been made 777 to comply with the rfc editors requirements: 779 References splitted in normative and informative sections, 780 other related references added. 782 Abstract shortened. 784 Changed all occurances of MUST, MAY etc. to lowercase to 785 reflect that this is not a standards track document. 787 Sections moved around so they appear in the required order. 789 draft-ietf-magma-snoop-04.txt: November 2002 791 Editorial changes only. 793 draft-ietf-magma-snoop-03.txt: October 2002 795 IGMP Forwarding rules: 796 Add references to and become consistant with the current 797 IGMP proxy draft, 799 Unrecognized IGMP packets should not be ignored because 800 "mbz" fields are not zero since packets from future 801 versions are expected to maintain consistency. 803 Corrections related to IGMP Querier election process. 805 Add clarification to how lists of router ports may be 806 assembled. 808 Data Forwarding rules: 809 Added discussion of the problems for different IGMP 810 environments in choosing whether to flood or to prune 811 unregistered multicasts. 813 Added refinements for how to handle NON-IPv4 multicasts, 814 to keep IGMP-snooping functionality from interfering with 815 IPv6 and other multicast traffic. Any filtering for non- 816 IPv4 multicasts should be based on bridge behavior and 817 not IGMP snooping behavior. 819 IGMP snooping related problems: 820 Fixed description of interoperability issues in 821 environments with v3 routers and hosts, and v2 snooping 822 switches. 824 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 826 Added discussion of the IGMPv3 "include source" and 827 "exclude source" options, and the inability to support 828 them on shared segments. 830 IPv6 Considerations: 831 Clarifications regarding address ranges FF00::, FF01:: 832 and all hosts FF02::1 in relation to data forwarding. 834 draft-ietf-magma-snoop-02.txt: June 2002 836 Status section removes document history; moved into this 837 section instead. 839 Introduction restores text from the -00 revision that 840 describes snooping and its goals 842 IGMP flooding rules eased, allowing management option to 843 broaden beyond "routers only". 845 Removed a should/MAY inconsistancy between IPv4 Forwarding and 846 IPv6 processing of checksums. 848 IGMP Forwarding Rules: clarify text describing processing of 849 non-zero reserved fields. 851 Data Forwarding Rules, item 3 is changed from "MUST forward to 852 all ports" to "MAY"; item 4 default changes from "MUST" to 853 "should use network addresses". 855 Added two sets of additional responses to the questionnaire 856 and text indicating that responses don't cover all products. 858 Removed (commented out) description of IPR issues: IESG is 859 aware of them. 861 draft-ietf-magma-snoop-01.txt: January 2002 863 Extensive restructuring of the original text. 865 draft-ietf-idmr-snoop-01.txt: 2001 867 Added several descriptions of cases where IGMP snooping 868 implementations face problems. Also added several network 869 topology figures. 871 draft-ietf-idmr-snoop-00.txt: 2001 873 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 875 Initial snooping draft. An overview of IGMP snooping and the 876 problems to be solved. 878 5. References 880 5.1. Normative References 882 [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" 884 [IGMPv3] Cain, B., "Internet Group Management Protocol, Version 885 3", RFC3376, October 2002. 887 [IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6 888 Packets over IEEE 1394 Networks", RFC3146, October 889 2001. 891 [IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over 892 Ethernet Networks", RFC2464, December 1998. 894 [IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 895 Networks", RFC2467, December 1998. 897 [IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., "Transmission 898 of IPv6 Packets over Token Ring Networks", RFC2470, 899 December 1998. 901 [MLD] Deering, S., Fenner, B. and Haberman, B. "Multicast 902 Listener Discovery (MLD) for IPv6", RFC2710, October 903 1999. 905 [MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery 906 Version 2 (MLDv2) for IPv6", draft-vida-mld-v2-06.txt, 907 November 2002. 909 [MRDISC] Biswas, S., Cain, B. and Haberman, B., "Multicast 910 Router Discovery", draft-ietf-idmr-igmp-mrdisc-10.txt, 911 January 2003. 913 [NDP] Narten, T., Nordmark, E. and Simpson, W., "Neighbor 914 Discovery for IP Version 6 {IPv6)", RFC2461, December 915 1998. 917 [PROXY] Fenner, B. et al, "IGMP/MLD-based Multicast 918 Forwarding (IGMP/MLD Proxying)", draft-ietf-magma- 919 igmp-proxy-02.txt, November 2002. 921 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 923 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 924 RFC1112, August 1989. 926 [RFC2026] Bradner, S. "The Internet Standards Process -- 927 Revision 3", RFC2026, October 1996. 929 [RFC2236] Fenner, W., "Internet Group Management Protocol, 930 Version 2", RFC2236, November 1997. 932 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 933 Multicast Addresses", RFC3307, August 2002. 935 5.2. Informative References 937 [IANA] Internet Assigned Numbers Authority, "Internet 938 Multicast Addresses", 939 http://www.iana.org/assignments/multicast-addresses 941 [CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP 942 and IGMP snooping", 943 http://www.cisco.com/warp/public/473/22.html 945 [MSOFT] Microsoft support article Q223136, "Some LAN Switches 946 with IGMP Snooping Stop Forwarding Multicast Packets 947 on RRAS Startup", 948 http://support.microsoft.com/support/articles/Q223/1/36.ASP 950 [IETF56] Briefing by Dave Thaler, Microsoft, presented to the 951 MAGMA WG at the 56'th IETF meeting in San Francisco, 952 http://www.ietf.org/proceedings/03mar/index.html 954 6. Security Considerations 956 Under normal network operation, the snooping switch is expected to 957 improve overall network performance by limiting the scope of 958 multicast flooding to a smaller portion of the local network. In 959 the event of forged IGMP messages, the benefits of using a snooping 960 switch might be reduced or eliminated. 962 Security considerations for IGMPv3 at the network layer of the 963 protocol stack are described in [IGMPv3]. The introduction of IGMP 964 snooping functionality does not alter the handling of multicast 965 packets by the router as it does not make use of link layer 967 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 969 information. 971 There are, however, changes in the way that the IGMP snooping 972 switch handles multicast packets within the local network. In 973 particular: 975 - A Query message with a forged source address which is less than 976 that of the current Querier could cause snooping switches to 977 forward subsequent Membership reports to the wrong network 978 interface. It is for this reason that IGMP Membership Reports 979 should be sent to all multicast routers as well as the current 980 Querier. 982 - It is possible for a host on the local network to generate 983 Current-State Report Messages that would cause the switch to 984 incorrectly believe that there is a multicast listener on the 985 same network segment as the originator of the forged message. 986 This will cause unrequested multicast packets to be forwarded 987 into the network segments between the source and the router. 988 If the router requires that all Multicast Report messages be 989 authenticated as described in section 9.4 of [IGMPv3], it will 990 discard the forged Report message from the host inside the 991 network in the same way that it would discard one which 992 originates from a remote location. It is worth noting that if 993 the router accepts unauthenticated Report messages by virtue of 994 them having arrived over a network interface associated with 995 the internal network, investigating the affected network 996 segments will quickly narrow the search for the source of the 997 forged messages. 999 - As noted in [IGMPv3], there is little motivation for an 1000 attacker to forge a Membership report message since joining a 1001 group is generally an unprivileged operation. The sender of 1002 the forged Membership report will be the only recipient of the 1003 multicast traffic to that group. This is in contrast to a 1004 shared LAN segment (HUB) or network without snooping switches, 1005 where all other hosts on the same segment would be unable to 1006 transmit when the network segment is flooding the unwanted 1007 traffic. 1009 The worst case result for each attack would remove the performance 1010 improvements that the snooping functionality would otherwise 1011 provide. It would, however, be no worse than that experienced on a 1012 network with switches that do not perform multicast snooping. 1014 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 1016 7. Acknowledgements 1018 We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter, 1019 Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward 1020 Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka 1021 Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret 1022 Wasserman for comments and suggestions on this document. 1024 Furthermore, the following companies are acknowledged for their 1025 contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, 1026 Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane 1027 The ordering of these names do not necessarily correspond to the 1028 column numbers in the response table. 1030 8. Authors' Addresses 1032 Morten Jagd Christensen 1033 Thrane & Thrane 1034 Lundtoftegaardsvej 93 D 1035 2800 Lyngby 1036 DENMARK 1037 email: mjc@tt.dk 1039 Karen Kimball 1040 Hewlett-Packard 1041 8000 Foothills Blvd. 1042 Roseville, CA 95747 1043 USA 1044 email: karen.kimball@hp.com 1046 Frank Solensky 1047 West Ridge Networks 1048 25 Porter Rd. 1049 Boxboro, MA 01719 1050 USA 1051 email: fsolensky@WestRidgeNetworks.com 1053 9. IETF IPR Statement 1055 "The IETF takes no position regarding the validity or scope of any 1056 intellectual property or other rights that might be claimed to 1057 pertain to the implementation or use of the technology described in 1058 this document or the extent to which any license under such rights 1059 might or might not be available; neither does it represent that it 1060 has made any effort to identify any such rights. Information on 1061 the IETF's procedures with respect to rights in standards-track and 1063 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 1065 standards-related documentation can be found in [RFC-2026]. Copies 1066 of claims of rights made available for publication and any 1067 assurances of licenses to be made available, or the result of an 1068 attempt made to obtain a general license or permission for the use 1069 of such proprietary rights by implementors or users of this 1070 specification can be obtained from the IETF Secretariat." 1072 10. Full Copyright Statement 1074 Copyright (C) The Internet Society (2003). All Rights Reserved. 1076 This document and translations of it may be copied and furnished to 1077 others, and derivative works that comment on or otherwise explain 1078 it or assist in its implementation may be prepared, copied, 1079 published and distributed, in whole or in part, without restriction 1080 of any kind, provided that the above copyright notice and this 1081 paragraph are included on all such copies and derivative works. 1082 However, this document itself may not be modified in any way, such 1083 as by removing the copyright notice or references to the Internet 1084 Society or other Internet organizations, except as needed for the 1085 purpose of developing Internet standards in which case the 1086 procedures for copyrights defined in the Internet Standards process 1087 must be followed, or as required to translate it into languages 1088 other than English. 1090 The limited permissions granted above are perpetual and will not be 1091 revoked by the Internet Society or its successors or assigns. 1093 This document and the information contained herein is provided on 1094 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1095 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1096 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1097 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1098 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1100 Acknowledgement: 1102 Funding for the RFC Editor function is currently provided by the 1103 Internet Society. 1105 RFC DRAFT Considerations for IGMP and MLD Snooping SwitchesOctober 2003 1107 Table of Contents 1109 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1110 2. IGMP Snooping Recommendations . . . . . . . . . . . . . . . 3 1111 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3 1112 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 3 1113 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 6 1114 2.2. IGMP snooping-related problems . . . . . . . . . . . . . . 9 1115 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9 1116 4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11 1117 4. Revision History . . . . . . . . . . . . . . . . . . . . . . 13 1118 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 1119 5.1. Normative References . . . . . . . . . . . . . . . . . . . 19 1120 5.2. Informative References . . . . . . . . . . . . . . . . . . 20 1121 6. Security Considerations . . . . . . . . . . . . . . . . . . 20 1122 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 1123 8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 22 1124 9. IETF IPR Statement . . . . . . . . . . . . . . . . . . . . . 22 1125 10. Full Copyright Statement . . . . . . . . . . . . . . . . . 23 1127 [To RFC Editor: The TOC page is to be moved to page 2 at 1128 publication time ] 1130 [To RFC Editor: Page renumbering in TOC and in document will be 1131 necessary ]