(I apologize if this is too late... I just returned from a long vacation ^^;)
Just a small idea about the `Multiple IDs generated in rapid succession may use the same system clock value' problem. What about using, instead of the system clock, `the less of the system clock and (the previously used value plus one, if there is any)'? Considering that it will most probably be the same system up and running without interruption between such rapid allocations, I think it's not too unreasonable to keep a stateful counter. Eugene ----- Original Message ----- From: "Brian Haberman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 28, 2003 5:27 AM Subject: Random algorithm in draft-ietf-ipv6-unique-local-addr-00.txt > There have been several comments on eliminating the > user input portion of the random selection algorithm. > This would, primarily, provide the capability to > automate the prefix generation process. After assessing > issues with this, I have two possible proposals: > > 1. Re-use the random ID process defined in Appendix A.6 > in RFC 1889. That algorithm derives a 32-bit number > from the system clock, system name, process ID, and > several other system-related IDs. It would have to > be modified slightly to provide a 40-bit value. > > 2. Replace the user-supplied birthday value with a system > derived value (EUI has been suggested). The system > clock would still be utilized as a portion of the input > to MD5. > > It should be noted that #1 will return the same value on > repeated calls until the system clock changes or a different > value is passed in as a parameter. > > At this point, my preference is for #1, since it has been > tested as a part of RTCP and the probability function is > well-defined in the rfc. > > If others have differing opinions, let me know. > > Thanks, > Brian H. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
