IETF Logo Mail Archive

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

Tarko Tikan <tarko@lanparty.ee> Thu, 31 January 2019 16:26 UTC

Return-Path: <tarko@lanparty.ee>
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 71EDF128D52 for <v6ops@ietfa.amsl.com>; Thu, 31 Jan 2019 08:26:09 -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 Gdlm5lY17WAu for <v6ops@ietfa.amsl.com>; Thu, 31 Jan 2019 08:26:07 -0800 (PST)
Received: from valgus.lanparty.ee (valgus.lanparty.ee [194.126.124.108]) (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 18822127AC2 for <v6ops@ietf.org>; Thu, 31 Jan 2019 08:26:06 -0800 (PST)
Received: from tuli.elion.ee ([194.126.117.170] helo=[10.65.57.99]) by valgus.lanparty.ee with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <tarko@lanparty.ee>) id 1gpFAA-0002KM-Qj for v6ops@ietf.org; Thu, 31 Jan 2019 18:26:03 +0200
To: v6ops@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr>
From: Tarko Tikan <tarko@lanparty.ee>
Message-ID: <d9eeb2b7-588b-0ce0-00a7-354960d94400@lanparty.ee>
Date: Thu, 31 Jan 2019 18:26:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 194.126.117.170
X-SA-Exim-Mail-From: tarko@lanparty.ee
X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000)
X-SA-Exim-Scanned: Yes (on valgus.lanparty.ee)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Zob2CqO8HkpJ-I3EAozad9NIEFM>
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: Thu, 31 Jan 2019 16:26:10 -0000

hey,

> Isn't that handled by L-13 of RFC7084?
> 
> L-13:  If the delegated prefix changes, i.e., the current prefix is
>            replaced with a new prefix without any overlapping time
>            period, then the IPv6 CE router MUST immediately advertise the
>            old prefix with a Preferred Lifetime of zero and a Valid
>            Lifetime of either a) zero or b) the lower of the current
>            Valid Lifetime and two hours (which must be decremented in
>            real time) in a Router Advertisement message as described in
>            Section 5.5.3, (e) of [RFC4862].

Correct but this does not handle the CPE reboot scenario where old 
prefix information is not stored over reboot (but it does work great if 
prefix changes without reboot).

In reality we have not found the reboot to be a big problem as for most 
residential/SOHO customers the same CPE provides wired LAN ports and 
wifi. Both will be disconnected during reboot and this information is 
visible to OS and OSes will stop using the prefix on those interfaces 
due to that anyway.

-- 
tarko

v2.23.0 | Report a Bug | By Email