IETF Logo Mail Archive

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

Ole Troan <otroan@employees.org> Tue, 19 February 2019 06:00 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 32B0F130E71; Mon, 18 Feb 2019 22:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 45XWtB4uHQ3K; Mon, 18 Feb 2019 22:00:00 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72567124BF6; Mon, 18 Feb 2019 22:00:00 -0800 (PST)
Received: from [192.168.10.189] (30.51-175-112.customer.lyse.net [51.175.112.30]) (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 BA968FECC155; Tue, 19 Feb 2019 05:59:58 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (16D39)
In-Reply-To: <d9503983-6524-a13a-2cb0-cdcb95f76ea6@si6networks.com>
Date: Tue, 19 Feb 2019 06:59:56 +0100
Cc: Jen Linkova <furry13@gmail.com>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <207AEC9F-BD52-437C-AAA2-AB974DA17AFC@employees.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>
To: Fernando Gont <fgont@si6networks.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/fgkBJJ9IobQbrpLZWl_Xb2qXId0>
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: Tue, 19 Feb 2019 06:00:04 -0000


> On 18 Feb 2019, at 23:24, Fernando Gont <fgont@si6networks.com> wrote:
> 
> Hello, Jen,
> 
>> On 18/2/19 17:16, Jen Linkova wrote:
>> On Thu, Jan 31, 2019 at 11:12 PM Fernando Gont <fgont@si6networks.com> wrote:
>>>> When the new prefix is received it'll most likely have a higher
>>>> preferred and valid lifetime, so hosts should use the new prefix just by
>>>> means of them preferring the higher preferred lifetime of that PIO. So
>>>> the problem is a bit less than you write in the draft.
>>> 
>>> Nothing in the spec says preference is related to the "Preferred
>>> Lifetime" timer. i.e., an address is preferred, or it is not...
>> 
>> I tried to address this problem before (and there are more use cases
>> than just CPE reboot):
>> https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00
>> 
>> I might be biased here indeed but I think that using the "most
>> recently updated" (however we define that) address would be the
>> simpler solution than
>> deprecating the whole prefix (and both solution requires hosts to keep
>> the PIO <> advertising router mapping).
> 
> Say the Stale prefix is 2001:Db8:1::/64, for which you configured
> 2001:db8:1::1.
> 
> Say that Prefix(2001:Db8:1::/64) has now become stale, and a new prefix
> 2001:db8:2::/64 is being announced, for which you have 2001:db8:2::1.
> 
> Say you now need to send packets to 2001:db8:1::/64.
> 
> You will use the new addresses (from 2001:db8:2::/64), but will send the
> packets assuming nodes are "on-link", instead of sending them to the
> default router.
> 
> -- You do need to get rid of information, including routes, asap.
> 
> Similarly, if you have multiple interfaces, Rule 5 might override your
> rule 8. Whether because you are sending to the stale prefix, or because
> your first default-router was the one the happened to crash-and-reboot.

How is your case different from the multi-prefix multi-homed case where one path is (temporary) out of service?

Ole

> 
> Cheers,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email