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
drafts?
* 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
option?
* 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
document
- 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
option'
* 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
client
* Change DUID/VUID to have a length field to allow for longer IDs
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
