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

[Fernando Gont <[e-mail]>]

Hi, Jen,

On 31/3/20 23:14, Jen Linkova wrote:
> 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.

After talking with Brian and Fred, that's likely the case. i.e., the 
behavior I mentioned might be desired, but we cannot really say that it 
is "expected" -- as you correctly noted, RFC8028 did not update RFC8028, 
so...  FWIW, I've filled an errata so that this is looked into if/when 
RFC8028 is rev'ed. But, as noted, what you described is probably the 
only safe assumption.

In that light, how about, when Router Lifetime == 0, setting the PIO 
Preferred Lifetime to 1800 (the current default router lifetime), and 
the PIO Valid Lifetime as a function (multiple) of that?


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

I've re-read RFC8028 and, clearly, what's in RFC8028 is what you describe.

That said, in a scenario where e.g. one router considers a prefix 
valid/preferred/on-link, and another considers it the opposite, it would 
seem to me that rather than do flip-flop and go back and forth (valid 
<-> invalid), it would be best for hosts to use the prefix as valid with 
the router that considers it valid.  -- that seems to be more resilient.

But, as noted above, if anything this is stuff to be considered in the 
event of an RFC8028 update. Whereas, in the context of our draft, we 
should be e.g. deal with the case where Router Lifetime = 0 as an exception.

Thoughts?


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

You mean "Router Lifetime" (i.e., the value manually configured) rather 
than AdvDefaultLifetime?  -- cause AdvDefaultLifetime is defined itself 
as 3 * MaxRtrAdvInterval.

Thanks!

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