MLDv1/v2

This is a multipart message in MIME format.
--===============3261666164191432096==
Content-Type: multipart/alternative; boundary="=_alternative 007AF8BF8825787A_="

This is a multipart message in MIME format.
--=_alternative 007AF8BF8825787A_=
Content-Type: text/plain; charset="US-ASCII"

Hi All,

Had a question regarding the MLD router behavior when MLD is enabled on an 
interface with reference to 
Neighbor Discovery RFC 4861 attached below for reference:

******* RFC 4861 ************
7.2.1.  Interface Initialization

   When a multicast-capable interface becomes enabled, the node MUST
   join the all-nodes multicast address on that interface, as well as
   the solicited-node multicast address corresponding to each of the IP
   addresses assigned to the interface.

   The set of addresses assigned to an interface may change over time.
   New addresses might be added and old addresses might be removed
   [ADDRCONF].  In such cases the node MUST join and leave the
   solicited-node multicast address corresponding to the new and old
   addresses, respectively.  Joining the solicited-node multicast
   address is done using a Multicast Listener Discovery such as [MLD] or
   [MLDv2] protocols.  Note that multiple unicast addresses may map into
   the same solicited-node multicast address; a node MUST NOT leave the
   solicited-node multicast group until all assigned addresses
   corresponding to that multicast address have been removed.
***********
What are the MLD join packets that should be sent when the interface has 
version 
MLDv1 and when the version is MLDv2. Is there some IETF document 
that provides more details on this behavior. Have not found any clear 
description
in RFCs 3810 or 2710. 

regards,
-rekha



--=_alternative 007AF8BF8825787A_=
Content-Type: text/html; charset="US-ASCII"

<font size=2 face="sans-serif">Hi All,</font>
<br>
<br><font size=2 face="sans-serif">Had a question regarding the MLD router
behavior when MLD is enabled on an interface with reference to </font>
<br><font size=2 face="sans-serif">Neighbor Discovery RFC 4861 attached
below for reference:</font>
<br>
<br><font size=2 face="sans-serif">******* RFC 4861 ************</font>
<table width=100%>
<tr valign=top>
<td width=100%><tt><font size=2><i>7.2.1. &nbsp;Interface Initialization<br>
<br>
 &nbsp; When a multicast-capable interface becomes enabled, the node MUST<br>
 &nbsp; join the all-nodes multicast address on that interface, as well
as<br>
 &nbsp; the solicited-node multicast address corresponding to each of the
IP<br>
 &nbsp; addresses assigned to the interface.<br>
<br>
 &nbsp; The set of addresses assigned to an interface may change over time.<br>
 &nbsp; New addresses might be added and old addresses might be removed<br>
 &nbsp; [ADDRCONF]. &nbsp;In such cases the node MUST join and leave the<br>
 &nbsp; solicited-node multicast address corresponding to the new and old<br>
 &nbsp; addresses, respectively. &nbsp;Joining the solicited-node multicast<br>
 &nbsp; address is done using a Multicast Listener Discovery such as [MLD]
or<br>
 &nbsp; [MLDv2] protocols. &nbsp;Note that multiple unicast addresses may
map into<br>
 &nbsp; the same solicited-node multicast address; a node MUST NOT leave
the<br>
 &nbsp; solicited-node multicast group until all assigned addresses<br>
 &nbsp; corresponding to that multicast address have been removed.</i></font></tt>
<br><tt><font size=3>***********</font></tt>
<br><tt><font size=3>What are the MLD join packets that should be sent
when the interface has version </font></tt>
<br><tt><font size=3>MLDv1 and when the version is MLDv2. Is there some
IETF document &nbsp;</font></tt>
<br><tt><font size=3>that provides more details on this behavior. Have
not found any clear description</font></tt>
<br><tt><font size=3>in RFCs 3810 or 2710. </font></tt>
<br>
<br><tt><font size=3>regards,</font></tt>
<br><tt><font size=3>-rekha<br>
<br>
</font></tt></table>
<br>
--=_alternative 007AF8BF8825787A_=--

--===============3261666164191432096==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
magma mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/magma

--===============3261666164191432096==--