idnits 2.17.00 (12 Aug 2021) /tmp/idnits56796/draft-ietf-magma-snoop-01.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: ---------------------------------------------------------------------------- == 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 3 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 114: '... snooping switch MUST only forward IGM...' RFC 2119 keyword, line 116: '...switch MUST NOT forward IGMP Membershi...' RFC 2119 keyword, line 125: '...ng IGMP snooping MUST maintain a list ...' RFC 2119 keyword, line 126: '...they are attached. This list SHOULD be...' RFC 2119 keyword, line 128: '...switches MAY alternatively build this ...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC112' is mentioned on line 85, but not defined == Unused Reference: 'BRIDGE' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'IANA' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'MLDv2' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC1112' is defined on line 452, 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: 5 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MAGMA Working Group M. Christensen 3 Internet Draft jCAPS 4 January 2002 F. Solensky 5 Expiration Date: July 2002 7 IGMP and MLD snooping switches 8 10 Status of this Memo 12 This document is the successor of draft-ietf-magma-snoop-00 which was 13 presented at the 52'nd IETF in Salt Lake City. The main differences 14 between this and the previous version is a restructuring of the draft 15 to introduce the main result as early as possible. Also the draft has 16 been trimmed to a smaller size. No new results are presented, as the 17 draft is expected to published as Informational within the next four 18 months. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026 [RFC2026]. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This memo describes the requirements for IGMP and MLD snooping 41 switches. The requirements for IGMPv2 snooping switches are based on 42 best current practices. IGMPv3 and MLDv2 snooping are also covered in 43 this draft although we are not aware of any such implementations at 44 the time of writing. 46 RFC DRAFT January 2001 48 The memo also describes the interoperability problems and issues that 49 can arise when a mixed deployment of IGMPv3 and IGMPv2 capable hosts 50 and routers are interconnected by a switch with IGMP snooping 51 capabilities. 53 Areas which are of relevance to IGMP and MLD snooping switches, such 54 as link layer topology changes and Ethernet specific encapsulation 55 issues are also considered. 57 It is intended as an accompanying document to the IGMPv3 and MLDv2 58 specifications. 60 1. Introduction 62 In recent years, a number of commercial vendors have introduced prod- 63 ucts described as "IGMP snooping switches" to the market. These 64 devices do not adhere to the conceptual model that provides the 65 strict separation of functionality between different communications 66 layers in the ISO model and instead utilizes information in the upper 67 level protocol headers as factors to be considered in the processing 68 at the lower levels. 70 This is analogous to the manner in which a router can act as a fire- 71 wall by looking into the transport protocol's header before allowing 72 a packet to be forwarded to its destination address. 74 In the case of multicast traffic, an IGMP snooping switch provides 75 the benefit of conserving bandwidth on those segments of the network 76 where no node has expressed interest in receiving packets addressed 77 to the group address. This is in contrast to normal switch behaviour 78 where multicast traffic is typically forwarded on all interfaces. 80 Many switch datasheets state support for IGMP snooping, but no 81 requirements for this exist today. It is the authors hope that the 82 information presented in this draft will supply this information. 84 The requirements presented here is based on the following information 85 sources: The IGMP specifications [RFC112][RFC2236][IGMPv3], vendor 86 supplied technical documents [CISCO], bug reports [MSOFT], discus- 87 sions with people invovled in design of IGMP snooping switches, MAGMA 88 mailinglist discussions, and on replies by switch vendors to an 89 implementation questionnaire. 91 The discussions in this document are based on IGMP which applies to 92 IPv4 only. For IPv6 we must use MLD instead. Because MLD is based on 93 IGMP we do not repeat the whole discussion and requirements for MLD 95 RFC DRAFT January 2001 97 snooping switches. Instead we point out the few cases where there is 98 a difference compared to IGMP. 100 2. IGMP Snooping Requirements 102 The following sections list the requirements for an IGMP snooping 103 switch. The requirement is stated and is supplemented by a discus- 104 sion. All implementation discussions are examples only and there may 105 well be other ways to achieve the same functionality. 107 2.1. Forwarding rules 109 The IGMP snooping functionality is here separated in a control section 110 (IGMP forwarding) and data section (Data forwarding). 112 2.1.1. IGMP Forwarding Rules 114 1) A snooping switch MUST only forward IGMP Membership Reports on ports 115 where multicast routers are attached. Alternatively stated: A snooping 116 switch MUST NOT forward IGMP Membership Reports to ports on which only 117 hosts are attached. 119 This is the main IGMP snooping functionality. Sending membership reports 120 to other hosts can result (For IGMPv2 and IGMPv1) in the unwanted pre- 121 vention of a host wishing to join a specific multicast group. This is 122 not a problem in a IGMPv3 only network because there is no cancellation 123 of IGMP Membership reports. 125 The switch supporting IGMP snooping MUST maintain a list of multicast 126 routers and the ports on which they are attached. This list SHOULD be 127 built using IGMP Multicast Router Discovery [MRDISC]. IGMP snooping 128 switches MAY alternatively build this list based on 130 a) The arrival port for IGMP Queries (sent by multicast routers) or 132 b) List of ports configured (by management) as having multicast routers 133 attached. 135 Implementation example: IGMP snooping can be achieved by redirecting all 136 IGMP packets (IP packets with IP-PROTO = 2) to the CPU (or similar 137 higher layer entity) for IGMP message processing and table management. 139 2) IGMP snooping switches MAY implement "proxy-reporting" in which 140 RFC DRAFT January 2001 142 reports received from downstream hosts are summarized and used to build 143 internal membership states. An IGMP proxy-reporting switch would then 144 report it's own state in response to upstream queriers. If the switch 145 does not have an IP address it SHOULD use the address 0.0.0.0 as source 146 in these reports. 148 An IGMP proxy-reporting switch may act as Querier for the downstream 149 hosts while proxy reporting to the 'real' upstream queriers. 151 It should be noted that there may be multiple IGMP proxy-reporting 152 switches in the network all using the 0.0.0.0 source IP address. In this 153 case the switches can be identified by their, link layer source MAC 154 address. 156 IGMP membership reports should not be rejected because of a source IP 157 address of 0.0.0.0. 159 3) The switch that supports IGMP snooping MUST forward all unrecognized 160 IGMP messages and MUST NOT attempt to make use of any information beyond 161 the end of the network layer header. In particular, messages where any 162 reserved fields are non-zero MUST NOT be subject to "normal" snooping 163 since this could indicate an incompatible change to the message format. 165 4) An IGMP snooping switch SHOULD be aware of link layer topology 166 changes. Following a topology change the switch SHOULD initiate the 167 transmission of a General Query on all ports in order to reduce network 168 convergence time. 170 5) An IGMP snooping switch MUST discard from the IGMP snooping process 171 IGMP packets where IP or IGMP headers have checksum errors. 173 2.1.2. Data Forwarding Rules 175 6) Packets with a destination IP (DIP) address in the 224.0.0.X range 176 which are *not* IGMP MUST be forwarded on all ports. 178 This requirement is based on fact that many hosts exist today, which 179 does not Join IP multicast addresses in this range before sending or 180 listening to IP multicast. Furthermore since the 224.0.0.X address range 181 is defined as link local (not to be routed) it seems unnecessary to keep 182 state for each address in this range. 184 7) Packets with a destination IP address outside 224.0.0.X which are 185 *not* IGMP SHOULD be forwarded according to group based port membership 186 RFC DRAFT January 2001 188 tables and MUST also be forwarded on router ports. 190 This is the core IGMP snooping requirement for the data path. 192 Discussion: An implementation could maintain separate membership and 193 multicast router tables in software and then "merge" these tables into a 194 current forwarding cache. 196 8) If a switch receives a *non* IGMP multicast packet without having 197 first processed Membership Reports for the group address, it MUST for- 198 ward the packet on all ports. In other words, the switch must allow for 199 the possibility that connected hosts and routers have been upgraded to 200 support future versions or extensions of IGMP that the switch does not 201 yet recognize. A switch MAY have a configuration option that suppresses 202 this operation, but default behavior MUST be to allow flooding of unreg- 203 istered packets. 205 9) IGMP snooping switches MAY maintain forwarding tables based on either 206 MAC addresses or IP addresses. If a switch supports both types of for- 207 warding tables then the default behavior MUST be to use IP addresses. 209 Discussion: Forwarding based on MAC addresses is subject to the problem 210 associated with the 32-fold IP address to 1 MAC address mapping. 212 10) Switches which rely on information in the IP header SHOULD verify 213 that the IP header checksum is correct. If the checksum fails the packet 214 SHOULD be silently discarded. 216 2.2. IGMP snooping related problems 218 A special problem arise in the network consisting of IGMPv3 routers as 219 well as IGMPv2 and IGMPv3 hosts interconnected by a IGMPv2 snooping 220 switch. IGMPv3 has a mechanism to fall back to IGMPv2 when receiving 221 IGMPv2 membership reports. This means that the network will converged on 222 IGMPv2 eventually. However, the convergence time will lead to supression 223 of v3 Hosts for several minutes. 225 Therefore it is recommended that in such a network, the multicast router 226 is configured to use IGMPv2. 228 3. IPv6 Considerations 230 In order to avoid confusion, the previous discussions have been based 231 on IGMPv3 functionality which only applies to IPv4 multicast. In the 232 case of IPv6 most of the above discussions are still valid with a few 234 RFC DRAFT January 2001 236 exceptions which we will describe here. 238 In IPv6 the protocol for multicast group maintenance is called Multi- 239 cast Listener Discovery (MLDv2). IPv6 is not widely deployed today 240 and neither is IPv6 multicast. However, it is anticipated that at 241 some time IPv6 switches capable of MLD snooping will appear. 243 The three main differences between IGMPv3 and MLDv2 are 245 - MLDv2 uses ICMPv6 message types instead of IGMP message types. 247 - The ethernet encapsulation is a mapping of 32bits of the 128bit 248 DIP addresses into 48bit DMAC addresses [IPENCAPS]. 250 - Multicast router discovery is done using Neighbor Discovery Pro- 251 tocol (NDP) for IPv6. NDP uses ICMPv6 message types. 253 A minor difference which applies to the requirements section is that in 254 IPv6 there is no checksum in the IP header. This is the reason that the 255 checksum validation requirement is listed as a MAY. 257 The fact that MLDv2 is using ICMPv6 adds new requirements to a snooping 258 switch because ICMPv6 has multiple uses aside from MLD. This means that 259 it is no longer sufficient to detect that the next-header field of the 260 IP header is ICMPv6 in order to redirect packets to the CPU. If this 261 was the case the CPU queue assigned for MLD would potentially be filled 262 with non-MLD related packets. Furthermore ICMPv6 packets destined for 263 other hosts would not reach their destination. A solution is either to 264 require that the snooping switch looks further into the packets or to be 265 able to detect a multicast DMAC address in conjunction with ICMPv6. The 266 first solution is desirable only if it is configurable which message 267 types should trigger a CPU redirect and which should not. The reason is 268 that a hardcoding of message types is unflexible for the introduction of 269 new message types. The second solution introduces the risk of new pro- 270 tocols, which are not related to MLD but uses ICMPv6 and multicast DMAC 271 addresses wrongly being identified as MLD. It is suggested that solution 272 one is the preferred if the switch is capable of triggering CPU redi- 273 rects on individual ICMPv6 message types. If this is not the case then 274 use solution two. 276 The mapping from IP multicast addresses to multicast DMAC addresses 277 introduces a potentially enormous overlap. The structure of an IPv6 mul- 278 ticast address is shown in figure 5. Theoretically 2**80, two to the 279 power of 80 (128 - 8 - 4 - 4 - 32) unique DIP addresses could map to one 280 DMAC address. This should be compared to 2**5 in the case of IPv4. 282 Initial allocation of IPv6 multicast addresses, however, uses only the 283 RFC DRAFT January 2001 285 lower 32 bits of group ID. This eliminates the address ambiguity for the 286 time being but it should be noted that the allocation policy may change 287 in the future. 289 | 8 | 4 | 4 | 112 bits | 290 +--------+----+----+---------------------------------------+ 291 |11111111|flgs|scop| group ID | 292 +--------+----+----+---------------------------------------+ 293 Figure 5 295 In the case of IPv6 forwarding can be made on the basis of DMAC 296 addresses in the forseable future. 298 Finally, we mention the reserved address range FF0X:0:0:0:0:0:X:X where 299 X is any value. This range is similar to 224.0.0.X for IPv4 and is 300 reserved to routing protocols and resource discovery [RFC2375]. In the 301 case of IPv6 it is suggested that packets in this range are forwarded on 302 all ports if they are not MLD packets. 304 4. Security Considerations 306 Security considerations for IGMPv3 are accounted for in [IGMPv3]. 307 The introduction of IGMP snooping switches adds the following consid- 308 erations with regard to IP multicast. 310 The exclude source failure which could cause traffic from sources 311 that are 'black listed' to reach hosts that have requested otherwise. 312 This can also occur in certain network topologies without IGMP snoop- 313 ing. 315 It is possible to generate packets which make the switch wrongly 316 believe that there is a multicast router on the segment on which the 317 source is attached. This will potentially lead to excessive flooding 318 on that segment. The authentication methods discussed in [IGMPv3] 319 will also provide protection in this case. 321 IGMP snooping switches which rely on the IP header of a packet for 322 their operation and which do not validate the header checksum poten- 323 tially will forward packets on the wrong ports. Even though the IP 324 headers are protected by the ethernet checksum this is a potential 325 vulnerability. 327 Generally though, it is worth to stress that IP multicast must so far 328 be considered insecure until the work of for example the suggested 329 Multicast Security (MSEC) working group or similar is completed or at 330 least has matured. 332 RFC DRAFT January 2001 334 5. IGMP Questionnaire 336 As part of this work the following questions were asked both on the 337 MAGMA discussion list and sent to known switch vendors implementing IGMP 338 snooping. The individual contributions have been anonymized upon 339 request. 341 The questions were: 343 Q1 Does your switches perform IGMP Join aggregation? In other words, 344 are IGMP joins intercepted, absorbed by the hardware/software so that 345 only one Join is forwarded to the querier? 347 Q2 Is multicast forwarding based on MAC addresses? Would datagrams 348 addressed to multicast IP addresses 224.1.2.3 and 239.129.2.3 be for- 349 warded on the same ports-groups? 351 Q3 Is it possible to forward multicast datagrams based on IP addresses 352 (not routed). In other words, could 224.1.2.3 and 239.129.2.3 be for- 353 warded on different port-groups with unaltered TTL? 355 Q4 Are multicast datagrams within the range 224.0.0.1 to 224.0.0.255 356 forwarded on all ports whether or not IGMP Joins have been sent? 358 Q5 Are multicast frames within the MAC address range 01:00:5E:00:00:01 359 to 01:00:5E:00:00:FF forwarded on all ports whether or not IGMP joins 360 have been sent? 362 Q6 Does your switch support forwarding to ports on which IP multicast 363 routers are attached in addition to the ports where IGMP Joins have been 364 received? 366 Q7 Is your IGMP snooping functionality fully implemented in hardware? 368 Q8 Is your IGMP snooping functionality partly software implemented? 370 Q9 Can topology changes (for example spanning tree configuration 371 changes) be detected by the IGMP snooping functionality so that for 372 example new queries can be sent or tables can be updated to ensure 373 robustness? 375 The answers were: 377 RFC DRAFT January 2001 379 --------------------------------------------- 380 Switch Vendor 381 -------------------------+---+---+---+---+--- 382 | 1 | 2 | 3 | 4 | 383 -------------------------+---+---+---+---+--- 384 Q1 Join aggregation | x | x | x | | 385 Q2 Layer-2 forwarding | x | x | x | x | 386 Q3 Layer-3 forwarding |(1)| |(1)| | 387 Q4 224.0.0.X aware |(1)| x |(1)|(2)| 388 Q5 1:00:5e:0:0:X aware | x | x | x |(2)| 389 Q6 Mcast router list | x | x | x | x | 390 Q7 Hardware implemented | | | | | 391 Q8 Software assisted | x | x | x | x | 392 Q9 Topology change aware | x | x | x | x | 393 -------------------------+---+---+---+---+--- 394 x Means that the answer was Yes. 395 (1) In some products (typically high-end) Yes, in others No. 396 (2) Currently no, but will be real soon. 398 6. IPR Issues 400 It appears that a number of patents have been filed which may apply to 401 this draft or parts thereof. None of these patents, listed below, have 402 been filed by the authors of this draft or companies in which they are 403 or have been employed. 405 We, the authors, have not tried to evaluate whether these patents are 406 violated by implementing IGMP snooping according to this document. The 407 IETF/IESG have been notified about the patents. 409 International patent: WO 96/34474, Oct. 31 1996, Title: "Broadcast 410 transmission in a data network" 412 US patent: Number 5,608,726, Mar. 4, 1997 (filed 1995) Title: "Network- 413 ing Bridge with Multicast forwarding table" 415 US patent: Number 5,898,686, Apr. 27, 1999 (filed 1996) Title: "Network- 416 ing Bridge with Multicast forwarding table" 418 Australian patent: Application No. 65440/98 Title: "System, Device, and 419 Method for Managing Multicast Group Memberships in a Multicast Network" 420 RFC DRAFT January 2001 422 7. References 424 [BRIDGE] IEEE 802.1D, "Media Access Control (MAC) Bridges" 426 [CISCO] Cisco Tech Notes, "Multicast In a Campus Network: CGMP 427 and IGMP snooping", http://www.cisco.com/warp/pub- 428 lic/473/22.html 430 [IANA] Internet Assigned Numbers Authority, "Internet Multicast 431 Addresses", http://www.isi.edu/in-notes/iana/assign- 432 ments/multicast-addresses 434 [IGMPv3] Cain, B., "Internet Group Management Protocol, Version 435 3", draft-ietf-idmr-igmp-v3-06.txt, November 2000 437 [IPENCAPS] Crawford, M., "Transmission of IPv6 Packets over Ether- 438 net Networks", RFC2464, December 1998. 440 [MLDv2] Vida, R., "Multicast Listener Discovery Version 2 441 (MLDv2) for IPv6", draft-vida-mld-v2-00.txt, February 442 2001. 444 [MRDISC] Biswas, S. "IGMP Multicast Router Discovery", draft- 445 ietf-idmr-igmp-mrdisc-06.txt, May 2001. 447 [MSOFT] Microsoft support article Q223136, "Some LAN Switches 448 with IGMP Snooping Stop Forwarding Multicast Packets on 449 RRAS Startup", http://support.microsoft.com/sup- 450 port/kb/articles/Q223/1/36.ASP 452 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 453 1112, August 1989. 455 [RFC2026] Bradner, S. "The Internet Standards Process -- Revision 456 3", RFC2026, October 1996. 458 RFC DRAFT January 2001 460 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 461 2", RFC2236, November 1997. 463 [RFC2375] Hinden, R. "IPv6 Multicast Address Assignments", 464 RFC2375, July 1998. 466 8. Acknowledgements 468 We would like to thank (in no identifiable order) Hugh Holbrook, Bill 469 Fenner, Yiqun Cai, Edward Hilquist, Toerless Eckert, Kevin Humphries, 470 Karen Kimball and Martin Bak for comments and suggestions on this 471 document. Furthermore, the following companies are acknowledged for 472 their contributions: Vitesse Semiconductor Corporation, Cisco Sys- 473 tems, Hewlett-Packard, Enterasys Networks. 475 9. Author's Addresses: 477 Morten Jagd Christensen 478 jCAPS 479 Begoniavej 13 480 2820 Gentofte 481 DENMARK 482 email: morten@jcaps.com 484 Frank Solensky 486 email: solenskyf@acm.org