Well...DHCPv6 doesn't have any better mechanism for announcing availability of a server than does DHCPv4 (which is to say "none"). There has not been an identified need to push an announcement of DHCP server availability out to clients.
Section 14 of RFC 3315 specifies the retransmission behavior for DHCP clients. When that behavior is interpreted for Solicit messages in section 17.1.2, the result is that the DHCP client continues to retransmit Solicit messages at low frequency (once every 2 minutes) forever. Therefore, the client will eventually contact the DHCP service when a server becomes available. - Ralph On Fri, 2005-05-20 at 13:53 -0400, Thomas Narten wrote: > > 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. > > I would assume that DHC has mechanisms for discovering when DHC > servers come on line. I.e., the client just sits quietly in background. > > Sure, an RA bit could also signal the availability of a new server, > but I would first like to be convinced that the existing default DHC > mechanism isn't good enough for handling this case (better not to have > multiple ways of acheiving the same result). > > 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 --------------------------------------------------------------------
