Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Fernando Gont <fgont@si6networks.com> Wed, 23 October 2019 16:07 UTC

Return-Path: <fgont@si6networks.com>
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 993A01200B3 for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2019 09:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 Mpnc_A1QQ41k for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2019 09:07:46 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A577412004D for <v6ops@ietf.org>; Wed, 23 Oct 2019 09:07:45 -0700 (PDT)
Received: from [192.168.4.76] (unknown [190.179.55.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0AE64865B4; Wed, 23 Oct 2019 18:07:41 +0200 (CEST)
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, v6ops@ietf.org
References: <m1iNIFE-0000IwC@stereo.hq.phicoh.net>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Message-ID: <d1b6855d-bde9-7b53-4809-0846bb9772e4@si6networks.com>
Date: Wed, 23 Oct 2019 11:07:20 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <m1iNIFE-0000IwC@stereo.hq.phicoh.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ChqgyU2izny_nE3XD52ajO8PStg>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
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: Wed, 23 Oct 2019 16:07:48 -0000

On 23/10/19 10:08, Philip Homburg wrote:
>> The document is available at:
>> https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum
> 
> I think this is an important subject that is worth fixing.
> 
> In this reply I'll focus on the preferred and valid lifetimes.
> 
> On a host, the preferred and valid lifetimes play quite different roles.
> 
> The preferred lifetime plays a role in setting up new flows. I.e. if the
> application does not provide a source address then the IPv6 layer uses
> the preferred lifetime to select the best source address among multiple
> candidates. Mistakenly setting the preferred lifetime of an address to zero 
> may cause problems for new flows but has no impact on existing flows
> 
> In contrast setting the valid lifetime to zero immediately signals an error
> condition to existing flows. This could cause a lot of trouble for long 
> lived flows.
> 
> The other side of the coin is that if a host ends up with stale prefixes,
> then the user maybe willing to wait for a few minutes for the situation to
> resolve itself, but probably not much longer.

Agreed.



> So the suggestion that
> 	AdvPreferredLifetime: AdvDefaultLifetime
> is likely not sufficient to be responsive to a user. And at the same time
> 	AdvValidLifetime: 1.5 * AdvDefaultLifetime
> is very risky if AdvDefaultLifetime is low.
> 
> Note that RFC 4861 allows MaxRtrAdvInterval to be a low as 4 seconds, 
> AdvDefaultLifetime can be as low as MaxRtrAdvInterval, so also 4 seconds.
> 
> This creates a very fragile system.

I may agree. That said, note that according to RFC7772, you'd never send
RAs at a high frequency such as once as every 4 seconds.



> At the same time, AdvDefaultLifetime is commonly 1800 seconds. Which is way
> too long to wait for stale information to expire.
> 
> I agree that valid and preferred lifetimes of resp. 30 days and 7 days 
> are excessive. But I'm not at all convinced that tying them to 
> AdvDefaultLifetime will have a positive effect.

I'd say that at the very least the Preferred lifetime shouldn't be
larger than AdvDefaultLifetime (what's the point of preferring an
address you don't have a router for?).

I do agree with your analysis of the valid lifetime -- is trickier.



> I'm also not convinced
> that there are sensible values for these lifetimes that are robust enough 
> and at the same time responsive enough to deal with the issue at hand.
> 
> Reducing the lifetimes would help against build up of stale prefixes. If
> they are set to a couple of hours.

I do agree that this is not a complete solution, but, as you correctly
note, would help against build up of stale prefixes.


A better mitigation is to affect the preferred and possibly the valid
lifetimes in response to consecutive RAs from the same router that lack
the original (stale) prefix. e.g., after two consecutive RAs that do not
contain the existing prefix, reduce the preferred lifetime. After two
additional RAs, reduce the valid lifetime.

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492