Re: A common problem with SLAAC in "renumbering" scenarios

Jen Linkova <furry13@gmail.com> Tue, 19 February 2019 07:56 UTC

Return-Path: <furry13@gmail.com>
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 945D2124B0C; Mon, 18 Feb 2019 23:56:27 -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 6yrjzhanS9YA; Mon, 18 Feb 2019 23:56:26 -0800 (PST)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 DE95A1276D0; Mon, 18 Feb 2019 23:56:25 -0800 (PST)
Received: by mail-qt1-x830.google.com with SMTP id v10so22129692qtp.8; Mon, 18 Feb 2019 23:56:25 -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=RrwmF7C94oj/FLZqM/rlaEwljHlbe+bRuLb8tUcnK1c=; b=UPGv2QUS9fi4DgOB+IJhXdGKCDMBK+6+hZK1anq+LGGTX+zyF8vYiD1ZI6xYjoPyz6 4O5Sfsr1Uyw8XRQC7bUv384l6vYtAl248z5LE2NfgSKPEb2aIlWRDxCI3CSPkWv6/+P7 EqG2OXD0OFAqzJqoqWLiO2zWY1ntNhC5v014mhRvLw+DD6/uGAsEHC7aONTzbOCvTNtJ yWPxLoYZBgvbcrPYnQW3VytrvDjQsk4KSs3MP8Uet5dmg4+b76ZZJmlmyoRIjdKfrBXI dgmJpVhTxqRTDVJ5m3OpZ/AzW6pSvc90D0vEocmANTewxDCPKUjLYBnCC4Fqe84eCamY ASQw==
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=RrwmF7C94oj/FLZqM/rlaEwljHlbe+bRuLb8tUcnK1c=; b=JTafMVP1t8mWX3L1k+wKEc/As6BSlT8sv8VxsryFp5qgeszZtbm5WmbLXVnmEV1fQJ nqXd9paWpmRI6lfz+D/ETzRemGCOhwfhwxA44YY8L0dno6N33O4Wvru0YAmboAOyqOhl kDUV+HXDlUWE/pnUiKbiARxiMO1u4JrPnsmnoOSbYorBBOgz2ci4kKmGxhHYx2LkAhKc 2GsFN8GllDSKZJMfZhxIBVMFf4DxhglSxTLzPlH+ToXXjO+Yb+CLi+iFaQx6bf5ckUN0 beRb2PW8qSnTxAjBomcPFgyrKemjha9locPrXlOqGFhLPorSMGSSo0EROO+yirIJKojJ UbPw==
X-Gm-Message-State: AHQUAuatjeRqFwD6328GgDiMApPxvdOTMrzgGdJrE0kBcv7q8XUdn7nV woa32ZrN4vQMHPnVGIV8BWpkqWCQS9Wj4a7oFjRC40OK
X-Google-Smtp-Source: AHgI3Ib4Sm12g+4JxPuNGDex9I1DHWHiHYG8QEWSfrXBYWnk9rk4Uf/DmBV3WEg2MSGone7iHnFWTlSmQcv4Oemic2w=
X-Received: by 2002:a0c:88ed:: with SMTP id 42mr19517378qvo.126.1550562984584; Mon, 18 Feb 2019 23:56:24 -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> <CAFU7BAS1_veTu-ZXAF0MF4niJwz149nGipx3ep_6fh1bewOzgg@mail.gmail.com> <d9503983-6524-a13a-2cb0-cdcb95f76ea6@si6networks.com>
In-Reply-To: <d9503983-6524-a13a-2cb0-cdcb95f76ea6@si6networks.com>
From: Jen Linkova <furry13@gmail.com>
Date: Tue, 19 Feb 2019 18:56:12 +1100
Message-ID: <CAFU7BAQfg712UfgW9wi9pd3eVeZP9cqJEXd6=FDmchuSdauv+g@mail.gmail.com>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
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/ipv6/uSrtmWmRizYUZSYCyT_lQ-RqNyE>
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, 19 Feb 2019 07:56:28 -0000

On Tue, Feb 19, 2019 at 10:41 AM Fernando Gont <fgont@si6networks.com> wrote:
> > 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).
>
> Say the Stale prefix is 2001:Db8:1::/64, for which you configured
> 2001:db8:1::1.
>
> Say that Prefix(2001:Db8:1::/64) has now become stale, and a new prefix
> 2001:db8:2::/64 is being announced, for which you have 2001:db8:2::1.
>
> Say you now need to send packets to 2001:db8:1::/64.
>
> You will use the new addresses (from 2001:db8:2::/64), but will send the
> packets assuming nodes are "on-link", instead of sending them to the
> default router.

True. I'm not convinced that this use case is worth solving by
introducing the complexity (and impact on other scenarios)  the draft
is suggesting

What I'm not a big fun of is assuming that absence of evidence is
actually evidence of absence. When a router stops advertising a prefix
it does not necessary mean
that hosts shall stop using the addresses. It does indeed in the
scenario the draft describes but the host can not know the
topology/scenario.
The proposed host changes would solve  one particular case (DHCPv6-PD
router crash/reboot) while multiprefix/multihomed networks.

Lets say there are two routers (R1 and R2) on the LAN.
R1 advertised 2001:db8:1::/64 and 2001:db8:3::/64
R2 advertised 2001:db8::2::/64 and 2001:db8:3::/64.

Hosts have addresses from 3 prefixes.
Now R2 stops advertising 2001:db8:3::/64.

There is no reason for hosts to deprecate addresses in 2001:db8:3::/64.
What's going to happen is every time an RA from R1 is received, hosts
would get preferred addresses in 2001:db8:3::/64 and every RA from R2
would deprecate them.

I do believe that the default preferred lifetime is a bit longer that
it should be (and I have to tweak it all the time). So maybe we shall
change that.

> Similarly, if you have multiple interfaces, Rule 5 might override your
> rule 8.

Sorry, I must be very slow today. Could you please elaborate on this
scenario?  I'm having difficulties figuring it out..
The draft is talking about deprecating prefixes on *another*
interface? I hope not..

Actually I've just realized that I could not find any clear definition
of what 'the same router' means. The same address installed as
'next-hop'?
The same combination of IPv6 address and L2 address?

-- 
SY, Jen Linkova aka Furry