idnits 2.17.1 draft-holbrook-ssm-arch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IANA-ALLOCATION], [IGMPv3], [IGMPSSM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 9 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 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 332 has weird spacing: '...equired modif...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (24 November 2000) is 8525 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) == Missing Reference: 'RFC 2119' is mentioned on line 33, but not defined == Unused Reference: 'RFC2119' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'IGMPv2' is defined on line 507, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-ALLOCATION' -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv3' ** Downref: Normative reference to an Informational RFC: RFC 2771 ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM-DM' ** Obsolete normative reference: RFC 2362 (ref. 'PIM-SM') (Obsoleted by RFC 4601, RFC 5059) ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. 'DVMRP') ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPSSM' -- Possible downref: Non-RFC (?) normative reference: ref. 'EXPRESS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MSFAPI' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Source-Specific Multicast H. Holbrook 2 Expires May 24, 2001 Cisco Systems 3 B. Cain 4 Mirror Image Internet 5 24 November 2000 7 Source-Specific Multicast for IP 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC 2119]. 34 Abstract 36 IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 37 (currently) designated as source-specific multicast (SSM) destination 38 addresses and are reserved for use by source-specific applications and 39 protocols [IANA-ALLOCATION]. This document defines the semantics of 40 source-specific multicast addresses and specifies the policies governing 41 their use. It defines an extension to the Internet network service that 42 applies to datagrams sent to SSM addresses and defines the host and 43 router requirements to support this extension. 45 A companion document, [IGMPSSM], describes how the Internet Group 46 Management Protocol Version 3 (IGMPv3) [IGMPv3] can be adapted to 47 support source-specific multicast. 49 1. Overview and Rationale 51 The Internet Protocol (IP) multicast service model is defined in RFC 52 1112 [RFC1112]. RFC 1112 specifies that a datagram sent to an IP class 53 D address (224.0.0.0 through 239.255.255.255) G is delivered to each 54 "upper-layer protocol module" that has requested reception of datagrams 55 sent to address G. RFC 1112 calls the network service identified by a 56 multicast destination address G a "host group." This model supports 57 both one-to-many and many-to-many group communication. This document 58 uses the term "Any-Source Multicast" (ASM) to refer to the RFC 1112 59 model of multicast. 61 IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 62 currently designated as source-specific multicast (SSM) destination 63 addresses and are reserved for use by source-specific applications and 64 protocols [IANA-ALLOCATION]. 66 Source-Specific Multicast delivery semantics are provided for a datagram 67 sent to an SSM address. That is, a datagram with source IP address S 68 and SSM destination address G is delivered to each upper-layer "socket" 69 that has specifically requested the reception of datagrams sent to 70 address G by source S, and only to those sockets. The network service 71 identified by (S,G), for SSM address G and source host address S, is 72 referred to as a "channel." In contrast to the ASM model of RFC 1112, 73 SSM provides network-layer support for one-to-many delivery only. 75 The benefits of source-specific multicast include: 77 Elimination of cross-delivery of traffic when two sources 78 simultaneously use the same source-specific destination address. 79 The simultaneous use of an SSM destination address by multiple 80 sources is explicitly supported. 82 Avoidance of the need for inter-host coordination when choosing 83 source-specific addresses, as a consequence of the above. 85 Avoidance of many of the router protocols and algorithms that are 86 needed to provide the ASM service model. For instance, the "shared 87 trees" and Rendezvous Points of the PIM-Sparse Mode (PIM-SM) 88 protocol are not necessary to support the source-specific address 89 range. The router mechanisms required to support SSM are not new, 90 and are in fact largely a subset of those required to support ASM. 91 For example, the PIM-SM protocol can be adapted easily to provide 92 SSM, by using the shortest-path tree mechanism of PIM-SM. 94 Like ASM, SSM is receiver-driven, and the receivers are unknown to the 95 sender. An SSM source is provided with neither the identity of receivers 96 nor their number. 98 This document defines the semantics of source-specific multicast 99 addresses and specifies the policies governing their use. In 100 particular, it defines an extension to the Internet network service that 101 applies to datagrams sent to SSM addresses and defines host extensions 102 to support the network service. Hosts, routers, applications, and 103 protocols that use these addresses MUST comply with the policies 104 outlined in this document. Failure of a host to comply may prevent that 105 host or other hosts on the same LAN from receiving traffic sent to an 106 SSM channel. Failure of a router to comply may cause SSM traffic to be 107 delivered to parts of the network where it is unwanted, unnecessarily 108 burdening the network. 110 2. Semantics of Source-Specific Multicast Addresses 112 The source-specific multicast service is defined as follows: 114 A datagram sent with source IP address S and destination IP address 115 G in the SSM range is delivered to each host socket that has 116 specifically requested delivery of datagrams sent by S to G, and 117 only to those sockets. 119 Where, using the terminology of [IGMPv3], 121 "socket" is an implementation-specific parameter used to distinguish 122 among different requesting entities (e.g., programs or processes or 123 communication end-points within a program or process) within the 124 requesting host; the socket parameter of BSD Unix system calls is a 125 specific example. 127 Any host may send a datagram to any SSM address, and delivery is 128 provided according to the above semantics. 130 The IP module interface to upper-layer protocols is extended to allow a 131 socket to "Subscribe" to or "Unsubscribe" from a particular channel 132 identified by an SSM destination address and a source IP address. The 133 extended interface is defined in section 4.1. It is meaningless for an 134 application or host to request reception of datagrams sent to an SSM 135 destination address G, as is supported in "classic" IP Multicast (Any- 136 Source Multicast), without also specifying a corresponding source 137 address, and routers MUST ignore any such request from a host, pursuant 138 to [IGMPSSM]. 140 Multiple source applications on different hosts can use the same SSM 141 destination address G without conflict because datagrams sent by each 142 source host Si are delivered only to those sockets that requested 143 delivery of datagrams sent to G specifically by Si. 145 The key distinguishing property of the model is that a channel is 146 identified (addressed) by the combination of a unicast source address 147 and a multicast destination address in the SSM range. So, for example 148 the channel 150 S,G = (36.18.0.1, 232.7.8.9) 152 differs from 154 S,G = (36.18.0.2, 232.7.8.9), 156 even though they have the same destination address portion. 158 3. Terminology 160 To avoid confusion between Internet Standard Multicast and Source- 161 Specific Multicast, we use different terminology when discussing the two 162 service models. 164 We use the term "channel" to refer to the service associated with an SSM 165 address. A channel is identified by the combination of an SSM 166 destination address and a specific source, e.g., an (S,G) pair. 168 We use the term "host group" (used in RFC 1112) to refer to the service 169 associated with "regular" class D addresses (excluding those in the SSM 170 range). A host group is identified by a single class D address. 172 Any host can send to a host group, and similarly, any host can send to 173 an SSM destination address. A packet sent by a host S to an ASM 174 destination address G is delivered to the host group identified by G. A 175 packet sent by host S to an SSM destination address G is delivered to 176 the channel identified by (S,G). The receiver operations allowed on a 177 host group are called "join(G)" and "leave(G)" (as per RFC 1112). The 178 receiver operations allowed on a channel are called "Subscribe(S,G)" and 179 "Unsubscribe(S,G)." 181 The following table summarizes the terminology: 183 Service Model: Any-Source Source-Specific 184 Network Abstraction: group channel 185 Identifier: G S,G 186 Receiver Operations: join, leave subscribe, unsubscribe 188 We note that, although this document specifies a new service model 189 available to applications, the protocols and techniques necessary to 190 support the service model are largely a subset of those used to support 191 ASM. 193 4. Host Requirements 195 This section describes requirements on hosts that support Source- 196 Specific Multicast, including: 198 - Extensions to the IP Module Interface 200 - Extensions to the IP Module 202 - Allocation of SSM Addresses 204 4.1. Extensions to the IP Module Interface 206 The IP module interface to upper-layer protocols is extended to allow 207 protocols to request reception of all datagrams sent to a particular 208 channel. 210 Subscribe ( socket, source-address, group-address, interface ) 212 Unsubscribe ( socket, source-address, group-address, interface ) 214 where 216 "socket" is as previously defined, 218 and, paraphrasing [IGMPv3], 220 "interface" is a local identifier of the network interface on which 221 reception of the channel identified by the (source-address,group- 222 address) pair is to be enabled or disabled. A special value may be 223 used to indicate a "default" interface. If reception of the same 224 channel is desired on multiple interfaces, Subscribe is invoked once 225 for each. 227 The above are strictly abstract functional interfaces -- the 228 functionality can be provided in an implementation-specific way. On a 229 host that supports the full IGMPv3 application programming interface of 230 [MSFAPI], Subscribe and Unsubscribe may be supported via that API. 232 Widespread implementations of the IP packet reception interface (e.g., 233 the recvfrom() system call in BSD unix) do not allow a receiver to 234 determine the destination address to which a datagram was sent. On a 235 host with such an implementation, the destination address of a datagram 236 cannot be inferred when the socket on which the datagram is received is 237 Subscribed to multiple channels. Host operating systems SHOULD provide 238 a way for a host to determine both the source and the destination 239 address to which a datagram was sent. (As one example, the Linux 240 operating system provides the destination of a packet as part of the 241 response to the recvmsg() system call.) Until this capability is 242 present, applications are forced to use higher-layer mechanisms to 243 identify the channel to which a datagram was sent. 245 4.2. Requirements on the Host IP Module 247 An incoming datagram destined to an SSM address MUST be delivered by the 248 IP module to all sockets that have indicated (via Subscribe) a desire to 249 receive data that matches the datagram's source address, destination 250 address, and arriving interface. It MUST NOT be delivered to other 251 sockets. 253 When the first socket on host H subscribes to a channel (S,G) on 254 interface I, the host IP module on H sends a request on interface I to 255 indicate to neighboring routers that the host wishes to receive traffic 256 sent by source S to source-specific destination G. Similarly, when the 257 last socket on a host unsubscribes from a channel on interface I, the 258 host IP module sends an unsubscription request for that channel out 259 interface I. 261 These requests will typically be IGMPv3 messages, and the exact rules 262 for sending source-specific subscription and unsubscription requests and 263 the algorithms used to maintain subscriptions are defined in [IGMPSSM]. 265 4.3. Allocation of Source-Specific Multicast Addresses 267 The SSM destination address 232.0.0.0 is reserved, and hosts MUST NOT 268 send datagrams with destination address of 232.0.0.0. The address range 269 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. 271 The policy for allocating the rest of the SSM addresses to sending 272 applications is strictly locally determined at the sender's host. 274 When allocating SSM addresses dynamically, a host or host operating 275 system MUST NOT allocate sequentially from the first allowed address. 276 As described in Section 6, the mapping of an IP packet with SSM 277 destination address onto a link-layer multicast address does not take 278 into account the datagram's source IP address (on commonly-used link 279 layers like Ethernet). If all hosts started at the first allowed 280 address, then with high probability, many source-specific channels on 281 shared-medium local area networks would collide on the same link-layer 282 multicast address. As a result, traffic destined for one channel member 283 would burden another as the link-layer (unaware of the IP Source 284 Address) accepts the multicast datagram, passes it to the IP layer, 285 which then simply rejects it. 287 It is RECOMMENDED to allocate SSM addresses to applications randomly, 288 while ensuring that allocated addresses are not given simultaneously to 289 multiple applications and avoiding the reserved space, and while 290 avoiding the IANA reserved range. 292 A host operating system SHOULD provide an interface to allow an 293 application to request a unique allocation of a channel destination 294 address in advance of a session's commencement, and this allocation 295 database SHOULD persist across host reboots. By providing persistent 296 allocations, a host application can advertise the session in advance of 297 its start time on a web page or in another directory. (We note that 298 this issue is not specific to SSM applications -- the same problem 299 arises when ASM is used.) 301 This document neither defines the interfaces for requesting or returning 302 addresses nor specifies the host algorithms for storing those 303 allocations. One plausible abstract API is defined in RFC 2771 304 [RFC2771], although the interface of RFC 2771 allows an application to 305 request an address from a specific sub-range of the SSM allocation. 306 This is NOT RECOMMENDED for SSM, unless the start address of the allowed 307 range is selected at random. Randomization is essential to minimize 308 link-layer address collisions. 310 No globally agreed-upon administratively-scoped address range [ADMIN- 311 SCOPE] is needed for the source-specific multicast range because there 312 is no possibility of address conflict between hosts in different 313 administrative domains (or between two hosts of any kind). 314 Administrative scoping of SSM addresses MAY be implemented within an 315 administrative domain by filtering at domain boundary routers. 317 5. Router Requirements 319 5.1. Packet Forwarding 321 A router that receives an IP datagram with a source-specific destination 322 address MUST silently drop it unless a neighboring host or router has 323 communicated a desire to receive packets sent to the source and 324 destination address of the received packet. 326 5.2. Protocols 328 Certain IP multicast routing protocols already have the ability to 329 communicate source-specific joins to neighboring routers (in particular, 330 PIM-SM), and these protocols can, with slight modifications, be used to 331 provide source-specific semantics. Companion documents will specify the 332 required modifications to those protocols to support the source- 333 specific address range. 335 A network can concurrently support SSM semantics in the SSM address 336 range and Any-Source Multicast in the rest of the class D address space, 337 and it is expected that this will be commonplace. In such a network, a 338 router may receive a non-source-specific, or "(*,G)" in conventional 339 terminology, request for delivery of traffic in the SSM range from a 340 neighbor that does not implement source-specific multicast in a manner 341 compliant with this document. A router that receives such a non-source- 342 specific request for data in the SSM range MUST NOT use the request to 343 establish forwarding state and MUST NOT propagate the request to other 344 neighboring routers. This applies both to any request received from a 345 host, e.g., an IGMPv1 or IGMPv2 host report, and to any request received 346 from a routing protocol, e.g., a PIM-SM (*,G) join [PIM-SM]. The inter- 347 router case is further discussed in section 8, Transition 348 Considerations. 350 It is essential that all routers in the network give source-specific 351 semantics to the same range of addresses in order to achieve the full 352 benefit of SSM. To comply with this specification, a router MUST treat 353 ALL SSM addresses with source-specific semantics. 355 6. Link-Layer Transmission of Datagrams 357 Source-specific multicast packets are transmitted on link-layer networks 358 as specified in RFC 1112. On most shared-medium link-layer networks 359 that support multicast (e.g., Ethernet), the IP source address is not 360 used in the selection of the link-layer destination address. 361 Consequently, on such a network, all packets sent to destination address 362 G will be delivered to any host that has subscribed to any channel 363 (S,G), regardless of S. And therefore, the IP module MUST filter 364 packets it receives from the link layer before delivering them to the 365 socket layer. A socket on which an (S,G) subscription has been 366 requested MUST receive packets whose source and destination address 367 match the requested subscription(s) for that socket. 369 7. Security Considerations 371 7.1. Denial-of-Service 373 A subscription request creates (S,G) state in a router to record the 374 subscription and invokes processing on that router and possibly causes 375 processing at neighboring routers. A host can mount a denial of service 376 attack by requesting a large number of subscriptions. A denial of 377 service can result if: 379 - a large amount of traffic arrives when it was otherwise undesired, 380 consuming network resources to deliver it and host resources to drop 381 it 383 - a large amount of source-specific multicast state is created in 384 network routers, using router memory and CPU resources to store and 385 process the state 387 - a large amount of control traffic is generated to manage the 388 source-specific state, using router CPU and network bandwidth 390 To reduce the damage from such an attack, a router MAY have a 391 configuration option to limit the following items: 393 - The total rate at which all hosts on any one interface are allowed 394 to initiate subscriptions (to limit the damage caused by forged 395 source-address attacks) 397 - The total number of subscriptions that can be initated from any 398 single interface. 400 Any decision by an implementor to artificially limit the rate or number 401 of subscriptions should be taken carefully, however, as future 402 applications may use large numbers of channels. Tight limits on the 403 rate or number of channel subscriptions would inhibit the deployment of 404 such applications. 406 A router SHOULD verify that the source of a subscription request is a 407 valid address for the interface on which it was received. Failure to do 408 so would exacerbate a spoofed-source address attack. 410 We note that these attacks are not unique to SSM -- they are also 411 present for Any-Source Multicast. 413 7.2. Spoofed Source Addresses 415 By forging the source address in a datagram, an attacker can potentially 416 violate the SSM service model by transmitting datagrams on a channel 417 belonging to another host. Thus, an application requiring strong 418 authentication should not assume that all packets that arrive on a 419 channel were sent by the requested source. Higher-layer authentication 420 mechanisms should be used in such an application. The IPSEC 421 Authentication Header [IPSEC] may be used to authenticate the source of 422 an SSM transmission, for instance. 424 Some degree of protection against spoofed source addresses in multicast 425 is already fairly widespread, because the commonly deployed IP multicast 426 routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a "reverse-path 427 forwarding check" that validates that a multicast packet arrived on the 428 expected interface for its source address. Routing protocols used for 429 SSM SHOULD incorporate such a check. 431 We note that Loose Source Routing [RFC791] in combination with source 432 address spoofing may be used to allow an impostor of the true channel 433 source to inject packets onto an SSM channel. An SSM router SHOULD have 434 a configuration option to disable loose source routing to an SSM 435 destination addresses. Anti-source spoofing mechanisms, like source 436 address filtering at the edges of the network, are also strongly 437 encouraged. 439 8. Transition Considerations 441 A host that complies with this document will send ONLY source-specific 442 host reports for addresses in the SSM range. However, during a 443 transition period, non-compliant hosts might send non-source-specific 444 (IGMPv1 or IGMPv2) host reports for source-specific destination 445 addresses, and routers SHOULD ignore these reports (as stated in 446 [IGMPSSM]). Failure to do so would violate the SSM service model 447 promised to the sender: that a packet sent to (S,G) would only be 448 delivered to hosts that specifically requested delivery of packets sent 449 to G by S. 451 During a transition period, it would be possible to deliver SSM 452 datagrams through domains that do not support SSM semantics by simply 453 forwarding any packet destined to G to all hosts that have requested 454 subscription of (S,G) for any S. However, this implementation risks 455 unduly burdening the network infrastructure by deliver (S,G) datagrams 456 to hosts that did not request them. Such an implementation for 457 addresses in the SSM range is specifically not compliant with Section 458 5.2 of this document. 460 9. IANA Considerations 462 Addresses in the range 232.0.0.1 through 232.0.0.255 are reserved for 463 services with wide applicability that either require or would strongly 464 benefit if all hosts used a well-known SSM destination address for that 465 service. IANA shall allocate addresses in this range according to IETF 466 Consensus [IANA-CONSIDERATIONS]. Any proposal for allocation must 467 consider the fact that, on an Ethernet network, all datagrams sent to 468 any SSM destination address will be transmitted with the same link-layer 469 destination address, regardless of the source. Furthermore, the fact 470 that SSM destinations in 232.0.0.0/24 use the same link-layer addresses 471 as the reserved IP multicast group range 224.0.0.0/24 must also be 472 considered. 474 Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM 475 destination address to a particular entity or application. To do so 476 would compromise one of the important benefits of the source-specific 477 model: the ability for a host to simply and autonomously allocate a 478 source-specific address from a large flat address space. 480 10. Acknowledgments 482 The SSM service model draws on previous work done on the EXPRESS 483 Multicast model [EXPRESS] with David Cheriton. We would like to thank 484 David Cheriton and Jon Postel for their support in reassigning the 232/8 485 address range to SSM. 487 11. References 489 [IANA-ALLOCATION] Internet Assigned Numbers Authority, 490 http://www.isi.edu/in-notes/iana/assignments/multicast-addresses. 492 [IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group 493 Management Protocol, Version 3," Work in Progress. 495 [RFC791] Postel, J., ed., "Internet Protocol, Darpa Internet Program 496 Protocol Specification," September 1981. 498 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, 499 August 1989. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels," RFC 2119, March 1997. 504 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address 505 Allocation," RFC 2771, February 2000. 507 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," 508 RFC 2236, November 1997. 510 [IANA-CONSIDERATIONS] Narten, T., and H. Alvestrand, "Guidelines for 511 Writing an IANA Considerations Section in RFCs," RFC 2434, October 1998. 513 [PIM-DM] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy, 514 A., Meyer, D., and L. Wei, "Protocol Independent Multicast Version 2 515 Dense Mode Specification," Work in Progress. 517 [PIM-SM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 518 Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol 519 Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification," RFC 520 2362, June 1998. 522 [DVMRP] Waitzman, D., Partridge, C., and S. Deering., "Distance Vector 523 Multicast Routing Protocol," RFC 1075, Nov 1988. 525 [ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 526 RFC 2365, July, 1998. 528 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the Internet 529 Protocol.", RFC 2401. 531 [IGMPSSM] Holbrook, H., and Cain, B. "Using IGMPv3 for Source-Specific 532 Multicast". Work in Progress. 534 [EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested Source- 535 Specific Multicast: EXPRESS support for Large-scale Single-source 536 Applications." Proceedings of ACM SIGCOMM '99, Cambridge, MA, September 537 1999. 539 [MSFAPI] Thaler, D., Fenner, B., and Quinn, B. "Socket Interface 540 Extensions for Multicast Source Filters." Work in Progress. 542 12. Author's Address 544 Brad Cain 545 Mirror Image Internet 546 brad.cain@mirror-image.com 548 Hugh Holbrook 549 Cisco Systems 550 170 W. Tasman Drive 551 San Jose, CA 95134 552 holbrook@cisco.com 554 This document expires May 24, 2001.