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 --------------------------------------------------------------------
