Hi Arifumi, On Tue, 26 Apr 2011 20:15:31 +0900 Arifumi Matsumoto <arif...@nttv6.net> wrote:
> Mark, > > in your case, policy table should be helpful to manipulate source > address selection behavior for SLAAC and manually configured > addresses. > True, although that requires actively changing the default policy. > 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. I'm not sure I agree. If I think about the thought process of choosing a particular value for a preferred lifetime, it seems to me that the more you prefer an address, the larger you set the preferred lifetime. An infinite preferred lifetime therefore indicates you want the address to be preferred infinitely. That seems to be consistent with static addresses having infinite preferred and valid lifetimes by default, where as dynamic addresses usually have lower preferred lifetime values. You usually configure static addresses with the intention that they'll be used in preference over to anything else. I think that would be the common expectation of people, yet Linux isn't doing that. However, there doesn't seem to be any rules in RFC3484 that either directly or indirectly makes static addresses preferred over any others. I can see some logic in what Linux is doing, although I don't think this behaviour is described and specified in RFC3484. It seems to be taking the view that the most recently updated information is the most preferred. I think the drawback of that is that fundamentally it is incorporating into the address selection process attributes that aren't specifically address attributes - it is now including how recently the addresses were updated, which in the case of SLAAC addresses means that RA announcement intervals also now have an influence over address selection. If these sorts of address configuration source related attributes were intended to be incorporated into the address selection, then I'd be expecting there'd be rules that specify preference between static, stateful and stateless address configuration sources, and tie breakers within them e.g. router preference in RAs when there are two stateless address configuration sources (i.e. two routers). I think we'd end up with far more rules than exist now if address configuration source attributes were to be intentionally incorporated into the address selection process. So in an update to RFC3484, I'd be seeking some more specific and defined default behavior for when multiple addresses are "non-deprecated". It seems to me that the amount of preference, indicated by the current value of the preferred lifetime would be a fairly simple way to achieve that and be applicable to a number of common scenarios, such as static vs SLAAC, or SLAAC vs SLAAC. > Regarding determinacy, it should not be useful when > you have multiple SLAAC addresses. > I think from a troubleshooing point of view it can be. It is my current expectation to be able to look at a range of current addresses on an interface and be able to be able to predict quite accurately in most cases, based on knowing the default set of address selection rules, the address that is going to be used for new outbound connections. Best regards, Mark. > 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 --------------------------------------------------------------------
