Hi,

This Informational document presents an IPv6 deployment model in which clients connecting to a large broadcast network are allocated prefix(es) via DHCP-PD rather than single addresses via SLAAC or DHCPv6.

The draft is well-written, articulating the benefits of the model well, and suggesting where it is - and is not - most appropriate to use.

A parallel draft (collink-6man-pio-flag) describes a new PIO flag through which the network can signal that DHCP-PD is the preferred method on that network, though this is not required for the DHCP-PD per device approach to operate.

Security and privacy considerations are duly discussed.

I consider the document Ready for publication, though a small number of minor nits follow for consideration.

In the benefits in the introduction and section 12, the issue of cost to support increased address-related tables is not explicitly mentioned (that I see), in particular in campus networks we see sites having to consider more expensive WLAN controllers to support multi-address IPv6 nodes.  This is implied by bullet point 5 in section 12, but is a literal cost too and one I hear not infrequently as a concern for IPv6 deployment.

I think the discussion of the size of site prefix needed towards the end of section 8 is good, but again in a campus environment were the DHCP-PD approach used in shared WiFi environments a /48 would be consumed fairly quickly, more so if "DHCP-PD Privacy Prefixes" are supported. That said it's increasingly common for campuses to obtain LIR status now to get a larger, independent block.

It may be useful to explicitly describe how a client using this approach configures an address through which it can be reached from off the link it is attached to, e.g, to ssh to it, use an HTTP method, etc.  This is implied in section 6.4 I think, but could be clearer.

In section 9, first bullet, one SSID may span multiple links, e.g., when prefix pooling is enabled in a WLAN deployment.

The last bullet in section 12 seems to ignore NPTv6.  Though I am not surprised :).  Maybe better to delete the "like as it.." part to avoid that rathole and focus on the transparent, addressable extension.

Overall, a very nice document.

Best wishes,
Tim