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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 27 May 2005 09:18:14 -0400

Why?

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

Note that this will require changes to 3315 and 3736 - since stateless
servers will need to respond to Solicits with Advertises.

Clients that can do full 3315, would. And, if no stateful DHCPv6 server
is available but a stateless is, it will get "other configuration
parameters".

Clients that only do 3736 would do that and get "other configuration
parameters".

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

These changes would potentially cause some issues with any deployments
today because the clients and servers do not support this "new"
behavior, but it that's why it is critical we work this out ASAP.
However, those clients, if they use the M & O bits, could continue to do
what they do today -- since both bits are available. It is just new
clients with old servers that may have issues.

- Bernie

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Friday, May 27, 2005 9:07 AM
> 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 14:56, Bernie Volz ((volz)) wrote:
> 
> > I think if we come to agreement on having no distinction between the
> > bits, we should deprecate one of the bits (O-bit?); though for  
> > backwards
> > compatibility, we can't remove/reassign it until many years from  
> > now (if
> > ever).
> 
> I think having M = 0, O = 1 would be useful as an indication that  
> clients should use the simplified stateless DHCPv6 rather than the  
> full DHCPv6.
> 
> And I would object to any deprecation on the basis that there isn't  
> enough operational experience to be able to make a good decision.
> 

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

---

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

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

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

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 May 2005 10:42:30 -0700

> servers will need to respond to Solicits with Advertises.

Do we know we can change DHCPv6 that way without causing compatibility 
problems for any existing DHCPv6 clients? I can see such a client not 
expecting configuration information in the advertise message.
Or are we assuming that there are no 3315 DHCP clients out there?

There might also be compatibility issues on the server, since this 
appears to assume that a 3736-only server will handle Solicit messages, 
unless the clients have some logic to fallback from using Solicit to 
using Information-Requests after a few attempts.

    Erik

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 May 2005 08:15:51 -0700

> clients with old servers that may have issues.

I may not have a full sense of the market, but FWIW I don't get the  
impression that backwards compatibility for servers is a huge issue  
at the moment.   So a simplifying change at this point would be a  
good thing.   There have certainly been times in the past when we've  
regretted our failure to make simplifying changes in the DHCP  
protocol back when it wasn't widely deployed.   (Or at least I have -  
I can't really speak for other members of the wg.)