idnits 2.17.1 draft-ietf-mboned-ipv6-multicast-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 517. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 3) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 11, 2004) is 7170 days in the past. Is this intentional? 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: 'I-D.ietf-pim-sm-bsr' is defined on line 474, but no explicit reference was found in the text ** Downref: Normative reference to an Historic draft: draft-ietf-bgmp-spec (ref. 'I-D.ietf-bgmp-spec') == Outdated reference: A later version (-07) exists of draft-ietf-pim-anycast-rp-02 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-10 == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-05 ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 3446 ** Downref: Normative reference to an Experimental RFC: RFC 3618 -- No information found for draft-bhattach-diot-pimso - is the name correct? == Outdated reference: A later version (-12) exists of draft-ietf-magma-snoop-11 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-04 Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONE Deployment WG P. Savola 3 Internet-Draft CSC/FUNET 4 Expires: February 9, 2005 August 11, 2004 6 IPv6 Multicast Deployment Issues 7 draft-ietf-mboned-ipv6-multicast-issues-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 9, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This memo describes known issues with IPv6 multicast, and provides 43 historical reference of how some earlier problems have been resolved. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Multicast-related Abbreviations . . . . . . . . . . . . . 3 49 2. Justification for IPv6 Inter-domain ASM . . . . . . . . . . . 3 50 2.1 SSM Deployment Issues . . . . . . . . . . . . . . . . . . 3 51 2.2 Groups of Different Non-global Scope . . . . . . . . . . . 4 52 3. Different Solutions to Inter-domain Multicast . . . . . . . . 5 53 3.1 Changing the Multicast Usage Model . . . . . . . . . . . . 5 54 3.2 Implementing MSDP for IPv6 . . . . . . . . . . . . . . . . 6 55 3.3 Implementing Another Multicast Routing Protocol . . . . . 6 56 3.4 Embedding the RP Address in an IPv6 Multicast Address . . 6 57 4. Issues with IPv6 Multicast . . . . . . . . . . . . . . . . . . 7 58 4.1 Issues with Embedded RP . . . . . . . . . . . . . . . . . 7 59 4.1.1 RP Failover with Embedded RP . . . . . . . . . . . . . 7 60 4.1.2 Embedded RP and Control Mechanisms . . . . . . . . . . 7 61 4.2 Neighbor Discovery Using Multicast . . . . . . . . . . . . 8 62 4.3 Functionality Like MLD Snooping . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 67 7.2 Informative References . . . . . . . . . . . . . . . . . . . 10 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 69 Intellectual Property and Copyright Statements . . . . . . . . 12 71 1. Introduction 73 There are many issues concerning the deployment and implementation, 74 and to a lesser degree, specification of IPv6 multicast. This memo 75 describes known problems to raise awareness, and documents how 76 previous problems have been resolved. 78 Section 2 describes the justifications for providing an inter-domain 79 multicast solution using Any Source Multicast (ASM) with IPv6. 80 Section 3 in turn describes which options were considered for filling 81 those the requirements for the IPv6 inter-domain multicast solutions. 82 These sections are provided for historical reference of the 83 discussion and consensus in the IETF MBONED working group. 85 Section 4 lists issues that have come up with IPv6 multicast but have 86 not yet been at least fully resolved, and may require raised 87 awareness. 89 1.1 Multicast-related Abbreviations 91 ASM Any Source Multicast 92 BSR Bootstrap Router 93 CGMP Cisco Group Management Protocol 94 DR Designated Router 95 IGMP Internet Group Management Protocol 96 MLD Multicast Listener Discovery 97 MSDP Multicast Source Discovery Protocol 98 PIM Protocol Independent Multicast 99 PIM-SM Protocol Independent Multicast - Sparse Mode 100 RP Rendezvous Point 101 SSM Source-specific Multicast 103 2. Justification for IPv6 Inter-domain ASM 105 This section documents the reasons and the discussion which led to 106 the agreement why a solution to IPv6 inter-domain ASM was necessary. 108 The main reason was that SSM [I-D.ietf-ssm-arch] was not considered 109 to solve all the relevant problems (e.g., many-to-many applications, 110 source discovery), and that SSM was not sufficiently widely deployed 111 and used. 113 2.1 SSM Deployment Issues 115 To be deployed, SSM requires changes to: 117 1. routers 118 2. IGMP/MLD-snooping Ethernet switches 120 3. hosts 122 4. application programming interfaces (APIs) 124 5. multicast usage models 126 Introducing SSM support in the routers has been straightforward as 127 PIM-SSM is a subset of PIM-SM [I-D.ietf-pim-sm-v2-new]. 129 IGMP-snooping Ethernet switches have been a more difficult issue 130 [SSMSNOOP]; some which perform IGMPv2 snooping discard IGMPv3 reports 131 or queries, or multicast transmissions associated to them. If MLDv1 132 snooping had been implemented (or is implemented in a similar 133 manner), this would likely have affected that as well. 135 Host systems require MLDv2 [RFC3810] support. The situation has 136 improved with respect to MLDv2 support for end systems, and 137 interoperability has increased after the publication of the RFC due 138 to the stabilization of the ICMP types used. 140 The multicast source filtering API specification has also been 141 completed [RFC3678]; its deployment is likely roughly equal (or 142 slightly worse) than MLDv2. The API is required for creating 143 (cross-platform) SSM applications. 145 The most difficult issue, multicast usage models, remains a problem 146 as of this writing. SSM is an excellent fit for one-to-many 147 distribution topologies, and porting such applications to use SSM 148 would likely be rather simple. However, a significant number of 149 current applications are many-to-many (e.g., conferencing 150 applications) which cannot be converted to SSM without significant 151 effort, including, for example, out-of-band source discovery. For 152 such applications to be usable for IPv6 at least in a short to medium 153 term, ASM -like techniques seem to be required. 155 2.2 Groups of Different Non-global Scope 157 Many ASM applications are used with a smaller scope than global; some 158 of these have a wider scope than others. However, groups of smaller 159 scope typically need to be in their own PIM-SM domains to prevent 160 inappropriate data leakage. Therefore if a site has groups of 161 different scopes, having multiple PIM domain borders becomes a 162 requirement unless inter-domain multicast is used instead; further, 163 configuring such nesting scopes would likely be an operational 164 challenge. In consequence, if these applications of non-global scope 165 need to be used, inter-domain multicast support is practically 166 required. 168 In consequence, especially if multicast with different non-global 169 scopes is used, there will be a need for inter-domain multicast 170 solutions. As many applications are relying on ASM characteristics, 171 this further increases a need for an inter-domain ASM solution. 173 3. Different Solutions to Inter-domain Multicast 175 When ASM is used, the Internet must be divided to multiple PIM-SM for 176 both administrative and technical reasons, which means there will be 177 multiple PIM-SM RPs which need to communicate the information of 178 sources between themselves. 180 On the other hand, SSM does not require RPs and also works in the 181 inter-domain without such communication. Section 2 describes the 182 justification why Inter-domain ASM was still considered to be 183 required. This section describes different solutions which were 184 discussed to providing inter-domain multicast for IPv6. 186 For inter-domain multicast, there is consensus to continue using SSM, 187 and also use Embedded-RP as appropriate. 189 This section provides historical reference of the discussion and 190 decisions. 192 3.1 Changing the Multicast Usage Model 194 As ASM model has been found to be complex and a bit problematic, some 195 felt that this is a good incentive to move to SSM for good (at least 196 for most cases). Below two paragraphs are adapted from 197 [I-D.bhattach-diot-pimso]: 199 The most serious criticism of the SSM architecture is that it does 200 not support shared trees which may be useful for supporting 201 many-to-many applications. In the short-term this is not a 202 serious concern since the multicast application space is likely to 203 be dominated by one-to-many applications. Some other classes of 204 multicast applications that are likely to emerge in the future are 205 few-to-few (e.g. private chat rooms, whiteboards), few-to-many 206 (e.g., video conferencing, distance learning) and many-to-many 207 (e.g., large chat rooms, multi-user games). The first two classes 208 can be easily handled using a few one-to-many source-based trees. 210 The issue of many-to-many multicasting service on top of a SSM 211 architecture is an open issue at this point. However, some feel 212 that even many-to-many applications should be handled with 213 multiple one- to-many instead of shared trees. 215 In any case, even though SSM would avoid the problems of ASM, it was 216 felt that SSM is not sufficiently widely available to completely 217 replace ASM (see Section 2.1), and that the IETF should not try to 218 force the application writers to change their multicast usage models. 220 3.2 Implementing MSDP for IPv6 222 In IPv4, notification of multicast sources between these PIM-SM RPs 223 is done with Multicast Source Discovery Protocol (MSDP) [RFC3618]. 224 The protocol is widely considered a sub-optimal solution and even 225 dangerous to deploy; when it was specified, it was only meant as a 226 "stop-gap" measure. 228 The easiest stop-gap solution (to a stop-gap solution) would have 229 been to specify IPv6 TLV's for MSDP. This would be fairly 230 straightforward, and existing implementations would probably be 231 relatively easy to modify. 233 There is and has been resistance to this, as MSDP was not supposed to 234 last this long in the first place; there is clear consensus that 235 there should be no further work on it [I-D.ietf-mboned-msdp-deploy]. 237 3.3 Implementing Another Multicast Routing Protocol 239 One possibility might have been to specify and/or implement a 240 different multicast routing protocol. 242 In fact, Border Gateway Multicast Protocol (BGMP) 243 [I-D.ietf-bgmp-spec] has been specified; however, it is widely held 244 to be quite complex and there have been no implementations, nor will 245 to make any. Lacking deployment experience and specification 246 analysis, it is difficult to say which problems it might solve (and 247 possibly, which new ones to introduce). One probable reason why BGMP 248 failed to attract continuing interest was it's dependance on 249 similarly heavy-weight multicast address allocation/assignment 250 protocols. 252 As of this writing, no other inter-domain protocols have been 253 specified, and BGMP is not considered a realistic option. 255 3.4 Embedding the RP Address in an IPv6 Multicast Address 257 One way to work around these problems was to allocate and assign 258 multicast addresses in such a fashion that the address of the RP 259 could be automatically calculated from the IPv6 multicast address. 261 Making some assumptions about how the RPs would configure Interface 262 Identifiers, this is can achieved as described in 264 [I-D.ietf-mboned-embeddedrp]; PIM-SM implementations need to 265 implement the Embedded RP group-to-RP mapping mechanism which 266 processes this encoding. 268 To completely replace the need for MSDP for IPv6, a different way to 269 implement "Anycast RP" [RFC3446] -technique, for sharing the state 270 information between different RP's in one PIM-SM domain, is also 271 needed. One such approach is described in [I-D.ietf-pim-anycast-rp]. 273 4. Issues with IPv6 Multicast 275 This section describes issues that have come up with IPv6 multicast 276 but have not yet been at least fully resolved. 278 4.1 Issues with Embedded RP 280 4.1.1 RP Failover with Embedded RP 282 Embedded RP provides a means for ASM multicast without inter-domain 283 MSDP. However, to continue providing failover mechanisms for RPs, a 284 form of state sharing, Anycast-RP, should still be supported. 285 Instead of MSDP, this can be achieved using a PIM-SM extension 286 [I-D.ietf-pim-anycast-rp]. 288 One should note that as Embedded RP does not require MSDP peerings 289 between the RPs, it's possible to deploy more RPs in a PIM domain. 290 For example, the scalability and redundancy could be achieved by 291 co-locating RP functionality in the DRs: each major source, which 292 "owns" a group, could have its own DR act as the RP. This has about 293 the same redundancy characteristics as using SSM -- so there may not 294 be an actually very urgent need for Anycast-RP if operational methods 295 to include fate-sharing of the groups is followed. 297 In any case, a "cold failover" variant of anycast-RP, without state 298 sharing, applicable for long-term redundancy, is still an option. In 299 this mechanism, multiple routers would be configured with the RP 300 address, but only one would be active at the time: if the main RP 301 goes down, another takes its place. However, the multicast state 302 stored in the RP would be lost, unless it is synchronized by some 303 out-of-band mechanism. 305 4.1.2 Embedded RP and Control Mechanisms 307 With ASM and MSDP deployment, the ISPs can better control who is 308 using their RPs. 310 With Embedded RP, anyone could use a third-party RP to host their 311 groups unless some mechanisms, for example access-lists, are in place 312 to control the use of the RP [I-D.ietf-mboned-embeddedrp]. 314 Such abuse is of questionable benefit, though, as anyone with a /64 315 could form an RP of its own. 317 Whether this is a sufficiently serious problem worth designing a 318 (potentially complex) solution for is still under debate, as of this 319 writing. 321 4.2 Neighbor Discovery Using Multicast 323 Neighbor Discovery [RFC2461] uses link-local multicast in Ethernet 324 media, not broadcast as ARP does with IPv4. This has been seen to 325 cause operational problems with some equipment. 327 The author has seen one brand of managed Ethernet switches, and heard 328 reports of a few unmanaged switches, that do not forward IPv6 329 link-local multicast packets to other ports at all. In essence, 330 native IPv6 is impossible with this equipment. These problems have 331 likely been fixed in later revisions of the equipment, but this does 332 not fix the equipment on the field, and it is likely that similar 333 problems will surface again. 335 It seems likely that this may be a problem with some switches that 336 build multicast forwarding state based on Layer 3 information (and do 337 not support IPv6); state using Layer 2 information would work just 338 fine [I-D.ietf-magma-snoop]. Therefore the snooping swich developers 339 should be aware of the tradeoff of using Layer 2 vs Layer 3 340 information on multicast data forwarding, especially if IPv6 snooping 341 is not supported. 343 For the deployment of IPv6, it would be important to find out how 344 this can be fixed (e.g., how exactly this breaks specifications) and 345 how one can identify which equipment could cause problems like these 346 (and whether there are workarounds). 348 One workaround might be to implement a toggle in the nodes that would 349 use link-layer broadcast instead of multicast as a fallback solution. 350 However, this would have to be used in all the systems on the same 351 link, otherwise local communication is impaired. 353 4.3 Functionality Like MLD Snooping 355 On Ethernet, multicast frames are forwarded to every port, even 356 without subscribers (or IPv6 support). 358 Especially if multicast traffic is relatively heavy (e.g., video 359 streaming), it becomes particularly important to have some feature 360 like Multicast Listener Discovery (MLD) snooping implemented, to 361 reduce the amount of flooding [I-D.ietf-magma-snoop]. 363 In addition, some vendors have not realized which multicast addresses 364 (in particular, link-local addresses) MLD reports -- utilized in the 365 snooping -- should be generated for. The introduction of MLD 366 snooping could cause hosts which do not send MLD reports 367 appropriately to be blocked out. As specified in [RFC2461], an MLD 368 report must be generated for every group except all-nodes (ff02::1 -- 369 which is forwarded to all ports); this also includes all the other 370 link-local groups. 372 Looking at the actual problem from a higher view, it is not clear 373 that MLD snooping is the right long-term solution. It makes the 374 switches complex, requires the processing of datagrams above the 375 link-layer, and should be discouraged 376 [I-D.ietf-mboned-iesg-gap-analysis]: the whole idea of L2-only 377 devices having to peek into L3 datagrams seems like a severe layering 378 violation -- and often the devices aren't upgradeable (if there are 379 bugs or missing features, which could be fixed later) in any way. 380 Better mechanisms could be having routers tell switches which 381 multicasts to forward where (e.g., [CGMP]) or by using some other 382 mechanisms [GARP]. 384 5. Security Considerations 386 Only deployment and implementation issues are considered, and these 387 do not have any particular security considerations; security 388 considerations for each technology are covered in the respective 389 specifications. 391 6. Acknowledgements 393 Early discussions with Stig Venaas, Jerome Durand, Tim Chown et al. 394 led to the writing of this draft. Brian Haberman offered extensive 395 comments along the way. "Itojun" Hagino brought up the need for MLD 396 snooping in a presentation. Bill Nickless pointed out issues in the 397 gap analysis and provided a pointer to GARP/GMRP; Havard Eidnes made 398 a case for a protocol like CGMP. Leonard Giuliano pointed out a more 399 complete analysis of SSM with different kind of applications. 401 7. References 403 7.1 Normative References 405 [I-D.ietf-bgmp-spec] 406 Thaler, D., "Border Gateway Multicast Protocol (BGMP): 407 Protocol Specification", draft-ietf-bgmp-spec-06 (work in 408 progress), January 2004. 410 [I-D.ietf-mboned-embeddedrp] 411 Savola, P. and B. Haberman, "Embedding the Rendezvous 412 Point (RP) Address in an IPv6 Multicast Address", 413 draft-ietf-mboned-embeddedrp-07 (work in progress), July 414 2004. 416 [I-D.ietf-mboned-msdp-deploy] 417 McBride, M., "Multicast Source Discovery Protocol (MSDP) 418 Deployment Scenarios", draft-ietf-mboned-msdp-deploy-06 419 (work in progress), March 2004. 421 [I-D.ietf-pim-anycast-rp] 422 Farinacci, D., "Anycast-RP using PIM", 423 draft-ietf-pim-anycast-rp-02 (work in progress), June 424 2004. 426 [I-D.ietf-pim-sm-v2-new] 427 Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, 428 "Protocol Independent Multicast - Sparse Mode PIM-SM): 429 Protocol Specification (Revised)", 430 draft-ietf-pim-sm-v2-new-10 (work in progress), July 2004. 432 [I-D.ietf-ssm-arch] 433 Holbrook, H. and B. Cain, "Source-Specific Multicast for 434 IP", draft-ietf-ssm-arch-05 (work in progress), July 2004. 436 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 437 Discovery for IP Version 6 (IPv6)", RFC 2461, December 438 1998. 440 [RFC3446] Kim, D., Meyer, D., Kilmer, H. and D. Farinacci, "Anycast 441 Rendevous Point (RP) mechanism using Protocol Independent 442 Multicast (PIM) and Multicast Source Discovery Protocol 443 (MSDP)", RFC 3446, January 2003. 445 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 446 Protocol (MSDP)", RFC 3618, October 2003. 448 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 449 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 451 7.2 Informative References 453 [CGMP] "Cisco Group Management Protocol", 454 . 456 [GARP] Tobagi, F., Molinero-Fernandez, P. and M. Karam, "Study of 457 IEEE 802.1p GARP/GMRP Timer Values", 1997. 459 [I-D.bhattach-diot-pimso] 460 Bhattacharyya, S., Diot, C., Giuliano, L. and R. Rockell, 461 "Deployment of PIM-SO at Sprint (PIM-SO)", March 2000. 463 [I-D.ietf-magma-snoop] 464 Christensen, M., Kimball, K. and F. Solensky, 465 "Considerations for IGMP and MLD Snooping Switches", 466 draft-ietf-magma-snoop-11 (work in progress), May 2004. 468 [I-D.ietf-mboned-iesg-gap-analysis] 469 Meyer, D. and B. Nickless, "Internet Multicast Gap 470 Analysis from the MBONED Working Group for the IESG", 471 draft-ietf-mboned-iesg-gap-analysis-00 (work in progress), 472 July 2002. 474 [I-D.ietf-pim-sm-bsr] 475 Fenner, B., "Bootstrap Router (BSR) Mechanism for PIM", 476 draft-ietf-pim-sm-bsr-04 (work in progress), July 2004. 478 [RFC3678] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface 479 Extensions for Multicast Source Filters", RFC 3678, 480 January 2004. 482 [SSMSNOOP] 483 "Operational Problems with IGMP snooping switches", March 484 2003, . 486 Author's Address 488 Pekka Savola 489 CSC/FUNET 490 Espoo 491 Finland 493 EMail: psavola@funet.fi 495 Intellectual Property Statement 497 The IETF takes no position regarding the validity or scope of any 498 Intellectual Property Rights or other rights that might be claimed to 499 pertain to the implementation or use of the technology described in 500 this document or the extent to which any license under such rights 501 might or might not be available; nor does it represent that it has 502 made any independent effort to identify any such rights. Information 503 on the procedures with respect to rights in RFC documents can be 504 found in BCP 78 and BCP 79. 506 Copies of IPR disclosures made to the IETF Secretariat and any 507 assurances of licenses to be made available, or the result of an 508 attempt made to obtain a general license or permission for the use of 509 such proprietary rights by implementers or users of this 510 specification can be obtained from the IETF on-line IPR repository at 511 http://www.ietf.org/ipr. 513 The IETF invites any interested party to bring to its attention any 514 copyrights, patents or patent applications, or other proprietary 515 rights that may cover technology that may be required to implement 516 this standard. Please address the information to the IETF at 517 ietf-ipr@ietf.org. 519 Disclaimer of Validity 521 This document and the information contained herein are provided on an 522 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 523 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 524 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 525 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 526 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 527 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 529 Copyright Statement 531 Copyright (C) The Internet Society (2004). This document is subject 532 to the rights, licenses and restrictions contained in BCP 78, and 533 except as set forth therein, the authors retain all their rights. 535 Acknowledgment 537 Funding for the RFC Editor function is currently provided by the 538 Internet Society.