Nick 'Sharkey' Moore wrote:
On 2004-02-27, Nick 'Sharkey' Moore wrote:
I'm convinced that a change needs to be made to the wording to resolve this issue, but I'm not sure which is the better option.
My suggested text for "DAD but interoperable with DIID":
[5.4. Duplicate Address Detection][...]
- Each individual unicast address MUST be tested for uniqueness.
- When configuring a global unicast address, the link-local address with the same suffix as that address MUST be configured and tested for uniqueness in order to maintain interoperability with RFC2462 behaviour.
I think that configuring additional addresses which don't match the prefix used to generate the suffix in the CGA is going to cause problems.
(the following is simplified): Essentially, the CGA is generated from a nonce, a prefix and a public key.
in this case:
prefix::PrK(Hash(Nonce,prefix,PuK)).
The recipient of the nonce and public key (provided in SEND messages can check that the private key owner generated the address.
If the prefix changes and the suffix stays the same:
the receiver would have fe80::PrK(Hash(Nonce,Prefix,PuK)) and the Nonce and PuK, but not the original prefix.
Unless the recipient knows the original prefix, the hash is useless (doesn't prove anything).
The messages would have to be treated as unsecured for SEND (unless new SEND procedures were defined).
I'm pretty sure that SEND nodes work around unsecured messages in the case of DAD (they currently accept a single unsecured DAD NA response.
The solution is pretty ugly though, since it relies upon function which is hacked into SEND.
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
