Re: A common problem with SLAAC in "renumbering" scenarios

[Fernando Gont <[e-mail]>]

On 19/2/19 04:56, Jen Linkova wrote:
> On Tue, Feb 19, 2019 at 10:41 AM Fernando Gont <[e-mail]> wrote:
>>> I might be biased here indeed but I think that using the "most
>>> recently updated" (however we define that) address would be the
>>> simpler solution than
>>> deprecating the whole prefix (and both solution requires hosts to keep
>>> the PIO <> advertising router mapping).
>>
>> Say the Stale prefix is 2001:Db8:1::/64, for which you configured
>> 2001:db8:1::1.
>>
>> Say that Prefix(2001:Db8:1::/64) has now become stale, and a new prefix
>> 2001:db8:2::/64 is being announced, for which you have 2001:db8:2::1.
>>
>> Say you now need to send packets to 2001:db8:1::/64.
>>
>> You will use the new addresses (from 2001:db8:2::/64), but will send the
>> packets assuming nodes are "on-link", instead of sending them to the
>> default router.
> 
> True. I'm not convinced that this use case is worth solving by
> introducing the complexity (and impact on other scenarios)  the draft
> is suggesting

Could you elaborate on what's the complexity you are referring to and
what's the impact on other scenarios?  Having multiples addresses from
multiples prefixes is complex.



> What I'm not a big fun of is assuming that absence of evidence is
> actually evidence of absence. When a router stops advertising a prefix
> it does not necessary mean
> that hosts shall stop using the addresses.

This is not the way the proposed algorithm work.

I'd agree with you that if you stopped receiving RAs, *that* wouldn't
necessarily warrant a prompt reaction.

However, the proposed algorithm reacts to *RAs from the same router*
(i.e. the router *is alive*) that do carry PIOs, but they happen to
advertise PIOs for different prefixes.

Once you receive four RAs with PIOs from the same router, all of them
including PIOs, but failing to advertise the stale prefix, you remove
the addresses.



> It does indeed in the
> scenario the draft describes but the host can not know the
> topology/scenario.
> The proposed host changes would solve  one particular case (DHCPv6-PD
> router crash/reboot) while multiprefix/multihomed networks.
> 
> Lets say there are two routers (R1 and R2) on the LAN.
> R1 advertised 2001:db8:1::/64 and 2001:db8:3::/64
> R2 advertised 2001:db8::2::/64 and 2001:db8:3::/64.
> 
> Hosts have addresses from 3 prefixes.
> Now R2 stops advertising 2001:db8:3::/64.
> 
> There is no reason for hosts to deprecate addresses in 2001:db8:3::/64.
> What's going to happen is every time an RA from R1 is received, hosts
> would get preferred addresses in 2001:db8:3::/64 and every RA from R2
> would deprecate them.

That's not correct. It takes two consecutive RAs for the prefixe to be
unpreferred. And another two consecutive RAs for the prefix to be
removed. In the scenario you describe, R1 would keep advertising the
prefix, and hence it would never be unpreferred or removed.

There's room for improvement and clarification, though: one may clarify
that. You might think of this problem as havinf a reference count on the
prefix. If there's only one router associated with the prefix, un-prefer
and remove the prefix. Otherwise, just dis-associate the prefix with
this particular router.




> I do believe that the default preferred lifetime is a bit longer that
> it should be (and I have to tweak it all the time). So maybe we shall
> change that.

Same applies to the Valid Lifetime. In the context of RFC8028 it doesn't
make sense for the Valid Lifetime of a prefix to span past the Router
Lifetime of a router.



>> Similarly, if you have multiple interfaces, Rule 5 might override your
>> rule 8.
> 
> Sorry, I must be very slow today. Could you please elaborate on this
> scenario?  I'm having difficulties figuring it out..

Example:

Say you have two network interfaces: If1 and If2.
Say If1, is configured with 2001:db8:1::/64, and If2 with 2001:db8:2::/64

Say the first default router is that associated with If1.

Say prefix 2001:db8:1::/64 stops being announced, or that you stop
receiving RAs on If1, but RAs on If2 keep arriving fine.

Based on the logic of your algorithm, one would expect that a new
connection uses 2001:db8:2::/64/If2 (since that's the "more recently
advertised information). However, Rule #5 would override that and make
you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes addresses on
the outgoing interface.

So as long as you have stale routes, in many cases that will override
any other rules for address selection. -- i.e., if your new rule for
RFC6724 comes after rule 5, you better get rid of stale routes, or
otherwise they will override you well-intended rule.



> The draft is talking about deprecating prefixes on *another*
> interface? I hope not..

Certainly not.



> Actually I've just realized that I could not find any clear definition
> of what 'the same router' means. The same address installed as
> 'next-hop'?
> The same combination of IPv6 address and L2 address?

My mental model (as long as this algorithm is concerned) is that the
router is uniquely identified by the (link-local) IPv6 address (the
combination of IPv6 and L2 would work, too, but it seems unnecessary).

We'll spell it out in the next rev.

Thanks!

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