Re: [v6ops] SLAAC security concerns

Vasilenko Eduard <> Wed, 05 August 2020 06:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FFBA3A133F; Tue, 4 Aug 2020 23:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xS0LCbKVXaaP; Tue, 4 Aug 2020 23:44:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EEAA3A117F; Tue, 4 Aug 2020 23:44:02 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 2DD581E68C84DD8E9ADE; Wed, 5 Aug 2020 07:44:00 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 5 Aug 2020 07:43:55 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 5 Aug 2020 09:43:54 +0300
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Wed, 5 Aug 2020 09:43:54 +0300
From: Vasilenko Eduard <>
To: "Pascal Thubert (pthubert)" <>, "Ted Lemon" <>
CC: Michael Richardson <>, v6ops list <>, 6man <>, Gert Doering <>
Thread-Topic: [v6ops] SLAAC security concerns
Thread-Index: AdZqh2IDVN0JAX5fTSutty/fgHiG3P//7l0AgAAIigCAAAdgAP//J7PQ
Date: Wed, 5 Aug 2020 06:43:54 +0000
Message-ID: <>
References: <> <20200804194448.GA2485@Space.Net>, <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_fa73c4e3aca6406995daa12ffa30e260huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [v6ops] SLAAC security concerns
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Aug 2020 06:44:05 -0000

Hi Pascal,
I was in business for long time. I am not much scared of bad vendor implementation of multicast or not implemented multicast at all.

Your concern that not every technology is good for multicast is right: WiFi (most popular type of connection our times) is not friendly to multicast whatever vendor would do about it.
Your point is very valid, but I do not want revolution in SLAAC. I want evolution – minimal number of changes to patch only biggest holes. Revolution would not be accepted by the market.
I agree that final picture is not ideal.

PS: If people would like revolution – you have the good proposal what to do. Let we see how much would be acceptance after additional 10 years.
From: ipv6 [] On Behalf Of Pascal Thubert (pthubert)
Sent: 4 августа 2020 г. 23:42
To: Ted Lemon <>
Cc: Michael Richardson <>ca>; v6ops list <>rg>; 6man <>rg>; Gert Doering <>
Subject: Re: [v6ops] SLAAC security concerns

Talking about multicast might be misleading. Has anyone deployed L2 multicast? IEEE people told me they designed one and that after some hiccups it was made to work but not much implemented and deployed.

Even then this is pushing the scalability problem one layer down not solving it, like almost as many groups as there are addresses so what’s the point?

Else for all I know we are mostly broadcasting any DAD and lookup over the whole L2, causing storms and wasting the wireless bandwidth. This is also a major pain point for the deployment of large multi site fabrics.
Disclaimer: I have not seen IGMP snooping successfully turned on for link scope multicast; unclear if and how that can help or if as hinted in this thread it should be turned off. I’d be interested in return from experience there :)

Keep safe,


Le 4 août 2020 à 22:17, Ted Lemon <<>> a écrit :
 On Aug 4, 2020, at 3:44 PM, Gert Doering <<>> wrote:
There is too many broken switch vendors out there that show again and
again that "implementing multicast is hard", breaking IPv6 ND in the

Why don’t you return that switch for a refund?

(I’ve never run into a switch that had trouble with IPv6 multicast, but admittedly I only have four different switches in my house, so that’s not a very big sample.)

v6ops mailing list<>