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