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

[Michael Richardson <[e-mail]>]

Joel M. Halpern <[e-mail]> wrote:
    > Given that if the CPE had stored the delegated prefix, it could have
    > continued to use it, one could equally (and arguably with more
    > justification) argue that the DHCP server violated its contract with
    > the CPE when it did not return the still-valid prefix (with a correct
    > lifetime).  After all, the server madea "contract" when it handed over
    > the address.

I mostly agree with your analysis.

There are some additional situations that make this a bit murkier:
1) The CPE died and was replaced, reflashed, upgraded, etc.  After which,
   it could well have a different DHCP DUID and the DHCP server thinks this
   is a different customer/device.  This is hard to get wrong with PPPoE
   if one links the prefixes to the customer login (via radius or other).
   On cable it's easier to get wrong, particularly if the CPE failure results
   in the new one having a different ethernet address (ethernet randomization not
   always good or useful)

2) The ISP died and the user connected to a different ISP!
   The prefix is legitimately quite different.

3) The customer was moved to a different CMTS, with the result that really
   needs to be renumbered.  I think that ISPs can do this correctly by
   setting correct lifetimes and doing some /60 routing until the lease
   expires, but...

    > Have I missed something in the "problem"?  Robustness is nice.  But
    > let's not bend over backwards trying to fix a problem of multiple
    > failures.

I think that the flash write issue is really not that big a deal.
It requires one write per renumber if done intelligently.  Perhaps one can
further enhance the heuristic to not bother if the lease time is less than a
few hours:  There are apparently jurisdictions where everyone gets renumbered
at 1am, but in those places the lifetimes should be very small.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-