rfc3810.txt

xorp源码hg

      entry is present, a new entry is created, using the parameters
      specified in the request.

4.2.  Per-Interface State

   In addition to the per-socket multicast listening state, a node must
   also maintain or compute multicast listening state for each of its
   interfaces.  That state conceptually consists of a set of records of
   the form:

      (IPv6 multicast address, filter mode, 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.  For example, suppose one application or process invokes
   the following operation on socket s1:

      IPv6MulticastListen ( s1, i, m, INCLUDE, {a, b, c} )









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


   requesting reception on interface i of packets sent to multicast
   address m, *only* if they come from the sources a, b, or c.  Suppose
   another application or process invokes the following operation on
   socket s2:

      IPv6MulticastListen ( s2, i, m, INCLUDE, {b, c, d} )

   requesting reception on the same interface i of packets sent to the
   same multicast address m, *only* if they come from sources b, c, or
   d.  In order to satisfy the reception requirements of both sockets,
   it is necessary for interface i to receive packets sent to m from any
   one of the sources a, b, c, or d.  Thus, in this example, the
   listening state of interface i for multicast address m has filter
   mode INCLUDE and source list {a, b, c, d}.

   After a multicast packet has been accepted from an interface by the
   IP layer, its subsequent delivery to the application or process that
   listens on 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).  So, in the above
   example, if a packet arrives on interface i, destined to multicast
   address m, with source address a, it may be delivered on socket s1
   but not on socket s2.  Note that MLDv2 messages are not subject to
   source filtering and must always be processed by hosts and routers.

   Requiring the filtering of packets based upon a socket's multicast
   reception state is a new feature of this service interface.  The
   previous service interface described no filtering based upon
   multicast listening state; rather, a Start Listening operation on a
   socket simply caused the node to start to listen to a multicast
   address on the given interface; packets sent to that multicast
   address could be delivered to all sockets, whether they had started
   to listen or not.

   The general rules for deriving the per-interface state from the per-
   socket state are as follows:  for each distinct (interface, IPv6
   multicast address) pair that appears in any per-socket state, a per-
   interface record is created for that multicast address on that
   interface.  Considering all socket records that contain the same
   (interface, IPv6 multicast address) pair,

   o  if *any* such record has a filter mode of EXCLUDE, then the filter
      mode of the interface record is EXCLUDE, and the source list of
      the interface record is the intersection of the source lists of
      all socket records in EXCLUDE mode, minus those source addresses
      that appear in any socket record in INCLUDE mode.  For example, if
      the socket records for multicast address m on interface i are:




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


         from socket s1:  ( i, m, EXCLUDE, {a, b, c, d} )
         from socket s2:  ( i, m, EXCLUDE, {b, c, d, e} )
         from socket s3:  ( i, m, INCLUDE, {d, e, f} )

      then the corresponding interface record on interface i is:

         ( m, EXCLUDE, {b, c} )

      If a fourth socket is added, such as:

         From socket s4:  ( i, m, EXCLUDE, {} )

      then the interface record becomes:

         ( m, EXCLUDE, {} )

   o  if *all* such records have a filter mode of INCLUDE, then the
      filter mode of the interface record is INCLUDE, and the source
      list of the interface record is the union of the source lists of
      all the socket records.  For example, if the socket records for
      multicast address m on interface i are:

         from socket s1:  ( i, m, INCLUDE, {a, b, c} )
         from socket s2:  ( i, m, INCLUDE, {b, c, d} )
         from socket s3:  ( i, m, INCLUDE, {e, f} )

      then the corresponding interface record on interface i is:

         ( m, INCLUDE, {a, b, c, d, e, f} )

   An implementation MUST NOT use an EXCLUDE interface record for a
   multicast address if all sockets for this multicast address are in
   INCLUDE state.  If system resource limits are reached when a per-
   interface state source list is calculated, an error MUST be returned
   to the application which requested the operation.

   The above rules for deriving the per-interface state are
   (re)evaluated whenever an IPv6MulticastListen invocation modifies the
   per-socket state by adding, deleting, or modifying a per-socket state
   record.  Note that a change of the per-socket state does not
   necessarily result in a change of the per-interface state.

5.  Message Formats

   MLDv2 is a sub-protocol of ICMPv6, that is, MLDv2 message types are a
   subset of ICMPv6 messages, and MLDv2 messages are identified in IPv6
   packets by a preceding Next Header value of 58.  All MLDv2 messages
   described in this document MUST be sent with a link-local IPv6 Source



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


   Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option
   [RFC2711] in a Hop-by-Hop Options header.  (The Router Alert option
   is necessary to cause routers to examine MLDv2 messages sent to IPv6
   multicast addresses in which the routers themselves have no
   interest.)  MLDv2 Reports can be sent with the source address set to
   the unspecified address [RFC3513], if a valid link-local IPv6 source
   address has not been acquired yet for the sending interface.  (See
   section 5.2.13. for details.)

   There are two MLD message types of concern to the MLDv2 protocol
   described in this document:

   o  Multicast Listener Query (Type = decimal 130)

   o  Version 2 Multicast Listener Report (Type = decimal 143).  See
      section 11 for IANA considerations.

   To assure the interoperability with nodes that implement MLDv1 (see
   section 8), an implementation of MLDv2 must also support the
   following two message types:

   o  Version 1 Multicast Listener Report (Type = decimal 131) [RFC2710]

   o  Version 1 Multicast Listener Done (Type = decimal 132) [RFC2710]

   Unrecognized message types MUST be silently ignored.  Other message
   types may be used by newer versions or extensions of MLD, by
   multicast routing protocols, or for other uses.

   In this document, unless otherwise qualified, the capitalized words
   "Query" and "Report" refer to MLD Multicast Listener Queries and MLD
   Version 2 Multicast Listener Reports, respectively.

5.1.  Multicast Listener Query Message

   Multicast Listener Queries are sent by multicast routers in Querier
   State to query the multicast listening state of neighboring
   interfaces.  Queries have the following format:













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


     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 = 130   |      Code     |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Maximum Response Code      |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    *                                                               *
    |                                                               |
    *                       Multicast Address                       *
    |                                                               |
    *                                                               *
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    *                                                               *
    |                                                               |
    *                       Source Address [1]                      *
    |                                                               |
    *                                                               *
    |                                                               |
    +-                                                             -+
    |                                                               |
    *                                                               *
    |                                                               |
    *                       Source Address [2]                      *
    |                                                               |
    *                                                               *
    |                                                               |
    +-                              .                              -+
    .                               .                               .
    .                               .                               .
    +-                                                             -+
    |                                                               |
    *                                                               *
    |                                                               |
    *                       Source Address [N]                      *
    |                                                               |
    *                                                               *
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







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


5.1.1.  Code

   Initialized to zero by the sender; ignored by receivers.

5.1.2.  Checksum

   The standard ICMPv6 checksum; it covers the entire MLDv2 message,
   plus a "pseudo-header" of IPv6 header fields [RFC2463].  For
   computing the checksum, the Checksum field is set to zero.  When a
   packet is received, the checksum MUST be verified before processing
   it.

5.1.3.  Maximum Response Code

   The Maximum Response Code field specifies the maximum time allowed
   before sending a responding Report.  The actual time allowed, called
   the Maximum Response Delay, is represented in units of milliseconds,
   and is derived from the Maximum Response Code as follows:

   If Maximum Response Code < 32768,
      Maximum Response Delay = Maximum Response Code

   If Maximum Response Code >=32768, Maximum Response Code represents a
   floating-point value as follows:

       0 1 2 3 4 5 6 7 8 9 A B C D E F
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1| exp |          mant         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Maximum Response Delay = (mant | 0x1000) << (exp+3)

   Small values of Maximum Response Delay allow MLDv2 routers to tune
   the "leave latency" (the time between the moment the last node on a
   link ceases to listen to a specific multicast address and the moment
   the routing protocol is notified that there are no more listeners for