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

["Soliman, Hesham" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On 
 > > Behalf Of Soliman, Hesham
 > > Sent: Friday, May 20, 2005 3:15 PM
 > > To: Ralph Droms (rdroms)
 > > Cc: [e-mail]; [e-mail]
 > > 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: [e-mail] 
 > [mailto:[e-mail]]On 
 > >  > >  > Behalf Of
 > >  > >  > Ralph Droms
 > >  > >  > Sent: Friday, May 20, 2005 2:34 PM
 > >  > >  > To: [e-mail]; [e-mail]
 > >  > >  > 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
 > >  > >  > > [e-mail]
 > >  > >  > > Administrative Requests: 
 > >  > > https://www1.ietf.org/mailman/listinfo/ipv6
 > >  > > > 
 > >  > 
 > > 
 > --------------------------------------------------------------------
 > >  > > 
 > >  > > 
 > >  > 
 > > 
 > --------------------------------------------------------------------
 > >  > > IETF IPv6 working group mailing list
 > >  > > [e-mail]
 > >  > > 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
 > > [e-mail]
 > > Administrative Requests: 
https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg