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; [email protected] >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'; [email protected] >> 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: [email protected] >> >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 >> >[email protected] >> >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> >-------------------------------------------------------------------- >> > >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
