[dhcwg] Issues raised during last call for DHCPv6 specification

[Ralph Droms <[e-mail]>]

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


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