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

Jen Linkova <furry13@gmail.com> Mon, 18 February 2019 20:17 UTC

Return-Path: <furry13@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 2634212D4EA; Mon, 18 Feb 2019 12:17:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 oPjPvtSTrrGI; Mon, 18 Feb 2019 12:17:24 -0800 (PST)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 4BDAE12426E; Mon, 18 Feb 2019 12:17:24 -0800 (PST)
Received: by mail-qk1-x72b.google.com with SMTP id y140so10718106qkb.9; Mon, 18 Feb 2019 12:17:24 -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=9kg45C7746bdFa44yU16mAAv+YDIOAg6BbXJ0qnnTXI=; b=hSPcTS3BR6/uy9EwNQUHkOvWAaX3CP9wVGjzm7OfN/heV4aDmWpsX3Gk7gXk7VTboT QrREYqOCCPtfLqp7sGL9HDM2bH6soTvSjKD5ukPAC1xcPdaJxIN2vuS7frYEzFDk7b5Y bWTN/4rEzHlX0Nfou6zEIvbi22AR32yB8UBtn+HdTKGWSjS37VR3T6I90MA2fcNm0yPK 1RTXmB3VeSPUqvXACHM9m1aR+PorkDpz09PI9eG+fm7ZEfzerfjBpx2Bp8fmQBEIJIy0 N7w0ttZUG+9frerx+JkyTS4xE38PTAHeQGdyktNYwIJxWdXeciLA17eRY1LUeVSFnkq9 kPTA==
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=9kg45C7746bdFa44yU16mAAv+YDIOAg6BbXJ0qnnTXI=; b=A2CH6kXt83WD5uzcA2v3DlkhpyWMkKkML/EiGRjwaDAG0CyYNAHlW3Ta0YUlPY5bLO ZgxpVdtkvteIOm/6XLK3eaPPAcuO8JJwaCGNdRWOGNffU4Dw/Jli7MZzSIZB9whB18oN tCb58WfJYmd4Et/scOo8onevsaAj1mnszmvCIozYOqIXTp8CkcSMse+Ehb8uQHipZ0Xc NTz6Kdi5PYbXAA6KMzlv5rwkmeNSvP1IpU5Iml51lvdcPbuRY17JKFNdm4chh8lffH5w 5btwagre/XIRAbGeBAkfx5TQ75tyjvthg/1TH7UTlFN+oUlqCRF/BjuOQTqz6uvGYdWY 0ssQ==
X-Gm-Message-State: AHQUAuZx2/E4sv9KtzyiS9VAR2f7EwSfNi7VWlLZRVn8O+4IG4F66bAD uIW2uQHkikwrqSk66pU9hxr32c8LgkBkbyeH5ayqxFOs
X-Google-Smtp-Source: AHgI3IalmwSbWyNTpxmyrZLsQZFJn6QO08QBLKPZZaLn/pkpoTwN0zicBk8DIrNmPreA9yd0ttdBJltnaM+m8QsAZUI=
X-Received: by 2002:a05:620a:1333:: with SMTP id p19mr16422644qkj.165.1550521042839; Mon, 18 Feb 2019 12:17:22 -0800 (PST)
MIME-Version: 1.0
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com>
In-Reply-To: <35adea8e-704a-76f2-857f-a83a9ad689ef@si6networks.com>
From: Jen Linkova <furry13@gmail.com>
Date: Tue, 19 Feb 2019 07:16:59 +1100
Message-ID: <CAFU7BAS1_veTu-ZXAF0MF4niJwz149nGipx3ep_6fh1bewOzgg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, 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/v6ops/SameLgZWrImKZWdxAQxHJRBWhO0>
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: Mon, 18 Feb 2019 20:17:26 -0000

On Thu, Jan 31, 2019 at 11:12 PM Fernando Gont <fgont@si6networks.com> wrote:
> > When the new prefix is received it'll most likely have a higher
> > preferred and valid lifetime, so hosts should use the new prefix just by
> > means of them preferring the higher preferred lifetime of that PIO. So
> > the problem is a bit less than you write in the draft.
>
> Nothing in the spec says preference is related to the "Preferred
> Lifetime" timer. i.e., an address is preferred, or it is not...

I tried to address this problem before (and there are more use cases
than just CPE reboot):
https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00

I might be biased here indeed but I think that using the "most
recently updated" (however we define that) address would be the
simpler solution than
deprecating the whole prefix (and both solution requires hosts to keep
the PIO <> advertising router mapping).

-- 
SY, Jen Linkova aka Furry