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

Mark Smith <> Sun, 27 October 2019 22:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FA0F120046 for <>; Sun, 27 Oct 2019 15:37:31 -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, 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 X6DDq5uLJFiv for <>; Sun, 27 Oct 2019 15:37:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3EC7120044 for <>; Sun, 27 Oct 2019 15:37:29 -0700 (PDT)
Received: by with SMTP id b19so3173546otq.10 for <>; Sun, 27 Oct 2019 15:37:29 -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; bh=HVid2a9/R0bJ86udl5eip2u6Jjy1Xs67kUKrAe++vZY=; b=ZaTI84/EdAZ9n8o8EIKeedLAr3NFev21zwFX6C1TA9Bv6JIf6/gRs7/g1YKCoQidKW mImleFeqawBj2cuAXjNji0FE6N0WebY8nzz01XHP2QSmJaMltwfNGjAWjz4b0pT2kpXE neglmJPpQkWFpDSysug4rBWQEPjGJx1ouScjsVPBX2Nb59pLNri6DGuWtLsMNPJz8l5L t3dNTsgV1yf4C1TTKxrOFQG+3iox/PlJlvM/7WcGHzCvRieZoL7GihVDnK8uhM/hMHQu cduoLD5y6bLBrYywbJjXx7bJt0OSuOyNjnvvbYmGMniUgERxfYFklXvhzCb7PlrDLhzK CqrA==
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=HVid2a9/R0bJ86udl5eip2u6Jjy1Xs67kUKrAe++vZY=; b=MQzObQVnzCS3fkE9F/GQMCzPSGIbXurSh459EvgPBUta5qKNdyaxXx51cHbmWPMDws Bva8nVK7oMswbZDng9b6ZcgkhoYyfVjf+mCJqEJ5AWKi+NepVcPYLq6IPYHE+NQfTcoM 1G6sLWkkpmrczchIVZSD7LJThNEGiqw3HOZW5K+06vaGRMGAPqIKCtpyDVI2qfSthlEc HTEncpPQSlMquFJ5EuNKzpxevXg5NHKi2ZgVd40azFGuVD73HOOlJdXakQpusFRjiPs7 keiyAZWkEGzOR3quyllUl0en92tz4hNNToOzexfbaFKyBpDjxvsHhvpUWk2xUcqVr7gx KC6w==
X-Gm-Message-State: APjAAAUDEQ6unOBSUBBy3zBtumYeZG9sgMk832PERJHgJWDB+VHaq/sv Ys11Aog425w5VZD87qKQNgwV3d4SVc8sHiczlt4=
X-Google-Smtp-Source: APXvYqxzTemcGpIdlcgUYicDiGBxJw5pI+wRx+fqSUNga2v6bCyy7zrJ501NYh75pRj8y2ZLtBvIlZ9rG5qySlPo2bY=
X-Received: by 2002:a05:6830:43:: with SMTP id d3mr11946331otp.153.1572215848854; Sun, 27 Oct 2019 15:37:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Mon, 28 Oct 2019 09:37:01 +1100
Message-ID: <>
To: Brian E Carpenter <>
Cc: Fernando Gont <>, Owen DeLong <>, v6ops list <>
Content-Type: multipart/alternative; boundary="0000000000002e6bbf0595ec0777"
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 22:37:31 -0000

On Mon, 28 Oct 2019, 06:06 Brian E Carpenter, <>

> On 28-Oct-19 05:29, Fernando Gont wrote:
> ...
> > Robustness has a lot to do with being able to gracefully handle the case
> > when others screw up.

> This. We can't make the world perfect, but we can make individual
> components
> that expect imperfection.

This is not what I said, as it is implying that I said there is no need for

Robustness suffers from the law of diminishing returns. At some point the
cost to design and implement robustness exceeds the either the likelihood
it will be needed or the benefit it returns if needs to be used.

Sugar is sometimes poured into the fuel tanks of cars, which will destroy
the engine. It is not common and is done maliciously. If robustness should
be universal, does that mean car engines should be made impervious to
sugar, at great expense to everybody, despite the need for that robustness
being rare?

Some ISPs are shifting the cost and consequences of their design decision,
which they can change, onto the IETF, CPE vendors and host implementers,
and indirectly their customers'. Are they willing to pay these other
parties to fix a problem that they are both causing and could fix

(Can I bill these ISPs for the time I spent implementing the
'DeprecatePrefix' and 'DecrementLifetimes' options in 'radvd' in 2011 that
address this problem? Those options have limitations that I still don't
think are acceptable, which is why ISPs fixing their backend systems is
still the best solution.)

>     Brian