Fernando, The purpose of your draft was not to obsolete or update RFC 4941 and you wanted to have your approach as an optional approach in parallel with that approach. So what is your problem with improving that document. It has nothing to do with your proposal. The people can accept or reject yours. I do not see any harmful behavior here as I also asked you 1000 times to update that rfc instead of having something new or in between two RFCs.
Hosnieh -----Original Message----- From: Fernando Gont [mailto:fg...@si6networks.com] Sent: Thursday, May 02, 2013 10:18 PM To: Hosnieh Rafiee Cc: ipv6@ietf.org Subject: Re: Solutions to the problem with RFC 4941 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-re view.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 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
