idnits 2.17.1 draft-morin-mboned-igmpmld-error-feedback-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 740. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 753. 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 3, 2008) is 5624 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 308 -- Looks like a reference, but probably isn't: '2' on line 311 == Missing Reference: 'M' is mentioned on line 258, but not defined == Missing Reference: 'N' is mentioned on line 318, but not defined == Missing Reference: 'TBD' is mentioned on line 513, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-05 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mboned T. Morin, Ed. 3 Internet-Draft France Telecom - Orange Labs 4 Intended status: Experimental B. Haberman 5 Expires: May 7, 2009 The Johns Hopkins University, 6 Applied Physics Laboratory 7 November 3, 2008 9 IGMP/MLD Error Feedback 10 draft-morin-mboned-igmpmld-error-feedback-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 7, 2009. 37 Abstract 39 This document describes messages and procedures that can optionally 40 be implemented in IGMP/MLD Queriers and Hosts, to provide information 41 to multicast receivers on the reason why the IGMP/MLD Querier didn't 42 take into account a Membership Report message. 44 Requirements Language 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [RFC2119]. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. History and problem statement . . . . . . . . . . . . . . . . 3 55 4. Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5.1. Procedures on the IGMP/MLD Querier . . . . . . . . . . . . 4 58 5.2. Procedures on the IGMP/MLD Host . . . . . . . . . . . . . 5 59 6. Message encodings . . . . . . . . . . . . . . . . . . . . . . 6 60 6.1. Feedback message . . . . . . . . . . . . . . . . . . . . . 6 61 6.2. Error codes . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Feedback to the application layer . . . . . . . . . . . . . . 9 63 8. Impact on IGMP/MLD proxies and equipments doing IGMP/MLD 64 snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 8.1. IGMP/MLD Proxies . . . . . . . . . . . . . . . . . . . . . 11 66 8.2. Equipments doing IGMP/MLD snooping . . . . . . . . . . . . 12 67 9. IGMP/MLD Hosts stacks not implementing the Feedback 68 mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 74 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Appendix A. Protocol to carry error feedback messages . . . . . . 15 76 A.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 A.2. IGMP/MLD . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 79 Intellectual Property and Copyright Statements . . . . . . . . . . 17 81 1. Introduction 83 Requirements have been formulated for means to provide multicast 84 receivers 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 exchanges between multicast receivers and multicast routing 89 equipments would help provide a better service (e.g. a liaison 90 between the IETF mboned working group and the DSLForum was made in 91 December 2005 to discuss this issue, but didn't lead to a 92 standardized solution). 94 An examples case is when an IGMP Querier refuses to take into account 95 an IGMP Membership Report because the number of multicast channels 96 would surpass the allowed threshold for the service. Many other 97 examples of the case where an IGMP error feedback channel would be 98 useful are presented in Section 6.2. 100 This document describes new message encodings and the associated 101 procedures, all of which being optional and preserving full backward 102 and forward compatibility, and details the impact on the host API for 103 multicast subscriptions. 105 This document doesn't state yet whether the messages should be 106 carried over IGMP, ICMP or another protocol, but tries to document 107 the pros and cons of the different alternatives, to guide the 108 decision process. 110 2. Terminology 112 The terminology in this document is the terminology used in [RFC3376] 113 and [RFC3810]. 115 For readability, "Querier" and "Host(s)" will be used throughout this 116 document, in place of "IGMP or MLD Querier" and "IGMP or MLD 117 Host(s)". 119 3. History and problem statement 121 The DSLForum expressed interest for such a feature, which was 122 discussed [magma-archive] in a liaison with the Magma IETF Working 123 group. The specifications described in this document try to address 124 the comments exchanged on the magma WG mailing-list. 126 4. Principle 128 The procedures described in this memo are fully optional : their only 129 intent is to carry informative data from the Querier to the Hosts. 131 Most specifically, the intent is that: 133 o the procedures don't change the state machine of the Querier or 134 Host, the information carried is only meant to provide information 135 to the application subscribed to multicast data 137 o a Host implementing these specifications will behave correctly in 138 the absence of these informations. 140 o the behavior of a Querier implementing these specifications is 141 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 Section 6 for details about message 153 encodings. 155 Using these procedures a Querier can OPTIONALLY emmit a Feedback 156 message after receiving an IGMP or MLD Membership Report message that 157 it can not process (see Section 6.2 for example reasons on why a 158 Querier would 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 0::0), the address of the sender of the Membership 171 Report is used 173 o else, the group address specified in the Membership Report message 174 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, not more than one Feedback message 180 should be sent for a said Membership Report message. 182 If IGMPv3/MLDv2 is being used, not more than one Feedback message 183 should be sent for each (S,G) pair present in the Membership Report 184 message. Multiple feedback message MAY be sent if the group record 185 in error contains multiple source addresses. Multiple feedback 186 message SHOULD be sent if the relevant error codes are different for 187 the sources/groups of the Report message. 189 In any case the amount of Feedback messages sent on a link MUST be 190 rate-limited. 192 5.2. Procedures on the IGMP/MLD Host 194 When a Host receives an Feedback message, it MAY process it. 196 Processing a Feedback message consists in : 198 o MANDATORY checking that the TTL is set to 1 200 o OPTIONALLY checking that the message source address is the address 201 of a known Querier 203 o parsing the Feedback message 205 o determining the network sockets for which the Feedback message is 206 relevant (G is the group address of the Feedback message) 208 * if no source address is included in the Feedback message, the 209 sockets are the sockets that have some active forwarding state 210 related to G (subscribed to G with a non-null include list) 212 * if some source addresses are indicated in the Feedback message, 213 the sockets are the sockets to which traffic from at least one 214 of these sources, and toward G, would be forwarded 216 o notifying these sockets of the error (see Section 7) 218 o OPTIONALLY logging the error and/or doing any local action 219 depending on policy 221 6. Message encodings 223 6.1. Feedback message 225 The Feedback message is a subtype of IGMP message when used as a 226 feedback to an IGMP message, and a subtype of ICMPv6 when used as a 227 feedback to an MLD message. It contains an error code, the multicast 228 group address in error (optional), and the source addresses in error 229 (optional). 231 The encoding is common to the two types of messages (except the 232 length of fields specifying addresses). 233 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Type = XXX | Code | Checksum | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Reserved | Number of Group Records (M) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 . . 242 . Group Record [1] . 243 . . 244 | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | 247 . . 248 . Group Record [2] . 249 . . 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | . | 253 . . . 254 | . | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 . . 258 . Group Record [M] . 259 . . 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Fields: 265 Type: Identifies this message as a Feedback message. Currently 266 using: 268 * in the case of IPv6/MLD: 0xYY (currently using value 200 as 269 defined in RFC 4443 "private experimentation value", until 270 another value is registered with IANA). 272 * in the case of IPv4/IGMP: 0xZZ (currently using 0xF2, in the 273 "Reserved for experimentation" range, until another value is 274 registered with IANA) 276 Code: One byte, gives additional information about the error that 277 triggered the feedback message. The possible values are described 278 in Section 6.2. 280 Checksum: The standard IGMP checksum. 282 Reserved: Reserved for future use. Set to zero on transmission; 283 ignored upon receipt. 285 Number of Group Records: Indicates the number of group records. 287 The Feedback message MUST at least include one group record. 289 It MUST NOT include more than one group record if the Feedback 290 message is to be sent toward a multicast group address (see section 291 Section 5). 293 o the message that triggered the Feedback message is IGMPv3 or MLDv2 294 and the group record that triggered the error contains no source 295 address 297 o the message that triggered the Feedback message is IGMPv2 or MLDv1 298 and the message contains no source address 300 Group record encoding: 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Multicast Group Address | 304 ~ ~ 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Reserved | Number of Sources (N) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Source Address [1] | 309 ~ ~ 310 +--- ---+ 311 | Source Address [2] | 312 ~ ~ 313 +--- ---+ 314 . . . 315 . . . 316 ~ ~ 317 +--- ---+ 318 | Source Address [N] | 319 ~ ~ 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Fields: 324 Multicast Group Address: IPv4 multicast group address of the group 325 in error. Possibly set to all zeros. Contains an IPv4 address in 326 the case of IPv4/IGMP, and an IPv6 address in the case of IPv6/ 327 MLD. 329 Reserved: Reserved for future use. Set to zero on transmission; 330 ignored upon receipt. 332 Number of Sources: Indicates the number of sources in error. 333 Possibly set to zero. 335 Source Address [1..n]: Addresses of the multicast sources in error. 336 In the case of IPv4/IGMP, all these fields are 32-bit fields 337 containing IPv4 addresses. In the case of IPv6/MLD, all these 338 fields are 128-bit fields containing IPv6 addresses. 340 The Multicast Group Address field MAY be set to all zeros (for 341 instance, if the error is not specific to a said multicast group). 343 A group record MAY include zero Source Address (it can be the case, 344 for instance, for a feedback that is not specific to particular 345 sources, or that relates to an ASM subscription). It MUST NOT 346 include any source in the following cases: 348 o the message that triggered the Feedback message is IGMPv3 or MLDv2 349 and the group record that triggered the error contains no source 350 address 352 o the message that triggered the Feedback message is IGMPv2 or MLDv1 354 6.2. Error codes 356 This section describes some proposed error codes: 358 0x01: improper message : the Membership Report message is improper 359 (the group address is not in the 224/0 or FF00::/8 range, or 360 specified sources are improper addresses) 362 0x02: The IGMP or MLD version of the Report message is not supported 363 by querier 365 0x03: wildcard on an SSM group : IGMPv2 or IGMPv3/MLDv2 with an 366 Exclude source filter mode was used in the Report, but the group 367 address is not in the SSM range of the Querier 369 0x04: exclude source filter mode not supported by the Querier 371 0x05: group administratively prohibited 373 0x06: source(s) administratively prohibited 375 0x07: a resource limit was reached 377 0x08: multicast reception is disabled on the link 379 0x09: multicast routing protocol issue 381 Remember that the Feedback message is NOT meant to carry information 382 about transient errors that the network is supposed to recover from, 383 like for instance network outages. 385 7. Feedback to the application layer 387 This section gives an example of how the information from Feedback 388 messages is supplied to applications subscribed to multicast streams, 389 and which expect the reception of multicast datagrams on a socket, 390 based on Linux extensions to the POSIX [posix] network socket API. 392 A first requirement is full backward compatibility with applications 393 not supporting these specifications : an application not supporting 394 these specifications must not be affected by a Feedback message. For 395 instance, a wrong solution would be to return an error on a read() or 396 recv() call. 398 A second requirement is to allow an application to keep receiving 399 data on a socket, even if some error was reported through a Feedback 400 message, for a group or channel joined on this socket. This is 401 needed, for instance, in two cases : when a socket is used to join 402 multiple distinct group or channels and only one of them is subject 403 to an error ; when a socket is used to join only one multicast group, 404 for which the Querier sends a Feedback message, but there are members 405 for this group sending data on a directly connected link. 407 The proposed solution is to rely on the use of the MSG_ERRQUEUE flag 408 of the recvmsg()/recvfrom() POSIX calls. This call allows the socket 409 user to retrieve the network errors queued for the socket. 411 The MLD component receiving an MLD Feedback message containing error 412 condition reports the error to the application via the MSG_ERRQUEUE 413 flag in the recvmsg()/recvfrom() calls. The MSG_ERRQUEUE flag 414 indicates the presence of a sock_extended_err data structure. When 415 the sock_extended_err data structure is passed to the application, 416 the ee_origin field is set to 3 (SO_EE_ORIGIN_ICMP6) in the case of 417 an MLD Feedback message, and XX (SO_EE_ORIGIN_YYYY) in the case of an 418 IGMP Feedback message [XX and YYY is to be determined in compliance 419 with the relevant standard, 4 and SO_EE_ORIGIN_IGMP are proposed as 420 interim values]. The Type and Code fields from the MLD Feedback 421 message are copied into the ee_type and ee_code field of the 422 sock_extended_err data structure. 424 The addresses of the multicast group and sources in error can be 425 retrieved as follows: 427 o in the IPv4 case, the group address and source address are stored, 428 respectively, in the ee_info and ee_data fields, 430 o the group address and source address can be retrieved, in all 431 cases, by calling functions returning a sockaddr pointer and which 432 take into argument a sock_extended_err pointer (similarly as 433 SOCK_EE_OFFENDER) and called SOCK_EE_MCAST_FEEDBACK_GRP and 434 SOCK_EE_MCAST_FEEDBACK_SRC 436 If the Feedback contains multiple sources addresses, a 437 sock_extended_err will be added to the message queue for each such 438 sources. 440 An application receiving a sock_extended_err message from the MLD 441 component MUST NOT terminate the multicast subscription to the group 442 or source/group address in error, except possibly if it can be 443 ascertained that the Feedback message comes from a legitimate Querier 444 (e.g. thanks to a mechanism like SEND [RFC3971]), and if multicast 445 traffic for the said group or channel is not expected from any host 446 attached to a directly-connected link. 448 ( Another proposal would be to allow the setsockopt() and 449 set(ipv4)sourcefilter() calls [RFC3678] to return an error. That 450 would require the local network stack to wait for some time after 451 sending a Membership Report message, before being able to return from 452 the setsockopt()/set(ipv4)sourcefilter() call, and would not easily 453 allow to carry detailed information about the specific group or 454 channel in error. Consequently, this approach doesn't seem a viable 455 one. ) 457 8. Impact on IGMP/MLD proxies and equipments doing IGMP/MLD snooping 459 8.1. IGMP/MLD Proxies 461 To support this Feedback mechanism, an IGMP or MLD proxy [RFC4605] 462 SHOULD send Feedback messages received on its Host side toward its 463 Querier side(s) that have matching multicast memberships. The 464 procedures for sending the Feedback messages are then the same as for 465 a normal Querier, as specified in Section 5: in particular the IGMP/ 466 MLD proxy MUST use its own address as the source address of the 467 Feedback message. 469 A new member of a multicast group already forwarded by the proxy on 470 its Querier side, will have to wait for some time before having a 471 chance to receive a Feedback message : timers will have to trigger 472 before the Querier on the Host side of the proxy sends a Query, 473 causing the proxy to send a Membership Report that may then cause the 474 Querier on the Host side to send a Feedback message, and this 475 Feedback message to be propagated to the new receiver. 477 To quickly provide Feedback messages to receivers on its Querier 478 side, the proxy MAY cache the information in the Feedback messages 479 that it receives on the Host side, so that it can later reuse this 480 information to eventually send feedback to Membership Report messages 481 received on its Querier side. When such Feedback information caching 482 is used, the proxy MUST keep only one Feedback message per (S,G) 483 entry or (*,G) entry. On reception of a Report message on its 484 Querier side, it shall then lookup in its cache the most relevant 485 feedback information. A Feedback information MUST be removed from 486 the cache if no Feedback message containing it is received by the 487 Querier on its Host side interface, seconds after a corresponding 488 Report was sent. 490 Last, an IGMP/MLD proxy MAY produce its own Feedback messages. In 491 that case it MUST still respect procedures of Section 5. 493 8.2. Equipments doing IGMP/MLD snooping 495 IGMP/MLD snooping equipments are expected to transparently 496 interoperate with the procedures described in this document, given 497 that RFC 4541 section 2.2.1(3) [RFC4541] states that "[a] switch that 498 supports IGMP snooping must flood all unrecognized IGMP messages to 499 all other ports". 501 9. IGMP/MLD Hosts stacks not implementing the Feedback mechanism 503 To allow applications running on an IGMP/MLD Host, whose networking 504 stack or API does not implement the Feedback mechanism described in 505 this spec, it is proposed that IGMP/MLD Querier implementing this 506 specification can, when configured to do so, send each Feedback 507 message twice : once with the encoding described in these 508 specifications, and another time encapsulated in a UDP packet. 510 The UDP message uses port xxx [TBD], with a payload identical to the 511 IGMP or MLD Feedback message, except that the checksum is set to zero 512 (the UDP message having its own checksum). The message is sent to 513 the welknown link local multicast group adress 224.0.0.z [TBD], so 514 that reception by multiple applications running on a same host is 515 possible. The TTL used MUST be one. 517 10. IANA Considerations 519 Request to IANA for IGMP and ICMPv6 type allocation will be needed 520 for the messages defined in this document. 522 Request to IANA for a UDP port and a link local multicast group 523 address will be needed. 525 [Whether or not it is needed to define a registry for the error codes 526 used in IGMP/MLD Feedback messages will be later determined.] 528 [Note to RFC Editor: this section may be removed on publication as an 529 RFC.] 531 11. Security Considerations 533 Given that the specifications in this document do not change nor the 534 state machine of the IGMP/MDLD Querier and Host stack, nor the 535 datagrams that will be received by an application, they are not 536 expected to introduce security issues not already existing with IGMP/ 537 MLD or the protocol used to carry the Feedback message. 539 A possible issue would be to have wrong feedback sent toward 540 multicast applications. Such an issue could arise if spoofed 541 Feedback messages are sent and interpreted by multicast receiver 542 hosts. This issue is mitigated by the fact that IGMP/MLD Hosts MUST 543 check that the TTL of the Feedback messages is 1. 545 The case where such a verification does not protect from spoofing is 546 the case of LANs. In that case, spoofing is typically hard to 547 prevent and some level of trust in other hosts present on a LAN is 548 required. Checking that the source IP of the Feedback message 549 against a list of known Queriers can be minor an improvement in these 550 contexts. 552 Another possible issue is denial of service of the Querier function, 553 that would be due to having the IGMP/MLD Querier be overloaded by 554 Feedback messages to send. This is mitigated by allowing the Querier 555 to rate-limit the flow of Feedback messages. On a LAN, such a rate- 556 limiting would possibly result in some receivers not receiving the 557 feedback message that they would have, which is a form of denial of 558 service, but only on the Feedback function by itself, with no impact 559 on the rest of the multicast group membership control protocol 560 infrastructure. This later type of denial of service might be 561 mitigated by doing rate-limiting based on the source address of the 562 receivers (the source address of the Membership Report triggering the 563 Feedback message); but such mechanism may themselves be subject to 564 weaknesses due to Membership Report spoofing. 566 12. Acknowledgements 568 Acknowledgments go to DSLForum contributors who provided an initial 569 proposal, to IETF participants that participated in the discussion on 570 the magma WG list, from which guidance and inspiration was largely 571 taken. Thank you to Bill Fenner for providing detailed information 572 on issues related to ICMP errors in reaction to multicast datagrams. 574 Thanks to Toerless Eckert for his inputs and who offered a suggestion 575 on how to handle application running on hosts not implementing the 576 Feedback mechanism. 578 Message encodings are largely inspired from Report message encodings 579 found in[RFC3376]. 581 13. References 583 13.1. Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, March 1997. 588 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 589 Thyagarajan, "Internet Group Management Protocol, Version 590 3", RFC 3376, October 2002. 592 [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 593 Extensions for Multicast Source Filters", RFC 3678, 594 January 2004. 596 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 597 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 599 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 600 "Considerations for Internet Group Management Protocol 601 (IGMP) and Multicast Listener Discovery (MLD) Snooping 602 Switches", RFC 4541, May 2006. 604 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 605 "Internet Group Management Protocol (IGMP) / Multicast 606 Listener Discovery (MLD)-Based Multicast Forwarding 607 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 609 13.2. Informative References 611 [I-D.ietf-mboned-maccnt-req] 612 He, H., "Requirements for Multicast AAA coordinated 613 between Content Provider(s) and Network Service 614 Provider(s)", draft-ietf-mboned-maccnt-req-05 (work in 615 progress), October 2007. 617 [RFC1122] Braden, R., "Requirements for Internet Hosts - 618 Communication Layers", STD 3, RFC 1122, October 1989. 620 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 621 RFC 1812, June 1995. 623 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 624 Neighbor Discovery (SEND)", RFC 3971, March 2005. 626 [fenner-icmp-mcast] 627 "ICMP errors in response to multicast", March 1999, 628 . 630 [magma-archive] 631 "IETF Magma WG mailing-list archives", December 2005, . 635 [posix] ISO, "ISO/IEC 9945 Information technology, Portable 636 Operating System Interface (POSIX), Part 1: Base 637 Definitions", 2003. 639 Appendix A. Protocol to carry error feedback messages 641 ICMP and IGMP/MLD were possible candidates for carrying the Feedback 642 message. This section exposes the pros/cons of both alternatives, 643 and ought to be removed once a decision is made on one of them. 645 A.1. ICMP 647 The Feedback message could be an ICMP message that would use a new 648 ICMP message type (or possibly reusing existing types and codes). 650 Pros: 652 o ICMP is already used to carry error messages between routers and 653 hosts (e.g.. port unreachable message) 655 o ICMP has an extensible format which could easily be reused for the 656 Feedback function described in this memo 658 o Implementations of network socket APIs already take into account 659 ICMP messages 661 Cons: 663 o ICMP has currently nothing to do with multicast today 665 o some RFC explicitly forbid the sending of ICMP in reaction to 666 receiving multicast packets, and IGMP/MLD Membership Reports are 667 multicast packets ([RFC1122] section 7.2 and 3.2.2, [RFC1812] 668 section 4.3.2.7) (see [fenner-icmp-mcast]) 670 o ICMP messages are (currently) never sent toward multicast 671 addresses, whereas that would be required to send Feedback 672 messages to IGMPv2/MLDv1 hostsSo we may say that the generic 673 argument is that the restriction for ICMP ; this has lead to 674 practical issues to integrate this approach into existing stacks, 675 because of the need to work around sanity checks 677 A.2. IGMP/MLD 679 The Feedback message could be an IGMP or MLD message that would use 680 new IGMP/MLD message types. 682 Pros: 684 o IGMP and MLD are the protocols used for all operations related to 685 multicast subscription 687 Cons: 689 o possibly more work to define the encodings 691 o a new IANA registry might be needed to manage Feedback error codes 693 o definition of how the network socket API will be used to carry the 694 information to the applications has to be defined 696 Authors' Addresses 698 Thomas Morin (editor) 699 France Telecom - Orange Labs 700 2, avenue Pierre Marzin 701 Lannion 22307 702 France 704 Email: thomas.morin@orange-ftgroup.com 706 Brian Haberman 707 The Johns Hopkins University, Applied Physics Laboratory 708 11100 Johns Hopkins Road 709 Laurel, MD 20723-6099 710 US 712 Phone: +1 443 778 1319 713 Email: brian@innovationslab.net 715 Full Copyright Statement 717 Copyright (C) The IETF Trust (2008). 719 This document is subject to the rights, licenses and restrictions 720 contained in BCP 78, and except as set forth therein, the authors 721 retain all their rights. 723 This document and the information contained herein are provided on an 724 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 725 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 726 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 727 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 728 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 729 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 731 Intellectual Property 733 The IETF takes no position regarding the validity or scope of any 734 Intellectual Property Rights or other rights that might be claimed to 735 pertain to the implementation or use of the technology described in 736 this document or the extent to which any license under such rights 737 might or might not be available; nor does it represent that it has 738 made any independent effort to identify any such rights. Information 739 on the procedures with respect to rights in RFC documents can be 740 found in BCP 78 and BCP 79. 742 Copies of IPR disclosures made to the IETF Secretariat and any 743 assurances of licenses to be made available, or the result of an 744 attempt made to obtain a general license or permission for the use of 745 such proprietary rights by implementers or users of this 746 specification can be obtained from the IETF on-line IPR repository at 747 http://www.ietf.org/ipr. 749 The IETF invites any interested party to bring to its attention any 750 copyrights, patents or patent applications, or other proprietary 751 rights that may cover technology that may be required to implement 752 this standard. Please address the information to the IETF at 753 ietf-ipr@ietf.org.