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

Tore Anderson <tore@fud.no> Mon, 04 February 2019 07:29 UTC

Return-Path: <tore@fud.no>
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 487731292F1; Sun, 3 Feb 2019 23:29:47 -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 HBCShOMTOvmK; Sun, 3 Feb 2019 23:29:45 -0800 (PST)
Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9B7126CC7; Sun, 3 Feb 2019 23:29:45 -0800 (PST)
Received: from [2a02:c0:2:90:443:6:0:1000] (port=52472 helo=sloth.fud.no) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from <tore@fud.no>) id 1gqYhK-0007RQ-HK; Mon, 04 Feb 2019 08:29:42 +0100
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, Fernando Gont <fgont@si6networks.com>, Ole Troan <otroan@employees.org>
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, 6man WG <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> <a484d5de-0dce-a41a-928e-785d8d80d05d@si6networks.com> <A40C5116-9474-4F2B-BD94-F57D155ECD4C@employees.org> <b05e3872-d63b-108c-6c00-21b951dad263@si6networks.com> <A9FBBED3-A858-4BB1-A02A-2A06CBEB7662@consulintel.es> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com>
From: Tore Anderson <tore@fud.no>
Message-ID: <822850f0-12b3-d29d-6fcc-7739f11897ec@fud.no>
Date: Mon, 04 Feb 2019 08:29:41 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ksCt8y4iY22eMfWjtoXe8FBgu3o>
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 07:29:47 -0000

* Brian E Carpenter

> It doesn't matter. The objective fact is that getting a new prefix after a CPE reboot, or after a DSL disconnect/reconnect, or every 24 hours, is common, and not just in Germany.
> 
> Not that I've ever had any stale address problems as a result, even at a time when I was getting multiple ADSL disconnects per day due to a line fault. So with a FritzBox and Windows hosts, the "common problem" simply wasn't a problem.
If I recall correctly, the FritzBox I used to own would immediately send a few
RAs with PIO timers=0 after receiving a packet from the LAN with a source
address from a unknown prefix.

Thus it didn't have to worry about remembering the previous delegated prefixes
across a crash+reboot, as it would be reminded about it and get the opportunity
to invalidate it the second a host tried to use it.

That approach didn't work very well in networks with multiple routers, of
course...

This was 7-8 years ago, things might have changed since then.

Tore