IETF Logo Mail Archive

Re: A common problem with SLAAC in "renumbering" scenarios

Jan Zorz - Go6 <jan@go6.si> Mon, 04 February 2019 10:54 UTC

Return-Path: <jan@go6.si>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0BD130E59 for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 02:54:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 DWGSiaoIc6eh for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 02:54:28 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [91.239.96.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 984A3130E5A for <ipv6@ietf.org>; Mon, 4 Feb 2019 02:54:26 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 689536602B for <ipv6@ietf.org>; Mon, 4 Feb 2019 11:54:23 +0100 (CET)
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 8vdQWu9peEeQ for <ipv6@ietf.org>; Mon, 4 Feb 2019 11:54:22 +0100 (CET)
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 550A365E65 for <ipv6@ietf.org>; Mon, 4 Feb 2019 11:54:22 +0100 (CET)
Received: from haktar.local (unknown [IPv6:2001:67c:27e4:5::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Jan Zorz", Issuer "COMODO RSA Client Authentication and Secure Email CA" (not verified)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id D5C3E80949 for <ipv6@ietf.org>; Mon, 4 Feb 2019 11:54:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1549277661; bh=0K90CJhQ5Nts6Fojxf3lVXM8k0tUWDwmn8eZQdtsQRE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=tgYk9DiZ2verKgsI3TMzI2KYT1LoQul8qeYAewbXfyKg4Y1tpicF0IDoQv8KtjtSg bHQNQ1P61wHn8IabCF8AfeCplzqFTDWbN779fvt8dzg1xV54+ntajSLxy7nrHkOGrE 1K2prqcp1aaXH0n6NE/ZUeAGGpFnMQPrO21e3oR0=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <m1gpCcz-0000FlC@stereo.hq.phicoh.net> <ddd28787-8905-bafd-3546-2ceef436c8b0@si6networks.com> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si>
Date: Mon, 04 Feb 2019 11:54:19 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org>
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/ipv6/UohdXG8ZE5Vh0VEssD4te-zxTCs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Feb 2019 10:54:31 -0000

On 02/02/2019 12:57, Ole Troan wrote:
>> One question is whether it makes sense for routers to have valid lifetimes of
>> more than a day for prefixes that are obtained using DHCP-PD.
>>
>> Another is whether general purpose hosts should accept lifetimes of more
>> than a day. Maybe hosts should just truncate.
> 
> The (original) intended lifetime for DHCP PD is a lifetime equal to the length of the contract with your ISP.
> Lifetimes become meaningless with “flash renumbering”. Neither SLAAC nor DHCP PD is designed for that.
> 
> The simple solution to this problem is “if it hurts, stop doing it”.

Ole, in theory, I agree with you.

In practice - "if it hurts, stop doing it" means that ISPs declares IPv6 
as not functioning and switch it off for good.

Is this what we want?

CPE power-cycle is something that ISP has no control of. Now, if 
provisioning vendors would play our game, then they would never 
implement a provisioning mechanism that allows flash renumbering, as you 
call it.

Ole, I would ask you a favour. Can you ask internally at your employer 
why provisioning at BRAS allows creating "pools" of IPv6 addresses and 
dynamic prefix delegations? Basically, this is the core root of a 
problem and if we can fix it in provisioning platforms, then we are all 
set and there is no need for changing CPE or host.

But I'm afraid that the answer that you'll get will be "customers 
demanded this and we had to implement it". Money talks. Do you think we 
can change that? Talk VendorC, VendorJ, VendorX and all others into 
turning their behaviour into one that actually give ISPs even an option 
to honour their "contract" with a customer, even in case of unintended 
event with the CPE?

Should we write a Standard RFC that neatly defines all the MUSTS for 
provisioning platforms?

If yes - good. If not - then we have to change the host and CPE.

Cheers, Jan

v2.23.0 | Report a Bug | By Email