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

[Christian Huitema <[e-mail]>]

 

> On Feb 22, 2019, at 4:36 AM, Nick Hilliard <[e-mail]> 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".
> 
> 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.

I think that's a good summary: a problem that does not occur very often, but is very annoying when it does.

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

I think that your response to the previous question also sums up this side of the issue. Many operators do provision fairly stable prefixes. However, for a set of complicated reasons, not all of them will guarantee this stability, not all the time. The answer there could very well be to do nothing, and to not add another mandate to operators.

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

Anything we do in this space can take a long time to roll out, but it does not take forever. In many cases it probably takes less time than it takes to agree on a potential solution in the IETF. For example, security bugs in operating systems can get patched in a matter of weeks or maybe months. Not all devices can be patched quickly, but many can.

As usual, we don't want to see creative solutions popping in different devices. A common standard seems preferable. So, if a subset of the working group wants to work on the solution, we should be happy to let them do that.

-- Christian Huitema