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

Ole Troan <otroan@employees.org> Tue, 26 February 2019 10:13 UTC

Return-Path: <otroan@employees.org>
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 1F85C130EBC; Tue, 26 Feb 2019 02:13:54 -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 RgmNJXOU2OzU; Tue, 26 Feb 2019 02:13:52 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C715130EB8; Tue, 26 Feb 2019 02:13:52 -0800 (PST)
Received: from astfgl.hanazo.no (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 97858FECBB2B; Tue, 26 Feb 2019 10:13:50 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id C8685EE96A7; Tue, 26 Feb 2019 11:13:47 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com>
Date: Tue, 26 Feb 2019 11:13:47 +0100
Cc: Tim Chown <Tim.Chown@jisc.ac.uk>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4F90B88-3EED-4AF2-82FE-5F1023A05605@employees.org>
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <CAHL_VyD34V=TRcsCp0DOO9HJNHyy5xkiMQ_cZoBa7zTE4fe5OA@mail.gmail.com> <ead01e0a-9211-7944-88d6-ae8d037c03a8@si6networks.com> <FB8B77EE-CC16-4418-BB5E-D44EE66D6B72@jisc.ac.uk> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Yk-3FWCyB9vu7kYJdGkCNuzrazg>
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: Tue, 26 Feb 2019 10:13:54 -0000

Fernando,

>>> On 25 Feb 2019, at 18:36, Fernando Gont <fgont@si6networks.com> wrote:
>>> 
>>> On 25/2/19 07:32, Richard Patterson wrote:
>>>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont <fernando@gont.com.ar> wrote:
>>>> 
>>>>> * As per RFC4862, it turns out that you cannot remove a stale prefix vy
>>>>> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards,
>>>>> not even the CPEs can (even if they wanted to) do something to fix the
>>>>> problem.
>>>> 
>>>> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but
>>>> the Preferred Lifetime can.  So we can't invalidate the prefix, but we
>>>> can deprecate it so it's not used for new outbound sessions.   This is
>>>> what we've implemented in our CPEs, after an unavoidable change in
>>>> prefix, and it seems to have mitigated (or reduced the impact of) the
>>>> issue.
>>> 
>>> Agreed. That said, with the current default lifetime values, things
>>> become tricky:
>>> At least in theory, you should be sending such RAs for "Valid Lifetime"
>>> seconds. With a default of one month, that means that, in theory, you
>>> should be sending such RAs for a month. And if there are multiple
>>> crash-and-reboot events, you should advertise each of the stale
>>> prefixes. (I assume the CPE just records the last one)
>> 
>> When / where was the default Valid Lifetime chosen to be one month?
> 
> Section 6.2.1 of RFC 4861:
> 
>      AdvPrefixList
>                     A list of prefixes to be placed in Prefix
>                     Information options in Router Advertisement
>                     messages sent from the interface.
> 
>                     Default: all prefixes that the router advertises
>                     via routing protocols as being on-link for the
>                     interface from which the advertisement is sent.
>                     The link-local prefix SHOULD NOT be included in the
>                     list of advertised prefixes.
> 
>                     Each prefix has an associated:
> 
>                        AdvValidLifetime
>                             The value to be placed in the Valid
>                             Lifetime in the Prefix Information option,
>                             in seconds.  The designated value of all
>                             1's (0xffffffff) represents infinity.
>                             Implementations MAY allow AdvValidLifetime
>                             to be specified in two ways:
> 
>                               - a time that decrements in real time,
>                                 that is, one that will result in a
>                                 Lifetime of zero at the specified time
>                                 in the future, or
> 
>                               - a fixed time that stays the same in
>                                 consecutive advertisements.
> 
>                             Default: 2592000 seconds (30 days), fixed
>                             (i.e., stays the same in consecutive
>                             advertisements).


Red herring.

RA lifetimes cannot be longer than the DHCP PD lifetimes.
In the DHCP PD case they should also be counted down in real time.
And the lifetimes can be dynamically adjusted.

Cheers,
Ole