idnits 2.17.1 draft-ietf-magma-snoop-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1128. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 6 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 806: '...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 781 has weird spacing: '...rrected a ref...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 7007 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2026' is mentioned on line 17, but not defined == Missing Reference: 'PROXY' is mentioned on line 731, but not defined == Unused Reference: 'RFC3668' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 964, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-magma-mrdisc-03 ** Obsolete normative reference: RFC 2461 (ref. 'NDP') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: August 2005 K. Kimball 5 Category: Informational Hewlett-Packard 6 F. Solensky 7 Calix Networks 8 February 2005 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 By submitting this Internet-Draft, we certify that any applicable 36 patent or other IPR claims of which we are aware have been 37 disclosed, or will be disclosed, and any of which we become aware 38 will be disclosed, in accordance with RFC 3668 [IPR]. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). All rights reserved. 44 Abstract 46 This memo describes the recommendations for IGMP- and MLD-snooping 47 switches. These are based on best current practices for IGMPv2, 49 RFC DRAFT Considerations for IGMP and February 2005 50 MLD Snooping Switches 52 with further considerations for IGMPv3- and MLDv2-snooping. 53 Additional areas of relevance, such as link layer topology changes 54 and Ethernet-specific encapsulation issues, are also considered. 56 1. Introduction 58 The IEEE bridge standard [BRIDGE] specifies how LAN packets are 59 'bridged', or as is more commonly used today, switched between LAN 60 segments. The operation of a switch with respect to multicast 61 packets can be summarized as follows. When processing a packet 62 whose destination MAC address is a multicast address, the switch 63 will forward a copy of the packet into each of the remaining 64 network interfaces that are in the forwarding state in accordance 65 with [BRIDGE]. The spanning tree algorithm ensures that the 66 application of this rule at every switch in the network will make 67 the packet accessible to all nodes connected to the network. 69 This behaviour works well for broadcast packets that are intended 70 to be seen or processed by all connected nodes. In the case of 71 multicast packets, however, this approach could lead to less 72 efficient use of network bandwidth, particularly when the packet is 73 intended for only a small number of nodes. Packets will be flooded 74 into network segments where no node has any interest in receiving 75 the packet. While nodes will rarely incur any processing overhead 76 to filter packets addressed to unrequested group addresses, they 77 are unable to transmit new packets onto the shared media for the 78 period of time that the multicast packet is flooded. In general, 79 significant bandwidth can be wasted by flooding. 81 In recent years, a number of commercial vendors have introduced 82 products described as "IGMP snooping switches" to the market. 83 These devices do not adhere to the conceptual model that provides 84 the strict separation of functionality between different 85 communications layers in the ISO model, and instead utilize 86 information in the upper level protocol headers as factors to be 87 considered in processing at the lower levels. This is analogous to 88 the manner in which a router can act as a firewall by looking into 89 the transport protocol's header before allowing a packet to be 90 forwarded to its destination address. 92 In the case of IP multicast traffic, an IGMP snooping switch 93 provides the benefit of conserving bandwidth on those segments of 94 the network where no node has expressed interest in receiving 95 packets addressed to the group address. This is in contrast to 96 normal switch behavior where multicast traffic is typically 97 forwarded on all interfaces. 99 RFC DRAFT Considerations for IGMP and February 2005 100 MLD Snooping Switches 102 Many switch datasheets state support for IGMP snooping, but no 103 recommendations for this exist today. It is the authors' hope that 104 the information presented in this draft will supply this 105 foundation. 107 The recommendations presented here are based on the following 108 information sources: The IGMP specifications [RFC1112], [RFC2236] 109 and [IGMPv3], vendor-supplied technical documents [CISCO], bug 110 reports [MSOFT], discussions with people involved in the design of 111 IGMP snooping switches, MAGMA mailing list discussions, and on 112 replies by switch vendors to an implementation questionnaire. 114 Interoperability issues that arise between different versions of 115 IGMP are not the focus of this document. Interested readers are 116 directed to [IGMPv3] for a thorough description of problem areas. 118 The suggestions in this document are based on IGMP, which applies 119 only to IPv4. For IPv6, Multicast Listener Discovery [MLD] must be 120 used instead. Because MLD is based on IGMP, we do not repeat the 121 entire description and recommendations for MLD snooping switches. 122 Instead, we point out the few cases where there are differences 123 from IGMP. 125 Note that the IGMP snooping function should apply only to IPv4 126 multicasts. Other multicast packets, such as IPv6, might be 127 suppressed by IGMP snooping if additional care is not taken in the 128 implementation as mentioned in the recommendations section. It is 129 desired not to restrict the flow of non-IPv4 multicasts other than 130 to the degree which would happen as a result of regular bridging 131 functions. Likewise, MLD snooping switches are discouraged from 132 using topological information learned from IPv6 traffic to alter 133 the forwarding of IPv4 multicast packets. 135 2. IGMP Snooping Recommendations 137 The following sections list the recommendations for an IGMP 138 snooping switch. The recommendation is stated and is supplemented 139 by a description of a possible implementation approach. All 140 implementation discussions are examples only and there may well be 141 other ways to achieve the same functionality. 143 2.1. Forwarding rules 145 The IGMP snooping functionality is separated into a control section 146 (IGMP forwarding) and a data section (Data forwarding). 148 RFC DRAFT Considerations for IGMP and February 2005 149 MLD Snooping Switches 151 2.1.1. IGMP Forwarding Rules 153 1) A snooping switch should forward IGMP Membership Reports only 154 to those ports where multicast routers are attached. 155 Alternatively stated: a snooping switch should not forward IGMP 156 Membership Reports to ports on which only hosts are attached. 157 An administrative control may be provided to override this 158 restriction, allowing the report messages to be flooded to 159 other ports. 161 This is the main IGMP snooping functionality for the control 162 path. 164 Sending membership reports to other hosts can result, for 165 IGMPv1 and IGMPv2, in unintentionally preventing a host from 166 joining a specific multicast group. 168 When an IGMPv1 or IGMPv2 host receives a membership report for 169 a group address that it is intending to join, the host will 170 suppress its own membership report for the same group. This 171 join or message suppression is a requirement for IGMPv1 and 172 IGMPv2 hosts. However, if a switch does not receive a 173 membership report from the host it will not forward multicast 174 data to it. 176 This is not a problem in an IGMPv3-only network because there 177 is no suppression of IGMP Membership reports. 179 The administrative control allows IGMP Membership Report 180 messages to be processed by network monitoring equipment such 181 as packet analyzers or port replicators. 183 The switch supporting IGMP snooping must maintain a list of 184 multicast routers and the ports on which they are attached. 185 This list can be constructed in any combination of the 186 following ways: 188 a) This list should be built by the snooping switch sending 189 Multicast Router Solicitation messages as described in IGMP 190 Multicast Router Discovery [MRDISC]. It may also snoop 191 Multicast Router Advertisement messages sent by and to 192 other nodes. 194 b) The arrival port for IGMP Queries (sent by multicast 195 routers) where the source address is not 0.0.0.0. 197 The 0.0.0.0 address represents a special case where the 198 switch is proxying IGMP Queries for faster network 200 RFC DRAFT Considerations for IGMP and February 2005 201 MLD Snooping Switches 203 convergence, but is not itself the Querier. The switch 204 does not use its own IP address (even if it has one), 205 because this would cause the Queries to be seen as coming 206 from a newly elected Querier. The 0.0.0.0 address is used 207 to indicate that the Query packets are NOT from a multicast 208 router. 210 c) Ports explicitly configured by management to be IGMP- 211 forwarding ports, in addition to or instead of any of the 212 above methods to detect router ports. 214 2) IGMP networks may include devices which implement "proxy- 215 reporting", in which reports received from downstream hosts are 216 summarized and used to build internal membership states. Such 217 proxy-reporting devices may use the all-zeros address when 218 forwarding any summarized reports upstream. For this reason, 219 IGMP membership reports received by the snooping switch must 220 not be rejected because of a source IP address of 0.0.0.0. 222 3) The switch that supports IGMP snooping must flood all 223 unrecognized IGMP messages to all other ports and must not 224 attempt to make use of any information beyond the end of the 225 network layer header. 227 In addition, earlier versions of IGMP should interpret IGMP 228 fields as defined for their versions and must not alter these 229 fields when forwarding the message. When generating new 230 messages, a given IGMP version should set fields to the 231 appropriate values for its own version. If any fields are 232 reserved or otherwise undefined for a given IGMP version, the 233 fields should be ignored when parsing the message and must be 234 set to zeroes when new messages are generated by 235 implementations of that IGMP version. An exception may occur 236 if the switch is performing a spoofing function, and is aware 237 of the settings for new or reserved fields that would be 238 required to correctly spoof for a different IGMP version. 240 The reason to worry about these trivialities is that IGMPv3 241 overloads the old IGMP query message using the same type number 242 (0x11) but with an extended header. Therefore there is a risk 243 that IGMPv3 queries may be interpreted as older version queries 244 by, for example, IGMPv2 snooping switches. This has already 245 been reported [IETF56] and is discussed in section 2.2. 247 4) An IGMP snooping switch should be aware of link layer topology 248 changes caused by Spanning Tree operation. When a port is 249 enabled or disabled by Spanning Tree, a General Query may be 251 RFC DRAFT Considerations for IGMP and February 2005 252 MLD Snooping Switches 254 sent on all active non-router ports in order to reduce network 255 convergence time. Non-Querier switches should be aware of 256 whether the Querier is in IGMPv3 mode. If so, the switch should 257 not spoof any General Queries unless it is able to send an 258 IGMPv3 Query that adheres to the most recent information sent 259 by the true Querier. In no case should a switch introduce a 260 spoofed IGMPv2 Query into an IGMPv3 network, as this may create 261 excessive network disruption. 263 If the switch is not the Querier, it should use the 'all-zeros' 264 IP Source Address in these proxy queries (even though some 265 hosts may elect to not process queries with a 0.0.0.0 IP Source 266 Address). When such proxy queries are received, they must not 267 be included in the Querier election process. 269 5) An IGMP snooping switch must not make use of information in 270 IGMP packets where the IP or IGMP headers have checksum or 271 integrity errors. The switch should not flood such packets but 272 if it does, it should also take some note of the event (i.e., 273 increment a counter). These errors and their processing are 274 further discussed in [IGMPv3], [MLD] and [MLDv2]. 276 6) The snooping switch must not rely exclusively on the appearance 277 of IGMP Group Leave announcements to determine when entries 278 should be removed from the forwarding table. It should 279 implement a membership timeout mechanism such as the router- 280 side functionality of the IGMP protocol as described in the 281 IGMP and MLD specifications (See Normative Reference section 282 for IGMPv1-3 and MLDv1-2) on all its non-router ports. This 283 timeout value should be configurable. 285 2.1.2. Data Forwarding Rules 287 1) Packets with a destination IP address outside 224.0.0.X which 288 are not IGMP should be forwarded according to group-based port 289 membership tables and must also be forwarded on router ports. 291 This is the main IGMP snooping functionality for the data path. 293 One approach that an implementation could take would be to 294 maintain separate membership and multicast router tables in 295 software and then "merge" these tables into a forwarding cache. 297 2) Packets with a destination IP (DIP) address in the 224.0.0.X 298 range which are not IGMP must be forwarded on all ports. 300 This recommendation is based on fact that many host systems do 302 RFC DRAFT Considerations for IGMP and February 2005 303 MLD Snooping Switches 305 not send Join IP multicast addresses in this range before 306 sending or listening to IP multicast packets. Furthermore, 307 since the 224.0.0.X address range is defined as link-local (not 308 to be routed) it seems unnecessary to keep state for each 309 address in this range. Additionally, some routers operate in 310 the 224.0.0.X address range without issuing IGMP Joins, and 311 these applications would break if the switch were to prune them 312 due to not having seen a Join Group message from the router. 314 3) An unregistered packet is defined as an IPv4 multicast packet 315 with a destination address which does not match any of the 316 groups announced in earlier IGMP Membership Reports. 318 If a switch receives an unregistered packet, it must forward 319 that packet on all ports to which an IGMP router is attached. 320 A switch may default to forwarding unregistered packets on all 321 ports. Switches that do not forward unregistered packets to 322 all ports must include a configuration option to force the 323 flooding of unregistered packets on specified ports. 325 In an environment where IGMPv3 hosts are mixed with snooping 326 switches that do not yet support IGMPv3, the switch's failure 327 to flood unregistered streams could prevent v3 hosts from 328 receiving their traffic. Alternatively, in environments where 329 the snooping switch supports all of the IGMP versions that are 330 present, flooding unregistered streams may cause IGMP hosts to 331 be overwhelmed by multicast traffic, even to the point of not 332 receiving Queries and failing to issue new membership reports 333 for their own groups. 335 It is encouraged that snooping switches at least recognize and 336 process IGMPv3 Join Reports, even if this processing is limited 337 to the behavior for IGMPv2 Joins, i.e., is done without 338 considering any additional "include source" or "exclude source" 339 filtering. When IGMPv3 Joins are not recognized, a snooping 340 switch may incorrectly prune off the unregistered data streams 341 for the groups (as noted above); alternatively, it may fail to 342 add in forwarding to any new IGMPv3 hosts if the group has 343 previously been joined as IGMPv2 (because the data stream is 344 seen as already having been registered). 346 4) All non-IPv4 multicast packets should continue to be flooded 347 out all remaining ports in the forwarding state as per normal 348 IEEE bridging operations. 350 This recommendation is a result of the fact that groups made up 351 of IPv4 hosts and IPv6 hosts are completely separate and 352 distinct groups. As a result, information gleaned from the 354 RFC DRAFT Considerations for IGMP and February 2005 355 MLD Snooping Switches 357 topology between members of an IPv4 group would not be 358 applicable when forming the topology between members of an IPv6 359 group. 361 5) IGMP snooping switches may maintain forwarding tables based on 362 either MAC addresses or IP addresses. If a switch supports 363 both types of forwarding tables then the default behavior 364 should be to use IP addresses. IP address based forwarding is 365 preferred because the mapping between IP multicast addresses 366 and link-layer multicast addresses is ambiguous. In the case 367 of Ethernet, there is a multiplicity of 1 Ethernet address to 368 32 IP addresses [RFC1112]. 370 6) Switches which rely on information in the IP header should 371 verify that the IP header checksum is correct. If the checksum 372 fails, the information in the packet must not be incorporated 373 into the forwarding table. Further, the packet should be 374 discarded. 376 7) When IGMPv3 "include source" and "exclude source" membership 377 reports are received on shared segments, the switch needs to 378 forward the superset of all received membership reports onto 379 the shared segment. Forwarding of traffic from a particular 380 source S to a group G must happen if at least one host on the 381 shared segment reports an IGMPv3 membership of the type 382 INCLUDE(G, Slist1) or EXCLUDE(G, Slist2) where S is an element 383 of Slist1 and not an element of Slist2. 385 The practical implementation of the (G,S1,S2,...) based data 386 forwarding tables are not within the scope of this document. 387 However, one possibility is to maintain two (G,S) forwarding 388 lists: one for the INCLUDE filter where a match of a specific 389 (G,S) is a requirement before forwarding will happen, and one 390 for the EXCLUDE filter where a match of a specific (G,S) will 391 result in no forwarding. 393 2.2. IGMP snooping-related problems 395 A special problem arises in networks consisting of IGMPv3 routers 396 as well as IGMPv2 and IGMPv3 hosts interconnected by an IGMPv2 397 snooping switch as recently reported [IETF56]. The router will 398 continue to maintain IGMPv3 even in the presence of IGMPv2 hosts, 399 and thus the network will not converge on IGMPv2. But it is likely 400 that the IGMPv2 snooping switch will not recognize or process the 401 IGMPv3 membership reports. Groups for these unrecognized reports 402 will then either be flooded (with all of the problems that may 404 RFC DRAFT Considerations for IGMP and February 2005 405 MLD Snooping Switches 407 create for hosts in a network with a heavy multicast load) or 408 pruned by the snooping switch. 410 Therefore, it is recommended that in such a network, the multicast 411 router be configured to use IGMPv2. If this is not possible, and if 412 the snooping switch cannot recognize and process the IGMPv3 413 membership reports, it is instead recommended that the switch's 414 IGMP snooping functionality be disabled, as there is no clear 415 solution to this problem. 417 3. IPv6 Considerations 419 In order to avoid confusion, the previous discussions have been 420 based on the IGMP protocol which only applies to IPv4 multicast. 421 In the case of IPv6 most of the above discussions are still valid 422 with a few exceptions which we will describe here. 424 The control and data forwarding rules in the IGMP section can, with 425 a few considerations, also be applied to MLD. This means that the 426 basic functionality of intercepting MLD packets, and building 427 membership lists and multicast router lists, is the same as for 428 IGMP. 430 In IPv6, the data forwarding rules are more straight forward 431 because MLD is mandated for addresses with scope 2 (link-scope) or 432 greater. The only exception is the address FF02::1 which is the 433 all hosts link-scope address for which MLD messages are never sent. 434 Packets with the all hosts link-scope address should be forwarded 435 on all ports. 437 MLD messages are also not sent regarding groups with addresses in 438 the range FF00::/15 (which encompasses both the reserved FF00::/16 439 and node-local FF01::/16 IPv6 address spaces). These addresses 440 should never appear in packets on the link. 442 Equivalent to the IPv4 behaviors regarding the null IP Source 443 address, MLD membership reports must not be rejected by an MLD 444 snooping switch because of an unspecified IP source address (::). 445 Additionally, if a non-Querier switch spoofs any General Queries 446 (as addressed in Section 2.1 above, for Spanning Tree topology 447 changes), the switch should use the null IP source address (::) 448 when sending said queries. When such proxy queries are received, 449 they must not be included in the Querier election process. 451 The three major differences between IPv4 and IPv6 in relation to 452 multicast are: 454 RFC DRAFT Considerations for IGMP and February 2005 455 MLD Snooping Switches 457 - The IPv6 protocol for multicast group maintenance is called 458 Multicast Listener Discovery [MLDv2]. MLDv2 uses ICMPv6 message 459 types instead of IGMP message types. 461 - The RFCs [IPV6-ETHER] and [IPV6-FDDI] describe how 24 of the 128 462 bit DIP address are used to form the 48 bit DMAC addresses for 463 multicast groups, while [IPV6-TOKEN] describes the mapping for 464 token ring DMAC addresses by using three low-order bits. The 465 specification [IPV6-1394] makes use of a 6 bit channel number. 467 - Multicast router discovery is accomplished using Neighbor 468 Discovery Protocol [NDP] for IPv6. NDP uses ICMPv6 message 469 types. 471 The IPv6 packet header does not include a checksum field. 472 Nevertheless, the switch should detect other packet integrity 473 issues such as address version and payload length consistencies if 474 possible. When the snooping switch detects such an error, it must 475 not include information from the corresponding packet in the MLD 476 forwarding table. The forwarding code should instead drop the 477 packet and take further reasonable actions as advocated above. 479 The fact that MLDv2 is using ICMPv6 adds new requirements to a 480 snooping switch because ICMPv6 has multiple uses aside from MLD. 481 This means that it is no longer sufficient to detect that the next- 482 header field of the IP header is ICMPv6 in order to identify 483 packets relevant for MLD snooping. A software-based implemention 484 which treats all ICMPv6 packets as candidates for MLD snooping 485 could easily fill its receive queue and bog down the CPU with 486 irrelevant packets. This would prevent the snooping functionality 487 from performing its intended purpose and the non-MLD packets 488 destined for other hosts could be lost. 490 A solution is either to require that the snooping switch looks 491 further into the packets, or to be able to detect a multicast DMAC 492 address in conjunction with ICMPv6. The first solution is 493 desirable when a configuration option allows the administrator to 494 specify which ICMPv6 message types should trigger a CPU redirect 495 and which should not. The reason is that a hardcoding of message 496 types is inflexible for the introduction of new message types. The 497 second solution introduces the risk that new protocols which use 498 ICMPv6 and multicast DMAC addresses could be incorrectly identified 499 as MLD. It is suggested that solution one is preferred when the 500 configuration option is provided. If this is not the case, then 501 the implementor should seriously consider making it available since 502 Neighbor Discovery messages would be among those that fall into 503 this false positive case and are vital for the operational 504 integrity of IPv6 networks. 506 RFC DRAFT Considerations for IGMP and February 2005 507 MLD Snooping Switches 509 The mapping from IP multicast addresses to multicast DMAC addresses 510 introduces a potentially enormous overlap. The structure of an 511 IPv6 multicast address is shown in the figure below. As a result, 512 there are 2 ** (112 - 32), or more than 1.2e24 unique DIP addresses 513 which map into a single DMAC address in Ethernet and FDDI. This 514 should be compared to 2**5 in the case of IPv4. 516 Initial allocation of IPv6 multicast addresses as described in 517 [RFC3307], however, cover only the lower 32 bits of group ID. 518 While this reduces the problem of address ambiguity to group IDs 519 with different flag and scope values for now, it should be noted 520 that the allocation policy may change in the future. Because of 521 the potential overlap it is recommended that IPv6 address based 522 forwarding is preferred to MAC address based forwarding. 524 | 8 | 4 | 4 | 112 bits | 525 +--------+----+----+---------------------------------------+ 526 |11111111|flgs|scop| group ID | 527 +--------+----+----+---------------------------------------+ 529 4. IGMP Questionnaire 531 As part of this work the following questions were asked both on the 532 MAGMA discussion list and sent to known switch vendors implementing 533 IGMP snooping. The individual contributions have been anonymized 534 upon request and do not necessarily apply to all of the vendors' 535 products. 537 The questions were: 539 Q1 Does your switches perform IGMP Join aggregation? In other 540 words, are IGMP joins intercepted, absorbed by the 541 hardware/software so that only one Join is forwarded to the 542 querier? 544 Q2 Is multicast forwarding based on MAC addresses? Would 545 datagrams addressed to multicast IP addresses 224.1.2.3 and 546 239.129.2.3 be forwarded on the same ports-groups? 548 Q3 Is it possible to forward multicast datagrams based on IP 549 addresses (not routed)? In other words, could 224.1.2.3 and 550 239.129.2.3 be forwarded on different port-groups with 551 unaltered TTL? 553 Q4 Are multicast datagrams within the range 224.0.0.1 to 554 224.0.0.255 forwarded on all ports whether or not IGMP Joins 555 have been sent? 557 RFC DRAFT Considerations for IGMP and February 2005 558 MLD Snooping Switches 560 Q5 Are multicast frames within the MAC address range 561 01:00:5E:00:00:01 to 01:00:5E:00:00:FF forwarded on all ports 562 whether or not IGMP joins have been sent? 564 Q6 Does your switch support forwarding to ports on which IP 565 multicast routers are attached in addition to the ports where 566 IGMP Joins have been received? 568 Q7 Is your IGMP snooping functionality fully implemented in 569 hardware? 571 Q8 Is your IGMP snooping functionality partly software 572 implemented? 574 Q9 Can topology changes (for example spanning tree configuration 575 changes) be detected by the IGMP snooping functionality so that 576 for example new queries can be sent or tables can be updated to 577 ensure robustness? 579 The answers were: 581 ---------------------------+-----------------------+ 582 | Switch Vendor | 583 ---------------------------+---+---+---+---+---+---+ 584 | 1 | 2 | 3 | 4 | 5 | 6 | 585 ---------------------------+---+---+---+---+---+---+ 586 Q1 Join aggregation | x | x | x | | x | x | 587 Q2 Layer-2 forwarding | x | x | x | x |(1)| | 588 Q3 Layer-3 forwarding |(1)| |(1)| |(1)| x | 589 Q4 224.0.0.X aware |(1)| x |(1)|(2)| x | x | 590 Q5 01:00:5e:00:00:XX aware | x | x | x |(2)| x | x | 591 Q6 Mcast router list | x | x | x | x | x | x | 592 Q7 Hardware implemented | | | | | | | 593 Q8 Software assisted | x | x | x | x | x | x | 594 Q9 Topology change aware | x | x | x | x | |(2)| 595 ---------------------------+---+---+---+---+---+---+ 596 x Means that the answer was Yes. 597 (1) In some products (typically high-end) Yes; in others No. 598 (2) Not at the time that the questionnaire was received 599 but expected in the near future. 601 Revision History 603 [To RFC Editor: This section is to be removed at publication time] 605 RFC DRAFT Considerations for IGMP and February 2005 606 MLD Snooping Switches 608 This section, while incomplete, is provided as a convenience to the 609 working group members. It will be removed when the document is 610 released in its final form. 612 draft-ietf-magma-snoop-12.txt: January 2005 614 Editorial changes only: 616 Update document references and author address; IPR and 617 disclaimer statements to adhere to RFC3668 requirements. 619 draft-ietf-magma-snoop-11.txt: April 2004 621 Editorial changes only: 623 Remove reference to IGMP/MLD Proxy (draft-ietf-magma- 624 proxy-06.txt) to avoid perception of content dependency. 626 Updated references to reflect current revisions, author 627 address. 629 draft-ietf-magma-snoop-10.txt: October 2003 631 The changes in this version are the result of the IESG review. 633 Substantial comments 635 The security considerations section was found a little 636 too brief. It has now been extended. 638 Editorial Changes 640 Removed reference RFC2375, using RFC3307 instead. New 641 author address information. 643 draft-ietf-magma-snoop-09.txt: August 2003 645 The changes in this version are the result of the AD review 646 following the WG chair review. 648 Substantial comments 650 There were no substantial technical comments, but a list 651 of suggested wordings and clarifications to improve the 652 readability and RFC conformance of the draft. 654 Reference in Abstract removed. Improved wording in 655 Introduction. 657 RFC DRAFT Considerations for IGMP and February 2005 658 MLD Snooping Switches 660 Improved wording in recommendations section, clarified 661 integrity checking for IPv6, removed security issues 662 which were really IGMP/MLD security issues. 664 Editorial Changes 666 Author information changes, TOC added, fixed a wrong 667 indentation following section 5. 669 draft-ietf-magma-snoop-08.txt: June 2003 671 The changes in this version are the result of the WG chair 672 review following the second WG last call. The last call itself 673 did not result in further comments. 675 Substantial comments 677 Requirements have now been replaced with Recommendations 678 throughout the draft, which is more appropriate for an 679 Informational draft. 681 Clarifications regarding the overloading of the IGMP 682 query message in section 2.1.1. 684 Clarification regarding the data forwarding in the case 685 of INCLUDE/EXCLUDE filters. 687 More detail added on the special case of Source IP 688 address 0.0.0.0. 690 Editorial Changes 692 Moved Data Forwarding recommendation up as first bullet 693 as it really is the main recommendation. 695 Added a more suitable reference for the Thaler briefing 696 at the 56'th IETF meeting. Hopefully it will become a 697 valid link sometime soon. 699 Moved reference to RFC2375 to the Informative section. 701 draft-ietf-magma-snoop-07.txt: May 2003 703 The current version reflects comments made at the 56'th IETF 704 meeting and from the previous WG last call. The majority of 705 changes appear in sections 2.1 and 2.2, and even the changes 706 here are in reality not substantial. 708 RFC DRAFT Considerations for IGMP and February 2005 709 MLD Snooping Switches 711 Substantial comments 713 Section 2.1.1.(4): Changed wording for IGMP forwarding 714 section on when spoofing of General Queries should occur. 715 Added description of how to avoid IGMP version 716 incompatibility problems when doing said spoofing. 718 Section 2.1.2.(3): Clarification of incompatibility 719 problems in mixed IGMPv2 and IGMPv3 networks. Added 720 recommendation for switches to implement some level of 721 IGMPv3 Join recognition to reduce these problems. 723 Section 2.2: Advice following the briefing [IETF56], that 724 in some cases disabling IGMP snooping functionality is 725 the only 'solution' 727 Section 6, IPv6 Considerations: added descriptions of 728 behavior involving the IPv6 version of the null IP Source 729 Address (to parallel the IPv4 behaviors). 731 Added reference to [IGMPv3] in stead of [PROXY] for group 732 membership maintenance and timeout. 734 Editorial Changes 736 Really minor stuff such as change of authors email 737 address, addition of references, draft name increment and 738 date changes. 740 draft-ietf-magma-snoop-06.txt: March 2003 742 Changes in response to comments made during WG last call and 743 assessment by the WG chairs: 745 Substantial comments 747 Clarification in IGMP forwarding section on the 748 acceptance of membership reports with source IP address 749 0.0.0.0 as being a switch recommendation. 751 Section 2.1.1.(4): Allow the router port to be excluded 752 from the General Query messages 754 Section 2.1.1.(6): Replace description of timing out 755 older entries with a reference to IGMP/MLD Proxying. 757 Section 2.1.2.(3): Replaced description of timeout 758 mechanism with a reference to IGMP/MLD. 760 RFC DRAFT Considerations for IGMP and February 2005 761 MLD Snooping Switches 763 Section 2.1.2.(4) Expanded rationale to discourage 764 leaking info between IPv4 and IPv6 groups. 766 Section 3: more strongly encourage the use of a 767 configuration option for selection of ICMPv6 message 768 types. 770 Editorial comments. 772 Hyphenation problem resolved for groff by setting then ms 773 HY register to zero, disabling all forms for the entire 774 document 775 (".hy 0" and ".nr" worked only as far as the following 776 ms macro). 778 Sections moved around - again - to comply with 779 rfc2223bis-03 draft. Added copyright notice after memo 780 status. Removed table of contents as the draft is fairly 781 short. Corrected a reference typo. 783 Section 2.1.2.(3): Requirement and rationale broken into 784 separate paragraphs. 786 Added references to other IPv6 encapsulation documents, 788 Corrected estimates for MAC address collisions for 789 Ethernet and FDDI: both specification take the low-order 790 four (not six) bytes from the IPv6 group addresses. 792 draft-ietf-magma-snoop-05.txt: January 2003 794 Changes in wording of IGMP forwarding rule 6) and Data 795 forwarding rule 7). Corrections in the references section. 797 Apart from above, no substantial changes has occured in the 798 document. Several editorial changes, however, have been made 799 to comply with the rfc editors requirements: 801 References splitted in normative and informative sections, 802 other related references added. 804 Abstract shortened. 806 Changed all occurances of MUST, MAY etc. to lowercase to 807 reflect that this is not a standards track document. 809 Sections moved around so they appear in the required order. 811 RFC DRAFT Considerations for IGMP and February 2005 812 MLD Snooping Switches 814 draft-ietf-magma-snoop-04.txt: November 2002 816 Editorial changes only. 818 draft-ietf-magma-snoop-03.txt: October 2002 820 IGMP Forwarding rules: 821 Add references to and become consistant with the current 822 IGMP proxy draft, 824 Unrecognized IGMP packets should not be ignored because 825 "mbz" fields are not zero since packets from future 826 versions are expected to maintain consistency. 828 Corrections related to IGMP Querier election process. 830 Add clarification to how lists of router ports may be 831 assembled. 833 Data Forwarding rules: 834 Added discussion of the problems for different IGMP 835 environments in choosing whether to flood or to prune 836 unregistered multicasts. 838 Added refinements for how to handle NON-IPv4 multicasts, 839 to keep IGMP-snooping functionality from interfering with 840 IPv6 and other multicast traffic. Any filtering for non- 841 IPv4 multicasts should be based on bridge behavior and 842 not IGMP snooping behavior. 844 IGMP snooping related problems: 845 Fixed description of interoperability issues in 846 environments with v3 routers and hosts, and v2 snooping 847 switches. 849 Added discussion of the IGMPv3 "include source" and 850 "exclude source" options, and the inability to support 851 them on shared segments. 853 IPv6 Considerations: 854 Clarifications regarding address ranges FF00::, FF01:: 855 and all hosts FF02::1 in relation to data forwarding. 857 draft-ietf-magma-snoop-02.txt: June 2002 859 Status section removes document history; moved into this 860 section instead. 862 RFC DRAFT Considerations for IGMP and February 2005 863 MLD Snooping Switches 865 Introduction restores text from the -00 revision that 866 describes snooping and its goals 868 IGMP flooding rules eased, allowing management option to 869 broaden beyond "routers only". 871 Removed a should/MAY inconsistancy between IPv4 Forwarding and 872 IPv6 processing of checksums. 874 IGMP Forwarding Rules: clarify text describing processing of 875 non-zero reserved fields. 877 Data Forwarding Rules, item 3 is changed from "MUST forward to 878 all ports" to "MAY"; item 4 default changes from "MUST" to 879 "should use network addresses". 881 Added two sets of additional responses to the questionnaire 882 and text indicating that responses don't cover all products. 884 Removed (commented out) description of IPR issues: IESG is 885 aware of them. 887 draft-ietf-magma-snoop-01.txt: January 2002 889 Extensive restructuring of the original text. 891 draft-ietf-idmr-snoop-01.txt: 2001 893 Added several descriptions of cases where IGMP snooping 894 implementations face problems. Also added several network 895 topology figures. 897 draft-ietf-idmr-snoop-00.txt: 2001 899 Initial snooping draft. An overview of IGMP snooping and the 900 problems to be solved. 902 5. References 904 5.1. Normative References 906 [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" 908 [IGMPv3] Cain, B., "Internet Group Management Protocol, Version 909 3", RFC3376, October 2002. 911 RFC DRAFT Considerations for IGMP and February 2005 912 MLD Snooping Switches 914 [IPV6-1394] Fujisawa, K. and Onoe, A., "Transmission of IPv6 915 Packets over IEEE 1394 Networks", RFC3146, October 916 2001. 918 [IPV6-ETHER] Crawford, M., "Transmission of IPv6 Packets over 919 Ethernet Networks", RFC2464, December 1998. 921 [IPV6-FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 922 Networks", RFC2467, December 1998. 924 [IPV6-TOKEN] Crawford, M., Narten, T. and Thomas, S., "Transmission 925 of IPv6 Packets over Token Ring Networks", RFC2470, 926 December 1998. 928 [MLD] Deering, S., Fenner, B. and Haberman, B. "Multicast 929 Listener Discovery (MLD) for IPv6", RFC2710, October 930 1999. 932 [MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery 933 Version 2 (MLDv2) for IPv6", RFC3810, June 2004. 935 [MRDISC] Haberman, B. and Martin, J. "Multicast Router 936 Discovery", draft-ietf-magma-mrdisc-03.txt, September 937 2004. 939 [NDP] Narten, T., Nordmark, E. and Simpson, W., "Neighbor 940 Discovery for IP Version 6 {IPv6)", RFC2461, December 941 1998. 943 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 944 RFC1112, August 1989. 946 [RFC2236] Fenner, W., "Internet Group Management Protocol, 947 Version 2", RFC2236, November 1997. 949 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 950 Multicast Addresses", RFC3307, August 2002. 952 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 953 Technology", RFC3668, February 2004. 955 5.2. Informative References 957 [CISCO] 958 Cisco Tech Notes, "Multicast In a Campus Network: CGMP and 959 IGMP snooping", http://www.cisco.com/warp/public/473/22.html 961 RFC DRAFT Considerations for IGMP and February 2005 962 MLD Snooping Switches 964 [IANA] Internet Assigned Numbers Authority, "Internet 965 Multicast Addresses", 966 http://www.iana.org/assignments/multicast-addresses 968 [IETF56] Briefing by Dave Thaler, Microsoft, presented to the 969 MAGMA WG at the 56'th IETF meeting in San Francisco, 970 http://www.ietf.org/proceedings/03mar/index.html 972 [MSOFT] Microsoft support article Q223136, "Some LAN Switches 973 with IGMP Snooping Stop Forwarding Multicast Packets 974 on RRAS Startup", 975 http://support.microsoft.com/support/articles/Q223/1/36.ASP 977 6. Security Considerations 979 Under normal network operation, the snooping switch is expected to 980 improve overall network performance by limiting the scope of 981 multicast flooding to a smaller portion of the local network. In 982 the event of forged IGMP messages, the benefits of using a snooping 983 switch might be reduced or eliminated. 985 Security considerations for IGMPv3 at the network layer of the 986 protocol stack are described in [IGMPv3]. The introduction of IGMP 987 snooping functionality does not alter the handling of multicast 988 packets by the router as it does not make use of link layer 989 information. 991 There are, however, changes in the way that the IGMP snooping 992 switch handles multicast packets within the local network. In 993 particular: 995 - A Query message with a forged source address which is less than 996 that of the current Querier could cause snooping switches to 997 forward subsequent Membership reports to the wrong network 998 interface. It is for this reason that IGMP Membership Reports 999 should be sent to all multicast routers as well as the current 1000 Querier. 1002 - It is possible for a host on the local network to generate 1003 Current-State Report Messages that would cause the switch to 1004 incorrectly believe that there is a multicast listener on the 1005 same network segment as the originator of the forged message. 1006 This will cause unrequested multicast packets to be forwarded 1007 into the network segments between the source and the router. 1008 If the router requires that all Multicast Report messages be 1010 RFC DRAFT Considerations for IGMP and February 2005 1011 MLD Snooping Switches 1013 authenticated as described in section 9.4 of [IGMPv3], it will 1014 discard the forged Report message from the host inside the 1015 network in the same way that it would discard one which 1016 originates from a remote location. It is worth noting that if 1017 the router accepts unauthenticated Report messages by virtue of 1018 them having arrived over a network interface associated with 1019 the internal network, investigating the affected network 1020 segments will quickly narrow the search for the source of the 1021 forged messages. 1023 - As noted in [IGMPv3], there is little motivation for an 1024 attacker to forge a Membership report message since joining a 1025 group is generally an unprivileged operation. The sender of 1026 the forged Membership report will be the only recipient of the 1027 multicast traffic to that group. This is in contrast to a 1028 shared LAN segment (HUB) or network without snooping switches, 1029 where all other hosts on the same segment would be unable to 1030 transmit when the network segment is flooding the unwanted 1031 traffic. 1033 The worst case result for each attack would remove the performance 1034 improvements that the snooping functionality would otherwise 1035 provide. It would, however, be no worse than that experienced on a 1036 network with switches that do not perform multicast snooping. 1038 7. Acknowledgements 1040 We would like to thank Martin Bak, Les Bell, Yiqun Cai, Ben Carter, 1041 Paul Congdon, Toerless Eckert, Bill Fenner, Brian Haberman, Edward 1042 Hilquist, Hugh Holbrook, Kevin Humphries, Isidor Kouvelas, Pekka 1043 Savola, Suzuki Shinsuke, Jaff Thomas, Rolland Vida, and Margaret 1044 Wasserman for comments and suggestions on this document. 1046 Furthermore, the following companies are acknowledged for their 1047 contributions: 3Com, Alcatel, Cisco Systems, Enterasys Networks, 1048 Hewlett-Packard, Vitesse Semiconductor Corporation, Thrane & Thrane 1049 The ordering of these names do not necessarily correspond to the 1050 column numbers in the response table. 1052 RFC DRAFT Considerations for IGMP and February 2005 1053 MLD Snooping Switches 1055 8. Authors' Addresses 1057 Morten Jagd Christensen 1058 Thrane & Thrane 1059 Lundtoftegaardsvej 93 D 1060 2800 Lyngby 1061 DENMARK 1062 email: mjc@tt.dk 1064 Karen Kimball 1065 Hewlett-Packard 1066 8000 Foothills Blvd. 1067 Roseville, CA 95747 1068 USA 1069 email: karen.kimball@hp.com 1071 Frank Solensky 1072 Calix Networks 1073 43 Nanog Park 1074 Acton, MA 01720 1075 USA 1076 email: frank.solensky@calix.com 1078 9. IETF IPR Statement 1080 "The IETF takes no position regarding the validity or scope of any 1081 intellectual property or other rights that might be claimed to 1082 pertain to the implementation or use of the technology described in 1083 this document or the extent to which any license under such rights 1084 might or might not be available; neither does it represent that it 1085 has made any effort to identify any such rights. Information on 1086 the IETF's procedures with respect to rights in standards-track and 1087 standards-related documentation can be found in [RFC-2026]. Copies 1088 of claims of rights made available for publication and any 1089 assurances of licenses to be made available, or the result of an 1090 attempt made to obtain a general license or permission for the use 1091 of such proprietary rights by implementors or users of this 1092 specification can be obtained from the IETF Secretariat." 1094 10. Full Copyright Statement 1096 Copyright (C) The Internet Society (2005). This document is 1097 subject to the rights, licenses and restrictions contained in BCP 1098 78, and except as set forth therein, the authors retain all their 1099 rights. 1101 RFC DRAFT Considerations for IGMP and February 2005 1102 MLD Snooping Switches 1104 This document and translations of it may be copied and furnished to 1105 others, and derivative works that comment on or otherwise explain 1106 it or assist in its implementation may be prepared, copied, 1107 published and distributed, in whole or in part, without restriction 1108 of any kind, provided that the above copyright notice and this 1109 paragraph are included on all such copies and derivative works. 1110 However, this document itself may not be modified in any way, such 1111 as by removing the copyright notice or references to the Internet 1112 Society or other Internet organizations, except as needed for the 1113 purpose of developing Internet standards in which case the 1114 procedures for copyrights defined in the Internet Standards process 1115 must be followed, or as required to translate it into languages 1116 other than English. 1118 The limited permissions granted above are perpetual and will not be 1119 revoked by the Internet Society or its successors or assigns. 1121 This document and the information contained herein are provided on 1122 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1123 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1124 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1125 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1126 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1127 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1128 PARTICULAR PURPOSE. 1130 Acknowledgement: 1132 Funding for the RFC Editor function is currently provided by the 1133 Internet Society. 1135 RFC DRAFT Considerations for IGMP and February 2005 1136 MLD Snooping Switches 1138 Table of Contents 1140 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1141 2. IGMP Snooping Recommendations . . . . . . . . . . . . . . . 3 1142 2.1. Forwarding rules . . . . . . . . . . . . . . . . . . . . . 3 1143 2.1.1. IGMP Forwarding Rules . . . . . . . . . . . . . . . . . 4 1144 2.1.2. Data Forwarding Rules . . . . . . . . . . . . . . . . . 6 1145 2.2. IGMP snooping-related problems . . . . . . . . . . . . . . 8 1146 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 9 1147 4. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . 11 1148 4. Revision History . . . . . . . . . . . . . . . . . . . . . . 12 1149 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 1150 5.1. Normative References . . . . . . . . . . . . . . . . . . . 18 1151 5.2. Informative References . . . . . . . . . . . . . . . . . . 19 1152 6. Security Considerations . . . . . . . . . . . . . . . . . . 20 1153 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 1154 8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 21 1155 9. IETF IPR Statement . . . . . . . . . . . . . . . . . . . . . 22 1156 10. Full Copyright Statement . . . . . . . . . . . . . . . . . 22 1158 [To RFC Editor: The TOC page is to be moved to page 2 at 1159 publication time ] 1161 [To RFC Editor: Page renumbering in TOC and in document will be 1162 necessary ]