Re: [v6ops] Implementation Status of PREF64

Philip Homburg <pch-v6ops-10@u-1.phicoh.com> Tue, 28 September 2021 19:36 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 E77EE3A0D3E for <v6ops@ietfa.amsl.com>; Tue, 28 Sep 2021 12:36:35 -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 ADcvttaZOeJv for <v6ops@ietfa.amsl.com>; Tue, 28 Sep 2021 12:36:33 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:981:201c:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD533A0D3B for <v6ops@ietf.org>; Tue, 28 Sep 2021 12:36:30 -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-CHACHA20-POLY1305) (Smail #158) id m1mVItl-0000GuC; Tue, 28 Sep 2021 21:36:17 +0200
Message-Id: <m1mVItl-0000GuC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-10@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <CAN-Dau2in52xSUkqKEXu=2AAiR4O_jLhna7hY-hshYDORfGtcQ@mail.gmail.com> <CAMGpriWFp4JPtqDK5tEj1RkS-SzEfvscfUUnxgK+o6qP2pusRA@mail.gmail.com> <6E95834D-12B3-447B-8326-8EDE9DC6FFB1@delong.com> <CAO42Z2zA-4cK489nxKsWUN8vvU0eAiz-jS0e-_eWPg+OmP8wLw@mail.gmail.com> <DDA36020-90CC-471B-83AD-3D98950F1164@delong.com> <CAO42Z2wdoSdJDOB2Zo0=ZK0ecOARRsdg2nbHZGSDOhryPbLfDw@mail.gmail.com> <F2BD0A42-E9AD-45DD-999A-638E73BE1177@delong.com> <CAKD1Yr2K3Gd3JD=NJFOoH6GYgs-8ACxRQB9-sKJ7cbF4_hxsow@mail.gmail.com> <0B533C71-5DB0-410D-A5A3-7E8FD559F214@delong.com> <CAKD1Yr3NoYfNT7+OVJoCCdgdif6AHHw29tNCPttS=-NuRZKv3w@mail.gmail.com> <5FAD5290-3616-4194-B783-D473DB38A89A@delong.com> <m1mVGC6-0000HSC@stereo.hq.phicoh.net> <D6620D7C-8FE8-4294-8014-AB18A230C9C7@delong.com>
In-reply-to: Your message of "Tue, 28 Sep 2021 11:21:53 -0700 ." <D6620D7C-8FE8-4294-8014-AB18A230C9C7@delong.com>
Date: Tue, 28 Sep 2021 21:36:16 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Yxd54sY4WURHTsqJg0UzumCOY1M>
Subject: Re: [v6ops] Implementation Status of PREF64
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, 28 Sep 2021 19:36:36 -0000

> With SLAAC, you can begin advertising an additional prefix right
> now.
> 
> You cant get rid of the old one so fast, you have to wait for the
> timers to expire.

Indeed I was sloppy. In addition to adding a prefix right now, you can 
also deprecate the old prefix without waiting for timers to expire.

The net effect is that new flows use the new prefix right away, but the old
prefix can be used for 2 hours longer. So timers are limited to 2 hours.

If I remember correctly, there was a draft in 6man that tried to change that
for dealing with flash renumbering. But other parts of the draft got too
complex and the draft seems to have stalled.

> Yes, but actually, this is more effective, also as the DHCP
> reconfigure will also be able to deprecate the previous address
> immediately if needed.

True. Though I don't want to bet on every IoT device implementing reconfigure.

In any case, for a very large part of internet traffic it is important that
new flows use the new address. Many applications agressively kill flows that
don't seem to make progress so there no real need to wait for the old
addresses to disappear.