Re: [v6ops] Interesting problems with using IPv6

Erik Nordmark <nordmark@acm.org> Mon, 15 September 2014 22:09 UTC

Return-Path: <nordmark@acm.org>
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 D5BC91A87F0 for <v6ops@ietfa.amsl.com>; Mon, 15 Sep 2014 15:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
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 Ia6HuFqHMw22 for <v6ops@ietfa.amsl.com>; Mon, 15 Sep 2014 15:08:59 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2153A1A87C4 for <v6ops@ietf.org>; Mon, 15 Sep 2014 15:08:59 -0700 (PDT)
Received: from [172.22.229.45] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8FM8sOC001507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2014 15:08:55 -0700
Message-ID: <54176375.3070003@acm.org>
Date: Mon, 15 Sep 2014 15:08:53 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Mikael Abrahamsson <swmike@swm.pp.se>
References: <1410082125488.85722@surrey.ac.uk> <540CB702.3000605@gmail.com> <20140908183339.GB98785@ricotta.doit.wisc.edu> <540E26D9.3070907@gmail.com> <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com> <540E6299.2050003@gmail.com> <1410743000.11973.YahooMailNeo@web162204.mail.bf1.yahoo.com> <54166EE5.9080007@gmail.com> <alpine.DEB.2.02.1409150702180.14735@uplift.swm.pp.se> <54174A26.1050206@gmail.com>
In-Reply-To: <54174A26.1050206@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVY3x7atgBirB3kAwa5Zf2HNAzJQ92EiSZ1u3w1rs50fiudkPd3TiEmsG5uCLLfYRbWpVpTeRnEXQHJILylCRzl4
X-Sonic-ID: C;Giep4SQ95BGJ4jZXoK8kYw== M;KB9r4iQ95BGJ4jZXoK8kYw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/u18eao6WhBCU5oOQGSrC2OIi1b0
Cc: IPv6 Operations <v6ops@ietf.org>
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: Mon, 15 Sep 2014 22:09:01 -0000

On 9/15/14, 1:20 PM, Brian E Carpenter wrote:
> On 15/09/2014 17:04, Mikael Abrahamsson wrote:
>> On Mon, 15 Sep 2014, Brian E Carpenter wrote:
>>
>>> was MLD snooping (i.e. a layer violation by L2 switches). Even so,
>> This is the first time I have seen anyone calling MLD/IGMP snooping a
>> "layer violation by L2 switches" (I'm interpreting this as you thinking
>> it's negative, do tell if this is not the case).
> Yes, layer violations have this nasty habit of coming back and
> biting you, and this is an example.

Brian,

I don't think we have sufficient data on the contributions of the 
different factors that resulted in triggering the implementation 
problems in this case.

The overloading of IGMP for to both feed L3 multicast routing 
information into routers and to feed L2 multicast information into IGMP 
snooping switches (which was faithfully carries forward into MLD) 
certainly is part of the picture. That results in the routers seeing MLD 
reports for link-local groups, which the routers do not care about.

But even if we had a non-overloaded approach (with L2 multicast 
membership being propagated by IEEE *Multiple Registration Protocol* 
(*MRP*) instead of IGMP/MLD snooping), the L2 switches would still be 
overloaded with so many temporary addresses and associated 
solicited-node multicast addresses.

Of course, I've never seen a host which implements MRP, but that is 
separate from the implied architectural question about which part of the 
blame should be placed on overloading (or layer violations if you prefer 
that term) in this case.

Regards,
    Erik

>
>> How else is L2 equipment going to make intelligent decisions about
>> multicast forwarding within an L2?
> They're not. That's why DEC Gigaswitches had ARP throttling, for example,
> to control broadcast storms. It's unavoidable if you build big L2
> networks. I learnt not to do that.
>
>      Brian
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>