Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Mark Smith <> Sun, 27 October 2019 07:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1248E120111 for <>; Sun, 27 Oct 2019 00:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Status: No, score=-0.497 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, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qJI-n2n_uZq8 for <>; Sun, 27 Oct 2019 00:58:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 398A3120110 for <>; Sun, 27 Oct 2019 00:58:23 -0700 (PDT)
Received: by with SMTP id 53so4817385otv.4 for <>; Sun, 27 Oct 2019 00:58:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=H/9smu29jBk/29gHq3vlVmqKNy4t5k1ioIOR1UjU25A=; b=B7VDNvKnNgT7SkRjlBQ0z23p1n5vSZurxqJMxIQ7o8EVJO/YfXLjeCBmZcjEGKCIpN jf0Rh/KW3/yahIha9uqBo5UZK0o2DR+NyrN6E2YHc40w03eqrywZS1Au3ajjKc96G8aq 17Db3yBuRKsOP4HAZALNwn5g2qg6OBVEO2MCzs61mutDIaBA3ZTjDYAywjbAPwrOzRA1 NSw3/IBOw2Nn+KO1pfgz87h0xUBcDWrkTqX5WeDrS9kBNHedFtwZnc6BV0GLFFsPJPL9 ffrq5jDW+vFUnkhvMN824pixhLBGry6CRziw/DCbR/in31UDpP7ld+HiCOgSqHrkGtQB Rv4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=H/9smu29jBk/29gHq3vlVmqKNy4t5k1ioIOR1UjU25A=; b=bi/t5+EUH60ZmhqDnqca21iQrd72ZWyh6CEmoeoyK92k8OBXIV/d2VRaiLrvVMxhSL RyppH+xs64Q1Vt7ZrTwScVctKjfLOTvnf74lLGxjaC5yAMgkxA3dyGxP1ZNaHDCu/pp4 ilxHIu9e39GmtK5m9S3CMdLmGMeUw3sa3LLXTyVWEFYhvHFNTkNrc4Wd4kdiSvgGQHOV 18yDB8MjROnrDodJGdpaRA+lh0D+JAoEPg9W8tKAVOs9lEFvaHLpzZ9nHOHtzPa2DYik WfKJ7lyDUunslNhwjx06rijwOQeFy3BrpLy+AY5ZuBa0CP8rx7gcHtceQ30J4QsOX2pj 3QqQ==
X-Gm-Message-State: APjAAAWQvhj8Dpeyg2PMOGO9k6bvkumScKuS2x9vYVLTvNBmzFt0gcU0 wZzboSXayr0PzP6GUZd/eb51UXTJ59hH75/GpFLexGey
X-Google-Smtp-Source: APXvYqw570v2RKdOcEoNpd4mla4/M8La16MH2B+0tbUfT+Odpb+/tQr/6I/sxxX+Fn6LOhjW47QVAtQQSAoaSvzfE0g=
X-Received: by 2002:a05:6830:43:: with SMTP id d3mr9707329otp.153.1572163102376; Sun, 27 Oct 2019 00:58:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Sun, 27 Oct 2019 18:57:55 +1100
Message-ID: <>
To: Owen DeLong <>
Cc: Fernando Gont <>, v6ops list <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 27 Oct 2019 07:58:25 -0000

So in summary, the proposal is to update RFCs, change 100s of millions
of CPE implementations, and billions of IPv6 host implementations, to
accommodate some ISPs who want to cling to an obsolete dynamic and
dial up origin address provisioning model for always on Internet

Robustness is useful, however there needs to be a determined threshold
where, beyond that, the cost of adding robustness exceeds the cost of
properly fixing the problem that created the need for additional
robustness in the first place.

Making all CPE and all IPv6 hosts more robust to work around a problem
caused by some ISPs' address provisioning systems and models is going
to be far more expensive and incur costs on everybody (IETF, CPE
vendors and host vendors, and their customers who indirectly pay CPE
and host implementation costs), compared to those ISPs accepting that
IPv6 customers require persistent prefixes and paying the costs of
making changes to their own address provisioning systems.

On Sun, 27 Oct 2019, 15:48 Owen DeLong, <> wrote:
> It is worth noting that these values are tunable by the administrator
> and the
> RFC suggested defaults should never be a hard-coded value.
> With the following exception, I don’t advocate modifying this on the client
> side:
> +Section 5.5.3 of RFC4862 should be amended to specifically
> allow the immediate deprecation of a prefix by sending a valid
> lifetime of 0 seconds. Hosts should be required to honor
> this as a signal that the prefix is no longer valid.
> Could you please elaborate on this one?
> I’m not sure what I could do to elaborate. The addition of a specific call-out that
> even if the current behavior of ≤2 hours = 2 hours is to be preserved, there should
> be a special case for “0 seconds” which causes the prefix to be immediately
> deprecated with extreme prejudice.
> Hosts should be required to treat an RA containing a prefix with a 0 second
> valid lifetime as an invalid prefix and immediately deprecate it from the interface
> if it is in use.
> I do think that generally speaking, your proposed modifications to CPE and
> router behavior should be standardized and implemented.
> A better mitigation is to affect the preferred and possibly the valid
> lifetimes in response to consecutive RAs from the same router that lack
> the original (stale) prefix. e.g., after two consecutive RAs that do not
> contain the existing prefix, reduce the preferred lifetime. After two
> additional RAs, reduce the valid lifetime.
> In the crash scenarios you describe, you’re assuming a single router on
> the network or
> at least only one router announcing the prefix(es) in question with no
> persistent
> memory of the prefixes it was announcing across a reboot. In such a
> scenario,
> it seems to me that the following are also likely valid assumptions:
> +The network has significant excess bandwidth compared to demand.
> +The small overhead of frequent RAs and short lifetimes is probably
> an acceptable tradeoff in this environment.
> However, there are lots of other scenarios in the world where those
> assumptions
> won’t hold true and we should not seek to solve this problem (which is
> generally
> applicable to residential and SMB environments) at the expense of all of
> those
> other professionally administered environments.
> Even with the default RA frequency, if you were to unprefer a prefix
> upon, say, second RA that doesn't advertise it, and say, remove the
> prefix after many other RAs are received, that would be a *big*
> improvement to what we have now.
> I don’t like this idea because I can think of some scenarios where you
> may receive multiple RAs from router A not containing the prefix in the
> same time frame that router B has not sent an additional RA containing
> the prefix, but it will do so in its next RA.
> There is no requirement for all routers on the same link to provide the
> same set of PIOs, nor are they required to use the same advertisement
> timers.
> I agree that it’s a bit of a corner case and it’s certainly not an ideal way
> to configure a network, but it is not entirely unlikely to happen in the
> real world, it is within the current RFCs, it is valid functionality and it
> is not broken by the expected behaviors today.
> In section 3.2.1, you advocate setting the A and L bits to their
> previous values
> for prefixes which are being deprecated. IMHO, this is incorrect and the
> announcements calling for immediate deprecation should also indicate that
> the prefix should no longer be auto-configured and should no longer be
> considered on-link.
> Not sure I follow. Could you please elaborate?
> Sure… In section 3.2.1 of your document, you advocate that if the previously
> valid PIOs were set A=1 and/or L=1, then those values of the A and L bits
> should be preserved in the RAs sent to deprecate them.
> My argument is that since you are attempting to make this a prefix that hosts
> will no longer autoconfigure (A) and will no longer consider on-link (L), that
> in reality, regardless of the previous state of the A and L bits in the RAs
> announcing the prefix in a valid PIO, the new RAs since the prefix has been
> deprecated should be sent with A=0, L=0 in order to signal the host
> that this prefix should not be auto configured and should no longer be
> considered on-link.
> Is there some unfortunate widely deployed behavior that interacts poorly
> with setting A and L to 0 for these previously valid prefixes?
> Finally, An editorial note… In Section 3, you state “Finally, Section
> 2.5 analyzes…”
> I believe this is intended to be a reference to section 3.2.2.
> Nope. Section 3.2.2 talks about the interaction between dhcpv6-pd and
> slaac. BUt it is section 2.5 that discusses other considerations for
> dynamic/stable prefixes. For example, stable prefixes are not nice for
> privacy.
> Fair enough, but in that case, I don’t think I would put it after the description of section 3.2,
> nor would I use the word “Finally” as a lead-in to a back-reference.
> Owen
> _______________________________________________
> v6ops mailing list