On 13/02/2016 11:08, Christian Huitema wrote: > On Friday, February 12, 2016 12:48 PM, Fred Templin wrote >>> From: dhcwg [mailto:dhcwg-bounces@xxxxxxxx] On Behalf Of ???? (> JINMEI, > Tatuya) >>> >>> Brian Carpenter called for an attention to Section 4.5.2 of the draft... >>> so I'm responding to it. >>> >>> 4.5.2. Prefix delegation >>> >>> The interaction between prefix delegation and anonymity require >>> further study. For now, the simple solution is to avoid using prefix >>> delegation when striving for anonymity. When using the anonymity >>> profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of >>> address assignment. >>> >>> I'm not sure what Brian tried to indicate in his message, but at least >>> this section looks vague to me about the rationale for the "SHOULD >>> NOT". It's not obvious to me how IA_PD is worse than IA_NA in terms >>> of privacy. Is this a "SHOULD NOT" simply because the "interaction" >>> (is not yet fully understood and) requires further study? > > Yes, exactly that. There was some anxiety that prefix delegation requires > understanding to whom the prefix is delegated. There are also potential side > effects if prefix are reassigned quickly to random nodes. All that needs > further study before we can make a recommendation. We can certainly add a > bit of text to make that more clear. > >> I don't have a strong opinion on the "SHOULD NOT" in this paragraph, but > it is >> very important that this guidance not be taken out of context. This > document >> is only about clients that wish to remain anonymous, which does not apply > to >> all use cases. > > Yes. Also, we can add text explaining that once these problems are better > understood and the IETF agrees on the proper way to handle anonymous prefix > delegation, clients MAY use the agreed upon solution. Which is kind of > redundant, but if you guys prefer it that way, why not. To be clear, I don't have a strong opinion on this; it simply seemed like something the IPv6 community should be aware of before it ends up in an RFC. I also noticed this morning that it might impact draft-ietf-v6ops-host-addr-availability. Brian