Re: [v6ops] Interesting problems with using IPv6

Brian Haberman <brian@innovationslab.net> Tue, 09 September 2014 17:08 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95831A7009 for <v6ops@ietfa.amsl.com>; Tue, 9 Sep 2014 10:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuYauZ7FHcvv for <v6ops@ietfa.amsl.com>; Tue, 9 Sep 2014 10:08:55 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855341A802F for <v6ops@ietf.org>; Tue, 9 Sep 2014 10:08:55 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6ADDC880F6 for <v6ops@ietf.org>; Tue, 9 Sep 2014 10:08:55 -0700 (PDT)
Received: from 1025210049.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 31C3871B0001 for <v6ops@ietf.org>; Tue, 9 Sep 2014 10:08:55 -0700 (PDT)
Message-ID: <540F3432.5030702@innovationslab.net>
Date: Tue, 09 Sep 2014 13:09:06 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: v6ops@ietf.org
References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <540E7DC3.8060408@gont.com.ar> <540EAA55.7000207@gmail.com> <540F0BCF.1060905@gont.com.ar>
In-Reply-To: <540F0BCF.1060905@gont.com.ar>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="1Jpk1dQfOT6QJf5e9EAjLpejwCvDh14UU"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jRdLmkQKiPNeQRs9oSPq1Y1gqVI
Subject: Re: [v6ops] Interesting problems with using IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 17:08:58 -0000


On 9/9/14 10:16 AM, Fernando Gont wrote:
> On 09/09/2014 04:20 AM, Brian E Carpenter wrote:
>>>> OK, but I would also like to understand why we require
>>>> MLD messages for a Solicited-Node multicast address to
>>>> set Router Alert.
>>>
>>> Because in theory the multicast router needs to process the MLD message
>>> to build its forwarding table....
>>
>> Why, for the Solicited-Node group, which is only meaningful on the link
>> from which the MLD message arrives?
> 
> Then, let me change the question: Why do I need MLD for *this*?

The MLD specs say that an MLD Report is sent for every multicast group
joined except the All-Nodes multicast address.

The use of MLD Reports for essentially all multicast addresses was done
to facilitate this very type of snooping functionality.  The use of
Router Alerts in MLD messages is due to MLDv1 (and IGMPv2) using the
group address as the IP destination rather than the All-Routers
multicast address.

> 
> We probably use MLD because "If you use multicast, you use MLD". Truth
> is that, *unless your switch does MLD snooping* (and hence you *need*
> MLD, or else your packets will not flow around), you could completely
> kill MLD, and ND would still work just fine.

Sure, since NDP is link-local.  The drawback is what happens if your
network is using RFC 4541 snooping that relies on seeing those MLD
messages to build forwarding/filtering tables?

> 
> Not to mention that there are nodes that default t running MLDv2 *for
> this* (way overkill, IMO)
> 

Why is MLDv2 overkill?

Brian