Re: A common problem with SLAAC in "renumbering" scenarios

[Nick Hilliard <[e-mail]>]

Mark Smith wrote on 14/02/2019 04:46:
> So to me, the cheapest and best solution is for the an ISP to provide
> a static/stable PD prefix to the customer (even though I've written
> code to try to mitigate it i.e. . DeprecatePrefix and
> DecrementLifetimes in radvd in the past.)

Mark,

Largely, I agree with your rationale on this.  The problem is that ISPs 
will be loath to commit to a stable prefix for the lifetime of a 
customer account.  This approach doesn't scale for larger providers 
because it commits them to making routing compromises for the lifetime 
of customer accounts, e.g. injecting dynamically assigned prefixes into 
their routing tables.  Accretion of configuration fossils causes long 
term complexity problems.

Stepping back though, connectivity loss due to stale PDs is caused not 
by failure of a single component, but by a cascade of failures and 
miscommunications between multiple discrete components;  the core 
problem is how to deal with the transfer of state.   Most of the 
discussion in this thread has been centered around three ideas: changing 
SLAAC, state survival in CPEs, and suggesting that SPs implement design 
changes.  My take is that we should make suggestions about fixing all 
three problem areas, i.e. add a section to slaac-renum about SP design. 
Whether this would belong in a standards track document is open to 
question, though.  Perhaps it would be useful to document the proposed 
SLAAC changes in a ST document and have a separate document describing 
the stale PD problem, with guidelines for CPE vendors and SPs as to how 
the problem can be worked around.

Modifying SLAAC would be likely to take years to roll out to end hosts.

The other two suggestions - behavioural changes to CPEs and design / 
implementation changes on service provider networks - will require 
buy-in from cpe vendors and service providers.  Barbara's comments about 
equipment implementation limitations are spot on, and I think we will 
see some push back from SPs on this.

Regarding the discussion on DUIDs, it's hard to imagine why a CPE which 
can provide a persistent DUID and which has an active lease on a 
particular prefix would be provided with a different PD reply if it 
issues a request or renew after a reboot. There's an argument to make 
that SPs should refrain from punishing their customers with the 
limitations of their provisioning platform, particularly in a situation 
which can kill v6 connectivity for extended periods of time like this.

Conversely, a different DUID means different lease parameters, so the 
correct behaviour would be for the SP to assign a different dhcp reply, 
assuming the original lease was still active.  A SP can't generally 
second-guess the intentions of the CPE if it requests different parameters.

tl;dr: complex problem; no single solution.

Nick