Re: [v6ops] Interesting problems with using IPv6

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 09 September 2014 02:14 UTC

Return-Path: <brian.e.carpenter@gmail.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 934D91A03B4 for <v6ops@ietfa.amsl.com>; Mon, 8 Sep 2014 19:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 14sIiuJLrtuB for <v6ops@ietfa.amsl.com>; Mon, 8 Sep 2014 19:14:49 -0700 (PDT)
Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985B61A03B1 for <v6ops@ietf.org>; Mon, 8 Sep 2014 19:14:49 -0700 (PDT)
Received: by mail-pd0-f174.google.com with SMTP id v10so7894654pde.5 for <v6ops@ietf.org>; Mon, 08 Sep 2014 19:14:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KHfBZbaammF6LU7YwaXvjkt5DL6EnbHyvqptgTk4I7M=; b=tET6P7U8vEagwVMoqI51yy4SPgQKV4p6F6XR8vSabjLlI7MxF1thoYVu+yApp0gKgZ i1fhX0Q0A3zEZ7Md/72SjDng82/QLvIY4dtYlwD13oroJowVp2Fsdo3dHGbmIl5fVJRS dzc9Tw1acEhi8ShEoWhwNTYVnqsavETjEFJxPtsGYQ+QH4NP4f2LjQaz0WoKRin4toxl rWxIvObQvgQsptHVcTcpSJWQus0j0lt+RI+//qt/MhROzk2m+i44Z333FuqQOGqS8dw7 y53fwsaPUFvVp42SisKzZGozA1RkaPZO+qAqEYS4/eJoqfzbyPHHbKrcqal3JlMeRcmb D+Vg==
X-Received: by 10.68.68.134 with SMTP id w6mr24055838pbt.110.1410228889143; Mon, 08 Sep 2014 19:14:49 -0700 (PDT)
Received: from [192.168.178.23] (21.196.69.111.dynamic.snap.net.nz. [111.69.196.21]) by mx.google.com with ESMTPSA id pg2sm9995719pbb.43.2014.09.08.19.14.45 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 19:14:48 -0700 (PDT)
Message-ID: <540E6299.2050003@gmail.com>
Date: Tue, 09 Sep 2014 14:14:49 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
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>
In-Reply-To: <1410227735.13436.YahooMailNeo@web162204.mail.bf1.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/a1FpP-bfq8dRaXoz2s5dTWF3df8
Cc: IPv6 Operations <v6ops@ietf.org>, "l.wood@surrey.ac.uk" <l.wood@surrey.ac.uk>
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 02:14:51 -0000

Mark,

My point is that it's worth *understanding* such problems and then
perhaps writing up operational or implementation recommendations.
Exactly what the v6ops charter says we should do, in fact.

"1. Solicit input from network operators and users to identify
operational issues with the IPv4/IPv6 Internet, and
determine solutions or workarounds to those issues. These issues
will be documented in Informational or BCP RFCs, or in
Internet-Drafts."

Or recommend protocol changes if they might help, which is why I
want to understand the value of Router Alert in MLD messages for
Solicited-Node multicast addresses. Or should we revive
draft-pashby-magma-simplify-mld-snooping-01?

    Brian


On 09/09/2014 13:55, Mark ZZZ Smith wrote:
> 
> 
> 
> ----- Original Message -----
>> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
>> To: Dale W. Carder <dwcarder@wisc.edu>
>> Cc: IPv6 Operations <v6ops@ietf.org>rg>; l.wood@surrey.ac.uk
>> Sent: Tuesday, 9 September 2014, 7:59
>> Subject: Re: [v6ops] Interesting problems with using IPv6
>>
>> I switched to the relevant list.
>>
>> On 09/09/2014 06:33, Dale W. Carder wrote:
>>>  Thus spake Brian E Carpenter (brian.e.carpenter@gmail.com) on Mon, Sep 08, 
>> 2014 at 07:50:26AM +1200:
>>>>  If they really are interesting problems, it might be more to the
>>>>  point to analyse them over on v6ops. Given the number of large
>>>>  IPv6 deployments that don't have such problems, it seems like
>>>>  this particular deployment hit an unfortunate combination of
>>>>  implementation issues.
> 
> 
> If this email is referring to this blog post:
> 
> http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/
> 
> 
> then I think this particular network was already on the verge of catastrophic failure, and some of IPv6's ND differences were just the trigger to push it over that threshold.
> 
> 
> According to the blog post, they might have:
> 
> - hardware errors
> - software errors
> - 'bridge loops' causing the control plane to overload
> 
> In some of these cases they've taken actions to try to resolve them, however the actions taken seem to be based on speculating what is happening rather than finding evidence to support the hypothesised cause before taking action.
> 
> For example, there isn't any evidence that they've actually determined that 'bridge loops' are occurring, found out what is causing them, and then taking measures to prevent them or at least reduce the chances of them occurring. If a 'bridge loop' can cause the control plane to overload, then adding anything to this network like IPv6 is likely to only make the problem worse.
> 
> I'd like to see them get to the bottom of and then fix these 'bridge loop' and other problems first before any value is placed on addressing their criticisms of IPv6. Other people have deployed IPv6 without these problems, so what is different between this network and everybody else's that doesn't have these sorts of problems?
> 
> 
> 
>  That is worth understanding (for example,
>>>>  how large is the layer 2 network that leads to the MLD listener
>>>>  report overload?).
>>>  Implementing MLD snooping for Solicited-Node multicast addresses 
>>>  is probably a bad idea.
>>>
> 
>>>  See: draft-pashby-magma-simplify-mld-snooping-01
>> OK, but I would also like to understand why we require
>> MLD messages for a Solicited-Node multicast address to
>> set Router Alert.
>>
>>     Brian
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>