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.
> -----Original Message-----
> From: Lawrence Zou [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 24, 2006 11:41 PM
> To: Durand, Alain; 'James Carlson'; ipv6@ietf.org
> Subject: RE: address selection and DHCPv6
>
> another rule 9?
>
>
>
> Best regards,
>
> Lawrence
>
> >-----Original Message-----
> >From: Durand, Alain [mailto:[EMAIL PROTECTED]
> >Sent: Wednesday, October 25, 2006 10:40 AM
> >To: Lawrence Zou; James Carlson; ipv6@ietf.org
> >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.
> >
> >> -----Original Message-----
> >> From: Lawrence Zou [mailto:[EMAIL PROTECTED]
> >> Sent: Tuesday, October 24, 2006 10:02 PM
> >> To: 'James Carlson'; ipv6@ietf.org
> >> 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 PROTECTED]
> >> >Sent: Wednesday, October 25, 2006 3:52 AM
> >> >To: ipv6@ietf.org
> >> >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 PROTECTED]>
> >> >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 ipv6@ietf.org Administrative
> >> >Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6
> >>
> >--------------------------------------------------------------------
> >> >
> >>
> >>
> >>
> >>
> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6
> >>
> --------------------------------------------------------------------
> >>
> >
>
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
