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 <noreply@xxxxxxxx> 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
