rfc3810.txt

xorp源码hg

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


5.2.1.  Reserved

   The Reserved fields are set to zero on transmission, and ignored on
   reception.

5.2.2.  Checksum

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

5.2.3.  Nr of Mcast Address Records (M)

   The Nr of Mcast Address Records (M) field specifies how many
   Multicast Address Records are present in this Report.

5.2.4.  Multicast Address Record

   Each Multicast Address Record is a block of fields that contain
   information on the sender listening to a single multicast address on
   the interface from which the Report is sent.

5.2.5.  Record Type

   It specifies the type of the Multicast Address Record.  See section
   5.2.12 for a detailed description of the different possible Record
   Types.

5.2.6.  Aux Data Len

   The Aux Data Len field contains the length of the Auxiliary Data
   Field in this Multicast Address Record, in units of 32-bit words.  It
   may contain zero, to indicate the absence of any auxiliary data.

5.2.7.  Number of Sources (N)

   The Number of Sources (N) field specifies how many source addresses
   are present in this Multicast Address Record.

5.2.8.  Multicast Address

   The Multicast Address field contains the multicast address to which
   this Multicast Address Record pertains.






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


5.2.9.  Source Address [i]

   The Source Address [i] fields are a vector of n unicast addresses,
   where n is the value in this record's Number of Sources (N) field.

5.2.10.  Auxiliary Data

   The Auxiliary Data field, if present, contains additional information
   that pertain to this Multicast Address Record.  The protocol
   specified in this document, MLDv2, does not define any auxiliary
   data.  Therefore, implementations of MLDv2 MUST NOT include any
   auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any
   transmitted Multicast Address Record, and MUST ignore any such data
   present in any received Multicast Address Record.  The semantics and
   the internal encoding of the Auxiliary Data field are to be defined
   by any future version or extension of MLD that uses this field.

5.2.11.  Additional Data

   If the Payload Length field in the IPv6 header of a received Report
   indicates that there are additional octets of data present, beyond
   the last Multicast Address Record, MLDv2 implementations MUST include
   those octets in the computation to verify the received MLD Checksum,
   but MUST otherwise ignore those additional octets.  When sending a
   Report, an MLDv2 implementation MUST NOT include additional octets
   beyond the last Multicast Address Record.

5.2.12.  Multicast Address Record Types

   There are a number of different types of Multicast Address Records
   that may be included in a Report message:

   o  A "Current State Record" is sent by a node in response to a Query
      received on an interface.  It reports the current listening state
      of that interface, with respect to a single multicast address.
      The Record Type of a Current State Record may be one of the
      following two values:

      Value  Name and Meaning
      -----  ----------------
        1    MODE_IS_INCLUDE - indicates that the interface has a filter
             mode of INCLUDE for the specified multicast address.  The
             Source Address [i] fields in this Multicast Address Record
             contain the interface's source list for the specified
             multicast address.  A MODE_IS_INCLUDE Record is never sent
             with an empty source list.





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


        2    MODE_IS_EXCLUDE - indicates that the interface has a filter
             mode of EXCLUDE for the specified multicast address.  The
             Source Address [i] fields in this Multicast Address Record
             contain the interface's source list for the specified
             multicast address, if it is non-empty.

   o  A "Filter Mode Change Record" is sent by a node whenever a local
      invocation of IPv6MulticastListen causes a change of the filter
      mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to
      INCLUDE) of the interface-level state entry for a particular
      multicast address, whether the source list changes at the same
      time or not.  The Record is included in a Report sent from the
      interface on which the change occurred.  The Record Type of a
      Filter Mode Change Record may be one of the following two values:

      3    CHANGE_TO_INCLUDE_MODE - indicates that the interface has
           changed to INCLUDE filter mode for the specified multicast
           address.  The Source Address [i] fields in this Multicast
           Address Record contain the interface's new source list for
           the specified multicast address, if it is non-empty.

      4    CHANGE_TO_EXCLUDE_MODE - indicates that the interface has
           changed to EXCLUDE filter mode for the specified multicast
           address.  The Source Address [i] fields in this Multicast
           Address Record contain the interface's new source list for
           the specified multicast address, if it is non-empty.

   o  A "Source List Change Record" is sent by a node whenever a local
      invocation of IPv6MulticastListen causes a change of source list
      that is *not* coincident with a change of filter mode, of the
      interface-level state entry for a particular multicast address.
      The Record is included in a Report sent from the interface on
      which the change occurred.  The Record Type of a Source List
      Change Record may be one of the following two values:

      5    ALLOW_NEW_SOURCES - indicates that the Source Address [i]
           fields in this Multicast Address Record contain a list of
           the additional sources that the node wishes to listen to,
           for packets sent to the specified multicast address.  If
           the change was to an INCLUDE source list, these are the
           addresses that were added to the list; if the change was to
           an EXCLUDE source list, these are the addresses that were
           deleted from the list.

      6    BLOCK_OLD_SOURCES - indicates that the Source Address [i]
           fields in this Multicast Address Record contain a list of
           the sources that the node no longer wishes to listen to,
           for packets sent to the specified multicast address.  If the



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


           change was to an INCLUDE source list, these are the
           addresses that were deleted from the list; if the change
           was to an EXCLUDE source list, these are the addresses that
           were added to the list.

   If a change of source list results in both allowing new sources and
   blocking old sources, then two Multicast Address Records are sent for
   the same multicast address, one of type ALLOW_NEW_SOURCES and one of
   type BLOCK_OLD_SOURCES.

   We use the term "State Change Record" to refer to either a Filter
   Mode Change Record or a Source List Change Record.

   Multicast Address Records with an unrecognized Record Type value MUST
   be silently ignored, with the rest of the report being processed.

   In the rest of this document, we use the following notation to
   describe the contents of a Multicast Address Record that pertains to
   a particular multicast address:

      IS_IN ( x )  -  Type MODE_IS_INCLUDE, source addresses x
      IS_EX ( x )  -  Type MODE_IS_EXCLUDE, source addresses x
      TO_IN ( x )  -  Type CHANGE_TO_INCLUDE_MODE, source addresses x
      TO_EX ( x )  -  Type CHANGE_TO_EXCLUDE_MODE, source addresses x
      ALLOW ( x )  -  Type ALLOW_NEW_SOURCES, source addresses x
      BLOCK ( x )  -  Type BLOCK_OLD_SOURCES, source addresses x

      where x is either:

   o  a capital letter (e.g., "A") to represent the set of source
      addresses,

      or

   o  a set expression (e.g., "A+B"), where "A+B" means the union of
      sets A and B,  "A*B" means the intersection of sets A and B, and
      "A-B" means the removal of all elements of set B from set A.

5.2.13.  Source Addresses for Reports

   An MLDv2 Report MUST be sent with a valid IPv6 link-local source
   address, or the unspecified address (::), if the sending interface
   has not acquired a valid link-local address yet.  Sending reports
   with the unspecified address is allowed to support the use of IP
   multicast in the Neighbor Discovery Protocol [RFC2461].  For
   stateless autoconfiguration, as defined in [RFC2462], a node is
   required to join several IPv6 multicast groups, in order to perform
   Duplicate Address Detection (DAD).  Prior to DAD, the only address



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


   the reporting node has for the sending interface is a tentative one,
   which cannot be used for communication.  Thus, the unspecified
   address must be used.

   On the other hand, routers MUST silently discard a message that is
   not sent with a valid link-local address, without taking any action
   on the contents of the packet.  Thus, a Report is discarded if the
   router cannot identify the source address of the packet as belonging
   to a link connected to the interface on which the packet was
   received.  A Report sent with the unspecified address is also
   discarded by the router.  This enhances security, as unidentified
   reporting nodes cannot influence the state of the MLDv2 router(s).
   Nevertheless, the reporting node has modified its listening state for
   multicast addresses that are contained in the Multicast Address
   Records of the Report message.  From now on, it will treat packets
   sent to those multicast addresses according to this new listening
   state.  Once a valid link-local address is available, a node SHOULD
   generate new MLDv2 Report messages for all multicast addresses joined
   on the interface.

5.2.14.  Destination Addresses for Reports

   Version 2 Multicast Listener Reports are sent with an IP destination
   address of FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast
   routers listen (see section 11 for IANA considerations related to
   this special destination address).  A node that operates in version 1
   compatibility mode (see details in section 8) sends version 1 Reports
   to the multicast address specified in the Multicast Address field of
   the Report.  In addition, a node MUST accept and process any version
   1 Report whose IP Destination Address field contains *any* of the
   IPv6 addresses (unicast or multicast) assigned to the interface on
   which the Report arrives.  This might be useful, e.g., for debugging
   purposes.

5.2.15.  Multicast Listener Report Size

   If the set of Multicast Address Records required in a Report does not
   fit within the size limit of a single Report message (as determined
   by the MTU of the link on which it will be sent), the Multicast
   Address Records are sent in as many Report messages as needed to
   report the entire set.










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


   If a single Multicast Address Record contains so many source
   addresses that it does not fit within the size limit of a single
   Report message, then:

   o  if its Type is not IS_EX or TO_EX, it is split into multiple
      Multicast Address Records; each such record contains a different
      subset of the source addresses, and is sent in