Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Fernando Gont <[e-mail]>]

On 3/2/19 15:30, Joel M. Halpern wrote:
> I have been trying to follow the discussion.  I think I have been able
> to reconstruct the problem being discussed.
> 
> If I understand correctly, we are talking about CPE behavior when the
> CPE receives IPv6 prefixes via DHCP-PD, and then advertises prefixes for
> hust using RA PIO.  The assumptions that I believe Fernando is making are:
> 
> 1) The CPE Does not store its delegations across reboots.
> 2) The CPE crashes
> 3) The CPE requests a prefix from DHCP-PD
> 4) The CPE receives a different prefix than it received before.

Yes. Or any variation of this that leads to the same behaviour -- e.g.,
the CPE does not cap the prefix lifetime according to the DHCPv6 lease,
and only sends one RA with PIO lifetime=0 at the time a new prefix is
leased -- but that RA is lost and not received by some nodes.



> An Fernando seems to be saying that this results in the CPE violating
> its "contract" with the hosts from earlier PIO information.

Well, the CPE cannot respect the contract in somehow it does not get
leased the same prefix, and it failed to cap the prefix lifetimes
accordingly, wither.



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

As far as the DHCPv6 server is concerned, I guess the argument could be:
you got a different prefix because you asked for a new leased. Had you
not asked a new lease, you could have continued using the previous one
-- but you just didn't know about it, because you didn't record it on
stable storage.



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

There are multiple reasons for which this may happen. THe interaction on
the WAN side and LAN side is largely unaddressed. So while we could
"expect" things from the CPEs that "would just make sense", we haven't
helped the situation by the lack of advice on how automatic
configuration on LAN and WAN sides are glued together. Some of those
devices  are part of the installed base, and are not going to go away
anytime soon.


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