On Mon, 25 Nov 2002, Christian Huitema wrote: > You keep ignoring one of the requirements: that we be able to find out > who is leaking information when "local" addresses leak through > applications, or through management protocols. Random numbers don't give > you that.
Such paths can be traced from messages (look at the source of e.g. SMTP message); the advantage of globally registered addresses is that you can look it up in the assignments table (unless the address was misconfigured/spoofed). Basically you still have to trace it. So, I'm not sure how useful this requirement is. > Also, you should never underestimate how bad people and > computers are at picking random numbers. People -- should people pick these anyway? Problem is naturally that people just pick all-zeroes or something like that. Computers -- I don't agree, provided enough keying material is provided. > And you should also never > underestimate the malicious users who will deliberately pick the "wrong" > value and cause trouble. Nothing prevents from malicious users, not even "really unique" allocations. > There are several ways to provide global uniqueness: registration is > one; reuse of an already registered number is another. Among the > candidates that we could consider: > > * IPv4 addresses, for those who already have them: 32 bits. > * Telephone numbers: we can encode 11 digits in 37 bits. > * Various unique enterprise numbers. > > Such numbers can easily be configured offline. I'm not insisting on random strings. Some of those mechanisms would be practically equivalent to what I'm proposing. IPv4 addresses, can't really be considered unique enough (ISP changes, RFC1918 addresses, etc.), though. What I'm against, is trying to make to some global registry like IANA. That kind of hierarchy is too heavy, and IMO against the spirit of _site-local_ addressing. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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] --------------------------------------------------------------------
