Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)

Owen DeLong <owen@delong.com> Tue, 12 November 2019 04:19 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 9C2F21200C3 for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 20:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Level:
X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 5Vg-H35jbFBE for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 20:19:26 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDFD120115 for <v6ops@ietf.org>; Mon, 11 Nov 2019 20:19:26 -0800 (PST)
Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xAC4IC7n030473 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 20:18:17 -0800
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xAC4IC7n030473
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1573532298; bh=amUYQYc6yxCKwxO3X8PNMhpoVXwTu3bcrnuDu3/aUuc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=ef/MM5m14U+W1Tu3MjxZ1UVImigT6yq4Z72cKS4W7AA4cu3yS9njqx1fvZhliYUkY c3+Mx7JKHkpWhl0an9zKZ7xfmQguXHAplPNksZ3UZ+METgLVBFJiINm7+Lstdu/FEO bSw9EL6TIMJ+YOBPGykPXV1DhWZ6/nLlERuTnk7s=
From: Owen DeLong <owen@delong.com>
Message-Id: <4705CFC1-BD69-4C2B-8AC0-BA3ADF2D0DE2@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FAFD616F-EEF0-4DE0-89BF-6FD36B87EDD2"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 11 Nov 2019 20:18:12 -0800
In-Reply-To: <BB40F000-AEBE-4A65-A55E-077D9171BA11@fugue.com>
Cc: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, v6ops@ietf.org
To: Ted Lemon <mellon@fugue.com>
References: <m1iU5Lh-0000LOC@stereo.hq.phicoh.net> <BB40F000-AEBE-4A65-A55E-077D9171BA11@fugue.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Mon, 11 Nov 2019 20:18:18 -0800 (PST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/zX3ub0xnU3yo0ORNoK9wl1Kxw-A>
Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: 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, 12 Nov 2019 04:19:28 -0000


> On Nov 11, 2019, at 03:01 , Ted Lemon <mellon@fugue.com> wrote:
> 
> On Nov 11, 2019, at 3:47 AM, Philip Homburg <pch-v6ops-9@u-1.phicoh.com> wrote:
>> 
>> In your letter dated Fri, 8 Nov 2019 16:30:31 +0100 you wrote:
>>> why would we have to delay deployment?
>> 
>> So the ISP delays rolling out IPv6 until either the problem is fixed in
>> IPv6 or, less likely, the ISP has a chance to re-engineer their setup to
>> avoid flash renumbering.
> 
> The ISP has to install a DHCPv6 server in order to do an IPv6 deployment.  We’ve already heard from one of the main vendors of DHCPv6 servers that their server behaves correctly and does not do flash renumbering.   The two DHCPv6 servers that I have worked on don’t either.  So why is the ISP going to have to delay?  The one time I was asked to help an ISP to set up DHCPv6 in a way that would allow frequent renumbering, it was a major engineering effort (which we wound up not doing).   The ISP would have to go out of their way to not support stable prefixes.
> 
> So where is the impediment to deployment?

We’ve also heard from at least one cable provider how flash renumbering is inflicted on their customers due to splits/combines/moves of blocks of customers from one CMTS to another.

Owen