Subject: RE: DHCPINFORM

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 30 Mar 2001 10:33:44 -0600

Ted:

The only problem I see is what if there are FUTURE resources other than IP Addresses? That is one reason that we carry address assignment requests in Options.

So, I think this overloading is OK because it is still getting parameters (just that some are allocated and others are not).

I think we can easily state something like: "If a host is not looking for allocated resources (IP addresses) then it may be sufficient to do just Solicit/Advertise (no need to do request/reply)."?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, March 30, 2001 12:25 AM
To: DHCPv6 discussion list
Subject: Re: DHCPINFORM 

> We should clarify what is and is not allowed/expected. Is a
> DHCPSolicit (or DHCPRequest) without an IA basically a DHCPINFORM? Or,
> do we not allow either of these to have no IA?

That's precisely the problem - it doesn't make sense for DHCPSolicit
to be a DHCPINFORM, but it doesn't make sense for DHCPRequest to be
DHCPINFORM either.   I think DHCP Information Request ought to be
seperate, because it's not a four-way handshake.

> Also, wasn't the original purpose to use the DHCPRequest to allow a
> client to get just configuration parameters (no addresses) - when no
> IA?

Yes, but my point is that we're overloading functionality on message
types for no apparent reason.

> Having multiple was to something isn't good, IMHO.

I agree.   Perhaps DHCPsolicit and DHCPrequest should not be valid
without at least one IA option.

> Note with DHCPv4 there was NO way *NOT* to request an address
> without doing DHCPINFORM. With DHCPv6, that problem does not exist (do
> a Solicit or Request without an IA option).

Right, but because of the four-way handshake, the protocol without the
DHCP Information Request message is confusing.   Certainly we can
define things in such a way that a careful read of the standard will
cause an implementor to do the right thing, but it might be better to
just define a seperate message for information requests not related to
IAs, and that way even a careless read of the spec will produce the
right results.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Mar 2001 11:58:23 -0700

> The only problem I see is what if there are FUTURE resources other
> than IP Addresses? That is one reason that we carry address assignment
> requests in Options.

Seems like we could address that when we write this future
specification.

> So, I think this overloading is OK because it is still getting
> parameters (just that some are allocated and others are not).

But there is no need for a four-way handshake for just getting
parameters.

> I think we can easily state something like: "If a host is not
> looking for allocated resources (IP addresses) then it may be
> sufficient to do just Solicit/Advertise (no need to do
> request/reply)."?

Of course.   The question I am raising is, "does this make sense?"
And my answer is "no."   I realize that this is how we have proposed
to do things.   I am asking whether or not it makes sense.   I think
it's confusing.   We could write in the spec that DHCPReconfirm was
just a DHCPRequest with slightly different parameters, but we don't do
that because it's confusing.   This case is similar.

			       _MelloN_