rfc2710.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/4 页

Network Working Group                                        S. Deering
Request for Comments: 2710                                Cisco Systems
Category: Standards Track                                     W. Fenner
                                                          AT&T Research
                                                            B. Haberman
                                                                    IBM
                                                           October 1999


              Multicast Listener Discovery (MLD) 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 (1999).  All Rights Reserved.

Abstract

   This document specifies the protocol used by an IPv6 router to
   discover the presence of multicast listeners (that is, nodes wishing
   to receive multicast packets) on its directly attached links, and to
   discover specifically which multicast addresses are of interest to
   those neighboring nodes.  This protocol is referred to as Multicast
   Listener Discovery or MLD.  MLD is derived from version 2 of IPv4's
   Internet Group Management Protocol, IGMPv2.  One important difference
   to note is that MLD uses ICMPv6 (IP Protocol 58) message types,
   rather than IGMP (IP Protocol 2) message types.

1.  Definitions

   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 [KEYWORDS].

2.  Introduction

   The purpose of Multicast Listener Discovery (MLD) is to enable each
   IPv6 router to discover the presence of multicast listeners (that is,
   nodes wishing to receive multicast packets) on its directly attached
   links, and to discover specifically which multicast addresses are of
   interest to those neighboring nodes.  This information is then



Deering, et al.             Standards Track                     [Page 1]

RFC 2710         Multicast Listener Discovery for IPv6      October 1999


   provided to whichever multicast routing protocol is being used by the
   router, in order to ensure that multicast packets are delivered to
   all links where there are interested receivers.

   MLD is an asymmetric protocol, specifying different behaviors for
   multicast listeners and for routers.  For those multicast addresses
   to which a router itself is listening, the router performs both parts
   of the protocol, including responding to its own messages.

   If a router has more than one interface to the same link, it need
   perform the router part of MLD over only one of those interfaces.
   Listeners, on the other hand, must perform the listener part of MLD
   on all interfaces from which an application or upper-layer protocol
   has requested reception of multicast packets.

3.  Message Format

   MLD is a sub-protocol of ICMPv6, that is, MLD message types are a
   subset of the set of ICMPv6 messages, and MLD messages are identified
   in IPv6 packets by a preceding Next Header value of 58.  All MLD
   messages described in this document are sent with a link-local IPv6
   Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert
   option [RTR-ALERT] in a Hop-by-Hop Options header.  (The Router Alert
   option is necessary to cause routers to examine MLD messages sent to
   multicast addresses in which the routers themselves have no
   interest.)

   MLD messages have the following format:

    0                   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      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Maximum Response Delay    |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Multicast Address                       +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Deering, et al.             Standards Track                     [Page 2]

RFC 2710         Multicast Listener Discovery for IPv6      October 1999


3.1.  Type

   There are three types of MLD messages:

   Multicast Listener Query (Type = decimal 130)

      There are two subtypes of Multicast Listener Query messages:

      - General Query, used to learn which multicast addresses have
        listeners on an attached link.
      - Multicast-Address-Specific Query, used to learn if a
        particular multicast address has any listeners on an attached
        link.

      These two subtypes are differentiated by the contents of the
      Multicast Address field, as described in section 3.6.

      Multicast Listener Report (Type = decimal 131)

      Multicast Listener Done (Type = decimal 132)

   In the rest of this document, the above messages types are referred
   to simply as "Query", "Report", and "Done".

3.2.  Code

   Initialized to zero by the sender; ignored by receivers.

3.3.  Checksum

   The standard ICMPv6 checksum, covering the entire MLD message plus a
   "pseudo-header" of IPv6 header fields [ICMPv6,IPv6].

3.4.  Maximum Response Delay

   The Maximum Response Delay field is meaningful only in Query
   messages, and specifies the maximum allowed delay before sending a
   responding Report, in units of milliseconds.  In all other messages,
   it is set to zero by the sender and ignored by receivers.

   Varying this value allows the routers to tune the "leave latency"
   (the time between the moment the last node on a link ceases listening
   to a particular multicast address and moment the routing protocol is
   notified that there are no longer any listeners for that address), as
   discussed in section 7.8.  It also allows tuning of the burstiness of
   MLD traffic on a link, as discussed in section 7.3.





Deering, et al.             Standards Track                     [Page 3]

RFC 2710         Multicast Listener Discovery for IPv6      October 1999


3.5.  Reserved

   Initialized to zero by the sender; ignored by receivers.

3.6.  Multicast Address

   In a Query message, the Multicast Address field is set to zero when
   sending a General Query, and set to a specific IPv6 multicast address
   when sending a Multicast-Address-Specific Query.

   In a Report or Done message, the Multicast Address field holds a
   specific IPv6 multicast address to which the message sender is
   listening or is ceasing to listen, respectively.

3.7.  Other fields

   The length of a received MLD message is computed by taking the IPv6
   Payload Length value and subtracting the length of any IPv6 extension
   headers present between the IPv6 header and the MLD message.  If that
   length is greater than 24 octets, that indicates that there are other
   fields present beyond the fields described above, perhaps belonging
   to a future backwards-compatible version of MLD.  An implementation
   of the version of MLD specified in this document MUST NOT send an MLD
   message longer than 24 octets and MUST ignore anything past the first
   24 octets of a received MLD message.  In all cases, the MLD checksum
   MUST be computed over the entire MLD message, not just the first 24
   octets.

4.  Protocol Description

   Note that defaults for timer values are described later in this
   document.  Timer and counter names appear in square brackets.

   Routers use MLD to learn which multicast addresses have listeners on
   each of their attached links.  Each router keeps a list, for each
   attached link, of which multicast addresses have listeners on that
   link, and a timer associated with each of those addresses.  Note that
   the router needs to learn only that listeners for a given multicast
   address are present on a link; it does NOT need to learn the identity
   (e.g., unicast address) of those listeners or even how many listeners
   are present.

   For each attached link, a router selects one of its link-local
   unicast addresses on that link to be used as the IPv6 Source Address
   in all MLD packets it transmits on that link.






Deering, et al.             Standards Track                     [Page 4]

RFC 2710         Multicast Listener Discovery for IPv6      October 1999


   For each interface over which the router is operating the MLD
   protocol, the router must configure that interface to listen to all
   link-layer multicast address that can be generated by IPv6
   multicasts.  For example, an Ethernet-attached router must set its
   Ethernet address reception filter to accept all Ethernet multicast
   addresses that start with the hexadecimal value 3333 [IPv6-ETHER]; in
   the case of an Ethernet interface that does not support the filtering
   of such a range of multicast address, it must be configured to accept
   ALL Ethernet multicast addresses, in order to meet the requirements
   of MLD.

   With respect to each of its attached links, a router may assume one
   of two roles: Querier or Non-Querier.  There is normally only one
   Querier per link.  All routers start up as a Querier on each of their
   attached links.  If a router hears a Query message whose IPv6 Source
   Address is numerically less than its own selected address for that
   link, it MUST become a Non-Querier on that link.  If [Other Querier
   Present Interval] passes without receiving, from a particular
   attached link, any Queries from a router with an address less than
   its own, a router resumes the role of Querier on that link.

   A Querier for a link periodically [Query Interval] sends a General
   Query on that link, to solicit reports of all multicast addresses of
   interest on that link.  On startup, a router SHOULD send [Startup
   Query Count] General Queries spaced closely together [Startup Query
   Interval] on all attached links in order to quickly and reliably
   discover the presence of multicast listeners on those links.

   General Queries are sent to the link-scope all-nodes multicast
   address (FF02::1), with a Multicast Address field of 0, and a Maximum
   Response Delay of [Query Response Interval].

   When a node receives a General Query, it sets a delay timer for each
   multicast address to which it is listening on the interface from
   which it received the Query, EXCLUDING the link-scope all-nodes
   address and any multicast addresses of scope 0 (reserved) or 1
   (node-local).  Each timer is set to a different random value, using
   the highest clock granularity available on the node, selected from
   the range [0, Maximum Response Delay] with Maximum Response Delay as
   specified in the Query packet.  If a timer for any address is already
   running, it is reset to the new random value only if the requested
   Maximum Response Delay is less than the remaining value of the
   running timer.  If the Query packet specifies a Maximum Response
   Delay of zero, each timer is effectively set to zero, and the action
   specified below for timer expiration is performed immediately.






Deering, et al.             Standards Track                     [Page 5]

RFC 2710         Multicast Listener Discovery for IPv6      October 1999


   When a node receives a Multicast-Address-Specific Query, if it is
   listening to the queried Multicast Address on the interface from
   which the Query was received, it sets a delay timer for that address
   to a random value selected from the range [0, Maximum Response
   Delay], as above.  If a timer for the address is already running, it
   is reset to the new random value only if the requested Maximum
   Response Delay is less than the remaining value of the running timer.
   If the Query packet specifies a Maximum Response Delay of zero, the
   timer is effectively set to zero, and the action specified below for
   timer expiration is performed immediately.

   If a node's timer for a particular multicast address on a particular
   interface expires, the node transmits a Report to that address via
   that interface; the address being reported is carried in both the
   IPv6 Destination Address field and the MLD Multicast Address field of
   the Report packet.  The IPv6 Hop Limit of 1 (as well as the presence
   of a link-local IPv6 Source Address) prevent the packet from
   traveling beyond the link to which the reporting interface is
   attached.

   If a node receives another node's Report from an interface for a
   multicast address while it has a timer running for that same address
   on that interface, it stops its timer and does not send a Report for