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

[Fernando Gont <[e-mail]>]

On 22/2/19 09:36, Nick Hilliard wrote:
> Christian Huitema wrote on 22/02/2019 07:44:
>> Debating the beauty of NAT on an IPv6 list is surely good fun for some,
>> but could we get some progress on the original issue, which could be
>> summed up as a "bug in SLAAC"? Fernando filed that bug 3 weeks ago, I
>> saw hundreds of messages on the mailing list, but I did not see much
>> progress.
> 
> There seems to be lack of consensus on whether this can be thrown into
> the "bug in SLAAC" category.
> 
> Ole declared that the root cause was "misconfiguration/error".

I'm not sure that's Ole's view. Actually, it would seem to me that at
the very least he agrees that the "CPE crashes-and-reboots and network
continues using a stale prefix" is a problem to solve.



> Fernando and others feel that it's the compound outcome of several
> independent protocol and design-choice behaviours, none of which,
> incidentally, is inherently broken per se.

I'd disagree a bit.

e.g.,

* The current default values for the prefix lifetimes does not seem to
be the result of much of a "design choice".

* The underspecification of DHCPv6-PD/SLAAC is.. that... fault on our side

* As per RFC4862, it turns out that you cannot remove a stale prefix vy
sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards,
not even the CPEs can (even if they wanted to) do something to fix the
problem.




>> Do we agree that this is indeed a bug, or do we think that having users
>> disconnected from the Internet after a home router reboots is just a
>> desirable feature of IPv6?
> 
> Most people feel the outcome is undesirable when it happens.  Some
> people feel that it's not worth getting too excited about because
> assignment stickiness tends to ensure that prefix assignments are
> long-lived enough that it probably won't cause too much difficulty.

This work was triggered from such (bad) experience by an ISP. As per a
survey referenced in our I-D, 37% of IPv6 deployment seem to offer
dynamic prefixes. The problem we are discussing may be masked via
IPv4/HE -- but I don't think we can or want to rely on that.


>> Do we agree that the working group should actually start working on some
>> improvement in SLAAC that would mitigate the issue? Not excluding of
>> course solutions that would also mitigate related egress filtering issue?
> 
> Fixing or updating SLAAC is likely to take years to roll out and at
> least one person was of the opinion that SLAAC was basically unfixable
> in this regard.  This ignores whether it would be useful or viable for
> the IETF to issue advice to CPE vendors and service providers about how
> to avoid the problem from happening in the first place.

May I ask why SLAAC is unfixable?



> Ultimately, your email shows why the discussion ended up in a discussion
> about NAT.  There's no single cause of the problem and no quick fix;
> declaring the problem to be solely the domain of any particular
> stakeholder may cause CPE vendors to deploy NPTv6 in the long term to
> work around the issue, because this would make the problem mostly
> disappear from the point of view of the user. There is a cost, of
> course, but it's a cost which most end users are already familiar with,
> and accept.  It would be sad and unfortunate if this were to be the
> outcome of this discussion.

Indeed.

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1