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

[Fernando Gont <[e-mail]>]

On 22/2/19 13:44, Christian Huitema wrote:
> 
>>> 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.

Everytime there's a power outage, this problem will happen. Similarly,
at least in these latitudes, whenever you call tech support at your ISP,
first question is "have you tried disconnecting and reconnecting the
router" -- that's the way most non-technical users (and also technical
users) first approach issues with their connectivity. Everytime this
happens, this problem may occur.

For the time being, as long as we have IPv4, IPv4/HE may mask the
problem. So, as long as this gets fixed before we go IPv6-only (which in
many places will not be anytime soon), that's pretty good timing to get
the problem solved.



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

Indeed. As one datapoint, we published RFC8064 in early 2017. And even
mid 2018 if you were to install a fresh copy of a modern OS, in most
cases it would implement RFC8064/RFC7217.

Particularly when you get implementers in the loop, and when they
realize that stuff makes sense, things don't take that long.



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

Agreed.


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

Exactly. Some of those solutions have already popped (see the FRITZ
reference in our I-D). Ignoring the problem is simply asking for more
(and worse)

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