2009年9月27日

IP - MLD (in IPv6) Multicast Listener Discovery (Study Note)

MLD (in IPv6) Multicast Listener Discovery

1). MLD Overview:

§ IPv6 multicast does not use the IGMP but rather the Multicast Listener Discovery (MLD) protocol.

§ MLD is derived from Version 2 of IPv4 IGMPv2.

§ 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.

§ MLDv1 is similar to IGMPv2, and MLDv2 is similar to IGMPv3.

§ 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, this being similar to SSM.

§ Recall that SSM is a form of multicast where a receiver must specify both the network layer address of the source and the multicast destination address to receive the multicast datagrams of interest.

§ MLD is based on RFC 2710 Version 1 Multicast Listener Discovery (MLD) for IPv6, and RFC 3810, Multicast Listener

Discovery Version 2 (MLDv2) for IPv6.

§ MLD [RFC 2710, RFC 3550, RFC 3810] specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (i.e., nodes wishing to receive multicast packets) on its directly attached links and to discover which multicast addresses are of interest to those neighboring nodes.

§ MLD enables IPv6 routers to discover the presence of multicast listeners. This information is then provided to the multicast routing protocol being used by the router 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, the “multicast router part” and the “multicast address listener part”, including responding to its own messages.

§ If a router has more than one interface to the same link, it needs to perform the router part of the MLD over only one of those interfaces.

§ Listeners, on the contrary, must perform the listener part of MLD on all interfaces from which an application or upper layer protocol has requested reception of multicast packets.

§ 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.

2). MLD Message Overview:

§ MLD is a subprotocol of ICMPv6, namely, MLD message types are a subset of the set of ICMPv6 messages

§ One important difference is that MLD uses ICMPv6 message types (IP 58) rather than IGMP message types (IP 2).

§ MLD messages are identified in IPv6 packets by a preceding next header value of 58. All MLD messages are sent with a link-local IPv6 source address, an IPv6 hop limit of 1, and an IPv6 Router Alert option in a Hop-by-Hop Options header.

3). There are three types of MLDv1 messages:

1. Multicast Listener Query (type decimal 130), also known as “Query” (or Join)

§ There are two subtypes of Multicast Listener Query messages (differentiated by the contents of the Multicast Address field):

§ 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.

2. Multicast Listener Report (type decimal 131), also known as “Report”

3. Multicast Listener Done (type decimal 132), also known as “Done” (or Leave)

4). MLDv1 Message Format:

http://docs.google.com/View?id=ddh56dhg_221hp74wwgg

§ The Code field is initialized to zero by the sender; ignored by receivers.

§ The Checksum field is the standard ICMPv6 checksum, covering the entire MLD message plus a “pseudoheader” of IPv6 header fields.

§ 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.

§ The Reserved field is initialized to zero by the sender; ignored by receivers.

§ 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 multicastaddress-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.

§ 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 theMLDmessage.

5). IGMP Message Type:

http://docs.google.com/View?id=ddh56dhg_223fkq32xxx

6). MLDv2 Message Overview:

§ There are three types of MLDv2 query messages: general queries, multicast address specific queries, and multicast address- and

source-specific queries.

§ 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 of all MLDv2 routers on the link listen to. On the contrary, if the listening state of a node changes, the node immediately reports these changes through a State Change Report message.

§ Source filtering is based on RFC 4604. The term “Source Filtering GMP (SFGMP)” is used to refer jointly to the IGMPv3 and MLDv2 group management protocols.

7). Multicast Address Record Types

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

§ Current State Record

  • IS_IN ( x ) =1 - Type MODE_IS_INCLUDE, source addresses x
  • IS_EX ( x ) =2 - Type MODE_IS_EXCLUDE, source addresses x

§ Filter Mode Change Record

  • TO_IN ( x ) =3 - Type CHANGE_TO_INCLUDE_MODE, source addresses x
  • TO_EX ( x ) =4 - Type CHANGE_TO_EXCLUDE_MODE, source addresses

§ Source List Change Record

  • ALLOW ( x ) =5 - Type ALLOW_NEW_SOURCES, source addresses x
  • BLOCK ( x ) =6 - Type BLOCK_OLD_SOURCES, source addresses x

8). MLDv2 Message Type:

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

§ Version 2 Multicast Listener Query (Type = decimal 130)

§ Version 2 Multicast Listener Report (Type = decimal 143).

§ To assure the interoperability with nodes that implement MLDv1, an implementation of MLDv2 must also support the following two message types:

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

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

9). MLDv2 Message Format:

Version 2 Multicast Listener Query

http://docs.google.com/View?id=ddh56dhg_225c6v5w6dw

Version 2 Multicast Listener Report

http://docs.google.com/View?id=ddh56dhg_227ftpm48c6


沒有留言:

張貼留言