Subject: RE: address selection and DHCPv6

From: "Durand, Alain" <[email-masked]>
Date: Thu, 26 Oct 2006 15:00:29 -0400

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-masked]] 
> Sent: Thursday, October 26, 2006 12:37 PM
> To: James Carlson; Vlad Yasevich
> Cc: Durand, Alain; [email-masked]
> 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-masked]]
> Sent: Thursday, October 26, 2006 12:31 PM
> To: Vlad Yasevich
> Cc: Durand, Alain; [email-masked]
> 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-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: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 26 Oct 2006 15:06:24 -0400

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

> From: Durand, Alain [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 2:00 PM
> To: Bernie Volz (volz); James Carlson; Vlad Yasevich
> Cc: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Fri, 27 Oct 2006 09:36:19 +0100

Indeed.   A changing privacy address can be assigned by DHCP for example.

-- 
Tim