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

Mark Smith <> Fri, 25 October 2019 13:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 078F0120877 for <>; Fri, 25 Oct 2019 06:17:04 -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 aEBjzrwQlt8L for <>; Fri, 25 Oct 2019 06:17:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB58812086F for <>; Fri, 25 Oct 2019 06:17:02 -0700 (PDT)
Received: by with SMTP id v138so1608123oif.6 for <>; Fri, 25 Oct 2019 06:17:02 -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=k27MOwajP6+IwUTjulRcVYlcejhaSDtJCxA9BTov5s4=; b=e6YRt5MroknEUyD2Q2HAZ/G5zNIbJJRuFwKfwpI0GnvuaI6Ku2hN3HLwbc1/hHuWpt MvJMMGmZnB8kG6oEg5OFEsAYGIIYI//m4DHDBrz4eu6A6kqlcaoRdLXSNU8iQyrO1yr/ 7Dt8S+G0DXhDtMwQwl5Ll+1ueSn+QHBQH5wePK71qy1eWBt8lsdrhiqxDvlupgNIx4ud cJKhb10ONb/243vDkFvozbhCQ2qBHUzfW+Z8ivA00Xk/MnZfioEAKR1tIm3rswGXCRNe isgbJ0dGGM7bykQo+mlf4JLPoqwV2Z2pXgswv2jBCk9exFf8KfQidLErOHElpOOLUa50 Zj7Q==
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=k27MOwajP6+IwUTjulRcVYlcejhaSDtJCxA9BTov5s4=; b=POAnPDT9DvLrNvScXUGn1SL+NbCjAAM8L3B15/cV3m/Ti93UNLnhjDjDwes90Ew58v 3hhRjFo5B9EFEgz/w4JJwu+KYOFn4emUnwJRJ2Xe3OKsf/x28yKt++e9jQJoZvyyPpvO 5csMdwr/jWYQbvJ3OoPZGBvSks+j9Qw6caxpf61gU+rs67Z0E0HgmFWz+Z/DCrIcRkp3 PqP2ZerpPqxSbqKr3UeJJs/MuDoqG81on8nRhzk9Yb4jRJ+/okGhsvsTuX9xwd+WsRSt Bwodt/tKOBkrpRCP+tkpdyhpBNIoX4IDrpdZbuqEoZstry8gZ4aFyipNLZs6u4FJgOO0 B0dw==
X-Gm-Message-State: APjAAAVqYU4EFGHBEg/8+wejqld3WD619cqoSWZcs7w5a6vnCELEveYY XNDLo5iZO772GcEA0S9qlkOR+B095pEuEM7TeSNeFg==
X-Google-Smtp-Source: APXvYqzeFDbzJz+H+o8lDZBaXpERSs2WfKIg7r6teHjPta1RYCXxNlAQIX7RnX3pZP2AOl8fgdWE6aBHEjIGh7AoyZQ=
X-Received: by 2002:aca:db09:: with SMTP id s9mr3044178oig.7.1572009421818; Fri, 25 Oct 2019 06:17:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Sat, 26 Oct 2019 00:16:35 +1100
Message-ID: <>
To: Philip Homburg <>
Cc: v6ops list <>
Content-Type: text/plain; charset="UTF-8"
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: Fri, 25 Oct 2019 13:17:04 -0000

On Fri, 25 Oct 2019 at 19:37, Philip Homburg <> wrote:


> Reality is that ISPs do flash renumbering for IPv4 customers.


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