"Manfredi, Albert E" <[EMAIL PROTECTED]> writes: > > -----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): > >=20 > > 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: > >=20 > > if (RT > MRT) > > RT =3D MRT + RAND*MRT > >=20 > >=20 > > 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. > >=20 > > 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? You seem to be assuming (incorrectly) that getting addresses via DHC is a blocking operation, and everything waits 2 minutes until the DHC step is declared a "failure". That, of course, would be an awful way to implement things. Fortunately, the specification doesn't say to do this. The system invokes DHC, and if/when it provides addresses, they get configured. Same for stateless address autoconf. Both run in parallel. No need to block everything for 2 minutes here in the case there is no DHC server (or no RAs...). Also, this 2 minute timer is a cap on the maximum value of the retransmission timer. It is NOT an indication (from a protocol perspective) that DHC has failed and that the system is supposed to declare "no DHC servers available". AFAIK, DHC doesn't declare "no servers available" and then go into any special mode. Rather, it just continues to retransmit until it gets a response. I.e., until a DHC server becomes available. The way DHC & stateless address autonconfiguration are supposed to be implemented is that both run in parallel and independently of each other. Whenever one provides addresses, you configure them and start using them. You don't have to wait for one operatoin to complete before invoking the other, or anything like that. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
