Subject: RE: address selection and DHCPv6

From: "Durand, Alain" <[email-masked]>
Date: Tue, 24 Oct 2006 22:39:59 -0400

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. 

> -----Original Message-----
> 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  
> 
> >-----Original Message-----
> >From: James Carlson [mailto:[email-masked]] 
> >Sent: Wednesday, October 25, 2006 3:52 AM
> >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
> --------------------------------------------------------------------
> 

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

---

From: Lawrence Zou <[email-masked]>
Date: Wed, 25 Oct 2006 11:40:34 +0800

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]
>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. 
>
>> 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:
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
>> 
>> >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:
>> >
>> >Administrative Requests:
https://www1.ietf.org/mailman/listinfo/ipv6
>> Administrative Requests:
https://www1.ietf.org/mailman/listinfo/ipv6