Hi Tim, On Mon, 15 Nov 2010 15:29:42 +0000 Tim Chown <t...@ecs.soton.ac.uk> wrote:
> > On 13 Nov 2010, at 22:24, Mark Smith wrote: > > > > 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? > > 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. > 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 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
