idnits 2.17.00 (12 Aug 2021) /tmp/idnits50351/draft-ietf-magma-snoop-02.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 seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 55 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' Introduction restores text from the -00 revision that' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 6 instances of too long lines in the document, the longest one being 26 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. ** The abstract seems to contain references ([MLD], [PROXY], [RFC2026], [RFC1112], [RFC2236], [IPENCAPS], [IGMPv3], [MLDv2], [MRDISC], [MSOFT], [IANA], [RFC2375], [CISCO], [RFC112], [BRIDGE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 122: '... snooping switch SHOULD forward IGMP M...' RFC 2119 keyword, line 124: '... snooping switch SHOULD NOT forward IG...' RFC 2119 keyword, line 126: '...strative control MAY be provided to ov...' RFC 2119 keyword, line 141: '...ng IGMP snooping MUST maintain a list ...' RFC 2119 keyword, line 146: '... a) This list SHOULD be built using...' (27 more instances...) 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2026' on line 469 looks like a reference -- Missing reference section? 'IGMPv3' on line 442 looks like a reference -- Missing reference section? 'BRIDGE' on line 432 looks like a reference -- Missing reference section? 'RFC112' on line 96 looks like a reference -- Missing reference section? 'RFC2236' on line 472 looks like a reference -- Missing reference section? 'CISCO' on line 434 looks like a reference -- Missing reference section? 'MSOFT' on line 458 looks like a reference -- Missing reference section? 'MRDISC' on line 455 looks like a reference -- Missing reference section? 'PROXY' on line 463 looks like a reference -- Missing reference section? 'MLD' on line 448 looks like a reference -- Missing reference section? 'MLDv2' on line 452 looks like a reference -- Missing reference section? 'IPENCAPS' on line 445 looks like a reference -- Missing reference section? 'RFC2375' on line 475 looks like a reference -- Missing reference section? 'IANA' on line 438 looks like a reference -- Missing reference section? 'RFC1112' on line 466 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MAGMA Working Group M. Christensen 3 Internet Draft morten@jagd-christensen.com 4 June 2002 F. Solensky 5 Expiration Date: December 2002 Premonitia 7 IGMP and MLD snooping switches 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [RFC2026]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other docu¡ 22 ments at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo describes the requirements for IGMP and MLD snooping 35 switches. The requirements for IGMPv2 snooping switches are based 36 on best current practices. IGMPv3 and MLDv2 snooping are also cov¡ 37 ered in this draft although we are not aware of any such implemen¡ 38 tations at the time of writing. Areas which are of relevance to 39 IGMP and MLD snooping switches, such as link layer topology changes 40 and Ethernet specific encapsulation issues are also considered. 42 Interoperability issues that arise betweed different versions of 43 IGMP are not discussed in this document. Interested readers are 44 directed to [IGMPv3] for a thorough description of problem area. 46 This document is intended as an accompanying document to the IGMPv3 47 and MLDv2 specifications. 49 11.. IInnttrroodduuccttiioonn 51 When a packet with a broadcast or multicast destination address is 52 received, the switch will forward a copy into each of the remaining 53 network segments in accordance with [BRIDGE]. Eventually, the 54 packet is made accessible to all nodes connected to the network. 56 This approach works well for broadcast packets that are intended to 57 be seen or processed by all connected nodes. In the case of multi¡ 58 cast packets, however, this approach could lead to less efficient 59 use of network bandwidth, particularly when the packet is intended 60 for only a small number of nodes. Packets will be flooded into 61 network segments where no node has any interest in receiving the 62 packet. While nodes will rarely incur any processing overhead to 63 filter packets addressed to unrequested group addresses, they are 64 unable to transmit new packets onto the shared media for the period 65 of time that the multicast packet is flooded. 67 The problem of wasting bandwidth is even worse when the LAN segment 68 is not shared, for example in Full Duplex links. Full Duplex is 69 standard today for most switches operating at 1Gbps or above. In 70 this case the bandwidth that is wasted is proportional to the num¡ 71 ber of attached nodes. 73 In recent years, a number of commercial vendors have introduced 74 products described as "IGMP snooping switches" to the market. 75 These devices do not adhere to the conceptual model that provides 76 the strict separation of functionality between different communica¡ 77 tions layers in the ISO model and instead utilizes information in 78 the upper level protocol headers as factors to be considered in the 79 processing at the lower levels. This is analogous to the manner in 80 which a router can act as a firewall by looking into the transport 81 protocol's header before allowing a packet to be forwarded to its 82 destination address. 84 In the case of multicast traffic, an IGMP snooping switch provides 85 the benefit of conserving bandwidth on those segments of the net¡ 86 work where no node has expressed interest in receiving packets 87 addressed to the group address. This is in contrast to normal 88 switch behaviour where multicast traffic is typically forwarded on 89 all interfaces. 91 Many switch datasheets state support for IGMP snooping, but no 92 requirements for this exist today. It is the authors hope that the 93 information presented in this draft will supply this information. 95 The requirements presented here is based on the following informa¡ 96 tion sources: The IGMP specifications [RFC112][RFC2236][IGMPv3], 97 vendor supplied technical documents [CISCO], bug reports [MSOFT], 98 discussions with people invovled in design of IGMP snooping 99 switches, MAGMA mailinglist discussions, and on replies by switch 100 vendors to an implementation questionnaire. 102 The discussions in this document are based on IGMP which applies to 103 IPv4 only. For IPv6 we must use MLD instead. Because MLD is based 104 on IGMP we do not repeat the whole discussion and requirements for 105 MLD snooping switches. Instead we point out the few cases where 106 there is a difference compared to IGMP. 108 22.. IIGGMMPP SSnnooooppiinngg RReeqquuiirreemmeennttss 110 The following sections list the requirements for an IGMP snooping 111 switch. The requirement is stated and is supplemented by a discus¡ 112 sion. All implementation discussions are examples only and there 113 may well be other ways to achieve the same functionality. 115 22..11.. FFoorrwwaarrddiinngg rruulleess 117 The IGMP snooping functionality is here separated in a control sec¡ 118 tion (IGMP forwarding) and data section (Data forwarding). 120 22..11..11.. IIGGMMPP FFoorrwwaarrddiinngg RRuulleess 122 1) A snooping switch SHOULD forward IGMP Membership Reports only 123 to those ports where multicast routers are attached. Alterna¡ 124 tively stated: A snooping switch SHOULD NOT forward IGMP Mem¡ 125 bership Reports to ports on which only hosts are attached. An 126 administrative control MAY be provided to override this 127 restriction, allowing the report messages to be flooded to 128 other ports. 130 This is the main IGMP snooping functionality. Sending member¡ 131 ship reports (as described in IGMP versions 1 and 2) to other 132 hosts can result in unintentionally preventing a host from 133 joining a specific multicast group. This is not a problem in 134 an IGMPv3 only network because there is no cancellation of IGMP 135 Membership reports. 137 The administrative control allows IGMP Membership Report mes¡ 138 sages to be processed by network monitoring equipment such as 139 packet analysers or port replicators. 141 The switch supporting IGMP snooping MUST maintain a list of 142 multicast routers and the ports on which they are attached. 143 This list can be constructed in any combination of the follow¡ 144 ing ways: 146 a) This list SHOULD be built using IGMP Multicast Router Dis¡ 147 covery [MRDISC] by the snooping switch sending Multicast 148 Router Solicitation messages on its own. It MAY also snoop 149 Multicast Router Advertisement messages sent by and to 150 other nodes. 152 b) The arrival port for IGMP Queries (sent by multicast 153 routers) where the source where the address is not 0.0.0.0. 155 c) A list of ports configured by management as described in 156 the previous step. 158 2) IGMP snooping switches MAY implement "proxy-reporting" in which 159 reports received from downstream hosts are summarized and used 160 to build internal membership states as described in [PROXY]. 161 An IGMP proxy-reporting switch would then report its own state 162 in response to upstream queriers. If the switch does not 163 alreay have an IP address it SHOULD use the address 0.0.0.0 as 164 source in these reports. 166 An IGMP proxy-reporting switch may act as Querier for the down¡ 167 stream hosts while proxy reporting to the 'real' upstream 168 queriers. 170 It should be noted that there may be multiple IGMP proxy- 171 reporting switches in the network all using the 0.0.0.0 source 172 IP address. In this case the switches can be uniquely identi¡ 173 fied through their link layer source MAC address. 175 IGMP membership reports MUST NOT be rejected because of a 176 source IP address of 0.0.0.0; however, these messages MUST NOT 177 be included the election process so that a snooping switch does 178 not elected over an active router. 180 3) The switch that supports IGMP snooping MUST flood all unrecog¡ 181 nized IGMP messages to all other ports and MUST NOT attempt to 182 make use of any information beyond the end of the network layer 183 header. In particular, messages where any reserved fields in 184 the IGMP header are non-zero MUST NOT be subject to "normal" 185 snooping since this could indicate an incompatible change to 186 the IGMP message format. 188 4) An IGMP snooping switch SHOULD be aware of link layer topology 189 changes. Following a topology change the switch SHOULD initi¡ 190 ate the transmission of a General Query on all ports in order 191 to reduce network convergence time. 193 5) An IGMP snooping switch MUST NOT make use of information in 194 IGMP packets where the IP or IGMP headers have checksum or 195 intregity errors. The switch SHOULD NOT flood such packets but 196 if it does, it SHOULD take some note of the event (i.e.: incre¡ 197 ment a counter). These errors and their processing are further 198 discussed in [IGMPv3], [MLD] and [MLDv2]. 200 22..11..22.. DDaattaa FFoorrwwaarrddiinngg RRuulleess 202 1) Packets with a destination IP (DIP) address in the 224.0.0.X 203 range which are not IGMP MUST be forwarded on all ports. 205 This requirement is based on fact that many hosts exist today, 206 which does not Join IP multicast addresses in this range before 207 sending or listening to IP multicast. Furthermore since the 208 224.0.0.X address range is defined as link local (not to be 209 routed) it seems unnecessary to keep state for each address in 210 this range. 212 2) Packets with a destination IP address outside 224.0.0.X which 213 are not IGMP SHOULD be forwarded according to group based port 214 membership tables and MUST also be forwarded on router ports. 216 This is the core IGMP snooping requirement for the data path. 218 Discussion: An implementation could maintain separate member¡ 219 ship and multicast router tables in software and then "merge" 220 these tables into a current forwarding cache. 222 3) If a switch receives a non-IGMP multicast packet without having 223 first processed Membership Reports for the group address, it 224 MAY forward the packet on all ports, but it MUST forward the 225 packet on router ports. A switch MAY forward an unregistered 226 packet only on router ports, but the switch MUST have a config¡ 227 uration option that suppresses this restrictive operation and 228 forces flooding of unregistered packets on all ports. 230 4) IGMP snooping switches MAY maintain forwarding tables based on 231 either MAC addresses or IP addresses. If a switch supports 232 both types of forwarding tables then the default behavior 233 SHOULD be to use IP addresses. 235 Discussion: Forwarding based on MAC addresses is subject to the 236 problem associated with the 32-fold IP address to 1 MAC address 237 mapping. 239 5) Switches which rely on information in the IP header SHOULD ver¡ 240 ify that the IP header checksum is correct. If the checksum 241 fails, the information in the packet MUST NOT be incorporated 242 into the forwarding table. Further, the packet SHOULD be dis¡ 243 carded. 245 22..22.. IIGGMMPP ssnnooooppiinngg rreellaatteedd pprroobblleemmss 247 A special problem arise in the network consisting of IGMPv3 routers 248 as well as IGMPv2 and IGMPv3 hosts interconnected by a IGMPv2 249 snooping switch. IGMPv3 has a mechanism to fall back to IGMPv2 250 when receiving IGMPv2 membership reports. This means that the net¡ 251 work will converged on IGMPv2 eventually. However, the convergence 252 time will lead to supression of v3 Hosts for several minutes. 254 Therefore it is recommended that in such a network, the multicast 255 router is configured to use IGMPv2. 257 33.. IIPPvv66 CCoonnssiiddeerraattiioonnss 259 In order to avoid confusion, the previous discussions have been 260 based on IGMPv3 functionality which only applies to IPv4 multicast. 261 In the case of IPv6 most of the above discussions are still valid 262 with a few exceptions which we will describe here. 264 In IPv6 the protocol for multicast group maintenance is called Mul¡ 265 ticast Listener Discovery (MLDv2). IPv6 is not widely deployed 266 today and neither is IPv6 multicast. However, it is anticipated 267 that at some time IPv6 switches capable of MLD snooping will 268 appear. 270 The three main differences between IGMPv3 and MLDv2 are: 272 - MLDv2 uses ICMPv6 message types instead of IGMP message types. 274 - The ethernet encapsulation is a mapping of 32 bits of the 128 275 bit DIP addresses into 48 bit DMAC addresses [IPENCAPS]. 277 - Multicast router discovery is done using Neighbor Discovery Pro¡ 278 tocol (NDP) for IPv6. NDP uses ICMPv6 message types. 280 The IPv6 packet header does not include a checksum field. Never¡ 281 theless, the switch SHOULD detect other packet integrity issues. 282 When the snooping switch detects such an error, it MUST NOT include 283 information from the corresponding packet in the IGMP forwarding 284 table. The forwarding code SHOULD drop the packet and take further 285 reasonable actions as advocated above. 287 The fact that MLDv2 is using ICMPv6 adds new requirements to a 288 snooping switch because ICMPv6 has multiple uses aside from MLD. 289 This means that it is no longer sufficient to detect that the next- 290 header field of the IP header is ICMPv6 in order to redirect pack¡ 291 ets to the CPU. If this was the case the CPU queue assigned for 292 MLD would potentially be filled with non-MLD related packets. Fur¡ 293 thermore ICMPv6 packets destined for other hosts would not reach 294 their destination. A solution is either to require that the snoop¡ 295 ing switch looks further into the packets or to be able to detect a 296 multicast DMAC address in conjunction with ICMPv6. The first solu¡ 297 tion is desirable only if it is configurable which message types 298 should trigger a CPU redirect and which should not. The reason is 299 that a hardcoding of message types is unflexible for the introduc¡ 300 tion of new message types. The second solution introduces the risk 301 of new protocols, which are not related to MLD but uses ICMPv6 and 302 multicast DMAC addresses wrongly being identified as MLD. It is 303 suggested that solution one is the preferred if the switch is capa¡ 304 ble of triggering CPU redirects on individual ICMPv6 message types. 305 If this is not the case then use solution two. 307 The mapping from IP multicast addresses to multicast DMAC addresses 308 introduces a potentially enormous overlap. The structure of an IPv6 309 multicast address is shown in figure 5. Theoretically 2**80, two 310 to the power of 80 (128 - 8 - 4 - 4 - 32) unique DIP addresses 311 could map to one DMAC address. This should be compared to 2**5 in 312 the case of IPv4. 314 Initial allocation of IPv6 multicast addresses, however, uses only 315 the lower 32 bits of group ID. This eliminates the address ambigu¡ 316 ity for the time being but it should be noted that the allocation 317 policy may change in the future. 319 | 8 | 4 | 4 | 112 bits | 320 +--------+----+----+---------------------------------------+ 321 |11111111|flgs|scop| group ID | 322 +--------+----+----+---------------------------------------+ 323 Figure 5 325 In the case of IPv6 forwarding can be made on the basis of DMAC 326 addresses in the forseable future. 328 Finally, we mention the reserved address range FF02::/96. This 329 range is similar to 224.0.0.X for IPv4 and is reserved to routing 330 protocols and resource discovery [RFC2375]. In the case of IPv6 it 331 is suggested that packets in this range are forwarded on all ports 332 if they are not MLD packets. 334 44.. SSeeccuurriittyy CCoonnssiiddeerraattiioonnss 336 Security considerations for IGMPv3 are accounted for in [IGMPv3]. 337 The introduction of IGMP snooping switches adds the following con¡ 338 siderations with regard to IP multicast. 340 The exclude source failure which could cause traffic from sources 341 that are 'black listed' to reach hosts that have requested other¡ 342 wise. This can also occur in certain network topologies without 343 IGMP snooping. 345 It is possible to generate packets which make the switch wrongly 346 believe that there is a multicast router on the segment on which 347 the source is attached. This will potentially lead to excessive 348 flooding on that segment. The authentication methods discussed in 349 [IGMPv3] will also provide protection in this case. 351 IGMP snooping switches which rely on the IP header of a packet for 352 their operation and which do not validate the header checksum 353 potentially will forward packets on the wrong ports. Even though 354 the IP headers are protected by the ethernet checksum this is a 355 potential vulnerability. 357 Generally though, it is worth to stress that IP multicast must so 358 far be considered insecure until the work of for example the sug¡ 359 gested Multicast Security (MSEC) working group or similar is com¡ 360 pleted or at least has matured. 362 55.. IIGGMMPP QQuueessttiioonnnnaaiirree 364 As part of this work the following questions were asked both on the 365 MAGMA discussion list and sent to known switch vendors implementing 366 IGMP snooping. The individual contributions have been anonymized 367 upon request and do not necessarily apply to all of the vendors' 368 products. 370 The questions were: 372 Q1 Does your switches perform IGMP Join aggregation? In other 373 words, are IGMP joins intercepted, absorbed by the hard¡ 374 ware/software so that only one Join is forwarded to the 375 querier? 377 Q2 Is multicast forwarding based on MAC addresses? Would data¡ 378 grams addressed to multicast IP addresses 224.1.2.3 and 379 239.129.2.3 be forwarded on the same ports-groups? 381 Q3 Is it possible to forward multicast datagrams based on IP 382 addresses (not routed). In other words, could 224.1.2.3 and 383 239.129.2.3 be forwarded on different port-groups with unal¡ 384 tered TTL? 386 Q4 Are multicast datagrams within the range 224.0.0.1 to 387 224.0.0.255 forwarded on all ports whether or not IGMP Joins 388 have been sent? 390 Q5 Are multicast frames within the MAC address range 391 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports 392 whether or not IGMP joins have been sent? 394 Q6 Does your switch support forwarding to ports on which IP multi¡ 395 cast routers are attached in addition to the ports where IGMP 396 Joins have been received? 398 Q7 Is your IGMP snooping functionality fully implemented in hard¡ 399 ware? 401 Q8 Is your IGMP snooping functionality partly software imple¡ 402 mented? 404 Q9 Can topology changes (for example spanning tree configuration 405 changes) be detected by the IGMP snooping functionality so that 406 for example new queries can be sent or tables can be updated to 407 ensure robustness? 409 The answers were: 411 ---------------------------+-----------------------+ 412 | Switch Vendor | 413 ---------------------------+---+---+---+---+---+---+ 414 | 1 | 2 | 3 | 4 | 5 | 6 | 415 ---------------------------+---+---+---+---+---+---+ 416 Q1 Join aggregation | x | x | x | | x | x | 417 Q2 Layer-2 forwarding | x | x | x | x |(1)| | 418 Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x | 419 Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x | 420 Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x | 421 Q6 Mcast router list | x | x | x | x | x | x | 422 Q7 Hardware implemented | | | | | | | 423 Q8 Software assisted | x | x | x | x | x | x | 424 Q9 Topology change aware | x | x | x | x | |(2)| 425 ---------------------------+---+---+---+---+---+---+ 426 x Means that the answer was Yes. 427 (1) In some products (typically high-end) Yes, in others No. 428 (2) Currently no, but will be real soon. 430 66.. RReeffeerreenncceess 432 [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" 434 [CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP 435 and IGMP snooping", http://www.cisco.com/warp/pub¡ 436 lic/473/22.html 438 [IANA] Internet Assigned Numbers Authority, "Internet Multicast 439 Addresses", http://www.isi.edu/in-notes/iana/assign¡ 440 ments/multicast-addresses 442 [IGMPv3] Cain, B., "Internet Group Management Protocol, Version 443 3", draft-ietf-idmr-igmp-v3-11.txt, May 2002. 445 [IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether¡ 446 net Networks", RFC2464, December 1998. 448 [MLD] Deering, S., Fenner, B., and Haberman, B. "Multicast 449 Listener Discovery (MLD) for IPv6", RFC2710, October 450 1999. 452 [MLDv2] Vida, R., "Multicast Listener Discovery Version 2 453 (MLDv2) for IPv6", draft-vida-mld-v2-03.txt, June 2002. 455 [MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft- 456 ietf-idmr-igmp-mrdisc-08.txt, January 2002. 458 [MSOFT] Microsoft support article Q223136, "Some LAN Switches 459 with IGMP Snooping Stop Forwarding Multicast Packets on 460 RRAS Startup", http://support.microsoft.com/sup¡ 461 port/kb/articles/Q223/1/36.ASP 463 [PROXY] Fenner, B. et al, "IGMP-based Multicast Forwarding (IGMP 464 Proxying)", draft-ietf-magma-proxy-02(?).txt. 466 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 467 1112, August 1989. 469 [RFC2026] Bradner, S. "The Internet Standards Process -- Revision 470 3", RFC2026, October 1996. 472 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 473 2", RFC2236, November 1997. 475 [RFC2375] Hinden, R. "IPv6 Multicast Address Assignments", 476 RFC2375, July 1998. 478 77.. AAcckknnoowwlleeddggeemmeennttss 480 We would like to thank Martin Bak, Les Bell, Yiqun Cai, Paul Cong¡ 481 don, Toerless Eckert, Bill Fenner, Brian Haberman, Edward Hilquist, 482 Hugh Holbrook, Kevin Humphries, Karen Kimball and Jaff Thomas for 483 comments and suggestions on this document. 485 Furthermore, the following companies are acknowledged for their 486 contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, 487 Hewlett-Packard, Vitesse Semiconductor Corporation. The ordering 488 of these names do not necessarily correspond to the column numbers 489 in the response table. 491 88.. RReevviissiioonn HHiissttoorryy 493 This section, while incomplete, is provided as a convenience to the 494 working group members. It will be removed when the document is 495 released in its final form. 497 draft-ietf-magma-snoop-01.txt: January 2002 499 Extensive restructuring of the original text. 501 draft-ietf-magma-snoop-02.txt: June 2002 503 Status section removes document history; moved into this sec¡ 504 tion instead. 506 Introduction restores text from the -00 revision that 507 describes snooping and its goals 509 IGMP flooding rules eased, allowing management option to 510 broaden beyond "routers only". 512 Removed a SHOULD/MAY inconsistancy between IPv4 Forwarding and 513 IPv6 processing of checksums. 515 IGMP Forwarding Rules: clarify text describing processing of 516 non-zero reserved fields. 518 Data Forwarding Rules, item 3 is changed from "MUST forward to 519 all ports" to "MAY"; item 4 default changes from "MUST" to 520 "SHOULD use network addresses". 522 Added two sets of additional responses to the questionnaire 523 and text indicating that responses don't cover all products. 525 Removed (commented out) description of IPR issues: IESG is 526 aware of them. 528 The next revision: 530 In the interest of getting this version of the draft released 531 before the deadline (less than seven hours from the moment 532 this paragraph is being typed), we briefly summarize some of 533 the comments on the previous version that need to be included 534 in the next one. We believe that other comments have been 535 addressed in this draft; please let the authors know if this 536 they have either not been included or need to be corrected. 538 IGMP Forwarding rules: 540 Add a reference to and become consistant with the next 541 revision of the IGMP proxy draft, 543 In item 'b': include a description on how the switch 544 determines that a Query came from the router and not 545 another switch. Is there some way to make this distinc¡ 546 tion beyond the source address? 548 Proxy reporting: further analysis of the impact on the 549 election process when using 0.0.0.0 as the source address 550 in membership report messages. Also consider the case 551 where the switch assumes the role of Querier when no 552 routers are detected and forfeits the role as soon as one 553 is announced. 555 Include some discussion about how entries are to be aged 556 from the list, perhaps similar to spanning tree algorithm 557 for unicast MAC address processing. 559 Data Forwarding rules: 561 Link-local range to mention the problem is due to routing 562 protocols not sending Report Messages for their respec¡ 563 tive multicast addresses. 565 Expand discussion of non-IGMP packet forwarding for data 566 that matches an IGMPv3 record. Do snooping switches add 567 intelligence to recognize SSM versus ASM groups? 569 IPv6 Considerations: 571 Is having MLD a subset of ICMPv6 an issue? Should MLDv2 572 be a separate protocol? 574 Add reference to ICMPv6 specification for message pro¡ 575 cessing rules. 577 99.. AAuutthhoorr''ss AAddddrreesssseess 579 Morten Jagd Christensen 580 email: morten@jagd-christensen.com 582 Frank Solensky 583 Premonitia, Inc. 584 1 Nanog Park 585 Acton, MA 01720 586 email: fsolensky@premonitia.com 587 TTaabbllee ooff CCoonntteennttss 589 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 590 2. IGMP Snooping Requirements . . . . . . . . . . . . . . . . . 3 591 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3 592 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 3 593 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 5 594 2.2. IGMP snooping related problems . . . . . . . . . . . . . . 6 595 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 6 596 4. Security Considerations . . . . . . . . . . . . . . . . . . 8 597 5. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 8 598 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 599 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 600 8. Revision History . . . . . . . . . . . . . . . . . . . . . . 11 601 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 13