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

Ole Troan <otroan@employees.org> Thu, 24 October 2019 13:38 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 388DF120889 for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 06:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 vATBvG01cwUl for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 06:38:39 -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 DE1DD120232 for <v6ops@ietf.org>; Thu, 24 Oct 2019 06:38:39 -0700 (PDT)
Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id C017E4E11AEF; Thu, 24 Oct 2019 13:38:38 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id C5A6E1FEAB38; Thu, 24 Oct 2019 15:38:36 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <A61279DA-4678-4A10-9117-6CA227AE2FA5@cisco.com>
Date: Thu, 24 Oct 2019 15:38:36 +0200
Cc: Mark Smith <markzzzsmith@gmail.com>, v6ops list <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A90AD47E-00E2-4EAB-8BD8-142CC10A6B6F@employees.org>
References: <m1iNIFE-0000IwC@stereo.hq.phicoh.net> <d1b6855d-bde9-7b53-4809-0846bb9772e4@si6networks.com> <CAO42Z2x7vudujw5t++obry56g=VNjQXXTHFK8pBPk0jmk78Bcg@mail.gmail.com> <CAJoHkZ8pTjszP0vw4BjX0HUhmPa6wJONzdy2JEm5iqAfBUvjRg@mail.gmail.com> <CAO42Z2wCYi4KWTEz1hUSPVr9+hu8GaHRkPuvQQ2P00knvnPaaQ@mail.gmail.com> <848BA3B3-36B4-4C42-86D0-88759BC45D5A@employees.org> <A61279DA-4678-4A10-9117-6CA227AE2FA5@cisco.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/vtRquFvTtz9r8zT2DTCeCVe_BpE>
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: Thu, 24 Oct 2019 13:38:41 -0000

Eric,

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


That said, if people want to write a "IPv6 networks need stable prefixes" document, go ahead.
I'm skeptical that playing with prefix timers and protocol mechanisms will do more than put lipstick on the pig. Iff we wanted to solve ephemeral addressing / connectivity, that's would require something else.

Best regards,
Ole