rfc3810.txt

xorp源码hg

Network Working Group                                       R. Vida, Ed.
Request for Comments: 3810                                 L. Costa, Ed.
Updates: 2710                                                       LIP6
Category: Standards Track                                      June 2004


        Multicast Listener Discovery Version 2 (MLDv2) for IPv6

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   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.




















Vida & Costa                Standards Track                     [Page 1]

RFC 3810                     MLDv2 for IPv6                    June 2004


Table of Contents

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The Service Interface for Requesting IP Multicast Reception .   9
   4.  Multicast Listening State Maintained by Nodes . . . . . . . .  11
   5.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .  13
   6.  Protocol Description for Multicast Address Listeners. . . . .  27
   7.  Protocol Description for Multicast Routers. . . . . . . . . .  34
   8.  Interoperation with MLDv1 . . . . . . . . . . . . . . . . . .  48
   9.  List of Timers, Counters, and their Default Values. . . . . .  51
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  55
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  56
   12. References. . . . . . . . . . . . . . . . . . . . . . . . . .  56
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  57
   Appendix A. Design Rationale. . . . . . . . . . . . . . . . . . .  58
   Appendix B. Summary of Changes from MLDv1 . . . . . . . . . . . .  59
   Editors' Contact Information. . . . . . . . . . . . . . . . . . .  61
   Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . .  61
   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .  62

1.  Introduction

   The Multicast Listener Discovery Protocol (MLD) is used by IPv6
   routers to discover the presence of multicast listeners (i.e., nodes
   that wish to receive multicast packets) on their directly attached
   links, and to discover specifically which multicast addresses are of
   interest to those neighboring nodes.  Note that a multicast router
   may itself be a listener of one or more multicast addresses; in this
   case it performs both the "multicast router part" and the "multicast
   address listener part" of the protocol, to collect the multicast
   listener information needed by its multicast routing protocol on the
   one hand, and to inform itself and other neighboring multicast
   routers of its listening state on the other hand.

   This document specifies Version 2 of MLD.  The previous version of
   MLD is specified in [RFC2710].  In this document we will refer to it
   as MLDv1.  MLDv2 is a translation of the IGMPv3 protocol [RFC3376]
   for IPv6 semantics.

   The MLDv2 protocol, when compared to MLDv1, adds support for "source
   filtering", i.e., the ability for a node to report interest in
   listening to packets *only* from specific source addresses, as
   required to support Source-Specific Multicast [RFC3569], or from *all
   but* specific source addresses, sent to a particular multicast
   address.  MLDv2 is designed to be interoperable with MLDv1.





Vida & Costa                Standards Track                     [Page 2]

RFC 3810                     MLDv2 for IPv6                    June 2004


   The capitalized 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
   [RFC2119].  Due to the lack of italics, emphasis is indicated herein
   by bracketing a word or phrase in "*" characters.  Furthermore,
   square brackets are used to denote the value of the enclosed
   variable, as opposed to the variable itself, written without
   brackets.

2.  Protocol Overview

   This section gives a brief description of the protocol operation. The
   following sections present the protocol details.

   MLD is an asymmetric protocol; it specifies separate behaviors for
   multicast address listeners (i.e., hosts or routers that listen to
   multicast packets) and multicast routers.  The purpose of MLD is to
   enable each multicast router to learn, for each of its directly
   attached links, which multicast addresses and which sources have
   interested listeners on that link.  The information gathered by MLD
   is provided to whichever multicast routing protocol is used by the
   router, in order to ensure that multicast packets are delivered to
   all links where there are listeners interested in such packets.

   Multicast routers only need to know that *at least one* node on an
   attached link is listening to packets for a particular multicast
   address, from a particular source; a multicast router is not required
   to *individually* keep track of the interests of each neighboring
   node.  (Nevertheless, see Appendix A2 item 1 for discussion.)

   A multicast router performs the *router part* of the MLDv2 protocol
   (described in details in section 7) on each of its directly attached
   links.  If a multicast router has more than one interface connected
   to the same link, it only needs to operate the protocol on one of
   those interfaces.  The router behavior depends on whether there are
   several multicast routers on the same subnet, or not.  If that is the
   case, a querier election mechanism (described in section 7.6.2) is
   used to elect a single multicast router to be in Querier state.  This
   router is called the Querier.  All multicast routers on the subnet
   listen to the messages sent by multicast address listeners, and
   maintain the same multicast listening information state, so that they
   can take over the querier role, should the present Querier fail.
   Nevertheless, only the Querier sends periodical or triggered query
   messages on the subnet, as described in section 7.1.







Vida & Costa                Standards Track                     [Page 3]

RFC 3810                     MLDv2 for IPv6                    June 2004


   A multicast address listener performs the *listener part* of the
   MLDv2 protocol (described in details in section 6) on all interfaces
   on which multicast reception is supported, even if more than one of
   those interfaces are connected to the same link.

2.1.  Building Multicast Listening State on Multicast Address Listeners

   Upper-layer protocols and applications that run on a multicast
   address listener node use specific service interface calls (described
   in section 3) to ask the IP layer to enable or disable reception of
   packets sent to specific multicast addresses.  The node keeps
   Multicast Address Listening state for each socket on which the
   service interface calls have been invoked (section 4.1).  In addition
   to this per-socket multicast listening state, a node must also
   maintain or compute multicast listening state for each of its
   interfaces (section 4.2).  Conceptually, that state consists of a set
   of records, with each record containing an IPv6 multicast address, a
   filter mode, and a source list.  The filter mode may be either
   INCLUDE or EXCLUDE.  In INCLUDE mode, reception of packets sent to
   the specified multicast address is enabled *only* from the source
   addresses listed in the source list.  In EXCLUDE mode, reception of
   packets sent to the given multicast address is enabled from all
   source addresses *except* those listed in the source list.

   At most one record per multicast address exists for a given
   interface.  This per-interface state is derived from the per-socket
   state, but may differ from it when different sockets have differing
   filter modes and/or source lists for the same multicast address and
   interface.  After a multicast packet has been accepted from an
   interface by the IP layer, its subsequent delivery to the application
   connected to a particular socket depends on the multicast listening
   state of that socket (and possibly also on other conditions, such as
   what transport-layer port the socket is bound to).  Note that MLDv2
   messages are not subject to source filtering and must always be
   processed by hosts and routers.

2.2.  Exchanging Messages between the Querier and the Listening Nodes

   There are three types of MLDv2 query messages: General Queries,
   Multicast Address Specific Queries, and Multicast Address and Source
   Specific Queries.  The Querier periodically sends General Queries, to
   learn multicast address listener information from an attached link.
   These queries are used to build and refresh the Multicast Address
   Listener state inside all multicast routers on the link.

   Nodes respond to these queries by reporting their per-interface
   Multicast Address Listening state, through Current State Report
   messages sent to a specific multicast address all MLDv2 routers on



Vida & Costa                Standards Track                     [Page 4]

RFC 3810                     MLDv2 for IPv6                    June 2004


   the link listen to.  On the other hand, if the listening state of a
   node changes, the node immediately reports these changes through a
   State Change Report message.  The State Change Report contains either
   Filter Mode Change records, Source List Change records, or records of
   both types.  A detailed description of the report messages is
   presented in section 5.2.12.

   Both router and listener state changes are mainly triggered by the
   expiration of a specific timer, or the reception of an MLD message
   (listener state change can be also triggered by the invocation of a
   service interface call).  Therefore, to enhance protocol robustness,
   in spite of the possible unreliability of message exchanges, messages
   are retransmitted several times.  Furthermore, timers are set so as
   to take into account the possible message losses, and to wait for
   retransmissions.

   Periodical General Queries and Current State Reports do not apply
   this rule, in order not to overload the link; it is assumed that in
   general these messages do not generate state changes, their main
   purpose being to refresh existing state.  Thus, even if one such
   message is lost, the corresponding state will be refreshed during the
   next reporting period.

   As opposed to Current State Reports, State Change Reports are
   retransmitted several times, in order to avoid them being missed by
   one or more multicast routers.  The number of retransmissions depends
   on the so-called Robustness Variable.  This variable allows tuning
   the protocol according to the expected packet loss on a link.  If a
   link is expected to be lossy (e.g., a wireless connection), the value
   of the Robustness Variable may be increased.  MLD is robust to
   [Robustness Variable]-1 packet losses.  This document recommends a
   default value of 2 for the Robustness Variable (see section 9.1).

   If more changes to the same per-interface state entry occur before
   all the retransmissions of the State Change Report for the first
   change have been completed, each additional change triggers the
   immediate transmission of a new State Change Report.  Section 6.1
   shows how the content of this new report is computed. Retransmissions
   of the new State Change Report will be scheduled as well, in order to
   ensure that each instance of state change is transmitted at least
   [Robustness Variable] times.

   If a node on a link expresses, through a State Change Report, its
   desire to no longer listen to a particular multicast address (or
   source),  the Querier must query for other listeners of the multicast
   address (or source) before deleting the multicast address (or source)
   from its Multicast Address Listener state and stopping the
   corresponding traffic.  Thus, the Querier sends a Multicast Address



Vida & Costa                Standards Track                     [Page 5]

RFC 3810                     MLDv2 for IPv6                    June 2004


   Specific Query to verify whether there are nodes still listening to a
   specified multicast address or not.  Similarly, the Querier sends a
   Multicast Address and Source Specific Query to verify whether, for a
   specified multicast address, there are nodes still listening to a
   specific set of sources, or not.  Section 5.1.13 describes each query
   in more detail.

   Both Multicast Address Specific Queries and Multicast Address and