> 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 PROTECTED] > Sent: Friday, May 27, 2005 12:02 PM > To: Bernie Volz (volz) > Cc: [EMAIL PROTECTED]; Ralph Droms (rdroms); > dhcwg@ietf.org; ipv6@ietf.org > 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.) > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
