Hosnieh, You have been making many misleading claims about things I have said or stated. Quite a few times I have corrected you, provided pointers, etc. -- which you have systematically ignored. Your comments below seem to indicate to you didn't bother reading the Introduction of draft-ietf-6man-stable-privacy-addresses, or pay attention to the clarifications I made on-list. I suggest you wait for the next rev of the document, but meanwhile you may consult <http://www.iab.org/wp-content/IAB-uploads/2011/07/IPv6-addresses-privacy-review.txt> for an alternative explanation of the issues involved.
I believe such behavior is harmful. All & chairs: I'm currently working a lot with all (off-list, to reduce the noise) with all those folks that provided feedback during IETC LC and right after IETF LC on the mailing-list... and we're making a lot of progress on the I-D. My plan is to submit a rev of draft-ietf-6man-stable-privacy-addresses fr broader review (i.e., have the wg review that I have double-checked that addresses IETF LC comments). FWIW, I'd like to express a big "thank you" to all the folks that have provided timely comments/reviews, and that have been exchanging emails with me (off-list) to improve the I-D. P.S.: At this point I will not continue responding on this thread. Thanks, Fernando On 05/02/2013 04:35 PM, Hosnieh Rafiee wrote: > Dear All, > > > > Since Fernando’s proposal is not going to solve the current problem with > RFC 4941, I have suggested to him, on several occasions, that he resolve > this problem so that the node's privacy will be better protected but he > ignored this suggestion and claiming that his purpose is different. This > is the main reason that today I wrote an RFC draft which I will submit > to the IETF repository. This draft does not overlap Fernando’s proposal > it is related to the problems with this RFC (RFC 4941) which he doesn't > feel the need to address. The problems that I address here concern the > fact that the node should also change its IID when it receives different > router prefixes. > > > > In the experimental results, Windows machine that implemented privacy > extension RFC, generates different IIDs by rebooting .But when it > receives a different prefix without a reboot, then, on the first two > occasions that the new prefixes received, the node was generated a new > IID, but not for other new prefix generations. Also, as you can see, the > temporary addresses have the same IID. This means that there is a need > to change section 8 of this RFC > > 6. The node is now allowed to generate different interface > > identifiers for different prefixes, if it so desires. > > > > Where a different IID should be generated when a different prefix is > received. I called it “RA-based privacy extension for SLAAC”. > > Physical Address. . . . . . . . . : 00-0C-29-FA-38-32 > > > > IPv6 Address. . . . . . . . . . . : > 2000:abc:ab:0:3003:bfe7:125a:5c0(Preferre > > d) > > IPv6 Address. . . . . . . . . . . : > 2000:abc:bad:bad:3003:bfe7:125a:5c0(Prefe > > rred) > > Temporary IPv6 Address. . . . . . : > 2000:abc:ab:0:5d60:2136:554:188b(Preferre > > d) > > Temporary IPv6 Address. . . . . . : > 2000:abc:bad:bad:5d60:2136:554:188b(Prefe > > rred) > > Temporary IPv6 Address. . . . . . : > 2000:bad:bad:bad:5d60:2136:554:188b(Prefe > > rred) > > > > Lifetime of the addresses as long as the computer is on > > Addr Type DAD State Valid Life Pref. Life Address > > --------- ----------- ---------- ---------- ------------------------ > > Public Preferred 3314d21m1s 779d18h22m24s > 2000:abc:ab:0:3003:bfe7:125a:5c0 > > Temporary Preferred 6d23h51m4s 6d23h51m4s > 2000:abc:ab:0:5d60:2136:554:188b > > Public Preferred 3314d16m15s 779d18h17m38s > 2000:abc:bad:bad:3003:bfe7:125a: > > 5c0 > > Temporary Preferred 6d23h50m22s 23h50m22s > 2000:abc:bad:bad:5d60:2136:554:188b > > Public Preferred 3314d21m13s 779d18h22m36s > 2000:aed:ab:0:3003:bfe7:125a:5c0 > > Temporary Preferred 6d23h55m20s 23h55m20s > 2000:aed:ab:0:5d60:2136:554:188b > > Public Preferred 3314d15m26s 779d18h16m49s > 2000:bad:bad:bad:3003:bfe7:125a: > > 5c0 > > Temporary Preferred 6d23h49m13s 6d23h49m13s > 2000:bad:bad:bad:5d60:2136:554:188 > > b > > > > A second problem that I found with that RFC is the second approach used > to generate the IID. In section 3.2.2 it describes a more randomized > IID generation approach by using CGA, but it does not explain how to > use this algorithm when security is not a consideration. In my > extension, I also explain how to use that algorithm if we do not wish to > consider security as a part of CGA. Of course, I derived that section > from my last draft , SSAS, and will remove that section from SSAS. I > would prefer that the SSAS algorithm focus more on security and then > focus on privacy. > > > > Best, > > Hosnieh > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
