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

Richard Patterson <richard@helix.net.nz> Tue, 26 February 2019 11:17 UTC

Return-Path: <richard@helix.net.nz>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD02130ED0 for <ipv6@ietfa.amsl.com>; Tue, 26 Feb 2019 03:17:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.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 CVJgEYYHyKsF for <ipv6@ietfa.amsl.com>; Tue, 26 Feb 2019 03:17:08 -0800 (PST)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 C269C130EC9 for <6man@ietf.org>; Tue, 26 Feb 2019 03:17:07 -0800 (PST)
Received: by mail-yb1-xb30.google.com with SMTP id f196so5116889yba.5 for <6man@ietf.org>; Tue, 26 Feb 2019 03:17:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xmc9TKxRPu/Kvh7oFT5ua4EDFmZ+hB+TkmnK/DfgH2c=; b=nLAiCpPJDLrtDpBFih+CuH+pqvgGBWq6rqyIK0LF89Ocor74qAQNOsA/vLExfBDZHn ZGMw5eUFJ5Pmg6d5JXfGjYQYfA7VTfAmS9INY2LklNbafthiVbnnoMWYG7xVT2WHXUCI McjcllIo8unsceBPaJYRiQWdCwNqQDvC6xL6ZIfIFYLZsRoOXwEp+k1UCjsVNiF2rn6n p0vdtC+YWfTsVaqdQ2v8h5y3hiSpu1ozLDYLhN0NxtxQ4oi8VoQaJUg0Q66VGFWMaQXv X6Qc24qfSLWjbyliUSSZHKti09U36GO6tz+NWm41zEHKN+Q+bKFxg0k5S/EANs0nic4I f/DQ==
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=Xmc9TKxRPu/Kvh7oFT5ua4EDFmZ+hB+TkmnK/DfgH2c=; b=IyWJuKSqt9ZSHCL6qqGciiZxOCycj+Bvvm+h4ZwugTkIMssKkXCz8dOV+R1tJ90S+H lUpaYeVnocG5/1jK8GP2s2dnfhNkLMUr7h85q1CJCn490Dch5YuXhWn/kwxycfDYsz+K zfhd5BcDikrEghdpgWsd9Wkb0wiYEv7o4CbybkzXjKYH7vdepMJto3My7Mv2CLk6RIJj V8zJdqrSzvPZ+XrpSBuKnRliSlZCmYP6FnVHfM8bSYpbknogEkLiWtOPect/inw/Ijgc xbrxNCg6oR23+l+HF0Wq2s6Xs7BNmzK3Iq79av/YrBg0HT9S8Z2Pl9ThRfOn70V/ogV+ xfSQ==
X-Gm-Message-State: AHQUAuaylmn2lI8DCPv/09oRRIMo/w/lCFsoygLavHcd+/Sb+Jzbs/pH lgkwfif5intlDv9gl+S2cYmKng==
X-Google-Smtp-Source: AHgI3IZDXQwURok971vycraWblZJZJmEW2daaC6Wp8GGxw2roZGn39DQFXtVJkE6cF4V5H0nkDVBQg==
X-Received: by 2002:a25:ad53:: with SMTP id l19mr11676621ybe.1.1551179826410; Tue, 26 Feb 2019 03:17:06 -0800 (PST)
Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com. [209.85.219.180]) by smtp.gmail.com with ESMTPSA id l203sm3984894ywe.3.2019.02.26.03.17.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 03:17:05 -0800 (PST)
Received: by mail-yb1-f180.google.com with SMTP id 66so5093300ybo.13; Tue, 26 Feb 2019 03:17:05 -0800 (PST)
X-Received: by 2002:a25:e686:: with SMTP id d128mr8082620ybh.193.1551179824889; Tue, 26 Feb 2019 03:17:04 -0800 (PST)
MIME-Version: 1.0
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> <CAHL_VyAs2b5pNcrJJRV_ppthLoVN4+X4Axzte0QRxJ3s-bkNHw@mail.gmail.com> <781412ce-0627-0751-a4e2-bb9b5e485802@si6networks.com>
In-Reply-To: <781412ce-0627-0751-a4e2-bb9b5e485802@si6networks.com>
From: Richard Patterson <richard@helix.net.nz>
Date: Tue, 26 Feb 2019 11:16:52 +0000
X-Gmail-Original-Message-ID: <CAHL_VyCLdgWNkwfnn7Lhgb7vUSnN0bf1670zg9oKGz+jF1xT8w@mail.gmail.com>
Message-ID: <CAHL_VyCLdgWNkwfnn7Lhgb7vUSnN0bf1670zg9oKGz+jF1xT8w@mail.gmail.com>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: Fernando Gont <fernando@gont.com.ar>
Cc: IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QFfU2WcOdEvscDzIUFX1pGLe5SM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2019 11:17:09 -0000

On Tue, 26 Feb 2019 at 10:59, Fernando Gont <fgont@si6networks.com> wrote:

> >  If not, would an update to 6724 that introduces a Preferred Lifetime
> > comparison as a tie-breaker help?  i.e. When deciding between multiple
> > non-deprecated source addresses, always pick the address with the
> > highest Preferred Lifetime?
>
> Not really. If you were to follow that road, then fore each
> prefix/router you should keep a new "Last Advertised" timer and use that
> as a tie breaker.  Using the Preferred Lifetime would not be safe since,
> while there are default values, you don't really know what values the
> CPE will use for them.

I don't think that or anything else is required to change on the CPE
router.  The onus is on the end host to track the Preferred Lifetime
counter (it already does), and to adjust its source address selection.
  It doesn't really matter what the default values are, as long as the
CPE router continues to send out RAs with that PIO to keep the timer
refreshed.

Although what I do think might be an issue is in a multi-homed
environment, an end host might flip flop outgoing connections between
prefixes depending on which PIO was refreshed last.