[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: slaac-renum: Valid Lifetimes
From:       Philip Homburg <pch-ipv6-ietf-6 () u-1 ! phicoh ! com>
Date:       2020-04-05 11:30:09
Message-ID: m1jL3Te-0000NiC () stereo ! hq ! phicoh ! net
[Download RAW message or body]

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

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.

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

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.

>> In particular, I can imagine that some people may want long lifetimes to
>> 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.

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.

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

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.

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

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.

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

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.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]