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

Mark Smith <> Sat, 26 October 2019 00:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB442120026 for <>; Fri, 25 Oct 2019 17:41:21 -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 dmMeO3tXzobc for <>; Fri, 25 Oct 2019 17:41:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87E5C12004A for <>; Fri, 25 Oct 2019 17:41:19 -0700 (PDT)
Received: by with SMTP id d8so3258379otc.7 for <>; Fri, 25 Oct 2019 17:41:19 -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=xzQt2B9LQBj71kVblyCuQZHoWHBG99i/Pg1OrxYzFi8=; b=rChqxn3fdVNRoCy6sVthSQnx5G8ixO85mLnfG4fLKeFiTzoj3W5uiGDI3OeaYXhJlo fzGbhU5RLfiD4uNpzkha35Rdngy3BQqg4tWZt/1lXGr3Cq39onPe5iQkazeUMamtKC9N c0IXgZuO9Pgvm8W5Imm2hSIlF709reAnI/h1FqxpbrWrO049rdDFAnRTVEIle/84gIE9 xYDIxMWdw/clnEnO7hg9HsU8Jb1BO/+ju8nXvGBsPV3acqmcCxBgmngEg3amZ9TG7nM/ jWIY5cu8q/6qv7xKvA+YmBl+Y4uPDRH55fqmdDAiEtC1X61HeqzmfcGjJGnVhf392Lvv rxSg==
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=xzQt2B9LQBj71kVblyCuQZHoWHBG99i/Pg1OrxYzFi8=; b=VpNa8hSQR4ovmMdKnzEXNe2nYIIFVkj6S7xdxoyY40l0x1EVmLSjRGa5I4NCOqPTEY JgFX2hyWhuMH95Q4i8byHh9MNQpAI/LvlR0Efdx2saEhD8Z0brYT5pF3nNtKfW85gJOp 2kPzb4V35ePHRoFbb3091PEQ1eBJ41m+IIXPLTtRxiX/a9SORD+1UWpotcXxKUXmwNgO JcTQiJ1ffu6SHMBu1lyrNnxyJSQK/tLK84Sojh7Lc5nkIr21Gknm8QAkX6KGJxqEY9CB x8So84TRzxuxXbe/7txmrCizOu+vIJSC6aBzYDKsra3iqMU+6A77eaR9R8k1T1Zvqg8s dRKg==
X-Gm-Message-State: APjAAAVHVjI4VgFbcQWFVL6SdZzBJYtqExwiQTKBAqKu4KVk1vG/EdTx 8YHkUhqeupRnysq2ACrxiDbb757o0UvaGsiF+jI=
X-Google-Smtp-Source: APXvYqxhpciS2+pbO6FsSfGA4wC4RQWeZw9bUDgXQMYY7hAzVRQMW9BN8QroLPWFF1Wgz1BYmwPW4IfW/9d5roPevxM=
X-Received: by 2002:a9d:6c85:: with SMTP id c5mr4789698otr.257.1572050478712; Fri, 25 Oct 2019 17:41:18 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Sat, 26 Oct 2019 11:41:07 +1100
Message-ID: <>
To: Clark Gaylord <>
Cc: Philip Homburg <>, v6ops list <>
Content-Type: multipart/alternative; boundary="0000000000005a53980595c586ad"
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: Sat, 26 Oct 2019 00:41:22 -0000

On Sat, 26 Oct 2019, 00:25 Clark Gaylord, <> wrote:

> Note: that makes your sample size 2, not 240,000....

I think the volume of users is an indication of the likelihood of
encountering it, in the context of rapid broadband adoption at the time.

When I started at the smaller ISP in 2005, we had 6000 customers. When I
left in November of 2009, we had 80 000 customers.

During that time the network was also entirely rebuilt, including going
from 2 LNSes and a single BRAS to 2 new LNSes and 6 BRASes, on a new
network core with an entirely new routing architecture (i.e. BGP for
everything, OSPF carrying loopbacks and link addressing) . The rebuild
included unavoidable redistribution of routes back and forth between and
new network instances of BGP and OSPF (and the risk of BGP -> OSPF -> BGP).

So given the growth, and the complexity of what we had to do to deploy a
new network during that growth, while continuing to providing legacy
network connectivity, I think if flash renumbering was a common thing that
needed to be done, I think I should have encountered it often given my

> Renumbering is not "common" but it certainly happens.

I didn't say it didn't happen.

People imply it is a regular and routine event that then justifies a lot if
effort to work around its consequences to IPv6.

I don't agree, because I don't think it is a common and routine event, and
with the right address provisioning system and routing architecture,
customers don't get flash renumbered even when, e.g. a BRAS is rebooted.

With that said, "flash renumber" could reasonably be considered a "high
> support risk" operation.. IPv6 is supposed to accommodate renumbering
> *more* gracefully, not less, than legacy IP, but it is still supposed to be
> a planned event.

If you use IPv6's graceful renumbering mechanisms i.e. multi-addressing and
preferred and valid lifetimes, then it won't be flash renumbering.

> --
> Clark Gaylord
> ... autocorrect may have improved this message ...
> On Fri, Oct 25, 2019, 09:17 Mark Smith <> wrote:
>> On Fri, 25 Oct 2019 at 19:37, Philip Homburg <>
>> wrote:
>> >
>> <snip>
>> >
>> > Reality is that ISPs do flash renumbering for IPv4 customers.
>> Why?
>> Between 2005 and 2011, I worked for two residential ISPs, one state
>> based with 80 000 customers, and another national one, with 160 000
>> customers. In all that time, I never needed to or saw anybody
>> intentionally "flash renumber" as far as I can remember.
>> The only time I can see a need to purposefully "flash renumber" would
>> be if you want to shift around IP address pools across to different
>> BRASes. I don't think that is a common event. (The common event was
>> adding new IP addresses to existing per-BRAS pools, as customer
>> numbers grew.)
>> So I would like to hear from ISPs that purposely "flash renumber" why
>> they do so, and how often.
>> People are trying to continue to use the decades old dial up model.
>> That's understandable - "if it ain't broke, don't fix it". It could be
>> carried over from dial to residential broadband IPv4+NAT, because
>> there were enough similarities. The problem is that it is broken when
>> applied to IPv6.
>> You don't keep using old solutions and ideas when they start to cause
>> too many problems, and require too many work arounds to keep using
>> them. Too many problems caused by the old method and too many work
>> arounds to overcome them is a sign the old solution is really beyond
>> its useful life and a new solution is necessary.
>> >We can tell them
>> > that they cannot do that for IPv6, but that will result either in a
>> delay
>> > of IPv6 deployment, or they will find a hack (such as NAT66) to make it
>> 'work'.
>> >
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> >
>> >
>> _______________________________________________
>> v6ops mailing list