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

List:       ipng
Subject:    Re: rfc3484-bis issue 3: prefer greatest prefix lifetime?
From:       Mark Smith <ipng () 69706e6720323030352d30312d31340a ! nosense ! org>
Date:       2011-06-30 8:28:49
Message-ID: 20110630174649.2bba7811 () opy ! nosense ! org
[Download RAW message or body]

Hi Tim,


On Tue, 28 Jun 2011 15:41:01 +0100
Tim Chown <tjc@ecs.soton.ac.uk> 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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


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