Subject: RE: address selection and DHCPv6

From: "Durand, Alain" <[email-masked]>
Date: Tue, 24 Oct 2006 21:44:04 -0400

I like your rule7bis algorithm.
When RFC3484 was discussed, it was clear that it will need to be
revisited
over time to cover new types of addresses or new use cases.

   - Alain.

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]] 
> Sent: Tuesday, October 24, 2006 3:52 PM
> To: [email-masked]
> Subject: address selection and DHCPv6
> 
> I've done quite a bit of searching over the archives and over 
> various web resources, but I haven't seen this issue 
> addressed directly.
> Apologies if I've just missed it.
> 
> RFC 3484 ("Default Address Selection for Internet Protocol version 6
> (IPv6)") section 5 gives a set of ordered comparisons for 
> source address selection.  However, missing from this list is 
> a distinction implied by RFCs 2461 and 2462: some systems may 
> have a mix of addresses acquired by stateless address 
> autoconfiguration, stateful
> (DHCPv6) configuration, and manual addressing.  How are these 
> distinguished?
> 
> Rule 7 does address the temporary (RFC 3041) addresses, but 
> what about these other flavors of addresses?  Are they 
> distinguished only by scope?
> 
> Was this issue addressed and intentionally omitted from the 
> RFC?  (If so, I don't see it in the archives.)
> 
> I suspect that some clients may need to distinguish among the 
> various flavors here.  I'd suggest amending Rule 7 to read:
> 
>    Rule 7:  Prefer stable, public addresses.
>    If SA is a manually-configured address and SB is automatic or
>    temporary, then prefer SA.  If SA is automatically configured via
>    stateful (DHCPv6) methods and SB is automatically configured via
>    stateless methods or temporary, then prefer SA.  If SA is
>    automatically configured via stateless methods and SB is temporary,
>    prefer SA.
> 
>    Similarly, if SB is a manually-configured address and SA is not,
>    then prefer SB.  If SB is stateful and SA is stateless or
>    temporary, prefer SB.  If SB is stateless and SA is temporary,
>    prefer SB.
> 
>    When the application has the "prefer temporary address" flag
>    enabled, all temporary addresses are (within this rule) elevated in
>    preference above manually-configured addresses.  The other
>    preferences are unaltered.  (In other words, the preference order
>    with this flag set becomes temporary first, then manual, stateful,
>    and stateless last.)
> 
> ... or, to simplify, defining a "stability_of_address(A)" 
> function that can work here.
> 
> -- 
> James Carlson, KISS Network                    
> <[email-masked]>
> Sun Microsystems / 1 Network Drive         71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 25 Oct 2006 01:35:28 -0400

Actually, I would say a variation of rule 8:

   Rule 8 may be superseded if the implementation has other means of
   choosing among source addresses.  For example, if the implementation
   somehow knows which source address will result in the "best"
   communications performance.

     - Alain. 

> From: Lawrence Zou [mailto:[email-masked]] 
> Sent: Tuesday, October 24, 2006 11:41 PM
> To: Durand, Alain; 'James Carlson'; [email-masked]
> Subject: RE: address selection and DHCPv6
> 
> another rule 9?
> 
> 
> 
> Best regards,
> 
> Lawrence  
> 
> >From: Durand, Alain [mailto:[email-masked]]
> >Sent: Wednesday, October 25, 2006 10:40 AM
> >To: Lawrence Zou; James Carlson; [email-masked]
> >Subject: RE: address selection and DHCPv6
> >
> >Lawrence,
> >
> >You have a point...
> >For this to work, we may have to do it after the longest 
> prefix match 
> >rule, but limit the match to the upper 64 bits.
> >
> >  - Alain. 
> >
> >> From: Lawrence Zou [mailto:[email-masked]]
> >> Sent: Tuesday, October 24, 2006 10:02 PM
> >> To: 'James Carlson'; [email-masked]
> >> Subject: RE: address selection and DHCPv6
> >> 
> >> I don't think we should amending rule 7 in such a way.
> >>  in fact , i think this will make the rule 8 unworkable.
> >> according to RFC3484,when at last we have two source address 
> >> available,both can pass rule1-rule7,then,the rule 8 will chose the 
> >> longest match prefix.but if we amend rule 7 and prefer 
> >> manul-configured address,some thing changed,for example:
> >> address A is autoconfigured  and belong to ISP1,host use it
> >to access
> >> network of ISP1.
> >> address B is manuconfigured and belong to ISP2,host use it to
> access 
> >> network of ISP2.
> >> then if we prefer manuconfigured address ,we will chose address B
> as 
> >> source when we access ISP1,that maybe refused by the PE
> >router of ISP1
> >> for the reason of soure address filter.
> >> 
> >> 
> >> Best regards,
> >> 
> >> Lawrence
> >> 
> >> >Sent: Wednesday, October 25, 2006 3:52 AM
> >> >To: [email-masked]
> >> >I've done quite a bit of searching over the archives and
> >over various
> >> >web resources, but I haven't seen this issue addressed directly.
> >> >(IPv6)") section 5 gives a set of ordered comparisons for source 
> >> >address selection.  However, missing from this list is a
> >distinction
> >> >implied by RFCs 2461 and 2462: some systems may have a mix of 
> >> >addresses acquired by stateless address autoconfiguration,
> stateful
> >> >Rule 7 does address the temporary (RFC 3041) addresses, but what 
> >> >about these other flavors of addresses?  Are they
> >distinguished only
> >> >by scope?
> >> >
> >> >I suspect that some clients may need to distinguish among
> >the various
> >> >flavors here.  I'd suggest amending Rule 7 to read:
> >> >
> >> >   enabled, all temporary addresses are (within this rule)
> elevated
> >> in
> >> >IETF IPv6 working group mailing list [email-masked] Administrative 
> >> >Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6
> >>
> >> Administrative Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6
> >>

---

From: "Durand, Alain" <[email-masked]>
Date: Thu, 26 Oct 2006 16:38:14 -0400

> From: Gray, Eric [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 4:27 PM
> To: Durand, Alain
> Cc: [email-masked]; James Carlson; Vlad Yasevich
> --> The question is not to get an absolutely stable address, 
> but to make 
> --> sure that in case multiple addresses are defined, the one 
> with the 
> --> highest likelyhood of stability is selected.
> 
> 	When you say "highest likelihood of stability" - is 
> what you really mean "stability is under the control of the 
> entity who most feels the consequences of instability"?

Yes, this is a good way to articulate this.

  - Alain.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 26 Oct 2006 17:00:37 -0400

But, in these cases both addresses are stateless so using how the
address was assigned would still not resolve the issue.

So, that is a related, but separate issue?

Probably the only solution to that is to have some stickiness factor
where a host continues to favor that address for a period of time. An
easy solution may simple by to divide the perferred lifetime by some
factor and compare those. That way, small changes in the preferred
lifetime don't alter the result.

- Bernie

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Thursday, October 26, 2006 4:48 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: address selection and DHCPv6

Bernie Volz (volz) wrote:
> I would think that how an address is assigned shouldn't enter into
this.
> I can't see that it matters.
> 
> What really matters is the lifetimes associated with the address. The
> longest lifetime address is probably the best to use since it is the
> most stable. [Ignoring privacy and other related issues.]

That's sort of what I thought at first as well. But if you use remaining
lifetime (and not the initial) you might easily end up in situations
where you fluctuate between several addresses. Not so good.

As an example, imagine two routers regularly sending RAs for one prefix
each, then you might end up always using the prefix you last got an RA
for, possibly changing every few seconds depending on the adv. rate.

Stig

> 
> Perhaps this gets at what you want anyway, since manually assigned
> addresses would presumable have the longest lifetime? 
> 
> - Bernie 
> 
> From: Manfredi, Albert E [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 3:06 PM
> To: Durand, Alain
> Cc: [email-masked]
> Except that from what others have said, that might not be the desired
> goal. Perhaps for privacy or other reasons, a most stable address
choice
> might not be optimal.
> 
> I originally thought that would be the best choice, but ...
> 
> Bert
> 
> 
> 
>>Sent: Thursday, October 26, 2006 2:00 PM
>>To: Bernie Volz (volz); James Carlson; Vlad Yasevich
>>Cc: [email-masked]
>>The question is not to get an absolutely stable address,
>>but to make sure that in case multiple addresses are defined,
>>the one with the highest likelyhood of stability is selected.
> 
>