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

[Jen Linkova <[e-mail]>]

On Wed, Feb 20, 2019 at 3:22 PM Fernando Gont <[e-mail]> wrote:
> 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.

yeah, see another email I've just sent ;)

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

Well, my ISP sent me a CPE which is configured to send RAs with router
lifetime of 30 seconds or smth (I sent it back so can not verify
anymore ;))
I would object if I can not listen to the music (which is stored at
the machine in the network) because my Internet connection goes down
(as it's been doing 5 times/day recently ;)

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

I'm even more confused now, sorry ;((

Both your draft and my draft talk about cases when *the given
interface* has addresses from the different prefixes and it would be
nice to make sure the host selects the correct one.
So in the case described above:
Time t0:
if1: has addresses from 2001:db8:1::/64, the default route -> if1
if2: has addresses from 2001:db8:2::/64

Time t1
an RA received on if1 containing PIO for 2001:db8:3::/64 (no PIO for
2001:db8:1::/64)

Time t2
if1: has addresses from 2001:db8:1::/64, 2001:db8:3::/64 the default
route -> if1. An RA received
if2: has addresses from 2001:db8:2::/64

Time t3:
the host is trying to send an IPv6 packet off-link.
It selects if1 and now needs to select one of addresses on the
outgoing interfaces. My algorithm suggests that address(es) from
2001:db8:3::/64
should be preferred as they are "freshest" ones. The same outcome as
deprecating  2001:db8:1::/64

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

If the only routes are default routes  it does not matter, right?

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

It would be nice to make it clear IMHO...

-- 
SY, Jen Linkova aka Furry