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

Mark Smith <markzzzsmith@gmail.com> Thu, 24 October 2019 08:17 UTC

Return-Path: <markzzzsmith@gmail.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 C5433120824 for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 01:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NTUlj6sL4ja8 for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 01:17:57 -0700 (PDT)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AF1120046 for <v6ops@ietf.org>; Thu, 24 Oct 2019 01:17:56 -0700 (PDT)
Received: by mail-oi1-x229.google.com with SMTP id v186so7051707oie.5 for <v6ops@ietf.org>; Thu, 24 Oct 2019 01:17:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rxyvXGkpXVs7QdXqyUDNoc07Q1dcKcm5KKgjKYBssMw=; b=ntrKJDE1EjNNumNzjjiG9E8FtSKZmpgLFQkqfuTff2aFU1KuwYOzSqN+BqsdwJuJlU c2ZgK1HnySPGIK/KMvM9ihHpb0sdF74MpoazVZ/v0SW049wZHXMPl0A5Og+QPKvmj/AB OYiwwc/BOgoAkuW/FkKsNaGCSvh94JzNZSaXm+TUfhuLG1W+Oc1B3Nh++uM9xKXC7+xz iNHnxOwnMc8n4ZClW3opQJ3kwidQm2U58TC03DzPArdaMJulPqHWgaBdvvOvoyx/tFqt kzoRwCKSbDiV/yhjV63jmIrHol//vdsrJPXYDMfMS92LBHJlImXJynhwCGGhiFVQS0MA kD3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rxyvXGkpXVs7QdXqyUDNoc07Q1dcKcm5KKgjKYBssMw=; b=ooQgwc+5IKU7boPGzppW8WSfvWQ4zpp763WJzGewyOh8w5Ch9/xyUJXAd5lq7qh4z6 WeVdV2o5bYX7dn8429dxZnhn5lBl7HFZZNK/k91j6e0SU1u42l6S00EBDmHuqaoslZ2q I31M6pmpAjXuVlcFOW+MXAmKuk8fjyeNcCfcB69xzT8Jpj3TPCK65IeIBEpkxEnTP9xi pwPCh9vQpFf69h8v8S+OUiVNW+TQgLip/jO4p7Pd3B1B4GIA64LFVtc1bxcsv4ZEAL/F q80Odb2DiGfNZvhiPlItsVWtQpfiL7WypMLETAEMVF+Mo58Hd1Krp+5j+wNlr1lGdIYa WiFw==
X-Gm-Message-State: APjAAAVmXEXh3j+/tNGV27eEtT1iJ7nERPpO4Ahvhw83l1ulsTEn2cag te4eTQdT208p4ZVcBpLscwFQHeCwfMm2kVnmMmbJCA==
X-Google-Smtp-Source: APXvYqy1cx2zRyB/0Qd3jHtQDf3ig42Ax7u+ZwKkTBB6pu4AN8ud/IqIQIsb0dHKxt0X66ttV7g1vkrzqQzLaMbs+3Q=
X-Received: by 2002:aca:5691:: with SMTP id k139mr3581981oib.54.1571905075773; Thu, 24 Oct 2019 01:17:55 -0700 (PDT)
MIME-Version: 1.0
References: <m1iNIFE-0000IwC@stereo.hq.phicoh.net> <d1b6855d-bde9-7b53-4809-0846bb9772e4@si6networks.com>
In-Reply-To: <d1b6855d-bde9-7b53-4809-0846bb9772e4@si6networks.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 24 Oct 2019 19:17:45 +1100
Message-ID: <CAO42Z2x7vudujw5t++obry56g=VNjQXXTHFK8pBPk0jmk78Bcg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a986d80595a3ab57"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/rs2AYVUA8HrwiqXxyFCfX3zXdJI>
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 08:17:59 -0000

On Thu, 24 Oct 2019, 03:08 Fernando Gont, <fgont@si6networks.com>; wrote:

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



Actually it doesn't, according to SA selection in RFC 6724.

It's easy to think that, which is why I have in the past.

I've even thought about proposing it, however when you think about it, you
realise there are cases where it wouldn't work. The largest preferred
lifetime address isn't always the best SA to use.

For example, say you wanted to renumber a network. At the same time, you
want to have a lower preferred and valid lifetime for the new prefix
(perhaps it was set too high when the network was built). Yet the as the
old addresses still have larger preferred lifetimes, they would be
preferred.

What you're really trying to choose is the newest addresses learned by the
host. Preferred lifetime doesn't really always tell you that.

I thought about this in the exact context of the scenario of this draft.
Although the design of the broadband deployment I worked on always planned
to give out stable prefixes, I worked through this scenario and realised
that so many complex issues disappear if you provide stable prefixes.

Fundamentally, if an ISP is selling an always on link to the same location,
then the addressing should be as permanent as the link delivery location is.



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
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>