idnits 2.17.00 (12 Aug 2021) /tmp/idnits11180/draft-ietf-magma-msnip-03.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 54 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 258: '...Pv6. This option MUST be included in a...' RFC 2119 keyword, line 286: '...MSNIP, the mis-configuration SHOULD be...' RFC 2119 keyword, line 290: '...ers on that link MUST be configured to...' RFC 2119 keyword, line 314: '...system MUST default to flooding and im...' RFC 2119 keyword, line 322: '... system MUST use the SSM multicast de...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 April 2003) is 6989 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 1000, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1003, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2463 (ref. '5') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2401 (ref. '8') (Obsoleted by RFC 4301) == Outdated reference: draft-ietf-magma-igmp-proxy has been published as RFC 4605 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force MAGMA WG 2 INTERNET-DRAFT B. Fenner/AT&T 3 draft-ietf-magma-msnip-03.txt B. Haberman/Caspian Networks 4 H. Holbrook/Cisco 5 I. Kouvelas/Cisco 6 2 April 2003 7 Expires: October 2003 9 Multicast Source Notification of Interest Protocol (MSNIP) 11 Status of this Document 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 This document is a product of the IETF MAGMA WG. Comments should be 32 addressed to the authors, or the WG's mailing list at magma@ietf.org. 34 Abstract 36 This document discusses the Multicast Source Interest 37 Notification Protocol (MSNIP). MSNIP is an extension to 38 IGMPv3 and MLDv2 that provides membership notification 39 services for sources of multicast traffic operating within the 40 SSM destination address range. 42 Table of Contents 44 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 45 2. Routing Protocol Support. . . . . . . . . . . . . . . . 3 46 3. Service Interface for Requesting Membership Noti- 47 fication . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3.1. Application Operation. . . . . . . . . . . . . . . . 5 49 4. MSNIP Managed Address Range Negotiation . . . . . . . . 6 50 4.1. Router Coordination. . . . . . . . . . . . . . . . . 6 51 4.1.1. MSNIP Operation Option. . . . . . . . . . . . . . 6 52 4.1.2. SSM Range Option. . . . . . . . . . . . . . . . . 7 53 4.2. Managed Range Discovery by Source Systems. . . . . . 7 54 5. Requesting and Receiving Notifications. . . . . . . . . 8 55 5.1. Host Interest Solicitation . . . . . . . . . . . . . 9 56 5.2. Router Receiver Membership Reports . . . . . . . . . 9 57 6. Application Notification. . . . . . . . . . . . . . . . 10 58 7. Router Processing . . . . . . . . . . . . . . . . . . . 12 59 8. Message Formats . . . . . . . . . . . . . . . . . . . . 14 60 8.1. Host Interest Solicitation Packet. . . . . . . . . . 15 61 8.2. Receiver Membership Report Packet. . . . . . . . . . 15 62 8.3. IPv4 Header Fields . . . . . . . . . . . . . . . . . 17 63 8.4. IPv6 Header Fields . . . . . . . . . . . . . . . . . 17 64 9. Constants Timers and Default Values . . . . . . . . . . 18 65 10. Possible Optimisations . . . . . . . . . . . . . . . . 18 66 10.1. Suppressing HIS Messages. . . . . . . . . . . . . . 18 67 10.2. Host Stack Filtering. . . . . . . . . . . . . . . . 18 68 10.3. Responding to Unexpected IGMP Queries . . . . . . . 19 69 10.4. Host and Router Startup . . . . . . . . . . . . . . 19 70 11. Inter-operation with IGMP / MLD Proxying . . . . . . . 20 71 12. Security Considerations. . . . . . . . . . . . . . . . 20 72 12.1. Receiver Membership Report attacks. . . . . . . . . 21 73 12.2. Host Interest Solicitation attacks. . . . . . . . . 21 74 12.3. MSNIP Managed Range Discovery . . . . . . . . . . . 22 75 13. IANA Considerations. . . . . . . . . . . . . . . . . . 22 76 14. Acknowledgments. . . . . . . . . . . . . . . . . . . . 23 77 15. Normative References . . . . . . . . . . . . . . . . . 23 78 16. Informative References . . . . . . . . . . . . . . . . 23 80 1. Introduction 82 The Multicast Source Notification of Interest Protocol (MSNIP) is 83 an extension to version 3 of the Internet Group Membership Protocol 84 (IGMPv3 [1]) and version 2 of the Multicast Listener Discovery Protocol 85 (MLDv2 [2]). MSNIP operates between multicast sources and their first- 86 hop routers to provide information on the presence of receivers to the 87 source systems. Using the services offered by MSNIP an application on an 88 IP system wishing to source multicast data can register to be notified 89 when receivers join and leave the session. This enables multicast 90 sources to avoid the work of transmitting packets onto their first-hop 91 link when there are no joined receivers. 93 A common scenario where MSNIP may be useful is one where there is a 94 multicast server offering a large pool of potential flows that map onto 95 separate multicast destination addresses but receivers exist only for a 96 small subset of the flows. If the source were to continuously transmit 97 data for all the flows that could potentially have receivers, 98 significant resources would be wasted in the system itself as well as 99 the first-hop link and first-hop router. Using a higher level control 100 protocol to determine the existence of receivers for particular flows 101 may not be practical as there may be many potential receivers in each 102 active session. 104 Information on which multicast destination addresses have receivers 105 for a particular sender is typically available to the multicast routing 106 protocol on the first hop router for a source. MSNIP uses this 107 information to notify the application in the sending system of when it 108 should start or stop transmitting. This is achieved without any 109 destination address specific state on the first-hop router for potential 110 sources without receivers. 112 2. Routing Protocol Support 114 For reasons described in this section, MSNIP only supports 115 transmission control for applications that use multicast destination 116 addresses that are routed using Source Specific Multicast (SSM). 118 Many currently deployed multicast routing protocols require data 119 from an active source to be propagated past the first-hop router before 120 information on the existence of receivers becomes available on the 121 first-hop. In addition, such protocols require that this activity is 122 repeated periodically to maintain source liveness state on remote 123 routers. All dense-mode protocols fall under this category as well as 124 sparse-mode protocols that use shared trees for source discovery (such 125 as PIM-SM [11]). In order to provide receiver interest notification for 126 such protocols, the default mode of operation would require that the 127 source IP system periodically transmits on all potential destination 128 addresses and the first-hop routers prune the traffic back. Such a 129 flood-and-prune behaviour on the first-hop link significantly diminishes 130 the benefits of managing source transmission. 132 In contrast, with source-specific sparse-mode protocols such as 133 PIM-SSM [11] availability of receiver membership information on the 134 first-hop routers is independent of data transmission. Such protocols 135 use an external mechanism for source discovery (like source-specific 136 IGMPv3 membership reports) to build source-specific multicast trees. 138 Clearly these two classes of routing protocols require different 139 handling for the problem MSNIP is trying to solve. In addition the 140 second type covers the majority of applications that MSNIP is targeted 141 at. MSNIP avoids the extra complication in supporting routing protocols 142 that require a flood and prune behaviour. 144 3. Service Interface for Requesting Membership Notification 146 Applications within an IP system that wish to source multicast 147 packets and are interested in being notified on the existence of 148 receivers must register with the IP layer of the system. MSNIP requires 149 that within the IP system, there is (at least conceptually) a service 150 interface that can be used to register with the IP layer for such 151 notifications. Dual stack systems supporting both IPv4 and IPv6 need to 152 provide separate service interfaces for each protocol. 154 A system's IPv4 or IPv6 service interface must support the 155 following operation or any logical equivalent: 157 IPMulticastSourceRegister (socket, source-address, multicast-address) 158 IPMulticastSourceDeregister (socket, source-address, multicast-address) 160 In addition the application must provide the following interface 161 for receiving notifications from the IP system: 163 IPMulticastSourceStart (socket, source-address, multicast-address) 164 IPMulticastSourceStop (socket, source-address, multicast-address) 166 where: 168 socket 169 is an implementation-specific parameter used to distinguish amongst 170 different requesting entities (e.g., programs or processes) within 171 the system; the socket parameter of BSD Unix system calls is a 172 specific example. 174 source-address 175 is the IP unicast source address that the application wishes to use 176 in transmitting data to the specified multicast address. The 177 specified address must be one of the IP addresses associated with 178 the network interfaces of the IP system. Note that an interface in 179 an IP system may be associated with more than one IP address. An 180 implementation may allow a special "unspecified" value to be passed 181 as the source-address parameter, in which case the request would 182 apply to the "primary" IP address of the "primary" or "default" 183 interface of the system (perhaps established by system 184 configuration). If transmission to the same multicast address is 185 desired using more than one source IP address, 186 IPMulticastSourceRegister must be invoked separately for each 187 desired source address. 189 multicast-address 190 is the IP multicast destination address to which the request 191 pertains. If the application wishes to transmit data to more than 192 one multicast addresses for a given source address, 193 IPMulticastSourceRegister must be invoked separately for each 194 desired multicast address. 196 3.1. Application Operation 198 Applications wishing to use MSNIP to control their multicast data 199 transmission to destination G from source address S operate as follows. 201 Initially the application contacts the IP system to obtain the 202 socket handle for use on all subsequent interactions. The application 203 invokes IPMulticastSourceRegister for the desired S and G and then waits 204 without transmitting any packets for the IP system to notify that 205 receivers for the session exist. 207 If and when the IP system notifies the application that receivers 208 exist using the IPMulticastSourceStart call, the application may start 209 transmitting data. After the application has been notified to send, if 210 all receivers for the session leave, the IP system will notify the 211 application using the IPMulticastSourceStop call. At this point the 212 application should stop transmitting data until it is notified again 213 that receivers have joined through another IPMulticastSourceStart call. 215 When the application no longer wishes to transmit data it should 216 invoke the IPMulticastSourceDeregister call to let the IP system know 217 that it is no longer interested in notifications for this source and 218 destination. The IPMulticastSourceDeregister call should be implicit in 219 the teardown of the associated socket state. 221 4. MSNIP Managed Address Range Negotiation 223 With current multicast deployment in the Internet, different 224 multicast routing protocols coexist and operate under separate parts of 225 the multicast address space. Multicast routers are consistently 226 configured with information that maps specific multicast address ranges 227 to multicast routing protocols. Part of this configuration describes the 228 subset of the address space that is used by source-specific multicast 229 (SSM) [12]. As described in section 2 MSNIP only tries to control 230 application transmission within the SSM address range. 232 It is desirable for applications within an IP system that supports 233 MSNIP to have a consistent service interface for multicast transmission 234 that does not require the application to be aware of the SSM address 235 range. MSNIP supports this by allowing applications to use the service 236 interface described in section 3 for multicast destination addresses 237 that are outside its operating range. When an application registers for 238 notifications for a destination address that is not managed by MSNIP it 239 is immediately notified to start transmitting. This is equivalent to the 240 default behaviour of IP multicast without MSNIP support which forces 241 multicast applications to assume that there are multicast receivers 242 present in the network. 244 4.1. Router Coordination 246 In order for MSNIP to operate on a shared link where more than one 247 multicast routers may be present, all multicast routers must be MSNIP- 248 capable and have an identical configuration for the SSM address range. 249 MSNIP enforces these requirements by using two new options for IPv4 in 250 the Multicast Router Discovery protocol [3] and one new option for IPv6 251 in the Neighbor Discovery / ICMPv6 protocol [6]. 253 4.1.1. MSNIP Operation Option 255 A multicast router advertises that it is participating in MSNIP 256 using the MSNIP Operation option in either the Multicast Router 257 Discovery protocol for IPv4 or the Neighbor Discovery / ICMPv6 protocol 258 for IPv6. This option MUST be included in all router advertisement 259 messages of a router that is configured for MSNIP. The format of the 260 option is as follows: 262 0 1 2 3 263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type | Length | Padding | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Padding | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Type The type field is set to WW (TBD by IANA) for IPv4 and ZZ (TBD by 271 IANA) for IPv6. 273 Length 274 The length field is set to 0 for IPv4 and 1 for IPv6. 276 Padding 277 The six extra bytes of padding are only present in IPv6 and are 278 required to bring the size of the option up to the eight octet 279 boundary. The value of the padding bytes must be set to zero on 280 transmission and ignored on receipt. 282 A multicast router uses received Multicast Router Advertisement and 283 Neighbor Discovery / ICMPv6 messages to determine if all live neighbour 284 multicast routers on each interface are participating in MSNIP. When a 285 router advertisement message not containing an MSNIP option is received 286 by a router participating in MSNIP, the mis-configuration SHOULD be 287 logged to the operator in a rate-limited manner. 289 If even one multicast router on a link does not have MSNIP 290 capability then ALL routers on that link MUST be configured to not 291 provide MSNIP services and to not advertise the MSNIP Operation option. 293 4.1.2. SSM Range Option 295 The SSM Range Multicast Router Discovery option advertises the SSM 296 Range with which the router is configured. The option is defined in [4]. 297 This option is only valid in IPv4. SSM support in IPv6 does not allow 298 for alternative SSM address ranges. 300 4.2. Managed Range Discovery by Source Systems 302 When an application in an IP system uses the MSNIP service 303 interface to register for notification, the IP system must behave 304 differently depending on whether or not the destination address for 305 which the application registered is operating under SSM (and is being 306 managed by MSNIP). For SSM channels, the IP system should only instruct 307 the application to transmit when there are receivers for the multicast 308 destination. For non-SSM destination addresses the IP system will not be 309 able to determine if there are receivers and should immediately instruct 310 the application to transmit. In addition, an MSNIP-capable IP system 311 must be able to detect if there are multicast routers on its connected 312 links and if they support MSNIP operation. If no multicast routers are 313 present or if the multicast routers are not MSNIP-capable then the IP 314 system MUST default to flooding and immediately instruct applications to 315 transmit. 317 An IP system controls transmission behaviour under the different 318 possible conditions by adapting its definition of the MSNIP-managed 319 multicast destination address range: 321 o On a link with multicast routers operating the MSNIP protocol the IP 322 system MUST use the SSM multicast destination address range as the 323 MSNIP-managed range. IPv4 systems MUST use the contents of the SSM 324 Range option in received Multicast Router Advertisement messages [4] 325 to discover the configured SSM range. SSM range discovery is not 326 needed in IPv6 where the SSM destination address range is fixed. 328 o On a link not connected to a multicast routed infrastructure or on a 329 link with multicast routers that do not support MSNIP operation, the 330 IP system MUST use an empty range as its MSNIP-managed range. This 331 forces applications transmitting to any multicast destination address 332 to default to flooding thus providing backward compatibility. 334 As described in 4.1.1, an IP system can determine the status of a 335 link and distinguish between the above two cases through the reception 336 of IPv4 Multicast Router Advertisement and Neighbor Discovery / ICMPv6 337 messages. 339 5. Requesting and Receiving Notifications 341 Like IGMP, MSNIP is an asymmetric protocol specifying different 342 behaviour for systems wishing to source traffic and for multicast 343 routers. Host IP systems multicast Host Interest Solicitation messages 344 to register for notification with their first-hop routers. Routers 345 unicast Router Receiver Membership Reports to IP systems to notify them 346 of the arrival of the first or departure of the last receiver for a 347 session. Note that a system may perform at the same time both of the 348 above functions. An example is a router that wishes to source traffic. 350 5.1. Host Interest Solicitation 352 Source systems that wish to be managed by MSNIP periodically 353 transmit an Interest Solicitation message. This message is multicast 354 with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) 355 or ALL_MLDv2_ROUTERS (TBA) and is transmitted every [Interest 356 Solicitation Interval] seconds. The Interest Solicitation message 357 contains a holdtime which is set to [Interest Solicitation Holdtime] and 358 instructs the multicast first-hop routers to maintain MSNIP state for 359 this IP system for the specified period. A generation ID is also 360 included in the Interest Solicitation message to provide support for 361 routers to detect IP system restarts (see section 8.1). Systems with 362 multiple interfaces or multiple IP addresses per interface must 363 originate separate Host Interest Solicitation messages from each of 364 their IP addresses that they wish to have managed by MSNIP. In practice 365 a system with more than one IP address is treated by MSNIP as multiple 366 IP systems. 368 When an IP system first comes up it transmits [Robustness Variable] 369 Interest Solicitation messages spaced by [Initial Interest Solicitation 370 Interval] seconds. 372 All MSNIP capable routers that receive an Interest Solicitation 373 message from an IP system, maintain a system interest record of the 374 form: 376 (IP system address, holdtime timer) 378 Each time an Interest Solicitation message is received from the IP 379 system, the holdtime timer is reset to the holdtime in the received 380 message. In addition the router may respond to the solicitation message 381 with a Receiver Membership Report message described in section 5.2. The 382 message contains a TRANSMIT record for each of the multicast destination 383 addresses within the MSNIP-managed range for which the routing protocol 384 indicates there are receivers for this source system. 386 The holdtime timer of a record counts down to zero. When the 387 holdtime timer of a specific system interest record expires, the record 388 is deleted. 390 5.2. Router Receiver Membership Reports 392 Receiver Membership Report messages are used by routers to 393 communicate the receiver membership status of particular multicast 394 destination addresses to a specific IP system. Each message contains a 395 list of transmission control records of either TRANSMIT or HOLD type 396 that instruct a system to respectively start or stop sending traffic on 397 this link to the specified multicast destination address. Receiver 398 Membership Report messages are unicast to the target system. 400 In addition to reports sent in response to Interest Solicitation 401 messages, routers send unsolicited Receiver Membership Reports to IP 402 systems when the receiver membership status reported by the multicast 403 routing protocol changes for a specific source and multicast 404 destination. Such reports are only sent if the multicast destination 405 address is managed by MSNIP and the router has a system interest record 406 created by a previously received Interest Solicitation message with an 407 IP system address equal to the source address. If the source / 408 destination pair satisfy these conditions then [Robustness Variable] 409 Receiver Membership Reports are sent out spaced by [Unsolicited 410 Membership Report Interval] seconds. If the membership status changes 411 again for the same destination address and source system while 412 transmission of Receiver Membership Reports is still pending then the 413 pending report messages are canceled and a new set of [Robustness 414 Variable] messages indicating the new state are scheduled. 416 When an IP system receives a Receiver Membership Report message, 417 for each of the TRANSMIT records listed in the message, it creates or 418 updates a transmission record of the form: 420 (router address, source address, multicast address, holdtime timer) 422 The router address is obtained from the source address on the IP header 423 of the received message. The source address is obtained from the 424 destination address of the IP header of the received message. The 425 multicast address is obtained from the information in the TRANSMIT 426 record. The holdtime timer is set to the value of the holdtime field in 427 the received Receiver Membership Report message. 429 For each HOLD record present in the message, the system deletes the 430 matching previously created transmission record from its state. 432 The holdtime timer of a record counts down to zero. When the 433 holdtime timer of a specific transmission record expires, the record is 434 deleted. 436 Note that creation and deletion of transmission records in an IP 437 system's state may cause local applications to be notified to start and 438 stop transmitting data (see section 6). 440 6. Application Notification 442 This section describes the relation between protocol events and 443 notifications to source applications within an IP system. The state 444 machine below is specific to each source address of the IP system and 445 each multicast destination address. The initial state is the No Info 446 state. 448 +-----------------------------------+ 449 | Figures omitted from text version | 450 +-----------------------------------+ 452 Figure 1: Per source-address (S) and multicast destination address (G) 453 state machine at an IP system 455 In tabular form, the state-machine is: 457 +-----------+-----------------------------------------------------------+ 458 | | Event | 459 | +----------+-----------+------------+-----------+-----------+ 460 |Prev State |New |Start |Stop |Recv |Recv last | 461 | |Register |Manage |Manage |TRANSMIT |HOLD or | 462 | | | | | |timeout | 463 +-----------+----------+-----------+------------+-----------+-----------+ 464 | |Start new |-> Hold |- |- |- | 465 |No Info | |Stop ALL | | | | 466 | | |registered | | | | 467 +-----------+----------+-----------+------------+-----------+-----------+ 468 | |- |- |-> No Info |-> |- | 469 |Hold | | | |Transmit | | 470 | | | |Stop ALL |Start ALL | | 471 | | | |registered |registered | | 472 +-----------+----------+-----------+------------+-----------+-----------+ 473 | |Start new |- |-> No Info |- |-> Hold | 474 |Transmit | | | | |Stop ALL | 475 | | | | | |registered | 476 +-----------+----------+-----------+------------+-----------+-----------+ 478 The events in state machine above have the following meaning: 480 New register 481 A new application has registered through a call to 482 IPMulticastSourceRegister for this S and G. 484 Start manage 485 We received a SSM Range option in an MRD packet on the interface 486 that S belongs to that changed the status of G from a non-managed 487 to a MSNIP-managed destination address. The SSM Range option is 488 only valid in IPv4. 490 Stop manage 491 We received a SSM Range option in an MRD packet on the interface 492 that S belongs to that changed the status of G from a MSNIP-managed 493 to a non-managed destination address or the mapping state that 494 caused this destination address to be managed expired. The SSM 495 Range option is only valid in IPv4. 497 Receive TRANSMIT 498 We received a Receiver Membership Report with S as the IP 499 destination address that contains a TRANSMIT record for G. 501 Receive last HOLD or timeout 502 We either received a Receiver Membership Report with S as the IP 503 destination address that contains a HOLD record for G or the 504 holdtime timer in a transmission record for S and G expired and 505 there are no other transmission records for S and G. This means 506 that the last router that was reporting receivers no longer does so 507 and there are no routers left wishing to receive traffic from this 508 S to destination address G. 510 The state machine actions have the following meaning: 512 Start new 513 Send an IPMulticastSourceStart notification to the application that 514 just registered for this S and G. 516 Start ALL registered 517 Send an IPMulticastSourceStart notification to all applications 518 that are registered for this S and G. 520 Stop ALL registered 521 Send an IPMulticastSourceStop notification to all applications that 522 are registered for this S and G. 524 7. Router Processing 526 This section describes the per-source system tracking state machine 527 operated by each first-hop router. The initial state is No Info. 529 +-----------------------------------+ 530 | Figures omitted from text version | 531 +-----------------------------------+ 533 Figure 2: Per IP source system (S) state machine at a router 535 In tabular form, the state-machine is: 537 +------------+----------------------------------------------------------+ 538 | | Event | 539 | +------------+-----------+--------------+------------------+ 540 |Prev State | Receive | HIS | Receivers | Receivers | 541 | | HIS | timeout | for new | of G leave | 542 | | | | destination | | 543 | | | | G | | 544 +------------+------------+-----------+--------------+------------------+ 545 | | -> | - | - | - | 546 | | Tracking | | | | 547 | | Set HT to | | | | 548 |Not | message | | | | 549 |tracking | holdtime | | | | 550 | | Send ALL | | | | 551 | | existing | | | | 552 | | TRANSMITs | | | | 553 +------------+------------+-----------+--------------+------------------+ 554 | | Set HT to | -> Not | Send | Send HOLD | 555 | | message | tracking | TRANSMIT | for G | 556 |Tracking | holdtime | | for G | | 557 | | Send ALL | | | | 558 | | existing | | | | 559 | | TRANSMITs | | | | 560 +------------+------------+-----------+--------------+------------------+ 562 The events in state machine above have the following meaning: 564 Receive HIS 565 The router has received a Host Interest Solicitation from S. 567 HIS timeout 568 The holdtime timer (HT) in the host interest record associated with 569 S has expired. 571 Receivers for new destination G 572 The routing protocol has informed MSNIP that it now has receivers 573 for the MSNIP-managed destination address G and source IP system S. 575 Receivers of G leave 576 The routing protocol has informed MSNIP that all receivers for the 577 MSNIP-managed destination address G and source IP system S have 578 left the channel. 580 The state machine actions have the following meaning: 582 Set HT to message holdtime 583 The holdtime timer in the host interest record associated with S is 584 restarted to the value of the holdtime field in the received Host 585 Interest Solicitation message. 587 Send ALL existing TRANSMITs 588 The router builds and transmits Receiver Membership Reports to S 589 that contain a TRANSMIT record for each of the MSNIP-managed 590 destination addresses that have receivers for S. 592 Send TRANSMIT for G 593 The router builds and transmits a Receiver Membership Report to S 594 that contains a TRANSMIT record for the destination address G. 596 Send HOLD for G 597 The router builds and transmits a Receiver Membership Report to S 598 that contains a HOLD record for the destination address G. 600 8. Message Formats 602 The following packet formats are valid for both IPv4 and IPv6. IP 603 version-specific values will be explicitly defined. 605 There are two message types of concern to the MSNIP protocol 606 described in this document: 608 +-------------------+----------------------------+ 609 | Type Number (hex) | Message Name | 610 +-------------------+----------------------------+ 611 | 0xXX | Host Interest Solicitation | 612 +-------------------+----------------------------+ 613 | 0xYY | Receiver Membership Report | 614 +-------------------+----------------------------+ 615 8.1. Host Interest Solicitation Packet 617 A Interest Solicitation packet is periodically multicast by MSNIP 618 capable systems to declare interest in Receiver Membership Reports from 619 multicast routers on the link. The Interest Solicitation message is 620 multicast with a destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) 621 or ALL_MLDv2_ROUTERS (TBA). 623 0 1 2 3 624 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Type | Reserved | Checksum | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Holdtime | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Type The type field is set to XX (to be assigned by IANA as an IGMP type 632 for IPv4 and an ICMPv6 type for IPv6). 634 Reserved 635 Transmitted as zero. Ignored upon receipt. 637 Checksum 638 In IPv4, the Checksum is the 16-bit one's complement of the one's 639 complement sum of the whole IGMP message (the entire IP payload). 640 In IPv6, the Checksum is the standard ICMPv6 checksum, covering the 641 entire MLDv2 message plus a "pseudo-header" of IPv6 header fields 642 [5]. For computing the checksum, the Checksum field is set to zero. 643 When receiving packets, the checksum MUST be verified before 644 processing a packet. 646 Holdtime 647 The amount of time a receiving router must keep the system interest 648 state alive, in seconds. The default value for this field is 649 [Interest Solicitation Holdtime]. 651 8.2. Receiver Membership Report Packet 653 A Receiver Membership Report packet is unicast by first-hop multicast 654 routers and targeted at potential sources to inform them of the 655 existence or not of receivers for the listed multicast destination 656 addresses. 658 0 1 2 3 659 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Type | Dest Count | Checksum | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Holdtime | Reserved | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Record-Type-1 | Record-Reserved-1 | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Destination-Address-1 | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | . | 670 | . | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Type The type field is set to YY (to be assigned by IANA as an IGMP type 674 for IPv4 and an ICMPv6 type for IPv6). 676 Dest Count 677 The number of multicast destination address records present in this 678 message. 680 Checksum 681 In IPv4, the Checksum is the 16-bit one's complement of the one's 682 complement sum of the whole IGMP message (the entire IP payload). 683 In IPv6, the Checksum is the standard ICMPv6 checksum, covering the 684 entire MLDv2 message plus a "pseudo-header" of IPv6 header fields 685 [5]. For computing the checksum, the Checksum field is set to zero. 686 When receiving packets, the checksum MUST be verified before 687 processing a packet. 689 Holdtime 690 The amount of time in seconds that the target host must keep alive 691 the transmission record state created or updated by the TRANSMIT 692 records in this report. The router originating the Receiver 693 Membership Report sets this field to the current value of the 694 holdtime timer in the system interest record corresponding to the 695 target host. As a result Receiver Membership Reports sent in 696 response to the reception of a Host Interest Solicitation message 697 have their holdtime set to the value of the holdtime field in the 698 received HIS message. 700 Reserved 701 Transmitted as zero. Ignored upon receipt. 703 Record-Type-1 704 The type of the first transmission control record in this message. 705 Valid values are: 707 +-------------+----------------------------------------------+-------+ 708 | Record Type | Description | Value | 709 +-------------+----------------------------------------------+-------+ 710 | TRANSMIT | Request to start transmitting to destination | 1 | 711 +-------------+----------------------------------------------+-------+ 712 | HOLD | Request to stop transmitting to destination | 2 | 713 +-------------+----------------------------------------------+-------+ 715 Reserved 716 Transmitted as zero. Ignored upon receipt. 718 Destination-Address-1 719 The multicast destination address of the first record in the 720 message. 722 8.3. IPv4 Header Fields 724 Like all IGMP messages, MSNIP messages are encapsulated in IPv4 725 datagrams, with an IP protocol number of 2. MSNIP messages can be 726 identified from other IGMP messages by the message types listed in 727 section 8. Every MSNIP message described in this document is sent with 728 an IP Time-to-Live of 1, and carries an IP Router Alert option [9] in 729 its IP header. 731 8.4. IPv6 Header Fields 733 MLD messages are a sub-protocol of the Internet Control Message 734 Protocol (ICMPv6 [5]). MSNIP messages are identified in IPv6 packets by 735 the combination of a preceding Next Header value of 58 and by the MLD 736 message types listed in section 8. All MSNIP messages described in this 737 document are sent with a link-local IPv6 Source Address (or the 738 unspecified address, if a valid link-local address is not available), an 739 IPv6 Hop Limit of 1, and an IPv6 Router Alert option [10] in a Hop-by- 740 hop Options header. 742 9. Constants Timers and Default Values 744 Robustness Variable 745 The Robustness Variable allows tuning for the expected packet loss 746 on a network. If a network is expected to be lossy, the Robustness 747 Variable may be increased. MSNIP is robust to (Robustness Variable 748 - 1) packet losses. The Robustness Variable MUST NOT be zero, and 749 SHOULD NOT be one. Default: 2 751 Interest Solicitation Interval 752 The interval used by MSNIP capable systems between transmissions of 753 Interest Solicitation messages. Default: 60 secs 755 Interest Solicitation Holdtime 756 The interval inserted in Interest Solicitation messages by systems 757 to instruct routers how long they should maintain system interest 758 state for. This MUST be ((the Robustness Variable) times (the 759 Interest Solicitation Interval) plus (one second)). 761 Initial Interest Solicitation Interval 762 The interval used by systems to send out the initial Interest 763 Solicitation messages when they first come up. Default: 1 second. 765 Unsolicited Membership Report Interval 766 The interval used by routers to send out a set of Membership Report 767 messages when the receiver membership changes for a specific 768 system. Default: 1 second. 770 10. Possible Optimisations 772 10.1. Suppressing HIS Messages 774 A possible optimisation for MSNIP is to suppress the transmission 775 of Host Interest Solicitation messages from the source address of an IP 776 system for which no local application has registered interest. In 777 addition to conserving bandwidth, not transmitting HIS messages prevents 778 remote receivers for groups with no matching source application from 779 creating transmission record state in the host system. 781 10.2. Host Stack Filtering 783 Legacy applications that have not been coded with MSNIP support can 784 still be prevented from wasting first-hop link bandwidth by filtering 785 transmitted packets at the operating system level. Even though such 786 applications will not register for MSNIP notifications with the host 787 operating system, if the OS is MSNIP-capable and the application is 788 transmitting data to an MSNIP-managed group for which there are no 789 transmit records, the OS can safely filter the packets and not transmit 790 them on the wire. 792 A problem with the filtering approach is that it cannot be combined 793 with the HIS message suppression optimisation (see section 10.1). If 794 there are no registered applications in the system and HIS messages are 795 being suppressed then the first-hop routers will not send any Receiver 796 Membership Reports to the system. As a result, knowledge of receiver 797 membership from the presence of transmit records for groups operated by 798 legacy applications will not exist. It therefore becomes unsafe to 799 filter packets from legacy applications. 801 10.3. Responding to Unexpected IGMP Queries 803 Under steady state the router side of the IGMP protocol elects a 804 single router on each link that is responsible for issuing IGMP Queries. 805 Routers other than the acting IGMP querier will send an IGMP Query only 806 if they restart and have no IGMP querier election state or if the active 807 Querier crashes and a new election takes place. 809 MSNIP can take advantage of this mechanism to quickly populate the 810 host interest records of a new router starting up. When the router comes 811 up it will issue an IGMP Query in an attempt to be elected as a Querier. 812 MSNIP-capable hosts will notice that the sender of the Query is not the 813 acting Querier. They can use this trigger to respond with Host Interest 814 Solicitation Messages (with transmission randomised over a small 815 interval) to quickly bring the new router up-to-date. 817 10.4. Host and Router Startup 819 When a host operating system is restarted there may be applications 820 that are started as part of the initialisation process and want to 821 source IPv4 multicast traffic. It is possible for the applications to 822 register through MSNIP with the IP subsystem and to start transmitting 823 multicast data before the host receives the MSNIP-managed range 824 definition through the SSM Range option of the Multicast Router 825 Discovery protocol. 827 This temporary flooding can be avoided if the host OS holds off 828 notifying MSNIP-capable applications that they can transmit until it 829 receives an MRD advertisement and learns the SSM configuration for the 830 network. This behaviour has the drawback that it is not compatible with 831 legacy networks with no MRD deployment. In such a network the host OS 832 has to be able to determine after a configurable period that MRD is not 833 enabled and hence all multicast applications wishing to source traffic 834 should be notified to transmit. A good default value for this period is 835 the MAX_RESPONSE_DELAY of the Multicast Router Discovery protocol [4]. 837 Late router startup is harder to deal with. Hosts that start up 838 before the multicast router may time out waiting for an MRD 839 advertisement and instruct all MSNIP-capable multicast source 840 applications to transmit data. One way to work around this problem is to 841 configure the host OS to wait forever for an MRD advertisement before 842 instructing MSNIP applications to transmit. 844 11. Inter-operation with IGMP / MLD Proxying 846 MSNIP is intended for use on networks with multicast servers 847 offering a large number of potential sessions. Although unlikely, it is 848 possible to deploy such a server behind an IGMP / MLD Proxy [14]. If the 849 proxy is not MSNIP-aware and does not implement the extensions described 850 below then sources behind the proxy will default to flooding. 852 If a device performing IGMP / MLD Proxying wishes to proxy MSNIP, 853 it MUST forward MSNIP Host Interest Solicitation messages that are 854 received on downstream interfaces to its upstream interface. No special 855 treatment is required for MSNIP Receiver Membership Reports as they are 856 unicast to the target host. 858 In addition to the forwarding of MSNIP messages, an IGMP proxy MUST 859 operate the Multicast Router Discovery protocol [3] on all its 860 downstream interfaces and advertise the MSNIP capability option (section 861 4.1.1) and SSM address range option (section 4.1.2). The MSNIP 862 capability option should be advertised on downstream interfaces only if 863 it is included in MRD messages received on the upstream interface. The 864 address range to be included in the SSM Range option MUST be determined 865 by MRD and IGMP messages received on the upstream interface of the proxy 866 according to the rules in section 4.2. 868 In addition to the forwarding of MSNIP messages, an MLD proxy MUST 869 operate the IPv6 Neighbor Discovery protocol. The MSNIP capability 870 option should be advertised on downstream interfaces when it is included 871 in IPv6 Neighbor Discovery messages received on the upstream interface. 873 12. Security Considerations 875 We consider the ramifications of a forged message of each type. As 876 described in [1] and [2], IPSEC AH can be used to authenticate IGMP and 877 MLD messages if desired. 879 12.1. Receiver Membership Report attacks 881 A DoS attack on a host could be staged through forged Receiver 882 Membership Report messages. The attacker can send a large number of 883 reports, each with a large number of TRANSMIT records and a holdtime 884 field set to a large value. The host will have to store and maintain the 885 transmission records specified in all of those reports for the duration 886 of the holdtime. This would consume both memory and CPU cycles in the 887 host. 889 Forged Receiver Membership Report messages from the local network 890 can be easily traced. There are three measures necessary to defend 891 against externally forged reports: 893 o Routers SHOULD NOT forward Receiver Membership Reports. This is easier 894 for a router to accomplish if the report carries the Router-Alert 895 option. 897 o Hosts SHOULD ignore Receiver Membership Reports without the Router- 898 Alert option. 900 Note that a remote attack through the multicast routing protocol is 901 possible. A remote site can originate join state for a large number of 902 groups that will propagate through MSNIP to the target source host. 903 Such attacks are considered a more significant problem for the routers 904 involved and are left up to the routing protocol security. 906 HOLD records in forged Receiver Membership Report messages are not 907 a significant threat as hosts track the individual interests of each 908 first-hop router separately. Only by forging the source address of the 909 report message so that is appears to have originated from a real first- 910 hop router can the attacker cause the source to stop transmitting to a 911 group that has valid receivers. Such forged messages can be detected by 912 the router itself. 914 12.2. Host Interest Solicitation attacks 916 Forged Host Interest Solicitation messages can have two effects: 918 o When non-existent source addresses are used the solicitation messages 919 can create unwanted host record state on attached routers for the 920 duration of the holdtime specified in the message. 922 o When a source address corresponding to an existing host is used in the 923 forged HIS message, receipt of the message by attached routers will 924 cause them to transmit Receiver Membership Reports messages for all 925 MSNIP-managed multicast destination addresses with receivers for the 926 target host. Although no additional state will be created in routers 927 or hosts from this attack, bandwidth and CPU is wasted in both the 928 first-hop routers and the target host. 930 Just like for the Receiver Membership Report message, attacks using 931 the Host Interest Solicitation message can be reduced by requiring the 932 use of the Router-Alert option on the message. 934 12.3. MSNIP Managed Range Discovery 936 As discussed in [4] it is possible for directly connected systems 937 to send forged Multicast Router Advertisement messages containing the 938 SSM Range Discovery option. As the SSM Range Discovery option determines 939 the MSNIP-managed range under IPv4, such forged messages can temporarily 940 replace the managed range map with incorrect information in receiving 941 hosts. An incorrect mapping can have two effects: 943 o Applications using a multicast destination address within the real SSM 944 range that have no valid receivers can be tricked into thinking that 945 their chosen destination address is no longer an SSM address and will 946 therefore start transmitting data. 948 o Applications using group addresses outside the valid SSM range can be 949 tricked into thinking that they are using an SSM destination address 950 and therefore prevented from transmitting data. 952 The Multicast Router Discovery SSM Range Option specification 953 suggests that a router receiving a Multicast Router Advertisement with 954 an inconsistent SSM Range Option log the event to the operator. Such 955 logging will enable tracking of this type of attack. 957 13. IANA Considerations 959 This document introduces the following new types and options that 960 require allocation by IANA: 962 o Two new IGMP messages for Host Interest Solicitation and Receiver 963 Membership Report. Each of these messages requires a new IGMP type 964 value to be assigned by IANA [13]. 966 o The new MSNIP Operation option for the Multicast Router Discovery 967 protocol. This option requires a new MRD type value to be assigned by 968 IANA. 970 o The new MSNIP Operation option for the Neighbour Discovery / ICMPv6 971 protocol. This option requires a new NDP / ICMPv6 type value to be 972 assigned by IANA. 974 14. Acknowledgments 976 The authors would like to thank Dave Thaler, Jon Crowcroft, Toerless 977 Eckert, Haixiang He, Pekka Savola and Karen Kimball for their 978 contribution to this specification. 980 15. Normative References 982 [1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet 983 Group Management Protocol, Version 3", RFC 3376. 985 [2] R. Vida, et al, "Multicast Listener Discovery Version 2 (MLDv2) for 986 IPv6", work in progress, , November 2002. 988 [3] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In 989 Progress, , January 2003. 991 [4] I. Kouvelas, "Multicast Router Discovery SSM Range Option", work in 992 progress, , February 2003. 994 [5] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) 995 for the Internet Protocol Version 6 (IPv6)", RFC 2463. 997 [6] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP 998 Version 6 (IPv6)", RFC 2461. 1000 [7] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in 1001 progress, , March 2003. 1003 [8] S. Kent, R. Atkinson, "Security Architecture for the Internet 1004 Protocol.", RFC 2401. 1006 [9] D. Katz, "IP Router Alert Option", RFC 2113. 1008 [10] C. Partridge, A. Jackson, "IPv6 Router Alert Option", RFC 2711. 1010 16. Informative References 1012 [11] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 1013 Independent Multicast - Sparse Mode (PIM-SM): Protocol 1014 Specification (Revised)", Work In Progress, , March 2003. 1017 [12] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4 1018 Multicast Address Allocation", Best Current Practices, , 2001. 1021 [13] W. Fenner, "IANA Considerations for IGMP", 1022 http://www.iana.org/assignments/igmp-type-numbers, RFC 3228 (BCP 1023 57), February 2002. 1025 [14] W. Fenner, H. He, B. Haberman, H. Sandick, "IGMP / MLD-based 1026 Multicast Forwarding (IGMP / MLD Proxying)" draft-ietf-magma-igmp- 1027 proxy-02.txt, March 2003. 1029 Authors' Addresses 1031 Bill Fenner 1032 AT&T Labs - Research 1033 75 Willow Road 1034 Menlo Park, CA 94025 1035 fenner@research.att.com 1037 Brian Haberman 1038 Caspian Networks 1039 One Park Drive, Suite 300 1040 Research Triangle Park, NC 27709 1041 bkhabs@nc.rr.com 1043 Hugh Holbrook 1044 Cisco Systems 1045 170 W. Tasman Drive 1046 San Jose, CA 95134 1047 holbrook@cisco.com 1049 Isidor Kouvelas 1050 Cisco Systems 1051 170 W. Tasman Drive 1052 San Jose, CA 95134 1053 kouvelas@cisco.com 1055 Full Copyright Statement 1057 Copyright (C) The Internet Society (Apr 1 2003). All Rights Reserved. 1059 This document and translations of it may be copied and furnished to 1060 others, and derivative works that comment on or otherwise explain it or 1061 assist in its implementation may be prepared, copied, published and 1062 distributed, in whole or in part, without restriction of any kind, 1063 provided that the above copyright notice and this paragraph are included 1064 on all such copies and derivative works. However, this document itself 1065 may not be modified in any way, such as by removing the copyright notice 1066 or references to the Internet Society or other Internet organizations, 1067 except as needed for the purpose of developing Internet standards in 1068 which case the procedures for copyrights defined in the Internet 1069 Standards process must be followed, or as required to translate it into 1070 languages other than English. 1072 The limited permissions granted above are perpetual and will not be 1073 revoked by the Internet Society or its successors or assigns. 1075 This document and the information contained herein is provided on 1076 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1077 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1078 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1079 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1080 FITNESS FOR A PARTICULAR PURPOSE.