Re: [Int-dir] Intdir telechat review of draft-ietf-v6ops-dhcp-pd-per-device-07

[Jen Linkova <[e-mail]>]

Hi Tim,

First of all, thank you for the review!
When I say 'fixed' or 'added' below it means the changes will appear
in -08 which we are going to submit in ~24 hrs.

On Thu, Mar 28, 2024 at 1:27 AM Tim Chown via Datatracker
<[e-mail]> wrote:
> 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.

Yes, good point, we have added some text. The beginning of Section 12 now reads:

* Network device resources (e.g., memory) need to scale to the number
of devices, not the number of IPv6 addresses. The first-hop routers
have a single route per device pointing to the device's link-local
address. This can potentially enable hardware cost savings, for
example if hardware such as wireless LAN controllers is limited to
supporting only a specific number of client addresses, or in VXLAN
deployments where each client address consumes one routing table
entry.

* The cost of having multiple addresses is offloaded to the clients.
Hosts are free to create and use as many addresses as they need
without imposing any additional costs onto the network.

> 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.

The following text has been added to the end of the penultimate
paragraph of Section 8:

"Existing sites that currently use a /48 prefix cannot support more
than 64k clients in this model without renumbering, though many
networks of such size have LIR status and can justify bigger address
blocks."

> 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.

Strictly speaking it's the same approach as SLAAC.
Would the following text address your concern:

DHCPv6 servers that delegate prefixes can interface with Dynamic DNS
infrastructure to automatically populate reverse DNS, similarly to
what is described in section 2.5.2 of RFC [RFC8501]. Networks that
also wish to populate forward DNS cannot do so automatically based
only on DHCPv6 prefix delegation transactions, but they can do so in
other ways, such as by supporting DHCPv6 address registration as
described in [I-D.ietf-dhc-addr-notification].

?

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

To be honest I'm not sure what to add here. Ideally, the client shall
stay on the same link all the time (otherwise we are going to see all
those issues my gulla draft is trying to address - and thank you,
prefix pooling is another example to add there!!).

> The last bullet in section 12 seems to ignore NPTv6.  Though I am not surprised
> :).

The last thing I want is to bring the NPTv6 discussion to this thread,
so I'm only going to say that NPTv6 doesn't really solve the problem
of extending the network downstream ;)

> Maybe better to delete the "like as it.." part to avoid that rathole and
> focus on the transparent, addressable extension.

I believe it's important to mention this, as migrating to
IPv6-only/mostly w/o PD breaks exactly this scenario: s router which
looks like a host and extends the network downstream via NATv4.

> Overall, a very nice document.

Thank you!

-- 
Cheers, Jen Linkova