> No one is suggesting DHCP is the "default address configuration > mechanism". Let's *please* not go down that discussion path...
=> some parts of the discussion were hinting at that, that's why I said "side note". I'm glad you're not suggesting that. > > 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. => It's unrealistic to assume that. An SDO might suggest that but how does an implementation know it's in a 3GPP/2 or some other wireless network, or even ethernet? An implementation might just see a PPP driver or an ethernet driver. That says nothing about the underlying technology. > > > 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? => You can try, but my concern is about how often you're going to try. If there are bits that say whether you should try or not and those bits are not set (i.e. no DHCP server in the network), why would you try? Hesham > > > 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 --------------------------------------------------------------------
