Subject: Address selection - largest preferred lifetime as a tie breaker?

From: Mark Smith <[email-masked]>
Date: Sun, 14 Nov 2010 08:54:40 +1030

Hi,

Geert Hendrickx has posted the following, regarding Linux preferring
most recently updated SLAAC addresses over statically assigned
addresses for source addresses, from within the same /64 prefix, even
thought the preferred lifetime of the static address would be
infinite, and therefore greater than the SLAAC address (presuming the
VPS host hasn't set the preferred lifetime to infinite in the RA PIO,
which is probably likely).

http://lists.cluenet.de/pipermail/ipv6-ops/2010-November/004328.html

I've noticed similar behaviour myself.

RFC3484, and the draft-ietf-6man-rfc3484-revise-01 update, don't seem to
specify that preferred lifetime values should be used as a tie-breaker
with all other things are equal. The only related text I can see in
RFC3484 is -

'Rule 3:  Avoid deprecated addresses.
The addresses SA and SB have the same scope.  If one of the two
source addresses is "preferred" and one of them is "deprecated" (in
the RFC 2462 sense), then prefer the one that is "preferred."'

Should the value of the preferred lifetime of an address, with the
largest value preferred, be used in this case, and only then resort to
using the most recently updated address if preferred lifetimes are
equal?

Thanks,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Mon, 15 Nov 2010 15:29:42 +0000

> using the most recently updated address if preferred lifetimes are

What are the scenarios for differing preferred lifetimes on RAs?    As I recall from renumbering work we did some time ago, following RFC4192, in the 'steady state' with two prefixes in use the preferred lifetimes were set to be the same.     Only when the 'old' prefix was deprecated did we set its preferred lifetime to zero.

Tim

---

From: Mark Smith <[email-masked]>
Date: Tue, 16 Nov 2010 07:06:33 +1030

Hi Tim,

On Mon, 15 Nov 2010 15:29:42 +0000

> What are the scenarios for differing preferred lifetimes on RAs?    As I recall from renumbering work we did some time ago, following RFC4192, in the 'steady state' with two prefixes in use the pre…

I know you've followed the thread on the other mailing list, I'll
summarise it here for others that haven't.

Geert's Virtual Private Server provider is using SLAAC for
autoconfiguring IPv6 addressing on the virtual hosts, possibly for
their own management purposes (e.g. they might track virtual hosts by
periodically scanning the neighbor cache in the RA announcing router) -
possibly they'd use stateful DHCPv6 for that purpose instead if a
client was more easily available for the OS they run on the virtual
hosts. 

To simplify Geert and other customer's DNS and other operations, the VPS
provider is also allocating ranges of static IPv6 addresses to each
customer, within the same /64 being announced in the RA. The U/L bit
would be keeping these static and SLAAC address ranges separate.

So from Geert's perspective, the only addressing to be used, for
both inbound and outbound connections, is the static addresses. The
SLAAC addresses are only for the VPS provider's uses. For the VPS
provider, it is more convenient to use SLAAC, otherwise they'd have
to start having customer's inform them of moves/adds/changes of the
customer static addresses - an administrative overhead that is cheaper
to avoid.

The mismatch in preferred lifetime occurs between the static addresses
and SLAAC addresses within the same /64. Under Linux, and presumably
under other OSes, static addresses by default have infinite preferred
and valid lifetimes. The SLAAC addresses created via RAs would
(probably) have much lower preferred and valid lifetimes. What is
happening is even though the preferred lifetime of the static addresses
is infinite, and therefore should be "infinitely preferred", the newest
configured address, the SLAAC ones, is always preferred over the static
addresses. I'd have expected that the largest preferred lifetime would
always win the as the source address in this situation.

I haven't fully thought it through, however I don't think there would
be any different behaviour if the SLAAC and static addresses were from
within different /64s. If both addresses end up being chosen as
candidate source addresses via the current source address selection
rules, then choosing the most recently (auto)configured would be the
tie breaker. I think in this scenario the largest preferred lifetime
should be used at that point, and only when the candidate addresses
preferred lifetimes are equal does it resort to something like the most
recently configured.

Regards,
Mark.

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