Subject: RE: [dhcwg] RE: purpose of m/o bit

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 27 May 2005 12:16:05 -0400

> 1   1   send Solicit               send Information-Request

But what happens if the stateful server is down and stateless is
running? Though I would never recommend that a link have both of these
types of servers.

We could easily resolve this by adjusting the DHCPv6 protocol as
proposed (ie, stateful and stateless servers can respond to Solicit with
Advertise with just other configuration parameters).

Then, if people feel that there is value in having the two bits, all
will work.

Of course, there is the issue that the stateful server is down and later
returns, but I would argue that it would be a BAD idea to run BOTH a
stateful and stateless server on a single link -- run ONE type or the
OTHER; not both!

We really want to communicate three states in terms of the DHCPv6
service available on the link: No DHCPv6, Stateful DHCPv6, and Stateless
DHCPv6 -- not 4. Note that this says nothing about what a client
supports (if the client can only do stateless, that's all it can do!).
Clients would run DHCPv6 unless the "No DHCPv6" is set.

So, perhaps we should deprecate M=1 *AND* O=1. Clients should always run
DHCPv6 if EITHER M = 1 OR O = 1. If M=1, run stateful (if supported,
stateless otherwise). If O=1, run stateless (if supported).

In any case, I would still fix the DHCPv6 protocol to allow Advertises
to return other configuration parameters when no addresses are available
AND to require stateless DHCPv6 servers to support Solicit (with
Advertise with just other configuration parameters).

I still believe deprecating the 2nd bit (O) is better.

- Bernie

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Friday, May 27, 2005 12:02 PM
> To: Bernie Volz (volz)
> Cc: [email-masked]; Ralph Droms (rdroms); 
> [email-masked]; [email-masked]
> Subject: Re: [dhcwg] RE: purpose of m/o bit
> 
> On 27-mei-2005, at 15:18, Bernie Volz ((volz)) wrote:
> 
> > Why?
> 
> Well, why not?
> 
> I'm not too familiar with the internals of DHCPv6, but I can imagine  
> that it would be moderately useful if a client knows in advance  
> whether it's going to do full DHCP and may receive stateful  
> information, or it's only going to obtain some stateless information.
> 
> I'm not sure if we would be designing this today that we'd 
> include an  
> O bit, but it's here, and using it in this way comes 
> reasonably close  
> to its original meaning AND may provide some benefits, so why go  
> through the trouble of doing something radical now?
> 
> > If we update the DHCPv6 protocol to allow "other configuration"  
> > options
> > to be returned in an Advertise for a Solicit, Information-Request/ 
> > Reply
> > and Solicit/Advertise are then essentially the same in a stateless
> > DHCPv6 environment (though the Solicit does require a client  
> > identifier
> > and likely may require a IA_* option).
> 
> So we need to do more protocol work in order to send larger packets  
> so we can get rid of a bit that doesn't bother anyone? Hm...
> 
> > I think if we have two bits, we'll just be back to some of the edge
> > conditions (what if M is set, but O isn't, etc).
> 
> I think I addressed that in my message yesterday, for the most part.  
> If we ignore all other input and just look at the bits, then:
> 
> M   O   stateful clients           stateless clients
> 0   0   do nothing                 do nothing
> 1   0   send Solicit               do nothing
> 0   1   send Information-Request   send Information-Request
> 1   1   send Solicit               send Information-Request
> 
> The compelling advantage here would be that it's possible to run a  
> server that only understands stateless DHCPv6. (I'm assuming 
> that you  
> need a server that implements full DHCPv6 to answer Solicits even if  
> it otherwise only serves up stateless information.)
> 

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 27 May 2005 22:27:39 +0200

> running?

Buy more servers?? Some solutions are simple.  :-)

> Though I would never recommend that a link have both of these
> types of servers.

I would assume that both types of servers wouldn't existing  
alongside. AFAIK, there is no reason that a server that does full  
DHCPv6 couldn't/shouldn't do answer stateless DHCPv6 queries as well.

Only when there is no need for stateful DHCPv6, it would make sense  
to run a light-weight stateless server. For instance, on a  
residential type router.

> Advertise with just other configuration parameters).

Wouldn't that put RFC 3376 out of business?

> DHCPv6 -- not 4.

Ok, I agree with you that those three are needed. I also think the  
fourth one is slightly useful, but that one isn't very imporant.

Do we all agree that no DHCPv6/stateful DHCPv6/stateless DHCPv6 are  
all useful?

> Note that this says nothing about what a client

Right.

> Clients would run DHCPv6 unless the "No DHCPv6" is set.

:-)

> stateless otherwise). If O=1, run stateless (if supported).

It already says in RFC 246x that O = 1 is implied when M = 1. I.e.,  
the useful combinations are:

M = 0, O = 0
M = 0, O = 1
M = 1, O = x

> Advertise with just other configuration parameters).

I'm offering no opinions on that one.

> I still believe deprecating the 2nd bit (O) is better.

Disagree for various reasons. The way I see it, people may be  
interested in implementing clients and servers that just do stateless  
DHCPv6 (RFC 3376). Sure, it's probably doable to make any combination  
of stateful/stateless server and stateful/stateless client do  
something reasonable, but I'm convinced that knowing in advance (by  
virtue of the M = 0, O = 1 combination) on both the server and the  
client that we'll be stateless makes for much simpler implemenations.

It also makes troubleshooting easier: with the O bit present, the M  
bit is a reliable indicator whether or not hosts will take addresses  
from a DCHPv6 server. Without the O bit the M bit is overloaded and  
the only way to determine whether the DHCPv6 server also supplies  
addresses (and possibly messes this job up) is by looking at a DHCPv6  
interaction.

Predictability is a highly regarded commodity in operational  
environments.