Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Sun, 27 October 2019 13:42 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87718120128 for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 06:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=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 vxvM08G6k67A for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 06:42:05 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 B13C912006E for <v6ops@ietf.org>; Sun, 27 Oct 2019 06:42:04 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iOinq-0000J3C; Sun, 27 Oct 2019 14:41:54 +0100
Message-Id: <m1iOinq-0000J3C@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com> <e67f597d-93a7-3882-3a12-69519178893d@foobar.org>
In-reply-to: Your message of "Sun, 27 Oct 2019 12:33:53 +0000 ." <e67f597d-93a7-3882-3a12-69519178893d@foobar.org>
Date: Sun, 27 Oct 2019 14:41:54 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7pdHGw674pf1TL9N9n7RkkzbKxg>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 27 Oct 2019 13:42:07 -0000

> This isn't a criticism of what you're suggesting btw. It's an
> observation that the design philosophy behind SLAAC has intrinsic
> problems that cannot be resolved without dealing with state and
> state transfer, and that maybe we need to take a critical look at
> SLAAC and make potentially difficult decisions about whether or
> not it's fit for purpose for common deployment situations.

In this particular case (a CPE rebooting and getting a different prefix from
the ISP), SLAAC has for the most part what we need.

The little bit missing is that the CPE should write prefixes advertised using
SLAAC to persistent storage which allows the CPE to invalidate stale prefixes
after a reboot.

Note that we could change SLAAC to allow the lifetime of a prefix to be
set to zero, instead of having to wait for 2 hours. That might be an
improvement but requires careful analsysis.