Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Timothy Winters <[e-mail]>]

On Thu, Feb 21, 2019 at 11:12 AM Fernando Gont <[e-mail]>
wrote:

> On 21/2/19 07:41, Tim Chown wrote:
> >> On 21 Feb 2019, at 02:01, Erik Kline <[e-mail] <mailto:[e-mail]>>
> >> wrote:
> >>
> >> On Wed, 20 Feb 2019 at 17:49, Fernando Gont <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >>     Hi, Eric,
> >>
> >>     On 20/2/19 22:12, Erik Kline wrote:
> >>     >
> >>     >
> >>     > On Wed, 20 Feb 2019 at 17:07, Fernando Gont
> >>     <[e-mail] <mailto:[e-mail]>
> >>     > <mailto:[e-mail] <mailto:[e-mail]>>>
> >>     wrote:
> >>     >
> >>     >     On 20/2/19 06:36, Jen Linkova wrote:
> >>     >     [...]
> >>     >     >> 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 ;((
> >>     >
> >>     >     I was referring to the fact that some of the previous rules
> >>     might
> >>     >     prevent the evaluation of the rule about freshness. e.g.:
> >>     >
> >>     >     * You have two network interfaces eth0 and eth1 (say each
> >>     connected to a
> >>     >     different ISP)
> >>     >     * eth0 has stopped receiving RAs
> >>     >     * eth1 receives RAs as usual (hence all info associated with
> >>     this
> >>     >       interface is "fresher" than than corresponding to eth0)
> >>     >     * The default router employed by eth0 has precedence
> >>     (whether because it
> >>     >       had a higher preference value, because it was the first
> >>     one that was
> >>     >       learned, or whatever)
> >>     >     * When you evaluate the rules in RFC6724, rule 5 will say
> >>     that the
> >>     >       outgoing interface will be eth0, and thus you should pick
> >>     an address
> >>     >       associated with it --- however, as noted above, the
> >>     addresses on eth1
> >>     >       are fresher than those from eth1.
> >>     >
> >>     >
> >>     > Not receiving multicast RAs is not a condition you can really
> >>     take any
> >>     > action on.
> >>
> >>     Agreed.
> >>
> >>     The main issue I see with incorporating an explicit rule in RFC6724
> >>     about "freshness" is that in multi-prefix scenarios, it's guaranteed
> >>     that the default SA will oscillate among the different prefixes, and
> >>     that if you only implement this workaround, you wouldn't be able to
> >>     communicate with hosts actively employing your stale prefix.
> >>
> >>
> >> that's where rule 5.5 would help (wherever it is actually implemented;
> >> alas...)
> >
> > Yeah.... we did add an explicit pointer to this in the Nodes
> > Requirements -bis, fwiw (noting RFC 8028).
>
> Probably an irrelevant question to ask now :-), but, anyway: any clues
> why RFC8028 is a "SHOULD" rather than "MUST"? -- It would seem to me you
> cannot really do multi-prefix without RFC8028...
>
My memory of this was the working group wasn't convinced that every node
needed to support it.

>
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>