Re: draft-gont-6man-slaac-renum: Algorithm (Section 4.5) in the presence of Router Lifetime=0

[Jen Linkova <[e-mail]>]

On Wed, Apr 1, 2020 at 10:50 AM Fernando Gont <[e-mail]> wrote:
> In the context of RFC8028, the information in PIOs become more
> associated with the sending router, than with the link itself.
>
> e.g., our draft aside: if you have Router 1 saying PREFIX A is on-link,
> and should be used for auto-configuration, and Router 2 saying that
> PREFIX A is not on-link and should not be used for auto-configuration,
> you'd be safe to consider it on-link, configure addresses for it, and
> send packets sourced from PREFIX A to Router 1.

Keep in mind there 3, not two signals here a router can send:
1) PREFIX A has the property X (e.g. is onlink or suitable for SLAAC)
2) PREFIX A does not have the property X (e.g. the prefix is not onlink)
3) no data about PREFIX A whatsoever.

My understanding of the current standards is that, as RAs are
processed independently, multiple RA containing 1+3 or 2+3 would
result in the consistent and predicable behaviour, while if routers
send both signals 1 and 2 - each new RA would update the information
about the prefix.

> There's no reason for the announcements of Router 2 to discard the
> information provided by Router 1 -- each of them simply provide their
> own view of the network.
>
> That's how I read the spec -- but will ask Brian and Fred, just in case.
> (thanks for noting this!)

I'd say I did not read the RFC8028 that way. My understanding is:
- it is talking about scenarios when multiple PIOs are advertised by
multiple routers.
- it requires the host to track what router announced what prefixes
(and btw I do not see it explicitly excluding PIOs with lifetime = 0
from that tracking...)
- PIO - router binding is supposed to be used to select the source
address for the specific next-hop (or  the next-hop for the specific
address). It does not seem change any other PIO processing.
Even more, it explicitly say 'If no router has advertised the prefix
in an RA, normal routing metrics will apply'.

> >> 2) RFC8028 requires that PIOs be associated with routers (otherwise in a
> >> multiprefix network scenario, your packets could be egress-filtered).
> >> Hence what one router advertises shouldn't affect the behavior wrt other
> >> routers.
> >
> > It is not about 'behaviour wrt other routers'. It's PIO processing
> > rules as specified in
> > https://tools.ietf.org/html/rfc4862#section-5.5.3
> > " If the advertised prefix is equal to the prefix of an address
> >
> >        configured by stateless autoconfiguration in the list, the
> >        preferred lifetime of the address is reset to the Preferred
> >        Lifetime in the received advertisement.  "
> >
> > So if I have two routers advertizing the same prefix in PIO, a single
> > RA with Preferred Lifetime =0 (from any of those two routers) would
> > deprecate the prefix.
> > I could not find anything in  RFC8028 (which does not even update
> > RFC4862) which changes that logic.
> > Am I missing anything?
>
> You raise a valid point, indeed. I'll check this with Fred and Brian,
> and will also check what implementations are doing. But you may be right
> in that we might want to include an exception for the case where Router
> Lifetime == 0.

IMHO the simplest way to do that would be Preferred Lifetime =
max(AdvDefaultLifetime, 3 * MaxRtrAdvInterval).

> > last time I checked the Rule 5.5 was not widely supported, which is
> > very sad indeed.
> > I'd be very happy to be proved wrong.
>
> I will check and report back.

Would be appreciated, thanks!

-- 
SY, Jen Linkova aka Furry