Re: slaac-renum: New rev of draft-gont-6man-slaac-renum (Fwd: New Version Notification for draft-gont-6man-slaac-renum-08.txt)

[Fernando Gont <[e-mail]>]

On 20/5/20 13:05, Philip Homburg wrote:
> In your letter dated Tue, 19 May 2020 13:06:28 -0300 you wrote:
>>> In Section 4.5, I think it is bad to hardcode knowledge about ULAs
>>> in detecting stale prefixes. In my opinion that shows that the
>>> algorithm is fragile. And note that this applies to all hosts.
>>
>> Not sure what you mean. Could you please elaborate?
>> Unfolding th processing of ULA vs. non-ULA is simply
>> fine-tuning/optimization: So if, say, you had a globally-reachable
>> address, and now the router ceases to advertise the globally-reachable
>> addresses, but starts advertising the ULA, you keep both.
>>
>> One might was well not do this optimization, but it's certainly better
>> this way.
>>
>> WHy do you think about the algorithm being fragile?
> 
> I don't think it an optimization. Without separate processing it will fail.

That's a bold statement.

No, the algorithm will now fail.

If the algorithm were to not consider ULAs separately, then:
1) If the local network uses, say, ULA and non-ULA, *and*
2) The router advertises prefixes in separate packets, *and*
3) There's a lot of packet loss

Then, the algorithm would unprefer e.g. the ULA or non-ULA addresses, 
and might (depending on which values we use for the config variables) 
disable those later addresses. One can always set this second time-out 
to, say, the Router Lifetime  -- that would still clean-up stale 
addresses in reasonable time, while never removing them "erroneously".


I should point out that, from your pov, virtually every protocol you may 
engineer should be flagged as "will fail" or "fragile". SLAAC fails if 
all RAs are lost during a "Router Lifetime" period, for instance.



> We want something that quickly after the router reboots causes the
> old prefix to be dropped. Yet, the algorithm should not drop any prefixes
> due to modest packet loss. Currently, 2 out of 3 RAs can be lost without
> ill effects.

LTA_INVALID is your friend. As noted, one might even set it to "Router 
Lifetime".



> If an organisation has a third class of address, for example if a non-ULA
> prefix is used for internal addresses next to a separate prefix for
> external addresses. Or two different ULA prefixes with different semantics.
> Then this algorithm may drop some of the prefixes if prefixes are sent in
> separate RAs, as is currently allowed.

As much as you may drop a Router if RAs are lost.


[...]
> 
> So, the ULAs need to be treated specially to make it to work at all. This
> locks us into a situation where ULA, non-ULA is all that can exist.
> Introducing a third type of addresses would cause this algorithm to fail.

I believe this seems to me like an over statement.

As with my description above, for this to happen:
1) The same router should be advertising multiple non-ula prefixes, *and*
2) the router must be advertising different prefixes in different RAs, *and*
3) Multiple RAs need to be lost, for a considerable period of time, *and*
4) A new type of address (?) would need to be specified

Then, only then, one of such prefixes would be removed.

Me, I consider this very unlikely.

That said, I don't mind setting LTA_INVALID to the "Router Lifetime", 
and/or recommending that a host sends an unicasted RA at LTA_DEPRECATE, 
and another one at, say, time LTA_DEPRECATE + (LTA_INVALID - 
LTA_DEPRECATE) / 2.

I would expect any of these two, and particularly the setting of 
LTA_INVALID to address your concerns.



>> 2) Irrelevant from #2, from a theoretical there's no way in which a host
>> can positively know whether information is split into multiple RAs or
>> not. You may try to "sample" the router. But if you don't get split
>> information that might simply be the result of packet loss.
>> Additionally, the fact that at time T information is sent in a single
>> RA, doesn't mean that that will be the case at time T+t.
> 
> If have described my algorithm before. That finds splits RAs even in the
> presence of some packet loss (2 out of 3 packets getting lost).
> 
> Dealing with the case where a router suddenly switches from a single
> RA to multiple RAs is tricky. My algorithm can handle that if the router
> sends all RAs in a short period and there is no packet loss.
> 
> I assume that going from 1 to multiple RAs is a very rare event. If it
> isn't then my algorithm would need more work.

What's the basis on which the events that I deem as "unlikely" are to be 
handled because "theoretically, the std allows them", but then you 
ignore other possible scenarios by deeming them as "rare" (when they 
are, too, theoretically allowed by the spec)?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492