doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc2710.txt b/doc/rfc/rfc2710.txt
new file mode 100644
index 0000000..50d1165
--- /dev/null
+++ b/doc/rfc/rfc2710.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+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
+   that address, thus suppressing duplicate reports on the link.
+
+   When a router receives a Report from a link, if the reported address
+   is not already present in the router's list of multicast address
+   having listeners on that link, the reported address is added to the
+   list, its timer is set to [Multicast Listener Interval], and its
+   appearance is made known to the router's multicast routing component.
+   If a Report is received for a multicast address that is already
+   present in the router's list, the timer for that address is reset to
+   [Multicast Listener Interval].  If an address's timer expires, it is
+   assumed that there are no longer any listeners for that address
+   present on the link, so it is deleted from the list and its
+   disappearance is made known to the multicast routing component.
+
+   When a node starts listening to a multicast address on an interface,
+   it should immediately transmit an unsolicited Report for that address
+   on that interface, in case it is the first listener on the link.  To
+   cover the possibility of the initial Report being lost or damaged, it
+   is recommended that it be repeated once or twice after short delays
+   [Unsolicited Report Interval].  (A simple way to accomplish this is
+   to send the initial Report and then act as if a Multicast-Address-
+   Specific Query was received for that address, and set a timer
+   appropriately).
+
+
+
+
+
+Deering, et al.             Standards Track                     [Page 6]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+   When a node ceases to listen to a multicast address on an interface,
+   it SHOULD send a single Done message to the link-scope all-routers
+   multicast address (FF02::2), carrying in its Multicast Address field
+   the address to which it is ceasing to listen.  If the node's most
+   recent Report message was suppressed by hearing another Report
+   message, it MAY send nothing, as it is highly likely that there is
+   another listener for that address still present on the same link.  If
+   this optimization is implemented, it MUST be able to be turned off
+   but SHOULD default to on.
+
+   When a router in Querier state receives a Done message from a link,
+   if the Multicast Address identified in the message is present in the
+   Querier's list of addresses having listeners on that link, the
+   Querier sends [Last Listener Query Count] Multicast-Address-Specific
+   Queries, one every [Last Listener Query Interval] to that multicast
+   address.  These Multicast-Address-Specific Queries have their Maximum
+   Response Delay set to [Last Listener Query Interval].  If no Reports
+   for the address are received from the link after the response delay
+   of the last query has passed, the routers on the link assume that the
+   address no longer has any listeners there; the address is therefore
+   deleted from the list and its disappearance is made known to the
+   multicast routing component.  This process is continued to its
+   resolution (i.e. until a Report is received or the last Multicast-
+   Address-Specific Query is sent with no response) despite any
+   transition from Querier to Non-Querier on this link.
+
+   Routers in Non-Querier state MUST ignore Done messages.
+
+   When a router in Non-Querier state receives a Multicast-Address-
+   Specific Query, if its timer value for the identified multicast
+   address is greater than [Last Listener Query Count] times the Maximum
+   Response Delay specified in the message, it sets the address's timer
+   to that latter value.
+
+5.  Node State Transition Diagram
+
+   Node behavior is more formally specified by the state transition
+   diagram below.  A node may be in one of three possible states with
+   respect to any single IPv6 multicast address on any single interface:
+
+   - "Non-Listener" state, when the node is not listening to the address
+      on the interface (i.e., no upper-layer protocol or application has
+      requested reception of packets to that multicast address).  This
+      is the initial state for all multicast addresses on all
+      interfaces; it requires no storage in the node.
+
+
+
+
+
+
+Deering, et al.             Standards Track                     [Page 7]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+   - "Delaying Listener" state, when the node is listening to the
+      address on the interface and has a report delay timer running for
+      that address.
+
+   - "Idle Listener" state, when the node is listening to the address on
+      the interface and does not have a report delay timer running for
+      that address.
+
+   There are five significant events that can cause MLD state
+   transitions:
+
+   - "start listening" occurs when the node starts listening to the
+      address on the interface.  It may occur only in the Non-Listener
+      state.
+
+   - "stop listening" occurs when the node stops listening to the
+      address on the interface.  It may occur only in the Delaying
+      Listener and Idle Listener states.
+
+   - "query received" occurs when the node receives either a valid
+      General Query message, or a valid Multicast-Address-Specific Query
+      message.  To be valid, the Query message MUST come from a link-
+      local IPv6 Source Address, be at least 24 octets long, and have a
+      correct MLD checksum.  The Multicast Address field in the MLD
+      message must contain either zero (a General Query) or a valid
+      multicast address (a Multicast- Address-Specific Query).  A
+      General Query applies to all multicast addresses on the interface
+      from which the Query is received.  A Multicast-Address-Specific
+      Query applies to a single multicast address on the interface from
+      which the Query is received.  Queries are ignored for addresses in
+      the Non-Listener state.
+
+   - "report received" occurs when the node receives a valid MLD Report
+      message.  To be valid, the Report message MUST come from a link-
+      local IPv6 Source Address, be at least 24 octets long, and have a
+      correct MLD checksum.  A Report applies only to the address
+      identified in the Multicast Address field of the Report, on the
+      interface from which the Report is received.  It is ignored in the
+      Non-Listener or Idle Listener state.
+
+   - "timer expired" occurs when the report delay timer for the address
+      on the interface expires.  It may occur only in the Delaying
+      Listener state.
+
+
+
+
+
+
+
+
+Deering, et al.             Standards Track                     [Page 8]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+   All other events, such as receiving invalid MLD messages or MLD
+   message types other than Query or Report, are ignored in all states.
+
+   There are seven possible actions that may be taken in response to the
+   above events:
+
+   - "send report" for the address on the interface.  The Report message
+      is sent to the address being reported.
+
+   - "send done" for the address on the interface.  If the flag saying
+      we were the last node to report is cleared, this action MAY be
+      skipped.  The Done message is sent to the link-scope all-routers
+      address (FF02::2).
+
+   - "set flag" that we were the last node to send a report for this
+      address.
+
+   - "clear flag" since we were not the last node to send a report for
+      this address.
+
+   - "start timer" for the address on the interface, using a delay value
+      chosen uniformly from the interval [0, Maximum Response Delay],
+      where Maximum Response Delay is specified in the Query.  If this
+      is an unsolicited Report, the timer is set to a delay value chosen
+      uniformly from the interval [0, [Unsolicited Report Interval] ].
+
+   - "reset timer" for the address on the interface to a new value,
+      using a delay value chosen uniformly from the interval [0, Maximum
+      Response Delay], as described in "start timer".
+
+   - "stop timer" for the address on the interface.
+
+   In all of the following state transition diagrams, each state
+   transition arc is labeled with the event that causes the transition,
+   and, in parentheses, any actions taken during the transition.  Note
+   that the transition is always triggered by the event; even if the
+   action is conditional, the transition still occurs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deering, et al.             Standards Track                     [Page 9]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+                             ________________
+                            |                |
+                            |                |
+                            |                |
+                            |                |
+                  --------->|  Non-Listener  |<---------
+                 |          |                |          |
+                 |          |                |          |
+                 |          |                |          |
+                 |          |________________|          |
+                 |                   |                  |
+                 | stop listening    | start listening  | stop listening
+                 | (stop timer,      |(send report,     | (send done if
+                 |  send done if     | set flag,        |  flag set)
+                 |  flag set)        | start timer)     |
+         ________|________           |          ________|________
+        |                 |<---------          |                 |
+        |                 |                    |                 |
+        |                 |<-------------------|                 |
+        |                 |   query received   |                 |
+        |     Delaying    |    (start timer)   |      Idle       |
+   ---->|     Listener    |------------------->|     Listener    |
+  |     |                 |   report received  |                 |
+  |     |                 |    (stop timer,    |                 |
+  |     |                 |     clear flag)    |                 |
+  |     |_________________|------------------->|_________________|
+  | query received    |        timer expired
+  | (reset timer if   |        (send report,
+  |  Max Resp Delay   |         set flag)
+  |  < current timer) |
+   -------------------
+
+   The link-scope all-nodes address (FF02::1) is handled as a special
+   case.  The node starts in Idle Listener state for that address on
+   every interface, never transitions to another state, and never sends
+   a Report or Done for that address.
+
+   MLD messages are never sent for multicast addresses whose scope is 0
+   (reserved) or 1 (node-local).
+
+   MLD messages ARE sent for multicast addresses whose scope is 2
+   (link-local), including Solicited-Node multicast addresses [ADDR-
+   ARCH], except for the link-scope, all-nodes address (FF02::1).
+
+
+
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 10]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+6.  Router State Transition Diagram
+
+   Router behavior is more formally specified by the state transition
+   diagrams below.
+
+   A router may be in one of two possible states with respect to any
+   single attached link:
+
+   - "Querier", when this router is designated to transmit MLD Queries
+      on this link.
+
+   - "Non-Querier", when there is another router designated to transmit
+      MLD Queries on this link.
+
+   The following three events can cause the router to change states:
+
+   - "query timer expired" occurs when the timer set for query
+      transmission expires.  This event is significant only when in the
+      Querier state.
+
+   - "query received from a router with a lower IP address" occurs when
+      a valid MLD Query is received from a router on the same link with
+      a lower IPv6 Source Address. To be valid, the Query message MUST
+      come from a link-local IPv6 Source Address, be at least 24 octets
+      long, and have a correct MLD checksum.
+
+   - "other querier present timer expired" occurs when the timer set to
+      note the presence of another querier with a lower IP address on
+      the link expires.  This event is significant only when in the
+      Non-Querier state.
+
+   There are three actions that may be taken in response to the above
+   events:
+
+   - "start general query timer" for the attached link to [Query
+      Interval].
+
+   - "start other querier present timer" for the attached link to [Other
+      Querier Present Interval].
+
+   - "send general query" on the attached link.  The General Query is
+      sent to the link-scope all-nodes address (FF02::1), and has a
+      Maximum Response Delay of [Query Response Interval].
+
+
+
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 11]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+                                     --------------------------------
+                             _______|________  gen. query timer      |
+ ---------                  |                |        expired        |
+| Initial |---------------->|                | (send general query,  |
+ ---------  (send gen. q.,  |                |  start gen. q. timer) |
+     start initial gen. q.  |                |<----------------------
+             timer)         |    Querier     |
+                            |                |
+                       -----|                |<---
+                      |     |                |    |
+                      |     |________________|    |
+query received from a |                           | other querier
+router with a lower   |                           | present timer
+IP address            |                           | expired
+(start other querier  |      ________________     | (send gen. query,
+ present timer)       |     |                |    | start gen. q. timer)
+                      |     |                |    |
+                      |     |                |    |
+                       ---->|      Non       |----
+                            |    Querier     |
+                            |                |
+                            |                |
+                       ---->|                |----
+                      |     |________________|    |
+                      | query received from a     |
+                      | router with a lower IP    |
+                      | address                   |
+                      | (start other querier      |
+                      |  present timer)           |
+                       ---------------------------
+
+   A router starts in the Initial state on all attached links, and
+   immediately transitions to Querier state.
+
+   In addition, to keep track of which multicast addresses have
+   listeners, a router may be in one of three possible states with
+   respect to any single IPv6 multicast address on any single attached
+   link:
+
+   - "No Listeners Present" state, when there are no nodes on the link
+      that have sent a Report for this multicast address.  This is the
+      initial state for all multicast addresses on the router; it
+      requires no storage in the router.
+
+   - "Listeners Present" state, when there is a node on the link that
+      has sent a Report for this multicast address.
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 12]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+   - "Checking Listeners" state, when the router has received a Done
+      message but has not yet heard a Report for the identified address.
+
+   There are five significant events that can cause router state
+   transitions:
+
+   - "report received" occurs when the router receives a Report for the
+      address from the link.  To be valid, the Report message MUST come
+      from a link-local IPv6 Source Address, be at least 24 octets long,
+      and have a correct MLD checksum.
+
+   - "done received" occurs when the router receives a Done message for
+      the address from the link.  To be valid, the Done message MUST
+      come from a link-local IPv6 Source Address, be at least 24 octets
+      long, and have a correct MLD checksum.  This event is significant
+      only in the "Listerners Present" state and when the router is a
+      Querier.
+
+   - "multicast-address-specific query received" occurs when a router
+      receives a Multicast-Address-Specific Query for the address from
+      the link.  To be valid, the Query message MUST come from a link-
+      local IPv6 Source Address, be at least 24 octets long, and have a
+      correct MLD checksum.  This event is significant only in the
+      "Listeners Present" state and when the router is a Non-Querier.
+
+   - "timer expired" occurs when the timer set for a multicast address
+      expires.  This event is significant only in the "Listeners
+      Present" or "Checking Listeners" state.
+
+   - "retransmit timer expired" occurs when the timer set to retransmit
+      a Multicast-Address-Specific Query expires.  This event is
+      significant only in the "Checking Listeners" state.
+
+   There are seven possible actions that may be taken in response to the
+   above events:
+
+   - "start timer" for the address on the link - also resets the timer
+      to its initial value [Multicast Listener Interval] if the timer is
+      currently running.
+
+   - "start timer*" for the address on the link - this alternate action
+      sets the timer to the minimum of its current value and either
+      [Last Listener Query Interval] * [Last Listener Query Count] if
+      this router is a Querier, or the Maximum Response Delay in the
+      Query message * [Last Listener Query Count] if this router is a
+      non-Querier.
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 13]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+   - "start retransmit timer" for the address on the link [Last Listener
+      Query Interval].
+
+   - "clear retransmit timer" for the address on the link.
+
+   - "send multicast-address-specific query" for the address on the
+      link.  The Multicast-Address-Specific Query is sent to the address
+      being queried, and has a Maximum Response Delay of [Last Listener
+      Query Interval].
+
+   - "notify routing +" internally notify the multicast routing protocol
+      that there are listeners to this address on this link.
+
+   - "notify routing -" internally notify the multicast routing protocol
+      that there are no longer any listeners to this address on this
+      link.
+
+   The following state diagrams apply per group per link.  There are two
+   diagrams; one for routers in Querier state and one for routers in
+   Non-Querier state.  The transition between Querier and Non-Querier
+   state on a link is handled specially.  All groups on that link in "No
+   Listeners Present" or "Listeners Present" states switch state
+   transition diagrams when the Querier/Non-Querier state transition
+   occurs.  However, any groups in "Checking Listeners" state continue
+   with the same state transition diagram until the "Checking Listeners"
+   state is exited.  E.g. a router that starts as a Querier, receives a
+   Done message for a group and then receives a Query from a router with
+   a lower address (causing a transition to the Non-Querier state)
+   continues to send multicast-address-specific queries for the group in
+   question until it either receives a Report or its timer expires, at
+   which time it starts performing the actions of a Non-Querier for this
+   group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 14]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+   The state transition diagram for a router in Querier state follows:
+
+                          ________________
+                         |                |
+                         |                |timer expired
+            timer expired|                |(notify routing -,
+       (notify routing -)|  No Listeners  |clear rxmt tmr)
+                 ------->|    Present     |<---------
+                |        |                |          |
+                |        |                |          |
+                |        |________________|          |  ---------------
+                |                    |               | | rexmt timer   |
+                |     report received|               | |  expired      |
+                |  (notify routing +,|               | | (send m-a-s   |
+                |        start timer)|               | |  query,       |
+      __________|______              |       ________|_|______ st rxmt |
+     |                 |<------------       |                 | tmr)   |
+     |                 |                    |                 |<-------
+     |                 | report received    |                 |
+     |                 | (start timer,      |                 |
+     |                 |  clear rxmt tmr)   |                 |
+     |    Listeners    |<-------------------|    Checking     |
+     |     Present     | done received      |    Listeners    |
+     |                 | (start timer*,     |                 |
+     |                 |  start rxmt timer, |                 |
+     |                 |  send m-a-s query) |                 |
+ --->|                 |------------------->|                 |
+|    |_________________|                    |_________________|
+| report received |
+| (start timer)   |
+ -----------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 15]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+   The state transition diagram for a router in Non-Querier state is
+   similar, but non-Queriers do not send any messages and are only
+   driven by message reception.
+
+                              ________________
+                             |                |
+                             |                |
+                timer expired|                |timer expired
+           (notify routing -)|  No Listeners  |(notify routing -)
+                   --------->|    Present     |<---------
+                  |          |                |          |
+                  |          |                |          |
+                  |          |                |          |
+                  |          |________________|          |
+                  |                   |                  |
+                  |                   |report received   |
+                  |                   |(notify routing +,|
+                  |                   | start timer)     |
+          ________|________           |          ________|________
+         |                 |<---------          |                 |
+         |                 |  report received   |                 |
+         |                 |  (start timer)     |                 |
+         |    Listeners    |<-------------------|     Checking    |
+         |     Present     | m-a-s query rec'd  |    Listeners    |
+         |                 | (start timer*)     |                 |
+    ---->|                 |------------------->|                 |
+   |     |_________________|                    |_________________|
+   | report received |
+   | (start timer)   |
+    -----------------
+
+7.  List of timers and default values
+
+   Most of these timers are configurable.  If non-default settings are
+   used, they MUST be consistent among all routers on a single link.
+   Note that parentheses are used to group expressions to make the
+   algebra clear.
+
+7.1.  Robustness Variable
+
+   The Robustness Variable allows tuning for the expected packet loss on
+   a link.  If a link is expected to be lossy, the Robustness Variable
+   may be increased.  MLD is robust to (Robustness Variable - 1) packet
+   losses.  The Robustness Variable MUST NOT be zero, and SHOULD NOT be
+   one.  Default: 2
+
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 16]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+7.2.  Query Interval
+
+   The Query Interval is the interval between General Queries sent by
+   the Querier.  Default: 125 seconds.
+
+   By varying the [Query Interval], an administrator may tune the number
+   of MLD messages on the link; larger values cause MLD Queries to be
+   sent less often.
+
+7.3.  Query Response Interval
+
+   The Maximum Response Delay inserted into the periodic General
+   Queries.  Default: 10000 (10 seconds)
+
+   By varying the [Query Response Interval], an administrator may tune
+   the burstiness of MLD messages on the link; larger values make the
+   traffic less bursty, as node responses are spread out over a larger
+   interval.  The number of seconds represented by the [Query Response
+   Interval] must be less than the [Query Interval].
+
+7.4.  Multicast Listener Interval
+
+   The Multicast Listener Interval is the amount of time that must pass
+   before a router decides there are no more listeners for an address on
+   a link.  This value MUST be ((the Robustness Variable) times (the
+   Query Interval)) plus (one Query Response Interval).
+
+7.5.  Other Querier Present Interval
+
+   The Other Querier Present Interval is the length of time that must
+   pass before a router decides that there is no longer another router
+   which should be the querier on a link.  This value MUST be ((the
+   Robustness Variable) times (the Query Interval)) plus (one half of
+   one Query Response Interval).
+
+7.6.  Startup Query Interval
+
+   The Startup Query Interval is the interval between General Queries
+   sent by a Querier on startup.  Default: 1/4 the Query Interval.
+
+7.7.  Startup Query Count
+
+   The Startup Query Count is the number of Queries sent out on startup,
+   separated by the Startup Query Interval.  Default: the Robustness
+   Variable.
+
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 17]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+7.8.  Last Listener Query Interval
+
+   The Last Listener Query Interval is the Maximum Response Delay
+   inserted into Multicast-Address-Specific Queries sent in response to
+   Done messages, and is also the amount of time between Multicast-
+   Address-Specific Query messages.  Default: 1000 (1 second)
+
+   This value may be tuned to modify the "leave latency" of the link.  A
+   reduced value results in reduced time to detect the departure of the
+   last listener for an address.
+
+7.9.  Last Listener Query Count
+
+   The Last Listener Query Count is the number of Multicast-Address-
+   Specific Queries sent before the router assumes there are no
+   remaining listeners for an address on a link.  Default: the
+   Robustness Variable.
+
+7.10.  Unsolicited Report Interval
+
+   The Unsolicited Report Interval is the time between repetitions of a
+   node's initial report of interest in a multicast address.  Default:
+   10 seconds.
+
+8.  Message Destinations
+
+   This information is provided elsewhere in the document, but is
+   summarized here for convenience.
+
+Message Type                       IPv6 Destination Address
+------------                       ------------------------
+General Query                      link-scope all-nodes (FF02::1)
+Multicast-Address-Specific Query   the multicast address being queried
+Report                             the multicast address being reported
+Done                               link-scope all-routers (FF02::2)
+
+9.  Security Considerations
+
+   We consider the ramifications of a forged message of each type.  Note
+   that the requirement that nodes verify that the IPv6 Source Address
+   of all received MLD messages is a link-local address defends them
+   from acting on forged MLD messages originated off-link, so we discuss
+   only the effects of on-link forgery.
+
+
+
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 18]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+   Query message:
+
+        A forged Query message from a machine with a lower IP address
+        than the current Querier will cause Querier duties to be
+        assigned to the forger.  If the forger then sends no more Query
+        messages, other routers' Other Querier Present timer will time
+        out and one will resume the role of Querier.  During this time,
+        if the forger ignores Done messages, traffic might flow to
+        addresses with no listeners for up to [Multicast Listener
+        Interval].
+
+        A forged Query message sent to an address with listeners will
+        cause one or more nodes that are listeners to that address to
+        send a Report.  This causes a small amount of extra traffic on
+        the link, but causes no protocol problems.
+
+   Report message:
+
+        A forged Report message may cause routers to think there are
+        listeners for an address present on a link when there are not.
+        However, since listening to a multicast address is generally an
+        unprivileged operation, a local user may trivially gain the same
+        result without forging any messages.
+
+   Done message:
+
+        A forged Done message will cause the Querier to send out
+        Multicast-Address-Specific Queries for the address in question.
+        This causes extra processing on each router and on each of the
+        address's listeners, and extra packets on the link, but cannot
+        cause loss of desired traffic.
+
+10.  Acknowledgments
+
+   MLD was derived from IGMPv2 [IGMPv2], which was designed by Rosen
+   Sharma and Steve Deering and documented by Bill Fenner.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 19]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+11.  References
+
+   [ADDR-ARCH]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+                Architecture", RFC 2373, July 1998.
+
+   [ICMPv6]     Conta, A. and S. Deering, "Internet Control Message
+                Protocol (ICMPv6) for the Internet Protocol Version 6
+                (IPv6) Specification", RFC 2463, December 1998.
+
+   [IGMPv2]     Fenner, W., "Internet Group Management Protocol, Version
+                2", RFC 2236, November 1997.
+
+   [IPv6]       Deering, S. and R. Hinden, "Internet Protocol, Version 6
+                (IPv6) Specification", RFC 2460, December 1998.
+
+   [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
+                Ethernet Networks", RFC 2464, December, 1998.
+
+   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RTR-ALERT]  Partridge, C. and A. Jackson, "IPv6 Router Alert
+                Option", RFC 2711, October 1999.
+
+   [STD-PROC]   Bradner, S., "The Internet Standards Process -- Revision
+                3", BCP 9, RFC 2026, October 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 20]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+12.  Authors' Addresses
+
+   Stephen E. Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+   Phone: +1 408 527 8213
+   EMail: deering@cisco.com
+
+
+   William C. Fenner
+   AT&T Research
+   75 Willow Road
+   Menlo Park, CA 94025
+   USA
+
+   Phone: +1 650 867 6073
+   EMail: fenner@research.att.com
+
+
+   Brian Haberman
+   IBM Corporation
+   800 Park Office Drive
+   Research Triangle Park, NC  27709
+   USA
+
+   Phone: +1 919 254 2673
+   EMail: haberman@raleigh.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 21]
+
+RFC 2710         Multicast Listener Discovery for IPv6      October 1999
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deering, et al.             Standards Track                    [Page 22]
+