Re: [v6ops] Interesting problems with using IPv6

Philip Homburg <pch-v6ops-3@u-1.phicoh.com> Tue, 09 September 2014 09:27 UTC

Return-Path: <pch-bBB316E3E@u-1.phicoh.com>
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 D69FA1A86E0 for <v6ops@ietfa.amsl.com>; Tue, 9 Sep 2014 02:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2] 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 adaKl8mOolFA for <v6ops@ietfa.amsl.com>; Tue, 9 Sep 2014 02:27:49 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id A17B11A89A8 for <v6ops@ietf.org>; Tue, 9 Sep 2014 02:27:47 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XRHiD-0000COC; Tue, 9 Sep 2014 11:27:45 +0200
Message-Id: <m1XRHiD-0000COC@stereo.hq.phicoh.net>
To: IPv6 Operations <v6ops@ietf.org>
From: Philip Homburg <pch-v6ops-3@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.com
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>
In-reply-to: Your message of "Tue, 09 Sep 2014 19:20:53 +1200 ." <540EAA55.7000207@gmail.com>
Date: Tue, 09 Sep 2014 11:27:44 +0200
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1cXddYPn614CugwA_6hQ6jgbIu8
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 09:27:51 -0000

In your letter dated Tue, 09 Sep 2014 19:20:53 +1200 you wrote:
>In its role as a node on the same link, participating in ND on that
>link, yes. In its role as a forwarding device, surely it should ignore
>traffic to the Solicited-Node address? So Router Alert is not
>needed. Or am I missing something?

Something else is weird as well. MLD-snooping involves a trade-off. The benefits of
MLD-snooping are reduced multicast traffic. The costs are the extra hardware needed
to do the filtering and increased complexity.

In most networks, increased complexity causes headaches and downtime, so the savings
better be significant.

Though ND is quite chatty, even in big networks it is not going to overload a
100 Mbit/s ethernet link or a host that is less than a decade old and not
significantly under powered.

One type of link that is certainly not going to be affected is backbone links between
switches.

So where does MLD-snooping make sense? On links from a switch to either a rather
slow network technology, like 2.4 GHz wifi, or particularly low-end devices, like
small ARM boards.

So the weird thing in the story is that core switches get overloaded processing MLD
even though they can just as well just forward multicast over a spanning tree.

Somehow the network architecture at CSAIL ended up with central processing of MLD and
a centralized TCAM for filtering instead of just filtering at the edges where it
makes sense.