Re: Moving draft-gont-slaac-renum forward (fwd: New Version Notification for draft-gont-6man-slaac-renum-06.txt)

[Mark Smith <[e-mail]>]

On Thu, 16 Apr 2020, 21:58 Philip Homburg, <[e-mail]>
wrote:

> >
> https://www.ripe.net/publications/docs/ripe-690#5-2--why-non-persistent-assign
> >ments-are-considered-harmful
> >
> >That happened to some ISPs in the past and that was the main reason why
> >we documented it in RIPE-690 and consequently are trying to fix things
> here.
>
> What I recall from earlier discussions here (or in v6ops) is that some
> operators have operational reasons for changing prefixes.
>
> >From Section 5.3:
> "Finally, if you're unconvinced about the use of persistent prefixes,
> "you should at least consider using non-persistent but long-lived
> "assignments so the lease time is as long as your provisioning system
> "allows.
>
> This will still create problems when the prefix is changed.
>
> I.e. in my opion we should make hosts and CPEs robust against renumbering.
> In my experience, just about all renumbering is done wrong. Essentially
> nobody
> has the tools to record the old prefix, keep that working for a while and
> meanwhile introduce a new prefix.
>
> Plenty of operators have pools of prefixes and change the prefix of a
> customer when the customer is moved to a different pool. Are you aware of
> any documents that describe how to move a customer from one pool to another
> without flash renumbering?
>

The general renumbering procedure in RFC4291 would apply.



> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>