idnits 2.17.00 (12 Aug 2021) /tmp/idnits9972/draft-ietf-magma-msnip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 54 instances of too long lines in the document, the longest one being 4 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 255: '...Pv6. This option MUST be included in a...' RFC 2119 keyword, line 272: '... MSNIP, a miss-configuration SHOULD be...' RFC 2119 keyword, line 276: '...ers on that link MUST be configured to...' RFC 2119 keyword, line 644: '...packets, the checksum MUST be verified...' RFC 2119 keyword, line 695: '...packets, the checksum MUST be verified...' (5 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 November 2002) is 7140 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) -- Looks like a reference, but probably isn't: 'RFC-2113' on line 736 == Unused Reference: '2' is defined on line 987, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1014, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2463 (ref. '9') (Obsoleted by RFC 4443) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 Bill Fenner/AT&T 3 draft-ietf-magma-msnip-01.txt Brian Haberman/Caspian Networks 4 Hugh Holbrook/Cisco 5 Isidor Kouvelas/Cisco 6 2 November 2002 7 Expires: May 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. 41 Table of Contents 43 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 44 2. Routing Protocol Support. . . . . . . . . . . . . . . . 3 45 3. Service Interface for Requesting Membership Noti- 46 fication . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 3.1. Application Operation. . . . . . . . . . . . . . . . 5 48 4. MSNIP Managed Address Range Negotiation . . . . . . . . 6 49 4.1. Router Coordination. . . . . . . . . . . . . . . . . 6 50 4.1.1. MSNIP Operation Option. . . . . . . . . . . . . . 6 51 4.1.2. SSM Range Option. . . . . . . . . . . . . . . . . 7 52 4.2. Communicating Range to Source Systems. . . . . . . . 7 53 5. Requesting and Receiving Notifications. . . . . . . . . 8 54 5.1. Host Interest Solicitation . . . . . . . . . . . . . 9 55 5.2. Router Receiver Membership Reports . . . . . . . . . 10 56 6. Application Notification. . . . . . . . . . . . . . . . 11 57 7. Router Processing . . . . . . . . . . . . . . . . . . . 13 58 8. Message Formats . . . . . . . . . . . . . . . . . . . . 14 59 8.1. Host Interest Solicitation Packet. . . . . . . . . . 15 60 8.2. Receiver Membership Report Packet. . . . . . . . . . 16 61 8.3. IPv4 Header Fields . . . . . . . . . . . . . . . . . 18 62 8.4. IPv6 Header Fields . . . . . . . . . . . . . . . . . 18 63 9. Constants Timers and Default Values . . . . . . . . . . 18 64 10. Possible Optimisations . . . . . . . . . . . . . . . . 19 65 10.1. Suppressing HIS Messages. . . . . . . . . . . . . . 19 66 10.2. Host Stack Filtering. . . . . . . . . . . . . . . . 19 67 10.3. Responding to Unexpected IGMP Queries . . . . . . . 19 68 10.4. Host and Router Startup . . . . . . . . . . . . . . 20 69 11. Security Considerations. . . . . . . . . . . . . . . . 20 70 11.1. Receiver Membership Report attacks. . . . . . . . . 21 71 11.2. Host Interest Solicitation attacks. . . . . . . . . 21 72 11.3. MSNIP Managed Range Discovery . . . . . . . . . . . 22 73 12. IANA Considerations. . . . . . . . . . . . . . . . . . 23 74 13. Acknowledgments. . . . . . . . . . . . . . . . . . . . 23 75 14. Authors' Addresses . . . . . . . . . . . . . . . . . . 23 76 15. References . . . . . . . . . . . . . . . . . . . . . . 24 78 1. Introduction 80 The Multicast Source Notification of Interest Protocol (MSNIP) is 81 an extension to version 3 of the Internet Group Membership Protocol 82 (IGMPv3 [1] ) and version 2 of the Multicast Listener Discovery Protocol 83 (MLDv2 [8] ). MSNIP operates between multicast sources and their first- 84 hop routers to provide information on the presence of receivers to the 85 source systems. Using the services offered by MSNIP an application on an 86 IP system wishing to source multicast data can register to be notified 87 when receivers join and leave the session. This enables multicast 88 sources to avoid the work of transmitting packets onto their first-hop 89 link when there are no joined receivers. 91 A common scenario where MSNIP may be useful is one where there is a 92 multicast server offering a large pool of potential flows that map onto 93 separate multicast destination addresses but receivers exist only for a 94 small subset of the flows. If the source were to continuously transmit 95 data for all the flows that could potentially have receivers, 96 significant resources would be wasted in the system itself as well as 97 the first-hop link. Using a higher level control protocol to determine 98 the existence of receivers for particular flows may not be practical as 99 there may be many potential receivers in each active session. 101 Information on which multicast destination addresses have receivers 102 for a particular sender is typically available to the multicast routing 103 protocol on the first hop router for a source. MSNIP uses this 104 information to notify the application in the sending system of when it 105 should start or stop transmitting. This is achieved without any 106 destination address specific state on the first-hop router for potential 107 sources without receivers. 109 2. Routing Protocol Support 111 For reasons described in this section, MSNIP only supports 112 transmission control for applications that use multicast destination 113 addresses that are routed using Source Specific Multicast (SSM). 115 Many currently deployed multicast routing protocols, require data 116 from an active source to be propagated past the first-hop router before 117 information on the existence of receivers becomes available on the 118 first-hop. In addition, such protocols require that this activity is 119 repeated periodically to maintain source liveness state on remote 120 routers. All dense-mode protocols fall under this category as well as 121 sparse-mode protocols that use shared trees for source discovery (such 122 as PIM-SM [3] ). In order to provide receiver interest notification for 123 such protocols, the default mode of operation would require that the 124 source IP system periodically transmits on all potential destination 125 addresses and the first-hop routers prune the traffic back. Such a 126 flood-and-prune behaviour on the first-hop link significantly diminishes 127 the benefits of managing source transmission. 129 In contrast, with source-specific sparse-mode protocols such as 130 PIM-SSM [3] availability of receiver membership information on the 131 first-hop routers is independent of data transmission. Such protocols 132 use an external mechanism for source discovery (like source-specific 133 IGMPv3 membership reports) to build source-specific multicast trees. 135 Clearly these two classes of routing protocols require different 136 handling for the problem MSNIP is trying to solve. In addition the 137 second type covers the majority of applications that MSNIP is targeted 138 at. MSNIP avoids the extra complication in supporting routing protocols 139 that require a flood and prune behaviour. 141 3. Service Interface for Requesting Membership Notification 143 Applications within an IP system that wish to source multicast 144 packets and are interested in being notified on the existence of 145 receivers must register with the IP layer of the system. MSNIP requires 146 that within the IP system, there is (at least conceptually) a service 147 interface that can be used to register with the IP layer for such 148 notifications. Dual stack systems supporting both IPv4 and IPv6 need to 149 provide separate service interfaces for each protocol. 151 A system's IPv4 or IPv6 service interface must support the 152 following operation or any logical equivalent: 154 IPMulticastsSourceRegister (socket, source-address, multicast-address) 155 IPMulticastsSourceDeregister (socket, source-address, multicast-address) 157 In addition the application must provide the following interface 158 for receiving notifications from the IP system: 160 IPMulticastSourceStart (socket, source-address, multicast-address) 161 IPMulticastSourceStop (socket, source-address, multicast-address) 163 where: 165 socket 166 is an implementation-specific parameter used to distinguish amongst 167 different requesting entities (e.g., programs or processes) within 168 the system; the socket parameter of BSD Unix system calls is a 169 specific example. 171 source-address 172 is the IP unicast source address that the application wishes to use 173 in transmitting data to the specified multicast address. The 174 specified address must be one of the IP addresses associated with 175 the network interfaces of the IP system. Note that an interface in 176 an IP system may be associated with more than one IP addresses. An 177 implementation may allow a special "unspecified" value to be passed 178 as the source-address parameter, in which case the request would 179 apply to the "primary" IP address of the "primary" or "default" 180 interface of the system (perhaps established by system 181 configuration). If transmission to the same multicast address is 182 desired using more than one source IP address, 183 IPMulticastSourceRegister must be invoked separately for each 184 desired source address. 186 multicast-address 187 is the IP multicast destination address to which the request 188 pertains. If the application wishes to transmit data to more than 189 one multicast addresses for a given source address, 190 IPMulticastSourceRegister must be invoked separately for each 191 desired multicast address. 193 3.1. Application Operation 195 Applications wishing to use MSNIP to control their multicast data 196 transmission to destination G from source address S operate as follows. 198 Initially the application contacts the IP system to obtain the 199 socket handle for use on all subsequent interactions. The application 200 invokes IPMulticastSourceRegister for the desired S and G and then waits 201 without transmitting any packets for the IP system to notify that 202 receivers for the session exist. 204 If and when the IP system notifies the application that receivers 205 exist using the IPMulticastSourceStart call, the application may start 206 transmitting data. After the application has been notified to send, if 207 all receivers for the session leave, the IP system will notify the 208 application using the IPMulticastSourceStop call. At this point the 209 application should stop transmitting data until it is notified again 210 that receivers have joined through another IPMulticastSourceStart call. 212 When the application no longer wishes to transmit data it should 213 invoke the IPMulticastsSourceDeregister call to let the IP system know 214 that it is no longer interested in notifications for this source and 215 destination. The IPMulticastsSourceDeregister call should be implicit in 216 the teardown of the associated socket state. 218 4. MSNIP Managed Address Range Negotiation 220 With current multicast deployment in the Internet, different 221 multicast routing protocols coexist and operate under separate parts of 222 the multicast address space. Multicast routers are consistently 223 configured with information that maps specific multicast address ranges 224 to multicast routing protocols. Part of this configuration describes the 225 subset of the address space that is used by source-specific multicast 226 (SSM) [4]. As described in section 2 MSNIP only tries to control 227 application transmission within the SSM address range. 229 It is desirable for applications within an IP system that supports 230 MSNIP to have a consistent service interface for multicast transmission 231 that does require the application to be aware of the SSM address range. 232 MSNIP supports this by allowing applications to use the service 233 interface described in section 3 for multicast destination addresses 234 that are outside its operating range. When an application registers for 235 notifications for a destination address that is not managed by MSNIP it 236 is immediately notified to start transmitting. This is equivalent to the 237 default behaviour of IP multicast without MSNIP support which forces 238 multicast applications to assume that there are multicast receivers 239 present in the network. 241 4.1. Router Coordination 243 In order for MSNIP to operate on a shared link where more than one 244 multicast routers may be present all multicast routers must be MSNIP 245 capable and have a consistent configuration for the SSM address range. 246 MSNIP enforces these requirements by using two new options for IPv4 in 247 the Multicast Router Discovery protocol [5] and one new option for IPv6 248 in Neighbor Discovery / ICMPv6 protocol. 250 4.1.1. MSNIP Operation Option 252 A multicast router advertises that it is participating in MSNIP 253 using the MSNIP Operation option in either the Multicast Router 254 Discovery protocol for IPv4 and the Neighbor Discovery / ICMPv6 protocol 255 for IPv6. This option MUST be included in all router advertisement 256 messages of a router that is configured for MSNIP. The format of the 257 option is as follows: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type | Length=0 | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Type The type field is set to WW (TBD by IANA) in IPv4 and ZZ (TBA by 266 IANA) in IPv6. 268 A multicast router uses received Multicast Router Advertisement and 269 Neighbor Discovery / ICMPv6 messages to determine if all live neighbour 270 multicast routers on each interface are participating in MSNIP. When a 271 router advertisement message not containing an MSNIP option is received 272 by a router participating in MSNIP, a miss-configuration SHOULD be 273 logged to the operator in a rate-limited manner. 275 If even one multicast router on a link does not have MSNIP capability 276 then ALL routers on that link MUST be configured to not provide MSNIP 277 services and to not advertise the MSNIP Operation option. 279 4.1.2. SSM Range Option 281 The SSM Range Multicast Router Discover option advertises the SSM 282 Range with which the router is configured. The option is defined in [7]. 283 This option is only valid in IPv4. SSM support in IPv6 does not allow 284 for alternative SSM address ranges. 286 4.2. Communicating Range to Source Systems 288 When an application in an IP system uses the MSNIP service 289 interface to register for notification, the IP system must behave 290 differently depending on whether or not the destination address for 291 which the application registered is operating under SSM (and is being 292 managed by MSNIP). For SSM channels, the IP system should only instruct 293 the application to transmit when there are receivers for the multicast 294 destination. For non-SSM destination addresses the IP system will not be 295 able to determine if there are receivers and should immediately instruct 296 the application to transmit. 298 The MSNIP managed range discovery mechanism in a source IP system 299 has to deal with three different link configurations: 301 o A link connected to a multicast routed infrastructure where the first- 302 hop multicast routers are configured for MSNIP operation. 304 o A link connected to a multicast routed infrastructure where the first- 305 hop multicast routers are not participating in MSNIP. 307 o A link with no multicast routers. 309 To be able to differentiate between the three cases and in each 310 case discover the MSNIP managed range an MSNIP capable source IP system 311 must process IGMP Queries as well as Multicast Router Discovery 312 Advertisement messages. The presence of an IGMP querier differentiates 313 between the first two cases, where the host is in a multicast routed 314 network, and the third, where there is no multicast routing. 316 Multicast Router Discovery Advertisements provide the 317 differentiation between the first two cases. If the MRD Advertisements 318 contain the MSNIP Operation option then the IP system knows that routers 319 on that interface are configured for MSNIP operation. 321 In each of the three cases the MSNIP managed range is defined as 322 follows: 324 MSNIP capable multicast routers: 325 The IP system should use as the MSNIP range the SSM range provided 326 by the last SSM Range option [7] received in a Multicast Router 327 Discovery message. 329 Multicast routers not participating in MSNIP: 330 The IP system should use an empty MSNIP managed range. This 331 provides a compatibility mode where all group ranges default to 332 flooding. 334 Link without multicast routing: 335 The IP system should use as the MSNIP managed range the default SSM 336 range of 232/8 defined in [6]. This allows directly connected 337 receivers to perform the router side of the MSNIP protocol and 338 control the source transmission within the default SSM range. 340 5. Requesting and Receiving Notifications 342 Like IGMP, MSNIP is an asymmetric protocol specifying different 343 behaviour for systems wishing to source traffic and for multicast 344 routers. Host IP systems multicast Host Interest Solicitation messages 345 to register for notification with their first-hop routers. Routers 346 unicast Router Receiver Membership Reports to IP systems to notify them 347 of the arrival of the first or departure of the last receivers for a 348 session. Note that a system may perform at the same time both of the 349 above functions. An example is a router that wishes to source traffic. 351 5.1. Host Interest Solicitation 353 Source systems that wish to be managed by MSNIP periodically 354 transmit an Interest Solicitation message. This message is multicast 355 with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) 356 or ALL_MLDv2_ROUTERS (TBA) and is transmitted every [Interest 357 Solicitation Interval] seconds. The Interest Solicitation message 358 contains a holdtime which is set to [Interest Solicitation Holdtime] and 359 instructs the multicast first-hop routers to maintain MSNIP state for 360 this IP system for the specified period. A generation ID is also 361 included in the Interest Solicitation message to provide support for 362 routers to detect IP system restarts (see section 8.1). Systems with 363 multiple interfaces or multiple IP addresses per interface must 364 originate separate Host Interest Solicitation messages from each of 365 their IP addresses that they wish to have managed by MSNIP. In practice 366 a system with more than one IP address is treated by MSNIP as multiple 367 IP systems. 369 When an IP system first comes up it transmits [Robustness Variable] 370 Interest Solicitation messages spaced by [Initial Interest Solicitation 371 Interval] seconds. 373 All MSNIP capable routers that receive an Interest Solicitation 374 message from an IP system, maintain a system interest record of the 375 form: 377 (IP system address, holdtime timer) 379 Each time an Interest Solicitation message is received from the IP 380 system, the holdtime timer is reset to the holdtime in the received 381 message. In addition the router may respond to the solicitation message 382 with a Receiver Membership Report message described in section 5.2. The 383 message contains a TRANSMIT record for each of the multicast destination 384 addresses within the MSNIP managed range for which the routing protocol 385 indicates there are receivers for this source system. 387 The holdtime timer of a record counts down to zero. When the 388 holdtime timer of a specific system interest record expires, the record 389 is deleted. 391 5.2. Router Receiver Membership Reports 393 Receiver Membership Report messages are used by routers to 394 communicate the receiver membership status of particular multicast 395 destination addresses to a specific IP system. Each message contains a 396 list of transmission control records of either TRANSMIT or HOLD type 397 that instruct a system to respectively start or stop sending traffic on 398 this link to the specified multicast destination address. Receiver 399 Membership Report messages are unicast to the target system. 401 In addition to reports sent in response to Interest Solicitation 402 messages, routers send unsolicited Receiver Membership Reports to IP 403 systems when the receiver membership status reported by the multicast 404 routing protocol changes for a specific source and multicast 405 destination. Such reports are only sent if the destination address is 406 managed by MSNIP and the router has a system interest record created by 407 a previously received Interest Solicitation message with an IP system 408 address equal to the source address. If the source destination pair 409 satisfy these conditions then [Robustness Variable] Receiver Membership 410 Reports are sent out spaced by [Unsolicited Membership Report Interval] 411 seconds. If the membership status changes again for the same 412 destination address and source system while transmission of Receiver 413 Membership Reports is still pending then the pending report messages are 414 canceled and a new set of [Robustness Variable] messages indicating the 415 new state are scheduled. 417 When an IP system receives a Receiver Membership Report message, 418 for each of the TRANSMIT records listed in the message it creates or 419 updates a transmission record of the form: 421 (router address, source address, multicast address, holdtime timer) 423 The router address is obtained from the source address on the IP header 424 of the received message. The source address is obtained from the 425 destination address in the of the IP header. The holdtime timer is set 426 to the value of the holdtime field in the received Receiver Membership 427 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 systems 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 IPMulticastsSourceRegister 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 +-------------------+----------------------------+ 616 8.1. Host Interest Solicitation Packet 618 A Interest Solicitation packet is periodically multicast by MSNIP 619 capable systems to declare interest in Receiver Membership Reports from 620 multicast routers on the link. The Interest Solicitation message is 621 multicast with a destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) 622 or ALL_MLDv2_ROUTERS (TBA). 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Type | Reserved | Checksum | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Holdtime | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Type The type field is set to XX (to be assigned by IANA as an IGMP type 633 for IPv4 and an ICMPv6 type for IPv6). 635 Reserved 636 Transmitted as zero. Ignored upon receipt. 638 Checksum 639 In IPv4, the Checksum is the 16-bit one's complement of the one's 640 complement sum of the whole IGMP message (the entire IP payload). 641 In IPv6, the Checksum is the standard ICMPv6 checksum, covering the 642 entire MLDv2 message plus a "pseudo-header" of IPv6 header fields 643 .CITE ICMPv6 . For computing the checksum, the Checksum field is 644 set to zero. When receiving packets, the checksum MUST be verified 645 before processing a packet. 647 Holdtime 648 The amount of time a receiving router must keep the system interest 649 state alive, in seconds. The default value for this field is 650 [Interest Solicitation Holdtime]. 652 GenID 653 Generation ID of the IP system. A number that is selected randomly 654 for each of the [Robustness Variable] initial Interest Solicitation 655 messages when the system comes up and afterwards remains fixed to 656 the value used in the last of the initial messages throughout the 657 system lifetime. The GenID is used by routers to detect system 658 crashes. 660 8.2. Receiver Membership Report Packet 662 A Receiver Membership Report packet is unicast by first-hop multicast 663 routers and targeted at potential sources to inform them of the 664 existence or not of receivers for the listed multicast destination 665 addresses. 667 0 1 2 3 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Type | Dest Count | Checksum | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Holdtime | Reserved | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Record-Type-1 | Record-Reserved-1 | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Destination-Address-1 | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | . | 679 | . | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 Type The type field is set to YY (to be assigned by IANA as an IGMP type 683 for IPv4 and an ICMPv6 type for IPv6). 685 Dest Count 686 The number of multicast destination address records present in this 687 message. 689 Checksum 690 In IPv4, the Checksum is the 16-bit one's complement of the one's 691 complement sum of the whole IGMP message (the entire IP payload). 692 In IPv6, the Checksum is the standard ICMPv6 checksum, covering the 693 entire MLDv2 message plus a "pseudo-header" of IPv6 header fields 694 .CITE ICMPv6 . For computing the checksum, the Checksum field is 695 set to zero. When receiving packets, the checksum MUST be verified 696 before processing a packet. 698 Holdtime 699 The amount of time in seconds that the target host must keep alive 700 the transmission record state created or updated by the TRANSMIT 701 records in this report. The router originating the Receiver 702 Membership Report sets this field to the current value of the 703 holdtime timer in the system interest record corresponding to the 704 target host. As a result Receiver Membership Reports sent in 705 response to the reception of a Host Interest Solicitation message 706 have their holdtime set to the value of the holdtime field in the 707 received HIS message. 709 Reserved 710 Transmitted as zero. Ignored upon receipt. 712 Record-Type-1 713 The type of the first transmission control record in this message. 714 Valid values are: 716 +-------------+----------------------------------------------+-------+ 717 | Record Type | Description | Value | 718 +-------------+----------------------------------------------+-------+ 719 | TRANSMIT | Request to start transmitting to destination | 1 | 720 +-------------+----------------------------------------------+-------+ 721 | HOLD | Request to stop transmitting to destination | 2 | 722 +-------------+----------------------------------------------+-------+ 724 Reserved 725 Transmitted as zero. Ignored upon receipt. 727 Destination-Address-1 728 The multicast destination address of the first record in the 729 message. 731 8.3. IPv4 Header Fields 733 Like all other IGMP messages, MSNIP messages are encapsulated in 734 IPv4 datagrams, with an IP protocol number of 2. Every MSNIP message 735 described in this document is sent with an IP Time-to-Live of 1, and 736 carries an IP Router Alert option [RFC-2113] in its IP header. 738 8.4. IPv6 Header Fields 740 MLD messages are a sub-protocol of the Internet Control Message 741 Protocol (ICMPv6 [9] ). MSNIP messages are identified in IPv6 packets by 742 a preceding Next Header value of 58. All MSNIP messages described in 743 this document are 744 sent with a link-local IPv6 Source Address (or the unspecified address, 745 if a valid link-local address is not available), an IPv6 Hop Limit of 1, 746 and an IPv6 Router Alert option .CITE RAv6 in a Hop-by-hop Options 747 header. 749 9. Constants Timers and Default Values 751 Robustness Variable 752 The Robustness Variable allows tuning for the expected packet loss 753 on a network. If a network is expected to be lossy, the Robustness 754 Variable may be increased. MSNIP is robust to (Robustness Variable 755 - 1) packet losses. The Robustness Variable MUST NOT be zero, and 756 SHOULD NOT be one. Default: 2 758 Interest Solicitation Interval 759 The interval used by MSNIP capable systems between transmissions of 760 Interest Solicitation messages. Default: 60 secs 762 Interest Solicitation Holdtime 763 The interval inserted in Interest Solicitation messages by systems 764 to instruct routers how long they should maintain system interest 765 state for. This MUST be ((the Robustness Variable) times (the 766 Interest Solicitation Interval) plus (one second)). 768 Initial Interest Solicitation Interval 769 The interval used by systems to send out the initial Interest 770 Solicitation messages when they first come up. Default: 1 second. 772 Unsolicited Membership Report Interval 773 The interval used by routers to send out a set of Membership Report 774 messages when the receiver membership changes for a specific 775 system. Default: 1 second. 777 10. Possible Optimisations 779 10.1. Suppressing HIS Messages 781 A possible optimisation for MSNIP is to suppress the transmission 782 of Host Interest Solicitation messages from the source address of an IP 783 system for which no local application has registered interest. Apart 784 from the saving is wasted bandwidth, not transmitting HIS messages 785 prevents remote receivers for groups with no matching source application 786 from creating transmission record state in the host system. 788 10.2. Host Stack Filtering 790 Legacy applications that have not been coded with MSNIP support can 791 still be prevented from waisting first-hop link bandwidth by filtering 792 transmitted packets at the operating system level. Even though such 793 applications will not register for MSNIP notifications with the host 794 operating system, if the OS is MSNIP capable and the application is 795 transmitting data to an MSNIP managed group for which there are no 796 transmit records, the OS can safely filter the packets and not transmit 797 them on the wire. 799 A problem with the filtering approach is that it cannot be combined 800 with the HIS message suppression optimisation (see section 10.1). If 801 there is no registered applications in the system and HIS messages are 802 being suppressed then the first-hop routers will not send any Receiver 803 Membership Reports to the system. As a result knowledge of receiver 804 membership from the presence of transmit records for groups operated by 805 legacy applications will not exist. It therefore becomes unsafe to 806 filter packets from legacy applications. 808 10.3. Responding to Unexpected IGMP Queries 810 Under steady state the router side of the IGMP protocol elects a 811 single router on each link that is responsible for issuing IGMP Queries. 812 Routers other than the acting IGMP querier will send an IGMP Query only 813 if they restart and have no IGMP querier election state or if the active 814 Querier crashes and a new election takes place. 816 MSNIP can take advantage of this mechanism to quickly populate the 817 host interest records of a new router starting up. When the router comes 818 up it will issue an IGMP Query in an attempt to be elected as a Querier. 819 MSNIP capable hosts will notice that the sender of the Query is not the 820 acting Querier. They can use this trigger to respond with Host Interest 821 Solicitation Messages (with transmission randomised over a small 822 interval) to quickly bring the new router up-to-date. 824 10.4. Host and Router Startup 826 When a host operating system is restarted there may be applications 827 that are started as part of the initialisation process and want to 828 source IPv4 multicast traffic. It is possible for the applications to 829 register through MSNIP with the IP subsystem and to start transmitting 830 multicast data before the host receives the MSNIP managed range 831 definition through the SSM Range option of the Multicast Router 832 Discovery protocol. 834 This temporary flooding can be avoided if the host OS holds off 835 notifying MSNIP capable applications that they can transmit until it 836 receives an MRD advertisement and learns the SSM configuration for the 837 network. This behaviour has the drawback that it is not compatible with 838 legacy networks with no MRD deployment. In such a network the host OS 839 has to be able to determine after a configurable period that MRD is not 840 enabled and hence all multicast applications wishing to source traffic 841 should be notified to transmit. A good default value for this period is 842 the MAX_RESPONSE_DELAY of the Multicast Router Discovery protocol [7]. 844 Late router startup is harder to deal with. Hosts that start up 845 before the multicast router may time out waiting for an MRD 846 advertisement and instruct all MSNIP capable multicast source 847 applications to transmit data. One way to work around this problem is to 848 configure the host OS to wait forever for an MRD advertisement before 849 instructing MSNIP applications to transmit. 851 11. Security Considerations 853 We consider the ramifications of a forged message of each type. As 854 described in [1] IPSEC AH can be used to authenticate IGMP messages if 855 desired. 857 11.1. Receiver Membership Report attacks 859 A DoS attack on a host could be staged through forged Receiver 860 Membership Report messages. The attacker can send a large number of 861 reports, each with a large number of TRANSMIT records and a holdtime 862 field set to a large value. The host will have to store and maintain the 863 transmission records specified in all of those reports for the duration 864 of the holdtime. This would consume both memory and CPU cycles in the 865 host. 867 Forged Receiver Membership Report messages from the local network 868 can be easily traced. There are three measures necessary to defend 869 against externally forged reports: 871 o Routers SHOULD NOT forward Receiver Membership Reports. This is easier 872 for a router to accomplish if the report carries the Router-Alert 873 option. 875 o Hosts SHOULD ignore Receiver Membership Reports without the Router- 876 Alert option. 878 Note that a remote attack through the multicast routing protocol is 879 possible. A remote site can originate join state for a large number of 880 groups that will propagate through MSNIP to the target source host. 881 Such attacks are considered a more significant problem for the routers 882 involved and are left up to the routing protocol security. 884 HOLD records in forged Receiver Membership Report messages are not 885 a significant threat as hosts track the individual interests of each 886 first-hop router separately. Only by forging the source address of the 887 report message so that is appears to have originated from a real first- 888 hop router can the attacker cause the source to stop transmitting to a 889 group that has valid receivers. Such forged messages can be detected by 890 the router itself. 892 11.2. Host Interest Solicitation attacks 894 Forged Host Interest Solicitation messages can have two effects: 896 o When non-existent source addresses are used the solicitation messages 897 can create unwanted host record state on attached routers for the 898 duration of the holdtime specified in the message. 900 o When a source address corresponding to an existing host is used in the 901 forged HIS message, receipt of the message by attached routers will 902 cause them to transmit Receiver Membership Reports messages for any 903 multicast destination addresses with receivers for the target host. 904 Although no additional state will be created in routers or hosts from 905 this attack, bandwidth and CPU is wasted in both the first-hop routers 906 and the target host. 908 Just like for the Receiver Membership Report message, attacks using 909 the Host Interest Solicitation message can be reduced by requiring the 910 use of the Router-Alert option on the message. 912 11.3. MSNIP Managed Range Discovery 914 As discussed in [7] it is possible for directly connected systems 915 to send forged Multicast Router Advertisement messages containing the 916 SSM Range Discovery option. As the SSM Range Discovery option determines 917 the MSNIP managed range under IPv4, such forged messages can temporarily 918 replace the managed range map with incorrect information in receiving 919 hosts. An incorrect mapping can have two effects: 921 o Applications using a multicast destination address within the real SSM 922 range that have no valid receivers can be tricked into thinking that 923 their chosen destination address is no longer an SSM address and will 924 therefore start transmitting data. 926 o Applications using group addresses outside the valid SSM range can be 927 tricked into thinking that they are using an SSM destination address 928 and therefore prevented from transmitting data. 930 The Multicast Router Discovery SSM Range Option specification 931 suggests that a router receiving a Multicast Router Advertisement with 932 an inconsistent SSM Range Option log the event to the operator. Such 933 logging will enable tracking of this type of attack. 935 12. IANA Considerations 937 This document introduces the following new types and options that 938 require allocation by IANA: 940 o Two new IGMP messages for Host Interest Solicitation and Receiver 941 Membership Report. Each of these messages requires a new IGMP type 942 value to be assigned by IANA [11]. 944 o The new MSNIP Operation option for the Multicast Router Discovery 945 protocol. This option requires a new MRD type value to be assigned by 946 IANA. 948 o The new MSNIP Operation option for the Neighbour Discovery / ICMPv6 949 protocol. This option requires a new NDP / ICMPv6 type value to be 950 assigned by IANA. 952 13. Acknowledgments 954 The authors would like to thank Dave Thaler and Jon Crowcroft for their 955 contribution to this specification. 957 14. Authors' Addresses 959 Bill Fenner 960 AT&T Labs - Research 961 75 Willow Road 962 Menlo Park, CA 94025 963 fenner@research.att.com 965 Brian Haberman 966 Caspian Networks 967 One Park Drive, Suite 400 968 Research Triangle Park, NC 27709 969 bkhabs@nc.rr.com 970 Hugh Holbrook 971 Cisco Systems 972 170 W. Tasman Drive 973 San Jose, CA 95134 974 holbrook@cisco.com 976 Isidor Kouvelas 977 Cisco Systems 978 170 W. Tasman Drive 979 San Jose, CA 95134 980 kouvelas@cisco.com 982 15. References 984 [1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet 985 Group Management Protocol, Version 3", RFC 3376. 987 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet 988 Protocol.", RFC 2401. 990 [3] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 991 Independent Multicast - Sparse Mode (PIM-SM): Protocol 992 Specification (Revised)", Work In Progress, , 2002. 995 [4] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4 996 Multicast Address Allocation", Best Current Practices, , 2001. 999 [5] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In 1000 Progress, , 2001. 1002 [6] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in 1003 progress, , 21 November 2001. 1005 [7] I. Kouvelas, "Multicast Router Discovery SSM Range Option", work in 1006 progress, , November 2002. 1008 [8] R. Vida, et al, "Multicast Listener Discovery Version 2 (MLDv2) for 1009 IPv6", work in progress, , October 2002. 1011 [9] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) 1012 for the Internet Protocol Version 6 (IPv6)", RFC 2463. 1014 [10] C. Partridge, A. Jackson, "IPv6 Router Alert Option", RFC 2711. 1016 [11] Fenner, W., "IANA Considerations for IGMP", 1017 http://www.iana.org/assignments/igmp-type-numbers, RFC 3228 (BCP 1018 57), February 2002.