Alain,

        Please see my clarification question below...

--
Eric 

--> -----Original Message-----
--> From: Durand, Alain [mailto:[EMAIL PROTECTED] 
--> Sent: Thursday, October 26, 2006 3:00 PM
--> To: Bernie Volz (volz); James Carlson; Vlad Yasevich
--> Cc: ipv6@ietf.org
--> Subject: RE: address selection and DHCPv6
--> 
--> 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.

        When you say "highest likelihood of stability" - is what 
you really mean "stability is under the control of the entity 
who most feels the consequences of instability"?

        It seems debatable (to me) that an assigned address might 
change many times more often than a derived address, but (it also
seems to me) the entity that controls assignment is also the one 
that has to deal with the consequences...

--> 
-->   - 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; ipv6@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:[EMAIL PROTECTED]
--> > Sent: Thursday, October 26, 2006 12:31 PM
--> > To: Vlad Yasevich
--> > Cc: Durand, Alain; ipv6@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                    
--> > <[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
--------------------------------------------------------------------

Reply via email to