Re: [dhcwg] Options in base doc for DHCPv6

Vijay Bhaskar A K <> Wed, 23 January 2002 18:13 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id NAA19029 for <>; Wed, 23 Jan 2002 13:13:33 -0500 (EST)
Received: (from daemon@localhost) by (8.9.1a/8.9.1) id NAA09369 for; Wed, 23 Jan 2002 13:13:34 -0500 (EST)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id MAA08025; Wed, 23 Jan 2002 12:56:06 -0500 (EST)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id MAA07996 for <>; Wed, 23 Jan 2002 12:56:04 -0500 (EST)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA18405 for <>; Wed, 23 Jan 2002 12:56:02 -0500 (EST)
Received: from ( []) by (Postfix) with ESMTP id 19E016000CC; Wed, 23 Jan 2002 12:55:32 -0500 (EST)
Received: (from vijayak@localhost) by (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id XAA03676; Wed, 23 Jan 2002 23:29:52 +0530 (IST)
From: Vijay Bhaskar A K <>
Message-Id: <>
Subject: Re: [dhcwg] Options in base doc for DHCPv6
Date: Wed, 23 Jan 2002 23:29:51 +0530
In-Reply-To: <> from Ralph Droms at Jan "22, " 2002 "02:55:41" pm
X-Mailer: ELM [$Revision: $]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>
Content-Transfer-Encoding: 7bit

> We've recently experienced a proliferation of proposed and defined options 
> for DHCPv6.  Initially, the WG agreed to publish all options that were 
> defined at the time the base spec was completed in the same doc.  I'm 
> having second thoughts about that decision.  Here's what I'm thinking:
> * The new options are adding more weight to
>    an already hefty document
> * Keeping all the options in one doc make
>    updating any one option more complicated
> * Reviewing all of these options will slow
>    down the acceptance process

The basic use of DHCPv6 is not only allocating IP addresses but also for
giving other configuration parameters also.  Most of the OS are IPv6fied
and almost all the applications are IPv6 enabled.  The hosts need DHCPv6
to provide  options  for  getting the info about the  servers  providing
various  services  available  to them.  This will  make the host work as
fullfledged  IPv6fied  node.  If your  concern is about delay in getting
the PS, i worry that, it will take another year to get all those options
in the  options  draft  and  making  it PS.  I feel  that we can add the
options  in the base  spec  which  are  already  requested  to be added,
because we really  need them.  I dont agree that  review of the  options
will take much time, since including the options  doesn't  involve major
design  change and most of the  options are already  known in DHCPv4 and
most of the options follow the similar pattern.

> I propose that we put a moratorium on adding any new options to 
> draft-ietf-dhc-dhcpv6-22.txt, and move any non-essential options out of 
> draft-ietf-dhc-dhcpv6-22.txt into individual drafts.  The definition of 
> "essential" is open to discussion; here's a first pass at a list of the 
> options to retain in draft-ietf-dhc-dhcpv6-22.txt:
> * DHCP unique identifier option
> * Identity association option
> * IA Address option
> * Requested Temporary Addresses (RTA) Option
> * Option request option
> * Preference option
> * Elapsed Time
> * Client message option
> * Server message option
> * Authentication option
> * Server unicast option
> * Domain Search Option
> * Domain Name Server Option
> * Status Code Option
> - Ralph
> _______________________________________________
> dhcwg mailing list


dhcwg mailing list