idnits 2.17.00 (12 Aug 2021) /tmp/idnits9186/draft-ietf-magma-msnip-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 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 257: '...Pv6. This option MUST be included in a...' RFC 2119 keyword, line 274: '... MSNIP, a miss-configuration SHOULD be...' RFC 2119 keyword, line 278: '...ers on that link MUST be configured to...' RFC 2119 keyword, line 655: '...packets, the checksum MUST be verified...' RFC 2119 keyword, line 706: '...packets, the checksum MUST be verified...' (9 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 (1 March 2003) is 7021 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 747 == Unused Reference: '7' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1044, 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) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2401 (ref. '7') (Obsoleted by RFC 4301) == Outdated reference: draft-ietf-magma-igmp-proxy has been published as RFC 4605 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 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-02.txt Brian Haberman/Caspian Networks 4 Hugh Holbrook/Cisco 5 Isidor Kouvelas/Cisco 6 1 March 2003 7 Expires: September 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. . . . . . . . . 9 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. Inter-operation with IGMP / MLD Proxying . . . . . . . 20 70 12. Security Considerations. . . . . . . . . . . . . . . . 21 71 12.1. Receiver Membership Report attacks. . . . . . . . . 21 72 12.2. Host Interest Solicitation attacks. . . . . . . . . 22 73 12.3. MSNIP Managed Range Discovery . . . . . . . . . . . 23 74 13. IANA Considerations. . . . . . . . . . . . . . . . . . 23 75 14. Acknowledgments. . . . . . . . . . . . . . . . . . . . 24 76 15. Authors' Addresses . . . . . . . . . . . . . . . . . . 24 77 16. Normative References . . . . . . . . . . . . . . . . . 24 78 17. Informative References . . . . . . . . . . . . . . . . 25 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. Using a higher level control protocol to determine 100 the existence of receivers for particular flows may not be practical as 101 there may be many potential receivers in each active session. 103 Information on which multicast destination addresses have receivers 104 for a particular sender is typically available to the multicast routing 105 protocol on the first hop router for a source. MSNIP uses this 106 information to notify the application in the sending system of when it 107 should start or stop transmitting. This is achieved without any 108 destination address specific state on the first-hop router for potential 109 sources without receivers. 111 2. Routing Protocol Support 113 For reasons described in this section, MSNIP only supports 114 transmission control for applications that use multicast destination 115 addresses that are routed using Source Specific Multicast (SSM). 117 Many currently deployed multicast routing protocols, require data 118 from an active source to be propagated past the first-hop router before 119 information on the existence of receivers becomes available on the 120 first-hop. In addition, such protocols require that this activity is 121 repeated periodically to maintain source liveness state on remote 122 routers. All dense-mode protocols fall under this category as well as 123 sparse-mode protocols that use shared trees for source discovery (such 124 as PIM-SM [9] ). In order to provide receiver interest notification for 125 such protocols, the default mode of operation would require that the 126 source IP system periodically transmits on all potential destination 127 addresses and the first-hop routers prune the traffic back. Such a 128 flood-and-prune behaviour on the first-hop link significantly diminishes 129 the benefits of managing source transmission. 131 In contrast, with source-specific sparse-mode protocols such as 132 PIM-SSM [9] availability of receiver membership information on the 133 first-hop routers is independent of data transmission. Such protocols 134 use an external mechanism for source discovery (like source-specific 135 IGMPv3 membership reports) to build source-specific multicast trees. 137 Clearly these two classes of routing protocols require different 138 handling for the problem MSNIP is trying to solve. In addition the 139 second type covers the majority of applications that MSNIP is targeted 140 at. MSNIP avoids the extra complication in supporting routing protocols 141 that require a flood and prune behaviour. 143 3. Service Interface for Requesting Membership Notification 145 Applications within an IP system that wish to source multicast 146 packets and are interested in being notified on the existence of 147 receivers must register with the IP layer of the system. MSNIP requires 148 that within the IP system, there is (at least conceptually) a service 149 interface that can be used to register with the IP layer for such 150 notifications. Dual stack systems supporting both IPv4 and IPv6 need to 151 provide separate service interfaces for each protocol. 153 A system's IPv4 or IPv6 service interface must support the 154 following operation or any logical equivalent: 156 IPMulticastsSourceRegister (socket, source-address, multicast-address) 157 IPMulticastsSourceDeregister (socket, source-address, multicast-address) 159 In addition the application must provide the following interface 160 for receiving notifications from the IP system: 162 IPMulticastSourceStart (socket, source-address, multicast-address) 163 IPMulticastSourceStop (socket, source-address, multicast-address) 165 where: 167 socket 168 is an implementation-specific parameter used to distinguish amongst 169 different requesting entities (e.g., programs or processes) within 170 the system; the socket parameter of BSD Unix system calls is a 171 specific example. 173 source-address 174 is the IP unicast source address that the application wishes to use 175 in transmitting data to the specified multicast address. The 176 specified address must be one of the IP addresses associated with 177 the network interfaces of the IP system. Note that an interface in 178 an IP system may be associated with more than one IP addresses. An 179 implementation may allow a special "unspecified" value to be passed 180 as the source-address parameter, in which case the request would 181 apply to the "primary" IP address of the "primary" or "default" 182 interface of the system (perhaps established by system 183 configuration). If transmission to the same multicast address is 184 desired using more than one source IP address, 185 IPMulticastSourceRegister must be invoked separately for each 186 desired source address. 188 multicast-address 189 is the IP multicast destination address to which the request 190 pertains. If the application wishes to transmit data to more than 191 one multicast addresses for a given source address, 192 IPMulticastSourceRegister must be invoked separately for each 193 desired multicast address. 195 3.1. Application Operation 197 Applications wishing to use MSNIP to control their multicast data 198 transmission to destination G from source address S operate as follows. 200 Initially the application contacts the IP system to obtain the 201 socket handle for use on all subsequent interactions. The application 202 invokes IPMulticastSourceRegister for the desired S and G and then waits 203 without transmitting any packets for the IP system to notify that 204 receivers for the session exist. 206 If and when the IP system notifies the application that receivers 207 exist using the IPMulticastSourceStart call, the application may start 208 transmitting data. After the application has been notified to send, if 209 all receivers for the session leave, the IP system will notify the 210 application using the IPMulticastSourceStop call. At this point the 211 application should stop transmitting data until it is notified again 212 that receivers have joined through another IPMulticastSourceStart call. 214 When the application no longer wishes to transmit data it should 215 invoke the IPMulticastsSourceDeregister call to let the IP system know 216 that it is no longer interested in notifications for this source and 217 destination. The IPMulticastsSourceDeregister call should be implicit in 218 the teardown of the associated socket state. 220 4. MSNIP Managed Address Range Negotiation 222 With current multicast deployment in the Internet, different 223 multicast routing protocols coexist and operate under separate parts of 224 the multicast address space. Multicast routers are consistently 225 configured with information that maps specific multicast address ranges 226 to multicast routing protocols. Part of this configuration describes the 227 subset of the address space that is used by source-specific multicast 228 (SSM) [10]. As described in section 2 MSNIP only tries to control 229 application transmission within the SSM address range. 231 It is desirable for applications within an IP system that supports 232 MSNIP to have a consistent service interface for multicast transmission 233 that does require the application to be aware of the SSM address range. 234 MSNIP supports this by allowing applications to use the service 235 interface described in section 3 for multicast destination addresses 236 that are outside its operating range. When an application registers for 237 notifications for a destination address that is not managed by MSNIP it 238 is immediately notified to start transmitting. This is equivalent to the 239 default behaviour of IP multicast without MSNIP support which forces 240 multicast applications to assume that there are multicast receivers 241 present in the network. 243 4.1. Router Coordination 245 In order for MSNIP to operate on a shared link where more than one 246 multicast routers may be present all multicast routers must be MSNIP 247 capable and have a consistent configuration for the SSM address range. 248 MSNIP enforces these requirements by using two new options for IPv4 in 249 the Multicast Router Discovery protocol [3] and one new option for IPv6 250 in Neighbor Discovery / ICMPv6 protocol. 252 4.1.1. MSNIP Operation Option 254 A multicast router advertises that it is participating in MSNIP 255 using the MSNIP Operation option in either the Multicast Router 256 Discovery protocol for IPv4 or the Neighbor Discovery / ICMPv6 protocol 257 for IPv6. This option MUST be included in all router advertisement 258 messages of a router that is configured for MSNIP. The format of the 259 option is as follows: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length=0 | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Type The type field is set to WW (TBD by IANA) for IPv4 and ZZ (TBD by 268 IANA) for IPv6. 270 A multicast router uses received Multicast Router Advertisement and 271 Neighbor Discovery / ICMPv6 messages to determine if all live neighbour 272 multicast routers on each interface are participating in MSNIP. When a 273 router advertisement message not containing an MSNIP option is received 274 by a router participating in MSNIP, a miss-configuration SHOULD be 275 logged to the operator in a rate-limited manner. 277 If even one multicast router on a link does not have MSNIP capability 278 then ALL routers on that link MUST be configured to not provide MSNIP 279 services and to not advertise the MSNIP Operation option. 281 4.1.2. SSM Range Option 283 The SSM Range Multicast Router Discover option advertises the SSM 284 Range with which the router is configured. The option is defined in [4]. 285 This option is only valid in IPv4. SSM support in IPv6 does not allow 286 for alternative SSM address ranges. 288 4.2. Communicating Range to Source Systems 290 When an application in an IP system uses the MSNIP service 291 interface to register for notification, the IP system must behave 292 differently depending on whether or not the destination address for 293 which the application registered is operating under SSM (and is being 294 managed by MSNIP). For SSM channels, the IP system should only instruct 295 the application to transmit when there are receivers for the multicast 296 destination. For non-SSM destination addresses the IP system will not be 297 able to determine if there are receivers and should immediately instruct 298 the application to transmit. 300 The MSNIP managed range discovery mechanism in a source IP system 301 has to deal with three different link configurations: 303 o A link connected to a multicast routed infrastructure where the first- 304 hop multicast routers are configured for MSNIP operation. 306 o A link connected to a multicast routed infrastructure where the first- 307 hop multicast routers are not participating in MSNIP. 309 o A link with no multicast routers. 311 To be able to differentiate between the three cases and in each 312 case discover the MSNIP managed range an MSNIP capable source IP system 313 must process IGMP Queries as well as Multicast Router Discovery 314 Advertisement messages. The presence of an IGMP querier differentiates 315 between the first two cases, where the host is in a multicast routed 316 network, and the third, where there is no multicast routing. 318 Multicast Router Discovery Advertisements provide the 319 differentiation between the first two cases. If the MRD Advertisements 320 contain the MSNIP Operation option then the IP system knows that routers 321 on that interface are configured for MSNIP operation. 323 In each of the three cases the MSNIP managed range is defined as 324 follows: 326 MSNIP capable multicast routers: 327 The IP system should use as the MSNIP range the SSM range provided 328 by the last SSM Range option [4] received in a Multicast Router 329 Discovery message. 331 Multicast routers not participating in MSNIP: 332 The IP system should use an empty MSNIP managed range. This 333 provides a compatibility mode where all group ranges default to 334 flooding. 336 Link without multicast routing: 337 To ensure backwards compatibility with existing receivers, MSNIP 338 does not try to control traffic on a router-less link. It does so 339 by defining the MSNIP managed range to be empty. Although it would 340 be possible to control multicast transmission on a shared link not 341 connected to a multicast routed infrastructure, MSNIP operation 342 would require that receivers were capable of actively participating 343 in the protocol. Source control would work by defining an address 344 range within which sources would not transmit until directly 345 contacted by a receiver (for example the default IPv4 SSM range of 346 232/8 [6]). The drawback would be that a non MSNIP capable receiver 347 joining a group through IGMP would have no way of getting the 348 source to transmit. Relying on triggered IGMP messages from legacy 349 receivers to control transmission would not be robust either. 351 5. Requesting and Receiving Notifications 353 Like IGMP, MSNIP is an asymmetric protocol specifying different 354 behaviour for systems wishing to source traffic and for multicast 355 routers. Host IP systems multicast Host Interest Solicitation messages 356 to register for notification with their first-hop routers. Routers 357 unicast Router Receiver Membership Reports to IP systems to notify them 358 of the arrival of the first or departure of the last receivers for a 359 session. Note that a system may perform at the same time both of the 360 above functions. An example is a router that wishes to source traffic. 362 5.1. Host Interest Solicitation 364 Source systems that wish to be managed by MSNIP periodically 365 transmit an Interest Solicitation message. This message is multicast 366 with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) 367 or ALL_MLDv2_ROUTERS (TBA) and is transmitted every [Interest 368 Solicitation Interval] seconds. The Interest Solicitation message 369 contains a holdtime which is set to [Interest Solicitation Holdtime] and 370 instructs the multicast first-hop routers to maintain MSNIP state for 371 this IP system for the specified period. A generation ID is also 372 included in the Interest Solicitation message to provide support for 373 routers to detect IP system restarts (see section 8.1). Systems with 374 multiple interfaces or multiple IP addresses per interface must 375 originate separate Host Interest Solicitation messages from each of 376 their IP addresses that they wish to have managed by MSNIP. In practice 377 a system with more than one IP address is treated by MSNIP as multiple 378 IP systems. 380 When an IP system first comes up it transmits [Robustness Variable] 381 Interest Solicitation messages spaced by [Initial Interest Solicitation 382 Interval] seconds. 384 All MSNIP capable routers that receive an Interest Solicitation 385 message from an IP system, maintain a system interest record of the 386 form: 388 (IP system address, holdtime timer) 390 Each time an Interest Solicitation message is received from the IP 391 system, the holdtime timer is reset to the holdtime in the received 392 message. In addition the router may respond to the solicitation message 393 with a Receiver Membership Report message described in section 5.2. The 394 message contains a TRANSMIT record for each of the multicast destination 395 addresses within the MSNIP managed range for which the routing protocol 396 indicates there are receivers for this source system. 398 The holdtime timer of a record counts down to zero. When the 399 holdtime timer of a specific system interest record expires, the record 400 is deleted. 402 5.2. Router Receiver Membership Reports 404 Receiver Membership Report messages are used by routers to 405 communicate the receiver membership status of particular multicast 406 destination addresses to a specific IP system. Each message contains a 407 list of transmission control records of either TRANSMIT or HOLD type 408 that instruct a system to respectively start or stop sending traffic on 409 this link to the specified multicast destination address. Receiver 410 Membership Report messages are unicast to the target system. 412 In addition to reports sent in response to Interest Solicitation 413 messages, routers send unsolicited Receiver Membership Reports to IP 414 systems when the receiver membership status reported by the multicast 415 routing protocol changes for a specific source and multicast 416 destination. Such reports are only sent if the destination address is 417 managed by MSNIP and the router has a system interest record created by 418 a previously received Interest Solicitation message with an IP system 419 address equal to the source address. If the source destination pair 420 satisfy these conditions then [Robustness Variable] Receiver Membership 421 Reports are sent out spaced by [Unsolicited Membership Report Interval] 422 seconds. If the membership status changes again for the same 423 destination address and source system while transmission of Receiver 424 Membership Reports is still pending then the pending report messages are 425 canceled and a new set of [Robustness Variable] messages indicating the 426 new state are scheduled. 428 When an IP system receives a Receiver Membership Report message, 429 for each of the TRANSMIT records listed in the message it creates or 430 updates a transmission record of the form: 432 (router address, source address, multicast address, holdtime timer) 434 The router address is obtained from the source address on the IP header 435 of the received message. The source address is obtained from the 436 destination address in the of the IP header. The holdtime timer is set 437 to the value of the holdtime field in the received Receiver Membership 438 Report message. 440 For each HOLD record present in the message, the system deletes the 441 matching previously created transmission record from its state. 443 The holdtime timer of a record counts down to zero. When the 444 holdtime timer of a specific transmission record expires, the record is 445 deleted. 447 Note that creation and deletion of transmission records in an IP 448 systems state may cause local applications to be notified to start and 449 stop transmitting data (see section 6). 451 6. Application Notification 453 This section describes the relation between protocol events and 454 notifications to source applications within an IP system. The state 455 machine below is specific to each source address of the IP system and 456 each multicast destination address. The initial state is the No Info 457 state. 459 +-----------------------------------+ 460 | Figures omitted from text version | 461 +-----------------------------------+ 463 Figure 1: Per source-address (S) and multicast destination address (G) 464 state machine at an IP system 466 In tabular form, the state-machine is: 468 +-----------+-----------------------------------------------------------+ 469 | | Event | 470 | +----------+-----------+------------+-----------+-----------+ 471 |Prev State |New |Start |Stop |Recv |Recv last | 472 | |Register |Manage |Manage |TRANSMIT |HOLD or | 473 | | | | | |timeout | 474 +-----------+----------+-----------+------------+-----------+-----------+ 475 | |Start new |-> Hold |- |- |- | 476 |No Info | |Stop ALL | | | | 477 | | |registered | | | | 478 +-----------+----------+-----------+------------+-----------+-----------+ 479 | |- |- |-> No Info |-> |- | 480 |Hold | | | |Transmit | | 481 | | | |Stop ALL |Start ALL | | 482 | | | |registered |registered | | 483 +-----------+----------+-----------+------------+-----------+-----------+ 484 | |Start new |- |-> No Info |- |-> Hold | 485 |Transmit | | | | |Stop ALL | 486 | | | | | |registered | 487 +-----------+----------+-----------+------------+-----------+-----------+ 489 The events in state machine above have the following meaning: 491 New register 492 A new application has registered through a call to 493 IPMulticastsSourceRegister for this S and G. 495 Start manage 496 We received a SSM Range option in an MRD packet on the interface 497 that S belongs to that changed the status of G from a non-managed 498 to a MSNIP managed destination address. The SSM Range option is 499 only valid in IPv4. 501 Stop manage 502 We received a SSM Range option in an MRD packet on the interface 503 that S belongs to that changed the status of G from a MSNIP managed 504 to a non-managed destination address or the mapping state that 505 caused this destination address to be managed expired. The SSM 506 Range option is only valid in IPv4. 508 Receive TRANSMIT 509 We received a Receiver Membership Report with S as the IP 510 destination address that contains a TRANSMIT record for G. 512 Receive last HOLD or timeout 513 We either received a Receiver Membership Report with S as the IP 514 destination address that contains a HOLD record for G or the 515 holdtime timer in a transmission record for S and G expired and 516 there are no other transmission records for S and G. This means 517 that the last router that was reporting receivers no longer does so 518 and there are no routers left wishing to receive traffic from this 519 S to destination address G. 521 The state machine actions have the following meaning: 523 Start new 524 Send an IPMulticastSourceStart notification to the application that 525 just registered for this S and G. 527 Start ALL registered 528 Send an IPMulticastSourceStart notification to all applications 529 that are registered for this S and G. 531 Stop ALL registered 532 Send an IPMulticastSourceStop notification to all applications that 533 are registered for this S and G. 535 7. Router Processing 537 This section describes the per-source system tracking state machine 538 operated by each first-hop router. The initial state is No Info. 540 +-----------------------------------+ 541 | Figures omitted from text version | 542 +-----------------------------------+ 544 Figure 2: Per IP source system (S) state machine at a router 546 In tabular form, the state-machine is: 548 +------------+----------------------------------------------------------+ 549 | | Event | 550 | +------------+-----------+--------------+------------------+ 551 |Prev State | Receive | HIS | Receivers | Receivers | 552 | | HIS | timeout | for new | of G leave | 553 | | | | destination | | 554 | | | | G | | 555 +------------+------------+-----------+--------------+------------------+ 556 | | -> | - | - | - | 557 | | Tracking | | | | 558 | | Set HT to | | | | 559 |Not | message | | | | 560 |tracking | holdtime | | | | 561 | | Send ALL | | | | 562 | | existing | | | | 563 | | TRANSMITs | | | | 564 +------------+------------+-----------+--------------+------------------+ 565 | | Set HT to | -> Not | Send | Send HOLD | 566 | | message | tracking | TRANSMIT | for G | 567 |Tracking | holdtime | | for G | | 568 | | Send ALL | | | | 569 | | existing | | | | 570 | | TRANSMITs | | | | 571 +------------+------------+-----------+--------------+------------------+ 573 The events in state machine above have the following meaning: 575 Receive HIS 576 The router has received a Host Interest Solicitation from S. 578 HIS timeout 579 The holdtime timer (HT) in the host interest record associated with 580 S has expired. 582 Receivers for new destination G 583 The routing protocol has informed MSNIP that it now has receivers 584 for the MSNIP managed destination address G and source IP system S. 586 Receivers of G leave 587 The routing protocol has informed MSNIP that all receivers for the 588 MSNIP managed destination address G and source IP system S have 589 left the channel. 591 The state machine actions have the following meaning: 593 Set HT to message holdtime 594 The holdtime timer in the host interest record associated with S is 595 restarted to the value of the holdtime field in the received Host 596 Interest Solicitation message. 598 Send ALL existing TRANSMITs 599 The router builds and transmits Receiver Membership Reports to S 600 that contain a TRANSMIT record for each of the MSNIP managed 601 destination addresses that have receivers for S. 603 Send TRANSMIT for G 604 The router builds and transmits a Receiver Membership Report to S 605 that contains a TRANSMIT record for the destination address G. 607 Send HOLD for G 608 The router builds and transmits a Receiver Membership Report to S 609 that contains a HOLD record for the destination address G. 611 8. Message Formats 613 The following packet formats are valid for both IPv4 and IPv6. IP 614 version specific values will be explicitly defined. 616 There are two message types of concern to the MSNIP protocol 617 described in this document: 619 +-------------------+----------------------------+ 620 | Type Number (hex) | Message Name | 621 +-------------------+----------------------------+ 622 | 0xXX | Host Interest Solicitation | 623 +-------------------+----------------------------+ 624 | 0xYY | Receiver Membership Report | 625 +-------------------+----------------------------+ 627 8.1. Host Interest Solicitation Packet 629 A Interest Solicitation packet is periodically multicast by MSNIP 630 capable systems to declare interest in Receiver Membership Reports from 631 multicast routers on the link. The Interest Solicitation message is 632 multicast with a destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) 633 or ALL_MLDv2_ROUTERS (TBA). 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Type | Reserved | Checksum | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Holdtime | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Type The type field is set to XX (to be assigned by IANA as an IGMP type 644 for IPv4 and an ICMPv6 type for IPv6). 646 Reserved 647 Transmitted as zero. Ignored upon receipt. 649 Checksum 650 In IPv4, the Checksum is the 16-bit one's complement of the one's 651 complement sum of the whole IGMP message (the entire IP payload). 652 In IPv6, the Checksum is the standard ICMPv6 checksum, covering the 653 entire MLDv2 message plus a "pseudo-header" of IPv6 header fields 654 .CITE ICMPv6 . For computing the checksum, the Checksum field is 655 set to zero. When receiving packets, the checksum MUST be verified 656 before processing a packet. 658 Holdtime 659 The amount of time a receiving router must keep the system interest 660 state alive, in seconds. The default value for this field is 661 [Interest Solicitation Holdtime]. 663 GenID 664 Generation ID of the IP system. A number that is selected randomly 665 for each of the [Robustness Variable] initial Interest Solicitation 666 messages when the system comes up and afterwards remains fixed to 667 the value used in the last of the initial messages throughout the 668 system lifetime. The GenID is used by routers to detect system 669 crashes. 671 8.2. Receiver Membership Report Packet 673 A Receiver Membership Report packet is unicast by first-hop multicast 674 routers and targeted at potential sources to inform them of the 675 existence or not of receivers for the listed multicast destination 676 addresses. 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Type | Dest Count | Checksum | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Holdtime | Reserved | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Record-Type-1 | Record-Reserved-1 | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Destination-Address-1 | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | . | 690 | . | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Type The type field is set to YY (to be assigned by IANA as an IGMP type 694 for IPv4 and an ICMPv6 type for IPv6). 696 Dest Count 697 The number of multicast destination address records present in this 698 message. 700 Checksum 701 In IPv4, the Checksum is the 16-bit one's complement of the one's 702 complement sum of the whole IGMP message (the entire IP payload). 703 In IPv6, the Checksum is the standard ICMPv6 checksum, covering the 704 entire MLDv2 message plus a "pseudo-header" of IPv6 header fields 705 .CITE ICMPv6 . For computing the checksum, the Checksum field is 706 set to zero. When receiving packets, the checksum MUST be verified 707 before processing a packet. 709 Holdtime 710 The amount of time in seconds that the target host must keep alive 711 the transmission record state created or updated by the TRANSMIT 712 records in this report. The router originating the Receiver 713 Membership Report sets this field to the current value of the 714 holdtime timer in the system interest record corresponding to the 715 target host. As a result Receiver Membership Reports sent in 716 response to the reception of a Host Interest Solicitation message 717 have their holdtime set to the value of the holdtime field in the 718 received HIS message. 720 Reserved 721 Transmitted as zero. Ignored upon receipt. 723 Record-Type-1 724 The type of the first transmission control record in this message. 725 Valid values are: 727 +-------------+----------------------------------------------+-------+ 728 | Record Type | Description | Value | 729 +-------------+----------------------------------------------+-------+ 730 | TRANSMIT | Request to start transmitting to destination | 1 | 731 +-------------+----------------------------------------------+-------+ 732 | HOLD | Request to stop transmitting to destination | 2 | 733 +-------------+----------------------------------------------+-------+ 735 Reserved 736 Transmitted as zero. Ignored upon receipt. 738 Destination-Address-1 739 The multicast destination address of the first record in the 740 message. 742 8.3. IPv4 Header Fields 744 Like all other IGMP messages, MSNIP messages are encapsulated in 745 IPv4 datagrams, with an IP protocol number of 2. Every MSNIP message 746 described in this document is sent with an IP Time-to-Live of 1, and 747 carries an IP Router Alert option [RFC-2113] in its IP header. 749 8.4. IPv6 Header Fields 751 MLD messages are a sub-protocol of the Internet Control Message 752 Protocol (ICMPv6 [5] ). MSNIP messages are identified in IPv6 packets by 753 a preceding Next Header value of 58. All MSNIP messages described in 754 this document are 755 sent with a link-local IPv6 Source Address (or the unspecified address, 756 if a valid link-local address is not available), an IPv6 Hop Limit of 1, 757 and an IPv6 Router Alert option .CITE RAv6 in a Hop-by-hop Options 758 header. 760 9. Constants Timers and Default Values 762 Robustness Variable 763 The Robustness Variable allows tuning for the expected packet loss 764 on a network. If a network is expected to be lossy, the Robustness 765 Variable may be increased. MSNIP is robust to (Robustness Variable 766 - 1) packet losses. The Robustness Variable MUST NOT be zero, and 767 SHOULD NOT be one. Default: 2 769 Interest Solicitation Interval 770 The interval used by MSNIP capable systems between transmissions of 771 Interest Solicitation messages. Default: 60 secs 773 Interest Solicitation Holdtime 774 The interval inserted in Interest Solicitation messages by systems 775 to instruct routers how long they should maintain system interest 776 state for. This MUST be ((the Robustness Variable) times (the 777 Interest Solicitation Interval) plus (one second)). 779 Initial Interest Solicitation Interval 780 The interval used by systems to send out the initial Interest 781 Solicitation messages when they first come up. Default: 1 second. 783 Unsolicited Membership Report Interval 784 The interval used by routers to send out a set of Membership Report 785 messages when the receiver membership changes for a specific 786 system. Default: 1 second. 788 10. Possible Optimisations 790 10.1. Suppressing HIS Messages 792 A possible optimisation for MSNIP is to suppress the transmission 793 of Host Interest Solicitation messages from the source address of an IP 794 system for which no local application has registered interest. In 795 addition to conserving bandwidth, not transmitting HIS messages prevents 796 remote receivers for groups with no matching source application from 797 creating transmission record state in the host system. 799 10.2. Host Stack Filtering 801 Legacy applications that have not been coded with MSNIP support can 802 still be prevented from waisting first-hop link bandwidth by filtering 803 transmitted packets at the operating system level. Even though such 804 applications will not register for MSNIP notifications with the host 805 operating system, if the OS is MSNIP capable and the application is 806 transmitting data to an MSNIP managed group for which there are no 807 transmit records, the OS can safely filter the packets and not transmit 808 them on the wire. 810 A problem with the filtering approach is that it cannot be combined 811 with the HIS message suppression optimisation (see section 10.1). If 812 there is no registered applications in the system and HIS messages are 813 being suppressed then the first-hop routers will not send any Receiver 814 Membership Reports to the system. As a result knowledge of receiver 815 membership from the presence of transmit records for groups operated by 816 legacy applications will not exist. It therefore becomes unsafe to 817 filter packets from legacy applications. 819 10.3. Responding to Unexpected IGMP Queries 821 Under steady state the router side of the IGMP protocol elects a 822 single router on each link that is responsible for issuing IGMP Queries. 823 Routers other than the acting IGMP querier will send an IGMP Query only 824 if they restart and have no IGMP querier election state or if the active 825 Querier crashes and a new election takes place. 827 MSNIP can take advantage of this mechanism to quickly populate the 828 host interest records of a new router starting up. When the router comes 829 up it will issue an IGMP Query in an attempt to be elected as a Querier. 830 MSNIP capable hosts will notice that the sender of the Query is not the 831 acting Querier. They can use this trigger to respond with Host Interest 832 Solicitation Messages (with transmission randomised over a small 833 interval) to quickly bring the new router up-to-date. 835 10.4. Host and Router Startup 837 When a host operating system is restarted there may be applications 838 that are started as part of the initialisation process and want to 839 source IPv4 multicast traffic. It is possible for the applications to 840 register through MSNIP with the IP subsystem and to start transmitting 841 multicast data before the host receives the MSNIP managed range 842 definition through the SSM Range option of the Multicast Router 843 Discovery protocol. 845 This temporary flooding can be avoided if the host OS holds off 846 notifying MSNIP capable applications that they can transmit until it 847 receives an MRD advertisement and learns the SSM configuration for the 848 network. This behaviour has the drawback that it is not compatible with 849 legacy networks with no MRD deployment. In such a network the host OS 850 has to be able to determine after a configurable period that MRD is not 851 enabled and hence all multicast applications wishing to source traffic 852 should be notified to transmit. A good default value for this period is 853 the MAX_RESPONSE_DELAY of the Multicast Router Discovery protocol [4]. 855 Late router startup is harder to deal with. Hosts that start up 856 before the multicast router may time out waiting for an MRD 857 advertisement and instruct all MSNIP capable multicast source 858 applications to transmit data. One way to work around this problem is to 859 configure the host OS to wait forever for an MRD advertisement before 860 instructing MSNIP applications to transmit. 862 11. Inter-operation with IGMP / MLD Proxying 864 MSNIP is intended for use on networks with multicast servers 865 offering a large number of potential sessions. Although unlikely it is 866 possible to deploy such a server behind an IGMP / MLD Proxy [12]. 868 If a device performing IGMP / MLD Proxying wishes to proxy MSNIP, 869 it MUST forward MSNIP Host Interest Solicitation messages that are 870 received on downstream interfaces to its upstream interface. No special 871 treatment is required for MSNIP Receiver Membership Reports as they are 872 unicast to the target host. 874 In addition to the forwarding of MSNIP messages, an IGMP proxy MUST 875 operate the Multicast Router Discovery protocol [3] on all its 876 downstream interfaces and advertise the MSNIP capability option (section 877 4.1.1) and SSM address range option (section 4.1.2). The MSNIP 878 capability option should be advertised on downstream interfaces only if 879 it is included in MRD messages received on the upstream interface. The 880 address range to be included in the SSM Range option MUST be determined 881 by MRD and IGMP messages received on the upstream interface of the proxy 882 according to the rules in section 4.2. 884 In addition to the forwarding of MSNIP messages, an MLD proxy MUST 885 operate the IPv6 Neighbor Discovery protocol. The MSNIP capability 886 option should be advertised on downstream interfaces when it is included 887 in IPv6 Neighbor Discovery messages received on the upstream interface. 889 12. Security Considerations 891 We consider the ramifications of a forged message of each type. As 892 described in [1] IPSEC AH can be used to authenticate IGMP messages if 893 desired. 895 12.1. Receiver Membership Report attacks 897 A DoS attack on a host could be staged through forged Receiver 898 Membership Report messages. The attacker can send a large number of 899 reports, each with a large number of TRANSMIT records and a holdtime 900 field set to a large value. The host will have to store and maintain the 901 transmission records specified in all of those reports for the duration 902 of the holdtime. This would consume both memory and CPU cycles in the 903 host. 905 Forged Receiver Membership Report messages from the local network 906 can be easily traced. There are three measures necessary to defend 907 against externally forged reports: 909 o Routers SHOULD NOT forward Receiver Membership Reports. This is easier 910 for a router to accomplish if the report carries the Router-Alert 911 option. 913 o Hosts SHOULD ignore Receiver Membership Reports without the Router- 914 Alert option. 916 Note that a remote attack through the multicast routing protocol is 917 possible. A remote site can originate join state for a large number of 918 groups that will propagate through MSNIP to the target source host. 919 Such attacks are considered a more significant problem for the routers 920 involved and are left up to the routing protocol security. 922 HOLD records in forged Receiver Membership Report messages are not 923 a significant threat as hosts track the individual interests of each 924 first-hop router separately. Only by forging the source address of the 925 report message so that is appears to have originated from a real first- 926 hop router can the attacker cause the source to stop transmitting to a 927 group that has valid receivers. Such forged messages can be detected by 928 the router itself. 930 12.2. Host Interest Solicitation attacks 932 Forged Host Interest Solicitation messages can have two effects: 934 o When non-existent source addresses are used the solicitation messages 935 can create unwanted host record state on attached routers for the 936 duration of the holdtime specified in the message. 938 o When a source address corresponding to an existing host is used in the 939 forged HIS message, receipt of the message by attached routers will 940 cause them to transmit Receiver Membership Reports messages for any 941 multicast destination addresses with receivers for the target host. 942 Although no additional state will be created in routers or hosts from 943 this attack, bandwidth and CPU is wasted in both the first-hop routers 944 and the target host. 946 Just like for the Receiver Membership Report message, attacks using 947 the Host Interest Solicitation message can be reduced by requiring the 948 use of the Router-Alert option on the message. 950 12.3. MSNIP Managed Range Discovery 952 As discussed in [4] it is possible for directly connected systems 953 to send forged Multicast Router Advertisement messages containing the 954 SSM Range Discovery option. As the SSM Range Discovery option determines 955 the MSNIP managed range under IPv4, such forged messages can temporarily 956 replace the managed range map with incorrect information in receiving 957 hosts. An incorrect mapping can have two effects: 959 o Applications using a multicast destination address within the real SSM 960 range that have no valid receivers can be tricked into thinking that 961 their chosen destination address is no longer an SSM address and will 962 therefore start transmitting data. 964 o Applications using group addresses outside the valid SSM range can be 965 tricked into thinking that they are using an SSM destination address 966 and therefore prevented from transmitting data. 968 The Multicast Router Discovery SSM Range Option specification 969 suggests that a router receiving a Multicast Router Advertisement with 970 an inconsistent SSM Range Option log the event to the operator. Such 971 logging will enable tracking of this type of attack. 973 13. IANA Considerations 975 This document introduces the following new types and options that 976 require allocation by IANA: 978 o Two new IGMP messages for Host Interest Solicitation and Receiver 979 Membership Report. Each of these messages requires a new IGMP type 980 value to be assigned by IANA [11]. 982 o The new MSNIP Operation option for the Multicast Router Discovery 983 protocol. This option requires a new MRD type value to be assigned by 984 IANA. 986 o The new MSNIP Operation option for the Neighbour Discovery / ICMPv6 987 protocol. This option requires a new NDP / ICMPv6 type value to be 988 assigned by IANA. 990 14. Acknowledgments 992 The authors would like to thank Dave Thaler, Jon Crowcroft, Toerless 993 Eckert and Haixiang He for their contribution to this specification. 995 15. Authors' Addresses 997 Bill Fenner 998 AT&T Labs - Research 999 75 Willow Road 1000 Menlo Park, CA 94025 1001 fenner@research.att.com 1003 Brian Haberman 1004 Caspian Networks 1005 One Park Drive, Suite 400 1006 Research Triangle Park, NC 27709 1007 bkhabs@nc.rr.com 1009 Hugh Holbrook 1010 Cisco Systems 1011 170 W. Tasman Drive 1012 San Jose, CA 95134 1013 holbrook@cisco.com 1015 Isidor Kouvelas 1016 Cisco Systems 1017 170 W. Tasman Drive 1018 San Jose, CA 95134 1019 kouvelas@cisco.com 1021 16. Normative References 1023 [1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet 1024 Group Management Protocol, Version 3", RFC 3376. 1026 [2] R. Vida, et al, "Multicast Listener Discovery Version 2 (MLDv2) for 1027 IPv6", work in progress, , October 2002. 1029 [3] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In 1030 Progress, , 2001. 1032 [4] I. Kouvelas, "Multicast Router Discovery SSM Range Option", work in 1033 progress, , November 2002. 1035 [5] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) 1036 for the Internet Protocol Version 6 (IPv6)", RFC 2463. 1038 [6] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in 1039 progress, , 21 November 2001. 1041 [7] S. Kent, R. Atkinson, "Security Architecture for the Internet 1042 Protocol.", RFC 2401. 1044 [8] C. Partridge, A. Jackson, "IPv6 Router Alert Option", RFC 2711. 1046 17. Informative References 1048 [9] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 1049 Independent Multicast - Sparse Mode (PIM-SM): Protocol 1050 Specification (Revised)", Work In Progress, , 2002. 1053 [10] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4 1054 Multicast Address Allocation", Best Current Practices, , 2001. 1057 [11] W. Fenner, "IANA Considerations for IGMP", 1058 http://www.iana.org/assignments/igmp-type-numbers, RFC 3228 (BCP 1059 57), February 2002. 1061 [12] W. Fenner, H. He, B. Haberman, H. Sandick, "IGMP / MLD-based 1062 Multicast Forwarding (IGMP / MLD Proxying)" draft-ietf-magma-igmp- 1063 proxy-01.txt, November, 2002.