Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

[Owen DeLong <[e-mail]>]

> On Oct 31, 2019, at 8:02 PM, Fernando Gont <[e-mail]> wrote:
> 
> On 31/10/19 16:38, Owen DeLong wrote:
>> 
>> 
>>> On Oct 31, 2019, at 12:21 PM, Fernando Gont <[e-mail]> wrote:
>>> 
>>> Hello, Ted,
>>> 
>>> 
>>> On 27/10/19 09:02, Ted Lemon wrote:
>>>> Indeed, this would also not actually solve the problem.   At present,
>>>> the ISPs are doing something that is out of spec and causes problems.
>>>> If we “fix” this by accommodating what they do, does that help, or
>>>> does it just encourage them to continue doing it?
>>> 
>>> Did happy eyeballs encourage broken IPv6 connectivity, or did it
>>> actually help IPv6 deployment?
>> 
>> Considering these mutually exclusive is a false dichotomy.
>> 
>> It did both.
> 
> It's hard for me to believe that folks were breaking stuff on purpose.

Perhaps “encouraging broken…” is too strong, but certainly it “reduced motivation to fix broken IPv6” and “reduced visibility of broken IPv6”.

> In any case, I would assume and expect that helping IPv6 deployment was
> more of a priority at the time. IN fact, we wouldn't be talking about
> "google seeing 25% of IPv6" if there wasn't a way to circumvent
> brokenness, I'd assume.

It absolutely was more of a priority and that’s why it was implemented. However, we should recognize that it was not without collateral damage.

It may be that we accept that this idea, too, comes with certain unintended consequences, but we should at least make a legitimate effort to identify and consider them, mitigate them to the extent possible, and then make a conscious deliberate decision to accept them (or not).

> [...]
>> 
>>>> When another RA arrives, see if it was signed with the same key.   If
>>>> so, it came from the same router, and can be trusted to update
>>>> whatever information that router sent, including flash-deprecating a
>>>> prefix.   If not, ignore it.
>>> 
>>> In the non-SEND trust model, you do trust the local router. Why did you
>>> trust the local router to configure your network, but not for
>>> deprecating the prefix?
>> 
>> Trusting the local router to configure the network to add a previously non-operational host to the network has a somewhat different set of consequence for failure than trusting whatever on-link host wishes to tell you to effectively shut down your currently operating network connection.
> 
> We'll that's the SLAAC model.

I think you are still missing the point here… The current SLAAC model is trusting the router to configure the network. The consequences when this model fails are that new hosts have difficulty (or failure) joining the network. In most cases, it has pretty limited consequences to existing hosts ability to continue to run.

On the flip side, what is being proposed does create a possibility where a single crafted packet can literally immediately disconnect every host on the link from the network.

The model is the same, but the consequences are significantly different, so perhaps the greater consequences warrant considering a different trust model.

> 
> 
> 
>> Especially when you consider that such an announcement can be sent to the all nodes on link multicast address, effectively dropping them all at once.
>> 
>> I agree it’s not a huge difference, but, it is a difference and certainly the scope of the resulting problem can be much larger than the case of individual host configuration.
> 
> Hosts trust a lot of other crap. e.g., feel free to advertising a Cur
> Hop Limit of 1. Is that any different?

Yes… A hop limit of 1 leads to errors that make the cause rather obvious.

Crafted RAs that send out PIOs deprecating all the actually valid prefixes lead to error conditions that can be much harder to identify/isolate.

Owen