Subject: slaac-renum: Valid Lifetimes

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 15:03:46 -0300

Folks,

We don't need to agree on this *now* (although it would be great! ;-) ), 
but I felt like polling the wg to get some input from you.

In the current revision of our draft (draft-gont-6man-slaac-renum-05), 
we use the following default values for PIOs:

* Preferred Time: Router Lifetime
* Valid Time: 48 * Router Lifetime

With the default Router Lifetime of 1800 seconds, the Valid Lifetime 
results in 1 day. This wasn't the value we were using in earlier 
versions of the draft, but based on feedback from Owen on the v6ops 
list, we decided to go this conservative value (since the specific value 
to use was a low-order bit of the draft).

However, after discussing this with a number of developers from 
different OSes there seems to be agreement that this value Valid 
Lifetime is still to large, and that it would be more sensible to use 
something like: 2 * Router Lifetime  (which is still very conservative).

Thoughts?

Thanks!

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

---

From: Erik Kline <[email-masked]>
Date: Thu, 2 Apr 2020 22:28:21 -0700

Whatever values/scaling is decided for these and other values via the
slaac-renum effort I do think we should make sure it's still possible to
sensibly follow the 7772 guidelines.

On Thu, Apr 2, 2020 at 11:05 AM Fernando Gont <[email-masked]> wrote:

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 3 Apr 2020 04:06:47 -0300

Hello, Erik,

> sensibly follow the 7772 guidelines.

Indeed. What I'm asking is not to change the default router lifetime, 
but rather establish a relationship between the Router Lifetime and the 
other parameters.

And the point I'm trying to make is that extending the lifetimes beyond 
the Router Lifetime does not make sense. For instance, at the end of the 
day, e.g. the TCP abort interval is less than 10 minutes.

Once you are using, say, a Router Lifetime of 30 minutes, you're way 
over what e.g. your TCP connections would survive, anyway.

For a subnet where you have a single router, the router becoming invalid 
already means you have nowhere to send your packets. And if you are on a 
"multi-homed" subnet, as per RFC8028, use of a prefix is associated with 
the router that advertised it.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Fri, 03 Apr 2020 11:57:21 +0200

>something like: 2 * Router Lifetime  (which is still very conservative).

I think we should be extremely creaful with this. This a a host overriding
parameters provided by the network. So we effectively limit how people
can run their networks.

In particular, I can imagine that some people may want long lifetimes to
make sure that if a router dies, local communication remains possible.

So I think limiting the preferred lifetime is relatively safe. Maybe the
valid lifetime can be reduced to one day, but shorter is probably a bad idea.

That said, if we make valid lifetime a small multiple of router lifetime,
then people who want a long valid lifetime can increase router lifetime.
However, a long router lifetime may come back to bite us at other points.

So I would go for something like:
the limit on valid lifetime = max(1 day, 2 * router lifetime).

I assume that in most cases, the algorithm ill agressively limit the valid
lifetime of prefixes that are no longer announced. I.e., this blanked cap
is only for the cases where the algorithm fails.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 4 Apr 2020 17:23:32 -0300

Hello, Philip,

Thanks for your feedback! In-line...

> parameters provided by the network. So we effectively limit how people

I disagree in this respect for two reasons:

1) The current default values in RFC4861 essentially mean that these two 
parameters are not used. A preferred lifetime of 1 week or a valid 
lifetime of one month is not meaningful at all.

2) I this particular case, we are simply implementing a host-side limit 
for the amount of time we'll use information provided by the network 
(unless it is refreshed). SLAAC hosts implement a bunch of other limits, 
such as maximum number of configured addresses, maximum number of 
routers, etc.

That said, indeed nobody is intending to be careless. That's why I'm 
raising the question in the first place.

> make sure that if a router dies, local communication remains possible.

1) If you're thinking about a typical home/CPE scenario, the local 
router also happens to be the local switch. So if the router dies, 
you're toast, anyway.

2) That's what link-local addresses are for. IPv6 hosts typically 
configure many addresses of different properties. Therefore this 
increased flexibility should be leveraged, as opposed to applying the 
IPv4 model where hosts typically configure only one address for each 
network interface.

> valid lifetime can be reduced to one day, but shorter is probably a bad idea.

Can you think of a scenario where the Router Lifetime has expired 
because e.g. the router died, and it makes sense to keep addresses for 
such much longer extra time?

> then people who want a long valid lifetime can increase router lifetime.

Indeed.

> is only for the cases where the algorithm fails.

Yes, this limit is mostly aimed at dealing with routers that "disappear" 
(either because the router indeed disappeared, or because e.g. a 
switch-port was moved into a different VLAN and hence the router is not 
present in the local subnet anymore).

Thanks!

Cheers,

---

From: Philip Homburg <[email-masked]>
Date: Sun, 05 Apr 2020 13:30:09 +0200

>lifetime of one month is not meaningful at all.

If routers provide wrong parameters then it is to the network operator
to correct them, and to v6ops to recommend better parameters. it doesn't
mean that hosts should then change parameters.

>such as maximum number of configured addresses, maximum number of 

As far as I know, we don't specify the maximum number of address or the
maximum number of routers. In this line of argument, we don't have
to specify the maximum lifetime either.

>router also happens to be the local switch. So if the router dies, 

We talking about an update to all hosts not just the ones behind a CPE.
And worse, there is no way to recover. Currently, if I want to keep
my local network running while replacing the CPE, I can first move hosts
to a separate switch. With your proposal there is nothing the network
operator can do to deal with a router failing.

>IPv4 model where hosts typically configure only one address for each 

You cannot put link local address in DNS. You cannot copy-paste link
local addresses because you don't know what zone ID to use.

Link local addresses have a very limited use case. In practice, link local
address are hardly ever used by applications. There is mDNS, but mDNS 
force people to be aware of whether a service is on the same link or
behind a router. 

I doubt you want to wait with this draft until link local addresses are
common enough in applications.

>such much longer extra time?

Lots of things:
- long compiles using for examples ansible
- people having a lan party
- somebody watching a movie from a local media server.

In all cases, it is bizar to kill local communication just because a router
became unavaliable.

>present in the local subnet anymore).

Assuming that the host got moved to a different switch port, then the
host's default router disappears. The host can treat that as a virtual
link down event and recover that way. I implemented that, it works 
fine, and it works quickly. No need to change valid lifetimes.

The more I think about it, the more I am convinced that we should not break
local communication. So we need to be extremely careful limiting valid
lifetimes.