idnits 2.17.1 draft-ietf-mboned-ipv6-multicast-issues-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 518. ** 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 (September 2, 2004) is 7174 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 475, 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. -------------------------------------------------------------------------------- 1 MBONE Deployment WG P. Savola 2 Internet-Draft CSC/FUNET 3 Expires: March 3, 2005 September 2, 2004 5 IPv6 Multicast Deployment Issues 6 draft-ietf-mboned-ipv6-multicast-issues-01.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 3, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 This memo describes known issues with IPv6 multicast, and provides 42 historical reference of how some earlier problems have been resolved. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1 Multicast-related Abbreviations . . . . . . . . . . . . . 3 48 2. Justification for IPv6 Inter-domain ASM . . . . . . . . . . . 3 49 2.1 SSM Deployment Issues . . . . . . . . . . . . . . . . . . 3 50 2.2 Groups of Different Non-global Scope . . . . . . . . . . . 4 51 3. Different Solutions to Inter-domain Multicast . . . . . . . . 5 52 3.1 Changing the Multicast Usage Model . . . . . . . . . . . . 5 53 3.2 Implementing MSDP for IPv6 . . . . . . . . . . . . . . . . 6 54 3.3 Implementing Another Multicast Routing Protocol . . . . . 6 55 3.4 Embedding the RP Address in an IPv6 Multicast Address . . 6 56 4. Issues with IPv6 Multicast . . . . . . . . . . . . . . . . . . 7 57 4.1 Issues with Embedded RP . . . . . . . . . . . . . . . . . 7 58 4.1.1 RP Failover with Embedded RP . . . . . . . . . . . . . 7 59 4.1.2 Embedded RP and Control Mechanisms . . . . . . . . . . 7 60 4.2 Neighbor Discovery Using Multicast . . . . . . . . . . . . 8 61 4.3 Functionality Like MLD Snooping . . . . . . . . . . . . . 8 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 66 7.2 Informative References . . . . . . . . . . . . . . . . . . . 10 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 68 Intellectual Property and Copyright Statements . . . . . . . . 12 70 1. Introduction 72 There are many issues concerning the deployment and implementation, 73 and to a lesser degree, specification of IPv6 multicast. This memo 74 describes known problems to raise awareness, and documents how 75 previous problems have been resolved. 77 Section 2 describes the justifications for providing an inter-domain 78 multicast solution using Any Source Multicast (ASM) with IPv6. 79 Section 3 in turn describes which options were considered for filling 80 those the requirements for the IPv6 inter-domain multicast solutions. 81 These sections are provided for historical reference of the 82 discussion and consensus in the IETF MBONED working group. 84 Section 4 lists issues that have come up with IPv6 multicast but have 85 not yet been at least fully resolved, and may require raised 86 awareness. 88 1.1 Multicast-related Abbreviations 90 ASM Any Source Multicast 91 BSR Bootstrap Router 92 CGMP Cisco Group Management Protocol 93 DR Designated Router 94 IGMP Internet Group Management Protocol 95 MLD Multicast Listener Discovery 96 MSDP Multicast Source Discovery Protocol 97 PIM Protocol Independent Multicast 98 PIM-SM Protocol Independent Multicast - Sparse Mode 99 RP Rendezvous Point 100 SSM Source-specific Multicast 102 2. Justification for IPv6 Inter-domain ASM 104 This section documents the reasons and the discussion which led to 105 the agreement why a solution to IPv6 inter-domain ASM was necessary. 107 The main reason was that SSM [I-D.ietf-ssm-arch] was not considered 108 to solve all the relevant problems (e.g., many-to-many applications, 109 source discovery), and that SSM was not sufficiently widely deployed 110 and used. 112 2.1 SSM Deployment Issues 114 To be deployed, SSM requires changes to: 116 1. routers 117 2. IGMP/MLD-snooping Ethernet switches 119 3. hosts 121 4. application programming interfaces (APIs) 123 5. multicast usage models 125 Introducing SSM support in the routers has been straightforward as 126 PIM-SSM is a subset of PIM-SM [I-D.ietf-pim-sm-v2-new]. 128 IGMP-snooping Ethernet switches have been a more difficult issue 129 [SSMSNOOP]; some which perform IGMPv2 snooping discard IGMPv3 reports 130 or queries, or multicast transmissions associated to them. If MLDv1 131 snooping had been implemented (or is implemented in a similar 132 manner), this would likely have affected that as well. 134 Host systems require MLDv2 [RFC3810] support. The situation has 135 improved with respect to MLDv2 support for end systems, and 136 interoperability has increased after the publication of the RFC due 137 to the stabilization of the ICMP types used. 139 The multicast source filtering API specification has also been 140 completed [RFC3678]; its deployment is likely roughly equal (or 141 slightly worse) than MLDv2. The API is required for creating 142 (cross-platform) SSM applications. 144 The most difficult issue, multicast usage models, remains a problem 145 as of this writing. SSM is an excellent fit for one-to-many 146 distribution topologies, and porting such applications to use SSM 147 would likely be rather simple. However, a significant number of 148 current applications are many-to-many (e.g., conferencing 149 applications) which cannot be converted to SSM without significant 150 effort, including, for example, out-of-band source discovery. For 151 such applications to be usable for IPv6 at least in a short to medium 152 term, ASM -like techniques seem to be required. 154 2.2 Groups of Different Non-global Scope 156 Many ASM applications are used with a smaller scope than global; some 157 of these have a wider scope than others. However, groups of smaller 158 scope typically need to be in their own PIM-SM domains to prevent 159 inappropriate data leakage. Therefore if a site has groups of 160 different scopes, having multiple PIM domain borders becomes a 161 requirement unless inter-domain multicast is used instead; further, 162 configuring such nesting scopes would likely be an operational 163 challenge. In consequence, if these applications of non-global scope 164 need to be used, inter-domain multicast support is practically 165 required. 167 In consequence, especially if multicast with different non-global 168 scopes is used, there will be a need for inter-domain multicast 169 solutions. As many applications are relying on ASM characteristics, 170 this further increases a need for an inter-domain ASM solution. 172 3. Different Solutions to Inter-domain Multicast 174 When ASM is used, the Internet must be divided to multiple PIM-SM for 175 both administrative and technical reasons, which means there will be 176 multiple PIM-SM RPs which need to communicate the information of 177 sources between themselves. 179 On the other hand, SSM does not require RPs and also works in the 180 inter-domain without such communication. Section 2 describes the 181 justification why Inter-domain ASM was still considered to be 182 required. This section describes different solutions which were 183 discussed to providing inter-domain multicast for IPv6. 185 For inter-domain multicast, there is consensus to continue using SSM, 186 and also use Embedded-RP as appropriate. 188 This section provides historical reference of the discussion and 189 decisions. 191 3.1 Changing the Multicast Usage Model 193 As ASM model has been found to be complex and a bit problematic, some 194 felt that this is a good incentive to move to SSM for good (at least 195 for most cases). Below two paragraphs are adapted from 196 [I-D.bhattach-diot-pimso]: 198 The most serious criticism of the SSM architecture is that it does 199 not support shared trees which may be useful for supporting 200 many-to-many applications. In the short-term this is not a 201 serious concern since the multicast application space is likely to 202 be dominated by one-to-many applications. Some other classes of 203 multicast applications that are likely to emerge in the future are 204 few-to-few (e.g. private chat rooms, whiteboards), few-to-many 205 (e.g., video conferencing, distance learning) and many-to-many 206 (e.g., large chat rooms, multi-user games). The first two classes 207 can be easily handled using a few one-to-many source-based trees. 209 The issue of many-to-many multicasting service on top of a SSM 210 architecture is an open issue at this point. However, some feel 211 that even many-to-many applications should be handled with 212 multiple one- to-many instead of shared trees. 214 In any case, even though SSM would avoid the problems of ASM, it was 215 felt that SSM is not sufficiently widely available to completely 216 replace ASM (see Section 2.1), and that the IETF should not try to 217 force the application writers to change their multicast usage models. 219 3.2 Implementing MSDP for IPv6 221 In IPv4, notification of multicast sources between these PIM-SM RPs 222 is done with Multicast Source Discovery Protocol (MSDP) [RFC3618]. 223 The protocol is widely considered a sub-optimal solution and even 224 dangerous to deploy; when it was specified, it was only meant as a 225 "stop-gap" measure. 227 The easiest stop-gap solution (to a stop-gap solution) would have 228 been to specify IPv6 TLV's for MSDP. This would be fairly 229 straightforward, and existing implementations would probably be 230 relatively easy to modify. 232 There is and has been resistance to this, as MSDP was not supposed to 233 last this long in the first place; there is clear consensus that 234 there should be no further work on it [I-D.ietf-mboned-msdp-deploy]. 236 3.3 Implementing Another Multicast Routing Protocol 238 One possibility might have been to specify and/or implement a 239 different multicast routing protocol. 241 In fact, Border Gateway Multicast Protocol (BGMP) 242 [I-D.ietf-bgmp-spec] has been specified; however, it is widely held 243 to be quite complex and there have been no implementations, nor will 244 to make any. Lacking deployment experience and specification 245 analysis, it is difficult to say which problems it might solve (and 246 possibly, which new ones to introduce). One probable reason why BGMP 247 failed to attract continuing interest was it's dependance on 248 similarly heavy-weight multicast address allocation/assignment 249 protocols. 251 As of this writing, no other inter-domain protocols have been 252 specified, and BGMP is not considered a realistic option. 254 3.4 Embedding the RP Address in an IPv6 Multicast Address 256 One way to work around these problems was to allocate and assign 257 multicast addresses in such a fashion that the address of the RP 258 could be automatically calculated from the IPv6 multicast address. 260 Making some assumptions about how the RPs would configure Interface 261 Identifiers, this is can achieved as described in 263 [I-D.ietf-mboned-embeddedrp]; PIM-SM implementations need to 264 implement the Embedded RP group-to-RP mapping mechanism which 265 processes this encoding. 267 To completely replace the need for MSDP for IPv6, a different way to 268 implement "Anycast RP" [RFC3446] -technique, for sharing the state 269 information between different RP's in one PIM-SM domain, is also 270 needed. One such approach is described in [I-D.ietf-pim-anycast-rp]. 272 4. Issues with IPv6 Multicast 274 This section describes issues that have come up with IPv6 multicast 275 but have not yet been at least fully resolved. 277 4.1 Issues with Embedded RP 279 4.1.1 RP Failover with Embedded RP 281 Embedded RP provides a means for ASM multicast without inter-domain 282 MSDP. However, to continue providing failover mechanisms for RPs, a 283 form of state sharing, Anycast-RP, should still be supported. 284 Instead of MSDP, this can be achieved using a PIM-SM extension 285 [I-D.ietf-pim-anycast-rp]. 287 One should note that as Embedded RP does not require MSDP peerings 288 between the RPs, it's possible to deploy more RPs in a PIM domain. 289 For example, the scalability and redundancy could be achieved by 290 co-locating RP functionality in the DRs: each major source, which 291 "owns" a group, could have its own DR act as the RP. This has about 292 the same redundancy characteristics as using SSM -- so there may not 293 be an actually very urgent need for Anycast-RP if operational methods 294 to include fate-sharing of the groups is followed. 296 In any case, "cold failover" redundancy without state sharing is 297 still an option. This does not offer any load-balancing of RPs or 298 shared trees, but provides only long-term redundancy. In this 299 mechanism, multiple routers would be configured with the RP address 300 (with appropriate unicast metrics), but only one of them would be 301 active at any time: if the main RP goes down, another takes its 302 place. However, the multicast state stored in the RP would be lost, 303 unless it is synchronized by some 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): 408 Protocol Specification", draft-ietf-bgmp-spec-06 (work in 409 progress), January 2004. 411 [I-D.ietf-mboned-embeddedrp] 412 Savola, P. and B. Haberman, "Embedding the Rendezvous 413 Point (RP) Address in an IPv6 Multicast Address", 414 draft-ietf-mboned-embeddedrp-07 (work in progress), July 415 2004. 417 [I-D.ietf-mboned-msdp-deploy] 418 McBride, M., "Multicast Source Discovery Protocol (MSDP) 419 Deployment Scenarios", draft-ietf-mboned-msdp-deploy-06 420 (work in progress), March 2004. 422 [I-D.ietf-pim-anycast-rp] 423 Farinacci, D., "Anycast-RP using PIM", 424 draft-ietf-pim-anycast-rp-02 (work in progress), June 425 2004. 427 [I-D.ietf-pim-sm-v2-new] 428 Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, 429 "Protocol Independent Multicast - Sparse Mode PIM-SM): 430 Protocol Specification (Revised)", 431 draft-ietf-pim-sm-v2-new-10 (work in progress), July 2004. 433 [I-D.ietf-ssm-arch] 434 Holbrook, H. and B. Cain, "Source-Specific Multicast for 435 IP", draft-ietf-ssm-arch-05 (work in progress), July 2004. 437 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 438 Discovery for IP Version 6 (IPv6)", RFC 2461, December 439 1998. 441 [RFC3446] Kim, D., Meyer, D., Kilmer, H. and D. Farinacci, "Anycast 442 Rendevous Point (RP) mechanism using Protocol Independent 443 Multicast (PIM) and Multicast Source Discovery Protocol 444 (MSDP)", RFC 3446, January 2003. 446 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 447 Protocol (MSDP)", RFC 3618, October 2003. 449 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 450 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 452 7.2 Informative References 454 [CGMP] "Cisco Group Management Protocol", 455 . 457 [GARP] Tobagi, F., Molinero-Fernandez, P. and M. Karam, "Study of 458 IEEE 802.1p GARP/GMRP Timer Values", 1997. 460 [I-D.bhattach-diot-pimso] 461 Bhattacharyya, S., Diot, C., Giuliano, L. and R. Rockell, 462 "Deployment of PIM-SO at Sprint (PIM-SO)", March 2000. 464 [I-D.ietf-magma-snoop] 465 Christensen, M., Kimball, K. and F. Solensky, 466 "Considerations for IGMP and MLD Snooping Switches", 467 draft-ietf-magma-snoop-11 (work in progress), May 2004. 469 [I-D.ietf-mboned-iesg-gap-analysis] 470 Meyer, D. and B. Nickless, "Internet Multicast Gap 471 Analysis from the MBONED Working Group for the IESG", 472 draft-ietf-mboned-iesg-gap-analysis-00 (work in progress), 473 July 2002. 475 [I-D.ietf-pim-sm-bsr] 476 Fenner, B., "Bootstrap Router (BSR) Mechanism for PIM", 477 draft-ietf-pim-sm-bsr-04 (work in progress), July 2004. 479 [RFC3678] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface 480 Extensions for Multicast Source Filters", RFC 3678, 481 January 2004. 483 [SSMSNOOP] 484 "Operational Problems with IGMP snooping switches", March 485 2003, . 487 Author's Address 489 Pekka Savola 490 CSC/FUNET 491 Espoo 492 Finland 494 EMail: psavola@funet.fi 496 Intellectual Property Statement 498 The IETF takes no position regarding the validity or scope of any 499 Intellectual Property Rights or other rights that might be claimed to 500 pertain to the implementation or use of the technology described in 501 this document or the extent to which any license under such rights 502 might or might not be available; nor does it represent that it has 503 made any independent effort to identify any such rights. Information 504 on the procedures with respect to rights in RFC documents can be 505 found in BCP 78 and BCP 79. 507 Copies of IPR disclosures made to the IETF Secretariat and any 508 assurances of licenses to be made available, or the result of an 509 attempt made to obtain a general license or permission for the use of 510 such proprietary rights by implementers or users of this 511 specification can be obtained from the IETF on-line IPR repository at 512 http://www.ietf.org/ipr. 514 The IETF invites any interested party to bring to its attention any 515 copyrights, patents or patent applications, or other proprietary 516 rights that may cover technology that may be required to implement 517 this standard. Please address the information to the IETF at 518 ietf-ipr@ietf.org. 520 Disclaimer of Validity 522 This document and the information contained herein are provided on an 523 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 524 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 525 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 526 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 527 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 528 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 530 Copyright Statement 532 Copyright (C) The Internet Society (2004). This document is subject 533 to the rights, licenses and restrictions contained in BCP 78, and 534 except as set forth therein, the authors retain all their rights. 536 Acknowledgment 538 Funding for the RFC Editor function is currently provided by the 539 Internet Society.