IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Sat, 02 February 2019 14:17 UTC

Return-Path: <otroan@employees.org>
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 8923812426A; Sat, 2 Feb 2019 06:17:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 3vB-kJn6ceQU; Sat, 2 Feb 2019 06:17:15 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4690A1228B7; Sat, 2 Feb 2019 06:17:15 -0800 (PST)
Received: from astfgl.hanazo.no (77.16.52.6.tmi.telenormobil.no [77.16.52.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 1BABAFECC0E8; Sat, 2 Feb 2019 14:17:14 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id AF6E1DE1251; Sat, 2 Feb 2019 12:57:30 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: Ole Troan <otroan@employees.org>
In-Reply-To: <m1gptWx-0000G3C@stereo.hq.phicoh.net>
Date: Sat, 02 Feb 2019 12:57:29 +0100
Cc: 6man WG <ipv6@ietf.org>, v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.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>
To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/eCMnqYZinXaMMm9lmikETkX--2w>
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: Sat, 02 Feb 2019 14:17:17 -0000

> 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”.

Cheers,
Ole

v2.23.0 | Report a Bug | By Email