idnits 2.17.00 (12 Aug 2021) /tmp/idnits47871/draft-ietf-magma-snoop-07.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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations for IGMPv3 are accounted for in' ) ** 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 629: '...ll occurances of MUST, MAY etc. to low...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 604 has weird spacing: '...rrected a ref...' == Line 866 has weird spacing: '...imed to perta...' -- 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 (May 2003) is 6945 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2735' is mentioned on line 443, but not defined == Unused Reference: 'RFC2375' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 775, but no explicit reference was found in the text == Outdated reference: draft-vida-mld-v2 has been published as RFC 3810 ** Obsolete normative reference: RFC 2461 (ref. 'NDP') (Obsoleted by RFC 4861) == Outdated reference: draft-ietf-magma-igmp-proxy has been published as RFC 4605 Summary: 8 errors (**), 0 flaws (~~), 9 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: October 2003 K. Kimball 5 Category: Informational Hewlett-Packard 6 F. Solensky 7 Bluejavelin 8 May 2003 10 Considerations for IGMP and MLD Snooping Switches 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [RFC2026]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This memo describes the requirements for IGMP- and MLD-snooping 42 switches. These are based on best current practices for IGMPv2, 43 with further considerations for IGMPv3- and MLDv2-snooping. 44 Additional areas of relevance, such as link layer topology changes 45 and Ethernet-specific encapsulation issues, are also considered. 47 Interoperability issues that arise between different versions of 48 IGMP are not the focus of this document. Interested readers are 49 directed to [IGMPv3] for a thorough description of problem areas. 51 1. Introduction 53 When processing a packet whose destination MAC address is a 54 multicast address, the switch will forward a copy of the packet 55 into each of the remaining network interfaces that are the 56 forwarding state in accordance with [BRIDGE]. The spanning tree 57 algorithm ensures that the application of this rule at every switch 58 in the network will make the packet accessible to all nodes 59 connected to the network. 61 This approach works well for broadcast packets that are intended to 62 be seen or processed by all connected nodes. In the case of 63 multicast packets, however, this approach could lead to less 64 efficient use of network bandwidth, particularly when the packet is 65 intended for only a small number of nodes. Packets will be flooded 66 into network segments where no node has any interest in receiving 67 the packet. While nodes will rarely incur any processing overhead 68 to filter packets addressed to unrequested group addresses, they 69 are unable to transmit new packets onto the shared media for the 70 period of time that the multicast packet is flooded. In general, 71 significant bandwidth can be wasted by flooding. 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 77 communications layers in the ISO model, and instead utilize 78 information in the upper level protocol headers as factors to be 79 considered in the processing at the lower levels. This is 80 analogous to the manner in which a router can act as a firewall by 81 looking into the transport protocol's header before allowing a 82 packet to be forwarded to its 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 86 network where no node has expressed interest in receiving packets 87 addressed to the group address. This is in contrast to normal 88 switch behavior 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 93 the information presented in this draft will supply this 94 foundation. 96 The requirements presented here are based on the following 97 information sources: The IGMP specifications [RFC1112], [RFC2236] 98 and [IGMPv3], vendor-supplied technical documents [CISCO], bug 99 reports [MSOFT], discussions with people involved in the design of 100 IGMP snooping switches, MAGMA mailing list discussions, and on 101 replies by switch vendors to an implementation questionnaire. 103 The suggestions in this document are based on IGMP, which applies 104 only to IPv4. For IPv6, Multicast Listener Discovery [MLD] must be 105 used instead. Because MLD is based on IGMP, we do not repeat the 106 entire description and requirements for MLD snooping switches. 107 Instead, we point out the few cases where there are differences 108 from IGMP. 110 Note that the IGMP snooping function should apply only to IPv4 111 multicasts. Other multicast packets, such as IPv6, might be 112 suppressed by IGMP snooping if additional care is not taken in the 113 implementation. It is desired not to restrict the flow of non-IPv4 114 multicasts other than to the degree which would happen as a result 115 of regular bridging functions. Likewise, MLD snooping switches are 116 discouraged from using topological information learned from IPv6 117 traffic to alter the forwarding of IPv4 multicast packets. 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 123 description of a possible implementation approach. All 124 implementation discussions are examples only and there may well be 125 other ways to achieve the same functionality. 127 2.1. Forwarding rules 129 The IGMP snooping functionality is here separated into a control 130 section (IGMP forwarding) and a data section (Data forwarding). 132 2.1.1. IGMP Forwarding Rules 134 1) A snooping switch should forward IGMP Membership Reports only 135 to those ports where multicast routers are attached. 136 Alternatively stated: a snooping switch should not forward IGMP 137 Membership Reports to ports on which only hosts are attached. 138 An administrative control may be provided to override this 139 restriction, allowing the report messages to be flooded to 140 other ports. 142 This is the main IGMP snooping functionality. Sending 143 membership reports (as described in IGMP versions 1 and 2) to 144 other hosts can result in unintentionally preventing a host 145 from joining a specific multicast group. This is not a problem 146 in an IGMPv3-only network because there is no message 147 suppression of IGMP Membership reports. 149 The administrative control allows IGMP Membership Report 150 messages to be processed by network monitoring equipment such 151 as packet analyzers or port replicators. 153 The switch supporting IGMP snooping must maintain a list of 154 multicast routers and the ports on which they are attached. 155 This list can be constructed in any combination of the 156 following ways: 158 a) This list should be built by the snooping switch sending 159 Multicast Router Solicitation messages as described in IGMP 160 Multicast Router Discovery [MRDISC]. It may also snoop 161 Multicast Router Advertisement messages sent by and to 162 other nodes. 164 b) The arrival port for IGMP Queries (sent by multicast 165 routers) where the source address is not 0.0.0.0. 167 c) Ports explicitly configured by management to be IGMP- 168 forwarding ports, in addition to or instead of any of the 169 above methods to detect router ports. 171 2) IGMP snooping switches may also implement "proxy-reporting" in 172 which reports received from downstream hosts are summarized and 173 used to build internal membership states as described in 174 [PROXY]. The IGMP proxy-reporting switch would then report its 175 own state in response to upstream queriers. If the switch does 176 not already have an IP address assigned to it, the source 177 address for these reports should be set to all-zeros. 179 An IGMP proxy-reporting switch may act as Querier for the 180 downstream hosts while proxy reporting to the 'real' upstream 181 queriers. 183 It should be noted that there may be multiple IGMP proxy- 184 reporting switches in the network all using the 0.0.0.0 source 185 IP address. In this case the switches can be uniquely 186 identified through their link layer source MAC address. 188 IGMP membership reports must not be rejected by an IGMP 189 snooping switch because of a source IP address of 0.0.0.0. 191 3) The switch that supports IGMP snooping must flood all 192 unrecognized IGMP messages to all other ports and must not 193 attempt to make use of any information beyond the end of the 194 network layer header. 196 In addition, earlier versions of IGMP should interpret IGMP 197 fields as defined for their versions and must not alter these 198 fields when forwarding the message. When generating new 199 messages, a given IGMP version should set fields to the 200 appropriate values for its own version. If any fields are 201 reserved or otherwise undefined for a given IGMP version, the 202 fields should be ignored when parsing the message and must be 203 set to zeroes when new messages are generated by 204 implementations of that IGMP version. An exception may occur 205 if the switch is performing a spoofing function, and is aware 206 of the settings for new or reserved fields that would be 207 required to correctly spoof for a different IGMP version. 209 4) An IGMP snooping switch should be aware of link layer topology 210 changes caused by Spanning Tree operation. When a port is 211 enabled or disabled by Spanning Tree, a General Query may be 212 sent on all active non-router ports in order to reduce network 213 convergence time. Non-Querier switches should be aware of 214 whether the Querier is in IGMPv3 mode. If so, the switch should 215 not spoof any General Queries unless it is able to send an 216 IGMPv3 Query that adheres to the most recent information sent 217 by the true Querier. In no case should a switch introduce a 218 spoofed IGMPv2 Query into an IGMPv3 network, as this may create 219 excessive network disruption. 221 If the switch is not the Querier, it should use the 'all-zeros' 222 IP Source Address in these proxy queries (even though some 223 hosts may elect to not process queries with a 0.0.0.0 IP Source 224 Address). When such proxy queries are received, they must not 225 be included in the Querier election process. 227 5) An IGMP snooping switch must not make use of information in 228 IGMP packets where the IP or IGMP headers have checksum or 229 integrity errors. The switch should not flood such packets but 230 if it does, it should also take some note of the event (i.e., 231 increment a counter). These errors and their processing are 232 further discussed in [IGMPv3], [MLD] and [MLDv2]. 234 6) The snooping switch must not rely exclusively on the appearance 235 of IGMP Group Leave announcements to determine when entries 236 should be removed from the forwarding table. It should 237 implement a membership timeout mechanism such as the router- 238 side functionality of the IGMP protocol as described in 240 [IGMPv3] on all its non-router ports. This timeout value 241 should be configurable. 243 2.1.2. Data Forwarding Rules 245 1) Packets with a destination IP (DIP) address in the 224.0.0.X 246 range which are not IGMP must be forwarded on all ports. 248 This requirement is based on fact that many host systems do not 249 send Join IP multicast addresses in this range before sending 250 or listening to IP multicast packets. Furthermore, since the 251 224.0.0.X address range is defined as link-local (not to be 252 routed) it seems unnecessary to keep state for each address in 253 this range. Additionally, some routers operate in the 254 224.0.0.X address range without issuing IGMP Joins, and these 255 applications would break if the switch were to prune them due 256 to not having seen a Join Group message from the router. 258 2) Packets with a destination IP address outside 224.0.0.X which 259 are not IGMP should be forwarded according to group-based port 260 membership tables and must also be forwarded on router ports. 261 This is the core IGMP snooping requirement for the data path. 262 One approach that an implementation could take would be to 263 maintain separate membership and multicast router tables in 264 software and then "merge" these tables into a forwarding cache. 266 3) If a switch receives a non-IGMP IPv4 multicast packet without 267 having first processed Membership Reports for the group 268 address, it may forward the packet on all ports but it must 269 forward the packet on router ports. A switch may forward an 270 unregistered packet only on router ports, but the switch must 271 have a configuration option that suppresses this restrictive 272 operation and forces flooding of unregistered packets on 273 selected ports. 275 In an environment where IGMPv3 hosts are mixed with snooping 276 switches that do not yet support IGMPv3, the switch's failure 277 to flood unregistered streams could prevent v3 hosts from 278 receiving their traffic. Alternatively, in environments where 279 the snooping switch supports all of the IGMP versions that are 280 present, flooding unregistered streams may cause IGMP hosts to 281 be overwhelmed by multicast traffic, even to the point of not 282 receiving Queries and failing to issue new membership reports 283 for their own groups. 285 It is encouraged that snooping switches at least recognize and 286 process IGMPv3 Join Reports, even if this processing is limited 287 to the behavior for IGMPv2 Joins, i.e., is done without 288 considering any additional "include source" or "exclude source" 289 filtering. When IGMPv3 Joins are not recognized, a snooping 290 switch may incorrectly prune off the unregistered data streams 291 for the groups (as noted above); alternatively, it may fail to 292 add in forwarding to any new IGMPv3 hosts if the group has 293 previously been joined as IGMPv2 (because the data stream is 294 seen as already having been registered). 296 4) All non-IPv4 multicast packets should continue to be flooded 297 out all remaining ports in the forwarding state as per normal 298 IEEE bridging operations. 300 This requirement is a result of the fact that groups made up of 301 IPv4 hosts and IPv6 hosts are completely separate and distinct 302 groups. As a result, information gleaned from the topology 303 between members of an IPv4 group would not be applicable when 304 forming the topology between members of an IPv6 group. 306 5) IGMP snooping switches may maintain forwarding tables based on 307 either MAC addresses or IP addresses. If a switch supports 308 both types of forwarding tables then the default behavior 309 should be to use IP addresses. IP address based forwarding is 310 preferred because the mapping between IP multicast addresses 311 and link-layer multicast addresses is ambiguous. In the case 312 of Ethernet, there is a multiplicity of 1 Ethernet address to 313 32 IP addresses [RFC1112]. 315 6) Switches which rely on information in the IP header should 316 verify that the IP header checksum is correct. If the checksum 317 fails, the information in the packet must not be incorporated 318 into the forwarding table. Further, the packet should be 319 discarded. 321 7) When IGMPv3 "include source" and "exclude source" membership 322 reports are received on shared segments, the switch needs to 323 forward the superset of all received membership reports onto 324 the shared segment. Forwarding of traffic from a particular 325 source S to a group G must happen if at least one host on the 326 shared segment reports an IGMPv3 membership of the type 327 INCLUDE(G, Slist1) or EXCLUDE(G, Slist2) where S is an element 328 of Slist1 and not an element of Slist2. 330 2.2. IGMP snooping-related problems 332 A special problem arises in networks consisting of IGMPv3 routers 333 as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 334 snooping switch as recently reported [IETF56]. The router will 335 continue to maintain IGMPv3 even in the presence of IGMPv2 hosts, 336 and thus the network will not converge on IGMPv2. But it is likely 337 that the IGMPv2 snooping switch will not recognize or process the 338 IGMPv3 membership reports. Groups for these unrecognized reports 339 will then either be flooded (with all of the problems that may 340 create for hosts in a network with a heavy multicast load) or 341 pruned by the snooping switch. 343 Therefore, it is recommended that in such a network, the multicast 344 router be configured to use IGMPv2. If this is not possible, and if 345 the snooping switch cannot recognize and process the IGMPv3 346 membership reports, it is instead recommended that the switch's 347 IGMP snooping functionality be disabled, as there is no clear 348 solution to this problem. 350 3. IPv6 Considerations 352 In order to avoid confusion, the previous discussions have been 353 based on the IGMP protocol which only applies to IPv4 multicast. 354 In the case of IPv6 most of the above discussions are still valid 355 with a few exceptions which we will describe here. 357 The control and data forwarding rules in the IGMP section can, with 358 a few considerations, also be applied to MLD. This means that the 359 basic functionality of intercepting MLD packets, and building 360 membership lists and multicast router lists, is the same as for 361 IGMP. 363 In IPv6, the data forwarding rules are more straight forward 364 because MLD is mandated for addresses with scope 2 (link-scope) or 365 greater. The only exception is the address FF02::1 which is the 366 all hosts link-scope address for which MLD messages are never sent. 367 Packets with the all hosts link-scope address should be forwarded 368 on all ports. 370 MLD messages are also not sent to packets in the address range 371 FF00::/15 (which encompasses both the reserved FF00::/16 and node- 372 local FF01::/16 IPv6 address spaces). These addresses should never 373 appear in packets on the link. 375 Equivalent to the IPv4 behaviors regarding the null IP Source 376 address, MLD membership reports must not be rejected by an MLD 377 snooping switch because of an unspecified IP source address (::). 378 Additionally, if a non-Querier switch spoofs any General Queries 379 (as addressed in Section 2.1 above, for Spanning Tree topology 380 changes), the switch should use the null IP source address (::) 381 when sending said queries. When such proxy queries are received, 382 they must not be included in the Querier election process. 384 The three major differences between IPv4 and IPv6 in relation to 385 multicast are: 387 - The IPv6 protocol for multicast group maintenance is called 388 Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message 389 types instead of IGMP message types. 391 - The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128 392 bit DIP address are used to form the 48 bit DMAC addresses for 393 multicast groups, while [IPV6-TOKEN] describes the mapping for 394 token ring DMAC addresses by using three low-order bits. The 395 specification [IPV6-1394] makes use of a 6 bit channel number. 397 - Multicast router discovery is accomplished using Neighbor 398 Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message 399 types. 401 The IPv6 packet header does not include a checksum field. 402 Nevertheless, the switch should detect other packet integrity 403 issues. When the snooping switch detects such an error, it must 404 not include information from the corresponding packet in the MLD 405 forwarding table. The forwarding code should instead drop the 406 packet and take further reasonable actions as advocated above. 408 The fact that MLDv2 is using ICMPv6 adds new requirements to a 409 snooping switch because ICMPv6 has multiple uses aside from MLD. 410 This means that it is no longer sufficient to detect that the next- 411 header field of the IP header is ICMPv6 in order to identify 412 packets relevant for MLD snooping. A software-based implemention 413 which treats all ICMPv6 packets as candidates for MLD snooping 414 could easily fill its receive queue and bog down the CPU with 415 irrelevant packets. This would prevent the snooping functionality 416 from performing its intended purpose and the non-MLD packets 417 destined for other hosts could be lost. 419 A solution is either to require that the snooping switch looks 420 further into the packets, or to be able to detect a multicast DMAC 421 address in conjunction with ICMPv6. The first solution is 422 desirable when a configuration option allows the administrator to 423 specify which ICMPv6 message types should trigger a CPU redirect 424 and which should not. The reason is that a hardcoding of message 425 types is inflexible for the introduction of new message types. The 426 second solution introduces the risk that new protocols which use 427 ICMPv6 and multicast DMAC addresses could be incorrectly identified 428 as MLD. It is suggested that solution one is preferred when the 429 administrative switch is provided. If this is not the case, then 430 the implementator should seriously consider making this switch 431 available since Neighbor Discovery messages would be among those 432 that fall into this false positive case and are vital for the 433 operational integrity of IPv6 networks. 435 The mapping from IP multicast addresses to multicast DMAC addresses 436 introduces a potentially enormous overlap. The structure of an 437 IPv6 multicast address is shown in the figure below. As a result, 438 there are 2 ** (112 - (32 - 8)), or more than 7.9e28 unique DIP 439 addresses which map into a single DMAC address in Ethernet and 440 FDDI. This should be compared to 2**5 in the case of IPv4. 442 Initial allocation of IPv6 multicast addresses as described in 443 [RFC2735], however, cover only the lower 24 bits of group ID. 444 While this reduces the problem of address ambiguity to group IDs 445 with different flag and scope values for now, it should be noted 446 that the allocation policy may change in the future. Because of 447 the potential overlap it is recommended that IPv6 address based 448 forwarding is preferred to MAC address based forwarding. 450 | 8 | 4 | 4 | 112 bits | 451 +--------+----+----+---------------------------------------+ 452 |11111111|flgs|scop| group ID | 453 +--------+----+----+---------------------------------------+ 455 4. IGMP Questionnaire 457 As part of this work the following questions were asked both on the 458 MAGMA discussion list and sent to known switch vendors implementing 459 IGMP snooping. The individual contributions have been anonymized 460 upon request and do not necessarily apply to all of the vendors' 461 products. 463 The questions were: 465 Q1 Does your switches perform IGMP Join aggregation? In other 466 words, are IGMP joins intercepted, absorbed by the 467 hardware/software so that only one Join is forwarded to the 468 querier? 470 Q2 Is multicast forwarding based on MAC addresses? Would 471 datagrams addressed to multicast IP addresses 224.1.2.3 and 472 239.129.2.3 be forwarded on the same ports-groups? 474 Q3 Is it possible to forward multicast datagrams based on IP 475 addresses (not routed)? In other words, could 224.1.2.3 and 476 239.129.2.3 be forwarded on different port-groups with 477 unaltered TTL? 479 Q4 Are multicast datagrams within the range 224.0.0.1 to 480 224.0.0.255 forwarded on all ports whether or not IGMP Joins 481 have been sent? 483 Q5 Are multicast frames within the MAC address range 484 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports 485 whether or not IGMP joins have been sent? 487 Q6 Does your switch support forwarding to ports on which IP 488 multicast routers are attached in addition to the ports where 489 IGMP Joins have been received? 491 Q7 Is your IGMP snooping functionality fully implemented in 492 hardware? 494 Q8 Is your IGMP snooping functionality partly software 495 implemented? 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) Not at the time that the questionnaire was received 522 but expected in the near future. 524 Revision History 526 This section, while incomplete, is provided as a convenience to the 527 working group members. It will be removed when the document is 528 released in its final form. 530 draft-ietf-magma-snoop-07.txt: May 2003 532 The current version reflects comments made at the 56'th IETF 533 meeting and from the previous WG last call. The majority of 534 changes appear in sections 2.1 and 2.2, and even the changes 535 here are in reality not substantial. 537 Substantial comments 539 Section 2.1.1.(4): Changed wording for IGMP forwarding 540 section on when spoofing of General Queries should occur. 541 Added description of how to avoid IGMP version 542 incompatibility problems when doing said spoofing. 544 Section 2.1.2.(3): Clarification of incompatibility 545 problems in mixed IGMPv2 and IGMPv3 networks. Added 546 recommendation for switches to implement some level of 547 IGMPv3 Join recognition to reduce these problems. 549 Section 2.2: Advice following the briefing [IETF56], that 550 in some cases disabling IGMP snooping functionality is 551 the only 'solution' 553 Section 6, IPv6 Considerations: added descriptions of 554 behavior involving the IPv6 version of the null IP Source 555 Address (to parallel the IPv4 behaviors). 557 Added reference to [IGMPv3] in stead of [PROXY] for group 558 membership maintenance and timeout. 560 Editorial Changes 562 Really minor stuff such as change of authors email 563 address, addition of references, draft name increment and 564 date changes. 566 draft-ietf-magma-snoop-06.txt: March 2003 568 Changes in response to comments made during WG last call and 569 assessment by the WG chairs: 571 Substantial comments 573 Clarification in IGMP forwarding section on the 574 acceptance of membership reports with source IP address 575 0.0.0.0 as being a switch requirement. 577 Section 2.1.1.(4): Allow the router port to be excluded 578 from the General Query messages 580 Section 2.1.1.(6): Replace description of timing out 581 older entries with a reference to IGMP/MLD Proxying. 583 Section 2.1.2.(3): Replaced description of timeout 584 mechanism with a reference to IGMP/MLD. 586 Section 2.1.2.(4) Expanded rationale to discourage 587 leaking info between IPv4 and IPv6 groups. 589 Section 3: more strongly encourage the use of a 590 configuration option for selection of ICMPv6 message 591 types. 593 Editorial comments. 595 Hyphenation problem resolved for groff by setting then ms 596 HY register to zero, disabling all forms for the entire 597 document 598 (".hy 0" and ".nr" worked only as far as the following 599 ms macro). 601 Sections moved around - again - to comply with 602 rfc2223bis-03 draft. Added copyright notice after memo 603 status. Removed table of contents as the draft is fairly 604 short. Corrected a reference typo. 606 Section 2.1.2.(3): Requirement and rationale broken into 607 separate paragraphs. 609 Added references to other IPv6 encapsulation documents, 611 Corrected estimates for MAC address collisions for 612 Ethernet and FDDI: both specification take the low-order 613 four (not six) bytes from the IPv6 group addresses. 615 draft-ietf-magma-snoop-05.txt: January 2003 617 Changes in wording of IGMP forwarding rule 6) and Data 618 forwarding rule 7). Corrections in the references section. 620 Apart from above, no substantial changes has occured in the 621 document. Several editorial changes, however, have been made 622 to comply with the rfc editors requirements: 624 References splitted in normative and informative sections, 625 other related references added. 627 Abstract shortened. 629 Changed all occurances of MUST, MAY etc. to lowercase to 630 reflect that this is not a standards track document. 632 Sections moved around so they appear in the required order. 634 draft-ietf-magma-snoop-04.txt: November 2002 636 Editorial changes only. 638 draft-ietf-magma-snoop-03.txt: October 2002 640 IGMP Forwarding rules: 641 Add references to and become consistant with the current 642 IGMP proxy draft, 643 Unrecognized IGMP packets should not be ignored because 644 "mbz" fields are not zero since packets from future 645 versions are expected to maintain consistency. 647 Corrections related to IGMP Querier election process. 649 Add clarification to how lists of router ports may be 650 assembled. 652 Data Forwarding rules: 653 Added discussion of the problems for different IGMP 654 environments in choosing whether to flood or to prune 655 unregistered multicasts. 657 Added refinements for how to handle NON-IPv4 multicasts, 658 to keep IGMP-snooping functionality from interfering with 659 IPv6 and other multicast traffic. Any filtering for non- 660 IPv4 multicasts should be based on bridge behavior and 661 not IGMP snooping behavior. 663 IGMP snooping related problems: 664 Fixed description of interoperability issues in 665 environments with v3 routers and hosts, and v2 snooping 666 switches. 668 Added discussion of the IGMPv3 "include source" and 669 "exclude source" options, and the inability to support 670 them on shared segments. 672 IPv6 Considerations: 673 Clarifications regarding address ranges FF00::, FF01:: 674 and all hosts FF02::1 in relation to data forwarding. 676 draft-ietf-magma-snoop-02.txt: June 2002 678 Status section removes document history; moved into this 679 section instead. 681 Introduction restores text from the -00 revision that 682 describes snooping and its goals 684 IGMP flooding rules eased, allowing management option to 685 broaden beyond "routers only". 687 Removed a should/MAY inconsistancy between IPv4 Forwarding and 688 IPv6 processing of checksums. 690 IGMP Forwarding Rules: clarify text describing processing of 691 non-zero reserved fields. 693 Data Forwarding Rules, item 3 is changed from "MUST forward to 694 all ports" to "MAY"; item 4 default changes from "MUST" to 695 "should use network addresses". 697 Added two sets of additional responses to the questionnaire 698 and text indicating that responses don't cover all products. 700 Removed (commented out) description of IPR issues: IESG is 701 aware of them. 703 draft-ietf-magma-snoop-01.txt: January 2002 705 Extensive restructuring of the original text. 707 draft-ietf-idmr-snoop-01.txt: 2001 709 Added several descriptions of cases where IGMP snooping 710 implementations face problems. Also added several network 711 topology figures. 713 draft-ietf-idmr-snoop-00.txt: 2001 715 Initial snooping draft. An overview of IGMP snooping and the 716 problems to be solved. 718 5. References 720 5.1. Normative References 722 [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" 724 [IGMPv3] Cain, B., "Internet Group Management Protocol, 725 Version 3", RFC3376, October 2002. 727 [IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6 728 Packets over IEEE 1394 Networks", RFC3146, 729 October 2001. 731 [IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over 732 Ethernet Networks", RFC2464, December 1998. 734 [IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over 735 FDDI Networks", RFC2467, December 1998. 737 [IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., 738 "Transmission of IPv6 Packets over Token Ring 739 Networks", RFC2470, December 1998. 741 [MLD] Deering, S., Fenner, B. and Haberman, B. 742 "Multicast Listener Discovery (MLD) for IPv6", 743 RFC2710, October 1999. 745 [MLDv2] Vida, R. and Costa, L., "Multicast Listener 746 Discovery Version 2 (MLDv2) for IPv6", draft- 747 vida-mld-v2-06.txt, November 2002. 749 [MRDISC] Biswas, S., Cain, B. and Haberman, B., "Multicast 750 Router Discovery", draft-ietf-idmr-igmp- 751 mrdisc-10.txt, January 2003. 753 [NDP] Narten, T., Nordmark, E. and Simpson, W., 754 "Neighbor Discovery for IP Version 6 {IPv6)", 755 RFC2461, December 1998. 757 [PROXY] Fenner, B. et al, "IGMP/MLD-based Multicast 758 Forwarding (IGMP/MLD Proxying)", draft-ietf- 759 magma-igmp-proxy-02.txt, November 2002. 761 [RFC1112] Deering, S., "Host Extensions for IP 762 Multicasting", RFC1112, August 1989. 764 [RFC2026] Bradner, S. "The Internet Standards Process -- 765 Revision 3", RFC2026, October 1996. 767 [RFC2236] Fenner, W., "Internet Group Management Protocol, 768 Version 2", RFC2236, November 1997. 770 [RFC2375] Hinden, R. "IPv6 Multicast Address Assignments", 771 RFC2375, July 1998. 773 5.2. Informative References 775 [IANA] Internet Assigned Numbers Authority, "Internet 776 Multicast Addresses", http://www.isi.edu/in- 777 notes/iana/assignments/multicast-addresses 779 [CISCO] Cisco Tech Notes, "Multicast In a Campus Network: 780 CGMP and IGMP snooping", 781 http://www.cisco.com/warp/public/473/22.html 783 [MSOFT] Microsoft support article Q223136, "Some LAN 784 Switches with IGMP Snooping Stop Forwarding 785 Multicast Packets on RRAS Startup", 786 http://support.microsoft.com/support/kb/articles/ 787 Q223/1/36.ASP 789 [IETF56] Briefing by Dave Thaler, Microsoft, presented to 790 the MAGMA WG at the 56'th IETF meeting in San 791 Francisco. 793 6. Security Considerations 795 Security considerations for IGMPv3 are accounted for in 796 [IGMPv3]. The introduction of IGMP snooping switches adds the 797 following considerations with regard to IP multicast. 799 - The exclude source failure, which could cause traffic from 800 sources that are 'black listed' to reach hosts that have 801 requested otherwise. This can also occur in certain 802 network topologies without IGMP snooping. 804 - It is possible to generate packets which make the switch 805 wrongly believe that there is a multicast router on the 806 segment on which the source is attached. This will 807 potentially lead to excessive flooding on that segment. 808 The authentication methods discussed in [IGMPv3] will also 809 provide protection in this case. 811 - IGMP snooping switches which rely on the IP header of a 812 packet for their operation and which do not validate the 813 header checksum potentially will forward packets on the 814 wrong ports. Even though the IP headers are protected by 815 the Ethernet checksum this is a potential vulnerability. 817 - In IGMP, there is no mechanism for denying recipients 818 access to groups (i.e. no "exclude receiver" 819 functionality). Hence, apart from IP-level security 820 configuration outside the scope of IGMP, any multicast 821 stream may be received by any host without restriction. 823 Generally, IGMP snooping must be considered insecure due to 824 the issues above. However, none of the these issues are any 825 worse for IGMP snooping than for IGMP implementations in 826 general. 828 7. Acknowledgements 830 We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben 831 Carter, Paul Congdon, Toerless Eckert, Bill Fenner, Brian 832 Haberman, Edward Hilquist, Hugh Holbrook, Kevin Humphries, 833 Pekka Savola, Suzuki Shinsuke, Jaff Thomas, and Rolland Vida 834 for comments and suggestions on this document. 836 Furthermore, the following companies are acknowledged for 837 their contributions: 3Com, Alcatel, Cisco Systems, Enterasys 838 Networks, Hewlett-Packard, Vitesse Semiconductor Corporation. 839 The ordering of these names do not necessarily correspond to 840 the column numbers in the response table. 842 8. Authors' Addresses 844 Morten Jagd Christensen 845 Thrane & Thrane 846 Lundtoftegaardsvej 93 D 847 2800 Lyngby 848 email: mjc@tt.dk 850 Karen Kimball 851 Hewlett-Packard 852 8000 Foothills Blvd. 853 Roseville, CA 95747 854 email: karen.kimball@hp.com 856 Frank Solensky 857 Bluejavelin, Inc. 858 3 Dundee Park 859 Andover, MA 01810 860 email: solenskyf@acm.org 862 9. IETF IPR Statement 864 "The IETF takes no position regarding the validity or scope of 865 any intellectual property or other rights that might be 866 claimed to pertain to the implementation or use of the 867 technology described in this document or the extent to which 868 any license under such rights might or might not be available; 869 neither does it represent that it has made any effort to 870 identify any such rights. Information on the IETF's 871 procedures with respect to rights in standards-track and 872 standards-related documentation can be found in [RFC-2026]. 873 Copies of claims of rights made available for publication and 874 any assurances of licenses to be made available, or the result 875 of an attempt made to obtain a general license or permission 876 for the use of such proprietary rights by implementors or 877 users of this specification can be obtained from the IETF 878 Secretariat." 880 10. Full Copyright Statement 882 Copyright (C) The Internet Society (2003). All Rights 883 Reserved. 885 This document and translations of it may be copied and 886 furnished to others, and derivative works that comment on or 887 otherwise explain it or assist in its implementation may be 888 prepared, copied, published and distributed, in whole or in 889 part, without restriction of any kind, provided that the above 890 copyright notice and this paragraph are included on all such 891 copies and derivative works. However, this document itself 892 may not be modified in any way, such as by removing the 893 copyright notice or references to the Internet Society or 894 other Internet organizations, except as needed for the purpose 895 of developing Internet standards in which case the procedures 896 for copyrights defined in the Internet Standards process must 897 be followed, or as required to translate it into languages 898 other than English. 900 The limited permissions granted above are perpetual and will 901 not be revoked by the Internet Society or its successors or 902 assigns. 904 This document and the information contained herein is provided 905 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 906 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 907 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 908 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 909 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 910 PARTICULAR PURPOSE. 912 Acknowledgement: 914 Funding for the RFC Editor function is currently provided by 915 the Internet Society.