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

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Mar 2020 14:21:21 -0300

Folks/Jen,

During the 6man session Jen noted that it might be dangerous to set the 
PIO lifetimes to 0 when the Router Lifetime is set to 0.

Notes about our reasoning:

* If the prefix is advertised by multiple routers,  setting the PIO 
lifetimes to 0 will just dis-associate the prefix/addresses with this 
particular router, and the fate of this prefixes/addresses will depend 
on the other routers.

* If the router was advertised by only this router, where should packets 
be send to? In the light of RFC8028, prefixes are really tied to the 
routers that advertise them.

That said, if you could suggest how RAs with Router Lifetimes set to 0 
should be handled, we'd like to hear from you. Any suggestions for 
improvements are really welcome!

Thanks!

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

---

From: Mark Smith <[email-masked]>
Date: Wed, 1 Apr 2020 07:32:56 +1100

> routers that advertise them.

I don't think setting the VL to zero is a good idea, as it fails the
"principle of least surprise".

A VL of 0 has an implicit value of 7200 seconds per RFC4862, section 5.5.4:

1.  If the received Valid Lifetime is greater than 2 hours or
          greater than RemainingLifetime, set the valid lifetime of the
          corresponding address to the advertised Valid Lifetime.

      2.  If RemainingLifetime is less than or equal to 2 hours, ignore
          the Prefix Information option with regards to the valid
          lifetime, unless the Router Advertisement from which this
          option was obtained has been authenticated (e.g., via Secure
          Neighbor Discovery [RFC3971]).  If the Router Advertisement
          was authenticated, the valid lifetime of the corresponding
          address should be set to the Valid Lifetime in the received
          option.

3.  Otherwise, reset the valid lifetime of the corresponding
          address to 2 hours.

Note that the 2 hours is not host variable that can be changed by a
system administrator. I think that means that VL=0 will always
implicitly mean VL=7200 seconds. VL=0 doesn't mean "what ever the
host's VL minimum lifetime value  is currently".

When there is a choice, I've found it is better to make it obvious how
things work, because hopefully it makes things more obvious how
they've failed.

Setting the VL=7200 seconds could mislead people into thinking the VL
is actually being set to 0 seconds on an address on a host when one of
these PIOs is sent. This misunderstandings can waste a lot of time
while troubleshooting, because something apparently very basic (VL=0
in the PIO not having an effect of setting the host's address to VL=0)
doesn't seem to be working.

This is why the "DeprecatePrefix" option in 'radvd' doesn't set VL=0
to deprecate a prefix.

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Wed, 1 Apr 2020 07:43:13 +1100

> Setting the VL=7200 seconds could mislead people into thinking the VL

Got that the wrong way around (perhaps also demonstrates my point):

"Setting the VL=0 seconds could mislead people into thinking the VL is
actually being set to 0 seconds on an address on a host ..."

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 Mar 2020 23:25:41 +0200

>improvements are really welcome!

I don't think we can affort the break things that currently work.

Current a setup where a router announces prefixes without being a default
router and a separate default router that doesn't not announc prefixes
would work.

The obvious solution is simple: if the router lifetime is zero, then don't
change the advertised values. If the router lifetime is non zero then
limit them to some multiple of the router lifetime.

Note that RFC 8028 is carefull enough to not break this example.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Mar 2020 18:37:29 -0300

Hello, Mark,

> 3.  Otherwise, reset the valid lifetime of the corresponding

I'd say it has a meaning of "Reduce the vltime as much as possible" -- 
i.e., if you set the advertised vltime to 7200, but the remainingtime 
was less than 7200, then your advertised vltime will actually increase 
the reamining time.

OTOH, if you set vltime to 0, it will either reduce the remaining time, 
or leave it as is.

> doesn't seem to be working.

We are indeed also proposing to remove the corresponding paragraph from 
Section 5.5.3 of [RFC4862].

Thoughts?

Thanks for your feedback,by the way! (I always appreciate it!)

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Mar 2020 18:43:18 -0300

Hello, Philip,

Thanks so much for your feedback! In-line....

> router and a separate default router that doesn't not announc prefixes

In that scenario (multiple routers announcing the same prefix), a VL==0 
would only dis-associate the prefix with this router, but not actually 
deprecate it.

Please see the clauses like:
"ELSE IF this prefix has been advertised my multiple
             neighboring routers, simply disassociate this prefix with
             this particular router.  This will cause the fate of this
             prefix to depend on the other routers."

in the algorithms.

Or am I missing something?

Thanks for the feedback! (and also for your help in improving our 
document over time!)

Cheers,

---

From: Jen Linkova <[email-masked]>
Date: Wed, 1 Apr 2020 08:54:22 +1100

> particular router, and the fate of this prefixes/addresses will depend

I guess it's the case only for hosts which support your draft. What
about 'legacy' hosts?

So let's say I have a network with two routers and some hosts. Both
routers advertise themselves as default routers and a prefix in a PIO.
I'm lazy and I use the default values for almost everything.
Now I'm taking one router down for a maintenance. What I'd do
normally, among other things, is to make that router advertise itself
with Router Lifetime = 0.
The router will send an RA with:
- Router Lifetime = 0
- Lifetimes for prefixes = 0.
oops, I have some hosts in the network which deprecate the prefix
right way and their addresses would stay deprecated until the second
router sends a pariodic RA (God knows when...maybe in 30 mins?).
Absolutely undesirable result from my PoV.

> be send to?
> In the light of RFC8028, prefixes are really tied to the

I need 1) coffee 2) read the latest version of the draft. But:
- if prefixes are really tied to the routers that advertise them
(which, AFAIK, is recommendation which is not really happening in the
real life - but I'd love to learn what OSes support the Rule 5.5 of
the default address selection), then I'll try to sell you my old idea
(once again): let the router to send RAs from a link-local address
which is a hash of all prefixes advertized in PIOs. As soon as the
prefix set changes, the 'old' router becomes unreachable - NUD takes
care of it, and then Rule 5.5 would solve all problems.

> improvements are really welcome!

I'll send you the text.

-- 
SY, Jen Linkova aka Furry

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Mar 2020 19:14:39 -0300

> I guess it's the case only for hosts which support your draft. What

Nope. That's implied from RFC8028.

> router sends a pariodic RA (God knows when...maybe in 30 mins?).

Nope. Two things:

1) As per current specs ("e)" (pp. 19-20) from Section 5.5.3 of 
RFC4862), a VL of 0 would never get to invalidate the prefix, but would 
set the remaining time to 7200. If the host does something else (i.e., 
honor the VL==0), it's not legacy, and supports our draft.

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.

> I need 1) coffee 2) read the latest version of the draft.

Point taken ;-)

> But:
> the default address selection),

Without Rule 5.5, multi-prefix network can't possibly work (for at least 
the general case).

> then I'll try to sell you my old idea

Sounds smart, indeed. *But* that requires router changes for hosts to 
benefit from it. Hence, cannot be relied upon.

>> improvements are really welcome!

Look forward to it!

Thanks!

Cheers,

---

From: Jen Linkova <[email-masked]>
Date: Wed, 1 Apr 2020 09:58:05 +1100

> Nope. That's implied from RFC8028.

Could you please elaborate?

> honor the VL==0), it's not legacy, and supports our draft.

Pls note I did not say 'invalidate'. I said 'deprecate'. I'm not
talking about how valid lifetime is processed (because you are right,
all legacy host would ignore it).
However the router would set Preferred Lifetime to AdvDefaultLifetime
= 0. Which would be very disruptive for IPv6 on hosts.

> Hence what one router advertises shouldn't affect the behavior wrt other

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?

> Without Rule 5.5, multi-prefix network can't possibly work (for at least

Oh I'm well aware of that and I totally agree with you here! It's just
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.

> benefit from it.

Wait, aren't we discussing changes on *routers*?
Sorry, I seem to be very slow. Until now I've been under impression
that the topic of this thread is the proposed changes on routers: so
they would set both Preferred Lifetime and Valid Lifetime in PIOs
based on AdvDefaultLifetime.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 31 Mar 2020 20:49:58 -0300

Hello, Jen,

> Could you please elaborate?

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.

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

> = 0. Which would be very disruptive for IPv6 on hosts.

The above would apply here as well.

> RFC4862) which changes that logic.

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.

> I'd be very happy to be proved wrong.

I will check and report back.

> Wait, aren't we discussing changes on *routers*?

We are doing *both*. What I mean is: doing stuff on the router side is 
desirable -- including what you suggest. However, whatever we do on the 
router-side doesn't relieve us from doing stuff on the host side. That's 
why, for example, even when we change the default values for PIOs, we 
also propose to clamp the PIO lifetimes on the host side.

> based on AdvDefaultLifetime.

You're not slow. Maybe I was just sloppy with my response. I was simply 
responding to your comment "...NUD takes care of it, and then Rule 5.5 
would solve all problems". And I was meaning "what you propose is smart. 
However, we need to do more than that".

Thanks!

Cheers,

---

From: Jen Linkova <[email-masked]>
Date: Wed, 1 Apr 2020 13:14:49 +1100

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

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

> in that we might want to include an exception for the case where Router

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

> I will check and report back.

Would be appreciated, thanks!

---

From: Fernando Gont <[email-masked]>
Date: Wed, 1 Apr 2020 00:01:35 -0300

Hi, Jen,

> send both signals 1 and 2 - each new RA would update the information

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?

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

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

---

From: Jen Linkova <[email-masked]>
Date: Wed, 1 Apr 2020 15:40:34 +1100

On Wed, Apr 1, 2020 at 2:03 PM Fernando Gont <[email-masked]> wrote:
> RFC8028 is rev'ed.

Yeah, I've seen your errata.
I might be wrong but I think we are mixing two different scenarios.
1) Multiple RAs contain complementing information (e.g. different
PIOs). Information from RA1 does not contradict information from RA2.
That's OK and that's what RFC8028 seems to be dealing with.
2) Multiple RAs contain conflicting information. The prefix can not be
on-link and off-link at the same time. That looks like a configuration
error to me.
If we look at the example you provide in the errata: 'for the same
prefix, one router sends zero lifetime, another sends non-zero'.
That's reasonably intuitive. But what if the host receives two RAs
from two routers, the same PIO, but one RA contains lifetime = X secs,
while another contains lifetime = Y secs, X != Y?
Which one to use? Shall X = 0 case be special?

> the PIO Valid Lifetime as a function (multiple) of that?

See my suggestion below.

> >>  we might want to include an exception for the case where Router
> >> Lifetime == 0.
> >

AFAIR AdvDefaultLifetime is defined as 'The value to be placed in the
Router Lifetime field of Router Advertisements sent from the
interface'.
Its *default* value is 3 * MaxRtrAdvInterval.
So if you define the default value for the Preferred Lifetime as
max(AdvDefaultLifetime, 3 * MaxRtrAdvInterval), then it would always
be > 0 and >= 3 * MaxRtrAdvInterval. So missing two RAs would be still
safe.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 1 Apr 2020 02:26:10 -0300

Hi, Jen,

> Which one to use? Shall X = 0 case be special?

What I'd say is:
You keep this information on a per-router basis. So you keep X 
associated with one router, and Y with another. Normally, they would 
always be non-zero. But if one of them becomes 0, that's kind of 
equivalento to the prefix not being advertised by that router. And the 
fate of the prefix depends on what the other router is doing.

The only special thing about 0 is that it would mean "look, from my pov, 
this prefix is deprecated/invalid". IN that case, you wouldn't consider 
use of prefixes with routers that declare them as unpreferred/invalid. 
But as long as there's a router that considers the prefix valid, it 
should be okay to employ the prefix with it.

[...]>>>>   we might want to include an exception for the case where Router
> Its *default* value is 3 * MaxRtrAdvInterval.

You're right! -- The variable name seems kind of a misnomer: i.e., it's 
not really a default value.

FWIW, your suggestion looks like the right thing to do. We will update 
the draft accordingly. Thanks!

Cheers,