idnits 2.17.1 draft-ietf-ssm-arch-02.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 : ---------------------------------------------------------------------------- == 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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 386 has weird spacing: '...equired modif...' == Line 682 has weird spacing: '...imed to perta...' -- 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 (2 Mar 2003) is 7723 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: 'IPv6-UBM' is mentioned on line 65, but not defined == Missing Reference: 'IPv6-MALLOC' is mentioned on line 66, but not defined == Unused Reference: 'IGMPv2' is defined on line 628, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC2710' is defined on line 652, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2362 (ref. 'PIM-SM') (Obsoleted by RFC 4601, RFC 5059) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 4 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 Sep 2, 2003 Cisco Systems 4 B. Cain 5 Storigen Systems 6 2 Mar 2003 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. For 40 IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for 41 Source-Specific Multicast use. It defines an extension to the Internet 42 network service that applies to datagrams sent to SSM addresses and 43 defines the host and router requirements to support this extension. 45 1. Introduction 47 The Internet Protocol (IP) multicast service model is defined in RFC 48 1112 [RFC1112]. RFC 1112 specifies that a datagram sent to an IP 49 multicast address (224.0.0.0 through 239.255.255.255) G is delivered to 50 each "upper-layer protocol module" that has requested reception of 51 datagrams sent to address G. RFC 1112 calls the network service 52 identified by a multicast destination address G a "host group." This 53 model supports both one-to-many and many-to-many group communication. 54 This document uses the term "Any-Source Multicast" (ASM) to refer to the 55 RFC 1112 model of multicast. RFC 2373 [RFC2373] specifies the form of 56 IPv6 multicast addresses with ASM semantics. 58 IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 59 currently designated as source-specific multicast (SSM) destination 60 addresses and are reserved for use by source-specific applications and 61 protocols [IANA-ALLOCATION]. 63 For IPv6, the address prefix FF3x::/32 is reserved for source-specific 64 multicast use, where 'x' is any valid scope identifier, by [IPV6-UBM]. 65 Using the terminology of [IPv6-UBM], this means that P=1, T=1, and 66 plen=0 for any SSM address. [IPv6-MALLOC] mandates that the network 67 prefix field of an SSM address also be set to zero, hence all SSM 68 addresses fall in the FF3x::/96 range. Future documents may allow a 69 non-zero network prefix field if, for instance, a new IP address to MAC 70 address mapping is defined. Thus, address allocation should occur 71 within the FF3x::/96 range, but a system should treat all of FF3x::/32 72 as an SSM address, to allow for compatibility with possible future uses 73 of the network prefix field. 75 Addresses in the range FF3x::4000:0000 through FF3x::7FFF:FFFF are 76 reserved for allocation by IANA, and addresses in the range 77 FF3x::8000:0000 through FF3x::FFFF:FFFF are allowed for dynamic 78 allocation by a host, as described in [IPV6-MALLOC]. Addresses in the 79 range FF3x::0000:0000 through FF3x::3FFF:FFFF are invalid IPv6 SSM 80 addresses, per [IPV6-UBM]. The treatment of a packet sent to such an 81 invalid address is undefined -- a router or host MAY choose to drop such 82 a packet. 84 Source-specific multicast delivery semantics are provided for a datagram 85 sent to an SSM address. That is, a datagram with source IP address S 86 and SSM destination address G is delivered to each upper-layer "socket" 87 that has specifically requested the reception of datagrams sent to 88 address G by source S, and only to those sockets. The network service 89 identified by (S,G), for SSM address G and source host address S, is 90 referred to as a "channel." In contrast to the ASM model of RFC 1112, 91 SSM provides network-layer support for one-to-many delivery only. 93 The benefits of source-specific multicast include: 95 Elimination of cross-delivery of traffic when two sources 96 simultaneously use the same source-specific destination address. 97 The simultaneous use of an SSM destination address by multiple 98 sources and different applications is explicitly supported. 100 Avoidance of the need for inter-host coordination when choosing 101 source-specific addresses, as a consequence of the above. 103 Avoidance of many of the router protocols and algorithms that are 104 needed to provide the ASM service model. For instance, the "shared 105 trees" and Rendezvous Points of the PIM-Sparse Mode (PIM-SM) 106 protocol [PIM-SM] are not necessary to support the source-specific 107 model. The router mechanisms required to support SSM are in fact 108 largely a subset of those that are used to support ASM. For 109 example, the shortest-path tree mechanism of the PIM-SM protocol can 110 be adapted to provide SSM semantics. 112 Like ASM, the set of receivers is unknown to an SSM sender. An SSM 113 source is provided with neither the identity of receivers nor their 114 number. 116 SSM is particularly well-suited to dissemination-style applications with 117 one or more senders whose identities are known before the application 118 begins. For instance, a data dissemination application that desires to 119 provide a secondary data source in case the primary source fails over 120 might implement this by using one channel for each source and 121 advertising both of them to receivers. SSM can be used to build multi- 122 source applications where all participants' identities are not known in 123 advance, but the multi-source "rendezvous" functionality does not occur 124 in the network layer in this case. Just like in an application that 125 uses unicast as the underlying transport, this functionality can be 126 implemented by the application or by an application-layer library. 128 Multicast resource discovery of the form in which a client sends a 129 multicast query directly to a "service location group" to which servers 130 listen is not directly supported by SSM. 132 This document defines the semantics of source-specific multicast 133 addresses and specifies the policies governing their use. In 134 particular, it defines an extension to the Internet network service that 135 applies to datagrams sent to SSM addresses and defines host extensions 136 to support the network service. Hosts, routers, applications, and 137 protocols that use these addresses MUST comply with the policies 138 outlined in this document. Failure of a host to comply may prevent that 139 host or other hosts on the same LAN from receiving traffic sent to an 140 SSM channel. Failure of a router to comply may cause SSM traffic to be 141 delivered to parts of the network where it is unwanted, unnecessarily 142 burdening the network. 144 2. Semantics of Source-Specific Multicast Addresses 146 The source-specific multicast service is defined as follows: 148 A datagram sent with source IP address S and destination IP address 149 G in the SSM range is delivered to each host socket that has 150 specifically requested delivery of datagrams sent by S to G, and 151 only to those sockets. 153 Where, using the terminology of [IGMPv3], 155 "socket" is an implementation-specific parameter used to distinguish 156 among different requesting entities (e.g., programs or processes or 157 communication end-points within a program or process) within the 158 requesting host; the socket parameter of BSD Unix system calls is a 159 specific example. 161 Any host may send a datagram to any SSM address, and delivery is 162 provided according to the above semantics. 164 The IP module interface to upper-layer protocols is extended to allow a 165 socket to "Subscribe" to or "Unsubscribe" from a particular channel 166 identified by an SSM destination address and a source IP address. The 167 extended interface is defined in section 4.1. It is meaningless for an 168 application or host to request reception of datagrams sent to an SSM 169 destination address G, as is supported in the Any-Source Multicast 170 model, without also specifying a corresponding source address, and 171 routers MUST ignore any such request. 173 Multiple source applications on different hosts can use the same SSM 174 destination address G without conflict because datagrams sent by each 175 source host Si are delivered only to those sockets that requested 176 delivery of datagrams sent to G specifically by Si. 178 The key distinguishing property of the model is that a channel is 179 identified (addressed) by the combination of a unicast source address 180 and a multicast destination address in the SSM range. So, for example, 181 the channel 183 S,G = (192.0.2.1, 232.7.8.9) 185 differs from 187 S,G = (192.0.2.2, 232.7.8.9), 189 even though they have the same destination address portion. Similarly, 190 for IPv6, 192 S,G = (2001:3618::1, FF33::1234) 194 and 196 S,G = (2001:3618::2, FF33::1234) 198 are different channels. 200 3. Terminology 202 To reduce confusion when talking about the Any-Source and Source- 203 Specific Multicast models, we use different terminology when discussing 204 them. 206 We use the term "channel" to refer to the service associated with an SSM 207 address. A channel is identified by the combination of an SSM 208 destination address and a specific source, e.g., an (S,G) pair. 210 We use the term "host group" (used in RFC 1112) to refer to the service 211 associated with "regular" ASM multicast addresses (excluding those in 212 the SSM range). A host group is identified by a single multicast 213 address. 215 Any host can send to a host group, and similarly, any host can send to 216 an SSM destination address. A packet sent by a host S to an ASM 217 destination address G is delivered to the host group identified by G. A 218 packet sent by host S to an SSM destination address G is delivered to 219 the channel identified by (S,G). The receiver operations allowed on a 220 host group are called "join(G)" and "leave(G)" (as per RFC 1112). The 221 receiver operations allowed on a channel are called "Subscribe(S,G)" and 222 "Unsubscribe(S,G)." 224 The following table summarizes the terminology: 226 Service Model: Any-Source Source-Specific 227 Network Abstraction: group channel 228 Identifier: G S,G 229 Receiver Operations: join, leave subscribe, unsubscribe 231 We note that, although this document specifies a new service model 232 available to applications, the protocols and techniques necessary to 233 support the service model are largely a subset of those used to support 234 ASM. 236 4. Host Requirements 238 This section describes requirements on hosts that support Source- 239 Specific Multicast, including: 241 - Extensions to the IP Module Interface 243 - Extensions to the IP Module 245 - Allocation of SSM Addresses 247 4.1. Extensions to the IP Module Interface 249 The IP module interface to upper-layer protocols is extended to allow 250 protocols to request reception of all datagrams sent to a particular 251 channel. 253 Subscribe ( socket, source-address, group-address, interface ) 255 Unsubscribe ( socket, source-address, group-address, interface ) 257 where 259 "socket" is as previously defined in Section 2, 261 and, paraphrasing [IGMPv3], 263 "interface" is a local identifier of the network interface on which 264 reception of the channel identified by the (source-address,group- 265 address) pair is to be enabled or disabled. A special value may be 266 used to indicate a "default" interface. If reception of the same 267 channel is desired on multiple interfaces, Subscribe is invoked once 268 for each. 270 The above are strictly abstract functional interfaces -- the 271 functionality can be provided in an implementation-specific way. On a 272 host that supports the multicast source filtering application 273 programming interface of [MSFAPI], for instance, the Subscribe and 274 Unsubscribe interfaces may be supported via that API. When a host has 275 been configured to know the SSM address range, (whether the 276 configuration mechanism is manual or through a protocol) the host's 277 operating system SHOULD return an error to an application that makes a 278 non-source-specific request to receive multicast sent to an SSM 279 destination address. 281 Widespread implementations of the IP packet reception interface (e.g., 282 the recvfrom() system call in BSD unix) do not allow a receiver to 283 determine the destination address to which a datagram was sent. On a 284 host with such an implementation, the destination address of a datagram 285 cannot be inferred when the socket on which the datagram is received is 286 Subscribed to multiple channels. Host operating systems SHOULD provide 287 a way for a host to determine both the source and the destination 288 address to which a datagram was sent. (As one example, the Linux 289 operating system provides the destination of a packet as part of the 290 response to the recvmsg() system call.) Until this capability is 291 present, applications may be forced to use higher-layer mechanisms to 292 identify the channel to which a datagram was sent. 294 4.2. Requirements on the Host IP Module 296 An incoming datagram destined to an SSM address MUST be delivered by the 297 IP module to all sockets that have indicated (via Subscribe) a desire to 298 receive data that matches the datagram's source address, destination 299 address, and arriving interface. It MUST NOT be delivered to other 300 sockets. 302 When the first socket on host H subscribes to a channel (S,G) on 303 interface I, the host IP module on H sends a request on interface I to 304 indicate to neighboring routers that the host wishes to receive traffic 305 sent by source S to source-specific destination G. Similarly, when the 306 last socket on a host unsubscribes from a channel on interface I, the 307 host IP module sends an unsubscription request for that channel out 308 interface I. 310 These requests will typically be Internet Group Management Protocol 311 version 3 messages for IPv4, or Multicast Listener Discovery Version 2 312 messages for IPv6 [IGMPv3,MLDv2]. A separate document describes how 313 IGMPv3 and MLDv2 are adapted to support source-specific multicast. 315 4.3. Allocation of Source-Specific Multicast Addresses 317 The SSM destination address 232.0.0.0 is reserved, and systems MUST NOT 318 send datagrams with destination address of 232.0.0.0. The address range 319 232.0.0.1-232.0.0.255 is currently reserved for allocation by IANA. The 320 IPv6 SSM address range FF3x::/32 is reserved for IANA allocation. 322 The policy for allocating the rest of the SSM addresses to sending 323 applications is strictly locally determined by the sending host. 325 When allocating SSM addresses dynamically, a host or host operating 326 system MUST NOT allocate sequentially starting at the first allowed 327 address. It is RECOMMENDED to allocate SSM addresses to applications 328 randomly, while ensuring that allocated addresses are not given 329 simultaneously to multiple applications (and avoiding the reserved 330 address range for IPv4). For IPv6, the randomization should apply to 331 the lower 32 bits of the address. 333 As described in Section 6, the mapping of an IP packet with SSM 334 destination address onto a link-layer multicast address does not take 335 into account the datagram's source IP address (on commonly-used link 336 layers like Ethernet). If all hosts started at the first allowed 337 address, then with high probability, many source-specific channels on 338 shared-medium local area networks would use the same link-layer 339 multicast address. As a result, traffic destined for one channel 340 subscriber would be delivered to another's IP module, which would then 341 have to reject the datagram. 343 A host operating system SHOULD provide an interface to allow an 344 application to request a unique allocation of a channel destination 345 address in advance of a session's commencement, and this allocation 346 database SHOULD persist across host reboots. By providing persistent 347 allocations, a host application can advertise the session in advance of 348 its start time on a web page or in another directory. (We note that 349 this issue is not specific to SSM applications -- the same problem 350 arises for ASM.) 352 This document neither defines the interfaces for requesting or returning 353 addresses nor specifies the host algorithms for storing those 354 allocations. One plausible abstract API is defined in RFC 2771 355 [RFC2771]. Note that RFC 2771 allows an application to request an 356 address within a specific range of addresses. If this interface is 357 used, the starting address of the range SHOULD be selected at random by 358 the application. 360 For IPv6, administratively scoped SSM addresses are created by choosing 361 an appropriate scope identifier for the SSM destination address. Normal 362 IPv6 multicast scope boundaries are applied to traffic sent to an SSM 363 destination address. 365 No globally agreed-upon administratively-scoped address range [ADMIN- 366 SCOPE] is currently defined for IPv4 source-specific multicast. For 367 IPv4, administrative scoping of SSM addresses can be implemented within 368 an administrative domain by filtering outgoing SSM traffic sent to a 369 scoped address at the domain's boundary routers. 371 5. Router Requirements 373 5.1. Packet Forwarding 375 A router that receives an IP datagram with a source-specific destination 376 address MUST silently drop it unless a neighboring host or router has 377 communicated a desire to receive packets sent from the source and to the 378 destination address of the received packet. 380 5.2. Protocols 382 Certain IP multicast routing protocols already have the ability to 383 communicate source-specific joins to neighboring routers (in particular, 384 PIM-SM [PIM-SM]), and these protocols can, with slight modifications, be 385 used to provide source-specific semantics. Companion documents will 386 specify the required modifications to those protocols to support SSM. 388 A network can concurrently support SSM in the SSM address range and Any- 389 Source Multicast in the rest of the multicast address space, and it is 390 expected that this will be commonplace. In such a network, a router may 391 receive a non-source-specific, or "(*,G)" in conventional terminology, 392 request for delivery of traffic in the SSM range from a neighbor that 393 does not implement source-specific multicast in a manner compliant with 394 this document. A router that receives such a non-source-specific 395 request for data in the SSM range MUST NOT use the request to establish 396 forwarding state and MUST NOT propagate the request to other neighboring 397 routers. A router MAY log an error in such a case. This applies both 398 to any request received from a host, e.g., an IGMPv1 or IGMPv2 host 399 report, and to any request received from a routing protocol, e.g., a 400 PIM-SM (*,G) join. The inter-router case is further discussed in 401 section 8, Transition Considerations. 403 It is essential that all routers in the network give source-specific 404 semantics to the same range of addresses in order to achieve the full 405 benefit of SSM. To comply with this specification, a router MUST treat 406 ALL IANA-allocated SSM addresses with source-specific semantics. 408 6. Link-Layer Transmission of Datagrams 410 Source-specific multicast packets are transmitted on link-layer networks 411 as specified in RFC 1112 for IPv4 and as in [ETHERv6] for IPv6. On most 412 shared-medium link-layer networks that support multicast (e.g., 413 Ethernet), the IP source address is not used in the selection of the 414 link-layer destination address. Consequently, on such a network, all 415 packets sent to destination address G will be delivered to any host that 416 has subscribed to any channel (S,G), regardless of S. And therefore, 417 the IP module MUST filter packets it receives from the link layer before 418 delivering them to the socket layer. 420 7. Security Considerations 422 7.1. IPSec and SSM 424 The IPSec Authentication Header (AH) and Encapsulating Security Payload 425 (ESP) protocols [IPSEC] can be used to secure SSM traffic. As of this 426 writing, however, the IPSec protocols have some limitations when used 427 with SSM. This section describes those limitations. 429 [IPSEC] specifies that every incoming packet that requires IPSec 430 processing is ultimately looked up in a local Security Association 431 Database (SAD) to determine the Security Association (SA) that is to be 432 applied to the packet. The resulting SA determines the decryption 433 and/or authentication key to use and the anti-replay window, if one is 434 used. The key used for the SAD lookup is: 436 - the packet's destination IP address 438 - the IPSec protocol (ESP or AH) 440 - the Security Parameter Index (SPI) 442 A problem arises for SSM because the source address is not included in 443 the SAD lookup. IPSec does not currently provide any way to ensure that 444 two unrelated SSM channels will have unique SAD entries at all 445 receivers. Two senders that happen to choose the same SSM destination 446 address and the same Security Parameter Index will "collide" in the SAD 447 at any host that is receiving both channels. Because the channel 448 addresses and SPIs are both allocated autonomously by the senders, there 449 is no reasonable means to ensure that each sender uses a unique 450 destination address or SPI. 452 In practice, this problem only arises if a receiver subscribes 453 simultaneously to two unrelated channels using IPSec whose sources 454 happen to have chosen the same IP destination address (IPDA) and the 455 same IPSec SPI. The tuple, however, consists of 56 bits that 456 are generally randomly chosen, and a conflict is unlikely to occur 457 through random chance. 459 But when this problem occurs, however unlikely, a host will not be able 460 to simultaneously receive IPSec-protected traffic from the two colliding 461 sources under the current IPSec model. 463 This problem is under investigation and a solution will appear in a 464 separate document. One possible solution is to include the source 465 address in the SAD lookup when the destination is an SSM address. 467 7.2. Denial of Service 469 A subscription request creates (S,G) state in a router to record the 470 subscription, invokes processing on that router, and possibly causes 471 processing at neighboring routers. A host can mount a denial of service 472 attack by requesting a large number of subscriptions. A denial of 473 service can result if: 475 - a large amount of traffic arrives when it was otherwise undesired, 476 consuming network resources to deliver it and host resources to drop 477 it 479 - a large amount of source-specific multicast state is created in 480 network routers, using router memory and CPU resources to store and 481 process the state 483 - a large amount of control traffic is generated to manage the 484 source-specific state, using router CPU and network bandwidth 486 To reduce the damage from such an attack, a router MAY have 487 configuration options to limit the following items: 489 - The total rate at which all hosts on any one interface are allowed 490 to initiate subscriptions (to limit the damage caused by forged 491 source-address attacks) 493 - The total number of subscriptions that can be initated from any 494 single interface or host. 496 Any decision by an implementor to artificially limit the rate or number 497 of subscriptions should be taken carefully, however, as future 498 applications may use large numbers of channels. Tight limits on the 499 rate or number of channel subscriptions would inhibit the deployment of 500 such applications. 502 A router SHOULD verify that the source of a subscription request is a 503 valid address for the interface on which it was received. Failure to do 504 so would exacerbate a spoofed-source address attack. 506 We note that these attacks are not unique to SSM -- they are also 507 present for Any-Source Multicast. 509 7.3. Spoofed Source Addresses 511 By forging the source address in a datagram, an attacker can potentially 512 violate the SSM service model by transmitting datagrams on a channel 513 belonging to another host. Thus, an application requiring strong 514 authentication should not assume that all packets that arrive on a 515 channel were sent by the requested source without higher-layer 516 authentication mechanisms. The IPSEC Authentication Header [IPSEC] may 517 be used to authenticate the source of an SSM transmission, for instance. 519 Some degree of protection against spoofed source addresses in multicast 520 is already fairly widespread, because the commonly deployed IP multicast 521 routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a "reverse-path 522 forwarding check" that validates that a multicast packet arrived on the 523 expected interface for its source address. Routing protocols used for 524 SSM SHOULD incorporate such a check. 526 Source Routing [RFC791] (both Loose and Strict) in combination with 527 source address spoofing may be used to allow an impostor of the true 528 channel source to inject packets onto an SSM channel. An SSM router 529 SHOULD by default disallow source routing to an SSM destination address. 530 A router MAY have a configuration option to allow source routing. Anti- 531 source spoofing mechanisms such as source address filtering at the edges 532 of the network are also strongly encouraged. 534 8. Transition Considerations 536 A host that complies with this document will send ONLY source-specific 537 host reports for addresses in the SSM range. As stated above, a router 538 that receives a non-source-specific (e.g., IGMPv1 or IGMPv2 or MLDv1) 539 host report for a source-specific destination addresses MUST ignore 540 these reports. Failure to do so would violate the SSM service model 541 promised to the sender: that a packet sent to (S,G) would only be 542 delivered to hosts that specifically requested delivery of packets sent 543 to G by S. 545 During a transition period, it would be possible to deliver SSM 546 datagrams in a domain where the routers do not support SSM semantics by 547 simply forwarding any packet destined to G to all hosts that have 548 requested subscription of (S,G) for any S. However, this implementation 549 risks unduly burdening the network infrastructure by deliver (S,G) 550 datagrams to hosts that did not request them. Such an implementation 551 for addresses in the SSM range is specifically not compliant with 552 Section 5.2 of this document. 554 9. IANA Considerations 556 Addresses in the range 232.0.0.1 through 232.0.0.255 and IPv6 addresses 557 with prefix FF3x:: are reserved for services with wide applicability 558 that either require or would strongly benefit if all hosts used a well- 559 known SSM destination address for that service. IANA shall allocate 560 addresses in this range according to IETF Consensus [IANA- 561 CONSIDERATIONS]. Any proposal for allocation must consider the fact 562 that, on an Ethernet network, all datagrams sent to any SSM destination 563 address will be transmitted with the same link-layer destination 564 address, regardless of the source. Furthermore, the fact that SSM 565 destinations in 232.0.0.0/24 and 232.128.0.0/24 use the same link-layer 566 addresses as the reserved IP multicast group range 224.0.0.0/24 must 567 also be considered. Similar consideration should be given to the IPv6 568 reserved multicast addresses. 570 Except for the aforementioned addresses, IANA SHALL NOT allocate any SSM 571 destination address to a particular entity or application. To do so 572 would compromise one of the important benefits of the source-specific 573 model: the ability for a host to simply and autonomously allocate a 574 source-specific address from a large flat address space. 576 10. Acknowledgments 578 The SSM service model draws on a variety of prior work on alternative 579 aproaches to IP multicast, including the EXPRESS multicast model of 580 Holbrook and Cheriton [EXPRESS], Green's [SMRP] and the Simple Multicast 581 proposal of Perlman et. al. [SIMPLE]. We would also like to thank Jon 582 Postel and David Cheriton for their support in reassigning the 232/8 583 address range to SSM. Brian Haberman contributed to the IPv6 portion of 584 this document. 586 11. Normative References 588 [ETHERv6] Crawford, M., "Transmission of IPv6 Packets over Ethernet 589 Networks", RFC2464, Dec 1998. 591 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the Internet 592 Protocol.", RFC 2401. 594 [IPV6-UBM] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 Multicast 595 Addresses.", RFC 3306, August 2002. 597 [IPV6-MALLOC] B. Haberman, "Dynamic Allocation Guidelines for IPv6 598 Multicast Addresses", RFC 3307, August 2002. 600 [RFC791] Postel, J., ed., "Internet Protocol, Darpa Internet Program 601 Protocol Specification," September 1981. 603 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, 604 August 1989. 606 [RFC2373] Hinden, R. and Deering, S. "IP Version 6 Addressing 607 Architecture." RFC 2373, July 1998. 609 12. Informative References 611 [ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 612 RFC 2365, July 1998. 614 [DVMRP] Waitzman, D., Partridge, C., and S. Deering., "Distance Vector 615 Multicast Routing Protocol," RFC 1075, Nov 1988. 617 [EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested Source- 618 Specific Multicast: EXPRESS support for Large-scale Single-source 619 Applications." Proceedings of ACM SIGCOMM '99, Cambridge, MA, September 620 1999. 622 [IANA-ALLOCATION] Internet Assigned Numbers Authority, 623 http://www.iana.org/assignments/multicast-addresses. 625 [IANA-CONSIDERATIONS] Narten, T., and H. Alvestrand, "Guidelines for 626 Writing an IANA Considerations Section in RFCs," RFC 2434, October 1998. 628 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," 629 RFC 2236, November 1997. 631 [IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group 632 Management Protocol, Version 3," RFC 3376, October 2002. 634 [MLDv2] R. Vida, and L. Costa. "Multicast Listener Discovery Version 2 635 (MLDv2) for IPv6." Work in Progress. 637 [MSFAPI] Thaler, D., Fenner, B., and Quinn, B. "Socket Interface 638 Extensions for Multicast Source Filters." Work in Progress. 640 [PIM-SM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 641 Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol 642 Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification," RFC 643 2362, June 1998. 645 [PIM-DM] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy, 646 A., Meyer, D., and L. Wei, "Protocol Independent Multicast Version 2 647 Dense Mode Specification," Work in Progress. 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels," RFC 2119, March 1997. 652 [RFC2710] S. Deering, W. Fenner, B. Haberman, "Multicast Listener 653 Discovery (MLD) for IPv6", RFC 2710, October 1999. 655 [RFC2771] Finlayson, R., "An Abstract API for Multicast Address 656 Allocation," RFC 2771, February 2000. 658 [SIMPLE] R. Perlman, C-Y Lee, A. Ballardie, J. Crowcroft, Z. Wang, T. 659 Maufer, C. Diot, and M. Green. "Simple Multicast: A Design for Simple, 660 Low-Overhead Multicast." Work in Progress. 662 [SMRP] Green, M. "Method and System of Multicast Routing for Groups 663 with a Single Transmitter." United States Patent Number 5,517,494. 665 Authors' Addresses 667 Brad Cain 668 Storigen Systems 669 650 Suffolk St. 670 Lowell, MA 01854 671 bcain@storigen.com 673 Hugh Holbrook 674 Cisco Systems 675 170 W. Tasman Drive 676 San Jose, CA 95134 677 holbrook@cisco.com 679 Intellectual Property Rights Notice 681 The IETF takes no position regarding the validity or scope of any 682 intellectual property or other rights that might be claimed to pertain 683 to the implementation or use of the technology described in this 684 document or the extent to which any license under such rights might or 685 might not be available; neither does it represent that it has made any 686 effort to identify any such rights. Information on the IETF's 687 procedures with respect to rights in standards-track and standards- 688 related documentation can be found in BCP-11. Copies of claims of 689 rights made available for publication and any assurances of licenses to 690 be made available, or the result of an attempt made to obtain a general 691 license or permission for the use of such proprietary rights by 692 implementors or users of this specification can be obtained from the 693 IETF Secretariat. 695 The IETF invites any interested party to bring to its attention any 696 copyrights, patents or patent applications, or other proprietary rights 697 which may cover technology that may be required to practice this 698 standard. Please address the information to the IETF Executive 699 Director. 701 Full Copyright Statement 703 Copyright (C) The Internet Society (2002). All Rights Reserved. 705 This document and translations of it may be copied and furnished to 706 others, and derivative works that comment on or otherwise explain it or 707 assist in its implementation may be prepared, copied, published and 708 distributed, in whole or in part, without restriction of any kind, 709 provided that the above copyright notice and this paragraph are included 710 on all such copies and derivative works. However, this document itself 711 may not be modified in any way, such as by removing the copyright notice 712 or references to the Internet Society or other Internet organizations, 713 except as needed for the purpose of developing Internet standards in 714 which case the procedures for copyrights defined in the Internet 715 Standards process must be followed, or as required to translate it into 716 languages other than English. 718 The limited permissions granted above are perpetual and will not be 719 revoked by the Internet Society or its successors or assigns. 721 This document and the information contained herein is provided on an "AS 722 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 723 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 724 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 725 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 726 FITNESS FOR A PARTICULAR PURPOSE. 728 This document expires Sep 2, 2003.