<?xml version="1.0"?>
<?rfc toc="yes"?><?rfc tocompact="yes"?><?rfc tocdepth="3"?><?rfc tocindent="yes"?><?rfc symrefs="yes"?><?rfc sortrefs="yes"?><?rfc comments="no"?><?rfc inline="yes"?><?rfc compact="yes"?><?rfc subcompact="no"?><rfc category="exp" docName="draft-morin-mboned-igmpmld-error-feedback-02" ipr="full3978">
  <front>
    <title abbrev="">IGMP/MLD Error Feedback</title>

    <author fullname="Thomas Morin" initials="T." role="editor" surname="Morin">
      <organization>France Telecom - Orange Labs</organization>

      <address>
        <postal>
          <street>2, avenue Pierre Marzin</street>

          <city>Lannion</city>

          <code>22307</code>

          <country>France</country>
        </postal>

        <email>thomas.morin@orange-ftgroup.com</email>
      </address>
    </author>

    <author fullname="Brian Haberman" initials="B." surname="Haberman">
      <organization>The Johns Hopkins University, Applied Physics
      Laboratory</organization>

      <address>
        <postal>
          <street>11100 Johns Hopkins Road</street>

          <city>Laurel</city>

          <region>MD</region>

          <code>20723-6099</code>

          <country>US</country>
        </postal>

        <phone>+1 443 778 1319</phone>

        <email>brian@innovationslab.net</email>
      </address>
    </author>

    <date month="November" year="2008"/>

    <workgroup>mboned</workgroup>

    <keyword>draft</keyword>

    <abstract>
      <t>This document describes messages and procedures that can optionally
      be implemented in IGMP/MLD Queriers and Hosts, to provide information to
      multicast receivers on the reason why the IGMP/MLD Querier didn't take
      into account a Membership Report message.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Requirements have been formulated for means to provide multicast
      receivers with error feedback when the IGMP/MLD Querier did not or could
      not process an IGMP/MLD Membership Report message (<xref target="I-D.ietf-mboned-maccnt-req"/>, section 4). Operator's
      experience with IPTV deployments show that introducing such a feedback
      in IGMP exchanges between multicast receivers and multicast routing
      equipments would help provide a better service (e.g. a liaison between
      the IETF mboned working group and the DSLForum was made in December 2005
      to discuss this issue, but didn't lead to a standardized solution).</t>

      <t>An examples case is when an IGMP Querier refuses to take into account
      an IGMP Membership Report because the number of multicast channels would
      surpass the allowed threshold for the service. Many other examples of
      the case where an IGMP error feedback channel would be useful are
      presented in <xref target="error-codes"> </xref>.</t>

      <t>This document describes new message encodings and the associated
      procedures, all of which being optional and preserving full backward and
      forward compatibility, and details the impact on the host API for
      multicast subscriptions.</t>

      <t>This document doesn't state yet whether the messages should be
      carried over IGMP, ICMP or another protocol, but tries to document the
      pros and cons of the different alternatives, to guide the decision
      process.</t>
    </section>

    <section title="Terminology">
      <t>The terminology in this document is the terminology used in <xref target="RFC3376"> </xref> and <xref target="RFC3810"> </xref>.</t>

      <t>For readability, "Querier" and "Host(s)" will be used throughout this
      document, in place of "IGMP or MLD Querier" and "IGMP or MLD
      Host(s)".</t>
    </section>

    <section title="History and problem statement">
      <t>The DSLForum expressed interest for such a feature, which was <xref target="magma-archive">discussed</xref> in a liaison with the Magma IETF
      Working group. The specifications described in this document try to
      address the comments exchanged on the magma WG mailing-list.</t>
    </section>

    <section title="Principle">
      <t>The procedures described in this memo are fully optional : their only
      intent is to carry informative data from the Querier to the Hosts.</t>

      <t>Most specifically, the intent is that:<list style="symbols">
          <t>the procedures don't change the state machine of the Querier or
          Host, the information carried is only meant to provide information
          to the application subscribed to multicast data</t>

          <t>a Host implementing these specifications will behave correctly in
          the absence of these informations.</t>

          <t>the behavior of a Querier implementing these specifications is
          unchanged whether or not the hosts implement these specs.</t>
        </list></t>

      <t>Last, these specifications are not meant to carry information about
      transient errors that the network is supposed to recover from, like
      network outages.</t>
    </section>

    <section anchor="procedures" title="Procedures">
      <section title="Procedures on the IGMP/MLD Querier">
        <t>The following procedures introduce a new type of message : the
        Feedback message. See section <xref target="encodings"> </xref> for
        details about message encodings.</t>

        <t>Using these procedures a Querier can OPTIONALLY emmit a Feedback
        message after receiving an IGMP or MLD Membership Report message that
        it can not process (see <xref target="error-codes"/> for example
        reasons on why a Querier would not process a Membership Report
        message).</t>

        <t>The Feedback message carries error type/sub-type field, and
        information about the group to which the error pertains. Optionally,
        if IGMPv3/MLDv2 is used, and if the error message pertains to some
        specific sources, the addresses of the sources to which the error
        pertains are included in the message.</t>

        <t>The address to which the Feedback message will be sent is
        determined as follows:<list style="symbols">
            <t>if IGMPv3/MLDv2 is used (and if the sender IP address is not
            0.0.0.0 or 0::0), the address of the sender of the Membership
            Report is used</t>

            <t>else, the group address specified in the Membership Report
            message is used</t>
          </list></t>

        <t>The source address MUST be the same address as the address used for
        Query messages, and the TTL MUST be set to 1.</t>

        <t>If IGMPv2/MLDv1 is being used, not more than one Feedback message
        should be sent for a said Membership Report message.</t>

        <t>If IGMPv3/MLDv2 is being used, not more than one Feedback message
        should be sent for each (S,G) pair present in the Membership Report
        message. Multiple feedback message MAY be sent if the group record in
        error contains multiple source addresses. Multiple feedback message
        SHOULD be sent if the relevant error codes are different for the
        sources/groups of the Report message.</t>

        <t>In any case the amount of Feedback messages sent on a link MUST be
        rate-limited.</t>
      </section>

      <section title="Procedures on the IGMP/MLD Host">
        <t>When a Host receives an Feedback message, it MAY process it.</t>

        <t>Processing a Feedback message consists in :<list style="symbols">
            <t>MANDATORY checking that the TTL is set to 1</t>

            <t>OPTIONALLY checking that the message source address is the
            address of a known Querier</t>

            <t>parsing the Feedback message</t>

            <t>determining the network sockets for which the Feedback message
            is relevant (G is the group address of the Feedback message)<list style="symbols">
                <t>if no source address is included in the Feedback message,
                the sockets are the sockets that have some active forwarding
                state related to G (subscribed to G with a non-null include
                list)</t>

                <t>if some source addresses are indicated in the Feedback
                message, the sockets are the sockets to which traffic from at
                least one of these sources, and toward G, would be
                forwarded</t>
              </list></t>

            <t>notifying these sockets of the error (see <xref target="application"/>)</t>

            <t>OPTIONALLY logging the error and/or doing any local action
            depending on policy</t>
          </list></t>
      </section>
    </section>

    <section anchor="encodings" title="Message encodings">
      <section title="Feedback message">
        <t>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).</t>

        <t>The encoding is common to the two types of messages (except the
        length of fields specifying addresses).</t>

        <figure>
          <artwork>                     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]                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
        </figure>

        <t/>

        <t>Fields:<list style="hanging">
            <t hangText="Type:">Identifies this message as a Feedback message.
            Currently using:<list style="symbols">
                <t>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).</t>

                <t>in the case of IPv4/IGMP: 0xZZ (currently using 0xF2, in
                the "Reserved for experimentation" range, until another value
                is registered with IANA)</t>
              </list></t>

            <t hangText="Code:">One byte, gives additional information about
            the error that triggered the feedback message. The possible values
            are described in <xref target="error-codes"/>.</t>

            <t hangText="Checksum:">The standard IGMP checksum.</t>

            <t hangText="Reserved:">Reserved for future use. Set to zero on
            transmission; ignored upon receipt.</t>

            <t hangText="Number of Group Records:">Indicates the number of
            group records.</t>
          </list></t>

        <t>The Feedback message MUST at least include one group record.</t>

        <t>It MUST NOT include more than one group record if the Feedback
        message is to be sent toward a multicast group address (see section
        <xref target="procedures"> </xref>).</t>

        <t><list style="symbols">
            <t>the message that triggered the Feedback message is IGMPv3 or
            MLDv2 and the group record that triggered the error contains no
            source address</t>

            <t>the message that triggered the Feedback message is IGMPv2 or
            MLDv1 and the message contains no source address</t>
          </list></t>

        <t/>

        <t>Group record encoding:</t>

        <figure>
          <artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Multicast Group Address                    |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved                      |     Number of Sources (N)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address [1]                      |
~                                                               ~
+---                                                         ---+
|                       Source Address [2]                      |
~                                                               ~
+---                                                         ---+
.                               .                               .
.                               .                               .
~                                                               ~
+---                                                         ---+
|                       Source Address [N]                      |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
        </figure>

        <t>Fields:<list style="hanging">
            <t hangText="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.</t>

            <t hangText="Reserved:">Reserved for future use. Set to zero on
            transmission; ignored upon receipt.</t>

            <t hangText="Number of Sources:">Indicates the number of sources
            in error. Possibly set to zero.</t>

            <t hangText="Source Address [1..n]:">Addresses of the multicast
            sources in error. 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.</t>
          </list></t>

        <t>The Multicast Group Address field MAY be set to all zeros (for
        instance, if the error is not specific to a said multicast group).</t>

        <t>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:</t>

        <t><list style="symbols">
            <t>the message that triggered the Feedback message is IGMPv3 or
            MLDv2 and the group record that triggered the error contains no
            source address</t>

            <t>the message that triggered the Feedback message is IGMPv2 or
            MLDv1</t>
          </list></t>
      </section>

      <section anchor="error-codes" title="Error codes">
        <t>This section describes some proposed error codes:</t>

        <t><list style="hanging">
            <t hangText="0x01:">improper message : the Membership Report
            message is improper (the group address is not in the 224/0 or
            FF00::/8 range, or specified sources are improper addresses)</t>

            <t hangText="0x02:">The IGMP or MLD version of the Report message
            is not supported by querier</t>

            <t hangText="0x03:">wildcard on an SSM group : IGMPv2 or
            IGMPv3/MLDv2 with an Exclude source filter mode was used in the
            Report, but the group address is not in the SSM range of the
            Querier</t>

            <t hangText="0x04:">exclude source filter mode not supported by
            the Querier</t>

            <t hangText="0x05:">group administratively prohibited</t>

            <t hangText="0x06:">source(s) administratively prohibited</t>

            <t hangText="0x07:">a resource limit was reached</t>

            <t hangText="0x08:">multicast reception is disabled on the
            link</t>

            <t hangText="0x09:">multicast routing protocol issue</t>
          </list></t>

        <t>Remember that the Feedback message is NOT meant to carry
        information about transient errors that the network is supposed to
        recover from, like for instance network outages.</t>
      </section>
    </section>

    <section anchor="application" title="Feedback to the application layer">
      <t>This section gives an example of how the information from Feedback
      messages is supplied to applications subscribed to multicast streams,
      and which expect the reception of multicast datagrams on a socket, based
      on Linux extensions to the <xref target="posix">POSIX</xref> network
      socket API.</t>

      <t>A first requirement is full backward compatibility with applications
      not supporting these specifications : an application not supporting
      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
      recv() call.</t>

      <t>A second requirement is to allow an application to keep receiving
      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 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 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 this group
      sending data on a directly connected link.</t>

      <t>The proposed solution is to rely on the use of the MSG_ERRQUEUE flag
      of the recvmsg()/recvfrom() POSIX calls. This call allows the socket
      user to retrieve the network errors queued for the socket.</t>

      <t>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.</t>

      <t>The addresses of the multicast group and sources in error can be
      retrieved as follows:<list style="symbols">
          <t>in the IPv4 case, the group address and source address are
          stored, respectively, in the ee_info and ee_data fields,</t>

          <t>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</t>
        </list></t>

      <t>If the Feedback contains multiple sources addresses, a
      sock_extended_err will be added to the message queue for each such
      sources.</t>

      <t>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 <xref target="RFC3971">SEND</xref>), and if
      multicast traffic for the said group or channel is not expected from any
      host attached to a directly-connected link.</t>

      <t>( Another proposal would be to allow the setsockopt() and
      set(ipv4)sourcefilter() calls <xref target="RFC3678"/> to return
      an error. That would require the local network stack to wait for some
      time after sending a Membership Report message, before being able to
      return from the setsockopt()/set(ipv4)sourcefilter() call, and would not
      easily allow to carry detailed information about the specific group or
      channel in error. Consequently, this approach doesn't seem a viable one.
      )</t>
    </section>

    <section title="Impact on IGMP/MLD proxies and equipments doing IGMP/MLD snooping">
      <section title="IGMP/MLD Proxies">
        <t>To support this Feedback mechanism, an <xref target="RFC4605">IGMP
        or MLD proxy</xref> SHOULD send Feedback messages received on its Host
        side toward its Querier side(s) that have matching multicast
        memberships. The procedures for sending the Feedback messages are then
        the same as for a normal Querier, as specified in <xref target="procedures"> </xref>: in particular the IGMP/MLD proxy MUST
        use its own address as the source address of the Feedback message.</t>

        <t>A new member of a multicast group already forwarded by the proxy on
        its Querier side, will have to wait for some time before having a
        chance to receive a Feedback message : timers will have to trigger
        before the Querier on the Host side of the proxy sends a Query,
        causing the proxy to send a Membership Report that may then cause the
        Querier on the Host side to send a Feedback message, and this Feedback
        message to be propagated to the new receiver.</t>

        <t>To quickly provide Feedback messages to receivers on its Querier
        side, the proxy MAY cache the information in the Feedback messages
        that it receives on the Host side, so that it can later reuse this
        information to eventually send feedback to Membership Report messages
        received on its Querier side. When such Feedback information caching
        is used, the proxy MUST keep only one Feedback message per (S,G) entry
        or (*,G) entry. On reception of a Report message on its Querier side,
        it shall then lookup in its cache the most relevant feedback
        information. A Feedback information MUST be removed from the cache if
        no Feedback message containing it is received by the Querier on its
        Host side interface, &lt;n&gt; seconds after a corresponding Report
        was sent.</t>

        <t>Last, an IGMP/MLD proxy MAY produce its own Feedback messages. In
        that case it MUST still respect procedures of <xref target="procedures"/>.</t>
      </section>

      <section title="Equipments doing IGMP/MLD snooping">
        <t>IGMP/MLD snooping equipments are expected to transparently
        interoperate with the procedures described in this document, given
        that <xref target="RFC4541">RFC 4541 section 2.2.1(3)</xref> states
        that "[a] switch that supports IGMP snooping must flood all
        unrecognized IGMP messages to all other ports".</t>
      </section>
    </section>

    <section anchor="compat" title="IGMP/MLD Hosts stacks not implementing the Feedback mechanism">
      <t>To allow applications running on an IGMP/MLD Host, whose networking
      stack or API does not implement the Feedback mechanism described in 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.</t>

      <t>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). The message is sent to the
      welknown link local multicast group adress 224.0.0.z [TBD], so that
      reception by multiple applications running on a same host is possible.
      The TTL used MUST be one.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>Request to IANA for IGMP and ICMPv6 type allocation will be needed
      for the messages defined in this document.</t>

      <t>Request to IANA for a UDP port and a link local multicast group
      address will be needed.</t>

      <t>[Whether or not it is needed to define a registry for the error codes
      used in IGMP/MLD Feedback messages will be later determined.]</t>

      <t>[Note to RFC Editor: this section may be removed on publication as an
      RFC.]</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Given that the specifications in this document do not change 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 expected to
      introduce security issues not already existing with IGMP/MLD or the
      protocol used to carry the Feedback message.</t>

      <t>A possible issue would be to have wrong feedback sent toward
      multicast applications. Such an issue could arise if spoofed Feedback
      messages are sent and interpreted by multicast receiver hosts. This
      issue is mitigated by the fact that IGMP/MLD Hosts MUST check that the
      TTL of the Feedback messages is 1.</t>

      <t>The case where such a verification does not protect from spoofing is
      the case of LANs. In that case, spoofing is typically hard to prevent
      and some level of trust in other hosts present on a LAN is required.
      Checking that the source IP of the Feedback message against a list of
      known Queriers can be minor an improvement in these contexts.</t>

      <t>Another possible issue is denial of service of the Querier function,
      that would be due to having the IGMP/MLD Querier be overloaded by
      Feedback messages to send. This is mitigated by allowing the Querier to
      rate-limit the flow of Feedback messages. On a LAN, such a rate-limiting
      would possibly result in some receivers not receiving the 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 on the rest of
      the multicast group membership control protocol infrastructure. This
      later type of denial of service might be mitigated by doing
      rate-limiting based on the source address of the receivers (the source
      address of the Membership Report triggering the Feedback message); but
      such mechanism may themselves be subject to weaknesses due to Membership
      Report spoofing.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Acknowledgments go to DSLForum contributors who provided an initial
      proposal, to IETF participants that participated in the discussion on
      the magma WG list, from which guidance and inspiration was largely
      taken. Thank you to Bill Fenner for providing detailed information on
      issues related to ICMP errors in reaction to multicast datagrams.</t>

      <t>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.</t>

      <t>Message encodings are largely inspired from Report message encodings
      found in<xref target="RFC3376"> </xref>.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <!-- Begin inclusion reference.RFC.2119.xml. -->

      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>- +1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997"/>

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
                "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
                "OPTIONAL" in this document are to be interpreted as described
                in RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>

        <seriesInfo name="BCP" value="14"/>

        <seriesInfo name="RFC" value="2119"/>

        <format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" type="TXT"/>

        <format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>

        <format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
      </reference>

      <!-- End inclusion reference.RFC.2119.xml. -->

      <!-- Begin inclusion reference.RFC.3376.xml. -->

      <reference anchor="RFC3376">
        <front>
          <title>Internet Group Management Protocol, Version 3</title>

          <author fullname="B. Cain" initials="B." surname="Cain">
            <organization/>
          </author>

          <author fullname="S. Deering" initials="S." surname="Deering">
            <organization/>
          </author>

          <author fullname="I. Kouvelas" initials="I." surname="Kouvelas">
            <organization/>
          </author>

          <author fullname="B. Fenner" initials="B." surname="Fenner">
            <organization/>
          </author>

          <author fullname="A. Thyagarajan" initials="A." surname="Thyagarajan">
            <organization/>
          </author>

          <date month="October" year="2002"/>
        </front>

        <seriesInfo name="RFC" value="3376"/>

        <format octets="119726" target="ftp://ftp.isi.edu/in-notes/rfc3376.txt" type="TXT"/>
      </reference>

      <!-- End inclusion reference.RFC.3376.xml. -->

      <!-- Begin inclusion reference.RFC.3810.xml. -->

      <reference anchor="RFC3810">
        <front>
          <title>Multicast Listener Discovery Version 2 (MLDv2) for
          IPv6</title>

          <author fullname="R. Vida" initials="R." surname="Vida">
            <organization/>
          </author>

          <author fullname="L. Costa" initials="L." surname="Costa">
            <organization/>
          </author>

          <date month="June" year="2004"/>

          <abstract>
            <t>This document updates RFC 2710, and it specifies Version 2 of
            the multicast Listener Discovery Protocol (MLDv2). MLD is used by
            an IPv6 router to discover the presence of multicast listeners on
            directly attached links, and to discover which multicast addresses
            are of interest to those neighboring nodes. MLDv2 is designed to
            be interoperable with MLDv1. MLDv2 adds the ability for a node to
            report interest in listening to packets with a particular
            multicast address only from specific source addresses or from all
            sources except for specific source addresses. [STANDARDS
            TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3810"/>

        <format octets="153579" target="ftp://ftp.isi.edu/in-notes/rfc3810.txt" type="TXT"/>
      </reference>

      <!-- End inclusion reference.RFC.3810.xml. -->

      <!-- Begin inclusion reference.RFC.3678.xml. -->

      <reference anchor="RFC3678">
        <front>
          <title>Socket Interface Extensions for Multicast Source
          Filters</title>

          <author fullname="D. Thaler" initials="D." surname="Thaler">
            <organization/>
          </author>

          <author fullname="B. Fenner" initials="B." surname="Fenner">
            <organization/>
          </author>

          <author fullname="B. Quinn" initials="B." surname="Quinn">
            <organization/>
          </author>

          <date month="January" year="2004"/>

          <abstract>
            <t>The Internet Group Management Protocol (IGMPv3) for IPv4 and
            the Multicast Listener Discovery (MLDv2) for IPv6 add the
            capability for applications to express source filters on multicast
            group memberships, which allows receiver applications to determine
            the set of senders (sources) from which to accept multicast
            traffic. This capability also simplifies support of one-to-many
            type multicast applications. This document specifies new socket
            options and functions to manage source filters for IP Multicast
            group memberships. It also defines the socket structures to
            provide input and output arguments to these new application
            program interfaces (APIs). These extensions are designed to
            provide access to the source filtering features, while introducing
            a minimum of change into the system and providing complete
            compatibility for existing multicast applications.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3678"/>

        <format octets="36320" target="ftp://ftp.isi.edu/in-notes/rfc3678.txt" type="TXT"/>
      </reference>

      <!-- End inclusion reference.RFC.3678.xml. -->

      <!-- Begin inclusion reference.RFC.4605.xml. -->

      <reference anchor="RFC4605">
        <front>
          <title>Internet Group Management Protocol (IGMP) / Multicast
          Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD
          Proxying")</title>

          <author fullname="B. Fenner" initials="B." surname="Fenner">
            <organization/>
          </author>

          <author fullname="H. He" initials="H." surname="He">
            <organization/>
          </author>

          <author fullname="B. Haberman" initials="B." surname="Haberman">
            <organization/>
          </author>

          <author fullname="H. Sandick" initials="H." surname="Sandick">
            <organization/>
          </author>

          <date month="August" year="2006"/>

          <abstract>
            <t>In certain topologies, it is not necessary to run a multicast
            routing protocol. It is sufficient for a device to learn and proxy
            group membership information and simply forward multicast packets
            based upon that information. This document describes a mechanism
            for forwarding based solely upon Internet Group Management
            Protocol (IGMP) or Multicast Listener Discovery (MLD) membership
            information. [STANDARDS TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4605"/>

        <format octets="25558" target="ftp://ftp.isi.edu/in-notes/rfc4605.txt" type="TXT"/>
      </reference>

      <!-- End inclusion reference.RFC.4605.xml. -->

      <!-- Begin inclusion reference.RFC.4541.xml. -->

      <reference anchor="RFC4541">
        <front>
          <title>Considerations for Internet Group Management Protocol (IGMP)
          and Multicast Listener Discovery (MLD) Snooping Switches</title>

          <author fullname="M. Christensen" initials="M." surname="Christensen">
            <organization/>
          </author>

          <author fullname="K. Kimball" initials="K." surname="Kimball">
            <organization/>
          </author>

          <author fullname="F. Solensky" initials="F." surname="Solensky">
            <organization/>
          </author>

          <date month="May" year="2006"/>

          <abstract>
            <t>This memo describes the recommendations for Internet Group
            Management Protocol (IGMP) and Multicast Listener Discovery (MLD)
            snooping switches. These are based on best current practices for
            IGMPv2, with further considerations for IGMPv3- and
            MLDv2-snooping. Additional areas of relevance, such as link layer
            topology changes and Ethernet-specific encapsulation issues, are
            also considered. This memo provides information for the Internet
            community.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4541"/>

        <format octets="38555" target="ftp://ftp.isi.edu/in-notes/rfc4541.txt" type="TXT"/>
      </reference>

      <!-- End inclusion reference.RFC.4541.xml. -->
    </references>

    <references title="Informative References">
      <!-- Begin inclusion reference.I-D.ietf-mboned-maccnt-req.xml. -->

      <reference anchor="I-D.ietf-mboned-maccnt-req">
        <front>
          <title>Requirements for Multicast AAA coordinated between Content
          Provider(s) and Network Service Provider(s)</title>

          <author fullname="Haixiang He" initials="H" surname="He">
            <organization/>
          </author>

          <date day="4" month="October" year="2007"/>

          <abstract>
            <t>This memo presents requirements in the area of accounting and
            access control for IP multicasting. The scope of the requirements
            is limited to cases that Authentication, Accounting and
            Authorization (AAA) functions are coordinated between Content
            Provider(s) and Network Service Provider(s). General requirements
            for accounting and admission control capabilities including
            quality-of-service (QoS) related issues are listed. This memo
            assumes that these capabilities can be realized by functions
            implemented at edges of a network based on IGMP or MLD. Finally,
            cases for Content Delivery Services (CDS) are described as
            application examples which could benefit from multicasting
            accounting and access control capabilities as described in the
            memo. This memo defines requirements related to AAA issues for
            multi- entity provider models in which the network service
            provider and content provider cooperate to provide CDS and various
            related AAA functions for purposes such as protecting and
            accounting for the access to content and network resources. The
            requirements are generally not relevant to cases in which there is
            not a reason to share AAA functions between separate entities.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft" value="draft-ietf-mboned-maccnt-req-05"/>

        <format target="http://www.ietf.org/internet-drafts/draft-ietf-mboned-maccnt-req-05.txt" type="TXT"/>
      </reference>

      <!-- End inclusion reference.I-D.ietf-mboned-maccnt-req.xml. -->

      <!-- Begin inclusion reference.RFC.1122.xml. -->

      <reference anchor="RFC1122">
        <front>
          <title>Requirements for Internet Hosts - Communication
          Layers</title>

          <author fullname="Robert Braden" initials="R." surname="Braden">
            <organization>University of Southern California (USC)/ Information
            Sciences Institute (ISI)</organization>

            <address>
              <postal>
                <street>4676 Admiralty Way</street>

                <city>Marina del Rey</city>

                <region>CA</region>

                <code>90292-6695</code>

                <country>US</country>
              </postal>

              <phone>+1 213 822 1511</phone>

              <email>Braden@ISI.EDU</email>
            </address>
          </author>

          <date month="October" year="1989"/>
        </front>

        <seriesInfo name="STD" value="3"/>

        <seriesInfo name="RFC" value="1122"/>

        <format octets="295992" target="ftp://ftp.isi.edu/in-notes/rfc1122.txt" type="TXT"/>
      </reference>

      <!-- End inclusion reference.RFC.1122.xml. -->

      <!-- Begin inclusion reference.RFC.3971.xml. -->

      <reference anchor="RFC3971">
        <front>
          <title>SEcure Neighbor Discovery (SEND)</title>

          <author fullname="J. Arkko" initials="J." surname="Arkko">
            <organization/>
          </author>

          <author fullname="J. Kempf" initials="J." surname="Kempf">
            <organization/>
          </author>

          <author fullname="B. Zill" initials="B." surname="Zill">
            <organization/>
          </author>

          <author fullname="P. Nikander" initials="P." surname="Nikander">
            <organization/>
          </author>

          <date month="March" year="2005"/>

          <abstract>
            <t>IPv6 nodes use the Neighbor Discovery Protocol (NDP) to
            discover other nodes on the link, to determine their link-layer
            addresses to find routers, and to maintain reachability
            information about the paths to active neighbors. If not secured,
            NDP is vulnerable to various attacks. This document specifies
            security mechanisms for NDP. Unlike those in the original NDP
            specifications, these mechanisms do not use IPsec. [STANDARDS
            TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="3971"/>

        <format octets="123372" target="ftp://ftp.isi.edu/in-notes/rfc3971.txt" type="TXT"/>
      </reference>

      <!-- End inclusion reference.RFC.3971.xml. -->

      <!-- Begin inclusion reference.RFC.1812.xml. -->

      <reference anchor="RFC1812">
        <front>
          <title>Requirements for IP Version 4 Routers</title>

          <author fullname="Fred Baker" initials="F." surname="Baker">
            <organization>Cisco Systems</organization>

            <address>
              <postal>
                <street>519 Lado Drive</street>

                <city>Santa Barbara</city>

                <region>CA</region>

                <code>93111</code>

                <country>US</country>
              </postal>

              <phone>+1 805 681 0115</phone>

              <email>fred@cisco.com</email>
            </address>
          </author>

          <date month="June" year="1995"/>
        </front>

        <seriesInfo name="RFC" value="1812"/>

        <format octets="415740" target="ftp://ftp.isi.edu/in-notes/rfc1812.txt" type="TXT"/>
      </reference>

      <!-- End inclusion reference.RFC.1812.xml. -->

      <reference anchor="fenner-icmp-mcast" target="http://www.icir.org/fenner/mcast/icmp.html">
        <front>
          <title>ICMP errors in response to multicast</title>

          <author fullname="Bill Fenner">
            <organization/>
          </author>

          <date day="12" month="March" year="1999"/>
        </front>
      </reference>

      <reference anchor="magma-archive" target="http://www1.ietf.org/mail-archive/web/magma/current/msg00815.html">
        <front>
          <title>IETF Magma WG mailing-list archives</title>

          <author fullname="IETF Magma WG">
            <organization/>
          </author>

          <date day="16" month="December" year="2005"/>
        </front>
      </reference>

      <reference anchor="posix">
        <front>
          <title>ISO/IEC 9945 Information technology, Portable Operating
          System Interface (POSIX), Part 1: Base Definitions</title>

          <author fullname="ISO/IEC">
            <organization>ISO</organization>
          </author>

          <date year="2003"/>
        </front>
      </reference>
    </references>

    <section title="Protocol to carry error feedback messages">
      <t>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.</t>

      <section title="ICMP">
        <t>The Feedback message could be an ICMP message that would use a new
        ICMP message type (or possibly reusing existing types and codes).</t>

        <t>Pros:<list style="symbols">
            <t>ICMP is already used to carry error messages between routers
            and hosts (e.g.. port unreachable message)</t>

            <t>ICMP has an extensible format which could easily be reused for
            the Feedback function described in this memo</t>

            <t>Implementations of network socket APIs already take into
            account ICMP messages</t>
          </list></t>

        <t>Cons:<list style="symbols">
            <t>ICMP has currently nothing to do with multicast today</t>

            <t>some RFC explicitly forbid the sending of ICMP in reaction to
            receiving multicast packets, and IGMP/MLD Membership Reports are
            multicast packets (<xref target="RFC1122"/> section 7.2 and
            3.2.2, <xref target="RFC1812"/> section 4.3.2.7) (see <xref target="fenner-icmp-mcast"/>)</t>

            <t>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</t>
          </list></t>
      </section>

      <section title="IGMP/MLD">
        <t>The Feedback message could be an IGMP or MLD message that would use
        new IGMP/MLD message types.</t>

        <t>Pros:<list style="symbols">
            <t>IGMP and MLD are the protocols used for all operations related
            to multicast subscription</t>
          </list></t>

        <t>Cons:<list style="symbols">
            <t>possibly more work to define the encodings</t>

            <t>a new IANA registry might be needed to manage Feedback error
            codes</t>

            <t>definition of how the network socket API will be used to carry
            the information to the applications has to be defined</t>
          </list></t>
      </section>
    </section>
  </back>
</rfc>
