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

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 04 February 2019 12:34 UTC

Return-Path: <swmike@swm.pp.se>
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 425C912896A for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 04:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 xdJ2TDAFsFwW for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 04:34:44 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 BD5EA124BF6 for <ipv6@ietf.org>; Mon, 4 Feb 2019 04:34:43 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4DF9FB2; Mon, 4 Feb 2019 13:34:41 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1549283681; bh=HIORClK1DENqTkvCxKRtQlKs0jVPTtFP5bBCdHKBoSI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=iyH3hrx4G98UN+OPWyISSy29/vkXtmZrHTJKO9/KornPtpoLoymA+dR8t6lMeImQp KKnRdRLw2vkVfVeEY150p9S4uwwdiM96XvzyoZ4gIuI4X4BSuG5WExCOIYiY/ekBC6 MBzHY68PTEy0t+lszulRHxXEEDH02hf9cVyL7cC0=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4C2CEB0; Mon, 4 Feb 2019 13:34:41 +0100 (CET)
Date: Mon, 04 Feb 2019 13:34:41 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ole Troan <otroan@employees.org>
cc: Jan Zorz - Go6 <jan@go6.si>, 6man WG <ipv6@ietf.org>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
In-Reply-To: <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org>
Message-ID: <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se>
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> <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-137064504-1070334850-1549283681=:23912"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/G4z1MgoPz3CIeOvebeAyBYxzQjw>
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 12:34:48 -0000

On Mon, 4 Feb 2019, Ole Troan wrote:

> Now, I know there are cases where huge swats of users are moved from one 
> aggregation point in the network to another, where routing would end up 
> very messed up if customer weren’t renumbered, and also that in those 
> cases that flash renumbering is a lot easier to do, but those are 
> typically known events.

My current ISP has stated that their intention is to make sure people keep 
the same prefix as long as their HGW is alive, and they even provide a 7 
day life time of the lease. So unless your HGW is alive once every 7 days, 
you get to keep the lease. This makes a lot of sense to me and is a decent 
tradeoff between different realities.

Now, there is nothing in the contract that regulates this so they're free 
to change whenever (and they do in case they need to move people around 
between aggregation routers, but this is a rare event).

Trying to demand that ISPs keep the same /56 for the duration of the 
contract is not going to work because that's not what real life looks 
like. I'd say we should take the fight about perhaps about lifetimes and 
definititely about delegation sizes (I still run into people with only /60 
or /64), but contract-length stable prefix isn't something I'd advocate to 
fight for. It's too far out even for me.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se