Telechat Review of draft-ietf-v6ops-dhcp-pd-per-device-07
review-ietf-v6ops-dhcp-pd-per-device-07-intdir-telechat-chown-2024-03-27-00

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