In some scenarios there is a danger in the following approach: - hosts boots - looks for DHCP server, doesn't find one - Keeps looking every couple of minutes
This leads to inefficient use of power and network resources in some wireless devices. A more efficient way to do things is to indicate in the RA whether the host should even try to find a DHCP server. I find the current description in 2461/2bis sufficient, dynamic and provides enough granularity to allow hosts to look for what they need (i.e. addresses or "other" config). As a side note, we must not force DHCP to be a default address configuration mechanism in IPv6. Stateless address config actually provides a very useful and timely way of configuring addresses for mobile nodes. Hesham > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of > Ralph Droms > Sent: Friday, May 20, 2005 2:34 PM > To: ipv6@ietf.org; dhcwg@ietf.org > Subject: Re: meta thoughts on m/o bits > > > 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. > > Section 14 of RFC 3315 specifies the retransmission behavior for DHCP > clients. When that behavior is interpreted for Solicit messages in > section 17.1.2, the result is that the DHCP client continues to > retransmit Solicit messages at low frequency (once every 2 minutes) > forever. Therefore, the client will eventually contact the > DHCP service > when a server becomes available. > > - Ralph > > On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > > This proposal looks better and easy to understand. However, > > > if we just rely on timeout for concluding the > unavailabiliy of DHCP server, > > > how does the client re-invoke DHCP if the DHCP server is > available later in > > > time? I think we need one bit to inform the clients about the > > > availabilty of DHCP > > > services in the network. > > > > I would assume that DHC has mechanisms for discovering when DHC > > servers come on line. I.e., the client just sits quietly > in background. > > > > Sure, an RA bit could also signal the availability of a new server, > > but I would first like to be convinced that the existing > default DHC > > mechanism isn't good enough for handling this case (better > not to have > > multiple ways of acheiving the same result). > > > > Thomas > > > > > -------------------------------------------------------------------- > > 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 -------------------------------------------------------------------- =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
