Mark, in your case, policy table should be helpful to manipulate source address selection behavior for SLAAC and manually configured addresses.
As the final tie breaker, I do not see much sense to use preferred lifetime for that purpose. Indefinite lifetime does not always mean high preference. Regarding determinacy, it should not be useful when you have multiple SLAAC addresses. Kindest regards, On 2011/04/26, at 15:05, Mark Smith wrote: > Hi, > > I'd like to suggest the a few rules to be inserted between Rules 3 and 4 > of RFC3484 - > > 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." > > Rule 4: Prefer home addresses. > If SA is simultaneously a home address and care-of address and SB is > not, then prefer SA. Similarly, if SB is simultaneously a home > address and care-of address and SA is not, then prefer SB. > If SA is just a home address and SB is just a care-of address, then > prefer SA. Similarly, if SB is just a home address and SA is just a > care-of address, then prefer SB. > > Suggested rule - > > Rule X: Prefer greatest preferred lifetime > 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. > > > An example of where this would help produce better behaviour - > > Geert Hendrickx reported to the ipv6-ops list that his VPS provider > was using SLAAC addresses for their own monitoring, while providing > static IPv6 address ranges within the same /64 for customers to use for > their own purposes, so hosts have both SLAAC addresses and static > addresses. When multiple addresses have a "preferred" status, Linux > chooses the most recently added/configured address. In this VPS > scenario, this meant that outbound connections were using the SLAAC > addresses, despite Geert wanting all outbound connections to use the > static IPv6 addresses. His VPS provider would not allow SLAAC to > switched off. > > With the above suggested rule, the infinite preferred lifetime of the > static addresses verses the (presumably) non-infinite preferred > lifetimes of the SLAAC addresses would cause the static addresses to be > preferred as the source address. > > Related to the above suggested rule, I think there may also need to be > some final last resort tie breaker rule to cover the situation where two > addresses have the same value preferred lifetimes e.g. two static > addresses or a static and SLAAC address with infinite preferred > lifetimes. I think it'd be best to avoid something variable like most > recently added/configured, so possibly something like using the > numerically greatest interface id might be adequate. > > Regards, > Mark. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arif...@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
