Hi Arifumi,

On Wed, 27 Apr 2011 15:43:33 +0900
Arifumi Matsumoto <arifumi@nttv6.net> wrote:

> Mark,
> 
> On 2011/04/27, at 7:17, Mark Smith wrote:
> 
> > Hi Arifumi,
> > 
> > On Tue, 26 Apr 2011 20:15:31 +0900
> > Arifumi Matsumoto <arifumi@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.
> 
> If the manually configured address is static, you need not change
> the policy so often.
> 

In most cases, I think that IPv6 should be as at least as easy to
operate IPv4, and hopefully much easier. So I and I think most people
would think that configuring an IPv6 static address should be as easy
as it is in IPv4, involving no more than specifying the address and the
interface. As people seem to be commonly using static IPv6 addresses
for servers and servers are quite common, I think having both IPv4 and
IPv6 static address configuration involve equivalent effort would be
very useful.


> >> 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 do not think it is usual or common expectation that a manually
> configured address should have higher preference over a SLAAC
> address.
> 

I provided at least one example where somebody had that expectation, and
I have the same expectation. None of the people in the thread of
conversation (which I originally intended to link to, apologies for
not doing so) ever disputed that static's shouldn't override the SLAAC
addresses.

Here is the thread -

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

or in long form -

http://www.gossamer-threads.com/lists/nsp/ipv6/26148


Thinking about it in more detail, the only time I ever go to the
additional effort of overriding an automated mechanism (such as SLAAC
in this case) is when it has an operational property that I find
undesirable. People go to an additional effort when they configure
static addresses in the presence of SLAAC addressing, so I'd be
confident they want those static addresses to normally be preferred
over the SLAAC addressing.

I'll send a query to the ipv6-ops list just to see if this is a common
expectation.


> Sometimes I have a case where I want to use static address for
> receiving sessions, and a dynamically assigned address for
> outgoing sessions. In this case, your suggested lifetime rule
> always chooses an unexpected address.
> 

It wouldn't if you specified the preferred lifetime of your
static address to zero, leaving the valid lifetime at infinity. For
outbound connections the SLAAC address would be preferred because it's
preferred lifetime is greater than the static's, while the static
address would continue to be valid for incoming connections.

> If I want to use a manually configured address,
> usually I would turn of SLAAC for that specific interface.
> Your case of VPS seems to me really specific to your site. And
> such kind of site local policy should be implemented using the
> policy table.
>
> > 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'm not sure agree that there should be a default rule for prioritizing
> static, stateful, stateless addresses. However, I believe using router
> preference for that purpose is messing things up, in that it is intended
> for routing purpose. 
> 

I don't think it is a good idea either. Source and destination address
selection is already somewhat complicated to understand, in comparison
to IPv4, so adding preferences of sources and timeliness of
configuration information would make it far more complicated.

> > 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. 
> > 
> 
> As I mentioned above,
> I see some sense to define address type dependent prioritization,
> but lifetime should not be used for that purpose.
> 

I can't really think of any cases where using preferred lifetime in my
suggested manner would cause any problems, and I've been thinking
about this occasionally since when that original discussion occurred
back in November 2010. So I'm not sure why using the value of the
preferred lifetime in this manner would be an issue.

Thanks,
Mark.

> Regards,
> 
> > 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: arifumi@nttv6.net
> >> TEL +81-422-59-3334 FAX +81-422-59-6364
> >> 
> 
> 
> --
> Arifumi Matsumoto
>  NGN System Architecture Project
>  NTT Service Integration Laboratories
>  E-mail: arifumi@nttv6.net
>  TEL +81-422-59-3334 FAX +81-422-59-6364
>