> > Proposed resolution: write "MAY be disabled" instead. > > Um, I'd suggest that this by itself isn't really all that helpful. It > might help to add some more explanatary text together with > recommendations on what to do. E.g., > > - should an implementation just configure the address and use it > anyway? (I doubt this, as this implies we should just punt on DAD)
No, we clarified later that the implementation should disable the address. > - Assume there is a DOS attack, wait a while, and try again? (hoping > the bad guy goes away in the meantime) I would not specify that.. > - generate a new IID and try again? And if so, are there > recommendations on what kind of ID? And if there is a DOS attack > in progress, why would trying *any* address result in success? Yes. The implementation may very well have access to several EUI-64, and may try an alternative. Or, it may try to use a random address. The persistence of DAD collision would indicate with quasi certainty a DOS attack. Forcing the attacker to repeat the attack increases the chances of detection. > - Try generating a new address, but use exponential backoff in > delaying after each failed attempt? That is a variation of the above. It may be useful in some cases, e.g. when turning of the interface briefly saves energy. > - something else? (or some combination of the above?) Maybe. There is no limit to creativity. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
