No one is suggesting DHCP is the "default address configuration mechanism". Let's *please* not go down that discussion path...
More comments in line. On Fri, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote: > 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 A client is free to use some other timeout (2 hours instead of 2 minutes?) if it chooses. See sections 5, 14 and 17.1.2 of RFC 3315. I imagine standards bodies for specific environments (3GPP2?) might well mandate different retransmit timeouts, for example, to conserve bandwidth or power. > 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). Yes, a bit indicating whether to expect a DHCP service at all might be useful ... although I, as an implementor, might be tempted to try the DHCP service anyway in certain circumstances; suppose there are no advertised prefixes from which to assign SLAAC addresses? > 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 --------------------------------------------------------------------
