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

[Tim Chown <[e-mail]>]

Hi Jen,

> On 3 Apr 2024, at 08:38, Jen Linkova <[e-mail]> wrote:
> 
> 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.

Looks good.

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

Likewise.

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

Hmm, there’s the how the node configures an address on that interface, and then also the how that might be added to the DNS. I’m not sure either is stated explicitly at the moment. 

I recall ietf-dhc-addr-notification originally included DNS registration, but the current version removed that?

>> 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 ;)

Fair enough :)

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

Best wishes,
Tim

> 
> -- 
> Cheers, Jen Linkova