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

Owen DeLong <owen@delong.com> Tue, 29 October 2019 17:20 UTC

Return-Path: <owen@delong.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 13771120AAE for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2019 10:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com
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 3X2ShQVRA4e0 for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2019 10:20:31 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D74B120AAD for <v6ops@ietf.org>; Tue, 29 Oct 2019 10:20:30 -0700 (PDT)
Received: from [199.187.216.130] ([199.187.216.130]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x9THKQPA015312 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Oct 2019 10:20:29 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x9THKQPA015312
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572369629; bh=tJxaMQAz63ayNM6eyG9nYSR+6gLYdB2k2LWrSK9GQHE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=W90ZPtYGEqAoqhq32ude4qxlba5lHMtWXTj2ZuN8+LwbKFt7qEEvdLCCKKBV0ESko C/bKEI0lJWthjCYdbf0g+RATWuu2JpQX5ts4IIWk3v4N9G9q65C594QEdnmXc72g4x 7GRr/HAtuhz2VhHhyS76yeTl5VYYUdT5Ie/XT94s=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <m1iPRLi-0000EpC@stereo.hq.phicoh.net>
Date: Tue, 29 Oct 2019 10:20:26 -0700
Cc: v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CB498DEF-FCEA-4A6E-B795-3731AB1F9987@delong.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> <m1iPRLi-0000EpC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Tue, 29 Oct 2019 10:20:29 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/yzNT_HIsmChyD9IIX9LsFSHbDeA>
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 17:20:33 -0000


> On Oct 29, 2019, at 6:15 AM, Philip Homburg <pch-v6ops-9@u-1.phicoh.com> wrote:
> 
>>> 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.

Not exactly… They do fairly quickly get sent TCP RSTs in most cases.

> 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).

Bringing the link down quickly and resetting the session allows for the connection
to be re-established and continue in most cases. OTOH, leaving the connection
hung until it times out at the application or host TCP stack level creates huge
delays in service restoration.

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

Because the IPv4 host fairly quickly receives an RST packet when the outbound
packet hits a non-existent state table entry or a state table entry marked as dead.

OTOH, the IPv6 host doesn’t (currently) get any signaling from the local router
indicating that anything is amiss. It continues to treat the prefix as valid for existing
flows (and depending on the level of deprecation, i.e. whether or not a preferred
lifetime 0 was received) perhaps for new flows as well.

>> 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.


Unless the CPE knows to send out an RA with a preferred lifetime of 0 for the now
deprecated prefix, then you are mistaken in the actual systemic behavior.

Owen