Hi Carlos, On Fri, May 10, 2024 at 7:51 AM Carlos Jesús Bernardos via Datatracker <noreply@xxxxxxxx> wrote: > Based on my review, if I was on the IESG I would ballot this document as YES. Thank you! ;) > - At the end of section 1, it is mentioned that the mechanism described in the > document provides parity with IPv4, by allowing a device to inform the DHCPv6 > server about a self-configured or statically configured address. Apologies for > my ignorance on this in advance, but, is there a mechanism in IPv4 to do so for > statically configured addresses? If so, I think adding a reference would be > useful. If not, maybe the text can be rewritten a bit, as I would find it a bit > unclear. We've just submitted -12 which now says: "This operational practice relies on the DHCP server knowing the IP address assignments. This works quite well for IPv4 addresses, as most addresses are either assigned by DHCP [RFC2131] or statically configured by the network operator. For IPv6, however, this practice is much harder to implement, as devices often self-configure IPv6 addresses via SLAAC [RFC4862]. This document provides a mechanism for a device to inform the DHCPv6 server that the device has a self-configured IPv6 address (or has a statically configured address), and thus provides parity with IPv4, by making DHCPv6 infrastructure aware of self-assigned IPv6 addresses." I hope it's more clear now, pls let us know if you think further improvements are needed. > - It is mentioned that the client MUST include the Client Identifier option in > the ADDRESS-REG-INFORM messages. I think this might deserve some text regarding > how this might imply (or not) a potential privacy issue for hosts implementing > some kind of MAC address randomization and rotation of IPv6 self-assigned > addresses, as an observer could easily track the addresses being used and match > those to the same device. We don’t think this is a concern, because on-link attackers do not need to use the client identifier to match self-assigned addresses to devices, they can use the MAC address for that purpose. Privacy-sensitive clients that randomize their MAC addresses should obviously randomize their DHCPv6 Client Identifiers too. We’re not sure this document is the right place to say so, though? > - It is not completely clear to me if the spec requires a client to use the > mechanism on ALL interfaces. I mean, can a client use it just on some > interfaces, but not all, by having configuration policies indicating on which > ones to use it? As I read the document, it seems to imply that if it is used on > one interface, it MUST be used on all of them. Oh very good point, I didn't realize we are not making that part clear. No, as the registration messame must be sent from the address being registered (section 4.2 does say that), and the registration support is network-specific, the client should (must) enable this on per-interface basis. We have added the following text to Section 4.4: "A client with multiple interfaces MUST discover address registration support for each interface independently. The client MUST NOT send address registration messages on a given interface unless the client has discovered that the interface is connected to a network which supports address registration." > - Minor nit (or maybe just nothing at it is just that I’m not a native English > speaker): “to specify the address to being registered” -> I guess the “to” > should be removed. Yeah, a typo, fixed! -- Cheers, Jen Linkova -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
