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

From: Ralph Droms <[email-masked]>
Date: Fri, 20 May 2005 15:06:03 -0400

No one is suggesting DHCP is the "default address configuration
mechanism".  Let's *please* not go down that discussion path...

More comments in line.

On Fri, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote:
> In some scenarios there is a danger in the following approach:
> - hosts boots
> - looks for DHCP server, doesn't find one
> - Keeps looking every couple of minutes

A client is free to use some other timeout (2 hours instead of 2
minutes?) if it chooses.  See sections 5, 14 and 17.1.2 of RFC 3315.  I
imagine standards bodies for specific environments (3GPP2?) might well
mandate different retransmit timeouts, for example, to conserve
bandwidth or power.

> This leads to inefficient use of power and network resources 
> in some wireless devices. A more efficient way to do things is 
> to indicate in the RA whether the host should even try to find
> a DHCP server. I find the current description in 2461/2bis
> sufficient, dynamic and provides enough granularity to allow
> hosts to look for what they need (i.e. addresses or "other" config).

Yes, a bit indicating whether to expect a DHCP service at all might be
useful ... although I, as an implementor, might be tempted to try the
DHCP service anyway in certain circumstances; suppose there are no
advertised prefixes from which to assign SLAAC addresses?

> As a side note, we must not force DHCP to be a default address 
> configuration mechanism in IPv6. Stateless address config actually
> provides a very useful and timely way of configuring addresses 
> for mobile nodes.
> 
> Hesham
> 
> 
>  > -----Original Message-----
>  > From: [email-masked] [mailto:[email-masked]]On 
>  > Behalf Of
>  > Ralph Droms
>  > Sent: Friday, May 20, 2005 2:34 PM
>  > To: [email-masked]; [email-masked]
>  > Subject: Re: meta thoughts on m/o bits
>  > 
>  > 
>  > 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
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> ===========================================================
> This email may contain confidential and privileged material for the sole use
>  of the intended recipient.  Any review or distribution by others is strictly
>  prohibited.  If you are not the intended recipient please contact the sender
>  and delete all copies.
> ===========================================================

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 20 May 2005 14:50:15 -0400

Hesham

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 23 May 2005 14:48:24 +0200

>> - Keeps looking every couple of minutes

Yes, this would clearly be harmful in cases where hosts both use  
DHCPv6 and stateless autoconfiguration, but no DHCPv6 server is  
available. This especially adds up when there are many hosts on the  
subnet.

> minutes?) if it chooses.

How is this useful? Either I want to know that a DHCPv6 server has  
become available, so waiting 2 hours is way too long, or I don't  
care, so why bother checking in the first place?

The situation where a server broadcasts its existence makes MUCH more  
sense.

But the real question is: how do we know we want to use DHCPv6 in the  
first place? Obviously in many cases the answer is simple: yes, I  
want it all the time, or no, I never want it.

But suppose some networks adopt DHCPv6 in lieu of stateless  
autoconfiguration for reasons that make sense to them (and work  
elsewhere, such as shim6, _may_ make this a somewhat more likely  
situation). It would then make sense for a laptop or similar client  
to have both stateless autoconfiguration and DHCPv6 on board for  
autoconfiguration. However, such a client wouldn't have any idea  
about the availability of either mechanism or their preference. Since  
presumably, DHCPv6 won't be available in many cases, an agnostic host  
wouldn't want to wait for DHCPv6 to fail when stateless autoconfig is  
available. On the other hand, some admins may strongly prefer hosts  
to use DHCPv6, but provide stateless autoconfig as a fallback for  
hosts that don't support DHCPv6. In that case, it would be better to  
ignore stateless autoconfig altogether when DHCPv6 works. The real  
problems start when DHCPv6 is preferred, but there is some kind of  
failure. Obviously the host should use stateless autoconfig in the  
mean time, but it would be useful if it were to switch to DHCPv6 as  
soon as the server becomes available.

So what we really need is a mechanism that says:

- DHCPv6 isn't available so don't bother with it
- DHCPv6 is available, but use stateless autoconfig unless you can't/ 
won't
- DHCPv6 is available and equal to stateless autoconfig, use either  
but no need to use both
- DHCPv6 is available and equal to stateless autoconfig, use both
- DHCPv6 is available and preferred, use it exclusively if you can

Something similar is probably needed for the O flag.

In addition, it would be useful to have some kind of flag that  
indicates that the DHCPv6 server status has changed so hosts should  
refresh their leases and other information.

Obviously all of this can't be accommodated with two bits in RAs. So  
we can:

- forget the whole thing and let the implementers/admins figure it out
- hammer on it until it fits in the m and o bits
- come up with an RA/ND option that has room for all of this

(It would be cool to find a way to integrate DHCPv6 and RAs to some  
degree, though. For instance, by allowing DHCP options in RA options.)