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

In line...

On 21-May-20 04: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 makes it fragile. 
> 
> 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.
> 
> Without the separately processing ULA from non-ULAs, if the router sends
> ULA and non-ULAs in separate packets, and some of non-ULAs get lost, then
> the host will drop the non-ULA prefixes (or the other way around).
> 
> 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.
> 
> So in my opinion, the algorithm has to work correctly without knowledge
> of ULA.
> 
>> When a prefix is missing, that's an indication that the prefix has 
>> become stale. Now, you might process the RAs irrelevant of ULA nad 
>> non-ULA, and it would also be fine.
>>
>> But the logic here is that it is better to have one stale address of 
>> each type, than no address of that type. If you want, this is the 
>> algorithm being more conservative.
> 
> Again, without special treatment of ULAs, the algorithm is dangerous. It can
> take an RA with a ULA to invalid all non-ULA prefixes.

I'm finding this hard to understand, since the text says:

  "o  Only RAs that advertise Global Unicast prefixes may deprecate
      Global Unicast Addresses (GUAs), while only RAs that advertise
      Unique Local prefixes may deprecate Unique Local Addresses (ULAs)."

Perhaps that should be reformulated with MUST NOT terminology to make it
clearer:

   o  RAs that advertise Global Unicast prefixes MUST NOT deprecate
      Unique Local prefixes, and RAs that advertise Unique Local
      prefixes MUST NOT deprecate Global Unicast prefixes.

> So, the ULAs need to be treated specially to make it to work at all. 

Yes, of course. They *are* special. They work even if the WAN side drops
and even if the WAN prefix changes. 

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

Yes. If there was a 4th type of address (we already have three, counting
link-local), every router in the universe would need a fix.

Regards
    Brian

>> Two things:
>>
>> 1) network config split into multiple RAs do not happen in practice -- 
>> as reported by Time Winters
> 
> We have a mature IPv6 standard. We should not modify hosts to deal with
> one corner case, and then break other things that are allowed by
> the standard.
> 
> Note that even your proposed change to sending RAs still allows for the
> possibility to send split RAs.
> 
>> 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.
> 
>> The point of the algorithm is simple:
>> The algorithm doesn't deprecate prefixes at once. So if information is 
>> split into multiple RAs, then since you don't act on RAs at once, the 
>> algorithm will handle the split information gracefully.
> 
> Without the ULA, non-ULA split this algorithm is unsafe. Receiving a 
> ULA in a single RA causes the hosts to deprecated other prefixes within
> 5 seconds, which causes new connections to use ULAs which fails.
> 
> It is only by recognizing ULA as special that this algorithm works.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 