Subject: [dhcwg] Revised charter

From: Ralph Droms <[email-masked]>
Date: Wed, 07 Apr 2004 08:53:58 -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: "S. Daniel Park" <[email-masked]>
Date: Fri, 09 Apr 2004 14:50:05 +0900

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ralph Droms
> Sent: Wednesday, April 07, 2004 9:54 PM
> To: [email-masked]
> Subject: [dhcwg] Revised charter
> 
>

---

From: Ralph Droms <[email-masked]>
Date: Fri, 09 Apr 2004 08:24:55 -0400

Can you give us more details?  What problems would we
consider as part of mobility support in DHCP?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 09 Apr 2004 08:29:05 -0400

Jinmei-san - thanks for catching the typo, and I will add
a reference to the newly published RFC 3736.

- Ralph

At 11:08 AM 4/9/2004 +0900, JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
> >>>>> On Wed, 07 Apr 2004 08:53:58 -0400,
> >>>>> Ralph Droms <[email-masked]> said:
>
>It basically looks good.  A couple of minor comments:
>
>s/RFCS/RFCs/ ?
>We may want to add RFC3736 as a reference of "stateless DHCPv6".
>
>                                         JINMEI, Tatuya
>                                         Communication Platform Lab.
>                                         Corporate R&D Center, Toshiba Corp.
>                                         [email-masked]

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 9 Apr 2004 13:33:31 -0400

Ralph:

The draft charter great!

One minor issue - you might want to make the list elements consistent.
Some start out with an action, others give a description first and then
the actions. To scan the list quickly, it might be nice if they all
started with actions. But, this is very minor and completely your
choice.

- Bernie

---

From: "S. Daniel Park" <[email-masked]>
Date: Sat, 10 Apr 2004 09:08:42 +0900

> consider as part of mobility support in DHCP?

Well, I think it's not problem but restriction in DHCP. 
I guess current DHCP architecture is not concretely 
matched to the mobility because of long round-trips 
to get IP address and related information. Above all 
DHCP is a natural choice in the Wireless Lan (802.11) 
in conjunction with Access Point (AP), thus I think it's 
worth discussing this with dhc folks.

It's [Introduction] [Background] [Design Goals]
sections of preparing draft for your information and it 
will be available soon.

Hope this helps.

1. Introduction 
      
The world has become increasingly mobile. As a result,
traditional ways of networking the world have proven 
inadequate to meet the challenges posed by our new 
collective lifestyle.  Wireless technology has been 
successful because it enables people to connect with each
other regardless of location and the most successful 
wireless networking technology this far has been 802.11 
WLAN [802.11][WLAN]. 
      
Regarding the wireless technology, DHCP [RFC 2131] 
is widely used for obtaining the network configuration on
the mobile node such as its unique IP address and others
in the local networks.  DHCP is useful with access point 
which generally includes a DHCP server because it 
minimizes mobile node configuration.  The DHCP server 
(access point) can be allocated a pool of addresses.  The 
administrator specifies both the DHCP based address and 
the size of the pool.  The DHCP server (access point) can 
also be configured to hand out a default gateway and DNS 
server information. 
      
The main objective of this draft is to propose a new architecture
of DHCP to support the mobility on the DHCP client as mobile 
node.  Also fast network attachment mechanism should be 
considered in conjunction with the mobile IP [RFC 3220] [MIP6] 
which allows a mobile node to move from one link to another 
without changing the mobile node's "home address".  Packets 
may be routed to the mobile node using this address regardless
of the mobile node's current point of attachment to the Internet.  
The mobile node may also continue to communicate with other
nodes (stationary or mobile) after moving to a new link.  The 
movement of a mobile node away from its home link is thus 
transparent to transport and higher-layer protocols and 
applications. 
      
The aim of this draft is neither network information such as 
DNS nor fast handover mechanism [FH802.11]. 

3. Background 

The aim of this draft is to discuss mobility issue in the
DHCP environment and it is especially appropriate for 
processes and devices which already interpret DHCP
messages.   
      
In particular, a new proposed architecture allow DHCP 
server to send available IP addresses to DHCP client 
quickly to attach a new network when in motion. 
      
Placing DHCP server on the access point is a natural 
choice in the 802.11 wireless environment. 
      
The Unsolicited message is an extension to the DHCP 
protocol. 
      
The main purpose of this draft is to provide a starting 
point of mobility issue in the DHC Working Group. 

4. Design Goals 
      
The goal of this draft is to provide a lightweight mechanism
for supporting mobility in the DHCP environment.  It is 
designed to optimize current DHCP mechanism to cut 
down number of round-trips between DHCP client and 
DHCP server. 
      
Here are some requirements why this design is required. 
      
[1] Wireless technologies especially 802.11 are widely 
spread in the DHCP environment, thus fast network 
attachment is importantly required on the DHCP client 
when in motion. 
      
[2] Current 4-messages exchange is not matched for
the mobility. 
  
[3] Effectively this design aims outperforming rapid 
commit technique by substituting the explicit DHCP 
operation with the implicit link-layer association event. 
      
[4] DHCP server functionality is common on the access
point. 
      
[5] For supporting mobility on the current DHCP protocol, 
minimal additional configuration/requirement is required.