IETF Logo Mail Archive

Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 26 February 2019 13:31 UTC

Return-Path: <swmike@swm.pp.se>
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 A3B4E130EA2; Tue, 26 Feb 2019 05:31:15 -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 epXq0fqpguZ7; Tue, 26 Feb 2019 05:31:09 -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 3AF91130E5D; Tue, 26 Feb 2019 05:31:09 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9E9A7B2; Tue, 26 Feb 2019 14:31:07 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1551187867; bh=XQ/tZrGPTqGmzCFXyiAK0w+rIu/edghGC0oX/UIhTr4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TRfiv47Yyqb2DZVL9vY/sNamyjieOIRmIAf0CnmnZ1jK2NhQLwEEuLRV4851yUwZ3 k4KNmuqxQkxNmQnTCsxEmZEyHXIUetXgF0CYpl8ZeHzy1opVmEQ62OPuuD9XwXEgx9 H5bUyav4CFdqz/n6sAkkGXka6jfV/+4GE1J9bxlQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9B4A9B0; Tue, 26 Feb 2019 14:31:07 +0100 (CET)
Date: Tue, 26 Feb 2019 14:31:07 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Fernando Gont <fgont@si6networks.com>
cc: Ole Troan <otroan@employees.org>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <c3562b5b-0eec-636b-3bb1-1b0381109542@si6networks.com>
Message-ID: <alpine.DEB.2.20.1902261428050.24327@uplift.swm.pp.se>
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <CAHL_VyD34V=TRcsCp0DOO9HJNHyy5xkiMQ_cZoBa7zTE4fe5OA@mail.gmail.com> <ead01e0a-9211-7944-88d6-ae8d037c03a8@si6networks.com> <FB8B77EE-CC16-4418-BB5E-D44EE66D6B72@jisc.ac.uk> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> <F4F90B88-3EED-4AF2-82FE-5F1023A05605@employees.org> <c3562b5b-0eec-636b-3bb1-1b0381109542@si6networks.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/gRRfmKjA3qiO8ofbpgRr-3GnH_o>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
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, 26 Feb 2019 13:31:16 -0000

On Tue, 26 Feb 2019, Fernando Gont wrote:

> They should. However, quite frequently the DHCPv6-PD part is a different 
> piece of software from the ra{d,dvd} part. Both pieces are glued by some 
> script, and the lifetime is *not* dynamically adjusted.

In OpenWrt they are, and I definitely think this should be the default.

I also tries to deploy two upstreams in my home and this failed because 
the lifetime of my less preferred ISP was higher than my most preferred 
ISP, which meant the one with the highest lifetime was always used.

So there should be some kind of configurable cap that the HGW uses, so 
that this isn't a problem. It might also make sense to not have 24 hour or 
a week lifetimes on the LAN, even if the PD leasetime is this high. But 
these are two different problems, and I would like to see the LAN 
lifetimes lowered to more sane values, so that it's capped to 24 hours 
max. Maybe it should be even lower.

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

v2.23.0 | Report a Bug | By Email