Re: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds))

[Tassos Chatzithomaoglou <[e-mail]>]

Mark Smith wrote on 12/11/19 02:33:
> On Tue, 12 Nov 2019 at 10:38, Fernando Gont <[e-mail]> wrote:
> <snip>
>
>
>>> I don't really understand what is so hard about all this.
>>>
>>> You either provide prefix stability using a client's DUID, or you can
>>> use RADIUS.
>> As noted elsewhere, we have an RFC for DUID radnomization ("dhcp
>> anynimity profile", iirc). Besides, it's also understandable the
>> possible expectation of a user to get a new prefix upon CPE reboot (due
>> to privacy considerations).
>>
> The trouble with this discussion is that it still hasn't defined the
> problem properly. Different people have different scenarios in mind,
> and then scenarios are sometimes changed to suit an argument.
>
> What are the specific design requirements?
>
> Is the fundamental goal a stable prefix or not?
>
> To suit commonly deployed transport layer protocols' requirements,
> address stability is needed so that connections can survive transient
> connectivity faults - which is what a CPE reboot is, or what a BRAS
> reboot is.
>
> On the other hand, the privacy argument says that an unstable prefix
> is optimal, with as unstable as possible the most optimal. Addresses
> used by transport layer protocols should only last as long as the
> transport layer protocol connection using the address and no longer -
> basically "Transient Addressing for Related Processes: Improved
> Firewalling by Using IPV6 and Multiple Addresses per Host" -
> https://www.cs.columbia.edu/~smb/papers/tarp/tarp.html
>
> Are we trying to address a fault situation, or an intentional,
> non-fault action to achieve some other goal (CPE reboot to acquire new
> prefix for privacy)?
>
> Is the "flash" renumber event a very rare event that an ISP does as a
> last resort during troubleshooting, despite them having infrastructure
> to support providing stable prefixes (i.e. RADIUS/DUID above)? Say
> occurring no more than once every 2 years, ideally no more than once
> every 5, and ideally never.
>
> Is the "flash" renumber event a reasonably rare event that coincides
> with an occasional BRAS/BNG reboot that causes customers to land on a
> different BRAS/BNG with a different PD pool, and the ISP hasn't gone
> to the effort of putting in stable prefix infrastructure? Say
> occurring no more than once every six months (that was my minimum up
> time expectation for a production BRAS/BNG).
>
> Is the "flash" renumber event a reasonably rare event triggered by a
> customer who wants a stable prefix for as long as they're comfortable
> with the privacy they have, and will actively trigger a prefix change
> when they consider they need to "reinitialise" their privacy with a
> different prefix? Say once every month or two.
>
> Is the "flash" renumber event a fairly common event because ISPs don't
> want to provide stable prefix infrastructure, because they've divided
> the their customers into two classes - "clients only" and a higher
> paying, typically SOHO/SME premium "full service" (client, and
> server/service if desired - i.e. peer) class. Say, once every week or
> two for "client only" residential customers.
>
> Until requirements are locked down, we can never know if you've
> achieved them or not, and the discussion goes in never ending circles
> - as it is.
>
> All of the above are impossible to achieve at once because there are
> unresolveable conflicts.
>
> For example, for an ISP that provides a stable prefix, how can they
> know that a CPE reboot is intentional to get a different prefix for
> privacy? It could also be because of a mains power failure, or a CPE
> reboot due to a bug.
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>

The subscriber should have the choice to decide and the technology should give the means to support his/her choices.
We're building a page inside our subscriber portal, where the subscriber chooses how frequently the LAN IPv6 assigned prefix should change.
Default is to change at every PPP reconnect, but the subscriber can choose specific periods (x weeks/months) or action (once at next reconnect).
SOHO/SME accounts do not have these options and have stable prefixes forever. Non-SOHO/SME accounts are not guaranteed to follow subscriber's choice due to network conditions.


--
Tassos