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

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Tue, 29 October 2019 13:16 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 4D9D3120822 for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2019 06:16:00 -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 EG7QcAHnqA8I for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2019 06:15:58 -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 9016E120817 for <v6ops@ietf.org>; Tue, 29 Oct 2019 06:15:58 -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 m1iPRLi-0000EpC; Tue, 29 Oct 2019 14:15:50 +0100
Message-Id: <m1iPRLi-0000EpC@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> <m1iOk6q-0000IyC@stereo.hq.phicoh.net> <855496CB-BF7E-41E6-B273-41C4AA771E41@fugue.com> <m1iOokE-0000KvC@stereo.hq.phicoh.net> <670EDAE2-D472-45BB-9888-27D0D03BEEB9@delong.com>
In-reply-to: Your message of "Mon, 28 Oct 2019 19:58:26 -0700 ." <670EDAE2-D472-45BB-9888-27D0D03BEEB9@delong.com>
Date: Tue, 29 Oct 2019 14:15:40 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/SJENZ0ZK8fe_CZQQemkYpeMVFZU>
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: Tue, 29 Oct 2019 13:16:00 -0000

> > Today, you can deprecate a prefix by sending an RA with the preferred lifet
> ime
> > set to zero. That is enough to get IPv6 at the same level as IPv4.
> 
> No, this only deprecates it for new sessions. Existing sessions
> will still need to time out before they stop trying to use the old
> prefix. In an ideal world, a mechanism to signal the need to
> immediately error out such existing sessions is preferable.

For IPv4 + NAT, if you flash renumber the upstream address then existing
connections will be stuck.

I'm not aware of any IPv4 signalling that could even tell a host behind NAT
that the upstream address changed (with the exception of bringing the link
down).

Maybe you can be more specific why deprecating the old IPv6 prefix does not 
give the same effect as on IPv4 + NAT?

> Updating CPEs is generally a much more dependable and faster process
> than updating all hosts.

Updating CPEs should make general web browsing work after flash renumbering.
That should be enough for most users.