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. This I-D details a new DHCP option to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report allocation usage statistics. The Security reference points to RFC 2131 and RFC 3118. I think this adequately describes denial of service due to a rogue delegating router advertising bogus prefixes, as well as denial of service due to a malicious DHCP client masquerade as a legitimate client and claiming all resources to itself. RFC 3118 says that it can be used in combination with this option to provide some level of mutual DHCP server and client authentication and thus addresses threats mentioned above, although it has its limitations. (However I am not a DHCP expert and haven't studied RFC 3118 in details.) I can't think of any other threats not described in the Security Considerations section. Other issues I found in the document: Major: 3.3. Subnet-Name Suboption format The Subnet-Name suboption may be used in order to pass a subnet name to the server for use during allocation. This name may be used for any purpose but is intended to tell the server something extra about the needed subnet; for example, "sales department", "customer 1002", "address pool FOO", or some such. The "name" should NOT be NULL terminated since the "len" field already specifies the length of the name. The "Name" in this suboption is simply a number of octets and need not be ASCII text. The last sentence: if it doesn't need to be ASCII you need to specify whether it is a textual string or a binary string. In the former case you also need to specify which character set is used in this field. Ideally it should be UTF-8 [RFC3629]. Minor: It would be good to describe upfront that this option is only specified for IPv4 and not for IPv6. 3.2. Subnet-Information Suboption format 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 2 | Len | Flags :c:s| SP1, SP2, ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Len = Length of the sub-option (min. length of 8) (1 octet) Flags = Various flags which apply to ALL Subnet Prefix Information fields specified in this suboption. Unused flags must be zero. Are unused flags ignored by a recipient if non zero? (Similar question regarding Section 3.1) 3.2.1. Subnet Prefix Information block format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | Flags |h|d| Stat-len | Optional stats... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addr = IPv4 network number (4 octets) Did you mean "Network"? There is no "Addr" in the table above. 3.2.1.1. Subnet Usage Statistics Fewer fields may be included than what is specified in any current RFC, but all fields which are included MUST remain in order specifed here. Can you elaborate on what this mean? Does it mean only including 1 or 2 of the specified fields?