Hi Jürgen, Thank you for your review! On Sun, Feb 4, 2024 at 4:53 PM Jürgen Schönwälder via Datatracker <noreply@xxxxxxxx> wrote: > - There is a question left in the privacy considerations. Perhaps > simply drop the question since this text is just outlining an idea > and far from specifying a concrete solution. Actually, we have updated the privacy considerations based on Artart review, and the new text (not yet submitted) will be: "If an eavesdropper or information collector is aware that a given client is using the proposed mechanism, then they may be able to track the client based on its prefix. The privacy implications of this are equivalent to the privacy implications of networks using stateful DHCPv6 address assignment: in both cases, the IPv6 addresses are determined by the server, either because the server assigns a full 128-bit address in a shared prefix, or because the server determines what prefix is delegated to the client. Administrators deploying the proposed mechanism can use similar methods to mitigate the impact as the ones used today in networks that use stateful DHCPv6 address assignment. Networks that use the proposed mechanism instead of SLAAC or in addition to SLAAC, SHOULD minimally: Ensure that when a client requests a prefix, the prefix is randomly assigned and not allocated deterministically. Use short prefix lifetimes, to ensure that when a client disconnects and reconnects it gets a different prefix. To provide privacy roughly equivalent to SLAAC with temporary addresses ([RFC8981]), the network SHOULD allow the client to have two prefixes at the same time. This allows the client to rotate prefixes using a mechanism similar to temporary addresses but that operates on prefixes instead of on individual addresses. The prefix's lifetimes SHOULD be short enough to allow the client to use a reasonable rotation interval without using too much address space. For example, if every 24 hours the the client asks for a new prefix and stops renewing the old prefix, and the Valid Lifetime of delegated prefixes is one hour, then the client will consume two prefixes for one hour out of 24 hours, and thus will on average consume just under 1.05 prefixes. " > Editorial: > > - Perhaps have a more descriptive short title than 'MultAddrr' on the > text rendering. (But then the species reading text renderings may be > dying out.) Oh good point, I've changed it to "Prefix per node using DHCPv6 PD" > - 'depened' -> 'depend' Fixed, thank you! -- Cheers, Jen Linkova -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
