Look, I'm not advocating that every device run DHCPv6. I think we're all on the same page here - we want some indication of whether to run or not run DHCP, but that is only an indication not a hard requirement. I, as the owner/administrator of a device, should be able to explicitly configure the device to either always run DHCP or never run DHCP. If I chose to run it when there is no service available, so be it. If I chose to no run it when there is a service and it is needed for "full" network access, so be it -- my device may have limited access depending on what stateless allows or doesn't allow.
Other than periodic traffic, which in many networks is of no significant consequence (though it *IS* in other networks), there is no harm if you err on the side or running DHCP ALWAYS. If on the other hand you do not run it when it is needed for full access ... There are many heuristics that can be used by devices to "guess" at whether DHCP might be useful to run or not. For example, if there are prefixes advertised but none are stateless, run DHCP. If all advertised prefixes are stateless, don't run DHCP (at least for stateful addresses). And, clients could be smarter about the retransmission algorithms they use -- such as using longer "probe" intervals if they fail to get a response. Or stopping the probes after a period of time. Sure, all of this takes some processing overhead and that's why I think we all feel that having a bit or two bits as hints makes a lot of sense. I believe some people were very concerned if a router is misconfigured. Personally, I don't get that issue at all. If an administrator doesn't configure other things properly, the network may or may not work either. So, why are these bits any different than the hundreds of other parameters and knobs? Perhaps we should be discussing what routers might do to figure out how to automatically determine the setting of these bits or "alarm" if the bit is potentially set incorrectly? One simple rule is if the router is configured to be a relay agent, the bit(s) should be set. (At least if we take DHCPv4 networks as a model, this will likely properly configure a good portion of the routers correctly.) Perhaps the router should periodically probe for a DHCP server (via the link-local multicast address). If one is discovered and the bit(s) are clear, either there is a rogue server on the network OR the bit(s) wasn't configured correctly. If no server responds after some number of attempts and the bit(s) are set, either the server is down (in which case clearing the bit(s) in the RA might not be a big issue until the server returns -- modulo the probe interval) or the bits were set incorrectly and some type of "alarm" is reasonable. - Bernie > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jari Arkko > Sent: Saturday, May 21, 2005 12:57 AM > To: Soliman, Hesham > Cc: [email protected]; [email protected]; Bernie Volz (volz); Ralph > Droms (rdroms) > Subject: Re: meta thoughts on m/o bits > > Soliman, Hesham wrote: > > >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. > > > > > I tend to agree with Hesham that we should attempt to design > our protocols so that unnecessary periodic probing over wireless > is minimized. One thing that should be kept in mind is that most > people want their devices to be always on and reachable, but yet > they might actually use them for something only a very small > fraction of the time. Even a tiny amount of traffic during the > inactive period may thus result in a relatively large impact > when you compare it to actual useful traffic. This in turn > translates to battery lifetimes and cost for the users. > > --Jari > > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
