Re: [v6ops] Flash renumbering

As far as flash renumbering per RIPE-690 below question.

https://www.internetsociety.org/blog/2017/10/ipv6-prefix-assignment-bcop-published-ripe-690/

Are the renumbering events occurring due to smaller allocations less than
/56, and as long as /56 or larger is doled our for privacy that limits the
frequency of renumbering events?

RIPE-690 outlines best current operational practices for the assignment of
IPv6 prefixes (i.e. a block of IPv6 addresses) for end-users, as making
wrong choices when designing an IPv6 network will eventually have negative
implications for deployment and require further effort such as renumbering
when the network is already in operation. In particular, assigning IPv6
prefixes longer than /56 to residential customers is strongly discouraged,
with /48 recommended for business customers. This will allow plenty of
space for future expansion and sub-netting without the need for
renumbering, whilst persistent prefixes (i.e. static) should be highly
preferred for simplicity, stability and cost reasons.

The target audience of RIPE-690 is technical staff working in ISPs and
other network operators who currently provide or intend to provide IPv6
services to residential or business end-users. Up until now, there have
been no clear recommendations on how to assign IPv6 prefixes to customers,
and a variety of different and sometimes problematic solutions have been
implemented.

On Fri, Sep 18, 2020 at 11:21 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> I browsed through the PD RFC and was wondering instead of changing the VL
> PL timers and other changes on the SLAAC side, could the PD default timers
> be changed to short VL PL.
>
> I think the problem is their is not any glue logic between PD and SLAAC
> communication so the renumbering event does not update SLAAC.
>
> So as I suggested even if PD had short VL PL that would not help at all
> per what I stated.
>
> Is their a way to build some signaling between PD WAN broadband  and the
> SLAAC interfaces so the renumbering event is automatically propagated
> downstream.
>
> https://tools.ietf.org/html/rfc3633#page-9
>
>
> On Fri, Sep 18, 2020 at 10:39 PM Ted Lemon <mellon@fugue.com> wrote:
>
>> It’s possible, but isn’t always done, and doesn’t address the problem of
>> topology changes.
>>
>> On Sep 18, 2020, at 22:30, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>>
>> 
>>
>>
>> The whole issue with flash renumbering is related to PD.  Instead of
>> changing SLAAC to react better to flash renumbering event could we just
>> make PD sticky so it keeps your last prefix doled out similar to DHCPv4
>> where you get your last leased prefix.
>>
>> Is that possible?
>>
>> On Fri, Sep 18, 2020 at 10:13 PM Brian E Carpenter <
>> brian.e.carpenter@gmail.com> wrote:
>>
>>> On 19-Sep-20 09:21, Ole Troan wrote:
>>>
>>> >
>>>
>>> >
>>>
>>> >> On 18 Sep 2020, at 22:57, Brian E Carpenter <
>>> brian.e.carpenter@gmail.com> wrote:
>>>
>>> >>
>>>
>>> >> On 19-Sep-20 05:11, Gyan Mishra wrote:
>>>
>>> >>>
>>>
>>> >>> All
>>>
>>> >>>
>>>
>>> >>> I really still feel this use case being Broadband provider PD
>>> related stale prefix issue  is really a corner case for SOHO users
>>>
>>> >>
>>>
>>> >> Why is that a "corner case"? We can count SOHO networks by the
>>> hundreds of millions, compared with enterprise networks in millions. They
>>> both matter, but SOHOs are about two orders of magnitude greater in number.
>>>
>>> >
>>>
>>> > Corner case because Service Providers generally do not flash renumber
>>> their customers.
>>>
>>>
>>>
>>> Can you put a percentage on that? Where I live, they do, whenever
>>> there's a glitch on the local loop, even if the local loop is made of glass.
>>>
>>>
>>>
>>>     Brian
>>>
>>>
>>>
>>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD