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

[Fernando Gont <[e-mail]>]

On 11/11/19 21:33, Mark Smith wrote:
> 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?

It can't be a fundamental goal. It is not stated anywhere, and that ship
has sailed: over 30% of surveyed ISPs do dynamic prefixes. SO that ship
has sailed. Besides, as noted by numerous folks on-list, even when it's
not the goal, it can happen. And when it does happen, you should ba able
to handle it gracefully.



> 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.

Not really. IN a world where in the vast majority of cases a CPE does
NAT (in IPv4) or a stateful firewall, when the firewall reboots, you
loose state, and with it your ongoing connections.



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

Mostly a fault situation that, at times, may arise due to an intentional
action. (e.g. an ISP moving customers around, a user "fixing" their
network by reseting the CPE, etc.)



> 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.

You can't know. BUt if you handle it gracefully, it doesn't matter.




> 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.

May happen. And may also happen when a user just decides to "fix" his
network by rebooting the CPE.



[...]
> 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.

I don't think we need to enumerate every possible reason for which this
might happen. In fact, it would probably be impossible to do so.

For example, when you implement resiliency to packet loss or duplication
in TCP, you don't go around analyzing every possible reason for which
that might happen. As long as you have concrete indications that the
scenario is possible, you design mechanisms to mitigate the problems.




> 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.

I think you're trying to boil the ocean. This work is on resiliency to
flsh-renumbering. The scenario of an ISP trying to figure out whether
they should deliver the same or different prefix (by inferring what the
user wants) is a totally different problem.

I reiterate a previous question, that remains unanswered: is there in
cpe-slaac-renum that you think shouldn't be there anyway?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492