This has my full support ... I kind of like the idea of one bit to say "run-DHCP if you otherwise wouldn't" but would leave the meaning as simple as that. Those hosts that run DHCP always (because that is how they are 'configured'), would do so.
Note that if this bit is set, it means run FULL 3315 if you're able to and 3736 if you're not. Of course, if there's no DHCP client ... The client won't run either. That way, networks were bandwidth is a expensive or primarily mandate NOT using DHCP (or just stateless DHCP), COULD do so. - Bernie > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Thomas Narten > Sent: Friday, May 20, 2005 1:33 PM > To: dhcwg@ietf.org > Subject: [dhcwg] FWD: meta thoughts on m/o bits > > Forgot to cc the dhc group on this. > > ------- Forwarded Message > > From: Thomas Narten <[EMAIL PROTECTED]> > To: ipv6@ietf.org > Date: Fri, 20 May 2005 13:24:26 -0400 > Subject: meta thoughts on m/o bits > > Stepping up a level (and this also reflects my thinking after a > private exchange with Ralph/Bernie - but not necessarily their > thinking!)... > > I think the M/O bits (in retrospect) have turned out to be more > trouble than they are worth. Indeed, they seem to be mostly just > confusing. Thus, maybe we should work towards removing them > completely. > > In an ideal world, there would be exactly one way for a client to > invoke DHC. That is, it would use the same message exchange to get > "addresses" as it did for "non-address configuration". In such a > world, there would be no need for the M/O bits, since the client would > do the same thing if either one of them were set. > > Unfortunately, we are not quite there, since DHC actually has HCB & > ICB message exchanges (using Ralph's terminology). Thus, there are > scenarios where invoking ICB is preferable over HCB. (Aside note: here > is another example where having two ways to do similar things, results > in undesirable complexity). Currently, we sort of need the M/O bits so > a client can know which variant of DHC to invoke. But, we now also > allow for the possibility of "silly states", i.e., states that aren't > supposed to happen, but can, e.g., through misconfiguration. Having > the M bit set but no addresses available is one such example. > > Ralph has already indicated that with some small changes to the DHC > spec, we might be able to fix the DHC issue so that there is one way > to invoke DHC that does the right thing in all combinations of > addresses and/or other configuration information being available via > DHC. > > If we had that, we wouldn't need two RA bits anymore. At most, a > single "there is stuff to obtain via DHC" bit would suffice. > > Indeed, one could go further and say "just always invoke DHC", and > don't even bother with an RA bit saying DHC is available. That has the > nice property of being simple to implement and you don't have silly > states where the RA bit(s) are configured incorrectly, etc. > > The only advantage I can see right off to having at least 1 RA bit is > to tell the client "there is no DHC server running, so don't even > bother". This would be a performance optimization to allow one to > avoid needing to invoke DHC and have it timeout -- before concluding > that there are no DHC servers. Is this a significant optimization? > Hard to say. > > What I would like to suggest: followup on the above proposed DHC > changes and see if we can actually "fix" DHC to simplify what the > client has to do to invoke it. And if that works, do away with one or > both of the RA bits. > > Remember, simplicity is Good! > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > ------- End of Forwarded Message > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
