Subject: [dhcwg] Accept <draft-rentschler-dhc-discovery-01.txt> as WG work item?

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Dec 2003 08:18:01 -0500

We have a request to accept draft-rentschler-dhc-discovery-01.txt as a WG
action item.  Here is the Abstract and an excerpt from the Introduction:

Abstract

    The discovery mechanism described here is built upon and coexists
    with BOOTP according to RFC 1542 and DHCP according to RFC 2131
    and RFC 3203. It allows server-initiated communication to specific or all
    clients in the network, using the DHCP packet format and with that the
    relay agent functionality. The Discovery Extensons are a powerful and
    flexible add-on to client-initiated DHCP that allow a variety of
    applications.

1. Introduction

    Host Configuration using "traditional" DHCP according to RFC 2131
    is based on host- (client-) initiated communication. If a network
    is booting, all the clients start sending DHCP requests until
    accepting an answer from a DHCP server.  The server may either
    allocate IP addresses out of a pool of available adresses or,
    similar to BOOTP, pre-configured static IP addresses and
    configuration parameters for each known client.

    These concepts did not intend server-initiated and -controlled
    configuration or reconfiguration of clients. This capability was
    later partially added with RFC 3203, but the mechanism there does
    not allow to discover "silent" clients yet unknown to a server or
    trigger the configuration of such a client.  This is especially
    limiting when a server is later plugged to an already configured
    network.  These shortcomings will be overcome with the protocol
    extensions described in this document.

Please respond to [email-masked] by 1/6/2004 with comments about this I-D
and whether the dhc WG should accept this I-D as a WG work item.  If there
are no objections, the default action will be for the dhc WG to accept the
I-D as a WG work item.

- Ralph

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Dec 2003 14:21:31 -0600

I don't see any point in working on this.   Based on the insistence of 
a few folks that we really needed DHCP Reconfigure, we published an RFC 
describing how to do it, which as far as I know has seen zero adoption 
thus far.   This proposal has many of the disadvantages of DHCP 
Reconfigure, isn't really functionally related to DHCP anyway, and 
doesn't look like it would work.   I see no point in spending WG time 
working on this - I think the authors need to go off and do some 
research (that is, come up with a working prototype and adjust the 
draft accordingly) and then come back to us or to some appropriate WG 
when their ideas are a little better baked.

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 30 Dec 2003 16:03:12 -0500

I fully agree with Ted's objections to this. And, this proposal has major
security issues (after all it would have been easy to allow
multicast/broadcast reconfigures in DHCPv6/DHCPv4 except for the security
issues that this would open).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Lemon
Sent: Tuesday, December 30, 2003 3:22 PM
To: Ralph Droms
Cc: [email-masked]
Subject: Re: [dhcwg] Accept <draft-rentschler-dhc-discovery-01.txt> as WG
work item?

---

From: "Kevin A. Noll" <[email-masked]>
Date: Tue, 30 Dec 2003 22:13:07 -0500

Can someone verify for me that RFC 2131 doesn't explicitly limit
when a client may send a DHCPRELEASE.

It doesn't make any sense for the client to send a DHCPRELEASE 
unless it is in BOUND, RENEWING, or REBINDING.

In addition, by the nature of a DHCPRELEASE, the client would 
have to go back to the INIT state when it sends a RELEASE.

I'm just looking for someone to verify that my interpretation is 
correct.

Thanks.

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

---

From: "Kevin A. Noll" <[email-masked]>
Date: Tue, 30 Dec 2003 22:35:27 -0500

I agree with Ted and Bernie. 

The suggested implementation in this draft leaves too much trust with 
the client. Not to mention some potential interoperability problems.

In addition, there are other methods available to perform functions 
that are being proposed.

--kan--

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Bernie Volz
> Sent: Tuesday, 30 December, 2003 4:03 PM
> To: 'Ted Lemon'; 'Ralph Droms'
> Cc: [email-masked]
> Subject: RE: [dhcwg] Accept <draft-rentschler-dhc-discovery-01.txt> as
> WG work item?
> 
>

---

From: "Kevin A. Noll" <[email-masked]>
Date: Tue, 30 Dec 2003 23:23:28 -0500

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

--kan--

> Kevin A. Noll
> Sent: Tuesday, 30 December, 2003 10:13 PM
> To: [email-masked]
> Subject: [dhcwg] Valid states for use of DHCPRELEASE?
> 
> 
>