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

Mark Smith <markzzzsmith@gmail.com> Tue, 26 February 2019 11:09 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 24905130EC5; Tue, 26 Feb 2019 03:09:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 0AvY9PGSL9jE; Tue, 26 Feb 2019 03:09:20 -0800 (PST)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 5F2E8130DF1; Tue, 26 Feb 2019 03:09:20 -0800 (PST)
Received: by mail-ot1-x332.google.com with SMTP id i5so10703072oto.9; Tue, 26 Feb 2019 03:09:20 -0800 (PST)
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=z7mKdUUM2GqqSoiaEwQQDajOqoDwO4H19s4dGtb78I4=; b=DwpGvzPas2E37CExUkcUKLk2rWlNm5xzTe+AIDl17cCKVx2nUasD9eFzw4Wnq2AirK a0WVBHP9XJo/MYdoSPL+4FDoMYNrhbiX6+JFi2+Fi/7dZqv2KUcL/OcA+miItf0jLjyC zN9JeKgHvZwiC4LJcUqO7SPne1lXtFbbbl8Pb4la2etcreTdCyTNFsTno7Rm9ZBIY1ZW IC0/hvRDOFaN1SVAjWnNKmNgppwm2EfxAzBdYSvb9+OH2YSXNCHrCfIYjPxkZZzBkjYl ex08B62URzGbAJnwZ2iEMW19cjRMxHDFdgXMkA9IWwM9w0vKPa7rIagIIsEj7msoDFJi rc4Q==
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=z7mKdUUM2GqqSoiaEwQQDajOqoDwO4H19s4dGtb78I4=; b=mQd1ciaX9/GfN5v9SkeB9wDgogwcWtBEkTfe7/RH7o6qsc3LYHhZ4mpeDxFUiVRBKh EDhobdID7urPNpM6QV8WNxBmEBjENh5XMPBYCB/ukmWEMz5DzcvSkQeoMB3fFOu9qwEJ 9GSUDXM7OoJKjhcBweEkAscM8mTfQEkeFpj2dTibW89RGydZ9u7H1PFTY7t37sbe2xKD 99YUSSsPlbQWzv7hCsy7ovxO0H8NXQQEZav3P6m7EIXgy9qauqv/t7sdDZBJESJI+9y/ N5WE/Tvg6wDozBLSl5h9R64EEgxABGbMNsxCWYi43Ib3+5jxSt7jdCkVO7Y0sFElk6/b twpw==
X-Gm-Message-State: AHQUAuadW4nOIhM7NLgRdfQRGvHFiSbVLuNKmkH59qFpXpdm8mQJ1dLe +PbK6TdLQ7e40dZF45EHWFdYKpTFiWBJ67W/R74=
X-Google-Smtp-Source: AHgI3IYxRChmK3vxtF2U0bxHWkOtvbjZDQXFvncZTPgcuIGNUcUUDIHEblOQKkD593GrBJ6/uS8hwHc2dI0Ryl7QSCU=
X-Received: by 2002:a9d:6d98:: with SMTP id x24mr15108730otp.318.1551179359426; Tue, 26 Feb 2019 03:09:19 -0800 (PST)
MIME-Version: 1.0
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <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> <F4F90B88-3EED-4AF2-82FE-5F1023A05605@employees.org> <c3562b5b-0eec-636b-3bb1-1b0381109542@si6networks.com>
In-Reply-To: <c3562b5b-0eec-636b-3bb1-1b0381109542@si6networks.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 26 Feb 2019 22:09:07 +1100
Message-ID: <CAO42Z2y+poR1cHp=wxPDs6umu80uyN94r=bh+NOw2HdFQYZMNg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Ole Troan <otroan@employees.org>, v6ops list <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Content-Type: multipart/alternative; boundary="000000000000b39e8d0582ca168d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/taRvsPPbTBydRbU5SgOm1F-UUJY>
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 11:09:22 -0000

On Tue., 26 Feb. 2019, 22:00 Fernando Gont, <fgont@si6networks.com> wrote:

> On 26/2/19 07:13, Ole Troan wrote:
> > 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.
>
> I don't disagree with you.
>
>
> > In the DHCP PD case they should also be counted down in real time.
> > And the lifetimes can be dynamically adjusted.
>
> They should. However, quite frequently the DHCPv6-PD part is a different
> piece of software from the ra{d,dvd} part. Both pieces are glued by some
> script, and the lifetime is *not* dynamically adjusted.
>

There is a knob in 'radvd' to do and suit that, the PD triggered/driven
script just needs to do a bit of radvd.conf modification, stopping,
starting, and signalling.


*DecrementLifetimes* *on*|*off*

This option causes radvd to decrement the values of the preferred and valid
lifetimes for the prefix over time. The lifetimes are decremented by the
number of seconds since the last RA. If radvd receives a SIGUSR1 signal, it
will reset the values of the preferred and valid lifetimes back to the
initial values used by radvd when it started. If radvd never receives a
SIGUSR1 signal, it will continue to decrement the lifetimes until the
preferred lifetime reaches zero. After a final RA with a zero value
preferred lifetime, radvd will cease to announce the prefix. If a SIGUSR1
signal then causes the lifetimes to be reset, the prefix will then
re-appear in the RAs.

This option is intended to be used in conjunction with a DHCPv6 client that
is using the Identity Association for Prefix Delegation (IA_PD) option to
acquire a prefix from a Delegating Router for use by a Requesting Router.
In this scenario, the prefix(es) from within the delegated prefix that are
announced by radvd would age in parallel with and at the same rate as the
delegated prefix, and expire at approximately the same time, if the
delegated prefix's life isn't extended.

See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol
(DHCP) version 6".

Default: off


> Thanks,
> --
> 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
>