idnits 2.17.1 draft-ietf-ssm-arch-00.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], [MLDv2], [SSMIPv6]), 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 350 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 (21 November 2001) is 8163 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 34, but not defined == Unused Reference: 'IGMPv2' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'RFC2710' is defined on line 567, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. 'DVMRP') -- Possible downref: Non-RFC (?) normative reference: ref. 'EXPRESS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-ALLOCATION' ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv3' ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. 'MLDv2' -- Possible downref: Non-RFC (?) normative reference: ref. 'MSFAPI' ** Obsolete normative reference: RFC 2362 (ref. 'PIM-SM') (Obsoleted by RFC 4601, RFC 5059) -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM-DM' ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Downref: Normative reference to an Informational RFC: RFC 2771 -- Possible downref: Non-RFC (?) normative reference: ref. 'SIMPLE' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMRP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSMIPv6' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Source-Specific Multicast H. Holbrook 3 Expires May 21, 2002 Cisco Systems 4 B. Cain 5 Cereva Networks 6 21 November 2001 8 Source-Specific Multicast for IP 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC 2119]. 35 Abstract 37 IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 38 designated as source-specific multicast (SSM) destination addresses and 39 are reserved for use by source-specific applications and protocols 40 [IANA-ALLOCATION]. For IP version 6 (IPv6), a proposed range exists, 41 although there is currently no IANA allocation [SSMIPv6]. This document 42 defines the semantics of source-specific multicast addresses and 43 specifies the policies governing their use. It defines an extension to 44 the Internet network service that applies to datagrams sent to SSM 45 addresses and defines the host and router requirements to support this 46 extension. 48 A companion document will describe how the Internet Group Management 49 Protocol Version 3 [IGMPv3] and the Multicast Listener Discovery 50 Protocol Version 2 [MLDv2] can be adapted to support source-specific 51 multicast. 53 1. Overview and Rationale 55 The Internet Protocol (IP) multicast service model is defined in RFC 56 1112 [RFC1112]. RFC 1112 specifies that a datagram sent to an IP 57 multicast address (224.0.0.0 through 239.255.255.255) G is delivered to 58 each "upper-layer protocol module" that has requested reception of 59 datagrams sent to address G. RFC 1112 calls the network service 60 identified by a multicast destination address G a "host group." This 61 model supports both one-to-many and many-to-many group communication. 62 This document uses the term "Any-Source Multicast" (ASM) to refer to the 63 RFC 1112 model of multicast. RFC 2373 [RFC2373] specifies the form of 64 IPv6 multicast addresses with ASM semantics. 66 IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 67 currently designated as source-specific multicast (SSM) destination 68 addresses and are reserved for use by source-specific applications and 69 protocols [IANA-ALLOCATION]. For IPv6, the address prefixes FF3x:: and 70 FF2x:: are proposed for Source-Specific Multicast, with the former 71 corresponding to "transient" and the latter corresponding to "permanent" 72 addresses [SSMIPv6]. 74 Source-Specific Multicast delivery semantics are provided for a datagram 75 sent to an SSM address. That is, a datagram with source IP address S 76 and SSM destination address G is delivered to each upper-layer "socket" 77 that has specifically requested the reception of datagrams sent to 78 address G by source S, and only to those sockets. The network service 79 identified by (S,G), for SSM address G and source host address S, is 80 referred to as a "channel." In contrast to the ASM model of RFC 1112, 81 SSM provides network-layer support for one-to-many delivery only. 83 The benefits of source-specific multicast include: 85 Elimination of cross-delivery of traffic when two sources 86 simultaneously use the same source-specific destination address. 87 The simultaneous use of an SSM destination address by multiple 88 sources is explicitly supported. 90 Avoidance of the need for inter-host coordination when choosing 91 source-specific addresses, as a consequence of the above. 93 Avoidance of many of the router protocols and algorithms that are 94 needed to provide the ASM service model. For instance, the "shared 95 trees" and Rendezvous Points of the PIM-Sparse Mode (PIM-SM) 96 protocol are not necessary to support the source-specific model. 97 The router mechanisms required to support SSM are not new, and are 98 in fact largely a subset of those required to support ASM. For 99 example, the shortest-path tree mechanism of the PIM-SM protocol can 100 be adapted easily to provide SSM semantics. 102 Like ASM, SSM is "receiver-driven," and the set of receivers is unknown 103 to the sender. An SSM source is provided with neither the identity of 104 receivers nor their number. 106 This document defines the semantics of source-specific multicast 107 addresses and specifies the policies governing their use. In 108 particular, it defines an extension to the Internet network service that 109 applies to datagrams sent to SSM addresses and defines host extensions 110 to support the network service. Hosts, routers, applications, and 111 protocols that use these addresses MUST comply with the policies 112 outlined in this document. Failure of a host to comply may prevent that 113 host or other hosts on the same LAN from receiving traffic sent to an 114 SSM channel. Failure of a router to comply may cause SSM traffic to be 115 delivered to parts of the network where it is unwanted, unnecessarily 116 burdening the network. 118 2. Semantics of Source-Specific Multicast Addresses 120 The source-specific multicast service is defined as follows: 122 A datagram sent with source IP address S and destination IP address 123 G in the SSM range is delivered to each host socket that has 124 specifically requested delivery of datagrams sent by S to G, and 125 only to those sockets. 127 Where, using the terminology of [IGMPv3], 129 "socket" is an implementation-specific parameter used to distinguish 130 among different requesting entities (e.g., programs or processes or 131 communication end-points within a program or process) within the 132 requesting host; the socket parameter of BSD Unix system calls is a 133 specific example. 135 Any host may send a datagram to any SSM address, and delivery is 136 provided according to the above semantics. 138 The IP module interface to upper-layer protocols is extended to allow a 139 socket to "Subscribe" to or "Unsubscribe" from a particular channel 140 identified by an SSM destination address and a source IP address. The 141 extended interface is defined in section 4.1. It is meaningless for an 142 application or host to request reception of datagrams sent to an SSM 143 destination address G, as is supported in the Any-Source Multicast 144 model. without also specifying a corresponding source address, and 145 routers MUST ignore any such request from a host. 147 Multiple source applications on different hosts can use the same SSM 148 destination address G without conflict because datagrams sent by each 149 source host Si are delivered only to those sockets that requested 150 delivery of datagrams sent to G specifically by Si. 152 The key distinguishing property of the model is that a channel is 153 identified (addressed) by the combination of a unicast source address 154 and a multicast destination address in the SSM range. So, for example, 155 the channel 157 S,G = (36.18.0.1, 232.7.8.9) 159 differs from 161 S,G = (36.18.0.2, 232.7.8.9), 163 even though they have the same destination address portion. Similarly, 164 for IPv6, 166 S,G = (2001:3618::1, FF23::1234) 168 and 170 S,G = (2001:3618::2, FF23::1234) 172 are different channels. 174 3. Terminology 176 To avoid confusion when talking about the Any-Source and Source-Specific 177 Multicast models, we use different terminology when discussing them. 179 We use the term "channel" to refer to the service associated with an SSM 180 address. A channel is identified by the combination of an SSM 181 destination address and a specific source, e.g., an (S,G) pair. 183 We use the term "host group" (used in RFC 1112) to refer to the service 184 associated with "regular" ASM multicast addresses (excluding those in 185 the SSM range). A host group is identified by a single multicast 186 address. 188 Any host can send to a host group, and similarly, any host can send to 189 an SSM destination address. A packet sent by a host S to an ASM 190 destination address G is delivered to the host group identified by G. A 191 packet sent by host S to an SSM destination address G is delivered to 192 the channel identified by (S,G). The receiver operations allowed on a 193 host group are called "join(G)" and "leave(G)" (as per RFC 1112). The 194 receiver operations allowed on a channel are called "Subscribe(S,G)" and 195 "Unsubscribe(S,G)." 197 The following table summarizes the terminology: 199 Service Model: Any-Source Source-Specific 200 Network Abstraction: group channel 201 Identifier: G S,G 202 Receiver Operations: join, leave subscribe, unsubscribe 204 We note that, although this document specifies a new service model 205 available to applications, the protocols and techniques necessary to 206 support the service model are largely a subset of those used to support 207 ASM. 209 4. Host Requirements 211 This section describes requirements on hosts that support Source- 212 Specific Multicast, including: 214 - Extensions to the IP Module Interface 216 - Extensions to the IP Module 218 - Allocation of SSM Addresses 220 4.1. Extensions to the IP Module Interface 222 The IP module interface to upper-layer protocols is extended to allow 223 protocols to request reception of all datagrams sent to a particular 224 channel. 226 Subscribe ( socket, source-address, group-address, interface ) 228 Unsubscribe ( socket, source-address, group-address, interface ) 230 where 232 "socket" is as previously defined in Section 2, 234 and, paraphrasing [IGMPv3], 236 "interface" is a local identifier of the network interface on which 237 reception of the channel identified by the (source-address,group- 238 address) pair is to be enabled or disabled. A special value may be 239 used to indicate a "default" interface. If reception of the same 240 channel is desired on multiple interfaces, Subscribe is invoked once 241 for each. 243 The above are strictly abstract functional interfaces -- the 244 functionality can be provided in an implementation-specific way. On a 245 host that supports the multicast source filtering application 246 programming interface of [MSFAPI], the Subscribe and Unsubscribe 247 interfaces may be supported via that API. 249 Widespread implementations of the IP packet reception interface (e.g., 250 the recvfrom() system call in BSD unix) do not allow a receiver to 251 determine the destination address to which a datagram was sent. On a 252 host with such an implementation, the destination address of a datagram 253 cannot be inferred when the socket on which the datagram is received is 254 Subscribed to multiple channels. Host operating systems SHOULD provide 255 a way for a host to determine both the source and the destination 256 address to which a datagram was sent. (As one example, the Linux 257 operating system provides the destination of a packet as part of the 258 response to the recvmsg() system call.) Until this capability is 259 present, applications may be forced to use higher-layer mechanisms to 260 identify the channel to which a datagram was sent. 262 4.2. Requirements on the Host IP Module 264 An incoming datagram destined to an SSM address MUST be delivered by the 265 IP module to all sockets that have indicated (via Subscribe) a desire to 266 receive data that matches the datagram's source address, destination 267 address, and arriving interface. It MUST NOT be delivered to other 268 sockets. 270 When the first socket on host H subscribes to a channel (S,G) on 271 interface I, the host IP module on H sends a request on interface I to 272 indicate to neighboring routers that the host wishes to receive traffic 273 sent by source S to source-specific destination G. Similarly, when the 274 last socket on a host unsubscribes from a channel on interface I, the 275 host IP module sends an unsubscription request for that channel out 276 interface I. 278 These requests will typically be IGMPv3 messages for IPv4, or MLDv2 279 messages for IPv6. The exact rules for sending source-specific 280 subscription and unsubscription requests and the algorithms used to 281 maintain subscriptions are defined in other documents. 283 4.3. Allocation of Source-Specific Multicast Addresses 285 The SSM destination address 232.0.0.0 is reserved, and hosts MUST NOT 286 send datagrams with destination address of 232.0.0.0. The address range 287 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. The 288 IPv6 SSM address range FF2x:: is reserved for IANA allocation. 290 The policy for allocating the rest of the SSM addresses to sending 291 applications is strictly locally determined by the sending host. 293 When allocating SSM addresses dynamically, a host or host operating 294 system MUST NOT allocate sequentially starting at the first allowed 295 address. It is RECOMMENDED to allocate SSM addresses to applications 296 randomly, while ensuring that allocated addresses are not given 297 simultaneously to multiple applications (and avoiding the reserved 298 address range for IPv4). For IPv6, the randomization should apply to 299 the lower 32 bits of the address. 301 As described in Section 6, the mapping of an IP packet with SSM 302 destination address onto a link-layer multicast address does not take 303 into account the datagram's source IP address (on commonly-used link 304 layers like Ethernet). If all hosts started at the first allowed 305 address, then with high probability, many source-specific channels on 306 shared-medium local area networks would collide on the same link-layer 307 multicast address. As a result, traffic destined for one channel member 308 would potentially be delivered to another as the link-layer (unaware of 309 the IP Source Address) accepts the multicast datagram, passes it to the 310 IP layer, which then simply rejects it. 312 A host operating system SHOULD provide an interface to allow an 313 application to request a unique allocation of a channel destination 314 address in advance of a session's commencement, and this allocation 315 database SHOULD persist across host reboots. By providing persistent 316 allocations, a host application can advertise the session in advance of 317 its start time on a web page or in another directory. (We note that 318 this issue is not specific to SSM applications -- the same problem 319 arises for ASM.) 320 This document neither defines the interfaces for requesting or returning 321 addresses nor specifies the host algorithms for storing those 322 allocations. One plausible abstract API is defined in RFC 2771 323 [RFC2771], although the interface of RFC 2771 allows an application to 324 request an address from a specific sub-range of the SSM allocation. 325 This is NOT RECOMMENDED for SSM, unless the start address of the allowed 326 range is selected at random. 328 No globally agreed-upon administratively-scoped address range [ADMIN- 329 SCOPE] is needed for the source-specific multicast range because there 330 is no possibility of address conflict between hosts in different 331 administrative domains (or between two hosts of any kind). 332 Administrative scoping of SSM addresses can be implemented within an 333 administrative domain by filtering at domain boundary routers. 335 5. Router Requirements 337 5.1. Packet Forwarding 339 A router that receives an IP datagram with a source-specific destination 340 address MUST silently drop it unless a neighboring host or router has 341 communicated a desire to receive packets sent to the source and 342 destination address of the received packet. 344 5.2. Protocols 346 Certain IP multicast routing protocols already have the ability to 347 communicate source-specific joins to neighboring routers (in particular, 348 PIM-SM), and these protocols can, with slight modifications, be used to 349 provide source-specific semantics. Companion documents will specify the 350 required modifications to those protocols to support the source- 351 specific address range. 353 A network can concurrently support SSM semantics in the SSM address 354 range and Any-Source Multicast in the rest of the multicast address 355 space, and it is expected that this will be commonplace. In such a 356 network, a router may receive a non-source-specific, or "(*,G)" in 357 conventional terminology, request for delivery of traffic in the SSM 358 range from a neighbor that does not implement source-specific multicast 359 in a manner compliant with this document. A router that receives such a 360 non-source-specific request for data in the SSM range MUST NOT use the 361 request to establish forwarding state and MUST NOT propagate the request 362 to other neighboring routers. This applies both to any request received 363 from a host, e.g., an IGMPv1 or IGMPv2 host report, and to any request 364 received from a routing protocol, e.g., a PIM-SM (*,G) join [PIM-SM]. 366 The inter-router case is further discussed in section 8, Transition 367 Considerations. 369 It is essential that all routers in the network give source-specific 370 semantics to the same range of addresses in order to achieve the full 371 benefit of SSM. To comply with this specification, a router MUST treat 372 ALL SSM addresses with source-specific semantics. 374 6. Link-Layer Transmission of Datagrams 376 Source-specific multicast packets are transmitted on link-layer networks 377 as specified in RFC 1112 for IPv4 and as in [ETHERv6] for IPv6. On most 378 shared-medium link-layer networks that support multicast (e.g., 379 Ethernet), the IP source address is not used in the selection of the 380 link-layer destination address. Consequently, on such a network, all 381 packets sent to destination address G will be delivered to any host that 382 has subscribed to any channel (S,G), regardless of S. And therefore, 383 the IP module MUST filter packets it receives from the link layer before 384 delivering them to the socket layer. A socket on which an (S,G) 385 subscription has been requested MUST receive packets whose source and 386 destination address match the requested subscription(s) for that socket. 388 7. Security Considerations 390 7.1. Denial-of-Service 392 A subscription request creates (S,G) state in a router to record the 393 subscription and invokes processing on that router and possibly causes 394 processing at neighboring routers. A host can mount a denial of service 395 attack by requesting a large number of subscriptions. A denial of 396 service can result if: 398 - a large amount of traffic arrives when it was otherwise undesired, 399 consuming network resources to deliver it and host resources to drop 400 it 402 - a large amount of source-specific multicast state is created in 403 network routers, using router memory and CPU resources to store and 404 process the state 406 - a large amount of control traffic is generated to manage the 407 source-specific state, using router CPU and network bandwidth 409 To reduce the damage from such an attack, a router MAY have a 410 configuration option to limit the following items: 412 - The total rate at which all hosts on any one interface are allowed 413 to initiate subscriptions (to limit the damage caused by forged 414 source-address attacks) 416 - The total number of subscriptions that can be initated from any 417 single interface or host. 419 Any decision by an implementor to artificially limit the rate or number 420 of subscriptions should be taken carefully, however, as future 421 applications may use large numbers of channels. Tight limits on the 422 rate or number of channel subscriptions would inhibit the deployment of 423 such applications. 425 A router SHOULD verify that the source of a subscription request is a 426 valid address for the interface on which it was received. Failure to do 427 so would exacerbate a spoofed-source address attack. 429 We note that these attacks are not unique to SSM -- they are also 430 present for Any-Source Multicast. 432 7.2. Spoofed Source Addresses 434 By forging the source address in a datagram, an attacker can potentially 435 violate the SSM service model by transmitting datagrams on a channel 436 belonging to another host. Thus, an application requiring strong 437 authentication should not assume that all packets that arrive on a 438 channel were sent by the requested source. Higher-layer authentication 439 mechanisms should be used in such an application. The IPSEC 440 Authentication Header [IPSEC] may be used to authenticate the source of 441 an SSM transmission, for instance. 443 Some degree of protection against spoofed source addresses in multicast 444 is already fairly widespread, because the commonly deployed IP multicast 445 routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a "reverse-path 446 forwarding check" that validates that a multicast packet arrived on the 447 expected interface for its source address. Routing protocols used for 448 SSM SHOULD incorporate such a check. 450 We note that Source Routing [RFC791] (both Loose and Strict) in 451 combination with source address spoofing may be used to allow an 452 impostor of the true channel source to inject packets onto an SSM 453 channel. An SSM router MUST have a configuration option to disable 454 source routing to an SSM destination addresses, and the default value 455 SHOULD be to disable Source Routing to an SSM destination address. 457 Anti-source spoofing mechanisms like source address filtering at the 458 edges of the network are also strongly encouraged. 460 8. Transition Considerations 462 A host that complies with this document will send ONLY source-specific 463 host reports for addresses in the SSM range. A router that receives a 464 non-source-specific (IGMPv1 or IGMPv2) host report for a source-specific 465 destination addresses SHOULD ignore these reports. Failure to do so 466 would violate the SSM service model promised to the sender: that a 467 packet sent to (S,G) would only be delivered to hosts that specifically 468 requested delivery of packets sent to G by S. 470 During a transition period, it would be possible to deliver SSM 471 datagrams in a domain where the routers do not support SSM semantics by 472 simply forwarding any packet destined to G to all hosts that have 473 requested subscription of (S,G) for any S. However, this implementation 474 risks unduly burdening the network infrastructure by deliver (S,G) 475 datagrams to hosts that did not request them. Such an implementation 476 for addresses in the SSM range is specifically not compliant with 477 Section 5.2 of this document. 479 9. IANA Considerations 481 Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses 482 with prefix FF2x:: are reserved for services with wide applicability 483 that either require or would strongly benefit if all hosts used a well- 484 known SSM destination address for that service. IANA shall allocate 485 addresses in this range according to IETF Consensus [IANA- 486 CONSIDERATIONS]. Any proposal for allocation must consider the fact 487 that, on an Ethernet network, all datagrams sent to any SSM destination 488 address will be transmitted with the same link-layer destination 489 address, regardless of the source. Furthermore, the fact that SSM 490 destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same link-layer 491 addresses as the reserved IP multicast group range 224.0.0.0/24 must 492 also be considered. Similar consideration should be given to the IPv6 493 reserved multicast addresses. 495 Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM 496 destination address to a particular entity or application. To do so 497 would compromise one of the important benefits of the source-specific 498 model: the ability for a host to simply and autonomously allocate a 499 source-specific address from a large flat address space. 501 10. Acknowledgments 503 The SSM service model draws on a variety of prior work on alternative 504 aproaches to IP multicast, including the EXPRESS multicast model of 505 Holbrook and Cheriton [EXPRESS], Green's [SMRP] and the Simple multicast 506 proposal of Perlman et. al. [SIMPLE]. We would also like to thank Jon 507 Postel and David Cheriton for their support in reassigning the 232/8 508 address range to SSM. Thanks also to Brian Haberman for his 509 contributions to the IPv6 portions of this document. 511 11. References 513 [ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 514 RFC 2365, July 1998. 516 [DVMRP] Waitzman, D., Partridge, C., and S. Deering., "Distance Vector 517 Multicast Routing Protocol," RFC 1075, Nov 1988. 519 [ETHERv6] Crawford, M., "Transmission of IPv6 Packets over Ethernet 520 Networks", RFC2464, Dec 1998. 522 [EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested Source- 523 Specific Multicast: EXPRESS support for Large-scale Single-source 524 Applications." Proceedings of ACM SIGCOMM '99, Cambridge, MA, September 525 1999. 527 [IANA-ALLOCATION] Internet Assigned Numbers Authority, 528 http://www.isi.edu/in-notes/iana/assignments/multicast-addresses. 530 [IANA-CONSIDERATIONS] Narten, T., and H. Alvestrand, "Guidelines for 531 Writing an IANA Considerations Section in RFCs," RFC 2434, October 1998. 533 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," 534 RFC 2236, November 1997. 536 [IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group 537 Management Protocol, Version 3," Work in Progress. 539 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the Internet 540 Protocol.", RFC 2401. 542 [MLDv2] R. Vida, L. Costa, R. Zara, S. Fdida, S. Deering, B. Fenner, I. 543 Kouvelas, B. Haberman. "Multicast Listener Discovery Version 2 (MLDv2) 544 for IPv6." Work in Progress. 546 [MSFAPI] Thaler, D., Fenner, B., and Quinn, B. "Socket Interface 547 Extensions for Multicast Source Filters." Work in Progress. 549 [PIM-SM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 550 Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol 551 Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification," RFC 552 2362, June 1998. 554 [PIM-DM] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy, 555 A., Meyer, D., and L. Wei, "Protocol Independent Multicast Version 2 556 Dense Mode Specification," Work in Progress. 558 [RFC791] Postel, J., ed., "Internet Protocol, Darpa Internet Program 559 Protocol Specification," September 1981. 561 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, 562 August 1989. 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels," RFC 2119, March 1997. 567 [RFC2710] S. Deering, W. Fenner, B. Haberman, "Multicast Listener 568 Discovery (MLD) for IPv6", RFC 2710, October 1999. 570 [RFC2373] Hinden, R. and Deering, S. "IP Version 6 Addressing 571 Architecture." RFC 2373, July 1998. 573 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address 574 Allocation," RFC 2771, February 2000. 576 [SIMPLE] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. 577 Maufer, C. Diot, and M. Green. "Simple Multicast: A Design for Simple, 578 Low-Overhead Multicast." Work in Progress. 580 [SMRP] Green, M. "Method and System of Multicast Routing for Groups 581 with a Single Transmitter." United States Patent Number 5,517,494. 583 [SSMIPv6] Haberman, B. and Thaler, D. "Unicast-Prefix-based IPv6 584 Multicast Addresses." Work in Progress. 586 12. Author's Address 588 Brad Cain 589 Cereva Networks 590 3 Network Drive 591 Marlborough, MA 01752 592 bcain@cereva.com 593 Hugh Holbrook 594 Cisco Systems 595 170 W. Tasman Drive 596 San Jose, CA 95134 597 holbrook@cisco.com 599 This document expires May 21, 2002.