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

Owen DeLong <owen@delong.com> Thu, 24 October 2019 15:57 UTC

Return-Path: <owen@delong.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 70AAB12011C for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 08:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.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 Z_E16Sii-Svm for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 08:57:09 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 53A3F1200CC for <v6ops@ietf.org>; Thu, 24 Oct 2019 08:57:08 -0700 (PDT)
Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x9OFv149016541 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Oct 2019 08:57:05 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x9OFv149016541
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1571932627; bh=e95bmMxKW6puHriG5cUe7KdqEVWK2NamgvYTeN84LLs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=FwDzVj7lKZePMZVBnRUA88G/81wtS5sm4AxzTgO0AzGQTJ0YzezminaLLj5pf7o8z XTuPJ7nDg//EvsW5XlDzjdHfMrAYGrih0aCHMR7KGU8qN2azgoT+qC3mYG7EtU0NSD bq72yOSn1DCd4lK1R0nAN8dQZJEvIHpv1w9Fg2vA=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <m1iNIFE-0000IwC@stereo.hq.phicoh.net>
Date: Thu, 24 Oct 2019 08:57:01 -0700
Cc: v6ops@ietf.org, Fernando Gont <fgont@si6networks.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <19CE795F-B6B9-40A4-9231-34A73A84561C@delong.com>
References: <m1iNIFE-0000IwC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Thu, 24 Oct 2019 08:57:07 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/OjJC6Nl7wKjn3-UUdTTX77Qzhtc>
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: Thu, 24 Oct 2019 15:57:13 -0000


> On Oct 23, 2019, at 08:08 , Philip Homburg <pch-v6ops-9@u-1.phicoh.com> 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.
> 
> 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.
> 
> At the same time, AdvDefaultLifetime is commonly 1800 seconds. Which is way
> too long to wait for stale information to expire.

Isn’t the issue of stale information strictly under the control of the person running
the router(s)?

I mean during normal operations, 1800 seconds seems like a reasonable default
to me. In an environment where you are depending on routers advertising different
prefixes on the same network for redundancy (you’ve kind of cobbled things
poorly to begin with), you’ll want to select a shorter time, certainly, but then you
have that option. In a more traditional environment where you have multiple
routers announcing the same prefix providing redundancy, then it seems to me
that the prefix only goes stale during a renumber event.

The procedure for renumbering a SLAAC network should be relatively straightforward…

1.	Configure and test new prefix on routers and perhaps a few test hosts with manual
	configuration.

2.	Begin announcing new prefix via RAs.

3.	Note the Valid Lifetime for the old prefix. (Tvold).

4.	Take the old prefix out of the RAs (leave it fully configured on the routers).

5.	Wait some time greater than Tvold for the old prefix to expire.

6.	Remove the old prefix from the routers.

> 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'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.

Any tying of them to AdvDefaultLifetime should be merely for the purpose of
establishing a default, which seems a reasonable process. Certainly there
is a need for the Valid and Preferred lifetimes to be ≥ MaxRtrAdvInterval
which must be ≤ AdvDefaultLifetime for things to function at all.

> Reducing the lifetimes would help against build up of stale prefixes. If
> they are set to a couple of hours.

Shouldn’t this be an individual administrative decision on a site-by-site
basis?

If we’re looking to set more rational defaults or provide advice on better
defaults to administrators and/or product developers, then perhaps we
should provide a context-aware set of rational defaults for these variables.

IMHO, there are a number of contexts each of which would likely need
different values to achieve an optimum balance:

	Single-homed household or SMB end-user
	Multi-homed multi-prefix household or SMB end-user
	Multi-homed single-prefix (BGP) end site
	Enterprise Environment
	Transit Network (would you even use SLAAC here?)
	Others?

Owen