Pekka Nikander wrote: ... > Step 1. Detect if the client wants to use the default > authorization mechanism, i.e. RR, or something > stronger.
gabriel montenegro wrote: .... > > Think of "strong" addresses as expressing 2 things to the peer: > > "(1) I do not engage in redirection operations on my address, or, if I do, > (2) I only do so with cryptographically strong mechanisms in which I will prove >to your > satisfaction that I do have authorization to use that address" I agree that embedding this semantics in the address is a way of achieving Step 1. But after reading lots of mail, and a preview (thanks!) of Gabriel's draft, I'm still stuck, as Tony Hain seems to be, on why this is the only way. As far as I can see, what is needed is a bit in the *packet*, not necessarily a bit in the address. Whether the bit is in the address or not doesn't affect the MitM's ability to fake it, or whether it can be cryptograhically verified. (Note - I'm not arguing about generating the IID field itself by some cryptographic technique as Gabriel describes. Architecturally, that should be 64 opaque bits anyway.) Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
