Christian, > Christian Huitema wrote: > There is a sense of deja vu in all this discussion.
Indeed. I think that one of the reasons former proposals have failed is because there was no enforcement of non-routability in the public Internet, if my memory is correct. >> 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. There is a difference between registered and centrally controlled. Both require access to a server that guarantees uniqueness. Unregistered means that the requester does not have to provide any information. I thought about using "anonymous registration" but there is no info to register. The sequential server would not keep track of registrations for more than 24 hours, I think. > 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. This is easy, just split the address range reserved for this purpose for multiple servers. > But in the absence of registration there is a big risk that poorly > written implementations will get a new number each time they boot. I have addressed this in the draft to come. It's under co-author review and I will post a link ASAP. > In fact, there is also a big risk that a denial of service attack > brings the system down. Not that much of a big deal. DOS do not last forever. The case that uses access to the GUSL server is manual configuration initiated by the administrator. If the GUSL server is unreachable, the administrator can settle for a hash generated prefix to get his network going and try again the next day. Beside, the savvy administrator would have obtained the prefix *before* configuring the router. > I would personally go for a simpler scheme: 1 bit for > random/registered, and a controlled registration process > to remove doubts. Problem is this won't be free, are there any takers to do it for free? > By the way, I would also probably reserve a /16 prefix for a > special class of 32 bits identifiers, the alreday allocated > IPv4 addresses. You mean, something like FEFE:IPV4:ADDR:, similar to 6to4 mechanism? It crossed my mind, what worries in doing this is that people will hijack non-portable IPv4 addresses as well as legitimately using portable ones. Michel. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
