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

Mark Smith <markzzzsmith@gmail.com> Sat, 26 October 2019 00:41 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB442120026 for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 17:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dmMeO3tXzobc for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2019 17:41:19 -0700 (PDT)
Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (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 87E5C12004A for <v6ops@ietf.org>; Fri, 25 Oct 2019 17:41:19 -0700 (PDT)
Received: by mail-ot1-x343.google.com with SMTP id d8so3258379otc.7 for <v6ops@ietf.org>; Fri, 25 Oct 2019 17:41:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <m1iNIFE-0000IwC@stereo.hq.phicoh.net> <d1b6855d-bde9-7b53-4809-0846bb9772e4@si6networks.com> <CAO42Z2x7vudujw5t++obry56g=VNjQXXTHFK8pBPk0jmk78Bcg@mail.gmail.com> <CAJoHkZ8pTjszP0vw4BjX0HUhmPa6wJONzdy2JEm5iqAfBUvjRg@mail.gmail.com> <CAO42Z2wCYi4KWTEz1hUSPVr9+hu8GaHRkPuvQQ2P00knvnPaaQ@mail.gmail.com> <848BA3B3-36B4-4C42-86D0-88759BC45D5A@employees.org> <A61279DA-4678-4A10-9117-6CA227AE2FA5@cisco.com> <A90AD47E-00E2-4EAB-8BD8-142CC10A6B6F@employees.org> <m1iNv5U-0000KUC@stereo.hq.phicoh.net> <CAO42Z2xUa7n6uUz9gtiZyZR39KFhsQ8mLeiyQdyERGTcJcXWWA@mail.gmail.com> <CADzU5g77cvfZknAzSkkNTP5vT73MZnSdGuOJ4y0Uba8XMgiASA@mail.gmail.com>
In-Reply-To: <CADzU5g77cvfZknAzSkkNTP5vT73MZnSdGuOJ4y0Uba8XMgiASA@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 26 Oct 2019 11:41:07 +1100
Message-ID: <CAO42Z2xHYU3y455XsM5grvG0360b9RigCaN=L+cc27_oyxhq0w@mail.gmail.com>
To: Clark Gaylord <cgaylord@vt.edu>
Cc: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005a53980595c586ad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/OrVgYEX9OXf3rATACIvNUVL_MQI>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Oct 2019 00:41:22 -0000

On Sat, 26 Oct 2019, 00:25 Clark Gaylord, <cgaylord@vt.edu> 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
experience.



> 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
> cgaylord@vt.edu
> ... autocorrect may have improved this message ...
>
> On Fri, Oct 25, 2019, 09:17 Mark Smith <markzzzsmith@gmail.com> wrote:
>
>> On Fri, 25 Oct 2019 at 19:37, Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
>> 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@ietf.org
>> > https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>