[magma] MLDv1/v2

Rekha Mundhra <rmundhra@us.ibm.com> Fri, 22 April 2011 22:23 UTC

Return-Path: <rmundhra@us.ibm.com>
X-Original-To: magma@ietfc.amsl.com
Delivered-To: magma@ietfc.amsl.com
Received: from localhost (localhost []) by ietfc.amsl.com (Postfix) with ESMTP id C0932E0780 for <magma@ietfc.amsl.com>; Fri, 22 Apr 2011 15:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.217
X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfc.amsl.com []) (amavisd-new, port 10024) with ESMTP id ekuzLTseYIsW for <magma@ietfc.amsl.com>; Fri, 22 Apr 2011 15:23:16 -0700 (PDT)
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com []) by ietfc.amsl.com (Postfix) with ESMTP id ED994E0685 for <magma@ietf.org>; Fri, 22 Apr 2011 15:23:15 -0700 (PDT)
Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com []) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3MMC4a4021287 for <magma@ietf.org>; Fri, 22 Apr 2011 16:12:04 -0600
Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com []) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3MMN9rW105706 for <magma@ietf.org>; Fri, 22 Apr 2011 16:23:09 -0600
Received: from d03av06.boulder.ibm.com (loopback []) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3MMMRFV008011 for <magma@ietf.org>; Fri, 22 Apr 2011 16:22:27 -0600
Received: from d03nm691.boulder.ibm.com (d03nm691.boulder.ibm.com []) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3MMMRHX008008 for <magma@ietf.org>; Fri, 22 Apr 2011 16:22:27 -0600
To: magma@ietf.org
MIME-Version: 1.0
X-KeepSent: C8B47CFC:037720AE-8725787A:00771F3F; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: <OFC8B47CFC.037720AE-ON8725787A.00771F3F-8825787A.007AF8BF@us.ibm.com>
From: Rekha Mundhra <rmundhra@us.ibm.com>
Date: Fri, 22 Apr 2011 15:23:10 -0700
X-MIMETrack: Serialize by Router on D03NM691/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 04/22/2011 16:23:08, Serialize complete at 04/22/2011 16:23:08
Content-Type: multipart/alternative; boundary="=_alternative 007AF8BF8825787A_="
Subject: [magma] MLDv1/v2
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/magma>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 22:23:16 -0000

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 
MLDv1 and when the version is MLDv2. Is there some IETF document 
that provides more details on this behavior. Have not found any clear 
in RFCs 3810 or 2710.