Re: [v6ops] Flash renumbering

Jan Zorz - Go6 <jan@go6.si> Wed, 16 September 2020 22:44 UTC

Return-Path: <jan@go6.si>
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 4B26A3A12B3; Wed, 16 Sep 2020 15:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, 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=go6.si
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 roi2giPmaiyB; Wed, 16 Sep 2020 15:44:47 -0700 (PDT)
Received: from mx.go6lab.si (mx.go6lab.si [IPv6:2001:67c:27e4::23]) (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 DEC473A12B1; Wed, 16 Sep 2020 15:44:44 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 5215E623C8; Thu, 17 Sep 2020 00:44:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id gqGnlkYMmYKT; Thu, 17 Sep 2020 00:44:40 +0200 (CEST)
Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id 50ED4623C6; Thu, 17 Sep 2020 00:44:40 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 mx.go6lab.si 50ED4623C6
Received: from haktar.local (unknown [212.30.70.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "jan@go6.si", Issuer "Actalis Client Authentication CA G2" (verified OK)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 255E0200BE; Thu, 17 Sep 2020 00:44:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1600296280; bh=nOEzPHnB/gl/FChuDTRDSdscvZCyGDnTGcYJYZDMipI=; h=To:References:From:Subject:Date:In-Reply-To:From; b=X0DDyJnj4cjOoSNHIN8JShH2PyOssDafZ4dZ4W0vTFH7z7PNJXKBfsjueyXFlTvx2 69Amsb6nyCnOyte7GRvIPTz87QLAjSUyLW04F1crIrHQbMSylbt45u+cSIFh0r8A/w W1dGbNMERnnKWRD/dUCAXJ2Bvoyv2ws0lggaSldk=
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>, "6man@ietf.org" <6man@ietf.org>, IPv6 Operations <v6ops@ietf.org>
References: <8f964b8650cd4b619ff47aed5b07bc67@huawei.com>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <7ef6cbcc-164f-383c-658b-b3c0df859535@go6.si>
Date: Thu, 17 Sep 2020 00:44:39 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:81.0) Gecko/20100101 Thunderbird/81.0
MIME-Version: 1.0
In-Reply-To: <8f964b8650cd4b619ff47aed5b07bc67@huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/so3gQ798lWlzhUlv-j8OhfqXHtc>
Subject: Re: [v6ops] Flash renumbering
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: Wed, 16 Sep 2020 22:44:49 -0000

On 15/09/2020 22:29, Vasilenko Eduard wrote:
> Hi all,
> I did think on the problem today and come to the conclusion that the 
> problem has very small corner case. We could say that it does not exist. 
> It definitely does not need urgent solution.

This problem is so real in deployments where operators decided to go 
with non-persistent IPv6 prefix delegations that we documented it in 
RIPE-690 where we suggest to deploy prefix delegations as 
persistent/static as possible so networks/hosts behind CPEs don't suffer 
from this issue.

My personal preference strongly lies towards static/persistent IPv6 
prefixes, but that doesn't mean we should not make SLAAC at least more 
robust to more accurately and timely follow the topology changes (one of 
them being PD change).

Cheers, Jan Zorz