Re: [v6ops] SLAAC security concerns

Mark Smith <> Tue, 04 August 2020 23:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71DBD3A11E0; Tue, 4 Aug 2020 16:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XYtPVydYVO-c; Tue, 4 Aug 2020 16:33:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 486E23A11DA; Tue, 4 Aug 2020 16:33:08 -0700 (PDT)
Received: by with SMTP id z18so11460216otk.6; Tue, 04 Aug 2020 16:33:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4F1vdwkP3WRvWd/EbEsBNSUgvafronNA4XkPsS+dXRg=; b=oAvYRD941ttFuA/ABnIdlAPgHBCcV409sYDOBSyZpqDxfrtkDYoRAi8FhGXR+qSFWW iBMy9mj59TQ1aK5tq2BNXgFWpvYJ+EJW2fiPOe0LtCLmr86eov25h8B8raLwAEqjguZt sEkbRdq94D0p5dmmALnbiVmnVgPiYdn6mlT4z8A3yxShluJMlHLsWhFD1Uun6X1Bn0OB rbbZzYb4CgQEoHBnd8fI4bESYERMrlszx78OtEO4eJYKKKdk4yfxEG/bkQVgOlqwMSR+ iYFNxmjQrkSMOYxn16tLls5rdFIovzJCXXsnKiumFkRXbkvWvNuF6s5eTQgSofpuqkUd raog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4F1vdwkP3WRvWd/EbEsBNSUgvafronNA4XkPsS+dXRg=; b=tuW/xpV9OPEYrgJzw93e78ruc9Nc1aVkkG5BKmjWvpKwCCrxXbwD+xk11R46c4s6R6 IrVmUuDaSA6GP2Kmi9AoHtIhh4LkxPWTPL0RZQSCe15wkv6ZI05DA1nKkLRd07fc3j+z tyd7E0tb/4JeC+HOr+puqgx9DnkOyEkhRy6VaKXK2CoYiBibismsFiggjVUgciT4X/F9 HYRmbhKu+jsMnAYGxT98b8XloN1forpXC/zGfCbJWWZbuquVyJWyufNU0FVNYFntxuL6 yhD/GUTcHSrV7Jdxrn+gSOndBDIhsEcyE8Ehv13T/Eojymu4WspCK9TsaVQ2B6QxRL56 RTig==
X-Gm-Message-State: AOAM531ABIMPC/WEq8KKTE2YMy1XlevgVuq9oL4oBk4wVE0OAshf+r3g bIBlvZwSTj+cwQnuuc89xTmFrFZarT3nDmP+52M=
X-Google-Smtp-Source: ABdhPJxV+mtc2RrcqaXpJS4QegdtFKhuYeZgYks6IWcjk/t3wisCTm2wyAgViwQTxA9KUWh3cvJwoDehb/gixq6yBos=
X-Received: by 2002:a9d:38f:: with SMTP id f15mr459018otf.74.1596583987620; Tue, 04 Aug 2020 16:33:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <20200804194448.GA2485@Space.Net>
In-Reply-To: <20200804194448.GA2485@Space.Net>
From: Mark Smith <>
Date: Wed, 5 Aug 2020 09:32:56 +1000
Message-ID: <>
To: Gert Doering <>
Cc: Vasilenko Eduard <>, Michael Richardson <>, 6man <>, v6ops list <>
Content-Type: multipart/alternative; boundary="0000000000006fb1c205ac15ad80"
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: Tue, 04 Aug 2020 23:33:09 -0000

On Wed, 5 Aug 2020, 05:44 Gert Doering, <> wrote:

> Hi,
> On Tue, Aug 04, 2020 at 06:00:39PM +0000, Vasilenko Eduard wrote:
> > I believe that Multicast is so basic function of SLAAC that it does not
> make sense to delete it.
> Have I heard "delete multicast" here?
> Yes, please!
> There is too many broken switch vendors out there that show again and
> again that "implementing multicast is hard", breaking IPv6 ND in the
> process.
> The motivation for going to multicast "back in the dark ages" might have
> been honorable, but in today's networks, it just adds needless
> complications.

Multicast also shifts and distributes state away from a central device.

A central device is a much bigger consequence point of failure, and is a
harder thing to make redundant due to having to invent a state
synchronisation and load selection or distribution method mechanism between
a primary and one or more backup nodes.

Nodes maintaining their own state is simpler and means that when a node
fails, the loss of state due to the failure only impacts the failed node.

A specific design for redundant DHCPv6 has to exist. Redundancy in SLAAC
came inherently in its design because a node failure only impacts that node.

> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279