RE: [dhcwg] RE: meta thoughts on m/o bits

2005-05-23 Thread Bound, Jim
; [EMAIL PROTECTED]; > ipv6@ietf.org; [EMAIL PROTECTED]; dhcwg@ietf.org > Subject: Re: [dhcwg] RE: meta thoughts on m/o bits > > John - My understanding is that the selection of SLAAC addresses is > separate from the use of DHCP; that is, a host may be in a scenario in > which it uses

Re: [dhcwg] RE: meta thoughts on m/o bits

2005-05-23 Thread Ralph Droms
John - I agree that in lieu of some failure or otherwise special condition, devices should use the mechanisms built into SLAAC and DHCP (address lifetimes) to control the use and assignment of addresses. I think the DNAv6 work may have some impact on this discussion as providing a more reliable me

Re: [dhcwg] RE: meta thoughts on m/o bits

2005-05-23 Thread Ralph Droms
John - My understanding is that the selection of SLAAC addresses is separate from the use of DHCP; that is, a host may be in a scenario in which it uses both an address chosen through SLAAC and an address assigned through a DHCP message exchange. So, the availability of a SLAAC address should not

Re: [dhcwg] Re: meta thoughts on m/o bits

2005-05-20 Thread Syam Madanapalli
On 5/21/05, Ralph Droms <[EMAIL PROTECTED]> wrote: > Well...DHCPv6 doesn't have any better mechanism for announcing > availability of a server than does DHCPv4 (which is to say "none"). > There has not been an identified need to push an announcement of DHCP > server availability out to clients. > >

Re: [dhcwg] Re: meta thoughts on m/o bits

2005-05-20 Thread Ralph Droms
Small goof in previous message: > > Those assuming a broadcast mechanism is needed may be making the > > assumption that if an admin turns on a DHC server, it is a > > _requirement_ that all nodes start using DHC effectively > > _immediately_. > > > > It is not at all clear to me that this is a r