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

Erik Kline <ek@loon.co> Thu, 21 February 2019 01:12 UTC

Return-Path: <ek@google.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 9454E130FEA for <ipv6@ietfa.amsl.com>; Wed, 20 Feb 2019 17:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.498
X-Spam-Level:
X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.co
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 oGhJdNthwP3l for <ipv6@ietfa.amsl.com>; Wed, 20 Feb 2019 17:12:16 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 D3191130F0E for <6man@ietf.org>; Wed, 20 Feb 2019 17:12:15 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id y13so98188iop.11 for <6man@ietf.org>; Wed, 20 Feb 2019 17:12:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.co; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=p8CnfzeiY0T/0xXOFamyrpVAl9hPS+c3FTdjjJ2vXDE=; b=HEemp2ILpjZdCBgH0WIvZKzCk/AkxxD7Vx0w0+EOL74Ne8pMdfS6qNg/UTcfVZwej8 wCi5BXZpcGix9K9ru4Guy0yHN1BO2rjzPp4l6V5AMS8S3+/+X8BZRXHaOCYxwjN2f7t5 vqUE8/y1T75i0COxrPwkYGuYx8AHFTOjpEaKk=
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:reply-to :from:date:message-id:subject:to:cc; bh=p8CnfzeiY0T/0xXOFamyrpVAl9hPS+c3FTdjjJ2vXDE=; b=meV10uMkHYXiLJWH2xTly31eyZawT8DQPLaSyItSRtuP9q7wFRBo91wp+m6WQfKkdc yq4W2T+pjJZGu5YwcZ+C0bTywaDFDoUHEIrJq+8WfLr1ad9Q99p/Sqdz+lG1RpMdf00u 9Am1HZmAodLIaoPglnYgHLajWNlXDS8ZnJOl4W0+AgvKU+BF1F2VXObjqeBZpHaBZSAc +VqhUtodlpZtmiPT/2DV3v1rjaoaX9UyiSTf4VuQ1Cu3Vidf1y9z435bf6mPhX+jWeb3 0J09yoi1XlyLDyDWUT6lkTH+cSSh6qRpsXbXjxQ6vLvqxXpcY1YCA+FmDPoGq1kwvrjj D55A==
X-Gm-Message-State: AHQUAuaBU2S3IIaojHL4/GnBaTpUq64zyMNTxMyMq9s4ZN7SLPDlnR5w F4eqm9loHimRM3UYwSZ7eLBlP852m0cjXpaBhDBwaA==
X-Google-Smtp-Source: AHgI3IZ5arPg2Gv9ULz8yMpBiZgbJnWwQhGKcYAALwDTVb3reaprDeLmgL3enrtLTR55k3y/mj6FDuOKz3CAtGADHH0=
X-Received: by 2002:a6b:5913:: with SMTP id n19mr23543202iob.62.1550711534277; Wed, 20 Feb 2019 17:12:14 -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> <CAFU7BAQfg712UfgW9wi9pd3eVeZP9cqJEXd6=FDmchuSdauv+g@mail.gmail.com> <82c00442-bbc4-581b-2054-2d02d50d20ad@si6networks.com> <CAFU7BASDgmSwY=SLiabSqyiTOphxU0COtFLQvT8drm0iTxM+-Q@mail.gmail.com> <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com>
In-Reply-To: <76c488e0-5be7-3b81-d4c3-7af826f0dbef@si6networks.com>
Reply-To: ek@loon.co
From: Erik Kline <ek@loon.co>
Date: Wed, 20 Feb 2019 17:12:01 -0800
Message-ID: <CAAedzxq5d0fgOq5KZu7aCL9wxoDij6C-1Ad9+nQbYyhu2aMt-Q@mail.gmail.com>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: Fernando Gont <fgont@si6networks.com>
Cc: Jen Linkova <furry13@gmail.com>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000026c34705825d2a79"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vSbX2T_xG7aXU4zMVI3Vs069MAw>
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: Thu, 21 Feb 2019 01:12:24 -0000

On Wed, 20 Feb 2019 at 17:07, Fernando Gont <fgont@si6networks.com> wrote:

> On 20/2/19 06:36, Jen Linkova wrote:
> [...]
> >> Example:
> >>
> >> Say you have two network interfaces: If1 and If2.
> >> Say If1, is configured with 2001:db8:1::/64, and If2 with
> 2001:db8:2::/64
> >>
> >> Say the first default router is that associated with If1.
> >>
> >> Say prefix 2001:db8:1::/64 stops being announced, or that you stop
> >> receiving RAs on If1, but RAs on If2 keep arriving fine.
> >>
> >> Based on the logic of your algorithm, one would expect that a new
> >> connection uses 2001:db8:2::/64/If2 (since that's the "more recently
> >> advertised information). However, Rule #5 would override that and make
> >> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes addresses on
> >> the outgoing interface.
> >
> > I'm even more confused now, sorry ;((
>
> I was referring to the fact that some of the previous rules might
> prevent the evaluation of the rule about freshness. e.g.:
>
> * You have two network interfaces eth0 and eth1 (say each connected to a
> different ISP)
> * eth0 has stopped receiving RAs
> * eth1 receives RAs as usual (hence all info associated with this
>   interface is "fresher" than than corresponding to eth0)
> * The default router employed by eth0 has precedence (whether because it
>   had a higher preference value, because it was the first one that was
>   learned, or whatever)
> * When you evaluate the rules in RFC6724, rule 5 will say that the
>   outgoing interface will be eth0, and thus you should pick an address
>   associated with it --- however, as noted above, the addresses on eth1
>   are fresher than those from eth1.
>

Not receiving multicast RAs is not a condition you can really take any
action on.

PIO/RIO/default route/... timers expiring? Of course.

ND is_router goes from 1 to 0? Absolutely.

NUD says the router is gone? Most definitely.

Some kind of repeatedly beating on the router with unicast RSes... maybe...

Other cases might be if an interface has a stale ULA address one one
> interface, and a fresh one on another. You might end up using the stale
> ULA becase the rules about scope and "use addresses from the outgoing
> interface" take precedence over the rule about freshness.
>
> I do agree that these might be considered corner cases which might be
> unimportant for scenarios where we only deal with GUAs, or at least only
> GUAs become stale.
>
>
> Note (that I forgot to mention in a previous email): Many
> implementations limit the number of prefixes they may use for address
> configuration. I seem to recall that some implementations limit them to
> 16. If you don't do "garbage collection" for the stale addresses (remove
> stale addresses when there's some sort of indication that they are
> stale), then you might end up in a scenario where stale addresses take
> all the available "slots" for address configuration, and you don't have
> room for configuring addresses for the fresh prefixes. With the default
> Valid Lifetimes of 1 month, this is certainly a concern: if the prefix
> changes 16 times in a month, without explicit signaling to remove the
> stale addresses, you might be unable to configure addresses for the
> fresh prefixes.
>
> 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
>