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

Ole Troan <otroan@employees.org> Fri, 25 October 2019 17:40 UTC

Return-Path: <otroan@employees.org>
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 0C51C120132 for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 10:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 iHNl94ONsEvD for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 10:40:51 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC19120088 for <v6ops@ietf.org>; Fri, 25 Oct 2019 10:40:51 -0700 (PDT)
Received: from [IPv6:2a01:79c:cebd:47d8:9c52:20df:ffc:2b15] (unknown [IPv6:2a01:79c:cebd:47d8:9c52:20df:ffc:2b15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id D1B364E11A42; Fri, 25 Oct 2019 17:40:49 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Date: Fri, 25 Oct 2019 19:40:46 +0200
Message-Id: <5A20C8D8-3A42-464D-9D6D-79F1567B6FA4@employees.org>
References: <860c946a-c23c-4060-d83c-587302de28f8@si6networks.com>
Cc: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, v6ops list <v6ops@ietf.org>
In-Reply-To: <860c946a-c23c-4060-d83c-587302de28f8@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: iPhone Mail (17B5084a)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/dp_Inkx75GNmgBLV3fv9SU8nlTc>
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: Fri, 25 Oct 2019 17:40:53 -0000


> On 25 Oct 2019, at 19:34, Fernando Gont <fgont@si6networks.com> wrote:
> 
>>> What about a "IPv6 renumbering considered harmful" or "Unstable DHCP-PD prefix considered harmful" ?
>> 
>> Perhaps, but isn't there a long list of documents the IETF has produced on IPV6 renumbering already?
>> Would a new document say anything new and more useful?
>> 
>> And it's not like DHCPv6 PD (RFC3633) isn't clear either. From the abstract:
>> 
>>   The Prefix Delegation options provide a mechanism for automated
>>   delegation of IPv6 prefixes using the Dynamic Host Configuration
>>   Protocol (DHCP).  This mechanism is intended for delegating a long-
>>   lived prefix from a delegating router to a requesting router, across
>>   an administrative boundary, where the delegating router does not
>>   require knowledge about the topology of the links in the network to
>>   which the prefixes will be assigned.
> 
> Long-lived != immortal. As long as a prefix eventually changes, that is
> when the problem may be experienced.

Not if renumbering of the network is done according to specification. 
Flash renumbering is not defined so no-one should be surprised that you get undefined behavior. 

O.