Re: [dhcwg] DHC WG charter

Thomas Narten <> Fri, 14 June 2002 15:05 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id LAA02439 for <>; Fri, 14 Jun 2002 11:05:37 -0400 (EDT)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id LAA16907 for; Fri, 14 Jun 2002 11:06:16 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id LAA16720; Fri, 14 Jun 2002 11:02:04 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id LAA16701 for <>; Fri, 14 Jun 2002 11:02:02 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id LAA02271 for <>; Fri, 14 Jun 2002 11:01:23 -0400 (EDT)
Received: from ( []) by (8.12.2/8.12.2) with ESMTP id g5EF0og5141856; Fri, 14 Jun 2002 11:00:52 -0400
Received: from ( []) by (8.11.1m3/NCO/VER6.1) with ESMTP id g5EF0nQ33470; Fri, 14 Jun 2002 09:00:50 -0600
Received: from (narten@localhost) by (8.11.6/8.11.6) with ESMTP id g5EEwlk15942; Fri, 14 Jun 2002 10:58:47 -0400
Message-Id: <>
To: Ralph Droms <>
Subject: Re: [dhcwg] DHC WG charter
In-Reply-To: Message from "Thu, 13 Jun 2002 08:27:24 EDT." <>
Date: Fri, 14 Jun 2002 10:58:47 -0400
From: Thomas Narten <>
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>


Thanks for getting this discussion started.

> The working group has the following primary objectives:

> * Develop additional authentication protocols within the framework
>   defined in RFC3118, along with other mechanisms to mitigate the
>   threat of attacks on DHCP clients and servers:
>   - New RFC3118 protocols to address improved key management and
>     improved scalability

I think the charter should be more specific here. What new protocols
are needed? What problems need to be solved? The above is just a blank
check to do unspecified work (not good).

>   - Provide security for messages passed between relay agents and
>     servers

A good deliverable.

>   - Consider solutions for specific threats such as use of nonce
>     identifier to defend against DoS attacks through FORCERENEW from
>     off-path attackers

This might be good, but it seems like a prerequisite is to have a
documented threat analysis. What are the primary threats to DHCP?
Which ones are the ones that are important to address? Only then does
it make sense to think about specfic solutions. 

> * Complete the specification of DHCP for IPv6 (DHCPv6):
>   - Gain acceptance and publication of current Internet Draft as
>     Proposed Standard
>   - Develop and publish specifications for options and other
>     extensions to DHCPv6, including those already published as
>     Internet Drafts:
>     + "DNS Configuration Options for DHCPv6"
>     + "Time Configuration Options for DHCPv6"
>     + "NIS Configuration Options for DHCPv6"
>     + "DSTM Ports Option for DHCPv6", "DSTM Options for DHCPv6"
>     + "Load Balancing for DHCPv6"
>   - Encourage independent implementations and conduct interoperability
>     testing

I don't think this needs to be called out in the charter. WGs don't do
interoperability testing per se. But interoperability reports are
needed for advancing documents along the standards track.

>   - Revise specification and publish for acceptance as Draft Standard
>     by 6/30/2002

>   - Develop extensions to DHCPv6 for prefix delegation, DNS
>     configuration, etc.

I'm not sure I agree with this. I think the DHC needs to stick with
its core expertise, which is the DHC core protocols, and reviewing
options motivated from outside the WG from the perspective of being
consistent with standard DHC operating practice.

But in terms of actually defining new options, I think that requires
significant input AND MOTIVATION from the customers of the option. In
the case of Prefix delegation, that seems like a broader problem,
where a DHC solution might well be appropriate. But I don't think this
should be driven by the DHC WG, since the problem is not inherently a
DHC problem.

Does the DHC WG really have the expertise to do the prefix delegation
work? I wouldn't immediately think so. They do have  expertise to
review any options once it is determined what the prefix delegation
solution requires.

So, I think better charter wording would say that the WG will review
options whose impetus comes from other WGs. A number of the specific
options mentioned above are really motivated by other WGs.

> * Revise and submit the DHCP specification for acceptance as a Full
>   Standard

I guess I'm a cynic. If there is no realistic plan for doing this, I'd
say leave it out of the charter.

The charter should not be a kitchen sink of all possible work
items. It should capture the priority items the WG will work on over
the next 12 months. One can easily recharter if something interesting
pops up that should get attention.

> * Complete the specification and publish work in progress as
>   standards:
>   - Failover protocol
>   - DHCP/DDNS interaction
>   - SNMP MIB

What is the MIB item? Do we really need it?

>   - Host name options
>   - Other client and relay agent options

> * Review new options for DHCP, as deemed appropriate by the working
>   group and/or the Internet area directors


dhcwg mailing list