Last Call Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05
review-ietf-dhc-dhcpv6-prefix-length-hint-issue-05-secdir-lc-orman-2017-02-16-00

	 Security review of DHCPv6 Prefix Length Hint Issues
	  draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

The document gives advice on how servers and clients can handle DHCP cases
in which the client requests a particular prefix length and the server
cannot exactly match it.  

This statement is very difficult to interpret:
"the server SHOULD provide the prefix with the shortest length
   possible which is closest to the prefix-length hint value."
This alternative in section 3.6 makes more sense:
"assign a prefix of at least the hint length (or shorter) if one is
   available."

I do not see any obvious security flaws, but my opinion is tempered by
the lack of prior discussion.  The security considerations refer to
RFC3633 "IPv6 Prefix Options for DHCPv6", and that refers to ongoing
development of IPsec for DHCPv6.  As nearly as I can tell, that work
was never done.  That makes it difficult to have confidence in the "no
new security considerations" claim.

Some nits:

Remove the comma in the first sentence of the introduction.

"prefix which length" should be "prefix with length" or possibly
"prefix whose length".

"The servers usually has a record" should be "The server usually has a record".

No comma in "When the client wants the same prefix back from the
server, and would prefer ...".

Hilarie