< draft-morin-mboned-igmpmld-error-feedback-00.txt   draft-morin-mboned-igmpmld-error-feedback-01.txt >
mboned T. Morin mboned T. Morin, Ed.
Internet-Draft France Telecom - Orange Labs Internet-Draft France Telecom - Orange Labs
Intended status: Experimental November 12, 2007 Intended status: Experimental B. Haberman
Expires: May 15, 2008 Expires: January 12, 2009 The Johns Hopkins University,
Applied Physics Laboratory
July 11, 2008
IGMP/MLD Error Feedback IGMP/MLD Error Feedback
draft-morin-mboned-igmpmld-error-feedback-00 draft-morin-mboned-igmpmld-error-feedback-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 15, 2008. This Internet-Draft will expire on January 12, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes messages and procedures that can optionnaly This document describes messages and procedures that can optionally
be implemented in IGMP/MLD Queriers and Hosts, to provide information be implemented in IGMP/MLD Queriers and Hosts, to provide information
to terminals on the reason why the IGMP/MLD Querier didn't take into to multicast receivers on the reason why the IGMP/MLD Querier didn't
account a Membership Report message. take into account a Membership Report message.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. History and problem statement . . . . . . . . . . . . . . . . 3 3. History and problem statement . . . . . . . . . . . . . . . . 3
4. Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Procedures on the IGMP/MLD Querier . . . . . . . . . . . . 4 5.1. Procedures on the IGMP/MLD Querier . . . . . . . . . . . . 4
5.2. Procedures on the IGMP/MLD Host . . . . . . . . . . . . . 5 5.2. Procedures on the IGMP/MLD Host . . . . . . . . . . . . . 5
6. Message encoding . . . . . . . . . . . . . . . . . . . . . . . 6 6. Message encodings . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Base encoding . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Feedback message . . . . . . . . . . . . . . . . . . . . . 6
6.2. Protocol to carry error feedback messages . . . . . . . . 6 6.2. Error codes . . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Feedback to the application layer . . . . . . . . . . . . . . 9
6.2.2. IGMP/MLD . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 7
7. Feedback to the application layer . . . . . . . . . . . . . . 8
8. Impact on IGMP/MLD proxies and equipments doing IGMP/MLD 8. Impact on IGMP/MLD proxies and equipments doing IGMP/MLD
snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. IGMP/MLD Proxies . . . . . . . . . . . . . . . . . . . . . 9 8.1. IGMP/MLD Proxies . . . . . . . . . . . . . . . . . . . . . 11
8.2. Equipments doing IGMP/MLD snooping . . . . . . . . . . . . 9 8.2. Equipments doing IGMP/MLD snooping . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IGMP/MLD Hosts stacks not implementing the Feedback
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 13 13.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Protocol to carry error feedback messages . . . . . . 15
A.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.2. IGMP/MLD . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
Requirements have been formulated for means to provide mutticast Requirements have been formulated for means to provide multicast
terminals with error feedback when the IGMP/MLD Querier did not or receivers with error feedback when the IGMP/MLD Querier did not or
could not process an IGMP/MLD Membership Report message could not process an IGMP/MLD Membership Report message
([I-D.ietf-mboned-maccnt-req], section 4). Operator's experience ([I-D.ietf-mboned-maccnt-req], section 4). Operator's experience
with IPTV deployments show that introducing such a feedback in IGMP with IPTV deployments show that introducing such a feedback in IGMP
exhanges between terminals and multicast access equipments would help exchanges between multicast receivers and multicast routing
provide a better service (e.g. a liaison between the IETF mboned equipments would help provide a better service (e.g. a liaison
working group and the DSLForum was made in December 2005 to discuss between the IETF mboned working group and the DSLForum was made in
this issue, but didn't lead to a standardized solution). December 2005 to discuss this issue, but didn't lead to a
standardized solution).
An examples case is when an IGMP Querier refuses to take into account An examples case is when an IGMP Querier refuses to take into account
an IGMP Membership Report because the number of multicast channels an IGMP Membership Report because the number of multicast channels
would outpass the allowed threshold for the service. Many other would surpass the allowed threshold for the service. Many other
examples of the case where an IGMP error feedback channel would be examples of the case where an IGMP error feedback channel would be
useful are presented in Section 6.3. useful are presented in Section 6.2.
This document describes new message encodings and the associated This document describes new message encodings and the associated
procedures, all of which being optional and preserving full backward procedures, all of which being optional and preserving full backward
and forward compatibility, and details the impact on the host API for and forward compatibility, and details the impact on the host API for
multicast subscriptions. multicast subscriptions.
This document doesn't state yet whether the messages should be This document doesn't state yet whether the messages should be
carried over IGMP, ICMP or another protocol, but tries to document carried over IGMP, ICMP or another protocol, but tries to document
the pros and cons of the different alternatives, to guide the the pros and cons of the different alternatives, to guide the
decision process. decision process.
2. Terminology 2. Terminology
The terminology in this document is the terminology used in [RFC3376] The terminology in this document is the terminology used in [RFC3376]
and [RFC3810]. and [RFC3810].
For readability, "Querier" and "Host(s)" will be used thoughout this For readability, "Querier" and "Host(s)" will be used throughout this
document, in place of "IGMP or MLD Querier" and "IGMP or MLD document, in place of "IGMP or MLD Querier" and "IGMP or MLD
Host(s)". Host(s)".
3. History and problem statement 3. History and problem statement
The DSLForum expressed interest for such a feature, which was The DSLForum expressed interest for such a feature, which was
discussed [magma-archive] in a liaison with the Magma IETF Working discussed [magma-archive] in a liaison with the Magma IETF Working
group. The specifications described in this document try to address group. The specifications described in this document try to address
the comments exchanged on the magma WG mailing-list. the comments exchanged on the magma WG mailing-list.
4. Principle 4. Principle
The procedures described in this memo are fully optionnal : their The procedures described in this memo are fully optional : their only
only intent is to carry informative data from the IGMP/MLD Querier to intent is to carry informative data from the Querier to the Hosts.
the IGMP/MLD Hosts.
Most specifically, the intent is that: Most specifically, the intent is that:
o the procedures don't change the state machine of the IGMP Querier o the procedures don't change the state machine of the Querier or
or IGMP Host, the information carried is only meant to provide Host, the information carried is only meant to provide information
information to the application subscribed to multicast data to the application subscribed to multicast data
o an IGMP Host implementing these specifications will behave o a Host implementing these specifications will behave correctly in
correctly in the absence of these informations. the absence of these informations.
o the behavior of an IGMP Querier implementing these specifications o the behavior of a Querier implementing these specifications is
is unchanged whether or not the hosts implement these specs. unchanged whether or not the hosts implement these specs.
Last, these specifications are not meant to carry information about Last, these specifications are not meant to carry information about
transient errors that the network is supposed to recover from, like transient errors that the network is supposed to recover from, like
network outages. network outages.
5. Procedures 5. Procedures
5.1. Procedures on the IGMP/MLD Querier 5.1. Procedures on the IGMP/MLD Querier
The following procedures introduce a new type of message : the The following procedures introduce a new type of message : the
Feedback message. See section xxx for details about message Feedback message. See section Section 6 for details about message
encodings. encodings.
Using these procedures a Querier can optionally emmit a Feedback Using these procedures a Querier can OPTIONALLY emmit a Feedback
message after receiving a Membership Report message that it can not message after receiving an IGMP or MLD Membership Report message that
process (see Section 6.3 for example reasons on why a Querier would it can not process (see Section 6.2 for example reasons on why a
not process a Membership Report message). Querier would not process a Membership Report message).
The Feedback message carries error type/sub-type field, and The Feedback message carries error type/sub-type field, and
information about the group to which the error pertains. Optionally, information about the group to which the error pertains. Optionally,
if IGMPv3/MLDv2 is used, and if the error message pertains to some if IGMPv3/MLDv2 is used, and if the error message pertains to some
specific sources, the addresses of the sources to which the error specific sources, the addresses of the sources to which the error
pertains are included in the message. pertains are included in the message.
The address to which the Feedback message will be sent is determined The address to which the Feedback message will be sent is determined
as follows: as follows:
o if IGMPv3/MLDv2 is used and if the sender IP address is not o if IGMPv3/MLDv2 is used (and if the sender IP address is not
0.0.0.0 or 0000::/32, the address of sender of the IGMP Membership 0.0.0.0 or 0::0), the address of the sender of the Membership
Report is used Report is used
o else, the group address that was mentioned in the Membership o else, the group address specified in the Membership Report message
Report message is used is used
The source address MUST be the same address as the address used for The source address MUST be the same address as the address used for
Query messages, and the TTL MUST be set to 1. Query messages, and the TTL MUST be set to 1.
If IGMPv2/MLDv1 is being used, only one feedback message should be If IGMPv2/MLDv1 is being used, not more than one Feedback message
sent for a said Membership Report message. should be sent for a said Membership Report message.
If IGMPv3/MLDv2 is being used, only one feedback message should be If IGMPv3/MLDv2 is being used, multiple feedback message MAY be sent
sent for each (S,G) in the Membership Report message. if the group record of the IGMP/MLD message that triggered the error
contained multiple source addresses.
In any case the amount of Feedback messages sent on a link MUST be In any case the amount of Feedback messages sent on a link MUST be
rate-limited, rate-limited,
5.2. Procedures on the IGMP/MLD Host 5.2. Procedures on the IGMP/MLD Host
When a Host receives an Feedback message, it MAY process it. When a Host receives an Feedback message, it MAY process it.
Processing a Feedback message consists in : Processing a Feedback message consists in :
skipping to change at page 6, line 5 skipping to change at page 6, line 5
* if some source addresses are indicated in the Feedback message, * if some source addresses are indicated in the Feedback message,
the sockets are the sockets to which traffic from at least one the sockets are the sockets to which traffic from at least one
of these sources, and toward G, would be forwarded of these sources, and toward G, would be forwarded
o notifying these sockets of the error (see Section 7) o notifying these sockets of the error (see Section 7)
o OPTIONALLY logging the error and/or doing any local action o OPTIONALLY logging the error and/or doing any local action
depending on policy depending on policy
6. Message encoding 6. Message encodings
This document currently only proposes a base encoding for the
Feedback message. Discussion is left open on the protocol on which
these messages should be piggybacked on, though ICMP and IGMP/MLD are
natural candidates. The definitive choice and exact detailed
encodings will be detailed in a later revision.
6.1. Base encoding
Encoding of the error feedback message type, is as follows: 6.1. Feedback message
o error type (1 byte) The Feedback message is a subtype of IGMP message when used as a
feedback to an IGMP message, and a subtype of ICMPv6 when used as a
feedback to an MLD message. It contains an error code, the multicast
group address in error (optional), and the source addresses in error
(optional).
o error sub-type (1 bytes) The encoding is common to the two types of messages (except the
length of fields specifying addresses).
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = XXX | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number of Group Records (M) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Group Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o group address (field length depends on IP protocol revision used) Fields:
o number of sources in error (possibly zero), followed by the source Type: Identifies this message as a Feedback message. Currently
addresses in error (possibly none, field length depends on IP using:
protocol revision used and number of sources)
[ nice ASCII-art might be considered for future revisions ] * in the case of IPv6/MLD: 0xYY (currently using value 200 as
defined in RFC 4443 "private experimentation value", until
another value is registered with IANA).
6.2. Protocol to carry error feedback messages * in the case of IPv4/IGMP: 0xZZ (currently using 0xF2, in the
"Reserved for experimentation" range, until another value is
registered with IANA)
ICMP and IGMP/MLD are candidates for carrying the error feedback Code: One byte, gives additional information about the error that
message. This section exposes the pros/cons of both alternatives, triggered the feedback message. The possible values are described
and ought to be removed once a decision is made on one of them. in Section 6.2.
6.2.1. ICMP Checksum: The standard IGMP checksum.
The Feedback message could be an ICMP message that would use a new Reserved: Reserved for future use. Set to zero on transmission;
ICMP message type (or possibly reusing existing types and codes). ignored upon receipt.
Pros: Number of Group Records: Indicates the number of group records.
o ICMP is already used to carry error messages between routers and The Feedback message MUST at least include one group record.
hosts (e.g.. port unreachable message)
o ICMP has an extensible format which could easily be reused for the It MUST NOT include more than one group record if the Feedback
Feedback function described in this memo message is to be sent toward a multicast group address (see section
Section 5).
o Implementations of network socket APIs already take into account o the message that triggered the Feedback message is IGMPv3 or MLDv2
ICMP messages and the group record that triggered the error contains no source
address
Cons: o the message that triggered the Feedback message is IGMPv2 or MLDv1
and the message contains no source address
o ICMP has currently nothing to do with multicast today Group record encoding:
o some RFC explicitly forbid the sending of ICMP in reaction to +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
receiving multicast packets, and IGMP/MLD Membership Reports are | Multicast Group Address |
multicast packets ([RFC1122] section 7.2 and 3.2.2, [RFC1812] ~ ~
section 4.3.2.7) (see [fenner-icmp-mcast]). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address [1] |
~ ~
+--- ---+
| Source Address [2] |
~ ~
+--- ---+
. . .
. . .
~ ~
+--- ---+
| Source Address [N] |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o ICMP messages are (currently) never sent toward multicast Fields:
addresses, whereas that would be required to send Feedback
messages to IGMPv2/MLDv1 hosts
6.2.2. IGMP/MLD Multicast Group Address: IPv4 multicast group address of the group
in error. Possibly set to all zeros. Contains an IPv4 address in
the case of IPv4/IGMP, and an IPv6 address in the case of IPv6/
MLD.
The Feedback message could be an IGMP or MLD message that would use Reserved: Reserved for future use. Set to zero on transmission;
new IGMP/MLD message types. ignored upon receipt.
Pros: Number of Sources: Indicates the number of sources in error.
Possibly set to zero.
o IGMP and MLD are the protocols used for all operations related to Source Address [1..n]: Addresses of the multicast sources in error.
multicast subscription In the case of IPv4/IGMP, all these fields are 32-bit fields
containing IPv4 addresses. In the case of IPv6/MLD, all these
fields are 128-bit fields containing IPv6 addresses.
Cons: The Multicast Group Address field MAY be set to all zeros (for
instance, if the error is not specific to a said multicast group).
o possibly more work to define the encodings A group record MAY include zero Source Address (it can be the case,
for instance, for a feedback that is not specific to particular
sources, or that relates to an ASM subscription). It MUST NOT
include any source in the following cases:
o a new IANA registry might be needed to manage Feedback error codes o the message that triggered the Feedback message is IGMPv3 or MLDv2
and the group record that triggered the error contains no source
address
o definition of how the network socket API will be used to carry the o the message that triggered the Feedback message is IGMPv2 or MLDv1
information to the applications has to be defined
6.3. Error codes 6.2. Error codes
This section describes some proposed based error types: This section describes some proposed error codes:
o improper message : the Membership Report message is improper (the o improper message : the Membership Report message is improper (the
group address is not in the 224/0 or FF00::/8 range, or specified group address is not in the 224/0 or FF00::/8 range, or specified
sources are improper addresses) sources are improper addresses)
o IGMP version not supported by querier o IGMP or MLD version is not supported by querier
o wildcard on an SSM group : IGMPv2 or IGMPv3/MLDv2 with Exclude o wildcard on an SSM group : IGMPv2 or IGMPv3/MLDv2 with an Exclude
source filter mode was asked, but the group address is not in the source filter mode was used in the Report, but the group address
SSM range of the Querier is not in the SSM range of the Querier
o exclude source filter mode not supported by the Querier o exclude source filter mode not supported by the Querier
o group administratively prohibited o group administratively prohibited
o source(s) administratively prohibited o source(s) administratively prohibited
o resource limit reached o resource limit reached
o multicast reception is disabled on the link o multicast reception is disabled on the link
[ This section will later be completed to include error type numbers o multicast routing protocol issue
[ This section will later be completed to include error code numbers
] ]
Remind that the Feedback message is NOT meant to carry information Remember that the Feedback message is NOT meant to carry information
about transient errors that the network is supposed to recover from, about transient errors that the network is supposed to recover from,
like for instance network outages. like for instance network outages.
An IANA registry may be required to manage these and future error
codes, and provide third party with the ability to define error codes
for IGMP/MLD error feedback.
7. Feedback to the application layer 7. Feedback to the application layer
[ TBC : working group guidance is sought on how to link these This section gives an example of how the information from Feedback
specifications with possibly needed evolution of the POSIX [posix] messages is supplied to applications subscribed to multicast streams,
network socket API ] and which expect the reception of multicast datagrams on a socket,
based on Linux extensions to the POSIX [posix] network socket API.
This section describes how the information from Feedback messages is
supplied to applications subscribed to multicast stream, and
expecting the reception of multicast datagrams on a socket.
A requirement is fully backward compatibility with applications not A first requirement is full backward compatibility with applications
supporting these specifications : an application not supporting these not supporting these specifications : an application not supporting
specifications must not be affected by a Feedback message. For these specifications must not be affected by a Feedback message. For
instance, a wrong solution would be to return an error on a read() or instance, a wrong solution would be to return an error on a read() or
recv() call. recv() call.
A second requirement is to allow an application to keep receiving A second requirement is to allow an application to keep receiving
data on a socket, even if some error was reported through a Feedback data on a socket, even if some error was reported through a Feedback
message, for a group or channel joined on this socket. This is message, for a group or channel joined on this socket. This is
needed, for instance, in two cases : when a socket is used to join needed, for instance, in two cases : when a socket is used to join
multiple distinct group or channels and only one of them is subject multiple distinct group or channels and only one of them is subject
to an error ; when a socket is used to join only one multicast group, to an error ; when a socket is used to join only one multicast group,
for which the Querier sends a Feedback message, but there are members for which the Querier sends a Feedback message, but there are members
for this group sending data on a directly connected link. for this group sending data on a directly connected link.
A proposal is to rely on the use of the MSG_ERRQUEUE flag of the The proposed solution is to rely on the use of the MSG_ERRQUEUE flag
recvmsg()/recvfrom() POSIX calls. This call allows the socket user of the recvmsg()/recvfrom() POSIX calls. This call allows the socket
to retrieve the network errors queued for the socket. Further work user to retrieve the network errors queued for the socket.
is required to fully describe how information from the Feedback
message would be mapped in the sock_extended_err structure.
Another proposal would be to allow the setsockopt() and The MLD component receiving an MLD Feedback message containing error
condition reports the error to the application via the MSG_ERRQUEUE
flag in the recvmsg()/recvfrom() calls. The MSG_ERRQUEUE flag
indicates the presence of a sock_extended_err data structure. When
the sock_extended_err data structure is passed to the application,
the ee_origin field is set to 3 (SO_EE_ORIGIN_ICMP6) in the case of
an MLD Feedback message, and XX (SO_EE_ORIGIN_YYYY) in the case of an
IGMP Feedback message [XX and YYY is to be determined in compliance
with the relevant standard, 4 and SO_EE_ORIGIN_IGMP are proposed as
interim values]. The Type and Code fields from the MLD Feedback
message are copied into the ee_type and ee_code field of the
sock_extended_err data structure.
The addresses of the multicast group and sources in error can be
retrieved as follows:
o in the IPv4 case, the group address and source address are stored,
respectively, in the ee_info and ee_data fields,
o the group address and source address can be retrieved, in all
cases, by calling functions returning a sockaddr pointer and which
take into argument a sock_extended_err pointer (similarly as
SOCK_EE_OFFENDER) and called SOCK_EE_MCAST_FEEDBACK_GRP and
SOCK_EE_MCAST_FEEDBACK_SRC
If the Feedback contains multiple sources addresses, a
sock_extended_err will be added to the message queue for each such
sources.
An application receiving a sock_extended_err message from the MLD
component MUST NOT terminate the multicast subscription to the group
or source/group address in error, except possibly if it can be
ascertained that the Feedback message comes from a legitimate Querier
(e.g. thanks to a mechanism like SEND [RFC3971]), and if multicast
traffic for the said group or channel is not expected from any host
attached to a directly-connected link.
( Another proposal would be to allow the setsockopt() and
set(ipv4)sourcefilter() calls [RFC3678] to return an error. That set(ipv4)sourcefilter() calls [RFC3678] to return an error. That
would require the local network stack to wait for some time after would require the local network stack to wait for some time after
sending a Membership Report message, before being able to return from sending a Membership Report message, before being able to return from
the setsockopt()/set(ipv4)sourcefilter() call, and would not easily the setsockopt()/set(ipv4)sourcefilter() call, and would not easily
allow to carry detailed information about the specific group or allow to carry detailed information about the specific group or
channel in error. Consequently, this approach doesn't seem a viable channel in error. Consequently, this approach doesn't seem a viable
one. one. )
8. Impact on IGMP/MLD proxies and equipments doing IGMP/MLD snooping 8. Impact on IGMP/MLD proxies and equipments doing IGMP/MLD snooping
8.1. IGMP/MLD Proxies 8.1. IGMP/MLD Proxies
To support this Feedback mechanism, an IGMP or MLD proxy [RFC4605] To support this Feedback mechanism, an IGMP or MLD proxy [RFC4605]
SHOULD send Feedback messages received on its Host side toward its SHOULD send Feedback messages received on its Host side toward its
Querier side(s) that have matching multicast memberships. The Querier side(s) that have matching multicast memberships. The
procedures for sending the Feedback messages are then the same as for procedures for sending the Feedback messages are then the same as for
a normal Querier, as specified in Section 5: in particular the IGMP/ a normal Querier, as specified in Section 5: in particular the IGMP/
skipping to change at page 10, line 7 skipping to change at page 12, line 14
that case it MUST still respect procedures of Section 5. that case it MUST still respect procedures of Section 5.
8.2. Equipments doing IGMP/MLD snooping 8.2. Equipments doing IGMP/MLD snooping
IGMP/MLD snooping equipments are expected to transparently IGMP/MLD snooping equipments are expected to transparently
interoperate with the procedures described in this document, given interoperate with the procedures described in this document, given
that RFC 4541 section 2.2.1(3) [RFC4541] states that "[a] switch that that RFC 4541 section 2.2.1(3) [RFC4541] states that "[a] switch that
supports IGMP snooping must flood all unrecognized IGMP messages to supports IGMP snooping must flood all unrecognized IGMP messages to
all other ports". all other ports".
9. IANA Considerations 9. IGMP/MLD Hosts stacks not implementing the Feedback mechanism
Request to IANA for ICMP or IGMP code point allocation would To allow applications running on an IGMP/MLD Host, whose networking
expectedly be requested in the future for the messages defined in stack or API does not implement the Feedback mechanism described in
this document. this spec, it is proposed that IGMP/MLD Querier implementing this
specification can, when configured to do so, send each Feedback
message twice : once with the encoding described in these
specifications, and another time encapsulated in a UDP packet.
The UDP message uses port xxx [TBD], with a payload identical to the
IGMP or MLD Feedback message, except that the checksum is set to zero
(the UDP message having its own checksum).
10. IANA Considerations
Request to IANA for IGMP and ICMPv6 type allocation will be needed
for the messages defined in this document.
[Whether or not it is needed to define a registry for the error codes
used in IGMP/MLD Feedback messages will be later determined.]
[Note to RFC Editor: this section may be removed on publication as an [Note to RFC Editor: this section may be removed on publication as an
RFC.] RFC.]
10. Security Considerations 11. Security Considerations
Given that the specifications in this document do not change nor the Given that the specifications in this document do not change nor the
state machine of the IGMP/MDLD Querier and Host stack, nor the state machine of the IGMP/MDLD Querier and Host stack, nor the
datagrams that will be received by an application, they are not datagrams that will be received by an application, they are not
expected to introduce security issues not already existing with IGMP/ expected to introduce security issues not already existing with IGMP/
MLD or the protocol used to carry the Feedback message. MLD or the protocol used to carry the Feedback message.
A possible issue would be to have wrong Feedback sent toward A possible issue would be to have wrong Feedback sent toward
multicast applications. Such an issue could arise if spoofed multicast applications. Such an issue could arise if spoofed
Feedback messages are sent and interpreted by multicast receiver Feedback messages are sent and interpreted by multicast receiver
skipping to change at page 10, line 46 skipping to change at page 13, line 23
limiting would possibly result in some receivers not receiving the limiting would possibly result in some receivers not receiving the
feedback message that they would have, which is a form of denial of feedback message that they would have, which is a form of denial of
service, but only on the Feedback function by itself, with no impact service, but only on the Feedback function by itself, with no impact
on the rest of the multicast group membership control protocol on the rest of the multicast group membership control protocol
infrastructure. This later type of denial of service might be infrastructure. This later type of denial of service might be
mitigated by doing rate-limiting based on the source address of the mitigated by doing rate-limiting based on the source address of the
receivers (the source address of the Membership Report triggering the receivers (the source address of the Membership Report triggering the
Feedback message); but such mechanism may themselves be subject to Feedback message); but such mechanism may themselves be subject to
weaknesses due to Membership Report spoofing. weaknesses due to Membership Report spoofing.
11. Acknowledgements 12. Acknowledgements
Acknowledgments go to DSLForum contributors who provided an initial Acknowledgments go to DSLForum contributors who provided an initial
proposal, to IETF participants that participated in the discussion on proposal, to IETF participants that participated in the discussion on
the magma WG list, from which guidance and inspiration was largely the magma WG list, from which guidance and inspiration was largely
taken. Thank you to Bill Fenner for providing detailed information taken. Thank you to Bill Fenner for providing detailed information
on issues related to ICMP errors in reaction to multicast datagrams. on issues related to ICMP errors in reaction to multicast datagrams.
12. References Thanks to Toerless Eckert for his inputs and who offered a suggestion
on how to handle application running on hosts not implementing the
Feedback mechanism.
12.1. Normative References Message encodings are largely inspired from Report message encodings
found in[RFC3376].
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678, Extensions for Multicast Source Filters", RFC 3678,
skipping to change at page 11, line 37 skipping to change at page 14, line 20
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006. Switches", RFC 4541, May 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, August 2006.
12.2. Informative References 13.2. Informative References
[I-D.ietf-mboned-maccnt-req] [I-D.ietf-mboned-maccnt-req]
He, H., "Requirements for Multicast AAA coordinated He, H., "Requirements for Multicast AAA coordinated
between Content Provider(s) and Network Service between Content Provider(s) and Network Service
Provider(s)", draft-ietf-mboned-maccnt-req-05 (work in Provider(s)", draft-ietf-mboned-maccnt-req-05 (work in
progress), October 2007. progress), October 2007.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995. RFC 1812, June 1995.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[fenner-icmp-mcast] [fenner-icmp-mcast]
"ICMP errors in response to multicast", March 1999, "ICMP errors in response to multicast", March 1999,
<http://www.icir.org/fenner/mcast/icmp.html>. <http://www.icir.org/fenner/mcast/icmp.html>.
[magma-archive] [magma-archive]
"IETF Magma WG mailing-list archives", December 2005, <htt "IETF Magma WG mailing-list archives", December 2005, <htt
p://www1.ietf.org/mail-archive/web/magma/current/ p://www1.ietf.org/mail-archive/web/magma/current/
msg00815.html>. msg00815.html>.
[posix] "ISO/IEC 9945 Information technology, Portable Operating [posix] "ISO/IEC 9945 Information technology, Portable Operating
System Interface (POSIX), Part 1: Base Definitions", 2003. System Interface (POSIX), Part 1: Base Definitions", 2003.
Author's Address Appendix A. Protocol to carry error feedback messages
Thomas Morin ICMP and IGMP/MLD were possible candidates for carrying the Feedback
message. This section exposes the pros/cons of both alternatives,
and ought to be removed once a decision is made on one of them.
A.1. ICMP
The Feedback message could be an ICMP message that would use a new
ICMP message type (or possibly reusing existing types and codes).
Pros:
o ICMP is already used to carry error messages between routers and
hosts (e.g.. port unreachable message)
o ICMP has an extensible format which could easily be reused for the
Feedback function described in this memo
o Implementations of network socket APIs already take into account
ICMP messages
Cons:
o ICMP has currently nothing to do with multicast today
o some RFC explicitly forbid the sending of ICMP in reaction to
receiving multicast packets, and IGMP/MLD Membership Reports are
multicast packets ([RFC1122] section 7.2 and 3.2.2, [RFC1812]
section 4.3.2.7) (see [fenner-icmp-mcast])
o ICMP messages are (currently) never sent toward multicast
addresses, whereas that would be required to send Feedback
messages to IGMPv2/MLDv1 hostsSo we may say that the generic
argument is that the restriction for ICMP ; this has lead to
practical issues to integrate this approach into existing stacks,
because of the need to work around sanity checks
A.2. IGMP/MLD
The Feedback message could be an IGMP or MLD message that would use
new IGMP/MLD message types.
Pros:
o IGMP and MLD are the protocols used for all operations related to
multicast subscription
Cons:
o possibly more work to define the encodings
o a new IANA registry might be needed to manage Feedback error codes
o definition of how the network socket API will be used to carry the
information to the applications has to be defined
Authors' Addresses
Thomas Morin (editor)
France Telecom - Orange Labs France Telecom - Orange Labs
2, avenue Pierre Marzin 2, avenue Pierre Marzin
Lannion 22307 Lannion 22307
France France
Email: thomas.morin@orange-ftgroup.com Email: thomas.morin@orange-ftgroup.com
Brian Haberman
The Johns Hopkins University, Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, MD 20723-6099
US
Phone: +1 443 778 1319
Email: brian@innovationslab.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 13, line 44 skipping to change at line 738
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 77 change blocks. 
155 lines changed or deleted 333 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/