idnits 2.17.00 (12 Aug 2021) /tmp/idnits17114/draft-holbrook-idmr-igmpv3-ssm-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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IGMPv3], [SSM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 239 has weird spacing: '...ress in sourc...' -- 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 March 2000) is 8115 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 34, but not defined == Unused Reference: 'RFC2119' is defined on line 325, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IGMPv3' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-ALLOCATION' -- Possible downref: Non-RFC (?) normative reference: ref. 'MSFAPI' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSM' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT IGMPv3 for SSM H. Holbrook 3 Expires September 2, 2001 Cisco Systems 4 B. Cain 5 Cereva Networks 6 2 March 2000 8 Using IGMPv3 For Source-Specific Multicast 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC 2119]. 35 Abstract 37 This document describes changes to the Internet Group Management 38 Protocol Version 3 (IGMPv3) [IGMPv3] to support source-specific 39 multicast (SSM) [SSM]. 41 1. Overview and Rationale 43 The Internet Group Management Protocol (IGMP) [RFC1112,IGMPv2,IGMPv3], 44 is the standard mechanism for communicating IP multicast group 45 membership requests from a host to its locally attached routers. IGMP 46 version 3 (IGMPv3) [IGMPv3] provides the ability for a host to 47 selectively request or filter traffic from individual sources within a 48 multicast group. The IGMPv3 algorithms and message processing rules 49 require small changes to support the source-specific multicast model. 50 This document defines the modifications required to the host and router 51 portions of IGMPv3 to support source-specific multicast. 53 2. IGMP Host Requirements for Source-Specific Multicast 55 This document does not strictly require the IP layer or IGMP module of 56 an IGMPv3-enabled host to treat SSM destination addresses specially. 57 For correct operation of SSM, however, a host applications must 59 - know the range of destination addresses that have SSM semantics 61 - use ONLY the source-specific APIs to request delivery of packets 62 sent to SSM destination addresses 64 The 232/8 address range is currently allocated for SSM by IANA [IANA- 65 ALLOCATION], however hosts and routers may be configured to force SSM 66 semantics for other addresses as well. A IGMP module on a host or 67 router SHOULD have a configuration mechanism to set the SSM address 68 range(s). If this configuration option exists, it MUST default to the 69 IANA-allocated SSM range. The mechanism for setting this configuration 70 option MUST at least allow for manual configuration. Protocol 71 mechanisms to set this option may be defined in subsequent documents. 72 If a host that does not have this option, applications on that host may 73 be denied SSM service by other non-compliant applications on the same 74 host or by other non-compliant hosts on the same network, as described 75 below. 77 It is strongly recommened that the multicast source filtering (MSF) APIs 78 of [MSFAPI] be used to implement SSM. If the host IP module receives a 79 non source-specific request for an SSM destination address, it SHOULD 80 return an error to the application. If the host IP module is not 81 configured with the SSM address range, the non-source-specific (RFC 82 1112) APIs will not return an error when passed an SSM destination 83 addresses. On these hosts, applicaitons that mistakenly use the wrong 84 APIs (e.g., "join(G)", or "IPMulticastListen(G,EXCLUDE(S1))" for IGMPv3) 85 to request delivery of packets sent to an SSM address will not receive 86 the requested service, as routers will refuse to process any such 87 request, as per section 10.2. 89 This section documents the behavior of hosts with respect to sending and 90 receiving the following IGMP message types: 92 - IGMPv1/v2 Reports 93 - IGMPv3 Reports 94 - IGMPv1/v2 Queries 95 - IGMPv2 Leave 96 - IGMPv2 Group Specific Query 97 - IGMPv3 Group Specific Query 98 - IGMPv3 Group-and-Source Specific Query 100 2.1. IGMPv1/v2 Reports 102 A compliant host SHOULD NOT send IGMPv1 or IGMPv2 host reports for SSM 103 addresses. If an SSM-unaware IGMPv3-enabled host receives an IGMPv1 or 104 IGMPv2 host report for SSM destination address G, its IGMP module will 105 revert to IGMPv1/v2 compatibility mode for address G. This will prevent 106 the host from sending source-specific joins, and consequently the SSM 107 service model will not be provided for destination address G. 108 Therefore, it is important that the SSM address range be used only in 109 conjunction with the SSM APIs. 111 2.2. IGMPv3 Reports 113 Source-specific multicast destination-and-source pairs (channels) are 114 reported using IGMPv3 with the IGMPv3 INCLUDE report. A host 115 implementation MAY report either one or multiple channels in a single 116 IGMPv3 report. 118 When source-specific channels are reported in an IGMPv3 Report, the 119 report may contain one or more group records of the following types: 121 - MODE_IS_INCLUDE as part of a Current-State Record 123 - ALLOW_NEW_SOURCES as part of a State-Change Record 125 - BLOCK_OLD_SOURCES as part of a State-Change Record 127 The source list for any individual Group Record may be of length one or 128 more than one. If a host implementation so chooses, it may report both 129 SSM destination addresses and RFC 1112 multicast (henceforth termed Any- 130 Source Multicast or ASM as in [SSM]) destination addresses in the same 131 message. 133 If all applications on a host use the SSM APIs for SSM addresses, then a 134 host would not normally send any of the following group record types for 135 addresses in the source-specific range: 137 - MODE_IS_EXCLUDE as part of a Current-State Record 139 - CHANGE_TO_INCLUDE_MODE as part of a Filter-Mode-Change Record 141 - CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record 143 EXCLUDE mode does not apply to SSM addresses, and the filter mode used 144 for a SSM address should never change to or from EXCLUDE mode under 145 correct application behavior. [Note: please see Section 4, Outstanding 146 Issues.] A host that is configured with the SSM address range MUST NOT 147 send any of the above record types for an SSM address. 149 2.3. IGMPv1/IGMPv2 Queries 151 If an IGMPv1 or IGMPv2 query is received, the IGMPv3 protocol 152 specification requires the host to revert to the older (IGMPv1 or 153 IGMPv2) mode of operation for that destination address. If this occurs, 154 the host will stop reporting source-specific subscriptions for that 155 destination address and start using either IGMPv1 or IGMPv2 to report 156 interest in the SSM destination address, unqualified by a source 157 address. If this occurs, SSM semantics will no longer be applied for G. 159 A router compliant with this document would never generate an IGMPv1 or 160 IGMPv2 query for an address in the SSM range, so this situation would 161 only occur if some router is not compliant with this document for an 162 address that the host believes to have SSM semantics. 164 When a host reverts to an older version of operation for some 165 destination address, it will no longer be able to send source-specific 166 IGMPv3 messages and applications on that host will not be able to 167 subscribe to SSM channels using that destination address. A host that 168 is configured with the SSM address range MAY have a configuration option 169 to allow it continue to to refuse to revert to the older (IGMPv1 or 170 IGMPv2) mode of operation for addresses in the source-specific range, 171 even if an IGMPv1 or IGMPv2 query is heard. 173 These problems only arise on a shared-medium link that has both SSM- 174 aware and non-SSM-aware routers present. Therefore, it SHOULD be 175 administratively assured that all routers on a given shared-medium 176 network are compliant with this document. 178 2.4. IGMPv2 Leave 180 IGMP Leave messages are not processed by hosts. IGMPv2 Leave messages 181 are not sent for SSM addresses. 183 2.5. IGMPv2 Group Specific Query 185 If a host receives an IGMPv2 Group Specific Query for an address in its 186 configured source-specific range, it MUST silently discard the query, 187 even if the group listed matches the source-specific destination address 188 of some locally subscribed source-specific group. The transmission of 189 such a query indicates that the sender is not compliant with this 190 document. 192 2.6. IGMPv3 Group Specific Query 194 If a host receives an IGMPv3 Group-Specific Query in its configured 195 source-specific range, it MUST respond with a report if the group 196 matches the source-specific destination address of any of its subscribed 197 source-specific groups. 199 Although in the current IGMPv3 protocol specification, routers would 200 have no reason to send one, the semantics of such a query are well- 201 defined in this range and future implementations may have reason to send 202 such a query. Be liberal in what you accept. 204 2.7. IGMPv3 Group-and-Source Specific Query 206 An IGMPv3 router will query a source-specific channel that a host has 207 requested to leave (via a BLOCK_OLD_SOURCES record) with a group-and- 208 source specific query. A host MUST respond to a group-and-source 209 specific query for which the group and source in the query match match 210 any channel for which the host has a subscription. 212 Hosts MUST be able to process a query with multiple sources listed per 213 group. 215 3. IGMP Router Requirements for Support Source-Specific Multicast 217 Routers must be aware of the SSM address range. The 232/8 address range 218 is currently allocated for SSM by IANA [IANA-ALLOCATION]. However, an 219 SSM router may be configured to force SSM semantics for other addresses 220 as well. If this configuration option exists, it MUST default to the 221 IANA-allocated range. 223 This section documents the behavior of routers with respect to the 224 following types of IGMP messages for source-specific destination 225 addresses: 227 - IGMPv3 Reports 228 - IGMPv3 General Query 229 - IGMPv3 Group-Specific Query 230 - IGMPv3 Group-and-Source Specific Query 231 - IGMPv1/v2 Reports 232 - IGMPv1/v2 Queries 233 - IGMPv2 Leave 235 3.1. IGMPv3 Reports 237 IGMPv3 Reports are used to report source-specific subscriptions in the 238 SSM address range. If a router receives an IGMPv3 report that contains 239 a group record for a destination address in source-specific range that 240 matches one of the types listed below, then it MUST ignore that group 241 record, however, it MUST process other group records within that same 242 report. 244 - Any Current-State Record with MODE_IS_EXCLUDE 246 - A CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Record 248 - A CHANGE_TO_EXCLUDE_MODE Filter-Mode-Change Record 250 3.2. IGMPv3 General Queries 252 IGMPv3 General Queries are used to periodically build the total desired 253 membership state on a subnet. These queries are used for the same 254 purpose in the source-specific address range -- no change in behavior is 255 required. An SSM router sends periodic IGMPv3 General Queries as per 256 the IGMPv3 specification. 258 3.3. IGMPv3 Group Specific Queries 260 IGMPv3 routers that support source-specific multicast MAY send group- 261 specific queries for addresses in the source-specific range, although, 262 in the current IGMPv3 protocol spec, there is no scenario under which 263 this would occur. 265 3.4. IGMPv3 Group-and-Source Specific Queries 267 IGMPv3 Group-and-Source Specific Queries are used to verify that there 268 are no locally attached listeners when a receiver has indicated that it 269 is no longer interested in receiving traffic from a particular (S,G) 270 pair. Group-and-Source Specific Queries are used within the source- 271 specific address range when a router receives a BLOCK_OLD_SOURCES Record 272 for one or more source-specific groups. 274 3.5. IGMPv1/v2 Reports 276 An IGMPv1/v2 report for an address in the source-specific range could be 277 sent by a host that does not support the source-specific model. A 278 router MUST ignore all IGMPv1 and IGMPv2 reports in the source-specific 279 address range and specifically MUST NOT use them to establish IP 280 forwarding state. 282 3.6. IGMPv1/v2 Queries 284 The IGMP querier on a shared-medium network is elected to be the one 285 with lowest source IP address. Therefore, an IGMPv3 router will yield 286 to an IGMPv1 or v2 querier with a lower IP address. IGMPv3 routers that 287 lose the querier election to a lower version router MUST log an error, 288 as per the IGMPv3 specification. However, IGMPv3 routers MUST NOT 289 revert into previous version compatibility mode for the source-specific 290 address range. An IGMPv3 router that loses the querier election to an 291 IGMPv1 or v2 querier SHOULD continue to process source-specific reports 292 in the source-specific address range. 294 3.7. IGMPv2 Leave 296 An IGMPv2 Leave may be received for a source-specific address from a 297 host that does not support the source-specific model. A router MUST 298 ignore all IGMPv2 leaves in the source-specific address range. 300 4. A Note on EXCLUDE Mode 302 [To be removed before going to the IESG.] 304 The IGMPv3 specification formerly indicated that a host should convert 305 to EXCLUDE mode operation when it no longer has enough memory to record 306 INCLUDE mode requests. This would cause SSM working applications to 307 suddenly break when the router runs out of memory for subsequent joins. 308 The IGMPv3 protocol specification was subsequently changed to say that a 309 host MUST NOT transition to EXCLUDE mode as a result of running out of 310 resources. 312 5. Acknowledgments 314 The authors would like to thank Vince Laviano, Nidhi Bhaskar, and Steve 315 Deering and for their input and careful review. 317 6. References 319 [IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group 320 Management Protocol, Version 3," Work in Progress. 322 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, 323 August 1989. 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels," RFC 2119, March 1997. 328 [IANA-ALLOCATION] Internet Assigned Numbers Authority, 329 http://www.isi.edu/in-notes/iana/assignments/multicast-addresses. 331 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," 332 RFC 2236, November 1997. 334 [MSFAPI] Thaler, D., Fenner, B., and Quinn, B. "Socket Interface 335 Extensions for Multicast Source Filters." Work in Progress. 337 [SSM] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP", 338 Work in Progress. 340 7. Author's Address 341 Hugh Holbrook 342 Cisco Systems 343 170 W. Tasman Drive. 344 San Jose, CA 95134 345 holbrook@cisco.com 347 Brad Cain 348 Cereva Networks 349 3 Network Drive 350 Marlborough, MA 01752 351 bcain@cereva.com 353 This document expires September 2, 2001.