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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 14 February 2019 10:21 UTC

Return-Path: <prvs=1948fd41cf=jordi.palet@consulintel.es>
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 A733B130DC9 for <ipv6@ietfa.amsl.com>; Thu, 14 Feb 2019 02:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 eWZHwsWP3l1p for <ipv6@ietfa.amsl.com>; Thu, 14 Feb 2019 02:21:51 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6A912870E for <ipv6@ietf.org>; Thu, 14 Feb 2019 02:21:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1550139708; x=1550744508; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=Cjtc9JxgO8qw+SYnimpVCE1Ik7OknEswCkHeUCK26WE=; b=Z+AUNrjCPeFTn ax+21hq93V+aHfW2A4DKPtCA+QTA6/TtNS8Y9kff0Rl/Y4HuQZukgHCsSBt6zhOt me7Y0sMQ36BEcWwsy0YSoT0qzXBB+J1eGLeK9NzKnrnw4elrI+jgjZ7FiGpJW1gy DJXa6CXHMT1cZsrQh6/3d7Lbi9hKno=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 14 Feb 2019 11:21:48 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 14 Feb 2019 11:21:47 +0100
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006154599.msg for <ipv6@ietf.org>; Thu, 14 Feb 2019 11:21:46 +0100
X-MDRemoteIP: 2001:470:1f09:495:2cd1:4c11:8272:8b78
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Thu, 14 Feb 2019 11:21:46 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1948fd41cf=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.7.190210
Date: Thu, 14 Feb 2019 11:21:45 +0100
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Nick Hilliard <nick@foobar.org>, Mark Smith <markzzzsmith@gmail.com>
CC: 6man WG <ipv6@ietf.org>
Message-ID: <56F813F4-C512-40A9-8A68-1090C76A80F6@consulintel.es>
Thread-Topic: A common problem with SLAAC in "renumbering" scenarios
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org> <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se> <46B8DB92-DC81-4242-9780-0D00FB6BDB7A@employees.org> <1c7ebabb-d6f6-d877-d4aa-d6c0fc7d5c60@go6.si> <6278.1549471453@dooku.sandelman.ca> <CAO42Z2xdKtLJV11KXELBKca6CWn=B6Avz6bO_94kFFXaKiZ-pQ@mail.gmail.com> <4602.1549908472@localhost> <CAO42Z2w1swQNuwnrOyTCEMXt0NSyrBx7Ww3kUN-7dfEV=fvk3A@mail.gmail.com> <c16e0e1f-1ed2-ad88-80f1-070bdd8bccca@go6.si> <1F2C2AEE-1C7D-481C-BBA7-7E507312C53A@employees.org> <e56a6e5b-648d-200e-c35d-97f15a31fb2a@asgard.org> <CAO42Z2zh7fKAgQJq9aLCTiFoSSsTeGM=pK3gXitg+gcxH=9fhQ@mail.gmail.com> <d38857c2-6e92-91d6-bb5d-d3eeeb61276a@gmail.com> <CAO42Z2yb47OyXk__Sz-kO00pfcBJgLAhff5DF=mpAddR0iCnAA@mail.gmail.com> <2612280f-195a-ae7a-b3b1-9022d9282fa7@foobar.org>
In-Reply-To: <2612280f-195a-ae7a-b3b1-9022d9282fa7@foobar.org>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/e_QBeeFGdhs9OxtC71FiixpNhyQ>
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: Thu, 14 Feb 2019 10:21:54 -0000

    Mark Smith wrote on 14/02/2019 04:46:
    > So to me, the cheapest and best solution is for the an ISP to provide
    > a static/stable PD prefix to the customer (even though I've written
    > code to try to mitigate it i.e. . DeprecatePrefix and
    > DecrementLifetimes in radvd in the past.)
    
    Mark,
    
    Largely, I agree with your rationale on this.  The problem is that ISPs 
    will be loath to commit to a stable prefix for the lifetime of a 
    customer account.  This approach doesn't scale for larger providers 
    because it commits them to making routing compromises for the lifetime 
    of customer accounts, e.g. injecting dynamically assigned prefixes into 
    their routing tables.  Accretion of configuration fossils causes long 
    term complexity problems.


Why not? This is already happening in IPv4. I've got from a major operator in Spain (and other operators in other countries do the same), the same IPv4 address for decades! I'm talking about residential services, with both DSL and GPON. Not to mention business services were you actually pay for that static address a monthly fee.

Any contract can have special clauses, that clearly indicate that "in case of major technology or network changes or similar events, renumbering can happen and in those situations the customers will be alerted with a minimum of 1 month" (this is just an example, I can think in many alternative wordings).
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.