"One of the issues with this RFC concerns the wording that is used that allows the implementation to make the choice as to what approach to use, and in so doing, in some cases, the choice made is not the most prudent or best approach, and this thus is not ideal and can lead to some problems."
"prudent" and "best" are things that will change overtime. I can see the value in publishing some algorithm to generate IID, and maybe the more of these we have - the better. I see it harmful in marking the core IPv6 specs updated with this algorithm - even http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ does not do that. Now, beyond the philosophical-political comments, a couple of things on the "meat": 1) http://tools.ietf.org/html/draft-ietf-6man-ug-02 - is in the WGLC. This seems to me that step 6 of algorithm needs to go. 2) the algorithm components R1=(modifier(16 bytes)||timestamp(8 bytes)|| router prefix) it looks to me that it is functionally equivalent of just taking a hash of 16 random bytes and using that as an interface ID ? Why the additional components ? They're trivially guessable (even remotely) and are the same for the nodes on the segment, so they do not add much in terms of entropy. 3) DAD If, after 3 tries, it receives the same result, it will consider this an attack and will start using that IP address. Uh. So if I have a mass of devices on the segment from the same vendor who made a poor implementation of this algorithm there is a plausible race condition where they might start using the same address ? (if the RNG is of bad quality). 4) stable storage. If I read it right, I think the node still must have at least enough storage to keep a single IID. If we are talking this a replacement of EUI64, then, again, why not take a random 64bit value, store that, and just use either that value alone for the IID ? --a On 8/13/13, Hosnieh Rafiee <i...@rozanak.com> wrote: >> For the record, this document doesn't address my feedback. >> >> Most of the I-D is about how to generate a random number. >> >> If you need a PRNG, just require implementations to implement one. Your >> workaround is to get into the same level of complexity to produce a PRNG > that >> wil be employed just by the stack -- if you're ging to implement one, >> make > it >> available to all apps/functions (rather than reinvent the wheel at every > module >> that needs a PRNG). > > JFYI: if you check the algorithm, when stable storage is in use, they also > need to implement a PRNG in addition to use a stack. > I have already discussed about the complexity in my last email. obtaining > timestamp from the system, generating a random number using timestamp as a > seed and call it modifier or whatever and then applying SHA256 on > (timestamp, prefix, modifier) is not complex. For using a default value in > history, the system need to generate random number anyway. While after that > it needs stack in RFC 4941, but with my update it only needs that PRNG. > Second, I did not say that the implementation cannot use the stable > storage. > This way is only "RECOMMENDED" but no force to implement this and the > implementers can keep their first approach. But, what is clear here is the > probability of an attacker to find the history value in order to guess the > next IID of the node is more than using my approach which is completely > random. This is because I do not need to keep any value anywhere in the > node > and modifier every time can be new value. > > >> There's still lots of text that could/should be removed throughout the > document >> -- for instance, you need to get deep into the Abstract to see what the >> document is trying to solve (I bet you might even get a id-nits warning >> as > a >> result of the large Abstract?). > > No, I didn't. It passed without any problem! My abstract is explaining what > I plan to address in the whole document. There is no problem to shorten it > as well. > >> I won't comment further, but just wanted to note that my comments have >> not >> been addressed, since you've stated that they have. > > You usually do not apply the comments that you are not convinced about and > have already explained your reason as to why you are not agree. This is the > same case for your comments on PRNG. > > To be more clear, here is your comments which I applied: > http://www.ietf.org/mail-archive/web/ipv6/current/msg18732.html > > Thanks, > Hosnieh > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
