idnits 2.17.00 (12 Aug 2021) /tmp/idnits51238/draft-ietf-magma-snoop-04.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? == 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 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 135: '... snooping switch SHOULD forward IGMP M...' RFC 2119 keyword, line 137: '... snooping switch SHOULD NOT forward IG...' RFC 2119 keyword, line 139: '...strative control MAY be provided to ov...' RFC 2119 keyword, line 157: '...ng IGMP snooping MUST maintain a list ...' RFC 2119 keyword, line 162: '... a) This list SHOULD be built by th...' (33 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: 'RFC112' is mentioned on line 109, but not defined == Unused Reference: 'IANA' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'RFC1112' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC2375' is defined on line 589, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BRIDGE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CISCO' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' == Outdated reference: draft-ietf-idmr-igmp-v3 has been published as RFC 3376 == Outdated reference: draft-vida-mld-v2 has been published as RFC 3810 == Outdated reference: A later version (-10) exists of draft-ietf-idmr-igmp-mrdisc-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'MSOFT' == Outdated reference: draft-ietf-magma-igmp-proxy has been published as RFC 4605 ** Downref: Normative reference to an Informational RFC: RFC 2375 Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MAGMA Working Group M. Christensen 3 Internet Draft mjc@jcaps.com 4 November 2002 K. Kimball 5 Expiration Date: May 2003 Hewlett-Packard 6 F. Solensky 7 Bluejavelin 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 docu- 24 ments at any time. It is inappropriate to use Internet-Drafts as 25 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 Abstract 36 This memo describes the requirements for IGMP and MLD snooping 37 switches. The requirements for IGMPv2 snooping switches are based 38 on best current practices. IGMPv3 and MLDv2 snooping are also cov- 39 ered in this draft although we are not aware of any such implemen- 40 tations at the time of writing. 42 Note that IGMP snooping is related only to IPv4 multicast. Other 43 multicast packets, such as IPv6, might be suppressed by the snoop- 44 ing functionality if additional care is not taken in the implemen- 45 tation. It is desired not to restrict the flow of non-IPv4 multi- 46 casts other than to the degree which would happen as a result of 47 regular bridging functions. The same note can be made of MLD 49 RFC DRAFT October 2002 51 snooping switches with respect to suppression of IPv4. 53 Areas which are of relevance to IGMP and MLD snooping switches, 54 such as link layer topology changes and Ethernet specific encapsu- 55 lation issues, are also considered. 57 Interoperability issues that arise between different versions of 58 IGMP are not discussed in this document. Interested readers are 59 directed to [IGMPv3] for a thorough description of problem areas. 61 This document is intended as an accompanying document to the IGMPv3 62 and MLDv2 specifications. 64 1. Introduction 66 When a packet with a broadcast or multicast destination address is 67 received, the switch will forward a copy into each of the remaining 68 network segments in accordance with [BRIDGE]. Eventually, the 69 packet is made accessible to all nodes connected to the network. 71 This approach works well for broadcast packets that are intended to 72 be seen or processed by all connected nodes. In the case of multi- 73 cast packets, however, this approach could lead to less efficient 74 use of network bandwidth, particularly when the packet is intended 75 for only a small number of nodes. Packets will be flooded into 76 network segments where no node has any interest in receiving the 77 packet. While nodes will rarely incur any processing overhead to 78 filter packets addressed to unrequested group addresses, they are 79 unable to transmit new packets onto the shared media for the period 80 of time that the multicast packet is flooded. In general, signifi- 81 cant bandwidth can be wasted by flooding. 83 In recent years, a number of commercial vendors have introduced 84 products described as "IGMP snooping switches" to the market. 85 These devices do not adhere to the conceptual model that provides 86 the strict separation of functionality between different communica- 87 tions layers in the ISO model, and instead utilize information in 88 the upper- level protocol headers as factors to be considered in 89 the processing at the lower levels. This is analogous to the man- 90 ner in which a router can act as a firewall by looking into the 91 transport protocol's header before allowing a packet to be for- 92 warded to its destination address. 94 In the case of multicast traffic, an IGMP snooping switch provides 95 the benefit of conserving bandwidth on those segments of the net- 96 work where no node has expressed interest in receiving packets 97 addressed to the group address. This is in contrast to normal 99 RFC DRAFT October 2002 101 switch behavior where multicast traffic is typically forwarded on 102 all interfaces. 104 Many switch datasheets state support for IGMP snooping, but no 105 requirements for this exist today. It is the authors' hope that the 106 information presented in this draft will supply this foundation. 108 The requirements presented here are based on the following informa- 109 tion sources: The IGMP specifications [RFC112][RFC2236][IGMPv3], 110 vendor-supplied technical documents [CISCO], bug reports [MSOFT], 111 discussions with people involved in the design of IGMP snooping 112 switches, MAGMA mailinglist discussions, and on replies by switch 113 vendors to an implementation questionnaire. 115 The discussions in this document are based on IGMP which applies to 116 IPv4 only. For IPv6 we must use MLD instead. Because MLD is based 117 on IGMP we do not repeat the whole discussion and requirements for 118 MLD snooping switches. Instead we point out the few cases where 119 there is a difference compared to IGMP. 121 2. IGMP Snooping Requirements 123 The following sections list the requirements for an IGMP snooping 124 switch. The requirement is stated and is supplemented by a discus- 125 sion. All implementation discussions are examples only and there 126 may well be other ways to achieve the same functionality. 128 2.1. Forwarding rules 130 The IGMP snooping functionality is here separated into a control 131 section (IGMP forwarding) and a data section (Data forwarding). 133 2.1.1. IGMP Forwarding Rules 135 1) A snooping switch SHOULD forward IGMP Membership Reports only 136 to those ports where multicast routers are attached. Alterna- 137 tively stated: a snooping switch SHOULD NOT forward IGMP Mem- 138 bership Reports to ports on which only hosts are attached. An 139 administrative control MAY be provided to override this 140 restriction, allowing the report messages to be flooded to 141 other ports. 143 This is the main IGMP snooping functionality. Sending member- 144 ship reports (as described in IGMP versions 1 and 2) to other 145 hosts can result in unintentionally preventing a host from 147 RFC DRAFT October 2002 149 joining a specific multicast group. This is not a problem in 150 an IGMPv3-only network because there is no cancellation of IGMP 151 Membership reports. 153 The administrative control allows IGMP Membership Report mes- 154 sages to be processed by network monitoring equipment such as 155 packet analyzers or port replicators. 157 The switch supporting IGMP snooping MUST maintain a list of 158 multicast routers and the ports on which they are attached. 159 This list can be constructed in any combination of the follow- 160 ing ways: 162 a) This list SHOULD be built by the snooping switch sending 163 Multicast Router Solicitation messages as described in IGMP 164 Multicast Router Discovery [MRDISC]. It MAY also snoop 165 Multicast Router Advertisement messages sent by and to 166 other nodes. 168 b) The arrival port for IGMP Queries (sent by multicast 169 routers) where the source address is not 0.0.0.0. 171 c) Ports explicitly configured by management to be IGMP-for- 172 warding ports, in addition to or instead of any of the 173 above methods to detect router ports. 175 2) IGMP snooping switches MAY also implement "proxy-reporting" in 176 which reports received from downstream hosts are summarized and 177 used to build internal membership states as described in 178 [PROXY]. The IGMP proxy-reporting switch would then report its 179 own state in response to upstream queriers. If the switch does 180 not already have an IP address assigned to it, the source 181 address for these reports SHOULD be set to all-zeros. 183 An IGMP proxy-reporting switch may act as Querier for the down- 184 stream hosts while proxy reporting to the 'real' upstream 185 queriers. 187 It should be noted that there may be multiple IGMP proxy- 188 reporting switches in the network all using the 0.0.0.0 source 189 IP address. In this case the switches can be uniquely identi- 190 fied through their link layer source MAC address. 192 IGMP membership reports MUST NOT be rejected because of a 193 source IP address of 0.0.0.0. 195 3) The switch that supports IGMP snooping MUST flood all unrecog- 196 nized IGMP messages to all other ports and MUST NOT attempt to 198 RFC DRAFT October 2002 200 make use of any information beyond the end of the network layer 201 header. 203 In addition, earlier versions of IGMP SHOULD interpret IGMP 204 fields as defined for their versions and MUST NOT alter these 205 fields when forwarding the message. When generating new mes- 206 sages, a given IGMP version should set fields to the appropri- 207 ate values for its own version. If any fields are reserved or 208 otherwise undefined for a given IGMP version, the fields SHOULD 209 be ignored when parsing the message and MUST be set to zeroes 210 when new messages are generated by implementations of that IGMP 211 version. 213 4) An IGMP snooping switch SHOULD be aware of link layer topology 214 changes. Following a topology change the switch SHOULD initi- 215 ate the transmission of a General Query on all ports in order 216 to reduce network convergence time. If the switch is not the 217 Querier, it SHOULD use the 'all-zeros' IP Source Address in 218 these proxy queries. When such proxy queries are received, 219 they MUST NOT be included in the Querier election process. 221 5) An IGMP snooping switch MUST NOT make use of information in 222 IGMP packets where the IP or IGMP headers have checksum or 223 integrity errors. The switch SHOULD NOT flood such packets but 224 if it does, it SHOULD take some note of the event (i.e., incre- 225 ment a counter). These errors and their processing are further 226 discussed in [IGMPv3], [MLD] and [MLDv2]. 228 6) The snooping switch MUST NOT rely exclusively on IGMP announce- 229 ments to determine when entries should be removed from the for- 230 warding table. The reason for this is that changes in the 231 local topology may cause the snooping switch to fall off the 232 path between the router and recipient system. As a result, the 233 switch cannot be assured of seeing an annoucement message asso- 234 ciated with the recipient leaving the group. 236 2.1.2. Data Forwarding Rules 238 1) Packets with a destination IP (DIP) address in the 224.0.0.X 239 range which are not IGMP MUST be forwarded on all ports. 241 This requirement is based on fact that many hosts exist today 242 which do not Join IP multicast addresses in this range before 243 sending or listening to IP multicasts. Furthermore since the 244 224.0.0.X address range is defined as link local (not to be 245 routed) it seems unnecessary to keep state for each address in 247 RFC DRAFT October 2002 249 this range. Additionally, some vendors' applications, which 250 are not IGMP, use this 224.0.0.X address range, and these 251 applications would break if the switch were to prune them due 252 to not seeing a Join. 254 2) Packets with a destination IP address outside 224.0.0.X which 255 are not IGMP SHOULD be forwarded according to group-based port 256 membership tables and MUST also be forwarded on router ports. 258 This is the core IGMP snooping requirement for the data path. 260 Discussion: An implementation could maintain separate member- 261 ship and multicast router tables in software and then "merge" 262 these tables into a current forwarding cache. 264 3) If a switch receives a non-IGMP IPV4 multicast packet without 265 having first processed Membership Reports for the group 266 address, it MAY forward the packet on all ports, but it MUST 267 forward the packet on router ports. A switch MAY forward an 268 unregistered packet only on router ports, but the switch MUST 269 have a configuration option that suppresses this restrictive 270 operation and forces flooding of unregistered packets on all 271 ports. In environments with v3 hosts where the snooping switch 272 does not support v3, failure to flood unregistered streams 273 could prevent v3 hosts from receiving their traffic. Alterna- 274 tively, in environments where the snooping switch supports all 275 of the IGMP versions that are present, flooding unregistered 276 streams may cause IGMP hosts to be overwhelmed by multicast 277 traffic, even to the point of not receiving Queries and failing 278 to issue new membership reports for their own groups. 280 4) All non-IPv4 multicast packets SHOULD be flooded, except where 281 normal IEEE bridging operation would result in filtering multi- 282 cast packets. Discussion: This ensures that enabling IGMP 283 snooping does not break, for example, IPv6 multicast. 285 5) IGMP snooping switches MAY maintain forwarding tables based on 286 either MAC addresses or IP addresses. If a switch supports 287 both types of forwarding tables then the default behavior 288 SHOULD be to use IP addresses. 290 Discussion: Forwarding based on MAC addresses is subject to the 291 problem associated with the 32-fold IP address to 1 MAC address 292 mapping. 294 6) Switches which rely on information in the IP header SHOULD ver- 295 ify that the IP header checksum is correct. If the checksum 296 fails, the information in the packet MUST NOT be incorporated 298 RFC DRAFT October 2002 300 into the forwarding table. Further, the packet SHOULD be dis- 301 carded. 303 7) The "include source" and "exclude source" options in IGMPv3 do 304 not work on shared segments. These options are used to register 305 for multicast traffic only from certain senders, or from all 306 except certain senders. On shared segments, if one host has 307 registered to receive a multicast data stream but has used the 308 "include source" or "exclude source" option, any additional 309 hosts that later request membership for that same multicast 310 group must accept the restrictions issued in the first host's 311 request. 313 2.2. IGMP snooping related problems 315 A special problem arises in networks consisting of IGMPv3 routers 316 as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 317 snooping switch. The router will continue to maintain IGMPv3 even 318 in the presence of IGMPv2 hosts, and thus the network will not 319 likely converge on IGMPv2. But it is likely that the IGMPv2 snoop- 320 ing switch will not recognize or process the IGMPv3 membership 321 reports. Groups for these unrecognized reports will then either be 322 flooded (with all of the problems that may create for hosts in a 323 network with a heavy multicast load) or pruned by the snooping 324 switch. 326 Therefore it is recommended that in such a network, the multicast 327 router be configured to use IGMPv2. 329 3. IPv6 Considerations 331 In order to avoid confusion, the previous discussions have been 332 based on the IGMP protocol which only applies to IPv4 multicast. 333 In the case of IPv6 most of the above discussions are still valid 334 with a few exceptions which we will describe here. 336 The control and data forwarding rules in the IGMP section can, with 337 a few considerations, also be applied to MLD. This means that the 338 basic functionality of intercepting MLD packets, and building mem- 339 bership lists and multicast router lists, is the same as for IGMP. 341 In IPv6, the data forwarding rules are more straight forward 342 because MLD is mandated for addresses with scope 2 (link-scope) or 343 greater. The only exception is the address FF002::1 which is the 344 all hosts link-scope address for which MLD messages are never sent. 345 Packets with the all hosts link-scope address should be forwarded 347 RFC DRAFT October 2002 349 on all ports. 351 MLD messages are also not sent to packets in the address range 352 FF00X::/16 when X is 0 or 1 (which are reserved and node-local, 353 respectively), and these addresses should never appear in packets 354 on the link. 356 The three main differences between IPv4 and IPv6 in relation to 357 multicast are: 359 - The IPv6 protocol for multicast group maintenance is called Mul- 360 ticast Listener Discovery (MLDv2). MLDv2 uses ICMPv6 message 361 types instead of IGMP message types. 363 - The ethernet encapsulation is a mapping of 32 bits of the 128 364 bit DIP addresses into 48 bit DMAC addresses [IPENCAPS]. 366 - Multicast router discovery is done using Neighbor Discovery Pro- 367 tocol (NDP) for IPv6. NDP uses ICMPv6 message types. 369 The IPv6 packet header does not include a checksum field. Never- 370 theless, the switch SHOULD detect other packet integrity issues. 371 When the snooping switch detects such an error, it MUST NOT include 372 information from the corresponding packet in the MLD forwarding ta- 373 ble. The forwarding code SHOULD drop the packet and take further 374 reasonable actions as advocated above. 376 The fact that MLDv2 is using ICMPv6 adds new requirements to a 377 snooping switch because ICMPv6 has multiple uses aside from MLD. 378 This means that it is no longer sufficient to detect that the next- 379 header field of the IP header is ICMPv6 in order to identify pack- 380 ets relevant for MLD snooping. 382 Discussion: If an implementation was software-based, wrongly iden- 383 tifying non-MLD packets as candidates for MLD snooping would poten- 384 tially fill the CPU queue with irrelevant packets thus preventing 385 the snooping functionality. Furthermore, ICMPv6 packets destined 386 for other hosts would not reach their destinations. 388 A solution is either to require that the snooping switch looks fur- 389 ther into the packets, or to be able to detect a multicast DMAC 390 address in conjunction with ICMPv6. The first solution is desir- 391 able only if it is configurable which message types should trigger 392 a CPU redirect and which should not. The reason is that a hardcod- 393 ing of message types is inflexible for the introduction of new mes- 394 sage types. The second solution introduces the risk of new proto- 395 cols which use ICMPv6 and multicast DMAC addresses but which are 396 not related to MLD, wrongly being identified as MLD. It is 398 RFC DRAFT October 2002 400 suggested that solution one is preferred if the switch is capable 401 of triggering CPU redirects on individual ICMPv6 message types. If 402 this is not the case, then use solution two. 404 The mapping from IP multicast addresses to multicast DMAC addresses 405 introduces a potentially enormous overlap. The structure of an IPv6 406 multicast address is shown in the figure below. Theoretically 407 2**80, two to the power of 80 (128 - 8 - 4 - 4 - 32) unique DIP 408 addresses could map to one DMAC address. This should be compared to 409 2**5 in the case of IPv4. 411 Initial allocation of IPv6 multicast addresses, however, uses only 412 the lower 32 bits of group ID. This eliminates the address ambigu- 413 ity for the time being, but it should be noted that the allocation 414 policy may change in the future. Because of the potential overlap 415 it is recommended that IPv6 address based forwarding is preferred 416 to MAC address based forwarding. 418 | 8 | 4 | 4 | 112 bits | 419 +--------+----+----+---------------------------------------+ 420 |11111111|flgs|scop| group ID | 421 +--------+----+----+---------------------------------------+ 423 4. Security Considerations 425 Security considerations for IGMPv3 are accounted for in [IGMPv3]. 426 The introduction of IGMP snooping switches adds the following con- 427 siderations with regard to IP multicast. 429 1) The exclude source failure, which could cause traffic from 430 sources that are 'black listed' to reach hosts that have requested 431 otherwise. This can also occur in certain network topologies with- 432 out IGMP snooping. 434 2) It is possible to generate packets which make the switch wrongly 435 believe that there is a multicast router on the segment on which 436 the source is attached. This will potentially lead to excessive 437 flooding on that segment. The authentication methods discussed in 438 [IGMPv3] will also provide protection in this case. 440 3) IGMP snooping switches which rely on the IP header of a packet 441 for their operation and which do not validate the header checksum 442 potentially will forward packets on the wrong ports. Even though 443 the IP headers are protected by the ethernet checksum this is a 444 potential vulnerability. 446 RFC DRAFT October 2002 448 Generally though, it is worth it to stress that IP multicast must 449 so far be considered insecure until the work of for example the 450 suggested Multicast Security (MSEC) working group or similar is 451 completed or at least has matured. 453 5. IGMP Questionnaire 455 As part of this work the following questions were asked both on the 456 MAGMA discussion list and sent to known switch vendors implementing 457 IGMP snooping. The individual contributions have been anonymized 458 upon request and do not necessarily apply to all of the vendors' 459 products. 461 The questions were: 463 Q1 Does your switches perform IGMP Join aggregation? In other 464 words, are IGMP joins intercepted, absorbed by the hard- 465 ware/software so that only one Join is forwarded to the 466 querier? 468 Q2 Is multicast forwarding based on MAC addresses? Would data- 469 grams addressed to multicast IP addresses 224.1.2.3 and 470 239.129.2.3 be forwarded on the same ports-groups? 472 Q3 Is it possible to forward multicast datagrams based on IP 473 addresses (not routed)? In other words, could 224.1.2.3 and 474 239.129.2.3 be forwarded on different port-groups with unal- 475 tered TTL? 477 Q4 Are multicast datagrams within the range 224.0.0.1 to 478 224.0.0.255 forwarded on all ports whether or not IGMP Joins 479 have been sent? 481 Q5 Are multicast frames within the MAC address range 482 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports 483 whether or not IGMP joins have been sent? 485 Q6 Does your switch support forwarding to ports on which IP multi- 486 cast routers are attached in addition to the ports where IGMP 487 Joins have been received? 489 Q7 Is your IGMP snooping functionality fully implemented in hard- 490 ware? 492 Q8 Is your IGMP snooping functionality partly software imple- 493 mented? 495 RFC DRAFT October 2002 497 Q9 Can topology changes (for example spanning tree configuration 498 changes) be detected by the IGMP snooping functionality so that 499 for example new queries can be sent or tables can be updated to 500 ensure robustness? 502 The answers were: 504 ---------------------------+-----------------------+ 505 | Switch Vendor | 506 ---------------------------+---+---+---+---+---+---+ 507 | 1 | 2 | 3 | 4 | 5 | 6 | 508 ---------------------------+---+---+---+---+---+---+ 509 Q1 Join aggregation | x | x | x | | x | x | 510 Q2 Layer-2 forwarding | x | x | x | x |(1)| | 511 Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x | 512 Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x | 513 Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x | 514 Q6 Mcast router list | x | x | x | x | x | x | 515 Q7 Hardware implemented | | | | | | | 516 Q8 Software assisted | x | x | x | x | x | x | 517 Q9 Topology change aware | x | x | x | x | |(2)| 518 ---------------------------+---+---+---+---+---+---+ 519 x Means that the answer was Yes. 520 (1) In some products (typically high-end) Yes, in others No. 521 (2) Currently no, but will be really soon. 523 6. IETF IPR Statement 525 "The IETF takes no position regarding the validity or scope of any 526 intellectual property or other rights that might be claimed to 527 pertain to the implementation or use of the technology described in 528 this document or the extent to which any license under such rights 529 might or might not be available; neither does it represent that it 530 has made any effort to identify any such rights. Information on 531 the IETF's procedures with respect to rights in standards-track and 532 standards-related documentation can be found in BCP-11. Copies of 533 claims of rights made available for publication and any assurances 534 of licenses to be made available, or the result of an attempt made 535 to obtain a general license or permission for the use of such pro- 536 prietary rights by implementors or users of this specification can 537 be obtained from the IETF Secretariat." 539 RFC DRAFT October 2002 541 7. References 543 [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" 545 [CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP 546 and IGMP snooping", http://www.cisco.com/warp/pub- 547 lic/473/22.html 549 [IANA] Internet Assigned Numbers Authority, "Internet Multicast 550 Addresses", http://www.isi.edu/in-notes/iana/assign- 551 ments/multicast-addresses 553 [IGMPv3] Cain, B., "Internet Group Management Protocol, Version 554 3", draft-ietf-idmr-igmp-v3-11.txt, May 2002. 556 [IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether- 557 net Networks", RFC2464, December 1998. 559 [MLD] Deering, S., Fenner, B., and Haberman, B. "Multicast 560 Listener Discovery (MLD) for IPv6", RFC2710, October 561 1999. 563 [MLDv2] Vida, R., "Multicast Listener Discovery Version 2 564 (MLDv2) for IPv6", draft-vida-mld-v2-03.txt, June 2002. 566 [MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft- 567 ietf-idmr-igmp-mrdisc-08.txt, January 2002. 569 [MSOFT] Microsoft support article Q223136, "Some LAN Switches 570 with IGMP Snooping Stop Forwarding Multicast Packets on 571 RRAS Startup", http://support.microsoft.com/sup- 572 port/kb/articles/Q223/1/36.ASP 574 [PROXY] Fenner, B. et al, "IGMP-based Multicast Forwarding (IGMP 575 Proxying)", draft-ietf-magma-igmp-proxy-01.txt, July 576 2002. 578 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 579 1112, August 1989. 581 [RFC2026] Bradner, S. "The Internet Standards Process -- Revision 582 3", RFC2026, October 1996. 584 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 585 2", RFC2236, November 1997. 587 RFC DRAFT October 2002 589 [RFC2375] Hinden, R. "IPv6 Multicast Address Assignments", 590 RFC2375, July 1998. 592 8. Acknowledgements 594 We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter, 595 Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward 596 Hilquist, Hugh Holbrook, Kevin Humphries, Suzuki Shinsuke, Jaff 597 Thomas and Rolland Vida for comments and suggestions on this docu- 598 ment. 600 Furthermore, the following companies are acknowledged for their 601 contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, 602 Hewlett-Packard, Vitesse Semiconductor Corporation. The ordering 603 of these names do not necessarily correspond to the column numbers 604 in the response table. 606 9. Revision History 607 This section, while incomplete, is provided as a convenience to the 608 working group members. It will be removed when the document is 609 released in its final form. 611 draft-ietf-magma-snoop-04.txt: November 2002 Editorial changes 612 only. 614 draft-ietf-magma-snoop-03.txt: October 2002 616 IGMP Forwarding rules: 617 Add references to and become consistant with the current IGMP 618 proxy draft, 620 Unrecognized IGMP packets should not be ignored because "mbz" 621 fields are not zero since packets from future versions are 622 expected to maintain consistency. 624 Corrections related to IGMP Querier election process. 626 Add clarification to how lists of router ports may be assem- 627 bled. 629 Data Forwarding rules: 630 Added discussion of the problems for different IGMP environ- 631 ments in choosing whether to flood or to prune unregistered 632 multicasts. 634 RFC DRAFT October 2002 636 Added refinements for how to handle NON-IPv4 multicasts, to 637 keep IGMP-snooping functionality from interfering with IPv6 638 and other multicast traffic. Any filtering for non-IPv4 multi- 639 casts should be based on bridge behavior and not IGMP snooping 640 behavior. 642 IGMP snooping related problems: 643 Fixed description of interoperability issues in environments 644 with v3 routers and hosts, and v2 snooping switches. 646 Added discussion of the IGMPv3 "include source" and "exclude 647 source" options, and the inability to support them on shared 648 segments. 650 IPv6 Considerations: 651 Clarifications regarding address ranges FF00::, FF01:: and all 652 hosts FF02::1 in relation to data forwarding. 654 draft-ietf-magma-snoop-02.txt: June 2002 656 Status section removes document history; moved into this sec- 657 tion instead. 659 Introduction restores text from the -00 revision that 660 describes snooping and its goals 662 IGMP flooding rules eased, allowing management option to 663 broaden beyond "routers only". 665 Removed a SHOULD/MAY inconsistancy between IPv4 Forwarding and 666 IPv6 processing of checksums. 668 IGMP Forwarding Rules: clarify text describing processing of 669 non-zero reserved fields. 671 Data Forwarding Rules, item 3 is changed from "MUST forward to 672 all ports" to "MAY"; item 4 default changes from "MUST" to 673 "SHOULD use network addresses". 675 Added two sets of additional responses to the questionnaire 676 and text indicating that responses don't cover all products. 678 Removed (commented out) description of IPR issues: IESG is 679 aware of them. 681 draft-ietf-magma-snoop-01.txt: January 2002 683 RFC DRAFT October 2002 685 Extensive restructuring of the original text. 687 draft-ietf-idmr-snoop-01.txt: 2001 689 Added several descriptions of cases where IGMP snooping imple- 690 mentations face problems. Also added several network topology 691 figures. 693 draft-ietf-idmr-snoop-00.txt: 2001 695 Initial snooping draft. An overview of IGMP snooping and the 696 problems to be solved. 698 10. Author's Addresses 700 Morten Jagd Christensen 701 jCAPS 702 Begoniavej 13 703 2820 Gentofte 704 email: mjc@jcaps.com 706 Karen Kimball 707 Hewlett-Packard 708 8000 Foothills Blvd. 709 Roseville, CA 95747 710 email: karen.kimball@hp.com 712 Frank Solensky 713 Bluejavelin, Inc. 714 3 Dundee Park 715 Andover, MA 01810 716 email: fsolensky@bluejavelin.net 718 RFC DRAFT October 2002 720 Table of Contents 722 1. Introduction . . . . . . . . . . . . . . . . . . . . . 2 723 2. IGMP Snooping Requirements . . . . . . . . . . . . . . 3 724 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . 3 725 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . 3 726 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . 5 727 2.2. IGMP snooping related problems . . . . . . . . . . . 7 728 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . 7 729 4. Security Considerations . . . . . . . . . . . . . . . . 9 730 5. IGMP Questionnaire . . . . . . . . . . . . . . . . . . 10 731 6. IETF IPR Statement . . . . . . . . . . . . . . . . . . 11 732 7. References . . . . . . . . . . . . . . . . . . . . . . 12 733 8. Acknowledgements . . . . . . . . . . . . . . . . . . . 13 734 9. Revision History . . . . . . . . . . . . . . . . . . . 13 735 10. Author's Addresses . . . . . . . . . . . . . . . . . . 15