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

[Ted Lemon <[e-mail]>]

So, who’s going to summarize this discussion in a presentation at IETF, and
will it be in 6man or v6ops?

On Sat, Feb 23, 2019 at 00:23 Fernando Gont <[e-mail]> wrote:

> 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
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>