Subject: [dhcwg] Re: meta thoughts on m/o bits

From: Ralph Droms <[email-masked]>
Date: Fri, 20 May 2005 14:33:38 -0400

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
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Syam Madanapalli <[email-masked]>
Date: Sat, 21 May 2005 00:37:13 +0530

> when a server becomes available.

This may not be efficient for wireless networks where power and
bandwidth are crucial.