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

[Nick Hilliard <[e-mail]>]

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

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.

> 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. 
Others noted that long SLAAC lifetimes and lack of application 
workarounds (HE, etc) would make it a noticeable problem, when it 
happens, but didn't comment on how frequently it happened.

> Do we agree that it would be good if routers that reboot could just
> reacquire the same prefix from DHCPv6 PD?

Most operators seem to provision their networks such that they will not 
commit to prefix stability over the lifetime of a customer contract 
unless the customer coughs up more money for it.  Hand in hand with 
this, static ip addressing is routinely handled differently to dynamic 
IP addressing on service provider networks.

> Do we also agree that there
> will always be a significant fraction of deployment in which that won't
> be possible?

This is a complex question which interplays with cost, network design 
and long term network complexity.  There is no easy answer to it.

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

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.

Nick