There is a sense of deja vu in all this discussion -- similar proposals of making SL more unique by somehow sticking an identifier in the 38 available bits have popped out every 2 years on the list since 1994; I have to plead guilty, since I have indeed been one of the proponents. > There is a need for three types of allocation: > - Free, automated configuration, no registration, > no external connection, almost unique. > - Free, manual or semi-automatic configuration, > no registration, Internet connection necessary > for semi-automatic configuration, unique. > - Fee-based, manual registration, unique. > Additonal properties TBD.
I don't understand the intermediate category, and specifically the implementation as: > 1.2.2 Unregistered, free, unique, sequentially allocated. Unique and sequential is contradictory with unregistered. I understand that we could implement a web site that distributes sequential numbers, although it is not clear that we can run a web site that runs a strictly sequential counter efficiently; you will probably need to loosen the sequential requirement to allow for a parallel implementation. But in the absence of registration there is a big risk that poorly written implementations will get a new number each time they boot. In fact, there is also a big risk that a denial of service attack brings the system down. I would personally go for a simpler scheme: 1 bit for random/registered, and a controlled registration process to remove doubts. By the way, I would also probably reserve a /16 prefix for a special class of 32 bits identifiers, the alreday allocated IPv4 addresses. -- Christian Huitema -------------------------------------------------------------------- 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] --------------------------------------------------------------------
