IETF Logo Mail Archive

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

Tarko Tikan <tarko@lanparty.ee> Thu, 31 January 2019 16:42 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 C8B6C130E0A for <v6ops@ietfa.amsl.com>; Thu, 31 Jan 2019 08:42:39 -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 RKl9yhHDNsXm for <v6ops@ietfa.amsl.com>; Thu, 31 Jan 2019 08:42:38 -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 9106F130E6B for <v6ops@ietf.org>; Thu, 31 Jan 2019 08:42:38 -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 1gpFQC-0002Mj-Bs; Thu, 31 Jan 2019 18:42:36 +0200
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, v6ops@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <7b77cbfe-2bee-fda0-9751-44f9fb95a553@forthnet.gr> <d9eeb2b7-588b-0ce0-00a7-354960d94400@lanparty.ee> <m1gpFLa-0000FyC@stereo.hq.phicoh.net>
From: Tarko Tikan <tarko@lanparty.ee>
Message-ID: <9da736fc-032f-1466-f90f-5d346e73a1aa@lanparty.ee>
Date: Thu, 31 Jan 2019 18:42:36 +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: <m1gpFLa-0000FyC@stereo.hq.phicoh.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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/PCc9ZrM3JfmPGrX2jdpinmpGpz0>
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:42:40 -0000

hey,

> There is always the possibility that someone uses a switch or a wifi
> repeater.
> 
> In addition, VMs (on a laptop) can be connected using a software bridge on
> the host.
> 
> Simple setups will be fine, but it may be worth solving this problem.

Sure, don't get me wrong, I'm not saying it's an non-issue that is not 
worth solving. Everyone would win if we could iron out another corner case.

Like with everything, we have to balance different factors. Considering 
how many problems (many) we have had due to flash wear/issues in the 
CPEs, and also considering the lack of issues (none) due to additional 
switches/equipment, I'd say the solution is not storing the prefix 
information to flash.

-- 
tarko

v2.23.0 | Report a Bug | By Email