[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))

[Mark Smith <[e-mail]>]

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.