> -----Original Message----- > From: Thomas Narten [mailto:[EMAIL PROTECTED]
> My understanding is that when clients invoke DHC, and there are no > DHCP servers, they backoff and retransmit, eventually stablizing as is > governed by the following (from RFC 3315): > > MRT specifies an upper bound on the value of RT (disregarding the > randomization added by the use of RAND). If MRT has a value of 0, > there is no upper limit on the value of RT. Otherwise: > > if (RT > MRT) > RT = MRT + RAND*MRT > > > In the case of solicit messages, MRT is set to 120 seconds. RAND is > set to +/- .1, so the RT is capped at between 118 and 122 seconds. > > So, clients will retransmit about once every 2 minutes. This creates a long wait for the user, if his workstation was misconfigured to use DHCP when none is available. Seems like a good reason to keep the M&O flags, just to avoid that long wait? > Did you read my original note carefully? In it, I pointed out that one > concern against trusting the M&O bits was misconfiguration. You may > think this scenario is rare to non-existant, but please acknowledge > that others in the community may view the concern differently than you > -- and indeed, may weigh this concern as more significant than your > concern about additional multicast traffic. It seems more likely that random clients would be misconfigured, though. If the M&O flags are misconfigured, then the situation is not much different from having no flags to begin with. The client would wait some time before giving up, and using autoconfiguration. But in most cases, the client can avoid the agonizingly long waits. Possibly too, a case can be made that the clients' behavior does not need to be uniquely specified by the IETF. "Use stateful addresses when they are available" seems like it could be a viable strategy, without having to incur that long wait to implement it. Bert -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
