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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 May 2005 14:52:25 -0400

This has my full support ...

I kind of like the idea of one bit to say "run-DHCP if you otherwise
wouldn't" but would leave the meaning as simple as that. Those hosts
that run DHCP always (because that is how they are 'configured'), would
do so.

Note that if this bit is set, it means run FULL 3315 if you're able to
and 3736 if you're not. Of course, if there's no DHCP client ... The
client won't run either.

That way, networks were bandwidth is a expensive or primarily mandate
NOT using DHCP (or just stateless DHCP), COULD do so.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Thomas Narten
> Sent: Friday, May 20, 2005 1:33 PM
> To: [email-masked]
> Subject: [dhcwg] FWD: meta thoughts on m/o bits
> 
> Forgot to cc the dhc group on this.
> 
> ------- Forwarded Message
> 
> From: Thomas Narten <[email-masked]>
> To: [email-masked]
> Date: Fri, 20 May 2005 13:24:26 -0400
> Subject: meta thoughts on m/o bits
> 
> Stepping up a level (and this also reflects my thinking after a
> private exchange with Ralph/Bernie - but not necessarily their
> thinking!)...
> 
> I think the M/O bits (in retrospect) have turned out to be more
> trouble than they are worth. Indeed, they seem to be mostly just
> confusing. Thus, maybe we should work towards removing them
> completely.
> 
> In an ideal world, there would be exactly one way for a client to
> invoke DHC. That is, it would use the same message exchange to get
> "addresses" as it did for "non-address configuration". In such a
> world, there would be no need for the M/O bits, since the client would
> do the same thing if either one of them were set.
> 
> Unfortunately, we are not quite there, since DHC actually has HCB &
> ICB message exchanges (using Ralph's terminology). Thus, there are
> scenarios where invoking ICB is preferable over HCB. (Aside note: here
> is another example where having two ways to do similar things, results
> in undesirable complexity). Currently, we sort of need the M/O bits so
> a client can know which variant of DHC to invoke. But, we now also
> allow for the possibility of "silly states", i.e., states that aren't
> supposed to happen, but can, e.g., through misconfiguration. Having
> the M bit set but no addresses available is one such example.
> 
> Ralph has already indicated that with some small changes to the DHC
> spec, we might be able to fix the DHC issue so that there is one way
> to invoke DHC that does the right thing in all combinations of
> addresses and/or other configuration information being available via
> DHC.
> 
> If we had that, we wouldn't need two RA bits anymore. At most, a
> single "there is stuff to obtain via DHC" bit would suffice.
> 
> Indeed, one could go further and say "just always invoke DHC", and
> don't even bother with an RA bit saying DHC is available. That has the
> nice property of being simple to implement and you don't have silly
> states where the RA bit(s) are configured incorrectly, etc.
> 
> The only advantage I can see right off to having at least 1 RA bit is
> to tell the client "there is no DHC server running, so don't even
> bother". This would be a performance optimization to allow one to
> avoid needing to invoke DHC and have it timeout -- before concluding
> that there are no DHC servers. Is this a significant optimization?
> Hard to say.
> 
> What I would like to suggest: followup on the above proposed DHC
> changes and see if we can actually "fix" DHC to simplify what the
> client has to do to invoke it. And if that works, do away with one or
> both of the RA bits.
> 
> Remember, simplicity is Good!
> 
> Thomas
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> ------- End of Forwarded Message
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

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

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

=> some parts of the discussion were hinting at that, that's 
why I said "side note". I'm glad you're not suggesting that.

 > 
 > 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.

=> It's unrealistic to assume that. An SDO might suggest that but
how does an implementation know it's in a 3GPP/2 or some other 
wireless network, or even ethernet? An implementation might just 
see a PPP driver or an ethernet driver. That says nothing about 
the underlying technology.

 > 
 > > 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?

=> You can try, but my concern is about how often you're going to try.
If there are bits that say whether you should try or not and those 
bits are not set (i.e. no DHCP server in the network), why would you try?

Hesham

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 May 2005 15:26:16 -0400

> bits are not set (i.e. no DHCP server in the network), why 
 
This means that the wiresless operators will get more revenue from
Ralph!

If the wireless operator isn't using DHCP (or only using stateless),
there's no reason they can't charge for that (stateful) traffic.

This is the reason why having one (or two) bits in the RA to indicate
whether DHCP should be run are useful. But, those bits are advisory
only.

- Bernie

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Soliman, Hesham
> Sent: Friday, May 20, 2005 3:15 PM
> To: Ralph Droms (rdroms)
> Cc: [email-masked]; [email-masked]
> Subject: RE: meta thoughts on m/o bits
> 
> 
>

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 21 May 2005 09:21:28 -0400

Look, I'm not advocating that every device run DHCPv6. I think we're all
on the same page here - we want some indication of whether to run or not
run DHCP, but that is only an indication not a hard requirement. I, as
the owner/administrator of a device, should be able to explicitly
configure the device to either always run DHCP or never run DHCP. If I
chose to run it when there is no service available, so be it. If I chose
to no run it when there is a service and it is needed for "full" network
access, so be it -- my device may have limited access depending on what
stateless allows or doesn't allow.

Other than periodic traffic, which in many networks is of no significant
consequence (though it *IS* in other networks), there is no harm if you
err on the side or running DHCP ALWAYS. If on the other hand you do not
run it when it is needed for full access ...

There are many heuristics that can be used by devices to "guess" at
whether DHCP might be useful to run or not. For example, if there are
prefixes advertised but none are stateless, run DHCP. If all advertised
prefixes are stateless, don't run DHCP (at least for stateful
addresses). And, clients could be smarter about the retransmission
algorithms they use -- such as using longer "probe" intervals if they
fail to get a response. Or stopping the probes after a period of time. 

Sure, all of this takes some processing overhead and that's why I think
we all feel that having a bit or two bits as hints makes a lot of sense.

I believe some people were very concerned if a router is misconfigured.
Personally, I don't get that issue at all. If an administrator doesn't
configure other things properly, the network may or may not work either.
So, why are these bits any different than the hundreds of other
parameters and knobs?

Perhaps we should be discussing what routers might do to figure out how
to automatically determine the setting of these bits or "alarm" if the
bit is potentially set incorrectly?

One simple rule is if the router is configured to be a relay agent, the
bit(s) should be set. (At least if we take DHCPv4 networks as a model,
this will likely properly configure a good portion of the routers
correctly.)

Perhaps the router should periodically probe for a DHCP server (via the
link-local multicast address). If one is discovered and the bit(s) are
clear, either there is a rogue server on the network OR the bit(s)
wasn't configured correctly. If no server responds after some number of
attempts and the bit(s) are set, either the server is down (in which
case clearing the bit(s) in the RA might not be a big issue until the
server returns -- modulo the probe interval) or the bits were set
incorrectly and some type of "alarm" is reasonable.

- Bernie

> Behalf Of Jari Arkko
> Sent: Saturday, May 21, 2005 12:57 AM
> To: Soliman, Hesham
> Cc: [email-masked]; [email-masked]; Bernie Volz (volz); Ralph 
> Droms (rdroms)
> Soliman, Hesham wrote:
> >Hi Bernie, 
> >=> :) I don't want them to charge users for Ralph's implementation :)
> >But seriously, charging is one thing, inefficient use of power is 
> >another serious problem which can actually reduce revenue because
> >a device doesn't go dormant long enough and runs out of battery 
> >instead of using that battery power for what the user actually wants
> >to do.
> >  
> >
> I tend to agree with Hesham that we should attempt to design
> our protocols so that unnecessary periodic probing over wireless
> is minimized. One thing that should be kept in mind is that most
> people want their devices to be always on and reachable, but yet
> they might actually use them for something only a very small
> fraction of the time. Even a tiny amount of traffic during the
> inactive period may thus result in a relatively large impact
> when you compare it to actual useful traffic. This in turn
> translates to battery lifetimes and cost for the users.
> 
> --Jari
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 23 May 2005 08:53:12 -0400

This is my understanding too and the way it should be implemented too.
/jim 

> Behalf Of Ralph Droms
> Sent: Monday, May 23, 2005 7:47 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [dhcwg] RE: meta thoughts on m/o bits
> 
> John - My understanding is that the selection of SLAAC addresses is
> separate from the use of DHCP; that is, a host may be in a scenario in
> which it uses both an address chosen through SLAAC and an address
> assigned through a DHCP message exchange.  So, the availability of a
> SLAAC address should not affect the use of DHCP.
> 
> - Ralph
> 
> On Mon, 2005-05-23 at 12:24 +0300, [email-masked] wrote: 
> > Jari & Hesham,
> > 
> > Basically, what I think we'd like is that if a device has a working
> > address and is 'attached' to a network, it should probably use that
> > address and only probe upon some failure event.  When the device
> > shows up to a new network, it can probe and if it gets a 
> DHCP address,
> > then use it, and update the address before the lease expires.  If
> > the device gets a valid address via autoconfig, then it 
> should continue
> > to use that.  It doesn't make much sense that a node should 
> continually
> > verify if it should use a DHCP address if it has an 
> otherwise working
> > address.
> > 
> > Note that many applications will run sometime of watchdog 
> or heartbeat
> > to ensure that application is still alive on both ends.  If 
> this fails,
> > that might be a clue to check if the IP address is still valid.  I
> > agree that having probing at multiple layers is a bad design, IMO.
> > 
> > John
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 23 May 2005 08:57:41 -0400

I don't know what is complex here this is all obvious today with current
wording. Even if DHCPv6 is used for addresses, statless is still
required as a note too.  This is not an implementation problem I see at
all.  

Of those speaking how many of you when writing your code got stuck and
that might help this discussion?  This has been going on to long.

Our specs need to work whether someone uses them or not that is not our
job here.  

thanks
/jim 

> Behalf Of Iljitsch van Beijnum
> Sent: Monday, May 23, 2005 8:48 AM
> To: Ralph Droms
> Cc: [email-masked]; IETF IPv6 Mailing List
> On 20-mei-2005, at 21:06, Ralph Droms wrote:
> 
> 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.)
>