idnits 2.17.1 draft-ietf-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 abstract seems to contain references ([IANA-ALLOCATION], [IGMPv3], [MLDv2], [IPV6-UBM]), 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 355 has weird spacing: '...equired modif...' -- 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 (3 Nov 2002) is 7817 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 == Missing Reference: 'IANA-ALLOCATION' is mentioned on line 549, but not defined == Missing Reference: 'IGMPv3' is mentioned on line 558, but not defined == Missing Reference: 'MLDv2' is mentioned on line 564, but not defined == Missing Reference: 'MSFAPI' is mentioned on line 568, but not defined == Missing Reference: 'RFC2771' is mentioned on line 586, but not defined == Missing Reference: 'ADMIN-SCOPE' is mentioned on line 538, but not defined == Missing Reference: 'PIM-SM' is mentioned on line 571, but not defined == Missing Reference: 'IPSEC' is mentioned on line 561, but not defined == Missing Reference: 'PIM-DM' is mentioned on line 576, but not defined == Missing Reference: 'DVMRP' is mentioned on line 541, but not defined == Missing Reference: 'IANA-CONSIDERATIONS' is mentioned on line 552, but not defined == Missing Reference: 'EXPRESS' is mentioned on line 544, but not defined == Missing Reference: 'SMRP' is mentioned on line 593, but not defined == Missing Reference: 'SIMPLE' is mentioned on line 589, but not defined == Missing Reference: 'IGMPv2' is mentioned on line 555, but not defined == Missing Reference: 'RFC2119' is mentioned on line 580, but not defined == Missing Reference: 'RFC2710' is mentioned on line 583, but not defined ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) Summary: 4 errors (**), 0 flaws (~~), 21 warnings (==), 2 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 3, 2003 Cisco Systems 4 B. Cain 5 Cereva Networks 6 3 Nov 2002 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), the address prefix 41 FF3x::/32 is reserved for Source-Specific Multicast use, where 'x' is 42 any valid scope identifier [IPV6-UBM]. This document defines the 43 semantics of source-specific multicast addresses and specifies the 44 policies governing their use. It defines an extension to the Internet 45 network service that applies to datagrams sent to SSM addresses and 46 defines the host and router requirements to support this 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] are 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]. 71 For IPv6, the address prefix FF3x::/32 is reserved for Source-Specific 72 Multicast use, where 'x' is any valid scope identifier [IPV6-UBM]. 73 Addresses in the range FF3x::4000:0000 through FF3x::7fff:ffff are 74 reserved for allocation by IANA, and addresses in the range 75 FF3x::8000:0000 through FF3x::ffff:ffff are allowed for dynamic 76 allocation by a host, as described in [IPV6-MALLOC]. Addresses in the 77 range FF3x::0000:0000 through FF3x::3fff:ffff are invalid IPv6 SSM 78 addresses, per [IPV6-UBM]. The treatment of a packet sent to such an 79 invalid address is undefined -- a router or host MAY choose to drop such 80 a packet. 82 Source-Specific Multicast delivery semantics are provided for a datagram 83 sent to an SSM address. That is, a datagram with source IP address S 84 and SSM destination address G is delivered to each upper-layer "socket" 85 that has specifically requested the reception of datagrams sent to 86 address G by source S, and only to those sockets. The network service 87 identified by (S,G), for SSM address G and source host address S, is 88 referred to as a "channel." In contrast to the ASM model of RFC 1112, 89 SSM provides network-layer support for one-to-many delivery only. 91 The benefits of source-specific multicast include: 93 Elimination of cross-delivery of traffic when two sources 94 simultaneously use the same source-specific destination address. 95 The simultaneous use of an SSM destination address by multiple 96 sources and different applications is explicitly supported. 98 Avoidance of the need for inter-host coordination when choosing 99 source-specific addresses, as a consequence of the above. 101 Avoidance of many of the router protocols and algorithms that are 102 needed to provide the ASM service model. For instance, the "shared 103 trees" and Rendezvous Points of the PIM-Sparse Mode (PIM-SM) 104 protocol are not necessary to support the source-specific model. 105 The router mechanisms required to support SSM are in fact largely a 106 subset of those that are used to support ASM. For example, the 107 shortest-path tree mechanism of the PIM-SM protocol can be adapted 108 to provide SSM semantics. 110 Like ASM, the set of receivers is unknown to an SSM sender. An SSM 111 source is provided with neither the identity of receivers nor their 112 number. 114 This document defines the semantics of source-specific multicast 115 addresses and specifies the policies governing their use. In 116 particular, it defines an extension to the Internet network service that 117 applies to datagrams sent to SSM addresses and defines host extensions 118 to support the network service. Hosts, routers, applications, and 119 protocols that use these addresses MUST comply with the policies 120 outlined in this document. Failure of a host to comply may prevent that 121 host or other hosts on the same LAN from receiving traffic sent to an 122 SSM channel. Failure of a router to comply may cause SSM traffic to be 123 delivered to parts of the network where it is unwanted, unnecessarily 124 burdening the network. 126 2. Semantics of Source-Specific Multicast Addresses 128 The source-specific multicast service is defined as follows: 130 A datagram sent with source IP address S and destination IP address 131 G in the SSM range is delivered to each host socket that has 132 specifically requested delivery of datagrams sent by S to G, and 133 only to those sockets. 135 Where, using the terminology of [IGMPv3], 137 "socket" is an implementation-specific parameter used to distinguish 138 among different requesting entities (e.g., programs or processes or 139 communication end-points within a program or process) within the 140 requesting host; the socket parameter of BSD Unix system calls is a 141 specific example. 143 Any host may send a datagram to any SSM address, and delivery is 144 provided according to the above semantics. 146 The IP module interface to upper-layer protocols is extended to allow a 147 socket to "Subscribe" to or "Unsubscribe" from a particular channel 148 identified by an SSM destination address and a source IP address. The 149 extended interface is defined in section 4.1. It is meaningless for an 150 application or host to request reception of datagrams sent to an SSM 151 destination address G, as is supported in the Any-Source Multicast model 152 without also specifying a corresponding source address, and routers MUST 153 ignore any such request from a host. 155 Multiple source applications on different hosts can use the same SSM 156 destination address G without conflict because datagrams sent by each 157 source host Si are delivered only to those sockets that requested 158 delivery of datagrams sent to G specifically by Si. 160 The key distinguishing property of the model is that a channel is 161 identified (addressed) by the combination of a unicast source address 162 and a multicast destination address in the SSM range. So, for example, 163 the channel 165 S,G = (36.18.0.1, 232.7.8.9) 167 differs from 169 S,G = (36.18.0.2, 232.7.8.9), 171 even though they have the same destination address portion. Similarly, 172 for IPv6, 174 S,G = (2001:3618::1, FF23::1234) 176 and 177 S,G = (2001:3618::2, FF23::1234) 179 are different channels. 181 3. Terminology 183 To avoid confusion when talking about the Any-Source and Source-Specific 184 Multicast models, we use different terminology when discussing them. 186 We use the term "channel" to refer to the service associated with an SSM 187 address. A channel is identified by the combination of an SSM 188 destination address and a specific source, e.g., an (S,G) pair. 190 We use the term "host group" (used in RFC 1112) to refer to the service 191 associated with "regular" ASM multicast addresses (excluding those in 192 the SSM range). A host group is identified by a single multicast 193 address. 195 Any host can send to a host group, and similarly, any host can send to 196 an SSM destination address. A packet sent by a host S to an ASM 197 destination address G is delivered to the host group identified by G. A 198 packet sent by host S to an SSM destination address G is delivered to 199 the channel identified by (S,G). The receiver operations allowed on a 200 host group are called "join(G)" and "leave(G)" (as per RFC 1112). The 201 receiver operations allowed on a channel are called "Subscribe(S,G)" and 202 "Unsubscribe(S,G)." 204 The following table summarizes the terminology: 206 Service Model: Any-Source Source-Specific 207 Network Abstraction: group channel 208 Identifier: G S,G 209 Receiver Operations: join, leave subscribe, unsubscribe 211 We note that, although this document specifies a new service model 212 available to applications, the protocols and techniques necessary to 213 support the service model are largely a subset of those used to support 214 ASM. 216 4. Host Requirements 218 This section describes requirements on hosts that support Source- 219 Specific Multicast, including: 221 - Extensions to the IP Module Interface 223 - Extensions to the IP Module 224 - Allocation of SSM Addresses 226 4.1. Extensions to the IP Module Interface 228 The IP module interface to upper-layer protocols is extended to allow 229 protocols to request reception of all datagrams sent to a particular 230 channel. 232 Subscribe ( socket, source-address, group-address, interface ) 234 Unsubscribe ( socket, source-address, group-address, interface ) 236 where 238 "socket" is as previously defined in Section 2, 240 and, paraphrasing [IGMPv3], 242 "interface" is a local identifier of the network interface on which 243 reception of the channel identified by the (source-address,group- 244 address) pair is to be enabled or disabled. A special value may be 245 used to indicate a "default" interface. If reception of the same 246 channel is desired on multiple interfaces, Subscribe is invoked once 247 for each. 249 The above are strictly abstract functional interfaces -- the 250 functionality can be provided in an implementation-specific way. On a 251 host that supports the multicast source filtering application 252 programming interface of [MSFAPI], the Subscribe and Unsubscribe 253 interfaces may be supported via that API. 255 Widespread implementations of the IP packet reception interface (e.g., 256 the recvfrom() system call in BSD unix) do not allow a receiver to 257 determine the destination address to which a datagram was sent. On a 258 host with such an implementation, the destination address of a datagram 259 cannot be inferred when the socket on which the datagram is received is 260 Subscribed to multiple channels. Host operating systems SHOULD provide 261 a way for a host to determine both the source and the destination 262 address to which a datagram was sent. (As one example, the Linux 263 operating system provides the destination of a packet as part of the 264 response to the recvmsg() system call.) Until this capability is 265 present, applications may be forced to use higher-layer mechanisms to 266 identify the channel to which a datagram was sent. 268 4.2. Requirements on the Host IP Module 270 An incoming datagram destined to an SSM address MUST be delivered by the 271 IP module to all sockets that have indicated (via Subscribe) a desire to 272 receive data that matches the datagram's source address, destination 273 address, and arriving interface. It MUST NOT be delivered to other 274 sockets. 276 When the first socket on host H subscribes to a channel (S,G) on 277 interface I, the host IP module on H sends a request on interface I to 278 indicate to neighboring routers that the host wishes to receive traffic 279 sent by source S to source-specific destination G. Similarly, when the 280 last socket on a host unsubscribes from a channel on interface I, the 281 host IP module sends an unsubscription request for that channel out 282 interface I. 284 These requests will typically be IGMPv3 messages for IPv4, or MLDv2 285 messages for IPv6. The exact rules for sending source-specific 286 subscription and unsubscription requests and the algorithms used to 287 maintain subscriptions are defined in other documents. 289 4.3. Allocation of Source-Specific Multicast Addresses 291 The SSM destination address 232.0.0.0 is reserved, and hosts MUST NOT 292 send datagrams with destination address of 232.0.0.0. The address range 293 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. The 294 IPv6 SSM address range FF2x:: is reserved for IANA allocation. 296 The policy for allocating the rest of the SSM addresses to sending 297 applications is strictly locally determined by the sending host. 299 When allocating SSM addresses dynamically, a host or host operating 300 system MUST NOT allocate sequentially starting at the first allowed 301 address. It is RECOMMENDED to allocate SSM addresses to applications 302 randomly, while ensuring that allocated addresses are not given 303 simultaneously to multiple applications (and avoiding the reserved 304 address range for IPv4). For IPv6, the randomization should apply to 305 the lower 32 bits of the address. 307 As described in Section 6, the mapping of an IP packet with SSM 308 destination address onto a link-layer multicast address does not take 309 into account the datagram's source IP address (on commonly-used link 310 layers like Ethernet). If all hosts started at the first allowed 311 address, then with high probability, many source-specific channels on 312 shared-medium local area networks would collide on the same link-layer 313 multicast address. As a result, traffic destined for one channel 314 subscriber would be delivered to another's IP module, which would then 315 have to reject the datagram. 317 A host operating system SHOULD provide an interface to allow an 318 application to request a unique allocation of a channel destination 319 address in advance of a session's commencement, and this allocation 320 database SHOULD persist across host reboots. By providing persistent 321 allocations, a host application can advertise the session in advance of 322 its start time on a web page or in another directory. (We note that 323 this issue is not specific to SSM applications -- the same problem 324 arises for ASM.) 326 This document neither defines the interfaces for requesting or returning 327 addresses nor specifies the host algorithms for storing those 328 allocations. One plausible abstract API is defined in RFC 2771 329 [RFC2771]. Note that RFC 2771 allows an application to request an 330 address within a specific range of addresses. If this interface is 331 used, the starting address of the range SHOULD be selected at random. 333 No globally agreed-upon administratively-scoped address range [ADMIN- 334 SCOPE] is currently defined for source-specific multicast. Note that 335 there is no possibility of address conflict between hosts in different 336 administrative domains (or between two hosts of any kind). 337 Administrative scoping of SSM addresses can be implemented within an 338 administrative domain by filtering at domain boundary routers. 340 5. Router Requirements 342 5.1. Packet Forwarding 344 A router that receives an IP datagram with a source-specific destination 345 address MUST silently drop it unless a neighboring host or router has 346 communicated a desire to receive packets sent from the source and to the 347 destination address of the received packet. 349 5.2. Protocols 351 Certain IP multicast routing protocols already have the ability to 352 communicate source-specific joins to neighboring routers (in particular, 353 PIM-SM), and these protocols can, with slight modifications, be used to 354 provide source-specific semantics. Companion documents will specify the 355 required modifications to those protocols to support the source- 356 specific address range. 358 A network can concurrently support SSM semantics in the SSM address 359 range and Any-Source Multicast in the rest of the multicast address 360 space, and it is expected that this will be commonplace. In such a 361 network, a router may receive a non-source-specific, or "(*,G)" in 362 conventional terminology, request for delivery of traffic in the SSM 363 range from a neighbor that does not implement source-specific multicast 364 in a manner compliant with this document. A router that receives such a 365 non-source-specific request for data in the SSM range MUST NOT use the 366 request to establish forwarding state and MUST NOT propagate the request 367 to other neighboring routers. This applies both to any request received 368 from a host, e.g., an IGMPv1 or IGMPv2 host report, and to any request 369 received from a routing protocol, e.g., a PIM-SM (*,G) join [PIM-SM]. 370 The inter-router case is further discussed in section 8, Transition 371 Considerations. 373 It is essential that all routers in the network give source-specific 374 semantics to the same range of addresses in order to achieve the full 375 benefit of SSM. To comply with this specification, a router MUST treat 376 ALL SSM addresses with source-specific semantics. 378 6. Link-Layer Transmission of Datagrams 380 Source-specific multicast packets are transmitted on link-layer networks 381 as specified in RFC 1112 for IPv4 and as in [ETHERv6] for IPv6. On most 382 shared-medium link-layer networks that support multicast (e.g., 383 Ethernet), the IP source address is not used in the selection of the 384 link-layer destination address. Consequently, on such a network, all 385 packets sent to destination address G will be delivered to any host that 386 has subscribed to any channel (S,G), regardless of S. And therefore, 387 the IP module MUST filter packets it receives from the link layer before 388 delivering them to the socket layer. A socket on which an (S,G) 389 subscription has been requested MUST NOT receive packets whose source 390 and destination address do not match the requested subscription(s) for 391 that socket. 393 7. Security Considerations 395 7.1. Denial-of-Service 397 A subscription request creates (S,G) state in a router to record the 398 subscription and invokes processing on that router and possibly causes 399 processing at neighboring routers. A host can mount a denial of service 400 attack by requesting a large number of subscriptions. A denial of 401 service can result if: 403 - a large amount of traffic arrives when it was otherwise undesired, 404 consuming network resources to deliver it and host resources to drop 405 it 407 - a large amount of source-specific multicast state is created in 408 network routers, using router memory and CPU resources to store and 409 process the state 411 - a large amount of control traffic is generated to manage the 412 source-specific state, using router CPU and network bandwidth 414 To reduce the damage from such an attack, a router MAY have a 415 configuration option to limit the following items: 417 - The total rate at which all hosts on any one interface are allowed 418 to initiate subscriptions (to limit the damage caused by forged 419 source-address attacks) 421 - The total number of subscriptions that can be initated from any 422 single interface or host. 424 Any decision by an implementor to artificially limit the rate or number 425 of subscriptions should be taken carefully, however, as future 426 applications may use large numbers of channels. Tight limits on the 427 rate or number of channel subscriptions would inhibit the deployment of 428 such applications. 430 A router SHOULD verify that the source of a subscription request is a 431 valid address for the interface on which it was received. Failure to do 432 so would exacerbate a spoofed-source address attack. 434 We note that these attacks are not unique to SSM -- they are also 435 present for Any-Source Multicast. 437 7.2. Spoofed Source Addresses 439 By forging the source address in a datagram, an attacker can potentially 440 violate the SSM service model by transmitting datagrams on a channel 441 belonging to another host. Thus, an application requiring strong 442 authentication should not assume that all packets that arrive on a 443 channel were sent by the requested source without higher-layer 444 authentication mechanisms. The IPSEC Authentication Header [IPSEC] may 445 be used to authenticate the source of an SSM transmission, for instance. 447 Some degree of protection against spoofed source addresses in multicast 448 is already fairly widespread, because the commonly deployed IP multicast 449 routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a "reverse-path 450 forwarding check" that validates that a multicast packet arrived on the 451 expected interface for its source address. Routing protocols used for 452 SSM SHOULD incorporate such a check. 454 Source Routing [RFC791] (both Loose and Strict) in combination with 455 source address spoofing may be used to allow an impostor of the true 456 channel source to inject packets onto an SSM channel. An SSM router 457 MUST have a configuration option to disable source routing to an SSM 458 destination addresses, and the default value SHOULD be to disable Source 459 Routing to an SSM destination address. Anti-source spoofing mechanisms 460 like source address filtering at the edges of the network are also 461 strongly encouraged. 463 8. Transition Considerations 465 A host that complies with this document will send ONLY source-specific 466 host reports for addresses in the SSM range. A router that receives a 467 non-source-specific (IGMPv1 or IGMPv2) host report for a source-specific 468 destination addresses SHOULD ignore these reports. Failure to do so 469 would violate the SSM service model promised to the sender: that a 470 packet sent to (S,G) would only be delivered to hosts that specifically 471 requested delivery of packets sent to G by S. 473 During a transition period, it would be possible to deliver SSM 474 datagrams in a domain where the routers do not support SSM semantics by 475 simply forwarding any packet destined to G to all hosts that have 476 requested subscription of (S,G) for any S. However, this implementation 477 risks unduly burdening the network infrastructure by deliver (S,G) 478 datagrams to hosts that did not request them. Such an implementation 479 for addresses in the SSM range is specifically not compliant with 480 Section 5.2 of this document. 482 9. IANA Considerations 484 Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses 485 with prefix FF2x:: are reserved for services with wide applicability 486 that either require or would strongly benefit if all hosts used a well- 487 known SSM destination address for that service. IANA shall allocate 488 addresses in this range according to IETF Consensus [IANA- 489 CONSIDERATIONS]. Any proposal for allocation must consider the fact 490 that, on an Ethernet network, all datagrams sent to any SSM destination 491 address will be transmitted with the same link-layer destination 492 address, regardless of the source. Furthermore, the fact that SSM 493 destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same link-layer 494 addresses as the reserved IP multicast group range 224.0.0.0/24 must 495 also be considered. Similar consideration should be given to the IPv6 496 reserved multicast addresses. 498 Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM 499 destination address to a particular entity or application. To do so 500 would compromise one of the important benefits of the source-specific 501 model: the ability for a host to simply and autonomously allocate a 502 source-specific address from a large flat address space. 504 10. Acknowledgments 506 The SSM service model draws on a variety of prior work on alternative 507 aproaches to IP multicast, including the EXPRESS multicast model of 508 Holbrook and Cheriton [EXPRESS], Green's [SMRP] and the Simple Multicast 509 proposal of Perlman et. al. [SIMPLE]. We would also like to thank Jon 510 Postel and David Cheriton for their support in reassigning the 232/8 511 address range to SSM. Brian Haberman contributed to the IPv6 portion of 512 this document. 514 11. References 516 11.1. Normative 518 [RFC791] Postel, J., ed., "Internet Protocol, Darpa Internet Program 519 Protocol Specification," September 1981. 521 [IPV6-UBM] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 Multicast 522 Addresses.", RFC 3306, August 2002. 524 [IPV6-MALLOC] B. Haberman, "Dynamic Allocation Guidelines for IPv6 525 Multicast Addresses", RFC 3307, August 2002. 527 [ETHERv6] Crawford, M., "Transmission of IPv6 Packets over Ethernet 528 Networks", RFC2464, Dec 1998. 530 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, 531 August 1989. 533 [RFC2373] Hinden, R. and Deering, S. "IP Version 6 Addressing 534 Architecture." RFC 2373, July 1998. 536 11.2. Non-normative 538 [ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 539 RFC 2365, July 1998. 541 [DVMRP] Waitzman, D., Partridge, C., and S. Deering., "Distance Vector 542 Multicast Routing Protocol," RFC 1075, Nov 1988. 544 [EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested Source- 545 Specific Multicast: EXPRESS support for Large-scale Single-source 546 Applications." Proceedings of ACM SIGCOMM '99, Cambridge, MA, September 547 1999. 549 [IANA-ALLOCATION] Internet Assigned Numbers Authority, 550 http://www.isi.edu/in-notes/iana/assignments/multicast-addresses. 552 [IANA-CONSIDERATIONS] Narten, T., and H. Alvestrand, "Guidelines for 553 Writing an IANA Considerations Section in RFCs," RFC 2434, October 1998. 555 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," 556 RFC 2236, November 1997. 558 [IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group 559 Management Protocol, Version 3," RFC 3376, October 2002. 561 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the Internet 562 Protocol.", RFC 2401. 564 [MLDv2] R. Vida, L. Costa, R. Zara, S. Fdida, S. Deering, B. Fenner, I. 565 Kouvelas, B. Haberman. "Multicast Listener Discovery Version 2 (MLDv2) 566 for IPv6." Work in Progress. 568 [MSFAPI] Thaler, D., Fenner, B., and Quinn, B. "Socket Interface 569 Extensions for Multicast Source Filters." Work in Progress. 571 [PIM-SM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 572 Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol 573 Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification," RFC 574 2362, June 1998. 576 [PIM-DM] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy, 577 A., Meyer, D., and L. Wei, "Protocol Independent Multicast Version 2 578 Dense Mode Specification," Work in Progress. 580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 581 Requirement Levels," RFC 2119, March 1997. 583 [RFC2710] S. Deering, W. Fenner, B. Haberman, "Multicast Listener 584 Discovery (MLD) for IPv6", RFC 2710, October 1999. 586 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address 587 Allocation," RFC 2771, February 2000. 589 [SIMPLE] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. 590 Maufer, C. Diot, and M. Green. "Simple Multicast: A Design for Simple, 591 Low-Overhead Multicast." Work in Progress. 593 [SMRP] Green, M. "Method and System of Multicast Routing for Groups 594 with a Single Transmitter." United States Patent Number 5,517,494. 596 12. Author's Address 598 Brad Cain 599 Cereva Networks 600 3 Network Drive 601 Marlborough, MA 01752 602 bcain@cereva.com 604 Hugh Holbrook 605 Cisco Systems 606 170 W. Tasman Drive 607 San Jose, CA 95134 608 holbrook@cisco.com 610 This document expires May 3, 2003.