idnits 2.17.00 (12 Aug 2021) /tmp/idnits14250/draft-morin-mboned-igmpmld-error-feedback-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 559. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (November 12, 2007) is 5304 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mboned T. Morin 3 Internet-Draft France Telecom - Orange Labs 4 Intended status: Experimental November 12, 2007 5 Expires: May 15, 2008 7 IGMP/MLD Error Feedback 8 draft-morin-mboned-igmpmld-error-feedback-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 15, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes messages and procedures that can optionnaly 42 be implemented in IGMP/MLD Queriers and Hosts, to provide information 43 to terminals on the reason why the IGMP/MLD Querier didn't take into 44 account a Membership Report message. 46 Requirements Language 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [RFC2119]. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. History and problem statement . . . . . . . . . . . . . . . . 3 57 4. Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Procedures on the IGMP/MLD Querier . . . . . . . . . . . . 4 60 5.2. Procedures on the IGMP/MLD Host . . . . . . . . . . . . . 5 61 6. Message encoding . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Base encoding . . . . . . . . . . . . . . . . . . . . . . 6 63 6.2. Protocol to carry error feedback messages . . . . . . . . 6 64 6.2.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.2.2. IGMP/MLD . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Feedback to the application layer . . . . . . . . . . . . . . 8 68 8. Impact on IGMP/MLD proxies and equipments doing IGMP/MLD 69 snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. IGMP/MLD Proxies . . . . . . . . . . . . . . . . . . . . . 9 71 8.2. Equipments doing IGMP/MLD snooping . . . . . . . . . . . . 9 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 12.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 Intellectual Property and Copyright Statements . . . . . . . . . . 13 81 1. Introduction 83 Requirements have been formulated for means to provide mutticast 84 terminals with error feedback when the IGMP/MLD Querier did not or 85 could not process an IGMP/MLD Membership Report message 86 ([I-D.ietf-mboned-maccnt-req], section 4). Operator's experience 87 with IPTV deployments show that introducing such a feedback in IGMP 88 exhanges between terminals and multicast access equipments would help 89 provide a better service (e.g. a liaison between the IETF mboned 90 working group and the DSLForum was made in December 2005 to discuss 91 this issue, but didn't lead to a standardized solution). 93 An examples case is when an IGMP Querier refuses to take into account 94 an IGMP Membership Report because the number of multicast channels 95 would outpass the allowed threshold for the service. Many other 96 examples of the case where an IGMP error feedback channel would be 97 useful are presented in Section 6.3. 99 This document describes new message encodings and the associated 100 procedures, all of which being optional and preserving full backward 101 and forward compatibility, and details the impact on the host API for 102 multicast subscriptions. 104 This document doesn't state yet whether the messages should be 105 carried over IGMP, ICMP or another protocol, but tries to document 106 the pros and cons of the different alternatives, to guide the 107 decision process. 109 2. Terminology 111 The terminology in this document is the terminology used in [RFC3376] 112 and [RFC3810]. 114 For readability, "Querier" and "Host(s)" will be used thoughout this 115 document, in place of "IGMP or MLD Querier" and "IGMP or MLD 116 Host(s)". 118 3. History and problem statement 120 The DSLForum expressed interest for such a feature, which was 121 discussed [magma-archive] in a liaison with the Magma IETF Working 122 group. The specifications described in this document try to address 123 the comments exchanged on the magma WG mailing-list. 125 4. Principle 127 The procedures described in this memo are fully optionnal : their 128 only intent is to carry informative data from the IGMP/MLD Querier to 129 the IGMP/MLD Hosts. 131 Most specifically, the intent is that: 133 o the procedures don't change the state machine of the IGMP Querier 134 or IGMP Host, the information carried is only meant to provide 135 information to the application subscribed to multicast data 137 o an IGMP Host implementing these specifications will behave 138 correctly in the absence of these informations. 140 o the behavior of an IGMP Querier implementing these specifications 141 is unchanged whether or not the hosts implement these specs. 143 Last, these specifications are not meant to carry information about 144 transient errors that the network is supposed to recover from, like 145 network outages. 147 5. Procedures 149 5.1. Procedures on the IGMP/MLD Querier 151 The following procedures introduce a new type of message : the 152 Feedback message. See section xxx for details about message 153 encodings. 155 Using these procedures a Querier can optionally emmit a Feedback 156 message after receiving a Membership Report message that it can not 157 process (see Section 6.3 for example reasons on why a Querier would 158 not process a Membership Report message). 160 The Feedback message carries error type/sub-type field, and 161 information about the group to which the error pertains. Optionally, 162 if IGMPv3/MLDv2 is used, and if the error message pertains to some 163 specific sources, the addresses of the sources to which the error 164 pertains are included in the message. 166 The address to which the Feedback message will be sent is determined 167 as follows: 169 o if IGMPv3/MLDv2 is used and if the sender IP address is not 170 0.0.0.0 or 0000::/32, the address of sender of the IGMP Membership 171 Report is used 173 o else, the group address that was mentioned in the Membership 174 Report message is used 176 The source address MUST be the same address as the address used for 177 Query messages, and the TTL MUST be set to 1. 179 If IGMPv2/MLDv1 is being used, only one feedback message should be 180 sent for a said Membership Report message. 182 If IGMPv3/MLDv2 is being used, only one feedback message should be 183 sent for each (S,G) in the Membership Report message. 185 In any case the amount of Feedback messages sent on a link MUST be 186 rate-limited, 188 5.2. Procedures on the IGMP/MLD Host 190 When a Host receives an Feedback message, it MAY process it. 192 Processing a Feedback message consists in : 194 o MANDATORY checking that the TTL is set to 1 196 o OPTIONALLY checking that the message source address is the address 197 of a known Querier 199 o parsing the Feedback message 201 o determining the network sockets for which the Feedback message is 202 relevant (G is the group address of the Feedback message) 204 * if no source address is included in the Feedback message, the 205 sockets are the sockets that have some active forwarding state 206 related to G (subscribed to G with a non-null include list) 208 * if some source addresses are indicated in the Feedback message, 209 the sockets are the sockets to which traffic from at least one 210 of these sources, and toward G, would be forwarded 212 o notifying these sockets of the error (see Section 7) 214 o OPTIONALLY logging the error and/or doing any local action 215 depending on policy 217 6. Message encoding 219 This document currently only proposes a base encoding for the 220 Feedback message. Discussion is left open on the protocol on which 221 these messages should be piggybacked on, though ICMP and IGMP/MLD are 222 natural candidates. The definitive choice and exact detailed 223 encodings will be detailed in a later revision. 225 6.1. Base encoding 227 Encoding of the error feedback message type, is as follows: 229 o error type (1 byte) 231 o error sub-type (1 bytes) 233 o group address (field length depends on IP protocol revision used) 235 o number of sources in error (possibly zero), followed by the source 236 addresses in error (possibly none, field length depends on IP 237 protocol revision used and number of sources) 239 [ nice ASCII-art might be considered for future revisions ] 241 6.2. Protocol to carry error feedback messages 243 ICMP and IGMP/MLD are candidates for carrying the error feedback 244 message. This section exposes the pros/cons of both alternatives, 245 and ought to be removed once a decision is made on one of them. 247 6.2.1. ICMP 249 The Feedback message could be an ICMP message that would use a new 250 ICMP message type (or possibly reusing existing types and codes). 252 Pros: 254 o ICMP is already used to carry error messages between routers and 255 hosts (e.g.. port unreachable message) 257 o ICMP has an extensible format which could easily be reused for the 258 Feedback function described in this memo 260 o Implementations of network socket APIs already take into account 261 ICMP messages 263 Cons: 265 o ICMP has currently nothing to do with multicast today 267 o some RFC explicitly forbid the sending of ICMP in reaction to 268 receiving multicast packets, and IGMP/MLD Membership Reports are 269 multicast packets ([RFC1122] section 7.2 and 3.2.2, [RFC1812] 270 section 4.3.2.7) (see [fenner-icmp-mcast]). 272 o ICMP messages are (currently) never sent toward multicast 273 addresses, whereas that would be required to send Feedback 274 messages to IGMPv2/MLDv1 hosts 276 6.2.2. IGMP/MLD 278 The Feedback message could be an IGMP or MLD message that would use 279 new IGMP/MLD message types. 281 Pros: 283 o IGMP and MLD are the protocols used for all operations related to 284 multicast subscription 286 Cons: 288 o possibly more work to define the encodings 290 o a new IANA registry might be needed to manage Feedback error codes 292 o definition of how the network socket API will be used to carry the 293 information to the applications has to be defined 295 6.3. Error codes 297 This section describes some proposed based error types: 299 o improper message : the Membership Report message is improper (the 300 group address is not in the 224/0 or FF00::/8 range, or specified 301 sources are improper addresses) 303 o IGMP version not supported by querier 305 o wildcard on an SSM group : IGMPv2 or IGMPv3/MLDv2 with Exclude 306 source filter mode was asked, but the group address is not in the 307 SSM range of the Querier 309 o exclude source filter mode not supported by the Querier 311 o group administratively prohibited 312 o source(s) administratively prohibited 314 o resource limit reached 316 o multicast reception is disabled on the link 318 [ This section will later be completed to include error type numbers 319 ] 321 Remind that the Feedback message is NOT meant to carry information 322 about transient errors that the network is supposed to recover from, 323 like for instance network outages. 325 An IANA registry may be required to manage these and future error 326 codes, and provide third party with the ability to define error codes 327 for IGMP/MLD error feedback. 329 7. Feedback to the application layer 331 [ TBC : working group guidance is sought on how to link these 332 specifications with possibly needed evolution of the POSIX [posix] 333 network socket API ] 335 This section describes how the information from Feedback messages is 336 supplied to applications subscribed to multicast stream, and 337 expecting the reception of multicast datagrams on a socket. 339 A requirement is fully backward compatibility with applications not 340 supporting these specifications : an application not supporting these 341 specifications must not be affected by a Feedback message. For 342 instance, a wrong solution would be to return an error on a read() or 343 recv() call. 345 A second requirement is to allow an application to keep receiving 346 data on a socket, even if some error was reported through a Feedback 347 message, for a group or channel joined on this socket. This is 348 needed, for instance, in two cases : when a socket is used to join 349 multiple distinct group or channels and only one of them is subject 350 to an error ; when a socket is used to join only one multicast group, 351 for which the Querier sends a Feedback message, but there are members 352 for this group sending data on a directly connected link. 354 A proposal is to rely on the use of the MSG_ERRQUEUE flag of the 355 recvmsg()/recvfrom() POSIX calls. This call allows the socket user 356 to retrieve the network errors queued for the socket. Further work 357 is required to fully describe how information from the Feedback 358 message would be mapped in the sock_extended_err structure. 360 Another proposal would be to allow the setsockopt() and 361 set(ipv4)sourcefilter() calls [RFC3678] to return an error. That 362 would require the local network stack to wait for some time after 363 sending a Membership Report message, before being able to return from 364 the setsockopt()/set(ipv4)sourcefilter() call, and would not easily 365 allow to carry detailed information about the specific group or 366 channel in error. Consequently, this approach doesn't seem a viable 367 one. 369 8. Impact on IGMP/MLD proxies and equipments doing IGMP/MLD snooping 371 8.1. IGMP/MLD Proxies 373 To support this Feedback mechanism, an IGMP or MLD proxy [RFC4605] 374 SHOULD send Feedback messages received on its Host side toward its 375 Querier side(s) that have matching multicast memberships. The 376 procedures for sending the Feedback messages are then the same as for 377 a normal Querier, as specified in Section 5: in particular the IGMP/ 378 MLD proxy MUST use its own address as the source address of the 379 Feedback message. 381 A new member of a multicast group already forwarded by the proxy on 382 its Querier side, will have to wait for some time before having a 383 chance to receive a Feedback message : timers will have to trigger 384 before the Querier on the Host side of the proxy sends a Query, 385 causing the proxy to send a Membership Report that may then cause the 386 Querier on the Host side to send a Feedback message, and this 387 Feedback message to be propagated to the new receiver. 389 To quickly provide Feedback messages to receivers on its Querier 390 side, the proxy MAY cache the Feedback messages that it receives on 391 the Host side to later match them with Membership Report messages 392 received on its Querier side, and send relevant Feedback messages in 393 reaction to these. If doing Feedback message caching, the proxy MUST 394 keep only one Feedback message per (S,G) entry or (*,G) entry. It 395 MUST also remove a Feedback message from its cache, if a same 396 Feedback message hasn't been sent in the last <> seconds by the 397 Querier on its Host side. 399 Last, an IGMP/MLD proxy MAY produce its own Feedback messages. In 400 that case it MUST still respect procedures of Section 5. 402 8.2. Equipments doing IGMP/MLD snooping 404 IGMP/MLD snooping equipments are expected to transparently 405 interoperate with the procedures described in this document, given 406 that RFC 4541 section 2.2.1(3) [RFC4541] states that "[a] switch that 407 supports IGMP snooping must flood all unrecognized IGMP messages to 408 all other ports". 410 9. IANA Considerations 412 Request to IANA for ICMP or IGMP code point allocation would 413 expectedly be requested in the future for the messages defined in 414 this document. 416 [Note to RFC Editor: this section may be removed on publication as an 417 RFC.] 419 10. Security Considerations 421 Given that the specifications in this document do not change nor the 422 state machine of the IGMP/MDLD Querier and Host stack, nor the 423 datagrams that will be received by an application, they are not 424 expected to introduce security issues not already existing with IGMP/ 425 MLD or the protocol used to carry the Feedback message. 427 A possible issue would be to have wrong Feedback sent toward 428 multicast applications. Such an issue could arise if spoofed 429 Feedback messages are sent and interpreted by multicast receiver 430 hosts. This issue is mitigated by the fact that IGMP/MLD Hosts MUST 431 check that the TTL of the Feedback messages is 1, and MAY also check 432 the source IP of the Feedback message against a list of known 433 Queriers. 435 Another possible issue is denial of service of the Querier function, 436 that would be due to having the IGMP/MLD Querier be overloaded by 437 Feedback messages to send. This is mitigated by allowing the Querier 438 to rate-limit the flow of Feedback messages. On a LAN, such a rate- 439 limiting would possibly result in some receivers not receiving the 440 feedback message that they would have, which is a form of denial of 441 service, but only on the Feedback function by itself, with no impact 442 on the rest of the multicast group membership control protocol 443 infrastructure. This later type of denial of service might be 444 mitigated by doing rate-limiting based on the source address of the 445 receivers (the source address of the Membership Report triggering the 446 Feedback message); but such mechanism may themselves be subject to 447 weaknesses due to Membership Report spoofing. 449 11. Acknowledgements 451 Acknowledgments go to DSLForum contributors who provided an initial 452 proposal, to IETF participants that participated in the discussion on 453 the magma WG list, from which guidance and inspiration was largely 454 taken. Thank you to Bill Fenner for providing detailed information 455 on issues related to ICMP errors in reaction to multicast datagrams. 457 12. References 459 12.1. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 465 Thyagarajan, "Internet Group Management Protocol, Version 466 3", RFC 3376, October 2002. 468 [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 469 Extensions for Multicast Source Filters", RFC 3678, 470 January 2004. 472 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 473 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 475 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 476 "Considerations for Internet Group Management Protocol 477 (IGMP) and Multicast Listener Discovery (MLD) Snooping 478 Switches", RFC 4541, May 2006. 480 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 481 "Internet Group Management Protocol (IGMP) / Multicast 482 Listener Discovery (MLD)-Based Multicast Forwarding 483 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 485 12.2. Informative References 487 [I-D.ietf-mboned-maccnt-req] 488 He, H., "Requirements for Multicast AAA coordinated 489 between Content Provider(s) and Network Service 490 Provider(s)", draft-ietf-mboned-maccnt-req-05 (work in 491 progress), October 2007. 493 [RFC1122] Braden, R., "Requirements for Internet Hosts - 494 Communication Layers", STD 3, RFC 1122, October 1989. 496 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 497 RFC 1812, June 1995. 499 [fenner-icmp-mcast] 500 "ICMP errors in response to multicast", March 1999, 501 . 503 [magma-archive] 504 "IETF Magma WG mailing-list archives", December 2005, . 508 [posix] "ISO/IEC 9945 Information technology, Portable Operating 509 System Interface (POSIX), Part 1: Base Definitions", 2003. 511 Author's Address 513 Thomas Morin 514 France Telecom - Orange Labs 515 2, avenue Pierre Marzin 516 Lannion 22307 517 France 519 Email: thomas.morin@orange-ftgroup.com 521 Full Copyright Statement 523 Copyright (C) The IETF Trust (2007). 525 This document is subject to the rights, licenses and restrictions 526 contained in BCP 78, and except as set forth therein, the authors 527 retain all their rights. 529 This document and the information contained herein are provided on an 530 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 531 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 532 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 533 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 534 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 535 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 537 Intellectual Property 539 The IETF takes no position regarding the validity or scope of any 540 Intellectual Property Rights or other rights that might be claimed to 541 pertain to the implementation or use of the technology described in 542 this document or the extent to which any license under such rights 543 might or might not be available; nor does it represent that it has 544 made any independent effort to identify any such rights. Information 545 on the procedures with respect to rights in RFC documents can be 546 found in BCP 78 and BCP 79. 548 Copies of IPR disclosures made to the IETF Secretariat and any 549 assurances of licenses to be made available, or the result of an 550 attempt made to obtain a general license or permission for the use of 551 such proprietary rights by implementers or users of this 552 specification can be obtained from the IETF on-line IPR repository at 553 http://www.ietf.org/ipr. 555 The IETF invites any interested party to bring to its attention any 556 copyrights, patents or patent applications, or other proprietary 557 rights that may cover technology that may be required to implement 558 this standard. Please address the information to the IETF at 559 ietf-ipr@ietf.org. 561 Acknowledgment 563 Funding for the RFC Editor function is provided by the IETF 564 Administrative Support Activity (IASA).