Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)

Mark Smith <> Fri, 08 November 2019 23:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89A5312011E for <>; Fri, 8 Nov 2019 15:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Status: No, score=-0.498 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=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 TnDbyVhWduGy for <>; Fri, 8 Nov 2019 15:41:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B79F120026 for <>; Fri, 8 Nov 2019 15:41:15 -0800 (PST)
Received: by with SMTP id t4so6709251otr.1 for <>; Fri, 08 Nov 2019 15:41:15 -0800 (PST)
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; bh=RLTX6EuzU+3o1tb8Ti5077iXD9q6WPbtrl906y7gJEI=; b=GV3sa9SLmVgx6PgfH/e9gegxwi/zK/pw1t+ErsVZmARWqDhtprPlLwTGfVWi3hA3XS 3xUfOiugMHk774rtYphnDQIlBoY8dsxGQ2k/ivL9MM0emAGLVeWdP0U4w0QmguGa5SuT AAIJ3baVdoUt8rG1i3wnC4qXcvNMY9ha03+Dn+xyRh6hBvuclGjNB/3sYGpTLjP3SvMg lfwbswaXKpu/Xi/4tURL6kAUqJPYRU7IbcpgFiLnRSbDAdt9OQgjculCq7MJKPdMwLIv 6pFAO1nnCLcQcK9XQ2ZnSZJ8u21ZMyrD/X+NzTRAg2FKdnpipRD1i8sQ980KYANfGYPr fL/g==
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; bh=RLTX6EuzU+3o1tb8Ti5077iXD9q6WPbtrl906y7gJEI=; b=HFIFQBuLqYgl+gbs7HGgbzK3E0nWuMMSDAU6O59OA3w1K9fIdCsVZ3hgPljn8oEB6n rm3RF9GACs6hfCTGnBkxP1Us3ZoF3gdnHU8Cc79X3WTIw5R8NkPhQQJ0VzVXcn7sMBnf mGzh95nnmRXJ3MgfGVCJOt6BkQ66gUG+q6ZLKQkMvYvraojlvMXhRjqdkBzyr3gvltdq jzrVhqj0y93R6xiv4puufG79pzOz5QGmf4s8BSVAj6/RPW7ndUxMBkKO1TXuJYtGIbwe 2dsuUXKw9Yo2thrQD8wDWl9W2ifhyJJ3d3QKG1pE8dCBp2LAkNq5PHe/30my8exkEdpc R2Ow==
X-Gm-Message-State: APjAAAUNNvxwWSXYBGTUjPaqLkBrobgaDT8I7iuwWb3UfJjY8eHWjTqv P5lTRdeMrfa2WXGhEMojvD2abq8Yt39CnJS7+brpaQ==
X-Google-Smtp-Source: APXvYqxp+5Zb4b6pkyqX81uGtuVUDRCf6bgEzGQeMAme80BYtap4BKxxfH4120aL3Fcfyb+RBaWYCRMfuAVNcgctGS4=
X-Received: by 2002:a9d:74d6:: with SMTP id a22mr11068481otl.153.1573256474659; Fri, 08 Nov 2019 15:41:14 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Sat, 9 Nov 2019 10:41:04 +1100
Message-ID: <>
To: Fernando Gont <>
Cc: Philip Homburg <>, v6ops list <>
Content-Type: multipart/alternative; boundary="000000000000500edb0596de51a7"
Archived-At: <>
Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: 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: Fri, 08 Nov 2019 23:41:18 -0000

On Sat, 9 Nov 2019, 09:15 Fernando Gont, <> wrote:

> On 8/11/19 18:50, Mark Smith wrote:
> > One of the best questions to often ask is "why?"
> >
> > On Sat, 9 Nov 2019, 01:20 Philip Homburg, <
> > <>> wrote:
> >
> >     > Probably there is no formal requirement for prefixes to be stable
> >     > across crashes and reboots[*], but there is a behaviour of the
> >     > client to send CONFIRM after reboot or wake-up from sleep, as
> >     > described in the RFC DHCPv6.
> >
> >     Sending a CONFIRM after a reboot requires that the client writes the
> >     lease to presistant storage.
> >
> >     As far as I know, there is no requirement for clients to have
> suitable
> >     persistent storage.
> >
> >     Of course, the big issue is: do we want to delay IPv6 by making IPv6
> >     deliberately incompatible with common IPv4 deploy strategies?
> >
> >
> > Why do you think that this "strategy" exists in IPv4 deployments?
> >
> > Why is it relevant and preferable today for IPv6?
> >
> > Why is it best for IPv6 when people get something different in IPv6 than
> > in IPv4 - public address space to use on their LAN.
> Asking "why" is nice. BUt as for many other uses of the question, it
> doesn't solve the problem.

It gets to the root of the problem, so you can determine where the problem
truly exists, and where to then prevent the problem.

The Five whys method suggests you need to ask "why" around 5 times to get
to the root cause of a problem.

Five whys

Prevention is better than cure or mitigation.

Mitigation is all that is being proposed here. As someone who has
implemented and had had distributed mitigations for this in 'radvd' (the
DecrementLifetimes and DeprecatePrefix options), they're not as effective
as preventing the problem where it actually exists.

Have a look at how horrible the problem gets and how ineffective these
mitigations are when someone has a routed network using the dynamic PD

Over 30% of IPv6 deployments do dynamic
> prefixes, and hence are prone to face this. That's the deployed reality.

Why are they doing it that way when it causes problems for their customers?
Why don't we know the answer to that question?

Why do we always have to try to solve technology problems with more
technology, when sometimes education about a different and better way to
solve the problem can be cheaper, quicker and more effective?

Why is "the ISP is always right" assumed?

Why aren't the IETF allowed to say to ISPs, "this is not the way this
protocol was designed to be deployed, the correct way is 'X'"?

> That aside, I reiterate this is *one of many* possible scenarios where
> this issue may be faced.

If it is common, why haven't we heard about it here in the IETF in any
other context other than ISPs doing dynamic PD prefixes?

> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492