Hi Bernie, > > => 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? > > This means that the wiresless operators will get more revenue from > Ralph! > > If the wireless operator isn't using DHCP (or only using stateless), > there's no reason they can't charge for that (stateful) traffic.
=> :) I don't want them to charge users for Ralph's implementation :) But seriously, charging is one thing, inefficient use of power is another serious problem which can actually reduce revenue because a device doesn't go dormant long enough and runs out of battery instead of using that battery power for what the user actually wants to do. Hesham > > This is the reason why having one (or two) bits in the RA to indicate > whether DHCP should be run are useful. But, those bits are advisory > only. > > - Bernie > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Soliman, Hesham > > Sent: Friday, May 20, 2005 3:15 PM > > To: Ralph Droms (rdroms) > > Cc: [email protected]; [email protected] > > Subject: RE: meta thoughts on m/o bits > > > > > > > > > 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: [email protected]; [email protected] > > > > > 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 > > > > > > [email protected] > > > > > > Administrative Requests: > > > > https://www1.ietf.org/mailman/listinfo/ipv6 > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > [email protected] > > > > 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 > > [email protected] > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
