IETF Logo Mail Archive

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

Jan Zorz - Go6 <jan@go6.si> Mon, 04 February 2019 11:10 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 C9DA8130E2E for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 03:10:57 -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, 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 GC_ahqlXG7Sb for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 03:10:56 -0800 (PST)
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 46DFB12872C for <ipv6@ietf.org>; Mon, 4 Feb 2019 03:10:56 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 901316602B for <ipv6@ietf.org>; Mon, 4 Feb 2019 12:10:54 +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 E1AAPc4CVsP0 for <ipv6@ietf.org>; Mon, 4 Feb 2019 12:10:48 +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 CEDE760749 for <ipv6@ietf.org>; Mon, 4 Feb 2019 12:10:48 +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 54828809E6 for <ipv6@ietf.org>; Mon, 4 Feb 2019 12:10:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1549278648; bh=hyKUqQKrRbenJL2ehMCjZAGbEwXlE3wy//1DbQC+hbM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=D5vQl+NzDJnQEnbpHdEudG9/PvoSp5uI0cWz+emW2oOnJJ95cXUwi0QKNvrgh7gUv Vz/7I55lXv7AxC8SgPXrDqOdRf4t3GwcaTeIghOZzz5BpIk29lz7OqNe0O0z09ssHs D5m2QLIP32O/LzFd6mWoLk6qmYE/4wB8dZr8Jj9Q=
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> <ac773bb5-0da8-064b-d46b-3a218b8c9e7a@si6networks.com> <CFAEACC4-BA78-4DF9-AD8A-3EB0790B8000@employees.org> <a4f6742e-f18e-3384-d4cc-06bfab49101f@si6networks.com> <FEFA99C2-4F09-4D8F-8D51-C9D9D7090637@employees.org>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <ce75e608-61be-4fb5-905a-c7decf1ef24c@go6.si>
Date: Mon, 04 Feb 2019 12:10:47 +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: <FEFA99C2-4F09-4D8F-8D51-C9D9D7090637@employees.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/O9Wk4aOYuezPXj75tYiK7bTvZk4>
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 11:10:58 -0000

On 03/02/2019 13:27, Ole Troan wrote:
>> Ideally, the CPE will advertise that the contract is void. But it
>> is clear that for most deployed CPEs, that will not happen.
> 
> So a bug. What you are talking about is the case where the ISP breaks
> the contract. While it previously promised to delegate you a prefix
> until 20200301, all trace of that has gone.
Ok, so this is clear. As already suggested - should we write a Standards 
document for provisioning providers vendors and say that they MUST only 
write code that can sets a prefix lifetime to something longer than the 
lifetime of their business contract with their customer and also that 
they MUST NOT allow operators to assign to their customers a different 
prefix during that lifetime and break their contract with this?

This would be an easy fix. Number of provisioning providers vendors is 
much smaller than CPE providers and hosts to fix on the planet. :)

Cheers, Jan

v2.23.0 | Report a Bug | By Email