On 31-jul-2006, at 9:31, marcelo bagnulo braun wrote:
First, it is customary to require a mandatory to implement security mechanism for IETF specs. Without this, there will be very little interoperability. But it doesn't rule out pluggable security mechanisms, just that one of them has to be mandatory.
Well, if people feel the patent issues with CGA/HBA are such that they can't implement those, should we prohibit them from implementing shim6 altoghether? That doesn't make too much sense...
moreover, i think it would be interesting to understand how the protocol would behave, if for instance, one end supports only HBA and the other end only supports CGA (or other two different security mechanisms)
And: it's possible that an implementation supports a certain security mechanism for authenticating its own stuff but not for checking the authentication of the other side, or the other way around. So we need to exchange capabilities for both send and receive.
(the reception of packet is done solely based on the context tag, so it doesn't matter which source locator is used).
I don't like this assumption...
perhaps one option would be to include something like the Locator List Option in the ack message where the receiver of the update message can ack each locator separately and also specify the reason why it doesn't ack a given locator (including a code for validation method not supported)
Does it make sense to have different authentication mechanisms for different locators?
Iljitsch