Hi Tim,
On Tue, 28 Jun 2011 15:41:01 +0100 Tim Chown <[email protected]> wrote: > The third issue is I think one that Mark Smith raised, and there was some > discussion without a conclusion. > Thanks very much for checking on this. > Do we add a rule between 3 and 4 saying 'Prefer greatest preferred lifetime', > i.e. If the addresses SA and SB both have non-zero value preferred lifetimes > (are "non-deprecated"), prefer the address with the greatest value preferred > lifetime? > > There are some cases where this might be expected behaviour, but there have > been views expressed both ways. > > Comments please. > I raised the specific question of static vs SLAAC on the ipv6-ops operator list under the title "Static vs SLAAC - Static expected to be preferred?". There were a few direct, "yes, that's what I expect" responses. The rest of the discussion seemed to be about increasingly complicated and variety of ways of disabling SLAAC addresses (including disabling receiving RAs completely) on hosts that you want to assign static addresses to. Perhaps their complexity and variety also suggest that configure IPv6 static addresses and having them preferred should be simpler. One possible outcome of the discussion was to change the position of my suggested rule to between rules 7 and 8, as the original position I suggested would make static addresses preferred over privacy (temporary) rules, as privacy addresses would have smaller preferred lifetimes than the typical infinite preferred lifetime of a static address. Thinking about this some more, I've realised that rule 3 is more of a rule to filter out deprecated addresses. It would only result in a final address selection if there is only one preferred address remaining. If there is more than one preferred address after rule 3, then the subsequent rules are the ones that select the actual preferred address to use, based on different address attributes. The attribute that isn't in the current list is the value of the preferred lifetime. I've though that preferred lifetimes that are significantly (dramatically!) greater than RA lifetimes are serving more than the purpose of just aging addresses out, but also expressing a preference for use of that address. This preference idea seemed to me to be supported by the RFC4861 defaults of an RA lifetime of 3 * MaxRtrAdvInterval or 1800 seconds, and a an AdvPreferredLifetime of 604800 seconds. If two prefixes were announced, one with a preferred lifetime of 3600 seconds, and the other with 604800, I'd think the administrator intended the 604800 second prefix to be preferred because it is going to live for far longer. So it seemed to me that the address selection rules should consider the value of the preferred lifetime. By doing so, it also meant that static addresses would win if they were configured, as their preferred lifetime is 'infinite'. Having better understood the purpose of rule 3, I'm now having trouble suggesting where in the subsequent rules that the value of the preferred lifetime should be considered. If it is put in between rule 3 and 4, it means that the subsequent rules are unlikely to ever be applied unless two or more addresses have exactly the same preferred lifetime. I think that is being too restrictive. OTOH, the preferred lifetime value could be used as a tie breaker for the subsequent rules, applied if two or more addresses pass. For example, if there are two Rule 4 home addresses, then preferred lifetime is used to pick one of those, and if they both have the same preferred lifetime, then Rule 5 is evaluated. The drawback of that is that static routes may then not override SLAAC or DHCPv6 learned addresses which was the original goal. Unfortunately I can't see a simple way to use the value of the preferred lifetime in the source address selection process and still achieve preference of static addresses over other types. So perhaps the only way to make static addresses take precedence is just to have a simple "Prefer Static Addresses" rule between Rule 3 and Rule 4. Thanks, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
