Hi Harald, Thank you for your review! Sorry for the delayed response. On Wed, Feb 7, 2024 at 8:29 AM Harald Alvestrand via Datatracker <noreply@xxxxxxxx> wrote: > The document is targeted at Informational, and makes no protocol changes; it > does contain a number of requirements on deployments, which makes me wonder if > it should be Proposed or BCP. The authors and the WG believe it should be an Informational document, because the document describes just one of many possible deployment models. While the proposed solution does bring some benefits when deployed in large networks, it comes with some costs and requirements (such as a large amount of IPv6 address space). The authors would like to document the problem they faced assuring IPv6-only deployment and a proposed solution, but it might be unwise to claim that everyone needs this and shall deploy their network exactly the same way. The document aims to provide network administrators with information they need to make a decision on 'do I need this? Do I want to deploy this?' and should they answer 'yes' - with recommendations on how to do this. As this document is operational and describes how to deploy existing protocols, I do not believe 'Proposed' would suit it at all. Requirements specified in the document are about 'please ensure you configure this and that' - similar, for example, to recommendations like 'if you are deploying IPv6, you MUST permit certain ICMPv6 traffic between hosts and routers'. > The biggest detected problem is with privacy, where the risk of tracking seems > to be underplayed, with the recommendation being a weak "client might consider > implementing a mechanism similar to RFC 8981". Given that a fixed prefix per > client is near certain to be tracked as soon as it's deployed, I think the > recommendation should be "SHOULD (MUST?) reallocate prefixes on the same > schedule as is deployed for RFC 8981 addresses". Thank you, I agree we should have documented it in more detail. The most important things to remember are: - exactly the same problem exists for DHCPv6 IA_NA today. - to track the client, the observer needs to know if the device has its own prefix or not. The host behaviour is out of scope, the document intentionally focused on recommendations for nework administrators on how to configure the network. So we have rewritten the Security Considerations (not submitted yet), and now it looks like that: "A malicious (or just misbehaving) client might attempt to exhaust the DHCP-PD pool by sending a large number of requests with differing DUIDs. This is not a new issue, as the same attack might be implemented in DHCPv4 or DHCPv6 for IA_NA requests. To prevent a misbehaving client from denying service to other clients, the DHCPv6 server or relay MUST support limiting the number of prefixes delegated to a given client at any given time. A malicious client might request a prefix and then release it very quickly, causing routing convergence events on the relays. The impact of this attack can be reduced if the network rate limits the amount of broadcast and multicast messages from the client. Delegating the same prefix for the same client introduces privacy concerns. The proposed mitigation is discussed in Section 13. Spoofing scenarios and prevention mechanisms are discussed in Section 10." Would the updated text address your concern? > Apart from that, I think the document is ready. > > Nits: > > - PIO is not defined or expanded on first use Thanks, will be fixed in the next version. > - Example topology drawing in section 4 is truncated in HTML format (covered by > TOC), and > 80 chars in text format - Oh, thanks you, I'll look into it. txt shall be using ascii and be 79 chars, and HTML shall be using SVG, I'll find out why it doesn't work as expected. >in section 12, "network devices > resources" should probably be "network devices' resources" Probably, English is hard ;) -- Cheers, Jen Linkova -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
