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