A single bit for authentication seems like weak authentication... ;) At any rate, you can't use truly random values in addressing and expect to establish a trust based on that. At best you could have a pseudo-random table that both ends are working from, but either that table is well-known, or establishing it and maintaining synchronization will be an operational nightmare.
As for using an address without performing DAD, this is a *bad idea* in general and fast-handoff is no excuse to avoid verifying that someone else is not already using an address on the link (assigned or random). If mip is that far off in the weeds we may need an AD to ask them to revisit their charter. Tony > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 05, 2002 10:31 AM > To: Tony Hain > Cc: [EMAIL PROTECTED] > Subject: Re: Randomness and uniqueness > > > "Tony Hain" <[EMAIL PROTECTED]> writes: > > In a quick scan of 3041 I didn't see a reference to that, > but it was a > > fundemental assumption. If 3041 is updated it would probably help to > > have a clear pointer back to 2462. > > Sure, thanks for pointing this. I wasn't referring to rfc3041 > though. > > My remark was rather generic. > > For example, let's say I design DHCP2 where the 65th bit of all > addresses has particular meaning to DHCP2 servers: helps in better > authenticating clients. Also, the 66th bit up to 128th contain a > random number that is used to securely communicate between DHCP2 > servers and relays. > > Of course, this would have huge advantages for the DHCP2 protocol, > since it allows combining trust properties into addressing and routing > properties. But would this work with other things? > > Thanks for any feedback, > > Alex > > PS: with respect to uniqueness there's a draft on random Interface > ID's without DAD: draft-soto-mobileip-random-iids-00.txt > PPS: with respect to security there's ongoing discussion on Mobile IP, > around a novel method to generate addresses (Computationally > Generated Addresses). > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
