Re: [rfc2462bis issue 275] DAD text inconsistencies
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rfc2462bis issue 275] DAD text inconsistencies
Hi Sharkey,
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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.