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

[Clark Gaylord <[e-mail]>]

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

Renumbering is not "common" but it certainly happens. 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.

--
Clark Gaylord
[e-mail]
... autocorrect may have improved this message ...

On Fri, Oct 25, 2019, 09:17 Mark Smith <[e-mail]> wrote:

> On Fri, 25 Oct 2019 at 19:37, Philip Homburg <[e-mail]>
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>