Indeed. A changing privacy address can be assigned by DHCP for example. On Thu, Oct 26, 2006 at 03:00:29PM -0400, Durand, Alain wrote: > 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. > > - Alain. > > > -----Original Message----- > > From: Bernie Volz (volz) [mailto:[EMAIL PROTECTED] > > Sent: Thursday, October 26, 2006 12:37 PM > > To: James Carlson; Vlad Yasevich > > Cc: Durand, Alain; [email protected] > > Subject: RE: address selection and DHCPv6 > > > > Whatever technique you use will likely never guarantee a > > completely stable address. > > > > Manually assigned is just as good (or bad) as DHCPv6 because > > both depend on some type of stable storage (so yes there is > > hardware associated with it). (Well, I guess you could always > > rely on a human to type in the manually assigned address on a > > boot but that is unlikely to be desirable and may not be as reliable). > > > > - Bernie > > > > -----Original Message----- > > From: James Carlson [mailto:[EMAIL PROTECTED] > > Sent: Thursday, October 26, 2006 12:31 PM > > To: Vlad Yasevich > > Cc: Durand, Alain; [email protected] > > Subject: Re: address selection and DHCPv6 > > > > Vlad Yasevich writes: > > > The concept that a DHCP address is more stable then > > > EUI64 base address is flawed in my opinion. Both depend on > > a piece of > > > hardware that can fail or be changed. > > > > That's incorrect. See RFC 3315 -- DUIDs are required to be > > stable, even if the hardware is changed. > > > > > I guess manually configured addresses are a bit more stable. > > > > Indeed. > > > > > The rules as specified now tend to be agnostic more or less. They > > > would work no matter how things are set up. > > > (there are exceptions, such as ULA). > > > > More or less? I don't think the temporary address decision > > is a small matter, and I do think this issue is related to that one. > > > > > Of course, implementations may override Rule 8 (longest > > prefix match) > > > with something better/different. I wouldn't object as strongly to > > > something like this: > > > > > > 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 or knows relative stability > > of addresses > > > and wants to select a more stable one. > > > > I'm no longer quite convinced that this sort of thing is right. > > Placing it above rule 8 means that prefix routing issues are ignored. > > > > It seems to want to go below rule 8 in priority order. But I > > guess I could still go along with that as a compromise. > > > > -- > > 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 > --------------------------------------------------------------------
-- Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
