RE: [dhcwg] Revised charter

["S. Daniel Park" <[e-mail]>]

Can we show a mobility issue in the DHC charter ?
* The DHC WG will address mobility in DHCP

Or out of scope of the DHC charter at this stage ?

Regarding this issue, I am trying to propose a
new draft as a starting point to discuss mobility
support for the DHCP and it will be available in the
middle of this month.


Regards.


- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics. 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Ralph Droms
> Sent: Wednesday, April 07, 2004 9:54 PM
> To: [e-mail]
> Subject: [dhcwg] Revised charter
> 
> 
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


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