Subject: [dhcwg] Reminder! Revised charter

From: Ralph Droms <[email-masked]>
Date: Mon, 12 Apr 2004 12:14:46 -0400

Here is a draft charter for the WG, based on discussion at the WG meeting in
Seoul and discussion on the mailing list.  Please review and respond with
comments.

- Ralph

dhc WG draft revised charter
----------------------------

The dhc working group (DHC WG) has developed DHCP for automated
allocation, configuration and management of IP addresses and TCP/IP
protocol stack parameters. DHCPv4 is currently a "Draft Standard" and
is documented in RFC2131 and RFC2132.  DHCPv6 is currently a "Proposed
Standard" and is documented in RFC3315.  Subsequent RFCS document
additional options and other enhancements to the specifications.

The DHC WG is responsible for reviewing (and sometimes developing)
DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG
is expected to review all proposed extensions to DHCP to ensure that
they are consistent with the DHCP specification and other option
formats, that they do not duplicate existing mechanisms, etc. The DHC
WG will not (generally) be responsible for evaluating the semantic
content of proposed options. The DHC WG will not adopt new proposals
for extensions to DHCP as working group documents without first
coordinating with other relevant working groups and determining who
has the responsibility for reviewing the semantic content of an
option.

The DHC WG has the following main objectives:

* The DHC WG will address security in DHCP

    o Develop and document security requirements for DHCP. RFC 3118
      defines current security mechanisms for DHCPv4. Unfortunately, RFC
      3118 has neither been implemented nor deployed to date.  Specific
      issues to be considered include:

      - Improved key management and scalability

      - Security for messages passed between relay agents and servers

      - Threats of DoS attacks through FORCERENEW

      - The increased usage of DHC on unsecured (e.g., wireless) and
        public LANs

      - The need for clients to be able to authenticate servers, without
        simultaneously requiring client authentication by the server.

    o Develop and document a roadmap of any new documents or protocols
      needed to meet the security requirements for DHCP

* Write an analysis of the DHCP specification, including RFC2131,
    RFC2132 and other RFCs defining additional options, which identifies
    ambiguities, contradictory specifications and other obstacles to
    development of interoperable implementations. Recommend a process
    for resolving identified problems and incorporating the resolutions
    into the DHCP specification.

* Hosts that include implementations of both IPv4 and IPv6
    ("dual-stack hosts") may use DHCP to obtain configuration settings
    (including assigned addresses) for both IPv4 and IPv6.  The DHCPv4
    and DHCPv6 specifications (RFC2131, RFC2132, RFC3315 and subsequent
    RFCs) do not explicitly explain how a dual-stack host uses DHCP to
    obtain configuration settings for both IP stacks. The dhc WG will
    assess the requirements for a dual-stack host to use DHCP to obtain
    configuration settings for both IPv4 and IPv6, review alternative
    solutions and select a solution, and develop, review and publish a
    document that defines the chosen solution.

* The DHCPv6 specification in RFC3315 includes a mechanism through
    which clients can obtain other configuration information without
    obtaining an address or addresses.  This mechanisms is sometimes
    called "stateless DHCPv6".  RFC3315 includes no provision for
    notifying DHCPv6 clients using stateless DHCPv6 of changes in the
    configuration information supplied to the client or any
    recommendations as to when a client should obtain possibly updated
    information.  The dhc WG will assess the requirements for informing
    DHCPv6 clients of changes in configuration information, review
    alternative solutions and select a solution, and develop, review and
    publish a specification for the chosen solution.

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 13 Apr 2004 10:57:24 +0900

>>>>> On Mon, 12 Apr 2004 12:14:46 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> Seoul and discussion on the mailing list.  Please review and respond with

I can only see differences in indentation margin between this one and
the one you sent on Apr. 7th...is that intentional?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Mon, 12 Apr 2004 23:35:21 -0400

I had intended to resend the original message about the charter - I don't 
know why the indentation changed.

I've included belowa revised version with the edits you suggested and a few 
other minor editorial changes.

- Ralph

At 10:57 AM 4/13/2004 +0900, JINMEI Tatuya / 

The dhc working group (DHC WG) has developed DHCP for automated
allocation, configuration and management of IP addresses and TCP/IP
protocol stack parameters. DHCPv4 is currently a "Draft Standard" and
is documented in RFC 2131 and RFC 2132.  DHCPv6 is currently a
"Proposed Standard" and is documented in RFC 3315.  Subsequent RFCs
document additional options and other enhancements to the
specifications.

   o Develop and document security requirements for DHCP. RFC 3118
     defines current security mechanisms for DHCPv4. Unfortunately,
     RFC 3118 has neither been implemented nor deployed to date.
     Specific issues to be considered include:

     - Threats of DoS attacks through DHCPFORCERENEW

* Write an analysis of the DHCP specification, including RFC 2131,
   RFC 2132 and other RFCs defining additional options, which
   identifies ambiguities, contradictory specifications and other
   obstacles to development of interoperable implementations. Recommend
   a process for resolving identified problems and incorporating the
   resolutions into the DHCP specification.

* Hosts that include implementations of both IPv4 and IPv6
   ("dual-stack hosts") may use DHCP to obtain configuration settings
   (including assigned addresses) for both IPv4 and IPv6.  The DHCPv4
   and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and
   subsequent RFCs) do not explicitly explain how a dual-stack host
   uses DHCP to obtain configuration settings for both IP stacks. The
   DHC WG will assess the requirements for a dual-stack host to use
   DHCP to obtain configuration settings for both IPv4 and IPv6, review
   alternative solutions and select a solution, and develop, review and
   publish a document that defines the chosen solution.

* The DHCPv6 specification in RFC 3315 includes a mechanism through
   which clients can obtain other configuration information without
   obtaining an address or addresses.  This mechanisms is sometimes
   called "stateless DHCPv6" and is specified in RFC 3736.  RFC 3315
   includes no provision for notifying DHCPv6 clients using stateless
   DHCPv6 of changes in the configuration information supplied to the
   client or any recommendations as to when a client should obtain
   possibly updated information.  The DHC WG will assess the
   requirements for informing DHCPv6 clients of changes in
   configuration information, review alternative solutions and select a
   solution, and develop, review and publish a specification for the
   chosen solution.

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Tue, 13 Apr 2004 12:02:22 -0700

the revised charter looks good to me, Ralph

--Barr