idnits 2.17.00 (12 Aug 2021) /tmp/idnits52975/draft-ietf-magma-snoop-05.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.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([IGMPv3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 639: '...ll occurances of MUST, MAY etc. to low...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2003) is 7065 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC112' is mentioned on line 96, but not defined == Unused Reference: 'RFC1112' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC2375' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 467, but no explicit reference was found in the text == Outdated reference: draft-vida-mld-v2 has been published as RFC 3810 == Outdated reference: draft-ietf-magma-igmp-proxy has been published as RFC 4605 Summary: 6 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: July 2003 K. Kimball 5 Category: Informational Hewlett-Packard 6 F. Solensky 7 Bluejavelin 8 January 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 Abstract 37 This memo describes the requirements for IGMP- and MLD-snooping 38 switches. These are based on best current practices for IGMPv2, 39 with further considerations for IGMPv3- and MLDv2-snooping. Addi- 40 tional areas of relevance, such as link layer topology changes and 41 Ethernet-specific encapsulation issues, are also considered. 43 Interoperability issues that arise between different versions of 44 IGMP are not the focus of this document. Interested readers are 45 directed to [IGMPv3] for a thorough description of problem areas. 47 This document is intended to accompany the IGMPv3 and MLDv2 49 RFC DRAFT January 2003 51 specifications. 53 1. Introduction 55 When a packet with a broadcast or multicast destination address is 56 received, the switch will forward a copy into each of the remaining 57 network segments in accordance with [BRIDGE]. Eventually, the 58 packet is made accessible to all nodes connected to the network. 60 This approach works well for broadcast packets that are intended to 61 be seen or processed by all connected nodes. In the case of multi- 62 cast packets, however, this approach could lead to less efficient 63 use of network bandwidth, particularly when the packet is intended 64 for only a small number of nodes. Packets will be flooded into 65 network segments where no node has any interest in receiving the 66 packet. While nodes will rarely incur any processing overhead to 67 filter packets addressed to unrequested group addresses, they are 68 unable to transmit new packets onto the shared media for the period 69 of time that the multicast packet is flooded. In general, signifi- 70 cant bandwidth can be wasted by flooding. 72 In recent years, a number of commercial vendors have introduced 73 products described as "IGMP snooping switches" to the market. 74 These devices do not adhere to the conceptual model that provides 75 the strict separation of functionality between different communica- 76 tions layers in the ISO model, and instead utilize information in 77 the upper- level protocol headers as factors to be considered in 78 the processing at the lower levels. This is analogous to the man- 79 ner in which a router can act as a firewall by looking into the 80 transport protocol's header before allowing a packet to be for- 81 warded to its destination address. 83 In the case of multicast traffic, an IGMP snooping switch provides 84 the benefit of conserving bandwidth on those segments of the net- 85 work where no node has expressed interest in receiving packets 86 addressed to the group address. This is in contrast to normal 87 switch behavior where multicast traffic is typically forwarded on 88 all interfaces. 90 Many switch datasheets state support for IGMP snooping, but no 91 requirements for this exist today. It is the authors' hope that 92 the information presented in this draft will supply this founda- 93 tion. 95 The requirements presented here are based on the following informa- 96 tion sources: The IGMP specifications [RFC112][RFC2236][IGMPv3], 97 vendor-supplied technical documents [CISCO], bug reports [MSOFT], 99 RFC DRAFT January 2003 101 discussions with people involved in the design of IGMP snooping 102 switches, MAGMA mailinglist discussions, and on replies by switch 103 vendors to an implementation questionnaire. 105 The discussions in this document are based on IGMP, which applies 106 only to IPv4. For IPv6, MLD must be used instead. Because MLD is 107 based on IGMP, we do not repeat the whole discussion and require- 108 ments for MLD snooping switches. Instead, we point out the few 109 cases where there are differences from IGMP. 111 Note that the IGMP snooping function should apply only to IPv4 mul- 112 ticasts. Other multicast packets, such as IPv6, might be suppressed 113 by IGMP snooping if additional care is not taken in the implementa- 114 tion. It is desired not to restrict the flow of non-IPv4 multi- 115 casts other than to the degree which would happen as a result of 116 regular bridging functions. The same note can be made of MLD snoop- 117 ing switches with respect to suppression of IPv4. 119 2. IGMP Snooping Requirements 121 The following sections list the requirements for an IGMP snooping 122 switch. The requirement is stated and is supplemented by a discus- 123 sion. All implementation discussions are examples only and there 124 may well be other ways to achieve the same functionality. 126 2.1. Forwarding rules 128 The IGMP snooping functionality is here separated into a control 129 section (IGMP forwarding) and a data section (Data forwarding). 131 2.1.1. IGMP Forwarding Rules 133 1) A snooping switch should forward IGMP Membership Reports only 134 to those ports where multicast routers are attached. Alterna- 135 tively stated: a snooping switch should not forward IGMP Mem- 136 bership Reports to ports on which only hosts are attached. An 137 administrative control may be provided to override this 138 restriction, allowing the report messages to be flooded to 139 other ports. 141 This is the main IGMP snooping functionality. Sending member- 142 ship reports (as described in IGMP versions 1 and 2) to other 143 hosts can result in unintentionally preventing a host from 144 joining a specific multicast group. This is not a problem in 146 RFC DRAFT January 2003 148 an IGMPv3-only network because there is no cancellation of IGMP 149 Membership reports. 151 The administrative control allows IGMP Membership Report mes- 152 sages to be processed by network monitoring equipment such as 153 packet analyzers or port replicators. 155 The switch supporting IGMP snooping must maintain a list of 156 multicast routers and the ports on which they are attached. 157 This list can be constructed in any combination of the follow- 158 ing ways: 160 a) This list should be built by the snooping switch sending 161 Multicast Router Solicitation messages as described in IGMP 162 Multicast Router Discovery [MRDISC]. It may also snoop 163 Multicast Router Advertisement messages sent by and to 164 other nodes. 166 b) The arrival port for IGMP Queries (sent by multicast 167 routers) where the source address is not 0.0.0.0. 169 c) Ports explicitly configured by management to be IGMP-for- 170 warding ports, in addition to or instead of any of the 171 above methods to detect router ports. 173 2) IGMP snooping switches may also implement "proxy-reporting" in 174 which reports received from downstream hosts are summarized and 175 used to build internal membership states as described in 176 [PROXY]. The IGMP proxy-reporting switch would then report its 177 own state in response to upstream queriers. If the switch does 178 not already have an IP address assigned to it, the source 179 address for these reports should be set to all-zeros. 181 An IGMP proxy-reporting switch may act as Querier for the down- 182 stream hosts while proxy reporting to the 'real' upstream 183 queriers. 185 It should be noted that there may be multiple IGMP proxy- 186 reporting switches in the network all using the 0.0.0.0 source 187 IP address. In this case the switches can be uniquely identi- 188 fied through their link layer source MAC address. 190 IGMP membership reports must not be rejected because of a 191 source IP address of 0.0.0.0. 193 3) The switch that supports IGMP snooping must flood all unrecog- 194 nized IGMP messages to all other ports and must not attempt to 195 make use of any information beyond the end of the network layer 197 RFC DRAFT January 2003 199 header. 201 In addition, earlier versions of IGMP should interpret IGMP 202 fields as defined for their versions and must not alter these 203 fields when forwarding the message. When generating new mes- 204 sages, a given IGMP version should set fields to the appropri- 205 ate values for its own version. If any fields are reserved or 206 otherwise undefined for a given IGMP version, the fields should 207 be ignored when parsing the message and must be set to zeroes 208 when new messages are generated by implementations of that IGMP 209 version. 211 4) An IGMP snooping switch should be aware of link layer topology 212 changes. Following a topology change the switch should initi- 213 ate the transmission of a General Query on all ports in order 214 to reduce network convergence time. If the switch is not the 215 Querier, it should use the 'all-zeros' IP Source Address in 216 these proxy queries. When such proxy queries are received, 217 they must not be included in the Querier election process. 219 5) An IGMP snooping switch must not make use of information in 220 IGMP packets where the IP or IGMP headers have checksum or 221 integrity errors. The switch should not flood such packets but 222 if it does, it should take some note of the event (i.e., incre- 223 ment a counter). These errors and their processing are further 224 discussed in [IGMPv3], [MLD] and [MLDv2]. 226 6) The snooping switch must not rely exclusively on IGMP group 227 leave announcements to determine when entries should be removed 228 from the forwarding table. The snooping switch should imple- 229 ment a membership timeout feature to ensure unneeded forwarding 230 table entries will be appropriately removed if downstream mem- 231 bers silently leave the group or become unavailable for any 232 reason. If the switch implements this timeout behavior, it must 233 have a feature to override it if the switch is also configured 234 to forward unregistered multicast packets on all ports. Addi- 235 tionally, if timeout is implemented, a group's forwarding table 236 entry should be removed from a port when no IGMP report has 237 been received for [(Query Interval x Number of Queries) + Query 238 Response Time] seconds. These variables may be learned dynami- 239 cally but IGMP snooping switches implementing timeout should 240 have a configuration option that allows these variables to be 241 set manually. 243 RFC DRAFT January 2003 245 2.1.2. Data Forwarding Rules 247 1) Packets with a destination IP (DIP) address in the 224.0.0.X 248 range which are not IGMP must be forwarded on all ports. 250 This requirement is based on fact that many hosts exist today 251 which do not Join IP multicast addresses in this range before 252 sending or listening to IP multicasts. Furthermore since the 253 224.0.0.X address range is defined as link local (not to be 254 routed) it seems unnecessary to keep state for each address in 255 this range. Additionally, some vendors' applications, which 256 are not IGMP, use this 224.0.0.X address range, and these 257 applications would break if the switch were to prune them due 258 to not seeing a Join. 260 2) Packets with a destination IP address outside 224.0.0.X which 261 are not IGMP should be forwarded according to group-based port 262 membership tables and must also be forwarded on router ports. 264 This is the core IGMP snooping requirement for the data path. 266 Discussion: An implementation could maintain separate member- 267 ship and multicast router tables in software and then "merge" 268 these tables into a current forwarding cache. 270 3) If a switch receives a non-IGMP IPV4 multicast packet without 271 having first processed Membership Reports for the group 272 address, it may forward the packet on all ports, but it must 273 forward the packet on router ports. A switch may forward an 274 unregistered packet only on router ports, but the switch must 275 have a configuration option that suppresses this restrictive 276 operation and forces flooding of unregistered packets on all 277 ports. In environments with v3 hosts where the snooping switch 278 does not support v3, failure to flood unregistered streams 279 could prevent v3 hosts from receiving their traffic. Alterna- 280 tively, in environments where the snooping switch supports all 281 of the IGMP versions that are present, flooding unregistered 282 streams may cause IGMP hosts to be overwhelmed by multicast 283 traffic, even to the point of not receiving Queries and failing 284 to issue new membership reports for their own groups. 286 4) All non-IPv4 multicast packets should be flooded, except where 287 normal IEEE bridging operation would result in filtering multi- 288 cast packets. Discussion: This ensures that enabling IGMP 289 snooping does not break, for example, IPv6 multicast. 291 5) IGMP snooping switches may maintain forwarding tables based on 292 either MAC addresses or IP addresses. If a switch supports 294 RFC DRAFT January 2003 296 both types of forwarding tables then the default behavior 297 should be to use IP addresses. 299 Discussion: Forwarding based on MAC addresses is subject to the 300 problem associated with the 32-fold IP address to 1 MAC address 301 mapping. 303 6) Switches which rely on information in the IP header should ver- 304 ify that the IP header checksum is correct. If the checksum 305 fails, the information in the packet must not be incorporated 306 into the forwarding table. Further, the packet should be dis- 307 carded. 309 7) When IGMPv3 "include source" and "exclude source" membership 310 reports are received on shared segments, the switch needs to 311 forward the superset of all received membership reports onto 312 the shared segment. Forwarding of traffic from a particular 313 source S to a group G must happen if at least one host on the 314 shared segment reports an IGMPv3 membership of the type 315 INCLUDE(G, Slist1) or EXCLUDE(G, Slist2) where S is an element 316 of Slist1 and not an element of Slist2. 318 2.2. IGMP snooping related problems 320 A special problem arises in networks consisting of IGMPv3 routers 321 as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 322 snooping switch. The router will continue to maintain IGMPv3 even 323 in the presence of IGMPv2 hosts, and thus the network will not 324 likely converge on IGMPv2. But it is likely that the IGMPv2 snoop- 325 ing switch will not recognize or process the IGMPv3 membership 326 reports. Groups for these unrecognized reports will then either be 327 flooded (with all of the problems that may create for hosts in a 328 network with a heavy multicast load) or pruned by the snooping 329 switch. 331 Therefore it is recommended that in such a network, the multicast 332 router be configured to use IGMPv2. 334 3. IPv6 Considerations 336 In order to avoid confusion, the previous discussions have been 337 based on the IGMP protocol which only applies to IPv4 multicast. 338 In the case of IPv6 most of the above discussions are still valid 339 with a few exceptions which we will describe here. 341 RFC DRAFT January 2003 343 The control and data forwarding rules in the IGMP section can, with 344 a few considerations, also be applied to MLD. This means that the 345 basic functionality of intercepting MLD packets, and building mem- 346 bership lists and multicast router lists, is the same as for IGMP. 348 In IPv6, the data forwarding rules are more straight forward 349 because MLD is mandated for addresses with scope 2 (link-scope) or 350 greater. The only exception is the address FF02::1 which is the 351 all hosts link-scope address for which MLD messages are never sent. 352 Packets with the all hosts link-scope address should be forwarded 353 on all ports. 355 MLD messages are also not sent to packets in the address range 356 FF0X::/16 when X is 0 or 1 (which are reserved and node-local, 357 respectively), and these addresses should never appear in packets 358 on the link. 360 The three main differences between IPv4 and IPv6 in relation to 361 multicast are: 363 - The IPv6 protocol for multicast group maintenance is called Mul- 364 ticast Listener Discovery (MLDv2). MLDv2 uses ICMPv6 message 365 types instead of IGMP message types. 367 - The ethernet encapsulation is a mapping of 32 bits of the 128 368 bit DIP addresses into 48 bit DMAC addresses [IPENCAPS]. 370 - Multicast router discovery is done using Neighbor Discovery Pro- 371 tocol (NDP) for IPv6. NDP uses ICMPv6 message types. 373 The IPv6 packet header does not include a checksum field. Never- 374 theless, the switch should detect other packet integrity issues. 375 When the snooping switch detects such an error, it must not include 376 information from the corresponding packet in the MLD forwarding ta- 377 ble. The forwarding code should drop the packet and take further 378 reasonable actions as advocated above. 380 The fact that MLDv2 is using ICMPv6 adds new requirements to a 381 snooping switch because ICMPv6 has multiple uses aside from MLD. 382 This means that it is no longer sufficient to detect that the next- 383 header field of the IP header is ICMPv6 in order to identify pack- 384 ets relevant for MLD snooping. 386 Discussion: If an implementation was software-based, wrongly iden- 387 tifying non-MLD packets as candidates for MLD snooping would poten- 388 tially fill the CPU queue with irrelevant packets thus preventing 389 the snooping functionality. Furthermore, ICMPv6 packets destined 390 for other hosts would not reach their destinations. 392 RFC DRAFT January 2003 394 A solution is either to require that the snooping switch looks fur- 395 ther into the packets, or to be able to detect a multicast DMAC 396 address in conjunction with ICMPv6. The first solution is desir- 397 able only if it is configurable which message types should trigger 398 a CPU redirect and which should not. The reason is that a hardcod- 399 ing of message types is inflexible for the introduction of new mes- 400 sage types. The second solution introduces the risk of new proto- 401 cols which use ICMPv6 and multicast DMAC addresses but which are 402 not related to MLD, wrongly being identified as MLD. It is sug- 403 gested that solution one is preferred if the switch is capable of 404 triggering CPU redirects on individual ICMPv6 message types. If 405 this is not the case, then use solution two. 407 The mapping from IP multicast addresses to multicast DMAC addresses 408 introduces a potentially enormous overlap. The structure of an 409 IPv6 multicast address is shown in the figure below. Theoretically 410 2**80, two to the power of 80 (128 - 8 - 4 - 4 - 32) unique DIP 411 addresses could map to one DMAC address. This should be compared 412 to 2**5 in the case of IPv4. 414 Initial allocation of IPv6 multicast addresses, however, uses only 415 the lower 32 bits of group ID. This eliminates the address ambigu- 416 ity for the time being, but it should be noted that the allocation 417 policy may change in the future. Because of the potential overlap 418 it is recommended that IPv6 address based forwarding is preferred 419 to MAC address based forwarding. 421 | 8 | 4 | 4 | 112 bits | 422 +--------+----+----+---------------------------------------+ 423 |11111111|flgs|scop| group ID | 424 +--------+----+----+---------------------------------------+ 426 4. Normative References 428 [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" 430 [IGMPv3] Cain, B., "Internet Group Management Protocol, Version 431 3", RFC3376, October 2002. 433 [IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether- 434 net Networks", RFC2464, December 1998. 436 [MLD] Deering, S., Fenner, B., and Haberman, B. "Multicast 437 Listener Discovery (MLD) for IPv6", RFC2710, October 438 1999. 440 RFC DRAFT January 2003 442 [MLDv2] Vida, R., "Multicast Listener Discovery Version 2 443 (MLDv2) for IPv6", draft-vida-mld-v2-06.txt, November 444 2002. 446 [MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft- 447 ietf-idmr-igmp-mrdisc-10.txt, January 2003. 449 [PROXY] Fenner, B. et al, "IGMP-based Multicast Forwarding 450 (IGMP Proxying)", draft-ietf-magma-igmp-proxy-01.txt, 451 November 2002. 453 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 454 1112, August 1989. 456 [RFC2026] Bradner, S. "The Internet Standards Process -- Revision 457 3", RFC2026, October 1996. 459 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 460 2", RFC2236, November 1997. 462 [RFC2375] Hinden, R. "IPv6 Multicast Address Assignments", 463 RFC2375, July 1998. 465 5. Informative References 467 [IANA] 468 Internet Assigned Numbers Authority, "Internet Multicast 469 Addresses", http://www.isi.edu/in-notes/iana/assignments/mul- 470 ticast-addresses 472 [CISCO] 473 Cisco Tech Notes, "Multicast In a Campus Network: CGMP and 474 IGMP snooping", http://www.cisco.com/warp/public/473/22.html 476 [MSOFT] 477 Microsoft support article Q223136, "Some LAN Switches with 478 IGMP Snooping Stop Forwarding Multicast Packets on RRAS 479 Startup", http://support.microsoft.com/support/kb/arti- 480 cles/Q223/1/36.ASP 482 6. Security Considerations 484 Security considerations for IGMPv3 are accounted for in [IGMPv3]. 485 The introduction of IGMP snooping switches adds the following con- 486 siderations with regard to IP multicast. 488 RFC DRAFT January 2003 490 1) The exclude source failure, which could cause traffic from 491 sources that are 'black listed' to reach hosts that have requested 492 otherwise. This can also occur in certain network topologies with- 493 out IGMP snooping. 495 2) It is possible to generate packets which make the switch wrongly 496 believe that there is a multicast router on the segment on which 497 the source is attached. This will potentially lead to excessive 498 flooding on that segment. The authentication methods discussed in 499 [IGMPv3] will also provide protection in this case. 501 3) IGMP snooping switches which rely on the IP header of a packet 502 for their operation and which do not validate the header checksum 503 potentially will forward packets on the wrong ports. Even though 504 the IP headers are protected by the ethernet checksum this is a 505 potential vulnerability. 507 4) In IGMP, there is no mechanism for denying recipients access to 508 groups (i.e. no "exclude receiver" functionality). Hence, apart 509 from IP-level security configuration outside the scope of IGMP, any 510 multicast stream may be received by any host without restriction. 512 Generally, IGMP snooping must be considered insecure due to the 513 issues above. However, none of the these issues are any worse for 514 IGMP snooping than for IGMP implementations in general. 516 7. IGMP Questionnaire 518 As part of this work the following questions were asked both on the 519 MAGMA discussion list and sent to known switch vendors implementing 520 IGMP snooping. The individual contributions have been anonymized 521 upon request and do not necessarily apply to all of the vendors' 522 products. 524 The questions were: 526 Q1 Does your switches perform IGMP Join aggregation? In other 527 words, are IGMP joins intercepted, absorbed by the hard- 528 ware/software so that only one Join is forwarded to the 529 querier? 531 Q2 Is multicast forwarding based on MAC addresses? Would data- 532 grams addressed to multicast IP addresses 224.1.2.3 and 533 239.129.2.3 be forwarded on the same ports-groups? 535 Q3 Is it possible to forward multicast datagrams based on IP 536 addresses (not routed)? In other words, could 224.1.2.3 and 538 RFC DRAFT January 2003 540 239.129.2.3 be forwarded on different port-groups with unal- 541 tered TTL? 543 Q4 Are multicast datagrams within the range 224.0.0.1 to 544 224.0.0.255 forwarded on all ports whether or not IGMP Joins 545 have been sent? 547 Q5 Are multicast frames within the MAC address range 548 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports 549 whether or not IGMP joins have been sent? 551 Q6 Does your switch support forwarding to ports on which IP multi- 552 cast routers are attached in addition to the ports where IGMP 553 Joins have been received? 555 Q7 Is your IGMP snooping functionality fully implemented in hard- 556 ware? 558 Q8 Is your IGMP snooping functionality partly software imple- 559 mented? 561 Q9 Can topology changes (for example spanning tree configuration 562 changes) be detected by the IGMP snooping functionality so that 563 for example new queries can be sent or tables can be updated to 564 ensure robustness? 566 The answers were: 568 ---------------------------+-----------------------+ 569 | Switch Vendor | 570 ---------------------------+---+---+---+---+---+---+ 571 | 1 | 2 | 3 | 4 | 5 | 6 | 572 ---------------------------+---+---+---+---+---+---+ 573 Q1 Join aggregation | x | x | x | | x | x | 574 Q2 Layer-2 forwarding | x | x | x | x |(1)| | 575 Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x | 576 Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x | 577 Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x | 578 Q6 Mcast router list | x | x | x | x | x | x | 579 Q7 Hardware implemented | | | | | | | 580 Q8 Software assisted | x | x | x | x | x | x | 581 Q9 Topology change aware | x | x | x | x | |(2)| 582 ---------------------------+---+---+---+---+---+---+ 583 x Means that the answer was Yes. 584 (1) In some products (typically high-end) Yes, in others No. 585 (2) Currently no, but will be really soon. 587 RFC DRAFT January 2003 589 8. IETF IPR Statement 591 "The IETF takes no position regarding the validity or scope of any 592 intellectual property or other rights that might be claimed to 593 pertain to the implementation or use of the technology described in 594 this document or the extent to which any license under such rights 595 might or might not be available; neither does it represent that it 596 has made any effort to identify any such rights. Information on 597 the IETF's procedures with respect to rights in standards-track and 598 standards-related documentation can be found in BCP-11. Copies of 599 claims of rights made available for publication and any assurances 600 of licenses to be made available, or the result of an attempt made 601 to obtain a general license or permission for the use of such pro- 602 prietary rights by implementors or users of this specification can 603 be obtained from the IETF Secretariat." 605 9. Acknowledgements 607 We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter, 608 Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward 609 Hilquist, Hugh Holbrook, Kevin Humphries, Suzuki Shinsuke, Jaff 610 Thomas and Rolland Vida for comments and suggestions on this docu- 611 ment. 613 Furthermore, the following companies are acknowledged for their 614 contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, 615 Hewlett-Packard, Vitesse Semiconductor Corporation. The ordering 616 of these names do not correspond to the column numbers in the 617 response table. 619 10. Revision History 621 This section, while incomplete, is provided as a convenience to the 622 working group members. It will be removed when the document is 623 released in its final form. 625 draft-ietf-magma-snoop-05.txt: January 2003 Changes in wording of 626 IGMP forwarding rule 6) and Data forwarding rule 7). Corrections 627 in the references section. 629 RFC DRAFT January 2003 631 Apart from above, no substantial changes has occured in the docu- 632 ment. Several editorial changes, however, have been made to comply 633 with the rfc editors requirements: 635 References splitted in normative and informative sections. 637 Abstract shortened. 639 Changed all occurances of MUST, MAY etc. to lowercase to reflect 640 that this is not a standards track document. 642 Sections moved around so they appear in the required order. 644 draft-ietf-magma-snoop-04.txt: November 2002 Editorial changes 645 only. 647 draft-ietf-magma-snoop-03.txt: October 2002 649 IGMP Forwarding rules: 650 Add references to and become consistant with the current IGMP 651 proxy draft, 653 Unrecognized IGMP packets should not be ignored because "mbz" 654 fields are not zero since packets from future versions are 655 expected to maintain consistency. 657 Corrections related to IGMP Querier election process. 659 Add clarification to how lists of router ports may be assem- 660 bled. 662 Data Forwarding rules: 663 Added discussion of the problems for different IGMP environ- 664 ments in choosing whether to flood or to prune unregistered 665 multicasts. 667 Added refinements for how to handle NON-IPv4 multicasts, to 668 keep IGMP-snooping functionality from interfering with IPv6 669 and other multicast traffic. Any filtering for non-IPv4 mul- 670 ticasts should be based on bridge behavior and not IGMP snoop- 671 ing behavior. 673 IGMP snooping related problems: 674 Fixed description of interoperability issues in environments 675 with v3 routers and hosts, and v2 snooping switches. 677 Added discussion of the IGMPv3 "include source" and "exclude 678 source" options, and the inability to support them on shared 680 RFC DRAFT January 2003 682 segments. 684 IPv6 Considerations: 685 Clarifications regarding address ranges FF00::, FF01:: and all 686 hosts FF02::1 in relation to data forwarding. 688 draft-ietf-magma-snoop-02.txt: June 2002 690 Status section removes document history; moved into this sec- 691 tion instead. 693 Introduction restores text from the -00 revision that 694 describes snooping and its goals 696 IGMP flooding rules eased, allowing management option to 697 broaden beyond "routers only". 699 Removed a should/MAY inconsistancy between IPv4 Forwarding and 700 IPv6 processing of checksums. 702 IGMP Forwarding Rules: clarify text describing processing of 703 non-zero reserved fields. 705 Data Forwarding Rules, item 3 is changed from "MUST forward to 706 all ports" to "MAY"; item 4 default changes from "MUST" to 707 "should use network addresses". 709 Added two sets of additional responses to the questionnaire 710 and text indicating that responses don't cover all products. 712 Removed (commented out) description of IPR issues: IESG is 713 aware of them. 715 draft-ietf-magma-snoop-01.txt: January 2002 717 Extensive restructuring of the original text. 719 draft-ietf-idmr-snoop-01.txt: 2001 721 Added several descriptions of cases where IGMP snooping imple- 722 mentations face problems. Also added several network topology 723 figures. 725 draft-ietf-idmr-snoop-00.txt: 2001 727 Initial snooping draft. An overview of IGMP snooping and the 729 RFC DRAFT January 2003 731 problems to be solved. 733 11. Author's Addresses 735 Morten Jagd Christensen 736 Thrane & Thrane 737 Lundtoftegaardsvej 93 D 738 2800 Lyngby 739 email: mjc@tt.dk 741 Karen Kimball 742 Hewlett-Packard 743 8000 Foothills Blvd. 744 Roseville, CA 95747 745 email: karen.kimball@hp.com 747 Frank Solensky 748 Bluejavelin, Inc. 749 3 Dundee Park 750 Andover, MA 01810 751 email: fsolensky@bluejavelin.net 753 RFC DRAFT January 2003 755 Table of Contents 757 1. Introduction . . . . . . . . . . . . . . . . . . . . . 2 758 2. IGMP Snooping Requirements . . . . . . . . . . . . . . 3 759 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . 3 760 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . 3 761 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . 6 762 2.2. IGMP snooping related problems . . . . . . . . . . . 7 763 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . 7 764 4. Normative References . . . . . . . . . . . . . . . . . 9 765 5. Informative References . . . . . . . . . . . . . . . . 10 766 6. Security Considerations . . . . . . . . . . . . . . . . 10 767 7. IGMP Questionnaire . . . . . . . . . . . . . . . . . . 11 768 8. IETF IPR Statement . . . . . . . . . . . . . . . . . . 13 769 9. Acknowledgements . . . . . . . . . . . . . . . . . . . 13 770 10. Revision History . . . . . . . . . . . . . . . . . . . 13 771 11. Author's Addresses . . . . . . . . . . . . . . . . . . 16