Subject: RE: [dhcwg] Valid states for use of DHCPRELEASE?

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 2 Jan 2004 09:54:49 -0800

yes, of course, but it is not a very interesting state:  once the client
transitions to the STOPPED state, nothing else will happen.  The intended
behavior of a DHCP client was for it to be persistent because it was
expected to request (and be offered) a lease with a limited lifetime that
would be periodically renewed by the client.  That mechanism ceases to
function if the client goes to a STOPPED state.

--Barr

> -----Original Message-----
> From: Kevin A. Noll
> Sent: Tuesday, December 30, 2003 20:23
> To: [email-masked]
>
> Could I also claim that an additional state could be
> added to the client state machine (call it "STOPPED") that
> the client transitions to after sending a DHCPRELEASE?
>
> The assumption would be that the STOPPED state would be
> associated with a graceful shutdown of the system or with
> some external process that caused the client to RELEASE. If
> this is the case, then STOPPED would be a final state (like
> INIT or INIT-REBOOT are the beginning states).
>

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Jan 2004 14:09:55 -0600

On Jan 2, 2004, at 11:54 AM, Barr Hibbs wrote:
> transitions to the STOPPED state, nothing else will happen.

Until something changes.   You don't leave the STOPPED state without 
the system's or user's intervention, but that's not to say that you 
never leave that state.   In any case, it's an interesting state if 
only in the sense that every client I've ever used supports it, even 
though it's never documented in RFC2131.   :')

---

From: "Kevin A. Noll" <[email-masked]>
Date: Sun, 04 Jan 2004 21:12:51 -0500

I'm a little unclear on the delivery of ACK and NAK to the client in
specific situations.

If the client is in the REQUESTING state, we assume that the client is not
yet fully configured and send the DHCPACK as a broadcast if the broadcast
flag is set and unicast if the flag is cleared.

In the REQUESTING state we send DHCPNAK as a broadcast since there is no
other valid way to deliver the message.

If the client is in the RENEWING state both DHCPACK and DHCPNAK can be
delivered as unicast since the client is fully configured.

If the client is in the REBINDING state, how are the ACK and NAK delivered?

Section 4.1 of 2131 seems to indicate that an ACK or NAK would be unicast
in the REBINDING state since ciaddr would be non-zero. Is this correct?

No other sections seem to address this particular aspect of REBINDING even
though similar questions are addressed for the other states.

Similarly, how should the ACK and NAK be delivered if the client is in
INIT-REBOOT or REBOOTING state? Would the ACK be delivered based on the
broadcast flag and a NAK would be broadcast?

I am specifically interested in delivery *to the client*. Obviously the
server will change its behavior based on contents of giaddr, ciaddr,
broadcast
flag, etc. So my questions are specific to the segment on which the client
resides. Perhaps making the assumption that client and server are on the
same network segment will make it more clear.

--kan--

--
Kevin A. Noll, KD4WOZ
CCIE 10948, CCDP
Perfect Order, Inc.
[email-masked]
717-796-1936

---

From: "Bernie Volz" <[email-masked]>
Date: Sun, 4 Jan 2004 22:16:25 -0500

See section 2.17 of
http://www.ietf.org/internet-drafts/draft-ietf-dhc-implementation-01.txt.
(Last three paragraphs of section 4.1 of RFC 2131 discuss the general case
for server/relay to client communication.)

Also, keep in mind that the client's state is not something that the server
easily knows and it really doesn't need to.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin
A. Noll
Sent: Sunday, January 04, 2004 9:13 PM
To: [email-masked]
Subject: [dhcwg] Delivery of DHCPACK and DHCPNAK

--kan--

---

From: "Kevin A. Noll" <[email-masked]>
Date: Mon, 05 Jan 2004 09:37:49 -0500

Thanks for pointing me to that draft.

I understand that the server does not keep track of (nor easily know)
the client's state. It would be much clearer if message transmission
(at least for the server) were described exclusively in the context of
message type or in terms of the contents of the matching request.

However, message transmission includes reference to the client state.
Those references are what I'm trying to clarify for myself.

I haven't attempted this, but I suppose if I were to map the client
state to the request message contents, I may be able to describe
server-side message transmission exclusvely in terms of request contents.

Also, draft-ietf-dhc-implementation-01.txt doesn't appear to clarify
delivery of the ACK. Can I safely assume that ACK's are delivered based
on the BROADCAST flag in all client states?

That wouldn't seem to be a good assumption since you should be able
to deliver an ACK via unicast when you are renewing or rebinding (i.e.
based on ciaddr being non-zero).

--kan--

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Bernie Volz
> Sent: Sunday, 04 January, 2004 10:16 PM
> To: 'Kevin A. Noll'
> Cc: [email-masked]
> Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK
>
>
> See section 2.17 of

---

From: "Kevin A. Noll" <[email-masked]>
Date: Mon, 05 Jan 2004 10:06:21 -0500

After Bernie's suggestion to read draft-ietf-dhc-implementation-01.txt,
I have some comments and questions about the draft.

Section 2.13
How do you support the claim that clients do not send messages in the
RENEWING or REBINDING states? At a minimum a DHCPREQUEST would be 
broadcast from the RENEWING state as the client moves to the REBINDING 
state, wouldn't it? 

Section 2.26 states "[see also general comment below about policy.]"
What section does this refer to? It appears to refer to sectoin 2.3,
but that is above, not below.

--kan--