Re: [v6ops] SLAAC security concerns

True, there are pros and cons and engineering trade offs as usual. That’s why we are here.

It doesn’t mean that this particular benefit is the most important consideration in all situations. The distributed approach has large consequences in usage of broadcast, security (DOS. SAVI, hijacking) and reactivity (Lookup reactive to outstanding packets) that make it unsuitable in many modern forms of l2 networks.

 In fact DHCP in the IPv4 world has survived quite successfully through the years without being the major pain point that broadcast storms have been.

The state in a centralized ND database can be synchronized. It’s not that hard. Routing protocols do that all the time. In fact a route type 2 in eVPN is exactly that.

Bottom line is that there may be a very large number of small deployments such as home where stateless ND and the associated multicast are quite fine. But there is  also a growing number of larger networks (enterprise, Conference wireless, distributed  Fabrics. cloud) where it’s completely Ill-suited.

So yes, we need an ND solution that uses only unicast, has inherent SAVI and ownership control, scales to large numbers of devices and is not an easy target for remote DoS.

Keep safe,

Pascal

Le 5 août 2020 à 01:34, Mark Smith <markzzzsmith@gmail.com> a écrit :

On Wed, 5 Aug 2020, 05:44 Gert Doering, <gert@space.net<mailto:gert@space.net>> 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
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops