Subject: Suggestion for draft-ietf-6man-rfc3484-revise-02 - use current preferred value as a tie breaker

From: Mark Smith <[email-masked]>
Date: Tue, 26 Apr 2011 15:35:58 +0930

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.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 26 Apr 2011 20:15:31 +0900

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:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
Arifumi Matsumoto
  NGN System Architecture Project
  NTT Service Integration Laboratories
  E-mail: [email-masked]
  TEL +81-422-59-3334 FAX +81-422-59-6364

---

From: Mark Smith <[email-masked]>
Date: Wed, 27 Apr 2011 07:47:30 +0930

Hi Arifumi,

On Tue, 26 Apr 2011 20:15:31 +0900

> address selection behavior for SLAAC and manually configured

True, although that requires actively changing the default policy.

> 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

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.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 27 Apr 2011 15:43:33 +0900

Mark,

> True, although that requires actively changing the default policy.

If the manually configured address is static, you need not change
the policy so often.

> directly or indirectly makes static addresses preferred over any

I do not think it is usual or common expectation that a manually
configured address should have higher preference over a SLAAC
address.

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.

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.

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

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

Regards,

---

From: Mark Smith <[email-masked]>
Date: Wed, 27 Apr 2011 20:55:50 +0930

Hi Arifumi,

On Wed, 27 Apr 2011 15:43:33 +0900

> If the manually configured address is static, you need not change

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.

> configured address should have higher preference over a SLAAC

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.

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

> preference for that purpose is messing things up, in that it is intended

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.

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