El 31/07/2006, a las 12:15, Jari Arkko escribió:
marcelo bagnulo braun wrote:well, what we have in the current protocol is that the Locator List Option Format has a one octet of Verification Method per locator included in the option, so that we can specify the mechanism used to validate each of the locators (currently only HBA and CGA methods are defined in the draft)Ah, I missed that. This may be enough.however, it is not obvious at this point what a host can do if the validation method for the locators is not supported.Behave as if you did not support multihoming for this set of locators? But it is necessary to let the other end know about this.
yes, especally becuase the other could convey the locator set using an alternative mechanism
For instance suppose a host that supports both HBA and CGA and the other end only supports CGA
The HBA/CGA host can initially send the locator set validated with HBA (because is cheaper). If the CGA only host only ignores this locators, then we may have no alternative locators to fall back the communication. However, if the CGA only host informs the CGA/HBA host that he doesn't support HBA the CGA/HBA host could send the locator set again using CGA validation and the result is that the alternative locator set will be non empty
OTOH, i wouldn't want to have a full security mechanisms capabilities exchange in the shim6 protocol, since the complexity would raise considerably (and after all, shim6 is not a security protocol , i think :-)
Regards, marcelo
--Jari