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

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 20 February 2019 04:31 UTC

Return-Path: <jmh@joelhalpern.com>
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 B2EAF12E036; Tue, 19 Feb 2019 20:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 7VOQWUKP1uPr; Tue, 19 Feb 2019 20:31:25 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 52A3E12DD85; Tue, 19 Feb 2019 20:31:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4444Rw5G73z1c0cg; Tue, 19 Feb 2019 20:31:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1550637084; bh=jQnQxcMB364HIkq7WSFhEhdb+HlnqHfBsNvPxE1x3oA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VsR8BACy37AceK7zOljYpk9D1qwmXnqbGBXRCWiK5mHQ4QrE1BWxBwLoevaeVnsU+ mp6G9uG8VOXnHkxlqILd2JAnQlPUAhxFvWkZjOLZqs3TFbZmWx6Ab/eRAoHtFe8H86 JJ9vmaOs5XTMW3L1HuRUMlPtc/ncSqnbAbAGanlI=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4444Rv5tk0z1c02P; Tue, 19 Feb 2019 20:31:22 -0800 (PST)
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: Fernando Gont <fgont@si6networks.com>
Cc: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com> <CAFU7BAS1_veTu-ZXAF0MF4niJwz149nGipx3ep_6fh1bewOzgg@mail.gmail.com> <d9503983-6524-a13a-2cb0-cdcb95f76ea6@si6networks.com> <CAFU7BAQfg712UfgW9wi9pd3eVeZP9cqJEXd6=FDmchuSdauv+g@mail.gmail.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <d9acba7b-4414-469f-44dc-b72354ab3421@joelhalpern.com>
Date: Tue, 19 Feb 2019 23:31:21 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TcXNOBTgqN4dgO26FGzIZnk-n_k>
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: Wed, 20 Feb 2019 04:31:27 -0000

I was trying to think through what breaks if you do the below.
The one case I can see is if there is an open TCP connection using the 
prefix to be dropped.  If that TCP connection appears to be working, 
then dropping the prefix would seem harmful.  It would also seem that if 
the TCP connection is working that would be evidence that there is no 
need to drop the prefix.

Yours,
Joel

On 2/19/19 10:59 PM, Fernando Gont wrote:
,,,
> This is not the way the proposed algorithm work.
> 
> I'd agree with you that if you stopped receiving RAs, *that* wouldn't
> necessarily warrant a prompt reaction.
> 
> However, the proposed algorithm reacts to *RAs from the same router*
> (i.e. the router *is alive*) that do carry PIOs, but they happen to
> advertise PIOs for different prefixes.
> 
> Once you receive four RAs with PIOs from the same router, all of them
> including PIOs, but failing to advertise the stale prefix, you remove
> the addresses.
,,,