Re: address selection and DHCPv6

[Tim Chown <tjc at ecs.soton.ac.uk>]

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:volz at cisco.com] 
> > Sent: Thursday, October 26, 2006 12:37 PM
> > To: James Carlson; Vlad Yasevich
> > Cc: Durand, Alain; ipv6 at ietf.org
> > 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:james.d.carlson at sun.com]
> > Sent: Thursday, October 26, 2006 12:31 PM
> > To: Vlad Yasevich
> > Cc: Durand, Alain; ipv6 at ietf.org
> > 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                    
> > <james.d.carlson at sun.com>
> > 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 at ietf.org
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Tim



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------