idnits 2.17.00 (12 Aug 2021) /tmp/idnits56109/draft-ietf-magma-snoop-00.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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 16 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 312: '... MUST NOT send Queries....' RFC 2119 keyword, line 458: '...ing devices. Keywords as MUST, SHOULD,...' RFC 2119 keyword, line 459: '... MUST NOT etc. are suggestions only....' RFC 2119 keyword, line 461: '...ets with IP-PROTO = 2) SHOULD be redi-...' RFC 2119 keyword, line 465: '...support for IGMP snooping MUST forward...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 63 has weird spacing: '...rder to minim...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'MLDv2' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'RFC2236' is defined on line 748, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BRIDGE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CISCO' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' == Outdated reference: draft-ietf-idmr-igmp-v3 has been published as RFC 3376 == Outdated reference: draft-vida-mld-v2 has been published as RFC 3810 == Outdated reference: A later version (-10) exists of draft-ietf-idmr-igmp-mrdisc-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'MSOFT' ** Downref: Normative reference to an Informational RFC: RFC 2375 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MAGMA Working Group M. Christensen 3 Internet Draft Vitesse 4 October 2001 F. Solensky 5 Expiration Date: April 2001 Gotham Networks 7 IGMP and MLD snooping switches 8 10 Status of this Memo 12 This document is the successor of draft-ietf-idmr-snoop-01 which was 13 presented at the 51'st IETF in London. Since then IGMP snooping has 14 been rechartered to belong to the MAGMA working group. The main 15 differences between this and previous version are: Responses to IGMP 16 questionnaire from switch vendors, IPR section, new draft filename. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026 [RFC2026]. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This memo describes the interoperability problems and issues that can 39 arise when a mixed deployment of IGMPv3 and IGMPv2 capable hosts and 40 routers are interconnected by a switch with IGMP snooping 41 capabilities. It is intended as an accompanying document to the 42 IGMPv3 and MLDv2 specifications. 44 The memo contains a brief IGMP walk through followed by a description 45 of the IGMP snooping functionality. Specific examples are given 46 which are all based on Ethernet as the link layer protocol. MLDv2 for 48 RFC DRAFT October 2001 50 IPv6 is discussed. Finally recommendations are given for the 51 behavior of IGMP snooping switches. The memo is aiming for BCP or 52 Informational status. 54 The purpose of this document is twofold: 56 - We want to summarize IGMP snooping induced problems and best cur- 57 rent solutions. We hope that a description of IGMP snooping will 58 be of aid to the IETF when standardizing new protocols and behav- 59 iors within this scope. 61 - We also hope to bring this work to the attention of switch ven- 62 dors, typically active within the IEEE community but perhaps not 63 within IETF, in order to minimize protocol interoperability 64 problems in the future. 66 1. Introduction 68 In recent years, a number of commercial vendors have introduced prod- 69 ucts described as "IGMP snooping switches" to the market. These 70 devices do not adhere to the conceptual model that provides the 71 strict separation of functionality between different communications 72 layers in the ISO model and instead utilizes information in the upper 73 level protocol headers as factors to be considered in the processing 74 at the lower levels. This is analogous to the manner in which a 75 router can act as a firewall by looking into the transport protocol's 76 header before allowing a packet to be forwarded to its destination 77 address. 79 In the case of multicast traffic, an IGMP snooping switch provides 80 the benefit of conserving bandwidth on those segments of the network 81 where no node has expressed interest in receiving packets addressed 82 to the group address. 84 The discussions in this document are based on IGMP which applies to 85 IPv4 only. For IPv6 we must use MLD instead. Because MLD is based on 86 IGMP with only a few differences these discussions also apply to 87 IPv6. 89 2. IGMP snooping overview 91 For a full description of IGMP we refer to [IGMPv3], however, IGMP 92 operation is summarized in the following: 94 RFC DRAFT October 2001 96 * Hosts send IGMP Membership Report messages to inform neighboring 97 routers that they wish to join a specific IP multicast group. 99 * IGMPv3 Membership Reports may be qualified with a list of allowed 100 or forbidden source addresses. 102 * Routers periodically send IGMP Query messages to hosts in order 103 to maintain group membership state information. These queries 104 can be either general or group specific queries. 106 * Hosts respond to queries with Membership Reports. 108 * Hosts running either IGMPv2 or IGMPv3 may also send a Leave Group 109 message to routers to withdraw from the group. 111 A traditional Ethernet network may be separated into different net- 112 work segments to prevent placing too many devices onto the same 113 shared media. These segments are connected by bridges and switches. 114 When a packet with a broadcast or multicast destination address is 115 received, the switch will forward a copy into each of the remaining 116 network segments in accordance with the IEEE MAC bridge standard 117 [BRIDGE]. Eventually, the packet is made accessible to all nodes 118 connected to the network. 120 This approach works well for broadcast packets that are intended to 121 be seen or processed by all connected nodes. In the case of multi- 122 cast packets, however, this approach could lead to less efficient use 123 of network bandwidth, particularly when the packet is intended for 124 only a small number of nodes. Packets will be flooded into network 125 segments where no node has any interest in receiving the packet. 126 While nodes will rarely incur any processing overhead to filter pack- 127 ets addressed to unrequested group addresses, they are unable to 128 transmit new packets onto the shared media for the period of time 129 that the multicast packet is flooded. The problem of wasting band- 130 width is even worse when the LAN segment is not shared, for example 131 in Full Duplex links. Full Duplex is standard today for most 132 switches operating at 1Gbps, and it will be standard for 10Gbps eth- 133 ernet too. In this case the wasted bandwidth is proportional to the 134 number of attached nodes. 136 Allowing switches to snoop IGMP packets is a creative effort to solve 137 this problem. The switch uses the information in the IGMP packets as 138 they are being forwarded throughout the network to determine which 139 segments should receive packets directed to the group address. 141 IGMP snooping is being implemented slightly different by different 142 switch vendors. We will not address specific implementations here as 143 documentation is not widely available. For details of one 145 RFC DRAFT October 2001 147 implementation we refer to [CISCO]. 149 In the following we will describe problems in relation to IGMP snoop- 150 ing with the following constraints, which we believe are the most 151 common cases. 153 1. Group membership is based on multicast MAC addresses only. 155 2. Forwarding is based on a 'list' of member ports for each sup- 156 ported multicast group. 158 3. The switch is equipped with a CPU for maintaining group member- 159 ship information. 161 Constraint 3 above is not a strict requirement as IGMP snooping could 162 be accomplished entirely in hardware. However, when sending IGMP 163 datagrams all is done to ensure that the packets are not routed. For 164 example the TTL is set to 1 and the IP header contains the router 165 alert option. This is a hint to developers that there is probably a 166 need to send this packet to the CPU. 168 IGMP snooping switches build forwarding lists by listening for (and 169 in some cases intercepting) IGMP messages. Although the software 170 processing the IGMP messages may maintain state information based on 171 the full IP group addresses, the forwarding tables are typically 172 mapped to link layer addresses. An example of such a forwarding 173 table is shown in Figure 1. 175 Multicast MAC address | Member ports 176 ------------------------------------- 177 01-00-5e-00-00-01 | 2, 7 178 01-00-5e-01-02-03 | 1, 2, 3, 7 179 01-00-5e-23-e2-05 | 1, 4 180 ------------------------------------- 181 Figure 1. 183 Because only the least significant 23 bits of the IP address are 184 mapped to Ethernet addresses [RFC1112], there is a loss of informa- 185 tion when forwarding solely on the destination MAC (DMAC) address. 186 This means that for example 224.0.0.123 and 239.128.0.123 and similar 187 IP multicast addresses all map to MAC address 01-00-5e-00-00-7b (for 188 Ethernet). As a consequence, IGMP snooping switches may collapse IP 189 multicast group memberships into a single Ethernet multicast member- 190 ship group. 192 Finally, it should be mentioned that in addition to building and 193 maintaining lists of multicast group memberships the snooping switch 194 should also maintain a list of multicast routers. When forwarding 196 RFC DRAFT October 2001 198 multicast packets they should be forwarded on ports which have joined 199 using IGMP but also on ports on which multicast routers are attached. 200 The reason for this is that in IGMP there is only one active querier. 201 This means that all other routers on the network are suppressed and 202 thus not detectable by the switch. 204 2.1. Problems in older networks 206 The drawback of using IGMP snooping switches to make the flooding of 207 multicast traffic more efficient is that the underlying link layer 208 topology is required to remain very stable. This is especially true 209 in IGMP versions 1 and 2 where group members do not transmit Member- 210 ship Report messages after having overheard a report from another 211 group member. 213 This problem can be demonstrated with an example. In the topology 214 illustrated in figure 2, a topology loop exists between four IGMP 215 snooping switches labeled A, B, C and D. 217 - The spanning tree algorithm would detect this loop and disable 218 one of the links; for example, the link connecting ports B3 and 219 C1. 221 - Host H1 transmits a group Membership Report which will be flooded 222 throughout the network. 224 - When switch A hears the report, it determines that packets 225 addressed to the group should be forwarded to port A3. 227 - Router R hears the Join message and starts forwarding packets 228 with the multicast destination address into the network. Host H1 229 is now part of the group. 231 - The link between D2 and C2 is broken. The spanning tree algo- 232 rithm reactivates the blocked link B3-C1. 234 - If switch A relies solely on the exchange of IGMP messages to 235 alter its forwarding behavior, host H1 will be unable to receive 236 packets forwarded to the group address until router R sends out 237 another Membership Query. 239 One possible approach to work around this limitation would be for the 240 switch to keep track of which nodes belong to the group, altering the 241 forwarding tables whenever a member becomes visible through a different 242 port. When switch A sees that host H1 has moved from port A3 to A2, the 243 RFC DRAFT October 2001 245 +------+ B2 246 B1 |Snoop |----- - - - +------+ 247 -----|Switch| | Host | 248 / | B |----- / | H1 | 249 +--------+ A2 / +------+ B3 X C1 +------+ +--+---+ 250 A1 | Snoop |----- / -----|Snoop | | 251 --+----| Switch | |Switch|-----+---- 252 | | A |----- -----| C | C3 253 +-+-+ +--------+ A3 \ +------+ D2 / C2 +------+ 254 | R | \ D1 |Snoop |----- 255 ++-++ -----|Switch| 256 | | | D |---------+------ - - - 257 +------+ D3 | 258 +--+---+ 259 | Host | 260 | H2 | 261 +------+ 262 Figure 2 263 group membership table would be updated. This does not work, however, 264 when more than one node joins the same group address when at least one 265 of them has not yet been upgraded to IGMPv3: if hosts H1 and H2 were to 266 join the group at approximately the same time, they would both start off 267 random timers for the transmission of their first Membership Reports. 268 If host H2 selects a longer interval than H1, it will hear H1's report 269 message and cancel the one it was about to send. Switch A, therefore, 270 never learns that node H2 has joined the group. When the switch learns 271 that H1 is now accessible through port A2, it has no way of knowing that 272 it should continue forwarding group packets to port A3 as well. 274 Two recommendations can be made based on the above discussion: 276 - The switch should play an active role when detecting a topology 277 change; The spanning tree root bridge (which is also a snooping 278 switch) should initiate the transmission of a IGMP General Query, 279 for example through signalling the CPU. This will help to reduce 280 the join latency otherwise introduced. 282 - IGMP Membership Reports should not be flooded because this will 283 lead to Join suppression. 285 2.2. IGMPv2 snooping and 224.0.0.X 287 Special attention should be brought to the IP address range from 288 224.0.0.1 through 224.0.0.255 which is reserved for routing protocols 289 and other low-level topology discovery or maintenance protocols 290 [IANA]. Examples of reserved multicast addresses are: 292 RFC DRAFT October 2001 294 224.0.0.2 All Routers on this Subnet 295 224.0.0.4 DVMRP 296 224.0.0.5 (M)OSPF routers 297 224.0.0.6 (M)OSPF DRs 298 224.0.0.9 RIP2 Routers 299 224.0.0.13 PIM Routers 300 224.0.0.22 IGMPv3 Membership Reports 302 Multicast routers are discouraged from routing packets when a desti- 303 nation address falls within this range, regardless of the TTL value. 304 The router will be the originator or consumer of these messages so it 305 has less of a motivation to maintain forwarding path information for 306 these addresses. As a result, it becomes less critical for the 307 router to send out periodic Query messages for these groups. If the 308 router chooses not to, the group would be unable to recover from 309 topology changes as described above. Note that the only difference 310 between the 'all hosts' address (224.0.0.1) and the remainder of this 311 range is that the router has no discretion in the former case: it 312 MUST NOT send Queries. 314 To avoid this situation, IGMP snooping switches should be less con- 315 servative when forwarding packets to these addresses and flood them 316 to all ports. 318 As an example of this, it is reported in [MSOFT] that a number of 319 switches can be misconfigured to perform IGMP snooping and forwarding 320 for all IP multicast groups: 322 Figure 3 illustrates the scenario where two routers R1 and R2 are 323 communicating using for example 224.0.0.6. The routers never send 324 IGMP Joins for this address. The switch floods the (unknown) multi- 325 cast traffic on all ports. 327 Now the server SVR is started and it sends an IGMP Join for 328 224.0.0.6, which is snooped by the switch. The switch then generates 329 a Membership Query on all ports to determine which ports have devices 330 attached that also belong to this group. 332 The routers R1 and R2 do not respond and the switch builds a forward- 333 ing port list with only SVR in it. Now R1 and R2 are not able to 334 communicate using this address. 336 There are two possible fixes to this problem: One is to require that 337 all routers (also being hosts) which use IP multicast respond to IGMP 338 queries in the range 224.0.0.X. This seems unnecessary as discussed 339 above because of the inherent link local scope of these messages. 341 RFC DRAFT October 2001 343 +----+ +----------+ 344 --| R1 |-----| | 345 +----+ | Snooping | +-----+ 346 | |----| SVR | 347 +----+ | switch | +-----+ 348 --| R2 |-----| | 349 +----+ +----------+ 351 Figure 3. 352 Another solution to this problem, which is also discussed above, is 353 that the switch is configured to forward all packets for a range of 354 IP multicast addresses to all ports (flooding). 356 It is suggested that all multicast packets in the range 224.0.0.1 357 through 224.0.0.255 are forwarded on all ports. This of course 358 requires an examination of the network layer header. Note that these 359 are IP adress ranges and that mapping these to MAC address range 360 01-00-5e-00-00-X is subject to problems discussed in the previous 361 sections. 363 2.3. IGMPv3 and IGMPv2 coexistence 365 IGMPv3 and IGMPv2 are designed to interoperate with older versions of 366 IGMP. Both hosts and routers are capable of falling back to an ear- 367 lier version when receiving older IGMP messages, thus enabling a 368 mixed deployment and migration to new versions. While this works fine 369 in a network of hosts and routers an IGMP snooping switch introduces 370 problems. 372 In figure 4 where hosts H1 and H2 are connected to an IGMP snooping 373 switch on ports P1 and P2 respectively, consider the following 374 sequence of communication: 376 - Router R sends an IGMPv3 Query 378 - Host H1 sends an IGMPv2 Report since it has only implemented v2. 379 R notices this and switches to IGMPv2 mode. The report is not 380 received by H2 because of the snooping functionality. 382 - Switch S puts H1's port P1 in the forwarding table. 384 - Host H2 sends an IGMPv3 Report in response to R's Query. 386 - Switch S fails to add H2's port P2 to the forwarding table 387 because it doesn't support IGMPv3. 389 RFC DRAFT October 2001 391 - H2 does not receive any traffic before R sends its next Query 392 which will put H2 in IGMPv2 mode. 394 This introduces a Join latency for host H2, which apparently cannot be 395 avoided. The latency is potentially of the order of minutes. It is pos- 396 sible however to reduce this latency by tuning the Query Interval which 397 defaults to 125 seconds. 399 When operating in a mixed deployment mode it is suggested that initially 400 the Query Interval is set to "a low value" until the compatibility modes 401 have stabilized both host and routers on the same IGMP version. After 402 stabilization the Query Interval could be increased to its original 403 value. 405 2.4. Source Specific Joins 407 Even for IGMPv3 snooping capable switches there can be limitations 408 caused by link layer based forwarding. This is illustrated in figure 409 4. 411 Assume that host H1 sends a Join(S1, G) to R and that host H2 sends a 412 Join(S2, G) to R. 414 The switch adds both hosts to the forwarding list for group G. 416 Frames originating from sources S1 and S2 for the same multicast 417 address G are routed via R. These are sent from R with the router's 418 MAC address as source. 420 The switch is unable to distinguish the two different types of flow 421 and forwards both flows to both hosts. This effectively disables the 422 Join source functionality in this network configuration. 424 +----+ P1+----------+ 425 | H1 |-----| | 426 +----+ | Snooping | +---+ (S1, G) 427 | |----| R |--- and 428 +----+ | switch | +---+ (S2, G) 429 | H2 |-----| | 430 +----+ P2+----------+ 432 Figure 4. 434 This is a problem caused by layer 2 based forwarding of a layer 3 435 flow in conjunction with the difference between the link layer and 437 RFC DRAFT October 2001 439 the network layer information. 441 The example above means that host implementations cannot rely on the 442 router to perform all source address filtering. Therefore they must 443 still filter out packets that do not match the source address crite- 444 rion specified in the Join messages. While this might be seen as an 445 inconvience, this is no different than the case where the router is 446 directly connected to both hosts on a shared LAN and no snooping 447 switch is present. 449 A complete solution would be for the switch to further qualify the 450 search process by including the source IP address when determining 451 which ports should forward the packet. 453 Similar problems occur with the attempt to exclude sources. 455 3. Snooping Requirements 457 Note that in the following we provide suggestions for good/best prac- 458 tices when designing IGMP snooping devices. Keywords as MUST, SHOULD, 459 MUST NOT etc. are suggestions only. 461 1) All IGMP packets (IP packets with IP-PROTO = 2) SHOULD be redi- 462 rected to the CPU for IGMP snooping processing and table management. 463 This allows for the most flexible IGMP snooping solution. 465 2) The switch that provides support for IGMP snooping MUST forward 466 all unrecognized IGMP messages and MUST NOT attempt to make use of 467 any information beyond the end of the network layer header. In par- 468 ticular, messages where any reserved fields are non-zero MUST NOT be 469 subject to "normal" snooping since this could indicate an incompati- 470 ble change to the message format. 472 3) Packets with a destination IP (DIP) address in the 224.0.0.X range 473 which are *not* IGMP SHOULD be forwarded on all ports. 475 4) Packets with a destination IP address outside 224.0.0.X which are 476 *not* IGMP SHOULD be forwarded according to port membership tables 477 and MUST also be forwarded on router ports. 479 5) If a switch receives a *non* IGMP multicast packet without having 480 first processed Membership Reports for the group address, it MUST 481 forward the packet on all ports. In other words, the switch must 482 allow for the possibility that connected hosts and routers have been 483 upgraded to support future versions or extensions of IGMP that the 485 RFC DRAFT October 2001 487 switch does not yet recognize. A switch MAY have a configuration 488 option that suppresses this operation, but default behavior MUST be 489 to allow flooding of unregistered packets. 491 6) A snooping switch SHOULD forward IGMP Membership Reports on router 492 "ports" only. 494 7) The switch supporting IGMP snooping MUST maintain a list of multi- 495 cast routers. This list SHOULD be built using IGMP Multicast Router 496 Discovery [MRDISC] which is currently going through IETF Last Call. 497 IGMP snooping switches MAY build this list based on the arrival port 498 for packets destined to 224.0.0.X, when 500 - The packets are IGMP Queries or 502 - The packets are *not* IGMP or 504 - The ports are configured (by management) as having multicast 505 routers attached 507 8) IGMP snooping switches MAY maintain forwarding tables based on either 508 MAC addresses or IP addresses. If a switch supports both types of for- 509 warding tables then the default behavior SHOULD be to use IP addresses. 511 9) Switches which rely on information in the IP header MAY verify that 512 the IP header checksum is correct. If the checksum fails the packet 513 SHOULD be silently discarded. 515 10) IGMP snooping switches SHOULD inform the CPU (or hardware) when a 516 link layer topology change has been detected. Following a topology 517 change the switch SHOULD initiate the transmission of a General Query on 518 all ports in order to reduce Join latency. 520 4. IPv6 Considerations 522 In order to avoid confusion, the previous discussions have been based 523 on IGMPv3 functionality which only applies to IPv4 multicast. In the 524 case of IPv6 most of the above discussions are still valid with a few 525 exceptions which we will describe here. 527 In IPv6 the protocol for multicast group maintenance is called Multi- 528 cast Listener Discovery (MLDv2). IPv6 is not widely deployed today 529 and neither is IPv6 multicast. However, it is anticipated that at 530 some time IPv6 switches capable of MLD snooping will appear. 532 The three main differences between IGMPv3 and MLDv2 are 534 RFC DRAFT October 2001 536 - MLDv2 uses ICMPv6 message types instead of IGMP message types. 538 - The ethernet encapsulation is a mapping of 32bits of the 128bit 539 DIP addresses into 48bit DMAC addresses [IPENCAPS]. 541 - Multicast router discovery is done using Neighbor Discovery Pro- 542 tocol (NDP) for IPv6. NDP uses ICMPv6 message types. 544 A minor difference which applies to the requirements section is that in 545 IPv6 there is no checksum in the IP header. This is the reason that the 546 checksum validation requirement is listed as a MAY. 548 The fact that MLDv2 is using ICMPv6 adds new requirements to a snooping 549 switch because ICMPv6 has multiple uses aside from MLD. This means that 550 it is no longer sufficient to detect that the next-header field of the 551 IP header is ICMPv6 in order to redirect packets to the CPU. If this 552 was the case the CPU queue assigned for MLD would potentially be filled 553 with non-MLD related packets. Furthermore ICMPv6 packets destined for 554 other hosts would not reach their destination. A solution is either to 555 require that the snooping switch looks further into the packets or to be 556 able to detect a multicast DMAC address in conjunction with ICMPv6. The 557 first solution is desirable only if it is configurable which message 558 types should trigger a CPU redirect and which should not. The reason is 559 that a hardcoding of message types is unflexible for the introduction of 560 new message types. The second solution introduces the risk of new pro- 561 tocols, which are not related to MLD but uses ICMPv6 and multicast DMAC 562 addresses wrongly being identified as MLD. We do not suggest a recom- 563 mended solution in this case. 565 The mapping from IP multicast addresses to multicast DMAC addresses 566 introduces a potentially enormous overlap. The structure of an IPv6 mul- 567 ticast address is shown in figure 5. Theoretically 2**80, two to the 568 power of 80 (128 - 8 - 4 - 4 - 32) unique DIP addresses could map to one 569 DMAC address. This should be compared to 2**5 in the case of IPv4. 571 Initial allocation of IPv6 multicast addresses, however, uses only the 572 lower 32 bits of group ID. This eliminates the address ambiguity for the 573 time being but it should be noted that the allocation policy may change 574 in the future. 576 | 8 | 4 | 4 | 112 bits | 577 +--------+----+----+---------------------------------------+ 578 |11111111|flgs|scop| group ID | 579 +--------+----+----+---------------------------------------+ 580 Figure 5 582 In the case of IPv6 forwarding can be made on the basis of DMAC 583 RFC DRAFT October 2001 585 addresses in the forseable future. 587 Finally we mention the reserved address range FF0X:0:0:0:0:0:X:X where X 588 is any value. This range is similar to 224.0.0.X for IPv4 and is 589 reserved to routing protocols and resource discovery [RFC2375]. In the 590 case of IPv6 it is suggested that packets in this range are forwarded on 591 all ports if they are not MLD packets. 593 5. Security Considerations 595 Security considerations for IGMPv3 are accounted for in [IGMPv3]. 596 The introduction of IGMP snooping switches adds the following consid- 597 erations with regard to IP multicast. 599 The exclude source failure which could cause traffic from sources 600 that are 'black listed' to reach hosts that have requested otherwise. 601 This can also occur in certain network topologies without IGMP snoop- 602 ing. 604 It is possible to generate packets which make the switch wrongly 605 believe that there is a multicast router on the segment on which the 606 source is attached. This will potentially lead to excessive flooding 607 on that segment. The authentication methods discussed in [IGMPv3] 608 will also provide protection in this case. 610 IGMP snooping switches which rely on the IP header of a packet for 611 their operation and which do not validate the header checksum poten- 612 tially will forward packets on the wrong ports. Even though the IP 613 headers are protected by the ethernet checksum this is a potential 614 vulnerability. 616 Generally though, it is worth to stress that IP multicast must so far 617 be considered insecure until the work of for example the suggested 618 Multicast Security (MSEC) working group or similar is completed or at 619 least has matured. 621 6. IGMP Questionnaire 623 As part of this work the following questions were asked both on the 624 MAGMA discussion list and sent to known switch vendors implementing IGMP 625 snooping. The individual contributions have been anonymized upon 626 request. 628 The questions were: 630 RFC DRAFT October 2001 632 Q1 Does your switches perform IGMP Join aggregation? In other words, 633 are IGMP joins intercepted, absorbed by the hardware/software so that 634 only one Join is forwarded to the querier? 636 Q2 Is multicast forwarding based on MAC addresses? Would datagrams 637 addressed to multicast IP addresses 224.1.2.3 and 239.129.2.3 be for- 638 warded on the same ports-groups? 640 Q3 Is it possible to forward multicast datagrams based on IP addresses 641 (not routed). In other words, could 224.1.2.3 and 239.129.2.3 be for- 642 warded on different port-groups with unaltered TTL? 644 Q4 Are multicast datagrams within the range 224.0.0.1 to 224.0.0.255 645 forwarded on all ports whether or not IGMP Joins have been sent? 647 Q5 Are multicast frames within the MAC address range 01:00:5E:00:00:01 648 to 01:00:5E:00:00:FF forwarded on all ports whether or not IGMP joins 649 have been sent? 651 Q6 Does your switch support forwarding to ports on which IP multicast 652 routers are attached in addition to the ports where IGMP Joins have been 653 received? 655 Q7 Is your IGMP snooping functionality fully implemented in hardware? 657 Q8 Is your IGMP snooping functionality partly software implemented? 659 Q9 Can topology changes (for example spanning tree configuration 660 changes) be detected by the IGMP snooping functionality so that for 661 example new queries can be sent or tables can be updated to ensure 662 robustness? 664 The answers were: 666 RFC DRAFT October 2001 668 --------------------------------------------- 669 Switch Vendor 670 -------------------------+---+---+---+---+--- 671 | 1 | 2 | 3 | 4 | 672 -------------------------+---+---+---+---+--- 673 Q1 Join aggregation | x | x | x | 674 Q2 Layer-2 forwarding | x | x | x | 675 Q3 Layer-3 forwarding |(1)| |(1)| 676 Q4 224.0.0.X aware |(1)| x |(1)| 677 Q5 1:00:5e:0:0:X aware | x | x | x | 678 Q6 Mcast router list | x | x | x | 679 Q7 Hardware implemented | | | | 680 Q8 Software assisted | x | x | x | 681 Q9 Topology change aware | x | x | x | 682 -------------------------+---+---+---+---+--- 683 x Means that the answer was Yes. 684 (1) In some products (typically high-end) Yes, in others No. 686 7. IPR Issues 688 It appears that a number of patents have been filed which may apply to 689 this draft or parts thereof. None of these patents have been filed by 690 the authors of this draft or companies in which they are or have been 691 employed. 693 We, the authors, have not tried to evaluate whether these patents are 694 violated by implementing IGMP snooping according to this document. The 695 IETF/IESG have been notified about the patents. 697 International patent: WO 96/34474, Oct. 31 1996, Title: "Broadcast 698 transmission in a data network" 700 US patent: Number 5,608,726, Mar. 4, 1997 (filed 1995) Title: "Network- 701 ing Bridge with Multicast forwarding table" 703 US patent: Number 5,898,686, Apr. 27, 1999 (filed 1996) Title: "Network- 704 ing Bridge with Multicast forwarding table" 706 Australian patent: Application No. 65440/98 Title: "System, Device, and 707 Method for Managing Multicast Group Memberships in a Multicast Network" 708 RFC DRAFT October 2001 710 8. References 712 [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" 714 [CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP 715 and IGMP snooping", http://www.cisco.com/warp/pub- 716 lic/473/22.html 718 [IANA] Internet Assigned Numbers Authority, "Internet Multicast 719 Addresses", http://www.isi.edu/in-notes/iana/assign- 720 ments/multicast-addresses 722 [IGMPv3] Cain, B., "Internet Group Management Protocol, Version 723 3", draft-ietf-idmr-igmp-v3-06.txt, November 2000 725 [IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether- 726 net Networks", RFC2464, December 1998. 728 [MLDv2] Vida, R., "Multicast Listener Discovery Version 2 729 (MLDv2) for IPv6", draft-vida-mld-v2-00.txt, February 730 2001. 732 [MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft- 733 ietf-idmr-igmp-mrdisc-06.txt, May 2001. 735 [MSOFT] Microsoft support article Q223136, "Some LAN Switches 736 with IGMP Snooping Stop Forwarding Multicast Packets on 737 RRAS Startup", http://support.microsoft.com/sup- 738 port/kb/articles/Q223/1/36.ASP 740 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 741 1112, August 1989. 743 [RFC2026] Bradner, S. "The Internet Standards Process -- Revision 744 3", RFC2026, October 1996. 746 RFC DRAFT October 2001 748 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 749 2", RFC2236, November 1997. 751 [RFC2375] Hinden, R. "IPv6 Multicast Address Assignments", 752 RFC2375, July 1998. 754 9. Acknowledgements 756 We would like to thank Bill Fenner, Yiqun Cai, Edward Hilquist and 757 Martin Bak for comments and suggestions on this document. Further- 758 more, the following companies are acknowledged for their contribu- 759 tions: List-of-Companies will not be displayed until a sufficient 760 number of replies have been received in order to keep promise about 761 anomymization. 763 10. Author's Addresses: 765 Morten Jagd Christensen 766 Vitesse Semiconductor Corporation 767 Hoerkaer 16 768 2730 Herlev 769 DENMARK 770 email: mjc@vitesse.com 772 Frank Solensky 773 Gotham Networks 774 15 Discovery Way 775 Acton, MA 01720 776 USA 777 email: fsolensky@GothamNetworks.com 778 solensky@acm.org 780 RFC DRAFT October 2001 782 Table of Contents 784 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 785 2. IGMP snooping overview . . . . . . . . . . . . . . . . . . . . 2 786 2.1 Problems in older networks . . . . . . . . . . . . . . . . . . 5 787 2.2 IGMPv2 snooping and 224.0.0.X . . . . . . . . . . . . . . . . . 6 788 2.3 IGMPv3 and IGMPv2 coexistence . . . . . . . . . . . . . . . . . 8 789 2.4 Source Specific Joins . . . . . . . . . . . . . . . . . . . . . 9 790 3. Snooping Requirements . . . . . . . . . . . . . . . . . . . . . 10 791 4. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 11 792 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 793 6. IGMP Questionnaire . . . . . . . . . . . . . . . . . . . . . . 13 794 7. IPR Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 15 795 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 796 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 797 10. Author's Addresses: . . . . . . . . . . . . . . . . . . . . . . 17