[dhcwg] Issues raised during last call for DHCPv6 specification

Ralph Droms <rdroms@cisco.com> Tue, 22 January 2002 10:35 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15158 for <dhcwg-archive@odin.ietf.org>; Tue, 22 Jan 2002 05:35:38 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01224 for dhcwg-archive@odin.ietf.org; Tue, 22 Jan 2002 05:35:42 -0500 (EST)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00585; Tue, 22 Jan 2002 05:24:34 -0500 (EST)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00564 for <dhcwg@optimus.ietf.org>; Tue, 22 Jan 2002 05:24:32 -0500 (EST)
Received: from funnel.cisco.com (funnel.cisco.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14999 for <dhcwg@ietf.org>; Tue, 22 Jan 2002 05:24:28 -0500 (EST)
Received: from rdroms-w2k.cisco.com (rtp-vpn2-61.cisco.com []) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA01521; Tue, 22 Jan 2002 05:24:00 -0500 (EST)
Message-Id: <>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 22 Jan 2002 05:24:27 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Cc: ipng@sunroof.eng.sun.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [dhcwg] Issues raised during last call for DHCPv6 specification
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

The following issues were raised during the last call for the DHCPv6 spec
<draft-ietf-dhc-dhcpv6-22.txt>; I will kick off separate discussion threads
for each open issue later today.

- Ralph Droms

Open issues

* We've experienced a proliferation of DHCPv6 options.  Should all
   options *not* used in the base protocol be moved out to separate

* Does DHCPv6 need a "default routes" option?

* Does DHCPv6 need a "static routes" option?

* Does DHCPv6 need an FQDN option (basically identical to proposed
   DHCPv4 FQDN option)?

* Other options:
   - NTP servers
   - NIS servers
   - NIS+ servers
   - Subnet selection
   - NIS domain name
   - NIS+ domain name
   - IEEE 1003.1 POSIX timezone
   - SLP directory agent
   - SLP service scope

* Should the DHCPv6 option codes start at 256 to avoid overlap with
   DHCPv4 option codes; overlap of option codes would be an issue for
   the DHCID RR.

* What error codes may a server send in response to an
   Information-Request message?

* Should the Decline message have error codes defining the reason for
   the Decline?

* Does the Information-Request message require a DUID?  Could the
   "MUST" in the third paragraph of 18.1.5 be changed to "SHOULD"?  If
   a DUID "SHOULD" be included, text needs to be added pointing out the
   client-specific information (based on identifying the client with a
   DUID) cannot be returned if a DUID is not included.

* Is a client required to implement the Reconfigure message -
   supporting Reconfigure will require that the client maintain state.

* Do we want to allow a client to request that more normal addresses
   be added to an IA, perhaps through use of the equivalent of the RTA

* DHCP/DDNS interaction

* Is the text in section 17.1.3 sufficient?

Changes to be made in -23
* Editorial changes:
   - Change "Inform message" to "Information-request message"
     and "INFORM" to "INFORMATION-REQUEST" throughout the
   - In the list of DHCP messages in section 7, fix Reconfigure to
     start Renew/Reply or Inform/Reply sequence (not Request/Reply)
   - Fix page 10 (which is blank in -22 draft)
   - In third paragraph of section 14, change "Requested
     Temporary Addresses Option 22.5" to "Requested
     Temporary Addresses Option (see section 22.5)"
   - Change "Rebind" to "Inform" in the last paragraph
     of section 18.1.5 (cut-and-paste error)
   - Fix redundancy between sections 18.2.5 and 18.2.8
   - Edit third paragraph of section 19.2 to delete references to IAs
   - In section 19.3.4, change "Rebind or Information-Request" to
     "Renew or Information-Request"
   - Change last sentence of section 22.5 to: "A client MUST
     only include this option when it wants to have
     additional temporary address allocated; a client SHOULD
     NOT send this option if 'num-requested' is 0".
   - Edit section 22.14 to indicate that the server-address field is in
     the fixed-format part of the DHCP message, not the unicast option
   - Clarify the text in section 22.19 to indicate that the 'user class
     data' items are carried in the data area of the 'user class

* Clarify text in section 13 about address selection based on source
   of message from client

* Remove references to "IAs" in section 19.2

* Fix chart in Appendix B to allow DSTM option in same
   messages as IA option

* Modify SIP server option according to input from Henning Schulzrinne

* Require that the DUID option appear before any IA options to improve
   processing efficiency

* Require that the authentication option be first in th elist of
   options to reduce the work that a server must expend before
   discarding a message that fails authentication (reduces effect of
   denial of service attacks)

* Clean up text specifying selection of address by server to insert
   into 'server-address' field

* Clarify that a server MAY return fewer temporary addresses than
   requested by the client and MUST return AddrUnavail only if no
   temporary addresses are available

* Clarify that a client MUST include all requested options in an ORO
   and MAY include suggested values by including specific options; also,
   the server MAY ignore suggestions from client and the client MUST
   use whatever the server returns

* Clarify that a server MAY renew only some of the IAs sent by a

* Change DUID/VUID to have a length field to allow for longer IDs

dhcwg mailing list