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.
On 5/20/05, Thomas Narten <[EMAIL PROTECTED]> wrote: > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
