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